Ilustración 3.5 : Grafico de radar
4. Implementación de TweetAnalyse r
En este capítulo se muestra cómo fue diseñada y desarrollada la herramienta TweetAnalyser. En la primera sección se detalla la arquitectura general del sistema. Seguido a esto, en la siguiente sección se presenta un diagrama UML (Unified Modeling Language) del diseño del sistema. Concretamente, para este caso se utiliza la vista de módulos ya que presenta la funcionalidad de un sistema mediante unidades estáticas que implementan un conjunto de responsabilidades. Esta vista es mostrada mediante un estilo de descomposición en el cual cada diagrama es refinado recursivamente para incluir más y más detalles. Acorde a esto, las subsecciones siguientes detallan el diseño de cada uno de los componentes del sistema. Para describir la interacción que existe entre diferentes objetos del sistema se utilizan diagramas de secuencia.
Por otro lado, es importante mencionar que la implementación de TweetAnalyser fue realizada en NodeJS, utilizando la herramienta SublimeText. El motivo de usar NodeJS se debe principalmente a la familiarización y experiencia con dichas tecnologías, junto con la gran cantidad de bibliotecas existentes que realizan mucho del trabajo básico necesario, permitiendo enfocarse en el objetivo real del proyecto.
4.1 Diseño de la arquitectura
La Ilustración 4.1 corresponde a al diagrama de componentes que conforma nuestro trabajo. Para la arquitectura general se plantea un estilo ClienteServidor, donde la interfaz de visualización cumple el rol de cliente y el motor de consultas analiticas define el servidor. Adicionalmente, se posee un servidor de streaming con el cual el cliente puede comunicarse y configurar para realizar la obtención de publicaciones desde Twitter.
Ilustración 4.1. Diagrama de componentes de la arquitectura implementada
La arquitectura ClienteServidor es una extensión de la programación modular. La programación modular se basa en separar grandes piezas de software en módulos de código para lograr que el programa resultante sea de más fácil desarrollo y mantenimiento. Con esta idea surge un módulo o componente cliente y otro servidor, conectados a través de un comunicador.
El componente servidor satisface los requisitos del cliente ejecutando algún servicio del conjunto de los mismos ofrecidos, por eso se suele decir que el servidor toma una actitud pasiva o de esclavo. En general, estos servicios pueden estar vinculados a un repositorio de datos, o pueden ser más complejos como la ejecución de lógica de negocio. Por otro lado, el componente cliente, conociendo la interface del servidor, puede solicitar peticiones o requerimientos mediante el conector tomando así, el rol de maestro. Usualmente este componente administra la parte de UI (user interface) de la aplicación, validando datos de entrada, y en algunos casos se encargan de la lógica del negocio. A modo general, el cliente se ocupa de la parte de frontend y el servidor se ocupa de la parte backend de la aplicación. Los recursos que el cliente administra generalmente son el monitor, teclado, la CPU de la estación de trabajo y otros periféricos. En cambio, el servidor administra recursos compartidos tales como bases de datos, impresoras, enlaces y tareas con un costo computacional muy elevado.
El modo de interactuar, en general, es el siguiente: cuando el componente cliente, que es el proceso activador, tiene una tarea, le envía un mensaje al
operación indicada para continuar con su ejecución. El servidor tiene que esperar a que le llegue un requerimiento. Cuando llega uno, de alguna manera lo atiende y, transcurrido un tiempo, retorna datos. El conector generalmente es una llamada remota o un envío de mensaje, pero puede variar dependiendo del ambiente.
Este estilo separa las responsabilidades derivando funcionalidad al servidor, lo que simplifica al componente cliente. Ademas, esta separación ayuda a la escalabilidad del sistema, permitiendo que cualquiera de los componentes, o ambos, pueda ir evolucionando independientemente, siempre y cuando no cambie la interfaz entre ellos. La reusabilidad se da cuando un servidor es utilizado por varios clientes, ya que éste le es indistinto atender a un cliente específico o a otro [18]
4.2 Diseño del Sistema
En la Ilustración 4.2 se ilustra mediante un diagrama de paquetes UML, cómo fue organizado TweetAnalyser en diferentes unidades de implementación. En su más alto nivel se encuentra dividido en 4 componentes: En primer lugar, el componente denominado TwitterAnalyticsService, en donde se encuentra la lógica que recopila e interpreta publicaciones compartidas en la red social Twitter. En segundo lugar la Base de datos que permite almacenar de forma persistente la información extraída por la herramienta. Dicha información conforma el conocimiento sobre las publicaciones categorizadas. El tercer componente es el TwitterQueryService que permite a terceros acceder a la información almacenada en la base de datos. Por último, el cuarto componente, la interfaz de usuario. Es una Página web que utiliza dicho servicio web (TwitterQueryService) para obtener información sobre las tendencias temáticas y visualizarlas sobre un conjunto de gráficos.
Ilustración 4.2. Diseño general del sistema
4.3 Recepción y simplificación de publicaciones
Este paquete contiene las clases encargadas de la recepción de publicaciones provenientes de Twitter y la simplificación de las mismas. Por otra parte también incluye la clase que representa a las publicaciones. La red social considerada para la implementación fue Twitter, pero el sistema se encuentra diseñado para agregar la capacidad de recibir flujos de otras redes sociales de manera sencilla. En la Ilustración 4.3 se muestra un diagrama con las clases de esta etapa seguido de una explicación de cada una de ellas.
Ilustracion 4.3. Diagrama de clases del paquete Recepción y simplificación