teg huamanciza rodriguez

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


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


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




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



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



24 Consulta con Hibernate (HQL) ..................................................................... 48

x

REPÚBLICA BOLIVARIANA DE VENEZUELA UNIVERSIDAD JOSÉ ANTONIO PÁEZ


ESCUELA DE COMPUTACIÓN CARRERA: INGENIERÍA DE COMPUTACIÓ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)


29

Figura 2: Diagrama de caso de uso (supervisor)


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)


Figura 4: Modelo de navegación de la aplicación


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


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


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


Tabla 2: Caso de uso “Iniciar sesión”


34

Número 2

Nombre Registrar Cuentas por Cobrar/Pagar


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


35

Postcondiciones: Continúa hacia la próxima interfaz.

Número 3

Nombre Gestionar Registros Cliente/Proveedor


Fecha 05-02-2013

Descripción: Permite agregar nuevos registros de cuentas por cobrar y pagar al sistema


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”.


Tabla 3: Caso de uso “Registrar Cuentas por Cobrar/Pagar”


Figura 9: Gestionar Registros Cliente/Proveedor


36


Número 4

Nombre Vincular Persona-Usuario (1)


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.


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)


Tabla 4: Caso de uso “Gestionar Registros Cliente/Proveedor”


37

Flujo alternativo:

7. Si el usuario es existente, se realiza la búsqueda del mismo.


Número 5

Nombre Vincular Persona-Usuario (2)


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.



Flujo normal:

1. El actor selecciona si el usuario que desea vincular ya existe.

Tabla 5: Caso de uso “Vincular Persona-Usuario (1)”


Figura 11: Vincular Persona-Usuario (2)


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.




Número 6

Nombre Registrar persona


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.


Flujo normal:

Tabla 6: Caso de uso “Vincular Persona-Usuario (2)”


Figura 12: Registrar persona


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.


Flujo alternativo:

3. Cuando se encuentra en el módulo de registro de Cliente/Proveedor, la siguiente interfaz es

Datos Cliente/Proveedor.


Número 5

Nombre Registrar datos de usuario


Fecha 05-02-2013

Tabla 7: Caso de uso “Registrar persona”


Figura 13: Registrar datos de usuario


40

Descripción: Permite vincular los datos de la persona con los del usuario.


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.




Número 6

Nombre Registrar datos de cliente/proveedor


Fecha 05-02-2013

Tabla 8: Caso de uso “Registrar datos de usuario”


Figura 14: Registrar datos de cliente/proveedor


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”


42

Figura 16: Modelo de orquestación Administrar Cuentas por Cobrar


Figura 15: Modelo de orquestación Ingresar al Sistema


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


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


Figura 19: Selección de estilo de componentes de la aplicación: Clean


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


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




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 24: Consulta con Hibernate (HQ L)


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


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


61

Anexo 2: Diagrama físico de base de datos


62

Anexo 3: Modelo de Navegación


63

Anexo 4: Diagrama de estados de cuentas por cobrar


64

Anexo 4: Diagrama de estados de cuentas por pagar


teg huamanciza rodriguez

Documents