Memoria_Miguel_Azocar_Final by HC111111012641

VIEWS: 5 PAGES: 62

									       UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA
       DEPARTAMENTO DE ELECTRÓNICA




   “Desarrollo de Proyecto J2EE para la
automatización de los procesos contables de
  una Administradora General de Fondos”



  Memoria presentada por: Miguel Ángel Azócar Vega
    Como requisito parcial para optar al título de
             Ingeniero Civil Electrónico
    Mención Computadores y Sistemas Digitales


           Profesor Guía: Agustín González Valenzuela
    Profesor Correferente: Tomás Arredondo Vidal
               Comisión: Oscar Romero Jara




           Valparaíso, Noviembre del 2007
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



 Desarrollo de Proyecto J2EE para la automatización de
 los procesos contables de una Administradora General
                       de Fondos
               Memoria para optar al título de Ingeniero Civil Electrónico
                    Mención Computadores y Sistemas Digitales

                                Miguel Ángel Azócar Vega

                           Profesor Guía: Agustín González V.
                    Profesor Correferente: Tomás Arredondo V.

                                 Valparaíso, Noviembre 2007

                                          Resumen
Para toda empresa es esencial que los datos contables sean llevados en forma correcta, en las
Administradoras de Fondos esto adquiere la mayor importancia debido a los grandes flujos de
dinero que manejan, la fiscalización que reciben y a que los valores cuota son obtenidos
diariamente de la contabilidad de los distintos fondos que administran.

Actualmente, muchos procesos contables son llevados en forma manual debido a dificultades
de comunicación entre los distintos módulos de las Administradoras. Sistemas de gestión
empresarial (sistemas ERP) se han utilizado para mitigar este efecto. Otra solución son los
llamados software de clase mundial, no obstante su elevado precio y su dificultad para
adaptarlo al mercado chileno lo han hecho una solución inviable.

El objetivo de este trabajo es la creación de un módulo contable para una Administradora
General de Fondos, operable a través de la Web, que cumpla con los requisitos de seguridad,
escalabilidad y disponibilidad que una aplicación de este tipo requiere. Se eligió la
tecnología J2EE como plataforma para la creación computacional de la aplicación, ya que
ella cumple con los requisitos mencionados, además de permitir un rápido y modular
desarrollo de ésta.

En el desarrollo del proyecto, se utilizó los últimos avances de la tecnología J2EE, tales como
JSF, EJB QL Query, junto a tecnologías tradicionales de J2EE; EJB CMP, Java Beans, entre
otras, con el fin de hacer un sistema robusto, rápido, tolerante a fallas, y que cumpliese
cabalmente los requerimientos de negocio solicitados.

El resultado del proyecto es un módulo contable operativo, de fácil uso, configurable para la
conexión con otros módulos. El código fuente es fácil de modificar y mejorar, debido a su
diseño basado en objetos, y a que la lógica de la aplicación está basada en capas delimitadas.

Palabras Claves: J2EE, JSF, EJB CMP, Servidor Aplicaciones J2EE



Miguel Angel Azócar Vega                                                                 P ágina 2
                                                                                        Departamento Electrónica




Índice Contenidos
1. Introducción…………………………………..………………….……..............8
   1.1. Descripción de las administradoras generales de fondos...................................8
   1.2. Problemas con los sistemas contables de las AGF.............................................8
   1.3. Objetivos del proyecto........................................................................................9
   1.4. Elección de la tecnología informática.................................................................9
       1.4.1. Requerimientos computacionales del proyecto.........................................9
   1.5. Tecnologías J2EE utilizadas.............................................................................10

2. Diseño Orientado a Objetos.......................……..……………………….....12
   2.1. Metodología……………………………………….……………………….....12
       2.1.1. Arquitectura de cada ciclo de desarrollo..................................................12
   2.2. Herramientas utilizadas…………………………………………………….....13
       2.2.1. Power Designer........................................................................................13
       2.2.2. Microsoft Office Visio.............................................................................15
   2.3. Definición de Requerimientos……………………………..………………....16
   2.4. Casos de uso…………………………………………….........……………....17
       2.4.1. Definición de tipo de cambio...................................................................17
       2.4.2. Definición de índice.................................................................................17
       2.4.3. Validación de usuario..............................................................................18
   2.5. Diagramas de Secuencia de UML....................................................................18
       2.5.1. Detalles sintácticos de los diagramas de secuencia.................................19
       2.5.2. Ejemplo de diagrama de secuencia .........................................................20
             2.5.2.1. Definición de tipo de cambio.......................................................20

3. Introducción a J2EE………………………….......………………………….23
   3.1. Componentes J2EE……….…………………..………...….............................23
        3.1.1. Componentes JavaBeans……….……………….…………...…............24
        3.1.2. Componentes de la capa cliente ……….……….………………...…....24
        3.1.3. Componentes de la capa Web ……….…………..……………...…......25
        3.1.4. Componentes de la capa Business……….……………………..……...26
   3.2. Comunicación entre los componentes……….…………………………….....26
        3.2.1. Comunicación de los componentes de la capa cliente………………....27
        3.2.2. Comunicación de los componentes de la capa Web…………….……..27
        3.2.3. Comunicación de los componentes de la capa Business…………...….28
   3.3. Servidor Aplicaciones J2EE……………………………………………….....29
        3.3.1. Contenedor Web……….………………………...….............................29
        3.3.2. Contenedor EJB……….………………………...…..............................29
        3.3.3. Servicios de los contenedores……….………………............................29
   3.4. Principales API J2EE…………………............................................................30
        3.4.1. Enterprise JavaBean Technology…........................................................31
        3.4.2. Java Servlet Technology ........................................................................31
        3.4.3. Java Server Pages Technology…...........................................................31



                                                                                                            Página 3
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



        3.4.4. JDBC…...................................................................................................32
        3.4.5. Java Naming and Directory Interface….................................................32

4. Implementación J2EE de la aplicación.....................................………....34
   4.1. Capa Cliente……….………………………...…..............................................35
        4.1.1. Java Server Faces……….………………………...…............................35
               4.1.1.1. Estructura base de una página JSP-JSF……….……………....36
               4.1.1.2. Estructura de tag JSF para la validación de usuarios………….36
   4.2. Capa Web……….………………………...…..................................................37
        4.2.1. Funciones de los componentes de la capa Web……….….....................37
               4.2.1.1. Implementación de los procesos lógicos de la aplicación…….37
               4.2.1.2. Comunicación con la capa cliente……….…………………...38
               4.2.1.3. Comunicación con la capa Business…….............................….39
   4.3. Capa Business……….………………………...…...........................................40
        4.3.1. Estrategias de conexión a bases de datos por medio de J2EE………....41
               4.3.1.1. Conexión a base de datos por medio de Session Bean………..41
               4.3.1.2. Conexión a base de datos por medio de Entity Bean……….....41
                        4.3.1.2.1. EJB CMP……….………………………...…...........41
                        4.3.1.2.2. EJB QL Query……….…………………..................42
                                   4.3.1.2.2.1. Ejemplos de EJB QL Query.......…........42
         4.3.2. Comunicación con la capa Web……….…………...............................43
               4.3.2.1. Secuencia de la comunicación con la capa Web……….…......43
   4.4. Arquitectura J2EE de toda la Aplicación……….……………………….........44
   4.5. Casos de estudio……….………………………...….......................................45
        4.5.1. Edición de monedas……….…...............................................................45
               4.5.1.1. Capa Cliente……….………......................................................45
                        4.5.1.1.1. Visualización de las monedas…………………...….45
                        4.5.1.1.2. Edición de las monedas……….…………….……...46
               4.5.1.2. Capa Web……….………………….........................................47
               4.5.1.3. Capa Business……….………………………...…...................48
        4.5.2. Ingreso de nuevas monedas……….…………………..........................48
               4.5.2.1. Capa Cliente……….……………….........................................49
                        4.5.2.1.1. Selección de alternativas………....………………...49
                        4.5.2.1.2. Navegación Web……….…………………………..49
               4.5.2.2. Capa Web……….………………………...…..........................50
               4.5.2.3. Capa Business……….………………………...…....................51
                        4.5.2.3.1. Valores consecutivos a través de la Base de Datos...51
                        4.5.2.3.2. Valores consecutivos a través de la aplicación……..52

5. Pruebas y Análisis de Resultados………………………............................54
   5.1. Pruebas de la aplicación……….………………………...................................54
        5.1.1. Implementación sistema contable Web…………………...…...............54
               5.1.1.1. Validación de Usuario……….………………………..............54



Miguel Angel Azócar Vega                                                                                   P ágina 4
                                                                                           Departamento Electrónica




               5.1.1.2. Eliminación de Moneda……….………...….............................55
        5.1.2. Cálculo del valor cuota de los Fondos……………………...….............56
   5.2. Análisis de Resultados……….……………………….....................................57
        5.2.1. Requerimientos de alto nivel……….……………………….................57
        5.2.2. Requerimientos de bajo nivel……….…………...….............................57
               5.2.2.1. Seguridad……….………………………..................................57
               5.2.2.2. Mantenimiento de la Aplicación……………..........…..............57
               5.2.2.3. Desempeño ante alta carga………………......…......................58

6. Conclusiones, Trabajo futuro....................………………………………...59
   6.1. Conclusiones.....................................................................................................59
        6.1.1. Sistemas computacionales empresariales………….…………….........59
        6.1.2. Ingeniería de Software……….………………………...…....................59
        6.1.3. J2EE……….………………………...…................................................59
        6.1.4. Módulo contable……….………………………...….............................59
   6.2. Trabajo Futuro……….………………………...…..........................................60
         6.2.1. Definición de Documentos……….………...…....................................60
         6.2.2. Definición de Plantilla de Documentos……………………….............60
         6.2.3. Generación de Libros……….………………………...….....................60
         6.2.4. Asociación de FECU……….……………………................................60

7. Referencias……..……………............................................................................62




                                                                                                               Página 5
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




