UCE SOCIEDAD ANONIMA (SAUCE)

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

1

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´on de Ingenier´ıa Inform´atica 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´on pr´actica 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´a utilizado y mejorado en su posterioridad. Y susceptible de ser cambiado y readaptado qui´en sabe cu´antas veces. Pormenorizar minuciosamente cuantas m´as particularidades del mismo es una responsabilidad para que pueda servir como documentaci´on en dichas incursiones .

Por otra parte, al hilo del esperable caso antedicho, no s´olo prever que estas notas puedan ser vistas a posteriori como un cuaderno de bit´acora sino que quienes las puedan llegar a utilizar o incluso a leer, no tendr´ıan por qu´e ser necesariamente expertos inform´aticos. Por ello, contribuir a su buen entendimiento y a su caracter divulgativo, ser´a y ha sido, otra de las tareas del autor. En este sentido, el lector notar´a que algunas secciones se resuelven con m´as cuidado para que cualquiera las entendiese, que no otras m´as t´ecnicas y de antemano destinadas a la evaluaci´on del trabajo.

Finalmente, aunque responde a necesidades de otro calibre, y ha colaborado m´as 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´en para recordar tanto d´onde se puso cada cosa como por qu´e se tom´o cada decisi´on. Dejar demasiada informaci´on 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´afica y que no inponga limitaciones en cuanto al sistema operativo. Lo que en realidad se necesita es un sistema de software que la organizaci´on 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´on .

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´oximo a estos menesteres, acercarse a las problem´aticas m´as 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´olo 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´as interesado le ha de servir para tener un modelo de representaci´on del proyecto y, desde ah´ı, tanto evaluar su bondad estructural de conjunto como aproximarse algo m´as en cualquier tipo de mantenimiento posterior.

El cap´ıtulo 5o desciende hasta las contradicciones m´as materiales, propias de la implementaci´ on o puesta en pr´actica. Movi´endose en todo momento en el terreno de menor nivel de abstracci´on, explica los problemas encontrados y las decisiones tomadas para resolverlo; sirviendo, en especial a un lector menos interesado en las cuestiones te´oricas, para valorar muchos aspectos pr´acticos que son propios del ((d´ıa a d´ıa)) de la programaci´on en general.

Por necesidades ajenas al inter´es acad´emico de este trabajo pero –parad´ojicamente– aumentando ´este, surge un nuevo frente que atender cuyo desenlace, sin ser una necesidad primordial, acaba resultando de gran inter´es. Se trata de la aparici´on 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´on a corto plazo es que el destinatario de este sistema decida si invierte o no en avanzar m´as 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´actico tanto sobre la calidad del producto final como sobre las razones m´as profundas de sus propiedades, ya sea en el ´ambito de las decisiones de toda ´ındole que se han tomado como en cuanto al nivel de trabajo invertido en el dise˜ no.

x

´Indice general Pr´ ologo

VII

Resumen

VIII

´Indice general

XI

´Indice de figuras

XV

´Indice de cuadros

XVII

1. Introducci´ on 1.1. Descripci´on de la situaci´on . . . . . . . . . . . . . . . . . . . . . . . .

1.2. Prop´ositos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . .

2. Estado del arte 2.1. Introducci´on: fundamentos teoricos . . . .

2.1.1. Definici´on . . . . . . . . . . . . . .

2.1.2. Ventajas y desventajas . . . . . . .

2.2. Reflexi´on 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

xi

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

4.2. Dise˜ no arquitect´onico . . . . . . . . . . . . . .

El flujo de trasformaci´on . . . . . . . .

4.2.1. Cliente . . . . . . . . . . . . . . . . . .

Descomposici´on de primer nivel . . . .

Descomposici´on de segundo nivel . . .

4.2.2. Servidor . . . . . . . . . . . . . . . . .

Descomposici´on de primer nivel . . . .

Descomposici´on de segundo nivel . . .

4.3. Descripci´on de m´odulos (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´aquina . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Alternativas independientes de la plataforma ¿Por qu´e no JAVA? . . . . . . . . . . . . . . ¿Por qu´e no Perl? . . . . . . . . . . . . . . .

La decisi´on 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´e 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´on . . . . . . . . . . . . . . . .

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

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´on en el cliente sobre 7.1.3. El editor . . . . . . . . . . . .

7.1.4. Reajustes en el c´odigo . . . .

Divergencias Windows-Linux .

El dilema del socket . . . . .

7.2. Velocidad . . . . . . . . . . . . . . .

7.2.1. Medici´on . . . . . . . . . . . .

7.2.2. Resultados . . . . . . . . . . .

7.2.3. Conclusiones . . . . . . . . .

7.3. Valoraci´on 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

91

El c´ odigo del cliente

97

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

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

7

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´on de login y password Inicio sin conexi´on . . . . .

Inicio sin conexi´on an´omalo Menu de conexi´on . . . . . .

. . . .

. . . .

. . . .

xv

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

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´on m´odulo: Grabar tabla localmente. . . . . . . . . .

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

Descripci´on m´odulo: mostrar la tabla. . . . . . . . . . . . . . .

Descripci´on m´odulo: valores de la conexi´on. . . . . . . . . . .

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

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

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

Descripci´on m´odulo: conexi´on inicial con la base de datos. . .

Descripci´on m´odulo: escucha de peticiones del cliente (primer bis cliente-servidor). . . . . . . . . . . . . . . . . . . . . . . .

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

4.11. Descripci´on m´odulo: gesti´on 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´on y env´ıo por suscripci´on de varias publicaciones ofertadas por el Ateneo Madrid XXI y otras empresas de holding relacionadas con ´este.

Actualmente esta editorial tiene repartidos por la pen´ınsula unos cincuenta trabajadores comerciales encargados de la difusi´on y suscripci´on mensual de todas sus publicaciones. Estos comerciales, recaban semanalmente informaci´on de nuevos clientes o suscritos y de nuevos posibles clientes.

En la Oficina Central, ubicada en Valencia, adem´as de cotejarse la contabilidad y hacerse otras tareas de gesti´on, 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´on correspondiente a los mismos. Se actualizan las nuevas entradas y se comprueba toda la informaci´on entrante. La base de datos crece inexorablemente.

Debido a la inexistencia de un departamento inform´atico, a la imprevisi´on de sus gestores y al exponencial desarrollo de los nuevos proyectos: la administraci´on centralizada de todo este operativo viene siendo desde hace tiempo, lenta y poco resolutiva.

Los comerciales env´ıan la informaci´on semanalmente de muy diferentes maneras, habitualmente tablas en un correo electr´onico pero a veces hasta se env´ıan manuscritos por fax. La informaci´on 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´on 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´an dispuestos a mejorarlo pero no pueden dedicar a ello una parte del tiempo de los empleados de la Oficina Central, no est´an seguros de hacer una inversi´on 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´on la figura 1.1 describe la situaci´on en el terreno estrictamente f´ısico. En pocas palabras: Un sistema de suscripci´on 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´on 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´on que pueda funcionar como cliente y que no est´e cerrada, es decir, susceptible de ser ampliada en posteriores fases de mantenimiento. Que sea f´acil 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´on tenga acceso s´olo a lo que necesita. + Muy importante, el sistema debe ser r´apido y debe poder generar informes a cerca de la base de datos de manera inmediata. + Por u ´ ltimo, pero no menos importante, la soluci´on debe ser lo m´as barata posible.

1.3.

Objetivos del proyecto

Atendiendo al orden cronol´ogico que requieren estos prop´ositos y estudi´andolos m´as pormenorizadamente, se entiende que: + Se necesita migrar tanto el hardware como el software portador de la Base de Datos a un sistema mucho m´as seguro, m´as r´apido, m´as 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´on actual es v´alida 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´on o ´esta 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´e que la versi´on 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´atica y la informaci´on, 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 ´enfasis 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].

4

CAP´ITULO 2. ESTADO DEL ARTE



trabajos los necesitan)).

Implantar una base de datos en un sistema, frente al uso de ficheros cl´asicos, tiene ventajas y desventajas, t´enganse 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´as informaci´on que la suma individual de los datos por separado). + Mejor y m´as normalizada documentaci´on de la informaci´on, la cual est´a integrada con los datos. + Mayor eficiencia en la recogida, validaci´on e introducci´ on de los datos en el sistema. + Reducci´on 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´actica. Esto no tiene que ocurrir necesariamente, se refiere a un desfase entre la concepci´on te´orica, 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´eis que hay una cita donde aparece el listado de las organizaciones ben´eficas 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´elula 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´on 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´a en un terreno diferente del an´alisis que merece este tema, pero lo que se intenta introducir con esta peque˜ na presentaci´on es que en la actualidad, la tecnolog´ıa que maneja la informaci´on es un arma de un calibre inpensable, todo lo relacionado con ello merece un cuidado exquisito y es la piedra angular de cualquier organizaci´on ya sea social, empresarial, estatal, militar, administrativa o tambi´en popular.

