Universidad Nacional del Nordeste Facultad de Ciencias Exactas, Naturales y Agrimensura Trabajo Final de Aplicacin

Sistema Web con Acceso a Bases de Datos Multiplataforma a Travs de Dispositivos Mviles

Juan Felix Basterretche - L.U.: 34039 Profesores Orientadores: Mgter. David Luis la Red Martnez Lic. Valeria Emilce Uribe Licenciatura en Sistemas de Informacin Corrientes - Argentina 2009

A mi familia y amigos por su incansable apoyo

Prefacio
En los ltimos aos se han realizado grandes avances en tecnologas de comunicacin mvil, lo cual hace posible que hoy en da la sociedad tenga acceso a informacin til del contenido de las bases de datos, mediante dispositivos mviles. Es decir, hoy un usuario de un PDA, o bien un usuario de un telfono celular puede navegar por internet desde el mismo utilizando redes, en este caso inalmbricas. La aparicin de tecnologas como bluetooth y wi- han revolucionado la manera en que los usuarios desean conectarse, ya que ambas tecnologas presentan pocas dicultades para lograr la conexin entre distintos dispositivos debido a la estandarizacin de las mismas. Estas tecnologas se han desarrollado tanto hasta abarcar escenarios donde la utilizacin de dispositivos mviles presentan grandes ventajas y comodidades, ya que cada vez se ven ms servicios que antes solo podan ser utilizados a travs de computadoras personales conectadas a redes cableadas. Considerando esto, se ve la necesidad de estudiar detalladamente estas tecnologas para poder explotar las oportunidades que los servicios de Internet y los dispositivos mviles presentan a la sociedad, ya que, juegan un papel fundamental en todos los mbitos: Profesionales, culturales, educativos, comerciales y otros. Desde la aparicin de las computadoras stas han sido usadas en los sistemas de informacin de las empresas para facilitar el trabajo de control y gestin gracias a la capacidad de recopilar y procesar gran cantidad de datos. En entornos fuertemente competitivos las empresas han comprendido que las inversiones en tecnologas de la informacin pueden incrementar de forma signicativa la competitividad de la empresa. Aunque las necesidades tecnolgicas de los restaurantes parezcan inferiores en comparacin 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 ms obligados a realizar inversiones en este campo. Hoy en da parece impensable que un restaurant no tenga pgina web y en el caso ideal su sistema de informacin debera 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 aplicacin con software de computacin mvil multipla-

vi

taforma, que permita el acceso a informacin situada en bases de datos multiplataforma en un servidor Web, a travs de dispositivos mviles tales como PDAs. La aplicacin 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 signica disminuir los tiempos de atencin en cada mesa, ya que cada accin que realice el mozo sobre los datos, esto se reejar en las bases de datos del restaurant. A su vez se propuso el desarrollo de la plataforma Web de la aplicacin que sea accesible desde la Intranet, que contemple funciones adicionales como ser: registro de usuarios, registro de nuevos platos o bebidas que formarn parte del men, poder ver en cada momento los pedidos que van registrando los mozos, facturar los mismos, y adems obtener estadsticas. Se propuso tambin 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 atencin 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 aplicacin utilitaria empleando un software de computacin mvil multiplataforma para PDAs que permita acceder a informacin situada en una base de datos que se encuentra en un servidor Web, mediante una red wi-. Desarrollo de la plataforma web de la aplicacin con acceso a bases de datos, que sirva de apoyo a la aplicacin mvil. Desarrollo de la plataforma web que simula ser el sitio web de un restaurant que permita realizar reservas on-line.

vii

Clasicacin del Trabajo El trabajo se encuadra en la utilizacin de software de base que permite el desarrollo de aplicaciones que permitan el acceso a bases de datos multiplataformas desde dispositivos mviles tales como PDAs. Etapas de Desarrollo Se ha efectuado una amplia recopilacin bibliogrca especca a los temas pertinentes a la tarea planicada y a los productos de software que se emplearon para la concrecin del trabajo nal. 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 realizacin del presente Trabajo Final los productos de software como los siguientes: WebSphere Studio Application Developer versin 5.0 y 5.1.2. DB2 UDB WorkGroup Server Edition versin 8.1. WebSphere Studio Device Developer versin 5.7.1.

Se ha efectuado un estudio acerca de las arquitecturas de aplicaciones mviles. Se ha realizado el anlisis y diseo de la base de datos que utiliza la aplicacin. Se ha realizado el estudio del manejador de bases de datos DB2 UDB para Windows. Se ha realizado un detallado estudio del J2ME (versin de Java para mviles), para la herramienta de desarrollo WebSphere Studio Device Developer versin 5.7.1. Se ha realizado un detallado estudio del software para el desarrollo de las plataformas web de la aplicacin, WebSphere Studio Application Developer versin 5.1.2.

viii

Se ha desarrollado el aplicativo mvil con la utilizacin del lenguaje Java, versin J2ME. En el marco de la herramienta WebSphere Studio Application Developer se desarrollaron los mdulos web del aplicativo utilizadando pginas XHTMLs, JSPs y Servlets de Java. Una vez nalizada la etapa de desarrollo se realizaron las siguientes actividades: Empaquetado de la aplicacin mvil para su distribucin e instalacin en los PDAs. Instalacin del simulador de la Palm TX. Instalacin y prueba de la aplicacin tanto en los emuladores como as tambin en una Palm TX real. Testeo del sistema, simulando un escenario real realizando pruebas de conexin entre el sistema mvil y el servidor web a travs de wi- en una Intranet. Finalizada la aplicacin se realiz la grabacin en DVD de todo el material correspondiente al trabajo nal: una versin de la aplicacin, otra referente al libro en formato LaTex y el PDF generado. Tambin 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. Organizacin del Informe Final El trabajo nal de aplicacin comprende un informe nal impreso y un DVD adems de un resmen y de un resmen extendido. El informe nal est organizado en captulos los que se indican a continuacin: Introduccin: Se presenta una vision global acerca de las nuevas tecnologas de informacin y comunicaciones, como as tambin las principales caracteristicas del comercio electronico mvil, computacin ubicua y de la sociedad de la informacin y el conocimiento.

ix

Tecnologa mvil: Se indican los principales dispositivos mviles y su evolucin, y se explican las diferentes tecnologas de conexin inalmbricas de estos. Aplicaciones mviles: Se explican los requerimientos necesarios para una aplicacin mvil. Java: Se presentan los principales aspectos y caractersticas referidas al lenguaje. Java 2 Micro Edition: Se detallan las conceptos y caractersticas del lenguaje Java para dispositivos electrnicos con menos recursos. Introduccin al DB2: Se detallan las ms relevantes caractersticas de esta familia de productos de gestin de bases de datos. WebSphere Studio: Presenta los principales aspectos de este entorno de aplicaciones complejas. Descripcin de la aplicacin: Se describen todos los aspectos de la aplicacin desarrollada utilizando las herramientas antes mencionadas. Conclusiones: Se presentan las conclusiones a las que se ha llegado al nalizar el presente trabajo y las posibles lneas futuras de accin. El DVD adjunto al informe nal impreso, contiene lo siguiente: Instaladores del software utilizado. Resmenes del trabajo realizado. Informe nal en formato digital. Presentacin para la defensa nal. Aplicacin desarrollada. Juan Felix Basterretche Licenciatura en Sistemas de Informacin Universidad Nacional del Nordeste L.U.: 34039 Corrientes; 19 de Noviembre de 2009

ndice General
1 Introduccin 1.1 Comercio Electrnico . . . . . . . . . . . . . . . . . . . . . . . . 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 funcin tiempo . . . . . . . . . . . . . . 1.1.4 Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.5 Otras Concepciones del Comercio Electrnico . . . . . . 1.1.6 Esquema General . . . . . . . . . . . . . . . . . . . . . . 1.1.7 Modelos de Comercio Electrnico . . . . . . . . . . . . . 1.2 M-Commerce . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Computacin Ubicua . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Concepto . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.3 Diseo centrado en el usuario . . . . . . . . . . . . . . . 1.4 La Ley de Moore y la Visin de Weiser . . . . . . . . . . . . . . 1.5 SIC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.1 La Visin Sobre las Sociedades de la Informacin y de la Comunicacin . . . . . . . . . . . . . . . . . . . . . . 1.5.2 Principios Gua . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 Hacia las sociedades de informacin y comunicacin . . 1.6 TICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.6.1 Aspecto social de las TIC . . . . . . . . . . . . . . . . . 1.7 Tecnologa en el Restaurant . . . . . . . . . . . . . . . . . . . . 1.7.1 Benecios e inconvenientes del uso de las tecnologas de la informacin en el sector gastronmico. . . . . . . . . 1 1 1 2 3 3 4 4 5 7 8 8 8 11 15 17 17 18 18 19 20 20 21

2 Tecnologa Mvil 25 2.1 Telefona Mvil . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.1.1 Celulares: Concepto General . . . . . . . . . . . . . . . 25 xi

xii

NDICE GENERAL

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 Porttil . . . . . . . . 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 . . . . . . Estndares . . . . . . . . . . . . . . . . 2.6.1 Bluetooth . . . . . . . . . . . . . 2.6.2 IrDA - Infrared Data Association 2.6.3 IEEE 802.11 o Wi-Fi . . . . . . . Internet Mvil - WAP . . . . . . . . . . 2.7.1 Tecnologa - WAP . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26 28 32 34 35 36 37 39 40 42 42 43 46 49 50 53 53 54 56 59 62 63 65 65 67 68 69 70 71 71 72 72 73 73 75 75 76 76

3 Aplicaciones Mviles 3.1 Introduccin . . . . . . . . . . . . . . . 3.2 Requerimientos Para una Arquitectura 3.3 Arquitectura de Portal Mvil . . . . . 3.4 Arquitectura de Bases de Datos . . . . 3.5 Aplicaciones Multiplataforma . . . . . 3.5.1 Java y Multiplataforma . . . .

. . . . Mvil . . . . . . . . . . . . . . . .

4 Java 4.1 Introduccin al Lenguaje . . . . . . . . . . . . . . 4.1.1 Bibliotecas de Clases Estndares de Java 4.1.2 Java es Multiplataforma . . . . . . . . . . 4.1.3 Caractersticas del Lenguaje . . . . . . . . 4.2 Estructura de un Programa Java . . . . . . . . . 4.3 Conceptos Bsicos . . . . . . . . . . . . . . . . . 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 Aritmticos . . . . . . . . . .

NDICE GENERAL

xiii

4.6

4.7

4.5.2 Operadores de Asignacin . . 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 Concatenacin Estructuras de Programacin . . . . 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 Instanciacin e Inicializacin 4.7.3 Servicio de Demanda . . . . . 4.7.4 Terminacin . . . . . . . . . . 4.7.5 Java Server Faces . . . . . . . 4.7.6 Desarrollando Aplicaciones .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . de Caracteres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

5 Java 2 Micro Edition 5.1 Introduccin . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Comparacin de Versiones . . . . . . . . . . . . . 5.1.2 Algunas Consideraciones al Desarrollar en J2ME 5.2 Componentes de J2ME . . . . . . . . . . . . . . . . . . . 5.2.1 Mquinas Virtuales J2ME . . . . . . . . . . . . . 5.2.2 Conguraciones . . . . . . . . . . . . . . . . . . . 5.2.3 Perles . . . . . . . . . . . . . . . . . . . . . . . 5.3 Cmo Detectar una Aplicacin 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 Grcas de Usuario . . . . . . . . . . . . . . . 5.5.1 La Clase Display . . . . . . . . . . . . . . . . . . 5.5.2 La Clase Displayable . . . . . . . . . . . . . . . . 5.5.3 Las Clases Command y CommandListener . . . .

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 Creacin de un Record Store . . . . . . . . . . . . . . . 5.6.4 Manipulacin de Registros . . . . . . . . . . . . . . . . . 5.6.5 Operaciones con Record Stores . . . . . . . . . . . . . . 5.6.6 Bsqueda 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 Introduccin al DB2 175 6.1 Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 6.1.1 Objetivos de las Bases de Datos . . . . 6.1.2 Ventajas de las Bases de Datos . . . . . Sistema de Administracin de Bases de Datos Organizacin de Bases de Datos . . . . . . . . 6.3.1 Bases de Datos Jerrquicas . . . . . . . 6.3.2 Bases de Datos en Red . . . . . . . . . 6.3.3 6.4 6.5 Bases de Datos Relacional Introduccin a DB2 UDB . . . . . . . . . . . . 6.4.1 Caractersticas Generales del DB2 UDB DB2 UDB Versin 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 Depsito de Datos de DB2 . 6.5.5 Asistentes de DB2 . . . . . . . . . . . . 6.5.6 Centro de Mandatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 176 177 179 179 180 182 183 186 186 188 188 188 189 190 193 193 194 195 195 196 197 198

6.2 6.3

. . . . . . . . . . . . . . . . 180 . . . . . . . . . . . . . . . . .

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 . . . . . . . . . . . . . . . . .

NDICE GENERAL

xv

7.4

7.5

7.6

7.7

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 Introduccin . . . . . . . . . . . . . . . . . . . . . . . . 7.5.2 WebSphere Application Server Como Plataforma Para el Comercio Electrnico . . . . . . . . . . . . . . . . . . 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 Utilizacin del IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

8 Descripcin de la Aplicacin 8.1 Introduccin . . . . . . . . . . . . . . . 8.2 Estructuracin . . . . . . . . . . . . . 8.3 Modelo de datos . . . . . . . . . . . . 8.4 Descripcin de MobileChef . . . . . . . 8.4.1 Levantar Pedidos . . . . . . . . 8.4.2 Ver Pedidos . . . . . . . . . . . 8.4.3 Estructura de los Record Stores 8.5 Descripcin de J-Chef . . . . . . . . . 8.5.1 Estructura de J-Chef . . . . . .

xvi

NDICE GENERAL

8.6

Descripcin de Miarritze . . . . . . . . . . . . . . . . . . . . . . 286 8.6.1 Estructuracin de Miarritze . . . . . . . . . . . . . . . . 288

9 Concluciones 299 9.1 Concluciones Generales. . . . . . . . . . . . . . . . . . . . . . . 299 9.2 Conclusiones Acerca de las Tecnologas y Software Utilizados . 300 9.3 Lneas Futuras de Accin . . . . . . . . . . . . . . . . . . . . . 301

Bibliografa ndice de Materias

303 305

ndice de Figuras
1.1 1.2 1.3 1.4 1.5 1.6 2.1 2.2 2.3 2.4 Esquema General del Comercio Electrnico. . . . . . . . . . . . Ideal de Computacin Ubicua. . . . . . . . . . . . . . . . . . . Arquitectura Genrica de un Dispositivo de Computacin Ubicua Fases del Diseo Orientado al Usuario . . . . . . . . . . . . . . MarkWeiser (1952-1999), el Visionario de la Computacin Ubicua Benecios Obtenidos de la Introduccin de Tecnologa. . . . . . Handie Talkie12-16 . . . . . . . . . . . . . . . . . . . . . . . . . Martin Cooper mostrando el primer telfono celular. ArrayComm Publicidad del Motorola Handie Talkie H12-16 . . . . . . . . . La evolucin de los telfonos celulares fue ms all de las caractersticas tcnicas. Se puede apreciar cmo en tamao y peso la evolucin 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 tamaos entre la Palm Pilot 5000 y el Apple Newton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Bluetooth Apple Mighty Mouse . . . . . . . . . . . . . . . . . . Teclado Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . IrDA - Organizacin de sus capas. . . . . . . . . . . . . . . . . Tarjeta Wi-Fi para PalmOne . . . . . . . . . . . . . . . . . . . Tarjeta USB para Wi-Fi . . . . . . . . . . . . . . . . . . . . . . Arquitectura Portal Mvil . . . . . . . . . . . . . . . . . . . . . xvii 5 9 12 13 16 21 26 27 28

2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14 2.15 2.16 2.17 3.1

30 32 33 34 35 37 38 40 41 44 44 46 47 49 60

xviii

NDICE DE FIGURAS

4.1 4.2 4.3 4.4 4.5 4.6 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 6.1 6.2 6.3 6.4 6.5 6.6 6.7 6.8 6.9 6.10 7.1 7.2

Mecanismo de Mensajes . . . . . . . . . . . . . . . . . . . . . . Proceso Compilacin y Ejecucin . . . . . . . . . . . . . . . . . Jerarqua y Mtodos de las Principales Clases Para Crear Servlets. Ciclo de Vida de un Servlet. . . . . . . . . . . . . . . . . . . . . Requerimiento de un archivo JSP. . . . . . . . . . . . . . . . . Requerimiento de un Servlet . . . . . . . . . . . . . . . . . . . . Arquitectura de la Plataforma Java 2 de Sun. . . Ubicacin de las Tecnologas Java. . . . . . . . . Proceso de Vericacin. . . . . . . . . . . . . . . Entorno de Ejecucin de J2ME. . . . . . . . . . . Ciclo de Vida de un MIDlet. . . . . . . . . . . . . Estados de un MIDlet. . . . . . . . . . . . . . . . Jerarqua de Clases. . . . . . . . . . . . . . . . . Un MIDlet y el RMS. . . . . . . . . . . . . . . . Acceso a un RMS a Travs de un MIDlet Suite. . Esturctura de Un Record Store. . . . . . . . . . . Ejemplo RMS. . . . . . . . . . . . . . . . . . . . Jerarqua de Interfaces. . . . . . . . . . . . . . . Estados de una conexin HTTP. . . . . . . . . . Ejemplo de comunicacin HTTP de un MIDlet. . Solicitud de permiso para utilizar tiempo de aire. Iniciando el proceso de conexin. . . . . . . . . . Conectandose a la red wi-. . . . . . . . . . . . . Obteniendo direccin IP. . . . . . . . . . . . . . . Conectado a red wi-. . . . . . . . . . . . . . . . Estructura de Una Base de Datos . . . . . . . Sistema de Administracin de Bases de Datos Modelo de Bases de Datos Jerrquica. . . . . 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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67 69 86 89 95 95 100 101 105 110 117 118 124 139 140 141 151 154 158 168 169 170 171 172 173 178 178 180 181 182 185 185 187 190 191

La familia del WebSphere Studio. . . . . . . . . . . . . . . . . . 199 WebSphere Studio, entorno de desarrollo. . . . . . . . . . . . . 199

NDICE DE FIGURAS

xix

7.3 7.4 7.5 7.6 7.7 7.8 7.9 7.10 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 8.15 8.16 8.17 8.18 8.19 8.20 8.21 8.22 8.23 8.24 8.25

. . . . . . . . . . . . . . . . . . . . . . . Plataforma de Eclipse. . . . . . . . . . . Asistente de Proyecto Java. . . . . . . . Paquete Java. . . . . . . . . . . . . . . . Dilogo de Conguracin de Ejecucin. . WebSphere para e-bussines. . . . . . . . Barra de herramientas de WSDD. . . . . Mtodos de un Objeto. . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

200 201 206 207 208 209 219 221 225 226 227 231 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 260

Casos de uso del Sistema Principal. J-Chef y MobileChef. . . . Casos de Uso del mdulo 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 Conguracin 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 envo 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 Facturacin. . . . . . . . . . . . . . . . . . . . . . . . . . Se ha registrado correctamente el pedido para poder ser Facturado por el Cajero. . . . . . . . . . . . . . . . . . . . . . . . . . Pantalla inicial de J-Chef. . . . . . . . . . . . . . . . . . . . . .

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 Gestin del Men. . . . . . . . . . . . . . . . . . . . . . . . . . 8.33 Nuevo Item de Men. . . . . . . . . . . . . . . . . . . . . . . . 8.34 Luego de seleccionar Tipo, Categora y Sub Categora se habilitan los campos a rellenar para el nuevo tem de men. . . . . 8.35 Editar Item de Men. . . . . . . . . . . . . . . . . . . . . . . . 8.36 Gestin de Estadsticas. . . . . . . . . . . . . . . . . . . . . . . 8.37 Todos los Usuarios. . . . . . . . . . . . . . . . . . . . . . . . . . 8.38 Escoger opciones de seleccin en Estadsticas de Mozos. . . . . 8.39 Opcin que requiere de una parmetro de comparacin. . . . . 8.40 Ver Comidas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.41 Listado de Items resultado de una consulta estadstica. . . . . . 8.42 Buscar facturas por monto. . . . . . . . . . . . . . . . . . . . . 8.43 Facturas que coinciden con los parmetros de bsqueda ingresados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.44 Cantidad de Mesas con las que va a trabajar el Restaurant. . . 8.45 Modicar Perl del Administrador. . . . . . . . . . . . . . . . . 8.46 Logout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.47 Inicio del panel de Jefe de Cocina. . . . . . . . . . . . . . . . . 8.48 Ver Pedidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.49 Modifcar Perl del Jefe de Cocina. . . . . . . . . . . . . . . . . 8.50 Inicio del Panel de Cajero. . . . . . . . . . . . . . . . . . . . . . 8.51 Lista de Pedidos listos para Facturar. . . . . . . . . . . . . . . 8.52 Facturas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.53 Modicar Perl 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

xxi

8.62 8.63 8.64 8.65 8.66 8.67

Reserva Registrada. . . . . . . . . . . . . . . . . . . . . . . . . Miarritze - Conguracin. . . . . . . . . . . . . . . . . . . . . . Miarritze - Listado de Reservas segn su Estado. . . . . . . . . Conrmar o Rechazar una Reserva . . . . . . . . . . . . . . . . Atender Reserva. . . . . . . . . . . . . . . . . . . . . . . . . . . La Reserva se ha registrado como pedido activo correctamente.

294 295 296 296 297 297

Captulo 1

Introduccin
1.1 Comercio Electrnico

Antes de intentar una denicin de comercio electrnico, resulta apropiado analizar los distintos aspectos y caractersticas que hacen a la esencia misma de esta forma de comercio. Las particularidades del comercio electrnico estn dadas, tanto por la forma en que los actores interactan, como por la nueva dimensin que adquieren las funciones de tiempo y espacio. Aunque el comercio electrnico mantiene ciertas analogas 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 electrnico no existe contacto fsico directo entre los actores. Las operaciones se realizan a travs de medios electrnicos de comunicacin, 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 catlogos u otros medios grcos, o publicitada a travs de la radio o la televisin, sean nalizadas por medios de comunicacin como el telfono o el fax. En un sentido ms estricto, slo se consideran operaciones de comercio 1

CAPTULO 1. INTRODUCCIN

electrnico a aquellas realizadas enteramente a travs de medios digitales de comunicacin como Internet, Intranets, Extranets, o sistemas de Intercambio Electrnico de Datos (EDI: Electronic Data Interchange).

1.1.2

Espacio donde se realizan las operaciones

Si se llama mercado al lugar donde interactan compradores y vendedores se verica que desde la antigedad esta interaccin est asociada a un lugar fsico determinado. De una forma u otra esta tradicin an continua, y se pueden encontrar dos tipos de mercados fsicos:

Aquel en el cual comprador y vendedor se encuentran en persona a los nes de realizar la transaccin. Aquel que se reere especcamente al lugar donde la operacin es llevada a cabo, abarcando de este modo a las operaciones que se asocian a dicho lugar fsico. Como ejemplo pueden ser mencionados los mercados de valores o bolsas donde gente de un lugar u otro del planeta compra o vende ttulos comercializables pertenecientes a corporaciones localizadas en cualquier lugar del mundo.

Esta dualidad de mercado abrira 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 operacin y el lugar fsico-geogrco en el cual se realiza. Frente a esta realidad, el comercio electrnico ha abierto una tercera posibilidad: que las operaciones ocurran dentro de un espacio virtual, no especco. En este caso, la problemtica esta planteada por el hecho de que, legalmente, a los nes de otorgarle validez a la transaccin, los mismos marcos regulatorios del comercio requieren la presencia de un lugar fsico donde circunscribirla. Dadas las particularidades del comercio electrnico, surge la necesidad de establecer lineamientos normativos adecuados, a n de dar solucin al vaco legal existente.

1.1. COMERCIO ELECTRNICO

1.1.3

El comercio y la funcin tiempo

El comercio tradicional slo funciona durante ciertos periodos de tiempo, es decir durante determinados horarios o durante ciertas pocas del ao. En dicho comercio, las respuestas a los estmulos producidos por los actores pueden tomar das, 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 an ms tiempo para modicarlos en caso de ser necesario. El comercio electrnico no involucra horarios. Trabaja 24 horas al da, los 365 das del ao. Opera permanentemente un agente electrnico que es capaz de brindar los datos requeridos, tomar pedidos u ofrecer variedad de servicios. De igual modo interacta, obtiene informacin y la transforma en conocimiento en tiempo real, sin demoras y casi instantneamente.

1.1.4

Actores

Como se ha visto en el punto anterior. Los actores del comercio electrnico pueden no ser humanos. Los agentes electrnicos son capaces de realizar una gran cantidad de funciones. Si bien es cierto que an no estn muy desarrollados, empresas como Apple o instituciones educativas como el M.I.T. estn trabajando en el desarrollo de dichas tecnologas, as como otras compaas dedicadas a la produccin de software para Internet. Los robots o agentes electrnicos, una vez preestablecidos ciertos parmetros, poseern la capacidad de buscar, comparar, negociar y completar operaciones sin la necesidad de que intervenga un ser humano. En comparacin con las opciones ofrecidas en los distintos sitios de la red, an un agente electrnico poco sosticado puede, actualmente, encontrar el mejor valor tanto para un libro como para un CD o un pasaje areo. Luego de haber analizado los elementos que le otorgan al comercio electrnico sus propiedades distintivas, llegamos a denirlo como: Toda transaccin comercial (produccin, publicidad, distribucin y venta de bienes y servicios) realizada tanto por personas, empresas o agentes electrnicos a travs de medios digitales de comunicacin, en un mercado virtual

CAPTULO 1. INTRODUCCIN

que carece de lmites geogrcos y temporales.

1.1.5

Otras Concepciones del Comercio Electrnico

Transacciones de negocios efectuadas mediante redes pblicas o privadas, incluyendo transacciones pblicas y privadas que utilizan Internet como instrumento de entrega. Estas transacciones incluyen transferencias nancieras, intercambios en lnea, subasta, entrega de productos y servicios, actividades de la cadena de abastecimiento y redes de negocios integradas. [2] El Comercio Electrnico (e-Commerce) es la simple replicacin de un negocio en Internet u otro medio electrnico que permita recoger los pedidos u ofertar los productos y/o servicios desde o hacia clientes o proveedores. Por ejemplo vender zapatos en la pgina 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 duplicacin de tareas o tareas extras para asentar esas transacciones en los sistemas digitales centrales del negocio.

1.1.6

Esquema General

El comercio electrnico se puede denir como un intercambio electrnico 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 electrnico consiste bsicamente en un vendedor que oferta sus productos a travs de un catlogo (preferentemente actualizado) y unos compradores de dicho producto quienes consultan el catlogo 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 ELECTRNICO

La entidad compradora (demandante) realiza el pedido. La entidad vendedora (ofertante) acepta el pedido y lo conrma. Finalmente es necesario realizar la entrega del producto y el pago (ambos procesos se pueden realizar indistintamente de forma electrnica o no). Todos los intercambios entre compradores y vendedores en el escenario electrnico o virtual se realizan de forma no presencial mediante la utilizacin de redes de transmisin como el caso de la red Internet. Como se puede apreciar en la gura 1.1 de la pgina 5.

Figura 1.1: Esquema General del Comercio Electrnico.

1.1.7

Modelos de Comercio Electrnico

B2C (Bussines to Consumer) (Negocio a Cliente Final) Es el negocio orientado hacia el consumidor nal (internauta particular que navega por la red). Las empresas ofrecen sus productos a particulares a travs de su portal web. El nico requisito es conectarse a su web y hacer un pedido. Se considera el original comercio electrnico. Las estadsticas indican que cada vez se compra ms por Internet, pero la evolucin es lenta comparada con las expectativas que se haban creado. Tiene el riesgo de que los clientes puedan comparar precios fcilmente, con lo que el marketing y el posicionamiento de la marca son muy importantes. Gran parte de su xito depende de:

CAPTULO 1. INTRODUCCIN

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 tambin 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 jadas. Es el verdadero impulsor del comercio electrnico. El volumen de negocio entre empresas es muy superior al negocio dirigido al cliente nal. C2C (Consumer to Comsumer) (Consumidor a Consumidor) La negociacin se desarrolla entre personas con intereses similares indistintamente de la parte compradora y vendedora. La comunicacin se realiza de forma espontnea y los participantes pueden asumir roles de comprador, vendedor o ambos. Requiere sistema de intermediario para garantizar la conanza entre los participantes. Un ejemplo podra 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 podra resumir en dos negocios B2C paralelos. Otra categora de comercio electrnico que seguramente impactar en el futuro es Mobile-Commerce (M-Commerce) o comercio electrnico a travs de telfonos mviles. Se fundamenta en lo siguiente: La penetracin de la telefona mvil. El acceso gratuito/tarifa plana a Internet. La implantacin de la tarjeta inteligente. Los mviles inteligentes.

1.2. M-COMMERCE

Telefona inalmbrica digital. La convergencia: Telfono jo/mvil/Internet. El potencial de usuarios de telfonos mviles es superior al de los internautas. Los estudios de empresas consultoras de comercio electrnico apuestan por el comercio electrnico mvil , 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 benecios 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 jas. El M-COMMERCE consiste en el uso de terminales mviles (Telfonos celulares, Asistentes personales Digitales - PDAs, Palms, LapTops, etc.) y de redes mviles pblicas o privadas para accesar informacin y conducir transacciones que resultan en la transferencia de valor mediante el intercambio de informacin, bienes o servicios. El fuerte desarrollo de la norma GSM en Europa, el sistema de SMS, y especialmente el WAP, facilitaron el acceso mvil e interactivo a datos, abriendo nuevas posibilidades para el comercio. Pero esas oportunidades tienen algunas dicultades como el ancho de banda limitado que an complica las transmisiones, y la interfaz de usuario de los dispositivos mviles es limitada en tamao. Adems, los costos de acceso son altos, y el poder de cmputo de estos dispositivos es mucho ms pequeo que el de las PCs. El M-Commerce involucra tres aspectos bsicos: Oferta de los negocios y servicios en un rea circundante al usuario. Informacin oportuna georeferenciada mientras el usuario est en movimiento. Posibilidad de completar la transaccin de forma inmediata.

CAPTULO 1. INTRODUCCIN

Por ello debe ofrecer al usuario las siguientes prestaciones: Negociacin y entrega inmediata. Mtodos de micro y macro pagos. Facilidades de uso en el contexto mvil.

1.3

Computacin Ubicua

La ubicuidad es la propiedad por la cual una entidad existe o se encuentra en todos los sitios al mismo tiempo. La Computacin Ubicua pretende la integracin de las nuevas tecnologas en el entorno personal, insertando dispositivos inteligentes en las tareas diarias, haciendo que interacten de forma natural y desinhibida en todo tipo de situaciones y circunstancias. De esta forma se pretende unir el mundo real con una representacin virtual, apoyndose sobre la inteligencia ambiental y logrando el entorno inteligente.

1.3.1

Concepto

La Computacin Ubicua, tambin denominada Computacin Pervasiva, fue descrita por primera vez por Mark Weiser en 1991. La esencia de su visin era la creacin de entornos llenos de computacin y capacidad de comunicacin, integrados de forma inapreciable con las personas. En la fecha en que Weiser describi su idea no exista la tecnologa necesaria para llevarla a cabo, por lo que no era posible desarrollarla, pero despus de una dcada de progreso, estas ideas son productos comercialmente viables, an cuando fueron en sus orgenes criticadas. [4]

1.3.2

Objetivos

Uno de los objetivos ms importantes de la Computacin Ubicua es integrar los dispositivos computacionales lo ms posible, como se puede ver en la gura 1.2 de la pgina 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 revolucin que cambie el modo de vida. El hecho de enviar la computacin a un segundo plano tiene dos signicados:

1.3. COMPUTACIN UBICUA

El primero es el signicado literal, detallando que la tecnologa de la computacin se debe integrar en los objetos, cosas, tareas y entornos cotidianos. El segundo se reere a que esta integracin se debe realizar de forma que estos elementos no deben interferir en las actividades para las que son usadas, proporcionando un uso ms cmodo, sencillo y til de los mismos.

Figura 1.2: Ideal de Computacin Ubicua. Como ya se ha detallado, en su momento la Computacin Ubicua era una visin inalcanzable, pero hoy en da la evolucin de las tecnologas, hacen que sta sea viable. Siguiendo la Ley de Moore, las previsiones se van cumpliendo, y la capacidad de cmputo de los procesadores avanza rpidamente, adems de la capacidad de almacenamiento, el ancho de banda para las comunicaciones, etc. En resumen, cada poco tiempo tenemos dispositivos ms baratos, ms pequeos y ms potentes, siendo la previsin para los prximos tiempos que siga ocurriendo lo mismo, excepto para un factor, las bateras. Esto supone

10

CAPTULO 1. INTRODUCCIN

una limitacin para los dispositivos que se tratan aqu, porque las capacidades de procesamiento y de almacenamiento crecen exponencialmente, y tambin, aunque no al mismo ritmo crece el consumo de energa pero la capacidad para dotar a estos dispositivos de la energa necesaria crece muy lentamente. [5] Con las nuevas tecnologas tambin disponemos de nuevos materiales, dando lugar a novedosos sistemas, pero tambin existen otros en pleno desarrollo que pueden presentar grandes avances en la Computacin Ubicua. Por lo tanto, los objetos cotidianos en los que se integra la tecnologa de computacin, tienen una serie de caractersticas que permiten y delimitan la creacin del entorno ubicuo buscado: Comunicacin entre dispositivos, ya que los elementos del sistema disponen no slo de capacidad de computacin, sino tambin de comunicacin, tanto con el usuario como con los dems elementos a su alrededor mediante WiFi, Bluetooth, GPRS/UMTS, UWB, RFID, etc. Disponibilidad de memoria, que puede ser usada para almacenar informacin y as mejorar la interaccin con el resto de dispositivos. Sensibilidad al contexto, siendo capaces de adaptarse a diferentes situaciones, como su situacin geogrca, 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 estmulos o eventos, que pueden percibir en su entorno a travs de sensores o mediante interaccin con otros dispositivos. La Computacin Ubicua, incorpora cuatro nuevos conceptos: Uso ecaz de espacios perspicaces: Se basa, en la deteccin del estado de un individuo y de sus necesidades, deducidas de dicho estado, ya sea en la ocina, sala de reuniones, clase, domicilio, coche, etc. El espacio perspicaz surge cuando varios dispositivos inteligentes coinciden en el mismo espacio fsico e interactan colaborativamente para dar soporte a los individuos que se encuentren en l. La domtica, computacin ubicua en el domicilio, es la aplicacin ms popular. Invisibilidad: Actualmente, se est lejos de la propiedad expuesta por Weiser para los sistemas ubicuos, la completa desaparicin de la tecnologa de la consciencia del usuario. Una buena aproximacin es tener presente, en el diseo de estos sistemas, la idea de mnima distraccin del usuario. La invisibilidad va a requerir del cambio drstico en el tipo de interfaces que nos comunican con los computadores. Reconocimiento de voz y de gestos, comprensin del lenguaje natural y del texto manuscrito, en la direccin hombre mquina y en el sentido contrario, sntesis