Índice de Figuras
Figura 1: Modelos de Power Designer……………….……………………………...14
Figura 2: Modelo de Datos Orientado a Objetos………………………………….....14
Figura 3: Modelo de Datos Físico…………………………………………………...15
Figura 4: Elección del diagrama de secuencia UML………………………….…….16
Figura 5: Diagrama de secuencia UML……………………………………….…….16
Figura 6: Línea de vida de un objeto………………………………………….…….21
Figura 7: Foco de control…………………………………………………………...21
Figura 8: Diagrama de secuencia: Definición de tipo de cambio…………………...22
Figura 9: Arquitectura de la plataforma J2EE……………………………………….23
Figura 10: Aplicaciones Multicapas…………………………………………………24
Figura 11: Comunicación de los componentes de la capa cliente…………………...28
Figura 12: Comunicación de los componentes de la capa Web……………………..28
Figura 13: Comunicación de los componentes de la capa Business…………………29
Figura 14: Servidor J2EE y los contenedores que lo forman………………………..30
Figura 15: Interacción entre JSF y JSP-Servlet……………………………………...33
Figura 16: Estructura base de una página JSP que soporta componentes JSF……....34
Figura 17: Estructura de tag JSF para validar usuarios……………………………...35
Figura 18: Bean manejador de los datos del usuario………………………………..36
Figura 19: Pagina JSP-JSF enlazada con JavaBean de la capa Web………………..37
Figura 20: Implementación del método validar usuario………………………….....37
Figura 21: Estructura de la capa Web……………………………………………….38
Figura 22: Tabla de una base de datos, y su correspondiente EJB CMP…………....40
Figura 23: Estructura de la capa Business…………………………………………...42
Figura 24: Arquitectura MVC de la aplicación……………………………………...42
Figura 25: Arquitectura J2EE de toda la aplicación…………………………………43
Figura 26: Ejemplo de visualización de datos de una base de datos………………...44
Figura 27: Utilización de JSF para mostrar las monedas de la aplicación…………..44
Figura 28: Edición de monedas utilizando componentes JSF……………………….45
Figura 29: Código del DTO original………………………………………………...46
Figura 30: Código del DTO intermedio……………………………………………..46
Figura 31: Arquitectura modificada capa Web………………………………………47
Figura 32: Método findAllMonedas…………………………………………………47
Figura 33: Código componente JSF inputText………………………………………48
Figura 34: Código componente JSF selectOneMenu………………………………..48
Figura 35: Visualización del componente JSF selectOneMenu…………………......48
Figura 36: Extracto del archivo faces-config.xml…………………………………...49
Figura 37: Configuración gráfica de la Navegación Web……………………...........49
Figura 38: Código para transformar DTO a SelectItem……………………………..50
Figura 39: Detalle del método Select del CMP……………………………………...51
Figura 40: Implementación del método GetMaxId………………………………..…51




Miguel Angel Azócar Vega                                                                 P ágina 6
                                                          Departamento Electrónica




Figura 41: Validación de usuarios…………………………………………………..52
Figura 42: Elección del perfil del usuario………………………………………..….52
Figura 43: Validación exitosa del usuario…………………………………………..53
Figura 44: Parte página mantenedora de monedas ………………………………....53
Figura 45: Selección de una moneda para su eliminación……………….……….…53
Figura 46: Moneda eliminada……………………………………………………..…53
Figura 47: Parte de página Calculo de Valor Cuota ………………………..……….54
Figura 48: Elección de fecha de inicio ……………………………………….……..54
Figura 49: Resultado cálculo valor cuota…………………………………….……...55




Índice de Tablas
Tabla 1: Comparación de las herramientas computacionales PHP, .NET y J2EE…..10




                                                                         Página 7
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




CAPITULO 1: Introducción
El Objetivo de esta memoria fue diseñar e implementar el módulo contable de un
sistema Web, que será usado por las Administradoras Generales de Fondos.


1.1 Descripción de las administradoras generales de fondos
Las Administradoras generales de fondos, tienen como fin administrar dineros de
terceros (personas naturales y jurídicas, denominados “partícipes”) de la mejor forma
posible, mediante la inversión en instrumentos financieros.
Los fondos son el patrimonio constituido por las aportaciones de diversas personas
naturales o jurídicas, denominadas partícipes del fondo, que se agrupan bajo un
mismo objetivo de inversión, el cual tiene características particulares que lo
diferencian de otros fondos, tales como, los tipos de instrumentos financieros en que
invierte, el tipo de inversionista que recibe, el horizonte de vida del fondo, etc. Estas
características particulares de un Fondo quedan definidas en su “Reglamento Interno”
y es obligación de la Administradora velar porque se cumplan los objetivos de
inversión estipulados en este Reglamento.
El porcentaje de participación de un participe en un determinado Fondo, es
determinado por el número de cuotas que este posee. El número de cuotas de un
Fondo es fijo, y el valor de cada cuota se calcula dividiendo el Patrimonio del Fondo,
por el número total de cuotas de este. Dado que las cuotas se transan todos los días
(participes quieren vender cuotas, y otros quieren comprar cuotas), es importante
saber con exactitud el valor de cada cuota. La dificultad estriba en que el patrimonio
del fondo varía diariamente, y éste es calculado directamente de la contabilidad. De
ahí la importancia de que ésta sea llevada en forma correcta.


1.2 Problemas con los sistemas contables de las
administradoras generales de fondos
Los sistemas de las administradoras de fondos tienen sus inicios a principios del siglo
anterior, por lo cual todos los procesos de éstas eran llevados en forma manual. Con
la aparición de los computadores los datos y procesos fueron migrando
paulatinamente a sistemas informáticos. Los problemas de esta evolución, es que este
proceso no fue adecuadamente estructurado y planificado, debido principalmente a
problemas tecnológicos del momento con lo cual los distintos módulos de las
administradoras tenían problemas de comunicación de datos. Como una forma de
paliar estos problemas, se implementaron sistemas ERP, lo cual solucionó en parte el
problema pero muchos procesos siguieron haciéndose en forma manual y sigue
habiendo problemas de comunicación entre los módulos.[14]




Miguel Angel Azócar Vega                                                                 P ágina 8
                                                                 Departamento Electrónica




La situación actual es que los sistemas contables actuales no soportan todos los
eventos que deben tener un reflejo en la contabilidad, debido a esto es necesario
mantener procesos manuales de administración, valorización y contabilización de
instrumentos y operaciones financieras, para la correcta determinación del Patrimonio
del Fondo. Además éstos son de alto costo y no cuentan con niveles de seguridad,
auditoria, ni escalabilidad necesaria para la atención de distintas Administradoras.
Presentan así mismo problemas de integración con otros sistemas financieros de las
Administradoras[14].
Hay soluciones completas para todos los procesos de las administradoras, los
llamados de clase mundial, pero tienen el inconveniente de su elevado precio (cientos
de miles de dólares) y el costo de su implantación en la realidad nacional.


1.3 Objetivos del proyecto
Este proyecto surge como una solución a las problemáticas antes señaladas, siendo las
directrices de su diseño y desarrollo, el cumplimiento de tres objetivos;
1) Diseñar e implementar el módulo contable de un sistema web de Administración
de Fondos, que permita incorporar de manera paramétrica las distintas operaciones,
financieras y de negocios que puede realizar un Fondo y/o la Administradora, que
conlleven un registro contable.
2) Este módulo debe permitir el cálculo del valor cuota de los Fondos a partir de la
información contable.
3) La solución debe hacer uso de tecnologías actuales para sistemas informáticos de
estas características, específicamente el estándar J2EE.
Para cumplir con el primer objetivo del proyecto; el diseño del módulo contable, fue
crucial la utilización de principios de Ingeniería de Software, cuya aplicación al
diseño de este módulo es mostrado en detalle en el capítulo 2.
El segundo objetivo; el cálculo del valor cuota, está enmarcado dentro de los
requerimientos de la aplicación, por lo que está inserto en el diseño de ésta.
El cumplimiento del tercer objetivo, precisaba una justificación del hecho de utilizar
J2EE como herramienta computacional, la cual se muestra en la sección siguiente;


1.4 Elección de la tecnología actual para sistemas
informáticos
Independiente del tipo de tecnología seleccionada, ésta debía responder a dos
requerimientos principales; la implementación de los procesos contables e interacción
con el usuario a través de la Web.



                                                                                 Página 9
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



El primer requerimiento no es problema para la mayoría de las herramientas
tecnológicas pero la interacción con el usuario a través de la Web trae implícitos
ciertos requerimientos.


1.4.1 Requerimientos computacionales del proyecto
i) Obtención de respuestas rápidas y confiables frente a interacciones Web-Base de
Datos, independiente de las solicitudes, y usuarios que utilicen la aplicación.
ii) Niveles de seguridad acordes al tipo de transacciones que se ejecuten.
iii) Modificaciones en el programa, sean lo menos traumáticas.
Estos requerimientos, disminuyen el espectro de posibles tecnologías, siendo PHP,
.NET y J2EE, las tecnologías más conocidas que podrían cumplirlos.
Para ver cual de ellas usar, la elección se centró en el desempeño mostrado en las
áreas; seguridad, estabilidad, escalabilidad, velocidad de desarrollo, costo de
implementación y flexibilidad, ya que estas áreas incluyen los requerimientos
anteriores, pero permiten un mayor detalle para comparar las alternativas.
Pese a que PHP es muy utilizada dada su facilidad de programación [1] y por ende
alta velocidad de desarrollo, fue la primera alternativa en ser desechada ya que bajo
alta carga, presenta problemas de estabilidad y escalabilidad [2].
La opción .NET presentaba características similares en estabilidad, escalabilidad y
velocidad de desarrollo a J2EE, pero presentaba desventajas en las áreas; costo de
implementación y flexibilidad [3], por lo cual la alternativa seleccionada es J2EE. En
el capítulo 3, se da una introducción a esta tecnología, mostrando sus características
principales.
En la tabla 1 se muestra un resumen del desempeño de las herramientas
computacionales evaluadas [15];
                             PHP                .NET                J2EE
Seguridad                    Baja               Buena             Excelente
Estabilidad                  Baja             Excelente           Excelente
Escalabilidad                Nula             Excelente           Excelente
Velocidad de
desarrollo                Excelente             Buena               Buena
Costo de
implementación            Excelente              Baja               Buena
Flexibilidad              Excelente              Nula             Excelente
Tabla 1: Comparación de las herramientas computacionales PHP, .NET y J2EE




Miguel Angel Azócar Vega                                                                 P ágina 10
                                                                Departamento Electrónica




1.5 Tecnologías J2EE utilizadas
Para cumplir de la mejor forma posible los requerimientos computacionales del
proyecto, se estudió en detalle la tecnología J2EE, seleccionando las siguientes
tecnologías para la implementación de la aplicación; Java Server Faces[4], EJB Entity
Bean (CMP)[5] y EJB QL Query[6], ya que ellas mejoran y optimizan varias
funcionalidades.
Además, del estudio de la tecnología J2EE, se observó, que es altamente productivo
utilizar los “Patrones de diseño J2EE” (recomendaciones de programación para
solucionar problemas comunes), siendo los más adecuados para este proyecto los
patrones Session Facade[7], DTO (Data Transfer Object)[8], Business Delegate[9] y
Service Locator[10].
En el capítulo 4, se muestra como estas tecnologías y patrones de diseño, son
aplicados en el desarrollo de la aplicación.




                                                                                Página 11
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



