6 DESARROLLO DEL PROYECTO

Se presentan en esta sección del documento los pasos, métodos, técnicas y

herramientas utilizados en la elaboración del proyecto desde fase de investigación
hasta la fase final.

6.1 FASE DE INVESTIGACIÓN

El desarrollo del proyecto inicia a través de una fase de investigación, en la cual el

objetivo es indagar, comparar y aprender sobre diferentes conceptos que pudieran
ser necesarios en la implementación de la herramienta web, conceptos referentes
al tratamiento de datos de la web, herramientas, métodos, técnicas de extracción de
datos y su almacenamiento se postularon como los temas principales de
investigación.
La información es actualmente uno de los bienes más valiosos y preciados en todo
el mundo, esta puede ser generada a través de la correcta interpretación de los
datos obtenidos de diversas fuentes, en este caso el proyecto posee como fuente
de datos la red social Twitter, donde la magnitud de estos aumenta constantemente.
La mayoría de organizaciones buscan como aprovechar la información que circula
en internet, miles de páginas, blogs, journals, todas juntas tienen una cantidad de
información incalculable a la cual con la aplicación de un análisis adecuado y
enfocado en un tema específico puede sacársele un máximo provecho que casi
siempre se traduce a la toma de decisiones fundamentadas por parte de la
organización.
En este caso aprovechando la gigantesca cantidad y calidad de datos proveniente
de las redes sociales y enfocadas en la descripción del problema a tratar, se
realizó una investigación profunda sobre recuperación de datos de redes sociales,
extracción, curación de datos, almacenamiento y métodos por los cuales se
pudieran aplicar o enfocar estos conceptos durante el desarrollo de la herramienta.
La información consultada en esta fase es proveniente de bases de datos
científicas, bibliotecas virtuales y diferentes recursos web, en los cuales se
realizaron las diferentes búsquedas luego de identificar los conceptos importantes
de la investigación y sus palabras clave, teniendo en cuenta las técnicas de
investigación aprendidas y expuestas en diferentes seminarios universitarios.
Este proceso de investigación comenzó en el mes de julio del año 2016, donde
basados en la información recolectada y estudiada desde esa fecha hasta el mes

41
de noviembre del mismo año se realizó la propuesta del presente proyecto, es decir,
es un proyecto que ha tenido un proceso extenso de investigación contemplando
fuentes de información certificadas y catalogadas con información verídica. La fase
de investigación no es un proceso con cierre absoluto, ya que durante las otras
fases, la investigación sigue siendo un factor importante y participativo.

6.2 PLANIFICACIÓN DEL PROYECTO

Posteriormente luego de la fase de investigación se da inicio a la fase de

planificación, donde se especifican las bases del proyecto y se define el camino
correcto a seguir para su implementación, en la planificación se tuvieron en cuenta
todas las posibles actividades y todos los posibles procesos que se requieren para
llevar a cabo el proyecto basados en la investigación realizada hasta el momento.
Una parte esencial de esta fase consistió en el levantamiento de requerimientos
de la herramienta, ya que allí es donde la información del cómo desarrollarla está
ligada totalmente con las necesidades del estudio que en este caso sería nuestro
cliente. Por lo tanto antes de definir los requerimientos de la herramienta, era
necesario definir la metodología de desarrollo a seguir, esto debido a la necesidad
de establecer la mejor manera de realizar el proyecto desde la planificación a la fase
de pruebas, como lo vimos en el marco teórico y en la definición metodológica.
Luego de seleccionada la metodología que en este caso fue el concepto de
programación extrema llamado Personal Extreme Programming, se obtuvo la base
o guía para poder llevar a cabo el levantamiento de requerimientos, el cual como
lo dicta la metodología aplicada debe contener algunas historias de usuario en las
cuales basarse y una especificación formal que se puede encontrar en el documento
de especificación de requerimientos (Véase el Anexo A).
Conjunto a la definición de los requerimientos debemos definir las herramientas
base a utilizar para la construcción de la herramienta, cuestiones como ¿Qué
arquitectura de software es la ideal? ¿Qué lenguaje de programación utilizar en la
codificación? ¿Qué tipo de bases de datos deberían implementarse? ¿Cómo
estarán relacionados los datos dentro del sistema? Y varias más surgen en esta
fase de planificación y se abordan en la siguiente la cual corresponde a la fase de
diseño.

