uce sociedad anonima (sauce)

Proyecto final de carrera

Sistema de Base de Datoscliente-servidor con interfaz

grafica multiplataforma:

Perl

Marcelo J. Armengot [email protected]

Junio – 2004

Este esbozo sobre la trayectoria de mis estudios en el campo de la EconomıaPolıtica tiende simplemente a demostrar que mis ideas, cualquiera que sea el juicioque merezcan y por mucho que choquen con los prejuicios interesados de las clasesdominantes, son el fruto de largos anos de concienzuda investigacion. Y a la puertade la ciencia, como a la del infierno, debiera estamparse esta consigna:

Qui si convien lasciare ogni sospetto;Ogni vilta convien che qui sia morta.1

Carlos Marx

1Dejese aquı cuanto sea recelo; Matese aquı cuanto sea vileza (Dante– La divina comedia).

A mi madre, Ana Marıa.A mi padre, Eduardo.

A mi hermano, Juanfer.

Prologo

El presente documento se ofrece como la memoria de un Proyecto Final de Ca-rrera para la titulacion de Ingenierıa Informatica en la Universidad de Valencia. Esaes su principal naturaleza.No obstante, en tanto que resultado de un zigzagueante proceso que, finalmente, hadado solucion practica a un problema real, cobran importancia, otros aspectos queel lector debe tener en cuenta:Si los acontecimientos siguen un curso favorable, el sistema que aquı se describesera utilizado y mejorado en su posterioridad. Y susceptible de ser cambiado yreadaptado quien sabe cuantas veces. Pormenorizar minuciosamente cuantas masparticularidades del mismo es una responsabilidad para que pueda servir como do-cumentacion en dichas incursiones .Por otra parte, al hilo del esperable caso antedicho, no solo prever que estas notaspuedan ser vistas a posteriori como un cuaderno de bitacora sino que quienes laspuedan llegar a utilizar o incluso a leer, no tendrıan por que ser necesariamenteexpertos informaticos. Por ello, contribuir a su buen entendimiento y a su caracterdivulgativo, sera y ha sido, otra de las tareas del autor. En este sentido, el lectornotara que algunas secciones se resuelven con mas cuidado para que cualquiera lasentendiese, que no otras mas tecnicas y de antemano destinadas a la evaluacion deltrabajo.Finalmente, aunque responde a necesidades de otro calibre, y ha colaborado masde una persona, este proyecto es resultado –para bien o para mal– de un procesofundamentalmente individual. En ese sentido, en vista de que pueda ser retomadoen posteriores ocasiones, sirva tambien para recordar tanto donde se puso cada cosacomo por que se tomo cada decision. Dejar demasiada informacion a merced de unasola cabeza, de una sola memoria, no suele ser recomendable.

Marcelo Armengot IborraValencia, 8 de junio de 2004.

vii

Resumen

En el capıtulo 1o, como introduccion, se describe un problema tıpico (aunquecon una buena dosis de particularidades) de bases de datos en un caso concreto delmundo real: Un sistema centralizado de base de datos que permita accesos remotoscon una interfaz grafica y que no inponga limitaciones en cuanto al sistema opera-tivo. Lo que en realidad se necesita es un sistema de software que la organizacionpueda ir ampliando y modificando en sucesivas fases de mantenimiento, por eso –aunque el objetivo principal sea comenzar resolviendo lo inmediato– se ha decididodesarrollar por cuenta propia la parte de aplicacion .

En capıtulo 2o se propone un cambio de escala en el punto de vista trasladando, alautor y al lector, al estado del arte de las bases de datos en la actualidad. Colo-cando el espejo donde mirarse tan alto como se ha podido y, permitiendo al lectormenos proximo a estos menesteres, acercarse a las problematicas mas habituales delas bases de datos.

En el capıtulo 3o se analiza el problema descrito en el capıtulo 1o desde el punto devista de la Ingenierıa del Software. Quedan tomadas algunas decisiones y comienzaa cristalizar en planos lo que primero ha sido solo una idea. No en vano, la lecturadel capıtulo 4o no es recomendable sin comprender –cuanto menos– lo fundamentalde su predecesor. Ambos capıtulos –analisis y diseno– plasman conjuntamente eltrabajo previo que se ha preparado al desarrollo propiamente dicho. Al lector masinteresado le ha de servir para tener un modelo de representacion del proyecto y,desde ahı, tanto evaluar su bondad estructural de conjunto como aproximarse algomas en cualquier tipo de mantenimiento posterior.

El capıtulo 5o desciende hasta las contradicciones mas materiales, propias de la im-plementacion o puesta en practica. Moviendose en todo momento en el terrenode menor nivel de abstraccion, explica los problemas encontrados y las decisionestomadas para resolverlo; sirviendo, en especial a un lector menos interesado en lascuestiones teoricas, para valorar muchos aspectos practicos que son propios del ((dıaa dıa)) de la programacion en general.

Por necesidades ajenas al interes academico de este trabajo pero –paradojicamente–aumentando este, surge un nuevo frente que atender cuyo desenlace, sin ser una ne-cesidad primordial, acaba resultando de gran interes. Se trata de la aparicion estelarde un personaje de moda: los PDAs. El capıtulo 6o pretende dar una respuesta pro-visional que –discutiendo las posibilidades– pueda servir, en un futuro nada lejano,para anadir este pequeno lujo a la realidad del sistema desarrollado. Su funcion acorto plazo es que el destinatario de este sistema decida si invierte o no en avanzarmas por esta rama del camino.

ix

Finalmente, en el capıtulo 7o se ha sometido el sistema –una vez acabado– a dife-rentes pruebas con el objetivo de sacar conclusiones de caracter practico tantosobre la calidad del producto final como sobre las razones mas profundas de suspropiedades, ya sea en el ambito de las decisiones de toda ındole que se han tomadocomo en cuanto al nivel de trabajo invertido en el diseno.

x

Indice general

Prologo VII

Resumen VIII

Indice general XI

Indice de figuras XV

Indice de cuadros XVII

1. Introduccion 11.1. Descripcion de la situacion . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Propositos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Estado del arte 42.1. Introduccion: fundamentos teoricos . . . . . . . . . . . . . . . . . . . 4

2.1.1. Definicion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2. Ventajas y desventajas . . . . . . . . . . . . . . . . . . . . . . 4

2.2. Reflexion sobre la importancia de las bases de datos . . . . . . . . . . 52.3. Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4. Alternativas libres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4.1. MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.2. PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.3. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Analisis 113.1. Estudio de la viabilidad del sistema . . . . . . . . . . . . . . . . . . . 11

3.1.1. Alcance del sistema . . . . . . . . . . . . . . . . . . . . . . . . 113.1.2. Discusion de las alternativas . . . . . . . . . . . . . . . . . . . 12

Acerca de la base de datos . . . . . . . . . . . . . . . . . . . . 12Acerca del entorno . . . . . . . . . . . . . . . . . . . . . . . . 13¿Un proceso servidor como intermediario hasta MySQL? . . . 14

xi

3.1.3. Requisitos del sistema . . . . . . . . . . . . . . . . . . . . . . 153.1.4. Usuarios posibles . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.5. Identificacion de subprocesos . . . . . . . . . . . . . . . . . . . 18

Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Cliente de pruebas . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1.6. Planificacion del trabajo . . . . . . . . . . . . . . . . . . . . . 203.2. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3. Modelo del proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.1. Caso del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.2. Caso del servidor . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4. Modelo del comportamiento . . . . . . . . . . . . . . . . . . . . . . . 26

4. Diseno 284.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2. Diseno arquitectonico . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

El flujo de trasformacion . . . . . . . . . . . . . . . . . . . . . 294.2.1. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Descomposicion de primer nivel . . . . . . . . . . . . . . . . . 30Descomposicion de segundo nivel . . . . . . . . . . . . . . . . 30

4.2.2. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Descomposicion de primer nivel . . . . . . . . . . . . . . . . . 31Descomposicion de segundo nivel . . . . . . . . . . . . . . . . 32

4.3. Descripcion de modulos (postproceso) . . . . . . . . . . . . . . . . . . 334.3.1. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Limitaciones en el modelo del cliente . . . . . . . . . . . . . . 354.3.2. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Limitaciones en el modelo del servidor . . . . . . . . . . . . . 374.4. Diseno de la interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.1. Notas previas . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.4.2. Interfaz hombre-maquina . . . . . . . . . . . . . . . . . . . . . 40

5. Implementacion 425.1. Decisiones previas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1.1. El lenguaje de programacion . . . . . . . . . . . . . . . . . . . 42Alternativas independientes de la plataforma . . . . . . . . . . 43¿Por que no JAVA? . . . . . . . . . . . . . . . . . . . . . . . . 44¿Por que no Perl? . . . . . . . . . . . . . . . . . . . . . . . . . 48La decision final . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.2. Cliente Perl en entorno de ventanas . . . . . . . . . . . . . . . 52Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Estructura de datos de la tabla . . . . . . . . . . . . . . . . . 54

xii

5.1.3. Compatibilidad Ms-Excel . . . . . . . . . . . . . . . . . . . . . 55Componentes de Miscrosoft . . . . . . . . . . . . . . . . . . . 56

Acceso a archivos *.xls . . . . . . . . . . . . . . . . . . . . . . 57

5.1.4. Concurrencia: ¿Hilos o procesos? . . . . . . . . . . . . . . . . 58Hilos y/o procesos en Perl . . . . . . . . . . . . . . . . . . . . 59

Por que usar hilos . . . . . . . . . . . . . . . . . . . . . . . . . 595.2. Pruebas previas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.2.1. Acceso a Bases de Datos con Perl . . . . . . . . . . . . . . . . 605.2.2. Sockets en Perl . . . . . . . . . . . . . . . . . . . . . . . . . . 61

6. Trabajos futuros: PDA 64

6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646.2. Historia reciente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.3. Posibles soluciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.3.1. Palm Pilot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6.3.2. Linux en PDA . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.3.3. Pocket PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Preambulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Microsoft .NET para dispositivos . . . . . . . . . . . . . . . . 70

SDE y MIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.5. Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7. Pruebas y conclusiones 787.1. Primeras pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.1.1. Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.1.2. Informacion en el cliente sobre el servidor . . . . . . . . . . . 807.1.3. El editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7.1.4. Reajustes en el codigo . . . . . . . . . . . . . . . . . . . . . . 81Divergencias Windows-Linux . . . . . . . . . . . . . . . . . . . 82

El dilema del socket . . . . . . . . . . . . . . . . . . . . . . . 847.2. Velocidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.2.1. Medicion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 847.2.2. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.2.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.3. Valoracion final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

El codigo del servidor 91

El codigo del cliente 97

Tabla de pruebas 118

xiii

Bibliografıa 120

Referencias web 121

Indice alfabetico 123

xiv

Indice de figuras

1.1. Croquis de la situacion . . . . . . . . . . . . . . . . . . . . . . . . . . 2

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

3.1. Descomposicion funcional del problema . . . . . . . . . . . . . . . . . 123.2. Emplazamiento de los elementos principales . . . . . . . . . . . . . . 163.3. DCA cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.4. Posibles casos de uso del sistema . . . . . . . . . . . . . . . . . . . . 183.5. Diagrama de hitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.6. Diagramas entidad relacion: entidad suscriptor x zoom . . . . . . . . 213.7. Diagramas entidad relacion: sobre los informes . . . . . . . . . . . . . 223.8. DFD0 cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.9. DFD1 cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.10. DFD0 servidor – primera vista . . . . . . . . . . . . . . . . . . . . . . 243.11. DFD0 servidor (un cliente) . . . . . . . . . . . . . . . . . . . . . . . . 253.12. DFD0 - concurrencia en el servidor . . . . . . . . . . . . . . . . . . . 253.13. DFD1 - principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.14. DFD1 - concurrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.1. DFD1 cliente – refinado . . . . . . . . . . . . . . . . . . . . . . . . . 314.2. Estructura del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3. Estructura del servidor, proceso principal . . . . . . . . . . . . . . . . 324.4. Estructura del servidor, proceso concurrente . . . . . . . . . . . . . . 33

5.1. Benchmark C++ versus JAVA . . . . . . . . . . . . . . . . . . . . . . 465.2. La arquitectura de Perl . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.1. Mobile Internet Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2. Smart Device Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 73

7.1. Peticion de login y password . . . . . . . . . . . . . . . . . . . . . . . 797.2. Inicio sin conexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 797.3. Inicio sin conexion anomalo . . . . . . . . . . . . . . . . . . . . . . . 807.4. Menu de conexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

xv

7.5. Aspecto del editor para tablas . . . . . . . . . . . . . . . . . . . . . . 827.6. Evolucion: tiempos/tabla . . . . . . . . . . . . . . . . . . . . . . . . . 86

xvi

Indice de cuadros

4.1. Descripcion modulo: Grabar tabla localmente. . . . . . . . . . . . . . 344.2. Descripcion modulo: Entrar datos a la tabla. . . . . . . . . . . . . . . 344.3. Descripcion modulo: mostrar la tabla. . . . . . . . . . . . . . . . . . . 354.4. Descripcion modulo: valores de la conexion. . . . . . . . . . . . . . . 354.5. Descripcion modulo: conexion inicial. . . . . . . . . . . . . . . . . . . 364.6. Descripcion modulo: envıo de sentencias SQL. . . . . . . . . . . . . . 364.7. Descripcion modulo: generar proceso concurrente. . . . . . . . . . . . 374.8. Descripcion modulo: conexion inicial con la base de datos. . . . . . . 374.9. Descripcion modulo: escucha de peticiones del cliente (primer bis a

bis cliente-servidor). . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.10. Descripcion modulo: escucha de consultas en el servidor. . . . . . . . 384.11. Descripcion modulo: gestion de consultas del servidor. . . . . . . . . . 39

5.1. Benchmark C++ versus JAVA: tabla de tiempos . . . . . . . . . . . . 47

6.1. .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.2. .NET Compact Framework . . . . . . . . . . . . . . . . . . . . . . . . 706.3. Sıntesis del estudio y discusion sobre PDA . . . . . . . . . . . . . . . 75

7.1. Esquema del interfaz grafico: parte cliente . . . . . . . . . . . . . . . 817.2. Resumen de la tabla de pruebas . . . . . . . . . . . . . . . . . . . . . 857.3. Medicion de velocidades . . . . . . . . . . . . . . . . . . . . . . . . . 877.4. Velocidades segun accesos . . . . . . . . . . . . . . . . . . . . . . . . 88

xvii

Capıtulo 1

Introduccion

1.1. Descripcion de la situacion

Una pequena empresa, la Editorial Sauce, gestiona desde hace anos la edicion yenvıo por suscripcion de varias publicaciones ofertadas por el Ateneo Madrid XXI yotras empresas de holding relacionadas con este.Actualmente esta editorial tiene repartidos por la penınsula unos cincuenta tra-bajadores comerciales encargados de la difusion y suscripcion mensual de todassus publicaciones. Estos comerciales, recaban semanalmente informacion de nuevosclientes o suscritos y de nuevos posibles clientes.En la Oficina Central, ubicada en Valencia, ademas de cotejarse la contabilidad yhacerse otras tareas de gestion, se trabaja con una base de datos que actualmentetiene unos 7000 registros correspondientes a los suscriptores de las distintas publica-ciones. Se procuran los envıos y se gestionan las nominas de los empleados, ası comotoda la informacion correspondiente a los mismos. Se actualizan las nuevas entradasy se comprueba toda la informacion entrante. La base de datos crece inexorable-mente.Debido a la inexistencia de un departamento informatico, a la imprevision de susgestores y al exponencial desarrollo de los nuevos proyectos: la administracion cen-tralizada de todo este operativo viene siendo desde hace tiempo, lenta y poco reso-lutiva.Los comerciales envıan la informacion semanalmente de muy diferentes maneras,habitualmente tablas en un correo electronico pero a veces hasta se envıan manus-critos por fax. La informacion es reentrada manualmente a la base de datos central,como mucho importando las tablas originales, tanto para comprobar las posiblesduplicaciones como la normalidad de los datos.Cada mes se actualiza una tabla con los suscritos activos y se envia su listado dedirecciones postales en un informe, a una empresa llamada Grupo Meydis, que entreotros servicios tiene una oferta para envıos por correo. La informacion es tratada

1

CAPITULO 1. INTRODUCCION

actualmente sobre Access de MicroSoft y se gestiona a nivel local en la propia ofici-na.Los responsables de todo este sistema son conscientes del nivel de inoperatividaddel mismo, su falta de privacidad y la cantidad de limitaciones que tiene. Estandispuestos a mejorarlo pero no pueden dedicar a ello una parte del tiempo de losempleados de la Oficina Central, no estan seguros de hacer una inversion en softwareni en hardware y mientras tanto, la eficacia aparente del sistema actual se convierteen una tendencia al conservadurismo.En este primer nivel de descripcion la figura 1.1 describe la situacion en el terrenoestrictamente fısico. En pocas palabras: Un sistema de suscripcion centralizado poruna base de datos y llevado adelante por un equipo de comerciales operativo portodo el paıs que se mueve en funcion de objetivos y estudios de mercado, por lo quesus accesos a la base de datos son siempre imprescindibles pero impredecibles.

Host local 1 Host local n Host local 2

Base de datos

CIUDAD 1

(VALENCIA)

Uso información

remoto

Host remoto 1

Oficina

Central

CIUDAD 2

Trabajo con la

información,

local

Ciudad 3

Hos remoto 2

Host con BD

Figura 1.1: Croquis de la situacion

1.2. Propositos del proyecto

Es evidente que desde un punto de vista de ingenierıa, son muchas y muy suscu-lentas las posibles soluciones que pueden darsele a esta situacion. Tras una primeraentrevista, algunas necesidades se apuntan como principales.

CAPITULO 1. INTRODUCCION

+ Todos los actuales trabajadores, tanto gestores como comerciales deben poderusar la base de datos esten donde esten.

+ Para ello hace falta una aplicacion que pueda funcionar como cliente y queno este cerrada, es decir, susceptible de ser ampliada en posteriores fases demantenimiento. Que sea facil de usar y compatible con el entorno de MicrosoftOffice con el que actualmente trabaja la plantilla de empleados.

+ Renovar la seguridad del sistema, consiguiendo que cada usuario de la infor-macion tenga acceso solo a lo que necesita.

+ Muy importante, el sistema debe ser rapido y debe poder generar informes acerca de la base de datos de manera inmediata.

+ Por ultimo, pero no menos importante, la solucion debe ser lo mas barataposible.

1.3. Objetivos del proyecto

Atendiendo al orden cronologico que requieren estos propositos y estudiandolosmas pormenorizadamente, se entiende que:

+ Se necesita migrar tanto el hardware como el software portador de la Base deDatos a un sistema mucho mas seguro, mas rapido, mas potente.

+ Debe ponerse en marcha, para almacenar la base de datos y gestionar losaccesos remotos de los clientes, un servidor que proporcione robustez, seguridady pueda funcionar de manera indefinida.

+ La informacion actual es valida 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 instalacion o esta sea facilmentereversible. Que convierta cualquier PC en una pequena pero eficienteterminal remota de la base de datos.

- Hay que programarlo y documentarlo para poder ampliar sus funciona-lidades en el futuro. En el futuro se preve que la version del cliente conla que se trabaje localmente en la Oficina Central, incluya la parte decontabilidad y accesos bancarios que actualmente se delegan en otro de-partamento.

+ Hay que probar el trabajo localmente y remotamente. Contrastarlo con otrassoluciones y justificar la necesidad de su implante.

Capıtulo 2

Estado del arte

Algunas secciones de este capıtulo (como la introduccion) y algunas anotaciones estanespecialmente dedicadas al lector mas profano, en otro caso puede servir para repasaralgunos terminos o (como en este caso) ajustar un punto de partida en lugar de darlo todopor supuesto.

2.1. Introduccion: fundamentos teoricos

2.1.1. Definicion

Como ((base de datos)) puede aceptarse la siguiente definicion1:

((Coleccion o deposito de datos integrados, almacenados en soporte secundario (novolatil) y con redundancia controlada. Los datos, que han de ser compartidos pordiferentes usuarios o aplicaciones, deben mantenerse independientes de ellos, y sudefinicion (estructura de la base de datos) unica y almacenada junto con los datos, seha de apoyar en un modelo de datos, el cual ha de permitir captar las interrelacionesy restricciones existentes en el mundo real. Los procedimientos de actualizacion yrecuperacion, comunes y bien determinados, facilitaran la seguridad del conjunto delos datos)).

2.1.2. Ventajas y desventajas

Entendiendo que antes de aparecer el concepto de base de datos ya existıa la tecno-logıa informatica y la informacion, y la necesidad de utilizar la primera para manejar lasegunda, puede imaginarse que las soluciones anteriores pasaban por ((sistemas orientadosal proceso, debido a que en ellos se pone el enfasis en los tratamientos que reciben los da-tos, los cuales se almacenan en ficheros disenados para una determinada aplicacion. Lasaplicaciones se analizan e implantan con entera independencia una de otras, y los datosno se suelen trasferir entre ellas, sino que se duplican siempre que los correspondientes

1Esta seccion (2.1.1 y 2.1.2) esta tomada de [11].

4

CAPITULO 2. ESTADO DEL ARTE

trabajos los necesitan)).Implantar una base de datos en un sistema, frente al uso de ficheros clasicos, tiene ventajasy desventajas, tenganse 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 realentre los datos, tiene mas informacion que la suma individual de los datos porseparado).

+ Mejor y mas normalizada documentacion de la informacion, la cual esta integradacon los datos.

