doc20110311115751consolidacion de herramientas para el servicio de urbanismo en red

5/11/2018 DOC20110311115751Consolidacion de Herramientas Para El Servicio de Urbanismo en Red - slidepdf.com

http://slidepdf.com/reader/full/doc20110311115751consolidacion-de-herramientas-para-el-servicio-de-urbanismo-en-red 1/178

Diseño del Sistema (DSI) Versión: 9.0 | Diciembre 2009 | Página 1“Consolidación de Herramientas Para el Servicio de Urbanismo en Red”. Exp 20/09-SP .

.

DISEÑO DEL SISTEMA“Consolidación de Herramientas Para el Servicio de Urbanismo en Red”.

Exp 20/09-SP

“El objetivo de este proceso es la obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base

para el posterior diseño del sistema.”

Métrica Versión 3




.

CONTROL DOCUMENTAL

Proyecto: CONSOLIDACIÓN DE HERRAMIENTAS PARA EL PROGRAMA DEURBANISMO EN RED

Titulo: Diseño del Sistema de Información

Versión: 9

Fecha edición: 11/03/2010

Fichero: URBR-CON_2009_11_DSI_v009.doc

Autor(es): Javier Molina Herrero, Jorge Bodas Lobato, Francisco Guerrero Aranda

Resumen: Diseño del Sistema de Información

CONTROL DE CAMBIO DE VERSIÓN

Versión Fecha Módulos Descripción del cambio

1.0 10/08/2009 N/A Documento original

2.0 03/08/2009 N/A Cambios sugeridos por el equipo de verificación



5.0 23/09/2009 N/A Cambios Sugeridos por Red.es


7.0 05/10/2009 N/A Cambios sugeridos tras la conversación telefónicaentre Red.es, el equipo de desarrollo y el deverificación.

8.0 13/10/2009 N/A Cambios sugeridos tras reunión en Red.es conmodificaciones propuestas en el documento DC-260-79435C10428.pdf

9.0 03/12/2009 N/A Incorporación de casos de uso de validación,refundido y servicios web, que estaban pendientes .




.

INDICE

1. INTRODUCCIÓN ................................................................................................................................................................ 6

1.1 Objetivo del Proyecto ............................................................................................................................................... 6

2. DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA. ................................................................................................... 7

2.1 Arquitectura Física del Sistema. .............................................................................................................................. 7

2.2 Descripción de las capas Física y Lógica de los Nodos .......................................................................................... 8

3. REQUISITOS DE DISEÑO Y CONSTRUCCIÓN. ............................................................................................................ 10

3.1 Plataforma GIS. ...................................................................................................................................................... 15

3.2 Plataforma Hardware. ............................................................................................................................................ 17

4. ESTÁNDARES Y NORMAS DE DISEÑO Y CONSTRUCCIÓN. ..................................................................................... 19

5. SUBSISTEMAS DE DISEÑO. .......................................................................................................................................... 20

5.1 Subsistemas Comunes o que cubren Servicios Comunes. ................................................................................... 20

5.2 Subsistemas específicos. ....................................................................................................................................... 21

6. ESPECIFICACIÓN DEL ENTORNO TECNOLÓGICO. ................................................................................................... 25

7. ESPECIFICACIÓN DE REQUISITOS DE OPERACIÓN Y SEGURIDAD. ............................................................ 33

7.1 Procedimientos de seguridad y control de acceso. ................................................................................................ 33 7.1.0 Mantenimiento de la integridad y confidencialidad de los datos. .......................................................... 33

7.2 Control y Registro de accesos al sistema. ............................................................................................................. 33

7.3 Copias de Seguridad y Recuperación de datos. .................................................................................................... 35

7.4 Procedimientos de Operación y Administración del Sistema. ................................................................................ 35

8. DISEÑO DE LA ARQUITECTURA DE SOPORTE. ......................................................................................................... 36

8.1 Diseño de Subsistemas de Soporte. ...................................................................................................................... 36

8.2 Identificación de Mecanismos Genéricos de Diseño ............................................................................................. 37

9. DISEÑO DE CASOS DE USO REALES. ......................................................................................................................... 39

9.1 Identificación de Clases asociadas a un Caso de Uso. ......................................................................................... 39

9.1.0 Consola. ................................................................................................................................................ 40

9.1.1 Validador. .............................................................................................................................................. 54

9.1.2 Consolidador. ........................................................................................................................................ 68

9.1.3 Motor de Refundido. .............................................................................................................................. 73

9.1.4 Servicios Web. ...................................................................................................................................... 79

9.1.5 Gestión de Diccionarios. ....................................................................................................................... 89




.

9.1.6 Gestión del Plan Base. .......................................................................................................................... 92

9.2 DISEÑO DE CLASES. ........................................................................................................................................... 95

9.2.0 Consola. ................................................................................................................................................ 95

9.2.1 Validador. ............................................................................................................................................ 104

9.2.2 Consolidador. ...................................................................................................................................... 114

9.2.3 Motor de Refundido. ............................................................................................................................ 118

9.2.4 Visualizador del RPM. ......................................................................................................................... 122

9.2.5 Servicios Web. .................................................................................................................................... 126

9.2.6 Visor Web. ........................................................................................................................................... 139

9.2.7 Gestión de Diccionario. ....................................................................................................................... 144 9.2.8 Gestión del Plan Base. ........................................................................................................................ 145

9.3 Revisión del Interfaz de Usuario. ......................................................................................................................... 147

10. DISEÑO DE LA ARQUITECTURA DE MÓDULOS DEL SISTEMA .............................................................................. 154

10.1 Diseño de Módulos Visor Web ............................................................................................................................. 154

10.2 Diseño de Comunicaciones entre Módulos .......................................................................................................... 155

10.3 Revisión de la interfaz de Usuario ....................................................................................................................... 155

11. DISEÑO FISÍCO DE DATOS. ......................................................................................................................................... 160

11.1 Diseño del Modelo Físico de Datos. .................................................................................................................... 160

11.2 Optimización del Modelo Físico de Datos. ........................................................................................................... 161

11.3 Especificación de la Distribución deDatos. ......................................................................................................... 162

12. GENERACIÓN DE ESPECIFICACIONES DE CONSTRUCCIÓN. ................................................................................ 162

12.1 Especificación del Entorno de Construcción. ....................................................................................................... 162

13. DISEÑO DE LA MIGRACIÓN Y CARGA INICIAL DE DATOS ..................................................................................... 165

14. ESTABLECIMIENTO DE REQUISITOS DE IMPLANTACIÓN. ........................................................................... 165

14.1 Especificación de Requisitos de Implantación. .................................................................................................... 165

15. Especificación de Excepciones. .................................................................................................................................. 167

15.1 Especificación de Excepciones. ........................................................................................................................... 167




.

PAGINA EN BLANCO




.

1. INTRODUCCIÓN

El objetivo de este proceso es la obtención de una especificación detallada del sistema de información que satisfaga las necesidades de información de los usuarios y sirva de base para el posterior diseño del sistema.

(Metodología METRICA Versión 3)

1 .1 Objetivo del Proyecto

El Urbanismo es un dominio distribuido de información territorial en el que los planificadores,

las administraciones públicas y los ciudadanos intervienen sobre el territorio mediante planesurbanísticos siguiendo una técnica urbanística y un procedimiento administrativo y de control muydepurados tras décadas de mejora y especificación. Actualmente funciona sobre documentación depapel y en el futuro su tratamiento como información territorial exige la utilización de herramientasde información geográfica y la formación de un sistema de información.

Se pretende por tanto crear un sistema de información en el que los planes pasan a ser informacióndigital en todo su ciclo de vida y en todo su contenido, y que tiene la pretensión de eliminar a medioplazo la fase de papel de los planes trasladando a un sistema integral toda su información.

La Entidad Pública Empresarial Red.es, adscrita al Ministerio de Industria, Turismo y Comercio a

través de la Secretaría de Estado de Telecomunicaciones y para la Sociedad de la Información,tiene como misión contribuir al fomento y desarrollo de las telecomunicaciones y la sociedad de lainformación en nuestro país.

En el ejercicio de la función genérica, que la Ley le atribuye, de fomento y desarrollo de la Sociedadde la Información, Red.es gestiona, en coordinación con otros organismos públicos estatales,autonómicos y locales, diversos programas de difusión y extensión de las telecomunicaciones y lasociedad de la información. Estos programas, que cuentan con financiación procedente de fondosFEDER de los Programas Operativos FEDER, pretenden dar un fuerte impulso a la disponibilidad yutilización de las telecomunicaciones y las tecnologías de la información, poniendo en marchaservicios y desplegando infraestructuras de redes y acceso a Internet de banda ancha en losámbitos de mayor necesidad y cercanía al ciudadano (escuelas, bibliotecas, entornos rurales, etc.),

así como creando contenidos digitales e implementando servicios que faciliten el acceso a losciudadanos a la Sociedad de la Información.

En el marco de las citadas actuaciones, Red.es puso el marcha un proyecto con el objetivo deejecutar los proyectos pilotos del “Programa de Impulso del Urbanismo en Red” (en adelante, “elPrograma”), que tiene por objeto que los ciudadanos puedan acceder a través de Internet a losplanes urbanísticos de sus municipios al efecto de aumentar y potenciar la transparencia en lagestión pública del sector urbanístico.

Es objeto del programa Urbanismo en Red, la transformación del sistema de publicación delPlaneamiento en un sistema digital que permitirá el acceso universal a los planes a través de




.

Internet. Aportando un Registro de Planeamiento que albergue todos los planes vigentes en su

ámbito, que contemple las operaciones interplanes y que utilice sistemas de refundido automatizadoen los que obtener el plan refundido es una cuestión de minutos.

Además, el sistema debe disponer de funcionalidad que permita la publicación a través de internetde la información del refundido automático y opcionalmente de planes en tramitación a través deservicios web, servicios de mapas y un visor web que consuma todos los servicios disponibles.

La complejidad inherente al lanzamiento de un Programa de estas características (necesidad deestandarización, volúmenes de información que se manejan en los planes urbanísticos, etc.),determinó la necesidad de acometer el mismo en dos fases diferenciadas:

- Una fase previa de definición, normalización y realización de proyectos pilotos.

- Una fase posterior de despliegue masivo (futura).

Como resultado de los trabajos se crearon una serie de soluciones software para la construcción deun Registro de Planeamiento Municipal (en adelante “RPM”) que permitieron contener y mantener elplaneamiento vigente para su publicación en Internet (en adelante, los “Servicios de desarrollo”). Seconcretaba en la aplicación de Validación de Ficheros FIP, la aplicación de Consolidación de planesen el Registro, el Motor de Refundido de planes y los Servicios Web de publicación de planeamientorefundido. Además se desarrollaron una serie de visores web siempre englobados en estas fases“piloto”.

El objeto del actual proyecto es la consolidación de dichos desarrollos para la construcción de unaúnica plataforma que mejore y amplíe la funcionalidad desarrollada en los proyectos piloto.

2. DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA.

2 .1 Arquitectura Física del Sistema.

La arquitectura física del sistema está basada en dos nodos, tal y como muestra el siguienteesquema:




.

• Cliente: El nodo Cliente será un equipo informático, el cual mediante un navegador web,

accederá al nodo servidor.

• Servidor: El nodo Servidor contendrá a nivel lógico el servidor web, servidor de aplicaciones,servidor de mapas, motor espacial y sistema de gestión de base de datos. Este gestionarálas solicitudes del nodo Cliente.

2 .2 Descripción de las capas Física y Lógica de los Nodos

Para la descripción física y lógica de cada uno de los nodos, nos centraremos en el nodo Servidor,ya que será en este nodo donde residirá en su totalidad el Sistema de Información.

Dentro de las capa físicas, se repartirán las capas lógicas de la siguiente manera:

Dentro de servidor Web, residirá los interfaces de usuario ConsolaRPM y Visor Web.

En el Sistema de Gestión de Base de Datos será donde está ubicada la Base de Datos dePlaneamiento. Así mismo, aquí será donde se cree la Base de Datos de Validación.

El Servidor de Aplicaciones será el encargado de alojar la capa de Gestor de Servicios y ProcesadorFIP y Gestor de Persistencia.




.

La siguiente figura, nos muestra de forma ilustrativa las distintas capas lógicas que componen

nuestro Sistema:

La capa de Interfaz Gráfica, será la encargada de la interactuación del usuario con el Sistema; En estacapa se localiza:

- El Visor Web.

-La Consola RPM.

Las capas de Gestor de Servicios, establecerá la lógica de negocio; Será en esta capa dondeactúen los subsistemas de:

- Validación.

- Consolidación.

- Refundido.

- Servicios Web.

La capa de Procesador de FIP, que será la encargada de cargar Información referente a losTrámites, junto al Gestor de Persistencia, que será la capa donde se almacenará y gestionará lainformación, constituyen la capa de datos del Sistema.




.

3. REQUISITOS DE DISEÑO Y CONSTRUCCIÓN.

Alta Disponibilidad

IDENTIFICACIÓN URBR_41

DESCRIPCIÓN Permite detectar la interrupción de un servicio y proporciona mecanismos de recuperación encaso de que se produzca un fallo en el sistema o un defecto en el proceso. Además, la altadisponibilidad permite a un sistema de copia de seguridad controlar los servicios en caso deque se haya producido un fallo en el sistema principal.

COMENTARIO El uso de Servidores Jboss, nos ofrece un clustering, que nos permite desarrollar una latadisponibilidad.

Arquitectura orientada a Servicios


DESCRIPCIÓN Arquitectura Orientada a Servicios (SOA)

COMENTARIO El sistema debe desarrollarse siguiendo una Arquitectura Orientada a Servicios (SOA) lo quefavorece que el sistema sea altamente escalable y a su vez brinda una forma estándar deexposición e invocación de servicios, lo cual facilita la interacción entre diferentes sistemaspropios o incluso con sistemas de terceros.

Plataforma Opensource


DESCRIPCIÓN Plataforma del sistema

COMENTARIO El sistema se construirá obligatoriamente sobre una plataforma OpenSOURCE.En este sentido la Consola debe apoyarse en los siguientes productos Software:OPENSOURCE/OPENGIS

• Servidor de Aplicaciones: JBoss y/o glassfish

• SGBDR: PostgreSQL

• Motor Espacial: POSTGIS

• Servicios SIG: GeoServer

• Lenguaje de programación: debe ser libre, ampliamente distribuido y multiplataforma(se utilizará J2EE)

• LocalgisDeberá ser integrable con LocalGIS, herramienta surgida a partir de la evolución de GeoPISTAdestinada a fomentar la introducción de la Administración Electrónica (o e-Administración) en lasentidades locales; ayudando a realizar una gestión más eficaz sobre la información municipal. Sebasa tanto en la georreferenciación de dicha información como en la automatización de losprocesos implicados en la gestión de la Administración Local.




.

Autoactualización


DESCRIPCIÓN Actualizaciones automáticas de la plataforma a través de Internet

COMENTARIO Se deberá permitir la autoactualización a través de la conexión remota. De este modo, cualquiererror detectado y solventado en la fase de explotación será rápidamente desplegado en lasdistintas Entidades Locales de un modo automático.

Multiplataforma


DESCRIPCIÓN Posibilidad de funcionamiento en múltiples plataformas (Windows o Linux)

COMENTARIO Se prevé el despliegue sobre una plataforma servidora basada en Linux (Ubuntu Server).

Solución Web


DESCRIPCIÓN La parte cliente debe ser exclusivamente Web

COMENTARIO En la parte del cliente, los desarrollos deberán ser diseñados para funcionar sobre exploradorde internet y deberán soportarán los navegadores más extendidos en el mercado (InternetExplorer y Mozilla Firefox)

Directiva INSPIRE


DESCRIPCIÓN Se cumplirá la directiva INSPIRE

COMENTARIO La Directiva Inspire aprobada por la Comunidad Europea crea un marco que trasciende laapertura de una gran biblioteca cartográfica en formato digital y actualizable para inaugurar unainfraestructura de datos espacial, integrada y homogénea que pone al alcance de todos lacartografía del territorio europeo. Esto permite combinar información y conocimientos del territorioprocedentes de diferentes sectores y elaborados por distintas autoridades.

http://inspire.jrc.ec.europa.eu/proposal/ES.pdf http://www.idee.es/resources/leyes/DIRECTIVA_2007_2_CE_ES.pdf

http://inspire.jrc.ec.europa.eu/index.cfm/pageid/47

http://inspire.jrc.ec.europa.eu/proposal/ES.pdf

http://www.idee.es/resources/leyes/DIRECTIVA_2007_2_CE_ES.pdf



http://www.idee.es/resources/leyes/DIRECTIVA_2007_2_CE_ES.pdf

http://inspire.jrc.ec.europa.eu/proposal/ES.pdf




.

Alto grado de interactividad


DESCRIPCIÓN El sistema deberá ofrecer una respuesta a las instrucciones del usuario con la suficienterapidez como para que éste pueda trabajar de forma continuada.

COMENTARIO deberá ofrecer un tiempo máximo de respuesta máximo de:

• Carga de un mapa con 3 capas: < 5 segundos para una imagen de 470Kb 800X6008bits.

• Peticiones atendidas por unidad de tiempo: > 20 / segundo

Seguridad


DESCRIPCIÓN SEGURIDAD en el acceso a la información y su manipulación, en la integridad de los datos yla capacidad de su recuperación en caso de fallo.

COMENTARIO La autenticación de los clientes del sistema podrá ser de dos tipos:

• Mediante certificados X509, validados con acceso a una Autoridad certificadora(FNMT, DNI electrónico, etc.)

• Mediante usuario/clave, configurable.

Ergonomía y calidad


DESCRIPCIÓN

Cumplimiento de estándares españoles y europeos en materia de ergonomía y calidad y seguridadgarantizando el cumplimiento de la Ley Orgánica de protección de Datos de Carácter Personal(LOPD) y su reglamento de desarrollo

COMENTARIO La nueva ley, que ha nacido con una amplia vocación de generalidad, prevé en su artículo 1 que «tienepor objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, laslibertades públicas y los derechos fundamentales de las personas físicas, y especialmente de su honor eintimidad personal». Comprende por tanto el tratamiento automatizado y el no automatizado de los datosde carácter personal.

https://www.agpd.es/portalweb/canaldocumentacion/legislacion/estatal/common/pdfs/RD_1720_2007.pdf http://www.boe.es/aeboe/consultas/bases_datos/doc.php?coleccion=iberlex&id=2008/00979

https://www.agpd.es/portalweb/canaldocumentacion/legislacion/estatal/common/pdfs/RD_1720_2007.pdf

http://www.boe.es/aeboe/consultas/bases_datos/doc.php?coleccion=iberlex&id=2008/00979

http://www.boe.es/aeboe/consultas/bases_datos/doc.php?coleccion=iberlex&id=2008/00979

https://www.agpd.es/portalweb/canaldocumentacion/legislacion/estatal/common/pdfs/RD_1720_2007.pdf




.

Estructura modular


DESCRIPCIÓN Catálogo de módulos del sistema

COMENTARIO El sistema tendrá al menos los siguientes módulos bien diferenciados:

• Consola de Gestióno Servicios WEBo Motor de Refundidoo Consolidadoro Validadoro Gestión del Plan Baseo Gestión de Diccionarios

• Visor Web.

Parametrización, flexibilidad y mantenibilidad


DESCRIPCIÓN Alto grado de parametrización, flexibilidad y mantenibilidad

COMENTARIO El sistema debe permitir la modificación de su comportamiento funcional del mismo medianteparámetros de configuración. El cumplimiento de este requisito permitirá el más alto gradoposible de modificación funcional del mismo sin necesidad de realizar modificaciones de código,recompilaciones y/o reinstalaciones.Además, el sistema deberá poseer un mecanismo sencillo para la incorporación de nuevasfuncionalidades que puedan complementar al sistema en el futuro.También se deben intercalar en el código fuente cuantas líneas de comentario se consideren

necesarias para la comprensión de los algoritmos utilizados. Con esto se conseguirá minimizar elesfuerzo requerido en la localización y corrección de posibles errores.

Eficiencia


DESCRIPCIÓN En el diseño de los diferentes procedimientos y cuando se establezcan comunicaciones seha de procurar un tratamiento de los datos que minimice las transmisiones a través de laslíneas para optimizar la utilización de los recursos.

COMENTARIO

Entorno amigable


DESCRIPCIÓN El sistema debe proporcionar un entorno amigable para un usuario sin formación técnica,mediante la utilización de menús, ventanas, normalización de objetos, accesos rápidos a laopción deseada y ayudas en línea

COMENTARIO




.

Incorporación de nuevas funcionalidades


DESCRIPCIÓN El sistema deberá poseer un mecanismo sencillo para la incorporación de nuevasfuncionalidades que puedan complementar al sistema en el futuro.

COMENTARIO No debe ser un sistema cerrado, sino abierto en todo lo posible para permitir la implementacióntanto de nuevas funcionalidades como de modificaciones de las existentes.

Servicios Web (GIS).

IDENTIFICACIÓN URBR_25.1_3

DESCRIPCIÓN Servicios de consulta de datos gráficos a través de internet

COMENTARIO La capa de Servicios GIS WEB tendrá que cumplir con las directrices de OGC para laconstrucción de servicios interoperables. Para lograrlo se utilizarán los estándares WMS y WFSpara publicación de mapas.

Dos Arquitecturas


DESCRIPCIÓN La instalación del Sistema se puede realizar mediante dos instalaciones distintas, con 1 ó 2niveles.

COMENTARIO En el caso de instalar todo el sistema bajo el mismo nivel, todos sus componentes estarán bajo

dicho nivel.En el caso de instalación en dos niveles, se separará de la siguiente manera:

• Capa Web: Servicios Web, Visor Web y Consola RPM.

• Capa Gestor de Servicios y Gestor de Datos.




.

3 .1 Plataforma GIS.

En toda infraestructura GIS basada en tres capas se pueden encontrar, al menos, los siguientescomponentes:

- Sistema de Gestión de Base de datos

- Motor Espacial

- Servidor de aplicaciones

- Servidor Web

- Servidor de Mapas

- Aplicación de consultaQue permiten al sistema “crecer” sin dificultades de incompatibilidades.

Gráficamente, los esquemas de conexión entre ellos se puede observar en la siguiente figura:

Las pruebas se han de realizar en un entorno de una capa, (caso peor), en la cual conviven todoslos servicios. Según el número de accesos y las necesidades se puede utilizar otro tipo arquitecturadiferente.

Con el fin de conseguir una solución efectiva y práctica para la producción basada en soluciónOpensource, se seleccionan los siguientes componentes:




.

* El servidor Apache se ha incluido para hacer posible la publicación indirecta de las aplicaciones,incrementado la seguridad del servidor de aplicaciones, haciendo las veces de proxy inverso.

En la parte servidora:

Componentes Aplicaciones

Sistema Operativo Ubuntu 8.0.4 LTS / WindowsSistema de Base de datos PostgreSQL 8.3 o superior

Motor Espacial PostGIS 1.3.5

Servidor de Mapas Geoserver 1.7.2

JVM/JDK/JRE Java 5 (JDK 1.5.x)

Servidor web Apache 2.2

Servidor de Aplicaciones Jboss 5.1

Variable del sistema REDES_PATH Contendrá la ruta al servidor Jboss

Variable del sistema JAVA_HOME Contendrá la ruta relativa a al JDK.

En la parte cliente:

• El cliente del Sistema no necesita ningún tipo de instalación,simplemente basta con un ordenador (con cualquier sistemaoperativo) que disponga de un navegador web estándar (InternetExplorer, Mozilla Firefox o Google Chrome en sus últimasversiones).




.

Navegador Versión

Internet Explorer 7 ó superior

Mozilla Firefox 2 ó superior

Google Chrome 3 ó superior

