ANÁLISIS DEL SISTEMA · 2012-06-01 · DISEÑO DEL SISTEMA “Consolidación de Herramientas Para...

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 DE URBANISMO 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ónica entre Red.es, el equipo de desarrollo y el de verificación.

8.0 13/10/2009 N/A Cambios sugeridos tras reunión en Red.es con modificaciones 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 de Datos. ......................................................................................................... 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 planes urbanísticos siguiendo una técnica urbanística y un procedimiento administrativo y de control muy depurados tras décadas de mejora y especificación. Actualmente funciona sobre documentación de papel y en el futuro su tratamiento como información territorial exige la utilización de herramientas de 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ón digital en todo su ciclo de vida y en todo su contenido, y que tiene la pretensión de eliminar a medio plazo 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 la informació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 Sociedad de 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 la sociedad de la información. Estos programas, que cuentan con financiación procedente de fondos FEDER de los Programas Operativos FEDER, pretenden dar un fuerte impulso a la disponibilidad y utilización de las telecomunicaciones y las tecnologías de la información, poniendo en marcha servicios 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 los ciudadanos a la Sociedad de la Información. En el marco de las citadas actuaciones, Red.es puso el marcha un proyecto con el objetivo de ejecutar los proyectos pilotos del “Programa de Impulso del Urbanismo en Red” (en adelante, “el Programa”), que tiene por objeto que los ciudadanos puedan acceder a través de Internet a los planes urbanísticos de sus municipios al efecto de aumentar y potenciar la transparencia en la gestión pública del sector urbanístico. Es objeto del programa Urbanismo en Red, la transformación del sistema de publicación del Planeamiento 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 automatizado en 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 internet de la información del refundido automático y opcionalmente de planes en tramitación a través de servicios 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 de estandarizació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 de un Registro de Planeamiento Municipal (en adelante “RPM”) que permitieron contener y mantener el planeamiento vigente para su publicación en Internet (en adelante, los “Servicios de desarrollo”). Se concretaba en la aplicación de Validación de Ficheros FIP, la aplicación de Consolidación de planes en el Registro, el Motor de Refundido de planes y los Servicios Web de publicación de planeamiento refundido. 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 siguiente esquema:


.

• 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 de Planeamiento. 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 Procesador FIP 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 esta capa se localiza:

- El Visor Web. -La Consola RPM.

Las capas de Gestor de Servicios, establecerá la lógica de negocio; Será en esta capa donde actú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 los Trámites, junto al Gestor de Persistencia, que será la capa donde se almacenará y gestionará la informació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 en caso de que se produzca un fallo en el sistema o un defecto en el proceso. Además, la alta disponibilidad permite a un sistema de copia de seguridad controlar los servicios en caso de que se haya producido un fallo en el sistema principal.

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

Arquitectura orientada a Servicios IDENTIFICACIÓN URBR_10

DESCRIPCIÓN Arquitectura Orientada a Servicios (SOA)

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

Plataforma Opensource IDENTIFICACIÓN URBR_11

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) • Localgis

Deberá ser integrable con LocalGIS, herramienta surgida a partir de la evolución de GeoPISTA destinada a fomentar la introducción de la Administración Electrónica (o e-Administración) en las entidades locales; ayudando a realizar una gestión más eficaz sobre la información municipal. Se basa tanto en la georreferenciación de dicha información como en la automatización de los procesos implicados en la gestión de la Administración Local.


.

Autoactualización IDENTIFICACIÓN URBR_12

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, cualquier error detectado y solventado en la fase de explotación será rápidamente desplegado en las distintas Entidades Locales de un modo automático.

Multiplataforma IDENTIFICACIÓN URBR_13

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 IDENTIFICACIÓN URBR_14

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 explorador de internet y deberán soportarán los navegadores más extendidos en el mercado (Internet Explorer y Mozilla Firefox)

Directiva INSPIRE IDENTIFICACIÓN URBR_26

DESCRIPCIÓN Se cumplirá la directiva INSPIRE

COMENTARIO La Directiva Inspire aprobada por la Comunidad Europea crea un marco que trasciende la apertura de una gran biblioteca cartográfica en formato digital y actualizable para inaugurar una infraestructura de datos espacial, integrada y homogénea que pone al alcance de todos la cartografía del territorio europeo. Esto permite combinar información y conocimientos del territorio procedentes 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://inspire.jrc.ec.europa.eu/index.cfm/pageid/47�


.

Alto grado de interactividad IDENTIFICACIÓN URBR_27

DESCRIPCIÓN El sistema deberá ofrecer una respuesta a las instrucciones del usuario con la suficiente rapidez 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 800X600

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

Seguridad IDENTIFICACIÓN URBR_28

DESCRIPCIÓN SEGURIDAD en el acceso a la información y su manipulación, en la integridad de los datos y la 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 IDENTIFICACIÓN URBR_29

DESCRIPCIÓN Cumplimiento de estándares españoles y europeos en materia de ergonomía y calidad y seguridad garantizando 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 «tiene por objeto garantizar y proteger, en lo que concierne al tratamiento de los datos personales, las libertades públicas y los derechos fundamentales de las personas físicas, y especialmente de su honor e intimidad personal». Comprende por tanto el tratamiento automatizado y el no automatizado de los datos de 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�


.

Estructura modular IDENTIFICACIÓN URBR_15

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

COMENTARIO El sistema tendrá al menos los siguientes módulos bien diferenciados: • Consola de Gestión

o Servicios WEB o Motor de Refundido o Consolidador o Validador o Gestión del Plan Base o Gestión de Diccionarios

• Visor Web.

Parametrización, flexibilidad y mantenibilidad IDENTIFICACIÓN URBR_30

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

COMENTARIO El sistema debe permitir la modificación de su comportamiento funcional del mismo mediante parámetros de configuración. El cumplimiento de este requisito permitirá el más alto grado posible 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 nuevas funcionalidades 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 el esfuerzo requerido en la localización y corrección de posibles errores.

Eficiencia IDENTIFICACIÓN URBR_31

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

COMENTARIO

Entorno amigable IDENTIFICACIÓN URBR_32

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 la opción deseada y ayudas en línea

COMENTARIO


.

Incorporación de nuevas funcionalidades IDENTIFICACIÓN URBR_33

DESCRIPCIÓN El sistema deberá poseer un mecanismo sencillo para la incorporación de nuevas funcionalidades 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ón tanto 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 la construcción de servicios interoperables. Para lograrlo se utilizarán los estándares WMS y WFS para publicación de mapas.

Dos Arquitecturas IDENTIFICACIÓN URBR_40

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

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 siguientes componentes:

- Sistema de Gestión de Base de datos

- Motor Espacial

- Servidor de aplicaciones

- Servidor Web

- Servidor de Mapas

- Aplicación de consulta Que 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 todos los servicios. Según el número de accesos y las necesidades se puede utilizar otro tipo arquitectura diferente. Con el fin de conseguir una solución efectiva y práctica para la producción basada en solución Opensource, 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 / Windows

Sistema 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 sistema operativo) que disponga de un navegador web estándar (Internet Explorer, Mozilla Firefox o Google Chrome en sus últimas versiones).


.

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 servidores por 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 ha resultado efectiva para soportar un factor de concurrencia con caché pregenerada de más de 50 usuarios. Como especificaciones mínimas, para entornos pequeños, y empleando cachés pregeneradas, se debería contar con un servidor Intel Dual Core a 3Ghz, la memoria RAM se determinaría en base a 1GB ó 2 por core según la información a mover, discos SATA y tarjetas de red 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 realizar pruebas de rendimiento y carga para determinar el factor de escalabilidad del hardware o emplear entornos basados en dos o tres capas. En la siguiente tabla se podrían establecer las pautas mínimas para definir la arquitectura según el tipo de entorno:

Entorno Instalación Comunicaciones Servidores

Pequeño Básica 1 Nivel

1 ó 2 Mbps simétricos • Un solo nivel: o 1 ó 2 procesadores de 4

núcleos a 2,53Ghz o 12 GB RAM

Mediano /Grande

Avanzada 2 Niveles

4 a 10 Mbps simétricos • Servidor BBDD y aplicaciones: o 1 ó 2 procesadores de 4

núcleos a 2,53Ghz o 12 GB RAM

• Servidor Web o 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 en alta 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, separando capa 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 internet de 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 Desarrollo Orientada 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.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�


.