42
6.3 DISEÑO

Al diseñar nosotros podemos aclarar un poco más el concepto que teníamos de la

herramienta al realizar el levantamiento de requerimientos, ya que se contempla la
estructura que tendrá la herramienta desde diferentes aspectos. Al iniciar esta fase
lo primero a definir fue la arquitectura del proyecto, la cual fue definida con el
apoyo del lenguaje unificado de modelado UML, el cual permite modelar la
arquitectura de un sistema por medio de diferentes diagramas enfocados
específicamente en un aspecto funcional o estructural.
En esta fase, con vista a la construcción de la herramienta se han establecido los
siguientes diagramas los cuales se describen teniendo como base el concepto
definido en (Clases et al., 2001)

Diagrama de casos de uso: el cual modela la funcionalidad del sistema

(representa los requerimientos funcionales) y se concentra en plasmar
gráficamente las interacciones con el desarrollo es decir lo que el sistema
puede brindar al usuario.

Diagrama de distribución o despliegue: Este diagrama permite modelar

la arquitectura física de un sistema informático, sus diferentes equipos físicos,
conexiones y también los componentes de software en un nivel muy básico.

Diagrama de componentes: El cual modela la organización de los

diferentes componentes de software del sistema, sus diferentes
dependencias y como se relacionan entre ellos.

Adicionalmente se ha generado un diagrama de procesos BPMN el cual se

encuentra junto con los diagramas de caso de uso y el diagrama de entidad
relación en el documento de especificación de requerimientos de software (Véase
el Anexo A).
A continuación se ilustran y describen los diagramas de distribución y despliegue de
la herramienta de software:

43
6.3.1 Diagrama de Despliegue.

Ilustración 1 - Diagrama de despliegue.

En el diagrama de despliegue podemos apreciar los diferentes componentes

físicos del sistema y que permiten el funcionamiento de la herramienta. Todos juntos
representan la arquitectura física de la herramienta.
Se representa a través de un nodo contenedor el portal gestor de contenidos Liferay
el cual es la plataforma donde la aplicación está alojada, dentro de este nodo se
encuentra otro nodo que representa el ambiente de ejecución o la aplicación en un
contexto de integración. Allí es donde nuestros componentes de software se
encuentran (relevantes), tanto el componente de extracción como los componentes
de los modelos tanto el relacional como el no relacional. Adicionalmente se
presentan los componentes de visualización que en lugar de

44
estar en el mismo entorno de ejecución, está directamente ligado con el gestor
Liferay.
Estos componentes involucrados con el almacenamiento de datos provenientes de
twitter y la herramienta, están conectados con diferentes servidores de bases de
datos, tal como se representa tenemos un servidor de base de datos relacional
donde la base de datos de MySQL almacena los datos propios de la herramienta y
la clasificación de las diferentes cuentas, la cual es generada por los diferentes
usuarios. También se representa el servidor de bases de datos no relacional el
cual contiene la base de datos Mongo que contiene la información de los perfiles
de cada cuenta extraída y sus correspondientes líneas de tiempo las cuales son
un conjunto de estados realizados por la cuenta específica y agrupados en una
sola estructura.

45
6.3.2 Diagrama de Componentes.

Ilustración 2 - Diagrama de componentes.

En el diagrama de componentes podemos detallar los diferentes componentes de

software de nuestra herramienta y como se relacionan en un mismo entorno de
ejecución, adicionalmente a esto vemos la interfaz de inicio de sesión por parte del
usuario la que lleva posterior mente un control establecido por el proceso de
autenticación. Este control verificara el usuario y su rol frente al sistema de allí el
sistema le permitirá ingresar al componente Twitter Parametrization View la vista

46
donde el usuario podrá generar la clasificación de las cuentas deseadas en las
categorías y subcategorías que se definan.
Claramente el componente de vista de extracción, Twitter Extraction View, también
se representa como accesible desde que se realice la autenticación, esto depende
de la actividad que necesite realizar el usuario ya que allí tendrá acceso al
componente que permitirá extraer información de las diferentes cuentas
introduciendo sus identificadores. Como se puede apreciar, este componente está
ligado al componente de modelo de datos no relacionales Twitter Extractor
Model el cual almacenara todos los datos provenientes del componente de
extracción.
Adicionalmente vemos una interfaz de integración con Liferay nuestra plataforma
gestora de contenidos la cual nos permitirá gestionar las interfaces de la herramienta
y se puede ver como el consumo de otro componente externo a la codificación de
la herramienta, ya que el software de la plataforma es un producto o servicio el cual
se decidió utilizar en el presente proyecto.