3 .2 Plataforma Hardware.

Dichos componentes deben desplegarse sobre una plataforma en alta disponibilidad (dos servidorespor nivel) cuyo dimensionamiento se establecen a continuación según el tipo de entorno.

En cuanto a las características del nodo servidor, la configuración empleada en laboratorio haresultado efectiva para soportar un factor de concurrencia con caché pregenerada de más de 50usuarios. Como especificaciones mínimas, para entornos pequeños, y empleando cachéspregeneradas, se debería contar con un servidor Intel Dual Core a 3Ghz, la memoria RAM sedeterminaría en base a 1GB ó 2 por core según la información a mover, discos SATA y tarjetas dered a Gigabit. Para un entorno medio, se recomienda un equipo Intel Quadcore o doble Quadcore,1GB ó 2 por core de RAM, etc. Por último, para entornos más pesados sería preciso realizarpruebas de rendimiento y carga para determinar el factor de escalabilidad del hardware o emplearentornos basados en dos o tres capas.

En la siguiente tabla se podrían establecer las pautas mínimas para definir la arquitectura según eltipo de entorno:

Entorno Instalación Comunicaciones Servidores

Pequeño Básica1 Nivel

1 ó 2 Mbps simétricos • Un solo nivel:

o 1 ó 2 procesadores de 4núcleos a 2,53Ghz

o 12 GB RAM

Mediano /Grande

Avanzada2 Niveles

4 a 10 Mbps simétricos • Servidor BBDD y aplicaciones:

o 1 ó 2 procesadores de 4núcleos a 2,53Ghz

o 12 GB RAM

• Servidor Webo 1 procesador de 4 núcleos a

2,53Ghz

o 6 GB RAM

En el caso de una configuración básica, todos los componentes se instalarían bajo un único nivel enalta disponibilidad, tal y como muestra la siguiente imagen:




.

En el caso de una instalación avanzada, esta sería tal y como indica la siguiente imagen, separandocapa Web, Servidor de aplicaciones y BD.




.

En ambos casos se utiliza una estructura de 2 ó 4 servidores, aportar alta disponibilidad al sistema.

Respecto la parte Cliente no existen exigencias previas, salvo el del uso un navegador de internetde los expuestos anteriormente y del suficiente nivel de memoria libre.

4. ESTÁNDARES Y NORMAS DE DISEÑO Y CONSTRUCCIÓN.

La realización del sistema de información se realizará utilizando una Metodología de DesarrolloOrientada a Objetos. Se prestará atención especial además a mecanismos de estandarización de:

• Estándares de programación orientada a objetos

