Avanza Local Padrón 2

(1)

Avanza Local Padrón 2

ANÁLISIS FUNCIONAL TERRITORIO

(2)

HISTÓRICO DE MODIFICACIONES

Fecha Versión Descripción Autor

23/02/12 1.0 Versión inicial Software AG

08/03/12 1.1 Revisión por INTECO INTECO 09/03/12 1.2 Revisión por MINETUR Ministerio de Industria,

Energía y Turismo

12/03/12 2.0 Corregido según

comentarios de MINETUR

Software AG

13/03/12 2.1 Revisión por INTECO INTECO 14/03/12 3.0 Revisión por MINETUR.

Versión final (aceptada)

(3)

Avanza Local Padrón 2 – Análisis funcional territorio 3

Índice

1. VISIÓNGENERALDELPROYECTO 8

1.1. Introducción 8 1.2. Propósito y Alcance 8 1.3. Definiciones y Abreviaturas 9 1.4. Listado de referencias 10 1.5. Notación 10 2. REPRESENTACIÓNDELAARQUITECTURA 11

2.1. Metas y restricciones de la arquitectura 13 2.2. Desarrollar diseños alternativos de la arquitectura 13

2.2.1. Solución A 14

2.2.2. Solución B 14

2.2.3. Solución propuesta 15

2.3. Requisitos y visión de la arquitectura 15 2.4. Conformidad con estándares abiertos 16 2.5. Soluciones específicas de vendedores 17

2.6. Reutilización 17

2.7. Componentes y frameworks reutilizados por el proyecto 17

3. VISTADECASOSDEUSO 19

3.1. Introducción 19

3.1.1. Gestión de entidades de territorio 19 3.1.2. Gestión del histórico del territorio 43

3.1.3. Diagrama de Caso de Uso 44

3.2. Alta neta de entidad de territorio 46

3.2.2. Alta neta de Vía 48

3.2.3. Alta neta de Subsección 48

3.2.4. Alta neta de APP 49

3.2.5. Alta neta de Hueco 49

3.3. Baja neta de entidad de territorio 50

(4)

3.3.3. Baja neta de Subsección 52

3.3.4. Baja neta de APP 53

3.3.5. Baja neta de Hueco 53

3.4. Modificación de entidad de territorio 53

3.4.2. Modificación de Entidad Colectiva 55

3.4.3. Modificación de Entidad Singular 59

3.4.4. Modificación de Núcleo/Diseminado 63 3.4.5. Modificación de Vía 67 3.4.6. Modificación de Distrito 72 3.4.7. Modificación de Sección 76 3.4.8. Modificación de Subsección 80 3.4.9. Modificación de APP 84 3.4.10. Modificación de hueco 85

3.5. Gestión de estructuras del usuario 86

3.5.2. Alta de tipo de estructura 88

3.5.3. Baja de tipo de estructura 88

3.5.4. Modificación de tipo de estructura 89

3.5.5. Alta de estructura 89

3.5.6. Baja de estructura 90

3.5.7. Modificación de estructura 90

3.6. Modificación de fecha de documento 91

3.7. Anulación de movimiento 93

3.8. Consulta de territorio 94

3.8.2. Consulta de situación actual de entidades 95 3.8.3. Consulta de histórico de entidades 98 3.8.4. Consulta de histórico de operaciones 98

3.9. Gestión de histórico 99

3.9.2. Gestionar histórico de operaciones 99

3.9.3. Gestionar histórico de entidades 102

3.10. Ejemplos de operaciones 105

3.10.1. Recodificación de vía 105

(5)

Avanza Local Padrón 2 – Análisis funcional territorio 5 4. VISTALÓGICA 107 4.1. Interfaz de usuario 107 4.2. Seguridad 108 4.3. Gestión de territorio 108 4.4. Validador 110 4.5. Gestión de entidades 110

4.6. Gestión de histórico de entidades 110 4.7. Gestión de histórico de operaciones 111

4.8. Gestión de cartografía 111 4.9. Comunicaciones 111 5. VISTADEINTERACCIÓN 113 5.1. Interfaces de usuario 113 5.1.1. Interfaz web 113 5.2. Interfaces Software 124 5.2.1. Expedientes 125 5.2.2. Módulo de comunicaciones 130 6. VISTADESEGURIDAD 137 6.1. Directrices OWASP 137 6.2. Subsistema de seguridad 140 6.2.1. Usuario 140 6.2.2. Perfil 141 6.2.3. Administrador 141 6.2.4. Funcionalidad 142 6.2.5. Permiso 142 6.2.6. Auditoría 143

7. VISTADELPROCESO 144

7.1. Alta de entidad 144

7.2. Baja de entidad 146

7.3. Modificación de entidad 148

7.4. Consulta de territorio 150

8. VISTADELDESPLIEGUE 152

(6)

9. VISTADEIMPLEMENTACIÓN 156

9.1. Vista general de las capas 156

9.2. Paquetes/Componentes 157 9.2.1. Interfaz web 157 9.2.2. Seguridad 159 9.2.3. Gestión de territorio 160 9.2.4. Gestión de entidades 162 9.2.5. Gestión de histórico 162 9.2.6. Gestión de operaciones 162 9.2.7. Gestión de cartografía 163 9.2.8. Validación 163 9.2.9. Acceso a datos 164 9.2.10. Modelo 165 9.3. Interfaz 166 10. VISTADEDATOS 167 10.1. Diagrama Entidad/Relación 169 10.2. Tablas de Entidades Territoriales 171

10.2.1. Comunidad Autónoma 171 10.2.2. Provincia 171 10.2.3. Municipio 171 10.2.4. Vía 171 10.2.5. Aproximación Postal 172 10.2.6. Hueco 172

10.3. Tablas de Entidades Lógicas 172

(7)

Avanza Local Padrón 2 – Análisis funcional territorio 7 10.4.6. Tipo de vía 174 10.4.7. Tipo de colectivo 174 10.4.8. Tipo de hueco 175 10.4.9. Tipo de local 175 10.4.10. Idioma Español 176 10.5. Tablas auxiliares 176 10.5.1. Tipo de Estructura 176 10.5.2. Atributo de Estructura 176 10.5.3. Estructura 177 10.5.4. Valor de Estructura 178 10.5.5. Relación Estructura-APP 178 10.5.6. Relación Estructura-Estructura 178 10.6. Tablas especiales 178 10.6.1. Expediente 178 10.6.2. Operaciones 178 10.7. Campos de control 179 10.8. Tablas de histórico 179

10.8.1. Gestión de los históricos 180

11. VISTADEADMINISTRACIÓN 181

12. CARACTERÍSTICASGENERALESDECALIDAD 182

12.1. Fiabilidad 182 12.2. Aseguramiento de Calidad 183 12.3. Usabilidad 184 12.3.1. Diseño de Interacción 184 12.3.2. Reglas Heurísticas 185 12.3.3. Metodología 187

12.4. Portabilidad, Mantenibilidad y Rendimiento 187 12.5. Seguridad 189

12.6. Capacidad de prueba 190

(8)

1. VISIÓN

GENERAL

DEL

PROYECTO

1.1. Introducción

El objetivo del módulo es desarrollar una solución cuyo alcance funcional se agrupa en los siguientes objetivos principales:

• Realizar la gestión de las entidades de territorio, a nivel municipal. • Mantener la funcionalidad de AL Padrón 1.2.1.

• Adaptar el modelo de datos de AL Padrón al modelo del Sistema Integrado de Gestión de Población y Territorio (SIG_PT) del INE.