CAPITULO 2: Diseño Orientado a Objetos.
El diseño orientado a objetos, se enmarca dentro del área de la Ingeniería de
Software, cuyo objetivo es establecer y usar principios ingenieriles para obtener con
el mejor desempeño posible, software confiable, que opere eficaz y eficientemente en
máquinas reales.
Las ventajas principales del diseño orientado a objetos son que mejora la captura y
validación de requerimientos al aproximar los conceptos del modelado a las entidades
del mundo real, facilitando la construcción, mantenimiento y reutilización, de todas
las partes del proyecto.


2.1 Metodología
Se utilizan metodologías al desarrollar software ya que ellas ayudan en la
planificación y evaluación de los proyectos, ya que imponen un proceso disciplinado
sobre el desarrollo del software, con el fin de hacerlo más predecible y eficiente.
La metodología guía en el análisis e implementación del proyecto fue RUP (Rational
Unified Process). No se pudo seguir al pie de la letra lo sugerido por la metodología,
ya que el grupo de trabajo era heterogéneo, y con un fuerte enfoque industrial, más
que informático.
Esta metodología se caracteriza por ser iterativa e incremental, estar centrada en la
arquitectura y guiada por los casos de uso.
RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al término
de cada ciclo. Las fases de cada ciclo son; inicio, elaboración, construcción y
transición. El desarrollo del proyecto, fue dividido en etapas, las cuales formaban las
fases de cada ciclo.


2.1.1 Arquitectura de cada ciclo de desarrollo
Fase Inicial:
Etapa 1: Definición de requerimientos
Etapa 2: Creación de casos de uso asociados a los requerimientos

Fase de Elaboración
Etapa 3: Creación de base de datos que soporte los requerimientos

Fase de Construcción



Miguel Angel Azócar Vega                                                                 P ágina 12
                                                               Departamento Electrónica




Etapa 4: Desarrollo de prototipos funcionales

Fase de Transición
Etapa 5: Pruebas de Prototipos
Etapa 6: Si Etapa 5 es exitosa, se mejoran los prototipos.
       Si Etapa 5 fracasa, se realiza el proceso completo de nuevo, buscando los
motivos del fallo.


2.2 Herramientas utilizadas
En el proceso de modelado de la aplicación, es imprescindible contar con
herramientas profesionales, que permitan una rápida creación de modelos, y una fácil
manipulación de ellos. Pese a que las herramientas Open Source han alcanzado
relativa madurez, todavía no presentan las características de las herramientas
comerciales, por lo que se optó por utilizar estas últimas.


2.2.1 Power Designer
Para modelar la base de datos se utilizó la herramienta gráfica de modelado Power
Designer 12, de Sybase. Esta herramienta provee un enfoque de modelado de los
procesos de negocios, que alinea estos y las últimas tecnologías informáticas,
combina varias técnicas de modelado de datos, por ejemplo; UML, Business Process
Modeling, etc, las cuales son fácilmente montables en los principales ambientes de
desarrollo, como Java/J2EE (se pueden crear en forma automática Entity Beans),
Eclipse (a través de un plugin se puede hacer el modelo directamente), etc. Permite
hacer varios tipos de modelos; Conceptual, Orientado a Objetos, Físico, entre otros.
En la Figura 1, se muestra un detalle de los tipos de modelos;




                                                                             Página 13
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




                           Figura 1: Modelos de Power Designer
Dado el enfoque del proyecto, en un primer momento se trató de crear un modelo de
la base orientado a objetos, con Java como lenguaje de objetos, pero esto no prosperó,
dado el desconocimiento de Java, su definición de tipos, y la forma en que se
presentaba el modelo, por parte de algunos miembros del grupo de análisis. La
solución, fue crear un modelo de datos físico, el cual era conocido por todos. En la
figura 2 se muestra un ejemplo de modelado de datos orientado a objetos y en la
figura 3 su respectivo modelo físico.




                      Figura 2: Modelo de Datos Orientado a Objetos



Miguel Angel Azócar Vega                                                                 P ágina 14
                                                                Departamento Electrónica




                          Figura 3: Modelo de Datos Físico
Otra ventaja que posee esta herramienta, es que mejora mucho la productividad, ya
que todos los cambios que se deba hacer a la base, se hacen desde ella, por ejemplo,
en el desarrollo del proyecto, debido a nuevos requerimientos, se debía modificar la
estructura de algunas tablas. Utilizando fuentes de datos ODBC, la herramienta se
comunicaba con la base, y hacía los cambios en forma automática, aunque esas tablas
tuviesen datos.


2.2.2 Microsoft Office Visio
Para realizar los diversos diagramas UML que requería la aplicación, se utilizó
Microsoft Office Visio. Esta herramienta además de permitir realizar varios
diagramas de software (diagramas UML, diagramas de flujos de datos, etc), permite
realizar diagramas de procesos de varias ramas de la ingeniería; eléctrica, mecánica,
industrial, etc.
En las figuras 4 y 5 se muestran los pasos a seguir en la creación de un diagrama de
secuencia UML:




                                                                              Página 15
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




                    Figura 4: Elección del diagrama de secuencia UML




Miguel Angel Azócar Vega                                                                 P ágina 16
                                                                  Departamento Electrónica




                        Figura 5: Diagrama de secuencia UML


2.3 Definición de requerimientos
Los requerimientos específicos que debía cumplir el módulo contable, eran varios,
por lo que se optó por detallar sólo algunos;
1) El sistema debe permitir definir la estructura de cuentas que se utilizará
2) El plan de cuentas debe estar asociado a la Administradora, y al tipo de fondo
(fondo mutuo, fondo de inversión, fondo de inversión privado, etc.)
3) Cada fondo tiene una contabilidad independiente
4) La contabilidad del fondo se lleva en la moneda definida para el fondo.
5) La Administradora tiene una contabilidad independiente
6) El sistema debe permitir la definición e ingreso de valores de distintos índices. Los
valores que se deben guardar son; periodo de desfase, mes, año y valor
7) El sistema debe permitir el ingreso de monedas. Por ejemplo, “dólar observado”




                                                                                Página 17
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



8) El sistema debe permitir definir las posibles paridades cambiarias (por ejemplo,
“dólar observado respecto de “pesos”) y posteriormente, permitir el ingreso del tipo
de cambio entre dos monedas, para una determinada fecha de publicación de la
moneda.
9) El sistema debe trabajar con 4 perfiles de usuario; administrador de sistema,
usuario de sistema, administrador administradora, usuario administradora
10) Un mismo usuario, puede tener más de un perfil


2.4 Casos de uso
Se muestran sólo algunos casos de uso, dada el gran número de ellos;


2.4.1 Definición de tipo de cambio
Actor: Usuario.
Descripción: El usuario define e ingresa en el sistema un nuevo tipo de cambio.

Flujo principal:
    a) Usuario selecciona la opción “definición de tipos de cambio”, en la página
       principal del sistema, y aprieta el botón OK para acceder a ella.
    b) El sistema retorna la página “Definición de tipos de cambio”, la cual contiene
       dos secciones; la primera muestra los tipos de cambio existentes, y la segunda
       dos List Menu, con las monedas definidas en el sistema.
    c) Usuario selecciona la moneda de origen (primer List Menu) y la moneda de
       destino (segundo List Menu).
    d) Usuario aprieta el botón OK para ingresar el nuevo tipo de cambio.
    e) El sistema almacena el nuevo tipo de cambio, y retorna la misma página
       “Definición de tipos de cambio”, incluyendo ahora en su primera sección el
       tipo de cambio ingresado.


2.4.2 Definición de índice
Actor: Usuario.
Descripción: El usuario define e ingresa en el sistema un nuevo índice económico.




Miguel Angel Azócar Vega                                                                 P ágina 18
                                                                 Departamento Electrónica




Flujo principal:
   a) El usuario selecciona la opción “definición de índices”, en la página principal
      del sistema, y aprieta el botón OK para acceder a ella.
   b) El sistema retorna la página “Definición de índices”, la cual contiene dos
      secciones; la primera muestra los índices existentes, y la segunda dos Input
      Text; uno para el nombre del nuevo índice y el otro para el periodo de desfase.
   c) El usuario ingresa el nombre del nuevo índice y el período de desfase.
   d) El usuario aprieta el botón OK para ingresar el nuevo índice.
   e) El sistema almacena el nuevo índice, y retorna la misma página “Definición
      de índices”, incluyendo ahora en su primera sección el índice ingresado.


2.4.3 Validación de usuario
Actor: Usuario.
Descripción: El usuario se valida en el sistema, y obtiene una página con opciones
asociadas a su perfil.

Flujo principal:
   a) El usuario accede al sitio Web de la aplicación.
   b) El sistema retorna la página de bienvenida, la cual contiene un formulario con
      un Input Text, un Input Secret y un List Menu, para ingresar el rut, la
      contraseña, y seleccionar el perfil del usuario.
   c) El usuario ingresa su rut, su contraseña, y selecciona el perfil.
   d) El usuario aprieta el botón OK para validarse en el sistema.
   e) El sistema retorna la página principal del sistema, con las opciones asociadas
      al perfil.


2.5 Diagramas de secuencias UML
Los diagramas UML de secuencia y de colaboración (llamados diagramas de
interacción) se utilizan para modelar los aspectos dinámicos de un sistema. Ellos
constan de un conjunto de objetos, sus relaciones y los distintos mensajes que
intercambian.
La diferencia entre los diagramas UML de secuencia y de colaboración, es que los
primeros destacan el orden temporal de los mensajes, mientras que los segundos



                                                                               Página 19
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



destacan la organización estructural de los objetos que envían y reciben mensajes.
Pese a esto, ambos diagramas son semánticamente equivalentes, permitiendo pasar de
uno a otro sin perder información [REF???].
Se optó por crear sólo diagramas de secuencia, ya que ellos reflejan más claramente
lo que pasa entre los objetos, al funcionar la aplicación.
Los detalles sintácticos de los diagramas de secuencia son los siguientes;

2.5.1 Detalles sintácticos de los diagramas de secuencia
La línea de vida de un objeto, es la línea discontinua vertical, la cual representa la
existencia de ese objeto a lo largo de un periodo de tiempo. La figura 6 detalla esto en
forma gráfica.




                            Figura 6: Línea de vida de un objeto
El foco de control, es un rectángulo delgado que representa el periodo de tiempo
durante el cual un objeto ejecuta una acción. La figura 7 detalla esto en forma gráfica.




Miguel Angel Azócar Vega                                                                 P ágina 20
                                                               Departamento Electrónica




                              Figura 7: Foco de control
A continuación, se muestran un de diagrama de secuencia de la aplicación, el cual se
obtuvo del respectivo caso de uso.

2.5.2 Ejemplo de diagrama de secuencia
2.5.2.1 Definición de tipo de cambio




                                                                             Página 21
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




Figura 8: Diagrama de secuencia: Definición de tipo de cambio




Miguel Angel Azócar Vega                                                                 P ágina 22
                                                                  Departamento Electrónica