+ Mayor eficiencia en la recogida, validacion e introduccion de los datos en el sistema.

+ Reduccion del espacio de almacenamiento.

Desventajas:

– Instalacion costosa.

– Personal especializado.

– Implantacion larga y difıcil.

– Falta de rentabilidad a corto plazo.

– Escasa estandarizacion (la tendencia de esta desventaja es a ser cada vez menor).

– Desfase entre teorıa y practica. Esto no tiene que ocurrir necesariamente, se refierea un desfase entre la concepcion teorica, de lo que es la base de datos, que puedenlos directivos con respecto a lo que ofrece la tecnologıa realmente.

2.2. Reflexion sobre la importancia de las bases

de datos

((Al Qaeda es una especie de multinacional de prestacion de servicios y preparacionlogıstica para el terrorismo internacional. Tiene campamentos, armamento, preparahombres, combatientes, francotiradores, capta posibles martires. Al Qaeda no es unpartido, no es en sı mismo una organizacion islamica. A Al Qaeda se vinculan muydistintas organizaciones como la Yihad, los salafistas, los Hermanos Musulmanes deEgipto, una rama que es directamente la de Atta y la del numero dos de Bin Laden.Tengo la conviccion de que Al Qaeda va mas alla que Bin laden, es la Umma, la


patria islamica. Ojo aquı que no es un Estado. El ideal es extender el verde del Islamdesde Cordoba a Manila, donde estuvo, pero no de recuperacion de terrenos sino deuna moral fundamentalista.))

((En este libro, vereis que hay una cita donde aparece el listado de las organizacio-nes beneficas que directamente estan sufragando los campos de entrenamiento de AlQaeda. Hay constancia de esto en diligencias judiciales. Y de ellas, algunas estanpresididas por el ministro de Defensa de Arabia Saudı, otra por el padre del emba-jador en EEUU, que daba talones a terroristas, a hombres de Al Qaeda que eran dela celula de Atta. Eso esta ahı con numero de transferencias y cantidades. ArabiaSaudita ha financiado directamente a varios de los pilotos que perpetraron el 11 deseptiembre)).

Con estas palabras –la conocida periodista de investigacion y autora de varios libros– PilarUrbano, dejaba perplejo a todo el aforo en la presentacion de su libro ((Jefe Atta)).Es del dominio publico que ((Al Qaeda)) significa ((base de datos)). Un documento acerca delestado del arte de las bases de datos esta en un terreno diferente del analisis que mereceeste tema, pero lo que se intenta introducir con esta pequena presentacion es que en laactualidad, la tecnologıa que maneja la informacion es un arma de un calibre inpensable,todo lo relacionado con ello merece un cuidado exquisito y es la piedra angular de cualquierorganizacion ya sea social, empresarial, estatal, militar, administrativa o tambien popular.

Las principales multinacionales han promovido el desarrollo de esta tecnologıa y la hanhecho avanzar hasta llegar a una potencia de calculo y de consulta impensable hace cienanos. Ellos pueden utilizarlo para sus fines. Los estudiantes, ingenieros y profesionales dela informatica en general, deben aprender a esgrimir este arma y tienen la responsabilidadde denunciar cualquier tipo de uso anomalo que se le pretenda dar.

2.3. Oracle R©

En junio de 2004 la consultora estadounidense IDC emitio un informe2 acerca del por-centaje de mercado de los principales sistemas de base de datos. El gigante Oracle, siguesiendo el lider en sistemas de bases de datos (los resultados de este estudio pueden versesintetizados en la figura3 2.1 ). Y hay que tener en cuenta que aunque haya otros sistemasque le hagan sombra, las principales empresas utilizan Oracle.Desde hace casi treinta anos, Oracle viene desarrollando los productos mas competitivosen el mercado de la base de datos, desde su posicion dirigente, ha ido obligando a todoslos desarrolladores de bases de datos a cumplir una serie de criterios. La siguiente enume-racion4 recoge las veinte propiedades mas avanzadas de la version Oracle 10g. Sirva para

2Puede visitarse en http://www.idc.com.3Se ha incluıdo MySQL aunque sea gratuita para poder comparar su uso con respecto a las

demas.4Tomada del artıculo ((Oracle Database 10g: The Top 20 Features for DBAs)) pu-

blicado por Arup Nanda en la revista Oracle Magazine’s 2003. Puede visitarse enhttp://otn.oracle.com/pub/articles.


Figura 2.1: Reparto de mercado de las principales bases de datos

tener una concepcion de lo que necesitan las ultimas aplicaciones practicas en el mercado.Se debe entender como los ultimos retos a los que las bases de datos se ven desafiadas porsus usuarios, y desde ahı, tomar conciencia del terreno en el que se mueven hoy dıa lossitemas de bases de datos:

1. Tienes una pelıcula, no una fotografıa. Una base de datos debe mostrar lainformacion en relacion a la actualidad, partiendo de que puede ser consultada pormuchos usuarios y modificada simultaneamente.

2. ¿Queda mucho? Cuando se monitoriza un rollback5 amenudo los usuarios pre-guntan al administrador esto, estimar dicha operacion con el maximo de precisiones el servicio que la base de datos debe proporcionar.

3. Mejorar la gestion del espacio de tabla. Se refiere a las restricciones a la horade crear tablas, los usuarios no pueden utilizar espacio de disco que corresponde alsistema o a otros usuarios.

4. Potencia de exportacion de datos. La base de datos frecuentemente requiereexportar datos, el objetivo es alcanzar la maxima potencia. Cuanto mayor tamanode tabla en menos tiempo se pueda emitir, mejor.

5. Tabla de flashback. O tabla de recuperacion, para borrados accidentales y otrotipo de perdidas de informacion.

6. Almacen automatico del trabajo acumulado. Se trata –cuando ocurre algunproblema– 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 relacion entre dos problemas?

5Un rollback es la operacion de vuelta atras que se hace en una base de datos cuando unatransaccion ha quedado interrumpida. Se vuelve a un punto anterior donde los datos mantienen laconsistencia (por ejemplo es trasferencias bancarias, el dinero puede estar en una cuenta emisorao en la receptora pero no en ambas a la vez o en ninguna).


7. Soporte para SQL*Plus 10.1.0.2 Aunque SQL6 es un estandar y nacio en losanos 70 en los laboratorios de IBM, hoy dıa, en ciertos ambitos es SQL*Plus quienmarca el rumbo (o mas marca el rumbo) de lo que debe ser SQL. Sus nuevas con-tribuciones representan un modelo de interprete de SQL para cualesquiera sistemasde base de datos, Oracle, por supuesto predica con el ejemplo.

8. Gestion automatica del almacenamiento. En cuanto al manejo fısico de losdiscos, la base de datos debe ser la que automaticamente lo gestione optimizandolas posibilidades.

9. RMAN Un sistema automatico7 para crear y disponer del back up de la base dedatos.

10. La auditorıa te lo dice todo. Un sistema detallado para saber de manera por-menorizada no solo que usuario actua sobre la base de datos sino que hace.

11. Interfaz de espera. De cara a las consultas que tardan en resolverse (desquiciandoa los usuarios), este interfaz detalla el proceso para que se sepa en cada momentoque queda, que se esta esperando, cuanto va a tardar.

12. Vistas materializadas. Una gestion sofisticada del resultado de una consulta,que se puede concebir como un fotograma en la memoria y que se emite al usuariocuando vuelve a hacer la misma consulta, teniendo cierto nivel de modificacion si laconsulta varıa.

13. Enterprise Manager.8 La base de datos debe ofrecer al administrador un interfazpara gestionar la base de datos, potente, sencillo de usar, etc.

14. Base de datos privada virtual. La base de datos incorpora un sistema de nivelsuperior al usuario que le introduce una consulta, anadiendole a esta lo que hagafalta para introducir distintos tipos de dispositivos de seguridad. Con este sistema,por ejemplo, se pueden emular vistas9.

15. Gestion de segmentos. Gestion del almacenamiento eficientemente: compactandolos objetos, aprovechando el espacio en desuso, etc.

16. Espacio de tablas trasportables. Los espacios de tablas, deben ser trasportablesa traves de plataformas, haciendo que la publicacion de datos sea cuanto mas facily mas rapido.

6SQL es un lenguaje estandarizado para hacer consultas a bases de datos y gestionarlas (Struc-tured Query Language).

7RMAN es el Recovery Manager o gestor de recuperaciones.8La traduccion serıa gestor de la empresa, o gestor para la empresa. Se ha dejado en ingles

porque quienes conozcan algo (o mucho) a Oracle no lo llamaran de otra manera.9Supongase que el usuario ((Carlos)), con permiso para ver solo sus registros pretende hacer un

listado de la tabla total, este sistema le anade a su consulta una condicion mas, de manera quesolo reciba aquellos registros en los que ((Usuario)) sea igual a ((Carlos)).


17. Gestion automatica de memoria compartida. Gestiona y localiza memoriadonde mas falta hace. No pueden producirse errores de falta de memoria por unproblema de gestion.

18. Monitor automatico de diagnostico. Debe imaginarse como un robotico admi-nistrador de la base de datos que (aunque con limitaciones) ayude al administrador(humano) de la base de datos en determinados problemas. Trabaja en connivenciacon un notificador de ajustes de SQL.

19. Scheduler10. Un sistema que automatice la creacion y almacenamiento de traba-jos (o sesiones) de la gestion de la base de datos para automatizar ciertas tareasrutinarias.

20. La guinda del pastel. Colecciones de estadısticas, retencion garantizada de datospara ((deshacer)) determinadas acciones, operaciones de cifrado mas faciles y masseguras.

2.4. Alternativas libres

Afortunadamente, ademas de pagar a Oracle por sus servicios, existen otras posibilida-des interesantes. El mundo de la Open Source tiene brillantes soluciones que, en ocasiones,pueden salir mas rentables. Es dificil encontrar documentacion (imparcial) como para pro-fundizar lo debido en todas (PostgreSQL11, MySQL12, Firebird13, MaxDB14, etc) pero valela pena echar un vistazo a las dos mas conocidas15.

2.4.1. MySQL

Sus principales propiedades son:

∗ Fue disenado para proporcionar buena velocidad.

∗ Consume pocos recursos.

∗ Ventajas:

+ Buen rendimiento, buena velocidad a la hora de conectar con el servidor y derespuesta a consultas.

+ Registros sin lımite de tamano.

10((Scheduler)), algo ası como planificador, en espanol.

11http://www.postgresql.org12http://www.mysql.org13http://firebird.sourceforge.net14http://www.mysql.com/products/maxdb/15Esta comparacion 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 deInnovacion Informatica puede visitarse en http://www.mmlabx.ua.es.


+ Control de acceso: que usuarios tienen acceso a que tablas y con que permisos.

+ Buena reaccion 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 laaltura de Oracle, Sybase, etc.

∗ Ventajas:

+ Buena escalabilidad. Debido a su diseno, conforme se aumenta el numero deprocesadores aumenta el rendimiento.

+ Soporta un subconjunto del estandar SQL mayor que el de MySQL y tienepropiedades de orientacion a objetos.

∗ Desventajas:

– Es entre dos y tres veces mas lento que MySQL.

– Sobrecarga el sistema bastante mas que MySQL.

2.4.3. Comparativa

Aunque esta comparacion esta algo anticuada (de hecho, no se han anadido ciertascaracterısticas por no estar referidas a las versiones actuales de uno y de otro), pareceevidente que PostgreeSQL persigue un modelo mas ambicioso que MySQL. No obstante,para un sistema de caracter domestico o similares, parece bastante mas recomendableMySQL que es mas rapido y consume menos recursos. Por otra parte no debe olvidarse lafigura 2.1 y el estudio del que se ha extraıdo: MySQL es mas utilizada que PostgreSQL.Por ultimo, es interesante saber que aunque ambas son de libre distribucion y codigoabierto, mientras que MySQL esta firmada con una licencia GPL (lo cual obliga al que lautilizare a liberar tambien su codigo y firmar con GPL), PostgreSQL no tiene copyleft ypor lo tanto deja a sus usuarios ((libertad)) total16.

16La autentica libertad es la que propone la filosofia de la GPL, si en PostgreSQL no son tanradicales quiza es porque no pueden permıtirselo o no les interesa.

Capıtulo 3

Analisis

Este capıtulo recoge la primera aproximacion al problema desde un punto de vistade Ingenierıa del Software. No da respuestas para todas las preguntas pero sı a algunasimportantes. Se apoya en ciertas figuras que tienen el principal objetivo de facilitar lacomprension del problema tanto para el que va a enfrentarse a el como para cualquier tipode lector.Conviene decir, en ese sentido, que se ha postergado por el momento el dilema de sisera necesaria la Orientacion a Objetos a la hora de afrontar la construccion de estesistema de software, hasta tener un nivel de comprension mayor sobre lo que se va ahacer.De todas maneras el lector menos profano puede reconocer algunos diagramas propiosdel modelado en dicha disciplina, pues se ha cotejado distintas fuentes para resolver estecapıtulo con el interes principal de completar:

((Algo que ayude a hacer una particion de los requisitos y a documentar esas divi-siones antes de especificar . . . ))

((Algun metodo de seguimiento y evaluacion de interfaces))

((Herramientas para describir la logica y la tactica, algo mejores que descripcionesnarrativas . . . ))

Entendiendo que son tres mınimos1 objetivos que debe cubrir una fase de analisis.

3.1. Estudio de la viabilidad del sistema

3.1.1. Alcance del sistema

Es absurdo hacer ningun estudio sobre la distribucion organizativa del equipo porqueeste se reduce a un solo responsable. Sin embargo, para atacar lo que se va a hacer, esimportante estudiar la descomposicion funcional del sistema descrito.Existen varios campos involucrados en el sistema resultante. Para vislumbrar las posibles

1Extracto de discusion en [9] citando a DeMarco.

11

CAPITULO 3. ANALISIS

soluciones y discutir las alternativas, sirva la figura 3.1 como diagrama de referencia. Enella, aparece desglosado lo que se debe empezar a diferenciar. Por un lado lo referente a lossitemas de la base de datos, los equipos que trabajen en la Oficina y lo que en ese sentidose anada. Por otra parte la aplicacion cliente, que aunque puede ser usada tambien en lamisma Oficina Central, debe estar preparada segun las condiciones que se han puesto.

Solución Nueva

Aplicación cliente

Plataforma, sistema seguro

Servidor (host)

Base de datos Proceso servidor?

Comunicación

servidor

Interfaz

gráfica

Compatible

MS-Office

Migración datos

actuales Puesta a punto

Figura 3.1: Descomposicion funcional del problema

3.1.2. Discusion de las alternativas

Acerca de la base de datos

Lo primero a descartar en este apartado es la posibilidad de desarrollar un sistemade base de datos propio. Serıa dedicarle una parte del tiempo y arriesgarse teniendo encuenta que hay muchas soluciones disponibles actualmente. Y no hay ninguna ventaja enimplementarla por cuenta propia.Partiendo de que el presupuesto economico es una clave en cada parte de este desarrollo,dentro del mundo de las bases de datos, se ha visto en la seccion 2.4 las posibilidades.Por las caracterısticas del sistema descrito parece mas adecuada MySQL (mas rapida,que consuma menos recursos). Se trata de una base de datos potente, puede descargarsegratuitamente desde http://www.mysql.com y esta comunmente comprobada.Conviene decir aquı, que aunque pueda parecer una manıa de gurus del GPL2 o masbien una sensacion subjetiva por todo lo que esta desarrollado siguiendo esta orientacion,

2Licencia Publica del proyecto GNU.


MySQL es realmente una solucion seria:Tengase en cuenta, que por ejemplo, hace mas de un ano, la empresa Ziff Davis Media Inc.publicaba un artıculo en http://www.eweek.com donde en distintos benchmarks3 aparecıaMySQL tuteandose con otras bases de datos de tipo comercial: DB2 7.2, MS SQL Server2000, 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ıade los grandes servidores de empresas, o de Internet: se trata de un Hewlett-Packard Net-Server LT 6000r con cuatro procesadores Xeon a 700MHz, 2GB de memoria RAM y 24discos Ultra3 SCSI a 10,000 RPM de 9.1GB.))Aunque se trate de solo un tipo de prueba donde por ejemplo las medidas se habıan((ejecutado bajo la plataforma Windows 2000, los resultados son de gran ayuda orientati-va para prever como responderıan estos sistemas bajo Linux)) y deben tomarse en cuentacomo referencia objetiva sobre MySQL.Las pruebas consistıan en una simulacion de ((varios cientos de usuarios navegando di-multaneamente por un portal dinamico de Internet que se apoya en una base de datos, quees la que precisamente se esta estudiando.))Y las conclusiones apuntaban a que quien estuviera planificando adquirir una licenciacomercial de Oracle debıa pensarselo dos veces y estudiar detenidamente el estudio reali-zado4

Ademas MySQL:

∗ Tiene APIs5 para distintos lenguajes de programacion: 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 contrasenas y usuarios.

∗ Maneja grandes bases de datos.

∗ ODBC (Open Database Connectivity) soporta conexion con Win32.

MySQL tiene muchas otras prestaciones, que la hacen ser una competitiva solucion parabase de datos 6.

Acerca del entorno

Sobre la aplicacion cliente no cabe ninguna duda porque esta implıcito en los requisitosiniciales, debe correr en cualquier plataforma ya que no es predecible el sistema que ma-nejen los usuariso finales. Con respecto al entorno en la Oficina Central hay basicamente

3Termino sajon para referirse a los procesos y programas que aplican pruebas comparativastanto absolutas como relativas a un sistema de hardware o de software.

4Mas informacion en http://linux.bankhacker.com/software/Benchmarks+de+MySQL/ y enhttp://www.eweek.com.

5API (Application Programming Interface): Interfaz de programacion para aplicaciones.6Mas informacion en el manual de referencia de MySQL [6].


dos aspectos, que invitan a decidir casi de manera inmediata que conviene migrar a unsistema de tipo Unix como Linux. Por orden de importancia:

+ En este problema, la seguridad y privacidad de la informacion es de caracter pri-mordial.

+ Debe ponerse en marcha un servidor robusto, que funcione indefinidamentey queacepte multiples accesos. Aunque en esto Linux no tiene la exclusividad7, es lasolucion mas asequible a las posibilidades actuales.

En definitiva, un sistema software donde la aplicacion cliente sea la misma para dentroque para fuera de la oficina (donde los equipos con Linux van a abundar) y donde laaplicacion servidor pueda correr en Windows por lo que pueda decidirse en el futuro peroeste adaptada a la optimizacion que le extraiga Unix.

¿Un proceso servidor como intermediario hasta MySQL?

Llegados a este punto, aunque aun no esta abordado el problema de la puesta en mar-cha de la base de datos, entre algunas preguntas que aparecıan confusas cristalizan ciertasrazones que invitan a desarrollar un programa servidor que se comunique directamentecon MySQL y al que pueda acceder el cliente.En principio esto no deberıa hacer falta porque las librerıas para acceder a MySQL per-miten programar una aplicacion cliente que se conecte directamente con nuestra base dedatos de manera remota. Crear un intermediario para este dialogo parece innecesario fun-cionalmente y completamente prescindible a nivel academico. Es como contratar a untraductor para que se entiendan dos personas que hablan el mismo idioma.Las desventajas son evidentes, discutanse las ventajas:

+ La principal razon para tomar esta decision aparentemente tan singular es que,desgraciadamente, MySQL no soporta vistas (view). Uno de los requisitos explıcitosde todo el sistema es que cada usuario puede ver solo un sesgo (su sesgo) de la tabla.Con un campo anadido a las tablas correspondientes (del dueno de la informacion) sepuede enmascarar este problema y hacer que nunca llegue hasta un cliente remotola informacion no deseada. Dividir la tabla en pequenas tablas es una solucion adescartar porque hace que el numero de tablas incremente sin parar con la llegadade 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 este usandoMySQL u otra base de datos. Se podrıa cambiar de base de datos a voluntad,mientras la comunicacion entre el servidor y el cliente siga igual. Los clientes seguiranfuncionando y sus usuarios no tienen ni por que saberlo.

+ El cliente queda liberado de cierta carga, esta es una buena ventaja, y esta relaciona-da con lo mencionado en 1.3 en la pagina 3. Recuerdese: una aplicacion cliente todo

7Se podrıa discutir, por ejemplo, acerca de ciertas instalacioens de Windows NT o de equiposMac.


terreno capaz de convertir cualquier ordenador en una puerta hacia la seguridad delsistema central, incluso si este es un equipo limitado.

+ Se puede (y segun el primer punto, se debe) configurar MySQL para que solo admitaaccesos locales, desde el mismo host o desde un host conocido. De manera que alprograma servidor que debe crearse, se le pueden dar, en un futuro, facultadespropias de cortafuegos e incrementar la seguridad. Con todo ello, disponer a lamaquina donde corra el proceso servidor, como lo que en cierta literatura se conocecon el nombre de ((bastion host)) o bien disponer de este y a otro nivel de la red localun 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 an-teriores y poder mejorarlas en el futuro. A corto plazo es una decision que tiene variosinconvenientes:

- Complejiza el problema, lo peor que tiene, sin duda.

- Tiempo de programacion que podrıa dedicarse en otra tarea. Tengase en cuenta quese 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 segu-ridad. Aunque se apunte esto como una desventaja hay que recordar que es muchomejor que recaiga en el servidor que en el cliente, ya que hay que partir de que elprimero esta bajo control mientras que el segundo podrıa ser imitado en cualquiertipo de ataque al sistema simplemente utilizando esta documentacion.