• 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 sirva para 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 por el 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 en subsistemas 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 Java que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML) que permiten establecer estas relaciones. Esta herramienta de acceso a datos se empleará en todos los subsistemas que componen el Sistema Global. Autentificación: Método criptográfico de identidad de una persona o de un equipo informático. En funció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 de los distintos Subsistemas, este dispone de un sistema de Logger. Log4j es una biblioteca open source desarrollada en Java por la Apache Software Foundation. El servidor de aplicaciones dispondrá de distintos ficheros .log dentro de la carpeta server\default\log, con información puntual de lo sucedido, indicando la hora, la clase que ejecutó la acción, así como la información aportada por 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�


.

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 de los FIP, su función principal es revisar la coherencia y la validez, así como el cumplimiento de distintas normativas urbanísticas.

Se desplegarán sobre el servidor de aplicaciones. Habrá un servicio por validación a realizar. 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 las validaciones a realizar. Internamente las Validaciones se clasificarán por el tipo de validació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 planes

en formato FIP y al traslado de éstos al repositorio.

El subsistema de Consolidación será un EJB 3.0, que solamente se podrá ejecutar para FIP´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 FIP

con el resultado de un plan refundido a partir de los planes vigentes en el repositorio de planeamiento.

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


.

Figura 4. Subsistema de Refundido.

• Subsistema de servicios Web: Es la solución software destinada a proporcionar el acceso

a la información de planeamiento, sin la necesidad de conocer en profundidad las complejidades del modelo de datos.

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

• Subsistema de visor Web: Se trata de una aplicación web que sirve de punto de

información urbanística a todos los ciudadanos a través de internet. Ofrece los datos expuestos por los servicios web.