1.3. COMPUTACIN UBICUA

11

de lenguaje hablado y escrito y de representaciones grcas. Escalabilidad local: El concepto de localidad de servicios en computacin 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 domticas situadas en el domicilio particular tengan que estar escrutando las necesidades del usuario que se encuentra trabajando en ese momento en la ocina. Al igual que la mayora de las interacciones en la naturaleza, la proporcionada por estos sistemas, decrece con la distancia al usuario. Ocultacin de los desniveles de acondicionamiento: Dependiendo de la infraestructura y del desarrollo tecnolgico disponible, la distribucin de los servicios ofrecidos puede ser muy poco uniforme, en esta situacin el principio de invisibilidad puede no cumplirse ya que el usuario detectara desagradables transiciones. Este requisito es hoy da el ms alejado respecto de la situacin ideal, los sistemas que incorporan computacin ubicua estn aislados, sin continuidad entre unos y otros. En la gura 1.3 de la pgina 12, se describe una arquitectura genrica de un dispositivo de computacin ubicua, que permite interactuar con el usuario a travs de su interfaz (tanto de entrada como de salida), obtener el contexto e informacin relevante del mundo real para dar el soporte adecuado a sus necesidades y modicar el entorno en base a la informacin capturada por los sensores y las acciones realizadas a travs de los actuadores, y mediante su interfaz de red puede coordinarse con otros elementos del sistema. Se puede ir viendo cmo el usuario toma un rol principal en el sistema, por lo que tiene sentido adoptar una perspectiva de diseo centrada en el usuario, a la hora de idear e implementar los posibles servicios y aplicaciones.

1.3.3

Diseo centrado en el usuario

La arquitectura y diseo de los sistemas ubicuos giran entorno a las caractersticas de los usuarios. Adems, a la hora de disear el sistema, se debe tener presente que ciertas capacidades son necesarias: Identicar al usuario: En este sentido se puede pensar en dos estrategias posibles, la utilizacin de seales de identidad (tags) que porta el

12

CAPTULO 1. INTRODUCCIN

Figura 1.3: Arquitectura Genrica de un Dispositivo de Computacin Ubicua propio usuario o el uso de sensores que le reconocen por alguna caracterstica o conjunto de ellas (biometra). Reconocer el estado del usuario: El sistema debe adquirir informacin del estado del usuario con el n de tomar decisiones acertadas, en este sentido la localizacin tanto espacial como temporal es considerada como parte del estado del individuo. Inferir sus necesidades: Una vez conocido el estado del usuario, pueden determinarse cules van a ser sus necesidades, a travs de sus hbitos de comportamiento, basndose 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 fsico que cambiarn el estado y las necesidades de los usuarios. Esta capacidad requiere ser diseada con especial cuidado, ya que no todos los usuarios estn 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 diseo centrado en el usuario es una losofa y proceso de diseo en el que las necesidades, los deseos y las limitaciones del usuario

1.3. COMPUTACIN UBICUA

13

nal del sistema toman una atencin y relevancia considerable en cada nivel del proceso de diseo. El diseo centrado en el usuario puede ser caracterizado como un problema de resolucin en mltiples niveles, que no slo requiere diseadores para que analicen y prevean cmo los usuarios se sienten ms a gusto en el uso de una interfaz o una accin, sino tambin para probar la validez de sus hiptesis teniendo en cuenta las conductas del usuario con pruebas en la vida real con usuarios actuales. Tales pruebas son tan necesarias como difciles para los diseadores de un sistema, de comprender en forma intuitiva lo que un usuario primerizo experimenta de sus diseos, y cmo es la curva de aprehensin de cada usuario.

Figura 1.4: Fases del Diseo Orientado al Usuario Las tecnologas en ocasiones son demasiado complicadas para la audiencia objetivo, por lo que el diseo de la interaccin con los usuarios pretende minimizar la curva de aprendizaje e incrementar la precisin y eciencia de una tarea sin disminuir su utilidad. As, se pretende disminuir la frustracin e incrementar la productividad y satisfaccin del usuario. El proceso de diseo centrado en el usuario se compone de varias fases (ver gura 1.4 de la pgina 13), ideadas para involucrar al mximo al propio

14

CAPTULO 1. INTRODUCCIN

usuario, sus necesidades, caractersticas y objetivos que espera del sistema nal. 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 continuacin se detallan los mismos: Investigacin de diseo: En base a ciertas tcnicas (observacin, entrevistas, cuestionarios, etc.) los diseadores deben investigar sobre los usuarios y su entorno, para aprender ms sobre ellos y as ser capaces de disear para ellos. Anlisis de la investigacin y generacin del concepto: En base a la informacin obtenida de los usuarios, las posibilidades tecnolgicas y las oportunidades de negocio, los diseadores crean, idean y realizan esbozos de nuevo software, servicios o sistemas. Este proceso puede involucrar varias fases de brainstorming, discusiones y renamiento. Para extraer los requisitos de los usuarios, los diseadores pueden hacer uso de perles de usuarios existentes; a partir de los requisitos se pueden crear los escenarios de aplicacin, y un resumen de alto nivel de los objetivos del desarrollo. Diseo alternativo y evaluacin: Una vez denido el problema a resolver, los diseadores son capaces de desarrollar soluciones alternativas acompaadas de prototipos bsicos, que apoyen los conceptos e ideas propuestos. Estas soluciones son evaluadas y a veces fusionadas, dando lugar a un diseo que cubra el mayor nmero de requisitos posibles. Prototipado y test de usabilidad: Los diseadores de interaccin usan una gran variedad de tcnicas de prototipado para probar aspectos de ideas de diseo. 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 implementacin. Implementacin: Los diseadores de la interfaz tienen que estar involucrados en el desarrollo del producto, para conrmar que el diseo se est implementando correctamente. En ocasiones, se necesitan realizar cambios durante el proceso de creacin, y por lo tanto los diseadores deben actuar sobre el diseo de la interfaz. Pruebas del sistema: Una vez que el sistema est terminado, se deben denir y realizar otra ronda de tests, tanto para controlar la usabilidad como los posibles errores.

1.4. LA LEY DE MOORE Y LA VISIN DE WEISER

15

En base al proceso denido para la creacin 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 camuados en el entorno.

1.4

La Ley de Moore y la Visin de Weiser

Los constantes avances en microelectrnica se han convertido en algo comn: la ley de Moore, formulada en los aos sesenta por Gordon Moore, arma que la capacidad de computacin disponible en un microchip se multiplica por dos aproximadamente cada 18 meses y, de hecho, esto ha resultado ser un pronstico extraordinariamente exacto del desarrollo del chip desde entonces. Se puede observar tambin un crecimiento exponencial comparable en otras reas de la tcnica, como por ejemplo en la capacidad de almacenamiento y el ancho de banda para la comunicacin. Visto de otra forma, los precios para la funcionalidad microelectrnica con la misma capacidad de computacin estn bajando gradualmente de forma radical. Esta tendencia que no cesa producir una profusin de computadores muy pequeos en un futuro no demasiado lejano, lo que anuncia un cambio de paradigma en las aplicaciones informticas: se montarn procesadores, dispositivos de memoria y sensores para formar una amplia gama de aparatos electrnicos de informacin baratos, que estarn conectados sin cables a Internet y sern construidos de forma personalizada para realizar tareas especcas. Estos componentes microelectrnicos se podrn incrustar adems en casi cualquier tipo de objeto cotidiano, lo que le aadir sensibilidad (smartness), por ejemplo modicando su comportamiento dependiendo del contexto en que se encuentre del objeto. Al nal, el procesamiento de la informacin y las capacidades de comunicacin quedarn integrados en objetos que, por lo menos a primera vista, no parecern de ningn modo aparatos elctricos, de esta forma las capacidades de la computacin se volvern ubicuas. El trmino computacin ubicua (ubiquitous computing), que denota esta visin, fue acuado hace ms de diez aos por Mark Weiser , un investigador del Palo Alto Research Center de XEROX. Weiser ve la tecnologa solamente como un medio para un n y como algo que debera quedar en segundo plano

16

CAPTULO 1. INTRODUCCIN

para permitir al usuario concentrarse completamente en la tarea que est realizando. En este sentido, considerar el computador personal como herramienta universal para la tecnologa de la informacin sera un enfoque equivocado, ya que su complejidad absorbera demasiado la atencin del usuario. Segn Weiser , el computador como dispositivo dedicado debera desaparecer, mientras que al mismo tiempo debera poner a disposicin de todo lo que nos rodea sus capacidades de procesamiento de la informacin.

Figura 1.5: MarkWeiser (1952-1999), el Visionario de la Computacin Ubicua Weiser ve el trmino computacin ubicua en un sentido ms acadmico e idealista como una visin de tecnologa discreta, centrada en la persona, mientras que la industria ha acuado por eso el trmino computacin pervasiva, o ampliamente difundida pervasive computing con un enfoque ligeramente diferente: Aunque su visin siga siendo todava integrar el procesamiento de la informacin en objetos cotidianos de forma casi invisible, su objetivo principal es utilizar tales objetos en un futuro prximo en el mbito del comercio electrnico y para tcnicas de negocios basados en la Web. Esta variante pragmtica de computacin ubicua est empezando ya a tomar forma: El presidente de IBM Lou Gerstner describa una vez su visin de la era post-PC como mil millones de personas interactuando con un milln de negocios electrnicos a travs de un billn de dispositivos inteligentes interconectados.

1.5. SIC

17

1.5

Sociedad de la Informacin y el Conocimiento (SIC)

El trmino Sociedad de la Informacin ha sido incorporado, con relativa insistencia, en los aos recientes, a la literatura poltica, acadmica y meditica contemporneas. Periodistas, polticos, cibernautas, acadmicos e investigadores suelen evocar tan ambiguo concepto para referirse al tipo de sociedades deseables a las cuales habr de conducirnos la globalizacin. [6] La Cumbre Mundial sobre la Sociedad de la Informacin (CMSI) [7], organizada por el sistema de la ONU bajo el auspicio de Ko Annan, la Unin Internacional de Telecomunicaciones (UIT), y otras agencias de la ONU interesadas en la materia, planea adoptar una declaracin que incorpore un conjunto de principios y reglas de conducta destinados a crear a nivel mundial una Sociedad de la Informacin ms inclusiva y equilibrada; un plan de accin y una declaracin de principios que formulen propuestas operativas y medidas concretas para que todos los actores se benecien ms equitativamente de las oportunidades que conceder la Sociedad de la Informacin en el futuro. Las organizaciones cvicas internacionales que ms han participado a nivel mundial en la discusin y construccin del futuro que debe adoptar la sociedad de la informacin a travs de la CMSI, poseen una visin diferente a la manejada por los organismos econmicos y polticos internacionales tradicionales que han creado esencialmente un proyecto de expansin de las empresas como negocios ecientes y no en el mejoramiento generalizado de las condiciones de vida de los seres humanos. Por ello, la sociedad civil ha proclamado la otra versin de lo que debe ser la Sociedad de la Informacin y de la Comunicacin y fundamenta su concepcin, en las siguientes bases: concepcin de la sociedad de la informacin, principios guas.

1.5.1

La Visin Sobre las Sociedades de la Informacin y de la Comunicacin

La sociedad civil entiende a las sociedades de la informacin y de la comunicacin como realidades basadas en los derechos humanos y en el desarrollo humano duradero. Los sucesos que denen las sociedades de la informacin y de la comunicacin deben basarse en principios de justicia econmica, poltica y social y deben perseguir objetivos de desarrollo humano duradero, adems del apoyo a la democracia, la participacin, el fortalecimiento y la igualdad de

18

CAPTULO 1. INTRODUCCIN

gneros.

1.5.2

Principios Gua

Para alcanzar los objetivos anteriores las estrategias de desarrollo de sociedades de la informacin y de la comunicacin debern estar guiadas por los siguientes principios que respondan a la visin expuesta: Preponderancia de los derechos humanos y del desarrollo humano duradero. El derecho a la comunicacin. Acceso a la informacin y a los medios de comunicacin. Fomentar la diversidad cultural y lingstica. Adoptar una perspectiva democrtica para las sociedades de informacin y comunicacin.

1.5.3

Hacia las sociedades de informacin y comunicacin

En la CMSI se abordarn cuestiones tales como las barreras que encuentran la ciudadana y las naciones en el acceso a las sociedades de la informacin. La CMSI reconoce, especca y abiertamente, un conjunto de diversos tipos de barreras y no slo un concepto monoltico de brecha digital. Se har gran hincapi en tratar las barreras que encuentran los pases menos desarrollados (LDC) y se otorgar especial atencin a los pueblos indgenas que tienen un estatus socioeconmico bajo en la mayora de los pases de residencia, incluso en pases desarrollados. Otros temas a tratar aqu incluiran: barreras educativas, culturales, econmicas y sociales; barreras sociales y polticas; relaciones y roles de gnero; requisitos para lograr un acceso universal y equitativo; la informacin en tanto que bien pblico, con especial consideracin acerca de la propiedad intelectual y cultural; libertad de expresin y de medios; apoyo a la diversidad lingstica y cultural con el n de eliminar las barreras y roles de los gobiernos, la sociedad civil y el sector privado en la eliminacin de los obstculos que impiden la creacin de sociedades de informacin y comunicacin.

1.6. TICS

19

La Cumbre deber examinar algunos de los temas regulatorios como la libertad de expresin; la proteccin de la informacin; el acceso a la misma; la privacidad y seguridad de las redes; la privacidad en el lugar de trabajo; la proteccin de la comunidad de consumidores, especialmente en lo que respecta al correo no deseado y a la creacin de categoras de poblacin electrnicas.

1.6

Tecnologas de la Informacin y la Comunicacin

Por Tecnologas de la Informacin y de la Comunicacin (TICs) se entiende un concepto difuso empleado para designar lo relativo a la informtica conectada a Internet y, especialmente, el aspecto social de stos. TICS : Se denomina as a las Tecnologas de la Informacin y de la Comunicacin. Tambin se las suele denominar Ntics (por Nuevas Tecnologas de la Informacin y de la Comunicacin). Parece pues necesario conectar el concepto a un conjunto de estructuras materiales, localizar el origen de la difusin de estas estructuras en el tiempo y en el espacio geogrco y delimitar el fenmeno del espacio virtual que estas estructuras hacen posible. Dentro de sta denicin general encontramos los siguientes temas principales: Sistemas de comunicacin. Informtica. Herramientas omticas que contribuyen a la comunicacin. Las TIC agrupan un conjunto de sistemas necesarios para administrar la informacin, y especialmente las computadoras y programas necesarios para convertirla, almacenarla, administrarla, transmitirla y encontrarla. Los primeros pasos hacia una Sociedad de la Informacin se remontan a la invencin del telgrafo elctrico, pasando posteriormente por el telfono jo, la radiotelefona y, por ltimo, la televisin. Internet, la telecomunicacin mvil y el GPS pueden considerarse como nuevas tecnologas de la informacin y la comunicacin. La revolucin tecnolgica que vive la humanidad actualmente es debida en buena parte a los avances signicativos en las tecnologas de la informa-

20

CAPTULO 1. INTRODUCCIN

cin y la comunicacin. Los grandes cambios que caracterizan esencialmente a esta nueva sociedad son: la generalizacin del uso de las tecnologas, las redes de comunicacin, el rpido desenvolvimiento tecnolgico y cientco y la globalizacin de la informacin.

1.6.1

Aspecto social de las TIC

La introduccin de estas tecnologas consigue un cambio de nuestra sociedad. Se habla de sociedad de la informacin o sociedad del conocimiento. Se trata de un cambio en profundidad de la propia sociedad. Las nuevas tecnologas de la informacin y la comunicacin designan a la vez un conjunto de innovaciones tecnolgicas pero tambin las herramientas que permiten una redenicin radical del funcionamiento de la sociedad. La puesta en prctica de las TIC afecta a numerosos mbitos de las ciencias humanas, la teora de las organizaciones o la gestin. La expansin de las tecnologas de la informacin y la comunicacin basadas en la microelectrnica, la informtica, la robtica y las redes de comunicaciones se est produciendo a gran velocidad en todos los mbitos socioeconmicos y de las actividades humanas congurando la nombrada Sociedad de la informacin.

1.7

Tecnologa en el Restaurant

Desde la aparicin de las computadoras stas han sido usadas en los sistemas de informacin de las empresas para facilitar el trabajo de control y gestin gracias a la capacidad de recopilar y procesar gran cantidad de datos. En entornos fuertemente competitivos las empresas han comprendido que las inversiones en tecnologas de la informacin pueden incrementar de forma signicativa la competitividad de la empresa. Aunque las necesidades tecnolgicas de los restaurantes parezcan inferiores en comparacin a otros sectores, muchos estudios hablan del uso de las TIC en estos, que a causa de la globalizacin y de una competencia creciente, estos restaurantes cada vez se ven ms obligados a realizar inversiones en este campo. Hoy en da parece impensable que un restaurant no tenga pgina web y en el caso ideal su sistema de informacin debera estar preparado para

1.7. TECNOLOGA EN EL RESTAURANT

21

afrontar retos como el E-Commerce o poder ofrecer servicios como Wi-Fi a sus clientes.

1.7.1

Benecios e inconvenientes del uso de las tecnologas de la informacin en el sector gastronmico.

Las TIC se han convertido en una fuente de ventajas competitivas y en un arma estratgica, especialmente en sectores donde la informacin juega un papel fundamental en la descripcin, promocin y distribucin de sus productos. Pueden ser requisitos para formar alianzas estratgicas, desarrollar canales de distribucin innovadores y nuevas vas de comunicacin con proveedore clientes Existe una relacin 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 informacin relevante e incrementando la comunicacin entre los diferentes departamentos o unidades funcionales, evitando las ineciencias.

Figura 1.6: Benecios Obtenidos de la Introduccin de Tecnologa.

22

CAPTULO 1. INTRODUCCIN

En la gura 1.6 de la pgina 21 se detallan los benecios obtenidos por la aplicacin de las tecnologas de la informacin y las comunicaciones. En el esquema vemos como todos los benecios se centran en el cliente. Para mejorar el grado de satisfaccin del cliente es necesaria la introduccin de tcnicas como data warehouse, data mining o Customer Relationship Management. Estas tcnicas permiten recopilar y consolidar datos del cliente de todos los puntos de contacto con l, antes, durante y despus 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 satisfaccin del cliente con el uso de las TIC. La incorporacin de nuevas tecnologas no est sin embargo exenta de riesgos. Segn estudios un 90% de los proyectos de TIC no alcanzan los objetivos, un 80% estn por encima del presupuesto o tiempo de implementacin 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 tecnolgicas ha sido discutido. Algunos estudios enuncian que mediante la aplicacin de tecnologas de la informacin se obtienen mejoras en el funcionamiento de la empresa, pero otros enuncian que no hay relacin entre productividad y la aplicacin de estas tecnologas o que incluso hay un efecto negativo en su aplicacin. Mientras que en otros se llega a la conclusin que para obtener benecio es necesario aprovechar las capacidades de integracin, informacin y transformacin que tienen estas tecnologas, as como hacer un uso ms estratgico. El cambio del sistema de informacin en una empresa es un momento crtico. La empresa debe dejar de trabajar con un sistema que ya es conocido por los usuarios y que cumple una serie de requerimientos mnimos para dar soporte a los procesos crticos 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 transicin 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. TECNOLOGA 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 cooperacin por parte del personal. Un punto clave es la formacin del personal antes, durante y despus de la puesta en funcionamiento del nuevo sistema. Especialmente crtico es en un sector como el gastronmico donde muchos de los usuarios que van a utilizar el sistema tienen un perl de formacin bajo.

Captulo 2

Tecnologa Mvil
2.1 Telefona Mvil

2.1.1

Celulares: Concepto General

Se dene al telfono mvil o celular como un dispositivo electrnico de comunicacin, normalmente de diseo reducido y sugerente, basado en la tecnologa de ondas de radio, que tiene la misma funcionalidad que cualquier telfono de lnea ja. Su rasgo caracterstico principal es que se trata de un dispositivo portable e inalmbrico, es decir, que la realizacin de llamadas no es dependiente de ningn terminal jo y que no requiere de ningn tipo de cableado para llevar a cabo la conexin a la red telefnica. [8] Adems de ser capaz de realizar llamadas como cualquier otro telfono convencional, un celular moderno suele incorporar un conjunto de funciones adicionales que aumentan la potencialidad de utilizacin de estos dispositivos. Es ms, su desarrollo y exigencia ha llegado a tal punto, que se puede hablar incluso de trminos tales como memoria RAM. Y considerando que estos pueden crear y reproducir informacin de todo tipo (audio, video, texto, etc.), hace de estos un complemento perfecto tanto para el hombre comn como para el de negocios. 25

26

CAPTULO 2. TECNOLOGA MVIL

2.1.2

Un Poco de Historia

La telefona mvil utiliza ondas de radio para poder ejecutar todas y cada una de las operaciones de comunicacin, ya sea llamar, mandar un mensaje de texto, etc., y esto es producto de lo que sucedi hace algunas dcadas. [9] La comunicacin inalmbrica tiene sus races en la invencin del radio por Nikola Tesla en los aos 1880, aunque formalmente presentado en 1894 por un joven italiano llamado Guglielmo Marconi. El telfono mvil se remonta a los inicios de la Segunda Guerra Mundial, donde ya se vea que era necesaria la comunicacin a distancia, es por eso que la compaa Motorola cre un equipo llamado Handie Talkie H12-16 el cual se puede apreciar en la gura 2.1 de la pgina 26, el cual permita el contacto con las tropas va ondas de radio que en ese tiempo no superaban ms de 600 kHz.

Figura 2.1: Handie Talkie12-16 Fue slo cuestin de tiempo para que las dos tecnologas de Tesla y Marconi se unieran y dieran a luz a la comunicacin mediante radio-telfonos. Martin Cooper , gura 2.2 de la pgina 27, pionero y considerado como el padre de la telefona celular , fabric el primer radio telfono entre 1970 y 1973, en Estados Unidos. La gente desea hablar con la gente - no en una casa, o en una ocina, o en un coche. Dales la opcin, y la gente exigir la libertad para comunicarse dondequiera que este, desencadenndose del infame alambre de cobre. Es esa libertad que intentamos demostrar vividamente en 1973 dijo Martin Cooper. [10]

2.1. TELEFONA MVIL

27

Figura 2.2: Martin Cooper mostrando el primer telfono celular. ArrayComm

En 1979 aparecieron los primeros sistemas a la venta en Tokio (Japn), fabricados por la Compaa NTT. Los pases europeos no se quedaron atrs 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 pas adopt reglas para la creacin de un servicio comercial de telefona celular, en 1983 se puso en operacin el primer sistema comercial en la ciudad de Chicago. Este fue el inicio de una de las tecnologas que ms avances tiene, aunque contina en la bsqueda de novedades y mejoras. Hace una dcada aproximadamente los telfonos celulares se caracterizaban slo por llamar, pero ha sido tanta la evolucin que ya se puede hablar de equipos Multimedia que pueden llamar y ejecutar aplicaciones, jugar juegos 3D, ver videos, ver televisin y ms. Obviamente muchas marcas de placas madres para PC o fabricantes de hardware en general se hacen presentes en los telfono mviles como por ejemplo: ASUS e INTEL que construyen las placas matrices de lo celulares o ayudan con el acelerador grco o el sistema de video. En n, se debe tener conciencia y estar preparados para lo que se viene ms adelante y pensar que el telfono celular ya no es tan slo para hablar, y de esta forma poder aprovechar las situaciones de negocios que estos nos brindan.

28

CAPTULO 2. TECNOLOGA MVIL

2.1.3

Generaciones del Celular

0-G: Generacin 0 Tristemente, siempre se dice que las guerras agudizan la inventiva y el ingenio del hombre, no solo a nivel armamentstico, sino a otros muchos niveles tales como el de las comunicaciones. Por supuesto, la Segunda Guerra Mundial no fue una excepcin. La compaa Motorola lanz el Handie Talkie H12-16, el cual permita la comunicacin a distancia entre las tropas, un dispositivo basado en la transmisin mediante ondas de radio que, a pesar de trabajar por aquel entonces con un espectro de 550 MHz aproximadamente, supuso una revolucin de enormes proporciones.

Figura 2.3: Publicidad del Motorola Handie Talkie H12-16 Esta tecnologa fue aprovechada a partir de los aos 50 y 60 para crear una gran variedad de aparatos de radio y de comunicacin a distancia (los tradicionales Walkie-Talkies), utilizados sobretodo por servicios pblicos tales como taxis, ambulancias o bomberos. Aunque realmente estos dispositivos no pueden ser considerados como telfonos mviles, la implementacin de los primeros supuso el comienzo de la evolucin hacia los dispositivos que conocemos en la actualidad. Los primeros estndares ms utilizados, en los que se fundament esta generacin 0, fueron: Estndar PTT (Push To Talk): Pulsar para Hablar. Estndar IMTS (Improved Mobile Telefone System): el Sistema de Telefona Mvil Mejorado.

2.1. TELEFONA MVIL

29

1-G: Mviles de Primera Generacin Surgidos a partir de 1973 y con un tamao y peso inmanejable, los mviles de primera generacin funcionaban de manera analgica, es decir que la transmisin y recepcin de datos se apoyaba sobre un conjunto de ondas de radio que cambiaban de modo continuo. El hecho de que fueran analgicos traa consigo una serie de inconvenientes, tales como que solo podan ser utilizados para la transmisin de voz (el uso de mensajera instantnea era algo solo visible en un futuro muy lejano) o su baja seguridad, la cual haca 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 generacin considerada realmente como de telfonos mviles. Estndares ms utilizados: NMT: Nordic Mobile Telephone AMPS: Advaced Mobile Phone System

2-G: Segunda Generacin Al contrario de lo que pasa en otras generaciones, la denominada segunda generacin no es un estndar concreto, sino que marca el paso de la telefona analgica a la digital, que permiti, mediante la introduccin de una serie de protocolos, la mejora del manejo de llamadas, ms enlaces simultneos en el mismo ancho de banda y la integracin 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 compaas, siendo este hecho el origen de uno de los principales problemas de esta generacin la incompatibilidad entre protocolos, debido a que el radio de utilizacin del telfono quedaba limitado al rea en el que su compaa le diera soporte. Estndares ms utilizados:

30

CAPTULO 2. TECNOLOGA MVIL

Figura 2.4: La evolucin de los telfonos celulares fue ms all de las caractersticas tcnicas. Se puede apreciar cmo en tamao y peso la evolucin fue considerable. GSM: Global System for Mobile Communications - Sistema Global para Comunicaciones Mviles. CDMA: Code Division Multiple Access - Acceso Mltiple por Divisin de Cdigo. GPRS: General Packet Radio Service - Servicio General de Radio por Paquetes. 3-G: Tercera Generacin El ao 2001 fue un ao revolucionario en el mbito de la telefona mvil ya que supuso la aparicin de los primeros celulares que incorporaban pantalla LCD a color, hecho que abra un inmenso abanico de posibilidades en cuanto a adaptacin de nuevas funciones se reere. As, pronto el usuario pudo asistir al nacimiento de dispositivos que se crean como mnimo futuristas tales como mviles con cmara fotogrca di-

2.1. TELEFONA MVIL

31

gital, posibilidad de grabar videos y mandarlos con un sistema de mensajera instantnea evolucionado, juegos 3d, sonido Mp3 o poder mantener conversaciones por videoconferencia gracias a una tasa de transferencia de datos ms que aceptable y a un soporte para Internet correctamente implementado (correo electrnico, descargas, etc.). Todo este conjunto de nuevos servicios integrados en el terminal junto con un nuevo estndar dieron lugar a la denominada hoy en da tercera generacin de mviles o mviles 3G. Estndares ms utilizados: UMTS: Universal Mobile Telecommunications System - Servicios Universales de Comunicaciones Mviles. Concepto de la Red de Telefona Celular La red se constituye bsicamente en torno a dos tipos de elementos: Estaciones base: son las encargadas de transmitir y recibir la seal. Centrales de conmutacin: son las que permiten la conexin entre dos terminales concretos. La adecuada combinacin de estos dos elementos posibilita la comunicacin tanto entre telfonos mviles como entre un celular y un telfono jo. Se ve entonces que la telefona mvil, es algo ms que el telfono mvil. Funcionamiento de la Red A nivel general, su funcionamiento es bastante sencillo. Las estaciones base se disponen creando una gran malla con forma de clula o celda (cell; de ah que se denomine a este tipo de telfonos, telfonos celulares), conectando mediante ondas de radio dos terminales con los controladores de dichas estaciones base. Esta disposicin en forma de panal no es meramente casual, sino que responde a un esquema que permite la reutilizacin de un determinado conjunto

32

CAPTULO 2. TECNOLOGA MVIL

de frecuencias asignadas en distintas celdas, siempre que estas no sean adyacentes, aumentando el rendimiento de la red por un lado (el nmero de frecuencias de que se dispone es limitado), y economizando por otro.

Figura 2.5: Celdas En la gura 2.6 de la pgina 33, se puede apreciar detalladamente la arquitectura de un sistema celular mvil segn el estndar GSM, uno de los ms utilizados hoy en da.

2.2

La Computadora Porttil

A lo largo de los aos, las computadoras personales porttiles han sufrido algunos cambios que las hacen ser como lo son hoy da, aunque no se parecen en nada a sus principios. Resulta muy difcil establecer un orden cronolgico de la historia y secuencias de la computadora porttil y su evolucin porque nadie puede asegurar quin fue el primero en desarrollar el primer ordenador mvil. Algunos arman que el pionero fue Alan Kay, del centro de investigacin 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 porttil parecido a los que usamos hoy en da, algo pequeo y ligero que cualquiera se pudiera permitir.

2.2. LA COMPUTADORA PORTTIL

33

Figura 2.6: Arquitectura GSM Otros aseguran que el porttil fue construido en 1979 por William Moggridge el cual trabajaba para la corporacin Grid Systems. Tena 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 porttil que existi fue creado en 1983 por Gavilan Computers. Este porttil tena de 64 a 128 megabytes de memoria, un ratn e incluso una impresora porttil. Su peso, sin la impresora, era algo mayor que los actuales. Gavilan fracaso tiempo despus por problemas de incompatibilidad con otros ordenadores. El porttil de Gavilan usaba su propio sistema operativo. Apple Computers introdujo el modelo Apple IIc en 1984, el cual se puede apreciar en la gura 2.7 de la pgina 34, pero no era mucho mejor que lo que haba producido Gavilan un ao antes. Un punto favorable era que inclua la funcin opcional de LCD lo cual impact en posteriores equipos. Finalmente en 1986 un porttil real fue creado por IBM el cual lo llam PC de IBM Convertible, el cual se puede apreciar en la gura 2.8 de la pgina 35. Se calica como real porque al contrario de otros, a este porttil no se le tena que hacer una conguracin inicial en cada sitio. Tambin posea dos disqueteras de 3.5 pulgadas y espacio para un mdem interno. En este

34

CAPTULO 2. TECNOLOGA MVIL

convertible podamos encontrar una pantalla LCD y algunas aplicaciones bsicas que los usuarios podan usar para crear documentos de texto, y tomar notas. El precio del porttil de IBM rondaba los 3500 dlares de aquella poca. Hoy en da pagar ese precio por un porttil moderno est fuera de toda consideracin, afortunadamente. Desde los aos ochenta, muchos fabricantes estn produciendo y desarrollando nuevos equipos cada vez ms rpidos y potentes dejando en el olvido a sus predecesores. Y segn avanza la tecnologa, los precios se vuelven ms competitivos hasta el punto de que cualquier persona puede disponer de una computadora porttil.

Figura 2.7: Modelo Apple IIc de Apple Computers - 1984

2.3

PDAs