Tomando pues la decision de desarrollar este programa servidor8 tomese como referenciala figura 3.2 que, como diagrama de emplazamiento, sirve para comprender a partir deahora la relacion entre los distintos elementos que se van a manejar.

3.1.3. Recapitulacion de requisitos

El capıtulo primero esta escrito con un conocimiento parcial de la solucion. A medidaque el estudio de la misma avanza, la respuesta es mas completa, mas multilateral. Eshora de aclarar al lector sobre lo que se va a hacer:

1. Desarrollar un programa cliente:

+ Con entorno grafico 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:

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


Figura 3.2: Emplazamiento de los elementos principales

+ Acepte conexiones de multiples clientes, luego debe admitir cierto nivel deconcurrencia.

+ Se conecte a la base de datos MySQL.

+ Ofrezca al administrador del sistema informacion acerca de las conexiones y eltrabajo que estas realizan.

3. Poner en marcha una maquina 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:

- Disenar un protocolo de comunicacion entre el cliente y el servidor. Un sistema deenvıos y recepciones que les permita dialogar.La figura 3.3 da una vision de la arquitectura interna en el cliente, en la cual quedanrecogidas las principales funcionalidades que va a tener el sistema en su conjunto


desde un punto de vista practico para lo que el cliente necesita y ayuda a comprenderel nivel de complejidad –o sencillez– del mismo.

- Para probar al servidor convendra programar un ((cliente de pruebas)) que no requierala interfaz grafica y permita agilidad al desarrollar y depurar el codigo.

Interfaz de

usuario

entrada salida

Mantenimiento y

autocomprobación

Funciones de

tratamiento y control

Interfaz grafico Entrada de consultas e

intrucciones SQL

Ficheros XLS de

Ms-Excel

por TCP/IP desde servidor Ficheros XLS

de Ms-Excel

por TCP/IP hasta servidor

Tratamiento de sockets

tabla en memoria local

Gestionar ordenes implícitas

Tratar variaciones

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 despues habra que contemplar esta situacion:

- El gestor que trabaja en la oficina y necesita utilizar la base de datos o hacer alguninforme: lista –al banco– de domiciliaciones para cobrar mensualmente, informes dedirecciones 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 permisosde gestor.

- El administrador del sistema, que no solo pueda hacer ajustes y variaciones en ladisposicion del mismo sino que tenga que comprobar cualesquiera de las tareas queestan haciendo el resto de trabajadores.

El diagrama 3.4 deberıa servir para dar una idea de los posibles casos de uso que se derivande esta situacion y que determinan diferentes areas del sistema final.


Figura 3.4: Posibles casos de uso del sistema

3.1.5. Identificacion de subprocesos

Distıngase este nivel de estudio de los procesos y mecanismos inmiscuidos en lo ante-riormente descrito, del posterior modelado del proceso que se debera ver en otra seccion.

Es inevitable diferenciar a partir de ahora el trabajo en el desarrollo del cliente del que sehace con el servidor. Se trata, en realidad, de programas diferentes y deben ser tratadospor separado.Las principales funcionalidades a las que hay que enfrentarse son las siguientes:

Cliente

1. Conexion

a) Pedir login y password.

b) Primer bis a bis con el servidor, para establecer con el el socket de comunica-cion.


c) Cargar una primera vista de MySQL con las bases de datos del usuario conec-tado.

2. Permitir cargar una tabla Ms-Office (tablas de Ms-Excel9).

a) Buscar un archivo en disco local.

b) Compatibilidad Ms-Excel (comprension del formato y archivos *.xls).

3. Entorno de la tabla

a) Modificar valores (columnas, numero de registros).

b) Anadir nuevos registros.

c) Profundizar (si es tabla con nombres de bases de datos o con nombres de tablasde 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(simultanea).

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 en2 como con sus distintas instancias.

a) Conexion 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 grafico un cliente mucho mas simpleque pueda interactuar con el servidor. Aunque no sea necesario ((oficialmente)), puesto quese va a utilizar para probar el servidor, conviene aclarar que es lo que puede hacer esteprograma que puede concebirse, durante el desarrollo y algunas de sus pruebas, como el((doble de escenas de accion)) del cliente protagonista,.

9Se ha elegido Ms-Excel como un mecanismo facil, habitual y comun para llegar hasta Ms-Officeen general e incluso Access si hiciera falta.


1. Tiene bis a bis inicial con el servidor igual que el cliente en su version de interfazgrafica.

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. Planificacion del trabajo

Entendiendo que ninguna de las tareas vistas en 3.1.3 (pagina 15) es de una complejidadextrema ni que se generan bucles de dependencias mutuas, y atendiendo principalmentea que todas las tareas deben ser desarrolladas conviene dibujar un diagrama con los hitosprincipales.La figura 3.5 uestra el camino hacia la meta. A nivel academico podrıa decirse que loshitos: poner a punto servidor, portar datos y puesta en marcha oficial son la guinda delpastel. Sin dejar de prestarles atencion, concentrar las fuerzas en poner en marcha conexito la aplicacion cliente, el proceso servidor y hacer los ajustes necesarios a la base dedatos, permitira aprovechar el tiempo.

Diseño protocolo

comunicación Cliente-

Servidor

inicio

Diseño y creación de

Base de Datos

Cliente Gráfico

(definitivo)

Cliente de pruebas

Programa servidor

pruebas

Poner a punto host servidor

Portar

datos

Puesta en marcha oficial

Figura 3.5: Diagrama de planificacion con los hitos principales

3.2. Modelo de datos

No esta de mas en este caso, profundizar en la relacion que guardan los datos dentrode este sistema y su estructura a nivel practico.Aunque en esta seccion se sobrepase los lımites de lo que va a desarrollarse a posteriori,


todo lo que aquı quede plasmado servira para poder contrastar la vision de conjunto que setiene en este ambito y para preparar cualquier estudio o ampliacion posterior del sistema.

Este nivel de abstraccion es global, de manera que no hay distincion entre elproceso servidor del proceso cliente, porque en ultima instancia la informacion quemanejan es la misma.

El suscriptor La base de informacion sobre la que gira todo este sistema es cadauno de los registros con informacion sobre los clientes y posibles clientes.Su trasformacion en altas como clientes o bajas es el primer nivel de trasformacionposible. Cada mes, se envia al banco una peticion de domiciliar los cobros a todos lossuscritos (incluyendo los nuevos de ese mes) y este devuelve un informe sobre los quetuvo exito. Siempre puede haber incidencias y aunque en teorıa alguien este suscritopara la base de datos, fallar en el pago un mes por error bancario, alguna confusioncon la cuenta si es nuevo o falta de fondos (esto es habitual en los suscritos queasignan una cuenta por separado para la suscripcion).

persona registrada

alta suscripción

baja suscripción

pago del mes

[1:1]

[1:m]

[1:1]

Figura 3.6: Sub-diagrama entidad relacion: entidad suscrito

Los informes Como ha quedado dicho en anteriores secciones, existen trabajado-res comerciales que gestionan directamente las suscripciones de las distintas publica-ciones. Dentro de la base de datos constan como parte integrante de la informacionque se tiene de los suscritos. Para el departamento de contabilidad, se trata de lapieza primera de su esqueleto. El sueldo de estos trabajadores varıa segun la canti-dad de suscritos que en cada momento tienen. De manera que el informe de suscritosactivos se tramita para hacer un informe que se enviara al departamento de conta-bilidad que gestiona los pagos.Por otra parte, cada mes que un suscrito paga, le da derecho a recibir aquello queesta pagando. Desde la base de datos, se genera una lista de etiquetas con las direc-ciones de los clientes, se genera en funcion del informe bancario, que contiene quienpaga y quien no. La lista de etiquetas se envıa al Grupo Maydis que envıa por correolas diferentes publicaciones y los correspondientes packs.


cliente

comercial

informe domiciliaciones

informe sueldos

informe envios

postales

[n:1]

[1:1]

[n:m]

[1:1]

[1:m]

Figura 3.7: Sub-diagrama entidad relacion: relaciones entre informes

3.3. Modelo del proceso

Aquı, como es evidente, solo se puede avanzar diferenciando claramente, lo queatane al proceso cliente de lo que atane al proceso servidor.

3.3.1. Modelo del proceso cliente

Modelo del proceso cliente: Nivel 0. Como aplicacion autonoma, el procesocliente solo puede recibir informacion de tres fuentes diferentes:

- Puede recibir informacion directa que el usuario introduce de alguna manera.

- Puede cargar alguna tabla en formato Ms-Excel que haya en el disco durolocal o en cualquier sistema de archivos montado remotamente por el sistemaoperativo local.

- O bien puede recibir diferentes mensajes o secuencias de mensajes desde elservidor.

En la figura 3.8 queda claro que las posibles salidas de la informacion procesada (osin procesar) son las mismas.

Aplicación cliente

usuario

Archivo local importado

SERVIDOR SERVIDOR

usuario

Archivo local

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


Modelo del proceso cliente: Nivel 1 Descendiendo a un nivel mas profundo hayvarios procesos que aparecen separados por su exclusivizacion y por su importancia:

- La conexion inicial con el servidor es un momento particular. Debe haber unproceso que obtenga de la interfaz grafica los datos del socket y direccion IPdel 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 pequeno protocolo parajerarquizar los datos y que este pueda gestionarlo mas habilmente. Al revessucede lo mismo.

- Cuando el usuario profundiza en el nivel principal que le muestra la interfazgrafica pide implıcitamente que se le muestren las tablas de una base de datoso las bases de datos que puede ver. Las sentencias SQL que esto requiere debenser procesadas automaticamente, igual que cuando se traen o envıan tablas aMySQL.

- Las tablas estan en memoria y desde la interfaz grafica pueden modificarse.Hay mas ocasiones en las que se hace esto que las que a simple vista el usuariopuede imaginar, y en cada redibujado es necesario recargar la tabla, debe haberun proceso encargado de esto.

De manera mas desglosada, puede estudiarse la figura 3.9.

usuario

Archivo local

importado

SERVIDOR SERVIDOR

usuario

Archivo local

Tratamiento de

mensajes leídos

en el socket

Interfaz

gráfica

Tratamiento

tablas

Traducir en

sentencias SQL

las instrucciones

implícitas

Gestión de

la conexion

Convertir en

mensaje para

el servidor

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


3.3.2. Modelo del proceso servidor

Modelo del proceso servidor: Nivel 0 – uno Desde un punto de vista super-ficial, y sobretodo, desde las exigencias del proceso cliente, el proceso servidor tienesolo dos entidades externas por las que fluye la informacion en entrada o en salida:ya sea el cliente a traves del socket, o la base de datos (la figura 3.10 muestra estocon claridad).

Proceso

servidor MySQL

TCP/IP

desde el

cliente

Figura 3.10: Diagrama de Flujo de Datos: Servidor, Nivel 0 – vista superficial

Modelo del proceso servidor: Nivel 0 – dos Sin embargo, el proceso servidordebe ser entendido con dos dimensiones. Por una parte profundizar en sus subproce-sos de la misma manera que con el proceso cliente, pero por otra, el proceso servidordebera 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 serconocido 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, parapoder liberar de nuevo el socket general. Cuando el cliente comprende esto, elproceso principal genera otro subproceso que gestiona concurrentemente a esecliente en particular y que conoce el socket asignado.

- Por su parte, cada proceso concurrente generado permanece en un bucle, enel que escucha los mensajes del cliente y despues de cotejarlos con la base dedatos, envıa las respuestas correspondientes y se pone a la escucha de nuevo.

Aunque con una sola dimension, la figura 3.11 intenta mostrar la primera partede lo explicado. En el proceso principal recae la continuidad del servidor. Aunqueno sea ası con el resto de subprocesos, la creacion y terminacion de cada procesoconcurrente debe ser impecable para que el sistema no se colapse nunca por estarazon. De la misma manera, la gestion de los sockets debe ser cuidadosa. La figura3.12 representa el estado del servidor al llegar un nuevo cliente y pudiendolo haberduplicado mas veces, dibujando mas clientes, hubiera quedado una imagen muyrepresentativa de la carga del servidor.


MySQL

cliente

concurrente dedicado i

Servidor proceso

principal

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

MySQL

Cliente

i

Cliente

ii

Concurrente dedicado

i

Concurrente dedicado

ii

Servidor proceso

principal

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 queaquı interesa, la parte del proceso servidor que no atiende en profundidad las cues-tiones del cliente, no necesita informacion acerca de la base de datos ni provinentede ella.Permanecer a la escucha por el socket inicial (conocido). Cuando llega una conexionautomaticamente 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 estesocket.

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


Escucha conexiones

Cliente

Abrir socket

Lanzar parte concurrente

Figura 3.13: Diagrama de Flujo de Datos: Servidor, Nivel 1 – principal

- Una primera gestion del login y el password que responde segun la base dedatos acepte o no a dicho usuario.

- Gestionar los mensajes que envıa el cliente y separar de el las sentencias SQLque incluyen en el caso que ası sea, o generando las sentencias implıcitas comoen 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 quepodran apreciarse interna o externamente en el cliente ni en el servidor. Aunque


no quede cerrada una seccion de diagramas que describa el comportamiento y latransicion entre los estados, deben quedar anotadas ciertas cuestiones fundamenta-les:

- El proceso cliente tiene tanto en una version grafica como en una version depruebas dos estados importantes.

+ Conectado a la base de datos. Solo es posible si el usuario entra correc-tamente la IP del servidor, el puerto de escucha es conocido y un loginy un password que la base de datos reconozca. Ademas el servidor debedar la respuesta correspondiente. Este estado determinara el resto delcomportamiento del cliente.

+ Desconectado: es el estado inicial y final si todo sigue un curso normal.

- En cada conversacion entre cliente y servidor la secuencia debe ser:

1. Pregunta del cliente.

2. Respuesta del servidor.

Que uno u otro esten a la espera de una respuesta, es un estado determinantey que debe ser cuidado, pues un mal funcionamiento harıa inestable a eseproceso.

Capıtulo 4

Diseno orientado al flujo de datos

4.1. Discusion sobre la Orientacion a Objetos

Considerando que puede enfocarse el diseno (y, en general, la construccion delsoftware) ya sea desde el punto de vista del flujo de los datos por cada uno de losprocesos o a su traves; o bien siguiendo una filosofıa de Orientacion a Objetos1. Enel capıtulo 3 (pagina 11) se ha dejado esta contradiccion abierta, razonando queaun no estaba lo bastante maduro el analisis del problema como para pensar enque filosofia de diseno le era la apropiada. Es hora de abordarla.A favor de la Orientacion a Objetos podrıa apuntarse:

+ El manejo de los sockets puede enmascararse para su uso y hacer esta tareamas trasparente a la hora de abordar los procesos de comunicacion (pregun-ta/respuesta) entre cliente y servidor.

+ El manejo de las tablas en el interfaz grafico quiza merece pensarse desde laOO, pudiendose diferenciar lo que es el contenido de la informacion de susmetodos de representacion en pantalla o de modificacion.

+ Se pueden resolver otras tareas como clases, separando informacion y meto-dos, creando quiza una clase que encierre lo relativo a las sentencias SQL, sutraduccion, las sentencias implıcitas que encierran ciertas acciones del usuario,etc.

Se pueden encontrar, sin embargo, razones determinantes para descartar este tipode filosofia:

- La resolucion de este problema, incorpora dos poderosos aliados en los queapoyarse, para resolver una buena parte de las tareas:

1El diseno OO permite ((construir sobre tres pilares fundamentales: abstraccion, ocultamientode la informacion y modularidad.)) Aunque todos los metodos de diseno procuran esto el ((DOOproporciona un mecanismo que permite al disenador conseguir las tres sin complejidad)) definicionde [9] en su tercera edicion.

28

CAPITULO 4. DISENO

· Por un lado la base de datos (en este caso MySQL) facilitara el manejo dela informacion (de los registros) y las cuestiones de seguridad de accesode forma inmediata.

· La interfaz grafica propia del sistema o lenguaje de programacion que sedecida utilizar debera integrar mecanismos para almacenar lo representa-do en pantalla de manera que la tabla cargada no necesite ser manejadapor el programador a mas nivel que el usuario de una librerıa. Por otraparte, si se programan metodos para cambiar el contenido de la tabla querequieren nuevos accesorios propios de la interfaz grafica como cuadrosde dialogo y ventanas, acabarıan creandose ciclos (ocultos por las clasescreadas) en el uso de la librerıa grafica.

- El manejo de los sockets tambien debe ser facilitado por el lenguaje de pro-gramacion utilizado. Concebir este problema como una tarea complicada eserroneo. El cliente y el servidor solo necesitan dialogar y el cliente es siempreel que pregunta.

- No hay necesidad de prevenirse para una posterior herencia en una fase demantenimiento perfectivo2. Y aunque este tipo de practica siempre eleva lacalidad, en este caso serıa exactamente matar moscas a canonazos. Harıa mascomplejo el trabajo y no resolverıa ni mejorarıa nada en particular.

NOTA: Observese que en esta seccion se han introducido implıcitamente algunasnecesidades que deberan ser tenidas en cuenta a la hora de elegir el lenguaje deprogramacion, las librerıas graficas y las librerıas de sockets que ofrezca.

4.2. Diseno arquitectonico

Determinacion del flujo de datos (primera revision DFDs)

Repasando sobretodo las figuras 3.8, 3.9, 3.10 y en general todos los diagramasde flujo de datos que se han utilizado en la fase de analisis se puede descartar quehaya un flujo de transaccion.En el capıtulo correspondiente de [9] Pressman define este tipo de flujo de la in-formacion cuando los datos se ((mueven a lo largo de un camino de entrada queconvierte la informacion del mundo exterior en una transaccion. La transaccion seevalua y basandose en ese valor, se inicia el flujo a lo largo de uno de muchos ca-minos de accion. El centro del flujo de informacion del que parten los caminos de

2Ya se explico en 1.2 que uno de los objetivos del trabajo es abrir un camino para poderampliar en el futuro el software cliente-servidor de manera que todas las actividades necesariaspuedan resolverse desde este sistema y en particular desde el cliente.

CAPITULO 4. DISENO

accion se denomina centro de transaccion)). Y no existe en el capıtulo de analisisningun DFD con ese aspecto.

4.2.1. Diseno arquitectonico en el cliente

Descomposicion de primer nivel

Atendiendo pues, a un punto de vista de flujo de trasformacion y estudiandoprimeramente la figura 3.9 puede desglosarse el subproceso de interfaz grafica desdedos intereses:

∗ La constante emision grafica de la tabla y del resto de variables de entornoque supone tener una ventana para la aplicacion y los diferentes menus ysubmenus.

∗ Las ocasionales entradas de datos que el usuario hace para modificar registrosde la tabla o variables como los datos de la conexion, los datos desde Ms-Excel,etc.

Como muestra la figura 4.1, la interfaz grafica se dividirıa en varios procesos dife-renciandose lo que es la salida grafica propiamente dicha de las entradas de valoresde la conexion, de la tabla o las instrucciones implıcitas si el usuario interactua conla tabla.De la misma manera se separa la salida a nivel local ya sea de informacion de latabla al disco (en un archivo Ms-Excel) o la salida por pantalla; de las salidas deinformacion o preguntas al servidor.

Descomposicion de segundo nivel

Con la subdivision de la figura 4.1 se puede presentar una descomposicion desegundo nivel con un aspecto de arbol propio de la notacion de una jerarquıa decontrol.Siguiendo una particion estructural de tipo horizontal en la figura 4.2 se ha hechouna primera aproximacion desglosando por niveles de profundidad y separando laentrada de la salida a nivel local, aunque la interfaz grafica sea un concepto quecubra uno y otro servicio.La relacion entre los DFDs y los diagramas de arquitectura como el que se ha tra-ladado a la figura 4.2 no debe ser tomada, en esta fase, como una biyeccion perfectaentre modulos; Pressman en [9] dice que ((se pueden combinar dos o incluso tresburbujas y representarlas como un solo modulo, o una sola burbuja puede dividirseen dos o mas modulos (...) La revision y el refinamiento pueden llevar a cambios enla estructura, pero puede servir como una primera iteracion del diseno.))

CAPITULO 4. DISENO

usuario

Archivo local importado

SERVIDOR SERVIDOR

usuario

Archivo local

Entrar datos a tabla

Valores conexión

Navegar

por base de datos

Respuestas

con datos

Tratamiento tabla en

ámbito local

Proceso de

la conexión

Entorno

interfaz gráfica

Convertir en

mensaje para el servidor

Tramiento tabla en ámbito

remoto

Procesos de

ENTRADA

Comunicación

son servidor

SALIDA

Figura 4.1: Diagrama de Flujo de Datos: Cliente, Nivel 1 refinado – descomposicionde primer nivel

Aplicación cliente

Entrada

datos

local

Conexión

inicial

Comunicación

servidor

Valores

conexion

Entrar datos

a tabla

Navegar

entorno bd Sentencias

para

MySQL

Salida

datos

local

(interfaz gráfica)

Mostrar

tabla

Valores

conexion

Menús

interactivos

Grabar

tabla localmente

Figura 4.2: Estructura del cliente (particion horizontal) – descomposicion de segundonivel

4.2.2. Diseno arquitectonico en el servidor

Descomposicion de primer nivel

Lo unico que requiere de especial la fase de diseno del proceso servidor es atendera la presencia de un proceso concurrente que atiende las peticiones de cada cliente

CAPITULO 4. DISENO

y un proceso principal. Por todo lo demas, el proceso servidor, es aun mas sencilloque el del cliente y la conversion de los DFDs mucho menos problematica.El diagrama de flujo de datos del servidor, en la profundidad uno, tanto del procesoprincipal como del proceso concurrente, puede dejarse tal cual en la revision y en elrefinado. Las figuras 3.13 y 3.14 muestran con claridad los problemas que habra queabordar a la hora de desarrollar el servidor.