CAPITULO 3: Introducción a J2EE
El objetivo de este capítulo es hacer una revisión de la tecnología J2EE, viendo sus
principales características y fortalezas.
 Lo usual es que el desarrollo aplicaciones empresariales sea difícil ya que ellas
requieren muchas líneas de código para manejar las transacciones, el estado de estas,
los recursos, etc. El objetivo de esta memoria es un ejemplo de ésto; el desarrollo de
un módulo contable operable a través de la Web. Este panorama empeora si se busca
separar la aplicación en múltiples capas, con límites claros entre ellas, con el fin de
hacer más fácil y rápido el mantenimiento de la aplicación.
 Para solucionar esta problemática Sun Microsystems, en conjunto con otras
importantes empresas; Oracle, IBM, entre otras, desarrollaron un conjunto de
estándares y especificaciones orientadas al desarrollo de aplicaciones empresariales
distribuidas, llegando a ser en la actualidad, la plataforma estándar para desarrollar
aplicaciones empresariales. En la figura 9 se muestra la arquitectura de esta
plataforma.




                   Figura 9: Arquitectura de la plataforma J2EE [4]
La plataforma se basa en componentes para proveer un entorno multicapa, distribuido
y un modelo transaccional a las aplicaciones empresariales. Gracias al enfoque de
múltiples capas, la lógica de la aplicación puede ser separado en 3 partes principales,
cliente, servidor y base de datos, siendo ésta la estrategia usada en el desarrollo de la
aplicación de esta memoria. Esto trae la gran ventaja que, poniéndose de acuerdo en
delineamientos generales, estás partes pueden ser desarrolladas por equipos



                                                                                Página 23
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



independientes y probadas en forma autónoma, dando gran flexibilidad a la creación
de la aplicación principal, y disminuyendo el tiempo necesario para su creación y
puesta en marcha. En la figura 10 se muestra como ejemplo la estructura de dos
aplicaciones multicapa.




                          Figura 10: Aplicaciones Multicapas [11]
La plataforma provee un modelo unificado de seguridad, control flexible de las
transacciones y soporte de servicios Web a través de un intercambio de datos
integrados en XML, basado en estándares y protocolos abiertos.
En resumen, las aplicaciones J2EE se forman de múltiples capas, las cuales a su vez
están formadas por componentes, los cuales habitan en distintas máquinas, y prestan
distintos servicios. Estas características fueron ampliamente utilizadas y
aprovechadas al desarrollar la aplicación.


3.1 Componentes J2EE
Un componente J2EE, es una unidad funcional autónoma de software, que está
integrada en una aplicación J2EE que se comunica con otros componentes. Éstos son
modulares, estandarizados y reutilizables, proveyendo J2EE un completo conjunto de
servicios a estos componentes manejando muchas de las funciones de estos de forma
automática.
Los componentes de J2EE se escriben en el lenguaje de programación Java y se
compilan de la misma manera que cualquier programa del lenguaje. La diferencia
entre los componentes de J2EE y las clases "estándar" de Java es que los
componentes J2EE están integrados en una aplicación J2EE, son verificados para que
se integren bien y en conformidad con la especificación J2EE y son desplegados en
la fabricación de la aplicación y su posterior puesta en marcha.




Miguel Angel Azócar Vega                                                                 P ágina 24
                                                                  Departamento Electrónica




Para reducir costos y aumentar la velocidad en el diseño y desarrollo de aplicaciones,
J2EE provee componentes base, enfocados al diseño, al desarrollo, al montaje, y al
despliegue de aplicaciones empresariales. Estos componentes se clasifican de acuerdo
a la capa en la que se utilizan.

3.1.1 Componentes JavaBeans
Pese a ser muy utilizados en el desarrollo de la aplicación de este proyecto los
componentes JavaBeans no son considerados componentes J2EE por la
especificación J2EE, sino que pertenecen a un modelo de componentes creado por
Sun.
Éstos componentes no pertenecen a una capa particular de la aplicación, por lo que se
utilizan para manejar los flujos de datos entre una aplicación cliente o applet, y
componentes Web, o entre componentes J2EE y una base de datos.
En este proyecto estos componentes fueron ampliamente utilizados para comunicar la
capa Web con la capa Business y para comunicación interna de la capa Web. En estos
casos los componentes JavaBean reciben el nombre de DTO ya que provienen de la
aplicación del patrón de diseño Data Transfer Object.
Las propiedades de estos componentes solo pueden ser accedidas y manejadas por
medio de los métodos set y get que ellos proveen. Debido a estas características, ellos
son simples en su diseño y puesta en funcionamiento, pero deben estar conforme a las
convenciones de nombres y diseño especificadas en la arquitectura de componentes
JavaBeans [11].


3.1.2 Componentes de la capa cliente
Son componentes de la capa cliente las Aplicaciones clientes, los clientes Web y los
applets.
La aplicación sólo utilizó los clientes Web, ya que las Aplicaciones clientes se
utilizan cuando se quiere o necesita una interacción directa con el usuario, sin pasar a
través del navegador Web. Los applets tampoco se utilizaron, ya que en general
presentan problemas, y sus fortalezas; despliegue de figuras dinámicas u otros
aspectos gráficos no se requerían.

3.1.2.1 Aplicaciones Clientes
Las aplicaciones clientes proporcionan una forma para que los usuarios realicen
tareas que requieren una abundante interfaz de usuario, la cual puede ser provista por
un lenguaje de marcas, como HTML o XML. Lo usual es que tengan una interfaz
gráfica de usuario, creada a partir de Swing o AWT, o en su defecto, una interfaz de
línea de comandos.



                                                                                Página 25
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



Las aplicaciones clientes tienen acceso directo a los EJB. Sin embargo, si los
requisitos de la aplicación lo requieren, una aplicación cliente puede abrir una
conexión HTTP para establecer comunicación con los Servlet de la capa Web.


 3.1.2.2 Clientes Web
Son la forma más extendida de que los usuarios interactúen con las aplicaciones J2EE
dada su facilidad de uso y desarrollo. Éstos constan de dos partes;
1) Páginas Web dinámicas, que contienen varios tipos de lenguaje de marcas
(HTML, XML, etcétera), y que son creadas por los componentes Web, y
2) Un navegador, el cual se encarga de mostrar las páginas dinámicas al usuario.
Los clientes Web son llamados clientes delgados, ya que ellos no hacen
requerimientos a las bases de datos, no ejecutan reglas de negocio complejas y no se
conectan con aplicaciones. Las operaciones duras, son ejecutadas por los EJB, los
cuales aplican la seguridad, la velocidad, los servicios y la confiabilidad de las
tecnologías del servidor J2EE.


  3.1.2.3 Applets
Un applet, es una pequeña aplicación cliente, escrita en el lenguaje de programación
Java, que se ejecuta en la máquina virtual de Java, instalada en el navegador del
cliente.
El problema con los applets, es que el cliente necesita que el Java Plug-in funcione
adecuadamente, y que el archivo de la política de la seguridad del cliente esté en
orden, para que el applet se ejecute con éxito en el navegador. Debido a estas
limitantes, la utilización de componentes Web es la manera más extendida para
interactuar con el usuario, ya que no presentan estas restricciones.


3.1.3 Componentes de la capa Web
Son componentes de la capa Web los Java Servlet y las Java Server Pages (JSP). En
la aplicación no se utilizaron directamente los Java Servlet sino que la tecnología Java
Server Faces, la cual está construida sobre la tecnología Java Servlet, logrando de esta
manera otorgar mayores facilidades de desarrollo. En el capítulo 4, sección 1.1 se da
mayores detalles de esta tecnología.


 3.1.3.1 Java Servlet




Miguel Angel Azócar Vega                                                                 P ágina 26
                                                                   Departamento Electrónica




Los servlets son clases java, que se utilizan para extender las capacidades de los
servidores Web. Ellos procesan peticiones y construyen las respuestas a estas
peticiones en forma dinámica. Están especializados en el manejo de peticiones Web,
pudiendo crear ellos mismos páginas Web, o comunicarse con las JSP, entregándoles
los datos requeridos.
Cuando se trabaja sólo con contenedores Web (Tomcat por ejemplo), los servlet son
los encargados de manejar toda la lógica del negocio, además de comunicarse con las
bases de datos.


 3.1.3.2 Java Server Pages
Estos componentes permiten a los diseñadores y desarrolladores Web, un rápido
desarrollo y fácil mantenimiento de páginas Web dinámicas, al separar la interfaz del
usuario de la generación del contenido, permitiendo a los diseñadores cambiar todo el
diseño de la página, sin alterar su contenido dinámico.


3.1.4 Componentes de la capa Business
Son componentes de la capa Business los tres tipos de EJB; los Session Bean, los
Entity Bean y los Message-Driven Bean. En la aplicación, sólo los últimos no fueron
utilizados.


 3.1.4.1 Session Bean
El objetivo de los Session Bean es realizar tareas para los clientes, evitando a éstos la
complejidad de realizar éstas dentro del servidor. Para ello el cliente invoca los
métodos del bean.
La interacción con estos beans es similar a una sesión interactiva, yo hablo, y me
responden. La comunicación que se establece entre el cliente y el bean, no es
persistente, ya que los datos surgidos de esta comunicación, no son guardados en una
base de datos.
Una vez que el cliente termina la comunicación con el bean, todos los datos asociados
a la comunicación, se pierden, con lo cual, no hay forma de establecer relaciones
entre el cliente y el bean una vez que la comunicación termina.


 3.1.4.2 Entity Bean
Los Entity Beans representan objetos de un mecanismo de almacenaje persistente, por
lo general este mecanismo de almacenaje persistente es una base de datos.
Típicamente cada entity bean representa una tabla de una base de datos y cada




                                                                                 Página 27
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



instancia de él una fila de esa tabla. Se dice que los entity bean son persistentes, ya
que cuando la comunicación con el cliente termina los datos de la comunicación son
guardados.


 3.1.4.3 Message-Driven Bean
Los message-driven beans son utilizados para procesar mensajes asincrónicos. Su
funcionamiento, es similar a los event listener de las interfaces gráficas, con la
diferencia, que ellos no manejan eventos, sino que mensajes JMS.
Los mensajes pueden ser enviados por cualquier componente J2EE (otro EJB, un
Servlet, una aplicación cliente, etc.), o por un aplicación o sistema JMS que no utilice
tecnología J2EE


3.2 Comunicación entre los componentes
Para el desarrollador, todo el proceso de comunicación entre los distintos
componentes que forman parte de una aplicación J2EE es transparente, ya que los
detalles de bajo nivel; protocolo de comunicación, manejo de errores, etc. es
manejado por el Servidor de aplicaciones J2EE.