6.4 DESARROLLO (CODIFICACIÓN)

En la fase de codificación o desarrollo en su expresión máxima, se establecieron

un conjunto de procesos para llevar a cabo la elaboración de cada componente de
software. Lo primero en esta fase fue la definición simple de los componentes, de
tal manera que al inicio se enfocó en las funcionalidades de Extracción,
Almacenamiento relacional y Almacenamiento no relacional, lo que involucró el
repaso de algunos conceptos trabajados en la fase de investigación.
Como primer paso como se planteó en el desarrollo metodológico, se realizó la
construcción de un repositorio privado en GitHub para llevar un control de
versiones en la codificación. Esto nos permite llevar un mejor control durante el
desarrollo de la herramienta.
Conceptos de minería de datos, extracción y almacenamiento de grandes
volúmenes de información fueron la base del desarrollo inicial, sin embargo lo
primero a definir era la forma en la cual se iba a realizar la conexión con la red social
Twitter y a partir de que métodos podría extraer la información necesaria definida
por los requerimientos de la herramienta.
Por lo tanto el primer concepto y parte de desarrollo se basó en la conexión con el
API de Twitter la cual le brinda al desarrollador la oportunidad de crear una
aplicación la cual está ligada directamente con el servidor web de twitter y los
datos de cuentas públicas.

47
Para crear dicha conexión primero se ingresó a la página de comunidad de
desarrollo twitter llamada Twitter Developers, posterior mente se debe crear una
App que simplemente requiere ingresar a una cuenta personal de twitter y
posteriormente introducir alguna información referente a su objetivo y páginas de
acceso.

Ilustración 3 - API de Twitter.

Ilustración 4 - Creación - API de Twitter.

48
Posteriormente se generarán unas llaves de acceso al API y Tokens los cuales
con los códigos con los cuales dentro de la herramienta yo puedo establecer la
conexión con la red social.
Tal cual se define en el estado del arte del proyecto un API es una interfaz que me
da la oportunidad de consumir un servicio web, en este caso la utilización de esta
API nos permitirá consumir el servicio de twitter. Cabe aclarar que para poder
establecer una extracción de datos de la red social no basta solo con crear dicha
conexión con el API. Adicionalmente necesitamos utilizar una herramienta que
ligado al lenguaje de programación nos permitirá desde nuestra aplicación realizar
la conexión pasando las llaves de acceso y Tokens.
En este caso la herramienta fue programada bajo lenguaje Java y por lo tanto la
herramienta seleccionada luego de una previa investigación de métodos, ventajas
y aplicación fue la famosa librería Twitter4j, la cual también nos permite utilizar
métodos de recolección de datos twitter lo que facilita el proceso de extracción ya
que puede generarse de forma específica como lo menciona (Rubira, 2011) esta
herramienta permite gestionar tweets, usuarios, hilos, listas, mensajes directos,
relaciones, favoritos, subscripciones, bloqueos, realizar y guardar búsquedas,
reportar spam y más estructuras que sin lugar a duda proveen al usuario de la
información necesaria para recolectar los datos de cuentas específicas.
Su implementación es realmente sencilla, retomando el ciclo de desarrollo del
proyecto, se decide crear en el IDE Eclipse tres proyectos independientes
(estructura desacoplada) los cuales representarán los componentes principales de
extracción y almacenamiento tanto relacional como no relacional.

Ilustración 5 - Componentes en proyectos

49
Como se puede ver se identifica la sincronización con el repositorio de Github en
el primer componente, en cuanto a los otros dos componentes se puede apreciar
el símbolo de almacenamiento. Esto debido a que se crearon con configuración JPA.

6.4.1 Componente de extracción.

Posteriormente en el componente de extracción twitter-extractor-controller

creamos los paquetes necesarios los cuales están debidamente documentados
con archivos de información (package-info) en este caso uno para la conexión a
través del API de twitter y otro para la clase de extracción.
En el paquete de conexión creamos una clase TwitterConnection, en donde con
ayuda de la librería twitter4j pasamos a la API los datos de acceso generados, los
cuales fueron almacenados y posteriormente pueden ser accedidos para enviar
los diferentes datos de acceso.

