Está en la página 1de 47

Sistema Gestión FSE 2014 – 2020

Arquitectura y Diseño Técnico


S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 0. Índice

HOJA DE CONTROL
Título Arquitectura y Diseño Técnico

Autor

Versión/Edición V.1.1 Fecha Versión 27/09/2015

Revisado por Fecha Revisión

Aprobado por Fecha de Aprobación

Nº Total Páginas

CONTROL DE CAMBIOS
Versión Causa del Cambio Responsable Fecha

V 1.0 Versión inicial MECD 06/04/2015

CONTROL DE DISTRIBUCIÓN
Nombre y Apellidos Cargo Área / Empresa

13/12/2015
Página 2
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 0. Índice

Índice
HOJA DE CONTROL ................................................................................................................................ 2
CONTROL DE CAMBIOS ......................................................................................................................... 2
CONTROL DE DISTRIBUCIÓN ............................................................................................................... 2
Índice ............................................................................................................................................................ 3
1. Introducción .............................................................................................................................................. 5
1.1. Objetivo .............................................................................................................................................. 5
2. Arquitectura de la Aplicación .................................................................................................................... 6
2.1. Arquitectura general........................................................................................................................... 6
2.2. Contexto Tecnológico ........................................................................................................................ 6
2.3. Arquitectura Interna ........................................................................................................................... 7
2.4. Versiones de las Librerías ............................................................................................................... 11
3. Organización Interna de los Módulos ..................................................................................................... 13
4. Módulo de Gestión de Usuarios ............................................................................................................. 15
4.1. Funcionalidad ................................................................................................................................... 15
4.2. Diseño .............................................................................................................................................. 15
4.3. Transiciones entre Estados ............................................................................................................. 16
5. Módulo de Gestión de Operaciones ....................................................................................................... 17
5.1. Funcionalidad ................................................................................................................................... 17
5.2. Diseño .............................................................................................................................................. 17
5.3. Transiciones entre Estados ............................................................................................................. 21
5.4. Importación y Exportación de Operaciones ..................................................................................... 21
6. Módulo de Verificación ........................................................................................................................... 24
6.1. Funcionalidad ................................................................................................................................... 24
6.2. Diseño .............................................................................................................................................. 24
6.3. Transiciones entre Estados ............................................................................................................. 25
7. Módulo de Gastos y Justificación ........................................................................................................... 26
7.1. Funcionalidad ................................................................................................................................... 26
7.2. Diseño .............................................................................................................................................. 26
7.3. Transiciones entre Estados ............................................................................................................. 28
8. Módulo de Certificación .......................................................................................................................... 29
8.1. Funcionalidad ................................................................................................................................... 29
8.2. Diseño .............................................................................................................................................. 29
8.3. Transiciones entre Estados ............................................................................................................. 30
9. Módulo de Programación ....................................................................................................................... 32
9.1. Funcionalidad ................................................................................................................................... 32
9.2. Diseño .............................................................................................................................................. 32
10. Gestión de la Sesión de los Usuarios .................................................................................................. 33
11. Integración con Sistemas Externos ...................................................................................................... 34
11.1. Integración con Documentum ........................................................................................................ 34
11.2. Integración con @Firma ................................................................................................................ 35
12. Ficheros de Configuración de la Aplicación ......................................................................................... 36
13. Convenciones del Desarrollo ............................................................................................................... 38
13.1. Estructura del Proyecto ................................................................................................................. 38
13.2. Definición de los Paquetes de la Aplicación .................................................................................. 38
13.3. Nombres de Clases, Métodos y Variables .................................................................................... 38
13.4. Gestión de Excepciones ................................................................................................................ 39

13/12/2015
Página 3
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 0. Índice

13.5. Plantillas y Ensamblado de las páginas ........................................................................................ 39


13.6. Convenciones para los Objetos de la Base de Datos ................................................................... 40
14. Arquitectura Física y Despliegue .......................................................................................................... 42
14.1. Topología de la Plataforma ............................................................................................................ 42
14.2. Despliegue en los entornos de Pre-Producción y Producción ...................................................... 43
15. Entorno de Desarrollo........................................................................................................................... 44
15.1. Herramientas ................................................................................................................................. 44
15.2. Versiones de las Herramientas ...................................................................................................... 46
15.3. Ciclo de Desarrollo con SVN y Maven ........................................................................................... 46

13/12/2015
Página 4
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 1. Introducción

1. Introducción
1.1. Objetivo
El objetivo fundamental del documento que se presenta a continuación es la realización de un
diseño técnico pormenorizado de los procesos que desarrollan los casos de usos recogidos en
el análisis funcional realizado con anterioridad, necesarios para la implementación de la
aplicación del Sistema de Gestión de los Fondos Sociales Europeos (SGFSE).

Así, este documento tiene por objeto la recopilación del diseño técnico de la aplicación para
guiar al equipo de desarrollo durante la fase de implementación.

13/12/2015
Página 5
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 2. Arquitectura de la Aplicación

2. Arquitectura de la Aplicación
2.1. Arquitectura general
El siguiente diagrama muestra la arquitectura general del sistema. De un lado están las
Comunidades Autónomas que se conectan a los módulos del Sistema de Gestión de los
Fondos Sociales Europeos (SGFSE) y del otro está la Unidad Administradora del Fondo
Social Europeo (UAFSE) que procesa y consolida toda la información. La interacción entre los
actores y módulos de CCAA y los módulos del SGFSE se realizará a través de una aplicación
web, intercambio de ficheros e invocación de servicios web.

Sistema
Externo

CCAA

Sistema Módulos de
UAFSE
Externo GSFSE

CCAA

Sistema
Externo

CCAA
Arquitectura general del sistema

Los siguientes apartados abordan la arquitectura interna de los módulos del SGFSE
(aplicaciones y servicios) y su implementación.

2.2. Contexto Tecnológico


En el diseño de las aplicaciones distribuidas, se ha convertido en un principio ampliamente
aceptado la división de cada aplicación en componentes que ofrezcan los servicios de
presentación, lógica de negocio y de persistencia (acceso a los datos). Los componentes que
realizan los mismos tipos de funciones se pueden agrupar en capas que están organizadas en
una jerarquía o pila. Así, los componentes que están en una misma capa interactúan entre ellos
directamente y con los componentes de las capas inferiores—pero nunca invocan a los
componentes de las capas superiores.
Es importante tener en cuenta que las capas son simplemente agrupaciones lógicas de los
componentes de software que conforman la aplicación o servicio. Las capas ayudan a
diferenciar entre los tipos de tareas que realizan los componentes y facilitan la comunicación
del diseño y la reutilización en la solución.

13/12/2015
Página 6
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 2. Arquitectura de la Aplicación

Basándonos en los principios generales de diseño de arquitecturas de software, hemos


establecido unas pautas para construir la arquitectura de los módulos del FSE del MECD
separando en capas funcionales cada uno de los “componentes” o “servicios” que darán la
funcionalidad requerida de cada módulo. Esto nos reportará grandes beneficios en términos de
reutilización, escalabilidad, mantenimiento y la optimización del funcionamiento a través de las
últimas tecnologías existentes.

2.3. Arquitectura Interna


Teniendo en cuenta lo anterior, a continuación se muestra el diseño detallado de la aplicación.
Los siguientes apartados, explican la función de cada una de las capas y los componentes que
se usan para su implementación.

Usuarios

Red Sara

Capa de Presentación
Aplicación

Capa de Negocio

Capa de
Integración
Persistencia

me ntum Intranet Bases


Docu de Datos

@Firma Correo

La siguiente tabla resume las características de cada una de las capas. Los apartados que
vienen a continuación las describen con más detalle.

13/12/2015
Página 7
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 2. Arquitectura de la Aplicación

Capa Descripción Componentes


