UCE SOCIEDAD ANONIMA (SAUCE) by Militante .

Proyecto final de carrera Sistema de Base de Datos cliente-servidor con interfaz grÂ´ afica multiplataforma: Perl

Marcelo J. Armengot Iborra marari@alumni.uv.es

Junio â&#x20AC;&#x201C; 2004

Este esbozo sobre la trayectoria de mis estudios en el campo de la Econom´ıa Pol´ıtica tiende simplemente a demostrar que mis ideas, cualquiera que sea el juicio que merezcan y por mucho que choquen con los prejuicios interesados de las clases dominantes, son el fruto de largos a˜ nos de concienzuda investigaci´on. Y a la puerta de la ciencia, como a la del infierno, debiera estamparse esta consigna: Qui si convien lasciare ogni sospetto; Ogni vilt`a convien che qui sia morta.1 Carlos Marx

D´ejese aqu´ı cuanto sea recelo; M´ atese aqu´ı cuanto sea vileza (Dante– La divina comedia).

A mi madre, Ana Mar織覺a. A mi padre, Eduardo. A mi hermano, Juanfer.

Pr´ ologo El presente documento se ofrece como la memoria de un Proyecto Final de Ca´ rrera para la titulación de Ingenier´ıa Informática en la Universidad de Valencia. Esa es su principal naturaleza. No obstante, en tanto que resultado de un zigzagueante proceso que, finalmente, ha dado solución práctica a un problema real, cobran importancia, otros aspectos que el lector debe tener en cuenta: Si los acontecimientos siguen un curso favorable, el sistema que aqu´ı se describe será utilizado y mejorado en su posterioridad. Y susceptible de ser cambiado y readaptado quién sabe cuántas veces. Pormenorizar minuciosamente cuantas más particularidades del mismo es una responsabilidad para que pueda servir como documentación en dichas incursiones . Por otra parte, al hilo del esperable caso antedicho, no sólo prever que estas notas puedan ser vistas a posteriori como un cuaderno de bitácora sino que quienes las puedan llegar a utilizar o incluso a leer, no tendr´ıan por qué ser necesariamente expertos informáticos. Por ello, contribuir a su buen entendimiento y a su caracter divulgativo, será y ha sido, otra de las tareas del autor. En este sentido, el lector notará que algunas secciones se resuelven con más cuidado para que cualquiera las entendiese, que no otras más técnicas y de antemano destinadas a la evaluación del trabajo. Finalmente, aunque responde a necesidades de otro calibre, y ha colaborado más de una persona, este proyecto es resultado –para bien o para mal– de un proceso fundamentalmente individual. En ese sentido, en vista de que pueda ser retomado en posteriores ocasiones, sirva también para recordar tanto dónde se puso cada cosa como por qué se tomó cada decisión. Dejar demasiada información a merced de una sola cabeza, de una sola memoria, no suele ser recomendable.

Marcelo Armengot Iborra Valencia, 8 de junio de 2004.

vii

viii

Resumen En el cap´ıtulo 1o , como introducci´ on, se describe un problema t´ıpico (aunque con una buena dosis de particularidades) de bases de datos en un caso concreto del mundo real: Un sistema centralizado de base de datos que permita accesos remotos con una interfaz gráfica y que no inponga limitaciones en cuanto al sistema operativo. Lo que en realidad se necesita es un sistema de software que la organización pueda ir ampliando y modificando en sucesivas fases de mantenimiento, por eso – aunque el objetivo principal sea comenzar resolviendo lo inmediato– se ha decidido desarrollar por cuenta propia la parte de aplicación . En cap´ıtulo 2o se propone un cambio de escala en el punto de vista trasladando, al autor y al lector, al estado del arte de las bases de datos en la actualidad. Colocando el espejo donde mirarse tan alto como se ha podido y, permitiendo al lector menos próximo a estos menesteres, acercarse a las problemáticas más habituales de las bases de datos. En el cap´ıtulo 3o se analiza el problema descrito en el cap´ıtulo 1o desde el punto de vista de la Ingenier´ıa del Software. Quedan tomadas algunas decisiones y comienza a cristalizar en planos lo que primero ha sido sólo una idea. No en vano, la lectura del cap´ıtulo 4o no es recomendable sin comprender –cuanto menos– lo fundamental de su predecesor. Ambos cap´ıtulos –an´ alisis y dise˜ no– plasman conjuntamente el trabajo previo que se ha preparado al desarrollo propiamente dicho. Al lector más interesado le ha de servir para tener un modelo de representación del proyecto y, desde ah´ı, tanto evaluar su bondad estructural de conjunto como aproximarse algo más en cualquier tipo de mantenimiento posterior. El cap´ıtulo 5o desciende hasta las contradicciones más materiales, propias de la implementaci´ on o puesta en práctica. Moviéndose en todo momento en el terreno de menor nivel de abstracción, explica los problemas encontrados y las decisiones tomadas para resolverlo; sirviendo, en especial a un lector menos interesado en las cuestiones teóricas, para valorar muchos aspectos prácticos que son propios del ((d´ıa a d´ıa)) de la programación en general. Por necesidades ajenas al interés académico de este trabajo pero –paradójicamente– aumentando éste, surge un nuevo frente que atender cuyo desenlace, sin ser una necesidad primordial, acaba resultando de gran interés. Se trata de la aparición estelar de un personaje de moda: los PDAs. El cap´ıtulo 6o pretende dar una respuesta provisional que –discutiendo las posibilidades– pueda servir, en un futuro nada lejano, para a˜ nadir este peque˜ no lujo a la realidad del sistema desarrollado. Su función a corto plazo es que el destinatario de este sistema decida si invierte o no en avanzar más por esta rama del camino. ix

Finalmente, en el cap´ıtulo 7o se ha sometido el sistema –una vez acabado– a diferentes pruebas con el objetivo de sacar conclusiones de caracter práctico tanto sobre la calidad del producto final como sobre las razones más profundas de sus propiedades, ya sea en el ámbito de las decisiones de toda ´ındole que se han tomado como en cuanto al nivel de trabajo invertido en el dise˜ no.

´Indice general Pr´ ologo

VII

Resumen

VIII

´Indice general

´Indice de figuras

´Indice de cuadros

XVII

1. Introducci´ on 1.1. Descripción de la situación . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Propósitos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Estado del arte 2.1. Introducción: fundamentos teoricos . . . . 2.1.1. Definición . . . . . . . . . . . . . . 2.1.2. Ventajas y desventajas . . . . . . . 2.2. Reflexión sobre la importancia de las bases 2.3. Oracle . . . . . . . . . . . . . . . . . . . . 2.4. Alternativas libres . . . . . . . . . . . . . . 2.4.1. MySQL . . . . . . . . . . . . . . . 2.4.2. PostgreSQL . . . . . . . . . . . . . 2.4.3. Comparativa . . . . . . . . . . . .

1 1 2 3

. . . . . . . . .

4 4 4 4 5 6 9 9 10 10

3. An´ alisis 3.1. Estudio de la viabilidad del sistema . . . . . . . . . . . . . . . . 3.1.1. Alcance del sistema . . . . . . . . . . . . . . . . . . . . . 3.1.2. Discusi´on de las alternativas . . . . . . . . . . . . . . . . Acerca de la base de datos . . . . . . . . . . . . . . . . . Acerca del entorno . . . . . . . . . . . . . . . . . . . . . ¿Un proceso servidor como intermediario hasta MySQL?

. . . . . .

11 11 11 12 12 13 14

. . . . . . . . . . . . . . . de datos . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . .

3.1.3. Requisitos del sistema . . . 3.1.4. Usuarios posibles . . . . . . 3.1.5. Identificaci´on de subprocesos Cliente . . . . . . . . . . . . Servidor . . . . . . . . . . . Cliente de pruebas . . . . . 3.1.6. Planificaci´on del trabajo . . 3.2. Modelo de datos . . . . . . . . . . . 3.3. Modelo del proceso . . . . . . . . . 3.3.1. Caso del cliente . . . . . . . 3.3.2. Caso del servidor . . . . . . 3.4. Modelo del comportamiento . . . .

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

4. Dise˜ no 4.1. Introducción . . . . . . . . . . . . . . . . . . . 4.2. Dise˜ no arquitectónico . . . . . . . . . . . . . . El flujo de trasformación . . . . . . . . 4.2.1. Cliente . . . . . . . . . . . . . . . . . . Descomposición de primer nivel . . . . Descomposición de segundo nivel . . . 4.2.2. Servidor . . . . . . . . . . . . . . . . . Descomposición de primer nivel . . . . Descomposición de segundo nivel . . . 4.3. Descripción de módulos (postproceso) . . . . . 4.3.1. Cliente . . . . . . . . . . . . . . . . . . Limitaciones en el modelo del cliente . 4.3.2. Servidor . . . . . . . . . . . . . . . . . Limitaciones en el modelo del servidor 4.4. Dise˜ no de la interfaz . . . . . . . . . . . . . . 4.4.1. Notas previas . . . . . . . . . . . . . . 4.4.2. Interfaz hombre-máquina . . . . . . . .

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

15 17 18 18 19 19 20 20 22 22 24 26

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

28 28 29 29 30 30 30 31 31 32 33 34 35 37 37 39 39 40

5. Implementaci´ on 5.1. Decisiones previas . . . . . . . . . . . . . . . . . . . 5.1.1. El lenguaje de programación . . . . . . . . . Alternativas independientes de la plataforma ¿Por qué no JAVA? . . . . . . . . . . . . . . ¿Por qué no Perl? . . . . . . . . . . . . . . . La decisión final . . . . . . . . . . . . . . . . 5.1.2. Cliente Perl en entorno de ventanas . . . . . Alternativas . . . . . . . . . . . . . . . . . . Estructura de datos de la tabla . . . . . . .

. . . . . . . . .

42 42 42 43 44 48 51 52 52 54

xii

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

5.1.3. Compatibilidad Ms-Excel . . . . . Componentes de Miscrosoft . . . Acceso a archivos *.xls . . . . . . 5.1.4. Concurrencia: ¿Hilos o procesos? Hilos y/o procesos en Perl . . . . Por qué usar hilos . . . . . . . . . 5.2. Pruebas previas . . . . . . . . . . . . . . 5.2.1. Acceso a Bases de Datos con Perl 5.2.2. Sockets en Perl . . . . . . . . . . 6. Trabajos futuros: PDA 6.1. Introducción . . . . . . . . . . . . . . . . 6.2. Historia reciente . . . . . . . . . . . . . . 6.3. Posibles soluciones . . . . . . . . . . . . 6.3.1. Palm Pilot . . . . . . . . . . . . . 6.3.2. Linux en PDA . . . . . . . . . . . 6.3.3. Pocket PC . . . . . . . . . . . . . Preámbulo . . . . . . . . . . . . . Microsoft .NET para dispositivos SDE y MIT . . . . . . . . . . . . 6.4. Conclusiones . . . . . . . . . . . . . . . . 6.5. Referencias . . . . . . . . . . . . . . . . 7. Pruebas y conclusiones 7.1. Primeras pruebas . . . . . . . . . . . 7.1.1. Inicio . . . . . . . . . . . . . . 7.1.2. Información en el cliente sobre 7.1.3. El editor . . . . . . . . . . . . 7.1.4. Reajustes en el código . . . . Divergencias Windows-Linux . El dilema del socket . . . . . 7.2. Velocidad . . . . . . . . . . . . . . . 7.2.1. Medición . . . . . . . . . . . . 7.2.2. Resultados . . . . . . . . . . . 7.2.3. Conclusiones . . . . . . . . . 7.3. Valoración final . . . . . . . . . . . .

. . . . . . . . .

55 56 57 58 59 59 60 60 61

. . . . . . . . . . .

64 64 65 65 66 67 68 68 70 72 74 76

. . . . . . . . . . . . . . el servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

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

78 78 78 80 81 81 82 84 84 84 86 88 89

. . . . . . . . . . .

El c´ odigo del servidor

El c´ odigo del cliente

Tabla de pruebas

118 xiii

Bibliograf´ıa

120

Referencias web

121

´Indice alfab´ etico

123

xiv

´Indice de figuras 1.1. Croquis de la situaci´on . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1. Principales bases de datos: reparto de mercado . . . . . . . . . . . . .

3.1. Descomposici´on funcional del problema . . . . 3.2. Emplazamiento de los elementos principales . 3.3. DCA cliente . . . . . . . . . . . . . . . . . . . 3.4. Posibles casos de uso del sistema . . . . . . . 3.5. Diagrama de hitos . . . . . . . . . . . . . . . 3.6. Diagramas entidad relacion: entidad suscriptor 3.7. Diagramas entidad relacion: sobre los informes 3.8. DFD0 cliente . . . . . . . . . . . . . . . . . . 3.9. DFD1 cliente . . . . . . . . . . . . . . . . . . 3.10. DFD0 servidor – primera vista . . . . . . . . . 3.11. DFD0 servidor (un cliente) . . . . . . . . . . . 3.12. DFD0 - concurrencia en el servidor . . . . . . 3.13. DFD1 - principal . . . . . . . . . . . . . . . . 3.14. DFD1 - concurrente . . . . . . . . . . . . . . . 4.1. 4.2. 4.3. 4.4.

DFD1 cliente – refinado . . . . . . . . . . . Estructura del cliente . . . . . . . . . . . . . Estructura del servidor, proceso principal . . Estructura del servidor, proceso concurrente

. . . .

. . . . .

. . . . . . . .

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

. . . .

x zoom

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

12 16 17 18 20 21 22 22 23 24 25 25 26 26

. . . .

31 31 32 33

5.1. Benchmark C++ versus JAVA . . . . . . . . . . . . . . . . . . . . . . 46 5.2. La arquitectura de Perl . . . . . . . . . . . . . . . . . . . . . . . . . . 49 6.1. Mobile Internet Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.2. Smart Device Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.1. 7.2. 7.3. 7.4.

Petición de login y password Inicio sin conexión . . . . . Inicio sin conexión anómalo Menu de conexión . . . . . .

. . . .

79 79 80 81

7.5. Aspecto del editor para tablas . . . . . . . . . . . . . . . . . . . . . . 82 7.6. EvoluciÂ´on: tiempos/tabla . . . . . . . . . . . . . . . . . . . . . . . . . 86

xvi

´Indice de cuadros 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9.

Descripción módulo: Grabar tabla localmente. . . . . . . . . . Descripción módulo: Entrar datos a la tabla. . . . . . . . . . . Descripción módulo: mostrar la tabla. . . . . . . . . . . . . . . Descripción módulo: valores de la conexión. . . . . . . . . . . Descripción módulo: conexion inicial. . . . . . . . . . . . . . . Descripción módulo: env´ıo de sentencias SQL. . . . . . . . . . Descripción módulo: generar proceso concurrente. . . . . . . . Descripción módulo: conexión inicial con la base de datos. . . Descripción módulo: escucha de peticiones del cliente (primer bis cliente-servidor). . . . . . . . . . . . . . . . . . . . . . . . 4.10. Descripción módulo: escucha de consultas en el servidor. . . . 4.11. Descripción módulo: gestión de consultas del servidor. . . . . .

. . . . . . . . . . . . . . . . bis . . . . . .

. . . . . . . . a . . .

. . . . . . . .

34 34 35 35 36 36 37 37

. 38 . 38 . 39

5.1. Benchmark C++ versus JAVA: tabla de tiempos . . . . . . . . . . . . 47 6.1. .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 6.2. .NET Compact Framework . . . . . . . . . . . . . . . . . . . . . . . . 70 6.3. S´ıntesis del estudio y discusi´on sobre PDA . . . . . . . . . . . . . . . 75 7.1. 7.2. 7.3. 7.4.

Esquema del interfaz gr´afico: parte cliente Resumen de la tabla de pruebas . . . . . . Medici´on de velocidades . . . . . . . . . . Velocidades segun accesos . . . . . . . . .

xvii

. . . .

81 85 87 88

xviii

Cap´ıtulo 1 Introducci´ on 1.1.

Descripci´ on de la situaci´ on

Una peque˜ na empresa, la Editorial Sauce, gestiona desde hace a˜ nos la edición y env´ıo por suscripción de varias publicaciones ofertadas por el Ateneo Madrid XXI y otras empresas de holding relacionadas con éste. Actualmente esta editorial tiene repartidos por la pen´ınsula unos cincuenta trabajadores comerciales encargados de la difusión y suscripción mensual de todas sus publicaciones. Estos comerciales, recaban semanalmente información de nuevos clientes o suscritos y de nuevos posibles clientes. En la Oficina Central, ubicada en Valencia, además de cotejarse la contabilidad y hacerse otras tareas de gestión, se trabaja con una base de datos que actualmente tiene unos 7000 registros correspondientes a los suscriptores de las distintas publicaciones. Se procuran los env´ıos y se gestionan las nominas de los empleados, as´ı como toda la información correspondiente a los mismos. Se actualizan las nuevas entradas y se comprueba toda la información entrante. La base de datos crece inexorablemente. Debido a la inexistencia de un departamento informático, a la imprevisión de sus gestores y al exponencial desarrollo de los nuevos proyectos: la administración centralizada de todo este operativo viene siendo desde hace tiempo, lenta y poco resolutiva. Los comerciales env´ıan la información semanalmente de muy diferentes maneras, habitualmente tablas en un correo electrónico pero a veces hasta se env´ıan manuscritos por fax. La información es reentrada manualmente a la base de datos central, como mucho importando las tablas originales, tanto para comprobar las posibles duplicaciones como la normalidad de los datos. Cada mes se actualiza una tabla con los suscritos activos y se envia su listado de direcciones postales en un informe, a una empresa llamada Grupo Meydis, que entre otros servicios tiene una oferta para env´ıos por correo. La información es tratada 1

´ CAP´ITULO 1. INTRODUCCION



actualmente sobre Access de MicroSoft y se gestiona a nivel local en la propia oficina. Los responsables de todo este sistema son conscientes del nivel de inoperatividad del mismo, su falta de privacidad y la cantidad de limitaciones que tiene. Están dispuestos a mejorarlo pero no pueden dedicar a ello una parte del tiempo de los empleados de la Oficina Central, no están seguros de hacer una inversión en software ni en hardware y mientras tanto, la eficacia aparente del sistema actual se convierte en una tendencia al conservadurismo. En este primer nivel de descripción la figura 1.1 describe la situación en el terreno estrictamente f´ısico. En pocas palabras: Un sistema de suscripción centralizado por una base de datos y llevado adelante por un equipo de comerciales operativo por todo el pa´ıs que se mueve en función de objetivos y estudios de mercado, por lo que sus accesos a la base de datos son siempre imprescindibles pero impredecibles. Trabajo con la información, local

Host local 1

Host local 2

Host local n Host con BD

Base de datos

Oficina Central

CIUDAD 1 (VALENCIA)

CIUDAD 2 Host remoto 1

Uso información remoto

Ciudad 3 Hos remoto 2

Figura 1.1: Croquis de la situaci´on

1.2.

Prop´ ositos del proyecto

Es evidente que desde un punto de vista de ingenier´ıa, son muchas y muy susculentas las posibles soluciones que pueden d´arsele a esta situaci´on. Tras una primera entrevista, algunas necesidades se apuntan como principales.

´ CAP´ITULO 1. INTRODUCCION



+ Todos los actuales trabajadores, tanto gestores como comerciales deben poder usar la base de datos est´ en donde est´ en. + Para ello hace falta una aplicación que pueda funcionar como cliente y que no esté cerrada, es decir, susceptible de ser ampliada en posteriores fases de mantenimiento. Que sea fácil de usar y compatible con el entorno de Microsoft Office con el que actualmente trabaja la plantilla de empleados. + Renovar la seguridad del sistema, consiguiendo que cada usuario de la información tenga acceso sólo a lo que necesita. + Muy importante, el sistema debe ser rápido y debe poder generar informes a cerca de la base de datos de manera inmediata. + Por u ´ ltimo, pero no menos importante, la solución debe ser lo más barata posible.

1.3.

Objetivos del proyecto

Atendiendo al orden cronológico que requieren estos propósitos y estudiándolos más pormenorizadamente, se entiende que: + Se necesita migrar tanto el hardware como el software portador de la Base de Datos a un sistema mucho más seguro, más rápido, más potente. + Debe ponerse en marcha, para almacenar la base de datos y gestionar los accesos remotos de los clientes, un servidor que proporcione robustez, seguridad y pueda funcionar de manera indefinida. + La información actual es válida y debe ser reentrada en el nuevo sistema. + Hay que programar un cliente para la base de datos que sea: - Sencillo de usar y que no sobrecargue el equipo cliente. - Facilmente portable y que no requiera instalación o ésta sea facilmente reversible. Que convierta cualquier PC en una peque˜ na pero eficiente terminal remota de la base de datos. - Hay que programarlo y documentarlo para poder ampliar sus funcionalidades en el futuro. En el futuro se prevé que la versión del cliente con la que se trabaje localmente en la Oficina Central, incluya la parte de contabilidad y accesos bancarios que actualmente se delegan en otro departamento. + Hay que probar el trabajo localmente y remotamente. Contrastarlo con otras soluciones y justificar la necesidad de su implante.

Cap´ıtulo 2 Estado del arte Algunas secciones de este cap´ıtulo (como la introducci´ on) y algunas anotaciones est´ an especialmente dedicadas al lector m´ as profano, en otro caso puede servir para repasar algunos t´erminos o (como en este caso) ajustar un punto de partida en lugar de darlo todo por supuesto.

2.1. 2.1.1.

Introducci´ on: fundamentos teoricos Definici´ on

Como ((base de datos)) puede aceptarse la siguiente definici´on1 : ((Colecci´ on o dep´ osito de datos integrados, almacenados en soporte secundario (no vol´ atil) y con redundancia controlada. Los datos, que han de ser compartidos por diferentes usuarios o aplicaciones, deben mantenerse independientes de ellos, y su definici´ on (estructura de la base de datos) u ´nica y almacenada junto con los datos, se ha de apoyar en un modelo de datos, el cual ha de permitir captar las interrelaciones y restricciones existentes en el mundo real. Los procedimientos de actualizaci´ on y recuperaci´ on, comunes y bien determinados, facilitar´ an la seguridad del conjunto de los datos)).

2.1.2.

Ventajas y desventajas

Entendiendo que antes de aparecer el concepto de base de datos ya exist´ıa la tecnolog´ıa informática y la información, y la necesidad de utilizar la primera para manejar la segunda, puede imaginarse que las soluciones anteriores pasaban por ((sistemas orientados al proceso, debido a que en ellos se pone el énfasis en los tratamientos que reciben los datos, los cuales se almacenan en ficheros dise˜ nados para una determinada aplicaci´ on. Las aplicaciones se analizan e implantan con entera independencia una de otras, y los datos no se suelen trasferir entre ellas, sino que se duplican siempre que los correspondientes 1

Esta secci´ on (2.1.1 y 2.1.2) est´ a tomada de [11].

CAP´ITULO 2. ESTADO DEL ARTE



trabajos los necesitan)). Implantar una base de datos en un sistema, frente al uso de ficheros clásicos, tiene ventajas y desventajas, ténganse en cuenta: Ventajas: + Independencia de los datos respecto a los tratamientos y viceversa. + Coherencia de los resultados. + Mejor disponibilidad de los datos para el conjunto de los usuarios. + Mayor valor informativo (puesto que se captan relaciones propias del mundo real entre los datos, tiene más información que la suma individual de los datos por separado). + Mejor y más normalizada documentación de la información, la cual está integrada con los datos. + Mayor eficiencia en la recogida, validación e introducci´ on de los datos en el sistema. + Reducción del espacio de almacenamiento. Desventajas: – Instalaci´ on costosa. – Personal especializado. – Implantaci´ on larga y dif´ıcil. – Falta de rentabilidad a corto plazo. – Escasa estandarizaci´ on (la tendencia de esta desventaja es a ser cada vez menor). – Desfase entre teor´ıa y práctica. Esto no tiene que ocurrir necesariamente, se refiere a un desfase entre la concepción teórica, de lo que es la base de datos, que pueden los directivos con respecto a lo que ofrece la tecnolog´ıa realmente.

2.2.

Reflexi´ on sobre la importancia de las bases de datos

((Al Qaeda es una especie de multinacional de prestaci´ on de servicios y preparaci´ on log´ıstica para el terrorismo internacional. Tiene campamentos, armamento, prepara hombres, combatientes, francotiradores, capta posibles m´ artires. Al Qaeda no es un partido, no es en s´ı mismo una organizaci´ on isl´ amica. A Al Qaeda se vinculan muy distintas organizaciones como la Yihad, los salafistas, los Hermanos Musulmanes de Egipto, una rama que es directamente la de Atta y la del n´ umero dos de Bin Laden. Tengo la convicci´ on de que Al Qaeda va m´ as all´ a que Bin laden, es la Umma, la

CAP´ITULO 2. ESTADO DEL ARTE



patria isl´ amica. Ojo aqu´ı que no es un Estado. El ideal es extender el verde del Islam desde C´ ordoba a Manila, donde estuvo, pero no de recuperaci´ on de terrenos sino de una moral fundamentalista.)) ((En este libro, veréis que hay una cita donde aparece el listado de las organizaciones benéficas que directamente est´ an sufragando los campos de entrenamiento de Al Qaeda. Hay constancia de esto en diligencias judiciales. Y de ellas, algunas est´ an presididas por el ministro de Defensa de Arabia Saud´ı, otra por el padre del embajador en EEUU, que daba talones a terroristas, a hombres de Al Qaeda que eran de la célula de Atta. Eso est´ a ah´ı con n´ umero de transferencias y cantidades. Arabia Saudita ha financiado directamente a varios de los pilotos que perpetraron el 11 de septiembre)). Con estas palabras –la conocida periodista de investigaci´ on y autora de varios libros– Pilar Urbano, dejaba perplejo a todo el aforo en la presentación de su libro ((Jefe Atta)). Es del dominio p´ ublico que ((Al Qaeda)) significa ((base de datos)). Un documento acerca del estado del arte de las bases de datos está en un terreno diferente del análisis que merece este tema, pero lo que se intenta introducir con esta peque˜ na presentación es que en la actualidad, la tecnolog´ıa que maneja la información es un arma de un calibre inpensable, todo lo relacionado con ello merece un cuidado exquisito y es la piedra angular de cualquier organización ya sea social, empresarial, estatal, militar, administrativa o también popular. Las principales multinacionales han promovido el desarrollo de esta tecnolog´ıa y la han hecho avanzar hasta llegar a una potencia de cálculo y de consulta impensable hace cien a˜ nos. Ellos pueden utilizarlo para sus fines. Los estudiantes, ingenieros y profesionales de la informática en general, deben aprender a esgrimir este arma y tienen la responsabilidad de denunciar cualquier tipo de uso anómalo que se le pretenda dar.

2.3.

R Oracle

En junio de 2004 la consultora estadounidense IDC emitió un informe2 acerca del porcentaje de mercado de los principales sistemas de base de datos. El gigante Oracle, sigue siendo el lider en sistemas de bases de datos (los resultados de este estudio pueden verse sintetizados en la figura3 2.1 ). Y hay que tener en cuenta que aunque haya otros sistemas que le hagan sombra, las principales empresas utilizan Oracle. Desde hace casi treinta a˜ nos, Oracle viene desarrollando los productos más competitivos en el mercado de la base de datos, desde su posición dirigente, ha ido obligando a todos los desarrolladores de bases de datos a cumplir una serie de criterios. La siguiente enumeración4 recoge las veinte propiedades más avanzadas de la versión Oracle 10g. Sirva para 2

Puede visitarse en http://www.idc.com. Se ha inclu´ıdo MySQL aunque sea gratuita para poder comparar su uso con respecto a las dem´ as. 4 Tomada del art´ıculo ((Oracle Database 10g: The Top 20 Features for DBAs)) publicado por Arup Nanda en la revista Oracle Magazine’s 2003. Puede visitarse en http://otn.oracle.com/pub/articles. 3

CAP´ITULO 2. ESTADO DEL ARTE



Figura 2.1: Reparto de mercado de las principales bases de datos tener una concepci´ on de lo que necesitan las u ´ltimas aplicaciones prácticas en el mercado. Se debe entender como los u ´ltimos retos a los que las bases de datos se ven desafiadas por sus usuarios, y desde ah´ı, tomar conciencia del terreno en el que se mueven hoy d´ıa los sitemas de bases de datos: 1. Tienes una pel´ıcula, no una fotograf´ıa. Una base de datos debe mostrar la información en relación a la actualidad, partiendo de que puede ser consultada por muchos usuarios y modificada simultaneamente. 2. ¿Queda mucho? Cuando se monitoriza un rollback 5 amenudo los usuarios preguntan al administrador esto, estimar dicha operación con el máximo de precisión es el servicio que la base de datos debe proporcionar. 3. Mejorar la gesti´ on del espacio de tabla. Se refiere a las restricciones a la hora de crear tablas, los usuarios no pueden utilizar espacio de disco que corresponde al sistema o a otros usuarios. 4. Potencia de exportaci´ on de datos. La base de datos frecuentemente requiere exportar datos, el objetivo es alcanzar la máxima potencia. Cuanto mayor tama˜ no de tabla en menos tiempo se pueda emitir, mejor. 5. Tabla de flashback. O tabla de recuperación, para borrados accidentales y otro tipo de pérdidas de información. 6. Almacen autom´ atico del trabajo acumulado. Se trata –cuando ocurre alg´ un problema– de poder responder con la mayor eficacia posible a las tres preguntas: ¿Es el mismo problema recurrentemente? ¿Ocurre durante un per´ıodo espec´ıfico de tiempo? ¿Existe una relación entre dos problemas? 5

Un rollback es la operaci´ on de vuelta atr´as que se hace en una base de datos cuando una transacci´on ha quedado interrumpida. Se vuelve a un punto anterior donde los datos mantienen la consistencia (por ejemplo es trasferencias bancarias, el dinero puede estar en una cuenta emisora o en la receptora pero no en ambas a la vez o en ninguna).

CAP´ITULO 2. ESTADO DEL ARTE



7. Soporte para SQL*Plus 10.1.0.2 Aunque SQL6 es un estándar y nació en los a˜ nos 70 en los laboratorios de IBM, hoy d´ıa, en ciertos ámbitos es SQL*Plus quien marca el rumbo (o más marca el rumbo) de lo que debe ser SQL. Sus nuevas contribuciones representan un modelo de intérprete de SQL para cualesquiera sistemas de base de datos, Oracle, por supuesto predica con el ejemplo. 8. Gesti´ on autom´ atica del almacenamiento. En cuanto al manejo f´ısico de los discos, la base de datos debe ser la que automáticamente lo gestione optimizando las posibilidades. 9. RMAN Un sistema automático7 para crear y disponer del back up de la base de datos. 10. La auditor´ıa te lo dice todo. Un sistema detallado para saber de manera pormenorizada no sólo qué usuario act´ ua sobre la base de datos sino qué hace. 11. Interfaz de espera. De cara a las consultas que tardan en resolverse (desquiciando a los usuarios), este interfaz detalla el proceso para que se sepa en cada momento qué queda, qué se esta esperando, cuánto va a tardar. 12. Vistas materializadas. Una gestión sofisticada del resultado de una consulta, que se puede concebir como un fotograma en la memoria y que se emite al usuario cuando vuelve a hacer la misma consulta, teniendo cierto nivel de modificación si la consulta var´ıa. 13. Enterprise Manager.8 La base de datos debe ofrecer al administrador un interfaz para gestionar la base de datos, potente, sencillo de usar, etc. 14. Base de datos privada virtual. La base de datos incorpora un sistema de nivel superior al usuario que le introduce una consulta, a˜ nadiendole a esta lo que haga falta para introducir distintos tipos de dispositivos de seguridad. Con este sistema, por ejemplo, se pueden emular vistas9 . 15. Gesti´ on de segmentos. Gestión del almacenamiento eficientemente: compactando los objetos, aprovechando el espacio en desuso, etc. 16. Espacio de tablas trasportables. Los espacios de tablas, deben ser trasportables a través de plataformas, haciendo que la publicación de datos sea cuanto más fácil y más rápido. 6

SQL es un lenguaje estandarizado para hacer consultas a bases de datos y gestionarlas (Structured Query Language). 7 RMAN es el Recovery Manager o gestor de recuperaciones. 8 La traducci´ on ser´ıa gestor de la empresa, o gestor para la empresa. Se ha dejado en inglés porque quienes conozcan algo (o mucho) a Oracle no lo llamaran de otra manera. 9 Sup´ ongase que el usuario ((Carlos)), con permiso para ver s´ olo sus registros pretende hacer un listado de la tabla total, este sistema le a˜ nade a su consulta una condición más, de manera que sólo reciba aquellos registros en los que ((Usuario)) sea igual a ((Carlos)).

CAP´ITULO 2. ESTADO DEL ARTE



17. Gesti´ on autom´ atica de memoria compartida. Gestiona y localiza memoria donde más falta hace. No pueden producirse errores de falta de memoria por un problema de gestión. 18. Monitor autom´ atico de di´ agnostico. Debe imaginarse como un robótico administrador de la base de datos que (aunque con limitaciones) ayude al administrador (humano) de la base de datos en determinados problemas. Trabaja en connivencia con un notificador de ajustes de SQL. 19. Scheduler 10 . Un sistema que automatice la creación y almacenamiento de trabajos (o sesiones) de la gestión de la base de datos para automatizar ciertas tareas rutinarias. 20. La guinda del pastel. Colecciones de estad´ısticas, retención garantizada de datos para ((deshacer)) determinadas acciones, operaciones de cifrado más fáciles y más seguras.

2.4.

Alternativas libres

Afortunadamente, adem´ as de pagar a Oracle por sus servicios, existen otras posibilidades interesantes. El mundo de la Open Source tiene brillantes soluciones que, en ocasiones, pueden salir m´ as rentables. Es dificil encontrar documentaci´ on (imparcial) como para profundizar lo debido en todas (PostgreSQL11 , MySQL12 , Firebird13 , MaxDB14 , etc) pero vale la pena echar un vistazo a las dos m´ as conocidas15 .

2.4.1.

MySQL

Sus principales propiedades son: ∗ Fue dise˜ nado para proporcionar buena velocidad. ∗ Consume pocos recursos. ∗ Ventajas: + Buen rendimiento, buena velocidad a la hora de conectar con el servidor y de respuesta a consultas. + Registros sin l´ımite de tama˜ no. 10

((Scheduler)), algo as´ı como planificador, en espa˜ nol. http://www.postgresql.org 12 http://www.mysql.org 13 http://firebird.sourceforge.net 14 http://www.mysql.com/products/maxdb/ 15 Esta comparaci´ on ha sido tomada de un estudio hecho en la Universidad de Alicante, a su vez cotejando diferentes fuentes. El sitio web, al parecer mantenido por una unidad independiente de Innovaci´ on Inform´ atica puede visitarse en http://www.mmlabx.ua.es. 11

CAP´ITULO 2. ESTADO DEL ARTE



+ Control de acceso: qué usuarios tienen acceso a qué tablas y con qué permisos. + Buena reacción ante momentos de inestabilidad en el sistema. ∗ Desventajas: – No soporta vistas (entre otras cosas).

2.4.2.

PostgreSQL

Sus principales propiedades son: ∗ En principio, tiene un sistema de bases de datos de mayor nivel a MySQL, a la altura de Oracle, Sybase, etc. ∗ Ventajas: + Buena escalabilidad. Debido a su dise˜ no, conforme se aumenta el n´ umero de procesadores aumenta el rendimiento. + Soporta un subconjunto del estándar SQL mayor que el de MySQL y tiene propiedades de orientaci´ on a objetos. ∗ Desventajas: – Es entre dos y tres veces más lento que MySQL. – Sobrecarga el sistema bastante más que MySQL.

2.4.3.

Comparativa

Aunque esta comparaci´ on está algo anticuada (de hecho, no se han a˜ nadido ciertas caracter´ısticas por no estar referidas a las versiones actuales de uno y de otro), parece evidente que PostgreeSQL persigue un modelo más ambicioso que MySQL. No obstante, para un sistema de caracter doméstico o similares, parece bastante más recomendable MySQL que es más rápido y consume menos recursos. Por otra parte no debe olvidarse la figura 2.1 y el estudio del que se ha extra´ıdo: MySQL es más utilizada que PostgreSQL. Por u ´ltimo, es interesante saber que aunque ambas son de libre distribución y código abierto, mientras que MySQL está firmada con una licencia GPL (lo cual obliga al que la utilizare a liberar también su c´ odigo y firmar con GPL), PostgreSQL no tiene copyleft y por lo tanto deja a sus usuarios ((libertad)) total16 .

La aut´entica libertad es la que propone la filosofia de la GPL, si en PostgreSQL no son tan radicales quiz´ a es porque no pueden perm´ıtirselo o no les interesa.

Cap´ıtulo 3 An´ alisis Este cap´ıtulo recoge la primera aproximaci´ on al problema desde un punto de vista de Ingenier´ıa del Software. No da respuestas para todas las preguntas pero s´ı a algunas importantes. Se apoya en ciertas figuras que tienen el principal objetivo de facilitar la comprensi´ on del problema tanto para el que va a enfrentarse a él como para cualquier tipo de lector. Conviene decir, en ese sentido, que se ha postergado por el momento el dilema de si ser´ a necesaria la Orientaci´ on a Objetos a la hora de afrontar la construcci´ on de este sistema de software, hasta tener un nivel de comprensi´ on mayor sobre lo que se va a hacer. De todas maneras el lector menos profano puede reconocer algunos diagramas propios del modelado en dicha disciplina, pues se ha cotejado distintas fuentes para resolver este cap´ıtulo con el interés principal de completar: ((Algo que ayude a hacer una partici´ on de los requisitos y a documentar esas divisiones antes de especificar . . . )) ((Alg´ un método de seguimiento y evaluaci´ on de interfaces)) ((Herramientas para describir la l´ ogica y la t´ actica, algo mejores que descripciones narrativas . . . )) Entendiendo que son tres m´ınimos1 objetivos que debe cubrir una fase de an´ alisis.

3.1. 3.1.1.

Estudio de la viabilidad del sistema Alcance del sistema

Es absurdo hacer ning´ un estudio sobre la distribución organizativa del equipo porque éste se reduce a un sólo responsable. Sin embargo, para atacar lo que se va a hacer, es importante estudiar la descomposición funcional del sistema descrito. Existen varios campos involucrados en el sistema resultante. Para vislumbrar las posibles 1

Extracto de discusi´ on en [9] citando a DeMarco.

´ CAP´ITULO 3. ANALISIS



soluciones y discutir las alternativas, sirva la figura 3.1 como diagrama de referencia. En ella, aparece desglosado lo que se debe empezar a diferenciar. Por un lado lo referente a los sitemas de la base de datos, los equipos que trabajen en la Oficina y lo que en ese sentido se a˜ nada. Por otra parte la aplicaci´on cliente, que aunque puede ser usada tambi´en en la misma Oficina Central, debe estar preparada seg´ un las condiciones que se han puesto.

Solución Nueva

Aplicación cliente

Comunicación servidor

Interfaz gráfica

Servidor (host)

Compatible MS-Office

Plataforma, sistema seguro

Proceso servidor?

Base de datos

Migración datos actuales

Puesta a punto

Figura 3.1: Descomposici´on funcional del problema

3.1.2.

Discusi´ on de las alternativas

Acerca de la base de datos Lo primero a descartar en este apartado es la posibilidad de desarrollar un sistema de base de datos propio. Ser´ıa dedicarle una parte del tiempo y arriesgarse teniendo en cuenta que hay muchas soluciones disponibles actualmente. Y no hay ninguna ventaja en implementarla por cuenta propia. Partiendo de que el presupuesto económico es una clave en cada parte de este desarrollo, dentro del mundo de las bases de datos, se ha visto en la sección 2.4 las posibilidades. Por las caracter´ısticas del sistema descrito parece más adecuada MySQL (más rápida, que consuma menos recursos). Se trata de una base de datos potente, puede descargarse gratuitamente desde http://www.mysql.com y está comunmente comprobada. Conviene decir aqu´ı, que aunque pueda parecer una man´ıa de gur´ us del GPL2 o más bien una sensación subjetiva por todo lo que está desarrollado siguiendo esta orientación, 2

Licencia P´ ublica del proyecto GNU.

´ CAP´ITULO 3. ANALISIS



MySQL es realmente una solución seria: Téngase en cuenta, que por ejemplo, hace más de un a˜ no, la empresa Ziff Davis Media Inc. publicaba un art´ıculo en http://www.eweek.com donde en distintos benchmarks 3 aparec´ıa MySQL tuteandose con otras bases de datos de tipo comercial: DB2 7.2, MS SQL Server 2000, MySQL-Max 4.0.1, Oracle9i 9.0.1.1.1 y Sybase ASE 12.5.0.1. Los tests se hab´ıan ((realizado en un buen equipo, superior en prestaciones a la mayor´ıa de los grandes servidores de empresas, o de Internet: se trata de un Hewlett-Packard NetServer LT 6000r con cuatro procesadores Xeon a 700MHz, 2GB de memoria RAM y 24 discos Ultra3 SCSI a 10,000 RPM de 9.1GB.)) Aunque se trate de sólo un tipo de prueba donde por ejemplo las medidas se hab´ıan ((ejecutado bajo la plataforma Windows 2000, los resultados son de gran ayuda orientativa para prever c´ omo responder´ıan estos sistemas bajo Linux)) y deben tomarse en cuenta como referencia objetiva sobre MySQL. Las pruebas consist´ıan en una simulación de ((varios cientos de usuarios navegando dimult´ aneamente por un portal din´ amico de Internet que se apoya en una base de datos, que es la que precisamente se est´ a estudiando.)) Y las conclusiones apuntaban a que quien estuviera planificando adquirir una licencia comercial de Oracle deb´ıa pensárselo dos veces y estudiar detenidamente el estudio realizado4 Además MySQL: ∗ Tiene APIs 5 para distintos lenguajes de programación: C, C++, Eiffel, JAVA, Perl, PHP, Python, Ruby y Tcl. ∗ Funciona en diferentes plataformas. ∗ Tiene soporte completo para consultas SQL del tipo ORDER BY, GROUP BY. ∗ Tiene un sistema seguro de contrase˜ nas y usuarios. ∗ Maneja grandes bases de datos. ∗ ODBC (Open Database Connectivity) soporta conexión con Win32. MySQL tiene muchas otras prestaciones, que la hacen ser una competitiva solución para base de datos 6 .

Acerca del entorno Sobre la aplicaci´on cliente no cabe ninguna duda porque est´a impl´ıcito en los requisitos iniciales, debe correr en cualquier plataforma ya que no es predecible el sistema que manejen los usuariso finales. Con respecto al entorno en la Oficina Central hay basicamente 3

Término saj´ on para referirse a los procesos y programas que aplican pruebas comparativas tanto absolutas como relativas a un sistema de hardware o de software. 4 Más informaci´ on en http://linux.bankhacker.com/software/Benchmarks+de+MySQL/ y en http://www.eweek.com. 5 API (Application Programming Interface): Interfaz de programación para aplicaciones. 6 Más informaci´ on en el manual de referencia de MySQL [6].

´ CAP´ITULO 3. ANALISIS



dos aspectos, que invitan a decidir casi de manera inmediata que conviene migrar a un sistema de tipo Unix como Linux. Por orden de importancia: + En este problema, la seguridad y privacidad de la información es de caracter primordial. + Debe ponerse en marcha un servidor robusto, que funcione indefinidamentey que acepte multiples accesos. Aunque en esto Linux no tiene la exclusividad7 , es la solución más asequible a las posibilidades actuales. En definitiva, un sistema software donde la aplicación cliente sea la misma para dentro que para fuera de la oficina (donde los equipos con Linux van a abundar) y donde la aplicación servidor pueda correr en Windows por lo que pueda decidirse en el futuro pero esté adaptada a la optimización que le extraiga Unix.

¿Un proceso servidor como intermediario hasta MySQL? Llegados a este punto, aunque a´ un no está abordado el problema de la puesta en marcha de la base de datos, entre algunas preguntas que aparec´ıan confusas cristalizan ciertas razones que invitan a desarrollar un programa servidor que se comunique directamente con MySQL y al que pueda acceder el cliente. En principio esto no deber´ıa hacer falta porque las librer´ıas para acceder a MySQL permiten programar una aplicación cliente que se conecte directamente con nuestra base de datos de manera remota. Crear un intermediario para este di´ alogo parece innecesario funcionalmente y completamente prescindible a nivel académico. Es como contratar a un traductor para que se entiendan dos personas que hablan el mismo idioma. Las desventajas son evidentes, disc´ utanse las ventajas: + La principal razón para tomar esta decisión aparentemente tan singular es que, desgraciadamente, MySQL no soporta vistas (view ). Uno de los requisitos expl´ıcitos de todo el sistema es que cada usuario puede ver sólo un sesgo (su sesgo) de la tabla. Con un campo a˜ nadido a las tablas correspondientes (del due˜ no de la información) se puede enmascarar este problema y hacer que nunca llegue hasta un cliente remoto la información no deseada. Dividir la tabla en peque˜ nas tablas es una solución a descartar porque hace que el n´ umero de tablas incremente sin parar con la llegada de nuevos trabajadores y no es elegante ni eficiente. + Crear un intermediario entre el cliente y MySQL supone separar dos problemas. Todo lo relacionado con el cliente ya no depende en nada de si se esté usando MySQL u otra base de datos. Se podr´ıa cambiar de base de datos a voluntad, mientras la comunicación entre el servidor y el cliente siga igual. Los clientes seguiran funcionando y sus usuarios no tienen ni por qué saberlo. + El cliente queda liberado de cierta carga, esta es una buena ventaja, y está relacionada con lo mencionado en 1.3 en la página 3. Recuérdese: una aplicación cliente todo 7

Se podr´ıa discutir, por ejemplo, acerca de ciertas instalacioens de Windows NT o de equipos Mac.

´ CAP´ITULO 3. ANALISIS



terreno capaz de convertir cualquier ordenador en una puerta hacia la seguridad del sistema central, incluso si este es un equipo limitado. + Se puede (y seg´ un el primer punto, se debe) configurar MySQL para que sólo admita accesos locales, desde el mismo host o desde un host conocido. De manera que al programa servidor que debe crearse, se le pueden dar, en un futuro, facultades propias de cortafuegos e incrementar la seguridad. Con todo ello, disponer a la máquina donde corra el proceso servidor, como lo que en cierta literatura se conoce con el nombre de ((bastion host)) o bien disponer de éste y a otro nivel de la red local un host con el servidor corriendo y otro con el sistema de base de datos montado. En definitiva, crear un proceso servidor, a largo plazo, supone cuidar las cuestiones anteriores y poder mejorarlas en el futuro. A corto plazo es una decisión que tiene varios inconvenientes: - Complejiza el problema, lo peor que tiene, sin duda. - Tiempo de programaci´ on que podr´ıa dedicarse en otra tarea. Téngase en cuenta que se trata de un programa capaz de estar a la escucha y atender multiples peticiones. Es decir, es un proceso concurrente. - Crea una nueva responsabilidad para el sistema: una parte importante de la seguridad. Aunque se apunte esto como una desventaja hay que recordar que es mucho mejor que recaiga en el servidor que en el cliente, ya que hay que partir de que el primero está bajo control mientras que el segundo podr´ıa ser imitado en cualquier tipo de ataque al sistema simplemente utilizando esta documentación. Tomando pues la decisión de desarrollar este programa servidor8 tómese como referencia la figura 3.2 que, como diagrama de emplazamiento, sirve para comprender a partir de ahora la relación entre los distintos elementos que se van a manejar.

3.1.3.

Recapitulaci´ on de requisitos

El cap´ıtulo primero está escrito con un conocimiento parcial de la solución. A medida que el estudio de la misma avanza, la respuesta es más completa, más multilateral. Es hora de aclarar al lector sobre lo que se va a hacer: 1. Desarrollar un programa cliente: + Con entorno gráfico intuitivo. + Se comunica por sockets con el servidor. + Permite modificar la tabla cargada y reenviarla. + Con compatibilidad para almacenar y portar datos desde Ms-Office. 2. Desarrollar un programa servidor que: 8

Desde ahora entiendase por servidor al programa intermediario entre el cliente y la base de datos ya que funciona como tal.

´ CAP´ITULO 3. ANALISIS



Figura 3.2: Emplazamiento de los elementos principales + Acepte conexiones de multiples clientes, luego debe admitir cierto nivel de concurrencia. + Se conecte a la base de datos MySQL. + Ofrezca al administrador del sistema información acerca de las conexiones y el trabajo que éstas realizan. 3. Poner en marcha una máquina con Linux y MySQL, para lanzar en ella el servidor. 4. Portar a MySQL las tablas actuales y crear la base de datos definitiva en MySQL. 5. Lanzar y probar el sistema. La lista anterior podr´ıa incluir los siguientes puntos como un previo: - Dise˜ nar un protocolo de comunicación entre el cliente y el servidor. Un sistema de env´ıos y recepciones que les permita dialogar. La figura 3.3 da una visi´ on de la arquitectura interna en el cliente, en la cual quedan recogidas las principales funcionalidades que va a tener el sistema en su conjunto

´ CAP´ITULO 3. ANALISIS



desde un punto de vista práctico para lo que el cliente necesita y ayuda a comprender el nivel de complejidad –o sencillez– del mismo. - Para probar al servidor convendrá programar un ((cliente de pruebas)) que no requiera la interfaz gráfica y permita agilidad al desarrollar y depurar el código.

Entrada de consultas e intrucciones SQL

Interfaz grafico

Tratamiento de sockets Ficheros XLS de Ms-Excel

Gestionar ordenes implícitas

Interfaz de usuario

por TCP/IP hasta servidor

Tratar variaciones Funciones de tratamiento y control

por TCP/IP desde servidor tabla en memoria local entrada

Mantenimiento y autocomprobación

Ficheros XLS de Ms-Excel

salida

Figura 3.3: Diagrama de contexto de la arquitectura para el cliente

3.1.4.

Acerca de los tipos de usuarios

Hay varios tipos de personas dentro de la empresa que pueden utilizar este sistema, antes o después habrá que contemplar esta situación: - El gestor que trabaja en la oficina y necesita utilizar la base de datos o hacer alg´ un informe: lista –al banco– de domiciliaciones para cobrar mensualmente, informes de direcciones postales para env´ıos, variaciones en nominas, cambios de permisos, etc. - Cualquier otro trabajador que se conecte a la base de datos y que no tenga permisos de gestor. - El administrador del sistema, que no sólo pueda hacer ajustes y variaciones en la disposición del mismo sino que tenga que comprobar cualesquiera de las tareas que están haciendo el resto de trabajadores. El diagrama 3.4 deber´ıa servir para dar una idea de los posibles casos de uso que se derivan de esta situación y que determinan diferentes áreas del sistema final.

´ CAP´ITULO 3. ANALISIS



Figura 3.4: Posibles casos de uso del sistema

3.1.5.

Identificaci´ on de subprocesos

Dist´ıngase este nivel de estudio de los procesos y mecanismos inmiscuidos en lo anteriormente descrito, del posterior modelado del proceso que se deber´ a ver en otra secci´ on. Es inevitable diferenciar a partir de ahora el trabajo en el desarrollo del cliente del que se hace con el servidor. Se trata, en realidad, de programas diferentes y deben ser tratados por separado. Las principales funcionalidades a las que hay que enfrentarse son las siguientes:

Cliente 1. Conexi´ on a) Pedir login y password. b) Primer bis a bis con el servidor, para establecer con ´el el socket de comunicaci´ on.

´ CAP´ITULO 3. ANALISIS



c) Cargar una primera vista de MySQL con las bases de datos del usuario conectado. 2. Permitir cargar una tabla Ms-Office (tablas de Ms-Excel 9 ). a) Buscar un archivo en disco local. b) Compatibilidad Ms-Excel (comprensi´on del formato y archivos *.xls). 3. Entorno de la tabla a) Modificar valores (columnas, n´ umero de registros). b) A˜ nadir nuevos registros. c) Profundizar (si es tabla con nombres de bases de datos o con nombres de tablas de una base de datos) cargando posteriores tablas. - Convertir en consulta y enviar a servidor para que la procese. - Interpretar el resultado que env´ıa el servidor. d) Reenviar la tabla hacia el servidor.

Servidor 1. Abrir socket de escucha. 2. Aceptar conexiones: a) Generar un proceso que gestiona cada nueva conexion de forma concurrente (simult´anea). b) Liberar el socket de escucha y dedicar a cada proceso gestor uno nuevo 3. Proceso gestor, que se ejecuta concurrentemente tanto con el proceso comentado en 2 como con sus distintas instancias. a) Conexi´ on con MySQL partiendo de los datos enviados por el cliente. b) Esperar consultas. c) Cotejar consultas con MySQL. d) Enviar resultados al cliente.

Cliente de pruebas Es previsible desarrollar paralelamente al cliente gráfico un cliente mucho más simple que pueda interactuar con el servidor. Aunque no sea necesario ((oficialmente)), puesto que se va a utilizar para probar el servidor, conviene aclarar qué es lo que puede hacer este programa que puede concebirse, durante el desarrollo y algunas de sus pruebas, como el ((doble de escenas de acci´ on)) del cliente protagonista,. 9

Se ha elegido Ms-Excel como un mecanismo f´acil, habitual y com´ un para llegar hasta Ms-Office en general e incluso Access si hiciera falta.

´ CAP´ITULO 3. ANALISIS



1. Tiene bis a bis inicial con el servidor igual que el cliente en su versi´on de interfaz gr´afica. 2. Acepta cadena entrada por teclado. 3. La env´ıa tal cual al servidor. 4. Espera en el socket el resultado y lo muestra por pantalla.

3.1.6.

Planificaci´ on del trabajo

Entendiendo que ninguna de las tareas vistas en 3.1.3 (página 15) es de una complejidad extrema ni que se generan bucles de dependencias m´ utuas, y atendiendo principalmente a que todas las tareas deben ser desarrolladas conviene dibujar un diagrama con los hitos principales. La figura 3.5 uestra el camino hacia la meta. A nivel académico podr´ıa decirse que los hitos: poner a punto servidor, portar datos y puesta en marcha oficial son la guinda del pastel. Sin dejar de prestarles atención, concentrar las fuerzas en poner en marcha con éxito la aplicación cliente, el proceso servidor y hacer los ajustes necesarios a la base de datos, permitirá aprovechar el tiempo. Cliente Gráfico (definitivo) Diseño protocolo comunicación ClienteServidor

Cliente de pruebas

Puesta en marcha oficial Programa servidor

inicio

pruebas

Diseño y creación de Base de Datos

Portar datos

Poner a punto host servidor

Figura 3.5: Diagrama de planificaci´on con los hitos principales

3.2.

Modelo de datos

No est´ a de m´ as en este caso, profundizar en la relaci´ on que guardan los datos dentro de este sistema y su estructura a nivel pr´ actico. Aunque en esta secci´ on se sobrepase los l´ımites de lo que va a desarrollarse a posteriori,

´ CAP´ITULO 3. ANALISIS



todo lo que aqu´ı quede plasmado servir´ a para poder contrastar la visi´ on de conjunto que se tiene en este a ´mbito y para preparar cualquier estudio o ampliaci´ on posterior del sistema.

Este nivel de abstracción es global, de manera que no hay distinción entre el proceso servidor del proceso cliente, porque en u ´ ltima instancia la información que manejan es la misma. El suscriptor La base de información sobre la que gira todo este sistema es cada uno de los registros con información sobre los clientes y posibles clientes. Su trasformación en altas como clientes o bajas es el primer nivel de trasformación posible. Cada mes, se envia al banco una petición de domiciliar los cobros a todos los suscritos (incluyendo los nuevos de ese mes) y éste devuelve un informe sobre los que tuvo éxito. Siempre puede haber incidencias y aunque en teor´ıa alguien esté suscrito para la base de datos, fallar en el pago un mes por error bancario, alguna confusión con la cuenta si es nuevo o falta de fondos (esto es habitual en los suscritos que asignan una cuenta por separado para la suscripción). alta suscripción [1:1]

persona registrada

[1:m]

pago del mes

[1:1]

baja suscripción

Figura 3.6: Sub-diagrama entidad relación: entidad suscrito Los informes Como ha quedado dicho en anteriores secciones, existen trabajadores comerciales que gestionan directamente las suscripciones de las distintas publicaciones. Dentro de la base de datos constan como parte integrante de la información que se tiene de los suscritos. Para el departamento de contabilidad, se trata de la pieza primera de su esqueleto. El sueldo de estos trabajadores var´ıa seg´ un la cantidad de suscritos que en cada momento tienen. De manera que el informe de suscritos activos se tramita para hacer un informe que se enviará al departamento de contabilidad que gestiona los pagos. Por otra parte, cada mes que un suscrito paga, le da derecho a recibir aquello que está pagando. Desde la base de datos, se genera una lista de etiquetas con las direcciones de los clientes, se genera en función del informe bancario, que contiene quién paga y quién no. La lista de etiquetas se env´ıa al Grupo Maydis que env´ıa por correo las diferentes publicaciones y los correspondientes packs.

´ CAP´ITULO 3. ANALISIS



comercial

[1:1]

informe sueldos

[n:m] [1:m]

cliente

[n:1]

informe domiciliaciones [1:1]

informe envios postales

Figura 3.7: Sub-diagrama entidad relaci´on: relaciones entre informes

3.3.

Modelo del proceso

Aqu´ı, como es evidente, s´olo se puede avanzar diferenciando claramente, lo que ata˜ ne al proceso cliente de lo que ata˜ ne al proceso servidor.

3.3.1.

Modelo del proceso cliente

Modelo del proceso cliente: Nivel 0. Como aplicación autónoma, el proceso cliente sólo puede recibir información de tres fuentes diferentes: - Puede recibir información directa que el usuario introduce de alguna manera. - Puede cargar alguna tabla en formato Ms-Excel que haya en el disco duro local o en cualquier sistema de archivos montado remotamente por el sistema operativo local. - O bien puede recibir diferentes mensajes o secuencias de mensajes desde el servidor. En la figura 3.8 queda claro que las posibles salidas de la información procesada (o sin procesar) son las mismas. SERVIDOR usuario Archivo local importado

SERVIDOR Aplicación cliente

usuario Archivo local

Figura 3.8: Diagrama de Flujo de Datos: Cliente, Nivel 0

´ CAP´ITULO 3. ANALISIS



Modelo del proceso cliente: Nivel 1 Descendiendo a un nivel más profundo hay varios procesos que aparecen separados por su exclusivización y por su importancia: - La conexion inicial con el servidor es un momento particular. Debe haber un proceso que obtenga de la interfaz gráfica los datos del socket y dirección IP del servidor, y le env´ıe cierto mensaje con el login y el password del cliente. - Cada mensaje que se env´ıe al servidor debe seguir un peque˜ no protocolo para jerarquizar los datos y que éste pueda gestionarlo más habilmente. Al revés sucede lo mismo. - Cuando el usuario profundiza en el nivel principal que le muestra la interfaz gráfica pide impl´ıcitamente que se le muestren las tablas de una base de datos o las bases de datos que puede ver. Las sentencias SQL que esto requiere deben ser procesadas automáticamente, igual que cuando se traen o env´ıan tablas a MySQL. - Las tablas están en memoria y desde la interfaz gráfica pueden modificarse. Hay más ocasiones en las que se hace esto que las que a simple vista el usuario puede imaginar, y en cada redibujado es necesario recargar la tabla, debe haber un proceso encargado de esto. De manera más desglosada, puede estudiarse la figura 3.9.

SERVIDOR

Traducir en sentencias SQL las instrucciones implícitas

Convertir en mensaje para el servidor

SERVIDOR

Gestión de la conexion Interfaz gráfica

usuario

Tratamiento de mensajes leídos en el socket Tratamiento tablas Archivo local importado

Archivo local

Figura 3.9: Diagrama de Flujo de Datos: Cliente, Nivel 1.

´ CAP´ITULO 3. ANALISIS

3.3.2.



Modelo del proceso servidor

Modelo del proceso servidor: Nivel 0 – uno Desde un punto de vista superficial, y sobretodo, desde las exigencias del proceso cliente, el proceso servidor tiene s´olo dos entidades externas por las que fluye la informaci´on en entrada o en salida: ya sea el cliente a traves del socket, o la base de datos (la figura 3.10 muestra esto con claridad).

TCP/IP desde el cliente

Proceso servidor

MySQL

Figura 3.10: Diagrama de Flujo de Datos: Servidor, Nivel 0 – vista superficial Modelo del proceso servidor: Nivel 0 – dos Sin embargo, el proceso servidor debe ser entendido con dos dimensiones. Por una parte profundizar en sus subprocesos de la misma manera que con el proceso cliente, pero por otra, el proceso servidor deberá encerrar cierto grado de concurrencia para poder atender a todos los clientes: - Existe un proceso principal, que abre un socket general de escucha que debe ser conocido por el cliente. Cada vez que entra una nueva conexion por este socket, se debe abrir otro socket y decirselo al cliente, para que hablen por él, para poder liberar de nuevo el socket general. Cuando el cliente comprende esto, el proceso principal genera otro subproceso que gestiona concurrentemente a ese cliente en particular y que conoce el socket asignado. - Por su parte, cada proceso concurrente generado permanece en un bucle, en el que escucha los mensajes del cliente y después de cotejarlos con la base de datos, env´ıa las respuestas correspondientes y se pone a la escucha de nuevo. Aunque con una sola dimensión, la figura 3.11 intenta mostrar la primera parte de lo explicado. En el proceso principal recae la continuidad del servidor. Aunque no sea as´ı con el resto de subprocesos, la creación y terminación de cada proceso concurrente debe ser impecable para que el sistema no se colapse nunca por esta razón. De la misma manera, la gestión de los sockets debe ser cuidadosa. La figura 3.12 representa el estado del servidor al llegar un nuevo cliente y pudiéndolo haber duplicado más veces, dibujando más clientes, hubiera quedado una imagen muy representativa de la carga del servidor.

´ CAP´ITULO 3. ANALISIS



Servidor proceso principal

cliente

concurrente dedicado i

MySQL

Figura 3.11: Diagrama de Flujo de Datos: Servidor, Nivel 0 – un cliente

Cliente i

Servidor proceso principal

Concurrente dedicado i

Cliente ii

Concurrente dedicado ii MySQL

Figura 3.12: Diagrama de Flujo de Datos: Servidor, Nivel 0 – dos clientes Modelo del proceso servidor: Nivel 1 en el proceso principal Al nivel que aqu´ı interesa, la parte del proceso servidor que no atiende en profundidad las cuestiones del cliente, no necesita información acerca de la base de datos ni provinente de ella. Permanecer a la escucha por el socket inicial (conocido). Cuando llega una conexión automáticamente lee el mensaje entrante y: 1. Abre un socket a parte, por el cual se comunica con el cliente. 2. Crea un proceso concurrente que atiende las peticiones que entren por este socket.

Modelo del proceso servidor: Nivel 1 en el proceso concurrente Las necesidades para atender al cliente pueden desglosarse es:

´ CAP´ITULO 3. ANALISIS

Cliente



Escucha conexiones

Lanzar parte concurrente

Abrir socket

Figura 3.13: Diagrama de Flujo de Datos: Servidor, Nivel 1 – principal - Una primera gesti´on del login y el password que responde seg´ un la base de datos acepte o no a dicho usuario. - Gestionar los mensajes que env´ıa el cliente y separar de ´el las sentencias SQL que incluyen en el caso que as´ı sea, o generando las sentencias impl´ıcitas como en el caso de la desconexion. - Emitir las sentencias SQL a la base de datos y recoger los resultados. - Enviar al cliente los resultados obtenidos por de la base de datos.

Interpretar cadena en socket

Cliente

Emitir consulta SQL

Evaluar conexion

MySQL

Traducir en mensaje para el cliente

Figura 3.14: Diagrama de Flujo de Datos: Servidor, Nivel 1 – proceso concurrente

3.4.

Modelo del comportamiento

No parece ser necesario un estudio profundo sobre los distintos estados que podr´an apreciarse interna o externamente en el cliente ni en el servidor. Aunque

´ CAP´ITULO 3. ANALISIS



no quede cerrada una sección de diagramas que describa el comportamiento y la transición entre los estados, deben quedar anotadas ciertas cuestiones fundamentales: - El proceso cliente tiene tanto en una versión gráfica como en una versión de pruebas dos estados importantes. + Conectado a la base de datos. Sólo es posible si el usuario entra correctamente la IP del servidor, el puerto de escucha es conocido y un login y un password que la base de datos reconozca. Además el servidor debe dar la respuesta correspondiente. Este estado determinará el resto del comportamiento del cliente. + Desconectado: es el estado inicial y final si todo sigue un curso normal. - En cada conversación entre cliente y servidor la secuencia debe ser: 1. Pregunta del cliente. 2. Respuesta del servidor. Que uno u otro estén a la espera de una respuesta, es un estado determinante y que debe ser cuidado, pues un mal funcionamiento har´ıa inestable a ese proceso.

Cap´ıtulo 4 Dise˜ no orientado al flujo de datos 4.1.

Discusi´ on sobre la Orientaci´ on a Objetos

Considerando que puede enfocarse el dise˜ no (y, en general, la construcción del software) ya sea desde el punto de vista del flujo de los datos por cada uno de los procesos o a su través; o bien siguiendo una filosof´ıa de Orientación a Objetos1 . En el cap´ıtulo 3 (página 11) se ha dejado esta contradicción abierta, razonando que a´ un no estaba lo bastante maduro el análisis del problema como para pensar en qué filosofia de dise˜ no le era la apropiada. Es hora de abordarla. A favor de la Orientación a Objetos podr´ıa apuntarse: + El manejo de los sockets puede enmascararse para su uso y hacer esta tarea más trasparente a la hora de abordar los procesos de comunicación (pregunta/respuesta) entre cliente y servidor. + El manejo de las tablas en el interfaz gráfico quizá merece pensarse desde la OO, pudiéndose diferenciar lo que es el contenido de la información de sus metodos de representación en pantalla o de modificación. + Se pueden resolver otras tareas como clases, separando información y métodos, creando quizá una clase que encierre lo relativo a las sentencias SQL, su traducción, las sentencias impl´ıcitas que encierran ciertas acciones del usuario, etc. Se pueden encontrar, sin embargo, razones determinantes para descartar este tipo de filosofia: - La resolución de este problema, incorpora dos poderosos aliados en los que apoyarse, para resolver una buena parte de las tareas: 1

El dise˜ no OO permite ((construir sobre tres pilares fundamentales: abstracción, ocultamiento de la informaci´ on y modularidad.)) Aunque todos los métodos de dise˜ no procuran esto el ((DOO proporciona un mecanismo que permite al dise˜ nador conseguir las tres sin complejidad)) definición de [9] en su tercera edici´ on.

˜ CAP´ITULO 4. DISENO



· Por un lado la base de datos (en este caso MySQL) facilitará el manejo de la información (de los registros) y las cuestiones de seguridad de acceso de forma inmediata. · La interfaz gráfica propia del sistema o lenguaje de programación que se decida utilizar deberá integrar mecanismos para almacenar lo representado en pantalla de manera que la tabla cargada no necesite ser manejada por el programador a más nivel que el usuario de una librer´ıa. Por otra parte, si se programan métodos para cambiar el contenido de la tabla que requieren nuevos accesorios propios de la interfaz gráfica como cuadros de diálogo y ventanas, acabar´ıan creándose ciclos (ocultos por las clases creadas) en el uso de la librer´ıa gráfica. - El manejo de los sockets también debe ser facilitado por el lenguaje de programación utilizado. Concebir este problema como una tarea complicada es erróneo. El cliente y el servidor sólo necesitan dialogar y el cliente es siempre el que pregunta. - No hay necesidad de prevenirse para una posterior herencia en una fase de mantenimiento perfectivo2 . Y aunque este tipo de práctica siempre eleva la calidad, en este caso ser´ıa exactamente matar moscas a ca˜ nonazos. Har´ıa más complejo el trabajo y no resolver´ıa ni mejorar´ıa nada en particular. NOTA: Obsérvese que en esta sección se han introducido impl´ıcitamente algunas necesidades que deberán ser tenidas en cuenta a la hora de elegir el lenguaje de programación, las librer´ıas gráficas y las librer´ıas de sockets que ofrezca.

4.2.

Dise˜ no arquitect´ onico

Determinaci´ on del flujo de datos (primera revisi´ on DFDs) Repasando sobretodo las figuras 3.8, 3.9, 3.10 y en general todos los diagramas de flujo de datos que se han utilizado en la fase de análisis se puede descartar que haya un flujo de transacción. En el cap´ıtulo correspondiente de [9] Pressman define este tipo de flujo de la información cuando los datos se ((mueven a lo largo de un camino de entrada que convierte la información del mundo exterior en una transacción. La transacción se eval´ ua y basándose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos de acción. El centro del flujo de información del que parten los caminos de 2

Ya se explic´ o en 1.2 que uno de los objetivos del trabajo es abrir un camino para poder ampliar en el futuro el software cliente-servidor de manera que todas las actividades necesarias puedan resolverse desde este sistema y en particular desde el cliente.

˜ CAP´ITULO 4. DISENO



acción se denomina centro de transacción)). Y no existe en el cap´ıtulo de análisis ning´ un DFD con ese aspecto.

4.2.1.

Dise˜ no arquitect´ onico en el cliente

Descomposici´ on de primer nivel Atendiendo pues, a un punto de vista de flujo de trasformación y estudiando primeramente la figura 3.9 puede desglosarse el subproceso de interfaz gráfica desde dos intereses: ∗ La constante emisión gráfica de la tabla y del resto de variables de entorno que supone tener una ventana para la aplicación y los diferentes men´ us y submen´ us. ∗ Las ocasionales entradas de datos que el usuario hace para modificar registros de la tabla o variables como los datos de la conexión, los datos desde Ms-Excel, etc. Como muestra la figura 4.1, la interfaz gráfica se dividir´ıa en varios procesos diferenciándose lo que es la salida gráfica propiamente dicha de las entradas de valores de la conexión, de la tabla o las instrucciones impl´ıcitas si el usuario interactua con la tabla. De la misma manera se separa la salida a nivel local ya sea de información de la tabla al disco (en un archivo Ms-Excel ) o la salida por pantalla; de las salidas de información o preguntas al servidor. Descomposici´ on de segundo nivel Con la subdivisión de la figura 4.1 se puede presentar una descomposición de segundo nivel con un aspecto de árbol propio de la notación de una jerarqu´ıa de control. Siguiendo una partición estructural de tipo horizontal en la figura 4.2 se ha hecho una primera aproximación desglosando por niveles de profundidad y separando la entrada de la salida a nivel local, aunque la interfaz gráfica sea un concepto que cubra uno y otro servicio. La relación entre los DFDs y los diagramas de arquitectura como el que se ha traladado a la figura 4.2 no debe ser tomada, en esta fase, como una biyección perfecta entre módulos; Pressman en [9] dice que ((se pueden combinar dos o incluso tres burbujas y representarlas como un solo módulo, o una sola burbuja puede dividirse en dos o más módulos (...) La revisión y el refinamiento pueden llevar a cambios en la estructura, pero puede servir como una primera iteración del dise˜ no.))

˜ CAP´ITULO 4. DISENO



Proceso de la conexión

Convertir en mensaje para el servidor

Comunicación son servidor

Respuestas con datos SERVIDOR

SERVIDOR Tramiento tabla en ámbito remoto

Entrar datos a tabla

Navegar por base de datos

usuario

Archivo local importado

Valores conexión

Entorno interfaz gráfica

usuario

Tratamiento tabla en ámbito local

Archivo local

SALIDA

Procesos de ENTRADA

Figura 4.1: Diagrama de Flujo de Datos: Cliente, Nivel 1 refinado – descomposici´on de primer nivel Aplicación cliente

Entrada datos local

Navegar entorno bd Valores conexion

Salida datos local (interfaz gráfica) Entrar datos a tabla

Grabar tabla localmente

Valores conexion

Mostrar tabla

Comunicación servidor

Conexión inicial

Sentencias para MySQL

Menús interactivos

Figura 4.2: Estructura del cliente (partici´on horizontal) – descomposici´on de segundo nivel

4.2.2.

Dise˜ no arquitect´ onico en el servidor

Descomposici´ on de primer nivel Lo u ´ nico que requiere de especial la fase de dise˜ no del proceso servidor es atender a la presencia de un proceso concurrente que atiende las peticiones de cada cliente

˜ CAP´ITULO 4. DISENO



y un proceso principal. Por todo lo demás, el proceso servidor, es a´ un más sencillo que el del cliente y la conversión de los DFDs mucho menos problemática. El diagrama de flujo de datos del servidor, en la profundidad uno, tanto del proceso principal como del proceso concurrente, puede dejarse tal cual en la revisión y en el refinado. Las figuras 3.13 y 3.14 muestran con claridad los problemas que habrá que abordar a la hora de desarrollar el servidor. Descomposici´ on de segundo nivel Más aun, de una manera a´ un más expl´ıcita y menos arbitraria, se puede diferenciar que el proceso servidor tiene dos v´ıas de comunicación con subdivisiones de entrada y salida, en lo que a la parte concurrente se refiere. En relación al proceso principal se han apuntado en la figura 4.3 los tres frentes en los que –con el nivel de conocimiento que puede tenerse en esta fase– se entiende que habrá que construir esta parte del servidor. La figura 4.4 separa la parte de la Servidor proceso principal

Generación del proceso concurrente

Escuchar peticiones de el/los cliente/s

Figura 4.3: Estructura del servidor – descomposición de segundo nivel, proceso principal conexión inicial del cliente del resto de ejes de construcción del servidor. Por la manera en que se ha dividido los diagramas del servidor atendiendo a su multiplicidad y a su concurrencia, la fase de conexión es un proceso donde intervienen todos los factores en el servidor de manera concentrada: - Información del login y el password que el usuario ha introducido en el cliente. - La confirmación de la base de datos. - La creación de un socket dedicado para el nuevo cliente. - La instanciación de un proceso concurrente que resuelva las peticiones del cliente por separado.

˜ CAP´ITULO 4. DISENO



De todas maneras, como la propia figura 4.4 muestra, se trata de un proceso3 muy peque˜ no, que se puede concretar en la fase de implementaci´on sin problemas, con algo de cuidado. Servidor proceso concurrente

Gestión de la conexión inicial a la base de datos

Recoger mensajes y tratarlos (IN)

Trato con el cliente

Emitir datos al cliente (OUT)

Trato con la base de datos

Emitir sentencias SQL

Recoger resultados

Figura 4.4: Estructura del servidor – descomposici´on de segundo nivel, proceso concurrente

4.3.

Postproceso de dise˜ no

En esta sección se han de tratarse principalmente tres aspectos propios de la fase que Pressman define en [9] como postproceso y que en este caso se han considerado los más importantes: - Desarrollar una descripción del procesamiento para cada módulo. - Una descripción de la interfaz para cada módulo. - Anotar las restricciones y limitaciones del dise˜ no. Concretamente, conviene releer que ((un texto explicativo del procesamiento es una delimitada descripción sin ambig¨ uedades del procesamiento que ocurre dentro de un módulo. La narrativa describe el procesamiento, las tareas, las decis´ıones y la entrada/salida)). Y resaltar que en cuanto a la interfaz, convendrá detenerse a concretar la entrada y la salida del sistema en cada módulo, al tiempo que postergar lo relativo a las interfaces entre módulos y las interfaces hombre-computadora que se abordarán en secciones siguientes. Es interesante respetar la jerarqu´ıa de los árboles que se han dibujado en secciones 3

Sigue refiri´endose a la ”gesti´ on de la conexi´on inicial a la base de datos”.

˜ CAP´ITULO 4. DISENO



anteriores, no sólo para facilitar el trabajo en esta sección y su lectura sino también para poder anotar las limitaciones que se van encontrando en el dise˜ no y que se deberán tener en cuenta en próximas fases.

4.3.1.

Descripci´ on de m´ odulos en el cliente

Para entender las tablas de esta sección, se deben cotejar conjuntamente con la figura 4.1 en la página 31 y los DFDs de los que procede. El objetivo de esta sección es reducir el máximo n´ umero de módulos a una descripción más o menos inmediata. Comprender en ese proceso las debilidades del modelo y dejar previstas el resto de cuestiones para fases posteriores de desarrollo con el máximo nivel de entendimiento. Nombre del m´ odulo Proceso Entrada Salida Descripci´ on

grabar tabla localmente cliente tabla en memoria archivo en disco con formato Ms-Excel Permite al usuario nombrar el archivo y ubicarlo localmente. Le da una extensi´on xls al nombre y graba en ´el, el contenido de la tabla que hay cargada en memoria y que el interfaz visualiza.

Cuadro 4.1: Descripci´on m´odulo: Grabar tabla localmente.

Nombre del m´ odulo Proceso Entrada Salida Descripci´ on

entrar datos a la tabla cliente interfaz de usuario (teclado y ratón) tabla en memoria y visualización en pantalla Ms-Excel Permite al usuario ver la tabla que está cargada en memoria de una manera intuitiva. Elegir la columna o registro que quiere modificar y modificarlo de forma inmediata viendo los resultados en pantalla.

Cuadro 4.2: Descripci´on m´odulo: Entrar datos a la tabla.

˜ CAP´ITULO 4. DISENO

 Nombre del m´ odulo Proceso Entrada Salida Descripci´ on

mostrar la tabla cliente tabla en memoria local visualizaci´on –en pantalla– de la tabla de manera intuitiva Debe sacar por pantalla cada vez lo que realmente hay en la memoria. Debe respetar el contenido en los redibujados.

Cuadro 4.3: Descripci´on m´odulo: mostrar la tabla. Nombre del m´ odulo Proceso Entrada Salida Descripci´ on

valores de la conexión cliente interfaz de usuario (teclado y ratón) variables globalescon la información La dirección del servidor, el puerto de escucha (del mismo), el login y el password del usuario son cuatro valores necesarios para la conexion inicial a la base de datos. Hace falta pedirlos y almacenarlos para el resto de la conexión.

Cuadro 4.4: Descripción módulo: valores de la conexión.

Limitaciones en el modelo del cliente Avanzar la descripción de los módulos provista en esta fase del refinado de los DFDs, su estudio y su descomposición: aproxima una visión más real del trabajo hecho hasta ahora, sus limitaciones y algunas de las dificultades que a´ un no han sido resultas. - La cuestión de la estructura de datos que contiene en memoria a la tabla inicializada o cargada (ya sea desde un archivo o desde la base de datos), no ha sido finalmente abordada hasta el momento. El riesgo de tropezar más adelante con una interfaz gráfica o un soporte propio del lenguaje de programación que resuelva esto sigue invitando por el momento a postergar esta decisión, pero al mismo tiempo debilita la visión global que se tiene y supone una dependencia de un entorno de trabajo (librer´ıas, lenguajes de programación, etc) que a´ un no se disponen. - Algunos de los módulos han quedado ambig¨ uos o diluidos por ser demasiado generales y no se han descrito en las tablas de estas páginas. Sus tareas, sin

˜ CAP´ITULO 4. DISENO Nombre del m´ odulo Proceso Entrada Salida Descripci´ on

 conexion inicial cliente variables de la conexion (IP-Servidor y Socket-Escucha-Servidor ) estado general conectado o no (a almacenar en una variable global) El cliente se conecta primero con el servidor seg´ un el IP-Servidor y el Socket-Escucha-Servidor que introduce el usuario. Si tiene ´exito despu´es pide al proceso servidor que le conecte a la base de datos y que le haga de intermediario (partiendo del login y el password introducidos por el usuario).

Cuadro 4.5: Descripci´on m´odulo: conexion inicial.

Nombre del m´ odulo Proceso Entrada Salida Descripci´ on

sentencias para MySQL cliente interfaz del usuario (teclado y rat´on) sentencias SQL encuadradas en un mensaje al servidor El usuario puede manipular en entorno de la tabla, cambiar registros, a˜ nadir columnas, etc. Las sentencias SQL que generan estas acciones impl´ıcitamente o las que el usuario introduzca directamente de manera expl´ıcita son env´ıadas al proceso servidor en un mensaje debidamente enmarcado cuyo aspecto el servidor conoce.

Cuadro 4.6: Descripci´on m´odulo: env´ıo de sentencias SQL.

embargo, siguen siendo diferentes y en fases de implementación deberá revisarse sobretodo los DFDs y documentar debidamente en qué partes del código han quedado dichas soluciones.

˜ CAP´ITULO 4. DISENO



4.3.2.

Descripci´ on de m´ odulos en el servidor

Para esta parte deben examinarse las tablas revisando las figuras 4.3 y 4.4 (en la p´agina 32) y tenerse en cuenta que el proceso servidor se ha estudiado por duplicado desde la fase de analisis teniendo en cuenta su concurrencia. Nombre del m´ odulo Proceso Entrada Salida Descripci´ on

generar proceso concurrente servidor (proceso principal) Socket para hablar con el cliente un manejador de proceso En esta parte el proceso servidor lanza (en connivencia con el sistema operativo) un proceso concurrente que escucha las peticiones del cliente.

Cuadro 4.7: Descripci´on m´odulo: generar proceso concurrente.

Nombre del m´ odulo Proceso Entrada Salida Descripci´ on

conexión con la base de datos servidor (proceso concurrente) login y password del usuario en el cliente lista con las bases de datos que puede ver ese usuario o negativa Con la información del usuario que remotamente está conectado desde el cliente, el proceso servidor (ya en su parte concurrente) pide conexión a la base de datos, obteniendo acceso y mostrando al usuario sus bases de datos accesibles o devolviéndole una negativa.

Cuadro 4.8: Descripción módulo: conexión inicial con la base de datos.

Limitaciones en el modelo del servidor Igual que cuando se ha procedido al refinamiento y estudio de los DFDs del cliente para describir sus módulos, se trata ahora de ver qué debilidades han aparecido al hacer lo propio con los módulos del servidor: - Examinando los módulos del proceso concurrente y la figura 4.4 (en la página 33) se nota que se han desglosado excesivamente (aunque con el buen objetivo

˜ CAP´ITULO 4. DISENO Nombre del m´ odulo Proceso Entrada

Salida Descripci´ on

 escuchar peticiones de los clientes servidor (proceso principal) Mensaje por socket de escucha del servidor con el n´ umero del socket de escucha del cliente un n´ umero de socket del servidor dedicado exclusivamente a ese cliente Primer bis a bis entre cliente y servidor. El servidor escucha (por definición). Un cliente llega y le dice por qué socket (del cliente) solicita conversar. El servidor crea su propio socket para hablar con aquél y ambos liberan la conversación inicial (es necesario que el servidor libere su socket general de escucha pues por este le llegaran nuevas peticiones).

Cuadro 4.9: Descripci´on m´odulo: escucha de peticiones del cliente (primer bis a bis cliente-servidor). Nombre del m´ odulo Proceso Entrada Salida Descripci´ on

recoger mensajes del cliente y tratarlos servidor (proceso concurrente) Mensaje por socket enviado por el cliente retorno por el mismo socket de la respuesta El preceso concurrente espera cada mensaje del cliente. Lo examina y eval´ ua separando la sentencia SQL si existe. Consulta con la base de datos, recoge la respuesta y la reenvia enmarcada debidamente en una ristra com´ unmente acordada. Muy importante, la respuesta puede suponer un envio o m´as, el proceso servidor coordina esto y avisa debidamente al cliente.

Cuadro 4.10: Descripci´on m´odulo: escucha de consultas en el servidor.

de separar mecanismos diferentes) los m´odulos de entrada y salida ya sea con el cliente o con la base de datos. A la hora de describir dichos procesos resulta

˜ CAP´ITULO 4. DISENO

 Nombre del m´ odulo Proceso Entrada Salida Descripci´ on

pregunta respuesta SQL servidor (proceso concurrente) sentencia SQL respuesta de la base de datos En este proceso se emite a la base de datos la sentencia SQL y se recoge (de forma multiple si es necesario) la respuesta.

Cuadro 4.11: Descripción módulo: gestión de consultas del servidor.

más cómodo y mucho más intuitivo juntarlos pues la salida se debe a la entrada y no puede entenderse por separado. Queda para fases posteriores la decisión del nivel de subdivisión que se le va a dar a las cuatro ramas del árbol que en las tablas han aparecido como dos módulos. - El inicio en el servidor: llegada de un nuevo cliente, generación de socket dedicado, generación de un proceso concurrente y posterior conexión a la base de datos ha sido separado atendiendo sobretodo a la multiplicidad en el servidor. Este mecanismo puede resolverse de muy distintas maneras y en posteriores fases de desarrollo, en función de cómo se resuelva la gestión de los sockets quedará como se ha mostrado aqu´ı o con otro ((ritmo))4 .

4.4. 4.4.1.

Dise˜ no de la interfaz Notas previas

Volviendo una vez más a Pressman en [9] entiéndase por interfaz los tres casos siquientes: - ((El dise˜ no de interfaces entre los m´ odulos software)) Esta parte no será abordada en esta sección, porque la sencillez con la que hasta el momento se ha resuelto la comunicación entre los datos y los procesos, invita a pensar que en posteriores fases del desarrollo, podrá resolverse de una manera más o menos inmediata, y si hiciera falta revisar lo aqu´ı descrito ser´ıa entonces el momento correspondiente donde exlicarlo. - ((El dise˜ no de interfaces entre el software y otros productores y consumidores no humanos de informaci´ on los m´ odulos software)) 4

Se refiere a la secuencialidad de los di´alogos entre el cliente y el servidor.

˜ CAP´ITULO 4. DISENO



En el caso de este sistema, se trata del interfaz con el proceso cliente (como entidad externa del servidor) y el interfaz con la base de datos. S´ı que se ha escrito sobre ambos: ∗ Con respecto al interfaz entre el servidor y el cliente se ha decidido, y ya se ha escrito sobre ello, que habrá una comunicación mediante sockets, es decir, un interfaz TCP/IP. También se ha descrito en distintos momentos que a la hora de enviarse mensajes, cliente y servidor, deben encapsular sus env´ıos en un marco conocido por ambos. Con aspecto de lo que en otro nivel5 se podr´ıa concebir como una trama o un paquete. La descripción de esta interfaz se ha postergado a fases posteriores. Pero antes o después debe ser abordada pues se trata de la piedra angular para la comunicación entre el cliente y el servidor. ∗ La interfaz entre el servidor y la base de datos está en función de las librer´ıas que permitan la conexión con la base de datos. Sabiendo que está será MySQL puede recordarse aqu´ı que en la sección 3.1.2 (página 12) se valoraba como una ventaja de MySQL que pod´ıa ser invocada desde diferentes lenguajes de programación. Como a´ un no se ha decidido nada acerca del lenguaje de programación el dise˜ no de dicha interfaz queda pendiente, aunque no será necesario de una manera expl´ıcita si el lenguaje que definitivamente se utilice es lo bastante potente (y esto es una aspecto importante para que resulte elegido). - ((El dise˜ no de la interfaz entre el hombre y la computadora)) Entendiendo que sobre esto a´ un no se ha descrito nada, conviene profundizar un poco más y (siguiendo los pasos de Pressman en [9]) abrir el apartado dedicado a esta discusión.

4.4.2.

Consideraciones sobre el dise˜ no de la interfaz hombrem´ aquina

La figura 3.4 en la página 18 mostraba tres tipos de usuario diferentes. Lo que debe importar de ellos en esta sección es su conocimiento sintáctico6 y semántico7 del sistema: - El administrador del sistema no debe preocupar al dise˜ nador (además por el momento ambas figuras son la misma). Tiene (o debe tener) conocimiento 5

Se refiere a otro nivel en el modelo por capas que la literatura al respecto propone para describir las comunicaciones entre computadoras. 6 Pressman lo define en [9] como ((mec´ anica necesaria para usar la interfaz eficazmente)). 7 ((Sentido subyacente de la aplicaci´ on: una comprensi´ on de las funciones que se ralizan, el significado de los datos de entrada y de salida y las metas y los objetivos del sistema)).



˜ CAPÍTULO 4. DISENO completo del sistema. Es el u ´ nico que maneja el proceso servidor con lo que esta interfaz puede ser simple, aunque s´ı clara, y puede ser en modo consola. - Algunos de los comerciales deben ser considerados usuarios novatos. Sin conocimiento sintáctico. La l´ınea de demarcación para construir la interfaz hombremáquina en la aplicación cliente debe rebajarse hasta ellos. La imagen del sistema debe guiarles en sus operaciones y sólo deben necesitar información adicional para resolver la conexión inicial, proceso que una vez aprendido debe ser sencillo. - Los gestores pueden ser considerados usuarios frecuentes (con ((conocimiento semántico razonable pero con recuerdo vago de la información sintáctica))). Lo que hay que considerar de ellos es que trabajan en el mismo entorno del servidor. Pueden resolver cualquier dificultad in situ pues no trabajan remotamente. Pueden disponer de notas, de ésta u otra documentación, y de la ayuda del administrador del sistema. De todas maneras lo más importante es que si los usuarios novatos pueden utilizar la interfaz gráfica de la aplicación cliente ellos deben tenerlo más fácil. A efectos de dise˜ no de la interfaz hay que atender a las consideraciones de usuario novato de momento. Aunque se prevea un tiempo para capacitarlo, éste será ´ınfimo.

Cap´ıtulo 5 Implementaci´ on Todas aquellas cuestiones que a´ un no han quedado resueltas, todas aquellas decisiones que (por una u otra raz´ on) aun no han sido tomadas, deben ser abordadas en esta fase. Eso s´ı, siempre que entren en el terreno de m´ as bajo nivel de abstracci´ on: la implementaci´ on o el trabajo directo. Por otra parte, incluso el m´ as experto de los cirujanos, habiendo estudiado concienzudamente los pormenores de una intervenci´ on, teniendo preparadas las radiograf´ıas, las anal´ıticas y al anestesista, antes de comenzar observa por s´ı mismo el estado del paciente, comprueba la hora en su reloj, la totalidad del material y su limpieza, etc. Algunas cosas solamente se pueden comprobar en la pr´ actica directa.

5.1. 5.1.1.

Decisiones previas El lenguaje de programaci´ on

Seguramente, una de las decisiones más importantes que quedan por tomar. Por qué lenguaje tomar partida. En principio no hay ninguna obligación de elegir uno u otro en particular, pero s´ı que es menester, antes de tomar ninguna decisión, apuntar qué criterios1 para elegir el lenguaje de programación se han ido contemplando hasta el momento y jerarquizarlos (de más importante a menos importante): 1. Tiene que ser uno de los enumerados en la sección 3.1.2 ya que lo que s´ı que está decidido es que la base de datos será MySQL, recuérdense estas posibilidades: C, C++, Eiffel, JAVA, Perl, Python, Ruby y Tcl. 2. Debe permitir un c´ odigo facilmente portable entre Linux y Windows, ya que el entorno en la Oficina puede variar, y a´ un siendo Linux el cliente correrá en equipos Linux (de la oficina) y Windows indistintamente. 3. Es preferible que sobrecargue el sistema lo menos posible. 1

En la secci´ on 4.1 ya se habl´ o algo sobre ello, se trata aqu´ı de recordarlo y recoger otros criterios que se hayan visto en otras secciones o apuntar otros que se consideren ahora.

´ CAP´ITULO 5. IMPLEMENTACION



4. Debe poder acceder a información de Ms-Excel, al menos.Ya se ha comentado que actualmente se trabaja en un entorno de Microsoft Office y los usuarios van a necesitar informes que posteriormente tratarán desde Excel, al cual ya están habituados. 5. Interfaz gráfico para Windows y para Linux (aunque no se haya dicho expl´ıcitamente es evidente que tener un proceso que lo automatice o unas buenas librer´ıas es un criterio). 6. Manejo de sockets inmediato.

Alternativas independientes de la plataforma La primera criba (que elegir MySQL ha establecido) proporciona una lista de 9 lenguajes de programación de entre los que decidir finalmente. El siguiente de los criterios se refiere a la plataforma, y al hecho, de que el lenguaje que sea elegido finalmente debe funcionar tanto en Windows como en Linux. Es interesante, por lo tanto, ver qué alternativas existen al respecto2 : ∗ C/GDK/GTK: Lenguaje de programación C y librer´ıas gráficas GDK y GTK. Ventajas: + La potencia y la buena (e histórica) relación de C con Linux. + Las librer´ıas gráficas GDK y GTK son bastante poderosas. Desventajas: - ((El conjunto de GDK y GTK est´ a dise˜ nado para ser independiente de la plataforma y en cierta medida dependiente del lenguaje. Lamentablemente los ports de GDK no est´ an tan extendidos en plataformas no Linux. Por otra parte las librerias de C espec´ıficas son generalmente ligadas a la plataforma. Por lo que habr´ıa que comenzar a combinar c´ odigo genérico con c´ odigo espec´ıfico, lo que complica el desarrollo)). Esta es sin duda la razón más determinante para descartar C. - El trato de la memoria (sobretodo), a menudo queda en C en manos del programador, esto es una desventaja en beneficio de alternativas como JAVA. En otras palabras, la rigidez en la que educa C a sus partidarios y que desde un punto de vista académico puede ser interesante, aqu´ı representa una losa prescindible. ∗ C++/QT: Las ventajas y desventajas de utilizar C++ ser´ıan las mismas que en el caso anterior. La u ńica diferencia es que C++ permite Orientación a Objetos de una manera natural, pero ya se ha dicho en 3 y en 4.1 que esto era completamente innecesario. 2

Se ha tomado como referencia el sitio web http://linux.ubiobio.cl donde qued´o plasmado el 3o Encuentro Linux UBIOBIO 2002 en la Universidad del B´ıo-B´ıo (campus Concep-

ci´on)– Chile–, todas las citas en esta secci´on se refieren a lo discutido en dicha web.

´ CAP´ITULO 5. IMPLEMENTACION



∗ C#/GTK#: Esta ser´ıa una alternativa interesante, tanto desde el punto de vista de la actualidad como desde un punto de vista académico, por desgracia, seg´ un su manual (ver [6] en la bibliograf´ıa), MySQL no soporta esta posibilidad todav´ıa. ∗ JAVA: En principio, JAVA es una alternativa muy prometedora. Se trata de un lenguaje independiente de la plataforma que incluye la ventaja del garbage collector que ((se encarga de reasignar la memoria de objetos que ya no estén siendo referenciados.)) El caso merece ser estudiado con algo más de profundidad.

¿Por qu´ e no JAVA? Para un usuario ne´ ofito es dif´ıcil averiguar, sobre un lenguaje de programaci´ on que no ha utilizado, lo suficiente para saber si le interesa o no en una aplicaci´ on concreta. Normalmente no se escriben tratados caracterizando la naturaleza de un lenguaje de programaci´ on sino que existen manuales y la experiencia proporciona al programador una visi´ on de conjunto. Por otra parte hay muchos m´ as manuales y textos redactados por partidarios que por sus detractores y nadie hace cr´ıticas severas a ning´ un lenguaje de programaci´ on, porque si ha tenido que vérselas con él, normalmente habr´ a saltado los obst´ aculos y aprovechado sus propiedades. No hay mucho tiempo que perder en esta cuesti´ on, as´ı que como tampoco se ha encontrado mucha literatura al respecto la secci´ on que sigue ha quedado resuelta sobre la base de cotejar informaci´ on de distintas fuentes (tanto Internet como programadores habituados a JAVA). Si el lector queda anegado por la incertidumbre de las referencias a Internet es tan grave (sino m´ as) como que al autor le haya pasado lo mismo. Lo justo es reproducir en esta secci´ on las conclusiones m´ as claras que se tienen de la manera m´ as parecida a como se han conseguido. Tomando primeramente desde http://www.qualitrain.com3 donde aparece una comparación entre JAVA y VBasic se pueden aceptar cuatro criterios generales en lo referente a una arquitectura cliente-servidor a la hora de elegir el lenguaje de programación: - La complejidad de la arquitectura. - La migración de la arquitectura de 2 a 3 capas. - Las necesidades de la organización4 . - El presupuesto asignado para implantar esta tecnolog´ıa. Las ventajas que ofrece JAVA son: 3

Referencia web de Qualitrain Express que ((inici´ o operaciones en noviembre de 1996, ofreciendo los servicios de capacitaci´ on, consultor´ıa especializada en tecnolog´ıas de objetos e implantaci´ on de metodolog´ıas de desarrollo orientadas a objetos.)). 4 La organizaci´ on donde se usar´ a la aplicaci´ on.

´ CAP´ITULO 5. IMPLEMENTACION



+ El JDK5 es una herramienta libre de licencias (sin coste) y ampliamente utilizada. + Es independiente de la plataforma. + ((Existen, dentro de su librer´ıa, clases gr´ aficas como awt y swing, las cuales permiten crear objetos gr´ aficos comunes altamente configurables y con una arquitectura independiente de la plataforma.)) + Se trata de un lenguaje ((de moda)). Su avance, su uso y su conocimiento están a la orden del d´ıa y siguen ampliandose documentaciones y libros. + ((Se puede acceder a bases de datos f´ acilmente con JDBC, independientemente de la plataforma utilizada. El manejo de las bases de datos es uniforme, es decir transparente y simple.)) Aunque JAVA parece ser una alternativa definitiva hay que estudiar sus desventajas, que también tiene, seg´ un parece: - Con respecto a la portabilidad: ((para manejo a bajo nivel deben usarse métodos nativos)). En cuanto que limitación de la portabilidad esto s´ı es una desventaja. - ((El dise˜ no de interfaces gr´ aficas con awt y swing no es simple. Existen herramientas como el JBuilder que permiten generar interfaces gr´ aficas de manera sencilla, pero tienen un costo adicional.)) - Parece que no está claro que haya soporte JDBC6 para bases de datos no comerciales, es una desventaja en cuanto a que puede limitar el campo de mira en el futuro. En las actuales condiciones, soportando MySQL hay más que suficiente.

La lentitud de JAVA Por el momento las caracter´ısticas siguen invitando a su uso. No obstante, el tercer requisito que ha sido incluido en 5.1.1 es que el lenguaje no debe sobrecargar el sistema. La arquitectura de JAVA incorpora la máquina virtual de JAVA (a partir de ahora sólo JVM): ((un procesador software (virtual) que se dedica a procesar las instrucciones del programa y se entienda con el hardware y el sistema operativo)). Lo que el compilador de JAVA genera es un ((byte code)) intermedio que es igual para todas las plataformas y que la JVM traslada en cada caso. Las consideraciones al respecto de esta ((técnica)) son muchas y diversas a lo largo y ancho de Internet y de la literatura al respecto. Lo que interesa a la hora de la verdad es si el resultado es eficaz y eficiente. Hace unos a˜ nos, muchos de los estudios y discusiones sobre este tema afirmaban con rotundidad que JAVA era bastante más lento que C y C++. Siempre se ha atribuido este problema al hecho de incorporar un proceso intermediario entre la aplicación, y el sistema operativo y el hardware. La figura 5.1 y la tabla 5.1 son el resultado de un estudio comparativo entre C++ y JAVA 5 6

JAVA Development Kit o kit de desarrollo para JAVA. Java Database Connectivity.

´ CAP´ITULO 5. IMPLEMENTACION



Figura 5.1: C++ versus JAVA – ((el tamaño más grande representa quién es mejor)) publicado por la revista JDJ (Java Developer’s Journal8 ) del grupo Sys-Con Media9 . Se trata de un art´ıculo hecho con el objetivo de demostrar que, actualmente, la tesis de que ((JAVA es lento)) (o ((más lento que ...))) es más bien una leyenda del pasado. Hay que tener en cuenta que las pruebas se lanzaron en un ordenador portatil ((Pentium 4 mobile chip)) con 512 Megabytes de memoria (aunque –eso s´ı– con un peque˜ no y lento ´ sistema operativo era Red Hat Linux 9/Fedora con la versión 2.4.20-20.9 disco duro). El del kernel. Las pruebas demostraron que en la mayor´ıa de casos, JAVA era superior a las versiones de 8

El diario para desarrolladores de JAVA. SYS-CON Media (Montvale, NJ), fundado en 1994 ((ampliamente reconocido entre las industrias de publicaci´ on de revistas y de tecnolog´ıa en Internet como el lider mundial en publicaciones . . . )) traduciendo directamente de su p´agina web que puede visitarse en http://www.sys-con.com. 9

´ CAP´ITULO 5. IMPLEMENTACION



Ackermann Fibonacci Hash2 Hash Heapsort Matrix Method call Nested loop Object creation Random no. gen. Sieve String concatenation Sumcol Word count

G++ 3.3.1 JAVA 1.4.2 Intel 386 Intel 686 Server JVM Client JVM 60.95 39.03 34.53 N/A7 49.41 43.13 33.12 49.78 21.11 21.62 9.96 14.56 16.43 16.51 7.93 86.76 20.04 19.63 21.59 20.47 10.58 10.76 14.95 30.55 24 20.49 2.47 39.18 12.63 15.08 23.42 32.57 24.88 23.47 6.4 7.17 21.29 15.12 29.99 57.08 16.54 16.53 15.08 16.66 2.49 1.79 2.6 2.99 9.11 8.51 6.69 12.75 4.37 4.27 3.02 3.89

Cuadro 5.1: C++ versus JAVA – tabla de tiempos ((el tamaño más pequeño (siempre en negrita) representa quién es mejor)).

C++. Si bien las versiones que utilizaban el JAVA client eran manifiestamente peores.

Una conclusi´ on provisional Los puntos más débiles (recapitulando) que finalmente han supuesto no elegir –de momento– JAVA, son (por orden de importancia): 1. El sistema de la JVM que utiliza JAVA para tener independencia de la plataforma arroja la sombra de duda. Los benchmarks de la revista JDJ por un lado tranquilizan pero por otro lado asustan: Parece demasiado importante para los partidarios de JAVA demostrar la rapidez de éste y su ((no inferioridad)) con respecto a C. En el sistema al que se deben estas páginas, no puede haber posibilidad de dudas. Como se vio en el primer cap´ıtulo, el equipo cliente puede ser cualquier equipo y es importante que la instalación y lanzamiento del proceso cliente sean lo más rápidas posible y no sobrecarguen el sistema en dicha máquina. 2. La dependencia de la JVM crea problemas a la hora de generar un archivo ejecutable en JAVA. Esto es posible pero no es inmediato. A˜ nadiendo a las necesidades citadas en el caso anterior hay que decir que lo más interesante es que el usuario disponga para el equipo cliente un ejecutable que resuelva concentradamente la apliación. Otro tipo de formatos que compliquen más ese proceso y requieran del usuario la instalación de la JVM es aqu´ı un lastre a evitar. Hay una diferencia importante entre ser independiente de la plataforma y tener fácil portabilidad entre plataformas.

´ CAP´ITULO 5. IMPLEMENTACION



3. En lo que a programaci´ on (más bien codificación) se refiere, aunque no se ha profundizado previamente, JAVA es fuertemente Orientado a Objetos y tanto en la sección 3 como en 4.1 ya se ha explicado que esa no es aqu´ı ninguna prioridad. Esta caracter´ıstica le hace a JAVA ser a veces demasiado complicado para una sentencia sencilla. El cl´ asico ((hola mundo!)) en JAVA seg´ un parece, se implementar´ıa seg´ un algo as´ı: public class HelloWorld { public static void main (String[] args) { System.out.println("Hello, world!"); } } Tenga presente el lector que JAVA es, en general, una magn´ıfica y muy atractiva oferta, pero que puede ser algo incómodo para este caso. Por eso conviene estudiar más alternativas antes de decantarse por la primera.

¿Por qu´ e no Perl? Como Perl se ha convertido pr´ acticamente en un paquete org´ anico a todas las distribuciones Linux algunas de las dudas al respecto se han resuelto en esta secci´ on probando (con telnet) directamente un peque˜ no script en el servidor slabii.uv.es de la Universidad de Valencia. Lo cu´ al hace buena publicidad de lo inmediato que resulta a veces el uso de este lenguaje.

Un int´ erprete independiente de la plataforma Dentro del mundo de los lenguajes de programación se puede decir que hay dos posibilidades: Los lenguajes de programación (propiamente dichos, como C, C++ o JAVA10 ) y los lenguajes de scripting 11 o (en espa˜ nol) interpretados (como Perl, Visual Basic, Python o Tcl). Citando al propio Larry Wall (creador de Perl): ((un script es lo que se le da a los actores, un programa es lo que se le da a la audiencia)). Tradicionalmente se llamaba script al ((guión)) o archivo de instrucciones que se le introduc´ıa directamente al intérprete del sistema operativo para resolver de manera más automatizada ciertas tareas de administración. Los lenguajes interpretados han revolucionado esta concepci´ on y la han ampliado enormemente. Perl nace del mundo de Unix. Su creador lo dise˜ nó en 1987 inicialmente como un lenguaje de script para fortalecer y simplificar ciertas tareas de administración del sistema operativo. De hecho, sus siglas12 significan algo as´ı como lenguaje práctico de extracción de 10

En esta taxonom´ıa se ha colocado a JAVA acompa˜ nando a C y C++ aunque ya se ha escrito sobre su curiosa arquitectura que lo diferencia de C y C++. 11 script en ingl´es significa gui´ on. 12 Practical Extraction Report Language.

´ CAP´ITULO 5. IMPLEMENTACION



informes. Desde entonces hasta nuestros d´ıas, entre otras muchas ampliaciones con las que la comunidad Open Source ha contribuido, Perl tiene int´erpretes para una buena variedad de sistemas operativos.

Figura 5.2: La arquitectura de Perl La figura 5.2 muestra la arquitectura de Perl13 . El script del programador, es traducido a un código intermedio optimizado. Lo que se conoce genéricamente con el nombre de ((opcode)) (ya se ha comentado un caso particular con el ((byte code)) de JAVA). Un ((opcode)) es una especie de c´ odigo máquina14 que ((en lugar de ser interpretado por la m´ aquina es interpretado por una m´ aquina virtual)). La diferencia de este proceso entre JAVA y Perl es que mientras que el ((byte code)) de JAVA pierde el tiempo en el intérprete, el ((opcode)) de Perl (por otra parte, de un nivel de abstracción mucho más alto) se combina con ((un gran n´ umero de opcodes que se corresponden con herramientas disponibles en el nivel del usuario)). Esto explicar´ıa15 por qué Perl es mucho más rapido que JAVA.

Algunas comodidades de Perl Una de las ventajas de Perl es que existen una gran variedad de m´odulos o paquetes (lo que en C se llamar´ıan librer´ıas). La inmensa mayor´ıa de ellos son contribuciones libres de programadores particulares y que vienen catalogados, caracterizados y documentados en http://www.cpan.org desde donde se pueden descargar e instalar. Pero adem´as de 13

Esta figura y lo fundamental de esta sección está extra´ıdo de [4]. En inform´ atica se llama c´ odigo m´ aquina al código binario que en u ´ ltima instancia interpretan los microprocesadores 15 Siempre seg´ un Sriram Srinivasan 14

´ CAP´ITULO 5. IMPLEMENTACION



ello, a partir de la versión 5.6, Perl dispone de un potente Package Manager 16 que es una aplicación cliente que puede, en el host local, buscar e instalar los paquetes, desde distintos sitios de Internet. Estos se configuran de acuerdo al sistema que uno tiene y el package manager o ppm avisa si ya están en la actual configuración. Con respecto a la fácil portabilidad (concepto que ya se ha diferenciado de la capacidad de la independencia de plataforma), lo que el usuario final quiere y obtiene en Perl, es que puede descargarse libremente el u ´ltimo intérprete (por ejemplo) para Linux y para MsWindows desde http://www.ActiveState.com y sus scripts corren, dando los mismos, resultados tanto en un sistema como en otro.

Concurrencia en Perl Esta es una cuestión importante para decidirse, porque en el sistema que ata˜ ne a esta discusión, como se ha dicho, será necesario desarrollar un servidor concurrente. Aunque lo que no se ha dicho, en su correspondiente sección, es que parece que la implementación de la concurrencia en JAVA es uno de sus puntos fuertes. As´ı que en esta cuestión, vencer´ıa la decisión por JAVA en detrimento de Perl. Partiendo de que se puede desarrollar la concurrencia desde dos puntos de vista (a nivel de implementaci´ on) conviene echar un vistazo en cada uno de ellos cómo está Perl de fuerte. Más adelante convendrá discutir y decidir cuál de ambos métodos utilizar: - Procesos o fork(): Parece ser que Perl soporta el estándar Unix de fork/exec para multiples procesos as´ı que en este sentido no parece tener gran inconveniente. Tanto en la documentaci´ on de Perl como en otros manuales, aparece el uso de esta funci´ on con un aspecto prácticamente calcado de C. - Hilos: La literatura al respecto de la manera en que Perl implementa esta técnica parece estar quedando obsoleta. Las referencias en Internet, en la propia documentaci´ on de Perl e incluso en las referencias bibliográficas (página 120) que cierran este documento; arrojan la sombra de duda al decir que se trata de una versión experimental. Perl incluye esta versión experimental desde su versión 5.005 pero lo cierto es que tras la inclusi´ on de un nuevo modelo de implementación en la versión 5.6 y los sucesivos ajustes, a d´ıa de hoy puede decirse que Perl soporta hilos. Y con la versión 5.8.4 (la u ´ltima a fecha de redacción de esta p´ agina) Perl soporta hilos en Windows (cosa que en versiones anteriores emulaba enmascarando un fork() por debajo).

Ejecutables con Perl Se ha apuntado como una desventaja de JAVA que no era inmediato crear archivos ejecutables para lanzar los programas, directamente a partir del código. Pues bien, en Perl existe la misma desventaja o todav´ıa más, pues realmente, por lo que respecta a Larry Wall y al equipo oficial, cualquier cuestión que se diga acerca de esto, es una mera promesa. A parte de meter el script en un código de C no parece haber muchas posibilidades. 16

administrador de paquetes

´ CAP´ITULO 5. IMPLEMENTACION



Efectivamente, esta ser´ıa una razón de peso para abandonar la posibilidad de Perl si no llegara, al rescate, una contribuci´ on no exactamente de la Perl community no muy ortodoxa pero bastante más potente de lo que a primera vista parece. Se trata de la aplicación perl2exe. Como el propio nombre indica17 , se trata de un programa que genera archivos ejecutables partiendo de un script de Perl. Tras unas cuantas pruebas, sobre la potencia de perl2exe al generar ejecutables para Windows, no puede quedar ninguna duda. También pueden generarse ejecutables para Linux con perl2exe pero esta posibilidad no se ha probado directamente puesto que no va a ser necesaria. Eso s´ı, hay que leer su documentación y quizá a˜ nadir alguna l´ınea comentada al código del script que para el intérprete oficial de Perl serán solo comentarios pero que perl2exe interpretará como detalles especiales a cerca de las librer´ıas que se han usado, y podrá enlazarlas ((por s´ı mismo)) a la hora de generar el código. Hay que aclarar, que en realidad, perl2exe utiliza el intérprete local de Perl para trabajar. Sobre la garant´ıa de perl2exe el lector puede juzgar por s´ı mismo. Se trata de una obra de la compa˜ n´ıa canadiense IndigoSTAR. Una mediana empresa que da debido aguantar desde 1997 sobre la base de ser subcontratista de empresas como Microsoft, IBM, Dell, HP/Compaq, Intel, AMD, General Motors, Ford, Shell, BP, Boeing, Airbus, Siemens y el mism´ısimo ejercito de los Estados Unidos de América. Todo lo referente a este programa puede encontrarse en una modesta página web 18 donde también hay información de otros programas de IndigoSTAR. En lo relativo a las licencias, la versión más barata de perl2exe vale 50 dólares estadounidenses19 . Pero existe una versión shareware siempre disponible en la página web que tiene lo fundamental, no caduca y lo u ńico que supone es imprimir en ASCII20 un cartel de publicidad de IndigoSTAR. As´ı que para lo que ata˜ ne a estas páginas, es como si fuera gratuito.

La decisi´ on final Posiblemente el lector, tenga una premonición de quién es el ganador de esta batalla. Aunque el autor tiene otro nivel de conocimiento que antes de llegar a este punto del camino, conviene contemplar que hay otras alternativas y dedicarles algo de atención: - Tcl, Ruby y Python: Las propiedades de estos lenguajes son parecidas a las de Perl. En la mayor´ıa de referencias y de literatura sobre ellos aparecen grandes elogios y similitudes con Perl. Por el momento la sensación subjetiva del que se sumerje en este oceano de referencias y comparativas es que son buenos competidores pero inferiores. Si no en facilidad de uso, al menos s´ı en ((séquito)). Los partidarios y libres contribuyentes de Perl (o Perl Mongers) como se ha dicho antes, son uno de los principales alicientes de Perl y constituyen una de sus garant´ıas. 17

Este juego de palabras es t´ıpico, en vez de ((Perl to exe)), en espa˜ nol ((Perl a exe)) (de executable) ponen un n´ umero dos que en ingl´es se pronuncia igual que la preposici´ on ((to)) 18 http://www.indigostar.com 19 50$ son unos 40.68e, o sea, 6,768.74 pesetas (esto esta calculado seg´ un divisas de junio de 2004) 20 Se refiere a que lo imprime por pantalla tras la ejecuci´on del programa

´ CAP´ITULO 5. IMPLEMENTACION



- PHP: Aunque representar´ıa una muy buena alternativa, PHP parece más bien propio del mundo del servicio web y las aplicaciones cliente/servidor correspondientes. No es el caso, por lo tanto, de usarlo. Por si queda alguna duda, conviene aclarar por qué se ha decidido finalmente utilizar Perl: 1. Es independiente de la plataforma y fácilmente portable. 2. Es más rápido que JAVA seg´ un se ha discutido. 3. Es compatible con MySQL. 4. Está completamente libre de licencias. 5. Es fácil de aprender y se parece al famoso C (ya se ha dicho –y ejemplificado– que para el programador novato JAVA parece complicar un poco ciertas cosas). 6. Tiene librer´ıas gráficas para desarrollar programas de ventanas portables con Linux y con Windows. 7. Todas las librer´ıas pueden descargarse facilmente con su ppm 21 y están ampliamente documentadas.

5.1.2.

Una aplicaci´ on gr´ afica en Perl para un entorno de ventanas

Una vez tomada la decisi´ on m´ as pesada, resulta mucho m´ as sencillo avanzar hacia la soluci´ on porque el campo se ha acotado. Sin embargo, aparecen nuevas dudas.

Alternativas Por definición la biblioteca estándar de Perl en lo que se refiere a aplicaciones con ventanas es Perl/Tk. Sin embargo su implementación no es precisamente amigable. Se trata de la primera aproximación para resolver esto y está pre˜ nada de varios aspectos: - Las dolencias y debilidades del primer (lenguaje de script) Perl. Más destinado (y estructuralmente pensado) para ser un lenguaje de shell que de entornos gráficos. - En cuanto a su parte gráfica, Perl está más acostumbrado a ser complemento de CGI22 en páginas web que (otra vez) de entornos gráficos. El recurso más sofisticado al respecto estar´ıa en el paquete para Visual Studio .NET. La principal desventaja es que no está libre de licencias. Visual Perl tiene un entorno gráfico donde pueden gozarse de una buena parte de las habituales ventajas de Visual Studio .NET: 21

Perl Package Manager (se ha visto anteriormente) Common Gateway Interface o est´ andar para programas pasarela externa que necesiten una interfaz con servidores de informaci´ on (como servidores HTTP) 22

´ CAP´ITULO 5. IMPLEMENTACION

 Editor de c´ odigo Debugger gr´afico.

Una herramienta para simplificar las expresiones regulares. Arbol de clases Gestor del proyecto Integración de un kit de desarrollo para Perl. Control del c´ odigo fuente. Aunque la información para resolver esta sección está extra´ıda de fundamentalmente de http://www.ActiveState.com y http://www.microsoft.com y no ha habido, por lo tanto, práctica directa sobre el mismo, la sospecha de que Visual Perl está en la otra cara de la moneda de lo que Perl (y el mundo del Open Source) representa está completamente justificada. Seg´ un eso, muchas de las caracter´ısticas que se han apuntado como bondades de Perl estar´ıan en tela de juicio. Lo principal desde luego, sigue siendo la cuestión financiera, pero con todo lo dicho, llegados a este punto, parece estar más cerca el retroceso hasta JAVA que el avance hasta Visual Perl Lo que se ha venido calificando, desde una sensación subjetiva del que se sumerge en Internet buscando sobre Perl, como el ((séquito)) de Perl, Los Perl Mongers o la comunidad Perl: Todo este fen´ omeno, se hace doblemente cierto cuando se particulariza en el descubrimiento de Prima23 . Prima es una biblioteca alternativa a Perl/Tk con todas sus ventajas y ninguna de sus debilidades. Es más moderna, ha sido desarrollada en los u ´ltimos a˜ nos en la Universidad de Copenhage para cubrir las necesidades de un proyecto de biolog´ıa. Tiene un constructor gráfico que genera un esqueleto de c´ odigo de acuerdo al esquema que introduce el usuario. No tan sofisticado como el que pueda tener Visual C++ pero desde su sencillez, bastante u ´til. Además, tiene la ventaja de que sólo interviene en un archivo y es f´ acil comprobar lo que ha hecho. Por lo que el programador más novato no se ve ((en manos)) de trozos de código que no conoce, no entiende y ni siquiera mira. Por alguna razón las librer´ıas de Prima, aunque también están documentadas en la http://www.cpan.org, son poco populares. Ninguno de los libros citados en la bibliograf´ıa (revisar página 120), en efecto, hablan de Prima. Esto se debe seguramente a que Perl ya tiene una biblioteca gráfica estándar y quizá sus partidarios más radicales no quieren ninguna más. Pero lo cierto es que Prima es muy potente, está muy documentada y trae varios ejemplos que agilizan mucho su estudio. Todo lo referente a Prima puede encontrarse en http://www.prima.eu.org. 23

Aunque el acr´ onimo no es perfecto se refiere a Perl Graphic Toolkit o paquete de herramientas gr´aficas para Perl

´ CAP´ITULO 5. IMPLEMENTACION



Dentro de Prima (la EDA para las tablas) Prima ofrece, intr´ınsecamente, una serie de módulos y funciones que facilitan muchas posibilidades gráficas y que (aunque sea insitencia) Perl/Tk no tiene. Uno de ellos es el grid que parece el primer candidato para representar una tabla. El aspecto resultante es (aunque más tosco) parecido al que muestra Ms-Excel. En la documentación (véase [2]) y en los ejemplos que trae el paquete puede probarse con: $g = $w-> insert( ( $abstract_grid ? ’Prima::AbstractGrid’ : ’Prima::Grid’ ), origin => [0, 0], size => [$w-> size], ( $abstract_grid ? () : (’cells’, [ map { my $a = $_; [ map {"$a.$_"} 0 .. 300]} 0 .. 300])), growMode => gm::Client, onMeasure => sub { my ( $self, $axis, $index, $ref) = @_; if ( defined $user_breadths[$axis]->{$index} ) { $$ref = $user_breadths[$axis]->{$index}; } else { $$ref = ( 11 - ( $index % 11)) * 15; $$ref = 15 if $$ref < 15; } }, onSetExtent => sub { my ( $self, $axis, $index, $breadth) = @_; $user_breadths[$axis]->{$index} = $breadth; }, onDrawCell => sub { my ( $self, $canvas, $col, $row, $type, $x1, $y1, $x2, $y2, $X1, $Y1, $X2, $Y2, $sel, $foc) = @_; $canvas-> backColor( $sel ? $self-> hiliteBackColor : ( $type ? $self-> indentCellBackColor : cl::Back)); $canvas-> clear( $x1, $y1, $x2, $y2); $canvas-> color( $sel ? $self-> hiliteColor : ( $type ? $self-> indentCellColor : cl::Fore)); $canvas-> text_out( "$col.$row", $X2-50, $Y1+3); $canvas-> rect_focus( $x1, $y1, $x2, $y2 ) if $foc; }, allowChangeCellWidth => 1, allowChangeCellHeight => 1, #clipCells => 1, );

A quien le parezca muy complicado debe tener en cuenta que lo más importante es que con eso ya está todo hecho. En efecto, el ejemplo del que se ha extra´ıdo esta sección de código no es mucho mayor. Se ha definido una red en cuyas celdas aparecerá mapeada la tabla. $abstract_grid ? () : (’cells’, [ map { my $a = $_; [ map {"$a.$_"} 0 .. 300]} 0 .. 300])),

´ CAP´ITULO 5. IMPLEMENTACION



Puede controlarse el contenido y medidas de cada celta y capturarse los eventos. El problema que tiene esta estructura es que la tabla debe ser una matriz que el programador maneje. Esto es un poco embarazoso teniendo en cuenta que el paso de los cambios en el contenido de la matriz, desde el entorno gráfico a la memoria y viceversa habr´ıa que resolverlos ((a mano)). Por eso conviene estudiar las distintas implementaciones de listas y visores de listas que trae Prima. Entre ellos, para listas de más de una columna o matrices, existe Prima::detailedlist (en Perl se caracteriza a un módulo dentro de una librer´ıa de módulos poniendo los dos puntos dos veces ((::))). La ventaja de la lista detallada (o detailed list) es que entre sus atributos hay uno llamado items que se carga al principio con la tabla (que hay que construirla primero –eso s´ı– en un array convencional) y después puede utilizarse a lo largo y ancho del programa. En este ejemplo $miDetailedList-¿items: $miDetailedList=$main->insert(DetailedList=> columns=> $globalcolumnas, name=> ’ListaGlobal’, multiColumn=> 0, origin=> [0,0], size=> [$main->size], growMode => gm::Client, headers=> [@matriz], items=> $ref_items, gridColor=> onSort=> onClick=> onSelectItem=> onKeyDown =>

cl::Black, sub{}, sub{}, sub{}, sub{}

);

A la izquierda aparecen las propiedades y atributos. Los entornos sub{} son para implementar (dentro) la función correspondiente como reacción a ese evento. NOTA: Recuérdese que en la sección 4.3.1 (página 35) esta cuestión quedó pendiente: resolver la relación rec´ıproca entre lo que hay almacenado en la memoria sobre la tabla y la representaci´ on gráfica de esta. Pues bien, he aqu´ı una solución satisfactoria.

5.1.3.

Compatibilidad Ms-Excel

Se ha mencionado en los cap´ıtulos 1, 3 y 4 que la parte del cliente debe admitir – de entrada/salida– informaci´on compatible con el entorno Office de Microsoft, por varias razones entre las que estaban que la base de datos est´a actualmente funcionando en Access

´ CAP´ITULO 5. IMPLEMENTACION



y no se migrará por completo, que los gestores trabajan con informes y están habituados a Excel, etc. En los cap´ıtulos 3 y 4 aparec´ıa por activa y por pasiva una función en cada gráfico que se comunicaba de alguna manera con este entorno y se concretó que cuanto menos, el cliente deb´ıa entenderse con Ms-Excel y poder portar información con él. Se ha indicado y se ha caracterizado, pero no se ha resuelto. Es hora de afrontar, desde el terreno del lenguaje de programación, las posibilidades que ofrece Perl y el propio entorno de Microsoft para resolver esta cuestión aparentemente tan trivial.

Componentes de Miscrosoft Repasando las librer´ıas de Perl, lo primero que salta a la vista es la librer´ıa Win32 y dentro de ésta concretamente el módulo Win32::OLE. El paquete Win32 resuelve (como no podr´ıa ser de otra manera) distintas funciones para acceder24 a APIs de Win32. Genericamente, se habla de arquitectura de componentes cuando en un programa se utilizan módulos especializados que se enlazan o utilizan dinámicamente en tiempo de ejecución. Son por tanto módulos binarios cerrados (no trozos de código ni paquetes de librer´ıas, que ser´ıa lo propio de la Orientaci´ on a Objetos). Lo que esta idea promueve es la especialización masiva del software. También facilita el dise˜ no y permite usar software ajeno con permiso del due˜ no pero sin poder modificarlo (superando también en esto a la filosof´ıa de la Orientaci´ on a Objetos). En lo que a estas páginas ata˜ ne, Microsoft ofrece un servicio de componentes llamado R componentes COM+. ((Las clases administradas se generan con Microsoft Visual Studio .NET y después se instalan en aplicaciones COM+ para obtener servicios COM+, como las transacciones, la agrupaci´ on de objetos y la sem´ antica de actividad)), habitualmente25 : Las clases y módulos en la librer´ıa Win32 de Perl, están desarrolladas por socios activos de la Perl community autores de infinidad de art´ıculos y protagonistas de varias conferencias. La librer´ıa Win32, aunque lleva el copyright de Microsoft, su uso esta cubierto por licencia p´ ublica26 de GNU. Desde Perl basta con hacer algo como: sub generarhoja { eval { $ObjetoCOM::ex = Win32::OLE->GetActiveObject(’Excel.Application’) }; die sub { ImprimirVentana ("Error","Excel no est´ a instalado"); } if $@; unless (defined $ex) 24

API es el acr´ onimo de ((Interfaz para programas de aplicaci´ on)) (Application Program Interface), as´ı que quiz´ a deber´ıa decirse m´ as bien utilizar el API de Win32 25 M´as informaci´ on en http://www.Microsoft.com 26 Todo lo relativo a GPL se ha dado por sentado en este trabajo, el lector profano puede informarse en http://www.fsf.com

´ CAP´ITULO 5. IMPLEMENTACION

 {

$ObjetoCOM::ex = Win32::OLE->new(’Excel.Application’, sub {$_[0]->Quit;}) or die sub {ImprimirVentana("Error","No se puede iniciar Excel");}; } $libro=$ObjetoCOM::ex->WorkBooks->Open($_[0]); $hoja=$libro->Worksheets(1); }

Lo que en este extracto de código aparece como la instancia de una clase (hablando de la variable ((hoja))), en realidad es un manejador de un componente Excel que tiene activa esa hoja (o tabla). Con un resultado muy potente (por lo capaz) se puede interactuar de utilizando esta librer´ıa con Excel. La librer´ıa Win32 incluye métodos para hacer esto y lo cierto es que resulta bastante fácil e inmediato, como el ejemplo muestra. Las desventajas por las que finalmente esta técnica no se ha elegido son las siguientes: - Es lento, sobretodo para hojas de gran tama˜ no. Crea dos capas, en el uso de los recursos, en tiempo de ejecución y lastra al proceso principal (que en este caso ser´ıa la aplicación cliente y no la aplicación de Excel). - Requiere que el usuario tenga instalado y bien configurado el paquete correspondiente de Microsoft, aunque esto no es complicado, para un usuario novato27 puede ser problemático. - Pero sin duda, lo peor de todo, es que no es una alternativa portable. La aplicación cliente –en el ámbito de los usuarios que gestionen la base de datos– deber´ıa correr sobre Windows, lo que robar´ıa prestaciones, partiendo de que el servidor corre sobre una máquina Linux o Unix que puede ser incluso la misma. Acceso a archivos *.xls En lo que a este sistema se refiere, es suficiente con poder incorporar información tra´ıda desde Excel de la manera que sea, basta con leer los propios archivos28 y generar archivos excel partiendo de una tabla en memoria. La solución de utilizar componentes, aunque muy espectacular y quizá recomendable para otras necesidades es –además de las desventajas que se han mencionado– demasiado sofisticada para las necesidades que hace falta cubrir en este caso. En una nueva b´ usqueda por http://www.cpan.org puede descubrirse el paquete de 27

Este perfil se ha caracterizado en la sección 4.4.2 en la página 40 siguiendo los pasos de Pressman en [9] 28 Los archivos que maneja Excel son siempre nombrados con una extensión xls (y de ah´ı el t´ıtulo de esta secci´ on)

´ CAP´ITULO 5. IMPLEMENTACION



librer´ıas ((Spreadsheet)). Dentro de ((Spreadsheet)) hay varias posibilidades, se trata de crear una manera sencilla de leer archivos desde Excel. Para este ejemplo se ha utilizado una de las formas m´as sencillas: $xls=Spreadsheet::ParseExcel::Simple->read($fichero); $RegistrosTabla=0; foreach $sheet ($xls->sheets) { while ($sheet->has_data) { @data = $sheet->next_row; push @GlobalItems, [@data]; $RegistrosTabla++; } }

El uso de la instrucción push es necesario para simplificar el almacenamiento en una matriz29 . La variable ((data)) ser´ıa un vector en el ejemplo, y ((GlobalItems)) una matriz. Para saber el n´ umero de columnas bastar´ıa con poner en otra variable el contenido de ((@data)), puesto que, en contexto escalar, Perl interpreta ((@data)) como el cardinal del vector ((data)). La variable ((fichero)) en el ejemplo debe almacenar la referencia absoluta del path donde esté la tabla de Excel (por ejemplo ((C:\tablas\agenda.xls))). Esta librer´ıa nos permite: Un acceso sencillo a la información. Funciona igual en Linux y en Windows. Es rápido y sólo hace falta llamarla una vez, frente a los componentes COM que necesitan utilizar el procesador y la memoria en paralelo a la aplicación que los invoca.

5.1.4.

Concurrencia: ¿Hilos o procesos?

Hasta ahora, en cap´ıtulos anteriores, se ha hablado de la concurrencia que necesita el proceso servidor para atender las peticiones del cliente. Lo que no se ha dicho en ning´ un momento es cómo resolverlo. Partiendo de que existen estas dos maneras de interpretar la idea de la concurrencia en el nivel de la implementación, esta discusión tiene interés práctico para este caso, en al menos, estos dos frentes: ¿El ejemplo que se ha descrito es propio de una de las dos filosof´ıas? En concreto con Perl ¿es más recomendable alguna de las dos? 29

En realidad Perl no tiene matrices sino vectores, para crear una matriz hay que utilizar un vector de vectores que, finalmente se le referencia como a una matriz de C

´ CAP´ITULO 5. IMPLEMENTACION

 Hilos y/o procesos en Perl

Esta cuestión, de gran interés para los afinionados a Perl, no tiene un gran eco en la literatura. Lo más interesante ya se ha comentado en 5.1.1 (ver página 50). Existen intervenciones al respecto las distintas conferencias de la Open Source que pueden visitarse en los detallados informes que se han colgado de http://conferences.oreillynet.com, pero ninguno de estos art´ıculos (ni siquiera el de Gurusamy Sarathy de 2002 que incluye las trasparencias de su exposición) resuelve las dudas acerca de las prestaciones entre uno y otro modo, dentro de Perl. Lo u ńico que se puede a˜ nadir, casi anecdóticamente, es la introducción con la que el propio Larry Wall abre el c´ ap´ıtulo correspondiente en [1]: ((imagina coger una receta de un libro de cocina y convertirla en algo que varias docenas de cocineros puedan guisar al mismo tiempo, puedes encontrar dos aproximaciones: Una, darle a cada cocinero una cocina privada y completarla con su propio aprovisionamiento de ingredientes, materiales y u ´tiles. Para recetas que son f´ acilmente dividibles en partes es f´ acil y también para comidas que pueden ser trasportadas de cocina a cocina, esta aproximaci´ on funciona bien porque mantiene a cada cocinero fuera de las otras cocinas. Alternativamente t´ u puedes poner a los cocineros en una cocina y dejarles trabajar (...) esto puede ser peligroso, especialmente cuando los cuchillos de cocina empiezan a volar)). El ejemplo sirve para ejemplificar ambos casos30 , pero lo curioso es que la imagen de la metáfora no puede ser más desafortunada (o quizá se pens´ o as´ı a propósito ¿alguien puede imaginar un restaurante funcionando de la primera manera?). Si as´ı es como son los hilos y los procesos en Perl, la opci´ on de utilizar multiples procesos quedar´ıa descartada.

Por qu´ e usar hilos Olvidando lo que respecta a Perl en concreto, la aplicación servidor que se ha visto en las fases anteriores es t´ıpica de un dise˜ no con hilos. - Cuando no hay nuevas consultas en el socket es un buen momento para que el hilo quede bloqueado y pueda seguir otro. Suponiendo un caso t´ıpico de diez hilos atendiendo peticiones de diferentes clientes, los cambios de hilo serán rápidos y no puede perderse tiempo en ello. En definitiva, por ser ((peticiones que conducen a bloqueos)) es preferible utilizar hilos. - Puede ser necesario compartir, al menos entre el hilo principal y cada uno de los hilos dedicados, cierta información en forma de variables globales, lo cual será mucho más fácil con hilos que no con procesos. - En el futuro pueden a˜ nadirsele propiedades al hilo principal para que permita informar, al administrador del sistema, de los diferentes clientes que hay conectados 30

Se ha inclu´ıdo tambi´en para que un lector m´as profano pudiera comprender esta secci´ on

´ CAP´ITULO 5. IMPLEMENTACION



y todo tipo de estad´ısticas e ficheros de log sobre ellos. Entendiendo que, al fin y al cabo, no es más que un script de Perl, esta posibilidad es poco costosa y puede valer la pena en, sin duda, con una implementación basada hilos será menos complicada a la hora de modificar.

5.2.

Pruebas previas

Finalmente, como se ha dicho al principio del cap´ıtulo, conviene probar algunas librer´ıas básicas de Perl, para asegurar su funcionamiento y ganar confianza con ellas antes de utilizarlas de manera sistem´ atica. Anteriormente, se ha mostrado ejemplos de código formando parte de una discusi´ on entre varias dos posibilidades, ahora se hará, aunque no haya más de una posibilidad, por lo decisivas que son estas librer´ıas y aprender a utilizarlas correctamente.

5.2.1.

Acceso a Bases de Datos con Perl

Perl tiene varias librer´ıas que se ocupan de esta cuestión. Lo interesante en este caso es resolver la comunicación con MySQL. Para conectarse con exito a MySQL desde un script hay que tener un login y un password hábiles en MySQL (esto es igual que si se accede por consola) y además hay que conocer tres cosas, a saber: El nombre de la máquina donde está montada la base de datos de MySQL (puede ser la misma donde corra el script o no). El nombre de la base de datos al cual hay que acceder. Habitualmente MySQL cede una base de datos llamada test a todos los usuarios, as´ı que puede utilizarse esta (en principio). El socket de escucha de MySQL. Este es desconocido, no puede intentarse una conexión ((manual)) por él. Está guardado siempre en /var/lib/mysql/mysql.sock. Una secuencia de conexi´ on v´ alida para Perl ser´ıa: use DBI; my $driver="DBI:mysql:database=test"; my $host="host=$maquina"; my $socket="mysql_socket=/var/lib/mysql/mysql.sock"; my $dsn=join ’;’,($driver,$host,$socket); $dbh = DBI->connect($dsn,$login,$passwd) or $error="$DBI::errstr"; if ($dbh) { @dbs = $dbh->func(’_ListDBs’); }

´ CAP´ITULO 5. IMPLEMENTACION



En este ejemplo se ha hecho la conexión y despues una prueba utilizando una función (dentro del if ) que mostrar´ıa las bases de datos a las que el usuario tiene acceso. El parámetro host admite tanto una dirección de IP (147.156.16.31) como un nombre válido de máquina (slabii.uv.es).

5.2.2.

Sockets en Perl

Además de probar aqu´ı las librer´ıas de sockets de Perl (cosa que no tiene más complicación que estudiarse la documentación al respecto) ser´ıa interesante resolver la cuestión de la conexión inicial cliente servidor. El lector puede recordar (o combrobar) que en la sección 3.3.2 (página 24) se ha caracterizado este problema y se resolvió –a un primer nivel– en la fase de postproceso (del dise˜ no), generando (en la página 36) la tabla 4.5. Se trata de un primer diálogo informativo entre cliente y servidor que permita establecer una conexión entre ellos. Lo que hay que resolver, concretamente, es que el servidor pueda tener permanentemente un socket a la escucha y que la negociación inicial de una sesión entre el cliente y el servidor no limite al servidor la capacidad de atender más peticiones. Es una situación muy habitual, as´ı que no debe ser causante de ning´ un trastorno: el servidor ofrecerá siempre un mismo socket de n´ umero conocido, por el que entrarán las nuevas peticiones y a las que dedicará sólo unos segundos cada vez. En Perl, una secuencia válida para abrir un socket de escucha ser´ıa: $portescucha=1080; socket (EscuchaServer,PF_INET,SOCK_STREAM,getprotobyname(’tcp’)) or die "socket: $!\n";; setsockopt(EscuchaServer,SOL_SOCKET,SO_REUSEADDR,pack("l",1)) or die "setsockopt: $!\n"; bind (EscuchaServer,sockaddr_in($portescucha,INADDR_ANY)) or die "bind: $!\n"; listen (EscuchaServer,SOMAXCONN) or die "listen: $! \n"; ($p,$ip)=sockaddr_in(getsockname(EscuchaServer)); print "Servidor escuchando en el puerto $p del sitio ",inet_ntoa($ip),"\n"; print "Esperando cox...\n"; accept(ClienteActual,EscuchaServer);

La función ((accept)) de Perl, es bloqueante, es decir, el servidor queda suspendido aqu´ı mientras ning´ un cliente llega. Posteriormente, a esta instrucción (ya ha llegado un cliente) el servidor podrá comunicarse con aquél haciendo: sysread(ClienteActual,$datosentrantes,255); syswrite(ClienteActual,$datossalientes,255);

´ CAP´ITULO 5. IMPLEMENTACION



La conexi´on es bidireccional, de manera que si se cuida que el ritmo del di´alogo sea el mismo para ambos, puede utilizarse sin problemas el mismo socket. En la parte cliente habr´ıa que hacer: $iaddrsocket=$ip_server; $portsocket=$port_server; $aux=inet_aton($iaddrsocket); $paddrsocket=sockaddr_in($portsocket,$aux); socket(SocketCliente,PF_INET,SOCK_STREAM,getprotobyname(’tcp’)) or return((-1,"socket: $!\n")); connect(SocketCliente,$paddrsocket) or return((-1,"connect: $!\n"));

Donde la variable ((ip server)) ha de referirse a la dirección del servidor y la variable ((portsocket)) (cuyo contenido se ha copiado aqu´ı de ((port server))) se referirá al socket de n´ umero conocido que el servidor tiene disponible siempre. Resulta evidente que, en Perl, la variable $! (todas las variables comienzan por $) recoge el u ´ ltimo error producido. Para no abrumar mucho más con sesgos de código, se resolvera la cuestión del bis a bis (comentado al principio de esta sección) sólo en la parte del cliente. Ser´ıa a˜ nadir al ejemplo anterior lo siguiente: # crear una escucha propia: EscuchaCliente $port=$port_server; socket(EscuchaCliente,PF_INET,SOCK_STREAM,getprotobyname(’tcp’)) or return((-1,"socket: $!\n")); setsockopt(EscuchaCliente,SOL_SOCKET,SO_REUSEADDR,pack("l",1)) or return((-1,"set: $!\n")); # rudimentario bucle para buscar un numero de puerto que BIND acepte $bool=0; while ($bool==0) { $bool=1; bind(EscuchaCliente,sockaddr_in($port,INADDR_ANY)) or $bool=0; $port++; } ($port,$iaddr)=sockaddr_in(getsockname(EscuchaCliente)); listen(EscuchaCliente,SOMAXCONN) or return((-1,"listen: $!\n")); #print "Escucho por $port ",inet_ntoa($iaddr),"\n"; # Avisar al serviodr de que puede comunicarse con el cliente por esta ’escucha’ $linea="$port$EOL";

´ CAP´ITULO 5. IMPLEMENTACION



syswrite(SocketCliente,$linea,$LIM) or return((-1,"syswrite: $!\n")); close (SocketCliente); # cerrar el socket anterior para liberar al Servidor # aceptar entrada accept(SocketServer,EscuchaCliente) or return((-1,"accept: $!\n")); return(1,SocketServer,EscuchaCliente);

Juntando ambos ejemplos se podr´ıa formar una funci´on llamada bisabis que cubriera lo especificado en la tabla 4.5 antes mencionada.

Cap´ıtulo 6 Trabajos futuros: Personal Digital Assistant 6.1.

Introducci´ on

Para ser completamente fiel a la realidad, en el cap´ıtulo primero, no se ha mencionado en absoluto de la necesidad de introducir un PDA en todo este contexto. No es que se trate de una necesidad imperiosa y desde luego no ha sido un objetivo inicial pero, teniendo en cuenta las particularidades que se han descrito en el cap´ıtulo 1o , resulta evidente que proporcionar la posibilidad de que la aplicación cliente pueda también correr sobre un PDA ofrecerá un gran servicio a los usuarios finales y al sistema en general: - El usuario puede modificar en el acto los datos que le interesen. No necesita para una operación tan sencilla, disponer de un ordenador y de un acceso a Internet. - El servidor puede verse liberado de cierta carga porque si los usuarios sólo disponen de un entorno en ordenador personal, la tendencia es conectarse a la base de datos a unas horas determinadas (por ejemplo, por la noche al acabar la jornada). En cambio, el PDA les ofrece la posibilidad de llevar consigo una terminal remota. El objetivo de este cap´ıtulo es analizar las posibilidades de portar la parte cliente de la aplicación (interfaz gráfica) a un PDA. Allanando, de esta manera, las dudas que puedan surgir en la organización y dando una respuesta cuyo acabado satisgafa a unos y otros, y permita, a quienes tengan que tomar esta decisión, si se invierte o no el dinero necesario. 64

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



6.2.

Historia reciente

Antes de aparecer el PDA, exist´ıa el mercado variopinto de la agenda electrónica. Sin seguir apenas unos parámetros comunes, con dise˜ nos muy diversos, las distintas compa˜ n´ıas ofrec´ıan sus repertorios de modelos que pod´ıan variar desde calculadoras disfrazadas de algo más hasta artefactos algo más espectaculares. A pesar de todo, el uso de estos aparatos y su comercio en general, siempre tuvo más pasado que futuro, pues el perfil de su destinatario estaba más tentado por los avances en los ordenadores personales que por las virguer´ıas de estos inventos. El término Personal Digital Assistant (o PDA) fue acu˜ nado en 1992 por el empresa1 rio americano John Sculley para dar nombre al producto Apple Newton 2 . Se trataba de un PDA pionero que, aunque se adelantó a su época, ten´ıa un precio prohibitivo y no resolv´ıa satisfactoriamente la cuestión del reconocimiento de caracteres. Cerca del a˜ no 2000 el mercado de el PDA dio un primer salto y ganó una buena base de sus actuales entusiastas y usuarios. Los PDA de 2000 estaban muy lejos de los de hoy, aunque ya empezaban a resolver una parte importante de tareas: sincronización con datos desde el PC, compatibilidad con una buena variedad de documentos informáticos, agenda, calculadora, reloj, notas, portapapeles, contactos, escritura, etc. Con la llegada de las u ´ ltimas tecnolog´ıas para móviles y la posibilidad de incluir nuevas posibilidades a los PDAs, este invento se ha hecho muy popular. Las nuevas prestaciones (recursos inalámbricos, autonom´ıa de la bater´ıa, resolución de pantalla, audio y v´ıdeo, etc.) le han hecho al PDA tan novedoso como en su d´ıa lo fue el ordanador portátil: bonitos, potentes, portatiles y cada vez más baratos. El comprador y el posible comprador acaban viendo estos inventos más interesantes que sus aparatosos ordenadores de sobremesa que no mueven nunca. Salvando las distancias, porque el uso del portátil (que no es más que un PC superintegrado) es diferente que el del PDA. Al menos de momento.

6.3.

Posibles soluciones

Antes de estudiar las alternativas posibles de portar a PDA la aplicación cliente que se ha desarrollado conviene apuntar algunos datos más sobre el PDA. De entrada, aunque el nombre correcto (por lo genérico) es PDA quizá al lector le suenen más otros nombres para referirse a estos equipos. Aunque las habilidades que la tecnolog´ıa del hardware va a˜ nadiendo a estos equipos son cada vez mayores, la batalla en el mercado parece dirimirse en el terreno del software y primeramente, en el terreno del sistema operativo, donde como en otros casos, parecen no ponerse de acuerdo las grandes compa˜ n´ıas fabricantes. 1

John Sculley: Se le nombr´ o presidente de PepsiCo y en 1983 se hizo cargo de la direcci´on general de Apple. 2 Oficialmente fue llamado Message Pad

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



Además, en el mundo del PDA, arquitectura (f´ısica) y complemento software, suelen ir unidos desde que el fabricante lo lleva a las tiendas. Como lo que quieren los fabricantes de hardware es vender mucho y a lo que más acostumbrado el usuario es al entorno de Microsoft Windows, otra vez, ha ocurrido como con el PC (y como con otras marcas ocurrió en otros productos tecnológicos): el gigante estadounidense dirigido por el afamado Bill Gates y aconsejado por un intelegente equipo de estrategas, parece ir camino de monopolizar el mercado del PDA implantando en un porcentaje cada vez más amplio de los PDA que llegan al mercado su Windows CE (versión de windows para PDA). Aunque (como siempre) hay otras marcas, se podr´ıa hablar de un matrimonio entre HP y Microsoft parecido (aunque no tan forzoso) al que hubo con el PC entre IBM y Microsoft. De todas maneras, esta batalla no esta ganada ni perdida todav´ıa, pues las Palm llevan más tiempo en el mercado y tienen muchas ventajas. En estos términos se pod´ıa hacer la siguiente taxonom´ıa: - Apple Newton - RIM Blackberry - REX 5000 y REX 6000, tarjetas PCMCIA con visor y botones. - Sistema operativo Linux ∗ Sharp Zaurus - Pocket PCs (Windows CE) ∗ HP iPAQ - Sistema operativo Palm OS ∗ Handspring Visor ∗ Palm Pilot

6.3.1.

Palm Pilot

La primera posibilidad es reprogramar para una Palm lo que se ha programado para la parte cliente en PC. Ventajas: + Las Palm son los dispositivos más baratos dentro del mundo del PDA. + La parte cliente –y el sistema en general– está pensada para cargar el sistema lo menos posible. Esto da esperanzas de que pudiera desarrollarse una versión Palm con éxito.

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



+ Las Palm parecen ser, por el momento, más robustas y potentes que los Pocket PC, aunque es conocida la habilidad de Microsoft para poner parches en sus popios remiendos. Y también como la consolidación del hardware acaba equiparando en ocasiones al software lento y al más rápido. Desventajas: – Supone un proceso relativamente largo, aprender a desarrollar sobre este dispositivo, redise˜ nar el sofware para las posibilidades de Palm (téngase en cuenta que Perl acostumbra a ciertas licencias con el uso de la memoria y el manejo de los strings 3 ni si quiera comunes en muchos lenguajes de alto nivel). – El aspecto del resultado ser´ıa muy diferente a la versión PC, y se perder´ıan ciertas funcionalidades por el camino. – El proceso de mantenimiento se bifurcar´ıa y cada nueva función que se quisiera a˜ nadir deber´ıa ser programada por separado en la versión PC y en la versión Palm (esta desventaja lleva a pensar que, aunque se hubiera previsto con antelación el a˜ nadido del PDA, ciertas complicaciones hubieran sido las mismas). – En general, multiplica por dos los problemas: dise˜ nar por separado, programar por separado, probar por separado, etc. Demasiado trabajo a˜ nadido para tan poco rendimiento, al fin y al cabo no se trata de una necesidad de primer orden. Esta alternativa no es muy interesante en el terreno práctico, sólo vale la pena si se está dispuesto a iniciar este camino con todas sus consecuencias.

6.3.2.

Linux en PDA

Aunque parezca sorprendente –el conocido grupo nipón– Sharp lleva más de un a˜ no ofreciendo una gama de PDAs que parecen poder cumplir esta misión. En lo que ata˜ ne a estas páginas, es curioso que allá por febrero de 2002, Kevin Bingham –miembro del O’Reilly Book Support 4 – respond´ıa con escepticismo, en un foro, ante la pregunta de que Perl pudiera correr en un Palm. Citándolo textualmente: ((de alguna manera es como intentar que Perl corriera en una Game Boy (...) Perl no es un peque˜ no intérprete, seguramente ocupar´ıa toda la memoria de una Palm en un momento)) En este mismo mensaje, el propio Kevin Bingham auspiciaba que las –por aquel entonces– nuevas iPAQ donde corr´ıa una versión de Linux era el u ´ nico horizonte posible para Perl dentro de los PDA. 3 4

Cadenas de texto Una especie de ((atenci´ on al cliente)) que ofrece el grupo de O’Reilly

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



Pues efectivamente, Sharp ha seguido este camino. En principio parece ser que estos PDAs sólo soportan C como lenguaje de programación, pero recuérdese que –en definitiva– Perl acaba siendo en u ´ ltima instancia C. La instalación de Perl en las primeras Sharp Zaurus PDA SL-5500 y SL-5600 no parece un proceso sencillo. Pero antes de profundizar en él y comenzar a estudiar qué bibliotecas de Perl soporta esta alternativa y cuáles no, conviene decir una cosa importante: La Sharp Zaurus PDA SL-6000 actual heredera de los modelos SL-5500 y SL-5600 vale5 700$. Por algo más de dinero se puede adquirir un buen ordenador portatil y con bastante menos un ordenador de sobremesa de segunda mano que cubra estos intereses. Desde luego esta posibilidad es tan interesante como resplandeciente, pero a parte de la traba económica conviene ver algo más habitual. No se ha hecho suficiente hincapié, pero en lo que a mercado se refiere, la distancia que separa a los Pocket PC y las Palm de este tipo de alternativas es autenticamente abismal.

6.3.3.

Desarrollo para Pocket PC con Visual Studio

.NET

Podemos haber acabado con el pasado, pero el pasado no ha acabado con nosotros. Bergen Evans ((The Natural History of Nonsense)) A la hora de elegir el entorno sobre el que programar la parte gráfica del cliente, en la sección 5.1.2, se ha visto la posibilidad de utilizar Visual Studio .NET frente a un desarrollo con Perl y Perl/Tk demasiado denso. Aunque parec´ıa que el descubrimiento de las bibliotecas Prima hund´ıan esta posibilidad de manera definitiva, por segunda vez es necesario –y esta vez con mayor profundidad– estudiar las posibilidades que ofrece Visual Studio .NET en general y en concreto para el dilema que se viene discutiendo. Pre´ ambulo Microsoft Visual Studio .NET es un entorno creado para ser la herramienta definitiva del programador. Los desarrolladores pueden usar Visual Studio .NET para: ∗ Construir la próxima generación de Internet. ∗ Crear aplicaciones potentes de manera rápida y efectiva. ∗ Expanderse a cualquier plataforma o dispositivo. 5

Conservando el cambio utilizado en la p´agina 51 esto equivale a 569.52e, que son 94760,15 antiguas pesetas

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



La idea es ser para la próxima década, lo que para los noventa fue el inicio de Visual Basic 1.0. Para conseguir esto, puede intuirse que Visual Studio .NET trabaja sobre dos ejes fundamentales: ∗ Proporcionar al desarrollador las más sofisticadas herramientas gráficas intentando estar presente en todas las fases de desarrollo: el editor, la herramienta de depuración, una aplicación gráfica para el dise˜ no, etc. Todo orgánicamente entrelazado –en teor´ıa– para liberar al usuario de la cantidad mayor de trabajo posible. ∗ Soportar cuantas más posibilidades mejor. Existen paquetes –aqu´ı llamados plugins para los lenguajes más ((de moda))6 . Lo que han creado es el CLR7 : una especie de JAVA para cualquier lenguaje de programación que las capas inferiores de Visual Studio .NET traducen. Para ello, es necesario un profundo dise˜ no por capas (puede echársele un vistazo en el cuadro 6.1). System.Web Services UI Description HtmlControls Discovery WebControls Protocols

Design

System.WinForms ComponentModel

Caching

Security

System.Drawing Drawing 2D Printing

Configuration

SessionState

Imaging

Text

System.Data ADO.NET SqlClient

System.Xml XmlDocument Serialization

Design

Xslt/XPath

Reader/Writers

Runtime

System Collections

Configuration

Security

Net

ServiceProcess

InteropServices

Text

Reflection

Diagnostics

Remoting

Globalization

Resources

Threading

Serialization

Cuadro 6.1: Esqueleto .NET Antes de comenzar a estudiar qu´e herramientas incluye este entorno de programaci´on para desarrollar aplicaciones para Pocket PC es importante tener en cuenta dichas 6

Dicho de otra manera: Microsoft pretende monopolizar tambi´en el mercado de los lenguajes de programaci´ on. 7 Common Language Runtime o –en espa˜ nol– lenguaje com´ un para tiempo de ejecuci´on

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



herramientas son a˜ nadidos posteriores al entorno Visual Studio .NET en s´ı mismo. Al menos en cuanto a su lanzamiento al mercado. Bien mirado, este tipo de mantenimiento representa, de entrada, un punto débil del dise˜ no en cuanto a lo expuesto a continuación. Microsoft .NET para dispositivos En efecto, con la aparición del Pocket PC, hábil como siempre y –también como siempre– desde su posición de fuerza, Microsoft ha creado un ((esqueleto compacto)) partiendo del dise˜ no que representa el cuadro 6.1, con el objetivo de crear un entorno .NET para desarrollar aplicaciones que puedan correr en Pocket PC. Aunque se ha venido traduciendo, el lector más avanzado reconocerá que en la literatura de Microsoft se habla del .NET framework y del .NET compact framework : esqueleto y esqueleto compacto, respectivamente. Pues bien, como era de esperar, el .NET CF (o Compact Framework ) soporta algunas de las funcionalidades anteriores y otras no, puesto que los Pocket PC son inferiores PCs. Véanse cuáles son unos y cuáles son otros, y est´ udiese el cuadro 6.1 en comparación con el 6.2. Caracter´ısticas de .NET para dispositivos comunes del CLR: System.Web Services Description Discovery Protocols

Security

Design

System.WinForms ComponentModel

System.Drawing Drawing 2D Text

System.Data ADO.NET SqlClient

System.Xml XmlDocument

SqlServerCE

Reader/Writers

System Collections

Security

Net

Text

Reflection

Diagnostics

Globalization

Resources

Threading

Cuadro 6.2: Esqueleto compacto de .NET

∗ Excepciones.

CAP´ITULO 6. TRABAJOS FUTUROS: PDA

 ∗ Constructores y finalizadores. ∗ Depuraci´on remota.

∗ Dominios de aplicación, esto es, una aplicación puede iniciar otro dominio de aplicación dentro del mismo proceso. ∗ Servicio P/Invoke (o invocación de plataforma) es la tecnolog´ıa que en .NET permite usar el código en CLR para hacer llamadas a librer´ıas dinámicas DLL8 no gestionadas a priori, incluyendo el API de Win32. Propiedades de Studio .NET que su versión para dispositivos no soporta: ∗ Reflection emit: Herramienta para ensamblar el código ejecutable final. ∗ Remoting (un mecanismo para invocar otras aplicaciones más allá de sus respectivos dominios). ∗ Serialización9 . ∗ Impresión. ∗ Interoperabilidad con COM. ∗ Funcionalidad del lado del servidor. ∗ XPath/XSLT10 Desde luego, es dificil comprender toda esta palabrer´ıa sin adentrarse en la práctica de Visual Studio .NET. Las metas con las que ha sido dise˜ nado Visual Studio .NET Compact Framework o Visual Studio .NET para dispositivos ayudan a ver las posibilidades que ofrece esta tecnolog´ıa: ∗ Un CLR peque˜ no y portatil para dispositivos, permitiendo el uso de Visual Basic y C#. ∗ Sacar provecho del modelo anterior de Visual Studio .NET y lanzar los ejecutables y sus librer´ıas dinamicas11 . Depurar con Visual Studio .NET. 8

Dynamic Link Library o librer´ıas dinamicamente enlazadas ((La serializaci´ on es el proceso de almacenamiento del estado de una instancia de objeto en un medio de almacenamiento. Durante este proceso, los campos p´ ublicos y privados del objeto y el nombre de la clase, incluidos el ensamblador que contiene la clase, se convierten en una secuencia de bytes que, posteriormente, se escribir´ a en una secuencia de datos.)) 10 XSL (Extensible Style Language) es una especificación desarrollada para aplicar formato a los documentos XML de forma estandarizada, después se decidi´ o ((sacar)) fuera de la especificaci´ on XSL el lenguaje de transformaci´ on y desarrollarlo como una especificación ((independiente)) a la que se denominó XSLT. A esta nueva especificación se le denominó XPath XPath(XML Path Language). 11 Esto puede ser una alternativa a lo discutido en la sección 5.1.1 9

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



∗ Facilitar el uso de servicios web XML: bibliotecas de clases para formularios, dibujo en pantalla, almacenamiento, comunicaciones, acceso a datos, XML12 . ∗ Coexistir con el sistema operativo de forma trasparente. Ejecutar en hilos nativos ayud´andose de P/Invoke. SDE y MIT Dentro de Visual Studio .NET existen dos plataformas para desarrollar aplicaciones en dispositivos peque˜ nos. La primera, MIT o Mobile Internet Toolkit (herramienta para Internet desde m´oviles): soluciona la parte del acceso por navegador. En

Figura 6.1: Plataforma de desarrollo MIT (Mobile Internet Toolkit) para Visual Studio .NET cuanto a la segunda: SDE significa extensiones para dispositivos peque˜ nos o Smart Device Extensions. Es la que se ocupa tanto del procesamiento local. 12

No se ha descrito anteriormente: XML es un eXtensible Meta Language, un lenguaje de marca que se utiliza para Internet y otras aplicaciones. Su ventaja es que separa la información de su presentaci´ on, permitiendo modificar ambas independientemente. Es muy potente, está muy de moda y el lenguaje HTML tradicional para hacer páginas web se podr´ıa concebir como un caso particular de XML

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



Figura 6.2: Plataforma de desarrollo SDE (Smart Device Extensions) para Visual Studio .NET MIT Ventajas: + Soporta un buen espectro de dispositivos. + Maneja las diferencias entre dispositivos. Desventajas: – S´olo acepta acceso por navegador. – No aprovecha la posibilidad del procesamiento local. – La interfaz de usuario es limitada. SDE Ventajas: + Funciona tanto en l´ınea como fuera de linea. + Aprovecha completamente las ventajas de los Pocket PC. + Tiene una excelente integraci´on con el SQL Server CE.

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



+ Aprvecha las ventajas del procesamiento local: gráficas, multimedia, etc. Desventajas: – Soporta una gama de dispositivos muy peque˜ na. Además, parece ser que la integración de SDE en el entorno de Visual Studio .NET incorpora un emulador que incluye la funcionalidad completa de Pocket PC 2002, también incluye otras posibilidades: ∗ Compila la aplicación para el dispositivo. ∗ Visual Studio .NET puede instalar el .NET CF en el dispositivo si hace falta. ∗ Incluye una serie de plantillas que pueden facilitar la contrucción de: Aplicaciones para Pocket PC. Biblioteca de clases para Pocket PC. Biblioteca de controles para Pocket PC. Aplicaciones para Windows CE .NET. Aplicaciones para teléfonos móviles. ∗ Existe una opci´ on, en el emulador, para variar las caracter´ısticas del dispositivo (resolución, color, memoria, etc).

6.4.

Conclusiones

Teniendo en cuenta que esta discusión no es en general –aunque tiene aspectos generales y es un problema habitual desde que apareció el PDA– sino que más bien se trata de un estudio concreto para este caso: sirva esta s´ıntesis para concentrar los puntos más fuertes y más débiles de unas y otras posibilidades. También para coger un punto de vista de conjunto. Analizando conjuntamente con la tabla 6.3, podemos resumir que: A saber: Como se ha dicho, la posibilidad más inmediata es ponerse a redise˜ nar el código y volver a desarrollar una versión que pueda correr en una Palm. Este proceso no es trivial y tiene el problema de que aparecen dos frentes de mantenimiento. Cualquier cosa que se pretenda a˜ nadir a partir de tomar esta decisión, se hará por duplicado, por un lado la versión PC y por otro la versión Palm. Tiene el aliciente de que los dispositivos son baratos y que la aplicación cliente tal y como se ha creado, liberada por el servidor de la mayor parte del trabajo, no a˜ nadirá más complicaciones.

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



Alternativas para migrar a PDA

VENTAJAS

+ El dispositivo es barato

+ La conversi´ on es posible, la aplicaci´ on cliente no tiene mucha carga

Palm

DESVENTAJAS

– Redise˜ no y reconstrucci´ on de aplicaci´ on cliente necesarios. – Duplica el mantenimiento a partir de ahora – Mucho trabajo para obener poca satisfacci´ on - Aprender entorno diferente - Aspecto resultante diferente a la versi´ on PC

+ Potencia + No redise˜ no y poca adaptaci´ on.

Linux

MIT

+Soportado por muchos dispositivos.

Pocket PC

– Instalaci´ on de Perl no trivial. – S´ olo disponible en modelos de Sharp Zaurus muy caros

Dispositivos en ambos casos:

– Desaprovecha potencia local (s´ olo por navegador).

+Buenas prestaciones.

– Redise˜ no y reconstruicci´ on necesarios.

Ambos casos: El software de desarrollo no estar´ a libre de licencias y es caro

SDE

+ Cierta fase para adaptarlo pero no redise˜ no + Aprovecha potencia local.

+ No tan barato como Palm pero precio razonable. + Entorno Windos CE como Windows

– Soportado por pocos dispositivos

– Plugin de Active State para .NET CF no probado en la pr´ actica

Cuadro 6.3: S´ıntesis del estudio y discusión sobre PDA Se ha visto que existen unos modelos de Sharp Zaurus que soportan Linux y por lo tanto es posible instalar una versión de Perl. No tendr´ıa los inconvenientes citados antes pero se trata de unos dispositivos demasiado caros. Por otra parte la instalación de Perl no parece fácil, se trata de una versión reducida de Linux y el problema es a´ un tema de debate en ciertos foros de discusión. Por u ´ ltimo se ha visto la tecnolog´ıa que Microsoft está incorporando en sus nuevas versiones de Visual Studio .NET : se trata de una serie de herramientas para crear aplicaciones para Pocket PC. Se ha acotado el esqueleto estructural del .NET para PC y se ha logrado un paquete de herramientas bastante

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



potente. Las ventajas que tiene es que los dispositivos a los que ata˜ ne tienen un precio bastante razonable para la cantidad de prestaciones que ofrecen. Y no har´ıa falta un redise˜ no completo, sólo algunas adaptaciones en el peor de los casos. El principal problema de esta posibilidad es que el software de desarrollo no está libre de licencias. Por otra parte la v´ıa más interesante dentro de .NET la representa la plataforma SDE que no está disponible en tantos dispositivos.

6.5.

Referencias

Se ha separado, sólo en este cap´ıtulo, el ´ındice bibliográfico de la sección general de bibliograf´ıa en la página 120. Principalmente por no sobrecargar aquélla y –al mismo tiempo– porque en este cap´ıtulo la bibliograf´ıa cumple otro papel. Lo más llamativo de toda esta cuestión, es la poca cantidad de textos de caracter divulgativo que existen a´ un sobre estos artefactos. Es más fácil encontrar, en algun foro, una discusión entre usuarios avanzados de alguna cuestión de u ´ ltima instancia, que un texto general acerca de el PDA. De hecho, el cap´ıtulo en s´ı, es más bien un compendio de la cultura que actualmente emana de Internet sobre PDA: En http://www.desarrolloweb.com puede encontrarse un art´ıculo escrito por un consultor de marketing acerca de los posibles sistemas operativos de PDA y su discusión. Realmente, http://enciclopedia.us.es es una auténtica enciclopedia web fuertemente autorreferenciada y lo bastante actualizada en cierta terminolog´ıa tecnológica sin cuya ayuda ciertos textos resultan incomprensibles o algo cojos. Por desgracia, se explaya lo justo en sus definiciones. Lo más importante acerca de la famosa Sharp Zaurus puede encontrarse en la página del fabricante: http://www.sharpusa.com/zaurus/ el precio, aunque no suele aparecer a priori en las paginas de Sharp se puede obtener en sitios web de distribuidoras de toda ´ındole. En cuanto a su relación con Perl la información más interesante está en forma de art´ıculos y cartas tanto en http://letters.oreilly.com/ como en http://perlmonks.thepen.com13 Acerca de Visual Studio .NET la información más técnica se encuentra en http://www.microsoft.com y no hay que dejar de ver las traducciones en http://www.microsoft.com/latam aunque no suelen ser completas y no 13

Ya se ha hablado de los Perl Mongers y en cuanto a O’Reilly, puede encontrarse m´as informaci´on en la bibligraf´ıa de la p´ agina 121 de este mismo documento.



CAPÍTULO 6. TRABAJOS FUTUROS: PDA se actualizan con mucha frecuencia. Sobre la relación entre .NET y Perl, la información más certera proviene otra vez de http://www.ActiveState.com y de un enlace que incluye esta hacia un tutorial muy breve en http://wdvl.internet.com/Reviews. Para la parte final, sobre el desarrollo para Pocket PC ha sido de gran ayuda una presentación escrita por un consultor informático de México que, avalado por el certificado profesional de Microsoft ha ((colaborado como expositor en los congresos nacionales e internacionales que ha organizado la Universidad del Valle de Atemajac (UNIVA) y en diversos eventos organizados o patrocinados por Microsoft)); Seg´ un su propia web, situada en http://www.nazul.net y desde la que puede descargarse la presentación antedicha.

Cap´ıtulo 7 Pruebas y conclusiones El objetivo de este cap´ıtulo es probar tanto la aplicación cliente que se ha desarrollado como el proceso servidor. Demostrar su funcionalidad y someter a cr´ıtica su eficiencia. Lo más interesante es lo segundo, puesto que la funcionalidad no se puede trasladar al papel de una manera completamente fiel y tampoco será as´ı como se eval´ ue, lo que s´ı que vale la pena hacer más hincapié es en el comportamiento y aspecto para Linux y para Windows: Recuérdese que la portabilidad de la aplicación cliente es total (también la del servidor pero éste funciona por consola) . Secundariamente, otro tipo de lector podrá encontrar este cap´ıtulo como un manual para utilizar la aplicación cliente.

7.1. 7.1.1.

Primeras pruebas Inicio

Al iniciar la aplicación aparece un cuadro diálogo, mostrado en la figura 7.1, para introducir un login y un password. Se trata de un usuario y una contrase˜ na que se enviaran a MySQL, de manera que tiene que ser all´ı donde se haya registrado a este usuario. Existen dos opciones, también puede trabajarse sin conexión, por ejemplo, si se está gastando red telefónica, puede editarse una tabla off-line para subirla a posteriori, y estar conectado el menor tiempo posible. La figura 7.2 muestra la ventana de aviso si se pulsa ((Más tarde)) en su predecesora. Aunque pueda parecer tonto, es recomendable avisar de estos movimientos al usuario menos instruido, y el más rápido pronto se acostumbrará a iniciar con estos dos avisos. En el caso de que se intente la conexión pero ésta falle por alguna razón, la aplicación avisa con una ventana como la de la figura 7.3. Igual a la anterior pero 78

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



Figura 7.1: Petición de login y password con un aviso de error. Es interesante no enmascarar todo el proceso de cara al usuario final, los avisos en inglés y el t´ıtulo MySQL logran, secundariamente, educar al usuario en el proceso real que está ocurriendo cuando se conecta. La figura 7.3 es un ejemplo de esta situación, concretamente el error es desconocido porque el cliente no ha conseguido ni siquiera acceder al servidor. En otro caso, la respuesta retornada por MySQL es copiada en esta ventana.

Figura 7.2: Aviso de inicio sin conexión por petición de usuario Las razones por las que puede fallar este intento son varias, sirva de ayuda el siguiente árbol: 1. El usuario sólo quiere utilizar el editor de tablas, de momento, pulsa ((más tarde)) y entra sin problemas a la aplicación. – Se muestra un aviso de que no hay conexión. 2. El usuario introduce su código y su clave. Se equivoca. – Aparece aviso de error. – Entra de todas maneras como en el primer caso, sólo editor.

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



No se equivoca, errores posibles. – El usuario no est´a registrado en la base de datos o no tiene permisos actualmente. – La red no se alcanza (para el cliente es un error desconocido). – Problema en el servidor: el servidor no se alcanza (´ıdem). – Problema en los par´ametros que el cliente tiene sobre servidor: el servidor no se alcanza (´ıdem).

Figura 7.3: Aviso de inicio sin conexi´on por error en el intento

7.1.2.

Informaci´ on en el cliente sobre el servidor

La u ´ nica información sobre el servidor que tiene la aplicación cliente es una dirección de Internet en formato n´ umerico (la IP) y el n´ umero del puerto de escucha en el servidor. Como se ha dicho, esta información debe ser conocida (e introducida) por el usuario. Estos valores pueden modificarse en los men´ us y también pueden guardarse. Por defecto, cuando se pulsa la opción de guardar se vuelcan los datos actuales a un fichero local en formato de texto plano que se nombre con ((.serverop)). Su contenido en un momento dado puede ser: C:\gen> type .serverop 147.156.16.31 1081 C:\gen> En este fichero es en el que la aplicación busca la información al iniciar el programa. Si no lo encuentra, está programado para buscar la IP 0.0.0.0 y el puerto 1080 por defecto, es decir, está programado para funcionar dentro del propio servidor. En otro caso, el usuario no podrá conectarse inmediatamente sino que tendrá que poner valores a estos parámetros desde los men´ us. Luego puede guardarlo para las próximas conexiones.

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



Figura 7.4: Men´ u para ajustar par´ametros de conexi´on

7.1.3.

El editor

El aspecto de la pantalla principal en la aplicaci´on cliente es muy sencillo. De hecho su desnudez inicial puede desconcertar a m´as de un usuario. Secci´ on para los men´ us Parte para el editor, esquema similar a la cuadr´ıcula de una hoja de c´ alculo

Entrada de texto

Cuadro 7.1: Esquema del interfaz gr´afico: parte cliente

El usuario puede navegar por los registros y sus columnas con el rat´on y los cursores, y el contenido de cada celda va apareciendo en la entrada de texto inferior, para poderlo modificar. Adem´as, por medio de los men´ us, el usuario puede elegir un registro y editarlo por separado en una ventana a parte. En el ejemplo de la figura 7.5 se ha cargado una tabla para pruebas emitida por la base de datos MySQL instalada en el servidor slabii.uv.es de la Universidad de Valencia.

7.1.4.

Reajustes en el c´ odigo

Para algunas cosas, en efecto, el u ńico criterio de verdad es la práctica. Esta sección documenta algunas cuestiones demasiado secundarias para enfocarlas desde

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



Figura 7.5: Aspecto del editor para tablas el cap´ıtulo de implementación. Son, en el fondo, ciertas divergencias entre la teor´ıa y la práctica y/o que sólo se pueden descubrir en un terreno de ((laboratorio virtual)). ´ Unicamente un lector más próximo a ciertas técnicas las considerará imprescindibles, pero desde un punto de vista menos sufrido, también pueden resultar interesantes. Divergencias Windows-Linux No está en el ámbito de una demostración final pero s´ı dentro de lo que es el proceso de desarrollo y pruebas, ciertas variaciones en el comportamiento que tiene la implementación dentro del entorno de Windows o dentro del entorno de Linux. Al ser el funcionamiento de MySQL mucho más adecuado dentro de Linux, y la concurrencia de los hilos en cualquier entorno Unix diametralmente opuesta1 a la que proporciona Windows, la tendencia a la hora de desarrollar el cliente es utilizar una instalación de Linux en un equipo mediano. De manera que –una vez hecho esto– se lleva el código a Windows, se ven algunas sorpresas. En anteriores secciones se ha hecho buena propaganda de la portabilidad de Perl y 1

Comparar la concurrencia que ofrece Windows 9X/XP con la que ofrece Linux es un disparate o un ataque a Linux.

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



´ de la de Prima. Esta es –sin duda– total. Los desarrolladores de Perl, sin embargo, no pueden hacer todav´ıa brujer´ıa, de modo que algunas cuestiones hay que estudiarlas por separado. En este sentido, Perl contiene algunos ((trucos)) que permitiran averiguar dentro del código en qué sistema se está. La propuesta que ofrece Prima y que se ha utilizado definitivamente está en el módulo Prima::Aplicaction. Lo mejor es almacenar esto en una variable diferente concebida2 como de tipo lógico o booleano. Por ejemplo: $os=Prima::Application->get_system_info(); if ($os->{apc}==apc::Unix) { $UNIX=1; $SO_font={name=>"Arial",size=>10}; } else { $UNIX=0; $SO_font={name=>"Verdana",size=>8}; } En este extracto del código de la aplicación cliente se almacena –para el resto de la ejecución del programa– una variable que valdrá 1 si se está corriendo la aplicación cliente en un sistema Unix y 0 si está corriendo en Windows. Además se ha hecho depender el tama˜ no y el tipo de la letra utilizada en el resto de caracteres (ventanas, cuadros de diálogo, etc) para que esté en sincron´ıa con los entornos de uno y otro sistema. Partiendo de que la ayuda de la aplicación –que por cierto, en sucesivas fases de mantenimiento habrá que fortalecer– se resuelve mediante una llamada a una página HTML inclu´ıda con el ejecutable (y que es un extracto de esta documentación), es diferente el navegador que se utilize con Windows que en Linux. As´ı, podr´ıa hacerse, vinculando a la acción del men´ u correspondiente: if ($UNIX) { system("mozilla ayuda.html"); } else { system("explorer ayuda.htm"); 2

Perl no diferencia un valor l´ ogico de uno entero, real o alfanum´erico, para Perl todo son escalares y es una de sus comodidades.

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



}

El dilema del socket En teor´ıa, la escritura y lectura de sockets en Perl es bloqueante por defecto. Habitualmente puede hacerse syswrite en un extremo y cuando en el otro se haga sysread se leerá la información escrita antes. Si el orden es inverso, el lector queda bloqueado a la espera y –una vez act´ ua el escritor– reanuda su marcha con la nueva información. Esto puede probarse facilmente en alg´ un programa sencillo y no da ning´ un tipo de problema. Se ha comprobado sin embargo, que en ritmos de lectura/escritura con más sobrecarga de información y de mayor rapidez, la lectura era incorrecta. Hay que decir que no se ha investigado más allá de lo estrictamente emp´ırico y se desconoce si este comportamiento es normal, espec´ıfico de Perl o espec´ıfico de accesos más rápidos. Es precisamente la diferencia de comportamiento entre las pruebas locales y las pruebas entre PCs en tramos de subred diferentes y con cierta distancia mediante, lo que ha permitido vislumbrar una solución satisfactoria. Esta no es otra que colocar una sentencia sleep detrás de cada escritura en el socket para que el receptor no se ((aturulle)). Lo ideal para resolverlo es permitir que desde la aplicación cliente se pueda ajustar esto, bien sea porque el usuario lo introduzca manualmente o bien mediante una negociación de velocidades inicial que permita averiguar al cliente y al servidor qué ((tiempo)) les separa.

7.2.

Velocidad

Una u ´ltima cuesti´on emp´ırica, someter a pruebas el sistema. Medirlo, enfrentarse a los resultados para analizarlos y sacar conclusiones objetivas

7.2.1.

Medici´ on

Esta prueba consiste en medir cuánto tarda el sistema en cargar una tabla. Por otra parte, se ha comentado en la sección 3.1.2 (en la página 14) la singularidad que ten´ıa resolver el problema de las vistas3 de MySQL, interponiendo un proceso servidor entre éste y la aplicación cliente. Se han discutido las ventajas y desventajas desde el punto de vista del dise˜ no. Estas pruebas tienen interés, por lo tanto, para ver en la práctica cuánto ha perturbado dicha decisión. Por desgracia, no se ha desarrollado un cliente alternativo que consulte directamente a MySQL, que ser´ıa 3

Como se ha dicho, MySQL no soporta vistas, al menos por el momento.

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



lo ideal para comparar ambos comportamientos. Para hacer esta prueba se ha utilizado una tabla existente en la base de datos del servidor slabii.uv.es de la Universidad de Valencia. En la tabla 7.2 se muestra un resumen del contenido de la misma, se trata de una tabla de 12 columnas con 125 registros, en el apéndice de la página 118 puede encontrarse más información de la misma: Columna A B C D E F G H I J K L

Sumatorio (longitud caracteres) 1250 7336 25096 11304 7955 11986 6585 2066 1134 820 4791 4944

Promedio 10 58,688 200,768 90,432 63,64 95,888 52,68 16,528 9,072 6,56 38,328 39,552

Cuadro 7.2: Resumen de la tabla de pruebas

Concretamente la tabla 7.2 muestra en la columna central la suma total de caracteres para ese campo. La columna derecha hace un promedio. Esto es interesante porque las mediciones no se han hecho con diferentes tablas de distintos tama˜ nos sino con sesgos de esta misma tabla. Es decir, se ha lanzado una versión modificada del servidor que en cada prueba emit´ıa solamente 5 registros, 10 registros, 15, 20, 25, ... hasta 125. Se ha elegido una tabla lo bastante homogénea y se han medido en el cliente los tiempos de llegada. En el cap´ıtulo 3 de [5] se recomienda un mecanismo muy sencillo y de alta resolución que ser´ıa: use Time::HiRes qw(gettimeofday);

$t0 = gettimeofday; ## operaciones para medir

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



$t1 = gettimeofday; $intervalo = $t1-$t0;

print "Intervalo dur´ o= ",$intervalo," segundos\n"; Que podr´ıa tener una salida como por ejemplo: Intervalo dur´ o 0.450648069381714 segundos Las marcas pare medir T 0 y T 1 se han puesto en la funci´on que controla el click del rat´on, de manera que entre que se solicita una base de datos y esta se muestra se supiera el tiempo. En otras palabras, lo que tarda en llegar la tabla exactamente desde el punto de vista del usuario.

Figura 7.6: Evoluci´on del tiempo para cargase una tabla con respecto a su longitud

7.2.2.

Resultados

Es evidente que los datos mostrados en la tabla 7.3 siguen una evoluci´on lineal, salvando casos de sesgos de la tabla que no hayan seguido el patr´on de homogenei-



CAP´ITULO 7. PRUEBAS Y CONCLUSIONES N´ umero de registros 10 15 20 25 30 35 40 45 50 55 60 65 70 75 80 85 90 95 100 105 110 115 120 125

Segundos que tardaron en llegar 0,070558309555100 0,434070348739601 0,672323942184402 0,764810085296702 0,896802186966003 1,050723314285300 1,189467191696200 1,354887723922790 1,487727403640700 1,622884035110500 1,764297485351500 1,896936416625890 2,058029174804700 1,841727972030710 2,318615198135400 2,445594549179110 2,585010528564500 2,699517488479600 2,849133014679000 2,977719068527010 3,071854591370010 3,224241971970000 3,397480964661000 3,571947813033990

Cuadro 7.3: Medici´on de velocidades

dad. Es interesante saber cuánto de lineal para tener una referencia general. Tratándolo como el más sencillo de los tradicionales problemas de métodos o análisis numérico, puede interpolarse la función que siguen estos numeros tomando el siguiente polinomio de interpolación: f (x) = y0 +

y1 − y0 (x − x0 ) x1 − x0

Asumiendo que, como se ha dicho, la funci´on que estamos buscando es lineal podemos tomar como x1 , y1 , x0 y y0 cualesquiera valores de la tabla 7.3. Suponiendo:

x0 = 40

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



x1 = 110 y0 = 1, 189467191696200 y1 = 3, 071854591370010 Se resuelve finalmente que: f (x) = 0, 02689124856676880000x + 0, 11381724902544300000 Cuyo factor de crecimiento puede verse con mayor claridad si se represnta como: f (x) =

x + 0, 11381724902544300000 37, 18681926

Esto significa que aunque las tablas van tardando cada vez más conforme mayores son, por ejemplo una rabla de estas caracter´ısticas, con mil registros tardar´ıa aproximadamente unos 27 segundos, el progreso crece muy lentamente. Hay que tener en cuenta que se ha medido en unas condiciones muy buenas. El acceso es de unos 400Kbps. Teniendo en cuenta que la tabla madre (sin sesgar) que se ha utilizado tiene 84017 caracteres, es decir, podemos redondear a 10, 5kilobits y generalizar orientativamente a los casos mostrados en la tabla 7.4. Estos cálculos se han simplificado, desde luego, entre otras cosas, por ejemplo, se ha supuesto trafico homogéneo para unos accesos que para otros. resultados para una tabla acceso 400kbps coef. 2,939572622 velocidad. segs. 3,571947813033990

de 125 registros con 10.5kilobits 33kbps 45,2kbps 0,242514741 0,332171706 43,296337127684700 31,610157637468900

Cuadro 7.4: C´alculo de velocidades (en segundos tardados) seg´ un accesos

7.2.3.

Conclusiones

Las u ´ ltimas valoraciones sobre los resultados en la sección anterior pueden dejar algo insatisfecho al lector. En seg´ un qué casos, medio minuto para cargar una tabla puede ser demasiado. De todas maneras hay varios aspectos positivos que deben tenerse en cuenta acerca de estos datos: + La d´ınámica en la aplicación cliente cuando esta se utiliza remotamente es cargar (una vez) la tabla propia con la información individual, modificar los registros que corresponda o bien a˜ nadir algunos nuevos y subir la actualización.

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



Habitualmente, cada trabajador tiene una tabla de unos cien o doscientos clientes como máximo, as´ı que en el peor de los casos tarda un par de minutos en las operaciones de acceso a la base de datos y lo que le cueste modificar los valores una vez cargados localmente. + El ejemplo que se ha puesto, de una tabla de mil registros, o incluso de más, sólo se dar´ıa en el entorno de la oficina, es más, puede utilizarse para este tipo de usos –propios de los gestores de la base de datos o del administrdor sistema– el propio servidor o un host que conviva en el mismo tramo de subred. + El coste de la operación que se ha medido (cargar una tabla remotamente) no puede ser menor que de un orden lineal –excepto con técnicas de cifrado más avanzadas que para tablas grandes también cargar´ıan al servidor–. En tanto que lineal, su crecimiento es ´ınfimo y esto es –en realidad– una muestra de que la decisión de enmascarar las vistas (o no vistas) de MySQL mediante un proceso intermedio no sólo no era tan descabellada como en un principio pod´ıa parecer sino que ha sido desarrollada con bastante fortuna.

7.3.

Valoraci´ on final

Cierto lector puede echar a faltar algunos temas en esta memoria. En todo caso, téngase en cuenta las siguientes conclusiones y consideraciones generales a modo de cierre: – A un nivel como el que se ha tratado, la cuestión de las bases de datos no tiene mayor inconveniente. La oferta de posibilidades para implantar es, seg´ un se ha discutido, suficiente como para dudar a la hora de tomar cada decisión. Esto anima a todos aquellos usuarios de sistemas de bases de datos que no estén contentos con el rendimiento que les ofrecen sus instalaciones, a que estudien las posibilidades de implantar un sistema como el descrito. – Vale la pena recomendar el uso de Perl y de Prima a todos aquellos programadores que no estén satisfechos con los entornos en los que trabajan y en especial a todos aquellos que busquen la independencia de plataforma para su código. Se trata sin duda de herramientas potentes que no fallan, están bien documentadas y son sencillas. Además, el programador habitual de C se familiarizará pronto con Perl. La portabilidad de Perl, en efecto, es tan abrumadora como sus partidarios defienden. – No se ha cerrado con rigor una sección dedicada a presupuestos porque no se ha considerado relevante. Lo u ´ nico que se ha gastado es la fuerza de trabajo de un sólo ingeniero. Sopesándolo en unas 500 horas de base y otras 150 para cerrar debidamente esta memoria. El lector puede imaginar un sueldo habitual

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



de informático en tres meses. Lo realmente interesante es que se ha resuelto todo lo demás sin coste adicional ninguno ni en software ni en hardware. Aprovechando eso s´ı, la naturaleza académica del proyecto, se ha recurrido a ciertas instalaciones de la Universidad de Valencia que han sido de mucha ayuda (biblioteca, accesos p´ ublicos a Internet para portátiles, apuntes de varios cursos, etc). – El principal aspecto que tiene el trabajo desarrollado es, desde el punto de vista del autor y con todo lo expuesto desde la primera página hasta la u ´ ltima de este documento, que se ha salido de una situación fatalmente planteada y se han abierto varios caminos para alcanzar soluciones de mucha envergadura. Asimismo, las cuestiones más inmediatas y necesarias se han cubierto satisfactoriamente.

El c´ odigo del servidor # servidor use use use use

DBI; Socket; threads; threads::shared;

$LIM=5000; # limite de bytes por envio my $driver="DBI:mysql:database=test"; my $host="host=localhost"; my $socket="mysql_socket=/var/lib/mysql/mysql.sock"; my $dsn :shared = join ’;’,($driver,$host,$socket); my @listaclientes : shared = (); my $cuentacli : shared = 0; # INICIALIZO UN PUERTO DE ESCUCHA PARA MI SERVIDOR numero conocido colectivamente 1080 $portescucha=1083; ($portescucha)=$portescucha=~/^(\d+)$/ or die "puerto invalido\n"; socket (EscuchaServer,PF_INET,SOCK_STREAM,getprotobyname(’tcp’)) or die "socket: $!\n";; setsockopt(EscuchaServer,SOL_SOCKET,SO_REUSEADDR,pack("l",1)) or die "setsockopt: $!\n"; bind (EscuchaServer,sockaddr_in($portescucha,INADDR_ANY)) or die "bind: $!\n"; listen (EscuchaServer,SOMAXCONN) or die "listen: $! \n";; # SERVER STARTING ($p,$ip)=sockaddr_in(getsockname(EscuchaServer)); print "Servidor escuchando en $p ",inet_ntoa($ip),"\n"; while(1) # hilo principal o administrador del trabajo { print "Esperando cox...\n"; accept(ClienteActual,EscuchaServer); ($port,$iaddr)=sockaddr_in(getpeername(ClienteActual));

´ ´ APENDICE . EL CODIGO DEL SERVIDOR



sysread(ClienteActual,$port,$LIM); print "Nueva conexion desde ",inet_ntoa($iaddr)," solicitando conversacion en su $port\n"; die "No port: $port \n" unless $port;

$paddr=sockaddr_in($port,$iaddr); $listaclientes[$cuentacli]="MySS0$cuentacli"; socket($listaclientes[$cuentacli-1],PF_INET,SOCK_STREAM,getprotobyname(’tcp’)) or die "socket: $! connect ($listaclientes[$cuentacli-1],$paddr) or print "No pude devolver la cox\n";

$hil0=threads->new(\&gestor,$listaclientes[$cuentacli-1]); close ClienteActual; } # HILO CONSUMIDOR DEL TRABAJO sub gestor { $interlocutor=shift; $EOL="\015\012"; $dormilon=0; $running=1; while (($running) and ((sysread($interlocutor,$buffer,$LIM))>0)) { $dormilon=0; print "Tiempo gastado en DORMIR= ",$dormilon,"segundos\n"; #print "< ",$buffer; chop $buffer; #chop $buffer; # el EOL son dos caracteres, los quitamos $error=’’; ($codigo,$buffer)=split /:~:/,$buffer; print "\tCliente dijo: $codigo $buffer\n"; if (($codigo cmp ’LOGIN’)==0) { ($login,$passwd)=split /::/,$buffer; $|=1; $dbh = DBI->connect($dsn,$login,$passwd) or $error="$DBI::errstr"; if ($dbh) { @dbs = $dbh->func(’_ListDBs’); $buf=join ’:’,@dbs; $buf="1:~:LOGINTRUE::$buf:$EOL";



´ ´ APENDICE . EL CODIGO DEL SERVIDOR syswrite($interlocutor,$buf,$LIM); } else { $buf="0:~:LOGINFALSE::$DBI::errstr$EOL"; print $buf; syswrite($interlocutor,$buf,$LIM); } } elsif (($codigo cmp ’LOGOUT’)==0) { $buf="-1:~:NULL::Loging out... $EOL"; syswrite($interlocutor,$buf,$LIM); $running=0; } elsif (($codigo cmp ’SQL’)==0) { @instruccion=split /\s/,$buffer; #print "@intruccion\n"; for ($i=0;$i<@instruccion;$i++) { print $instruccion[$i],"\n"; $|=1; } $tipo=uc $instruccion[0]; # en mayusculas miramos el inicio de la consulta

print "\t\tCliente pidio consulta tipo: -$tipo-\n"; if (($tipo cmp ’SELECT’)==0) # SELECT query { $dormilon=0; if ($instruccion[1] =~ /\*/) { $sth=$dbh->prepare("show columns from $instruccion[3]"); $sth->execute() or $error=$DBI::errstr; @cab=(); $i=0; while (@r=$sth->fetchrow_array) { $cab[$i]=$r[0]; $i++; } } else { @cab=split /,/,"$instruccion[1]"; }

´ ´ APENDICE . EL CODIGO DEL SERVIDOR $buf=join ’:’,@cab; $buf="1:~:SEQ::$buf:~:$EOL"; syswrite($interlocutor,$buf,$LIM);

sleep(1);

$sth=$dbh->prepare($buffer); $sth->execute() or $error=$DBI::errstr; if (@penultimo=$sth->fetchrow_array) { $ref_penult=\@penultimo; @ultimo=(); $ref_ult=\@ultimo; $arrays_bool=0; while (@{$ref_ult}=$sth->fetchrow_array) { $buffer=join ’:’,@{$ref_penult}; $buffer="1:~:SEQ::$buffer: :~:$EOL"; print $buffer; syswrite($interlocutor,$buffer,$LIM);

if ($arrays_bool==0) { $aux=$ref_penult; $ref_penult=$ref_ult; $ref_ult=$aux; $arrays_bool=1; } else { $aux=$ref_ult; $ref_ult=$ref_penult; $ref_penult=$aux; $arrays_bool=0; } } $buffer=join ’:’,@{$ref_penult}; $buffer="1:~:ULT::$buffer: :~:$EOL"; #print $buffer; syswrite($interlocutor,$buffer,$LIM); } else { $buffer="0:~:NULL::Resultado de SELECT vacio $error $EOL"; syswrite($interlocutor,$buffer,$LIM);



´ ´ APENDICE . EL CODIGO DEL SERVIDOR

 }

} elsif (($tipo cmp ’SHOW’)==0) { $buf=$instruccion[1]; $buf="1:~:SEQ::$buf: :~:$EOL"; syswrite($interlocutor,$buf,$LIM);

$sth=$dbh->prepare($buffer); $sth->execute() or $error=$DBI::errstr; if (@penultimo=$sth->fetchrow_array) { $ref_penult=\@penultimo; @ultimo=(); $ref_ult=\@ultimo; $arrays_bool=0; while (@{$ref_ult}=$sth->fetchrow_array) { #print @{$ref_penult},"\n"; #print @{$ref_ult},"\n"; $buffer=join ’:’,(@{$ref_penult},’ ’); $buffer="1:~:SEQ::$buffer$EOL"; print $buffer; syswrite($interlocutor,$buffer,$LIM);

if ($arrays_bool==0) { $aux=$ref_penult; $ref_penult=$ref_ult; $ref_ult=$aux; $arrays_bool=1; } else { $aux=$ref_ult; $ref_ult=$ref_penult; $ref_penult=$aux; $arrays_bool=0; } } $buffer=join ’:’,(@{$ref_penult},’ ’); $buffer="1:~:ULT::$buffer$EOL"; print $buffer; syswrite($interlocutor,$buffer,$LIM);

´ ´ APENDICE . EL CODIGO DEL SERVIDOR



} else { $buffer="0:~:NULL::Resultado de SHOW vacio $error $EOL"; syswrite($interlocutor,$buffer,$LIM); } } else # NON-SELECT & NON SHOW query if (1==0) { $sth=$dbh->prepare($buffer); $error=’’; $r=$sth->execute() or $error=$sth->errstr; $cod=1; $n_col=0; if ($r<0) { $n_col=’desconocido’; $cod=0; } if ($r>0) { $n_col=$r; } if ($r) # SIENDO 0 sabemos que $r puede ser considerado TRUE o FALSE segun si hubo o no error { $texto=’Ok:’; } else { $texto=’¡!’; } $buffer="$cod:~:INF::$texto Columnas afectadas = $n_col\t$error$EOL"; syswrite($interlocutor,$buffer,$LIM); } } else { $buffer="0:~:INF::Recibido paquete sin cabecera o esta es erronea $EOL"; syswrite($interlocutor,$buffer,$LIM); } } # si el cliente se termina libera su socket, el servidor lo detecta en el consiguiente sysread # y este hilo muere, de otra manera el hilo pervive close $interlocutor; }

El c´ odigo del cliente use use use use use use use use use use use use use use use use

Prima; Prima::DetailedList; Prima::Header; Prima::Classes; Prima::StdDlg; Prima::MsgBox; Prima::Grids; Prima::Buttons; Prima::Label; Prima::Application; Prima::FrameSet; Cwd; Spreadsheet::ParseExcel::Simple; Spreadsheet::WriteExcel; Prima qw( ComboBox Edit); DBI;

package SauceWindow; use Socket; use Carp; use vars qw(@ISA); @ISA = qw(Prima::Window); $os=Prima::Application->get_system_info(); if ($os->{apc}==apc::Unix) { $UNIX=1; $SO_font={name=>"Arial",size=>10}; } else { $SO_font={name=>"Verdana",size=>8}; $UNIX=0; }

my $ICONO=Prima::Icon->create; $ICONO->load("hoja.gif"); # ######################################## VARIABLES GLOBALES $fichero=’Tabla1’; @globalitems=(); #lista de la ventana principal es un array de array $globalregistrostabla=1; $globalcolumnas=5;

´ ´ APENDICE . EL CODIGO DEL CLIENTE



$globalmultiselect=0; $ref_items=0; @sqlitems=(); @altofila[1..TAMY]; @anchocol[1..TAMX];

# OPCIONES de la cuadricula (menu) $margenh=0; $margenv=0; $aj_manual=1; $texto=’’; $hacker=0; $LIM=5000; # limite de bytes por envio # CUESTIONES DE IDENTIDAD ANTE EL SERVIDOR $login=’’; $passwd=’’; $ip_server="0.0.0.0"; $port_server=1080; $interlocutor=-1; $socketpropio=-1; $interfazon=0; opcionescox(); # si hay un fichero (.serverop) con las opciones guardadas lo utiliza $premain; $main; $EOL="\015\012"; # fin de linea $conectado=0; $cnctmenu=’’; $nocnctmenu=’-’; $sqlnivel=-1;

# ####################################### VARIACIONES SOBRE ESQUELETO DESDE VISUAL BUILDER DE PRIMA (MENUS) sub profile_default { my $def = $_[ 0]-> SUPER::profile_default; my %prf = ( #width => 50, #left => 50, icon => $ICONO, #size => [500,500], #centered => 1, windowState=>2, # como ws::Maximized #borderStyle => bs::Dialog,

menuItems=> [[ ’Ms-excel’, [ [ ’Nuevo’, q(nueva)], [ ’Abrir’, sub { abrir(); $maindl->close(); $mainil->close(); $i=@globalitems; while ($i) {

´ ´ APENDICE . EL CODIGO DEL CLIENTE



pop @globalitems; $i--; } @globalitems=(); abrirxls(1); }], [ ’Guardar’, q(guardar)], [], [ ’Salir’, q(on_destroy)], ]], [ ’Editor’,[ [ ’Cabecera’, sub{ cab(); abrirxls(-2); [], [ ’Columnas’, sub{ $antiguo=$globalcolumnas;

}],

$globalcolumnas=generic(’Propiedades tabla’,’N´ umero de columnas’,$globalcolumnas); if ($antiguo!=$globalcolumnas) { for ($i=$antiguo;$i<$globalcolumnas;$i++) { $cabecera[$i]=" "; } $maindl->columns($globalcolumnas); } abrirxls(-2); }], [ ’Registros’, sub{ $antiguo=$globalregistrostabla; $globalregistrostabla=generic(’Propiedades tabla’,’N´ umero de registros’,$globalregistrostabla); if ($antiguo!=$globalregistrostabla) { if ($antiguo<$globalregistrostabla) { for ($i=$antiguo;$i<$globalregistrostabla;$i++) { push @{$maindl->items}, [()]; $maindl->items($maindl->items); } } else { for ($i=$antiguo;$i>=$globalregistrostabla;$i--) { $maindl->delete_items($i); } } $maindl->select; } }], [], [’ms’, ’Multi select’=>sub{$_[0]-> menu-> toggle( $_[1]); $globalmultiselect=$globalmultiselect? 0 : 1; $maindl->multiSelect($globalmultiselect); }], ]], [’Conexion’,[ [’IP’,[

´ ´ APENDICE . EL CODIGO DEL CLIENTE



["".ipremota=>"$ip_server",q()], [’_cambiar_’,sub { $ip_server=generic(’Par´ ametros conexion’,’IP del servidor’,$ip_server); $_[0]->menu->ipremota->text($ip_server); }], ]], [’Puerto’,[ ["".puerto=>"$port_server"=>q()], [’_cambiar_’,sub { $port_server=generic(’Par´ ametros conexion’,’Puerto en host remoto’,$port_server); $_[0]->menu->puerto->text($port_server); }], ]], [], [’Guardar opciones’,sub{ open f,">.serverop"; print f "$ip_server\n"; print f "$port_server\n"; close f; }], [’Restablecer opciones’,sub{ opcionescox(); $_[0]->menu->ipremota->text($ip_server); $_[0]->menu->puerto->text($port_server); }], [], ["$cnctmenu".cox=>"Intentar conexion"=>sub{ logpas(); if ($conectado==1) { $_[0]->menu->cox->enabled(0); $cnctmenu=’-’; $_[0]->menu->nocox->enabled(1); $nocnctmenu=’’; } }], ["$nocnctmenu".nocox=>"Desconectar"=>sub{ $buf="LOGOUT:~:null::$EOL"; syswrite($interlocutor,$buf,$LIM); sysread($interlocutor,$buffer,$LIM); tratar($buffer); if ($conectado==0) { $_[0]->menu->nocox->enabled(0); $nocnctmenu=’-’; $_[0]->menu->cox->enabled(1); $cnctmenu=’’; $maindl->close; $mainil->close; $fichero=’Tabla1’; abrirxls(1); $sqlnivel=-1; } }],

´ ´ APENDICE . EL CODIGO DEL CLIENTE

 ]], [], [ ’?’, [ [ ’Ayuda’, sub{ if ($UNIX==0) {

system("mozilla ayuda.html"); } else { system("explorer ayuda.html"); } }], [ ’Acerca de...’, sub{ ventanita("",""); }], ]], ], name => ’Sauce’,

onActivate=>sub{ }, selectable=>1, #sizeDontCare => 1, #originDontCare => 1, #designScale => [ 5, 13], ); @$def{keys %prf} = values %prf; return $def; } sub init { my $self = shift; my %instances = map {$_ => {}} qw(); my %profile = $self-> SUPER::init(@_); my %names = ( q(Sauce) => $self); $self-> lock; $self-> unlock; return %profile; } sub on_destroy { $::application-> close; }

# #################################### Funciones: ############# # ################################################################

´ ´ APENDICE . EL CODIGO DEL CLIENTE

sub abrir { my $w = Prima::OpenDialog-> create( name=>’Abrir’, filter=>[ [’Datos’=>’*.xls’], [’Todos los archivos’=>’*’], ], fileName=>$fichero,

); if ($w->execute) { $fichero=$w->fileName; #$fichero=~ tr/\//\\/;

#if MS-WINDOWS else LINUX

}

} sub nueva { $maindl->close; $mainil->close; $fichero=’Tabla1’; abrirxls(1); } sub guardar # guardar fichero { my $w = Prima::SaveDialog-> create( name=>’Guardar’, filter=>[ [’Datos’=>’*.xls’], [’Todos los archivos’=>’*’], ], fileName=>$fichero, defaultExt=>’xls’, fileMustExist=>0, overwritePrompt=>0, ); if ($w->execute) { $fichero=$w->fileName; #$fichero=~ tr/\//\\/; if (-e $fichero) { unlink $fichero; } } my $workbook = Spreadsheet::WriteExcel->new($fichero); # Add a worksheet





´ ´ APENDICE . EL CODIGO DEL CLIENTE

$worksheet = $workbook->add_worksheet(); # Add and define a format $format = $workbook->add_format(); # Add a format #$format->set_bold(); #$format->set_color(’red’); #$format->set_align(’center’); # Write a formatted and unformatted string, row and column notation. $col = $row = 0; for ($col=0;$col<$globalcolumnas;$col++) { $worksheet->write(0,$col,$cabecera[$col],$format); for ($row=0;$row<$globalregistrostabla;$row++) { #$worksheet->write($row, $col, "Hi Excel!", $format); $worksheet->write($row+1,$col,${$maindl->items}[$row][$col],$format); } } # Write a number and a formula using A1 notation #$worksheet->write(’A3’, 1.2345); #$worksheet->write(’A4’, ’=SIN(PI()/4)’);

} # conexion inicial entre servidor y cliente que negocia socket de trasmision sub bisabis { my ($iaddrsocket,$portsocket,$paddrsocket,$iaddrsocket,$port,$iaddr,$b,$buffer,$linea);

# Creo un socket para hablar con el 1080:iaddr $iaddrsocket=$ip_server; #"147.156.224.34"; $portsocket=$port_server; if ($portsocket=~/\D/) { $portsocket=getservbyname($portsocket,’tcp’); } die "No port \n" unless $portsocket;

$aux=inet_aton($iaddrsocket); $paddrsocket=sockaddr_in($portsocket,$aux); # or return ((-1,"sockaddr_in: $!\n")); socket(SocketCliente,PF_INET,SOCK_STREAM,getprotobyname(’tcp’)) or return((-1,"socket: $!\n")); connect(SocketCliente,$paddrsocket) or return((-1,"connect: $!\n"));

# Me creo una escucha propia: EscuchaCliente $port=$port_server; if ($port=~/\D/) { $port=getservbyname($port,’tcp’); } die "No port \n" unless $port;

´ ´ APENDICE . EL CODIGO DEL CLIENTE



socket(EscuchaCliente,PF_INET,SOCK_STREAM,getprotobyname(’tcp’)) or return((-1,"socket: $!\n")); setsockopt(EscuchaCliente,SOL_SOCKET,SO_REUSEADDR,pack("l",1)) or return((-1,"set: $!\n")); # rudimentario bucle para buscar un numero de puerto que BIND acepte $bool=0; while ($bool==0) { $bool=1; bind(EscuchaCliente,sockaddr_in($port,INADDR_ANY)) or $bool=0; $port++; } ($port,$iaddr)=sockaddr_in(getsockname(EscuchaCliente)); listen(EscuchaCliente,SOMAXCONN) or return((-1,"listen: $!\n")); #print "Escucho por $port ",inet_ntoa($iaddr),"\n"; # Aviso al servidr de que puede comunicarse conmigo por esta ’escucha’ $linea="$port$EOL"; syswrite(SocketCliente,$linea,$LIM) or return((-1,"syswrite: $!\n")); close (SocketCliente); # cerrar el socket anterior para liberar al Servidor # acepto entrada accept(SocketServer,EscuchaCliente) or return((-1,"accept: $!\n")); return(1,SocketServer,EscuchaCliente); } # ###############################################################Procedimiento para modificar un registro # ##################################################################################### sub reg { my $Y=220; my $X=240; if (@{${$maindl->items}[$maindl->focusedItem]}<$globalcolumnas) { for ($i=@{${$maindl->items}[$maindl->focusedItem]};$i<$globalcolumnas;$i++) { ${$maindl->items}[$maindl->focusedItem][$i]=’ ’; } } my $c=Prima::Window->create( size=>[$Y,$X], origin=>[0,0], centered=>1, name=>"Registro $maindl->focusedItem", growMode=>0, onActivate=>sub{}, onDestroy=>sub{}, borderIcons=>10, icon => $ICONO, onClose=>sub{ @{${$maindl->items}[$maindl->focusedItem]}=@{$micombo->items}; }, borderStyle=>bs::Dialog);

$micombo=$c->insert( ListBox=> size=>[$c->width,$c->height-20], origin=>[0,0], name=>’’,

´ ´ APENDICE . EL CODIGO DEL CLIENTE



#literal=>0, onSelectItem=>sub{ $texto->text(${$micombo->items}[$micombo->focusedItem]); }, onKeyDown => sub { my ( $self, $code, $key, $mod) = @_; if (($code==0) and ($key==263168)) { #$micombo->delete_items($micombo->focusedItem); ${$micombo->items}[$micombo->focusedItem]=’’; $texto->text(’’); @{${$maindl->items}[$maindl->focusedItem]}=@{$micombo->items}; } }, items=>[(@{${$maindl->items}[$maindl->focusedItem]})] ); $texto=$c->insert( InputLine=> size=>[$c->width,20], origin=>[0,$c->height-20], font=>$SO_font, text => ${$micombo->items}[$micombo->focusedItem], #growMode => gm::Client, onChange=>sub{}, onKeyDown => sub { my ( $self, $code, $key, $mod) = @_; if (($code==13) and ($key==134400)) #return { ${$micombo->items}[$micombo->focusedItem]=$_[0]->text; $micombo->select; } } );

$c->execute; } # ############################################# Procedimiento para arreglar la cabecera de la TABLA # ######################################################################################### sub cab { my $Y=220; my $X=240; my $c=Prima::Window->create( size=>[$Y,$X], origin=>[0,0], centered=>1, name=>"Cabecera tabla", growMode=>0, onActivate=>sub{}, onDestroy=>sub{}, borderIcons=>10, icon => $ICONO, onClose=>sub{ @cabecera=@{$micombo->items}; $globalcolumnas=@cabecera; $maindl->columns($globalcolumnas); $maindl->headers(@cabecera); }, borderStyle=>bs::Dialog);

´ ´ APENDICE . EL CODIGO DEL CLIENTE

$micombo=$c->insert( ListBox=> size=>[$c->width,$c->height-20], origin=>[0,0], name=>’’, #literal=>0, onSelectItem=>sub{ $texto->text(${$micombo->items}[$micombo->focusedItem]); }, onKeyDown => sub { my ( $self, $code, $key, $mod) = @_; if (($code==0) and ($key==263168)) { $micombo->delete_items($micombo->focusedItem); $globalcolumnas--; @cabecera=$micombo->items; } }, items=>[(@cabecera)]); $texto=$c->insert( InputLine=> size=>[$c->width,20], origin=>[0,$c->height-20], font=>$SO_font, text => ${$micombo->items}[$micombo->focusedItem], #growMode => gm::Client, onChange=>sub{}, onKeyDown => sub { my ( $self, $code, $key, $mod) = @_; if (($code==13) and ($key==134400)) #return { $micombo->items->[$micombo->focusedItem]=$_[0]->text; $micombo->select; } } );

$c->execute; }

sub opcionescox { # lee el fichero que contiene opciones iniciales para conectarse al servidor

$i=0; @a=(); open $f,".serverop" or print "\nNo existe ./.serveropc\nImposible lectura\n"; while (<$f>) { @a[$i]=$_; $i++; } close $f; $ip_server=$a[0]; chop $ip_server; $port_server=$a[1]; chop $port_server;





´ ´ APENDICE . EL CODIGO DEL CLIENTE

if (@a==()) { $ip_server="0.0.0.0"; $port_server=1080; } }

# ############################################## Dialogo generico con InputLine # ###################################################################################### sub generic # generic (titulo, label, referencia a variable a modificar) { my $Y=100; my $X=220; $guardo=$_[2];

my $c=Prima::Window->create( size=>[$X,$Y], origin=>[1,1], centered=>1, name=>$_[0], growMode=>0, icon=>$ICONO, borderStyle => bs::Dialog, onActivate=>sub{}, borderIcons=>11);

$c-> insert( Label => font=>$SO_font, #{name=>"Verdana", size=>8,}, origin => [ 10,$Y-40], text => $_[1], focusLink => $b1, wordWrap => 0, width => 120, alignment => ta::Left, growMode => 0, showPartial => 0, ); my $valor=$c->insert(InputLine=>text=>$_[2], #$SauceAuto::g->columnWidth($actualx), width=>50, origin=>[150,$Y-40], alignment=>ta::Left, font=>$SO_font, #{name=>"Verdana",size=>8,}, growMode=>2, buffered=>0, borderWidth=>3, autoselect=>0,);

my $b1=$c->insert(Button => font=>$SO_font, #{name=>"Verdana",size=>8,}, size=>[90,40], left=>10, text=>"Aceptar", bottom => 10,

´ ´ APENDICE . EL CODIGO DEL CLIENTE onClick=>sub{ $cont=$valor->text; $c->close; }, ); my $b2=$c->insert(Button => font=>$SO_font, #{name=>"Verdana",size=>8,}, size=>[90,40], text=>"Cancelar", left=>$X-10-90, bottom => 10, onClick=>sub{ $cont=$guardo; $c->close; }, ); $c->execute; return $cont; }

# #################################################### UTIL PARA VENTANAS GENERICAS DE AVISO # void ventanita (string titulo, string mensaje) sub ventanita { my $titulo=shift; my $mensaje=shift;

my $l=length($mensaje);

# la ventana se adec´ ua a lo grande que sea el texto

if ($l>70) { $Xx=400; $lineas=int($l/60)==($l/60)?int($l/60):1+int($l/60); $Yy=45+(13*$lineas); } else { $Xx=8*$l; $Yy=60; }

my $c=Prima::Window->create( size=>[$Xx,$Yy], origin=>[1,1], centered=>1, icon=>$ICONO, name=>$titulo, growMode=>0, #borderIcons=>11, borderStyle => bs::Dialog);

$c->insert( Label => font=>$SO_font, #{name=>"Verdana", size =>8},



´ ´ APENDICE . EL CODIGO DEL CLIENTE

 origin => [0,0], text => $mensaje, focusLink => $b1, wordWrap => 1, width => $Xx, height => $Yy-5, autoHeight=>1, alignment => ta::Center, growMode => -1, showPartial => 1, );

my $b1=$c->insert(Button => font=>$SO_font, #{name=>"Verdana",size=>8,}, origin=>[int($Xx/2)-40,5], size=>[80,25], left=>10, text=>"Aceptar", bottom => 10, onClick=>sub{$c->close;}, ); $c->execute; } # Tratamiento de las recepciones por SOCKET que vienen del servidor # ## SQL com sub tratar # recibe un string como parametro { $buffer=$_[0]; print "pretenden que trabaje con: $buffer\n"; chop $buffer; chop $buffer; ($cabecera,$buffer)=split /:~:/,$buffer; ($bucle,$buffer)=split /::/,$buffer; if (($cabecera cmp ’-2’)==0) { ventanita(’MySQL info’,’Desconecxion forzosa a peticion del servidor...’); close($socketpropio); close($interlocutor); $conectado=0; return; } elsif (($cabecera cmp ’-1’)==0) { ventanita(’MySQL info’,’Desconectando a peticion del cliente...’); close($socketpropio); close($interlocutor); $conectado=0; return; } elsif (($cabecera cmp ’0’)==0) { if (($bucle cmp ’LOGINFALSE’)==0) { ventanita("MySQL info","Cliente funcionando sin conexi´ on\n $buffer"); } } else {

´ ´ APENDICE . EL CODIGO DEL CLIENTE if (($bucle cmp ’LOGINTRUE’)==0) { $sqlnivel=0; $conectado=1; $cnctmenu=’-’; $nocnctmenu=’’; $fichero=’SQL’; @sqlitems=split /:/,$buffer; if ($interfazon==0) { $interfazon=1; previo(); abrirxls(-1); $premain->select; run Prima; } else { $maindl->close(); $mainil->close(); abrirxls(-1); } } elsif (($bucle cmp ’INF’)==0) { print $buffer,"\n"; } elsif (($bucle cmp ’UNI’)==0) { @array=split /:/,$buffer; for ($i=0;$i<@array;$i++) { print $array[$i],’ ’; } print "\n"; } elsif (($bucle cmp ’SEQ’)==0) { @sqlitems=(); if (($bucle cmp ’SEQ’)==0) { @cabecera=split /:/,$buffer; for ($i=0;$i<@cabecera;$i++) { print "i- Le estoy metiendo: - cab -$cabecera[$i] -\n"; } sysread($interlocutor,$buffer,$LIM); print "pretenden que trabaje con: $buffer\n"; chop $buffer; chop $buffer; ($cabecera,$buffer)=split /:~:/,$buffer; ($bucle,$buffer)=split /::/,$buffer; $globalregistrostabla=0; } print "$bucle\n"; while (($bucle cmp ’SEQ’)==0) { @array=split /:/,$buffer; for ($i=0;$i<@array;$i++) { print "ii - Le estoy metiendo: - $array[$i] -\n";



´ ´ APENDICE . EL CODIGO DEL CLIENTE

 } push @sqlitems,[@array];

sysread($interlocutor,$buffer,$LIM); print "pretenden que trabaje con: $buffer\n"; chop $buffer; chop $buffer; ($cabecera,$buffer)=split /:~:/,$buffer; ($bucle,$buffer)=split /::/,$buffer; $globalregistrostabla++; } if (($bucle cmp ’ULT’)==0) { @array=split /:/,$buffer; for ($i=0;$i<@array;$i++) { print "iii - Le estoy metiendo: - $array[$i] -\n"; } print "@array\n----~ nn ~----"; push @sqlitems,[@array]; $globalregistrostabla++; } for ($i=0;$i<@sqlitems;$i++) { print "BURUTAL: @{$sqlitems[$i]}\n"; } $maindl->close; $mainil->close; abrirxls(-3); } } }

# ###################################################################### Procedimiento para entrar login/passwd # ################################################################################################################# # Intenta conexion al SQLd con este login y este password sub logpas { my $Y=150; my $X=220; my $c=Prima::Window->create( size=>[$X,$Y], origin=>[1,1], centered=>1, name=>"Introduzca usuario/clave", growMode=>0, onActivate=>sub{}, onDestroy=>sub{$hacker?die:{};}, borderIcons=>10, icon => $ICONO, borderStyle=>bs::Dialog);

$c-> insert( Label => font=>$SO_font, #{name=>"Verdana", size=>8,},

´ ´ APENDICE . EL CODIGO DEL CLIENTE origin => [ 10,$Y-40], text => "Usuario:", focusLink => $b1, wordWrap => 0, #1 width => 120, alignment => ta::Left, growMode => 0, showPartial => 0, ); my $inh=$c->insert(InputLine=>text=>$login, width=>110, origin=>[100,$Y-40], alignment=>ta::Left, font=>$SO_font, #{name=>"Verdana",size=>8,}, growMode=>2, buffered=>0, borderWidth=>3, autoselect=>0,); $c->insert( Label => font=>$SO_font, #{name=>"Verdana", size=>8,}, origin => [ 10,$Y-80], text => "Contrase~ na:", focusLink => $b1, wordWrap => 1, width => 100, alignment => ta::Left, growMode => 0, showPartial => 0, ); my $inv=$c->insert(InputLine=>text=>$passwd, width=>110, origin=>[100,$Y-80], alignment=>ta::Left, font=>$SO_font, #{name=>"Verdana",size=>8,}, growMode=>1, writeOnly=>1, passwordChar=>’·’, buffered=>0, borderWidth=>3, autoselect=>0,);

my $b1=$c->insert(Button => font=>$SO_font, #{name=>"Verdana",size=>8,}, size=>[90,40], left=>10, text=>"Ahora", bottom => 10, onClick=>sub{ $login=$inh->text; $passwd=$inv->text; @retorno=bisabis();

if ($retorno[0]>0) { $buf=join ’’,(’LOGIN’,’:~:’,$login,’::’,$passwd,":~:","$EOL"); #$buf="LOGIN:~:$login::$passwd$EOL"; $interlocutor=$retorno[1]; $socketpropio=$retorno[2]; syswrite($interlocutor,$buf,$LIM); sysread($interlocutor,$buffer,$LIM);



´ ´ APENDICE . EL CODIGO DEL CLIENTE

 $c->close; tratar($buffer); } else { $c->close;

ventanita("MySQL info","Cliente funcionando sin conexi´ on\n $retorno[1] "); };

}, ); my $b2=$c->insert(Button => font=>$SO_font, #{name=>"Verdana",size=>8,}, size=>[90,40], text=>"M´ as tarde", left=>$X-10-90, bottom => 10, onClick=>sub{ $c->close; if ($conectado==0) { ventanita("MySQL info","Cliente funcionando sin conexi´ on"); } }, ); $c->execute; }

#abre los FRAMES de la ventana principal sub previo { $premain=SauceWindow->create; $premain->icon($ICONO); $main=$premain->insert( FrameSet => size => [$premain->width,$premain->height-30], origin => [0, 30], growMode => gm::Client, frameSizes => [qw()], #211 20% 123 10% * 45% *)], opaqueResize => 0, frameProfiles => [ 0,0, { minFrameWidth => 123, maxFrameWidth => 123 }], ); $main2=$premain->insert( FrameSet => size => [$premain->width,20], origin => [0, 0], growMode => gm::Floor, #Client, frameSizes => [qw()], #211 20% 123 10% * 45% *)], opaqueResize => 0, frameProfiles => [ 0,0, { minFrameWidth => 123, maxFrameWidth => 123 }], ); }

´ ´ APENDICE . EL CODIGO DEL CLIENTE

# Para mostrar la tabla cargada (sea xls o sea de MySQL en memoria) sub abrirxls # (BOOL_FLAG primera vez) { if ($_[0]==-2) # modo de interfaz - reestructuracion - cierra el interfaz anterior { $ref_items=$maindl->items; $old_maindl=$maindl; $old_mainil=$mainil; } if ($_[0]==-1) # modo de interfaz - se abre por primera vez partiendo de conexion con MySQL { @cabecera=(); @globalitems=(); $cabecera[0]="$login databases"; for ($i=0;$i<@sqlitems;$i++) { push @globalitems,[($sqlitems[$i], ’ ’)]; } $ref_items=\@globalitems; } if ($_[0]==-3) # modo de interfaz - muestra un resultado SQL { for ($i=0;$i<@sqlitems;$i++) { print "BURUTAL: @{$sqlitems[$i]}\n"; } print "barbarie -- @sqlitems \ncapricornio"; $ref_items=\@sqlitems; } if ($_[0]==1) # modo de interfaz - modo sin conexion si hay un fichero elegido lo abre { if (($fichero cmp "Tabla1")==0) { @r=(’’,’’); @globalitems=(); @cabecera=(); for ($i=0;$i<$globalcolumnas;$i++) { $cabecera[$i]=’ ’; } push @globalitems,[@r]; $globalregistrostabla=1; } else { $flag=1; $xls=Spreadsheet::ParseExcel::Simple->read($fichero); $globalregistrostabla=0; foreach $sheet ($xls->sheets) { if ($sheet->has_data) { @cabecera=$sheet->next_row; } while ($sheet->has_data) { @data = $sheet->next_row; #print @data; push @globalitems, [@data]; $globalregistrostabla++; } }



´ ´ APENDICE . EL CODIGO DEL CLIENTE

 $globalcolumnas=@cabecera; } $ref_items=\@globalitems; }

@muestra=(); for ($i=0;$i<@cabecera;$i++) { $muestra[$i]=join ’ ’, (’ ’,$cabecera[$i],’ ’); }

$maindl=$main->insert(DetailedList=> columns=>$globalcolumnas, name=>’GLOBALLI’, #multiSelect=>$globalmultiselect, multiColumn=>0, font=>$SO_font, origin=>[0,0], size=>[$main->size], growMode => gm::Client, headers=>[@muestra], items=>$ref_items, gridColor=>cl::Black, onSort=>sub{ #$mainil->text(${$maindl->items}[$actualy][$actualx]); }, onClick=>sub{ # doble click con el raton (tratar aqui)

print $sqlnivel,"\n"; if ($sqlnivel<0) { reg(); } elsif ($sqlnivel>1) { reg(); } elsif ($sqlnivel==0) # navega por las bases de datos y elige una { $sqlnivel++; $buf=join ’’,(’SQL’,’:~:’,’use’,’ ’,${$maindl->items}[$maindl->focusedItem][0],":~:","$EOL"); syswrite($interlocutor,$buf,$LIM); sysread($interlocutor,$buffer,$LIM); $buf=join ’’,(’SQL’,’:~:’,’show’,’ ’,tables,":~:","$EOL"); syswrite($interlocutor,$buf,$LIM); sysread($interlocutor,$buffer,$LIM); tratar($buffer); } elsif ($sqlnivel==1) # mira las tablas y elige una { $sqlnivel++; $buf=join ’’,(’SQL’,’:~:’,’select’,’ * ’,’from ’,${$maindl->items}[$maindl->focusedItem][0],":~:","$EOL") syswrite($interlocutor,$buf,$LIM); sysread($interlocutor,$buffer,$LIM); tratar($buffer); } }, onSelectItem=>sub{ $mainil->text(${$maindl->items}[$actualy][$actualx]); }, onKeyDown => sub {

´ ´ APENDICE . EL CODIGO DEL CLIENTE



my ( $self, $code, $key, $mod) = @_; #print "\n",$code,"\n",$key,"\n",$mod,"\n"; if (($code==0) and ($key==263168)) { if ($maindl->multiSelect()) { @borratarios=(); for ($i=0;$i<$globalregistrostabla;$i++) { if ($maindl->is_selected($i)) { push @borratarios, $i; } } print @borratarios; $maindl->delete_items(@borratarios); $globalregistrostabla=$globalregistrostabla-@borratarios; $maindl->select; } else { $maindl->delete_items($maindl->focusedItem); $maindl->select; }

} elsif (($code==0) and ($key==264448)) # flecha abajo { $mainil->text(${$maindl->items}[$maindl->focusedItem][$actualx]); } elsif (($code==0) and ($key==263936)) # flecha arriba { $mainil->text(${$maindl->items}[$maindl->focusedItem][$actualx]); } elsif (($code==0) and ($key==264192)) # flecha dcha { if ($actualx<$globalcolumnas) { $actualx++; } $mainil->text(${$maindl->items}[$maindl->focusedItem][$actualx]); } elsif (($code==0) and ($key==263680)) # flecha izq { if ($actualx>0) { $actualx--; } $mainil->text(${$maindl->items}[$maindl->focusedItem][$actualx]); } elsif (($code==9) and ($key==133376)) # tabulador { $mainil->select(); } } ); $mainil=$main2->insert( InputLine => origin => [ 0,0],

´ ´ APENDICE . EL CODIGO DEL CLIENTE



font=>$SO_font, size => [$main2->size], #[ $main-> width, 20], text => ${$maindl->items}[$actualy][$actualx], #current => 1, growMode => gm::Client, onKeyDown => sub { my ( $self, $code, $key, $mod) = @_; if (($code==13) and ($key==134400)) #return { ${$maindl->items}[$maindl->focusedItem][$actualx]=$mainil->text; $maindl->select; } elsif (($code==9) and ($key==133376)) # tabulador { $maindl->select; }

} ); if ($_[-1]==-2) { $old_mainil->close(); $old_maindl->close(); } } logpas(); if ($interfazon==0) { $interfazon=1; previo(); abrirxls(1); $premain->select; run Prima; }

Tabla de pruebas Se ha adjuntado esta secuencia en apoyo a la secci´on 7.2.1 donde se explica c´omo ha sido utilizada la tabla aqu´ı extra´ıda. Sirva como testimonio de lo que all´ı se ha expuesto. Welcome to SuSE Linux 8.2 (i586) - Kernel 2.4.20-4GB (0). slabii login: marmeng Password: Last login: Thu Jul 15 09:37:05 from vpn1-18.vpn.uv.es Have a lot of fun... slabii:$ mysql Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 184 to server version: 3.23.55-log Type ’help;’ or ’\h’ for help. Type ’\c’ to clear the buffer. mysql> use test; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> show columns from proyecto_10102; Welcome to SuSE Linux 8.2 (i586) - Kernel 2.4.20-4GB (0). slabii login: marmeng Password: Last login: Thu Jul 15 09:37:05 from vpn1-18.vpn.uv.es Have a lot of fun... slabii:$ mysql Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 184 to server version: 3.23.55-log

118



´ APENDICE . TABLA DE PRUEBAS

Bibliograf´ıa [1] Larry Wall, Tom Christiansen and Jon Orwant, Programming in Perl, Third Edition, O’Reilly & Associates, July 2000. [2] Dmitry Karasik, Anton Berezin and Vadim Belman, Prima – the perl graphic c 1997-2003 The Protein Laboratory, University of Copenhagen. toolkit, [3] Ellen Siever, Stephen Spainhour and Nathan Patwardhan, Perl in a nutshell, c 2002, 1999 O’Reilly & Associates, Inc. second ed., Copyright [4] Sriram Srinivasan, Advanced Perl Programming, first ed., O’Reilly & Associates, Inc. August 1997. [5] Tom Christiansen and Nathan Torkington, Perl Cookbook, O’Reilly & Associates, Inc. August 1998. [6] David Axmark, Michael (Monty) Widenius, Jeremy Cole, Arjen Lentz and c 1997-2004 MySQL AB . Paul DuBois, MySQL Reference Manual, Copyright [7] Larry Ullman, Gu´ıa de aprendizaje MySQL, 2003, Prentice Hall. ˜ [8] J. BenavidesAbajo, J.M. Olaizola Bartolomé y E. Rivero Cornelio, SQL Para usuarios y programadores, quinta ed. 1999, Ed. Paraninfo. [9] Roger S. Pressman, Ingenier´ıa del Software, un enfoque práctico, cuarta edición4 . 1997, Mc Graw Hill. [10] Alberto Domingo Ajenjo, Dirección y gestión de proyectos –Un enfoque práctico, Ra-Ma, 2000. [11] Adoración de Miguel Casta˜ no y Mario G. Piattini Velthis, Fundamentos y modelos de Bases de Datos, segunda ed. 1999, Ra-Ma.

Tambi´en se ha utilizado la tercera edici´on de 1995

120

Referencias web http:// www.ActiveState.com Se trata de un grupo filial de la empresa Sophos. Pueden descargarse de aqu´ı interpretes de Perl para Linux y para Windows. La página se actualiza con frecuencia y ofrece posibilidades para otros lenguajes, a parte de cierta documentación. http:// www.perl.com Página muy u ´ til sobre Perl, página oficial. Contiene art´ıculos y enlaces de actualidad, lo mejor para estar al d´ıa. http:// www.cpan.com Desde aqu´ı no sólo se puede descargar Perl sino también multitud de modulos, documentados y con enlaces a sus sitios web. CPAN es el Comprehensive Perl Archive Network. Tiene un caracter mucho más próximo a Open Source que ActiveState, ambas son recomendables. http:// www.indigostar.com Sitio web de una relativamente peque˜ na empresa Canadiense de software. Entre otros programas distribuye un ensamblador muy simple que genera ejecutables partiendo de scripts de Perl. http:// www.mysql.com Sitio oficial de MySQL. Puede encontrarse todo lo referente a esta potente base de datos firmada con licencia libre (GPL). http:// www.orreily.com Página del grupo O’Reilly. Se trata de una empresa de publicaciones informáticas que ofrece bastante calidad. La página puede servir sobre todo para buscar art´ıculos, reports sobre conferencias, etc. O’Reilly se dedica tanto a la publicación on line como al papel tocante http:// www.unix.org.ua Página soviética de alguna asociación Unix, quien sepa ruso podrá averiguarlo. Es muy recomendable porque incluye en HTML copias de algunos libros de O’Reilly. Seguramente es ilegal hacer esto porque los libros más modernos 121

´ APENDICE . REFERENCIAS WEB



de O’Reilly valen del orden de 50$ y en su p´agina web solamente pueden descargarse alg´ un cap´ıtulo de muestra en formato PDF. Aunque tiene otras muchas cosas, sin duda lo m´as espectacular es la magn´ıfica biblioteca gratuita que esconde http://www.unix.org.ua/orelly/.

Índice alfab´ etico C , 43 JAVA, 44 ((byte code)), 49 máquina virtual de, 45 Base de datos definición, 4 privada virtual, 8 benchmark, 13 GPL, 10 IndigoStar, 50 perl2exe, 51 JDBC, 45 Larry Wall, 48 cita, 59 hilos y procesos, 59

dise˜ no, 28 PDA, 65 Palm, 66 Pocket PC, 68 Sharp Zaurus, 67 Perl, 48 ((op code)), 49 DBI, 60 mongers, 53 package manager, 50 Prima, 53 DetailedList, 55 Grid, 54 sockets, 61 Tk, 52 PHP, 52 PostgreSQL, 10 Python, 52

Microsoft componentes COM+, 56 MySQL benchmarks y propiedades, 12 propiedades b´asicas, 9 vistas, 14

rollback, 7 Ruby, 52

ODBC, 13 Oracle Empresa, 6 RMAN, 8 versión 10g, propiedades, 7 Orientación a Objetos análisis, 11

Tcl, 52

script, 48 SQL definici´on, 8

usuario experto, 41 frecuente, 41 novato, 41 Visual Studio .NET, 52 123

´INDICE ALFABETICO ´ Compact Framework (diagrama), 70 Framework (definici´ on), 70 Framework (diagrama), 69 MIT, 72 P/Invoke, 71 reflection emit, 71 remoting, 71 SDE, 72 serializaci´on, 71 XPath/XSLT, 71 XML, 72

