Download gestordeprevencion_v1.0.0_manual_tecnico

MANUAL TÉCNICO
GESTOR DE PREVENCIÓN ADC
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
ÍNDICE
1.
INTRODUCCIÓN ............................................................................ 4
2.
CARATERÍSTICAS GENERALES ...................................................... 5
2.1. CARACTERÍSTICAS ARQUITECTÓNICAS GENERALES ............................ 5
2.2. CARACTERÍSTICAS TÉCNICAS GENERALES ......................................... 5
2.3. IMPLANTACIÓN ............................................................................... 5
3.
DESCRIPCIÓN POR CAPA ARQUITECTÓNICA ................................. 6
3.1. CAPA PRESENTACIÓN. ...................................................................... 6
3.2. CAPA LÓGICA DE NEGOCIO. .............................................................. 6
3.3. CAPA DE DATOS / PERSISTENCIA. ..................................................... 6
4.
ESTRUCTURA DE APLICACIÓN....................................................... 8
4.1. DIRECTORIO DEL PROYECTO............................................................. 8
4.2. DIRECTORIO SRC ............................................................................ 8
4.3. DIRECTORIO PUBLIC_HTML .............................................................. 9
4.4. WEB-INF Y LIBRERIAS ..................................................................... 10
4.4.1 CONTENIDO WEB-INF ..................................................................................... 10
4.4.2 DIRECTORIO LIB ............................................................................................ 10
5.
CONFIGURACION ........................................................................ 11
5.1. FICHERO WEB.XML ......................................................................... 11
5.2. FILTER-SESSION-DO.XML Y FILTER-SESSION-JSP.XML (CONTROL NO
INTRUSIVO DE ACCESO) ......................................................................... 13
5.2.1 DESCRIPCIÓN FICHERO FILTER-SESSION-DO.XML ............................................. 13
5.2.2 DESCRIPCIÓN FICHERO FILTER-SESSION-JSP.XML ............................................. 13
6.
ANEXO I: VOS Y MÉTODOS ESTÁNDAR DAOS ............................. 14
6.1. VO ................................................................................................ 14
6.2. CREATE ......................................................................................... 14
6.3. EXISTS .......................................................................................... 14
6.4. FIND ............................................................................................. 14
6.5. LIST .............................................................................................. 14
6.6. UPDATE ......................................................................................... 14
6.7. REMOVE ........................................................................................ 14
6.8. COUNT .......................................................................................... 14
Página 2 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
7.
ANEXO II: ACTIONS, DAOS Y MANAGERS .................................... 15
8.
ANEXO V: HQL ............................................................................. 16
Página 3 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
1.
INTRODUCCIÓN
En el presente documento se detalla la arquitectura definida para la aplicación
‘Gestor de Prevención’.
En los siguientes apartados se irá detallando la misma en cada uno de sus niveles.
Lo más destacable es que incorpora el motor de persistencia Hibernate 3 y el uso
del contenedor de Inversión de Control Spring para la unión de las capas de la
aplicación.
Página 4 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
2.
CARATERÍSTICAS GENERALES
2.1. CARACTERÍSTICAS ARQUITECTÓNICAS GENERALES





Uso de tecnología Orientada a Objetos.
Uso de arquitectura en 3 capas (Presentación, Lógica de Negocio y Datos o
Persistencia).
Contenedor de IoC Spring
Uso de patrones de diseño:
o Modelo – Vista – Controlador (MVC).
o Session Facade (SF).
o Inyección de Dependencias
o Data Access Object (DAO).
o Value Object (VO).
Control de autentificación y autorización no intrusiva.
2.2. CARACTERÍSTICAS TÉCNICAS GENERALES
El entorno tecnológico bajo el cual ha sido desarrollada la aplicación es el siguiente:
SERVIDOR:







Plataforma J2EE: Sun Microsystems J2EE 1.4.2
Framework MVC: Jakarta – Struts 1.2.4
Framework de persistencia: Hibernate 3
Contenedor Spring para la unión de capas.
Utilidades de Log: Jakarta – log4j 1.2.9
Base de Datos: MySQL 5.0.37
Servidor Aplicaciones: Tomcat 5.0 – Oracle iAS (OC4J 9.0.4)
CLIENTE:


