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: Docume nto de re que rimie ntos
28
Figura 1: Diagrama de caso de uso (ge stor de l siste ma)
29
Figura 2: Diagrama de caso de uso (supe rvisor)
30
4.3.3– Fase navegacional
Se realizó el modelo de navegación, que es el siguiente: Figura 3: Diagrama de caso de uso (e mple ado)
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 4: Mode lo de nave gació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 e stados de cue ntas 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 e stados de cue ntas 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 Se sió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: Re gistrar C ue ntas por C obrar/Pagar
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: C aso de uso “Re gistrar C ue ntas por C obrar/Pagar”
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 9: Ge stionar Re gistros C lie nte /Prove e dor
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 Pe rsona-Usuario (1)
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Tabla 4: C aso de uso “Ge stionar Re gistros C lie nte /Prove e dor”
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: C aso de uso “Vincular Pe rsona-Usuario (1)”
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 11: Vincular Pe rsona-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. 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: Re gistrar pe rsona
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: Re gistrar datos de usuario
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: Re gistrar datos de clie nte /prove e dor
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: Mode lo de orque stación Administrar C ue ntas por C obrar
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 15:Mode lo de orque stación Ingre sar al Siste ma
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: Mode lo de orque stación Administrar C ue ntas 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:C re ación de un nue vo proye cto de aplicación we b – C onfiguración inicial
Fuente: Paúl Huamanciza y Alejandra Rodríguez (2013)
Figura 19: Se le cción de e stilo de compone nte s de la aplicación: C le an
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 de sde e l GWT De signe r
47
mismo paquete del proyecto y deben colocarse las rutas en la configuración inicial de Hibernate.
Figura 21: C onfiguración de Hibe rnate – Parte 1
Fuente: Paúl Huamanciza y Alejandra Rodríguez (201 3)
Figura 22: C onfiguración de Hibe rnate – Parte 2
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: C onfiguración de Hibe rnate – Parte 3
Fuente: Paúl Huamanciza y Alejandra Rodríguez (201 3)
Figura 24: C onsulta con Hibe rnate (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: Re ndimie nto e n re gistro de cue ntas 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.