• Integrarse y comunicarse con el Sistema Integrado de Gestión de Población y Territorio (SIG_PT) del INE, mediante el módulo de comunicaciones SIG_PT.

• Integración con aplicaciones cartográficas (en particular, LocalGIS)

• Gestionar estructuras definidas por el usuario de interés para la gestión municipal • Anexar documentación a las operaciones para su revisión por parte del INE

• Anular movimientos realizados en el sistema, así como modificar su fecha de variación

• Incorporar los requisitos comunes y necesarios para formar parte de la plataforma AL Soluciones.

1.2. Propósito y Alcance

(9)

1.3. Definiciones y Abreviaturas

A continuación se expone una tabla con los diferentes acrónimos y abreviaturas utilizados a lo largo del documento con su correspondiente definición.

Acrónimo / Abreviatura Definición

APP Aproximación Postal

CE Censo Electoral

EATIM Entidad de Ámbito Territorial Inferior al Municipio

EC Entidad Colectiva

ES Entidad Singular

INE Instituto Nacional de Estadística

JSF Java Server Faces

LocalGIS Sistema de información Territorial para Entidades Locales

LOPD Ley Orgánica de Protección de Datos

MINETUR Ministerio de Industria, Energía y Turismo OWASP Open Web Application Security Project

SIGM Sistema Integrado de Gestión Municipal SIGPT Sistema Integrado de Gestión de Población y

Territorio

SOA Arquitectura Orientada a Servicios

(10)

1.4. Listado de referencias

A continuación se muestran las referencias utilizadas en el presente documento. Toda la documentación es accesible mediante la extranet, en la dirección web:

https://extranet.mityc.es/sites/PlanAvanza/PADRON/default.aspx

Referencia Título Autor

SETSI_AL_PADRON_2_Espe cificacion_de_requisitos_v3.0. doc Requisitos funcionales de AL PADRÓN Software AG SETSI. Manual_integracion_logotipo_ comun_v1_4.doc

Manual de integración con el logotipo común AL SOLUCIONES MINETUR SETSI_AL_PADRON_2_Mod elo_de_Datos_v1.doc Modelo de datos de la aplicación Software AG

1.5. Notación

(11)

2. REPRESENTACIÓN DE LA ARQUITECTURA

Desde el punto de vista conceptual, la arquitectura sobre la que se cimentará AL PADRÓN es una arquitectura SOA. Una Arquitectura Orientada a Servicios (SOA) es un tipo de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio. El concepto de Servicio no debe asociarse exclusivamente a servicio web (WS), sino que este concepto abarcará a todos los módulos y funciones que reciban algún tipo de información, realicen un tratamiento de la misma y devuelva el resultado de dicho tratamiento. Por ejemplo, en el módulo de gestión de población, se introducirá la información de una habitante, será incorporada en al sistema, esto podría considerar un servicio. Posteriormente, esta información empleará el módulo de comunicaciones para realizar el envío a SIGPT (envío, validación, etc. son servicios). Para finalmente recibir la respuesta de SIGPT y consolidar la variación, siendo estos varios servicios.

Ilustración 1: Diagrama de componentes del sistema y su relación

Los diferentes módulos de la aplicación están a su vez formados por otros servicios más simples que, en su conjunto, cubren la funcionalidad requerida. Cada módulo es un

AL PADRON INE SIGPT Aplicaciones LocalGIS SIGM Entidades Organismos SCCD

Comunicaciones Servicios expuestos

Población Territorio Herramientas

(12)

componente independiente y desacoplado del resto de módulos, pero se pueden comunicar entre ellos en el caso que sea necesario.

Ilustración 2: Arquitectura técnica de la aplicación

Desde el punto de vista tecnológico, AL PADRÓN es concebida como una aplicación web incluida ésta en un servidor de aplicaciones. AL PADRÓN estará formada por diferentes partes diferenciadas:

1. Una interfaz web para la gestión de territorio, población y el resto de las herramientas; además tendrá publicados servicios para su invocación de manera externa. Para la interfaz web se aplicará el patrón MVC (Modelo-Vista-Controlador), utilizando para la presentación JSF.

2. Un framework base de la arquitectura, utilizándose Spring para este propósito. 3. Una capa de persistencia que empleará Hibernate con diversos conectores de Base

(13)

2.1. Metas y restricciones de la arquitectura

En el diseño de la arquitectura del sistema se han tenido en cuenta las siguientes metas y restricciones.

Metas

• La aplicación de gestión estará basado en una interfaz web a la que se accede mediante identificación del usuario, habilitando tan sólo las operaciones a las que el usuario está autorizado.

• El sistema gestionará una base de datos local con la información territorial del municipio. Esta información está compuesta por la situación actual de las entidades así como toda su información histórica disponible.

• Existirá una comunicación con SIGPT para el intercambio de información y la sincronía de ambos sistemas, realizándose esta comunicación a través de un módulo de comunicaciones y la invocación de servicios web.

Restricciones

• El sistema deberá soportar diferentes motores de base de datos (Oracle, PostgreSQL, MySQL)

• La aplicación podrá ser publicada en diferentes servidores de aplicaciones (JBoss y Apache Tomcat) y bajo diferentes sistemas operativos: Windows, OpenSUSE, CentOS u otras distribuciones Linux.

• La comunicación con otros sistemas o aplicaciones deberá ser segura, por lo que los mensajes enviados y recibidos por el módulo de comunicaciones y los servicios expuestos irán firmados.

• Para facilitar la compatibilidad con SIGPT y permitir un rendimiento óptimo del sistema se adopta el mismo modelo de datos local que el utilizado en SIGPT.

2.2. Desarrollar diseños alternativos de la arquitectura

(14)

2.2.1. Solución A

La solución se corresponde con la propuesta en la arquitectura. Se resumen los principales puntos:

• Vista: se utiliza JSF para el control de la navegación y la generación de las páginas. Se elige la implementación RichFaces de JSF ya que presenta un nivel de madurez adecuado y proporciona una amplia biblioteca de componentes reutilizables para las páginas.

• Framework: se utiliza Spring ya que facilita el desacoplamiento en el código y posee clases de utilidad y soporte para agilizar el desarrollo.

• Servicios web: se utiliza Spring WS para la generación de los servicios web por la sencillez y rapidez en su implementación.

• Persistencia: se utiliza Hibernate como capa de soporte a la persistencia ya que ofrece un método sencillo de acceso a datos y uniforme, independizando del motor de base de datos utilizado.

2.2.2. Solución B

Está solución es similar estructuralmente a la arquitectura propuesta, con las siguientes particularidades:

• Vista: se utiliza JSP para la generación de las páginas de la interfaz web. Mientras que JSP es una tecnología más ligera que JSF, se alargaría el tiempo de desarrollo al no disponer de una biblioteca de componentes visuales para ser utilizados en la interfaz de las páginas.

• Framework: se prescinde de Spring como framework base de la aplicación, utilizando otro framework que ofrezca el patrón de diseño MVC (Modelo, Vista, Controlador) • Servicios web: la implementación de servicios web proporcionada por Spring se

(15)

• Persistencia: se elimina la capa que proporciona Hibernate para el acceso a la base de datos. El acceso sería más directo, pero sería necesario implementar las diferentes particularidades de cada motor de base de datos soportado.

2.2.3. Solución propuesta

Se adopta la Solución A como óptima para la arquitectura del sistema por los siguientes motivos:

• Rapidez en el desarrollo: el uso de Spring, Hibernate y JSF aceleran el tiempo de desarrollo pues cubren un amplio espectro de funcionalidades que, de otra manera, deberían ser implementadas manualmente.