Implementa las páginas de la interface
Páginas JSP, Actions (Struts),
Presentación gráfica de los usuarios. Es la cara visible de
plantillas HTML, CSS
la aplicación.
Implementa la lógica del funcionamiento de Objetos de negocio y servicios
la aplicación, gestión de las transacciones, implementados con clases
Negocio
conversiones de tipos de datos. Es el Java y que se integran con
corazón de la aplicación. Spring
Permite el acceso a la base de datos Entities de persistencia, tablas
Persistencia
relacional de la base de datos
Gestiona el acceso a todos los sistemas
Servicios con stubs de acceso
Integración externos: Documentum, @Firma, servidor
a servicios web
de correos

Capa de Presentación
En el caso de las aplicaciones, la capa de presentación se encarga de implementar la
interacción con los usuarios finales. Se implementa con Struts, páginas JSP, código HTML y
Javascript. Aquí también se instalan los componentes de @Firma: la integración del MiniApplet
de @Firma (cliente ligero para la firma digital en navegadores Web), permite ahorrar tiempo y
esfuerzo en otros mecanismos de firma digital que supongan un aumento en la carga y costes
de desarrollo y pruebas.

Capa de Presentación
Struts 2.x CFX @Firma

JSP HTML

Componentes y librerías utilizados para implementar la capa de presentación

El siguiente diagrama de clases muestra una parte de la jerarquía de actions (Struts) de la capa
de presentación de la aplicación web. Nótese que la superclase AplicacionAction tiene
métodos que simplifican la gestión de la sesión y del usuario. Estos métodos están disponibles
en todas las subclases y se utilizan para gestionar la seguridad, el rol actual del usuario, su
idioma actual, etc.

13/12/2015
Página 8
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 2. Arquitectura de la Aplicación

ActionSupport

Clase
abstracta
AplicacionAction

+getUsuarioSesion()
+getRastroMigas()
+getServicioAdministracion()
+getServicioUsuarios()

AltaEdicionUsuariosAction CargaMasivaAction OperacionesFPBAction

BusquedaUsuariosAction CambiarContraseniaAction OperacionesESOAction

BuscarProgramacionesAction AltaCambioContrasenia LoginCertificadoAction InicioAction

Los actions utilizan clases auxiliares para mostrar y editar la información de los formularios de las
páginas JSP. El siguiente diagrama muestra algunas de estas clases:

FormularioCentro FormularioFiltroOper. FormularioOperacionFPB FormularioTitulo


-provincias -provincias -beneficiarios -titulos
-localidades -beneficiarios -periodos -idOperacion
-codigoCentro -estados -tiposOperacion -idTitulo
-nombreCentro -tiposOperacion -formulariosTitulo -tituloSeleccionado
-idEnsenianza -actuacions -codigoBeneficiario -descripcion
-provincia -periodos -codigoPeriodo -codigo
-rural -orden -idEstado -contieneDescripcionOriginal
-codigoLocalidad -centro -fechaPresentacion -formularioIndicadores
-idProvincia -nombreCentro -descripcionBeneficiario -numeroGrupos
-director -codigoPeriodo -descripcionEstado
-apellido1 -codigoBeneficiario
-apellido2 -idProvincia
-idEstado

Capa de Negocio
La capa de negocio está compuesta objetos de negocio (beans de Java) y un conjunto de
servicios. Los objetos de negocio son las entidades identificadas en la aplicación, como por
ejemplo: las operaciones, los indicadores, los beneficiarios. Los servicios se encargan de
gestionar las transacciones y coordinan el flujo de las operaciones que se inician con las
acciones de los usuarios desde la capa de presentación.

Esta capa delega los accesos a la base de datos en la capa de persistencia y las invocaciones
de servicios remotos a la capa de integración. Finalmente, aquí también se genera los reportes
(con POI y JasperReports).
13/12/2015
Página 9
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 2. Arquitectura de la Aplicación

Capa de Servicios
Jasper
Java Spring Reports

Componentes y librerías utilizados para implementar la capa de servicios

Capa de Persistencia
Esta capa, implementada con Hibernate, centraliza todo el acceso a la base de datos relacional
(Oracle) para hacer consultas, inserciones, actualización y borrado de datos en las tablas. Los
datos mantenidos en la base de datos son representados con objetos denominados entities
que definen el mapeo con las columnas de las tablas utilizando anotaciones especiales en las
clases.

Capa de Persistencia
Hibernate JDBC

Componentes y librerías utilizados para implementar la capa de persistencia

El siguiente diagrama de clases muestra una parte de la jerarquía de entities de la capa de


persistencia de la aplicación:

IndicadorEntity
-id
DefinicionIndicadorEntity
-idOperacion
-codigo -idTitulo OperacionEntity
-codigoTipoIndicador -codigoDefinicion
-descripcion -hombres -id
-descripcionCorta -mujeres -codigoBeneficiario
-codigo -otros -codigoActuacion
-idCentro
-codigo
-codigoPeriodo
-idEstado
UsuarioEntity CentroEntity -codigoTipo
-id -id -fechaPresentacion
-nombre -codigoLocalidad -fechaInicio
-apellido1 -idProvincia -fechaFinPrevista
-apellido2 -nombre -convocatoriaPermanente
-email -tipoEnsenianza -coejecutable
-hashContrasena -directorNombre -costeTotal
-tipoDocumento -directorApellido1
-numeroDocumento -directorApellido2
-idioma -direccion
-codigoEstado

Hibernate también proporciona un lenguaje de consulta para recuperar información de la base


de datos. En nuestro caso, todas las operaciones de acceso a la base de datos están
implementadas en unas clases Java que se denominan repositorios. A continuación se
muestran algunas de esas clases:

13/12/2015
Página 10
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 2. Arquitectura de la Aplicación

UsuarioRepository AdministracionRepository OperacionesRepository


-sessionFactory -sessionFactory -sessionFactory
+actualizarUsuario() +getBeneficiariosTodos() +actualizarOperacion()
+agregarUsuario() +getLocalidadPorCodigo() +agregarIndicador()
+eliminarUsuario() +getProvinciasTodas() +agregarOperacion()
+getUsuarioPorDocumentoIdentidad() +actualizarCentro() +eliminarIndicadoresPorId()
+getUsuarioPorId() +agregarCentro() +eliminarOperacion()
+getUsuarios() +agregarCoejecutor() +getOperaciones()
+getOperacionPorId()
+getTitulosTodos()

Capa de Integración
Esta capa gestiona las invocaciones a los servicios remotos (Documentum, @Firma). Los
servicios se invocan mediante stubs generados con Apache CFX.

Capa de Integración
Spring CFX

Componentes y librerías utilizados para implementar la capa de integración

El gestor documental Documentum proporciona una API de Java que permitiría realizar tareas
específicas desde el propio aplicativo. Documentum puede emplearse para la gestión de los
documentos que deben aportarse en los módulos de Justificación Financiera, Verificación y
Auditoría.

Otro componente externo importante es el servidor de correo que se utiliza para el envío de
todas las notificaciones a los usuarios (activación de cuentas, envío de mensajes y alertas de
operaciones, etc.). Este servidor de correo está proporcionado por el MECD (host =
servidor.mecd.es, puerto = 25). Mediante la integración de envío de correos de Spring se
accede a este servidor para el envío de estas notificaciones.

Finalmente, es importante señalar que la integración con el Registro de Centros de Formación


del MECD se realiza a través de la capa de persistencia porque la consulta del Registro se
hace con una vista creada en la base de datos: MVW_CENTROS_WEB_V1.

2.4. Versiones de las Librerías


La siguiente tabla resume las versiones de las principales librerías utilizadas en la
implementación de los módulos.
Nótese que la tabla no incluye todas las dependencias requeridas ni las librerías auxiliares
(Apache Commons, Spring Security, etc.).

