Sistema Web Con Acceso a Bases de Datos Multiplataforma a Través de Dispositivos Móviles.

Universidad Nacional del Nordeste
Facultad de Ciencias Exactas, Naturales y Agrimensura
Trabajo Final de Aplicación
Sistema Web con Acceso a Bases de Datos
Multiplataforma a Través de Dispositivos
Móviles
Juan Felix Basterretche - L.U.: 34039
Profesores Orientadores:
Mgter. David Luis la Red Martínez
Lic. Valeria Emilce Uribe
Licenciatura en Sistemas de Información
Corrientes - Argentina
2009
A mi familia y amigos por su incansable apoyo
Prefacio
En los últimos años se han realizado grandes avances en tecnologías de comunicación móvil, lo cual hace posible que hoy en día la sociedad tenga acceso
a información útil del contenido de las bases de datos, mediante dispositivos
móviles. Es decir, hoy un usuario de un PDA, o bien un usuario de un teléfono
celular puede navegar por internet desde el mismo utilizando redes, en este
caso inalámbricas.
La aparición de tecnologías como bluetooth y wi-fi han revolucionado la
manera en que los usuarios desean conectarse, ya que ambas tecnologías presentan pocas dificultades para lograr la conexión entre distintos dispositivos
debido a la estandarización de las mismas.
Estas tecnologías se han desarrollado tanto hasta abarcar escenarios donde
la utilización de dispositivos móviles presentan grandes ventajas y comodidades, ya que cada vez se ven más servicios que antes solo podían ser utilizados
a través de computadoras personales conectadas a redes cableadas.
Considerando esto, se ve la necesidad de estudiar detalladamente estas tecnologías para poder explotar las oportunidades que los servicios de Internet y
los dispositivos móviles presentan a la sociedad, ya que, juegan un papel fundamental en todos los ámbitos: Profesionales, culturales, educativos, comerciales
y otros.
Desde la aparición de las computadoras éstas han sido usadas en los sistemas de información de las empresas para facilitar el trabajo de control y
gestión gracias a la capacidad de recopilar y procesar gran cantidad de datos. En entornos fuertemente competitivos las empresas han comprendido que
las inversiones en tecnologías de la información pueden incrementar de forma
significativa la competitividad de la empresa.
Aunque las necesidades tecnológicas de los restaurantes parezcan inferiores
en comparación a otros sectores, muchos estudios hablan del uso de las TIC
en los mismos, que a causa de una competencia creciente, estos restaurantes
cada vez se ven más obligados a realizar inversiones en este campo. Hoy en día
parece impensable que un restaurant no tenga página web y en el caso ideal
su sistema de información debería estar preparado para afrontar retos como
el “E-Commerce” o poder ofrecer servicios como Wi-Fi a sus clientes.
Para satisfacer lo anteriormente mencionado, en este trabajo se propuso
el desarrollo de una aplicación con software de computación móvil multipla-
vi
taforma, que permita el acceso a información situada en bases de datos multiplataforma en un servidor Web, a través de dispositivos móviles tales como
PDAs.
La aplicación se ha desarrollado para correr en PDAs, se basa en el trabajo
de un mozo de restaurant, es decir, permite el registro y el seguimiento de
pedidos de clientes dentro del restaurant. Para esto, el mozo deberá utilizar
un PDA con el aplicativo instalado.
Esto significa disminuir los tiempos de atención en cada mesa, ya que cada
acción que realice el mozo sobre los datos, esto se reflejará en las bases de
datos del restaurant.
A su vez se propuso el desarrollo de la plataforma Web de la aplicación
que sea accesible desde la Intranet, que contemple funciones adicionales como
ser: registro de usuarios, registro de nuevos platos o bebidas que formarán
parte del menú, poder ver en cada momento los pedidos que van registrando
los mozos, facturar los mismos, y además obtener estadísticas.
Se propuso también el desarrollo de un sitio Web accesible desde Internet,
que simula ser el sitio de un restaurant, el cual contemple funciones de ecommerce como ser: registro de clientes, registro y atención de solicitudes de
reservas on-line, permitiendo a un cliente realizar una reserva donde puede
expresar los platos y bebidas que desea para la misma.
Objetivos Logrados
Se han alcanzado plenamente la totalidad de los objetivos planteados para
el presente trabajo:
• Desarrollo de una aplicación utilitaria empleando un software de computación móvil multiplataforma para PDAs que permita acceder a información situada en una base de datos que se encuentra en un servidor
Web, mediante una red wi-fi.
• Desarrollo de la plataforma web de la aplicación con acceso a bases de
datos, que sirva de apoyo a la aplicación móvil.
• Desarrollo de la plataforma web que simula ser el sitio web de un restaurant que permita realizar reservas on-line.
vii
Clasificación del Trabajo
El trabajo se encuadra en la utilización de software de base que permite el
desarrollo de aplicaciones que permitan el acceso a bases de datos multiplataformas desde dispositivos móviles tales como PDAs.
Etapas de Desarrollo
• Se ha efectuado una amplia recopilación bibliográfica específica a los
temas pertinentes a la tarea planificada y a los productos de software
que se emplearon para la concreción del trabajo final.
• Gracias a las gestiones realizadas por el Profesor Orientador Mgter. David Luis la Red Martinez ante IBM Argentina se han recibido materiales
tanto en CDs como en libros de dicha empresa, en el marco del Scholars
Program de la misma, destinado a Universidades de todo el mundo; se
destacan por ser necesarios para la realización del presente Trabajo Final
los productos de software como los siguientes:
— WebSphere Studio Application Developer versión 5.0 y 5.1.2.
— DB2 UDB WorkGroup Server Edition versión 8.1.
— WebSphere Studio Device Developer versión 5.7.1.
• Se ha efectuado un estudio acerca de las arquitecturas de aplicaciones
móviles.
• Se ha realizado el análisis y diseño de la base de datos que utiliza la
aplicación.
• Se ha realizado el estudio del manejador de bases de datos DB2 UDB
para Windows.
• Se ha realizado un detallado estudio del J2ME (versión de Java para
móviles), para la herramienta de desarrollo WebSphere Studio Device
Developer versión 5.7.1.
• Se ha realizado un detallado estudio del software para el desarrollo de
las plataformas web de la aplicación, WebSphere Studio Application Developer versión 5.1.2.
viii
• Se ha desarrollado el aplicativo móvil con la utilización del lenguaje Java,
versión J2ME.
• En el marco de la herramienta WebSphere Studio Application Developer se desarrollaron los módulos web del aplicativo utilizadando páginas
XHTMLs, JSPs y Servlets de Java.
• Una vez finalizada la etapa de desarrollo se realizaron las siguientes actividades:
— Empaquetado de la aplicación móvil para su distribución e instalación en los PDAs.
— Instalación del simulador de la Palm TX.
— Instalación y prueba de la aplicación tanto en los emuladores como
así también en una Palm TX real.
— Testeo del sistema, simulando un escenario real realizando pruebas
de conexión entre el sistema móvil y el servidor web a través de
wi-fi en una Intranet.
• Finalizada la aplicación se realizó la grabación en DVD de todo el material correspondiente al trabajo final: una versión de la aplicación, otra
referente al libro en formato LaTex y el PDF generado. También se incluyó los instaladores de los productos utilizados para el desarrollo, es
decir DB2 UDB, WebSphere Studio Application Developer, WebSphere
Studio Device Developer y emuladores.
Organización del Informe Final
El trabajo final de aplicación comprende un informe final impreso y un
DVD además de un resúmen y de un resúmen extendido.
El informe final está organizado en capítulos los que se indican a continuación:
• Introducción: Se presenta una vision global acerca de las nuevas tecnologías de información y comunicaciones, como así también las principales
caracteristicas del comercio electronico móvil, computación ubicua y de
la sociedad de la información y el conocimiento.
ix
• Tecnología móvil: Se indican los principales dispositivos móviles y su
evolución, y se explican las diferentes tecnologías de conexión inalámbricas de estos.
• Aplicaciones móviles: Se explican los requerimientos necesarios para una
aplicación móvil.
• Java: Se presentan los principales aspectos y características referidas al
lenguaje.
• Java 2 Micro Edition: Se detallan las conceptos y características del
lenguaje Java para dispositivos electrónicos con menos recursos.
• Introducción al DB2: Se detallan las más relevantes características de
esta familia de productos de gestión de bases de datos.
• WebSphere Studio: Presenta los principales aspectos de este entorno de
aplicaciones complejas.
• Descripción de la aplicación: Se describen todos los aspectos de la aplicación desarrollada utilizando las herramientas antes mencionadas.
• Conclusiones: Se presentan las conclusiones a las que se ha llegado al
finalizar el presente trabajo y las posibles líneas futuras de acción.
El DVD adjunto al informe final impreso, contiene lo siguiente:
— Instaladores del software utilizado.
— Resúmenes del trabajo realizado.
— Informe final en formato digital.
— Presentación para la defensa final.
— Aplicación desarrollada.
Juan Felix Basterretche
Licenciatura en Sistemas de Información
Universidad Nacional del Nordeste
L.U.: 34039
Corrientes; 19 de Noviembre de 2009
x
Índice General
1 Introducción
1.1 Comercio Electrónico . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Forma en que los actores se relacionan . . . . . . . . . .
1.1.2 Espacio donde se realizan las operaciones . . . . . . . .
1.1.3 El comercio y la función tiempo . . . . . . . . . . . . . .
1.1.4 Actores . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.5 Otras Concepciones del Comercio Electrónico . . . . . .
1.1.6 Esquema General . . . . . . . . . . . . . . . . . . . . . .
1.1.7 Modelos de Comercio Electrónico . . . . . . . . . . . . .
1.2 M-Commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Computación Ubicua . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Concepto . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3 Diseño centrado en el usuario . . . . . . . . . . . . . . .
1.4 La Ley de Moore y la Visión de Weiser . . . . . . . . . . . . . .
1.5 SIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1 La Visión Sobre las Sociedades de la Información y de
la Comunicación . . . . . . . . . . . . . . . . . . . . . .
1.5.2 Principios Guía . . . . . . . . . . . . . . . . . . . . . . .
1.5.3 Hacia las sociedades de información y comunicación . .
1.6 TICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1 Aspecto social de las TIC . . . . . . . . . . . . . . . . .
1.7 Tecnología en el Restaurant . . . . . . . . . . . . . . . . . . . .
1.7.1 Beneficios e inconvenientes del uso de las tecnologías de
la información en el sector gastronómico. . . . . . . . .
1
1
1
2
3
3
4
4
5
7
8
8
8
11
15
17
17
18
18
19
20
20
21
2 Tecnología Móvil
25
2.1 Telefonía Móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1 Celulares: Concepto General . . . . . . . . . . . . . . . 25
xi
xii
ÍNDICE GENERAL
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
28
32
34
35
36
37
39
40
42
42
43
46
49
50
. . . .
Móvil
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
53
54
56
59
62
63
4 Java
4.1 Introducción al Lenguaje . . . . . . . . . . . . . .
4.1.1 Bibliotecas de Clases Estándares de Java
4.1.2 Java es Multiplataforma . . . . . . . . . .
4.1.3 Características del Lenguaje . . . . . . . .
4.2 Estructura de un Programa Java . . . . . . . . .
4.3 Conceptos Básicos . . . . . . . . . . . . . . . . .
4.3.1 Clases . . . . . . . . . . . . . . . . . . . .
4.3.2 Herencia . . . . . . . . . . . . . . . . . . .
4.3.3 Interfaces . . . . . . . . . . . . . . . . . .
4.3.4 Package . . . . . . . . . . . . . . . . . . .
4.4 Variables de Java . . . . . . . . . . . . . . . . . .
4.4.1 Datos de Objetos o Instancia . . . . . . .
4.4.2 Datos de Clase . . . . . . . . . . . . . . .
4.5 Operadores del Lenguaje Java . . . . . . . . . . .
4.5.1 Operadores Aritméticos . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
65
67
68
69
70
71
71
72
72
73
73
75
75
76
76
2.2
2.3
2.4
2.5
2.6
2.7
2.1.2 Un Poco de Historia . . . . . . .
2.1.3 Generaciones del Celular . . . . .
La Computadora Portátil . . . . . . . .
PDAs . . . . . . . . . . . . . . . . . . .
2.3.1 Historia de las PDAs . . . . . . .
2.3.2 Atari Portfolio . . . . . . . . . .
2.3.3 Apple Newton . . . . . . . . . .
Palm Pilot 5000 . . . . . . . . . . . . . .
Sistemas operativos y equipos . . . . . .
Estándares . . . . . . . . . . . . . . . .
2.6.1 Bluetooth . . . . . . . . . . . . .
2.6.2 IrDA - Infrared Data Association
2.6.3 IEEE 802.11 o Wi-Fi . . . . . . .
Internet Móvil - WAP . . . . . . . . . .
2.7.1 Tecnología - WAP . . . . . . . .
3 Aplicaciones Móviles
3.1 Introducción . . . . . . . . . . . . . . .
3.2 Requerimientos Para una Arquitectura
3.3 Arquitectura de Portal Móvil . . . . .
3.4 Arquitectura de Bases de Datos . . . .
3.5 Aplicaciones Multiplataforma . . . . .
3.5.1 Java y Multiplataforma . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE GENERAL
4.6
4.7
4.5.2 Operadores de Asignación . .
4.5.3 Operadores Unarios . . . . .
4.5.4 Operador Instanceof . . . . .
4.5.5 Operador Condicional . . . .
4.5.6 Operadores Incrementales . .
4.5.7 Operadores Relacionales . . .
4.5.8 Operadores de Concatenación
Estructuras de Programación . . . .
4.6.1 Sentencias o Expresiones . . .
4.6.2 Comentarios . . . . . . . . .
4.6.3 Bifurcaciones . . . . . . . . .
4.6.4 Bucles . . . . . . . . . . . . .
Servlets . . . . . . . . . . . . . . . .
4.7.1 Estructura de un Servlet . . .
4.7.2 Instanciación e Inicialización
4.7.3 Servicio de Demanda . . . . .
4.7.4 Terminación . . . . . . . . . .
4.7.5 Java Server Faces . . . . . . .
4.7.6 Desarrollando Aplicaciones .
xiii
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
de Caracteres
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Java 2 Micro Edition
5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Comparación de Versiones . . . . . . . . . . . . .
5.1.2 Algunas Consideraciones al Desarrollar en J2ME
5.2 Componentes de J2ME . . . . . . . . . . . . . . . . . . .
5.2.1 Máquinas Virtuales J2ME . . . . . . . . . . . . .
5.2.2 Configuraciones . . . . . . . . . . . . . . . . . . .
5.2.3 Perfiles . . . . . . . . . . . . . . . . . . . . . . .
5.3 Cómo Detectar una Aplicación J2ME . . . . . . . . . .
5.4 Los MIDlets . . . . . . . . . . . . . . . . . . . . . . . .
5.4.1 El Gestor de Aplicaciones . . . . . . . . . . . . .
5.4.2 Ciclo de Vida de un Midlet . . . . . . . . . . . .
5.4.3 Estados de un MIDlet . . . . . . . . . . . . . . .
5.4.4 El paquete javax.microedition.midlet . . . . . . .
5.4.5 La Clase MIDlet . . . . . . . . . . . . . . . . . .
5.4.6 Estructura de los MIDlets . . . . . . . . . . . . .
5.5 Interfaces Gráficas de Usuario . . . . . . . . . . . . . . .
5.5.1 La Clase Display . . . . . . . . . . . . . . . . . .
5.5.2 La Clase Displayable . . . . . . . . . . . . . . . .
5.5.3 Las Clases Command y CommandListener . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
76
77
77
77
78
78
79
79
79
80
81
82
84
85
88
90
90
90
96
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
97
97
98
101
102
103
106
109
114
115
116
116
118
119
119
121
123
124
126
126
xiv
ÍNDICE GENERAL
5.6
5.7
5.5.4 Interfaz de Usuario de Alto Nivel . . . . . . . . . . . . .
RMS (Record Management System) . . . . . . . . . . . . . . .
5.6.1 Modelo de Datos . . . . . . . . . . . . . . . . . . . . . .
5.6.2 Record Stores . . . . . . . . . . . . . . . . . . . . . . .
5.6.3 Creación de un Record Store . . . . . . . . . . . . . . .
5.6.4 Manipulación de Registros . . . . . . . . . . . . . . . . .
5.6.5 Operaciones con Record Stores . . . . . . . . . . . . . .
5.6.6 Búsqueda de Registros . . . . . . . . . . . . . . . . . . .
Comunicaciones en J2ME . . . . . . . . . . . . . . . . . . . . .
5.7.1 Clases y Conexiones del Generic Connection Framework
5.7.2 Comunicaciones HTTP . . . . . . . . . . . . . . . . . .
128
137
139
140
141
142
152
152
153
153
157
6 Introducción al DB2
175
6.1 Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
6.2
6.3
6.1.1 Objetivos de las Bases de Datos . . . .
6.1.2 Ventajas de las Bases de Datos . . . . .
Sistema de Administración de Bases de Datos
Organización de Bases de Datos . . . . . . . .
6.3.1 Bases de Datos Jerárquicas . . . . . . .
6.3.2 Bases de Datos en Red . . . . . . . . .
6.3.3
6.4
Bases de Datos Relacional
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
176
176
177
179
179
180
. . . . . . . . . . . . . . . . 180
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
182
183
186
186
188
188
188
189
190
7 WebSphere Studio
7.1 ¿Qué es WebSphere? . . . . . . . . . . . . . . . . . . . . . .
7.2 Plataforma de Software . . . . . . . . . . . . . . . . . . . .
7.2.1 WebSphere for Commerce - Soluciones B2B . . . . .
7.2.2 WebSphere for Commerce - Soluciones B2C . . . . .
7.2.3 WebSphere for Commerce-Soluciones de Portal . . .
7.2.4 WebSphere for Commerce-Soluciones Digital Media .
7.3 Productos WebSphere Studio . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
193
193
194
195
195
196
197
198
6.5
Introducción a DB2 UDB . . . . . . . . . . . .
6.4.1 Características Generales del DB2 UDB
DB2 UDB Versión 8.1 . . . . . . . . . . . . . .
6.5.1 Centro de Desarrollo . . . . . . . . . . .
6.5.2 Mejoras en XML Extender . . . . . . .
6.5.3 DB2 Warehouse Manager . . . . . . . .
6.5.4 Centro de Depósito de Datos de DB2 .
6.5.5 Asistentes de DB2 . . . . . . . . . . . .
6.5.6 Centro de Mandatos . . . . . . . . . . .
. .
.
. .
. .
. .
. .
. .
. .
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE GENERAL
7.4
7.5
7.6
7.7
xv
WebSphere Studio Application Developer . . . . . . . . . . .
7.4.1 Ventajas de Utilizar a WebSphere Studio Application
Developer . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.2 Desarrollando Aplicaciones Java . . . . . . . . . . . . .
WebSphere Application Server . . . . . . . . . . . . . . . . . .
7.5.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . .
7.5.2 WebSphere Application Server Como Plataforma Para
el Comercio Electrónico . . . . . . . . . . . . . . . . . .
7.5.3 Application Server - Advanced Edition . . . . . . . . . .
7.5.4 Application Server - Enterprise Edition . . . . . . . . .
7.5.5 Application Server - Standard Edition . . . . . . . . . .
7.5.6 Servidor HTTP . . . . . . . . . . . . . . . . . . . . . . .
7.5.7 Servidor de Aplicaciones . . . . . . . . . . . . . . . . . .
7.5.8 Contenedor de EJB . . . . . . . . . . . . . . . . . . . .
7.5.9 Contenedor Web . . . . . . . . . . . . . . . . . . . . . .
7.5.10 Contenedor de Clientes de Aplicaciones . . . . . . . . .
7.5.11 Sistema Principal Virtual . . . . . . . . . . . . . . . . .
7.5.12 Virtual Hosts (Hosts Virtuales) . . . . . . . . . . . . .
WCTME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.1 WebSphere Everyplace Micro Environment . . . . . . .
7.6.2 WebSphere Everyplace Custom Environment . . . . . .
7.6.3 J9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6.4 WebSphere Studio Device Developer . . . . . . . . . . .
7.6.5 Java 2 Micro Edition (J2ME) . . . . . . . . . . . . . . .
WebSphere Studio Device Developer . . . . . . . . . . . . . . .
7.7.1 Componentes de WebSphere Studio Device Developer .
7.7.2 Herramienta de Desarrollo C (CDT) para Eclipse . . . .
7.7.3 Arquitectura de Device Developer . . . . . . . . . . . .
7.7.4 Utilización del IDE . . . . . . . . . . . . . . . . . . . . .
8 Descripción de la Aplicación
8.1 Introducción . . . . . . . . . . . . . . .
8.2 Estructuración . . . . . . . . . . . . .
8.3 Modelo de datos . . . . . . . . . . . .
8.4 Descripción de MobileChef . . . . . . .
8.4.1 Levantar Pedidos . . . . . . . .
8.4.2 Ver Pedidos . . . . . . . . . . .
8.4.3 Estructura de los Record Stores
8.5 Descripción de J-Chef . . . . . . . . .
8.5.1 Estructura de J-Chef . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
de MobileChef
. . . . . . . . .
. . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
198
201
205
207
207
208
209
210
211
211
212
212
212
213
213
213
214
215
215
215
215
216
216
217
217
218
218
223
223
224
226
235
245
250
256
259
259
xvi
ÍNDICE GENERAL
8.6
Descripción de Miarritze . . . . . . . . . . . . . . . . . . . . . . 286
8.6.1 Estructuración de Miarritze . . . . . . . . . . . . . . . . 288
9 Concluciones
299
9.1 Concluciones Generales. . . . . . . . . . . . . . . . . . . . . . . 299
9.2 Conclusiones Acerca de las Tecnologías y Software Utilizados . 300
9.3 Líneas Futuras de Acción . . . . . . . . . . . . . . . . . . . . . 301
Bibliografía
303
Índice de Materias
305
Índice de Figuras
1.1
1.2
1.3
1.4
1.5
1.6
Esquema General del Comercio Electrónico. . . . . . . . . . . .
Ideal de Computación Ubicua. . . . . . . . . . . . . . . . . . .
Arquitectura Genérica de un Dispositivo de Computación Ubicua
Fases del Diseño Orientado al Usuario . . . . . . . . . . . . . .
MarkWeiser (1952-1999), el Visionario de la Computación Ubicua
Beneficios Obtenidos de la Introducción de Tecnología. . . . . .
5
9
12
13
16
21
2.1
2.2
2.3
2.4
26
27
28
2.13
2.14
2.15
2.16
2.17
Handie Talkie12-16 . . . . . . . . . . . . . . . . . . . . . . . . .
Martin Cooper mostrando el primer teléfono celular. ArrayComm
Publicidad del Motorola Handie Talkie H12-16 . . . . . . . . .
La evolución de los teléfonos celulares fue más allá de las características técnicas. Se puede apreciar cómo en tamaño y peso
la evolución fue considerable. . . . . . . . . . . . . . . . . . . .
Celdas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arquitectura GSM . . . . . . . . . . . . . . . . . . . . . . . . .
Modelo Apple IIc de Apple Computers - 1984 . . . . . . . . . .
PC Convertible de IBM - 1986 . . . . . . . . . . . . . . . . . .
Atari Portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . .
Apple Newton . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Palm Pilot 5000 . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparativa en tamaños entre la Palm Pilot 5000 y el Apple
Newton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bluetooth Apple Mighty Mouse . . . . . . . . . . . . . . . . . .
Teclado Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . .
IrDA - Organización de sus capas. . . . . . . . . . . . . . . . .
Tarjeta Wi-Fi para PalmOne . . . . . . . . . . . . . . . . . . .
Tarjeta USB para Wi-Fi . . . . . . . . . . . . . . . . . . . . . .
3.1
Arquitectura Portal Móvil . . . . . . . . . . . . . . . . . . . . .
60
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
xvii
30
32
33
34
35
37
38
40
41
44
44
46
47
49
xviii
ÍNDICE DE FIGURAS
4.1
4.2
4.3
4.4
4.5
4.6
Mecanismo de Mensajes . . . . . . . . . . . . . . . . . . . . . .
Proceso Compilación y Ejecución . . . . . . . . . . . . . . . . .
Jerarquía y Métodos de las Principales Clases Para Crear Servlets.
Ciclo de Vida de un Servlet. . . . . . . . . . . . . . . . . . . . .
Requerimiento de un archivo JSP. . . . . . . . . . . . . . . . .
Requerimiento de un Servlet . . . . . . . . . . . . . . . . . . . .
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
5.19
Arquitectura de la Plataforma Java 2 de Sun. . .
Ubicación de las Tecnologías Java. . . . . . . . .
Proceso de Verificación. . . . . . . . . . . . . . .
Entorno de Ejecución de J2ME. . . . . . . . . . .
Ciclo de Vida de un MIDlet. . . . . . . . . . . . .
Estados de un MIDlet. . . . . . . . . . . . . . . .
Jerarquía de Clases. . . . . . . . . . . . . . . . .
Un MIDlet y el RMS. . . . . . . . . . . . . . . .
Acceso a un RMS a Través de un MIDlet Suite. .
Esturctura de Un Record Store. . . . . . . . . . .
Ejemplo RMS. . . . . . . . . . . . . . . . . . . .
Jerarquía de Interfaces. . . . . . . . . . . . . . .
Estados de una conexión HTTP. . . . . . . . . .
Ejemplo de comunicación HTTP de un MIDlet. .
Solicitud de permiso para utilizar tiempo de aire.
Iniciando el proceso de conexión. . . . . . . . . .
Conectandose a la red wi-fi. . . . . . . . . . . . .
Obteniendo dirección IP. . . . . . . . . . . . . . .
Conectado a red wi-fi. . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
100
101
105
110
117
118
124
139
140
141
151
154
158
168
169
170
171
172
173
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
Estructura de Una Base de Datos . . . . . . .
Sistema de Administración de Bases de Datos
Modelo de Bases de Datos Jerárquica. . . . .
Modelo de Bases de Datos en Red. . . . . . .
Modelo de Bases de Datos Relacional. . . . .
AIV Extender. . . . . . . . . . . . . . . . . .
XML Extender. . . . . . . . . . . . . . . . . .
Centro de Desarrollo. . . . . . . . . . . . . . .
Asistente Para Crear Tabla. . . . . . . . . . .
Centro de Mandatos. . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
178
178
180
181
182
185
185
187
190
191
7.1
7.2
La familia del WebSphere Studio. . . . . . . . . . . . . . . . . . 199
WebSphere Studio, entorno de desarrollo. . . . . . . . . . . . . 199
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
67
69
86
89
95
95
ÍNDICE DE FIGURAS
xix
7.3
7.4
7.5
7.6
7.7
7.8
7.9
7.10
. . . . . . . . . . . . . . . . . . . . . . .
Plataforma de Eclipse. . . . . . . . . . .
Asistente de Proyecto Java. . . . . . . .
Paquete Java. . . . . . . . . . . . . . . .
Diálogo de Configuración de Ejecución. .
WebSphere para e-bussines. . . . . . . .
Barra de herramientas de WSDD. . . . .
Métodos de un Objeto. . . . . . . . . . .
.
.
.
.
.
.
.
.
200
201
206
207
208
209
219
221
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13
8.14
Casos de uso del Sistema Principal. J-Chef y MobileChef. . . .
Casos de Uso del módulo Miarritze. . . . . . . . . . . . . . . . .
Modelo de datos del Sistema Principal. . . . . . . . . . . . . . .
Modelo de datos del sitio web Miarritze. . . . . . . . . . . . . .
Pantalla de Aplicaciones de una Palm TX con SO Garnet 5.4.9.
Pantalla Inicial de MobileChef. . . . . . . . . . . . . . . . . . .
Pantalla de Configuración de MobileChef. . . . . . . . . . . . .
Pantalla Default Settings. . . . . . . . . . . . . . . . . . . . . .
Inicio del Proceso de Login. . . . . . . . . . . . . . . . . . . . .
Pantalla de Alerta. . . . . . . . . . . . . . . . . . . . . . . . . .
Posibles situaciones del Proceso de Login. . . . . . . . . . . . .
Progreso del Proceso de Login. . . . . . . . . . . . . . . . . . .
Menú Principal de MobileChef. . . . . . . . . . . . . . . . . . .
Pantalla donde el Mozo debe seleccionar el Nro de mesa, y si el
cliente solicitó una Comida o una Bebida. . . . . . . . . . . . .
Levantar Pedido. . . . . . . . . . . . . . . . . . . . . . . . . . .
El item se ha cargado de manera local. . . . . . . . . . . . . . .
Items de una Orden. . . . . . . . . . . . . . . . . . . . . . . . .
Editar Pedido. . . . . . . . . . . . . . . . . . . . . . . . . . . .
El envío de los datos se realizó correctamente. . . . . . . . . . .
Mesas con pedidos del mozo. . . . . . . . . . . . . . . . . . . .
El Administrador ha atendido una Reserva y la ha convertido
en Pedido Activo. . . . . . . . . . . . . . . . . . . . . . . . . . .
Se ha habilitado el comando Cerrar debido a que todas las ordenes poseen un estado Entregado. . . . . . . . . . . . . . . . .
Formulario donde se capturan los datos necesarios para la posterior Facturación. . . . . . . . . . . . . . . . . . . . . . . . . .
Se ha registrado correctamente el pedido para poder ser Facturado por el Cajero. . . . . . . . . . . . . . . . . . . . . . . . . .
Pantalla inicial de J-Chef. . . . . . . . . . . . . . . . . . . . . .
225
226
227
231
237
238
239
240
241
242
243
244
245
8.15
8.16
8.17
8.18
8.19
8.20
8.21
8.22
8.23
8.24
8.25
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
246
247
248
249
250
251
252
253
254
255
256
260
xx
ÍNDICE DE FIGURAS
8.26 No se han rellenado correctamente los campos necesarios para
el proceso de Login. . . . . . . . . . . . . . . . . . . . . . . . .
8.27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.28 Inicio del Panel de Administrador. . . . . . . . . . . . . . . . .
8.29 Usuarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.30 Nuevo Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.31 Se debe seleccionar el usuario a editar. . . . . . . . . . . . . . .
8.32 Gestión del Menú. . . . . . . . . . . . . . . . . . . . . . . . . .
8.33 Nuevo Item de Menú. . . . . . . . . . . . . . . . . . . . . . . .
8.34 Luego de seleccionar Tipo, Categoría y Sub Categoría se habilitan los campos a rellenar para el nuevo ítem de menú. . . . .
8.35 Editar Item de Menú. . . . . . . . . . . . . . . . . . . . . . . .
8.36 Gestión de Estadísticas. . . . . . . . . . . . . . . . . . . . . . .
8.37 Todos los Usuarios. . . . . . . . . . . . . . . . . . . . . . . . . .
8.38 Escoger opciones de selección en Estadísticas de Mozos. . . . .
8.39 Opción que requiere de una parámetro de comparación. . . . .
8.40 Ver Comidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.41 Listado de Items resultado de una consulta estadística. . . . . .
8.42 Buscar facturas por monto. . . . . . . . . . . . . . . . . . . . .
8.43 Facturas que coinciden con los parámetros de búsqueda ingresados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.44 Cantidad de Mesas con las que va a trabajar el Restaurant. . .
8.45 Modificar Perfil del Administrador. . . . . . . . . . . . . . . . .
8.46 Logout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.47 Inicio del panel de Jefe de Cocina. . . . . . . . . . . . . . . . .
8.48 Ver Pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.49 Modifcar Perfil del Jefe de Cocina. . . . . . . . . . . . . . . . .
8.50 Inicio del Panel de Cajero. . . . . . . . . . . . . . . . . . . . . .
8.51 Lista de Pedidos listos para Facturar. . . . . . . . . . . . . . .
8.52 Facturas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.53 Modificar Perfil del Cajero. . . . . . . . . . . . . . . . . . . . .
8.54 Pantalla Inicial de Miarritze. . . . . . . . . . . . . . . . . . . .
8.55 Miarritze - Quienes Somos?. . . . . . . . . . . . . . . . . . . . .
8.56 Miarritze - Servicios. . . . . . . . . . . . . . . . . . . . . . . . .
8.57 Miarritze - Contacto. . . . . . . . . . . . . . . . . . . . . . . . .
8.58 Registro de Clientes de Miarritze . . . . . . . . . . . . . . . . .
8.59 Cliente Logeado. . . . . . . . . . . . . . . . . . . . . . . . . . .
8.60 Miarritze - Reservas y Pedidos. . . . . . . . . . . . . . . . . . .
8.61 Solicitud de Reserva con Pedidos. . . . . . . . . . . . . . . . . .
260
261
262
263
264
264
265
266
266
267
270
270
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
290
291
292
292
293
ÍNDICE DE FIGURAS
8.62
8.63
8.64
8.65
8.66
8.67
Reserva Registrada. . . . . . . . . . . . . . . . . . . . . . . . .
Miarritze - Configuración. . . . . . . . . . . . . . . . . . . . . .
Miarritze - Listado de Reservas según su Estado. . . . . . . . .
Confirmar o Rechazar una Reserva . . . . . . . . . . . . . . . .
Atender Reserva. . . . . . . . . . . . . . . . . . . . . . . . . . .
La Reserva se ha registrado como pedido activo correctamente.
xxi
294
295
296
296
297
297
Capítulo 1
Introducción
1.1
Comercio Electrónico
Antes de intentar una definición de comercio electrónico, resulta apropiado
analizar los distintos aspectos y características que hacen a la esencia misma
de esta forma de comercio.
Las particularidades del comercio electrónico están dadas, tanto por la forma en que los actores interactúan, como por la nueva dimensión que adquieren
las funciones de tiempo y espacio. Aunque el comercio electrónico mantiene
ciertas analogías y similitudes con el comercio tradicional, dentro de su contexto, los actores pasan a cumplir nuevos roles, operando en un nuevo ámbito
y siguiendo los lineamientos de nuevos principios. [1]
1.1.1
Forma en que los actores se relacionan
En el comercio electrónico no existe contacto físico directo entre los actores.
Las operaciones se realizan a través de medios electrónicos de comunicación,
de ahí que en un sentido amplio algunas personas incluyan dentro de esta
modalidad de comercio a aquellas operaciones que, aunque originadas en una
oferta publicada en catálogos u otros medios gráficos, o publicitada a través
de la radio o la televisión, sean finalizadas por medios de comunicación como
el teléfono o el fax.
En un sentido más estricto, sólo se consideran operaciones de comercio
1
2
CAPÍTULO 1. INTRODUCCIÓN
electrónico a aquellas realizadas enteramente a través de medios digitales de
comunicación como Internet, Intranets, Extranets, o sistemas de Intercambio
Electrónico de Datos (EDI: Electronic Data Interchange).
1.1.2
Espacio donde se realizan las operaciones
Si se llama mercado al lugar donde interactúan compradores y vendedores se
verifica que desde la antigüedad esta interacción está asociada a un lugar físico
determinado. De una forma u otra esta tradición aún continua, y se pueden
encontrar dos tipos de mercados físicos:
• Aquel en el cual comprador y vendedor se encuentran en persona a los
fines de realizar la transacción.
• Aquel que se refiere específicamente al lugar donde la operación es llevada
a cabo, abarcando de este modo a las operaciones que se asocian a dicho
lugar físico. Como ejemplo pueden ser mencionados los mercados de
valores o bolsas donde gente de un lugar u otro del planeta compra o
vende títulos comercializables pertenecientes a corporaciones localizadas
en cualquier lugar del mundo.
Esta dualidad de mercado abriría en principio la posibilidad de asignar las
transacciones o bien al sitio donde está localizado el vendedor, o bien al lugar
donde está situado el comprador. Lo importante es destacar que en ambos
casos las operaciones comerciales ocurren en un lugar determinado. Hasta
ahora siempre ha existido un nexo inseparable entre la operación y el lugar
físico-geográfico en el cual se realiza.
Frente a esta realidad, el comercio electrónico ha abierto una tercera posibilidad: que las operaciones ocurran dentro de un espacio virtual, no específico.
En este caso, la problemática esta planteada por el hecho de que, legalmente, a los fines de otorgarle validez a la transacción, los mismos marcos
regulatorios del comercio requieren la presencia de un lugar físico donde circunscribirla. Dadas las particularidades del comercio electrónico, surge la necesidad de establecer lineamientos normativos adecuados, a fin de dar solución
al vacío legal existente.
1.1. COMERCIO ELECTRÓNICO
1.1.3
3
El comercio y la función tiempo
El comercio tradicional sólo funciona durante ciertos periodos de tiempo, es
decir durante determinados horarios o durante ciertas épocas del año. En dicho comercio, las respuestas a los estímulos producidos por los actores pueden
tomar días, semanas y hasta meses. Si una determinada empresa decide, por
ejemplo, presentar un producto nuevo o lanzar un mensaje a sus potenciales clientes tardará un tiempo en conocer los resultados y requerirá aún más
tiempo para modificarlos en caso de ser necesario.
El comercio electrónico no involucra horarios. Trabaja 24 horas al día,
los 365 días del año. Opera permanentemente un agente electrónico que es
capaz de brindar los datos requeridos, tomar pedidos u ofrecer variedad de
servicios. De igual modo interactúa, obtiene información y la transforma en
conocimiento en tiempo real, sin demoras y casi instantáneamente.
1.1.4
Actores
Como se ha visto en el punto anterior. Los actores del comercio electrónico
pueden no ser humanos.
Los agentes electrónicos son capaces de realizar una gran cantidad de funciones. Si bien es cierto que aún no están muy desarrollados, empresas como
Apple o instituciones educativas como el M.I.T. están trabajando en el desarrollo de dichas tecnologías, así como otras compañías dedicadas a la producción
de software para Internet.
Los robots o agentes electrónicos, una vez preestablecidos ciertos parámetros, poseerán la capacidad de buscar, comparar, “negociar” y completar operaciones sin la necesidad de que intervenga un ser humano. En comparación
con las opciones ofrecidas en los distintos sitios de la red, aún un agente electrónico poco sofisticado puede, actualmente, encontrar el mejor valor tanto
para un libro como para un CD o un pasaje aéreo.
Luego de haber analizado los elementos que le otorgan al comercio electrónico sus propiedades distintivas, llegamos a definirlo como:
“Toda transacción comercial (producción, publicidad, distribución y venta
de bienes y servicios) realizada tanto por personas, empresas o agentes electrónicos a través de medios digitales de comunicación, en un mercado virtual
4
CAPÍTULO 1. INTRODUCCIÓN
que carece de límites geográficos y temporales.”
1.1.5
Otras Concepciones del Comercio Electrónico
• Transacciones de negocios efectuadas mediante redes públicas o privadas, incluyendo transacciones públicas y privadas que utilizan Internet
como instrumento de entrega. Estas transacciones incluyen transferencias financieras, intercambios en línea, subasta, entrega de productos y
servicios, actividades de la cadena de abastecimiento y redes de negocios
integradas. [2]
• El Comercio Electrónico (e-Commerce) es la simple replicación de un
negocio en Internet u otro medio electrónico que permita recoger los
pedidos u ofertar los productos y/o servicios desde o hacia clientes o
proveedores. Por ejemplo vender zapatos en la página web de la empresa,
recibir los pedidos desde la web, por ejemplo, en forma de e-mail o a
una base de datos y hacer los despachos. Muchas veces esta actividad
puede generar duplicación de tareas o tareas extras para asentar esas
transacciones en los sistemas digitales centrales del negocio.
1.1.6
Esquema General
El comercio electrónico se puede definir como un intercambio electrónico de
datos que se utilizan para dar soporte a transacciones comerciales, es decir, un
intercambio de valores entre un vendedor o comerciante (ofertante de bienes
y servicios) y un comprador (demandante de bienes y servicios). [3]
La mayor parte de los sistemas actuales de comercio electrónico consiste
básicamente en un vendedor que oferta sus productos a través de un catálogo
(preferentemente actualizado) y unos compradores de dicho producto quienes
consultan el catálogo ofrecido por el vendedor y a su vez tienen la posibilidad
de comprar dichos productos.
Se puede sintetizar el ciclo de compra en las siguientes etapas:
• La entidad vendedora (ofertante) oferta sus productos mediante un catalogo actualizado.
• La entidad compradora (demandante) consulta los productos ofertados.
1.1. COMERCIO ELECTRÓNICO
5
• La entidad compradora (demandante) realiza el pedido.
• La entidad vendedora (ofertante) acepta el pedido y lo confirma.
• Finalmente es necesario realizar la entrega del producto y el pago (ambos
procesos se pueden realizar indistintamente de forma electrónica o no).
Todos los intercambios entre compradores y vendedores en el escenario
electrónico o virtual se realizan de forma no presencial mediante la utilización
de redes de transmisión como el caso de la red Internet. Como se puede
apreciar en la figura 1.1 de la página 5.
Figura 1.1: Esquema General del Comercio Electrónico.
1.1.7
Modelos de Comercio Electrónico
B2C (Bussines to Consumer) (Negocio a Cliente Final)
Es el negocio orientado hacia el consumidor final (internauta particular
que navega por la red).
Las empresas ofrecen sus productos a particulares a través de su portal
web. El único requisito es conectarse a su web y hacer un pedido.
Se considera el original comercio electrónico.
Las estadísticas indican que cada vez se compra más por Internet, pero la
evolución es lenta comparada con las expectativas que se habían creado.
Tiene el riesgo de que los clientes puedan comparar precios fácilmente, con
lo que el marketing y el posicionamiento de la marca son muy importantes.
Gran parte de su éxito depende de:
6
CAPÍTULO 1. INTRODUCCIÓN
• La originalidad del negocio.
• La comodidad para el comprador.
• La rapidez de la entrega.
• El precio (ahorro con respecto al comercio tradicional).
B2B (Bussines to Bussines) (Negocio a Negocio)
A este tipo de comercio también se lo conoce como comercio mayorista.
En este caso las entidades comerciales son empresas.
Congrega a proveedores, compradores e intermediarios que se ofrecen mutuamente sus productos en base a unas reglas de negocios fijadas.
Es el verdadero impulsor del comercio electrónico.
El volumen de negocio entre empresas es muy superior al negocio dirigido
al cliente final.
C2C (Consumer to Comsumer) (Consumidor a Consumidor)
La negociación se desarrolla entre personas con intereses similares indistintamente de la parte compradora y vendedora. La comunicación se realiza de
forma espontánea y los participantes pueden asumir roles de comprador, vendedor o ambos. Requiere sistema de intermediario para garantizar la confianza
entre los participantes.
Un ejemplo podría ser un sitio de subastas, donde un particular ofrece un
producto y otro lo compra. Es necesario pasar por un intermediario, que es la
subasta, con lo que se podría resumir en dos negocios B2C paralelos.
Otra categoría de comercio electrónico que seguramente impactará en el
futuro es Mobile-Commerce (M-Commerce) o comercio electrónico a través de
teléfonos móviles.
Se fundamenta en lo siguiente:
• La penetración de la telefonía móvil.
• El acceso gratuito/tarifa plana a Internet.
• La implantación de la tarjeta inteligente. Los móviles inteligentes.
1.2. M-COMMERCE
7
• Telefonía inalámbrica digital.
• La convergencia: Teléfono fijo/móvil/Internet.
El potencial de usuarios de teléfonos móviles es superior al de los internautas.
Los estudios de empresas consultoras de comercio electrónico apuestan por
el comercio electrónico móvil , como el de mayor desarrollo e impacto futuro.
1.2
M-Commerce
Teniendo en cuenta todas las ventajas que el E-COMMERCE ha demostrado
tener, surge una pregunta, ¿Por qué es necesario estar atado a la pantalla de
un computador en un escritorio para poder disfrutar de los servicios y de los
beneficios del E-COMMERCE ? La respuesta está en el M-COMMERCE , el
cual nos ofrece el valor agregado de la movilidad y nos libera de las conexiones
fijas. El M-COMMERCE consiste en el uso de terminales móviles (Teléfonos
celulares, Asistentes personales Digitales - PDAs, Palms, LapTops, etc.) y de
redes móviles públicas o privadas para accesar información y conducir transacciones que resultan en la transferencia de valor mediante el intercambio de
información, bienes o servicios.
El fuerte desarrollo de la norma GSM en Europa, el sistema de SMS, y especialmente el WAP, facilitaron el acceso móvil e interactivo a datos, abriendo
nuevas posibilidades para el comercio. Pero esas oportunidades tienen algunas
dificultades como el ancho de banda limitado que aún complica las transmisiones, y la interfaz de usuario de los dispositivos móviles es limitada en tamaño.
Además, los costos de acceso son altos, y el poder de cómputo de estos
dispositivos es mucho más pequeño que el de las PCs.
El M-Commerce involucra tres aspectos básicos:
• Oferta de los negocios y servicios en un área circundante al usuario.
• Información oportuna georeferenciada mientras el usuario está en movimiento.
• Posibilidad de completar la transacción de forma inmediata.
8
CAPÍTULO 1. INTRODUCCIÓN
Por ello debe ofrecer al usuario las siguientes prestaciones:
• Negociación y entrega inmediata.
• Métodos de micro y macro pagos.
• Facilidades de uso en el contexto móvil.
1.3
Computación Ubicua
La ubicuidad es la propiedad por la cual una entidad existe o se encuentra en
todos los sitios al mismo tiempo. La Computación Ubicua pretende la integración de las nuevas tecnologías en el entorno personal, insertando dispositivos
inteligentes en las tareas diarias, haciendo que interactúen de forma natural
y desinhibida en todo tipo de situaciones y circunstancias. De esta forma se
pretende unir el mundo real con una representación virtual, apoyándose sobre
la inteligencia ambiental y logrando el entorno inteligente.
1.3.1
Concepto
La Computación Ubicua, también denominada Computación Pervasiva, fue
descrita por primera vez por Mark Weiser en 1991. La esencia de su visión era
la creación de entornos llenos de computación y capacidad de comunicación,
integrados de forma inapreciable con las personas. En la fecha en que Weiser
describió su idea no existía la tecnología necesaria para llevarla a cabo, por
lo que no era posible desarrollarla, pero después de una década de progreso,
estas ideas son productos comercialmente viables, aún cuando fueron en sus
orígenes criticadas. [4]
1.3.2
Objetivos
Uno de los objetivos más importantes de la Computación Ubicua es integrar
los dispositivos computacionales lo más posible, como se puede ver en la figura
1.2 de la página 9, para hacer que se mezclen en la vida cotidiana, y permitir a
los usuarios centrarse en las tareas que deben hacer, y no en las herramientas
que deben usar, pudiendo suponer una revolución que cambie el modo de vida.
El hecho de enviar la computación a un “segundo plano” tiene dos significados:
1.3. COMPUTACIÓN UBICUA
9
• El primero es el significado literal, detallando que la tecnología de la
computación se debe integrar en los objetos, cosas, tareas y entornos
cotidianos.
• El segundo se refiere a que esta integración se debe realizar de forma
que estos elementos no deben interferir en las actividades para las que
son usadas, proporcionando un uso más cómodo, sencillo y útil de los
mismos.
Figura 1.2: Ideal de Computación Ubicua.
Como ya se ha detallado, en su momento la Computación Ubicua era una
visión inalcanzable, pero hoy en día la evolución de las tecnologías, hacen que
ésta sea viable. Siguiendo la Ley de Moore, las previsiones se van cumpliendo,
y la capacidad de cómputo de los procesadores avanza rápidamente, además de
la capacidad de almacenamiento, el ancho de banda para las comunicaciones,
etc. En resumen, cada poco tiempo tenemos dispositivos más baratos, más
pequeños y más potentes, siendo la previsión para los próximos tiempos que
siga ocurriendo lo mismo, excepto para un factor, las baterías. Esto supone
10
CAPÍTULO 1. INTRODUCCIÓN
una limitación para los dispositivos que se tratan aquí, porque las capacidades
de procesamiento y de almacenamiento crecen exponencialmente, y también,
aunque no al mismo ritmo crece el consumo de energía pero la capacidad para
dotar a estos dispositivos de la energía necesaria crece muy lentamente. [5]
Con las nuevas tecnologías también disponemos de nuevos materiales, dando lugar a novedosos sistemas, pero también existen otros en pleno desarrollo
que pueden presentar grandes avances en la Computación Ubicua.
Por lo tanto, los objetos cotidianos en los que se integra la tecnología de
computación, tienen una serie de características que permiten y delimitan la
creación del entorno ubicuo buscado: Comunicación entre dispositivos, ya que
los elementos del sistema disponen no sólo de capacidad de computación, sino
también de comunicación, tanto con el usuario como con los demás elementos
a su alrededor mediante WiFi, Bluetooth, GPRS/UMTS, UWB, RFID, etc.
Disponibilidad de memoria, que puede ser usada para almacenar información
y así mejorar la interacción con el resto de dispositivos. Sensibilidad al contexto, siendo capaces de adaptarse a diferentes situaciones, como su situación
geográfica, las preferencias de los usuarios, los dispositivos que se encuentran
en el entorno, etc., actuando en base a este contexto. Por último, son capaces de reaccionar ante ciertos estímulos o eventos, que pueden percibir en su
entorno a través de sensores o mediante interacción con otros dispositivos.
La Computación Ubicua, incorpora cuatro nuevos conceptos:
• Uso eficaz de espacios “perspicaces”: Se basa, en la detección
del estado de un individuo y de sus necesidades, deducidas de dicho
estado, ya sea en la oficina, sala de reuniones, clase, domicilio, coche,
etc. El espacio perspicaz surge cuando varios dispositivos inteligentes
coinciden en el mismo espacio físico e interactúan colaborativamente
para dar soporte a los individuos que se encuentren en él. La domótica,
computación ubicua en el domicilio, es la aplicación más popular.
• Invisibilidad: Actualmente, se está lejos de la propiedad expuesta por
Weiser para los sistemas ubicuos, la completa desaparición de la tecnología de la consciencia del usuario. Una buena aproximación es tener
presente, en el diseño de estos sistemas, la idea de mínima distracción
del usuario. La invisibilidad va a requerir del cambio drástico en el tipo
de interfaces que nos comunican con los computadores. Reconocimiento
de voz y de gestos, comprensión del lenguaje natural y del texto manuscrito, en la dirección hombre máquina y en el sentido contrario, síntesis
1.3. COMPUTACIÓN UBICUA
11
de lenguaje hablado y escrito y de representaciones gráficas.
• Escalabilidad local: El concepto de localidad de servicios en computación ubicua es fundamental frente a la universalidad de servicios de
Internet. Los usuarios disponen de capacidades asociadas al contexto en
el que se encuentran, careciendo de sentido, por ejemplo, que las aplicaciones domóticas situadas en el domicilio particular tengan que estar
escrutando las necesidades del usuario que se encuentra trabajando en
ese momento en la oficina. Al igual que la mayoría de las interacciones
en la naturaleza, la proporcionada por estos sistemas, decrece con la
distancia al usuario.
• Ocultación de los desniveles de acondicionamiento: Dependiendo
de la infraestructura y del desarrollo tecnológico disponible, la distribución de los servicios ofrecidos puede ser muy poco uniforme, en esta
situación el principio de invisibilidad puede no cumplirse ya que el usuario detectaría desagradables transiciones. Este requisito es hoy día el
más alejado respecto de la situación ideal, los sistemas que incorporan
computación ubicua están aislados, sin continuidad entre unos y otros.
En la figura 1.3 de la página 12, se describe una arquitectura genérica de
un dispositivo de computación ubicua, que permite interactuar con el usuario
a través de su interfaz (tanto de entrada como de salida), obtener el contexto
e información relevante del mundo real para dar el soporte adecuado a sus
necesidades y modificar el entorno en base a la información capturada por los
sensores y las acciones realizadas a través de los actuadores, y mediante su
interfaz de red puede coordinarse con otros elementos del sistema.
Se puede ir viendo cómo el usuario toma un rol principal en el sistema, por
lo que tiene sentido adoptar una perspectiva de diseño centrada en el usuario,
a la hora de idear e implementar los posibles servicios y aplicaciones.
1.3.3
Diseño centrado en el usuario
La arquitectura y diseño de los sistemas ubicuos giran entorno a las características de los usuarios. Además, a la hora de diseñar el sistema, se debe tener
presente que ciertas capacidades son necesarias:
• Identificar al usuario: En este sentido se puede pensar en dos estrategias posibles, la utilización de señales de identidad (tags) que porta el
12
CAPÍTULO 1. INTRODUCCIÓN
Figura 1.3: Arquitectura Genérica de un Dispositivo de Computación Ubicua
propio usuario o el uso de sensores que le reconocen por alguna característica o conjunto de ellas (biometría).
• Reconocer el estado del usuario: El sistema debe adquirir información del estado del usuario con el fin de tomar decisiones acertadas, en
este sentido la localización tanto espacial como temporal es considerada
como parte del estado del individuo.
• Inferir sus necesidades: Una vez conocido el estado del usuario, pueden determinarse cuáles van a ser sus necesidades, a través de sus hábitos
de comportamiento, basándose en situaciones similares que le ocurrieron
a él o a otros usuarios en la misma circunstancia o similar.
• Actuar proactivamente: El sistema tendrá iniciativa, realizará operaciones sobre el mundo físico que cambiarán el estado y las necesidades
de los usuarios. Esta capacidad requiere ser diseñada con especial cuidado, ya que no todos los usuarios están dispuestos a que un sistema tome
decisiones de forma transparente a ellos. Esta cualidad tendrá que estar
parametrizada y será ajustada por el usuario.
De forma general, el diseño centrado en el usuario es una filosofía y proceso
de diseño en el que las necesidades, los deseos y las limitaciones del usuario
1.3. COMPUTACIÓN UBICUA
13
final del sistema toman una atención y relevancia considerable en cada nivel del
proceso de diseño. El diseño centrado en el usuario puede ser caracterizado
como un problema de resolución en múltiples niveles, que no sólo requiere
diseñadores para que analicen y prevean cómo los usuarios se sienten más a
gusto en el uso de una interfaz o una acción, sino también para probar la validez
de sus hipótesis teniendo en cuenta las conductas del usuario con pruebas en
la vida real con usuarios actuales. Tales pruebas son tan necesarias como
difíciles para los diseñadores de un sistema, de comprender en forma intuitiva
lo que un usuario primerizo experimenta de sus diseños, y cómo es la curva de
aprehensión de cada usuario.
Figura 1.4: Fases del Diseño Orientado al Usuario
Las tecnologías en ocasiones son demasiado complicadas para la audiencia objetivo, por lo que el diseño de la interacción con los usuarios pretende
minimizar la curva de aprendizaje e incrementar la precisión y eficiencia de
una tarea sin disminuir su utilidad. Así, se pretende disminuir la frustración
e incrementar la productividad y satisfacción del usuario.
El proceso de diseño centrado en el usuario se compone de varias fases
(ver figura 1.4 de la página 13), ideadas para involucrar al máximo al propio
14
CAPÍTULO 1. INTRODUCCIÓN
usuario, sus necesidades, características y objetivos que espera del sistema
final. Así, el proceso se estructura en seis pasos principales, los cuales pueden
ser iterados diversas veces en base al feedback dado por el usuario a lo largo
del desarrollo. A continuación se detallan los mismos:
• Investigación de diseño: En base a ciertas técnicas (observación,
entrevistas, cuestionarios, etc.) los diseñadores deben investigar sobre
los usuarios y su entorno, para aprender más sobre ellos y así ser capaces
de diseñar para ellos.
• Análisis de la investigación y generación del concepto: En base
a la información obtenida de los usuarios, las posibilidades tecnológicas
y las oportunidades de negocio, los diseñadores crean, idean y realizan
esbozos de nuevo software, servicios o sistemas. Este proceso puede involucrar varias fases de brainstorming, discusiones y refinamiento. Para
extraer los requisitos de los usuarios, los diseñadores pueden hacer uso de
perfiles de usuarios existentes; a partir de los requisitos se pueden crear
los escenarios de aplicación, y un resumen de alto nivel de los objetivos
del desarrollo.
• Diseño alternativo y evaluación: Una vez definido el problema a resolver, los diseñadores son capaces de desarrollar soluciones alternativas
acompañadas de prototipos básicos, que apoyen los conceptos e ideas
propuestos. Estas soluciones son evaluadas y a veces fusionadas, dando
lugar a un diseño que cubra el mayor número de requisitos posibles.
• Prototipado y test de usabilidad: Los diseñadores de interacción
usan una gran variedad de técnicas de prototipado para probar aspectos
de ideas de diseño. Éstas pueden ser divididas en: las que se centran en
probar el rol de un artefacto, las que se centran en el look and feel, y las
que prueban la implementación.
• Implementación: Los diseñadores de la interfaz tienen que estar involucrados en el desarrollo del producto, para confirmar que el diseño se
está implementando correctamente. En ocasiones, se necesitan realizar
cambios durante el proceso de creación, y por lo tanto los diseñadores
deben actuar sobre el diseño de la interfaz.
• Pruebas del sistema: Una vez que el sistema está terminado, se deben
definir y realizar otra ronda de tests, tanto para controlar la usabilidad
como los posibles errores.
1.4. LA LEY DE MOORE Y LA VISIÓN DE WEISER
15
En base al proceso definido para la creación y desarrollo del sistema en
torno al usuario, se tiene la capacidad de lograr servicios o aplicaciones que
cubran las necesidades y requisitos marcados, ofreciendo muy diversas funcionalidades a los usuarios gracias a los dispositivos inteligentes distribuidos y
camuflados en el entorno.
1.4
La Ley de Moore y la Visión de Weiser
Los constantes avances en microelectrónica se han convertido en algo común:
la ley de Moore, formulada en los años sesenta por Gordon Moore, afirma que
la capacidad de computación disponible en un microchip se multiplica por
dos aproximadamente cada 18 meses y, de hecho, esto ha resultado ser un
pronóstico extraordinariamente exacto del desarrollo del chip desde entonces.
Se puede observar también un crecimiento exponencial comparable en otras
áreas de la técnica, como por ejemplo en la capacidad de almacenamiento y el
ancho de banda para la comunicación. Visto de otra forma, los precios para la
funcionalidad microelectrónica con la misma capacidad de computación están
bajando gradualmente de forma radical.
Esta tendencia que no cesa producirá una profusión de computadores muy
pequeños en un futuro no demasiado lejano, lo que anuncia un cambio de paradigma en las aplicaciones informáticas: se montarán procesadores, dispositivos
de memoria y sensores para formar una amplia gama de “aparatos electrónicos
de información” baratos, que estarán conectados sin cables a Internet y serán
construidos de forma personalizada para realizar tareas específicas.
Estos componentes microelectrónicos se podrán incrustar además en casi
cualquier tipo de objeto cotidiano, lo que le añadirá “sensibilidad” (smartness),
por ejemplo modificando su comportamiento dependiendo del contexto en que
se encuentre del objeto. Al final, el procesamiento de la información y las
capacidades de comunicación quedarán integrados en objetos que, por lo menos
a primera vista, no parecerán de ningún modo aparatos eléctricos, de esta
forma las capacidades de la computación se volverán ubicuas.
El término “computación ubicua” (ubiquitous computing), que denota esta
visión, fue acuñado hace más de diez años por Mark Weiser , un investigador
del Palo Alto Research Center de XEROX. Weiser ve la tecnología solamente
como un medio para un fin y como algo que debería quedar en segundo plano
16
CAPÍTULO 1. INTRODUCCIÓN
para permitir al usuario concentrarse completamente en la tarea que está realizando. En este sentido, considerar el computador personal como herramienta
universal para la tecnología de la información sería un enfoque equivocado, ya
que su complejidad absorbería demasiado la atención del usuario.
Según Weiser , el computador como dispositivo dedicado debería desaparecer, mientras que al mismo tiempo debería poner a disposición de todo lo
que nos rodea sus capacidades de procesamiento de la información.
Figura 1.5: MarkWeiser (1952-1999), el Visionario de la Computación Ubicua
Weiser ve el término “computación ubicua” en un sentido más académico e
idealista como una visión de tecnología discreta, centrada en la persona, mientras que la industria ha acuñado por eso el término “computación pervasiva”,
o ampliamente difundida “pervasive computing” con un enfoque ligeramente
diferente: Aunque su visión siga siendo todavía integrar el procesamiento de
la información en objetos cotidianos de forma casi invisible, su objetivo principal es utilizar tales objetos en un futuro próximo en el ámbito del comercio
electrónico y para técnicas de negocios basados en la Web.
Esta variante pragmática de computación ubicua está empezando ya a
tomar forma: El presidente de IBM Lou Gerstner describía una vez su visión
de la “era post-PC” como “mil millones de personas interactuando con un
millón de negocios electrónicos a través de un billón de dispositivos inteligentes
interconectados”.
1.5. SIC
1.5
17
Sociedad de la Información y el Conocimiento
(SIC)
El término “Sociedad de la Información” ha sido incorporado, con relativa insistencia, en los años recientes, a la literatura política, académica y mediática
contemporáneas. Periodistas, políticos, cibernautas, académicos e investigadores suelen evocar tan ambiguo concepto para referirse al tipo de sociedades
deseables a las cuales habrá de conducirnos la “globalización”. [6]
La Cumbre Mundial sobre la Sociedad de la Información (CMSI) [7], organizada por el sistema de la ONU bajo el auspicio de Kofi Annan, la Unión
Internacional de Telecomunicaciones (UIT), y otras agencias de la ONU interesadas en la materia, planea adoptar una declaración que incorpore un
conjunto de principios y reglas de conducta destinados a crear a nivel mundial
una Sociedad de la Información más inclusiva y equilibrada; un plan de acción
y una declaración de principios que formulen propuestas operativas y medidas
concretas para que todos los actores se beneficien más equitativamente de las
oportunidades que concederá la Sociedad de la Información en el futuro.
Las organizaciones cívicas internacionales que más han participado a nivel
mundial en la discusión y construcción del futuro que debe adoptar la sociedad
de la información a través de la CMSI, poseen una visión diferente a la manejada por los organismos económicos y políticos internacionales tradicionales
que han creado esencialmente un proyecto de expansión de las empresas como
negocios eficientes y no en el mejoramiento generalizado de las condiciones de
vida de los seres humanos. Por ello, la sociedad civil ha proclamado la otra
versión de lo que debe ser la Sociedad de la Información y de la Comunicación
y fundamenta su concepción, en las siguientes bases: concepción de la sociedad
de la información, principios guías.
1.5.1
La Visión Sobre las Sociedades de la Información y de
la Comunicación
La sociedad civil entiende a las sociedades de la información y de la comunicación como realidades basadas en los derechos humanos y en el desarrollo
humano duradero. Los sucesos que definen las sociedades de la información y
de la comunicación deben basarse en principios de justicia económica, política
y social y deben perseguir objetivos de desarrollo humano duradero, además
del apoyo a la democracia, la participación, el fortalecimiento y la igualdad de
18
CAPÍTULO 1. INTRODUCCIÓN
géneros.
1.5.2
Principios Guía
Para alcanzar los objetivos anteriores las estrategias de desarrollo de sociedades de la información y de la comunicación deberán estar guiadas por los
siguientes principios que respondan a la visión expuesta:
• Preponderancia de los derechos humanos y del desarrollo humano duradero.
• El derecho a la comunicación.
• Acceso a la información y a los medios de comunicación.
• Fomentar la diversidad cultural y lingüística.
• Adoptar una perspectiva democrática para las sociedades de información
y comunicación.
1.5.3
Hacia las sociedades de información y comunicación
En la CMSI se abordarán cuestiones tales como las barreras que encuentran
la ciudadanía y las naciones en el acceso a las sociedades de la información.
La CMSI reconoce, específica y abiertamente, un conjunto de diversos tipos
de barreras y no sólo un concepto monolítico de “brecha digital”. Se hará gran
hincapié en tratar las barreras que encuentran los países menos desarrollados
(LDC) y se otorgará especial atención a los pueblos indígenas que tienen un
estatus socioeconómico bajo en la mayoría de los países de residencia, incluso
en países desarrollados. Otros temas a tratar aquí incluirían: barreras educativas, culturales, económicas y sociales; barreras sociales y políticas; relaciones
y roles de género; requisitos para lograr un acceso universal y equitativo; la
información en tanto que bien público, con especial consideración acerca de la
propiedad intelectual y cultural; libertad de expresión y de medios; apoyo a
la diversidad lingüística y cultural con el fin de eliminar las barreras y roles
de los gobiernos, la sociedad civil y el sector privado en la eliminación de los
obstáculos que impiden la creación de sociedades de información y comunicación.
1.6. TICS
19
La Cumbre deberá examinar algunos de los temas regulatorios como la
libertad de expresión; la protección de la información; el acceso a la misma;
la privacidad y seguridad de las redes; la privacidad en el lugar de trabajo; la
protección de la comunidad de consumidores, especialmente en lo que respecta
al correo no deseado y a la creación de categorías de población electrónicas.
1.6
Tecnologías de la Información y la Comunicación
Por Tecnologías de la Información y de la Comunicación (TICs) se entiende un
concepto difuso empleado para designar lo relativo a la informática conectada
a Internet y, especialmente, el aspecto social de éstos. TIC’S : Se denomina
así a las Tecnologías de la Información y de la Comunicación. También se
las suele denominar Ntic’s (por Nuevas Tecnologías de la Información y de la
Comunicación).
Parece pues necesario conectar el concepto a un conjunto de estructuras
materiales, localizar el origen de la difusión de estas estructuras en el tiempo
y en el espacio geográfico y delimitar el fenómeno del espacio virtual que estas
estructuras hacen posible. Dentro de ésta definición general encontramos los
siguientes temas principales:
• Sistemas de comunicación.
• Informática.
• Herramientas ofimáticas que contribuyen a la comunicación.
Las TIC agrupan un conjunto de sistemas necesarios para administrar la
información, y especialmente las computadoras y programas necesarios para
convertirla, almacenarla, administrarla, transmitirla y encontrarla. Los primeros pasos hacia una “Sociedad de la Información” se remontan a la invención
del telégrafo eléctrico, pasando posteriormente por el teléfono fijo, la radiotelefonía y, por último, la televisión. Internet, la telecomunicación móvil y
el GPS pueden considerarse como nuevas tecnologías de la información y la
comunicación.
La revolución tecnológica que vive la humanidad actualmente es debida
en buena parte a los avances significativos en las tecnologías de la informa-
20
CAPÍTULO 1. INTRODUCCIÓN
ción y la comunicación. Los grandes cambios que caracterizan esencialmente
a esta nueva sociedad son: la generalización del uso de las tecnologías, las
redes de comunicación, el rápido desenvolvimiento tecnológico y científico y la
globalización de la información.
1.6.1
Aspecto social de las TIC
La introducción de estas tecnologías consigue un cambio de nuestra sociedad.
Se habla de sociedad de la información o sociedad del conocimiento. Se trata
de un cambio en profundidad de la propia sociedad.
Las nuevas tecnologías de la información y la comunicación designan a la
vez un conjunto de innovaciones tecnológicas pero también las herramientas
que permiten una redefinición radical del funcionamiento de la sociedad. La
puesta en práctica de las TIC afecta a numerosos ámbitos de las ciencias
humanas, la teoría de las organizaciones o la gestión.
La expansión de las tecnologías de la información y la comunicación basadas en la microelectrónica, la informática, la robótica y las redes de comunicaciones se está produciendo a gran velocidad en todos los ámbitos socioeconómicos y de las actividades humanas configurando la nombrada “Sociedad
de la información”.
1.7
Tecnología en el Restaurant
Desde la aparición de las computadoras éstas han sido usadas en los sistemas de
información de las empresas para facilitar el trabajo de control y gestión gracias a la capacidad de recopilar y procesar gran cantidad de datos. En entornos
fuertemente competitivos las empresas han comprendido que las inversiones
en tecnologías de la información pueden incrementar de forma significativa la
competitividad de la empresa.
Aunque las necesidades tecnológicas de los restaurantes parezcan inferiores
en comparación a otros sectores, muchos estudios hablan del uso de las TIC
en estos, que a causa de la globalización y de una competencia creciente,
estos restaurantes cada vez se ven más obligados a realizar inversiones en este
campo. Hoy en día parece impensable que un restaurant no tenga página
web y en el caso ideal su sistema de información debería estar preparado para
1.7. TECNOLOGÍA EN EL RESTAURANT
21
afrontar retos como el “E-Commerce” o poder ofrecer servicios como Wi-Fi a
sus clientes.
1.7.1
Beneficios e inconvenientes del uso de las tecnologías de
la información en el sector gastronómico.
Las TIC se han convertido en una fuente de ventajas competitivas y en un
arma estratégica, especialmente en sectores donde la información juega un papel fundamental en la descripción, promoción y distribución de sus productos.
Pueden ser requisitos para formar alianzas estratégicas, desarrollar canales de
distribución innovadores y nuevas vías de comunicación con proveedore clientes
Existe una relación directa entre la mejora del funcionamiento de los procesos internos de la empresa y la mejora del servicio ofrecido a los clientes. Las
TIC deben mejorar el funcionamiento de estos procesos creando información
relevante e incrementando la comunicación entre los diferentes departamentos
o unidades funcionales, evitando las ineficiencias.
Figura 1.6: Beneficios Obtenidos de la Introducción de Tecnología.
22
CAPÍTULO 1. INTRODUCCIÓN
En la figura 1.6 de la página 21 se detallan los beneficios obtenidos por la
aplicación de las tecnologías de la información y las comunicaciones. En el
esquema vemos como todos los beneficios se centran en el cliente.
Para mejorar el grado de satisfacción del cliente es necesaria la introducción
de técnicas como “data warehouse”, “data mining” o “Customer Relationship
Management”. Estas técnicas permiten recopilar y consolidar datos del cliente
de todos los puntos de contacto con él, antes, durante y después de su estancia.
Esto permite mantener un historial completo y ofrecerle lo que quiere cuando lo
quiere. De hecho algunos directivos piensan que realmente se consigue mejorar
la satisfacción del cliente con el uso de las TIC.
La incorporación de nuevas tecnologías no está sin embargo exenta de riesgos. Según estudios un 90% de los proyectos de TIC no alcanzan los objetivos,
un 80% están por encima del presupuesto o tiempo de implementación esperados, un 40% fallan completamente o son abandonados, en menos del 40%
el personal está preparado para explotar satisfactoriamente el sistema y solo
entre un 10% y un 20% obtiene exitosamente todos los objetivos.
El incremento de la productividad cuando se aplican innovaciones tecnológicas ha sido discutido. Algunos estudios enuncian que mediante la aplicación de tecnologías de la información se obtienen mejoras en el funcionamiento
de la empresa, pero otros enuncian que no hay relación entre productividad
y la aplicación de estas tecnologías o que incluso hay un efecto negativo en
su aplicación. Mientras que en otros se llega a la conclusión que para obtener
beneficio es necesario aprovechar las capacidades de integración, información
y transformación que tienen estas tecnologías, así como hacer un uso más
estratégico.
El cambio del sistema de información en una empresa es un momento
crítico. La empresa debe dejar de trabajar con un sistema que ya es conocido
por los usuarios y que cumple una serie de requerimientos mínimos para dar
soporte a los procesos críticos de la empresa, para pasar a trabajar con un
nuevo sistema cuyo rendimiento no es conocido a priori. Para evitar riesgos se
puede optar por un periodo de convivencia de los dos sistemas, lo que provoca
duplicar el trabajo, o bien hacer la transición de forma acumulativa cambiando
no todo el sistema a la vez sino realizar el cambio por departamentos o unidades
funcionales.
Durante el proceso de cambio es necesario vencer las posibles resistencias
al cambio que se puedan presentar. Para ello puede ser útil la presencia de
1.7. TECNOLOGÍA EN EL RESTAURANT
23
una persona de cierto prestigio en la empresa que sea capaz de promocionar el
uso del nuevo sistema y convertir las posibles resistencias en cooperación por
parte del personal.
Un punto clave es la formación del personal antes, durante y después de la
puesta en funcionamiento del nuevo sistema. Especialmente crítico es en un
sector como el gastronómico donde muchos de los usuarios que van a utilizar
el sistema tienen un perfil de formación bajo.
Capítulo 2
Tecnología Móvil
2.1
2.1.1
Telefonía Móvil
Celulares: Concepto General
Se define al teléfono móvil o celular como un dispositivo electrónico de comunicación, normalmente de diseño reducido y sugerente, basado en la tecnología
de ondas de radio, que tiene la misma funcionalidad que cualquier teléfono de
línea fija. Su rasgo característico principal es que se trata de un dispositivo
portable e inalámbrico, es decir, que la realización de llamadas no es dependiente de ningún terminal fijo y que no requiere de ningún tipo de cableado
para llevar a cabo la conexión a la red telefónica. [8]
Además de ser capaz de realizar llamadas como cualquier otro teléfono
convencional, un celular moderno suele incorporar un conjunto de funciones
adicionales que aumentan la potencialidad de utilización de estos dispositivos.
Es más, su desarrollo y exigencia ha llegado a tal punto, que se puede hablar
incluso de términos tales como memoria RAM. Y considerando que estos pueden crear y reproducir información de todo tipo (audio, video, texto, etc.),
hace de estos un complemento perfecto tanto para el hombre común como
para el de negocios.
25
26
2.1.2
CAPÍTULO 2. TECNOLOGÍA MÓVIL
Un Poco de Historia
La telefonía móvil utiliza ondas de radio para poder ejecutar todas y cada
una de las operaciones de comunicación, ya sea llamar, mandar un mensaje
de texto, etc., y esto es producto de lo que sucedió hace algunas décadas. [9]
La comunicación inalámbrica tiene sus raíces en la invención del radio por
Nikola Tesla en los años 1880, aunque formalmente presentado en 1894 por
un joven italiano llamado Guglielmo Marconi.
El teléfono móvil se remonta a los inicios de la Segunda Guerra Mundial,
donde ya se veía que era necesaria la comunicación a distancia, es por eso que
la compañía Motorola creó un equipo llamado Handie Talkie H12-16 el cual
se puede apreciar en la figura 2.1 de la página 26, el cual permitía el contacto
con las tropas vía ondas de radio que en ese tiempo no superaban más de 600
kHz.
Figura 2.1: Handie Talkie12-16
Fue sólo cuestión de tiempo para que las dos tecnologías de Tesla y Marconi
se unieran y dieran a luz a la comunicación mediante radio-teléfonos. Martin
Cooper , figura 2.2 de la página 27, pionero y considerado como el padre de la
telefonía celular , fabricó el primer radio teléfono entre 1970 y 1973, en Estados
Unidos.
“La gente desea hablar con la gente - no en una casa, o en una oficina, o
en un coche. Dales la opción, y la gente exigirá la libertad para comunicarse
dondequiera que este, desencadenándose del infame alambre de cobre. Es esa
libertad que intentamos demostrar vividamente en 1973” dijo Martin Cooper.
[10]
2.1. TELEFONÍA MÓVIL
27
Figura 2.2: Martin Cooper mostrando el primer teléfono celular. ArrayComm
En 1979 aparecieron los primeros sistemas a la venta en Tokio (Japón),
fabricados por la Compañía NTT. Los países europeos no se quedaron atrás y
en 1981 se introdujo en Escandinavia un sistema similar a AMPS (Advanced
Mobile Phone System). Y si bien Europa y Asia dieron los primeros pasos, en
Estados Unidos, gracias a que la entidad reguladora de ese país adoptó reglas
para la creación de un servicio comercial de telefonía celular, en 1983 se puso
en operación el primer sistema comercial en la ciudad de Chicago.
Este fue el inicio de una de las tecnologías que más avances tiene, aunque
continúa en la búsqueda de novedades y mejoras.
Hace una década aproximadamente los teléfonos celulares se caracterizaban
sólo por llamar, pero ha sido tanta la evolución que ya se puede hablar de
equipos Multimedia que pueden llamar y ejecutar aplicaciones, jugar juegos
3D, ver videos, ver televisión y más. Obviamente muchas marcas de placas
madres para PC o fabricantes de hardware en general se hacen presentes en
los teléfono móviles como por ejemplo: ASUS e INTEL que construyen las
placas matrices de lo celulares o ayudan con el acelerador gráfico o el sistema
de video. En fin, se debe tener conciencia y estar preparados para lo que se
viene más adelante y pensar que el teléfono celular ya no es tan sólo para
hablar, y de esta forma poder aprovechar las situaciones de negocios que estos
nos brindan.
28
CAPÍTULO 2. TECNOLOGÍA MÓVIL
2.1.3
Generaciones del Celular
0-G: Generación 0
Tristemente, siempre se dice que las guerras agudizan la inventiva y el ingenio
del hombre, no solo a nivel armamentístico, sino a otros muchos niveles tales
como el de las comunicaciones.
Por supuesto, la Segunda Guerra Mundial no fue una excepción. La compañía Motorola lanzó el Handie Talkie H12-16, el cual permitía la comunicación a distancia entre las tropas, un dispositivo basado en la transmisión
mediante ondas de radio que, a pesar de trabajar por aquel entonces con un
espectro de 550 MHz aproximadamente, supuso una revolución de enormes
proporciones.
Figura 2.3: Publicidad del Motorola Handie Talkie H12-16
Esta tecnología fue aprovechada a partir de los años 50 y 60 para crear
una gran variedad de aparatos de radio y de comunicación a distancia (los
tradicionales Walkie-Talkies), utilizados sobretodo por servicios públicos tales
como taxis, ambulancias o bomberos.
Aunque realmente estos dispositivos no pueden ser considerados como teléfonos móviles, la implementación de los primeros supuso el comienzo de la
evolución hacia los dispositivos que conocemos en la actualidad.
Los primeros estándares más utilizados, en los que se fundamentó esta
“generación 0”, fueron:
• Estándar PTT (Push To Talk): Pulsar para Hablar.
• Estándar IMTS (Improved Mobile Telefone System): el Sistema de Telefonía Móvil Mejorado.
2.1. TELEFONÍA MÓVIL
29
1-G: Móviles de Primera Generación
Surgidos a partir de 1973 y con un tamaño y peso inmanejable, los móviles de
primera generación funcionaban de manera analógica, es decir que la transmisión y recepción de datos se apoyaba sobre un conjunto de ondas de radio que
cambiaban de modo continuo.
El hecho de que fueran analógicos traía consigo una serie de inconvenientes,
tales como que solo podían ser utilizados para la transmisión de voz (el uso de
mensajería instantánea era algo solo visible en un futuro “muy lejano”) o su
baja seguridad, la cual hacía posible a una persona escuchar llamadas ajenas
con un simple sintonizador de radio o, incluso hacer uso de las frecuencias
cargando el importe de las llamadas a otras personas.
A pesar de todo, esta fue la primera generación considerada realmente
como de teléfonos móviles.
Estándares más utilizados:
• NMT: Nordic Mobile Telephone
• AMPS: Advaced Mobile Phone System
2-G: Segunda Generación
Al contrario de lo que pasa en otras generaciones, la denominada “segunda
generación” no es un estándar concreto, sino que marca el paso de la telefonía
analógica a la digital, que permitió, mediante la introducción de una serie de
protocolos, la mejora del manejo de llamadas, más enlaces simultáneos en el
mismo ancho de banda y la integración de otros servicios adicionales al de la
voz, de entre los que destaca el Servicio de Mensajes Cortos (Short Message
Service).
Estos protocolos fueron implementados por diversas compañías, siendo este
hecho el origen de uno de los principales problemas de esta generación la
incompatibilidad entre protocolos, debido a que el radio de utilización del
teléfono quedaba limitado al área en el que su compañía le diera soporte.
Estándares más utilizados:
30
CAPÍTULO 2. TECNOLOGÍA MÓVIL
Figura 2.4: La evolución de los teléfonos celulares fue más allá de las características técnicas. Se puede apreciar cómo en tamaño y peso la evolución fue
considerable.
• GSM: Global System for Mobile Communications - Sistema Global para
Comunicaciones Móviles.
• CDMA: Code Division Multiple Access - Acceso Múltiple por División
de Código.
• GPRS: General Packet Radio Service - Servicio General de Radio por
Paquetes.
3-G: Tercera Generación
El año 2001 fue un año revolucionario en el ámbito de la telefonía móvil ya
que supuso la aparición de los primeros celulares que incorporaban pantalla
LCD a color, hecho que abría un inmenso abanico de posibilidades en cuanto
a adaptación de nuevas funciones se refiere.
Así, pronto el usuario pudo asistir al nacimiento de dispositivos que se
creían como mínimo futuristas tales como móviles con cámara fotográfica di-
2.1. TELEFONÍA MÓVIL
31
gital, posibilidad de grabar videos y mandarlos con un sistema de mensajería
instantánea evolucionado, juegos 3d, sonido Mp3 o poder mantener conversaciones por videoconferencia gracias a una tasa de transferencia de datos
más que aceptable y a un soporte para Internet correctamente implementado
(correo electrónico, descargas, etc.).
Todo este conjunto de nuevos servicios integrados en el terminal junto con
un nuevo estándar dieron lugar a la denominada hoy en día “tercera generación
de móviles” o móviles 3G.
Estándares más utilizados:
• UMTS: Universal Mobile Telecommunications System - Servicios Universales de Comunicaciones Móviles.
Concepto de la Red de Telefonía Celular
La red se constituye básicamente en torno a dos tipos de elementos:
• Estaciones base: son las encargadas de transmitir y recibir la señal.
• Centrales de conmutación: son las que permiten la conexión entre
dos terminales concretos.
La adecuada combinación de estos dos elementos posibilita la comunicación
tanto entre teléfonos móviles como entre un celular y un teléfono fijo. Se ve
entonces que la telefonía móvil, es algo más que el teléfono móvil.
Funcionamiento de la Red
A nivel general, su funcionamiento es bastante sencillo. Las estaciones base se
disponen creando una gran malla con forma de célula o celda (cell; de ahí que
se denomine a este tipo de teléfonos, teléfonos celulares), conectando mediante
ondas de radio dos terminales con los controladores de dichas estaciones base.
Esta disposición en forma de panal no es meramente casual, sino que responde a un esquema que permite la reutilización de un determinado conjunto
32
CAPÍTULO 2. TECNOLOGÍA MÓVIL
de frecuencias asignadas en distintas celdas, siempre que estas no sean adyacentes, aumentando el rendimiento de la red por un lado (el número de
frecuencias de que se dispone es limitado), y economizando por otro.
Figura 2.5: Celdas
En la figura 2.6 de la página 33, se puede apreciar detalladamente la arquitectura de un sistema celular móvil según el estándar GSM, uno de los más
utilizados hoy en día.
2.2
La Computadora Portátil
A lo largo de los años, las computadoras personales portátiles han sufrido
algunos cambios que las hacen ser como lo son hoy día, aunque no se parecen
en nada a sus principios.
Resulta muy difícil establecer un orden cronológico de la historia y secuencias de la computadora portátil y su evolución porque nadie puede asegurar
quién fue el primero en desarrollar el primer ordenador móvil.
Algunos afirman que el pionero fue Alan Kay, del centro de investigación
de XeroX en Palo Alto en 1970, quien fue el primero que llego con la idea de
un ordenador que se pudiera llevar encima. Kay visionó un dispositivo portátil
parecido a los que usamos hoy en día, algo pequeño y ligero que cualquiera se
pudiera permitir.
2.2. LA COMPUTADORA PORTÁTIL
33
Figura 2.6: Arquitectura GSM
Otros aseguran que el portátil fue construido en 1979 por William Moggridge el cual trabajaba para la corporación Grid Systems. Tenía 340 kilobytes,
una pantalla plegable y estaba hecho de metal (magnesio). Era bastante diferente a lo que hoy conocemos pero era un comienzo.
Aunque se discute su veracidad, el siguiente ordenador portátil que existió
fue creado en 1983 por “Gavilan Computers”. Este portátil tenía de 64 a 128
megabytes de memoria, un ratón e incluso una impresora portátil. Su peso,
sin la impresora, era algo mayor que los actuales.
Gavilan fracaso tiempo después por problemas de incompatibilidad con
otros ordenadores. El portátil de Gavilan usaba su propio sistema operativo.
“Apple Computers” introdujo el modelo “Apple IIc” en 1984, el cual se
puede apreciar en la figura 2.7 de la página 34, pero no era mucho mejor que
lo que había producido Gavilan un año antes. Un punto favorable era que
incluía la función opcional de LCD lo cual impactó en posteriores equipos.
Finalmente en 1986 un portátil real fue creado por IBM el cual lo llamó
PC de IBM Convertible, el cual se puede apreciar en la figura 2.8 de la página
35. Se califica como “real” porque al contrario de otros, a este portátil no
se le tenía que hacer una configuración inicial en cada sitio. También poseía
dos disqueteras de 3.5 pulgadas y espacio para un módem interno. En este
34
CAPÍTULO 2. TECNOLOGÍA MÓVIL
“convertible” podíamos encontrar una pantalla LCD y algunas aplicaciones
básicas que los usuarios podían usar para crear documentos de texto, y tomar
notas.
El precio del portátil de IBM rondaba los 3500 dólares de aquella época. Hoy en día pagar ese precio por un portátil moderno está fuera de toda
consideración, afortunadamente.
Desde los años ochenta, muchos fabricantes están produciendo y desarrollando nuevos equipos cada vez más rápidos y potentes dejando en el olvido
a sus predecesores. Y según avanza la tecnología, los precios se vuelven más
competitivos hasta el punto de que cualquier persona puede disponer de una
computadora portátil.
Figura 2.7: Modelo Apple IIc de Apple Computers - 1984
2.3
PDAs
PDA, del inglés Personal Digital Assistant, Ayudante Personal Digital, es
una computadora de mano originalmente diseñada como agenda electrónica
(calendario, lista de contactos, bloc de notas y recordatorios) con un sistema
de reconocimiento de escritura. Hoy día se puede usar como una computadora
doméstica (ver películas, crear documentos, juegos, correo electrónico, navegar
por Internet, escuchar música, etc.).
2.3. PDAS
35
Figura 2.8: PC Convertible de IBM - 1986
2.3.1
Historia de las PDAs
En 1989, el Atari Portfolio, aunque técnicamente clasificado como palmtop, fue
una muestra temprana de algunos de los más modernos dispositivos electrónicos. Le siguieron otros dispositivos como los Psion Organizer, el Sharp Wizard
o la Amstrad Penpad que fueron sentando la base de las funcionalidades de
las PDAs.
La primera mención formal del término y concepto de PDA es del 7 de
enero de 1992 por Jhon Sculley al presentar el Apple Newton, en el Consumer
Electronics Show de Las Vegas (EE.UU.). Sin embargo fue un sonoro fracaso
financiero para la compañía Apple, dejando de venderse en 1998. La tecnología
estaba aún poco desarrollada y el reconocimiento de escritura en la versión
original era bastante impreciso, entre otros problemas. Aún así, este aparato
ya contaba con todas las características del PDA moderno: pantalla sensible
al tacto, conexión a una computadora para sincronización, interfaz de usuario
especialmente diseñada para el tipo de máquina, conectividad a redes vía
módem y reconocimiento de escritura.
En 1995 con la aparición de la empresa Palm comenzó una nueva etapa
de crecimiento y desarrollo tecnológico para el mercado de estos dispositivos.
Tal fue el éxito que las PDA son a veces llamadas Palm o Palm Pilot, lo cual
constituye un caso de una marca registrada que se transforma en el nombre
36
CAPÍTULO 2. TECNOLOGÍA MÓVIL
genérico del producto.
La irrupción de Microsoft Windows CE (2000) y Windows Mobile (2003)
en el sector los dotó de mayores capacidades multimedia y conectividad, y
sobre todo incorporó a un público ya acostumbrado al uso de sus programas
y que se los encontraban en versión reducida.
La irrupción de los Smartphones, híbridos entre PDA y teléfono móvil ,
trajeron por un lado nuevos competidores al mercado y por otro incorporaron
al usuario avanzado de móviles al mercado. También supuso la vuelta de un
sistema operativo que había abandonado el mercado de las PDAs y ordenadores de mano en favor de los móviles: el Symbian OS. Las PDAs de hoy en
día traen multitud de comunicaciones inalámbricas como ser Bluetooth, WiFi, IrDA, GPS, que los hace tremendamente atractivos hasta para cosas tan
inverosímiles como su uso para domótica o como navegadores GPS.
2.3.2
Atari Portfolio
El Atari Portfolio, puede verse en la figura 2.9 de la página 37, fue lanzado
por Atari en 1989 siendo este el primer ordenador PC compatible PDA.
Se trataba de un PC XT compatible MS-DOS, construido utilizando un
procesador 80C88 a 4,9152 MHz, y del tamaño aproximado de una cinta de
VHS, estando cerrado.
La versión estándar tenía 128 kB de RAM, con un disco interno RAM
configurable (C:).
Tenía 256 KB ROM con software de aplicaciones preinstaladas, que no
utilizaban la RAM:
• Sistema operativo DIP DOS 2.11, compatible con MS-DOS & PC BIOS.
• Procesador de texto.
• Agenda.
• Hoja de cálculo.
• Calendario.
2.3. PDAS
37
Figura 2.9: Atari Portfolio
Utilizaba un puerto para tarjetas de expansión, que desgraciadamente no
era compatible con PCMCIA.
Esa expansión estaba localizada en la parte derecha del ordenador. Existían módulos de expansión para puerto paralelo, serie e incluso MIDI.
Además disponía de un zócalo para insertar tarjetas de memoria de estado
sólido de 64, 128 y 256 KB a modo de disquetes o de tarjetas Secure Digital.
El Atari Portfolio tenía un panel LCD sin retroiluminación y un altavoz
capaz de emitir tonos de teléfono que usado conjuntamente con la agenda
permitía marcar números de teléfono de manera automática (marcación por
tonos).
Atari no desarrolló el Portfolio sino que lo licenció de la empresa DiP.
El Portfolio aparece en la película Terminator, donde era utilizado por
el protagonista, el joven John Connor, para abrir una puerta con sistema de
seguridad a base de tarjeta electrónica y para robar un cajero automático.
2.3.3
Apple Newton
El Apple Newton, el cual se puede observar en la figura 2.10 de la página 38, o
simplemente Newton, fue una línea temprana de asistentes digitales personales
desarrollada, manufacturada y comercializada por Apple Computer entre 1993
y 1998. [11]
38
CAPÍTULO 2. TECNOLOGÍA MÓVIL
Figura 2.10: Apple Newton
Los Newtons originales estaban basados en el procesador RISC ARM 610 e
incluían reconocimiento de escritura manual. El nombre oficial de Apple para
el dispositivo era MessagePad; el término Newton era el nombre de Apple para
el sistema operativo que usaba, pero el uso popular de la palabra Newton ha
crecido hasta incluir el dispositivo y su software juntos.
Apple también adoptó ese nombre, ya que es una alusión a la manzana de
Isaac Newton y encajan perfecto en sus esfuerzos de marketing en lo relacionado a su marca.
El Newton permitía a los usuarios escribir notas, capturar datos de calendario, crear una libreta de direcciones y se incluyó el software de reconocimiento
de escritura. Los usuarios también podían verificar la hora de varias zonas
horarias, calcular y verificar mensajes.
El Newton falló en su afán de generar un gran cambio en el mercado durante
sus cinco años de vida. Su alto precio, tamaño y corta duración de la batería
contribuyó a que se discontinuase su fabricación en 1998.
Un accesorio especial para el Newton de Apple fue el módem fax, diseñado
específicamente para satisfacer las necesidades de los Newton. El cual utilizaba
2.4. PALM PILOT 5000
39
un cable de serie corto alimentado por dos pilas AA.
2.4
Palm Pilot 5000
La Palm Pilot 5000, la cual se puede ver en la figura 2.11 de la página 40,
fue el segundo modelo de la primera generación de PDAs manufacturadas por
Palm Computing, entonces conocida como US Robotics. [12]
Debutando en Marzo de 1996, la Pilot apareció en un mercado donde tenía
un solo competidor real: el Apple Newton.
El pequeño tamaño de las Pilots, las cuales cabían en el bolsillo de una
camisa, fue definitivamente una ventaja sobre el Apple Newton, que funcionaba
de manera muy similar y tenía casi exactamente la misma pantalla que el
modelo Pilot 5000, esto se puede apreciar en la figura 2.12 de la página 41.
La Pilot funcionaba con un poder de computo similar al Macintosh SE,
alardeando de sus 512 KB de memoria RAM, casi cinco veces más capacidad de
datos que el original modelo Pilot 1000. Más tarde, Palm Computing vendía
una tarjeta de expansión de 1 MB para aumentar la capacidad de memoria
aún más.
Fue también el primer PDA de mano en distinguirse con la capacidad de
sincronizar con Windows 95, 3.1 o PCs de escritorio Macintosh.
El Palm OS 1 fue un sistema operativo que habilitaba la posibilidad de
integración con computadoras de escritorio a un bajo costo, y poco consumo
de energía. Si bien este dispositivo no contaba con puerto de infrarrojos o de
memoria flash, el software de la Pilot podía sincronizar su información con la
mayoría de los PC estándar, permitiendo a los usuarios trabajar y compartir
información de otros programas de aplicación en su computadora a través de
su computadora de mano.
La sincronización de la PDA Pilot 5000 con una PC permitía a los usuarios
introducir texto desde su teclado de tamaño normal y ver las aplicaciones de
la Pilot en la pantalla de sus monitores. Y esto hacía de la Pilot una pequeña
pero muy buena herramienta de negocios.
Para la información de entrada, los consumidores utilizában un lápiz (Stylus) o el popular Graffiti Text Entry Software, creado por Palm, que permitía
la entrada de 30 palabras por minuto con una precisión del 100 por ciento.
40
CAPÍTULO 2. TECNOLOGÍA MÓVIL
Figura 2.11: Palm Pilot 5000
La mayoría de la información se podía acceder con un solo toque, ya que las
aplicaciones contaban con buenos tiempos de respuesta.
La Pilot venía de varios colores con una carcasa plástica, tenía un panel
táctil LCD y 160 x 160 mm de pantalla gráfica y funcionaba con dos pilas
AAA, corría aplicaciones simples en blanco y negro. Contaba con aplicaciones
pre-cargadas como directorio telefónico, lista de tareas, notas, calculadora y
múltiples funciones de búsqueda de aplicaciones, la Pilot también era compatible con otras muchas aplicaciones populares de la epoca, tales como Ascend,
DataSync, Lotus Organizer y Microsoft Schedule +.
2.5
Sistemas operativos y equipos
Hoy en día tenemos los siguientes sistemas operativos y equipos competidores:
• Dispositivos Palm OS, hoy en día mantenido casi en solitario por Palm,
pero que hasta hace poco ha tenido importantes fabricantes como Sony;
• Dispositivos Pocket Pc, con HP como líder de fabricantes acompañado
por otras empresas de informática como Dell o Acer, a quienes se han
2.5. SISTEMAS OPERATIVOS Y EQUIPOS
41
Figura 2.12: Comparativa en tamaños entre la Palm Pilot 5000 y el Apple
Newton
incorporado los fabricantes de Taiwán como High Tech Computer que
van copando el mercado del Smartphone con sus marcas propias, como
Qtek, o fabricando para terceros y, sobre todo, operadores de telefonía
móvil ;
• Research In Motion con sus Blackberry, más propiamente Smartphones que PDAs, pero que han copado una parte importante del mercado
corporativo a la vez que incorporaban prestaciones de PDA.
• Dispositivos Symbian OS presente en las gamas altas de teléfonos móviles
de Nokia y Sony Ericsson;
• Dispositivos Linux liderado por las Sharp Zaurus.
• Y por último, multitud de PDAs de juguete, desde los verdaderos juguetes infantiles a los aparatos baratos fabricados en China, pero que,
aparte del reconocimiento de escritura, incorporan todas las prestaciones básicas de las primeras PDAs, incluyendo cámaras digitales básicas
y comunicaciones con los PCs.
42
CAPÍTULO 2. TECNOLOGÍA MÓVIL
2.6
2.6.1
Estándares
Bluetooth
El nombre procede del rey danés y noruego Harald Blåtand cuya traducción al
inglés sería Harold Bluetooth (‘Diente Azul’ en su traducción al español, aunque en lengua danesa significa ‘de tez oscura’) conocido por buen comunicador
y por unificar las tribus noruegas, suecas y danesas.
De la misma manera, Bluetooth intenta unir diferentes tecnologías como
las de las computadoras, los teléfonos móviles y el resto de periféricos. El
símbolo de Bluetooth es la unión de las runas nórdicas H y B. [13]
Bluetooth es el nombre común de la especificación industrial IEEE 802.15.1,
que define un estándar global de comunicación inalámbrica que posibilita la
transmisión de voz y datos entre diferentes dispositivos mediante un enlace
por radiofrecuencia de corto rango. Los principales objetivos que se pretende
conseguir con esta norma son:
• Facilitar las comunicaciones entre equipos móviles y fijos.
• Eliminar cables y conectores entre éstos.
• Ofrecer la posibilidad de crear pequeñas redes inalámbricas y facilitar la
sincronización de datos entre nuestros equipos personales.
Los dispositivos que con mayor intensidad utilizan esta tecnología son los de
los sectores de las telecomunicaciones y la informática personal, como PDAs,
teléfonos celulares, computadoras portátiles, PCs, impresoras y cámaras digitales.
La tecnología Bluetooth comprende hardware, software y requerimientos
de interoperatividad, por lo que para su desarrollo ha sido necesaria la participación de los principales fabricantes de los sectores de las telecomunicaciones
y la informática, tales como: Sony Ericsson, Nokia, Motorola, Toshiba, IBM e
Intel, entre otros. Posteriormente se han ido incorporando muchas más compañías, y se prevé que próximamente lo hagan también empresas de sectores
tan variados como automatización industrial, maquinaria, ocio y entretenimiento, fabricantes de juguetes, electrodomésticos, etc., con lo que en poco
tiempo se nos presentará un panorama de total conectividad de nuestros aparatos tanto en casa como en el trabajo.
2.6. ESTÁNDARES
43
Descripción
Bluetooth proporciona una vía de interconexión inalámbrica entre diversos
aparatos que tengan dentro de sí esta tecnología, como móviles ( Nokia 6600),
consolas (Nokia N-Gage), dispositivos PDA, cámaras digitales, computadoras
portátiles, impresoras, o simplemente cualquier dispositivo que un fabricante considere oportuno, usando siempre una conexión segura de radio de muy
corto alcance. El alcance que logran tener estos dispositivos es de 10 metros
para ahorrar energía ya que generalmente estos dispositivos utilizan mayoritariamente baterías. Sin embargo, se puede llegar a un alcance de hasta 100
metros (similar a Wi-Fi) pero aumentando el consumo energético considerablemente. Para mejorar la comunicación es recomendable que nada físico, como
por ejemplo una pared, se interponga.
El primer objetivo para los productos Bluetooth de primera generación eran
los entornos de la gente de negocios que viaja frecuentemente. Esto originaba
una serie de cuestiones previas que deberían solucionarse tales como:
• El sistema debería operar en todo el mundo.
• El emisor de radio deberá consumir poca energía, ya que debe integrarse
en equipos alimentados por baterías.
• La conexión deberá soportar voz y datos, y por lo tanto aplicaciones
multimedia.
• La tecnología debería tener un bajo costo. Como objetivo se quiso alcanzar los 5 US$ por dispositivo.
Muchos dipositivos han adquirido esta característica lo que es un gran
avance.
2.6.2
IrDA - Infrared Data Association
Infrared Data Association (IrDA) define un estándar físico en la forma de
transmisión y recepción de datos por rayos infrarrojos. IrDA se crea en 1993
entre HP, IBM, Sharp y otros.
Esta tecnología está basada en rayos luminosos que se mueven en el espectro infrarrojo. Los estándares IrDA soportan una amplia gama de dispositivos
44
CAPÍTULO 2. TECNOLOGÍA MÓVIL
Figura 2.13: Bluetooth Apple Mighty Mouse
Figura 2.14: Teclado Bluetooth
2.6. ESTÁNDARES
45
eléctricos, informáticos y de comunicaciones, permite la comunicación bidireccional entre dos extremos a velocidades que oscilan entre los 9.600 bps y los
4 Mbps. Esta tecnología se encuentra en muchos ordenadores portátiles, y en
un creciente número de teléfonos celulares, sobre todo en los de fabricantes
líderes como Nokia y Ericsson.
El FIR (Fast Infrared) se encuentra en estudio, con unas velocidades teóricas de hasta 16 Mbps.
Estructura
En IrDA se define una organización en capas, las cuales pueden verse en la
figura 2.15 de la página 46.
Además cualquier dispositivo que quiera obtener la conformidad de IrDA
ha de cumplir los protocolos obligatorios (azul), no obstante puede omitir
alguno o todos los protocolos opcionales (verde). Esta diferenciación permite
a los desarrolladores optar por diseños más ligeros y menos costosos, pudiendo
también adecuarse a requerimientos más exigentes sin que sea necesario salirse
del estándar IrDA.
Protocolos IrDA
• PHY (Physical Signaling Layer) establece la distancia máxima, la velocidad de transmisión y el modo en el que la información se transmite.
• IrLAP (Link Access Protocol) facilita la conexión y la comunicación
entre dispositivos.
• IrLMP (Link Management Protocol) permite la multiplexación de la
capa IrLAP.
• IAS (Information Access Service ) actúa como unas páginas amarillas
para un dispositivo.
• Tiny TP mejora la conexión y la transmisión de datos respecto a IrLAP.
• IrOBEX diseñado para permitir a sistemas de todo tamaño y tipo intercambiar comandos de una manera estandarizada.
• IrCOMM para adaptar IrDA al método de funcionamiento de los puertos
serie y paralelo.
46
CAPÍTULO 2. TECNOLOGÍA MÓVIL
Figura 2.15: IrDA - Organización de sus capas.
• IrLan permite establecer conexiones entre ordenadores portátiles y LANs
de oficina.
2.6.3
IEEE 802.11 o Wi-Fi
El protocolo IEEE 802.11 o Wi-Fi es un estándar de protocolo de comunicaciones del IEEE que define el uso de los dos niveles más bajos de la arquitectura
OSI (capas física y de enlace de datos), especificando sus normas de funcionamiento en una WLAN. En general, los protocolos de la rama 802.x definen
la tecnología de redes de área local.
La familia 802.11 actualmente incluye seis técnicas de transmisión por
modulación que utilizan todos los mismos protocolos. El estándar original de
este protocolo data de 1997, era el IEEE 802.11 , tenía velocidades de 1 hasta
2 Mbps y trabajaba en la banda de frecuencia de 2,4 GHz. En la actualidad
no se fabrican productos sobre este estándar.
El término IEEE 802.11 se utiliza también para referirse a este protocolo
al que ahora se conoce como “802.11legacy”. La siguiente modificación apareció en 1999 y es designada como IEEE 802.11b, esta especificación tenía
velocidades de 5 hasta 11 Mbps, también trabajaba en la frecuencia de 2,4
GHz. También se realizó una especificación sobre una frecuencia de 5 Ghz
que alcanzaba los 54 Mbps, era la 802.11a y resultaba incompatible con los
productos de la b y por motivos técnicos casi no se desarrollaron productos.
Posteriormente se incorporó un estándar a esa velocidad y compatible con el
b que recibiría el nombre de 802.11g.
En la actualidad la mayoría de productos son de la especificación b y de la
2.6. ESTÁNDARES
47
Figura 2.16: Tarjeta Wi-Fi para PalmOne
g. El siguiente paso se dará con la norma 802.11n que sube el límite teórico
hasta los 600 Mbps. Actualmente ya existen varios productos que cumplen un
primer borrador del estándar N con un máximo de 300 Mbps (80-100 estables).
La seguridad forma parte del protocolo desde el principio y fue mejorada en
la revisión 802.11i. Otros estándares de esta familia (c-f, h-j, n) son mejoras
de servicio y extensiones o correcciones a especificaciones anteriores. El primer
estándar de esta familia que tuvo una amplia aceptación fue el 802.11b. En
2005, la mayoría de los productos que se comercializan siguen el estándar
802.11g con compatibilidad hacia el 802.11b.
Los estándares 802.11b y 802.11g utilizan bandas de 2,4 Ghz que no necesitan de permisos para su uso. El estándar 802.11a utiliza la banda de 5
GHz. El estándar 802.11n hará uso de ambas bandas, 2,4 GHz y 5 GHz.
Las redes que trabajan bajo los estándares 802.11b y 802.11g pueden sufrir
interferencias por parte de hornos microondas, teléfonos inalámbricos y otros
equipos que utilicen la misma banda de 2,4 Ghz.
Dispositivos
Existen varios dispositivos que permiten interconectar elementos Wi-Fi, de
forma que puedan interactuar entre si. Entre ellos destacan routers, acces
points, etc, para la emisión de la señal Wi-Fi y para la recepción se utilizan
tarjetas para conectar a los PC, ya sean internas, como tarjetas PCI o bien
USB (tarjetas de nueva generación que no requieren incluir ningún hardware
dentro de la computadora).
48
CAPÍTULO 2. TECNOLOGÍA MÓVIL
Los acces points funcionan a modo de emisor remoto, es decir, en lugares
donde la señal Wi-Fi del router no tenga suficiente señal, se colocan estos
dispositivos, que reciben la señal bien por un cable UTP que se lleve hasta él
o bien que capture la señal débil y la amplifique (aunque para este ultimo caso
existen aparatos especializados que ofrecen un mayor rendimiento).
Los routers son los que reciben la señal de la línea que ofrezca el proveedor,
se encargan de todos los problemas inherentes a la recepción de la señal, donde
se incluye el control de errores y extracción de la información, para que los
diferentes niveles de red puedan trabajar. En este caso el router efectúa el
reparto de la señal, de forma muy eficiente.
Además de routers, hay otros dispositivos que pueden encargarse de la distribución de la señal, aunque no pueden encargarse de las tareas de recepción,
como pueden ser hubs y switch, estos dispositivos son mucho más sencillos que
los routers, pero también su rendimiento en la red local es muy inferior.
Los dispositivos de recepción abarcan tres tipos mayoritarios: tarjetas PCI,
tarjetas PCMCIA y tarjetas USB :
• Las tarjetas PCI para Wi-Fi se agregan a las computadoras de escritorio,
permiten un acceso muy eficiente, la única desventaja de este tipo de
tarjeta es que requiere abrir el gabinete de la computadora.
• Las tarjetas PCMCIA son un modelo que se utilizó mucho en las primeras computadoras portátiles, la mayor parte de estas tarjetas solo son
capaces de llegar hasta la tecnología b de Wi-Fi, no permitiendo por
tanto disfrutar de una velocidad de transmisión demasiado elevada.
• Las tarjetas USB para Wi-Fi son el tipo de tarjeta más moderno que
existe y más sencillo de conectar a un PC, ya sea de escritorio o portátil,
haciendo uso de todas las ventajas que tiene la tecnología USB, además la
mayor parte de las tarjetas USB actuales permite utilizar la tecnología g
de Wi-Fi, incluso algunas ya ofrecen la posibilidad de utilizar la llamada
tecnología Pre n.
Ventajas y desventajas
Una de las desventajas que tiene Wi-Fi es la pérdida de velocidad en relación
a la misma conexión utilizando cables, debido a las interferencias y pérdidas
de señal que el ambiente puede acarrear.
2.7. INTERNET MÓVIL - WAP
49
Figura 2.17: Tarjeta USB para Wi-Fi
Existen algunos programas capaces de capturar paquetes, trabajando con
su tarjeta Wi-Fi en modo promiscuo, de forma que puedan calcular la contraseña de la red y de esta forma acceder a ella, las claves de tipo WEP son
relativamente fáciles de conseguir para cualquier persona con un conocimiento medio de informática. La alianza Wi-Fi arregló estos problemas sacando
el estándar WPA y posteriormente WPA2, basados en el grupo de trabajo
802.11i. Las redes protegidas con WPA2 se consideran robustas dado que
proporcionan muy buena seguridad.
Los dispositivos Wi-Fi ofrecen gran comodidad en relación a la movilidad
que ofrece esta tecnología, sobre los contras que tiene Wi-Fi es la capacidad
de terceras personas para conectarse a redes ajenas si la red no está bien
configurada y la falta de seguridad que esto trae consigo.
Cabe aclarar que esta tecnología no es compatible con otros tipos de conexiones sin cables como Bluetooth, GPRS, UMTS, etc.
2.7
Internet Móvil - WAP
Wireless Application Protocol o WAP (protocolo de aplicaciones inalámbricas)
es un estándar abierto internacional para aplicaciones que utilizan las comunicaciones inalámbricas, por Ej. Acceso a servicios de Internet desde un teléfono
móvil.
Se trata de la especificación de un entorno de aplicación y de un conjunto de
protocolos de comunicaciones para normalizar el modo en que los dispositivos
50
CAPÍTULO 2. TECNOLOGÍA MÓVIL
inalámbricos, se pueden utilizar para acceder a correo electrónico, grupo de
noticias y otros.
El organismo que se encarga de desarrollar el estándar WAP fue originalmente el WAP Forum, fundado por cuatro empresas del sector de las comunicaciones móviles, Sony-Ericsson, Nokia, Motorola y Openwave (originalmente
Unwired Planet). Desde 2002 el WAP Forum es parte de la Open Mobile
Alliance (OMA), consorcio que se ocupa de la definición de diversas normas
relacionadas con las comunicaciones móviles, entre ellas las normas WAP.
2.7.1
Tecnología - WAP
En la versión 1 de WAP, definida en 1999, el lenguaje de presentación de contenidos es el WML, o Wireless Markup Language. La pila de protocolos de WAP
1 no es compatible directamente con la de Internet: WSP (Wireless Session
Protocol), WTP (Wireless Transaction Protocol), WTLS (Wireless Transport
Layer Security), y WDP (Wireless Datagram Protocol). WDP corresponde
a la capa de transporte, con funcionalidad equivalente al protocolo UDP de
Internet, y se apoya en los servicios de la “portadora” WAP, que depende de
la red móvil que esté usando el terminal. WAP 1 además define la interfaz de
acceso de las aplicaciones a las funciones de telefonía del terminal con WTAI
(Wireless Telephony Application Interface), y también un sencillo lenguaje de
“scripting”, WMLScript, basado en ECMAscript/JavaScript.
La incompatibilidad de la pila de protocolos WAP 1 con la de Internet exige
la presencia de un nodo pasarela para hacer de intermediario en la comunicación entre un terminal WAP y un servidor de contenidos WAP residente en
Internet. WAP 1 ha sido objeto de fuertes críticas por diversos motivos, que
incluyen la pobreza del soporte gráfico (gráficos monocromos WBMP, Wireless Bitmap), las diferencias en las implantaciones de WAP en los terminales
de distintos fabricantes, y un potencial problema de seguridad debido a que
WTLS no es muy robusto y además, por no ser compatible con las capas de
seguridad usadas en Internet, en la pasarela WAP los contenidos deben estar
en claro.
La nueva versión de WAP, WAP 2.0 , está presente en los teléfonos móviles
de nueva generación (a partir de 2004). Esta versión es una reingeniería de
WAP que utiliza XHTML-MP (Mobile Profile) como lenguaje de presentación
de contenidos, y mejora el soporte de los gráficos (incluye color). En cuanto
a los protocolos usados, en la capa de transporte se usa TCP y en la de
2.7. INTERNET MÓVIL - WAP
51
aplicación, HTTP. Así pues, WAP 2.0 ha adoptado los protocolos de Internet.
WAP 2.0 además especifica opciones tanto en TCP como en HTTP para
mejorar las prestaciones de dichos protocolos sobre redes de comunicaciones
móviles. Los mecanismos de seguridad usados ya son compatibles con los de
Internet por lo que los problemas de seguridad de WAP 1 se resuelven. La
pasarela WAP no es estrictamente necesaria en WAP 2.0 , pero su presencia
puede tener funciones útiles, como caché web y para dar soporte a las opciones
de TCP y HTTP antes mencionadas.
Capítulo 3
Aplicaciones Móviles
3.1
Introducción
Los dispositivos de computación inalámbrica han crecido rápidamente, requiriendo aplicaciones de software cada vez más potentes que puedan manejar
esta nueva realidad. Los usuarios desean que las aplicaciones que corren en
sus dispositivos móviles tengan la misma funcionalidad estando conectados
o desconectados de la red. Esperan aplicaciones que puedan soportar conexiones intermitentes, anchos de banda cambiantes y que manejen
eficientemente el problema del roaming.
El rango de dispositivos móviles va desde dispositivos dedicados a tareas específicas, como los teléfonos celulares, hasta aquellos dispositivos de propósito
general, como las handhelds o como las notebooks. Cada uno de ellos presenta
diferentes conjuntos de desafíos para el diseño de aplicaciones móviles.
Algunos de estos desafíos compartidos por la mayoría de los dispositivos
móviles incluyen:
• La ubicación física del dispositivo y la configuración pueden cambiar en
cualquier momento a medida que el dispositivo está conectado o desconectado de la red o se mueve entre dos puntos de conexión. La arquitectura de aplicación móvil debe soportar una operación consistente
operando tanto online como offline y proveer una conectividad continua
mientas el dispositivo se mueve entre puntos de conexión.
53
54
CAPÍTULO 3. APLICACIONES MÓVILES
• Los dispositivos que se alimentan mediante el uso de baterías pueden
operar por un tiempo limitado sin recargar o reemplazar las mismas. La
arquitectura de una aplicación móvil debe ser diseñada para administrar
esa energía limitada de las baterías, mediante el uso de estrategias que
prologuen la vida útil al reducir el consumo sin sacrificar el rendimiento
del sistema.
Una arquitectura de aplicaciones móviles debe proveer soporte para un amplio rango de dispositivos. Debido a que los dispositivos pequeños de propósito
específico, tales como teléfonos celulares, poseen limitaciones de recursos como el tamaño reducido de sus pantallas, limitado almacenamiento y poder de
cómputo. [14]
3.2
Requerimientos Para Una Arquitectura de Aplicaciones Móviles
Una aplicación diseñada para ser usada en un dispositivo móvil debe cumplir
con ciertos requerimientos, algunos son propios del ambiente móvil y otros
pueden ser requerimientos de cualquier tipo de aplicación. A continuación se
presentan los más relevantes:
• Operación consistente tanto online como offline: En varias arquitecturas, los datos son almacenados en un sistema compartido accesible
a través de la red, en forma de documentos, registros de datos o archivos
binarios, donde se tiene un acceso coordinado a una copia de la información. Una aplicación móvil debe ser diseñada de forma de que los
usuarios puedan acceder a los datos sin importar si lo hacen en forma
online o en forma offline. Cuando se trabaja offline, el usuario percibe
que la información compartida está disponible para lectura y escritura.
Cuando la conectividad regresa, los cambios en la información local son
integrados a la copia de red y viceversa.
• Conectividad continua: Una aplicación diseñada para movilidad debe trabajar con un agente o servicio Proxy para permitir un manejo
transparente de los cambios en la conectividad. La conectividad no tiene que ser un requerimiento para la funcionalidad y cortes intermitentes
e inesperados en la conexión con la red deben poder ser manejados satisfactoriamente. Así mismo este agente o servicio Proxy debe poder
3.2. REQUERIMIENTOS PARA UNA ARQUITECTURA MÓVIL
55
seleccionar la red óptima de las disponibles en ese momento, y manejar las tareas propias de la comunicación como autentificación segura o
autorización y direccionamiento lógico.
• Clientes que soporten multiplataformas: Una aplicación móvil debe al menos ajustar su interacción y comportamiento al dispositivo en
el que corre, como por ejemplo tipo de entrada y salida, recursos disponibles y nivel de performance.
• Administración de recursos: Un recurso como la energía, el ancho
de banda o el espacio de almacenamiento puede ser consumido y existe
en una cantidad finita. La administración de recursos debe permitir el
monitoreo de atributos como cantidad o tasa de uso, y soportar notificaciones basadas en disparadores predefinidos por el usuario.
• Administración del contexto: Contexto es cualquier información que
puede ser usada para caracterizar la situación de una entidad. Donde
una entidad es una persona, lugar u objeto que es relevante para la
interacción entre un usuario y una aplicación, incluyendo al usuario y
la aplicación. La administración del contexto debe permitir el monitoreo de atributos como ubicación actual o tipo de dispositivo, y proveer
notificación de cambios en el mismo.
• Codificación: La codificación involucra la modificación de los datos
y protocolo en función de los requerimientos del contexto y recursos
disponibles. Ejemplos de codificación son la encriptación, compresión y
transcodificación. Una implementación de la capacidad de codificación
permitirá la enumeración de los encoders y decoders disponibles. Luego
con ésta información disponible junto con la capacidad de administración
del contexto, proveer la habilidad de negociar el uso de uno u otro método
de codificación.
• Almacenamiento duradero: La capacidad de manejar un almacenamiento duradero permite la persistencia de datos de configuración o
información estática.
• Seguridad: Para evitar las consecuencias de ataques maliciosos, aplicaciones con diseños pobres, y errores inadvertidos de usuarios, se deben
tomar ciertas medidas de seguridad como ser: Sistemas y usuarios deben
ser autenticados, autentificación de sistemas, usuarios y acciones deben
ser autorizados, y acciones e interacciones deben ser auditadas.
56
CAPÍTULO 3. APLICACIONES MÓVILES
Se puede observar que los requerimientos planteados son en gran medida
requerimientos no funcionales, esto se debe a la naturaleza sumamente restrictiva implicada en un escenario móvil, y relacionada especialmente con aspecto
de hardware.
3.3
Arquitectura de Portal Para Aplicaciones Móviles
La función primaria de un portal es la de agregar e integrar diversas y distribuidas fuentes de información, y presentar el resultado al usuario en una vista
simple concisa y pertinente a través de un navegador Web o Web Browser.
Un portal es típicamente dirigido a un grupo específico o tipo de usuario.
Por ejemplo en la Intranet de una compañía, el sector de atención al cliente
puede acceder a información relacionada con clientes (promociones vigentes,
descuentos, etc.), pero no puede acceder a información financiera, ésta estaría
sólo autorizada para los integrantes del sector de finanzas. [14]
Los contenidos que puede tener un portal son:
• Datos relativamente estáticos, como banners, gráficos y estructura general.
• Contenido dinámico, información que cambia con cierta frecuencia, el
caso de las promociones vigentes para el sector de atención al cliente
estaría dentro de este grupo.
• Información nueva o trascendente, como notificaciones o información
incremental. Por ejemplo una notificación para el grupo de ventas de
un determinado producto que indique que el stock se ha terminado.
La arquitectura de un portal abarca tres tipos de funciones:
• Fuentes de Información: Las fuentes de información proveen de datos al
portal. Las fuentes de información incluyen bases de datos, aplicaciones
u otros portales externos al sistema.
• Funciones del Portal: Las funciones de un portal son básicamente las de
agregar y componer la información para luego ser entrada al usuario.
3.3. ARQUITECTURA DE PORTAL MÓVIL
57
• Funciones Independientes: Son tecnologías persistentes o componentes,
como el Web Browser.
Los componentes incluidos en un portal son los siguientes:
• Web browser: Provee una interface del portal al usuario, si se accede a
través de Internet, un protocolo Proxy soporta la comunicación con el
usuario y con el portal HTTP y HTML comúnmente mejorado del lado
del cliente con el uso de lenguajes de scripting y/o código ubicado en el
browser como ActiveX o controles Java.
• Servidor de Presentación: Crea e integra vistas de contenido a través de
la interacción con otros componentes.
• Servidor de Aplicación: Ejecuta cualquier código que sea requerido dinámicamente para extraer y reformatear información desde sistemas no
basados en Web.
• Administración de Contenido, búsqueda e indexación, y colaboración.
• Servicios de Personalización: Disponible para que cada usuario pueda
configurar la vista y el contenido que quiere tener cada vez que accede
al portal.
• Seguridad: Un requerimiento para toda arquitectura de aplicaciones
móviles, es el de asegurar la integridad de información sensible en sitios remotos.
Un portal Web es completamente dependiente de la conexión de red, ya
que es una arquitectura centrada en el servidor y la conexión de red se hace
un recurso imprescindible.
Una solución simple para aplicaciones móviles es la de permitir el acceso
offline a sitios Web, bases de datos y archivos que han sido previamente descargados en el móvil. El usuario interactúa con los mismos y una vez que la
conexión se restablece, las copias locales y remotas se sincronizan. Esta solución es válida para aquellos portales simples, pero cuando las fuentes de datos
vienen asociadas con otros sistemas o directamente no caben en el dispositivo
móvil , no podrá ser aplicada.
Entonces, sin conexión de red, la creación de contenido dinámico desde
un portal y sus sistemas back-end en tiempo de ejecución es esencialmente
58
CAPÍTULO 3. APLICACIONES MÓVILES
imposible. Sin embargo existen algunas aproximaciones que pueden ser usadas
para proveer una vista offline del contenido:
• Prealmacenado del contenido generado en el portal.
• Replicación en el sistema móvil de los datos y el código usado para
generar el portal y su sistema back-end.
La apropiada estrategia a utilizar dependerá de factores como cantidad de
datos involucrados, la complejidad de la interacción del usuario con los datos,
y la frecuencia necesaria de actualización de los mismos.
A continuación se presentará de que forma una arquitectura de portal móvil
puede cubrir los requerimientos planteados para caracterizar una aplicación
móvil:
• Clientes que soporten multiplataformas: Los portales usualmente soportan el acceso desde diferentes plataformas, manejan diferentes
caracterizaciones de dispositivos, y cualquier transcodificación de contenido requerido. Como el contenido comúnmente es dinámico y el tipo de
dispositivo del cliente impredecible, estas actividades ocurren en tiempo
de ejecución. Una aplicación cliente que soporte movilidad no necesita soportar transcodificación dinámica porque el tipo de dispositivo del
cliente es estático. La aplicación no necesita manejar cambios dinámicos en la personalización del dispositivo offline, ya que se supone que el
mismo será usado por una única persona.
• Capacidad de trabajar offline:
— Prealmacenado de Contenido: involucra el prealmacenado del contenido provisto por un portal en respuesta a un requerimiento hecho
por un cliente a través de una URL, como una página Web. El código que genera el contenido no es prealmacenado. Por ejemplo un
link (enlace) puede ser referencia a un script JSP o ASP, el Server
de aplicación corre este script y devuelve al cliente streams HTML.
Estos HTML son los que están prealmacenados, no los scripts. Navegar por el portal, siguiendo cada link y almacenar la salida en
el sistema local para luego disponer del mismo offline, es un mecanismo completamente ineficiente. Además todas la páginas pueden
no ser requeridas, por lo tanto el prealmacenado de contenido debe
3.4. ARQUITECTURA DE BASES DE DATOS
59
realizarse bajo el control de la configuración local que especifique
las páginas de interés o provea un criterio de selección.
— Replicación de Código: permite que el contenido del portal sea más
dinámico. El portal puede ejecutar código, por ejemplo JAVA, en
el proceso de servir el contenido al usuario o en la recolección y
manejo de datos de otros sistemas. El código es replicado desde el
servidor al cliente. Alguna replicación involucra componentes de la
interface del usuario, la mayoría está involucrado con la colección,
manipulación y almacenamiento de datos.
— Replicación de Datos: los datos pueden ser replicados del portal
al cliente, del cliente al portal o en ambas direcciones. Si los datos solo pueden tener permiso de escritura en el lado del cliente,
la implementación se vuelve más simple, sin embargo la implementación que permite esquemas de múltiples copias que pueden ser
actualizadas independientemente, se vuelve más compleja.
— Conectividad Continua: Dos áreas están incluidas dentro de conectividad continua, estas son administración de conectividad de red
y la seguridad desde el punto de vista del usuario. Por ejemplo el
usuario no tendrá físicamente que re-autenticarse cada vez que el
sistema se reconecta. La conectividad continua puede ser soportada
por emulación, la cual provee la apariencia de que el recurso de red
se encuentra disponible.
Una posible arquitectura de portal para aplicaciones móviles es la mostrada en la figura 3.1 de la página 60, la cual refleja varios tipos de modificaciones:
agregado de nuevos componentes (a los habituales de un portal no móvil).
3.4
Arquitectura de Bases de Datos Para Aplicaciones Móviles
Los usuarios tradicionales de una base de datos acceden a los datos residentes
en el servidor de bases de datos desde sus equipos clientes conectados físicamente a la red. Los datos se presentan en la máquina cliente como una simple
vista de los datos residentes en el servidor. Esta particular arquitectura es segura pero al mismo tiempo limitada en el hecho de que los usuario no pueden
ver o trabajar con los datos sin una conexión a la red. Todo procesamiento
tiene lugar en el servidor, construido específicamente para tal propósito.
60
CAPÍTULO 3. APLICACIONES MÓVILES
Figura 3.1: Arquitectura Portal Móvil
3.4. ARQUITECTURA DE BASES DE DATOS
61
Se puede afirmar que una base de datos es un archivo que contiene varios
registros de datos. En un ambiente cliente / servidor tradicional, más de
un usuario puede utilizar la misma base de datos simultáneamente. RDBMS
(Sistemas Manejadores de Bases de Datos Relacionales) hace esto posible a
través del uso de mecanismos internos de locking que previenen que más de
un usuario modifique un registro al mismo tiempo. [14]
Una arquitectura de base de datos preparada para un ambiente móvil,
permite a los usuarios acceder a la información en cualquier momento y desde
cualquier lugar.
En un ambiente móvil, copias de los datos pueden existir en distintos
sistemas clientes. Dado que estos sistemas clientes no están continuamente
conectados a la base de datos central, el RDBMS de dicha base no es capaz
de prevenir cambios simultáneos a los datos por más de un usuario. Por
otra parte, los datos locales en cada sistema cliente deben ser periódicamente
sincronizados con los datos de la base master que reside en el servidor.
Algunos de los desafíos al diseñar una arquitectura de bases de datos son
los siguientes:
• Los datos en los sistemas cliente se desactualizan durante los periodos
en que el cliente no está conectado. Los mensajes referentes a actualizaciones pendientes no estarán disponibles mientras el sistema este desconectado, esto introducirá más dudas sobre la validez de los datos.
• La resolución de conflictos se volverán más desafiantes y ya no estarán
bajo el control del RDBMS.
• El poder de procesamiento local en los clientes puede ser limitado en
comparación al poder de procesamiento disponible en el servidor.
• Los datos propietarios, deben mantenerse seguros en las ubicaciones remotas.
Un usuario móvil debe ser capaz de seleccionar los datos a replicar en el
sistema cliente para su uso cuando el sistema este desconectado de la red. La
replicación de la base de datos completa no debe ser permitida, se debe limitar
al usuario a un arbitrario conjunto de datos.
Las desconexiones cliente / servidor deben ser transparentes al usuario.
62
CAPÍTULO 3. APLICACIONES MÓVILES
La aplicación cliente debe continuar teniendo un buen comportamiento y los
datos continuar disponibles para el usuario.
Un usuario necesita saber si los datos que va a utilizar en un ambiente
offline son viejos, irrelevantes o transitorios. El usuario debe ser capaz de basar
sus decisiones en estos datos, pero los mismos deben ser marcados de forma
que la decisión resultante pueda ser actualizada cuando los datos vuelvan a
estar disponibles online nuevamente.
Una arquitectura de base de datos para aplicaciones móviles debe garantizar que las transacciones serán trasmitidas confiablemente. Durante una
transacción normal, una conexión de red es establecida entre el cliente y el
servidor y la transferencia de datos es iniciada.
Cuando la transferencia de datos se completa, una notificación sobre si la
transferencia fue realizada con éxito o no es enviada al que la inició. La falla
o el éxito de la transacción, no debe limitar el trabajo que el usuario puede
hacer. Por ejemplo, si el dispositivo está conectado a la red y actualiza un
campo de datos, la transacción será trasmitida al servidor inmediatamente.
Si la conexión se pierde durante la transmisión, la transacción será encolada
para ser transmitida cuando la conexión sea restablecida. Mientras tanto el
usuario debe poder ser capaz de hacer referencia a la actualización aunque la
transmisión no se haya completado.
3.5
Aplicaciones Multiplataforma
Multiplataforma es un término usado para referirse a los programas, sistemas
operativos, lenguajes de programación, u otra clase de software, que puedan
funcionar en diversas plataformas. Por ejemplo, una aplicación multiplataforma podría ejecutarse en Windows en un procesador x86, en GNU/Linux en
un procesador x86, y en Mac OS X en un x86, sin ningún tipo de problemas.
Una plataforma es una combinación de hardware y software usada para
ejecutar aplicaciones, en su forma más simple consiste únicamente de un sistema operativo, una arquitectura, o una combinación de ambos. La plataforma
más conocida es probablemente Microsoft Windows en una arquitectura x86,
otras plataformas conocidas son GNU/Linux y Mac OS X (que ya de por sí
son multiplataforma).
3.5. APLICACIONES MULTIPLATAFORMA
63
El software en general está escrito de modo que dependa de las características de una plataforma particular; bien sea el hardware, sistema operativo, o
máquina virtual en que se ejecuta. La plataforma Java es una máquina virtual
multiplataforma, tal vez la más conocida de este tipo, así como una plataforma
popular para hacer software.
3.5.1
Java y Multiplataforma
Uno de los principales objetivos de los desarrolladores de software en los últimos años ha sido conseguir programas portables, capaces de ser ejecutados en
diversas plataformas (Macintosh PC, Unix, Windows), logrando la compatibilidad total.
La aparición del lenguaje Java da la primera solución satisfactoria al problema de la compatibilidad. La idea consiste en crear máquinas virtuales
idénticas en cada una de las diferentes plataformas y encargarles a ellas la
ejecución de programas, obteniendo así la compatibilidad total.
Con el desarrollo de estas máquinas virtuales anteriormente mencionadas
se puede lograr que el mismo código binario ejecutable se pueda usar en todos
los sistemas compatibles con el software Java. Además la penetración de Java
en Internet, como lenguaje de acompañamiento al HTML, ha sido todo un
éxito.
Capítulo 4
Java
4.1
Introducción al Lenguaje
Java es un lenguaje orientado a objetos. Esto significa que posee ciertas características estándares en los lenguajes OO:
• Objetos.
• Clases.
• Métodos.
• Subclases.
• Herencia simple.
• Enlace dinámico.
• Encapsulamiento.
Java se volvió un lenguaje muy popular. Antes de que Java apareciera,
por ejemplo, C era un lenguaje extremadamente popular entre los programadores y parecía que era el lenguaje de programación perfecto, combinando
los mejores elementos de los lenguajes de bajo y alto nivel en un lenguaje de
programación que se ajustaba a la arquitectura del ordenador y que gustaba
a los programadores.
65
66
CAPÍTULO 4. JAVA
Sin embargo, el lenguaje C tenía limitaciones, al igual que los lenguajes de
programación anteriores. Cuando los programas crecían, los programas C se
hacían inmanejables porque no había una forma fácil de acortarlo. Esto quiere
decir que el código de la primera línea de un programa largo podría interferir
con el código de la última línea y el programador tendría que recordar todo el
código mientras programaba.
La programación orientada a objetos se hizo popular por ser capaz de
dividir programas largos en unidades semi-autónomas. El lema de la programación orientada a objetos es “divide y vencerás”.
Dicho en otras palabras, un programa se puede dividir en partes fácilmente
identificables.
Por ejemplo, se supone que para mantener fresca la comida se utiliza un
sistema complejo.
Debería comprobar la temperatura de la comida usando un termómetro y
cuando la temperatura fuera lo suficientemente alta, se activaría un interruptor
que arrancara el compresor e hiciera funcionar las válvulas para que el frío
circulara; luego arrancaría un ventilador que moviera el aire. Esa es una forma
de hacerlo. Sin embargo, otra consiste en coordinar todas esas operaciones
de forma que sean automáticas, cubriendo todo con una unidad sencilla, un
refrigerador. Ahora las interioridades no se ven y lo único que hay que hacer
es introducir o sacar comida del frigorífico.
De esta forma es como funcionan los objetos, ocultan los detalles de la
programación al resto del programa, reduciendo todas las interdependencias
que aparecen en un programa C e inicializando una interfaz bien definida y
controlable que mantiene la conexión entre el objeto y el resto del código.
Resumiendo se puede decir que la programación orientada a objetos consiste en la división de un problema en diferentes partes (objetos) donde:
• Cada objeto posee una funcionalidad específica.
• Los objetos interactúan entre sí enviando y recibiendo mensajes; ver
figura 4.1 de la página 67.
La tarea del programador es coordinar las acciones de los objetos y la
comunicación entre los mismos.
4.1. INTRODUCCIÓN AL LENGUAJE
67
Figura 4.1: Mecanismo de Mensajes
Para programar bajo el paradigma orientado a objetos es necesario primero
diseñar un conjunto de clases. La claridad, eficiencia y mantenibilidad del
programa resultante dependerá principalmente de la calidad del diseño de
clases. Un buen diseño de clases significará una gran economía en tiempo de
desarrollo y mantención.
Lamentablemente se necesita mucha habilidad y experiencia para lograr
diseños de clases de calidad. Un mal diseño de clases puede llevar a programas
OO de peor calidad y de más alto costo que el programa equivalente no OO
[15].
Una gran ventaja de un lenguaje OO, son las bibliotecas de clases que se
pueden construir para la aplicación [16]. Una biblioteca de clases cumple el
mismo objetivo de una biblioteca de procedimientos en una lenguaje como C.
Sin embargo:
Una biblioteca de clases es mucho más fácil de usar que una biblioteca de
procedimientos, incluso para programadores sin experiencia en orientación a
objetos. Esto se debe a que las clases ofrecen mecanismos de abstracción más
eficaces que los procedimientos.
4.1.1
Bibliotecas de Clases Estándares de Java
Toda implementación de Java debe tener las siguientes bibliotecas de clases:
• Manejo de archivos.
• Comunicación de datos.
• Acceso a la red Internet..
68
CAPÍTULO 4. JAVA
• Acceso a bases de datos.
• Interfaces gráficas.
La interfaz de programación de estas clases es estándar, esto quiere decir
que en todas ellas las operaciones se invocan con el mismo nombre y los mismos
argumentos.
4.1.2
Java es Multiplataforma
Los programas en Java pueden ejecutarse en cualquiera de las siguientes plataformas, sin necesidad de hacer cambios:
Windows/95 y /NT.
Power/Mac.
Unix (Solaris, Silicon Graphics, ...).
La compatibilidad es total:
A nivel de fuentes: el lenguaje es exactamente el mismo en todas las
plataformas.
A nivel de bibliotecas: en todas las plataformas están presentes las mismas
bibliotecas estándares.
A nivel del código compilado: el código intermedio que genera el compilador
es el mismo para todas las plataformas. Lo que cambia es el intérprete del
código intermedio, la MVJ (Máquina Virtual Java).
Máquina Virtual Java
Es un programa (software) que maneja la interacción entre las aplicaciones
Java y el Sistema operativo y hardware subyacentes.
Este programa interpreta los bytecodes generados por el compilador de
Java durante la ejecución de un programa Java.
El proceso de compilación y ejecución se pueden observar en la figura 4.2
de la página 69.
4.1. INTRODUCCIÓN AL LENGUAJE
69
Figura 4.2: Proceso Compilación y Ejecución
4.1.3
Características del Lenguaje
• Robustez
Los siguientes errores no se pueden cometer en Java:
— Java siempre chequea los índices al acceder a un arreglo.
— Java realiza chequeo de tipos durante la compilación (al igual que
C). En una asignación entre punteros el compilador verifica que los
tipos sean compatibles.
— Java realiza chequeo de tipos durante la ejecución (C y C++ no lo
hacen). Cuando un programa usa un cast para acceder a un objeto
como si fuese de un tipo específico, se verifica durante la ejecución
que el objeto en cuestión sea compatible con el cast que se le aplica. Si el objeto no es compatible, entonces se lanza una excepción
informando al programador la línea en donde está el error.
— Java posee un recolector de basuras que administra automáticamente la memoria. La MVJ lo ejecuta para limpiar o reasignar
memoria, se lo denomina “Garbage Collector”.
• Flexibilidad
Java combina flexibilidad, robustez y legibilidad gracias a una mezcla de
chequeo de tipos durante la compilación y durante la ejecución. En Java se
pueden tener punteros a objetos de un tipo específico y también se pueden
70
CAPÍTULO 4. JAVA
tener punteros a objetos de cualquier tipo. Estos punteros se pueden convertir
a punteros de un tipo específico aplicando un cast.
El programador usa entonces punteros de tipo específico en la mayoría de
los casos con el fin de ganar legibilidad y en unos pocos casos usa punteros a
tipos desconocidos cuando necesita tener flexibilidad.
• Administración Automática de la Memoria
En Java los programadores no necesitan preocuparse de liberar un trozo de
memoria cuando ya no lo necesitan. Es el garbage collector el que determina
cuando se puede liberar la memoria ocupada por un objeto.
Un recolector de basuras es un gran aporte a la productividad. Se ha
estudiado en casos concretos que los programadores han dedicado un 40% del
tiempo de desarrollo a determinar en qué momento se puede liberar un trozo
de memoria.
Además este porcentaje de tiempo aumenta a medida que aumenta la
complejidad del software en desarrollo. Es relativamente sencillo liberar correctamente la memoria en un programa de 1000 líneas. Sin embargo, es difícil
hacerlo en un programa de 10000 líneas. Y se puede postular que es imposible
liberar correctamente la memoria en un programa de 100000 líneas.
4.2
Estructura de un Programa Java
En el siguiente ejemplo se presenta la estructura general de un programa realizado en cualquier lenguaje orientado a objetos u OOP (Object Oriented
Programming), y en particular en el lenguaje Java:
import java.awt.*;
import java.lang.String;
import java.lang.Integer;
import java.awt.event.WindowEvent;
import java.util.*;
import java.awt.TextField;
4.3. CONCEPTOS BÁSICOS
71
public class Simu extends Frame implements ActionListener, ItemListener{
MenuBar barra;
m1 =new Menu(“Archivo”);
barra.add(m1);
m2 =new Menu(“Ver”);
barra.add(m2);
....
public static void main(String args [ ]){
Simu menus = new Simu();
menus.setTitle(“Simulación de Redes”);
menus.setVisible(true);
}
}
Aparece una clase que contiene el programa principal Simu (aquel que
contiene la función main()) y algunas clases de usuario (las específicas de
la aplicación que se está desarrollando) que son utilizadas por el programa
principal. La aplicación se ejecuta por medio del nombre de la clase que
contiene la función main(). Las clases de Java se agrupan en packages, que
son librerías de clases. Si las clases no se definen como pertenecientes a un
package, se utiliza un package por defecto (default) que es el directorio activo.
4.3
4.3.1
Conceptos Básicos
Clases
Una clase es una plantilla desde la que se pueden crear objetos. La definición
de una clase incluye especificaciones formales para la clase y cualquier dato y
métodos incluidos en ella. La programación orientada a objetos se basa en la
programación de clases [17]. Un programa se construye a partir de un conjunto
de clases.
Una vez definida e implementada una clase, es posible declarar elementos
de esta clase. Los elementos declarados de una clase se denominan objetos de
72
CAPÍTULO 4. JAVA
la clase. De una única clase se pueden declarar o crear numerosos objetos. La
clase es lo genérico: es el patrón o modelo para crear objetos.
Cada objeto tiene sus propias copias de las variables miembro, con sus
propios valores, en general distintos de los demás objetos de la clase.
Ejemplo:
public abstract class FuncionActivacion implements Cloneable, Serializable{
/*constructor sin argumentos que permite la herencia */
public FuncionActivacion () {
}
}
4.3.2
Herencia
La herencia es uno de los aspectos de la programación orientada a objetos que
se ha definido formalmente. Utilizando la herencia, se puede crear una nueva
clase a partir de otra, y la nueva heredará todos los métodos y miembros de
datos de la primera.
La clase nueva se llama subclase y la clase original, clase base o superclase.
La idea es añadir lo que se quiera a la nueva clase para darle más funcionalidad
que a la clase base.
La herencia es un tema importante en Java, ya que se puede usar la gran
librería de clases disponible, derivando de ellas nuestras clases propias.
En Java, a diferencia de otros lenguajes orientados a objetos, una clase sólo
puede derivar de una única clase, con lo cual no es posible realizar herencia
múltiple en base a clases. Sin embargo es posible “simular” la herencia múltiple
en base a las interfaces.
4.3.3
Interfaces
Una interfaz es una clase abstracta que define métodos abstractos y constantes, pero no implementa los métodos. La clase que implemeta una interfaz
4.4. VARIABLES DE JAVA
73
hereda los métodos y debe implementarlos, es decir se forma un contrato entre
la Interfaz y la clase que implementa la Interfaz.
Una clase puede “implementar” más de una interface y una interface puede
ser implementada por clases que no se encuentran relacionadas.
4.3.4
Package
Un package es una agrupación de clases. Existen una serie de packages incluidos en el lenguaje.
Además el programador puede crear sus propios packages. Todas las clases
que formen parte de un package deben estar en el mismo directorio.
Los packages se utilizan con las siguientes finalidades:
1. Para agrupar clases relacionadas.
2. Para evitar conflictos de nombres. En caso de conflicto de nombres
entre clases importadas, el compilador obliga a cualificar en el código los
nombres de dichas clases con el nombre del package.
3. Para ayudar en el control de la accesibilidad de clases y miembros.
Por las razones citadas, durante la etapa de Diseño del Software desarrollado, se ha decido crear dos paquetes, calculos e interface, utilizando la sentencia
package.
package myprojects.simu;
import myprojects.calculos.*;
import myprojects.interfase.*;
4.4
Variables de Java
Una variable en Java es un identificador que representa una palabra de memoria que contiene información. El tipo de información almacenado en una
variable sólo puede ser del tipo con que se declaró esa variable. Los diferentes
74
CAPÍTULO 4. JAVA
tipos tienen que ver con el formato de los datos que se almacenan en ella, así
como con la memoria que es necesaria para gestionar ese dato.
Hay dos tipos principales de variables:
• Variables de tipos primitivos: Están definidas mediante un valor único
y almacenan directamente ese valor siempre que pertenezca al rango de
ese tipo. Por ejemplo una variable int almacena un valor entero como
1, 2, 0, -1, etc.
• Variables referencia: Las variables referencia son referencias o nombres
de una información más compleja: arrays u objetos de una determinada
clase. Una referencia a un objeto es la dirección de un área en memoria
destinada a representar ese objeto. El área de memoria se solicita con el
operador new. Una variable de referencia también puede ser descripta
como una referencia a una clase.
Por ejemplo si se define: Estudiante e1. e1 es una referencia a una
instancia de Estudiante.
Se puede decir que dentro de un programa las variables pueden ser:
• Variables miembro de una clase: Se definen en una clase, fuera de cualquier método; pueden ser tipos primitivos o referencias. Son también
llamadas atributos.
• Variables locales: Se definen dentro de un método o más en general
dentro de cualquier bloque entre llaves {}. Se crean en el interior del
bloque y se destruyen al finalizar dicho bloque. Pueden ser también tipos
primitivos o referencias.
En la Tabla 4.1 de la página 74 se muestran las grandes categorías de tipos
para las variables en Java:
Tipos Primitivos
int, short, byte, long
char, boolean
float, double
Referencias a Objetos
Strings
Arreglos
otros objetos
Tabla 4.1: Categorías de Variables.
4.4. VARIABLES DE JAVA
75
En la Tabla 4.2 de la página 75 se indica para cada tipo primitivo el número
de bits que se emplea en su representación y el rango de valores que se puede
almacenar en las variables de estos tipos.
Tipo
int
short
byte
long
boolean
char
float
double
Bits
32
16
8
64
1
16
32
64
Rango
−231 ..231 − 1
−215 ..215 − 1
−27 ..27 − 1
−263 ..263 − 1
n/a
n/a
IEEE
IEEE
Ejemplos
0,1,5,-120,...
0,1,5,-120,...
0,1,5,-120,...
0,1,5,-120,...
false, true
‘a’,‘A’,‘0’,‘*’,...
1.2
1.2
Tabla 4.2: Tipos Primitivos de Datos
4.4.1
Datos de Objetos o Instancia
Son datos propios de cada instancia (objeto) de una clase determinada. Cada
objeto tiene una copia de sus datos. Estos pueden ser variables, métodos.
Se inicializan con el valor por defecto dependiendo del tipo de dato de la
variable.
Cada tipo de dato tiene asociado un valor por defecto de inicialización:
• Integrales (byte, short, int, long): Se inicializan en “0”.
• Flotantes (float, double): Se inicializan en “0,0”.
• Boolean: se inicializan en false.
• Char: se inicializan en /u0000 en formato UNICODE.
4.4.2
Datos de Clase
Son datos generales o globales a la ejecución de un aplicación.
76
CAPÍTULO 4. JAVA
Representan datos que son compartidos por todas las instancias de una
clase y son cargados en memoria antes de que una instancia de la clase sea
creada. Es decir antes de que se instancien nuevos objetos de la clase. Se
declaran con la palabra reservada “static”.
Por ejemplo una variable de clase sería:
public static String mensaje.
Y un ejemplo de la declaración de un método de clase:
public static void leerURL().
4.5
4.5.1
Operadores del Lenguaje Java
Operadores Aritméticos
Son operadores binarios (requieren siempre dos operandos) que realizan las
operaciones aritméticas habituales: suma (+), resta (-), multiplicación (*),
división (/) y resto de la división (%).
4.5.2
Operadores de Asignación
Los operadores de asignación permiten asignar un valor determinado a una
variable. El operador de asignación por excelencia es el operador igual (=).
La forma general de las sentencias de asignación con este operador es:
variable = expresión;
Java dispone de otros operadores de asignación. Se trata de versiones
abreviadas del operador (=) que realizan operaciones “acumulativas” sobre
una variable.
La siguiente Tabla 4.3 de la pág. 77, muestra estos operadores y su equivalencia con el uso del operador igual (=).
4.5. OPERADORES DEL LENGUAJE JAVA
Operador
+=
-=
=*
=/
%=
Utilización
op1 + = op2
op1 - = op2
op1 * = op2
op1 / = op2
op1% = op2
77
ExpresiónEquivalente
op1 = op1 + op2
op1 = op1 - op2
op1 = op1 * op2
op1 = op1 / op2
op1 = op1 % op2
Tabla 4.3: Operadores de asignación.
4.5.3
Operadores Unarios
Los operadores unarios sirven para mantener o cambiar el signo de una variable, constante o expresión numérica. Ellos son el más (+) y menos (-). Su uso
en Java es el estándar de estos operadores.
4.5.4
Operador Instanceof
El operador Instanceof permite saber si un objeto es una instancia o no de
una clase determinada y se utiliza de la siguiente manera:
objectName instanceof className.
Devuelve true o false según el objeto pertenezca o no a la clase.
4.5.5
Operador Condicional
Este operador permite realizar bifurcaciones sencillas, su forma general es la
siguiente:
boolean expresion? res1: res2
donde se evalúa la expresion booleana y si es true devuelve res1, si es false
devuelve res2.
Es el único operador ternario de Java.
78
CAPÍTULO 4. JAVA
4.5.6
Operadores Incrementales
Java dispone del operador incremento (++) y decremento (—). El operador
(++) incrementa en una unidad la variable a la que se aplica, mientras que
(—) la reduce en una unidad. Se pueden utilizar de dos formas:
• Precediendo a la variable de la forma “++i”. En este caso primero se incrementa la variable y luego se utiliza (ya incrementada) en la expresión
en la que aparece.
• Después de la variable de la forma “i++”. En este caso primero se utiliza
la variable en la expresión (con el valor anterior) y luego se incrementa.
En muchos casos estos operadores se utilizan para incrementar una variable
fuera de una expresión. En estos casos ambos operadores son equivalentes. Si
se utilizan en una expresión más complicada, el resultado de utilizar estos
operadores en una u otra de sus formas será diferente.
4.5.7
Operadores Relacionales
Los operadores relacionales sirven para realizar comparaciones de igualdad,
desigualdad y relación de menor o mayor. El resultado de estos operadores
es siempre un valor boolean (true o false) según se cumpla o no la relación
considerada. La siguiente Tabla 4.4 de la pág. 78 muestra los operadores
relacionales de Java.
Operador
>
>=
<
<=
==
! =
Utilización
op1 > op2
op1 >= op2
op1 < op2
op1 <= op2
op1 == op2
op1 != op2
El resultado es true
si op1 es mayor que op2
si op1 es mayor o igual que op2
si op1 es menor que op 2
si op1 es menor o igual que op2
si op1 y op2 son iguales
sio p1 y op2 son diferentes
Tabla 4.4: Operadores relacionales.
4.6. ESTRUCTURAS DE PROGRAMACIÓN
4.5.8
79
Operadores de Concatenación de Caracteres
El operador más (+) también se utiliza para concatenar cadenas de caracteres.
Por ejemplo, para concatenar cadenas puede utilizarse la sentencia:
String msj = “Datos ingresados correctamente”;
System.out.println(“Mensaje: ” + msj);
en donde la leyenda que aparecerá en la consola sería:
“Mensaje: Datos ingresados correctamente”.
4.6
Estructuras de Programación
Las estructuras de programación o estructuras de control permiten tomar decisiones y realizar un proceso repetidas veces. Son las denominadas bifurcaciones y bucles. En la mayoría de los lenguajes de programación, este tipo de
estructuras son comunes en cuanto a concepto, aunque su sintaxis varía de un
lenguaje a otro. La sintaxis de Java coincide prácticamente con la utilizada
en C/C++, lo que hace que para un programador de C/C++ no suponga
ninguna dificultad adicional.
4.6.1
Sentencias o Expresiones
Una expresión es un conjunto variables unidas por operadores. Son órdenes
que se le dan al computador para que realice una tarea determinada.
Una sentencia es una expresión que acaba en punto y coma (;). Se permite
incluir varias sentencias en una línea, aunque lo habitual es utilizar una línea
para cada sentencia. A continuación se muestra un ejemplo de una línea
compuesta de tres sentencias:
i = 0; j = 5; x = i + j;
donde lo habitual sería:
i = 0;
80
CAPÍTULO 4. JAVA
j = 5;
x = i + j;
4.6.2
Comentarios
Existen dos formas diferentes de introducir comentarios entre el código de Java
(en realidad son tres, como pronto se verá). Son similares a la forma de realizar comentarios en el lenguaje C/C++. Los comentarios son tremendamente
útiles para poder entender el código utilizado, facilitando de ese modo futuras
revisiones y correcciones. Además permite que cualquier persona distinta al
programador original pueda comprender el código escrito de una forma más
rápida. Se recomienda acostumbrarse a comentar el código desarrollado. De
esta forma se simplifican también las tareas de estudio y revisión posteriores.
Java interpreta que todo lo que aparece a la derecha de dos barras “//
” en una línea cualquiera del código es un comentario del programador y no
lo tiene en cuenta. El comentario puede empezar al comienzo de la línea o
a continuación de una instrucción que debe ser ejecutada. La segunda forma
de incluir comentarios consiste en escribir el texto entre los símbolos “ /* */
”. Este segundo método es válido para comentar más de una línea de código.
Por ejemplo:
// Esta línea es un comentario de una sola línea
int a=1; // Comentario a la derecha de una sentencia
/* Este tipo de comentarios es para comentar más de una sóla línea,
sólo requiere modificar el comienzo y el final. */
En Java existe además una forma especial de introducir los comentarios
(utilizando /***/ más algunos caracteres especiales) que permite generar automáticamente la documentación sobre las clases y packages desarrollados por el
programador. Una vez introducidos los comentarios, el programa javadoc.exe
(incluido en el JDK) genera de forma automática la información de forma similar a la presentada en la propia documentación del JDK. La sintaxis de estos
comentarios y la forma de utilizar el programa javadoc.exe se puede encontrar
en la información que viene con el JDK.
4.6. ESTRUCTURAS DE PROGRAMACIÓN
4.6.3
81
Bifurcaciones
Las bifurcaciones permiten ejecutar una de entre varias acciones en función
del valor de una expresión lógica o relacional. Se tratan de estructuras muy
importantes ya que son las encargadas de controlar el flujo de ejecución de un
programa. Se exponen dos variantes del de tipo if.
Bifurcación if
Esta estructura permite ejecutar un conjunto de sentencias en función del valor
que tenga la expresión de comparación. Ejemplo: se ejecuta si la expresión de
comparación (error < errorMinimo) tiene valor true:
numero = 58;
if (math.abs(numero) < 10){
System.out.println(“Número de 1 solo dígito”);
} /* fin del if */
Las llaves {} sirven para agrupar en un bloque las sentencias que se han
de ejecutar, y no son necesarias si sólo hay una sentencia dentro del if.
Bifurcación if else
Análoga a la anterior, de la cual es una ampliación. Las sentencias incluidas
en el else se ejecutan en el caso de no cumplirse la expresión de comparación
(false),
Ejemplo:
numero = 58;
if (Math.abs(numero) < 10){
System.out.println(“Número de 1 solo dígito”);
}else{
System.out.println(“Número de 2 dígitos”);
}// fin del else
82
CAPÍTULO 4. JAVA
4.6.4
Bucles
Un bucle se utiliza para realizar un proceso repetidas veces. Se denomina
también lazo o loop. El código incluido entre las llaves {} (opcionales si el
proceso repetitivo consta de una sola línea), se ejecutará mientras se cumplan
unas determinadas condiciones. Hay que prestar especial atención a los bucles
infinitos, hecho que ocurre cuando la condición de finalizar el bucle (booleanExpression) no se llega a cumplir nunca. Se trata de un fallo muy típico,
habitual sobre todo entre programadores poco experimentados.
Bucle while
En el siguiente ejemplo se muestra que se ejecutará la sentencia fin++ mientras
la expresión (capas.charAt(fin)!=‘,’ && capas.charAt(fin)!=-1) sea verdadera.
for (int j=0; j < numeroCapas; j++){
int fin = principio;
try {
while (capas.charAt(fin) != ‘,’ && capas.charAt(fin) != -1){
fin++;
}
}
}
Bucle for
A continuación se podrá apreciar la utilización del bucle for:
/* calcular el nuevo vector de diseño */
for (int i = 0; i < vectorDis.length; i++){
vectorDis[i] = vectorDis[i] + learningRate * S[i];
}
4.6. ESTRUCTURAS DE PROGRAMACIÓN
83
La sentencia int i = 0 (inicialización) se ejecuta al comienzo del for, e
i++ (incremento) después de vectorDis[i] = vectorDis[i] + learningRate * S[i]
(sentencia). La expresión booleana (vectorDis.length) se evalúa al comienzo
de cada iteración; el bucle termina cuando la expresión de comparación toma
el valor false.
Bucle do while
Es similar al bucle while pero con la particularidad de que el control está al
final del bucle (lo que hace que el bucle se ejecute al menos una vez, independientemente de que la condición se cumpla o no). Una vez ejecutadas las
sentencias, se evalúa la condición: si resulta true se vuelven a ejecutar las
sentencias incluidas en el bucle, mientras que si la condición se evalúa a false
finaliza el bucle.
do{
/* calcular el gradiente del vector fijar el vector de diseño */
problema.fijoVector(vectorDis);
/* incrementar el contador de iteraciones*/
step++;
}while (error > errorDeseado && step < iteracionesMaximas);
/* ... hasta que el error sea menor o igual que el deseado o */
/* se alcance el número de iteraciones pasado como argumento */
problema.fijoVector(vectorDis);
Bloque try{...} catch{...} finally{...}
Java incorpora en el propio lenguaje la gestión de errores. El mejor momento
para detectar los errores es durante la compilación. Sin embargo prácticamente
sólo los errores de sintaxis son detectados en esta operación. El resto de los
problemas surgen durante la ejecución de los programas.
84
CAPÍTULO 4. JAVA
En el lenguaje Java, una Exception es un cierto tipo de error o una condición anormal que se ha producido durante la ejecución de un programa.
Algunas excepciones son fatales y provocan que se deba finalizar la ejecución
del programa. En este caso conviene terminar ordenadamente y dar un mensaje explicando el tipo de error que se ha producido. Otras excepciones, como
por ejemplo no encontrar un fichero en el que hay que leer o escribir algo,
pueden ser recuperables. En este caso el programa debe dar al usuario la
oportunidad de corregir el error (dando por ejemplo un nuevo path del fichero
no encontrado).
Los errores se representan mediante clases derivadas de la clase Throwable,
pero los que tiene que chequear un programador derivan de Exception (java.lang.Exception que a su vez deriva de Throwable). Existen algunos tipos
de excepciones que Java obliga a tener en cuenta. Esto se hace mediante el
uso de bloques try, catch y finally.
El código dentro del bloque try está “vigilado”: Si se produce una situación
anormal y se lanza como consecuencia una excepción, el control pasa al bloque
catch que se hace cargo de la situación y decide lo que hay que hacer. Se pueden
incluir tantos bloques catch como se desee, cada uno de los cuales tratará un
tipo de excepción. Finalmente, si está presente, se ejecuta el bloque finally,
que es opcional, pero que en caso de existir se ejecuta siempre, sea cual sea el
tipo de error.
En el caso en que el código de un método pueda generar una Exception
y no se desee incluir en dicho método la gestión del error (es decir los bucles
try/catch correspondientes), es necesario que el método pase la Exception al
método desde el que ha sido llamado. Esto se consigue mediante la adición de
la palabra throws seguida del nombre de la Exception concreta, después de la
lista de argumentos del método. A su vez el método superior deberá incluir
los bloques try/catch o volver a pasar la Exception. De esta forma se puede ir
pasando la Exception de un método a otro hasta llegar al último método del
programa, el método main().
4.7
Servlets
Los servlets son programas de Java que construyen respuestas dinámicas para
el cliente, tal como páginas Web. Los servlets reciben y responden a las
demandas de los clientes Web, normalmente por HTTP.
4.7. SERVLETS
85
Además los servlets son escalables, dando soporte para una multi-aplicación
de configuración del servidor. [18]
Permiten utilizar datos caché, acceso a información de base de datos, y
compartir datos con otros servlets, archivos JSP y (en algunos ambientes) con
los bean empresariales.
Poseen algunas ventajas respecto a los tradicionales programas CGI:
• Independencia de la plataforma. Esto proporciona un menor esfuerzo de
codificación con respecto a soluciones dependientes del servidor web y
de la plataforma.
• Ejecución en paralelo de múltiples peticiones por una sola instancia del
servlet.Tradicionalmente en los programas CGI se ejecuta un proceso
distinto para cada petición, lo que conlleva una gradual degradación del
rendimiento y una necesidad de recursos muy elevada. En un servlet
todas las peticiones se atienden en el mismo proceso por distintos hilos
y una vez que se ha cargado el servlet este permanece en memoria hasta
que se reinicie el servidor.
4.7.1
Estructura de un Servlet
El API Servlet consiste básicamente en dos paquetes:
• javax.servlet
• javax.servlet.http
Todas las clases e interfaces que hay que utilizar en la programación de
servlets están en estos dos paquetes.
Vision General del API de Servlet
La relación entre las clases e interfaces de Java, muy determinada por el concepto de herencia, tal como puede verse en la figura 4.3 de la página 86, se
representan con letra normal las clases y las interfaces con cursiva.
86
CAPÍTULO 4. JAVA
Figura 4.3: Jerarquía y Métodos de las Principales Clases Para Crear Servlets.
La clase GenericServlet es una clase abstracta puesto que su método service() es abstracto. Esta implementa dos interfaces, de las cuales la más
importante es la interface Servlet.
La interface Servlet declara métodos más importantes de cara a la vida de
un servlet: init() que se ejecuta sólo al arrancar el servlet; destroy() que se
ejecuta cuando va a ser destruido y service() que se ejecutará cada vez que el
servlet debe atender una solicitud de servicio.
Cualquier clase que derive de GenericServlet deberá definir el método service(). Este método tiene en su definición dos argumentos correspondientes
a las interfaces ServletRequest y ServletResponse. La primera referencia a un
objeto que describe por completo la solicitud de servicio que se le envía al
servlet. Si la solicitud de servicio viene de un formulairo HTML, a través de
ese objeto se puede acceder a los nombres de los campos y a los valores introducidos por el usuario. El segundo argumento es un objeto con la referencia
a la interface ServletResponse que constituye el camino mediante el cual el
método service() se conecta de nuevo con el cliente y le comunica el resultado
de su solicitud.
La clase HttpServlet ya no es abstracta y dispone de una implementación
o definición del método service(). Dicha implementación detecta el tipo de
servicio o método HTTP que le ha sido solicitado desde el browser y llama
al método adecuado de esa misma clase (doPost(), doGet(), etc.), también
aparecen otras interfaces como ser:
4.7. SERVLETS
87
• La interfaz ServletConfig define métodos que permiten pasar al servlet
información sobre sus parametros de inicialización.
• La interface ServletContext permite a los servlets acceder a información
sobre el entorno en que se estan ejecutando.
Principios de Codificación de Servlet
Para crear un servlet de HTTP, es necesario extender las clases:
javax.servlet.HttpServlet y sustituir cualquier método que se desee implementar en el servlet. Por ejemplo, un servlet reemplaza el método doGet para
manejar las demandas Get de los clientes.
El HttpServletRequest representa los requerimientos de un cliente. Este
objeto da acceso al servlet, a la información incluida como datos en formato
HTML, encabezados HTTP, etc.
El HttpServletResponse representa la respuesta del servlet.
El servlet usa este objeto para devolverle datos al cliente como errores
de HTTP (200, 404, y otros), encabezados de respuesta (Content-Type, SetCookie, y otros), y datos de salida para escribir cadenas de salida de respuesta
o salida impresa.
El principio de un servlet podría parecerse al siguiente ejemplo:
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class ServletPrueba extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException{
Ciclo de Vida del Servlet
Un Servlet de Java tiene un ciclo de vida que determina como el servlet es
cargado e inicializado, como recibe y responde a las peticiones y como sale
88
CAPÍTULO 4. JAVA
fuera de servicio.
Las clases javax.servlet.http.HttpServlet definen métodos tales como:
• Iniciar un servlet.
• Solicitar servicios.
• Quitar un servlet del servidor.
Éstos son conocidos como métodos del ciclo de vida y son llamados en la
siguiente secuencia:
• Se construye el servlet.
• Se inicializa con el método init().
• Se manejan llamadas de los clientes al método de servicio.
• Se saca el servlet de servicio.
• Se destruye con el método destruir.
• Se finaliza el servlet y la basura es recolectada.
El ciclo de vida de un Servlet se puede apreciar en la figura 4.4 de la página
89.
4.7.2
Instanciación e Inicialización
El motor del servlet (la función del Servidor de Aplicaciones que procesa servlets, archivos JSP, y otros tipos de server-side incluyendo codificación) crea
una instancia del servlet. El motor del servlet crea el objeto de configuración
del servlet y lo usa para pasar los parámetros de inicialización del servlet al
método init(). La inicialización de los parámetros persiste hasta que el servlet se destruye y es aplicada a todas las invocaciones de ese servlet hasta
destruirse.
Si la inicialización tiene éxito, el servlet está disponible para el servicio. Si
la inicialización falla, el motor del servlet descarga el servlet. El administrador
4.7. SERVLETS
89
Figura 4.4: Ciclo de Vida de un Servlet.
90
CAPÍTULO 4. JAVA
puede inhabilitar una aplicación y el servlet para el servicio. En tales casos,
la aplicación y el servlet permanecen inhabilitados hasta que el administrador
los habilite.
4.7.3
Servicio de Demanda
Una demanda del cliente llega al servidor de aplicaciones. El motor del servlet
crea un objeto demanda y un objeto respuesta. El motor del servlet invoca
al método de servicio del servlet, procesa el requerimiento y usa métodos del
objeto respuesta para crear la respuesta para el cliente.
El método de servicio recibe información sobre el requerimiento del objeto
demanda, procesa el requerimiento, y usa los métodos del objeto respuesta
para crear la contestación para el cliente. El método de servicio puede invocar
otros métodos para procesar el requerimiento, tales como doGet (), doPost (),
o métodos del usuario.
4.7.4
Terminación
El motor del servlet invoca al método destroy () del servlet cuando apropia
y descarga el servlet. La Máquina Virtual de Java realiza la recolección de
basura después de la destrucción del servlet.
Cuando el contenedor Web ya no necesita que el servlet o una nueva instancia del servlet se recarguen, invoca al método destroy() del servlet. El
contenedor Web también puede llamar al método destroy() si el motor necesita conservar recursos o una llamada pendiente a un método service() del
servlet excediendo el timeout. La Máquina Virtual de Java realiza recolección
de basura después del destroy.
4.7.5
Java Server Faces
Java Server Pages (JSP) combinan HTML con fragmentos de Java para producir páginas web dinámicas.
Cada página es automáticamente compilada a servlet por el motor de JSP
, en primer lugar es recogida y a continuación ejecutada. JSP tiene gran
variedad de formas para comunicarse con las clases de Java, servlets, applets
4.7. SERVLETS
91
y el servidor web; por esto se puede aplicar una funcionalidad a nuestra web
a base de componentes.
Una página JSP es un archivo de texto simple que consiste en contenido
HTML o XML con elementos JSP. Cuando un cliente pide una página JSP
del sitio web y no se ha ejecutado antes, la página es inicialmente pasada al
motor de JSP, el cual compila la página convirtiéndola en Servlet, la ejecuta
y devuelve el contenido de los resultados al cliente.
El código fuente de una página JSP incluye:
• Directivas: Dan información global de la página, por ejemplo, importación de estamentos, página que majena los errores o cuando la página
forma parte de una sesión.
• Declaraciones: Sirven para declarar métodos y variables.
• Scripts de JSP: Es el código Java embebido en la página.
• Expresiones de JSP: Formatea las expresiones como cadenas para incluirlas en la página de salida.
Directivas
Una directiva de JSP es un estamento que proporciona la información del
motor de JSP para la página que la pide. Su sintaxis general es <%@ directiva
{atributo =“valor”} %> dónde la directiva debe tener un número de atributos.
Algunos ejemplos son:
— Page: Información para la página.
— Include: Incluye archivos completos palabra por palabra.
— Taglib: La dirección de la librería de tags que se usará en la página.
La directiva Page posee varios atributos:
— language=“java”: Comunica al servidor el lenguaje que va a ser
utilizado en el archivo. Java es el único posible en esta especificación.
92
CAPÍTULO 4. JAVA
— extends=“package.class”: La variale extends, define la clase padre
del servlet generado. Normalmente no es necesario utilizar otras
que no sean las clases base del proveedor.
— import=“package.*, package.class”: Sirve para especificar los paquetes y clases que se quieran utilizar.
— session=“true|false”: Por defecto session vale true, manteniendo los
datos de las sesión para la página.
— isThreadSafe=“true|false”: Por defecto vale true, le hace señales
al motor de JSP para que múltiples pedidos del cliente puedan ser
tomados como uno.
— info=“text”: Información en la página a la que puede accederse a
través del método Servlet.getServletInfo().
— errorPage=”pagina_error”: Página que manejará las excepciones
de errores.
Declaraciones
Una declaración de JSP, puede definirse como una definición de variables
y métodos a nivel de clase que son usadas en la página.
Un bloque de declaraciones típico sería <%! declaración %>
Un ejemplo de declaración de script sería el siguiente:
<HTML>
<HEAD>
<TITLE>Página simple JSP</TITLE>
</HEAD>
<BODY>
<%!
String strCadena = ”x”;
int intContador = 0;
%>
</BODY>
4.7. SERVLETS
93
</HTML>
Scripts de JSP
Los Scripts son bloques de código Java residentes entre los tags <% y %>.
Estos bloques de código estarán dentro del servlet generado incluídos en el
método _jspService(). Los Scripts pueden acceder a cualquier variable o Bean
que haya sido declarado. También hay algunos objetos implícitos disponibles
para los Scripts desde entorno del Servlet.
Algunos de ellos pueden verse a continuación:
• request: Es la petición del cliente. Es normalmente una subclase de la
clase HttpServletRequest.
• response: Es la página JSP de respuesta y es una subclase de HttpServletResponse. Los atributos de la página y los objetos implícitos necesitan
ser accesibles a través de API, para permitir al motor de JSP compilar
la página. Pero cada servidor tiene implementaciones específicas de cada
uno de esos atributos y objetos.
• pageContext: Esta clase PageContext es inicializada con los objetos response y request y algunos atributos de la directiva de la página (erropage,
session, buffer and autoflush) y facilita los otros objetos implícitos para
la página de petición.
• session: El objeto de sesión HTTP asociado a la petición.
• application: Lo que devuelve el servlet cuando se llama a getServletConfig().getContext().
• page: Es la forma que tiene la página para referirse a si misma. Se usa
como alternativa al objeto this.
El siguiente fragmento de código muestra como obtener el valor de un
parámetro mediante el objeto request, y como pasarlo a una cadena para
mostrarlo en pantalla.
<%
String strNombre = request.getParameter(“nombre”);
94
CAPÍTULO 4. JAVA
out.println(strNombre);
%>
Expresiones JSP
Las expresiones son una magnífica herramienta para insertar código embebido dentro de la página HTML. Cualquier cosa que esté entre los tags <%= y
%> será evaluado, convertido a cadena y posteriormente mostrado en pantalla.
La conversión desde el tipo inicial a String es manejada autómaticamente.
Es importante remarcar que la expresión no termina en punto y coma (;)
. Esto es así porque el motor de JSP, pondrá la expresión automáticamente
entre out.println().
Las expresiones JSP permiten parametrizar las páginas HTML (es parecido a cuando se parametriza una consulta SQL pero difieren la forma de los
valores).
Una y otra vez , en el código de la página HTML, ser verán bucles o condiciones usando código Java, simplemente empezando y acabando las condiciones
o bucles entre los tags <% y %>.
Un ejemplo sería:
<% for (int i=0;i<5;i++) { %>
<BR>El valor del contador es <%=i%>
<% } %>
Modelos de Acceso JSP
Se puede acceder a los archivos JSP de dos maneras:
El browser envía un requerimiento para los archivos JSP.
Los archivos JSP acceden a los beans u otros componentes que generan
contenido dinámico para ser enviado al browser como se muestra en la figura
4.5 de la página 95.
Cuando el servidor Web recibe un requerimiento para un archivo JSP, el
servidor envía ese requerimiento al servidor de aplicaciones. El servidor de
4.7. SERVLETS
95
Figura 4.5: Requerimiento de un archivo JSP.
Figura 4.6: Requerimiento de un Servlet
aplicaciones analiza el archivo JSP y genera código fuente de Java que se
compila y se ejecuta como un servlet.
El requerimiento se envía a un servlet que genera contenido dinámico y
llama a un archivo JSP para enviar el contenido a un browser, como se muestra
en la figura 4.6 de la página 95.
Este modelo de acceso facilita la generación de contenido separado del
despliegue de contenido.
El servidor de aplicaciones proporciona un juego de métodos en el objeto
HttpServiceRequest object y el objeto HttpServiceResponse. Estos métodos
permiten una invocación de servlet para colocar un objeto (normalmente un
96
CAPÍTULO 4. JAVA
bean) en un objeto demanda y pasa ese requerimiento a otra página (normalmente un archivo JSP) para el despliegue. La página invocada recupera el
beans del objeto demanda y genera el HTML que recibe el cliente.
4.7.6
Desarrollando Aplicaciones
Para WebSphere Application Server, las aplicaciones son combinaciones de
bloques que trabajan conjuntamente para el logro de una función de la lógica
comercial. Las aplicaciones Web son grupos de uno o más servlets, más el
contenido estático.
Aplicaciones Web = servlets + archivos JSP + archivos XML + archivos
HTML + gráficos.
El modelo de programación de WebSphere Application Server está basado
en la plataforma Java de Sun (J2SE). El ambiente J2SE soporta la base para
construir redes centrales de aplicaciones empresariales para correr sobre una
variedad de sistemas. El software J2SE consiste en los Java SDK Standard
Edition y el Java Runtime Environment (JRE ) Standard Edition.
Capítulo 5
Java 2 Micro Edition
5.1
Introducción
Para empezar se puede decir que Java 2 Micro Edition o J2ME es la versión
del lenguaje Java que está orientada al desarrollo de aplicaciones para dispositivos pequeños con capacidades restringidas tanto en pantalla gráfica, como
de procesamiento y memoria (teléfonos móviles, PDA’s, Handhelds, Pagers,
etc.).
Esta versión de Java fue presentada en 1999 por Sun Microsystems con el
propósito de habilitar aplicaciones Java para pequeños dispositivos. En esta
presentación lo que realmente se mostró fue una nueva máquina virtual Java
o JVM (Java Virtual Machine) que podía ejecutarse en dispositivos Palm.
La tardía aparición de esta tecnología puede ser debido a que las necesidades de los usuarios de telefonía móvil han cambiado mucho en estos últimos
años y cada vez demandan más servicios y prestaciones por parte tanto de los
terminales como de las compañías. Además el uso de esta tecnología depende
del asentamiento en el mercado de otras, como GPRS, íntimamente asociada
a J2ME y que no ha estado al alcance hasta hace poco. J2ME es la tecnología
del futuro para la industria de los dispositivos móviles.
97
98
CAPÍTULO 5. JAVA 2 MICRO EDITION
5.1.1
Comparación de Versiones
Sun Microsystems, con el objetivo de cubrir las necesidades de todos los usuarios creó distintas versiones de Java de acuerdo a las necesidades de cada
uno, por lo cual existe el paquete Java 2 que se puede dividir en 3 ediciones
distintas:
• J2SE (Java Standard Edition) orientada al desarrollo de aplicaciones
independientes de la plataforma.
• J2EE (Java Enterprise Edition) orientada al entorno empresarial.
• J2ME (Java Micro Edition) orientada a dispositivos con capacidades restringidas.
Algunas de las características de cada una de las versiones son:
1. Java 2 Platform, Standard Edition (J2SE): Esta edición de Java es la
que en cierta forma recoge la iniciativa original del lenguaje Java. Tiene
las siguientes Características:
• Inspirado inicialmente en el lenguaje C++, pero con componentes
de alto nivel, como soporte nativo de strings y recolector de basura
(garbage colector ).
• Código independiente de la plataforma, precompilado a bytecodes
intermedio y ejecutado en el cliente por una JVM (Java Virtual
Machine).
• Modelo de seguridad tipo sandbox proporcionado por la JVM.
• Abstracción del sistema operativo subyacente mediante un juego
completo de APIs de programación.
• Contiene el conjunto básico de herramientas usadas para desarrollar Java Applets, así cómo las APIs orientadas a la programación
de aplicaciones de usuario final: Interfaz gráfica de usuario, multimedia, redes de comunicación.
2. Java 2 Platform, Enterprise Edition (J2EE): Esta versión está orientada
al entorno empresarial. El software empresarial tiene unas características
propias marcadas:
5.1. INTRODUCCIÓN
99
— Está pensado no para ser ejecutado en un equipo, sino para
ejecutarse sobre una red de ordenadores de manera distribuida
y remota mediante EJBs (Enterprise Java Beans).
— Esta edición está orientada especialmente al desarrollo de servicios web, servicios de nombres, persistencia de objetos, XML,
autenticación, APIs para la gestión de transacciones, etc.
— El cometido de esta especificación es ampliar la J2SE para dar
soporte a los requisitos de las aplicaciones de empresa.
3. Java 2 Platform, Micro Edition (J2ME): Esta versión de Java está enfocada a la aplicación de la tecnología Java en dispositivos electrónicos
con capacidades computacionales y gráficas muy reducidas, tales como
teléfonos móviles, PDAs o electrodomésticos inteligentes:
— Esta edición tiene unos componentes básicos que la diferencian de
las otras versiones, como el uso de una máquina virtual denominada
KVM (Kilo Virtual Machine, debido a que requiere sólo unos pocos
Kilobytes de memoria para funcionar) en vez del uso de la JVM
clásica.
La figura 5.1 de la página 100 muestra la arquitectura de Java2.
En la actualidad se puede decir que Java no es sólo un simple lenguaje de
programación sino un conjunto de tecnologías que engloba a todos los aspectos
de la computación con dos elementos en común:
• El código fuente en lenguaje Java es compilado a código intermedio
interpretado por una Java Virtual Machine (JVM ), por lo que el código
ya compilado es independiente de la plataforma.
• Todas las tecnologías comparten un conjunto más o menos amplio de
APIs básicas del lenguaje, agrupadas principalmente en los paquetes
java.lang y java.io.
Debido a que la edición estándar de APIs de Java ocupa 20 MB aproximadamente y los dispositivos pequeños disponen de una cantidad de memoria
mucho más reducida, J2ME contiene una mínima parte de las APIs de Java.
Concretamente, J2ME usa 37 clases de la plataforma J2SE provenientes de
los paquetes java.lang, java.io, java.util. Esta parte de la API que se mantiene
fija forma parte de lo que se denomina “configuración” [19].
100
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.1: Arquitectura de la Plataforma Java 2 de Sun.
Otra diferencia con la plataforma J2SE viene dada por el uso de una
máquina virtual distinta de la clásica JVM denominada KVM. Esta KVM
tiene unas restricciones que hacen que no posea todas las capacidades incluidas
en la JVM clásica.
J2ME representa una versión simplificada de J2SE. Sun separó estas dos
versiones ya que J2ME está pensada para dispositivos con limitaciones de
proceso y capacidad gráfica. También separó J2SE de J2EE porque este
último exigía unas características muy pesadas o especializadas de E/S, trabajo
en red, etc. Por tanto, separó ambos productos por razones de eficiencia.
Hoy, J2EE es un superconjunto de J2SE pues contiene toda la funcionalidad de éste y más características, así como J2ME es un subconjunto de J2SE
(excepto por el paquete javax.microedition) ya que contiene varias limitaciones
con respecto a J2SE.
Sólo de manera muy simplista se puede considerar a J2ME y J2EE como
versiones reducidas y ampliadas de J2SE respectivamente (ver fig. 5.2 de la
pág. 101): en realidad cada una de las ediciones está enfocada a ámbitos de
aplicación muy distintos [19].
5.1. INTRODUCCIÓN
101
Figura 5.2: Ubicación de las Tecnologías Java.
5.1.2
Algunas Consideraciones al Desarrollar en J2ME
Algunas consideraciones son las siguientes:
• Prácticamente los dispositivos móviles y más aún los nuevos teléfonos
celulares ya poseen capacidad de ejecución de aplicaciones desarrolladas
en J2ME. Existen algunas ventajas y restricciones o desventajas respecto
a otras tecnologías [20].
• Algunas ventajas en comparación de J2ME con respecto al lenguaje C son:
∗ Multiplataforma: Significa 1 programa - se puede ejecutar en
n móviles.
∗ Seguridad: El usuario está protegido.
∗ Descarga OTA (Over The Air).
∗ Desarrollo rápido.
— Inconveniente:
∗ Alejamiento del hardware. No puede accederse a ciertos recursos del teléfono si éste no incorpora el API correspondiente.
102
CAPÍTULO 5. JAVA 2 MICRO EDITION
• Las aplicaciones móviles que poseen conectividad a Internet pueden utilizar la tecnología GPRS, en la cual se tarifa al usuario por Kbytes recibidos y enviados, es por esto que es importante minimizar la cantidad
de información intercambiada. Las relaciones que existen de acuerdo
al tipo de información intercambiada y el volumen de la misma son las
siguientes:
— Página html - 10-100Kb.
— Página wml 1-10Kb.
— Información “pura” - 0.1 - 1kb.
• ¿Cuándo interesa desarrollar en J2ME ?:
— Cuando no hay tráfico de información, por ejemplo: juegos, conversores de unidades.
— Cuando el tráfico de información puede minimizarse con J2ME .
— Cuando pueden almacenarse datos localmente en el móvil y sólo
transferir algunos otros como los resultados [20].
5.2
Componentes de J2ME
Los componentes que forman parte de la tecnología J2ME son:
• Máquina virtual: Existe una serie de máquinas virtuales java con diferentes requisitos, cada una para diferentes tipos de pequeños dispositivos.
• Configuraciones: Son un conjunto de clases básicas orientadas a conformar el corazón de las implementaciones para dispositivos de características específicas:
— Connected Limited Device Configuration (CLDC) enfocada a dispositivos con restricciones de procesamiento y memoria.
— Connected Device Configuration (CDC) enfocada a dispositivos con
más recursos [20].
• Perfiles: Son unas bibliotecas Java de clases específicas orientadas a
implementar funcionalidades de más alto nivel para familias específicas
de dispositivos.
5.2. COMPONENTES DE J2ME
5.2.1
103
Máquinas Virtuales J2ME
Una máquina virtual de Java (JVM ) es un programa encargado de interpretar
código intermedio (bytecode) de los programas Java precompilados a código
máquina ejecutable por la plataforma, efectuar las llamadas pertinentes al
sistema operativo subyacente y observar las reglas de seguridad y corrección
de código definidas para el lenguaje Java. De esta forma, la JVM proporciona
al programa Java independencia de la plataforma con respecto al hardware y
al sistema operativo subyacente.
Las implementaciones tradicionales de JVM son, en general, muy pesadas
en cuanto a memoria ocupada y requerimientos computacionales. J2ME define
varias JVMs de referencia adecuadas al ámbito de los dispositivos electrónicos
que, en algunos casos, suprimen algunas características con el fin de obtener
una implementación menos exigente.
La tecnología J2ME ha definido dos configuraciones, CDC y CLDC, cada
una de ellas con características propias, en consecuencia, para cada tipo de
configuración se definió una máquina virtual distinta. La VM (Virtual Machine) correspondiente a CLDC se denomina KVM y la de la configuración
CDC se denomina CVM.
A continuación se detallan las principales características de cada una de
ellas:
KVM
Se corresponde con la máquina virtual más pequeña. Su nombre KVM
proviene de Kilobyte (que hace referencia a la baja ocupación de memoria).
Se trata de una implementación de máquina virtual reducida y especialmente
orientada a dispositivos con bajas capacidades computacionales y de memoria,
como ser los teléfonos celulares.
La KVM está escrita en el lenguaje de programación C y posee algunas
características particulares como:
• Pequeña, con una carga de memoria entre los 40Kb y los 80 Kb, dependiendo de la plataforma y las opciones de compilación.
• Alta portabilidad.
• Modulable.
104
CAPÍTULO 5. JAVA 2 MICRO EDITION
• Lo más completa y rápida posible y sin sacrificar características para las
que fue diseñada.
Sin embargo, existen algunas limitaciones debido a su bajo consumo de
memoria respecto la maquina virtual clásica:
• No hay soporte para tipos en coma flotante. Esta limitación está presente porque los dispositivos carecen del hardware necesario para estas
operaciones.
• No existe soporte para JNI (Java Native Interface) debido a los recursos
limitados de memoria.
• No existen cargadores de clases (class loaders) definidos por el usuario.
• No se permiten los grupos de hilos o hilos daemon. Si se necesita la
utilización de grupos de hilos se tendrán que utilizar los objetos colección
para almacenar cada hilo.
• No existe la finalización de instancias de clases. No existe el método
Object.finalize().
• Limitada capacidad para el manejo de excepciones debido a que el manejo de éstas depende en gran parte de las APIs de cada dispositivo por
lo que son éstos los que controlan la mayoría de las excepciones.
Otro tema en cuestión que se puede encontrar en ésta maquina virtual
más pequeña es la verificación de clases. El verificador de clases estándar
de Java es demasiado grande para la KVM, de hecho es más grande que la
propia KVM y el consumo de memoria es excesivo, más de 100Kb para las
aplicaciones típicas.
Este verificador de clases es el encargado de rechazar las clases no válidas
en tiempo de ejecución. Este mecanismo verifica los bytecodes de las clases
Java realizando las siguientes comprobaciones:
• Ver que el código no sobrepase los límites de la pila de la VM.
• Comprobar que no se utilizan las variables locales antes de ser inicializadas.
5.2. COMPONENTES DE J2ME
105
Figura 5.3: Proceso de Verificación.
• Comprobar que se respetan los campos, métodos y los modificadores de
control de acceso a clases.
Por esta razón los dispositivos que usen la configuración CLDC y KVM
introducen un algoritmo de verificación de clases en dos pasos. Este proceso
puede apreciarse gráficamente en la figura 5.3 de la página 105.
CVM
• La CVM (Compact Virtual Machine) ha sido tomada como máquina virtual Java de referencia para la configuración CDC y soporta las mismas
características que la máquina virtual clásica. Está orientada a dispositivos electrónicos con procesadores de 32 bits de gama alta y en torno a
2 Mb o más de memoria RAM.
Las características que presenta ésta máquina virtual son:
1. Sistema de memoria avanzado.
2. Tiempo de espera bajo para el recolector de basura.
3. Separación completa de la VM del sistema de memoria.
106
CAPÍTULO 5. JAVA 2 MICRO EDITION
4. Recolector de basura modularizado.
5. Portabilidad.
6. Rápida sincronización.
7. Ejecución de las clases Java fuera de la memoria de sólo lectura (ROM).
8. Soporte nativo de hilos.
9. Baja ocupación en memoria de las clases.
10. Proporciona soporte e interfaces para servicios en sistemas operativos de
tiempo real.
11. Conversión de hilos Java a hilos nativos.
12. Soporte para todas las características de Java2 v1.3 y librerías de seguridad, referencias débiles, Interfaz Nativa de Java (JNI ), invocación
remota de métodos (RMI ), Interfaz de depuración de la máquina virtual
(JVMDI).
5.2.2
Configuraciones
Una configuración es el conjunto mínimo de APIs Java que permiten desarrollar aplicaciones para un grupo de dispositivos. Estas APIs describen las
características básicas, comunes a todos los dispositivos:
• Características soportadas del lenguaje de programación Java.
• Características soportadas por la máquina virtual Java.
• Bibliotecas básicas de Java y APIs soportadas.
Como se ha mencionado con anterioridad, existen dos configuraciones, la
que está orientada a dispositivos con limitaciones computacionales y de memoria que se denomina CLDC y la configuración que se encuentra orientada
a dispositivos con menos restricciones en cuanto a capacidad de cómputo y
memoria, la cual se denomina CDC .
A continuación se presentan las características más relevantes de cada una:
5.2. COMPONENTES DE J2ME
107
• Configuración de dispositivos con conexión, CDC (Conected Device Configuration):
— La CDC está orientada a dispositivos con cierta capacidad computacional y de memoria. Por ejemplo, decodificadores de televisión
digital, televisores con Internet, algunos electrodomésticos y sistemas de navegación en automóviles.
— CDC usa una máquina virtual Java similar en sus características
a una de J2SE, pero con limitaciones en el apartado gráfico y de
memoria del dispositivo.
— La CDC está enfocada a dispositivos con las siguientes capacidades:
— Procesador de 32 bits.
— 2 Mb o más de memoria total, incluyendo memoria RAM y
ROM.
— Conectividad a algún tipo de red.
— Poseer la funcionalidad completa de la Máquina Virtual Java
2.
— La CDC está basada en J2SE v1.3 e incluye varios paquetes Java
de la edición estándar. Las peculiaridades de la CDC están contenidas principalmente en el paquete javax.microedition.io, que incluye
soporte para comunicaciones http y basadas en datagramas [19].
La tabla 5.1 de la pág. 108 muestra las librerías incluidas en la CDC.
• Configuracion de dispositivos limitados con conexión, CLDC (Conected
Limited Device Configuration):
— La CLDC está orientada a dispositivos dotados de conexión y con limitaciones en cuanto a capacidad gráfica, cómputo y memoria. Como por ejemplo teléfonos móviles, buscapersonas (Pagers), PDAs,
organizadores personales, etc.
— Las restricciones que contiene la configuración CLDC vienen dadas
por la utilización de la máquina virtual o KVM.
— Los dispositivos que usan CLDC deben cumplir los siguientes requisitos:
108
CAPÍTULO 5. JAVA 2 MICRO EDITION
Nombre del paquete
CDC
java.io
java.lang
java.lang.ref
java.lang.reflect
java.math
java.net
java.security
java.security.cert
java.text
java.util
java.util.jar
java.util.zip
javax.microedition.io
Descripción
Clases y paquetes estándar de E/S
Clases e interfaces de la máquina virtual
Clases de referencia
Clases e interfaces de reflectión
Paquete de matemáticas
Clases e interfaces de red
Clases e interfaces de seguridad
Clases de certificados de seguridad
Paquete de texto
Clases de utilidades estándar
Clases y utilidades para archivos JAR
Clases y utilidades para archivos
ZIP y comprimidos
Clases e interfaces para conexión genérica CDC
Tabla 5.1: Librerías de configuración CDC.
∗ Disponer entre 160 Kb y 512 Kb de memoria total disponible.
Como mínimo se debe disponer de 128 Kb de memoria no volátil para la máquina virtual Java y las bibliotecas CLDC, y 32
Kb de memoria volátil para la máquina virtual en tiempo de
ejecución.
∗ Procesador de 16 o 32 bits con al menos 25 Mhz de velocidad.
∗ Tener conexión a algún tipo de red, normalmente sin cable, con
conexión intermitente y ancho de banda limitado.
∗ Ofrecer bajo consumo, debido a que éstos dispositivos trabajan con suministro de energía limitado, normalmente baterías
recargables.
— La CLDC aporta las siguientes funcionalidades a los dispositivos:
∗ Un subconjunto del lenguaje Java y todas las restricciones de
su máquina virtual (KVM ).
∗ Un subconjunto de las bibliotecas del núcleo de Java.
∗ Soporte para acceso a redes.
∗ Soporte para E/S básica.
5.2. COMPONENTES DE J2ME
109
∗ Seguridad.
La tabla 5.2 de la pág. 109 muestra las librerías incluidas en la CLDC.
Nombre del paquete CLDC
java.io
java.lang
java.util
javax.microedition.io
Descripción
Clases y paquetes estándar de E/S
Clases e interfaces de la máquina virtual
Clases e interfaces, utilidades estándar
Clases e interfaces de conexión genérica
Tabla 5.2: Librerías de configuración CLDC.
5.2.3
Perfiles
Un perfil es el que define las APIs que controlan el ciclo de vida de la aplicación,
interfaz de usuario, etc. Concretamente, un perfil es un conjunto de APIs
orientado a un ámbito de aplicación determinado.
Los perfiles identifican un grupo de dispositivos por la funcionalidad que
proporcionan (ya sean electrodomésticos, teléfonos móviles, etc.) y el tipo de
aplicaciones que se ejecutarán en ellos.
Las librerías de la interfaz gráfica son un componente muy importante en
la definición de un perfil. Se pueden encontrar grandes diferencias entre las
interfaces, desde el menú textual de los teléfonos móviles hasta los táctiles de
los PDAs.
El perfil establece unas APIs que definen las características de un dispositivo, mientras que la configuración hace lo propio con una familia de ellos.
Esto hace que a la hora de construir una aplicación se cuente tanto con las
APIs del perfil como de la configuración.
Anteriormente se mencionó que para una configuración determinada se
usaba una Máquina Virtual Java específica. Teníamos que con la configuración CDC se utilizaba la CVM y que con la configuración CLDC se utilizaba
la KVM. Con los perfiles ocurre lo mismo. Existen unos perfiles que se construirán sobre la configuración CDC y otros que se construirán sobre la CLDC.
110
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.4: Entorno de Ejecución de J2ME.
Para la configuración CDC se encuentran los siguientes perfiles:
• Fundation Profile.
• Personal Profile.
• RMI Profile.
Y para la configuración CLDC se encuentran los siguientes:
• PDA Profile.
• Mobile Information Device Profile (MIDP).
En la figura 5.4 de la página 110 se puede ver cómo quedaría el esquema
del entorno de ejecución al completo.
A continuación se describirá con más detenimiento cada uno de estos perfiles:
5.2. COMPONENTES DE J2ME
111
Foundation Profile: Este perfil define una serie de APIs sobre la CDC
orientadas a dispositivos que carecen de interfaz gráfica como, por ejemplo,
decodificadores de televisión digital [19].
Este perfil incluye gran parte de los paquetes de la J2SE, pero excluye
totalmente los paquetes que conforman la interfaz gráfica de usuario (GUI )
de J2SE, concretamente los paquetes “java.awt” Abstract Windows Toolkit
(AWT ) y “java.swing”.
Los paquetes que forman parte del Foundation Profile se muestran en la
tabla 5.3 de la página. 111.
Paq. del Fundation Profile
java.lang
java.util
java.net
java.io
java.text
java.segurity
Descripción
Soporte del lenguaje Java
Añade soporte completo para
zip y otras funcionalidades
Incluye sockets TCP/IP
y conexiones HTTP
Clases Reader y Writer de J2SE
Incluye soporte para internacionalización
Incluye códigos y certificados
Tabla 5.3: Librerías del Foundation Profile.
Personal Profile: Es un subconjunto de la plataforma J2SE versión 1.3,
proporciona un completo soporte gráfico AWT .
El objetivo es el de dotar a la configuración CDC de una interfaz gráfica
completa, con capacidades web y soporte de applets Java.
Este perfil requiere una implementación del perfil Foundation Profile.
La tabla 5.4 de la página 112 muestra los paquete que conforman el perfil.
RMI Profile: Este perfil requiere una implementación del Foundation
Profile. El perfil RMI soporta un subconjunto de las APIs J2SE v1.3 RMI.
Algunas características de estas APIs se han eliminado del perfil RMI debido
a las limitaciones de cómputo y memoria de los dispositivos.
Las siguientes propiedades se han eliminado del J2SE RMI v1.3 :
112
CAPÍTULO 5. JAVA 2 MICRO EDITION
Paq. del Personal
Profile
java.applet
java.awt
java.awt.datatransfer
java.awt.event
java.awt.font
java.awt.im
java.awt.im.spi
java.awt.image
java.beans
javax.microedition.xlet
Descripción
Clases necesarias para crear applets
Clases para crear GUIs con AWT
Clases e interfaces para transmitir
datos entre aplicaciones
Clases e interfaces para manejar
eventos AWT
Clases e interfaces para la
manipulación de fuentes
Clases e interfaces para definir
métodos editores de entrada
Interfaces que añ aden el desarrollo de métodos
editores de entrada para cualquier entorno
de ejecución Java
Clases para crear y modificar imágenes
Clases que soportan JavaBeans
Interfaces que usa el Personal Profile
para la comunicación
Tabla 5.4: Librerías del Personal Profile.
5.2. COMPONENTES DE J2ME
113
• Java.rmi.server.disableHTTP.
• Java.rmi.activation.port.
• Java.rmi.loader.packagePrefix.
• Java.rmi.registry.packagePrefix.
• Java.rmi.server.packagePrefix
PDA Profile: Está construido sobre CLDC. Pretende abarcar PDAs de
gama baja, tipo Palm, con una pantalla y algún tipo de puntero (ratón o lápiz)
y una resolución de al menos 20000 pixeles.
Mobile Information Device Profile (MIDP): Este perfil está construido sobre la configuración CLDC. MIDP fue el primer perfil definido para
esta plataforma.
Este perfil está orientado para dispositivos con las siguientes características:
• Reducida capacidad computacional y de memoria.
• Conectividad limitada (en torno a 9600 bps).
• Capacidad gráfica muy reducida (mínimo un display de 96x54 pixels).
• Entrada de datos alfanumérica reducida.
• 128 Kb de memoria no volátil para componentes MIDP.
• 8 Kb de memoria no volátil para datos persistentes de aplicaciones.
• 32 Kb de memoria volátil en tiempo de ejecución para la pila Java.
Los tipos de dispositivos que se adaptan a estas características son: teléfonos móviles, buscapersonas (pagers) o PDAs de gama baja con conectividad.
El perfil MIDP especifica las APIs relacionadas con:
• La aplicación (semántica y control de la aplicación MIDP).
• Interfaz de usuario.
114
CAPÍTULO 5. JAVA 2 MICRO EDITION
• Almacenamiento persistente.
• Trabajo en red.
• Temporizadores.
Las aplicaciones realizadas utilizando MIDP reciben el nombre de MIDlets
(por simpatía con APPlets). Se puede decir que un MIDlet es una aplicación
Java realizada con el perfil MIDP sobre la configuración CLDC.
En la tabla 5.5 de la página 114 se pueden apreciar cuáles son los paquetes
que están incluidos en el perfil MIDP.
Paq. del MIDP
javax.microedition.lcdui
javax.microedition.rms
javax.microedition.midlet
javax.microedition.io
java.io
java.lang
java.util
Descripción
Clases e interfaces para GUIs
Soporte para el almacenamiento
persistente del dispositivo
Clases de definición de la aplicación
Clases e interfaces de conexión genérica
Clases e interfaces de E/S básica
Clases e interfaces de la máquina virtual
Clases e interfaces de utilidades estándar
Tabla 5.5: Librerías del MIDP Profile.
5.3
Requerimientos Funcionales Para Detectar una
Aplicación J2ME
Los dispositivos deben proporcionar mecanismos mediante los cuales se puedan encontrar los MIDlets que se desean descargar. En algunos casos, se
pueden encontrar los MIDlets a través de un navegador WAP o a través de
una aplicación residente escrita específicamente para identificar MIDlets.
Otros mecanismos como Bluetooth, cable serie, etc, pueden ser soportados
por el dispositivo y a partir de estas conexiones se pueden instalar aplicaciones
(MIDlets).
5.4. LOS MIDLETS
115
El programa encargado de manejar la descarga y ciclo de vida de los MIDlets en el dispositivo se llama Gestor de Aplicaciones o AMS (Application
Management Software).
Un dispositivo que posea la especificación MIDP debe ser capaz de:
• Localizar archivos JAD vinculados a un MIDlet en la red.
• Descargar el MIDlet y el archivo JAD al dispositivo desde un servidor
usando el protocolo HTTP 1.1 u otro que posea su funcionalidad.
• Enviar el nombre de usuario y contraseña cuando se produzca una respuesta HTTP por parte del servidor 401 (Unauthorized) o 407 (Proxy
Authentication Required).
• Instalar el MIDlet en el dispositivo.
• Ejecutar MIDlets.
• Permitir al usuario borrar MIDlets instalados.
5.4
Los MIDlets
Los MIDlets son aplicaciones creadas usando la especificación MIDP. Están
diseñados para ser ejecutados en dispositivos con poca capacidad gráfica, de
cómputo y de memoria.
Las clases de un MIDLet, son almacenadas en bytecodes Java, dentro de
un fichero .class. Estas clases deben ser verificadas antes de su “puesta en
marcha”, para garantizar que no realizan ninguna operación no permitida.
Esta preverificación, se debe hacer debido a las limitaciones de la máquina
virtual usada en estos dispositivos [19].
Para mantener a la máquina virtual lo más sencilla y pequeña posible, se
elimina esta verificación, y se realiza antes de la entrada en producción.
La preverificación se realiza después de la compilación, y el resultado es
una nueva clase, lista para ser puesta en producción.
Los MIDLets son empaquetados en ficheros “.jar”.
116
CAPÍTULO 5. JAVA 2 MICRO EDITION
Existen 2 ficheros que contienen información extra dentro del “.jar” para
la puesta en marcha de la aplicación, el fichero “manifiesto”, con extensión
“.mf ” y un fichero “descriptor”, con extensión “.jad”.
Un fichero “.jar” típico, por tanto, se compondrá de:
• Clases del MIDLet.
• Clases de soporte.
• Recursos (imágenes, sonidos, etc.).
• Manifiesto (fichero “.mf”).
• Descriptor (fichero “.jad”).
5.4.1
El Gestor de Aplicaciones
El gestor de aplicaciones o AMS (Application Management System) es el software encargado de gestionar los MIDlets. Este software reside en el dispositivo
y es el que permite ejecutar, pausar o destruir aplicaciones J2ME.
El AMS realiza dos grandes funciones:
• Por un lado gestiona el ciclo de vida de los MIDlets.
• Por otro, es el encargado de controlar los estados por los que pasa el
MIDlet mientras está en ejecución.
5.4.2
Ciclo de Vida de un Midlet
Como puede ilustrarse en la figura 5.5 de la página 117 el ciclo de vida de
un MIDlet pasa por cinco fases: Descubrimiento o localización; instalación;
ejecución; actualización y borrado.
El AMS es el encargado de gestionar cada una de estas fases de la siguiente
manera:
1. Localización: Esta fase es la etapa previa a la instalación del MIDlet y
es donde se selecciona a través del gestor de aplicaciones la aplicación
5.4. LOS MIDLETS
117
Figura 5.5: Ciclo de Vida de un MIDlet.
a descargar. Por tanto, el gestor de aplicaciones tiene que proporcionar
los mecanismos necesarios para realizar la elección del MIDlet a descargar. El AMS puede ser capaz de realizar la descarga de aplicaciones
de diferentes maneras, dependiendo de las capacidades del dispositivo.
Por ejemplo, esta descarga se debe poder realizar mediante un cable
conectado a un ordenador o mediante una conexión inalámbrica.
2. Instalación: En esta fase el gestor de aplicaciones controla todo el proceso de instalación del MIDlet informando al usuario tanto de la evolución
de la instalación como de si existiese algún problema durante ésta.
3. Ejecución: Mediante el gestor de aplicaciones se va a poder iniciar la
ejecución de los MIDlets. En esta fase, el AMS tiene la función de gestionar los estados del MIDlet en función de los eventos que se produzcan
durante esta ejecución.
4. Actualización: El AMS tiene que tener la capacidad de detectar si el MIDlet a instalar es una actualización de alguno ya existente, en cuyo caso
deberá informar de la situación y permitir la actualización del MIDlet.
5. Borrado: Una vez instalado el MIDlet en el dispositivo, este permanece
almacenado en la memoria persistente todo el tiempo hasta que el usuario
decida borrarlo.
118
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.6: Estados de un MIDlet.
El AMS es el encargado de eliminar el MIDlet pidiendo una confirmación
del proceso antes de continuar.
5.4.3
Estados de un MIDlet
Además de gestionar el ciclo de vida de los MIDlets, el AMS es el encargado de
controlar los estados del MIDlet durante su ejecución. Durante ésta el MIDlet
es cargado en la memoria del dispositivo y es aquí donde puede transitar entre
3 estados diferentes: activo, en pausa y destruido como puede apreciarse en la
figura 5.6 de la página 118.
Como se puede ver en la figura 5.6 de la página 118, un MIDlet puede
cambiar de estado mediante una llamada a los métodos MIDlet.startApp(),
MIDlet.pauseApp() o MIDlet.destroyApp(). El gestor de aplicaciones cambia
el estado de los MIDlets haciendo una llamada a cualquiera de los métodos
anteriores.
Un MIDlet también puede cambiar de estado por sí mismo.
5.4. LOS MIDLETS
5.4.4
119
El paquete javax.microedition.midlet
El paquete javax.microedition.midlet define las aplicaciones MIDP y su comportamiento con respecto al entorno de ejecución.
En la tabla 5.6 de la página 119 se puede apreciar cuáles son las clases que
están incluidas en este paquete.
Clases
MIDlet
MIDletstateChangeException
Descripción
Aplicación MIDP
Indica que el cambio de estado ha fallado
Tabla 5.6: Clases del Paquete javax.microedition.midlet.
5.4.5
La Clase MIDlet
Como se ha mencionado con anterioridad, un MIDlet es una aplicación realizada usando el perfil MIDP.
La aplicación desarrollada debe extender o heredar de esta clase para que
el gestor de aplicaciones o AMS pueda gestionar sus estados y tener acceso a
sus propiedades.
Los métodos de los que dispone esta clase son los siguientes:
• protected MIDlet()
Constructor de clase sin argumentos. Si la llamada a este constructor falla,
se lanzaría la excepción SecurityException.
• public final int checkPermission(String permiso)
Con este método se consigue un número que determina el permiso especificado. Este permiso está descrito en el atributo MIDlet-Permission del archivo
JAD.
Los valores que puede arrojar este método son:
120
CAPÍTULO 5. JAVA 2 MICRO EDITION
— 0 si el permiso es denegado.
— 1 si el permiso es permitido.
— -1 si el estado es desconocido.
• protected abstract void destroyApp(boolean incondicional) throws MIDletstateChangeException
Indica la terminación del MIDlet y su paso al estado de “Destruido”. En
el estado de “Destruido” el MIDlet debe liberar todos los recursos y salvar
cualquier dato en el almacenamiento persistente que deba ser guardado. Este
método puede ser llamado desde los estados “Pausa” o “Activo”.
• public final String getAppProperty(String key)
Este método proporciona al MIDlet un mecanismo que le permite recuperar
el valor de las propiedades desde el AMS. Las propiedades se consiguen por
medio de los archivos manifest y JAD. El nombre de la propiedad a recuperar
debe ir indicado en el parámetro key.
• public final void notifyDestroyed()
Con este método se notifica al AMS que el MIDlet no quiere estar “Activo”
y que ha entrado en el estado de “Pausa”. Este método sólo debe ser invocado
cuando el MIDlet esté en el estado “Activo”.
Si la aplicación es pausada por sí misma, es necesario llamar al método
MIDlet.resumeRequest() para volver al estado “Activo”.
• protected abstract void pauseApp()
Indica al MIDlet que entre en el estado de “Pausa”. Este método sólo debe
ser llamado cuándo el MIDlet esté en estado “Activo”.
• public final boolean platformRequest(String url)
5.4. LOS MIDLETS
121
Establece una conexión entre el MIDlet y la dirección URL. Dependiendo
del contenido de la URL, el dispositivo ejecutará una determinada aplicación
que sea capaz de leer el contenido y dejar al usuario que interactúe con él.
• protected abstract void startApp() throws MIDletstateChangeException
Este método indica al MIDlet que ha entrado en el estado “Activo”. Este método sólo puede ser invocado cuándo el MIDlet está en el estado de
“Pausa”. En el caso de que el MIDlet no pueda pasar al estado “Activo” en
este momento pero sí pueda hacerlo en un momento posterior, se lanzaría la
excepción MIDletstateChangeException.
Los métodos anteriormente mencionados se utilizan para la comunicación
entre el MIDlet y el AMS. Por un lado se tiene que los métodos startApp(),
pauseApp() y destroyApp() los utiliza el AMS para comunicarse con el MIDlet,
mientras que los métodos resumeRequest(), notifyPaused() y notifyDestroyed()
los utiliza el MIDlet para comunicarse con el AMS.
5.4.6
Estructura de los MIDlets
Es posible decir que los MIDlets, al igual que los applets carecen de la función
main().
Aunque si existiese dicha función, el gestor de aplicaciones la ignoraría por
completo. Un MIDlet tampoco puede realizar una llamada a System.exit().
Una llamada a este método lanzaría la excepción SecurityException.
Los MIDlets tienen la siguiente estructura:
import javax.microedition.midlet.*;
public class MiMidlet extends MIDlet{
public MiMidlet() {
/* Éste es el constructor de clase. Aquí se deben
* inicializar las variables.
*/
}
public startApp(){
122
CAPÍTULO 5. JAVA 2 MICRO EDITION
/* Aquí se puede incluir el código que el
* MIDlet debe ejecutar cuándo se active.
*/
}
public pauseApp(){
/* Aquí se puede incluir el código que el
* MIDlet debe ejecutar cuándo entre en el estado de pausa
* es opcional
*/
}
public destroyApp(){
/* Aquí se puede incluir el código que el
* MIDlet debe ejecutar cuándo sea destruido. Normalmente
* aquí se liberaran los recursos ocupados por el
* MIDlet como memoria, etc.
* es opcional
*/
}
}// fin de la clase MiMidlet
Un pequeño ejemplo de una aplicación simple se puede apreciar a continuación.
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class HolaMundo extends MIDlet{
private Display pantalla;
private Form formulario = null;
public HolaMundo(){
pantalla = Display.getDisplay(this);
formulario = new Form(“Hola Mundo”);
5.5. INTERFACES GRÁFICAS DE USUARIO
123
}
public void startApp(){
pantalla.setCurrent(formulario);
}
public void pauseApp(){
}
public void destroyApp(boolean unconditional){
pantalla = null;
formulario = null;
notifyDestroyed();
}
}
Estos métodos son los que obligatoriamente tienen que poseer todos los
MIDlets ya que, como se ha visto, la clase que se ha creado tiene que heredar de
la clase MIDlet y ésta posee tres métodos abstractos: startApp(), pauseApp()
y destroyApp() que han de ser implementados por cualquier MIDlet.
5.5
Interfaces Gráficas de Usuario
Teniendo en cuenta la diversidad de aplicaciones que se pueden realizar para
los dispositivos MID y los elementos que proporcionan tanto la configuración
CLDC como el perfil MIDP se pueden clasificar a los elementos en dos grandes
grupos:
• Por un lado existen los elementos que corresponden a la interfaz de
usuario de alto nivel. Esta interfaz usa componentes tales como botones, cajas de texto, formularios, etc. La finalidad de usar estas APIs de
alto nivel es su portabilidad. Al utilizar esta interfaz de usuario se pierde
el control del aspecto de las aplicaciones desarrolladas, ya que la estética
depende exclusivamente del dispositivo donde se ejecute. La ventaja de
la utilización de esta interfaz de usuario de alto nivel es la gran portabilidad que se consigue. Generalmente esta interfaz es utilizada para la
creación de aplicaciones de negocios.
124
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.7: Jerarquía de Clases.
• Por otro lado existen los elementos que forman parte de la interfaz de
usuario de bajo nivel. Al utilizar las APIs de bajo nivel se puede tener
un control total de todo lo que está dibujado en la pantalla, además
se pueden manejar eventos de bajo nivel, tales como pulsaciones de las
teclas. Esta interfaz es más adecuada para el desarrollo de juegos. El
paquete javax.microedition.lcdui definido en el perfil MIDP incluye las
clases necesarias para crear interfaces de usuario, tanto de alto nivel
como de bajo nivel. En la figura 5.7 de la página 124 se puede apreciar
la organización de estas clases.
5.5.1
La Clase Display
La clase Display representa el manejador de la pantalla y los dispositivos de
entrada. Todo MIDlet debe poseer por lo menos un objeto Display. En este
objeto Display se puede incluir tantos objetos Displayable como se desee. La
clase Display puede obtener información sobre las características de la pantalla
del dispositivo donde se ejecute el MIDlet.
En la tabla 5.7 de la pág. 125 se puede ver los métodos incluidos en esta
clase.
5.5. INTERFACES GRÁFICAS DE USUARIO
Métodos
void callSerially
(Runnable r)
boolean flashBacklight
(int duracion)
int getBestImageHeight
(int imagen)
int getBestImageWidth
(int imagen)
int getBorderStyle
(bolean luminosidad)
int getColor
(int color)
Displayable getCurrent()
static Display getDisplay
(MIDlet m)
boolean isColor()
int numAlphaLevels()
int numColors()
void setCurrent
(Alert a, Displayable d)
void setCurrent
(Displayable d)
void setCurrent
(Item item)
boolean vibrate
(int duracion)
Descripción
Retrasa la ejecución del método run()
del objeto r
Provoca un efecto de flash
en la pantalla
Devuelve el mejor alto
de imagen
Devuelve el mejor ancho
de imagen
Devuelve el estilo de
borde actual
Devuelve un color basado en el
parámetro pasado
Devuelve la pantalla actual
Devuelve una referencia a la pantalla
del MIDlet m
Devuelve true o false si la pantalla
es de color o b/n
Devuelve el número de niveles
alpha soportados
Devuelve el número de colores
Establece la pantalla d
despues de la alerta a
Establece la pantalla actual
Establece en la pantalla
al item
Realiza la operación de
vibración del dispositivo
Tabla 5.7: Métodos de la Clase Display.
125
126
CAPÍTULO 5. JAVA 2 MICRO EDITION
5.5.2
La Clase Displayable
La clase Displayable representa a las pantallas de la aplicación.
Como se mencionó anteriormente, cada objeto Display puede contener tantos objetos displayables como se desee.
Mediante los métodos getCurrent y setCurrent se controlan las pantallas
para que sean visibles y accesibles en cada momento.
La clase abstracta Displayable incluye los métodos encargados de manejar
los eventos de pantalla y añadir o eliminar comandos.
Estos métodos aparecen en la tabla 5.8 de la pág. 126.
Métodos
void addCommand
(Command cmd)
int getHeight()
Ticker getTicker()
String getTitle()
int getWidth()
bolean isShown()
void removeCommand
(Command cmd)
void setCommandListener
(CommandListener l)
protected void sizeChanged
(int w, int h)
void setTicker(Ticker ticker)
void setTitle(String title)
Descripción
añade el Command cmd
Devuelve el alto de la pantalla
Devuelve el Ticker asignado a la pantalla
Devuelve el título de la pantalla
Devuelve el ancho de la pantalla
Devuelve true si la pantalla está activa
Elimina el Commando cmd
de la pantalla
Establece un Listener para la
captura de eventos
El AMS llama a este método
cuándo el área disponible
para el objeto Displayable es modificada
Establece un Ticker a la pantalla
Establece un título a la pantalla
Tabla 5.8: Métodos de la Clase Displayable.
5.5.3
Las Clases Command y CommandListener
Un objeto de la clase Command mantiene información sobre un evento.
5.5. INTERFACES GRÁFICAS DE USUARIO
127
Por establecer una analogía se puede pensar a un objeto Command como
un botón de Windows.
Se implementan en los MIDlets para poder detectar y ejecutar una acción
simple.
Existen tres parámetros que hay que definir al constuir un Command:
• Etiqueta: La etiqueta es la cadena de texto que aparecerá en la pantalla
del dispositivo que identificará al Command.
• Tipo: La declaración del tipo sirve para que el dispositivo identifique
el Command y le dé una apariencia específica acorde con el resto de
aplicaciones existentes en el dispositivo.
• Prioridades: Esto puede servirle al AMS para establecer un orden de
aparición de los Command en pantalla. A mayor número, menor prioridad.
Los tipos que se pueden asignar aparecen en la tabla 5.9 de la página 127.
Tipo
BACK
CANCEL
EXIT
HELP
ITEM
OK
SCREEN
STOP
Descripción
Petición para volver a la pantalla anterior
Petición para cancelar la acción en curso
Petición para salir de la aplicación
Petición para mostrar información de ayuda
Petición para introducir el comando en
un Item en la pantalla
Aceptación de una acción por parte del usuario
Para comandos de propósito más general
Petición para parar una operación
un Listener para la captura de eventos
Tabla 5.9: Tipos de Commands.
Ejemplo de un Command con la etiqueta “Atras”:
new Command(“Atras”,Command.BACK,1);
La tabla 5.10 de la pág. 128 muestra los métodos de la clase Command.
128
CAPÍTULO 5. JAVA 2 MICRO EDITION
Método
public int
getCommandType()
public String getLabel()
public String getLongLabel()
public int getPriority()
Devuelve el tipo del Command
Petición para volver a la
pantalla anterior
Devuelva la etiqueta del Command
Devuelve la etiqueta larga del Command
Devuelve la prioridad del Command
Tabla 5.10: Métodos de la Clase Command.
No solo basta con crear objetos Command, para poder controlar algún
evento de la aplicación. Otra tarea pendiente es implementar la interfaz
CommandListener, la cual define un método abstracto llamado CommandAction(Command d, Displayable d), donde debe ser implentado dicho método,
ya que una interfaz sólo define métodos abstractos, es tarea de la clase que
implementa dicha interfaz tener que implementar los métodos definidos.
A través de la implementación del método CommandAction se podrán
manejar los eventos que lanza el Command c que se encuentran en el objeto
Displayable d.
5.5.4
Interfaz de Usuario de Alto Nivel
Para comenzar se verá la clase Screen que es la superclase de todas las clases
que conforman la interfaz de usuario de alto nivel:
public abstract class Screen extends Displayable
En la especificación MIDP 1.0 esta clase contenía cuatro métodos que le
permitían definir y obtener el título y el ticker: setTitle(String s), getTitle(),
setTicker(Ticket ticker) y getTicker(). El ticker es una cadena de texto que
se desplaza por la pantalla de derecha a izquierda. En la especificación MIDP
2.0, que es la más reciente, estos cuatro métodos han sido incluidos en la clase
Displayable.
5.5. INTERFACES GRÁFICAS DE USUARIO
129
La Clase Alert
El objeto Alert representa una pantalla de aviso. Normalmente se usa cuando
se quiere avisar al usuario de una situación especial como, por ejemplo, un
error.
Para crear un Alert se dispone de 2 constructores de acuerdo a su apariencia:
• Alert(String titulo).
• Alert(String titulo, String textoalerta, Image imagen, AlertType tipo).
Existen dos tipos de alertas:
1. Modal : Este tipo de alerta permanece un tiempo indeterminado en la
pantalla hasta que el usuario la cancela. Se obtiene llamando al método
Alert. setTimeOut (Alert. FOREVER).
2. No modal : Este tipo de alerta permanecerá por un tiempo definido por el
usuario y luego desaparecerá. Para ello se indica el tiempo en el método
setTimeOut(tiempo), el tiempo expresado en milisegundos.
También se puede elegir el tipo de alerta que se va a mostrar. Cada tipo
de alerta tiene asociado un sonido. Los tipos que se pueden definir aparecen
en la tabla 5.11 de la página 129.
Método
ALARM
CONFIRMATION
ERROR
INFO
WARNING
Devuelve el tipo del Command
Aviso de una Petición previa
Indica la aceptació de una acció
Indica que ha ocurrido un error
Indica algún tipo de información
Indica que puede ocurrir algún problema
Tabla 5.11: Tipos de Alerta.
130
CAPÍTULO 5. JAVA 2 MICRO EDITION
La Clase List
La clase List hereda de la clase Screen, pero presenta una funcionalidad más
amplia que la clase Alert. La clase List proporciona una pantalla que contiene
una lista de elementos sobre los que el usuario puede seleccionar. Esta clase
implementa la interfaz Choice, que define constantes que describen tres tipos
básicos de listas de opciones:
• EXCLUSIVE: Una lista que permite seleccionar un solo elemento a la
vez.
• IMPLICIT: Un lista en la que la selección de un elemento provoca un
evento (se adapta para la creación de menús).
• MÚLTIPLE: Una lista que permite seleccionar uno o más elementos a
la vez.
Existen dos constructores que permiten construir listas: el primero de ellos
crea una lista vacía y el segundo proporciona una lista con un conjunto inicial
de opciones y de imágenes asociadas:
• List(String titulo, int listType).
• List(String titulo, int listType, String[] elementos, Image[] imagenes).
En la siguiente tabla 5.12 de la página 131 se puede observar los distintos
métodos de la clase List.
La Clase TextBox
La clase TextBox implementa un componente de edición de texto, que ocupa
toda la pantalla.
El constructor de la clase es:
TextBox(String title, String text, int maxSize, int constraints)
El parámetro title es un texto que aparecerá en la parte superior de la
pantalla, mientras que el parámetro text es usado para inicializar el texto que
contendrá el TextBox.
5.5. INTERFACES GRÁFICAS DE USUARIO
Métodos
int append(String texto,
Image imagen)
void delete(int posición)
void deleteAll()
void insert(int pos,
String texto, Image im)
int getFitPolicy()
Font getFont(int pos)
Image getImage(int pos)
int getSelectedFlags
(bolean[] array)
int getSelectedIndex()
String getString(int pos)
boolean isSelected(int pos)
void removeCommand
(Command cmd)
void set(int pos,
String texto, Image im)
void setFitPolicy(int modo)
void setFont
(int pos, Font fuente)
void setSelectCommand
(Command cmd)
int setSelectedFlags
(bolean[] array)
int setSelectedIndex(int pos,
boolean selec)
int size()
131
Descripción
Añade un elemento
al final de la lista
Elimina el elemento de la
posición especificada
Elimina todas las entradas de la lista
Inserta un elemento en la
posición especificada
Devuelve el modo en el que se muestran
las entradas de la lista por pantalla
Devuelve la fuente del elemento pos
Obtiene la imagen de una
posicióndeterminada
Almacena el estado de selección
en un array
Obtiene el ´(i)ndice del
elemento seleccionado
Obtiene el texto del elemento
indicado por pos
Determina si est´(a) seleccionado
el elemento
Elimina el comando cmd
Reemplaza el elemento de la
posición pos
Establece el modo de posicionar las
entradas de la lista por pantalla
Establece la fuente de la
entrada indicada en pos
Selecciona el Command a usar
Reemplaza el estado de selección
por el de array
Reemplaza el estado de la selección
Obtiene el número de elementos
Tabla 5.12: Métodos de la Clase List.
132
CAPÍTULO 5. JAVA 2 MICRO EDITION
El parámetro maxSize especifica el número máximo de caracteres de texto
que pueden ser introducidos en el TextBox.
Por último el parámetro constraints describe las limitaciones a aplicar
sobre el texto.
Estas limitaciones son especificadas según las constantes definidas en la
clase TextField:
• ANY: No hay limitaciones en el texto.
• EMAILADDR: Sólo se puede introducir una dirección de correo electrónico.
• NUMERIC: Sólo se puede introducir un valor numérico.
• PASSWORD: El texto es protegido para que no sea visible.
• PHONENUMBER: Sólo se puede introducir un número de teléfono.
• URL: Sólo se puede introducir una URL.
Un ejemplo de uso sería:
TextBox box = new TextBox(“NOTAS”, “Nota:” , 256, TextField.ANY).
La Clase Form
Un formulario (clase Form) es un componente que actúa como contenedor de
un número indeterminado de objetos. Todos los objetos que puede contener
un formulario derivan de la clase Item.
El número de objetos que se pueden insertar en un formulario es variable pero, teniendo en cuenta el tamaño de las pantallas de los dispositivos
MID, se recomienda que el número sea pequeño para evitar así el scroll que se
produciría si se insertan demasiados objetos en un formulario.
Un mismo Item no puede estar en más de un formulario a la vez. Si,
por ejemplo, se desea usar una misma imagen en más de un formulario, se
debe borrar esa imagen de un formulario antes de insertarla en el que se va a
mostrar por pantalla.
5.5. INTERFACES GRÁFICAS DE USUARIO
133
Si no se cumple esta regla, se lanzaría la excepción IllegalStateException.
La tabla 5.13 de la página 133 muestra los métodos de la clase Form.
Métodos
int append(Image imagen)
int append(Item item)
int append(String texto)
void delete(int num)
void deleteAll()
Item get(int num)
int getHeight()
int getWidth()
void insert(int num,
Item item)
void set(int num,
Item item)
boolean isSelected(int pos)
void setItemStateListener
(ItemStateListener listener
int size()
Descripción
Añade una imagen al formulario
Añade un item al formulario
Añade un String al formulario
Elimina el Item que ocupa
la posición num
Elimina todos los Items del formulario
Devuelve el Item que se encuentra
en la posici´(o)n num
Devuelve la altura del área
disponible para los Items
Devuelve la anchura del área disponible
para los Items
Inserta un Item justo antes del
que ocupa la posición num
Reemplaza el Item que ocupa la
posici´(o)n num
Determina si est seleccionado el elemento
Establece un listener
eventos capturar
Devuelve el número de Items
del formulario
Tabla 5.13: Métodos de la Clase Form.
Manejo de Eventos
El manejo de eventos en un formulario es muy similar al manejo de eventos
de los Command vistos anteriormente. Nada más que para un formulario se
tiene que implementar la interfaz ItemStateListener que contiene un método
abstracto llamado itemStateChanged(Item item).
Cuando se realiza algún tipo de acción en el algún ítem del formulario se
134
CAPÍTULO 5. JAVA 2 MICRO EDITION
ejecuta el código asociado del método itemStateChanged(Item item).
Un ejemplo de su utilización se puede observar a continuación:
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class ManejoItems extends MIDlet implements ItemStateListener, CommandListener{
Display pantalla;
Form formulario;
TextField txt;
Command salir;
public ManejoItems(){
pantalla = Display.getDisplay(this);
formulario = new Form(“”);
txt = new TextField(“Introduce datos”,“”,70,TextField.ANY);
salir = new Command(“Salir”,Command.EXIT,1);
formulario.append(txt);
formulario.addCommand(salir);
formulario.setItemStateListener(this);
formulario.setCommandListener(this);
public void startApp() {
pantalla.setCurrent(formulario);
}
public void pauseApp() {
}
public void destroyApp(boolean unconditional) {
}
public void commandAction(Command c, Displayable d){
if (i == txt){
System.out.println(“Evento detectado en el TextBox”);
}
}
}
5.5. INTERFACES GRÁFICAS DE USUARIO
135
La Clase StringItem
La clase StringItem es la clase más simple que deriva de Item. Es una cadena
no modificable de texto, es decir, una cadena de texto con la que el usuario
no puede interactuar de ninguna manera.
Para construir un StringItem se hace uso de cualquiera de sus dos constructores:
• StringItem(String etiqueta, String texto).
• StringItem(String etiqueta, String texto, int apariencia).
Los parámetros:
• etiqueta: Es la etiqueta del ítem.
• texto: Es el texto que contiene el ítem.
• apariencia: Es la apariencia del texto: Item.PLAIN, Item.HYPERLINK,
Item.BUTTON.
Los métodos que posee la clase StringItem aparecen en la tabla 5.14 de la
página 135
Métodos
int getAppearanceMode()
Font getFont()
String getText()
void setFont(Font fuente)
void setText(String texto)
Descripción
devuelve la apariencia del texto
devuelve la Fuente del texto
devuelve el texto del StringItem
Establece la Fuente del texto
Establece el texto del StringItem
Tabla 5.14: Métodos de la Clase StringItem.
La Clase ImageItem
La clase ImageItem brinda la posibilidad de incluir imágenes en un formulario.
136
CAPÍTULO 5. JAVA 2 MICRO EDITION
Al igual que la clase StringItem, el usuario no podrá interactuar con la
imagen.
Para crear un objeto ImageItem se pueden usar uno de sus dos constructores:
• ImageItem(String etiqueta, Image imagen, int layout, String textoalt).
• ImageItem(String etiqueta, Image imagen, int layout, String textoalt, int
apariencia).
El parámetro textoalt especifica una cadena de texto alternativa a la imagen
en caso de que ésta exceda la capacidad de la pantalla. Por su parte, el
parámetro layout indica la posición de la imagen en la pantalla. Los valores
que puede tomar son:
• LAYOUT_LEFT: Imagen posicionada a la izquierda.
• LAYOUT_RIGHT: Imagen posicionada a la derecha.
• LAYOUT_CENTER: Imagen centrada.
• LAYOUT_DEFAULT : Posición por defecto.
• LAYOUT_NEWLINE_AFTER: Imagen posicionada tras un salto de
línea.
• LAYOUT_NEWLINE_BEFORE: Imagen posicionada antes de un salto
de línea.
Los métodos de la clase ImageItem se pueden ver en la tabla 5.15 de la
página 137.
La Clase TextField
Un texfield es un campo de texto que puede ser insertado en un formulario y
en el cuál se puede editar texto. Tiene similitud con la clase TextBox. Sus
diferencias son:
5.6. RMS (RECORD MANAGEMENT SYSTEM)
Métodos
String getAltText()
Int getAppearanceMode()
Image getImage()
Int getLayout()
void setAltText(String textoalt)
void setImage(Image imagen)
void setLayout(int layout)
137
Descripción
devuelve la cadena de
texto alternativa
devuelve la apariencia
devuelve la imagen
devuelve el posicionado de la imagen
Establece un texto alternativo
Establece una nueva imagen
Establece un nuevo posicionado
en pantalla
Tabla 5.15: Métodos de la Clase ImageItem.
• Un texfield tiene que ser insertado en un formulario, a diferencia de un
textbox puede existir por sí mismo.
• TextField deriva de la clase Item, mientras que TextBox deriva directamente de Screen, y sus eventos se controlan a través de Commands. Por
esta razón, los eventos que produce un TextField se controlan a través
del método itemStateChanged(Item item), mientras que en un TextBox
se controlan en el método commandAction(Command c, Displayable d).
Sin embargo ambas clases (TextBox y TextField) comparten las mismas
restricciones de edición que se vieron anteriormente.
Para crear un TextField sólo hay que invocar al constructor con los siguientes parámetros:
TextField(String etiqueta, String texto, int capacidad, int restricciones).
Otros métodos de esta clase pueden verse en la tabla 5.16 de la página 138
5.6
RMS (Record Management System)
El sistema de gestión de registros (Record Management System, RMS ) se compone de una serie de clases e interfaces que proporcionan soporte a un sistema
simple de base de datos que es usado para almacenar información.
138
CAPÍTULO 5. JAVA 2 MICRO EDITION
Métodos
void delete(int desplazamiento,
int longitud)
int getCaretPosition()
Image getImage()
int getChars(char[] datos)
int getConstraints()
int getMaxSize()
String getString()
void insert(char[] datos,
int des, int long, int pos)
void insert(char[] datos,
int pos)
void setChars(char[] datos,
int des, int long)
void setConstraints
(int restricciones)
void setInitialInputMode
(String caracteres)
int setMaxSize(int capacidad)
void setString(String texto)
void setString(String texto)
int size()
Descripción
Borra caracteres del TextField
Devuelve la posici n del cursor en pantalla
devuelve la imagen
Copia el contenido del TextField en datos
Devuelve las restricciones de entrada
Devuelve el tamaño máximo del TextField.
Devuelve el contenido del TextField
Inserta un subrango de caracteres
de datos en el TextField
Inserta la cadena de caracteres datos
en una posición determinada
Reemplaza el contenido del TextField por
un subconjunto de caracteres de datos
Establece las restricciones
de entrada
Establece un tipo
de entrada inicial
Establece el tamaño máximo del TextField
Establece el contenido del TextField
Establece el contenido del TextField
Devuelve el número de caracteres
Tabla 5.16: Métodos de la Clase TextField.
5.6. RMS (RECORD MANAGEMENT SYSTEM)
139
Figura 5.8: Un MIDlet y el RMS.
El objetivo del RMS es almacenar datos de tal forma que estén disponibles
una vez que el MIDlet detenga su ejecución.
La unidad básica de almacenamiento es el registro (record) que será almacenado en un base de datos especial, denominada almacén de registros (record
store ).
Cuando un MIDlet usa un almacén de registros, primero debe crearlo y
luego añadir los registros. Cuando un registro es añadido a un almacén de
registros, se le asigna un identificador único (id) [19].
5.6.1
Modelo de Datos
Como ya se ha dicho, el RMS está implementado en una base de datos basada
en registros; ver figura 5.8 de la página 139.
Los MIDlets son los encargados de crear los Record Stores para poder comunicarse con ellos. Estos Record Stores quedan almacenados en el dispositivo
y pueden ser accedidos por cualquier MIDlet que pertenezca en la misma suite,
es decir que pertenezcan al mismo grupo, como se puede ver en la figura 5.9
de la página 140.
140
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.9: Acceso a un RMS a Través de un MIDlet Suite.
5.6.2
Record Stores
Las propiedades de estos almacenes de registros son:
1. Cada Record Store está compuesto por cero o más registros.
2. El nombre puede tener un máximo de 32 caracteres.
3. Si una suite es borrada, todos los Record Store también se borran.
4. Un Midlet no perteneciente a la suite puede acceder al Record Store,
siempre que éste lo permita.
5. No pueden coexistir dos Record Stores con el mismo nombre dentro de
una MIDlet suite.
Entonces se puede decir que un Record Store es un almacén de registros,
donde éstos registros son la unidad básica de información.
Cada uno de estos registros está formado por dos unidades:
• Un número identificador de registro (Record ID) que es un valor entero
que realiza la función de clave primaria en la base de datos.
5.6. RMS (RECORD MANAGEMENT SYSTEM)
141
Figura 5.10: Esturctura de Un Record Store.
• Un array de bytes destinados a almacenar la información deseada.
En la figura 5.10 de la página 141 se ilustra la estructura de un Record
Store.
5.6.3
Creación de un Record Store
El API de MIDP incluye un paquete para el RMS , llamado javax.microedition.rms.
Este paquete incluye clases e interfaces que proporcionan un marco de trabajo
para los registros, los almacenes y otras características.
Básicamente se dispone de:
• Capacidad para añadir y borrar registros de un almacén.
• Capacidad para compartir almacenes de todos los MIDlets de una MIDlet suite.
La clase RecordStore no dispone de ningún constructor, pero posee el método estático:
• static RecordStore openRecordStore(String name, Boolean createIfNeccesary).
Este método permite la apertura de un Record Store existente o bien la
creación de un almacén si el parámetro createIfNeccesary tiene el valor true.
También existen otras dos alternativas de este método:
142
CAPÍTULO 5. JAVA 2 MICRO EDITION
• static RecordStore openRecordStore(String name, boolean createIfNeccesary,
int autorización, boolean writable).
• static RecordStore openRecordStore(String name, String vendorName, String
suiteName).
El primero de ellos utiliza los siguientes parámetros:
• autorización:
— AUTHMODE_PRIVATE : Sólo permite el acceso al Record Store
a la MIDlet suite que lo creó.
— AUTHMODE_ANY : Permite el acceso a cualquier MIDlet del dispositivo.
• writable: Este modo especifica si el Record Store puede ser modificado
por cualquier MIDlet que pueda acceder a él.
El segundo método se utiliza para abrir un Record Store que está asociado a
alguna MIDlet suite especificada por los parámetros vendorName y suiteName.
El acceso vendrá limitado por el tipo de autorización del Record Store
cuando fue creado.
Al finalizar con el uso de un determinado Record Store hay que cerrar la
comunicación con él. Para ello se utiliza el siguiente método:
• public void closeRecordStore() throws RecordStoreNotFoundException, RecordStoreException.
En la tabla 5.17 de la página 143 se pueden apreciar los métodos que
proporcionan operaciones con los Record Stores.
5.6.4
Manipulación de Registros
Una vez creado o abierta la comunicación con el Record Store, se puede leer,
escribir, modificar o borrar registros como se desee. Para ello, se usan los
métodos de la clase RecordStore que se ven en la tabla 5.18 de la página 144.
5.6. RMS (RECORD MANAGEMENT SYSTEM)
Métodos
String getName()
int getVersion()
long getLastModified()
int getNumRecords()
int getSize()
int getSizeAvailable()
String[] listRecordStores()
void deleteRecordStore
(String name)
RecordEnumeration enumerateRecords(RecordFilter
filter, RecordComparator
comparator, boolean
actualizado)
void addRecordListener
(RecordListener listener)
void removeRecordListener
(RecordListener listener)
143
Descripción
Devuelve el nombre del Record Store
Devuelve la versi n del Record Store
Devuelve la marca temporal
Devuelve el número de registros
Devuelve el número de bytes
ocupado por el Record Store
Devuelve el tama˜(n)o disponible
para añadir registros
Devuelve una lista con los
nombres de los Record Stores
Elimina del dispositivo al Record
Store especificado por el
parámetro name
devuelve un objeto
RecordEnumeration
Añade un listener para
detectar cambios en el Record Store
Elimina un listener
Tabla 5.17: Métodos Generales de la Clase RecordStore.
144
CAPÍTULO 5. JAVA 2 MICRO EDITION
Métodos
int addRecord(byte[] datos,
int offset, int numBytes)
void deleteRecord(int id)
Int getNextRecordId()
byte[] getRecord(int id)
int getRecord(int id,
byte[] buffer,int offset)
int getRecordSize(int id)
void setRecord(int id,byte[]
datonuevo, int offset,
int tamaño)
Descripción
Añade un registro
al Record Store
Borra el registro id del Record Store
Devuelve el siguiente id del registro
que se vaya a insertar
Devuelve el registro con identificador id
Devuelve el registro con identificador
id en buffer a partir de offset
Devuelve el tama˜(n)o del registro id
Sustituye el registro id
con el valor de datonuevo
Tabla 5.18: Métodos Para Manejo de Registros.
A continuación se mostrará un ejemplo que utiliza un Record Store de
jugadores, donde se pueden ingresar nuevos jugadores y su puntaje obtenido.
package rms;
import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;
import javax.microedition.lcdui.*;
import javax.microedition.rms.*;
import java.io.*;
public class Rms extends MIDlet implements CommandListener{
//Atributos
protected Display d;
protected Form form;
protected TextField textField;
protected TextField textField1;
protected TextField textField2;
5.6. RMS (RECORD MANAGEMENT SYSTEM)
145
protected Command ingresar, volver;
protected Alert alert;
private RecordStore rs;
protected List list;
protected Form form2;
protected String[] respuesta;
//Metodos
// metodo para iniciar la aplicacion, aqui se inicializa el objeto display y se
// muestra primeramente el menu como pantalla principal
protected void startApp() throws MIDletStateChangeException{
d = Display.getDisplay(this);
d.setCurrent(getList());
}
protected void pauseApp(){
}
protected void destroyApp(boolean flag) throws MIDletStateChangeException{
}
// este método arma el formulario y retorna para poder ser mostrado
protected Form getForm(){
if (form == null){
form = new Form(”Nuevo Puntaje”);
form.append(getTextField());
form.append(getTextField1());
form.append(getTextField2());
form.addCommand(getCommand());
form.addCommand(getBack());
form.setCommandListener(this);
}
return form;
146
CAPÍTULO 5. JAVA 2 MICRO EDITION
}
public TextField getTextField(){
if (textField == null){
textField = new TextField(”Nombre Jugador: ”, ””, 255, TextField.ANY);
}
return textField;
}
public TextField getTextField1(){
if (textField1 == null){
textField1 = new TextField(”Documento: ”, ””, 255, TextField.ANY);
}
return textField1;
}
public TextField getTextField2() {
if (textField2 == null) {
textField2 = new TextField(”Puntaje: ”, ””, 2, TextField.NUMERIC);
}
return textField2;
}
public Command getCommand(){
if (ingresar == null){
ingresar = new Command(”Cargar”,Command.OK,1);
}
return ingresar;
}
public Command getBack(){
if (volver == null){
5.6. RMS (RECORD MANAGEMENT SYSTEM)
147
volver = new Command(”Volver”,Command.BACK,1);
}
return volver;
}
public void commandAction(Command c, Displayable dis){
if (c==list.SELECT_COMMAND){
if (list.getSelectedIndex()==0){
d.setCurrent(getForm());
}else{
//se llama al formulario de lectura .. form2
System.out.println(”ok”);
abrirRecordStore();
leerRegistro();
cerrarRecordStore();
}
}
if (c==ingresar){
cargarDatos();
d.setCurrent(getAlert());
textField.setString(””);
textField1.setString(””);
textField2.setString(””);
}
if (c==volver){
d.setCurrent(getList());
}
}
public Alert getAlert() {
if (alert == null) {
alert = new Alert(”Información”, ”Los datos se estan cargando
espere...”, null, AlertType.INFO);
148
CAPÍTULO 5. JAVA 2 MICRO EDITION
alert.setTimeout(3000);
}
return alert;
}
private void cargarDatos(){
abrirRecordStore();
// luego se graban los datos y despues cierra la conexion
escribirRegistro(textField.getString(),
textField1.getString(),textField2.getString());
cerrarRecordStore();
}
private void abrirRecordStore(){
try{
rs = RecordStore.openRecordStore(”Jugadores”,true);
}catch(RecordStoreException e){
System.out.println(”Error al abrir el record store”);
}
}
private void cerrarRecordStore(){
try{
rs.closeRecordStore();
}catch(RecordStoreException e){
System.out.println(”error al cerrar el recordstore”);
}
}
private void escribirRegistro(String jugador, String doc, String pun){
byte[] registro;
ByteArrayOutputStream baos;
DataOutputStream dos;
try{
baos = new ByteArrayOutputStream();
5.6. RMS (RECORD MANAGEMENT SYSTEM)
149
dos = new DataOutputStream(baos);
dos.writeUTF(jugador);
dos.writeUTF(doc);
dos.writeUTF(pun);
dos.flush();
registro = baos.toByteArray();
rs.addRecord(registro,0,registro.length);
baos.close();
dos.close();
}catch(Exception e){
System.out.println(”error al insertar el registro”);
}
}
private void leerRegistro(){
ByteArrayInputStream bais;
DataInputStream dis;
byte[] registro = new byte[200];
try{
bais = new ByteArrayInputStream(registro);
dis = new DataInputStream(bais);
respuesta = new String[rs.getNumRecords()+ 1];
for (int i=1;i<=rs.getNumRecords();i++){
rs.getRecord(i,registro,0);
System.out.println(”Registro: ” + i);
respuesta[i]= ”Nombre: ” + dis.readUTF() + ” \nDocumento:
” +
dis.readUTF()+” \nPuntaje: ” + dis.readUTF();
bais.reset();
}
bais.close();
dis.close();
}catch(Exception e){
System.out.println(”error al leer registros”);
150
CAPÍTULO 5. JAVA 2 MICRO EDITION
}
registro = null;
mostrarDatos();
}
public List getList() {
if (list == null) {
list = new List(”Menu”, Choice.IMPLICIT);
list.append(”Cargar Datos”,null);
list.append(”Leer Datos”,null);
list.setCommandListener(this);
}
return list;
}
public Form getForm2() {
if (form2 == null) {
form2 = new Form(”Lectura de Datos”);
for (int i=1;i<respuesta.length;i++){
form2.append(respuesta[i]);
form2.addCommand(getBack());
form2.setCommandListener(this);
}
}
return form2;
}
public void mostrarDatos(){
d.setCurrent(getForm2());
}
}
En la figura 5.11 de la página 151 se pueden apreciar las pantallas del
ejemplo representadas por capturas de pantalla de una Palm T|X.
5.6. RMS (RECORD MANAGEMENT SYSTEM)
Figura 5.11: Ejemplo RMS.
151
152
CAPÍTULO 5. JAVA 2 MICRO EDITION
5.6.5
Operaciones con Record Stores
En el ejemplo anteriormente visto se ha usado un simple bucle para recorrer
los distintos registros del Record Store. El bucle es el siguiente:
for (int i=1;i<=rs.getNumRecords();i++){
longitud = rs.getRecordSize(i);
registro = rs.getRecord(i);
System.out.println(“Registro ”+i+“: ”+ new String(registro,0,longitud));
}
Sin embargo, la clase RecordStore proporciona la interfaz RecordEnumeration que facilita ésta tarea.
Utilizando esta interfaz se puede sustituir el bucle anterior por el siguiente
código:
RecordEnumeration re = rs.enumerateRecords(null,null,false);
while (re.hasNextElement()){
registro = re.nextRecord();
//se realizan las operaciones que se desean
...
}
Como se puede ver, la navegación por los registros usando RecordEnumeration es mucho más intuitiva y permite realizar acciones como mover hacia
delante o hacia atrás de una manera muy sencilla.
5.6.6
Búsqueda de Registros
Para realizar una búsqueda eficiente de registros, se debe implementar la interfaz RecordFilter, esta interfaz se encarga de devolver sólo los registros que
coincidan con el patrón de búsqueda especificado.
Para usar esta interfaz se debe implementar necesariamente el método:
5.7. COMUNICACIONES EN J2ME
153
public boolean matches(byte [] candidato), el cual se encarga de comparar el
registro candidato pasado como parámetro con el valor que se quiere buscar y
devolverá true en caso de que coincidan.
5.7
Comunicaciones en J2ME
A pesar de la cantidad de restricciones que soportan los dispositivos MID y
también restricciones propias del lenguaje Java, la gran ventaja que posee este
tipo de dispositivos es la posibilidad de estar siempre “conectados”.
La posibilidad de llevar un dispositivo con poco tamaño y que permita
comunicarse en cualquier momento y lugar abre un abanico de posibilidades
en el desarrollo de aplicaciones [19].
Las aplicaciones MIDP para trabajar en red utilizan las clases contenidas
en los paquetes javax.microedition.io y java.io de la siguiente manera:
• El primer paquete contiene numerosas clases que permitirán crear y
manejar diferentes conexiones de red. Estas conexiones podrán usar
diferentes formas de comunicación: HTTP, datagramas, sockets, etc.
• El paquete java.io se encargará de proporcionar las clases necesarias
para leer y escribir en estas conexiones.
En la figura 5.12 de la página 154 puede verse la jerarquía de clases que
reciben el nombre de Generic Framework Conection (GFC).
En la raíz del árbol se encuentra la interfaz Connection que representa la
conexión más genérica y abstracta que se puede crear. El resto de interfaces
que derivan de Connection representan los distintos tipos de conexiones que
se pueden crear.
5.7.1
Clases y Conexiones del Generic Connection Framework
Lo que proporciona el Generic Connection Framework es una sola clase Connector que esconde los detalles de la conexión.
Esta clase puede por sí misma crear cualquier tipo de conexión: Archivos,
Http, socket,etc.
154
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.12: Jerarquía de Interfaces.
Clase Connector
Como se ha dicho anteriormente, el GCF proporciona la clase Connector que
esconde los detalles de la conexión. De esta forma se puede realizar cualquier tipo de conexión usando sólo esta clase y sin preocuparnos de cómo se
implementa el protocolo requerido.
La conexión se realiza de la siguiente manera:
Connector.open(“protocolo:dirección;parámetros”);
Algunos ejemplo de invocación son:
• Connector.open(“http://direccionquesea.es”);
• Connector.open(“file://autoexec.bat”);
• Connector.open(“socket://direccion:0000”);
La clase Connector se encarga de buscar la clase específica que implemente
el protocolo requerido. Si esta clase se encuentra, el método open() devuelve
5.7. COMUNICACIONES EN J2ME
155
un objeto que implementa la interfaz Connection.
En la tabla 5.19 de la página 155 se puede apreciar los métodos de la clase
Connector.
Métodos
public static Connection
open(String dir)
public static Connection
open(String dir,int modo
public static Connection open(
String dir, int mode,
boolean tespera)
public static DataInputStream
openDataInputStream(String dir)
public static DataOutputStream
openDataOutputStream(String dir)
public static InputStream
openInputStream(String dir)
public static OutputStream
openOutputStream(String dir)
Descripción
Crea y abre una conexión
Crea y abre una
conexión con permisos
Crea y abre una conexión
especificando el permiso
y tiempo de espera
Crea y abre una conexión de
entrada devolviendo para
ello un DataInputStream
Crea y abre una conexi´[on de
salida a través de
un DataOutputStream
Crea y abre una conexión de
entrada usando un InputStream
Crea y abre una conexión de
salida devolviendo para
ello un OutputStream
Tabla 5.19: Métodos de la Clase Connector.
Los tipos de permisos se pueden ver en la tabla 5.20 de la página 156.
La Interfaz Connection
La interfaz Connection se encuentra en lo más alto de la jerarquía de interfaces
del Generic Connection Framework, por lo que cualquier otra interfaz deriva
de ésta.
Una conexión de tipo Connection se crea después de que un objeto Connector invoque al método open(). Como se dijo anteriormente, esta interfaz
representa la conexión más genérica posible por lo que define un sólo método:
156
CAPÍTULO 5. JAVA 2 MICRO EDITION
Modo
READ
READ_WRITE
WRITE
Descripción
Permiso de solo lectura
Permiso de lectura y escritura
Permiso de solo escritura
Tabla 5.20: Tipos de Permisos.
public void close(), que realiza el cierre de la conexión.
Interfaz InputConnection
La interfaz InputConnection representa una conexión basada en streams de
entrada. Esta interfaz sólo posee dos métodos que devuelven objetos de tipo
InputStreams.
En el siguiente ejemplo se ilustra cómo podría utilizarse este tipo de conexión:
String url = “www.midireccion.com”;
InputConnection conexión = (InputConnection)Connector.open(url);
DataInputStream dis = conexion.openDataInputStream();
Interfaz OutputConnection
La interfaz OutputConnection representa una conexión basada en streams de
salida. Esta interfaz sólo posee dos métodos que devuelven objetos de tipo
OutputStreams.
La conexión a través de esta interfaz se realiza de la misma forma a la
interfaz
InputConnection.
5.7. COMUNICACIONES EN J2ME
157
Interfaz StreamConnection
Esta interfaz representa una conexión basada en streams tanto de entrada
como de salida. No añade ningún método nuevo, si no que hereda los métodos
de los interfaces que están por encima de él. Su única misión en la jerarquía
del GCF es representar un tipo de conexión cuyos datos pueden ser tratados
como streams de bytes y en la que es posible leer y escribir.
A continuación un ejemplo de cómo podría utilizarse esta conexión:
StreamConnection sc = (StreamConnection)Connector.open(url);
InputStream is = sc.openInputStream();
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int c;
while((c = is.read()) != -1){
baos.write(c);
}
5.7.2
Comunicaciones HTTP
El protocolo HTTP es un protocolo de tipo petición / respuesta. El funcionamiento de este protocolo es el siguiente: El cliente realiza una petición al
servidor y espera a que éste le envíe una respuesta. Normalmente, esta comunicación es la que suele realizarse entre un navegador web (cliente) y un
servidor web (servidor). En este caso la comunicación se realiza a través de
un MIDlet(cliente) y un Servlet(servidor) que recibirá peticiones y devolverá
los resultados.
Una conexión HTTP pasa por tres estados que se pueden ver en la figura
5.13de la página 158.
Establecimiento de la Conexión
En este estado es donde se van a establecer los parámetros de la comunicación.
158
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.13: Estados de una conexión HTTP.
El cliente prepara la petición que va a realizar al servidor, además de
negociar con él una serie de parámetros como el formato, idioma, etc.
Existen dos métodos que pueden ser invocados. En la tabla 5.21 de la
página 158 se pueden apreciar estos métodos.
Método
public void setRequestMethod(String tipo)
public void setRequestProperty
(String clave, String valor)
Descripción
Establece el tipo de petición
Establece una propiedad de la
petición
Tabla 5.21: Métodos en la Etapa de Establecimiento.
El primer método establece el tipo de petición que se va a realizar. Esta
petición puede ser de los tipos indicados en la tabla 5.22 de la página 159.
El segundo método permite negociar entre el cliente y el servidor detalles
de la petición como, por ejemplo, idioma, formato, etc. Estos campos forman
parte de la cabecera de la petición. En la tabla 5.23 de la página 159 se pueden
ver algunos de los más importantes.
Peticiones GET
5.7. COMUNICACIONES EN J2ME
Tipo
GET
Descripción
Petición de información en la que
los datos se envían como parte del URL
Petición de información en la que
los datos se envían aparte en un stream
Petición de metainformación
POST
HEAD
Tabla 5.22: Tipos de peticiones.
Campo
public void setRequestMethod (String tipo)
User-Agent
Content-Language
Content-Length)
Accept
Connection
Cache-Control
Expires
If-Modified-Since
Descripción
Establece el tipo de petición
Tipo de contenido que
devuelve el servidor
Pais e idioma que usa el cliente
Longitud de la petici n
Formatos que acepta el cliente
Indica al servidor si se quiere
cerrar la conexión después de
la petición o se quiere dejar abierta
Sirve para controlar el almacenamiento
de información
Tiempo m ximo para respuesta del servidor
Pregunta si el contenido solicitado se ha
modificado desde una fecha dada
Tabla 5.23: Campos de la Cabezera.
159
160
CAPÍTULO 5. JAVA 2 MICRO EDITION
A continuación se muestra un ejemplo en el que se prepara una conexión
mediante la interfaz HttpConnection usando una petición de tipo GET.
//se crea la conexión
String url = http://www.midireccion.com/local?opcion=1&us=usuario&pass=1234;
HttpConnection hc = (HttpConnection)Connector.open(url);
//se informa el tipo de conexión a realizar
hc.setRequestMethod(HttpConnection.GET);
// se establece algunos campos en la cabezera
hc.setRequestProperty(“User-Agent”,“Profile/MIDP-2.0
Configuration/CLDC-1.0”);
hc.setRequestProperty(“Content-Language”,“es-ES”);
Como puede apreciarse, la información sobre la petición va incluida en la
cabecera de la dirección URL. El cuerpo de la petición lo forma la cadena:
“opcion=1&us=usuario&pass=1234”.
Esta información va detrás del símbolo “?” situado al final de la dirección
URL. Cada parámetro de la petición va separado del siguiente por el símbolo
“&”.
Peticiones POST
En este tipo de conexión, el cuerpo de la petición se envía en un stream
después de iniciar la conexión. El siguiente ejemplo muestra cómo se realiza
el envío del cuerpo de la petición:
//se crea la conexión
String url = http://www.midireccion.com;
HttpConnection hc = (HttpConnection)Connector.open(url);
// se informa el tipo de petición a realizar
hc.setRequestMethod(HttpConnection.POST);
//se establece algunos campos de la cabezera
5.7. COMUNICACIONES EN J2ME
161
hc.setRequestProperty(“User-Agent”,“Profile/MIDP-2.0
Configuration/CLDC-1.0”);
hc.setRequestProperty(“Content-Language”,“es-ES”);
// se envia el cuerpo de la petición
OutputStream os = hc.openOutputStream();
os.write(opcion=1.getBytes());
os.write(&us=usuario.getBytes());
os.write(&pass=1234.getBytes());
os.flush();
Estado de la Conexión
En este estado se realiza el intercambio de información entre el cliente y el
servidor. En los ejemplos anteriores se ha visto la manera de enviar la petición
al servidor. Ahora se verá cómo se realiza la respuesta del servidor hacia el
cliente.
Respuesta del Servidor
Al igual que la petición del cliente posee distintas partes, la respuesta del
servidor se compone de:
• Línea de estado.
• Cabecera.
• Cuerpo de la respuesta.
Para conocer la respuesta del servidor, la interfaz HttpConnection proporciona diversos métodos que permiten conocer las distintas partes de ésta.
La interfaz HttpConnection dispone de treinta y cinco códigos de estado
diferentes.
Básicamente se pueden dividir en cinco clases de la siguiente manera:
162
CAPÍTULO 5. JAVA 2 MICRO EDITION
• 1xx: Código de información.
• 2xx: Código de éxito.
• 3xx: Código de redirección.
• 4xx: Código de error del cliente.
• 5xx: Código de error del servidor.
Por ejemplo, el código 400 corresponde a la constante HTTP_BAD_REQUEST.
En realidad la respuesta del servidor posee el siguiente formato:
HTTP/1.1 400 Bad Request.
HTTP/1.1 200 OK.
En la respuesta se incluye el protocolo usado, seguido del código de estado
y de un mensaje de respuesta. Este mensaje es devuelto al invocar el método
getResponseMessage().
Estado de Cierre
La conexión entra en este estado una vez que se termina la comunicación entre
el cliente y el servidor invocando al método close().
A continuacion se verá un ejemplo donde se produce una petición mediante
una petición POST, se describirán tanto el código del MIDlet como del Servlet
que recibe la petición y devuelve una respuesta.
Código del MIDlet
package hilo;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import javax.microedition.io.Connector;
import javax.microedition.io.HttpConnection;
5.7. COMUNICACIONES EN J2ME
163
import javax.microedition.lcdui.*;
import javax.microedition.midlet.MIDlet;
public class HiloConexionMidlet extends MIDlet implements CommandListener,
Runnable{
private Display mDisplay;
private Form mMainScreen;
public HiloConexionMidlet(){
mMainScreen = new Form(”HTTP MIDlet”);
mMainScreen.append(”Presione OK para crear una conexión HTTP.”);
mMainScreen.append(”\n”); // Introduce un salto de linea
mMainScreen.append(”Este programa simula un Login.”);
mMainScreen.append(”\n”);
mMainScreen.append(”Usuario: jb”);
mMainScreen.append(”\n”);
mMainScreen.append(”Clave: si”);
Command exitCommand = new Command(”Exit”, Command.EXIT, 0);
Command okCommand = new Command(”OK”, Command.OK, 0);
mMainScreen.addCommand(exitCommand);
mMainScreen.addCommand(okCommand);
mMainScreen.setCommandListener(this);
}
public void startApp() {
if (mDisplay == null){
mDisplay = Display.getDisplay(this);
164
CAPÍTULO 5. JAVA 2 MICRO EDITION
mDisplay.setCurrent(mMainScreen);
}
}
public void pauseApp() {
}
public void destroyApp(boolean unconditional){
}
public void commandAction(Command c, Displayable s){
if(c.getCommandType() == Command.EXIT){
notifyDestroyed();
}else if (c.getCommandType() == Command.BACK){
mDisplay.setCurrent(mMainScreen);
}else if (c.getCommandType() == Command.OK){
// Aqui poner una pantalla de espera.
Form waitForm = new Form(”Conectando...”);
mDisplay.setCurrent(waitForm);
Thread t = new Thread(this);
t.start();
}
}
// metodo Runnable
public void run(){
5.7. COMUNICACIONES EN J2ME
165
String url = ”http://localhost:9080/hiloServer/ServerHilo”;
Form resultsForm = new Form(”Results”);
Command backCommand =
new Command(”Volver”, Command.BACK, 0);
resultsForm.addCommand(backCommand);
resultsForm.setCommandListener(this);
HttpConnection hc = null;
InputStream in = null;
OutputStream os = null;
try {
// aqui se realiza la conexión al servidor.
hc = (HttpConnection)Connector.open(url);
// se envia el cuerpo de la peticion
hc.setRequestMethod(HttpConnection.POST);
hc.setRequestProperty(”Content-Language”,”es-ES”);
hc.setRequestProperty(”User-Agent”,”ProfileMIDP-2.0 Configuration/CLDC1.0”);
hc.setRequestProperty(”Content-Type”,”application/octect-stream”);
os = hc.openOutputStream();
os.write(”usuario=jb”.getBytes());
os.write(”&clave=si”.getBytes());
os.flush();
// se toma la respuesta.
in = hc.openInputStream();
int length = 256;
byte[] raw = new byte[length];
int readLength = in.read(raw);
String message = new String(raw, 0, readLength);
resultsForm.append(message);
}catch (Exception e){
resultsForm.append(new StringItem(”Exception: ”, e.toString()));
}finally{
if (in != null) {
166
CAPÍTULO 5. JAVA 2 MICRO EDITION
try {
in.close();
}catch(IOException ioe){
System.out.println(ioe.getMessage());
}
}
if (hc != null){
try {
hc.close();
}catch(IOException ioe){
System.out.println(ioe.getMessage());
}
}
}
mDisplay.setCurrent(resultsForm);
}
}
Código del Servlet
package hilo;
import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.*;
public class ServerHilo extends HttpServlet {
5.7. COMUNICACIONES EN J2ME
167
public void doGet(HttpServletRequest req, HttpServletResponse resp)throws ServletException, IOException{
}
public void doPost(HttpServletRequest req, HttpServletResponse resp)throws ServletException, IOException{
InputStream in = req.getInputStream();
int length = 256;
byte[] raw = new byte[length];
int readLength = in.read(raw);
String query= new String(raw, 0, readLength);
int index = query.indexOf(”&”);
String usuarioaux = query.substring(0,index);
index = usuarioaux.indexOf(”=”);
String userid = usuarioaux.substring(index+1,usuarioaux.length());
String claveaux = query.substring(index + 1, query.length());
index = claveaux.indexOf(”=”);
String password = claveaux.substring(index+1,claveaux.length());
resp.setContentType(”text/plain”);
PrintWriter out = resp.getWriter();
if(userid.equals(”jb”) && password.equals(”si”)) {
System.out.println(”Login correcto”);
out.println(”Login correcto.”);
} else {
System.out.println(”Login falló.”);
out.println(”Login falló.”);
}
}
168
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.14: Ejemplo de comunicación HTTP de un MIDlet.
}
El ejemplo puede verse en la figura 5.14 de la página 168, estas son capturas
de pantalla de una Palm T|X real, donde se corrió el ejemplo citado.
Entre la pantalla 1 y la pantalla 2 del ejemplo, se realizó una conexión
wi-fi real, la cual se demuestra con imágenes; el proceso de conexión comienza
con una pantalla igual a la figura 5.15 de la página 169 en la cual puede verse
una solicitud de permiso para utilizar tiempo de aire, debido a que el tipo
de conexión que se realizará depende de las capacidades de conectividad del
dispositivo, este tiempo de aire puede ser cobrado o no al usuario, y ese es el
motivo por el cual se solicita permiso antes de realizar la conexión.
Luego de confirmar el permiso, puede verse en la pantalla de la Palm la
figura 5.16 de la página 170, que indica que se está iniciando el proceso de
conexión.
Luego se puede apreciar en la pantalla del dispositivo la figura 5.17 de
página 171 donde se informa que se está conectando a la red wi-fi, que en este
ejemplo se llama SteelNet.
En la figura 5.18 de la pániga 172, puede verse que se está gestionando
la obtención de una dirección IP, para que la Palm pueda comunicarse con el
servidor a través de la red wi-fi SteelNet.
5.7. COMUNICACIONES EN J2ME
Figura 5.15: Solicitud de permiso para utilizar tiempo de aire.
169
170
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.16: Iniciando el proceso de conexión.
5.7. COMUNICACIONES EN J2ME
Figura 5.17: Conectandose a la red wi-fi.
171
172
CAPÍTULO 5. JAVA 2 MICRO EDITION
Figura 5.18: Obteniendo dirección IP.
5.7. COMUNICACIONES EN J2ME
173
Figura 5.19: Conectado a red wi-fi.
La ultima pantalla que se observa en el proceso de conexión es la que
confirma el estado de finalización del proceso, en este caso fue “Conectado”,
esto se puede ver en la figura 5.19 de la página 173.
Capítulo 6
Introducción al DB2
6.1
Bases de Datos
La necesidad de mejorar la manera de acceder y manejar los datos ha evolucionado con el transcurso del tiempo hasta llegar a la generación de los sistemas
de administración de bases de datos relacionales (RDBMS ).
En los últimos tiempos ha surgido una nueva base de datos llamada “Universal”, la cuál es capaz de almacenar y hacer búsquedas no solamente de
datos alfanuméricos sino también de imágenes, audio, video y otros objetos.
Esta ventaja de las bases de datos universales abre un gran número de
oportunidades que permiten mejorar tanto los servicios como las aplicaciones.
Se puede definir una Base de Datos como una serie de datos organizados y
relacionados entre sí, y un conjunto de programas que permitan a los usuarios
acceder y modificar esos datos [21].
Mientras que un archivo normalmente contiene datos acerca de un tipo de
entidad (ej.: personal, órdenes, clientes, ventas), una base de datos contiene
datos acerca de muchos tipos de entidades e información acerca de cómo las
entidades están lógicamente relacionadas entre sí.
Las bases son cualquier conjunto de datos organizados para su almacenamiento en la memoria de un ordenador, diseñado para facilitar su mantenimiento y acceso de una manera estándar. Los datos suelen aparecer en forma
175
176
CAPÍTULO 6. INTRODUCCIÓN AL DB2
de texto, números o gráficos.
Otra definición más completa de bases de datos afirma que es un “conjunto
exhaustivo, no redundante, de datos estructurados, organizados independientemente de su utilización y su implementación en máquina, accesibles en tiempo
real y compatibles con usuarios concurrentes con necesidad de información
diferente y no predecible en el tiempo, donde la información se encuentra almacenada en una memoria auxiliar que permite el acceso directo a un conjunto
de programas que manipulan esos datos” [22].
6.1.1
Objetivos de las Bases de Datos
Automatización de:
• El mantenimiento.
• Cualquier generación de información.
• Cualquier consulta sobre dicha información.
6.1.2
Ventajas de las Bases de Datos
Algunas ventajas de las bases de datos se describen a continuación:
Ahorro de Espacio: No hacen falta archivos de papeles que pudieran
ocupar mucho espacio.
Velocidad: Con la utilización de las bases de datos se pueden modificar,
consultar datos con una velocidad mucho mayor que realizándolo manualmente.
Ahorro de trabajo: ya que las máquinas son encargadas de manejar estas
bases y no se necesitan manejar archivos a mano, existe un ahorro de trabajo
humano.
Actualización: Se dispone en cualquier momento de información precisa
y al día.
Comodidad: Al tener la información en un mismo sitio, se ahorrará tiempo y trabajo.
6.2.
SISTEMA DE ADMINISTRACIÓN DE BASES DE DATOS
177
Disminución de la Redundancia: La duplicación de los datos implica
mayor trabajo en el mantenimiento. Gracias a que las bases de datos disminuyen la redundancia también se disminuye el trabajo.
Compartición de Datos: Se trata de datos actuales, ya que al estar
centralizados, se puede tener acceso a los datos actualizados en prácticamente
tiempo real.
Restricciones de Seguridad: Para mantener la seguridad acerca del
mantenimiento de los datos, los administradores de la Base de Datos, crean
un nivel de acceso, que permitirá o prohibirá a los usuarios hacer una u otra
acción sobre dicha base de datos.
Posibilidad de Mantener la Integridad: En una base de datos se debe
mantener una coherencia.
Esto se controlará mediante:
• Máscaras.
• Reglas de validación.
6.2
Sistema de Administración de Bases de Datos
Una base de datos es una colección de tablas y objetos relacionados entre sí y
organizados como un grupo. La estructura de una base de datos se muestra
en la figura 6.1 de la página 178.
Un DBMS es un conjunto de programas que maneja todos los accesos a
las bases de datos; ver figura 6.2 de la página 178.
Funciones de un DBMS:
— Definición de datos.
— Manipulación de datos.
— Seguridad e integridad de los datos.
— Recuperación y concurrencia de los datos.
— Diccionario de datos.
— Desempeño.
178
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Figura 6.1: Estructura de Una Base de Datos
Figura 6.2: Sistema de Administración de Bases de Datos
6.3. ORGANIZACIÓN DE BASES DE DATOS
6.3
179
Organización de Bases de Datos
Los modelos más comunes de organización de Bases de Datos son:
• Jerárquico.
• En Red.
• Relacional.
• Orientado a Objetos.
6.3.1
Bases de Datos Jerárquicas
Estructura los campos en nodos en una estructura jerárquica. Los nodos son
puntos conectados entre sí formando una especie de árbol invertido. Cada
entrada tiene un nodo padre, que puede tener varios nodos hijos; esto suele
denominarse relación uno a muchos. Los nodos inferiores se subordinan a los
que se hallan a su nivel inmediato superior.
Un nodo que no tiene padre es llamado raíz, en tanto que los que no
tienen hijos son conocidos como hojas. Cuando se desea hallar un campo en
particular, se empieza por el tope, con un nodo padre, descendiendo por el
árbol en dirección a un nodo hijo.
Por Ejemplo: Un Sistema de Reservaciones de una Línea Aérea (ver
figura 6.3 de la página 180).
El Nodo Padre es la Ciudad de Salida en este caso es (Caracas), Nodos
Hijos representando las Ciudades Destino que tiene a su vez Nodos Hijos,
que son el Número de Vuelo. El Número de Vuelo tendrá también Nodos
Hijos, que son los Pasajeros.
Limitaciones de las Base de Datos Jerárquicas
• Al borrar un nodo padre, desaparecen también sus nodos subordinados.
• Sólo podrá añadirse un nodo hijo, si existe el nodo padre.
• Pero lo más significativo es la rigidez de su estructura: sólo un padre
por hijo y ausencia de relaciones entre los nodos hijos.
180
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Figura 6.3: Modelo de Bases de Datos Jerárquica.
6.3.2
Bases de Datos en Red
Se trata también de una organización jerárquica de nodos, pero un nodo hijo
puede tener más de un solo nodo padre (relación muchos a muchos). Existen
los punteros, que son conexiones adicionales entre nodos padres y nodos hijos,
que permiten acceder a un nodo por vías distintas accediendo al mismo en
dirección descendente por las diversas ramas.
Representa una mejora al modelo jerárquico.
Por ejemplo:Los vendedores destacados para distribuir determinados productos en algunas ciudades pueden ilustrar este modelo (ver figura 6.4 de la
página 181).
Cada Producto puede ser distribuido por más de un Vendedor, así mismo
cada Vendedor puede encargarse de diferentes Ciudades.
6.3.3
Bases de Datos Relacional
Esta organización ofrece la mayor flexibilidad ya que los datos se almacenan en
Tablas diferentes, conformadas así mismo por Filas y Columnas. Una tabla
se denomina relación. En una Tabla las Filas contienen los Registros. Las
6.3. ORGANIZACIÓN DE BASES DE DATOS
181
Figura 6.4: Modelo de Bases de Datos en Red.
Columnas representan los Campos. Las Tablas relacionadas poseen un campo
común, el Campo Clave, mediante el cual la información almacenada en una
tabla puede enlazarse con la información almacenada en otra.
El acceso a los datos se realiza mediante consultas escritas en SQL (Structured Query Language). La Organización de Bases de Datos Relacional es la
más difundida en la actualidad debido a su sencillez para realizar operaciones
de adición, eliminación y modificación en contraste con la mayor rigidez de las
Organizaciones Jerárquicas y de Red.
Por ejemplo: En un pequeño negocio, se puede contar con una Tabla de
Clientes y Tabla de Pedidos (ver figura 6.5 de la página 182).
Las órdenes que pertenecen a un determinado cliente son identificadas
colocando el campo de identificación del cliente en la orden (campo clave de
la tabla de clientes), lo cual permite enlazar las dos tablas.
Limitaciones de las Bases de Datos Relacionales
• Estructuras muy simples.
• Poca riqueza semántica.
• No soporta tipos definidos por el ususarios (sólo Dominios).
182
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Figura 6.5: Modelo de Bases de Datos Relacional.
• No soporta Recursividad.
• Falta de Procesamiento/Disparadores.
• No admite Herencia.
6.4
Introducción a DB2 UDB
DB2 UDB Universal Database es una Base de Datos Universal. Es completamente escalable, veloz y confiable.
Corre en modo nativo en casi todas las plataformas como ser: Windows
Vista, NT, Sun Solaris, HP-UX, AIX U, OS/2 entre otros.
DB2 es un software de base de datos relacional. Es completamente multimedia, disponible para su uso en la Web, muy bueno para satisfacer las
demandas de las grandes corporaciones y bastante flexible para servir a los
medianos y pequeños negocios.
DB2 UDB es un sistema manejador de base de datos relacional fuertemente
6.4. INTRODUCCIÓN A DB2 UDB
183
escalable. Es suficientemente flexible para atender estructuras e inestructuras
manejadoras de datos necesarias para usuarios simples de grandes empresas.
Es conveniente para una gama amplia de aplicaciones de los clientes, quienes
pueden desplegar una variedad de plataformas de hardware y software desde
dispositivos manuales a los sistemas multiprocesador paralelos masivos.
6.4.1
Características Generales del DB2 UDB
DB2 UDB es el producto principal de la estrategia de Data Management de
IBM.
DB2 UDB es un sistema para administración de Bases de Datos Relacionales (RDBMS). Es multiplataforma, especialmente diseñada para ambientes
distribuidos, permitiendo que los usuarios locales compartan información con
los recursos centrales. Es el sistema de gestión de datos que entrega una plataforma de base de datos flexible y rentable para construir un sistema robusto
para aplicaciones de gestión.
DB2 UDB libera los recursos con amplio apoyo al open source (fuente
abierta) y plataformas de desarrollo populares como J2EE y Microsoft .NET.
Integridad
El DB2 UDB incluye características de Integridad, asegurando la protección
de los datos aún en caso de que los sistemas sufran un colapso, y de Seguridad
permitiendo realizar respaldos en línea con distintos grados de granularidad,
sin que esto afecte la disponibilidad de acceso a los datos por parte de los
usuarios.
Múltiples Usos
Provee la capacidad de hacer frente a múltiples necesidades, desde Procesamiento Transaccional de Misión Crítica (OLTP), hasta análisis exhaustivo de
los datos para el soporte a la toma de decisiones (OLAP).
184
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Escalabilidad
Sus características distintivas de Escalabilidad le permiten almacenar información en un amplio rango de equipos, desde un PC portátil hasta un complejo
ambiente de mainframes procesando en paralelo.
Web Enabled Para e-Business
Incluye tecnología basada en Web que permite generar aplicaciones en las
Intranets y responder a las oportunidades de negocios disponibles en Internet.
Facilidad de Instalación y Uso
La primera versión de DB2 para NT fue reconocida en el mercado como una
base de datos muy poderosa, pero difícil de instalar y usar.
En esta versión (DB2 UDB V. 8.1), IBM agregó muchas herramientas
gráficas para facilitar el uso para los usuarios, como también para los administradores y desarrolladores. Dicha versión incluye guías para operaciones como
instalación, configuración de performance, setup, etc. Además, se agregaron
herramientas para facilitar las tareas de integración con otras bases de datos,
tecnologías de networking y desarrollo de aplicaciones.
Universalidad
DB2 UDB es, además, la única base de datos realmente universal; es multiplataforma (16 plataformas - de las cuales 10 no son de IBM), brinda soporte
a un amplio rango de clientes, soporta el acceso de los datos desde Internet y
permite almacenar todo tipo de datos:
• Texto, Audio, Imágenes y Video (AIV Extender) (ver figura 6.6 de la
página 185) .
• Documentos XML ( XML Extender) (ver figura 6.7 de la página 185).
6.4. INTRODUCCIÓN A DB2 UDB
Figura 6.6: AIV Extender.
Figura 6.7: XML Extender.
185
186
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Funciones Complementarias del DB2 UDB
Conectividad
Las herramientas de conectividad permiten acceder a los datos más allá de
donde ellos se encuentren. El slogan cualquier cliente, a cualquier servidor,
en cualquier red está completamente sustentado por la funcionalidad que sus
herramientas ofrecen.
DB2 permite acceder a los datos de DB2 en mainframe o AS/400, desde
Windows Vista, NT, Windows 95/98, OS/2 o cualquiera de los Unix soportados. Además, el producto Datajoiner posibilita acceder de forma única y
transparente a los datos residentes en Oracle, Sybase, Informix, Microsoft SQL
Server, IMS, VSAM y otros.
6.5
DB2 UDB Versión 8.1
La versión 8.1 ofrece un soporte más potente para Business Intelligence, Gestión de Datos y Soluciones e-business.
DB2 Universal Database Versión 8.1 contiene muchas características nuevas, que incluyen el Centro de desarrollo, funciones ampliadas de XML Extender, soporte de Linux para DB2 Warehouse Manager, integración de Spatial
Extender con herramientas de IBM Business Intelligence, un nuevo Centro de
duplicación, mejoras de enlace y rendimiento de DB2 Data Links Manager.
Nuevas herramientas de gestión y supervisión de bases de datos, soporte de 64
bits ampliado y nuevos asistentes de Instalación de DB2 y Centro de control
de DB2.
6.5.1
Centro de Desarrollo
En la versión 8.1, el Centro de desarrollo sustituye al Stored Procedure Builder
de anteriores versiones y proporciona un funcionamiento incrementado.
Mediante el Centro de desarrollo, el usuario puede desarrollar procedimientos almacenados y funciones definidas por el usuario como se muestra en la
figura 6.8 de la página 187. También es posible correlacionar tipos estructurados de los Enterprise JavaBeans. Los asistentes simplifican las tareas de
6.5. DB2 UDB VERSIÓN 8.1
187
Figura 6.8: Centro de Desarrollo.
desarrollo.
Las nuevas características incluyen:
• Soporte de varios proyectos y conexiones de base de datos.
• La Vista de servidor para examinar los objetos de desarrollo en el servidor.
• Depurador de SQL para depurar rutinas; incluye vistas para puntos de
interrupción, variables y pila de llamadas.
• Una interfaz mejorada para controlar el entorno de desarrollo.
• Asistentes para construir funciones definidas por el usuario para MQSeries, fuentes de datos OLE DB y documentos XML.
• Asistentes para exportar, importar y desplegar rutinas e información de
proyectos Productos y Paquetes Nuevos.
188
CAPÍTULO 6. INTRODUCCIÓN AL DB2
6.5.2
Mejoras en XML Extender
Se han añadido nuevas características a XML Extender : ahora, XML Extender
soporta servicios de Web con los servicios Web Object Runtime Framework
(WORF), conjunto de herramientas para implantar servicios de Web con DB2.
Asimismo, XML Extender soporta ahora MQSeries, de forma que es posible
enviar documentos XML a las colas de mensajes de MQSeries, y recuperarlos
de las mismas.
6.5.3
DB2 Warehouse Manager
Se han añadido nuevas características y mejoras a DB2 Warehouse Manager :
Con el soporte de carga paralela nativa para DB2 Universal Database Enterprise Server Edition, es posible cargar grandes volúmenes de datos con más
rapidez.
DB2 Warehouse Manager tiene capacidades ampliadas, por lo que se puede
incrementar y mejorar el rendimiento de las operaciones de depósito, manipular y localizar metadatos más deprisa, y ejecutar el agente de depósito,
programas y transformadores en Linux.
Los conectores para la Web y SAP se han mejorado en el paquete de DB2
Warehouse Manager.
6.5.4
Centro de Depósito de Datos de DB2
Se han añadido nuevas características al Centro de depósito de datos:
El soporte de servidor de depósito se amplía a AIX. El servidor de depósito y el iniciador de sesiones de depósito, que se ejecutan como servicios en
Windows, se ejecutan como daemons en AIX.
Es posible exportar e importar metadatos del lenguaje de código y exportar
estos objetos:
• Tablas, archivos y vistas de origen.
• Tablas y archivos de destino.
6.5. DB2 UDB VERSIÓN 8.1
189
El proceso en cascada (varios intervalos) permite gestionar varios pasos
definiendo y habilitando una planificación y un flujo de tareas para los procesos
que contienen los pasos.
Con el nuevo paso Select and Update de SQL, se puede actualizar una
tabla de destino del depósito de datos sin sustituir la tabla completa ni grabar
código adicional.
Ahora, la Guía de aprendizaje de Business Intelligence se compone de dos
guías de aprendizaje más cortas: Guía de aprendizaje de Business Intelligence:
Introducción al Centro de depósito de datos y Guía de aprendizaje de Business
Intelligence: Lecciones ampliadas sobre depósito de datos.
6.5.5
Asistentes de DB2
Asistente para la Configuración de DB2
La instalación de DB2 en plataformas Windows y UNIX resulta más fácil
mediante la utilización del Asistente para la configuración de DB2. Esta interfaz gráfica permite instalar productos DB2 directamente o crear archivos
de respuestas para permitir una instalación posterior. En los sistemas UNIX,
también se puede utilizar el Asistente para la configuración de DB2 para realizar funciones de gestión de instancias.
Asistentes del Centro de Control
En DB2 Versión 8.1, los asistentes que están disponibles en las Herramientas
de administración se han ampliado para abarcar un ámbito más amplio de
funciones, en comparación con las de que se disponía en versiones anteriores
de DB2. Por ejemplo, un asistente de DB2 Versión 8.1 brinda el conjunto
total de opciones disponibles para crear una tabla.
Como se puede observar en la figura 6.9 de la página 190 el asistente para
creación de tablas, que va guiando paso a paso al usuario a través de una
interfaz amigable, permitiendo crear campos de la tabla, definir una clave,
definir un índice y tambien restricciones a la tabla.
190
CAPÍTULO 6. INTRODUCCIÓN AL DB2
Figura 6.9: Asistente Para Crear Tabla.
6.5.6
Centro de Mandatos
El centro de mandatos permite realizar funciones sobre la base de datos como realizar consultas SQL (insert, delete, update, select), crear estructuras
de tablas, modificar índices, etc. Donde un usuario avanzado puede escribir
directamente la sentencia y ejecutarla; ver figura 6.10 de la página 191.
Para usuarios menos avanzados también se dispone de un asistente llamado “SQL ASSIST” que va ayudando al usuario para la realización de una
consulta.
6.5. DB2 UDB VERSIÓN 8.1
Figura 6.10: Centro de Mandatos.
191
Capítulo 7
WebSphere Studio
7.1
¿Qué es WebSphere?
• IBM WebSphere es una plataforma de IBM para el desarrollo y gestión
de sitios web y aplicaciones destinadas al comercio electrónico.
• WebSphere es una plataforma de Software para e-business.
• WebSphere posee una amplia gama de servidores y aplicaciones para
brindar cualquier tipo de capacidades de negocio y ayuda al desarrollo
de las aplicaciones.
• La Plataforma de Software WebSphere está compuesta por un conjunto
de herramientas de e-business integradas y basadas en estándares abiertos de mercado.
• WebSphere es ideal para todas las fases de un e-business, comenzando
desde pequeños sitios Web a mega sitios.
La plataforma de software WebSphere proporciona una completa gama de
habilidades que permiten a los clientes la entrega de altos niveles de servicio a
todos los visitantes del sitio en la web. Administra cargas pico en los servidores
web, mantiene la disponibilidad del sitio en la web, y reconoce contenido de
solicitudes de la web para QoS (calidad de servicio). También permite la
diferenciación de niveles de servicio con base en el tipo de cliente.
193
194
CAPÍTULO 7. WEBSPHERE STUDIO
7.2
Plataforma de Software
La creciente complejidad de los aplicativos de e-business crea muchos desafíos.
Los aplicativos deben ser escalables, fiables y se deben integrar completamente con los sistemas back-end para proteger las inversiones existentes. El
equipo de desarrollo debe poseer las más actualizadas habilidades de programación para acompañar el ciclo de vida del e-business.
Se necesita una plataforma completa, escalable y flexible que proporcione
soporte a la construcción y diseminación de aplicativos de e-business. Las
soluciones de software WebSphere ofrecen las herramientas necesarias para
alcanzar los objetivos de e-business.
Al proporcionar un banco de trabajo abierto que integre y simplifique
diferentes tareas, roles y herramientas, el software WebSphere ayuda a que el
equipo desarrolle, entregue y administre los aplicativos de e-business [18].
El ambiente de desarrollo del software WebSphere:
• Da soporte al desarrollo y cambios rápidos de nuevos aplicativos utilizando un paradigma de desarrollo basado en reglas.
• Proporciona código pre-construido, pre-testeado.
• Proporciona herramientas especializadas para páginas Web y desarrollo
de módulos migrables.
Adicionalmente, servicios basados en estándares Web permiten mezclar
y combinar componentes funcionales de diferentes orígenes de tal forma que
se puede proveer nuevos procesos y servicios al mercado de manera rápida y
eficiente.
La capacidad de un portal de negocios tiene importancia crítica para permitir que las personas interactúen y transaccionen de forma personalizada con
diversos recursos de negocios. Empieza dejando a la medida los ambientes
de usuarios para sus necesidades específicas, integrándolo entonces con otros
usuarios para permitir colaboración en tiempo real, y con los diversos ambientes de TI.
Todo esto permite que las personas trabajen en conjunto de forma más
productiva mientras actúan sobre la información que necesitan. La capacidad
7.2. PLATAFORMA DE SOFTWARE
195
del portal de negocios es proporcionada por la familia WebSphere Portal y la
familia WebSphere Commerce .
7.2.1
WebSphere for Commerce - Soluciones B2B
El e-commerce consiste en realizar negocios con sus clientes, proveedores y
contratistas comerciales sin dificultades en cuanto al tiempo, limitaciones organizacionales o fronteras geográficas.
Con el software With WebSphere Commerce, se establecen relaciones más
estrechas, más productivas con sus clientes y contratistas comerciales en todos
los puntos de contacto. Facilita que sus clientes y contratistas comerciales
hagan negocios hoy y que continúen mañana.
7.2.2
WebSphere for Commerce - Soluciones B2C
El software WebSphere Commerce le permite ir a la línea de las ventas online
a los consumidores.
Crea campañas de marketing dinámicas, fija como objetivo diferentes segmentos de mercado, elabora promociones de producto personalizadas, y mejora
el servicio a clientes.
Esta solución ayuda a crear rápidamente y mantener eficientemente un
sitio interactivo, de alto volumen.
WebSphere Commerce proporciona:
• Personalización del B2B para ayudar a administrar las relaciones de
negocio.
• Tecnología de ventas asistidas para conducir a los clientes y contratistas
a través de la agrupación de requisitos y del proceso de selección del
producto.
• Herramientas de cooperación online y de formación de equipo virtual
para mejorar la eficacia de contratistas comerciales, canal y clientes.
• Administración de pedidos anticipados resultando en capacidades de optimización de operaciones.
196
CAPÍTULO 7. WEBSPHERE STUDIO
• Capacidades avanzadas de inteligencia de negocios para decisiones fundamentales del e-business.
7.2.3
WebSphere for Commerce-Soluciones de Portal
La integración del WebSphere Commerce y WebSphere Portal permite que las
empresas se dirijan a múltiples sectores con necesidades de personalización positivas de soluciones de comercio tanto para las áreas B2B o B2C. Actualmente,
muchas empresas crean sitios separados para cada división, lo que demanda
mucho tiempo y cuesta caro.
El abordaje racionalizado proporciona rápido retorno de inversión al eliminar la necesidad de que la empresa mantenga múltiples sitios. Las empresas
también aumentan la eficiencia de interacciones con clientes y contratistas, lo
que mejora la retención del cliente.
Los productos IBM WebSphere Commerce y WebSphere Portal proporcionan un único punto de interacción con información dinámica y personalizada,
aplicativos, procesos y personas, que son esenciales para construir portales
exitosos para el B2B y B2C.
Con el portal habilitado para el comercio, se puede crear un ambiente
personalizado de comercio provechoso para ambos ambientes, B2B y B2C:
• Ambientes B2B: organizar eficientemente información online, servicios
y aplicativos para contratistas de negocio y proveedores a lo largo de
múltiples divisiones en un portal.
• Ambientes B2C o de ventas al por menor: obtener ventas cruzadas e
impulsar los beneficios, mediante la oferta de acceso a productos, información y servicios desde la Web y de dispositivos inalámbricos, así como
acceso consolidado a catálogos múltiples.
Con un portal de e-commerce integrado, se les puede ofrecer a los clientes, contratistas y proveedores acceso 24x7 a los aplicativos online - rápida y
fácilmente.
7.2. PLATAFORMA DE SOFTWARE
7.2.4
197
WebSphere for Commerce-Soluciones Digital Media
Empresas de medios con volúmenes crecientes de activos digitales -fotos, vídeo
clips, archivos de audio, ilustraciones e imágenes animadas, enfrentan nuevas
exigencias reguladoras y el desafío de colocar esos activos disponibles online. El software WebSphere permite administrar estos activos digitales más
eficazmente, alcanzando clientes en todos el mundo a través de la Web.
WebSphere Commerce para Medios Digitales permite almacenar, buscar,
ver, administrar, colaborar, comprar, vender y hacer download de activos digitales, alcanzando clientes en todo el mundo por la Web. Esta nueva oferta de
servicio de e-commerce combina el software WebSphere Commerce aprobado
por la industria con las capacidades del IBM Content Manager, reforzado por
la tecnología Java.
WebSphere Commerce para Medios Digitales permite enriquecer la experiencia del consumidor y la interfase de compra B2B, creando nuevas relaciones
con clientes al mismo tiempo en que fortalece las existentes y ayudando a generar y aumentar ganancias así como sus márgenes de beneficios.
WebSphere ofrece un amplio portafolio de soluciones clasificadas en tres
áreas críticas:
• Infraestructura y herramientas de Desarrollo (Foundation & Tools):
— Application server.
— WebSphere studio:
∗ IBM WebSphere Studio Site Developer.
∗ IBM WebSphere Studio Application Developer.
∗ IBM WebSphere Studio Application Developer Integration Edition.
∗ IBM WebSphere Studio Enterprise Developer.
∗ IBM WebSphere Studio Homepage Builder.
— Host Access.
• Alcance y experiencia con el usuario (Business Portals):
— WebSphere Portal.
— WebSphere Everyplace.
198
CAPÍTULO 7. WEBSPHERE STUDIO
— WebSphere Commerce.
• Integración de negocio (Business Integration):
— WebSphere Business Integrator.
— WebSphere MQ Integrator.
7.3
Productos WebSphere Studio
WebSphere Studio es una familia de productos de software propietario de IBM,
aunque el término se refiere de manera popular a uno de sus productos específicos: WebSphere Application Server (WAS).
Todos los productos del WebSphere Studio fueron construidos sobre el
Workbench de Eclipse como un sistema de plug-ins conforme al estándar APIs
del Workbench.
La familia del WebSphere Studio tiene actualmente los siguientes miembros
(ver figura 7.1 de la página 199):
• WebSphere Studio Site Developer Advanced .
• WebSphere Studio Application Developer .
• WebSphere Studio Application Developer Integration Edition .
• WebSphere Studio Enterprise Developer .
Cada producto de la familia WebSphere Studio presenta el mismo entorno
de desarrollo integrado (IDE) y una base común de herramientas, por ejemplo
para el desarrollo Java y Web (ver figura 7.2 de la página 199).
7.4
WebSphere Studio Application Developer
WebSphere Studio Application Developer es un producto que se ha desarrollado
basado en el Workbench (banco de trabajo) de Eclipse.
7.4.
WEBSPHERE STUDIO APPLICATION DEVELOPER
Figura 7.1: La familia del WebSphere Studio.
Figura 7.2: WebSphere Studio, entorno de desarrollo.
199
200
CAPÍTULO 7. WEBSPHERE STUDIO
Figura 7.3:
La plataforma del Workbench de Eclipse fue diseñada por IBM y lanzada
a la comunidad de open-source (código abierto).
Este Workbench se ha diseñado para proveer la máxima flexibilidad en el
desarrollo de las herramientas y las nuevas tecnologías que pueden emerger en
el futuro.
La familia del WebSphere Studio Application Developer se basa en un ambiente integrado de desarrollo (IDE), donde este permite desarrollar, probar,
eliminar errores y desplegar su usos. Donde también proporciona la ayuda
para cada fase del ciclo de vida del desarrollo.
Los líderes de la industria de software como: IBM, Borland, Merant, QNX
Software Systems, Rational Software, RedHat, SuSE, TogetherSoft y WebGain
formaron inicialmente la eclipse.org que actualmente administra los directores
del Eclipse open source project.
Eclipse es una plataforma abierta para la integración de herramientas.
Eclipse se ha diseñado a partir de la necesidad de Construir, Integrar los
desarrollos útiles del uso de las tecnologías.
El valor más importante que tiene esta plataforma es: el rápido desarrollo
7.4.
WEBSPHERE STUDIO APPLICATION DEVELOPER
201
Figura 7.4: Plataforma de Eclipse.
de herramienta siendo esta una de las características basadas en un modelo
plug-in (ver figura 7.4 de la página 201).
7.4.1
Ventajas de Utilizar a WebSphere Studio Application
Developer
La ventaja fundamental consiste en la integración de todos los entornos de
desarrollo Java Web en una única plataforma de desarrollo.
J2EE:
• Herramientas de importación/exportación, generación de código, edición
de deployment descriptors estandars, extensiones y bindings (mapeos)
específicos para WebSphere Application Server (WAS).
• Herramienta de mapeo EJB-RDB soportanto tanto top-down, como
bottom-up y meet-in-the-middle.
• Herramientas de edición gráfica de esquemas de bases de datos.
202
CAPÍTULO 7. WEBSPHERE STUDIO
• Herramientas para la creación, edición y validación de ficheros EAR.
• Editores para deployment descriptors (ejb-jar.xml y application.xml).
Desarrollo Java:
• Nuevo Editor Visual Java para GUIs (Swing y AWT).
• Nueva generación de JavaDoc.
• Soporte JDK 1.3.
• Capacidad de utilizar diferentes JREs.
• Compilación incremental automática.
• Posibilidad de ejecutar código incluso con errores.
• Protección contra crashs y auto-recovery.
• Error Reporting y corrección.
• Editor Java con asistente contextual.
• Herramientas de refactoring de código.
• Búsquedas inteligentes y herramientas para comparar código y “merge”.
• Scrapbook para evaluación rápida de código.
Web Services:
• Nuevo soporte UDDI Version 2.
• Soporte UDDI privado.
• Nuevo soporte de WSIL.
• Posibilidad de crear un web service a partir de un fichero ISD.
• Visualización de UDDI business entry para localización de web services
existentes.
7.4.
WEBSPHERE STUDIO APPLICATION DEVELOPER
203
• Creación de web services a partir de código existente (JavaBeans, RLSs,
DB2 XML Extender calls, procedimientos almacenados DB2 y queries
SQL).
• Crear wrappers SOAP y HTTP GET/POST de código existente.
• Generación de proxies desde el Web Services Client/Wizard para tratar
mensajes SOAP.
• Generación de una aplicación de ejemplo, a partir de la cual crear el
resto.
• Realizar el test de un web service local o remoto.
• Deployment de un web service sobre el entorno de test de tanto WebSphere Application Server como Tomcat.
• Publicar web services en un UDDI business registry.
• Nuevos menús pop-up para la creación y consumo de web services, además de los típicos wizards.
XML:
• Entorno totalmente visual.
• Editor de XML con posibilidades de validación de documentos.
• Editor de DTD con posibilidades de validación de documentos.
• Editor de XML schemas.
• Editor de XSL.
• Debugger de XSL y herramienta de transformación para aplicar XSL a
XML.
• Editor de mapping XML - XML.
• Wizard de creación de XML a partir de queries SQL.
• Editor de mapping RDB - XML.
Desarrollo web:
204
CAPÍTULO 7. WEBSPHERE STUDIO
• Nuevo soporte para XHTML y Struts.
• Nuevo entorno visual de construcción de aplicaciones basado en struts.
• Editor visual de HTML y JSPs.
• Edición y validación de JavaScript.
• Soporte de JSP Custom tags (taglibs) 1.2.
• Edición de imágenes y animaciones.
• Edición de CSS.
• Importación via HTTP/FTP.
• Exportación vía FTP a un servidor.
• Visualización de links, broken links, etc.
• Wizards para la creación de servlets.
• Wizards para la creación de proyectos J2EE.
• Wizards para la creación de aplicaciones web.
Testing y Deployment:
• Incrementa la productividad de forma muy importante.
• Entorno ligero de carga rápida.
• Permite pruebas unitarias locales.
• Permite debugger de código en el servidor a través del debugger integrado.
• Permite configurar diferentes aplicaciones web.
• TCP/IP monitoring server.
• Permite instalar los siguientes entornos, tanto locales como remotos:
(WebSphere Application Server AEs Version 4.0.3 and Version 5, WebSphere Application Server - Express Version 5, Apache Tomcat).
7.4.
WEBSPHERE STUDIO APPLICATION DEVELOPER
205
Tracing, Monitoring y Performance:
• Performance Analyzer muestra los tiempos de ejecución y ayuda a detectar memory leaks.
• Muestra información de los objetos existentes.
• Tiene capacidades de “Pattern extraction”.
• Es posible monitorizar varios procesos simultáneamente, incluso corriendo en diferentes máquinas.
• Codificación por colores de las clases.
• Presentación de los resultados en modo gráfico y estadístico.
• Soporte de profiling a nivel de objetos.
• Análisis de los logs de WebSphere Application Server e interacción con
la bases de datos de problemas.
• Edición de items en la base de datos de problemas.
Debugger:
• Muy similar al existente en VisualAge for Java.
• Permite realizar debug tanto a código local como a código residente en
el servidor.
7.4.2
Desarrollando Aplicaciones Java
Los lineamientos que se deben seguir para crear una aplicación Java en WebSphere Application Developer son los siguientes:
• Crear un proyecto Java.
• Crear paquetes dentro del proyecto.
• Crear clases.
206
CAPÍTULO 7. WEBSPHERE STUDIO
• Ejecutar el programa.
• Localizar errores.
Para crear un proyecto Java se debe seleccionar archivo → Nuevo → Proyecto, de desplegará el cuadro de diálogo de Nuevo Proyecto, se debe seleccionar Java y proyecto Java en el diálogo y hacer click en siguiente para iniciar el
asistente de creación de proyectos. Luego se debe indicar en la primer página
el nombre del proyecto y click en aceptar; (ver figura 7.5 de la página 206).
Figura 7.5: Asistente de Proyecto Java.
El proyecto es creado con las opciones que se hayan configurado anteriormente en las preferencias o con las que tiene por defecto. Estas preferencias
puede ser modificadas dirigiendose al menu Ventana → Preferencias y luego
Java → Proyecto Nuevo.
Se pueden agregar paquetes al proyecto para tener una estructura más
ordenada de la aplicación. Para ello se debe seleccionar en la vista de exploración de paquetes Nuevo → Paquete en el menú. En la ventana de diálogo
se tiene que indicar el nombre del paquete y hacer clic en finalizar; ver figura
7.6 de la página 207.
7.5. WEBSPHERE APPLICATION SERVER
207
Figura 7.6: Paquete Java.
Luego de haber finalizado el código y compilado los errores, se puede ejecutar el programa. Se tiene que seleccionar la opción ejecutar de la barra de
herramientas.
Si es la primera vez que se ejecuta ese código se abre el diálogo ejecutar
configuraciones. Como se puede ver en la figura 7.7 de la página 208 se puede
seleccionar el tipo de configuración para ejecutar el programa.
7.5
7.5.1
WebSphere Application Server
Introducción
El WebSphere Application Server representa una familia de software para servidores de aplicaciones. Permite a las empresas responder a los mercados
cambiantes sin migrar a tecnologías diferentes preservando las inversiones hechas en tecnología previamente disponible en la organización, soporta normas
abiertas vigentes en las organizaciones, proporciona soporte pleno a la plataforma abierta Java 2 y Java 2 Enterprise Edition (J2EE) y también provee
soporte para servicios bajo normas abiertas en la Web [23].
208
CAPÍTULO 7. WEBSPHERE STUDIO
Figura 7.7: Diálogo de Configuración de Ejecución.
WebSphere Application Server, es una plataforma de alto desempeño y extrema escalabilidad para diseminar aplicativos dinámicos de e-business, proporciona las funciones esenciales de e-business de manipulación de transacciones y ampliación de datos back-end del negocio y aplicativos para la Web.
La plataforma ayuda a construir aplicativos que ejecutan esas funciones
con seguridad sólida, fiabilidad y escalabilidad.
7.5.2
WebSphere Application Server Como Plataforma Para
el Comercio Electrónico
Brinda un soporte amplio para aplicaciones de comercio electrónico. Se caracteriza por su flexibilidad para adaptarse a cambios en los mercados y en los
objetivos comerciales.
Construyendo aplicaciones en esta robusta plataforma, se pueden integrar
diversos ambientes de las IT (Tecnología de Información), para aprovechar al
máximo las inversiones existentes.
Se pueden instalar aplicaciones comerciales existentes para su acceso desde
7.5. WEBSPHERE APPLICATION SERVER
209
Figura 7.8: WebSphere para e-bussines.
la Web y escalar estas aplicaciones para adecuarlas a las necesidades de los
cambios y de la demanda.
En la figura 7.8 de la página 209 se puede observar la plataforma del
Software de WebSphere para e-bussines.
7.5.3
Application Server - Advanced Edition
La Edición Avanzada es la oferta del principal servidor de aplicativo dirigido
a desarrolladores profesionales de tecnología Java que necesitan funcionalidad
de servicios J2EE y Web para aplicativos dinámicos de e-business.
Esta Edición del WebSphere Application Server, está disponible en tres
configuraciones:
• Edición Avanzada:
— Proporciona integración sólida a las bases de datos, middleware
orientado a mensajes, y sistemas preexistentes y aplicativos, en conjunto con soporte de agrupación. Esta configuración se ajusta a la
210
CAPÍTULO 7. WEBSPHERE STUDIO
mayoría de los escenarios de la empresa e interesa a los negocios que
necesitan construir aplicativos altamente transaccionales, administrables, disponibles y escalables que ofrecen seguridad distribuida
y administración remota.
• Edición Avanzada del Single Server :
— Proporciona el mismo modelo de programación esencial J2EE y
Web Services con administración simplificada. Esta configuración
interesa a departamentos, negocios de tamaño mediano y aplicativos piloto que necesitan un costo bajo, opción de ejecución rápida,
distribución de carga de trabajo o administración remota asociados
a administración de multi-servidor.
• Edición Avanzada del IBM WebSphere Application Server, para Linux
en zSeries:
— La Edición Avanzada del WebSphere Application Server, para Linux en zSeries continúa cumpliendo el compromiso de IBM en cuanto a mantener cobertura amplia para plataformas para el WebSphere Application Server.
— Este producto WebSphere tiene la combinación potente de un rico
conjunto de dispositivos y soporte a estándares abiertos del WebSphere Application Server y el ambiente operacional familiar del sistema operativo Linux.
— También contiene los recursos de administración, alta fiabilidad, y
la intensa velocidad de comunicación de datos internos del hardware
de la plataforma zSeries.
7.5.4
Application Server - Enterprise Edition
La Edición empresarial del IBM WebSphere Application Server, en conjunto
con IBM WebSphere Studio Application Developer Integration Edition, ofrece
una combinación potente de tiempo de ejecución y herramientas que permiten
integrar activos IT existentes, mejorar la productividad del desarrollador y
crear y mantener aplicativos de e-business flexibles.
Juntos, el IBM’s WebSphere Application Server Enterprise Edition y el
WebSphere Studio Application Developer Integration Edition permiten a los
desarrolladores la capacidad de:
7.5. WEBSPHERE APPLICATION SERVER
211
• Coreografiar visualmente y componer servicios de la Web y componentes
de aplicativo J2EE a través de una interfase simple drag-and-drop.
• Construir potentes adaptadores de aplicativo basados en J2EE Connector Architecture (JCA) para integrar sistemas back-end con servicios
Web y aplicativos J2EE.
• Obtener una infraestructura completa de servicios Web que impulse un
ambiente único, eficaz en cuanto a costo de tiempo de ejecución del
servidor del aplicativo administrativo y operacional.
• Evitar la repetición del desarrollo y diseminación de aplicativos debido a
condiciones cambiantes del mercado, separando las políticas del negocio
de la lógica de aplicativos esenciales.
• Crear una paleta de componentes de aplicativos que puede ser rápidamente montada para desarrollar nuevos aplicativos fácilmente publicada
como servicio Web.
7.5.5
Application Server - Standard Edition
La Edición Estándar para desarrolladores de la web y autores de contenido
incluye mejorías de facilidad de uso en toda su extensión, comprendiendo un
Quick Installation que elimina conjeturas en cuanto al Enhanced Java, impulsando el Software Development Kit del Java 2 V1.2.2 en todos los sistemas
operativos soportados.
7.5.6
Servidor HTTP
IBM WebSphere Application Server trabaja con un servidor HTTP para manejar las peticiones de servlets y otros contenidos dinámicos desde las aplicaciones Web.
El servidor HTTP y el servidor de aplicaciones se comunican utilizando
el plug-in HTTP de WebSphere para el servidor HTTP. El plug-in HTTP
utiliza un archivo de configuración XML de fácil lectura para determinar si la
petición la debe gestionar el servidor Web o el servidor de aplicaciones. Utiliza
el protocolo HTTP estándar para comunicarse con el servidor de aplicaciones.
212
7.5.7
CAPÍTULO 7. WEBSPHERE STUDIO
Servidor de Aplicaciones
El servidor de aplicaciones colabora con el servidor Web intercambiando peticiones de clientes y respuestas de aplicaciones. Puede definir varios servidores
de aplicaciones, cada uno de ellos ejecutándose en su propia Máquina Virtual
Java (JVM).
7.5.8
Contenedor de EJB
El contenedor de EJB proporciona los servicios de tiempo de ejecución necesarios para desplegar y manejar componentes EJB, conocidos como enterprise
beans. Es un proceso de servidor que maneja peticiones para beans de sesión
y beans de entidad.
Los enterprise beans (dentro de los módulos EJB) instalados en un servidor de aplicaciones no se comunican directamente con el servidor; en su lugar,
el contenedor de EJB ofrece una interfaz entre los enterprise beans y el servidor. Juntos, el contenedor y el servidor proporcionan el entorno de tiempo de
ejecución del bean.
El contenedor proporciona muchos servicios de bajo nivel, incluido el soporte de hebras y transacciones. Desde un punto de vista administrativo, el
contenedor gestiona el almacenamiento y la recuperación de datos para los
beans que contiene. Un solo contenedor puede gestionar más de un archivo
JAR de EJB.
7.5.9
Contenedor Web
Los servlets y los archivos JSP (Java Server Pages) son componentes del servidor que se utilizan para procesar peticiones de clientes HTTP como, por
ejemplo, navegadores Web. Se encargan de la presentación y el control de
la interacción del usuario con los datos de aplicación subyacentes y la lógica
empresarial.
El contenedor Web procesa servlets, archivos JSP y otros tipos de inclusiones de servidor. Los servlets anteriores a J2EE se ejecutarán en un motor
de servlets. Cada contenedor Web contiene automáticamente un único gestor
de sesiones.
7.5. WEBSPHERE APPLICATION SERVER
213
Cuando se manejan los servlets, el contenedor Web crea un objeto de
petición y un objeto de respuesta, e invoca el método de servicio de servlets.
El contenedor Web invoca el método destroy() del servlet cuando corresponda
y descarga el servlet, y después la JVM ejecuta la recolección de basura.
7.5.10
Contenedor de Clientes de Aplicaciones
Los clientes de aplicaciones son programas Java que se ejecutan normalmente
en un sistema de sobremesa con una interfaz gráfica de usuario (GUI). Tienen
acceso a toda la gama de componentes y servicios del servidor J2EE.
El contenedor de clientes de aplicaciones maneja programas de aplicaciones de Java que acceden a los beans enterprise, Java Database Connectivity
(JDBC) y las colas de mensajes de Java Message Service. El programa Cliente
de aplicaciones J2EE se ejecuta en las máquinas cliente.
Este programa sigue el mismo modelo de programación Java que otros
programas Java; no obstante, el cliente de aplicaciones J2EE depende del
tiempo de ejecución del cliente de aplicaciones para configurar su entorno de
ejecución, y utiliza el espacio de nombres JNDI (Java Naming and Directory
Interface) para acceder a los recursos.
7.5.11
Sistema Principal Virtual
Un sistema principal virtual es una configuración que permite que una única
máquina de sistema principal parezca varias máquinas de sistema principal.
Los recursos asociados con un sistema principal virtual no pueden compartir
datos con recursos asociados con otro sistema principal virtual, incluso si los
sistemas principales virtuales comparten la misma máquina física.
Los sistemas principales virtuales permiten al administrador asociar aplicaciones Web con un sistema principal particular configurado para la máquina
que ejecuta la aplicación.
7.5.12
Virtual Hosts (Hosts Virtuales)
Un host virtual es una configuración que permite a una sola máquina host
aparentar ser múltiples máquinas hosts. Permite que una sola máquina física
214
CAPÍTULO 7. WEBSPHERE STUDIO
configure y administre independientemente varias aplicaciones administradas.
No está asociado a un nodo particular (máquina). Es una configuración, diferente de un “objeto vivo”, indicando que puede crearse, pero no arrancarse o
detenerse.
Cada host virtual tiene un nombre lógico y una lista de uno o más seudónimos de DNS por los cuales es conocido. Un seudónimo de DNS es el nombre
TCP/IP del host y el número del puerto que use la petición del servlet, por
ejemplo su nombre Host:80.
El WebSphere Application Server proporciona un host virtual predefinido, denominado “el default_host”, con algunos seudónimos comunes, como
el IP de la máquina, nombre corto del host, y el nombre del host completo. El seudónimo comprende la primera parte del camino para el acceso a un recurso, como un servlet. Por ejemplo, localhost:80 en la petición
http://localhost:80/servlet/snoop.
Los hosts virtuales le permiten al administrador aislar y manejar independientemente los múltiples grupos de recursos en la misma máquina física.
7.6
Workplace Client Technology Micro Edition
Workplace Client Technology Micro Edition (WCTME) es una plataforma intergrada para la extensión de aplicaciones empresariales existentes hacia dispositivos clientes manejados por servidor como ser un computador de escritorio,
sistemas móviles, PDAs, y otros dispositivos móviles y pervasivos.
El paquete integrado combina las herramientas WebSphere Studio Device
Developer y Micro Environment Toolkit for WebSphere Studio, con los tiempos
de ejecución de WebSphere Everyplace Micro Environment, Service Management Framework (SMF), y WebSphere Everyplace Custom Environment, y
el middleware (DB2e, MQe, Web Services), para construir, testear y lanzar
software cliente manejado por servidor en dispositivos pervasivos.
En escencia WCTME es la plataforma base para la familia WCT que ofrece
IBM y provee una plataforma robusta que soporta dispositivos desde teléfonos
celulares, PDAs y otros dispositivos con teclado, móviles y hasta sistemas de
escritorio.
Independientemente de que si la computadora está siempre, ocasionalmen-
7.6. WCTME
215
te o rara vez conectada, el modelo WCTME permite extender las aplicaciones
y modelos de programación usando los estándares de la industria y sin tener
que volver a reescribir todo usando estos dispositivos.
La plataforma WCTME está construida como una combinación de una
plataforma cliente rica basada en el modelo de Eclipse (originalmente ideado
para herramientas, y motivado para ser una plataforma de aplicación más genérica) al igual que el modelo basado en navegador. Eclipse es una plataforma
para la construcción de herramientas de desarrollo de software potentes y ricas
aplicaciones de escritorio [24].
7.6.1
WebSphere Everyplace Micro Environment
WebSphere Everyplace Micro Environment es una implementación de IBM de
la especificación J2ME que cumple con la autorización y líneas guías funcionales definidas por Sun Microsystem para obtener “Java Powered Logos”.
7.6.2
WebSphere Everyplace Custom Environment
Similar a Websphere
Custom Environment
habilitar a clientes y
run times específica,
establecidos.
7.6.3
Everyplace Micro Enviroment, WebSphere Everyplace
provee un conjunto mayor de librerías y funciones para
asociados a crear versiones más a medida de la Java
sin necesariamente tener que cumplir con estándares
J9
La J9 es una implementación independiente de IBM de la Maquina Virtual
de Java. La combinación de la J9 junto con la configuración y los perfiles
conforman el ambiente de ejecución o run times.
Las configuraciones y perfiles son librerías de clases en Java.
7.6.4
WebSphere Studio Device Developer
WebSphere Studio Device Developer es un IDE de IBM para J2ME que extiende Eclipse para el desarrollo de aplicaciones Java o C/C++ que corren en
216
CAPÍTULO 7. WEBSPHERE STUDIO
dispositivos pervasivos, y forma el núcleo del WCTME.
7.6.5
Java 2 Micro Edition (J2ME)
J2ME es un plataforma Java para dispositivos embebidos.
Al igual que las plataformas Enterprise J2EE y escritorio J2SE, J2ME
es un conjunto de APIs Java estándar que entrega el poder y los beneficios
de la tecnología Java a medida para los dispositivos embebidos, incluyendo
interfaces de usuario flexibles, modelo de seguridad robusto, gran rango de
protocolos de red y soporte para aplicaciones conectadas y desconectadas a la
red.
7.7
WebSphere Studio Device Developer
Device developer es un IDE (Integraded Development Enviroment) para el
desarrollo, depuración y despliegue de aplicaciones que serán lanzadas en computadoras de mano y otros dispositivos pequeños [24].
Esto ayuda a los desarrolladores a crear aplicaciones que habilitan a los
dipositivos (teléfonos celulares, PDAs, y computadoras de mano) a formar
parte de una solución “e-businnes end-to-end”.
El entorno de desarrollo integrado también viene con una copia del WebSphere Micro Environment (IBM-compatible con J2ME JVM), con licencia para el desarrollo.
Con WebSphere Studio Device Developer se extiende las capacidades del
workbench permitiendo:
• Crear aplicaciones WebSphere Studio Device Developer y correrlas localmente.
• Crear una Suite de MIDlet y correla localmente (en un emulador de
MIDlet).
• Lanzar y depurar aplicaciones en varios dispositivos.
7.7. WEBSPHERE STUDIO DEVICE DEVELOPER
7.7.1
217
Componentes de WebSphere Studio Device Developer
El Workbrenck de Device Developer incluye como componetes a una J9, utilidades, y un paquete de herramientas para el desarrollo más el SmartLinker
para el preenlazado de archivos .class en la aplicación.
J9 Runtimes, Utilidades y Herramientas
El WebSphere Studio Device Developer incluye como componentes a un paquete de J9 runtimes, utilidades y herramientas, para construcción y lanzamiento
de aplicaciones Java en el ambiente de desarrollo.
Actualmente, los ambientes de desarrollos soportados son:
• Windows XP/2000.
• Red Hat Linux 8.
MicroAnalyzer
MicroAnalyzer es usado para perfilar y analizar la ejecución de los programas
en un dispositivo embebido.
En la vista Analizer se pueden agregar eventos de usuario al código y
rastrear su ejecución en una prueba física corriendo en una maquina virtual
J9. Esta información puede ser usada para optimizar los programas en cuanto
a velocidad, tamaño y eficiencia global.
7.7.2
Herramienta de Desarrollo C (CDT) para Eclipse
Device Developer incluye el CDT (C Development Tooling) de Eclipse que
permite escribir código C e integrar con aplicaciones Java.
Se pueden crear proyectos en lenguaje C en el espacio de trabajo, construir
y compilar estos proyectos y enlazarlos a otros proyectos (estos son, WebSphere
Studio Device Developer o otros proyectos Java) en el espacio de trabajo o
WorkSpace.
218
CAPÍTULO 7. WEBSPHERE STUDIO
7.7.3
Arquitectura de Device Developer
WebSphere Studio Device Developer forma parte de la familia WebSphere. Todo producto WebSphere Studio tiene un apecto en común, el WebSphere Studio
Workbench (WSWB ), que es la versión de IBM de la plataforma Eclipse.
Eclipse es un IDE de código abierto (open-source). Utiliza un plug-in
diseñado para ampliar su funcionalidad básica, ya que solo hace muy poco.
Debido a que es de código abierto, se podrá contribuir a su desarrollo.
Periódicamente, IBM toma una instantánea de Eclipse y los distribuye
como el WebSphere Studio Workbench, que está diseñado para ser una plataforma de desarrollo para socios de negocio para ampliar la arquitectura básica
y complementos.
Estas herramientas también deben ser capaces de conectar a Eclipse, así
como los miembros de la familia de productos de WebSphere Studio.
7.7.4
Utilización del IDE
WebSphere Studio Device Developer utiliza el concepto de espacio de trabajo
o workspace, un directorio que contiene el código de trabajo (un subdirectorio
por cada proyecto), y un subdirectorio de metadatos que contienen información
sobre el código.
La creación de un acceso directo es importante cuando se desee utilizar
múltiples espacios de trabajo, puesto que se puede usar la bandera “-data”
para poner un específico espacio de trabajo en ejecución, por ejemplo, wsdd.exe
-data “C:\user_workspace\project”, se utilizará el subdirectorio project en el
directorio user_workspace como su espacio de trabajo.
WebSphere Studio Device Developer también utiliza el concepto de proyecto, una colección de paquetes que componen la totalidad de una aplicación, ya
sea Java u otra. Por ejemplo, se podrá crear un proyecto Java, J2ME, MIDlet,
C u otro tipo.
Se puede pensar a un proyecto como un super-paquete.
La pantalla de bienvenida actúa como un archivo readme para la versión
de la herramienta, y se muestra automáticamente la primera vez que se invoca
7.7. WEBSPHERE STUDIO DEVICE DEVELOPER
219
Figura 7.9: Barra de herramientas de WSDD.
el producto. También se encuentra en el menú Ayuda.
La herramienta se divide en Perspectivas, barras de herramientas, vista, y
editores. La pantalla entera es a veces llamado el Workbench.
Una perspectiva es una colección predefinida de barras de herramientas,
vistas y editores [25].
Barra de Herramientas
La barra de herramientas superior que se encuentra bajo el menú principal,
contiene a todos los asistentes disponibles de WebSphere Studio Device Developer (ver figura 7.9 de la página 219).
Los asistentes se pueden utilizar para crear aplicaciones, probar código,
crear estructuras Java, crear proyectos, crear dispositivos, configurar dispositivos, generar construcciones de un proyecto para su distribución.
La barra izquierda de herramientas contiene todas las perspectivas y / o
vistas abiertas.
220
CAPÍTULO 7. WEBSPHERE STUDIO
Perspectiva, Editores y Vistas
Una perspectiva es un grupo de vistas y editores en la ventana del espacio de
trabajo diseñadas para centrarse en una determinada tarea.
En una ventana del espacio de trabajo pueden existir una o varias perspectivas.
Cada perspectiva contiene una o varias vistas y editores.
Dentro de una ventana, cada perspectiva puede tener un conjunto distinto
de vistas, pero todas las perspectivas comparten el mismo conjunto de editores.
También se puede personalizar perspectivas y guardarlas.
Una vista es un componente visual del espacio de trabajo.
Se suele utilizar para navegar en una jerarquía de información (como los
recursos del espacio de trabajo), abrir un editor o visualizar propiedades del
editor activo.
Las modificaciones efectuadas en una vista se guardan inmediatamente.
Sólo puede existir una instancia de un tipo de vista concreto en una ventana
del espacio de trabajo.
Un editor se utiliza para modificar los archivos, y es específico para el tipo
de archivo que está siendo editado.
Con WebSphere Studio Device Developer, se puede especificar editores externos para determinados tipos de archivo.
Sólo un editor puede estar activo en cualquier momento, varios editores se
podrán abrir, pero todos estarán en la misma ventana, disponible a través de
pestañas.
El editor del código fuente es una de las ventanas principales del WSDD.
Este editor está siempre presente, aunque cambiemos entre las distintas
perspectivas.
Como su nombre lo indica, en este editor se muestra el código fuente de la
clase con todos sus elementos. Pero además incluye diversas funcionalidades
para ayudar al desarrollador, entre ellas se tiene:
7.7. WEBSPHERE STUDIO DEVICE DEVELOPER
221
Figura 7.10: Métodos de un Objeto.
• Utiliza distintos colores para diferenciar entre palabras reservadas, comentarios, cadenas de texto, y nombres de variables. De este modo se
puede encontrar e identificar más fácilmente una línea de texto o una
instrucción.
• Muestra los campos y métodos pertenecientes al objeto al que se está
haciendo referencia según se va escribiendo (ver figura 7.10 de la página
221). De esta forma, se puede elegir el que se quiera a través de la lista.
• Además, en la lista de métodos de los objetos, se indican los parámetros
necesarios en la llamada al mismo, y el tipo del valor que devuelve, junto
con una breve descripción del mismo.
• Incluye una función automática para cerrar paréntesis y corchetes.
• En caso de cometer algún error de sintaxis, remarca la parte de código
errónea en rojo.
• Utiliza advertencias que son subrayados amarillos. Las advertencias no
serán causa de error, pero ayudan a mejorar el código; por ejemplo,
importar alguna clase que no se utilice nunca.
Dispositivos
Cada dispositivo requiere una configuración separada. Todos los dispositivos se comparten, por lo que cualquier proyecto puede ser desplegado en un
dispositivo específico.
222
CAPÍTULO 7. WEBSPHERE STUDIO
WebSphere Studio Device Developer soporta dispositivos Palm (a través de
HotSync), emulador Palm, y dispositivos PocketPC (a través de ActiveSync)
directamente.
WebSphere Studio Device Developer también ejecutará proyectos a nivel local JVM, y aplicaciones MIDP pueden ser desplegados en un emulador MIDP.
Otros proveedores pueden incluir emuladores soportados a través de plugins Eclipse. Estos deben estar disponibles a través del gestor de actualizaciones, o directamente desde el proveedor.
Añadir Emuladores
Una manera de probar las aplicaciones que se diseñan es añadiendo emuladores
que proveen los fabricantes. Webphere Studio Device Developer permite añadir
emuladores de distintos fabricantes.
Capítulo 8
Descripción de la Aplicación
8.1
Introducción
El presente trabajo consiste en la creación de una aplicación con Software
de Computación Móvil Multiplataforma, que permita el acceso a información
situada en bases de datos multiplataforma en un servidor Web, a través de
dispositivos móviles tales como PDAs.
El objetivo esencial de este trabajo es llevar a la práctica la comunicación
entre un PDA y un Servidor Web, teniendo acceso a los datos almacenados en
un motor de bases de datos alojado en el servidor.
Para esto se ha enfocado el problema dentro de un caso de estudio, el cual
es la concepción llevada a la realidad de lo que podría ser un sistema comercial
para un restaurant, aplicando las últimas tecnologías para lograr así no solo
alcanzar el objetivo principal sino también proveer de ventajas competitivas
en el rubro para aquél restaurant que utilice sistemas de este tipo.
El sistema realizado pretende reducir los tiempos requeridos en la atención al cliente dentro del restaurant, cubriendo la mayor parte de operaciones
esenciales requeridas por una entidad dedicada a la gastronomía.
Para el desarrollo del trabajo se utilizó el lenguaje de programación Java,
debido a que sus características lo hacen adecuado para el propósito planteado:
seguridad, robustez y sobre todo, portabilidad.
La variedad de dispositivos existentes en el mercado condiciona que la apli223
224
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
cación deba ser compatible con todos ellos. Como es conocido, la portabilidad
es una de las características inherentes al lenguaje Java.
8.2
Estructuración
El sistema está compuesto por dos módulos principales, uno móvil que correrá
en el PDA al cual se lo ha llamado MobileChef, y otro Web al cual se lo ha
llamado J-Chef, este ultimo correrá en un servidor web en la Intranet del
restaurant. Se ha desarrollado también un tercer módulo que simula ser el
sitio web de un restaurant ficticio llamado Miarritze para completar el ideal
de lo que debería ser un sistema para un restaurant.
Los módulos principales J-Chef y MobileChef correrán en la Intranet del
restaurant, y las comunicaciones se realizarán a través de una conexión inalámbrica wi-fi.
El sistema está pensado para que trabaje con distintos tipos de perfiles
de usuario, donde cada perfil tendrá funciones específicas de acuerdo al cargo
que representan los usuarios. A continuación se verán los distintos perfiles de
usuario y a que módulos pertenecen:
• Módulo Intranet J-Chef :
— Administrador.
— Jefe de Cocina.
— Cajero.
• Módulo Móvil MobileChef :
— Mozo.
• Módulo Internet Miarritze:
— Administrador Web.
— Cliente Web.
El sistema principal está formado por los módulos J-Chef y MobileChef,
por lo tanto se muestra en la figura 8.1 de la página 225 los casos de uso que
involucran a los usuarios de ambos módulos.
8.2. ESTRUCTURACIÓN
Figura 8.1: Casos de uso del Sistema Principal. J-Chef y MobileChef.
225
226
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.2: Casos de Uso del módulo Miarritze.
En la figura 8.2 de la página 226 se muestran los casos de uso con respecto
a los usuarios del módulo complementario Miarritze.
8.3
Modelo de datos
El manejador de bases de datos que utiliza el sistema es el DB2 UDB V. 8.1.
A continuación se detallará el modelo de datos del sistema principal, el
mismo se puede apreciar en la figura 8.3 de la página 227.
La base de datos del sistema principal tiene por nombre CHEFDB y las
entidades que la componen son las siguientes:
• CARGOS.
• CATEGORIAS.
• CONFIGURACIONES.
8.3. MODELO DE DATOS
227
Figura 8.3: Modelo de datos del Sistema Principal.
• FACTURAS.
• ITEM_MENU.
• PEDIDOS_CABECERA.
• PEDIDOS_DETALLES.
• SUB_CATEGORIAS.
• TIPO_ITEM_MENU.
• USUARIOS.
Ahora se verán los campos que conforman cada tabla.
CONFIGURACIONES: Esta tabla contiene las configuraciones necesarias para el correcto funcionamiento del sistema. Por ejemplo la fecha de
última modificación del menú y también la cantidad de mesas con las que
operará el sistema, los campos que la componen son los siguientes.
228
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
• ID_CONF: Es el campo clave de la tabla. Contiene el número único de
la configuración.
• NOMBRE_CONF: Es el nombre que se le da a la configuración.
• VALOR_CONF: Es el dato propiamente dicho de la configuración.
CARGOS: Contiene los distintos cargos que pueden asumir los usuarios
del sistema, está compuesta por los siguientes campos.
• ID_CARGO: Es el campo clave de la tabla. Contiene el número único
del cargo.
• NOMBRE_CARGO: Contiene el nombre del cargo.
USUARIOS: Contiene los datos de los usuarios del sistema principal.
Los campos que la componen son:
• ID_USUARIO: Es el campo clave de la tabla. Es el identificador único
de cada usuario.
• CARGO: Actúa como clave foránea estableciendo la relación con la tabla
CARGOS, indica el cargo del usuario.
• NOMBRE: Es el nombre del usuario.
• APELLIDO: Es el apellido del usuario.
• FEC_NAC: Es la fecha de nacimiento del usuario.
• USUARIO: Es el pseudónimo que el usuario utilizará para logearse al
sistema.
• PASS: Es la contraseña que el usuario utilizará para logearse al sistema.
• HR_ENTRADA: Indica la hora en que el usuario debe empezar a trabajar en el restaurant.
• HR_SALIDA: Indica el horario de finalización de la jornada laboral del
usuario.
• TELEFONO: Es el número de teléfono del usuario.
8.3. MODELO DE DATOS
229
• DNI: Es el número del Documento Nacional de Identidad del usuario.
• MAIL: Es la dirección de email del usuario.
• CANT_FACTURAS: Indica la cantidad de facturas que ha facturado el
usuario, solo se cargará si el usuario es un cajero.
• CANT_PEDIDOS: Indica la cantidad de pedidos que ha levantado el
usuario, solo se cargará si el usuario es un mozo.
TIPO_ITEM_MENU: Contiene los distintos tipos de ítems de menú
con los que funciona el sistema, estos son Comidas o Bebidas, y los campos
que la componen son:
• ID_TIPO: Es el campo clave de la tabla. Es el identificador del tipo de
ítem de menú.
• NOMBRE_TIPO: Contiene el nombre del tipo de ítem de menú.
CATEGORIAS: Contiene las distintas categorías de los ítems de menú,
está compuesta por los siguientes campos.
• ID_CAT: Es el campo clave de la tabla. Es el identificador de la categoría a la cual pertenece un ítem de menú.
• ID_TIPO: Es la clave foránea que relaciona la tabla CATEGORIAS con
TIPO_ITEM_MENU.
• NOMBRE_CAT: Es el nombre de la categoría.
SUB_CATEGORIAS: Contiene las distintas sub categorías de los ítems
de menú. Está compuesta por los siguientes campos.
• ID_SUB: Es el campo clave de la tabla. Es el identificador único de la
sub categoría.
• ID_CAT: Funciona como clave foránea estableciendo la relación con la
tabla CATEGORIAS.
• NOMBRE_SUB: Es el nombre de la sub categoría.
230
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
ITEM_MENU: Esta tabla contiene todos los ítems de menú que forman
la carta del restaurant. Está compuesta por los siguientes campos:
• ID_ITEM: Es el campo clave de la tabla. Es el identificador único de
cada ítem.
• ID_CAT: Es una clave foránea que relaciona esta tabla con CATEGORIAS.
• ID_SUB: Es una clave foránea que relaciona esta tabla con SUB_CATEGORIAS.
• NOMBRE_ITEM: Es el nombre del ítem de menú.
• DESCRIPCION: Es la descripción del ítem.
• PRECIO: Es el precio del ítem.
PEDIDOS_CABECERA: Contiene los datos principales de los pedidos
que levantan los mozos, los campos que componen esta tabla son:
• ID_PEDIDO: Es la clave de la tabla. Es el identificador único de un
pedido.
• ID_MOZO: Actúa como clave foránea estableciendo la relación con la
tabla USUARIOS, e identifica al usuario con cargo “mozo” que ha levantado el pedido.
• MESA_NRO: Es el número de mesa a cual corresponde este pedido.
• FECHA: Es la fecha en que se ha levantado el pedido.
• ESTADO: Indica el estado en que se encuentra el pedido.
• DIA_DE_SEMANA: Indica que día de la semana fue levantado el pedido.
• HOUR: Indica a qué hora fue levantado el pedido.
PEDIDOS_DETALLES: Contiene los detalles de un pedido_cabecera,
es decir contiene los ítems de menú que conforman el pedido de una mesa
determinada. Los campos que conforman esta tabla son:
8.3. MODELO DE DATOS
231
Figura 8.4: Modelo de datos del sitio web Miarritze.
• ID_DETALLE: Es el campo clave de la tabla. Es el identificador único
de un detalle de pedido.
• ID_PEDIDO: Actúa como clave foránea estableciendo la relación con
la tabla PEDIDOS_CABECERA.
• ID_ITEM: Actúa como clave foránea estableciendo la relación con la
tabla ITEM_MENU.
• CANTIDAD: Es la cantidad de porciones o unidades del ítem de menú
que se ha solicitado en la mesa.
• OBSERVACIONES: Representa algún tipo de observación que haya realizado un cliente acerca del ítem de menú que solicitó.
• ESTADO: Es el estado de un detalle de pedido.
A continuación se detallará el modelo de datos del sitio web Miarritze, el
mismo se puede apreciar en la figura 8.4 de la página 231.
La base de datos del mismo tiene por nombre WEBCHEF y las entidades
que la componen son las siguientes:
232
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
• CONFIGURACIONES.
• USUARIOS.
• TIPO.
• CATEGORIAS.
• SUB_CATEGORIAS.
• ITEM_MENU.
• RESERVA_CABECERA.
• RESERVA_DETALLES.
Ahora se verán los campos que conforman cada tabla.
CONFIGURACIONES: Esta tabla contiene las configuraciones necesarias para el correcto funcionamiento del sistema. Por ejemplo la dirección IP
y el Puerto donde el sitio web puede comunicarse con el servidor donde corre
J-Chef para convertir las reservas en pedidos, los campos que la componen son
los siguientes:
• ID_CONF: Es el campo clave de la tabla. Contiene el número único de
la configuración.
• NOMBRE_CONF: Es el nombre que se le da a la configuración.
• VALOR_CONF: Es el dato propiamente dicho de la configuración.
USUARIOS: Esta tabla contiene los datos de los usuarios web, estos
pueden ser de dos tipos, o administrador o cliente. Los campos que componen
esta tabla son:
• COD_USUARIO: Es el campo clave de la tabla. Es el identificador
único de cada usuario web.
• TIPO_USUARIO: Identifica el tipo de usuario, si es un administrador
o un cliente.
• USUARIO: Es el pseudónimo con el que el usuario se va a logear.
8.3. MODELO DE DATOS
233
• PASS: Es la contraseña con la que el usuario se va a logear.
• NOMBRE: Es el nombre del usuario.
• APELLIDO: Es el apellido del usuario.
• DNI: Es el Documento Nacional de Identidad del usuario.
• EMAIL: Es el email del usuario.
• TEL: Es el teléfono del usuario.
TIPO: Contiene los distintos tipos de ítems de menú con los que funciona
el sistema, estos son Comidas o Bebidas, y los campos que la componen son:
• ID_TIPO: Es el campo clave de la tabla. Es el identificador del tipo de
ítem de menú.
• NOMBRE_TIPO: Contiene el nombre del tipo de ítem de menú.
CATEGORIAS: Contiene las distintas categorías de los ítems de menú,
está compuesta por los siguientes campos.
• ID_CAT: Es el campo clave de la tabla. Es el identificador de la categoría a la cual pertenece un ítem de menú.
• ID_TIPO: Es la clave foránea que relaciona la tabla CATEGORIAS con
TIPO.
• NOMBRE_CAT: Es el nombre de la categoría.
SUB_CATEGORIAS: Contiene las distintas sub categorías de los ítems
de menú. Está compuesta por los siguientes campos.
• ID_SUB: Es el campo clave de la tabla. Es el identificador único de la
sub categoría.
• ID_CAT: Funciona como clave foránea estableciendo la relación con la
tabla CATEGORIAS.
• NOMBRE_SUB: Es el nombre de la sub categoría.
234
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
ITEM_MENU: Esta tabla contiene todos los ítems de menú que forman
la carta del restaurant. Está compuesta por los siguientes campos:
• ID_ITEM: Es el campo clave de la tabla. Es el identificador único de
cada ítem.
• ID_CAT: Es una clave foránea que relaciona esta tabla con CATEGORIAS.
• ID_SUB: Es una clave foránea que relaciona esta tabla con SUB_CATEGORIAS.
• NOMBRE_ITEM: Es el nombre del ítem de menú.
• DESCRIPCION: Es la descripción del ítem.
• PRECIO: Es el precio del ítem.
RESERVA_CABECERA: Contiene los datos principales de las reservas que solicitan los clientes web, los campos que componen esta tabla son:
• NRO_RESERVA: Es la clave de la tabla. Es el identificador único de
una reserva.
• COD_USUARIO: Actúa como clave foránea estableciendo la relación
con la tabla USUARIOS, e identifica al cliente que ha solicitado la reserva.
• FECHA: Es la fecha en que la reserva debe concretarse.
• HORA: Es la hora en que la reserva debe concretarse.
• CANT_PERSONAS: Indica la cantidad de personas que desean asistir
a la fecha y hora indicadas en la reserva.
• COMENTARIOS: Indica algun tipo de comentario que realiza el cliente
a la hora de solicitar la reserva.
• ESTADO: Indica el estado de la reserva.
RESERVA_DETALLES: Contiene los detalles de una reserva_cabecera,
es decir contiene los ítems de menú que conforman el pedido de una reserva
determinada. Los campos que conforman esta tabla son:
8.4. DESCRIPCIÓN DE MOBILECHEF
235
• ID_DET_RESERVA: Es el campo clave de la tabla. Es el identificador
único de un detalle de reserva.
• ID_RESERVA: Actúa como clave foránea estableciendo la relación con
la tabla RESERVA_CABECERA.
• ID_ITEM: Actúa como clave foránea estableciendo la relación con la
tabla ITEM_MENU.
• CANTIDAD: Es la cantidad de porciones o unidades del ítem de menú
que se ha solicitado el cliente web en la reserva.
8.4
Descripción de MobileChef
La interfaz gráfica de MobileChef es una interfaz simple, permite una fácil
interacción con el usuario, es estándar para todos los PDAs que soportan
J2ME.
Por razones de que se trata de una aplicación de negocios y para lograr
la mayor portabilidad posible del aplicativo, para desarrollar la interfaz de
usuario se eligió a las APIs de alto nivel, donde no se tiene un control total
del aspecto de los controles, ya que su estética depende exclusivamente del SO
del dispositivo donde se ejecute. Para más información acerca de interfaces
gráficas ver capítulo cinco (J2ME).
Otro aspecto muy interesante a la hora de desarrollar una aplicación móvil
utilizando J2ME es poder almacenar localmente cierta información útil en el
PDA para no tener que volver a realizar una petición al servidor sobre datos
solicitados anteriormente.
MobileChef proporciona la posibilidad de almacenar cierto tipo de información (como ser la totalidad de ítems de menú, categorías y sub categorías,
como también ciertas configuraciones) en la zona de almacenamiento persistente del PDA.
Para implementar esta funcionalidad, utiliza el sistema de gestión de registros, conocido como Record Management System (RMS). Más adelante se
describirá con más detalle la estructura de estos registros.
MobileChef posee conectividad con un servidor Web, para lograr esto utiliza una conexión wi-fi. Y al ser un dispositivo con capacidades limitadas
236
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
de almacenamiento y procesamiento la aplicación minimiza el intercambio de
datos.
Esto quiere decir que el PDA debe poseer conectividad wi-fi como requisito
para poder utilizar el sistema y por supuesto poder ejecutar aplicaciones Java.
Como se ha mencionado en el capítulo cinco (J2ME) las aplicaciones que
se desarrollan bajo la configuración CLDC (Conected Limited Device Configuration) y el perfil MIDP (Mobile Information Device Profile) se denominan
MIDlets. Por lo tanto como MobileChef se desarrolló bajo la configuración
CLDC 1.1 y el perfil MIDP 2.0 es un MIDlet.
En el desarrollo del sistema principal (J-Chef y MobileChef ) se estableció
que la utilización de PDAs se limitaba solo a aquellos usuarios cuyo cargo
fuese el de “Mozo”, siendo MobileChef un aplicativo de uso exclusivo de los
mismos.
El aplicativo fue probado en una Palm TX real, y de ella se obtuvieron
las capturas de pantalla.
En la figura 8.5 de la página 237 se ve la pantalla de Aplicaciones en una
Palm TX, en esta pantalla puede observase el icono de la aplicación MobileChef.
La figura 8.6 de la página 238 representa la pantalla inicial de MobileChef.
Esta pantalla inicial ofrece al usuario, tres posibles acciones, estas son:
• Entrar.
• Configuración.
• Salir.
Si el usuario presiona con el stylus el botón “Salir”, el aplicativo se cierra
y el usuario vuelve a ver la pantalla de la figura 8.5 de la página 237.
Antes de empezar a utilizar MobileChef, es necesaria una configuración
correcta del aplicativo, entonces si el “Mozo” presiona con el stylus el botón
“Configuración” podrá observar una pantalla como la que se ve en la figura
8.7 de la página 239. Cuando esta pantalla se ejecuta por primera vez en
el dispositivo móvil, se crea un Record Store llamado ConfCon, en el cual se
almacenan datos por defecto a fin de establecer los campos necesarios de la
8.4. DESCRIPCIÓN DE MOBILECHEF
237
Figura 8.5: Pantalla de Aplicaciones de una Palm TX con SO Garnet 5.4.9.
238
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.6: Pantalla Inicial de MobileChef.
8.4. DESCRIPCIÓN DE MOBILECHEF
239
Figura 8.7: Pantalla de Configuración de MobileChef.
configuración de MobileChef. Estos datos por defecto no garantizan que el
aplicativo se conecte correctamente al servidor, sino que solo son utilizados
para crear los registros necesarios. Luego el usuario deberá ingresar la dirección IP y el Puerto correspondientes para que la conexión con el servidor se
realice de manera correcta.
Los datos que se almacenan por defecto son:
• IP del Servidor: 192.168.1.101
• Puerto: 9080
• Fecha de última modificación del menú: Se almacena la fecha que se
obtiene al lanzar la pantalla por primera vez.
• Número de mesas: 10
240
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.8: Pantalla Default Settings.
Esta pantalla ofrece tres opciones al usuario: Guardar, Default Settings y
Volver.
Si el usuario presiona “Guardar” se actualizarán los campos en el Record
Store ConfCon.
Si el usuario presiona “Default Settings”, se cargarán los datos de ejemplo,
con una leyenda comunicando que estos datos son solo un ejemplo de lo que
el usuario debería introducir en estos campos como se puede observar en la
figura 8.8 de la página 240.
Si el usuario presiona “Volver”, volverá a ver la pantalla inicial de la figura
8.6 de la página 238.
Ahora bien, si el usuario presiona “Entrar” verá la pantalla que se muestra
en la figura 8.9 de la página 241, la cual representa el inicio del proceso de
login.
8.4. DESCRIPCIÓN DE MOBILECHEF
Figura 8.9: Inicio del Proceso de Login.
241
242
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.10: Pantalla de Alerta.
En este punto se pueden dar diversas situaciones que se detallarán a continuación.
Si el usuario presionara “Entrar” cuando alguno de los campos esté vacio,
el aplicativo mostraría una alerta como la que se ve en la figura 8.10 de la
página 242, indicando el error.
Ahora bien, suponiendo que el usuario ha llenado los campos correctamente, en este punto se iniciaría la conexión con la red wi-fi, este proceso de
conexión puede verse en el último ejemplo del capítulo cinco (J2ME).
Pero aunque el usuario haya llenado correctamente los campos “Usuario”
y “Contraseña”, puede haber olvidado configurar previamente el aplicativo,
por lo que si durante el proceso de login, el aplicativo no puede conectarse
al módulo J-Chef que se encuentra en el servidor, MobileChef mostrará una
pantalla como la “Pantalla 1” de la figura 8.11 de la página 243.
Supongamos ahora, que el usuario ha configurado correctamente el aplica-
8.4. DESCRIPCIÓN DE MOBILECHEF
243
Figura 8.11: Posibles situaciones del Proceso de Login.
tivo, y ha llenado correctamente los campos requeridos, esto nos lleva a tres
nuevos posibles desenlaces en el proceso de login.
Una posibilidad es que el usuario que se logea desde el PDA, haya llenado
correctamente los campos, pero que esos datos no coincidan con datos registrados en el server, los cuales corresponden a usuarios válidos. En esta situación
MobileChef informará al usuario que intenta logearse con una pantalla como
la “Pantalla 2” que vemos en la figura 8.11 de la página 243 donde se aprecia
el mensaje que dice que los datos ingresados no coinciden con los registrados.
Otra posibilidad es que algún usuario registrado en el sistema principal
intente logearse desde un PDA, es decir un “Administrador”, “Cajero” o “Jefe de Cocina” intente logearse desde el PDA. Este usuario posee datos que
coinciden con los registrados en la base de datos, por lo tanto el mensaje informativo es distinto y se lo puede apreciar en “Pantalla 3” de la figura 8.11
de la página 243.
Ahora veremos el desenlace que debería ser el habitual, es decir, un “Mozo”
que ha configurado correctamente el aplicativo y que ha llenado correctamente con sus datos los campos requeridos para el ingreso al sistema. En este
caso se podrá observar una pantalla como la que muestra la figura 8.12 de la
página 244. Donde en la pantalla se van añadiendo cadenas de texto que van
informando al usuario en que etapa del proceso de login se encuentra en cada
244
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.12: Progreso del Proceso de Login.
momento.
En el proceso de login, se realizan procesos intermedios destinados a almacenar los ítems de menú, las Categorías, y Sub Categorías en sus respectivos
Record Stores. Más adelante se explicarán en detalle tanto estructura como
funcionamiento de los mismos.
Este proceso “extra” Login, comienza solo si el proceso de login fue satisfactorio, y su primer chequeo es el de comparar la Fecha de última modificación
del menú que se registró en el Record Store ConfCon contra la Fecha de última
modificación del menú que se encuentra en la Tabla CONFIGURACIONES
de la base de datos del sistema principal, si estas fechas no coinciden se deben
cargar en el PDA todas las Categorías, Sub Categorías e Ítems de menú que
se leen de la base de datos CHEFDB.
También se actualiza el número de mesas con las que trabajará el restaurant.
8.4. DESCRIPCIÓN DE MOBILECHEF
245
Figura 8.13: Menú Principal de MobileChef.
Luego de todo este proceso, el sistema mostrará la pantalla principal de
MobileChef, la cual se puede observar en la figura 8.13 de la página 245.
Esta pantalla constituye el menú principal de MobileChef, el cual habilita tres posibles acciones, las cuales son: “Salir”, “Levantar Pedido” y “Ver
Pedidos”.
8.4.1
Levantar Pedidos
Si el mozo presiona en el menú principal “Levantar Pedidos” verá una pantalla
como la de la figura 8.14 de la página 246. Allí deberá seleccionar primero
un número de mesa, y luego seleccionar “Comidas” o “Bebidas” según lo que
solicite el cliente en ese momento. Si el mozo selecciona Comidas o Bebidas y
no ha seleccionado un número de mesa, el aplicativo muestra una pantalla de
error diciendo que debe seleccionar primero el número de mesa.
246
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.14: Pantalla donde el Mozo debe seleccionar el Nro de mesa, y si el
cliente solicitó una Comida o una Bebida.
8.4. DESCRIPCIÓN DE MOBILECHEF
247
Figura 8.15: Levantar Pedido.
Supongamos que el mozo ha seleccionado la Mesa Número 1, y luego “Comidas”, lo que verá inmediatamente después, serán las Categorías que se corresponden con el Tipo Comidas, esto se puede apreciar en “Pantalla 1” de la
figura 8.15 de la página 247.
Luego el mozo debe seleccionar una de esas categorías, para poder ver los
ítems de menú que se corresponden con la misma.
Supongamos que el mozo ha seleccionado “Plato Principal”, esta Categoría, posee Sub Categorías, las cuales se observan en “Pantalla 2” de la figura
8.15 de la página 247.
Luego supongamos que el mozo selecciona la Sub Categoría “Carnes”, en
ese momento se realiza la búsqueda de los ítems de menú en el Record Store
que los almacena, y se obtienen solo aquellos que se corresponden a esa Sub
Categoría, como se ve en “Pantalla 3” de la figura 8.15 de la página 247.
Luego el mozo, deberá seleccionar el ítem que ha solicitado el cliente, y
verá una pantalla que describe la información de dicho ítem, esto puede verse
en “Pantalla 1” de la figura 8.16 de la página 248. Allí podrá ingresar observaciones que provee el cliente, y también la cantidad de dicho ítem, ya que
varios comensales de la misma mesa podrían pedir el mismo ítem.
Luego, si presiona “Cargar”, este ítem se carga en un array localmente,
248
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.16: El item se ha cargado de manera local.
esto se puede ver en “Pantalla 2” de la figura 8.16 de la página 248, es decir,
en ese momento todavía no se envía la orden al servidor, esto es porque el
mozo puede seguir cargando ítems a la orden.
Si el mozo presiona “Atrás”, podrá por ejemplo cargar del mismo modo
una Bebida, y la orden podría quedar como se muestra en la figura 8.17 de la
página 249.
Antes de enviar el pedido al servidor, el mozo tiene la posibilidad de editar
el mismo. Si el mozo presiona el botón (...) que se ve en “Pantalla 2” de
la figura 8.16 de la página 248, se desplegará un menú como el que se ve
en “Pantalla 1” de la figura 8.18 de la página 250. Pudiendo así realizar la
edición del pedido como se describe en las pantallas que muestra la figura de
la página. Aquí podrá editar o quitar esa orden del pedido.
En “Pantalla 2” de la figura 8.18 de la página 250 se muestra una lista con
las ordenes que componen al pedido de la mesa en cuestión, el mozo podrá
8.4. DESCRIPCIÓN DE MOBILECHEF
Figura 8.17: Items de una Orden.
249
250
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.18: Editar Pedido.
seleccionar aquel ítem que desea modificar o quitar del pedido.
Una vez que el mozo haya finalizado de cargar las ordenes que solicitaron
los clientes, el pedido se puede enviar, presionando el botón “Enviar” que se
ve en la descripción del pedido, esto se muestra en la figura 8.17 de la página
249.
Hasta este momento se había realizado solo una comunicación entre MobileChef y J-Chef que se encuentra en el servidor.
Cuando el mozo presiona enviar se establece una nueva comunicación con
J-Chef para que este cargue en la base de datos CHEFDB los datos correspondientes al pedido recientemente levantado, si la transacción se completó correctamente el mozo recibirá como respuesta una pantalla como la que muestra
la figura 8.19 de la página 251, de otro modo recibirá una pantalla informando
el error.
8.4.2
Ver Pedidos
En esta sección el mozo puede ver las mesas para las cuales él mismo ha
levantado pedidos, y puede ver también los pedidos de cada mesa.
Si el mozo presiona en el menú principal “Ver Pedidos”, esto inicia una
8.4. DESCRIPCIÓN DE MOBILECHEF
Figura 8.19: El envío de los datos se realizó correctamente.
251
252
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.20: Mesas con pedidos del mozo.
comunicación con J-Chef, el cual consultará la base de datos para recuperar
aquellas mesas con pedidos del mozo que inicio la comunicación.
Esto hace que puedan darse dos situaciones.
Al momento de seleccionar “Ver Pedidos”, el mozo puede no tener ninguna
mesa con pedidos levantados por él, entonces MobileChef lo informará con una
pantalla como “Pantalla 1” de la figura 8.20 de la página 252.
Si el mozo al momento de solicitar este comando tuviese mesas con pedidos,
recibirá un listado de los números de mesa con pedidos, como se ve en “Pantalla
2” de la figura 8.20 de la página 252.
Si el mozo tiene mesas para atender, podrá ver los pedidos de las mismas
y podrá agregar nuevas ordenes al pedido.
También puede darse el caso de que un mozo tenga una mesa sin pedidos,
es decir debe atender una mesa a la cual él mismo no ha levantado pedidos,esta
8.4. DESCRIPCIÓN DE MOBILECHEF
253
Figura 8.21: El Administrador ha atendido una Reserva y la ha convertido en
Pedido Activo.
opción se da cuando el “Administrador” ha atendido una reserva y la pasó al
sistema como un pedido activo. Esta situación puede verse en la figura 8.21
de la página 253.
Nótese que cada orden que conforma un pedido, posee entre paréntesis
a su extremo derecho, su estado actual. Si dicho estado es Abierto el mozo
también podrá modificar esa orden. Esto se debe a que si el estado de la orden
es Abierto esto indica que no se ha atendido todavia esa orden en la cocina.
Los posibles estados que puede asumir una orden son los siguientes:
• Abierto: La orden no ha sido atendida por la cocina. Puede ser editada
o anulada.
• Anulado: La orden ha sido editada y se ha puesto en cero su cantidad.
• Atendiendo: La orden ha sido atendida en la cocina, es decir, se esta
254
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.22: Se ha habilitado el comando Cerrar debido a que todas las ordenes poseen un estado Entregado.
cocinando el plato que ha solicitado el cliente.
• Entregado: La orden ha sido entregada al mozo para que este la entregue
en la mesa correspondiente.
Solo los ítems de menú de tipo “Comidas”, pueden pasar de estado Abierto
a Atendiendo, debido a que necesitan ser preparados en la cocina.
En cambio, los ítems de tipo “Bebidas” nunca podrán tener estado Atendiendo debido a que estos solo se entregan, entonces estos pueden pasar de
Abierto a Anulado o bien a Entregado.
Ahora bien, si todas las ordenes del pedido poseen un estado Entregado
esto habilita el comando “Cerrar” como lo describe la figura 8.22 de la página
254.
El mozo cerrará un pedido cuando el cliente “Pida la Cuenta”, es decir
8.4. DESCRIPCIÓN DE MOBILECHEF
255
Figura 8.23: Formulario donde se capturan los datos necesarios para la posterior Facturación.
marca la finalización en el consumo por parte de los clientes de una mesa
determinada.
En este punto ese pedido está listo para ser facturado, este proceso lo
empieza el mozo, ya que cuando cierra un pedido aparecerá en la pantalla del
PDA un formulario como el de la figura 8.23 de la página 255.
En donde el mozo, solo cargará los datos de como el cliente desea que se
facture lo que ha consumido.
Será tarea del usuario “Cajero” facturar propiamente dicho, el pedido en
cuestión.
Cuando un pedido es cerrado este ya no aparecerá en la pantalla del “Jefe
de Cocina”, y luego de que el mozo cargue el formulario con los datos previos
a la facturación este pedido aparecerá en la pantalla del “Cajero”.
256
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.24: Se ha registrado correctamente el pedido para poder ser Facturado por el Cajero.
Luego de que el mozo haya cargado el formulario previo a la facturación del
pedido, recibirá una respuesta como la que muestra la figura 8.24 de la página
256, esto si se ha finalizado la transacción correctamente, de otro modo recibirá
una respuesta de error.
Al presionar “Continuar”, el mozo regresará al menú principal y podrá
continuar con su trabajo.
8.4.3
Estructura de los Record Stores de MobileChef
Gracias a la implementación del sistema de gestión de registros (RMS) se
puede guardar información en el PDA.
Sabiendo que los registros de un Record Stores están formados por pares
tipo clave - valor, donde:
8.4. DESCRIPCIÓN DE MOBILECHEF
257
— Clave: es el identificador único del registro.
— Valor: es el valor del registro propiamente dicho, almacenado en
un formato tipo “bytes”.
Se han utilizado los siguientes Record Stores:
— ConfCon
— Categorias
— SubCategorias
— ItemsMenu
Se presenta entonces su estructura.
Record Store ConfCon:
Cuando MobileChef ejecuta por primera vez la pantalla de configuración,
en esta se trata de leer este Record Store, pero para poder leerlo antes se lo
debe abrir.
Al abrir el Record Store ConfCon, se establece el atributo que indica que
si este no existe se lo debe crear.
Cuando se crea el Record Store ConfCon se registran los datos por defecto.
ConfCon solo almacena cuatro registros, los cuales se ven a continuación
con los datos por defecto que se asignan:
— IP del Servidor: 192.168.1.101
— Puerto: 9080
— Fecha de última modificación del menú: se ingresa la fecha en que
se ejecutó por primera vez la pantalla de Configuraciones.
— Cantidad de mesas: 10
Luego estos son editados con los valores correctos.
Al chequear la Fecha de última modificación del menú, si esta no coincide
con la Fecha de última modificación del menú que se encuentra en el servidor,
se deben cargar los Record Stores Categorias, SubCategorias e ItemsMenu.
Record Store Categorías:
258
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Está compuesto por los siguientes campos:
— Id_tipo
— Id_Categoria
— Nombre_Categoria
Para delimitar un campo de otro se utiliza “@”, de la siguiente manera:
— registro = Id_tipo@Id_Categoria@Nombre_Categoria
Donde registro es una cadena “String” y debe ser transformado a flujos de
bytes antes de ser insertado al RecorStore “Categorias”.
Record Store SubCategorias:
Maneja los siguientes campos:
— Id_Categoria
— Id_Sub
— Nombre_Sub
Para delimitar un campo de otro se utiliza “@”, de la siguiente manera:
— registro = Id_ Categoria@Id_ Sub@Nombre_Sub
Record Store ItemsMenu:
Maneja los siguientes campos:
—
—
—
—
—
—
Id_Categoria
Id_Sub
Id_Item
Nombre_Item
Descripcion
Precio
Para delimitar un campo de otro se utiliza “@”, de la siguiente manera:
— registro = Id_Categoria@Id_Sub@Id_Item@Nombre_Item@Descripcion@Precio
8.5. DESCRIPCIÓN DE J-CHEF
8.5
259
Descripción de J-Chef
J-Chef se desarrolló con el lenguaje de programación Java, utilizando las
tecnologías de Servlet y JSP.
La base de datos llamada CHEFDB es manejada por el motor DB2 UDB
8.1 de IBM.
En cuanto a su interfaz gráfica se ha buscado que la misma sea atractiva
pero lo suficientemente sencilla para facilitar la usabilidad del sistema. Es
decir, se ha optado por ejemplo el diseño de menús de navegación fijos y
no desplegables, ya que estos últimos son muy atractivos pero muchas veces
incómodos, y debido a que este será un sistema de uso muy frecuente por los
mismos usuarios, se ha optado por establecer menús fijos e intuitivos.
8.5.1
Estructura de J-Chef
Como se ha explicado anteriormente, J-Chef esta desarrollado para soportar
distintos perfiles de usuario, donde cada perfil tendrá su propio panel del
sistema donde debe realizar su trabajo.
Los distintos tipos de usuarios que utilizarán J-Chef son:
— Adminitrador.
— Jefe de Cocina.
— Cajero.
Cuando un usuario se logea en J-Chef, este es dirigido al panel que le
corresponde de acuerdo a su cargo.
La figura 8.25 de la página 260 muestra la pantalla inicial de J-Chef.
Si se presiona entrar y alguno de los campos está vacion se verá un mensaje
de error como se ve en la figura 8.26 de la página 260.
Primeramente se explicará que ocurre cuando un nuevo usuario ingresa
por primera vez al sistema. Todos los tipos de usuarios deben ingresar por
primera vez a travéz de J-Chef, inclusive los mozos.
Los usuarios son dados de “Alta” por el Administrador, más adelante se
explicará en detalle el proceso.
260
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.25: Pantalla inicial de J-Chef.
Figura 8.26: No se han rellenado correctamente los campos necesarios para el
proceso de Login.
8.5. DESCRIPCIÓN DE J-CHEF
261
Figura 8.27:
La primera vez que un usuario ingresa a J-Chef, lo debe realizar con los
siguientes datos:
— Usuario: Debe ingresar su nombre.
— Contraseña: Debe ingresar su Documento Nacional de Identidad.
Cuando el nuevo usuario se logea con estos datos podrá ver la pantalla que
se observa en la figura de la página, donde deberá seleccionar su Usuario y
Contraseña que desea utilizar para los posteriores ingresos al sistema.
Si los datos que ha seleccionado el nuevo usuarios son válidos, recibe un
mensaje comunicando que ha seleccionado correctamente sus datos de Usuario
y Contraseña, si se produce algún tipo de error, es decir, si ya existe ese usuario
o esa contraseña, el sistema lo comunica al usuario que está intentando logearse
por primera vez.
Luego de que un mozo ha seleccionado correctamente sus datos para el
login, solo podrá logearse desde un PDA.
Ahora veremos en detalle los distintos paneles de acuerdo a los perfiles de
usuario.
262
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.28: Inicio del Panel de Administrador.
Administrador
Cuando un Administrador se logea a J-Chef, si los datos que ingresó no son
correctos el sistema responde con un mensaje de error, pero si los datos coinciden con los registrados en la base de datos para el Administrador este será
dirigido a la pantalla inicial del panel de Administrador, la cual se puede ver
en la figura 8.28 de la página 262.
En la pantalla inicial del panel de Administrador se puede observar que
tiene un menú principal el cual está ubicado arriba de la pantalla, el cual está
compuesto por tres links: usuarios, menú y estadísticas.
A continuación se explicará cada uno.
Administrador −→ usuarios :
Al presionar el link usuarios se podrá ver la pantalla que se muestra en
la figura 8.29 de la pantalla 263. En esta pantalla se puede observar que ha
aparecido un submenú Administrador a la izquierda, este está compuesto por
tres links: los cuales son: Nuevo Usuario, Editar Usuario y Borrar Usuario.
Si se presiona Nuevo Usuario el administrador podrá dar de alta a un nuevo
usuario como se puede ver en la figura 8.30 de la página 264, al presionar el
botón “cargar”, el usuario se almacena en la base de datos, en sus campos
8.5. DESCRIPCIÓN DE J-CHEF
263
Figura 8.29: Usuarios.
Usario y Contraseña se grabarán su Nombre y DNI respectivamente.
Si se presiona Editar Usuario se podrá ver una pantalla como la que se
describe en la figura 8.31 de la página 264.
Si se presiona el botón modificar sin haber seleccionado un usuario, el
sistema muestra una alerta informando que debe seleccionar uno. Ahora si se
ha seleccionado el usuario a editar, se habilita una pantalla donde se permite al
administrador realizar las actualizaciones necesarias sobre los datos del usuario
seleccionado.
Si se presiona el link Borrar Usuario, se realiza un proceso similar a la
edición.
Administrador −→ menú :
Aquí aparecerá el submenú compuesto por: Nuevo Item de Menú, Editar
Item de Menú y Borrar Item de Menú, como se puede observar en la figura
8.32 de la página 265.
En esta sección cualquier acción que lleve a cabo el administrador es decir,
Alta, Baja o Modificación de algún ítem, produce la actualización inmediata
de la Fecha de última modificación del menú.
264
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.30: Nuevo Usuario
Figura 8.31: Se debe seleccionar el usuario a editar.
8.5. DESCRIPCIÓN DE J-CHEF
265
Figura 8.32: Gestión del Menú.
Este valor de configuración es muy importante para el sistema ya es el que
determina cuando MobileChef debe actualizar sus bases de datos internas.
Al presionar Nuevo Item de Menú se podrá observar una pantalla como la
que se muestra en la figura 8.33 de la página 266.
En esta pantalla se ha configurado mediante javascript una serie de cajas
de selección enlazadas para seleccionar el tipo, categoría y eventualmente sub
categoría si corresponde, de ítem de menú que se desea ingresar, luego de
realizar las selecciones correspondientes se habilitarán los campos donde se
introducirán los datos del nuevo ítem, esto se ve en la figura 8.34 de la página
266.
Luego de cargar el nuevo ítem de menú se mostrará una pantalla con los
datos del mismo.
Editar Item de Menú y Borrar Item de Menú son muy similares, se mostrarán las pantallas de la edición.
Al presionar Editar Item de Menú se podrá observar una pantalla como la
que muestra la figura 8.35 de la página 267.
En esta sección se ha implementado una llamada asíncrona AJAX.
266
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.33: Nuevo Item de Menú.
Figura 8.34: Luego de seleccionar Tipo, Categoría y Sub Categoría se habilitan
los campos a rellenar para el nuevo ítem de menú.
8.5. DESCRIPCIÓN DE J-CHEF
Figura 8.35: Editar Item de Menú.
267
268
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Cuando el administrador selecciona una categoría o una sub categoría dependiendo de que la categoría tenga o no sub categorías, en ese momento
cuando la caja de selección detecta un cambio lanza la ejecución de una función javascript para realizar el procedimiento AJAX, y así recuperar los ítems
de menú correspondientes.
Para esta llamada se ha utilizado la librería javascript jQuery, la cual
cuenta con la función $.getJSON(), con esta función se realiza la llamada
asíncrona.
Esta llamada difiere de lo que sería un AJAX “tradicional”, es decir aquella
que obtiene como respuesta una porción de código HTML, que eventualmente
puede ser el resultado del proceso de un script en lenguaje servidor o bien
puede ser un HTML el cual no requiere de proceso previo para obtenerlo.
En este caso de AJAX “tradicional”, la llamada asíncrona obtiene una
porción de código HTML y la inserta en un contenedor dentro de la página
desde la cual se ha iniciado dicha llamada. Esto tiene como beneficio que no
se debe recargar toda una página sino que se carga solo una porción de la
misma, mejorando así la performance de un sitio web ya que reduce el proceso
del servidor.
En el caso de la función $.getJSON() de jQuery, lo que obtiene como
resultado es un String con una estructura determinada, y no una porción de
código HTML.
Al recibir el String respuesta, esta función, la cual se encuentra en la
página web que el administrador está viendo en el browser de una máquina
cliente, parsea dicho String y con código javascript se elabora el formulario
que mostrará y enviará los datos del ítem a editar, y cuando ha terminado de
generar el formulario lo inserta en un contenedor (<div></div>) dentro de
esta página donde se incio la llamada.
Este método resulta aún más efectivo que el método “tradicional” debido
a que el proceso del armado del código HTML es realizado en la máquina
cliente, es decir, si libera aún mas al servidor.
El String respuesta recibido tiene una estructura similar a la siguiente:
({ items:
[
8.5. DESCRIPCIÓN DE J-CHEF
269
{ idItem: “6”, categ: “Plato Principal”, subcateg: “Carnes”, nombreItem: “Costillitas de cerdo con puré de habas”, descipcionItem:
“Costillas de cordero, habas, romero, aceite de oliva”, precioItem:
“63.38”},
{ idItem: “7”, categ: “Plato Principal”, subcateg: “Carnes”, nombreItem: “Bondiola con repollo”, descipcionItem: “Repollo, Bondiola
grande, cebollas”, precioItem: “42.59”},
{ idItem: “8”, categ: “Plato Principal”, subcateg: “Carnes”, nombreItem: “Ojo de Bife a la pimienta”, descipcionItem: “Ojo de bife,
pimienta, cebolla de verdeo, morrón picado, tomate, perejil picado”,
precioItem: “52.87”},
{ idItem: “9”, categ: “Plato Principal”, subcateg: “Carnes”, nombreItem: “Solomillos de cerdo”, descipcionItem: “Solomillos de cerdo con
quínoa estilo risotto y láminas de gruyere”, precioItem: “49.62”},
{ idItem: “10”, categ: “Plato Principal”, subcateg: “Carnes”, nombreItem: “Colita de cuadril rellena”, descipcionItem: “Colita de cuadril,
queso crema, jamón cocido, tomate, papines, batata, portobelos y
rúcula”, precioItem: “48.26”}
]
})
Luego de seleccionar el ítem que se desea editar se muestran los datos del
ítem para que el administrador pueda editarlos.
En el caso del borrado de ítems, cuando el administrador selecciona el ítem
a eliminar, se le presenta una alerta con la que se consulta si está seguro de
borrar dicho ítem, al responder que si, ese ítem es eliminado de la base de
datos.
Administrador −→ estadı́sticas :
Al clickear sobre estadísticas aparecerá un submenú compuesto por los
siguientes links: Ver Usuarios, Ver Menú y Ver Facturación como se ve en la
figura 8.36 de la página 270.
Cada uno de estos links a su vez tendrá subsubmenús, en la figura 8.37 de
la página 270 se ve la pantalla que se obtendría al presionar la siguiente ruta,
estadísticas - Ver Usuarios - Ver Todos.
270
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.36: Gestión de Estadísticas.
Figura 8.37: Todos los Usuarios.
8.5. DESCRIPCIÓN DE J-CHEF
271
Ahora se explicarán las posibilidades de extracción de estadísticas disponibles en J-Chef.
• Ver Usuarios.
Esta opción está compuesta por otros links: Ver Todos, Ver Mozos, Ver
Cajeros y Ver Jefes de Cocina.
En Ver Todos y Ver Jefes de Cocina, se mostrará una lista con los usuarios,
donde en el extremo derecho de cada fila, se dispone de un link Ver, este
mostrará los datos completos del usuario respresentado por dicha fila.
Para los links Ver Mozos y Ver Cajeros se habilitan otras posibilidades ya
que se permite saber cual es el mozo con más pedidos levantados y cual es el
cajero con más pedidos facturados.
Al precionar en Ver Mozos, se verá la pantalla que se muestra en la figura
8.38 de la página 272.
A continuación se nombran las opciones de selección:
Ver todos los mozos.
Ver el mozo con más pedidos levantados.
Ver el mozo con menos pedidos levantados.
Ver los Mozos que tienen un número fijo de pedidos levantados.
Ver los Mozos que tienen más o inclusive un número fijo de pedidos
levantados.
Ver los Mozos que tienen menos o inclusive un número fijo de pedidos
levantados.
Donde las tres últimas opciones habilitan una caja de texto para ingresar
un parámetro comparativo para realizar la consulta SQL, como se ve en la
figura 8.39 de la página 273.
Las opciones en Ver Cajeros son muy similares a las de Ver Mozos.
• Ver Menú.
272
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.38: Escoger opciones de selección en Estadísticas de Mozos.
8.5. DESCRIPCIÓN DE J-CHEF
Figura 8.39: Opción que requiere de una parámetro de comparación.
273
274
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.40: Ver Comidas.
Aquí se podrán ver las opciones Ver Todo, Ver Comidas y Ver Bebidas.
Ver Comidas puede observarse en la figura 8.40 de la página 274. Comos
se puede ver, las opciones de selección son:
Ver la Comida más pedida.
Ver la Comida menos pedida.
Seleccionar Categoría o Sub Categoría.
Considerar Fecha.
Considerar Hora.
El formato de selección podría ser algo así:
Ver la comida más pedida de la Sub Categoría Carnes, entre las fechas
10/11/09 y 15/11/09, entre las horas 12:00:00 y 23:00:00.
Luego se obtendrá un listado como muestra la figura 8.41 de la página 275.
El funcionamiento de las otras opciones es muy similar.
8.5. DESCRIPCIÓN DE J-CHEF
Figura 8.41: Listado de Items resultado de una consulta estadística.
275
276
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.42: Buscar facturas por monto.
• Ver Facturación.
Al presionar este link se obtendrán las opciones Buscar por Número y
Buscar por monto.
Al buscar por número se ingresa el número de factura que se desea buscar
y J-Chef responderá con una pantalla comunicando el resultado, si no existe
muestra una pantalla de error, y si existe muestra los datos de la factura.
Al buscar por monto, se habilitan distintas opciones las cuales se puede
apreciar en la figura 8.42 de la página 276.
Luego de seleccionar las opciones se muestra un listado de las facturas que
coinciden con los parámetros de búsqueda como se ve en la figura 8.43 de la
277 página. Si no existen facturas que coincidan se mostrará una pantalla que
informe al administrador de tal situación.
Administrador −→ Configuraciones :
8.5. DESCRIPCIÓN DE J-CHEF
277
Figura 8.43: Facturas que coinciden con los parámetros de búsqueda ingresados.
278
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.44: Cantidad de Mesas con las que va a trabajar el Restaurant.
Cantidad de Mesas
Al presionar este link se verá la pantalla que se muestra en la figura 8.44
de la página 278.
Aquí se debe establecer el número de mesas con el trabajará el restaurant.
La modificación de este valor de configuración también modifica la Fecha
de última modificación del menú.
El administrador debe escribir el número de mesas correspondientes y luego
presionar el botón cargar, y J-Chef responderá con un mensaje informando si
la transacción se realizó con exito o no.
Solo responderá que fue exitosa si también se ha modificado la Fecha de
última modificación del menú.
Modificar Perfil
En esta sección el administrador podrá cambiar sus datos, como también
su Usuario y Contraseña.
Verá una pantalla como la de la figura 8.45 de la página 279.
Logout
8.5. DESCRIPCIÓN DE J-CHEF
Figura 8.45: Modificar Perfil del Administrador.
279
280
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.46: Logout.
Todo usuario de J-Chef al realizar el logout verá una pantalla como la de
la figura 8.46 de la página 280.
Aquí se destruye la sesión del usuario.
Jefe de Cocina
Una vez que el usuario “Jefe de Cocina” se logea correctamente verá una
pantalla como la que se observa en la figura 8.47 de la página 281.
El tipo de usuario “Jefe de Cocina” es aquel que se encuentra en la cocina
y maneja el orden y los tiempos de atención de los pedidos.
Este usuario ordenará, a los cocineros, elaborar los distintos platos que se
van solicitando determinando cuando y como atenderá cada uno, con el fin de
que los platos de una misma mesa puedan estar listos para servir todos a la
vez.
Pero esto es algo que lo debe manejar el Jefe de Cocina de manera personal,
8.5. DESCRIPCIÓN DE J-CHEF
281
Figura 8.47: Inicio del panel de Jefe de Cocina.
el sistema J-Chef no se encargará de este tipo de cuestiones.
Si se presta atención a la pantalla inicial de este panel podrá observarse que
posee un menú de acciones acotado, se explicará a continuación como funciona
este panel.
El link más importante de este panel es sin dudas “Ver Pedidos”, este
link se verá repetido en distintas posiciones dentro de la misma página para
facilitar tener acceso a él.
Ver Pedidos
Cuando el Jefe de Cocina presione este link podrá observar una pantalla
como la que se muestra en la figura 8.48 de la página 282. Como se ve, en
ella aparecerá una lista con los distintos pedidos que los mozos han levantado
utilizando el aplicativo MobileChef.
Esta lista muestra por cada pedido, las ordenes que lo componen, pudiendo
Atender aquellos ítems que sean del tipo Comidas, cuando estos estén listos,
los podrá Entregar. Estas acciones cambian el estado de cada orden.
Las bebidas solo pueden ser entregadas como ya se ha explicado en la
descripción de MobileChef.
282
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.48: Ver Pedidos.
Puede observarse también un pedido sin ordenes con la leyenda “Al momento, no hay ordenes para este pedido. Proviene de una Reserva”. Esto
indica que el administrador de Miarritze ha Atendido una Reserva sin pedidos
y la insertó a J-Chef como un pedido.
Como se ha explicado en el funcionamiento de MobileChef, los pedidos que
posean todas sus ordenes Entregadas, estarán listos para ser Cerrados por el
mozo.
Aquellos pedidos cerrados ya no aparecerán en la lista de pedidos del Jefe
de Cocina.
Modificar Perfil
Cuando se presione este link se verá una pantalla similar a la de la figura
8.49 de la página 283. Donde el “Jefe de Cocina” puede modificar su Usuario
y Contraseña.
8.5. DESCRIPCIÓN DE J-CHEF
Figura 8.49: Modifcar Perfil del Jefe de Cocina.
283
284
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.50: Inicio del Panel de Cajero.
Cajero
Una vez que el usuario “Cajero” se logeado correctamente al sistema podrá
observar una pantalla como la que se observa en la figuar 8.50 de la página
284. Se puede ver que esta pantalla es muy similar a la del Jefe de Cocina,
posee cuatro links, los cuales son Ver Pedidos, Ver Facturas, Modificar Perfil
y Logout.
Cajero −→ V erP edidos :
Este link ofrecerá al cajero una lista de los pedidos cerrados a los cuales
el mozo, con el aplicativo MobileChef, ya ha cargado los datos necesarios para
llevar a cabo la facturación del mismo. Esto se puede ver en la figura 8.51 de
la página 285.
Luego el cajero debe presionar el link “Facturar” del pedido que desea
registrar, si el cliente eligió pagar con efectivo se habilita una caja de texto
donde el cajero debe ingresar el monto recibido por el cliente y el sistema le
responderá con el pedido factura y el vuelto que debe otorgarle al cliente.
Si la factura se va a pagar con tarjeta de crédito solo se registra el pedido.
Cajero −→ V er F acturas :
Al presionar este link podrá ver las facturas que ha registrado. Como se
8.5. DESCRIPCIÓN DE J-CHEF
Figura 8.51: Lista de Pedidos listos para Facturar.
285
286
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.52: Facturas.
ve en la figura 8.52 de la página 286.
Luego de seleccionar una factura y presionar el botón “Ver” podrá ver los
datos de la factura seleccionada.
Modificar Perfil
Aquí el Cajero podrá modificar su Usuario y Contraseña como se ve en la
figura 8.53 de la página 287.
8.6
Descripción de Miarritze
Miarritze al igual que J-Chef se desarrolló con el lenguaje de programación
Java, utilizando las tecnologías de Servlet y JSP.
La base de datos llamada WEBCHEF es manejada por el motor DB2 UDB
8.6. DESCRIPCIÓN DE MIARRITZE
Figura 8.53: Modificar Perfil del Cajero.
287
288
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.54: Pantalla Inicial de Miarritze.
8.1 de IBM.
Este módulo como se ha explicado anteriormente simula ser el sitio web de
un restaurant, por lo tanto este corre en Internet, y cualquier persona puede
registrarse en el mismo como “Cliente” y así solicitar reservas on-line.
La pantalla principal de Miarritze puede verse en la figura 8.54 de la página
288.
8.6.1
Estructuración de Miarritze
Miarritze acepta tres tipos de usuarios, los cuales se describen a continuación:
Internauta.
Cliente.
Administrador.
8.6. DESCRIPCIÓN DE MIARRITZE
289
Figura 8.55: Miarritze - Quienes Somos?.
Internauta
Este tipo de usuario solo puede navegar por el sitio pero no puede realizar
reservas.
Los links que tendrá habilitados un usuario de este tipo serán: Inicio,
Quienes Somos?, Servicios y Contacto.
En la figura 8.55 de la página 289 se puede ver la pantalla Quienes Somos?.
El link Servicios mostrará la pantalla que se ve en la figura 8.56 de la
página 290.
El link Contacto habilita una pantalla donde cualquier usuario podrá enviar mensajes vía email al administrador de Miarritze, esta pantalla se ve en
la figura 8.57 de la página 290.
Cliente
Cualquier persona que desee ser un Cliente de Miarritze y aprovechar los
beneficios de solicitar sus reservas y pedidos on-line, primero debe registrarse
como cliente.
En el cuadro Login, se encuentra el link Registrate!, el cual muestra una
pantalla como la de la figura 8.58 de la página 291, donde la persona debe
rellenar el formulario con los datos que en el se solicitan.
290
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.56: Miarritze - Servicios.
Figura 8.57: Miarritze - Contacto.
8.6. DESCRIPCIÓN DE MIARRITZE
291
Figura 8.58: Registro de Clientes de Miarritze
Una vez que la persona se ha registrado correctamente, se debe logear al
sistema, cuando realice esta acción verá una pantalla como la figura 8.59 de
la página 292.
Cuando un Cliente se logea correctamente se habilita el link Reservas y
este puede solicitar una. Esto se ve en la figura 8.60 de la página 292.
Aquí el Cliente puede seleccionar la Fecha, Hora y Cantidad de Personas.
También puede tildar la opción de Seleccionar Pedidos.
Un Cliente puede realizar dos tipos de reservas: Reservas o Reservas con
Pedidos.
En una Reserva, el Cliente solo solicita la reserva de una mesa para la
fecha, hora y cantidad de personas que ha seleccionado.
Ahora, en una Reserva con Pedidos el Cliente también realiza el pedido
de los platos que desea. Esta opción puede verse en la figura 8.61 de la página
293.
Luego el Cliente podrá introducir comentarios a su reserva, y registrarla.
Al registrar, es decir que la solicitud de la reserva se grabado en WEBCHEF, al Cliente se le mostrará una pantalla como la que se ve en la figura
292
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.59: Cliente Logeado.
Figura 8.60: Miarritze - Reservas y Pedidos.
8.6. DESCRIPCIÓN DE MIARRITZE
293
Figura 8.61: Solicitud de Reserva con Pedidos.
8.62 de la página 294, la cual describe un Reserva.
Al hacer clic sobre el link Logout se destruye la sesión y se mostrará la
pantalla inicial de Miarritze.
Administrador
El usuario Administrador debe logearse al sistema para realizar su trabajo,
cuando este se logea recibe una pantalla de bienvenida y se habilitan links para
ver las reservas y también se habilita un link Configuración.
Durante la explicación del sistema principal (J-Chef y MobileChef ) en
varias oportunidades se ha explicado que un administrador de Miarritze puede
Atender reservas convirtiendo las mismas en Pedidos activos en J-Chef. Para
esto es necesario que el sitio web que corre en Internet se conecte al servidor
donde corre J-Chef el cual se encuentra en la Intranet del restaurant.
Esta conexión se podrá realizar estableciendo correctamente la dirección
IP donde este servidor sea alcanzable por el sitio web, y también se deberá
configurar el puerto donde el servidor atenderá las solicitudes provenientes
desde Miarritze.
294
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.62: Reserva Registrada.
Cómo configurar esta conexión se puede ver en la pantalla que se muestra
en la figura 8.63 de la página 295.
Ver Reservas
Cuando un administrador se logea en Miarritze puede verse en la imágenes
que el menú del sitio cambia, y en este aparecen distintos links para ver las
reservas.
Se muestra un link por cada tipo de estado que puede asumir una reserva,
estos son:
Reservas Solicitadas.
Reservas Del Día.
Reservas Confirmadas.
Reservas Rechazadas.
Reservas Atendidas.
Todas las vistas de las distintas pantallas de las reservas son similares, lo
que cambia es el contenido de cada pantalla, ya que se cargan las reservas
correspondientes al link que se ha clickeado, es decir, solo aquellas que tengan
dicho estado.
8.6. DESCRIPCIÓN DE MIARRITZE
295
Figura 8.63: Miarritze - Configuración.
En la figura 8.64 de la página 296 se pueden ver las reservas solicitadas.
Al presionar en “Ver” en la lista, se pueden ver los datos de la reserva.
Si es una reserva Solicitada, el administrador puede Confirmar o Recharzar
dicha reserva como se ve en la figura 8.65 de la página 296.
Las Reservas Del Día son aquellas que fueron Confirmadas pero su consulta se realiza el mismo día para la cual fue solicitada. De este modo el
administrador podrá Atenderla.
Cuando se clickea el link Ver Res.Del Día se mostrará un listado de las
mismas. Las cuales serán verificadas por el administrador.
Al clickear sobre el link Ver de alguna de estas reservas del día presentes
en la lista, se verán sus datos y ademas se verá un botón Atender.
Al presionar este botón Atender, Miarritze se comunica con J-Chef, y
obtiene la lista de mozos y el número de mesas. Esto se puede ver en la figura
8.66 de la página 297.
Luego el administrador recibirá una pantalla de error si la transacción no
se concretó correctamente o si registro correctamente como un pedido recibira
como respuesta una pantalla como la que se muestra en la figura 8.67 de la
página 297.
296
CAPÍTULO 8. DESCRIPCIÓN DE LA APLICACIÓN
Figura 8.64: Miarritze - Listado de Reservas según su Estado.
Figura 8.65: Confirmar o Rechazar una Reserva
8.6. DESCRIPCIÓN DE MIARRITZE
297
Figura 8.66: Atender Reserva.
Figura 8.67: La Reserva se ha registrado como pedido activo correctamente.
Capítulo 9
Concluciones
9.1
Concluciones Generales.
Es una realidad que tecnologías como el Comercio Electrónico, Java, Aplicaciones Móviles y Dispositivos Móviles, han revolucionado la manera en que
los distintos negocios se deben llevar a cabo. Ya que todas estas tecnologías
pueden aportar enormes ventajas competitivas en distintos rubros.
Estas distintas tecnologías aportan un marco muy completo para el desarrollo de aplicaciones que se adapten a las particularidades de cada negocio
debido a que ya no es necesario estar en un lugar físico para llevarlo a cabo.
En este trabajo se ha cumplido con el objetivo propuesto de desarrollar
una aplicación móvil que acceda a bases de datos multiplataforma, adicionalmente se desarrollaron también las aplicaciones web a fin de tener un sistema
completo desarrollado.
Se ha optado por desarrollar la aplicación móvil sin utilizar ninguna característica propia de ninguna marca del mercado (Palm, PoketPC ), por lo que
la aplicación debería funcionar en cualquier PDA que posea soporte para Java
y conectividad wi-fi.
La aplicación móvil se ha provado en:
• Emulador estándar de Websphere Application Device Developer.
• Simulador de Palm TX.
299
300
CAPÍTULO 9. CONCLUCIONES
También se ha probado en una Palm TX real con SO Garnet 5.4.9.
El resultado en las pruebas realizadas tanto en emuladores como en el
dispositivo real fue exitoso.
9.2
Conclusiones Acerca de las Tecnologías y Software Utilizados
Se ha podido comprobar las grandes ventajas de la utilización de tecnologías
y software, tanto de base de datos como de desarrollo de aplicaciones.
Los productos de WebSphere han demostrado ser herramientas muy potentes al momento de desarrollar tanto aplicaciones móviles como web, contando
con asistentes, corrección de errores y otras facilidades que hacen más rápido
y eficiente el trabajo.
Cabe destacar la gran utilidad del debugger de las herramientas WebSphere, ya que facilitan la detección y corrección de errores que no son detectados
en la compilación.
Con respecto al motor de bases de datos DB2, se debe destacar la escalabilidad, integridad y seguridad; interfaces sencillas y entendibles, completas,
intuitivas y con diversos asistentes, permitiendo de esa manera una mejor
comprensión en la utilización de la herramienta.
Resaltar también la gran utilidad del SQL Assist que brinda un apoyo
para realizar todo tipo de consultas SQL hacia las tablas.
Asimismo se pudo apreciar las facilidades del Scientific WorkPlace para
escribir libros, por la calidad del producto obtenido, la automatización en el
manejo de índices, la gestión dinámica de espacios, listas de figuras, de tablas,
referencias dinámicas a objetos, bibliografía, etc.
Se destaca la gran potencialidad de este conjunto de herramientas para el
desarrollo de aplicaciones de gran porte y alta complejidad, utilizables en una
amplia gama de sistemas operativos y con diversos motores de bases de datos.
9.3. LÍNEAS FUTURAS DE ACCIÓN
9.3
301
Líneas Futuras de Acción
A continuación se detallan las principales líneas futuras de acción del presente
trabajo:
• Dotar al módulo J-Chef de toda la salida impresa en facturación, cocina,
estadísticas, etc.
• Proveer la posibilidad de exportar los datos a planillas Excel ya que éstas
pueden ser de gran utilidad para la contaduría.
• Aumentar las opciones de extracción de estadísticas.
• Rediseñar el módulo Miarritze para que este pueda incluirse en sitios web
existentes de distintos restaurantes. Conciderando el desarrollo del mismo módulo en distintas versiones de acuerdo al lenguaje de programación
y motor de base de datos utilizados por los sitios de los restaurantes que
pretendan obtener este servicio.
• Proveer una conectividad total entre J-Chef y el módulo Miarritze, ya
que al momento la carga de los ítems se realizó de manera manual sobre
la base de datos y la edición o borrado de los ítems en J-Chef no se
reflejan en Miarritze.
Bibliografía
[1] Geraldo Gariboldi. Comercio Electrónico: Conceptos y reflexiones básicas. Banco Interamericano de Desarrollo. BID - INTAL. Documento de
Divulgación 4., 1999.
[2] Michael J. Cunningham. Como Desarrollar una Estrategia de Comercio
Electrónico. Pearson Educación, México, 2001.
[3] Isabel Gallego Fernández. Tesis doctoral: Modelo para comercio electrónico basados en sistemas intermediarios. Universidad Politécnica de
Catalunya, 2001.
[4] Friedemann Mattern. Revista de la ATI (Asociación de Técnicos de Informática) “Novática”, Octubre 2001.
[5] Alberto Los Santos Aransay. Computación Ubicua: Trabajo Individual.
Diseño de interacción centrada en el usuario. Universidad de Vigo, 2009.
[6] Gutiérrez Fernando Islas Octavio. La Sociedad de la Información £Utopía
o Panóptico? Revista Electrónica “Razón y Palabra”, Mayo 2004.
[7] Esteinou Javier. Hacia una Nueva Sociedad de la Comunicación y de la
Información. Revista Electrónica “Razón y Palabra”, Marzo 2003.
[8] Jorge Blanco López. TELEFONÍA MÓVIL: LAS PALABRAS EN EL
AIRE. Observatorio Tecnológico. Ministerio de Educación, Política Social
y Deportes. Gobierno de España., Junio 2006.
[9] Historia del teléfono móvil. Junio 2006.
[10] Martin Cooper - History of Cell Phone.
[11] Museum of Mobility History MuMoH. Apple Newton. Mayo 2008.
[12] Museum of Mobility History MuMoH. Pilot 5000. Mayo 2008.
303
304
BIBLIOGRAFÍA
[13] Ramón Ruiz Benito Raul Alvarez Barrio Antonio Sánchez Dotor, Isidro
Arroyo Garcia de Mateos. EL BLUETOOTH.
[14] Ing. Dario Yorio. Tesis de Magistratura:Identificación y clasificación de
patrones en el diseño de aplicaciones móviles. Universidad Nacional de
la Plata.
[15] E. Castillo; A. Cobo; P. Gómez; C. Solares. JAVA - Un Lenguaje de
Programación Multiplataforma para Internet. Paraninfo, España, 1997.
[16] L. Joyanes Aguilar; I. Zahonero Martínez. Estructura de Datos - Algoritmos, Abstracción y Objetos. Mc Graw Hill/Interamericana de España,
S.A.U., España, 1998.
[17] L. Joyanes Aguilar. Programación Orientada a Objetos - Segunda Edición. Mc Graw Hill/Interamericana de España, S.A.U., España, 1998.
[18] IBM. WebSphere Comerse V5.5 Architecture. IBM Press, USA, 2003.
[19] Lucas Ortega Díaz Sergio Gálvez Rojas. Java a Tope: J2ME. Universidad
de Málaga, Málaga, España, 2004.
[20] Jorge Cardenes Patricia Froufe Quintas Agustín. J2ME Java 2 Micro Edition Manual De Usuario y Tutorial. Alfaomega Grupo Editor Argentino
S.A., 2004.
[21] Korth Henry F. & Susarshan S. Silberschatz, Abraham. Aprenda Servlets
de Java como si estuviera en Segundo. Editorial McGraw-Hill, USA, 1993.
[22] VV.AA. Introducción a las Bases de Datos. THOMSON PARANINFO,
S.A., USA, 2005.
[23] Bart Jacob Carla Sadtler, John Ganci. WebSphere Product Family Overview and Architecture. IBM Press, USA, 2004.
[24] IBM Corp. IBM Workplace Client Technology Micro Edition Version
5.7.1. IBM, 2005.
[25] IBM Corp. WebSphere Studio Device Developer Product Documentation.
IBM, 2004.
Índice de Materias
AIV Extender, 184
AMS, 115, 116
aplicaciones móviles, 53—59, 62
AWT, 111
CLDC, 109
Conected Limited Device Configuration, 106
comentarios, 80
comercio electrónico, 1—7, 16, 21
computación pervasiva, 8, 16
computación ubicua, 8—11, 15, 16
computadora portátil, 32—34, 42, 43,
45, 48
comunicaciones en J2ME, 153
comunicaciones HTTP, 157
configuración, 106, 109
contenedor
cliente de aplicaciones de, 213
EJB de, 212
Web, 212
B2B, 196
B2C, 196
base de datos, 56, 57, 59, 61, 62
Bases de Datos
Introduccion, 175
Bases de Datos en Red
Modelo, 180
Bases de Datos Jerárquicas
Modelo, 179
Bases de Datos Relacional
Modelo, 180
bibliotecas de clases, 67
bifurcaciones, 81
if, 81
if else, 81
bloque try, catch, finally, 83
bluetooth, 42, 43, 49
bucles, 82
do while, 83
for, 82
while, 82
DB2
Introduccion, 175
db2 Data Links Manager, 186
DB2 UDB
Caracteristicas Generales, 183
Funciones Complementarias, 186
DB2 Warehouse Manager, 186
DBMS
Sistema de Administración de
Bases de Datos, 177
digitales
activos, 197
Dispositivos, 221
dispositivos móviles, 7, 53, 57
DNS, 214
C/C++, 80
CDC, 109
Conected Device Configuration,
106
Centro de Desarrollo, 186
305
306
doGet (), 87, 90
doPost (), 90
download, 197
e-commerce, 195
Eclipse, 218
Introduccíon y Conceptos, 198
ejemplo de
bifurcación if, 81
bifurcación if else, 81
bucle for, 82
bucle while, 82
comentario, 80
do while, 83
línea compuesta por tres sentencias, 79
ejemplo de clase, 72
enterprise beans, 212
estructuras de programación, 79
expresión, 79
GFC, 153, 155, 157
Generic Framework Conection,
153, 154
GPRS, 97
GUI, 213
herencia, 72
hosts virtuales, 213
HttpServletRequest, 87
HttpServletResponse, 87
instanciación e inicialización, 88
interfaz
Connection, 155
InputConnection, 156
OutputConnection, 156
StreamConnection, 157
irda, 43, 45
IT, 210
ÍNDICE DE MATERIAS
J2EE, 209
Java 2 Enterprise Edition, 98
J2ME, 97
Java 2 Micro Edition, 97, 98,
102
J2SE
Java 2 Standard Edition, 98
Java, 97
java, 57, 59, 63, 65, 67—69, 72—74,
76—80, 83, 84, 87, 90, 98
estructura general de un programa, 70
javax.servlet.HttpServlet, 87
JCA, 211
JDBC, 213
JDK, 80
JNDI, 213
JSP, 212
jsp, 58, 90, 91, 94
JVM, 97, 212
Java Virtual Machine, 98
ley de Moore, 9, 15
m-commerce, 6, 7
Mark Weiser, 8, 10, 15, 16
Martin Cooper, 26
memoria
administrador automático de la,
70
middleware, 209
MIDlet, 115, 118, 119, 139
MIDP, 110, 153
multi servidor, 210
multiplataforma, 55, 58, 62, 63, 68,
101, 183, 223
OOP, 70
operadores
aritméticos, 76
de asignación, 76
ÍNDICE DE MATERIAS
de concatenación de cadenas de
caracteres, 79
package, 73
packages, 71
Palm, 35, 39, 40
palm, 97
PDA, 214
pda, 34—37, 39, 41—43, 97, 223
perfil, 109
plataforma
de software, 194
plug-in, 211
Quick Installation, 211
rdbms, 61
record, 139
store, 139, 140
stores, 152
RMS, 137, 139, 141
sentencia, 79
Server
Application
Advanced Edition, 209
Enterprise Edition, 210
Standard Edition, 211
servidor
de aplicaciones, 212
HTTP, 211
servlets, 84, 85, 87, 90, 212
motor del, 88
sociedad de la información y el conocimiento, 17—20
Spatial Extender, 186
tecnologías de la información y la
comunicación, 19, 20
tecnologías de la información y la
comunicación, 19—22
307
teléfono móvil, 25—31, 36, 42, 45,
49, 50, 53, 54
teléfonos celulares, 103, 214
teléfono móvil, 97
telefonía celular, 26, 31
virtual
sistema principal, 213
wap, 49—51
WAS
WebSphere Application Server,
198, 207
WCTME
Workplace Client Technology Micro Edition, 214
Web Services, 210
WebSphere
Application Server, 207
Studio, 193
WebSphere Commerce, 195
WebSphere for Commerce
soluciones de portal, 196
soluciones digital media, 197
WebSphere for commerce
soluciones B2B, 195
soluciones B2C, 195
WebSphere Portal, 195
WebSphere Studio
Productos, 198
wi-fi, 36, 46—49
Workbench
banco de trabajo, 198
WSAD
Entorno de Desarrollo de WebSphere Studio, 198
WebSphere Studio Application
Developer, 198
WSADIE
308
WebSphere Studio Application
Developer Integration Edition, 198
WSED
WebSphere Studio Enterprise Developer, 198
WSSDA
WebSphere Studio Site Developer Advanced, 198
XML Extender, 184, 186
ÍNDICE DE MATERIAS