• Desacoplamiento: se consigue un desacoplamiento en los diferentes componentes que forman el sistema. Gracias a Spring todas las dependencias de código se resuelven en un único archivo de configuración. Mediante Hibernate se consigue independizar el desarrollo de la base de datos utilizada, permitiendo cambiar de forma fácil sin que afecte a la implementación.

• Estabilidad: todos los productos propuestos se han convertido en estándares de la industria por su flexibilidad, rendimiento y funcionalidad. Estas soluciones llevan algún tiempo en el mercado por lo que tienen un nivel de madurez alto y una estabilidad muy alta. Además existe suficiente soporte técnico para ayudar al desarrollo.

2.3. Requisitos y visión de la arquitectura

Los criterios que justifican el uso de la arquitectura propuesta se detallan en los siguientes puntos:

(16)

futuros sistemas, creando los servicios complejos necesarios a partir de otros servicios simples ya implementados.

• Patrón MVC (Modelo, Vista, Controlador): realiza una división en varias capas lógicas de la aplicación web, de manera que cambios en una de estas capas tenga un impacto mínimo sobre las otras. Este patrón es el más utilizado en el desarrollo de aplicaciones web.

• JSF: es un estándar en el desarrollo de interfaces de aplicaciones web. Las implementaciones de JSF disponen de amplias bibliotecas de componentes que ayudan a la creación de interfaces de usuario ricas y funcionales.

• Framework Spring: Este framework tiene una madurez suficiente como para poder ser confiable y permite un desacoplamiento de las diferentes capas que forman la aplicación. Además facilita la escalabilidad y la integración con diversas tecnologías, permitiendo una rápida adaptación a nuevos requerimientos o necesidades.

• Hibernate: proporciona un nivel de abstracción en el acceso a la base de datos, ocupándose de la integración con diferentes motores de bases de datos y ofreciendo un acceso unificado a los datos, independientemente de la fuente utilizada.

2.4. Conformidad con estándares abiertos

(17)

2.5. Soluciones específicas de vendedores

En la arquitectura se utilizan los siguientes productos:

• Servidor web: Apache Tomcat 7.x, JBoss Application Server 7 • Framework: Spring 2.5

• Vista: RichFaces 4.0

• Persistencia: Hibernate 3.6, Oracle 9/10, PostgreSQL 9.1.2, MySQL 5.5

2.6. Reutilización

El uso de componentes reutilizables va a permitir un desarrollo más eficaz, desacoplando los componentes utilizados y facilitando su interconexión mediante el framework utilizado. Mediante Spring se consigue un ensamblado de diferentes componentes gracias a un archivo de configuración en el que se definen todas las dependencias, pudiendo reemplazar un componente por otro sin afectar al código desarrollado.

En el desarrollo de la interfaz web se utilizará el patrón de diseño MVC (Modelo/Vista/Controlador) pues asegura una separación de la lógica de negocio, las clases y páginas utilizadas para la visualización de la información y el control de la navegación. En el acceso a la base de datos se debe asegurar una independencia total del motor de base de datos utilizado. Ya que la aplicación puede funcionar con diferentes motores, es importante que el uso de uno u otro sea transparente y no afecte a la lógica de negocio de la aplicación.

2.7. Componentes y frameworks reutilizados por el proyecto

(18)

Framework o componente

reutilizable

Proveedor Lista de beneficios Repositorio donde se ubican

Spring 2.5 Código abierto Provee de clases de soporte para un desarrollo rápido, integración con otros

componentes, desacoplamiento y creación de servicios web http://www.springsourc e.org

Hibernate 3.6 JBoss Implementa una capa de acceso a base de datos que aporta independencia

del software utilizado, optimiza el rendimiento y

facilita el acceso y tratamiento de los datos

http://www.hibernate.org/

RichFaces 4.0 JBoss Implementa el estándar JSF para generación de interfaces web flexibles, aportando una biblioteca de componentes de fácil integración en cualquier

página web

(19)

3. VISTA DE CASOS DE USO

En este apartado se recogen los principales casos de uso existentes en la aplicación. Algunos casos de uso se dividen a su vez en otros casos de uso más particularizados.

3.1. Introducción

El módulo de territorio permitirá la gestión del territorio a nivel local para un organismo (ayuntamiento) y en coordinación con SIGPT del INE. Además deberá permitir el mantenimiento de todos aquellos datos necesarios para la integración con aplicaciones cartográficas (LocalGIS u otras).

Toda modificación en la gestión del territorio implicará el envío de un expediente con dicha modificación al SIGPT con el fin de que la información se encuentre sincronizada en ambos sistemas. Esta comunicación es posible mediante el módulo de comunicaciones de la aplicación. La funcionalidad de este módulo junto con la gestión de expedientes se trata en el documento correspondiente, abordándose en este documento solamente la gestión de territorio a nivel local.

Por último indicar que, en la aplicación, la gestión y la BBDD de territorio están estrechamente relacionados con la gestión y BBDD de población. Esto se manifiesta en que no podrá ser dada de baja una entidad en la BBDD si contiene huecos que estén habitados. Dentro de territorio cabe reseñar dos gestiones diferenciadas:

3.1.1. Gestión de entidades de territorio

En la gestión de entidades de territorio se incluirá toda la funcionalidad que permita el manejo de la situación actual de dichas entidades. Para ello se definen operaciones orientadas al mantenimiento de las diferentes entidades que componen el municipio.

La gestión de entidades se puede clasificar en dos categorías:

(20)

o Operaciones simples: Son aquellas que solo realizan una operación sobre una entidad, pudiendo implicar la modificación de las entidades que se encuentran jerárquicamente debajo.

o Operaciones complejas: Son aquellas que realizan o pueden realizar más de una operación afectando a varias entidades simultáneamente. Al igual que con las operaciones simples, las entidades inferiores jerárquicamente pueden verse implicadas en la modificación.

Las operaciones existentes son: Alta Neta (simple) Baja Neta (simple) Modificación:

• Cambio de clase (simple) • Recodificación (simple) • Renumeración (simple)

• Modificación de denominación (simple) • Modificación de otros atributos (simple) • Fusión (compleja)

• Segregación (compleja) • Cambio de límites (compleja) Especiales

• Modificación de fecha de documento • Anulación de movimiento

La ejecución de uno u otro tipo de operación entraña unas validaciones específicas sobre la situación en BBDD de las entidades afectadas.

(21)

Además de las entidades propias de territorio, se tendrá una funcionalidad que permitirá al usuario definir unas estructuras propias del ayuntamiento que agruparán a otras entidades o estructuras.

3.1.1.1. Entidades

El Estado se organiza territorialmente en Municipios, en Provincias y en las Comunidades Autónomas que se constituyan, según el artículo 137 de la CE, gozando todas estas entidades de autonomía para la gestión de sus respectivos intereses.

A su vez, el municipio se divide en otras entidades territoriales menores, sobre las que se podrán realizar gestiones por el sistema.

Por último, se encuentran las entidades electorales, que se corresponden con la parte de la gestión del callejero que es útil únicamente para la gestión de Censo Electoral. Estas entidades sólo podrán ser consultadas por el sistema.

Se obtiene así el siguiente listado de entidades: • Gestionadas por el sistema:

o Territoriales, comenzando desde la de más bajo nivel y terminando en la entidad más amplia:

(22)

o Electorales

Local electoral Mesa electoral • No gestionadas por el sistema:

o Territoriales: Municipio Provincia Comunidad Autónoma o Electorales: Delegación provincial

Nota: La gestión de las entidades mesa electoral y local electoral no se explica en este documento. Al ser entidades de índole electoral, su tratamiento se cubre en la parte de integración con Censo Electoral del módulo de administración y herramientas.