Las principales multinacionales han promovido el desarrollo de esta tecnolog´ıa y la han hecho avanzar hasta llegar a una potencia de c´alculo y de consulta impensable hace cien a˜ nos. Ellos pueden utilizarlo para sus fines. Los estudiantes, ingenieros y profesionales de la inform´atica en general, deben aprender a esgrimir este arma y tienen la responsabilidad de denunciar cualquier tipo de uso an´omalo que se le pretenda dar.

2.3.

R Oracle

En junio de 2004 la consultora estadounidense IDC emiti´o 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´as competitivos en el mercado de la base de datos, desde su posici´on dirigente, ha ido obligando a todos los desarrolladores de bases de datos a cumplir una serie de criterios. La siguiente enumeraci´on4 recoge las veinte propiedades m´as avanzadas de la versi´on 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´acticas 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´on en relaci´on 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´on con el m´aximo de precisi´on 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´axima potencia. Cuanto mayor tama˜ no de tabla en menos tiempo se pueda emitir, mejor.

5. Tabla de flashback. O tabla de recuperaci´on, para borrados accidentales y otro tipo de p´erdidas de informaci´on.

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´on 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´andar y naci´o en los a˜ nos 70 en los laboratorios de IBM, hoy d´ıa, en ciertos ´ambitos es SQL*Plus quien marca el rumbo (o m´as marca el rumbo) de lo que debe ser SQL. Sus nuevas contribuciones representan un modelo de int´erprete 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´aticamente lo gestione optimizando las posibilidades.

9. RMAN Un sistema autom´atico7 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´olo qu´e usuario act´ ua sobre la base de datos sino qu´e 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´e queda, qu´e se esta esperando, cu´anto va a tardar.

12. Vistas materializadas. Una gesti´on 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´on 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´on 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´es de plataformas, haciendo que la publicaci´on de datos sea cuanto m´as f´acil y m´as r´apido.

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´es 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´on m´as, de manera que s´olo 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´as falta hace. No pueden producirse errores de falta de memoria por un problema de gesti´on.

18. Monitor autom´ atico de di´ agnostico. Debe imaginarse como un rob´otico 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´on y almacenamiento de trabajos (o sesiones) de la gesti´on de la base de datos para automatizar ciertas tareas rutinarias.

20. La guinda del pastel. Colecciones de estad´ısticas, retenci´on garantizada de datos para ((deshacer)) determinadas acciones, operaciones de cifrado m´as f´aciles y m´as 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´e usuarios tienen acceso a qu´e tablas y con qu´e permisos. + Buena reacci´on 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´andar SQL mayor que el de MySQL y tiene propiedades de orientaci´ on a objetos. ∗ Desventajas: – Es entre dos y tres veces m´as lento que MySQL. – Sobrecarga el sistema bastante m´as que MySQL.

2.4.3.

Comparativa

Aunque esta comparaci´ on est´a 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´as ambicioso que MySQL. No obstante, para un sistema de caracter dom´estico o similares, parece bastante m´as recomendable MySQL que es m´as r´apido 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´as utilizada que PostgreSQL. Por u ´ltimo, es interesante saber que aunque ambas son de libre distribuci´on y c´odigo abierto, mientras que MySQL est´a firmada con una licencia GPL (lo cual obliga al que la utilizare a liberar tambi´en su c´ odigo y firmar con GPL), PostgreSQL no tiene copyleft y por lo tanto deja a sus usuarios ((libertad)) total16 .

16

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 ´el 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´es 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´etodo 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´on organizativa del equipo porque ´este se reduce a un s´olo responsable. Sin embargo, para atacar lo que se va a hacer, es importante estudiar la descomposici´on 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.

11

´ 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´omico es una clave en cada parte de este desarrollo, dentro del mundo de las bases de datos, se ha visto en la secci´on 2.4 las posibilidades.

Por las caracter´ısticas del sistema descrito parece m´as adecuada MySQL (m´as r´apida, que consuma menos recursos). Se trata de una base de datos potente, puede descargarse gratuitamente desde http://www.mysql.com y est´a comunmente comprobada.

Conviene decir aqu´ı, que aunque pueda parecer una man´ıa de gur´ us del GPL2 o m´as bien una sensaci´on subjetiva por todo lo que est´a desarrollado siguiendo esta orientaci´on, 2

Licencia P´ ublica del proyecto GNU.

´ CAP´ITULO 3. ANALISIS



MySQL es realmente una soluci´on seria: T´engase en cuenta, que por ejemplo, hace m´as 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´olo 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´on 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´arselo dos veces y estudiar detenidamente el estudio realizado4 Adem´as MySQL: ∗ Tiene APIs 5 para distintos lenguajes de programaci´on: 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´on con Win32.

MySQL tiene muchas otras prestaciones, que la hacen ser una competitiva soluci´on 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´ermino 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´as 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´on para aplicaciones.

6 M´as 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´on 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´on m´as asequible a las posibilidades actuales.

En definitiva, un sistema software donde la aplicaci´on cliente sea la misma para dentro que para fuera de la oficina (donde los equipos con Linux van a abundar) y donde la aplicaci´on servidor pueda correr en Windows por lo que pueda decidirse en el futuro pero est´e adaptada a la optimizaci´on que le extraiga Unix.

¿Un proceso servidor como intermediario hasta MySQL? Llegados a este punto, aunque a´ un no est´a 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´on 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´emico. 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´on para tomar esta decisi´on 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´olo un sesgo (su sesgo) de la tabla.

Con un campo a˜ nadido a las tablas correspondientes (del due˜ no de la informaci´on) se puede enmascarar este problema y hacer que nunca llegue hasta un cliente remoto la informaci´on no deseada. Dividir la tabla en peque˜ nas tablas es una soluci´on 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´e usando MySQL u otra base de datos. Se podr´ıa cambiar de base de datos a voluntad, mientras la comunicaci´on entre el servidor y el cliente siga igual. Los clientes seguiran funcionando y sus usuarios no tienen ni por qu´e saberlo. + El cliente queda liberado de cierta carga, esta es una buena ventaja, y est´a relacionada con lo mencionado en 1.3 en la p´agina 3. Recu´erdese: una aplicaci´on 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´olo 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´aquina donde corra el proceso servidor, como lo que en cierta literatura se conoce con el nombre de ((bastion host)) o bien disponer de ´este 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´on 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´engase 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´a bajo control mientras que el segundo podr´ıa ser imitado en cualquier tipo de ataque al sistema simplemente utilizando esta documentaci´on.

Tomando pues la decisi´on de desarrollar este programa servidor8 t´omese como referencia la figura 3.2 que, como diagrama de emplazamiento, sirve para comprender a partir de ahora la relaci´on entre los distintos elementos que se van a manejar.

3.1.3.

Recapitulaci´ on de requisitos

El cap´ıtulo primero est´a escrito con un conocimiento parcial de la soluci´on. A medida que el estudio de la misma avanza, la respuesta es m´as completa, m´as multilateral. Es hora de aclarar al lector sobre lo que se va a hacer: 1. Desarrollar un programa cliente: + Con entorno gr´afico 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´on acerca de las conexiones y el trabajo que ´estas realizan.

3. Poner en marcha una m´aquina 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´on 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´actico para lo que el cliente necesita y ayuda a comprender el nivel de complejidad –o sencillez– del mismo.

- Para probar al servidor convendr´a programar un ((cliente de pruebas)) que no requiera la interfaz gr´afica y permita agilidad al desarrollar y depurar el c´odigo.

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´es habr´a que contemplar esta situaci´on: - 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´olo pueda hacer ajustes y variaciones en la disposici´on del mismo sino que tenga que comprobar cualesquiera de las tareas que est´an 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´on y que determinan diferentes ´areas 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´afico un cliente mucho m´as 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´e 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´agina 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´emico 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´on, concentrar las fuerzas en poner en marcha con ´exito la aplicaci´on cliente, el proceso servidor y hacer los ajustes necesarios a la base de datos, permitir´a 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´on es global, de manera que no hay distinci´on entre el proceso servidor del proceso cliente, porque en u ´ ltima instancia la informaci´on que manejan es la misma.

El suscriptor La base de informaci´on sobre la que gira todo este sistema es cada uno de los registros con informaci´on sobre los clientes y posibles clientes.

Su trasformaci´on en altas como clientes o bajas es el primer nivel de trasformaci´on posible. Cada mes, se envia al banco una petici´on de domiciliar los cobros a todos los suscritos (incluyendo los nuevos de ese mes) y ´este devuelve un informe sobre los que tuvo ´exito. Siempre puede haber incidencias y aunque en teor´ıa alguien est´e suscrito para la base de datos, fallar en el pago un mes por error bancario, alguna confusi´on 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´on). alta suscripción [1:1]

persona registrada

[1:m]

pago del mes

[1:1]

baja suscripción