Ilustración 6 - Componente de extracción

Al realizar la conexión con el API de Twitter y tener acceso a la red social y a los
métodos que nos provee la librería twitter4j anteriormente agregada al Build Path
del componente de software, se puede iniciar con el proceso de codificación
enfocado a la extracción de datos.
Para definir la funcionalidad, creamos dos clases en el paquete definido para la
extracción (.extraction)

50
Ilustración 7 - Componente de extracción.

Una clase contiene la programación necesaria para extraer la información de cada

cuenta requerida TwitterExtractedDataByAccount, esta clase depende de los
métodos de la otra clase creada en este paquete TwitterExtractorUtilities, esto
debido a que esta última clase tiene los métodos principales de extracción en los
formatos necesarios para que la clase TwitterExtractedDataByAccount los
consuma y genere así un conjunto ordenado de datos provenientes de cada una
de las cuentas de una manera consolidada y más formal.
En cada método de extracción se definen los parámetros requeridos para su
ejecución.

6.4.1.1 Métodos de TwitterExtractorUtilities.

extractTimeline: Método que recibe por parámetros un objeto que

representa la conexión con la red social y una cadena llamada account
name que representa el identificador de la cuenta a la cual se le extraerá
su timeline.

Este genera una lista de estados de cada cuenta los cuales se extraen por
16 páginas cada una con 200 estados propios de la cuenta especificada.
Devolverá la lista tipo Status o un mensaje de error especificando que no
pudo obtenerse el timeline.

51
extractTimelineAndStoreJSON : Método booleano que recibe por
parámetros un objeto que representa la conexión con la red social, una
cadena con la ruta de un archivo JSON generado y una cadena de texto que
corresponde al account name o nombre de la cuenta de twitter a la cual se le
quiere extraer la información en este caso el timeline.

Su funcionalidad consiste en extraer el timeline de la cuenta identificada

con el account name recibido y posteriormente después de convertir estos
datos a formato JSON, y almacenarlos en un archivo de texto plano con el
nombre de la cuenta y que se encuentra en la dirección indicada en la cadena
llamada “filepath”. Devuelve un valor booleano de confirmación.

loadStatusfromJSON : Método que recibe por parámetros un objeto que

representa la conexión con la red social, una cadena con la ruta de un archivo
JSON generado y una cadena de texto que corresponde al file name o
nombre del archivo el cual contiene el timeline de la cuenta en formato JSON.

Su funcionalidad consiste en extraer los estados del timeline de la cuenta

previamente generado y almacenado en un archivo con formato JSON.
Devuelve un objeto tipo Status o un error informativo.
loadStatusesfromJSON: Método que recibe por parámetros un objeto que
representa la conexión con la red social, una cadena con la ruta de un archivo
JSON generado y una cadena de texto que corresponde al file name o
nombre del archivo el cual contiene el timeline de la cuenta en formato JSON.

Su funcionalidad consiste en extraer los estados del timeline de la cuenta

previamente generado y almacenado en un archivo con formato JSON.
Devuelve una lista tipo Status con todos los estados del timeline propio de
la cuenta o un error informativo.

getFollowingUsers: Método que recibe por parámetros un objeto que

representa la conexión con la red social y una cadena llamada account
name que representa el identificador de la cuenta a la cual se le extraerá
una lista con los perfiles de cada usuario seguido por la cuenta, el método
devuelve esta lista o un error informativo.

52
 getFollowers: Método que recibe por parámetros un objeto que representa
la conexión con la red social y una cadena llamada account name que
representa el identificador de la cuenta a la cual se le extraerá una lista con
los perfiles de cada usuario que sigue la cuenta, el método devuelve esta lista
o un error informativo.

getHashTags: Método que recibe por parámetro un objeto tipo status que
representa un estado de una cuenta específica con el cual opera y devuelve
una lista de cadenas de texto con los hashtags realizados en ese estado
específico.

6.4.1.2 Métodos de TwitterExtractedDataByAccount.

initalize: Método que crea la conexión con twitter e inicializa todas las
variables a utilizar en la clase.

TwitterExtractedDataByAccount: Posee tres métodos constructores con