En los siguientes puntos se enumeran todas las entidades territoriales existentes, incluyendo las no gestionadas por el sistema a nivel informativo.

Las entidades correspondientes a unidad poblacional (entidad colectiva, entidad singular, núcleo/diseminado) y seccionado (distrito, sección y subsección) realizan una división del municipio completa, es decir, abarcan todo el territorio existente.

Todas las entidades tienen asociadas un número de identificación único, denominado NIDEN. Este NIDEN es un valor secuencial que se asigna al realizar el alta de una nueva entidad y viene proporcionado por SIGPT. Así, el NIDEN identifica a una entidad de manera única para todo el territorio español.

(23)

• NIDEN LOCAL: Número identificativo para la base de datos local del sistema. La aplicación asigna este número en el alta de una entidad de forma local.

• NIDEN INE: Número identificativo de SIGPT válido para todo el territorio español. Su valor será vacío hasta que SIGPT procese la operación de alta y devuelva el valor asignado. Este NIDEN será el utilizado para identificar entidades en las comunicaciones con procesos del INE.

3.1.1.1.1. Hueco

Un hueco representa conceptualmente a una vivienda (que puede o no tener habitantes), local o alojamiento. Es la entidad territorial de último nivel y representa una dirección postal completa, con referencia en un plano en tres dimensiones.

3.1.1.1.2. APP

Una aproximación postal representa una dirección postal hasta el nivel de portal. Además cada APP deberá estar referenciada mediante unas coordenadas catastrales y GPS.

3.1.1.1.3. Vía

La entidad de Vías reúne el conjunto de vías o pseudovías a nivel lógico que conforman un municipio. Se define la pseudovía como todo aquello que no es ni unidad poblacional ni vía, que sustituye a la vía en el caso de que no exista y la complementa en caso contrario. Por norma general para formar la denominación de cualquier vía se utilizará el tipo de vía seguido de su nombre, aunque en ocasiones y dependiendo del idioma oficial del municipio esto podrá ser a la inversa.

(24)

contenida en una unidad de población. En caso contrario no podrá ejecutarse el expediente a este nivel, siendo necesario realizar la modificación a nivel de APP.

En la actualidad, el municipio codifica sus propias vías, utilizando un número único dentro del municipio.

Entendemos que una fusión de vías corresponde a la unión de dos o más vías para generar una única vía pudiendo darse de baja las otras vías implicadas.

Una segregación de vía corresponde a partición de una vía en dos o más vías siendo necesario dar de alta las nuevas vías, que no deben existir con anterioridad.

El resto de casos en los que se produce un traspaso de APP entre varias vías corresponde a expedientes de cambio de límites ya que las vías implicadas permanecen.

En ninguno de los tres casos anteriores debe producirse una variación en los datos de Entidad de Población o de Seccionado en las APP, ya que en ese caso la operación deberá corresponder a alguna de las existentes a nivel de Seccionado de Unidad de Población. Se debe tener en cuenta que existen zonas del territorio en las cuales no existen vía ni pseudovía estando las distintas APP numeradas a nivel de Núcleo/Diseminado.

Para mantener la integridad se considerará que en todos los municipios habrá al menos una vía que se identificara con el código cero.

3.1.1.1.4. Subsección

A efectos de Censo Electoral, las secciones se dividirán en subsecciones. Éstas se utilizan para reubicar a los electores de una Sección en distintas mesas electorales por motivos geográficos.

Históricamente la subsección es un concepto que no se mantiene fuera de períodos no electorales dada la variabilidad de éstas que se producían entre los distintos tipos de elecciones.

(25)

Se considera que todas las secciones tienen al menos una subsección identificada con el código cero.

La subsección es una de las entidades más dinámicas del sistema ya que es actualizada en cada proceso electoral.

3.1.1.1.5. Sección

Los distritos se dividen en secciones estadísticas. Una sección estadística es esencialmente un área del terreno del término municipal, cuyo tamaño viene determinado por el número de electores. Según la Ley 5/1985 de Régimen Electoral General, el número de electores en una sección está comprendido entre 500 y 2.000, aunque si existe un municipio que contenga un número inferior de habitantes, éste se definirá como una sección.

La sección es el segundo nivel de la división administrativa electoral la cual agrupa habitantes. Un distrito tendrá al menos una sección.

Por cuestiones de gestión electoral existe la posibilidad de necesitar agrupar a los habitantes en divisiones de la sección. Para ello se utiliza la entidad subsección. Una sección puede no tener subsecciones o estar completamente dividida en subsecciones.

3.1.1.1.6. Distrito

Es la entidad de mayor nivel dentro de la división administrativa electoral. Permite agrupar secciones y éstas a su vez habitantes. Un municipio tendrá al menos un distrito.

Los distritos se dividen en secciones y un distrito tendrá al menos una sección.

3.1.1.1.7. Núcleo/Diseminado

Núcleo de población: Conjunto de al menos diez edificaciones, que están formando calles, plazas y otras vías urbanas. Excepcionalmente el número de edificaciones podrá ser inferior a 10 siempre que la población de derecho supere los 50 habitantes.

(26)

A la agrupación de entidad colectiva, entidad singular, y Núcleo o diseminado se le denomina Nomenclátor.

3.1.1.1.8. Entidad Singular

Cualquier área habitable del término municipal, habitada, o excepcionalmente, deshabitada, claramente diferenciada dentro del mismo, y que es conocida por una denominación específica que la identifica sin posibilidad de confusión.

Las entidades singulares estarán constituidas por núcleos de población y/o diseminados.

3.1.1.1.9. Entidad Colectiva

La Entidad Colectiva es la unidad intermedia entre el Municipio y la Entidad Singular y es la entidad de máximo nivel dentro de la unidad poblacional, agrupando a una o varias entidades singulares (parroquias, hermandades, anteiglesias, concejos, diputaciones y otras). Conforma una Entidad Colectiva de población con identidad propia.

Esta agrupación solo se produce en algunos casos ya que normalmente la Entidad Singular será la entidad de mayor nivel en una unidad poblacional.

3.1.1.1.10. Municipio

Según la Ley 7/1985, de 2 de abril, Reguladora de las Bases del Régimen Local, el municipio es la entidad local básica de la organización territorial del estado. Tiene personalidad jurídica y plena capacidad para el cumplimiento de sus fines. Sus elementos son el territorio, la población y la organización.

En el Principado de Asturias los municipios reciben, oficialmente, la denominación tradicional de concejos.

(27)

Avanza Local Padrón 2 – Análisis funcional territorio 27 3.1.1.1.11. Provincia

La provincia es una división territorial de España, reconocida en la Constitución Española. Es una entidad local con personalidad jurídica propia, determinada por la agrupación de municipios y división territorial para el cumplimiento de las actividades del Estado.

En España hay un total de cincuenta provincias. Ceuta y Melilla son ciudades autónomas, pero se incluyen como entidades provincia para unificar su gestión.

3.1.1.1.12. Comunidad Autónoma

Una comunidad autónoma es una entidad territorial que, dentro del ordenamiento constitucional de España, está dotada de autonomía legislativa y competencias ejecutivas, así como de la facultad de administrarse mediante sus propios representantes. La comunidad autónoma permite agrupar provincias.

Es una entidad muy estable por lo que su modificación no será común.

3.1.1.1.13. Mesa Electoral

Una mesa electoral identifica la urna donde se deposita el voto electoral. Siempre estará ubicada dentro de un local electoral y agrupará a electores de una misma sección o subsección por las iniciales de sus apellidos. En ocasiones, y dependiendo del número de electores, podrá haber una mesa única para una sección/subsección.