Figura 3.6: Sub-diagrama entidad relaci´on: 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´on 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´a 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´a pagando. Desde la base de datos, se genera una lista de etiquetas con las direcciones de los clientes, se genera en funci´on del informe bancario, que contiene qui´en paga y qui´en 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´on aut´onoma, el proceso cliente s´olo puede recibir informaci´on de tres fuentes diferentes: - Puede recibir informaci´on 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´on 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´as profundo hay varios procesos que aparecen separados por su exclusivizaci´on y por su importancia: - La conexion inicial con el servidor es un momento particular. Debe haber un proceso que obtenga de la interfaz gr´afica los datos del socket y direcci´on 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 ´este pueda gestionarlo m´as habilmente. Al rev´es sucede lo mismo.

- Cuando el usuario profundiza en el nivel principal que le muestra la interfaz gr´afica 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´aticamente, igual que cuando se traen o env´ıan tablas a MySQL. - Las tablas est´an en memoria y desde la interfaz gr´afica pueden modificarse.

Hay m´as 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´as 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

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´a 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 ´el, 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´es 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´on, 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´on y terminaci´on de cada proceso concurrente debe ser impecable para que el sistema no se colapse nunca por esta raz´on. De la misma manera, la gesti´on de los sockets debe ser cuidadosa. La figura 3.12 representa el estado del servidor al llegar un nuevo cliente y pudi´endolo haber duplicado m´as veces, dibujando m´as 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´on acerca de la base de datos ni provinente de ella.

Permanecer a la escucha por el socket inicial (conocido). Cuando llega una conexi´on autom´aticamente 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´on de diagramas que describa el comportamiento y la transici´on entre los estados, deben quedar anotadas ciertas cuestiones fundamentales: - El proceso cliente tiene tanto en una versi´on gr´afica como en una versi´on de pruebas dos estados importantes. + Conectado a la base de datos. S´olo 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´as el servidor debe dar la respuesta correspondiente. Este estado determinar´a el resto del comportamiento del cliente. + Desconectado: es el estado inicial y final si todo sigue un curso normal.

- En cada conversaci´on entre cliente y servidor la secuencia debe ser: 1. Pregunta del cliente.

2. Respuesta del servidor.

Que uno u otro est´en 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´on del software) ya sea desde el punto de vista del flujo de los datos por cada uno de los procesos o a su trav´es; o bien siguiendo una filosof´ıa de Orientaci´on a Objetos1 . En el cap´ıtulo 3 (p´agina 11) se ha dejado esta contradicci´on abierta, razonando que a´ un no estaba lo bastante maduro el an´alisis del problema como para pensar en qu´e filosofia de dise˜ no le era la apropiada. Es hora de abordarla.

A favor de la Orientaci´on a Objetos podr´ıa apuntarse: + El manejo de los sockets puede enmascararse para su uso y hacer esta tarea m´as trasparente a la hora de abordar los procesos de comunicaci´on (pregunta/respuesta) entre cliente y servidor. + El manejo de las tablas en el interfaz gr´afico quiz´a merece pensarse desde la OO, pudi´endose diferenciar lo que es el contenido de la informaci´on de sus metodos de representaci´on en pantalla o de modificaci´on. + Se pueden resolver otras tareas como clases, separando informaci´on y m´etodos, creando quiz´a una clase que encierre lo relativo a las sentencias SQL, su traducci´on, 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´on 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´on, ocultamiento de la informaci´ on y modularidad.)) Aunque todos los m´etodos de dise˜ no procuran esto el ((DOO proporciona un mecanismo que permite al dise˜ nador conseguir las tres sin complejidad)) definici´on de [9] en su tercera edici´ on.

28

˜ CAP´ITULO 4. DISENO



· Por un lado la base de datos (en este caso MySQL) facilitar´a el manejo de la informaci´on (de los registros) y las cuestiones de seguridad de acceso de forma inmediata. · La interfaz gr´afica propia del sistema o lenguaje de programaci´on que se decida utilizar deber´a integrar mecanismos para almacenar lo representado en pantalla de manera que la tabla cargada no necesite ser manejada por el programador a m´as nivel que el usuario de una librer´ıa. Por otra parte, si se programan m´etodos para cambiar el contenido de la tabla que requieren nuevos accesorios propios de la interfaz gr´afica como cuadros de di´alogo y ventanas, acabar´ıan cre´andose ciclos (ocultos por las clases creadas) en el uso de la librer´ıa gr´afica.

- El manejo de los sockets tambi´en debe ser facilitado por el lenguaje de programaci´on utilizado. Concebir este problema como una tarea complicada es err´oneo. El cliente y el servidor s´olo 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´actica siempre eleva la calidad, en este caso ser´ıa exactamente matar moscas a ca˜ nonazos. Har´ıa m´as complejo el trabajo y no resolver´ıa ni mejorar´ıa nada en particular.

NOTA: Obs´ervese que en esta secci´on se han introducido impl´ıcitamente algunas necesidades que deber´an ser tenidas en cuenta a la hora de elegir el lenguaje de programaci´on, las librer´ıas gr´aficas 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´alisis se puede descartar que haya un flujo de transacci´on.

En el cap´ıtulo correspondiente de [9] Pressman define este tipo de flujo de la informaci´on cuando los datos se ((mueven a lo largo de un camino de entrada que convierte la informaci´on del mundo exterior en una transacci´on. La transacci´on se eval´ ua y bas´andose en ese valor, se inicia el flujo a lo largo de uno de muchos caminos de acci´on. El centro del flujo de informaci´on 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´on se denomina centro de transacci´on)). Y no existe en el cap´ıtulo de an´alisis 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´on y estudiando primeramente la figura 3.9 puede desglosarse el subproceso de interfaz gr´afica desde dos intereses: ∗ La constante emisi´on gr´afica de la tabla y del resto de variables de entorno que supone tener una ventana para la aplicaci´on 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´on, los datos desde Ms-Excel, etc.

Como muestra la figura 4.1, la interfaz gr´afica se dividir´ıa en varios procesos diferenci´andose lo que es la salida gr´afica propiamente dicha de las entradas de valores de la conexi´on, 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´on de la tabla al disco (en un archivo Ms-Excel ) o la salida por pantalla; de las salidas de informaci´on o preguntas al servidor.

Descomposici´ on de segundo nivel Con la subdivisi´on de la figura 4.1 se puede presentar una descomposici´on de segundo nivel con un aspecto de ´arbol propio de la notaci´on de una jerarqu´ıa de control.

Siguiendo una partici´on estructural de tipo horizontal en la figura 4.2 se ha hecho una primera aproximaci´on desglosando por niveles de profundidad y separando la entrada de la salida a nivel local, aunque la interfaz gr´afica sea un concepto que cubra uno y otro servicio.

