Embed Size (px)
Citation preview
Diseño de una arquitectura de software para el análisis de sentimientos aplicado a las opiniones
de usuarios en Twitter sobre los servicios ofrecidos en el sistema de salud en Colombia.
Juan Carlos Chaparro Cruz, [email protected]
Joan Andrés Romero Loaiza, [email protected]
Tesis de Maestría presentada para optar al título de Magíster en Ingeniería de Software
Asesor: Iván Mauricio Cabezas Troyano, Doctor (PhD) en Ingeniería con énfasis en ciencias de
la computación
Universidad de San Buenaventura Colombia
Facultad de Ingeniería
Maestría en Ingeniería de Software
Santiago de Cali, Colombia
2018
2
Citar/How to cite [1]
Referencia/Reference
Estilo/Style:
IEEE (2014)
[1] J. C. Chaparro Cruz, J. A. Romero Loaiza, “Diseño de una arquitectura de
software para el análisis de sentimientos aplicado a las opiniones de usuarios en
Twitter sobre los servicios ofrecidos en el sistema de salud en Colombia.”,
Tesis Maestría en Ingeniería de Software, Universidad de San Buenaventura
Cali, Facultad de Ingeniería, 2018.
Maestría en Ingeniería de Software, Cohorte V.
Laboratorio de Investigación para el Desarrollo de la Ingeniería de Software (LIDIS).
Bibliotecas Universidad de San Buenaventura
• Biblioteca Fray Alberto Montealegre OFM - Bogotá.
• Biblioteca Fray Arturo Calle Restrepo OFM - Medellín, Bello, Armenia, Ibagué.
• Departamento de Biblioteca - Cali.
• Biblioteca Central Fray Antonio de Marchena – Cartagena.
Universidad de San Buenaventura Colombia
Universidad de San Buenaventura Colombia - http://www.usb.edu.co/
Bogotá - http://www.usbbog.edu.co
Medellín - http://www.usbmed.edu.co
Cali - http://www.usbcali.edu.co
Cartagena - http://www.usbctg.edu.co
Editorial Bonaventuriana - http://www.editorialbonaventuriana.usb.edu.co/
Revistas - http://revistas.usb.edu.co/
Biblioteca Digital (Repositorio)
http://bibliotecadigital.usb.edu.co
3
Dedicatoria
Dedico este proyecto de Tesis a todos los que en silencio luchan por sus sueños.
Juan Carlos Chaparro.
A todas las personas que de una u otra manera aportaron en la realización de este sueño.
Joan Andrés Romero Loaiza.
Agradecimientos
Agradecemos a todas las personas involucradas en la realización de este proyecto de Tesis para
la obtención de nuestro título como Magister en Ingeniería de Software.
Profesor Iván Mauricio Cabezas
Profesor Fernando Barraza
Profesor Hugo Erazo
Profesor Jose Luis Jurado
Profesor Johan Bejarano
Profesora Rocio Segovia
Profesor Diego Gomez
4
Resumen
Una necesidad actual es la de poder entender cómo la inteligencia artificial se involucra en las
actividades humanas del día a día, proveer capacidades de comunicación e interacción a los
sistemas de cómputo, en donde las formas de establecer ese contacto humano-computador dejen
de ser cada vez menos los medios tradicionales como lo son el teclado y el mouse y pasen ahora
a ser medios audiovisuales y lingüísticos que permitan una comunicación "natural" con los
sistemas del futuro. Una de las ramas de la inteligencia que más nos hace pensar en este avance
tecnológico es la de Análisis de Sentimientos. En este proyecto se aborda el diseño de una
arquitectura de software que permita el procesamiento de un lenguaje formal escrito. Se investiga
la forma de cómo el diseño de una arquitectura de software podrá "analizar" un texto desde una
fuente de datos dada, separarla en sus componentes lingüísticos, para luego organizar y
categorizar según lo que el mismo lenguaje plantea como algo positivo, negativo o neutral. A
través de las técnicas del Análisis de Sentimientos se busca encontrar esta categorización en
textos que como fuente de datos para este proyecto será la red social Twitter.
Para este proyecto se elige hacer Análisis de Sentimientos dentro del contexto del servicio de
salud obligatorio en Colombia, se aplicaron las técnicas computacionales establecidas para lograr
los objetivos a través de la ingeniería de software que al final permitieron plantear una
arquitectura de software.
5
Contenido
Dedicatoria 3
Agradecimientos 3
Resumen 4
Contenido 5
1. Introducción 7
1.1 Pregunta De Investigación 7
1.2 Planteamiento Del Problema 8
1.3 Propuesta De Solución 8
1.4 Justificación 9
1.5 Objetivos 10
1.5.1 Objetivo General 10
1.5.2 Objetivos Específicos 10
2. Marco Teórico 11
2.1 Arquitectura De Software 11
2.1.1 Estilo Arquitectónico 11
2.1.2 Atributos De Calidad Para Una Arquitectura De Software 12
2.1.3 Atributos De Calidad Por Estilo Arquitectónico 14
2.1.4 Patrones De Arquitectura De Software 14
2.1.5 Taller De Atributos De Calidad - QAW 15
2.1.6 Método De Análisis De Intercambio De Arquitectura - ATAM 17
2.2 Análisis De Sentimientos 20
2.2.1 Conceptualización 20
2.2.2 Preprocesamiento De Textos 24
2.2.2.1 Extracción 24
2.2.2.2 Eiminación De Palabras Vacias (Stop Words) 24
2.2.2.3 Identificación De La Raíz De Una Palabra (Stemming) 24
2.2.3 Clasificación De Textos 25
2.2.3.1 Técnica De Naive Bayes 25
2.2.3.2 Técnica De Máxima Entropía 25
6
2.2.3.3 Técnica De Support Vector Machine 26
2.2.3.4 Técnica De Árboles De Decisión 26
2.2.4 Natural Language Toolkit 27
2.2.5 Evaluación de Clasificadores 28
2.2.5.1 Matriz de Confusión 28
2.2.5.2 Precisión 29
2.2.5.3 Recall 29
2.2.5.4 Medida F 30
3. Proceso de Ingeniería 31
3.1 Exploración Y Selección 31
3.1.1 Selección De Estilo Arquitectónico 31
3.2 Construcción 36
3.2.1 Diseño De Arquitectura De Software Para El Análisis De Sentimientos 36
3.2.2 Selección Del Conjunto De Entrenamiento 38
3.2.3 Evaluación Y Selección Del Clasificador 43
3.2.4 Prototipo Funcional 50
3.3 Evaluación 57
3.3.1 Evaluación de la Arquitectura 57
3.3.2 ATAM Definición de Fases 58
3.3.3 Resultados Metodología ATAM 58
3.3.3.1 Conjunto de Escenarios Priorizados y Preguntas Asociadas 59
3.3.3.2 Árbol de Utilidad 60
4. Observaciones Finales y Recomendaciones 61
4.1 Conclusiones 61
4.2 Trabajos Futuros 62
5. Bibliografía 63
7
1. Introducción
El objetivo de esta investigación es plantear una arquitectura de software que permita hacer
análisis de sentimientos, para clasificar las opiniones y comentarios de usuarios entre negativos,
positivos y neutrales cuando estos están dentro de las categorías que los relacionan con algún
tema del servicio de salud en Colombia. La fuente de donde se escogen estas opiniones, es decir
la fuente de los datos, es la red social Twitter, esta red social es un sistema que permite compartir
ideas, opiniones, comentarios en no más de 140 caracteres. Esta red social está ampliamente
difundida a nivel internacional y es famosa por su sencillez y facilidad de uso.
Los comentarios escritos por los usuarios en esta red social se buscarán por categorías que dentro
del contexto de Twitter son llamados Hashtags, estos son una frase o palabra sin espacios
precedida por el símbolo "#", usada especialmente en redes sociales para identificar mensajes de
un tema en particular.
Ejemplos de Hashtag que categorizan el tema de salud en Colombia:
#poscolombia
#saludcolombia
#saludencolombia
#epscolombia
#ley100
#eps
#ips
Se plantea una solución arquitectural desde la Ingeniería de Software para obtener y organizar
conceptos, tecnologías, metodologías de trabajo, todo bajo un esquema de desarrollo ágil que
permita crear un prototipo funcional y que podrá hacer ver y entender cómo y cuáles
mecanismos del análisis de sentimientos se pueden usar para clasificar desde las opiniones de
los Colombianos uno de los temas más complejos en una economía en desarrollo como lo es la
Colombiana y su servicio obligatorio de salud.
1.1 Pregunta De Investigación
¿Cúal es el diseño de una arquitectura de software que soporte el análisis de sentimientos para el
procesamiento y categorización de las opiniones de usuarios de la red social Twitter con respecto
a los servicios ofrecidos por el sistema de salud en Colombia?
8
1.2 Planteamiento Del Problema
El problema que se encuentra es que no se ha definido una arquitectura de software que permita
hacer la clasificación entre positiva, negativa y neutral de los datos extraídos de la red social
Twitter.
Con todos los datos que se puede obtener de manera libre desde Internet, donde se plasman
opiniones de muchos Colombianos con respecto al tema de como es el servicio de salud en
Colombia, no hay un estudio que permita hacer esta clasificación como lo plantea el análisis de
sentimientos y las entidades prestadoras del servicio en salud, el gobierno y los ciudadanos están
separados los unos de los otros sin conocer o entender cuáles son esas opiniones y cómo estas
afectan de manera positiva o negativa la prestación del servicio.
1.3 Propuesta De Solución
El desarrollo de este trabajo de ingeniería es el diseño y prototipado de un sistema basado en esta
arquitectura de software, para extraer opiniones y comentarios de usuarios de la red social
Twitter y se procesen usando análisis de sentimientos, esta información podrá ser categorizada
según el idioma base escogido el cual es el Español, se podrán conocer si estos son positivos,
negativos o simplemente neutrales que no apuntan a ningún extremo en particular (tal como se
ilustra en la Figura 1.1).
Figura 1.1. Opiniones de usuarios en redes sociales fuera del alcance de las entidades prestadoras del servicio de salud y de las
entidades de control gubernamentales.
9
Propuesta de solución:
● Diseñar una arquitectura de software que soporte el análisis de sentimientos con los datos
de la red social Twitter.
● Hacer minería de textos con los datos de la red social Twitter basados en los hashtags con
los que se categorizan los mensajes de los usuarios.
● Definir como punto de evaluación el tema de la prestación del servicio de salud en
Colombia.
1.4 Justificación
Una arquitectura de software dentro del marco de la ingeniería de software actualmente es el
insumo primordial como base de un sistema que está orientado a la automatización de algún
proceso en general.
El planteamiento de la arquitectura de software para hacer análisis de sentimientos se validará
con un prototipo funcional, que se construirá usando la biblioteca de funciones para
procesamiento de textos llamada NLTK del lenguaje de programación Python.
Con el prototipo funcional basado en la arquitectura de software planteada se tiene una
oportunidad para interconectar usuarios digitales y entidades de salud en Colombia, y presenciar
el poder de los sistemas no convencionales en favor del mejoramiento continuo y fortalecimiento
de las instituciones de salud en Colombia. Su importancia radicará en que se mantengan todos
los procesos y mecanismos de las opiniones positivas y se trabaje en mejorar y estabilizar las
opiniones marcadas como negativas.
10
1.5 Objetivos
A continuación, se plantean los objetivos generales y específicos asociados a esta investigación.
1.5.1 Objetivo General
Diseñar una arquitectura de software para soportar análisis de sentimientos de opiniones de
usuarios en la red social Twitter sobre el tema del servicio de salud en Colombia.
1.5.2 Objetivos Específicos
● Seleccionar el modelo de arquitectura de software adecuado que se ajuste a las
necesidades para el análisis de sentimientos para opiniones en español de los usuarios de
la red social Twitter.
● Diseñar y construir el prototipo de los componentes necesarios para realizar análisis de
sentimientos de opiniones de usuarios en español obtenidos en la red social Twitter.
● Realizar un proceso de experimentación para validar los componentes diseñados para el
análisis de sentimientos.
● Aplicar un método de evaluación de arquitecturas de software para validar cada uno de
los atributos del diseño propuesto.
11
2. Marco Teórico
En este capítulo se definen los conceptos básicos que permiten entender el desarrollo del proceso
de ingeniería que se presentan en la sección 3. Se tendrán en cuenta los conceptos teóricos de
arquitecturas de software, análisis de sentimientos y técnicas de evaluación de resultados.
2.1 Arquitectura De Software
Para la ingeniería de sistemas, una arquitectura es la infraestructura de software dentro de la cual
cada componente de la aplicación proporcionada al usuario puede ser especificada, desplegada y
ejecutada [22].
Los componentes o bloques de construcción que conforman las partes de un sistema de software
se definen en tres tipos, estos son:
● Elementos de datos: Contienen la información que será transformada.
● Elementos de proceso: Transforman los elementos de datos.
● Elementos de conexión: Llamados también conectores, que bien pueden ser elementos
de datos o de proceso, y mantienen unidas las diferentes piezas de la arquitectura.
Una relación es la conexión entre los componentes. Puede definirse también como una
abstracción de la forma en que los componentes interactúan en el sistema a través de los
elementos de conexión. Es importante reconocer que una relación se concreta mediante los
conectores [4].
2.1.1 Estilo Arquitectónico
Un estilo arquitectónico es un conjunto de reglas que dan los lineamientos para construir un
sistema. Estos indican cómo se organizan los componentes, como son manipulados los datos, y
cómo se comunican los componentes entre ellos.
Están condicionados por un principio en particular tales como proceso secuencial de datos,
jerarquía de componentes, entre otros. Cada arquitectura tiene un impacto positivo y negativo
sobre unos atributos de calidad, dando ventajas y desventajas unas sobre otras [14].
Algunos estilos de arquitectura son [4]:
12
● Datos Centralizados: Clientes acceden a datos compartidos en un repositorio de manera
frecuente.
● Flujo De Datos: Transformaciones sobre piezas sucesivas de datos de entrada. El dato
entra al sistema y fluye entre los componentes hasta llegar a su destino final (salida o
repositorio).
● Máquinas Virtuales: Simulan funcionalidad que no es nativa en la plataforma que está
implementado.
● Llamada Y Retorno: Programa principal que tiene el control del sistema y varios
subprogramas se comunican con él a través de llamados.
● Componentes Independientes: Procesos u objetos independientes que se comunican a
través de mensajes.
● Orientación A Servicios: Componentes que pueden ser invocados y cuya descripción de
interfaz puede ser publicada y descubierta.
2.1.2 Atributos De Calidad Para Una Arquitectura De Software
La calidad del software se define como el grado en el cual un software posee una combinación
adecuada de atributos. Los atributos de calidad son requisitos adicionales del sistema, los cuales
son características que debe tener el sistema, pero no son considerados como requisitos
funcionales [4].
Se establecen en dos grupos:
● Los observables vía ejecución se pueden ver en la Tabla 2.1: determinan el
comportamiento en tiempo de ejecución.
● No observables vía ejecución, listados en la Tabla 2.2: se establecen durante el desarrollo
del sistema.
13
Tabla 2.1
Atributos de calidad observables vía ejecución
Atributo Descripción
Disponibilidad Disponibilidad para el uso
Confidencialidad Ausencia de acceso no autorizado a la información
Funcionalidad Realizar el trabajo para el cual fue desarrollado
Desempeño Cumplir con sus funciones dentro de restricciones de
velocidad, exactitud, entre otras
Confiabilidad Mantenerse operativo a lo largo del tiempo
Seguridad Servir a usuarios legítimos. Restringir los accesos no
autorizados mediante negación del servicio
Tabla 2.2
Atributos de calidad no observables vía ejecución
Atributo Descripción
Configurabilidad Poder realizar ciertos cambios al sistema
Integrabilidad Trabajar correctamente componentes que fueron desarrollados
por separado al integrarlos
Integridad Ausencia de alteraciones inapropiadas de la información
Interoperabilidad Habilidad para trabajar con otros sistemas
Modificabilidad Poder realizar cambios futuros al sistema
Mantenibilidad Capacidad para hacer reparaciones y evoluciones
Portabilidad Poder ser ejecutado en diferentes ambientes
Reusabilidad Componentes puedan ser usados en otros sistemas
Escalabilidad Poder ampliar el diseño arquitectónico, datos o procedimental
Prueba Facilidad para mostrar fallas ante un conjunto de pruebas
14
2.1.3 Atributos De Calidad Por Estilo Arquitectónico
Cada uno de los estilos arquitectónicos está directamente relacionado con uno o varios atributos
de calidad, que, al aplicar el estilo, pueden llegar a ser abordados de manera adecuada. A
continuación, en la Tabla 2.3 se hace un resumen de los atributos de calidad por estilo:
Tabla 2.3
Resumen de atributos de calidad por estilo arquitectónico
Estilo Atributos De Calidad
Datos Centralizados Integrabilidad, escalabilidad, modificabilidad
Flujo de Datos Reusabilidad, modificabilidad, mantenibilidad
Máquinas Virtuales Portabilidad
Llamada y Retorno Modificabilidad, escalabilidad, desempeño
Componentes Independientes Modificabilidad, escalabilidad
Orientación a Servicios Interoperabilidad, desempeño, seguridad, confiabilidad,
disponibilidad, modificabilidad, pruebas, usabilidad,
escalabilidad
2.1.4 Patrones De Arquitectura De Software
Los patrones de una arquitectura de software guían a los desarrolladores en como diseñar los
componentes y además definen como estos componentes deben interactuar [20].
Dentro de los patrones de arquitectura más comúnmente usados y difundidos se encuentran los
siguientes:
● Arquitectura En Capas: Las capas organizadas de forma horizontal, donde cada capa
posee un rol definido dentro de la aplicación (Presentación, Lógica y/o Lógica de
Negocio, Persistencia). Se puede hablar de capas abiertas o cerradas para permitir una
comunicación abierta y detallada por restricciones.
● Arquitectura Conducida Por Eventos: La arquitectura conducida o manejada por
eventos es una arquitectura distribuida y asíncrona para producir aplicaciones altamente
escalables. Esta arquitectura es desacoplada con un propósito definido en sus
componentes que reciben y procesan los eventos asíncronamente. Consiste en dos tipos
de topologias, el mediador (mediator) y el corredor (broker).
15
● Arquitectura Microkernel: Se puede entender como dos tipos de componentes de
arquitectura de software: Un Core del sistema y Módulos específicos (plug-ins). El Core
del sistema contiene solo la mínima funcionalidad para hacer el sistema operacional. Los
módulos son podrían trabajar independientes o en consorcio con otros, teniendo en cuenta
que esta práctica estaría generando dependencia. Este patrón de arquitectura podría ser
usado como parte de otras arquitecturas o embebido dentro de estas mismas.
● Arquitectura Microservicios: Cada componente de la arquitectura micro servicios
funciona como una unidad separada. Este patrón aumenta la escalabilidad y
desacoplamiento. Se piensa como servicios de componentes, envés de servicios dentro de
una arquitectura de micro servicios. Los servicios de componentes podrían contener uno
ó más módulos que representan una única funcionalidad o una porción independiente del
negocio de la aplicación. En su correcto nivel de diseño granulado está el mayor de los
retos para este patrón de arquitectura. Los componentes son accedidos a través de alguno
de los protocolos de acceso remotos (JMS, AMQP, REST, SOAP, RMI, entre otros).
● Arquitectura Basada En Espacio: También conocido como el patrón de arquitectura
cloud (nube), minimiza los factores que limitan el escalamiento de una aplicación. La
información de la aplicación es mantenida en memoria y replicada en todas las unidades
de procesamiento activas. De esta manera las unidades pueden incrementar o disminuir
de acuerdo con la cantidad de peticiones que se hacen el tiempo. Se manejan
principalmente dos componentes, la unidad de procesamiento y el middleware
virtualizado. La unidad de procesamiento se encarga de replicar la data de las
aplicaciones y el middleware se encarga de la comunicación entre ellas. En el middleware
también existen 4 componentes: La grilla de mensajes, la grilla de datos, la grilla de
procesamiento y administrador de despliegue.
2.1.5 Taller De Atributos De Calidad - QAW
Se definirá QAW como referencia de Quality Attribute Workshop, que significa
Taller/Metodología de Atributos de Calidad. Es una metodología que permite a los interesados
del proyecto determinar los atributos de calidad de un sistema [1].
Es de vital importancia tener claro todos los requisitos de un sistema desde las etapas iniciales
del desarrollo. Teniendo claros estos requisitos, puede determinarse de manera adecuada los
atributos de calidad del sistema. Todos los interesados en el proyecto deben dar su punto de vista
y determinar en conjunto cada uno de los detalles del sistema.
La metodología del QAW se centra en el sistema y es enfocado hacia los interesados, los cuales
pueden expresar sus necesidades y expectativas con atributos de calidad de su interés. Todo esto
se desarrolla en etapas previas al desarrollo de la arquitectura para describir de una manera clara
16
los atributos de calidad que son importantes y las responsabilidades de cada uno de ellos se
utilizan escenarios, que son historias de interacción del sistema.
El QAW se compone de los siguientes pasos:
1. Presentación E Introducción: Se describe la motivación del QAW y se explica cada
paso del método. Se hace una introducción a cada uno de los interesados.
2. Presentación Del Negocio/Misión: Uno de los interesados hace la presentación del
contexto del negocio, la misión del sistema y de los requisitos funcionales de alto nivel,
restricciones y requisitos de los atributos de calidad.
3. Presentación Del Plan De Arquitectura: De los involucrados, el encargado de la parte
técnica explica los planes y estrategias que se tienen para cumplir con los requisitos del
negocio, requisitos técnicos y restricciones. Y en caso de que existan diagramas de
contexto, diagramas de sistemas de alto nivel y otras descripciones que se encuentren
escritas.
4. Identificación De Controladores De Arquitectura: Dada la información de los pasos
anteriores, se obtiene una lista en consenso de los controladores de arquitectura tales
como requisitos de alto nivel, controladores del negocio, restricciones y los atributos de
calidad.
5. Lluvia De Escenarios: Los involucrados realizan escenarios en los cuales se plantean sus
perspectivas del sistema. Es recomendable que cada uno de ellos contribuya al menos con
dos escenarios. Se debe asegurar que cada uno de los escenarios represente un
controlador arquitectural y que cada uno de estos tengan al menos un escenario
representando.
6. Consolidación De Escenarios: Entre los involucrados se deben revisar todos los
escenarios e identificar todos aquellos que sean similares en contenido. Estos escenarios
deben ser combinados dejando solo uno, todo con la aprobación de los interesados que
escribieron estos escenarios.
7. Priorización De Escenarios: Se asigna un número de votos a cada involucrado
correspondiente al 30% del total de escenarios después de la consolidación. Los
interesados dan sus votos a los escenarios, los cuales son contados y su resultado dará el
orden de priorización.
17
8. Refinamiento De Escenarios: Los primeros cuatro o cinco escenarios después de la
priorización, son refinados con un detalle más profundo. En este se describe el
requerimiento que afecta, el atributo de calidad asociado y se detalla posibles problemas
que puedan presentarse.
El QAW permite reunir una gran cantidad de interesados que pueden llegar a clarificar aspectos
y contradicciones sobre los requisitos del sistema. También clarifica los atributos de calidad, se
genera una mejor documentación arquitectónica y da un soporte para el análisis y pruebas
durante la vida útil del sistema.
2.1.6 Método De Análisis De Intercambio De Arquitectura - ATAM
ATAM es la técnica para analizar arquitecturas de software. Esta técnica ayuda a verificar que
una arquitectura satisface los objetivos de calidad planteados y también da una idea de cómo
estos objetivos interactúan entre sí [12]. Esas decisiones de diseño son críticas, tienen
consecuencias más trascendentales y son difíciles de cambiar después de que se haya
implementado un sistema.
Al evaluar una arquitectura con ATAM, el objetivo es comprender las consecuencias de las
decisiones arquitectónicas con respecto a los requisitos de los atributos de calidad del sistema.
Un sistema está motivado por un conjunto de objetivos funcionales y de calidad. ATAM es un
medio para determinar si estos objetivos son alcanzables por la arquitectura tal como se concibió
antes de hacer una inversión de recursos.
El propósito de ATAM es evaluar las consecuencias de las decisiones arquitecturales con base en
los requisitos de atributos de calidad. El ATAM está destinado a ser un método de identificación
de riesgos, un medio para detectar áreas de riesgo potencial dentro de la arquitectura de un
sistema de software complejo. Esto tiene muchas implicaciones:
● El ATAM puede ser realizado en etapas tempranas del ciclo de vida de desarrollo.
● Puede hacerse en forma relativamente económica y rápida
● Producirá análisis proporcionales al nivel de detalle de la especificación de la
arquitectura. Además, no necesita producir análisis detallados de ningún atributo de
calidad medible de un sistema para tener éxito. En cambio, el éxito es logrado mediante
la identificación de tendencias.
En particular, se quieren encontrar decisiones claves que presenten riesgos para cumplir los
requisitos de calidad y decisiones clave que todavía no han sido tomadas. Finalmente, ATAM
ayuda a la organización a desarrollar una serie de análisis, fundamentos y directrices para la toma
de decisiones sobre la arquitectura.
18
El proceso de ATAM consiste en nueve pasos. A pesar de que los pasos están enumerados,
sugiriendo linealidad, este no es un proceso que deba ser estrictamente en cascada. La
importancia de esos pasos es delinear claramente las actividades del ATAM junto con los
resultados de estas actividades. Los pasos son los siguientes:
1. Presentación Del ATAM: se explica el proceso que cada uno de los involucrados
seguirá, permitiendo resolver preguntas y establecer el contexto y expectativas para las
actividades. Esta describe brevemente los pasos, las técnicas que serán usadas para
elicitación y análisis y las salidas de la evaluación.
2. Presentación De Controladores De Negocio: el gerente de proyecto presenta una visión
general del sistema desde una perspectiva empresarial. Debe describir los requisitos más
importantes, restricciones (técnicas, administrativas, económicas o políticas), objetivos y
contexto, principales interesados y los controladores de arquitectura.
3. Presentación De La Arquitectura: será presentada por el arquitecto líder o equipo de
arquitectura en el nivel de detalle apropiado. Es un paso importante ya que la cantidad de
información disponible y documentada afectará directamente el análisis que es posible y
su calidad. Se deben cubrir restricciones técnicas, interacción con otros sistemas y
enfoques arquitecturales usados para cumplir los atributos de calidad.
4. Identificar Enfoques Arquitectónicos: son identificados los enfoques y estilos
arquitectónicos por el equipo de análisis, más no son analizados. Estos representan los
medios de la arquitectura para abordar los atributos de calidad de mayor prioridad.
También definen las estructuras importantes del sistema y la forma en que éste puede
crecer, responder a cambios, resistir ataques, integrarse con otros sistemas, entre otros.
5. Generar Árbol De Utilidad De Atributos De Calidad: el equipo de evaluación trabaja
con el equipo de arquitectura, el gerente y los representantes del cliente para identificar,
priorizar y refinar los objetivos de calidad más importantes del sistema. El resultado del
proceso de generación del árbol de utilidades es una priorización de requisitos de
atributos de calidad específicos, realizados como escenarios.
6. Analizar Enfoques Arquitectónicos: una vez el alcance de la evaluación ha sido
definido mediante el árbol de utilidad, el equipo de evaluación puede explorar los
enfoques arquitectónicos que realizan los atributos de calidad importantes. Esto se hace
con el objetivo de documentar aquellas decisiones arquitecturales e identificar sus
riesgos, puntos sensibles y compensaciones.
19
7. Lluvia De Ideas Y Priorización De Escenarios: generar un conjunto de escenarios
facilita la tarea de la lluvia de ideas. Los escenarios son ejemplos de estímulos
arquitectónicos para representar el interés de los interesados y entender los requisitos de
atributos de calidad. Hay dos tipos de escenarios, los de caso de uso donde el interesado
es un usuario final que utiliza el sistema para ejecutar alguna función, y los escenarios de
cambios representan cambios en el sistema (escenarios de crecimiento y de exploración).
Una vez obtenidos los escenarios, deben ser priorizados mediante votación, asignando a
cada involucrado un número de votos igual al 30% del total de escenarios.
8. Analizar Enfoques Arquitectónicos: después de recopilados y analizados los
escenarios, el arquitecto comienza el mapeo de los escenarios mejor clasificados en las
descripciones arquitectónicas que se hayan presentado. Asumiendo que en el paso
anterior no se produjo ningún escenario prioritario que no estuviera cubierto por análisis
previos, ésta es una actividad de prueba: se espera y se supone descubrir poca
información nueva.
9. Presentación De Resultados: se presenta toda la información recogida durante el
proceso. Se incluye el contexto del negocio, requisitos de conducción, restricciones y la
arquitectura. Lo más importante, sin embargo, es el conjunto de salidas de ATAM: los
enfoques y estilos arquitecturales documentados, el conjunto de escenarios y su
priorización, el conjunto de preguntas basadas en atributos, el árbol de utilidad, los
riesgos descubiertos, los no riesgos documentados, los puntos de sensibilidad y los puntos
de intercambio encontrados.
Estos pasos son generalmente agrupados en dos fases. La primera fase es centrada en la
arquitectura y se concentra en elicitar información arquitectural y analizarla. La segunda fase es
centrada en los involucrados y se concentra en elicitar sus puntos de vista y verificar los
resultados de la primera fase.
20
2.2 Análisis De Sentimientos
2.2.1 Conceptualización
El análisis de sentimientos es una técnica computacional que permite categorizar información
válida desde fuentes textuales, basándose en el procesamiento del lenguaje natural [18].
En la Figura 2.1 se ejemplifica proceso de análisis de sentimientos. En una primera etapa se tiene
la recolección de datos que en este caso de estudio corresponde a redes sociales de uso público.
Posteriormente se realiza el procesamiento de dicha información para finalmente obtener su
categorización y poder mostrar a través de la organización de los datos cuál es el sentimiento
asociado a los textos revisados.
Figura 2.1. Análisis de sentimientos basado en las redes sociales
La clasificación asociada que se encuentra mediante procesamiento computacional se puede
resumir en tres categorías:
● Positivo
● Negativo
● Neutral
Las siguientes imágenes son un ejemplo claro de clasificación de los datos entre positivo,
negativo y neutral, encontrados en la red social Twitter por medio del hashtag "#saludcolombia".
21
Figura 2.2. Dato categorizado como positivo.
Figura 2.3. Dato categorizado como negativo.
22
Figura 2.4. Dato categorizado como neutral.
Explotar información subjetiva es de gran importancia actualmente, hay demasiado contenido
sobre casi cualquier tema en las redes sociales y de las opiniones de sus usuarios, y de allí se
puede extraer valiosa información para su categorización y posterior estudio. Para las empresas y
mercadotecnia se hace muy importante conocer cuál es la opinión de los usuarios hacia sus
productos y servicios, para los mismos clientes es importante conocer cuál fue el nivel de
satisfacción usando esos mismo productos y servicios por otros clientes, y de esta manera tener
una idea efectiva de cual llenaría mejor las expectativas.
Cuando nos referimos a productos y servicios apuntamos a cualquier ámbito de consumo, ya sea
elementos de la canasta familiar, viajes, vivienda, estudios, electrónicos y gobierno entre otros.
El análisis de sentimientos como rama de la inteligencia artificial está lejos de poder utilizar las
teorías cognitivas de la emoción o el afecto para poder tomar decisiones. Éstas pueden ser útiles
para entender sobre similitudes y contrastes entre sentimientos o casi que entender etiquetas
naturales de los textos [19] como se puede ver en la Tabla 2.4, donde se presentan las emociones
básicas humanas y sus opuestos, también en la Tabla 2.5 se observa como la suma de dos de las
emociones básicas generan un sentimiento y su sentimiento opuesto.
23
Tabla 2.4
Contraste de Emociones de Plutchik
Emoción Básica Emoción Opuesta
Alegria Tristeza
Confianza Disgusto
Miedo Ira
Sorpresa Anticipación
Tabla 2.5
Contraste de Emociones y Sentimientos de Plutchik
Emociones Básicas Sentimiento Sentimiento Opuesto
Anticipación + Alegría Optimismo Desaprobación
Alegrías + Confianza Amor Remordimiento
Confianza + Miedo Sumisión Desprecio
Miedo + Sorpresa Temor Agresividad
Sorpresa + Tristeza Desaprobación Optimismo
Tristeza + Disgusto Remordimiento Amor
Disgusto + Ira Desprecio Sumisión
Ira + Anticipación Agresividad Temor
El análisis computacional de sentimientos consiste en detectar estas emociones, quién las posee,
cúal es el aspecto que genera la emoción, cuál es el tipo de emoción, o su polaridad (positiva,
negativa o neutral) y cuáles son las sentencias que la contienen [11].
24
Por lo cual la información obtenida del análisis de sentimientos la podríamos resumir en los
siguientes ítems:
● Polaridad de sentimientos sobre el servicio de salud.
● Nivel de fidelización de clientes.
● Opinión pública sobre representantes políticos o situaciones de interés social.
● Predicciones sobre resultados de elecciones.
● Tendencias de mercado.
2.2.2 Preprocesamiento De Textos
Los métodos de preprocesamiento de juegan un papel muy importante en las técnicas de minería
de datos y sus aplicaciones. Este es el primer paso para el proceso de minería de datos [24].
2.2.2.1 Extracción
Método utilizado para tokenización que es la tarea de cortar en pedazos una secuencia de
caracteres y una unidad de texto definida, cuyos pedazos son llamados tokens, y a mismo tiempo
descartando ciertos caracteres como la puntuación.
2.2.2.2 Eiminación De Palabras Vacias (Stop Words)
Las palabras vacías deben ser removidas de un texto por que hacen que el texto se vuelva pesado
y menos importante para el análisis. Remover estas palabras reduce la dimensionalidad del
espacio de términos. Las palabras más comunes en documentos de textos son artículos,
preposiciones, pronombres, entre otros que no dan el significado a los documentos. Estas
palabras son tratadas como palabras vacías, entre las cuales podemos encontrar: el, en, un, una,
con y son eliminadas de los documentos porque no se miden como palabras claves en la minería
de textos.
2.2.2.3 Identificación De La Raíz De Una Palabra (Stemming)
Steeming es el método utilizado para identificar la raíz de una palabra. El propósito de este
método es remover varios sufijos, para reducir el número de palabras, para tener trozos precisos,
ahorrar tiempo y espacio de memoria. En esta técnica, la traducción de formas morfológicas de
una palabra a su raíz es hecha suponiendo que cada una está semánticamente relacionada. Hay
dos puntos a considerar mientras se realiza el proceso de stemming:
● Las palabras que no tienen el mismo significado deben mantenerse separadas
25
● Se supone que las formas morfológicas de una palabra tienen el mismo significado básico
y por lo tanto deben ser asignadas al mismo origen.
Estas dos reglas son buenas y suficientes en aplicaciones de minería de textos o procesamiento
de lenguaje. Stemming generalmente se considera como un dispositivo que mejora la memoria.
2.2.3 Clasificación De Textos
En un sistema de análisis de sentimientos se buscan características y patrones asociadas a
opiniones, emociones y sentimientos. El objetivo principal es el que prevé cual es la categoría a
la cual se puede asociar el texto, esta puede ser positiva, negativa o neutral. Se revisarán a
continuación las técnicas asociadas a la clasificación de textos.
2.2.3.1 Técnica De Naive Bayes
Corresponden a un modelo simple de clasificación que tiene un buen funcionamiento para
categorización de textos. El algoritmo asume que cada una de las caracteristicas es independiente
de las otras dada una clase [9]. De esta manera se tiene la ecuación 2.1:
𝑃(𝑐|𝑡) =𝑃(𝑐) 𝑃(𝑡|𝑐)
𝑃(𝑡) (2.1)
Donde 𝑐 es una clase específica y 𝑡 es el texto que se quiere clasificar. 𝑃(𝑐) y 𝑃(𝑡) son las
probabilidades correspondientes a la clase y el texto, y 𝑃(𝑡|𝑐) es la probabilidad de que un texto
aparezca dada una clase. En el caso de la investigación, 𝑐 corresponde a los sentimientos
POSITIVO, NEUTRAL y NEGATIVO, y 𝑡 corresponde a cada uno de los datos a clasificar.
La meta es seleccionar el valor de 𝑐 que maximice 𝑃(𝑐|𝑡), donde 𝑃(𝑤𝑖|𝑐) es la probabilidad de
la 𝑖 − é𝑠𝑖𝑚𝑎característica en el texto 𝑡 aparezca dada la clase 𝑐. Para esto se necesita entrenar
parámetros de 𝑃(𝑐) y 𝑃(𝑤𝑖|𝑐), los cuales son fáciles de obtener en el modelo de Naive Bayes y
que corresponde a la estimación de probabilidad máxima de cada uno. Al hacer la predicción de
un nuevo texto 𝑡, se calcula el logaritmo de la probabilidad 𝑙𝑜𝑔 𝑃(𝑐) + 𝛴𝑖 𝑙𝑜𝑔 𝑃(𝑤𝑖|𝑐) de las
diferentes clases, y toma la clase con más alto logaritmo de probabilidad como predicción.
2.2.3.2 Técnica De Máxima Entropía
La idea detrás de esta técnica, abreviada como MaxEnt, es que se deberían preferir los modelos
más uniformes que satisfacen una restricción dada. Estos modelos son basados en características.
En un escenario de dos clases, usar estos modelos es equivalente a usar regresión logística para
encontrar la distribución sobre las clases. MaxEnt difiere con Naive Bayes en que no realiza
suposiciones de independencia para sus características, lo que conlleva a poder agregar
26
características como bigramas y expresiones sin preocuparnos por la superposición de
características [8]. El modelo está representado con la ecuación 2.2:
𝑃(𝑐|𝑑, 𝜆) =𝑒𝑥𝑝[𝛴𝑖𝜆𝑖𝑓𝑖(𝑐,𝑑)]
𝛴𝑐′𝑒𝑥𝑝[𝛴𝑖𝜆𝑖𝑓𝑖(𝑐,𝑑)] (2.2)
Donde 𝑐 corresponde a la clase, 𝑑 es el texto y 𝜆 es el vector de peso. Estos vectores deciden la
importancia de una característica en la clasificación. Un mayor peso significa que la
característica es un indicador fuerte para la clase. El vector de peso es obtenido mediante la
optimización de lambdas con el fin de maximizar la probabilidad condicional.
2.2.3.3 Técnica De Support Vector Machine
Está basado en el principio de minimización de riesgos estructurales para la teoría de aprendizaje
computacional, cuya idea es encontrar una hipótesis ℎ en el cual se pueda garantizar el error
verdadero más bajo. El error verdadero de ℎ es la probabilidad que ℎ caiga en un error en un
ejemplo de prueba no visto y seleccionado al azar [10]. Se puede usar un límite superior para
conectar el error verdadero de una hipótesis ℎ con el error de ℎ en el conjunto de entrenamiento
y la complejidad de 𝐻 (medida por la dimensión VC1), el espacio de hipótesis que contiene ℎ.
Support Vector Machine, denotado como SVM, encuentra la hipótesis ℎ aproximada que minice
el límite del error verdadero a través de controles efectivos y eficientes de la dimensión VC de
𝐻.
Aprendiendo la forma de umbral lineal en su forma básica, pero que a través de complementos
adecuados a su núcleo pueden ser usados para aprender clasificadores polinomiales, redes de
función básica radial y redes neuronales sigmoideas de tres capas. También tiene la habilidad de
que su aprendizaje puede ser independiente de la dimensionalidad del espacio de características,
midiendo la complejidad de la hipótesis basado en el margen por el cual están separados los
datos y no por la cantidad de las características.
2.2.3.4 Técnica De Árboles De Decisión
Provee una descomposición jerárquica del espacio del conjunto de datos en el cual se usa una
condición en el valor del atributo para dividir los datos. La condición o predicado es la presencia
o ausencia de una o más palabras. La división del espacio de datos es hecha recursivamente hasta
que los nodos hoja alcancen un número mínimo de registros que son utilizados para la
clasificación [17].
1 La dimensión Vapnik-Chervonenkis se usa para dar límites superiores e inferiores a la complejidad de la muestra
en clases infinitas de conceptos [7]
27
Los árboles tienen tres tipos de nodos [23]:
● Un nodo raíz que no tiene aristas entrantes y cero o más aristas de salida
● Nodos internos, cada uno de los cuales tiene exactamente una arista de entrada y dos o
más aristas de salida
● Hojas o nodos terminales, cada uno de los cuales tiene exactamente una arista de entrada
y ninguna arista de salida.
En un árbol de decisión, cada nodo hoja es asignada a una etiqueta de clase. Los nodos no
terminales, los cuales incluyen la raíz y los nodos internos, contienen condiciones de prueba de
atributos para separar registros que tienen diferentes características.
Existen varias medidas que pueden ser usadas para determinar la mejor manera para separar los
registros, las cuales están definidas en términos de la distribución de la clase de los registros
antes y después de separados. La expresión 𝑝(𝑖|𝑡) denota la fracción de registros que pertenecen
a la clase 𝑖 en un nodo 𝑡. En ocasiones, se omite la referencia al nodo 𝑡 expresando la fracción
como 𝑝𝑖.
Las medidas creadas para seleccionar la mejor manera de separar son basados frecuentemente en
el grado de impureza que los nodos hijos. Cuanto menor sea el grado de impureza, más sesgada
será la distribución de clase. Entre las medidas de impureza se tienen las expresadas en las
ecuaciones 2.3 a la 2.5:
𝐸𝑛𝑡𝑟𝑜𝑝í𝑎(𝑡) = −𝛴𝑖=0𝑐−1 𝑝(𝑖|𝑡) 𝑙𝑜𝑔2 𝑝(𝑖|𝑡) (2.3)
𝐺𝑖𝑛𝑖(𝑡) = 1 − 𝛴𝑖=0𝑐−1[𝑝(𝑖|𝑡)]2 (2.4)
𝐶𝑙𝑎𝑠𝑖𝑓𝑖𝑐𝑎𝑐𝑖ó𝑛 𝑑𝑒 𝐸𝑟𝑟𝑜𝑟(𝑡) = 1 − 𝑚𝑎𝑥𝑖[𝑝(𝑖|𝑡)] (2.5)
Donde 𝑐 es el número de clases y 0 𝑙𝑜𝑔2 0 = 0 en los cálculos de entropía.
2.2.4 Natural Language Toolkit
Denotada por NLTK, es un conjunto de módulos de programas, conjuntos de datos y tutoriales
que apoyan la investigación y la enseñanza en lingüística computacional y procesamiento de
lenguaje natural (NLP). NLTK está escrita en el lenguaje de programación Python y distribuida
bajo licencia de código abierto GPL [3].
28
Con el paso del tiempo la herramienta ha sido reescrita para simplificar muchas estructuras de
datos lingüísticos y aprovechando las últimas mejoras en el lenguaje Python.
Un conjunto de módulos base define tipos de datos básicos y sistemas de procesamiento que son
usados en toda la herramienta. El módulo de token se encarga del procesamiento de texto, tales
como palabras o frases. El módulo de árbol define estructuras de datos para representar
estructuras de árbol sobre texto, tales como árboles de sintaxis y árboles morfológicos. El
módulo de probabilidad codifica distribuciones de frecuencia y distribuciones de probabilidad,
incluida una variedad de técnicas estadísticas de suavizado [16].
Los demás módulos definen estructuras de datos e interfaces para hacer tareas específicas de
NLP. Entre ellos tenemos módulos de parseo, de etiquetado, autómatas de estado finito,
comprobación de tipos, visualización y clasificación de textos.
2.2.5 Evaluación de Clasificadores
2.2.5.1 Matriz de Confusión
Considerando el problema de estimar 𝑘 clases para un conjunto de prueba contenidas en 𝑛
instancias, las clases predecidas son representadas por 𝐶𝑖, mientras que las clases estimadas tal
como se definen en el clasificador son representadas por 𝐶�̂�. Los resultados arrojados por los
clasificadores pueden ser organizados en una matriz de confusión. Esta matriz representa como
las instancias son distribuidas sobre estimados (filas) y las clases predecidas (columnas). La
Tabla 2.7 muestra la representación de la matriz de confusión [15].
Los terminos 𝑛𝑖𝑗corresponden a la cantidad de instancias de clase 𝑖 por el clasificador, cuando en
realidad corresponden al número de clase 𝑗. De esta manera, los términos diagonales (𝑖 = 𝑗)
corresponden a las instancias correctamente clasificadas, mientras que los valores fuera de esa
diagonal (𝑖 ≠ 𝑗) representa instancias clasificadas incorrectamente.
Tabla 2.7
Representación de Matriz de Confusión
𝐶1 . .. 𝐶𝑘
𝐶1̂ 𝑛11 . .. 𝑛1𝑘
. .. . .. . .. . ..
𝐶�̂� 𝑛𝑘1 . .. 𝑛𝑘𝑘
29
Considerando una clase 𝑖 en particular, se pueden distinguir los siguientes tipos de instancias:
verdaderos positivos (𝑇𝑃) y falsos positivos (𝐹𝑃) que corresponden a instancias correcta e
incorrectamente clasificadas de 𝐶�̂�. Los verdaderos negativos (𝑇𝑁) y los falsos negativos (𝐹𝑁)
son instancias correcta e incorrectamente no clasificadas como 𝐶�̂� respectivamente.
La exactitud predictiva es definida según la ecuación 2.6:
𝐸𝑥𝑎𝑐𝑡𝑖𝑡𝑢𝑑 = (𝑇𝑃 + 𝑇𝑁) / (𝑇𝑃 + 𝐹𝑃 + 𝑇𝑁 + 𝐹𝑁) (2.6)
Sin embargo, esta exactitud no es apropiada para datos que se encuentren desequilibrados [5].
Como ejemplo del caso de estudio, consideremos que los comentarios positivos y negativos se
encuentran en una proporción más grande que los comentarios neutrales. Para estos casos pueden
usarse medidas tales como precisión, recall y medida F.
2.2.5.2 Precisión
Corresponde al número de ejemplos positivos correctamente clasificados dividido por el número
de ejemplos etiquetados por el sistema como positivos. De acuerdo a la notación definida en la
sección 2.2.4.1 se tiene expresa según la ecuación 2.7 [21]:
𝑃𝑟𝑒𝑐𝑖𝑠𝑖ó𝑛 =𝑇𝑃
𝑇𝑃 + 𝐹𝑃 (2.7)
2.2.5.3 Recall
Hace referencia al número de ejemplos positivos correctamente clasificados dividido por el
número de ejemplos positivos en los datos [21]. Se encuentra representado como se ve en la
ecuación 2.8:
𝑅𝑒𝑐𝑎𝑙𝑙 =𝑇𝑃
𝑇𝑃 + 𝐹𝑁 (2.8)
30
2.2.5.4 Medida F
Es una medida que combina las ventajas y las desventajas de la precisión y el recall, cuyo
resultado refleja la bondad de un clasificador ante una clase dada [5]. La medida F representa la
compensación entre los diferentes valores de 𝑇𝑃, 𝐹𝑃 y 𝐹𝑁. La expresión para la medida F está
dada por la ecuación 2.9:
𝑀𝑒𝑑𝑖𝑑𝑎 𝐹 =(1+𝛽2) ∗ 𝑟𝑒𝑐𝑎𝑙𝑙 ∗ 𝑝𝑟𝑒𝑐𝑖𝑠𝑖ó𝑛
𝛽2 ∗ 𝑟𝑒𝑐𝑎𝑙𝑙 + 𝑝𝑟𝑒𝑐𝑖𝑠𝑖ó𝑛 (2.9)
Donde 𝛽 corresponde a la importancia relativa de la precisión contra el recall. Usualmente este
valor 𝛽 se establece como 1.
31
3. Proceso de Ingeniería
En esta sección se detalla todo el trabajo ejecutado para hacer análisis de sentimientos a textos
escritos por los usuarios de la red social Twitter y los resultados obtenidos.
3.1 Exploración Y Selección
3.1.1 Selección De Estilo Arquitectónico
Existen diversos estilos arquitectónicos que pueden ser aplicados a una solución específica de
acuerdo con los controladores que la rijan y los atributos de calidad que se identifiquen y sean
más relevantes en el diseño.
A continuación, se detallan los procesos realizados en cada uno de los pasos sugeridos por el
QAW y los aspectos relevantes identificados en cada uno de ellos.
Paso 1: Presentación E Introducción
El equipo se compone por los investigadores de la presente investigación y adicional se cuenta
contó con la revisión y validación de los resultados de la metodología por un arquitecto experto.
Los miembros del equipo tuvieron claro cuáles fueron los pasos a tratar en la metodología. En
cuanto a los roles de cada uno, ambos tuvieron igualdad de funciones.
Paso 2: Presentación Del Negocio Y Misión
Definición de los requisitos del sistema:
● Descarga de los datos de acuerdo con los hashtags que sean tendencia y que hablen sobre
salud en Colombia.
● Clasificar estos datos descargados en una de las tres categorías de análisis de
sentimientos: positivo, neutral o negativo.
● Parametrizar los hashtags que sean tendencia.
● Parametrizar el clasificador a ser utilizado.
● Exponer interfaces que permitan realizar los procesos anteriores de manera independiente
y que puedan llegar a ser programados.
Paso 3: Presentación Del Plan De Arquitectura
En el modelo preliminar se hizo un análisis de cómo debería ser la interacción de los diferentes
componentes que fueron desarrollados. Para esto, se tiene como base la presentación de un
diagrama de alto nivel. Adicional del plan del diseño, se tienen claras las siguientes
consideraciones:
32
● Se debe realizar el refinamiento de atributos de calidad, los cuales conllevarán a la
selección del estilo arquitectónico adecuado para cada uno de ellos.
● Las librerías y APIs utilizadas para el desarrollo de componentes debe ser de uso libre,
que no se requiere el pago de licencias.
● El procesamiento de lenguaje natural de la información de Twitter debe ser en español.
● La información filtrada debe ser única y exclusivamente de temas que traten temas de la
salud y de entidades prestadoras del servicio de salud en el territorio colombiano.
Paso 4: Identificación De Controladores De La Arquitectura
En los pasos anteriores, se refinan los requisitos del proyecto y algunos controladores
arquitecturales relevantes. Extrayendo cada uno de ellos y los que se van a tener en cuenta para
el diseño, se tiene los siguientes:
● Definición de estilo arquitectónico adecuado para realizar análisis de sentimientos de
información de la red social Twitter sobre el tema de los servicios de salud en Colombia.
● Desarrollo de los componentes necesarios para realizar la recuperación de información de
Twitter y realizar el respectivo procesamiento para el análisis de sentimientos de cada
uno de los datos descargados.
● Evaluación del modelo arquitectónico propuesto.
● Se establece la restricción de las APIs y librerías a ser usadas deben ser de uso público y
libre.
● Desde la presentación del plan de la arquitectura se identifica que los atributos de calidad
que se deben tener en cuenta para el diseño de la arquitectura son: Interoperabilidad,
modificabilidad y escalabilidad, definidos en la Tabla 3.1.
33
Tabla 3.1
Atributos de calidad y significado
Atributo De Calidad Significado
Interoperabilidad La interoperabilidad es la capacidad que tiene un producto o un
sistema, cuyas interfaces son totalmente conocidas, para
funcionar con otros productos o sistemas existentes o futuros y
eso sin restricción de acceso o de implementación.
Modificabilidad Habilidad para hacer cambios al sistema de una forma rápida y
poco costosa. Es el atributo de calidad más íntimamente
relacionado con la arquitectura.
Escalabilidad Es la capacidad de la aplicación para funcionar correctamente si
el tamaño de procesamiento se incrementa. La escalabilidad
debe ser alcanzada sin modificaciones de la arquitectura
subyacente, a parte de los cambios inevitables de configuración.
Una arquitectura no escalable, cuando el tamaño de
procesamiento se incrementa su throughput se decrementa y el
tiempo de respuesta se incrementa exponencialmente.
Paso 5: Lluvia de Escenarios
Entre los stakeholders investigadores, se plantean diferentes escenarios que puedan llegarse a
presentar durante la puesta en marcha del prototipo funcional de la arquitectura. Cada uno aporta
dos escenarios, teniendo en cuenta que puedan ser tenidos en cuenta por lo menos una vez uno de
los atributos de calidad definidos, siendo ellos los siguientes:
1. Se deben descargar los datos directamente de la plataforma Twitter de acuerdo con
los filtros que se necesiten.
2. Se deben procesar todos los datos que sean descargados de manera periódica sin
importar el número que se recuperen.
3. Se debe poder modificar los parámetros para la descarga de la información de Twitter
de acuerdo con nuevas tendencias en cuanto a los términos de búsqueda.
4. A medida que se tenga más información en la base de datos, el sistema podrá
clasificar mejor los datos de la red social, para identificar el sentimiento asociado
Paso 6: Consolidación de Escenarios
Debido a la cantidad de participantes de escenarios y el trabajo conjunto que se hizo al momento
de la consideración de estos, no se presentan escenarios repetidos y cada uno se encarga de una
funcionalidad específica dentro del sistema.
34
Paso 7: Priorización de Escenarios
Se generaron 4 escenarios entre los stakeholders del sistema. Para cada uno de ellos se
obtuvieron un total de 2 votos para realizar la priorización. Haciendo la priorización de los
escenarios se tienen en orden con su respectiva votación:
● Escenario 2: Se deben procesar todos los datos que sean descargados de manera
periódica sin importar el número que se recuperen. (2 votos)
● Escenario 3: Se debe poder modificar los parámetros para la descarga de la información
de Twitter de acuerdo con nuevas tendencias. (1 voto)
● Escenario 4: A medida que se tenga más información en la base de datos, el sistema
podrá clasificar mejor los datos de la red social, para identificar el sentimiento asociado.
(1 voto)
● Escenario 1: Se deben descargar los datos directamente de la plataforma Twitter de
acuerdo con los filtros que se necesiten. (0 votos)
Paso 8: Refinamiento de Escenarios
El método de QAW sugiere que se realice el refinamiento de 4 o 5 escenarios. Debido a la
cantidad de escenarios que salieron durante el proceso, se decide hacer el refinamiento a los tres
primeros escenarios, que fueron los que obtuvieron votos durante la priorización.
Refinamiento de Escenario para Escenario 2
Escenario: Se deben procesar todos los datos que sean descargados de manera
periódica sin importar el número que se recuperen
Objetivos de Negocio: Realizar el análisis de sentimientos de la información obtenida de
Atributos de Calidad
Relevantes:
Escalabilidad
Estímulo: Procesar toda la información que obtenga de Twitter
Fuente de
Estímulo:
API de Twitter
Ambiente: Procesamiento de datos
Artefacto: Componente de análisis de sentimientos
Respuesta: Procesamiento y clasificación de los datos
Medida de
Respuesta:
Cantidad de aciertos sobre total de datos procesados
Preguntas: ¿Qué tanta precisión se debe tener en cuenta al momento de hacer el
análisis de sentimientos?
Problemas: Mala clasificación de los datos
Co
mp
on
e
nte
s
35
Refinamiento de Escenario para Escenario 3
Escenario: Se debe poder modificar los parámetros para la descarga de la
información de Twitter de acuerdo con nuevas tendencias
Objetivos de Negocio: Descarga de información de Twitter para análisis de sentimientos
Atributos de Calidad
Relevantes:
Modificabilidad
Estímulo: Poder utilizar todas las tendencias que sean útiles para el análisis
Fuente de
Estímulo:
API de Twitter
Ambiente: Descarga de los datos
Artefacto: Componente de descarga
Respuesta: Datos con tendencias parametrizadas
Medida de
Respuesta:
Preguntas: ¿Qué tan cambiante son las tendencias de Twitter respecto a temas
de salud en Colombia?
Problemas: Presencia de nuevas tendencias que no sean analizadas y contengan
información que pueda ser relevante
Refinamiento de Escenario para Escenario 4
Escenario: A medida que se tenga más información en la base de datos, el
sistema podrá clasificar mejor los datos de la red social, para
identificar el sentimiento asociado
Objetivos de Negocio: Realizar el análisis de sentimientos de la información obtenida de
Atributos de Calidad
Relevantes:
Escalabilidad
Estímulo: Tener un conjunto de entrenamiento robusto
Fuente de
Estímulo:
Datos analizados
Ambiente: Matriz de entrenamiento para el análisis de sentimientos
Artefacto: Componente de análisis de sentimientos
Respuesta:
Medida de
Respuesta:
Preguntas: ¿Qué tan grande debe ser la matriz de entrenamiento?
Problemas: No pasarle una matriz de entrenamiento con datos verídicos que
lleven a un procesamiento de datos
Terminado todo el proceso, se logró tener claridad sobre cuáles eran los requisitos del proyecto,
controladores de arquitectura, posibles escenarios y la forma de abordarlos y resultados
esperados, y los atributos de calidad. Entre los atributos de calidad que se definieron para el
diseño de la arquitectura se tienen interoperabilidad, modificabilidad y escalabilidad. Todo el
diseño debe realizarse para que estos atributos sean tenidos en cuenta en cada uno de los
Co
mp
on
e
Co
mp
on
e
36
componentes de la arquitectura y que al momento de realizarse la validación arrojan un alto
grado de cumplimiento.
Otro de los puntos que se puede concluir al aplicar la metodología, es la de seleccionar el estilo
arquitectónico adecuado entre los posibles estudiados. De acuerdo a los atributos de calidad y
controladores identificados, una de las arquitecturas que se amolda al proceso es la Orientada a
Servicios. Este estilo será el que se tenga en cuenta para el diseño y construcción del prototipo de
la investigación.
3.2 Construcción
3.2.1 Diseño De Arquitectura De Software Para El Análisis De Sentimientos
De acuerdo con los controladores definidos, se realizó el diseño de la arquitectura la cual va ser
la propuesta base para realizar análisis de sentimientos de información descargada de Twitter
sobre temas de salud en Colombia.
Se definieron los módulos principales que se crearon para los procesos base de la propuesta
como lo son la recuperación de datos, análisis de sentimientos y visualización de resultados.
Siguiendo el modelo de vistas de arquitectura 4+1 [13], se definen las vistas en las Figuras 3.1 a
la 3.5 para el diseño incluyendo cada uno de los componentes y las librerías que son utilizadas en
ellos.
Figura 3.1. Vista Lógica de la arquitectura propuesta
37
Figura 3.2. Vista de Procesos de la arquitectura propuesta
Figura 3.3. Vista de Desarrollo de la arquitectura propuesta
Figura 3.4. Vista Física de la arquitectura propuesta
38
Figura 3.5. Definición de escenarios para la arquitectura propuesta
Para el primer componente correspondiente a la recuperación de información de Twitter, se
realizó una conexión con la API expuesta por Twitter para la descarga de los datos de acuerdo a
los parámetros suministrados, los cuales serán guardados en una bodega de información.
El segundo componente de análisis de sentimientos, el cual tendrá como entrada los datos
descargados por el primer componente. Para este proceso se utilizará la librería NLTK, la cual
fue configurada para realizar todo el procesamiento de textos y demás procesos necesarios para
el análisis de sentimientos en español.
Un tercer componente complementario a los dos anteriores también fue desarrollado, el cual
corresponde a un generador de reportes, que organiza los resultados para entender la información
descargada y clasificada por los otros componentes.
Cada uno de estos componentes podrán ser accedidos a través de una interfaz de usuario donde
se pueda realizar cualquiera de los procesos principales y además poder visualizar los reportes de
una manera que pueda ser interpretada fácilmente por el usuario final.
3.2.2 Selección Del Conjunto De Entrenamiento
Para realizar el análisis de sentimientos se definió un conjunto de datos, los cuales expresan
formas conocidas de cada uno de los posibles sentimientos. Este conjunto de datos fue utilizado
tanto para el entrenamiento como para la validación del clasificador a ser utilizado.
Internet provee diferentes opciones de las cuales pueden llegar a ser extraídos textos los cuales
puedan ser utilizados como conjunto de datos. Dado el tema central de la investigación que
corresponde a la salud, acotamos los lugares de búsqueda a redes sociales mediante el uso de
tendencias, sitios especializados de salud en los cuales los usuarios dejen sus opiniones sobre
este tema, entre otros. Una de estas opciones es Google Maps, en el cual se registran diversos
sitios como restaurantes, centros comerciales, almacenes, hospitales, clínicas y demás. Esta
plataforma permite que los usuarios califiquen algún lugar en un rango de 1 a 5 (representado en
estrellas) y adicional de que hagan sus opiniones sobre el sitio que están visitando.
39
Para el caso de estudio, se obtuvieron los comentarios de las clínicas y hospitales de ciudades
capitales de Colombia, siendo ellas Bogotá, Medellín, Cali, Barranquilla, Cartagena y
Bucaramanga. En la Figura 3.6 se puede observar el detalle de una clínica de la ciudad de Cali,
donde se identifica la cantidad de calificaciones realizadas por usuarios y con su respectiva
calificación promedio.
Figura 3.6. Ubicación de clínica y puntuación en Google Maps
En la Figura 3.7, se puede observar el listado de todas las calificaciones y se realiza un resumen
de la cantidad de calificaciones por puntuación. Por cada una de las ellas se observa la
puntuación suministrada por el usuario, así como un comentario opcional complementando.
40
Figura 3.7. Resumen de puntuación y comentarios de clínica en Google Maps
De todas las clasificaciones por cada uno de los lugares, se descargan aquellas que tengan
puntuación y comentario y que sean en español. Estos comentarios con su puntuación son
organizados en una hoja electrónica, identificando la clínica u hospital al cual pertenece y la
ciudad en la que se encuentra. En la Tabla 3.2 se puede ver el esquema de cómo van a ser
organizados los comentarios que fueron obtenidos. En total son 1369 registros.
Para dar una clasificación a cada uno de los comentarios descargados, se tienen en cuenta las
siguientes opciones:
● Positivo: en caso de que el comentario exprese algo a favor.
● Negativo: en caso de que el comentario expresa inconformidad.
● Neutral: cuando el comentario no exprese aspectos positivos o negativos
● No Útil: todos aquellos comentarios no relevantes con temas de salud o que no aportan
para la clasificación
41
Tabla 3.2
Esquema de organización de comentarios de Google Maps
Ciudad Clínica Comentario Estrellas
Bogotá Clínica del Country Buena atención 5
Se supone que es una de la
mejores, paga uno medicina
prepagada para tener que estar
cuatro horas esperando que
atiendan a los niños, pésimo
servicio pediátrico.
1
Urgencias es lento, normal, pero
avanza. Por lo menos no es caótico
como en otras clinicuchas
3
Agradezco la atención que me
prestaron. Fue rápida y muy
profesional. Dios bendiga a sus
doctores y grupo de auxiliares. Un
saludo.
5
Cali Fundación Valle del Lili La Clínica Valle del Lili,
auspiciada en buena parte por la
Fundación Valle del Lili, está
catalogada como una de las
instituciones prestadoras de salud
más importantes de América
Latina. Sus servicios en general
son de alto nivel, con la más alta
tecnología y el cuerpo médico de
más alto perfil y competencias
laborales.
5
Yo estuve ahí me hicieron un
transplante y muy buena atención
5
Considerada una de las mejores
clínicas de país y de Suramérica.
4
Muy demorada la atención en el
laboratorio y rayos x y adicional
excesivo el cobro del parqueadero.
2:30 horas $5.500
1
42
Como guía de para la clasificación se toma el comentario y no la puntuación, ya que se pudo
identificar al obtener la colección de datos que muchas veces se daba una puntuación baja con
comentarios positivos o viceversa. La calificación realizada por cinco personas, las cuales
revisaron cada uno de los comentarios y dependiendo su contenido le asignaron una de las
opciones mencionadas anteriormente. Cuando todos los evaluadores dieron una clasificación a la
totalidad de los comentarios, se hicieron ponderaciones de las clasificaciones para determinar la
clasificación final de cada uno de ellos.
De todos los comentarios clasificados, se obtuvieron los resultados consignados en la Tabla 3.3:
Tabla 3.3
Resultados de calificación de comentarios
Clasificación Comentarios
Positivo 732
Negativo 360
Neutral 76
No Útil 203
De los comentarios clasificados como positivo, negativo y neutral, se realizaron procesos de
filtrado eliminando aquellos comentarios que sean repetidos. Posterior a este proceso quedan un
total de 1025 comentarios relevantes como conjunto de entrenamiento, distribuidos según
resultados de la Tabla 3.4 y representados en la Figura 3.8:
Tabla 3.4
Comentarios depurados por sentimiento
Clasificación Comentarios
Positivo 594
Negativo 355
Neutral 76
43
Figura 3.8. Distribución de comentarios por sentimiento
3.2.3 Evaluación Y Selección Del Clasificador
Como se definió en secciones anteriores, se usará como herramienta para el análisis de
sentimientos NLTK basada en el lenguaje de programación de Python. Esta librería dentro de su
implementación cuenta con diferentes clasificadores los cuales pueden llegar a ser utilizados para
analizar y clasificar cada uno de los datos que sean descargados a través de la API de Twitter.
Los clasificadores para ser analizados para la selección corresponden a los siguientes:
● Naive Bayes
● Máxima Entropía
● Support Vector Machines (SVM)
● Árboles de Decisión
Como conjunto de datos se tomará el definido anteriormente, que consta de un total de 1025
comentarios entre las tres clases definidas para el análisis de sentimientos. Este conjunto de datos
fue distribuido en un 70% para entrenamiento y el 30% restante utilizado para validar dicho
conjunto de entrenamiento, los cuales son seleccionados de manera aleatoria para un total de 718
comentarios para entrenamiento y 307 para validación. Teniendo estos grupos de datos para
entrenamiento y validación, son entrenados cada uno de los clasificadores implementados y
clasificados cada uno de los comentarios para validación, almacenando el resultado obtenido
para cada clasificador.
Posterior al proceso de clasificación, se creó la matriz de confusión para clasificadores
multiclase, de los cuales se obtienen medidas como precisión, recall y medida F1 por clase. Estas
44
métricas ayudarán a la selección del clasificador adecuado para el conjunto de datos
seleccionado.
Este procedimiento de validación se realiza con tres conjuntos aleatorios diferentes de
entrenamiento y validación, con la finalidad de tener resultados precisos ante diferentes entradas
y poder definir una tendencia en los clasificadores. Los resultados de estas tres validaciones se
pueden evidencias en las Tablas 3.5 a la 3.7 y en las Figuras 3.9 a la 3.11. Para las tablas tener en
cuenta las siguientes convenciones:
● Pos: Sentimiento Positivo
● Neg: Sentimiento Negativo
● Neu: Sentimiento Neutral
Tabla 3.5
Precisión de clasificadores para primeros tres conjuntos de prueba
Conjunto de Prueba 1 Conjunto de Prueba 2 Conjunto de Prueba 3
Bayes Max
Ent
SVM Árboles Bayes Max
Ent
SVM Árboles Bayes Max
Ent
SVM Árboles
Pos 0.75 0.68 0.87 0.86 0.79 0.69 0.91 0.90 0.69 0.60 0.82 0.80
Neg 0.33 - 0.50 0.45 0.17 - 0.50 0.33 0.40 - 0.63 0.47
Neu 0.82 0.92 0.86 0.76 0.88 0.94 0.86 0.76 0.85 0.97 0.88 0.77
Figura 3.9. Distribución de precisión de clasificadores para primeros tres conjuntos de prueba
45
Tabla 3.6
Recall de clasificadores para primeros tres conjuntos de prueba
Conjunto de Prueba 1 Conjunto de Prueba 2 Conjunto de Prueba 3
Bayes Max
Ent
SVM Árboles Bayes Max
Ent
SVM Árboles Bayes Max
Ent
SVM Árboles
Pos 0.96 0.99 0.96 0.90 0.95 0.99 0.95 0.87 0.95 0.99 0.94 0.90
Neg 0.04 - 0.20 0.36 0.05 - 0.37 0.37 0.07 - 0.34 0.24
Neu 0.56 0.34 0.84 0.73 0.64 0.34 0.84 0.79 0.57 0.28 0.79 0.73
Figura 3.10. Distribución de recall de clasificadores para primeros tres conjuntos de prueba
46
Tabla 3.7
Medida F1 de clasificadores para primeros tres conjuntos de prueba
Conjunto de Prueba 1 Conjunto de Prueba 2 Conjunto de Prueba 3
Bayes Max
Ent
SVM Árboles Bayes Max
Ent
SVM Árboles Bayes Max
Ent
SVM Árboles
Pos 0.84 0.80 0.91 0.88 0.86 0.81 0.93 0.88 0.80 0.75 0.88 0.85
Neg 0.07 - 0.29 0.40 0.08 - 0.42 0.35 0.12 - 0.44 0.32
Neu 0.67 0.49 0.85 0.75 0.74 0.50 0.85 0.77 0.68 0.43 0.84 0.75
Figura 3.11. Distribución de medida F1 de clasificadores para primeros tres conjuntos de prueba
Los datos analizados en las tres primeras validaciones no fueron uniformes en cuanto a cantidad
de comentarios por sentimiento, siendo los positivos con mayor participación y los neutrales con
una cantidad menor respecto a los otros. Para probar el comportamiento de los clasificadores con
otra distribución de comentarios, se decide hacer una cuarta validación con un subconjunto de
datos del seleccionado, pero esta vez teniendo igual número de comentarios por sentimiento. Se
toman 76 comentarios aleatorios por sentimiento para un total de 228 comentarios. A estos se
aplica de igual manera la distribución 70% para entrenamiento y 30% para validación que fue
utilizada en las anteriores validaciones.
Una última validación es realizada con la misma cantidad uniforme en cuanto al conjunto de
datos se refiere. Esta vez se toman los 228 comentarios seleccionados de la validación anterior
como entrenamiento y se realiza la validación con el total de 1025 comentarios. Los resultados
47
de las validaciones 4 y 5 se pueden evidenciar en las Tablas 3.8 a la 3.10 y en las figuras 3.12 a
la 3.14.
Tabla 3.8
Precisión de clasificadores para conjuntos de prueba 4 y 5
Conjunto de Prueba 4 Conjunto de Prueba 5
Bayes Max
Ent
SVM Árboles Bayes Max
Ent
SVM Árboles
Pos 0.56 0.67 0.76 0.33 0.80 0.85 0.93 0.91
Neg 0.45 0.53 0.52 0.53 0.40 0.42 0.42 0.27
Neu 0.89 0.71 0.58 0.42 0.98 0.96 0.90 0.73
Figura 3.12. Distribución de precisión de clasificadores para conjuntos de prueba 4 y 5
48
Tabla 3.9
Recall de clasificadores para conjuntos de prueba 4 y 5
Conjunto de Prueba 4 Conjunto de Prueba 5
Bayes Max
Ent
SVM Árboles Bayes Max
Ent
SVM Árboles
Pos 0.92 0.75 0.67 0.25 0.93 0.91 0.88 0.55
Neg 0.24 0.43 0.52 0.43 0.78 0.87 1.00 0.93
Neu 0.70 0.74 0.65 0.61 0.50 0.64 0.71 0.83
Figura 3.13. Distribución de recall de clasificadores para conjuntos de prueba 4 y 5
49
Tabla 3.10
Medida F1 de clasificadores para conjuntos de prueba 4 y 5
Conjunto de Prueba 4 Conjunto de Prueba 5
Bayes Max
Ent
SVM Árboles Bayes Max
Ent
SVM Árboles
Pos 0.70 0.71 0.71 0.29 0.86 0.88 0.90 0.68
Neg 0.31 0.47 0.52 0.47 0.53 0.57 0.59 0.42
Neu 0.78 0.72 0.61 0.50 0.67 0.77 0.79 0.77
Figura 3.14. Distribución de medida F1 de clasificadores para conjuntos de prueba 4 y 5
Los resultados de los conjuntos de datos 1, 2 y 3, muestran resultados no tan distantes y un poco
más equilibrados en los tres sentimientos entre los clasificadores SVM y árboles de decisión. En
la validación 4, se observa que árboles de decisión merma un poco los buenos resultados
obtenidos en la primera validación, dejando paso a un repunte de máxima entropía y de nuevo a
SVM. La última validación muestra resultados más equilibrados entre todos los clasificadores,
siendo SVM el que más destaca entre los demás. Analizando los resultados de todas las
validaciones, se puede decir SVM fue el clasificador que mejor comportamiento tuvo y fue
constante en sus resultados independiente de la distribución de datos con el que se entrenará en el
dominio de opiniones sobre temas de salud.
La técnica de SVM implementada utiliza la estrategia de uno contra el resto la cual es específica
para clasificadores multiclase, ayudando a que el proceso de clasificación sea adecuado y
preciso, creando clasificadores por clase y tratándolo como si fueran binarios, lo que hace que
50
siempre se presentan datos desiguales en cantidad de positivos y no positivos y haciendo que su
comportamiento sea el mismo para conjuntos de entrenamiento iguales o desiguales en cantidad
de registros por clase. Esto pudo ser corroborado con los resultados de las 5 validaciones que
fueron realizadas para los clasificadores.
3.2.4 Prototipo Funcional
El diseño de la arquitectura propuesta se empleó en la implementación del prototipo funcional,
con el cual se verifica cada uno de los requisitos del sistema y se valida que los controladores de
arquitectura identificados sean cumplidos en su totalidad.
Como almacén de datos se decidió utilizar una base de datos NoSQL como MongoDB, esta base
de datos permite versatilidad y facilidad al momento de almacenar todos los datos que sean
descargados sin necesidad de hacer relaciones complejas para tener un registro completo.
También se almacenará el conjunto de entrenamiento para el análisis de sentimientos y algunos
parámetros de configuración que serán detallados más adelante.
Para el primer componente de recuperación de información se utiliza la API suministrada por
Twitter, la cual retorna un JSON que es un acrónimo de JavaScript Object Notation, es un
formato de texto ligero para el intercambio de datos. con información relevante de cada dato en
la red social Twitter. Esta API puede ser configurada con ciertos parámetros para filtrar la
información que se necesita para el tema específico de la investigación: salud en Colombia y
comentarios solamente en español. Los parámetros que pueden ser agregados para la búsqueda
son nombre de usuario, rango de fechas de los datos a obtener, palabras clave o hashtag y
lenguaje (Idioma).
Para nuestro caso de estudio, los parámetros que se usarán son el rango de fecha, el lenguaje y la
palabra clave para filtrar por hashtags. Estos hashtags son las tendencias con las cuales se van a
filtrar todos los datos del universo que se encuentra en la base de datos de Twitter para extraer
únicamente aquellos que hablen de temas sobre salud en Colombia. Los hashtags que vayan
siendo tendencia pueden ser parametrizados en una colección de la base de datos, de la misma
manera en los cuales pueden ser eliminados algunos hashtags que ya no tengan relevancia para el
tema de la investigación.
La Figura 3.15 muestra el esquema estructural del primer componente, el cual para su
funcionamiento expone una interfaz REST la cual se invoca para descargar los datos de acuerdo
con los hashtags configurados. Dicha API recibe como parámetros el rango de fecha en la cual se
quieren descargar los datos, primero la fecha desde y segundo la fecha hasta. El formato de la
fecha debe iniciar con el año (de cuatro dígitos), el mes (de dos dígitos) y finalmente el día
(también de dos dígitos) sin ningún espacio ni carácter entre ellos. El servicio configura para la
51
descarga el idioma español, el cual se encuentra almacenado en una colección de la base de datos
que contiene parámetros generales.
Figura 3.15. Diagrama de componente de recuperación de información de Twitter
Esta API puede ser utilizada desde una aplicación en caso de que se desee hacer una descarga
específica de datos o puede programarse para que en un periodo de tiempo determinado se
descargue la información de Twitter de acuerdo con los parámetros establecidos.
Para el componente de análisis de sentimientos, se realizó un diseño arquitectural reflejado en la
Figura 3.16. En este es obtenido el conjunto de entrenamiento seleccionado y que se encuentra
almacenado en una colección de la base de datos. A cada uno de los comentarios sin importar su
clasificación, son aplicadas técnicas de preprocesamiento de textos tales como conversión en
minúscula, tokenización, eliminación de palabras vacías y stemming a cada una de las palabras.
52
Figura 3.16. Diagrama de componente de clasificación de datos extraídos de la red social Twitter
Teniendo los comentarios procesados, se extrae una lista con todas las palabras distintas y la
frecuencia de apariencia de cada una de ellas. Con esta lista y con un ayuda de un extractor de
características, se crea un diccionario que indica las palabras que están contenidas en cada una de
los comentarios, que en conjunto aplicando estas características al clasificador y pasando el
conjunto de comentarios generan una lista con el diccionario de características y el sentimiento
asociado a cada uno de ellas.
Definida la lista de características y sentimientos, se procede con la puesta a punto del
clasificador cuyo conjunto de entrenamiento corresponde a esta misma lista. El clasificador
utilizado es SVM de acuerdo con la experimentación realizada en la sección 3.2.3.
Una vez el clasificador haya finalizado su entrenamiento, se procede a su almacenamiento como
un archivo en disco para que este pueda ser recuperado cada vez que se vaya a hacer el análisis
de sentimientos a los datos que vayan siendo descargados y así no incurrir en tiempos
adicionales de entrenamiento innecesarios. Solo en caso de que se cambien o ajusten los datos
del conjunto de entrenamiento que los haría diferentes a los que tiene el clasificador, se
procederá con un nuevo entrenamiento.
Cuando se ha entrenado el clasificador, se obtienen todos los datos descargados de la colección y
que aún no hayan sido clasificados. Para cada uno de ellos se hace el mismo preprocesamiento
que fue realizado a cada comentario del conjunto de entrenamiento. Los datos son analizados con
el clasificador y el sentimiento obtenido es actualizado en la base de almacenamiento de
información.
53
Para poder acceder a este componente y ejecutar sus procesos, se dispone de una interfaz REST
la cual no lleva ningún parámetro, ya que siempre se van a obtener los datos que están sin
clasificar en la base de datos. De igual manera que la API del primer componente, esta puede ser
utilizada para ejecutarla desde una aplicación o para ser programada y sea ejecutada
periódicamente.
El tercer componente es el encargado de obtener y consolidar los resultados del análisis de
sentimientos realizado a todos los datos obtenidos. Para ello se dispone de una interfaz REST
que será accedida desde una aplicación para presentar estos resultados, cuyo diseño se observa
en la Figura 3.17.
Figura 3.17. Diagrama de componente de visualización de resultados
De todos los datos que ya han sido clasificados, se obtiene la cantidad que se encuentra en cada
una de los sentimientos definidos. No se tiene en cuenta los datos que por algún motivo aún no
hayan sido clasificados. También se obtienen los hashtags (marca de obtención para categorizar
dentro del dominio de la salud en Colombia) y menciones por cada sentimiento, especificando la
cantidad de ocurrencias en todos los datos clasificados. Estos resultados son organizados en un
formato JSON y retornados al artefacto que consume el servicio.
54
Para presentar los resultados, se realizó una aplicación Web que utiliza el servicio detallado
anteriormente, cuya información obtenida es organizada en un tablero de resultados, donde a
través de gráficos y tablas ésta puede ser visualizada para así poder ser interpretada de una forma
más sencilla.
En la Figura 3.18 se ilustra el tablero de resultados, indicando los hashtags que han sido
parametrizados para descarga de los datos y la clasificación realizada, agrupados por cantidad,
por sentimiento y top de hashtags mencionados y usuarios de Twitter referenciados.
Figura 3.18. Tablero de Resultados
55
3.2.5 Metodología De Desarrollo De Software
La metodología SCRUM que es un marco de referencia para el desarrollo ágil y permite la
organización de equipos de personas para la organización del proceso de desarrollo de software
fue usada como parte de la gestión de la construcción del prototipo funcional, para el propósito
de este proyecto nos enfocamos en la organización de las etapas tempranas del producto y en
afinar los detalles de su desarrollo a medida que se construyó.
Basados en SCRUM se asignaron los siguientes roles y se hace una explicación de su contexto:
1. Scrum Master (Juan Carlos Chaparro): Encargado de poner a todos los actores en
contexto y realizar las ceremonias de acuerdo con el cronograma establecido.
2. Scrum Developer (Joan Romero, Juan Carlos Chaparro): Son los encargados de dar
un reporte diario de las actividades (Reunión corta diaria de actividades) que se
desarrollaron para el prototipo funcional. Estos reportes se hacen en una reunión donde
cada uno de los desarrolladores dice que hizo el día anterior, que va a hacer el día actual
y si hay algún bloqueo, el reporte de cada desarrollador no debe durar más de 5 minutos.
Los bloqueos deben ser resueltos en el menor tiempo posible entre el Scrum Master y el
Product Owner, para proveer una solución rápida al desarrollador.
3. Product Owner (Iván Mauricio Cabezas): Es el encargado de entender el prototipo
funcional y quien prioriza actividades las cuales dan el perfil adecuado para encontrar la
versión final del prototipo.
4. Sprint: Tiempo en cual se desarrollan las actividades que se han estimado para lograr
cambios y nuevas funcionalidades en el prototipo, para nuestro caso de estudio se
estimaron 2 Sprints de 2 semana cada uno.
5. Historias de Usuario: Los Sprints se basan en historias de usuario que reemplazan los
"casos de uso" de metodologías de desarrollo tradicionales. Cada historia de usuario
contiene una descripción y criterios de aceptación que el desarrollador debe cumplir,
estos criterios deben ser validados por el Product Owner.
6. Dashboard: Para organizar todas las tareas de las que se compone el desarrollo del
prototipo "Backlog", utilizamos una herramienta ágil llamada JIRA -
https://www.atlassian.com/software/jira y de uso libre en Internet, esta herramienta en su
capa libre (no pago) permite organizar las actividades del Sprint y revisar las notas y
comentarios de los desarrolladores hacia el Product Owner y el Scrum Master.
Adicionalmente JIRA permite saber en qué estado se encuentra cada historia para
56
determinar si está en proceso de desarrollo, en pruebas o si ya esta terminada (Flujo de
trabajo). Esto permite incluir cambios en el proceso de desarrollo y actualizar
constantemente al Product Owner sobre el estado actual de la aplicación.
7. Prueba de Concepto: En el desarrollo de algunas funcionalidades propias del prototipo
sobre las cuales no se tiene previo conocimiento, se desarrolla una actividad llamada
prueba de concepto que permite por medio de un desarrollo corto validar mecanismos,
necesidades y posibles planes para encontrar solución a la historia de usuario a validar y
la cual podrá ser estimada en tiempo de desarrollo de una manera correcta.
8. Demo: Un demo al final de cada Sprint permite hacer una presentación del camino feliz
(Conocido como Happy path en el ámbito de pruebas de desarrollo de software) de cada
una de las características a liberar, también se hace una demostración de como debe y
está funcionando la aplicación, esto permite al Product Owner saber si está de acuerdo
como va el desarrollo de la aplicación o si por el contrario quiere enfatizar o dar prioridad
a alguna otra característica para el siguiente Sprint.
9. Retrospective: Es una reunión que se hace al final de cada Sprint para evaluar entre los
desarrolladores y el Scrum Master, que estuvo bien y que debe mejorarse y cuales
acciones se deben tomar en cuenta para encontrar las mejoras que se esperan en el
siguiente Sprint (Aprender de los errores).
10. Release: Al final de cada Sprint (dos semanas), el equipo de desarrollo se encarga de
liberar una versión del producto, al final en la cual se dejará el prototipo funcional será la
1.2.
3.2.6 Importancia En El Contexto Social
El contexto social de esta investigación radica principalmente en que la tecnología es un medio
por el cual podemos encontrar respuestas a situaciones que nos afectan a diario, la sociedad
moderna busca poder tener cabida en un mundo que provee soluciones a la interconectividad.
Por medio de las redes sociales las personas sienten el deseo de compartir su posición frente al
mundo y sus ideales, les interesa saber en qué situación se encuentran los más cercanos a
nosotros y que han compartido. En esta investigación se va a obtener y procesar opiniones de
usuarios que opinan sobre el tema de la salud en Colombia, dado que hay demasiada información
valiosa de por sí que no ha sido entendida y analizada.
Este proyecto propone una arquitectura de software que categorice estos mensajes entre
opiniones positivas, negativas y cuáles estarían en una categoría neutral, un tema complejo como
57
el de la salud abordado desde el estudio del análisis de sentimientos para que de esta manera
ambos mundos se relacionan y se conecten con el conocimiento de porqué tecnología y sociedad
son cada vez más dependientes el uno del otro.
La ingeniería de software es el mundo de las ideas de aplicación, la de proveer conocimiento a
un sin fin de datos que por voluntad propia la sociedad quiere dar a conocer, aceptamos la
realidad tal y como es y desde lo que es el entendimiento de un producto de software como su
arquitectura y lo que esto implica nos movemos en un sentido a favor de lo que está a nuestro
alcance para dar un paso hacia adelante para ayudar al público en general, a la academia, al
gobierno y a los usuarios, a mostrar que está bien y que está mal, una voz un poco organizada,
menos distorsionada más coherente sobre lo que se lleva tiempo diciendo en las redes sociales y
nadie se ha parado a pensar, ¿Es positivo? ¿Es negativo? ¿Qué podemos hacer para seguir siendo
bueno, qué podemos hacer para cambiar lo que está mal?
3.3 Evaluación
La evaluación de la arquitectura de software planteada en esta investigación se hizo usando la
metodología ATAM (Architecture Tradeoff Analysis Method), es la metodología para evaluar
arquitecturas de Software que principalmente evalúan la adecuación de la arquitectura definida
con respecto a sus atributos de calidad.
A continuación, se pone en contexto la explicación del proceso realizado y los resultados de esta
evaluación.
3.3.1 Evaluación de la Arquitectura
El proceso realizado con la metodología de ATAM se realiza usando 4 fases. Los involucrados
para la aplicación de la metodología ATAM son los miembros de este proyecto de investigación:
Iván Mauricio Cabezas
Joan Romero
Juan Carlos Chaparro
58
3.3.2 ATAM Definición de Fases
● Fase 0: Definición de tiempos, fechas, costos asociados, esfuerzos. Crear el equipo de
evaluación.
Las Fases 1 y 2 se organizan en 4 grupos, donde se realizan 9 pasos. A continuación, su
descripción:
● Fase 1:
Grupo 1:
○ Paso 1: Presentación de ATAM.
○ Paso 2: Presentación de las pautas del negocio.
○ Paso 3: Presentación de la arquitectura.
Grupo 2:
○ Paso 4: Identificar propuestas arquitectónicas.
○ Paso 5: Generar el árbol de utilidad de los atributos de calidad.
○ Paso 6: Analizar las propuestas arquitectónicas.
● Fase 2:
Grupo 3:
○ Paso 7: Lluvia de ideas.
○ Paso 8: Analizar las propuestas arquitectónicas.
Grupo 4:
○ Paso 9: Presentación de los resultados.
● Fase 3: Informe final de la evaluación realizada.
3.3.3 Resultados Metodología ATAM
Aplicando la metodología de ATAM para la evaluación de la arquitectura de software en la cual
se ha desarrollado esta investigación y haciendo énfasis que esta metodología fue complemento
del QAW desarrollado anteriormente se obtiene una lista de escenarios priorizados y las
diferentes propuestas arquitectónicas que los intentan satisfacer, a partir de los cuales se
descubrieron puntos de sensibilidad, de concesión, y riesgos asociados que fueron documentados
en los resultados del QAW en la sección 3.1.1 de este mismo documento.
Las propuestas arquitectónicas son una guía para tomar futuras decisiones, ya que se analizó su
impacto en la arquitectura y se enfoca en los requisitos de calidad que se han definido para el
sistema.
El método resultó muy útil para evaluar la arquitectura de software, se utilizó como un marco de
referencia hacia la metodología propuesta, se modificó y omitió lo que ya se tenía como parte del
59
desarrollo del QAW. Esta metodología permitió un enfoque amplio del sistema pensando en el
largo plazo. Gracias a este enfoque se descubrieron posibles riesgos y oportunidades de mejora.
La metodología de ATAM se debe poder adaptar a las necesidades particulares de cada
negocio/producto de software, manteniendo los aspectos positivos detectados reutilizando los
componentes aplicados.
3.3.3.1 Conjunto de Escenarios Priorizados y Preguntas Asociadas
A. Se deben procesar todos los datos que sean descargados de manera periódica sin importar
el número que se recuperen.
Pregunta: ¿Qué tanta precisión se debe tener en cuenta al momento de hacer el análisis
de sentimientos?
B. Se debe poder modificar los parámetros para la descarga de la información de Twitter de
acuerdo con nuevas tendencias.
Pregunta: ¿Qué tan cambiante son las tendencias de Twitter respecto a temas de salud en
Colombia?
C. A medida que se tenga más información en la base de datos, el sistema podrá clasificar
mejor los datos de la red social, para identificar el sentimiento asociado.
Pregunta: ¿Qué tan grande debe ser la matriz de entrenamiento?
D. Se deben descargar los datos directamente de la plataforma Twitter de acuerdo a los
filtros que se necesiten.
Pregunta: ¿Cada cuanto tiempo se debe ejecutar esta acción?
Pregunta: ¿Será este un proceso automatizado con responsabilidad de ejecución por
parte del sistema operativo?
60
3.3.3.2 Árbol de Utilidad
Tabla 3.11
Árbol de Utilidad resultante de ATAM
Atributo de Calidad Refinamiento del Atributo Escenarios
Escalabilidad ● Integración con
diferentes redes
sociales.
Se deben procesar todos los
datos que sean descargados de
manera periódica sin importar
el número que se recuperen.
A medida que se tenga más
información en la base de
datos, el sistema podrá
clasificar mejor los datos de
la red social, para identificar
el sentimiento asociado
Modificabilidad ● Configuración
Se debe poder modificar los
parámetros para la descarga
de la información de Twitter
de acuerdo con nuevas
tendencias
Desempeño (Performance) ● Tiempo de respuesta
● Latencia
Se deben descargar los datos
directamente de la plataforma
Twitter de acuerdo con los
filtros que se requieran.
La arquitectura de software diseñada y descrita en este documento como un sistema de análisis
de sentimientos para opiniones de usuarios sobre el tema de la salud en Colombia, satisface los
atributos de calidad según el proceso QAW complementado con ATAM anteriormente descrito.
61
4. Observaciones Finales y Recomendaciones
La culminación de este proyecto plantea retos y sobre todo abre el camino para que se siga
trabajando en el contexto del análisis de sentimientos y su aplicación por medio de una
arquitectura de software que pueda ser usada para la aplicación constante de la ingeniería en un
entorno académico, social, publicitario, comercial o industrial.
4.1 Conclusiones
● El proceso del QAW junto con el ATAM dentro del contexto del diseño de arquitectura
de software define sus características y sus objetivos, basados en la definición técnica de
la intención del producto.
● De los diferentes clasificadores analizados y con el análisis realizado de acuerdo con el
contexto del tema salud en Colombia, se obtuvo que el clasificador SVM - Support
Vector Machine, dio mejor resultados al conjunto de entrenamiento obtenido y que es la
base para el posterior análisis de los datos descargados de Twitter, teniendo en cuenta que
las diferentes pruebas realizadas tuvieran resultados lo mayor uniformemente posibles.
● El análisis de sentimientos aplicado en el contexto colombiano en el idioma español
permite la inclusión de la tecnología para resaltar las opiniones de las personas que usan
medios digitales de información y opinión. Desde un punto de vista en ingeniería de
software esta investigación tiene en cuenta elementos teóricos y técnicos que permiten el
modelamiento y diseño una arquitectura que soporte y se ajuste para categorizar en
cuanto a su sentimiento asociado las opiniones de usuarios en la red social Twitter.
● El prototipo funcional basado en la arquitectura de software expuesta en este documento
de investigación es una muestra aplicada de cómo los conceptos de la ingeniería desde su
análisis, modelamiento y organización obtienen resultados que la industria y la academia
pueden seguir involucrando en sus procesos internos y de enseñanza respectivamente,
acorde a los cambios constantes en las herramientas y servicios que se usan y soportan la
construcción de aplicaciones Web interactivas.
● El prototipo funcional como resultado final de esta investigación, es la conjunción de la
teoría investigada en el marco teórico y las diferentes evaluaciones aplicadas a la
arquitectura de software que permiten hacer análisis de sentimientos. La librería externa
NLTK usada de acuerdo con todo el proceso de construcción y evaluación de la
arquitectura descrita en esta investigación, es la expresión misma de la academia en su
contexto de investigación y de la industria con su aplicación en una fuente de datos que
62
permite reconocer la caracterización de las opiniones de usuarios con la prestación del
servicio de salud en Colombia.
4.2 Trabajos Futuros
Con la inclusión de artefactos externos como la conexión con bibliotecas de funciones para
análisis de sentimientos como NLTK del lenguaje de programación Python, los servicios API
REST de la red social Twitter, los servicios en la nube de hosting, y la comunicación con
componentes del prototipo funcional desarrollados a la medida de las características de esta
investigación, se da un paso importante para ampliar el rango de temas y datos que se pueden
extraer de Internet y para los cuales hay un sin fin de aplicaciones e investigaciones venideras
que transforman información desconectada en información coherente y con un sentido de
aplicabilidad en las decisiones a lo que estos datos conllevan.
Los datos fuentes que ayudaron a soportar este proyecto vinieron en particular de una red social,
en Internet existen muchas fuentes de información adicional y por ende el proceso de desarrollo
descrito en esta investigación permitirían el inicio de un observatorio complejo de análisis de
sentimientos sobre los datos compartidos por la sociedad moderna, este observatorio ayudaría a
impactar el esquema de salud Colombiano a la vez que se involucran más conceptos de
arquitecturas de software y metodologías de análisis y desarrollo para este tipo de proyectos
tecnológicos.
La metodología de evaluación desarrollada en este proyecto arrojó resultados concretos sobre el
algoritmo clasificador que mejor se adaptó a la fuente de datos. Con las restricciones que se
tenían como por ejemplo el idioma español y el tema de la salud en Colombia los entrenamientos
que se usaron para los clasificadores y los resultados obtenidos tal vez no sean los mismos si se
alteran las restricciones, por lo cual, se deja abierta la posibilidad de permitir el análisis de
sentimientos en nuevos temas con impactos de medición más cercanos, como lo puede ser las
elecciones presidenciales y su evaluación con respecto a los resultados de la investigación
después de las fechas de votación. Quedan sobre la mesa muy buenas ideas de hacer análisis de
sentimientos si se piensa en los insumos, dado que la arquitectura propuesta y su evaluación a
partir de esta investigación ya están armadas y solo están sujetas a su mejora continua en el
tiempo.
Como parte complementaria a este trabajo de investigación se va a crear un paper basado en este
proyecto de investigación para participar en el 13 Congreso Colombiano de Computación
(13CCC).
63
5. Bibliografía
[1] M. Barbacci, R. Ellison, A. Lattanze, J. Stafford, C. Weinstock, and W. Wood, “Quality
Attribute Workshops (QAWs),” Pittsburgh, PA, 2003.
[2] L. O’Brien, P. Merson, and L. Bass, “Quality attributes for service-oriented
architectures,” in Proceedings of the international Workshop on Systems Development in
SOA Environments, 2007, p. 3.
[3] S. Bird and E. Loper, “NLTK: the natural language toolkit,” in Proceedings of the ACL
2004 on Interactive poster and demonstration sessions, 2004, p. 31.
[4] E. Camacho, F. Cardeso, and G. Nuñez, “Arquitecturas de software: gu{’\i}a de estudio,”
Apr-2004, 2004.
[5] N. V Chawla, “Data mining for imbalanced datasets: An overview,” in Data mining and
knowledge discovery handbook, Springer, 2009, pp. 875–886.
[6] F. M. P. del Arco, M. T. M. Valdivia, S. M. J. Zafra, M. D. M. González, and E. M.
Cámara, “COPOS: corpus of patient opinions in spanish. application of sentiment
analysis techniques,” Proces. del Leng. Nat., vol. 57, pp. 83–90, 2016.
[7] S. Floyd and M. Warmuth, “Sample compression, learnability, and the Vapnik-
Chervonenkis dimension,” Mach. Learn., vol. 21, no. 3, pp. 269–304, 1995.
[8] A. Go, R. Bhayani, and L. Huang, “Twitter sentiment classification using distant
supervision,” CS224N Proj. Report, Stanford, vol. 1, no. 12, 2009.
[9] A. Go, L. Huang, and R. Bhayani, “Twitter sentiment analysis,” Entropy, vol. 17, p. 252,
2009.
[10] T. Joachims, “Text categorization with support vector machines: Learning with many
relevant features,” in European conference on machine learning, 1998, pp. 137–142.
[11] D. Jurafsky and C. Manning, “Natural language processing,” Instructor, vol. 212, no.
998, p. 3482, 2012.
[12] R. Kazman, M. Klein, and P. Clements, “ATAM: Method for architecture evaluation,”
2000.
64
[13] P. Kruchten, “Architectural blueprints—The ‘4+ 1’ view model of software architecture,”
Tutor. Proc. Tri-Ada, vol. 95, pp. 540–555, 1995.
[14] A. Kumar, “Software Architecture Styles: A Survey,” Int. J. Comput. Appl., vol. 87, no.
9, 2014.
[15] V. Labatut and H. Cherifi, “Accuracy measures for the comparison of classifiers,” arXiv
Prepr. arXiv1207.3790, 2012.
[16] E. Loper and S. Bird, “NLTK: The natural language toolkit,” in Proceedings of the ACL-
02 Workshop on Effective tools and methodologies for teaching natural language
processing and computational linguistics-Volume 1, 2002, pp. 63–70.
[17] W. Medhat, A. Hassan, and H. Korashy, “Sentiment analysis algorithms and applications:
A survey,” Ain Shams Eng. J., vol. 5, no. 4, pp. 1093–1113, 2014.
[18] R. Narayanan, B. Liu, and A. Choudhary, “Sentiment analysis of conditional sentences,”
Proc. 2009 Conf. Empir. Methods Nat. Lang. Process. Vol. 1 EMNLP 09, no. August, p.
180, 2009.
[19] C. Potts, “On the negativity of negation,” in Semantics and Linguistic Theory, 2010, vol.
20, pp. 636–659.
[20] M. Richards, Software architecture patterns. O’Reilly Media, Incorporated, 2015.
[21] M. Sokolova and G. Lapalme, “A systematic analysis of performance measures for
classification tasks,” Inf. Process. Manag., vol. 45, no. 4, pp. 427–437, 2009.
[22] F. Solms, “What is software architecture?,” in Proceedings of the South African Institute
for Computer Scientists and Information Technologists Conference, 2012, pp. 363–373.
[23] P.-N. Tan, M. Steinbach, and V. Kumar, “Classification: basic concepts, decision trees,
and model evaluation,” Introd. to data Min., vol. 1, pp. 145–205, 2006.
[24] S. Vijayarani, M. J. Ilamathi, and M. Nithya, “Preprocessing techniques for text mining-
an overview,” Int. J. Comput. Sci. Commun. Networks, vol. 5, no. 1, pp. 7–16, 2015.