3.2.1 Comunicación de los componentes de la capa cliente
En la figura 11, se muestran los tipos de comunicación que pueden tomar los
componentes de la capa cliente. Como se ve en la figura 11, estos componentes se
pueden comunicar directamente con la capa Business, o comunicarse con ella a través
de la capa Web.




          Figura 11: Comunicación de los componentes de la capa cliente [11]




Miguel Angel Azócar Vega                                                                 P ágina 28
                                                               Departamento Electrónica




Al evaluar el tipo de comunicación a usar, hay que ver las ventajas y desventajas que
esto trae. En general, la comunicación utilizando la capa Web como intermediaria,
permite que la aplicación sea más fácil de distribuir, desplegar y manejar, pero la
utilización de la comunicación directa trae consigo una mejor percepción de la
funcionalidad de la aplicación por parte del usuario. Debido a los requerimientos de
la aplicación de esta memoria y a las ventajas que trae el enfoque de tres capas, la
comunicación de los componentes de la capa cliente se hace a través de la capa Web.


3.2.2 Comunicación de los componentes de la capa Web
En la figura 12, se ve la forma en que se comunican los componentes de la capa Web,
con los demás componentes J2EE. Se aprecia que esta capa incluye los componentes
JavaBeans, los cuales son opcionales de usar, no obstante, en la aplicación de la
memoria fueron ampliamente utilizados.




         Figura 12: Comunicación de los componentes de la capa Web [11]

3.2.3 Comunicación de los componentes de la capa Business
En la figura 13 se muestra como se comunican los componentes de la capa Business
con el resto de los componentes de las demás capas, a la vez que se aprecia en su
totalidad la comunicación que existe entre los diversos componentes.




       Figura 13: Comunicación de los componentes de la capa Business [11]



                                                                             Página 29
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



La comunicación entre los EJB y el resto de componentes puede tomar dos caminos
principales; en el menos utilizado los EJB reciben datos de las aplicaciones cliente,
los procesan y los envía a la capa EIS para su almacenamiento. También recuperan
los datos almacenados en la capa EIS, procesan estos y los envía al programa del
cliente.
En el camino más utilizado, el cual se utilizó en la aplicación de ésta memoria, los
EJB reciben los datos de la capa Web (de los Servlet o los JavaBeans), los procesan y
los envía a la capa EIS para su almacenamiento. También recuperan los datos
almacenados en la capa EIS, los procesan y los envía a los componentes que residen
en la capa Web.


3.3 Servidor de aplicaciones J2EE
Otro aspecto importante que especifica el estándar J2EE son los servidores de
aplicaciones o servidores J2EE. Ellos son los encargados de entregarle a los
componentes las funcionalidades que los hacen eficientes, productivos, etc., al
manejar muchas de las funcionalidades de éstos en forma automática. En la
aplicación, el servidor de aplicaciones que se utilizó fue JBoss.
Los servidores de aplicaciones, están formados por un contenedor Web, y un
contenedor EJB, como se muestra en la figura 14;




            Figura 14: Servidor J2EE y los contenedores que lo forman [11]
Los contenedores son la interfaz entre un componente y las funcionalidades que se
entregan a ese componente. Antes de crear un componente, ya debe existir el
contenedor que lo soporte, y entra en funcionamiento cuando es desplegado dentro de
ese contenedor.




Miguel Angel Azócar Vega                                                                 P ágina 30
                                                                 Departamento Electrónica




3.3.1 Contenedor Web
Se encarga de administrar la ejecución de los componentes JSP y los servlet de las
aplicaciones J2EE. El contenedor Web que se utilizó en la aplicación fue Tomcat.

3.3.2 Contenedor EJB
Se encarga de administrar la ejecución de los distintos EJB. El contenedor EJB que se
utilizó en la aplicación fue JBoss, el cual tiene el mismo nombre que el servidor de
aplicaciones que lo contiene.

3.3.3 Servicios de los contenedores
La arquitectura de J2EE proporciona servicios configurables a los distintos
componentes, manejando estos servicios por medio de los contenedores. Gracias a
esto, los componentes de una aplicación, dentro de la misma aplicación, pueden
funcionar en forma diferente, dependiendo en donde ellos son desplegados. Por
ejemplo, un EJB puede tener ajustes de seguridad que le permitan un cierto nivel de
acceso a los datos de la base de datos, en un ambiente de producción, y otro nivel de
acceso a la base de datos en un ambiente de desarrollo.
Los contenedores también manejan servicios no configurables, tales como los ciclos
de vida de los EJB y los servlets, el manejo de los recursos de las conexiones a la
base de datos, la persistencia de los datos y el acceso a las distintas API´s de J2EE.
Aunque la persistencia de los datos es un servicio no configurable, J2EE permite que
se sobrescriba el manejador de la persistencia del contenedor, incluyendo el código
necesario en la implementación del EJB cuando se desea tener más control que la que
provee el manejador de la persistencia del contenedor. Por ejemplo, puede ser que se
utilice un bean que maneje la persistencia, para implementar un propio buscador de
métodos, o crear un caché construido según las especificaciones de la base de datos


3.4 Principales API J2EE
Las API, o interfaces para la programación de Aplicaciones, son las herramientas que
dispone el estándar para crear las distintas aplicaciones J2EE. Las utilizadas en la
aplicación fueron; Enterprise JavaBeans Technology, Java Server Pages Technology
y Java Naming and Directory Interface. Dada la importancia de las API Java Servlet
Technolog y JDBC también se agregaron en esta revisión.


3.4.1 Enterprise JavaBeans Technology
Los EJB son bloques funcionales ya creados, los cuales pueden ser usados en forma
individual o con otros EJB. Los EJB tienen campos y métodos que implementan



                                                                               Página 31
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



distintos módulos. Interactúan a menudo con las bases de datos ya que implementan
en forma automática operaciones de acceso rápidas a éstas.
Una de las ventajas de utilizar entity beans es que no es necesario escribir ningún
código SQL o utilizar la API JDBC para realizar operaciones de acceso a las bases de
datos. Sin embargo, si se anula o sobrescribe el manejador de la persistencia del
contenedor, o se utilizan session beans que tengan acceso a la base de datos, se debe
utilizar la API JDBC. Hay tres tipos de EJB: session beans, entity beans, y message-
driven beans.


3.4.2 Java Servlet Technology
Esta API es usada para que el programador defina clases servlet específicas para la
Web. Estas clases son usadas para extender la capacidad de los servidores que tienen
aplicaciones que están siendo accedidas vía Web.
Las clases servlet pueden responder a cualquier tipo de requerimientos, no sólo Web,
pero los mayores usos de ellos se dan en este campo.


3.4.3 Java Server Pages Technology
Esta API permite que se pongan trozos del código de un servlet directamente en un
documento de texto. Con esto se crean páginas Web JSP, las cuales son documentos
de texto que contiene dos tipos de datos; estáticos (código HTML, WML o XML) y
elementos JSP, los cuales determinan cómo la página construirá el contenido
dinámico


3.4.4 JDBC
Esta API permite invocar comandos SQL a través de métodos de programación de
Java. Se puede utilizar esta API en un EJB cuando se sobrescribe el manejador de la
persistencia del contenedor, o cuando un session bean accede a las bases de datos.
También se puede también utilizar ésta API desde un servlet o de una página JSP para
tener acceso a la base de datos directamente sin pasar a través de los EJB.
JDBC tiene dos partes: una interfaz a nivel de aplicación, usada por los componentes
de la aplicación para acceder a la base de datos, y un servicio para unir el driver
JDBC a la plataforma J2EE.


3.4.5 Java Naming and Directory Interface



Miguel Angel Azócar Vega                                                                 P ágina 32
                                                               Departamento Electrónica




Esta API, más conocida como JNDI, proporciona funciones de identificación y
supervisión, al proveer clases con métodos para realizar estas funciones, como por
ejemplo; asociar atributos con objetos, y buscar objetos que usen esos atributos.
Usando JNDI, una aplicación J2EE puede almacenar y recuperar cualquier tipo de
objeto Java.
J2EE provee a las aplicaciones cliente, a los EJB, y a los componentes Web, acceso a
un ambiente JNDI. Este ambiente JNDI permite que un componente sea modificado
sin la necesidad de acceder o de cambiar el código fuente de ese componente. El
contenedor donde habita el componente, implementa y provee el ambiente JNDI del
componente, permitiéndole a este acceder a la identificación proporcionada por el
sistema y a los objetos definidos por el usuario.
Como JNDI es independiente de una implementación específica, las aplicaciones
pueden utilizar JNDI para tener acceso a múltiples servicios de identificación y
supervisión, incluyendo servicios existentes de identificación y supervisión, tales
como; LDAP, NDS, DNS, y NIS. Esto permite que aplicaciones J2EE coexistan con
aplicaciones y otros sistemas de identificación.




                                                                             Página 33
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




CAPITULO 4: Implementación J2EE de la aplicación
Dada las ventajas del enfoque de capas para el desarrollo de aplicaciones
empresariales, la aplicación se implementó en tres capas: capa cliente, capa Web y
capa Business, logrando de ésta forma separar claramente las responsabilidades que
cada capa tenía, logrando un mayor control y velocidad de desarrollo de la aplicación.



4.1 Capa Cliente
Dados los requerimientos de la aplicación, se necesitaban páginas dinámicas que
interactuaran con el usuario, y que respondieran a eventos gatillados por éste. Las
páginas JSP son dinámicas, pero la interacción con el usuario no es tan fina como la
que se necesitaba, además que no provee grandes capacidades para interactuar con el
usuario.
La solución más común para resolver estas dificultades es utilizar JavaScript, ya que
este pseudo lenguaje provee muchas funcionalidades para interactuar con el usuario y
responder rápida y vistosamente a eventos gatillados por éste. El problema con
JavaScript, es que no es compatible en todos los navegadores, su funcionamiento
depende del nivel de seguridad que el navegador tiene asignado, y ensucia el código
de las páginas en las cuales se incluye, lo cual hace complicado la mantención y
mejoras de las páginas en las que se encuentra.
Investigando el estándar J2EE, los creadores de ésta desarrollaron la tecnología Java
Server Faces (JSF), como una forma de resolver lo hecho por JavaScript, en el ámbito
que nos interesaba en este proyecto, interacción a eventos gatillados por el usuario.
Otra alternativa estudiada, fue la tecnología Struts, pero esta resultó ser más débil que
JSF [12].


4.1.1 Java Server Faces
Esta tecnología es un conjunto de API´s para crear interfaces de usuario y manejar
sus estados, manejando eventos y realizando validaciones de los datos de entrada.
Permite definir reglas de navegación de las páginas, y permite mostrar la información
en múltiples idiomas
Esta tecnología se utiliza dentro de las páginas JSP, incluyendo los respectivos tags
dentro de ella, los cuales representan componentes JSF.