Librería Versión
CFX 2.7

Hibernate 4.1

13/12/2015
Página 11
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 2. Arquitectura de la Aplicación

Spring 3.1

Struts 2.3

Log4J 1.2

POI (generar y procesar Excel) 3.11

JasperReports (reportes en pdf) 5.6.1

Driver Oracle 6.x (compatible con Oracle 11g)

13/12/2015
Página 12
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 3. Organización Interna de los Módulos

3. Organización Interna de los Módulos


En el apartado anterior se presentaba la siguiente jerarquía de capas “lógicas”: Capa de
Presentación, Capa de Negocio y Capa de Persistencia:

Capa de Presentación
Aplicación

Capa de Servicios

Capa de Persistencia

Las capas implementan diferentes aspectos de los módulos funcionales de la aplicación y por
lo tanto pueden verse que son transversales a éstos. El siguiente diagrama muestra algunos
módulos de la aplicación. Nótese que todos los módulos tienen requerimientos de
implementación en las tres capas de la arquitectura:
Módulo Programación
Módulo Operaciones

Capa de Presentación
Módulo Usuarios
Aplicación

Capa de Servicios

Capa de Persistencia

Las capas se integran entre sí mediante el mecanismo de inyección de dependencias de


Spring (anotación @autowired).

El siguiente diagrama muestra la cadena de delegación de responsabilidades desde un


componente de la capa de presentación (OperacionesFPBAction) en un servicio de la capa
de negocio (OperacionesService) y éste a su vez delega en un repositorio de la capa de
persistencia (OperacionesRepository):

13/12/2015
Página 13
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 3. Organización Interna de los Módulos

OperacionesFPBAction

delega en
+buscar()
+cancelar()
+cargarListasBuscador()
+editar()

OperacionesESOAction
delega en
+buscar()
+cancelar()
+editar()

OperacionesService OperacionesRepository
-repositorioAdministracion -sessionFactory
-repositorioOperaciones +actualizarOperacion()
-factoryAdministracion +agregarIndicador()
delega en
-serviceAdministracion +agregarOperacion()
-serviceAuditoria +eliminarIndicadoresPorId()
-cacheEstadosOperacion +eliminarOperacion()
-cacheTitulos +getOperaciones()
-cacheDefinicionesIndicador +getOperacionPorId()
+getTitulosTodos()

El siguiente diagrama de secuencia muestran el flujo completo de invocaciones desde la capa


de presentación (páginas HTML) hasta la capa de persistencia:

El usuario interactúa la
interface de la aplicación
desde su navegador

Navegador Action Servicio Repositorio Base de Datos

buscar(...)
getOperaciones(filtro)
getOperaciones(filtro)
SQL

{registros}
{entities}
{objetos de negocio}
{código HTML}

Los siguientes apartados describen los detalles de la implementación de este flujo en cada una
de las capas

13/12/2015
Página 14
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 4. Módulo de Gestión de Usuarios

4. Módulo de Gestión de Usuarios


4.1. Funcionalidad
El módulo de usuarios implementa toda la gestión de los usuarios de la aplicación:
 Alta de nuevos usuarios en la aplicación
 Modificación de los datos de un usuario
 Baja de un usuario existente. Nótese que todas las bajas de usuarios son “lógicas”—los
usuarios no son borrados físicamente de las tablas
 Mecanismo de activación de los usuarios que utilizan contraseña para acceder—envío de
correos
 Recuperación de contraseñas

4.2. Diseño
El siguiente diagrama de clases muestra las entidades de la capa de negocio que participan en
este módulo:
Cada rol tiene 0..n beneficiarios. Para
cada beneficiario, el rol tiene 0..n
actuaciones asociadas. Ej: “Juana tiene
el rol de beneficiaria para Madrid en las
operaciones de ESO y FPB”

Usuario Rol beneficiarios Beneficiario


roles
-nombre -codigo
[ beneficiario ]
-apellido1 -descripcion
-apellido2 -idCCAA
actuacionesPorBeneficiario

-tipoDocumento
-numeroDocumento
-idioma

Las definiciones son: “rol DefinicionRol


Actuacion
de administrador”, “rol de -descripcion
verificador”, “rol OI”, “rol -requiereBeneficarios -codigo
de auditor”, “rol de -requiereActuaciones -descripción
beneficiario”

Este “calificador”
expresa que en cada rol,
cada beneficiario tiene
una lista de actuaciones

13/12/2015
Página 15
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 4. Módulo de Gestión de Usuarios

El siguiente esquema muestra las tablas utilizadas por el módulo de gestión de usuarios:

4.3. Transiciones entre Estados


Durante su ciclo de vida, los usuarios van cambiando de estado. Dentro de la aplicación, los estados se
representan con un tipo enumerativo: EstadoUsuario. El siguiente diagrama resume los principales
estados de los usuarios:

Alta (administrador)

Eliminar
(administrador)