PDA, del ingls Personal Digital Assistant, Ayudante Personal Digital, es una computadora de mano originalmente diseada como agenda electrnica (calendario, lista de contactos, bloc de notas y recordatorios) con un sistema de reconocimiento de escritura. Hoy da se puede usar como una computadora domstica (ver pelculas, crear documentos, juegos, correo electrnico, navegar por Internet, escuchar msica, 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 tcnicamente clasicado como palmtop, fue una muestra temprana de algunos de los ms modernos dispositivos electrnicos. 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 mencin formal del trmino 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 nanciero para la compaa Apple, dejando de venderse en 1998. La tecnologa estaba an poco desarrollada y el reconocimiento de escritura en la versin original era bastante impreciso, entre otros problemas. An as, este aparato ya contaba con todas las caractersticas del PDA moderno: pantalla sensible al tacto, conexin a una computadora para sincronizacin, interfaz de usuario especialmente diseada para el tipo de mquina, conectividad a redes va mdem y reconocimiento de escritura. En 1995 con la aparicin de la empresa Palm comenz una nueva etapa de crecimiento y desarrollo tecnolgico 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

CAPTULO 2. TECNOLOGA MVIL

genrico del producto. La irrupcin 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 pblico ya acostumbrado al uso de sus programas y que se los encontraban en versin reducida. La irrupcin de los Smartphones, hbridos entre PDA y telfono mvil , trajeron por un lado nuevos competidores al mercado y por otro incorporaron al usuario avanzado de mviles al mercado. Tambin supuso la vuelta de un sistema operativo que haba abandonado el mercado de las PDAs y ordenadores de mano en favor de los mviles: el Symbian OS. Las PDAs de hoy en da traen multitud de comunicaciones inalmbricas como ser Bluetooth, WiFi, IrDA, GPS, que los hace tremendamente atractivos hasta para cosas tan inverosmiles como su uso para domtica o como navegadores GPS.

2.3.2

Atari Portfolio

El Atari Portfolio, puede verse en la gura 2.9 de la pgina 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 tamao aproximado de una cinta de VHS, estando cerrado. La versin estndar tena 128 kB de RAM, con un disco interno RAM congurable (C:). Tena 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 clculo. Calendario.

2.3. PDAS

37

Figura 2.9: Atari Portfolio Utilizaba un puerto para tarjetas de expansin, que desgraciadamente no era compatible con PCMCIA. Esa expansin estaba localizada en la parte derecha del ordenador. Existan mdulos de expansin para puerto paralelo, serie e incluso MIDI. Adems dispona de un zcalo para insertar tarjetas de memoria de estado slido de 64, 128 y 256 KB a modo de disquetes o de tarjetas Secure Digital. El Atari Portfolio tena un panel LCD sin retroiluminacin y un altavoz capaz de emitir tonos de telfono que usado conjuntamente con la agenda permita marcar nmeros de telfono de manera automtica (marcacin por tonos). Atari no desarroll el Portfolio sino que lo licenci de la empresa DiP. El Portfolio aparece en la pelcula Terminator, donde era utilizado por el protagonista, el joven John Connor, para abrir una puerta con sistema de seguridad a base de tarjeta electrnica y para robar un cajero automtico.

2.3.3

Apple Newton

El Apple Newton, el cual se puede observar en la gura 2.10 de la pgina 38, o simplemente Newton, fue una lnea temprana de asistentes digitales personales desarrollada, manufacturada y comercializada por Apple Computer entre 1993 y 1998. [11]

38

CAPTULO 2. TECNOLOGA MVIL

Figura 2.10: Apple Newton Los Newtons originales estaban basados en el procesador RISC ARM 610 e incluan reconocimiento de escritura manual. El nombre ocial de Apple para el dispositivo era MessagePad; el trmino 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 tambin adopt ese nombre, ya que es una alusin a la manzana de Isaac Newton y encajan perfecto en sus esfuerzos de marketing en lo relacionado a su marca. El Newton permita 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 tambin podan vericar la hora de varias zonas horarias, calcular y vericar mensajes. El Newton fall en su afn de generar un gran cambio en el mercado durante sus cinco aos de vida. Su alto precio, tamao y corta duracin de la batera contribuy a que se discontinuase su fabricacin en 1998. Un accesorio especial para el Newton de Apple fue el mdem fax, diseado especcamente 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 gura 2.11 de la pgina 40, fue el segundo modelo de la primera generacin de PDAs manufacturadas por Palm Computing, entonces conocida como US Robotics. [12] Debutando en Marzo de 1996, la Pilot apareci en un mercado donde tena un solo competidor real: el Apple Newton. El pequeo tamao de las Pilots, las cuales caban en el bolsillo de una camisa, fue denitivamente una ventaja sobre el Apple Newton, que funcionaba de manera muy similar y tena casi exactamente la misma pantalla que el modelo Pilot 5000, esto se puede apreciar en la gura 2.12 de la pgina 41. La Pilot funcionaba con un poder de computo similar al Macintosh SE, alardeando de sus 512 KB de memoria RAM, casi cinco veces ms capacidad de datos que el original modelo Pilot 1000. Ms tarde, Palm Computing venda una tarjeta de expansin de 1 MB para aumentar la capacidad de memoria an ms. Fue tambin 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 integracin con computadoras de escritorio a un bajo costo, y poco consumo de energa. Si bien este dispositivo no contaba con puerto de infrarrojos o de memoria ash, el software de la Pilot poda sincronizar su informacin con la mayora de los PC estndar, permitiendo a los usuarios trabajar y compartir informacin de otros programas de aplicacin en su computadora a travs de su computadora de mano. La sincronizacin de la PDA Pilot 5000 con una PC permita a los usuarios introducir texto desde su teclado de tamao normal y ver las aplicaciones de la Pilot en la pantalla de sus monitores. Y esto haca de la Pilot una pequea pero muy buena herramienta de negocios. Para la informacin de entrada, los consumidores utilizban un lpiz (Stylus) o el popular Grati Text Entry Software, creado por Palm, que permita la entrada de 30 palabras por minuto con una precisin del 100 por ciento.

40

CAPTULO 2. TECNOLOGA MVIL

Figura 2.11: Palm Pilot 5000 La mayora de la informacin se poda acceder con un solo toque, ya que las aplicaciones contaban con buenos tiempos de respuesta. La Pilot vena de varios colores con una carcasa plstica, tena un panel tctil LCD y 160 x 160 mm de pantalla grca y funcionaba con dos pilas AAA, corra aplicaciones simples en blanco y negro. Contaba con aplicaciones pre-cargadas como directorio telefnico, lista de tareas, notas, calculadora y mltiples funciones de bsqueda de aplicaciones, la Pilot tambin 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 da tenemos los siguientes sistemas operativos y equipos competidores: Dispositivos Palm OS, hoy en da mantenido casi en solitario por Palm, pero que hasta hace poco ha tenido importantes fabricantes como Sony; Dispositivos Pocket Pc, con HP como lder de fabricantes acompaado por otras empresas de informtica como Dell o Acer, a quienes se han

2.5. SISTEMAS OPERATIVOS Y EQUIPOS

41

Figura 2.12: Comparativa en tamaos entre la Palm Pilot 5000 y el Apple Newton incorporado los fabricantes de Taiwn 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 telefona mvil ; Research In Motion con sus Blackberry, ms 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 telfonos mviles 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 bsicas de las primeras PDAs, incluyendo cmaras digitales bsicas y comunicaciones con los PCs.

42

CAPTULO 2. TECNOLOGA MVIL

2.6
2.6.1

Estndares
Bluetooth

El nombre procede del rey dans y noruego Harald Bltand cuya traduccin al ingls sera Harold Bluetooth (Diente Azul en su traduccin al espaol, aunque en lengua danesa signica de tez oscura) conocido por buen comunicador y por unicar las tribus noruegas, suecas y danesas. De la misma manera, Bluetooth intenta unir diferentes tecnologas como las de las computadoras, los telfonos mviles y el resto de perifricos. El smbolo de Bluetooth es la unin de las runas nrdicas H y B. [13] Bluetooth es el nombre comn de la especicacin industrial IEEE 802.15.1, que dene un estndar global de comunicacin inalmbrica que posibilita la transmisin 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 mviles y jos. Eliminar cables y conectores entre stos. Ofrecer la posibilidad de crear pequeas redes inalmbricas y facilitar la sincronizacin de datos entre nuestros equipos personales. Los dispositivos que con mayor intensidad utilizan esta tecnologa son los de los sectores de las telecomunicaciones y la informtica personal, como PDAs, telfonos celulares, computadoras porttiles, PCs, impresoras y cmaras digitales. La tecnologa Bluetooth comprende hardware, software y requerimientos de interoperatividad, por lo que para su desarrollo ha sido necesaria la participacin de los principales fabricantes de los sectores de las telecomunicaciones y la informtica, tales como: Sony Ericsson, Nokia, Motorola, Toshiba, IBM e Intel, entre otros. Posteriormente se han ido incorporando muchas ms compaas, y se prev que prximamente lo hagan tambin empresas de sectores tan variados como automatizacin industrial, maquinaria, ocio y entretenimiento, fabricantes de juguetes, electrodomsticos, 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. ESTNDARES

43

Descripcin Bluetooth proporciona una va de interconexin inalmbrica entre diversos aparatos que tengan dentro de s esta tecnologa, como mviles ( Nokia 6600), consolas (Nokia N-Gage), dispositivos PDA, cmaras digitales, computadoras porttiles, impresoras, o simplemente cualquier dispositivo que un fabricante considere oportuno, usando siempre una conexin segura de radio de muy corto alcance. El alcance que logran tener estos dispositivos es de 10 metros para ahorrar energa ya que generalmente estos dispositivos utilizan mayoritariamente bateras. Sin embargo, se puede llegar a un alcance de hasta 100 metros (similar a Wi-Fi) pero aumentando el consumo energtico considerablemente. Para mejorar la comunicacin es recomendable que nada fsico, como por ejemplo una pared, se interponga. El primer objetivo para los productos Bluetooth de primera generacin eran los entornos de la gente de negocios que viaja frecuentemente. Esto originaba una serie de cuestiones previas que deberan solucionarse tales como: El sistema debera operar en todo el mundo. El emisor de radio deber consumir poca energa, ya que debe integrarse en equipos alimentados por bateras. La conexin deber soportar voz y datos, y por lo tanto aplicaciones multimedia. La tecnologa debera tener un bajo costo. Como objetivo se quiso alcanzar los 5 US$ por dispositivo. Muchos dipositivos han adquirido esta caracterstica lo que es un gran avance.

2.6.2

IrDA - Infrared Data Association

Infrared Data Association (IrDA) dene un estndar fsico en la forma de transmisin y recepcin de datos por rayos infrarrojos. IrDA se crea en 1993 entre HP, IBM, Sharp y otros. Esta tecnologa est basada en rayos luminosos que se mueven en el espectro infrarrojo. Los estndares IrDA soportan una amplia gama de dispositivos

44

CAPTULO 2. TECNOLOGA MVIL

Figura 2.13: Bluetooth Apple Mighty Mouse

Figura 2.14: Teclado Bluetooth

2.6. ESTNDARES

45

elctricos, informticos y de comunicaciones, permite la comunicacin bidireccional entre dos extremos a velocidades que oscilan entre los 9.600 bps y los 4 Mbps. Esta tecnologa se encuentra en muchos ordenadores porttiles, y en un creciente nmero de telfonos celulares, sobre todo en los de fabricantes lderes como Nokia y Ericsson. El FIR (Fast Infrared) se encuentra en estudio, con unas velocidades tericas de hasta 16 Mbps. Estructura En IrDA se dene una organizacin en capas, las cuales pueden verse en la gura 2.15 de la pgina 46. Adems 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 diferenciacin permite a los desarrolladores optar por diseos ms ligeros y menos costosos, pudiendo tambin adecuarse a requerimientos ms exigentes sin que sea necesario salirse del estndar IrDA. Protocolos IrDA PHY (Physical Signaling Layer) establece la distancia mxima, la velocidad de transmisin y el modo en el que la informacin se transmite. IrLAP (Link Access Protocol) facilita la conexin y la comunicacin entre dispositivos. IrLMP (Link Management Protocol) permite la multiplexacin de la capa IrLAP. IAS (Information Access Service ) acta como unas pginas amarillas para un dispositivo. Tiny TP mejora la conexin y la transmisin de datos respecto a IrLAP. IrOBEX diseado para permitir a sistemas de todo tamao y tipo intercambiar comandos de una manera estandarizada. IrCOMM para adaptar IrDA al mtodo de funcionamiento de los puertos serie y paralelo.

46

CAPTULO 2. TECNOLOGA MVIL

Figura 2.15: IrDA - Organizacin de sus capas. IrLan permite establecer conexiones entre ordenadores porttiles y LANs de ocina.

2.6.3

IEEE 802.11 o Wi-Fi

El protocolo IEEE 802.11 o Wi-Fi es un estndar de protocolo de comunicaciones del IEEE que dene el uso de los dos niveles ms bajos de la arquitectura OSI (capas fsica y de enlace de datos), especicando sus normas de funcionamiento en una WLAN. En general, los protocolos de la rama 802.x denen la tecnologa de redes de rea local. La familia 802.11 actualmente incluye seis tcnicas de transmisin por modulacin que utilizan todos los mismos protocolos. El estndar original de este protocolo data de 1997, era el IEEE 802.11 , tena 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 estndar. El trmino IEEE 802.11 se utiliza tambin para referirse a este protocolo al que ahora se conoce como 802.11legacy. La siguiente modicacin apareci en 1999 y es designada como IEEE 802.11b, esta especicacin tena velocidades de 5 hasta 11 Mbps, tambin trabajaba en la frecuencia de 2,4 GHz. Tambin se realiz una especicacin 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 tcnicos casi no se desarrollaron productos. Posteriormente se incorpor un estndar a esa velocidad y compatible con el b que recibira el nombre de 802.11g. En la actualidad la mayora de productos son de la especicacin b y de la

2.6. ESTNDARES

47

Figura 2.16: Tarjeta Wi-Fi para PalmOne g. El siguiente paso se dar con la norma 802.11n que sube el lmite terico hasta los 600 Mbps. Actualmente ya existen varios productos que cumplen un primer borrador del estndar N con un mximo de 300 Mbps (80-100 estables). La seguridad forma parte del protocolo desde el principio y fue mejorada en la revisin 802.11i. Otros estndares de esta familia (c-f, h-j, n) son mejoras de servicio y extensiones o correcciones a especicaciones anteriores. El primer estndar de esta familia que tuvo una amplia aceptacin fue el 802.11b. En 2005, la mayora de los productos que se comercializan siguen el estndar 802.11g con compatibilidad hacia el 802.11b. Los estndares 802.11b y 802.11g utilizan bandas de 2,4 Ghz que no necesitan de permisos para su uso. El estndar 802.11a utiliza la banda de 5 GHz. El estndar 802.11n har uso de ambas bandas, 2,4 GHz y 5 GHz. Las redes que trabajan bajo los estndares 802.11b y 802.11g pueden sufrir interferencias por parte de hornos microondas, telfonos inalmbricos 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 emisin de la seal Wi-Fi y para la recepcin se utilizan tarjetas para conectar a los PC, ya sean internas, como tarjetas PCI o bien USB (tarjetas de nueva generacin que no requieren incluir ningn hardware dentro de la computadora).

48

CAPTULO 2. TECNOLOGA MVIL

Los acces points funcionan a modo de emisor remoto, es decir, en lugares donde la seal Wi-Fi del router no tenga suciente seal, se colocan estos dispositivos, que reciben la seal bien por un cable UTP que se lleve hasta l o bien que capture la seal dbil y la amplique (aunque para este ultimo caso existen aparatos especializados que ofrecen un mayor rendimiento). Los routers son los que reciben la seal de la lnea que ofrezca el proveedor, se encargan de todos los problemas inherentes a la recepcin de la seal, donde se incluye el control de errores y extraccin de la informacin, para que los diferentes niveles de red puedan trabajar. En este caso el router efecta el reparto de la seal, de forma muy eciente. Adems de routers, hay otros dispositivos que pueden encargarse de la distribucin de la seal, aunque no pueden encargarse de las tareas de recepcin, como pueden ser hubs y switch, estos dispositivos son mucho ms sencillos que los routers, pero tambin su rendimiento en la red local es muy inferior. Los dispositivos de recepcin 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 eciente, 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 porttiles, la mayor parte de estas tarjetas solo son capaces de llegar hasta la tecnologa b de Wi-Fi, no permitiendo por tanto disfrutar de una velocidad de transmisin demasiado elevada. Las tarjetas USB para Wi-Fi son el tipo de tarjeta ms moderno que existe y ms sencillo de conectar a un PC, ya sea de escritorio o porttil, haciendo uso de todas las ventajas que tiene la tecnologa USB, adems la mayor parte de las tarjetas USB actuales permite utilizar la tecnologa g de Wi-Fi, incluso algunas ya ofrecen la posibilidad de utilizar la llamada tecnologa Pre n. Ventajas y desventajas Una de las desventajas que tiene Wi-Fi es la prdida de velocidad en relacin a la misma conexin utilizando cables, debido a las interferencias y prdidas de seal que el ambiente puede acarrear.

2.7. INTERNET MVIL - 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 contrasea de la red y de esta forma acceder a ella, las claves de tipo WEP son relativamente fciles de conseguir para cualquier persona con un conocimiento medio de informtica. La alianza Wi-Fi arregl estos problemas sacando el estndar 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 relacin a la movilidad que ofrece esta tecnologa, sobre los contras que tiene Wi-Fi es la capacidad de terceras personas para conectarse a redes ajenas si la red no est bien congurada y la falta de seguridad que esto trae consigo. Cabe aclarar que esta tecnologa no es compatible con otros tipos de conexiones sin cables como Bluetooth, GPRS, UMTS, etc.

2.7

Internet Mvil - WAP

Wireless Application Protocol o WAP (protocolo de aplicaciones inalmbricas) es un estndar abierto internacional para aplicaciones que utilizan las comunicaciones inalmbricas, por Ej. Acceso a servicios de Internet desde un telfono mvil. Se trata de la especicacin de un entorno de aplicacin y de un conjunto de protocolos de comunicaciones para normalizar el modo en que los dispositivos

50

CAPTULO 2. TECNOLOGA MVIL

inalmbricos, se pueden utilizar para acceder a correo electrnico, grupo de noticias y otros. El organismo que se encarga de desarrollar el estndar WAP fue originalmente el WAP Forum, fundado por cuatro empresas del sector de las comunicaciones mviles, 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 denicin de diversas normas relacionadas con las comunicaciones mviles, entre ellas las normas WAP.

2.7.1

Tecnologa - WAP

En la versin 1 de WAP, denida en 1999, el lenguaje de presentacin 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 mvil que est usando el terminal. WAP 1 adems dene la interfaz de acceso de las aplicaciones a las funciones de telefona del terminal con WTAI (Wireless Telephony Application Interface), y tambin 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 comunicacin entre un terminal WAP y un servidor de contenidos WAP residente en Internet. WAP 1 ha sido objeto de fuertes crticas por diversos motivos, que incluyen la pobreza del soporte grco (grcos 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 adems, por no ser compatible con las capas de seguridad usadas en Internet, en la pasarela WAP los contenidos deben estar en claro. La nueva versin de WAP, WAP 2.0 , est presente en los telfonos mviles de nueva generacin (a partir de 2004). Esta versin es una reingeniera de WAP que utiliza XHTML-MP (Mobile Prole) como lenguaje de presentacin de contenidos, y mejora el soporte de los grcos (incluye color). En cuanto a los protocolos usados, en la capa de transporte se usa TCP y en la de

2.7. INTERNET MVIL - WAP

51

aplicacin, HTTP. As pues, WAP 2.0 ha adoptado los protocolos de Internet. WAP 2.0 adems especica opciones tanto en TCP como en HTTP para mejorar las prestaciones de dichos protocolos sobre redes de comunicaciones mviles. 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.

Captulo 3

Aplicaciones Mviles
3.1 Introduccin

Los dispositivos de computacin inalmbrica han crecido rpidamente, requiriendo aplicaciones de software cada vez ms potentes que puedan manejar esta nueva realidad. Los usuarios desean que las aplicaciones que corren en sus dispositivos mviles 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 ecientemente el problema del roaming. El rango de dispositivos mviles va desde dispositivos dedicados a tareas especcas, como los telfonos celulares, hasta aquellos dispositivos de propsito general, como las handhelds o como las notebooks. Cada uno de ellos presenta diferentes conjuntos de desafos para el diseo de aplicaciones mviles. Algunos de estos desafos compartidos por la mayora de los dispositivos mviles incluyen: La ubicacin fsica del dispositivo y la conguracin pueden cambiar en cualquier momento a medida que el dispositivo est conectado o desconectado de la red o se mueve entre dos puntos de conexin. La arquitectura de aplicacin mvil debe soportar una operacin consistente operando tanto online como oine y proveer una conectividad continua mientas el dispositivo se mueve entre puntos de conexin. 53

54

CAPTULO 3. APLICACIONES MVILES

Los dispositivos que se alimentan mediante el uso de bateras pueden operar por un tiempo limitado sin recargar o reemplazar las mismas. La arquitectura de una aplicacin mvil debe ser diseada para administrar esa energa limitada de las bateras, mediante el uso de estrategias que prologuen la vida til al reducir el consumo sin sacricar el rendimiento del sistema. Una arquitectura de aplicaciones mviles debe proveer soporte para un amplio rango de dispositivos. Debido a que los dispositivos pequeos de propsito especco, tales como telfonos celulares, poseen limitaciones de recursos como el tamao reducido de sus pantallas, limitado almacenamiento y poder de cmputo. [14]

3.2

Requerimientos Para Una Arquitectura de Aplicaciones Mviles

Una aplicacin diseada para ser usada en un dispositivo mvil debe cumplir con ciertos requerimientos, algunos son propios del ambiente mvil y otros pueden ser requerimientos de cualquier tipo de aplicacin. A continuacin se presentan los ms relevantes: Operacin consistente tanto online como oine: En varias arquitecturas, los datos son almacenados en un sistema compartido accesible a travs de la red, en forma de documentos, registros de datos o archivos binarios, donde se tiene un acceso coordinado a una copia de la informacin. Una aplicacin mvil debe ser diseada de forma de que los usuarios puedan acceder a los datos sin importar si lo hacen en forma online o en forma oine. Cuando se trabaja oine, el usuario percibe que la informacin compartida est disponible para lectura y escritura. Cuando la conectividad regresa, los cambios en la informacin local son integrados a la copia de red y viceversa. Conectividad continua: Una aplicacin diseada 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 conexin con la red deben poder ser manejados satisfactoriamente. As mismo este agente o servicio Proxy debe poder

3.2. REQUERIMIENTOS PARA UNA ARQUITECTURA MVIL

55

seleccionar la red ptima de las disponibles en ese momento, y manejar las tareas propias de la comunicacin como autenticacin segura o autorizacin y direccionamiento lgico. Clientes que soporten multiplataformas: Una aplicacin mvil debe al menos ajustar su interaccin y comportamiento al dispositivo en el que corre, como por ejemplo tipo de entrada y salida, recursos disponibles y nivel de performance. Administracin de recursos: Un recurso como la energa, el ancho de banda o el espacio de almacenamiento puede ser consumido y existe en una cantidad nita. La administracin de recursos debe permitir el monitoreo de atributos como cantidad o tasa de uso, y soportar noticaciones basadas en disparadores predenidos por el usuario. Administracin del contexto: Contexto es cualquier informacin que puede ser usada para caracterizar la situacin de una entidad. Donde una entidad es una persona, lugar u objeto que es relevante para la interaccin entre un usuario y una aplicacin, incluyendo al usuario y la aplicacin. La administracin del contexto debe permitir el monitoreo de atributos como ubicacin actual o tipo de dispositivo, y proveer noticacin de cambios en el mismo. Codicacin: La codicacin involucra la modicacin de los datos y protocolo en funcin de los requerimientos del contexto y recursos disponibles. Ejemplos de codicacin son la encriptacin, compresin y transcodicacin. Una implementacin de la capacidad de codicacin permitir la enumeracin de los encoders y decoders disponibles. Luego con sta informacin disponible junto con la capacidad de administracin del contexto, proveer la habilidad de negociar el uso de uno u otro mtodo de codicacin. Almacenamiento duradero: La capacidad de manejar un almacenamiento duradero permite la persistencia de datos de conguracin o informacin esttica. Seguridad: Para evitar las consecuencias de ataques maliciosos, aplicaciones con diseos pobres, y errores inadvertidos de usuarios, se deben tomar ciertas medidas de seguridad como ser: Sistemas y usuarios deben ser autenticados, autenticacin de sistemas, usuarios y acciones deben ser autorizados, y acciones e interacciones deben ser auditadas.

56

CAPTULO 3. APLICACIONES MVILES

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 mvil, y relacionada especialmente con aspecto de hardware.

3.3

Arquitectura de Portal Para Aplicaciones Mviles

La funcin primaria de un portal es la de agregar e integrar diversas y distribuidas fuentes de informacin, y presentar el resultado al usuario en una vista simple concisa y pertinente a travs de un navegador Web o Web Browser. Un portal es tpicamente dirigido a un grupo especco o tipo de usuario. Por ejemplo en la Intranet de una compaa, el sector de atencin al cliente puede acceder a informacin relacionada con clientes (promociones vigentes, descuentos, etc.), pero no puede acceder a informacin nanciera, sta estara slo autorizada para los integrantes del sector de nanzas. [14] Los contenidos que puede tener un portal son: Datos relativamente estticos, como banners, grcos y estructura general. Contenido dinmico, informacin que cambia con cierta frecuencia, el caso de las promociones vigentes para el sector de atencin al cliente estara dentro de este grupo. Informacin nueva o trascendente, como noticaciones o informacin incremental. Por ejemplo una noticacin 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 Informacin: Las fuentes de informacin proveen de datos al portal. Las fuentes de informacin incluyen bases de datos, aplicaciones u otros portales externos al sistema. Funciones del Portal: Las funciones de un portal son bsicamente las de agregar y componer la informacin para luego ser entrada al usuario.

3.3. ARQUITECTURA DE PORTAL MVIL

57

Funciones Independientes: Son tecnologas 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 travs de Internet, un protocolo Proxy soporta la comunicacin con el usuario y con el portal HTTP y HTML comnmente mejorado del lado del cliente con el uso de lenguajes de scripting y/o cdigo ubicado en el browser como ActiveX o controles Java. Servidor de Presentacin: Crea e integra vistas de contenido a travs de la interaccin con otros componentes. Servidor de Aplicacin: Ejecuta cualquier cdigo que sea requerido dinmicamente para extraer y reformatear informacin desde sistemas no basados en Web. Administracin de Contenido, bsqueda e indexacin, y colaboracin. Servicios de Personalizacin: Disponible para que cada usuario pueda congurar la vista y el contenido que quiere tener cada vez que accede al portal. Seguridad: Un requerimiento para toda arquitectura de aplicaciones mviles, es el de asegurar la integridad de informacin sensible en sitios remotos. Un portal Web es completamente dependiente de la conexin de red, ya que es una arquitectura centrada en el servidor y la conexin de red se hace un recurso imprescindible. Una solucin simple para aplicaciones mviles es la de permitir el acceso oine a sitios Web, bases de datos y archivos que han sido previamente descargados en el mvil. El usuario interacta con los mismos y una vez que la conexin se restablece, las copias locales y remotas se sincronizan. Esta solucin es vlida para aquellos portales simples, pero cuando las fuentes de datos vienen asociadas con otros sistemas o directamente no caben en el dispositivo mvil , no podr ser aplicada. Entonces, sin conexin de red, la creacin de contenido dinmico desde un portal y sus sistemas back-end en tiempo de ejecucin es esencialmente

58

CAPTULO 3. APLICACIONES MVILES

imposible. Sin embargo existen algunas aproximaciones que pueden ser usadas para proveer una vista oine del contenido: Prealmacenado del contenido generado en el portal. Replicacin en el sistema mvil de los datos y el cdigo 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 interaccin del usuario con los datos, y la frecuencia necesaria de actualizacin de los mismos. A continuacin se presentar de que forma una arquitectura de portal mvil puede cubrir los requerimientos planteados para caracterizar una aplicacin mvil: Clientes que soporten multiplataformas: Los portales usualmente soportan el acceso desde diferentes plataformas, manejan diferentes caracterizaciones de dispositivos, y cualquier transcodicacin de contenido requerido. Como el contenido comnmente es dinmico y el tipo de dispositivo del cliente impredecible, estas actividades ocurren en tiempo de ejecucin. Una aplicacin cliente que soporte movilidad no necesita soportar transcodicacin dinmica porque el tipo de dispositivo del cliente es esttico. La aplicacin no necesita manejar cambios dinmicos en la personalizacin del dispositivo oine, ya que se supone que el mismo ser usado por una nica persona. Capacidad de trabajar oine: Prealmacenado de Contenido: involucra el prealmacenado del contenido provisto por un portal en respuesta a un requerimiento hecho por un cliente a travs de una URL, como una pgina Web. El cdigo que genera el contenido no es prealmacenado. Por ejemplo un link (enlace) puede ser referencia a un script JSP o ASP, el Server de aplicacin corre este script y devuelve al cliente streams HTML. Estos HTML son los que estn prealmacenados, no los scripts. Navegar por el portal, siguiendo cada link y almacenar la salida en el sistema local para luego disponer del mismo oine, es un mecanismo completamente ineciente. Adems todas la pginas 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 conguracin local que especique las pginas de inters o provea un criterio de seleccin. Replicacin de Cdigo: permite que el contenido del portal sea ms dinmico. El portal puede ejecutar cdigo, por ejemplo JAVA, en el proceso de servir el contenido al usuario o en la recoleccin y manejo de datos de otros sistemas. El cdigo es replicado desde el servidor al cliente. Alguna replicacin involucra componentes de la interface del usuario, la mayora est involucrado con la coleccin, manipulacin y almacenamiento de datos. Replicacin 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 implementacin se vuelve ms simple, sin embargo la implementacin que permite esquemas de mltiples copias que pueden ser actualizadas independientemente, se vuelve ms compleja. Conectividad Continua: Dos reas estn incluidas dentro de conectividad continua, estas son administracin de conectividad de red y la seguridad desde el punto de vista del usuario. Por ejemplo el usuario no tendr fsicamente que re-autenticarse cada vez que el sistema se reconecta. La conectividad continua puede ser soportada por emulacin, la cual provee la apariencia de que el recurso de red se encuentra disponible. Una posible arquitectura de portal para aplicaciones mviles es la mostrada en la gura 3.1 de la pgina 60, la cual reeja varios tipos de modicaciones: agregado de nuevos componentes (a los habituales de un portal no mvil).

3.4

Arquitectura de Bases de Datos Para Aplicaciones Mviles

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 fsicamente a la red. Los datos se presentan en la mquina 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 conexin a la red. Todo procesamiento tiene lugar en el servidor, construido especcamente para tal propsito.

60

CAPTULO 3. APLICACIONES MVILES

Figura 3.1: Arquitectura Portal Mvil

3.4. ARQUITECTURA DE BASES DE DATOS

61

Se puede armar que una base de datos es un archivo que contiene varios registros de datos. En un ambiente cliente / servidor tradicional, ms de un usuario puede utilizar la misma base de datos simultneamente. RDBMS (Sistemas Manejadores de Bases de Datos Relacionales) hace esto posible a travs del uso de mecanismos internos de locking que previenen que ms de un usuario modique un registro al mismo tiempo. [14] Una arquitectura de base de datos preparada para un ambiente mvil, permite a los usuarios acceder a la informacin en cualquier momento y desde cualquier lugar. En un ambiente mvil, copias de los datos pueden existir en distintos sistemas clientes. Dado que estos sistemas clientes no estn continuamente conectados a la base de datos central, el RDBMS de dicha base no es capaz de prevenir cambios simultneos a los datos por ms de un usuario. Por otra parte, los datos locales en cada sistema cliente deben ser peridicamente sincronizados con los datos de la base master que reside en el servidor. Algunos de los desafos al disear 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 estarn disponibles mientras el sistema este desconectado, esto introducir ms dudas sobre la validez de los datos. La resolucin de conictos se volvern ms desaantes y ya no estarn bajo el control del RDBMS. El poder de procesamiento local en los clientes puede ser limitado en comparacin al poder de procesamiento disponible en el servidor. Los datos propietarios, deben mantenerse seguros en las ubicaciones remotas. Un usuario mvil 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 replicacin 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

CAPTULO 3. APLICACIONES MVILES

La aplicacin 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 oine 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 decisin resultante pueda ser actualizada cuando los datos vuelvan a estar disponibles online nuevamente. Una arquitectura de base de datos para aplicaciones mviles debe garantizar que las transacciones sern trasmitidas conablemente. Durante una transaccin normal, una conexin 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 noticacin sobre si la transferencia fue realizada con xito o no es enviada al que la inici. La falla o el xito de la transaccin, 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 transaccin ser trasmitida al servidor inmediatamente. Si la conexin se pierde durante la transmisin, la transaccin ser encolada para ser transmitida cuando la conexin sea restablecida. Mientras tanto el usuario debe poder ser capaz de hacer referencia a la actualizacin aunque la transmisin no se haya completado.

3.5

Aplicaciones Multiplataforma

Multiplataforma es un trmino usado para referirse a los programas, sistemas operativos, lenguajes de programacin, u otra clase de software, que puedan funcionar en diversas plataformas. Por ejemplo, una aplicacin multiplataforma podra ejecutarse en Windows en un procesador x86, en GNU/Linux en un procesador x86, y en Mac OS X en un x86, sin ningn tipo de problemas. Una plataforma es una combinacin de hardware y software usada para ejecutar aplicaciones, en su forma ms simple consiste nicamente de un sistema operativo, una arquitectura, o una combinacin de ambos. La plataforma ms 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 caractersticas de una plataforma particular; bien sea el hardware, sistema operativo, o mquina virtual en que se ejecuta. La plataforma Java es una mquina virtual multiplataforma, tal vez la ms 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 aos ha sido conseguir programas portables, capaces de ser ejecutados en diversas plataformas (Macintosh PC, Unix, Windows), logrando la compatibilidad total. La aparicin del lenguaje Java da la primera solucin satisfactoria al problema de la compatibilidad. La idea consiste en crear mquinas virtuales idnticas en cada una de las diferentes plataformas y encargarles a ellas la ejecucin de programas, obteniendo as la compatibilidad total. Con el desarrollo de estas mquinas virtuales anteriormente mencionadas se puede lograr que el mismo cdigo binario ejecutable se pueda usar en todos los sistemas compatibles con el software Java. Adems la penetracin de Java en Internet, como lenguaje de acompaamiento al HTML, ha sido todo un xito.

Captulo 4

Java
4.1 Introduccin al Lenguaje

Java es un lenguaje orientado a objetos. Esto signica que posee ciertas caractersticas estndares en los lenguajes OO: Objetos. Clases. Mtodos. Subclases. Herencia simple. Enlace dinmico. 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 pareca que era el lenguaje de programacin perfecto, combinando los mejores elementos de los lenguajes de bajo y alto nivel en un lenguaje de programacin que se ajustaba a la arquitectura del ordenador y que gustaba a los programadores. 65

66

CAPTULO 4. JAVA

Sin embargo, el lenguaje C tena limitaciones, al igual que los lenguajes de programacin anteriores. Cuando los programas crecan, los programas C se hacan inmanejables porque no haba una forma fcil de acortarlo. Esto quiere decir que el cdigo de la primera lnea de un programa largo podra interferir con el cdigo de la ltima lnea y el programador tendra que recordar todo el cdigo mientras programaba. La programacin orientada a objetos se hizo popular por ser capaz de dividir programas largos en unidades semi-autnomas. El lema de la programacin orientada a objetos es divide y vencers. Dicho en otras palabras, un programa se puede dividir en partes fcilmente identicables. Por ejemplo, se supone que para mantener fresca la comida se utiliza un sistema complejo. Debera comprobar la temperatura de la comida usando un termmetro y cuando la temperatura fuera lo sucientemente alta, se activara un interruptor que arrancara el compresor e hiciera funcionar las vlvulas para que el fro circulara; luego arrancara 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 automticas, 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 frigorco. De esta forma es como funcionan los objetos, ocultan los detalles de la programacin al resto del programa, reduciendo todas las interdependencias que aparecen en un programa C e inicializando una interfaz bien denida y controlable que mantiene la conexin entre el objeto y el resto del cdigo. Resumiendo se puede decir que la programacin orientada a objetos consiste en la divisin de un problema en diferentes partes (objetos) donde: Cada objeto posee una funcionalidad especca. Los objetos interactan entre s enviando y recibiendo mensajes; ver gura 4.1 de la pgina 67. La tarea del programador es coordinar las acciones de los objetos y la comunicacin entre los mismos.

4.1. INTRODUCCIN AL LENGUAJE

67

Figura 4.1: Mecanismo de Mensajes Para programar bajo el paradigma orientado a objetos es necesario primero disear un conjunto de clases. La claridad, eciencia y mantenibilidad del programa resultante depender principalmente de la calidad del diseo de clases. Un buen diseo de clases signicar una gran economa en tiempo de desarrollo y mantencin. Lamentablemente se necesita mucha habilidad y experiencia para lograr diseos de clases de calidad. Un mal diseo de clases puede llevar a programas OO de peor calidad y de ms 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 aplicacin [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 ms fcil de usar que una biblioteca de procedimientos, incluso para programadores sin experiencia en orientacin a objetos. Esto se debe a que las clases ofrecen mecanismos de abstraccin ms ecaces que los procedimientos.

4.1.1

Bibliotecas de Clases Estndares de Java

Toda implementacin de Java debe tener las siguientes bibliotecas de clases: Manejo de archivos. Comunicacin de datos. Acceso a la red Internet..

68

CAPTULO 4. JAVA

Acceso a bases de datos. Interfaces grcas. La interfaz de programacin de estas clases es estndar, 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 estn presentes las mismas bibliotecas estndares. A nivel del cdigo compilado: el cdigo intermedio que genera el compilador es el mismo para todas las plataformas. Lo que cambia es el intrprete del cdigo intermedio, la MVJ (Mquina Virtual Java). Mquina Virtual Java Es un programa (software) que maneja la interaccin entre las aplicaciones Java y el Sistema operativo y hardware subyacentes. Este programa interpreta los bytecodes generados por el compilador de Java durante la ejecucin de un programa Java. El proceso de compilacin y ejecucin se pueden observar en la gura 4.2 de la pgina 69.

4.1. INTRODUCCIN AL LENGUAJE

69

Figura 4.2: Proceso Compilacin y Ejecucin

4.1.3

Caractersticas 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 compilacin (al igual que C). En una asignacin entre punteros el compilador verica que los tipos sean compatibles. Java realiza chequeo de tipos durante la ejecucin (C y C++ no lo hacen). Cuando un programa usa un cast para acceder a un objeto como si fuese de un tipo especco, se verica durante la ejecucin que el objeto en cuestin sea compatible con el cast que se le aplica. Si el objeto no es compatible, entonces se lanza una excepcin informando al programador la lnea en donde est el error. Java posee un recolector de basuras que administra automticamente la memoria. La MVJ lo ejecuta para limpiar o reasignar memoria, se lo denomina Garbage Collector. Flexibilidad Java combina exibilidad, robustez y legibilidad gracias a una mezcla de chequeo de tipos durante la compilacin y durante la ejecucin. En Java se pueden tener punteros a objetos de un tipo especco y tambin se pueden

70

CAPTULO 4. JAVA

tener punteros a objetos de cualquier tipo. Estos punteros se pueden convertir a punteros de un tipo especco aplicando un cast. El programador usa entonces punteros de tipo especco en la mayora de los casos con el n de ganar legibilidad y en unos pocos casos usa punteros a tipos desconocidos cuando necesita tener exibilidad. Administracin Automtica 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. Adems 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 lneas. Sin embargo, es difcil hacerlo en un programa de 10000 lneas. Y se puede postular que es imposible liberar correctamente la memoria en un programa de 100000 lneas.

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 BSICOS

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(Simulacin de Redes); menus.setVisible(true); } }

Aparece una clase que contiene el programa principal Simu (aquel que contiene la funcin main()) y algunas clases de usuario (las especcas de la aplicacin que se est desarrollando) que son utilizadas por el programa principal. La aplicacin se ejecuta por medio del nombre de la clase que contiene la funcin main(). Las clases de Java se agrupan en packages, que son libreras de clases. Si las clases no se denen como pertenecientes a un package, se utiliza un package por defecto (default) que es el directorio activo.

4.3
4.3.1

Conceptos Bsicos
Clases

Una clase es una plantilla desde la que se pueden crear objetos. La denicin de una clase incluye especicaciones formales para la clase y cualquier dato y mtodos incluidos en ella. La programacin orientada a objetos se basa en la programacin de clases [17]. Un programa se construye a partir de un conjunto de clases. Una vez denida e implementada una clase, es posible declarar elementos de esta clase. Los elementos declarados de una clase se denominan objetos de

72

CAPTULO 4. JAVA

la clase. De una nica clase se pueden declarar o crear numerosos objetos. La clase es lo genrico: es el patrn o modelo para crear objetos. Cada objeto tiene sus propias copias de las variables miembro, con sus propios valores, en general distintos de los dems 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 programacin orientada a objetos que se ha denido formalmente. Utilizando la herencia, se puede crear una nueva clase a partir de otra, y la nueva heredar todos los mtodos y miembros de datos de la primera. La clase nueva se llama subclase y la clase original, clase base o superclase. La idea es aadir lo que se quiera a la nueva clase para darle ms funcionalidad que a la clase base. La herencia es un tema importante en Java, ya que se puede usar la gran librera de clases disponible, derivando de ellas nuestras clases propias. En Java, a diferencia de otros lenguajes orientados a objetos, una clase slo puede derivar de una nica clase, con lo cual no es posible realizar herencia mltiple en base a clases. Sin embargo es posible simular la herencia mltiple en base a las interfaces.

4.3.3

Interfaces

Una interfaz es una clase abstracta que dene mtodos abstractos y constantes, pero no implementa los mtodos. La clase que implemeta una interfaz

4.4. VARIABLES DE JAVA

73

hereda los mtodos y debe implementarlos, es decir se forma un contrato entre la Interfaz y la clase que implementa la Interfaz. Una clase puede implementar ms de una interface y una interface puede ser implementada por clases que no se encuentran relacionadas.

4.3.4

Package

Un package es una agrupacin de clases. Existen una serie de packages incluidos en el lenguaje. Adems 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 nalidades: 1. Para agrupar clases relacionadas. 2. Para evitar conictos de nombres. En caso de conicto de nombres entre clases importadas, el compilador obliga a cualicar en el cdigo 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 Diseo 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 identicador que representa una palabra de memoria que contiene informacin. El tipo de informacin almacenado en una variable slo puede ser del tipo con que se declar esa variable. Los diferentes

74

CAPTULO 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: Estn denidas 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 informacin ms compleja: arrays u objetos de una determinada clase. Una referencia a un objeto es la direccin de un rea en memoria destinada a representar ese objeto. El rea de memoria se solicita con el operador new. Una variable de referencia tambin puede ser descripta como una referencia a una clase. Por ejemplo si se dene: 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 denen en una clase, fuera de cualquier mtodo; pueden ser tipos primitivos o referencias. Son tambin llamadas atributos. Variables locales: Se denen dentro de un mtodo o ms en general dentro de cualquier bloque entre llaves {}. Se crean en el interior del bloque y se destruyen al nalizar dicho bloque. Pueden ser tambin tipos primitivos o referencias. En la Tabla 4.1 de la pgina 74 se muestran las grandes categoras de tipos para las variables en Java: Tipos Primitivos int, short, byte, long char, boolean oat, double Referencias a Objetos Strings Arreglos otros objetos

Tabla 4.1: Categoras de Variables.

4.4. VARIABLES DE JAVA

75

En la Tabla 4.2 de la pgina 75 se indica para cada tipo primitivo el nmero de bits que se emplea en su representacin y el rango de valores que se puede almacenar en las variables de estos tipos. Tipo int short byte long boolean char oat 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, mtodos. 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 inicializacin: Integrales (byte, short, int, long): Se inicializan en 0. Flotantes (oat, 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 ejecucin de un aplicacin.

76

CAPTULO 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 sera:
public static String mensaje.

Y un ejemplo de la declaracin de un mtodo de clase:

public static void leerURL().

4.5
4.5.1

Operadores del Lenguaje Java

Operadores Aritmticos

Son operadores binarios (requieren siempre dos operandos) que realizan las operaciones aritmticas habituales: suma (+), resta (-), multiplicacin (*), divisin (/) y resto de la divisin (%).

4.5.2

Operadores de Asignacin

Los operadores de asignacin permiten asignar un valor determinado a una variable. El operador de asignacin por excelencia es el operador igual (=). La forma general de las sentencias de asignacin con este operador es:
variable = expresin;

Java dispone de otros operadores de asignacin. Se trata de versiones abreviadas del operador (=) que realizan operaciones acumulativas sobre una variable. La siguiente Tabla 4.3 de la pg. 77, muestra estos operadores y su equivalencia con el uso del operador igual (=).

4.5. OPERADORES DEL LENGUAJE JAVA

77

Operador += -= =* =/ %=

Utilizacin op1 + = op2 op1 - = op2 op1 * = op2 op1 / = op2 op1% = op2

ExpresinEquivalente op1 = op1 + op2 op1 = op1 - op2 op1 = op1 * op2 op1 = op1 / op2 op1 = op1 % op2

Tabla 4.3: Operadores de asignacin.

4.5.3

Operadores Unarios

Los operadores unarios sirven para mantener o cambiar el signo de una variable, constante o expresin numrica. Ellos son el ms (+) y menos (-). Su uso en Java es el estndar 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 segn 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 evala la expresion booleana y si es true devuelve res1, si es false devuelve res2. Es el nico operador ternario de Java.

78

CAPTULO 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 expresin en la que aparece. Despus de la variable de la forma i++. En este caso primero se utiliza la variable en la expresin (con el valor anterior) y luego se incrementa. En muchos casos estos operadores se utilizan para incrementar una variable fuera de una expresin. En estos casos ambos operadores son equivalentes. Si se utilizan en una expresin ms 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 relacin de menor o mayor. El resultado de estos operadores es siempre un valor boolean (true o false) segn se cumpla o no la relacin considerada. La siguiente Tabla 4.4 de la pg. 78 muestra los operadores relacionales de Java. Operador > >= < <= == ! = Utilizacin 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 PROGRAMACIN

79

4.5.8

Operadores de Concatenacin de Caracteres

El operador ms (+) tambin 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 sera: Mensaje: Datos ingresados correctamente.

4.6

Estructuras de Programacin

Las estructuras de programacin o estructuras de control permiten tomar decisiones y realizar un proceso repetidas veces. Son las denominadas bifurcaciones y bucles. En la mayora de los lenguajes de programacin, este tipo de estructuras son comunes en cuanto a concepto, aunque su sintaxis vara de un lenguaje a otro. La sintaxis de Java coincide prcticamente con la utilizada en C/C++, lo que hace que para un programador de C/C++ no suponga ninguna dicultad adicional.

4.6.1

Sentencias o Expresiones

Una expresin 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 expresin que acaba en punto y coma (;). Se permite incluir varias sentencias en una lnea, aunque lo habitual es utilizar una lnea para cada sentencia. A continuacin se muestra un ejemplo de una lnea compuesta de tres sentencias:
i = 0; j = 5; x = i + j;

donde lo habitual sera:

i = 0;

80

CAPTULO 4. JAVA

j = 5; x = i + j;

4.6.2

Comentarios

Existen dos formas diferentes de introducir comentarios entre el cdigo 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 cdigo utilizado, facilitando de ese modo futuras revisiones y correcciones. Adems permite que cualquier persona distinta al programador original pueda comprender el cdigo escrito de una forma ms rpida. Se recomienda acostumbrarse a comentar el cdigo desarrollado. De esta forma se simplican tambin las tareas de estudio y revisin posteriores. Java interpreta que todo lo que aparece a la derecha de dos barras // en una lnea cualquiera del cdigo es un comentario del programador y no lo tiene en cuenta. El comentario puede empezar al comienzo de la lnea o a continuacin de una instruccin que debe ser ejecutada. La segunda forma de incluir comentarios consiste en escribir el texto entre los smbolos /* */ . Este segundo mtodo es vlido para comentar ms de una lnea de cdigo. Por ejemplo:
// Esta lnea es un comentario de una sola lnea int a=1; // Comentario a la derecha de una sentencia /* Este tipo de comentarios es para comentar ms de una sla lnea, slo requiere modicar el comienzo y el nal. */

En Java existe adems una forma especial de introducir los comentarios (utilizando /***/ ms algunos caracteres especiales) que permite generar automticamente la documentacin 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 automtica la informacin de forma similar a la presentada en la propia documentacin del JDK. La sintaxis de estos comentarios y la forma de utilizar el programa javadoc.exe se puede encontrar en la informacin que viene con el JDK.

4.6. ESTRUCTURAS DE PROGRAMACIN

81

4.6.3

Bifurcaciones

Las bifurcaciones permiten ejecutar una de entre varias acciones en funcin del valor de una expresin lgica o relacional. Se tratan de estructuras muy importantes ya que son las encargadas de controlar el ujo de ejecucin de un programa. Se exponen dos variantes del de tipo if. Bifurcacin if Esta estructura permite ejecutar un conjunto de sentencias en funcin del valor que tenga la expresin de comparacin. Ejemplo: se ejecuta si la expresin de comparacin (error < errorMinimo) tiene valor true:
numero = 58; if (math.abs(numero) < 10){ System.out.println(Nmero de 1 solo dgito); } /* n del if */

Las llaves {} sirven para agrupar en un bloque las sentencias que se han de ejecutar, y no son necesarias si slo hay una sentencia dentro del if. Bifurcacin if else Anloga a la anterior, de la cual es una ampliacin. Las sentencias incluidas en el else se ejecutan en el caso de no cumplirse la expresin de comparacin (false), Ejemplo:
numero = 58; if (Math.abs(numero) < 10){ System.out.println(Nmero de 1 solo dgito); }else{ System.out.println(Nmero de 2 dgitos); }// n del else

82

CAPTULO 4. JAVA

4.6.4

Bucles

Un bucle se utiliza para realizar un proceso repetidas veces. Se denomina tambin lazo o loop. El cdigo incluido entre las llaves {} (opcionales si el proceso repetitivo consta de una sola lnea), se ejecutar mientras se cumplan unas determinadas condiciones. Hay que prestar especial atencin a los bucles innitos, hecho que ocurre cuando la condicin de nalizar el bucle (booleanExpression) no se llega a cumplir nunca. Se trata de un fallo muy tpico, habitual sobre todo entre programadores poco experimentados. Bucle while En el siguiente ejemplo se muestra que se ejecutar la sentencia n++ mientras la expresin (capas.charAt(n)!=, && capas.charAt(n)!=-1) sea verdadera.
for (int j=0; j < numeroCapas; j++){ int n = principio; try { while (capas.charAt(n) != , && capas.charAt(n) != -1){ n++; } } }

Bucle for A continuacin se podr apreciar la utilizacin del bucle for:

/* calcular el nuevo vector de diseo */ for (int i = 0; i < vectorDis.length; i++){ vectorDis[i] = vectorDis[i] + learningRate * S[i]; }

4.6. ESTRUCTURAS DE PROGRAMACIN

83

La sentencia int i = 0 (inicializacin) se ejecuta al comienzo del for, e i++ (incremento) despus de vectorDis[i] = vectorDis[i] + learningRate * S[i] (sentencia). La expresin booleana (vectorDis.length) se evala al comienzo de cada iteracin; el bucle termina cuando la expresin de comparacin toma el valor false. Bucle do while Es similar al bucle while pero con la particularidad de que el control est al nal del bucle (lo que hace que el bucle se ejecute al menos una vez, independientemente de que la condicin se cumpla o no). Una vez ejecutadas las sentencias, se evala la condicin: si resulta true se vuelven a ejecutar las sentencias incluidas en el bucle, mientras que si la condicin se evala a false naliza el bucle.

do{ /* calcular el gradiente del vector jar el vector de diseo */ problema.joVector(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 nmero de iteraciones pasado como argumento */ problema.joVector(vectorDis);

Bloque try{...} catch{...} nally{...} Java incorpora en el propio lenguaje la gestin de errores. El mejor momento para detectar los errores es durante la compilacin. Sin embargo prcticamente slo los errores de sintaxis son detectados en esta operacin. El resto de los problemas surgen durante la ejecucin de los programas.

84

CAPTULO 4. JAVA

En el lenguaje Java, una Exception es un cierto tipo de error o una condicin anormal que se ha producido durante la ejecucin de un programa. Algunas excepciones son fatales y provocan que se deba nalizar la ejecucin 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 chero 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 chero 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 nally. El cdigo dentro del bloque try est vigilado: Si se produce una situacin anormal y se lanza como consecuencia una excepcin, el control pasa al bloque catch que se hace cargo de la situacin 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 excepcin. Finalmente, si est presente, se ejecuta el bloque nally, 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 cdigo de un mtodo pueda generar una Exception y no se desee incluir en dicho mtodo la gestin del error (es decir los bucles try/catch correspondientes), es necesario que el mtodo pase la Exception al mtodo desde el que ha sido llamado. Esto se consigue mediante la adicin de la palabra throws seguida del nombre de la Exception concreta, despus de la lista de argumentos del mtodo. A su vez el mtodo superior deber incluir los bloques try/catch o volver a pasar la Exception. De esta forma se puede ir pasando la Exception de un mtodo a otro hasta llegar al ltimo mtodo del programa, el mtodo main().

4.7

Servlets

Los servlets son programas de Java que construyen respuestas dinmicas para el cliente, tal como pginas Web. Los servlets reciben y responden a las demandas de los clientes Web, normalmente por HTTP.

4.7. SERVLETS

85

Adems los servlets son escalables, dando soporte para una multi-aplicacin de conguracin del servidor. [18] Permiten utilizar datos cach, acceso a informacin 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 codicacin con respecto a soluciones dependientes del servidor web y de la plataforma. Ejecucin en paralelo de mltiples peticiones por una sola instancia del servlet.Tradicionalmente en los programas CGI se ejecuta un proceso distinto para cada peticin, lo que conlleva una gradual degradacin 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 bsicamente en dos paquetes: javax.servlet javax.servlet.http Todas las clases e interfaces que hay que utilizar en la programacin de servlets estn en estos dos paquetes. Vision General del API de Servlet La relacin entre las clases e interfaces de Java, muy determinada por el concepto de herencia, tal como puede verse en la gura 4.3 de la pgina 86, se representan con letra normal las clases y las interfaces con cursiva.

86

CAPTULO 4. JAVA

Figura 4.3: Jerarqua y Mtodos de las Principales Clases Para Crear Servlets.

La clase GenericServlet es una clase abstracta puesto que su mtodo service() es abstracto. Esta implementa dos interfaces, de las cuales la ms importante es la interface Servlet. La interface Servlet declara mtodos ms importantes de cara a la vida de un servlet: init() que se ejecuta slo 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 denir el mtodo service(). Este mtodo tiene en su denicin 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 enva al servlet. Si la solicitud de servicio viene de un formulairo HTML, a travs 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 mtodo 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 implementacin o denicin del mtodo service(). Dicha implementacin detecta el tipo de servicio o mtodo HTTP que le ha sido solicitado desde el browser y llama al mtodo adecuado de esa misma clase (doPost(), doGet(), etc.), tambin aparecen otras interfaces como ser:

4.7. SERVLETS

87

La interfaz ServletCong dene mtodos que permiten pasar al servlet informacin sobre sus parametros de inicializacin. La interface ServletContext permite a los servlets acceder a informacin sobre el entorno en que se estan ejecutando. Principios de Codicacin de Servlet Para crear un servlet de HTTP, es necesario extender las clases: javax.servlet.HttpServlet y sustituir cualquier mtodo que se desee implementar en el servlet. Por ejemplo, un servlet reemplaza el mtodo 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 informacin 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 podra 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

CAPTULO 4. JAVA

fuera de servicio. Las clases javax.servlet.http.HttpServlet denen mtodos tales como: Iniciar un servlet. Solicitar servicios. Quitar un servlet del servidor. stos son conocidos como mtodos del ciclo de vida y son llamados en la siguiente secuencia: Se construye el servlet. Se inicializa con el mtodo init(). Se manejan llamadas de los clientes al mtodo de servicio. Se saca el servlet de servicio. Se destruye con el mtodo destruir. Se naliza el servlet y la basura es recolectada. El ciclo de vida de un Servlet se puede apreciar en la gura 4.4 de la pgina 89.

4.7.2

Instanciacin e Inicializacin

El motor del servlet (la funcin del Servidor de Aplicaciones que procesa servlets, archivos JSP, y otros tipos de server-side incluyendo codicacin) crea una instancia del servlet. El motor del servlet crea el objeto de conguracin del servlet y lo usa para pasar los parmetros de inicializacin del servlet al mtodo init(). La inicializacin de los parmetros persiste hasta que el servlet se destruye y es aplicada a todas las invocaciones de ese servlet hasta destruirse. Si la inicializacin tiene xito, el servlet est disponible para el servicio. Si la inicializacin falla, el motor del servlet descarga el servlet. El administrador

4.7. SERVLETS

89

Figura 4.4: Ciclo de Vida de un Servlet.

90

CAPTULO 4. JAVA

puede inhabilitar una aplicacin y el servlet para el servicio. En tales casos, la aplicacin 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 mtodo de servicio del servlet, procesa el requerimiento y usa mtodos del objeto respuesta para crear la respuesta para el cliente. El mtodo de servicio recibe informacin sobre el requerimiento del objeto demanda, procesa el requerimiento, y usa los mtodos del objeto respuesta para crear la contestacin para el cliente. El mtodo de servicio puede invocar otros mtodos para procesar el requerimiento, tales como doGet (), doPost (), o mtodos del usuario.

4.7.4

Terminacin

El motor del servlet invoca al mtodo destroy () del servlet cuando apropia y descarga el servlet. La Mquina Virtual de Java realiza la recoleccin de basura despus de la destruccin del servlet. Cuando el contenedor Web ya no necesita que el servlet o una nueva instancia del servlet se recarguen, invoca al mtodo destroy() del servlet. El contenedor Web tambin puede llamar al mtodo destroy() si el motor necesita conservar recursos o una llamada pendiente a un mtodo service() del servlet excediendo el timeout. La Mquina Virtual de Java realiza recoleccin de basura despus del destroy.

4.7.5

Java Server Faces

Java Server Pages (JSP) combinan HTML con fragmentos de Java para producir pginas web dinmicas. Cada pgina es automticamente compilada a servlet por el motor de JSP , en primer lugar es recogida y a continuacin 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 pgina JSP es un archivo de texto simple que consiste en contenido HTML o XML con elementos JSP. Cuando un cliente pide una pgina JSP del sitio web y no se ha ejecutado antes, la pgina es inicialmente pasada al motor de JSP, el cual compila la pgina convirtindola en Servlet, la ejecuta y devuelve el contenido de los resultados al cliente. El cdigo fuente de una pgina JSP incluye: Directivas: Dan informacin global de la pgina, por ejemplo, importacin de estamentos, pgina que majena los errores o cuando la pgina forma parte de una sesin. Declaraciones: Sirven para declarar mtodos y variables. Scripts de JSP: Es el cdigo Java embebido en la pgina. Expresiones de JSP: Formatea las expresiones como cadenas para incluirlas en la pgina de salida. Directivas Una directiva de JSP es un estamento que proporciona la informacin del motor de JSP para la pgina que la pide. Su sintaxis general es <%@ directiva {atributo =valor} %> dnde la directiva debe tener un nmero de atributos. Algunos ejemplos son: Page: Informacin para la pgina. Include: Incluye archivos completos palabra por palabra. Taglib: La direccin de la librera de tags que se usar en la pgina. 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 especicacin.

92

CAPTULO 4. JAVA

extends=package.class: La variale extends, dene 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 especicar los paquetes y clases que se quieran utilizar. session=true|false: Por defecto session vale true, manteniendo los datos de las sesin para la pgina. isThreadSafe=true|false: Por defecto vale true, le hace seales al motor de JSP para que mltiples pedidos del cliente puedan ser tomados como uno. info=text: Informacin en la pgina a la que puede accederse a travs del mtodo Servlet.getServletInfo(). errorPage=pagina_error: Pgina que manejar las excepciones de errores. Declaraciones Una declaracin de JSP, puede denirse como una denicin de variables y mtodos a nivel de clase que son usadas en la pgina. Un bloque de declaraciones tpico sera <%! declaracin %> Un ejemplo de declaracin de script sera el siguiente:
<HTML> <HEAD> <TITLE>Pgina 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 cdigo Java residentes entre los tags <% y %>. Estos bloques de cdigo estarn dentro del servlet generado includos en el mtodo _jspService(). Los Scripts pueden acceder a cualquier variable o Bean que haya sido declarado. Tambin hay algunos objetos implcitos disponibles para los Scripts desde entorno del Servlet. Algunos de ellos pueden verse a continuacin: request: Es la peticin del cliente. Es normalmente una subclase de la clase HttpServletRequest. response: Es la pgina JSP de respuesta y es una subclase de HttpServletResponse. Los atributos de la pgina y los objetos implcitos necesitan ser accesibles a travs de API, para permitir al motor de JSP compilar la pgina. Pero cada servidor tiene implementaciones especcas 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 pgina (erropage, session, buer and autoush) y facilita los otros objetos implcitos para la pgina de peticin. session: El objeto de sesin HTTP asociado a la peticin. application: Lo que devuelve el servlet cuando se llama a getServletCong().getContext(). page: Es la forma que tiene la pgina para referirse a si misma. Se usa como alternativa al objeto this. El siguiente fragmento de cdigo muestra como obtener el valor de un parmetro mediante el objeto request, y como pasarlo a una cadena para mostrarlo en pantalla.
<% String strNombre = request.getParameter(nombre);

94

CAPTULO 4. JAVA

out.println(strNombre); %>

Expresiones JSP Las expresiones son una magnca herramienta para insertar cdigo embebido dentro de la pgina HTML. Cualquier cosa que est entre los tags <%= y %> ser evaluado, convertido a cadena y posteriormente mostrado en pantalla. La conversin desde el tipo inicial a String es manejada autmaticamente. Es importante remarcar que la expresin no termina en punto y coma (;) . Esto es as porque el motor de JSP, pondr la expresin automticamente entre out.println(). Las expresiones JSP permiten parametrizar las pginas HTML (es parecido a cuando se parametriza una consulta SQL pero dieren la forma de los valores). Una y otra vez , en el cdigo de la pgina HTML, ser vern bucles o condiciones usando cdigo Java, simplemente empezando y acabando las condiciones o bucles entre los tags <% y %>. Un ejemplo sera:
<% 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 enva un requerimiento para los archivos JSP. Los archivos JSP acceden a los beans u otros componentes que generan contenido dinmico para ser enviado al browser como se muestra en la gura 4.5 de la pgina 95. Cuando el servidor Web recibe un requerimiento para un archivo JSP, el servidor enva 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 cdigo fuente de Java que se compila y se ejecuta como un servlet. El requerimiento se enva a un servlet que genera contenido dinmico y llama a un archivo JSP para enviar el contenido a un browser, como se muestra en la gura 4.6 de la pgina 95. Este modelo de acceso facilita la generacin de contenido separado del despliegue de contenido. El servidor de aplicaciones proporciona un juego de mtodos en el objeto HttpServiceRequest object y el objeto HttpServiceResponse. Estos mtodos permiten una invocacin de servlet para colocar un objeto (normalmente un

96

CAPTULO 4. JAVA

bean) en un objeto demanda y pasa ese requerimiento a otra pgina (normalmente un archivo JSP) para el despliegue. La pgina 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 funcin de la lgica comercial. Las aplicaciones Web son grupos de uno o ms servlets, ms el contenido esttico. Aplicaciones Web = servlets + archivos JSP + archivos XML + archivos HTML + grcos. El modelo de programacin 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.

Captulo 5

Java 2 Micro Edition

5.1 Introduccin

Para empezar se puede decir que Java 2 Micro Edition o J2ME es la versin del lenguaje Java que est orientada al desarrollo de aplicaciones para dispositivos pequeos con capacidades restringidas tanto en pantalla grca, como de procesamiento y memoria (telfonos mviles, PDAs, Handhelds, Pagers, etc.). Esta versin de Java fue presentada en 1999 por Sun Microsystems con el propsito de habilitar aplicaciones Java para pequeos dispositivos. En esta presentacin lo que realmente se mostr fue una nueva mquina virtual Java o JVM (Java Virtual Machine) que poda ejecutarse en dispositivos Palm. La tarda aparicin de esta tecnologa puede ser debido a que las necesidades de los usuarios de telefona mvil han cambiado mucho en estos ltimos aos y cada vez demandan ms servicios y prestaciones por parte tanto de los terminales como de las compaas. Adems el uso de esta tecnologa 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 tecnologa del futuro para la industria de los dispositivos mviles. 97

98

CAPTULO 5. JAVA 2 MICRO EDITION

5.1.1

Comparacin 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 caractersticas de cada una de las versiones son: 1. Java 2 Platform, Standard Edition (J2SE): Esta edicin de Java es la que en cierta forma recoge la iniciativa original del lenguaje Java. Tiene las siguientes Caractersticas: Inspirado inicialmente en el lenguaje C++, pero con componentes de alto nivel, como soporte nativo de strings y recolector de basura (garbage colector ). Cdigo 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. Abstraccin del sistema operativo subyacente mediante un juego completo de APIs de programacin. Contiene el conjunto bsico de herramientas usadas para desarrollar Java Applets, as cmo las APIs orientadas a la programacin de aplicaciones de usuario nal: Interfaz grca de usuario, multimedia, redes de comunicacin. 2. Java 2 Platform, Enterprise Edition (J2EE): Esta versin est orientada al entorno empresarial. El software empresarial tiene unas caractersticas propias marcadas:

5.1. INTRODUCCIN

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 edicin est orientada especialmente al desarrollo de servicios web, servicios de nombres, persistencia de objetos, XML, autenticacin, APIs para la gestin de transacciones, etc. El cometido de esta especicacin es ampliar la J2SE para dar soporte a los requisitos de las aplicaciones de empresa. 3. Java 2 Platform, Micro Edition (J2ME): Esta versin de Java est enfocada a la aplicacin de la tecnologa Java en dispositivos electrnicos con capacidades computacionales y grcas muy reducidas, tales como telfonos mviles, PDAs o electrodomsticos inteligentes: Esta edicin tiene unos componentes bsicos que la diferencian de las otras versiones, como el uso de una mquina virtual denominada KVM (Kilo Virtual Machine, debido a que requiere slo unos pocos Kilobytes de memoria para funcionar) en vez del uso de la JVM clsica. La gura 5.1 de la pgina 100 muestra la arquitectura de Java2. En la actualidad se puede decir que Java no es slo un simple lenguaje de programacin sino un conjunto de tecnologas que engloba a todos los aspectos de la computacin con dos elementos en comn: El cdigo fuente en lenguaje Java es compilado a cdigo intermedio interpretado por una Java Virtual Machine (JVM ), por lo que el cdigo ya compilado es independiente de la plataforma. Todas las tecnologas comparten un conjunto ms o menos amplio de APIs bsicas del lenguaje, agrupadas principalmente en los paquetes java.lang y java.io. Debido a que la edicin estndar de APIs de Java ocupa 20 MB aproximadamente y los dispositivos pequeos disponen de una cantidad de memoria mucho ms reducida, J2ME contiene una mnima 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 ja forma parte de lo que se denomina conguracin [19].

100

CAPTULO 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 mquina virtual distinta de la clsica JVM denominada KVM. Esta KVM tiene unas restricciones que hacen que no posea todas las capacidades incluidas en la JVM clsica. J2ME representa una versin simplicada de J2SE. Sun separ estas dos versiones ya que J2ME est pensada para dispositivos con limitaciones de proceso y capacidad grca. Tambin separ J2SE de J2EE porque este ltimo exiga unas caractersticas muy pesadas o especializadas de E/S, trabajo en red, etc. Por tanto, separ ambos productos por razones de eciencia. Hoy, J2EE es un superconjunto de J2SE pues contiene toda la funcionalidad de ste y ms caractersticas, as como J2ME es un subconjunto de J2SE (excepto por el paquete javax.microedition) ya que contiene varias limitaciones con respecto a J2SE. Slo de manera muy simplista se puede considerar a J2ME y J2EE como versiones reducidas y ampliadas de J2SE respectivamente (ver g. 5.2 de la pg. 101): en realidad cada una de las ediciones est enfocada a mbitos de aplicacin muy distintos [19].

5.1. INTRODUCCIN

101

Figura 5.2: Ubicacin de las Tecnologas Java.

5.1.2

Algunas Consideraciones al Desarrollar en J2ME

Algunas consideraciones son las siguientes: Prcticamente los dispositivos mviles y ms an los nuevos telfonos celulares ya poseen capacidad de ejecucin de aplicaciones desarrolladas en J2ME. Existen algunas ventajas y restricciones o desventajas respecto a otras tecnologas [20]. Algunas ventajas en comparacin de J2ME con respecto al lenguaje C son: Multiplataforma: Signica 1 programa - se puede ejecutar en n mviles. Seguridad: El usuario est protegido. Descarga OTA (Over The Air). Desarrollo rpido. Inconveniente: Alejamiento del hardware. No puede accederse a ciertos recursos del telfono si ste no incorpora el API correspondiente.

102

CAPTULO 5. JAVA 2 MICRO EDITION

Las aplicaciones mviles que poseen conectividad a Internet pueden utilizar la tecnologa GPRS, en la cual se tarifa al usuario por Kbytes recibidos y enviados, es por esto que es importante minimizar la cantidad de informacin intercambiada. Las relaciones que existen de acuerdo al tipo de informacin intercambiada y el volumen de la misma son las siguientes: Pgina html - 10-100Kb. Pgina wml 1-10Kb. Informacin pura - 0.1 - 1kb. Cundo interesa desarrollar en J2ME ?: Cuando no hay trco de informacin, por ejemplo: juegos, conversores de unidades. Cuando el trco de informacin puede minimizarse con J2ME . Cuando pueden almacenarse datos localmente en el mvil y slo transferir algunos otros como los resultados [20].

5.2

Componentes de J2ME

Los componentes que forman parte de la tecnologa J2ME son: Mquina virtual: Existe una serie de mquinas virtuales java con diferentes requisitos, cada una para diferentes tipos de pequeos dispositivos. Conguraciones: Son un conjunto de clases bsicas orientadas a conformar el corazn de las implementaciones para dispositivos de caractersticas especcas: Connected Limited Device Conguration (CLDC) enfocada a dispositivos con restricciones de procesamiento y memoria. Connected Device Conguration (CDC) enfocada a dispositivos con ms recursos [20]. Perles: Son unas bibliotecas Java de clases especcas orientadas a implementar funcionalidades de ms alto nivel para familias especcas de dispositivos.

5.2. COMPONENTES DE J2ME

103

5.2.1

Mquinas Virtuales J2ME

Una mquina virtual de Java (JVM ) es un programa encargado de interpretar cdigo intermedio (bytecode) de los programas Java precompilados a cdigo mquina ejecutable por la plataforma, efectuar las llamadas pertinentes al sistema operativo subyacente y observar las reglas de seguridad y correccin de cdigo denidas 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 dene varias JVMs de referencia adecuadas al mbito de los dispositivos electrnicos que, en algunos casos, suprimen algunas caractersticas con el n de obtener una implementacin menos exigente. La tecnologa J2ME ha denido dos conguraciones, CDC y CLDC, cada una de ellas con caractersticas propias, en consecuencia, para cada tipo de conguracin se deni una mquina virtual distinta. La VM (Virtual Machine) correspondiente a CLDC se denomina KVM y la de la conguracin CDC se denomina CVM. A continuacin se detallan las principales caractersticas de cada una de ellas: KVM Se corresponde con la mquina virtual ms pequea. Su nombre KVM proviene de Kilobyte (que hace referencia a la baja ocupacin de memoria). Se trata de una implementacin de mquina virtual reducida y especialmente orientada a dispositivos con bajas capacidades computacionales y de memoria, como ser los telfonos celulares. La KVM est escrita en el lenguaje de programacin C y posee algunas caractersticas particulares como: Pequea, con una carga de memoria entre los 40Kb y los 80 Kb, dependiendo de la plataforma y las opciones de compilacin. Alta portabilidad. Modulable.

104

CAPTULO 5. JAVA 2 MICRO EDITION

Lo ms completa y rpida posible y sin sacricar caractersticas para las que fue diseada. Sin embargo, existen algunas limitaciones debido a su bajo consumo de memoria respecto la maquina virtual clsica: No hay soporte para tipos en coma otante. Esta limitacin 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) denidos por el usuario. No se permiten los grupos de hilos o hilos daemon. Si se necesita la utilizacin de grupos de hilos se tendrn que utilizar los objetos coleccin para almacenar cada hilo. No existe la nalizacin de instancias de clases. No existe el mtodo Object.nalize(). 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 mayora de las excepciones. Otro tema en cuestin que se puede encontrar en sta maquina virtual ms pequea es la vericacin de clases. El vericador de clases estndar de Java es demasiado grande para la KVM, de hecho es ms grande que la propia KVM y el consumo de memoria es excesivo, ms de 100Kb para las aplicaciones tpicas. Este vericador de clases es el encargado de rechazar las clases no vlidas en tiempo de ejecucin. Este mecanismo verica los bytecodes de las clases Java realizando las siguientes comprobaciones: Ver que el cdigo no sobrepase los lmites 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 Vericacin. Comprobar que se respetan los campos, mtodos y los modicadores de control de acceso a clases. Por esta razn los dispositivos que usen la conguracin CLDC y KVM introducen un algoritmo de vericacin de clases en dos pasos. Este proceso puede apreciarse grcamente en la gura 5.3 de la pgina 105. CVM La CVM (Compact Virtual Machine) ha sido tomada como mquina virtual Java de referencia para la conguracin CDC y soporta las mismas caractersticas que la mquina virtual clsica. Est orientada a dispositivos electrnicos con procesadores de 32 bits de gama alta y en torno a 2 Mb o ms de memoria RAM. Las caractersticas que presenta sta mquina virtual son: 1. Sistema de memoria avanzado. 2. Tiempo de espera bajo para el recolector de basura. 3. Separacin completa de la VM del sistema de memoria.

106

CAPTULO 5. JAVA 2 MICRO EDITION

4. Recolector de basura modularizado. 5. Portabilidad. 6. Rpida sincronizacin. 7. Ejecucin de las clases Java fuera de la memoria de slo lectura (ROM). 8. Soporte nativo de hilos. 9. Baja ocupacin en memoria de las clases. 10. Proporciona soporte e interfaces para servicios en sistemas operativos de tiempo real. 11. Conversin de hilos Java a hilos nativos. 12. Soporte para todas las caractersticas de Java2 v1.3 y libreras de seguridad, referencias dbiles, Interfaz Nativa de Java (JNI ), invocacin remota de mtodos (RMI ), Interfaz de depuracin de la mquina virtual (JVMDI).

5.2.2

Conguraciones

Una conguracin es el conjunto mnimo de APIs Java que permiten desarrollar aplicaciones para un grupo de dispositivos. Estas APIs describen las caractersticas bsicas, comunes a todos los dispositivos: Caractersticas soportadas del lenguaje de programacin Java. Caractersticas soportadas por la mquina virtual Java. Bibliotecas bsicas de Java y APIs soportadas. Como se ha mencionado con anterioridad, existen dos conguraciones, la que est orientada a dispositivos con limitaciones computacionales y de memoria que se denomina CLDC y la conguracin que se encuentra orientada a dispositivos con menos restricciones en cuanto a capacidad de cmputo y memoria, la cual se denomina CDC . A continuacin se presentan las caractersticas ms relevantes de cada una:

5.2. COMPONENTES DE J2ME

107

Conguracin de dispositivos con conexin, CDC (Conected Device Conguration): La CDC est orientada a dispositivos con cierta capacidad computacional y de memoria. Por ejemplo, decodicadores de televisin digital, televisores con Internet, algunos electrodomsticos y sistemas de navegacin en automviles. CDC usa una mquina virtual Java similar en sus caractersticas a una de J2SE, pero con limitaciones en el apartado grco y de memoria del dispositivo. La CDC est enfocada a dispositivos con las siguientes capacidades: Procesador de 32 bits. 2 Mb o ms de memoria total, incluyendo memoria RAM y ROM. Conectividad a algn tipo de red. Poseer la funcionalidad completa de la Mquina Virtual Java 2. La CDC est basada en J2SE v1.3 e incluye varios paquetes Java de la edicin estndar. Las peculiaridades de la CDC estn 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 pg. 108 muestra las libreras incluidas en la CDC. Conguracion de dispositivos limitados con conexin, CLDC (Conected Limited Device Conguration): La CLDC est orientada a dispositivos dotados de conexin y con limitaciones en cuanto a capacidad grca, cmputo y memoria. Como por ejemplo telfonos mviles, buscapersonas (Pagers), PDAs, organizadores personales, etc. Las restricciones que contiene la conguracin CLDC vienen dadas por la utilizacin de la mquina virtual o KVM. Los dispositivos que usan CLDC deben cumplir los siguientes requisitos:

108

CAPTULO 5. JAVA 2 MICRO EDITION

Nombre del paquete CDC java.io java.lang java.lang.ref java.lang.reect java.math java.net java.security java.security.cert java.text java.util java.util.jar java.util.zip javax.microedition.io

Descripcin Clases y paquetes estndar de E/S Clases e interfaces de la mquina virtual Clases de referencia Clases e interfaces de reectin Paquete de matemticas Clases e interfaces de red Clases e interfaces de seguridad Clases de certicados de seguridad Paquete de texto Clases de utilidades estndar Clases y utilidades para archivos JAR Clases y utilidades para archivos ZIP y comprimidos Clases e interfaces para conexin genrica CDC

Tabla 5.1: Libreras de conguracin CDC. Disponer entre 160 Kb y 512 Kb de memoria total disponible. Como mnimo se debe disponer de 128 Kb de memoria no voltil para la mquina virtual Java y las bibliotecas CLDC, y 32 Kb de memoria voltil para la mquina virtual en tiempo de ejecucin. Procesador de 16 o 32 bits con al menos 25 Mhz de velocidad. Tener conexin a algn tipo de red, normalmente sin cable, con conexin intermitente y ancho de banda limitado. Ofrecer bajo consumo, debido a que stos dispositivos trabajan con suministro de energa limitado, normalmente bateras recargables. La CLDC aporta las siguientes funcionalidades a los dispositivos: Un subconjunto del lenguaje Java y todas las restricciones de su mquina virtual (KVM ). Un subconjunto de las bibliotecas del ncleo de Java. Soporte para acceso a redes. Soporte para E/S bsica.

5.2. COMPONENTES DE J2ME

109

Seguridad. La tabla 5.2 de la pg. 109 muestra las libreras incluidas en la CLDC. Nombre del paquete CLDC java.io java.lang java.util javax.microedition.io Descripcin Clases y paquetes estndar de E/S Clases e interfaces de la mquina virtual Clases e interfaces, utilidades estndar Clases e interfaces de conexin genrica

Tabla 5.2: Libreras de conguracin CLDC.

5.2.3

Perles

Un perl es el que dene las APIs que controlan el ciclo de vida de la aplicacin, interfaz de usuario, etc. Concretamente, un perl es un conjunto de APIs orientado a un mbito de aplicacin determinado. Los perles identican un grupo de dispositivos por la funcionalidad que proporcionan (ya sean electrodomsticos, telfonos mviles, etc.) y el tipo de aplicaciones que se ejecutarn en ellos. Las libreras de la interfaz grca son un componente muy importante en la denicin de un perl. Se pueden encontrar grandes diferencias entre las interfaces, desde el men textual de los telfonos mviles hasta los tctiles de los PDAs. El perl establece unas APIs que denen las caractersticas de un dispositivo, mientras que la conguracin hace lo propio con una familia de ellos. Esto hace que a la hora de construir una aplicacin se cuente tanto con las APIs del perl como de la conguracin. Anteriormente se mencion que para una conguracin determinada se usaba una Mquina Virtual Java especca. Tenamos que con la conguracin CDC se utilizaba la CVM y que con la conguracin CLDC se utilizaba la KVM. Con los perles ocurre lo mismo. Existen unos perles que se construirn sobre la conguracin CDC y otros que se construirn sobre la CLDC.

110

CAPTULO 5. JAVA 2 MICRO EDITION

Figura 5.4: Entorno de Ejecucin de J2ME. Para la conguracin CDC se encuentran los siguientes perles: Fundation Prole. Personal Prole. RMI Prole. Y para la conguracin CLDC se encuentran los siguientes: PDA Prole. Mobile Information Device Prole (MIDP). En la gura 5.4 de la pgina 110 se puede ver cmo quedara el esquema del entorno de ejecucin al completo. A continuacin se describir con ms detenimiento cada uno de estos perles:

5.2. COMPONENTES DE J2ME

111

Foundation Prole: Este perl dene una serie de APIs sobre la CDC orientadas a dispositivos que carecen de interfaz grca como, por ejemplo, decodicadores de televisin digital [19]. Este perl incluye gran parte de los paquetes de la J2SE, pero excluye totalmente los paquetes que conforman la interfaz grca de usuario (GUI ) de J2SE, concretamente los paquetes java.awt Abstract Windows Toolkit (AWT ) y java.swing. Los paquetes que forman parte del Foundation Prole se muestran en la tabla 5.3 de la pgina. 111. Paq. del Fundation Prole java.lang java.util java.net java.io java.text java.segurity Descripcin Soporte del lenguaje Java Aade soporte completo para zip y otras funcionalidades Incluye sockets TCP/IP y conexiones HTTP Clases Reader y Writer de J2SE Incluye soporte para internacionalizacin Incluye cdigos y certicados

Tabla 5.3: Libreras del Foundation Prole. Personal Prole: Es un subconjunto de la plataforma J2SE versin 1.3, proporciona un completo soporte grco AWT . El objetivo es el de dotar a la conguracin CDC de una interfaz grca completa, con capacidades web y soporte de applets Java. Este perl requiere una implementacin del perl Foundation Prole. La tabla 5.4 de la pgina 112 muestra los paquete que conforman el perl. RMI Prole: Este perl requiere una implementacin del Foundation Prole. El perl RMI soporta un subconjunto de las APIs J2SE v1.3 RMI. Algunas caractersticas de estas APIs se han eliminado del perl RMI debido a las limitaciones de cmputo y memoria de los dispositivos. Las siguientes propiedades se han eliminado del J2SE RMI v1.3 :

112

CAPTULO 5. JAVA 2 MICRO EDITION

Paq. del Personal Prole java.applet java.awt java.awt.datatransfer java.awt.event java.awt.font java.awt.im java.awt.im.spi

Descripcin 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 manipulacin de fuentes Clases e interfaces para denir mtodos editores de entrada Interfaces que a aden el desarrollo de mtodos editores de entrada para cualquier entorno de ejecucin Java Clases para crear y modicar imgenes Clases que soportan JavaBeans Interfaces que usa el Personal Prole para la comunicacin

java.awt.image java.beans javax.microedition.xlet

Tabla 5.4: Libreras del Personal Prole.

5.2. COMPONENTES DE J2ME

113

Java.rmi.server.disableHTTP. Java.rmi.activation.port. Java.rmi.loader.packagePrex. Java.rmi.registry.packagePrex. Java.rmi.server.packagePrex PDA Prole: Est construido sobre CLDC. Pretende abarcar PDAs de gama baja, tipo Palm, con una pantalla y algn tipo de puntero (ratn o lpiz) y una resolucin de al menos 20000 pixeles. Mobile Information Device Prole (MIDP): Este perl est construido sobre la conguracin CLDC. MIDP fue el primer perl denido para esta plataforma. Este perl est orientado para dispositivos con las siguientes caractersticas: Reducida capacidad computacional y de memoria. Conectividad limitada (en torno a 9600 bps). Capacidad grca muy reducida (mnimo un display de 96x54 pixels). Entrada de datos alfanumrica reducida. 128 Kb de memoria no voltil para componentes MIDP. 8 Kb de memoria no voltil para datos persistentes de aplicaciones. 32 Kb de memoria voltil en tiempo de ejecucin para la pila Java. Los tipos de dispositivos que se adaptan a estas caractersticas son: telfonos mviles, buscapersonas (pagers) o PDAs de gama baja con conectividad. El perl MIDP especica las APIs relacionadas con: La aplicacin (semntica y control de la aplicacin MIDP). Interfaz de usuario.

114

CAPTULO 5. JAVA 2 MICRO EDITION

Almacenamiento persistente. Trabajo en red. Temporizadores. Las aplicaciones realizadas utilizando MIDP reciben el nombre de MIDlets (por simpata con APPlets). Se puede decir que un MIDlet es una aplicacin Java realizada con el perl MIDP sobre la conguracin CLDC. En la tabla 5.5 de la pgina 114 se pueden apreciar cules son los paquetes que estn incluidos en el perl MIDP. Paq. del MIDP javax.microedition.lcdui javax.microedition.rms javax.microedition.midlet javax.microedition.io java.io java.lang java.util Descripcin Clases e interfaces para GUIs Soporte para el almacenamiento persistente del dispositivo Clases de denicin de la aplicacin Clases e interfaces de conexin genrica Clases e interfaces de E/S bsica Clases e interfaces de la mquina virtual Clases e interfaces de utilidades estndar

Tabla 5.5: Libreras del MIDP Prole.

5.3

Requerimientos Funcionales Para Detectar una Aplicacin 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 travs de un navegador WAP o a travs de una aplicacin residente escrita especcamente para identicar 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 especicacin 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 contrasea 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 especicacin MIDP. Estn diseados para ser ejecutados en dispositivos con poca capacidad grca, de cmputo y de memoria. Las clases de un MIDLet, son almacenadas en bytecodes Java, dentro de un chero .class. Estas clases deben ser vericadas antes de su puesta en marcha, para garantizar que no realizan ninguna operacin no permitida. Esta prevericacin, se debe hacer debido a las limitaciones de la mquina virtual usada en estos dispositivos [19]. Para mantener a la mquina virtual lo ms sencilla y pequea posible, se elimina esta vericacin, y se realiza antes de la entrada en produccin. La prevericacin se realiza despus de la compilacin, y el resultado es una nueva clase, lista para ser puesta en produccin. Los MIDLets son empaquetados en cheros .jar.

116

CAPTULO 5. JAVA 2 MICRO EDITION

Existen 2 cheros que contienen informacin extra dentro del .jar para la puesta en marcha de la aplicacin, el chero maniesto, con extensin .mf y un chero descriptor, con extensin .jad. Un chero .jar tpico, por tanto, se compondr de: Clases del MIDLet. Clases de soporte. Recursos (imgenes, sonidos, etc.). Maniesto (chero .mf). Descriptor (chero .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 ejecucin.

5.4.2

Ciclo de Vida de un Midlet

Como puede ilustrarse en la gura 5.5 de la pgina 117 el ciclo de vida de un MIDlet pasa por cinco fases: Descubrimiento o localizacin; instalacin; ejecucin; actualizacin y borrado. El AMS es el encargado de gestionar cada una de estas fases de la siguiente manera: 1. Localizacin: Esta fase es la etapa previa a la instalacin del MIDlet y es donde se selecciona a travs del gestor de aplicaciones la aplicacin

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 eleccin 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 conexin inalmbrica. 2. Instalacin: En esta fase el gestor de aplicaciones controla todo el proceso de instalacin del MIDlet informando al usuario tanto de la evolucin de la instalacin como de si existiese algn problema durante sta. 3. Ejecucin: Mediante el gestor de aplicaciones se va a poder iniciar la ejecucin de los MIDlets. En esta fase, el AMS tiene la funcin de gestionar los estados del MIDlet en funcin de los eventos que se produzcan durante esta ejecucin. 4. Actualizacin: El AMS tiene que tener la capacidad de detectar si el MIDlet a instalar es una actualizacin de alguno ya existente, en cuyo caso deber informar de la situacin y permitir la actualizacin 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

CAPTULO 5. JAVA 2 MICRO EDITION

Figura 5.6: Estados de un MIDlet.

El AMS es el encargado de eliminar el MIDlet pidiendo una conrmacin del proceso antes de continuar.

5.4.3

Estados de un MIDlet

Adems de gestionar el ciclo de vida de los MIDlets, el AMS es el encargado de controlar los estados del MIDlet durante su ejecucin. 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 gura 5.6 de la pgina 118. Como se puede ver en la gura 5.6 de la pgina 118, un MIDlet puede cambiar de estado mediante una llamada a los mtodos MIDlet.startApp(), MIDlet.pauseApp() o MIDlet.destroyApp(). El gestor de aplicaciones cambia el estado de los MIDlets haciendo una llamada a cualquiera de los mtodos anteriores. Un MIDlet tambin puede cambiar de estado por s mismo.

5.4. LOS MIDLETS

119

5.4.4

El paquete javax.microedition.midlet

El paquete javax.microedition.midlet dene las aplicaciones MIDP y su comportamiento con respecto al entorno de ejecucin. En la tabla 5.6 de la pgina 119 se puede apreciar cules son las clases que estn incluidas en este paquete. Clases MIDlet MIDletstateChangeException Descripcin Aplicacin 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 aplicacin realizada usando el perl MIDP. La aplicacin 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 mtodos de los que dispone esta clase son los siguientes: protected MIDlet() Constructor de clase sin argumentos. Si la llamada a este constructor falla, se lanzara la excepcin SecurityException. public nal int checkPermission(String permiso) Con este mtodo se consigue un nmero que determina el permiso especicado. Este permiso est descrito en el atributo MIDlet-Permission del archivo JAD. Los valores que puede arrojar este mtodo son:

120

CAPTULO 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 terminacin 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 mtodo puede ser llamado desde los estados Pausa o Activo. public nal String getAppProperty(String key) Este mtodo 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 parmetro key. public nal void notifyDestroyed() Con este mtodo se notica al AMS que el MIDlet no quiere estar Activo y que ha entrado en el estado de Pausa. Este mtodo slo debe ser invocado cuando el MIDlet est en el estado Activo. Si la aplicacin es pausada por s misma, es necesario llamar al mtodo MIDlet.resumeRequest() para volver al estado Activo. protected abstract void pauseApp() Indica al MIDlet que entre en el estado de Pausa. Este mtodo slo debe ser llamado cundo el MIDlet est en estado Activo. public nal boolean platformRequest(String url)

5.4. LOS MIDLETS

121

Establece una conexin entre el MIDlet y la direccin URL. Dependiendo del contenido de la URL, el dispositivo ejecutar una determinada aplicacin que sea capaz de leer el contenido y dejar al usuario que interacte con l. protected abstract void startApp() throws MIDletstateChangeException Este mtodo indica al MIDlet que ha entrado en el estado Activo. Este mtodo slo puede ser invocado cundo 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 lanzara la excepcin MIDletstateChangeException. Los mtodos anteriormente mencionados se utilizan para la comunicacin entre el MIDlet y el AMS. Por un lado se tiene que los mtodos startApp(), pauseApp() y destroyApp() los utiliza el AMS para comunicarse con el MIDlet, mientras que los mtodos 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 funcin main(). Aunque si existiese dicha funcin, el gestor de aplicaciones la ignorara por completo. Un MIDlet tampoco puede realizar una llamada a System.exit(). Una llamada a este mtodo lanzara la excepcin 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

CAPTULO 5. JAVA 2 MICRO EDITION

/* Aqu se puede incluir el cdigo que el * MIDlet debe ejecutar cundo se active. */ } public pauseApp(){ /* Aqu se puede incluir el cdigo que el * MIDlet debe ejecutar cundo entre en el estado de pausa * es opcional */ } public destroyApp(){ /* Aqu se puede incluir el cdigo que el * MIDlet debe ejecutar cundo sea destruido. Normalmente * aqu se liberaran los recursos ocupados por el * MIDlet como memoria, etc. * es opcional */ } }// n de la clase MiMidlet

Un pequeo ejemplo de una aplicacin simple se puede apreciar a continuacin.

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 GRFICAS DE USUARIO

123

} public void startApp(){ pantalla.setCurrent(formulario); } public void pauseApp(){ } public void destroyApp(boolean unconditional){ pantalla = null; formulario = null; notifyDestroyed(); } }