Descomposicion de segundo nivel

Mas aun, de una manera aun mas explıcita y menos arbitraria, se puede dife-renciar que el proceso servidor tiene dos vıas de comunicacion con subdivisiones deentrada y salida, en lo que a la parte concurrente se refiere.En relacion al proceso principal se han apuntado en la figura 4.3 los tres frentes enlos que –con el nivel de conocimiento que puede tenerse en esta fase– se entiendeque habra 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 – descomposicion de segundo nivel, proceso prin-cipal

conexion inicial del cliente del resto de ejes de construccion del servidor. Por la ma-nera en que se ha dividido los diagramas del servidor atendiendo a su multiplicidady a su concurrencia, la fase de conexion es un proceso donde intervienen todos losfactores en el servidor de manera concentrada:

- Informacion del login y el password que el usuario ha introducido en el cliente.

- La confirmacion de la base de datos.

- La creacion de un socket dedicado para el nuevo cliente.

- La instanciacion de un proceso concurrente que resuelva las peticiones delcliente por separado.

CAPITULO 4. DISENO

De todas maneras, como la propia figura 4.4 muestra, se trata de un proceso3 muypequeno, que se puede concretar en la fase de implementacion sin problemas, conalgo de cuidado.

Servidor proceso

concurrente

Gestión de

la conexión

inicial a la base de

datos

Trato con el

cliente

Trato con la

base de

datos

Recoger

mensajes y

tratarlos

(IN)

Emitir datos

al cliente

(OUT)

Emitir

sentencias

SQL

Recoger

resultados

Figura 4.4: Estructura del servidor – descomposicion de segundo nivel, proceso con-currente

4.3. Postproceso de diseno

En esta seccion se han de tratarse principalmente tres aspectos propios de la faseque Pressman define en [9] como postproceso y que en este caso se han consideradolos mas importantes:

- Desarrollar una descripcion del procesamiento para cada modulo.

- Una descripcion de la interfaz para cada modulo.

- Anotar las restricciones y limitaciones del diseno.

Concretamente, conviene releer que ((un texto explicativo del procesamiento es unadelimitada descripcion sin ambiguedades del procesamiento que ocurre dentro deun modulo. La narrativa describe el procesamiento, las tareas, las decisıones y laentrada/salida)).Y resaltar que en cuanto a la interfaz, convendra detenerse a concretar la entraday la salida del sistema en cada modulo, al tiempo que postergar lo relativo a lasinterfaces entre modulos y las interfaces hombre-computadora que se abordaran ensecciones siguientes.Es interesante respetar la jerarquıa de los arboles que se han dibujado en secciones

3Sigue refiriendose a la ”gestion de la conexion inicial a la base de datos”.

CAPITULO 4. DISENO

anteriores, no solo para facilitar el trabajo en esta seccion y su lectura sino tambienpara poder anotar las limitaciones que se van encontrando en el diseno y que sedeberan tener en cuenta en proximas fases.

4.3.1. Descripcion de modulos en el cliente

Para entender las tablas de esta seccion, se deben cotejar conjuntamente con lafigura 4.1 en la pagina 31 y los DFDs de los que procede.El objetivo de esta seccion es reducir el maximo numero de modulos a una descrip-cion mas o menos inmediata. Comprender en ese proceso las debilidades del modeloy dejar previstas el resto de cuestiones para fases posteriores de desarrollo con elmaximo nivel de entendimiento.

Nombre del modulo grabar tabla localmenteProceso clienteEntrada tabla en memoriaSalida archivo en disco con formato Ms-ExcelDescripcion Permite al usuario nombrar el archivo

y ubicarlo localmente. Le da una ex-tension xls al nombre y graba en el, elcontenido de la tabla que hay cargadaen memoria y que el interfaz visualiza.

Cuadro 4.1: Descripcion modulo: Grabar tabla localmente.

Nombre del modulo entrar datos a la tablaProceso clienteEntrada interfaz de usuario (teclado y raton)Salida tabla en memoria y visualizacion en

pantalla Ms-ExcelDescripcion Permite al usuario ver la tabla que

esta cargada en memoria de una mane-ra intuitiva. Elegir la columna o regis-tro que quiere modificar y modificarlode forma inmediata viendo los resulta-dos en pantalla.

Cuadro 4.2: Descripcion modulo: Entrar datos a la tabla.

CAPITULO 4. DISENO

Nombre del modulo mostrar la tablaProceso clienteEntrada tabla en memoria localSalida visualizacion –en pantalla– de la tabla

de manera intuitivaDescripcion Debe sacar por pantalla cada vez lo que

realmente hay en la memoria. Debe res-petar el contenido en los redibujados.

Cuadro 4.3: Descripcion modulo: mostrar la tabla.

Nombre del modulo valores de la conexionProceso clienteEntrada interfaz de usuario (teclado y raton)Salida variables globalescon la informacionDescripcion La direccion del servidor, el puerto de

escucha (del mismo), el login y el pas-sword del usuario son cuatro valores ne-cesarios para la conexion inicial a la ba-se de datos. Hace falta pedirlos y alma-cenarlos para el resto de la conexion.

Cuadro 4.4: Descripcion modulo: valores de la conexion.

Limitaciones en el modelo del cliente

Avanzar la descripcion de los modulos provista en esta fase del refinado de losDFDs, su estudio y su descomposicion: aproxima una vision mas real del trabajohecho hasta ahora, sus limitaciones y algunas de las dificultades que aun no han sidoresultas.

- La cuestion de la estructura de datos que contiene en memoria a la tablainicializada o cargada (ya sea desde un archivo o desde la base de datos), no hasido finalmente abordada hasta el momento. El riesgo de tropezar mas adelantecon una interfaz grafica o un soporte propio del lenguaje de programacion queresuelva esto sigue invitando por el momento a postergar esta decision, pero almismo tiempo debilita la vision global que se tiene y supone una dependenciade un entorno de trabajo (librerıas, lenguajes de programacion, etc) que aunno se disponen.

- Algunos de los modulos han quedado ambiguos o diluidos por ser demasiadogenerales y no se han descrito en las tablas de estas paginas. Sus tareas, sin

CAPITULO 4. DISENO

Nombre del modulo conexion inicialProceso clienteEntrada variables de la conexion (IP-Servidor y

Socket-Escucha-Servidor)Salida estado general conectado o no (a alma-

cenar en una variable global)Descripcion El cliente se conecta primero con el

servidor segun el IP-Servidor y elSocket-Escucha-Servidor que introduceel usuario. Si tiene exito despues pide alproceso servidor que le conecte a la basede datos y que le haga de intermedia-rio (partiendo del login y el passwordintroducidos por el usuario).

Cuadro 4.5: Descripcion modulo: conexion inicial.

Nombre del modulo sentencias para MySQLProceso clienteEntrada interfaz del usuario (teclado y raton)Salida sentencias SQL encuadradas en un

mensaje al servidorDescripcion El usuario puede manipular en entorno

de la tabla, cambiar registros, anadircolumnas, etc. Las sentencias SQL quegeneran estas acciones implıcitamenteo las que el usuario introduzca directa-mente de manera explıcita son envıadasal proceso servidor en un mensaje de-bidamente enmarcado cuyo aspecto elservidor conoce.

Cuadro 4.6: Descripcion modulo: envıo de sentencias SQL.

embargo, siguen siendo diferentes y en fases de implementacion debera revi-sarse sobretodo los DFDs y documentar debidamente en que partes del codigohan quedado dichas soluciones.

CAPITULO 4. DISENO

4.3.2. Descripcion de modulos en el servidor

Para esta parte deben examinarse las tablas revisando las figuras 4.3 y 4.4 (en lapagina 32) y tenerse en cuenta que el proceso servidor se ha estudiado por duplicadodesde la fase de analisis teniendo en cuenta su concurrencia.

Nombre del modulo generar proceso concurrenteProceso servidor (proceso principal)Entrada Socket para hablar con el clienteSalida un manejador de procesoDescripcion En esta parte el proceso servidor lanza

(en connivencia con el sistema operati-vo) un proceso concurrente que escuchalas peticiones del cliente.

Cuadro 4.7: Descripcion modulo: generar proceso concurrente.

Nombre del modulo conexion con la base de datosProceso servidor (proceso concurrente)Entrada login y password del usuario en el clien-

teSalida lista con las bases de datos que puede

ver ese usuario o negativaDescripcion Con la informacion del usuario que

remotamente esta conectado desde elcliente, el proceso servidor (ya en suparte concurrente) pide conexion a labase de datos, obteniendo acceso y mos-trando al usuario sus bases de datos ac-cesibles o devolviendole una negativa.

Cuadro 4.8: Descripcion modulo: conexion 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 clien-te para describir sus modulos, se trata ahora de ver que debilidades han aparecidoal hacer lo propio con los modulos del servidor:

- Examinando los modulos del proceso concurrente y la figura 4.4 (en la pagina33) se nota que se han desglosado excesivamente (aunque con el buen objetivo

CAPITULO 4. DISENO

Nombre del modulo escuchar peticiones de los clientesProceso servidor (proceso principal)Entrada Mensaje por socket de escucha del ser-

vidor con el numero del socket de escu-cha del cliente

Salida un numero de socket del servidor dedi-cado exclusivamente a ese cliente

Descripcion Primer bis a bis entre cliente y servidor.El servidor escucha (por definicion). Uncliente llega y le dice por que socket (delcliente) solicita conversar. El servidorcrea su propio socket para hablar conaquel y ambos liberan la conversacioninicial (es necesario que el servidor li-bere su socket general de escucha puespor este le llegaran nuevas peticiones).

Cuadro 4.9: Descripcion modulo: escucha de peticiones del cliente (primer bis a biscliente-servidor).

Nombre del modulo recoger mensajes del cliente y tratarlosProceso servidor (proceso concurrente)Entrada Mensaje por socket enviado por el

clienteSalida retorno por el mismo socket de la res-

puestaDescripcion El preceso concurrente espera cada

mensaje del cliente. Lo examina yevalua separando la sentencia SQL siexiste. Consulta con la base de da-tos, recoge la respuesta y la reenviaenmarcada debidamente en una ristracomunmente acordada. Muy importan-te, la respuesta puede suponer un envioo mas, el proceso servidor coordina estoy avisa debidamente al cliente.

Cuadro 4.10: Descripcion modulo: escucha de consultas en el servidor.

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

CAPITULO 4. DISENO

Nombre del modulo pregunta respuesta SQLProceso servidor (proceso concurrente)Entrada sentencia SQLSalida respuesta de la base de datosDescripcion En este proceso se emite a la base de

datos la sentencia SQL y se recoge (deforma multiple si es necesario) la res-puesta.

Cuadro 4.11: Descripcion modulo: gestion de consultas del servidor.

mas comodo y mucho mas intuitivo juntarlos pues la salida se debe a la entraday no puede entenderse por separado.Queda para fases posteriores la decision del nivel de subdivision que se le vaa dar a las cuatro ramas del arbol que en las tablas han aparecido como dosmodulos.

- El inicio en el servidor: llegada de un nuevo cliente, generacion de socket dedi-cado, generacion de un proceso concurrente y posterior conexion a la base dedatos ha sido separado atendiendo sobretodo a la multiplicidad en el servidor.Este mecanismo puede resolverse de muy distintas maneras y en posterioresfases de desarrollo, en funcion de como se resuelva la gestion de los socketsquedara como se ha mostrado aquı o con otro ((ritmo))4.

4.4. Diseno de la interfaz

4.4.1. Notas previas

Volviendo una vez mas a Pressman en [9] entiendase por interfaz los tres casossiquientes:

- ((El diseno de interfaces entre los modulos software)) Esta parte nosera abordada en esta seccion, porque la sencillez con la que hasta el momentose ha resuelto la comunicacion entre los datos y los procesos, invita a pensarque en posteriores fases del desarrollo, podra resolverse de una manera maso menos inmediata, y si hiciera falta revisar lo aquı descrito serıa entonces elmomento correspondiente donde exlicarlo.

- ((El diseno de interfaces entre el software y otros productores yconsumidores no humanos de informacion los modulos software))

4Se refiere a la secuencialidad de los dialogos entre el cliente y el servidor.

CAPITULO 4. DISENO

En el caso de este sistema, se trata del interfaz con el proceso cliente (comoentidad 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 yase ha escrito sobre ello, que habra una comunicacion mediante sockets, esdecir, un interfaz TCP/IP. Tambien se ha descrito en distintos momentosque a la hora de enviarse mensajes, cliente y servidor, deben encapsularsus envıos en un marco conocido por ambos. Con aspecto de lo que en otronivel5 se podrıa concebir como una trama o un paquete. La descripcionde esta interfaz se ha postergado a fases posteriores. Pero antes o despuesdebe ser abordada pues se trata de la piedra angular para la comunicacionentre el cliente y el servidor.

∗ La interfaz entre el servidor y la base de datos esta en funcion de laslibrerıas que permitan la conexion con la base de datos. Sabiendo queesta sera MySQL puede recordarse aquı que en la seccion 3.1.2 (pagina12) se valoraba como una ventaja de MySQL que podıa ser invocadadesde diferentes lenguajes de programacion. Como aun no se ha decididonada acerca del lenguaje de programacion el diseno de dicha interfazqueda pendiente, aunque no sera necesario de una manera explıcita si ellenguaje que definitivamente se utilice es lo bastante potente (y esto esuna aspecto importante para que resulte elegido).

- ((El diseno de la interfaz entre el hombre y la computadora)) En-tendiendo que sobre esto aun no se ha descrito nada, conviene profundizar unpoco mas y (siguiendo los pasos de Pressman en [9]) abrir el apartado dedicadoa esta discusion.

4.4.2. Consideraciones sobre el diseno de la interfaz hombre-maquina

La figura 3.4 en la pagina 18 mostraba tres tipos de usuario diferentes. Lo quedebe importar de ellos en esta seccion es su conocimiento sintactico6 y semantico7

del sistema:

- El administrador del sistema no debe preocupar al disenador (ademas por elmomento ambas figuras son la misma). Tiene (o debe tener) conocimiento

5Se refiere a otro nivel en el modelo por capas que la literatura al respecto propone para describirlas comunicaciones entre computadoras.

6Pressman lo define en [9] como ((mecanica necesaria para usar la interfaz eficazmente)).7((Sentido subyacente de la aplicacion: una comprension de las funciones que se ralizan, el

significado de los datos de entrada y de salida y las metas y los objetivos del sistema)).

CAPITULO 4. DISENO

completo del sistema. Es el unico que maneja el proceso servidor con lo queesta interfaz puede ser simple, aunque sı clara, y puede ser en modo consola.

- Algunos de los comerciales deben ser considerados usuarios novatos. Sin conoci-miento sintactico. La lınea de demarcacion para construir la interfaz hombre-maquina en la aplicacion cliente debe rebajarse hasta ellos. La imagen delsistema debe guiarles en sus operaciones y solo deben necesitar informacionadicional para resolver la conexion inicial, proceso que una vez aprendido debeser sencillo.

- Los gestores pueden ser considerados usuarios frecuentes (con ((conocimientosemantico razonable pero con recuerdo vago de la informacion sintactica))).Lo que hay que considerar de ellos es que trabajan en el mismo entorno delservidor. Pueden resolver cualquier dificultad in situ pues no trabajan remo-tamente. Pueden disponer de notas, de esta u otra documentacion, y de laayuda del administrador del sistema. De todas maneras lo mas importante esque si los usuarios novatos pueden utilizar la interfaz grafica de la aplicacioncliente ellos deben tenerlo mas facil.A efectos de diseno de la interfaz hay que atender a las consideraciones deusuario novato de momento. Aunque se prevea un tiempo para capacitarlo,este sera ınfimo.

Capıtulo 5

Implementacion

Todas aquellas cuestiones que aun no han quedado resueltas, todas aquellas decisionesque (por una u otra razon) aun no han sido tomadas, deben ser abordadas en esta fase. Esosı, siempre que entren en el terreno de mas bajo nivel de abstraccion: la implementaciono el trabajo directo.Por otra parte, incluso el mas experto de los cirujanos, habiendo estudiado concienzu-damente los pormenores de una intervencion, teniendo preparadas las radiografıas, lasanalı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 cosassolamente se pueden comprobar en la practica directa.

5.1. Decisiones previas

5.1.1. El lenguaje de programacion

Seguramente, una de las decisiones mas importantes que quedan por tomar. Porque lenguaje tomar partida. En principio no hay ninguna obligacion de elegir uno u otroen particular, pero sı que es menester, antes de tomar ninguna decision, apuntar que crite-rios1 para elegir el lenguaje de programacion se han ido contemplando hasta el momentoy jerarquizarlos (de mas importante a menos importante):

1. Tiene que ser uno de los enumerados en la seccion 3.1.2 ya que lo que sı que esta deci-dido es que la base de datos sera MySQL, recuerdense estas posibilidades: C, C++,Eiffel, JAVA, Perl, Python, Ruby y Tcl.

2. Debe permitir un codigo facilmente portable entre Linux y Windows, ya que elentorno en la Oficina puede variar, y aun siendo Linux el cliente correra en equiposLinux (de la oficina) y Windows indistintamente.

3. Es preferible que sobrecargue el sistema lo menos posible.

1En la seccion 4.1 ya se hablo algo sobre ello, se trata aquı de recordarlo y recoger otros criteriosque se hayan visto en otras secciones o apuntar otros que se consideren ahora.

42

CAPITULO 5. IMPLEMENTACION

4. Debe poder acceder a informacion de Ms-Excel, al menos.Ya se ha comentado que ac-tualmente se trabaja en un entorno de Microsoft Office y los usuarios van a necesitarinformes que posteriormente trataran desde Excel, al cual ya estan habituados.

5. Interfaz grafico para Windows y para Linux (aunque no se haya dicho explıcitamentees evidente que tener un proceso que lo automatice o unas buenas librerıas es uncriterio).

6. Manejo de sockets inmediato.

Alternativas independientes de la plataforma

La primera criba (que elegir MySQL ha establecido) proporciona una lista de 9 len-guajes de programacion de entre los que decidir finalmente. El siguiente de los criteriosse refiere a la plataforma, y al hecho, de que el lenguaje que sea elegido finalmente debefuncionar tanto en Windows como en Linux.Es interesante, por lo tanto, ver que alternativas existen al respecto2:

∗ C/GDK/GTK: Lenguaje de programacion C y librerıas graficas GDK y GTK.

Ventajas:

+ La potencia y la buena (e historica) relacion de C con Linux.

+ Las librerıas graficas GDK y GTK son bastante poderosas.

Desventajas:

- ((El conjunto de GDK y GTK esta disenado para ser independiente de laplataforma y en cierta medida dependiente del lenguaje. Lamentablemente losports de GDK no estan tan extendidos en plataformas no Linux. Por otra partelas librerias de C especıficas son generalmente ligadas a la plataforma. Por loque habrıa que comenzar a combinar codigo generico con codigo especıfico, loque complica el desarrollo)). Esta es sin duda la razon mas determinante paradescartar C.

- El trato de la memoria (sobretodo), a menudo queda en C en manos delprogramador, 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 desdeun punto de vista academico puede ser interesante, aquı representa una losaprescindible.

∗ C++/QT: Las ventajas y desventajas de utilizar C++ serıan las mismas que enel caso anterior. La unica diferencia es que C++ permite Orientacion a Objetos deuna manera natural, pero ya se ha dicho en 3 y en 4.1 que esto era completamenteinnecesario.

2Se ha tomado como referencia el sitio web http://linux.ubiobio.cl donde quedo plasma-

do el 3o Encuentro Linux UBIOBIO 2002 en la Universidad del Bıo-Bıo (campus Concep-cion)– Chile–, todas las citas en esta seccion se refieren a lo discutido en dicha web.


∗ C#/GTK#: Esta serıa una alternativa interesante, tanto desde el punto de vistade la actualidad como desde un punto de vista academico, por desgracia, segun sumanual (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 len-guaje independiente de la plataforma que incluye la ventaja del garbage collectorque ((se encarga de reasignar la memoria de objetos que ya no esten siendo referen-ciados.))El caso merece ser estudiado con algo mas de profundidad.

¿Por que no JAVA?

Para un usuario neofito es difıcil averiguar, sobre un lenguaje de programacion que noha utilizado, lo suficiente para saber si le interesa o no en una aplicacion concreta. Nor-malmente no se escriben tratados caracterizando la naturaleza de un lenguaje de progra-macion sino que existen manuales y la experiencia proporciona al programador una visionde conjunto. Por otra parte hay muchos mas manuales y textos redactados por partidariosque por sus detractores y nadie hace crıticas severas a ningun lenguaje de programacion,porque si ha tenido que verselas con el, normalmente habra saltado los obstaculos y apro-vechado sus propiedades.No hay mucho tiempo que perder en esta cuestion, ası que como tampoco se ha encontra-do mucha literatura al respecto la seccion que sigue ha quedado resuelta sobre la base decotejar informacion de distintas fuentes (tanto Internet como programadores habituados aJAVA).Si el lector queda anegado por la incertidumbre de las referencias a Internet es tan grave(sino mas) como que al autor le haya pasado lo mismo. Lo justo es reproducir en estaseccion las conclusiones mas claras que se tienen de la manera mas parecida a como sehan conseguido.

Tomando primeramente desde http://www.qualitrain.com3 donde aparece una compa-racion entre JAVA y VBasic se pueden aceptar cuatro criterios generales en lo referente auna arquitectura cliente-servidor a la hora de elegir el lenguaje de programacion:

- La complejidad de la arquitectura.

- La migracion de la arquitectura de 2 a 3 capas.

- Las necesidades de la organizacion4.

- El presupuesto asignado para implantar esta tecnologıa.

Las ventajas que ofrece JAVA son:

3Referencia web de Qualitrain Express que ((inicio operaciones en noviembre de 1996, ofreciendolos servicios de capacitacion, consultorıa especializada en tecnologıas de objetos e implantacion demetodologıas de desarrollo orientadas a objetos.)).

4La organizacion donde se usara la aplicacion.


+ 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 graficas como awt y swing, las cuales permi-ten crear objetos graficos comunes altamente configurables y con una arquitecturaindependiente de la plataforma.))