el mismo nombre, uno sin parámetros, uno que recibe el nombre de la cuenta
(accountName) y el otro recibe la ruta de un archivo JSON con el timeline de
alguna cuenta específica y el nombre del archivo, el cual también es el
nombre de la cuenta. Este último método carga de forma automática los
estados de dicha cuenta en una lista tipo status para su posterior operación.
Los tres constructores llaman el método initalize ().

extractTimelineFromTwitter: Método que recibe como parámetro el

nombre de la cuenta (accountName) y utilizando el método de la clase
TwitterExtractorUtilities llamado extractTimeline almacena el timeline en una
lista de tipo status, posteriormente calcula su tamaño y lo guarda en una
variable llamada totaltweets. Retorna un valor booleano que verifica el éxito
o fracaso de su uso.

populateEstructureData: Método que se encarga de generar información

variada del timeline, status y de la propia cuenta y almacena esta información
en diferentes variables.

Primero se define una variable result de tipo booleano que arrojara un valor
dependiendo de si se pudo extraer el timeline de una cuenta específica.

53
 Posteriormente calcula la cantidad de veces que cada estado del timeline
fue citado y almacena este valor en la variable entera totalQuotedTweets,
también calcula el número de retweets obtenidos por cada estado
almacenado en la variable entera totalReTweets.
Luego obtiene los hashtags de cada estado, los cuales son almacenados
en una lista string para la cual se utiliza el método getHashTags de la clase
TwitterExtractorUtilities y también genera listas de perfiles de seguidores y
seguidos donde se implementan los métodos getFollowers y
getFollowingUsers de la clase TwitterExtractorUtilities.

Nota: Los demás métodos consisten en los set y get de cada variable definida
en la clase.

6.4.2 Componente del Modelo de extracción (Base de datos No relacional).

Una vez obtenidos los datos solicitados de las cuentas es necesarios

almacenarlos, para esto se decide utilizar un modelo de datos no relacional debido
a la cantidad y estructura de los datos. El sistema de base de datos seleccionado
para cumplir con este papel fue MongoDB, el cual está orientado a documentos lo
cual se adapta a los datos recolectados los cuales en algunos casos simplemente
podrían ser almacenados directamente en la base de datos pero para poder definir
un modelo con una estructura concreta se ha construido un componente de software
llamado twitter extractor model que permite almacenar información de los perfiles
de cada usuario y también su línea de tiempo ajustada a los límites de utilización
del API mencionados en la descripción del componente de extracción.
Teniendo en cuenta estas funcionalidades a implementar, se construye dentro del
proyecto en el IDE, dos paquetes nuevos (debidamente documentados), donde en
el primero se albergará la clase principal, y en el segundo se crearan tres clases
diferentes.
La primer clase va a definir la estructura del perfil de un usuario, es decir la
información relevante del perfil de cada usuario será extraída y almacenada con la
estructura propuesta en esta clase, la cual se asemeja al concepto de entidad en
bases de datos. Esta “entidad” llevara el nombre de TwitterUserProfile.
La segunda clase será lógicamente será el DAO de esta entidad, la clase
TwitterUserProfileDAO (Data Acces Object) es suministra una interfaz común
entre la aplicación y uno o más dispositivos de almacenamiento de datos. Allí se

54
establece la conexión con la base de datos MongoDB y se declaran las diferentes
operaciones de un CRUD a través de sus métodos.
La tercer clase de este componente representa también un DAO pero en este
caso perteneciente a los timelines extraídos. TwitterUserTimelineDAO es una
clase que permite el almacenamiento de los timelines de cada cuenta y define las
diferentes operaciones de un CRUD a través de sus métodos.
Ilustración 8 - Componente de almacenamiento (No relacional)

A continuación (Véase ilustración 9 Clase TwitterUserProfile) se expone un

fragmento de la clase TwitterUserProfile (entidad), donde se aprecia su estructura
a través de los datos definidos como apropiados para ser parte de un perfil de
usuario.

55
Ilustración 9 - Clase TwitterUserProfile

En cuanto a la clase TwitterUserProfileDAO cabe aclarar que se implementa la

conexión con la base de datos, luego con la colección de perfiles de usuario y se
definen los siguientes métodos, métodos que no serán descritos en detalle ya que
hacen referencia a las operaciones comunes de un CRUD.

Simplemente enfocándonos en los métodos, primero se define un método de

creación de perfil llamado createTwitterUserProfile el cual inserta el perfil
recibido por parámetro en la base de datos.

