Post on 02-Jan-2017
UNIVERSIDAD JOSÉ ANTONIO PÁEZ
DESARROLLO DE UNA APLICACIÓN
ENRIQUECIDA DE INTERNET (RIA)
UTILIZANDO HERRAMIENTAS DE GOOGLE
(GWT) PARA LA ADMINISTRACIÓN DE
CUENTAS POR COBRAR Y PAGAR EN LA
DISTRIBUIDORA EL REMENDÓN
Autores:
Huamanciza, Paúl
Cédula: 19.455.808
Rodríguez, Alejandra
Cédula: 20.266.857
Urb. Yuma II, calle N° 3. Municipio San Diego
Teléfono: (0241) 8714240 (master) – Fax: (0241) 8712394
DESARROLLO DE UNA APLICACIÓN ENRIQUECIDA DE INTERNET
(RIA) UTILIZANDO HERRAMIENTAS DE GOOGLE (GWT) PARA LA
ADMINISTRACIÓN DE CUENTAS POR COBRAR Y PAGAR EN LA
DISTRIBUIDORA EL REMENDÓN
Proyecto del Trabajo de Grado para optar al título de
INGENIERO DE COMPUTACIÓN
Autores:
Paúl F. Huamanciza Santillán
Alejandra J. Rodríguez Avila
Tutor: Lcdo. José Canache
San Diego, Enero 2013
REPÚBLICA BOLIVARIANA DE VENEZUELA
UNIVERSIDAD JOSÉ ANTONIO PÁEZ
FACULTAD DE INGENIERÍA
ESCUELA DE COMPUTACIÓN
CARRERA: INGENIERÍA DE COMPUTACIÓN
ACTA DE ACEPTACIÓN DEL TUTOR ACADÉMICO
Quien suscribe, Lcdo. José Canache, portador de la cédula de identidad
N°15.607.108, en mi carácter de tutor del trabajo de grado presentado por los
ciudadanos Paúl Huamanciza, portador de la cédula de identidad N°19.455.808 y
Alejandra Rodríguez, portadora de la cédula de identidad N°20.266.857, titulado
DESARROLLO DE UNA APLICACIÓN ENRIQUECIDA DE INTERNET
(RIA) UTILIZANDO HERRAMIENTAS DE GOOGLE (GWT) PARA LA
ADMINISTRACIÓN DE CUENTAS POR COBRAR Y PAGAR EN LA
DISTRIBUIDORA EL REMENDÓN, presentado como requisito parcial para optar
al título de Ingeniero en Computación, considero que dicho trabajo reúne los
requisitos y méritos suficientes para ser sometido a la presentación pública y
evaluación por parte del jurado examinador que se designe.
En San Diego, Enero de 2013
_____________________________
Lcdo. José Canache
C.I. N°15.607.108
REPÚBLICA BOLIVARIANA DE VENEZUELA
UNIVERSIDAD JOSÉ ANTONIO PÁEZ
FACULTAD DE INGENIERÍA
ESCUELA DE COMPUTACIÓN
CARRERA: INGENIERÍA DE COMPUTACIÓN
v
ÍNDICE GENERAL
CONTENIDO
LISTA DE TABLAS................................................................................................... viii
LISTA DE FIGURAS ...................................................................................................ix
RESUMEN INFORMATIVO.......................................................................................xi
INTRODUCCIÓN ........................................................................................................ 1
CAPÍTULO
I. EL PROBLEMA
1.1– Planteamiento del Problema.......................................................................... 2
1.2– Formulación del problema ............................................................................ 3
1.3– Objetivos de la Investigación ........................................................................ 4
1.3.1– Objetivo General ..................................................................................... 4
1.3.2– Objetivos Específicos .............................................................................. 4
1.4– Justificación................................................................................................... 4
1.5– Alcance .......................................................................................................... 5
II. MARCO TEÓRICO
2.1– Antecedentes ................................................................................................. 6
2.2– Bases Teóricas ............................................................................................... 7
2.2.1– Cuentas por Cobrar.................................................................................. 7
2.2.2– Cuentas por Pagar.................................................................................... 8
2.2.3– Web 1.0 y 1.5 .......................................................................................... 8
2.2.4– Web 2.0 ................................................................................................... 9
2.2.5– RIA ........................................................................................................ 10
2.2.6– GWT ...................................................................................................... 11
2.2.7– Metodologías: OOHDM y OOH4RIA .................................................. 12
2.2.8- ORM ...................................................................................................... 15
2.3– Definición de Términos Básicos ................................................................. 16
III. MARCO METODOLÓGICO
vi
3.1– Tipo de Investigación .................................................................................. 19
3.2– Diseño de la Investigación .......................................................................... 19
3.3– Nivel de la Investigación............................................................................. 19
3.4– Población y muestra .................................................................................... 20
3.5– Técnicas e Instrumentos de recolección de datos........................................ 20
3.6– Análisis de los datos .................................................................................... 20
3.7– Estudio de factibilidad de la propuesta ....................................................... 20
3.7.1– Factibilidad técnica ................................................................................ 21
3.7.2– Factibilidad económica .......................................................................... 21
3.7.3– Factibilidad operativa ............................................................................. 21
3.8– Diseño de la propuesta ................................................................................ 21
3.9– Procedimientos previstos............................................................................. 22
3.10– Fases Metodológicas ................................................................................. 23
IV. RESULTADOS
4.1– FASE I: Realizar el levantamiento de la información del sistema y definir
sus requerimientos…………………………………………………………………...25
4.2– FASE II: Identificar y describir las relaciones de los componentes del
sistema……………………………………………………………………………….27
4.3– FASE III: Diseñar la aplicación siguiendo el modelo RIA con las
metodologías OOHDM y OOH4RIA……………………...………………………..27
4.3.1– Fase de definición del modelo de usuario…………………………….27
4.3.2– Fase conceptual……………………………………………………….27
4.3.3– Fase navegacional…………………………………………………….30
4.3.4– Fase de marcado del modelo de presentación……………………...…31
4.3.5– Fase de definición modelo del dispositivo……………………………31
4.3.6– Fase de interfaz abstracta……………………………………………32
4.3.7– Fase de realización de la transformación de la presentación…………41
4.3.8– Fase de Implementación……………………………………………...43
vii
4.4– FASE IV: Construir los módulos del sistema……………………………..43
4.5– FASE V: Integrar todas las unidades (módulos) del sistema y realizar las
pruebas pertinentes…………………………………………………………………..49
CONCLUSIONES ...................................................................................................... 50
RECOMENDACIONES ............................................................................................. 52
REFERENCIAS .......................................................................................................... 53
Bibliográficas ........................................................................................................... 53
Electrónicas .............................................................................................................. 54
ANEXOS..................................................................................................................... 59
Anexo 1– Diagrama de clases .................................................................................. 60
Anexo 2– Diagrama físico de base de datos ............................................................ 61
Anexo 3– Modelo de Navegación ............................................................................ 62
Anexo 4– Diagrama de estados de cuentas por cobrar............................................. 63
Anexo 5– Diagrama de estados de cuentas por pagar .............................................. 64
viii
LISTA DE TABLAS
TABLA PÁGINA
1 Documento de requerimientos ...................................................................... 27
2 Caso de uso “Iniciar sesión”.......................................................................... 33
3 Caso de uso “Registrar Cuentas por Cobrar/Pagar” ...................................... 34
4 Caso de uso “Gestionar Registros Cliente/Proveedor” ................................. 35
5 Caso de uso “Vincular Persona-Usuario (1)”................................................ 36
6 Caso de uso “Vincular Persona-Usuario (2)”................................................ 37
7 Caso de uso “Registrar persona” ................................................................... 38
8 Caso de uso “Registrar datos de usuario” ..................................................... 39
9 Caso de uso “Registrar datos de cliente/proveedor” ..................................... 40
10 Rendimiento en registro de cuentas por cobrar y pagar ................................ 49
ix
LISTA DE FIGURAS
FIGURA PÁGINA
1 Diagrama de casos de uso (gestor del sistema) ............................................. 28
2 Diagrama de casos de uso (supervisor) ......................................................... 29
3 Diagrama de casos de uso (empleado) .......................................................... 30
4 Modelo de navegación de la aplicación ........................................................ 30
5 Diagrama de estados de cuentas por cobrar .................................................. 31
6 Diagrama de estados de cuentas por pagar.................................................... 32
7 Iniciar Sesión ................................................................................................. 33
8 Registrar Cuentas por Cobrar/Pagar.............................................................. 34
9 Gestionar Registros Cliente/Proveedor ......................................................... 35
10 Vincular Persona-Usuario (1)........................................................................ 36
11 Vincular Persona-Usuario (2)........................................................................ 37
12 Registrar persona ........................................................................................... 38
13 Registrar datos de usuario ............................................................................. 39
14 Registrar datos cliente/proveedor .................................................................. 40
15 Modelo de orquestación Ingresar al Sistema................................................. 42
16 Modelo de orquestación Administrar Cuentas por Cobrar............................ 42
17 Modelo de orquestación Administrar Cuentas por Pagar.............................. 43
18 Creación de un nuevo proyecto de aplicación web – Configuración inicial . 45
19 Selección de estilo de componentes de la aplicación: Clean ........................ 45
20 Vista desde el GWT Designer ....................................................................... 46
21 Configuración de Hibernate – Parte 1 ........................................................... 47
22 Configuración de Hibernate – Parte 2 ........................................................... 47
23 Configuración de Hibernate – Parte 3 ........................................................... 48
24 Consulta con Hibernate (HQL) ..................................................................... 48
x
REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD JOSÉ ANTONIO PÁEZ
FACULTAD DE INGENIERÍA
ESCUELA DE COMPUTACIÓN CARRERA: INGENIERÍA DE COMPUTACIÓN
DESARROLLO DE UNA APLICACIÓN ENRIQUECIDA DE INTERNET
(RIA) UTILIZANDO HERRAMIENTAS DE GOOGLE (GWT) PARA LA
ADMINISTRACIÓN DE CUENTAS POR COBRAR Y PAGAR EN LA
DISTRIBUIDORA EL REMENDÓN
Autores: Paúl Francisco Huamanciza Santillán
Alejandra José Rodríguez Avila Tutor: Lcdo. José Canache Fecha: Enero de 2013
RESUMEN INFORMATIVO
En esta investigación, se tiene como objetivo el desarrollo de una aplicación enriquecida de internet (RIA - Rich Internet Application),
mediante el uso de herramientas de Google (GWT - Google Web Toolkit) para la administración de cuentas por cobrar y pagar en la distribuidora El Remendón, ubicada en San Felipe, estado Yaracuy. Para cumplir con esto,
se siguieron las fases metodológicas: Realizar el levantamiento de la información del sistema y definir sus requerimientos, identificar y describir
las relaciones de los componentes del sistema, diseñar la aplicación siguiendo el modelo RIA con las metodologías OOHDM y OOH4RIA, construir los módulos del sistema, y por último integrar todas las unidades
(módulos) del sistema y realizar las pruebas pertinentes. Concluyendo, se culminó el desarrollo de la RIA exitosamente validando así la propuesta
metodológica presentada. Descriptores: Rich Internet Application, Google Web Toolkit, OOH4RIA, cuentas
por pagar, cuentas por cobrar.
1
INTRODUCCIÓN
Actualmente se vive en un mundo con una constante y acelerada evolución, en el
cual se precisa ir cambiando los métodos para llevar a cabo las operaciones en las
empresas, sean grandes o pequeñas. Para este proyecto en particular, la distribuidora
El Remendón es una pequeña empresa que constituye el foco principal en la dirección
de la investigación. En esta empresa, todas las operaciones se realizan de forma
manual ocasionando poca organización, grandes tiempos de respuestas y cansancio
del recurso humano disponible en actividades que no están relacionadas directamente
con su función. En este trabajo se presenta una propuesta de una RIA (Rich Internet
Application) para la ejecución optimizada de los procesos seleccionados como
muestra, cuentas por cobrar y pagar, en la distribuidora El Remendón.
En el capítulo I, Planteamiento del Problema, se describe la problemática a
solventar en la distribuidora El Remendón, se establecen los objetivos generales y
específicos, además de la justificación de la investigación.
En el capítulo II, Marco Teórico, se presentan los antecedentes de este trabajo que
son investigaciones relacionadas al mismo y se muestra la teoría correspondiente al
entendimiento de los conceptos que conforman el desarrollo de las RIA, la web 2.0, y
metodologías de desarrollo, como lo son OOHDM y OOH4RIA.
En el capítulo III, Marco Metodológico, se determina el tipo de investigación, su
diseño y nivel; los procesos que constituyen la población y muestra, las técnicas de
recolección de datos y el análisis de los mismos, las factibilidades técnica, económica
y operativa, así como el diseño de la propuesta, los procedimientos previstos y las
fases metodológicas para el desarrollo de la aplicación.
Por último, en el capítulo IV, Resultados, se expone cada producto de las fases
metodológicas seguidas para el desarrollo de la aplicación, y su documentación
correspondiente.
CAPÍTULO I
EL PROBLEMA
1.1– Planteamiento del Problema
Una empresa es una organización que satisface ciertos bienes y servicios que
demanda una sociedad, además de ser una fuente generadora de empleos. Según
Thompson (2007):
La pequeña empresa es una entidad independiente, creada para ser
rentable, que no predomina en la industria a la que pertenece, cuya venta anual en valores no excede un determinado tope y el número de personas que la conforma no excede un determinado límite, y como toda empresa,
tiene aspiraciones, realizaciones, bienes materiales y capacidades técnicas y financieras, todo lo cual, le permite dedicarse a la producción,
transformación y/o prestación de servicios para satisfacer determinadas necesidades y deseos existentes en la sociedad.
La clasificación del tamaño de la empresa, varía de país a país ya que el uso de
calificativos como “pequeño”, “mediano” o “grande” son bastante relativos. En
Venezuela, una pequeña empresa posee un promedio anual de entre 5 a 50
trabajadores y ventas anuales en unidades tributarias entre 1.000 y 1.000.000. Este
esquema está establecido por el Decreto N° 6.215, con Rango, Valor y Fuerza de Ley
para la Promoción y Desarrollo de la Pequeña y Mediana Industria y Demás Unidades
de Producción Social de 2008, y la denomina como Pequeña y Mediana Industria.
Este decreto también establece el concepto de Unidad de Propiedad Social, el cual
está comprendido por asociaciones de carácter participativo tales como las
cooperativas, consejos comunales, unidades productivas familiares, o cualquier otra
asociación que surja en la comunidad y realice actividades económicas de forma lícita
y prevalezca el beneficio colectivo sobre la producción de capital y distribución de
beneficios de sus miembros.
3
La Distribuidora El Remendón es una pequeña empresa ubicada en la 4ta Avenida,
entre calles 18 y 19, Parroquia Albarico, Municipio San Felipe, Estado Yaracuy
dedicada a la distribución de materiales de zapatería y tapicería. Esta empresa
requiere la optimización de la administración de sus procesos de cuentas por cobrar y
pagar que actualmente se llevan de forma manual en cuadernos, ocasionando poca
organización, grandes tiempos de respuestas y cansancio del recurso humano
disponible en actividades que no están relacionadas directamente con su función.
Las cuentas por cobrar, son los derechos que posee una empresa sobre personas
pendientes de cobro en una determinada fecha, pudiendo ser las personas naturales, o
jurídicas. Según Chambi, G, “El objetivo de las cuentas por cobrar es proporcionar
información cuantificada referente al monto total de recuperaciones pendientes de
cobro a terceras personas naturales y/o jurídicas por operaciones normalmente del
giro específico de una empresa”. Se presupone que dichos derechos serán cobrados en
los próximos 12 meses (a corto plazo).
Luego, está el pago de cuentas por pagar. Según González, J, “Las Cuentas por
Pagar surgen por operaciones de compra de bienes materiales (Inventarios), servicios
recibidos, gastos incurridos y adquisición de activos fijos o contratación de
inversiones en proceso”. Si estas cuentas se pagan antes de transcurridos 12 meses de
su compra, son cuentas por pagar a corto plazo y si su vencimiento es mayor a los 12
meses de su compra, cuentan como cuentas por pagar a largo plazo.
Es poco práctico llevar control de operaciones de forma manual, sobre todo
porque éstos documentos podrían traspapelarse y entonces la organización entera
estará propensa a olvidar ciertas fechas importantes para el pago de servicios que le
son prestados a diario, dando como resultado el vencimiento de plazos de pago,
vencimiento de fechas límites, cargos por mora y demás cobros que disminuyen las
ganancias y llevan a pérdidas.
1.2– Formulación del problema
¿Cómo optimizar la administración de cuentas por cobrar y pagar en la
Distribuidora El Remendón?
4
1.3– Objetivos de la Investigación
1.3.1– Objetivo General
Desarrollar una RIA (Rich Internet Application) para la administración de cuentas
por cobrar y pagar en la Distribuidora El Remendón utilizando GWT (Google Web
Toolkit).
1.3.2– Objetivos Específicos
Realizar el levantamiento de la información del sistema para definir sus
requerimientos.
Identificar y describir las relaciones de los componentes del sistema.
Diseñar la aplicación siguiendo el modelo RIA con las metodologías
OOHDM y OOH4RIA.
Construir los módulos del sistema.
Integrar todas las unidades (módulos) del sistema y realizar las pruebas
pertinentes.
1.4– Justificación
Es difícil llevar de forma manual un control completo y específico de todas las
cuentas por cobrar y pagar, además de que en cada uno de ellos se tienen
características que pueden olvidarse o perderse estando en físico o en el pensamiento
de los encargados.
Cambiando el método manual a automatizado, se dispondrá de más tiempo en la
planificación de más actividades con menos esfuerzo laboral por parte de los
encargados, o ser más eficientes en las que ya existen, así como la mínima pérdida y
la optimización de pagos y cobros.
Hoy en día, se plantea un esquema de manejo para los mismos, llamada web 2.0,
que permite la interacción de las partes interesadas a través de internet. Este esquema,
viene practicándose en el mundo de las empresas para llevar sus controles de
ganancias, pérdidas, pagos y deudas colocando esa información crucial en un sitio en
5
donde todos los involucrados puedan actualizar los datos de las mismas facilitando
muchos procesos que se han venido llevando a cabo durante los últimos años.
Con el nacimiento de las Rich Internet Application (RIA), se tienen los beneficios
de las aplicaciones web y las aplicaciones tradicionales, a través de un navegador web
donde se carga primero toda la aplicación y sólo se comunicará con el servidor
cuando se necesitan datos externos a la aplicación. El uso de las RIA trae beneficios,
entre ellos que no es necesario instalar la aplicación ya que puede correr a través de
cualquier navegador web, las actualizaciones de la aplicación son automáticas,
además de mayor capacidad de respuesta ya que se interactúa directamente con el
servidor y funcionalidades asíncronas (no hay necesidad de recargar la página). El
manejo de los documentos de pequeñas empresas a través de la web, sugiere una
descentralización de los mismos ya que todas las partes estarán en contacto constante
para realizar las distintas operaciones de pago, control de los proveedores y clientes,
así como otros servicios varios, de la pequeña empresa.
1.5– Alcance
La problemática que se planea solventar es la optimización de la administración de
las cuentas por cobrar y pagar en la distribuidora El Remendón a través de una RIA
elaborada para tal fin, mediante el uso de la GWT, Hibernate y MySQL
principalmente.
CAPÍTULO II
MARCO TEÓRICO
2.1– Antecedentes
Para la elaboración de esta investigación, se hizo necesario revisar estudios
anteriores que estuviesen relacionados con el tema tratado actualmente. Un
antecedente, es todo aquel trabajo que precede a la investigación que se está
realizando y contribuyen en cierta manera con la misma. Entonces, algunos de ellos
son:
En el trabajo de Murillo, H. y Riera, M. (2010) titulado “Análisis de la
Plataforma RIA GWT para Desarrollo en Ajax para el Departamento de
Recursos Humanos de la Refinería Estatal de Esmeraldas” desarrollado en la
Escuela Superior Politécnica de Chimborazo, Ecuador se publica un proyecto para el
análisis, diseño, desarrollo, e implementación de aplicaciones web de empresas
públicas, mediante la utilización del GWT como un Framework de desarrollo en Java
de código abierto que rompe el esquema del modelo clásico para escribir aplicaciones
Ajax y JavaScript; en donde además se expone que con GWT se puede desarrollar y
depurar aplicaciones en Ajax usando Java como lenguaje de programación. El
proceso práctico es resumido en completar el código de la aplicación, compilarlo
utilizando GWT, lo cual traduce a JavaScript y HTML siendo compatible con
cualquier navegador. De dicho proyecto se toman en consideración el análisis
comparativo entre las diferentes IDEs y extensiones compatibles para el desarrollo de
una RIA, los procedimientos a seguir para generar sus entregables, y los diferentes
manuales generados.
El trabajo de investigación de Meliá, S., Martínez J., Pérez, A. y Gómez, J. (2009)
titulado “OOH4RIA Tool: Una Herramienta basada en el Desarrollo Dirigido
por Modelos para las RIAs”, realizado en la Universidad de Alicante, España, se
7
introduce una nueva herramienta para el desarrollo de RIAs llamada OOH4RIA tool
que es un extensión para el entorno de programación de Eclipse, destinada a facilitar
y optimizar el tiempo para desarrollar aplicaciones con el framework Google Web
Toolkit. La OOH4RIA Tool será utilizada para acelerar la creación de los modelos
de dominio, relaciones, navegación, y de objetos para el presente proyecto de
investigación.
Por último, en el trabajo de investigación de Meliá, S., Gómez, J., Pérez, S. y
Díaz, O. (2008), titulado “Facing Interaction-Rich RIAs: the Orchestration
Model” y realizado entre la Universidad de Alicante, España, y la Universidad de
Basque Country en San Sebastián, también en España se describe profundamente lo
que es el Modelo de Orquestación en cada una de sus etapas, lo cual conforma una
parte importante del desarrollo de las RIA utilizando GWT ya que es aquí cuando se
describen las interacciones de los elementos del sistema, sus dependencias además de
determinar qué elementos se agruparán en páginas AJAX. Todo esto se hace con las
transiciones orquestales y los estados orquestales. Este trabajo es una pieza clave en
el desarrollo de la aplicación ya que el modelo de orquestación hace posible la
diferenciación de las diferentes etapas y elementos del sistema, lo cual se hace
necesario en el desarrollo de la RIA, por lo que se tomará en consideración.
2.2– Bases Teóricas
2.2.1– Cuentas por Cobrar
Las cuentas por cobrar (o activos) representan los derechos exigibles que tiene una
empresa por los bienes o servicios que ha vendido, cuyo pago puede ser a corto o a
largo plazo. Las cuentas por cobrar comprenden todo aquello que esté por cobrar
siempre y cuando no haya evidencia de pagarés u otros instrumentos similares.
Para la presentación de estados financieros, las cuentas por cobrar pueden ser
circulantes (a corto plazo, hasta 12 meses después de realizada la venta), o fijas (a
largo plazo, o más de 12 meses). Las cuentas por cobrar se clasifican en:
8
Cuentas por cobrar al cliente: Son los acuerdos de los clientes con la
empresa, que concuerda con el monto de la venta realizada.
Cuentas por cobrar a funcionarios y empleados: Son los montos que
acuerdan los funcionarios y los empleados de la empresa, y corresponden con
conceptos de ventas a crédito, anticipos de sueldos y otros, los cuales al final
se descuentan de su salario.
Otras cuentas por cobrar: Son sobre acontecimientos que puedan surgir,
tales como anticipos, compras y daños o pérdidas, entre otros.
2.2.2– Cuentas por Pagar
Las cuentas por pagar (o pasivos), representan las deudas que una empresa se
compromete a pagar, por cualquier concepto. A esto, es aplicable también lo de corto
y largo plazo: las cuentas por pagar a corto plazo son aquellas que se pagan en los 12
meses de adquirida la deuda, y las de largo plazo son las que se pagan luego de
cumplidos los 12 meses. Las cuentas por pagar pueden clasificarse según su
naturaleza de la siguiente manera:
Cuentas por pagar a proveedores: Pasivos que deben de pagársele a los
proveedores.
Cuentas por pagar a accionistas y socios: Pasivos que corresponden al pago
de cuentas a accionistas y socios.
Sueldos y prestaciones: Dirigidos a los empleados de la empresa.
Cuentas por pagar a otros acreedores: Pasivos que no encajan en ninguna
de las clasificaciones anteriores.
2.2.3– Web 1.0 y 1.5
La web 1.0, conocida como la “web estática” es un estado de la World Wide Web,
estuvo en su mayor apogeo entre los años 1991 y 1997, y consiste en páginas cuyo
contenido es de sólo lectura, de únicamente textos bastante rápidos y animaciones
GIF. Esto surgió con la creación el HTML (HyperText Markup Language), que hizo
las páginas básicas sitios más agradables y cómodos a la vista. Como el contenido de
9
la web 1.0 es de sólo lectura, el usuario no podía interactuar con el mismo, como se
hace actualmente en la web 2.0, la información no es dinámica y sólo el webmaster o
dueño del sitio podía actualizarla (centralización del contenido). La web 1.0 sólo se
concentra en presentar contenidos, no crearlos.
La web 1.5 (1997-2004), conocida como la “web dinámica” surgió con la
integración del CSS (Cascade Style Sheet) con el que se pudo “ornamentar” y darle
aspecto más agradable a las páginas de la anterior web 1.0, conjuntamente con el uso
de DHTML (Dynamic HyperText Markup Language). Una característica de la web
1.5 es, que el contenido de las páginas es construido a partir de una o varias bases de
datos, que facilitan inclusive su actualización o el cambio de diseño de ellas
(descentralización del contenido). El usuario empezó a interactuar con las páginas
web en la 1.5, aunque debe recargar la página si espera observar un comportamiento
distinto, cuestión en la cual los usuarios hoy en día se han vuelto más exigentes, y
prefieren la actualización automática del contenido cuando interactúan con él.
2.2.4– Web 2.0
La web 2.0 (2004-presente) es conocida como “web colaborativa” ya que los
usuarios ayudan a construir el contenido de las mismas. Los cambios que se realizan
se ven reflejados automáticamente ya que se utilizan Ajax, XML, entre otras
tecnologías que permiten hacer contacto con el servidor sin tener que realizar un
refrescamiento de la página propiamente dicho, sólo se realiza en el sector del
contenido con el que el usuario haya interactuado, de manera asíncrona. Algunos
ejemplos de la web 2.0 son comunidades web, servicios web, aplicaciones web, las
redes sociales, servicios de alojamiento de videos, wikis, blogs, mashups y
folksonomías. Ciertas características de la web 2.0 son:
Uso de AJAX
Uso de Java Web Start
Algunos aspectos de redes sociales
Mashups
10
Otras característica importante de la web 2.0 es el hecho de que los usuarios son
quienes controlan la información que comparten en la misma. La web 2.0 ha
permitido la integración de personas de todas partes del mundo al mundo de la
Internet en la publicación de contenidos por lo cual ha representado un gran avance
tecnológico.
2.2.5– RIA
Una RIA, o “Rich Internet Application” (traducido por algunos autores como
“Aplicaciones de Internet Enriquecidas” y por otros como “Aplicaciones de Internet
Ricas”, aunque no define fielmente lo que la definición original realmente quiere
decir) es un nuevo paradigma de desarrollo de aplicaciones web con propiedades de
las aplicaciones de escritorio. El término Rich Internet Application, fue introducido
por Macromedia en el año 2002 (ahora fusionada con Adobe), aun cuando este
término ha existido anteriormente bajo los nombres de:
Remote Scripting, por Microsoft en 1999
X Internet, por ForresterResearch en el año 2000
Rich Web Clients
Rich Web Application
Estas aplicaciones corren a través de un navegador, estando disponibles en internet
o en intranet, complementos o plug-ins o en máquinas virtuales. Las RIA buscan
mejorar la experiencia del usuario a la hora de realizar sus operaciones, ofreciendo la
posibilidad de que todas las partes involucradas colaboren en el proceso desde
cualquier parte (ya esto depende si la aplicación está disponible en internet o sólo en
intranet). Algunos de los beneficios de las RIA son:
No necesitan instalación (solo es necesario mantener actualizado el navegador
web).
Las actualizaciones hacia nuevas versiones son automáticas.
Se pueden utilizar desde cualquier ordenador con una conexión a Internet sin
depender del sistema operativo que éste utilice.
11
Mejor capacidad de respuesta, ya que el usuario interactúa directamente con el
servidor, sin necesidad de recargar la página.
Ofrecen aplicaciones interactivas que no se pueden obtener utilizando
solo HTML, cálculos en el lado del cliente sin la necesidad de enviar la
información al servidor.
2.2.6 – GWT
Google Web Toolkit, mejor conocido como GWT, es un entorno bajo en software
libre, basado en Java y que permite crear aplicaciones en AJAX. Una vez escritas las
aplicaciones en Java, se encarga de compilarlas, y entonces lo traduce a JavaScript,
HTML y CSS. La creación de aplicaciones con este entorno permite crear RIAs
utilizando AJAX a través de un conjunto de herramientas y widgets. La interfaz se
hace en Java, como se hace al crear una aplicación Swing.
Luego de haber creado la aplicación en Java, según Jalali, J (2011), “El
compilador de GWT genera Javascript a partir de las clases Java que escribimos y la
GWT Class Library, que es un JRE optimizado para la traducción a Javascript. Esta
optimización consiste, básicamente, en utilizar un subconjunto de tipos del JRE.”
Para cada navegador, se genera un código JavaScript distinto, ya que el compilador
de GWT conoce las particularidades de cada navegador, además de que el código
JavaScript puede generarse por cada navegador o idioma que se defina. Además, una
aplicación de este tipo no sólo puede crearse en Java, sino también en PHP, Python, y
Ruby.
En cuanto a su arquitectura, GWT tiene cuatro componentes principales según
Blanco, E (2011) que lo componen, siendo:
Java-to-JavaScriptCompiler: Traduce el código de Java a Javascript
compatible con los navegadores más utilizados.
Hosted Web Browser: Ejecuta la aplicación Java sin traducirla al Javascript.
Es decir, lo hace en modo host, usando la máquina virtual de Java (JVM).
12
JRE Emulation Library: Contiene las librerías que son más importantes de
las clases de Java.
GWT Web UI Class Library: Este último componente contiene elementos
básicos de la interfaz de usuario para la creación de textos, imágenes, botones
y otros diversos widgets.
2.2.7– Metodologías: OOHDM (Método de Diseño Hipermedia Orientado a
Objeto) y OOH4RIA
Ambas metodologías, tanto la OOHDM como la OOH4RIA están enfocadas al
desarrollo de aplicaciones en navegadores. OOH4RIA está íntimamente relacionada
con Google Web Toolkit (GWT) ya que esta metodología se desarrolló
específicamente para el desarrollo de las RIA.
Aun cuando se trabajará en base a estas dos metodologías de forma
complementaria (ya que la OOH4RIA sólo se enfoca hacia la elaboración de las RIA
mediante GWT), la OOH4RIA se basa en la OOHDM, que es una metodología
desarrollada por D. Schwabe, G. Rossi y D. J. Barbosa. La metodología OOHDM
consta de las siguientes fases:
Fase conceptual: Se construye un diagrama conceptual de lo que son los
objetos, las clases y las relaciones, así como las colaboraciones existentes
entre ellos. Es también en esta etapa cuando se incluirán además la definición
de los actores del sistema, las tareas que realiza cada uno al utilizarlo y los
escenarios del sistema. El diagrama que incluye los objetos, las clases y las
relaciones es un diagrama de clases.
Fase navegacional: En esta metodología, se usarán dos esquemas: el
esquema de clases navegacionales (estructurado en nodos, enlaces y
estructuras de acceso) y el esquema de contextos navegacionales.
Normalmente se definen los menús y submenús de la aplicación. Los nodos,
enlaces y estructuras de acceso establecerán la ruta que se podrá seguir para
que el usuario pueda moverse dentro de la aplicación.
13
Fase de interfaz abstracta: En esta fase, básicamente lo que se hace es
definir la interfaz de la aplicación y la manera en que los elementos van a
aparecer, buscando siempre que sea ergonómico, de manera que le sea
cómodo y agradable al usuario mientras se mueve por la RIA. También se
definirán las transformaciones de la interfaz y los cambios que la misma hará
mientras la aplicación es usada. El diseño navegacional y el de la interfaz
abstracta deben ser lo más independiente que se pueda.
Fase de implementación: En esta última fase, se desarrollarán todos los
ítems anteriores usando un lenguaje de programación a preferencia del
programador, tomando en cuenta el entorno en que se va a correr la
aplicación.
La OOH4RIA, por su parte, consta de cuatro fases, las cuales son:
Definir el modelo de usuario: Contiene las variables de usuario y de
contexto. Se recolecta información con respecto a las características,
preferencias e intereses del usuario.
Marcar el modelo de presentación: Luego de haber recolectado la
información, el diseñador debe marcar el modelo producto de la fase anterior,
para reorganizar todos los elementos. Se define un nuevo modelo de
presentación marcado por cada nuevo tipo de mecanismo o subsistema que se
agregue. Todos estos modelos juntos, con el modelo de datos del sistema
guiarán a las reglas de transformación, que modificará la manera en que los
elementos estarán organizados espacialmente y transformar los widgets de un
tipo a otro de ser necesario. Para permitir que el diseñador haga estos
marcajes, el metamodelo del modelo de presentación es extendido; cada panel
tendrá un nuevo atributo llamado “Locación”, el cual indicará si el panel será
puesto en una nueva pantalla o en una ya existente, por ende, el atributo
locación puede tener diferentes valores como son:
14
o inherits: Este valor es el que viene por defecto en todos los paneles,
los cuales están anidados y serán puestos en la misma pantalla de su
panel padre a menos que el diseñador indique lo contrario colocándole
otro tipo de dato.
o new: En este caso el diseñador está especificando que el panel
aparecerá en otra pantalla.
o none: Se asigna cuando el diseñador quiere excluir el panel para que
no sea visible en la aplicación final.
o all: Se asigna este valor cuando se quiere incluir ese panel en todas las
pantallas de la aplicación objetivo.
o containerID: Este valor denota otro panel en específico, que debería
anidarse con el panel actual.
Definir el modelo de dispositivo: Con el fin de hacer frente a la
personalización a nivel de widget, la personalización de diseño selecciona
asignaciones de widget a partir de un conjunto predefinido de asignaciones,
creando instancias de ellos, complementándolos con los detalles necesarios
para el modelo de presentación específica (por ejemplo, la altura y el ancho de
un elemento). Si es necesario, se puede definir una nueva asignación de
widget personalizada. Esto se traduce en varios conjuntos de asignaciones,
cada uno apuntando a un dispositivo de tipo específico. Cada asignación
especifica la conversión de un widget (tipo) a otro widget, dándole una
funcionalidad similar en el dispositivo destino.
Realizar la transformación de personalización: Se realizan las
modificaciones utilizando el Modelo de Orquestación. Este modelo captura
las dependencias de interacción a través de los widgets, aunque no todas las
widgets pueden ser orquestadas. La orquestación se modela a través de
comportamiento de máquinas de estado de UML. Para capturar las
funcionalidades y dependencias en el modelo de orquestación, se introducen
15
las llamadas Transiciones Orquestales y Estados Orquestales. Las transiciones
orquestales se refieren a los comportamientos que pudieran originarse, y son
disparadas por eventos (los cuales los define el diseñador). Los estados
orquestales se refieren a estados en los que puede entrar el sistema, dependen
de la aplicación que se esté realizando por lo que no hay un estándar
propiamente dicho. Por ejemplo, si la aplicación fuese un servicio de correos,
los estados serían: alerta, confirmación, solicitar y seleccionarDesdeRango.
La metodología entonces a usar será un híbrido entre estas dos porque se
complementan aun cuando una proviene de la otra. Los pasos que se llevarán a cabo
serán:
Fase de definición del modelo de usuario
Fase conceptual
Fase navegacional
Fase de marcado del modelo de presentación
Fase de definición modelo del dispositivo
Fase de interfaz abstracta
Fase de realización de la transformación de la presentación
Fase de Implementación
Así, con esta propuesta, se espera poder lograr de manera adecuada y completa el
desarrollo de la aplicación de internet enriquecida usando Google Web Toolkit.
2.2.8 – ORM
El Mapeo Objeto-Relacional (ORM del inglés Object Role Modeling) es un
método para realizar y consultar modelos de bases de datos a nivel conceptual. A
diferencia de los diagramas de entidad-relación y el lenguaje UML, en ORM todos
los hechos se consideran como relaciones. Un hecho es la definición de cómo dos o
más entidades se relacionan. El ORM utilizado es Hibernate.
Hibernate, es una herramienta ORM para la plataforma Java que facilita el mapeo
de atributos entre una base de datos relacional y el modelo de objetos de una
16
aplicación, mediante el uso de archivos declarativos en XML. Es software libre, y
está distribuido bajo la licencia GNU LGPL. Hibernate, manipula los datos de la base
de datos operando sobre objetos. Esto se logra cuando el desarrollador detalla cómo
es su modelo de datos, qué relaciones existen y qué forma tienen.
Hibernate también ofrece su propio lenguaje de consulta llamado HQL (Hibernate
Query Language), que es orientado a objetos, a diferencia del SQL permitiendo usar
propiedades como la herencia y polimorfismo.
2.3– Definición de Términos Básicos
AJAX: Acrónimo de Asynchronous JavaScript and XML (JavaScript y XML
asíncronos), es una técnica de desarrollo web mediante la combinación de tres
tecnologías ya existentes: HTML (o XHTML) y Hojas de Estilo (CSS) para presentar
la información; Document Object Model (DOM) y JavaScript, para interactuar
dinámicamente con los datos, y XML, para intercambiar y manipular datos de manera
asíncrona con el servidor web.
Cuentas por Cobrar: Es la suma de dinero que corresponde a la venta de
mercancías, o la prestación de servicios a crédito a un cliente.
Cuentas por Pagar: Son obligaciones presentes provenientes de las operaciones de
transacciones pasadas tales como la adquisición de mercancías o servicios o por la
obtención de préstamos para el financiamiento de los bienes que constituyen el
activo.
Eclipse IDE for Java EE Developers: Es un espacio de trabajo para el desarrollo
para el lenguaje de programación Java.
Folcsonomía: También conocido como folksonomía, son conjuntos de términos
(tags) del lenguaje natural empleados para describir el contenido de un documento o
recurso Web.
Framework: Se refiere a “ambiente de trabajo, y ejecución”. En general los
framework son soluciones completas que contemplan herramientas de apoyo a la
construcción (ambiente de trabajo o desarrollo) y motores de ejecución (ambiente de
ejecución).
17
GWT (Google Web Toolkit): Es una serie de herramientas de desarrollo escritas en
la tecnología Java cuya finalidad es asistir en el desarrollo de aplicaciones web
complejas y optimizadas. Brinda la posibilidad de crear interfaces de usuario muy
complejas escritas completamente en Java utilizando una colección de
controles/widgets que están integrados en las librerías del GWT.
IDE (Integrated Development Environment): Un entorno de desarrollo integrado
es una aplicación de software que proporciona servicios integrales a los
programadores para el desarrollo de software. Una IDE normalmente se compone de:
Un editor de código fuente, un compilador y/o un intérprete, automatización de
generación de herramientas y un depurador.
Mashup: es un sitio web o aplicación web que usa contenido de otras aplicaciones
Web para crear un nuevo contenido completo, consumiendo servicios directamente,
siempre a través de protocolo http.
Metamodelo: Modelo de información con el que se describen las categorizaciones,
correspondiente a niveles de conceptualización del sistema.
RPC (Remote Procedure Call): La llamada a procedimiento remoto es un
mecanismo por el que dos procesos se pueden comunicar entre sí. Este mecanismo
habilita el intercambio de datos y permite solicitar funcionalidades residentes en otros
procesos. Dichos procesos pueden residir en el mismo equipo, en una red local o en
internet, es decir que en resumidas cuentas, este servicio permite que las aplicaciones
de nuestro equipo puedan comunicarse con el sistema operativo y entre sí.
Standalone: Una aplicación de este tipo es aquella que corre directamente sobre un
ordenador, generalmente se trata de un software que se ejecuta una vez instalado en el
equipo.
UML (Unified Modeling Language): Se trata de un lenguaje gráfico para construir,
documentar, visualizar y especificar un sistema de software.
Widget: Es un elemento de una interfaz gráfica de usuario (o GUI) que muestra
información con la cual el usuario puede interactuar.
18
Wiki: (del hawaiano wiki, 'rápido') es un sitio web colaborativo que puede ser
editado por varios usuarios. Los usuarios de una wiki pueden así crear, editar, borrar
o modificar el contenido de una página web, de una forma interactiva, fácil y rápida.
CAPÍTULO III
MARCO METODOLÓGICO
3.1– Tipo de Investigación
Esta investigación se clasifica como factible, ya que implica el desarrollo de un
producto. Según Arias, F (2006), un proyecto factible es una “Propuesta de acción
para resolver un problema práctico o satisfacer una necesidad. Es indispensable que
dicha propuesta se acompañe de la demostración de su factibilidad o posibilidad de
realización.”
3.2– Diseño de la Investigación
Según Arias, F (2006), “El diseño de investigación es la estrategia que adopta el
investigador para responder al problema planteado.”. El diseño de esta investigación,
según la misma fuente, es de campo, ya que “consiste en la recolección de datos
directamente de la realidad donde ocurren los hechos, sin manipular o controlar
variable alguna”. Para esto, se realiza un guión o modelo que permite explicar la
realidad de la problemática en estudio, en el que se determinan los actores y las
diferentes interacciones de ellos con dicha problemática.
3.3– Nivel de la Investigación
Según Arias, F (2006), “El nivel de investigación se refiere al grado de
profundidad con que se aborda un objeto o fenómeno. Aquí se indicará si se trata de
una investigación exploratoria, descriptiva o explicativa.”. En este caso, el nivel de la
investigación es descriptivo, y según Arias, F (2006), “Los estudios descriptivos
miden de forma independiente las variables, y aun cuando no se formulen hipótesis,
las primeras aparecerán enunciadas en los objetivos de investigación.”; teniendo en
consideración la manera en que la se llevan las cuentas por cobrar y pagar en la
empresa en cuestión, se establece así la representación de las necesidades y carencias
20
más sobresalientes para ser solventadas, con lo cual se espera tener un impacto las
mismas con la implementación de la RIA.
3.4– Población y muestra
La Población, también llamada Universo, según Arias, F (2006) es “el conjunto
para el cual serán válidas las conclusiones que se obtengan: a los elementos o
unidades (personas, instituciones o cosas) involucradas en la investigación.”. La
muestra, es simplemente un subconjunto representativo de la población. El universo
de procesos está establecido por los procesos de administración de la base de datos de
proveedores y clientes, realización de inventario, y administración de cuentas por
cobrar y por pagar. Como muestra se tomaron los procesos de administración de
cuentas por cobrar y pagar en la distribuidora El Remendón. Para la recolección de la
información, se utilizó la información suministrada por los empleados.
3.5– Técnicas e Instrumentos de recolección de datos
Arias, F (2006) expresa que, las técnicas de recolección de datos son las distintas
maneras en que el investigador puede recolectar la información que se usará en su
proyecto, mientras que los instrumentos de recolección de datos son las herramientas
mediante las cuales el investigador recoge diversos datos de la información y luego
compararla con los resultados obtenidos de la investigación realizada. En este caso, la
técnica de recolección de datos utilizada en la elaboración de este proyecto consta de
entrevistas no estructuradas, con las cuales se obtienen datos de manera informal de
las necesidades y requisitos solicitados por los usuarios.
3.6– Análisis de los datos
Luego de haber obtenido los datos mediante el uso de la entrevista no estructurada,
se estandarizaron las necesidades de los usuarios en cuanto al uso de aplicaciones en
navegadores web y las características principales para llevar a cabo la gestión de
cuentas por cobrar y por pagar, en este caso de la aplicación a desarrollar para la
administración de cuentas por cobrar y pagar en la distribuidora El Remendón.
3.7– Estudio de factibilidad de la propuesta
21
3.7.1– Factibilidad técnica
La factibilidad técnica consta de la factibilidad técnica por software y la
factibilidad técnica por hardware. Por el lado del software, sólo se requiere del
sistema operativo Windows XP o superior (en el caso de Windows), en el caso de
MacOS desde Leopard o superior y en el caso de Linux, cualquier distribución con un
navegador gráfico actualizado. Más específicamente con respecto al navegador, se
requieren alguna de las siguientes opciones gratuitas: Mozilla Firefox 17 o superior, o
Google Chrome versión 24.0.1312.57 m o superior. En cuanto al hardware, precisa de
un Pentium 4 o superior (en caso de Windows o Linux) con un mínimo de 1024 MB
de memoria RAM.
En la distribuidora El Remendón se cumplen todos los requisitos mínimos
anteriormente planteados para la utilización de la RIA, por lo que es factible
técnicamente.
3.7.2– Factibilidad económica
Este ítem se refiere a los costos que se generarán a partir del uso de esta
aplicación, del hardware y software que se necesitan para ello y el mantenimiento de
la misma; el proyecto no necesita de costos adicionales ni para el desarrollo ni para la
ejecución de la RIA en los equipos de la distribuidora en cuestión.
3.7.3– Factibilidad operativa
La factibilidad operativa se refiere a las exigencias o requerimientos mínimos
laborales y capacidades de los usuarios en la utilización de la aplicación. En este
caso, se requiere de un entrenamiento mínimo para el uso de la aplicación, para que
los usuarios puedan familiarizarse con la herramienta.
3.8– Diseño de la propuesta
Por todo lo anteriormente dicho, se concluye que la Rich Internet Application se
diseñará usando Google Web Toolkit utilizando las metodologías OOHDM y
OOH4RIA. El proyecto en cuestión pretende hacer sustitución del modelo manual de
la gestión de cuentas por cobrar y pagar en la distribuidora a un modelo automatizado
para facilitar en muchos aspectos la ejecución de los procesos.
22
3.9– Procedimientos previstos
Basándonos en la propuesta metodológica que se hizo entre OOHDM y
OOH4RIA, los procedimientos previstos para el desarrollo de la RIA son:
Fase de definición del modelo de usuario: En esta fase, se recolectarán las
preferencias del usuario y se definirán las variables, tanto las de usuario como
las de contexto. Básicamente consta de la entrevista no estructurada con el
usuario en la que él expresa qué necesita en el sistema.
Fase conceptual: Se conceptualizará la petición del usuario en un diagrama
de clases, en donde se expresarán los objetos, las clases y las relaciones e
interacciones entre ellos. Después de esto, se determinarán los actores y las
acciones que estarán implicadas en el sistema.
Fase navegacional: En esta etapa se realizará la estructura completa de la
navegación del sitio, así como los menús y submenús. Se usarán estructuras
de nodos, enlaces y estructuras de acceso que establecerán la ruta por la cual
el usuario podrá moverse dentro de la aplicación.
Fase de marcado del modelo de presentación: Se realizará la
reorganización de todos los elementos anteriores; así como la aparición de los
widgets en el sistema y cambiarlos de tipo si así se requiere. Cada widget
llevará un atributo “Locación” en el cual se determinará si estarán anidados al
panel principal o si aparecerán en pantallas diferentes en la ejecución de la
RIA.
Fase de definición del modelo de dispositivo: Aquí ocurrirá la clasificación
de los widgets así como su adaptación y mejoramiento de los mismos.
Fase de interfaz abstracta: Se diseñarán las interfaces que tendrá la
aplicación, así como su aparición y transformaciones de la misma a lo largo
de su ejecución.
Fase de realización de la transformación de la presentación: En esta fase
se realizará el “Modelo de Orquestación”, que consiste en la predicción de las
23
posibles acciones y comportamientos de la interacción del sistema y el
usuario, así como la determinación de las “transiciones orquestales” y los
“estados orquestales” para la RIA. Como anteriormente se dijo, dependen del
sistema que se esté desarrollando por lo que no hay un estándar para su
elaboración.
Fase de implementación: Aquí se desarrollará la aplicación a partir de todos
pasos anteriores usando un lenguaje de programación orientado a objetos
(Java), que será convertido a una RIA conformada por diversos lenguajes
como AJAX, HTML4, JavaScript y CSS por Google Web Toolkit.
3.10– Fases Metodológicas
FASE I: Realizar el levantamiento de la información del sistema y definir sus
requerimientos.
Se utilizará la entrevista no estructurada como técnica principal en lo que respecta
a las necesidades de posibles usuarios y la distribuidora, lo que determinará los
requerimientos esenciales de la RIA, además de la investigación en línea para
recopilar información proveniente de trabajos relacionados.
FASE II: Identificar y describir las relaciones de los componentes del sistema.
Una vez que se tienen los requerimientos esenciales de la RIA, se diferenciará
cada uno de ellos, se realizará el diagrama de clase de datos y se definirá lo que es la
arquitectura de la aplicación, así como el establecimiento de los actores del sistema,
sus roles y la interacción entre ellos.
FASE III: Diseñar la aplicación siguiendo el modelo RIA con las metodologías
OOHDM y OOH4RIA.
En esta fase, se seguirá con la metodología híbrida creada a partir de las
metodologías OOHDM y OOH4RIA, la cual contiene todos los pasos a seguir para la
creación de los esquemas de la aplicación y los entregables de la misma, que son los
documentos producto de cada fase de la metodología a usar.
FASE IV: Construir los módulos del sistema.
24
Se utilizará el lenguaje de programación Java para la construcción de los diversos
módulos que conforman a la RIA en su totalidad. Éstos se realizarán siguiendo la
metodología creada a partir de OOHDM y OOH4RIA.
FASE V: Integrar todas las unidades (módulos) del sistema y realizar las
pruebas pertinentes.
Luego de tener los módulos construidos en Java, se integrarán para dar lugar a una
misma aplicación, y luego se utilizará el GWT para realizar el compilado a web de la
misma, la cual se podrá utilizar a través de cualquier navegador de Internet. Existirán
dos modalidades de pruebas: Pruebas internas, que consistirá en la evaluación de la
RIA sobre un servidor local, y pruebas de implantación, que se realizarán con los
usuarios.
CAPÍTULO IV
RESULTADOS
4.1– FASE I: Realizar el levantamiento de la información del sistema y definir
sus requerimientos.
En esta fase, se realizó la entrevista no estructurada al Supervisor de la empresa.
Se trataron los siguientes tópicos en la misma:
Información de interés comercial
Procesos llevados a cabo diariamente en la empresa
Procesos que más se dificulta llevar al día y por qué
Información acerca de la manera en que dichos procesos son llevados a cabo
Además, se tiene el documento de requerimientos, que es el siguiente:
Documento de requerimientos
1.- Identificación del requerimiento
Se plantea la integración de los procesos básicos de administración de cuentas por
cobrar y pagar en un sistema realizado en GWT (Google Web Toolkit) como
herramienta de desarrollo. La misma, se realizará en Eclipse IDE for Java EE
Developers, el plugin de Google para Eclipse conjuntamente con el uso de
Hibernate.
2.- Alcance
El sistema debe comprender lo siguiente:
Seguimiento cronológico de las cuentas
Aquí, como el título lo indica, llevará seguimiento cronológico de los eventos por
pagar y cobrar. Se podrá observar detalladamente el histórico de movimientos
realizados, con fechas de inicio y fin, así como las fechas límites de pago o cobro y
26
su monto.
Alertas de próximo día crítico
Asociado a la característica anterior, se producirán alarmas dependiendo del tipo
de evento que se registre, a saber:
o Día crítico (día límite) de cobro/pago
o Día de llegada de productos para agregarse al inventario
Protección de información en cada perfil
Con esto, lo que se quiere asegurar es la apropiada protección de la información
en cada uno de los niveles de rol. Como los roles son jerárquicos (partiendo desde
Administrador del Sistema, pasando por Supervisor y llegando a Empleado), esta
característica es bastante importante ya que, por ejemplo, el Empleado no debería de
poder ver lo que hace el Administrador del Sistema.
Registro de clientes, proveedores y representantes de compañías que
abastecen o compran a la pequeña empresa
Mediante este módulo se podrá administrar la gestión de clientes, proveedores y
representantes para poder incluirlos, organizarlos y desincorporarlos (eliminar) de
los registros; además, se establecerán diferencias entre los tipos de clientes (ya que
puede ser persona natural o jurídica).
3.- Identificación de responsables y actores
Los actores que desarrollarán las acciones en el sistema son:
o Gestor de Sistema
o Supervisor
o Empleado
4.- Observaciones
o Registro de clientes, proveedores y representantes se hacen con la
misma tabla maestra de dirección. Lo mismo ocurre cuando se agrega
un usuario al sistema, ya sea supervisor o empleado. Ciertas
características de los clientes cambiarán dependiendo de que si es una
27
persona natural o jurídica.
5.- Glosario
No aplica.
4.2– FASE II: Identificar y describir las relaciones de los componentes del
sistema.
En esta fase, como ya se mencionó anteriormente se identifican y describen las
relaciones de los componentes del sistema. Esto se hace mediante un diagrama de
clases, el cual se puede apreciar en el anexo 1.
4.3– FASE III: Diseñar la aplicación siguiendo el modelo RIA con las
metodologías OOHDM y OOH4RIA.
4.3.1– Fase de definición del modelo de usuario
Se realizó la entrevista no estructurada, la cual se guió bajo los ítems mostrados en
la fase I. Con esto se pudo determinar los procesos que más se dificultaban de llevar
al día en la distribuidora El Remendón
4.3.2– Fase conceptual
En esta fase, se reutilizó el diagrama de clases (ver Figura 1, ya que el mismo
diagrama aplica para ambos casos) correspondiente a los requisitos obtenidos en la
fase anterior, ya que es el mismo. También se realizó el diagrama de casos de uso,
que define los actores del sistema, los procesos principales del mismo y la interacción
entre ellos. El diagrama, se dividió en uno para cada usuario y ya dividido, serían los
siguientes:
Tabla 1: Documento de requerimientos
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
28
Figura 1: Diagrama de caso de uso (gestor del sistema)
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
29
Figura 2: Diagrama de caso de uso (supervisor)
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
30
4.3.3– Fase navegacional
Se realizó el modelo de navegación, que es el siguiente:
Figura 3: Diagrama de caso de uso (empleado)
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 4: Modelo de navegación de la aplicación
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
31
4.3.4– Fase de marcado del modelo de presentación
Partiendo del diseño inicial que tienen los widgets clásicos, con la implementación
del GWT Deisgner, se reacomodará y ajustará a un diseño formal y elegante acorde a
la temática de la aplicación. Con el GWT Designer se puede ver en tiempo real la
distribución exacta de todos los paneles y widgets haciendo así evidente la necesidad
de la inclusión de más componentes o disminución de la cantidad de los mismos.
4.3.5– Fase de definición modelo del dispositivo
En esta etapa, se realizaron los diagramas de estado de la aplicación, los más
importantes son los que competen a cuentas por cobrar y cuentas por pagar. Son los
siguientes:
Figura 5: Diagrama de estados de cuentas por cobrar
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
32
4.3.6– Fase de interfaz abstracta
Se diseñaron las diferentes interfaces de usuario del sistema y sus
especificaciones. Son las siguientes:
Figura 6: Diagrama de estados de cuentas por pagar
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
33
Número 1
Nombre Iniciar sesión
Autor Paúl Huamanciza – Alejandra Rodríguez
Fecha 05-02-2013
Descripción: Permite el ingreso al sistema.
Actores: Gestor de sistemas, Supervisor, Empleado.
Precondiciones: El usuario en cuestión debe estar registrado previamente.
Flujo normal:
1. El actor accede a la aplicación
2. El actor marca su nombre de usuario en su contraseña.
3. Se presiona el botón “Ingresar”
Flujo alternativo: No aplica.
Postcondiciones: No aplica.
Figura 7: Iniciar Sesión
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Tabla 2: Caso de uso “Iniciar sesión”
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
34
Número 2
Nombre Registrar Cuentas por Cobrar/Pagar
Autor Paúl Huamanciza – Alejandra Rodríguez
Fecha 05-02-2013
Descripción: Permite agregar nuevos registros de cuentas por cobrar y pagar al sistema
Actores: Gestor de sistemas, Supervisor.
Precondiciones: El proveedor o el cliente deben haber sido registrados previamente en el sistema.
Flujo normal:
1. El actor selecciona si desea registrar una cuenta por cobrar o una cuenta por pagar.
2. Llena los campos correspondientes a: Tipo Cobro/Pago, Tipo de Identificación, Número de
Identificación, Persona/Razón Social, Fecha Inicial, Fecha Límite (si la hubiera), Monto
Inicial, Intereses, Descuentos, Motivo/Justificación.
3. Presiona el botón “Crear”.
Flujo alternativo:
4. Si se selecciona “Cobro”, la interfaz sigue siendo igual.
Figura 8: Registrar Cuentas por Cobrar/Pagar
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
35
Postcondiciones: Continúa hacia la próxima interfaz.
Número 3
Nombre Gestionar Registros Cliente/Proveedor
Autor Paúl Huamanciza – Alejandra Rodríguez
Fecha 05-02-2013
Descripción: Permite agregar nuevos registros de cuentas por cobrar y pagar al sistema
Actores: Gestor de sistemas, Supervisor.
Precondiciones: El proveedor o el cliente deben haber sido registrados previamente en el sistema.
Flujo normal:
1. El actor selecciona si desea registrar una cuenta por cobrar o una cuenta por pagar.
2. Llena los campos correspondientes a: Tipo Cobro/Pago, Tipo de Identificación, Número de
Identificación, Persona/Razón Social, Fecha Inicial, Fecha Límite (si la hubiera), Monto
Inicial, Intereses, Descuentos, Motivo/Justificación.
3. Presiona el botón “Crear”.
Flujo alternativo: No aplica.
Tabla 3: Caso de uso “Registrar Cuentas por Cobrar/Pagar”
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 9: Gestionar Registros Cliente/Proveedor
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
36
Postcondiciones: No aplica.
Número 4
Nombre Vincular Persona-Usuario (1)
Autor Paúl Huamanciza – Alejandra Rodríguez
Fecha 05-02-2013
Descripción: Permite la creación de un nuevo tipo de usuario, ya sea a partir de un usuario nuevo o
existente.
Actores: Gestor de sistemas, Supervisor.
Precondiciones: No aplica.
Flujo normal:
4. El actor selecciona si el usuario que desea vincular es nuevo.
5. Selecciona el tipo de Persona/Usuario y el tipo de identificación.
6. Presiona el botón “Seguir”.
Figura 10: Vincular Persona-Usuario (1)
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Tabla 4: Caso de uso “Gestionar Registros Cliente/Proveedor”
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
37
Flujo alternativo:
7. Si el usuario es existente, se realiza la búsqueda del mismo.
Postcondiciones: Continúa hacia la próxima interfaz.
Número 5
Nombre Vincular Persona-Usuario (2)
Autor Paúl Huamanciza – Alejandra Rodríguez
Fecha 05-02-2013
Descripción: Permite la creación de un nuevo tipo de usuario, ya sea a partir de un usuario nuevo o
existente.
Actores: Gestor de sistemas, Supervisor.
Precondiciones: No aplica.
Flujo normal:
1. El actor selecciona si el usuario que desea vincular ya existe.
Tabla 5: Caso de uso “Vincular Persona-Usuario (1)”
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 11: Vincular Persona-Usuario (2)
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
38
2. Selecciona el tipo de Persona/Usuario y el tipo de identificación.
3. Se coloca el número de identificación en el campo de búsqueda.
4. Presiona el botón “Seguir”.
Flujo alternativo: No aplica.
Postcondiciones: Continúa hacia la próxima interfaz.
Número 6
Nombre Registrar persona
Autor Paúl Huamanciza – Alejandra Rodríguez
Fecha 05-02-2013
Descripción: Permite registrar los datos de una persona, ya sea un usuario, un cliente o un proveedor.
Actores: Gestor de sistemas, Supervisor, Empleado.
Precondiciones: No aplica.
Flujo normal:
Tabla 6: Caso de uso “Vincular Persona-Usuario (2)”
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 12: Registrar persona
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
39
1. El actor llena todos los campos correspondientes al registro de usuario: Nombre, Tipo y
Número de Identificación, RIF, Cuenta Bancaria, Estado, Municipio, Parroquia, Ciudad,
Urbanización, Avenidas, Calles, Piso, Número/Nombre Residencia, E-Mail, Teléfono, Pin,
Página Web, y Fax.
2. Presiona el botón “Seguir”.
Flujo alternativo:
3. Cuando se encuentra en el módulo de registro de Cliente/Proveedor, la siguiente interfaz es
Datos Cliente/Proveedor.
Postcondiciones: Continúa hacia la próxima interfaz.
Número 5
Nombre Registrar datos de usuario
Autor Paúl Huamanciza – Alejandra Rodríguez
Fecha 05-02-2013
Tabla 7: Caso de uso “Registrar persona”
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 13: Registrar datos de usuario
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
40
Descripción: Permite vincular los datos de la persona con los del usuario.
Actores: Gestor de sistemas, Supervisor.
Precondiciones: Tiene que haber una persona registrada a la cual se le vaya a realizar la vinculación.
Flujo normal:
1. El actor llena todos los campos correspondientes a los datos de usuario: Persona/Razón
Social, Nombre Usuario, Es excepcional, Contraseña y Habilitar.
2. Presiona el botón “Seguir”.
Flujo alternativo: No aplica.
Postcondiciones: No aplica.
Número 6
Nombre Registrar datos de cliente/proveedor
Autor Paúl Huamanciza – Alejandra Rodríguez
Fecha 05-02-2013
Tabla 8: Caso de uso “Registrar datos de usuario”
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 14: Registrar datos de cliente/proveedor
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
41
Descripción: Permite registrar clientes y proveedores.
Actores: Supervisor, Empleado.
Precondiciones: No aplica
Flujo normal:
1. El actor selecciona si quiere registrar un cliente o proveedor.
2. Llena los datos correspondientes al seleccionado previamente.
3. Presiona el botón “Registrar”
Flujo alternativo:
4. Si el usuario es Empleado, sólo podrá registrar clientes. Lo hará de la misma manera.
Postcondiciones: Regresa a la interfaz de registro de persona.
4.3.7– Fase de realización de la transformación de la presentación
En esta fase, se realizaron los modelos de orquestación de los procesos más
importantes del sistema, tales como lo son:
Ingresar al Sistema
Administrar Cuentas por Cobrar
Administrar Cuentas por Pagar
Los modelos de orquestación mencionados son los siguientes:
Tabla 9: Caso de uso “Registrar datos de cliente/proveedor”
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
42
Figura 16: Modelo de orquestación Administrar Cuentas por Cobrar
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 15: Modelo de orquestación Ingresar al Sistema
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
43
4.3.8– Fase de Implementación
Se detallará en la Fase IV.
4.4– FASE IV: Construir los módulos del sistema.
Una vez terminado el diseño y la planificación inicial de la aplicación, se prosigue
con el desarrollo del mismo. Se obtiene el Eclipse IDE for Java EE Developers
(visitando la página oficial de Eclipse: www.eclipse.org) en su versión llamada
Eclipse Juno v.4.2.0 SR1 para 32 bits. Una vez instalado se procede con la instalación
de plugins y paquetes necesarios, el primero es el Plugin de Google para Eclipse
(Página oficial de Google, división para desarrolladores) que contiene a Google Web
Toolkit 2.5.0 relase 42, posteriormente se descarga los paquetes de Windows Builder
Pro v.1.5.1 y los de de GWT Designer, por ultimo buscamos el plugin de Hibernate
3.6.0 compatible con GWT (página oficial de JBoss).
Al crear el proyecto de aplicación web se eliminaron las siguientes opciones que
vienen por defecto: Google App Engine (no se utilizarán APIs, ni sincronización de
Figura 17: Modelo de orquestación Administrar Cuentas por Pagar
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
44
aplicaciones y datos), Google Apps MarketPlace (ya que no fue un desarrollo
enfocado a la nube), y Sample code (ya que no se utilizaron los modelos
predeterminados ofrecidos por el plugin) (Ver figura 20).
GWT provee cuatro temas de estilos para la presentación de los componentes del
cliente: Clean, Standard, Chrome y Dark. Para este proyecto el uso de Clean es el
indicado para la creación de aplicaciones web empresariales (Ver figura 21).
La aplicación se divide en dos partes, lado del cliente, y el lado del servidor. El
lado del cliente es la parte pública y fácil de acceder, en esta parte no es posible que
ningún usuario dé peticiones directas para información específica, todo esto se
controla por medio de enlaces del lado del servidor. En el lado del servidor se
introduce el esquema de ORM, la implementación de Hibernate para la simplificación
y disminución del código y abstracción de los datos, código HQL para mejorar el
nivel de consultas a la base de datos; también se pueden incluir APIs y librerías no
orientadas a GWT.
45
Figura 18: Creación de un nuevo proyecto de aplicación web – Configuración inicial
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 19: Selección de estilo de componentes de la aplicación: Clean
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
46
Para generar las interfaces gráficas visibles por los usuarios se utilizará el GWT
Designer, el cual presenta la modalidad gráfica de arrastre para generar los diferentes
componentes que integran la interfaz, como widgets, barras, paneles, entre otros.
Para poder acceder a la Base de Datos, Hibernate tiene que ser cuidadosamente
configurado por archivos .xml siguiendo sus estándares. Se utilizó una base de datos
relacional en MySQL, así que la configuración de Hibernate será con los drivers
compatibles, así como el dialecto de MySQL5. Para manejar la base de datos, se hizo
utilizando cada tabla como una lista de objetos, y los atributos y columnas de esa
tabla se manejan como objetos. Para cada tabla se creó una clase especial, la cual
manejará las diferentes columnas y relaciones con otras tablas, para ellos se debe
mapear estas asociaciones creando archivos de mapeo que tienen como extensión
hbm.xml. La idea es clara, por cada tabla debe existir un fichero de este tipo que
contenga la información de los campos de la tabla enlazada con los atributos de la
clase que debe contener dicha información. Todos estos ficheros deben estar en el
Figura 20: Vista desde el GWT Designer
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
47
mismo paquete del proyecto y deben colocarse las rutas en la configuración inicial de
Hibernate.
Figura 21: Configuración de Hibernate – Parte 1
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 22: Configuración de Hibernate – Parte 2
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
48
Para llenar formularios y consultas precisas la elección óptima y adecuada con el
uso de Hibernate es el uso del lenguaje HQL, que es orientado a objetos, permitiendo
así tener herencia y sobrecarga de operaciones, entre otros.
Figura 23: Configuración de Hibernate – Parte 3
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 24: Consulta con Hibernate (HQ L)
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
49
4.5– FASE V: Integrar todas las unidades (módulos) del sistema y realizar las
pruebas pertinentes.
Al integrar los módulos hay que tener en cuenta la inclusión de los métodos que
interactúan con la base de datos por medio del RPC con lo cual no hay que
preocuparse de las gestión de conexiones. GWT no permite más de dos consultas por
método RPC lo cual es un inconveniente ya que lleva a una reestructuración de parte
del código.
Se realizó una prueba piloto en la distribuidora El Remendón con los usuarios del
sistema, permitiendo que interactuaran con la herramienta, lo cual les resultó bastante
amigable y satisfactorio. Se tomó una muestra conformada por 5 cuentas por cobrar y
5 cuentas por pagar, para la verificación de todas sus funcionalidades, obteniéndose
así un comportamiento adecuado y correcto de la RIA. Entonces, se obtuvo el
siguiente rendimiento:
Proceso
Aproximación en minutos
Proceso anterior
utilizando registro
manual
Proceso nuevo
utilizando la
aplicación
Registro de proveedor 7 3
Registro de cliente No aplica 3
Registro de cuenta por cobrar 5 1
Registro de cuenta por pagar 5 1
Tabla 10: Rendimiento en registro de cuentas por cobrar y pagar
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
50
CONCLUSIONES
Google Web Toolkit, es una herramienta versátil que traduce el código fuente en
lenguaje de programación Java, a Javascript, AJAX, HTML y CSS para su ejecución
en un navegador.
GWT, ya tiene dos metodologías con las cuales trabajar, por lo cual no se necesitó
escoger alguna otra. Dichas metodologías son OOHDM y OOH4RIA, y OOH4RIA
es una metodología de desarrollo de software derivada de OOHDM para el desarrollo
de RIAs. Ambas se complementan perfectamente, y en este proyecto se combinaron,
para dar lugar a una propuesta metodológica híbrida, que fue validada con la
construcción exitosa de la herramienta. Esta propuesta permitió el adecuado
desarrollo del sistema en cuanto a su planificación y diseño a través de las
herramientas de la misma, sobre todo con el nuevo diagrama que es ofrecido en la
metodología OOH4RIA, que es el “Modelo de Orquestación”, que va mostrando las
interacciones de los widgets entre sí, lo cual es bastante importante en el desarrollo de
la aplicación, ya que se basa en la modificación de los widgets nativos de GWT.
En la fase de definición del modelo de usuario de la metodología híbrida, se
realizó la entrevista no estructurada correspondiente, que permitió la recolección de
los datos esenciales para establecer los requerimientos del sistema.
En la fase conceptual, se creó el diagrama de clases correspondiente, en donde se
manifestaron las relaciones entre las clases del sistema. También se crearon los
diagramas de casos de uso, en el que se muestran a los actores y las diferentes
acciones que pueden llevar a cabo en el mismo.
En la fase navegacional, se creó el modelo de navegación, que indica la manera en
la que el usuario se moverá a través de las pantallas de la aplicación.
En la fase de marcado del modelo de presentación, se reacomodaron y adecuaron
los widgets nativos de GWT para la elaboración de la aplicación. Además, se eligió
un tema (Clean), que viene por defecto con GWT y es adecuado para el tipo de
aplicación por su presentación a nivel de gráficos.
51
En la fase de definición del modelo de dispositivo, se realizaron los diagramas de
estado de las operaciones de la aplicación, para observar por las “fases” que atraviesa
(por así decirlo).
En la fase de Interfaz abstracta, se crearon los prototipos de las interfaces del
sistema, para tener un modelo a seguir a la hora de desarrollar la aplicación y saber de
una vez la distribución de las ventanas de la misma.
En la fase de realización de la transformación de la presentación, se realizaron los
Modelos de Orquestación, fundamentales en el desarrollo de un proyecto en GWT,
para ver la interacción y dependencias entre los widgets de la aplicación.
Y por último, en la fase de implementación, se procedió a desarrollar la aplicación
con todo el material realizado anteriormente, además de la unión de todos los
módulos de la aplicación.
52
RECOMENDACIONES
Como recomendaciones para el buen uso del sistema, y de mejoras futuras,
tenemos:
Se sugiere que el gestor del sistema sea una persona diferente al supervisor, ya
que las vistas son diferentes y no manejan los mismos tipos de datos ya que
para el gestor son datos estadísticos de la aplicación y para el supervisor son
datos que competen directamente a la empresa.
Añadir funcionalidades de manejo de cuentas de redes sociales, para el envío
de advertencias, datos estadísticos del sistema, y además la creación de
nuevos usuarios a partir de la información de los perfiles de dichas cuentas.
53
REFERENCIAS
Bibliográficas:
Arias, F (2006) – El proyecto de investigación: Guía para su elaboración (5ta
edición). Caracas, Venezuela. [2012, junio 26]
Atahys, M; Díaz, B; Martínez, Y; Rodríguez, Y; Salgado, H (2011) – Cuentas por
Cobrar. Lechería, Anzoátegui, Venezuela. [2013, febrero 3]
Bravo, E (2011) – Desarrollo de Aplicaciones Web 2.0 con Google Web Toolkit.
Alicante, España. [2013, enero 10]
Decreto N° 6.215, con Rango, Valor y Fuerza de Ley para la Promoción y Desarrollo
de la Pequeña y Mediana Industria y Demás Unidades de Producción Social. N°5.890
Extraordinario de la GACETA OFICIAL DE LA REPÚBLICA BOLIVARIANA DE
VENEZUELA, 31 de julio de 2008. [2012, junio 21]
Garrigós, I; Meliá, S; Casteleyn, S (2009) - Adapting the Presentation Layer in
Rich Internet Applications. Alicante, España. [2012, junio 26]
González, J (2001) – Tipos y Diseños de Investigación en los trabajos de grado.
[2012, julio 09]
Halpin, T (2009) – Object-Role Modeling. Atlanta, Estados Unidos. [2013, enero
10]
Jalali, J (2011) - GWT y SmartGWT. Madrid, España. [2013, enero 10]
54
Lizarralde, F (2008) - Aplicaciones dinámicas de Internet, Un nuevo enfoque para
su desarrollo en educación. Buenos Aires, Argentina. [2012, junio 25]
Mejías, J (2008) – Manual de GWT. [2013, enero 10]
Meliá, S; Martínez, J; Pérez, A; Gómez, J (2009) - OOH4RIA Tool: Una
Herramienta basada en el Desarrollo Dirigido por Modelos para las RIAs.
Alicante, España.
Pérez, S; Díaz, O; Meliá, S; Gómez, J (2008) - Facing Interaction-Rich RIAs: the
Orchestration Model. Alicante y San Sebastián. España. [2012, junio 26]
Electrónicas:
Alegsa, Diccionario de Informática – Definición de Widget (GUI) (en línea)
http://www.alegsa.com.ar/Dic/uml.php [2013, febrero 3]
Alegsa, Diccionario de Informática – Definición de UML (en línea)
http://www.alegsa.com.ar/Dic/widget.php [2012, junio 26]
Blanco, C – Entornos de Desarrollo Integrados (IDEs)-Introducción (en línea)
http://carlosblanco.pro/2012/04/entornos-desarrollo-integrado-introduccion/ [2013,
febrero 3]
Canal AR, Tecnología a Diario - ¿Qué son las Rich Internet Applications? (en línea)
http://www.canal-ar.com.ar/noticias/noticiamuestra.asp?Id=2639 [2012, junio 21]
Chambi, G – Cuentas por Cobrar. Contabilidad General (en línea) -
http://www.emagister.com/cuentas-cobrar-contabilidad-general_h [2013, febrero 3]
55
CHIPSYPC (2011, mayo 20) – De la Web 1.0 a la Web 3.0 (en línea)
http://www.chipsypc.com/?p=2028 [2012, julio 09]
Computing.es – Tecnologías RIA (Rich Internet Applications) (en línea)
http://www.computing.es/internet/informes/1035994001901/tecnologias-ria-rich-
internet-applications.1.html [2012, julio 1]
Contanetica – Pasivos o cuentas por pagar (en línea)
http://www.contanetica.com/exentus/manualdeoperacion/strcfina/1_estructura/elemen
tos/b3.htm [2013, febrero 4]
Díaz, M (2008) La pequeña empresa (en línea)
http://www.monografias.com/trabajos10/micro/micro.shtml [2012, junio 21]
Gallardo, J – Llamada a Procedimiento Remoto RPC (en línea)
http://www.fermu.com/es/451 [2013, enero 10]
González, J – Cuentas por pagar (en línea) http://www.zonaeconomica.com/analisis-
financiero/cuentas-pagar [2012, junio 21]
GWT Honduras - ¿Qué es el GWT? (en línea) http://illgamer.wordpress.com/ [2012,
junio 21]
Halpin, T – Object Role Modeling (en línea) http://www.orm.net/ [2013, enero 10]
Interacciones – URL Semántica/Clean URL/Friendly URL (en línea)
http://www.interacciones.com.ar/url-semantica-clean-url-friendly-url/ [2012, junio
24]
56
Lamarca, M (2011) – Modelo OOHDM (en línea)
http://www.hipertexto.info/documentos/oohdm.htm [2012, junio 26]
Martina, A (2010) – Gestión de las Relaciones con los Clientes (CRM) (en línea) -
http://www.monografias.com/trabajos29/gestion-relacion-cliente/gestion-relacion-
cliente.shtml [2012, junio 21]
Mediovirtual – Mashup (en línea)
http://www.mediovirtual.com/index.php?option=com_content&view=article&id=80:
mashup [2012, junio 24]
Mejía, R (2009) – Definición de la Micro y Pequeña Empresa (en línea) -
http://www.monografias.com/trabajos11/pymes/pymes.shtml [2012, junio 21]
Méndez, A (2011) – Metodologías Web: OOHDM. [2012, junio 26]
Molina, D (2008) - ¿Qué es la web 1.0, 2.0, 3.0? (en línea)
http://dimamoa.blogspot.com/2008/05/qu-es-la-web-10-20-30.html [2012, junio 24]
Moreiro, José Antonio (2009) – Folksonomía (en línea)
http://glossarium.bitrum.unileon.es/Home/folksonomia-folksonomy [2012, junio 24]
Nascimbene, C (2005) - ¿Qué son las Rich Internet Applications? (en línea)
http://www.canal-ar.com.ar/noticias/noticiamuestra.asp?Id=2639 [2012, junio 24]
ORM-Hibernate (2012) – Hibernate es una herramienta de mapeo (en línea)
http://teoriahibernate.blogspot.com/2012/10/hibernate-es-unaherramienta-de-
mapeo.html [2013, enero 10]
57
Pérez, I - ¿Qué son los wikis? (en línea) http://www.isabelperez.com/taller1/wiki.htm
[2012, junio 24]
Robles, D (2008, abril 24) – Aplicaciones RIA Web 2.0 (en línea)
http://www.danterobles.com.mx/?p=193 [2012, julio 09]
Rodríguez, M (2000) – Modelos y metamodelos (en línea)
http://sensei.lsi.uned.es/~miguel/tesis/node27.html [2012, junio 26]
SOA Agenda - ¿Qué son los Frameworks? (en línea)
http://www.soaagenda.com/journal/articulos/que-son-los-frameworks/ [2013, febrero
3]
Soto, L – Cuentas por Cobrar (en línea)
http://www.mitecnologico.com/Main/CuentasPorCobrar [2012, junio 21]
Soto, L – Cuentas por Pagar (en línea)
http://www.mitecnologico.com/Main/CuentasPorPagar [2012, junio 21]
Thompson, I (2007, marzo 14) – Definición de Pequeña Empresa (en línea)
http://lapequenaempresa.blogspot.com/2007/03/definicin-de-pequea-empresa.html
[2012, junio 21]
Thompson, I (2007) – La pequeña empresa (en línea)
http://www.promonegocios.net/empresa/pequena-empresa.html [2012, junio 21]
Tutoriales de Programación Java: Hibernate – Parte 7: HQL primera parte (en línea)
http://www.javatutoriales.com/2009/09/hibernate-parte-7-hql-primera-parte.html
[2013, enero 10]
58
Van Der Henst, C (2005) – ¿Qué es la Web 2.0?
http://www.maestrosdelweb.com/editorial/web2/ [2012, julio 09]
WebTaller - ¿Qué es AJAX? (en línea)
http://www.webtaller.com/maletin/articulos/que-es-ajax.php [2013, febrero 3]
59
ANEXOS
60
Anexo 1: Diagrama de clases
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
61
Anexo 2: Diagrama físico de base de datos
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
62
Anexo 3: Modelo de Navegación
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
63
Anexo 4: Diagrama de estados de cuentas por cobrar
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
64
Anexo 4: Diagrama de estados de cuentas por pagar
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)