Creating the Model

Se tienen los siguientes resultados:

1. Sobre la arquitectura propuesta. El experimento muestra como los componentes pueden ser instalados y desinstalados del framework, quien contrala la vida de los bundles. Cada componente afecta el comportamiento de sistema completo, debido a la modelo de capas. Por consecuencia, garantiza la portabilidad, la alta cohesion y el bajo acomplamiento de la funcionalidad del modelo. El desarrollo propuesto

CAP´ITULO 5. CONCLUSIONES

basado en componentes, es una de las tendencias de las arquitecturas de software modernas. Se demostr´o la reusabilidad y la portabilidad que permiten la definici´on de las interfaces de la arquitectura. Este principio permite que el modelo sea implementado cubriendo los requerimientos analizados en esta investigaci´on. Adem´as, permite que pueda ser extendido para las l´ıneas de investigaci´on futuras.

2. Sobre la comunicaci´on con redes de acceso personal. La comunicaci´on con redes personales, permite expander el mercado y disminuir los costos de la tecnolog´ıa. El experimento demuestra que es viable la comunicaci´on con uno de los protocolos m´as importantes del momento, como lo es Bluetooth. Se integraron los mecanismos para la conexi´on con los dispositivos basados en los protocolos del est´andar de red. Se utiliz´o el descubrimiento del dispositivo y el servicio de perfil de puerto serial(SPP). Se demostr´o la operaci´on del driver de red y se integraron los conceptos de device, service y sessi´on para el reconocimiento de los usuarios m´oviles en el ambiente.

3. Sobre la intereoperabilidad con diferentes protocolos de comunicaci´on. Analizando la importancia de integrar diferentes protocolos, se demostr´o la interoperabilidad lograda por el modelo propuesto. Se estable un broker de comunicaci´on basado en un puerto de comunicaci´on. Este puerto de comunicaci´on recibe e envia de una manera gen´erica mediante mensajes establecidos en un protocolo. La implementaci´on del broker, se basa en el patr´on bridge, el cual permite que la interfaz pueda ser implementada bajo otra tecnolog´ıa como web services, xlm, Corba, etc. O bien, interoperar con otro protocolo como Wifi o zigbee, siempre y cuando utilice el puerto de comunicaci´on definido en el modelo.

4. Sobre la integraci´on de los sevicios. La integraci´on de los servicios fue una propuesta basada en la especifici´on para UPnp. Se realizaron experimentos que demostraron que la estructura de servicios propuesta en UPnp, era una estrategia interesante que pod´ıa adaptarse al modelo mediante un administrdor de servicios que controle los clientes de manera organizada.

5. Sobre los aspectos distintivos los ambientes m´oviles. Debido a la movilidad y al dinamismo de los usuarios m´oviles, se propuso

CAP´ITULO 5. CONCLUSIONES

un esquema de administraci´on del contexto. Este coopera con el administrador de servicios para resolverlos de manera din´amica, dependiendo de la evaluaci´on de las reglas de contexto. En este sentido, el experimento demuestra la adaptaci´on al contexto de manera b´asica, pero puede resultar tan compleja como se desee a trav´es de la implementaci´on amplia y diversa de las reglas del contexto. Esto es totalmente soportado mediante la estructura abtracta para las reglas de contexto.

5.3.1.

An´alisis del N´umero de Interfaces

El modelo propuesto es dise˜nado tomando como base primordial la reducci´on de interfaces de integraci´on. En la secci´on 3.2.1, se analiz´o la complejidad de integrar un middleware dentro de una arquitectura basada en diferentes protocolos de comunicaci´on. Uno de los resultados m´as importantes, es que el costo de la interfaz con diferentes protocolos se reduce a 1, debido al broker de comunicaci´on establecido. De esta manera, ecordando la ecuaci´on 5.3.1, se tiene

O(n) = (α(n) +β(n) +γ(n))θ(n) (5.1)

donde θ(n), representa el costo de las interfaces y es un factor de la complejidad del middleware. Por lo tanto, si los desarrolladores y los diferentes proveedores pueden utilzar este middleware para k dispositivos, la complejidad de integraci´on de aplicaciones se reduce a m. Adem´as, considerando que el mecanismo puede ser el mismo para todas las interfaces, entonces m tambi´en puede disminuirse a 1. Aunque es importante aclarar, que esta reducci´on de integraci´on aumenta al complejidad de abstraci´on del modelo, por lo que se debe de lograr un equilibrio para este factor.

5.3.2.

An´alisis Comparativo de los Resultados

Finalmente, como resultados del modelo propuesto, se realiza el cuadro comparativo 5.2, basado en las diferentes propuestas de arquitecturas dom´oticas que existen en area de investigaci´on en diferentes universidades

CAP´ITULO 5. CONCLUSIONES

Caracter´ıstica Modelo SOA eCasa Matilda’s Propuesto Framework [38] [8] House [21] Interoperabilidad Aplica No considerada No cnsiderada Aplica

Integraci´on de Aplica Aplica Aplica Aplica

Servicios

Adaptaci´on Aplica Aplica Aplica No Aplica

al Contexto

Estandarizaci´on Aplica No considerado No considerado Aplica Basado en Aplica No considerado No considerado Aplica OSGi

Cuadro 5.2: An´alisis Comparativo del Modelo Propuesto con las Arquitec- turas Analizadas

comparada con la que se propone en esta tesis.

Las arquitecturas son representantivas de las investigaciones actuales sobre redes dom´oticas analizadas en las secci´on 3.3. El cuadro 5.2, muestra que no existe un modelo que integre todos los aspectos que se definieron en esta propuesta de tesis. Obs´ervese que las otras arquitectura solo cubren parte de requerimientos para integraci´on de ambientes m´oviles. Esta conclusi´on representa la aportaci´on final de esta tesis. Es decir, esta propuesta, detecta e integra los requerimientos completos de los ambientes m´oviles para proponer el modelo de referencia. Sin embargo, como toda investigaci´on, a´un hay trabajo futuro por resolver.