Estos mtodos 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 mtodos abstractos: startApp(), pauseApp() y destroyApp() que han de ser implementados por cualquier MIDlet.

5.5

Interfaces Grcas de Usuario

Teniendo en cuenta la diversidad de aplicaciones que se pueden realizar para los dispositivos MID y los elementos que proporcionan tanto la conguracin CLDC como el perl MIDP se pueden clasicar 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 nalidad 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 esttica depende exclusivamente del dispositivo donde se ejecute. La ventaja de la utilizacin de esta interfaz de usuario de alto nivel es la gran portabilidad que se consigue. Generalmente esta interfaz es utilizada para la creacin de aplicaciones de negocios.

124

CAPTULO 5. JAVA 2 MICRO EDITION

Figura 5.7: Jerarqua 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, adems se pueden manejar eventos de bajo nivel, tales como pulsaciones de las teclas. Esta interfaz es ms adecuada para el desarrollo de juegos. El paquete javax.microedition.lcdui denido en el perl MIDP incluye las clases necesarias para crear interfaces de usuario, tanto de alto nivel como de bajo nivel. En la gura 5.7 de la pgina 124 se puede apreciar la organizacin 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 informacin sobre las caractersticas de la pantalla del dispositivo donde se ejecute el MIDlet. En la tabla 5.7 de la pg. 125 se puede ver los mtodos incluidos en esta clase.

