• No se han encontrado resultados

Descripci´ on de la arquitectura

6. Arquitectura y dise˜ no 61

6.2. Descripci´ on de la arquitectura

A continuaci´on se despliega la arquitectura inicial y la arquitectura final plan- teada por el equipo. La misma se vio modificada debido a que se tuvo que adaptar a dificultades y cambios t´ecnicos, los cuales se describir´an mas adelante.

6.2.1. Propuesta inicial

Para dise˜nar la arquitectura el equipo tuvo en cuenta los diferentes requerimien- tos y los principales atributos de calidad. Por su parte, se tuvieron en cuenta los desaf´ıos previamente mencionados, por lo que al momento de dise˜nar dicha arquitec- tura, se busc´o que sea funcional, eficiente y sencilla, ayudando as´ı a la mantenibilidad a futuro.

Antes de comenzar con el desarrollo de la soluci´on se realizaron diferentes ar- quitecturas tentativas y se validaron con expertos, conocidos por los miembros del equipo, para as´ı conocer sus opiniones y buscar diferentes soluciones. Al comenzar el primer release, el equipo plante´o la siguiente arquitectura:

Figura 6.1: Arquitectura inicial a alto nivel

El diagrama anterior despliega la arquitectura inicial planteada a alto nivel. En la misma se despliegan siguientes m´odulos:

Aplicaci´on web de usuarios: es el sitio web responsive de MJR&Asociados creada para ser utilizada por sus clientes.

Servidor y base de datos: es donde se almacenan los endpoints expuestos por la API y la informaci´on generada para ser consumida por los diferentes sistemas.

Aplicaci´on web de gesti´on: es la plataforma web responsive de gesti´on de MJR&Asociados, creada para ser utilizada por los funcionarios de la inmobi- liaria.

Al adentrarse un poco m´as a bajo nivel en la arquitectura inicial, se puede apreciar que la misma esta dividida en tres principales m´odulos. El frontend de la web de usuarios, el frontend de la plataforma de gesti´on inmobiliaria y por ´ultimo el backend el cual se compone por el servidor y la base de datos. A continuaci´on se presenta un diagrama a m´as a bajo nivel, de componentes y conectores, para poder apreciar como interact´uan el frontend y el backend.

Figura 6.2: Diagrama de componentes y conectores de arquitectura inicial Como se puede apreciar en el diagrama anterior la conexi´on entre las aplicacio- nes de frontend y el backend se dan a trav´es de una API REST para favorecer la portabilidad y eficiencia, lo cu´al se entrar´a en detalle m´as adelante.

El servidor es ´unico tanto para la web de usuarios como para la plataforma de gesti´on inmobiliaria. Esta decisi´on principalmente se tom´o para favorecer la consis- tencia de los datos, ya que ambas plataformas deben acceder a mucha de la infor- maci´on en com´un que provee estaAPI REST que se conecta a la ´unica base de datos.

Por su parte, inicialmente el backend ser´ıa el encargado de comunicarse con las APIs de InfoCasas y con Mercado Libre para poder publicar propiedades en cada una de las plataformas.

En este ´ultimo aspecto fue donde surgieron los principales problemas, al integrar- se con dichos sistemas externos. Por este motivo, el equipo tuvo que tomar decisiones y modificar la arquitectura para poder cumplir con los requerimientos funcionales de poder publicar propiedades en InfoCasas y en Mercado Libre. En la secci´on que se encuentra a continuaci´on se detallan m´as los problemas encontrados, escenarios evaluados y la soluci´on implementada.

6.2.2. Arquitectura final

Cuando el equipo comenz´o con la investigaci´on y el desarrollo de las conexiones con InfoCasas y Mercado Libre, tuvo que afrontar a un gran problema: InfoCasas no prove´ıa unaAPI para que sistemas externos pudieran conectarse con dicha pla- taforma.

Esto gener´o una gran dificultad para el equipo, ya que el poder publicar pro- piedades en InfoCasas a trav´es de la plataforma web, era uno de los requerimientos funcionales pedidos por el cliente. A partir de esto, el mismo se adentr´o en investigar y dise˜nar posibles soluciones a dicha problem´atica.

Luego de varias reuniones de equipo y con el cliente se acord´o crear, adem´as de los sistemas previamente mencionados, una extensi´on para Google Chrome, la cu´al estar´ıa encargada de automatizar el proceso de publicar propiedades en InfoCasas desde la p´agina web de dicha plataforma. M´as adelante en el cap´ıtulo se entra en detalle del funcionamiento de dicha extensi´on.

Por su parte, para poder utilizar la API de Mercado Libre era necesario au- tenticarse mediante OAuth (Open Authorization). Se trata de un protocolo para pasar la autorizaci´on de un servicio a otro sin compartir las credenciales. Por este motivo, al momento de iniciar sesi´on en ercado Libre, no se podr´ıa hacer median- te una llamada a laAPI, sino que se deb´ıa hacer mediante la UI de dicha plataforma.

Por esta raz´on la conexi´on con Mercado Libre se decidi´o implementar desde la plataforma de gesti´on. Al momento de publicar una propiedad en Mercado Libre, previo a publicarse la misma mediante laAPI, se abre la p´agina de autenticaci´on de Mercado Libre, all´ı el usuario de la inmobiliaria debe ingresar sus credenciales, ob- teniendo de esta forma eltoken para poder publicar propiedades en esta plataforma.

Una vez obtenido eltoken, se puede utilizar laAPI de Mercado Libre para poder publicar la propiedad deseada. Como la comunicaci´on mediante dichas plataformas se debe realizar desde la UI, se decidi´o implementar y conectar ambas desde la pla- taforma de gesti´on, evitando enviar informaci´on al backend.

Luego de implementar las soluciones a los problemas previamente descritos, se modific´o la arquitectura, quedando de la siguiente forma:

Figura 6.3: Diagrama de componentes y conectores de arquitectura final Al igual que la propuesta inicial, las aplicaciones de frontend y la del backend se conectan mediante una API REST provistas por el servidor. Sin embargo, en esta soluci´on se implement´o el m´odulo de la extensi´on de Google Chrome. Adem´as, se modific´o la conexi´on con Mercado Libre mediante la plataforma de gesti´on.

Asimismo, las aplicaciones frontend se integran conGoogle Analytics para poder proveer datos en el caso de la web de usuarios, y para consumirlos en el caso de la plataforma de gesti´on. Adem´as de conectarse con la API de Google Maps para poder hacer uso de los mapas en las plataformas.