Miguel Angel Azócar Vega                                                                 P ágina 34
                                                                 Departamento Electrónica




                 Figura 15: Interacción entre JSF y JSP-Servlet [13]
JSF permite una separación clara entre la presentación, y la lógica de la aplicación,
manteniendo una fácil conexión entre ellas. El diseñador de las páginas sólo debe
conocer qué hace un tipo de tag JSF para ponerlo en el lugar que él decida. El
programador J2EE, se encarga de darle la funcionalidad al tag.
La estructura base de una página JSP que soportar componentes JSF se muestra en las
secciones siguientes.


4.1.1.1 Estructura base de una página JSP-JSF
La figura 16 muestra la estructura base de una página JSP que soporta componentes
JSF. Los taglib, indican las bibliotecas donde se encuentra la definición de los
distintos componentes JSF (los h, son los objetos básicos de HTML; form, Text,
commandButton, etc, mientras que los f son los objetos más avanzados de JSF;
actionListener, validador, converter, etc.). Los tag <f:view> </f:view>, se utilizan
para demarcar donde existirán componentes JSF, permitiendo al contenedor Web,
centrarse en esa parte para manejar esos componentes. Es importante hacer notar que
sin estos tags ningún componente JSF funciona.




     Figura 16: Estructura base de una página JSP que soporta componentes JSF




                                                                               Página 35
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



4.1.1.2 Estructura de tag JSF para la validación de usuarios
Un caso bastante común que se da con las páginas Web es la validación de usuarios a
través de un nombre de usuario y contraseña. En la figura 17 se muestra la estructura
de tags que debiese poner el diseñador de la página para lograr esto.




  Figura 17: Estructura de tag JSF para validar usuarios
El diseñador debe usar los tag <h:form> </ h:form>, para demarcar y definir un
formulario, el tag <h:inputText> </h:inputText>, se utiliza para entrada de texto
estándar, mientras que el tag <h:inputSecret> </h:inputSecret>, permite el ingreso de
texto, pero tienen la gracia, que el usuario no ve el texto ingresado, solo la cantidad
de letras. El tag <h:commandButton> </h: commandButton>, define un botón, el cual
utilizará el usuario, para gatillar la validación de sus datos.


4.2 Capa Web
Los componentes de esta capa, tenían tres funciones principales;


4.2.1 Funciones de los componentes de la capa Web
1) Implementar los procesos lógicos requeridos por la aplicación
2) Comunicarse con la capa cliente y
3) Comunicarse con la capa de negocios




Miguel Angel Azócar Vega                                                                 P ágina 36
                                                                Departamento Electrónica




A continuación, se muestra como los componentes cumplían estas funciones.


4.2.1.1 Implementación de los procesos lógicos de la aplicación
Para implementar los procesos lógicos requeridos, la capa Web se dividía en varios
Java Bean, cada uno especializado en algo (por ejemplo; definición y modificación de
tipos de cambio, inserción de valores de tipo de cambio, etc.) con el fin de que la
mantención y posteriores modificaciones a ella fuese fácil y rápida.
La lógica específica de cada requerimiento, no fue difícil de implementar, gracias a
que el lenguaje Java, además de poseer todas las ventajas de un lenguaje orientado a
objetos (herencia, polimorfismo, comunicación a través de métodos, etc.), tiene una
poderosa API disponible, la cual implementa muchos objetos extremadamente útiles,
por ejemplo, los Vectores, tablas Hash, etc.


4.2.1.2 Comunicación con la capa cliente
Para la comunicación con la capa cliente, en un primer momento se pensó en utilizar
la clase Servlet, pero el problema de ésta, es que el desarrollador aún debe
implementar muchas funciones de bajo nivel, por ejemplo, implementar los métodos
get y post de HTTP, lo cual redunda en una baja velocidad de desarrollo, a la vez que
se presta para cometer errores.
JSF, permite comunicarse en forma transparente con JavaBeans, utilizando los
métodos set de estos para enviarle los datos, y llamando los métodos get de estos para
capturar datos. El contenedor Web, es el que se encarga de manejar el protocolo
HTTP, siendo todo transparente para el programador.
Por ejemplo, tomando como base la sección 4.1.1.1 (estructura de tag JSF para la
validación de usuarios), se crea un bean para manejar los datos que vienen de la
página JSP; el login y el password del usuario:




                                                                              Página 37
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




                    Figura 18: Bean manejador de los datos del usuario


Y la página JSP, queda como sigue:




            Figura 19: Pagina JSP-JSF enlazada con JavaBean de la capa Web
Como se aprecia en la figura, en el tag <h:commandButton>, se especifica que el
Bean debe implementar un método para manejar la validación del usuario.
Dependiendo de la respuesta del Bean, JSF puede derivar al usuario hacia una página
u otra.




Miguel Angel Azócar Vega                                                                 P ágina 38
                                                                  Departamento Electrónica




                Figura 20: Implementación del método validar usuario

4.2.1.3 Comunicación con la capa Business
Si sólo se hubiese contado con un contenedor Web (por ejemplo Tomcat), dentro de
los Java Beans habría estado el código para realizar las conexiones a la base de datos.
Esto no es óptimo, ya que el contenedor de EJB tiene muchas funcionalidades y
ventajas para manejar bases de datos.
Como se contaba con un servidor de aplicaciones (Contenedores Web y EJB), en un
primer momento se pensó en comunicar directamente los Java Bean con el
contenedor de EJB, para recibir los datos de la base de datos. Estudiando bibliografía
relacionada con manejo de bases de datos en J2EE, se vio que esto no era un buen
camino, ya que cambios en la lógica de los EJB, repercutían directamente en esta
capa, y de rebote, en la capa Cliente. Se sugerían varias formas de mejorar el
desempeño, y de blindarse ante cambios, estas sugerencias son los llamados patrones
de diseño, que en síntesis son soluciones estándar a problemas comunes y repetitivos,
siendo su objetivo solucionar éstos de la mejor forma posible.
Se sugería que para mitigar los cambios en la lógica del negocio, se utilizara el patrón
Bussines Delegate, el cual establece una capa intermedia, la cual se encarga de crear
y gestionar los accesos a los objetos del contenedor EJB, ocultando a los Java Bean
los detalles de estos procesos.
Al utilizar este patrón, surgía el problema que cada vez que un Business Delegate
utilizaba un EJB, tenía que construir la estructura para buscar el EJB, y habilitar sus
interfaces, lo cual no es óptimo, ya que si reutilizaba el EJB otro Business Delegate,
tenía que volver a hacer todo el proceso nuevamente.
Para arreglar este problema, se utiliza el patrón de diseño ServiceLocator, el cual
proporciona servicios de caché de las interfaces de los EJB, lo cual mejora el
desempeño. Además, se reduce la complejidad del código al haber un solo punto de
control de creación de EJB, y son transparentes las complejas operaciones de
búsqueda de contexto y de interfaces de los EJB, y la reconstrucción de estos.
La figura 21 muestra la estructura de la capa Web.




                                                                                Página 39
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




                            Figura 21: Estructura de la capa Web


4.3 Capa Business
Hay distintas estrategias para manejar los datos de una Base de Datos por medio de
J2EE.


4.3.1 Estrategias de conexión a bases de datos por medio de J2EE
Dos son las estrategias más populares para conectarse a base de datos (utilizando
EJB);
a) A través de Session Bean, y
b) A través de Entity Bean
A continuación se muestran las ventajas y desventajas de estos enfoques.


4.3.1.1 Conexión a base de datos por medio de Session Bean
Esta estrategia utiliza el mismo método que otros lenguajes de programación (Ej.
PHP, ASP, etc); se crea una clase, a la cual se le entregan los parámetros de acceso a



Miguel Angel Azócar Vega                                                                 P ágina 40
                                                                  Departamento Electrónica




la base, y ella accede a la base ejecutando sentencias SQL estándar. En J2EE la clase
que se crea es un Session Bean, con el fin de obtener las ventajas que entrega el
Contenedor de EJB. El primer problema que aparece es que cada Session Bean que se
crea genera una nueva conexión a la base de datos, lo cual no es bueno. El problema
no es tan grave como en otros lenguajes de programación, ya que los Session Bean
que se utilizan (Stateless), pueden soportar múltiples clientes, con lo cual la
escalabilidad está asegurada.
La solución que hay para esto es crear una clase utilitaria adicional, la cual crea un
pooling de conexiones, a la cual acceden los Session Bean para conseguir una
conexión a la base de datos.
Estudiando más el estándar J2EE, lo sugerido para trabajar con base de datos es
utilizar otro tipo de EJB, los Entity Bean.


4.3.1.2 Conexión a base de datos por medio de Entity Bean
Estos EJB están optimizados para trabajar con las bases de datos, entregándoles el
contenedor funcionalidades para ello (El contenedor automáticamente crea un pooling
de conexiones, lo cual es transparente para el programador).
Hay dos tipos de Entity Bean, los BMP (Bean Managed Persistence), y los CMP
(Container Managed Persistence). Los primeros se utilizan cuando se quiere tener un
control más fino en el manejo de la persistencia de los datos, y el acceso a la base de
datos.
En este proyecto, el tipo de Entity Bean utilizado es el CMP (Container Managed
Persistence), ya que evita escribir mucho código, al manejar la persistencia de los
datos y el acceso a las bases de datos de forma automática.


4.3.1.2.1 EJB CMP
Estos EJB, representan una tabla de una base de datos, y como su nombre lo indica, la
persistencia de los datos es manejada por el Contenedor de EJB. La gracia de estos
EJB, es que proporcionan acceso distribuido, transaccional, y seguro a estos datos
persistentes.




                                                                                Página 41
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




         Figura 22: Tabla de una base de datos, y su correspondiente EJB CMP
Para realizar consultas a las base de datos, existe un lenguaje propio que utilizan los
EJB CMP, llamado EJB QL Query, muy parecido al SQL estándar.


4.3.1.2.2 EJB QL Query
Este lenguaje permite definir en forma simple y poderosa métodos de consultas de
búsqueda y selección en las tablas de la Base de Datos. Es completamente portable,
debido a que es traducido en forma automática por el contenedor EJB al lenguaje
específico de la base de datos que se esté utilizando.
A continuación, se muestran algunos ejemplos de las sentencias


4.3.1.2.2.1 Ejemplos de EJB QL Query
Ejemplo1:
SELECT OBJECT(p) FROM TbMoneda AS p


Ejemplo2:
SELECT OBJECT(p) FROM TbReglaseventoscontables AS p WHERE p.evento =
?1 AND p.rutadministradora = ?2


4.3.2 Comunicación con la capa Web



Miguel Angel Azócar Vega                                                                 P ágina 42
                                                                 Departamento Electrónica