5.5. INTERFACES GRFICAS DE USUARIO

125

Mtodos void callSerially (Runnable r) boolean ashBacklight (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)

Descripcin Retrasa la ejecucin del mtodo run() del objeto r Provoca un efecto de ash 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 parmetro 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 nmero de niveles alpha soportados Devuelve el nmero de colores Establece la pantalla d despues de la alerta a Establece la pantalla actual Establece en la pantalla al item Realiza la operacin de vibracin del dispositivo

Tabla 5.7: Mtodos de la Clase Display.

126

CAPTULO 5. JAVA 2 MICRO EDITION

5.5.2

La Clase Displayable

La clase Displayable representa a las pantallas de la aplicacin. Como se mencion anteriormente, cada objeto Display puede contener tantos objetos displayables como se desee. Mediante los mtodos getCurrent y setCurrent se controlan las pantallas para que sean visibles y accesibles en cada momento. La clase abstracta Displayable incluye los mtodos encargados de manejar los eventos de pantalla y aadir o eliminar comandos. Estos mtodos aparecen en la tabla 5.8 de la pg. 126. Mtodos 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) Descripcin aade el Command cmd Devuelve el alto de la pantalla Devuelve el Ticker asignado a la pantalla Devuelve el ttulo 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 mtodo cundo el rea disponible para el objeto Displayable es modicada Establece un Ticker a la pantalla Establece un ttulo a la pantalla

Tabla 5.8: Mtodos de la Clase Displayable.

5.5.3

Las Clases Command y CommandListener

Un objeto de la clase Command mantiene informacin sobre un evento.

5.5. INTERFACES GRFICAS DE USUARIO

127

Por establecer una analoga se puede pensar a un objeto Command como un botn de Windows. Se implementan en los MIDlets para poder detectar y ejecutar una accin simple. Existen tres parmetros que hay que denir al constuir un Command: Etiqueta: La etiqueta es la cadena de texto que aparecer en la pantalla del dispositivo que identicar al Command. Tipo: La declaracin del tipo sirve para que el dispositivo identique el Command y le d una apariencia especca acorde con el resto de aplicaciones existentes en el dispositivo. Prioridades: Esto puede servirle al AMS para establecer un orden de aparicin de los Command en pantalla. A mayor nmero, menor prioridad. Los tipos que se pueden asignar aparecen en la tabla 5.9 de la pgina 127. Tipo BACK CANCEL EXIT HELP ITEM OK SCREEN STOP Descripcin Peticin para volver a la pantalla anterior Peticin para cancelar la accin en curso Peticin para salir de la aplicacin Peticin para mostrar informacin de ayuda Peticin para introducir el comando en un Item en la pantalla Aceptacin de una accin por parte del usuario Para comandos de propsito ms general Peticin para parar una operacin 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 pg. 128 muestra los mtodos de la clase Command.

128

CAPTULO 5. JAVA 2 MICRO EDITION

Mtodo public int getCommandType() public String getLabel() public String getLongLabel() public int getPriority()

Devuelve el tipo del Command Peticin 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: Mtodos de la Clase Command.

No solo basta con crear objetos Command, para poder controlar algn evento de la aplicacin. Otra tarea pendiente es implementar la interfaz CommandListener, la cual dene un mtodo abstracto llamado CommandAction(Command d, Displayable d), donde debe ser implentado dicho mtodo, ya que una interfaz slo dene mtodos abstractos, es tarea de la clase que implementa dicha interfaz tener que implementar los mtodos denidos. A travs de la implementacin del mtodo CommandAction se podrn 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 especicacin MIDP 1.0 esta clase contena cuatro mtodos que le permitan denir y obtener el ttulo 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 especicacin MIDP 2.0, que es la ms reciente, estos cuatro mtodos han sido incluidos en la clase Displayable.

5.5. INTERFACES GRFICAS 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 situacin 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 mtodo Alert. setTimeOut (Alert. FOREVER). 2. No modal : Este tipo de alerta permanecer por un tiempo denido por el usuario y luego desaparecer. Para ello se indica el tiempo en el mtodo setTimeOut(tiempo), el tiempo expresado en milisegundos. Tambin 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 denir aparecen en la tabla 5.11 de la pgina 129. Mtodo ALARM CONFIRMATION ERROR INFO WARNING Devuelve el tipo del Command Aviso de una Peticin previa Indica la aceptaci de una acci Indica que ha ocurrido un error Indica algn tipo de informacin Indica que puede ocurrir algn problema

Tabla 5.11: Tipos de Alerta.

130

CAPTULO 5. JAVA 2 MICRO EDITION

La Clase List La clase List hereda de la clase Screen, pero presenta una funcionalidad ms 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 dene constantes que describen tres tipos bsicos de listas de opciones: EXCLUSIVE: Una lista que permite seleccionar un solo elemento a la vez. IMPLICIT: Un lista en la que la seleccin de un elemento provoca un evento (se adapta para la creacin de mens). MLTIPLE: Una lista que permite seleccionar uno o ms elementos a la vez. Existen dos constructores que permiten construir listas: el primero de ellos crea una lista vaca y el segundo proporciona una lista con un conjunto inicial de opciones y de imgenes asociadas: List(String titulo, int listType). List(String titulo, int listType, String[] elementos, Image[] imagenes). En la siguiente tabla 5.12 de la pgina 131 se puede observar los distintos mtodos de la clase List. La Clase TextBox La clase TextBox implementa un componente de edicin de texto, que ocupa toda la pantalla. El constructor de la clase es: TextBox(String title, String text, int maxSize, int constraints) El parmetro title es un texto que aparecer en la parte superior de la pantalla, mientras que el parmetro text es usado para inicializar el texto que contendr el TextBox.

5.5. INTERFACES GRFICAS DE USUARIO

131

Mtodos int append(String texto, Image imagen) void delete(int posicin) 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()

Descripcin Aade un elemento al nal de la lista Elimina el elemento de la posicin especicada Elimina todas las entradas de la lista Inserta un elemento en la posicin especicada 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 posicindeterminada Almacena el estado de seleccin en un array Obtiene el (i)ndice del elemento seleccionado Obtiene el texto del elemento indicado por pos Determina si est seleccionado (a) el elemento Elimina el comando cmd Reemplaza el elemento de la posicin 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 seleccin por el de array Reemplaza el estado de la seleccin Obtiene el nmero de elementos

Tabla 5.12: Mtodos de la Clase List.

132

CAPTULO 5. JAVA 2 MICRO EDITION

El parmetro maxSize especica el nmero mximo de caracteres de texto que pueden ser introducidos en el TextBox. Por ltimo el parmetro constraints describe las limitaciones a aplicar sobre el texto. Estas limitaciones son especicadas segn las constantes denidas en la clase TextField: ANY: No hay limitaciones en el texto. EMAILADDR: Slo se puede introducir una direccin de correo electrnico. NUMERIC: Slo se puede introducir un valor numrico. PASSWORD: El texto es protegido para que no sea visible. PHONENUMBER: Slo se puede introducir un nmero de telfono. URL: Slo se puede introducir una URL. Un ejemplo de uso sera: TextBox box = new TextBox(NOTAS, Nota: , 256, TextField.ANY). La Clase Form Un formulario (clase Form) es un componente que acta como contenedor de un nmero indeterminado de objetos. Todos los objetos que puede contener un formulario derivan de la clase Item. El nmero de objetos que se pueden insertar en un formulario es variable pero, teniendo en cuenta el tamao de las pantallas de los dispositivos MID, se recomienda que el nmero sea pequeo para evitar as el scroll que se producira si se insertan demasiados objetos en un formulario. Un mismo Item no puede estar en ms de un formulario a la vez. Si, por ejemplo, se desea usar una misma imagen en ms 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 GRFICAS DE USUARIO

133

Si no se cumple esta regla, se lanzara la excepcin IllegalStateException. La tabla 5.13 de la pgina 133 muestra los mtodos de la clase Form. Mtodos 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() Descripcin Aade una imagen al formulario Aade un item al formulario Aade un String al formulario Elimina el Item que ocupa la posicin 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 posicin num Reemplaza el Item que ocupa la posici (o)n num Determina si est seleccionado el elemento Establece un listener eventos capturar Devuelve el nmero de Items del formulario

Tabla 5.13: Mtodos 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 ms que para un formulario se tiene que implementar la interfaz ItemStateListener que contiene un mtodo abstracto llamado itemStateChanged(Item item). Cuando se realiza algn tipo de accin en el algn tem del formulario se

134

CAPTULO 5. JAVA 2 MICRO EDITION

ejecuta el cdigo asociado del mtodo itemStateChanged(Item item). Un ejemplo de su utilizacin se puede observar a continuacin:
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 GRFICAS DE USUARIO

135

La Clase StringItem La clase StringItem es la clase ms simple que deriva de Item. Es una cadena no modicable 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 parmetros: 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 mtodos que posee la clase StringItem aparecen en la tabla 5.14 de la pgina 135 Mtodos int getAppearanceMode() Font getFont() String getText() void setFont(Font fuente) void setText(String texto) Descripcin 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: Mtodos de la Clase StringItem.

La Clase ImageItem La clase ImageItem brinda la posibilidad de incluir imgenes en un formulario.

136

CAPTULO 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 parmetro textoalt especica una cadena de texto alternativa a la imagen en caso de que sta exceda la capacidad de la pantalla. Por su parte, el parmetro layout indica la posicin 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 : Posicin por defecto. LAYOUT_NEWLINE_AFTER: Imagen posicionada tras un salto de lnea. LAYOUT_NEWLINE_BEFORE: Imagen posicionada antes de un salto de lnea. Los mtodos de la clase ImageItem se pueden ver en la tabla 5.15 de la pgina 137. La Clase TextField Un texeld es un campo de texto que puede ser insertado en un formulario y en el cul se puede editar texto. Tiene similitud con la clase TextBox. Sus diferencias son:

5.6. RMS (RECORD MANAGEMENT SYSTEM)

137

Mtodos String getAltText() Int getAppearanceMode() Image getImage() Int getLayout() void setAltText(String textoalt) void setImage(Image imagen) void setLayout(int layout)

Descripcin 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: Mtodos de la Clase ImageItem. Un texeld 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 travs de Commands. Por esta razn, los eventos que produce un TextField se controlan a travs del mtodo itemStateChanged(Item item), mientras que en un TextBox se controlan en el mtodo commandAction(Command c, Displayable d). Sin embargo ambas clases (TextBox y TextField) comparten las mismas restricciones de edicin que se vieron anteriormente. Para crear un TextField slo hay que invocar al constructor con los siguientes parmetros: TextField(String etiqueta, String texto, int capacidad, int restricciones). Otros mtodos de esta clase pueden verse en la tabla 5.16 de la pgina 138