+ Se trata de un lenguaje ((de moda)). Su avance, su uso y su conocimiento estan a laorden del dıa y siguen ampliandose documentaciones y libros.

+ ((Se puede acceder a bases de datos facilmente con JDBC, independientemente de laplataforma utilizada. El manejo de las bases de datos es uniforme, es decir transpa-rente y simple.))

Aunque JAVA parece ser una alternativa definitiva hay que estudiar sus desventajas, quetambien tiene, segun parece:

- Con respecto a la portabilidad: ((para manejo a bajo nivel deben usarse metodosnativos)). En cuanto que limitacion de la portabilidad esto sı es una desventaja.

- ((El diseno de interfaces graficas con awt y swing no es simple. Existen herramientascomo el JBuilder que permiten generar interfaces graficas de manera sencilla, perotienen un costo adicional.))

- Parece que no esta 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. Enlas actuales condiciones, soportando MySQL hay mas que suficiente.

La lentitud de JAVA

Por el momento las caracterısticas siguen invitando a su uso. No obstante, el tercer requi-sito que ha sido incluido en 5.1.1 es que el lenguaje no debe sobrecargar el sistema.La arquitectura de JAVA incorpora la maquina virtual de JAVA (a partir de ahora soloJVM): ((un procesador software (virtual) que se dedica a procesar las instrucciones del pro-grama y se entienda con el hardware y el sistema operativo)). Lo que el compilador de JAVAgenera 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 ((tecnica)) son muchas y diversas a lo largo y anchode Internet y de la literatura al respecto. Lo que interesa a la hora de la verdad es si elresultado es eficaz y eficiente.Hace unos anos, muchos de los estudios y discusiones sobre este tema afirmaban con ro-tundidad que JAVA era bastante mas lento que C y C++. Siempre se ha atribuido esteproblema al hecho de incorporar un proceso intermediario entre la aplicacion, y el sistemaoperativo y el hardware.La figura 5.1 y la tabla 5.1 son el resultado de un estudio comparativo entre C++ y JAVA

5JAVA Development Kit o kit de desarrollo para JAVA.

6Java Database Connectivity.


