API DE COMUNICACIONES PARA POCKET PC BASADO EN LA

API DE COMUNICACIONES PARA POCKET PC BASADO EN LA

PROGRAMACIÓN ORIENTADA A ASPECTOS

PAULO ANDRÉS BURGOS HEREDIA

JESÚS ALBERTO PINZON ORTIZ

PONTIFICIA UNIVERSIDAD JAVERIANA

FACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMAS

SANTAFÉ DE BOGOTA D.C.

JUNIO DE 2005

API DE COMUNICACIONES PARA POCKET PC BASADO EN LA

PROGRAMACIÓN ORIENTADA A ASPECTOS

PAULO ANDRÉS BURGOS HEREDIA

JESÚS ALBERTO PINZON ORTIZ

Proyecto de grado presentado para optar el título de

INGENIERO DE SISTEMAS

DIRECTOR

JUAN PABLO GARZÓN

Ingeniero de Sistemas




SANTAFÉ DE BOGOTA D.C.

JUNIO DE 2005




Rector Magnífico:

Padre Gerardo Remolina Vargas S.J.

Decano Académico Facultad de Ingeniería:

Ingeniero Francisco Javier Rebolledo Muñoz

Decano del Medio Universitario Facultad de Ingeniería:

Padre José Sarmiento Nova S.J.

Director Carrera de Ingeniería de Sistemas:

Ingeniera Hilda Cristina Chaparro López

Director Departamento de Ingeniería de Sistemas:

Ingeniero Germán Alberto Chavarro Flórez

Nota de Aceptación

___________________

___________________

___________________

__________________________

Director del Proyecto

__________________________

Jurado

__________________________

Jurado

Mes y Año

DEDICATORIA

Dedicamos especialmente a Deogracias, Edgar Rodrigo, Julia Consuleo,

Maria Consuelo, Graciela, Ana Julia, Ricardo, Cony, Laura Jimena,

Sebastian y José David nuestros padres y familiares quienes hicieron

posible este gran logro en nuestras vidas.

AGRADECIMIENTOS

Agradecemos a Dios por brindarnos la oportunidad de realizar este gran

trabajo; por la salud, paciencia, perseverancia y sabiduría que fue el

motor de esta misión.

Agradecemos a Juan Pablo Garzón por la guía y apoyo continuo en el

desarrollo de esta investigación.

Agradecemos a nuestras familias, amigos y a quienes queremos de

corazón por la paciencia y fe impuesta en nosotros, que nos impulso a

seguir adelante en esta ardua tarea.

Agradecemos a Jaime Alberto y su hermano Juan David por brindarnos

su contribución en esta tesis.

Agradecemos a nuestros profesores y compañeros quienes de una u otra

forma nos apoyaron en esta investigación.

Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por

sus alumnos en sus proyectos de grado. Sólo velará porque no se

publique nada contrario al dogma y la moral católica y porque no

contengan ataques o polémicas puramente personales. Antes bien, que

se vean en ellos el anhelo de buscar la verdad y la Justicia”

TABLA DE CONTENIDO

1 INTRODUCCIÓN..................................................................................... 1 2 OBJETIVOS ........................................................................................... 2

2.1 OBJETIVO GENERAL ............................................................................... 2 2.2 OBJETIVOS ESPECÍFICOS ....................................................................... 2

3 PROBLEMA U OPORTUNIDAD................................................................... 3 4 ESTADO DEL ARTE ................................................................................. 4

4.1 PROGRAMACIÓN ORIENTADA A ASPECTOS ............................................... 4 4.1.1 Historia ......................................................................................... 4 4.1.2 ¿Qué es un Aspecto?....................................................................... 5 4.1.3 ¿Qué es la Programación Orientada a Aspectos? ................................. 5 4.1.4 Los aspectos en el diseño ................................................................ 6

4.1.4.1 AspectJ................................................................................... 7 4.1.4.2 JBoss 4.0 ................................................................................ 7 4.1.4.3 Cool ....................................................................................... 8 4.1.4.4 Aspectos en .NET..................................................................... 8

4.2 COMUNICACION ENTRE PARES ................................................................ 8 4.2.1 Definición ...................................................................................... 9 4.2.2 Ventajas........................................................................................ 9

4.2.2.1 Kazaa..................................................................................... 9 4.2.2.2 JXTA ...................................................................................... 9

4.3 CARACTERÍSTICAS DE LOS DISPOSITIVOS MÓVILES ............................... 10 4.3.1 Pocket PC .................................................................................... 10 4.3.2 Framework de desarrollo ............................................................... 11

4.3.2.1 J2ME .................................................................................... 11 4.3.2.2 Compact Framework .............................................................. 11

4.3.3 Emuladores.................................................................................. 12 5 MARCO TEÓRICO ................................................................................. 13

5.1 CONCEPTOS BÁSICOS DE LA PROGRAMACIÓN ORIENTADA A ASPECTOS.... 13 5.2 PROGRAMACIÓN ORIENTADA A ASPECTOS ............................................. 14

5.2.1 Análisis ....................................................................................... 15 5.2.2 Diseño ........................................................................................ 16

5.3 SOPORTE DE LA PROGRAMACIÓN ORIENTADA A ASPECTOS EN .NET.......... 17 5.3.1 Aspectos en C#............................................................................ 17

5.3.1.1 RAPIER-LOOM.NET [RLOM]: .................................................... 18 5.3.1.2 ASPECT# [ASP#]:.................................................................. 18 5.3.1.3 ADD-IN DE MESALEM [ADDM]:................................................ 19

5.3.2 Aspectos en Compact Framework ................................................... 19 5.3.2.1 El Namespace SYSTEM.REFLECTION.EMIT................................. 19 5.3.2.2 RAPIER-LOOM.NET................................................................. 20 5.3.2.3 ASPECT# .............................................................................. 20 5.3.2.4 ADD-IN DE MESALEM ............................................................. 21

5.4 HERRAMIENTA PARA EL DESARROLLO DE APLICACIONES BASADAS EN ARQUITECTURAS P2P PARA DISPOSITIVOS MÓVILES ............................... 21

5.4.1 JXME........................................................................................... 21 6 PROCESO DE DESARROLLO................................................................... 24

6.1 ETAPA DE ANÁLISIS ............................................................................. 24

6.2 REQUERIMIENTOS FUNCIONALES .......................................................... 24 6.2.1 Conectar a la Red P2P ................................................................... 25 6.2.2 Publicar Servicio........................................................................... 26 6.2.3 Buscar Servicio............................................................................. 28 6.2.4 Consumir Servicio......................................................................... 29 6.2.5 Desconectar de la Red................................................................... 30 6.2.6 Enviar Datos ................................................................................ 30

6.3 REQUERIMIENTOS NO FUNCIONALES ..................................................... 31 7 ARQUITECTURAS PROPUESTAS.............................................................. 33

7.1 CRITERIOS PARA ESCOGER Y EVALUAR LAS DIFERENTES ARQUITECTURAS 33 7.2 OPCIONES DE ARQUITECTURAS PARA IMPLEMENTAR P2P EN DISPOSITIVOS

MÓVILES............................................................................................. 34 7.2.1 Arquitectura Basada en Relays ....................................................... 35 7.2.2 P2P Pura...................................................................................... 36

7.3 INTEGRACIÓN DE LAS ARQUITECTURAS P2P........................................... 38 7.3.1 P2P Puntos Comunicados por Relay................................................. 39 7.3.2 P2P con Servidor de Índices con Puntos Comunicados por Relay......... 41 7.3.3 P2P Servidor Índices ..................................................................... 43 7.3.4 P2P con Servidor de Índices y Búsquedas ........................................ 44 7.3.5 P2P con Servidor de Índices y sin Búsquedas ................................... 45

7.4 MÉTODO PARA ESCOGER LA ARQUITECTURA DEL API DE COMUNICACIONES 45

7.5 DISEÑO DE LA ARQUITECTURA.............................................................. 47 7.5.1 Diseño de Paquetes ...................................................................... 47 7.5.2 Paquete del Cliente:...................................................................... 48 7.5.3 Paquete de Índices ....................................................................... 48 7.5.4 Paquete Comunicaciones ............................................................... 49 7.5.5 Paquete de Tipos .......................................................................... 49 7.5.6 Paquete de Servicios..................................................................... 50

8 ETAPA DE IMPLEMENTACIÓN DEL API..................................................... 51 8.1 EL TRABAJO DESARROLLADO EN MÁQUINAS VIRTUALES DE JAVA PARA

POCKET PC.......................................................................................... 51 8.1.1 Máquinas Virtuales de Java para Pocket PC ...................................... 51 8.1.2 Trabajo Desarrollado en JXME ........................................................ 52

8.2 MODELOS DE IMPLEMENTACIÓN............................................................ 52 8.2.1 Desarrollo Basado en Sockets, Mutihilos, Flujos Distribuidos y

Serialización de Objetos ................................................................ 53 8.2.2 Desarrollo Basado en Servicios Web................................................ 58

8.3 ADAPTACIÓN DE LA ARQUITECTURA DEL API .......................................... 59 8.3.1 Arquitectura del API...................................................................... 60

8.4 IMPLEMENTACIÓN DEL API.................................................................... 62 8.4.1 Implementación de los Aspectos..................................................... 63

8.4.1.1 Funcionamiento de los Aspectos en el API ................................. 65 8.4.2 Implementación del Cliente............................................................ 70 8.4.3 Implementación del Relay.............................................................. 72 8.4.4 Implementación del Directorio........................................................ 73 8.4.5 Implementación de las Clases Utilitarias .......................................... 74

9 ETAPA DE EVALUACIÓN ........................................................................ 77 9.1 ALCANCE ............................................................................................ 77 9.2 ÍTEMS A PROBAR ................................................................................. 77

9.2.1 VARIABLES.................................................................................. 77

9.3 ESTRATEGIA........................................................................................ 77 9.4 RECURSOS.......................................................................................... 78 9.5 IMPLEMENTACIÓN DEL API BASADO EN POO........................................... 78 9.6 ARQUITECTURAS A PROBAR.................................................................. 79 9.7 ESCENARIOS....................................................................................... 80 9.8 CONVENCIONES .................................................................................. 80

10 PLAN DE PRUEBAS ............................................................................... 81 10.1 ANALISIS DE LAS PRUEBAS................................................................... 82 10.2 ANALISIS DE IMPACTO DE POA ............................................................. 86

10.2.1 METRICAS PARA POA .................................................................... 86 10.2.1.1 RESULTADO DE LAS METRICAS ............................................... 88

10.2.2 COMPARACIONES DE LINEAS DE CODIGO ....................................... 89 11 CONCLUSIONES................................................................................... 93 12 GLOSARIO .......................................................................................... 96 13 REFERENCIAS.................................................................................... 104 14 REFRENCIAS DE PAGINAS DE INTERNET............................................... 107 15 ANEXOS............................................................................................ 113

ÍNDICE DE GRAFICAS Gráfica 1 Descomposición de conceptos, Analogía del Prisma [LADD] ...................... 16 Gráfica 2 Arquitectura de JXME [AROR] ............................................................... 23 Gráfica 3 Diagrama de Casos de Uso................................................................... 25 Gráfica 4 Diagrama de Arquitectura Basada en Relays........................................... 35 Gráfica 5 Diagrama de Secuencia Arquitectura Basada en Relays............................ 36 Gráfica 6 Diagrama de Arquitectura P2P Puro....................................................... 36 Gráfica 7 Diagrama de Secuencia Arquitectura P2P Puro........................................ 37 Gráfica 8 Diagrama de Arquitectura P2P Puntos Comunicados por Relay .................. 39 Gráfica 9 Diagrama de Secuencia Arquitectura P2P Puntos Comunicados por Relay ... 40 Gráfica 10 Diagrama de Arquitectura P2P con Servidor de Índices con Puntos

Comunicados por Relay ...................................................................... 41 Gráfica 11 Diagrama de Secuencia Arquitectura P2P con Servidor de Índices con Puntos

Comunicados por Relay ...................................................................... 42 Gráfica 12 Diagrama de Arquitectura P2P Servidor Índices ................................. 43 Gráfica 13 Diagrama de Secuencia Arquitectura P2P con Servidor de Índices y

Búsquedas........................................................................................ 44 Gráfica 14 Diagrama de Secuencia Arquitectura P2P con Servidor de Índices y sin

Búsquedas........................................................................................ 45 Gráfica 15 Diagrama de Componentes del API de Comunicaciones.......................... 47 Gráfica 16 Diagrama de Componentes Paquete de La Interfaz del Cliente ................ 48 Gráfica 17 Diagrama de Componentes Paquete de el Servidor de Índices................. 48 Gráfica 18 Diagrama de Componentes Paquete de Comunicaciones......................... 49 Gráfica 19 Diagrama de Componentes Paquete de Interfaces ................................. 49 Gráfica 20 Diagrama de Componentes Paquete de Aspectos................................... 50 Gráfica 21 Inicio del Servidor de Índices y adición de un nuevo Nodo...................... 53 Gráfica 22 Inicio del Relay y adición de un nuevo Nodo ......................................... 53 Gráfica 23 Pantalla principal del Cliente ............................................................... 54 Gráfica 24 Carga de un servicio .......................................................................... 54 Gráfica 25 Mensaje de adición de servicios en el Relay .......................................... 55 Gráfica 26 Mensaje de adición de servicios en el Servidor de Índices....................... 55 Gráfica 27 Mensaje de búsqueda en el Servidor de Índices .................................... 55 Gráfica 28 Mensaje de búsqueda en el Relay........................................................ 55 Gráfica 29 Presentación de los resultados obtenidos en el Cliente .......................... 56 Gráfica 30 Presentación prestación de servicios en el Servidor de Índices ................ 56 Gráfica 31 Error presentado por la serialización de objetos .................................... 57 Gráfica 32 Comunicaciones entre los Elementos de la red P2P ................................ 60 Gráfica 33 Diagrama de Distribución ................................................................... 61 Gráfica 34 Diagrama de Componentes................................................................. 62 Gráfica 35 Paquete de Aspectos.......................................................................... 64 Gráfica 36 Relación entre la clase y el aspecto...................................................... 66 Gráfica 37 Tejido de un objeto y un aspecto......................................................... 67 Gráfica 38 Ejecución del proceso de tejido ........................................................... 68 Gráfica 39 Vista de la clase tejida ....................................................................... 68 Gráfica 40 Clases independientes luego de la ejecución ......................................... 69 Gráfica 41 Relación de Aspectos y Clases en tiempo de ejecución ........................... 69 Gráfica 42 Paquete cliente ................................................................................. 71 Gráfica 43 Paquete Relay Servicio Web................................................................ 72 Gráfica 44 Paquete Lógica Relay......................................................................... 72

Gráfica 45 Paquete Directorio Servicio Web.......................................................... 73 Gráfica 46 Paquete Lógica Directorio ................................................................... 74 Gráfica 47 Paquete Tipos ................................................................................... 76 Gráfica 48 Arquitectura a probar con aspectos...................................................... 79 Gráfica 49 Arquitectura a probar sin aspectos ...................................................... 79 Gráfica 50 Plan de Pruebas ................................................................................ 81 Gráfica 51 Código con aspectos, función búsqueda ............................................... 90 Gráfica 52 Código sin aspectos, función búsqueda ................................................ 91

ÍNDICE DE TABLAS

Tabla 1 Comparación entre los paradigmas [ASTE] ............................................... 13 Tabla 2 Selección de Arquitectura a Implementar. ................................................ 46 Tabla 3 Rangos de Calificación ........................................................................... 46 Tabla 4 Convenciones para métricas de complejidad ............................................. 87 Tabla 5 Resultados obtenidos con la herramienta CCMetrics................................... 88 Tabla 6 Resultados obtenidos con la herramienta devMetrics.................................. 88 Tabla 7 Métricas de Beneficio y Limpieza ............................................................. 88 Tabla 8 Clases adicionales para los aspectos ........................................................ 89 Tabla 9 Total líneas de código por aspecto ........................................................... 89 Tabla 10 Total líneas de código por clase a tejer................................................... 90

ÍNDICE DE ANEXOS Anexo 1. Comunicación con el soporte de la herramienta Rapier-Loom.Net .......... 113 Anexo 2. Comunicación con el Soporte de la herramienta AspectC# .................... 114 Anexo 3. Comunicación con Mesalem, creador de un Add-in para Visual Studio para el

tejido de aspectos............................................................................ 115 Anexo 4. Migración del add-in de aop en .net con el Ejemplo Observer Pattern ..... 116 Anexo 5. Investigation sobre Desarrollo de .net Compact Framework Aspect Sharp

(aspectsharp.sourceforge.net)........................................................... 119 Anexo 6. Ejemplo desarrollado en Rapier Loom.Net........................................... 121 Anexo 7. Diagramas de Secuencia................................................................... 123

7.1 Caso de Uso: Atender Solicitud.......................................................... 123 7.2 Caso de Uso: Búsqueda Servicios ...................................................... 124 7.3 Caso de Uso: Conectar ..................................................................... 125 7.4 Caso de Uso: Desconectar ................................................................ 126 7.5 Caso de Uso: Enviar Datos................................................................ 127 7.6 Caso de Uso: Publicación de Servicios ................................................ 128 7.7 Caso de Uso: Solicitar Servicio .......................................................... 129

Anexo 8. Especificación del API....................................................................... 130 Anexo 9. Resultados de las Pruebas ................................................................ 210

9.1 Pruebas a los APIs Equipo 1 .............................................................. 210 9.2 Pruebas a los APIs Equipo 2 .............................................................. 211 9.3 Pruebas a los APIs entre los nodos..................................................... 212 9.4 Análisis de Varianza y Media de los resultados..................................... 213 9.5 Gráficas de Resultados de las pruebas................................................ 214

1

1 INTRODUCCIÓN En la actualidad el desarrollo de sistemas de información se construyen a partir de dos componentes. Estos son los requerimientos funcionales y los requerimientos no funcionales. En el desarrollo de soluciones de sistemas de software se presenta un problema muy frecuente, el cual es, la mezcla entre los módulos que hacen parte de la lógica del negocio y los que corresponden a las necesidades inherentes de la tecnología. La Programación Orientada a Objetos (POO) nos ayuda a modelar e implementar la lógica del negocio de forma muy cercana a la realidad, por lo que ayuda a que el proceso de desarrollo sea más fácil de elaborar, ya que la funcionalidad puede ser expresada fácilmente en objetos que se componen de propiedades y métodos. Pero el inconveniente de la POO es aquellos aspectos que se entrecruzan en varios conceptos a lo largo del sistema, lo cual hace muy complejo su desarrollo. Estos aspectos normalmente están relacionados con los requerimientos no funcionales (Ejemplo: tiempos de respuesta, manejo de memoria, seguridad, auditoria, etc.). La Programación Orientada a Aspectos (POA) es un paradigma que plantea una forma alterna para el modelamiento e implementación de estos aspectos. Para el desarrollo de esta investigación se quiso mostrar la factibilidad del desarrollo de un sistema con requerimientos funcionales y no funcionales, y que fuera analizado, modelado e implementado con la ayuda de POA. El escenario escogido es un API de comunicaciones entre dispositivos móviles. En la primera parte el documento se enuncia los objetivos, tanto el general, como los específicos, que persigue la investigación. Luego se muestra la importancia de la investigación y su porqué. Seguido a esto se hace una breve reseña del estado del arte en materia de POA y del escenario escogido; después se realiza un acercamiento al marco teórico necesario para mostrar las bases teóricas de la investigación. El siguiente aspecto que se trata son las arquitecturas propuestas para el escenario, el desarrollo que se construyó, las pruebas y resultados que se obtuvieron. Y finalmente se enuncian las conclusiones a las que se llegaron y las posibles extensiones de esta investigación.

2

2 OBJETIVOS Para el desarrollo de este Proyecto de Investigación se han definido una serie de objetivos, partiendo de uno general, que aclara la finalidad de la investigación, el cual se logrará cumpliendo los objetivos específicos.

2.1 OBJETIVO GENERAL

Diseñar un API (Interfaz de Programación de Aplicaciones) de comunicaciones, usando POA basado en Microsoft .NET Compact Framework y comparar el desempeño con el API de JXTA para J2ME.

2.2 OBJETIVOS ESPECÍFICOS

Analizar la viabilidad del desarrollo del API basado en POA y generar las conclusiones respectivas. Crear una aplicación P2P usando el API desarrollado y comparar el desempeño con una aplicación equivalente usando el API de JXTA para J2ME, basados en métricas y mediciones haciendo uso de un estándar de pruebas tipo Benchmark donde se comparen en términos de tiempos de respuesta y la utilización de recursos del dispositivo. Las métricas usadas serán comerciales o se definirán unas propias de ser necesario. Plantear conclusiones del desarrollo de una aplicación nativa en .NET sobre Pocket PC.

3

3 PROBLEMA U OPORTUNIDAD La tendencia en la informática muestra claramente una inclinación a convertir las herramientas tecnológicas en dispositivos mucho más fáciles de usar, de programar y de portar. La respuesta a esto son los dispositivos móviles, los cuales aportan estas ventajas entre muchas otras, haciendo que el mercado las explote y se creen aplicaciones útiles e innovadoras a un ritmo acelerado. La comunidad de desarrolladores ha tomado en serio los dispositivos móviles, brindando herramientas de programación que permiten crear tanto, las mismas aplicaciones de escritorio, como un mundo nuevo de aplicaciones basándose en sus ventajas, como por ejemplo la transmisión de datos de forma inalámbrica. El paradigma de POA es un concepto que se concibió en la década de los 90 como solución a algunas falencias de POO y a pesar de llevar más de diez años se considera un concepto novedoso. Este paradigma es poco difundido actualmente, se encuentran muy pocas aplicaciones en el mercado que estén basados en él. POA ofrece ventajas adicionales sobre POO, las cuales se pueden aprovechar en desarrollo de aplicaciones en Pocket PC ya que estos dispositivos brindan recursos de memoria y procesamiento limitados. Este nuevo concepto de programación provee una separación transparente entre la arquitectura del sistema y la aplicación desarrollada. El proceso de desarrollo iterativo se vuelve más fluido, como también se pueden hacer más tarde en el ciclo de vida, las decisiones de diseño sin modificar una sola línea de código [JBAO]. El auge de las aplicaciones basadas en arquitecturas de comunicación punto a punto (P2P) también hace parte de una propuesta interesante para las Pocket PC, ya que brindar las ventajas de P2P en forma inalámbrica, es algo novedoso y apenas tratado, en los dispositivos móviles. . La idea de trabajar con la arquitectura P2P es muy interesante puesto que es un modelo donde cada componente es un cliente y servidor al tiempo, lo que permite que se prueben cada componente como parte fundamental de un sistema. Es así como surge la oportunidad de esta investigación, de la combinación de los elementos anteriormente nombrados: POA, dispositivos móviles y la arquitectura P2P.

4

4 ESTADO DEL ARTE A continuación se presenta una breve introducción a un nuevo paradigma de programación, POA. Se reseñará su historia y se describirán los conceptos elementales, así como ejemplos vigentes de aplicaciones de software que la utilizan. Luego se muestra en que consiste la arquitectura de comunicaciones P2P, sus ventajas frente a las demás y algunos de los ejemplos actuales, tanto herramientas de programación como aplicaciones. Finalmente se describe el estado actual de los dispositivos móviles, sus principales características y las herramientas que existen para programar en estos.

4.1 PROGRAMACIÓN ORIENTADA A ASPECTOS

Usualmente, en el desarrollo de software es necesario encriptar datos, acceder a una base de datos o mostrar un mensaje de texto en pantalla, estos requerimientos no funcionales se traducen en líneas de código repetidas y diseminadas en todo la aplicación. POA, por lo tanto nace de la necesidad de separar la lógica funcional y encapsular la lógica no funcional en aspectos, haciendo que el código de un programa de software sea más fácil de entender, mantener y expandir. A continuación se describe en que consiste POA.

4.1.1 Historia A principios de los años 90, se iniciaron investigaciones sobre reflection y variant strains. Esta investigación involucró casi 10 años de experiencia en el desarrollo de sistemas orientados a objetos, mostrando las limitaciones que trae éste en el desarrollo de sistemas complejos, distribuidos y sistemas donde la flexibilidad es crítica. En el Centro de Investigaciones de Palo Alto PARC de Xerox, un grupo liderado por Gregor Kiczales que empezó con investigaciones en reflection y protocolos de meta objetos fue abarcando las falencias de la POO; esto los fue envolviendo en el desarrollo y conceptualización de POA [SLAU] que junto con la colaboración de Cristina Lopes y Karl J.

5

Lieberherr [REIN] permitió a los programadores modularizar estructuras transversales en sus códigos. El trabajo de Kiczales y su grupo en AspecJ (extensión de Java que soporta aspectos) comenzó en 1997, el primer usuario externo fue en 1998 y la primera versión de AspectJ fue publicada en el año 2001 [KIC2].

4.1.2 ¿Qué es un Aspecto? “Un Aspecto es una unidad modular que se disemina por la estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de diseño como en la de implementación. Un aspecto de diseño es una unidad modular que se entremezcla en la estructura de otras partes del diseño. Un aspecto de programa o de código es una unidad modular del programa que aparece en otras unidades modulares del programa” según Kiczales. Un aspecto es una funcionalidad que es factorizada del modulo del cliente y es ejecutada sin mayor conocimiento de la parte del cliente, dónde los métodos se dedican a hacer lo que deben hacer y no incurren en otros aspectos como persistencia, sincronización o seguridad [GARS].

4.1.3 ¿Qué es la Programación Orientada a Aspectos? Es un paradigma de programación, su idea principal es la de separar los aspectos de los componentes, estableciendo toda una metodología para abstraer aspectos en el diseño y desarrollo, con la intención de mejorar la reutilización y encapsulamiento del modulo objetivo y la invocación arbitraria de código. POA puede ser considerada una quinta generación entre los paradigmas de programación “POA es un desarrollo que sigue al paradigma de la orientación a objetos, y como tal, soporta la descomposición orientada a objetos, además de la procedimental y la descomposición funcional. Pero, a pesar de esto, POA no se puede considerar como una extensión de la POO, ya que puede utilizarse con los diferentes estilos de programación“[GARS]. Otros beneficios que trae POA ante sus predecesores son [GARS]:

6

• Un código menos enredado, más natural y reducido. • La facilidad en la depuración (respecto a la lógica funcional) y

modificación del código. • Un conjunto grande de modificaciones que tiene un impacto mínimo

en el sistema. • Se tiene un código más reusable y que se puede acoplar y desacoplar

cuando sea necesario. • Una mayor facilidad para razonar sobre los requerimientos, ya que

están separadas y tienen una dependencia mínima. Para lograr todo lo anterior POA se basa en las técnicas de reflexión, con el fin de cargar clases en tiempo de ejecución y emitir nuevos objetos producto de la unión de Objetos y Aspectos. Además se debe definir interfaces entre los objetos y los aspectos, las cuales se denominan puntos de corte, estas sirven para indicar el lugar donde entra a actuar el Aspecto. Para mezclarse con los objetos, este proceso es posible gracias a una tercera entidad encargada de hacer el tejido entre Aspectos y Objetos en tiempo de ejecución, denominada tejedor (weaver). “El tejedor se encarga de mezclar los diferentes mecanismos de abstracción y composición que aparecen en los lenguajes de aspectos y componentes ayudándose de los puntos de enlace.” [GARS]

4.1.4 Los aspectos en el diseño La idea es identificar desde el diseño los aspectos; esto genera un grupo de ventajas [YASU].

• Facilita la creación de la documentación y el aprendizaje. • Permite que los desarrolladores tengan una visión de más alto

nivel y ayudando así a que los diseñadores de aspectos y los principiantes puedan aprender y documentar los modelos de aspectos de un modo más intuitivo, pudiendo incluso utilizar herramientas CASE para tener representado el modelado en forma visual

• La facilidad de documentación y aprendizaje influye en la reutilización de la información de los aspectos. Al saber cómo se diseña y cómo afecta a otras clases, es más fácil ver cómo se pueden utilizar de otra forma, lo que incrementaría la reutilización de los aspectos.

7

La propuesta que se realiza en la denominada UXF (UML Exchange Format, Aspect expansion) es extender el lenguaje para tener en cuenta a los aspectos en la fase de diseño. Esta consiste en añadir nuevos elementos al lenguaje, los cuales representan los aspectos y los puntos de corte, reutilizando elementos ya existentes para la relación clase-aspecto. Actualmente se pueden encontrar en el mercado programas y herramientas de desarrollo para POA. A continuación se presenta algunos de los más importantes.

4.1.4.1 AspectJ

AspectJ extiende al lenguaje Java con una nueva clase de módulos agrupados bajo el paquete “aspecto”. Los aspectos entrecruzan el código descrito en las clases, las interfaces y a otros aspectos. Estos mejoran la separación de requerimientos haciendo posible localizar de forma limpia los puntos de corte. En AspectJ, los aspectos son constructores que trabajan cortando de forma transversal la modularidad de las clases de forma transparente y cuidadosamente diseñada. “Por lo tanto, un aspecto puede afectar a la implementación de un número de métodos en un número de clases, lo que permite capturar la estructura de corte modular de este tipo de conceptos de forma limpia” [GARS].

4.1.4.2 JBoss 4.0

JBoss AOP, es el framework que soporta POA en la versión 4.0. Esta herramienta provee la habilidad de definir y unir los servicios de capa media (Middleware) transparente e implícitamente a POJOs (Plain old Java objects), lo cual se constituye como el plan a largo plazo de JBoss Group [JBOS].

8

4.1.4.3 Cool

COOL es un lenguaje creado por Xerox, cuya finalidad es la sincronización de hilos concurrentes. El lenguaje base que utiliza es una versión restringida de Java, ya que se han de eliminar los métodos wait, notify y notifyAll, y la palabra clave synchronized para evitar que se produzcan situaciones de duplicidad al intentar sincronizar los hilos en el aspecto y en la clase. En COOL, la sincronización de los hilos se especifica de forma declarativa y, por lo tanto, más abstracta que la correspondiente codificación en Java. COOL proporciona mecanismos para trabajar con la exclusión mutua de hilos de ejecución, el estado de la sincronización, la suspensión con guardas, y la notificación de forma separada de las clases. COOL esta basado totalmente en una implementación de POA, propia de Xerox.

4.1.4.4 Aspectos en .NET

En el framework de .NET existen varias propuestas para incluir extensiones a C# que majen POA ya que Common Lenguaje Runtime (máquina virtual de .net) soporta la introspección y la retrospección, condiciones necesarias para poder construir aplicaciones basadas en aspectos [SCHU], como son el caso de Aspect C#, Rapier LOOM.net, entre otras.

4.2 COMUNICACION ENTRE PARES

La arquitectura P2P, es similar a la tradicional arquitectura cliente-servidor, con la diferencia que los clientes son servidores y los servidores son clientes, además no existe un único servidor. Estas características son explotadas actualmente en Internet con herramientas de intercambio de archivos como Emule, Kazaa, Morpheus, Gnutella etc. A Continuación se describe esta arquitectura y se exponen algunos ejemplos.

9

4.2.1 Definición La tecnología P2P permite que cualquier dispositivo habilitado para conectarse a la red, pueda dar servicios a otro dispositivo en las mismas condiciones, dando acceso a cualquier recurso que tenga a su disposición. P2P es una extensión del concepto de robustez a través de la descentralización en Internet.

4.2.2 Ventajas La principal ventaja es que P2P distribuye la responsabilidad de proveer servicios entre todos los puntos de la red, además, P2P permite la comunicación mediante una variedad de rutas de la red, reduciendo la congestión y permite prestar servicios con una alta disponibilidad. Los siguientes, son algunos ejemplos de aplicaciones que trabajan con P2P.

4.2.2.1 Kazaa

Kazaa es un programa de difusión gratuita en Internet, con el cual se pueden compartir archivos de música, video y demás. Tiene como base la tecnología P2P y utiliza nodos comunes y supernodos (los cuales sirven para detectar y encontrar archivos por sectores y hacer búsquedas más grandes a nivel mundial). En el mercado existen otros programas que se basan en el mismo principio, por ejemplo: Grokster, Morpheus, LimeWare, eMule, etc.