Estudiando la bibliografía asociada al manejo de los CMP, se recomienda que la
comunicación entre ellos y la capa Web (los Business Delegate, en este caso), no sea
directa, ya que eventuales cambios en los CMP, repercutirían en forma directa en las
capas superiores. Lo sugerido es utilizar el patrón de diseño Session Facade, cuyo fin
es aislar el acceso a los CMP, para que cambios en ellos no repercutan en las capas
superiores. Otra ventaja que tiene su uso es la reducción de llamadas realizadas al
contenedor EJB. Estos Session Facade, no son más que EJB Session Stateless. [16]
Se sugiere además que se combine el patrón de diseño Session Facade con el patrón
Data Transfer Object, en forma similar a lo hecho en la capa de negocios entre el
patrón Business Delegate, y el Service Locator. [17]
Este patrón Data Transfer Object se utiliza para encapsular objetos y pasarlos desde
el Contenedor EJB al Contenedor Web. Otra ventaja que tiene, es que logra reducir el
tráfico remoto de la red.


4.3.2.1 Secuencia de la comunicación con la capa Web
Los pasos que se siguen en la comunicación con la capa Web, es la siguiente;
a) La capa Web necesita hacer un requerimiento a la base de datos, para ello crean
Beans de Session (a través de Business Delegate y Service Locator), los cuales son
los Session Facade.
b) Los Session Facade, buscan a los CMP, y si no existen, los crean.
c) Los Session Facade, les entregan la consulta a los CMP
d) Los CMP, entregan las respuestas a los Session Facade, en forma de colecciones
de CMP, o CMP individuales.
e) Los Session Facade convierten las respuestas de los CMP en objetos Bean, es
decir, objetos que solo tienen métodos set y get, además de poseer la características
de ser serializables, lo cual permite su transferencia entre los contenedores. Estos
objetos Bean son los llamados objetos DTO.
f) Los Session Facade, retornan los objetos DTO a la capa Web
La figura 23 muestra un resumen de la estructura de la capa Business




                                                                               Página 43
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




                          Figura 23: Estructura de la capa Business


4.4 Arquitectura J2EE de toda la Aplicación
En la figura 24 se muestra la estructura de la aplicación como estructura MVC
(Modelo-Vista-Control), mientras que en la figura 25 se ve la misma, pero más
detallada, visualizada por contenedores.




                       Figura 24: Arquitectura MVC de la aplicación




Miguel Angel Azócar Vega                                                                 P ágina 44
                                                                 Departamento Electrónica




                  Figura 25: Arquitectura J2EE de toda la aplicación


4.5 Casos de estudio
Muchas funcionalidades que requería la aplicación, llevadas al desarrollo, tenían
características similares (definición monedas, definición tipos de cambio, etc.),
debido a lo cual, se decidió mostrar dos funcionalidades muy repetitivas; la edición
de datos, y el ingreso de nuevos datos.


4.5.1 Edición de monedas
El objetivo era modificar datos asociados a las monedas que existían en la base de
datos, de forma clara y transparente para el usuario.


4.5.1.1 Capa Cliente
Lograr editar los datos que venían en definitiva de la base de datos, fue relativamente
fácil, gracias a las funcionalidades provistas por JSF.


4.5.1.1.1 Visualización de las monedas
JSF tiene funcionalidades para mostrar los datos de una base de datos, en forma
bastante simple. La figura 26 muestra un ejemplo de esto;




                                                                               Página 45
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




           Figura 26: Ejemplo de visualización de datos de una base de datos
Como se aprecia del código, sólo se pone el nombre de la tabla, y los nombres de las
columnas que se quiere mostrar. Los encabezados de las columnas son opcionales.
En la figura 27, se muestra como se aplicó estas funcionalidades, para mostrar las
monedas de la base de datos.




        Figura 27: Utilización de JSF para mostrar las monedas de la aplicación

4.5.1.1.2 Edición de las monedas
Para poder editar los datos, se requiere utilizar flag que indiquen que “registro” fue
modificado. Además, como un aspecto estético, se requiere que cuando se seleccione
el flag que indica “modificar”, en ese momento se muestre el registro como
modificable.
Para ello, se modifica el código, y se agregan los flag, quedando el código como se
muestra en la figura 28




Miguel Angel Azócar Vega                                                                 P ágina 46
                                                               Departamento Electrónica




            Figura 28: Edición de monedas utilizando componentes JSF

4.5.1.2 Capa Web
Un problema que tiene directa relación con la parte Web, es el hecho que al poner los
flag para modificar las monedas, dentro del ámbito del dataTable, el servidor de
aplicaciones reclamaba, ya que no encontraba estos como atributos del DataModel, el
cual es el objeto que tiene la información de la tabla de la base de datos; sus
columnas, y valores.
Este objeto DataModel no es más que el objeto DTO obtenido al llamar el método
“getAllMonedas” del Business Delegate, el cual retorna todas las monedas existentes
en la base de datos.
Lo primero que se hizo, fue cambiar directamente el código de los DTO y agregarle
los flag como atributos, pero esta solución, acarreaba más problemas con los objetos
creados a partir de los otros patrones de diseño; los Session Facade, y los Business
Delegate.
La solución implementada fue crear un DTO intermedio, con los mismos atributos
que el original, pero además con los flag como atributos. Además se creo una clase
utilitaria, que era la encargada de manejar las conversiones del DTO original al DTO
modificado, para que la clase principal se mantuviese sin cambios. El código del
DTO original y del modificado, se muestran en las figuras 29 y 30. El diagrama de
esta solución, se muestra en la figura 31.




                                                                             Página 47
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




                             Figura 29: Código del DTO original




                           Figura 30: Código del DTO intermedio



Miguel Angel Azócar Vega                                                                 P ágina 48
                                                              Departamento Electrónica




                   Figura 31: Arquitectura modificada capa Web

4.5.1.3 Capa Business
Se debió implementar el método FindAllMonedas, en el CMP, para poder devolver a
la capa Web, una colección de DTO´s, los cuales incluían todas las monedas existente
en la base de datos. Este método se implementó utilizando la tecnología EJB QL
Query. La figura 32, muestra la implementación del método;




                        Figura 32: Método findAllMonedas




                                                                            Página 49
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



4.5.2 Ingreso de nuevas monedas
El objetivo era el ingreso de nuevas monedas a la base de datos, de forma fácil e
intuitiva para el usuario.


4.5.2.1 Capa Cliente
El ingreso de una nueva moneda, requería sólo ingresar el nombre de ella. JSF utiliza
el componente <h:inputText> para ingresar texto, el cual es simple de programar, tal
como se muestra en la figura 33.



                       Figura 33: Código componente JSF inputText

4.5.2.1.1 Selección de alternativas
Pese a que esta funcionalidad no era requerida para ingresar una nueva moneda, si se
repetía en muchos otros procesos de ingreso datos, por ejemplo, definición de
sucursales, ingreso de nuevos tipos de cambio, etc. por lo que se optó por mostrar
como se implementaba.
JSF provee los siguientes componentes para la selección de alternativas;
<h:selectBooleanCheckbox>, <h:selectManyCheckbox>, <h: selectOneRadio>,
<h:selectOneListbox>, <h:selectManyListbox>, <h:selectOneMenu>,
<h:selectManyMenu>
El componente más utilizado en la aplicación fue <h:selectOneMenu>, ya que era el
más acorde a los requerimientos de la aplicación. En la figura 34 y 35, se muestra
como se programa este componente, y como lo visualizaba el usuario
respectivamente;




                   Figura 34: Código componente JSF selectOneMenu




              Figura 35: Visualización del componente JSF selectOneMenu




Miguel Angel Azócar Vega                                                                 P ágina 50
                                                                  Departamento Electrónica




4.5.2.1.2 Navegación Web
Una vez que se agregan datos, hay dos alternativas, mantenerse en la página Web
actual, o emigrar a otra. Utilizando JSF, esto se configura de manera fácil, a través del
archivo de configuración faces-config.xml. En este archivo, dependiendo de la
respuesta de la capa Web, es hacia que página se redirige al usuario. En la figura 36,
se muestra el código que maneja el ingreso de nuevas monedas, y en la figura 37 se
muestra lo mismo en forma gráfica.




                   Figura 36: Extracto del archivo faces-config.xml




               Figura 37: Configuración gráfica de la Navegación Web


4.5.2.2 Capa Web
Como se mostró en la figura 34, la implementación del componente
<h:selectOneMenu>, requiere la utilización del componente <h:selectItem>. Este
componente tiene varios constructores [13], de los cuales se utilizó el constructor
SelectItem( java.lang.Object value, java.lang.String label ), por ser el que cumplía
con las necesidades de la aplicación.



                                                                                Página 51
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



Como los datos obtenidos del BusinessDelegate vienen como objetos DTO, es
necesario seleccionar los campos que se utilizarán al construir el SelectItem. Por lo
general, el campo valor, fue el identificador del registro, y la etiqueta, la descripción
de ese registro. En la figura 38 se muestra el código para seleccionar los campos del
DTO, y construir el SelectItem;




                  Figura 38: Código para transformar DTO a SelectItem

4.5.2.3 Capa Business
Al ingresar una nueva moneda, el usuario ingresaba solo el nombre de ella, pero en la
base de datos, a esta moneda se le asociaba un identificador, el cual era el
identificador del registro. Este identificador debía ser único, y por definición,
consecutivo. Para ello se manejaron dos alternativas; que la base de datos les diera el
valor, o que este fuese manejado por la aplicación.


4.5.2.3.1 Valores consecutivos a través de la Base de Datos
La forma más fácil de manejar datos consecutivos, es por medio del tipo de datos
SERIAL, los cuales aumentan su valor en forma automática.
El problema con esta alternativa, es que cuando se cae la base de datos, sea por corte
de luz, desbordamiento de memoria, etc., al recuperarse la base, el correlativo de
estos números aumenta mucho, por ejemplo, si el último número antes de la caída era
100, después queda en 100.000. Esto se observó en una base de datos Sybase, por lo
que esta alternativa fue descartada.




Miguel Angel Azócar Vega                                                                 P ágina 52
                                                                   Departamento Electrónica




4.5.2.3.2 Valores consecutivos a través de la aplicación
Esta fue la alternativa utilizada, dado el control que se tenía de los datos.
A grosso modo, se le preguntaba a la base de datos, cual era el mayor número de
identificador que tenía en ese momento, se aumentaba en uno, y se le ponía a la
moneda ingresada como su identificador. La implementación de esto, se detalla a
continuación;
a) Al CMP se le implementaba un método Select, el cual obtenía el valor del mayor
número de identificador de la tabla. Este método solo era visible dentro del propio
CMP, por limitantes de diseño. En la figura 39 se muestra el detalle de este método.
b) Para que el valor del identificador fuera utilizado por la capa Web, se debió
adicionar un nuevo método al CMP, el cual era visible fuera de este. Lo único que
hacia este método, era llamar al método Select. En al figura 40 se muestra la
implementación de este método.




                     Figura 39: Detalle del método Select del CMP




                   Figura 40: Implementación del método GetMaxId




                                                                                 Página 53
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