Figura 5.1: C++ versus JAVA – ((el tamano mas grande representa quien 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 deque ((JAVA es lento)) (o ((mas lento que ...))) es mas bien una leyenda del pasado.Hay que tener en cuenta que las pruebas se lanzaron en un ordenador portatil ((Pentium4 mobile chip)) con 512 Megabytes de memoria (aunque –eso sı– con un pequeno y lentodisco duro). El sistema operativo era Red Hat Linux 9/Fedora con la version 2.4.20-20.9del kernel.Las pruebas demostraron que en la mayorıa de casos, JAVA era superior a las versiones de

8El diario para desarrolladores de JAVA.9SYS-CON Media (Montvale, NJ), fundado en 1994 ((ampliamente reconocido entre las

industrias de publicacion de revistas y de tecnologıa en Internet como el lider mundialen publicaciones . . . )) traduciendo directamente de su pagina web que puede visitarse enhttp://www.sys-con.com.


G++ 3.3.1 JAVA 1.4.2Intel 386 Intel 686 Server JVM Client JVM

Ackermann 60.95 39.03 34.53 N/A7

Fibonacci 49.41 43.13 33.12 49.78Hash2 21.11 21.62 9.96 14.56Hash 16.43 16.51 7.93 86.76Heapsort 20.04 19.63 21.59 20.47Matrix 10.58 10.76 14.95 30.55Method call 24 20.49 2.47 39.18Nested loop 12.63 15.08 23.42 32.57Object creation 24.88 23.47 6.4 7.17Random no. gen. 21.29 15.12 29.99 57.08Sieve 16.54 16.53 15.08 16.66String concatenation 2.49 1.79 2.6 2.99Sumcol 9.11 8.51 6.69 12.75Word count 4.37 4.27 3.02 3.89

Cuadro 5.1: C++ versus JAVA – tabla de tiempos ((el tamano mas pequeno (siempre ennegrita) representa quien es mejor)).

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

Una conclusion provisionalLos puntos mas debiles (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 plataformaarroja la sombra de duda. Los benchmarks de la revista JDJ por un lado tranquilizanpero por otro lado asustan: Parece demasiado importante para los partidarios deJAVA demostrar la rapidez de este y su ((no inferioridad)) con respecto a C. En elsistema al que se deben estas paginas, no puede haber posibilidad de dudas. Como sevio en el primer capıtulo, el equipo cliente puede ser cualquier equipo y es importanteque la instalacion y lanzamiento del proceso cliente sean lo mas rapidas posible yno sobrecarguen el sistema en dicha maquina.

2. La dependencia de la JVM crea problemas a la hora de generar un archivo ejecutableen JAVA. Esto es posible pero no es inmediato. Anadiendo a las necesidades citadasen el caso anterior hay que decir que lo mas interesante es que el usuario dispongapara el equipo cliente un ejecutable que resuelva concentradamente la apliacion.Otro tipo de formatos que compliquen mas ese proceso y requieran del usuario lainstalacion de la JVM es aquı un lastre a evitar. Hay una diferencia importante entreser independiente de la plataforma y tener facil portabilidad entre plataformas.


3. En lo que a programacion (mas bien codificacion) se refiere, aunque no se ha profun-dizado previamente, JAVA es fuertemente Orientado a Objetos y tanto en la seccion3 como en 4.1 ya se ha explicado que esa no es aquı ninguna prioridad. Esta ca-racterıstica le hace a JAVA ser a veces demasiado complicado para una sentenciasencilla. El clasico ((hola mundo!)) en JAVA segun parece, se implementarıa segunalgo 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, peroque puede ser algo incomodo para este caso. Por eso conviene estudiar mas alternativasantes de decantarse por la primera.

¿Por que no Perl?

Como Perl se ha convertido practicamente en un paquete organico a todas las distri-buciones Linux algunas de las dudas al respecto se han resuelto en esta seccion probando(con telnet) directamente un pequeno script en el servidor slabii.uv.es de la Universidadde Valencia. Lo cual hace buena publicidad de lo inmediato que resulta a veces el uso deeste lenguaje.

Un interprete independiente de la plataformaDentro del mundo de los lenguajes de programacion se puede decir que hay dos posibili-dades: Los lenguajes de programacion (propiamente dichos, como C, C++ o JAVA10) ylos lenguajes de scripting11 o (en espanol) interpretados (como Perl, Visual Basic, Pythono Tcl). Citando al propio Larry Wall (creador de Perl): ((un script es lo que se le da alos actores, un programa es lo que se le da a la audiencia)).Tradicionalmente se llamaba script al ((guion)) o archivo de instrucciones que se le in-troducıa directamente al interprete del sistema operativo para resolver de manera masautomatizada ciertas tareas de administracion. Los lenguajes interpretados han revolucio-nado esta concepcion y la han ampliado enormemente.

Perl nace del mundo de Unix. Su creador lo diseno en 1987 inicialmente como un lenguajede script para fortalecer y simplificar ciertas tareas de administracion del sistema ope-rativo. De hecho, sus siglas12 significan algo ası como lenguaje practico de extraccion de

10En esta taxonomıa se ha colocado a JAVA acompanando a C y C++ aunque ya se ha escritosobre su curiosa arquitectura que lo diferencia de C y C++.

11script en ingles significa guion.12Practical Extraction Report Language.


informes. Desde entonces hasta nuestros dıas, entre otras muchas ampliaciones con las quela comunidad Open Source ha contribuido, Perl tiene interpretes para una buena variedadde sistemas operativos.

Figura 5.2: La arquitectura de Perl

La figura 5.2 muestra la arquitectura de Perl13. El script del programador, es traducidoa un codigo intermedio optimizado. Lo que se conoce genericamente con el nombre de((opcode)) (ya se ha comentado un caso particular con el ((byte code)) de JAVA). Un ((opcode))es una especie de codigo maquina14 que ((en lugar de ser interpretado por la maquina esinterpretado por una maquina virtual)).La diferencia de este proceso entre JAVA y Perl es que mientras que el ((byte code)) de JAVApierde el tiempo en el interprete, el ((opcode)) de Perl (por otra parte, de un nivel de abstrac-cion mucho mas alto) se combina con ((un gran numero de opcodes que se correspondencon herramientas disponibles en el nivel del usuario)). Esto explicarıa15 por que Perl esmucho mas rapido que JAVA.

Algunas comodidades de PerlUna de las ventajas de Perl es que existen una gran variedad de modulos o paquetes (loque en C se llamarıan librerıas). La inmensa mayorıa de ellos son contribuciones libresde programadores particulares y que vienen catalogados, caracterizados y documentadosen http://www.cpan.org desde donde se pueden descargar e instalar. Pero ademas de

13Esta figura y lo fundamental de esta seccion esta extraıdo de [4].14En informatica se llama codigo maquina al codigo binario que en ultima instancia interpretan

los microprocesadores15Siempre segun Sriram Srinivasan


ello, a partir de la version 5.6, Perl dispone de un potente Package Manager16 que es unaaplicacion cliente que puede, en el host local, buscar e instalar los paquetes, desde distintossitios de Internet. Estos se configuran de acuerdo al sistema que uno tiene y el packagemanager o ppm avisa si ya estan en la actual configuracion.

Con respecto a la facil portabilidad (concepto que ya se ha diferenciado de la capacidadde la independencia de plataforma), lo que el usuario final quiere y obtiene en Perl, es quepuede descargarse libremente el ultimo interprete (por ejemplo) para Linux y para Ms-Windows desde http://www.ActiveState.com y sus scripts corren, dando los mismos,resultados tanto en un sistema como en otro.

Concurrencia en PerlEsta es una cuestion importante para decidirse, porque en el sistema que atane a esta

discusion, como se ha dicho, sera necesario desarrollar un servidor concurrente. Aunque loque no se ha dicho, en su correspondiente seccion, es que parece que la implementacion dela concurrencia en JAVA es uno de sus puntos fuertes. Ası que en esta cuestion, vencerıala decision por JAVA en detrimento de Perl.Partiendo de que se puede desarrollar la concurrencia desde dos puntos de vista (a nivel deimplementacion) conviene echar un vistazo en cada uno de ellos como esta Perl de fuerte.Mas adelante convendra discutir y decidir cual de ambos metodos utilizar:

- Procesos o fork(): Parece ser que Perl soporta el estandar Unix de fork/execpara multiples procesos ası que en este sentido no parece tener gran inconveniente.Tanto en la documentacion de Perl como en otros manuales, aparece el uso de estafuncion con un aspecto practicamente calcado de C.

- Hilos: La literatura al respecto de la manera en que Perl implementa esta tecnicaparece estar quedando obsoleta. Las referencias en Internet, en la propia documen-tacion de Perl e incluso en las referencias bibliograficas (pagina 120) que cierraneste documento; arrojan la sombra de duda al decir que se trata de una versionexperimental. Perl incluye esta version experimental desde su version 5.005 pero locierto es que tras la inclusion de un nuevo modelo de implementacion en la version5.6 y los sucesivos ajustes, a dıa de hoy puede decirse que Perl soporta hilos. Y conla version 5.8.4 (la ultima a fecha de redaccion de esta pagina) Perl soporta hilos enWindows (cosa que en versiones anteriores emulaba enmascarando un fork() pordebajo).

Ejecutables con PerlSe ha apuntado como una desventaja de JAVA que no era inmediato crear archivos ejecu-tables para lanzar los programas, directamente a partir del codigo.Pues bien, en Perl existe la misma desventaja o todavıa mas, pues realmente, por lo querespecta a Larry Wall y al equipo oficial, cualquier cuestion que se diga acerca de esto, esuna mera promesa. A parte de meter el script en un codigo de C no parece haber muchasposibilidades.

16administrador de paquetes


Efectivamente, esta serıa una razon de peso para abandonar la posibilidad de Perl si nollegara, al rescate, una contribucion no exactamente de la Perl community no muy orto-doxa pero bastante mas potente de lo que a primera vista parece.Se trata de la aplicacion perl2exe. Como el propio nombre indica17, se trata de un progra-ma que genera archivos ejecutables partiendo de un script de Perl.Tras unas cuantas pruebas, sobre la potencia de perl2exe al generar ejecutables para Win-dows, no puede quedar ninguna duda. Tambien pueden generarse ejecutables para Linuxcon perl2exe pero esta posibilidad no se ha probado directamente puesto que no va a sernecesaria.Eso sı, hay que leer su documentacion y quiza anadir alguna lınea comentada al codigodel script que para el interprete oficial de Perl seran solo comentarios pero que perl2exeinterpretara como detalles especiales a cerca de las librerıas que se han usado, y podra en-lazarlas ((por sı mismo)) a la hora de generar el codigo. Hay que aclarar, que en realidad,perl2exe utiliza el interprete local de Perl para trabajar.Sobre la garantıa de perl2exe el lector puede juzgar por sı mismo. Se trata de una obrade la companıa canadiense IndigoSTAR. Una mediana empresa que da debido aguantardesde 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 elmismısimo ejercito de los Estados Unidos de America. Todo lo referente a este programapuede encontrarse en una modesta pagina web18 donde tambien hay informacion de otrosprogramas de IndigoSTAR.En lo relativo a las licencias, la version mas barata de perl2exe vale 50 dolares estadou-nidenses19. Pero existe una version shareware siempre disponible en la pagina web quetiene lo fundamental, no caduca y lo unico que supone es imprimir en ASCII20 un cartelde publicidad de IndigoSTAR. Ası que para lo que atane a estas paginas, es como si fueragratuito.

La decision final

Posiblemente el lector, tenga una premonicion de quien es el ganador de esta batalla.Aunque el autor tiene otro nivel de conocimiento que antes de llegar a este punto delcamino, conviene contemplar que hay otras alternativas y dedicarles algo de atencion:

- Tcl, Ruby y Python: Las propiedades de estos lenguajes son parecidas a las dePerl. En la mayorıa de referencias y de literatura sobre ellos aparecen grandes elogiosy similitudes con Perl. Por el momento la sensacion subjetiva del que se sumerje eneste oceano de referencias y comparativas es que son buenos competidores peroinferiores. Si no en facilidad de uso, al menos sı en ((sequito)). Los partidarios ylibres contribuyentes de Perl (o Perl Mongers) como se ha dicho antes, son uno delos principales alicientes de Perl y constituyen una de sus garantıas.

17Este juego de palabras es tıpico, en vez de ((Perl to exe)), en espanol ((Perl a exe)) (de executable)ponen un numero dos que en ingles se pronuncia igual que la preposicion ((to))

18http://www.indigostar.com1950$ son unos 40.68e, o sea, 6,768.74 pesetas (esto esta calculado segun divisas de junio de

2004)20Se refiere a que lo imprime por pantalla tras la ejecucion del programa


- PHP: Aunque representarıa una muy buena alternativa, PHP parece mas bien propiodel mundo del servicio web y las aplicaciones cliente/servidor correspondientes. Noes el caso, por lo tanto, de usarlo.

Por si queda alguna duda, conviene aclarar por que se ha decidido finalmente utilizar Perl:

1. Es independiente de la plataforma y facilmente portable.

2. Es mas rapido que JAVA segun se ha discutido.

3. Es compatible con MySQL.

4. Esta completamente libre de licencias.

5. Es facil de aprender y se parece al famoso C (ya se ha dicho –y ejemplificado– quepara el programador novato JAVA parece complicar un poco ciertas cosas).

6. Tiene librerıas graficas para desarrollar programas de ventanas portables con Linuxy con Windows.

7. Todas las librerıas pueden descargarse facilmente con su ppm21 y estan ampliamentedocumentadas.

5.1.2. Una aplicacion grafica en Perl para un entorno deventanas

Una vez tomada la decision mas pesada, resulta mucho mas sencillo avanzar hacia lasolucion porque el campo se ha acotado. Sin embargo, aparecen nuevas dudas.

Alternativas

Por definicion la biblioteca estandar de Perl en lo que se refiere a aplicaciones con ventanases Perl/Tk. Sin embargo su implementacion no es precisamente amigable. Se trata de laprimera aproximacion para resolver esto y esta prenada de varios aspectos:

- Las dolencias y debilidades del primer (lenguaje de script) Perl. Mas destinado (yestructuralmente pensado) para ser un lenguaje de shell que de entornos graficos.

- En cuanto a su parte grafica, Perl esta mas acostumbrado a ser complemento deCGI22 en paginas web que (otra vez) de entornos graficos.

El recurso mas sofisticado al respecto estarıa en el paquete para Visual Studio .NET.La principal desventaja es que no esta libre de licencias. Visual Perl tiene un entornografico donde pueden gozarse de una buena parte de las habituales ventajas de VisualStudio .NET:

21Perl Package Manager (se ha visto anteriormente)22Common Gateway Interface o estandar para programas pasarela externa que necesiten una

interfaz con servidores de informacion (como servidores HTTP)


Editor de codigo

Debugger grafico.

Una herramienta para simplificar las expresiones regulares.

Arbol de clases

Gestor del proyecto

Integracion de un kit de desarrollo para Perl.

Control del codigo fuente.

Aunque la informacion para resolver esta seccion esta extraıda de fundamentalmente dehttp://www.ActiveState.com y http://www.microsoft.com y no ha habido, por lo tan-to, practica directa sobre el mismo, la sospecha de que Visual Perl esta en la otra cara dela moneda de lo que Perl (y el mundo del Open Source) representa esta completamentejustificada. Segun eso, muchas de las caracterısticas que se han apuntado como bondadesde Perl estarıan en tela de juicio.Lo principal desde luego, sigue siendo la cuestion financiera, pero con todo lo dicho, lle-gados a este punto, parece estar mas cerca el retroceso hasta JAVA que el avance hastaVisual Perl

Lo que se ha venido calificando, desde una sensacion subjetiva del que se sumerge enInternet buscando sobre Perl, como el ((sequito)) de Perl, Los Perl Mongers o la comu-nidad Perl: Todo este fenomeno, se hace doblemente cierto cuando se particulariza en eldescubrimiento de Prima23. Prima es una biblioteca alternativa a Perl/Tk con todas susventajas y ninguna de sus debilidades.Es mas moderna, ha sido desarrollada en los ultimos anos en la Universidad de Copenhagepara cubrir las necesidades de un proyecto de biologıa. Tiene un constructor grafico quegenera un esqueleto de codigo de acuerdo al esquema que introduce el usuario. No tansofisticado como el que pueda tener Visual C++ pero desde su sencillez, bastante util.Ademas, tiene la ventaja de que solo interviene en un archivo y es facil comprobar lo queha hecho. Por lo que el programador mas novato no se ve ((en manos)) de trozos de codigoque no conoce, no entiende y ni siquiera mira.Por alguna razon las librerıas de Prima, aunque tambien estan documentadas en la http://www.cpan.org,son poco populares. Ninguno de los libros citados en la bibliografıa (revisar pagina 120), enefecto, hablan de Prima. Esto se debe seguramente a que Perl ya tiene una biblioteca graficaestandar y quiza sus partidarios mas radicales no quieren ninguna mas. Pero lo cierto es quePrima es muy potente, esta muy documentada y trae varios ejemplos que agilizan muchosu estudio. Todo lo referente a Prima puede encontrarse en http://www.prima.eu.org.

23Aunque el acronimo no es perfecto se refiere a Perl Graphic Toolkit o paquete de herramientasgraficas para Perl


Dentro de Prima (la EDA para las tablas)

Prima ofrece, intrınsecamente, una serie de modulos y funciones que facilitan muchasposibilidades graficas 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 aspectoresultante es (aunque mas tosco) parecido al que muestra Ms-Excel. En la documentacion(vease [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 mas importantees que con eso ya esta todo hecho. En efecto, el ejemplo del que se ha extraıdoesta seccion de codigo no es mucho mayor. Se ha definido una red en cuyas celdasaparecera mapeada la tabla.

$abstract_grid ? () : (’cells’, [ map { my $a = $_; [ map {"$a.$_"} 0 .. 300]} 0 .. 300])),


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 elprogramador maneje. Esto es un poco embarazoso teniendo en cuenta que el pasode los cambios en el contenido de la matriz, desde el entorno grafico a la memoria yviceversa habrıa que resolverlos ((a mano)).

Por eso conviene estudiar las distintas implementaciones de listas y visores de listasque trae Prima. Entre ellos, para listas de mas de una columna o matrices, existePrima::detailedlist (en Perl se caracteriza a un modulo dentro de una librerıa demodulos poniendo los dos puntos dos veces ((::))).La ventaja de la lista detallada (o detailed list) es que entre sus atributos hay unollamado items que se carga al principio con la tabla (que hay que construirla primero–eso sı– en un array convencional) y despues puede utilizarse a lo largo y ancho delprograma. En este ejemplo $miDetailedList-¿items :

$miDetailedList=$main->insert(DetailedList=>

columns=> $globalcolumnas,

name=> ’ListaGlobal’,

multiColumn=> 0,

origin=> [0,0],

size=> [$main->size],


headers=> [@matriz],

items=> $ref_items,

gridColor=> cl::Black,

onSort=> sub{},

onClick=> sub{},

onSelectItem=> sub{},

onKeyDown => sub{}

);

A la izquierda aparecen las propiedades y atributos. Los entornos sub{} son paraimplementar (dentro) la funcion correspondiente como reaccion a ese evento.NOTA: Recuerdese que en la seccion 4.3.1 (pagina 35) esta cuestion quedo pendiente:resolver la relacion recıproca entre lo que hay almacenado en la memoria sobre la tabla yla representacion grafica de esta. Pues bien, he aquı una solucion 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– informacion compatible con el entorno Office de Microsoft, por variasrazones entre las que estaban que la base de datos esta actualmente funcionando en Access


y no se migrara por completo, que los gestores trabajan con informes y estan habituadosa Excel, etc.En los capıtulos 3 y 4 aparecıa por activa y por pasiva una funcion en cada grafico que secomunicaba de alguna manera con este entorno y se concreto que cuanto menos, el clientedebıa entenderse con Ms-Excel y poder portar informacion con el. Se ha indicado y se hacaracterizado, pero no se ha resuelto.Es hora de afrontar, desde el terreno del lenguaje de programacion, las posibilidades queofrece Perl y el propio entorno de Microsoft para resolver esta cuestion aparentemente tantrivial.

Componentes de Miscrosoft

Repasando las librerıas de Perl, lo primero que salta a la vista es la librerıa Win32 ydentro de esta concretamente el modulo Win32::OLE. El paquete Win32 resuelve (comono 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 uti-lizan modulos especializados que se enlazan o utilizan dinamicamente en tiempo de ejecu-cion. Son por tanto modulos binarios cerrados (no trozos de codigo ni paquetes de librerıas,que serıa lo propio de la Orientacion a Objetos). Lo que esta idea promueve es la especia-lizacion masiva del software. Tambien facilita el diseno y permite usar software ajeno conpermiso del dueno pero sin poder modificarlo (superando tambien en esto a la filosofıa dela Orientacion a Objetos).En lo que a estas paginas atane, Microsoft ofrece un servicio de componentes llamadocomponentes COM+. ((Las clases administradas se generan con Microsoft R© Visual Studio.NET y despues se instalan en aplicaciones COM+ para obtener servicios COM+, comolas transacciones, la agrupacion de objetos y la semantica de actividad)), habitualmente25:Las clases y modulos en la librerıa Win32 de Perl, estan desarrolladas por socios activos dela 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 licenciapublica26 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 esta instalado");

} if $@;

unless (defined $ex)

24API es el acronimo de ((Interfaz para programas de aplicacion)) (Application Program Interfa-ce), ası que quiza deberıa decirse mas bien utilizar el API de Win32

25Mas informacion en http://www.Microsoft.com26Todo lo relativo a GPL se ha dado por sentado en este trabajo, el lector profano puede infor-

marse en http://www.fsf.com


{

$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 codigo aparece como la instancia de una clase (hablandode la variable ((hoja))), en realidad es un manejador de un componente Excel quetiene activa esa hoja (o tabla).Con un resultado muy potente (por lo capaz) se puede interactuar de utilizando estalibrerıa con Excel. La librerıa Win32 incluye metodos para hacer esto y lo cierto esque resulta bastante facil e inmediato, como el ejemplo muestra.

Las desventajas por las que finalmente esta tecnica no se ha elegido son las siguientes:

- Es lento, sobretodo para hojas de gran tamano. Crea dos capas, en el uso delos recursos, en tiempo de ejecucion y lastra al proceso principal (que en estecaso serıa la aplicacion cliente y no la aplicacion de Excel).

- Requiere que el usuario tenga instalado y bien configurado el paquete corres-pondiente de Microsoft, aunque esto no es complicado, para un usuario nova-to27 puede ser problematico.

- Pero sin duda, lo peor de todo, es que no es una alternativa portable. Laaplicacion 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 queel servidor corre sobre una maquina Linux o Unix que puede ser incluso lamisma.

Acceso a archivos *.xls

En lo que a este sistema se refiere, es suficiente con poder incorporar informaciontraıda desde Excel de la manera que sea, basta con leer los propios archivos28 ygenerar archivos excel partiendo de una tabla en memoria. La solucion de utilizarcomponentes, aunque muy espectacular y quiza recomendable para otras necesidadeses –ademas de las desventajas que se han mencionado– demasiado sofisticada paralas necesidades que hace falta cubrir en este caso.En una nueva busqueda por http://www.cpan.org puede descubrirse el paquete de

27Este perfil se ha caracterizado en la seccion 4.4.2 en la pagina 40 siguiendo los pasos dePressman en [9]

28Los archivos que maneja Excel son siempre nombrados con una extension xls (y de ahı el tıtulode esta seccion)


librerıas ((Spreadsheet)). Dentro de ((Spreadsheet)) hay varias posibilidades, se tratade crear una manera sencilla de leer archivos desde Excel. Para este ejemplo se hautilizado una de las formas mas 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 instruccion push es necesario para simplificar el almacenamientoen una matriz29. La variable ((data)) serıa un vector en el ejemplo, y ((GlobalItems))una matriz. Para saber el numero de columnas bastarıa con poner en otra variableel 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 pathdonde este la tabla de Excel (por ejemplo ((C:\tablas\agenda.xls))).Esta librerıa nos permite:

Un acceso sencillo a la informacion.

Funciona igual en Linux y en Windows.

Es rapido y solo hace falta llamarla una vez, frente a los componentes COMque necesitan utilizar el procesador y la memoria en paralelo a la aplicacionque los invoca.

5.1.4. Concurrencia: ¿Hilos o procesos?

Hasta ahora, en capıtulos anteriores, se ha hablado de la concurrencia que nece-sita el proceso servidor para atender las peticiones del cliente. Lo que no se ha dichoen ningun momento es como resolverlo.Partiendo de que existen estas dos maneras de interpretar la idea de la concurrenciaen el nivel de la implementacion, esta discusion tiene interes practico para este caso, enal menos, estos dos frentes:

¿El ejemplo que se ha descrito es propio de una de las dos filosofıas?

En concreto con Perl ¿es mas recomendable alguna de las dos?

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


Hilos y/o procesos en Perl

Esta cuestion, de gran interes para los afinionados a Perl, no tiene un gran eco enla literatura. Lo mas interesante ya se ha comentado en 5.1.1 (ver pagina 50). Existenintervenciones al respecto las distintas conferencias de la Open Source que pueden visitarseen 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 incluyelas trasparencias de su exposicion) resuelve las dudas acerca de las prestaciones entre unoy otro modo, dentro de Perl.Lo unico que se puede anadir, casi anecdoticamente, es la introduccion con la que el propioLarry Wall abre el capıtulo correspondiente en [1]:

((imagina coger una receta de un libro de cocina y convertirla en algo que variasdocenas de cocineros puedan guisar al mismo tiempo, puedes encontrar dos aproxi-maciones:Una, darle a cada cocinero una cocina privada y completarla con su propio apro-visionamiento de ingredientes, materiales y utiles. Para recetas que son facilmentedividibles en partes es facil y tambien para comidas que pueden ser trasportadas decocina a cocina, esta aproximacion funciona bien porque mantiene a cada cocinerofuera de las otras cocinas.Alternativamente tu puedes poner a los cocineros en una cocina y dejarles trabajar(...) esto puede ser peligroso, especialmente cuando los cuchillos de cocina empiezana volar)).

El ejemplo sirve para ejemplificar ambos casos30, pero lo curioso es que la imagen de lametafora no puede ser mas desafortunada (o quiza se penso ası a proposito ¿alguien puedeimaginar un restaurante funcionando de la primera manera?). Si ası es como son los hilosy los procesos en Perl, la opcion de utilizar multiples procesos quedarıa descartada.

Por que usar hilos

Olvidando lo que respecta a Perl en concreto, la aplicacion servidor que se ha visto enlas fases anteriores es tıpica de un diseno con hilos.

- Cuando no hay nuevas consultas en el socket es un buen momento para que elhilo quede bloqueado y pueda seguir otro. Suponiendo un caso tıpico de diez hilosatendiendo peticiones de diferentes clientes, los cambios de hilo seran rapidos y nopuede perderse tiempo en ello. En definitiva, por ser ((peticiones que conducen abloqueos)) es preferible utilizar hilos.

- Puede ser necesario compartir, al menos entre el hilo principal y cada uno de loshilos dedicados, cierta informacion en forma de variables globales, lo cual sera muchomas facil con hilos que no con procesos.

- En el futuro pueden anadirsele propiedades al hilo principal para que permita in-formar, al administrador del sistema, de los diferentes clientes que hay conectados

30Se ha incluıdo tambien para que un lector mas profano pudiera comprender esta seccion


y todo tipo de estadısticas e ficheros de log sobre ellos. Entendiendo que, al fin y alcabo, no es mas que un script de Perl, esta posibilidad es poco costosa y puede valerla pena en, sin duda, con una implementacion basada hilos sera menos complicadaa la hora de modificar.

5.2. Pruebas previas

Finalmente, como se ha dicho al principio del capıtulo, conviene probar algunas li-brerıas basicas de Perl, para asegurar su funcionamiento y ganar confianza con ellas antesde utilizarlas de manera sistematica. Anteriormente, se ha mostrado ejemplos de codigoformando parte de una discusion entre varias dos posibilidades, ahora se hara, aunque nohaya mas de una posibilidad, por lo decisivas que son estas librerıas y aprender a utilizarlascorrectamente.

5.2.1. Acceso a Bases de Datos con Perl

Perl tiene varias librerıas que se ocupan de esta cuestion. Lo interesante en este casoes resolver la comunicacion con MySQL. Para conectarse con exito a MySQL desde unscript hay que tener un login y un password habiles en MySQL (esto es igual que si seaccede por consola) y ademas hay que conocer tres cosas, a saber:

El nombre de la maquina donde esta montada la base de datos de MySQL (puedeser la misma donde corra el script o no).

El nombre de la base de datos al cual hay que acceder. Habitualmente MySQL cedeuna 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 unaconexion ((manual)) por el. Esta guardado siempre en /var/lib/mysql/mysql.sock.

Una secuencia de conexion valida 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’);

}


En este ejemplo se ha hecho la conexion y despues una prueba utilizando unafuncion (dentro del if ) que mostrarıa las bases de datos a las que el usuario tieneacceso.El parametro host admite tanto una direccion de IP (147.156.16.31) como un nombrevalido de maquina (slabii.uv.es).

5.2.2. Sockets en Perl

Ademas de probar aquı las librerıas de sockets de Perl (cosa que no tiene mascomplicacion que estudiarse la documentacion al respecto) serıa interesante resolverla cuestion de la conexion inicial cliente servidor.El lector puede recordar (o combrobar) que en la seccion 3.3.2 (pagina 24) se ha ca-racterizado este problema y se resolvio –a un primer nivel– en la fase de postproceso(del diseno), generando (en la pagina 36) la tabla 4.5.Se trata de un primer dialogo informativo entre cliente y servidor que permita esta-blecer una conexion entre ellos.Lo que hay que resolver, concretamente, es que el servidor pueda tener permanen-temente un socket a la escucha y que la negociacion inicial de una sesion entre elcliente y el servidor no limite al servidor la capacidad de atender mas peticiones. Esuna situacion muy habitual, ası que no debe ser causante de ningun trastorno: elservidor ofrecera siempre un mismo socket de numero conocido, por el que entraranlas nuevas peticiones y a las que dedicara solo unos segundos cada vez.En Perl, una secuencia valida 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 funcion ((accept)) de Perl, es bloqueante, es decir, el servidor queda suspendidoaquı mientras ningun cliente llega. Posteriormente, a esta instruccion (ya ha llegadoun cliente) el servidor podra comunicarse con aquel haciendo:

sysread(ClienteActual,$datosentrantes,255);

syswrite(ClienteActual,$datossalientes,255);


La conexion es bidireccional, de manera que si se cuida que el ritmo del dialogosea 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 direccion del servidor y la varia-ble ((portsocket)) (cuyo contenido se ha copiado aquı de ((port server))) se referira alsocket de numero conocido que el servidor tiene disponible siempre.Resulta evidente que, en Perl, la variable $! (todas las variables comienzan por $)recoge el ultimo error producido.Para no abrumar mucho mas con sesgos de codigo, se resolvera la cuestion del bis abis (comentado al principio de esta seccion) solo en la parte del cliente. Serıa anadiral 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";


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 funcion llamada bisabis quecubriera lo especificado en la tabla 4.5 antes mencionada.

Capıtulo 6

Trabajos futuros: Personal DigitalAssistant

6.1. Introduccion

Para ser completamente fiel a la realidad, en el capıtulo primero, no se ha men-cionado 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 objetivoinicial pero, teniendo en cuenta las particularidades que se han descrito en el capıtu-lo 1o, resulta evidente que proporcionar la posibilidad de que la aplicacion clientepueda tambien correr sobre un PDA ofrecera un gran servicio a los usuarios finalesy al sistema en general:

- El usuario puede modificar en el acto los datos que le interesen. No necesitapara una operacion tan sencilla, disponer de un ordenador y de un acceso aInternet.

- El servidor puede verse liberado de cierta carga porque si los usuarios solodisponen de un entorno en ordenador personal, la tendencia es conectarse a labase de datos a unas horas determinadas (por ejemplo, por la noche al acabarla jornada). En cambio, el PDA les ofrece la posibilidad de llevar consigo unaterminal remota.

El objetivo de este capıtulo es analizar las posibilidades de portar la parte clientede la aplicacion (interfaz grafica) a un PDA. Allanando, de esta manera, las dudasque puedan surgir en la organizacion y dando una respuesta cuyo acabado satisgafaa unos y otros, y permita, a quienes tengan que tomar esta decision, si se invierte ono el dinero necesario.

64

CAPITULO 6. TRABAJOS FUTUROS: PDA

6.2. Historia reciente

Antes de aparecer el PDA, existıa el mercado variopinto de la agenda electronica.Sin seguir apenas unos parametros comunes, con disenos muy diversos, las distintascompanıas ofrecıan sus repertorios de modelos que podıan variar desde calculadorasdisfrazadas de algo mas hasta artefactos algo mas espectaculares. A pesar de todo,el uso de estos aparatos y su comercio en general, siempre tuvo mas pasado quefuturo, pues el perfil de su destinatario estaba mas tentado por los avances en losordenadores personales que por las virguerıas de estos inventos.El termino Personal Digital Assistant (o PDA) fue acunado en 1992 por el empresa-rio americano John Sculley1 para dar nombre al producto Apple Newton2. Se tratabade un PDA pionero que, aunque se adelanto a su epoca, tenıa un precio prohibitivoy no resolvıa satisfactoriamente la cuestion del reconocimiento de caracteres.Cerca del ano 2000 el mercado de el PDA dio un primer salto y gano una buena basede sus actuales entusiastas y usuarios. Los PDA de 2000 estaban muy lejos de los dehoy, aunque ya empezaban a resolver una parte importante de tareas: sincronizacioncon datos desde el PC, compatibilidad con una buena variedad de documentos in-formaticos, agenda, calculadora, reloj, notas, portapapeles, contactos, escritura, etc.Con la llegada de las ultimas tecnologıas para moviles y la posibilidad de incluirnuevas posibilidades a los PDAs, este invento se ha hecho muy popular. Las nuevasprestaciones (recursos inalambricos, autonomıa de la baterıa, resolucion de pantalla,audio y vıdeo, etc.) le han hecho al PDA tan novedoso como en su dıa lo fue elordanador portatil: bonitos, potentes, portatiles y cada vez mas baratos. El compra-dor y el posible comprador acaban viendo estos inventos mas interesantes que susaparatosos ordenadores de sobremesa que no mueven nunca. Salvando las distancias,porque el uso del portatil (que no es mas que un PC superintegrado) es diferenteque el del PDA. Al menos de momento.

6.3. Posibles soluciones

Antes de estudiar las alternativas posibles de portar a PDA la aplicacion clienteque se ha desarrollado conviene apuntar algunos datos mas sobre el PDA.De entrada, aunque el nombre correcto (por lo generico) es PDA quiza al lector lesuenen mas otros nombres para referirse a estos equipos. Aunque las habilidades quela tecnologıa del hardware va anadiendo a estos equipos son cada vez mayores, labatalla 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 ponersede acuerdo las grandes companıas fabricantes.

1John Sculley: Se le nombro presidente de PepsiCo y en 1983 se hizo cargo de la direcciongeneral de Apple.

2Oficialmente fue llamado Message Pad


Ademas, en el mundo del PDA, arquitectura (fısica) y complemento software, sue-len ir unidos desde que el fabricante lo lleva a las tiendas. Como lo que quieren losfabricantes de hardware es vender mucho y a lo que mas acostumbrado el usuarioes al entorno de Microsoft Windows, otra vez, ha ocurrido como con el PC (y comocon otras marcas ocurrio en otros productos tecnologicos): el gigante estadouniden-se dirigido por el afamado Bill Gates y aconsejado por un intelegente equipo deestrategas, parece ir camino de monopolizar el mercado del PDA implantando enun porcentaje cada vez mas amplio de los PDA que llegan al mercado su WindowsCE (version de windows para PDA). Aunque (como siempre) hay otras marcas, sepodrıa hablar de un matrimonio entre HP y Microsoft parecido (aunque no tan for-zoso) al que hubo con el PC entre IBM y Microsoft.De todas maneras, esta batalla no esta ganada ni perdida todavıa, pues las Palmllevan mas tiempo en el mercado y tienen muchas ventajas.En estos terminos 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 programadopara la parte cliente en PC.

Ventajas:

+ Las Palm son los dispositivos mas baratos dentro del mundo del PDA.

+ La parte cliente –y el sistema en general– esta pensada para cargar el sistemalo menos posible. Esto da esperanzas de que pudiera desarrollarse una versionPalm con exito.


+ Las Palm parecen ser, por el momento, mas robustas y potentes que los Po-cket PC, aunque es conocida la habilidad de Microsoft para poner parches ensus popios remiendos. Y tambien como la consolidacion del hardware acabaequiparando en ocasiones al software lento y al mas rapido.

Desventajas:

– Supone un proceso relativamente largo, aprender a desarrollar sobre este dis-positivo, redisenar el sofware para las posibilidades de Palm (tengase en cuentaque Perl acostumbra a ciertas licencias con el uso de la memoria y el manejode los strings3 ni si quiera comunes en muchos lenguajes de alto nivel).

– El aspecto del resultado serıa muy diferente a la version PC, y se perderıanciertas funcionalidades por el camino.

– El proceso de mantenimiento se bifurcarıa y cada nueva funcion que se qui-siera anadir deberıa ser programada por separado en la version PC y en laversion Palm (esta desventaja lleva a pensar que, aunque se hubiera previstocon antelacion el anadido del PDA, ciertas complicaciones hubieran sido lasmismas).

– En general, multiplica por dos los problemas: disenar por separado, programarpor separado, probar por separado, etc. Demasiado trabajo anadido para tanpoco rendimiento, al fin y al cabo no se trata de una necesidad de primerorden.

Esta alternativa no es muy interesante en el terreno practico, solo vale la pena si seesta dispuesto a iniciar este camino con todas sus consecuencias.

6.3.2. Linux en PDA

Aunque parezca sorprendente –el conocido grupo nipon– Sharp lleva mas de unano ofreciendo una gama de PDAs que parecen poder cumplir esta mision.En lo que atane a estas paginas, es curioso que alla por febrero de 2002, KevinBingham –miembro del O’Reilly Book Support4– respondıa con escepticismo, en unforo, ante la pregunta de que Perl pudiera correr en un Palm. Citandolo textual-mente: ((de alguna manera es como intentar que Perl corriera en una Game Boy(...) Perl no es un pequeno interprete, seguramente ocuparıa toda la memoria deuna Palm en un momento))En este mismo mensaje, el propio Kevin Bingham auspiciaba que las –por aquelentonces– nuevas iPAQ donde corrıa una version de Linux era el unico horizonteposible para Perl dentro de los PDA.

3Cadenas de texto4Una especie de ((atencion al cliente)) que ofrece el grupo de O’Reilly


Pues efectivamente, Sharp ha seguido este camino. En principio parece ser que estosPDAs solo soportan C como lenguaje de programacion, pero recuerdese que –endefinitiva– Perl acaba siendo en ultima instancia C.La instalacion de Perl en las primeras Sharp Zaurus PDA SL-5500 y SL-5600 noparece un proceso sencillo. Pero antes de profundizar en el y comenzar a estudiarque bibliotecas de Perl soporta esta alternativa y cuales no, conviene decir una cosaimportante: La Sharp Zaurus PDA SL-6000 actual heredera de los modelos SL-5500y SL-5600 vale5 700$. Por algo mas de dinero se puede adquirir un buen ordenadorportatil y con bastante menos un ordenador de sobremesa de segunda mano quecubra estos intereses.Desde luego esta posibilidad es tan interesante como resplandeciente, pero a partede la traba economica conviene ver algo mas habitual. No se ha hecho suficientehincapie, pero en lo que a mercado se refiere, la distancia que separa a los PocketPC 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 grafica del cliente, enla seccion 5.1.2, se ha visto la posibilidad de utilizar Visual Studio .NET frente aun desarrollo con Perl y Perl/Tk demasiado denso. Aunque parecıa que el descubri-miento de las bibliotecas Prima hundıan esta posibilidad de manera definitiva, porsegunda vez es necesario –y esta vez con mayor profundidad– estudiar las posibili-dades que ofrece Visual Studio .NET en general y en concreto para el dilema que seviene discutiendo.

Preambulo

Microsoft Visual Studio .NET es un entorno creado para ser la herramientadefinitiva del programador. Los desarrolladores pueden usar Visual Studio .NET

para:

∗ Construir la proxima generacion de Internet.

∗ Crear aplicaciones potentes de manera rapida y efectiva.

∗ Expanderse a cualquier plataforma o dispositivo.

5Conservando el cambio utilizado en la pagina 51 esto equivale a 569.52e, que son 94760,15antiguas pesetas


La idea es ser para la proxima decada, lo que para los noventa fue el inicio de VisualBasic 1.0. Para conseguir esto, puede intuirse que Visual Studio .NET trabaja sobredos ejes fundamentales:

∗ Proporcionar al desarrollador las mas sofisticadas herramientas graficas inten-tando estar presente en todas las fases de desarrollo: el editor, la herramientade depuracion, una aplicacion grafica para el diseno, etc. Todo organicamenteentrelazado –en teorıa– para liberar al usuario de la cantidad mayor de trabajoposible.

∗ Soportar cuantas mas posibilidades mejor. Existen paquetes –aquı llamadosplugins para los lenguajes mas ((de moda))6. Lo que han creado es el CLR7: unaespecie de JAVA para cualquier lenguaje de programacion que las capas inferiores deVisual Studio .NET traducen. Para ello, es necesario un profundo diseno por capas(puede echarsele un vistazo en el cuadro 6.1).

System.Web System.WinForms

Services UI Design ComponentModelDescription HtmlControlsDiscovery WebControlsProtocols

System.Drawing

Caching Security Drawing 2D Printing

Configuration SessionState Imaging Text

System.Data System.Xml

ADO.NET SqlClient XmlDocument Serialization

Design Xslt/XPath Reader/Writers

System

Collections IO Configuration Runtime

Security Net ServiceProcess InteropServices

Text Reflection Diagnostics Remoting

Globalization Resources Threading Serialization

Cuadro 6.1: Esqueleto .NET

Antes de comenzar a estudiar que herramientas incluye este entorno de programacionpara desarrollar aplicaciones para Pocket PC es importante tener en cuenta dichas

6Dicho de otra manera: Microsoft pretende monopolizar tambien el mercado de los lenguajesde programacion.

7Common Language Runtime o –en espanol– lenguaje comun para tiempo de ejecucion


herramientas son anadidos posteriores al entorno Visual Studio .NET en sı mismo.Al menos en cuanto a su lanzamiento al mercado. Bien mirado, este tipo de mante-nimiento representa, de entrada, un punto debil del diseno en cuanto a lo expuestoa continuacion.

Microsoft .NET para dispositivos

En efecto, con la aparicion del Pocket PC, habil como siempre y –tambien comosiempre– desde su posicion de fuerza, Microsoft ha creado un ((esqueleto compacto))partiendo del diseno 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 mas avanzado reconocera que en la li-

teratura 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 al-gunas de las funcionalidades anteriores y otras no, puesto que los Pocket PC soninferiores PCs. Veanse cuales son unos y cuales son otros, y estudiese el cuadro 6.1en comparacion con el 6.2.Caracterısticas de .NET para dispositivos comunes del CLR:

System.Web System.WinForms

Services Design ComponentModelDescriptionDiscoveryProtocols

System.Drawing

Security Drawing 2D

Text

System.Data System.Xml

ADO.NET SqlClient XmlDocument

SqlServerCE Reader/Writers

System

Collections IO

Security Net

Text Reflection Diagnostics

Globalization Resources Threading

Cuadro 6.2: Esqueleto compacto de .NET

∗ Excepciones.


∗ Constructores y finalizadores.

∗ Depuracion remota.

∗ Dominios de aplicacion, esto es, una aplicacion puede iniciar otro dominio deaplicacion dentro del mismo proceso.

∗ Servicio P/Invoke (o invocacion de plataforma) es la tecnologıa que en .NETpermite usar el codigo en CLR para hacer llamadas a librerıas dinamicas DLL8

no gestionadas a priori, incluyendo el API de Win32.

Propiedades de Studio .NET que su version para dispositivos no soporta:

∗ Reflection emit: Herramienta para ensamblar el codigo ejecutable final.

∗ Remoting (un mecanismo para invocar otras aplicaciones mas alla de sus res-pectivos dominios).

∗ Serializacion9.

∗ Impresion.

∗ Interoperabilidad con COM.

∗ Funcionalidad del lado del servidor.

∗ XPath/XSLT10

Desde luego, es dificil comprender toda esta palabrerıa sin adentrarse en la practi-ca de Visual Studio .NET. Las metas con las que ha sido disenado Visual Studio.NET Compact Framework o Visual Studio .NET para dispositivos ayudan a ver lasposibilidades que ofrece esta tecnologıa:

∗ Un CLR pequeno y portatil para dispositivos, permitiendo el uso de VisualBasic y C#.

∗ Sacar provecho del modelo anterior de Visual Studio .NET y lanzar los ejecu-tables y sus librerıas dinamicas11. Depurar con Visual Studio .NET.

8Dynamic Link Library o librerıas dinamicamente enlazadas9((La serializacion es el proceso de almacenamiento del estado de una instancia de objeto en

un medio de almacenamiento. Durante este proceso, los campos publicos y privados del objeto y elnombre de la clase, incluidos el ensamblador que contiene la clase, se convierten en una secuenciade bytes que, posteriormente, se escribira en una secuencia de datos.))

10XSL (Extensible Style Language) es una especificacion desarrollada para aplicar formato a losdocumentos XML de forma estandarizada, despues se decidio ((sacar)) fuera de la especificacion XSLel lenguaje de transformacion y desarrollarlo como una especificacion ((independiente)) a la que sedenomino XSLT. A esta nueva especificacion se le denomino XPath XPath(XML Path Language).

11Esto puede ser una alternativa a lo discutido en la seccion 5.1.1


∗ 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 hilosnativos ayudandose de P/Invoke.

SDE y MIT

Dentro de Visual Studio .NET existen dos plataformas para desarrollar aplica-ciones en dispositivos pequenos. La primera, MIT o Mobile Internet Toolkit (herra-mienta para Internet desde moviles): soluciona la parte del acceso por navegador. En

Figura 6.1: Plataforma de desarrollo MIT (Mobile Internet Toolkit) para VisualStudio .NET

cuanto a la segunda: SDE significa extensiones para dispositivos pequenos o SmartDevice Extensions. Es la que se ocupa tanto del procesamiento local.

12No se ha descrito anteriormente: XML es un eXtensible Meta Language, un lenguaje de marcaque se utiliza para Internet y otras aplicaciones. Su ventaja es que separa la informacion de supresentacion, permitiendo modificar ambas independientemente. Es muy potente, esta muy demoda y el lenguaje HTML tradicional para hacer paginas web se podrıa concebir como un casoparticular de XML


Figura 6.2: Plataforma de desarrollo SDE (Smart Device Extensions) para VisualStudio .NET

MITVentajas:

+ Soporta un buen espectro de dispositivos.

+ Maneja las diferencias entre dispositivos.

Desventajas:

– Solo acepta acceso por navegador.

– No aprovecha la posibilidad del procesamiento local.

– La interfaz de usuario es limitada.

SDEVentajas:

+ Funciona tanto en lınea como fuera de linea.

+ Aprovecha completamente las ventajas de los Pocket PC.

+ Tiene una excelente integracion con el SQL Server CE.


+ Aprvecha las ventajas del procesamiento local: graficas, multimedia, etc.

Desventajas:

– Soporta una gama de dispositivos muy pequena.

Ademas, parece ser que la integracion de SDE en el entorno de Visual Studio .NETincorpora un emulador que incluye la funcionalidad completa de Pocket PC 2002,tambien incluye otras posibilidades:

∗ Compila la aplicacion 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 contruccion de:

Aplicaciones para Pocket PC.

Biblioteca de clases para Pocket PC.

Biblioteca de controles para Pocket PC.

Aplicaciones para Windows CE .NET.

Aplicaciones para telefonos moviles.

∗ Existe una opcion, en el emulador, para variar las caracterısticas del dispositivo(resolucion, color, memoria, etc).

6.4. Conclusiones

Teniendo en cuenta que esta discusion no es en general –aunque tiene aspectosgenerales y es un problema habitual desde que aparecio el PDA– sino que mas biense trata de un estudio concreto para este caso: sirva esta sıntesis para concentrarlos puntos mas fuertes y mas debiles de unas y otras posibilidades. Tambien paracoger un punto de vista de conjunto. Analizando conjuntamente con la tabla 6.3,podemos resumir que:A saber:

Como se ha dicho, la posibilidad mas inmediata es ponerse a redisenar el codigoy volver a desarrollar una version que pueda correr en una Palm. Este procesono es trivial y tiene el problema de que aparecen dos frentes de mantenimiento.Cualquier cosa que se pretenda anadir a partir de tomar esta decision, sehara por duplicado, por un lado la version PC y por otro la version Palm.Tiene el aliciente de que los dispositivos son baratos y que la aplicacion clientetal y como se ha creado, liberada por el servidor de la mayor parte del trabajo,no anadira mas complicaciones.


Alternativas para

migrar a PDA

VENTAJAS DESVENTAJAS

+ El dispositivo es barato – Rediseno y reconstruccionde aplicacion cliente necesa-rios.

Palm + La conversion es posible, laaplicacion cliente no tiene mu-cha carga

– Duplica el mantenimiento apartir de ahora

– Mucho trabajo para obenerpoca satisfaccion- Aprender entorno diferente- Aspecto resultante diferentea la version PC

+ Potencia – Instalacion de Perl no tri-vial.

Linux + No rediseno y poca adapta-cion.

– Solo disponible en modelosde Sharp Zaurus muy caros

MIT +Soportadopor muchosdispositivos.

Dispositivos en

ambos casos:

– Desaprovecha potencia local(solo por navegador).

Pocket PC +Buenas pres-taciones.

– Rediseno y reconstruiccionnecesarios.

Ambos casos: El software dedesarrollo no estara libre de li-cencias y es caro

SDE + Cierta fasepara adaptarlopero no redi-seno

+ No tan bara-to como Palmpero precio ra-zonable.

– Soportado por pocos dispo-sitivos

+ Aprovechapotencia local.

+ EntornoWindos CEcomo Windows

– Plugin de Active State pa-ra .NET CF no probado en lapractica

Cuadro 6.3: Sıntesis del estudio y discusion sobre PDA

Se ha visto que existen unos modelos de Sharp Zaurus que soportan Linux y porlo tanto es posible instalar una version de Perl. No tendrıa los inconvenientescitados antes pero se trata de unos dispositivos demasiado caros. Por otraparte la instalacion de Perl no parece facil, se trata de una version reducidade Linux y el problema es aun tema de debate en ciertos foros de discusion.

Por ultimo se ha visto la tecnologıa que Microsoft esta incorporando en susnuevas versiones de Visual Studio .NET : se trata de una serie de herramientaspara crear aplicaciones para Pocket PC. Se ha acotado el esqueleto estructu-ral del .NET para PC y se ha logrado un paquete de herramientas bastante


potente. Las ventajas que tiene es que los dispositivos a los que atane tienenun precio bastante razonable para la cantidad de prestaciones que ofrecen. Yno harıa falta un rediseno completo, solo algunas adaptaciones en el peor delos casos.El principal problema de esta posibilidad es que el software de desarrollo noesta libre de licencias. Por otra parte la vıa mas interesante dentro de .NETla representa la plataforma SDE que no esta disponible en tantos dispositivos.

6.5. Referencias

Se ha separado, solo en este capıtulo, el ındice bibliografico de la seccion generalde bibliografıa en la pagina 120. Principalmente por no sobrecargar aquella y –almismo tiempo– porque en este capıtulo la bibliografıa cumple otro papel.

Lo mas llamativo de toda esta cuestion, es la poca cantidad de textos de caracterdivulgativo que existen aun sobre estos artefactos. Es mas facil encontrar, en algunforo, una discusion entre usuarios avanzados de alguna cuestion de ultima instancia,que un texto general acerca de el PDA. De hecho, el capıtulo en sı, es mas bien uncompendio de la cultura que actualmente emana de Internet sobre PDA:

En http://www.desarrolloweb.com puede encontrarse un artıculo escritopor un consultor de marketing acerca de los posibles sistemas operativos dePDA y su discusion.

Realmente, http://enciclopedia.us.es es una autentica enciclopedia webfuertemente autorreferenciada y lo bastante actualizada en cierta termino-logıa tecnologica sin cuya ayuda ciertos textos resultan incomprensibles o algocojos. Por desgracia, se explaya lo justo en sus definiciones.

Lo mas importante acerca de la famosa Sharp Zaurus puede encontrarse en lapagina del fabricante: http://www.sharpusa.com/zaurus/ el precio, aun-que no suele aparecer a priori en las paginas de Sharp se puede obtener ensitios web de distribuidoras de toda ındole.En cuanto a su relacion con Perl la informacion mas interesante esta enforma de artıculos y cartas tanto en http://letters.oreilly.com/ como enhttp://perlmonks.thepen.com13

Acerca de Visual Studio .NET la informacion mas tecnica se encuentra enhttp://www.microsoft.com y no hay que dejar de ver las traducciones enhttp://www.microsoft.com/latam aunque no suelen ser completas y no

13Ya se ha hablado de los Perl Mongers y en cuanto a O’Reilly, puede encontrarse mas informacionen la bibligrafıa de la pagina 121 de este mismo documento.


se actualizan con mucha frecuencia.Sobre la relacion entre .NET y Perl, la informacion mas certera proviene otravez de http://www.ActiveState.com y de un enlace que incluye esta haciaun tutorial muy breve en http://wdvl.internet.com/Reviews.Para la parte final, sobre el desarrollo para Pocket PC ha sido de gran ayudauna presentacion escrita por un consultor informatico de Mexico que, avaladopor el certificado profesional de Microsoft ha ((colaborado como expositor enlos congresos nacionales e internacionales que ha organizado la Universidad delValle de Atemajac (UNIVA) y en diversos eventos organizados o patrocinadospor Microsoft)); Segun su propia web, situada en http://www.nazul.net ydesde la que puede descargarse la presentacion antedicha.

Capıtulo 7

Pruebas y conclusiones

El objetivo de este capıtulo es probar tanto la aplicacion cliente que se ha desa-rrollado como el proceso servidor. Demostrar su funcionalidad y someter a crıticasu eficiencia.Lo mas interesante es lo segundo, puesto que la funcionalidad no se puede trasladaral papel de una manera completamente fiel y tampoco sera ası como se evalue, loque sı que vale la pena hacer mas hincapie es en el comportamiento y aspecto paraLinux y para Windows: Recuerdese que la portabilidad de la aplicacion cliente estotal (tambien la del servidor pero este funciona por consola) .Secundariamente, otro tipo de lector podra encontrar este capıtulo como un manualpara utilizar la aplicacion cliente.

7.1. Primeras pruebas

7.1.1. Inicio

Al iniciar la aplicacion aparece un cuadro dialogo, mostrado en la figura 7.1, paraintroducir un login y un password. Se trata de un usuario y una contrasena que seenviaran a MySQL, de manera que tiene que ser allı donde se haya registrado a esteusuario.Existen dos opciones, tambien puede trabajarse sin conexion, por ejemplo, si seesta gastando red telefonica, puede editarse una tabla off-line para subirla a poste-riori, y estar conectado el menor tiempo posible.La figura 7.2 muestra la ventana de aviso si se pulsa ((Mas tarde)) en su predecesora.Aunque pueda parecer tonto, es recomendable avisar de estos movimientos al usua-rio menos instruido, y el mas rapido pronto se acostumbrara a iniciar con estos dosavisos.

En el caso de que se intente la conexion pero esta falle por alguna razon, laaplicacion avisa con una ventana como la de la figura 7.3. Igual a la anterior pero

78

CAPITULO 7. PRUEBAS Y CONCLUSIONES

Figura 7.1: Peticion de login y password

con un aviso de error. Es interesante no enmascarar todo el proceso de cara alusuario final, los avisos en ingles y el tıtulo MySQL logran, secundariamente, educaral usuario en el proceso real que esta ocurriendo cuando se conecta.La figura 7.3 es un ejemplo de esta situacion, concretamente el error es desconocidoporque el cliente no ha conseguido ni siquiera acceder al servidor. En otro caso, larespuesta retornada por MySQL es copiada en esta ventana.

Figura 7.2: Aviso de inicio sin conexion por peticion de usuario

Las razones por las que puede fallar este intento son varias, sirva de ayuda elsiguiente arbol:

1. El usuario solo quiere utilizar el editor de tablas, de momento, pulsa ((mastarde)) y entra sin problemas a la aplicacion.

– Se muestra un aviso de que no hay conexion.

2. El usuario introduce su codigo y su clave.

Se equivoca.

– Aparece aviso de error.

– Entra de todas maneras como en el primer caso, solo editor.


No se equivoca, errores posibles.

– El usuario no esta registrado en la base de datos o no tiene permisosactualmente.

– 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 parametros que el cliente tiene sobre servidor: elservidor no se alcanza (ıdem).

Figura 7.3: Aviso de inicio sin conexion por error en el intento

7.1.2. Informacion en el cliente sobre el servidor

La unica informacion sobre el servidor que tiene la aplicacion cliente es unadireccion de Internet en formato numerico (la IP) y el numero del puerto de escuchaen el servidor. Como se ha dicho, esta informacion debe ser conocida (e introducida)por el usuario.Estos valores pueden modificarse en los menus y tambien pueden guardarse. Pordefecto, cuando se pulsa la opcion de guardar se vuelcan los datos actuales a unfichero local en formato de texto plano que se nombre con ((.serverop)). Su contenidoen un momento dado puede ser:

C:\gen> type .serverop

147.156.16.31

1081

C:\gen>

En este fichero es en el que la aplicacion busca la informacion al iniciar el programa.Si no lo encuentra, esta programado para buscar la IP 0.0.0.0 y el puerto 1080por defecto, es decir, esta programado para funcionar dentro del propio servidor.En otro caso, el usuario no podra conectarse inmediatamente sino que tendra queponer valores a estos parametros desde los menus. Luego puede guardarlo para lasproximas conexiones.


Figura 7.4: Menu para ajustar parametros de conexion

7.1.3. El editor

El aspecto de la pantalla principal en la aplicacion cliente es muy sencillo. Dehecho su desnudez inicial puede desconcertar a mas de un usuario.

Seccion para los menus

Parte para el editor, esquema similar a la cuadrıcu-la de una hoja de calculo

Entrada de texto

Cuadro 7.1: Esquema del interfaz grafico: parte cliente

El usuario puede navegar por los registros y sus columnas con el raton y loscursores, y el contenido de cada celda va apareciendo en la entrada de texto inferior,para poderlo modificar.Ademas, por medio de los menus, el usuario puede elegir un registro y editarlo porseparado en una ventana a parte. En el ejemplo de la figura 7.5 se ha cargado unatabla para pruebas emitida por la base de datos MySQL instalada en el servidorslabii.uv.es de la Universidad de Valencia.

7.1.4. Reajustes en el codigo

Para algunas cosas, en efecto, el unico criterio de verdad es la practica. Estaseccion documenta algunas cuestiones demasiado secundarias para enfocarlas desde


Figura 7.5: Aspecto del editor para tablas

el capıtulo de implementacion. Son, en el fondo, ciertas divergencias entre la teorıay la practica y/o que solo se pueden descubrir en un terreno de ((laboratorio virtual)).Unicamente un lector mas proximo a ciertas tecnicas las considerara imprescindi-bles, pero desde un punto de vista menos sufrido, tambien pueden resultar intere-santes.

Divergencias Windows-Linux

No esta en el ambito de una demostracion final pero sı dentro de lo que es elproceso de desarrollo y pruebas, ciertas variaciones en el comportamiento que tienela implementacion dentro del entorno de Windows o dentro del entorno de Linux.Al ser el funcionamiento de MySQL mucho mas adecuado dentro de Linux, y laconcurrencia de los hilos en cualquier entorno Unix diametralmente opuesta1 a laque proporciona Windows, la tendencia a la hora de desarrollar el cliente es utilizaruna instalacion de Linux en un equipo mediano. De manera que –una vez hechoesto– se lleva el codigo a Windows, se ven algunas sorpresas.En anteriores secciones se ha hecho buena propaganda de la portabilidad de Perl y

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


de la de Prima. Esta es –sin duda– total. Los desarrolladores de Perl, sin embargo, nopueden hacer todavıa brujerıa, de modo que algunas cuestiones hay que estudiarlaspor separado.En este sentido, Perl contiene algunos ((trucos)) que permitiran averiguar dentro delcodigo en que sistema se esta. La propuesta que ofrece Prima y que se ha utilizadodefinitivamente esta en el modulo Prima::Aplicaction. Lo mejor es almacenar estoen una variable diferente concebida2 como de tipo logico 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 codigo de la aplicacion cliente se almacena –para el resto dela ejecucion del programa– una variable que valdra 1 si se esta corriendo la aplicacioncliente en un sistema Unix y 0 si esta corriendo en Windows.Ademas se ha hecho depender el tamano y el tipo de la letra utilizada en el restode caracteres (ventanas, cuadros de dialogo, etc) para que este en sincronıa con losentornos de uno y otro sistema.Partiendo de que la ayuda de la aplicacion –que por cierto, en sucesivas fases demantenimiento habra que fortalecer– se resuelve mediante una llamada a una paginaHTML incluıda con el ejecutable (y que es un extracto de esta documentacion), esdiferente el navegador que se utilize con Windows que en Linux. Ası, podrıa hacerse,vinculando a la accion del menu correspondiente:

if ($UNIX)

{

system("mozilla ayuda.html");

}

else

{

system("explorer ayuda.htm");

2Perl no diferencia un valor logico de uno entero, real o alfanumerico, para Perl todo son escalaresy es una de sus comodidades.


}

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 hagasysread se leera la informacion escrita antes. Si el orden es inverso, el lector quedabloqueado a la espera y –una vez actua el escritor– reanuda su marcha con la nuevainformacion.Esto puede probarse facilmente en algun programa sencillo y no da ningun tipo deproblema.Se ha comprobado sin embargo, que en ritmos de lectura/escritura con mas sobre-carga de informacion y de mayor rapidez, la lectura era incorrecta. Hay que decirque no se ha investigado mas alla de lo estrictamente empırico y se desconoce si estecomportamiento es normal, especıfico de Perl o especıfico de accesos mas rapidos.Es precisamente la diferencia de comportamiento entre las pruebas locales y las prue-bas entre PCs en tramos de subred diferentes y con cierta distancia mediante, loque ha permitido vislumbrar una solucion satisfactoria. Esta no es otra que colocaruna sentencia sleep detras de cada escritura en el socket para que el receptor no se((aturulle)).Lo ideal para resolverlo es permitir que desde la aplicacion cliente se pueda ajus-tar esto, bien sea porque el usuario lo introduzca manualmente o bien medianteuna negociacion de velocidades inicial que permita averiguar al cliente y al servidorque ((tiempo)) les separa.

7.2. Velocidad

Una ultima cuestion empırica, someter a pruebas el sistema. Medirlo, enfrentarsea los resultados para analizarlos y sacar conclusiones objetivas

7.2.1. Medicion

Esta prueba consiste en medir cuanto tarda el sistema en cargar una tabla. Porotra parte, se ha comentado en la seccion 3.1.2 (en la pagina 14) la singularidadque tenıa resolver el problema de las vistas3 de MySQL, interponiendo un procesoservidor entre este y la aplicacion cliente. Se han discutido las ventajas y desventajasdesde el punto de vista del diseno. Estas pruebas tienen interes, por lo tanto, paraver en la practica cuanto ha perturbado dicha decision. Por desgracia, no se hadesarrollado un cliente alternativo que consulte directamente a MySQL, que serıa

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


lo ideal para comparar ambos comportamientos.Para hacer esta prueba se ha utilizado una tabla existente en la base de datos delservidor slabii.uv.es de la Universidad de Valencia. En la tabla 7.2 se muestra unresumen del contenido de la misma, se trata de una tabla de 12 columnas con 125registros, en el apendice de la pagina 118 puede encontrarse mas informacion de lamisma:

Columna Sumatorio (lon-gitud caracteres)

Promedio

A 1250 10B 7336 58,688C 25096 200,768D 11304 90,432E 7955 63,64F 11986 95,888G 6585 52,68H 2066 16,528I 1134 9,072J 820 6,56K 4791 38,328L 4944 39,552

Cuadro 7.2: Resumen de la tabla de pruebas

Concretamente la tabla 7.2 muestra en la columna central la suma total decaracteres para ese campo. La columna derecha hace un promedio.Esto es interesante porque las mediciones no se han hecho con diferentes tablas dedistintos tamanos sino con sesgos de esta misma tabla. Es decir, se ha lanzado unaversion modificada del servidor que en cada prueba emitıa solamente 5 registros, 10registros, 15, 20, 25, ... hasta 125.Se ha elegido una tabla lo bastante homogenea y se han medido en el cliente lostiempos de llegada. En el capıtulo 3 de [5] se recomienda un mecanismo muy sencilloy de alta resolucion que serıa:

use Time::HiRes qw(gettimeofday);

$t0 = gettimeofday;

## operaciones para medir


$t1 = gettimeofday;

$intervalo = $t1-$t0;

print "Intervalo duro= ",$intervalo," segundos\n";

Que podrıa tener una salida como por ejemplo:

Intervalo duro 0.450648069381714 segundos

Las marcas pare medir T0 y T1 se han puesto en la funcion que controla el clickdel raton, de manera que entre que se solicita una base de datos y esta se muestrase supiera el tiempo. En otras palabras, lo que tarda en llegar la tabla exactamentedesde el punto de vista del usuario.

Figura 7.6: Evolucion 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 evolucion lineal,salvando casos de sesgos de la tabla que no hayan seguido el patron de homogenei-


Numero deregistros

Segundos que tar-daron en llegar

10 0,07055830955510015 0,43407034873960120 0,67232394218440225 0,76481008529670230 0,89680218696600335 1,05072331428530040 1,18946719169620045 1,35488772392279050 1,48772740364070055 1,62288403511050060 1,76429748535150065 1,89693641662589070 2,05802917480470075 1,84172797203071080 2,31861519813540085 2,44559454917911090 2,58501052856450095 2,699517488479600100 2,849133014679000105 2,977719068527010110 3,071854591370010115 3,224241971970000120 3,397480964661000125 3,571947813033990

Cuadro 7.3: Medicion de velocidades

dad. Es interesante saber cuanto de lineal para tener una referencia general.Tratandolo como el mas sencillo de los tradicionales problemas de metodos o anali-sis numerico, puede interpolarse la funcion que siguen estos numeros tomando elsiguiente polinomio de interpolacion:

f(x) = y0 +y1 − y0

x1 − x0(x − x0)

Asumiendo que, como se ha dicho, la funcion que estamos buscando es lineal pode-mos tomar como x1, y1, x0 y y0 cualesquiera valores de la tabla 7.3. Suponiendo:

x0 = 40


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

37, 18681926+ 0, 11381724902544300000

Esto significa que aunque las tablas van tardando cada vez mas conforme mayoresson, por ejemplo una rabla de estas caracterısticas, con mil registros tardarıa apro-ximadamente unos 27 segundos, el progreso crece muy lentamente.Hay que tener en cuenta que se ha medido en unas condiciones muy buenas. Elacceso es de unos 400Kbps. Teniendo en cuenta que la tabla madre (sin sesgar) quese ha utilizado tiene 84017 caracteres, es decir, podemos redondear a 10, 5kilobits ygeneralizar orientativamente a los casos mostrados en la tabla 7.4. Estos calculos sehan simplificado, desde luego, entre otras cosas, por ejemplo, se ha supuesto traficohomogeneo para unos accesos que para otros.

resultados para una tabla de 125 registros con 10.5kilobits

acceso 400kbps 33kbps 45,2kbpscoef. 2,939572622 0,242514741 0,332171706velocidad. segs. 3,571947813033990 43,296337127684700 31,610157637468900

Cuadro 7.4: Calculo de velocidades (en segundos tardados) segun accesos

7.2.3. Conclusiones

Las ultimas valoraciones sobre los resultados en la seccion anterior pueden dejaralgo insatisfecho al lector. En segun que casos, medio minuto para cargar una tablapuede ser demasiado.De todas maneras hay varios aspectos positivos que deben tenerse en cuenta acercade estos datos:

+ La dınamica en la aplicacion cliente cuando esta se utiliza remotamente escargar (una vez) la tabla propia con la informacion individual, modificar losregistros que corresponda o bien anadir algunos nuevos y subir la actualizacion.


Habitualmente, cada trabajador tiene una tabla de unos cien o doscientosclientes como maximo, ası que en el peor de los casos tarda un par de minutosen las operaciones de acceso a la base de datos y lo que le cueste modificar losvalores una vez cargados localmente.

+ El ejemplo que se ha puesto, de una tabla de mil registros, o incluso de mas,solo se darıa en el entorno de la oficina, es mas, puede utilizarse para este tipode 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 operacion que se ha medido (cargar una tabla remotamente) nopuede ser menor que de un orden lineal –excepto con tecnicas de cifrado masavanzadas que para tablas grandes tambien cargarıan al servidor–. En tantoque lineal, su crecimiento es ınfimo y esto es –en realidad– una muestra deque la decision de enmascarar las vistas (o no vistas) de MySQL mediante unproceso intermedio no solo no era tan descabellada como en un principio podıaparecer sino que ha sido desarrollada con bastante fortuna.

7.3. Valoracion final

Cierto lector puede echar a faltar algunos temas en esta memoria. En todo caso,tengase en cuenta las siguientes conclusiones y consideraciones generales a modo decierre:

– A un nivel como el que se ha tratado, la cuestion de las bases de datos no tienemayor inconveniente. La oferta de posibilidades para implantar es, segun se hadiscutido, suficiente como para dudar a la hora de tomar cada decision. Estoanima a todos aquellos usuarios de sistemas de bases de datos que no estencontentos con el rendimiento que les ofrecen sus instalaciones, a que estudienlas posibilidades de implantar un sistema como el descrito.

– Vale la pena recomendar el uso de Perl y de Prima a todos aquellos progra-madores que no esten satisfechos con los entornos en los que trabajan y enespecial a todos aquellos que busquen la independencia de plataforma para sucodigo. Se trata sin duda de herramientas potentes que no fallan, estan biendocumentadas y son sencillas. Ademas, el programador habitual de C se fami-liarizara pronto con Perl. La portabilidad de Perl, en efecto, es tan abrumadoracomo sus partidarios defienden.

– No se ha cerrado con rigor una seccion dedicada a presupuestos porque no seha considerado relevante. Lo unico que se ha gastado es la fuerza de trabajode un solo ingeniero. Sopesandolo en unas 500 horas de base y otras 150 paracerrar debidamente esta memoria. El lector puede imaginar un sueldo habitual


de informatico en tres meses. Lo realmente interesante es que se ha resueltotodo lo demas sin coste adicional ninguno ni en software ni en hardware. Apro-vechando eso sı, la naturaleza academica del proyecto, se ha recurrido a ciertasinstalaciones de la Universidad de Valencia que han sido de mucha ayuda (bi-blioteca, accesos publicos a Internet para portatiles, apuntes de varios cursos,etc).

– El principal aspecto que tiene el trabajo desarrollado es, desde el punto devista del autor y con todo lo expuesto desde la primera pagina hasta la ultimade este documento, que se ha salido de una situacion fatalmente planteaday se han abierto varios caminos para alcanzar soluciones de mucha enverga-dura. Asimismo, las cuestiones mas inmediatas y necesarias se han cubiertosatisfactoriamente.

El codigo del servidor

# servidor

use DBI;

use Socket;

use threads;

use 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: $!\n";

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


syswrite($interlocutor,$buf,$LIM);

}