Pendiente De
Activación Baja
Activa cuenta
)
Recuperar contraseña (usuario) ar or
in ad
(usuario) l im istr
E in
r or)
a dm ti va ra d
Reenviar correo activación ( a c n i st
(administrador) i
dm
(a

Activado

13/12/2015
Página 16
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 5. Módulo de Gestión de Operaciones

5. Módulo de Gestión de Operaciones


5.1. Funcionalidad
El módulo de operaciones implementa la gestión de las operaciones de la aplicación:
 Alta, baja y modificación de operaciones FPB
 Alta, baja y modificación de operaciones ESO
 Alta, baja y modificación de operaciones Acredita
 Búsqueda de operaciones utilizando filtros
 Exportación de operaciones a Excel
 Importación de operaciones desde Excel
 Presentación, validación y devolución de operaciones

5.2. Diseño
El siguiente diagrama de clases muestra las entidades de la capa de negocio que participan en
este módulo:

13/12/2015
Página 17
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 5. Módulo de Gestión de Operaciones

Categorías: “Menos
desarrollada”,
CategoriaRegion “Transitoria”...
Cada beneficiario tiene una lista -cofinanciacion
de responsables para cada -region
actuación
Cada beneficiario tiene una lista
de períodos para cada
categoria actuación

ResponsableBeneficiario responsablesPorActuacion Beneficiario periodosPorActuacion Periodo


-nombre codigo -id
[Actuacion] [Actuacion]
-apellidos descripcion -codigo
-NIF idCCAA -fechaInicio
-dirección -fechaFin

Clase
abstracta
responsable Operacion periodo

TipoOperacion -id estado EstadoOperacion


Los tipos posibles
tipo -codigo
son: FPB1, FPB2, -fechaPresentacion
ESO3, ESO4 y -fechaInicio definiciones
Convocatoria -fechaFin Indicadores
+exportarIndicadores()
+importarIndicadores()

centro
OperacionFPB OperacionESO OperacionAcredita coejecutores Coejecutor
centro -coejecutable acciones
-nombre
+getIndicadoresEspecificos() -fechaConvocatoria -apellidos
+getIndicadoresCentro()
+getIndicadorPorTitulo() -convocatoriaPermanente -NIF
+getIndicadorCentroPorCodigo()
+getIndicadorGrupo() -direccion
+getGruposMatematicasAplicadas()
Centro titulos [ Título ] +getGruposMatematicasAcademicas()
+getGruposEnsenanzasAplicadas()
-nombre +getGruposEnsenanzasAcademicas()
-codigo +getNumeroGruposClase()
indicadores
-directorNombre
AccionAcredita
-directorApellido1 indicadoresPorTitulo
-directorApellido2 -id
-. . . -descripcion

Indicador
Titulo
-id tipo
-id titulo -hombres
Este “calificador” expresa -descripcion -mujeres
que cada operación tiene -otro
varios indicadores TipoAccionAcredita
asociados a cada título Los tipos son: -codigo
definicion Resultado, Ejecución, -descripcion
Financiero...

DefinicionIndicador
tipo TipoIndicador
-id
-descripcion -id
-aplicableFPB -descripcion
-aplicableESO
-aplicableAcredita

Las clases que aparecen en el centro y están pintadas de color más oscuro implementan la
funcionalidad de las operaciones. La superclase de la jerarquía, Operacion, es abstracta e
implementa el mecanismo genérico para la gestión de los indicadores colaborando con las
clases DefinicionIndicador, Indicador, TipoIndicador). Las subclases se basan en este
mecanismo y lo especializan para implementar la gestión de los indicadores para cada tipo
específico de operación (FPB, ESO, Acredita, etc.). Así, por ejemplo, las operaciones de FPB
tienen indicadores a nivel de los títulos y las operaciones de ESO solo tienen indicadores a
nivel de centro de formación.

13/12/2015
Página 18
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 5. Módulo de Gestión de Operaciones

En modelo de clases también incluye tipos enumerativos que representan conceptos como los
tipos de operaciones, las actuaciones, objetivos, prioridades y ejes:

“FPB-1”, “FPB-2”, “Reducción”, “Aprendizaje”,


“ESO-3”, “ESO-4” “Refuerzo”...

TipoOperacion actuación Actuacion objetivo Objetivo prioridad Prioridad


-codigo -codigo -codigo -codigo
-descripcion -descripcion -descripcion -descripcion

“FPB y ESO”, eje


Las actuaciones son: "0.0.0.0"
(Asistencia técnica), "10.3.2.1"
“Acredita”, “Calidad”...
(Acredita), "10.1.1.1" (Ciclos Eje
FPB), "10.1.1.2" (Nuevos Hay dos ejes:
-descripcion
Itinerarios: ESO), etc “Eje 3” y “Eje 8”
-id

El siguiente esquema muestra las tablas utilizadas por el módulo de operaciones:

13/12/2015
Página 19
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 5. Módulo de Gestión de Operaciones

13/12/2015
Página 20
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 5. Módulo de Gestión de Operaciones

5.3. Transiciones entre Estados


Durante su ciclo de vida, las operaciones van cambiando de estado. Dentro de la aplicación, los estados
se representan con un tipo enumerativo: EstadoOperacion.

En general, estos cambios son iniciados por el usuario cuando utiliza la aplicación e invoca opciones
especiales de menú—solo es accesibles con roles específicos de los usuarios. Algunas transiciones
provocan el envío de notificaciones de correo a los actores involucrados en la operación (responsable,
etc.).

También hay transiciones automáticas que se producen con el paso del tiempo y que son iniciadas por
procesos internos de la aplicación. El siguiente diagrama resume los principales estados de las
operaciones:

En este estado se cargan los


Alta (beneficiario regional)
datos del centro (FSP/ESO) o de
Es el estado inicial de la convocatoria (Acredita)
las operaciones (alta)

Borrador Eliminar
Eliminada
(beneficiario regional)
n l)
ci ó n a
e ra g i o
p re
r o io
d ita ciar Presentar
E ef i
(responsable regional)
En este estado se cargan
en los indicadores de
(b
ejecución y gastos

Fin de
Devuelta Propuesta Ejecución
Devolver Validar Ejecución
(gestión OI) (gestión OI)

5.4. Importación y Exportación de Operaciones


El módulo de operaciones también incorpora funcionalidad para importar y exportar
operaciones. Los siguientes diagramas de secuencia muestran el flujo completo de
invocaciones para la exportación de operaciones de tipo ESO y FPB respectivamente:

13/12/2015
Página 21
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 5. Módulo de Gestión de Operaciones

El usuario quiere exportar las operaciones


ESO del resultado de una búsqueda en un
documento Excel

Action ProcesoExportarOperaciones ConvertidorExcel OperacionesService

getOperaciones(filtro)
{operaciones}

exportarOperacionesESO(operaciones)

exportarFilasESO(filas)

{Documento Excel}
{Documento Excel}

El usuario quiere exportar las operaciones


FPB del resultado de una búsqueda en un
documento Excel

Action ProcesoExportarOperaciones ConvertidorExcel OperacionesService

getOperaciones(filtro)
{operaciones}

exportarOperacionesFPB(operaciones)

exportarFilasFPB(filas)

{Documento Excel}
{Documento Excel}

13/12/2015
Página 22
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 5. Módulo de Gestión de Operaciones

Los siguientes diagramas de secuencia muestran el flujo completo de invocaciones para la


validación e importación de operaciones de tipo FPB. El flujo para las operaciones de tipo ESO
es similar—solo varían las plantillas de datos.

El usuario quiere
validar los datos de las Action ProcesoImportarOperaciones ConvertidorExcel OperacionesService
operaciones en Excel
antes de importarlas
en el sistema
validarDatosOperacionesFPB(Excel)

importarDatosOperacionesFPB(Excel)

{registros}

{ResultadoImportacion} validarRegistros

El usuario quiere
importar los datos de
las operaciones en
Excel
importarDatosOperacionesFPB(Excel)

validarOperacionesFPB(Excel)
importarOperacionesFPB(registros)
{ResultadoImportacion}

El usuario quiere
validar los indicadores
de las operaciones en
Excel antes de
importarlos en el
sistema
validarIndicadoresFPB(Excel)
importarIndicadoresFPB(Excel)

{registros}

validarRegistros
{ResultadoImportacion}

El usuario quiere
importar los
indicadores de las
operaciones en Excel
importarIndicadores(Excel)

validarIndicadoresFPB(Excel)

importarIndicadores(registros)
{ResultadoImportacion}

13/12/2015
Página 23
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 6. Módulo de Verificación

6. Módulo de Verificación
6.1. Funcionalidad
El módulo de verificación de operaciones se encarga de:
 Gestionar el alta, baja y modificación de las verificaciones de las operaciones
 Permitir la selección de las operaciones que corresponden a cada verificación
 Almacenar los documentos de las verificaciones en Documentum

6.2. Diseño
El siguiente diagrama de clases muestra las entidades de la capa de negocio que participan en
este módulo:

Beneficiario
codigo
descripcion
idCCAA

VerificacionFisica Irregularidad
-id irregularidades
-id
-idOperacion -causaIrregularidad
-codigoOperacion -tipoIrregularidad
VerificacionInSitu verificacionFisicas -direccion
id -localidad
estado -fechaInicio documentoMedidas
fechaInicio Adoptadas
-fechaFin
fechaFin -nivelRiesgo

actas
Documento
-id
checkListsInSitu -nombre
-fechaAlta
documentosVerificacionInSitu
-contenido

13/12/2015
Página 24
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 6. Módulo de Verificación

El siguiente esquema muestra las tablas utilizadas por el módulo de operaciones:

6.3. Transiciones entre Estados


Durante su ciclo de vida, las verificaciones van cambiando de estado. Dentro de la aplicación,
los estados se representan con un tipo enumerativo: EstadoVerificacionInSitu.

En general, estos cambios son iniciados por el usuario cuando utiliza la aplicación e invoca
opciones especiales de menú—solo es accesibles con roles específicos de los usuarios.

El siguiente diagrama muestra las transiciones de estados de las verificaciones:

Es el estado inicial de Alta (gestión OI)


las verificaciones
(alta). Rol:
beneficiario regional
eliminar
Alta Eliminada Validada

validar

13/12/2015
Página 25
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 7. Módulo de Gastos y Justificación

7. Módulo de Gastos y Justificación


7.1. Funcionalidad
El módulo de justificación y gestión de gastos se encarga de:
 Gestionar los gastos de las operaciones de cada beneficiario
 Crear justificaciones de un conjunto de gastos
 Crear el documento de solicitud de reembolso de una justificación

7.2. Diseño
El siguiente diagrama de clases muestra las entidades de la capa de negocio que participan en
este módulo:

JustificacionEconomica Gasto Baremo


gastos baremo
id -id -id
codigo -idOperacion -codigoBaremo
estado -codigoGasto -coste
fechaInicio -direccion -unidad
fechaPresentacion -numeroUnidades -tipoFormacion
-estado -tipoBaremo

lineaBase

LineaBase
Documento
-id
-id -tipoOperacion
documentoSolicitudReembolso -nombre -beneficiario
-fechaAlta -periodo
-contenido -fechaInicioAltaOperaciones
-fechaFinAltaOperaciones
-tipoFormacion

13/12/2015
Página 26
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 7. Módulo de Gastos y Justificación

El siguiente esquema muestra las tablas utilizadas por el módulo de gastos y justificaciones:

13/12/2015
Página 27
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 7. Módulo de Gastos y Justificación

7.3. Transiciones entre Estados


Durante su ciclo de vida, las justificaciones y los gastos van cambiando de estado. Dentro de la
aplicación, los estados se representan con tipos enumerativos: EstadoGasto y
EstadoJustificacionEconomica.

En general, estos cambios son iniciados por el usuario cuando utiliza la aplicación e invoca
opciones especiales de menú—solo es accesibles con roles específicos de los usuarios.
Algunas transiciones provocan el envío de notificaciones de correo a los actores involucrados
en la operación (responsable, etc.) y también la generación de documentos.

El siguiente diagrama muestra las transiciones de estados de las justificaciones:

Eliminada

l)
r ona
i n a re g i eliminar
Alta (gestión OI) i m
e l ri o (gestión OI)
a
i ci eliminar
Es el estado inicial de n ef (responsable
b e
( benef.)
las justificaciones
(alta). Rol:
preparar presentar
beneficiario regional (responsable (responsable aprobar (aceptar)
beneficiario) beneficiario) (gestión OI)
Alta Preparada Presentada Aceptada
Al pasar a este
estado, se genera el
PDF de la justificación
devolver
(gestión OI)

El siguiente diagrama muestra todas las transiciones de estados de los gastos, algunas de las
cuales se producen durante los cambios de estado de las justificaciones:

Alta (gestión OI)


Es el estado inicial de
los gastos (alta)
presentar justificación
aprobar la justificación
(gestión OI)
(gestión OI)
Alta Seleccionado Justificado
eliminar justificación

Se elimina la certificación. El gasto se añade a


El gasto se libera una certificación
(gestión OI)

Se valida la
certificación Se presenta la
certificación. El gasto no
(gestión OI) Preparado cambia de estado
Certificado
certificar (gestión OI)

Se rechaza la
certificación. El gasto
no cambia de estado
(gestión OI)

13/12/2015
Página 28
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 8. Módulo de Certificación

8. Módulo de Certificación
8.1. Funcionalidad
El módulo de certificación se encarga de:
 Crear certificaciones con los gastos que han sido justificados y que deben enviarse a la
UAFSE
 Crear el documento XML con toda la información para la UAFSE.

8.2. Diseño
El siguiente diagrama de clases muestra las entidades de la capa de negocio que participan en
este módulo:

Certificacion
Gasto Baremo
id gastos baremo
-id -id
codigo
-idOperacion -codigoBaremo
estado
-codigoGasto -coste
beneficiario
-direccion -unidad
actuacion
-numeroUnidades -tipoFormacion
fechaCreacion
-estado -tipoBaremo
fechaValidacion
fechaBaja

lineaBase

LineaBase
Documento
-id
-id -tipoOperacion
reporteOperaciones -nombre -beneficiario
-fechaAlta -periodo
-contenido -fechaInicioAltaOperaciones
-fechaFinAltaOperaciones
-tipoFormacion

13/12/2015
Página 29
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 8. Módulo de Certificación

El siguiente esquema muestra las tablas utilizadas por el módulo de certificación:

8.3. Transiciones entre Estados


Durante su ciclo de vida, las certificaciones van cambiando de estado. Dentro de la aplicación, los
estados se representan con un tipo enumerativo: EstadoCertificacion.

En general, estos cambios son iniciados por el usuario cuando utiliza la aplicación e invoca opciones
especiales de menú—solo es accesibles con roles específicos de los usuarios. Algunas transiciones
provocan el envío de notificaciones de correo a los actores involucrados en la operación (responsable,
etc.) y también la generación de documentos.

El siguiente diagrama muestra las transiciones de estados de las certificaciones:

Al pasar a este estado,


se genera el XML de la
Es el estado inicial de Alta (gestión OI) certificación
las certificaciones
(alta) presentar
(gestión OI) validar
(control OI)
Borrador Propuesta Validada
devolver
(gestión OI)

13/12/2015
Página 30
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 8. Módulo de Certificación

El siguiente diagrama muestra todas las transiciones de estados de los gastos, algunas de las
cuales se producen durante los cambios de estado de las certificaciones:

Alta (gestión OI)


Es el estado inicial de
los gastos (alta)
presentar justificación
aprobar la justificación
(gestión OI)
(gestión OI)
Alta Seleccionado Justificado
eliminar justificación

Se elimina la certificación. El gasto se añade a


El gasto se libera una certificación
(gestión OI)

Se valida la
certificación Se presenta la
certificación. El gasto no
(gestión OI) Preparado cambia de estado
Certificado
certificar (gestión OI)

Se rechaza la
certificación. El gasto
no cambia de estado
(gestión OI)

13/12/2015
Página 31
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 9. Módulo de Programación

9. Módulo de Programación
9.1. Funcionalidad
El módulo de programación se encarga de mostrar la senda financiera cargada actualmente en
la aplicación.

9.2. Diseño
El siguiente diagrama de clases muestra las entidades de la capa de negocio que participan en
este módulo:
Programacion dotacionesPorEje
version
reprogramacion dotacionesPorPrioridad

DotacionEconomica detallesCostesCCAA CostesDotacion


-costesTotalesPorAnyo
dotacionesPorMedida
+getCostesPorCategoria() +getCosteTotal()
+getTotalesPorCategoria() +getCosteSubvencionable()

DotacionEconomicaPorMedida DotacionEconomicaPorPrioridad DotacionEconomicaPorEje CostesCCAA CostesTotales


medida prioridad eje -beneficiario

El siguiente esquema muestra las tablas utilizadas por el módulo de programación:

13/12/2015
Página 32
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 10. Gestión de la Sesión de los Usuarios

10. Gestión de la Sesión de los Usuarios


La palabra “sesión” se refiere a las interacciones del usuario con la aplicación para las que el
servidor realiza un seguimiento. Las sesiones se usan para mantener el estado específico del
usuario, su identidad, idioma, etc. En nuestro caso, la sesión se usa para hacer el seguimiento
del usuario una vez que ha sido autenticado en la aplicación. Lo importante es que la sesión
como tal es gestionada por el servidor y reside en el espacio de memoria de éste.

Con cada invocación HTTP que el usuario realiza a través del navegador, se envía un
identificado único de sesión (ID) que permite al servidor reconocer al usuario del cual proviene
la petición. La sesión del usuario se mantiene viva en el servidor durante todo el tiempo que el
usuario interactúa con la aplicación. La sesión se cierra cuando el usuario sale explícitamente
de la aplicación (opción de menú “Cerrar Sesión”) o cuando pasan 30 minutos sin actividad por
parte del usuario.

Dentro de la aplicación, la superclase AplicacionAction tiene métodos que simplifican la


gestión de la sesión y del usuario. Estos métodos están disponibles en todas las subclases y se
utilizan para gestionar la seguridad, el rol actual del usuario, su idioma actual, etc.

La gestión de la autenticación y autorización de los usuarios de la aplicación está montada con


el framework Spring Security, que se basa en el uso de filtros estándar (ver ficheros web.xml y
presentación.xml de la configuración). La clase AutenticacionService implementa la
interface UserDetailsService para hacer la autenticación con DNI y contraseña. La clase
LoginCertificadoAction realiza la autenticación de los usuarios que utilizan certificado digital.

La aplicación también permite a los usuarios cambiar fácilmente el rol activo desde una opción
en el menú personal. La clase CambiarRolActivoAction es un action que Struts que
implementa esta funcionalidad.

13/12/2015
Página 33
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 11. Integración con Sistemas Externos

11. Integración con Sistemas Externos


11.1. Integración con Documentum
La aplicación permite a los usuarios adjuntar documentación en varios de los módulos, como
por ejemplo adjuntar las actas de las verificaciones in-situ. Por otro lado, la aplicación también
genera documentos que son descargados por los usuarios, como ocurre con las solicitudes de
reembolso en el módulo de justificaciones y gastos.

En ambos casos, toda la documentación recibida y producida por la aplicación es almacenada


en un gestor documental: Documentum.

Cada documento almacenado en Documentum tiene las siguientes propiedades:


 Un ID para identificarlo unívocamente. Este ID permite a la aplicación descargar el
documento del gestor documental y mostrarlo al usuario
 Un contenido binario (secuencia de bytes)
 Varios metadatos asociados que se representan con tipos documentales y otros atributos
(fecha de creación, etc.)

La aplicación interactúa con Documentum a través de un servicio web desplegado en la


intranet del MECD. El siguiente diagrama muestra las principales clases que participan en la
integración:

VerificacionesService
JustificacionesService
agregarVerificacionInSitu()
agregarJustificacionEconomica() actualizarVerificacionInSitu()
actualizarJustificacionEconomica() getVerificacionesInSitu()
eliminarJustificacionEconomica() servicioDocumentum
servicioDocumentum

CMISSoap
CertificacionService servicioDocumentum
DocumentumService stub
createDocument()
agregarCertificacion() createFolder()
actualizarCertificacion() agregarDocumento() deleteDocument()
eliminarCertificacion() eliminarDocumento() existsDocument()
getDocumentoPorId() getDocumentBytes()
getDocumentProperty()
getDocumentURL()
searchDocuments()
searchDocumentsIds()
searchDocumentsWithAllProperties()

13/12/2015
Página 34
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 11. Integración con Sistemas Externos

11.2. Integración con @Firma


La aplicación también se integra con @Firma para ofrecer la siguiente funcionalidad:
 Validar los certificados de los usuarios que se identifican con un certificado digital. Este
paso requiere que la aplicación se conecte a un servicio web desplegado en la intranet del
MECD.
 Realizar la firma electrónica de la documentación presentada por los usuarios. Para esto se
utiliza el mecanismo de firma implementado por el MiniApplet de @Firma.

El MiniApplet de @Firma es una herramienta de firma electrónica que funciona en forma de


Applet de Java integrado en una página Web mediante JavaScript. Este applet no almacena
ningún tipo de información personal del usuario, ni hace uso de cookies ni ningún otro
mecanismo para la gestión de datos de sesión. El MiniApplet sí almacena el log de su última
ejecución a efectos de ofrecer soporte al usuario si se encontrase
algún error durante la ejecución del Applet.

La integración del MiniApplet se ha realizado según las indicaciones del correspondiente


manual: “Manual del integrador del MiniApplet v1.3 del Cliente @Firma” disponible en:

http://administracionelectronica.gob.es/ctt/afirma/

El siguiente diagrama muestra las principales clases de la aplicación que participan en la


integración con @Firma:

LoginCertificadoAction

servicioVerificacion
VerificacionFirmasCertificadosService stub ServicioVerificador

validarCertificadoAutenticacion() getCertificado(String, boolean, boolean, boolean)()


validarFirma() validarCertificadoAutenticacion(String)()
servicioVerificacion validarCertificadoFirma()
validarFirmaCadesExplicit()
validarFirmaCadesImplicit()
validarFirmaPDF()
PresentarOperacionesAction validarFirmaPDFAddTS()
validarFirmasPDF()

13/12/2015
Página 35
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 12. Ficheros de Configuración de la Aplicación

12. Ficheros de Configuración de la Aplicación


La siguiente tabla muestra todos los ficheros de configuración de la aplicación. Todos ellos van
empaquetados en el fichero de despliegue (.war).

Nombre del fichero Descripción


Contiene los parámetros de la conexión a la base de datos. Existen 4
versiones de este fichero, una para entorno de despliegue. Al
datasource.xml momento de generar el war, Maven inserta la versión que
corresponda al entorno de despliegue seleccionado. Ver más
detalles en: notas.html en el proyecto Eclipse.
Contiene varios los parámetros de configuración utilizados
gesfse.properties internamente por la aplicación y que no son específicos de ninguna
librería. Ver el listado de parámetros en el siguiente apartado.
Declara parámetros que se utilizan para configurar la capa de
persistencia.xml
persistencia y la integración de Spring con Hibernate
Declara parámetros que se utilizan para configurar la capa de
presentacion.xml presentación: actions de Struts, rutas de seguridad, integración con
Spring
Declara parámetros que se utilizan para configurar la capa de
servicios.xml negocio, la integración con Spring, CXF y gestión declarativa de las
transacciones
Declara los servicios web consumidos por la aplicación (@Firma,
webservices.xml
etc.)
Son las plantillas utilizadas por Velocity para crear el contenido
*.vm HTML de los correos de activación de usuarios y recuperación de las
contraseñas.
Son las plantillas con la traducción de los mensajes y etiquetas
messages_*.properties mostrados en las páginas. Estas plantillas son utilizadas por Struts y
los procesos de importación de datos.
Es el fichero de configuración de Struts.
struts.xml
Ver también: presentación.xml.
Es el fichero de configuración de Tiles. Contiene la declaración de
tiles.xml
las plantillas que se usan para construir las páginas de la aplicación.
Este fichero es utilizado por Maven. Contiene la declaración de todas
las dependencias (librerías), scripts para generar stubs de los
pom.xml
servicios web, etc. Ver más detalles en: notas.html en el proyecto
Eclipse.
Son las plantillas que se usan en los procesos de exportación e
*.xlsx
importación de operaciones (carga masiva).
*.wsdl Es la definición de un servicio web consumido por la aplicación (Ej:

13/12/2015
Página 36
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 12. Ficheros de Configuración de la Aplicación

@Firma). Estos ficheros son utilizados por Maven para generar las
clases de los stubs en Java.

Parámetros de gesfse.properties

Nombre del fichero Descripción


Es la URL del dominio de despliegue del servidor. Por
ejemplo: https://aplipre.mecd.es. Esta URL se utiliza en los
mecd.url correos de activación de las cuentas de los usuarios para
construir el enlace que debe pinchar el usuario. El valor es
distinto para cada entorno de despliegue
Es el endpoint del servicio web de @Firma. Se invoca para
servicioVerificacion.endpoint validar los certificados de los usuarios que se identifican con
un certificado digital
documentum.endpoint Es el endpoint del servicio web intermediario de Documentum
documentum.atom.url La URL para acceder a Documentum
documentum.usuario ID del usuario para conectarse con Documentum
documentum.contrasena Contraseña para conectarse con Documentum
Un flag que indica si se pueden enviar correos. Los valores
email.activo
posibles son: false y true.
Cuenta de correo del remitente para los correos enviados por
email.remitente
la aplicación

13/12/2015
Página 37
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 13. Convenciones del Desarrollo

13. Convenciones del Desarrollo


13.1. Estructura del Proyecto
La aplicación se diseña siguiendo la definición del estándar J2EE. La estructura del proyecto en
Eclipse está creada con el arquetipo de aplicaciones web de Maven, que se muestra a
continuación.

13.2. Definición de los Paquetes de la Aplicación


El proyecto (Eclipse) tiene por un lado, las clases y recursos que corresponden a la
implementación de la aplicación (src/main) y por otro las clases y recursos de las pruebas
unitarias (src/test). El fichero pom.xml contiene la definición de las dependencias, targets y
demás parámetros utilizados por Maven.

Siguiendo las convenciones ya definidas en MECD, los paquetes del proyecto están
organizados de la siguiente manera:

13.3. Nombres de Clases, Métodos y Variables


En general, se adoptan todos los estándares y convenciones definidos para el lenguaje Java.
Los nombres de las clases, métodos y variables deben ser siempre castellanos o
castellanizados, evitando caracteres especiales como ñ, tildes, etc. Se admite el uso de prefijos
o sufijos en inglés a efectos de homogeneizar la nomenclatura de clases, propiedades y

13/12/2015
Página 38
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 13. Convenciones del Desarrollo

métodos para adecuarlos a la tecnología específica que se ha decidido utilizar. Por ejemplo:
usar “get” ,“set” o “is” para los beans.

Los nombres de las clases corresponden a sustantivos y son descriptivos de la función dentro
del modelo de objetos de la aplicación. En algunos casos también se añade un sufijo que
especifica su papel dentro de la jerarquía de capas. Por ejemplo: OperacionEntity,
OperacionRepository, etc.

Los nombres de los métodos deben ser siempre verbos. Si se trata de nombres compuestos
por varias palabras, la primera letra de cada palabra es una mayúscula. Por ejemplo:
setNombre(…), procesarOperacionesPendientes(), etc.

Los nombres de las variables de instancia y variables locales no pueden comenzar con “_” o “$”.
Deben ser breves y comunicar el significado de forma evidente. Se evitarán las variables de un
carácter, con la sola excepción de las variables de las cláusulas catch() y los contadores
temporales de los bucles (e, i, j, k, m). Los nombres de las variables no tendrán ningún prefijo
que indique el tipo del objeto u otro clasificador. Los nombres de constantes van en
mayúsculas y con un “_” para separar las palabras (por ejemplo: CANTIDAD_MAXIMA).

13.4. Gestión de Excepciones


Las excepciones son errores que ocurren durante la ejecución de la aplicación y afectan el flujo
normal de funcionamiento. Java ofrece una infraestructura robusta y basada en objetos para
gestionar los diferentes escenarios de excepciones.

En general, cuando se produce una excepción, la aplicación debe tratarla, propagarla o generar
una traza en el fichero de log. Si el bloque de código donde ocurre la excepción puede tratarla,
entonces deberá hacerlo. Caso contrario, por normal general, las excepciones serán
propagadas y tratadas en los niveles superiores.

Nunca deben usarse cláusulas try/catch vacías y siempre debe dejarse una traza en el fichero
de log con toda la pila de ejecución correspondiente. Las trazas serán generadas con la librería
Log4J y el fichero de configuración irá embarcado dentro de la misma aplicación (.war). En
ningún caso se deben generar trazas con System.out o System.err.

Las clases de excepciones específicas de la aplicación seguirán las convenciones definidas


previamente para el nombrado de clases y además deben terminar con el sufijo “Exception”.
Por ejemplo: “ValidacionUsuarioException”.

Finalmente, debe tenerse en cuenta que las excepciones son caras de gestionar y que deben
usarse razonablemente. Esto significa que debe analizarse si en algunos casos es más simple
retornar un flag booleano para indicar que una operación se realizó con éxito o no—en lugar de
lanzar y propagar una excepción.

13.5. Plantillas y Ensamblado de las páginas


Las páginas HTML que representan la funcionalidad y navegación de la aplicación para los
usuarios finales serán generadas a partir de una o varias plantillas. Así, cada página
únicamente cambia una porción—normalmente el cuerpo central—del contenido mostrado al
usuario.

13/12/2015
Página 39
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 13. Convenciones del Desarrollo

Esta forma de trabajo permite identificar y definir fragmentos que pueden ser ensamblados
dinámicamente en tiempo de ejecución para crear las páginas HTML. El uso de fragmentos
permite reducir la duplicación de elementos comunes a todas las páginas y trabajar con
plantillas que pueden reutilizarse.

Más concretamente, las páginas de la aplicación incluirán los siguientes elementos: una
cabecera de común, un pie, un menú de opciones y un cuerpo.

Las plantillas serán creadas con la librería Tiles y serán integradas en la capa de presentación
con Struts. La construcción de páginas a partir de plantillas se basa en la construcción de tres
elementos:

 La plantilla que define elementos estáticos y áreas donde insertar otros contenidos
 La página real que utiliza la plantilla insertando dinámicamente textos y otros elementos
 Las porciones reutilizables, que pueden ser otras páginas JSP

13.6. Convenciones para los Objetos de la Base de Datos


A continuación se mencionan las principales convenciones que se adoptan en la creación de
los objetos de la base de datos y que se basan en la documentación aportada por el MECD.

En general, todos los nombres constarán de una sola palabra, pero se admite el símbolo “_”
para unir las palabras en nombres compuestos. Todos los nombres se escribirán en castellano
o serán castellanizados y utilizarán caracteres alfabéticos o dígitos (0-9). No se utilizarán
vocales acentuadas ni caracteres propios de un idioma (como ‘ñ’, apóstrofes...) ni artículos,
conjunciones, ni partículas de unión.

Para las tablas y vistas deben utilizarse nombres en singular. En el caso de tablas o vistas que
procedan de una relación M:N entre dos tablas padre, el nombre será compuesto de la
denominación de las tablas padre, intentando dar preferencia a la entidad padre más relevante
o con más peso en la relación. En el caso de una vista que proceda de una tabla-base, se
nombrará a partir de la tabla de origen, precedida del prefijo “V_”. Se utilizarán numerales en
caso necesario. Por ejemplo: “V_Persona1”, “V_Persona2”.

Si una vista se ha creado para su uso específico desde un esquema concreto, se colocará
como sufijo el identificador de dicho esquema. Ejemplo: si se crea una vista a una tabla
'Persona' para su uso desde un esquema llamado CTLXXADM, se nombraría como
“V_PERSONA_CTL”

En el caso de entidades auxiliares que se encuentren en otro esquema (como tablas de


propósito general), se procede de la siguiente manera:
 Si se utilizan la mayor parte de los atributos y tuplas de la entidad auxiliar, se referenciará
ésta mediante un sinónimo, el cual mantendrá el nombre de la entidad original (aunque se
encuentre en plural)
 Si se utiliza un subconjunto reducido de los atributos y tuplas de la entidad auxiliar, se
accederá a ella mediante una vista. En ese caso, el nombre seguirá los mismos convenios
que para tablas.

13/12/2015
Página 40
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 13. Convenciones del Desarrollo

Los nombres de las secuencias comienzan siempre por “S_”. Si las utiliza una sola tabla,
llevarán a continuación el nombre de ésta. Si las utilizan varios objetos o tablas, tendrán un
nombre compuesto “_”.

Los nombres de los procedimientos almacenados comienzan por P_. La siguiente palabra debe
ser un verbo infinitivo indicativo de su propósito principal (Ejemplo: “P_ACTUALIZAR...”,
“P_CALCULAR...”). Los nombres de las funciones comienzan por “F_”. Como antes, la siguiente
palabra será un verbo infinitivo indicativo de su propósito principal.
Los paquetes tienen un formato libre, pero sus procedimientos y funciones componentes
respetarán las normas anteriores.

Las claves primarias deben nombrarse como la tabla y añadiendo el sufijo “_PK”. Los índices
únicos también se nombran como la tabla y añadiendo el sufijo “_U99”, donde ‘99’ son dos
posiciones para numeral correlativo. Los índices no únicos se nombran como la tabla y
añadiendo el sufijo “_I99”, donde ‘99’ son dos posiciones para numeral correlativo.

Las claves ajenas se nombran como la tabla en la que se define la restricción de clave ajena y
se añade el sufijo “_R99”, donde ‘99’ son dos posiciones para numeral correlativo.

13/12/2015
Página 41
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 14. Arquitectura Física y Despliegue

14. Arquitectura Física y Despliegue


14.1. Topología de la Plataforma

El siguiente diagrama muestra la configuración de los diferentes entornos del MECD


para el despliegue de las aplicaciones.

Topología de los entornos

Según la documentación aportada por el MECD que describe la plataforma tecnológica de su


CPD, hay que destacar los entornos de ejecución sobre los se basa el desarrollo e
implementación del sistema demandado:

 Sistema operativo: Red Hat Linux 6.0, bajo Hypervisor VMware 4.x
 Servidor de aplicaciones para los despliegues de las aplicaciones y servicios: Tomcat 7.x
 Servicios de identidades bajo LDAP tecnología Microsoft o SSO desarrollo ad-hoc MECD
 Base de datos Oracle 11g
 Gestor Documental: Documentum
 Gestión de datos con Visual Analytics
 Suite soluciones comunes: red SARA, @Firma y demás servicios incluidos en el Catálogo
de Servicios Comunes de la DTIC

13/12/2015
Página 42
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 14. Arquitectura Física y Despliegue

14.2. Despliegue en los entornos de Pre-Producción y Producción


Como parte del ciclo de vida de los desarrollos, éstos deben recorrer diferentes entornos
enfocados a la consecución de diferentes objetivos. Por ello una vez terminada la fase de
desarrollo es necesario realizar diferentes tareas, como pruebas de rendimiento o aceptación.
Para ello el MECD cuenta con un entorno específico de Pre-Producción (también denominado
entorno de Calidad), como se mencionaba en el apartado anterior.

Dada la importancia del paso de una aplicación a los entornos Pre-Producción y Producción, el
MECD cuenta con un procedimiento específico para el manejo de este cambio. Los
despliegues en dichos entornos serán realizados exclusivamente por personas del MECD. El
equipo de desarrollo podrá realizar validaciones de los despliegues y consultas de los ficheros
de log con las trazas de ejecución.

13/12/2015
Página 43
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 15. Entorno de Desarrollo

15. Entorno de Desarrollo


15.1. Herramientas
El entorno de desarrollo tiene dos caras: por un lado, están los ordenadores individuales con
las herramientas utilizadas por los desarrolladores y por otro están las herramientas
compartidas a través de la intranet.

Entorno local
de desarrollo
Proyectos con el código
fuente de las Proyecto1
aplicaciones Proyecto Servidor para desplegar
aplicaciones
Tomcat 7.x

IDE de desarrollo
Eclipse 4.4
(Luna)
JDK 1.7
Gestión de librerías
(dependencias) Maven 3.x
Depósito local de
librerías

Consultas a la base de
datos SQLDeveloper Repositorio
de Maven

Herramientas del entorno de desarrollo (puesto local)

Cada puesto de desarrollo cuenta con una instalación completa de las siguientes herramientas:
JDK, Eclipse, Tomcat, Maven, SQLDeveloper y Notedpad++. La instalación de Eclipse incluye
varios plug-ins que permiten acceder a SVN, extraer métricas calidad del código fuente e
integrar el proyecto con Maven.

El entorno de desarrollo también incluye herramientas compartidas por la intranet por todo el
equipo: el repositorio de código fuente (SVN), bases de datos y un servidor de integración
continua (IC). Nótese que en el diagrama, el icono de la base de datos representa el esquema
con las tablas de las aplicaciones propias del proyecto y también las tablas maestras comunes
a otras aplicaciones (códigos de países, códigos de CCAA, etc.).

13/12/2015
Página 44
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 15. Entorno de Desarrollo

Entorno compartido
de desarrollo

Servidor de
Integración
Continua (IC)

Repositorio SVN
Bases
Bases
de Datos
de Datos

Herramientas del entorno de desarrollo compartidas (intranet)

A continuación se describen brevemente las principales herramientas mencionadas en el


apartado anterior:

Maven es una herramienta open-source que simplifica los procesos de construcción y gestión
de los ficheros de instalación de las aplicaciones y servicios (.war), a partir del código fuente.
Entre las principales características de Maven, destacan las siguientes:
 Estandarización de la estructura interna de los proyecto (carpetas de código fuente,
ubicación de ficheros)
 Simplificación de la gestión de las librerías comunes (esto se denomina “gestión de
dependencias”). Las librerías se descargan desde repositorios públicos accesibles por
Internet.
 Automatización de tareas rutinarias, como la compilación y generación de ficheros de
despliegue (.war)
 Cada proyecto tiene un fichero pom.xml con la configuración utilizada por Maven
 Se invoca por línea de comandos o desde el menú de Eclipse

Subversion (SVN) es una herramienta de control de versiones del código fuente que se basa
en el uso de un repositorio central—accesible por la intranet—cuyo funcionamiento se asemeja
enormemente al de un sistema de ficheros. Con SVN, los cambios producidos en el repositorio
se denominan revisiones.
En nuestros proyectos, accederemos al repositorio central desde un plug-in de Eclipse. Desde
allí los desarrolladores harán todas las operaciones de check-in, check-out y etiquetado del
código fuente.

13/12/2015
Página 45
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 15. Entorno de Desarrollo

15.2. Versiones de las Herramientas


Herramienta Versión Descripción

Es la máquina virtual de Java y el


Java Development Kit (JDK) 1.7 compilador. Distribución libre y
gratuita

Es el IDE de desarrollo.
Eclipse Luna
Distribución libre y gratuita

Son extensiones de Eclipse (plug-


Plug-ins de Eclipse: SVN, ins) que se usan para conectarse
Maven, PMD, Findbugs, Compatible con Eclipse a SVN, Maven y sacar métricas de
CheckStyle calidad del código fuente.
Distribución libre y gratuita

Es el servidor de despliegue de las


Apache Tomcat 7 aplicaciones. Distribución libre y
gratuita

Herramienta para consultar una


SQLDeveloper 4 base de datos Oracle. Distribución
libre y gratuita

Automatiza la gestión de las


librerías utilizadas por las
Apache Maven 3.x
aplicaciones (dependencias).
Distribución libre y gratuita

Editor de textos (XML, HTML,


Notepad++ 6.x ficheros de configuración, etc.).
Distribución libre y gratuita

Navegador de internet.
Firefox 40
Distribución libre y gratuita

Navegador de internet.
Internet Explorer 9
Distribución libre y gratuita

Editor de textos para la


Microsoft Word 2010
documentación

15.3. Ciclo de Desarrollo con SVN y Maven


El siguiente diagrama resume el ciclo de desarrollo de las aplicaciones y servicios utilizando las
herramientas mencionadas previamente:
 Cada desarrollador trabaja desde su ordenador y accede al repositorio central de
Subversion (SVN) para hacer check-in y check-out del código fuente
 Las librerías utilizadas por los proyectos son gestionadas automáticamente por Maven, que
se encarga de descargarlas bajo demanda desde los repositorios públicos

13/12/2015
Página 46
S.I. para la programación, gestión, seguimiento y control
de las ayudas del FSE
Diseño de Arquitectura Tecnológica

Capítulo 15. Entorno de Desarrollo

Local Intranet
Check-in (commit)

Proyecto
Check-out descargar
pom.xml Repositorio SVN

librerías (dependencias) descargar


Repositorios
publicos
Repositorio
Repositorio local (caché) privado

Ciclo de desarrollo en el entorno compartido

13/12/2015
Página 47