Navegador Web: Internet Explorer 6.0, Firefox 1.5
Visualizador de archivos pdfs: Acrobat reader 6.0
2.3. IMPLANTACIÓN
La aplicación ‘Gestor de Prevención’ de ADC es una aplicación en forma de portal
Web que se albergará en un servidor Apache Tomcat. Para el despliegue de la
misma, sólo se necesita poner el .war en el directorio webapps del Tomcat.
Página 5 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
3.
DESCRIPCIÓN POR CAPA ARQUITECTÓNICA
El modelo de arquitectura desarrollado está basado, como ejes principales, en el
uso de los frameworks Struts, Spring e Hibernate.
3.1. CAPA PRESENTACIÓN.

Realizado en JSPs.

Elementos:
o HTML, CSS, XML y Javacript.

Los Action y DispatchAction de Struts son el mecanismo para acceder a la
lógica de negocio.

La información viaja desde la lógica de negocio a la capa de presentación
mediante los correspondiente beans definidos.
3.2. CAPA LÓGICA DE NEGOCIO.
Existe una interfaz de lógica de negocio y una implementación de la misma por
cada módulo del sistema.
Esta interfaz define todos los métodos de la lógica de negocio, los cuales son
usados por los Action y DispatchAction de Struts.
3.3. CAPA DE DATOS / PERSISTENCIA.

Por cada tabla de entidad del modelo de datos existe:



Un Interfaz que indica las operaciones que debe cumplir cada DAO.
Un DAO que implementa la interfaz.
Un VO por tabla.
Página 6 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
UNIÓN DE CAPAS
La unión entre las tres capas se realiza a través de Inyección de Dependencias con
el contenedor de Inversión de Control springframework.
Página 7 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
4.
ESTRUCTURA DE APLICACIÓN
Todos los elementos que compongan parte de una aplicación tienen un lugar
predefinido y una nomenclatura. En este apartado describiremos esta estructura,
así como la ubicación de cada uno de los elementos y algunas características de los
mismos.
4.1. DIRECTORIO DEL PROYECTO
En el proyecto existen dos directorios:


El directorio “src” que contendrá todos los fuentes “java”.
El directorio “public_html” que contendrá todos los contenidos “web”.
4.2. DIRECTORIO SRC
La estructura de clases (directorios) de los fuentes java de la aplicación, se detallan
a continuación:
o
o
o
o
o
o

El paquete configuration contiene:
o
o
o
o
o

applicationConfig.properties
ConfigurationParametersManager.java
ContextLoaderListener.java
log4j.properties
Log4jSetup.java
El paquete session contiene:
o
o

configuration
session
businesslogic
struts
model
util
HttpSessionFilter.java
HttpSessionManager.java
El paquete businesslogic:
Contiene la lógica de negocio.

El paquete struts:
o
controller:
Contiene los Action y DispatchAction de Struts.
o
view:
Página 8 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
Existe un paquete beans para contener todos los struts –
ActionForms. Los nombres de los beans son de la forma
<nombre_bean>ActionForm.
Existe un paquete resources para contener el fichero properties. El
nombre del fichero es ApplicationResoruces.properties.

El paquete model:
Existen dos paquetes dentro del paquete model, el paquete vo y el paquete
dao.
o
Paquete vo:
Contiene las clases que representan la estructura en base de datos
de las tablas o consultas.
El nombre de cada clase es <nombre_tabla/consulta>VO.
o
Paquete dao
Por cada VO existe un clase factoria de DAOs: un interfaz y su
implementación.

El nombre de los interfaces:
<nombre_tabla>DAO

El nombre de la implementaciones de DAOs:
Hibernate<nombre_tabla/consulta>DAO
4.3. DIRECTORIO PUBLIC_HTML
La estructura de directorios contenido “web” de la aplicación se detalla a
continuación:

css:
Contiene todos los ficheros de estilos (.css) que usa la aplicación.