else

{

$buf="0:~:LOGINFALSE::$DBI::errstr$EOL";

print $buf;


}

}

elsif (($codigo cmp ’LOGOUT’)==0)

{

$buf="-1:~:NULL::Loging out... $EOL";


$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]";

}


$buf=join ’:’,@cab;

$buf="1:~:SEQ::$buf:~:$EOL";


sleep(1);

$sth=$dbh->prepare($buffer);


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;


}

else

{

$buffer="0:~:NULL::Resultado de SELECT vacio $error $EOL";



}

}

elsif (($tipo cmp ’SHOW’)==0)

{

$buf=$instruccion[1];

$buf="1:~:SEQ::$buf: :~:$EOL";




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;


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;



}

else

{

$buffer="0:~:NULL::Resultado de SHOW vacio $error $EOL";


}

}

else # NON-SELECT & NON SHOW query if (1==0)

{


$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";


}

}

else

{

$buffer="0:~:INF::Recibido paquete sin cabecera o esta es erronea $EOL";


}

}

# 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 codigo del cliente

use Prima;

use Prima::DetailedList;

use Prima::Header;

use Prima::Classes;

use Prima::StdDlg;

use Prima::MsgBox;

use Prima::Grids;

use Prima::Buttons;

use Prima::Label;

use Prima::Application;