• Estándares OpenGeoSpatial (v1.7.6) ( http://www.opengeospatial.org/ ) • Diseño UML (http://www.uml.org/)

• XML (http://www.w3.org/XML/)

• SOAP – Web Services (http://www.w3.org/TR/soap/)

• Normas de ejecución INSPIRE

(http://www.idee.es/resources/presentaciones/GTIDEE_Malaga_2009/Reunion/NormasEjecucion_INSPIRE_2.pdf)

http://www.opengeospatial.org/



http://www.uml.org/)


http://www.w3.org/XML/

http://www.w3.org/TR/soap/

http://www.idee.es/resources/presentaciones/GTIDEE_Malaga_2009/Reunion/NormasEjecucion_INSPIRE_2.pdf

http://www.idee.es/resources/presentaciones/GTIDEE_Malaga_2009/Reunion/NormasEjecucion_INSPIRE_2.pdf

http://www.w3.org/TR/soap/

http://www.w3.org/XML/







.

• Metadatos según la norma ISO 19.100 (Información geográfica) y en

particular la 19.115, creada con el fin de definir una estructura que sirvapara describir los datos geográficos (Geographic Information Metadata )

(http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_ics_browse.htm?ICS1=19&ICS2=100)

• Ley Orgánica de protección de datos (LOPD) y Real Decreto 1720/2007 porel que se aprueba el reglamento de desarrollo de la LOPD

(http://www.boe.es/boe/dias/1999/12/14/pdfs/A43088-43099.pdf)

• El código se adaptará al convenido de codificación JAVA.(http://java.sun.com/docs/codeconv/CodeConventions.pdf)

5. SUBSISTEMAS DE DISEÑO.

Realizando una catalogación funcional obtenemos la siguiente calificación del sistema de información ensubsistemas de diseño.

5 .1 Subsistemas Comunes o que cubren Servicios Comunes.

Este conjunto de subsistemas, lo componen:

- Acceso a Datos.

- Autentificación.- Sistema de Log.

Acceso a Datos: Hibernate es una herramienta de Mapeo objeto-relacional para la plataforma Javaque facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo deobjetos de una aplicación, mediante archivos declarativos (XML) que permiten establecer estasrelaciones. Esta herramienta de acceso a datos se empleará en todos los subsistemas quecomponen el Sistema Global.

Autentificación: Método criptográfico de identidad de una persona o de un equipo informático. Enfunción del tipo de firma puede, además, asegurar la integridad del documento o mensaje. Mediante

este sistema, garantizamos la autentificación del usuario que se registra en el Sistema.

Sistema de Log: Para registrar todos los eventos que surgen en el Sistema durante la ejecución delos distintos Subsistemas, este dispone de un sistema de Logger. Log4j es una biblioteca opensource desarrollada en Java por la Apache Software Foundation. El servidor de aplicacionesdispondrá de distintos ficheros .log dentro de la carpeta server\default\log, con información puntualde lo sucedido, indicando la hora, la clase que ejecutó la acción, así como la información aportadapor el programador.

http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_ics_browse.htm?ICS1=19&ICS2=100

http://www.boe.es/boe/dias/1999/12/14/pdfs/A43088-43099.pdf

http://java.sun.com/docs/codeconv/CodeConventions.pdf

http://java.sun.com/docs/codeconv/CodeConventions.pdf

http://www.boe.es/boe/dias/1999/12/14/pdfs/A43088-43099.pdf

http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue_ics_browse.htm?ICS1=19&ICS2=100




.

Al tratarse de subsistemas comunes, estos afectan a todas las capas lógicas del Sistema, en el

nodo físico de Servidor de Aplicaciones, tal como muestra la siguiente imagen.

5 .2 Subsistemas específicos.

Este conjunto de subsistemas lo componen las funcionalidades propias del Sistema de información:

• Subsistema de Validación.

• Subsistema de Consolidación.

• Subsistema de Motor de Refundido.• Subsistema de Servicios Web.

• Visor Web

• Consola de Registro de Planeamiento Municipal (En adelante, Consola RPM).

• Subsistema de Validación: Es la solución software destinada a la verificación delos FIP, su función principal es revisar la coherencia y la validez, así como elcumplimiento de distintas normativas urbanísticas.

Se desplegarán sobre el servidor de aplicaciones. Habrá un servicio por validación arealizar. Todos estos servicios serán EJB 3.0´s; El proceso de Validación estará

relacionado con la Consola RPM, ya que desde esta, el usuario podrá configurar lasvalidaciones a realizar. Internamente las Validaciones se clasificarán por el tipo devalidación que va a realizar. Los tipos serán los siguientes: Entidades,Determinaciones, Condiciones Urbanísticas, Documentos, Regímenes,Operaciones, Trámites y Adscripciones.




.

Figura 2. Subsistema de Validación

• Subsistema de Consolidación: Es la solución software destinada a la lectura de los planesen formato FIP y al traslado de éstos al repositorio.

El subsistema de Consolidación será un EJB 3.0, que solamente se podrá ejecutar paraFIP´s que previamente han pasado con éxito el proceso de Validación.

Figura 3. Subsistema de Consolidación.

• Subsistema de Refundido: Es la solución software destinada a construir un fichero FIPcon el resultado de un plan refundido a partir de los planes vigentes en el repositorio deplaneamiento.

El proceso del Motor de Refundido, será a priori un solo Servicio aunque estará compuestoen prácticamente su totalidad por subservicios que únicamente utilizará el Motor deRefundido.




.

Figura 4. Subsistema de Refundido.

• Subsistema de servicios Web: Es la solución software destinada a proporcionar el accesoa la información de planeamiento, sin la necesidad de conocer en profundidad lascomplejidades del modelo de datos.

Serán igualmente EJB 3.0´s, que irán invocando a servicios externos para la obtención deinformación para el Visores Web.

• Subsistema de visor Web: Se trata de una aplicación web que sirve de punto deinformación urbanística a todos los ciudadanos a través de internet. Ofrece los datosexpuestos por los servicios web.

Será una aplicación web basada en ajax (javascript) y servlets para los procesos decomunicación con los servicios web.

Figura 5. Subsistema de Servicios Web y visor Web.

• Subsistema de Consola RPM: Este subsistema está basado en un modelo Vista-Controlador, donde un interface JSF se encargará de la parte gráfica, invocando serviciosdesplegados en el servidor de Aplicaciones así como del control de acceso y flujo denavegación por los distintos niveles del proceso de sistematización.

Figura 6. Consola de Control RPM




.

Los subsistemas de Validación, Consolidación y Motor de Refundido se encuentran en el nodológico de Servidor de Aplicaciones, tal como muestra la siguiente imagen:

Los subsistemas de Consola RPM, Servicios Web y Visor Web se encuentran en el nodo lógico deServidor Web, tal como muestra la siguiente imagen:




.

A continuación se muestra una visión general del Sistema:

6. ESPECIFICACIÓN DEL ENTORNO TECNOLÓGICO.

La arquitectura física/lógica descrita en el apartado 2.2 se implementa en la siguiente infraestructuratecnológica, dividiendo en los siguientes componentes Hardware y componentes Software:

Componentes Software:

La solución software definida en los puntos anteriores necesita un entorno tecnológicorobusto, independiente del sistema, multitarea y que se capaz de interaccionar condiferentes bases de datos. Para ajustarnos al máximo a las propiedades anteriormentedescritas haremos uso de la tecnología Java/J2EE; Las versiones mínimas Java deben ser1.5.

Para potenciar y completar las cualidades de dicha tecnología, los desarrollos harán uso deframeworks como Hibernate así como del API EJB 3.0.

EJB 3.0: proporcionan un modelo de componentes distribuido estándar del lado del servidor,permite que éstos sean flexibles y reutilizables




.

Los EJB 3.0 se disponen en un contenedor EJB 3.0 dentro del servidor de aplicaciones. La

especificación describe cómo el EJB 3.0 interactúa con su contenedor y cómo el códigocliente interactúa con la combinación del EJB 3.0 y el contenedor.

Un EJB 3.0 a través de un "EJB 3.0 Container" ofrece varios servicios y funcionalidades,algunas son las siguientes:

- Servicios: Cuando se diseña un componente de Software se deben definirvarios servicios para su funcionamiento.

- División de Trabajo: La posibilidad de dividir "Servicios"(EJB 3.0 Container)de "Componentes Principales"(EJB 3.0'S) permite una clara división detrabajo, esto es, un diseñador de "componentes"(EJB 3.0's) puedeconcentrar sus esfuerzos en la "lógica de proceso" sin preocuparse deldiseño de servicios. Y de la misma manera un "diseñador" de servicios

("Middleware") concentrarse en su área.

- Procedimientos Remotos: Debido a la solución que intentan ofrecer EJB 3.0("Enterprise Java Beans") su diseño gira alrededor de procedimientosremotos

- Diversos Clientes: Un EJB 3.0 puede interactuar con una gran gamma declientes desde: JSP o Servlets, bases de datos, Applets, sistemas ERP(SAP,JDEdward's).

Estos servicios se desplegaran bajo un servidor de aplicaciones J2EE (GlassFish, Jboss…)

El gestor de persistencia: es un componente fundamental, provee un mapeo objeto-relacional. El objetivo que persigue el diseño de esta API es no perder las ventajas de laorientación a objetos al interactuar con una cualquier base de datos y permitir usar objetosregulares; El motor de persistencia utilizado en el desarrollo de la solución software esHibernate V3. (http://www.hibernate.org/), que es una herramienta ORM para java.

JBPM: es una implementación en Java de BPM que facilita la creación de flujos deprocesos de negocio permitiendo la integración de procesos para la unión de personas yaplicaciones.

Soporta dos lenguajes de proceso:

- JPDL: Enfocado a la definición de flujos de procesos en Java. Que es elutilizado en el Sistema para la orquestación de servicios.

- BPEL: Proporciona facilidades para la orquestación de servicios,combinación de servicios web para conseguir un flujo de negocio.

Las dos características más potentes o útiles de BPM y en concreto de JBPM son suorientación gráfica y la persistencia en la BD.

JBPM enfoca su filosofía hacia GOA. Mediante un gráfico se diseña el flujo yposteriormente se le dota de la lógica necesaria mediante mapeos con clases de Java. Deeste modo se crea un nexo entre el analista o diseñador y el programador. Existenherramientas para diseñar estos flujos.




.

JBPM tiene la capacidad de persistir los flujos. En los lenguajes tradicionales no existen

situaciones de parada y espera de notificación de modo que ese thread pueda ser guardadoen la base de datos. De modo que no hay soporte para situaciones de asíncrona sin que elthread continúe corriendo.

JBPM modela flujos de negocio que básicamente son maquinas de estados, aunque losflujos son algo más que eso. De este modo cualquier cosa que sea susceptible de ser unamaquina de estados finitos puede ser modelada con un BPM: navegación web, procesos debackup, sistemas empotrados de control, autómatas totales en general. Realmente la mayorparte de sistemas informáticos pueden ser modelados así, la cuestión es si es viable oconveniente

JBPM es básicamente una librería de clases Java y viene distribuida en un JAR, de estemodo puede quedar embebida en cualquier tipo de aplicación: web, swing, en servidor, encliente, etc.

Gestor de Geometrías: Es el componente encargado de leer, organizar y operar lasgeometrías en formato WKT y las transforma a formato Geometry de JTS 1.9; Para facilitarla tarea de leer datos geométricos utilizaremos parte de la herramienta de Geotools(http://geotools.codehaus.org/).

Gestor de Firma digital: El encargado de la validación de firma digital y certificadosdigitales es ViaFirma en su versión 1.X, de distribución libre que se encuentracompletamente en googlecode.

ViaFirma es una plataforma de firma digital que venga a simplificar el desarrollo deaplicaciones que requieran usar Certificados Digitales. Cualquier aplicación puede hacer

uso de la autenticación y firma digital utilizando los servicios que el sistema ofrece,abstrayendo a las aplicaciones de los problemas relacionados con el uso de certificadosdigitales, como son la criptografía de clave pública, la validación usando CRLs o OCSP, lalectura de certificados, el uso del DNI-e, etc.

http://www.viafirma.org/

Interfaz gráfica: El desarrollo de la Consola de control RPM, se ha basado en tecnologíaJSF, (Java Server Faces). El acceso a dicha consola se efectúa desde un navegador Web,simplificando el acceso y haciendo la navegación más cómoda e intuitiva.

JavaServer Faces (JSF) es un framework para aplicaciones Java basadas en web quesimplifica el desarrollo de interfaces de usuario en aplicaciones J2EE (Java EnterpriseEdition). JSF usa JavaServer Pages (JSP) como la tecnología que permite hacer eldespliegue de las páginas.Los objetivos de diseño representan el foco de desarrollo de JSF:

- Definir un conjunto simple de clases base de Java para componentes de lainterfaz de usuario, estado de los componentes y eventos de entrada. Estasclases tratarán los aspectos del ciclo de vida de la interfaz de usuario,controlando el estado de un componente durante el ciclo de vida de supágina.

- Proporcionar un conjunto de componentes para la interfaz de usuario,incluyendo los elementos estándares de HTML para representar un




.

formulario. Estos componentes se obtendrán de un conjunto básico de

clases base que se pueden utilizar para definir componentes nuevos.

- Proporcionar un modelo de JavaBeans para enviar eventos desde loscontroles de la interfaz de usuario del lado del cliente a la aplicación delservidor.

- Definir APIs para la validación de entrada, incluyendo suporte para lavalidación en el lado del cliente.

- Especificar un modelo para la internacionalización y localización de lainterfaz de usuario.

-

Automatizar la generación de salidas apropiadas para el objetivo del cliente,teniendo en cuenta todos los datos de configuración disponibles del cliente,como versión del navegador...

Comunicaciones:

A continuación se presenta un esquema para una mejor comprensión de lascomunicaciones entre los distintos módulos del sistema:

Esquema básico de comunicaciones.

El Servidor de Mapas (GeoServer) se comunica con el SGDB (Base de Datos) para obtener lascapas que van a estar accesible para los usuarios




.

El Servidor de Aplicaciones (JBoss) se comunica con el SGDB (Base de Datos) a través de su capade JPA - Hibernate. Esta comunicación es para almacenar/consultar todos los datos relacionadoscon cualquier fase del proceso (validación, consolidación, refundido, consulta de los servicios web,etc.)

Dentro del Servidor de Aplicaciones, los servicios EJB 3.0 son aquellos servicios que tienen la lógicade negocio necesaria para realizar las distintas funcionalidades que proporcionan las distintasaplicaciones de Urbanismo en Red (todos los aplicativos). Estos servicios EJB 3.0 hacen uso de lacapa de Hibernate; además pueden hacer uso de los servicios del servidor de mapas.

Esta comunicación entre cliente y servicios EJB 3.0 se hará preferente siempre que estemos enentornos locales ya que al ser una comunicación basada en RMI su rendimiento es de 8 a 10 veces

superior a las comunicaciones entre clientes y servicios web.

La capa de servicios web del servidor de aplicaciones hará uso de todos los servicios EJB 3.0 quese ofrecen. La mayoría de las veces, esta capa de servicios web no será nada más que la fachadaweb de los servicios EJB 3.0 que son los que realmente van a poseer la lógica de negocio, aunquea veces los propios servicios web contienen parte de la lógica de negocio.

La capa de flujo de validación hará uso de los servicios EJB 3.0 y expondrá sus servicios para quedesde cualquier navegador se pueda ejecutar la aplicación de validación.

El visor web será una función javascript ejecutable desde cualquier navegador que hará uso tantode los servicios web como del servidor de mapas para explotar en el visor las distintasfuncionalidades. Este visor web está basado en openlayers (www.openlayers.com)

A continuación, se presenta un gráfico global del sistema total para una mejor percepción delmismo.




.

• 1 Nivel con dos servidores:

* El Servidor de Mapas se incluye dentro del Front-End, pero en caso de que el hardware del Front-End fuera insuficiente, sería posible incluirlo en la parte de Back-End mediante la inclusión de unproxy inverso en el Front-End




.

• 2 Niveles con 4 servidores:

• Gestor de Alta Disponibilidad

El gestor de alta disponibilidad recomendado, consistirá en 2/4 máquinas.

Dos Front Ends en configuración activo-activo, donde se ubicará:

o Balanceador de carga Solución para gestionar balance de carga en sistemas Linux. El

objetivo es desarrollar un servidor Linux de alto rendimiento que proporcione buenaescalabilidad, confiabilidad y robustez.

Ejemplo: LVS: Linux Virtual Server (http://www.linuxvirtualserver.org/ ) + KeepAlive

o Servidor web Apache utilizado para la realización del proxy inverso y aumentar el nivelde seguridad del sistema.

El Back End se estructurará en servidor de aplicaciones y de base de datos. La dotación de altadisponibilidad será realizada por componentes:

o Servidores de aplicaciones en activo-activo

Balanceador de carga

http://www.linuxvirtualserver.org/

http://www.linuxvirtualserver.org/




.

o Base de datos en activo-pasivo

PgPool II (http://pgpool.projects.postgresql.org/ ): Replica la información de una base dedatos PostgreSQL en 2 ó más servidores.

o Sistema de ficheros en activo pasivo

DRDB (http:// www.drbd.org/ ): Realiza un espejo de la información de unbloque enteroen otro servidor a través de red. Puede ser entendido como un RAID-1 (Un RAID 1 creauna copia exacta de un conjunto de datos en dos o más discos.)

http://pgpool.projects.postgresql.org/

http://www.drbd.org/

http://www.drbd.org/

http://pgpool.projects.postgresql.org/




.

7. ESPECIFICACIÓN DE REQUISITOS DE OPERACIÓN Y SEGURIDAD.

7 .1 Procedimientos de seguridad y control de acceso.

7.1.0 Mantenimiento de la integridad y confidencialidad de los datos.

El Mantenimiento de la integridad de los datos se inicia desde el proceso de Validación, donde seempiezan a cargar los datos en la correspondiente Base de Datos, comprobando la integridad ycoherencia de estos (más información sobre el proceso, consultar URBR-CON_2009_06_ASI_v004.doc); Esta integridad y coherencia se mantiene durante todos losprocesos del Sistema.

Todos los servicios que intervienen en procesos de escritura en Base de Datos, cuentan consegmentos de Rollback, que se ejecutan automáticamente si al ejecutarse se produce un error, deesta manera se garantiza la validez de la información del sistema.

El Rollback consiste en la no actualización de la base de datos si se produce un error en laejecución de los distintos servicios.

Si se produjera un error en las comunicaciones, se interrumpiese la conexión con la Base de Datoso se sufriese una caída del sistema, la Transacción del subsistema que estuviera corriendo en esemomento finalizaría y con ella se produciría un rollback en la Base de Datos, de forma que ningúncambio de los que realizó el subsistema en cuestión antes de finalizar sin éxito, afectaría alcontenido inicial de la Base de Datos.

Al usuario se le informará de la situación anómala y finalizará el proceso que estuviera en ejecuciónen dicho momento. Cuando el problema que causó la pérdida de conexión con la Base de Datos o

la inestabilidad en el sistema se solucionara, el usuario deberá ejecutar de nuevo los sistemasdesde el punto inicial antes de producirse el error.

Para evitar la replicación entre Bases de Datos, una vez validado un fichero FIP y habiéndoseprocedido a su Consolidación, cuando el Trámite se haya copiado correctamente a la Base de Datosde Planeamiento, este se eliminará de la Base de Datos de Validación.

El acceso al logs, librerías etc., está regulado mediante el acceso al sistema donde se halle alojadoel servidor de aplicaciones.

El acceso a datos está igualmente restringido mediante usuarios con distintos niveles de permisos abase de datos, así como al sistema, garantizando la confidencialidad de los datos.

7 .2 Control y Registro de accesos al sistema.

Para el acceso al sistema, el usuario deberá logarse mediante Usuario/contraseña o CertificadoDigital. Existiendo usuarios con distintos niveles de privilegios al acceso de datos (Roles).

Un rol de usuario es el conjunto de permisos que se asignan a un usuario que accede a los distintossubsistemas. De esta forma cada usuario representa un papel concreto como si de unaorganización jerárquica se tratara.

Así, existen usuarios que tienen la posibilidad de acceder a más funcionalidades de la aplicaciónque a otros usuarios ni siquiera se les ofrecen.




.

En el sistema se contemplan los siguientes roles. Cada usuario pertenecerá a uno o varios roles

para cada ámbito, lo que significa que habrá usuarios que puedan ejecutar muchas funcionalidadespara un solo ámbito (Ej.: usuario de entidad municipal) y otros podrán realizar determinadas tareassobre varios municipios (Ej.: usuario de entidad supramunicipal):

Rol administrador de la Consola RPM: Este actor representa al usuario específico deAdministración del Registro de Planeamiento Municipal. Dado que el conjunto de tareaspara la generación datos que irán incluidos en el FIP de tipo 1 son específicas de estemódulo, consideraremos a este usuario un tipo especial de Usuario Administrador.

Rol administrador de Servicios Web: Este actor representa al usuario específico deAdministración de los Servicios WEB. Los Servicios WEB sólo requerirán el mantenimiento

y control del estado de los servicios que una vez configurados no requerirán tareasadicionales.

Rol administrador de Motor de Refundido:Este actor representa al usuario específico deAdministración del Módulo de Motor de Refundido. Dado que el conjunto de tareas para laobtención de la bases de datos de planeamiento vigente (refundido) son específicas de estemódulo, consideraremos a este usuario un tipo especial de Usuario Administrador.

Rol administrador de Consolidación: Este actor representa al usuario específico deAdministración del Módulo de Consolidación. Dado que el conjunto de tareas deconsolidación de los instrumentos de planeamiento en el registro son específicas de estemódulo y tienen que ver con la carga de expedientes de Planeamiento en el registro a partir

de documentos FIP validados, consideraremos a este usuario un tipo especial de UsuarioAdministrador

Rol administrador de Validaciones: Este actor representa al usuario específico deAdministración del Módulo de Validación. Dado que el conjunto de tareas de validación sonespecíficas de este módulo y tienen que ver con la recepción y validación de información dePlaneamiento en formato FIP, consideraremos a este usuario un tipo especial de UsuarioAdministrador.

Rol administrador de Gestión de Diccionarios y Plan Base: Este actor representa alsistematizador de planeamiento. Las herramientas de producción de planeamiento están

excluidas del presente proyecto, pero se incluye al productor como Actor en calidad dereceptor de FIPs de tipo1 y generador de FIPs de tipo 2.

Rol administrador de Visor Web: Este actor representa cualquier usuario que, a través delvisor Web, accede a la información urbanística ofrecida a partir de los servicios disponibles.

• Rol Productor: Este rol se ha incluido por si en el futuro se le quiere dar al productor laposibilidad de que él mismo a través de Internet pueda subir su propio fichero deintercambio de planeamiento para que luego sea verificado por un usuario de la aplicación.




.

Este rol solo va a tener las funcionalidades de iniciar un proceso de validación, pero en su

primer estado de inicio de expediente, y buscar el estado de su proceso de validación parasaber en qué estado está.

En caso de acceder mediante usuario y contraseña, el Sistema dará al usuario 3 oportunidades delogarse, una vez consumidas estas 3 oportunidades, al usuario se le denegará el acceso.

Los accesos al sistema quedarán reflejados mediante un registro de acceso al sistema; Este registroconsistirá en una tabla de la base de datos donde quedará registrado el usuario que accedió, lahora, y las operaciones que realizó.

7 .3 Copias de Seguridad y Recuperación de datos.

El administrador del Sistema, será el encargado de decidir la periodicidad de las copias deseguridad. Se recomienda que la frecuencia de las copias de seguridad, venga dado por la actividaden el registro de planeamiento.

Las copias de seguridad deben recoger el contenido de la base de datos de planeamiento,posibilitando recuperar y restaurar el Sistema a un estado anterior, en caso de producirse un errorgrave.

Estas copias de seguridad se realizarán mediante la ejecución de Scripts, en los cuales eladministrador del Sistema, indicará el soporte en el que se almacenarán las copias. Se recomiendaque el soporte sea uno distinto al que reside el Sistema y Base de Datos.

El sistema dispondrá, además, de una herramienta para la realización de backups del sistema quepodrá ejecutar el administrador del mismo.

La restauración del Sistema en caso de desastre, la llevará a cabo el administrador del Sistema, elcual manualmente cargará los backups de la Base de Datos, todos estos procesos están descritosen el Manual de Administración. No obstante, la información necesaria para realizar unarestauración de todo el sistema será:

- Export de la base de datos completa

- Copia de seguridad de todos los ficheros de configuración

- Copia de seguridad de los documentos escaneados de planeamiento

En ningún caso será el Sistema el encargado de planificar ni ejecutar dichas tareas.

7 .4 Procedimientos de Operación y Administración del Sistema.

Los ficheros de FIP de tipo 1 serán descargados por el productor de planeamiento a través de unformulario web desarrollado a tal efecto. La petición y sus metadatos quedarán almacenados en eldiario de operaciones como parte del control al productor.

Para más información sobre Fichero FIP tipo 1, consultar el documento URBR-CON_2009_06_ASI_v004.doc




.

8. DISEÑO DE LA ARQUITECTURA DE SOPORTE.

En esta actividad se lleva a cabo la especificación de la arquitectura de soporte, que comprende eldiseño de los subsistemas de soporte identificados en la actividad de Definición de la Arquitecturadel Sistema (DSI 1), y la determinación de los mecanismos genéricos de diseño. Estos últimossirven de guía en la utilización de diferentes estilos de diseño, tanto en el ámbito global del sistemade información, como en el diseño de detalle.

8 .1 Diseño de Subsistemas de Soporte.

Teniendo en cuenta la arquitectura diseñada para el sistema, la cual se muestra en la siguienteimagen:

El subsistema de soporte sería aquel que corresponde con la capa de Servicios Básicos que estádentro de la Lógica de Negocio:

- Servicios Básicos: En esta capa Servicios Comunes de Arquitectura están los servicioscomunes de arquitectura que dan soporte a los servicios, subprocesos y flujos de negociopara la Gestión de Errores, Alertas, Trazabilidad y Transaccionabilidad y el Acceso a los




.

Datos de la Infraestructura de Datos. Los servicios comunes de Arquitectura son servicios

genéricos e independientes de las funcionalidades implementadas. Todos estoscomponentes se implementan con tecnología J2EE utilizando las APIs y utilidades. Porejemplo, se usan componentes basados en Hibernate para el acceso a bases de datosalfanuméricas.

8 .2 Identificación de Mecanismos Genéricos de Diseño

En este apartado se van a definir los patrones y guas de diseño comunes, así como los frameworksde trabajo que van a facilitar la construcción del sistema

Sistema de Persistencia HIBERNATE:

Trabajar con software orientado a objetos y bases de datos relacionales puede hacernos invertir

mucho tiempo en los entornos actuales. Hibernate es una herramienta que realiza el mapeo entre elmundo orientado a objetos de las aplicaciones y el mundo entidad-relación de las bases de datos enentornos Java. El término utilizado es ORM (object/relational mapping) y consiste en la técnica derealizar la transición de una representación de los datos de un modelo relacional a un modeloorientado a objetos y viceversa.

Hibernate no solo realiza esta transformación sino que nos proporciona capacidades para laobtención y almacenamiento de datos de la base de datos que nos reducen el tiempo de desarrollo.

Hibernate funciona asociando a cada tabla de la base de datos un Plain Old Java Object (POJO, aveces llamado Plain Ordinary Java Object).Hibernate es un poderoso, motor de ejecución depersistencia objeto relacional y servicio de consultas para Java. Hibernate permite desarrollar clasespersistentes siguiendo el idioma común de java – incluyendo asociación, inherencia, polimorfismo,composición y el Framework de colecciones de Java. Hibernate permite expresar consultas en su

propia extensión SQL (HQL), de forma similar a SQL nativo, o con objetos Java.El sistema de persistencia Hibernate se basa en una capa intermedia entre nuestro Sistema deInformación y la Base de Datos Relacional.

La conexión entre ambas se realiza median un Objeto Relacional, que es el paso intermedio entreObjetos y Tablas Relacionales.

Figura 8: Esquema de la capa de persistencia




.

Todos los servicios que se desarrollarán para el sistema serán desarrollados como Enterprise JavaBeans, más concretamente en su especificación 3.0 debido a una serie de ventajas quecomentaremos a continuación.

Los EJB 3.0 proporcionan un modelo de componentes distribuido estándar del lado del servidor. Elobjetivo de los EJB3.0 es dotar al programador de un modelo que le permita abstraerse de losproblemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia,seguridad,...) para centrarse en el desarrollo de la lógica de negocio en sí. El hecho de estar basadoen componentes permite que éstos sean flexibles y sobre todo reutilizables.

Los EJB3.0 se disponen en un contenedor EJB 3.0 dentro del servidor de aplicaciones. Laespecificación describe cómo el EJB 3.0 interactúa con su contenedor y cómo el código cliente

interactúa con la combinación del EJB 3.0 y el contenedor.A través de un "EJB 3.0 Container" ofrece varios servicios y funcionalidades, algunas son lassiguientes:

- Servicios: Cuando se diseña un componente de Software se deben definirvarios servicios para su funcionamiento.

- División de Trabajo: La posibilidad de dividir "Servicios"(EJB 3.0 Container)de "Componentes Principales"(EJB 3.0'S) permite una clara división detrabajo, esto es, un diseñador de "componentes"(EJB 3.0's) puedeconcentrar sus esfuerzos en la "lógica de proceso" sin preocuparse deldiseño de servicios. Y de la misma manera un "diseñador" de servicios("Middleware") concentrarse en su área.

- Procedimientos Remotos: Debido a la solución que intentan ofrecer EJB 3.0("Enterprise Java Beans") su diseño gira alrededor de procedimientosremotos

- Diversos Clientes: Un EJB 3.0 puede interactuar con una gran gamma declientes desde: JSP o Servlets, bases de datos, Applets, sistemas ERP(SAP, JDEdward’s).




.

9. DISEÑO DE CASOS DE USO REALES.

Esta actividad, que se realiza solo en el caso de Diseño Orientado a Objetos, tiene como propósitoespecificar el comportamiento del sistema de información para un caso de uso, mediante objetos osubsistemas de diseño que interactúan, y determinar las operaciones de las clases e interfaces delos distintos subsistemas de diseño. Para ello, una vez identificadas las clases participantes dentrode un caso de uso, es necesario completar los escenarios que se recogen del análisis, incluyendolas clases de diseño que correspondan y teniendo en cuenta las restricciones del entornotecnológico, esto es, detalles relacionados con la implementación del sistema. Es necesario analizarlos comportamientos de excepción para dichos escenarios. Algunos de ellos pueden haber sidoidentificados en el proceso de análisis, aunque no se resuelven hasta este momento. Dichasexcepciones se añadirán al catálogo de excepciones para facilitar las pruebas. Algunos de losescenarios detallados requerirán una nueva interfaz de usuario. Por este motivo es necesario

diseñar el formato de cada una de las pantallas o impresos identificados. Es importante validar quelos subsistemas definidos en la tarea Identificación de Subsistemas de Diseño tienen la mínimainterfaz con otros subsistemas. Por este motivo, se elaboran los escenarios al nivel de subsistemasy, de esta forma, se delimitan las interfaces necesarias para cada uno de ellos, teniendo en cuentatoda la funcionalidad del sistema que recogen los casos de uso. Además, durante esta actividadpueden surgir requisitos de implementación, que se recogen en el catálogo de requisitos. Las tareasde esta actividad se realizan en paralelo con las de Diseño de Clases.

9 .1 Identificación de Clases asociadas a un Caso de Uso.

El objetivo de esta tarea es identificar las clases que intervienen en cada caso de uso, a partir delconjunto de clases definidas en la tarea Identificación de Clases Adicionales, ya que, como se haseñalado en la introducción de esta actividad, las actividades Diseño de casos de uso reales yDiseño de clases se realizan en paralelo. Dichas clases se identifican a partir de las clases delmodelo del análisis y de aquellas clases adicionales necesarias para el escenario que se estádiseñando. A su vez, a medida que se va estudiando la descripción de los casos de uso, puedenaparecer nuevas clases de diseño que no hayan sido identificadas anteriormente y que seincorporan al modelo de clases posteriormente.




.

9.1.0 Consola.

En este apartado se identifican las clases de diseño que se utilizan para realizar el subsistema deconsola.

Los paquetes de los que se compone el subsistema de consola se pueden ver en la siguiente figura:




.

Como se ve en la imagen, el subsistema de consola afecta tanto a los paquetes ‘servicios’, que son

los que contendrán la lógica de negocio de los servicios comunes de acceso a la consola paracomprobar la autenticación del usuario y establecerle los permisos; como al paquete ‘ihm’, quecontendrá las interfaces gráficas para que un usuario (humano) pueda hacer uso del resto defuncionalidades

Para los paquetes que dependen de ‘BEANS.SEGURIDAD’, las clases que lo forman son lasencargadas de proporcionar servicios de acceso a la consola para comprobar la autenticación delusuario y establecerle los permisos. Estas clases son las siguientes:

CASO DE USO: Recibir FIP DUC-VAL-1

CLASE: GestionIntroduccionFIPEnSistemaBean

Atributos

Operaciones

Descripción Controla la introducción de ficheros FIP en el Sistema.




.

CASO DE USO: Autenticación DUC-CON-1

CLASE: AutenticacionController

Atributos

Operaciones

Descripción Autentifica los accesos de los usuarios al sistema.

CASO DE USO: Acceso a los módulos del sistema DUC-CON-3:

CASO DE USO: Acceso al módulo de gestión de diccionarios DUC-CON-3.1:

CASO DE USO: Acceso al módulo de gestión del plan base DUC-CON-3.2:CASO DE USO: Acceso al módulo de Consolidación de FIP DUC-CON-3.4:

CASO DE USO: Acceso al módulo de motor de refundido DUC-CON-3.5:

El acceso a los módulos del sistema es gestionado mediante controles de java Script.

Estos Java Script son los siguientes:

- loader.js

- loaderAdministracion.js

- loaderConsola.js

- loaderConsolidador.js

- loaderRefundido.js

- loaderVisRPM.js

- loaderVisualizadorValidacion.js

- loaderGestionPlanBase.js

- loaderGestionDiccionarios.js

Estos Java Script comprobaran que el usuario tiene acceso a los módulos a los que intenta accedery en caso afirmativo, creará la pantalla dinámicamente.




.

CASO DE USO: Acceso al módulo de validación de FIP DUC-CON-3.3:

CLASE: ValidacionControler

Atributos

Operaciones

Descripción Gestiona el acceso al módulo de Validación FIP en la Consola.

CASO DE USO: Acceso al diario de operaciones DUC-CON-6.

El diario de operaciones, queda todo registrado dentro de los distintos logs de la consola.

Estos log se encuentra dentro del servidor en la ruta Redes_Path\var\log.

Estos logs son:

- Urbanismoenred.log

- UrbanismoenredServicios.log

- UrbanismoenredServiciosBasicosRPM.log

- UrbanismoenredServiciosBasicosValidacion.log

- UrbanismoenredServiciosConsolidacion.log

- UrbanismoenredServiciosRefundido.log

- UrbanismoenredServiciosValidacion.log

- UrbanismoenredUtils.log

- ServicioValidacionDeterminacionSoloAplicadaEntidadesDefinidasGrupoAplicacionBean.log




.

CASO DE USO: Gestión de usuarios y roles DUC-CON-5:

CASO DE USO: Asignación DUC-CON-5.1

CLASE: RolBean

Atributos

Operaciones

Descripción Gestiona el acceso al módulo de Gestión de Usuarios y Roles en laConsola.

CASO DE USO: Creación de planes DUC-CON-4.3

CLASE: OperacionPlanBean

Atributos

Operaciones

Descripción Clase de Creación de planes




.

CASO DE USO: Visualización de planes DUC-CON-4.1

CLASE: PlanBean

Atributos

Operaciones

Descripción Controla las operaciones de Planes desde la consola.

CASO DE USO: Visualización de árbol de planes DUC-CON-2




.

CLASE: PlanIHMFacadeAtributos

Operaciones


CLASE: PlanIHMFacade




.

Atributos

Operaciones


CASO DE USO: Visualizador de geometrías DUC-VAL-9.4.2 y DUC-CON-4.2.3.2, es unafuncionalidad Java Script a la que se puede acceder desde el visualizador de validación,seleccionando un trámite del árbol, a continuación una entidad, y navegando por las entidades selocalizaran las geometrías.




.

CASO DE USO: Creación de trámites DUC-CON-4.4

CASO DE USO: Visualización de trámites DUC-CON-4.2

CASO DE USO: Visualizador de trámite DUC-VAL-9.1

CASO DE USO: Visualizador de documentos de trámite DUC-VAL-9.2

CLASE: TramiteContoller

Atributos

Operaciones

Descripción Controla las operaciones de Trámites desde la consola.

CLASE: TramiteIHMFacade

Descripción Interface de Tramite




.

CASO DE USO: Visualizador de documentos propios del trámite DUC-CON-4.2.1

CASO DE USO: Visualizador de documentos de entidades DUC-CON-4.2.3.5

CASO DE USO: Visualizador de documentos de determinaciones DUC-CON-4.2.2.6

CLASE: DocumentoController

Atributos

Operaciones

Descripción Controla las operaciones de Documentos desde la consola

CLASE: DocumentoIHMFacade

Descripción Interface de Documento

CASO DE USO: Visualización de determinaciones DUC-CON-4.2.2

CASO DE USO: Visualizador de valores de referencia DUC-CON-4.2.2.1

CASO DE USO: Visualizador de grupos de aplicación DUC-CON-4.2.2.2

CASO DE USO: Visualizador de regulación específica DUC-CON-4.2.2.3

CASO DE USO: Visualizador de determinaciones reguladoras DUC-CON-4.2.2.4CASO DE USO: Visualizador de operaciones entre determinaciones DUC-CON-4.2.2.5

CASO DE USO: Visualizador de documentos de determinaciones DUC-CON-4.2.2.6

CASO DE USO: Visualizador de aplicaciones de determinaciones DUC-CON-4.2.2.7

CASO DE USO: Visualizador de la aplicación de determinaciones DUC-CON-4.2.3.3

CASO DE USO: Visualizador de regímenes DUC-CON-4.2.3.3.2

CASO DE USO: Visualizador de regímenes específicos DUC-CON-4.2.3.3.3

CASO DE USO: Visualizador de determinaciones DUC-VAL-9.3

CASO DE USO: Visualizador de valores de referencia DUC-VAL-9.3.1




.

CASO DE USO: Visualizador de grupos de aplicación DUC-VAL-9.3.2

CASO DE USO: Visualizador de regulación específica DUC-VAL-9.3.3

CASO DE USO: Visualizador de determinaciones reguladoras DUC-VAL-9.3.4

CASO DE USO: Visualizador de operaciones entre determinaciones DUC-VAL-9.3.5

CASO DE USO: Visualizador de documentos de determinaciones DUC-VAL-9.3.6

CASO DE USO: Visualizador de aplicaciones de determinaciones DUC-VAL-9.3.7

CASO DE USO: Visualizador de la aplicación de determinaciones DUC-VAL-9.4.3

CLASE: DeterminacionController

Atributos

Operaciones

Descripción Controla las operaciones de Determinaciones desde la consola.

CLASE: DeterminacionIHMFacade

Descripción Interface de Determinaciones




.

CASO DE USO: Visualización de entidades DUC-CON-4.2.3

CASO DE USO: Visualizador de operaciones entre entidades DUC-CON-4.2.3.4

CASO DE USO: Visualizador de entidades DUC-VAL-9.4

CASO DE USO: Visualización de mapas temáticos DUC-VAL-14

CLASE: EntidadController

Atributos

Operaciones

Descripción Controla las operaciones de Entidad desde la consola.

CLASE: EntidadIHMFacade

Descripción Interface de Entidad




.

CASO DE USO: Visualizador de adscripciones DUC-CON-4.2.3.1

CASO DE USO: Visualizador de adscripciones DUC-VAL-9.4.1

CLASE: AdscripcionesController

Atributos

Operaciones

Descripción Controla las operaciones de Adscripciones desde la consola.

CLASE: AdscripcionesIHMFacade

Descripción Interface de Adscripciones




.

CASO DE USO: Visualizador de casos DUC-CON-4.2.3.3.1

CASO DE USO: Visualizador de casos DUC-VAL-9.4.4

CLASE: CasosController

Atributos

Operaciones

Descripción Controla las operaciones de Casos desde la consola.

CLASE: CasosIHMFacade

Descripción Interface de Casos




.

9.1.1 Validador.

Los paquetes de los que se compone el subsistema de validación se pueden ver en la siguientefigura:




.

Como se ve en la imagen, el subsistema de validación afecta tanto a los paquetes ‘data’, ya que sedeberá hacer consultas a datos de validación que haya en base de datos; al paquete ‘servicios’, queson los que contendrán la lógica de negocio de los servicios de validación; como al paquete ‘ihm’,que contendrá las interfaces gráficas para que un usuario (humano) pueda hacer uso de losservicios de validación.

Para el paquete ‘data.validacion’, las clases que lo forman son las encargadas del mapeo relacionalobjeto-base de datos. Estas clases son las siguientes:




.

Para el paquete ‘servicios.validacion’, las clases que lo forman son las encargadas de la lógica de

negocio del servicio. Estas clases son las siguientes:

Para los paquetes que dependen de ‘servicios.validacion’, las clases que lo forman son lasencargadas de la lógica de negocio del servicio. Estas clases son las siguientes:




.

Para los paquetes que dependen de ‘servicios.basicos.validacion’, las clases que lo forman son las

encargadas de proporcionar servicios básicos a las anteriores clases descritas del paquete‘servicios.validacion’. Estas clases son las siguientes:

CASO DE USO: Verificación de vigencia del FIP de tipo 1 DUC-VAL-002

CASO DE USO: Validación sintáctica DUC-VAL-3

CASO DE USO: Validar Integridad DUC-VAL-7

CLASE: ServicioValidacionIntegridadBean

Atributos

Operaciones

Descripción Procedimientos de validación de Integridad.




.

CASO DE USO: Validación de Contenido DUC-VAL-4

CLASE: ServicioValidacionBean

Atributos

Operaciones

Descripción Realiza las llamadas a las distintas validaciones.

CASO DE USO: Validar Documentos DUC-VAL-5

CLASE: ServicioValidacionOtrasBean

Atributos

Operaciones

Descripción Realiza las validaciones de documentos.




.

CASO DE USO: Validación geométrica DUC-VAL-6

CLASE: ServicioValidacionEntidadesWKTBean

Atributos

Operaciones

Descripción Validaciones de datos geométricos.

CASO DE USO: Validación manual DUC-VAL-8

CLASE: ValidationManualServiceBean

Atributos

Operaciones

Descripción Gestiona las validaciones manuales.




.

CASO DE USO: Visualizador de FIP DUC-VAL-9

CLASE: FIPValidacionController

Atributos

Operaciones

Descripción Visualiza el FIP de Validación en la Consola RPM.

CLASE: ValidacionFIPIHMFacade

Descripción Interface de FIP




.

CASO DE USO: Visualizador de regímenes DUC-VAL-9.4.5

CLASE: RegimenValidacionControlller

Atributos

Operaciones

Descripción Visualiza los datos de Régimen Validación Consola RPM.

CLASE: ValidacionRegimenValidacionIHMFacade

Descripción Interface de Régimen




.

CASO DE USO: Visualizador de regímenes específicos DUC-VAL-9.4.6

CASO DE USO: Visualizador de operaciones entre entidades DUC-VAL-9.4.7

CASO DE USO: Visualizador de documentos de entidades DUC-VAL-9.4.8

CLASE: RegimenEspecificoValidacionControlller

Atributos

Operaciones

Descripción Visualiza los datos de Régimen Específico Validación Consola RPM.

CLASE: ValidacionRegimenEspecificoValidacionIHMFacade

Descripción Interface de Régimen Específico




.

CASO DE USO: Informes FIP DUC-VAL-10

CLASE: ManagementValidacionPDFServiceBean

Atributos

Operaciones

Descripción Genera documento PDF con los resultados de las validaciones.

CLASE: ServicioResultadosValidacionBean

Atributos

Operaciones

Descripción Gestiona los resultados de las validaciones

CASO DE USO: Incorporación de nuevas validaciones DUC-VAL-11




.

CLASE: ServicioCargaInicialValidacionesBeanAtributos

Operaciones

Descripción Realiza las operaciones de carga inicial de validaciones.




.

CLASE: ValidacionValidacionesGenericasFacadeAtributos

Operaciones

Descripción Gestiona las validaciones genéricas

CLASE: ValidacionValidacionesEspecificasFacade

Atributos




.

Operaciones

Descripción Gestiona las validaciones específicas

CASO DE USO: Firma digital validación FIP DUC-VAL-13

CLASE: FirmaDigitalBean

Atributos

Operaciones

Descripción Valida Certificados Digitales tales como DNI-e y FNMT. Y firma FIPsdigitalmente.




.

CASO DE USO: Validación topológica DUC-VAL-15

CLASE: ValidacionTopologicaBean

Atributos

Operaciones

Descripción Servicio de validación topológica de solapamientos y agujeros.




.

9.1.2 Consolidador.

En este apartado se identifican las clases de diseño que se utilizan para realizar el subsistema deconsolidador.

Los paquetes de los que se compone el subsistema de consolidación se pueden ver en la siguientefigura:

Como se ve en la imagen, el subsistema de consolidación afecta tanto a los paquetes ‘data’, ya quese deberá hacer consultas a datos de validación que haya en base de datos y estos datosposteriormente después de aplicarle las respectivas transformaciones, guardarlos en la base dedatos del registro de planeamiento (rpm); al paquete ‘servicios’, que son los que contendrán lalógica de negocio de los servicios de consolidación, teniendo por un lado acceso a los datafacade, a




.

los servicios básicos y a los servicios propios de lógica de consolidación; como al paquete ‘ihm’, que

contendrá las interfaces gráficas para que un usuario (humano) pueda hacer uso de los servicios deconsolidación.

Para el paquete ‘data.validacion’, las clases que lo forman son las encargadas del mapeo relacionalobjeto-base de datos de validación que serán usadas por este subsistema. Estas clases son lassiguientes:

Para el paquete ‘data.rpm’, las clases que lo forman son las encargadas del mapeo relacionalobjeto-base de datos del registro de planeamiento municipal que serán usadas por este subsistema.Estas clases son las siguientes:




.

Para los paquetes que dependen de ‘servicios.basicos.validacion’, las clases que lo forman son lasencargadas de proporcionar servicios básicos a las clases descritas del paquete‘servicios.consolidacion’ que contienen la lógica de negocio. Estas clases son las siguientes:




.

Para los paquetes que dependen de ‘servicios.basicos.rpm’, las clases que lo forman son las

encargadas de proporcionar servicios básicos a las clases descritas del paquete‘servicios.consolidacion’ que contienen la lógica de negocio. Estas clases son las siguientes:

Para los paquetes que dependen de ‘servicios.consolidacion’, las clases que lo forman son lasencargadas de la lógica de negocio del servicio. Estas clases son las siguientes:




.

CASO DE USO: Carga de trámite DUC-CSD-2

CASO DE USO: Carga del Documentos del Trámite DUC-CSD-2.1

CASO DE USO: Carga de las Entidades DUC-CSD-2.2

CASO DE USO: Carga de las Determinaciones DUC-CSD-2.3

CASO DE USO: Carga de las Condiciones Urbanísticas DUC-CSD-2.4

CASO DE USO: Carga de las Operaciones DUC-CSD-2.5

CASO DE USO: Carga de las Adscripciones DUC-CSD-2.6

CASO DE USO: Carga de los Casos DUC-CSD-2.7

CASO DE USO: Creación de metadatos DUC- URBR_18.1

CLASE: ServicioConsolidacionBean

Atributos

Operaciones

Descripción Realiza una copia de todos los datos de un Trámite a la Base de Datos

de Planeamiento




.

9.1.3 Motor de Refundido.

En este apartado se identifican las clases de diseño que se utilizan para realizar el subsistema deRefundido.

Los paquetes que componen el sistema del Motor de refundido son los que se presentan en lasiguiente figura:

Como se ve en la imagen, el subsistema de Motor de Refundido, afecta tanto a los paquetes ‘data’,ya que se deberá hacer consultas a datos que haya en base de datos; al paquete ‘servicios’, queson los que contendrán la lógica de negocio de los servicios de Motor de Refundido.;

Para el paquete ‘servicios.refundido’, las clases que lo forman son las encargadas del mapeorelacional objeto-base de datos. Estas clases son las siguientes:




.

CASO DE USO: Validaciones previas del proceso de refundido DUC-REF-1.2.

CASO DE USO: Comprobación topológica DUC-REF-1.6 noEstos casos de uso estaban pensados para versiones antiguas del Sistema, antes de que existieraun subsistema de Validación; Actualmente estas comprobaciones que indican los casos de uso, notienen sentido ya que están ampliadas dentro del subsistema de Validación.

CASO DE USO: Extracción de los últimos trámites de cada plan DUC-REF-1.3.2

CASO DE USO: Ejecución del proceso de refundido parcial DUC-REF-4

De estos casos de uso se encargará el Controler del Proceso de Refundido de la Consola RPM.

CASO DE USO: Generación del FIP de tipo 2 del trámite refundido DUC-REF-2




.

CLASE: TramiteAtributos

Operaciones

Descripción Entity de tipo dato Tramite




.

CASO DE USO: Eliminación de determinaciones y entidades operadoras DUC-REF-1.5.1

CASO DE USO: Eliminación de carpetas vacías en los árboles de datos DUC-REF-1.5.2

CLASE: clsMain

Atributos

Operaciones

Descripción Realiza funciones de propósito general para el proceso de refundido.




.

CLASE: clsOperacionDeterminacionAtributos

Operaciones

Descripción Realiza las operaciones propias de Determinaciones.

CLASE: ClsOperacionEntidad

Atributos

Operaciones

Descripción Realiza las operaciones propias de Entidades.




.

CLASE: clsOperacionPlan

Atributos

Operaciones

Descripción Realiza las operaciones propias de Planes.

CASO DE USO: Ejecución del proceso de refundido DUC-REF-1

CASO DE USO: Obtención de la lista ordenada de planes refundibles DUC-REF-1.3.1

CASO DE USO: Algoritmo de refundido DUC-REF-1.4

CLASE: RefundidoBean

Atributos

Operaciones

Descripción Clase principal del proceso de refundido, contiene la distribución uordenación de las tareas del proceso.

CASO DE USO: Presentación de informe del proceso de refundido DUC-REF-3:

El informe de refundido, será el fichero de log, Refundido.log, donde se detallará todo lo sucedidodurante el proceso de Refundido.

Este informe se genera con la biblioteca Log4j.




.

9.1.4 Servicios Web.

En este apartado se identifican las clases de diseño que se utilizan para realizar el subsistema deservicios web.

Los paquetes de los que se compone el subsistema de servicios web se pueden ver en la siguientefigura:

Como se ve en la imagen, el subsistema de servicios web afecta tanto a los paquetes ‘data’, ya quese deberá hacer consultas a datos de validación que haya en base de datos como a datos que hayaen la base de datos del registro de planeamiento (rpm) para ofrecer los datos que requiere elservicio web; al paquete ‘servicios’, que son los que contendrán la lógica de negocio de los serviciosweb, teniendo por un lado acceso a los datafacade, a los servicios básicos y a los servicios propiosde lógica de los servicios web.

Para el paquete ‘data.validacion’, las clases que lo forman son las encargadas del mapeo relacionalobjeto-base de datos de validación que serán usadas por este subsistema. Estas clases son lassiguientes:




.

Para el paquete ‘data.rpm’, las clases que lo forman son las encargadas del mapeo relacionalobjeto-base de datos del registro de planeamiento municipal que serán usadas por este subsistema.Estas clases son las siguientes:




.

Para los paquetes que dependen de ‘servicios.basicos.validacion’, las clases que lo forman son las

encargadas de proporcionar servicios básicos a las clases descritas del paquete‘servicios.serviciosweb’ que contienen la lógica de negocio. Estas clases son las siguientes:




.

Para los paquetes que dependen de ‘servicios.basicos.rpm’, las clases que lo forman son las

encargadas de proporcionar servicios básicos a las clases descritas del paquete‘servicios.serviciosweb’ que contienen la lógica de negocio. Estas clases son las siguientes:

Para los paquetes que dependen de ‘servicios.serviciosweb’, las clases que lo forman son lasencargadas de la lógica de negocio del servicio que ofrecerán estos servicios web. Estas clases sonlas siguientes:




.

CASO DE USO: Búsqueda por callejero DUC-SRV-1.4.1:

CASO DE USO: Consulta de planes DUC-SRV-1.2.1

CASO DE USO: Consulta de trámites DUC-SRV-1.2.2

CASO DE USO: Consulta de documentos DUC-SRV-1.2.3

CASO DE USO: Consulta a partir de un punto DUC-SRV-1.3.1

CASO DE USO: Consulta a partir de un polígono DUC-SRV-1.3.2

CASO DE USO: Consulta a partir de metadatos DUC-SRV-1.3.3

CASO DE USO: Consulta del estado del registro DUC-SRV-1.3.4

CASO DE USO: Búsqueda por topónimos DUC-SRV-1.4.2

CASO DE USO: Búsqueda por datos urbanísticos DUC-SRV-1.4.4

CASO DE USO: Servidor de mapas DUC-SRV-2:CASO DE USO: Preconstrucción y tileado de mapas DUC-SRV-2.1.3

CASO DE USO: Administración de simbologías DUC-SRV-2.1.4

CASO DE USO: Administración de capas DUC-SRV-2.5

CASO DE USO: Configuración y tunning de servicios DUC-SRV-2.6

CASO DE USO Servicios de consulta alfanumérica DUC-SRV_1

CASO DE USO Servicios de consultas del registro DUC-SRV_1.2

CASO DE USO Servicios de búsqueda DUC-SRV_1.4

CASO DE USO Servicios de mapas de planeamiento refundido DUC-SRV_2.3

CASO DE USO Servicios de mapas de planeamiento en tramitación DUC-SRV_2.4

CASO DE USO ÁMBITO DE APLICACIÓN DUC-SRV-2.5.1CASO DE USO: Servicios de consulta Alfanumérica DUC-SRV-1

CASO DE USO: Servicio de búsqueda DUC-SRV-1.4

CASO DE USO CLASES DE SUELO DUC-SRV-2.5.2

CASO DE USO CATEGORIAS DUC-SRV-2.5.3

CASO DE USO ZONAS DUC-SRV-2.5.4

CASO DE USO GESTION DUC-SRV-2.5.5

CASO DE USO SISTEMAS DUC-SRV-2.5.6

CASO DE USO PROTECCIONES DUC-SRV-2.5.7

CASO DE USO AFECCIONES DUC-SRV-2.5.8CASO DE USO RESERVAS DUC-SRV-2.5.9

CASO DE USO ACCIONES DUC-SRV-2.5.10

CASO DE USO Sistemas de referencia utilizados DUC-SRV_2.7

CASO DE USO: Búsqueda por referencia catastral DUC-SRV-1.4.3




.

CLASE: urbrWSOperaciones




.

Descripción Clase contenedora de todos los Servicios Web

La siguiente tabla muestra la relación entre el caso de uso y el servicio web que lo satisface.

CASO DE USO: Búsqueda por callejero DUC-SRV-1.4.1: GetCoordenadas CASO DE USO: Consulta de planes DUC-SRV-1.2.1 estadoRegistro, IdAmbito, PlanesPadre, PlanesHijo, planesFromNombre

CASO DE USO: Consulta de trámites DUC-SRV-1.2.2 determinacionesPadre, DeterminacionesHija, entidadesFromClave, entidadesFromNombre

CASO DE USO: Consulta de documentos DUC-SRV-1.2.3 URLDoc CASO DE USO: Consulta a partir de un punto DUC-SRV-1.3.1 consultaGrafica CASO DE USO: Consulta a partir de un polígono DUC-SRV-1.3.2 consultaGrafica CASO DE USO: Consulta a partir de metadatos DUC-SRV-1.3.3 consultaMetadatos CASO DE USO: Consulta del estado del registro DUC-SRV-1.3.4 estadoRegistro CASO DE USO: Búsqueda por topónimos DUC-SRV-1.4.2 entidadesFromNombre,planesFromNombre CASO DE USO: Búsqueda por datos urbanísticos DUC-SRV-1.4.4

AmbitosPadre, AmbitosHijo, entidadesFromNombre,planesFromNombre

CASO DE USO: Servidor de mapas DUC-SRV-2: Geoserver CASO DE USO: Preconstrucción y tileado de mapas DUC-SRV-2.1.3 Geoserver CASO DE USO: Administración de simbologías DUC-SRV-2.1.4 Geoserver CASO DE USO: Administración de capas DUC-SRV-2.5 Geoserver CASO DE USO: Configuración y tunning de servicios DUC-SRV-2.6 Geoserver CASO DE USO

Servicios de consulta alfanumérica DUC-SRV_1

Requisito no funcional CASO DE USO Servicios de consultas del registro DUC-SRV_1.2 Requisito no funcional CASO DE USO Servicios de búsqueda DUC-SRV_1.4 Requisito no funcional CASO DE USO Servicios de mapas de planeamiento refundido DUC-SRV_2.3 Geoserver CASO DE USO Servicios de mapas de planeamiento en tramitación DUC-SRV_2.4 Geoserver CASO DE USO ÁMBITO DE APLICACIÓN DUC-SRV-2.5.1 Geoserver CASO DE USO CLASES DE SUELO DUC-SRV-2.5.2 Geoserver CASO DE USO CATEGORIAS DUC-SRV-2.5.3 Geoserver CASO DE USO ZONAS DUC-SRV-2.5.4 Geoserver CASO DE USO GESTION DUC-SRV-2.5.5 Geoserver CASO DE USO SISTEMAS DUC-SRV-2.5.6 Geoserver CASO DE USO PROTECCIONES DUC-SRV-2.5.7 Geoserver CASO DE USO AFECCIONES DUC-SRV-2.5.8 Geoserver CASO DE USO RESERVAS DUC-SRV-2.5.9 Geoserver CASO DE USO ACCIONES DUC-SRV-2.5.10 Geoserver CASO DE USO Sistemas de referencia utilizados DUC-SRV_2.7 No es un requisito funcional CASO DE USO: Búsqueda por referencia catastral DUC-SRV-1.4.3 ReferenciaCatastral




.

CASO DE USO: Emisor de fichas urbanísticas DUC-SRV-1.1

CLASE: FichaUrbanistica

Operaciones

Descripción La Clase urbrWS llamará a este servlet que será el encargado degenerar un ficha urbanística a partir de unas coordenadas.




.

CASO DE USO: Formulario de petición y descarga de FIP de tipo 1 DUC-SRV-3:

CLASE: ActionServletFip1

Atributos

Operaciones

Descripción La Clase urbrWS llamará a este servlet que será el encargado desolicitar la generación del FIP tipo 1.

CLASE:

Atributos

Operaciones

Descripción Servicio de generación de fichero FIP tipo 1.




.

CASO DE USO: Servidor WMS DUC-SRV-001.1:

CASO DE USO: Servidor WFS DUC-SRV-2.2:

Respecto a los casos de uso de publicación de servicios wms y wfs, se cubren con laimplementación de geoserver 2.0. Es un servidor desarrollado en java con software libre queimplementa estándares abiertos que permiten publicar datos espaciales.

GeoServer puede publicar y editar los datos mediante estándares abiertos. Su información estádisponible en una gran variedad de formatos, como mapas e imágenes reales o de datos

geoespaciales, proporcionando control completo sobre el aspecto del mapa.Las capacidades transaccionales GeoServer ofrecen un fuerte apoyo para la edición compartida.GeoServer está enfocado a la facilidad de uso y soporte para estándares, con el fin de servir como"pegamento" de la web geoespacial, la conexión de bases de datos heredadas a muchos clientesdiversos.

GeoServer admite WFS-T y protocolos abiertos WMS de la OGC para producir JPEG, PNG, SVG,KML / KMZ, GML, PDF, Shapefiles y mucho más.

GeoServer se basa en Geotools, la misma herramienta Java utiliza en la consola.

GeoServer es una comunidad verdaderamente abierta, bien documentada y código base modular.

http://vwfs.refractions.net/docs /GeoserverConfigDesign.pdf

http://vwfs.refractions.net/docs/GeoserverConfigDesign.pdf






.

9.1.5 Gestión de Diccionarios.

En este apartado se identifican las clases de diseño que se utilizan para realizar el subsistema degestión de diccionarios.

Los paquetes que componen el subsistema de Gestión de Diccionarios son los que se presentan enla siguiente figura:

Como se ve en la imagen, el subsistema de Gestión de Diccionarios, afecta tanto a los paquetes‘data’, ya que se deberá hacer consultas a datos que haya en base de datos; al paquete ‘servicios’,que son los que contendrán la lógica de negocio de los servicios de Gestión de Diccionarios;




.

CASO DE USO: Alta de registros DUC-DIC-1:

CASO DE USO: Eliminación de registros DUC-DIC-2:

CASO DE USO: Activación desactivación de la funcionalidad DUC-DIC-3

CASO DE USO: Gestión de equipos de redacción DUC-DIC-4:




.

CLASE: ActionServletDicAtributos N/A

Operaciones

Descripción Realiza las tareas propias del mantenimiento de las tablas dediccionario. Mediante componentes Json, dependiendo de la opción denavegación seleccionada, realizará la correspondiente tarea de alta,baja o modificación mediante la llamada al facade de la tabla amodificar y este a su vez, al entity donde tendrá la llamada del json.

A continuación exponemos una clase ejemplo con los métodos jsonque serán implementados en cada uno de los entitys comentado en elgráfico anterior.

Métodos Json.




.

9.1.6 Gestión del Plan Base.

En este apartado se identifican las clases de diseño que se utilizan para realizar el subsistema degestión de Plan Base.

Los paquetes que componen el subsistema de Gestión de Diccionarios son los que se presentan enla siguiente figura:

Como se ve en la imagen, el subsistema de Gestión de Plan Base, afecta tanto a los paquetes‘data’, ya que se deberá hacer consultas a datos que haya en base de datos; al paquete ‘servicios’,que son los que contendrán la lógica de negocio de los servicios de Gestión de Plan Base;

Para el paquete ‘servicios.PlanBase’, las clases que lo forman son las siguientes:




.

CASO DE USO: Creación del Plan Base DUC-BAS-1:

CASO DE USO: Creación del Trámite de alta del Plan Base DUC-BAS-2:

CASO DE USO: Creación de determinaciones base DUC- BAS -3:

CASO DE USO: Creación de entidades base DUC- BAS-6:

CLASE: AltaAltaBean

Atributos

Operaciones

Descripción Da de alta un Plan Base




.

CASO DE USO: Eliminación de determinaciones base DUC-BAS-5:

CASO DE USO: Eliminación de entidades base DUC-BAS-8:

CLASE: BajaPlanBaseBean

Atributos

Operaciones

Descripción Da de baja un Plan Base

CASO DE USO: Modificación de entidades base DUC-BAS-7:

CASO DE USO: Modificación de determinaciones base DUC-BAS-4:

CASO DE USO: Activación desactivación de la funcionalidad DUC-BAS-9:

CLASE: GestionPlanBaseBean

Atributos

Operaciones

Descripción Realiza la funciones de mantenimiento de Plan Base.




.

9 .2 DISEÑO DE CLASES.

A continuación se presenta el diagrama de contexto de la aplicación de consola y visor Web y aposteriormente se describirán los actores y los casos de uso de cada uno de los módulos delsistema.

A continuación presentamos los casos de uso para los subsistemas de Consola de Control dePlaneamiento y visor Web:

Comenzaremos con los Casos de Uso genéricos (propios de la Consola) y después trataremosindividualmente cada uno de los MODULOS que la componen y el visor WEB.

9.2.0 Consola.

En este apartado se detallan mediante diagramas de secuencia los distintos casos de usos delsubsistema de consola descritos en el documento de análisis (ASI).

Estos casos de usos estarán recogidos en los distintos diagramas que se presentan pudiendo undiagrama dar respuesta a más de un caso de uso planteado durante el análisis.

Los casos de uso a los que da respuesta los diagramas son los siguientes:

- Diagrama de Secuencia de Autenticación.

o CASO DE USO: Autenticación DUC-CON-1

El siguiente diagrama muestra la secuencia que seguirá el caso de uso deautenticación referidas a las distintas clases de diseño




.

Este diagrama muestra el flujo normal que se realiza para la autenticación de un usuario en elsistema. Este flujo es el siguiente:

1.- El usuario pretende acceder al sistema.




.

2.- El sistema al no detectar ninguna sesión abierta por parte del usuario ni llevar un token de

autentificación, pide al usuario el envío de sus credenciales3.- El usuario envía al ServicioControlAccesoSistema su nombre de usuario y su contraseña ocertificado digital

4.- El ServicioControlAccesoSistema comprueba las credenciales que la credencial.

5.- El ServicioControlAccesoSistema solicitará a la base de datos si existe dicha credencial.

6.- Después de obtener ambos datos de la base de datos, el ServicioControlAccesoSistema hará lascomprobaciones convenientes para averiguar si el usuario es efectivamente un usuario registradodel sistema y la credencial es correcta.

7.- En caso de que el usuario y la contraseña facilitada sean correctos, elServicioControlAccesoSistema devolverá al usuario un token de autenticación mediante el cual yapodrá tener acceso al sistema

8.- Si o bien el usuario no es un usuario registrado del sistema o la clave es errónea, elServicioControlAccesoSistema informará al usuario de este hecho, ante lo cual se denegaráprovisionalmente el acceso del usuario al sistema

- Diagrama de Secuencia de Acceso a los módulos del Sistema.

o DUC-CON-3: Acceso a los módulos del sistema

o DUC-CON-3.1: Acceso al módulo de gestión de diccionarios

o DUC-CON-3.2: Acceso al módulo de gestión del plan base

o DUC-CON-3.3: Acceso al módulo de validación de FIP

o DUC-CON-3.4: Acceso al módulo de consolidación de FIP

o DUC-CON-3.5: Acceso al módulo de motor de refundidoEl siguiente diagrama muestra la secuencia que seguirá el caso de uso de acceso a los módulosdel sistema referidas a las distintas clases de diseño, por simplicidad y mejor lectura en el diagrama,se ha puesto solamente el ejemplo para el acceso para tres de los subsistemas (GestiónDiccionario, Validación y Consolidación), sería equivalente para el resto de subsistemas (MotorRefundido, Gestión Plan Base y Diario Operaciones)




.

Este diagrama muestra el flujo normal que se realiza para el acceso a los distintos módulos desubsistema dentro del sistema. Este flujo parte del flujo anterior en el cual un usuario quiere accederal sistema:

1.- El usuario quiere acceder al subsistema de gestión de diccionario a través del servicioServicioGestionDiccionario, para ello, el usuario mandará el token obtenido anteriormente quecontiene su identificación y rol.

2.- El ServicioGestionDiccionario previamente a concederle acceso a cualquiera de susfuncionalidades, comprueba contra el ServicioControlAccesoSistema si el rol del usuario essuficiente para poder acceder a dicho servicio solicitado.




.

3.- El ServicioControlAccesoSistema comprobará si el usuario tiene los suficientes privilegios para

acceder a dicha funcionalidad y devolverá el resultado4.- Si el usuario pertenece a un rol con suficientes privilegios, se le permitirá el acceso a dichafuncionalidad

5.- Si el usuario pertenece a un rol que no tiene suficientes privilegios, se le denegará el acceso adicha funcionalidad

6.- El usuario quiere acceder al subsistema de validación a través del servicioServicioGestionValidación, para ello, el usuario mandará el token obtenido anteriormente quecontiene su identificación y rol.

7.- El ServicioGestionValidación previamente a concederle acceso a cualquiera de susfuncionalidades, comprueba contra el ServicioControlAccesoSistema si el rol del usuario essuficiente para poder acceder a dicho servicio solicitado.

8.- El ServicioControlAccesoSistema comprobará si el usuario tiene los suficientes privilegios paraacceder a dicha funcionalidad y devolverá el resultado

9.- Si el usuario pertenece a un rol con suficientes privilegios, se le permitirá el acceso a dichafuncionalidad


11.- El usuario quiere acceder al subsistema consolidación a través del servicioServicioGestionConsolidacion, para ello, el usuario mandará el token obtenido anteriormente quecontiene su identificación y rol.

12.- El ServicioGestionConsolidacion previamente a concederle acceso a cualquiera de susfuncionalidades, comprueba contra el ServicioControlAccesoSistema si el rol del usuario essuficiente para poder acceder a dicho servicio solicitado.

13.- El ServicioControlAccesoSistema comprobará si el usuario tiene los suficientes privilegios paraacceder a dicha funcionalidad y devolverá el resultado

14.- Si el usuario pertenece a un rol con suficientes privilegios, se le permitirá el acceso a dichafuncionalidad


- Diagrama de Secuencia de visualizaciones.

o CASO DE USO: Visualización de planes DUC-CON-4.1

o CASO DE USO: Visualización de trámites DUC-CON-4.2

o CASO DE USO: Visualizador de documentos propios del trámite DUC-CON-4.2.1o CASO DE USO: Visualización de determinaciones DUC-CON-4.2.2

o CASO DE USO: Visualizador de valores de referencia DUC-CON-4.2.2.1

o CASO DE USO: Visualizador de grupos de aplicación DUC-CON-4.2.2.2

o CASO DE USO: Visualizador de regulación específica DUC-CON-4.2.2.3

o CASO DE USO: Visualizador de determinaciones reguladoras DUC-CON-4.2.2.4

o CASO DE USO: Visualizador de operaciones entre determinaciones DUC-CON-4.2.2.5




.

o CASO DE USO: Visualizador de documentos de determinaciones DUC-CON-

4.2.2.6o CASO DE USO: Visualizador de aplicaciones de determinaciones DUC-CON-4.2.2.7

o CASO DE USO: Visualización de entidades DUC-CON-4.2.3

o CASO DE USO: Visualizador de adscripciones DUC-CON-4.2.3.1

o CASO DE USO: Visualizador de geometría DUC-CON-4.2.3.2

o CASO DE USO: Visualizador de la aplicación de determinaciones DUC-CON-4.2.3.3

o CASO DE USO: Visualizador de casos DUC-CON-4.2.3.3.1

o CASO DE USO: Visualizador de regímenes DUC-CON-4.2.3.3.2

o CASO DE USO: Visualizador de regímenes específicos DUC-CON-4.2.3.3.3o CASO DE USO: Visualizador de operaciones entre entidades DUC-CON-4.2.3.4

o CASO DE USO: Visualizador de documentos de entidades DUC-CON-4.2.3.5

o CASO DE USO: Visualizador de FIP DUC-VAL-9

o CASO DE USO: Visualizador de trámite DUC-VAL-9.1

o CASO DE USO: Visualizador de documentos de trámite DUC-VAL-9.2

o CASO DE USO: Visualizador de determinaciones DUC-VAL-9.3

o CASO DE USO: Visualizador de valores de referencia DUC-VAL-9.3.1

o CASO DE USO: Visualizador de grupos de aplicación DUC-VAL-9.3.2

o CASO DE USO: Visualizador de regulación específica DUC-VAL-9.3.3

o CASO DE USO: Visualizador de determinaciones reguladoras DUC-VAL-9.3.4

o CASO DE USO: Visualizador de operaciones entre determinaciones DUC-VAL-9.3.5

o CASO DE USO: Visualizador de documentos de determinaciones DUC-VAL-9.3.6

o CASO DE USO: Visualizador de aplicaciones de determinaciones DUC-VAL-9.3.7

o CASO DE USO: Visualizador de entidades DUC-VAL-9.4

o CASO DE USO: Visualizador de adscripciones DUC-VAL-9.4.1

o CASO DE USO: Visualizador de la aplicación de determinaciones DUC-VAL-

9.4.3o CASO DE USO: Visualizador de casos DUC-VAL-9.4.4

o CASO DE USO: Visualizador de regímenes DUC-VAL-9.4.5

o CASO DE USO: Visualizador de regímenes específicos DUC-VAL-9.4.6

o CASO DE USO: Visualizador de operaciones entre entidades DUC-VAL-9.4.7

o CASO DE USO: Visualizador de documentos de entidades DUC-VAL-9.4.8

o CASO DE USO: Visualización de mapas temáticos DUC-VAL-14.




.

A esta tarea solo se llega si anteriormente se ha realizado con éxito la validación de integridad.

Este flujo es el siguiente:

1.- El usuario de la aplicación inicia la validación de los contenidos.

2.- La tarea de control de planes usa el servicio de ServicioValidacion a través de la interfaz devalidaContenidos( idFip ) para iniciar un proceso de validación de los contenidos del FIP que se le

pasa como parámetro. Esta validación de contenidos incluye tanto las validaciones de planes,recintos, determinaciones, adscripciones, manuales, etc.

3.- El servicio ServicioValidacion hace uso del servicio ServicioResultadosValidacion a través de lainterfaz getValidationProcessResultObject( idFip ) para obtener el identificador de los resultados delproceso de validación que se ha creado anteriormente asociado al FIP.

4.- Se devuelve el identificador.

5.- El servicio ServicioValidacion hace uso del servicio ServicioValidacionContenidos a través de lainterfaz validaContenidos( FIP) ya que este servicio el que posee la lógica de negocio que valida loscontenidos del FIP en cuestión.

6.- El servicio ServicioValidacionContenidos realiza las distintas validaciones de planes que se handefinido en su lógica de negocio. Esta validación de contenidos incluye tanto las validaciones deplanes, recintos, determinaciones, adscripciones, manuales, etc.

7.- El servicio ServicioValidacionContenidos devuelve el resultado de la validación de contenidos enun objeto del tipo ValidationEntityResult. En este objeto están todos los requisitos que se hanvalidado y si su resultado ha sido correcto o no.

8.- Se guarda el resultado de la validación de plan asociada a ese FIP, se le da persistencia en labase de datos.

9.- Se devuelve a la tarea el resultado, si ha sido correcto o no, de la validación de los contenidos.




.

- Diagrama de creación de Planes y Trámites.

o Creación de planes DUC-CON-4.3

o Creación de trámites DUC-CON-4.4

El usuario de consola autorizado para la creación de nuevos Planes, invocará el servicio PlaNuevoBean.

1 – El primer paso para crear un Plan será crear el Ámbito del Plan, a través del interface del ámbito.

2 – Igualmente ocurre para el InstrumentoPlan, que se creará a través de su interface.

3– Se Procederá a incluir el Trámite del Plan, por lo cual lo primero es comprobar si existe dicho Plan, de noser así, se creará uno nuevo.

5 - 8 – Se creará el Ámbito de Aplicación del Trámite mediante su interface y posteriormente el ámbito y laEntidad.

Finalmente se devolverá a PlanNuevoBean, que finalizará la creación.




.

- Diagrama de Secuencia de Gestión Usuarios y Roles.

o DUC-CON-5: Gestión de usuarios y roles

o DUC-CON-5.1: Asignación

El siguiente diagrama muestra la secuencia que seguirá el caso de uso de gestión de roles yusuarios referidas a las distintas clases de diseño

Este diagrama muestra el flujo normal que se realiza para la gestión de los usuarios y los roles en elsistema. Este flujo parte del flujo anterior en el cual un usuario quiere acceder al sistema:

1.- El usuario solicita al servlet la página de gestión de usuarios y roles.

2.- El servlet llama al servicio de gestión de usuario donde comprueba las credenciales que le hamandado el usuario se comprobará si el usuario existe (modificación) o bien si se trata de un altanueva.

3.- UsuarioBean llamará a usuariofacade donde se procederá a la creación del usuario o lamodificación, y a su vez se le asignará el rol. .

4.- El finalmente si el proceso finaliza correctamente, se devolverá el usuario al listado de usuariosdel sistema de administración.




.

9.2.1 Validador.

En este apartado se detallan mediante diagramas de secuencia los distintos casos de usos delsubsistema de validación descritos en el documento de análisis (ASI).


- Diagrama de Secuencia de Control de Recepción.

o CASO DE USO: Recibir FIP DUC-VAL-1

A continuación veremos cómo se relacionan cada una de estas tareas con los servicios definidos ydesarrollados para este subsistema:




.

Este diagrama muestra el flujo normal que se realiza para el control de recepción. Este flujo es el

siguiente:1.- El usuario de la aplicación rellena el formulario de inicio de las tareas de digitalización.

2.- El usuario de la aplicación le da a continuar el proceso.

3.- La aplicación cambia de tarea y pasa a la tarea de recepción de información.

4.- El usuario de la aplicación le da a subir archivo.

5.- La aplicación se encarga de subir el fichero que el usuario se ha encargado de seleccionar alsistema.

6.- El usuario le da a desplegar el archivo que anteriormente ha subido.

7.- La tarea de recepción de información usa el servicio de Control de Recepción a través de lainterfaz de beginTransaction() para iniciar una transacción de despliegue.

8.- El servicio le devuelve el identificador de FIP temporal9.- La tarea de recepción de información usa el servicio de Control de Recepción a través de lainterfaz de copyZIP() para copiar el FIP.zip que anteriormente hemos subido al sitio adecuado.

10.- La tarea de recepción de información usa el servicio de Control de Recepción a través de lainterfaz de deployFIP() para desplegar el FIP.zip en el sistema de archivos del servidor.

11.- Si se ha producido algún error se hace un rollback para volver al estado inicial.

- Diagrama de Secuencia de nuevas validaciones

o CASO DE USO: Nuevas Validaciones DUC-VAL-11

El usuario de validación solicitará en la página jsp una nueva validación.

Se realizará una llamada al ValidacionBPMController donde este solicitará una conexión aServicioValidacionBPM para ejecutar inicioNuevoProcesoValidacion.

La conexión al nuevo proceso de validación generará una nueva instancia destartProcessInstanceByKey, donde se le pasarán las variables correspondientes a la nuevavalidación, recogidas en la página jsp inicial.

Se le devolverá a ValidaciónBPMController el resultado de la operación.




.

- Diagrama de Secuencia de Validación manual

o CASO DE USO: Validación manual DUC-VAL-8


1.- El usuario de la aplicación inicia la validación manual.

2.- La tarea de control manual usa el servicio de ValidationService a través de la interfaz devalidateManual( idFip ) para iniciar un proceso de validación manual del FIP que se le pasa comoparámetro.

3.- El servicio ValidationService hace uso del servicio ValidationResultsService a través de lainterfaz getValidationProcessResultObject( idFip ) para obtener el identificador de los resultados delproceso de validación que se ha creado anteriormente asociado al fip.

4.- Se devuelve el identificador.

5.- El servicio ValidationService hace uso del servicio ValidationManualService a través de lainterfaz validacionManual( fipAValidar, municipio ) ya que este servicio el que posee la lógica denegocio que valida los planes del fip en cuestión.

6.- El servicio ValidationManualService realiza las distintas validaciones manuales cargando losdatos que el usuario ha introducido en la plantilla de validación manual.

7.- El servicio ValidationManualService devuelve el resultado de la validación manual en un objetodel tipo ValidationEntityResult. En este objeto están todos los requisitos que se han validado y si suresultado ha sido correcto o no.

8.- Se guarda el resultado de la validación manual asociada a ese fip, se le da persistencia en labase de datos.

9.- Se devuelve a la tarea el resultado, si ha sido correcto o no, de la validación manual.




.

- Diagrama de Secuencia de Verificación de Contenido

o CASO DE USO: Validación sintáctica DUC-VAL-3

o CASO DE USO: Validación de Contenido DUC-VAL-4

o CASO DE USO: Validar Integridad DUC-VAL-7

o CASO DE USO: Verificación de vigencia del FIP de tipo 1 DUC-VAL-002

o CASO DE USO: Validar Documentos DUC-VAL-5

o CASO DE USO: Validación geométrica DUC-VAL-6

o CASO DE USO: Validación topológica DUC-VAL-15

El siguiente diagrama muestra el flujo normal que se realiza para el subsistema de verificación decontenido para la verificación de la integridad.


1.- El usuario de la aplicación inicia la validación de la integridad

2.- La tarea de validación de integridad usa el servicio de ServicioValidacion a través de la interfazde validarIntegridad() para iniciar un proceso de validación de integridad del FIP que se le pasacomo parámetro. Esta integridad incluye distintos aspectos del FIP como son: la verificación devigencia del FIP de tipo 1, la validación sintáctica, la validación de que los documentos seencuentren en el FIP.zip, etc.




.

3.- El servicio ServicioValidacion hace uso del servicio ServicioResultadosValidacion a través de la

interfaz createValidationIntegrityProcessResult(idFip) para crear un objeto para almacenar losresultados del proceso de validación de integridad asociado al FIP que se está validando

4.- El servicio ServicioValidacion hace uso del servicio ServicioValidacionIntegridad a través de lainterfaz validateIntegrityFIP( idFIP ) ya que este servicio el que posee la lógica de negocio quevalida la integridad del FIP en cuestión. Esta integridad incluye distintos aspectos del FIP como son:la verificación de vigencia del FIP de tipo 1, la validación sintáctica, la validación de que losdocumentos se encuentren en el FIP.zip, etc.

5.- El servicio ServicioValidacionIntegridad devuelve el resultado de la validación de la integridad enun objeto del tipo ValidationEntityResult. En este objeto están todos los requisitos que se hanvalidado y si su resultado ha sido correcto o no.

6.- El servicio ServicioValidacion hace uso del servicio ServicioResultadosValidación a través de lainterfaz getValidationIntegrityProcessResultObject( idFip ) para obtener el identificador del resultadodel proceso de validación que se ha creado anteriormente asociado al FIP7.- Se devuelve el identificador

8.- Se guarda el resultado de la validación de integridad asociada a ese FIP, se le da persistencia enla base de datos.

9.- El servicio ServicioValidacion devuelve a la tarea de validación de Integridad el resultado de lavalidación de integridad, es decir, si ha sido correcta o no, para que la tarea actúe de formaoportuna dependiendo de si el FIP es integro o no. Si el resultado ha sido satisfactorio, es decir, elFIP es íntegro, se dan los pasos 10, 11, 12 y 13. En caso que el FIP no sea integro, se da el caso14

10.- La tarea de validación de integridad usa el servicio de GestionIntroduccionFIPenSistema através de la interfaz de saveXMLFileToDatabase( idFIPTrans, unitNamePersistence ) para volcar

en la base de datos de validación el FIP ya que sabemos que es integro, para que posteriormentese puedan realizar el resto de validaciones.

11.- La tarea de validación de integridad usa el servicio de GestionIntroduccionFIPenSistema através de la interfaz de commitTransaction( idFIPTrans, idFIP ) para dar por concluida esatransacción de volcado en las bases de datos y borrar todos aquellos archivos temporales que ya noson necesarios

12.- La tarea de validación de integridad pasa el control al resto de tareas de validación (queveremos en sucesivos diagramas)

13.- Si la validación de integridad no fue satisfactoria, no se sigue con el resto del proceso devalidación ya que no se puede volcar en base de datos el FIP al no ser integro, se pasa a la tarea derecopilación de informes.




.

- Diagrama de Secuencia de Recopilación de Informes.

o CASO DE USO: Informes FIP DUC-VAL-10

A continuación veremos cómo se relaciona esta tarea con los servicios definidos y desarrolladospara este subsistema:

Este diagrama muestra el flujo normal que se realiza para el subsistema de recopilación deinformes. Este flujo es el siguiente:

1.- El usuario de la aplicación inicia el proceso de recopilación de informes.

2.- La tarea de recopilación de informes usa el servicio de ServicioResultadosValidación a través dela interfaz de getProcessValidationErrorElements( idFip ) para recopilar todos los errores de losdistintos procesos de validación que se han realizado.

3.- Se devuelve el objeto que contiene los errores de los distintos procesos de validación.

4.- El usuario de la aplicación pide que se muestre por pantalla todos los informes, tanto sicontienen errores como si no.




.

5.- La tarea de recopilación de informes usa el servicio de ServicioResultadosValidación a través de

la interfaz de getValidationProcessResultObject( idFip )para recopilar todos los informes de losdistintos procesos de validación que se han realizado, tanto si tienen errores como si no.

6.- Se devuelve el objeto que contiene los informes de los distintos procesos de validación, tanto sitienen error como si no.

7.- El usuario de la aplicación pide que se muestre por un fichero PDF todos los informes, tanto sicontienen errores como si no.

8.- La tarea de recopilación de informes usa el servicio de ServicioGestionInformesValidación através de la interfaz de getPDFCompleteByFIP(FIP, visor) para recopilar todos los informes de losdistintos procesos de validación que se han realizado, tanto si tienen errores como si no en unfichero del tipo PDF.

9.- El servicio de ServicioGestionInformesValidacion usa el servicio de ServicioResultadosValidación

a través de la interfaz de getValidationProcessResultObject( idFip )para recopilar todos los informesde los distintos procesos de validación que se han realizado, tanto si tienen errores como si no.

10.- Se devuelve el objeto que contiene los informes de los distintos procesos de validación, tanto sitienen error como si no.

11.- Se devuelve el PDF que contiene los informes de los distintos procesos de validación, tanto sitienen error como si no.

12.- El usuario de la aplicación pide que se muestre por un fichero PDF todos los informes, perosolo aquellos que contienen requisitos con errores.

13.- La tarea de recopilación de informes usa el servicio de ServicioGestionInformesValidacion através de la interfaz de getPDFErrorsByFIP(FIP, visor) para recopilar todos los informes de losdistintos procesos de validación que se han realizado que tienen errores en un fichero del tipo PDF.

14.- El servicio de ServicioGestionInformesValidacion usa el servicio deServicioResultadosValidación a través de la interfaz de getEntityValidationErrorElements (idFip,entityType) para recopilar todos los informes de los distintos procesos de validación que tienenerrores.

15.- Se devuelve el objeto que contiene los informes de los distintos procesos de validación quetienen errores.

16.- Se devuelve el PDF que contiene los informes de los distintos procesos de validación quetienen errores.




.

- Diagrama de Secuencia de Visualizador FIP en Validación.

o CASO DE USO: Visualizador de FIP DUC-VAL-9

o CASO DE USO: Previsualización de Refundido DUC-VAL-12

A continuación veremos cómo se relaciona esta tarea con los servicios definidos y desarrolladospara esta funcionalidad:

Este diagrama muestra el flujo normal que se realiza para la visualización de FIP. Este flujo es elsiguiente:

1.- El usuario de la aplicación pide la visualización previa del refundido. Se llama al servicio deServicioPrevisualizacionRefundido que generará un refundido previo con el resultado de refundir elplan que ya ha sido validado y esta correcto con el FIP que se encuentra en el registro de




.

planeamiento para que así el usuario pueda ver como quedaría el plan refundido una vez que lo

consolide y lo refunda en el registro de planeamiento municipal.2.- Se devuelve el resultado de la visualización del prerefundido.

3.- El usuario de la aplicación solicita la visualización de mapas temáticos. Se llama al servicio deServicioVisualizacionFIP que generará el mapa temático solicitado.

4.- Se devuelve el mapa temático.

5.- El usuario de la aplicación solicita la visualización de los trámites del FIP validado. Se llama alservicio de ServicioVisualizacionFIP que se encargará de recuperar la información del trámitevalidado para posteriormente mostrársela al usuario

6.- Se devuelve el trámite con la información.

7.- El usuario de la aplicación solicita la visualización de los documentos del trámite del FIPvalidado. Se llama al servicio de ServicioVisualizacionFIP que se encargará de recuperar lainformación de los documentos del trámite validado para posteriormente mostrársela al usuario8.- Se devuelve el documento del trámite con la información solicitada.

9.- El usuario de la aplicación solicita la visualización de las determinaciones del FIP validado. Sellama al servicio de ServicioVisualizacionFIP que se encargará de recuperar la información lasdeterminaciones del FIP validado para posteriormente mostrársela al usuario

10.- Se devuelve las determinaciones con la información solicitada.

11.- El usuario de la aplicación solicita la visualización de los recintos del FIP validado. Se llama alservicio de ServicioVisualizacionFIP que se encargará de recuperar la información de los recintosdel FIPvalidado para posteriormente mostrársela al usuario

12.- Se devuelve los recintos con la información solicitada.

- Diagrama de Secuencia de Certificados Digitales y Firma Digital

o CASO DE USO: Firma digital validación FIP DUC-VAL-13

Este diagrama muestra como un proceso de validación de un FIP, se firma Digitalmente.

Al finalizar el proceso de Validación, si ha finalizado correctamente, se llamará a la claseCertificadosDigitales, que procederá a marchar el documento con una firma MD5, como Indicandoque el FIP tal cual se encuentra en ese instante, es correcto. Si se produjera una alteración en este,el resultado de la firma MD5 sería diferente.




.

o CASO DE USO: Validación por Certificado Digital CON_01

El usuario Intenta Acceder mediante un certificado digital; El sistema procederá a comprobar de quétipo de certificado se trata. Actualmente se contempla DNI-e y Certificado de FNMT.

Si la validación del certificado es válida, se permitirá al usuario acceder al sistema.




.

9.2.2 Consolidador.

En este apartado se detallan mediante diagramas de secuencia los distintos casos de usos delsubsistema de consolidación descritos en el documento de análisis (ASI).


- Diagrama de Secuencia de Iniciar Consolidación (DUC-CSD-2)

A continuación veremos cómo se relaciona esta tarea con los servicios definidos ydesarrollados para consolidación:

Este diagrama muestra el flujo normal que se realiza para el subsistema de consolidación una vezque se ha pasado el proceso de validación. Este flujo es el siguiente:

1.- El usuario de la aplicación inicia el proceso de consolidación.

2.- Si la validación había sido correcta, se procede con la consolidación. Para ello, la tarea deconsolidación usa el servicio de ServicioConsolidacion a través de la interfaz de consolidoFIP(idFIP)para volcar en la base de datos del registro de planeamiento el FIP ya que sabemos que es integroy está validado. Internamente se realiza un proceso de volcado del FIP de validación (que se




.

encuentra en la base de datos de validación) a la base de datos del registro de planeamiento

municipal para que empiece a formar parte el FIP del registro. Este proceso será descrito en elsiguiente diagrama de secuencia.

3.- Se termina la consolidación

4.- Como la validación no era correcta, no se realiza la consolidación.

- Diagrama de Secuencia de Proceso de Consolidación.

o CASO DE USO: Carga de trámite DUC-CSD-2

o CASO DE USO: Carga del Documentos del Trámite DUC-CSD-2.1

o CASO DE USO: Carga de las Entidades DUC-CSD-2.2

o CASO DE USO: Carga de las Determinaciones DUC-CSD-2.3o CASO DE USO: Carga de las Condiciones Urbanísticas DUC-CSD-2.4

o CASO DE USO: Carga de las Operaciones DUC-CSD-2.5

o CASO DE USO: Carga de las Adscripciones DUC-CSD-2.6

o CASO DE USO: Carga de los Casos DUC-CSD-2.7

o CASO DE USO: Creación de metadatos DUC- URBR_18.1

Anteriormente se ha explicado cómo se lleva a cabo la tarea de consolidación. En este apartadoveremos más en detalle que es lo que ocurre durante ese proceso de consolidación y como un FIPes consolidado en la base de datos del registro de planeamiento a partir de los datos del FIP que se

encuentra en la base de datos de validación.




.

Este diagrama muestra el flujo de los procesos que se llevan a cabo para consolidar un FIP en labase de datos del registro de planeamiento municipal (BD RPM). Estos pasos son los siguientes:

1.- El ServicioConsolidacion recibe por parte de un cliente usuario que debe iniciar la consolidación

de un FIP en concreto que se pasa como parámetro.2.- Lo primero que debe hacer el ServicioConsolidacion es obtener todos los datos de ese FIP enconcreto que se pretende consolidar. Para ello deberá localizar esos datos del FIP en la base dedatos de validación.

3.- Los datos del FIP a consolidar son devueltos

4.- Se inicia el proceso de carga del trámite de FIP obtenido en la BD de RPM. Al ser bases dedatos con modelos de datos distintos, habrá que ir haciendo transformaciones en los modelos dedatos para ir consolidando los distintos elementos de los que se compone el trámite del FIP.

5.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos deRPM los documentos del trámite, haciendo previamente las transformaciones pertinentes en el




.

modelo de datos para adaptarlo del modelo de datos de validación al modelo de datos del registro

de planeamiento municipal.6.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos deRPM las entidades del trámite, haciendo previamente las transformaciones pertinentes en el modelode datos para adaptarlo del modelo de datos de validación al modelo de datos del registro deplaneamiento municipal.

7.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos deRPM las determinaciones del trámite, haciendo previamente las transformaciones pertinentes en elmodelo de datos para adaptarlo del modelo de datos de validación al modelo de datos del registrode planeamiento municipal.

8.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos deRPM las adscripciones del trámite, haciendo previamente las transformaciones pertinentes en elmodelo de datos para adaptarlo del modelo de datos de validación al modelo de datos del registrode planeamiento municipal.9.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos deRPM las condiciones urbanísticas del trámite, haciendo previamente las transformacionespertinentes en el modelo de datos para adaptarlo del modelo de datos de validación al modelo dedatos del registro de planeamiento municipal.

10.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos deRPM los casos del trámite, haciendo previamente las transformaciones pertinentes en el modelo dedatos para adaptarlo del modelo de datos de validación al modelo de datos del registro deplaneamiento municipal.

11.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos deRPM las operaciones del trámite, haciendo previamente las transformaciones pertinentes en elmodelo de datos para adaptarlo del modelo de datos de validación al modelo de datos del registrode planeamiento municipal.

12.- Una vez que el proceso de consolidación ha finalizado, se le informa al usuario del éxito de laconsolidación o de si se ha producido algún error o excepción.




.

9.2.3 Motor de Refundido.

- Extracción de los últimos trámites de cada plan

o CASO DE USO: Extracción de los últimos trámites de cada plan DUC-REF-1.3.2

Esta caso de uso se contempla en la consola RPM, donde al acceder al refundido,se presentará un árbol de trámites, donde el usuario podrá ir rellenando medianteun comando JSon la lista de los trámites que se desea refundir.

- Ejecución del proceso de refundido

o CASO DE USO: Ejecución del proceso de refundido DUC-REF-1

o CASO DE USO: Validaciones previas al proceso de refundido DUC-REF-1.2o CASO DE USO: Obtención de la lista ordenada de planes refundibles DUC-REF-1.3.1

o CASO DE USO: Algoritmo de refundido DUC-REF-1.4

La ejecución del proceso de Refundido completo, la iniciará un usuario autorizado.

Pasará el código de Ámbito a refundir.

El proceso en términos generales seguirá la siguiente secuencia:

1- El usuario lanza el proceso de refundido, indicando el Ámbito a Refundir.

2- Se confecciona una lista con los Planes a refundir para el Ámbito indicado.




.

3- Se cargan los datos desde la base de datos hasta los objetos relacionales para que el

proceso de refundido los manipule.4- Se realizan las operaciones de Recintos y operaciones gráficas.

5- Se comprueban los grupos.

6- Con los datos aportados se genera el fichero FIP2

7- Para restaurar la base de datos a su estado inicial, se ejecuta un Rollback.

- Eliminación de Determinaciones y Entidades Operadoras.

o CASO DE USO: Eliminación de determinaciones y entidades operadoras DUC-REF-1.5.1

o CASO DE USO Eliminación de carpetas vacías en los árboles de datos DUC-

REF-1.5.2

1- Una vez finalizado el refundido, la clase RefundidoBean, invocará al servicio deeliminarOperadores en la clase clsMain.

2- clsMain recuperará de los datos cargados en memoria en la clase clsDatos, el listado de losTrámites a refundir.

3- clsMain recorrerá el lisado, eliminando las Entidades y las Determinaciones Operadas.




.

- Exportación a fichero FIP tipo 2

o Generación del FIP de tipo 2 del trámite refundido DUC-REF-2

2 – Al finalizar el proceso de refundido, el resultado se exportará a un fichero FIP tipo 2, con lo cualRefundidoBean, llamará a ServicioExportFIP2.

2.1 - ServicioExportFIP2. Consultará los datos del Trámite a través de su interface. Se montarán losdatos obtenidos en una estructura XML que será devuelta a RefundidoBean en forma de ficheroFIP.xml.




.

- DUC-REF-1.4: Algoritmo de refundido

o CASO DE USO: Obtención de la lista ordenada de planes refundibles DUC-REF-1.3.1

El algoritmo de Refundido, se basa en un sistema de 4 bucles anidados donde se decide elorden de las operaciones. Dentro de un bucle con el listado de trámites irá iterando entre loselementos de Modificación de Plan, otro bucle para Desarrollo, otro para suspensión.

Finalmente se realizará la sustitución.




.

- DUC-REF-4: Ejecución del proceso de refundido parcial

Se ejecuta el algoritmo de generación del plan refundido sólo para determinados planes escogidospor el usuario que ejecuta la operación de refundido.

El algoritmo será el mismo de una ejecución completa, excepto por los primeros pasos. Ya no seránecesario obtener de base de datos los planes en una lista ordenada. Será el proceso de refundidoel encargado de ordenar los planes que el usuario le ha facilitado para refundir.

9.2.4 Visualizador del RPM.

En este apartado se detallan mediante diagramas de secuencia los distintos casos de usos delsubsistema de visualizador del Registro de Planeamiento Municipal (RPM) descritos en eldocumento de análisis (ASI).


A los casos de uso a los que da respuesta los siguientes diagramas son los siguientes:

o DUC-CON-2: Visualización de árbol de planes

o DUC-CON-4.1: Visualización de planes

o DUC-CON-4.2: Visualización de trámites

o DUC-CON-4.2.1: Visualizador de documentos propios del trámite

o DUC-CON-4.2.2: Visualización de determinaciones

o DUC-CON-4.2.2.1: Visualizador de valores de referencia




.

o DUC-CON -4.2.2.2: Visualizador de grupos de aplicación

o DUC-CON -4.2.2.3: Visualizador de regulación específica

o DUC-CON -4.2.2.4: Visualizador de determinaciones reguladoras

o DUC-CON -4.2.2.5: Visualizador de operaciones entre determinaciones

o DUC-CON -4.2.2.6: Visualizador de documentos de determinaciones

o DUC-CON -4.2.2.7: Visualizador de aplicaciones de determinaciones

o DUC-CON-4.2.3: Visualización de entidades

o DUC-CON -4.2.3.1: Visualizador de adscripciones

o DUC-CON -4.2.3.2: Visualizador de geometría

o DUC-CON -4.2.3.3: Visualizador de la aplicación de determinaciones

o DUC-CON -4.2.3.3.1: Visualizador de casoso DUC-CON -4.2.3.3.2: Visualizador de regímenes

o DUC-CON -4.2.3.3.3: Visualizador de regímenes específicos

o DUC-CON -4.2.3.5: Visualizador de documentos de entidades

- Diagrama de Secuencia de Visualización de Árbol de Planes (DUC-CON-2)

Este diagrama muestra el flujo de los procesos que se llevan a cabo para visualizar el árbol deplanes por parte del usuario. Estos pasos son los siguientes:

1.- El usuario solicita ver el árbol de planes, para ello llama al controlador JSF, la claseArbolPlanesJSFController que será la encarga de llamar a la clase que tiene la lógica de negociopara recuperar esos datos, y una vez con los datos generar la vista correspondiente.

2.- La clase ArbolPlanesJSFController solicita los datos para construir el árbol de planes al servicioServicioGestiónArbolPlanes




.

3.- El servicio ServicioGestiónArbolPlanes tendrá la lógica de negocio que le permite recuperar

estos datos que son enviados al controller JSF que se los solicitó.4.- Una vez que el controller recibe los datos, de acuerdo con la vista, sacará por pantalla para elusuario el árbol de planes.

- Diagrama de Secuencia Visualización de Planes (DUC-CON-4.1)

Este diagrama muestra el flujo de los procesos que se llevan a cabo para los datos asociados a losplanes por parte del usuario. Estos pasos son los siguientes:

1.- El usuario solicita ver los datos asociados a los planes, para ello llama al controlador JSF, laclase PlanesJSFController que será la encarga de llamar a la clase que tiene la lógica de negociopara recuperar esos datos, y una vez con los datos generar la vista correspondiente.

2.- La clase PlanesJSFController solicita los datos para ver los datos asociados a los planes al

servicio ServicioGestionPlanes3.- El servicio ServicioGestionPlanes tendrá la lógica de negocio que le permite recuperar estosdatos que son enviados al controller JSF que se los solicitó.

4.- Una vez que el controller recibe los datos, de acuerdo con la vista, sacará por pantalla para elusuario la información de los planes.




.

- Diagrama de Secuencia Visualización de Trámites (DUC-CON-4.2)

1.- El usuario solicita ver los documentos del trámite, para ello llama al controlador JSF, la claseTramitesJSFController que será la encarga de llamar a la clase que tiene la lógica de negocio pararecuperar esos datos, y una vez con los datos generar la vista correspondiente.




.

2.- La clase TramitesJSFController solicita los datos para ver los documentos del trámite al servicio

ServicioGestiónTramites3.- El servicio ServicioGestiónTramites tendrá la lógica de negocio que le permite recuperar estosdatos que son enviados al controller JSF que se los solicitó.

4.- Una vez que el controller recibe los datos, de acuerdo con la vista, sacará por pantalla para elusuario la información de los documentos del trámite.

5.- El usuario solicita ver las determinaciones del trámite, para ello llama al controlador JSF, la claseTramitesJSFController que será la encarga de llamar a la clase que tiene la lógica de negocio pararecuperar esos datos, y una vez con los datos generar la vista correspondiente.

6.- La clase TramitesJSFController solicita los datos para ver las determinaciones del trámite alservicio ServicioGestiónTramites

7.- El servicio ServicioGestiónTramites tendrá la lógica de negocio que le permite recuperar estos

datos que son enviados al controller JSF que se los solicitó.8.- Una vez que el controller recibe los datos, de acuerdo con la vista, sacará por pantalla para elusuario la información de las determinaciones del trámite.

9.- El usuario solicita ver las entidades del trámite, para ello llama al controlador JSF, la claseTramitesJSFController que será la encarga de llamar a la clase que tiene la lógica de negocio pararecuperar esos datos, y una vez con los datos generar la vista correspondiente.

10.- La clase TramitesJSFController solicita los datos para ver las entidades del trámite al servicioServicioGestiónTramites

11.- El servicio ServicioGestiónTramites tendrá la lógica de negocio que le permite recuperar estosdatos que son enviados al controller JSF que se los solicitó.

12.- Una vez que el controller recibe los datos, de acuerdo con la vista, sacará por pantalla para el

usuario la información de las entidades del trámite.

9.2.5 Servicios Web.

En este apartado se detallan mediante diagramas de secuencia los distintos casos de usos delsubsistema de servicios web descritos en el documento de análisis (ASI).


- Diagrama de Secuencia del Servicio de consultas del refundido (SRV_1.3)

o CASO DE USO: Consulta a partir de un polígono DUC-SRV-1.3.2o CASO DE USO: Consulta a partir de metadatos DUC-SRV-1.3.3

o CASO DE USO: Consulta del estado del registro DUC-SRV-1.3.4

A continuación veremos cómo se relaciona un cliente que quiere hacer uso de este servicio web conel propio servicio web a través de un diagrama de secuencia:




.




.

Este diagrama muestra el flujo normal de petición de un cliente para explotar este servicio web. Este

flujo es el siguiente:1.- El cliente del servicio web solicita al servicio web la realización de una consulta alfanumérica delos datos contenidos en el RPM

2.- El servicio web consulta a la base de datos de refundido para obtener esa información solicitada.

3.- Se obtiene una respuesta de la base de datos de que FIPs se encuentran almacenados en ella.

4.- El servicio web responde al cliente pasándole la información alfanumérica requerida de los datoscontenidos en el RPM.

5.- El cliente del servicio web solicita al servicio web que le proporcione la información del árbol deregistro, para ello pasa como parámetro el identificador del FIP. Este identificador lo puede coger dela petición anterior del listado de todos los FIPs que existen en base de datos.

6.- El servicio web consulta en base de datos para obtener la información específica del FIPsolicitado.7.- Se obtiene una respuesta de la base de datos de los datos del FIP solicitado

8.- El servicio web responde al cliente pasándole un String que contiene en formato XML el árbol derefundido del FIP solicitado.

9,10,11,12.- El cliente del servicio web solicita al servicio web información del trámite de un planseleccionado, el servicio web deberá ir a buscar esta información a la base de datos del registro deplaneamiento y le devolverá al cliente dicha información.

13,14,15,16.- El cliente del servicio web solicita al servicio web información de un plan específico, elservicio web deberá ir a buscar esta información a la base de datos del registro de planeamiento y ledevolverá al cliente dicha información.

17,18,19,20.- El cliente del servicio web solicita al servicio web información de los documentos de

un plan seleccionado, el servicio web deberá ir a buscar esta información a la base de datos delregistro de planeamiento y le devolverá al cliente dicha información.

21,22,23,24.- El cliente del servicio web solicita al servicio web información de a partir de lascoordenadas de un punto, el servicio web devolverá al cliente dicha información que será lasentidades por capa, registro de planeamiento, etc. de la coordenada puntual seleccionada.

24,25,26,27.- El cliente del servicio web solicita al servicio web información de a partir de lageometría de un polígono enviado en formato WKT, el servicio web devolverá al cliente dichainformación que será las entidades por capa, registro de planeamiento, etc. del polígonoseleccionado.

28,29,30,31.- El cliente del servicio web solicita al servicio web información de los metadatosasociados a los elementos presentes en el registro, el servicio web devolverá al cliente dichainformación que será las entidades por capa, registro de planeamiento, etc.

32,33,34,35.- El cliente del servicio web solicita al servicio web información del estado del registroque llevará un registro del diario de operaciones del RPM con un almacén histórico de las accionesllevadas a cabo, el servicio web devolverá al cliente dicha información.




.

- Diagrama de Secuencia del Servicio de Emisor de Fichas Urbanísticas.

o CASO DE USO: Emisor de fichas urbanísticas DUC-SRV-1.1

o CASO DE USO: Consulta a partir de un punto DUC-SRV-1.3.1


Este diagrama muestra el flujo normal de petición de un cliente para explotar este servicio web. Esteflujo es el siguiente:

1.- El cliente del servicio web solicita al servicio web una petición de ficha, para ello le pasa comoparámetros las coordenadas del punto sobre el cual quiere obtener la información.

2.- El servicio web, al ser asíncrono, devuelve al cliente la ejecución de su propia tarea, liberándoloy sigue su ejecución.

3.- El servicio web solicita al servidor de mapas las características (capas) que posee.

4.- El servidor de mapas devuelve las características solicitadas.

5.- El servicio web solicita al servidor de mapas los mapas correspondientes a las capas quepertenecen al visor (municipio) solicitado por el cliente y centrados en las coordenadas pasadas porparámetros por el cliente.

6.- El servidor de mapas devuelve los mapas solicitados.

7.- El servicio web consulta en base de datos para obtener la información asociada de la base dedatos de registro de planeamiento municipal asociada a las coordenadas solicitadas y a las capasdisponibles en el servidor de mapas.




.

8.- Se obtiene una respuesta de la base de datos de los datos solicitados.

9.- El servicio web pasa toda la información recopilada al servicio de ServicioGeneracionFichas paraque este se encargue de generar un PDF formateado con toda esta información.

10.- El servicio devuelve el PDF generado.

- Diagrama de Secuencia del Servicio de Búsquedas (DUC-SRV-1.4)

o CASO DE USO: Búsqueda por callejero DUC-SRV-1.4.1

o CASO DE USO: Búsqueda por topónimos DUC-SRV-1.4.2

o CASO DE USO: Búsqueda por referencia catastral DUC-SRV-1.4.3

o CASO DE USO: Búsqueda por datos urbanísticos DUC-SRV-1.4.4

El servicio de búsqueda es un servicio genérico que engloba tanto búsquedas por callejero, portopónimos, por referencia catastral como por otros datos urbanísticos.Vamos a ir viendo algunos ejemplos de estas búsquedas

A continuación veremos cómo se relaciona un cliente que quiere hacer uso del servicio de consultasde callejero a través de un diagrama de secuencia:




.


1.- El cliente del servicio web solicita al servicio web la lista de todas las provincias.




.

2, 3, 4.- El servicio web hace una llamada al servicio web de catastro solicitándole la información

que requiere el cliente web y cuando el servicio web de catastro responde, esta respuesta se pasaal cliente.

5.- El cliente del servicio web solicita al servicio web la lista de todos los municipios de la provinciaque le pasa por parámetros.

6, 7, 8.- El servicio web hace una llamada al servicio web de catastro solicitándole la informaciónque requiere el cliente web y cuando el servicio web de catastro responde, esta respuesta se pasaal cliente.

9.- El cliente del servicio web solicita al servicio web el callejero de un municipio (y provincia) quepasa por parámetros.

10, 11, 12.- El servicio web hace una llamada al servicio web de catastro solicitándole la informaciónque requiere el cliente web y cuando el servicio web de catastro responde, esta respuesta se pasa

al cliente.13.- El cliente del servicio web solicita al servicio web el número de una vía de un municipio quepasa por parámetros.


17.- El cliente del servicio web solicita al servicio web la información catastral no protegida de unpolígono y parcela de un municipio que pasa por parámetros.


- Diagrama de Secuencia del consulta (DUC-SRV-1.2)

o CASO DE USO: Consulta de planes DUC-SRV-1.2.1




.

1 - El cliente del servicio web solicita al servicio web la lista de consulta de planes.

2 – Los servicios web estadoRegistro, IdAmbito, PlanesPadre, PlanesHijo y planesFromNombreconsulta a Base de datos mediante la interface Facade y monta el trámite resultado de la consulta.Procediendo posteriormente a su devolución al cliente del servicio web

o CASO DE USO: Consulta de trámites DUC-SRV-1.2.2

1 - El cliente del servicio web solicita al servicio web la lista de consulta de Trámites.

2 – Los servicios web determinacionesPadre, DeterminacionesHija, entidadesFromClave yentidadesFromNombre consulta a Base de datos mediante la interface Facade y monta el trámiteresultado de la consulta. Procediendo posteriormente a su devolución al cliente del servicio web

o CASO DE USO: Consulta de documentos DUC-SRV-1.2.3

1 - El cliente del servicio web solicita al servicio web el listado de documentos.

2 – El servicio web URLDoc consulta a Base de datos mediante la interface Facade y procede a ladevolución de los documentos al cliente del servicio web.




.

A continuación veremos cómo se relaciona un cliente que quiere hacer uso del servicio de consultas

por referencia catastral a través de un diagrama de secuencia (DUC-SRV-1.4.3):

1.- El cliente del servicio web solicita al servicio web información catastral no protegida de unareferencia catastral que pasa por parámetros.

2, 3, 4.- El servicio web hace una llamada al servicio web de catastro solicitándole la información

que requiere el cliente web y cuando el servicio web de catastro responde, esta respuesta se pasaal cliente.

5.- El cliente del servicio web solicita al servicio web las coordenadas geográficas de un inmueble apartir de su referencia catastral que se pasa como parámetros.


9.- El cliente del servicio web solicita al servicio web la referencia catastral de un inmueble pasandocomo parámetros las coordenadas de éste.




.

10, 111, 12.- El servicio web hace una llamada al servicio web de catastro solicitándole la

información que requiere el cliente web y cuando el servicio web de catastro responde, estarespuesta se pasa al cliente.

- Diagrama de Secuencia Servicio de Petición y Descarga de FIP tipo 1

o CASO DE USO: Formulario de petición y descarga de FIP de tipo 1 DUC-SRV-3



1.- El cliente del servicio web solicita al servicio web que le proporcione la información del árbol deregistro, es decir, todos los municipios y su identificador de FIP tipo 1 más actual que tenga.

2.- El servicio web solicita al servlet de generación de FIP tipo 1, la creación del fichero FIP1

3.- El servlet llama al servicio SolicitudDescargaFIP1 que será el encargado de acceder a BD y

recopilar y presentar en forma de fichero xml la información del fip7.- La base de datos devuelve al servicio web el FIP tipo 1 solicitado.

8.- El servicio web devuelve al cliente en la URL para descargárselo.




.

- Diagrama de Secuencia del Servidor de Mapas WMS (DUC-SRV-001.1)

o CASO DE USO: Servidor WMS DUC-SRV-001.1

o CASO DE USO: Servidor de mapas DUC-SRV-2

o CASO DE USO: Pre construcción y tileado de mapas DUC-SRV-2.1.3



1.- El cliente del servicio web solicita al servidor de mapas obtener una descripción de los mapasofrecidos por el servidor.

2.- El servidor de mapas responde a la petición del cliente.

3.- El cliente del servicio web solicita al servidor de mapas obtener un mapa ofrecido por el servidor.





.

5.- El cliente del servicio web solicita al servidor de mapas consultar cierta información limitada

sobre las entidades mostradas en el mapa.6.- El servidor de mapas responde a la petición del cliente.

7.- El cliente del servicio web solicita al servidor de mapas realiza la petición de consulta decaracterísticas.


- Diagrama de Secuencia del Servidor .

o CASO DE USO: Servidor WFS DUC-SRV-2.2





.

Este diagrama muestra el flujo normal de petición de un cliente para explotar este servicio web. Este

flujo es el siguiente:1.- El cliente del servicio web solicita al servidor WFS consultar cierta información limitada sobre lasentidades mostradas en el mapa.

2.- El servidorWFS responde a la petición del cliente.

3.- El cliente del servicio web solicita al servidor WFS obtener una descripción de las capacidadesofrecidos por el servidor.

4.- El servidor WFS responde a la petición del cliente.

5.- El cliente del servicio web solicita al servidor WFS obtener una descripción de los tipos decaracterísticas ofrecidos por el servidor.


7.- El cliente del servicio web solicita al servidor WFS una transacción (esta puede ser insertar,editar, eliminar, etc) de los datos proporcionados por el servidor.


Los siguientes casos de uso:

o CASO DE USO: Administración de simbologías DUC-SRV-2.1.4

o CASO DE USO: Administración de capas DUC-SRV-2.5

o CASO DE USO: ÁMBITO DE APLICACIÓN DUC-SRV-2.5.1

o CASO DE USO: CLASES DE SUELO DUC-SRV-2.5.2

o CASO DE USO: CATEGORIAS DUC-SRV-2.5.3

o CASO DE USO: ZONAS DUC-SRV-2.5.4o CASO DE USO: GESTION DUC-SRV-2.5.5

o CASO DE USO: SISTEMAS DUC-SRV-2.5.6

o CASO DE USO: PROTECCIONES DUC-SRV-2.5.7

o CASO DE USO: AFECCIONES DUC-SRV-2.5.8

o CASO DE USO: RESERVAS DUC-SRV-2.5.9

o CASO DE USO: ACCIONES DUC-SRV-2.5.10

o CASO DE USO: Configuración y tunning de servicios DUC-SRV-2.6

o CASO DE USO: Servicios de mapas de planeamiento refundido SRV_2.3

o CASO DE USO: Servicios de mapas de planeamiento en tramitación SRV_2.4

o CASO DE USO: Sistemas de referencia utilizados SRV_2.7

Quedarán cubiertos mediante la configuración de geoserver.




.

9.2.6 Visor Web.

DUC-WEB-1: Configuración y administración de contenidos

Este caso de uso estará basado en tecnología Ajax, donde el usuario podrá personalizar el visor.

Esta personalización se realizará mediante el uso de cookies y modificación del fichero XML queprovee de información al Visor.

DUC-WEB-2: Visualización de capas

La visualización de capas ser controlará mediante Ajax, modificando la visibilidad de estas medianteeventos JavaScript/Ajax.

DUC-WEB-3: Navegación

La navegación se controlará mediante Ajax, Aportando al Visor controles gráficos como flechaspara la navegación y posicionamiento.

DUC-WEB-3.1: Zoom In

El Zoom in es un control Ajax, que gestionará las capas para que simule una aproximación.

DUC-WEB-3.2: Zoom Out

El Zoom in es un control Ajax, que gestionará las capas para que simule un alejamiento.

DUC-WEB-3.3: Desplazamientos

Los desplazamientos se controlará mediante Ajax, modificando la visibilidad de estas medianteeventos JavaScript/Ajax y elementos gráficos como flechas y punteros.

DUC-WEB-4: Control de Capas

El control de capas se gestionará mediante Ajax, modificando la visibilidad de estas medianteeventos JavaScript/Ajax.

DUC-WEB-5: Obtención de información

La obtención de información será mediante la invocación por parte del visor a servicios web.




.

El visor web lanzará una solicitud de información al servicio web correspondiente.

El servicio web devolverá un XML con la información solicitada.

DUC-WEB-5.1: Obtención de información de datos del planeamiento refundido

Igual que en el apartado anterior, el visor web lanzará una solicitud de información al servicio webde datos de planeamiento.


DUC-WEB-5.2: Obtención de información de datos del RPM


El servicio web consultará la base de datos RPM


DUC-WEB-5.3: Obtención de información de datos del planeamiento de tramitación



DUC-WEB-6: Medición de longitudes y áreas

El visor web mediante controles Ajax ejecuta esta función.

DUC-WEB-7: Herramientas de carga de servicios de Mapas WMS y WFS externos

La carga de Mapas, la ejecuta el servicio web de carga de ficheros.

El fichero puede estar en una máquina local o remota.




.

El visor web lanzará el servicio web correspondiente para la carga del fichero.

DUC-WEB-8: Herramientas de carga de ficheros KML

La carga de ficheros KML la ejecuta el servicio web de carga de ficheros.

El fichero puede estar en una máquina local o remota.

El visor web lanzará el servicio web correspondiente para la carga del fichero.

DUC-WEB-9: Herramientas de búsqueda

Los casos de uso de búsqueda para el Visor Web serán análogos, ya que todos se basan en lamisma idea de invocar a un Servicio Web que será el encargado Consultar al Catastro los datossegún los distintos criterios de búsqueda.

Ej.

DUC-WEB-9.1: Búsqueda por referencia catastral

La Búsqueda por referencia Catastral, ser realiza la primera parte mediante un JavaScript, me irásolicitando al usuario la incorporación de datos tales como, Provincia, población, vía…” para acontinuación pasará dicha información al Servicio Web de búsqueda, y este a su vez consulte alCatastro.

Los datos serán devueltos al visor en formato XML.




.

DUC-WEB-9.2: Búsqueda por topónimos

La Búsqueda por topónimo, tal como ya comentamos, será análoga al resto, así que tomaremoscomo ejemplo el caso genérico de búsqueda. La primera actuación será mediante un JavaScript, meirá solicitará el topónimo de búsqueda, a continuación pasa dicha información al Servicio Web debúsqueda, y este a su vez consulte al Catastro y Google.


DUC-WEB-9.3: Búsqueda por ámbito

Para la Búsqueda por Ámbito seguiremos tomando como ejemplo el caso genérico de búsqueda. Laprimera actuación será mediante un JavaScript, me irá solicitará el Ámbito de búsqueda, acontinuación pasa dicha información al Servicio Web de búsqueda, y este a su vez consulte alCatastro.


DUC-WEB-9.4: Búsqueda por plan

Para la Búsqueda por Plan seguiremos tomando como ejemplo el caso genérico de búsqueda. Laprimera actuación será mediante un JavaScript, me irá solicitará el Plan de búsqueda, acontinuación pasa dicha información al Servicio Web de búsqueda, y este a su vez consulte alCatastro.


DUC-WEB-9.5: Búsqueda por entidad

Para la Búsqueda por Entidad seguiremos tomando como ejemplo el caso genérico de búsqueda.La primera actuación será mediante un JavaScript, me irá solicitará la Entidad de búsqueda, a




.

continuación pasa dicha información al Servicio Web de búsqueda, y este a su vez consulte al

Catastro.Los datos serán devueltos al visor en formato XML.

DUC-WEB-9.6: Búsqueda por callejero

Para la Búsqueda por callejero seguiremos tomando como ejemplo el caso genérico de búsqueda.La primera actuación será mediante un JavaScript, me irá solicitará los datos de búsqueda, acontinuación pasa dicha información al Servicio Web de búsqueda, y este a su vez consulte alCatastro.


DUC-WEB-10: Herramientas básicas de Impresión

La herramienta básica de impresión, es la función Ajax Print.

DUC-WEB-11: Mapa de Situación

El mapa de situación será otra función Ajax, que muestra una miniatura del mapa actual envisualización, indicando la posición del puntero en el mapa.

DUC-WEB-12: Generación de Fichas urbanísticas

Las fichas urbanísticas se rellenarán gracias a la invocación del servicio web de fichas.

El visor solicitará la información a dichos servicios y estos la devolverán en formato XML.

DUC-WEB-13: Herramientas de dibujo

La Herramienta de dibujo es una utilidad Ajax que mediantes árboles generan un fichero PDF.

DUC-WEB-13.1: Guardado de dibujos

El guardado de dibujos se basará en el DUC-WEB-8, será el proceso inverso a la carga de ficheros.

DUC-WEB-14: Generación de mapas en pdf.

DUC-WEB-15: Presentación de leyendas

La presentación de leyendas se ejecutará mediante la invocación de los servicios web de leyendas.Estos devolverán los datos en formato XML.

DUC-WEB-21: Paleta de posición

La paleta de posición es otra funcionalidad Ajax. Que indicará el posicionamiento en el mapa.




.

9.2.7 Gestión de Diccionario.

CASO DE USO: Alta de registros DUC-DIC-1

CASO DE USO: Eliminación de registros DUC-DIC-2

CASO DE USO: Activación desactivación de la funcionalidad DUC-DIC-3

CASO DE USO: Gestión de equipos de redacción DUC-DIC-4

En el siguiente diagrama se muestra como el sistema de respuesta a estos casos de uso:

Un usuario gestor de diccionarios, accederá al módulo de Gestión de Diccionarios y de la páginaJSP solicitará el mantenimiento de una de las tablas diccionario presentadas por pantalla.

Se hará una llamada al actionServletDic, donde se le habrá pasado qué tipo de operación se quiererealizar, según haya sido la navegación por la pantalla jsp.

El servlet accederá al Facade correspondiente, según el usuario haya seleccionado una tabla.Este Facade, llamará a su Entity correspondiente que será el encargado de persistir en la base dedatos el objeto de la operación realizada.

El Entity le devolverá el resultado de la operación al Servlet.




.

9.2.8 Gestión del Plan Base.

CASO DE USO: Creación del Plan Base DUC-BAS-1

CASO DE USO: Creación del Trámite de alta del Plan Base DUC-BAS-2

CASO DE USO: Creación de determinaciones base DUC- BAS -3

CASO DE USO: Creación de entidades base DUC- BAS-6

Para la creación de un Plan Base, obedecerá a la siguiente secuencia:

1- El usuario iniciará el proceso de creación del Plan Base. Donde indicará todos los datos

necesarios para la creación de este.2- Se comprobará si ya existe el Plan Base en Base de Datos.

3- Se lanzará el proceso de creación del Plan Base se creará a su vez el Trámite de alta delPlan Base y la Determinación del Plan Base.

4- Se grabarán los datos en la BD donde se informará si la operación se ha realizado conéxito.

CASO DE USO: Modificación de determinaciones base DUC-BAS-4

CASO DE USO: Modificación de entidades base DUC-BAS-7




.

1- El usuario iniciará el proceso de modificación del Plan Base. En pantalla aparecerán los

datos del Plan Base en cuestión, donde el usuario modificará los datos necesarios.2- Se lanzará el proceso de modificación del Plan Base que a su vez el modificará las

Entidades. Trámite de alta del Plan Base y la Determinación del Plan Base.


CASO DE USO: Eliminación de determinaciones base DUC-BAS-5

CASO DE USO: Eliminación de entidades base DUC-BAS-8-

1- El usuario iniciará el proceso de eliminación de Determinaciones.2- El proceso comprobar si existe la Determinación en Base de Datos

3- En caso de existir, se lanzará el proceso de eliminación de la Determinación que a su vez eleliminará las Entidades. Trámite de alta del Plan Base y la Determinación del Plan Base.


CASO DE USO Activación desactivación de la funcionalidad DUC-BAS-9, se modificara mediante elcambio de la propiedad “visible” en el fichero de properties, “Consola.properties”, la funcionalidad degestión de diccionario.




.

9 .3 Nuevas clases adicionales.

Para la implementación de las funcionalidades relativas al diario de operaciones se hace necesarioel desarrollo de las siguientes clases:

CLASE: RegistroDiarioBean

Atributos

Operaciones

Descripción Clase encargada de guardar y recuperar en el diario de operaciones

los accesos de usuarios




.

CLASE: RegistroOperacionesSistemaBean

Atributos

Operaciones

Descripción Clase encargada de guardar y recuperar en el diario de operacioneslas operaciones realizadas.

9 .4 Revisión del Interfaz de Usuario.

Se definen las siguientes interfaces de usuario muy bien diferenciadas:

o Interfaz de la Consola de Control: Se incluyen en la misma el Validador, Consolidador,Motor de Refundido, mantenimiento de Servicios Web y Gestión de Diccionarios y PlanBase.

El interface gráfico está basado en el framework JSF (JavaServer Faces).

JavaServer. JSF usa JavaServer Pages (JSP) como la tecnología que permite hacer el

despliegue de las páginas.Estas clases tratarán los aspectos del ciclo de vida de la interfaz de usuario, controlando elestado de un componente durante el ciclo de vida de su página. Proporcionan un conjuntode componentes para la interfaz de usuario, incluyendo los elementos estándares de HTMLpara representar un formulario. Estos componentes se obtendrán de un conjunto básico declases base que se pueden utilizar para definir componentes nuevos.

o Interfaz de Visor Web está basado en el framework Ajax, utilizando páginas JSP.

Desde estas páginas JSP, se realizarán las llamadas a los servicios web que serán losproveedores de datos. Los datos serán entregados al visor web en formato XML.




.

La navegación en el visor así como las distintas tareas y eventos están controlados por

Java Script (Ajax).

La interfaz web propuesta para la consola de control dispondrá de los siguientes elementosprincipales:

Es una estructura de encabezado, menú de navegación y contenido.

o Contenedor Principal: Contendrá al resto de elementos

o Árbol de Planes: Estructura jerárquica en la que se mostrarán los ámbitos definidos en elRPM, los planes que contiene cada uno y los trámites cargados de cada plan

o Barra de Menú: Menús de acceso a toda la funcionalidad disponible en los módulos de laconsola de control:

o Gestión del Plan Base (aparecerá oculto por defecto)

o Gestión de Diccionarios (oculto por defecto)

o Validador

o Consolidador

o Motor de Refundidoo Visualizador del RPM

o Área de trabajo: En esta área se cargarán las ventanas correspondientes a cada módulo otrámite del que el usuario desea consultar información.

Árbol de Planes.

Se mostrará la información jerarquizada de ámbitos, planes y trámites disponibles en el RPM segúnlos permisos de acceso del usuario (si pertenece a una entidad local o supramunicipal). A modo deejemplo, un ejemplo de un posible árbol sería:




.

El ejemplo pertenece al visible por una entidad supramunicipal (diputación de Toledo), en la queaparecerían planes de varios municipios. Un árbol de planes del ayuntamiento de Toledo mostraríatan sólo la siguiente información:

Desde este árbol de planes el usuario accederá a la siguiente funcionalidad:o Creación de planes: Se abrirá una ventana modal para la introducción de datos del plan.

o Generación de FIP1: Se pedirá la ruta de salida del FIP1

o Visualización de la información contenida en cada trámite: Esta información se presentaráen la pantalla de visualización de trámites y FIPs en validación contenida en el Área detrabajo.

Barra de menú.

Desde la barra de menú se dará acceso a la funcionalidad principal de la consola de control en lasiguiente agrupación lógica:




.

o Gestión del Registro

o Gestión de Diccionarios

o Gestión del Plan Base

o Procesos

o Control de Procesos

Validación

Consolidación

Generación de Planeamiento Refundido

Área de Trabajo.Dentro del área de trabajo se cargarán las ventanas con la funcionalidad que el usuario hayasolicitado a través del árbol de planes (visualización de trámites) o de la barra de menú (Gestión dediccionarios y planes base y control de procesos)

Visualización de trámites y FIPs en validación.Se agrupa la visualización de trámites y la visualización de ficheros FIPs en validación ya que aefectos de interfaz, ambas funcionalidades serán idénticas.

La interfaz de visualización debe dividirse en diferentes pestañas para poder mostrar el máximo deinformación de cada trámite (o fichero FIP en proceso de validación):

o Pestaña de información general del trámite

o Pestaña de determinacioneso Pestaña de entidades

Pestaña de información general del trámite




.

Se dividirá en dos partes y contendrá, en una la información básica del trámite (nombre, tipo detrámite, etc.), y en la otra, toda la documentación asociada al mismo permitiendo la posibilidad deacceder a la visualización de cada documento.

La navegación entre las capas se producirá mediante la pulsación con el puntero del ratón, en lasdistintas etiquetas del menú de navegación.

Pestaña de determinaciones

Las determinaciones se presentan en forma de árbol según su categorización, al seleccionar unadeterminación en el árbol, se presentará la siguiente información divida a su vez en pestañas:

o Datos principales

o Datos alfanuméricos: Datos básicos que identifican la entidad.o Opciones: Valores de Referencia de la determinación.

o Grupos de aplicación.

o Regulación

o Regulación específica

o Determinaciones reguladoras

o Operaciones

o En las que actúa como operadora

o En las que actúa como operada

o Documentación asociada

o Aplicación: Entidades sobre las que se aplica la determinación

Pestaña de entidades




.

Las entidades se presentarán igualmente en forma de árbol según su categorización, al seleccionar

una entidad en el árbol, se presentará la siguiente información divida a su vez en pestañas:o Datos principales

o Datos alfanuméricos: Datos básicos que identifican la entidad.

o Adscripciones

o Geometría: Mapa mostrando la geometría de la entidad (si posee) con datos basede fondo

o Aplicación

o Aplicación de determinaciones en régimen directo

Casos

• Regímenes

o Regímenes específicoso Aplicación de determinaciones de uso

Casos

• Regímenes

o Regímenes específicos

o Aplicación de determinaciones de acto

Casos

• Regímenes

o Regímenes específicos

o Operaciones

o En las que actúa como operadora

o En las que actúa como operada

o Documentación asociada




.

10. DISEÑO DE LA ARQUITECTURA DE MÓDULOS DEL SISTEMA

El objetivo de este apartado, que sólo se realiza en el caso de Diseño Estructurado , es definir losmódulos del sistema de información, y la manera en que van a interactuar unos con otros.El Sistema está orientado prácticamente en su totalidad a objetos, excepto en el Visor Web, queestá basado en un diseño estructurado de Java Script. Por este motivo, este apartado solo tienesentido para el Visor Web.

10 .1 Diseño de Módulos Visor Web




.

El diseño de los módulos del visor web se ha realizado teniendo en cuenta las consideraciones

surgidas del análisis del sistema de información, definiendo módulos a través de la agrupaciónlógica de la funcionalidad requerida.

10 .2 Diseño de Comunicaciones entre Módulos

En el presente diagrama de estructura se muestra cómo interactúan cada uno de los módulos delVisor entre sí.

Como se puede observar, existe un modelo principal o modulo ejecutivo que se encarga degestionar la correcta ejecución de las distintas funcionalidades de los módulos. Todo el flujo se iniciaal elegir un perfil del visor e inicializar el Sistema, lo que permite cargar las información según una

personalización que se haya definido previamente. Una vez obtenida la misma se procede a iniciarlas funcionalidades de búsqueda asociada a los parámetros de configuración comentados. Lasventanas de búsqueda cargan los parámetros iniciales para la correcta ejecución de las distintasbúsquedas, A continuación se cargan los controles que permiten al usuario manejar el visor. Unavez preparado el entorno del visor, se produce a iniciar el mapa y sus controles. Tras esto el visorqueda completamente operativo y listo para que responda a cualquier petición del usuario.

10 .3 Revisión de la interfaz de Usuario

Se ha tratado de generar un modelo de interfaz de usuario amigable, ágil y capaz de soportar lagran cantidad de información que se pretende manejar con el Visor. Además se tratará de adaptarse




.

lo más posible a las normas de accesibilidad AA dando por sentado que nunca podrá ser un sistema

que cumpla al 100% dichas normas debido a la complejidad del mismo y al uso de mapas en formade imágenes. A continuación se definen las diferentes partes de la interfaz:

- Zona de Ventanas: en esta zona se quiere mostrar al usuario informaciónsegmentada y especifica de diferentes fuentes y para ello se va a generaruna serie de buscadores asíncronos ubicados en sus respectivas ventanas.Los resultados de los buscadores se obtienen siempre en la propia ventanapudiendo seleccionar un resultado con el fin de obtener informaciónextendida o la posición del resultado en el mapa. Además se añade unaventana que sirve de gestor de capas, la cual habilita al usuario una seriede funcionalidades para añadir, editar, ordenar, ocultar o eliminar capas.

- Controles: para facilitar al usuario el uso del Visor se habilitan un serie decontroles para conocer la ubicación del mapa, la escala en la que seencuentra, buscar en el callejero mediante un acceso directo al mismo opara controlar el tipo de vista con el que desea consultar la información.




.

- Mapa: es la parte más importante del Visor ya que es donde se van aplasmar las distintas capas que se desean ver y sobre el cual se van amostrar y realizar las consultas. Consta de unos controles de navegación

que dan la posibilidad de desplazar el mapa, realizar zoom o controlar laescala en la que se encuentra en un instante. También se ha asociado unmapa alternativo que proporciona la usuario una vista general del mapaprincipal para facilitarle la ubicación y el desplazamiento entre distintaszonas. Tanto el mapa principal como el mapa secundario interactuaránentre sí según las acciones del usuario.




.

- Menú avanzado: se suma a todos estos controles ventanas un menú

avanzado que permite controlar de forma más especifica la navegaciónsobre el mapa además de la posibilidad de realizar mediciones, dibujos yconsultas sobre zonas del mapa. Estos controles quedan descritos en lasiguiente imagen.




.

Como se puede observar existe un último botón en el menú (“Gestor de Configuración”) elpermitirá al usuario personalizar el visor modificación una serie de parámetros predefinidos.




.

11. DISEÑO FISÍCO DE DATOS.

11 .1 Diseño del Modelo Físico de Datos.

En las siguientes líneas se muestra el Modelo Físico de datos que se ha generado a partir delestudio del Modelo Lógico. Se parte de la base de que el Sistema ha sido liberado de un gestor debase de datos en concreto por introducir una capa de persistencia que gestiona el intercambio deinformación entre las aplicaciones y el propio gestor de base de datos que se utilice. Se evita atar alSistema con un solo gestor de bases de datos.

Por motivos de legibilidad, el modelo plasmado en la parte superior viene adjunto con el presente

documento. (Modelo Datos Registro 5.2.pdf)En el modelo se diferencian 2 esquemas.

En el esquema número 1, Diccionario, se recogen todos los elementos que forman parte del flujo dedatos de todo el sistema.

En el esquema número 2, Planeamiento, se registran las operaciones y resultados del proceso deSistematización.

En el esquema 3, Explotación, se puede prepara la información con el fin de ser utilizada por elpropio Sistema o por Sistemas externos.




.

11 .2 Optimización del Modelo Físico de Datos.

Se ha considerado la supresión del esquema de Explotación ya que sirve exclusivamente parapresentar o ver los datos. Se deja pues, de forma abierta la presentación de la información con loque se consigue una mejora de rendimiento en el acceso a la información. El modelo quedará de lasiguiente forma (es posible ver en detalle el modelo en el documento “Modelo Físico de DatosOptimizado.pdf” que se adjunta con este documento):

Evaluando de nuevo el modelo se ha conseguido realizar operaciones de optimización eliminando

redundancias, combinando entidades que tenían accesos frecuentes dentro de una mismatransacción, definiendo claves secundarias para determinar caminos de acceso alternativo yasegurando la integridad de entidad evitando que cada una de las claves principales pueda tenervalor nulo. Por lo que el modelo se vuelve consistente, eficiente y limpio.




.

11 .3 Especificación de la Distribución de Datos.

Una vez optimizado el modelo físico se hace necesário una descripción del modelo en detalle. Enlas siguientes líneas están descritos los diferentes esquemas plasmados:

• Diccionario: contiene cada uno de los elementos que definen al sistema mediantelos cuales se pueden procesar cualquiera de las operaciones necesarias paradesarrollar planeamiento urbanístico.

• Planeamiento: esquema sobre el que se plasma toda información resultante de losprocesos de sistematización urbanística. Se almacena el producto final delRefundido y todas y cada una de las operaciones que se realizan durante elproceso.

12. GENERACIÓN DE ESPECIFICACIONES DE CONSTRUCCIÓN.

En esta actividad se generan las especificaciones para la construcción del sistema de información, apartir del diseño detallado. Estas especificaciones definen la construcción del sistema deinformación a partir de las unidades básicas de construcción (en adelante, componentes),entendiendo como tales unidades independientes y coherentes de construcción y ejecución, que secorresponden con un empaquetamiento físico de los elementos del diseño de detalle, como puedenser módulos, clases o especificaciones de interfaz.

12 .1 Especificación del Entorno de Construcción.

El objetivo de esta tarea es la definición detallada y completa del entorno necesario para laconstrucción de los componentes del sistema de información.

En este apartado trataremos de ofrecer una visión acerca del entorno tecnológico en el cual se va aimplementar el sistema, así como ofrecer una breve introducción a las tecnologías usadas ya queresulta de gran utilidad para la construcción del mismo.

- Ubuntu Server

Ubuntu es una distribución GNU/Linux que ofrece un sistema operativo enfocadotanto a ordenadores personales como para servidores. Es una de las másimportantes distribuciones de GNU/Linux a nivel mundial. Se basa en DebianGNU/Linux y concentra su objetivo en la facilidad y libertad de uso, la fluidainstalación y los lanzamientos regulares.

El servidor incluye MySQL 5.0, PHP 5.2 y Python 2.5. Ubuntu 8.04 usa Linux 2.6.24y X.Org 7.3.

- Postgresql




.

El Sistema Gestor de Base de Datos en el que se basa la aplicación es

PostgreSQL.PostgreSQL es un servidor de base de datos relacional orientada a objetos desoftware libre, Proporciona funcionalidades muy apropiadas para el desarrollo de lagestión de expedientes y sistemas de información:

• control de integridad transaccional• disparadores de eventos (triggers)• lenguaje procedimental interno• capacidad de albergar operaciones geométricas (módulos específicos como

PostGIS)• control del acceso concurrente multiversión• etc...

El acceso a datos se realizará mediante el ORM (mapeador objeto-relacional)Hibernate, facilitando el desarrollo, independizando el código de acceso ypermitiendo la migración de modo sencillo a cualquier base de datos existente sinimpacto en el entorno.

- Postgis

PostGIS es un módulo que añade soporte de objetos geográficos a la base de datosobjeto-relacional PostgreSQL para su utilización en Sistema de InformaciónGeográfica. PostGIS ha sido certificado en 2006 por el Open Geospatial Consortium

(OGC) lo que garantiza la interoperabilidad con otros sistemas tambiéninteroperables. PostGIS almacena la información geográfica en una columna deltipo GEOMETRY, que es diferente del homónimo "GEOMETRY" utilizado porPostgreSQL, donde se pueden almacenar la geometría en formato WKB (WellKnow Binary).

- Servidor de Aplicaciones JBoss / Glassfish

Un servidor de Aplicaciones es un dispositivo de software que proporciona serviciosde aplicación a clientes. Un servidor de aplicaciones generalmente gestiona lamayor parte (o la totalidad) de las funciones de lógica de negocio y de acceso a losdatos de la aplicación.

JBoss es un servidor de aplicaciones J2EE de código abierto implementado enJava. J2EE provee estándares que le permiten a un servidor de aplicaciones servircomo "contenedor" de los componentes que conforman dichas aplicaciones. Estoscomponentes, escritos en lenguaje Java, usualmente se conocen como Servlets,Java Server Pages (JSPs) y Enterprise JavaBeans (EJB 3.0) y permitenimplementar diferentes capas de la aplicación, como la interfaz de usuario, la lógicade negocio, la gestión de sesiones de usuario o el acceso a bases de datosremotas.




.

La portabilidad de Java también ha permitido que los servidores de aplicación J2EE

se encuentren disponibles sobre una gran variedad de plataformas, como Unix,Microsoft Windows y GNU/Linux.

Se componen de dos partes: un "Servlet Engine" y un "EJB 3.0 Engine", dentro del"Servlet Engine" se ejecutan exclusivamente las clásicas aplicaciones de Servidor(JSP's ("Java Server Pages") y Servlets), mientras el "EJB 3.0 Engine(Container)"es reservado para aplicaciones desarrolladas alrededor de EJB 3.0's "EnterpriseJava Bean's":

- Web Services

Un servicio web significa un interfaz a aplicaciones web o empresariales que nospermite integrar éstas con otras aplicaciones empresariales, incluyendo aquellas dediferentes vendedores y diferentes plataformas, utilizando XML como el lenguaje deintercambio de datos.

El mecanismo básico de los servicios Web es utilizar XML para transportar los datosa través de diferentes aplicaciones utilizando el protocolo web estándar HTTP.Específicamente se utiliza SOAP (Simple Object Access Protocol) que es un XMLde peso ligero basado en RPC (Remote Procedure Call) sobre HTTP. El protocolotiene tres partes:

1. Un envelope (SOAP envelope) que define un marco de trabajo paradescribir qué hay en un mensaje y cómo procesarlo.

2. Un conjunto de reglas de codificación para expresar ejemplares de tiposde datos definidos por la aplicación.

3. Un conjunto de reglas para representar llamadas y respuestas aprocedimientos remotos.




.

Para optimizar el rendimiento de las aplicaciones basadas en Servicios Web, se han

desarrollado tecnologías complementarias a SOAP, que agilizan el envío de losmensajes (MTOM) y los recursos que se transmiten en esos mensajes (SOAP-RRSHB).

Por otro lado, WSDL (Lenguaje de Descripción de Servicios Web), permite que unservicio y un cliente establezcan un acuerdo en lo que se refiere a los detalles detransporte de mensajes y su contenido, a través de un documento procesable pordispositivos. WSDL representa una especie de contrato entre el proveedor y el quesolicita. WSDL especifica la sintaxis y los mecanismos de intercambio de mensajes.

Para el desarrollo de los Servicios Web con JBoss es tan simple como poner unaanotación de @WebService en el interfaz del servicio que queremos publicar comoservicio web, y una etiqueta de @WebMethod para aquellos métodos dentro delinterfaz que queramos que sean accedidos como métodos web.

13. DISEÑO DE LA MIGRACIÓN Y CARGA INICIAL DE DATOS

La carga inicial de datos, se limitará a:

- Esquema de Diccionario: Los datos de diccionario serán cargados mediantela ejecución de un script sql adjunto con el software

- Plan Base: Igualmente será generado mediante un script adjunto con elsoftware.

- Tablas de seguridad: En el esquema “seguridad,” habrá que cargar las

tablas rol, usuario y ámbito usuario. Estas tablas se cargarán igualmentemediantes scripts.- Tablas de validación: Las tablas de validación “Validación código”,

“específicas” y “genéricas”, se cargarán inicialmente mediante scripts.

El resto de los esquemas se irán cargando datos mediante la ejecución lógica del sistema. Estaejecución lógica, consistirá en:

- El subsistema de validación, mediante un fichero fip válido, cargará suinformación en el esquema de validación. Una vez cargados datosvalidados en el esquema de validación, el subsistema de consolidación seráel encargado de posibilitar la carga de datos en esquema de planeamiento.

Con datos en el esquema de planeamiento, será posible la ejecución delsubsistema de refundido y la visualización de dichos datos en la consolaRPM.

14. ESTABLECIMIENTO DE REQUISITOS DE IMPLANTACIÓN.

14 .1 Especificación de Requisitos de Implantación.

Para la implantación definitiva del sistema serán imprescindibles los siguientes requisitos:




.

Formación a usuarios

DESCRIPCIÓN Se debe realizar una formación a los usuarios según su nivel de acceso(ROL) con el objetivo de que el sistema sea totalmente entendido yutilizable por todos los implicados en el mismo.

PERFILES La formación específica para cada usuario se realizará según supertenencia prefijada a los siguientes roles definidos en el análisis delsistema:

• Administrador de la Consola

• Administrador del Módulo de Validación

•

Administrador del Módulo Consolidador• Administrador del Módulo Motor de Refundido

• Administrador del RPM

• Administrador de los Servicios WEB

Infraestructura

DESCRIPCIÓN Para la implantación del sistema, la entidad local o supramunicipal deberádisponer del hardware necesario especificado en el presente documento

según el supuesto escogido en cada caso.

Comunicaciones

DESCRIPCIÓN Para garantizar el buen funcionamiento de la solución, se deberá contarcon los requerimientos relativos a comunicaciones especificados en elpresente documento en cuanto a velocidad y accesibilidad para cumplirlas recomendaciones de la iniciativa INSPIRE:

Por ejemplo, para servicios de visualización (WMS) se exige:

• Disponibilidad 99%

• Tiempo de respuesta 5s para un mapa de 470 Kb

• Capacidad 20 peticiones por segundo

REFERENCIAS

Métrica versión 3

Ministerio de Administraciones Públicas

Consejo Superior de Administración Electrónica




.

http://www.csi.map.es/csi/metrica3/index.html

UML 2

Jim Arlow, Ila Neustadt

Ediciones Anaya Multimedia, 2006

15. Especificación de Excepciones.

15 .1 Especificación de Excepciones.

Las excepciones recogerán todas las situaciones anómalas que se produzcan en el sistema.Está excepciones estarán catalogadas e identificadas mediante un código de error.

Los códigos de error vendrán expresados de la siguiente forma:

“Error X Y ZZZ” donde

X = “1” Si es un error de Usuario.

“2” Si es un error del Sistema.

De tratarse un error de Usuario, aparecerá un mensaje aclaratorio sobre la causa del error y lamanera de solucionarlo.

En caso de que el error sea del Sistema, se informará al usuario del tipo de error del sistema y selanzará el correspondiente “Trap”.

Y = “1” Error en Subsistema de Validación“2” Error en Subsistema de Consolidación

“3” Error en Subsistema de Refundido

“4” Error en Subsistema de Servicios Web

“5“ Error en Subsistema de Consola RPM

“6” Error en Subsistema de Gestión de Plan Base

“7” Error en Subsistema de Gestión de Diccionarios

“8” Error general.ZZZ = será un número de 3 dígitos, que corresponderá al error específico

Para mayor información sobre las excepciones, se adjunta al presente documento un anexodetallado.

Las excepciones las clasificaremos en dos partes, excepciones de sistema y excepcionesde usuario.

Cuando se produzca una excepción, el sistema de log la recogerá dicho erro con el siguienteformato:

Hora: HH:MM:SS,MS






.

Nivel de Error: Info, Warn, Error

Clase que causante de la excepción

Detalle del error

Ejemplo:

08:49:48,357 ERROR [ServicioConsolidacionBean] Tramite no

encontrado. Reinicie el servicio de consolidación. Si el error

persiste compruebe el fichero FIP. Código Error 22001.

- Excepciones del sistema: Son causas anómalas ajenas al usuario que está manipulando lainformación.

Conexión a Base de Datos DESCRIPCIÓN El Componente de conexión a Base de datos intenta establecer conexión

con esta.

Excepción Error al ejecutar consulta a BD. Esta excepción afecta a todo el sistema.Respuesta del sistema será lanzar una excepción del tipo SQLException;

Condiciones previas Estar desconectado e intentar conectar a la Base de Datos.

Elemento afectado Todo el sistema

Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error de Sistema enla conexión a la base de datos. Inténtelo de nuevo más tarde, si el errorpersiste, póngase en contacto con su administrador.”

El sistema lanzará un Trap, que enviará un correo electrónico aladministrador informándole de lo sucedido. Código 28001




.

Entrada Salida de datos

DESCRIPCIÓN Los componentes de comunicación entre nodos intentan intercambiarinformación.

Excepción Error en la entrada/salida de datos. IOException. Se produjo un error en elenvío de datos por la red.

Condiciones previas n/a


Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error del sistema enentada/salida de datos, inténtelo de nuevo más tarde, si el error persiste,póngase en contacto con su administrador.”

El sistema lanzará un Trap, que enviará un correo electrónico aladministrador informándole de lo sucedido. Código 28002

Configuración del Sistema

DESCRIPCIÓN Los ficheros de configuración del Sistema estuvieran incorrectamenteconfigurados, se podría producir un error al intentar acceder a distintos

apartados del Sistema.

Excepción Error en la configuración del sistema. RedesConfigException



Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error de Sistema enla configuración. Póngase en contacto con su administrador” Código28003




.

Proceso de Consolidación

DESCRIPCIÓN Durante la carga de datos del proceso de Consolidación se produjeraalgún problema, este quedaría registrado en esta excepción

Excepción Error en el proceso de Consolidación. ConsolidacionException


Elemento afectado Servicio de Consolidación

Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error del Sistema al

consolidar FIP. Inténtelo de nuevo más tarde.” Código 22100

Proceso de Validación

DESCRIPCIÓN Durante la carga de datos del proceso de Validación se produjera algúnproblema, este quedaría registrado en esta excepción

Excepción Error en el proceso de Validación. ValidationException.


Elemento afectado Servicios de Validación

Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error del Sistema deValidación. Se ha producido un error al Validar FIP. Para más informaciónconsulte el registro de errores de validación.” 21100




.

Proceso de Refundido

DESCRIPCIÓN Durante la carga de datos del proceso de Refundido se produjera algúnproblema, este quedaría registrado en esta excepción

Excepción Error en el proceso de Refundido. RefundidoException.


Elemento afectado Servicio de Refundido

Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error del sistema de

Refundido. Se ha producido un error al refundir. Inténtelo más tarde”Código 23100

- Excepciones de usuario: Son excepciones producidas por manipulaciónincorrecta del usuario con el sistema de información.

Carga de Ficheros FIP

DESCRIPCIÓN

El usuario podrá manipular ficheros para el proceso de Validación de FIPS

Excepción Excepción de carga de ficheros. Se produce cuando el usuario intentaintroducir un fichero inexistente o con nombre incorrecto. El sistemalanzara una excepción del tipo FileNotFoundException.


Elemento afectado Servicio de carga de fichero FIP

Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error de Usuario al

cargar un Fichero. El fichero no existente, compruebe la ruta del ficheroque intenta cargar es correcto.” 18100




.

Lanzamiento de Servicios

DESCRIPCIÓN El componente de carga de ficheros, intenta incorporar un fichero alsistema.

Excepción Error de nombres. Esta excepción afecta a todo el sistema y se puedeproducir en distintos escenarios tales como la invocar un servicio. Laexcepción lanzada será NamingException.


Elemento afectado Servicio de carga archivo

Respuesta del Sistema

El Sistema lanzará al usuario el siguiente mensaje: “Error de Usuario alcargar un Fichero. El fichero no existente, compruebe que el nombre delfichero que intenta cargar es correcto.” 18200

Hasta este punto hemos definido las excepciones más genéricas del sistema, a continuación en lasiguiente tabla detallamos las excepciones de los distintos subsistemas:

Tipo deerror

SubsistemaCausante

ServicioCausante

Descripción Código Medida a tomar

Sistema Motor deRefundido

Errores enoperaciones entre

entidades: [231xx]

Se ha producido un error en laoperación opEnt_Eliminacion

23101 Reiniciar el servicio deRefundido


Errores enoperaciones entreentidades: [231xx]

Se ha producido un error en laoperaciónopEnt_AcumulacionCompleta




Se ha producido un error en laoperaciónopEnt_AdicionNormativa




Se ha producido un error en laoperación opEnt_AdicionGrafica




Se ha producido un error en laoperaciónopEnt_SustraccionGrafica


Sistema Motor de

Refundido

Errores en

operaciones entreentidades: [231xx]

Se ha producido un error en la

operaciónopEnt_SustitucionNormativaCompleta

23106 Reiniciar el servicio de

Refundido



Se ha producido un error en laoperaciónopEnt_SustitucionGrafica




Se ha producido un error en laoperaciónopEnt_SuspensionCompleta




Se ha producido un error en laoperaciónopEnt_SustitucionNormativaParcial





.

Sistema Motor de

Refundido

Errores en

operaciones entreentidades: [231xx]

Se ha producido un error en la

operaciónopEnt_SuperposicionCompleta


Refundido



Se ha producido un error en laoperaciónopEnt_AportacionEntidad




Se ha producido un error en laoperaciónopEnt_AcumulacionNormasGenerales




Se ha producido un error en laoperaciónopEnt_AcumulacionUsos




entidades: [231xx]

Se ha producido un error en laoperación

opEnt_AcumulacionActos




Se ha producido un error en laoperación opEnt_CreacionGrafica




Se ha producido un error en laoperaciónopEnt_SuperposicionNormasGenerales




Se ha producido un error en laoperaciónopEnt_SuperposicionUsos




Se ha producido un error en laoperaciónopEnt_SuperposicionActos


Sistema Motor deRefundido Errores enoperaciones entreentidades: [231xx]

Se ha producido un error en laoperaciónopEnt_DestruccionGrafica




Se ha producido un error en laoperación opEnt_HerenciaClave




Se ha producido un error en laoperaciónopEnt_SuspensionParcial




Se ha producido un error en laoperaciónopEnt_IncorporacionEntidad




determinaciones:[232xx]

Se ha producido un error en laoperación opDet_Eliminacion



Errores enoperaciones entredeterminaciones:[232xx]

Se ha producido un error en laoperaciónopDet_AdicionNormativa




Se ha producido un error en laoperaciónopDet_SustitucionNormativaCompleta



Errores enoperaciones entredeterminaciones:

Se ha producido un error en laoperación opDet_Suspension





.

[232xx]



Se ha producido un error en laoperaciónopDet_AdicionValorReferencia




Se ha producido un error en laoperaciónopDet_AportacionDeterminacion



Errores enoperaciones entreplanes: [233xx]

Se ha producido un error en laoperación opPla_Modificacion




Se ha producido un error en laoperación opPla_Desarrollo




Se ha producido un error en laoperación opPla_Suspension




Se ha producido un error en laoperación opPla_Sustitucion



Errores enoperaciones entrerelaciones:[234xx]

Se ha producido un error en laoperación oRel_Eliminacion



Errores enoperaciones entrerelaciones:[234xx]

Se ha producido un error en laoperación oRel_Adicion



Errores varios:[230xx]

Se ha producido un error nocontrolado durante el proceso




Entity Manager inactivo 23001 Se ha producido un problema deconexión. Inténtelo más tarde. Siel problema persiste póngase encontacto con el administrador



La lista de trámites a refundir acausado un error




Se ha producido un error alfinalizar el proceso




Se ha producido un error alexportar a FIP




Se ha producido un error alinicializar el contexto

23006 Se ha producido un problema deconexión. Inténtelo más tarde. Si

el problema persiste póngase encontacto con el administrador



Se ha producido un error enmaximoCodigoEntidad




Se ha producido un error enultimoIden




Se ha producido un error endatosPlan




Se ha producido un error eneliminarEntidadDeterminacion




Se ha producido un error encopiarEntidadDeterminacion





.

Sistema Motor de

Refundido

Errores varios:

[230xx]

Se ha producido un error en

relacionesPorElemento


RefundidoSistema Motor de

RefundidoErrores varios:[230xx]

Se ha producido un error eneliminarDocumentosHuerfanos




Se ha producido un error enlimpiarRelaciones




Se ha producido un error ensiguienteApartadoDeterminacion




Se ha producido un error ennumeroArabigoDeRomano




Se ha producido un error envalorDeCaracterRomano




Se ha producido un error endeterminacionGrupoDeEntidadesPorTramite




Se ha producido un error endeterminacionGrupoPorEntidad




Se ha producido un error enentidadesPorGrupoTramite




Se ha producido un error endeterminacionCarpetaPorTramite




Se ha producido un error enopcionPorDeterminaciones




Se ha producido un error enmaximaSuperposicionDeEntidad




Se ha producido un error enentidadesPorDeterminacionValorReferencia


Sistema Motor de

Refundido

Errores varios:

[230xx]

Se ha producido un error en

eliminarObjeto


RefundidoSistema Motor de

RefundidoErrores varios:[230xx]

Se ha producido un error enreasignarEntidad




Se ha producido un error encrearCarpetaEntidadesAportadas




Se ha producido un error entieneGeometria




Se ha producido un error eneliminarRelacionesHuerfanas




Se ha producido un error enreasignarDeterminacion




Se ha producido un error encrearCarpetaDeterminacionesAportadas


Sistema Motor deRefundido Errores varios:[230xx] Se ha producido un error enmaximoCodigoDeterminacion 23032 Reiniciar el servicio deRefundidoUsuario Visor Web Error en

navegaciónERROR DE LECTURA DE XML 15001 Compruebe que los XML existen

o están definidos correctamente.En su defecto, contacte con eladministrador.

Usuario Visor Web Error ennavegación

ERROR AL GENERAR XML 15002 Compruebe que su navegadoresta dentro de la lista denavegadores soportados

Usuario Visor Web Error ennavegación

ERROR. SERVICIO NOMAPEADO

15003 Se está intentando acceder a unservicio no mapeado. Si elproblema persiste, contacte conel administrador




.

Usuario Visor Web Error en

navegación

ERROR. IMPOSIBLE ACCEDER

AL SERVICIO WEB

15004 Se ha producido un problema de

conexión. Inténtelo más tarde. Siel problema persiste póngase encontacto con el administrador

Sistema Visor Web Error ennavegación

ERROR. CONSULTA CONPARAMETROS ERRONEOS

25001 Por favor, seleccione un puntoen el mapa que pertenezca alámbito del propio visor.

Sistema Visor Web Error ennavegación

ERROR. NO SE HANENCONTRADO DATOS

25002 Es posible que la zonaseleccionada con contengainformación. Si lo desea puedeseleccionar otro

Sistema Consolidador Error al importarFIP

Tramite no encontrado 22001 Reinicie el servicio deconsolidación. Si el errorpersiste compruebe el ficheroFIP

Sistema Consolidador Error al importarFIP Error al cargar Determinación 22002 Reinicie el servicio deconsolidación. Si el errorpersiste compruebe el ficheroFIP


Error al cargarOpcionDeterminacion

22003 Reinicie el servicio deconsolidación. Si el errorpersiste compruebe el ficheroFIP


Error al cargarDeterminacionGrupoEntidad



Error al cargar Entidad 22005 Reinicie el servicio deconsolidación. Si el error

persiste compruebe el ficheroFIPSistema Consolidador Error al importar

FIPError al cargar Documento 22006 Reinicie el servicio de

consolidación. Si el errorpersiste compruebe el ficheroFIP


Error al cargarDocumentoDeterminacion



Error al cargar DocumentoEntidad 22008 Reinicie el servicio deconsolidación. Si el errorpersiste compruebe el ficheroFIP

Sistema Consolidador Error al importarFIP Error al cargar OperacionEntidad 22009 Reinicie el servicio deconsolidación. Si el errorpersiste compruebe el ficheroFIP


Error al cargarOperacionDeterminacion



Error al cargar Valores 22011 Reinicie el servicio deconsolidación. Si el errorpersiste compruebe el ficheroFIP

Sistema Consolidador Error al importar Error al cargar Shape 22012 Reinicie el servicio de




.

FIP consolidación. Si el error

persiste compruebe el ficheroFIPUsuario Validación Error al introducir

el FIP en elsistema

Error. No se ha podido introducirel FIP.zip en el sistema.

11001 Error. El usuario debe probar avolver a subirlo en unosinstantes

Usuario Validación Error de formatode FIP que sequiere introduciren el sistema

Error. El formato de FIP que sepretende introducir en el sistemano es un formato valido (ZIP)

11002 Error. Avisar al usuario porconsola que el formato de FIPno es válido y probar a subirlode nuevo en el formato valido(ZIP)

Sistema Validación Error aldescomprimir elFIP introducidopor el usuario

Error. No se ha podidodescomprimir de forma correcta elFIP en el sistema.

21001 Error. Informar al usuario porconsola y pedirle que vuelva aintroducir un FIP.zip que no estécorrupto

Sistema Validación Error el FIPdescomprimido notiene unaestructura valida

Error. Al descomprimir el FIP.zipintroducido por el usuario, este notiene una estructura valida

21002 Error. Informar al usuario porconsola y pedirle que vuelva aintroducir un FIP.zip con laestructura correcta (informar dela estructura)

Sistema Validación Error deintegridad delFIP.xml

Error. El FIP.xml no es integrorespecto al XSD. El FIP.xml no seintroducira en la BD

21003 Error. Informar al usuario porconsola y pedirle que vuelva aintroducir un FIP.zip con unFIP.xml que sea integrorespecto al XSD

Sistema Validación Error al introducirel FIP.xml en labase de datos

Error. Se ha producido un errorinesperado al introducir el FIP.xmlen la base de datos

21004 Error. Informar al usuario porconsola. Reintentar la carga enBase de Datos. Si el problemapersiste consultar con el

administradorSistema Validación Error al validar lostramites

Error. No se ha podido validar eltrámite del FIP.xml

21005 Error. Informar al usuario porconsola. Se ha producido unerror y no se ha podido validar eltrámite del FIP.xml. Reintentar yno continuara hasta que no sehaya validado

Sistema Validación Error al validar lasdeterminaciones

Error. No se han podido validarlas determinaciones del FIP.xml

21006 Error. Informar al usuario porconsola. Se ha producido unerror y no se ha podido validarlas determinaciones del FIP.xml.Reintentar y no continuara hastaque no se haya validado

Sistema Validación Error al validar lasentidades

Error. No se han podido validarlas entidades del FIP.xml

21007 Error. Informar al usuario porconsola. Se ha producido unerror y no se ha podido validarlas entidades del FIP.xml.Reintentar y no continuara hastaque no se haya validado

Sistema Validación Error al validar lascondicionesurbanísticas

Error. No se han podido validarlas condiciones urbanísticas delFIP.xml

21008 Error. Informar al usuario porconsola. Se ha producido unerror y no se ha podido validarlas condiciones urbanísticas delFIP.xml. Reintentar y nocontinuara hasta que no se hayavalidado

Sistema Validación Error al validarotras validaciones

Error. No se han podido validarlas otras validaciones del FIP.xml

21009 Error. Informar al usuario porconsola. Se ha producido un



error y no se ha podido validar

las otras validaciones delFIP.xml. Reintentar y nocontinuara hasta que no se hayavalidado

doc20110311115751consolidacion de herramientas para el servicio de urbanismo en red

Documents