js:
Contiene todos los ficheros javascript (.js) que usa la aplicación.

images:
Contiene todos los ficheros gráficos que usa la aplicación.

comun:
Página 9 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
Contiene todo el contenido JSP, HTML, XML común para todos los módulos
de la aplicación.

Existe un directorio que contenga el contenido específico de cada módulo de
la aplicación (JSP, HTML, XML), quedando en la raíz las páginas genéricas
(index.jsp, login.jsp, logout.jsp, etc.).
4.4. WEB-INF Y LIBRERIAS
Dentro del directorio public_html se encuentra el directorio WEB-INF que contiene
datos referentes a la configuración de la aplicación. En este apartado vamos a
describir que contenido debe tener para el correcto funcionamiento de la aplicación.
4.4.1 CONTENIDO WEB-INF
Dentro de web-inf está el directorio “lib”, del que posteriormente hablaremos, y
todos los .tld y .xml de struts.
También están en este directorio los siguiente ficheros .xml: web.xml, strutsconfig.xml, applicationContext.xml, action-servlet.xml, filter-session-do.xml, filtersession-jsp.xml.
4.4.2
DIRECTORIO LIB
El directorio “lib” dentro de “web-inf” contiene todas las librerías necesarias para el
correcto funcionamiento de la aplicación.
Están todos los .jar de struts y el log4j.jar.
Además para la generación de PDFs, se ha utilizado la librería FOP 0.92.
Página 10 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
5.
CONFIGURACION
En este apartado se indica
correctamente la aplicación.
aspectos
a
tener
en
cuenta
para
configurar
5.1. FICHERO WEB.XML
Además de las configuraciones necesarias para trabajar con struts (para más
detalles consultar la documentación el jakarta-struts : http://struts.apache.org/ ),
es necesario incluir los siguientes bloques:

Fichero applicationConfig.properties (Apartado 4.2 paquete configuration).
<context-param>
<param-name>config-type</param-name>
<param-value>FILE</param-value>
</context-param>
<context-param>
<param-name>config-source</param-name>
<param-value>
eroski.scin.application.configuration.applicationConfig
</param-value>
</context-param>
Con este fragmento xml indicamos donde se encuentra el fichero de
configuración de la aplicación, donde se indican los DAOs que utiliza la
aplicación y otras propiedades que sean necesarias utilizar.
Cabe reseñar que el fichero de propiedades de la aplicación se lee en la
aplicación mediante la clase ConfigurationParametersManager.java y sus
métodos.

Configuración de Listener para carga de propiedades (Apartado 4.2 paquete
configuration).
<listener>
<listener-class>
com.adc.configuration.ContextLoaderListener
</listener-class>
</listener>
La clase ContextLoaderListerner.java es la encargada de carga del fichero
properties definido en el apartado anterior.

Configuración de filtros .jsp y actions ( Apartado 4.2. paquete session).
<filter>
<filter-name>sesion-do</filter-name>
<filter-class>com.adc.session.HttpSessionFilter</filterclass>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/filter-session-do.xml</param-value>
</init-param>
Página 11 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
</filter>
<filter>
<filter-name>sesion-jsp</filter-name>
<filter-class>com.adc.session.HttpSessionFilter</filterclass>
<init-param>
<param-name>config</param-name>
<param-value>/WEB-INF/filter-session-jsp.xml</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>sesion-do</filter-name>
<url-pattern>*.do</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>sesion-jsp</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>
La clase HttpSessionFilter.java conjuntamente con los ficheros
filtersession-do.xml, filter-session-jsp.xml se encargar de filtrar los actions y las
jsps. (Apartado 4.5.1). En apartados posteriores se detallará el
funcionamiento. Esta clase “java” y los fichero .xml citados anteriormente
permiten realizar el control de acceso no intrusivo.

Registro del servlet de configuración de log4j
<servlet>
<servlet-name>log4j-init</servlet-name>
<servlet-class>com.adc.configuration.Log4jSetup</servletclass>
<init-param>
<param-name>log-directory</param-name>
<param-value>/usr/local/tomcat/logs</param-value>
</init-param>
<init-param>
<param-name>log4j-init-file</param-name>
<param-value>eroski.scin.application.configuration.log4j
</param-value>
</init-param>
<init-param>
<param-name>watch</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>time-watch</param-name>
<param-value>10000</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
Log4jSetup.java es el servlet que realiza la configuración de log4j (para más
información sobre log4j: http://logging.apache.org/). Las propiedades del
Página 12 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
log4j están en
configuration).
el
fichero
log4j.properties.
(Apartado
4.2
paquete
5.2. FILTER-SESSION-DO.XML Y FILTER-SESSION-JSP.XML (CONTROL NO
INTRUSIVO DE ACCESO)
Mediante la clase HttpSessionFilter (apartado 4.2) y los fichero filter-session-do.xml
y filter-session-jsp.xml se puede controlar que Struts Actions y que JSPs se pueden
ejecutar sin estar o estando logeado en el sistema.
El fichero filter-session-do.xml controla el acceso a los Struts Actions, y el fichero
filter-session-jsp.xml controla el acceso a las JSPs.
5.2.1 DESCRIPCIÓN FICHERO FILTER-SESSION-DO.XML
<?xml version = '1.0' encoding = 'ISO-8859-1'?>
<filter-session>
<!-- accept para aceptar, cualquier otra cosa rechazar-->
<filter-behavior behavior="accept" />
<error-page>/stdJ2EE/comun/error_sesion.jsp</error-page>
<filter-uri>
<uri>/stdJ2EE/login.do</uri>
<uri>/stdJ2EE/logout.do</uri>
</filter-uri>
</filter-session>



filter-behavior: Indica si el filtro acepta sin validar el Struts Action, value
“accept” o “no-accept” el caso contrario.
error-page: Indica la página que se debe devolver en caso de que el Strut
Action sea rechazado.
uri-filter: Indica la direcciones de los elementos que deben / no deben ser
filtrados.
5.2.2 DESCRIPCIÓN FICHERO FILTER-SESSION-JSP.XML
<?xml version = '1.0' encoding = 'ISO-8859-1'?>
<filter-session>
<!-- accept para aceptar, cualquier otra cosa rechazar-->
<filter-behavior behavior="accept" />
<error-page>/stdJ2EE/comun/error_sesion.jsp</error-page>
<filter-uri>
<uri>/stdJ2EE/index.jsp</uri>
<uri>/stdJ2EE/comun/salida.jsp</uri>
</filter-uri>
</filter-session>



filter-behavior: Indica si el filtro acepta sin validar las JSPs, value “accept” o
“no-accept” el caso contrario.
error-page: Indica la página que se debe devolver en caso de que la JSP
sea rechazada.
uri-filter: Indica las direcciones de los elementos que deben/no deben ser
filtrados.
Página 13 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
6.
ANEXO I: VOS Y MÉTODOS ESTÁNDAR DAOS
En el siguiente apartado se detalla como construir un VO para una tabla o vista y se
detallan los métodos estándar que tiene el DAO de acceso para ese VO.
6.1. VO
El VO implementa el Interfaz Serializable. Tiene un atributo privado por cada campo
de base de datos e implementa el respectivo método set y get para cada uno de
estos atributos.
6.2. CREATE
El método TabVO:create(TabVO vo) crea un registro en la base de datos.
Este método implementa la SQL INSERT del SGBD.
6.3. EXISTS
El método boolean:existsByPk(TipoClaveBusqueda ClaveBusqueda) indica si el
registro existe o no buscando por la clave de búsqueda.
6.4. FIND
El método TabVO:findByPk(TipoClaveBusqueda ClaveBusqueda)
registro localizado unívocamente por la clave de búsqueda.
devuelve
un
6.5. LIST
El método List:list(TabVO Vo, int startIndex, int count) devuelve una List de
TabVOs indicando desde que posición a que posición se recuperan los datos.
6.6. UPDATE
El método void:updateByPk(TabVO vo) actualiza el registro de base de datos que
contiene los datos del vo en cuestión. Se realizará la discriminación del registro por
clave primaria.
Este método implementa la SQL UPDATE del SGBD.
6.7. REMOVE
El método void:removeByPk(TipoClaveBusqueda ClaveBusqueda) realiza el borrado
del registro que tiene como clave primaria la ClaveBusqueda.
Este método implementa la SQL UPDATE del SGBD.
6.8. COUNT
El método Long:count(TabVO vo) devuelve el número de ocurrencias de tuplas que
hay en la tabla que guarda la información sobre el vo.
Página 14 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
7.
ANEXO II: ACTIONS, DAOS Y MANAGERS
Para añadir una action de struts, o un dao, o un manager a la arquitectura de
Spring, hay que tocar tres ficheros en total.
1.- struts-config.xml
Se pone la clase de Spring que lo implementa. El nombre, es el del bean
asociado.
<action name="frmTipoUnidad" path="/addEditMaestroTipoUnidades"
type="org.springframework.web.struts.DelegatingActionProxy"
scope="request" parameter="method" unknown="false">
<forward name="exito_get" path="/tipoUnidades/addEditMaestroTipoUnidades.jsp"
redirect="false" />
<forward name="exito_edit"
path="/goAdministracion.do?method=init&amp;opcion=maestrounidades"
redirect="true" />
<forward name="exito_delete"
path="/goAdministracion.do?method=init&amp;opcion=maestrounidades"
redirect="true" />
<forward name="error_interno" path="/comun/error_interno.jsp"/>
</action>
2.- action-servlet.xml
En este xml se asocia la clase de Spring puesta en el anterior con la clase que
implementa la Action. La asociación se hace a través del acceso puesto para la
Action.
A cada Action, se le asocia uno o varios “managers” (lógica de negocio) que utilizar.
Por cada manager, debe existir una declaración de la interfaz y un setter en la
Action. A este setter es al que llama Spring cuando se arranca la aplicación.
<bean name="/addEditMaestroTipoUnidades"
class="com.adc.struts.controller.AddEditMaestroTipoUnidadesAction"
singleton="true">
<property name="tipoUnidadManager">
<ref bean="tipoUnidadManager" />
</property>
<property name="usuarioManager">
<ref bean="usuarioManager" />
</property>
</bean>
3.- applicationContext.xml
En este xml se declaran los managers, daos, datasources, etc que se utilizan en el
anterior.
Página 15 de 16
PROYECTO: GESTOR DE PREVENCIÓN
MANUAL TÉCNICO
Cada manager puede declararse “normalmente”, de modo que se le asocian los
daos que puede utilizar.
<bean id="tipoUnidadManager"
class="com.adc.businesslogic.impl.TipoUnidadManagerImpl">
<property name="tipoUnidadDAO">
<ref local="tipoUnidadDAO" />
</property>
<property name="usuarioDAO">
<ref local="usuarioDAO" />
</property>
</bean>
En caso de utilizar varios daos en el mismo método del manager, puede ser
interesante mantener la transaccionalidad, es decir, que todas las llamada a la
bbdd desde los diferentes daos se haga sobre la misma transacción (y así hacer
rollback en caso de falle algo, etc…).
Para ello, hay que definir los managers como “proxys”, de manera que se asocia el
proxy a un “target”, que es la clase que finalmente implementa el manager.
<bean id="usuarioManager"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
>
<property name="transactionManager"><ref
bean="transactionManager"/></property>
<property name="target"><ref
bean="usuarioManagerTarget"/></property>
<property name="transactionAttributes">
<props>
<prop key="*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
<bean id="usuarioManagerTarget"
class="com.eroski.scin.efqm.businesslogic.impl.UsuarioManagerImpl"
singleton="true">
<property name="usuarioDAO">
<ref local="usuarioDAO" />
</property>
</bean>
Así, los métodos especificados se ejecutan bajo la misma transacción.
8.
ANEXO V: HQL
Dado que hibernate proporciona APIs y un lenguaje propio (basado en objetos, no
en relaciones…) para realizar sentencias independientes de la base de datos, se
utilizan esas APIs y el lenguaje HQL.
Página 16 de 16