use Prima::FrameSet;

use Cwd;

use Spreadsheet::ParseExcel::Simple;

use Spreadsheet::WriteExcel;

use Prima qw( ComboBox Edit);

use 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)

{


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’,’Numero 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’,’Numero 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’,[


["".ipremota=>"$ip_server",q()],

[’_cambiar_’,sub

{

$ip_server=generic(’Parametros conexion’,’IP del servidor’,$ip_server);

$_[0]->menu->ipremota->text($ip_server);

}],

]],

[’Puerto’,[

["".puerto=>"$port_server"=>q()],

[’_cambiar_’,sub

{

$port_server=generic(’Parametros 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";


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;


abrirxls(1);

$sqlnivel=-1;

}

}],


]],

[],

[ ’?’, [

[ ’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: #############

# ################################################################


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;


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


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


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=>’’,


#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 {


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;


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

},



$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 {


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 {



{

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


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


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


size=>[90,40],

left=>10,

text=>"Aceptar",

bottom => 10,


onClick=>sub{

$cont=$valor->text;

$c->close;

},

);



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

}


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},


origin => [0,0],

text => $mensaje,

focusLink => $b1,

wordWrap => 1,

width => $Xx,

height => $Yy-5,

autoHeight=>1,

alignment => ta::Center,

growMode => -1,




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 conexion\n $buffer");

}

}

else

{


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

}



chop $buffer;

chop $buffer;




}

print "$bucle\n";

while (($bucle cmp ’SEQ’)==0)

{



{

print "ii - Le estoy metiendo: - $array[$i] -\n";


}

push @sqlitems,[@array];



chop $buffer;

chop $buffer;



$globalregistrostabla++;

}

if (($bucle cmp ’ULT’)==0)

{



{

print "iii - Le estoy metiendo: - $array[$i] -\n";

}

print "@array\n----~n~n----";

push @sqlitems,[@array];


}

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;


size=>[$X,$Y],

origin=>[1,1],

centered=>1,

name=>"Introduzca usuario/clave",

growMode=>0,

onActivate=>sub{},

onDestroy=>sub{$hacker?die:{};},

borderIcons=>10,

icon => $ICONO,


$c-> insert( Label =>



origin => [ 10,$Y-40],

text => "Usuario:",

focusLink => $b1,

wordWrap => 0, #1

width => 120,


growMode => 0,


my $inh=$c->insert(InputLine=>text=>$login,

width=>110,

origin=>[100,$Y-40],



growMode=>2,

buffered=>0,

borderWidth=>3,

autoselect=>0,);

$c->insert( Label =>


origin => [ 10,$Y-80],

text => "Contrase~na:",

focusLink => $b1,

wordWrap => 1,

width => 100,


growMode => 0,


my $inv=$c->insert(InputLine=>text=>$passwd,

width=>110,

origin=>[100,$Y-80],



growMode=>1,

writeOnly=>1,

passwordChar=>’·’,

buffered=>0,

borderWidth=>3,

autoselect=>0,);



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




$c->close;

tratar($buffer);

}

else

{

$c->close;

ventanita("MySQL info","Cliente funcionando sin conexion\n $retorno[1] ");

};

},

);



size=>[90,40],

text=>"Mas tarde",

left=>$X-10-90,

bottom => 10,

onClick=>sub{

$c->close;

if ($conectado==0)

{

ventanita("MySQL info","Cliente funcionando sin conexion");

}

},

);

$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],


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 }],

);

}


# 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";


{

push @globalitems,[($sqlitems[$i], ’ ’)];

}

$ref_items=\@globalitems;

}

if ($_[0]==-3) # modo de interfaz - muestra un resultado SQL

{


{

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


}

else

{

$flag=1;

$xls=Spreadsheet::ParseExcel::Simple->read($fichero);


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


}

}


$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],


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");



$buf=join ’’,(’SQL’,’:~:’,’show’,’ ’,tables,":~:","$EOL");



tratar($buffer);

}

elsif ($sqlnivel==1) # mira las tablas y elige una

{

$sqlnivel++;

$buf=join ’’,(’SQL’,’:~:’,’select’,’ * ’,’from ’,${$maindl->items}[$maindl->focusedItem][0],":~:","$EOL");



tratar($buffer);

}

},

onSelectItem=>sub{

$mainil->text(${$maindl->items}[$actualy][$actualx]);

},

onKeyDown => sub {



#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

{


}

elsif (($code==0) and ($key==264192)) # flecha dcha

{

if ($actualx<$globalcolumnas)

{

$actualx++;

}


}

elsif (($code==0) and ($key==263680)) # flecha izq

{

if ($actualx>0)

{

$actualx--;

}


}

elsif (($code==9) and ($key==133376)) # tabulador

{

$mainil->select();

}

}

);

$mainil=$main2->insert( InputLine =>

origin => [ 0,0],


font=>$SO_font,

size => [$main2->size], #[ $main-> width, 20],

text => ${$maindl->items}[$actualy][$actualx],

#current => 1,


onKeyDown => sub {



{

${$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 seccion 7.2.1 donde se explica comoha 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

Bibliografıa

[1] Larry Wall, Tom Christiansen and Jon Orwant, Programming in Perl, ThirdEdition, O’Reilly & Associates, July 2000.

[2] Dmitry Karasik, Anton Berezin and Vadim Belman, Prima – the perl graphictoolkit, c© 1997-2003 The Protein Laboratory, University of Copenhagen.

[3] Ellen Siever, Stephen Spainhour and Nathan Patwardhan, Perl in a nutshell,second ed., Copyright c© 2002, 1999 O’Reilly & Associates, Inc.

[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 andPaul DuBois, MySQL Reference Manual, Copyright c© 1997-2004 MySQL AB .

[7] Larry Ullman, Guıa de aprendizaje MySQL, 2003, Prentice Hall.

[8] J. BenavidesAbajo, J.M. Olaizola Bartolome y E. Rivero Cornelio, SQL Parausuarios y programadores, quinta ed. 1999, Ed. Paraninfo.

[9] Roger S. Pressman, Ingenierıa del Software, un enfoque practico, cuarta edicion4.1997, Mc Graw Hill.

[10] Alberto Domingo Ajenjo, Direccion y gestion de proyectos –Un enfoque practico,Ra-Ma, 2000.

[11] Adoracion de Miguel Castano y Mario G. Piattini Velthis, Fundamentos y mo-delos de Bases de Datos, segunda ed. 1999, Ra-Ma.

4Tambien se ha utilizado la tercera edicion de 1995

120

Referencias web

http:// www.ActiveState.comSe trata de un grupo filial de la empresa Sophos. Pueden descargarse de aquı in-terpretes de Perl para Linux y para Windows. La pagina se actualiza confrecuencia y ofrece posibilidades para otros lenguajes, a parte de cierta docu-mentacion.

http:// www.perl.comPagina muy util sobre Perl, pagina oficial. Contiene artıculos y enlaces deactualidad, lo mejor para estar al dıa.

http:// www.cpan.comDesde aquı no solo se puede descargar Perl sino tambien multitud de modulos,documentados y con enlaces a sus sitios web. CPAN es el Comprehensive PerlArchive Network. Tiene un caracter mucho mas proximo a Open Source queActiveState, ambas son recomendables.

http:// www.indigostar.comSitio web de una relativamente pequena empresa Canadiense de software. Entreotros programas distribuye un ensamblador muy simple que genera ejecutablespartiendo de scripts de Perl.

http:// www.mysql.comSitio oficial de MySQL. Puede encontrarse todo lo referente a esta potentebase de datos firmada con licencia libre (GPL).

http:// www.orreily.comPagina del grupo O’Reilly. Se trata de una empresa de publicaciones informati-cas que ofrece bastante calidad. La pagina puede servir sobre todo para buscarartıculos, reports sobre conferencias, etc. O’Reilly se dedica tanto a la publi-cacion on line como al papel tocante

http:// www.unix.org.uaPagina sovietica de alguna asociacion Unix, quien sepa ruso podra averiguarlo.Es muy recomendable porque incluye en HTML copias de algunos libros deO’Reilly. Seguramente es ilegal hacer esto porque los libros mas modernos

121

APENDICE . REFERENCIAS WEB

de O’Reilly valen del orden de 50$ y en su pagina web solamente puedendescargarse algun capıtulo de muestra en formato PDF. Aunque tiene otrasmuchas cosas, sin duda lo mas espectacular es la magnıfica biblioteca gratuitaque esconde http://www.unix.org.ua/orelly/.

Indice alfabetico

C , 43JAVA, 44

((byte code)), 49maquina virtual de, 45

Base de datosdefinicion, 4privada virtual, 8

benchmark, 13

GPL, 10

IndigoStar, 50perl2exe, 51

JDBC, 45

Larry Wall, 48cita, 59hilos y procesos, 59

Microsoftcomponentes COM+, 56

MySQLbenchmarks y propiedades, 12propiedades basicas, 9vistas, 14

ODBC, 13Oracle

Empresa, 6RMAN, 8version 10g, propiedades, 7

Orientacion a Objetosanalisis, 11

diseno, 28

PDA, 65Palm, 66Pocket PC, 68Sharp Zaurus, 67

Perl, 48((op code)), 49DBI, 60mongers, 53package manager, 50Prima, 53

DetailedList, 55Grid, 54

sockets, 61Tk, 52

PHP, 52PostgreSQL, 10Python, 52

rollback, 7Ruby, 52

script, 48SQL

definicion, 8

Tcl, 52

usuarioexperto, 41frecuente, 41novato, 41

Visual Studio .NET, 52

123

INDICE ALFABETICO

Compact Framework (diagrama), 70Framework (definicion), 70Framework (diagrama), 69MIT, 72P/Invoke, 71reflection emit, 71remoting, 71SDE, 72serializacion, 71XPath/XSLT, 71

XML, 72

uce sociedad anonima (sauce)

Documents