La relaci´on 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´on perfecta entre m´odulos; Pressman en [9] dice que ((se pueden combinar dos o incluso tres burbujas y representarlas como un solo m´odulo, o una sola burbuja puede dividirse en dos o m´as m´odulos (...) La revisi´on y el refinamiento pueden llevar a cambios en la estructura, pero puede servir como una primera iteraci´on 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´as, el proceso servidor, es a´ un m´as sencillo que el del cliente y la conversi´on de los DFDs mucho menos problem´atica.

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´on y en el refinado. Las figuras 3.13 y 3.14 muestran con claridad los problemas que habr´a que abordar a la hora de desarrollar el servidor.

Descomposici´ on de segundo nivel M´as aun, de una manera a´ un m´as expl´ıcita y menos arbitraria, se puede diferenciar que el proceso servidor tiene dos v´ıas de comunicaci´on con subdivisiones de entrada y salida, en lo que a la parte concurrente se refiere.

En relaci´on 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´a 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´on de segundo nivel, proceso principal conexi´on inicial del cliente del resto de ejes de construcci´on 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´on es un proceso donde intervienen todos los factores en el servidor de manera concentrada: - Informaci´on del login y el password que el usuario ha introducido en el cliente.

- La confirmaci´on de la base de datos.

- La creaci´on de un socket dedicado para el nuevo cliente.

- La instanciaci´on 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´on 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´as importantes: - Desarrollar una descripci´on del procesamiento para cada m´odulo.

- Una descripci´on de la interfaz para cada m´odulo.

- Anotar las restricciones y limitaciones del dise˜ no.

Concretamente, conviene releer que ((un texto explicativo del procesamiento es una delimitada descripci´on sin ambig¨ uedades del procesamiento que ocurre dentro de un m´odulo. La narrativa describe el procesamiento, las tareas, las decis´ıones y la entrada/salida)).

Y resaltar que en cuanto a la interfaz, convendr´a detenerse a concretar la entrada y la salida del sistema en cada m´odulo, al tiempo que postergar lo relativo a las interfaces entre m´odulos y las interfaces hombre-computadora que se abordar´an en secciones siguientes.

Es interesante respetar la jerarqu´ıa de los ´arboles 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´olo para facilitar el trabajo en esta secci´on y su lectura sino tambi´en para poder anotar las limitaciones que se van encontrando en el dise˜ no y que se deber´an tener en cuenta en pr´oximas fases.

4.3.1.

Descripci´ on de m´ odulos en el cliente

Para entender las tablas de esta secci´on, se deben cotejar conjuntamente con la figura 4.1 en la p´agina 31 y los DFDs de los que procede.

El objetivo de esta secci´on es reducir el m´aximo n´ umero de m´odulos a una descripci´on m´as 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´aximo 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´on) tabla en memoria y visualizaci´on en pantalla Ms-Excel Permite al usuario ver la tabla que est´a 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´on cliente interfaz de usuario (teclado y rat´on) variables globalescon la informaci´on La direcci´on 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´on.

Cuadro 4.4: Descripci´on m´odulo: valores de la conexi´on.

Limitaciones en el modelo del cliente Avanzar la descripci´on de los m´odulos provista en esta fase del refinado de los DFDs, su estudio y su descomposici´on: aproxima una visi´on m´as real del trabajo hecho hasta ahora, sus limitaciones y algunas de las dificultades que a´ un no han sido resultas.

- La cuesti´on 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´as adelante con una interfaz gr´afica o un soporte propio del lenguaje de programaci´on que resuelva esto sigue invitando por el momento a postergar esta decisi´on, pero al mismo tiempo debilita la visi´on global que se tiene y supone una dependencia de un entorno de trabajo (librer´ıas, lenguajes de programaci´on, etc) que a´ un no se disponen.

- Algunos de los m´odulos han quedado ambig¨ uos o diluidos por ser demasiado generales y no se han descrito en las tablas de estas p´aginas. 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´on deber´a revisarse sobretodo los DFDs y documentar debidamente en qu´e partes del c´odigo 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´on 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´on del usuario que remotamente est´a conectado desde el cliente, el proceso servidor (ya en su parte concurrente) pide conexi´on a la base de datos, obteniendo acceso y mostrando al usuario sus bases de datos accesibles o devolvi´endole una negativa.

Cuadro 4.8: Descripci´on m´odulo: conexi´on 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´odulos, se trata ahora de ver qu´e debilidades han aparecido al hacer lo propio con los m´odulos del servidor: - Examinando los m´odulos del proceso concurrente y la figura 4.4 (en la p´agina 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´on). Un cliente llega y le dice por qu´e socket (del cliente) solicita conversar. El servidor crea su propio socket para hablar con aqu´el y ambos liberan la conversaci´on 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´on m´odulo: gesti´on de consultas del servidor.

m´as c´omodo y mucho m´as intuitivo juntarlos pues la salida se debe a la entrada y no puede entenderse por separado.

Queda para fases posteriores la decisi´on del nivel de subdivisi´on que se le va a dar a las cuatro ramas del ´arbol que en las tablas han aparecido como dos m´odulos.

- El inicio en el servidor: llegada de un nuevo cliente, generaci´on de socket dedicado, generaci´on de un proceso concurrente y posterior conexi´on 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´on de c´omo se resuelva la gesti´on de los sockets quedar´a 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´as a Pressman en [9] enti´endase por interfaz los tres casos siquientes: - ((El dise˜ no de interfaces entre los m´ odulos software)) Esta parte no ser´a abordada en esta secci´on, porque la sencillez con la que hasta el momento se ha resuelto la comunicaci´on entre los datos y los procesos, invita a pensar que en posteriores fases del desarrollo, podr´a resolverse de una manera m´as 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´a una comunicaci´on mediante sockets, es decir, un interfaz TCP/IP. Tambi´en 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´on de esta interfaz se ha postergado a fases posteriores. Pero antes o despu´es debe ser abordada pues se trata de la piedra angular para la comunicaci´on entre el cliente y el servidor. ∗ La interfaz entre el servidor y la base de datos est´a en funci´on de las librer´ıas que permitan la conexi´on con la base de datos. Sabiendo que est´a ser´a MySQL puede recordarse aqu´ı que en la secci´on 3.1.2 (p´agina 12) se valoraba como una ventaja de MySQL que pod´ıa ser invocada desde diferentes lenguajes de programaci´on. Como a´ un no se ha decidido nada acerca del lenguaje de programaci´on el dise˜ no de dicha interfaz queda pendiente, aunque no ser´a 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´as y (siguiendo los pasos de Pressman en [9]) abrir el apartado dedicado a esta discusi´on.

4.4.2.

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

La figura 3.4 en la p´agina 18 mostraba tres tipos de usuario diferentes. Lo que debe importar de ellos en esta secci´on es su conocimiento sint´actico6 y sem´antico7 del sistema: - El administrador del sistema no debe preocupar al dise˜ nador (adem´as 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´ITULO 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´actico. La l´ınea de demarcaci´on para construir la interfaz hombrem´aquina en la aplicaci´on cliente debe rebajarse hasta ellos. La imagen del sistema debe guiarles en sus operaciones y s´olo deben necesitar informaci´on adicional para resolver la conexi´on inicial, proceso que una vez aprendido debe ser sencillo.

- Los gestores pueden ser considerados usuarios frecuentes (con ((conocimiento sem´antico razonable pero con recuerdo vago de la informaci´on sint´actica))).

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 ´esta u otra documentaci´on, y de la ayuda del administrador del sistema. De todas maneras lo m´as importante es que si los usuarios novatos pueden utilizar la interfaz gr´afica de la aplicaci´on cliente ellos deben tenerlo m´as f´acil.

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, ´este ser´a ´ı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´as importantes que quedan por tomar. Por qu´e lenguaje tomar partida. En principio no hay ninguna obligaci´on de elegir uno u otro en particular, pero s´ı que es menester, antes de tomar ninguna decisi´on, apuntar qu´e criterios1 para elegir el lenguaje de programaci´on se han ido contemplando hasta el momento y jerarquizarlos (de m´as importante a menos importante): 1. Tiene que ser uno de los enumerados en la secci´on 3.1.2 ya que lo que s´ı que est´a decidido es que la base de datos ser´a MySQL, recu´erdense 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´a 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.

42

´ CAP´ITULO 5. IMPLEMENTACION



4. Debe poder acceder a informaci´on 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´an desde Excel, al cual ya est´an habituados.

5. Interfaz gr´afico 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´on 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´e alternativas existen al respecto2 : ∗ C/GDK/GTK: Lenguaje de programaci´on C y librer´ıas gr´aficas GDK y GTK. Ventajas: + La potencia y la buena (e hist´orica) relaci´on de C con Linux. + Las librer´ıas gr´aficas 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´erico con c´ odigo espec´ıfico, lo que complica el desarrollo)). Esta es sin duda la raz´on m´as 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´emico 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 ´nica diferencia es que C++ permite Orientaci´on 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´emico, 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´en siendo referenciados.))

El caso merece ser estudiado con algo m´as 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´erselas con ´el, 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´on 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´on: - La complejidad de la arquitectura.

- La migraci´on de la arquitectura de 2 a 3 capas.

- Las necesidades de la organizaci´on4 .

- 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´an 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´en tiene, seg´ un parece: - Con respecto a la portabilidad: ((para manejo a bajo nivel deben usarse m´etodos nativos)). En cuanto que limitaci´on 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´a 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´as 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´aquina virtual de JAVA (a partir de ahora s´olo 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´ecnica)) 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´as lento que C y C++. Siempre se ha atribuido este problema al hecho de incorporar un proceso intermediario entre la aplicaci´on, 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˜no m´as grande representa qui´en 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´as lento que ...))) es m´as 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´on 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˜no m´as peque˜no (siempre en negrita) representa qui´en es mejor)).

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

Una conclusi´ on provisional Los puntos m´as d´ebiles (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 ´este y su ((no inferioridad)) con respecto a C. En el sistema al que se deben estas p´aginas, 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´on y lanzamiento del proceso cliente sean lo m´as r´apidas posible y no sobrecarguen el sistema en dicha m´aquina.

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´as interesante es que el usuario disponga para el equipo cliente un ejecutable que resuelva concentradamente la apliaci´on.

Otro tipo de formatos que compliquen m´as ese proceso y requieran del usuario la instalaci´on de la JVM es aqu´ı un lastre a evitar. Hay una diferencia importante entre ser independiente de la plataforma y tener f´acil portabilidad entre plataformas.

´ CAP´ITULO 5. IMPLEMENTACION



3. En lo que a programaci´ on (m´as bien codificaci´on) se refiere, aunque no se ha profundizado previamente, JAVA es fuertemente Orientado a Objetos y tanto en la secci´on 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´omodo para este caso. Por eso conviene estudiar m´as 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´on se puede decir que hay dos posibilidades: Los lenguajes de programaci´on (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´on)) o archivo de instrucciones que se le introduc´ıa directamente al int´erprete del sistema operativo para resolver de manera m´as automatizada ciertas tareas de administraci´on. Los lenguajes interpretados han revolucionado esta concepci´ on y la han ampliado enormemente.