CAPITULO 5: Pruebas y Análisis de Resultados

5.1 Pruebas de la aplicación
Las pruebas a las que fue sometida la aplicación estaban enfocadas en validar que los
objetivos del proyecto fuesen cumplidos satisfactoriamente.


5.1.1 Implementación sistema contable Web
Todos los aspectos relacionados con el diseño de la aplicación fueron abordados en el
capítulo 2, por lo que no se dará mayor énfasis en ese punto. Lo que se mostrará a
continuación, es el resultado aplicado de algunos requerimientos surgidos del diseño
de la aplicación.


5.1.1.1 Validación de Usuario
La figura 41 muestra la parte de validación que ve el usuario al ingresar al sistema. La
figura 42 muestra como el usuario elige su perfil, y por último la figura 43, muestra el
resultado de una validación exitosa.




                              Figura 41: Validación de usuarios




                          Figura 42: Elección del perfil del usuario




Miguel Angel Azócar Vega                                                                 P ágina 54
                                                                  Departamento Electrónica




                      Figura 43: Validación exitosa del usuario

5.1.1.2 Eliminación de Moneda
La figura 44, muestra parte de la página mantenedora de las monedas de la
aplicación. La figura 45 muestra el resultado de seleccionar una moneda para su
eliminación, y por último la figura 46, muestra el resultado al apretar el botón guardar
cambios.




                  Figura 44: Parte página mantenedora de monedas




               Figura 45: Selección de una moneda para su eliminación




                            Figura 46: Moneda eliminada



                                                                                Página 55
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



5.1.2 Cálculo del valor cuota de los Fondos
Esta funcionalidad era el objetivo final de la aplicación. La lógica que implementa el
cálculo del patrimonio del fondo, es simple, ya que se consolidan los asientos
contables de las cuentas, y su resultado es los que se muestra al usuario.
La figura 47 muestra parte de la página Calculo del Valor Cuota, la figura 48 muestra
la elección de fechas para calcular el valor cuota, y la figura 49 muestra el resultado
del cálculo.




                Figura 47: Parte de página Calculo de Valor Cuota Figura




   Figura 48: Elección de fecha de inicio Figura 49: Resultado cálculo valor cuota




Miguel Angel Azócar Vega                                                                 P ágina 56
                                                                  Departamento Electrónica




                       Figura 49: Resultado cálculo valor cuota

5.2 Análisis de Resultados
Para un claro análisis de los resultados, se optó por separar éstos en requerimientos de
alto nivel y en requerimientos de bajo nivel, siendo los primeros lo que el usuario ve
y requirió de la aplicación y los segundos las condiciones que debe cumplir una
aplicación empresarial del tipo que se requería en ésta aplicación.

5.2.1 Requerimientos de alto nivel
Gracias a la utilización de J2EE, los requerimientos computacionales, de alto nivel de
la aplicación, se cumplieron en forma adecuada. Estos eran, que el sistema fuese
operable a través de la Web, y que implementase la lógica de la aplicación.


5.2.2 Requerimientos de bajo nivel
Los requerimientos de bajo nivel que la aplicación debía cumplir era tener un nivel de
seguridad acorde al tipo de transacciones que se manejaba, que el mantenimiento y
mejoras a nivel de desarrollo fuesen fáciles y rápidas de implementar y que tuviese
asegurado un desempeño eficiente ante alta carga.


5.2.2.1 Seguridad
La utilización adecuada de J2EE que se implantó en el desarrollo de la aplicación,
unido a la implementación de procesos de seguridad en ciertas clases, aseguraban
niveles de seguridad acordes a los tipos de transacciones que eran realizadas, por lo
que la seguridad tanto de usuarios como de procesos, estaba garantizada.


5.2.2.2 Mantenimiento de la Aplicación




                                                                                Página 57
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



Gracias a la utilización de un lenguaje orientado a objetos, como es Java, unido al
enfoque de capas y componentes que utiliza J2EE, asegura que mejoras, y/o
posteriores modificaciones a la lógica de la aplicación o a su visualización, por parte
del usuario, sea poco traumática, ya que se sabe que componente o clase es
responsable de que proceso, y hay independencia en el funcionamiento de las capas
que componen la aplicación.


5.2.2.3 Desempeño ante alta carga
Este requerimiento no se pudo comprobar, ya que el número máximo de solicitudes
Web a las cuales estuvo sometido el sistema, como forma de testeo, fue de ocho,
valor muy inferior al que se enfrentará una vez que se integre con los otros módulos.
Pese a esto, se puede deducir, que el sistema no presentará problemas, ya que el
estándar J2EE, está orientado a ser escalable, motivo por el cual fue seleccionado
como plataforma tecnológica.




Miguel Angel Azócar Vega                                                                 P ágina 58
                                                                Departamento Electrónica




CAPITULO 6: Conclusiones, Trabajo futuro

6.1 Conclusiones
Las conclusiones del proyecto realizado se dividieron en cuatro partes, siendo éstas
los sistemas computacionales empresariales, la ingeniería de Software, J2EE y el
módulo contable.


6.1.1 Sistemas computacionales empresariales
La creación de sistemas computacionales de gran envergadura es un proceso muy
complejo, en el cual, es imprescindible contar con herramientas de control y
planificación de las distintas actividades, para terminar el proyecto dentro de los
plazos establecidos, o tomar medidas correctivas con anticipación. Debido a la
naturaleza de estos sistemas, la interacción con profesionales de otras áreas es
necesaria, resultando de ello una sinergia de ideas y enfoques, lo cual redunda en un
crecimiento profesional.


6.1.2 Ingeniería de Software
La utilización de principios y conceptos de Ingeniería de Software ayudan a lograr
que los proyectos terminen a tiempo, aunque, no lo aseguran. La utilización de la
metodología RUP fue de gran ayuda para el control de las actividades, ya que su
enfoque iterativo e incremental, servía como retroalimentación a las fases
subsiguientes del desarrollo de la aplicación.


6.1.3 J2EE
La utilización de la tecnología J2EE como plataforma de desarrollo fue bastante
exitosa, ya que ella permite una rápida velocidad de desarrollo de la aplicación,
gracias a su enfoque de componentes, de los cuales, el programador sólo debe
preocuparse de los procesos específicos que quiere que hagan, y no como ellos lo
hacen, gracias a los servicios que los contenedores entregan a estos componentes. En
los Servlet, por ejemplo, el desarrollador implementa la lógica que quiere que este
haga, pero él no debe programar el manejo de los atributos de la sesión, ni
implementar la comunicación con los JSP, etc., ya que estos servicios los implementa
el contenedor.
La utilización de una IDE empresarial es indispensable para trabajar con J2EE, ya
que el manejo de los archivos de configuración de los componentes, de
configuración de los contenedores, de la seguridad, etc. es bastante complejo, y hacer




                                                                              Página 59
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.



esto en forma manual, repercutiría fuertemente en la velocidad de desarrollo y
mantenimiento de la aplicación.


6.1.4 Módulo contable
El producto final del proyecto resultó en un módulo contable operativo, el cual
cumple los objetivos por lo que fue concebido; un sistema paramétrico contable,
operable a través de la Web. Sin embargo, para lograr ver sus funcionalidades al
100%, hay que esperar que los demás módulos que componen la aplicación final
estén operativos, para enlazarlos entre ellos.


6.2 Trabajo Futuro
Durante la etapa de requerimientos, varios de estos fueron dejados de lado, debido a
que su inclusión hacía el proyecto inviable, debido al tiempo necesario que se debía
gastar en implementarlos. Una vez que la aplicación esté en funcionamiento, estos
requerimientos podrían ser incorporados en forma secuencial. A continuación se da
una lista con los más importantes:


6.2.1 Definición de Documentos
El sistema debiese permitir la definición de documentos contables.


6.2.2 Definición de Plantilla de Documentos
Un documento tendrá definida una plantilla, que definirá los campos que deben ser
ingresados, y que simplificará el cálculo de los restantes valores que conforman el
libro. La plantilla del documento permite la generación automática del asiento
contable correspondiente.


6.2.3 Generación de Libros
El sistema debe generar los libros de compra/ventas y de retenciones, a partir de los
documentos ingresados en el ejercicio respectivo, y que correspondan al libro a
generar.


6.2.4 Asociación de FECU




Miguel Angel Azócar Vega                                                                 P ágina 60
                                                                Departamento Electrónica




El sistema debe permitir generar la F.E.C.U. La F.E.C.U. es la codificación del Plan
de Cuentas de la SVS. Para esto, a cada cuenta contable definida en el Plan de
Cuentas se le asociará una o más Cuentas F.E.C.U. de la SVS, junto con una regla
que definirá la operación que deberá realizarse para la asignación del valor.




                                                                              Página 61
Desarrollo de Proyecto J2EE para la automatización de los procesos contables de una Administradora
General de Fondos.




CAPITULO7: REFERENCIAS
[1] Mehdi Achour et al, http://www.php.net/manual/es/introduction.php
[2] James Gosling, http://www.phpdeveloper.org/news/4970
[3] Chad Vawter and Ed Roman “J2EE vs. Microsoft .NET”,
http://wwws.sun.com/software/whitepapers/webservices/J2EE-vs-DotNET.pdf
[4] David Geary, http://www.javaworld.com/javaworld/jw-11-2002/jw-1129-jsf.html
[5] Peter Purich,
http://www.oracle.com/technology/products/ias/toplink/doc/1013/MAIN/_html/undtl
dev013.htm
[6] Dale Green, http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBQL.html
[7] Deepak Alur, John Crupi and Dan Malks,
http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html
[8] Deepak Alur, John Crupi and Dan Malks,
http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
[9] Deepak Alur, John Crupi and Dan Malks,
http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.html
[10] Deepak Alur, John Crupi and Dan Malks,
http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html
[11] Jennifer Ball,
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSPIntro8.html#wp70748
[12] http://websphere.sys-
con.com/read/46516.htm?CFID=61124&CFTOKEN=FD559D82-11F9-B3B2-
738E901F37DDB4DE
[13]
http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/javax/faces/model/SelectItem.
html
[14]
http://www.ieb.cl/pdf/boletines_bibliograficos/mercado_de_capitales/mercado_de_ca
pitales.pdf
[15]
http://alumnos.elo.utfsm.cl/~azcar/ramos/2_semestre_2004/Seminario_redes_Comput
adores/primeras/Informe1.doc
[16] http://java.sun.com/blueprints/corej2eepatterns/Patterns/SessionFacade.html
[17] http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html




Miguel Angel Azócar Vega                                                                 P ágina 62

								
To top