5.6

RMS (Record Management System)

El sistema de gestin 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 informacin.

138

CAPTULO 5. JAVA 2 MICRO EDITION

Mtodos 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()

Descripcin 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 tamao mximo 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 posicin 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 tamao mximo del TextField Establece el contenido del TextField Establece el contenido del TextField Devuelve el nmero de caracteres

Tabla 5.16: Mtodos 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 estn disponibles una vez que el MIDlet detenga su ejecucin. La unidad bsica de almacenamiento es el registro (record) que ser almacenado en un base de datos especial, denominada almacn de registros (record store ). Cuando un MIDlet usa un almacn de registros, primero debe crearlo y luego aadir los registros. Cuando un registro es aadido a un almacn de registros, se le asigna un identicador 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 gura 5.8 de la pgina 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 gura 5.9 de la pgina 140.

140

CAPTULO 5. JAVA 2 MICRO EDITION

Figura 5.9: Acceso a un RMS a Travs 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 ms registros. 2. El nombre puede tener un mximo de 32 caracteres. 3. Si una suite es borrada, todos los Record Store tambin 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 almacn de registros, donde stos registros son la unidad bsica de informacin. Cada uno de estos registros est formado por dos unidades: Un nmero identicador de registro (Record ID) que es un valor entero que realiza la funcin 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 informacin deseada. En la gura 5.10 de la pgina 141 se ilustra la estructura de un Record Store.

5.6.3

Creacin 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 caractersticas. Bsicamente se dispone de: Capacidad para aadir y borrar registros de un almacn. Capacidad para compartir almacenes de todos los MIDlets de una MIDlet suite. La clase RecordStore no dispone de ningn constructor, pero posee el mtodo esttico: static RecordStore openRecordStore(String name, Boolean createIfNeccesary). Este mtodo permite la apertura de un Record Store existente o bien la creacin de un almacn si el parmetro createIfNeccesary tiene el valor true. Tambin existen otras dos alternativas de este mtodo:

142

CAPTULO 5. JAVA 2 MICRO EDITION

static RecordStore openRecordStore(String name, boolean createIfNeccesary,

int autorizacin, boolean writable).

static RecordStore openRecordStore(String name, String vendorName, String

suiteName).

El primero de ellos utiliza los siguientes parmetros: autorizacin: AUTHMODE_PRIVATE : Slo 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 especica si el Record Store puede ser modicado por cualquier MIDlet que pueda acceder a l. El segundo mtodo se utiliza para abrir un Record Store que est asociado a alguna MIDlet suite especicada por los parmetros vendorName y suiteName. El acceso vendr limitado por el tipo de autorizacin del Record Store cuando fue creado. Al nalizar con el uso de un determinado Record Store hay que cerrar la comunicacin con l. Para ello se utiliza el siguiente mtodo: public void closeRecordStore() throws RecordStoreNotFoundException, RecordStoreException.

En la tabla 5.17 de la pgina 143 se pueden apreciar los mtodos que proporcionan operaciones con los Record Stores.

5.6.4

Manipulacin de Registros

Una vez creado o abierta la comunicacin con el Record Store, se puede leer, escribir, modicar o borrar registros como se desee. Para ello, se usan los mtodos de la clase RecordStore que se ven en la tabla 5.18 de la pgina 144.

5.6. RMS (RECORD MANAGEMENT SYSTEM)

143

Mtodos String getName() int getVersion() long getLastModied() int getNumRecords() int getSize() int getSizeAvailable() String[] listRecordStores() void deleteRecordStore (String name) RecordEnumeration enumerateRecords(RecordFilter lter, RecordComparator comparator, boolean actualizado) void addRecordListener (RecordListener listener) void removeRecordListener (RecordListener listener)

Descripcin Devuelve el nombre del Record Store Devuelve la versi n del Record Store Devuelve la marca temporal Devuelve el nmero de registros Devuelve el nmero de bytes ocupado por el Record Store Devuelve el tama (n)o disponible para aadir registros Devuelve una lista con los nombres de los Record Stores Elimina del dispositivo al Record Store especicado por el parmetro name devuelve un objeto RecordEnumeration

Aade un listener para detectar cambios en el Record Store Elimina un listener

Tabla 5.17: Mtodos Generales de la Clase RecordStore.

144

CAPTULO 5. JAVA 2 MICRO EDITION

Mtodos int addRecord(byte[] datos, int oset, int numBytes) void deleteRecord(int id) Int getNextRecordId() byte[] getRecord(int id) int getRecord(int id, byte[] buer,int oset) int getRecordSize(int id) void setRecord(int id,byte[] datonuevo, int oset, int tamao)

Descripcin Aade 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 identicador id Devuelve el registro con identicador id en buer a partir de oset Devuelve el tama (n)o del registro id Sustituye el registro id con el valor de datonuevo

Tabla 5.18: Mtodos Para Manejo de Registros. A continuacin 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 ag) throws MIDletStateChangeException{ } // este mtodo 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

CAPTULO 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(Informacin, Los datos se estan cargando espere..., null, AlertType.INFO);

148

CAPTULO 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.ush(); 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

CAPTULO 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 gura 5.11 de la pgina 151 se pueden apreciar las pantallas del ejemplo representadas por capturas de pantalla de una Palm T|X.

5.6. RMS (RECORD MANAGEMENT SYSTEM)

151

Figura 5.11: Ejemplo RMS.

152

CAPTULO 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 cdigo:
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 navegacin por los registros usando RecordEnumeration es mucho ms intuitiva y permite realizar acciones como mover hacia delante o hacia atrs de una manera muy sencilla.

5.6.6

Bsqueda de Registros

Para realizar una bsqueda eciente de registros, se debe implementar la interfaz RecordFilter, esta interfaz se encarga de devolver slo los registros que coincidan con el patrn de bsqueda especicado. Para usar esta interfaz se debe implementar necesariamente el mtodo:

5.7. COMUNICACIONES EN J2ME

153

public boolean matches(byte [] candidato), el cual se encarga de comparar el registro candidato pasado como parmetro 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 tambin 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 tamao 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 permitirn crear y manejar diferentes conexiones de red. Estas conexiones podrn usar diferentes formas de comunicacin: HTTP, datagramas, sockets, etc. El paquete java.io se encargar de proporcionar las clases necesarias para leer y escribir en estas conexiones. En la gura 5.12 de la pgina 154 puede verse la jerarqua de clases que reciben el nombre de Generic Framework Conection (GFC). En la raz del rbol se encuentra la interfaz Connection que representa la conexin ms genrica 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 conexin. Esta clase puede por s misma crear cualquier tipo de conexin: Archivos, Http, socket,etc.

154

CAPTULO 5. JAVA 2 MICRO EDITION

Figura 5.12: Jerarqua de Interfaces. Clase Connector Como se ha dicho anteriormente, el GCF proporciona la clase Connector que esconde los detalles de la conexin. De esta forma se puede realizar cualquier tipo de conexin usando slo esta clase y sin preocuparnos de cmo se implementa el protocolo requerido. La conexin se realiza de la siguiente manera:
Connector.open(protocolo:direccin;parmetros);

Algunos ejemplo de invocacin son: Connector.open(http://direccionquesea.es); Connector.open(le://autoexec.bat); Connector.open(socket://direccion:0000); La clase Connector se encarga de buscar la clase especca que implemente el protocolo requerido. Si esta clase se encuentra, el mtodo open() devuelve

5.7. COMUNICACIONES EN J2ME

155

un objeto que implementa la interfaz Connection. En la tabla 5.19 de la pgina 155 se puede apreciar los mtodos de la clase Connector. Mtodos 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) Descripcin Crea y abre una conexin Crea y abre una conexin con permisos Crea y abre una conexin especicando el permiso y tiempo de espera Crea y abre una conexin de entrada devolviendo para ello un DataInputStream Crea y abre una conexi de [on salida a travs de un DataOutputStream Crea y abre una conexin de entrada usando un InputStream Crea y abre una conexin de salida devolviendo para ello un OutputStream

Tabla 5.19: Mtodos de la Clase Connector. Los tipos de permisos se pueden ver en la tabla 5.20 de la pgina 156.

La Interfaz Connection La interfaz Connection se encuentra en lo ms alto de la jerarqua de interfaces del Generic Connection Framework, por lo que cualquier otra interfaz deriva de sta. Una conexin de tipo Connection se crea despus de que un objeto Connector invoque al mtodo open(). Como se dijo anteriormente, esta interfaz representa la conexin ms genrica posible por lo que dene un slo mtodo:

156

CAPTULO 5. JAVA 2 MICRO EDITION

Modo READ READ_WRITE WRITE

Descripcin 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 conexin.

Interfaz InputConnection La interfaz InputConnection representa una conexin basada en streams de entrada. Esta interfaz slo posee dos mtodos que devuelven objetos de tipo InputStreams. En el siguiente ejemplo se ilustra cmo podra utilizarse este tipo de conexin: String url = www.midireccion.com; InputConnection conexin = (InputConnection)Connector.open(url); DataInputStream dis = conexion.openDataInputStream();

Interfaz OutputConnection La interfaz OutputConnection representa una conexin basada en streams de salida. Esta interfaz slo posee dos mtodos que devuelven objetos de tipo OutputStreams. La conexin a travs 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 conexin basada en streams tanto de entrada como de salida. No aade ningn mtodo nuevo, si no que hereda los mtodos de los interfaces que estn por encima de l. Su nica misin en la jerarqua del GCF es representar un tipo de conexin cuyos datos pueden ser tratados como streams de bytes y en la que es posible leer y escribir. A continuacin un ejemplo de cmo podra utilizarse esta conexin:
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 peticin / respuesta. El funcionamiento de este protocolo es el siguiente: El cliente realiza una peticin al servidor y espera a que ste le enve una respuesta. Normalmente, esta comunicacin es la que suele realizarse entre un navegador web (cliente) y un servidor web (servidor). En este caso la comunicacin se realiza a travs de un MIDlet(cliente) y un Servlet(servidor) que recibir peticiones y devolver los resultados. Una conexin HTTP pasa por tres estados que se pueden ver en la gura 5.13de la pgina 158.

Establecimiento de la Conexin En este estado es donde se van a establecer los parmetros de la comunicacin.

158

CAPTULO 5. JAVA 2 MICRO EDITION

Figura 5.13: Estados de una conexin HTTP. El cliente prepara la peticin que va a realizar al servidor, adems de negociar con l una serie de parmetros como el formato, idioma, etc. Existen dos mtodos que pueden ser invocados. En la tabla 5.21 de la pgina 158 se pueden apreciar estos mtodos. Mtodo public void setRequestMethod(String tipo) public void setRequestProperty (String clave, String valor) Descripcin Establece el tipo de peticin Establece una propiedad de la peticin

Tabla 5.21: Mtodos en la Etapa de Establecimiento. El primer mtodo establece el tipo de peticin que se va a realizar. Esta peticin puede ser de los tipos indicados en la tabla 5.22 de la pgina 159. El segundo mtodo permite negociar entre el cliente y el servidor detalles de la peticin como, por ejemplo, idioma, formato, etc. Estos campos forman parte de la cabecera de la peticin. En la tabla 5.23 de la pgina 159 se pueden ver algunos de los ms importantes. Peticiones GET

5.7. COMUNICACIONES EN J2ME

159

Tipo GET POST HEAD

Descripcin Peticin de informacin en la que los datos se envan como parte del URL Peticin de informacin en la que los datos se envan aparte en un stream Peticin de metainformacin

Tabla 5.22: Tipos de peticiones.

Campo public void setRequestMethod (String tipo) User-Agent Content-Language Content-Length) Accept Connection

Descripcin Establece el tipo de peticin 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 conexin despus de la peticin o se quiere dejar abierta Sirve para controlar el almacenamiento de informacin Tiempo m ximo para respuesta del servidor Pregunta si el contenido solicitado se ha modicado desde una fecha dada

Cache-Control Expires If-Modied-Since

Tabla 5.23: Campos de la Cabezera.

160

CAPTULO 5. JAVA 2 MICRO EDITION

A continuacin se muestra un ejemplo en el que se prepara una conexin mediante la interfaz HttpConnection usando una peticin de tipo GET.
//se crea la conexin String url = http://www.midireccion.com/local?opcion=1&us=usuario&pass=1234; HttpConnection hc = (HttpConnection)Connector.open(url); //se informa el tipo de conexin a realizar hc.setRequestMethod(HttpConnection.GET); // se establece algunos campos en la cabezera hc.setRequestProperty(User-Agent,Prole/MIDP-2.0 Conguration/CLDC-1.0); hc.setRequestProperty(Content-Language,es-ES);

Como puede apreciarse, la informacin sobre la peticin va incluida en la cabecera de la direccin URL. El cuerpo de la peticin lo forma la cadena: opcion=1&us=usuario&pass=1234. Esta informacin va detrs del smbolo ? situado al nal de la direccin URL. Cada parmetro de la peticin va separado del siguiente por el smbolo &. Peticiones POST En este tipo de conexin, el cuerpo de la peticin se enva en un stream despus de iniciar la conexin. El siguiente ejemplo muestra cmo se realiza el envo del cuerpo de la peticin:
//se crea la conexin String url = http://www.midireccion.com; HttpConnection hc = (HttpConnection)Connector.open(url); // se informa el tipo de peticin a realizar hc.setRequestMethod(HttpConnection.POST); //se establece algunos campos de la cabezera

5.7. COMUNICACIONES EN J2ME

161

hc.setRequestProperty(User-Agent,Prole/MIDP-2.0 Conguration/CLDC-1.0); hc.setRequestProperty(Content-Language,es-ES); // se envia el cuerpo de la peticin OutputStream os = hc.openOutputStream(); os.write(opcion=1.getBytes()); os.write(&us=usuario.getBytes()); os.write(&pass=1234.getBytes()); os.ush();

Estado de la Conexin En este estado se realiza el intercambio de informacin entre el cliente y el servidor. En los ejemplos anteriores se ha visto la manera de enviar la peticin al servidor. Ahora se ver cmo se realiza la respuesta del servidor hacia el cliente. Respuesta del Servidor Al igual que la peticin del cliente posee distintas partes, la respuesta del servidor se compone de: Lnea de estado. Cabecera. Cuerpo de la respuesta. Para conocer la respuesta del servidor, la interfaz HttpConnection proporciona diversos mtodos que permiten conocer las distintas partes de sta. La interfaz HttpConnection dispone de treinta y cinco cdigos de estado diferentes. Bsicamente se pueden dividir en cinco clases de la siguiente manera:

162

CAPTULO 5. JAVA 2 MICRO EDITION

1xx: Cdigo de informacin. 2xx: Cdigo de xito. 3xx: Cdigo de redireccin. 4xx: Cdigo de error del cliente. 5xx: Cdigo de error del servidor. Por ejemplo, el cdigo 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 cdigo de estado y de un mensaje de respuesta. Este mensaje es devuelto al invocar el mtodo getResponseMessage(). Estado de Cierre La conexin entra en este estado una vez que se termina la comunicacin entre el cliente y el servidor invocando al mtodo close(). A continuacion se ver un ejemplo donde se produce una peticin mediante una peticin POST, se describirn tanto el cdigo del MIDlet como del Servlet que recibe la peticin y devuelve una respuesta. Cdigo 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 conexin 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

CAPTULO 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 conexin 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,ProleMIDP-2.0 Conguration/CLDC1.0); hc.setRequestProperty(Content-Type,application/octect-stream); os = hc.openOutputStream(); os.write(usuario=jb.getBytes()); os.write(&clave=si.getBytes()); os.ush(); // 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())); }nally{ if (in != null) {

166

CAPTULO 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); } }

Cdigo 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

CAPTULO 5. JAVA 2 MICRO EDITION

Figura 5.14: Ejemplo de comunicacin HTTP de un MIDlet.

}

El ejemplo puede verse en la gura 5.14 de la pgina 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 conexin wi- real, la cual se demuestra con imgenes; el proceso de conexin comienza con una pantalla igual a la gura 5.15 de la pgina 169 en la cual puede verse una solicitud de permiso para utilizar tiempo de aire, debido a que el tipo de conexin 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 conexin. Luego de conrmar el permiso, puede verse en la pantalla de la Palm la gura 5.16 de la pgina 170, que indica que se est iniciando el proceso de conexin. Luego se puede apreciar en la pantalla del dispositivo la gura 5.17 de pgina 171 donde se informa que se est conectando a la red wi-, que en este ejemplo se llama SteelNet. En la gura 5.18 de la pniga 172, puede verse que se est gestionando la obtencin de una direccin IP, para que la Palm pueda comunicarse con el servidor a travs de la red wi- SteelNet.

5.7. COMUNICACIONES EN J2ME

169

Figura 5.15: Solicitud de permiso para utilizar tiempo de aire.

170

CAPTULO 5. JAVA 2 MICRO EDITION

Figura 5.16: Iniciando el proceso de conexin.

5.7. COMUNICACIONES EN J2ME

171

Figura 5.17: Conectandose a la red wi-.

172

CAPTULO 5. JAVA 2 MICRO EDITION

Figura 5.18: Obteniendo direccin IP.

5.7. COMUNICACIONES EN J2ME

173

Figura 5.19: Conectado a red wi-. La ultima pantalla que se observa en el proceso de conexin es la que conrma el estado de nalizacin del proceso, en este caso fue Conectado, esto se puede ver en la gura 5.19 de la pgina 173.

Captulo 6

Introduccin 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 generacin de los sistemas de administracin de bases de datos relacionales (RDBMS ). En los ltimos tiempos ha surgido una nueva base de datos llamada Universal, la cul es capaz de almacenar y hacer bsquedas no solamente de datos alfanumricos sino tambin de imgenes, audio, video y otros objetos. Esta ventaja de las bases de datos universales abre un gran nmero de oportunidades que permiten mejorar tanto los servicios como las aplicaciones. Se puede denir 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 modicar 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 informacin acerca de cmo las entidades estn lgicamente relacionadas entre s. Las bases son cualquier conjunto de datos organizados para su almacenamiento en la memoria de un ordenador, diseado para facilitar su mantenimiento y acceso de una manera estndar. Los datos suelen aparecer en forma 175

176

CAPTULO 6. INTRODUCCIN AL DB2

de texto, nmeros o grcos. Otra denicin ms completa de bases de datos arma que es un conjunto exhaustivo, no redundante, de datos estructurados, organizados independientemente de su utilizacin y su implementacin en mquina, accesibles en tiempo real y compatibles con usuarios concurrentes con necesidad de informacin diferente y no predecible en el tiempo, donde la informacin 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

Automatizacin de: El mantenimiento. Cualquier generacin de informacin. Cualquier consulta sobre dicha informacin.

6.1.2

Ventajas de las Bases de Datos

Algunas ventajas de las bases de datos se describen a continuacin: Ahorro de Espacio: No hacen falta archivos de papeles que pudieran ocupar mucho espacio. Velocidad: Con la utilizacin de las bases de datos se pueden modicar, consultar datos con una velocidad mucho mayor que realizndolo manualmente. Ahorro de trabajo: ya que las mquinas son encargadas de manejar estas bases y no se necesitan manejar archivos a mano, existe un ahorro de trabajo humano. Actualizacin: Se dispone en cualquier momento de informacin precisa y al da. Comodidad: Al tener la informacin en un mismo sitio, se ahorrar tiempo y trabajo.

6.2.

SISTEMA DE ADMINISTRACIN DE BASES DE DATOS

177

Disminucin de la Redundancia: La duplicacin de los datos implica mayor trabajo en el mantenimiento. Gracias a que las bases de datos disminuyen la redundancia tambin se disminuye el trabajo. Comparticin de Datos: Se trata de datos actuales, ya que al estar centralizados, se puede tener acceso a los datos actualizados en prcticamente 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 accin sobre dicha base de datos. Posibilidad de Mantener la Integridad: En una base de datos se debe mantener una coherencia. Esto se controlar mediante: Mscaras. Reglas de validacin.

6.2

Sistema de Administracin de Bases de Datos

Una base de datos es una coleccin de tablas y objetos relacionados entre s y organizados como un grupo. La estructura de una base de datos se muestra en la gura 6.1 de la pgina 178. Un DBMS es un conjunto de programas que maneja todos los accesos a las bases de datos; ver gura 6.2 de la pgina 178. Funciones de un DBMS: Denicin de datos. Manipulacin de datos. Seguridad e integridad de los datos. Recuperacin y concurrencia de los datos. Diccionario de datos. Desempeo.

178

CAPTULO 6. INTRODUCCIN AL DB2

Figura 6.1: Estructura de Una Base de Datos

Figura 6.2: Sistema de Administracin de Bases de Datos

6.3. ORGANIZACIN DE BASES DE DATOS

179

6.3

Organizacin de Bases de Datos

Los modelos ms comunes de organizacin de Bases de Datos son: Jerrquico. En Red. Relacional. Orientado a Objetos.

6.3.1

Bases de Datos Jerrquicas

Estructura los campos en nodos en una estructura jerrquica. 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 relacin 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 raz, 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 direccin a un nodo hijo. Por Ejemplo: Un Sistema de Reservaciones de una Lnea Area (ver gura 6.3 de la pgina 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 Nmero de Vuelo. El Nmero de Vuelo tendr tambin Nodos Hijos, que son los Pasajeros. Limitaciones de las Base de Datos Jerrquicas Al borrar un nodo padre, desaparecen tambin sus nodos subordinados. Slo podr aadirse un nodo hijo, si existe el nodo padre. Pero lo ms signicativo es la rigidez de su estructura: slo un padre por hijo y ausencia de relaciones entre los nodos hijos.

180

CAPTULO 6. INTRODUCCIN AL DB2

Figura 6.3: Modelo de Bases de Datos Jerrquica.

6.3.2

Bases de Datos en Red

Se trata tambin de una organizacin jerrquica de nodos, pero un nodo hijo puede tener ms de un solo nodo padre (relacin muchos a muchos). Existen los punteros, que son conexiones adicionales entre nodos padres y nodos hijos, que permiten acceder a un nodo por vas distintas accediendo al mismo en direccin descendente por las diversas ramas. Representa una mejora al modelo jerrquico. Por ejemplo:Los vendedores destacados para distribuir determinados productos en algunas ciudades pueden ilustrar este modelo (ver gura 6.4 de la pgina 181). Cada Producto puede ser distribuido por ms de un Vendedor, as mismo cada Vendedor puede encargarse de diferentes Ciudades.

6.3.3

Bases de Datos Relacional

Esta organizacin ofrece la mayor exibilidad ya que los datos se almacenan en Tablas diferentes, conformadas as mismo por Filas y Columnas. Una tabla se denomina relacin. En una Tabla las Filas contienen los Registros. Las

6.3. ORGANIZACIN 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 comn, el Campo Clave, mediante el cual la informacin almacenada en una tabla puede enlazarse con la informacin almacenada en otra. El acceso a los datos se realiza mediante consultas escritas en SQL (Structured Query Language). La Organizacin de Bases de Datos Relacional es la ms difundida en la actualidad debido a su sencillez para realizar operaciones de adicin, eliminacin y modicacin en contraste con la mayor rigidez de las Organizaciones Jerrquicas y de Red. Por ejemplo: En un pequeo negocio, se puede contar con una Tabla de Clientes y Tabla de Pedidos (ver gura 6.5 de la pgina 182). Las rdenes que pertenecen a un determinado cliente son identicadas colocando el campo de identicacin 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 semntica. No soporta tipos denidos por el ususarios (slo Dominios).

182

CAPTULO 6. INTRODUCCIN AL DB2

Figura 6.5: Modelo de Bases de Datos Relacional. No soporta Recursividad. Falta de Procesamiento/Disparadores. No admite Herencia.

6.4

Introduccin a DB2 UDB

DB2 UDB Universal Database es una Base de Datos Universal. Es completamente escalable, veloz y conable. 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 exible para servir a los medianos y pequeos negocios. DB2 UDB es un sistema manejador de base de datos relacional fuertemente

6.4. INTRODUCCIN A DB2 UDB

183

escalable. Es sucientemente exible 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

Caractersticas Generales del DB2 UDB

DB2 UDB es el producto principal de la estrategia de Data Management de IBM. DB2 UDB es un sistema para administracin de Bases de Datos Relacionales (RDBMS). Es multiplataforma, especialmente diseada para ambientes distribuidos, permitiendo que los usuarios locales compartan informacin con los recursos centrales. Es el sistema de gestin de datos que entrega una plataforma de base de datos exible y rentable para construir un sistema robusto para aplicaciones de gestin. 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 caractersticas de Integridad, asegurando la proteccin de los datos an en caso de que los sistemas sufran un colapso, y de Seguridad permitiendo realizar respaldos en lnea con distintos grados de granularidad, sin que esto afecte la disponibilidad de acceso a los datos por parte de los usuarios.

Mltiples Usos Provee la capacidad de hacer frente a mltiples necesidades, desde Procesamiento Transaccional de Misin Crtica (OLTP), hasta anlisis exhaustivo de los datos para el soporte a la toma de decisiones (OLAP).

184

CAPTULO 6. INTRODUCCIN AL DB2

Escalabilidad Sus caractersticas distintivas de Escalabilidad le permiten almacenar informacin en un amplio rango de equipos, desde un PC porttil hasta un complejo ambiente de mainframes procesando en paralelo.

Web Enabled Para e-Business Incluye tecnologa basada en Web que permite generar aplicaciones en las Intranets y responder a las oportunidades de negocios disponibles en Internet.

Facilidad de Instalacin y Uso La primera versin de DB2 para NT fue reconocida en el mercado como una base de datos muy poderosa, pero difcil de instalar y usar. En esta versin (DB2 UDB V. 8.1), IBM agreg muchas herramientas grcas para facilitar el uso para los usuarios, como tambin para los administradores y desarrolladores. Dicha versin incluye guas para operaciones como instalacin, conguracin de performance, setup, etc. Adems, se agregaron herramientas para facilitar las tareas de integracin con otras bases de datos, tecnologas de networking y desarrollo de aplicaciones.

Universalidad DB2 UDB es, adems, 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, Imgenes y Video (AIV Extender) (ver gura 6.6 de la pgina 185) . Documentos XML ( XML Extender) (ver gura 6.7 de la pgina 185).

6.4. INTRODUCCIN A DB2 UDB

185

Figura 6.6: AIV Extender.

Figura 6.7: XML Extender.

186

CAPTULO 6. INTRODUCCIN AL DB2

Funciones Complementarias del DB2 UDB Conectividad Las herramientas de conectividad permiten acceder a los datos ms 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. Adems, 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 Versin 8.1

La versin 8.1 ofrece un soporte ms potente para Business Intelligence, Gestin de Datos y Soluciones e-business. DB2 Universal Database Versin 8.1 contiene muchas caractersticas nuevas, que incluyen el Centro de desarrollo, funciones ampliadas de XML Extender, soporte de Linux para DB2 Warehouse Manager, integracin de Spatial Extender con herramientas de IBM Business Intelligence, un nuevo Centro de duplicacin, mejoras de enlace y rendimiento de DB2 Data Links Manager. Nuevas herramientas de gestin y supervisin de bases de datos, soporte de 64 bits ampliado y nuevos asistentes de Instalacin de DB2 y Centro de control de DB2.

6.5.1

Centro de Desarrollo

En la versin 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 denidas por el usuario como se muestra en la gura 6.8 de la pgina 187. Tambin es posible correlacionar tipos estructurados de los Enterprise JavaBeans. Los asistentes simplican las tareas de

6.5. DB2 UDB VERSIN 8.1

187

Figura 6.8: Centro de Desarrollo. desarrollo. Las nuevas caractersticas 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 interrupcin, variables y pila de llamadas. Una interfaz mejorada para controlar el entorno de desarrollo. Asistentes para construir funciones denidas por el usuario para MQSeries, fuentes de datos OLE DB y documentos XML. Asistentes para exportar, importar y desplegar rutinas e informacin de proyectos Productos y Paquetes Nuevos.

188

CAPTULO 6. INTRODUCCIN AL DB2

6.5.2

Mejoras en XML Extender

Se han aadido nuevas caractersticas 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 aadido nuevas caractersticas y mejoras a DB2 Warehouse Manager : Con el soporte de carga paralela nativa para DB2 Universal Database Enterprise Server Edition, es posible cargar grandes volmenes de datos con ms rapidez. DB2 Warehouse Manager tiene capacidades ampliadas, por lo que se puede incrementar y mejorar el rendimiento de las operaciones de depsito, manipular y localizar metadatos ms deprisa, y ejecutar el agente de depsito, 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 Depsito de Datos de DB2

Se han aadido nuevas caractersticas al Centro de depsito de datos: El soporte de servidor de depsito se ampla a AIX. El servidor de depsito y el iniciador de sesiones de depsito, que se ejecutan como servicios en Windows, se ejecutan como daemons en AIX. Es posible exportar e importar metadatos del lenguaje de cdigo y exportar estos objetos: Tablas, archivos y vistas de origen. Tablas y archivos de destino.

6.5. DB2 UDB VERSIN 8.1

189

El proceso en cascada (varios intervalos) permite gestionar varios pasos deniendo y habilitando una planicacin y un ujo 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 depsito de datos sin sustituir la tabla completa ni grabar cdigo adicional. Ahora, la Gua de aprendizaje de Business Intelligence se compone de dos guas de aprendizaje ms cortas: Gua de aprendizaje de Business Intelligence: Introduccin al Centro de depsito de datos y Gua de aprendizaje de Business Intelligence: Lecciones ampliadas sobre depsito de datos.

6.5.5

Asistentes de DB2

Asistente para la Conguracin de DB2 La instalacin de DB2 en plataformas Windows y UNIX resulta ms fcil mediante la utilizacin del Asistente para la conguracin de DB2. Esta interfaz grca permite instalar productos DB2 directamente o crear archivos de respuestas para permitir una instalacin posterior. En los sistemas UNIX, tambin se puede utilizar el Asistente para la conguracin de DB2 para realizar funciones de gestin de instancias.

Asistentes del Centro de Control En DB2 Versin 8.1, los asistentes que estn disponibles en las Herramientas de administracin se han ampliado para abarcar un mbito ms amplio de funciones, en comparacin con las de que se dispona en versiones anteriores de DB2. Por ejemplo, un asistente de DB2 Versin 8.1 brinda el conjunto total de opciones disponibles para crear una tabla. Como se puede observar en la gura 6.9 de la pgina 190 el asistente para creacin de tablas, que va guiando paso a paso al usuario a travs de una interfaz amigable, permitiendo crear campos de la tabla, denir una clave, denir un ndice y tambien restricciones a la tabla.

190

CAPTULO 6. INTRODUCCIN 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, modicar ndices, etc. Donde un usuario avanzado puede escribir directamente la sentencia y ejecutarla; ver gura 6.10 de la pgina 191. Para usuarios menos avanzados tambin se dispone de un asistente llamado SQL ASSIST que va ayudando al usuario para la realizacin de una consulta.

6.5. DB2 UDB VERSIN 8.1

191

Figura 6.10: Centro de Mandatos.

Captulo 7

WebSphere Studio
7.1 Qu es WebSphere?

IBM WebSphere es una plataforma de IBM para el desarrollo y gestin de sitios web y aplicaciones destinadas al comercio electrnico. 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 estndares abiertos de mercado. WebSphere es ideal para todas las fases de un e-business, comenzando desde pequeos 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). Tambin permite la diferenciacin de niveles de servicio con base en el tipo de cliente. 193

194

CAPTULO 7. WEBSPHERE STUDIO

7.2

Plataforma de Software

La creciente complejidad de los aplicativos de e-business crea muchos desafos. Los aplicativos deben ser escalables, ables y se deben integrar completamente con los sistemas back-end para proteger las inversiones existentes. El equipo de desarrollo debe poseer las ms actualizadas habilidades de programacin para acompaar el ciclo de vida del e-business. Se necesita una plataforma completa, escalable y exible que proporcione soporte a la construccin y diseminacin 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 simplique 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 rpidos de nuevos aplicativos utilizando un paradigma de desarrollo basado en reglas. Proporciona cdigo pre-construido, pre-testeado. Proporciona herramientas especializadas para pginas Web y desarrollo de mdulos migrables. Adicionalmente, servicios basados en estndares Web permiten mezclar y combinar componentes funcionales de diferentes orgenes de tal forma que se puede proveer nuevos procesos y servicios al mercado de manera rpida y eciente. La capacidad de un portal de negocios tiene importancia crtica para permitir que las personas interacten y transaccionen de forma personalizada con diversos recursos de negocios. Empieza dejando a la medida los ambientes de usuarios para sus necesidades especcas, integrndolo entonces con otros usuarios para permitir colaboracin en tiempo real, y con los diversos ambientes de TI. Todo esto permite que las personas trabajen en conjunto de forma ms productiva mientras actan sobre la informacin 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 dicultades en cuanto al tiempo, limitaciones organizacionales o fronteras geogrcas. Con el software With WebSphere Commerce, se establecen relaciones ms estrechas, ms 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 continen maana.

7.2.2

WebSphere for Commerce - Soluciones B2C

El software WebSphere Commerce le permite ir a la lnea de las ventas online a los consumidores. Crea campaas de marketing dinmicas, ja como objetivo diferentes segmentos de mercado, elabora promociones de producto personalizadas, y mejora el servicio a clientes. Esta solucin ayuda a crear rpidamente y mantener ecientemente un sitio interactivo, de alto volumen. WebSphere Commerce proporciona: Personalizacin del B2B para ayudar a administrar las relaciones de negocio. Tecnologa de ventas asistidas para conducir a los clientes y contratistas a travs de la agrupacin de requisitos y del proceso de seleccin del producto. Herramientas de cooperacin online y de formacin de equipo virtual para mejorar la ecacia de contratistas comerciales, canal y clientes. Administracin de pedidos anticipados resultando en capacidades de optimizacin de operaciones.

196