Luego se definen los métodos de lectura los cuales seleccionan desde la colección
los perfiles solicitados, existe un método que los selecciona por el id del usuario
getTwitterUserProfileById, otro que los selecciona por screenName
getTwitterUserProfileByScreenName y un último método de lectura que
selecciona todos los perfiles de la colección ReadAllTwitterUserProfiles. Los dos
primeros reciben el perfil, el último no recibe ningún objeto o variable por parámetro.

56
En cuanto al método de actualización nombrado updateTwitterUserProfileById, es
un método que recibe por parámetro el perfil a actualizar y el perfil con la información
que se quiere reemplazar. La funcionalidad está en identificar el perfil a actualizar
por el id del objeto y posterior mente eliminarlo e insertar el perfil nuevo con
todos sus nuevos atributos.

Finalmente para los métodos de eliminación al igual que los de escritura se puede
realizar la eliminación por Id, ScreenName o en general eliminar toda la lista de
perfiles estos métodos se nombraron como deleteTwitterUserProfileById,
deleteTwitterUserProfileByScreenName y deleteAllTwitterUserProfiles.

Por otro lado en cuanto a la clase TwitterUserTimelineDAO es una clase que en

cuanto a funcionalidad es muy similar al DAO de perfiles sin embargo esta clase
permite crear una colección por cada timeline extraído, no obstante, si el timeline de
una cuenta ya fue extraído previamente, el DAO no genera una colección
nueva, en lugar de esto se van añadiendo los diferentes timelines en la colección
construida la primer vez que se realizó el almacenamiento.

Los métodos son similares a los de TwitterUserProfileDAO, con la diferencia de

que la mayoría de ellos que realiza operaciones de manera singular reciben como
parámetro un objeto tipo status representante de un estado de una cuenta específica
y también se diferencia en que este DAO no posee método de actualización ya que
debido a que un objeto tipo status tiene una gran cantidad de información que no
tiene sentido modificar, preferiblemente se debe eliminar el estado que presente
algún problema o así lo requiera el usuario.

Adicionalmente los métodos de operaciones masivas como eliminar todos los

timelines o seleccionarlos todos tampoco se tienen en cuenta ya que al realizar estas
operaciones con screenname como parámetro obtendré el mismo resultado para
cada cuenta.

Los métodos de esta clase son los siguientes:

InsertStatusToTwitterUserTimeline – Método de inserción, recibe Status

por parámetro.

getStatusToTwitterUserTimelineById – Método de lectura por id recibe

Status por parámetro (lee un estado del timeline).

getStatusToTwitterUserTimelineByScreenName– Método de lectura por

screenname recibe Status por parámetro (lee un timeline).

deleteSatusToTwitterUserTimelineById– Método de eliminación por id

recibe Status por parámetro (elimina un estado del timeline).

57
 deleteTwitterUserTimelineByScreenName – Método de eliminación por
screenname recibe Status por parámetro (elimina una timeline).

Estas operaciones permiten llevar un control de los diferentes perfiles de cada

cuenta y cada uno de sus timelines y status almacenados en las diferentes
colecciones de la base de datos no relacional.

6.4.3 Componente del modelo de parametrización (Base de datos

relacional).

Por último, el componente de almacenamiento relacional llamado User-

Parametrization-Model, es el componente de software enfocado al modelo de
parametrización y clasificación de cada una de las cuentas en subcategorías y
categorías. Un ejemplo de esta clasificación puede verse representado en la
siguiente ilustración:

Ilustración 10 - Clasificación de cuentas

El componente posee un paquete para las diferentes entidades creadas en este

caso se hace uso del concepto de JPA en java, otro para los diferentes DAO de
cada entidad y sus implementaciones y un último paquete para el Factory de
Mysql el cual es el gestor de bases de datos utilizado en este componente debido
al modelo relacional que representan los datos de las entidades. Externamente en

58
el fichero META-INF se crea una persistencia donde se especifican los datos de
conexión con el gestor (autenticación) y su base de datos

Ilustración 11 - Componente de almacenamiento (Relacional)

Haciendo énfasis en las diferentes entidades de este modelo, cada una tiene
atributos que las identifican y relacionan entre ellas, esta relación puede detallarse
mejor en el diagrama entidad relación (Véase el Anexo A ).