Además una mesa electoral puede ser mesa electoral para residentes en España (mesas CER) y para residentes en el extranjero (mesas CERA).

3.1.1.1.14. Local Electoral

Es el lugar donde estarán ubicadas las mesas electorales en los procesos electorales. Podrá instalarse en colegios, institutos, diputaciones, centros culturales, asociaciones...

(28)

Esta entidad se renovará en cada proceso electoral. Los Ayuntamientos harán propuestas con los locales electorales a utilizar y será el INE el encargado de aceptarlos, denegarlos o proponer algunos nuevos.

3.1.1.1.15. Delegación Provincial

La entidad Delegación Provincial está directamente relacionada con la entidad Provincia y almacenará la información propia de cada delegación provincial del INE.

3.1.1.1.16. Relación entre entidades

A continuación se muestran las diferentes relaciones existentes entre las entidades.

CCAA

Provincia

Municipio

Ilustración 3: Relación entre CCAA, Provincia y Municipio

(29)

Una Provincia está formada por Municipios, de tal forma que una provincia se relaciona con un conjunto de municipios, y un municipio solo se relaciona con una Provincia.

Cada Provincia tendrá un código único a nivel nacional y estará relacionada con un elemento de la entidad Comunidad Autónoma

Se considera a la provincia como la entidad de primer nivel de callejero del cual dependen el resto de las entidades de territorio.

Municipio

E. Colectiva

E. Singular

Núcleos

Ilustración 4: Relación entre Municipio, Entidad Colectiva, Entidad Singular y Núcleo/Diseminado

Un Municipio puede estar formado por cero, una o varias Entidades Colectivas. Cuando un Municipio no tiene ninguna entidad colectiva, se relaciona directamente con las entidades singulares, si bien en este sistema se considerará que, en este caso, siempre existirá al menos una entidad con código cero.

Una entidad Colectiva está formada por entidades singulares. Por tanto, una entidad colectiva se relaciona con un conjunto de entidades singulares y una entidad Singular se relaciona con una única entidad Colectiva, si esta existe, o con un Municipio.

(30)

Municipio

Vías

Aprox Postal

Hueco

Ilustración 5: Relación entre Municipio, Vía, Aproximación Postal y Hueco

Un Municipio se relaciona con un conjunto de vías, y cada vía se relaciona con un solo Municipio. En un mismo Municipio no pueden existir dos vías con el mismo nombre y tipo. Una vía se relaciona con varias aproximaciones postales, pero una aproximación postal se relaciona solo con una vía.

(31)

Núcleo/Diseminado

Aprox. Postal

Hueco

Ilustración 6: Relación entre Núcleo/Diseminado, Aproximación Postal y Hueco

Un núcleo o diseminado se relaciona con varias aproximaciones postales, y una aproximación postal se relaciona con un único núcleo o diseminado.

(32)

Municipio

Distrito

Sección

Subsección

Mesa

Ilustración 7: Relación entre Municipio, Distrito, Sección, Subsección y Mesa Electoral

Un Municipio se relaciona con un conjunto de distritos, y un distrito solo se relaciona con un Municipio.

Un Distrito se relaciona con un conjunto de secciones, y una sección solo se relaciona con un distrito.

(33)

Municipio

Locales

Mesas

Ilustración 8: Relación entre Municipio, Local Electoral y Mesa Electoral

Un municipio contendrá varios locales electorales. Un local electoral solo puede estar relacionado con un municipio.

Cada local está relacionado con un conjunto de mesas, y cada mesa está relacionada con un solo local.

(34)

Una subsección tendrá asociadas varias mesas, mientras que una mesa solo puede pertenecer a una subsección.

Una APP podrá pertenecer a un local, con lo cual tendrá asociadas varias mesas, mientras que una mesa solo podrá pertenecer a un local. Al poder tener un local asociado a varias APPs, una mesa estará relacionada con todas las APPs que forman el local donde se encuentra.

Provincia Delegación

Ilustración 10: Relación entre Provincia y Delegación

(35)

Avanza Local Padrón 2 – Análisis funcional territorio 35 3.1.1.2. Operaciones

Respecto a las operaciones que se pueden realizar sobre las diferentes entidades, ya se enumeraron en el punto 3.1.1. Gestión de entidades de territorio. Hay que tener en cuenta que no todas las operaciones son aplicables a todas las entidades.

Además de las operaciones antes mencionadas se disponen de otras dos operaciones especiales, que se detallan en los siguientes puntos:

• Modificación de fecha de documento • Anulación de movimiento

3.1.1.2.1. Alta neta

Corresponde a altas de códigos que no existen en el sistema, asignando un número único (NIDEN) que identifica a la entidad que se ha dado de alta. Sobre el terreno estas operaciones al nivel de vías, APP, huecos o subsecciones no presentan problemas conceptuales. A otros niveles tales como sección, núcleos/diseminados..., conceptualmente pareciera que no deben existir ya que el territorio está divido en su totalidad en alguna de estas estructuras por lo que una nueva alta implicaría necesariamente un cambio de límites de alguna de ellas. Es decir, la aparición de una nueva sección solamente es posible a partir de una parte de territorio perteneciente previamente a una o más secciones.

Dicho esto, el control de operaciones en que intervengan más de una sección de nueva creación o alguna otra estructura de ámbito superior cuya codificación no sea potestad del Ayuntamiento puede ser complicado ya que únicamente podría realizarse a partir de denominaciones, llegándose al extremo de que al nivel de secciones no existe tampoco la denominación.

No debemos por tanto confundir las operaciones de Alta Neta con las acciones básicas de altas de códigos. Está claro que una segregación de una sección necesitará en algún momento generar el alta del nuevo código pero esta alta corresponde a una acción particular necesaria para llevar a cabo la segregación.

(36)

3.1.1.2.2. Baja neta

La situación es similar al caso de alta neta. Hay casos en que un código, después de una serie de operaciones o por error en su alta debe ser dado de baja.

3.1.1.2.3. Cambio de clase

Una operación de cambio de tipo quedará restringida a aquellos casos en que sea necesario “convertir” una vía en una pseudovía o viceversa.

En este caso, además se permitirá modificar tanto el código de la nueva entidad como su denominación y el resto de atributos.

3.1.1.2.4. Recodificación

Este tipo de operaciones permiten cambiar el código de una entidad (el caso más habitual es el de recodificación de vías) En este tipo de operaciones será posible cambiar no solamente el código sino también la denominación y el resto de atributos.

3.1.1.2.5. Renumeración

Esta operación solo se aplica a vías y permite modificar los valores de numeración de las APPs contenidas en la vía.

3.1.1.2.6. Modificación de denominación

(37)

En el caso particular de vías un cambio de denominación incluye tanto el nombre en sí mismo como el tipo de la vía.

No se permitirá modificar el nombre normalizado ya que este será generado por el sistema.

3.1.1.2.7. Modificación de otros atributos

Permitirá cambiar el resto de atributos de una entidad entendiendo por esto el resto de datos distintos del código y la denominación.

Este expediente no permitirá en ningún caso modificar datos referidos al código de la entidad ni a su denominación.

3.1.1.2.8. Fusión

Consideramos una operación de fusión de dos o mas entidades cuando el resultado de la misma es una única entidad que puede tener o no el mismo código de una de ellas pudiéndose dar de baja el resto de entidades.

Gráficamente una operación de fusión correspondería a:

Situación previa

Operación

Resultado

Vía 1 Vía 2

Fusión Vía 1 y 2 en la Vía 1