CAPTULO 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 integracin del WebSphere Commerce y WebSphere Portal permite que las empresas se dirijan a mltiples sectores con necesidades de personalizacin positivas de soluciones de comercio tanto para las reas B2B o B2C. Actualmente, muchas empresas crean sitios separados para cada divisin, lo que demanda mucho tiempo y cuesta caro. El abordaje racionalizado proporciona rpido retorno de inversin al eliminar la necesidad de que la empresa mantenga mltiples sitios. Las empresas tambin aumentan la eciencia de interacciones con clientes y contratistas, lo que mejora la retencin del cliente. Los productos IBM WebSphere Commerce y WebSphere Portal proporcionan un nico punto de interaccin con informacin dinmica 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 ecientemente informacin online, servicios y aplicativos para contratistas de negocio y proveedores a lo largo de mltiples divisiones en un portal. Ambientes B2C o de ventas al por menor: obtener ventas cruzadas e impulsar los benecios, mediante la oferta de acceso a productos, informacin y servicios desde la Web y de dispositivos inalmbricos, as como acceso consolidado a catlogos mltiples.

Con un portal de e-commerce integrado, se les puede ofrecer a los clientes, contratistas y proveedores acceso 24x7 a los aplicativos online - rpida y fcilmente.

7.2. PLATAFORMA DE SOFTWARE

197

7.2.4

WebSphere for Commerce-Soluciones Digital Media

Empresas de medios con volmenes crecientes de activos digitales -fotos, vdeo clips, archivos de audio, ilustraciones e imgenes animadas, enfrentan nuevas exigencias reguladoras y el desafo de colocar esos activos disponibles online. El software WebSphere permite administrar estos activos digitales ms ecazmente, alcanzando clientes en todos el mundo a travs 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 tecnologa 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 mrgenes de benecios. WebSphere ofrece un amplio portafolio de soluciones clasicadas en tres reas crticas: 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

CAPTULO 7. WEBSPHERE STUDIO