59
Por ahora cabe resaltar el contexto general y las relaciones entre entidades. La
definición de la entidad User o usuario, comprende al individuo que hará uso de la
herramienta, la información de esta entidad será importante a la hora de realizar una
autenticación e indagación sobre las personas con acceso a la herramienta.

Sus atributos se conforman por un identificador único tipo double auto

incrementable, un nombre de usuario y una contraseña (datos de autenticación) tipo
string, un estado el cual se define como estado del usuario en el sistema (1= activo
0= inactivo) tipo integer, y un tipo de usuario el cual representa el rol del usuario en
el sistema, el cual es de tipo string. Los métodos tratados en esta clase son todos
los get y set de cada atributo.

Las operaciones de su DAO se pueden apreciar en la siguiente ilustración:

Ilustración 12 - Métodos de la clase UserDAO.

La implementación de este DAO necesita de la conexión a la base de datos,

utilización del Factory creado y también comprende el concepto de transacciones
para cada operación, además de utilizar objetos como administrador de entidades,
query (consultas) para realizar las operaciones correspondientes y especificadas en
la imagen anterior, en la cual también se aprecia los diferentes parámetros que
reciben.

En cuanto a la entidad Account, se define como la entidad que representa una

cuenta especifica de twitter, a esta entidad se le definieron como atributos un id auto
incrementable de tipo double, un accountname el cual es un string que

60
representa el nombre de la cuenta, un screenname el cual es el identificador de la
cuenta (tipo string), una descripción (tipo string) y un estado que al igual de todas
las entidades sirve para definir su estado en la base de datos (tipo integer).

Las operaciones de su DAO se pueden apreciar en la siguiente ilustración:

Ilustración 13 - Métodos de la clase AccountDAO.

Podemos apreciar las diferentes operaciones y los parámetros que recibe cada
método, crear, leer, actualizar y eliminar, son las operaciones generales y las cuales
varían en cuanto al parámetro de identificación. Adicionalmente se crearon dos
métodos que se relacionan con las entidades Category y Subcategory, obteniendo
a cuál de las categorías y subcategorías definidas pertenece esa cuenta.

La entidad Subcategory, se define como la entidad que representa una subcategoría

especifica definida según los requerimientos funcionales, a esta entidad se le
definieron como atributos un id auto incrementable de tipo double, un
subcategoryname el cual es un string que representa el nombre de la
subcategoría, una descripción (tipo string), una lista de cuentas pertenecientes a la
subcategoría (tipo List<Account>) y un estado que al igual de todas las entidades
sirve para definir su estado en la base de datos (tipo integer).

61
Las operaciones de su DAO se pueden apreciar en la sigu iente imagen:

Ilustración 14 - Métodos de la clase SubCategoryDAO.

Podemos apreciar las diferentes operaciones y los parámetros que recibe cada
método, crear, leer, actualizar y eliminar, son las operaciones generales y las cuales
varían en cuanto al parámetro de identificación. Adicionalmente se crearon dos
métodos que se relacionan con las entidades Category y Account, obteniendo a cuál
de las categorías definidas pertenece y las cuentas que pertenecen a dicha
subcategoría.

Por último la entidad Category, se define como la entidad que representa una
categoría especifica definida según los requerimientos funcionales, a esta entidad
se le definieron como atributos un id auto incrementable de tipo double, un
categoryname el cual es un string que representa el nombre de la categoría, una
descripción (tipo string), una lista de subcategorías pertenecientes a la categoría
(tipo List<Subcategory>) y un estado que al igual de todas las entidades sirve para
definir su estado en la base de datos (tipo integer).

Las operaciones de su DAO se pueden apreciar en la siguiente imagen:

62
Ilustración 15 - Métodos de la clase CategoryDAO.

Podemos apreciar las diferentes operaciones y los parámetros que recibe cada
método, crear, leer, actualizar y eliminar, son las operaciones generales y las cuales
varían en cuanto al parámetro de identificación. Adicionalmente se crearon dos
métodos que se relacionan con las entidades Subcategory y Account, obteniendo
las subcategorías definidas que pertenecen a ella y las cuentas que pertenecen a
dicha categoría también.

En cuanto a los componentes de utilidades y construcción, son componentes

desarrollados previamente por el asesor implicado en el proyecto y en general se
describen como utilidades para la programación de los componentes y sus
diferentes métodos adicionalmente de la construcción automática o despliegue del
entorno en el gestor de contenidos.

63