4.2.2.2 JXTA

JXTA es un conjunto de protocolos para P2P (el nombre es derivado de la palabra "juxtapose", en inglés). Este soporta varios aspectos, como son el descubrimiento de otros dispositivos, servicios y la habilidad de intercambiar información o invocar servicios.

10

JXTA tiene como lenguaje de implementación Java. JXTA también ha sido implementado para J2ME para crear aplicaciones P2P en dispositivos móviles [JXPR] que incluyen la máquina virtual de java como los celulares de última tecnología y las PDA que utilizan el sistema operativo PALM OS.

4.3 CARACTERÍSTICAS DE LOS DISPOSITIVOS MÓVILES

Los dispositivos móviles hacen parte de la gran familia de los computadores. Normalmente se clasifican como computadores de bolsillo. Sus principales características principales son: • Tamaño: Actualmente existen tres tipos de tamaños promedio entre

estos dispositivos: los que se parecen a un portátil pequeño (Clamshell), los que caben en la palma de la mano (Palm size) y los que cuentan con la funcionalidad de un celular.

• Memoria: Los dispositivos móviles no tienen un disco duro físico,

almacenan la información en tarjetas de memoria RAM y ROM. Dependiendo del tipo de dispositivos, la memoria es más o menos grande, pero limitada en comparación de un computador de escritorio o un portátil.

• Forma de introducir los datos: Algunos funcionan con un esfero, teclado, almohadilla táctil o pantalla de contacto (dependiendo del modelo)

• Sistema operativo: Existen varias familias, Windows, Palm OS y las exclusivas del fabricante.

• Funcionalidad: Pueden guardar información personal, recibir y

enviar correos electrónicos, navegar en Internet, tomar fotos, grabar videos y reproducir música [ENT1].

4.3.1 Pocket PC Entre los PDA existe la familia de los Pocket PC, estos PDA tienen unas particularidades que los diferencian de las otras familias y esas particularidades son:

11

Tienen mayor velocidad de procesador y aunque su memoria es pequeña en comparación a los computadores, tienen la capacidad de expandirla con tarjetas CompactFlash y Multimedia, donde pueden alcanzar tamaños apropiados para el manejo de aplicaciones medianas. Además poseen tanto procesador como un sistema operativo estándar [ENT2]

4.3.2 Framework de desarrollo Entre los entornos para el desarrollo de aplicaciones en dispositivos móviles se destacan J2ME y Compact Framework.

4.3.2.1 J2ME El entorno de desarrollo de Java, presenta una serie de clases ya implementadas que hacen posible el desarrollo de aplicaciones sobre cualquier dispositivo móvil, ya que es independiente de la plataforma sobre la cual se desarrolla. El principal inconveniente de este Framework es su ineficiencia frente a su competidor Microsoft Compact Framework .NET, pues como J2ME debe ajustarse al sistema operativo donde se este utilizando las aplicaciones (lenguaje interpretado), requiere más tiempo de procesamiento en el dispositivo móvil [SLIW].

4.3.2.2 Compact Framework Este entorno es propiedad de Microsoft. Los programas que son desarrollados en este Framework requieren tener el sistema operativo Windows CE o Windows Mobile 2003. El entorno .NET Compact Framework emplea una versión aproximada de la versión completa de Microsoft .NET (para desarrollo de aplicaciones en computadores de escritorio). Se puede implementar aplicaciones en lenguajes C#, Visual Basic, Visual C, C++.

12

4.3.3 Emuladores Existen programas que puede imitar el comportamiento de los dispositivos móviles y estos se utilizan en el desarrollo de aplicaciones, pues es mucho más práctico probar inicialmente en estos y luego en el dispositivo físico. Los emuladores se pueden configurar para que tengan las disposiciones de memoria y procesador cercanas a los dispositivos, pero es muy común, que en el emulador corra de mejor forma un programa que el dispositivo real.

13

5 MARCO TEÓRICO A continuación se describen las bases teóricas de POA y sus etapas para la implementación. Adicionalmente se muestran las herramientas encontradas para el trabajo de POA sobre Microsoft .NET y en el Compact Framework. También se expone la herramienta para implementar aplicaciones P2P en dispositivos móviles JXME, modelo basado en JXTA.

5.1 CONCEPTOS BÁSICOS DE LA PROGRAMACIÓN ORIENTADA A

ASPECTOS

Tabla 1 Comparación entre los paradigmas [ASTE]

POA tiene sus inicios en la Programación Adaptativa, la cual se basa en la separación de conceptos (según Walter Hürsch y Cristina Lopes es un nuevo paradigma), que nacen de la necesidad de satisfacer requerimientos especiales de una aplicación, como lo son tiempo real, persistencia y distribución, entre otros; o también cuando se desea optimizar los algoritmos básicos de computación, como el control de

14

localización o la distribución [LOPE]. La mayoría de los artículos que hablan de las fases de análisis y diseño de POA utilizan la separación de conceptos o (Separation of Concerns) para identificar los aspectos que entrecruzan (crosscutting) una aplicación desarrollada bajo este paradigma [CLAR], así entonces, se puede decir que los aspectos se clasifican en conceptos específicos [LOPE]. “Las ‘6 C’, de Mehmet Aksit, hacen referencia a los seis características cuyos nombres en inglés comienzan con la letra ‘c’ y que son los siguientes: Entrecruzado: Un concepto se entrecruza con varias partes del sistema. Canónico: Brindar una implementación estable para los conceptos. Composición: Proveer factores de calidad, como adaptabilidad, reusabilidad y extensibilidad. Clausura: Mantener los factores de calidad del diseño en la etapa de implementación. Computabilidad: Crear un software ejecutable. Certificabilidad: evaluar y controlar la calidad de los modelos de diseño e implementación. Las “4 S” hacen referencia a conceptos sobre separación exitosa, de Harold Ossher, y corresponden a: Simultáneo: La coexistencia de diferentes composiciones son importantes. Auto-Contenido: Cada módulo debe declarar sus dependencias, para poder entenderlo individualmente. Simétrico: No debe haber distinción en la forma en que los diferentes módulos encapsulan los conceptos, para obtener una mayor confiabilidad en la composición. Espontaneidad: Debe ser posible identificar y encapsular nuevos conceptos, y aún nuevas formas de conceptos que se presenten durante el ciclo de vida del software.”[ASTE]

5.2 PROGRAMACIÓN ORIENTADA A ASPECTOS

El paradigma de POA no solo tiene impactos en la etapa de implementación de un proyecto de software, sino que también cambia la

15

manera de analizar y diseñar. A continuación, se exponen las etapas de análisis y diseño en el ciclo de vida de un proyecto de software.

5.2.1 Análisis Para identificar los aspectos que inciden en un sistema podemos basarnos en las preposiciones de Walter Hürsch y Cristina Lopes, quienes exponen como identificar y visualizar los conceptos; para esto, se tienen dos clases: Los Conceptos Básicos que se deben separar de los otros conceptos ya que representan el dominio de la aplicación y proveen la funcionalidad del sistema, por tal motivo deben estar separados de otros aspectos de la computación como la persistencia, la seguridad, alta disponibilidad, entre otros. Los Conceptos de Propósito Especial son usados para administrar y optimizar los Conceptos Básicos [LOPE]. Muchas veces los Conceptos de Propósito Especial satisfacen requerimientos no funcionales que se entremezclan en el código y traen problemas como baja reutilización y difícil mantenimiento. Es así como los aspectos se pueden clasificar dentro de los Conceptos de Propósito Especial y los componentes (objetos, métodos, procedimientos) en los Conceptos Básicos. Un componente puede ser claramente encapsulado en un procedimiento generalizado, mientras que un aspecto no [KICZ] Un procedimiento generalizado según Gregor Kickzales y su grupo, brinda un marco adecuado que facilita y clarifica la definición de un aspecto. Lo que propone es agrupar los lenguajes orientados a objetos, los proceduales y funcionales como lenguajes de procedimiento generalizado (LPG), ya que sus mecanismos claves de abstracción y composición pueden verse como agrupados bajo una misma raíz. Esa raíz tendría la forma de un procedimiento generalizado [ASTE]. Entonces, el análisis busca primero identificar los conceptos, luego clasificarlos en Básicos o de Propósito Especial. Con los conceptos de Propósito Especial se identifican los aspectos que entrecruzan el sistema.

16

Gráfica 1 Descomposición de conceptos, Analogía del Prisma [LADD]

La gráfica 1 muestra la analogía de un haz de luz, en este caso, los requerimientos de un sistema que pasan a través de un prisma identificador de conceptos y se descompone en cada uno de los conceptos que debe brindar el sistema (seguridad, autenticación, persistencia, lógica del negocio). De esta forma, se ilustra el proceso de desarrollo de conceptos [LADD].

5.2.2 Diseño En el Lenguaje de Modelado Unificado (UML por sus siglas en inglés) ofrece una Separación de Conceptos con la descomposición del sistema entre cuatro principales dimensiones: funcional (modelo de casos de uso), estática (diagramas de clases y paquetes), dinámica (diagramas de secuencia, colaboración, actividad y estado) y física (diagramas de componentes y despliegue) [MIHO]. En UML, los diagramas de interacción (diagramas de secuencia y colaboración) son usados para modelar los aspectos dinámicos de un sistema, modelando (en muchas situaciones) el flujo de control de un escenario en particular [BOOC]. Por tal motivo son los sugeridos a la hora de mostrar el diseño del sistema frente a los aspectos que entrecruzan el diseño (lógica no funcional). Una implementación basada en POA consiste en: [KICZ] [ASTE]

• El lenguaje base o componente para programar la funcionalidad. • Uno o más lenguajes de aspectos para especificar los aspectos

mismos. • Un tejedor de aspectos para la combinación de los lenguajes (base

y aspectos).

17

• El programa escrito en el lenguaje componente que implementa los componentes.

• Uno o más programas de aspectos que implementan los aspectos mismos.

Diseñar un sistema con base en los aspectos, requiere entender qué se debe incluir en el lenguaje base, qué se debe incluir dentro de los lenguajes de aspectos y qué debe compartir entre ambos lenguajes. El lenguaje componente debe proveer la forma de implementar la funcionalidad básica y asegurar que los programas escritos en ese lenguaje componente, no interfieran con los aspectos. Los lenguajes de aspectos tienen que proveer los medios para implementar los aspectos deseados de una manera intuitiva, natural y concisa [KICZ] [ASTE]. Adicionalmente el diseño debe especificar los puntos de corte y como el tejedor de aspectos combina los dos conceptos. Esta tarea se hace mediante reflexión, por tal motivo el tejedor de aspecto debe estar implementado con un lenguaje que utilice una máquina virtual.

5.3 SOPORTE DE LA PROGRAMACIÓN ORIENTADA A ASPECTOS

EN .NET

AspectJ es conocido como el principal API para la implementación de aspectos, esta basado en java y ha venido evolucionando desde el año 2001. Microsoft .NET no posee un proyecto de la trayectoria de AspectJ, pero cuenta con varias herramientas las cuales serán detalladas a continuación.

5.3.1 Aspectos en C# Existen varios proyectos y herramientas que intentan dar soporte a POA, los cuales pueden ser utilizados junto con el Framework de Microsoft.Net. Estos proyectos brindan soporte para declarar los Aspectos, puntos de corte y mecanismos de tejido; este últimos se puede hacer de manera dinámica o estática. Se basan en declaraciones en XML o en meta data, a través de atributos. Por lo general todos estos proyectos permiten implementar Aspectos en cualquier lenguaje soportado por el Framework de Miscrosoft.Net.

18

Durante el transcurso de esta investigación se han abordado los siguientes proyectos:

5.3.1.1 RAPIER-LOOM.NET [RLOM]:

Es un framework de desarrollo que soporta tejido dinámico y estático. Un tejido estático sucede cuando un aspecto teje por completo un objeto sin discriminar métodos, mientras que un tejido dinámico se permite seleccionar que métodos se desea interceptar para luego tejer. La principal ventaja de Rapier-Loom.NET es que no necesita un compilador adicional y no se necesita aprender una sintaxis específica. Esta basado en carga de propiedades en tiempo de ejecución, mediante el uso de la librería System.Reflection.Emit. La principal desventaja de Rapier-Loom.Net es que no se cuenta con un código fuente sino con assemblies dll. Un ejemplo que se desarrollo en el proyecto para probar RAPIER-LOOM .NET para probar su funcionalidad se anexa en la parte 6 Para codificar aspectos con C#.Net se debe referenciar la librería Loom al proyecto asociado, y se debe decir en qué lugar del programa (en este caso un método) se van a hacer los puntos de corte. Luego se declara un objeto que implementa la clase “Aspecto” (que provee Loom) y al instanciar las clases que tienen puntos de corte se hace una petición a una tejedora para obtener el objeto tejido, esto se realiza construyendo proxys dinámicos (apoderado construido en tiempo de ejecución) que capturan las llamadas al objeto y, según se especifique, llaman al aspecto antes o después de realizar la acción sobre el método.

5.3.1.2 ASPECT# [ASP#]: Al igual que Rapier-Loom, Aspect# es un framework de desarrollo que soporta tejido estático, su principal ventaja es que no necesita un compilador adicional y no se necesita aprender una sintaxis especifica. Trabaja la implementación de Proxies Dinámicos de Avalon, Primera implementación de DinamicProxy en .Net., los cuales están construidos con System.Reflection.Emit. Otras de las ventajas significativas de Aspect# es que, a diferencia de Rapier-Loom.Net, se puede utilizar el código fuente para extender su funcionalidad.

19

En los dos proyectos anteriores es necesario proveer una interfaz que defina los métodos en donde se realizarán los cortes, debido a que el Aspecto se relaciona con las interfaces y no con objetos concretos. Adicionalmente se debe hacer explícito en qué parte se encuentra el Aspecto. Para tener un mejor entendimiento del manejo de éste framework para aspectos, se hace una explicación en el anexo #5 acerca del desarrollo del ejemplo de ASPECT#.

5.3.1.3 ADD-IN DE MESALEM [ADDM]:

Es un plugg-in para Visual Studio.Net que permite crear clases de tipo Aspecto y un descriptor de éste, en formato XML. Provee un compilador adicional que se encarga de hacer el tejido según lo indique el Archivo descriptor, el cual debe ser único para todos los aspectos. Además es posible agregar métodos o miembros en tiempo de ejecución. Su principal desventaja es que no se cuenta con un código fuente, sino con assemblies dll, debe utilizar un compilador adicional y esta acoplado al IDE de Microsoft. Un ejemplo que se desarrollo con el Add-in de Messalem para probar su funcionalidad se anexa en la parte 4

5.3.2 Aspectos en Compact Framework Compact Framework es las versión de Microsoft .NET para dispositivos móviles, que tiene base en el mismo conjunto de librerías del Framework .NET, sin embargo librerías importantes como Remoting, para el manejo de procesos distribuidos y Emit para emisión de código en tiempo de ejecución, no fueron incluidas. A continuación analizaremos el impacto de la librería EMIT (System.Reflection.Emit) en la implementación de aspectos y tejedoras en Pocket PC.

5.3.2.1 El Namespace SYSTEM.REFLECTION.EMIT

Según Microsoft, el Namespace (agrupación lógica de clases) System.Reflection contiene clases e interfaces que proporcionan una vista administrada de los campos, métodos y los tipos cargados, con la

20

posibilidad de crear e invocar tipos dinámicamente mediante la emisión de meta datos y el Lenguaje intermedio de Microsoft (MSIL). Éste namespace facilita el manejo de reflexión en aplicaciones implementadas con la tecnología de .Net. Estos conjuntos de clases hacen de la implementación de soluciones basadas en reflexión, más fáciles de construir, por tal motivo las herramientas que soportan aspectos en .Net utilizan System.Reflection.Emit frecuentemente, ya sea para generar Proxies dinámicos, que capturen llamados en tiempo de ejecución, o para manipular dinámicamente el meta data.

5.3.2.2 RAPIER-LOOM.NET