WebSphere Commerce. Integracin 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 trmino se reere de manera popular a uno de sus productos especcos: 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 estndar APIs del Workbench. La familia del WebSphere Studio tiene actualmente los siguientes miembros (ver gura 7.1 de la pgina 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 comn de herramientas, por ejemplo para el desarrollo Java y Web (ver gura 7.2 de la pgina 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

199

Figura 7.1: La familia del WebSphere Studio.

Figura 7.2: WebSphere Studio, entorno de desarrollo.

200

CAPTULO 7. WEBSPHERE STUDIO

Figura 7.3: La plataforma del Workbench de Eclipse fue diseada por IBM y lanzada a la comunidad de open-source (cdigo abierto). Este Workbench se ha diseado para proveer la mxima exibilidad en el desarrollo de las herramientas y las nuevas tecnologas 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 tambin proporciona la ayuda para cada fase del ciclo de vida del desarrollo. Los lderes 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 integracin de herramientas. Eclipse se ha diseado a partir de la necesidad de Construir, Integrar los desarrollos tiles del uso de las tecnologas. El valor ms importante que tiene esta plataforma es: el rpido desarrollo

7.4.

WEBSPHERE STUDIO APPLICATION DEVELOPER

201

Figura 7.4: Plataforma de Eclipse. de herramienta siendo esta una de las caractersticas basadas en un modelo plug-in (ver gura 7.4 de la pgina 201).

7.4.1

Ventajas de Utilizar a WebSphere Studio Application Developer

La ventaja fundamental consiste en la integracin de todos los entornos de desarrollo Java Web en una nica plataforma de desarrollo. J2EE: Herramientas de importacin/exportacin, generacin de cdigo, edicin de deployment descriptors estandars, extensiones y bindings (mapeos) especcos para WebSphere Application Server (WAS). Herramienta de mapeo EJB-RDB soportanto tanto top-down, como bottom-up y meet-in-the-middle. Herramientas de edicin grca de esquemas de bases de datos.

202

CAPTULO 7. WEBSPHERE STUDIO

Herramientas para la creacin, edicin y validacin de cheros EAR. Editores para deployment descriptors (ejb-jar.xml y application.xml). Desarrollo Java: Nuevo Editor Visual Java para GUIs (Swing y AWT). Nueva generacin de JavaDoc. Soporte JDK 1.3. Capacidad de utilizar diferentes JREs. Compilacin incremental automtica. Posibilidad de ejecutar cdigo incluso con errores. Proteccin contra crashs y auto-recovery. Error Reporting y correccin. Editor Java con asistente contextual. Herramientas de refactoring de cdigo. Bsquedas inteligentes y herramientas para comparar cdigo y merge. Scrapbook para evaluacin rpida de cdigo. Web Services: Nuevo soporte UDDI Version 2. Soporte UDDI privado. Nuevo soporte de WSIL. Posibilidad de crear un web service a partir de un chero ISD. Visualizacin de UDDI business entry para localizacin de web services existentes.

7.4.

WEBSPHERE STUDIO APPLICATION DEVELOPER

203

Creacin de web services a partir de cdigo existente (JavaBeans, RLSs, DB2 XML Extender calls, procedimientos almacenados DB2 y queries SQL). Crear wrappers SOAP y HTTP GET/POST de cdigo existente. Generacin de proxies desde el Web Services Client/Wizard para tratar mensajes SOAP. Generacin de una aplicacin 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 mens pop-up para la creacin y consumo de web services, adems de los tpicos wizards. XML: Entorno totalmente visual. Editor de XML con posibilidades de validacin de documentos. Editor de DTD con posibilidades de validacin de documentos. Editor de XML schemas. Editor de XSL. Debugger de XSL y herramienta de transformacin para aplicar XSL a XML. Editor de mapping XML - XML. Wizard de creacin de XML a partir de queries SQL. Editor de mapping RDB - XML. Desarrollo web:

204

CAPTULO 7. WEBSPHERE STUDIO

Nuevo soporte para XHTML y Struts. Nuevo entorno visual de construccin de aplicaciones basado en struts. Editor visual de HTML y JSPs. Edicin y validacin de JavaScript. Soporte de JSP Custom tags (taglibs) 1.2. Edicin de imgenes y animaciones. Edicin de CSS. Importacin via HTTP/FTP. Exportacin va FTP a un servidor. Visualizacin de links, broken links, etc. Wizards para la creacin de servlets. Wizards para la creacin de proyectos J2EE. Wizards para la creacin de aplicaciones web. Testing y Deployment: Incrementa la productividad de forma muy importante. Entorno ligero de carga rpida. Permite pruebas unitarias locales. Permite debugger de cdigo en el servidor a travs del debugger integrado. Permite congurar 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 ejecucin y ayuda a detectar memory leaks. Muestra informacin de los objetos existentes. Tiene capacidades de Pattern extraction. Es posible monitorizar varios procesos simultneamente, incluso corriendo en diferentes mquinas. Codicacin por colores de las clases. Presentacin de los resultados en modo grco y estadstico. Soporte de proling a nivel de objetos. Anlisis de los logs de WebSphere Application Server e interaccin con la bases de datos de problemas. Edicin de items en la base de datos de problemas. Debugger: Muy similar al existente en VisualAge for Java. Permite realizar debug tanto a cdigo local como a cdigo residente en el servidor.

7.4.2

Desarrollando Aplicaciones Java

Los lineamientos que se deben seguir para crear una aplicacin Java en WebSphere Application Developer son los siguientes: Crear un proyecto Java. Crear paquetes dentro del proyecto. Crear clases.

206

CAPTULO 7. WEBSPHERE STUDIO

Ejecutar el programa. Localizar errores. Para crear un proyecto Java se debe seleccionar archivo Nuevo Proyecto, de desplegar el cuadro de dilogo de Nuevo Proyecto, se debe seleccionar Java y proyecto Java en el dilogo y hacer click en siguiente para iniciar el asistente de creacin de proyectos. Luego se debe indicar en la primer pgina el nombre del proyecto y click en aceptar; (ver gura 7.5 de la pgina 206).

Figura 7.5: Asistente de Proyecto Java. El proyecto es creado con las opciones que se hayan congurado anteriormente en las preferencias o con las que tiene por defecto. Estas preferencias puede ser modicadas dirigiendose al menu Ventana Preferencias y luego Java Proyecto Nuevo. Se pueden agregar paquetes al proyecto para tener una estructura ms ordenada de la aplicacin. Para ello se debe seleccionar en la vista de exploracin de paquetes Nuevo Paquete en el men. En la ventana de dilogo se tiene que indicar el nombre del paquete y hacer clic en nalizar; ver gura 7.6 de la pgina 207.

7.5. WEBSPHERE APPLICATION SERVER

207

Figura 7.6: Paquete Java. Luego de haber nalizado el cdigo y compilado los errores, se puede ejecutar el programa. Se tiene que seleccionar la opcin ejecutar de la barra de herramientas. Si es la primera vez que se ejecuta ese cdigo se abre el dilogo ejecutar conguraciones. Como se puede ver en la gura 7.7 de la pgina 208 se puede seleccionar el tipo de conguracin para ejecutar el programa.

7.5
7.5.1

WebSphere Application Server

Introduccin

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 tecnologas diferentes preservando las inversiones hechas en tecnologa previamente disponible en la organizacin, soporta normas abiertas vigentes en las organizaciones, proporciona soporte pleno a la plataforma abierta Java 2 y Java 2 Enterprise Edition (J2EE) y tambin provee soporte para servicios bajo normas abiertas en la Web [23].

208

CAPTULO 7. WEBSPHERE STUDIO

Figura 7.7: Dilogo de Conguracin de Ejecucin. WebSphere Application Server, es una plataforma de alto desempeo y extrema escalabilidad para diseminar aplicativos dinmicos de e-business, proporciona las funciones esenciales de e-business de manipulacin de transacciones y ampliacin de datos back-end del negocio y aplicativos para la Web. La plataforma ayuda a construir aplicativos que ejecutan esas funciones con seguridad slida, abilidad y escalabilidad.

7.5.2

WebSphere Application Server Como Plataforma Para el Comercio Electrnico

Brinda un soporte amplio para aplicaciones de comercio electrnico. Se caracteriza por su exibilidad 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 (Tecnologa de Informacin), para aprovechar al mximo 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 gura 7.8 de la pgina 209 se puede observar la plataforma del Software de WebSphere para e-bussines.

7.5.3

Application Server - Advanced Edition

La Edicin Avanzada es la oferta del principal servidor de aplicativo dirigido a desarrolladores profesionales de tecnologa Java que necesitan funcionalidad de servicios J2EE y Web para aplicativos dinmicos de e-business. Esta Edicin del WebSphere Application Server, est disponible en tres conguraciones: Edicin Avanzada: Proporciona integracin slida a las bases de datos, middleware orientado a mensajes, y sistemas preexistentes y aplicativos, en conjunto con soporte de agrupacin. Esta conguracin se ajusta a la

210

CAPTULO 7. WEBSPHERE STUDIO

mayora 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 administracin remota. Edicin Avanzada del Single Server : Proporciona el mismo modelo de programacin esencial J2EE y Web Services con administracin simplicada. Esta conguracin interesa a departamentos, negocios de tamao mediano y aplicativos piloto que necesitan un costo bajo, opcin de ejecucin rpida, distribucin de carga de trabajo o administracin remota asociados a administracin de multi-servidor. Edicin Avanzada del IBM WebSphere Application Server, para Linux en zSeries: La Edicin Avanzada del WebSphere Application Server, para Linux en zSeries contina cumpliendo el compromiso de IBM en cuanto a mantener cobertura amplia para plataformas para el WebSphere Application Server. Este producto WebSphere tiene la combinacin potente de un rico conjunto de dispositivos y soporte a estndares abiertos del WebSphere Application Server y el ambiente operacional familiar del sistema operativo Linux. Tambin contiene los recursos de administracin, alta abilidad, y la intensa velocidad de comunicacin de datos internos del hardware de la plataforma zSeries.

7.5.4

Application Server - Enterprise Edition

La Edicin empresarial del IBM WebSphere Application Server, en conjunto con IBM WebSphere Studio Application Developer Integration Edition, ofrece una combinacin potente de tiempo de ejecucin y herramientas que permiten integrar activos IT existentes, mejorar la productividad del desarrollador y crear y mantener aplicativos de e-business exibles. Juntos, el IBMs 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

Coreograar visualmente y componer servicios de la Web y componentes de aplicativo J2EE a travs 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, ecaz en cuanto a costo de tiempo de ejecucin del servidor del aplicativo administrativo y operacional. Evitar la repeticin del desarrollo y diseminacin de aplicativos debido a condiciones cambiantes del mercado, separando las polticas del negocio de la lgica de aplicativos esenciales. Crear una paleta de componentes de aplicativos que puede ser rpidamente montada para desarrollar nuevos aplicativos fcilmente publicada como servicio Web.

7.5.5

Application Server - Standard Edition

La Edicin Estndar para desarrolladores de la web y autores de contenido incluye mejoras de facilidad de uso en toda su extensin, 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 dinmicos 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 conguracin XML de fcil lectura para determinar si la peticin la debe gestionar el servidor Web o el servidor de aplicaciones. Utiliza el protocolo HTTP estndar para comunicarse con el servidor de aplicaciones.

212

CAPTULO 7. WEBSPHERE STUDIO

7.5.7

Servidor de Aplicaciones

El servidor de aplicaciones colabora con el servidor Web intercambiando peticiones de clientes y respuestas de aplicaciones. Puede denir varios servidores de aplicaciones, cada uno de ellos ejecutndose en su propia Mquina Virtual Java (JVM).

7.5.8

Contenedor de EJB

El contenedor de EJB proporciona los servicios de tiempo de ejecucin necesarios para desplegar y manejar componentes EJB, conocidos como enterprise beans. Es un proceso de servidor que maneja peticiones para beans de sesin y beans de entidad. Los enterprise beans (dentro de los mdulos 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 ejecucin 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 recuperacin de datos para los beans que contiene. Un solo contenedor puede gestionar ms 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 presentacin y el control de la interaccin del usuario con los datos de aplicacin subyacentes y la lgica empresarial. El contenedor Web procesa servlets, archivos JSP y otros tipos de inclusiones de servidor. Los servlets anteriores a J2EE se ejecutarn en un motor de servlets. Cada contenedor Web contiene automticamente un nico gestor de sesiones.

7.5. WEBSPHERE APPLICATION SERVER

213

Cuando se manejan los servlets, el contenedor Web crea un objeto de peticin y un objeto de respuesta, e invoca el mtodo de servicio de servlets. El contenedor Web invoca el mtodo destroy() del servlet cuando corresponda y descarga el servlet, y despus la JVM ejecuta la recoleccin 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 grca 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 mquinas cliente. Este programa sigue el mismo modelo de programacin Java que otros programas Java; no obstante, el cliente de aplicaciones J2EE depende del tiempo de ejecucin del cliente de aplicaciones para congurar su entorno de ejecucin, 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 conguracin que permite que una nica mquina de sistema principal parezca varias mquinas 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 mquina fsica. Los sistemas principales virtuales permiten al administrador asociar aplicaciones Web con un sistema principal particular congurado para la mquina que ejecuta la aplicacin.

7.5.12

Virtual Hosts (Hosts Virtuales)

Un host virtual es una conguracin que permite a una sola mquina host aparentar ser mltiples mquinas hosts. Permite que una sola mquina fsica

214

CAPTULO 7. WEBSPHERE STUDIO

congure y administre independientemente varias aplicaciones administradas. No est asociado a un nodo particular (mquina). Es una conguracin, diferente de un objeto vivo, indicando que puede crearse, pero no arrancarse o detenerse. Cada host virtual tiene un nombre lgico y una lista de uno o ms seudnimos de DNS por los cuales es conocido. Un seudnimo de DNS es el nombre TCP/IP del host y el nmero del puerto que use la peticin del servlet, por ejemplo su nombre Host:80. El WebSphere Application Server proporciona un host virtual predenido, denominado el default_host, con algunos seudnimos comunes, como el IP de la mquina, nombre corto del host, y el nombre del host completo. El seudnimo comprende la primera parte del camino para el acceso a un recurso, como un servlet. Por ejemplo, localhost:80 en la peticin http://localhost:80/servlet/snoop. Los hosts virtuales le permiten al administrador aislar y manejar independientemente los mltiples grupos de recursos en la misma mquina fsica.

7.6

Workplace Client Technology Micro Edition

Workplace Client Technology Micro Edition (WCTME) es una plataforma intergrada para la extensin de aplicaciones empresariales existentes hacia dispositivos clientes manejados por servidor como ser un computador de escritorio, sistemas mviles, PDAs, y otros dispositivos mviles y pervasivos. El paquete integrado combina las herramientas WebSphere Studio Device Developer y Micro Environment Toolkit for WebSphere Studio, con los tiempos de ejecucin 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 telfonos celulares, PDAs y otros dispositivos con teclado, mviles 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 programacin usando los estndares de la industria y sin tener que volver a reescribir todo usando estos dispositivos. La plataforma WCTME est construida como una combinacin de una plataforma cliente rica basada en el modelo de Eclipse (originalmente ideado para herramientas, y motivado para ser una plataforma de aplicacin ms genrica) al igual que el modelo basado en navegador. Eclipse es una plataforma para la construccin 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 implementacin de IBM de la especicacin J2ME que cumple con la autorizacin y lneas guas funcionales denidas por Sun Microsystem para obtener Java Powered Logos.

7.6.2

WebSphere Everyplace Custom Environment

Everyplace Micro Enviroment, WebSphere Everyplace provee un conjunto mayor de libreras y funciones para asociados a crear versiones ms a medida de la Java sin necesariamente tener que cumplir con estndares

Similar a Websphere Custom Environment habilitar a clientes y run times especca, establecidos.

7.6.3

J9

La J9 es una implementacin independiente de IBM de la Maquina Virtual de Java. La combinacin de la J9 junto con la conguracin y los perles conforman el ambiente de ejecucin o run times. Las conguraciones y perles son libreras 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

CAPTULO 7. WEBSPHERE STUDIO

dispositivos pervasivos, y forma el ncleo 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 estndar que entrega el poder y los benecios de la tecnologa Java a medida para los dispositivos embebidos, incluyendo interfaces de usuario exibles, 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, depuracin y despliegue de aplicaciones que sern lanzadas en computadoras de mano y otros dispositivos pequeos [24]. Esto ayuda a los desarrolladores a crear aplicaciones que habilitan a los dipositivos (telfonos celulares, PDAs, y computadoras de mano) a formar parte de una solucin e-businnes end-to-end. El entorno de desarrollo integrado tambin 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

217

7.7.1

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 ms el SmartLinker para el preenlazado de archivos .class en la aplicacin. J9 Runtimes, Utilidades y Herramientas El WebSphere Studio Device Developer incluye como componentes a un paquete de J9 runtimes, utilidades y herramientas, para construccin 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 perlar y analizar la ejecucin de los programas en un dispositivo embebido. En la vista Analizer se pueden agregar eventos de usuario al cdigo y rastrear su ejecucin en una prueba fsica corriendo en una maquina virtual J9. Esta informacin puede ser usada para optimizar los programas en cuanto a velocidad, tamao y eciencia global.

7.7.2

Herramienta de Desarrollo C (CDT) para Eclipse

Device Developer incluye el CDT (C Development Tooling) de Eclipse que permite escribir cdigo 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

CAPTULO 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 comn, el WebSphere Studio Workbench (WSWB ), que es la versin de IBM de la plataforma Eclipse. Eclipse es un IDE de cdigo abierto (open-source). Utiliza un plug-in diseado para ampliar su funcionalidad bsica, ya que solo hace muy poco. Debido a que es de cdigo abierto, se podr contribuir a su desarrollo. Peridicamente, IBM toma una instantnea de Eclipse y los distribuye como el WebSphere Studio Workbench, que est diseado para ser una plataforma de desarrollo para socios de negocio para ampliar la arquitectura bsica y complementos. Estas herramientas tambin deben ser capaces de conectar a Eclipse, as como los miembros de la familia de productos de WebSphere Studio.

7.7.4

Utilizacin del IDE

WebSphere Studio Device Developer utiliza el concepto de espacio de trabajo o workspace, un directorio que contiene el cdigo de trabajo (un subdirectorio por cada proyecto), y un subdirectorio de metadatos que contienen informacin sobre el cdigo. La creacin de un acceso directo es importante cuando se desee utilizar mltiples espacios de trabajo, puesto que se puede usar la bandera -data para poner un especco espacio de trabajo en ejecucin, 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 tambin utiliza el concepto de proyecto, una coleccin de paquetes que componen la totalidad de una aplicacin, 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 acta como un archivo readme para la versin de la herramienta, y se muestra automticamente la primera vez que se invoca

7.7. WEBSPHERE STUDIO DEVICE DEVELOPER

219

Figura 7.9: Barra de herramientas de WSDD.

el producto. Tambin 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 coleccin predenida 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 gura 7.9 de la pgina 219). Los asistentes se pueden utilizar para crear aplicaciones, probar cdigo, crear estructuras Java, crear proyectos, crear dispositivos, congurar dispositivos, generar construcciones de un proyecto para su distribucin. La barra izquierda de herramientas contiene todas las perspectivas y / o vistas abiertas.

220

CAPTULO 7. WEBSPHERE STUDIO

Perspectiva, Editores y Vistas

Una perspectiva es un grupo de vistas y editores en la ventana del espacio de trabajo diseadas 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. Tambin se puede personalizar perspectivas y guardarlas. Una vista es un componente visual del espacio de trabajo. Se suele utilizar para navegar en una jerarqua de informacin (como los recursos del espacio de trabajo), abrir un editor o visualizar propiedades del editor activo. Las modicaciones efectuadas en una vista se guardan inmediatamente. Slo puede existir una instancia de un tipo de vista concreto en una ventana del espacio de trabajo. Un editor se utiliza para modicar los archivos, y es especco para el tipo de archivo que est siendo editado. Con WebSphere Studio Device Developer, se puede especicar editores externos para determinados tipos de archivo. Slo un editor puede estar activo en cualquier momento, varios editores se podrn abrir, pero todos estarn en la misma ventana, disponible a travs de pestaas. El editor del cdigo 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 cdigo fuente de la clase con todos sus elementos. Pero adems incluye diversas funcionalidades para ayudar al desarrollador, entre ellas se tiene:

7.7. WEBSPHERE STUDIO DEVICE DEVELOPER

221

Figura 7.10: Mtodos 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 identicar ms fcilmente una lnea de texto o una instruccin. Muestra los campos y mtodos pertenecientes al objeto al que se est haciendo referencia segn se va escribiendo (ver gura 7.10 de la pgina 221). De esta forma, se puede elegir el que se quiera a travs de la lista. Adems, en la lista de mtodos de los objetos, se indican los parmetros necesarios en la llamada al mismo, y el tipo del valor que devuelve, junto con una breve descripcin del mismo. Incluye una funcin automtica para cerrar parntesis y corchetes. En caso de cometer algn error de sintaxis, remarca la parte de cdigo errnea en rojo. Utiliza advertencias que son subrayados amarillos. Las advertencias no sern causa de error, pero ayudan a mejorar el cdigo; por ejemplo, importar alguna clase que no se utilice nunca.

Dispositivos Cada dispositivo requiere una conguracin separada. Todos los dispositivos se comparten, por lo que cualquier proyecto puede ser desplegado en un dispositivo especco.

222

CAPTULO 7. WEBSPHERE STUDIO

WebSphere Studio Device Developer soporta dispositivos Palm (a travs de HotSync), emulador Palm, y dispositivos PocketPC (a travs de ActiveSync) directamente. WebSphere Studio Device Developer tambin ejecutar proyectos a nivel local JVM, y aplicaciones MIDP pueden ser desplegados en un emulador MIDP. Otros proveedores pueden incluir emuladores soportados a travs de plugins Eclipse. Estos deben estar disponibles a travs del gestor de actualizaciones, o directamente desde el proveedor. Aadir Emuladores Una manera de probar las aplicaciones que se disean es aadiendo emuladores que proveen los fabricantes. Webphere Studio Device Developer permite aadir emuladores de distintos fabricantes.

Captulo 8

Descripcin de la Aplicacin
8.1 Introduccin

El presente trabajo consiste en la creacin de una aplicacin con Software de Computacin Mvil Multiplataforma, que permita el acceso a informacin situada en bases de datos multiplataforma en un servidor Web, a travs de dispositivos mviles tales como PDAs. El objetivo esencial de este trabajo es llevar a la prctica la comunicacin 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 concepcin llevada a la realidad de lo que podra ser un sistema comercial para un restaurant, aplicando las ltimas tecnologas para lograr as no solo alcanzar el objetivo principal sino tambin proveer de ventajas competitivas en el rubro para aqul restaurant que utilice sistemas de este tipo. El sistema realizado pretende reducir los tiempos requeridos en la atencin al cliente dentro del restaurant, cubriendo la mayor parte de operaciones esenciales requeridas por una entidad dedicada a la gastronoma. Para el desarrollo del trabajo se utiliz el lenguaje de programacin Java, debido a que sus caractersticas lo hacen adecuado para el propsito planteado: seguridad, robustez y sobre todo, portabilidad. La variedad de dispositivos existentes en el mercado condiciona que la apli223

224

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

cacin deba ser compatible con todos ellos. Como es conocido, la portabilidad es una de las caractersticas inherentes al lenguaje Java.

8.2

Estructuracin

El sistema est compuesto por dos mdulos principales, uno mvil 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 tambin un tercer mdulo que simula ser el sitio web de un restaurant cticio llamado Miarritze para completar el ideal de lo que debera ser un sistema para un restaurant. Los mdulos principales J-Chef y MobileChef corrern en la Intranet del restaurant, y las comunicaciones se realizarn a travs de una conexin inalmbrica wi-. El sistema est pensado para que trabaje con distintos tipos de perles de usuario, donde cada perl tendr funciones especcas de acuerdo al cargo que representan los usuarios. A continuacin se vern los distintos perles de usuario y a que mdulos pertenecen: Mdulo Intranet J-Chef : Administrador. Jefe de Cocina. Cajero. Mdulo Mvil MobileChef : Mozo. Mdulo Internet Miarritze: Administrador Web. Cliente Web. El sistema principal est formado por los mdulos J-Chef y MobileChef, por lo tanto se muestra en la gura 8.1 de la pgina 225 los casos de uso que involucran a los usuarios de ambos mdulos.

8.2. ESTRUCTURACIN

225

Figura 8.1: Casos de uso del Sistema Principal. J-Chef y MobileChef.

226

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.2: Casos de Uso del mdulo Miarritze. En la gura 8.2 de la pgina 226 se muestran los casos de uso con respecto a los usuarios del mdulo 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 continuacin se detallar el modelo de datos del sistema principal, el mismo se puede apreciar en la gura 8.3 de la pgina 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 vern los campos que conforman cada tabla. CONFIGURACIONES: Esta tabla contiene las conguraciones necesarias para el correcto funcionamiento del sistema. Por ejemplo la fecha de ltima modicacin del men y tambin la cantidad de mesas con las que operar el sistema, los campos que la componen son los siguientes.

228

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

ID_CONF: Es el campo clave de la tabla. Contiene el nmero nico de la conguracin. NOMBRE_CONF: Es el nombre que se le da a la conguracin. VALOR_CONF: Es el dato propiamente dicho de la conguracin. 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 nmero 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 identicador nico de cada usuario. CARGO: Acta como clave fornea estableciendo la relacin 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 pseudnimo que el usuario utilizar para logearse al sistema. PASS: Es la contrasea 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 nalizacin de la jornada laboral del usuario. TELEFONO: Es el nmero de telfono del usuario.

8.3. MODELO DE DATOS

229

DNI: Es el nmero del Documento Nacional de Identidad del usuario. MAIL: Es la direccin 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 identicador del tipo de tem de men. NOMBRE_TIPO: Contiene el nombre del tipo de tem de men. CATEGORIAS: Contiene las distintas categoras de los tems de men, est compuesta por los siguientes campos. ID_CAT: Es el campo clave de la tabla. Es el identicador de la categora a la cual pertenece un tem de men. ID_TIPO: Es la clave fornea que relaciona la tabla CATEGORIAS con TIPO_ITEM_MENU. NOMBRE_CAT: Es el nombre de la categora. SUB_CATEGORIAS: Contiene las distintas sub categoras de los tems de men. Est compuesta por los siguientes campos. ID_SUB: Es el campo clave de la tabla. Es el identicador nico de la sub categora. ID_CAT: Funciona como clave fornea estableciendo la relacin con la tabla CATEGORIAS. NOMBRE_SUB: Es el nombre de la sub categora.

230

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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 identicador nico de cada tem. ID_CAT: Es una clave fornea que relaciona esta tabla con CATEGORIAS. ID_SUB: Es una clave fornea que relaciona esta tabla con SUB_CATEGORIAS. NOMBRE_ITEM: Es el nombre del tem de men. DESCRIPCION: Es la descripcin 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 identicador nico de un pedido. ID_MOZO: Acta como clave fornea estableciendo la relacin con la tabla USUARIOS, e identica al usuario con cargo mozo que ha levantado el pedido. MESA_NRO: Es el nmero 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 da 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 identicador nico de un detalle de pedido. ID_PEDIDO: Acta como clave fornea estableciendo la relacin con la tabla PEDIDOS_CABECERA. ID_ITEM: Acta como clave fornea estableciendo la relacin 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 algn tipo de observacin que haya realizado un cliente acerca del tem de men que solicit. ESTADO: Es el estado de un detalle de pedido. A continuacin se detallar el modelo de datos del sitio web Miarritze, el mismo se puede apreciar en la gura 8.4 de la pgina 231. La base de datos del mismo tiene por nombre WEBCHEF y las entidades que la componen son las siguientes:

232

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

CONFIGURACIONES. USUARIOS. TIPO. CATEGORIAS. SUB_CATEGORIAS. ITEM_MENU. RESERVA_CABECERA. RESERVA_DETALLES. Ahora se vern los campos que conforman cada tabla. CONFIGURACIONES: Esta tabla contiene las conguraciones necesarias para el correcto funcionamiento del sistema. Por ejemplo la direccin 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 nmero nico de la conguracin. NOMBRE_CONF: Es el nombre que se le da a la conguracin. VALOR_CONF: Es el dato propiamente dicho de la conguracin. 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 identicador nico de cada usuario web. TIPO_USUARIO: Identica el tipo de usuario, si es un administrador o un cliente. USUARIO: Es el pseudnimo con el que el usuario se va a logear.

8.3. MODELO DE DATOS

233

PASS: Es la contrasea 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 telfono 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 identicador del tipo de tem de men. NOMBRE_TIPO: Contiene el nombre del tipo de tem de men. CATEGORIAS: Contiene las distintas categoras de los tems de men, est compuesta por los siguientes campos. ID_CAT: Es el campo clave de la tabla. Es el identicador de la categora a la cual pertenece un tem de men. ID_TIPO: Es la clave fornea que relaciona la tabla CATEGORIAS con TIPO. NOMBRE_CAT: Es el nombre de la categora. SUB_CATEGORIAS: Contiene las distintas sub categoras de los tems de men. Est compuesta por los siguientes campos. ID_SUB: Es el campo clave de la tabla. Es el identicador nico de la sub categora. ID_CAT: Funciona como clave fornea estableciendo la relacin con la tabla CATEGORIAS. NOMBRE_SUB: Es el nombre de la sub categora.

234

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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 identicador nico de cada tem. ID_CAT: Es una clave fornea que relaciona esta tabla con CATEGORIAS. ID_SUB: Es una clave fornea que relaciona esta tabla con SUB_CATEGORIAS. NOMBRE_ITEM: Es el nombre del tem de men. DESCRIPCION: Es la descripcin 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 identicador nico de una reserva. COD_USUARIO: Acta como clave fornea estableciendo la relacin con la tabla USUARIOS, e identica 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. DESCRIPCIN DE MOBILECHEF

235

ID_DET_RESERVA: Es el campo clave de la tabla. Es el identicador nico de un detalle de reserva. ID_RESERVA: Acta como clave fornea estableciendo la relacin con la tabla RESERVA_CABECERA. ID_ITEM: Acta como clave fornea estableciendo la relacin 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

Descripcin de MobileChef

La interfaz grca de MobileChef es una interfaz simple, permite una fcil interaccin con el usuario, es estndar para todos los PDAs que soportan J2ME. Por razones de que se trata de una aplicacin 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 esttica depende exclusivamente del SO del dispositivo donde se ejecute. Para ms informacin acerca de interfaces grcas ver captulo cinco (J2ME). Otro aspecto muy interesante a la hora de desarrollar una aplicacin mvil utilizando J2ME es poder almacenar localmente cierta informacin til en el PDA para no tener que volver a realizar una peticin al servidor sobre datos solicitados anteriormente. MobileChef proporciona la posibilidad de almacenar cierto tipo de informacin (como ser la totalidad de tems de men, categoras y sub categoras, como tambin ciertas conguraciones) en la zona de almacenamiento persistente del PDA. Para implementar esta funcionalidad, utiliza el sistema de gestin de registros, conocido como Record Management System (RMS). Ms adelante se describir con ms detalle la estructura de estos registros. MobileChef posee conectividad con un servidor Web, para lograr esto utiliza una conexin wi-. Y al ser un dispositivo con capacidades limitadas

236

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

de almacenamiento y procesamiento la aplicacin minimiza el intercambio de datos. Esto quiere decir que el PDA debe poseer conectividad wi- como requisito para poder utilizar el sistema y por supuesto poder ejecutar aplicaciones Java. Como se ha mencionado en el captulo cinco (J2ME) las aplicaciones que se desarrollan bajo la conguracin CLDC (Conected Limited Device Conguration) y el perl MIDP (Mobile Information Device Prole) se denominan MIDlets. Por lo tanto como MobileChef se desarroll bajo la conguracin CLDC 1.1 y el perl MIDP 2.0 es un MIDlet. En el desarrollo del sistema principal (J-Chef y MobileChef ) se estableci que la utilizacin 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 gura 8.5 de la pgina 237 se ve la pantalla de Aplicaciones en una Palm TX, en esta pantalla puede observase el icono de la aplicacin MobileChef. La gura 8.6 de la pgina 238 representa la pantalla inicial de MobileChef. Esta pantalla inicial ofrece al usuario, tres posibles acciones, estas son: Entrar. Conguracin. Salir. Si el usuario presiona con el stylus el botn Salir, el aplicativo se cierra y el usuario vuelve a ver la pantalla de la gura 8.5 de la pgina 237. Antes de empezar a utilizar MobileChef, es necesaria una conguracin correcta del aplicativo, entonces si el Mozo presiona con el stylus el botn Conguracin podr observar una pantalla como la que se ve en la gura 8.7 de la pgina 239. Cuando esta pantalla se ejecuta por primera vez en el dispositivo mvil, se crea un Record Store llamado ConfCon, en el cual se almacenan datos por defecto a n de establecer los campos necesarios de la

8.4. DESCRIPCIN DE MOBILECHEF

237

Figura 8.5: Pantalla de Aplicaciones de una Palm TX con SO Garnet 5.4.9.

238

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.6: Pantalla Inicial de MobileChef.

8.4. DESCRIPCIN DE MOBILECHEF

239

Figura 8.7: Pantalla de Conguracin de MobileChef. conguracin 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 direccin IP y el Puerto correspondientes para que la conexin 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 modicacin del men: Se almacena la fecha que se obtiene al lanzar la pantalla por primera vez. Nmero de mesas: 10

240

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.8: Pantalla Default Settings.

Esta pantalla ofrece tres opciones al usuario: Guardar, Default Settings y Volver. Si el usuario presiona Guardar se actualizarn los campos en el Record Store ConfCon. Si el usuario presiona Default Settings, se cargarn los datos de ejemplo, con una leyenda comunicando que estos datos son solo un ejemplo de lo que el usuario debera introducir en estos campos como se puede observar en la gura 8.8 de la pgina 240. Si el usuario presiona Volver, volver a ver la pantalla inicial de la gura 8.6 de la pgina 238. Ahora bien, si el usuario presiona Entrar ver la pantalla que se muestra en la gura 8.9 de la pgina 241, la cual representa el inicio del proceso de login.

8.4. DESCRIPCIN DE MOBILECHEF

241

Figura 8.9: Inicio del Proceso de Login.

242

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.10: Pantalla de Alerta. En este punto se pueden dar diversas situaciones que se detallarn a continuacin. Si el usuario presionara Entrar cuando alguno de los campos est vacio, el aplicativo mostrara una alerta como la que se ve en la gura 8.10 de la pgina 242, indicando el error. Ahora bien, suponiendo que el usuario ha llenado los campos correctamente, en este punto se iniciara la conexin con la red wi-, este proceso de conexin puede verse en el ltimo ejemplo del captulo cinco (J2ME). Pero aunque el usuario haya llenado correctamente los campos Usuario y Contrasea, puede haber olvidado congurar previamente el aplicativo, por lo que si durante el proceso de login, el aplicativo no puede conectarse al mdulo J-Chef que se encuentra en el servidor, MobileChef mostrar una pantalla como la Pantalla 1 de la gura 8.11 de la pgina 243. Supongamos ahora, que el usuario ha congurado correctamente el aplica-

8.4. DESCRIPCIN 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 vlidos. En esta situacin MobileChef informar al usuario que intenta logearse con una pantalla como la Pantalla 2 que vemos en la gura 8.11 de la pgina 243 donde se aprecia el mensaje que dice que los datos ingresados no coinciden con los registrados. Otra posibilidad es que algn 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 gura 8.11 de la pgina 243. Ahora veremos el desenlace que debera ser el habitual, es decir, un Mozo que ha congurado 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 gura 8.12 de la pgina 244. Donde en la pantalla se van aadiendo cadenas de texto que van informando al usuario en que etapa del proceso de login se encuentra en cada

244

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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 Categoras, y Sub Categoras en sus respectivos Record Stores. Ms adelante se explicarn 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 modicacin del men que se registr en el Record Store ConfCon contra la Fecha de ltima modicacin 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 Categoras, Sub Categoras e tems de men que se leen de la base de datos CHEFDB. Tambin se actualiza el nmero de mesas con las que trabajar el restaurant.

8.4. DESCRIPCIN 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 gura 8.13 de la pgina 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 gura 8.14 de la pgina 246. All deber seleccionar primero un nmero de mesa, y luego seleccionar Comidas o Bebidas segn lo que solicite el cliente en ese momento. Si el mozo selecciona Comidas o Bebidas y no ha seleccionado un nmero de mesa, el aplicativo muestra una pantalla de error diciendo que debe seleccionar primero el nmero de mesa.

246

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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. DESCRIPCIN DE MOBILECHEF

247

Figura 8.15: Levantar Pedido.

Supongamos que el mozo ha seleccionado la Mesa Nmero 1, y luego Comidas, lo que ver inmediatamente despus, sern las Categoras que se corresponden con el Tipo Comidas, esto se puede apreciar en Pantalla 1 de la gura 8.15 de la pgina 247. Luego el mozo debe seleccionar una de esas categoras, para poder ver los tems de men que se corresponden con la misma. Supongamos que el mozo ha seleccionado Plato Principal, esta Categora, posee Sub Categoras, las cuales se observan en Pantalla 2 de la gura 8.15 de la pgina 247. Luego supongamos que el mozo selecciona la Sub Categora Carnes, en ese momento se realiza la bsqueda de los tems de men en el Record Store que los almacena, y se obtienen solo aquellos que se corresponden a esa Sub Categora, como se ve en Pantalla 3 de la gura 8.15 de la pgina 247. Luego el mozo, deber seleccionar el tem que ha solicitado el cliente, y ver una pantalla que describe la informacin de dicho tem, esto puede verse en Pantalla 1 de la gura 8.16 de la pgina 248. All podr ingresar observaciones que provee el cliente, y tambin la cantidad de dicho tem, ya que varios comensales de la misma mesa podran pedir el mismo tem. Luego, si presiona Cargar, este tem se carga en un array localmente,

248

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.16: El item se ha cargado de manera local.

esto se puede ver en Pantalla 2 de la gura 8.16 de la pgina 248, es decir, en ese momento todava no se enva la orden al servidor, esto es porque el mozo puede seguir cargando tems a la orden. Si el mozo presiona Atrs, podr por ejemplo cargar del mismo modo una Bebida, y la orden podra quedar como se muestra en la gura 8.17 de la pgina 249. Antes de enviar el pedido al servidor, el mozo tiene la posibilidad de editar el mismo. Si el mozo presiona el botn (...) que se ve en Pantalla 2 de la gura 8.16 de la pgina 248, se desplegar un men como el que se ve en Pantalla 1 de la gura 8.18 de la pgina 250. Pudiendo as realizar la edicin del pedido como se describe en las pantallas que muestra la gura de la pgina. Aqu podr editar o quitar esa orden del pedido. En Pantalla 2 de la gura 8.18 de la pgina 250 se muestra una lista con las ordenes que componen al pedido de la mesa en cuestin, el mozo podr

8.4. DESCRIPCIN DE MOBILECHEF

249

Figura 8.17: Items de una Orden.

250

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.18: Editar Pedido. seleccionar aquel tem que desea modicar o quitar del pedido. Una vez que el mozo haya nalizado de cargar las ordenes que solicitaron los clientes, el pedido se puede enviar, presionando el botn Enviar que se ve en la descripcin del pedido, esto se muestra en la gura 8.17 de la pgina 249. Hasta este momento se haba realizado solo una comunicacin entre MobileChef y J-Chef que se encuentra en el servidor. Cuando el mozo presiona enviar se establece una nueva comunicacin con J-Chef para que este cargue en la base de datos CHEFDB los datos correspondientes al pedido recientemente levantado, si la transaccin se complet correctamente el mozo recibir como respuesta una pantalla como la que muestra la gura 8.19 de la pgina 251, de otro modo recibir una pantalla informando el error.

8.4.2

Ver Pedidos

En esta seccin el mozo puede ver las mesas para las cuales l mismo ha levantado pedidos, y puede ver tambin los pedidos de cada mesa. Si el mozo presiona en el men principal Ver Pedidos, esto inicia una

8.4. DESCRIPCIN DE MOBILECHEF

251

Figura 8.19: El envo de los datos se realiz correctamente.

252

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.20: Mesas con pedidos del mozo.

comunicacin con J-Chef, el cual consultar la base de datos para recuperar aquellas mesas con pedidos del mozo que inicio la comunicacin. 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 gura 8.20 de la pgina 252. Si el mozo al momento de solicitar este comando tuviese mesas con pedidos, recibir un listado de los nmeros de mesa con pedidos, como se ve en Pantalla 2 de la gura 8.20 de la pgina 252. Si el mozo tiene mesas para atender, podr ver los pedidos de las mismas y podr agregar nuevas ordenes al pedido. Tambin 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. DESCRIPCIN DE MOBILECHEF

253

Figura 8.21: El Administrador ha atendido una Reserva y la ha convertido en Pedido Activo. opcin se da cuando el Administrador ha atendido una reserva y la pas al sistema como un pedido activo. Esta situacin puede verse en la gura 8.21 de la pgina 253. Ntese que cada orden que conforma un pedido, posee entre parntesis a su extremo derecho, su estado actual. Si dicho estado es Abierto el mozo tambin podr modicar 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

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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 podrn 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 gura 8.22 de la pgina 254. El mozo cerrar un pedido cuando el cliente Pida la Cuenta, es decir

8.4. DESCRIPCIN DE MOBILECHEF

255

Figura 8.23: Formulario donde se capturan los datos necesarios para la posterior Facturacin.

marca la nalizacin 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 gura 8.23 de la pgina 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 cuestin. 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 facturacin este pedido aparecer en la pantalla del Cajero.

256

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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 facturacin del pedido, recibir una respuesta como la que muestra la gura 8.24 de la pgina 256, esto si se ha nalizado la transaccin 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 implementacin del sistema de gestin de registros (RMS) se puede guardar informacin en el PDA. Sabiendo que los registros de un Record Stores estn formados por pares tipo clave - valor, donde:

8.4. DESCRIPCIN DE MOBILECHEF

257

Clave: es el identicador 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 conguracin, 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 continuacin con los datos por defecto que se asignan: IP del Servidor: 192.168.1.101 Puerto: 9080 Fecha de ltima modicacin del men: se ingresa la fecha en que se ejecut por primera vez la pantalla de Conguraciones. Cantidad de mesas: 10 Luego estos son editados con los valores correctos. Al chequear la Fecha de ltima modicacin del men, si esta no coincide con la Fecha de ltima modicacin del men que se encuentra en el servidor, se deben cargar los Record Stores Categorias, SubCategorias e ItemsMenu. Record Store Categoras:

258

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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 ujos 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. DESCRIPCIN DE J-CHEF

259

8.5

Descripcin de J-Chef

J-Chef se desarroll con el lenguaje de programacin Java, utilizando las tecnologas 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 grca se ha buscado que la misma sea atractiva pero lo sucientemente sencilla para facilitar la usabilidad del sistema. Es decir, se ha optado por ejemplo el diseo de mens de navegacin jos y no desplegables, ya que estos ltimos son muy atractivos pero muchas veces incmodos, y debido a que este ser un sistema de uso muy frecuente por los mismos usuarios, se ha optado por establecer mens jos e intuitivos.

8.5.1

Estructura de J-Chef

Como se ha explicado anteriormente, J-Chef esta desarrollado para soportar distintos perles de usuario, donde cada perl tendr su propio panel del sistema donde debe realizar su trabajo. Los distintos tipos de usuarios que utilizarn 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 gura 8.25 de la pgina 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 gura 8.26 de la pgina 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 travz de J-Chef, inclusive los mozos. Los usuarios son dados de Alta por el Administrador, ms adelante se explicar en detalle el proceso.

260

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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. DESCRIPCIN 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. Contrasea: 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 gura de la pgina, donde deber seleccionar su Usuario y Contrasea que desea utilizar para los posteriores ingresos al sistema. Si los datos que ha seleccionado el nuevo usuarios son vlidos, recibe un mensaje comunicando que ha seleccionado correctamente sus datos de Usuario y Contrasea, si se produce algn tipo de error, es decir, si ya existe ese usuario o esa contrasea, 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 perles de usuario.

262

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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 gura 8.28 de la pgina 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 estadsticas. A continuacin se explicar cada uno. Administrador usuarios : Al presionar el link usuarios se podr ver la pantalla que se muestra en la gura 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 gura 8.30 de la pgina 264, al presionar el botn cargar, el usuario se almacena en la base de datos, en sus campos

8.5. DESCRIPCIN DE J-CHEF

263

Figura 8.29: Usuarios. Usario y Contrasea se grabarn su Nombre y DNI respectivamente. Si se presiona Editar Usuario se podr ver una pantalla como la que se describe en la gura 8.31 de la pgina 264. Si se presiona el botn modicar 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 edicin. Administrador men : u 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 gura 8.32 de la pgina 265. En esta seccin cualquier accin que lleve a cabo el administrador es decir, Alta, Baja o Modicacin de algn tem, produce la actualizacin inmediata de la Fecha de ltima modicacin del men.

264

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.30: Nuevo Usuario

Figura 8.31: Se debe seleccionar el usuario a editar.

8.5. DESCRIPCIN DE J-CHEF

265

Figura 8.32: Gestin del Men.

Este valor de conguracin 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 gura 8.33 de la pgina 266. En esta pantalla se ha congurado mediante javascript una serie de cajas de seleccin enlazadas para seleccionar el tipo, categora y eventualmente sub categora si corresponde, de tem de men que se desea ingresar, luego de realizar las selecciones correspondientes se habilitarn los campos donde se introducirn los datos del nuevo tem, esto se ve en la gura 8.34 de la pgina 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 mostrarn las pantallas de la edicin. Al presionar Editar Item de Men se podr observar una pantalla como la que muestra la gura 8.35 de la pgina 267. En esta seccin se ha implementado una llamada asncrona AJAX.

266

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.33: Nuevo Item de Men.

Figura 8.34: Luego de seleccionar Tipo, Categora y Sub Categora se habilitan los campos a rellenar para el nuevo tem de men.

8.5. DESCRIPCIN DE J-CHEF

267

Figura 8.35: Editar Item de Men.

268

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Cuando el administrador selecciona una categora o una sub categora dependiendo de que la categora tenga o no sub categoras, en ese momento cuando la caja de seleccin detecta un cambio lanza la ejecucin de una funcin javascript para realizar el procedimiento AJAX, y as recuperar los tems de men correspondientes. Para esta llamada se ha utilizado la librera javascript jQuery, la cual cuenta con la funcin $.getJSON(), con esta funcin se realiza la llamada asncrona. Esta llamada diere de lo que sera un AJAX tradicional, es decir aquella que obtiene como respuesta una porcin de cdigo 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 asncrona obtiene una porcin de cdigo HTML y la inserta en un contenedor dentro de la pgina desde la cual se ha iniciado dicha llamada. Esto tiene como benecio que no se debe recargar toda una pgina sino que se carga solo una porcin de la misma, mejorando as la performance de un sitio web ya que reduce el proceso del servidor. En el caso de la funcin $.getJSON() de jQuery, lo que obtiene como resultado es un String con una estructura determinada, y no una porcin de cdigo HTML. Al recibir el String respuesta, esta funcin, la cual se encuentra en la pgina web que el administrador est viendo en el browser de una mquina cliente, parsea dicho String y con cdigo 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 pgina donde se incio la llamada. Este mtodo resulta an ms efectivo que el mtodo tradicional debido a que el proceso del armado del cdigo HTML es realizado en la mquina cliente, es decir, si libera an mas al servidor. El String respuesta recibido tiene una estructura similar a la siguiente:
({ items: [

8.5. DESCRIPCIN 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, morrn picado, tomate, perejil picado, precioItem: 52.87}, { idItem: 9, categ: Plato Principal, subcateg: Carnes, nombreItem: Solomillos de cerdo, descipcionItem: Solomillos de cerdo con qunoa estilo risotto y lminas de gruyere, precioItem: 49.62}, { idItem: 10, categ: Plato Principal, subcateg: Carnes, nombreItem: Colita de cuadril rellena, descipcionItem: Colita de cuadril, queso crema, jamn cocido, tomate, papines, batata, portobelos y rcula, 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 estadsticas : Al clickear sobre estadsticas aparecer un submen compuesto por los siguientes links: Ver Usuarios, Ver Men y Ver Facturacin como se ve en la gura 8.36 de la pgina 270. Cada uno de estos links a su vez tendr subsubmens, en la gura 8.37 de la pgina 270 se ve la pantalla que se obtendra al presionar la siguiente ruta, estadsticas - Ver Usuarios - Ver Todos.

270

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.36: Gestin de Estadsticas.

Figura 8.37: Todos los Usuarios.

8.5. DESCRIPCIN DE J-CHEF

271

Ahora se explicarn las posibilidades de extraccin de estadsticas disponibles en J-Chef. Ver Usuarios. Esta opcin 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 la, se dispone de un link Ver, este mostrar los datos completos del usuario respresentado por dicha la. Para los links Ver Mozos y Ver Cajeros se habilitan otras posibilidades ya que se permite saber cual es el mozo con ms pedidos levantados y cual es el cajero con ms pedidos facturados. Al precionar en Ver Mozos, se ver la pantalla que se muestra en la gura 8.38 de la pgina 272. A continuacin se nombran las opciones de seleccin: Ver todos los mozos. Ver el mozo con ms pedidos levantados. Ver el mozo con menos pedidos levantados. Ver los Mozos que tienen un nmero jo de pedidos levantados. Ver los Mozos que tienen ms o inclusive un nmero jo de pedidos levantados. Ver los Mozos que tienen menos o inclusive un nmero jo de pedidos levantados. Donde las tres ltimas opciones habilitan una caja de texto para ingresar un parmetro comparativo para realizar la consulta SQL, como se ve en la gura 8.39 de la pgina 273. Las opciones en Ver Cajeros son muy similares a las de Ver Mozos. Ver Men.

272

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.38: Escoger opciones de seleccin en Estadsticas de Mozos.

8.5. DESCRIPCIN DE J-CHEF

273

Figura 8.39: Opcin que requiere de una parmetro de comparacin.

274

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.40: Ver Comidas. Aqu se podrn ver las opciones Ver Todo, Ver Comidas y Ver Bebidas. Ver Comidas puede observarse en la gura 8.40 de la pgina 274. Comos se puede ver, las opciones de seleccin son: Ver la Comida ms pedida. Ver la Comida menos pedida. Seleccionar Categora o Sub Categora. Considerar Fecha. Considerar Hora. El formato de seleccin podra ser algo as: Ver la comida ms pedida de la Sub Categora 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 gura 8.41 de la pgina 275. El funcionamiento de las otras opciones es muy similar.

8.5. DESCRIPCIN DE J-CHEF

275

Figura 8.41: Listado de Items resultado de una consulta estadstica.

276

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.42: Buscar facturas por monto. Ver Facturacin. Al presionar este link se obtendrn las opciones Buscar por Nmero y Buscar por monto. Al buscar por nmero se ingresa el nmero 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 gura 8.42 de la pgina 276. Luego de seleccionar las opciones se muestra un listado de las facturas que coinciden con los parmetros de bsqueda como se ve en la gura 8.43 de la 277 pgina. Si no existen facturas que coincidan se mostrar una pantalla que informe al administrador de tal situacin. Administrador Conguraciones :

8.5. DESCRIPCIN DE J-CHEF

277

Figura 8.43: Facturas que coinciden con los parmetros de bsqueda ingresados.

278

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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 gura 8.44 de la pgina 278. Aqu se debe establecer el nmero de mesas con el trabajar el restaurant. La modicacin de este valor de conguracin tambin modica la Fecha de ltima modicacin del men. El administrador debe escribir el nmero de mesas correspondientes y luego presionar el botn cargar, y J-Chef responder con un mensaje informando si la transaccin se realiz con exito o no. Solo responder que fue exitosa si tambin se ha modicado la Fecha de ltima modicacin del men. Modicar Perl En esta seccin el administrador podr cambiar sus datos, como tambin su Usuario y Contrasea. Ver una pantalla como la de la gura 8.45 de la pgina 279. Logout

8.5. DESCRIPCIN DE J-CHEF

279

Figura 8.45: Modicar Perl del Administrador.

280

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.46: Logout. Todo usuario de J-Chef al realizar el logout ver una pantalla como la de la gura 8.46 de la pgina 280. Aqu se destruye la sesin 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 gura 8.47 de la pgina 281. El tipo de usuario Jefe de Cocina es aquel que se encuentra en la cocina y maneja el orden y los tiempos de atencin 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 n 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. DESCRIPCIN 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 atencin a la pantalla inicial de este panel podr observarse que posee un men de acciones acotado, se explicar a continuacin como funciona este panel. El link ms importante de este panel es sin dudas Ver Pedidos, este link se ver repetido en distintas posiciones dentro de la misma pgina 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 gura 8.48 de la pgina 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 estn 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 descripcin de MobileChef.

282

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.48: Ver Pedidos.

Puede observarse tambin 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, estarn listos para ser Cerrados por el mozo. Aquellos pedidos cerrados ya no aparecern en la lista de pedidos del Jefe de Cocina. Modicar Perl Cuando se presione este link se ver una pantalla similar a la de la gura 8.49 de la pgina 283. Donde el Jefe de Cocina puede modicar su Usuario y Contrasea.

8.5. DESCRIPCIN DE J-CHEF

283

Figura 8.49: Modifcar Perl del Jefe de Cocina.

284

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

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 guar 8.50 de la pgina 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, Modicar Perl 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 facturacin del mismo. Esto se puede ver en la gura 8.51 de la pgina 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 crdito 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. DESCRIPCIN DE J-CHEF

285

Figura 8.51: Lista de Pedidos listos para Facturar.

286

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.52: Facturas. ve en la gura 8.52 de la pgina 286. Luego de seleccionar una factura y presionar el botn Ver podr ver los datos de la factura seleccionada. Modicar Perl Aqu el Cajero podr modicar su Usuario y Contrasea como se ve en la gura 8.53 de la pgina 287.

8.6

Descripcin de Miarritze

Miarritze al igual que J-Chef se desarroll con el lenguaje de programacin Java, utilizando las tecnologas de Servlet y JSP. La base de datos llamada WEBCHEF es manejada por el motor DB2 UDB

8.6. DESCRIPCIN DE MIARRITZE

287

Figura 8.53: Modicar Perl del Cajero.

288

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.54: Pantalla Inicial de Miarritze. 8.1 de IBM. Este mdulo 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 gura 8.54 de la pgina 288.

8.6.1

Estructuracin de Miarritze

Miarritze acepta tres tipos de usuarios, los cuales se describen a continuacin: Internauta. Cliente. Administrador.

8.6. DESCRIPCIN 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 sern: Inicio, Quienes Somos?, Servicios y Contacto. En la gura 8.55 de la pgina 289 se puede ver la pantalla Quienes Somos?. El link Servicios mostrar la pantalla que se ve en la gura 8.56 de la pgina 290. El link Contacto habilita una pantalla donde cualquier usuario podr enviar mensajes va email al administrador de Miarritze, esta pantalla se ve en la gura 8.57 de la pgina 290. Cliente Cualquier persona que desee ser un Cliente de Miarritze y aprovechar los benecios 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 gura 8.58 de la pgina 291, donde la persona debe rellenar el formulario con los datos que en el se solicitan.

290

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.56: Miarritze - Servicios.

Figura 8.57: Miarritze - Contacto.

8.6. DESCRIPCIN 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 accin ver una pantalla como la gura 8.59 de la pgina 292. Cuando un Cliente se logea correctamente se habilita el link Reservas y este puede solicitar una. Esto se ve en la gura 8.60 de la pgina 292. Aqu el Cliente puede seleccionar la Fecha, Hora y Cantidad de Personas. Tambin puede tildar la opcin 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 tambin realiza el pedido de los platos que desea. Esta opcin puede verse en la gura 8.61 de la pgina 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 gura

292

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.59: Cliente Logeado.

Figura 8.60: Miarritze - Reservas y Pedidos.

8.6. DESCRIPCIN DE MIARRITZE

293

Figura 8.61: Solicitud de Reserva con Pedidos.

8.62 de la pgina 294, la cual describe un Reserva. Al hacer clic sobre el link Logout se destruye la sesin 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 tambin se habilita un link Conguracin. Durante la explicacin 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 conexin se podr realizar estableciendo correctamente la direccin IP donde este servidor sea alcanzable por el sitio web, y tambin se deber congurar el puerto donde el servidor atender las solicitudes provenientes desde Miarritze.

294

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.62: Reserva Registrada. Cmo congurar esta conexin se puede ver en la pantalla que se muestra en la gura 8.63 de la pgina 295. Ver Reservas Cuando un administrador se logea en Miarritze puede verse en la imgenes 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 Da. Reservas Conrmadas. 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. DESCRIPCIN DE MIARRITZE

295

Figura 8.63: Miarritze - Conguracin. En la gura 8.64 de la pgina 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 Conrmar o Recharzar dicha reserva como se ve en la gura 8.65 de la pgina 296. Las Reservas Del Da son aquellas que fueron Conrmadas pero su consulta se realiza el mismo da para la cual fue solicitada. De este modo el administrador podr Atenderla. Cuando se clickea el link Ver Res.Del Da se mostrar un listado de las mismas. Las cuales sern vericadas por el administrador. Al clickear sobre el link Ver de alguna de estas reservas del da presentes en la lista, se vern sus datos y ademas se ver un botn Atender. Al presionar este botn Atender, Miarritze se comunica con J-Chef, y obtiene la lista de mozos y el nmero de mesas. Esto se puede ver en la gura 8.66 de la pgina 297. Luego el administrador recibir una pantalla de error si la transaccin no se concret correctamente o si registro correctamente como un pedido recibira como respuesta una pantalla como la que se muestra en la gura 8.67 de la pgina 297.

296

CAPTULO 8. DESCRIPCIN DE LA APLICACIN

Figura 8.64: Miarritze - Listado de Reservas segn su Estado.

Figura 8.65: Conrmar o Rechazar una Reserva

8.6. DESCRIPCIN DE MIARRITZE

297

Figura 8.66: Atender Reserva.

Figura 8.67: La Reserva se ha registrado como pedido activo correctamente.

Captulo 9

Concluciones
9.1 Concluciones Generales.

Es una realidad que tecnologas como el Comercio Electrnico, Java, Aplicaciones Mviles y Dispositivos Mviles, han revolucionado la manera en que los distintos negocios se deben llevar a cabo. Ya que todas estas tecnologas pueden aportar enormes ventajas competitivas en distintos rubros. Estas distintas tecnologas 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 fsico para llevarlo a cabo. En este trabajo se ha cumplido con el objetivo propuesto de desarrollar una aplicacin mvil que acceda a bases de datos multiplataforma, adicionalmente se desarrollaron tambin las aplicaciones web a n de tener un sistema completo desarrollado. Se ha optado por desarrollar la aplicacin mvil sin utilizar ninguna caracterstica propia de ninguna marca del mercado (Palm, PoketPC ), por lo que la aplicacin debera funcionar en cualquier PDA que posea soporte para Java y conectividad wi-. La aplicacin mvil se ha provado en: Emulador estndar de Websphere Application Device Developer. Simulador de Palm TX. 299

300

CAPTULO 9. CONCLUCIONES

Tambin 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 Tecnologas y Software Utilizados

Se ha podido comprobar las grandes ventajas de la utilizacin de tecnologas 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 mviles como web, contando con asistentes, correccin de errores y otras facilidades que hacen ms rpido y eciente el trabajo. Cabe destacar la gran utilidad del debugger de las herramientas WebSphere, ya que facilitan la deteccin y correccin de errores que no son detectados en la compilacin. 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 comprensin en la utilizacin de la herramienta. Resaltar tambin 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 Scientic WorkPlace para escribir libros, por la calidad del producto obtenido, la automatizacin en el manejo de ndices, la gestin dinmica de espacios, listas de guras, de tablas, referencias dinmicas a objetos, bibliografa, 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. LNEAS FUTURAS DE ACCIN

301

9.3

Lneas Futuras de Accin

A continuacin se detallan las principales lneas futuras de accin del presente trabajo: Dotar al mdulo J-Chef de toda la salida impresa en facturacin, cocina, estadsticas, etc. Proveer la posibilidad de exportar los datos a planillas Excel ya que stas pueden ser de gran utilidad para la contadura. Aumentar las opciones de extraccin de estadsticas. Redisear el mdulo Miarritze para que este pueda incluirse en sitios web existentes de distintos restaurantes. Conciderando el desarrollo del mismo mdulo en distintas versiones de acuerdo al lenguaje de programacin 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 mdulo Miarritze, ya que al momento la carga de los tems se realiz de manera manual sobre la base de datos y la edicin o borrado de los tems en J-Chef no se reejan en Miarritze.

Bibliografa
[1] Geraldo Gariboldi. Comercio Electrnico: Conceptos y reexiones bsicas. Banco Interamericano de Desarrollo. BID - INTAL. Documento de Divulgacin 4., 1999. [2] Michael J. Cunningham. Como Desarrollar una Estrategia de Comercio Electrnico. Pearson Educacin, Mxico, 2001. [3] Isabel Gallego Fernndez. Tesis doctoral: Modelo para comercio electrnico basados en sistemas intermediarios. Universidad Politcnica de Catalunya, 2001. [4] Friedemann Mattern. Revista de la ATI (Asociacin de Tcnicos de Informtica) Novtica, Octubre 2001. [5] Alberto Los Santos Aransay. Computacin Ubicua: Trabajo Individual. Diseo de interaccin centrada en el usuario. Universidad de Vigo, 2009. [6] Gutirrez Fernando Islas Octavio. La Sociedad de la Informacin Utopa o Panptico? Revista Electrnica Razn y Palabra, Mayo 2004. [7] Esteinou Javier. Hacia una Nueva Sociedad de la Comunicacin y de la Informacin. Revista Electrnica Razn y Palabra, Marzo 2003. [8] Jorge Blanco Lpez. TELEFONA MVIL: LAS PALABRAS EN EL AIRE. Observatorio Tecnolgico. Ministerio de Educacin, Poltica Social y Deportes. Gobierno de Espaa., Junio 2006. [9] Historia del telfono mvil. 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

BIBLIOGRAFA

[13] Ramn Ruiz Benito Raul Alvarez Barrio Antonio Snchez Dotor, Isidro Arroyo Garcia de Mateos. EL BLUETOOTH. [14] Ing. Dario Yorio. Tesis de Magistratura:Identicacin y clasicacin de patrones en el diseo de aplicaciones mviles. Universidad Nacional de la Plata. [15] E. Castillo; A. Cobo; P. Gmez; C. Solares. JAVA - Un Lenguaje de Programacin Multiplataforma para Internet. Paraninfo, Espaa, 1997. [16] L. Joyanes Aguilar; I. Zahonero Martnez. Estructura de Datos - Algoritmos, Abstraccin y Objetos. Mc Graw Hill/Interamericana de Espaa, S.A.U., Espaa, 1998. [17] L. Joyanes Aguilar. Programacin Orientada a Objetos - Segunda Edicin. Mc Graw Hill/Interamericana de Espaa, S.A.U., Espaa, 1998. [18] IBM. WebSphere Comerse V5.5 Architecture. IBM Press, USA, 2003. [19] Lucas Ortega Daz Sergio Glvez Rojas. Java a Tope: J2ME. Universidad de Mlaga, Mlaga, Espaa, 2004. [20] Jorge Cardenes Patricia Froufe Quintas Agustn. 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. Introduccin 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 mviles, 5359, 62 AWT, 111 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 Jerrquicas Modelo, 179 Bases de Datos Relacional Modelo, 180 bibliotecas de clases, 67 bifurcaciones, 81 if, 81 if else, 81 bloque try, catch, nally, 83 bluetooth, 42, 43, 49 bucles, 82 do while, 83 for, 82 while, 82 C/C++, 80 CDC, 109 Conected Device Conguration, 106 Centro de Desarrollo, 186 305 CLDC, 109 Conected Limited Device Conguration, 106 comentarios, 80 comercio electrnico, 17, 16, 21 computacin pervasiva, 8, 16 computacin ubicua, 811, 15, 16 computadora porttil, 3234, 42, 43, 45, 48 comunicaciones en J2ME, 153 comunicaciones HTTP, 157 conguracin, 106, 109 contenedor cliente de aplicaciones de, 213 EJB de, 212 Web, 212 DB2 Introduccion, 175 db2 Data Links Manager, 186 DB2 UDB Caracteristicas Generales, 183 Funciones Complementarias, 186 DB2 Warehouse Manager, 186 DBMS Sistema de Administracin de Bases de Datos, 177 digitales activos, 197 Dispositivos, 221 dispositivos mviles, 7, 53, 57 DNS, 214

306

NDICE DE MATERIAS

doGet (), 87, 90 doPost (), 90 download, 197 e-commerce, 195 Eclipse, 218 Introduccon y Conceptos, 198 ejemplo de bifurcacin if, 81 bifurcacin if else, 81 bucle for, 82 bucle while, 82 comentario, 80 do while, 83 lnea compuesta por tres sentencias, 79 ejemplo de clase, 72 enterprise beans, 212 estructuras de programacin, 79 expresin, 79 GFC, 153, 155, 157 Generic Framework Conection, 153, 154 GPRS, 97 GUI, 213 herencia, 72 hosts virtuales, 213 HttpServletRequest, 87 HttpServletResponse, 87 instanciacin e inicializacin, 88 interfaz Connection, 155 InputConnection, 156 OutputConnection, 156 StreamConnection, 157 irda, 43, 45 IT, 210

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, 6769, 7274, 7680, 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 automtico 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 aritmticos, 76 de asignacin, 76

NDICE DE MATERIAS

307

de concatenacin de cadenas de caracteres, 79 package, 73 packages, 71 Palm, 35, 39, 40 palm, 97 PDA, 214 pda, 3437, 39, 4143, 97, 223 perl, 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 informacin y el conocimiento, 1720 Spatial Extender, 186 tecnologas de la informacin y la comunicacin, 19, 20 tecnologas de la informacin y la comunicacin, 1922

telfono mvil, 2531, 36, 42, 45, 49, 50, 53, 54 telfonos celulares, 103, 214 telfono mvil, 97 telefona celular, 26, 31 virtual sistema principal, 213 wap, 4951 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-, 36, 4649 Workbench banco de trabajo, 198 WSAD Entorno de Desarrollo de WebSphere Studio, 198 WebSphere Studio Application Developer, 198 WSADIE

308

NDICE DE MATERIAS

WebSphere Studio Application Developer Integration Edition, 198 WSED WebSphere Studio Enterprise Developer, 198 WSSDA WebSphere Studio Site Developer Advanced, 198 XML Extender, 184, 186