Perl nace del mundo de Unix. Su creador lo dise˜ n´o en 1987 inicialmente como un lenguaje de script para fortalecer y simplificar ciertas tareas de administraci´on del sistema operativo. De hecho, sus siglas12 significan algo as´ı como lenguaje pr´actico de extracci´on 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´odigo intermedio optimizado. Lo que se conoce gen´ericamente 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´aquina14 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´erprete, el ((opcode)) de Perl (por otra parte, de un nivel de abstracci´on mucho m´as 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´e Perl es mucho m´as 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´on est´a extra´ıdo de [4].

En inform´ atica se llama c´ odigo m´ aquina al c´odigo 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´on 5.6, Perl dispone de un potente Package Manager 16 que es una aplicaci´on 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´an en la actual configuraci´on.

Con respecto a la f´acil 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´erprete (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´on importante para decidirse, porque en el sistema que ata˜ ne a esta discusi´on, como se ha dicho, ser´a necesario desarrollar un servidor concurrente. Aunque lo que no se ha dicho, en su correspondiente secci´on, es que parece que la implementaci´on de la concurrencia en JAVA es uno de sus puntos fuertes. As´ı que en esta cuesti´on, vencer´ıa la decisi´on 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´omo est´a Perl de fuerte.

M´as adelante convendr´a discutir y decidir cu´al de ambos m´etodos utilizar: - Procesos o fork(): Parece ser que Perl soporta el est´andar 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´acticamente calcado de C. - Hilos: La literatura al respecto de la manera en que Perl implementa esta t´ecnica parece estar quedando obsoleta. Las referencias en Internet, en la propia documentaci´ on de Perl e incluso en las referencias bibliogr´aficas (p´agina 120) que cierran este documento; arrojan la sombra de duda al decir que se trata de una versi´on experimental. Perl incluye esta versi´on experimental desde su versi´on 5.005 pero lo cierto es que tras la inclusi´ on de un nuevo modelo de implementaci´on en la versi´on 5.6 y los sucesivos ajustes, a d´ıa de hoy puede decirse que Perl soporta hilos. Y con la versi´on 5.8.4 (la u ´ltima a fecha de redacci´on 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´odigo.

Pues bien, en Perl existe la misma desventaja o todav´ıa m´as, pues realmente, por lo que respecta a Larry Wall y al equipo oficial, cualquier cuesti´on que se diga acerca de esto, es una mera promesa. A parte de meter el script en un c´odigo de C no parece haber muchas posibilidades.

16

administrador de paquetes

´ CAP´ITULO 5. IMPLEMENTACION



Efectivamente, esta ser´ıa una raz´on 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´as potente de lo que a primera vista parece.

Se trata de la aplicaci´on 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´en 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´on y quiz´a a˜ nadir alguna l´ınea comentada al c´odigo del script que para el int´erprete oficial de Perl ser´an solo comentarios pero que perl2exe interpretar´a como detalles especiales a cerca de las librer´ıas que se han usado, y podr´a enlazarlas ((por s´ı mismo)) a la hora de generar el c´odigo. Hay que aclarar, que en realidad, perl2exe utiliza el int´erprete 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´erica. Todo lo referente a este programa puede encontrarse en una modesta p´agina web 18 donde tambi´en hay informaci´on de otros programas de IndigoSTAR. En lo relativo a las licencias, la versi´on m´as barata de perl2exe vale 50 d´olares estadounidenses19 . Pero existe una versi´on shareware siempre disponible en la p´agina web que tiene lo fundamental, no caduca y lo u ´nico que supone es imprimir en ASCII20 un cartel de publicidad de IndigoSTAR. As´ı que para lo que ata˜ ne a estas p´aginas, es como si fuera gratuito.

La decisi´ on final Posiblemente el lector, tenga una premonici´on de qui´en 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´on: - 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´on 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´equito)). 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´as 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´e se ha decidido finalmente utilizar Perl: 1. Es independiente de la plataforma y f´acilmente portable.

2. Es m´as r´apido que JAVA seg´ un se ha discutido.

3. Es compatible con MySQL. 4. Est´a completamente libre de licencias.

5. Es f´acil 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´aficas 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´an 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´on la biblioteca est´andar de Perl en lo que se refiere a aplicaciones con ventanas es Perl/Tk. Sin embargo su implementaci´on no es precisamente amigable. Se trata de la primera aproximaci´on para resolver esto y est´a pre˜ nada de varios aspectos: - Las dolencias y debilidades del primer (lenguaje de script) Perl. M´as destinado (y estructuralmente pensado) para ser un lenguaje de shell que de entornos gr´aficos.

- En cuanto a su parte gr´afica, Perl est´a m´as acostumbrado a ser complemento de CGI22 en p´aginas web que (otra vez) de entornos gr´aficos.

El recurso m´as sofisticado al respecto estar´ıa en el paquete para Visual Studio .NET. La principal desventaja es que no est´a libre de licencias. Visual Perl tiene un entorno gr´afico 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´on de un kit de desarrollo para Perl.

Control del c´ odigo fuente.

Aunque la informaci´on para resolver esta secci´on est´a extra´ıda de fundamentalmente de http://www.ActiveState.com y http://www.microsoft.com y no ha habido, por lo tanto, pr´actica directa sobre el mismo, la sospecha de que Visual Perl est´a en la otra cara de la moneda de lo que Perl (y el mundo del Open Source) representa est´a 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´on financiera, pero con todo lo dicho, llegados a este punto, parece estar m´as cerca el retroceso hasta JAVA que el avance hasta Visual Perl Lo que se ha venido calificando, desde una sensaci´on subjetiva del que se sumerge en Internet buscando sobre Perl, como el ((s´equito)) 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´as 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´afico 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´as, tiene la ventaja de que s´olo interviene en un archivo y es f´ acil comprobar lo que ha hecho. Por lo que el programador m´as novato no se ve ((en manos)) de trozos de c´odigo que no conoce, no entiende y ni siquiera mira.

Por alguna raz´on las librer´ıas de Prima, aunque tambi´en est´an documentadas en la http://www.cpan.org, son poco populares. Ninguno de los libros citados en la bibliograf´ıa (revisar p´agina 120), en efecto, hablan de Prima. Esto se debe seguramente a que Perl ya tiene una biblioteca gr´afica est´andar y quiz´a sus partidarios m´as radicales no quieren ninguna m´as. Pero lo cierto es que Prima es muy potente, est´a 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´odulos y funciones que facilitan muchas posibilidades gr´aficas 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´as tosco) parecido al que muestra Ms-Excel. En la documentaci´on (v´ease [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´as importante es que con eso ya est´a todo hecho. En efecto, el ejemplo del que se ha extra´ıdo esta secci´on de c´odigo no es mucho mayor. Se ha definido una red en cuyas celdas aparecer´a 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´afico 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´as de una columna o matrices, existe Prima::detailedlist (en Perl se caracteriza a un m´odulo dentro de una librer´ıa de m´odulos 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´es 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´on correspondiente como reacci´on a ese evento.

NOTA: Recu´erdese que en la secci´on 4.3.1 (p´agina 35) esta cuesti´on qued´o pendiente: resolver la relaci´on rec´ıproca entre lo que hay almacenado en la memoria sobre la tabla y la representaci´ on gr´afica de esta. Pues bien, he aqu´ı una soluci´on 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´a por completo, que los gestores trabajan con informes y est´an habituados a Excel, etc.

En los cap´ıtulos 3 y 4 aparec´ıa por activa y por pasiva una funci´on en cada gr´afico que se comunicaba de alguna manera con este entorno y se concret´o que cuanto menos, el cliente deb´ıa entenderse con Ms-Excel y poder portar informaci´on con ´el. Se ha indicado y se ha caracterizado, pero no se ha resuelto.

Es hora de afrontar, desde el terreno del lenguaje de programaci´on, las posibilidades que ofrece Perl y el propio entorno de Microsoft para resolver esta cuesti´on 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 ´esta concretamente el m´odulo 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´odulos especializados que se enlazan o utilizan din´amicamente en tiempo de ejecuci´on. Son por tanto m´odulos binarios cerrados (no trozos de c´odigo ni paquetes de librer´ıas, que ser´ıa lo propio de la Orientaci´ on a Objetos). Lo que esta idea promueve es la especializaci´on masiva del software. Tambi´en facilita el dise˜ no y permite usar software ajeno con permiso del due˜ no pero sin poder modificarlo (superando tambi´en en esto a la filosof´ıa de la Orientaci´ on a Objetos).

En lo que a estas p´aginas ata˜ ne, Microsoft ofrece un servicio de componentes llamado R componentes COM+. ((Las clases administradas se generan con Microsoft Visual Studio .NET y despu´es 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´odulos en la librer´ıa Win32 de Perl, est´an 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´odigo 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´etodos para hacer esto y lo cierto es que resulta bastante f´acil e inmediato, como el ejemplo muestra.

Las desventajas por las que finalmente esta t´ecnica 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´on y lastra al proceso principal (que en este caso ser´ıa la aplicaci´on cliente y no la aplicaci´on 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´atico.

- Pero sin duda, lo peor de todo, es que no es una alternativa portable. La aplicaci´on cliente –en el ´ambito 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´aquina 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´on 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´on de utilizar componentes, aunque muy espectacular y quiz´a recomendable para otras necesidades es –adem´as 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´on 4.4.2 en la p´agina 40 siguiendo los pasos de Pressman en [9] 28 Los archivos que maneja Excel son siempre nombrados con una extensi´on 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´on 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´e la tabla de Excel (por ejemplo ((C:\tablas\agenda.xls))).

Esta librer´ıa nos permite: Un acceso sencillo a la informaci´on.

Funciona igual en Linux y en Windows.

Es r´apido y s´olo hace falta llamarla una vez, frente a los componentes COM que necesitan utilizar el procesador y la memoria en paralelo a la aplicaci´on 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´omo resolverlo.

Partiendo de que existen estas dos maneras de interpretar la idea de la concurrencia en el nivel de la implementaci´on, esta discusi´on tiene inter´es pr´actico 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´as 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´on, de gran inter´es para los afinionados a Perl, no tiene un gran eco en la literatura. Lo m´as interesante ya se ha comentado en 5.1.1 (ver p´agina 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´on) resuelve las dudas acerca de las prestaciones entre uno y otro modo, dentro de Perl.

Lo u ´nico que se puede a˜ nadir, casi anecd´oticamente, es la introducci´on 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´en 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´afora no puede ser m´as desafortunada (o quiz´a se pens´ o as´ı a prop´osito ¿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´on 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´an r´apidos 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´on en forma de variables globales, lo cual ser´a mucho m´as f´acil 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´as que un script de Perl, esta posibilidad es poco costosa y puede valer la pena en, sin duda, con una implementaci´on basada hilos ser´a 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´asicas 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´odigo formando parte de una discusi´ on entre varias dos posibilidades, ahora se har´a, aunque no haya m´as 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´on. Lo interesante en este caso es resolver la comunicaci´on con MySQL. Para conectarse con exito a MySQL desde un script hay que tener un login y un password h´abiles en MySQL (esto es igual que si se accede por consola) y adem´as hay que conocer tres cosas, a saber: El nombre de la m´aquina donde est´a 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´on ((manual)) por ´el. Est´a 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´on y despues una prueba utilizando una funci´on (dentro del if ) que mostrar´ıa las bases de datos a las que el usuario tiene acceso.

El par´ametro host admite tanto una direcci´on de IP (147.156.16.31) como un nombre v´alido de m´aquina (slabii.uv.es).

5.2.2.

Sockets en Perl

Adem´as de probar aqu´ı las librer´ıas de sockets de Perl (cosa que no tiene m´as complicaci´on que estudiarse la documentaci´on al respecto) ser´ıa interesante resolver la cuesti´on de la conexi´on inicial cliente servidor.

El lector puede recordar (o combrobar) que en la secci´on 3.3.2 (p´agina 24) se ha caracterizado este problema y se resolvi´o –a un primer nivel– en la fase de postproceso (del dise˜ no), generando (en la p´agina 36) la tabla 4.5.

Se trata de un primer di´alogo informativo entre cliente y servidor que permita establecer una conexi´on entre ellos.

Lo que hay que resolver, concretamente, es que el servidor pueda tener permanentemente un socket a la escucha y que la negociaci´on inicial de una sesi´on entre el cliente y el servidor no limite al servidor la capacidad de atender m´as peticiones. Es una situaci´on muy habitual, as´ı que no debe ser causante de ning´ un trastorno: el servidor ofrecer´a siempre un mismo socket de n´ umero conocido, por el que entrar´an las nuevas peticiones y a las que dedicar´a s´olo unos segundos cada vez.

En Perl, una secuencia v´alida 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´on ((accept)) de Perl, es bloqueante, es decir, el servidor queda suspendido aqu´ı mientras ning´ un cliente llega. Posteriormente, a esta instrucci´on (ya ha llegado un cliente) el servidor podr´a comunicarse con aqu´el 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´on del servidor y la variable ((portsocket)) (cuyo contenido se ha copiado aqu´ı de ((port server))) se referir´a 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´as con sesgos de c´odigo, se resolvera la cuesti´on del bis a bis (comentado al principio de esta secci´on) s´olo 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´on cliente pueda tambi´en correr sobre un PDA ofrecer´a 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´on 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´olo 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´on (interfaz gr´afica) a un PDA. Allanando, de esta manera, las dudas que puedan surgir en la organizaci´on y dando una respuesta cuyo acabado satisgafa a unos y otros, y permita, a quienes tengan que tomar esta decisi´on, 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´onica.

Sin seguir apenas unos par´ametros 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´as hasta artefactos algo m´as espectaculares. A pesar de todo, el uso de estos aparatos y su comercio en general, siempre tuvo m´as pasado que futuro, pues el perfil de su destinatario estaba m´as tentado por los avances en los ordenadores personales que por las virguer´ıas de estos inventos.

El t´ermino 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´o a su ´epoca, ten´ıa un precio prohibitivo y no resolv´ıa satisfactoriamente la cuesti´on del reconocimiento de caracteres.

Cerca del a˜ no 2000 el mercado de el PDA dio un primer salto y gan´o 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´on con datos desde el PC, compatibilidad con una buena variedad de documentos inform´aticos, agenda, calculadora, reloj, notas, portapapeles, contactos, escritura, etc.

Con la llegada de las u ´ ltimas tecnolog´ıas para m´oviles y la posibilidad de incluir nuevas posibilidades a los PDAs, este invento se ha hecho muy popular. Las nuevas prestaciones (recursos inal´ambricos, autonom´ıa de la bater´ıa, resoluci´on de pantalla, audio y v´ıdeo, etc.) le han hecho al PDA tan novedoso como en su d´ıa lo fue el ordanador port´atil: bonitos, potentes, portatiles y cada vez m´as baratos. El comprador y el posible comprador acaban viendo estos inventos m´as interesantes que sus aparatosos ordenadores de sobremesa que no mueven nunca. Salvando las distancias, porque el uso del port´atil (que no es m´as 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´on cliente que se ha desarrollado conviene apuntar algunos datos m´as sobre el PDA. De entrada, aunque el nombre correcto (por lo gen´erico) es PDA quiz´a al lector le suenen m´as 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´as, 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´as acostumbrado el usuario es al entorno de Microsoft Windows, otra vez, ha ocurrido como con el PC (y como con otras marcas ocurri´o en otros productos tecnol´ogicos): 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´as amplio de los PDA que llegan al mercado su Windows CE (versi´on 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´as tiempo en el mercado y tienen muchas ventajas.

En estos t´erminos 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´as baratos dentro del mundo del PDA. + La parte cliente –y el sistema en general– est´a pensada para cargar el sistema lo menos posible. Esto da esperanzas de que pudiera desarrollarse una versi´on Palm con ´exito.

CAP´ITULO 6. TRABAJOS FUTUROS: PDA



+ Las Palm parecen ser, por el momento, m´as robustas y potentes que los Pocket PC, aunque es conocida la habilidad de Microsoft para poner parches en sus popios remiendos. Y tambi´en como la consolidaci´on del hardware acaba equiparando en ocasiones al software lento y al m´as r´apido.

Desventajas: – Supone un proceso relativamente largo, aprender a desarrollar sobre este dispositivo, redise˜ nar el sofware para las posibilidades de Palm (t´engase 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´on PC, y se perder´ıan ciertas funcionalidades por el camino.

– El proceso de mantenimiento se bifurcar´ıa y cada nueva funci´on que se quisiera a˜ nadir deber´ıa ser programada por separado en la versi´on PC y en la versi´on Palm (esta desventaja lleva a pensar que, aunque se hubiera previsto con antelaci´on 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´actico, s´olo vale la pena si se est´a dispuesto a iniciar este camino con todas sus consecuencias.

6.3.2.

Linux en PDA

Aunque parezca sorprendente –el conocido grupo nip´on– Sharp lleva m´as de un a˜ no ofreciendo una gama de PDAs que parecen poder cumplir esta misi´on.

En lo que ata˜ ne a estas p´aginas, es curioso que all´a 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´andolo textualmente: ((de alguna manera es como intentar que Perl corriera en una Game Boy (...) Perl no es un peque˜ no int´erprete, 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´on 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´olo soportan C como lenguaje de programaci´on, pero recu´erdese que –en definitiva– Perl acaba siendo en u ´ ltima instancia C. La instalaci´on de Perl en las primeras Sharp Zaurus PDA SL-5500 y SL-5600 no parece un proceso sencillo. Pero antes de profundizar en ´el y comenzar a estudiar qu´e bibliotecas de Perl soporta esta alternativa y cu´ales 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´as 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´omica conviene ver algo m´as habitual. No se ha hecho suficiente hincapi´e, 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´afica del cliente, en la secci´on 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´oxima generaci´on de Internet. ∗ Crear aplicaciones potentes de manera r´apida 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´oxima d´ecada, 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´as sofisticadas herramientas gr´aficas intentando estar presente en todas las fases de desarrollo: el editor, la herramienta de depuraci´on, una aplicaci´on gr´afica para el dise˜ no, etc. Todo org´anicamente entrelazado –en teor´ıa– para liberar al usuario de la cantidad mayor de trabajo posible. ∗ Soportar cuantas m´as posibilidades mejor. Existen paquetes –aqu´ı llamados plugins para los lenguajes m´as ((de moda))6 . Lo que han creado es el CLR7 : una especie de JAVA para cualquier lenguaje de programaci´on que las capas inferiores de Visual Studio .NET traducen. Para ello, es necesario un profundo dise˜ no por capas (puede ech´arsele 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

IO

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´ebil del dise˜ no en cuanto a lo expuesto a continuaci´on.

Microsoft .NET para dispositivos En efecto, con la aparici´on del Pocket PC, h´abil como siempre y –tambi´en como siempre– desde su posici´on 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´as avanzado reconocer´a 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´eanse cu´ales son unos y cu´ales son otros, y est´ udiese el cuadro 6.1 en comparaci´on 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

IO

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´on, esto es, una aplicaci´on puede iniciar otro dominio de aplicaci´on dentro del mismo proceso. ∗ Servicio P/Invoke (o invocaci´on de plataforma) es la tecnolog´ıa que en .NET permite usar el c´odigo en CLR para hacer llamadas a librer´ıas din´amicas DLL8 no gestionadas a priori, incluyendo el API de Win32.

Propiedades de Studio .NET que su versi´on para dispositivos no soporta: ∗ Reflection emit: Herramienta para ensamblar el c´odigo ejecutable final. ∗ Remoting (un mecanismo para invocar otras aplicaciones m´as all´a de sus respectivos dominios). ∗ Serializaci´on9 . ∗ Impresi´on. ∗ Interoperabilidad con COM. ∗ Funcionalidad del lado del servidor. ∗ XPath/XSLT10 Desde luego, es dificil comprender toda esta palabrer´ıa sin adentrarse en la pr´actica 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´on desarrollada para aplicar formato a los documentos XML de forma estandarizada, despu´es se decidi´ o ((sacar)) fuera de la especificaci´ on XSL el lenguaje de transformaci´ on y desarrollarlo como una especificaci´on ((independiente)) a la que se denomin´o XSLT. A esta nueva especificaci´on se le denomin´o XPath XPath(XML Path Language).

11 Esto puede ser una alternativa a lo discutido en la secci´on 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´on de su presentaci´ on, permitiendo modificar ambas independientemente. Es muy potente, est´a muy de moda y el lenguaje HTML tradicional para hacer p´aginas 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´aficas, multimedia, etc.

Desventajas: – Soporta una gama de dispositivos muy peque˜ na.

Adem´as, parece ser que la integraci´on de SDE en el entorno de Visual Studio .NET incorpora un emulador que incluye la funcionalidad completa de Pocket PC 2002, tambi´en incluye otras posibilidades: ∗ Compila la aplicaci´on 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´on 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´efonos m´oviles. ∗ Existe una opci´ on, en el emulador, para variar las caracter´ısticas del dispositivo (resoluci´on, color, memoria, etc).

6.4.

Conclusiones

Teniendo en cuenta que esta discusi´on no es en general –aunque tiene aspectos generales y es un problema habitual desde que apareci´o el PDA– sino que m´as bien se trata de un estudio concreto para este caso: sirva esta s´ıntesis para concentrar los puntos m´as fuertes y m´as d´ebiles de unas y otras posibilidades. Tambi´en 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´as inmediata es ponerse a redise˜ nar el c´odigo y volver a desarrollar una versi´on 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´on, se har´a por duplicado, por un lado la versi´on PC y por otro la versi´on Palm.

Tiene el aliciente de que los dispositivos son baratos y que la aplicaci´on cliente tal y como se ha creado, liberada por el servidor de la mayor parte del trabajo, no a˜ nadir´a m´as 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´on sobre PDA Se ha visto que existen unos modelos de Sharp Zaurus que soportan Linux y por lo tanto es posible instalar una versi´on de Perl. No tendr´ıa los inconvenientes citados antes pero se trata de unos dispositivos demasiado caros. Por otra parte la instalaci´on de Perl no parece f´acil, se trata de una versi´on reducida de Linux y el problema es a´ un tema de debate en ciertos foros de discusi´on.

Por u ´ ltimo se ha visto la tecnolog´ıa que Microsoft est´a 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´olo algunas adaptaciones en el peor de los casos.

El principal problema de esta posibilidad es que el software de desarrollo no est´a libre de licencias. Por otra parte la v´ıa m´as interesante dentro de .NET la representa la plataforma SDE que no est´a disponible en tantos dispositivos.

6.5.

Referencias

Se ha separado, s´olo en este cap´ıtulo, el ´ındice bibliogr´afico de la secci´on general de bibliograf´ıa en la p´agina 120. Principalmente por no sobrecargar aqu´ella y –al mismo tiempo– porque en este cap´ıtulo la bibliograf´ıa cumple otro papel.

Lo m´as llamativo de toda esta cuesti´on, es la poca cantidad de textos de caracter divulgativo que existen a´ un sobre estos artefactos. Es m´as f´acil encontrar, en algun foro, una discusi´on entre usuarios avanzados de alguna cuesti´on de u ´ ltima instancia, que un texto general acerca de el PDA. De hecho, el cap´ıtulo en s´ı, es m´as 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´on.

Realmente, http://enciclopedia.us.es es una aut´entica enciclopedia web fuertemente autorreferenciada y lo bastante actualizada en cierta terminolog´ıa tecnol´ogica sin cuya ayuda ciertos textos resultan incomprensibles o algo cojos. Por desgracia, se explaya lo justo en sus definiciones.

Lo m´as importante acerca de la famosa Sharp Zaurus puede encontrarse en la p´agina 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´on con Perl la informaci´on m´as interesante est´a 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´on m´as t´ecnica 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´ITULO 6. TRABAJOS FUTUROS: PDA se actualizan con mucha frecuencia.

Sobre la relaci´on entre .NET y Perl, la informaci´on m´as 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´on escrita por un consultor inform´atico de M´exico 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´on antedicha.

Cap´ıtulo 7 Pruebas y conclusiones El objetivo de este cap´ıtulo es probar tanto la aplicaci´on cliente que se ha desarrollado como el proceso servidor. Demostrar su funcionalidad y someter a cr´ıtica su eficiencia.

Lo m´as interesante es lo segundo, puesto que la funcionalidad no se puede trasladar al papel de una manera completamente fiel y tampoco ser´a as´ı como se eval´ ue, lo que s´ı que vale la pena hacer m´as hincapi´e es en el comportamiento y aspecto para Linux y para Windows: Recu´erdese que la portabilidad de la aplicaci´on cliente es total (tambi´en la del servidor pero ´este funciona por consola) .

Secundariamente, otro tipo de lector podr´a encontrar este cap´ıtulo como un manual para utilizar la aplicaci´on cliente.

7.1.

7.1.1.

Primeras pruebas Inicio

Al iniciar la aplicaci´on aparece un cuadro di´alogo, 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´en puede trabajarse sin conexi´on, por ejemplo, si se est´a gastando red telef´onica, 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´as tarde)) en su predecesora.

Aunque pueda parecer tonto, es recomendable avisar de estos movimientos al usuario menos instruido, y el m´as r´apido pronto se acostumbrar´a a iniciar con estos dos avisos.

En el caso de que se intente la conexi´on pero ´esta falle por alguna raz´on, la aplicaci´on 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´on 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´es y el t´ıtulo MySQL logran, secundariamente, educar al usuario en el proceso real que est´a ocurriendo cuando se conecta.

La figura 7.3 es un ejemplo de esta situaci´on, 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´on por petici´on de usuario Las razones por las que puede fallar este intento son varias, sirva de ayuda el siguiente ´arbol: 1. El usuario s´olo quiere utilizar el editor de tablas, de momento, pulsa ((m´as tarde)) y entra sin problemas a la aplicaci´on.

– Se muestra un aviso de que no hay conexi´on.

2. El usuario introduce su c´odigo y su clave.

Se equivoca.

– Aparece aviso de error.

– Entra de todas maneras como en el primer caso, s´olo 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´on sobre el servidor que tiene la aplicaci´on cliente es una direcci´on 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´on debe ser conocida (e introducida) por el usuario.

Estos valores pueden modificarse en los men´ us y tambi´en pueden guardarse. Por defecto, cuando se pulsa la opci´on 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´on busca la informaci´on al iniciar el programa.

Si no lo encuentra, est´a programado para buscar la IP 0.0.0.0 y el puerto 1080 por defecto, es decir, est´a programado para funcionar dentro del propio servidor.

En otro caso, el usuario no podr´a conectarse inmediatamente sino que tendr´a que poner valores a estos par´ametros desde los men´ us. Luego puede guardarlo para las pr´oximas 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 ´nico criterio de verdad es la pr´actica. Esta secci´on 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´on. Son, en el fondo, ciertas divergencias entre la teor´ıa y la pr´actica y/o que s´olo se pueden descubrir en un terreno de ((laboratorio virtual)). ´ Unicamente un lector m´as pr´oximo a ciertas t´ecnicas las considerar´a imprescindibles, pero desde un punto de vista menos sufrido, tambi´en pueden resultar interesantes.

Divergencias Windows-Linux No est´a en el ´ambito de una demostraci´on final pero s´ı dentro de lo que es el proceso de desarrollo y pruebas, ciertas variaciones en el comportamiento que tiene la implementaci´on dentro del entorno de Windows o dentro del entorno de Linux.

Al ser el funcionamiento de MySQL mucho m´as 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´on de Linux en un equipo mediano. De manera que –una vez hecho esto– se lleva el c´odigo 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´odigo en qu´e sistema se est´a. La propuesta que ofrece Prima y que se ha utilizado definitivamente est´a en el m´odulo Prima::Aplicaction. Lo mejor es almacenar esto en una variable diferente concebida2 como de tipo l´ogico 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´odigo de la aplicaci´on cliente se almacena –para el resto de la ejecuci´on del programa– una variable que valdr´a 1 si se est´a corriendo la aplicaci´on cliente en un sistema Unix y 0 si est´a corriendo en Windows.

Adem´as se ha hecho depender el tama˜ no y el tipo de la letra utilizada en el resto de caracteres (ventanas, cuadros de di´alogo, etc) para que est´e en sincron´ıa con los entornos de uno y otro sistema.

Partiendo de que la ayuda de la aplicaci´on –que por cierto, en sucesivas fases de mantenimiento habr´a que fortalecer– se resuelve mediante una llamada a una p´agina HTML inclu´ıda con el ejecutable (y que es un extracto de esta documentaci´on), es diferente el navegador que se utilize con Windows que en Linux. As´ı, podr´ıa hacerse, vinculando a la acci´on 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´a la informaci´on 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´on.

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´as sobrecarga de informaci´on y de mayor rapidez, la lectura era incorrecta. Hay que decir que no se ha investigado m´as all´a de lo estrictamente emp´ırico y se desconoce si este comportamiento es normal, espec´ıfico de Perl o espec´ıfico de accesos m´as r´apidos.

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´on satisfactoria. Esta no es otra que colocar una sentencia sleep detr´as de cada escritura en el socket para que el receptor no se ((aturulle)).

Lo ideal para resolverlo es permitir que desde la aplicaci´on cliente se pueda ajustar esto, bien sea porque el usuario lo introduzca manualmente o bien mediante una negociaci´on de velocidades inicial que permita averiguar al cliente y al servidor qu´e ((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´anto tarda el sistema en cargar una tabla. Por otra parte, se ha comentado en la secci´on 3.1.2 (en la p´agina 14) la singularidad que ten´ıa resolver el problema de las vistas3 de MySQL, interponiendo un proceso servidor entre ´este y la aplicaci´on cliente. Se han discutido las ventajas y desventajas desde el punto de vista del dise˜ no. Estas pruebas tienen inter´es, por lo tanto, para ver en la pr´actica cu´anto ha perturbado dicha decisi´on. 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´endice de la p´agina 118 puede encontrarse m´as informaci´on 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´on 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´enea 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´on 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´anto de lineal para tener una referencia general.

Trat´andolo como el m´as sencillo de los tradicionales problemas de m´etodos o an´alisis num´erico, puede interpolarse la funci´on que siguen estos numeros tomando el siguiente polinomio de interpolaci´on: 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´as 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´alculos se han simplificado, desde luego, entre otras cosas, por ejemplo, se ha supuesto trafico homog´eneo 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´on anterior pueden dejar algo insatisfecho al lector. En seg´ un qu´e 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´amica en la aplicaci´on cliente cuando esta se utiliza remotamente es cargar (una vez) la tabla propia con la informaci´on individual, modificar los registros que corresponda o bien a˜ nadir algunos nuevos y subir la actualizaci´on.

CAP´ITULO 7. PRUEBAS Y CONCLUSIONES



Habitualmente, cada trabajador tiene una tabla de unos cien o doscientos clientes como m´aximo, 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´as, s´olo se dar´ıa en el entorno de la oficina, es m´as, 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´on que se ha medido (cargar una tabla remotamente) no puede ser menor que de un orden lineal –excepto con t´ecnicas de cifrado m´as avanzadas que para tablas grandes tambi´en cargar´ıan al servidor–. En tanto que lineal, su crecimiento es ´ınfimo y esto es –en realidad– una muestra de que la decisi´on de enmascarar las vistas (o no vistas) de MySQL mediante un proceso intermedio no s´olo 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´engase en cuenta las siguientes conclusiones y consideraciones generales a modo de cierre: – A un nivel como el que se ha tratado, la cuesti´on 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´on. Esto anima a todos aquellos usuarios de sistemas de bases de datos que no est´en 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´en satisfechos con los entornos en los que trabajan y en especial a todos aquellos que busquen la independencia de plataforma para su c´odigo. Se trata sin duda de herramientas potentes que no fallan, est´an bien documentadas y son sencillas. Adem´as, el programador habitual de C se familiarizar´a pronto con Perl. La portabilidad de Perl, en efecto, es tan abrumadora como sus partidarios defienden.

– No se ha cerrado con rigor una secci´on dedicada a presupuestos porque no se ha considerado relevante. Lo u ´ nico que se ha gastado es la fuerza de trabajo de un s´olo ingeniero. Sopes´andolo 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´atico en tres meses. Lo realmente interesante es que se ha resuelto todo lo dem´as sin coste adicional ninguno ni en software ni en hardware. Aprovechando eso s´ı, la naturaleza acad´emica 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´atiles, 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´agina hasta la u ´ ltima de este documento, que se ha salido de una situaci´on fatalmente planteada y se han abierto varios caminos para alcanzar soluciones de mucha envergadura. Asimismo, las cuestiones m´as 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));

91

´ ´ 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;

97

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

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; +-----------------------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------------------+-------------+------+-----+---------+-------+ | Country | varchar(64) | YES | | NULL | | | Project_Name | varchar(64) | YES | | NULL | | | Description | text | YES | | NULL | | | Focal_area | text | YES | | NULL | | | Operational_programas | text | YES | | NULL | | | Type_of_project | text | YES | | NULL | | | Project_state | text | YES | | NULL | | | Start_Date | text | YES | | NULL | | | End_Date | text | YES | | NULL | | | Grant_Amount | text | YES | | NULL | | | Grant_Recipient | text | YES | | NULL | | | Grant_Recipient_Type | text | YES | | NULL | | +-----------------------+-------------+------+-----+---------+-------+ 12 rows in set (0.00 sec) mysql>

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´e 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´actico, cuarta edici´on4 .

1997, Mc Graw Hill.

[10] Alberto Domingo Ajenjo, Direcci´on y gesti´on de proyectos –Un enfoque pr´actico, Ra-Ma, 2000.

[11] Adoraci´on de Miguel Casta˜ no y Mario G. Piattini Velthis, Fundamentos y modelos de Bases de Datos, segunda ed. 1999, Ra-Ma.

4

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´agina se actualiza con frecuencia y ofrece posibilidades para otros lenguajes, a parte de cierta documentaci´on. http:// www.perl.com P´agina muy u ´ til sobre Perl, p´agina oficial. Contiene art´ıculos y enlaces de actualidad, lo mejor para estar al d´ıa. http:// www.cpan.com Desde aqu´ı no s´olo se puede descargar Perl sino tambi´en multitud de modulos, documentados y con enlaces a sus sitios web. CPAN es el Comprehensive Perl Archive Network. Tiene un caracter mucho m´as pr´oximo 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´agina del grupo O’Reilly. Se trata de una empresa de publicaciones inform´aticas que ofrece bastante calidad. La p´agina puede servir sobre todo para buscar art´ıculos, reports sobre conferencias, etc. O’Reilly se dedica tanto a la publicaci´on on line como al papel tocante http:// www.unix.org.ua P´agina sovi´etica de alguna asociaci´on Unix, quien sepa ruso podr´a averiguarlo.

Es muy recomendable porque incluye en HTML copias de algunos libros de O’Reilly. Seguramente es ilegal hacer esto porque los libros m´as 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/.

´Indice alfab´ etico C , 43 JAVA, 44 ((byte code)), 49 m´aquina virtual de, 45 Base de datos definici´on, 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´on 10g, propiedades, 7 Orientaci´on a Objetos an´alisis, 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