Según el Soporte de Rapier-Loom.Net [KAIK]. (ver anexo #1), Compact Framework no puede soportar Rapier-Loom.net ya que su implementación esta fuertemente basada en el Namespace System.Reflection.Emit el cual no es soportado actualmente por Compact Framework. La utilización de Rapier-Loom.Net depende directamente de la arquitectura que se vaya a emplear, ya que si utilizamos alguna arquitectura que delegué la responsabilidad de los aspectos, sería posible adaptar el API bajo algunos criterios expuestos más adelante. Las pruebas realizadas y los cometarios en Internet [RLOM] hacen de ésta una herramienta madura y robusta.

5.3.2.3 ASPECT#

Este Framework utiliza el Proyecto de Avalon, el cual se basa en el Namespace System.Reflection.Emit. Al igual que Rapier-Loom.Net, la utilización de ASPECT# depende directamente de la arquitectura, ya que si el manejo de aspectos reside directamente en los dispositivos Pocket PC no es posible emplear ASPECT# en el API de comunicaciones.

21

5.3.2.4 ADD-IN DE MESALEM

Según Mesalem (Ver Anexo #3), no hay ningún problema a la hora de implementar aspectos con el add-in. Se desarrolló una aplicación para probar la estructura de Mesalem en una Pocket PC, el resultado fue satisfactorio, sin embargo esta aplicación era bastante sencilla. La aplicación que se desarrollo sobre una Pocket PC consistía en imprimir un mensaje de “Hola Mundo” (este mensaje es un servicio encapsulado en un aspecto) antes de realizar una operación de copiado entre una caja de texto y otra. Luego se implementó una aplicación con manejo de hilos y sockets, la cual no funcionó, no se pudo resolver los errores ya que no es una herramienta comercial y su soporte es precario, adicionalmente se comprobó que no es estable ya que posee muchos bugs, por ejemplo no muestra ni los errores de compilación ni los del archivo descriptor.

5.4 HERRAMIENTA PARA EL DESARROLLO DE APLICACIONES

BASADAS EN ARQUITECTURAS P2P PARA DISPOSITIVOS

MÓVILES

Entre los proyectos de arquitecturas P2P se destaca el API de JXTA, dedicado a implementar soluciones basadas en la comunicación directa entre nodos de una red. A continuación veremos la descripción de JXME, su arquitectura se puede convertir en un modelo a adoptar en los API de comunicaciones para dispositivos móviles.

5.4.1 JXME JXME es la implementación de JXTA también para J2ME que permite crear aplicaciones P2P en dispositivos móviles que soporten la máquina virtual de Java. El propósito del proyecto JXTA para J2ME es proporcionar funcionalidades compatibles de JXTA en los dispositivos móviles, usando Connected Limited Device Configuration (CLDC) y el Mobile Information Device Profile (MIDP). La gama de dispositivos que se incluyen están desde los teléfonos menos potentes hasta las PDA’s más

22

potentes. Usando JXTA para J2ME, cualquier dispositivo de MIDP puede participar en actividades de P2P con otros dispositivos de MIDP. Igualmente, un dispositivo de MIDP puede participar, con algunas restricciones, en actividades P2P con los pares de JXTA que funcionan en computadores, estaciones de trabajo y servidores. J2ME provee perfiles especiales diseñados para soportar los recursos limitados de los dispositivos móviles. Uno es el CDLC y el MIDP. Las anteriores son el núcleo de librería de clases y APIs especialmente diseñadas para trabajar en ambientes (limitados) de dispositivos móviles. Así que estos dos perfiles brindan las herramientas necesarias para crear poderosas aplicaciones del mundo Java [AROR]. Las falencias de MDIP radica en librerías limitadas, como reducción en los parsers de XML, solamente permite http de salida, no hay soporte para la seguridad. Estas limitaciones influyen en JXME ya que los dispositivos móviles actúan como pares o puntos finales que utilizan proxies para tener interoperabilidad con los protocolos de JXTA, desarrollan actividades de crear grupos y descubrir pares para los dispositivos conectados a él, igualmente para hacer parte de ellos, filtrar el trafico de JXTA y optimizar los anuncios. Su funcionamiento radica en un punto Wireless1 que envía una petición de descubrimiento a su correspondiente JXTA Relay. Éste a su vez propaga el mensaje por JXTA actuando como un proxy. Todas las respuestas son recolectadas por el Relay, el cual ajusta o compacta éstas para optimizar la transferencia, ya que estos dispositivos poseen un bajo ancho de banda, mientras tanto el par Wireless1 periódicamente le pregunta al Relay por respuestas. El Relay de JXME no es una implementación novedosa, ya son usados para acceder a JXTA a través de un firewall. Y no es lo mismo que un cliente servidor, ya que no existe una relación estática entre el punto y el Relay. Para que se comuniquen dos puntos, no es necesario que hagan parte del mismo Relay. Adicionalmente, un punto Wireless1 puede dinámicamente cambiar su Relay o tener múltiples Relays.

23

Gráfica 2 Arquitectura de JXME [AROR]

24

6 PROCESO DE DESARROLLO La investigación utilizó un proceso de desarrollo en cascada, pasando por las etapas de análisis, diseño, implementación y pruebas. En la etapa de diseño, fue necesario seleccionar una arquitectura para soportar la tecnología de Servicios Web (Web Services) en el API, ya que las demás tecnologías de manejo de procesos distribuidos no tienen soporte en Compact Framework. Para expresar cada uno de los artefactos del proceso de desarrollo, se empleó UML como lenguaje de modelado. En la etapa de análisis se emplearon los casos de uso, los que facilitan el entendimiento de los 7.requerimientos funcionales del API. Con esto se evita que se confunda el fin de un aspecto (que es encapsular la lógica no funcional del sistema) con el de un objeto (el cual debe representar la lógica funcional). En la etapa de diseño se utilizaron los diagramas de arquitectura, distribución, clases y de secuencia para la definición del desarrollo que se implementará. Finalmente en la etapa de pruebas se comparó el desempeño del API desarrollado en esta investigación, contra un API sin aspectos.

6.1 ETAPA DE ANÁLISIS

El API de comunicaciones para dispositivos móviles Pocket PC, es una investigación que busca mezclar nuevas tendencias en el mundo de la tecnología, poniendo en prueba bajo un contexto específico a POA. Se describen los requerimientos que deben satisfacer el API, con el fin de que futuros desarrollos puedan utilizarlo bajo la arquitectura P2P, así mismo como los requerimientos no funcionales descritos.

6.2 REQUERIMIENTOS FUNCIONALES

A continuación, se hará un análisis de cada uno de los casos de uso identificados en el levantamiento de los requerimientos funcionales del API para comunicaciones P2P. Esta documentación establecerá la interacción entre el actor y el sistema.

25

Conectar a la redP2P

Publicar Servicio

Buscar Servicio

Desconectar de laRed

Nodo

Consumir Servicio

Enviar Datos

«extends»

«extends»

«extends»

«extends»

«uses»

«uses»

Gráfica 3 Diagrama de Casos de Uso

Como se puede observar en la gráfica 3, el actor principal sobre el cual se muestra la especificación de los requerimientos funcionales, es el nodo que hace parte de la red P2P. El sistema inicia su funcionamiento partiendo desde el caso de uso “Conectar a la Red”. Luego el usuario del sistema, en este caso un Nodo de la red P2P, puede realizar varias acciones: “Buscar Servicio”, “Desconectar de la Red”, “Publicar Servicio” y “Consumir Servicio”. Estos dos últimos casos de uso permiten extender su funcionalidad para pasar al evento de “Enviar Datos” entre los Nodos. A continuación la descripción de cada uno de éstos.

6.2.1 Conectar a la Red P2P Breve Descripción El nodo se conecta para poder utilizar los servicios que le ofrece la red. Flujo de Eventos Paso 1: Iniciador del Caso de Uso Nodo Pocket PC. Paso 2 El nodo le pide al Relay se le autorice el acceso a la red P2P. Mandándole como parámetro la dirección del dispositivo móvil en la red.

26

Paso 3 El sistema registra el nuevo nodo en la red P2P. Tanto el Relay como el Directorio deben actualizar sus registros de nodos. Paso 4 El Relay le informa al nodo el resultado exitoso del ingreso a la red. Flujos Alternativos Primer Flujo Alternativo En caso en que el nodo no pueda establecer una comunicación con el Relay, se informará del error al usuario. Segundo Flujo Alternativo En caso en que el Relay no pueda establecer una comunicación con el Servidor de Índices, le informará el error al usuario. Requerimientos Especiales El nodo debe tener conexión con su Relay, del mismo modo, debe estar sujeto a una red TCP/IP. Precondiciones No Tiene alguna. Poscondiciones El nodo es creado y tiene a su disposición los servicios de la red P2P. Puntos de Extensión Cuando el nodo se encuentre conectado, este puede llamar a algunos de los siguientes casos de uso:

• Publicar Servicio • Buscar Servicio • Consumir Servicio • Desconectar de la Red

6.2.2 Publicar Servicio Breve descripción El nodo ofrece un servicio que puede ser consultado y consumido por cualquier nodo de la red.

27

Flujo de Eventos Paso 1: Iniciador del Caso de Uso Nodo Pocket PC. Paso 2 El nodo le pide al Sistema por medio del Relay que sea publicado un servicio que reside en el nodo, éste debe tener una descripción, la cual es necesaria para poder ejecutar búsquedas sobre ese servicio Paso 3 El Sistema ingresa en el Directorio el nuevo servicio, actualizando la lista de servicios que ofrecen los nodos de la red P2P. Paso 4 El Sistema le envía un mensaje de éxito al nodo. Flujos Alternativos Primer Fluido Alternativo En caso en que el nodo no pueda establecer una comunicación con el Relay, se informará del error al usuario. Segundo Flujo Alternativo En caso en que el relay no pueda establecer una comunicación con el Servidor de Índices, le informará el error al usuario. Tercer Flujo Alternativo En caso en que el nodo quiera publicar un servicio que ya se encuentra registrado, el sistema descartará este evento. Requerimientos Especiales Primer Requerimiento Especial El nodo debe tener conexión con su Relay, así mismo, debe estar sujeto a una red TCP/IP. Segundo Requerimiento Especial El servicio deberá estar en disposición de uso de cualquier componente de la red P2P para su atención.

28

Precondiciones El nodo previamente debe estar conectado a la red P2P. Poscondiciones El nodo ofrece un servicio que es conocido por la red P2P Puntos de Extensión No tiene alguna.

6.2.3 Buscar Servicio Breve Descripción El nodo realiza la búsqueda de un servicio según su descripción. Flujo de Eventos Paso 1: Iniciador del Caso de Uso Nodo Pocket PC. Paso 2 El nodo le pide al Sistema por medio del Relay, buscar los nodos que prestan un servicio, a partir de una descripción contenida en el nombre del servicio. Paso 3 El Sistema realiza la búsqueda de los nodos que prestan el servicio. Paso 4 El Sistema le envía la información de los nodos que prestan servicios que contienen esa descripción en el nombre. Flujos Alternativos Primer Fluido Alternativo En caso en que el nodo no pueda establecer una comunicación con el Relay, se informará del error al usuario. Segundo Flujo Alternativo En caso en que el Relay no pueda establecer una comunicación con el Servidor de Índices, se le informará el error al usuario. Tercer Flujo Alternativo En caso que no se encuentren resultados, el sistema informará al usuario de este evento.

29

Requerimientos Especiales El nodo debe tener conexión con su Relay, así mismo, debe estar sujeto a una red TCP/IP. Precondiciones El nodo previamente debe estar conectado a la red P2P. Poscondiciones El nodo obtiene los resultados de la búsqueda, donde se muestran los nodos que prestan los servicios buscados. Puntos de Extensión No tiene alguna.

6.2.4 Consumir Servicio Breve Descripción El nodo consume el servicio prestado por otro nodo en la red. Flujo de Eventos Paso 1: Iniciador del Caso de Uso Nodo Pocket PC. Paso 2 Una vez el nodo tenga la información de la ubicación del servicio que es solicitando en la red, el nodo le pide a su par el servicio deseado. Paso 3 El par que posee el servicio, le provee, del servicio al nodo solicitante. Flujos Alternativos En caso en que el nodo no pueda establecer conexión con el par, el sistema le informará del error. Requerimientos Especiales El nodo solicitante debe tener conexión con el par en una red TCP/IP. Precondiciones El nodo par u oferente al igual que el nodo solicitante debe estar previamente conectado a la red P2P. Poscondiciones El nodo solicitante consume el servicio ofrecido por el nodo oferente.

30

Puntos de Extensión No tiene alguno.

6.2.5 Desconectar de la Red Breve Descripción El nodo se desconecta de la red y el sistema elimina su referencia del directorio de búsquedas. Flujo de Eventos Paso 1: Iniciador del Caso de Uso Nodo Pocket PC. Paso 2 El nodo le pide al sistema que sea desconectado de la red. Paso 3 El sistema elimina las referencias y los servicios ofrecidos por el nodo. Flujos Alternativos En caso en que el nodo no pueda establecer conexión con el Relay, el sistema le informará del error. Requerimientos Especiales No tiene alguno. Precondiciones El nodo debe estar previamente conectado a la red P2P. Poscondiciones El sistema libera las relaciones con el nodo desconectado. Puntos de Extensión No tiene alguno.

6.2.6 Enviar Datos Breve Descripción El nodo servidor le envía al nodo cliente datos mediante un canal.

31

Flujo de Eventos Paso 1: Iniciador del Caso de Uso Nodo Pocket PC. Paso 2 El nodo servidor le envía al nodo cliente los datos solicitados. Paso 3 El nodo cliente recibe los datos enviados por el nodo servidor y los procesa. Flujos Alternativos En caso que exista un error en la comunicación de los datos, el sistema despliega un error para el nodo cliente y para el nodo servidor. Requerimientos Especiales El nodo cliente y servidor debe tener establecido un canal TCP/IP sobre el cual viajarán los datos. Precondiciones El nodo cliente debe informar previamente al nodo servidor que datos específicos desea que se le envíen. Poscondiciones El nodo cliente recibe los datos enviados por el nodo servidor Puntos de Extensión No tiene alguno.

6.3 REQUERIMIENTOS NO FUNCIONALES

Se entiende como lógica no funcional la escalabilidad, transparencia en la localización de servicios, soporte, concurrencia, disponibilidad, seguridad, rendimiento, tiempos de respuesta; requerimientos que inciden directamente en el desarrollo de un sistema. Los requerimientos descritos a continuación se seleccionaron a partir de las necesidades que debe suplir el API, y que no se cubren con los requerimientos funcionales. Los requerimientos no funcionales que se desarrollarán para esta investigación, son:

32

• Auditoria de Mensajes: Este requerimiento busca crear un Log de

sucesos de la red P2P, con el fin de que el administrador de la red pueda contar con esta herramienta para diagnosticar problemas y formular posibles soluciones, así mismo, puede hacer mediciones sobre la carga de la red, las horas de tráfico pesado y estadísticas sobre los servicios que se solicitan de forma más frecuente.

• Optimización de búsquedas: Es necesario que las búsquedas de

servicios que realizan los nodos de la red sean eficientes en tiempos de respuesta, adicionalmente, es deseable que las máquinas servidor gasten pocos recursos.

• Controlar El periodo de inactividad de los nodos: Si un cliente

está inactivo en la red, el sistema debe desconectar el nodo para evitar que consuma recursos de los servidores.

• Encriptación: Es necesario utilizar algoritmos de encriptación de los

datos que garanticen la privacidad de la información que viaja en la red P2P.

33

7 ARQUITECTURAS PROPUESTAS P2P es una arquitectura de comunicación que puede ser implementada de diferentes maneras. Por ejemplo, JXME exige que se incorpore un Relay que actué como Proxy de un conjunto de dispositivos móviles, con el fin de delegar procesamiento a un servidor y no agotar los recursos del dispositivo móvil. A continuación se muestran los criterios para escoger la arquitectura adecuada para el caso de estudio y cuales opciones surgen, expresadas en un diagrama de arquitectura y en uno de secuencia. Al finalizar esta sección se escoge una arquitectura, la cual se implementará en el desarrollo del API.

7.1 CRITERIOS PARA ESCOGER Y EVALUAR LAS DIFERENTES

ARQUITECTURAS

Como objetivo especifico de la primera etapa del Proyecto de Investigación, se pretende establecer el diseño de la arquitectura y del API de comunicaciones. Para escoger y evaluar la decisión que se va a tomar, se cuenta con los siguientes criterios:

• Posible disponibilidad de un código abierto para la implementación de los aspectos, pues nos ayudaría a independizar esta parte con el API en concreto.

• Flexibilidad en la forma de la creación de servicios y fácil

extensibilidad del API para futuras implementaciones. • Baja complejidad en la construcción y futuro mantenimiento del

API. • Agilidad en la adquisición de conocimientos en la curva de

aprendizaje. • Uso de recursos físicos (memoria, procesador) donde se

implementarán los servicios del API.

34

• El uso de la comunicación y del canal de red, distribución de la carga, y flujo de paquetes.

• Parte técnica: qué existe en POA que sea soportado por Compact

Framework para brindar servicios de comunicación.

7.2 OPCIONES DE ARQUITECTURAS PARA IMPLEMENTAR P2P EN

DISPOSITIVOS MÓVILES

Existe una forma conocida para implementar soluciones P2P en dispositivos móviles y es la planteada por JXME, la cual es basada en Relays. Según el documento de MSDN Magazine. “NET P2P: Writing Peer-to-Peer Networked Apps with the Microsoft .NET Framework” [OLSN] las maneras de implementar P2P son: • P2P puro. • P2P con servidor de descubrimiento simple. • P2P con servidor de descubrimiento y búsquedas. • P2P con servidor de descubrimiento, búsquedas y contenido. A continuación se describirá cada una de las opciones de implementación de la arquitectura P2P. JXME es una implementación P2P pura, sin embargo, la comunicación entre la red y los dispositivos móviles se hace a través de Relays. Con lo cual no se quiere decir que es la única manera de montar P2P en dispositivos móviles.

35

7.2.1 Arquitectura Basada en Relays

Puntos Wireless Red P2P Puntos Wireless

Relay Relay

Aplicación Servidor conServicios Basados en Aspectos

Aplicaciones Cliente

Aplicaciones Cliente

Gráfica 4 Diagrama de Arquitectura Basada en Relays Un patrón Proxy provee un sustituto u objeto que asume el lugar de otro, que controla el acceso al objeto el cual se esta reemplazando [GAMM]. Esta es la filosofía de los Relay, en donde reside los servicios que resultarían pesados (en términos de recursos de máquina) en los dispositivos móviles.

36

Gráfica 5 Diagrama de Secuencia Arquitectura Basada en Relays

El anterior diagrama de secuencia muestra la comunicación entre dos puntos de la red P2P. El primer punto busca el servicio en la red preguntando a los demás puntos, a través de su Relay, una vez que se ha encontrado el servicio el punto que los posee se le retorna.

7.2.2 P2P Pura

Red P2P

Gráfica 6 Diagrama de Arquitectura P2P Puro

37

Gráfica 7 Diagrama de Secuencia Arquitectura P2P Puro

Una arquitectura P2P pura es aquella que descubre de manera dinámica los demás puntos, de esta forma consigue los servicios que se desea, para ello es usual utilizar una comunicación broadcast. En el diagrama de secuencias anterior se muestra como un punto se desea conectar a la red P2P, para esto el punto tiene la responsabilidad de recorrer la red buscando a cada uno de los puntos notificándoles su llegada. Los demás deben actualizar su caché con el nuevo punto, igualmente el punto que se acaba de conectar actualiza su caché. Luego, cuando el punto desea buscar un servicio, éste debe recorrer el caché para obtener la dirección de los demás puntos e ir a preguntarle a cada punto si posee el servicio. Una vez encontrado servicio se obtiene directamente entre los dos puntos. Esta solución elimina los Relay lo que implica que los servicios van a residir en los dispositivos móviles. Como los servicios que se pretenden

38

prestar van a estar tejidos con aspectos, la implementación de esta arquitectura utilizando Compact Framework no es posible, debido a las limitantes tecnológicas. Por ejemplo, la ausencia del Namespace System.Reflection.Emit.

7.3 INTEGRACIÓN DE LAS ARQUITECTURAS P2P

A continuación se analizarán las ventajas y desventajas de cada una de las posibles arquitecturas que podría adoptar el API de comunicaciones, basados en los criterios expuestos anteriormente en este documento y en los modelos P2P para dispositivos móviles (Arquitectura basada en Relays y P2P pura) Se prescindió de la arquitectura basada en servidores de contenido, ya que es bastante ineficiente. Esto se debe a que el servidor es el encargado de obtener cada uno de los servicios que se van a publicar; lo que implica que cada vez que se conecta un punto al servidor, éste debe descargar todos los servicios que va publicar. Si estos servicios fueran archivos, en algún momento el servidor se desbordaría en su capacidad, lo que implica que esta solución está limitada por la capacidad del servidor.

39

7.3.1 P2P Puntos Comunicados por Relay

Red P2P

RelayRelay

Gráfica 8 Diagrama de Arquitectura P2P Puntos Comunicados por Relay

Esta arquitectura implementa una solución P2P pura, pero la comunicación entre los dispositivos móviles y la red P2P se hace a través de Relays, estos liberarán de servicios pesados (en términos de recursos de máquina) a los dispositivos móviles.

40

Gráfica 9 Diagrama de Secuencia Arquitectura P2P Puntos Comunicados por

Relay Cuando un dispositivo móvil se desea conectar a la red P2P debe notificar a su Relay, éste se encarga de notificar a los demás puntos utilizando los protocolos P2P establecidos y brindándole al mensaje servicios de conexión, transmisión, búsquedas y seguridad entre otros. Una vez se ha notificado a todos los puntos de la red que se ha conectado el dispositivo móvil, estos actualizan su caché y finalmente el dispositivo móvil también debe actualizar su caché. Cuando el dispositivo móvil quiere hacer una búsqueda en la red, éste debe recorrer cada una de las direcciones almacenadas en el caché y con la ayuda del Relay preguntar a los demás puntos si posee el servicio, una vez encuentre el punto con el servicio se procede a hacer la transmisión de datos.

41

El hecho de utilizar Relays hace que la implementación del API tenga que preocuparse por el canal de comunicación entre el Relay y los dispositivos móviles; además el P2P no es muy escalable y el trafico de red es alto; adicionalmente implementar una solución dinámica implica utilizar (en principio) comunicación broadcast lo cual puede ser costoso en términos de desarrollo, seguridad y demás [OLSN]. La tecnología disponible a implementar POA para esta solución específica es sencilla, lo que es una ventaja en la curva de aprendizaje. Al utilizar un Relay los servicios residen en este, optimizando el uso de recursos de máquina del dispositivo móvil, razón por la cual el proyecto JXME emplea Relays.

7.3.2 P2P con Servidor de Índices con Puntos Comunicados por Relay

Red P2P

RelayRelay

Servidor de Indices

Gráfica 10 Diagrama de Arquitectura P2P con Servidor de Índices con Puntos

Comunicados por Relay Esta arquitectura implementa una solución al utilizar un servidor en el cual se publican las direcciones de todos los puntos de la red,

42

adicionalmente cuando un punto hace una búsqueda le pide a este servidor que le retorne la lista de los puntos que poseen el servicio. Este modelo es bastante eficiente ya que optimiza el tráfico de red, adicionalmente es un modelo escalable a bajo costo en tiempo de desarrollo [OLSN]. La comunicación entre los dispositivos móviles y la red P2P se hace a través de Relays, estos liberarán de servicios pesados (en términos de recursos de máquina) a los dispositivos móviles.

Gráfica 11 Diagrama de Secuencia Arquitectura P2P con Servidor de Índices

con Puntos Comunicados por Relay Cuando un dispositivo móvil desea obtener un servicio, le pide al Relay que realice una búsqueda en el servidor de índices. El servidor de índices posee una lista con la dirección y los servicios que tiene publicado cada punto, una vez encuentre los servicios, el servidor retorna una o todas las direcciones de los puntos al Relay. El Relay le comunica al dispositivo móvil la dirección del servicio y éste empieza a establecer la comunicación directa a través de los protocolos P2P que provee el Relay. Esta arquitectura nos brinda la posibilidad de implementar servicios basados en POA y contar con implementaciones robustas y que proveen un código abierto, por consiguiente la implementación de servicios es bastante flexible y conveniente. El hecho utilizar Relays hace que la implementación del API tenga que preocuparse por el canal de comunicación entre el Relay y los dispositivos móviles. La tecnología disponible a implementar POA para esta solución específica es sencilla, lo que es una ventaja en la curva de

43

aprendizaje. Al utilizar un Relay los servicios residen en este, optimizando el uso de recursos de máquina del dispositivo móvil, razón por la cual el proyecto JXME emplea Relays. El soporte de Compact Framework para crear una aplicación cliente que se comunique con el Relay no es un problema, principalmente porque los aspectos no van a residir en los dispositivos móviles sino en el Relay.

7.3.3 P2P Servidor Índices

Red P2P

Servidor de Indices

Gráfica 12 Diagrama de Arquitectura P2P Servidor Índices

Esta arquitectura implementa una solución utilizando un servidor en el cual se publican las direcciones de todos los puntos de la red, adicionalmente cuando un punto hace una búsqueda le pide a este servidor que le vuelva la lista de los puntos que poseen el servicio. Este modelo es bastante eficiente ya que optimiza el tráfico de red,

44

adicionalmente es un modelo escalable a bajo costo en tiempo de desarrollo [OLSN]. Esta solución elimina los Relay lo que implica que los servicios van a residir en los dispositivos móviles. Estos servicios van a estar tejidos con aspectos y por tanto la implementación de esta arquitectura utilizando Compact Framework no es posible.

7.3.4 P2P con Servidor de Índices y Búsquedas

Gráfica 13 Diagrama de Secuencia Arquitectura P2P con Servidor de Índices y

Búsquedas Cuando un dispositivo móvil desea obtener un servicio, le pide al servidor de índices la dirección de los puntos que poseen el servicio. El servidor de índices posee una lista con la dirección y los servicios que tiene publicado cada punto, una vez encuentre los servicios, el servidor retorna una o todas las direcciones de los puntos al dispositivo móvil, luego éste empieza a establecer la comunicación directa con el punto seleccionado. Esta solución elimina los Relay lo que implica que los servicios van a residir en los dispositivos móviles. Estos servicios van a estar tejidos con algunos aspectos y lo por tanto la implementación de esta arquitectura se haría utilizando Compact Framework lo cual no es posible.

45

7.3.5 P2P con Servidor de Índices y sin Búsquedas

Gráfica 14 Diagrama de Secuencia Arquitectura P2P con Servidor de Índices y

sin Búsquedas Esta solución no explota en su totalidad el servidor de índices, debido a que las búsquedas las realiza cada nodo por separado, por tal motivo fue descartada como arquitectura para implementar el API de comunicaciones.

7.4 MÉTODO PARA ESCOGER LA ARQUITECTURA DEL API DE

COMUNICACIONES

Para escoger entre todas las diferentes arquitecturas mencionadas anteriormente se utilizará el método descrito por Kinnear [KINN]. En el cual basados en los criterios planteados, se hará una cuantificación de las arquitecturas para escoger la que mejor se acomode al proyecto de investigación. Cada criterio posee un peso, que indica la importancia dentro del desarrollo del API de comunicaciones. Al multiplicar éste peso por la calificación que obtuvo cada arquitectura en determinado criterio y sumándolas se obtiene la calificación total de la arquitectura.

46

Los pesos de los criterios fueron establecidos de acuerdo a la experiencia en desarrollar aplicaciones distribuidas y van en una escala de 1 a 10. La calificación de la arquitectura en cada criterio está valuada por: Malo: con calificación de 1 Regular: con calificación de 3 Bueno: con calificación de 5 Los pesos de los criterios indican la relevancia frente al API, en una escala de 1 a 5.

Código Abierto

Flexibilidad

Creación nuevos

servicios

Baja complejidad Implementación

Agilidad en la curva

aprendizaje

Recursos máquina

PPC

Comunicación distribución de carga y envío de paquetes

Soporte CF Total

Pesos De los Criterios 2 3 2 2 5 5 4

P2P con Puntos comunicados por Relay

5 5 3 5 5 1 5 91

P2P con servidor de indices(sin búsquedas) y puntos comunicado por Relays

5 3 3 5 3 1 5 75

P2P con servidor de indices(con búsquedas) y puntos comunicado por Relays

5 5 5 5 5 3 5 105

P2P pura con servidor de indices (sin búsquedas)

1 3 3 3 1 3 3 55

P2P pura con servidor de indices (con búsquedas)

1 3 3 3 1 5 3 65

Tabla 2 Selección de Arquitectura a Implementar.

Bueno 5Regular 3Malo 1

Tabla 3 Rangos de Calificación Como se puede observar, la arquitectura que obtuvo un mejor resultado en la comparación fue “P2P con servidor de índices (con búsquedas) y puntos comunicado por Relays”, por tal motivo, es la arquitectura

47

escogida para el desarrollo de esta investigación y su diseño se describe a continuación.

7.5 DISEÑO DE LA ARQUITECTURA

El diseño de los paquetes del API, están distribuidos de la siguiente forma:

7.5.1 Diseño de Paquetes

Gráfica 15 Diagrama de Componentes del API de Comunicaciones

Paquete del Cliente: En éste paquete se busca agrupar la implementación del la interfaz del usuario en la Pocket PC y los componentes de comunicación con el Relay. Paquete de Tipos: Se busca mantener las interfaces de los componentes que crean la funcionalidad del API con el fin de mantener una relación de estos, sin crear dependencias directas. Paquete de Servicios: Agrupa los servicios necesarios para crear una red P2P, además mantiene los servicios que entrecruzan la aplicación encapsulados en los Aspectos.

48

Paquete de Índices Contiene la implementación del Servidor de índices, basado en un patrón Observer con el fin de desacoplar los clientes del servidor. Paquete de comunicaciones Establece las conexiones directas utilizando el protocolo TCP, permitiendo una comunicación P2P y la comunicación con el Servidor de Índices.

7.5.2 Paquete del Cliente:

Gráfica 16 Diagrama de Componentes Paquete de La Interfaz del Cliente

Paquete del Relay Reside la lógica del Relay basado en el Patrón Proxy, ya que el Relay hace las veces de un punto en la Red P2P. Paquete de GUI Representa la lógica que reside en la Pocket PC y el conjunto de herramientas para implementar una aplicación sobre el API.

7.5.3 Paquete de Índices

IServidorIndiceServidorIndices

-iPuntosVector:Vector

+attach:void+detach:void+inform:void+iPuntos:Enumeration

Gráfica 17 Diagrama de Componentes Paquete de el Servidor de Índices

49

Basado en el concepto de un patrón Observer, el servidor de índices mantiene una lista de los puntos que tiene conectados facilitando las notificaciones de eventos en el servidor a un bajo acoplamiento.

7.5.4 Paquete Comunicaciones

Gráfica 18 Diagrama de Componentes Paquete de Comunicaciones

Cliente TCP establece una comunicación P2P con otros puntos de la Red a través del Relay; mientras que el ServidorTCP lanza un hilo, representado por la clase ServidorHiloTCP, que atiende a los llamados de los clientes en el servidor de índices.

7.5.5 Paquete de Tipos

Gráfica 19 Diagrama de Componentes Paquete de Interfaces

50

Posee las interfaces de las clases más importantes de la implementación, manteniendo una relación sin crear dependencias. Estas clases modelan el comportamiento del API y la manera de cómo se deben implementar las aplicaciones.

7.5.6 Paquete de Servicios

Gráfica 20 Diagrama de Componentes Paquete de Aspectos

Los Servicios 1,2 y 3 son la lógica funcional del API. En el Paquete de Aspectos, se almacenan los aspectos que entrecruzan los servicios.

51

8 ETAPA DE IMPLEMENTACIÓN DEL API En este punto se ilustra como se desarrolló el proceso de implementación del API.

8.1 EL TRABAJO DESARROLLADO EN MÁQUINAS VIRTUALES DE

JAVA PARA POCKET PC

A continuación se detalla el trabajo que se desarrolló en la plataforma de desarrollo Java en los dispositivos móviles. Se ilustran las máquinas virtuales con las cuales se trabajó, el API de JXME y finalmente se plantean conclusiones al respecto.

8.1.1 Máquinas Virtuales de Java para Pocket PC A continuación se enumeran las máquinas virtuales que se trabajaron para realizar las pruebas correspondientes a JXME. PERSONALJAVA: Es la máquina virtual de Java implementada por SUN. Aunque es bastante ligera, la información concerniente a ésta es precaria, tanto así, que no es clara la descarga y posterior instalación para sistemas operativos Windows-CE o Windows Mobile 2003. WEME (WebSphere Everyplace Micro Edition): Es la máquina virtual de Java implementada por IBM, de carácter comercial (se trabajó con una licencia trial), lo que limita la funcionalidad de desarrollo. Adicionalmente esta versión utiliza paquetes propios es decir no es una implementación genérica. EWE: Es una implementación que permite crear aplicaciones con una máquina virtual que trabaja sobre Java; los ejemplos encontrados trabajan con paquetes propios de EWE, es decir, no es una implementación genérica. Para el desarrollo de esta investigación, se han probado otras máquinas virtuales y SDKs como SuperWaba, pero ninguna de estas nos brinda un soporte para JXME ya que es necesario que los paquetes que se invocan sean genéricos a J2ME.

52

8.1.2 Trabajo Desarrollado en JXME Durante el desarrollo de éste Proyecto de Investigación se ha tratado la instalación y desarrollo de JXME en dispositivos Pocket PC, y la primera conclusión que se puede obtener, es que el paso de JXME a dispositivos Pocket PC no es transparente, ya que depende estrictamente de la máquina virtual de Java, debido a que necesita que ésta contenga paquetes propios de J2ME, para su funcionamiento. Se han tenido problemas de compatibilidad con las versiones de las máquinas virtuales encontradas. Ante los resultados obtenidos durante el trabajo con J2ME, JXTA y Java en dispositivos Pocket PC, resulta más beneficioso para la investigación crear un API nuevo basado en POO y diseñado en Compact Framework. Por consiguiente se tomó la decisión de realizar la comparación del API basado en POA; objetivo principal de esta investigación, frente a un API similar donde los aspectos que se encuentren en el desarrollo, se mantengan encapsulados en objetos y embebidos en POO; es decir, se quiere hacer un API con aspectos, basados en POA, y compararlo contra un API similar, basado en POO. El hecho de hacer la comparación entre dos APIs construidos en el mismo lenguaje de programación, permite mantener constante la variable de el framework de desarrollo, variable que inicialmente con el objetivo de este proyecto no era posible mantener; el hecho de comparar el API implementado en Microsoft .NET con uno similar en el mundo JAVA involucraba variables, de tiempo y rendimiento, que no eran pertinentes al verdadero objeto de esta investigación, el valor agregado de POA frente al paradigma de POO.

8.2 MODELOS DE IMPLEMENTACIÓN

El diseño del API de comunicaciones tuvo como base la arquitectura escogida, el paso a seguir es la elección de las tecnologías que servirán de plataforma para la construcción. La primera opción a seleccionar; es manejar procesos distribuidos a través de Remoting, sin embargo Compact Framework no lo soporta [BYNA]. La siguiente opción es implementar el API basados en socket, multihilos y manejo de flujos, serializando los objetos de la lógica.

53

8.2.1 Desarrollo Basado en Sockets, Mutihilos, Flujos Distribuidos y Serialización de Objetos

Cada uno de los componentes de la arquitectura fue implementado a modo de librerías dll. La aplicación cliente, que consume los servicios del API, fue construida en Windows Forms. Este API provee la funcionalidad de publicar, buscar y transferir archivos en la Red P2P. Los métodos de enviar y recibir datos fueron interceptados y tejidos por un aspecto construido en el framework de RapierLoom.Net, de tal manera que se lanzaba un Aspecto de encripción de manera dinámica. Al iniciar la aplicación, se levanta el Servidor de índices:

Gráfica 21 Inicio del Servidor de Índices y adición de un nuevo Nodo

Como se observa en la gráfica 21, el servidor escucha por notificaciones en el puerto 9092. Luego se inicializa el servidor Relay:

Gráfica 22 Inicio del Relay y adición de un nuevo Nodo

Como se observa en la gráfica 22, el Relay espera por nodos que deseen conectarse a la red, escuchando por el puerto 9090.

54

Luego se inicializa el Cliente:

Gráfica 23 Pantalla principal del Cliente

Una vez la aplicación ha subido, podemos publicar archivos para compartir, como un servicio a prestar:

Gráfica 24 Carga de un servicio

55

Tanto el Relay como el Servidor de Índices reportan un mensaje, para agregar un servicio a al Red P2P:

Gráfica 25 Mensaje de adición de servicios en el Relay

Gráfica 26 Mensaje de adición de servicios en el Servidor de Índices

Ahora cualquier cliente puede buscar este servicio; las búsquedas (optimizada con el uso de los aspectos) se hacen por descripción, por tipo o por una mezcla entre estas dos. Una vez se oprime el botón Buscar, la aplicación muestra los resultados que le retorna la Red P2P, cada resultado posee la dirección IP y la ruta del archivo que se desea transferir:

Gráfica 27 Mensaje de búsqueda en el Servidor de Índices

Gráfica 28 Mensaje de búsqueda en el Relay

56

Gráfica 29 Presentación de los resultados obtenidos en el Cliente

Una vez se oprime el botón solicitar servicio, la aplicación procede a guardar en el dispositivo de almacenamiento local el archivo que es transmitido por el Nodo publicador. La comunicación termina con un mensaje “Fin comunicación P2P”:

Gráfica 30 Presentación prestación de servicios en el Servidor de Índices

Todos los mensajes que viajan por la Red P2P son cifrados por el Aspecto de encriptación que intercepta los métodos de enviar y recibir. La encriptación se realizó a través del algoritmo de encriptación tiny, TEA por sus siglas en ingles [PBRO], ya que la clase System.Security.Cryptography no es soportada por Compact Framework [CRIM].

57

Para la instalación del API en dispositivos Pocket PC, fue necesario implementar la aplicación cliente de ejemplo, que consume los servicios del API, en Compact Framework.

Al ejecutar la aplicación, los errores de ejecución mostraron que existía un problema de serialización de los objetos con la clase BinaryFormatter, encargada de convertir a bits los objetos:

Gráfica 31 Error presentado por la serialización de objetos

Al acudir al soporte de Compact Framework para encontrar una solución a este inconveniente [BYNA] se encontró que Compact Framework no incluyó en su implementación la clase BinaryFormatter ni la clase SOAPFormatter, encargadas de la serialización de objetos a través de flujos. La única opción restante era implementar la serialización a través de la clase XMLSerializer. Al utilizar XMLSerializer se detectaron errores en tiempo de ejecución con los flujos que incurrían en la serialización. Se consultó en el soporte de Microsoft pero no se encontró ningún ejemplo o comentario de serialización a flujos distribuidos. En este punto de la investigación se llegó a la conclusión que implementar un Cliente para Pocket PC usando socket y multihilos para enviar objetos serializados, no es posible debido a las limitantes tecnológicas. Así que fue necesario buscar otra opción que si es soportado por Compact Framework, la cual se encuentra descrita a continuación.

58

8.2.2 Desarrollo Basado en Servicios Web Existe la forma de consumir servicios de manera sincrónica o asincrónica, a través de Servicios Web. Mediante los Servicio Web se ajustó el API para poder utilizar los métodos que debían proporcionar los servidores a los puntos, bajo el mismo diseño que se había evaluado previamente. Se encontró que existe la forma de consumir servicios de manera sincrónica o asincrónica, a través de Servicios Web. Estos servicios son métodos o clases expuestas en un Servidor Web como componentes remotos, muy similar a incluir una librería dll en un proyecto. Los Servicios Web XML brindan la posibilidad de manejar procesos distribuidos de manera similar a Remoting en .NET o RMI en Java, con la diferencia que en él se utiliza el protocolo HTTP para establecer la comunicación. Se realizaron varias pruebas para saber si esta tecnología soporta el diseño del API, anteriormente descrito, ya que las Pocket PC solo pueden consumir los Servicios Web y no los pueden alojar, es decir, no pueden brindar estos servicios. Adicionalmente la funcionalidad en Compact Framework, respecto a los Servicios Web es reducida frente a la que se obtiene en el Framework de .NET [BYNA]. Estas pruebas consistieron en la conexión entre una Pocket PC y un Servidor Web; Se enviaron objetos de lado y lado mediante la inclusión de las definiciones de los tipos de objetos con un atributo llamado XmlInclude. Una vez terminadas las pruebas, se llegaron a varias conclusiones; la primera es que las Pocket PC consumen de manera transparente los Servicios Web, y se pueden enviar objetos desde el servidor hacia las Pocket PC. Pero, al enviar una referencia remota de un objeto residente en la memoria del dispositivo móvil hacia el Servidor Web, se generan errores concernientes a la serialización XML. Por tal motivo sólo se pueden enviar datos primitivos desde la Pocket PC hacia el servidor (el mismo problema presentado al utilizar los socket). Este inconveniente se resolvió enviando datos primitivos hacia el servidor. Se implementaron clases comunes entre el servidor y el

59

dispositivo móvil los cuales encapsulan los datos que viajan por el sistema. En el desarrollo se utiliza el Patrón Observador - Observable para notificar al cliente Pocket PC que debe enviar datos a otro punto de la Red P2P. Este patrón permite desacoplar el cliente, que consume servicios y envía sus datos, de la lógica funcional del API. Según Gamma [GOF] existen dos formas de implementar un patrón Observador – Observable: la primera y comúnmente empleada se denomina modelo Push, en el cual los observadores son informados de los cambios de estado. Existe otro modelo llamado Pull, en el cual el observador, para evitar múltiples actualizaciones, asume la responsabilidad de preguntarle al observable por cambios de estado con lo cual él puede actualizarse. Aplicando el modelo pull al escenario de implementación del API, debido a que no se pueden enviar referencias de objetos alojados en la memoria de la Pocket PC al Servidor Web, el Cliente es el responsable de preguntarle al Servidor por medio del Servicio Web, si el Relay ha reportado cambios de estado, en este caso, peticiones de datos a la Pocket Cliente; este diseño hace que el los puntos o clientes de la Red P2P tengan colas para atender las peticiones, cada petición tiene la dirección IP del punto que desea el servicio para así hacer la transferencia. Cada cliente lanza un hilo para atender peticiones, que siempre están pendientes, otro simplemente para hacer peticiones y la transferencia se hace a través de flujos de archivos. En el anexo 7 se encuentra el diagrama de secuencia que ilustra detalladamente la interacción descrita en éste párrafo.

8.3 ADAPTACIÓN DE LA ARQUITECTURA DEL API

En el caso de la concepción de esta investigación fue necesario adaptar el diseño de la arquitectura basada en Relays, ya que este nos permite dar un soporte total a POA, pero con un cambio de tecnología, ya que la implementación basada en serialización de objetos, como se explicó anteriormente, no es soportada por Compact Framework. A continuación se ilustra el proceso de implementación del API desarrollado con la ayuda de los Servicios Web.

60

8.3.1 Arquitectura del API La forma como se comunica cada uno de los componentes en la arquitectura del API, se expone en la gráfica 32. Estos componentes son: los Nodos (Dispositivos Pocket PC, consumen y publican servicios), los Relays (Servidores que actúan como Proxy de un conjunto de puntos) y el Servidor de Índices (Servidor que ofrece servicios de búsquedas y de publicación de servicios). Para la comunicación entre los nodos se utiliza el protocolo de comunicaciones TCP/IP y los canales se construyen utilizando Sockets. La información que viaja por este medio esta en formato de bytes. Para las demás comunicaciones se utilizan Servicios Web, por lo cual el protocolo utilizado es HTTP; los canales usados utilizan SOAP para el envió de los datos entre servidor - cliente y la información que viaja por este medio se encuentra en formato XML

RED DE COMUNICACIÓN

TCP/IP via Socket

RELAY

SERVIDOR DE INDICES

RELAY

PUNTOS PUNTOS

XML

XML

XML

BYTES

XML

XML

SOAP via HTTP

SOAP via HTTPSOAP via HTTP

SOAP via HTTP

SOAP via HTTP

Gráfica 32 Comunicaciones entre los Elementos de la red P2P

61

La distribución de cada componente es independiente, pero los servidores pueden llegar a estar sobre una misma máquina. El limitante actual existente, es que los dispositivos móviles no pueden ser servidores Relay o Directorio, debido a que no pueden ofrecer Servicios Web. La distribución de componentes se aprecia en la grafica 33. Los bloques representan máquinas virtuales diferentes.

Client Rela Directori

ClienteLogica

Relay Directorio

RelayLDirectorioLG

AspectoDirectorioAspectoRelay

RelayLogicaDirectorioLogica

Tipos

Servicio ResultadoBusquedas Peticion Nodo

Fabrica

FabricaObjetosTejidosRapierLoom.NET

RelaySV DirectorioS

Servicios Web (Framework)Cliente de Servicios Web (Compact Framework)

Servicios Transversales

Gráfica 33 Diagrama de Distribución

Los componentes del Cliente están construidos en Compact Framewok. Los componentes del Relay y del Directorio están construidos en el framework de .NET. El Relay y el Directorio tienen sus propios aspectos (AspectoRelay y AspectoDirectorio) que encapsulan la lógica no funcional. Adicionalmente se pude observar la librería de Rapier-Loom necesaria para tejer aspectos y objetos en tiempo de ejecución.

62

Los servicios travesales que se utilizan en la aplicación se encuentran en el paquete Tipos. El cliente final interactúa con el paquete ClienteLogica directamente.

8.4 IMPLEMENTACIÓN DEL API

En este diagrama se puede visualizar las dependencias entre los paquetes que componen el API. Las referencias que se manejan en el sistema son de 4 tipos: Referencia web: Cuando un subsistema apunta a un Servicio Web. Referencia general: Cuando un subsistema apunta a otro subsistema directamente. Referencia con la fábrica para obtención de objetos remotos: Cuando se necesita obtener una referencia a un objeto que en tiempo de ejecución se tejerá con un aspecto. Está referencia es una referencia general. Referencia relativa: Esta referencia se obtiene después del proceso de tejido, por lo que no es explícita.

«subsistema»Paquete superior::Aspectos

«subsistema»Paquete superior::Directorio

«subsistema»Paquete superior::Fabrica

«subsistema»Paquete superior::LogicaCliente

«subsistema»Paquete superior::LogicaRelay

«subsistema»Paquete superior::Relay

«subsistema»Paquete superior::Tipos

«subsistema»Paquete superior::LogicaDirectorio

Librería de Windows

Servicio Web

Librería Pocket Pc

Referencia webReferencia general

Referencia con la fabrica para la obtención de objetos tejidosReferencia relativa, con el objeto tejido

Gráfica 34 Diagrama de Componentes

63

A continuación se explica cada uno de los paquetes detalladamente.

8.4.1 Implementación de los Aspectos POA no es un paradigma sencillo de entender, el concepto de interceptar clases y tejerlas para emitir un nuevo objeto en tiempo de ejecución, contrasta con la teoría de compilación y ejecución de aplicaciones, que normalmente se conoce y en la cuál se basan los demás paradigmas de programación. Nacen nuevos retos en todas las etapas del proceso de desarrollo de software. El análisis debe identificar claramente y de forma transversal los requerimientos no funcionales, que luego el diseño debe abstraer. El modelado debe emplear la buenas prácticas, como patrones de software, también se hace vital poseer un estándar a seguir en la implementación ya que esto permite que los aspectos puedan ser componentes que corten de manera transversal toda la aplicación. La parte de depuración de código mediante herramientas como el Debug, se puede decir que no existen actualmente para POA. Esto se debe a la incapacidad de seguir el rastro al código, ya que esté se está emitiendo en tiempo de ejecución mediante reflexión; lo que no es explicitó para la herramienta que hace la depuración. Visual Studio 2003 permite hacer Debug a las aplicaciones .NET; para la implementación del API, fue necesario probar los Aspectos mediante debuggin, encontrando que el rastro de las líneas de código salta de una clase a otra, haciendo difícil entender el funcionamiento de los aspectos. Este es uno de las desventajas a la hora de utilizar POA, sin embargo se espera que las herramientas que brindan manejo a los aspectos solucionen este inconveniente en un futuro.

64

ASPECTOS

Loom::Aspect

+AspectoAuditoria()+AgregarCliente(entrada args : object[], entrada insTejer : string)+AgregarServicio(entrada args : object[], entrada insTejer : string)+EliminarCliente(entrada args : object[], entrada insTejer : string)+interceptarBusqueda(entrada args : object[], entrada insTejer : string)+iniciarEscritura()+cerrarEscritura()

-instaciaTejida : string-log : StreamWriter-put : FileStream

AspectoAuditoria

+AspectoDirectorio()+interceptarBusquedaParaAgilizar(entrada args : object[])+actualizarBusquedas(entrada args : object[])+RefrescarBusquedas(entrada args : object[])+AgregarCliente(entrada args : object[])+AgregarServicio(entrada args : object[])+EliminarCliente(entrada args : object[])+interceptarBusqueda(entrada args : object[])

-marrResultadoBusquedas : Hashtable-aspAuditoria : AspectoAuditoria-instaciaTejida : string = "Directorio"

AspectoDirectorio

+AspectoRelay()+AgregarCliente(entrada args : object[])+AgregarCliente(entrada args : object[])+AgregarServicio(entrada args : object[])+EliminarCliente(entrada args : object[])+interceptarBusqueda(entrada args : object[])

-aspAuditoria : AspectoAuditoria-instaciaTejida : string = "Relay"

AspectoRelay

Gráfica 35 Paquete de Aspectos

Bajo la arquitectura planteada fue posible emplear los aspectos, superando las dificultades respecto al soporte de estos en los dispositivos Pocket PC, particularmente Compact Framework. Como se muestra en la gráfica 35, los aspectos en el API, hacen parte del namespace Aspectos, allí están agrupados de forma lógica las clases AspectoRelay (encapsula la lógica no funcional relacionada al Relay), AspectoDirectorio (encapsula la lógica no funcional relacionada al Directorio) y el AspectoAuditoria (encapsula la lógica no funcional relacionada a la auditoria del sistema). Uno de los aspectos implementados permite agilizar las búsquedas que se realizan sobre la red P2P, reduciendo el tiempo que gasta el Servidor de Índices en retornar al cliente el conjunto de resultados que cumplen con tal solicitud. Básicamente, lo que hace el aspecto es mantener actualizada una colección de respuestas (nodos que poseen un servicio) a posibles búsquedas que realicen los clientes, evitando que la aplicación siga su curso normal, ya que hacer una búsqueda por cada

65

solicitud es costoso en términos de tiempo y recursos de máquina del servidor. Otro aspecto que se implementó esta encargado de llevar una auditoria de los sucesos de la red P2P. Éste aspecto se encarga de vigilar todos los llamados realizados al Relay y al Directorio, interceptando de manera transversal el sistema y mostrando la gran potencialidad de los Aspectos como código que se factoriza y se convierte en un útil componente reutilizable. Todos los sucesos de la red quedan escritos en un archivo de texto en las máquinas del Relay y el Servidor independientemente. Un aspecto que fue incorporado al API se tuvo como base las actuales herramientas de intercambio de archivos a través de Internet, como kazaa, emule y demás, las cuales desconectan a sus usuarios si estos no han reportado actividad en un cierto tiempo, lo que se conoce como time-out. En el API el Relay es el encargo de realizar ese tipo de administración sobre sus nodos, así que el aspecto entrecruza esta funcionalidad. La estructura de los aspectos que contiene el API se basa en funciones que contienen la lógica del aspecto, cada función debe indicar mediante atributos (meta datos) a qué función se le realizará el punto de corte y de qué manera se llamará el aspecto. Adicionalmente dentro del aspecto, se debe recibir un arreglo de argumentos que representan los parámetros que también recibe la función equivalente desarrollada bajo otro paradigma diferente a POA. En el anexo 8, se describen cada una de las funciones que contienen los aspectos.

8.4.1.1 Funcionamiento de los Aspectos en el API El AspectoRelay tiene la función específica de interceptar la clase RelayLG, clase encargada de implementar la lógica de publicación del Servicio Web del Relay. El AspectoDirectorio intercepta la clase Directorio principalmente con el fin de agilizar las búsquedas que éste Servicio Web debe llevar a cabo. Finalmente el AspectoAuditoria es la clase que implementa lógica de crear el Log de sucesos de la red P2P, esto se hace tanto en el Directorio como en el Relay. Para entender como funciona POA aplicado en el API, se toma como caso de estudio el proceso que sigue el sistema cuando un nodo desea agregar un servicio a la red P2P.

66

El aspecto AspectoAuditoria (ilustrado como “Aspecto”) y la clase Directorio, serán los sujetos de este ejemplo. Tanto el aspecto como la clase son entidades totalmente independientes.

Gráfica 36 Relación entre la clase y el aspecto

El aspecto es una clase que hereda de Aspect, interfaz que provee la tejedora que se utilizó, Rapier-Loom.NET (normalmente las tejedoras que se probaron funcionan de manera similar). En la Gráfica 36 se puede observar, resaltado en color azul, los puntos de corte de la función AgregarServicio. Estos puntos de corte son especificados en atributos. En POA los puntos de corte deben especificar en qué lugar (objeto o función) se debe hacer el corte y en qué momento de la ejecución se debe incorporar el aspecto.

67

Como se muestra en la Gráfica 36, el corte se realizará en el método AgregarServicio del objeto que se le indique a la tejedora; la invocación es de tipo After, esto quiere decir que una vez se ejecute el método que se desea tejer, el aspeto entrará entrar en acción. Existen varios tipos de invocación del aspecto: After (después de), Before (antes de), After Throwing (luego de lanzar una excepción), After Returning (después de retornar), Instead (en vez de). Así mismo, existen diferentes formas de indicar en un punto de corte, en donde se realiza el corte: En un método específico, en todos o excluyendo a alguno. La lógica que contiene el aspecto consiste en tomar los argumentos de entrada y escribirlos al archivo de Log. Los argumentos de entrada del aspecto son exactamente los mismos del objeto, esto quiere decir que son del mismo tipo y con los mismos valores. Nótese que el objeto no tiene relación ninguna con el aspecto, solamente contiene la lógica funcional. Para crear la relación entre el aspecto y el objeto se le debe indicar a la tejedora que realice el proceso de tejido.

Gráfica 37 Tejido de un objeto y un aspecto

La Gráfica 37 muestra el código necesario para crear un objeto tejido, esto se hace a través de una interfaz que el objeto debe implementar(en éste caso se denomina IDirectorio). Es una buena práctica delegar la responsabilidad de crear objetos a una clase, por tal motivo el API contiene una fábrica que sigue el patrón Fábrica Abstracta para encapsular la lógica de construcción.

68

Gráfica 38 Ejecución del proceso de tejido

Así pues, cuando los otros objetos instancíen al objeto Directorio estos tendrán un objeto tejido, que se muestra en la Grafica 38, donde la costura roja indica que la tejedora coció el aspecto y el objeto basándose en los puntos de corte definidos.

Gráfica 39 Vista de la clase tejida

La Gráfica 39 muestra la estructura de la clase tejida que se construye en tiempo de ejecución. En un mismo método se unen tanto la lógica del

69

objeto como la lógica del aspecto, ya que utilizan los mismos argumentos, el aspecto, de color amarillo, puede emplearlos, claro esta que sin modificar su valor, ya que esto iría en contra de la integridad de la clase. El trozo de código del aspecto aparece debajo del de la lógica funcional ya que el llamado del aspeto tiene invocación de tipo after. Una vez finalice la ejecución tanto del aspecto como del objeto, volverán a ser entidades independientes, sin relación alguna, como se muestra en la gráfica a continuación reseñada.

Gráfica 40 Clases independientes luego de la ejecución

El mismo aspecto puede ser utilizado con diferentes objetos, y haciendo cortes en diferentes funciones de los objetos, todo a la vez.

Gráfica 41 Relación de Aspectos y Clases en tiempo de ejecución

Esto quiere decir que un aspecto es un código que es encapsulado para que se disemine transparentemente a través del código que representa la lógica no funcional. POA es muy útil si se tiene un diseño estandarizado que permita que un aspecto pueda cortar varias funciones.

70

8.4.2 Implementación del Cliente El paquete cliente representa la lógica con la cual interactúa el cliente final. Este paquete se compone de cuatro clases: ClienteLG: Representa un nodo de la red; es la clase con la cual se establece la comunicación entre el cliente final y el API. Conoce las otras clases del paquete e interactúa con cada una de ellas. En su construcción, recibe como parámetro una interfaz llamada INotificador, la cual se encarga de generar al cliente final los mensajes del sistema. Tiene una referencia Web con el Relay, con quien se comunica para poder interactuar con la red P2P. ConsumirServicio: Clase que abstrae la forma de obtener un servicio específico. Es un hilo que se inicia cuando un Nodo requiere un servicio y se termina cuando se ha obtenido el servicio. ServidorSolicitudes: Clase que abstrae la forma de ofrecer los servicios que publica un Nodo. Es un hilo iniciado por el Nodo y termina cuando se desconecta de la red. Transferencias: Clase que abstrae la comunicación entre un Nodo y otro. Brinda los servicios de enviar y recibir datos.

71

CLIENTE

+ClienteLG(entrada ntfNotificador : INotificador, entrada strNombreDirectorio : string)+AgregarCliente()+AgregarServicio(entrada strServicio : string, entrada numTamano : long)+AgregarServicios(entrada arrServicios : string[], entrada numTamanos : long[])+EliminarCliente()+Busqueda(entrada strDescripcion : string)+SolicitarServicio (entrada numSolicitado : int, entrada strServicio : string, entrada strRuta : string, entrada numTamano : long)

-mnumIdentificador : int-mrlyServicio : RelaySV-mntfNotificador : INotificador-mstrIpLocal : string-mstrNombreDirectorio : string

ClienteLG

+EnviarDatos(entrada strIp : string, entrada arrDatos : byte[], entrada ntfNotificador : INotificador)+EnviarDatos(entrada sckEnlace, entrada arrDatos : byte[], entrada ntfNotificador : INotificador)+EnviarDatos(entrada stmFlujo, entrada arrDatos : byte[], entrada ntfNotificador : INotificador)+RecibirMensaje(entrada sckEnlace, entrada y salida arrbytMensaje : byte[], entrada ntfNotificador : INotificador) : int+RecibirMensaje(entrada stmFlujo, entrada y salida arrbytMensaje : byte[], entrada ntfNotificador : INotificador) : int

+NUMPUERTO : int = 65000+FRAME_SIZE : long = 1024

Transferencias

+ConsumirServicio(entrada strRuta : string, entrada numTamano : long, entrada ntfNotificador : INotificador)+LanzarServidor()-RecibirServicio(entrada sckEnlace)

-mthtPrncipal : Thread-mnumPuerto : int-mtplEscucha : TcpListener-mstrRuta : string-mnumTamano : long-mntfNotificador : INotificador

ConsumirServicio

+ServidorSolicitudes(entrada numSolicitado : int, entrada ntfNotificador : INotificador, entrada strNombreServidor : string)+LanzarServidor()-PrestarServicio()

-mthtPrncipal : Thread-mnumSolicitante : int-mnumSolicitado : int-mstrServicio : string-mstrIp : string-mrlyServicio : RelaySV-mntfNotificador : INotificador

ServidorSolicitudes

-Crea

*

-Inicia

1

-Usa

*

Gráfica 42 Paquete cliente

72

8.4.3 Implementación del Relay Los servicios del Relay está separado en dos paquetes, el referente al Servicio Web y el que implementa la lógica del Relay. RelaySV: Es la clase por donde llegan los llamados al Relay. Consiste en un Servicio Web. Obtiene la referencia de la lógica mediante la tejedora de aspectos.

RELAY SERVICIO WEB

+RelaySV()+RelaySV(entrada strNombreDirectorio : string)-InitializeComponent()#Dispose(entrada disposing : bool)+AgregarCliente(entrada strIp : string) : int+AgregarServicio(entrada numIdentificador : int, entrada strServicio : string, entrada numTamano : long)+AgregarServicios(entrada numIdentificador : int, entrada arrServicios : string[], entrada arrTamanos : long[])+EliminarCliente(entrada numIdentificador : int)+Busqueda(entrada strDescripcion : string) : ResultadoBusqueda[]+AgregarSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+AtenderSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+ObtenerSoliciudes (entrada numSolicitado : int) : Peticion[]

-rlyLogica : RelayLG-components : IContainer = null

Relay::RelaySV

Gráfica 43 Paquete Relay Servicio Web

RelayLG: Se encarga de implementar la lógica expuesta a través del Servicio Web. En los métodos de ésta clase se puede encontrar la lógica de administración de nodos, lógica propia del Relay. Implementa la interfaz IRelay.

LÓGICA RELAY

+RelayLG(entrada strNombreDirectorio : string)+AgregarCliente(entrada strIp : string) : int+AgregarServicio(entrada numIdentificador : int, entrada strServicios : string, entrada numTamano : long)+AgregarServicios(entrada numIdentificador : int, entrada arrServicios : string[], entrada arrTamanos : long[])+EliminarCliente(entrada numIdentificador : int)+Busqueda(entrada strDescripcion : string)+AgregarSolicitud(entrada numSolicitante : int , entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+AtenderSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+ObtenerSoliciudes(entrada numSolicitado : int )

-mdsvServicio : DirectorioSVRelayLG

Gráfica 44 Paquete Lógica Relay

73

8.4.4 Implementación del Directorio Los servicios del directorio están separados en dos paquetes, el referente al Servicio Web y el que implementa la lógica del Directorio.

DirectorioSV: Es la clase por donde llegan los llamados al Directorio y al Manejador de solicitudes. Consiste en un Servicio Web. Obtiene la referencia de la lógica mediante la tejedora de aspectos.

DIRECTORIO SERVICIO WEB

+DirectorioSV()-InitializeComponent()#Dispose(entrada disposing : bool)+AgregarCliente(entrada strIp : string) : int+AgregarServicio(entrada numIdentificador : int, entrada strServicio : string, entrada numTamano : long)+AgregarServicios(entrada numIdentificador : int, entrada arrServicios : string[], entrada arrTamanos : long[])+EliminarCliente(entrada numIdentificador : int)+Busqueda(entrada strDescripcion : string) : ResultadoBusqueda[]+AgregarSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+AtenderSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+ObtenerSoliciudes(entrada numSolicitado : int) : Peticion[]

-dirLogica : IDirectorio-fabObjetos : FabricaObjetosTejidos-components : IContainer = null

Directorio::DirectorioSV

Gráfica 45 Paquete Directorio Servicio Web

Directorio: Se encarga de redireccionar las solicitudes del Servidor Web a la lógica. Implementa la interfaz IDirectorio para su tejido con aspectos. DirectorioLG: Se encarga de abstraer la lógica del Servidor de Índices, es decir las referencias de todos los nodos (y sus servicios) de la red. En los métodos de ésta clase se puede encontrar la lógica de administración de búsquedas. Es una clase que se basa en el patrón Singleton. Manejador de Solicitudes: Se encarga de mantener en un arreglo único todas las solicitudes que se quieren consumir. Es una clase que se basa en el patrón Singleton.

74

-DirectorioLG()+Instancia() : DirectorioLG+AgregarCliente(entrada strIp : string) : int+AgregarServicio(entrada numIdentificador : int, entrada strServicios : string, entrada numTamano : long)+AgregarServicios(entrada numIdentificador : int, entrada arrServicios : string[], entrada arrTamanos : long[])+EliminarCliente(entrada numIdentificador : int)-ObtenerIp(entrada numIdentificador : int) : string+Busqueda(entrada strDescripcion : string) : ResultadoBusqueda[]

-marrNodos : Hashtable-instance : DirectorioLG-numConsecutivo : int-MAX_RESULTADOS : int = 100

LogicaDirectorio::DirectorioL

-ManejadorSolicitudes()+Instancia() : ManejadorSolicitudes+AgregarSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+AtenderSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+ObtenerSoliciudes(entrada numSolicitado : int) : Peticion[]

-marrSolicitudes : ArrayList-instance : ManejadorSolicitudes

LogicaDirectorio::ManejadorSolicitudes

LÓGICA DIRECTORIO

+AgregarCliente(entrada strIp : string) : int+AgregarServicio(entrada numIdentificador : int, entrada strServicio : string, entrada numTamano : long)+AgregarServicios(entrada numIdentificador : int, entrada arrServicios : string[], entrada arrTamanos : long[])+EliminarCliente(entrada numIdentificador : int)+Busqueda(entrada strDescripcion : string) : ResultadoBusqueda[]+AgregarSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+AtenderSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+ObtenerSoliciudes(entrada numSolicitado : int) : Peticion[]+Directorio()

-dirLogica : DirectorioLG-manSolicitudes : ManejadorSolicitudes

LogicaDirectorio::Directorio

-Direcciona llamados

1

-Envia Solicitudes

1

Gráfica 46 Paquete Lógica Directorio

8.4.5 Implementación de las Clases Utilitarias Las interfaces y las clases que viajan en la aplicación se encuentran agrupadas en el paquete Tipos. Interfaces: IRelay: Interfaz que contiene todos los métodos que debe implementar la lógica del Relay. Es necesaria para la construcción del objeto tejido que une a RelayLG y a AspectoRelay. IDirectorio: Interfaz que contiene todos los métodos que debe implementar la lógica del Directorio. Es necesaria para la construcción del objeto tejido que une a Directorio y a AspectoDirectorio. INotificador: Interfaz que debe implementar el cliente final. Contiene los métodos necesarios para generar notificaciones sobre informaciones y errores generados en el sistema.

75

ITemporizador: Interfaz que exige el patrón Observador – Observable para notificar la desconexión de un nodo después de transcurrir un tiempo de inactividad. Clases que viajan: Nodo: Clase que abstrae el comportamiento de un elemento de la red. Contiene servicios y puede realizar búsquedas sobre estos. ResultadoBusqueda: Clase que abstrae los datos que se entregan al cliente producto de una búsqueda. Contiene un servicio y una dirección del cliente que ofrece lo ofrece. Servicio: Clase que abstrae el comportamiento de un servicio que se ofrece/consume por los nodos de la red.

76

+Servicio()+Servicio(entrada strDescripcion : string, entrada numTamano : long)+Descripcion() : string+Tamano() : long

-mstrDescripcion : string-mnumTamano : long

Tipos::Servicio

+ResultadoBusqueda()+ResultadoBusqueda(entrada numIdentificador : int, entrada strServico : string, entrada strIp : string, entrada numTamano : long)+Identificador() : int+Servicio() : string+Ip() : string+Tamano() : long

-mnumIdentificador : int-mstrServicio : string-mstrIp : string-mnumTamano : long

Tipos::ResultadoBusqueda

+GenerarNotificacion(entrada strMensaje : string)+GenerarExcepcion(entrada strMensaje : string, entrada objEx : Exception)+MostrarAvanceRecibir(entrada strServicio : string, entrada numPorcentaje : int)+MostrarAvanceEnviar(entrada strServicio : string, entrada numPorcentaje : int)

«interfaz»Tipos::INotificador

+AgregarCliente(entrada strIp : string) : int+AgregarServicio(entrada numIdentificador : int, entrada strServicio : string, entrada numTamano : long)+AgregarServicios(entrada numIdentificador : int, entrada arrServicios : string[], entrada arrTamanos : long[])+EliminarCliente(entrada numIdentificador : int)+Busqueda(entrada strDescripcion : string) : ResultadoBusqueda[]+AgregarSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+AtenderSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+ObtenerSoliciudes(entrada numSolicitado : int) : Peticion[]

«interfaz»Tipos::IDirectorio

+Nodo()+Nodo(entrada numIdentificador : int, entrada strIp : string)+EstaServicio(entrada strDescripcion : string) : ArrayList+AgregarServicio(entrada strServicio : string, entrada numTamano : long)+AgregarServicios(entrada arrServicios : string[], entrada numTamanos : long[])+Identificador() : int+Ip() : string

-mnumIdentificador : int-mstrIp : string-marrServicios : ArrayList

Tipos::Nodo

-Posee

*

-Contiene

*

TIPOS

+AgregarCliente(entrada strIp : string) : int+AgregarServicio(entrada numIdentificador : int, entrada strServicio : string, entrada numTamano : long)+AgregarServicios(entrada numIdentificador : int, entrada arrServicios : string[], entrada arrTamanos : long[])+EliminarCliente(entrada numIdentificador : int)+Busqueda(entrada strDescripcion : string)+AgregarSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+AtenderSolicitud(entrada numSolicitante : int, entrada numSolicitado : int, entrada strServicio : string, entrada strIp : string)+ObtenerSoliciudes(entrada numSolicitado : int)

«interfaz»IRelay

+NotificarFinTiempo()

«interfaz»ITemporizador

Gráfica 47 Paquete Tipos

77

9 ETAPA DE EVALUACIÓN La evaluación tiene por principal objetivo conocer que tan bueno es el API cuyo desarrollo tuvo como base POA frente a un API basado totalmente en POO.

9.1 ALCANCE

El alcance nos lleva a generar métricas que indiquen la rapidez y eficiencia de los API y compararlos entre sí.

9.2 ÍTEMS A PROBAR

Los ítems a probar con esta investigación son la velocidad de compilación y de ejecución, tiempos de respuesta y consumo de máquina en los distintos servidores.

9.2.1 VARIABLES

Variables Dependientes • Tiempo de compilación • Tiempos de respuesta • Porcentaje de uso del procesador • Porcentaje tráfico de red

Variables Independientes • Tiempo • Número de muestra • API a probar

Constantes • Aplicación que consume el API • Equipos • Lenguaje de programación

9.3 ESTRATEGIA

La estrategia que será utilizada en el desarrollo de las pruebas es la siguiente:

78

• Se realizarán los escenarios de pruebas en intervalos de tiempo iguales y de forma intercalada.

• Se adicionaran a la red un número igual de clientes realizando operaciones similares.

• Se utilizará el administrador de tareas de Windows para verificar el estado del servidor, en cuanto a la utilización de memoria, procesador y estado de la red.

• Se utilizará un proceso en Batch que envíe peticiones al servidor, cuando existan conexiones con los clientes para verificar el tiempo de respuesta.

• Se realizarán 10 muestreos por cada equipo en condiciones equivalentes.

9.4 RECURSOS

• Computadoras: Pentium II Celerón de 450 MHZ y 320Mb en memoria RAM Athlon de 1 GHZ y 512 Mb en RAM • Pocket PC:

Dell Axim x30 de procesador 320 MHZ y 64 Mb en memoria RAM. • Cables. • Conector Bluetooth. • Cronometro genérico.

9.5 IMPLEMENTACIÓN DEL API BASADO EN POO

Para la implementación del API a comparar, se utilizó el paradigma de programación POO, tomando como base el API existente en POA. Para esto fue necesario eliminar el paquete de aspectos y reemplazar el llamado del punto de corte por el código implicito, es decir, mezclar la lógica funcional con la no funcional.

79

9.6 ARQUITECTURAS A PROBAR

Arquitectura con la lógica no funcional modelada en los aspectos

Servicio Web

Lógica de Cliente

Servicio Web

Lógica Funcional

Lógica Funcional

Aspectos

Cliente Relay Servidor Índices

Gráfica 48 Arquitectura a probar con aspectos

Arquitectura con la lógica no funcional modelada en los objetos

Lógica Funcional y No funcional

Servicio Web

Lógica de Cliente

Servicio Web

Lógica Funcional y No funcional

Relay Servidor ÍndicesCliente

Gráfica 49 Arquitectura a probar sin aspectos

Aspectos en donde se encapsula la lógica no-funcional

Proceso de tejido

Objetos con la lógica funcional y no funcional La diferencia entre los API a comparar radica en la forma de modelar los requerimientos ajenos a la lógica del negocio.

80

9.7 ESCENARIOS

Se definieron los escenarios de la siguiente manera: T0: Se refiere al tiempo de compilación en modo Debug en la herramienta de desarrollo T1: Es el tiempo de compilación en modo release en la herramienta de desarrollo T2: El Tiempo de carga del programa en modo Debug T3: El Tiempo de carga del programa en modo Release T4: Es el consumo de procesador y tiempo del servidor T5: El Tiempo de respuesta del servidor T6: El Tiempo de respuesta durante el envió de datos entre los nodos T7: El Tiempo de búsquedas en los nodos

9.8 CONVENCIONES

AP: Aplicación RL: Relay SI: Servidor de Índices ND: Nodo ACA: API con aspectos ASA: API sin aspectos

81

10 PLAN DE PRUEBAS

A continuación se muestra el plan de pruebas a realizar en la investigación, cada una de las hojas del árbol representa una prueba a realizar.

PRUEBAS API

ACA

T0

T2T1

T3

ND T7

AP

SIT4T5

RL T4T5

ASA

T0

T2T1

T3

ND T7

AP

SI T4T5

RL T4T5

ND T6

Gráfica 50 Plan de Pruebas

82

10.1 ANALISIS DE LAS PRUEBAS

Las pruebas se llevaron a cabo con los recursos anteriormente mencionados, a continuación se hará el análisis de las cuarenta pruebas realizadas, sus resultados se encuentran registrados en el Anexo 9. En el Anexo 9.4 se muestra la tabla de varianzas para cada una de las pruebas que se realizaron. Mostrando que la dispersión de los resultados con relación a la media se encuentra en un intervalo de

lo que quiere decir que las muestras son similares. La media, considerada promedio en el Anexo 9.4, muestra una diferencia en tiempos de hasta 3.37s y una diferencia porcentual de hasta 1.50%, lo que es considerado despreciable e indica que los dos APIs tiene un rendimiento similar. A continuación se analiza detalladamente cada resultado de las pruebas explicado el porque de su comportamiento. AP-T0 TIEMPO DE COMPILACION DE LA APLICACIÓN EN MODO DEBUG EN LA APLICACIÓN El modo Debug, en una herramienta de desarrollo, se considera la compilación de una aplicación en la que se cargan las herramientas para hacer depuración. Por tal motivo se espera que los tiempos de compilación sean más lentos que el modo Release. Como se muestra en el Anexo 9.5, la diferencia entre el equipo 1 y el equipo 2 se mantiene constante, lo que es despreciable, ya que es apenas obvio que la máquina más potente Equipo 2 tenga mejores tiempos de respuesta. En las pruebas realizadas a los APIs se obtuvieron los siguientes promedios:

• API con Aspectos: 00:16:15s • API sin Aspectos: 00:09:07s

Una diferencia en promedio de 00:07:08s a favor del API sin Aspectos. Esta diferencia es normal teniendo en cuenta que el API con aspectos debe cargar en compilación la librería de Aspectos Rapier-Loom.NET, adicionalmente posee un mayor número de clases, las cuales son necesarias para dar soporte a POA.

83

AP-TI TIEMPO DE COMPILACIÓN EN MODO RELEASE EN LA HERRAMIENTA DE DESARROLLO EN LA APLICACIÓN El modo Release, en una herramienta de desarrollo, se considera a la compilación de una aplicación que tiene como objetivo obtener una versión definitiva. A diferencia del modo Debug, esta compilación simplemente carga las clases necesarias, suponiendo tiempos de compilación mucho más cortos. Al igual que la prueba anterior, se considera despreciable la diferencia en tiempos entre los dos equipos de pruebas, ya que tienden a ser constantes. En las pruebas realizadas a los APIs se obtuvieron los siguientes promedios:


De nuevo es el API con Aspectos el que presenta mejores tiempos de respuesta, con una diferencia promedio a favor de 00:08:19s. Al igual que la prueba anterior, la diferencia radica en que el API con Aspectos debe cargar la librería para soporte de Aspectos Rapier-Loom.NET y además posee clases adicionales para poder soportar POA. AP-T2 TIEMPO DE CARGA DEL PROGRAMA EN MODO DEBUG EN LA APLICACIÓN Esta prueba busca medir el tiempo que demora en cargar el API, ya compilado como dll, más la aplicación ejemplo que se desarrolló. Cargando las herramientas necesarias para hacer depuración de errores sobre la aplicación. En las pruebas realizadas se obtuvieron los siguientes promedios:


Esta vez la diferencia promedio a favor la obtuvo el API con Aspectos. Esto se debe a que el API con Aspectos carga dinámicamente las clases mediante el uso de Reflexión, creando las referencias entre objetos en tiempo de ejecución, no en tiempo de compilación. La diferencia promedio es de 00:08:88s.

84

AP-T3 EL TIEMPO DE CARGA DEL PROGRAMA EN MODO RELEASE EN LA APLICACIÓN Esta prueba busca medir el tiempo que demora en cargar el API, ya compilado como dll, más la aplicación ejemplo que se desarrolló. En las pruebas realizadas se obtuvieron los siguientes promedios:


Al igual que la prueba anterior la diferencia promedio a favor la obtuvo el API con Aspectos. Esto se debe a que el API con Aspectos carga dinámicamente las clases mediante el uso de Reflexión, creando las referencias entre objetos en tiempo de ejecución, no en tiempo de compilación. La diferencia promedio es de 00:01:04s. SI-T4 CONSUMO DE PROCESADOR Y TIEMPO DEL SERVIDOR DE INDICES Para realizar esta prueba se midió el uso de recursos del Servidor de Índices haciendo una rutina de conexión de un cliente, que consistió en conectar un cliente y hacer una búsqueda.

• API con Aspectos: 00:35:19s; uso de procesador: 31% • API sin Aspectos: 00:50:37s; uso de procesador: 26%

La diferencia promedio es de 00:15:28s a favor de el API con Aspectos, sin embargo el consumo de procesador es de un 5% más que el API sin Aspectos. El API con Aspectos da mayor velocidad por su proceso dinámico, pero éste proceso de corte y tejido de objetos se ve reflejado en mayor consumo de procesador. SI-T5 TIEMPO DE RESPUESTA DEL SERVIDOR DE INDICES Para realizar esta prueba se midió el tráfico de red y el tiempo que se demora haciendo una rutina de conexión de un cliente, que consistió en conectar un cliente y hacer una búsqueda.

• API con Aspectos: 00:29:55s; tráfico de red: 76% • API sin Aspectos: 00:32:47s; tráfico de red: 78%

Esta prueba muestra que los tiempos de respuesta favorece al API con Aspectos en 00:03:08s de diferencia utilizando un 2% menos de tráfico de red. Esto se debe a que el API sin Aspectos es más acoplado haciendo que los mensajes que viajan entre la red sean más pesados.

85

RL-T4 CONSUMO DE PROCESADOR Y TIEMPO DEL RELAY Para realizar esta prueba se midió el uso de recursos del Relay haciendo una rutina de conexión de un cliente, que consistió en conectar un cliente y hacer una búsqueda.

• API con Aspectos: 00:25:42s; uso de procesador: 21% • API sin Aspectos: 00:41:45s; uso de procesador: 17%

La diferencia promedio es de 00:24:03s a favor de el API con Aspectos, sin embargo el consumo de procesador es de un 4% más que el API sin Aspectos. El API con Aspectos da mayor velocidad por su proceso dinámico, pero éste proceso de corte y tejido de objetos se ve reflejado en mayor consumo de procesador. RL-T5 TIEMPO DE RESPUESTA DEL RELAY Para realizar esta prueba se midió el tráfico de red y el tiempo que se demora haciendo una rutina de conexión de un cliente, que consistió en conectar un cliente y hacer una búsqueda.

• API con Aspectos: 00:16:33s; tráfico de red: 52% • API sin Aspectos: 00:17:43s; tráfico de red: 64%

Esta prueba muestra que los tiempos de respuesta favorece al API con Aspectos en 00:01:10s de diferencia utilizando un 12% menos de tráfico de red. Esto se debe a que el API sin Aspectos es más acoplado haciendo que los mensajes que viajan entre la red sean más pesados. ND-T7 TIEMPO DE BÚSQUEDAS EN LOS NODOS Esta prueba consiste en medir el tiempo de publicar un servicio y hacer una búsqueda sobre el mismo servicio.


En esta caso es el API sin Aspectos quien tiene menor tiempo de respuesta con una diferencia de 00:00:71s, aunque la diferencia es muy pequeña, 71 milisegundos, se esperaría que el API con Aspectos tuviera un tiempo de respuesta superior dado los resultados de pruebas anteriores, sin embargo 71 milisegundos puede considerarse desfase estadístico. ND-T6 TIEMPO DE RESPUESTA DURANTE EL ENVIÓ DE DATOS ENTRE LOS NODOS Para realizar esta prueba se enviaron varios archivos de diferentes tamaños entre dos Pockets y se calculo la razón promedio

86

00:13:23s/MB. Lo que quiere decir que el API con Aspectos transmite 1MB en aproximadamente 13 segundos.

10.2 ANALISIS DE IMPACTO DE POA

A partir de los resultados obtenidos se pretende realizar un análisis que muestre el verdadero valor de hacer desarrollos basados en POA frente a los desarrollos basados a POO. Como se pudo ver previamente, en el análisis de las pruebas, el impacto a nivel de desempeño es despreciable debido a que las diferencias son poco significativas. A continuación se mirará el verdadero impacto de POA en el producto.

10.2.1 METRICAS PARA POA

Basados en estudios previos de métricas enfocadas en POA, se seleccionaron algunas de las más dicientes a la hora de comparar los dos paradigmas de programación. Complejidad Ciclomática Mide el número de decisiones lógicas en un segmento de código y cumple con los dos componentes:

Descriptivo, es aquel que identifica código susceptible a errores, difícil de entender, difícil de modificar, difícil de probar y demás. Prescriptivo, es aquel que identifica los pasos operacionales para ayudar a controlar el software, por ejemplo: dividir módulos altamente complejos en varios módulos de menor complejidad o indicar la cantidad de pruebas que deben ejecutarse para cada módulo. [ZMIL]

Máxima Complejidad Es el número de relaciones de la clase que más tiene relaciones [ZVED]

Complejidad cíclica

Tipo de procedimiento

Riesgo

1-4 Un procedimiento Simple

Bajo

5-10 Un procedimiento bien estructurado y estable

Bajo

87

Complejidad cíclica

Tipo de procedimiento

Riesgo

11-20 Un procedimiento más complejo

Moderado

21-50 Un procedimiento complejo

Alto

>50 Extremadamente problemático

Muy Alto

Tabla 4 Convenciones para métricas de complejidad Reuso El reuso mide el número de llamados a una función desde otras partes del código. Sentencias Métrica que mide el número de sentencias por línea de código. Beneficio Beneficio POA, que mide cual es el beneficio de introducir aspectos. Para ello, define una relación de esfuerzo de desarrollo entre una implementación sin considerar aspectos, y otra donde se aplica el paradigma. Un valor de resultado mayor que uno significa un impacto positivo de la utilización de aspectos. Se tomó en cuenta el factor de desarrollo propuesto por Rich Rice. Este factor establece que para un sistema pequeño el tiempo de desarrollo promedio en Java es de 10 horas/programador, mientras que en AspectJ es de 2 horas/programador. [ZPOA] En esta investigación se asume que el factor de desarrollo de Java es similar en C# y el factor de desarrollo en AspectJ es similar al de la herramienta Rampier Loom.Net.

rrolloPOAFactorDesaspectosTamañoConArrolloPOOFactorDesaspectosTamañoSinAOABeneficioP

××=

ctosTamañoAspeásicaionalidadBTamañoFuncspectosTamañoConA +=

Limpieza Mide el porcentaje de código que se depura de la funcionalidad básica al introducir aspectos. [ZPOA]

88

( )spectosTamañoSinA

ásicaionalidadBTamañoFuncspectosTamañoSinALimpieza 100××=

10.2.1.1 RESULTADO DE LAS METRICAS

Se utilizaron las siguientes herramientas de calculo de métricas para C#.NET, CCMetrics [ZWOO] y devMetrics [ZVED]. Estas herramientas buscan cargar los módulos del software y arrojar los resultados de las mediciones estándar, algunas de las cuales se explicaron anteriormente.

Complejidad Medio por

Clase

Complejidad de Reuso

Código Reusado

Directorio 7,67 60,87% 62,55%Relay 18,5 21,62% 79,17%Directorio 8,33 64% 56,45%Relay 15 31,11% 79,86%

ASA

CCMetrics

ACA

Tabla 5 Resultados obtenidos con la herramienta CCMetrics

Complejidad Ciclomática

Total

Máxima Complejida Sentencias Total

Sentencias

Directorio 37 8 93Relay 38 2 115Directorio 40 12 167Relay 51 4 206

ASA 489

devMetrics

ACA 476

Tabla 6 Resultados obtenidos con la herramienta devMetrics

Como se puede ver en las tablas 5 y 6, el API con aspectos tiene una menor complejidad en su implementación que el API sin aspectos, así mismo, un mayor porcentaje de código reusado. El número de sentencias que contiene el API con aspectos es menor, puesto que se reduce los llamados a la lógica no-funcional y favorece a tener un código mejor estructurado.

ACA ASA Tamaño AspectosTamaño

Funcionalidad Básica Benefício LimpiezaRelay 20480 25380 4900 15580 6,19628906 38,6130812Directorio 24576 28672 4096 20480 5,83333333 28,5714286

Tamaños en bytes

Tabla 7 Métricas de Beneficio y Limpieza

89

Los resultados indican que existe un beneficio grande con la introducción de los aspectos en el API, debido a que los valores que se obtuvieron son mayores a 1. Adicionalmente, la métrica de limpieza muestra un porcentaje de reducción del código del 38% en la lógica del Relay y del 28% en la lógica del Directorio con respecto a la implementación basada en objetos.

10.2.2 COMPARACIONES DE LINEAS DE CODIGO

Para realizar estas pruebas se utilizaron las herramientas Counting Lines of Code in C# [ZASA] y Simple Source Line Counter in C# [ZBOL]. Esta prueba consistió en hacer un análisis de la cantidad de líneas de código de cada una de las implementaciones del API. Cabe decir que las dos implementaciones hacen exactamente lo mismo. El conteo de líneas de código es hecho sin contar los comentarios, regiones ni corchetes. El API sin aspectos tiene un total de 1847 líneas en 26 archivos, mientras que el API con aspectos tiene 2031 líneas en 31 archivos de código fuente. A simple vista resultaría mejor prescindir de los aspectos, ya que añade más archivos y líneas de código:

Clases Adicionales Lineas de CódigoAuditoria 41

Irelay 17Idirectorio 15

FabricaObjetosTejidos 24Total 97

Tabla 8 Clases adicionales para los aspectos La tabla 8 muestra las clases necesarias para que la tejedora (en este caso Rapier-Loom.NET) pueda tejer aspectos y objetos; adicionalmente la clase FabricaObjetosTejidos agrupa la lógica de creación de objetos basándose en el patrón de diseño Abstract Factory [GOF]. Así que estas clases adicionales desaparecerán cuando el Framework de Microsoft .NET decida incorporar POA, por otro lado la clase de fabricación es considerada una buena practica en el desarrollo de software.

Aspecto Lineas de CódigoAspectoDirectorio 80

AspectoRelay 124Total 204

Tabla 9 Total líneas de código por aspecto

90

Mientras que la tabla 9 muestra en sí las líneas de código que emplearon los Aspectos. Pero lo más importante es entender como POA marca la diferencia frete a POO y en general a cualquier paradigma.

Clase Líneas de Código Aspectos Líneas de Código Sin Aspectos DirefenciaRelayLG 63 169 106

DirectorioLG 89 98 9Total 152 267 115

Tabla 10 Total líneas de código por clase a tejer Como se puede observar la diferencia total, es de 115 líneas; estas líneas en tan solo 2 clases se puede considerar significativo ya que por ejemplo la clase RelayLG es superada por más del doble por su versión sin aspectos. Para entrar más en detalle observemos en la clase DirectorioLG a una de las principales funciones del API, BuscarServicio, la cual intercepta a dos aspectos, el de auditoria y el de agilización de búsquedas. La versión basada en aspectos se ve así:

Gráfica 51 Código con aspectos, función búsqueda

91

El código fuente que se muestra en la gráfica 51 es considerado código totalmente funcional, según los requerimientos y el diseño planteado a lo largo de éste documento. Ahora miremos la versión sin aspectos:

Gráfica 52 Código sin aspectos, función búsqueda

En color rojo se resalta los bloques de código que se adicionan a la función de Búsqueda, código que antes hacía parte del Aspecto y que en el caso del segundo recuadro rojo pertenece al AspectoAuditoria, ese bloque de código se escribe una sola vez en el aspecto y se multiplica en tiempo de ejecución tanto en el directorio como en el Relay, ahorrándole al desarrollador 6 líneas de código.

92

Aunque POA toma fuerza a medida que el desarrollo es más grande y complejo, en el API se puede ver claramente las ventajas a nivel de diseño que este paradigma trae, un código más transparente, menos entremezclado y con la facilidad de extender incluso luego de la etapa de desarrollo de un proyecto de software sin la necesidad de impactar la lógica funcional.

93

11 CONCLUSIONES Analizar la viabilidad de implementar soluciones de software basadas en POA utilizando Microsoft Compact Framework.NET era uno de los objetivos de esta investigación. Se realizaron varias pruebas de los diferentes proyectos que ofrecen herramientas para la construcción de Aspectos y la implementación de tejedoras, estableciendo que aún no existe un framework de desarrollo de POA maduro; sin embargo, se escogió la herramienta con mayor soporte y nivel de complejidad relativamente bajo (Rapier-Loom.NET). Se demostró que actualmente Compact Framework no puede implementar aplicaciones basadas en POA por los limitantes tecnológicos que hasta ahora se poseen, se establecieron contactos mediante correo electrónico con los responsables de la mayoría de herramientas para POA, llegando a la conclusión que la librería System.Reflect.Emit, no es soportada por Compact Framework, siendo este el principal conjunto de clases para la implementación de POA en .NET y por ende en cada uno de las herramientas consultadas es utilizado como base. De esta manera ofrecer soluciones para Compact Framework basadas en POA se convierte en una cuestión de diseño, como bien se plasmó en esta investigación es necesario recurrir a arquitecturas, componentes y modelos que permitan aprovechar los beneficios de POA; más aún cuándo Compact Framework es una herramienta para construir aplicaciones tipo cliente. POA, es un nuevo paradigma de implementación de software, concebido para mejorar algunas falencias de POO como el encapsulamiento, reutilización y abstracción, se convierte en una alternativa incluso necesaria; pero, como se encontró durante las pruebas realizadas, los tiempos de compilación y de ejecución de un programa desarrollado con POA contra un programa desarrollado con POO son mayores; este hecho es comprensible, puesto que la máquina virtual debe hacer un esfuerzo extra en la etapa de tejido de los aspectos. Esta investigación experimentó algunos de los beneficios de POA, se demostró lo sencillo que resulta abstraer, encapsular y factorizar el código considerado no funcional y dependiente de la tecnología, como lo es la escritura en archivos, haciendo que el API de comunicaciones cuente con un código sencillo de interpretar y fácil de extender. La extensibilidad se logra a través de la tejedora, ya que esta permite cortar el código, mediante la incorporación de los aspectos en cualquier

94

lugar en que se necesite sin necesidad de modificarlo, haciendo que el desarrollo de la lógica no funcional se pueda hacer incluso después de tener implementada la lógica funcional. Adicionalmente no importa en que lenguaje o que tejedora se utilice, ya que la lógica de construcción de aspectos corre por parte del lenguaje de aspectos, es decir que la lógica funcional no se entera de la existencia de los aspectos. Sin embargo, aún faltan mejores mecanismos de implementación de puntos de cortes, así como es necesaria la posibilidad de hacer depuración sobre los aspectos, ya que el uso de reflexión no permite mantener una referencia a la herramienta de desarrollo. Se espera que tanto java como .NET incluyan en su roadmap a POA, adicionándole nuevas herramientas a sus ambientes de desarrollo, así como ya lo hizo JBOSS en su versión JBOSS-AOP. Durante el desarrollo del API se observó la importancia vital que jugaron los Patrones de software para el diseño y posterior construcción. Los patrones encierran soluciones a problemas recurrentes, y plantean la mejor opción, se consideran buenas prácticas de programación, garantizando un diseño flexible, reutilizable y extensible. Al programar sobre los dispositivos móviles, el Compact Framework brindó una abstracción aceptable, la forma de la implementación en este ambiente es muy similar al ambiente de escritorio. El gran inconveniente encontrado sobre la implementación en las Pocket PC fue la ausencia en algunos paquetes vitales para esta investigación, debido al consumo de máquina que requieren en si mismos. Es deseable que para futuros lanzamientos sobre el Compact Framework se adicionen las funcionalidades que se encuentran fuera de éste, como es el caso del soporte de la librerías: Reflection.Emit, Remoting, Security.Cryptography, BinaryFormatter, SoapFormatter y de manejos de hilos. Al inicio de ésta investigación se creyó importante realizar una comparación frente a JXTA, ya que este API es un proyecto conocido en el desarrollo de aplicaciones P2P. Sin embargo, como se mostró en las pruebas realizadas, J2ME no es transparente como máquina virtual para Pockets PC, se utilizaron muchas de las diferentes implementaciones de J2ME que existen en el mercado. Se justificó que es más diciente comparar los paradigmas de POA y POO a través del API; es así como se realizaron un total de 20 pruebas bajo el contexto específico del API, encontrando que la diferencia entre POA y POO a nivel de rendimiento,

95

ejecución y tiempos de respuesta no es muy significativa, mientras que si lo son las ventajas en diseño e implementación que trae POA. Logrando la finalidad de esta investigación, mostrar el valor agregado de POA bajo un contexto específico. Los Servicios Web son parte fundamental de la arquitectura propuesta por Microsoft para el desarrollo de soluciones tecnológicas. La utilización de estos en el desarrollo de esta investigación fue muy benéfica, puesto que se pudo suplir las necesidades de comunicación remota entre los servidores y los clientes, proveyendo un canal seguro, estable y confiable de muy fácil implementación. Para futuros desarrollos se proponen varias posibles mejoras al API, entre las cuales se encuentran la integración de los aspectos en los dispositivos móviles, la inclusión de un proceso de encripción de los datos al ser transferidos y la adaptación de la arquitectura de envió de paquetes tipo Torrent, es decir, que cada uno de los nodos pueda ir consumiendo un mismo servicio de varios nodos, mediante la fragmentación/consolidación de los datos enviados.

96

12 GLOSARIO API Interfaz de programación de aplicaciones Una API (del ingles Application Programming Interface - Interface de Programación de Aplicaciones, interfaz de programación de la aplicación) es un conjunto de especificaciones de comunicación entre componentes software. Representa un método para conseguir abstracción en la programación, generalmente (aunque no necesariamente) entre los niveles o capas inferiores y los superiores del software. Uno de los principales propósitos de una API consiste en proporcionar un conjunto de funciones de uso general, por ejemplo, para dibujar ventanas o iconos en la pantalla. De esta forma, los programadores se benefician de las ventajas de la API haciendo uso de su funcionalidad, evitándose el trabajo de programar todo desde el principio. Las APIs asimismo son abstractas: el software que proporciona una cierta API generalmente es llamado la implementación de esa API. Las APIs de alto nivel generalmente pierden flexibilidad; por ejemplo, resulta mucho más difícil en un navegador web hacer girar texto alrededor de un punto con un contorno parpadeante que programarlo a bajo nivel. Al elegir usar una API se debe llegar a un cierto equilibrio entre su potencia y simplicidad y su pérdida de flexibilidad. Ejemplos de APIs: Microsoft Win32 API SUN J2EE APIs API for SCSI device interfacing The Carbon APIs for the Macintosh OS Common Object Request Broker Architecture (CORBA) AspectJ AspectJ es un lenguaje de programación orientado por aspectos construido como una extensión del lenguaje Java creado en Xerox PARC. Un compilador de AspectJ hace llegar la noción de aspecto hacia el código de máquina virtual implementando así una noción de relación. Los aspectos en si se escriben en Java extendido generándose un archivo java o compilado con código de máquina compatible con el generado por los compiladores de Java. Aspecto En la informática, un aspecto es una parte de un sistema que entrecruza la lógica funcional. Aislar los aspectos, tales como la autenticación y la

97

persistencia, de la lógica del negocio es el ideal del paradigma de programación orientado a aspectos. Benchmark Anglicismo traducible al castellano como cota o valor de referencia y utilizado en computación. Es el resultado de la ejecución de un programa informático o un conjunto de programas en una máquina, con el objetivo de estimar el rendimiento de un elemento concreto o la totalidad de la misma, y poder comparar los resultados con máquinas similares. Broadcast Mandar el mismo mensaje simultáneamente a múltiples receptores dentro de la misma red. Esta técnica es muy usada en los sistemas de e-mail, aunque también se usa con los fax. Bug Un error de software o computer bug, que significa bicho de computadora, es el resultado de una falla de programación introducida en el proceso de creación de programas de computadora. El término bug fue acreditado erróneamente a Grace Murray Hopper, una pionera en la historia de la computación, pero Thomas Edison ya lo empleaba en sus trabajos para describir defectos en sistemas mecánicos por el año 1870. Caché En informática, un caché es un conjunto de datos duplicados de otros originales, con la propiedad de que los datos originales son costosos de acceder, normalmente en tiempo, respecto a la copia en el caché. Cuando se accede por primera vez a un dato, se hace una copia en el caché; los accesos siguientes se realizan a dicha copia, haciendo que el tiempo de acceso aparente al dato sea menor. CLR El CLR (Common Language Runtime) es el motor en tiempo de ejecución del .NET Framework, es decir la parte del "entorno" que se encarga de ejecutar el código de los lenguajes del .NET Framework. COOL Lenguaje creado por Xerox, cuya finalidad es la sincronización de hilos concurrentes.

98

CORBA En computación, Common Object Request Broker Architecture (CORBA) es un estándar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos. Encripción Se refiere a aquellos programas informáticos de conversión de datos, que codifican y descodifican mensajes en la Red. Se necesita una clave o un conocimiento especial para interpretarlo de manera correcta. Es una traducción poco aceptada del término inglés -encryption-, que tiene otros sinónimos en español como codificar o cifrar Framework Un framework es una estructura extensible para describir un conjunto de conceptos, métodos y tecnologías para el diseño de un producto completo. Hilos concurrentes Muchos lenguajes de programación (como Java y C#), y otros entornos de desarrollo soportan los llamados hilos o hebras (en inglés, threads). Los hilos son similares a los procesos en que ambos representan una secuencia simple de instrucciones ejecutada en paralelo con otras secuencias. Los hilos son una forma de dividir un programa en dos o más tareas que corren simultáneamente. HTTP Protocolo de la Web (WWW), usado en cada transacción. Las letras significan Hyper Text Transfer Protocol, es decir, protocolo de transferencia de hipertexto. El hipertexto es el contenido de las páginas web, y el protocolo de transferencia es el sistema mediante el cual se envían las peticiones de acceder a una página web, y la respuesta de esa web, remitiendo la información que se verá en pantalla. También sirve el protocolo para enviar información adicional en ambos sentidos. IDE Entorno de Desarrollo Interactivo, Interactive Development Environment (IDE) por sus siglas en inglés. Inalámbrica Es un sistema de comunicación que utiliza ondas de radiofrecuencia, ultrasonido o rayos infrarrojos (IR) para intercambiar datos entre

99

dispositivos. Cada vez se está popularizando más el uso de este sistema para transferencia de datos entre cámaras digitales, PDAs, calculadoras, etc. con la computadora. En Internet, este término es utilizado para indicar que la transmisión de información se efectúa prescindiendo de cables. Es el caso de los celulares con sistema WAP, o las conexiones a Internet. En RedLibre y otras comunidades inalámbricas se emplea para designar las conexiones de red inalámbricas reguladas por la norma IEEE 802.11. J2ME Java 2 Platform Micro Edition. Es la respuesta de Sun Microsystems para una plataforma de dispositivos inalámbricos. El J2ME permite que los desarrolladores usen Java y las herramientas inalámbricas J2ME para crear aplicaciones y programas para dispositivos móviles inalámbricos. Consiste de dos elementos: configuraciones y perfiles. Las configuraciones proveen las librerías y una máquina virtual para una categoría de dispositivos inalámbricos. Hay dos configuraciones para J2ME, una para dispositivos inalámbricos fijos y otra para los móviles. Los perfiles son APIs integradas por encima de las configuraciones para proveer un ambiente de funcionamiento para dispositivos específicos, como PDAs, telefonía celular, o set-top boxes. El perfil administra la aplicación, la interfaz de usuario, las redes y la transmisión de datos. Para soportar aplicaciones Java, los fabricantes tienen que implementar un perfil para cada dispositivo específico. Java Package Carpeta creada para contener clases java, y así poder organizarlas. JBoss Servidor de aplicaciones de código abierto basado Java el cual se puede utilizar en cualquier sistema operativo que soporte a Java. JXTA Conjunto de protocolos para P2P basado en Java; también ha sido implementado para J2ME en la utilización de dispositivos móviles. Librería En computación, una biblioteca o librería es un conjunto de procedimientos y funciones (subprogramas) agrupadas en un archivo con el fin de ser aprovechadas por otros programas. Al proceso de hacer accesibles estos subprogramas al programa principal se le llama enlace (link).

100

Middleware Conjunto de servicios que permiten que la aplicaciones funciones en una red. Namespace The concept of a namespace has been around for quite a while in programming but has only become a requirement for Visual Basic programmers to know about since XML and .NET became critical technologies. The traditional definition of a namespace is a name that uniquely identifies a set of objects so there is no ambiguity when objects from different sources are used together. Nodo In a discussion of networks, a “node” refers to a processing location. A node can be a computer or some other device, such as a printer. Every node has a unique network address. A device attached to a network. A node uses the network as a means of communication and has an address on the network. P2P Punto a punto En general, una red informática entre iguales (en inglés peer-to-peer y más conocida como P2P) se refiere a una red que no tiene clientes y servidores fijos, sino una serie de nodos que se comportan a la vez como clientes y como servidores de los demás nodos de la red. Este modelo de red contrasta con el modelo cliente-servidor. Cualquier nodo puede iniciar o completar una transacción compatible. Los nodos pueden diferir en configuración local, velocidad de proceso, ancho de banda de su conexión a la red y capacidad de almacenamiento. Debido a que la mayoría de los ordenadores domésticos no tienen una IP fija, sino que le es asignada por el proveedor (ISP) en el momento de conectarse a Internet, no pueden conectarse entre sí porque no saben las direcciones que han de usar de antemano. La solución habitual es realizar una conexión a un servidor (o servidores) con dirección conocida (normalmente IP fija), que se encarga de mantener la relación de direcciones IP de los clientes de la red, de los demás servidores y habitualmente información adicional, como un índice de la información de que disponen los clientes. Tras esto, los clientes ya tienen información sobre el resto de la red, y pueden intercambiar información entre sí, ya sin intervención de los servidores.

101

Palm La palabra Palm puede referirse a: *PalmOne, Inc., fabricante de hardware para PDAs basadas en Palm OS*PalmSource, Inc., desarrollador de Palm OS *Palm OS, el sistema operativo para la Palm PDA*Palm Pilots, PDAs antiguas. Paradigma de Programación Representan un enfoque particular o filosofía para la construcción del software. No es mejor uno que otro sino que cada uno tiene ventajas y desventajas. También hay situaciones donde un paradigma resulta más apropiado que otro. Parser Programa de computador o un componente de un programa, que analiza la estructura gramatical de una entrada de datos, con respecto a una gramática formal dada. PDA PDA del inglés Personal Digital Assistant, (Ayudante personal digital) es un ordenador de mano originalmente diseñado como agenda electrónica. Hoy en día se puede usar como un ordenador doméstico (ver películas, crear documentos, navegar por Internet, etc.). POA Es un paradigma de programación, su idea principal es la de separar los aspectos de los componentes, estableciendo toda una metodología para abstraer aspectos en el diseño y desarrollo, con la intención de mejorar la reutilización y encapsulamiento del modulo objetivo y la invocación arbitraria de código. Pocket PC PocketPC es un ordenador de bolsillo, también llamado PDA (Personal Digital Assistant). Se trata de un pequeño ordenador, diseñado para ocupar el mínimo espacio y ser fácilmente transportable que ejecuta el sistema operativo Windows CE de Microsoft, el cual le proporciona capacidades similares a los PCs de escritorio. POO (POO u OOP según siglas en inglés) es una metodología de diseño de software y un paradigma de programación que define los programas en términos de "clases de objetos", objetos que son entidades que combinan estado (es decir, datos) y comportamiento (esto es,

102

procedimientos o métodos). La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que se comunican entre ellos para realizar tareas. Proxy En el contexto de las ciencias de la computación, el término proxy (en inglés «apoderado» o «delegado») hace referencia a un programa que realiza una acción en representación de otro. Punto Un punto o nodo se comportan a la vez como clientes y como servidores de los demás nodos de una red P2P. Cualquier nodo puede iniciar o completar una transacción compatible. Los nodos pueden diferir en configuración local, velocidad de proceso, ancho de banda de su conexión a la red y capacidad de almacenamiento. Reflection Es la habilidad de proveer información de los tipos en tiempo de ejecución de tal manera que el cliente puede descubrir miembros (métodos, campos, propiedades, eventos y tipos anidados) de un tipo. La Reflexión también permite que dichos miembros sean referenciados en tiempo de ejecución, y permite que nuevos tipos sean definidos. Recientemente los tipos definidos pueden ser salvados en disco, como también permite que las instancias puedan ser alocadas en memoria. a la reflexión es común en máquinas virtuales de lenguajes de programación de alto nivel como smalltalk. Relay Termino de la OSI para el dispositivo que se encarga de conectar dos más redes o sistemas para redes. Separación de conceptos La separación de conceptos es el proceso de descomponer un programa en diferentes características que se intercepten en funcionalidad lo menor posible. Smartphone Un smartphose es considerado cualquier dispositivo portable que integre la administración de información personal con las capacidades de un teléfono móvil en el mismo dispositivo.

103

Supernodo Los Supernodos son una parte esencial de la red de Kazaa. Al ser un Supernodo, otros usuarios en su proximidad pueden descargan automáticamente una lista pequeña de archivos que están compartiendo, siempre que sea con el mismo Proveedor de Internet o localizado en la misma región que usted. Cualquier computadora que usa Kazaa puede convertirse en un Supernodo si tienen una computadora moderna y están teniendo acceso al Internet con una conexión de banda ancha. El ser un Supernodo no afecta su funcionamiento perceptiblemente. UML Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modelling Language) es el lenguaje de modelado de sistemas de software más conocido en la actualidad; aún cuando todavía no es un estándar oficial, está apoyado en gran manera por la Object Management Group (OMG), consorcio creado en 1989 responsable de la creación, desarrollo y revisión de la arquitectura CORBA. No produce software, únicamente especificaciones. UXF UXF es el acrónimo de UML eXchange Format, especificación que permite definir nuevos componentes en UML. XML XML es el acrónimo del inglés eXtensible Markup Language (lenguaje de marcado ampliable o extensible) desarrollado por el World Wide Web Consortium (W3C).

104

13 REFERENCIAS [ADDM] MESALEM. An add-in for Aspect Oriented Programming in Visual Studio.NET.

http://www.codeproject.com/macro/AspectOrientedVSNet.asp [AERS] AERSCHOT. Dynamic Aspect Oriented Programming In .NET.

Universiteit Antwerpen http:// www.lore.ua.ac.be/Publications/pdf/VanAerschot2004.pdf

[AKS2] AKSIT. Examples of Reusing Synchronization Code in Aspect-Oriented Programming using Composition-Filters. University of Twente. http://trese.cs.utwente.nl/oldhtml/ publications/papers/mcseai98.pdf

[AKS3] AKSIT. Solving the modeling problems of object-oriented languages composing multiple aspects using composition filters. University of Twente. http://trese.cs.utwente.nl/aop-ecoop98/papers/Aksit.pdf

[AKSI] AKSIT. Aspect-oriented Programming Using Composition-Filters. University of Twente. http://trese.cs.utwente.nl/oldhtml/publications/paperinfo/mcseai98.pi.ref.htm

[AROR] ARORA, Akhil; HAYWOOD, Carl y PABLA, Kuldip. JXTA for J2ME™– Extending the Reach of Wireless With JXTA Technology. Sun Microsystems, Inc. Marzo 2002

[ASP#] ASPECT#.Framework para AOP en .Net. http://aspectsharp.sourceforge.net/

[ASPB] Aspect Builder. Aspect-Oriented Programming Enables Better Code Encapsulation and Reuse. http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx

[ASPJ] ASPECTJ. AspectJ Related Notes. http://eclipse.org/aspectj/

[ASTE] ASTEASUAIN. Programación Orientada A Aspectos Análisis del paradigma.UNIVERSIDAD NACIONAL DEL SUR. 2002 http://www.angelfire.com/ri2/aspectos/Tesis/tesis.pdf

[BLAC] BLACKSTOCK. Aspect Weaving with C# and .NET. University of British Columbia. 2003 http://www.cs.ubc.ca/~michael/publications/AOPNET5.pdf

[BOOC] G. BOOCH, J. RUMBAUGH, I JACOBSON. The Unified Modelling Language User Guide.Addison- Wesley.1998 http://coventry.bcs.org/resources/uml.htm

[CLAR] CLARKE. Separating Concerns throughout the Development Lifecycle.IBM. http://trese.cs.utwente.nl/aop-ecoop99/papers/clarke.pdf

[CLEM] CLEMENTE.Interconexión de Componentes CCM Mediante Programación Orientada a Aspectos http://tdg.lsi.us.es/~sit02/res/papers/clemente.pdf

[CPHC] COUNCIL OF PROFESSORS AND HEADS OF COMPUTING (CPHC) with the support of the uk Quality Assurance Agency (QAA). Towards Benchmarking standards for taught masters degrees in computing. http://www.comp.leeds.ac.uk/roger/cphc/Masters/BM.pdf

[DALA] DALAGER.Aspect Oriented Programming in JBoss 4.0. http://www.jboss.org

[ENT1] REVISTA ENTER. No solo de PC vive el hombre Pag 56-61..edición 15 (2001) [ENT2] REVISTA ENTER. ¿Palm o Pocket? Pag 42-45 .Edición 32 (2002) [FLEU] FLEURY.Jboss Blue “Why I Love EJBs”.

http://www.jboss.org [GAMM] GAMMA, ERICH. Design patterns: elements of reusable object - oriented software;

foreword by Grady Booch. Reading, Massachusetts: Addison-Wesley, 1995.

105

[GARS] GARSON, EDWARD.Aspect-Oriented Programming in C#/.NET http://consulting.dthomas.co.uk

[GHEZ] GHEZZI. Coding Diferent Design Paradigms for Distributed Applications with Aspect-Oriented Programming.Politecnico di Milano. http:// homes.dico.unimi.it/~monga/lib/wsdaal99.pdf

[JBAO] JBoss AOP. http://www.jboss.org/developers/projects/jboss/aop

[JBOS] JBOSS.Jboss Road Map. http://www.jboss.org

[JXPR] The JXTA Project. http://www.jxta.org

[KAIK] KAI, KOEHNE .AW: Using Loom on Compact Framework. Rapier-Loom.Net Development & Support. 38253

[KIC] KICILLOF. Programación Orientada a Aspectos (AOP).Universida Buenos Aires. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art152.asp

[KIC2] KICZALES. Interview with Gregor Kiczales. The server side. 2003 http://www.theserverside.com/talks/videos/GregorKiczalesText/interview.tss

[KICZ] KICZALES. Aspect-Oriented Programming. 1997 http://www.cs.ubc.ca/~gregor/papers/kiczales-ECOOP1997-AOP.pdf

[KIM] KIM, HOWARD. AspectC#: An AOSD implementation for C#. http://www.dsg.cs.tcd.ie/index.php?category_id=171.2002

[KINN] KINNEAR. Investigación de Mercados. 5ta Edicion. Mcgraw-Hill. Colombia, 2000. [KIVI] KIVILUOMA. Paradigms for Concern Separation. 2004

http://www.cs.tut.fi/~kk/webstuff/ParadigmsKalvot.pdf [KNUD] KNUDSEN, Jonathan.Getting Started with JXTA for J2ME. Sun Microsystems, Inc.

2002. http://developers.sun.com/techtopics/mobility/midp/articles/jxme/ [LADD] LADDAD. I want my AOP

http://www.JavaWorld.com [LAFF] LAFFERTY. RE: Responder: RE: Using AspectC# on Pocket-Pc.AspectC#.2004,

Septiembre 27, 2004 [LIEB] LIEBERHERR. Aspect-Oriented Programming and its Northeastern History.

http://www.ccs.neu.edu/research/demeter/ talks/phd-visitation-02/visitation.ppt [LOPE] W. Hursch and C. Lopes. Separation of Concerns. Northeastern University,

Febrero1995. [MICP] MICROSOFT. Introduction to Development Tools for Windows Mobile based Pocket

PCs and Smarthphones. Microsoft Corporation. Marzo 2004. [MIHO] WAI-MING, ho; PENNANEAC’H, François; JEZÉQUÉL. Jean-Mark; PLOUZEAU,

Noël. Aspect-Oriented Design with UML. IRISA. [MS01] MICROSOFT.Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y

servicios. http://www.microsoft.com/spanish/msdn/arquitectura/das_doc/Chapter2_Components.doc

[OLSN] OLSON, LANCE. .NET P2P: Writing Peer-to-Peer Networked Apps with the Microsoft .NET Framework.Tomado de: http://msdn.microsoft.com/msdnmag/issues/01/02/netpeers/

[OSSH] OSSHER, Harold y TARR, Peri.Multi-Dimensional Separation of Concerns and The Hyperspace Approach.IBM.2000

[POLZ] POLZE.Configurable Services for mobile Users based on Aspect Descriptions. Microsoft Aspect.NET.

[REIN] ANTONIA Mª REINA QUINTERO.Visión General de la Programación Orientada a Aspectos.www.lsi.us.es/~informes/aopv3.pdf

106

[RLOM] OPERATING SYSTEMS AND MIDDLEWARE GROUP AT HPI.The LOOM .NET

Project. http://www.dcl.hpi.uni-potsdam.de/research/loom/

[RUPP] RUPP. JBoss 4 and AOP, what gives with it? The Inquirer .Net.2003. http://www.theinquirer.net/?article=9813

[SCHU] SCHULT.Aspect-Oriented Programming with C# and .NET. http://www.dcl.hpi.uni-potsdam.de/cms/papers/papers/isorc2002.pdf

[SLAU] SEAN LAU.Aspect Oriented Programming. 2003. Noviembre 17, 2003. [SLIW] CAROL SLIWA .Pros & Cons: .Net vs. J2EE.

http://www.computerworld.com/developmenttopics/development/story/0,10801,71210,00.html

[TITO] TITOS. Programación orientada a aspectos. Malaj http://www.geocities.com/olmotitos/POA-Malaj.ppt

[YASU] J. SUZUKI, Y. YAMAMOTO.Extending UML with Aspect: Aspect Support in the Design Phase. 3er Aspect-Oriented Programming (AOP) Workshop at ECOOP'99. 1999.

[ZASA] SEATO.Counting Lines of Code in C# By Seato. http://www.codeproject.com/useritems/DirectoryLineCounter.asp

[ZBOL] OLLAR, Tom.Simple Source Line Counter in C# for C#. http://www.codeproject.com/csharp/CSharpLineCounter.asp

[ZMIL] MILANES, José Manuel. Midiendo la Complejidad del Software. Grupo Seti. http://www.gruposeti.com/Recursos/PDFs/COMPLEJIDAD.pdf

[ZPOA] ASTEASUAIN, Fernando; CONTRERAS, Bernardo; ESTEVEZ, Elsa y FILLOTTRANI, Pablo. Programación Orientada a Aspectos: Metodología y Evaluación. Departamento de Ciencias e Ingeniería de la Computación Universidad Nacional del Sur. Bahía Blanca, Argentina.

[ZVED] DEVMETRICS. devMetrics Documentation. http://www.anticipatingminds.com/Content/Documentation/devMetrics/default.aspx

[ZWOO] CCMETRICS COMPLEXITY ANALYZER. J. Wood Software Services llc. http://www.serviceframework.com/jwss/utility,ccmetrics,utility.aspx

107

14 REFRENCIAS DE PAGINAS DE INTERNET IBM, JBoss eye new Java plan Martin LaMonica, CNET News.com publicado en ZDNet News: Septiembre 24, 2003 http://news.zdnet.com/2100-3513_22-5081831.html Aspect Oriented Programming in JBoss 4 Christian Dalager, Simon Jorsal y Eske Sort Thesis Weblog http://www.dalager.com/thesis/index.html Marzo 1 de 2004 Aspectj Project Eclipse Foundation http://eclipse.org/aspectj/ April 12 de 2005 AOP: Aspect-Oriented Programming Enables Better Code Encapsulation and Reuse Dharma Shukla, Simon Fell y Chris Sells publicado en MSDN Magazine: Marzo 2002 http://msdn.microsoft.com/msdnmag/issues/02/03/AOP/default.aspx Aspect Oriented Programming Raviraj publicado en C# Corner: Noviembre 20 de 2002 http://www.c-sharpcorner.com/Code/2002/Nov/aop.asp Aspect# The Aspect# Team http://aspectsharp.sourceforge.net/ Octubre 1 de 2004 AspectC# Andrew Jackson, Siobhán Clarke,Howard Kim AspectC#: Intro http://www.dsg.cs.tcd.ie/index.php?category_id=169 Marzo 31 de 2005

108

Aspect-Oriented Programming with C# and .NET Prof. Dr. Andreas Polze http://www.dcl.hpi.uni-potsdam.de/folien/Net-Days/AOP-with-NET_files/v3_document.htm Mayo 06 de 2005 Welcome to the LOOM .NET Project! Prof. Dr. Andreas Polze, Dipl. Phys. Michael Dirska, Dr. Martin v. Löwis, Dipl. Inf. Bernhard Rabe, Dipl. Inf. Andreas Rasche, Dipl. Inf. Wolfgang Schult, Dipl. Inf. Peter Tröger y Sabine Wagner http://www.dcl.hpi.uni-potsdam.de/research/loom/ Diciembre 6 de 2004 Open Source Aspect-Oriented Frameworks in C# http://csharp-source.net/open-source/aspect-oriented-frameworks An add-in for Aspect Oriented Programming in Visual Studio.NET Mesalem publicado en CodeProject: Diciembre 8 de 2003 http://www.codeproject.com/macro/AspectOrientedVSNet.asp? Weave.NET: Language-Independent Aspect-Oriented Programming Donal Lafferty y Vinny Cahill http://www.dsg.cs.tcd.ie/index.php?category_id=194 Diciembre 9 de 2002 Welcome to aosd.net Harold Ossher, Yvonne Coady, Mehmet Aksit, Brian Barry, Tzilla Elrad, Bob Filman, Gregor Kiczales, Karl Lieberherr Mira Mezini, Gail Murphy y Linda Northrop http://www.aosd.net/ SetPoint: an Aspect-Oriented Tool based on semantic pointcuts, developed using Microsoft's .NET framework http://dependex.dc.uba.ar/setpoint/ Improve modularity with aspect-oriented programming Nicholas Lesiecki publicado en IBM: Enero 1 de 2002 http://www-106.ibm.com/developerworks/java/library/j-aspectj/

109

I want my AOP! Ramnivas Laddad publicado en JavaWorld Enero 18 de 2002 http://www.javaworld.com/javaworld/jw-01-2002/jw-0118-aspect.html Workshop on Multi-Dimensional Separation of Concerns in Software Engineering (ICSE 2000) http://researchweb.watson.ibm.com/hyperspace/workshops/icse2000/papers-index.htm ThemeUML Siobhán Clarke y Robert J. Walker http://www.dsg.cs.tcd.ie/index.php?category_id=353 Diciembre 9 de 2002 Developing Connected .NET Pocket PC Applications Using Web Services Andreas Sjöström Publicado en MSDN:Agosto 2003 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/connecteddotnetppcapps.asp The International Software Benchmarking Standards Group (ISBSG) http://www.isbsg.org/ Enero 25 de 2005 United Kingdom Software Metrics Association http://www.uksma.co.uk/ Performance Comparison: .NET Remoting vs. ASP.NET Web Services Priya Dhawan publicado en MSDN: Septiembre 2002 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch14.asp OOP vs AOP Mariano Lorente http://www.programemos.com/Articulos/1077227754/OOPvsAOP/ Agosto 1 de 2004

110

Detecting IP Address of Pocket PC Pete Vickers http://www.dotnet247.com/247reference/msgs/58/290850.aspx Detecting network connection Ignacio Machin http://www.dotnet247.com/247reference/msgs/52/262844.aspx Choosing a Windows Embedded API: Win32 vs. the .NET Compact Framework Paul Yao, Windows Embedded MVP publicado por MSDN: Sep`tiembre 2002 http://msdn.microsoft.com/mobility/understanding/articles/default.aspx?pull=/library/en-us/dncenet/html/choose_api.asp Documenting your code with NDoc Peter Foot http://www.opennetcf.org/PermaLink.aspx?guid=05650440-2281-4f72-bdb2-fe6343284dca 2003 File transfer using network I/O - I Yashavant Kanetkar http://www.expresscomputeronline.com/20030303/techspace2.shtml Fundamentals of Microsoft .NET Compact Framework Development for the Microsoft .NET Framework Developer Denise Barnes publicado por MSDN: Diciembre de 200 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/net_vs_netcf.asp3 Programming Merge Replication with the Microsoft .NET Compact Framework Content Master Ltd publicado por MSDN: Abril 2003 http://msdn.microsoft.com/mobility/understanding/articles/default.aspx?pull=/library/en-us/dnnetcomp/html/netcfmergereplication.asp

111

Differences in Microsoft .NET Compact Framework Development between the Pocket PC and Windows CE .NET Jim Wilson publicado por MSDN: Marzo 2003 http://msdn.microsoft.com/mobility/understanding/articles/default.aspx?pull=/library/en-us/dnnetcomp/html/netcfPPCtoCE.asp Using the Emulator in Smart Device Projects Don Espen, Jose Baldner y Ximing Zhou publicado en MSDN: Febrero 2003 http://msdn.microsoft.com/mobility/understanding/articles/default.aspx?pull=/library/en-us/dv_vstechart/html/grfUsingEmulatorInSmartDeviceProjects.asp Windows Mobile for Developers http://www.microsoft.com/windowsmobile/developers/default.mspx OpenNETCF.org: The Premier .NET Compact Framework Shared Source Site http://opennetcf.org/CategoryView.aspx?category=Home Microsoft .NET Compact Framework Multi-threading Tips Content Master Ltd publicado por MSDN: Abril de 2003 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/netcfmultithreadedapp.asp .NET P2P: Writing Peer-to-Peer Networked Apps with the Microsoft .NET Framework Lance Olson publicado en MSDN Magazine: Febrero 2001 http://msdn.microsoft.com/msdnmag/issues/01/02/netpeers/ P2P And C# Shripad Kulkarni http://www.csharphelp.com/archives/archive261.html Generic P2P Architecture, Tutorial and Example Daniel Stephen Rule publicado por CodeProject: Mayo de 2005 http://www.codeproject.com/vbscript/Generic_P2P_Architecture.asp

112

J2ME Downloads http://java.sun.com/j2me/download.html IBM Workplace Client Technology, Micro Edition https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?source=wctme57&S_PKG=dl&S_TACT=104AHW42 Java Support on Pocket PC http://www.comp.lancs.ac.uk/computing/users/fittond/ppcjava.html Ewe VM http://www.ewesoft.com SuperWaba VM http://www.superwaba.com.br IBM WebSphere Studio http://www.ibm.com/websphere Sun PersonalJava http://java.sun.com/products/personaljava/index.html JXTA Project http://www.jxta.org ASP.NET Web Services or .NET Remoting: How to Choose Priya Dhawan y Tim Ewald publicado por MSDN: Septiembre 2002 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch16.asp Use Threading with Asynchronous Web Services in .NET Compact Framework to Improve User Experience Christian Forsberg publicado por MSDN: Febrero 2004 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/use_thread_async_web_services.asp File Merger and Splitter in C# Say Gin Teh publicado por C#: Octubre 4 de 2001 http://www.c-sharpcorner.com/1/FileMergerAndSplitter.asp

113

15 ANEXOS Anexo 1. Comunicación con el soporte de la herramienta Rapier-

Loom.Net De Koehne Kai <[email protected]> Añadir remitente

Sent Jueves, Septiembre 23, 2004 5:10 am

Para [email protected]

CC Schult Wolfgang <[email protected]>

Asunto AW: Using Loom on Compact Framework

Hello, I must unfortunately say that Rapier-Loom.Net will not work with Microsoft .NET CF. This is because it relies heavily on classes in the System.Reflection.Emit namespace, which seem not to be available with the Compact Framework. Kai Koehne Rapier-Loom.Net Development & Support -----Ursprüngliche Nachricht----- Von: [email protected] [mailto:[email protected]] Gesendet: Mittwoch, 22. September 2004 23:04 An: [email protected] Betreff: Using Loom on Compact Framework Wichtigkeit: Hoch Hello, I'm an university student, and I was testing the axample application with Loom on Microsoft Compact Framework 2003 using Visual Studio, but it never works, so I want to know if I can use Loom and aspects oriented programming in general with Pocket Pc. Your answer is very important for a researh that I am making. Thank You, Paulo Andrés Burgos Heredia Pontificia Universidad Javeriana - Bogotá, Colombia

114

Anexo 2. Comunicación con el Soporte de la herramienta AspectC#

De Donal Lafferty <[email protected]> Añadir remitente

Sent Viernes, Septiembre 24, 2004 9:19 am

Para [email protected]

Asunto RE: Using AspectC# on Pocket-Pc

Archivos adjuntos OOPSLA2003_FP.pdf 934K AspectC# hasn't been actively developed on. If you need to do weaving, I've a library that works for XML-based crosscuttnig specifications based on the AspectJ language. I'm writing up my thesis on the tool at the moment, so why don?t you start by looking at the following OOPSLA 2003 paper, and decide if the weaver's of interest. DL > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > Sent: 23 September 2004 16:26 > To: [email protected] > Subject: Using AspectC# on Pocket-Pc > > > Hello, > > I'm an university student, and I was testing an axample application > with AspectC# on Microsoft Compact Framework 2003 using > Visual Studio, > but > it never works, so I want to know if I can use AspectC# and aspects > oriented programming in general with Pocket Pc. Your answer is very > important for a researh that I am making. > > Thank You, > > Paulo Andrés Burgos Heredia > Pontificia Universidad Javeriana - Bogotá, Colombia >

115

Anexo 3. Comunicación con Mesalem, creador de un Add-in para Visual Studio para el tejido de aspectos

De Mesalem <[email protected]> Añadir remitente

Sent Domingo, Septiembre 26, 2004 6:54 am

Para paburgos <[email protected]>

Asunto [CodeProject] Re: Using the Add-in on Pocket-Pc

*** DO NOT REPLY TO THIS MESSAGE *** This message has been sent from an unattended email box. The actual reply address can be found below. An answer has been posted to your message on the page 'An add-in for Aspect Oriented Programming in Visual Studio.NET': URL : http://www.codeproject.com/macro/AspectOrientedVSNet.asp?msg=933425#xx933425xx From: Mesalem ([email protected]) I made a simple .net cf application and used the addin in it and it worked I wasn't able to reproduce your problem, if you can send me your code i'll try to fix it --------------------------------------------------------------- This message was created by The Code Project http://www.codeproject.com

116

Anexo 4. Migración del add-in de aop en .net con el Ejemplo Observer Pattern

Esta implementación se probó con una aplicación que aplicaba el patrón observer [GOF] mediante aspectos en los observadores, y generaba código en tiempo de compilación, antes de ser ejecutado. Objetos de la Solución: Archivos Xml con la descripción del Aspecto aspectDescriptor.xml <?xml version="1.0" encoding="utf-8"?> <aspects> <aspect name="SubjectObserverAspect" code="SubjectObserverAspect.vb" weave="true"> <advices> <advice type="after"> <method name="initObservers" /> <pointcut> <execution> <method name="SubjectForm_Load" class="SubjectForm" access="*" return="*"/> </execution> </pointcut> </advice> <advice type="after"> <method name="afterEvent" /> <pointcut> <execution> <method name="Button1_Click" class="SubjectForm" access="*" return="*" /> </execution> </pointcut> </advice> </advices> <introductions> <member name="Observers" introduceto="SubjectForm" /> <interface name="Subject" introduceto="SubjectForm" /> <interface name="Observer" introduceto="Observer*" /> </introductions> </aspect> </aspects> Archivos con la descripción del Aspecto (Tejedor) SubjectObserverAspect.vb Public Class SubjectObserverAspect_vb Inherits AspectLib.Aspect #Region "Subject Functionality" Public Observers As New ArrayList Public Sub AddObserver(ByVal ob As Observer) Observers.Add(ob) End Sub

117

Public Sub UpdateObservers(ByVal subj As SubjectForm) Dim ob As Observer For Each ob In Observers ob.UpdateObserver(subj.BackColor) Next End Sub Public Sub initObservers(ByVal f As SubjectForm) f.AddObserver(f.o1) End Sub #End Region #Region "Observer Functionality" Public Sub UpdateObserver(ByVal obs As Form, ByVal note As Object) Dim c As Color = CType(note, Color) obs.BackColor = c End Sub #End Region End Class Public Interface Subject Sub UpdateObservers() Sub AddObserver(ByVal ob As Observer) End Interface Public Interface Observer Sub UpdateObserver(ByVal note As Object) End Interface Objetos del ejemplo SubjectForm.vb Public Class SubjectForm Inherits System.Windows.Forms.Form Friend WithEvents ComboBox1 As System.Windows.Forms.ComboBox Friend WithEvents Button1 As System.Windows.Forms.Button Friend WithEvents MainMenu1 As System.Windows.Forms.MainMenu + Windows Form Designer generated code Public o1 As New ObserverForm1 Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim curColor As String = ComboBox1.SelectedItem Select Case curColor Case "Red" Me.BackColor = Color.Red Case "Green" Me.BackColor = Color.Green Case "Blue" Me.BackColor = Color.Blue End Select End Sub End Class ObserverForm1.vb Public Class ObserverForm1 Inherits System.Windows.Forms.Form

118

+ Windows Form Designer generated code End Class

Librerías usadas Librería de Aspectos AspectLib.dll Librería de Microsoft Mscorlib.dll

119

Anexo 5. Investigation sobre Desarrollo de .net Compact Framework Aspect Sharp (aspectsharp.sourceforge.net)

El paquete de Aspect Sharp contiene un ejemplo en el cual se graban mensajes digitados por pantalla a un archivo de texto en la carpeta donde se depura el programa. El paquete de software de aspect sharp permite manejar una serie de clases ya implementadas las cuales sirven de base para trabajar con la programación orientada a aspectos. Entre los principales servicios se encuentra un proxy dinámico sobre el cual se define la forma de llamado de una clase que implementa una interfaz. La estructura básica sobre la cual se construyen los aspectos, esta dado por el siguiente árbol de especificación (en formato XML –E: Elemento A: Atributo-)

Ejemplo de envió de mensaje

120

El paquete de Aspect Sharp contiene un ejemplo en el cual se graban mensajes digitados por pantalla a un archivo de texto en la carpeta donde se depura el programa. Programa principal El código fuente que ejecuta el programa de ejemplo es el siguiente, en la sección señalada se hace uso de la creación de un proxy para enviar el mensaje: namespace AspectSharp.Sample { using System; using AspectSharp.Framework; using AspectSharp.Sample.Model; class AspectSharpSample { [STAThread] static void Main(string[] args) { Console.WriteLine("Type 'exit' to exit."); while(true) { Console.Write("Enter a message: "); string userInput = Console.ReadLine(); if (userInput == "exit") { return; } //Creating the proxy IMessage message = AspectSharpEngine.Wrap( new MessageImpl() ) as IMessage; message.Message = userInput; //Casting to the persistence service IMessagePersistence persistence = (IMessagePersistence)message; persistence.Save(); } } } }

Es importante señalar que en el ejemplo que trae el programa no usa otra implementación sobre las librerías de aspectos.

121

Anexo 6. Ejemplo desarrollado en Rapier Loom.Net Definición del Aspecto (muestra un cuadro de dialogo) Consiste en una aplicación bancaria que cada vez que se hace un retiro lanza un mensaje con el texto “Aspecto!”. using System; using System.Windows.Forms; using Loom; namespace BancariaAspectos.Aspectos { public class AspectoSeguridad: Loom.Aspect { [Loom.ConnectionPoint.Include("Retirar")] [Loom.Call(Invoke.Before)] public void Trace(object []args) { try { MessageBox.Show("Aspecto :D!! "); } catch(Exception e) { MessageBox.Show(""+e.InnerException); } } } }

Parte de la lógica donde se lanza el aspecto definido anteriormente using System.Windows.Forms; using BancariaAspectos.Datos; using BancariaAspectos.Aspectos; namespace BancariaAspectos.Logica { public class Logica:Datos.Datos { public bool RetirarPlatica(double numSaldo, int numCuenta, double numSaldoActual) { AspectoSeguridad aspecto = new AspectoSeguridad(); ITransaccion tran =(ITransaccion)Loom.Weaver.CreateInstance( typeof(Datos.Datos), null, aspecto); try { tran.Retirar(numSaldo, numCuenta, numSaldoActual); } catch(Exception e) { MessageBox.Show(e.InnerException +""); return false; } return true; } } }

Interfaz con la que se va a relacionar el aspecto using System; namespace BancariaAspectos.Datos { public interface ITransaccion {

122

bool Retirar(double saldoNuevo, int numCuenta, double numSaldo); bool Consignar(double saldoNuevo, int numCuenta, double numSaldo); } }

Implementación de la interfaz using System; using System.Data.SqlClient; using Microsoft.ApplicationBlocks.Data; namespace BancariaAspectos.Datos { public class Datos: ITransaccion { private string perfil = "User ID=sa;Initial Catalog=Bancaria;Data Source=127.0.0.1"; public bool Retirar(double saldoNuevo, int numCuenta, double numSaldo) { if(numSaldo < saldoNuevo) { return false; } numSaldo = numSaldo - saldoNuevo; using(SqlConnection objConn = new SqlConnection(perfil)) { SqlHelper.ExecuteNonQuery(objConn, "bcnSaldo_U", numCuenta, numSaldo); } return true; } public bool Consignar(double saldoNuevo, int numCuenta, double numSaldo) { numSaldo = numSaldo + saldoNuevo; using(SqlConnection objConn = new SqlConnection(perfil)) { SqlHelper.ExecuteNonQuery(objConn, "bcnSaldo_U", numCuenta, numSaldo); } return true; } public double ObtenerSaldo(int numCuenta) { Object obj = new Object(); using(SqlConnection objConn = new SqlConnection(perfil)) { obj = SqlHelper.ExecuteScalar(objConn, "bcnSaldo_S", numCuenta); } return Convert.ToDouble(obj); } public int ObtenerCuenta(int numCedula) { using(SqlConnection objConn = new SqlConnection(perfil)) { Object obj = SqlHelper.ExecuteScalar(objConn, "bcnCuenta_S", numCedula); if(obj == null) return -1; return (int)(obj); } } } }

123

An

exo 7

. D

iag

ram

as

de S

ecu

en

cia

7.1

C

aso

de U

so:

Ate

nd

er

Solici

tud

IDire

ctor

ioD

irect

orio

Rel

ayR

elay

SVIR

elay

Rel

ayLG

Pock

et P

CSe

rvid

orSo

licitu

des

Dire

ctor

ioD

irect

orio

SVSe

rvid

or S

olic

tude

sM

anej

ador

Solic

itude

s

Petic

ionN

Petic

ion

Solic

itude

sPe

ticio

nEm

isor

Tran

sfer

enci

asas

pRel

ayAs

pect

oRel

ayAu

dito

riaAs

pect

oAud

itoria

aspD

irect

orio

Aspe

ctoD

irect

orio

Petic

ionS

ervi

cio

Petic

ion

9: 'A

tend

erSo

licitu

d(ob

ject

[],s

tring

):voi

d'

6: 'T

empo

rizar

Clie

nte(

obje

ct []

):voi

d'

2.1:

<co

nstru

ctor

>(in

t,int

,stri

ng,s

tring

)

2: <

<Rec

orrid

o>>

2.1.

1: 'P

rest

arSe

rvic

io(T

ipos

.Pet

icio

n):v

oid'

11: <

<elim

inar

>>

10: A

tend

erSo

licitu

d(in

t,int

,stri

ng,s

tring

):voi

d

8.1:

<>

1.1.

1.1:

Obt

ener

Solic

iude

s(in

t):Pe

ticio

n[]

4: A

tend

erSo

licitu

d(in

t,int

,stri

ng,s

tring

):voi

d

3: E

nvia

rDat

os(S

ocke

t,byt

e [],

INot

ifica

dor):

void

1: O

bten

erSo

liciu

des(

int):

Tipo

s.Pe

ticio

n[]

8: A

tend

erSo

licitu

d(in

t,int

,stri

ng,s

tring

):voi

d

1.1.

1: O

bten

erSo

liciu

des(

int):

Petic

ion[

]

7: A

tend

erSo

licitu

d(in

t,int

,stri

ng,s

tring

):voi

d

5: <

<int

erce

pci

>>

1.1:

Obt

ener

Solic

iude

s(in

t):Ti

pos.

Petic

ion[

]

10.1

: Ate

nder

Solic

itud(

int,i

nt,s

tring

,stri

ng):v

oid

1.1.

1.1.

1: O

bten

erSo

liciu

des(

int):

Petic

ion[

]

124

7.2

C

aso

de U

so:

Bú

squ

ed

a S

erv

icio

s

Pock

etPC

Clie

nteL

GR

elay

Rel

aySV

Dire

ctor

ioD

irect

orio

SVD

irect

orio

L

ico

Dire

ctor

ioLG

Punt

osN

odo

Res

ulta

doR

esul

tado

Busq

ueda

aspD

irect

orio

Aspe

ctoD

irect

orio

aspR

elay

Aspe

ctoR

elay

IRel

ayR

elay

LGID

irect

orio

Dire

ctor

ioAu

dito

riaAs

pect

oAud

itoria

Clie

nte

Fina

l

1: B

usqu

eda(

strin

g):T

ipos

.Res

ulta

doBu

sque

da[]

4: B

usqu

eda(

strin

g):R

esul

tado

Busq

ueda

[]

3.1:

Bus

qued

a(st

ring)

:Tip

os.R

esul

tado

Busq

ueda

[]

2.1.

1: 'T

empo

rizar

Clie

nte(

obje

ct []

):voi

d'

3.1.

1.1.

1: 'I

nter

cept

arBu

sque

da(o

bjec

t [],s

tring

):voi

d'

3.1.

1.2.

1: B

usqu

eda(

strin

g):R

esul

tado

Busq

ueda

[]

3.1.

1.2:

'Int

erce

ptar

Busq

ueda

Para

Agiliz

ar(o

bjec

t []):

Res

ulta

doB

usqu

e...

3.1.

1.1:

'Int

erce

ptar

Busq

ueda

(obj

ect [

]):vo

id'

5.1:

<co

nstru

ctor

>(in

t,stri

ng,lo

ng)

6: 'A

ctua

lizar

Busq

ueda

s(ob

ject

[]):v

oid'

5: E

staS

ervi

cio(

strin

g):A

rrayL

ist

3.1.

1: <

<int

erce

pci

>>

3: B

usqu

eda(

strin

g):T

ipos

.Res

ulta

doBu

sque

da[]

2.1:

<>

7:2: B

usqu

eda(

strin

g):T

ipos

.Res

ulta

doBu

sque

da[]

En c

aso

que

la li

sta

de re

sulta

dos

este

vac

ia,

real

iza

lab俍

qued

a

125

7.3

C

aso

de U

so:

Con

ect

ar

aspR

elay

Aspe

ctoR

elay

Punt

oN

odo

Rel

ayR

elay

SV

Pock

etPC

Clie

nteL

G

IRel

ayR

elay

LGD

irect

orio

Dire

ctor

ioSV

aspD

irect

orio

Aspe

ctoD

irect

orio

Audi

toria

Aspe

ctoA

udito

riaID

irect

orio

Dire

ctor

ioD

irect

orio

L

ico

Dire

ctor

ioLG

Serv

idor

Serv

idor

Solic

itude

s

Clie

nte

Fina

l

2: A

greg

arC

lient

e():v

oid

1: <

cons

truct

or>(

INot

ifica

dor,s

tring

)

8.1:

Lan

zarS

ervi

dor()

:voi

d

7.1:

<co

nstru

ctor

>(in

t,stri

ng)

7: A

greg

arC

lient

e(st

ring)

:int

5.1.

1: A

greg

arC

lient

e(ob

ject

[],s

tring

):voi

d

5.1:

Agr

egar

Clie

nte(

obje

ct []

):voi

d

5: <

<int

erce

pci

>>

6: A

greg

arC

lient

e(st

ring)

:int

4: A

greg

arC

lient

e(st

ring)

:int

8: <

cons

truct

or>(

int,I

Not

ifica

dor,s

tring

)

3: A

greg

arC

lient

e(st

ring)

:int

3.1:

<>

3.2:

Agr

egar

Clie

nte(

strin

g):in

t

3.1.

1: 'T

empo

rizar

Clie

nte(

obje

ct []

):voi

d'

126

7.4

C

aso

de U

so:

Desc

on

ect

ar

Dire

ctor

ioD

irect

orio

SVD

irect

orio

L

ico

Dire

ctor

ioLG

Punt

oN

odo

Pock

etPC

Clie

nteL

GAu

dito

riaAs

pect

oAud

itoria

Rel

ayR

elay

SVas

pDire

ctor

ioAs

pect

oDire

ctor

ioID

irect

orio

Dire

ctor

ioIR

elay

Rel

ayLG

Serv

idor

Serv

idor

Solic

itude

sM

anej

ador

Man

ejad

orSo

licitu

des

Petic

ione

sPe

ticio

n

Clie

nte

Fina

l

1: E

limin

arC

lient

e():v

oid

7: <

<elim

inar

>>

2.1.

1: E

limin

arC

lient

e(in

t):vo

id

6: E

limin

arC

lient

e(in

t):vo

id

4: E

limin

arC

lient

e(in

t):vo

id

2.1.

1.1.

1.2:

'Act

ualiz

arBu

sque

das(

obje

ct []

):voi

d'

2.1.

1.1.

1: E

limin

arC

lient

e(ob

ject

[]):v

oid

2.1.

1.1.

1.1:

Elim

inar

Clie

nte(

obje

ct []

,stri

ng):v

oid

2.1:

Elim

inar

Clie

nte(

int):

void

8: <

<elim

inar

>>

2: E

limin

arC

lient

e(in

t):vo

id

5: <

<elim

inar

>>

3: E

limin

arC

lient

e(in

t):vo

id

2.1.

1.1:

<>

127

7.5

C

aso

de U

so:

En

via

r D

ato

s

Emis

or/R

ecep

tor

Clie

nteL

GTr

ansf

eren

cias

Tran

sfer

enci

as

Clie

nte

Fina

l 5: 'R

ecib

irMen

saje

(Stre

am,b

yte[

],IN

otifi

cado

r):in

t'

4: 'R

ecib

irMen

saje

(Soc

ket,b

yte[

],IN

otifi

cado

r):in

t'

3: 'E

nvia

rDat

os(s

tring

,byt

e [],

INot

ifica

dor):

void

'

2: 'E

nvia

rDat

os(S

tream

,byt

e [],

INot

ifica

dor):

void

'

1: 'E

nvia

rDat

os(S

ocke

t,byt

e [],

INot

ifica

dor):

void

'

5.1:

Rec

ibirM

ensa

je(S

tream

,byt

e[],I

Not

ifica

dor):

int

4.1:

Rec

ibirM

ensa

je(S

ocke

t,byt

e[],I

Not

ifica

dor):

int

3.1:

Env

iarD

atos

(stri

ng,b

yte

[],IN

otifi

cado

r):vo

id

2.1:

Env

iarD

atos

(Stre

am,b

yte

[],IN

otifi

cado

r):vo

id

1.1:

Env

iarD

atos

(Soc

ket,b

yte

[],IN

otifi

cado

r):vo

id

Func

ione

sso

brec

arga

das

para

env

iar y

reci

bir d

atos

128

7.6

C

aso

de U

so:

Pu

blica

ción

de S

erv

icio

s

Dire

ctor

io L

ic

oD

irect

orio

LGIR

elay

Rel

ayLG

IDire

ctor

ioD

irect

orio

aspD

irect

orio

Aspe

ctoD

irect

orio

Rel

ayR

elay

SVas

pRel

ayAs

pect

oRel

ayPo

cket

PCC

lient

eLG

Dire

ctor

ioD

irect

orio

SVPu

nto

Nod

oAu

dito

riaAs

pect

oAud

itoria

Clie

nte

Fina

l1:

Agr

egar

Serv

icio

(stri

ng,lo

ng):v

oid

6.1:

Agr

egar

Serv

icio

(stri

ng,lo

ng):v

oid

5: A

greg

arSe

rvic

io(in

t,stri

ng,lo

ng):v

oid

4: <

<int

erce

pci

>>

2: A

greg

arSe

rvic

io(in

t,stri

ng,lo

ng):v

oid

2.1.

1: 'T

empo

rizar

Clie

nte(

obje

ct []

):voi

d'

2.1:

<>

3: A

greg

arSe

rvic

io(in

t,stri

ng,lo

ng):v

oid

4.1.

1: A

greg

arSe

rvic

io(o

bjec

t [],s

tring

):voi

d

4.1:

Agr

egar

Serv

icio

(obj

ect [

]):vo

id

5.1:

Agr

egar

Serv

icio

(int,s

tring

,long

):voi

d

3.1:

Agr

egar

Serv

icio

(int,s

tring

,long

):voi

d

6: A

greg

arSe

rvic

io(s

tring

,long

):voi

d

129

7.7

C

aso

de U

so:

Solici

tar

Serv

icio

130

Anexo 8. Especificación del API

Detalle de la Clase

Class AspectoAuditoria public Clase AspectoAuditoria AspectoAuditoria es un Aspecto que se encarga de llevar un log de auditoria en el Servidor de Indices o Directorio.

Resumen de los Atributos private string instaciaTejida

Constante que indica el nombre de la instancia

private StreamWriter log Flujo de escritura

private FileStream put Flujo para el manejo de archivos

Resumen de los Constructores

public AspectoAuditoria() Constructora por defecto

Resumen de los Métodos

public void AgregarCliente(object [] args, string insTejer) Método del Aspecto que intercepta la función AgregarCliente en la clase Directorio o RelayLG con el fin de persistir la información de los clientes que se conectana a la red

131


public void AgregarServicio(object [] args, string insTejer) Método del Aspecto que intercepta la funcion AgregarServicio en el Directorio y en el Relay con el fin de persistir la información los logs de la red

public void cerrarEscritura() Método que cierra los flujos de escritura al archivo log.txt

public void EliminarCliente(object [] args, string insTejer) Método del Aspecto que intercepta la funcion EliminarCliente en el Directorio y en el Relay con el fin de persistir la información los logs de la red.

public void iniciarEscritura() Método que se encarga de iniciar un flujo de escritura para crear el log

public void interceptarBusqueda(object [] args, string insTejer) Método del Aspecto que intercepta la funcion Busqueda en el Directorio y en el Relay con el fin de persistir la información los logs de la red.

Detalles de los Atributos

instaciaTejida private string instaciaTejida


132

log private StreamWriter log

Flujo de escritura

put private FileStream put

Flujo para el manejo de archivos

Detalle del Constructor

AspectoAuditoria public AspectoAuditoria()

Constructora por defecto

Detalle de los Métodos

AgregarCliente public void AgregarCliente(object [] args, string insTejer)

Método del Aspecto que intercepta la funcion AgregarCliente en la clase Directorio o RelayLG con el fin de persistir la información de los clientes que se conectana a la red Parameteros:

Arreglo de objetos que almacena en orden los atributos de la funcion interceptada contiene el nombre de la instancia que esta siendo tejida, con ingresar la informaciónl log correspondiente

AgregarServicio public void AgregarServicio(object [] args, string insTejer)

Método del Aspecto que intercepta la funcion AgregarServicio en el Directorio y en el Relay con el fin de persistir la información los logs de la red

133

Parameteros: Arreglo de objetos que almacena en orden los atributos de la funcion interceptada contiene el nombre de la instancia que esta siendo tejida, con ingresar la informaciónl log correspondiente

cerrarEscritura public void cerrarEscritura()

Método que cierra los flujos de escritura al archivo log.txt

EliminarCliente public void EliminarCliente(object [] args, string insTejer)

Método del Aspecto que intercepta la funcion EliminarCliente en el Directorio y en el Relay con el fin de persistir la información los logs de la red. Parameteros:

Arreglo de objetos que almacena en orden los atributos de la funcion interceptada. Contiene el nombre de la instancia que esta siendo tejida, con ingresar la informaciónl log correspondiente.

iniciarEscritura public void iniciarEscritura()

Método que se encarga de iniciar un flujo de escritura para crear el log

interceptarBusqueda public void interceptarBusqueda(object [] args, string insTejer)

Método del Aspecto que intercepta la funcion Busqueda en el Directorio y en el Relay con el fin de persistir la información los logs de la red.

134

Parameteros: Arreglo de objetos que almacena en orden los atributos de la funcion interceptada. Contiene el nombre de la instancia que esta siendo tejida, con ingresar la informaciónl log correspondiente.

Clase AspectoDirectorio public Clase AspectoDirectorio Implementa:

Loom.Aspect

AspectoAuditoria es un Aspecto que se encarga de llevar un log de auditoria en el Servidor de Indices o Directorio. Resumen de los Atributos

private AspectoAuditoria aspAuditoria Aspecto que encapsula la auditoria del sistema

private static string instaciaTejida Constante que indica el nombre de la instancia

private Hashtable marrResultadoBusquedas Resumen de los Constructores

public AspectoDirectorio() Constructor por defecto


public void actualizarBusquedas(object [] args) public void AgregarCliente(object [] args)

Método del Aspecto que intercepta la funcion AgregarCliente en la clase Directorio.

135


public void AgregarServicio(object [] args) Método del Aspecto que intercepta la funcion AgregarServicio en el Directorio con el fin de invocar la clase AspectoAuditoria, encargada de implementar la la lógica de persistir la información del servicio en la red P2P.

public void EliminarCliente(object [] args) Método del Aspecto que intercepta la funcion EliminarCliente en el Directorio y en el Relay con el fin de invocar la clase AspectoAuditoria, encargada de implementar la la lógica de persistir la información los clientes que han salido de la red.

public void interceptarBusqueda(object [] args) public ResultadoBusqueda interceptarBusquedaParaAgilizar(object []

args) public void RefrescarBusquedas(object [] args)


aspAuditoria private AspectoAuditoria aspAuditoria

Aspecto que encapsula la auditoria del sistema

instaciaTejida private static string instaciaTejida = "Directorio"


marrResultadoBusquedas private Hashtable marrResultadoBusquedas

136

Detalles del Constructor

AspectoDirectorio public AspectoDirectorio()

Constructor por defecto


actualizarBusquedas public void actualizarBusquedas(object [] args)

AgregarCliente public void AgregarCliente(object [] args)

Método del Aspecto que intercepta la funcion AgregarCliente en la clase Directorio. Con el fin de invocar la clase AspectoAuditoria, encargada de implementar la la lógica de persistir la información de los clientes que se conectana a la red. Parameteros:

Arreglo de objetos que almacena en orden los atributos de la funcion interceptada.

AgregarServicio public void AgregarServicio(object [] args)

Método del Aspecto que intercepta la funcion AgregarServicio en el Directorio Con el fin de invocar la clase AspectoAuditoria, encargada de implementar la la lógica de persistir la información del servicio en la red P2P. Parameteros:


EliminarCliente public void EliminarCliente(object [] args)

Método del Aspecto que intercepta la funcion EliminarCliente en el Directorio y en el Relay con el fin de invocar la clase AspectoAuditoria, encargada de implementar la la

137

lógica de persistir la información los clientes que han salido de la red. Parameteros:


interceptarBusqueda public void interceptarBusqueda(object [] args)

interceptarBusquedaParaAgilizar public ResultadoBusqueda interceptarBusquedaParaAgilizar(object [] args)

RefrescarBusquedas public void RefrescarBusquedas(object [] args)

Clase AspectoRelay public Clase AspectoRelay Implementa:

Loom.Aspect, Tipos.ITemporizador

AspectoAuditoria es un Aspecto que se encarga de llevar un log de auditoria en el Servidor de Indices o Directorio. Debe implementar ITemporizador para que el timer le notifique el fin del tiempo y el aspecto proceda a desconectar el cliente.

Resumen de los Atributos private AspectoAuditoria aspAuditoria


private AspectoTemporizador aspTemporizador Variable que indica un delegado que maneja el temporizador de los clientes

private static string instaciaTejida Constante que indica el nombre de la instancia

138

Resumen de los Atributos private IRelay relRef

Referencia a la intrfaz de Relay, necesaria para elaborar objetos tejidos

private Thread tsTemporizador Tread que se encarga de lanzar un timer, que en caso de expirar, desconecta al cliente


public AspectoRelay() Constructora por defecto


public void AgregarServicio(object [] args) Método del Aspecto que intercepta la funcion AgregarServicio en el Directorio con el fin de invocar la clase AspectoAuditoria, encargada de implementar la la lógica de persistir la información del servicio en la red P2P.

public void BeforeBusqueda(object [] args) Función del Aspecto encargada de interceptar todos los Métodos, excepto EliminarCliente, de la clase RelayLG, lanzando un temporizador que desconecta a un nodo luego de un determindo tiempo de inactividad en la red.

public void EliminarCliente(object [] args) Método del Aspecto que intercepta la funcion EliminarCliente en el Directorio y en el Relay con el fin de invocar la clase AspectoAuditoria, encargada de implementar la la lógica de persistir la información los clientes que han salido de la red.

139


private void IniciarTemporizador() Se encarga de iniciar el timer

public void interceptarBusqueda(object [] args) public void NotificarFinTiempo()

Función que se debe incluir ya que se esta implementado la interfaz INotificador, la cual hace parte de un patrón observer

private void PararTemporizador(int tiempo) Se encarga de parar el timer.


aspAuditoria private AspectoAuditoria aspAuditoria


aspTemporizador private AspectoTemporizador aspTemporizador

Variable que indica un delegado que maneja el temporizador de los clientes

instaciaTejida private static string instaciaTejida = "Relay"


relRef private IRelay relRef

140

Referencia a la intrfaz de Relay, necesaria para elaborar objetos tejidos

tsTemporizador private Thread tsTemporizador

Tread que se encarga de lanzar un timer, que en caso de expirar, desconecta al cliente


AspectoRelay public AspectoRelay()



AfterAgregarCliente public void AfterAgregarCliente(object [] args)

AfterAgregarServicio public void AfterAgregarServicio(object [] args)

AfterAgregarSolicitud public void AfterAgregarSolicitud(object [] args)

AfterAtenderSolicitud public void AfterAtenderSolicitud(object [] args)

AfterBusqueda public void AfterBusqueda(object [] args)

141

AgregarServicio public void AgregarServicio(object [] args)

Método del Aspecto que intercepta la funcion AgregarServicio en el Directorio Con el fin de invocar la clase AspectoAuditoria, encargada de implementar la la lógica de persistir la información del servicio en la red P2P. Parameteros:


BeforeAgregarCliente public void BeforeAgregarCliente(object [] args)

BeforeAgregarServicio public void BeforeAgregarServicio(object [] args)

BeforeAgregarSolicitud public void BeforeAgregarSolicitud(object [] args)

BeforeAtenderSolicitud public void BeforeAtenderSolicitud(object [] args)

BeforeBusqueda public void BeforeBusqueda(object [] args)

Función del Aspecto encargada de interceptar todos los Métodos, excepto EliminarCliente, de la clase RelayLG, lanzando un temporizador que desconecta a un nodo luego de un determindo tiempo de inactividad en la red. Parameteros:


142

EliminarCliente public void EliminarCliente(object [] args)

Método del Aspecto que intercepta la funcion EliminarCliente en el Directorio y en el Relay con el fin de invocar la clase AspectoAuditoria, encargada de implementar la la lógica de persistir la información los clientes que han salido de la red. Parameteros:


IniciarTemporizador private void IniciarTemporizador()

Se encarga de iniciar el timer

interceptarBusqueda public void interceptarBusqueda(object [] args)

NotificarFinTiempo public void NotificarFinTiempo()

Función que se debe incluir ya que se esta implementado la interfaz INotificador, la cual hace parte de un patrón observer

PararTemporizador private void PararTemporizador(int tiempo)

Se encarga de parar el timer.

Clase AspectoTemporizador public Clase AspectoTemporizador Thread que funciona como timer y notificado, mediante patrón observer,

143

que un cliente debe salir del Relay por estar inactivo determinado tiempo.

Resumen de los Atributos private ArrayList Clientes

Arreglo de interfaces ITemporizador, necesarias para notificar a los observados el fin del tiempo del timer.

private int TiempoEspera Tiempo que dura el timer antes de notificar al cliente o Realy


public AspectoTemporizador(int sleeTime) Constructora el hilo.


public void AgregarCliente(ITemporizador client) Función que se encarga de mantener una colleccion de interfaces del Relay (ITemporizador) con el fin de poder notificarles si se ha expirado el tiempo del timer

public void EliminarCliente(ITemporizador client) Cuando el cliente se desconecta por causas difentes al fin de temporizador, este ya no debe ser tenido en cuenta más.

public void Temporizar() Función la cual se inicia la ejecución de Thread.

144


Clientes private ArrayList Clientes

Arreglo de interfaces ITemporizador, necesarias para notificar a los observados el fin del tiempo del timer.

TiempoEspera private int TiempoEspera

Tiempo que dura el timer antes de notificar al cliente o Realy


AspectoTemporizador public AspectoTemporizador(int sleeTime)

Constructora el hilo. Parameteros:

Recibe como parametro el tiempo máxiimo de inactividad de un cliente


AgregarCliente public void AgregarCliente(ITemporizador client)

Función que se encarga de mantener una colleccion de interfaces del Relay (ITemporizador) con el fin de poder notificarles si se ha expirado el tiempo del timer Parameteros:

Interfaz del Relay, necesaria en la estructura del patrón observer

EliminarCliente public void EliminarCliente(ITemporizador client)

145

Cuando el cliente se desconecta por causas difentes al fin de temporizador, este ya no debe ser tenido en cuenta más. Parameteros:

Interfaz del Relay

Temporizar public void Temporizar()

Función la cual se inicia la ejecución de Thread. Su funcion es poner a dormir el hilo, si éste se despierta por si mismo y no por un evento en el Relay. Éste debe notificar a la interfaz del relay que debe desconectar el cliente.

Clase DirectorioSV public Clase DirectorioSV Implementa:

System.Web.Services.WebService

Clase que sirve de entrada para las peticiones de los relays

Resumen de los Atributos private IContainer components private IDirectorio dirLogica

Referencia de la la lógica del Servidor de Índices


public DirectorioSV() Constructora que inicializa el Servicio Web del Directorio

146


public int AgregarCliente(string strIp) Agrega un cliente a la red P2P

public void AgregarServicio(int numIdentificador, string strServicio, long numTamano) Agrega un servicio a prestar en el nodo

public void AgregarServicios(int numIdentificador, string [] arrServicios, long[] arrTamanos) Agrega un listado de servicios al nodo

public void AgregarSolicitud(int numSolicitante, int numSolicitado, string strServicio, string strIp) Agrega una solicitud a la cola de solicitudes, para que sea atendida

public void AtenderSolicitud(int numSolicitante, int numSolicitado, string strServicio, string strIp) Elimina una solicitud ya atendida

public ResultadoBusqueda Busqueda(string strDescripcion) protected void Dispose(bool disposing)

Clean up any resources being used.

public void EliminarCliente(int numIdentificador) Desconecta un cliente de la Red P2P

147


private void InitializeComponent() Required method for Designer support - do not modify the contents of this method with the code editor.

public Peticion ObtenerSoliciudes(int numSolicitado) Obtiene las solicitudes de un nodo


components private IContainer components = null

dirLogica private IDirectorio dirLogica

Referencia de la la lógica del Servidor de Índices


DirectorioSV public DirectorioSV()

Constructora que inicializa el Servicio Web del Directorio Observaciones:

En este paso se obtiene la la lógica del directorio mediante el proceso de tejido de la fabrica


AgregarCliente public int AgregarCliente(string strIp)

Agrega un cliente a la red P2P

148

Parameteros: Dirección IP del Nodo

Retorna: Identificador del nodo. Se obtiene desde el Servidor de Índices

AgregarServicio public void AgregarServicio(int numIdentificador, string strServicio, long numTamano)

Agrega un servicio a prestar en el nodo Parameteros:

Identificador del nodo Descripción del servicio Tamaño del archivo

AgregarServicios public void AgregarServicios(int numIdentificador, string [] arrServicios, long[] arrTamanos)

Agrega un listado de servicios al nodo Parameteros:

Identificador del nodo Listado de las descripciones de los servicios Listado de los tamaños de los archivos a publicar

AgregarSolicitud public void AgregarSolicitud(int numSolicitante, int numSolicitado, string strServicio, string strIp)

Agrega una solicitud a la cola de solicitudes, para que sea atendida

Parameteros: Identificador del solicitante Identificador del solicitado Descripción del servicio Dirección IP del Solicitante

149

AtenderSolicitud public void AtenderSolicitud(int numSolicitante, int numSolicitado, string strServicio, string strIp)

Elimina una solicitud ya atendida Parameteros:

Identificador del solicitante Identificador del solicitado Descripción del servicio Dirección del solicitante

Busqueda public ResultadoBusqueda Busqueda(string strDescripcion)

Dispose protected void Dispose(bool disposing)


EliminarCliente public void EliminarCliente(int numIdentificador)

Desconecta un cliente de la Red P2P Parameteros:

Identificador del nodo

InitializeComponent private void InitializeComponent()

Required method for Designer support - do not modify the contents of this method with the code editor.

150

ObtenerSoliciudes public Peticion ObtenerSoliciudes(int numSolicitado)

Obtiene las solicitudes de un nodo Parameteros:

Identificacion del nodo Retorna:

Lista de las peticiones pendientes por atender

Clase FabricaObjetosTejidos public Clase FabricaObjetosTejidos Clase que encapsula el tejido de las clases que tienen puntos de corte con los aspectos Observaciones:

Implementa el patron Fabrica Abstracta Resumen de los Métodos

public IDirectorio getDirectorio() Obtiene una instancia tejida de una interfaz de directorio

public IRelay getRelay() Obtiene una instancia tejida de una interfaz de relay


getDirectorio public IDirectorio getDirectorio()

Obtiene una instancia tejida de una interfaz de directorio Retorna:

Instancia tejida

151

getRelay public IRelay getRelay()

Obtiene una instancia tejida de una interfaz de relay Retorna:

Instancia tejida

Clase ClienteLG public Clase ClienteLG Resumen de los Atributos

private INotificador mntfNotificador Notificador de la información presentarle al Cliente Final

private int mnumIdentificador Identificador del Cliente.

private RelaySV mrlyServicio Referencia del Servicio Web del Relay por el cual se conecta con la red P2P

private string mstrIpLocal Dirección IP Local del dispositivo

private string mstrNombreDirectorio Nombre del Relay al cual se conectará


public ClienteLG(INotificador ntfNotificador, string strNombreDirectorio)

152


public void AgregarCliente() Agrega un cliente a la red P2P

public void AgregarServicio(string strServicio, long numTamano) Agrega un servicio a prestar en el nodo

public void AgregarServicios(string[] arrServicios, long[] numTamanos) Agrega un listado de servicios al nodo

public ResultadoBusqueda Busqueda(string strDescripcion) public void EliminarCliente()

Desconecta un cliente de la Red P2P

public void EnviarDatos(Socket sckEnlace, byte [] arrDatos) Envia datos de un par hacia otro par

public void EnviarDatos(Stream stmFlujo, byte [] arrDatos) Envia datos de un par hacia otro par

public void EnviarDatos(string strIp, byte [] arrDatos) Envia datos de un par hacia otro par

public int RecibirMensaje(Socket sckEnlace, byte[] arrbytMensaje) Recibe datos desde un par

153


public int RecibirMensaje(Stream stmFlujo, byte[] arrbytMensaje) Recibe datos desde un par

public void SolicitarServicio(int numSolicitado, string strServicio, string strRuta, long numTamano)

Envia una solicitud para consumir un servicio


mntfNotificador private INotificador mntfNotificador

Notificador de la información presentarle al Cliente Final

mnumIdentificador private int mnumIdentificador

Identificador del Cliente. Es obtenido desde el Servidor de Índices

mrlyServicio private RelaySV mrlyServicio

Referencia del Servicio Web del Relay por el cual se conecta con la red P2P

mstrIpLocal private string mstrIpLocal

Dirección IP Local del dispositivo

154

mstrNombreDirectorio private string mstrNombreDirectorio

Nombre del Relay al cual se conectará


ClienteLG public ClienteLG(INotificador ntfNotificador, string strNombreDirectorio)


AgregarCliente public void AgregarCliente()

Agrega un cliente a la red P2P

AgregarServicio public void AgregarServicio(string strServicio, long numTamano)


Descripción del servicio Tamaño del archivo

AgregarServicios public void AgregarServicios(string[] arrServicios, long[] numTamanos)


Listado de las descripciones de los servicios Listado de los tamaños de los archivos a publicar


155

EliminarCliente public void EliminarCliente()


EnviarDatos public void EnviarDatos(Socket sckEnlace, byte [] arrDatos)

Envia datos de un par hacia otro par Parameteros:

Socket por donde se van a enviar los datos Datos a enviar

EnviarDatos public void EnviarDatos(Stream stmFlujo, byte [] arrDatos)


Flujo por donde se envian los datos Datos a enviar

EnviarDatos public void EnviarDatos(string strIp, byte [] arrDatos)


Dirección IP del punto solicitante Datos a enviar

RecibirMensaje public int RecibirMensaje(Socket sckEnlace, byte[] arrbytMensaje)

156

Recibe datos desde un par Parameteros:

Socket por donde viajan los datos Datos a recibir

Retorna: Tamaño de bytes enviados

RecibirMensaje public int RecibirMensaje(Stream stmFlujo, byte[] arrbytMensaje)


Flujo por donde viajan los datos Datos a recibir


SolicitarServicio public void SolicitarServicio(int numSolicitado, string strServicio, string strRuta, long numTamano)

Envia una solicitud para consumir un servicio Parameteros:

Identificador del nodo servidor Descripción del servicio Ubicación físic donde se desea salvar el archivo Tamaño del archivo a transferir

Clase ConsumirServicio public Clase ConsumirServicio Clase que encapsula la función de consumir un servicio

157

Resumen de los Atributos private INotificador mntfNotificador


private int mnumPuerto Puerto por el cual se comunica con el punto ofertante

private long mnumTamano Tamaño del archivo

private string mstrRuta Ruta fisica donde se va a almacenar el archivo

private Thread mthtPrncipal Hilo principal de la clase

private TcpListener mtplEscucha Clase que provee el soporte para establecer la comunicación el punto ofertante


public ConsumirServicio(string strRuta, long numTamano, INotificador ntfNotificador) Constructora sobrecargada


public void LanzarServidor() Inicia el servicio de escucha de la atención del servicio

158


private void RecibirServicio(Socket sckEnlace)




mnumPuerto private int mnumPuerto

Puerto por el cual se comunica con el punto ofertante

mnumTamano private long mnumTamano

Tamaño del archivo

mstrRuta private string mstrRuta

Ruta fisica donde se va a almacenar el archivo

mthtPrncipal private Thread mthtPrncipal

Hilo principal de la clase

mtplEscucha private TcpListener mtplEscucha

159

Clase que provee el soporte para establecer la comunicación el punto ofertante


ConsumirServicio public ConsumirServicio(string strRuta, long numTamano, INotificador ntfNotificador)

Constructora sobrecargada Parameteros:

Ruta físicadel archivo Tamaño del archivo Notificador de mensajes


LanzarServidor public void LanzarServidor()

Inicia el servicio de escucha de la atención del servicio

RecibirServicio private void RecibirServicio(Socket sckEnlace)

Clase ServidorSolicitudes public Clase ServidorSolicitudes Clase que encapsula la función de consumir un servicio

Resumen de los Atributos private INotificador mntfNotificador


160

Resumen de los Atributos private int mnumSolicitado

Idetnificador del solicitado

private int mnumSolicitante Identificador del solicitante

private RelaySV mrlyServicio Referencia del Servicio Web del Relay

private string mstrIp Dirección IP del solicitante

private string mstrServicio Descripciónel servicio

private Thread mthtPrncipal Hilo principal de la clase


public ServidorSolicitudes(int numSolicitado, INotificador ntfNotificador, string strNombreServidor) Constructora sobrecargada


public void LanzarServidor() Inicia el servicio de escucha de la atención del servicio

161


private void PrestarServicio() Inicia el servicio de escucha de la atención del servicio




mnumSolicitado private int mnumSolicitado

Idetnificador del solicitado

mnumSolicitante private int mnumSolicitante

Identificador del solicitante

mrlyServicio private RelaySV mrlyServicio

Referencia del Servicio Web del Relay

mstrIp private string mstrIp

Dirección IP del solicitante

162

mstrServicio private string mstrServicio

Descripciónel servicio

mthtPrncipal private Thread mthtPrncipal

Hilo principal de la clase


ServidorSolicitudes public ServidorSolicitudes(int numSolicitado, INotificador ntfNotificador, string strNombreServidor)


Identificador del solicitante Notificador general Nombre del relay al cual se va a conectar


LanzarServidor public void LanzarServidor()


PrestarServicio private void PrestarServicio()


163

Clase Transferencias public Clase Transferencias

Clase que encapsula la las trasnferencias de datos entre los pares

Resumen de los Atributos

public static long FRAME_SIZE Tamaño de los paquetes enviados entre los pares

public static int NUMPUERTO Resumen de los Métodos

public static void EnviarDatos(Socket sckEnlace, byte [] arrDatos, INotificador ntfNotificador) Envia datos de un par hacia otro par

public static void EnviarDatos(Stream stmFlujo, byte [] arrDatos, INotificador ntfNotificador) Envia datos de un par hacia otro par

public static void EnviarDatos(string strIp, byte [] arrDatos, INotificador ntfNotificador) Envia datos de un par hacia otro par

public static int RecibirMensaje(Socket sckEnlace, byte[] arrbytMensaje, INotificador ntfNotificador) Recibe datos desde un par

public static int RecibirMensaje(Stream stmFlujo, byte[] arrbytMensaje, INotificador ntfNotificador) Recibe datos desde un par

164


FRAME_SIZE public static long FRAME_SIZE = 1024

Tamaño de los paquetes enviados entre los pares

NUMPUERTO public static int NUMPUERTO = 65000


EnviarDatos public static void EnviarDatos(Stream stmFlujo, byte [] arrDatos, INotificador ntfNotificador)


Flujo por donde se envian los datos Datos a enviar Notificador general

EnviarDatos public static void EnviarDatos(Socket sckEnlace, byte [] arrDatos, INotificador ntfNotificador)


Socket por donde se van a enviar los datos Datos a enviar Notificador general

EnviarDatos public static void EnviarDatos(string strIp, byte [] arrDatos, INotificador ntfNotificador)

165


Dirección IP del punto solicitante Datos a enviar Notificador general

RecibirMensaje public static int RecibirMensaje(Stream stmFlujo, byte[] arrbytMensaje, INotificador ntfNotificador)


Flujo por donde viajan los datos Notificador general Datos a recibir


RecibirMensaje public static int RecibirMensaje(Socket sckEnlace, byte[] arrbytMensaje, INotificador ntfNotificador)

Recibe datos desde un par

Parameteros: Socket por donde viajan los datos Notificador general Datos a recibir


Clase Directorio public Clase Directorio Implementa:

Tipos.IDirectorio

166

Clase la lógica que redirecciona las solicitudes que llegan desde el Servicio Web del Directorio Observaciones:

Esta clase es construida por la fábrica, quien teje sobre los puntos de corte los aspectos Resumen de los Atributos

private DirectorioLG dirLogica Refencia a la la lógica del directorio

private ManejadorSolicitudes manSolicitudes Refrencia al manejador de solicitudes


public Directorio() Constructora por defecto, obtiene las referencias de las instancias que son construidas bajo el patron singleton





167




public ResultadoBusqueda Busqueda(string strDescripcion) public void EliminarCliente(int numIdentificador)




dirLogica private DirectorioLG dirLogica

Refencia a la la lógica del directorio

manSolicitudes private ManejadorSolicitudes manSolicitudes

Refrencia al manejador de solicitudes

168


Directorio public Directorio()

Constructora por defecto, obtiene las referencias de las instancias que son construidas bajo el patron singleton



Agrega un cliente a la red P2P Parameteros:

Dirección IP del Nodo Retorna:

Identificador del nodo. Se obtiene desde el Servidor de Índices



Identificador del nodo Descripciónel servicio Tamaño del archivo


Agrega un listado de servicios al nodo

169

Parameteros: Identificador del nodo Listado de las descripciones de los servicios Listado de los tamaños de los archivos a publicar


Agrega una solicitud a la cola de solicitudes, para que sea atendida Parameteros:

Identificador del solicitante Identificador del solicitado Descripciónel servicio Dirección IP del Solicitante



Identificador del solicitante Identificador del solicitado Descripciónel servicio Dirección IP del solicitante




170

Parameteros: Identificador del nodo


Obtiene las solicitudes de un nodo

Parameteros: Identificacion del nodo

Retorna: Lista de las peticiones pendientes por atender

Clase DirectorioLG public Clase DirectorioLG Clase que maneja la la lógica conserniente al servidor de índices Resumen de los Atributos

private static DirectorioLG instance Instancia del directorio, necesaria para poder implementar un patrón singleton.

private static Hashtable marrNodos private static int MAX_RESULTADOS

private int numConsecutivo Consecutivo que genera los identificadores de los nodos


private DirectorioLG() Constructora por defecto

171




public void AgregarServicios(int numIdentificador, string[] arrServicios, long[] arrTamanos) Agrega un listado de servicios al nodo


Elimina un nodo del listado de indices

public static DirectorioLG Instancia() Obtiene la referencia del manejador de solicitudes

private string ObtenerIp(int numIdentificador) Obtiene la dirección IP de un nodo específico


instance private static DirectorioLG instance

Instancia del directorio, necesaria para poder implementar un patrón singleton.

marrNodos private static Hashtable marrNodos

172

MAX_RESULTADOS private static int MAX_RESULTADOS = 100

numConsecutivo private int numConsecutivo

Consecutivo que genera los identificadores de los nodos


DirectorioLG private DirectorioLG()

Constructora por defecto Observaciones:

Es una constructora privada, para instanciar este objeto es necesario llamar a la función instancia()





Retorna el valor del consecutivo actual


Agrega un servicio a prestar en el nodo

173

Parameteros: Identificador del nodo Descripciónel servicio Tamaño del archivo

AgregarServicios public void AgregarServicios(int numIdentificador, string[] arrServicios, long[] arrTamanos)





Elimina un nodo del listado de indices Parameteros:


Instancia public static DirectorioLG Instancia()

Obtiene la referencia del manejador de solicitudes Retorna:

Instancia actual en memoria del directorio ObtenerIp private string ObtenerIp(int numIdentificador)

174

Obtiene la dirección IP de un nodo específico Parameteros:

Identificador del nodo Retorna:

Dirección IP del nodo

Clase ManejadorSolicitudes public Clase ManejadorSolicitudes Clase que maneja las colas de solicitudes pendientes por atender de los nodos Resumen de los Atributos

private static ManejadorSolicitudes

instance Instancia del manejador, necesaria para poder implementar un patrón singleton.

private static ArrayList marrSolicitudes Resumen de los Constructores

private ManejadorSolicitudes() Constructora por defecto



175



public void EliminarCliente(int numIdentificacion) Elimina todas las peticiones de un nodo que se desconecta de la red P2P

public static ManejadorSolicitudes

Instancia() Obtiene la referencia del manejador de solicitudes



instance private static ManejadorSolicitudes instance

Instancia del manejador, necesaria para poder implementar un patrón singleton.

marrSolicitudes private static ArrayList marrSolicitudes


ManejadorSolicitudes private ManejadorSolicitudes()


176

Observaciones: Es una constructora privada, para instanciar este objeto es necesario llamar a la función instancia()








EliminarCliente public void EliminarCliente(int numIdentificacion)

Elimina todas las peticiones de un nodo que se desconecta de la red P2P Parameteros:

Identificación del nodo

177

Instancia public static ManejadorSolicitudes Instancia()

Obtiene la referencia del manejador de solicitudes Retorna:

Instancia actual en memoria del manejador de solicitudes





Clase RelayLG public Clase RelayLG Implementa:

Tipos.IRelay

Clase que maneja la la lógica del relay Observaciones:

Esta clase es construida por la fábrica, quien teje sobre los puntos de corte los aspectos. Resumen de los Atributos

private DirectorioSV mdsvServicio Referencia del Servicio Web del Directorio por el cual se comunica con el

private int numIdentificador Variable que asigna el Directorio a cada uno de los clientes.

178


public RelayLG() Constructora por defecto

public RelayLG(string strDireccion) Constructora que recibe como parametro la direccion del servidor de indices




public void AgregarServicios(int numIdentificador, string[] arrServicios, long[] arrTamanos) Agrega un listado de servicios al nodo



public ResultadoBusqueda Busqueda(string strDescripcion)

179


public void EliminarCliente() Desconecta un cliente de la Red P2P



public void setDirectorio(string strNombreDirectorio) Función que recibe como parametro la dirección donde se encuentra el Servidor de Ídices


mdsvServicio private DirectorioSV mdsvServicio

Referencia del Servicio Web del Directorio por el cual se comunica con el

numIdentificador private int numIdentificador

Variable que asigna el Directorio a cada uno de los clientes.


RelayLG public RelayLG()


180

RelayLG public RelayLG(string strDireccion)

Constructora que recibe como parametro la direccion del servidor de indices Parameteros:

Direccion del servidor de indices









AgregarServicios public void AgregarServicios(int numIdentificador, string[] arrServicios, long[] arrTamanos)


181











182








setDirectorio public void setDirectorio(string strNombreDirectorio)

Función que recibe como parametro la dirección donde se encuentra el Servidor de Índices Parameteros:

Nombre del Servidor de Índices

Clase RelaySV public Clase RelaySV Implementa:

System.Web.Services.WebService

Clase que sirve de entrada para las peticiones del cliente del dispositivo móvil

183

Resumen de los Atributos private IContainer components

private IRelay rlyLogica Referencia de la la lógica del Relay


public RelaySV() Constructora por defecto, necesaria para el correcto funcionamiento del Servicio Web

public RelaySV(string strNombreDirectorio) Constructora sobrecargada, a partir del nombre carga el Servicio Web del Servidor de Índidces





184




public ResultadoBusqueda Busqueda(string strDescripcion) protected void Dispose(bool disposing)



private void InitializeComponent() Required method for Designer support - do not modify the contents of this method with the code editor.



components private IContainer components = null

rlyLogica private IRelay rlyLogica

185

Referencia de la la lógica del Relay


RelaySV public RelaySV()

Constructora por defecto, necesaria para el correcto funcionamiento del Servicio Web Observaciones:

El sitio donde corre el Servidor de Indices por defecto es LocalHost

RelaySV public RelaySV(string strNombreDirectorio)

Constructora sobrecargada, a partir del nombre carga el Servicio Web del Servidor de Índices Parameteros:








186










Elimina una solicitud ya atendida

187

Parameteros: Identificador del solicitante Identificador del solicitado Descripciónel servicio Dirección IP del solicitante


Dispose protected void Dispose(bool disposing)



Desconecta un cliente de la Red P2P Parameteros:


InitializeComponent private void InitializeComponent()

Required method for Designer support - do not modify the contents of this method with the code editor.



188



Clase Nodo public Clase Nodo Clase la lógica que representa un punto en la red P2P

Resumen de los Atributos public int Identificador


public string Ip Dirección IP del nodo

private ArrayList marrServicios Listado de los servicios que presta el nodo.

private int mnumIdentificador Identificador del nodo

private string mstrIp Dirección IP del nodo


public Nodo() Constructora por defecto

189

Resumen de los Constructores public Nodo(int numIdentificador, string strIp)

Constructora sobrecargada


public void AgregarServicio(string strServicio, long numTamano) Agrega un servicio al listado de servicios ofrecidos

public void AgregarServicios(string[] arrServicios, long[] numTamanos) Agrega un listado de servicios al listado de servicios ofrecidos

public ArrayList EstaServicio(string strDescripcion)


Identificador public int Identificador


Ip public string Ip


marrServicios private ArrayList marrServicios

Listado de los servicios que presta el nodo. Guarda objetos de tipo Servicio

190






Nodo public Nodo()


Nodo public Nodo(int numIdentificador, string strIp)


Identificador del nodo Dirección IP del nodo


AgregarServicio public void AgregarServicio(string strServicio, long numTamano)

Agrega un servicio al listado de servicios ofrecidos Parameteros:

Descripciónel servicio Tamaño del archivo

191

AgregarServicios public void AgregarServicios(string[] arrServicios, long[] numTamanos)

Agrega un listado de servicios al listado de servicios ofrecidos Parameteros:

Listado de las descripciones de los servicios Listado de los tamaños de los archivos a publicar

EstaServicio public ArrayList EstaServicio(string strDescripcion)

Clase Peticion public Clase Peticion Clase la lógica que representa las peticiones de los clientes Resumen de los Atributos

public string Ip Dirección IP del Solicitante

private int mnumSolicitado Identificador del Solicitado

private int mnumSolicitante Identificador del Solicitante

private string mstrIp Dirección IP del solicitante

192

Resumen de los Atributos private string mstrServicio

Descripciónel Servicio

public string Servicio Descripciónel servicio

public int Solicitado Identificador del solicitado

public int Solicitante Identificador del solicitante


public Peticion() Constructora por defecto, necesaria para el paso del objeto por los Servicios Web

public Peticion(int numSolicitante, int numSolicitado, string strServicio, string strIp) Constructora sobrecargada


Ip public string Ip

Dirección IP del Solicitante

193

mnumSolicitado private int mnumSolicitado

Identificador del Solicitado

mnumSolicitante private int mnumSolicitante

Identificador del Solicitante


Dirección IP del solicitante


Descripciónel Servicio

Servicio public string Servicio


Solicitado public int Solicitado

Identificador del solicitado

Solicitante public int Solicitante

194

Identificador del solicitante


Peticion public Peticion()

Constructora por defecto, necesaria para el paso del objeto por los Servicios Web

Peticion public Peticion(int numSolicitante, int numSolicitado, string strServicio, string strIp)


Identificador del solicitante Identificador del solicitado Descricpión del servicio Dirección IP del solicitante

Clase ResultadoBusqueda public Clase ResultadoBusqueda Resumen de los Atributos

public int Identificador Identificador del nodo

private int mnumIdentificador Identificador del nodo

195

Resumen de los Atributos private long mnumTamano

Tamaño del archivo

private string mstrServicio Descripciónel servicio

public string Servicio Descripciónel servicio

public long Tamano Tamaño del archivo


public ResultadoBusqueda() Constructora por defecto, necesaria para el paso del objeto por los Servicios Web

public ResultadoBusqueda(int numIdentificador, string strServico, long numTamano) Constructora sobrecargada


Identificador public int Identificador



196



Tamaño del archivo



Servicio public string Servicio


Tamano public long Tamano

Tamaño del archivo


ResultadoBusqueda public ResultadoBusqueda()

Constructora por defecto, necesaria para el paso del objeto por los Servicios Web

ResultadoBusqueda public ResultadoBusqueda(int numIdentificador, string strServico, long numTamano)

197



Clase Servicio public Clase Servicio Clase la lógica que representa un servicio

Resumen de los Atributos public string Descripcion


private long mnumTamano Tamaño del archivo

private string mstrDescripcion Descripciónel servicio

public long Tamano Tamaño del archivo


public Servicio() Constructora por defecto

198

Resumen de los Constructores public Servicio(string strDescripcion, long

numTamano) Constructora sobrecargada


Descripcion public string Descripcion



Tamaño del archivo

mstrDescripcion private string mstrDescripcion


Tamano public long Tamano

Tamaño del archivo


Servicio public Servicio()


199

Servicio public Servicio(string strDescripcion, long numTamano)

Constructora sobrecargada

Parameteros: Descripciónel servicio Tamaño del archivo

Detalles de las Interfaces

Interface IDirectorio Clases conocidades que Implementen la Interfaz:

Directorio

public interface IDirectorio Interfaz que define los Métodos necesarios para impelmentar un Directorio. Observaciones:

Se utiliza para la construcción de objetos tejidos Resumen de los Métodos



public void AgregarServicios(int numIdentificador, string [] arrServicios, long [] arrTamanos) Agrega un listado de servicios al nodo

200













201



AgregarServicios public void AgregarServicios(int numIdentificador, string [] arrServicios, long [] arrTamanos)





Parameteros: Identificador del solicitante Identificador del solicitado Descripciónel servicio Dirección IP del Solicitante


Elimina una solicitud ya atendida

202

Parameteros: Identificador del solicitante Identificador del solicitado Descripciónel servicio Dirección IP del solicitante









Interface INotificador public interface INotificador Interfaz que define los Métodos que debe tener un cliente final para desplegar los mensajes, errores y avances

203


public void GenerarExcepcion(string strMensaje, Exception objEx) Genera un mensaje, cuando ocurre una excepción

public void GenerarNotificacion(string strMensaje) Genera unh mensaje de información ///

public void MostrarAvanceEnviar(string strServicio, int numPorcentaje) Muestra el estado de avance al enviar datos

public void MostrarAvanceRecibir(string strServicio, int numPorcentaje) Muestra el estado de avance al recibir datos


GenerarExcepcion public void GenerarExcepcion(string strMensaje, Exception objEx)

Genera un mensaje, cuando ocurre una excepción Parameteros:

Mensaje a desplegar que muestra el lugar donde sucedio la excepcion Excepcion ocurrida

GenerarNotificacion public void GenerarNotificacion(string strMensaje)

Genera un mensaje de información Parameteros:

Contenido del mensaje

MostrarAvanceEnviar public void MostrarAvanceEnviar(string strServicio, int numPorcentaje)

204

Muestra el estado de avance al enviar datos Parameteros:

Descripciónel servicio que se estado enviando Porcentaje de avance

MostrarAvanceRecibir public void MostrarAvanceRecibir(string strServicio, int numPorcentaje)

Muestra el estado de avance al recibir datos Parameteros:

Descripciónel servicio que se esta recibiendo Porcentaje de avance

Interface IRelay Clases conocidades que Implementen la Interfaz:

RelayLG

public interface IRelay Interfaz que define los Métodos necesarios para impelmentar un Relay. Observaciones:

Se utiliza para la construcción de objetos tejidos Resumen de los Métodos



205


public void AgregarServicios(int numIdentificador, string [] arrServicios, long [] arrTamanos) Agrega un listado de servicios al nodo



public ResultadoBusqueda Busqueda(string strDescripcion) public void EliminarCliente()




public void setDirectorio(string strNombreDirectorio) Función que recibe como parametro la dirección donde se encuentra el Servidor de Índices

206







Agrega un servicio a prestar en el nodo

Parameteros: Identificador del nodo Descripciónel servicio Tamaño del archivo

AgregarServicios public void AgregarServicios(int numIdentificador, string [] arrServicios, long [] arrTamanos)




207


Parameteros: Identificador del solicitante Identificador del solicitado Descripciónel servicio Dirección IP del Solicitante










208





setDirectorio public void setDirectorio(string strNombreDirectorio)

Función que recibe como parametro la dirección donde se encuentra el Servidor de Índices Parameteros:


Interface ITemporizador Clases conocidades que Implementen la Interfaz:

AspectoRelay

public interface ITemporizador Interfaz que expone el Método de notificación para el aspecto timer. Resumen de los Métodos

public void NotificarFinTiempo() Método propio de la estructura del patrón observer, debe ser implementado para que los observados o IRelays puedan proceder a eliminar un nodo

209


NotificarFinTiempo public void NotificarFinTiempo()

Método propio de la estructura del patrón observer, debe ser implementado para que los observados o IRelays puedan proceder a eliminar un nodo

210

An

exo

9.

Resu

ltad

os

de las

Pru

eb

as

9

.1 P

rueb

as

a los

AP

Is E

qu

ipo 1

A

PI C

ON

ASP

ECTO

SA

CA-

AP-

T0A

CA-

AP-

T1A

CA-

AP-

T2A

CA-

AP-

T3A

CA-

SI-T

4AC

A-S

I-T5

ACA

-RL-

T4A

CA-

RL-

T5

Mue

stra

Tiem

pos

Tiem

pos

Tiem

pos

Tiem

pos

CP

UTi

empo

sTr

afic

oTi

empo

s R

espu

esta

CPU

Tiem

pos

Traf

ico

Tiem

pos

Res

pues

ta1

00:2

1:32

00:1

9:35

01:3

7:27

01:0

7:12

16%

00:2

3:21

46%

00:2

2:08

12%

00:1

7:23

48%

00:1

7:05

200

:21:

3400

:27:

1500

:55:

3601

:03:

0022

%00

:20:

0165

%00

:26:

0113

%00

:15:

5645

%00

:16:

543

00:1

9:06

00:1

7:16

01:0

8:08

01:0

8:32

15%

00:1

4:23

66%

00:2

0:37

15%

00:1

6:15

45%

00:1

7:22

400

:25:

1300

:16:

5400

:59:

2401

:37:

0514

%00

:20:

3066

%00

:30:

5813

%00

:18:

2542

%00

:18:

135

00:1

9:11

00:1

8:12

01:0

9:38

01:2

2:56

20%

00:2

9:58

62%

00:3

1:25

12%

00:1

7:01

43%

00:1

7:29

600

:19:

5000

:16:

1301

:07:

2001

:39:

0518

%00

:22:

2466

%00

:28:

5912

%00

:15:

2455

%00

:17:

337

00:1

9:41

00:1

4:30

01:1

0:34

01:1

5:32

14%

00:2

3:12

64%

00:2

6:13

10%

00:1

6:22

50%

00:1

7:18

800

:20:

0800

:16:

1401

:07:

0401

:22:

5816

%00

:25:

1962

%00

:27:

3511

%00

:16:

4742

%00

:16:

229

00:2

0:26

00:1

4:28

01:0

3:21

01:0

8:05

15%

00:2

4:39

63%

00:2

1:23

10%

00:1

6:55

40%

00:1

7:13

1000

:19:

0900

:14:

3901

:05:

4301

:16:

3214

%00

:25:

0166

%00

:24:

2515

%00

:16:

4951

%00

:17:

08M

edia

00:2

0:35

00:1

7:32

01:0

8:26

01:1

8:06

16%

00:2

2:53

63%

00:2

5:58

12%

00:1

6:44

46%

00:1

7:16

API

SIN

AS

PEC

TOS

ASA-

AP-

T0AS

A-A

P-T1

ASA-

AP-

T2AS

A-A

P-T3

ASA

-SI-T

4AS

A-S

I-T5

ASA-

RL-

T4A

SA-R

L-T5

Mue

stra

Tiem

pos

Tiem

pos

Tiem

pos

Tiem

pos

CP

UTi

empo

sTr

afic

oTi

empo

s R

espu

esta

CPU

Tiem

pos

Traf

ico

Tiem

pos

Res

pues

ta1

00:1

2:09

00:0

9:30

01:1

1:40

01:0

3:01

15%

00:4

7:02

65%

00:2

4:01

13%

00:3

0:02

44%

00:1

8:21

200

:13:

3300

:09:

0001

:05:

1301

:03:

1125

%00

:36:

0862

%00

:26:

0012

%00

:31:

2548

%00

:17:

563

00:1

3:20

00:0

8:58

01:0

4:29

01:0

2:27

12%

00:3

7:30

63%

00:2

0:35

13%

00:3

2:29

50%

00:1

8:21

400

:13:

1800

:09:

0501

:03:

5501

:02:

2112

%00

:41:

1571

%00

:24:

3713

%00

:35:

0152

%00

:16:

215

00:1

3:04

00:0

9:45

01:0

3:58

01:0

2:26

12%

00:3

7:59

67%

00:2

2:31

14%

00:3

1:26

50%

00:1

7:53

600

:12:

5600

:09:

3201

:08:

2901

:02:

0213

%00

:36:

2566

%00

:26:

3412

%00

:33:

0650

%00

:18:

327

00:1

3:22

00:0

8:59

01:0

7:52

01:0

3:24

14%

00:4

0:25

71%

00:2

3:46

11%

00:3

0:53

41%

00:1

8:00

800

:13:

1200

:09:

1201

:06:

1501

:01:

0712

%00

:40:

5270

%00

:23:

1511

%00

:31:

0140

%00

:18:

259

00:1

2:55

00:0

9:02

01:0

5:22

01:0

4:42

15%

00:3

8:32

68%

00:2

4:36

13%

00:3

4:01

48%

00:1

7:26

1000

:12:

4500

:09:

4801

:08:

0601

:04:

5512

%00

:37:

1869

%00

:24:

0512

%00

:31:

0145

%00

:18:

02M

edia

00:1

3:03

00:0

9:17

01:0

6:32

01:0

2:58

14%

00:3

9:21

67%

00:2

4:00

12%

00:3

2:02

47%

00:1

7:56

211

9.2

P

rueb

as

a los

AP

Is E

qu

ipo 2

A

PI C

ON

ASP

ECTO

SAC

A-A

P-T

0AC

A-A

P-T

1AC

A-A

P-T

2AC

A-A

P-T

3AC

A-S

I-T4

ACA

-SI-T

5AC

A-R

L-T4

ACA

-RL-

T5

Mue

stra

Tiem

pos

Tiem

pos

Tiem

pos

Tiem

pos

CPU

Tiem

pos

Traf

ico

Tiem

pos

Res

pues

taC

PU

Tiem

pos

Traf

ico

Tiem

pos

Res

pues

ta1

00:1

6:20

00:1

3:10

00:3

0:07

00:3

2:52

25%

00:4

0:12

77%

00:2

5:26

20%

00:2

5:01

50%

00:1

6:28

200

:14:

0900

:11:

1900

:35:

1700

:31:

0831

%00

:35:

2570

%00

:29:

0522

%00

:25:

3255

%00

:17:

253

00:1

4:06

00:1

1:22

00:3

0:49

00:4

0:29

33%

00:3

4:16

78%

00:3

1:02

21%

00:2

5:41

54%

00:1

6:14

400

:14:

3800

:11:

2300

:32:

1200

:32:

1735

%00

:33:

2972

%00

:35:

0120

%00

:26:

5550

%00

:14:

165

00:1

6:57

00:1

3:46

00:3

6:12

00:3

1:29

28%

00:3

5:06

78%

00:2

9:30

19%

00:2

6:57

52%

00:1

7:15

600

:19:

5000

:11:

3900

:31:

3000

:30:

1036

%00

:38:

4778

%00

:30:

0920

%00

:26:

0354

%00

:16:

247

00:1

7:36

00:1

3:01

00:2

9:32

00:3

2:12

31%

00:3

6:56

75%

00:3

0:40

20%

00:2

4:59

49%

00:1

6:35

800

:16:

3100

:13:

1000

:33:

0100

:31:

4032

%00

:31:

0978

%00

:30:

2421

%00

:25:

1250

%00

:16:

509

00:1

6:12

00:1

1:23

00:3

4:34

00:3

4:00

33%

00:3

2:42

79%

00:3

1:26

22%

00:2

5:31

53%

00:1

7:44

1000

:16:

1300

:13:

4000

:35:

5300

:32:

1029

%00

:35:

1372

%00

:26:

2921

%00

:25:

0650

%00

:16:

20M

edia

00:1

6:15

00:1

2:23

00:3

2:55

00:3

2:51

31%

00:3

5:19

76%

00:2

9:55

21%

00:2

5:42

52%

00:1

6:33

API

SIN

AS

PEC

TOS

ASA

-AP

-T0

ASA

-AP

-T1

ASA

-AP

-T2

ASA

-AP

-T3

ASA-

SI-T

4AS

A-S

I-T5

ASA-

RL-

T4AS

A-R

L-T5

Mue

stra

Tiem

pos

Tiem

pos

Tiem

pos

Tiem

pos

CPU

Tiem

pos

Traf

ico

Tiem

pos

Res

pues

taC

PU

Tiem

pos

Traf

ico

Tiem

pos

Res

pues

ta1

00:0

9:05

00:0

3:30

01:1

2:15

00:3

6:04

24%

00:5

8:06

72%

00:3

0:56

18%

00:4

2:05

65%

00:1

8:39

200

:09:

5900

:04:

1100

:40:

0200

:35:

3418

%00

:50:

1586

%00

:35:

5218

%00

:42:

1566

%00

:18:

263

00:0

9:40

00:0

3:27

00:4

2:06

00:3

3:57

26%

00:4

5:36

76%

00:2

9:23

15%

00:4

5:33

65%

00:1

7:21

400

:09:

0200

:04:

0200

:38:

1400

:33:

1230

%00

:54:

2370

%00

:28:

1318

%00

:41:

2162

%00

:15:

215

00:0

9:10

00:0

4:35

00:3

7:27

00:3

2:10

31%

00:5

1:23

75%

00:3

1:20

16%

00:4

1:05

62%

00:1

7:53

600

:09:

0200

:04:

5000

:39:

5900

:33:

2725

%00

:53:

1078

%00

:33:

0219

%00

:41:

2661

%00

:18:

367

00:0

8:50

00:0

4:21

00:3

7:46

00:3

3:07

28%

00:5

1:36

79%

00:3

3:12

17%

00:4

1:56

64%

00:1

7:44

800

:08:

5800

:03:

4600

:37:

5400

:35:

2025

%00

:52:

0181

%00

:33:

5014

%00

:40:

2367

%00

:17:

179

00:0

8:59

00:0

3:58

00:3

6:27

00:3

3:43

30%

00:4

4:16

80%

00:3

3:42

18%

00:4

0:27

65%

00:1

7:00

1000

:08:

3000

:03:

5700

:34:

5500

:32:

3319

%00

:45:

2479

%00

:38:

2019

%00

:40:

5866

%00

:18:

55M

edia

00:0

9:07

00:0

4:04

00:4

1:43

00:3

3:55

26%

00:5

0:37

78%

00:3

2:47

17%

00:4

1:45

64%

00:1

7:43

212

9.3

P

rueb

as

a los

AP

Is e

ntr

e los

nod

os

PRU

EBA

S EN

LO

S N

OD

OS

AP

I CO

N A

SP

EC

TOS

AP

I SIN

AS

PE

CTO

SN

D-T

6A

CA

-ND

-T7

AC

A-N

D-T

7M

uest

raS

g/M

bTi

empo

Tiem

po1

14,2

400

:03:

0100

:02:

032

13,2

700

:02:

0100

:02:

023

13,4

100

:02:

0400

:01:

084

12,9

400

:04:

0400

:02:

015

12,9

400

:02:

0500

:02:

046

13,2

400

:02:

0800

:02:

007

13,2

500

:02:

0300

:01:

098

12,9

400

:02:

0700

:02:

009

12,9

500

:02:

0600

:02:

0010

12,9

400

:02:

0400

:02:

02M

edia

13,2

1200

:02:

2200

:01:

51

213

9.4

A

nálisi

s d

e V

ari

an

za y

Med

ia d

e lo

s re

sult

ad

os

A

P-T

0A

P-T

1A

P-T

2A

P-T

3N

D-T

6N

D-T

7

Tiem

pos

Tiem

pos

Tiem

pos

Tiem

pos

CP

UTi

empo

sTr

afic

oTi

empo

s R

espu

esta

CP

UTi

empo

sTr

afic

oTi

empo

s R

espu

esta

Tiem

po/M

bTi

empo

AC

A1,

4403

5E-0

61,

4403

5E-0

62,

9006

E-0

63,

9767

7E-0

60,

0010

93,

6016

9E-0

60,

0021

1555

64,

3096

2E-0

69,

3333

3E-0

52,

5812

6E-0

70,

0004

6777

84,

3472

6E-0

79,

8071

5E-0

82,

1344

3E-0

7A

SA

8,41

934E

-08

9,45

469E

-08

5,74

821E

-05

8,40

968E

-07

0,00

1982

222

9,27

227E

-06

0,00

1045

556

3,38

455E

-06

0,00

0284

444

1,05

618E

-06

0,00

0401

111

5,39

582E

-07

9,80

715E

-08

6,71

418E

-08

May

or v

alor

va

rianz

a2,

12E

-03

Men

or v

alor

va

rianz

a6,

7141

8E-0

8

AP

-T0

AP

-T1

AP

-T2

AP

-T3

ND

-T6

ND

-T7

Tiem

pos

Tiem

pos

Tiem

pos

Tiem

pos

CP

UTi

empo

sTr

afic

oTi

empo

s R

espu

esta

CP

UTi

empo

sTr

afic

oTi

empo

s R

espu

esta

Tiem

po/M

bTi

empo

AC

A00

:12:

5400

:09:

5800

:42:

5700

:34:

0626

,88%

00:4

2:52

76,9

3%00

:31:

4419

,10%

0:34

:22

58,4

5%0:

17:3

10:

13:2

90:

01:5

8A

SA

00:1

1:42

00:0

7:56

00:4

3:34

00:3

3:58

26,3

8%00

:46:

2975

,60%

00:3

1:57

18,4

3%0:

37:0

059

,95%

0:17

:07

0:13

:29

0:01

:57

AC

A

ME

JOR

A

SA

?FA

LSO

FALS

OV

ER

DA

DE

RO

FALS

OFA

LSO

VE

RD

AD

ER

OFA

LSO

VE

RD

AD

ER

OFA

LSO

VE

RD

AD

ER

OV

ER

DA

DE

RO

FALS

ON

AFA

LSO

Dire

ncia

ab

solu

ta d

e pr

omed

ios

00:0

1:12

00:0

2:02

00:0

0:37

00:0

0:08

0,50

%00

:03:

371,

33%

00:0

0:13

0,67

%0:

02:3

81,

50%

0:00

:24

NA

0:00

:01

VAR

IAN

ZA

PRO

MED

IOS

I-T4

SI-T

5R

L-T4

RL-

T5

SI-T

4S

I-T5

RL-

T4R

L-T5

214

9.5

G

ráfi

cas

de R

esu

ltad

os

de las

pru

eb

as

ACA-

AP-T

0

00:0

0:00

00:0

7:12

00:1

4:24

00:2

1:36

00:2

8:48

12

34

56

78

910

Mue

stra

s

Tiempos

EQ

1E

Q2

ASA-

AP-T

0

00:0

0:00

00:0

1:26

00:0

2:53

00:0

4:19

00:0

5:46

00:0

7:12

00:0

8:38

00:1

0:05

00:1

1:31

00:1

2:58

00:1

4:24

12

34

56

78

910

Mue

stra

s

Tiempos

EQ1

EQ2

ACA-

AP-T

1

00:0

0:00

00:0

7:12

00:1

4:24

00:2

1:36

00:2

8:48

12

34

56

78

910

Mue

stra

s

Tiempos

EQ

1E

Q2

ASA

-AP-

T1

00:0

0:00

00:0

1:26

00:0

2:53

00:0

4:19

00:0

5:46

00:0

7:12

00:0

8:38

00:1

0:05

00:1

1:31

12

34

56

78

910

Mue

stra

s

TiemposEQ

1

E2

215

ACA-

AP-T

2

00:0

0:00

00:1

4:24

00:2

8:48

00:4

3:12

00:5

7:36

01:1

2:00

01:2

6:24

01:4

0:48

01:5

5:12

12

34

56

78

910

Prue

bas

Tiempos

EQ

1E

Q2

ASA-

AS-T

2

00:0

0:00

00:1

4:24

00:2

8:48

00:4

3:12

00:5

7:36

01:1

2:00

01:2

6:24

12

34

56

78

910

Mue

stra

s

Tiempos

EQ1

EQ2

ACA-

AP-T

3

00:0

0:00

00:1

4:24

00:2

8:48

00:4

3:12

00:5

7:36

01:1

2:00

01:2

6:24

01:4

0:48

01:5

5:12

12

34

56

78

910

Mue

stra

s

Tiempos

EQ

1E

Q2

ASA-

AP-T

3

00:0

0:00

00:1

4:24

00:2

8:48

00:4

3:12

00:5

7:36

01:1

2:00

12

34

56

78

910

Mue

stra

s

TiemposE

Q1

E2

216

ACA-

S1-T

4

0%5%10%

15%

20%

25%

30%

35%

40%

12

34

56

78

910

Mue

stra

s

Consumo del CPU

EQ1

EQ2

ASA-

SI-T

4

0%5%10%

15%

20%

25%

30%

35%

12

34

56

78

910

Mue

stra

sConsumo del CPU

EQ1

EQ2

217

ACA-

SI-T

4

00:0

0:00

00:0

7:12

00:1

4:24

00:2

1:36

00:2

8:48

00:3

6:00

00:4

3:12

12

34

56

78

910

Mue

stra

s

Tiempos

EQ1

EQ2

ASA-

SI-T

4

00:0

0:00

00:0

7:12

00:1

4:24

00:2

1:36

00:2

8:48

00:3

6:00

00:4

3:12

00:5

0:24

00:5

7:36

01:0

4:48

12

34

56

78

910

Mue

stra

sTiempos

EQ1

EQ2

218

ASA

-SI-T

5

0%10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

12

34

56

78

910

Mue

stra

s

Trafico

EQ1

EQ2

AC

A-S

I-T5

0%10%

20%

30%

40%

50%

60%

70%

80%

90%

12

34

56

78

910

Mue

stra

s

Trafico

EQ1

EQ2

219

ASA-

SI-T

5

00:0

0:00

00:0

7:12

00:1

4:24

00:2

1:36

00:2

8:48

00:3

6:00

00:4

3:12

12

34

56

78

910

Mue

stra

s

Tiempo Respuesta

EQ1

EQ2

ACA-

SI-T

5

00:0

0:00

00:0

7:12

00:1

4:24

00:2

1:36

00:2

8:48

00:3

6:00

00:4

3:12

12

34

56

78

910

Mue

stra

s

Tiempo Respuestas

EQ1

EQ2

220

AC

A-R

L-T4

0%5%10%

15%

20%

25%

12

34

56

78

910

Mue

stra

s

Consumo del CPU

EQ1

EQ2

ASA

-RL-

T4

0%2%4%6%8%10%

12%

14%

16%

18%

20%

12

34

56

78

910

Mue

stra

s

Consumo del CPU

EQ1

EQ2

Documents

API DE COMUNICACIONES PARA POCKET PC BASADO EN LA