Vía 1 Vía 2

Vía 1

Vía 2

Baja Vía 2

(38)

3.1.1.2.9. Segregación

Entendemos por segregación la operación mediante la cual una entidad se divide formando nuevas entidades del mismo tipo y con códigos no existentes hasta el momento, salvo el correspondiente a la entidad origen.

Gráficamente una segregación correspondería a:

Situación previa

Operación

Resultado

Segregación Vía 1 en Vía 1 y 2

Vía 1

Vía 1 Vía 2

Vía 1

Alta Nueva Vía

Vía 2 Vía 1

En esta operación las entidades resultantes pueden cambiar tanto de códigos como de nombre y resto de atributos.

3.1.1.2.10. Cambio de límites

En una operación de cambio de límites una parte del contenido de una entidad se traslada a otra u otras entidades ya existentes o no.

Gráficamente correspondería a:

Situación previa

Operación

Resultado

Vía 1 Vía 2

Cambio de límites Vía 1 y 2

Vía 1 Vía 2

(39)

En este caso las entidades iniciales (Vía 1 y Vía 2) se mantienen, habiendo, únicamente, un traspaso de APPs entre una y otra.

3.1.1.2.11. Modificación de fecha de documento

Permitirá corregir la fecha de variación de una operación ya incorporada al sistema.

3.1.1.2.12. Anulación de movimiento Permitirá anular una operación realizada previamente.

3.1.1.3. Listas de valores

Existen listas de valores para algunos de los atributos de las entidades. Se utilizan como diccionarios de datos de los valores posibles que puede tomar un atributo.

Las listas de valores se sincronizan con las de SIGPT mediante expedientes, tal como se detalla en el análisis funcional del módulo de administración y herramientas. En dicho documento se detallan las diferentes listas de valores.

3.1.1.4. Estructuras

Una estructura puede entenderse como una entidad propia del ayuntamiento, aunque su gestión y tratamiento difieren enormemente de la gestión de entidades territoriales normales. Mediante las estructuras se podrán definir agrupaciones lógicas de entidades simples (APPs) u otras estructuras. Su utilidad es la de proporcionar otras divisiones territoriales adaptadas a las necesidades de cada ayuntamiento, así como identificar entidades de interés en el municipio o gestionar información adicional sobre las entidades existentes. Como ejemplos, en un municipio se podrían definir las siguientes estructuras:

(40)

• Barrio: Agrupación de tramos.

• Colegio: Identificación de APPs correspondiente a colegios del municipio, permitiendo almacenar un código de centro para cada uno de ellos.

• Puntos de interés: Edificios, monumentos, etc.

En un ayuntamiento se podrán definir tantos tipos diferentes de estructuras como se deseen. Un tipo de estructura será una agrupación de APPs o de otras estructuras y contendrá una serie de atributos, pudiendo ser definidos por el usuario o corresponderse con algunos de los códigos pertenecientes a APPs (solo para el caso de agrupaciones de APPs).

Una vez definido un tipo de estructura, se podrán dar de alta estructuras de ese tipo, modificar las existentes y dar de baja estructuras. No confundir estas operaciones con las correspondientes a entidades territoriales. Estas operaciones son locales al ayuntamiento, no recibiendo SIGPT comunicación sobre ellas, además no generan histórico de ningún tipo y no permiten operaciones complejas de modificación, como por ejemplo fusión de estructuras.

A una estructura se podrán asociar entidades o estructuras a las que agrupa en el momento de su creación o modificando una estructura existente. De la misma manera, al realizar el alta de APPs se podrá indicar que pertenecen a una determinada estructura (lo que permitirá completar datos de las APPs de manera automática con los códigos que la estructura tenga definidos) y al realizar el alta de una estructura se podrá indicar a que otra estructura de mayor nivel pertenece.

(41)

Municipio

Tipo de estructura

Atributo

Ilustración 11; Relación entre Municipio, Tipo de estructura y Atributo de estructura

Un municipio tendrá definidas varios tipos de estructuras, perteneciendo un tipo de estructura solamente a un municipio.

(42)

Municipio

Estructura

APP

Ilustración 12: Relación entre Municipio, Estructura y Aproximación Postal

Un municipio tendrá definidas varias estructuras, perteneciendo cada estructura solamente a un municipio.

Una estructura podrá agrupar varias estructuras y a su vez podrá estar contenida en varias estructuras.

Una estructura podrá agrupar varias APPs y una APP podrá estar contenida en varias estructuras.

3.1.1.5. Cartografía

La gestión de la información cartográfica de las entidades territoriales también queda recogida en la gestión de territorio. Como la gestión cartográfica está muy ligada a la integración con otros sistemas de información geográfica, su tratamiento en profundidad está pendiente de revisar la integración con AL LocalGIS. No obstante, en este punto se abarcarán los conceptos generales de la gestión cartográfica en la aplicación.

(43)

territorio y los sistemas cartográficos gestionan la información en un plano de dos dimensiones. De forma general, toda operación compleja (fusión, segregación o cambio de límites) supondrá una modificación en la cartografía de la entidad.

Estas modificaciones cartográficas vendrán representadas mediante ficheros SHAPEFILE, que deben cumplir la directiva INSPIRE, donde se recoge las especificaciones para el diseño de las infraestructuras de datos espaciales. Se recoge más información sobre estos ficheros en el punto 5.2.1 Expedientes.

El sistema manejará para las entidades dos sistemas de coordenadas, cada uno propiedad de un organismo ya que los métodos de medición pueden ser diferentes en cada caso:

• Ayuntamiento: coordenadas definidas por el ayuntamiento para las entidades.

• SIGPT: coordenadas definidas por el INE para las entidades, proporcionadas por su propio sistema de información geográfica, por ejemplo Catastro.

3.1.2. Gestión del histórico del territorio

La gestión de los históricos de territorio se encuentra íntimamente ligado a la gestión de las entidades de territorio, ya que en esta gestión de los históricos se controlaran tanto las versiones de las entidades como las operaciones que manejan las entidades. De esta manera se tiene un control de las entidades activas y de las versiones anteriores y la evolución de las mismas.

Se diferencian así dos tipos de histórico:

• Histórico de entidades (versiones): Para cada entidad territorial (sección, subsección, vía, APP, hueco, etc.) se guarda un histórico de todas las situaciones por las que ha ido pasando a lo largo del tiempo. Las estructuras definidas por el usuario no generan ningún tipo de histórico, solo mantienen la situación actual.

(44)

sencillas y su información histórica se puede recuperar mediante los históricos de entidad.

La gestión histórica se realiza de forma automática por la aplicación, siendo transparente para el usuario.

3.1.3. Diagrama de Caso de Uso

En este punto se muestra el diagrama de los principales casos de uso de la aplicación, así como la relación existente entre ellos y los actores del sistema.

3.1.3.1. Actor

(45)

3.1.3.2. Diagrama

Gestor Territorio Gestor Territorio Gestor Territorio

Alta neta territorio

Baja neta territorio

Modificar territorio A 03 gestor Territorio modificación Territorio A 03 gestor Territorio modificación Territorio A 01 gestor Territorio

alta neta territorio

A 01

gestor Territorio

A 02

gestor Territorio

baja neta territorio

A 02

gestor Territorio

Consultar territorio A 04 gestor Territorio consulta territorio A 04 gestor Territorio consulta territorio Gestionar histórico A05

gestionar histórico

A05

gestionar histórico

A06

baja neta territorio gestionar histórico

A06

baja neta territorio gestionar histórico

A07 modificar territorio gestionar histórico A07 modificar territorio gestionar histórico Modificar fecha documento A08