Será una aplicación web basada en ajax (javascript) y servlets para los procesos de comunicació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 servicios desplegados en el servidor de Aplicaciones así como del control de acceso y flujo de navegació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 nodo ló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 de Servidor 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 infraestructura tecnoló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ógico robusto, independiente del sistema, multitarea y que se capaz de interaccionar con diferentes bases de datos. Para ajustarnos al máximo a las propiedades anteriormente descritas haremos uso de la tecnología Java/J2EE; Las versiones mínimas Java deben ser 1.5. Para potenciar y completar las cualidades de dicha tecnología, los desarrollos harán uso de frameworks 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ódigo cliente 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 definir varios 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 de trabajo, esto es, un diseñador de "componentes"(EJB 3.0's) puede concentrar sus esfuerzos en la "lógica de proceso" sin preocuparse del diseñ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 procedimientos remotos

- Diversos Clientes: Un EJB 3.0 puede interactuar con una gran gamma de clientes 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 la orientación a objetos al interactuar con una cualquier base de datos y permitir usar objetos regulares; El motor de persistencia utilizado en el desarrollo de la solución software es Hibernate 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 de procesos de negocio permitiendo la integración de procesos para la unión de personas y aplicaciones.

Soporta dos lenguajes de proceso: - JPDL: Enfocado a la definición de flujos de procesos en Java. Que es el

utilizado 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 su orientació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 y posteriormente se le dota de la lógica necesaria mediante mapeos con clases de Java. De este modo se crea un nexo entre el analista o diseñador y el programador. Existen herramientas 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 guardado en la base de datos. De modo que no hay soporte para situaciones de asíncrona sin que el thread continúe corriendo. JBPM modela flujos de negocio que básicamente son maquinas de estados, aunque los flujos son algo más que eso. De este modo cualquier cosa que sea susceptible de ser una maquina de estados finitos puede ser modelada con un BPM: navegación web, procesos de backup, sistemas empotrados de control, autómatas totales en general. Realmente la mayor parte de sistemas informáticos pueden ser modelados así, la cuestión es si es viable o conveniente JBPM es básicamente una librería de clases Java y viene distribuida en un JAR, de este modo puede quedar embebida en cualquier tipo de aplicación: web, swing, en servidor, en cliente, etc. Gestor de Geometrías: Es el componente encargado de leer, organizar y operar las geometrías en formato WKT y las transforma a formato Geometry de JTS 1.9; Para facilitar la 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 certificados digitales es ViaFirma en su versión 1.X, de distribución libre que se encuentra completamente en googlecode. ViaFirma es una plataforma de firma digital que venga a simplificar el desarrollo de aplicaciones 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 certificados digitales, como son la criptografía de clave pública, la validación usando CRLs o OCSP, la lectura 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ía JSF, (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 que simplifica el desarrollo de interfaces de usuario en aplicaciones J2EE (Java Enterprise Edition). JSF usa JavaServer Pages (JSP) como la tecnología que permite hacer el despliegue 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 la interfaz de usuario, estado de los componentes y eventos de entrada. Estas clases 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 su pá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 los controles de la interfaz de usuario del lado del cliente a la aplicación del servidor.

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

- Especificar un modelo para la internacionalización y localización de la interfaz 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 las comunicaciones 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 las capas 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 capa de JPA - Hibernate. Esta comunicación es para almacenar/consultar todos los datos relacionados con 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ógica de negocio necesaria para realizar las distintas funcionalidades que proporcionan las distintas aplicaciones de Urbanismo en Red (todos los aplicativos). Estos servicios EJB 3.0 hacen uso de la capa 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 en entornos 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 que se ofrecen. La mayoría de las veces, esta capa de servicios web no será nada más que la fachada web de los servicios EJB 3.0 que son los que realmente van a poseer la lógica de negocio, aunque a 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 que desde 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 tanto de los servicios web como del servidor de mapas para explotar en el visor las distintas funcionalidades. 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 del mismo.


.

• 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 un proxy 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 buena escalabilidad, 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 nivel de seguridad del sistema.

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

o Servidores de aplicaciones en activo-activo Balanceador de carga

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 de

datos 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 entero en otro servidor a través de red. Puede ser entendido como un RAID-1 (Un RAID 1 crea una copia exacta de un conjunto de datos en dos o más discos.)

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

www.drbd.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 se empiezan a cargar los datos en la correspondiente Base de Datos, comprobando la integridad y coherencia 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 los procesos del Sistema. Todos los servicios que intervienen en procesos de escritura en Base de Datos, cuentan con segmentos de Rollback, que se ejecutan automáticamente si al ejecutarse se produce un error, de esta 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 la ejecución de los distintos servicios. Si se produjera un error en las comunicaciones, se interrumpiese la conexión con la Base de Datos o se sufriese una caída del sistema, la Transacción del subsistema que estuviera corriendo en ese momento finalizaría y con ella se produciría un rollback en la Base de Datos, de forma que ningún cambio de los que realizó el subsistema en cuestión antes de finalizar sin éxito, afectaría al contenido 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ón en 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 sistemas desde 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éndose procedido a su Consolidación, cuando el Trámite se haya copiado correctamente a la Base de Datos de 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 alojado el servidor de aplicaciones. El acceso a datos está igualmente restringido mediante usuarios con distintos niveles de permisos a base 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 Certificado Digital. 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 distintos subsistemas. De esta forma cada usuario representa un papel concreto como si de una organización jerárquica se tratara. Así, existen usuarios que tienen la posibilidad de acceder a más funcionalidades de la aplicación que 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 funcionalidades para un solo ámbito (Ej.: usuario de entidad municipal) y otros podrán realizar determinadas tareas sobre varios municipios (Ej.: usuario de entidad supramunicipal):

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

Rol administrador de Servicios Web: Este actor representa al usuario específico de

Administració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 tareas adicionales.

Rol administrador de Motor de Refundido: Este actor representa al usuario específico de

Administración del Módulo de Motor de Refundido. Dado que el conjunto de tareas para la obtención de la bases de datos de planeamiento vigente (refundido) son específicas de este módulo, consideraremos a este usuario un tipo especial de Usuario Administrador.

Rol administrador de Consolidación: Este actor representa al usuario específico de

Administración del Módulo de Consolidación. Dado que el conjunto de tareas de consolidación de los instrumentos de planeamiento en el registro son específicas de este mó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 Usuario Administrador

Rol administrador de Validaciones: Este actor representa al usuario específico de

Administración del Módulo de Validación. Dado que el conjunto de tareas de validación son específicas de este módulo y tienen que ver con la recepción y validación de información de Planeamiento en formato FIP, consideraremos a este usuario un tipo especial de Usuario Administrador.

Rol administrador de Gestión de Diccionarios y Plan Base: Este actor representa al

sistematizador de planeamiento. Las herramientas de producción de planeamiento están excluidas del presente proyecto, pero se incluye al productor como Actor en calidad de receptor 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 del

visor 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 la

posibilidad de que él mismo a través de Internet pueda subir su propio fichero de intercambio 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 para saber en qué estado está.

En caso de acceder mediante usuario y contraseña, el Sistema dará al usuario 3 oportunidades de logarse, 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 registro consistirá en una tabla de la base de datos donde quedará registrado el usuario que accedió, la hora, 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 de seguridad. Se recomienda que la frecuencia de las copias de seguridad, venga dado por la actividad en 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 error grave. Estas copias de seguridad se realizarán mediante la ejecución de Scripts, en los cuales el administrador del Sistema, indicará el soporte en el que se almacenarán las copias. Se recomienda que 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 que podrá ejecutar el administrador del mismo. La restauración del Sistema en caso de desastre, la llevará a cabo el administrador del Sistema, el cual manualmente cargará los backups de la Base de Datos, todos estos procesos están descritos en el Manual de Administración. No obstante, la información necesaria para realizar una restauració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 un formulario web desarrollado a tal efecto. La petición y sus metadatos quedarán almacenados en el diario 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 el diseño de los subsistemas de soporte identificados en la actividad de Definición de la Arquitectura del Sistema (DSI 1), y la determinación de los mecanismos genéricos de diseño. Estos últimos sirven de guía en la utilización de diferentes estilos de diseño, tanto en el ámbito global del sistema de 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 siguiente imagen:

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 servicios

comunes de arquitectura que dan soporte a los servicios, subprocesos y flujos de negocio para 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 estos componentes se implementan con tecnología J2EE utilizando las APIs y utilidades. Por ejemplo, se usan componentes basados en Hibernate para el acceso a bases de datos alfanumé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 frameworks de 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 el mundo orientado a objetos de las aplicaciones y el mundo entidad-relación de las bases de datos en entornos Java. El término utilizado es ORM (object/relational mapping) y consiste en la técnica de realizar la transición de una representación de los datos de un modelo relacional a un modelo orientado a objetos y viceversa. Hibernate no solo realiza esta transformación sino que nos proporciona capacidades para la obtenció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, a veces llamado Plain Ordinary Java Object).Hibernate es un poderoso, motor de ejecución de persistencia objeto relacional y servicio de consultas para Java. Hibernate permite desarrollar clases persistentes 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 de Información y la Base de Datos Relacional. La conexión entre ambas se realiza median un Objeto Relacional, que es el paso intermedio entre Objetos 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 Java Beans, más concretamente en su especificación 3.0 debido a una serie de ventajas que comentaremos a continuación. Los EJB 3.0 proporcionan un modelo de componentes distribuido estándar del lado del servidor. El objetivo de los EJB3.0 es dotar al programador de un modelo que le permita abstraerse de los problemas 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 basado en 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. La especificació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 las siguientes:

- Servicios: Cuando se diseña un componente de Software se deben definir varios 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 de trabajo, esto es, un diseñador de "componentes"(EJB 3.0's) puede concentrar sus esfuerzos en la "lógica de proceso" sin preocuparse del diseñ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 procedimientos remotos

- Diversos Clientes: Un EJB 3.0 puede interactuar con una gran gamma de clientes 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ósito especificar el comportamiento del sistema de información para un caso de uso, mediante objetos o subsistemas de diseño que interactúan, y determinar las operaciones de las clases e interfaces de los distintos subsistemas de diseño. Para ello, una vez identificadas las clases participantes dentro de un caso de uso, es necesario completar los escenarios que se recogen del análisis, incluyendo las clases de diseño que correspondan y teniendo en cuenta las restricciones del entorno tecnológico, esto es, detalles relacionados con la implementación del sistema. Es necesario analizar los comportamientos de excepción para dichos escenarios. Algunos de ellos pueden haber sido identificados en el proceso de análisis, aunque no se resuelven hasta este momento. Dichas excepciones se añadirán al catálogo de excepciones para facilitar las pruebas. Algunos de los escenarios 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 que los subsistemas definidos en la tarea Identificación de Subsistemas de Diseño tienen la mínima interfaz con otros subsistemas. Por este motivo, se elaboran los escenarios al nivel de subsistemas y, de esta forma, se delimitan las interfaces necesarias para cada uno de ellos, teniendo en cuenta toda la funcionalidad del sistema que recogen los casos de uso. Además, durante esta actividad pueden surgir requisitos de implementación, que se recogen en el catálogo de requisitos. Las tareas de 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 del conjunto de clases definidas en la tarea Identificación de Clases Adicionales, ya que, como se ha señalado en la introducción de esta actividad, las actividades Diseño de casos de uso reales y Diseño de clases se realizan en paralelo. Dichas clases se identifican a partir de las clases del modelo 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, pueden aparecer nuevas clases de diseño que no hayan sido identificadas anteriormente y que se incorporan 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 de consola.

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 para comprobar la autenticación del usuario y establecerle los permisos; como al paquete ‘ihm’, que contendrá las interfaces gráficas para que un usuario (humano) pueda hacer uso del resto de funcionalidades Para los paquetes que dependen de ‘BEANS.SEGURIDAD’, las clases que lo forman son las encargadas de proporcionar servicios de acceso a la consola para comprobar la autenticación del usuario 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 acceder y 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 - ServicioValidacionDeterminacionSoloAplicadaEntidadesDefinidasGrupoApli

cacionBean.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 la Consola.

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: PlanIHMFacade

Atributos

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 una funcionalidad 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 se localizaran 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.4 CASO 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 siguiente figura:


.

Como se ve en la imagen, el subsistema de validación afecta tanto a los paquetes ‘data’, ya que se deberá hacer consultas a datos de validación que haya en base de datos; al paquete ‘servicios’, que son 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 los servicios de validación. Para el paquete ‘data.validacion’, las clases que lo forman son las encargadas del mapeo relacional objeto-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 las encargadas 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: ServicioCargaInicialValidacionesBean

Atributos

Operaciones

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


.

CLASE: ValidacionValidacionesGenericasFacade

Atributos

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 FIPs digitalmente.


.

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 de consolidador.

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

Como se ve en la imagen, el subsistema de consolidación afecta tanto a los paquetes ‘data’, ya que se deberá hacer consultas a datos de validación que haya en base de datos y estos datos posteriormente después de aplicarle las respectivas transformaciones, guardarlos en la base de datos del registro de planeamiento (rpm); al paquete ‘servicios’, que son los que contendrán la ló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 de consolidación. Para el paquete ‘data.validacion’, las clases que lo forman son las encargadas del mapeo relacional objeto-base de datos de validación que serán usadas por este subsistema. Estas clases son las siguientes:

Para el paquete ‘data.rpm’, las clases que lo forman son las encargadas del mapeo relacional objeto-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.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 las encargadas 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 de Refundido.

Los paquetes que componen el sistema del Motor de refundido son los que se presentan en la siguiente 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’, que son 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 mapeo relacional 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 no Estos casos de uso estaban pensados para versiones antiguas del Sistema, antes de que existiera un subsistema de Validación; Actualmente estas comprobaciones que indican los casos de uso, no tienen 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: Tramite

Atributos

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: clsOperacionDeterminacion

Atributos

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 u ordenació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 sucedido durante 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 de servicios web.

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

Como se ve en la imagen, el subsistema de servicios web afecta tanto a los paquetes ‘data’, ya que se deberá hacer consultas a datos de validación que haya en base de datos como a datos que haya en la base de datos del registro de planeamiento (rpm) para ofrecer los datos que requiere el servicio web; al paquete ‘servicios’, que son los que contendrán la lógica de negocio de los servicios web, teniendo por un lado acceso a los datafacade, a los servicios básicos y a los servicios propios de lógica de los servicios web. Para el paquete ‘data.validacion’, las clases que lo forman son las encargadas del mapeo relacional objeto-base de datos de validación que serán usadas por este subsistema. Estas clases son las siguientes:


.

Para el paquete ‘data.rpm’, las clases que lo forman son las encargadas del mapeo relacional objeto-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 las encargadas de la lógica de negocio del servicio que ofrecerán estos servicios web. Estas clases son las 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.1 CASO 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.8 CASO 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: urbrWS

Operaciones


.

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 de generar 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 de solicitar 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 la implementación de geoserver 2.0. Es un servidor desarrollado en java con software libre que implementa 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 clientes diversos. 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 de gestión de diccionarios.

Los paquetes que componen el subsistema de Gestión de Diccionarios son los que se presentan en la 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: ActionServletDic

Atributos N/A

Operaciones

Descripción Realiza las tareas propias del mantenimiento de las tablas de diccionario. Mediante componentes Json, dependiendo de la opción de navegación seleccionada, realizará la correspondiente tarea de alta, baja o modificación mediante la llamada al facade de la tabla a modificar y este a su vez, al entity donde tendrá la llamada del json. A continuación exponemos una clase ejemplo con los métodos json que serán implementados en cada uno de los entitys comentado en el grá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 de gestión de Plan Base.

Los paquetes que componen el subsistema de Gestión de Diccionarios son los que se presentan en la 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 a posteriormente se describirán los actores y los casos de uso de cada uno de los módulos del sistema.

A continuación presentamos los casos de uso para los subsistemas de Consola de Control de Planeamiento y visor Web: Comenzaremos con los Casos de Uso genéricos (propios de la Consola) y después trataremos individualmente 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 del subsistema 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 un diagrama 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 de autenticació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 el sistema. 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 credenciales 3.- El usuario envía al ServicioControlAccesoSistema su nombre de usuario y su contraseña o certificado 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á las comprobaciones convenientes para averiguar si el usuario es efectivamente un usuario registrado del sistema y la credencial es correcta. 7.- En caso de que el usuario y la contraseña facilitada sean correctos, el ServicioControlAccesoSistema devolverá al usuario un token de autenticación mediante el cual ya podrá tener acceso al sistema 8.- Si o bien el usuario no es un usuario registrado del sistema o la clave es errónea, el ServicioControlAccesoSistema 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 refundido

El siguiente diagrama muestra la secuencia que seguirá el caso de uso de acceso a los módulos del 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ón Diccionario, Validación y Consolidación), sería equivalente para el resto de subsistemas (Motor Refundido, Gestión Plan Base y Diario Operaciones)


.

Este diagrama muestra el flujo normal que se realiza para el acceso a los distintos módulos de subsistema dentro del sistema. Este flujo parte del flujo anterior en el cual un usuario quiere acceder al sistema: 1.- El usuario quiere acceder al subsistema de gestión de diccionario a través del servicio ServicioGestionDiccionario, para ello, el usuario mandará el token obtenido anteriormente que contiene su identificación y rol. 2.- El ServicioGestionDiccionario previamente a concederle acceso a cualquiera de sus funcionalidades, comprueba contra el ServicioControlAccesoSistema si el rol del usuario es suficiente 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 resultado 4.- Si el usuario pertenece a un rol con suficientes privilegios, se le permitirá el acceso a dicha funcionalidad 5.- Si el usuario pertenece a un rol que no tiene suficientes privilegios, se le denegará el acceso a dicha funcionalidad 6.- El usuario quiere acceder al subsistema de validación a través del servicio ServicioGestionValidación, para ello, el usuario mandará el token obtenido anteriormente que contiene su identificación y rol. 7.- El ServicioGestionValidación previamente a concederle acceso a cualquiera de sus funcionalidades, comprueba contra el ServicioControlAccesoSistema si el rol del usuario es suficiente para poder acceder a dicho servicio solicitado. 8.- El ServicioControlAccesoSistema comprobará si el usuario tiene los suficientes privilegios para acceder a dicha funcionalidad y devolverá el resultado 9.- Si el usuario pertenece a un rol con suficientes privilegios, se le permitirá el acceso a dicha funcionalidad 10.- Si el usuario pertenece a un rol que no tiene suficientes privilegios, se le denegará el acceso a dicha funcionalidad 11.- El usuario quiere acceder al subsistema consolidación a través del servicio ServicioGestionConsolidacion, para ello, el usuario mandará el token obtenido anteriormente que contiene su identificación y rol. 12.- El ServicioGestionConsolidacion previamente a concederle acceso a cualquiera de sus funcionalidades, comprueba contra el ServicioControlAccesoSistema si el rol del usuario es suficiente para poder acceder a dicho servicio solicitado. 13.- El ServicioControlAccesoSistema comprobará si el usuario tiene los suficientes privilegios para acceder a dicha funcionalidad y devolverá el resultado 14.- Si el usuario pertenece a un rol con suficientes privilegios, se le permitirá el acceso a dicha funcionalidad 15.- Si el usuario pertenece a un rol que no tiene suficientes privilegios, se le denegará el acceso a dicha funcionalidad

- 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.1 o 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.6 o 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.3 o 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.3 o 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 de validaContenidos( 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 la interfaz getValidationProcessResultObject( idFip ) para obtener el identificador de los resultados del proceso 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 la interfaz validaContenidos( FIP) ya que este servicio el que posee la lógica de negocio que valida los contenidos del FIP en cuestión. 6.- El servicio ServicioValidacionContenidos realiza las distintas validaciones de planes que se han definido en su lógica de negocio. Esta validación de contenidos incluye tanto las validaciones de planes, recintos, determinaciones, adscripciones, manuales, etc. 7.- El servicio ServicioValidacionContenidos devuelve el resultado de la validación de contenidos en un objeto del tipo ValidationEntityResult. En este objeto están todos los requisitos que se han validado 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 la base 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 no ser 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 la Entidad. 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 y usuarios 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 el sistema. 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 ha mandado el usuario se comprobará si el usuario existe (modificación) o bien si se trata de un alta nueva. 3.- UsuarioBean llamará a usuariofacade donde se procederá a la creación del usuario o la modificació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 usuarios del sistema de administración.


.

9.2.1 Validador.

En este apartado se detallan mediante diagramas de secuencia los distintos casos de usos del subsistema de validación descritos en el documento de análisis (ASI). Estos casos de usos estarán recogidos en los distintos diagramas que se presentan pudiendo un diagrama dar respuesta a más de un caso de uso planteado durante el análisis.

- 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 y desarrollados 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 al sistema. 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 la interfaz de beginTransaction() para iniciar una transacción de despliegue. 8.- El servicio le devuelve el identificador de FIP temporal 9.- La tarea de recepción de información usa el servicio de Control de Recepción a través de la interfaz 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 la interfaz 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 a ServicioValidacionBPM para ejecutar inicioNuevoProcesoValidacion. La conexión al nuevo proceso de validación generará una nueva instancia de startProcessInstanceByKey, donde se le pasarán las variables correspondientes a la nueva validació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

Este flujo es el siguiente: 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 de validateManual( idFip ) para iniciar un proceso de validación manual del FIP que se le pasa como parámetro. 3.- El servicio ValidationService hace uso del servicio ValidationResultsService a través de la interfaz getValidationProcessResultObject( idFip ) para obtener el identificador de los resultados del proceso 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 la interfaz validacionManual( fipAValidar, municipio ) ya que este servicio el que posee la lógica de negocio que valida los planes del fip en cuestión. 6.- El servicio ValidationManualService realiza las distintas validaciones manuales cargando los datos 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 objeto del tipo ValidationEntityResult. En este objeto están todos los requisitos que se han validado y si su resultado ha sido correcto o no. 8.- Se guarda el resultado de la validación manual asociada a ese fip, se le da persistencia en la base 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 de contenido para la verificación de la integridad.

Este flujo es el siguiente: 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 interfaz de validarIntegridad() para iniciar un proceso de validación de integridad del FIP que se le pasa como parámetro. 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 los documentos se encuentren 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 los resultados 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 la interfaz validateIntegrityFIP( idFIP ) ya que este servicio el que posee la lógica de negocio que valida 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 los documentos se encuentren en el FIP.zip, etc. 5.- El servicio ServicioValidacionIntegridad devuelve el resultado de la validación de la integridad en un objeto del tipo ValidationEntityResult. En este objeto están todos los requisitos que se han validado y si su resultado ha sido correcto o no. 6.- El servicio ServicioValidacion hace uso del servicio ServicioResultadosValidación a través de la interfaz getValidationIntegrityProcessResultObject( idFip ) para obtener el identificador del resultado del proceso de validación que se ha creado anteriormente asociado al FIP 7.- Se devuelve el identificador 8.- Se guarda el resultado de la validación de integridad asociada a ese FIP, se le da persistencia en la base de datos. 9.- El servicio ServicioValidacion devuelve a la tarea de validación de Integridad el resultado de la validación de integridad, es decir, si ha sido correcta o no, para que la tarea actúe de forma oportuna dependiendo de si el FIP es integro o no. Si el resultado ha sido satisfactorio, es decir, el FIP es íntegro, se dan los pasos 10, 11, 12 y 13. En caso que el FIP no sea integro, se da el caso 14 10.- La tarea de validación de integridad usa el servicio de GestionIntroduccionFIPenSistema a travé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 posteriormente se puedan realizar el resto de validaciones. 11.- La tarea de validación de integridad usa el servicio de GestionIntroduccionFIPenSistema a través de la interfaz de commitTransaction( idFIPTrans, idFIP ) para dar por concluida esa transacción de volcado en las bases de datos y borrar todos aquellos archivos temporales que ya no son necesarios 12.- La tarea de validación de integridad pasa el control al resto de tareas de validación (que veremos en sucesivos diagramas) 13.- Si la validación de integridad no fue satisfactoria, no se sigue con el resto del proceso de validación ya que no se puede volcar en base de datos el FIP al no ser integro, se pasa a la tarea de recopilació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 desarrollados para este subsistema:

Este diagrama muestra el flujo normal que se realiza para el subsistema de recopilación de informes. 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 de la interfaz de getProcessValidationErrorElements( idFip ) para recopilar todos los errores de los distintos 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 si contienen 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 los distintos 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 si tienen error como si no. 7.- El usuario de la aplicación pide que se muestre por un fichero PDF todos los informes, tanto si contienen errores como si no. 8.- La tarea de recopilación de informes usa el servicio de ServicioGestionInformesValidación a través de la interfaz de getPDFCompleteByFIP(FIP, visor) para recopilar todos los informes de los distintos procesos de validación que se han realizado, tanto si tienen errores como si no en un fichero 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 informes de 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 si tienen error como si no. 11.- Se devuelve el PDF que contiene los informes de los distintos procesos de validación, tanto si tienen error como si no. 12.- El usuario de la aplicación pide que se muestre por un fichero PDF todos los informes, pero solo aquellos que contienen requisitos con errores. 13.- La tarea de recopilación de informes usa el servicio de ServicioGestionInformesValidacion a través de la interfaz de getPDFErrorsByFIP(FIP, visor) para recopilar todos los informes de los distintos 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 de ServicioResultadosValidación a través de la interfaz de getEntityValidationErrorElements (idFip, entityType) para recopilar todos los informes de los distintos procesos de validación que tienen errores. 15.- Se devuelve el objeto que contiene los informes de los distintos procesos de validación que tienen errores. 16.- Se devuelve el PDF que contiene los informes de los distintos procesos de validación que tienen 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 desarrollados para esta funcionalidad:

Este diagrama muestra el flujo normal que se realiza para la visualización de FIP. Este flujo es el siguiente: 1.- El usuario de la aplicación pide la visualización previa del refundido. Se llama al servicio de ServicioPrevisualizacionRefundido que generará un refundido previo con el resultado de refundir el plan 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 de ServicioVisualizacionFIP 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 al servicio de ServicioVisualizacionFIP que se encargará de recuperar la información del trámite validado 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 FIP validado. Se llama al servicio de ServicioVisualizacionFIP que se encargará de recuperar la información de los documentos del trámite validado para posteriormente mostrársela al usuario 8.- 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. Se llama al servicio de ServicioVisualizacionFIP que se encargará de recuperar la información las determinaciones 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 al servicio de ServicioVisualizacionFIP que se encargará de recuperar la información de los recintos del 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 clase CertificadosDigitales, que procederá a marchar el documento con una firma MD5, como Indicando que 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 del subsistema de consolidación descritos en el documento de análisis (ASI). Estos casos de usos estarán recogidos en los distintos diagramas que se presentan pudiendo un diagrama dar respuesta a más de un caso de uso planteado durante el análisis.

- Diagrama de Secuencia de Iniciar Consolidación (DUC-CSD-2) A continuación veremos cómo se relaciona esta tarea con los servicios definidos y desarrollados para consolidación:

Este diagrama muestra el flujo normal que se realiza para el subsistema de consolidación una vez que 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 de consolidació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 integro y 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 el siguiente 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.3 o 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 apartado veremos más en detalle que es lo que ocurre durante ese proceso de consolidación y como un FIP es 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 la base 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 en concreto que se pretende consolidar. Para ello deberá localizar esos datos del FIP en la base de datos 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 de datos con modelos de datos distintos, habrá que ir haciendo transformaciones en los modelos de datos 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 de RPM 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 de RPM las entidades 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. 7.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos de RPM las determinaciones 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. 8.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos de RPM las adscripciones 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. 9.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos de RPM las condiciones urbanísticas 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. 10.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos de RPM los casos 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. 11.- A partir de los datos del trámite del FIP de validación obtenido, se carga en la base de datos de RPM las operaciones 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. 12.- Una vez que el proceso de consolidación ha finalizado, se le informa al usuario del éxito de la consolidació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 mediante un 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.2 o 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 de eliminarOperadores en la clase clsMain.

2- clsMain recuperará de los datos cargados en memoria en la clase clsDatos, el listado de los Trá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 cual RefundidoBean, llamará a ServicioExportFIP2. 2.1 - ServicioExportFIP2. Consultará los datos del Trámite a través de su interface. Se montarán los datos obtenidos en una estructura XML que será devuelta a RefundidoBean en forma de fichero FIP.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 el orden de las operaciones. Dentro de un bucle con el listado de trámites irá iterando entre los elementos 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 escogidos por 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 refundido el 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 del subsistema de visualizador del Registro de Planeamiento Municipal (RPM) descritos en el documento de análisis (ASI). Estos casos de usos estarán recogidos en los distintos diagramas que se presentan pudiendo un diagrama dar respuesta a más de un caso de uso planteado durante el análisis. 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 casos o 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 de planes 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 clase ArbolPlanesJSFController que será la encarga de llamar a la clase que tiene la lógica de negocio para 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 servicio ServicioGestió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 el usuario 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 los planes 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, la clase PlanesJSFController que será la encarga de llamar a la clase que tiene la lógica de negocio para 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 ServicioGestionPlanes 3.- El servicio ServicioGestionPlanes 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 el usuario 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 clase TramitesJSFController que será la encarga de llamar a la clase que tiene la lógica de negocio para recuperar 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ónTramites 3.- 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ó. 4.- Una vez que el controller recibe los datos, de acuerdo con la vista, sacará por pantalla para el usuario 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 clase TramitesJSFController que será la encarga de llamar a la clase que tiene la lógica de negocio para recuperar 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 al servicio 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 el usuario 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 clase TramitesJSFController que será la encarga de llamar a la clase que tiene la lógica de negocio para recuperar 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 servicio ServicioGestiónTramites 11.- 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ó. 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 del subsistema de servicios web descritos en el documento de análisis (ASI). Estos casos de usos estarán recogidos en los distintos diagramas que se presentan pudiendo un diagrama dar respuesta a más de un caso de uso planteado durante el análisis.

- 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.2 o 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 con el 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 de los 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 datos contenidos en el RPM. 5.- El cliente del servicio web solicita al servicio web que le proporcione la información del árbol de registro, para ello pasa como parámetro el identificador del FIP. Este identificador lo puede coger de la 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 FIP solicitado. 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 de refundido del FIP solicitado. 9,10,11,12.- El cliente del servicio web solicita al servicio web información del trámite de un plan seleccionado, el servicio web deberá ir a buscar esta información a la base de datos del registro de planeamiento 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, el servicio web deberá ir a buscar esta información a la base de datos del registro de planeamiento y le devolverá 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 del registro 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 las coordenadas de un punto, el servicio web devolverá al cliente dicha información que será las entidades 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 la geometría de un polígono enviado en formato WKT, el servicio web devolverá al cliente dicha información que será las entidades por capa, registro de planeamiento, etc. del polígono seleccionado. 28,29,30,31.- El cliente del servicio web solicita al servicio web información de los metadatos asociados a los elementos presentes en el registro, el servicio web devolverá al cliente dicha informació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 registro que llevará un registro del diario de operaciones del RPM con un almacén histórico de las acciones llevadas 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. Este flujo es el siguiente: 1.- El cliente del servicio web solicita al servicio web una petición de ficha, para ello le pasa como pará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ándolo y 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 que pertenecen al visor (municipio) solicitado por el cliente y centrados en las coordenadas pasadas por pará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 de datos de registro de planeamiento municipal asociada a las coordenadas solicitadas y a las capas disponibles 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 para que 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, por topó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 consultas de callejero 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 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 pasa al cliente. 5.- El cliente del servicio web solicita al servicio web la lista de todos los municipios de la provincia que le pasa por parámetros. 6, 7, 8.- 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 pasa al cliente. 9.- El cliente del servicio web solicita al servicio web el callejero de un municipio (y provincia) que pasa por parámetros. 10, 11, 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, 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 que pasa por parámetros. 14, 15, 16.- 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 pasa al cliente. 17.- El cliente del servicio web solicita al servicio web la información catastral no protegida de un polígono y parcela de un municipio que pasa por parámetros. 18, 19, 20.- 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 pasa al cliente.

- 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 planesFromNombre consulta 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 y entidadesFromNombre consulta 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 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 la devolució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 una referencia 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 pasa al cliente. 5.- El cliente del servicio web solicita al servicio web las coordenadas geográficas de un inmueble a partir de su referencia catastral que se pasa como parámetros. 6, 7, 8.- 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 pasa al cliente. 9.- El cliente del servicio web solicita al servicio web la referencia catastral de un inmueble pasando como 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, esta respuesta 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


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 que le proporcione la información del árbol de registro, 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 fip 7.- 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


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 de mapas obtener una descripción de los mapas ofrecidos 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. 4.- El servidor de mapas responde a la petición del cliente.


.

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 de características. 8.- El servidor de mapas responde a la petición del cliente.

- 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 las entidades 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 capacidades ofrecidos 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 de características ofrecidos por el servidor. 6.- El servidor WFS responde a la petición del cliente. 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. 8.- El servidor WFS responde a la petición del cliente. 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.4 o 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 que provee 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 mediante eventos JavaScript/Ajax. DUC-WEB-3: Navegación La navegación se controlará mediante Ajax, Aportando al Visor controles gráficos como flechas para 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 mediante eventos 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 mediante eventos 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 web de datos de planeamiento. El servicio web devolverá un XML con la información solicitada. DUC-WEB-5.2: Obtención de información de datos del RPM El visor web lanzará una solicitud de información al servicio web correspondiente. El servicio web consultará la base de datos RPM El servicio web devolverá un XML con la información solicitada. DUC-WEB-5.3: Obtención de información de datos del planeamiento de tramitación 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-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 la misma idea de invocar a un Servicio Web que será el encargado Consultar al Catastro los datos segú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 a continuación pasará 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.2: Búsqueda por topónimos La Búsqueda por topónimo, tal como ya comentamos, será análoga al resto, así que tomaremos como ejemplo el caso genérico de búsqueda. La primera actuación será mediante un JavaScript, me irá solicitará el topónimo de búsqueda, a continuación pasa dicha información al Servicio Web de búsqueda, y este a su vez consulte al Catastro y Google. Los datos serán devueltos al visor en formato XML. 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. La primera actuación será mediante un JavaScript, me irá solicitará el Ámbito 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.4: Búsqueda por plan Para la Búsqueda por Plan seguiremos tomando como ejemplo el caso genérico de búsqueda. La primera actuación será mediante un JavaScript, me irá solicitará el Plan 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.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, 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-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 en visualizació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ágina JSP 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 quiere realizar, 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 de datos 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 del

Plan 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.

3- Se grabarán los datos en la BD donde se informará si la operación se ha realizado con éxito.

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 el

eliminará las Entidades. Trámite de alta del Plan 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 Activación desactivación de la funcionalidad DUC-BAS-9, se modificara mediante el cambio de la propiedad “visible” en el fichero de properties, “Consola.properties”, la funcionalidad de gestión de diccionario.


.

9.3 Nuevas clases adicionales.

Para la implementación de las funcionalidades relativas al diario de operaciones se hace necesario el 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 operaciones las 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 Plan Base. 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 el

estado de un componente durante el ciclo de vida de su página. Proporcionan 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.

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 los proveedores 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 elementos principales: 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 el

RPM, 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 la

consola 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 Refundido o Visualizador del RPM

o Área de trabajo: En esta área se cargarán las ventanas correspondientes a cada módulo o trá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ún los permisos de acceso del usuario (si pertenece a una entidad local o supramunicipal). A modo de ejemplo, un ejemplo de un posible árbol sería:


.

El ejemplo pertenece al visible por una entidad supramunicipal (diputación de Toledo), en la que aparecerían planes de varios municipios. Un árbol de planes del ayuntamiento de Toledo mostraría tan 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 de trabajo.

Barra de menú. Desde la barra de menú se dará acceso a la funcionalidad principal de la consola de control en la siguiente 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 haya solicitado a través del árbol de planes (visualización de trámites) o de la barra de menú (Gestión de diccionarios 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 a efectos 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 de informació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 determinaciones o 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 de trámite, etc.), y en la otra, toda la documentación asociada al mismo permitiendo la posibilidad de acceder 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 las distintas 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 una determinació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 base

de fondo o Aplicación

o Aplicación de determinaciones en régimen directo Casos

• Regímenes o Regímenes específicos

o Aplicación de determinaciones de uso Casos


o Aplicación de determinaciones de acto Casos


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 los mó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, que está basado en un diseño estructurado de Java Script. Por este motivo, este apartado solo tiene sentido 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ón ló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 del Visor entre sí. Como se puede observar, existe un modelo principal o modulo ejecutivo que se encarga de gestionar la correcta ejecución de las distintas funcionalidades de los módulos. Todo el flujo se inicia al 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 iniciar las funcionalidades de búsqueda asociada a los parámetros de configuración comentados. Las ventanas de búsqueda cargan los parámetros iniciales para la correcta ejecución de las distintas búsquedas, A continuación se cargan los controles que permiten al usuario manejar el visor. Una vez preparado el entorno del visor, se produce a iniciar el mapa y sus controles. Tras esto el visor queda 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 la gran 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 forma de 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ón

segmentada y especifica de diferentes fuentes y para ello se va a generar una serie de buscadores asíncronos ubicados en sus respectivas ventanas. Los resultados de los buscadores se obtienen siempre en la propia ventana pudiendo seleccionar un resultado con el fin de obtener información extendida o la posición del resultado en el mapa. Además se añade una ventana que sirve de gestor de capas, la cual habilita al usuario una serie de funcionalidades para añadir, editar, ordenar, ocultar o eliminar capas.

- Controles: para facilitar al usuario el uso del Visor se habilitan un serie de controles para conocer la ubicación del mapa, la escala en la que se encuentra, buscar en el callejero mediante un acceso directo al mismo o para 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 a plasmar las distintas capas que se desean ver y sobre el cual se van a mostrar y realizar las consultas. Consta de unos controles de navegación que dan la posibilidad de desplazar el mapa, realizar zoom o controlar la escala en la que se encuentra en un instante. También se ha asociado un mapa alternativo que proporciona la usuario una vista general del mapa principal para facilitarle la ubicación y el desplazamiento entre distintas zonas. Tanto el mapa principal como el mapa secundario interactuarán entre 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ón sobre el mapa además de la posibilidad de realizar mediciones, dibujos y consultas sobre zonas del mapa. Estos controles quedan descritos en la siguiente imagen.


.

Como se puede observar existe un último botón en el menú (“Gestor de Configuración”) el permitirá 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 del estudio del Modelo Lógico. Se parte de la base de que el Sistema ha sido liberado de un gestor de base de datos en concreto por introducir una capa de persistencia que gestiona el intercambio de información entre las aplicaciones y el propio gestor de base de datos que se utilice. Se evita atar al Sistema 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 de datos de todo el sistema. En el esquema número 2, Planeamiento, se registran las operaciones y resultados del proceso de Sistematización. En el esquema 3, Explotación, se puede prepara la información con el fin de ser utilizada por el propio 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 para presentar o ver los datos. Se deja pues, de forma abierta la presentación de la información con lo que se consigue una mejora de rendimiento en el acceso a la información. El modelo quedará de la siguiente forma (es posible ver en detalle el modelo en el documento “Modelo Físico de Datos Optimizado.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 misma transacción, definiendo claves secundarias para determinar caminos de acceso alternativo y asegurando la integridad de entidad evitando que cada una de las claves principales pueda tener valor 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. En las siguientes líneas están descritos los diferentes esquemas plasmados:

• Diccionario: contiene cada uno de los elementos que definen al sistema mediante

los cuales se pueden procesar cualquiera de las operaciones necesarias para desarrollar planeamiento urbanístico.

• Planeamiento: esquema sobre el que se plasma toda información resultante de los

procesos de sistematización urbanística. Se almacena el producto final del Refundido y todas y cada una de las operaciones que se realizan durante el proceso.

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

En esta actividad se generan las especificaciones para la construcción del sistema de información, a partir del diseño detallado. Estas especificaciones definen la construcción del sistema de informació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 se corresponden con un empaquetamiento físico de los elementos del diseño de detalle, como pueden ser 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 la construcció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 a implementar el sistema, así como ofrecer una breve introducción a las tecnologías usadas ya que resulta de gran utilidad para la construcción del mismo.

- Ubuntu Server

Ubuntu es una distribución GNU/Linux que ofrece un sistema operativo enfocado tanto a ordenadores personales como para servidores. Es una de las más importantes distribuciones de GNU/Linux a nivel mundial. Se basa en Debian GNU/Linux y concentra su objetivo en la facilidad y libertad de uso, la fluida instalació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.24 y 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 de software libre, Proporciona funcionalidades muy apropiadas para el desarrollo de la gestió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 y permitiendo la migración de modo sencillo a cualquier base de datos existente sin impacto en el entorno.

- Postgis

PostGIS es un módulo que añade soporte de objetos geográficos a la base de datos objeto-relacional PostgreSQL para su utilización en Sistema de Información Geográfica. PostGIS ha sido certificado en 2006 por el Open Geospatial Consortium (OGC) lo que garantiza la interoperabilidad con otros sistemas también interoperables. PostGIS almacena la información geográfica en una columna del tipo GEOMETRY, que es diferente del homónimo "GEOMETRY" utilizado por PostgreSQL, donde se pueden almacenar la geometría en formato WKB (Well Know Binary).

- Servidor de Aplicaciones JBoss / Glassfish

Un servidor de Aplicaciones es un dispositivo de software que proporciona servicios de aplicación a clientes. Un servidor de aplicaciones generalmente gestiona la mayor parte (o la totalidad) de las funciones de lógica de negocio y de acceso a los datos de la aplicación. JBoss es un servidor de aplicaciones J2EE de código abierto implementado en Java. J2EE provee estándares que le permiten a un servidor de aplicaciones servir como "contenedor" de los componentes que conforman dichas aplicaciones. Estos componentes, escritos en lenguaje Java, usualmente se conocen como Servlets, Java Server Pages (JSPs) y Enterprise JavaBeans (EJB 3.0) y permiten implementar diferentes capas de la aplicación, como la interfaz de usuario, la lógica de negocio, la gestión de sesiones de usuario o el acceso a bases de datos remotas.


.

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 "Enterprise Java Bean's":

- Web Services

Un servicio web significa un interfaz a aplicaciones web o empresariales que nos permite integrar éstas con otras aplicaciones empresariales, incluyendo aquellas de diferentes vendedores y diferentes plataformas, utilizando XML como el lenguaje de intercambio de datos. El mecanismo básico de los servicios Web es utilizar XML para transportar los datos a través de diferentes aplicaciones utilizando el protocolo web estándar HTTP. Específicamente se utiliza SOAP (Simple Object Access Protocol) que es un XML de peso ligero basado en RPC (Remote Procedure Call) sobre HTTP. El protocolo tiene tres partes:

1. Un envelope (SOAP envelope) que define un marco de trabajo para describir qué hay en un mensaje y cómo procesarlo.

2. Un conjunto de reglas de codificación para expresar ejemplares de tipos de datos definidos por la aplicación.

3. Un conjunto de reglas para representar llamadas y respuestas a procedimientos 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 los mensajes (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 un servicio y un cliente establezcan un acuerdo en lo que se refiere a los detalles de transporte de mensajes y su contenido, a través de un documento procesable por dispositivos. WSDL representa una especie de contrato entre el proveedor y el que solicita. 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 una anotación de @WebService en el interfaz del servicio que queremos publicar como servicio web, y una etiqueta de @WebMethod para aquellos métodos dentro del interfaz 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 mediante la ejecución de un script sql adjunto con el software

- Plan Base: Igualmente será generado mediante un script adjunto con el

software. - Tablas de seguridad: En el esquema “seguridad,” habrá que cargar las

tablas rol, usuario y ámbito usuario. Estas tablas se cargarán igualmente mediantes 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. Esta ejecución lógica, consistirá en:

- El subsistema de validación, mediante un fichero fip válido, cargará su información en el esquema de validación. Una vez cargados datos validados 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 del subsistema de refundido y la visualización de dichos datos en la consola RPM.

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 y utilizable por todos los implicados en el mismo.

PERFILES La formación específica para cada usuario se realizará según su pertenencia prefijada a los siguientes roles definidos en el análisis del sistema:

• 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á contar

con los requerimientos relativos a comunicaciones especificados en el presente documento en cuanto a velocidad y accesibilidad para cumplir las 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 la manera de solucionarlo. En caso de que el error sea del Sistema, se informará al usuario del tipo de error del sistema y se lanzará 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 anexo detallado. Las excepciones las clasificaremos en dos partes, excepciones de sistema y excepciones de usuario.

Cuando se produzca una excepción, el sistema de log la recogerá dicho erro con el siguiente formato:

Hora: HH:MM:SS,MS

http://www.csi.map.es/csi/metrica3/index.html�


.

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 la informació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 en la conexión a la base 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 al administrador informándole de lo sucedido. Código 28001


.

Entrada Salida de datos DESCRIPCIÓN Los componentes de comunicación entre nodos intentan intercambiar

información.

Excepción Error en la entrada/salida de datos. IOException. Se produjo un error en el envío de datos por la red.

Condiciones previas n/a Elemento afectado Todo el sistema

Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error del sistema en entada/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 al administrador informándole de lo sucedido. Código 28002

Configuración del Sistema DESCRIPCIÓN Los ficheros de configuración del Sistema estuvieran incorrectamente

configurados, se podría producir un error al intentar acceder a distintos apartados del Sistema.

Excepción Error en la configuración del sistema. RedesConfigException

Condiciones previas n/a Elemento afectado Todo el sistema

Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error de Sistema en la configuración. Póngase en contacto con su administrador” Código 28003


.

Proceso de Consolidación DESCRIPCIÓN Durante la carga de datos del proceso de Consolidación se produjera

algún problema, este quedaría registrado en esta excepción

Excepción Error en el proceso de Consolidación. ConsolidacionException

Condiciones previas n/a 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ún

problema, este quedaría registrado en esta excepción

Excepción Error en el proceso de Validación. ValidationException.

Condiciones previas n/a Elemento afectado Servicios de Validación

Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error del Sistema de Validación. Se ha producido un error al Validar FIP. Para más información consulte 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ún

problema, este quedaría registrado en esta excepción

Excepción Error en el proceso de Refundido. RefundidoException.

Condiciones previas n/a 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ón incorrecta 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 intenta introducir un fichero inexistente o con nombre incorrecto. El sistema lanzara una excepción del tipo FileNotFoundException.

Condiciones previas n/a 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 fichero que intenta cargar es correcto.” 18100


.

Lanzamiento de Servicios DESCRIPCIÓN El componente de carga de ficheros, intenta incorporar un fichero al

sistema. Excepción Error de nombres. Esta excepción afecta a todo el sistema y se puede

producir en distintos escenarios tales como la invocar un servicio. La excepción lanzada será NamingException.

Condiciones previas n/a Elemento afectado Servicio de carga archivo

Respuesta del Sistema El Sistema lanzará al usuario el siguiente mensaje: “Error de Usuario al cargar un Fichero. El fichero no existente, compruebe que el nombre del fichero que intenta cargar es correcto.” 18200

Hasta este punto hemos definido las excepciones más genéricas del sistema, a continuación en la siguiente tabla detallamos las excepciones de los distintos subsistemas:

Tipo de error

Subsistema Causante

Servicio Causante

Descripción Código Medida a tomar

Sistema Motor de Refundido

Errores en operaciones entre entidades: [231xx]

Se ha producido un error en la operación opEnt_Eliminacion

23101 Reiniciar el servicio de Refundido



Se ha producido un error en la operación opEnt_AcumulacionCompleta




Se ha producido un error en la operación opEnt_AdicionNormativa




Se ha producido un error en la operación opEnt_AdicionGrafica




Se ha producido un error en la operación opEnt_SustraccionGrafica




Se ha producido un error en la operación opEnt_SustitucionNormativaCompleta




Se ha producido un error en la operación opEnt_SustitucionGrafica




Se ha producido un error en la operación opEnt_SuspensionCompleta




Se ha producido un error en la operación opEnt_SustitucionNormativaParcial



.



Se ha producido un error en la operación opEnt_SuperposicionCompleta




Se ha producido un error en la operación opEnt_AportacionEntidad




Se ha producido un error en la operación opEnt_AcumulacionNormasGenerales




Se ha producido un error en la operación opEnt_AcumulacionUsos




Se ha producido un error en la operación opEnt_AcumulacionActos




Se ha producido un error en la operación opEnt_CreacionGrafica




Se ha producido un error en la operación opEnt_SuperposicionNormasGenerales




Se ha producido un error en la operación opEnt_SuperposicionUsos




Se ha producido un error en la operación opEnt_SuperposicionActos




Se ha producido un error en la operación opEnt_DestruccionGrafica




Se ha producido un error en la operación opEnt_HerenciaClave




Se ha producido un error en la operación opEnt_SuspensionParcial




Se ha producido un error en la operación opEnt_IncorporacionEntidad



Errores en operaciones entre determinaciones: [232xx]

Se ha producido un error en la operación opDet_Eliminacion




Se ha producido un error en la operación opDet_AdicionNormativa




Se ha producido un error en la operación opDet_SustitucionNormativaCompleta



Errores en operaciones entre determinaciones:

Se ha producido un error en la operación opDet_Suspension



.

[232xx] Sistema Motor de

Refundido Errores en operaciones entre determinaciones: [232xx]

Se ha producido un error en la operación opDet_AdicionValorReferencia




Se ha producido un error en la operación opDet_AportacionDeterminacion



Errores en operaciones entre planes: [233xx]

Se ha producido un error en la operación opPla_Modificacion




Se ha producido un error en la operación opPla_Desarrollo




Se ha producido un error en la operación opPla_Suspension




Se ha producido un error en la operación opPla_Sustitucion



Errores en operaciones entre relaciones: [234xx]

Se ha producido un error en la operación oRel_Eliminacion



Errores en operaciones entre relaciones: [234xx]

Se ha producido un error en la operación oRel_Adicion



Errores varios: [230xx]

Se ha producido un error no controlado durante el proceso




Entity Manager inactivo 23001 Se ha producido un problema de conexión. Inténtelo más tarde. Si el problema persiste póngase en contacto con el administrador



La lista de trámites a refundir a causado un error




Se ha producido un error al finalizar el proceso




Se ha producido un error al exportar a FIP




Se ha producido un error al inicializar el contexto

23006 Se ha producido un problema de conexión. Inténtelo más tarde. Si el problema persiste póngase en contacto con el administrador



Se ha producido un error en maximoCodigoEntidad




Se ha producido un error en ultimoIden




Se ha producido un error en datosPlan




Se ha producido un error en eliminarEntidadDeterminacion




Se ha producido un error en copiarEntidadDeterminacion



.



Se ha producido un error en relacionesPorElemento




Se ha producido un error en eliminarDocumentosHuerfanos




Se ha producido un error en limpiarRelaciones




Se ha producido un error en siguienteApartadoDeterminacion




Se ha producido un error en numeroArabigoDeRomano




Se ha producido un error en valorDeCaracterRomano




Se ha producido un error en determinacionGrupoDeEntidadesPorTramite




Se ha producido un error en determinacionGrupoPorEntidad




Se ha producido un error en entidadesPorGrupoTramite




Se ha producido un error en determinacionCarpetaPorTramite




Se ha producido un error en opcionPorDeterminaciones




Se ha producido un error en maximaSuperposicionDeEntidad




Se ha producido un error en entidadesPorDeterminacionValorReferencia




Se ha producido un error en eliminarObjeto




Se ha producido un error en reasignarEntidad




Se ha producido un error en crearCarpetaEntidadesAportadas




Se ha producido un error en tieneGeometria




Se ha producido un error en eliminarRelacionesHuerfanas




Se ha producido un error en reasignarDeterminacion




Se ha producido un error en crearCarpetaDeterminacionesAportadas




Se ha producido un error en maximoCodigoDeterminacion


Usuario Visor Web Error en navegación

ERROR DE LECTURA DE XML 15001 Compruebe que los XML existen o están definidos correctamente. En su defecto, contacte con el administrador.


ERROR AL GENERAR XML 15002 Compruebe que su navegador esta dentro de la lista de navegadores soportados


ERROR. SERVICIO NO MAPEADO

15003 Se está intentando acceder a un servicio no mapeado. Si el problema persiste, contacte con el administrador


.


ERROR. IMPOSIBLE ACCEDER AL SERVICIO WEB

15004 Se ha producido un problema de conexión. Inténtelo más tarde. Si el problema persiste póngase en contacto con el administrador

Sistema Visor Web Error en navegación

ERROR. CONSULTA CON PARAMETROS ERRONEOS

25001 Por favor, seleccione un punto en el mapa que pertenezca al ámbito del propio visor.

Sistema Visor Web Error en navegación

ERROR. NO SE HAN ENCONTRADO DATOS

25002 Es posible que la zona seleccionada con contenga información. Si lo desea puede seleccionar otro

Sistema Consolidador Error al importar FIP

Tramite no encontrado 22001 Reinicie el servicio de consolidación. Si el error persiste compruebe el fichero FIP


Error al cargar Determinación 22002 Reinicie el servicio de consolidación. Si el error persiste compruebe el fichero FIP


Error al cargar OpcionDeterminacion

22003 Reinicie el servicio de consolidación. Si el error persiste compruebe el fichero FIP


Error al cargar DeterminacionGrupoEntidad



Error al cargar Entidad 22005 Reinicie el servicio de consolidación. Si el error persiste compruebe el fichero FIP


Error al cargar Documento 22006 Reinicie el servicio de consolidación. Si el error persiste compruebe el fichero FIP


Error al cargar DocumentoDeterminacion



Error al cargar DocumentoEntidad 22008 Reinicie el servicio de consolidación. Si el error persiste compruebe el fichero FIP


Error al cargar OperacionEntidad 22009 Reinicie el servicio de consolidación. Si el error persiste compruebe el fichero FIP


Error al cargar OperacionDeterminacion



Error al cargar Valores 22011 Reinicie el servicio de consolidación. Si el error persiste compruebe el fichero FIP

Sistema Consolidador Error al importar Error al cargar Shape 22012 Reinicie el servicio de


.

FIP consolidación. Si el error persiste compruebe el fichero FIP

Usuario Validación Error al introducir el FIP en el sistema

Error. No se ha podido introducir el FIP.zip en el sistema.

11001 Error. El usuario debe probar a volver a subirlo en unos instantes

Usuario Validación Error de formato de FIP que se quiere introducir en el sistema

Error. El formato de FIP que se pretende introducir en el sistema no es un formato valido (ZIP)

11002 Error. Avisar al usuario por consola que el formato de FIP no es válido y probar a subirlo de nuevo en el formato valido (ZIP)

Sistema Validación Error al descomprimir el FIP introducido por el usuario

Error. No se ha podido descomprimir de forma correcta el FIP en el sistema.

21001 Error. Informar al usuario por consola y pedirle que vuelva a introducir un FIP.zip que no esté corrupto

Sistema Validación Error el FIP descomprimido no tiene una estructura valida

Error. Al descomprimir el FIP.zip introducido por el usuario, este no tiene una estructura valida

21002 Error. Informar al usuario por consola y pedirle que vuelva a introducir un FIP.zip con la estructura correcta (informar de la estructura)

Sistema Validación Error de integridad del FIP.xml

Error. El FIP.xml no es integro respecto al XSD. El FIP.xml no se introducira en la BD

21003 Error. Informar al usuario por consola y pedirle que vuelva a introducir un FIP.zip con un FIP.xml que sea integro respecto al XSD

Sistema Validación Error al introducir el FIP.xml en la base de datos

Error. Se ha producido un error inesperado al introducir el FIP.xml en la base de datos

21004 Error. Informar al usuario por consola. Reintentar la carga en Base de Datos. Si el problema persiste consultar con el administrador

Sistema Validación Error al validar los tramites

Error. No se ha podido validar el trámite del FIP.xml

21005 Error. Informar al usuario por consola. Se ha producido un error y no se ha podido validar el trámite del FIP.xml. Reintentar y no continuara hasta que no se haya validado

Sistema Validación Error al validar las determinaciones

Error. No se han podido validar las determinaciones del FIP.xml

21006 Error. Informar al usuario por consola. Se ha producido un error y no se ha podido validar las determinaciones del FIP.xml. Reintentar y no continuara hasta que no se haya validado

Sistema Validación Error al validar las entidades

Error. No se han podido validar las entidades del FIP.xml

21007 Error. Informar al usuario por consola. Se ha producido un error y no se ha podido validar las entidades del FIP.xml. Reintentar y no continuara hasta que no se haya validado

Sistema Validación Error al validar las condiciones urbanísticas

Error. No se han podido validar las condiciones urbanísticas del FIP.xml

21008 Error. Informar al usuario por consola. Se ha producido un error y no se ha podido validar las condiciones urbanísticas del FIP.xml. Reintentar y no continuara hasta que no se haya validado

Sistema Validación Error al validar otras validaciones

Error. No se han podido validar las otras validaciones del FIP.xml

21009 Error. Informar al usuario por consola. Se ha producido un


.

error y no se ha podido validar las otras validaciones del FIP.xml. Reintentar y no continuara hasta que no se haya validado

ANÁLISIS DEL SISTEMA · 2012-06-01 · DISEÑO DEL SISTEMA “Consolidación de Herramientas Para...

Documents

Transcript of ANÁLISIS DEL SISTEMA · 2012-06-01 · DISEÑO DEL SISTEMA “Consolidación de Herramientas Para...