modificar territorio _modificar

fecha documento

A08

modificar territorio _modificar

fecha documento Gestionar Estructura Anular Movimiento A 09 gestor Territorio anular Movimiento A 09 gestor Territorio anular Movimiento A 10

gestor Territorio A 10 gestionar Estructura

(46)

3.2. Alta

neta

de

entidad de territorio

Realiza el alta de una entidad nueva no existente en el sistema. Para entidades que realicen una división completa del territorio (entidad colectiva, entidad singular, núcleo/diseminado, distrito y sección) no será posible realizar el alta de una entidad aislada, sino que vendrá promovido por modificaciones más complejas como fusiones, segregaciones o cambio de límites.

En la operación se puede realizar el alta de varias entidades simultáneamente.

(47)

3.2.1. Diagrama de Caso de Uso

Alta neta territorio Alta neta Vía Alta neta Subsección Alta neta APP Alta neta Hueco A 01.01.01

alta neta territorio alta neta

Vía

A 01.01.01

alta neta territorio alta neta

Vía

A 01.01.02

alta neta

Subsección A 01.01.02

alta neta

Subsección A 01.01.04

alta neta Hueco A 01.01.04

alta neta Hueco A 01.01.03

alta neta APP

A 01.01.03

(48)

3.2.2. Alta neta de Vía

RF4.1.3.1 _{Alta de vía}

Versión ₁

Descripción _{Realizar el alta de una nueva vía}

Prioridad _Alta

El alta de vía se realizará asociada al municipio, siempre que no exista otra vía en el mismo municipio con idénticos códigos. Tras completar el alta se asigna al hueco un NIDEN único para su identificación.

Junto con el alta de una vía se podrán dar de alta las APPs correspondientes a esta vía.

3.2.3. Alta neta de Subsección

RF4.1.4.1 _{Alta de subsección}

Versión ₁

Descripción _{Realizar el alta de una nueva subsección}

Prioridad _Alta

El alta de subsección se realizará asociada a una sección, siempre que no exista otra subsección en la misma sección con idénticos códigos. Tras completar el alta se asigna a la subsección un NIDEN único para su identificación.

(49)

3.2.4. Alta neta de APP

RF4.1.2.1 _{Alta de APP}

Versión ₁

Descripción _{Realizar el alta de una nueva APP}

Prioridad _Alta

El alta de APP se realizará asociada a una vía, siempre que no exista otra APP en la misma vía con idéntica numeración. Tras completar el alta se asigna a la APP un NIDEN único para su identificación.

Junto con el alta de un APP se podrá dar de alta los huecos correspondientes a esta APP. Al realizar el alta de una APP se puede asociar como perteneciente a una estructura existente definida por el usuario. Si la estructura tiene atributos con códigos pertenecientes a APP, se completarán los datos de la APP con los códigos definidos en la estructura.

3.2.5. Alta neta de Hueco

RF4.1.1.1 _{Alta de Vivienda}

Versión ₁

Descripción _{Realizar el alta de una nueva vivienda}

Prioridad _Alta

(50)

3.3. Baja neta de entidad de territorio

Realiza la baja de una entidad existente. Para entidades que realicen una división completa del territorio (entidad colectiva, entidad singular, núcleo/diseminado, distrito y sección) no será posible realizar la baja de una entidad aislada, sino que vendrá promovido por modificaciones más complejas como fusiones, segregaciones o cambio de límites.

(51)

3.3.1. Diagrama de Caso de Uso

Baja neta territorio Baja neta Vía Baja neta Subsección Baja neta APP Baja neta Hueco A 01.02.01

baja neta territorio baja neta

Vía A 01.02.01

baja neta territorio baja neta

Vía

A 01.02.02 baja neta territorio

baja neta

Subsección A 01.02.02 baja neta territorio

baja neta Subsección

A 01.02.03

baja neta APP A 01.02.03

baja neta APP

A 01.02.04 baja neta territorio

baja neta Hueco A 01.02.04

(52)

3.3.2. Baja neta de Vía

RF4.1.3.2 Baja de vía

Versión ₁

Descripción _{Realizar la baja de una vía existente}

Prioridad _Alta

Realiza la baja de una vía existente. En esta operación se podrán dar de baja las APPs incluidas en la vía. Cuando se da de baja una vía, ésta no deberá tener asociadas APPs activas.

3.3.3. Baja neta de Subsección

RF4.1.4.2 Baja de subsección

Versión ₁

Descripción _{Realizar la baja de una subsección existente}

Prioridad _Alta

Realiza la baja de una subsección existente.

(53)

3.3.4. Baja neta de APP

RF4.1.2.2 Baja de APP

Versión ₁

Descripción _{Realizar la baja de una APP existente}

Prioridad _Alta

Realiza la baja de una o varias APPs existentes. En esta operación se podrán dar de baja los huecos incluidos en las APPs que se dan de baja. Una APP solo se podrá dar de baja si no tiene huecos asociados, o si se dan de baja éstos.

3.3.5. Baja neta de Hueco

RF4.1.1.2 Baja de Vivienda

Versión ₁

Descripción _{Realizar la baja de una vivienda existente}

Prioridad _Alta

Realiza la baja de uno o varios huecos existentes.

3.4. Modificación de entidad de territorio

Realiza la modificación de entidades de territorio existentes.

(54)

3.4.1. Diagrama de Caso de Uso

Modificar territorio Modificar Entidad colectiva Modificar Entidad singular Modificar Nucleo / Diseminado Modificar Vía Modificar Distrito Modificar Sección Modificar Subsección Modificar APP Modificar Hueco A 01.03.01 modificar territorio modificar entidad colectiva _{A 01.03.01}

modificar territorio modificar entidad colectiva

A 01.03.02 modificación Territorio modificar entidad singular

A 01.03.03 modificar territorio

modificar nucleo diseminado

A 01.03.03 modificar territorio

modificar nucleo diseminado

A 01.03.04 modificar territorio Modificar vía A 01.03.04 modificar territorio Modificar vía A 01.03.07

modificar territorio A 01.03.07 modificar subSección

modificar territorio modificar subSección

(55)

3.4.2. Modificación de Entidad Colectiva

(56)

3.4.2.1. Diagrama de Caso de Uso Modificar Entidad colectiva Denominar E.C. A 01.03.01.01 entidad colectiva Denominar E.C. A 01.03.01.01 entidad colectiva Denominar E.C. Recodificar E.C. Segregar E.C. A 01.03.01.02 entidad colectiva

recodificar E.C. A 01.03.01.02 entidad colectiva recodificar E.C.

Fusionar E.C.

Cambiar límite E.C. A 01.03.01.04 entidad colectiva fusionar E.C. A 01.03.01.04 entidad colectiva fusionar E.C. A 01.03.01.05 entidad colectiva

cambiar límite E.C. A 01.03.01.05 entidad colectiva

cambiar límite E.C. A 01.03.01.03

entidad colectiva

segregar E.C. A 01.03.01.03

entidad colectiva

(57)

Avanza Local Padrón 2 – Análisis funcional territorio 57 3.4.2.2. Modificación de denominación de Entidad Colectiva

RF4.1.9.1 Denominación de entidad colectiva

Versión ₁

Descripción _{Modificar alguna de las denominaciones de una entidad colectiva}

Prioridad _Alta

Permitirá exclusivamente la modificación de las denominaciones de una Entidad Colectiva.

3.4.2.3. Recodificación de Entidad Colectiva RF4.1.9.2 Recodificación de entidad colectiva

Versión ₁

Descripción _{Recodificar alguno de los códigos existentes en una entidad colectiva}

Prioridad _Alta

Permitirá modificar alguno de los códigos que componen la entidad colectiva, así como su denominación. No permitirá la modificación de otros atributos de la entidad colectiva.

Deberá tenerse presente que una variación a nivel de código de EC implica necesariamente una variación en el código tanto de APP como de los núcleos y entidades singulares que contiene. Esta operación permite también la renumeración de las APPs.

(58)

Versión ₁

Descripción _{Fusionar dos o más entidades colectivas en una entidad colectiva}

nueva o existente

Prioridad _Alta

Consideramos una operación de fusión de dos EC cuando el resultado de la misma es una única EC que puede tener o no el mismo código de alguno de las implicadas, dándose de baja el resto de EC.

La fusión de EC dará lugar necesariamente a operaciones con las entidades singulares y núcleos pertenecientes a las EC que se fusionan. Estas operaciones podrán ir desde simples cambios de códigos a operaciones internas de fusión, segregación....etc.

A nivel de APP se recodificarán todas las APPs implicadas en la fusión, permitiendo también su renumeración.

3.4.2.5. Segregación de Entidad Colectiva RF4.1.9.3 Segregación de entidad colectiva

Versión ₁

Descripción _{Segregar una entidad colectiva en dos o más entidades colectivas}

nuevas

Prioridad _Alta

Consideramos una operación de segregación de una EC la operación mediante la cual se divide en varias EC. La Entidad Colectiva original podrá o no conservarse.

(59)

implicadas. Estas operaciones podrán ir desde simples cambios de códigos a operaciones internas de fusión, segregación... etc.

A nivel de APP se recodificarán todas las APPs implicadas en la segregación, permitiendo también su renumeración.

3.4.2.6. Cambio de límites de Entidad Colectiva RF4.1.9.5 Límites de entidad colectiva

Versión ₁

Descripción _{Cambiar los límites existentes entre dos o más entidades colectivas}

Prioridad _Alta

En una operación de cambio de límites una parte del contenido de un EC se traslada a otra/s EC ya existentes o a nuevas EC, que habrá que dar de alta en la operación.

Ahora bien, en cambio de límites de la EC puede implicar una modificación de código, operaciones de fusión, segregación o cambio de límites a nivel de alguna de las entidades singulares que la integran y, por tanto, de alguno de los núcleos que integran a estas entidades singulares, ya que todo el territorio que comprende la EC pertenece necesariamente a alguna de las entidades singulares que la forman.

A nivel de APP se recodificarán todas las APPs implicadas en el cambio de límites, permitiendo también su renumeración.

3.4.3. Modificación de Entidad Singular

(60)

3.4.3.1. Diagrama de Caso de Uso Modificar Entidad singular Denominar E.S. Recodificar E.S. Segregar E.S. Fusionar E.S.

Cambiar de límite E.S. A 01.03.02.01 entidad singular denominar E.S. A 01.03.02.01 entidad singular denominar E.S. A 01.03.02.03 entidad singular segregar E.S. A 01.03.02.03 entidad singular segregar E.S. A 01.03.02.02 entidad singular

recodificar E.S. A 01.03.02.02 entidad singular

recodificar E.S. A 01.03.02.04 entidad singular fusionar E.S. A 01.03.02.04 entidad singular fusionar E.S. A 01.03.02.05 entidad singular

cambiar de límite E.S.

A 01.03.02.05

entidad singular

(61)

Avanza Local Padrón 2 – Análisis funcional territorio 61 3.4.3.2. Modificación de denominación de Entidad Singular

RF4.1.8.1 Denominación de entidad singular

Versión ₁

Descripción _{Modificar alguna de las denominaciones de una entidad singular}

Prioridad _Alta

Permitirá exclusivamente la modificación de las denominaciones de una entidad singular.

3.4.3.3. Recodificación de Entidad Singular RF4.1.8.2 Recodificación de entidad singular

Versión ₁

Descripción _{Recodificar alguno de los códigos existentes en una entidad singular}

Prioridad _Alta

Permitirá modificar alguno de los códigos que componen la entidad singular, así como su denominación No permitirá la modificación de otros atributos de la entidad singular.

(62)

3.4.3.4. Fusión de Entidad Singular RF4.1.8.4 Fusión de entidad singular

Versión ₁

Descripción _{Fusionar dos o más entidades singulares en una entidad singular}

nueva o existente

Prioridad _Alta

Consideramos una operación de fusión de entidades singulares cuando el resultado de la misma es una única ES que puede tener o no el mismo código de alguno de las implicadas, dándose de baja el resto de ES.

La fusión de ES dará lugar necesariamente a operaciones con los núcleos pertenecientes a las ES que se fusionan. Estas operaciones podrán ir desde simples cambios de códigos a operaciones internas de fusión, segregación....etc.

A nivel de APP se recodificarán todas las APPs implicadas en la fusión, permitiendo también su renumeración.

3.4.3.5. Segregación de Entidad Singular RF4.1.8.3 Segregación de entidad singular

Versión ₁

Descripción _{Segregar una entidad singular en dos o más entidades singulares}

nuevas

Prioridad _Alta

(63)

La segregación de ES dará lugar necesariamente a operaciones con los núcleos pertenecientes a la ES que se segrega. Estas operaciones podrán ir desde simples cambios de códigos a operaciones internas de fusión, segregación o cambio de límites.

A nivel de APP se recodificarán todas las APPs implicadas en la segregación, permitiendo también su renumeración.

3.4.3.6. Cambio de límites de Entidad Singular RF4.1.8.5 Límites de entidad singular

Versión ₁

Descripción _{Cambiar los límites existentes entre dos o más entidades singulares}

Prioridad _Alta

En una operación de cambio de límites una parte del contenido de un ES se traslada a otra u otras ES. Las ES resultado de la operación podrán ser las ES de origen, o nuevas ES a las que se dará de alta.

Ahora bien, en cambio de límites de la ES puede implicar modificaciones de código, operaciones de fusión, segregación o modificación de límites a nivel de los núcleos que la integran ya que todo el territorio que comprende la ES pertenece necesariamente a alguno de los núcleos que la forman.

A nivel de APP se recodificarán todas las APPs implicadas en el cambio de límites, permitiendo también su renumeración.

3.4.4. Modificación de Núcleo/Diseminado

(64)

3.4.4.1. Diagrama de Caso de Uso Modificar Nucleo / Diseminado Denominar Nucleo / Diseminado Recodificar Nucleo / Diseminado Segregar Nucleo / Diseminado Fusionar Nucleo / Diseminado Cambiar de límite Nucleo / Diseminado A 01.03.03.01 nucleo / Diseminado denominar Nucleo / Diseminado A 01.03.03.01 nucleo / Diseminado denominar Nucleo / Diseminado A 01.03.03.02 nucleo / Diseminado recodificar

(65)

Avanza Local Padrón 2 – Análisis funcional territorio 65 3.4.4.2. Modificación de denominación de Núcleo/Diseminado

RF4.1.7.1 Denominación de núcleo

Versión ₁

Descripción _{Modificar alguna de las denominaciones de un núcleo/diseminado}

Prioridad _Alta

Permitirá exclusivamente la modificación de las denominaciones de un núcleo.

3.4.4.3. Recodificación de Núcleo/Diseminado RF4.1.7.2 Recodificación de núcleo

Versión ₁

Descripción _{Recodificar alguno de los códigos existentes en un}

núcleo/diseminado

Prioridad _Alta

Permitirá modificar alguno de los códigos que componen el núcleo así como su denominación. No permitirá la modificación de otros atributos del núcleo/diseminado.