http://www.ilustrados.com/documentos/Diagnostico-urbano-arquitectonico-de-Ciudad.pdf

RESUMEN
Automatización de los indicadores y variables patrimoniales, arquitectónicas y urbanas
para el manejo de las potencialidades del cambio de uso, restauración, conservación y
posibilidades de inversión en los inmuebles del Centro histórico de Camagüey.
Para la labor de refuncionalización de los centros histórico resulta necesario conocer el
potencial de cambio de uso con que cuenta en función de restablecer las estructuras
socioeconómicas devaluadas ante las exigencias contemporáneas para establecer una
estrategia que lejos de devaluar el centro histórico como Monumento Nacional, afiance
sus peculiaridades.
La creación de un sistema de indicadores y variables que sirva de estrategia al plan de
manejo del potencial de uso en los centros históricos exige de la interrelación de
indicadores patrimoniales arquitectónicos y urbanos que permitan la conservación del
centro por sus valores como conjunto urbano y no atendiendo a los monumentos
arquitectónicos.
Este software es de interés para todas aquellas entidades cuyo objeto se relaciona con
el planeamiento, control y gestión en las áreas de interés patrimonial, además de
permitirnos la proyección sobre bases reales en los análisis de la asignatura de
Proyecto Urbano Arquitectónico VI, el que se vincula específicamente con los temas de
la conservación y restauración. La creación de este instrumento, es de incuestionable
valor permitiéndonos la elaboración de una estrategia correcta en estas áreas.
En la actualidad no se cuenta con ningún Software que realice esta labor por lo que la
confección de este será de mucha ayuda para tratar las temáticas anteriormente dichas.
Con la realización de este software se podrá definir un sistema de indicadores y
variables patrimoniales y a partir de estos valorar la potencialidad de cambio de uso de
las edificaciones del Centro Histórico de la Ciudad de Camagüey
FUNDAMENTACION DEL TEMA.......................................................................................... 10
INTRODUCCIÓN .............................................................................................................. 10
¿POR QUÉ ES NECESARIO AUTOMATIZAR EL CENTRO HISTORICO DE CAMAGUEY? ...... 10
SITUACION PROBLEMICA Y PROBLEMA ARESOLVER. ......................................................... 11
1.4
SOLUCIONES EXISTENTES. ...................................................................................................... 12
1.5
DESCRIPCIÓN DE LOS CONCEPTOS ASOCIADOS A LA SOLUCIÓN DEL PROBLEMA. ......... 13
1.6
TECNOLOGÍAS Y REFERENCIAS BIBLIOGRÁFICAS. ......................................................... 14
1.7
FUNDAMENTACIÓN DE LOS OBJETIVOS QUE SE PROPONE EL TRABAJO. ........................ 14
1.7.1 Objetivos generales ............................................................................................................... 14
1.7.2 Objetivos específicos ................................................................................................. 15
1.7.3 Objetivos específicos del sistema. ............................................................................. 12
1.8
APORTES PRÁCTICOS ESPERADOS DEL TRABAJO. .......................................................... 12
1.9
CONCLUSIONES. ............................................................................................................. 13
1.1
1.2
1.3
TENDENCIAS Y TECNOLOGÍAS ACTUALES A CONSIDERAR .................................... 14
2.1 INTRODUCCIÓN. ................................................................................................................... 14
2.2 LENGUAJE VISUAL C#.NET................................................................................................. 15
2.3 MICROSOFT SQL SERVER COMO GESTOR DE BASES DE DATOS. ......................................... 20
2.4 METODOLOGÍA RUP, LENGUAJE UML. ............................................................................... 23
2.5 CONCLUSIONES. ................................................................................................................... 24
DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA............................................................... 28
3.1 INTRODUCCIÓN. ................................................................................................................... 28
3.2 ESTADO ACTUAL DEL NEGOCIO. .......................................................................................... 29
3.3 MODELO DEL NEGOCIO. ....................................................................................................... 30
3.3.1 Reglas del negocio........................................................................................................ 31
3.3.2 Modelo de casos de usos del negocio. .......................................................................... 32
3.4 REQUISITOS FUNCIONALES. ................................................................................................. 34
3.5 REQUISITOS NO FUNCIONALES. ............................................................................................ 40
3.6 DESCRIPCIÓN DEL SISTEMA PROPUESTO. ............................................................................. 43
3.6.1 Concepción General del Sistema.................................................................................. 43
3.7 MODELO CASO DE USO DEL SISTEMA. ................................................................................ 44
3.7.1Los actores del sistema. ................................................................................................. 42
3.7.2 Los casos de usos del sistema. ...................................................................................... 42
3.7.3 Descripción de los casos de usos del sistema............................................................... 44
3.8 DIAGRAMA DE CASOS DE USOS DEL SISTEMA. ..................................................................... 72
3.9 CONCLUSIONES. ................................................................................................................... 72
CONSTRUCCIÓN DE LA SOLUCIÓN PROPUESTA .......................................................... 73
4.1 INTRODUCCIÓN. ................................................................................................................... 73
4.2 MODELO DE DISEÑO. ........................................................................................................... 74
4.3 DIAGRAMA DE CLASES. ....................................................................................................... 74
4.4 DIAGRAMA MODELO DE DATOS. ......................................................................................... 74
4.5 DIAGRAMA DE CLASES PERSISTENTES. ............................................................................... 74
4.6 PRINCIPIOS DE DISEÑO......................................................................................................... 74
4.6.1 Estándares de Codificación. ......................................................................................... 72
4.6.2 Formato de los Reportes. ............................................................................................. 73
4.6.3 Concepción General de la Ayuda. ................................................................................ 73
4.6.4 Tratamiento de excepciones. ................................................................................................. 74
4.7 MODELO DE DESPLIEGUE. ................................................................................................... 76
4.8 MODELO DE IMPLEMENTACIÓN. ........................................................................................ 76
4.8.1 Diagrama de Componentes. ......................................................................................... 76
4.9 CONCLUSIONES. ................................................................................................................... 76
ESTUDIO DE FACTIBILIDAD ................................................................................................ 81
5.1 INTRODUCCIÓN. ................................................................................................................... 81
5.2 PLANIFICACIÓN. ................................................................................................................... 82
5.3 BENEFICIOS TANGIBLES E INTANGIBLES. ............................................................................. 83
5.3.1 Beneficios tangibles. ..................................................................................................... 83
5.3.2 BENEFICIOS INTANGIBLES. ............................................................................................... 84
5.4 ANÁLISIS DE COSTOS Y BENEFICIOS. ................................................................................... 84
5.5 CONCLUSIONES. ................................................................................................................... 85
CONCLUSIONES. ...................................................................................................................... 89
RECOMENDACIONES. ............................................................................................................ 90
REFERENCIAS BIBLIOGRÁFICAS. ..................................................................................... 91
BIBLIOGRAFÍA. ........................................................................................................................ 93
GLOSARIO DE TÉRMINOS. ................................................................................................... 94
ANEXOS. ........................................................................... ERROR! BOOKMARK NOT DEFINED.7
INTRODUCCIÓN
Los centros históricos constituyen la memoria viva de la evolución histórica y cultural de
los pueblos, en su interior sobreviven no solo las tradiciones y costumbres más antiguas
sino además están representados los valores arquitectónicos y urbanos más genuinos
del patrimonio edificado. La importancia que cobran hoy esos conjuntos, acrecienta la
necesidad de conocerles científicamente de ahí que se convierta en objeto de estudio
de investigadores e instituciones de todo el mundo, en particular en relación a la
búsqueda de respuesta a la demanda de su cuidado y protección en medio de una
puesta en valor que le haga rentable en coordenadas de incontrolable globalización y
desarrollo tecnológico.
Como áreas de especiales características dentro de la ciudad, los centros históricos son
consecuencia de una continua estratificación y compenetración de épocas distintas,
fruto de una rica yuxtaposición de lenguajes arquitectónicos y urbanos que evidencian la
correspondencia entre espacio físico y las necesidades generadas por un nuevo modo
de vida de sus habitantes. De modo que la continua relación entre la ciudad histórica y
el hombre actual da lugar al primordial problema de los centros históricos: el polémico
criterio de su conservación y rehabilitación. Se trata, como refiere Giorgio Piccinato, de
“lograr un equilibrio entre la permanencia y el reforzamiento de sus valores sin negar la
renovación de algunos de sus elementos, manteniendo su coherencia y riqueza de
expresión que la hace reconocible como tal”.
Por tanto el objeto de estudio de este trabajo es Plan Maestro y Gestión de la Oficina
del Historiador.
De aquí, se deriva que el campo de acción queda enmarcado en la automatización de
los procesos para la determinación de las potencialidades de cambio de uso, acciones
de mantenimiento y oportunidades de inversión en las edificaciones del centro histórico
de la ciudad de Camagüey.
El objetivo general de este trabajo será: Proponer un sistema de indicadores y variables
que integre los indicadores patrimoniales con los arquitectónicos y urbanos. Este
sistema permite trazar una estrategia de intervención general en los centros históricos
sobre la base de defender sus valores como conjunto urbano. Además que nos brinda
la posibilidad de clasificar las Unidades Edificatorias de acuerdo a sus potencialidades
para cambio de uso.
De aquí, se derivan los siguientes objetivos específicos:
•
Realizar el proceso de análisis y diseño del sistema empleando la metodología
RUP y el lenguaje UML, esto implica realizar el modelo del negocio y el modelo
del sistema. Para la representación grafica de ambos modelos se empleara la
herramienta CASE (Racional Rose).
•
Seleccionar los lenguajes de programación y gestor de base de datos que
permitan, darle solución a la problemática propuesta.
•
Implementar en los lenguajes de programación y gestor de base de datos
seleccionados los algoritmos desarrollados en las fases de análisis y diseño.
•
Poner a prueba el sistema.
Las tareas desarrolladas para cumplir los objetivos.
Para cumplir los objetivos desde el punto de vista arquitectónico se tomó como
referencia tesis de maestría de la arquitecta Elvira Sariol haciendo una revisión
bibliográfica de la misma.
Para la selección del tipo de aplicación, es decir una aplicación de escritorio, la
tecnología, como es el caso de la selección del lenguaje de programación y del tipo del
gestor de base de datos, y la metodología a utilizar, ADDOSI o RUP, se uso el MSDN
de Visual Studio de .NET.
Se realizaron entrevistas tanto físicas como a través del correo electrónico al usuario y a
personas interesadas en la confección de la aplicación para lograr la obtención de los
requerimientos. También a personal capacitado y actualizado en las nuevas tecnologías
de la informática para la selección de la tecnología a utilizar.
Se hizo un estudio de las ventajas del lenguaje, gestor de base de datos y herramienta
de análisis y diseño, llegando a la selección de C#, SQL-Server y RUP, con UML como
lenguaje.
La empresa esta orientada a la compilación, creación, estudio y puesta en práctica del
sistema de información que establece los parámetros de funcionalidad del centro
histórico, el uso potencial del suelo, controlando el comportamiento actual y perspectivo
de este, participa en la creación de las estrategias de intervención dirigidas a
transformar el medio, generando propuestas de intervención en todo tipo de
infraestructura,
reglamentando
y
normalizando
la
forma
de
realizar
las
transformaciones, apoyándose siempre en trabajos de investigación que van desde el
aspecto histórico del problema hasta las valoraciones sociológicas que este implica y
que de este emergen.
El contenido está estructurado en cinco capítulos fundamentales. El primero,
Fundamentación del Tema muestra aspectos generales del centro Histórico de la
Ciudad de Camagüey y su funcionamiento, así como el porqué de la informatización.
También se tratan elementos importantes relacionados con la necesidad del sistema
para una respuesta rápida, el estudio de tecnologías para el desarrollo de aplicaciones
eficientes, las soluciones de código abierto y los gestores de bases de datos.
En el segundo capítulo, Fundamentación teórica, criterio de selección de tecnología.
El tercer capitulo, Descripción de la Solución Propuesta, aborda los flujos de trabajo de
diseño donde se modelan un grupo de artefactos, se exponen los elementos
reutilizados, los estándares de programación y diseño de interfaz, así como las medidas
de seguridad a tener en cuenta. El cuarto capitulo es Construcción de la solución
propuesta, explicar el diseño del flujo de implementación, viéndolo desde ese punto de
vista.
El quinto y último capítulo, Estudio de Factibilidad, lleva a cabo la planificación del
proyecto, así como el análisis de costos y beneficios involucrados en la realización del
mismo.
Capítulo I Fundamentación del Tema
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
1
Capítulo
FUNDAMENTACION DEL TEMA
1.1
Introducción
En el presente capítulo se brinda una visión general de los aspectos relacionados con la
automatización de las variables del centro histórico de Camagüey. Se informa sobre la
descripción de los principales conceptos asociados al problema que son necesarios
para entender el negocio
Además se describen los procesos del negocio que se relacionan con el objeto de
estudio de este trabajo. Se identifican los principales problemas que fundamentan la
propuesta de solución, y se marcan los objetivos generales y específicos.
1.2
¿Por que es necesario automatizar el Centro Histórico de Camagüey?
Existen cinco razones fundamentales por las cuales es necesario el sistema DUAC
versión 1.0:
1. Resulta muy complicado actualizar las planillas de registros de las oficinas del
centro histórico, pues solo puede hacerse borrando los datos en la misma cada vez que
7
Capítulo I Fundamentación del Tema
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
se modifica, por lo que todo gasto tanto de recursos humanos como los económicos es
considerable al de cursar del tiempo.
2. Es prácticamente imposible consultar esta información, son miles de inmuebles los
que se ubican en la ciudad, por muy organizado que se conserven los expedientes no le
es factible a los técnicos consultarlas con frecuencia, primero porque la actividad de
trámites tanto a particulares como estatales es muy operativa, o sea para cada trámite
evidentemente se necesita consultar la información, pero la planilla solo permite hacer
un análisis elemental de los datos que en ella se recogen, pues es necesario realizar
cruce entre las diferentes variables pare poder valorar los datos y, no obstante solo así
podemos tener resultados parciales, pues para un análisis a escala urbana se requiere
de conocer el comportamiento de un área de considerable dimensiones.
3. A pesar de contar con un archivo de datos este no puede explotarse como es
debido, el personal existente no da abasto para en el tiempo previsto emitir respuestas
correctas, generándose nuevos libros de control sobre la actividad.
4. Se dificulta hasta el extremo la elaboración del Plan Estratégico, pues este
instrumento debe contar con un diagnóstico detallado que nos permita evaluar el
territorio, por lo que se hace inoperante el manejo de la información, solo permite
trabajar temáticas a pequeña escala., donde toda la información se procesa
manualmente.
5. Así mismo se cuenta con una base cartográfica muy desactualizada, que nos impide
contar con los planos temáticos que requieren los diferentes análisis, o elaborarlos las
veces que son necesarios para ilustrar diferentes situaciones.
1.3 Situación problémica y problema a resolver.
Necesidad imperiosa de agudizar los análisis a escala arquitectónica y urbanística, con
el objetivo de elaborar el Plan de Manejo de la ciudad total o parcialmente,
estableciendo así la estrategia de intervención a través del planeamiento, gestión y
correcto control del territorio. Pero para realizar un diagnostico confiable debemos
8
Capítulo I Fundamentación del Tema
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
procesar el inventario y actualizarlo constantemente, eso solo es posible si se
computariza. Fue necesario crear una herramienta útil que garantice a través de un
programa computarizado aplicar una correcta metodología de análisis, partiendo de una
base de datos literal lo cual nos permite lograr la información necesaria con garantía,
rapidez y permanentemente actualizada. Los resultados obtenidos facilitan a los
técnicos además del estudio del territorio, emitir soluciones alternativas a las diferentes
demandas los cuales no siempre pueden prolongarse en tiempo y generalmente
comprometen el estudio urbano. Además el técnico le podrá brindar al usuario un
cuerpo de regulaciones sobre la acción a realizar que garantice el correcto uso del
inmueble.
1.4
Soluciones existentes.
Se conoce de la existencia de un SIG actualizado por la Dirección del Plan Maestro de
la OHHV, 2004. Además de un fichaje y modo de presentación actualizado por la
Dirección Plan Maestro de la OCC en Santiago de Cuba, 2004. En el mundo existen
otros sistemas semejantes al que se desea implantar en el Centro Histórico de la
Ciudad de Camagüey, uno es un Sistema automatizado de Información o Inventario de
Monumentos y Sitios. Puebla, México.1996. Otro sistema es el de Inventario en España
para el centro histórico de Mondoñedo, Galicia, España, 1998.
Este software es de interés para todas aquellas entidades cuyo objeto se relaciona con
el planeamiento, control y gestión en las áreas de interés patrimonial, además de
permitirnos la proyección sobre bases reales en los análisis de la asignatura de
Proyecto Urbano Arquitectónico VI, el que se vincula específicamente con los temas de
la conservación y restauración. La creación de este instrumento, es de incuestionable
valor permitiéndonos la elaboración de una estrategia correcta en estas áreas.
En la actualidad no se cuanta con ningún Software que realice esta labor por lo que la
confección de este será de mucha ayuda para tratar las temáticas anteriormente dichas.
9
Capítulo I Fundamentación del Tema
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
1.5 Descripción de los conceptos asociados a la solución del problema.
Para la labor de refuncionalización de los centros histórico resulta necesario conocer el
potencial de cambio de uso con que cuenta en función de restablecer las estructuras
socioeconómicas devaluadas ante las exigencias contemporáneas para establecer una
estrategia que lejos de devaluar el centro histórico como Monumento Nacional, afiance
sus peculiaridades.
La creación de un sistema de indicadores y variables que sirva de estrategia al plan de
manejo del potencial de uso en los centros históricos exige de la interrelación de
indicadores patrimoniales arquitectónicos y urbanos que permitan la conservación del
centro por sus valores como conjunto urbano y no atendiendo a los monumentos
arquitectónicos.
Existen conceptos en el sistema que son de gran utilidad conocer su significado dentro
de los términos de la arquitectura de la ciudad:
Unidad Edificatoria: es el elemento clave para los análisis urbanos, es la unidad básica
en el patrimonio edificado., esta se dividen en lo que se llama desgloses.Luego de un
análisis valorativo de cada variable que se analiza en conjunto en la Unidad Edificatoria,
podremos evaluar la misma, para ello se validan los datos de cada desglose llegando a
valores únicos en cada variable para la Unidad Edificatoria.
Los indicadores y las variables seleccionadas para el análisis de los inmuebles de la
ciudad se clasifican en 4 grupos: localización (no. de UBIT, no. de manzana, no de
desglose), arquitectónicas (valor, carácter, estado constructivo, transformaciones, estilo,
época, uso, modificaciones, no. de plantas), urbanas(área de lote, área construida,
puntal, longitud de la fachada, si la fachada da a plaza, existencia de portal, presencia
de galería, sociales(cantidad de habitantes y nivel de vida).
Existen cuatro conceptos fundamentales en los cuales se sustenta el sistema:
Grado de protección (I, II, III, IV), si el inmueble constituye potencial o no para cambio
de uso, categoría tipológica que presenta, y su estado constructivo.
10
Capítulo I Fundamentación del Tema
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
1.6 Tecnologías y referencias bibliográficas.
La tecnología utilizada para el desarrollo del sistema:
SQL-SERVER, como gestor de Base de Datos.
C#, como lenguaje de programación.
RUP, con lenguaje UML, para el análisis y diseño del sistema.
La referencias bibliográficas utilizadas como fuente de información para el caso de la
información arquitectónica se tomo el Trabajo presentado en opción del título de
maestría en Conservación del Patrimonio Edificado de la arquitecta Elvira Sariol
Hernández, profesora de arquitectura de la Universidad de Camagüey.
Para obtener información acerca de la tecnología, metodología y del tipo de aplicación a
utilizar se uso el MSDN de Visual Studio.NET, el texto El proceso unificado de
desarrollo de software, volumen 1, Jacobson, Booch, Rumbaugh, y el de Ingeniería de
software con UML, Leyton Eduardo, tutoriales extraídos de Internet sobre C# y SQLSERVER.
1.7 Fundamentación de los objetivos que se propone el trabajo.
Para darle respuesta a la situación problemática planteada, se propone para este
trabajo un conjunto de objetivos:
1.7.1 Objetivos Generales:
Proponer un sistema de indicadores y variables que integre los indicadores
patrimoniales con los arquitectónicos y urbanos. Este sistema permite trazar una
estrategia de intervención general en los centros históricos sobre la base de defender
sus valores como conjunto urbano. Además que nos brinda la posibilidad de clasificar
las Unidades Edificatorias de acuerdo a sus potencialidades para cambio de uso.
1.7.2 Objetivos específicos:
1. Realizar el proceso de análisis y diseño del sistema empleando la metodología RUP y
el lenguaje UML, esto implica realizar el modelo del negocio y el modelo del sistema.
11
Capítulo I Fundamentación del Tema
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Para la representación grafica de ambos modelos se empleara la herramienta CASE
(Racional Rose).
2. Seleccionar los lenguajes de programación y gestor de base de datos que permitan,
darle solución a la problemática propuesta.
3. Implementar en los lenguajes de programación y gestor de base de datos
seleccionados los algoritmos desarrollados en las fases de análisis y diseño.
4. Poner a prueba el sistema.
1.7.3 Objetivos específicos del sistema.
1. Determinar los indicadores y variables patrimoniales y arquitectónicas que se deben
tener en cuenta para establecer un manejo del potencial de uso de los inmuebles
ubicados en el centro histórico de Camagüey.
2. Establecer un sistema de indicadores y variables que posibilite trazar una estrategia
en el manejo del potencial de uso en correspondencia con su ubicación en la estructura
urbana, las categorías tipológicas y los valores patrimoniales.
3. Definir la clasificación tipológica y las funciones compatibles en los inmuebles del
centro histórico de acuerdo a su potencial de cambio de uso.
1.8 Aportes prácticos esperados del trabajo.
1. Con la realización de este software se podrá definir un sistema de indicadores y
variables patrimoniales y a parir de estos valorar la potencialidad de cambio de uso de
las edificaciones del Centro Histórico de la Ciudad de Camagüey.
2. Determinar un conjunto de categorías tipológicas en base a metodologías
internacionales aplicadas a la formación y evolución de la arquitectura y el urbanismo de
12
Capítulo I Fundamentación del Tema
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
la ciudad de Camagüey en busca de probada cientificidad y aplicabilidad en los análisis
del centro histórico.
3. Contar con una base de datos, que posibilita realizar una serie de consultas,
cuantitativa y cualitativa, acerca de las unidades edificatorias del centro histórico.
1.9 Conclusiones.
En el presente capítulo se muestra cuán grande es el volumen de la información que se
maneja y cuán extensa es la labor que realiza el personal que trabaja en el centro
histórico de la ciudad de Camagüey por la Dirección de Plan Maestro de l Oficina del
Historiador de la Ciudad, elementos que, entre otros, demuestran la necesidad del
tratamiento informatizado de las variables para el inventario
13
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
2
Capítulo
TENDENCIAS Y TECNOLOGÍAS ACTUALES A
CONSIDERAR.
2.1 Introducción.
La aplicación se realizará en Visual Studio .Net específicamente en C#. Como gestor de
base de datos el SQL-Server con T-SqlServer como lenguaje y para la metodología de
análisis y diseño se usará la metodología RUP, con el lenguaje UML.
Los sistemas gestores de base de datos (SGBD) son los encargados de manipular la
información almacenada en las bases de datos y definir las estructuras para su
almacenamiento. En estos sistemas existe sólo una copia de los datos para que todos
los programas trabajen con ella. Otra de sus características es la capacidad de
interactuar en un ambiente cliente/servidor donde los usuarios trabajan con un conjunto
único de datos alojados en un servidor y al mismo tiempo.
El lenguaje de programación C#, fue el lenguaje nativo que surgió con el Visual Studio
y no es una adaptación como el caso de las ultimas versiones de Delphi y el Visual C++
.NET.
14
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Aunque es posible escribir código para la plataforma .NET en muchos otros lenguajes,
C# es el único que ha sido diseñado específicamente para ser utilizado en ella, por lo
que programarla usando C# es mucho más sencillo e intuitivo que hacerlo con
cualquiera de los otros lenguajes ya que C# carece de elementos heredados
innecesarios en .NET. Por esta razón, se suele decir que C# es el lenguaje nativo de
.NET.
2.2 Lenguaje Visual C#.NET.
C# supone una mejora respecto a otros lenguajes existente por que es el último, y por lo
tanto, el más adaptado a las necesidades actuales del programador y el que más ha
aprendido de los demás, heredando lo mejor de cada entorno, y añadiendo las cosas
que los programadores solicitaban.
Una de las características principales de C# es que se trata de un lenguaje que compila
(por defecto) a un formato intermedio, al estilo de Java, denominado Intermediate
Language (IL), que posteriormente, debe de ser interpretado por un entorno de
ejecución, una máquina JIT (just-in-time), también al estilo de Java. La gran diferencia
respecto a Java es que, ése intérprete será común a todos los lenguaje soportados por
el entorno de ejecución y mediante este mecanismo permitirá que los componentes
realizados en cualquier lenguaje puedan comunicarse entre sí.
Se trata pues, de una extensión del concepto inicial que dio origen a Java: en lugar de
un único lenguaje para muchas plataformas, se pretende un entorno común
multiplataforma, que soporte muchos lenguajes, basándose en que todos ellos compilen
a un mismo código intermedio. Para hacer viable esta idea, se ha optimizado
considerablemente la velocidad, respecto a Java y ya se están anunciando los primeros
.NET Framework para otras plataformas.
Permite la integración de los diferentes lenguajes soportados por el entorno común de
ejecución (CLR), se basa en la existencia un conjunto común de tipos de datos que
coinciden para cualquier lenguaje La principal ventaja que tiene un sistema de tipos
común radica en la seguridad. Seguridad en la conversión de tipos y garantía de que
15
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
cualquier lenguaje que utilizará el CTS podrá interpretar e interactuar con módulos
creados en otros lenguajes sin traducciones.
Sin duda, una de las novedades del lenguaje C# en comparación con sus similares
(C++, Java) es la presencia de las propiedades, también llamadas campos inteligentes,
que no son sino métodos de acceso a los campos de una clase, que se ven como
campos desde el cliente de esa clase. Se trata de un mecanismo más elegante de
acceso al estado de una clase, y una de las aportaciones que el lenguaje C# realiza a la
mejora de las técnicas de encapsulación en los lenguajes OOP.
Bases sobre las que se asienta la construcción de un programa escrito en C#:
1) Todo programa compilado para el entorno común de ejecución (CLR) comparte un
mismo código intermedio (Intermediate Language ó IL) que debe ser ejecutado por un
intérprete JIT que resida en la plataforma de ejecución. Aunque pueden distinguirse
entre componentes y ejecutables, en éste último caso, el formato resultante es
independiente del lenguaje que se utilizó en su escritura. El formato de los ejecutables
independientes se denomina PE (Portable Executable).
2) El entorno común de ejecución (CLR) es invocado por cualquier programa escrito en
el formato PE, y es quien se hace cargo del mantener la zona de memoria en la que se
ejecuta el programa y suministra un sistema de tipos de datos común (Common Type
System), que describe los tipos soportados por el intérprete y cómo estos tipos pueden
interactuar unos con otros y cómo puede ser almacenados en meta datos.
3) Los servicios del sistema operativo se suministran mediante librerías (DLL)
dispuestas por el CLR cuando se instala .NET Framework en una plataforma (Windows,
McIntosh, Linux, etc.). Dichas librerías son referenciadas en el código de C# mediante la
sentencia using seguida del nombre de la librería deseada. Tales declaraciones reciben
el nombre de Espacios Calificados o Espacios con Nombre Namespaces (un
namespace es una forma adecuada de organizar clases y otros tipos de datos en una
jerarquía. Podríamos decir que sirven al mismo tiempo para 3 propósitos: organizar
(dentro de la jerarquía), para firmar (o marcar de forma única) fragmentos de código
16
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
como pertenecientes a ese namespace, evitando colisiones con otros fragmentos que
puedan contener definiciones iguales, y como método de abreviación, ya que una vez
declarado el namespace podemos referirnos a sus contenidos en el código sin
necesidad de repetir toda la secuencia jerárquica).
4) En C#, todo puede ser tratado como un objeto, aunque no obligatoriamente, y sin la
penalización que supone esta característica en lenguajes orientados a objetos "puros",
como SmallTalk. Por tanto cualquier código en C# estará incluido en una clase, ya sea
esta instanciada o no. Además, se protege la inversión realizada previamente en
desarrollo, ya que permite la llamada a componentes COM, a librerías nativas del API
de Windows (DLL's), permite el acceso de bajo nivel cuando sea apropiado y los
ejecutables y componentes producidos con él se integran perfectamente con otros
ejecutables o componentes realizados en otros lenguajes del entorno.
5) La sintaxis de C# recuerda bastante la de Java, si bien los conceptos implicados en
la construcción de objetos, tipos, propiedades, métodos, y eventos no suelen ser
idénticos teniendo -en ocasiones- notables diferencias conceptuales. La mayor similitud
se encuentra, como cabía esperar, en el tratamiento de las estructuras de control del
programa (prácticamente idénticas a C++ y Java.
2.3 Microsoft SQL Server como gestor de Bases de Datos.
SQL Server es un sistema administrador para Bases de Datos relacionales basadas en
la arquitectura Cliente / Servidor (RDBMS) que usa Transact-SQL para mandar
peticiones entre un cliente y el SQL Server.
SQL Server usa la arquitectura Cliente / Servidor para separar la carga de trabajo en
tareas que corran en computadoras tipo Servidor y tareas que corran en computadoras
tipo Cliente:
•
El Cliente es responsable de la parte lógica y de presentar la información al usuario.
Generalmente, el cliente corre en una o más computadoras Cliente, aunque también
puede correr en una computadora Servidor con SQL Server.
•
SQL Server administra Bases de Datos y distribuye los recursos disponibles del
servidor (tales como memoria, operaciones de disco, etc.) entre las múltiples peticiones.
17
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Éste es una versión de SQL (Structured Query Languaje) usado como lenguaje de
programación para SQL Server.
SQL es un conjunto de comandos que permite
especificar la información que se desea restaurar o modificar. Con Transact – SQL se
puede tener acceso a la información, realizar búsquedas, actualizar y administrar
sistemas de Bases de Datos Relacionales.
SQL Server está integrado con el sistema de seguridad de Windows NT. Esta
integración permite acceder tanto a Windows NT como a SQL Server con el mismo
nombre y contraseña. Además SQL Server una las características de encriptación que
Windows NT para la seguridad en red. SQL Server está provisto de su propia seguridad
para clientes no-Microsoft.
SQL Server usa una arquitectura de comunicación por capas para aislar aplicaciones
internas de red y protocolos. Esta arquitectura permite desplegar la misma aplicación
en diferentes ambientes de red. Los componentes en la arquitectura de comunicación
incluyen:
•
APLICACIÓN: Una aplicación es desarrollada usando una aplicación de interfaz de
programación para Base de Datos (API). La aplicación no tiene conocimiento de los
protocolos internos de red usados para la comunicación con SQL Server.
•
INTERFAZ DE LA BASE DE DATOS: Esta es una interfaz usada por una aplicación
para mandar peticiones a SQL Server y procesar los resultados devueltos por SQL
Server.
•
LIBRERÍA DE RED: Este es un componente de Software de comunicación que
empaqueta las peticiones de la Base de Datos y los resultados para transmitirlos por
medio del protocolo de red apropiado. Una librería de Red, también conocida como
Net-Library, debe ser instalada tanto en el cliente como en el servidor. Tanto Clientes
como Servidores pueden usar más de una Net-Library al mismo tiempo, pero deben
usar una Librería de Red común para comunicarse satisfactoriamente. SQL Server
soporta protocolos de red tales como TCP/IP, Novell, IPX/SPX, Banyan VINES/IP,
Named Pipes, y Apple Talk ADSP.
•
TABULAR DATA STREAM: (TDS) Es un protocolo por niveles de aplicación usado
para la comunicación entre un Cliente y SQL Server.
Los paquetes TDS son
encapsulados en los paquetes de red hechos por la protocolo stak usada por las NetLibraries.
18
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
•
SERVICIOS OPEN DATA: Este es un componente de SQL Server que se encarga
de las conexiones de red, pasando las peticiones del cliente al SQL Server para
procesar
y
regresar
cualquier resultado a
los
Clientes.Open
Data
escucha
automáticamente en todas las Net-Libraries que están instaladas en el servidor.
SQL Server valida a los usuarios con 2 niveles de seguridad; autentificación del login y
validación de permisos en la Base de Datos de cuentas de usuarios y de roles. La
autentificación identifica al usuario que está usando una cuenta y verifica sólo la
habilidad de conectarse con SQL Server. El usuario debe tener permiso para acceder a
las Bases de Datos en el Servidor. Esto se cumple para asignar permisos específicos
para la Base de Datos, para las cuentas de usuario y los roles. Los permisos controlan
las actividades que el usuario tiene permitido realizar en la Base de Datos del SQL
Server.
Después de que los usuarios han sido autentificados, y se les ha permitido conectarse
al SQL Server, deben tener cuentas en la Base de Datos. Las cuentas de usuario y los
roles, identifican permisos para ejecutar tareas.
Las cuentas de usuario utilizadas para aplicar permisos de seguridad son las de
usuarios, o grupos de Windows NT o las de SQL Server. Las cuentas de usuario son
específicas para cada Base de Datos.
Permiten reunir a los usuarios en una sola unidad a la cual se le pueden aplicar
permisos. SQL Server contiene roles de servidor y de Base de Datos predefinidos, para
tareas administrativas comunes, de manera que pueden asignársele determinados
permisos administrativos a un usuario en particular. También se pueden crear roles de
Base de Datos definidos por el usuario.
En SQL Server, los usuarios pueden
pertenecer a varios roles:
•
Roles fijos del Servidor: Proveen agrupamientos con privilegios administrativos a
nivel del Servidor. Son administrados independientemente de las Bases de Datos de
usuarios a nivel servidor.
•
Roles fijos de la Base de Datos: Proveen agrupamientos con privilegios
administrativos a nivel de Base de Datos.
•
Roles de usuarios definidos en la Base de Datos: También se pueden crear roles
para Base de Datos, para representar un trabajo desarrollado por un grupo de
empleados dentro de una organización. No es necesario asignar y quitar permisos a
19
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
cada persona. En función de que cambia un rol, se pueden cambiar fácilmente los
permisos del rol y hacer que los cambios se apliquen automáticamente a todos los
miembros del rol.
Implementar una Base de Datos en SQL Server significa planear, crear y mantener un
número de componentes interrelacionados.
La naturaleza y complejidad de una
aplicación de Base de Datos, así como el proceso de planearla puede variar enormente.
Por ejemplo, una Base de Datos puede ser relativamente simple, diseñada para ser
usada por una sola persona, o puede ser grande y compleja, diseñada para atender
todas las transacciones de cientos o miles de clientes.
En cuanto al tamaño y complejidad de la Base de Datos, generalmente la
implementación de una Base de Datos involucra:
1. Diseñar la Base de Datos de manera que la aplicación optimice el uso de Hardware
y permita crecimiento futuro, identificar y modelar objetos de la Base de Datos y
aplicaciones de lógica, y especificar tipos de información para cada objeto y tipo de
relación.
2. Crear la Base de Datos y los objetos, incluyendo tablas, mecanismos de integridad
de datos, entrada de datos y objetos, índices y seguridad.
3. Probar la aplicación y la base de Datos. Cuando se diseña una Base de Datos, se
desea asegurar que la Base de Datos realiza las funciones importantes en forma rápida
y correcta.
4. Planear el funcionamiento, lo que incluye analizar la carga de trabajo y recomendar
una configuración óptima para la Base de Datos de SQL Server.
5. Administrar la aplicación, lo que incluye configurar a los clientes y servidores,
monitorear el funcionamiento del Server, administrar tareas, alertas y operadores,
administrar seguridad y procedimiento de backup de la Base de Datos.
ADMINISTRACIÓN DE UNA BASE DE DATOS DE SQL SERVER:
Abarca 3 puntos importantes:
1. Instalar y configurar SQL Server y establecer la seguridad de red.
2. Construir las Bases de Datos: incluye asignar espacio en disco para la Base de Datos
y la conexión, transferir datos de y hacia la Base de Datos, definir e implementar la
seguridad de la base de Datos y crear trabajos automatizados para ciertas tareas.
20
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
3.
Administrar actividades entrantes, como la importación y exportación de datos,
respaldar y restaurar la base de Datos y la conexión, y monitorear la Base de Datos. Una
tarea opcional es automatizar algunas de estas tareas administrativas recurrentes.
LOS PRO:
SQL Server está plagado de nuevas características. Vamos a repasar algunas de las
más significativas.
Asignación Dinámica de Recursos. La asignación dinámica de recursos del SQL Server
es una característica muy útil. La asignación dinámica de recursos permite la
escalabilidad del uso del disco y memoria para acomodarse a las necesidades de la
base de datos en cada momento. Esta flexibilidad permite un mejor rendimiento y
simplifica la administración del software. La eliminación de dispositivos también es una
ventaja añadida.
El Soporte 9x para Windows. El soporte para la plataforma Win9x aumenta
significativamente la base de aplicaciones posibles para el SQL Server. Al usarlo con la
replicación distribuida de fusión del SQL Server, el soporte Win9x permite que las
empresas con sucursales pequeños que incluyen solo unos pocos sistemas Win9x en
cada oficina remota aprovechen de las aplicaciones del Servidor SQL a través de la
empresa entera.
El Analizador Gráfico de Consultas. El programa ISQL/w del Servidor SQL 6.5 es una
herramienta útil y a menudo necesaria para construir y ejecutar las sentencias
interactivas de SQL. El nuevo Analizador de Sentencias del SQL Server representa un
paso adelante dentro de este programa. No solo se puede construir unos
procedimientos guardados y ejecutar unas consultas interactivas, sino que también se
puede enseñar gráficamente los pasos que el procesador de consultas usa para
ejecutar la consulta.
Los Servicios OLAP del Servidor SQL de Microsoft. Después de toda la incertidumbre
acerca de si Microsoft iba a añadir un servidor OLAP a SQL Server, o si por el contrario
iba a ofrecerlo por separado, disponer por fin de los Servicios OLAP para SQL Server
es casi como recibir un producto gratis. Con la inclusión de los Servicios OLAP como
parte del Servidor SQL, Microsoft ha abierto el mercado del data warehousing, data
21
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
mart, y el soporte a tomas de decisión a muchas empresas pequeñas o medianas que
no habrían pensado en usar este tipo de herramienta dados sus elevados costes.
Los Servicios de Transformación de Datos (DTS). La nueva característica DTS del SQL
Server es una poderosa herramienta y muy flexible. Aunque Microsoft la ha diseñado
pensando en facilitar el almacenamiento de datos, la utilidad del producto no acaba allí.
DTS simplifica la importación y la exportación de datos entre dos bases de datos
compatibles con OLE DB. DTS también genera scripts Visual Basic (VBScript) que se
puede ejecutar desde el WSH (Windows Scripting Host) u otros entornos COM
(Component Object Model).
Las funciones del Enterprise Manager (EM). Además de implementar el SQL Server
Enterprise Manager como un snap-in del MMC (Microsoft Management Console),
Microsoft ha mejorado sus funciones y ha incorporado de nuevas. La característica que
nos más nos ha llamado la atención es la posibilidad de mirar los contenidos de una
tabla directamente desde el EM. Otra función muy útil es la posibilidad de cambiar
directamente los tipos de datos de las tablas existentes.
LOS CONTRAS:
Y aunque el SQL Server tenga muchas ventajas, también tiene varias desventajas. Aquí
tiene algunas áreas en las cuales debe mejorar en próximas versiones...
La instalación y operación requiere del Internet Explorer (IE) 4.0. Le guste o no, la
interfaz del navegador de Web sigue siendo cada vez más habitual, y su uso es lo
último en desarrollo de interfaces. Podemos entender por qué Microsoft quiere usarlo
con el Servidor SQL, ya que también es un produce de la compañía. Sin embargo, no
tenemos ninguna utilidad para un navegador de Web en nuestro servidor de la base de
datos, y su instalación es un problema que posiblemente, a más de uno le gustaría
evitar.
La migración requiere un reinicio de la base de datos. El reinicio de todos los datos en
una base de datos es un trabajo serio que invita a la potencial pérdida de datos. Cuanto
más grande sea la base de datos, más onerosa será esta obligación. Sin embargo,
22
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
después de mirar las herramientas de migración del SQL Server, es obvio que Microsoft
se ha planteado esta operación como algo muy serio.
Ausencia de integridad referencial declarativa en cascada (DRI). La ausencia de una
integridad referencial en cascada podría ser la desventaja más grande del Servidor SQL
en comparación con las otras bases de datos dentro del mercado NT. Incluso Access
ofrece soporte de este estilo. Se pueden utilizar triggers para compensar esta
desventaja, aunque en otras bases de datos esta técnica no es necesaria, así que no es
lógico que deba utilizar para trabajar con SQL Server. Al considerar las otras nuevas
características de SQL Server, es una pena que ésta no esta incluida.
2.4 Metodología RUP, lenguaje UML.
RUP es una propuesta de proceso para el desarrollo de software orientado a objeto que
utiliza el Lenguaje Unificado de Modelado (UML), un lenguaje para la visualización,
especificación y documentación de los componentes de un sistema. Básicamente UML,
permite a los desarrolladores del sistema visualizar su los resultados de su trabajo en
esquemas o diagramas.
UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos
los componentes del proceso de desarrollo de aplicaciones. No pretende definir un
modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. [Leyton,
2000]
UML proporciona a los desarrolladores un vocabulario que incluye tres categorías:
elementos, relaciones y diagramas. De elementos hay cuatro tipos: estructurales, de
comportamiento, de agrupación y de notación.
De elementos estructurales hay sietes: casos de uso, clases, clases activas, interfaces,
componentes, colaboraciones y nodo.
De la categoría relación tenemos tres tipos: de dependencia, de asociación y de
generalización.
23
Capitulo II Tendencias y Tecnologías Actuales a Considerar.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
De la categoría de los diagramas hay nueve tipos: diagramas de caso de uso, de
clases, de secuencia, de colaboración, de estados, de actividad, de componentes y de
despliegue.
2.5 Conclusiones.
En este capitulo se realizo un estudio de las tecnologías utilizadas, las ventajas y
desventajas de cada una de ellas, así como su forma de empleo en aplicaciones. Se
destacan cualidades del gestor de Base de Datos SQL-Server, utilizada en el software
implementado, la programación en la plataforma .NET, con el lenguaje de programación
C#, por las potencialidades que ofrecen.
24
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
3
Capítulo
DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA
3.1 Introducción.
El desarrollo de la aplicación en cuestión se ha basado en el Proceso Unificado de
Desarrollo de Software (RUP por sus siglas en inglés) que hace uso del Lenguaje
Unificado de Modelado (UML por sus siglas en inglés) para la modelación de los
artefactos que se presentan. Ha sido de vital importancia la utilización, además, de la
herramienta case Rational Rose que asiste el desarrollo de software aumentando la
productividad y calidad del mismo. La combinación anterior ha tomado mucho auge
desde su surgimiento y ha demostrado sus potencialidades al unificar muchas
metodologías y lenguajes que, con la finalidad del desarrollo del software, se han venido
presentando. Poniendo en práctica dicho proceso y, con vista a entender el contexto del
sistema a desarrollar, se llevó a cabo un estudio de la estructura y la dinámica de las
oficinas del centro Histórico de la ciudad de Camagüey, y de forma más detallada, del
funcionamiento de cada una de sus secciones de trabajo.
Teniendo en cuenta lo anterior, se elaboró el presente capítulo que expone,
primeramente, un listado de las dificultades más relevantes que podemos encontrar
actualmente en las oficinas del historiador y el modelo del negocio que constituye un
punto de partida importante para el desarrollo y comprensión del sistema que se
pretende
implementar.
Inmediatamente,
el
capítulo
muestra
la
variante
de
automatización propuesta que contiene el modelo de casos de uso del sistema con los
25
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
actores del sistema, los casos de uso del sistema y las relaciones entre ellos, así como
un listado de requisitos adicionales (fiabilidad, seguridad, rendimiento, software,
hardware, etc.).
3.2 Estado actual del negocio.
En la actualidad, en la oficina del historiador de la ciudad de Camagüey, se presentan
numerosas dificultades que afectan directamente los trámites que en ellas se realizan.
Se pueden citar las siguientes:
1. Resulta muy complicado actualizar las planillas, pues solo puede hacerse borrando
los datos en la misma cada vez que se modifica, lo que implica todo tipo de gastos,
tanto de recursos humanos como económicos
2. Es prácticamente imposible consultar esta información, son miles de inmuebles los
que se ubican en la ciudad, por muy organizado que se conserven los expedientes
no le es factible a los técnicos consultarlas con frecuencia, primero porque la
actividad de trámites tanto a particulares como estatales es muy operativa, o sea
para cada trámite evidentemente se necesita consultar la información, pero la
planilla solo permite hacer un análisis elemental de los datos que en ella se recogen,
pues es necesario realizar cruce entre las diferentes variables pare poder valorar los
datos y, no obstante solo así podemos tener resultados parciales, pues para un
análisis a escala urbana se requiere de conocer el comportamiento de un área de
considerable dimensiones.
3. A pesar de contar con un archivo de datos este no puede explotarse como es
debido, el personal existente no da abasto para en el tiempo previsto emitir
respuestas correctas, generándose nuevos libros de control sobre la actividad.
4. Se dificulta hasta el extremo la elaboración del Plan Estratégico, pues este
instrumento debe ser contar con un diagnóstico detallado que nos permita evaluar el
territorio, por lo que se hace inoperante el manejo de la información, solo permite
trabajar temáticas a pequeña escala., donde toda la información se procesa
manualmente.
26
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
5. Así mismo se cuenta con una base cartográfica muy desactualizada, que nos impide
contar con los planos temáticos que requieren los diferentes análisis, o elaborarlos
las veces que son necesarios para ilustrar diferentes situaciones.
El inversionista llega a la oficina y le pide al técnico especialista que le muestre todos
los inmuebles que presenten determinadas características que el desea que posean
para efectuar su inversión, el técnico le hace entrega de un modelo que el debe llenar
para registrar su solicitud en un libro de control, se toman sus datos, que es lo que
desea hacer con ese inmueble, cual es el uso que le va a dar, y si afecta el patrimonio
de la ciudad. De ahí se hace una copia del documento se le entrega al cliente, y es
entonces que el técnico según capacidad hace cruzamientos entre las variables, es de
suponer que no tiene toda la claridad requerida el análisis que se hace. Entonces
podemos concluir diciendo que es ineficiente y demorado el negocio actualmente, y se
puede dar el caso de perder al inversionista.
Cuando el restaurador o el inversionista o el historiador llegan a la oficina piden la
información referente a todas las Unidad edificatoria que se encuentren en el centro
histórico, de ahí se hace un análisis, se buscan las planillas, se llenan libros de control
sobre el usuario interesado en esos datos y toda esa información es archivada por
técnicos especialistas en el libro de control de pedido de información.
Como parte de la inserción del Centro Histórico de Camagüey en el programa de
informatización de la sociedad, este organismo ha decidido crear toda una
infraestructura debidamente equipada que soporte un sistema cuyo objetivo sea
automatizar la actividad de las oficinas del centro histórico y que ofrezca una solución
efectiva a los problemas planteados anteriormente.
3.3 Modelo del negocio.
Como primer paso para el desarrollo de software, RUP propone que se comprenda el
contexto que se desea automatizar como fuente que aporta información muy importante
para la obtención de los requerimientos que debe cumplir el sistema a desarrollar e
identificación de los actores del mismo. Con este fin se han recogido las reglas del
negocio indicando las mejoras que se proponen con la aplicación y se ha realizado una
27
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
modelación del negocio que tiene lugar en las oficinas del Centro Histórico de la ciudad
de Camagüey, dicho modelo esta formado por el modelo de casos de usos del negocio.
3.3.1 Reglas del negocio.
En las oficinas del Centro Histórico de la ciudad de Camagüey el proceso surge ante la
necesidad de procesar toda la información referente a los inmuebles de la ciudad, emitir
rápidas respuestas ante la operatividad que demanda la ciudad fundamentalmente en
cuanto a las potencialidades de los cambios de uso, de inversiones, de restauraciones,
y de prioridad de conservación. Estos aspectos requieren respuestas urgentes, para lo
cual es necesario contar con el conocimiento de todos los elementos exigidos para
tener un plan de manejo, evitando así en la medida de lo posible compromisos que se
conviertan en transformaciones irreversibles y que afecten el patrimonio edificado. En
estas oficinas se implanta la aplicación y la base de datos estará en una oficina central
de la cual se tomara la información que desee el usuario que la solicite; el inversionista
llegara y pedirá unidades edificatorias con características que
el determino con
anterioridad, y la aplicación le generara los reportes con esos datos, la ubicación, la
cantidad de esas unidades edificatorias y el por ciento que representan del total,
dándole la posibilidad de elegir entre todas las unidades edificatorias que el sistema le
muestra, además ya no tiene que trasladarse hasta la entidad elegida para observarla,
el sistema es capaz de mostrarle la imagen de la misma. Si es un restaurador el que
llega a la oficina, el técnico especialista sabe que lo que le interesa a este usuario son
las unidades edificatorias que presenten determinados grados de protección, se buscan
los datos de la misma y se les da una respuesta rápida mediante el cruzamiento de
variables. Si es el historiador de la ciudad el que solicita la información, el técnico
especialista sabe que tiene que darle todas las unidades edificatorias con todos sus
datos.
Además el sistema es capaz de permitirle a los técnicos especialistas la inserción de
toda la información de todos los inmuebles del centro histórico, así como la eliminación
o modificación de los datos.
28
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
3.3.2 Modelo de casos de usos del negocio.
Este modelo de casos de uso describe los procesos del negocio en términos de casos
de uso del negocio y actores del negocio, representando en estos últimos a los clientes.
Dicho modelo se describe mediante diagramas de casos de uso que muestran cómo los
actores del negocio y los casos de uso del negocio se encuentran relacionados.
[Jacobson, 2000].
Los actores del negocio, que representan a los clientes de las oficinas historiador, son
los siguientes:
Actores
Justificación
Inversionista
Es la persona que se presenta en la Oficina del Historiador para
solicitar determinada información con el fin de realizar una inversión
en una determinada unidad edificatoria.
Historiador
Es la persona que se encarga de la investigación histórica de una
determinada localidad y que se presenta para obtener toda la
información existente sobre los distintos inmuebles del centro
histórico.
Restaurador
Es la persona que se dedica a la restauración de inmuebles de
interés histórico-cultural y patrimonial, que se presenta a la Oficina
del Historiador para obtener toda la información que se dispone
sobre los mismos y partiendo de estos datos proponer la
restauración del inmueble en cuestión.
Usuario General.
Es un actor abstracto del cual heredan los actores del negocio para
realizar el mismo caso de uso del negocio (Obtener información de
las unidades edificatorias).
Por su parte, los trabajadores del negocio, que representan a los técnicos de las
oficinas del historiador del Centro Histórico de la Ciudad de Camagüey, aparecen a
continuación:
29
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Trabajadores
Justificación
Técnico especialista del Dpto. Es la persona que se encarga de desarrollar las
de Planeamiento y Gestión.
investigaciones inherentes al territorio y proponer las
estrategias
de
desarrollo,
además
de
todo
lo
relacionado con el proceso de gestión y los talleres de
barrios.
Técnico especialista del Dpto. Es el responsable de mantener actualizada la
Control del Territorio.
información, todo lo relacionado con el inventario, así
como de controlar el territorio, atender a la población y
las entidades, además de elaborar la maqueta de la
ciudad.
DIAGRAMA DE CASO DE USO DEL NEGOCIO.
Obtener informacion sobre Unidad Edificatoria.
Usuario General
Historiador
Restaurador
Inversionista
30
Proponer Informacion para obtener Unidad
Edificatoria.
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Casos de usos del negocio:
Proponer información para obtener Unidad Edificatoria. El caso de uso inicia
cuando el inversionista llega a la oficina y pide todas las unidades edificatorias que
existan con ciertas características que el trae decididas. El Técnico especialista, llena
un modelo con los datos del inversionista y las caracteristicas de las unidades
edificatorias que desea, asienta los datos en un libro de control de solicitudes. Busca las
unidades edificatorias en los archivos, si existen hace una copia de este modelo. El
inversionista recoge el modelo con los datos y decide visitar las unidades edificatorias
que contiene el modelo. Fin del poceso .Si no existen unidades edificatorias con estas
caracteristicas, se le informa al inversionista, concluye asi el proceso.
La automatización de este proceso permitirá una mejora considerable en la velocidad de
los trámites para recoger la información de las unidades edificatorias que propone el
inversionista, mayor eficiencia y confianza en los datos, y no se toma el riesgo de perder
al inversionista por una demora en la respuesta que debe emitir la oficina.
Obtener información sobre Unidad Edificatoria. El caso de uso inicia cuando el
usuario general llega a la oficina y pide todas las unidades edificatorias que existan en
los archivos de la misma. El usuario general llega a la oficina y solicita los datos de las
unidades edificatorias archivadas. El Técnico especialista, llena un modelo con los
datos del usuario general, cual es el interes en eso datos, asienta los datos en un libro
de control de solicitudes Busca las unidades edificatorias en los archivos El usuario
recoge el modelo con los datos de las unidades edificatorias. El usuario general decide
visitar las unidades edificatorias que contiene el modelo. Fin del poceso.
La automatización de este proceso permitirá una mejora considerable en la velocidad de
los trámites para recoger la información de las unidades edificatorias que existan con
mayor eficiencia y confianza en los datos,
31
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Diagrama de actividad. Obtener Información sobre Unidad Edificatoria.
Usuario General : Usuario General
Técnico especialista del Dpto. de Control de Territorio : T...
inicio
Entregar Modelo para Obtener
Unidad Edificatoria
Solicitar modelo para
Obtener Unidad Edificatoria
Modelo de Solicitud
de UE
Llenar modelo de
Solicitud de UE
[Vacio]
Devolver Modelo de
Solicitud de UE
Modelo de Solicitud
de UE
Revisar Modelo de
Solicitud de UE
[Lleno]
Asentar en Libro de Control
de Certificaciones
Libro de control de Solicitudes
[Unidad Edificatoria, Usuario General]
Buscar UE
Emitir modelo
resumen de UE
Modelo resumen de
UE
[Encontradas]
Recibir Modelo
resumen de UE
Devoler Modelo
resumen de UE
Visitar UE
propuestas
Fin
32
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Diagrama de actividad. Proponer Información para obtener Unidad Edificatoria.
Inv esrionista
Solicitar modelo para
obtener Unidad Edificatoria
Llenar modelo
Técnico especialista del Dpto. de Planeamiento y Gestión
Entregar m odelo de
Solicitud de UE.
Modelo de solicitud
de UE.
[vacio]
Devolver m odeo de
Solicitud de UE
Modelo de solicitud
de UE.
Revisar modelo
[Lleno]
Asienta en el Libro de
Control de Solicitudes.
Libro de Control de Solicitudes
[Unidad Edificatoria, Inversionista]
Buscar UE
segun modelo
[Encontrada]
Emitir Modelo de Unidad
Edificatoria propuestas
Modelo de UE propuesta
[Unidades Edificatorias propuestas]
Recibir Modelo de
UE propuesta
Entregar Modelo de
UE propuesta
Visitar Unidades
Edificatorias propues tas
33
[No encontrada]
Emitir error
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
3.4 Requisitos funcionales.
A partir de la modelación del negocio realizada, se determinaron las funcionalidades
que debe desarrollar el sistema. Estas se recogen en el siguiente listado:
1
Actualizar unidad edificatoria
1.1 Adicionar unidad edificatoria.
1.2 Eliminar unidad edificatoria.
1.3 Modificar unidad edificatoria.
2
Verificar que no existen desglose de la unidad edificatoria que voy a eliminar.
3.
Actualizar desglose.
3.1 Adicionar desglose de la unidad edificatoria ya existente.
3.2 Eliminar desglose.
3.3 Modificar desglose.
4. Mostrar imagen por cada unidad edificatoria.
5. Mostrar imagen por cada desglose.
6. Actualizar las imágenes.
6.1 Adicionar una imagen.
6.2 Eliminar una imagen.
6.3 Modificar una imagen.
7
Mostrar reporte de todas las unidades edificatorias.
8.
Mostrar reporte de todos los desglose.
9.
Mostrar la cantidad de unidades edificatorias.
10.
Mostrar la cantidad de desglose.
11.
Mostrar reporte de valor.
12.
Mostrar reporte con carácter.
13.
Mostrar reporte de estado constructivo.
14.
Mostrar reporte de uso de redes.
15.
Mostrar reporte de uso de categorías.
16.
Mostrar reporte de uso.
17.
Mostrar reporte de época por unidad edificatoria.
34
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
18.
Mostrar reporte por época de los desgloses.
19.
Mostrar reporte de 1, 2, 3, 4 plantas.
20.
Mostrar reporte según el tipo de planta arquitectónica.
21.
Mostrar cada una de las consultas con relación a una calle.
22.
Mostrar reporte de con categoría A.
23.
Mostrar reporte de categoría B1...B4.
24.
Mostrar reporte de categoría C1...C3.
25.
Mostrar reporte de categoría D1...D3.
26.
Mostrar reporte de grado de protección de la I...IV.
27. Mostrar reporte que tengan un grado de protección, una categoría y un estado
constructivo determinado.
28.
Mostrar reportes de unidad edificatoria que constituyen potencial para el cambio
de uso.
29.
Automatizar el llenado de la tabla unidad edificatoria.
30.
Confeccionar una ayuda de la aplicación.
31.
Calcular el por ciento que representa cada una de las consultas del total de las
unidad edificatoria que existen.
32.
Mostrar unidad edificatoria por ejes (calles).
33.
Gestionar Búsquedas Especializadas.
34.
Busquedas libres.
35.
Obtener grado de proteccion.
36.
Obtener categorias predefinidas.
37.
Obtener grados de proteccion predefinido.
38.
Administrar Sistema.
39.
Autenticar usuario.
40.
Mostrar Indicadores patrimoniales.
41.
Gestionar Calles.
35
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
41.1 Insertar Calle
41.2 Modificar Calle
41.3 Eliminar Calle
42. Gestionar Carácter.
42.1 Insertar Carácter.
42.2 Modificar Carácter.
42.3 Eliminar Carácter.
43. Gestionar Valor.
43.1 Insertar Valor.
43.2 Modificar Valor.
43.3 Eliminar Valor.
44. Gestionar Transformaciones.
44.1 Insertar Transformaciones.
44.2 Modificar Transformaciones.
44.3 Eliminar Transformaciones.
45. Gestionar Estado Constructivo.
45.1 Insertar Estado Constructivo.
45.2 Modificar Estado Constructivo.
45.3 Eliminar Estado Constructivo.
46. Gestionar Épocas de los Desglose
46.1 Insertar Épocas de los Desglose
46.2 Modificar Épocas de los Desglose
46.3 Eliminar Épocas de los Desglose
47. Gestionar Épocas de la unidad edificatoria
47.1 Insertar Épocas de la unidad edificatoria
47.2 Modificar Épocas de la unidad edificatoria
47.3 Eliminar Épocas de la unidad edificatoria
36
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
48. Gestionar Usos
48.1 Insertar Usos
48.2 Modificar Usos
48.3 Eliminar Usos
49. Gestionar Portales.
49.1 Insertar Portales
49.2 Modificar Portales
49.3 Eliminar Portales
50. Gestionar Barrio
50.1 Insertar Barrio
50.2 Modificar Barrio
50.3 Eliminar Barrio
51. Gestionar Tipo Planta.
51.1 Insertar Tipo Planta
51.2 Modificar Tipo Planta
51.3 Eliminar Tipo Planta
52. Gestionar Tipo de Edificación.
52.1 Insertar Tipo de Edificación.
52.2 Modificar Tipo de Edificación.
52.3 Eliminar Tipo de Edificación.
3.5 Requisitos no funcionales.
Los requerimientos no funcionales pueden ser agrupados de acuerdo a:
Requerimientos de apariencia o interfaz externa:
La aplicación propuesta consta de pantallas con distribución uniforme de sus elementos.
Se pretende una aplicación que sea sencilla de utilizar, donde los controles y elementos
37
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
se encuentren correctamente distribuidos y que cumplan con los buenos estándares de
la programación basura y diseño siguiendo por ejemplo las interfaces tipo Windows,
además de brindar una imagen profesional del producto que se pretende implementar.
Se desea una interfaz legible, amigable, poco cargada y fácil de usar para todos los
tipos de usuarios
Requerimientos de usabilidad:
Debido al sector de personas a la que va dirigida esta aplicación se pensó en
desarrollar una interfaz de fácil uso y manejo, donde se manipulen los conceptos de una
manera asequible para todos sin dejar por esto que se pierda la seriedad y
profesionalidad. Esta aplicación reúne los conceptos tratados por los especialistas
haciéndola más comprensible y manejable.
Requerimientos de Rendimiento.
Se debe garantizar que la respuesta a solicitudes de los usuarios del sistema sea en un
período de tiempo breve (de segundos) para evitar la acumulación de trabajo por parte
de técnicos en las oficinas pues la labor en estas entidades se caracteriza por una gran
dinámica.
Requerimientos de Soporte:
Una vez terminada la aplicación se someterá a una fase de pruebas con el fin de
detectar todas las fallas posibles para ser corregidas.
Se requiere un servidor de bases de datos con las siguientes características:
Soporte para grandes volúmenes de datos y velocidad de procesamiento.
Tiempo de respuesta rápido.
Plataforma .NET versiones 1.0 / 1.1 o bien plataforma Mono.
Requerimientos de portabilidad:
El sistema propuesto esta pensado par ser usado en distintas plataformas, dado al
amplio auge que va tomando el sistema operativo LINUX y a la política que se esta
siguiendo de su implementación en el territorio nacional, todo esto posible gracias al
Proyecto Mono (Implementación del FrameWork .NET para LINUX) de la comunidad de
LINUX.
38
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Esta aplicación puede ser migrada rápidamente de un sistema operativo a otro sin
mayores complicaciones gracias a las facilidades del FrameWork.
Requerimientos de seguridad:
La información manejada por el sistema esta protegida de acceso no autorizado y
divulgación. Debido a la importancia de la información manipulada, esta será objeto de
cuidadosa protección contra la corrupción y estados inconsistentes mediante técnicas
de criptografía. El acceso a los distintos usuarios a la información será restringido
mediante el empleo de roles donde se separan los distintos privilegios según el tipo de
usuario.
Por la gran importancia de la información que se maneja en este sistema se hace
imprescindible mantener varias salvas de la misma tanto en otro disco duro del mismo
nodo servidor donde radica la base de datos como en otras computadoras conectadas a
otra fuente de alimentación eléctrica. Identificar al usuario antes de que pueda realizar
cualquier acción sobre el sistema.
Garantizar que la información sea vista únicamente por quien tiene derecho a verla.
Garantizar que las funcionalidades del sistema se muestren de acuerdo al nivel de
usuario que este activo.
Protección contra acciones no autorizadas o que puedan afectar la integridad de los
datos.
Verificación sobre acciones irreversibles (eliminaciones).
Requerimientos Políticos y Culturales
Se debe respetar la política y la cultura organizativa del centro y sus características
propias, en cuanto a la organización económica de la universidad.
Requerimientos Legales
El trabajo en estas oficinas está regido por leyes y normativas establecidas por lo que
de igual forma el sistema debe respetar todos los procedimientos y estructuras de
documentos que se encuentran legislados. De igual forma existen documentos que por
su valor como “originales” no serán sustituidos con el sistema.
39
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Requerimientos de confiabilidad
La información debe estar disponible en todo momento para todas las Oficinas del
centro Histórico de la Ciudad. Es importante garantizar este acceso debido a la
respuesta rápida que se desea brindar a los ciudadanos que asisten a estas unidades y
a la consistencia y actualización que se requiere tenga la información. Además existen
trámites a realizar dentro de un determinado período de tiempo, de lo contrario se
tornan más complejos, lo cual se traduce en insatisfacción del público que solicita el
servicio. Por otra parte, siempre se almacena la información con la referencia al
registrador que la suministró de forma tal que, ante cualquier eventualidad, se pueda
saber quién realizó el trámite o asiento.
Requerimientos de Ayudas y Documentación en línea.
El sistema debe implementar una ayuda online disponible al usuario en todo momento
de forma tal que el usuario que esté en el sistema pueda visitarla en caso de cualquier
duda, esta debe brindarle información de todas las actividades a realizar por él.
El software debe tener la documentación completa de todas las tareas y operaciones
que realiza así como todo sobre su implementación.
Requerimientos de Software.
Esta aplicación ha sido diseñada para que funcione sobre la familia Windows, 2000 o
superior, estando presenta el Microsoft FrameWork v1.0. También para que ejecute
correctamente sobre LINUX y el FrameWork de Proyecto Mono. Microsoft SQL Server
2000 y Plataforma .NET 1.0 o posterior.
Requerimientos de Hardware.
Se requiere de un microprocesador Pentium II o superior, con XXX Mb de RAM;
CDROM Drive para la instalación del producto, etc. Para el servidor seria una
3.6 Descripción del sistema propuesto.
3.6.1 Concepción General del Sistema.
El sistema que se propone es una aplicación de desarrollada con C# como lenguaje de
programación que esté conectada a una base de datos de SQL-Server central que
40
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
radique en la oficina del centro Histórico de la Ciudad de Camagüey y que contenga la
información de todos los inmuebles de la ciudad, Dicha aplicación podrá ser accedida
por las oficinas del centro histórico a través de un dominio que se cree con este fin. Esta
variante que se propone automatizará los procedimientos de trabajo en el flujo de
información.
Se pretende que con esta aplicación se recoja todos los elementos necesarios que
deben ser considerados y garantice la validez de los mismos, aunque como es lógico
existen restricciones para su modificación, pero esto facilitara que todas las entidades
involucradas en el manejo y gestión de los territorios elaboren sus propuestas de forma
colegiada y con todos los datos necesarios.
Con el desarrollo de esta aplicación se espera disminuir notablemente el tiempo de
respuesta al usuario. De igual forma se espera simplificar el trabajo de los técnicos
especialistas y crear una nueva y rápida vía de actualización de la información.
Por otra parte los gastos de la entidad se verán reducidos en cuanto al pago del servicio
telefónico y el de postal.
Además la entidad para la que proponemos este trabajo tiene una gran responsabilidad
en el territorio, los datos que han sido manejados para el diseño de este programa
pueden ser generalizados a otras ciudades , o para el uso también de otras entidades
que de alguna manera se involucran en estas tareas como pueden ser las Direcciones
de Patrimonio, Planificación Física, las Direcciones de Vivienda, como herramienta en
los estudio en las facultades de arquitectura para desarrollar habilidades en las
asignaturas relacionadas con los proyectos arquitectónicos y urbanos y, como es lógico
sirve para que les entidades relacionadas con el proceso inversionista conozcan las
potencialidades de los inmuebles sobre todo en el proceso de cambio de uso de los
mismos.
3.7 Modelo Caso de Uso del Sistema.
El modelo de los casos de uso del sistema representa un esquema donde se recogen
las funcionalidades del negocio que se automatiza y determina cómo será utilizado
41
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
desde la perspectiva del usuario (Actor) pues se construye sobre la base de sus
necesidades. A través de este modelo se puede establecer comunicación, más o menos
fluida en dependencia de la claridad del mismo, con los usuarios finales y clientes
expertos del sistema en desarrollo, e informarles acerca de su comportamiento futuro.
[Jacobson, 2000].
3.7.1Los actores del sistema.
Los actores representan los usuarios del sistema e incluyen otra aplicaciones que
puedan interactuar con el. Una vez identificados se tiene el entorno externo del externo
del sistema.
Actores
Descripción
Técnico especialista del Es la persona que se encarga de desarrollar las
Dpto. de Planeamiento y investigaciones inherentes al territorio y proponer las
Gestión.
estrategias de desarrollo, además de todo lo relacionado con
el proceso de gestión y los talleres de barrios.
Técnico especialista del Es el responsable de mantener actualizada la información,
Dpto. Control del Territorio. todo lo relacionado con el inventario, así como de controlar
el territorio, atender a la población y las entidades, además
de elaborar la maqueta de la ciudad.
Administrador de Sistema
Persona encargada de la administración del sistema como
entidad computacional.
Usuario
Actor abstracto del que heredan todos los demás actores
para tomar sus funcionalidades (Autenticar Usuario).
Técnico general
Actor abstracto del que heredan los técnicos especialistas
para obtener sus funcionalidades (Gestionar Búsquedas.)
3.7.2 Los casos de usos del sistema.
Los casos de usos son fragmentos de funcionalidad que el sistema ofrece para aportar
un resultado de valor para sus actores, un caso de usos especifica una secuencia de
acciones que el sistema puede llevar a cabo interactuando con sus actores, un caso de
uso es una especificación.
42
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
1. Gestionar unidad edificatoria.
2. Gestionar Desglose.
3. Gestionar Imagenes.
4. Gestionar Calles
5. Gestionar Valor.
6. Gestionar Caracter.
7. Gestionar Transformaciones.
8. Gestionar Estado Constructivo.
9. Gestionar Epoca en los Desgloses.
10. Gestionar Epoca en las Unidad edificatoria.
11. Gestionar Tipo de Planta.
12. Gestionar Tipo de Edificaciona
13. Gestionar Barrio.
14. Gestionar Portal.
15. Mostrar unidad edificatoria por ejes (calles).
16. Generar reportes.
16.1
Generar reportes de todos los desgloses.
16.2
Generar reporte de todas las Unidad edificatoria.
16.5.
Generar reporte de unidad edificatoria con valor.
16.6.
Generar reporte de unidad edificatoria sin valor.
16.7.
Generar reporte unidad edificatoria con caracter excepcional o
relevante.
16.8.
Generar reporte de unidad edificatoria en buen estado.
16.9.
Generar reporte de unidad edificatoria en mal estado.
16.10.
Generar reporte de unidad edificatoria segun susu usos
16.11.
.Generar reporte de unidad edificatoria por epoca.
16.12.
Generar reporte de unidad edificatoria de 1, 2, 3, 4 plantas.
43
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
16.13.
Generar reporte de unidad edificatoria segun el tipo de planta
arquitectonica
16.14.
Generar reporte de unidad edificatoria modificadas.
16.15.
Generar reporte de unidad edificatoria con tipologia A.
16.16.
Generar reporte de unidad edificatoria con tipologia B1...B7.
16.17.
Generar reporte de unidad edificatoria con tipologia C1...C7.
16.18.
Generar reporte de unidad edificatoria con tipologia D1...D7.
16.19.
Generar reporte de unidad edificatoria con grado de proteccion I..IV.
16.20.
Generar reporte de unidad edificatoria con un grado de proteccion, una
tipologia y un estado constructivo determinado.
16.21.
Generar reporte de unidad edificatoria que constituyen potencial para
cambio de uso.
17.
Gestionar Búsquedas.
17.5.
Busquedas libres.
17.6.
Obtener grado de proteccion.
17.7.
Obtener categorias predefinidas.
17.8.
Obtener grado de proteccion predefinidos.
18. Administrar Sistema.
19. Autenticar usuario.
3.7.3 Descripción de los casos de usos del sistema.
Caso de Uso
Gestionar unidad edificatoria.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar la información de las unidad edificatoria dentro de la
base de datos, ya sea eliminando, adicionando o modificando las
tuplas existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre la unidad
44
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
edificatoria. Según su requerimiento podrá insertar, eliminar o
modificar unidad edificatoria para lo cual el sistema le mostrará y
actualizará
respectivamente
el
registro
de
las
mismas.
Concluyendo, así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o modificar alguna de las unidad edificatoria tiene que
asegurarse primero de que ésta exista, y si va a adicionar una
nueva debe asegurarse también de que ya no esté en la base de
datos y estar autenticado como tal en el sistema.
Referencias
R1
Poscondiciones
Las unidades edificatorias en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 1 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Gestionar Desglose.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar la información de los Desglose dentro de la base de
datos, ya sea eliminando, adicionando o modificando las tuplas
existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre los
Desgloses. Según su requerimiento podrá insertar, eliminar o
modificar los Desgloses para lo cual el sistema le mostrará y
actualizará respectivamente el registro de las mismas, concluyendo
así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o modificar alguna de os Desgloses tiene que asegurarse
primero de que ésta exista, y si va a adicionar uno nuevo debe
asegurarse también de que ya no esté en la base de datos y estar
autenticado como tal en el sistema.
Referencias
R3
45
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Poscondiciones
Los Desgloses en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 3 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Gestionar Imágenes.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar las imágenes dentro de la base de datos, ya sea
eliminando, adicionando o modificando las existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre las
imágenes. Según su requerimiento podrá insertar, eliminar o
modificar las imágenes para lo cual el sistema le mostrará y
actualizará respectivamente el registro de las mismas, concluyendo
así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o modificar alguna de las imágenes tiene que asegurarse
primero de que ésta exista, y si va a adicionar una nueva debe
asegurarse también de que ya no esté en la base de datos.
Referencias
R4, R5, R6
Poscondiciones
Las imágenes en el sistema se actualizan.
Requerimientos
El prototipo de este caso de uso esta ubicado en el prototipo de la
especiales
Unidad Edificatoria, en la opción imagen.
Caso de Uso
Gestionar Calles.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar las calles dentro de la base de datos, ya sea eliminando,
adicionando o modificando las existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre las calles.
Según su requerimiento podrá insertar, eliminar o modificar las
46
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
calles para lo cual el sistema le mostrará y actualizará
respectivamente el registro de las mismas, concluyendo así el caso
de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o
modificar alguna de las calles tiene que asegurarse
primero de que ésta exista, y si va a adicionar una nueva debe
asegurarse también de que ya no esté en la base de datos.
Referencias
R37
Poscondiciones
Las calles en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 2 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Gestionar Valor.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar los valores dentro de la base de datos, ya sea
eliminando, adicionando o modificando los existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre los
valores. Según su requerimiento podrá insertar, eliminar o
modificar los valores para lo cual el sistema le mostrará y
actualizará respectivamente el registro de las mismas, concluyendo
así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o modificar alguna de los valores tiene que asegurarse
primero de que éste exista, y si va a adicionar uno nuevo debe
asegurarse también de que ya no esté en la base de datos.
Referencias
R39
Poscondiciones
Los valores en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 4los prototipos de interfaz de usuario del caso de uso)
47
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Caso de Uso
Gestionar Carácter.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar los caracteres dentro de la base de datos, ya sea
eliminando, adicionando o modificando los existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre los
caracteres. Según su requerimiento podrá insertar, eliminar o
modificar los caracteres para lo cual el sistema le mostrará y
actualizará respectivamente el registro de las mismas, concluyendo
así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o
modificar alguna de los caracteres
tiene que
asegurarse primero de que éste exista, y si va a adicionar uno
nuevo debe asegurarse también de que ya no esté en la base de
datos.
Referencias
R38
Poscondiciones
Los caracteres en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 7 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Gestionar Transformaciones.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar las transformaciones dentro de la base de datos, ya sea
eliminando, adicionando o modificando los existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre las
transformaciones. Según su requerimiento podrá insertar, eliminar
o modificar las transformaciones para lo cual el sistema le mostrará
y
actualizará
respectivamente
48
el
registro
de
las
mismas,
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
concluyendo así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o modificar alguna de las transformaciones tiene que
asegurarse primero de que éste exista, y si va a adicionar uno
nuevo debe asegurarse también de que ya no esté en la base de
datos.
Referencias
R40
Poscondiciones
Las transformaciones en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 5 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Gestionar Estado Constructivo.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar los estados constructivos dentro de la base de datos, ya
sea eliminando, adicionando o modificando los existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre los
estados constructivos. Según su requerimiento podrá insertar,
eliminar o modificar los estados constructivos para lo cual el
sistema le mostrará y actualizará respectivamente el registro de las
mismas, concluyendo así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o modificar alguna de los estados constructivos tiene que
asegurarse primero de que éste exista, y si va a adicionar uno
nuevo debe asegurarse también de que ya no esté en la base de
datos.
Referencias
R41
Poscondiciones
Los estados constructivos en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 6 los prototipos de interfaz de usuario del caso de uso)
49
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Caso de Uso
Gestionar Época en los Desgloses.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar las épocas de los desgloses dentro de la base de datos,
ya sea eliminando, adicionando o modificando los existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre las
épocas de los desgloses. Según su requerimiento podrá insertar,
eliminar o modificar las épocas para lo cual el sistema le mostrará
y
actualizará
respectivamente
el
registro
de
las
mismas,
concluyendo así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o modificar alguna de las épocas de los desgloses tiene
que asegurarse primero de que éste exista, y si va a adicionar una
nueva debe asegurarse también de que ya no esté en la base de
datos.
Referencias
R42
Poscondiciones
Las épocas de los desgloses en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 8 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Gestionar Época en las Unidad edificatoria.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar las épocas de las Unidad edificatoria dentro de la base
de datos, ya sea eliminando, adicionando o modificando las
existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre las
épocas de las Unidad edificatoria. Según su requerimiento podrá
insertar, eliminar o modificar las épocas para lo cual el sistema le
50
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
mostrará y actualizará respectivamente el registro de las mismas,
concluyendo así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o
modificar alguna de las épocas de las Unidad
edificatoria tiene que asegurarse primero de que éste exista, y si
va a adicionar uno nuevo debe asegurarse también de que ya no
esté en la base de datos.
Referencias
R43
Poscondiciones
Las épocas de las Unidad edificatoria en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 9 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Gestionar Tipo de Planta.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar los tipos de planta dentro de la base de datos, ya sea
eliminando, adicionando o modificando los existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre los tipos
de planta. Según su requerimiento podrá insertar, eliminar o
modificar los tipos de planta para lo cual el sistema le mostrará y
actualizará respectivamente el registro de las mismas, concluyendo
así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o
modificar alguna de los tipos de planta
tiene que
asegurarse primero de que éste exista, y si va a adicionar uno
nuevo debe asegurarse también de que ya no esté en la base de
datos.
Referencias
R6
Poscondiciones
Los tipos de planta en el sistema se actualizan.
Requerimientos
-
especiales
51
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Prototipo (Ver en Anexo 10 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Gestionar Tipo de Edificación.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar los tipos de edificación dentro de la base de datos, ya
sea eliminando, adicionando o modificando los existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre los tipos
de edificación. Según su requerimiento podrá insertar, eliminar o
modificar los tipos de edificación para lo cual el sistema le mostrará
y
actualizará
respectivamente
el
registro
de
las
mismas,
concluyendo así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o modificar alguna de los tipos de edificación tiene que
asegurarse primero de que éste exista, y si va a adicionar uno
nuevo debe asegurarse también de que ya no esté en la base de
datos.
Referencias
R48
Poscondiciones
Los tipos de edificación el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 13 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Gestionar Barrio.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar los barrios dentro de la base de datos, ya sea
eliminando, adicionando o modificando los existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre los
barrios. Según su requerimiento podrá insertar, eliminar o modificar
los barrios para lo cual el sistema le mostrará y actualizará
52
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
respectivamente el registro de las mismas, concluyendo así el caso
de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o modificar alguna de los barrios tiene que asegurarse
primero de que éste exista, y si va a adicionar uno nuevo debe
asegurarse también de que ya no esté en la base de datos.
Referencias
R46
Poscondiciones
Los barrios en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 11 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Gestionar Portal.
Actores
Técnico especialista del Dpto. Control del Territorio.(Inicia)
Propósito
Permitir al Técnico especialista del Dpto. Control del Territorio
actualizar los portales dentro de la base de datos, ya sea
eliminando, adicionando o modificando los existentes.
Resumen
El caso de uso se inicia cuando el Técnico especialista del Dpto.
Control del Territorio decide realizar una operación sobre los
portales. Según su requerimiento podrá insertar, eliminar o
modificar los portales para lo cual el sistema le mostrará y
actualizará respectivamente el registro de las mismas, concluyendo
así el caso de uso.
Precondiciones
Para el Técnico especialista del Dpto. Control del Territorio pueda
eliminar o modificar alguna de los portales tiene que asegurarse
primero de que éste exista, y si va a adicionar uno nuevo debe
asegurarse también de que ya no esté en la base de datos.
Referencias
R45
Poscondiciones
Los portales en el sistema se actualizan.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 12 los prototipos de interfaz de usuario del caso de uso)
53
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Caso de Uso
Mostrar unidad edificatoria por calles
Actores
-
Propósito
Una vez generados los reportes, es necesario mostrar las Unidad
edificatoria que pertenecen al tipo de reporte que se quiere
mostrar.
Resumen
El caso de uso es iniciado por el caso de uso Generar Reporte o
alguno de los casos de uso extendidos que le pertenecen. Según
el tipo de reporte que se desea generar se busca en la base de
datos todas las Unidad edificatoria que correspondan con lo que se
desea mostrar, obteniéndose de estas los datos más relevantes y
mostrándose en el reporte. De esta manera termina el caso de uso.
Precondiciones
Para que el caso de uso sea iniciado, es necesario que el Técnico
especialista del Dpto. Control del Territorio este autenticado en el
sistema como tal, y que el caso de uso sea llamado por el caso de
uso Generar Reportes.
Referencias
R32
Poscondiciones
Que las unidades edificatorias aparezcan en los reportes en los
reportes con sus respectivas calles.
Requerimientos
-
especiales
Caso de Uso
Autenticar Usuario
Actores
Usuario (Inicia)
Propósito
Garantizar la autenticación de usuarios al sistema así como la
seguridad del mismo en cuanto a los niveles de acceso que tengan
a la información.
Resumen
El caso de uso comienza cuando el usuario requiere autenticarse
al sistema, para lo cual suministra los datos necesarios. El sistema
verifica que sea usuario y en caso de no serlo se le comunica y
finaliza el caso de uso. Si es usuario del sistema le muestra, según
su nivel de acceso, la sección de trabajo a la que tiene permiso,
finalizando así el caso de uso.
54
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Precondiciones
Que el usuario esté registrado en el sistema con sus privilegios
asignados(Sea reconocido como Administrador de Sistema)
Referencias
R35
Poscondiciones
El sistema se personaliza para el usuario que se autenticó y a la (s)
sección (es) de trabajo a la que tiene acceso.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 14 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Administrar sistema
Actores
Administrador del sistema. (Inicia).
Propósito
Mantener actualizada la información referente a la autenticación de
los diversos usuarios, ya sea insertando, modificando, eliminando
sus tuplas.
Resumen
El caso de uso se inicia cuando el Administrador de Sistema
decide realizar una operación sobre los usuarios y tipos de
usuarios que soporta el sistema. Según su requerimiento podrá
insertar, eliminar o modificar los usuarios y sus tipos de usuarios
para lo cual el sistema le mostrará y actualizará respectivamente el
registro de los mismos, concluyendo así el caso de uso.
Precondiciones
Que el usuario esté registrado en el sistema con sus privilegios
asignados(Sea reconocido como Administrador de Sistema)
Referencias
R34
Poscondiciones
Los datos de los usuarios y los tipos de usuarios se actualizan,
Requerimientos
-
especiales
Prototipo (Ver en Anexo 15 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Generar Reporte.
Actores
Técnico especialista del Dpto. Control del Territorio. (Inicia).
Propósito
Generar Reportes mostrando informaciones sobre una variable
determinada, o combinaciones de ellas.
55
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Resumen
El caso de uso comienza cuando el Técnico especialista del Dpto.
Control del Territorio desea obtener un reporte sobre un inmueble
determinado. Para ello ofrece los datos necesarios para luego
obtener los inmuebles que se corresponden con los datos
suministrados consultando la base de datos y generar el reporte.
Este caso de uso debe ser capaz de calcular el por ciento que
representa la variable en cuestión del total existente en la base de
datos; así como la cantidad de éstas que hay. De esta forma
concluye el caso de uso.
Precondiciones
Que el Técnico especialista del Dpto. Control del Territorio este
autenticado en el sistema; que los datos que se suministren estén
correctos y que se encuentren sus correspondencias en la base de
datos.
Referencias
R7, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte por época de unidad edificatoria.
Actores
-
Propósito
Generar Reporte de Unidad edificatoria por épocas.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se le suministra la
época a la que se le desea obtener el reporte de sus Unidad
edificatoria, la que es validada y al verificarse que es correcta se
consulta la base de datos obteniendo los valores para generar el
reporte. Se calculan los por cientos que representan estas unidad
edificatoria del total y la cantidad y se muestra luego el reporte,
concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R17, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
56
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
especiales
Caso de Uso
Generar Reporte por época de los desgloses.
Actores
-
Propósito
Generar Reporte por época de los desgloses.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se le suministra la
época a la que se le desea obtener el reporte de los desgloses, la
que es validada y al verificarse que es correcta se consulta la base
de datos obteniendo los valores para generar el reporte. Se
calculan los por cientos que representan estos desgloses del total y
la cantidad y se muestra luego el reporte, concluyendo el caso de
uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R17, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de valor.
Actores
-
Propósito
Generar Reporte de valor.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, mediante la opción
específica del menú generar reportes de valor, se consulta la base
de datos obteniendo los valores para generar el reporte. Se
calculan los por cientos que representan estas unidad edificatoria
del total y la cantidad y se muestra luego el reporte, concluyendo el
caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R11, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
57
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de los usos por categorias.
Actores
-
Propósito
Generar Reporte de los usos agrupados por cada uso de red al
cual pertenece.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, mediante la opción
específica del menú generar reportes de los usos por categorías,
que no es más que los usos por redes que están agrupados en
categorías, se consulta la base de datos obteniendo los valores
para generar el reporte. Se calculan los por cientos que
representan estas unidad edificatoria del total y la cantidad y se
muestra luego el reporte, concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R12, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte con caracter.
Actores
-
Propósito
Generar Reporte de Unidad edificatoria con carácter.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, mediante la opción
específica del menú generar reportes con carácter, se consulta la
base de datos obteniendo los valores para generar el reporte. Se
calculan los por cientos que representan estas unidad edificatoria
del total y la cantidad y se muestra luego el reporte, concluyendo el
caso de uso.
Precondiciones
Que el se haya llamado al caso de uso Generar Reportes.
Referencias
R12, Caso de Uso Mostrar unidad edificatoria por calles.
58
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de Estado Constructivo,
Actores
-
Propósito
Generar Reporte de Estado Constructivo.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, mediante la opción
específica del menú generar reportes de Estado Constructivo, se
consulta la base de datos obteniendo los valores para generar el
reporte. Se calculan los por cientos que representan estas unidad
edificatoria del total y la cantidad y se muestra luego el reporte,
concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R14, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte del uso por redes.
Actores
-
Propósito
Generar Reporte de los usos que están agrupados en la definición
redes.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, mediante la opción
específica del menú generar reportes de los usos por redes, se
consulta la base de datos obteniendo los valores para generar el
reporte. Se calculan los por cientos que representan estas unidad
edificatoria del total y la cantidad y se muestra luego el reporte,
concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R14, Caso de Uso Mostrar unidad edificatoria por calles.
59
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte segun uso.
Actores
-
Propósito
Generar Reporte según el uso de la Unidad edificatoria.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, busca los datos de
los usos, la que es validada y al verificarse que es correcta se
consulta la base de datos obteniendo los valores para generar el
reporte. Se calculan los por cientos que representan estas unidad
edificatoria del total y la cantidad y se muestra luego el reporte,
concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R17, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de todas las Unidad edificatoria.
Actores
-
Propósito
Generar Reporte de Unidad edificatoria por épocas.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se va al menú
generar reportes y se piden todas las Unidad edificatoria, la que es
validada y al verificarse que es correcta se consulta la base de
datos obteniendo los valores para generar el reporte. Se calculan
los por cientos que representan estas unidad edificatoria del total y
la cantidad y se muestra luego el reporte, concluyendo el caso de
uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R7, Caso de Uso Mostrar unidad edificatoria por calles.
60
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de los Desgloses.
Actores
-
Propósito
Generar Reporte de todos los desgloses.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se va al menú
generar reportes y se piden todos los desgloses, la que es validada
y al verificarse que es correcta se consulta la base de datos
obteniendo los valores para generar el reporte. Se calculan los por
cientos que representan estas unidad edificatoria del total y la
cantidad y se muestra luego el reporte, concluyendo el caso de
uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R8, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de Unidad edificatoria de 1, 2, 3, 4 plantas.
Actores
-
Propósito
Generar Reporte de todas las Unidad edificatoria de 1, 2, 3, 4
plantas.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se le suministra la
cantidad de planta que desea, la que es validada y al verificarse
que es correcta se consulta la base de datos obteniendo los
valores para generar el reporte. Se calculan los por cientos que
61
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
representan estas unidad edificatoria del total y la cantidad y se
muestra luego el reporte, concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R18, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de Unidad edificatoria segun el tipo de planta
arquitectonica.
Actores
-
Propósito
Generar Reporte de todas las Unidad edificatoria según el tipo de
planta arquitectónica.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se le suministra el
tipo de planta arquitectónica que desea, la que es validada y al
verificarse que es correcta se consulta la base de datos obteniendo
los valores para generar el reporte. Se calculan los por cientos que
representan estas unidad edificatoria del total y la cantidad y se
muestra luego el reporte, concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R19, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de Unidad edificatoria modificadas.
Actores
-
Propósito
Generar Reporte de todas las Unidad edificatoria modificadas.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se va al menú
generar reportes y se pide esta opción, la que es validada y al
verificarse que es correcta se consulta la base de datos obteniendo
62
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
los valores para generar el reporte. Se calculan los por cientos que
representan estas unidad edificatoria del total y la cantidad y se
muestra luego el reporte, concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R18, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de Tipo de Edificacion.
Actores
-
Propósito
Generar Reporte de todas las Unidad edificatoria dad la calle.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se le suministra el
tipo de edificación y elige cual desea, la que es validada y al
verificarse que es correcta se consulta la base de datos obteniendo
los valores para generar el reporte. Se calculan los por cientos que
representan estas unidad edificatoria del total y la cantidad y se
muestra luego el reporte, concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R21, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de Unidad edificatoria con Categorías A1..A3.
Actores
-
Propósito
Generar Reporte de todas las Unidad edificatoria con tipología A.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se va una forma se
ve la información referente a lo que es tipología A y hay una opción
que es generar reporte de las Unidad edificatoria con esta
característica, la que es validada y al verificarse que es correcta se
63
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
consulta la base de datos obteniendo los valores para generar el
reporte. Se calculan los por cientos que representan estas unidad
edificatoria del total y la cantidad y se muestra luego el reporte,
concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R22, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de Unidad edificatoria con categoría B1...B4.
Actores
-
Propósito
Generar Reporte de todas las Unidad edificatoria con tipología
B1…B4.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se va una forma se
ve la información referente a lo que es tipología B1…B4 (B1, B1a,
B1b, B2, B2a, B2b, B3, B3a, B3b, B4) y hay una opción que es
generar reporte de las Unidad edificatoria con esta característica,
la que es validada y al verificarse que es correcta se consulta la
base de datos obteniendo los valores para generar el reporte. Se
calculan los por cientos que representan estas unidad edificatoria
del total y la cantidad y se muestra luego el reporte, concluyendo el
caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R23, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Prototipo (Ver en Anexo 16 los prototipos de interfaz de usuario del caso de uso)
64
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Caso de Uso
Generar Reporte de Unidad edificatoria con categoría C1...C3.
Actores
-
Propósito
Generar Reporte de todas las Unidad edificatoria con tipología
C1…C3.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se va una forma se
ve la información referente a lo que es tipología C1…C3 y hay una
opción que es generar reporte de las Unidad edificatoria con esta
característica, la que es validada y al verificarse que es correcta se
consulta la base de datos obteniendo los valores para generar el
reporte. Se calculan los por cientos que representan estas unidad
edificatoria del total y la cantidad y se muestra luego el reporte,
concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R24, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de Unidad edificatoria con grado de
proteccion del I...IV.
Actores
-
Propósito
Generar Reporte de todas las Unidad edificatoria con grado de
protección del I…IV.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se le suministran
los grados de protección elige el que desea, se valida y se verifica
que es correcta se consulta la base de datos obteniendo los
valores para generar el reporte. Se calculan los por cientos que
representan estas unidad edificatoria del total y la cantidad y se
muestra luego el reporte, concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
65
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Referencias
R26, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar Reporte de Unidad edificatoria con un grado de
proteccion, un estado constructivo y una categoria.
Actores
-
Propósito
Generar Reporte de todas las Unidad edificatoria con un grado de
protección, una tipología y un estado constructivo determinado.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se suministra la
opción, la que es validada y al verificarse que es correcta se
consulta la base de datos obteniendo los valores para generar el
reporte. Se calculan los por cientos que representan estas unidad
edificatoria del total y la cantidad y se muestra luego el reporte,
concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R22, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Generar reportes de unidad edificatoria que constituyen
potencial para cambio de uso.
Actores
-
Propósito
Generar Reporte de todas las Unidad edificatoria con un grado de
protección, una tipología y un estado constructivo determinado.
Resumen
El caso de uso comienza cuando es invocado por Generar
Reportes. Activado el caso de uso en cuestión, se suministra la
opción, la que es validada y al verificarse que es correcta se
consulta la base de datos obteniendo los valores para generar el
66
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
reporte. Se calculan los por cientos que representan estas unidad
edificatoria del total y la cantidad y se muestra luego el reporte,
concluyendo el caso de uso.
Precondiciones
Que se haya llamado al caso de uso Generar Reportes.
Referencias
R22, Caso de Uso Mostrar unidad edificatoria por calles.
Poscondiciones
Se muestra el reporte generado.
Requerimientos
-
especiales
Caso de Uso
Búsquedas libres.
Actores
Técnico General.
Propósito
Buscar las variables según los parámetros deseados.
Resumen
El caso de uso comienza cuando se desea buscar los elementos
que se encuentran en la Base de Datos según parámetros dados.
Se suministran los valores a los parámetros y luego se consulta la
base de datos obteniendo las tuplas deseadas, y de esta manera
termina el caso de uso.
Precondiciones
Que se encuentren las unidades edificatorias con estos datos.
Referencias
R34
Poscondiciones
-
Requerimientos
Se necesita una velocidad grande para efectuar las consultas y
especiales
que la espera no sea demasiado larga.
Prototipo (Ver en Anexo 17 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Obtener grado de protección.
Actores
Técnico General.
Propósito
Obtener reportes de los grados de protección de los inmuebles.
Resumen
El caso de uso comienza cuando el usuario desea buscar los
grados de protección (I, II, III, IV), se toman los grados de
protección de la base de datos, y se muestran, concluyendo así el
caso de uso.
67
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Precondiciones
Que se encuentren los grados de protección en la BD.
Referencias
R35
Poscondiciones
-
Requerimientos
-
especiales
Prototipo (Ver en Anexo 19 los prototipos de interfaz de usuario del caso de uso)
Caso de Uso
Obtener categorías predefinidas.
Actores
Técnico General.
Propósito
Obtener las categorías de las unidades edificatorias.
Resumen
El caso de uso comienza cuando el actor decide obtener las
categorías de las unidades edificatorias, en cada uno de sus
interfaces aparece lo que significa cada una, el actor decide cual
elegir según sus propósitos, así concluye el caso de uso.
Precondiciones
Que se encuentren categorías en la BD.
Referencias
R36
Poscondiciones
-
Requerimientos
-
especiales
Caso de Uso
Obtener grado de protección predefinidos.
Actores
Técnico General.
Propósito
Obtener los grados de protección que existen pero los que el actor
decide.
Resumen
El caso de uso comienza cuando el actor decide que grado de
protección elegir para tener
las unidades edificatorias que lo
presentan, concluye así el caso de uso
Precondiciones
Que se encuentren unidades edificatorias con esos grados de
protección.
Referencias
R37
68
Capítulo III Descripción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Poscondiciones
-
Requerimientos
-
especiales
Prototipo (Ver en Anexo 18 los prototipos de interfaz de usuario del caso de uso.)
3.8 Diagrama de casos de usos del sistema.
El diagrama de Caso de Uso del sistema esta encapsulado en tres paquetes, uno para
las Búsquedas, uno para los Reportes y otro para Gestionar las variables del sistema.
Además de otros casos de uso que interactúan con sus respectivos actores. De este
análisis realizado sale como resultado el siguiente Diagrama de Casos de Uso del
Sistema. (Ver anexo 20- 23)
3.9 Conclusiones.
En el presente capítulo, y sobre la base de la propuesta de RUP para el desarrollo de
software, se realizó una modelación del negocio donde se pudo comprender la
estructura de las oficinas del Centro Histórico de Camagüey así como los problemas
actuales existentes, y se determinaron las mejoras potenciales que puede aportar, al
negocio, el sistema a desarrollar. Como resultado del proceso anterior se obtuvo un
diagrama de casos de uso del negocio donde se identificaron los actores del negocio y
casos de uso del negocio así como las relaciones entre los mismos.
Este capítulo contempla la captura de los requerimientos del sistema. La entrada
principal para este flujo de trabajo la constituye la modelación del negocio realizada,
obteniendo del mismo el conjunto de funcionalidades que debe desarrollar el sistema.
En este flujo se definió un grupo de paquetes y para cada uno se muestra el diagrama
de casos de uso del sistema con los actores del sistema, casos de uso del sistema y
relaciones entre ellos, así como una descripción en formato de alto nivel y los prototipos
de interfaz de usuario de cada caso de uso
69
Capitulo IV Construcción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
4
Capítulo
CONSTRUCCIÓN DE LA SOLUCIÓN PROPUESTA
4.1 Introducción.
El presente capitulo recoge todo el flujo de diseño e implementación, es decir se expone
la construcción de la solución propuesta.
En el diseño, el sistema es modelado y se conforma para que soporte todos los
requisitos que se le suponen, adquiriendo una comprensión en profundidad de los no
funcionales, restricciones relacionadas con el lenguaje de programación a utilizar,
componentes reutilizables, entre otros. [Jacobson, 2000]. Para este flujo de trabajo se
presenta primeramente el diagrama de clases del diseño agrupado según los casos de
usos, se modelan los nodos sobre los cuales se distribuye la aplicación mediante el
modelo de despliegue, se presenta el diagrama de clases persistentes y el de modelo
de datos, obtenido a partir de este ultimo.
La implementación, por su parte, toma los resultados del diseño e implementa el
sistema en términos de componentes. [Jacobson, 2000]. Se ha modelado el diagrama
de componentes, además se hace referencia a los estándares de programación y
diseños de interfaz que se siguen, y de forma general la política de seguridad bajo la
que se debe regir la implantación del sistema.
70
Capitulo IV Construcción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
4.2 Modelo de Diseño.
El modelo de diseño es un modelo de objetos que describe la realización física de los
casos de uso centrándose en cómo los requisitos funcionales y no funcionales, junto
con otras restricciones relacionadas con el entorno de programación, tienen impacto en
el sistema a considerar, siendo una entrada fundamental para las actividades de
implementación. [Jacobson, 2000].
4.3 Diagrama de Clases.
Para la elaboración del diagrama de clases se organizo por paquetes de las capas de
programación, el Paquete Common, Paquete Acceso a Datos, Paquete Lógico de
Datos, Paquete Interfaz de Usuario. (Ver anexo 24 - 28)
4.4 Diagrama Modelo de Datos.
Las entidades mostradas en este diagrama, obtenidas después de la normalización,
donde se tienen entidades débiles de otras, tal es el caso de la entidad época de las
Unidad edificatoria que es una entidad débil de Época, desgloses que es una entidad
débil de la Unidad edificatoria, otro caso es el de los usos donde hay dos relaciones de
entidades débiles. (Ver anexo 29)
4.5 Diagrama de Clases Persistentes.
En el sistema se generan documentos que no serán destruidos, solo quedaran
archivados como material de consulta, tal es el caso de los reportes generados. (Ver
anexo 30)
4.6 Principios de Diseño.
El diseño ha sido elaborado pensando en los usuarios finales, que serán: técnicos
especialistas en los datos que se manejaran en el software, pero que poseen, no en
todos los casos, conocimientos mínimos de computación, por tanto, se ha elegido una
interfaz amigable e intuitiva. Se ha mantenido un diseño consistente en todas las
formas, para lograr que el usuario se sienta cómodo y logre acostumbrarse rápidamente
a la aplicación.
71
Capitulo IV Construcción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
4.6.1 Estándares de Codificación.
Hoy día se hallan estándares de codificación para aplicaciones desarrolladas en la
mayoría de las plataformas existentes. Estos definen un conjunto de convenciones a ser
aplicadas por los programadores, que les permiten generar código más comprensible y
fácil de mantener en menos tiempo.
Resulta ventajoso utilizar un estándar para escribir código, entre dichas ventajas,
tenemos las siguientes:
1. Reducir errores
2. Escribir un código comprensible y fácil de leer.
3. Garantizar una buena comunicación entre los programadores del equipo.
4. Facilitar el mantenimiento del software.
En el diseño de la base de datos, las tablas se han nombrado igual que la entidad que
almacenan. Los campos de estas tablas, siguen la misma regla, y están nombrados
igual que las propiedades de las entidades.
Se ha tenido especial cuidado para nombrar clases, variables, y demás elementos,
precediendo cada nombre con un prefijo para su fácil identificación.
Un código fuente completo debe reflejar un estilo armonioso, como si un único
programador hubiera escrito todo el código de una sola vez. Al comenzar un proyecto
de software, establezca un estándar de codificación para asegurarse de que todos los
programadores del proyecto trabajen de forma coordinada.
La legibilidad del código fuente repercute directamente en lo bien que un
programador comprende un sistema de software. La mantenibilidad del código es la
facilidad con que el sistema de software puede modificarse para añadirle nuevas
características, modificar las ya existentes, depurar errores, o mejorar el rendimiento.
Aunque la legibilidad y la mantenibilidad son el resultado de muchos factores, una
faceta del desarrollo de software en la que todos los programadores influyen
especialmente es en la técnica de codificación. El mejor método para asegurarse de
que un equipo de programadores mantenga un código de calidad es establecer un
estándar de codificación sobre el que se efectuarán luego revisiones del código de
rutinas.
72
Capitulo IV Construcción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
4.6.2 Formato de los Reportes.
El formato de los reportes, es legible para el usuario, con los campos necesarios para la
comprensión de lo que el usuario desea, los colores dentro del reporte son claros, con
una letra clara y de tamaño adecuado a la hoja en la cual se va a imprimir, los campos
están organizados por columnas dentro del reporte con nombres conocidos por el
usuario que trabajara con ellos. Un ejemplo que ilustra el formato de estos reportes es
el que se muestra a continuación:
4.6.3 Concepción General de la Ayuda.
Puesto que esta destinada una gran variedad de usuarios, el diseño debe ser a la ves
sencillo, atractivo, y de una fácil usabilidad. Por otra parte el módulo de administración
no debe ser muy complejo de manipular.
Para la implementación del sistema no se siguió una estándar conocido pero se
planifico una guía a la hora de escribir el código con el objetivo de
73
Capitulo IV Construcción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
1.
Reducir los errores.
2.
Garantizar la obtención de un código claro y comprensible.
3.
Garantizar una buena comunicación entre los programadores del equipo.
4.
Facilitar el mantenimiento del software.
5.
Facilitar la implementación del sistema por otro equipo de trabajo.
4.6.4 Tratamiento de excepciones.
El sistema trata de minimizar al máximo los posibles errores que puedan existir, para
ello se decidió:
- En el caso de los datos introducidos por los usuarios, se trata que los usuario no tenga
que teclear la información, sino que el usuario pueda seleccionar la información y en
caso contrario se hace una validación utilizando las facilidades que brinda C# y la
plataforma .Net para la validación de datos entrados por los formularios.
- A la hora de realizar operaciones de modificación o eliminación de elementos, se
muestra los mismos en una lista donde el usuario pueda seleccionar los mismos. De
esta manera siempre serán válidos los datos de entrada.
Excepciones del sistema:
Cuando el usuario se va a autenticar en el sistema, se verifica que coincidan el usuario
y la contraseña.
Cuando se va a insertar algún valor en las tablas de la base de datos que ya existe
captura una excepción no permitiéndole al usuario duplicar los identificadores de las
tablas permitiéndole al usuario.
74
Capitulo IV Construcción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Cuando se va a conectar la aplicación con el servidor SQL y este no se encuentra en
ejecución.
Cuando se crea un nuevo usuario y la contraseña no es la misma en las dos ocasiones
que la piden:
Al ocurrir una de estas excepciones se manipulan con las posibilidades que nos brinda
el lenguaje utilizado, mostrando al usuario una información correcta y explicativa sobre
el posible error cometido.
Además los mensajes de advertencia, de errores, de seguridad, tienen un contenido
legible, fácil de comprender, y de orientación al usuario. Ejemplo:
75
Capitulo IV Construcción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
4.7 Modelo de Despliegue.
El modelo de despliegue es un modelo de objetos que describe la distribución física del
sistema en términos de cómo se distribuyen la funcionalidad entre los nodos del
computo. El modelo de despliegue se utiliza como entrada fundamental en la
actividades de diseño e implementación debido a que la distribución del sistema tiene
una influencia principal en su diseño [Jacobson, 2000]. (Ver anexo 31)
4.8 Modelo de Implementación.
El modelo de implementación describe cómo los elementos del modelo de diseño, como
las clases, se implementan en términos de componentes. Describe también cómo se
organizan los componentes de acuerdo con los mecanismos de estructuración
disponibles en el entorno de implementación y en el lenguaje o lenguajes de
programación utilizados, y cómo dependen los componentes unos de otros. [Jacobson,
2000].
4.8.1 Diagrama de Componentes.
Un componente se puede definir como el empaquetamiento físico de los elementos de
un modelo, como son las clases en el modelo de diseño. [Jacobson, 2000] .El diagrama
de los componentes que participan en la ejecución del presente sistema se muestra con
cada uno de sus paquetes, el Paquete Interfaces, el Paquete Lógica del Negocio y el
Paquete Acceso a Datos. (Ver anexos 32 - 36)
4.9 Conclusiones.
En el presente capítulo se han desarrollado los flujos de trabajo de diseño e
implementación que propone RUP, modelándose un grupo de artefactos en cada uno
de ellos. Como resultado de este capítulo se obtuvo el diagrama de clases del sistema.
Es importante señalar que UML (Lenguaje Unificado De Modelado) permite a los
desarrolladores visualizar los resultados de su trabajo en esquemas o diagramas
estandarizados. Se modelaron los nodos en los que se distribuye la aplicación. Se
76
Capitulo IV Construcción de la Solución Propuesta.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
muestra además el diagrama de clases persistentes a partir del cual se obtuvo el
modelo de datos señalando las consideraciones que se tuvieron en cuenta en dicho
proceso. El modelo de datos fue representado elaborando una descripción de cada
tabla de la base de datos. Como parte de la implementación fue elaborado el diagrama
de componentes en los que se estructura la aplicación. Para mayor claridad en cuanto a
los componentes se muestra una tabla descriptiva de cada uno. Este capítulo, además,
presentó los estándares de programación y de diseño de interfaz que se siguen para el
desarrollo del sistema, así como las medidas de seguridad a tener en cuenta.
77
Capitulo V Estudio de Factibilidad.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
5
Capítulo
ESTUDIO DE FACTIBILIDAD
5.1 Introducción.
Resulta de vital importancia conocer, desde los primeros momentos del desarrollo de un
software, los beneficios que este aporta en todos los sentidos con el objetivo de
determinar si su implementación resulta factible o no. Con este estudio se determinarán,
además, parámetros que ayudan a planificar el trabajo a realizar en cuanto a cantidad
de personas que se necesitan y estimar el tiempo de duración del mismo teniendo en
cuenta el tamaño del sistema, experiencia en otras aplicaciones del mismo tipo,
reusabilidad, características de la plataforma a utilizar, trabajo en equipo, entre otros
aspectos.
5.2 Planificación.
En esta primera etapa de la técnica, se definen cinco tipos de funciones de usuario y se
clasifican según su complejidad. Estas funciones son: entradas de usuario al sistema
que aportan datos a la aplicación, salidas de usuario que le brindan a éste información
de la aplicación, peticiones de usuario, ficheros lógicos internos y ficheros o interfaces
externas que en este sistema no existen. [De la Fuente, 1999] La clasificación que se
realiza de cada función es en simple, media o compleja.
78
Capitulo V Estudio de Factibilidad.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Nombre de la entrada
externa
Autenticación.
Adicionar Unidad
Edificatoria.
Eliminar unidad
Edificatoria.
Adicionar Desgloses.
Eliminar Desgloses
Adicionar calles
Eliminar calles.
Adicionar valor
Eliminar valor
Adicionar carácter
Eliminar carácter
Adicionar barrio
Eliminar barrio
Adicionar
transformaciones
Eliminar transformaciones
Adicionar usos
Cantidad de Cantidad de
Ficheros
Elementos de datos
1
2
Clasificación (Simple,
Media y compleja)
Simple
1
28
Medio
1
28
Medio
1
1
1
1
1
1
1
1
1
1
1
29
29
2
2
2
2
2
2
2
2
2
Medio
Medio
Simple
Simple
Simple
Simple
Simple
Simple
Simple
Simple
Simple
1
3
2
8
Simple
Medio
Eliminar usos.
3
8
Medio
Adicionar épocas
Eliminar épocas
2
2
6
6
Medio
Medio
Adicionar estado
constructivo.
Eliminar estado
constructivo
Adicionar tipo de planta
1
2
Simple
1
2
Simple
1
2
Simple
Eliminar tipo de planta
1
2
Simple
Adicionar tipo de
edificación
Eliminar tipo de
edificación
1
2
Simple
1
2
Simple
Tabla1. Entradas externas
Nombre de la salida Cantidad de Cantidad
de Clasificación (Simple,
externa
Ficheros
Elementos de datos Media y compleja)
Listado de las Unidades
1
2
Simple
Edificatorias.
79
Capitulo V Estudio de Factibilidad.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Listado de los Desgloses.
Listado de las calles.
Listado de los estados
constructivos.
Listado de la épocas de las
unidades edificatorias.
Listado del portal.
Listado
del
tipo
de
edificación.
Listado del tipo de planta.
Listado de las
transformaciones.
Listado del uso.
Listado del valor.
Listado del barrio.
Listado del carácter.
1
1
1
3
2
2
Simple
Simple
Simple
1
2
Simple
1
1
2
2
Simple
Simple
1
1
2
2
Simple
Simple
1
1
1
2
2
2
Simple
Simple
Simple
1
2
Simple
Tabla 2. Salidas Externas
Nombre de la petición
Obtener Unidades
Edificatorias dada una o
varias variables.
Obtener Categorías
predefinidas
Obtener
grados
de
Protección.
Obtener Grados de
Protección predefinidos.
Tabla 3. Peticiones
Cantidad de Cantidad
de Clasificación
(Simple,
Ficheros
Elementos de datos Media y compleja)
1
2
Simple
Nombre del fichero interno
1
2
Simple
1
3
Simple
1
2
Simple
Cantidad
de record
Tabla Unidad Edificatoria
1
Tabla Desgloses.
1
Tabla Calles.
1
Tabla Valor.
1
Tabla Carácter.
1
Tabla Época de las Unidades
1
edificatorias.
Tabla Época de los
1
Desgloses.
Tabla Barrios.
1
Tabla Estado Constructivo.
1
Tabla Portal.
1
Tabla Tipo de Edificación.
1
Cantidad
de Clasificación
(Simple,
Elementos de datos Media y compleja)
28
Medio
29
Medio
3
Simple
2
Simple
2
Simple
2
Simple
80
5
Simple
2
2
2
2
Simple
Simple
Simple
Simple
Capitulo V Estudio de Factibilidad.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Tabla Tipo de Planta.
Tabla Transformaciones.
Tabla Uso por Redes.
Tabla Uso por Categorías.
Tabla Uso unidad Edificatoria
de Inf. Territorio.
1
1
1
1
1
2
2
2
5
3
Simple
Simple
Simple
Simple
Simple
Tabla eje
Tabla nodo
1
1
2
2
Simple
Simple
Tabla rol
1
2
Simple
Tabla usuario
Tabla 4. Ficheros Internos
1
3
Simple
Elementos
Simples
No X Peso
lógicos 18
7
Ficheros
internos
Entradas externas
Salidas externas
Peticiones
Total
17
13
4
Medios
No X Peso
2
10
3
4
3
8
0
0
4
5
4
Complejos
No X Peso
0
15
0
0
0
Subtotal de puntos de
función
146
6
7
6
83
52
12
293
Tabla 5. Puntos de función desajustados.
5.2 Costos.
Características
Puntos de función desajustados
Lenguaje
Valor
Instrucciones fuentes por puntos de función
Instrucciones fuentes por lenguaje (miles de instrucciones)
Instrucciones fuentes (miles de instrucciones)
Tabla 6. Cantidad de Instrucciones Fuentes
Factores
PREC
Valor
293
C# (80 %)
SQL (20%)
(59)
(39)
(14,694)
(1,7141)
16,41
Justificación
4,96
Este sistema presenta un análisis y
diseño que lo hace totalmente diferente.
81
Capitulo V Estudio de Factibilidad.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
FLEX
3,04
TEAM
3,29
RESL
4,24
PMAT
6,24
Existe cierta flexibilidad entre los
analistas del sistema, los programadores
y el cliente.
Los miembros del equipo que desarrollan
el software son altamente cooperativos,
con poca experiencia en los
compromisos.
Existen riesgos críticos, que son
identificados, generalmente con la
tecnología, la misión de la empresa,
interfaz con el usuario y el desempeño de
los programadores. Para estos riesgos se
traza un plan de acción.
El sistema presenta un nivel de madurez
alto.
Tabla 7. Factores de escala
Cálculo de:
Esfuerzo
Valor
81,53
Justificación
Salario medio
225
ΠEMi ≈ 1,69
E ≈ 1,13
∑SFi = 21,77
PREC = 4,96
FLEX = 3,04
RESL = 4,24
TEAM = 3,29
PMAT = 6,24
PM ≈ 81,53
F ≈ 0,32
Se necesita 5 personas para la realización
del sistema.
C =CHM * PM
CHM = 5 * 225 = 1125
PM ≈ 81,53
El salario mínimo es de 225 pesos.
RCPX
1,00
RELY = BASICO
Tiempo de desarrollo
15 meses
Cantidad de personas
5
Costo
91 721,25
DOCU = ALTO
CPLX = ALTO
DATA = NOMINAL
RUSE
1,00
Existe
concordancia
entre
la
documentación y las necesidades del ciclo
de vida.
PDIF
1,00
El .NET es una plataforma estable, no hay
restricciones fuertes de memoria o tiempo
82
Capitulo V Estudio de Factibilidad.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
nominal
PREX
1.00
Los desarrolladores tienen buena
experiencia en la plataforma y
herramientas de desarrollo. Lleva 1 año.
FCIL
0,87
Se hace un uso notable de herramientas
CASE para documentar implementar el
sistema.
SCED
1,00
Las exigencias para el cumplimiento de
cronograma son normales.
PERS
0,83
ACAP = ALTO
PCAP = ALTO
PCON = ALTO
Tabla 8. Cálculos Finales de La Estimación de Costos y Esfuerzos.
5.3 Beneficios tangibles e intangibles.
5.3.1 Beneficios tangibles.
No es un software con fines comerciales, aunque puede ampliarse con estos fines,
adaptarse a otras empresas u organismos que trabajen con datos del patrimonio
histórico-arquitectónico de la ciudad de Camagüey, además puede ser empleado en
otras ciudades del país.
Los beneficios tangibles que se observan con esta aplicación en la empresa son, una
reducción en el costo telefónico, en los recursos materiales que se empleaban para
archivar toda la información de los inmuebles de la ciudad, además del costo por
empleados que debían tener para poder satisfacer las necesidades del cliente.
En cuanto al tiempo de demora en la realización de los trámites, si se compara como se
realizan actualmente los trámites.
83
Capitulo V Estudio de Factibilidad.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
El tiempo que se toma un técnico especialista para realizar una búsqueda con el
sistema propuesto es mucho menor, ahora solo tiene que pedirle al sistema que lo que
desea, no tiene que realizar la búsqueda manual en los grandes archivos que existen en
el centro histórico de Camagüey, a esto se suma que ya el cliente no tendrá que
trasladarse hasta el inmueble que desee observar, si no que el propio sistema le
mostrara un a imagen del mismo. Así se gana en tiempo, y no tienen el riesgo de perder
al inversionista por la demora en la respuesta que debe recibir. El sistema brinda la
posibilidad de realizar las búsquedas por múltiples conceptos, facilitando la localización
de la información necesitada de forma eficiente.
Es apreciable la disminución del tiempo de respuesta al usuario para la realización de
un trámite, estimándose se invierta sólo la cuarta parte del tiempo que se invertía
anteriormente llenando todos los modelos, buscando en los archivos, haciendo
cruzamientos de las variables patrimoniales.
5.3.2 Beneficios intangibles.
Por otra parte, con la puesta en práctica de este sistema se logra centralizar la
información de todos los inmuebles del centro histórico de la ciudad de Camagüey, lo
cual se traduce en una disminución notable de los errores que se cometen en los
valores de cada una de las variables. De igual forma se simplificará el trabajo de los
técnicos especialistas y se creará una nueva y rápida vía de comunicación entre todas
las oficinas, así como de actualización y búsqueda de información.
5.4 Análisis de costos y beneficios.
El desarrollo de este sistema no supone grandes gastos de recursos, ni tampoco de
tiempo; la base de datos que contiene la información, puede ser alojada en un servidor
central. La tecnología utilizada para el desarrollo del sistema es .NET, que es gratis. El
sistema se ha diseñado pensando en los usuarios, en un fácil aprendizaje, no hay que
incurrir en gastos de contratar a un especialista del sistema para educar a los
trabajadores en el empleo del mismo.
84
Capitulo V Estudio de Factibilidad.
DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
El gasto radica más bien en la compra de un nuevo equipamiento tecnológico para las
oficinas del centro histórico, ahora toda la información estará almacenada en la base de
datos, y se tendrá acceso a ella a través de los técnicos especialista de la empresa.
Se investigaron otras soluciones existentes sobre el almacenamiento de todas las
variables de los inmuebles, y se llegó a la conclusión de que no se ajustan a las
características del entorno de la ciudad, además podría resultar muy costoso invertir en
ellas para después adaptarlas a las condiciones de la ciudad.
El sistema puede ser extendido para uso general, obteniéndose un producto
comercializable que puede ser fuente de ingresos.
El costo del sistema asciende a un total de 91 721,25 pesos, a pesar del precio se
considera que va aprestar muchos beneficios para el centro histórico de Camagüey, y
para la ciudad en su conjunto.
5.5 Conclusiones.
Del estudio realizado anteriormente, y a partir del análisis de los beneficios, tanto
tangibles como intangibles, se concluye que es factible el desarrollo de esta aplicación,
por todos los aportes económicos y sociales que brinda.
85
Conclusiones. DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Conclusiones.
Con la implantación exitosa del sistema, se dará solución a los problemas actuales
existentes en las oficinas del Centro Histórico de la Ciudad de Camagüey, lo cual
implica un mejoramiento en el servicio que se ofrece a los usuarios, en las condiciones
de trabajo de los técnicos, en la comunicación entre las distintas oficinas, así como una
reducción de costos relacionados con los recursos materiales empleados para realizar
anteriormente los servicios.
Se ha puesto en práctica una solución con un diseño y una implementación fácil de
manipular por los usuarios y futuros programadores que puedan darle mantenimiento al
sistema.
El desarrollo del sistema se ha basado en el Proceso Unificado de Desarrollo de
Software, como parte de lo cual se realizó una modelación del negocio con vista a
entender el contexto donde se va a implantar el sistema y se presentó un grupo de
artefactos para los flujos de trabajo de requisitos, diseño e implementación que propone
dicho proceso.
Con los beneficios expuestos, tanto tangibles como intangibles, se determinó que el
desarrollo de la aplicación es realmente factible, siendo indudable la revolución que
experimentará este servicio en nuestro país y en especial en la Ciudad Agramontina.
86
Recomendaciones. DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Recomendaciones.
Se recomienda la puesta en práctica del sistema en las oficinas del Centro Histórico de
la ciudad de Camagüey en el menor tiempo posible con vista a facilitar el trabajo en las
mismas.
Es importante elevar el software a una nueva versión que perfeccione sus
funcionalidades con elementos que surjan en la fase de explotación del mismo.
Una recomendación imprescindible lo constituye el asegurarse que, para la puesta en
marcha del sistema, se tomen las medidas de seguridad expuestas debido a la
importancia de la integridad de la información que se maneja.
Se continúe con el programa de informatización de la sociedad que prevé la cercanía de
la población a los servicios que ofrecen los diferentes sectores, lo cual se traduce en
satisfacción de los ciudadanos.
87
Referencias Bibliograficas. DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Referencias Bibliográficas.
[De la Fuente, 1999] De la Fuente Moya, Antonio. Cómodo v.2 “Modelo de estimación
de costes para proyectos de software”. Mayo 1999. [Fecha de consulta: 11 de abril de
2005] Disponible en: \\ceis\Clases\pregrado\4to\1er semestre\Ingenieria de Software
I\Curso 03-04\06 Planificación y Estimación
[Información sobre Bases de Datos]Historia de los sistemas de bases de datos, V
[Fecha de consulta 15 de mayo 2005] Disponibles en:
http://www3.uji.es/~mmarques/f47/apun/node6.html. (14/02/2004).
http://www3.uji.es/~mmarques/f47/apun/node39.html. (14/02/2004)
[Inei, 2004] Arquitectura Cliente Servidor. [Fecha de consulta: 16 de febrero de 2005]
Disponible en: http://www.inei.gob.pe/cpimapa/banco pub/libfree/lib616/cap0302.htm
[Jacobson, 2000] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. “El Proceso
Unificado de Desarrollo de Software”. 2000. Addison Wesley.
[Leyton, 2000] Leyton Eduardo: “Ingeniería de software con UML. Auditorias de
tecnología de la información. [Fecha de consulta: 5 de abril de 2005]. Disponible en:
http://www.eduardoleyton.com/Uml.pdf
MIC-Informatización, 2004] Ministerio de la Informática y las Comunicaciones de Cuba.
“Informatización de la Sociedad”. [Fecha de consulta: 10 de mayo de 2005] Disponible
en: http://www.mic.gov.cu/sitiomic/hinfosoc.asp
[Sariol, 2004] Sariol Hernández, Elvira. “Sistema de indicadores y variables
patrimoniales, arquitectónicas y urbanas para el manejo de las potencialidades del
cambio de uso en los inmuebles del Centro histórico de Camagüey.”. Tesis en opción
del título de maestría en Conservación del Patrimonio Edificado. Camagüey. Julio 2004.
88
Referencias Bibliograficas. DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
[Tutorial de C#, 2003] Introducción al lenguaje C#. [Fecha de consulta 10 de junio 2005]
Disponible en: http://www.microsoft.com/C#.pdf
[Tutorial de .NET]Características de Visual Studio .NET. Microsoft Corp. 2005. [Fecha
de consulta 5 de abril 2005] Disponible en
http://www.microsoft.com/latam/vstudio/producto/caracteristicas.pdf
89
Bibliografía. DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Bibliografía.
•
Arquitectura Cliente/Servidor
http://www.inei.gob.pe/cpi-mapa/bancopub/libfree/lib616/cap0301.HTM
(11/5/2005)
•
Curso de iniciación a la programación con c#. pdf.
•
Elvira Sariol Hernández. Sistema de indicadores y variables patrimoniales,
arquitectónicas y urbanas para el manejo de las potencialidades del cambio de
uso en los inmuebles del Centro histórico de Camagüey.”. Tesis en opción del
título de maestría en Conservación del Patrimonio Edificado. Camagüey. Julio
2004.
•
Object Management Group. Unified Modeling Language Specification. V1.5.
Marzo 2005.
•
Rumbaugh, J.; Jacobson, I. y Booch, G.; “El Lenguaje Unificado de Modelado.
Manual de Referencia. 2000. Addison-Wesley.
AUTORES
- Ing.Yanesky Montero Martínez.
Universidad de las Ciencias Informaticas, Cuba.
e-mail: [email protected]
- Ing. Yorlenis Dominguez Núñez.
Departamento Gestion Hotelera. Escuela de Hoteleria Turismo Santa Lucia , Cuba
e-mail: [email protected]
90
Bibliografía. DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
91
Glosario de Términos. DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Glosario de Términos.
Termino.
Accesos
Áreas
Carácter
Categoría
tipológica
Eje
Estado
constructivo
Concepto
Acceso principal:
Ubicación del acceso principal del inmueble.
Acceso secundario:
Caracteriza al inmueble por la presencia de un acceso secundario
Área de parcela:
Área de lote:
Área construida:
Área construidas en primer nivel.
Área ocupada:
Área total útil construida que posee el edificio.
Excepcional:
Cuando está considerado como edifico único, raro, exponente máximo de una época o estilo.
Relevante:
Cuando representa un edificio de gran importancia porque sus significados ilustran aspectos
importantes de la obra, tales como función y sistema constructivo, entre otros.
Representativo o típico:
Cuando se considera un edificio común de su época o estilo, cuyas características pueden
observarse en otros de su mismo origen.
Armónicos con elementos típicos:
Cuando se trata de edificios pobres estéticamente o que han perdido sus valores por
transformaciones sufridas pero conservan aún algunos elementos de valor.
Armónicos:
Cuando no rompen con el conjunto en el que se ubican
Inarmónicos:
Edificios sin valores que rompen la imagen visual del conjunto.
El grupo de edificios que mantienen características esenciales del tipo,
diferenciándose en una variable no esencial. Siguiendo ese principio se hace una
individualización de tipos arquitectónicos por medio de análisis de las características
estructurales, dimensiónales y distributivas (organización espacial) y las necesidades
de uso (organización funcional). El conjunto físico del centro histórico se dividió en
tres categorías tipológicas que ofrecen una base, lo más rigurosa posible, en lo que
respecta a la refuncionalización y utilización de los edificios(A, A1, A2, A3, B1, B2,
B3, B4, C1, C2, C3)
La senda que, caracterizada por el papel desempeñado en un momento histórico,
resulta contenedora de fuerza identitaria, la calle vehicular y peatonal con potencial
de movimiento. Dentro de los ejes urbanos se denominan principales o claves,
aquellos que portan identidad singular que las distingan de los canales circundantes
por una concentración de uso o una actividad especial a lo largo de su márgenes,
una cualidad espacial característica, una textura especial de piso o fachada, un
trazado particular de alumbrado, un conjunto singular de olores o sonidos, un detalle
típico o un modo de arbolado.
Ruinoso:
Edificio en alto grado de deterioro, La cubierta esta seriamente afectada, Esta en peligro la
estabilidad del mismo.
92
Glosario de Términos. DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Fachada a plaza
Grado de
protección
indicadores
Lote
Longitud de la
fachada
Manzana
Nodo
Parcela
Parcelación
Potencial de uso
Puntal
Tiene galería
Malo:
Edificio en alto grado de deterioro, La cubierta esta afectada, No peligra la estabilidad del
mismo.
Regular:
Edificio con deterioros importantes, el estado de la cubierta permite filtraciones. Requiere
reparaciones importantes que interesan la estructura del mismo
Bueno:
Edificio en buen estado técnico que solo requiere medianas y pequeñas reparaciones.
Caracteriza la relación directa del inmueble con una plaza.
Indicadores de la categoría cultural de los inmuebles que integran un conjunto urbano
de valor histórico-cultural.(I, II, III, IV)
Patrones a seguir, los mismos pueden variar en dependencia de cada región a
estudiar y expresan la forma de manifestarse los elementos de mayor significación
por períodos reflejando el comportamiento de cada uno de estos, desde el punto de
vista evolutivo
Estratigrafía de la parcela tradicional, considerando como unidad del lote la porción o
parte de la unidad edificatoria que, desde el punto de vista jurídico —Registro de la
propiedad— funciona como entidad independiente. Bajo este criterio la sumatoria de
los lotes conforma la parcela tradicional con su correspondiente unidad edificatoria.
Ancho de fachada del inmueble.
Unidad básica de información territorial (UBIT) y se corresponde con la tradicional
concepción de un área delimitada por ejes viales o elementos naturales.
Los focos estratégicos a los que puede entrar el observador, tratándose típicamente
de confluencias de sendas o de concentraciones de determinadas características.
Serán nodos principales aquellos que históricamente determinaron un recorrido
cultural en la ciudad; mientras que los secundarios serían aquellos que, por ser
formalmente pequeños y jugar un papel colateral en las tradiciones de los habitantes
de la ciudad, resultan contenedoras de funciones socioculturales de secundarias.
Punto de partida los resultados acerca del estudio de la cuadrícula en América, sello
identitario del proceso de poblamiento, que indica que el modelo de ciudad incluye
una forma típica de parcelación consistente en dividir las manzanas en cuatro partes
cuadradas iguales
Se utiliza en su carácter histórico, es decir, el espacio de terreno que, perteneciente a
una manzana, se corresponde con el área en la cual quedó emplazada la unidad
edificatoria
Funciona como un registro que detalla el uso de suelo de cada inmueble y que pueden
recuperarse para nuevas inversiones, este contempla los locales vacíos subutilizados o
explotados por un uso agresivo, siendo susceptibles de ser refuncionalizados.
El uso del suelo juega un papel “regenerador, catalizador, e integrador del desarrollo” de ahí
que deban fijarse oportunamente las pautas a seguir dentro de las políticas de intervención
urbana, máxime si en el caso cubano se ha heredado el enfoque de Uso y no el de valor del
suelo. En la actualidad se trata de lograr la optimización económica, financiera, social y
ambiental con los recursos disponibles.
Altura mayor que alcanza el edificio en fachada.
Caracteriza el inmueble partir de la presencia o no de galería.
Caracteriza el inmueble a partir de la presencia o no del portal.
Tiene portal
(publico o
privado)
Rectangular, cuadrada, U, C, L, trapezoidal
Tipo de planta
Transformaciones Sin transformar:
Edificio que no tiene añadidos desvalorizantes La estratificación puede estar presente
armónicamente.
Transformación reversible:
Edificios que han sufrido cambios inadecuados que se pueden revertir.
93
Glosario de Términos. DUAC
⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
Transformación irreversible:
Edificios que han sufrido cambios inadecuados que no se pueden revertir
Unidad
edificatoria
La construcción que por sus elementos y propiedades mantiene una unidad armónica
en relación con su valor patrimonial, unidad básica en el patrimonio edificado para la
intervención a escala urbana en el centro histórico.
uso
Baldío:
Terreno sin construir.
Sin uso:
Edificio que no está en uso por diferentes razones funcionales o técnicas, de propiedad, etc.
Industria:
Dedicado a funciones productivas industriales
Talleres:
Dedicado a funciones productivas ligeras.
Administrativo:
Dedicados a funciones de organización, planificación y dirección.
Salud:
Servicios de salud en los diferentes niveles.
Educación:
Edificios dedicados a la función educacional
Servicios:
Cuya función es ofrecer servicios de diferente tipo
Comercio MN:
Red comercial en moneda nacional
Comercio MLC:
Red comercial en dólares.
Alojamiento:
Instalación pública o privada que ofrezca alojamiento.
Cultura:
Servicios culturales
Gastronómico:
Edificios dedicados a la función de restauración
Deporte:
Instalaciones deportivas
Vivienda:
Edificios residenciales
Mixto:
Edificios que combinan la vivienda y otro servicio generalmente en planta baja
Religioso:
Edificios dedicados al culto religioso de cualquier denominación, incluyendo logias.
Militar:
Edificios de uso militar o de policía.
Valor
Arquitectónico:
Está determinado por sus características distintivas de un tipo, período, estilo o forma de
construcción. Representa el trabajo de un maestro y se distingue el carácter de su autoría.
Artístico:
Está en función de sus valores estéticos, visuales y simbólicos. Contenga obras de arte como
parte del edificio
Histórico:
Está asociado o vinculado con la historia del país o patrones socio-culturales distintivos de una
región o de la nación. Como fuente de información y conocimiento de la sociedad pasada.
Asociado con la vida de personalidades significativas desde el punto de vista histórico.
Contextual:
Está determinada por la armonía de la obra en el entorno en que se encuentra enclavada
aunque no posea valores arquitectónicos e históricos.
Inmueble:
Edificios que carecen de valor.
Variable
Propiedades que pueden tomar una serie de valores, en este caso patrimoniales,
arquitectónicos o urbanos dentro de ciertos límites, y que definen aspectos básicos
del objeto de estudio.
94
Anexo 1. Gestionar Unidad Edificatoria.
Anexo 2. Gestionar Calles.
Anexo 3. Gestionar Desgloses.
Anexo 4. Gestionar Valor.
Anexo 6. Gestionar Estado Constructivo.
Anexo 5 Gestionar Transformaciones.
Anexo 7. Gestionar Carácter.
Anexo 8. Gestionar Época de los desgloses.
Anexo 9. Gestionar Época de las UE.
Anexo 10. Gestionar Tipo de Planta.
Anexo 11. Gestionar Barrio.
Anexo 13. Gestionar Tipo de Edificación.
Anexo 12. Gestionar Portal.
Anexo 14. Autenticarse.
Anexo 15. Administrar sistema.
Anexo 16. Categorías Tipológicas. (Ejemplo, existe la de las A, C, D)
Anexo 17. Búsquedas libres.
Anexo 18. Grado de protección predefinido.
Anexo 19. Obtener Grado de Protección.
Diagrama de casos de uso del sistema.
Administrar Sistema
Autenticar Usuario
Gestionar
Variables.
Reportes
Administrador de
Sistema
Usuario
Técnico
especialista ...
(f rom Actors)
(f rom Actors)
Gestionar
Busquedas
Tecnico General
Técnico
especialista ...
(f rom Actors)
Anexo 20. Diagrama de Caso de Uso del Sistema.
Mostrar UBIT por calles
Diagrama de casos de uso del sistema. Paquete Búsquedas Libres.
Búsquedas Libres
Obtener Grado de Protección
Tecnico General
(f rom Use-Case Model)
Obtener Categorías Predefinidas.
Obtener Grado de Protección
predefinidos.
Anexo 21. Paquete Búsqueda.
Diagrama de casos de uso del sistema. Paquete Gestionar Variables.
Reportes.
Gesti onar Desgl ose Gesti onar Epoca de l as Uni dades
Edi ficatori as
(f rom Us e-Cas e Model)
Gestionar Uni dad Edi fi catori a
Gesti onar Imagenes
(f rom Us e-Cas e Model)
(f rom Us e-Cas e Model)
Gesti onar Epoca de l os Desgloses
Gesti onar Cal l es
Gesti onar Uso
Gesti onar Val or
T écnico
especi al i sta ...
(from Actors)
Gestionar Uso por Categori as.
Gestionar Transform aci ones
Gesti onar Uso por Redes
Gesti onar Ti po Pl anta
Gesti onar Estado Constructi vo
Gesti onar Tipo Edi ficaci on
Gesti onar Carácter
Gesti onar Portal
Anexo 22. Paquete Gestionar Variables.
Gesti onar Barrio
Generar reportes de Unidad
Generar reporte de Carácter. Edi ficatori a que consti tu...
Generar reporte de T ipo de
Edi ficaci on.
Generar reporte T ipo Pl anta.
Generar reportes de todos l os
desgl oses.
Generar reporte de todas las
Uni dades Edi fi catori as.
Generar reporte de Barrio.
<<extend>>
<<extend>>
<<extend>>
<<extend>>
Generar reporte de Unidad
Edi ficatori a según Usos 2
<<extend>>
<<extend>>
<<extend>>
Generar reporte de
T ransformaciones.
<<extend>>
<<extend>>
Generar reporte de Unidad
Edi ficatori a según Usos 1
Generar reporte de Uni dad
Edi ficatori a con categoría A1..A3
<<extend>>
<<extend>>
<<extend>>
Generar reporte de Unidad
Edi ficatori a según Usos
Generar Reporte
<<extend>>
<<extend>>
Generar reporte de Unidad
Edi ficatori a con categoría B1...B4.
<<extend>>
Generar reporte por época de l as
Uni dad Edificatori a
<<extend>>
<<extend>>
<<extend>>
<<extend>>
Generar reporte por época de l os
desgl oses.
Generar reporte de Unidad
Edi ficatori a con categoría C1...C3.
<<extend>>
<<extend>>
Generar reporte de Unidad
Edi ficatori a con categoría D1...D7.
Generar reporte de Unidad
Edi fi catori a según ti po pla...
Generar reporte de Unidad
Edi fi catori a modi ficadas.
Generar reporte de Unidad
Edi ficatori a con grado de protecc...
Generar reporte de Unidad
Edi ficatori a Estado Constructi vo
Generar reporte de Unidad
Edi ficatori a de 1, 2, 3, 4 pl antas.
Anexo 23. Paquete Gestionar Reportes.
Diagrama de clases.
Diagrama de
clases DAL
Diagrama de
clase BLL
Diagrama de clases
Common
Diagrama de
clases de Interfaz
Anexo 24. Relación entre paquetes.
Diagrama de clases
ConexionInfo
BaseDatos : String
ConnStr : String
contraseña : String
Name : String
Servidor : String
TipoConexion : Boolean
Usuario : String
MiConexion()
BuildConnSrt()
CCalle
nombre : String
CTEpocaUE
CTEpoca
CTUso
Epoca : String
Desde : String
Hasta : String
Uso : String
CTMasEspecifico
Epoca : String
CTPortal
especificacion : String
area : Double
Portal : String
CTBarrio
Barrio : String
Constantes
BoolNull : Boolean
CadNull : String
DecimalNull : Decimal
FloatNull : Float
IntNull : Integer
CLote
NroCasa : String
Cod_Postal : String
P_Principal : Boolean
AreaLote : Double
LongitudFachada : Double
NroPlantas : Integer
patio : Boolean
Anexo 25. Paquete Common.
CTValor
Valor : String
CTipoEdificacion
Tipo : String
CTTransformaciones
Transformaciones : String
CUsoEspecifico
especificacion : String
CTipoPlanta
Planta : String
CTEstadoConstructivo
Estado : String
CUnidadEdificatoria
Acceso_Secundario : Boolean
Compatibilidad : Boolean
Calle : String
Valor : String
Caracter : String
Estado : String
Transformaciones : String
Epoca : String
Uso : String
Diagrama de clases. Paquete de
Lógico
Acceso
de los
a Datos.
Datos. .
DALTipo_Edificacion
ActualizarTipoEdificacion()
EliminarTipoEdificacion()
AdicionarTipoEdificacion()
ObtenerIdDadoTipoEdifi()
ObtenerTipoDadoId()
ObtenerTablaTipoEdificaciono()
DALTValor
ActualizarValor()
EliminarValor()
AdicionarValor()
ObtenerIdValorDadoValor()
ObtenerValorDadoIDValor()
ObtenerTablaValor()
DALTEstadoConstructivo
ActualizarEdoConstructivo()
EliminarEdoConstructivo()
ActualizarEdoConstructivo()
ObtenerEdoDadoIdEdo()
ObtenerIdDadoEdo()
ObtenerTablaEdoCons()
DALTUso
AdicionarUso()
EliminarUso()
ActualizarUso()
ObtenerIdDadoUso()
ObtenerTablaUso()
ObtenerUsoDadoId()
ObtenerUsoDadoDadoMasEspecifico()
DALTTransformaciones
ActualizarTransf()
EliminarTransf()
AdicionarTransf()
ObtenerTransfDadoID()
ObtenerIdDadoTransform()
ObtenerTablaTransf()
DALTCaracter
AdicionarCaracter()
EliminarCaracter()
ActualizarCaracter()
ObtenerIdDadoCaracter()
ObtenerCaracterDadoId()
ObtenerTablaCaracer()
DALTPortal
ActualizarPortal()
EliminarPortal()
AdicionarPortal()
ObtenerIdDadoPortal()
ObtenerPoratlDadoId()
ObtenertablaPortal()
DALLote
AdicionarDesg lose()
EliminarDesglose()
ActualizarDesg lose()
ObtenerDesgloseDadoUE()
ObtenerIdDadoNodo()
ObtenerNodoDadoId()
ObtenerTablaLote()
ObtenerTablaNodo()
DALUsuario
AdicionarUsuario()
EliminarUsuario()
ObtenerIdRolDadoRol()
ObtenerRol()
ObtenerTablaRol()
ObtenerTablaUsuario()
VerificarUsuario()
DALTMasEspecifico
ActualizarMasEspecifico()
EliminarMasEspecifico()
AdicionarMasEspecifico()
ObtenerEspecDadoIdMasEspe()
ObtenerIdDadoEspecif()
ObtenerIdDadoIdEspeci()
ObtenerTablaMasEspecifico()
Anexo 26. Paquete de Acceso a Datos.
DALCalle
ActualizarCalle()
AdicionarCalle()
BorrarCalle()
ObtenerCalleDadoIdCalle()
ObtenerEjeDadoId()
ObtenerIdDadoCalle()
ObtenerIdDadoEje()
ObtenerIdDadoIdCalle()
ObtenerTablaCalle()
ObtenerTablaEje()
DALTBarrio
ActualizarBarrio()
EliminarBarrio()
ActualizarBarrio()
ObtenerBarrioDadoIdBarrio()
ObtenerIdDadoBarrio()
ObtenerTablaBarrio()
DALUsoEspecifico
ActualizarEspecifico()
EliminarEspecifico()
AdicionarEspecifico()
ObtenerEspecificacionDadoId()
ObtenerEspecDadoMasEspec()
ObtnerIdEspecDadoEspecificacion()
ObteneridDadoIdUso()
ObtenerTablaUsoEspecifico()
ObtenerTablaEspecificoDadoUso()
DALTipo_Planta
ActualizarTipoPlanta()
EliminarTipoPlanta()
AdicionarTipoPlanta()
ObtenerIdDadoPlanta()
ObtenerTipoPlantaDadoId()
ObtenerTablaTipoPlanta()
DALTEpocaUE
ActualizarEpocaUE()
EliminarEpocaUE()
AdicionarEpocaUE()
ObtenerEpocaUEDadoEpoca()
ObtenerEpocaUEDadoIDEpocaUE()
ObtenerIdEpocaUEDadoEpocaUE()
ObtenerTablaEpocaUE()
DALTEpoca
ActualizarEpoca()
AdicionarEpoca()
EliminarEpoca()
ObtenerIdDadoEpoca()
ObtenerIdEpocaDadoIdEpocaUE()
ObtenerTablaEpoca()
ObtenertablaEpocaDadoEpocaUE()
DALUnidad_Edificatoria
ActualizarCompatibilidad()
ActualizarUnidadEdif()
EliminarUnidadEdif()
AdicionarUnidadEdif()
Area_total_construida()
Area_total_parcela()
Barrio()
Calle()
Caracter()
Categ oriaA1()
Categ oriaA2()
Categ oriaA3()
Categ oriaB1()
Categ oriaB1a()
Categ oriaB1b()
Categ oriaB2()
Categ oriaB2a()
Categ oriaB2b()
Categ oriaB3()
Categ oriaB3a()
Categ oriaB3b()
Categ oriaC1()
Categ oriaC2()
Categ oriaC3()
Categ oriaA1()
Categ oriaA2()
Categ oriaA3()
Epoca()
Estado_Constructivo()
GradoProteccion1()
GradoProteccion2()
GradoProteccion3()
GradoProteccion4()
Longitud_Fachada()
ModificacionesAmpliacion()
ModificacionesDivision()
ModificacionesFachada()
ModificacionesEstrac()
Nodo()
NroPlantas()
ObtenerTablaUE()
Patio()
Portal()
Puntal()
Transformaciones()
Uso()
Valor()
BLLCalle
ActualizarC alle()
AdicionarC alle()
BorrarCalle()
ObtenerCalleDadoIdCalle()
ObtenerEjeDadoId()
ObtenerIdD adoCalle()
ObtenerIdD adoEje()
ObtenerIdD adoIdC alle()
ObtenerTablaCalle()
ObtenerTablaEje()
BLLLote
AdicionarD es glose()
EliminarDesglose()
ActualizarD esglose()
ObtenerDesgloseD adoU E()
ObtenerIdD adoNodo()
ObtenerNodoDadoId()
ObtenerTablaLote()
ObtenerTablaNodo()
BLLTCaracter
BLLTPortal
ActualizarPortal()
EliminarPortal()
AdicionarPortal()
ObtenerIdD adoPortal()
ObtenerPoratlDadoId()
ObtenertablaPortal()
AdicionarC aracter()
EliminarCaracter()
ActualizarC aracter()
ObtenerIdDadoCaracter()
ObtenerCaracterDadoId()
ObtenerTablaCaracer()
ActualizarEpoca()
AdicionarEpoca()
EliminarEpoca()
ObtenerIdD adoEpoca()
ObtenerIdEpocaDadoIdEpocaUE()
ObtenerTablaEpoca()
ObtenertablaEpocaDadoEpocaUE()
ActualizarEpocaUE()
EliminarEpoc aU E()
AdicionarEpocaUE()
ObtenerEpoc aU ED adoEpoca()
ObtenerEpoc aU ED adoIDEpocaUE()
ObtenerIdEpocaUEDadoEpocaUE()
ObtenerTablaEpocaU E()
ActualizarEspecif ico()
EliminarEspecif ico()
AdicionarEspecif ico()
ObtenerEspecif icacionDadoId()
ObtenerEspecD adoMasEspec()
ObtnerIdEspecD adoEspecif icacion()
ObteneridD adoIdU so()
ObtenerTablaUsoEspecif ico()
ObtenerTablaEspecif icoDadoUso()
BLLTEstado_Contructiv o
ActualizarEdoConstructiv o()
EliminarEdoC onstructiv o()
ActualizarEdoConstructiv o()
ObtenerEdoD adoIdEdo()
ObtenerIdD adoEdo()
ObtenerTablaEdoCons()
Anexo 27. Paquete Lógico de los Datos.
BLLTipo_Planta
ActualizarTipoPlanta()
EliminarTipoPlanta()
AdicionarTipoPlanta()
ObtenerIdD adoPlanta()
ObtenerTipoPlantaDadoId()
ObtenerTablaTipoPlanta()
AdicionarU suario()
EliminarUsuario()
ObtenerIdR olDadoRol()
ObtenerRol()
ObtenerTablaRol()
ObtenerTablaUs uario()
Verif icarUsuario()
BLLTValor
BLLTTransf ormaciones
BLLUsoEspecif ico
ActualizarBarrio()
EliminarBarrio()
ActualizarBarrio()
ObtenerBarrioDadoIdBarrio()
ObtenerIdD adoBarrio()
ObtenerTablaBarrio()
BLLUsuario
BLLTEpocaUE
BLLTEpoca
BLLTBarrio
ActualizarTransf ()
EliminarTrans f ()
AdicionarTransf ()
ObtenerTrans f D adoID()
ObtenerIdD adoTransf orm()
ObtenerTablaTransf ()
ActualizarValor()
EliminarValor()
AdicionarValor()
ObtenerIdValorD adoValor()
ObtenerValorDadoIDValor()
ObtenerTablaValor()
BLLTMasEspecif ico
BLLTUso
AdicionarU so()
EliminarUso()
ActualizarU so()
ObtenerIdD adoUso()
ObtenerTablaUso()
ObtenerUsoD adoId()
ObtenerUsoD adoD adoMasEspecif ico()
CadenaFiltros
AdicionarF iltro()
ApFiltro()
AppFiltroAnd()
EliminarFiltro()
Filtrar()
FiltrarGeneral()
ActualizarMasEspecif ico()
EliminarMasEspecif ico()
AdicionarMasEspecif ico()
ObtenerEspecDadoIdMasEspe()
ObtenerIdD adoEspecif ()
ObtenerIdD adoIdEspeci()
ObtenerTablaMasEspec if ico()
BLLTipo_Edif icacion
ActualizarTipoEdif icacion()
EliminarTipoEdif icacion()
AdicionarTipoEdif icacion()
ObtenerIdD adoTipoEdif i()
ObtenerTipoD adoId()
ObtenerTablaTipoEdif icaciono()
BLLUnidad_Edif icatoria
ActualizarC ompatibilidad()
ActualizarU nidadEdif ()
EliminarUnidadEdif ()
AdicionarU nidadEdif ()
Area_total_construida()
Area_total_parcela()
Barrio()
CalcularPorciento()
Calle()
Caracter()
CategoriaA1()
CategoriaA2()
CategoriaA3()
CategoriaB1()
CategoriaB1a()
CategoriaB1b()
CategoriaB2()
CategoriaB2a()
CategoriaB2b()
CategoriaB3()
CategoriaB3a()
CategoriaB3b()
CategoriaC 1()
CategoriaC 2()
CategoriaC 3()
CategoriaA1()
CategoriaA2()
CategoriaA3()
DesU so()
Epoca()
Estado_Constructiv o()
GradoProtecc ion1()
GradoProtecc ion2()
GradoProtecc ion3()
GradoProtecc ion4()
Longitud_Fachada()
Modif icacionesAmpliacion()
Modif icacionesD iv ision()
Modif icacionesF ac hada()
Modif icacionesEstrac()
Nodo()
NroPlantas()
ObtenerTablaUE()
Ocupado()
Parcialm enteOcupado()
Patio()
PerteneceEjePrimerOrden()
PerteneceEjeSegundoOrden()
PerteneceNodoSegundoOrden()
PerteneceNodoPrimerOrden()
Portal()
Puntal()
Transf ormaciones()
Uso()
Valor()
Diagrama de clases. Paquete Interfaz de Usuario.
Diagrama de clases. Paquete Interfaz de Usuario.
FormaBarrio
FormaTransf ormaciones
FormaUsuario
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaTransf ormaciones_Load()
SetData()
ShowReportTransf ormaciones()
Verif icarRol()
buttonAceptar_Click()
buttonCancelar_Click()
GetData()
ShowReportTablaBarrio()
Verif icarRol()
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaAdministrar
FormaGradoProteccion
Conf : String
nombre : String
pass : String
rol : String
FormaGradoProteccion_Load()
ShowReportGradoProteccion()
comboBoxGrado_SelectedIdexChanged()
FormaAddUsuario_Load()
listView_SelectedIdexChanged()
MostrarFormaAddUsuario()
MostrarUsuario()
FormaEpocaUE
FormaEstado_Constructiv o
FormaPrincipal
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaEpocaUE_Load()
SetData()
ShowReportTablaEpocaUE()
Verif icarRol()
FormaEpocaLote
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaEpocaLote_Load()
SetData()
ShowReportTablaEpocaLote()
Anexo 28. Paquete Interfaz de Usuario.
nombre : String
pass : String
rol : String
FormaPrincipal_Load()
Main()
ShowWindows()
toolBar1_ButtonClick()
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaEpocaLote_Load()
SetData()
ShowReportTablaEpocaLote()
Verif icarRol()
FormaCaracter
FormaValor
FormaPrincipal
nombre : String
pass : String
rol : String
ShowReportTablaBarrio()
VerificarRol()
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaValor_Load()
SetData()
ShowReportTablaValor()
VerificarRol()
FormaPrincipal_Load()
Main()
ShowWindows()
toolBar1_ButtonClick()
FormaTipoEdificacion
FormaConeccion
FormaConexion_Load()
radioButtonUsuario_CheckedChanged()
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaTipoEdificacion_Load()
SetData()
ShowReportTablaTipoEdificacion()
VerificarRol()
FormaUE
compatibilidad : Boolean
EdoConst : Boolean
parcialmente : Boolean
sinuso : Boolean
FormaGradoproteccionGral
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaUE_Load()
SetData()
ShowReportTablaUE()
VerificarRol()
FormaTipoPlanta
FormaGradoProteccion_Load()
ShowReportGradoProteccion()
comboBoxGrado_SelectedIdexChanged()
FormaLote
MZGlobal : String
UEGlobal : String
FormaImagen
FormaImagen_Load()
SetDataFileName()
ShowImagen()
Anexo 28.1. Paquete Interfaz de Usuario.
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaLote_Load()
SetData()
ShowReportTablaLote()
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaTipoPlanta_Load()
SetData()
ShowReportTablaTipoPlanta()
VerificarRol()
FormaUso
FormaCalle
FormaPrincipal
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaUso_Load()
SetData()
ShowReportTablaUso()
VerificarRol()
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaCalle_Load()
SetData()
ShowReportTablaCalle()
VerificarRol()
nombre : String
pass : String
rol : String
FormaPrincipal_Load()
Main()
ShowWindows()
toolBar1_ButtonClick()
FormaConexiones
FormaUsoEspecifico
Cod_UsoGlobal : String
FormaConexiones_Load()
listBox_SelectedIndexChanged()
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaUsoEspecifico_Load()
SetData()
ShowReportTablaUsoEspecifico()
FormaAddUsuario
FormaAddUsuario_Load()
GetData()
LlenarComponentes()
FormaMasEspecifico
FormaPortal
UsoEspecificoGlobal : String
UsoGlobal : String
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaMasEspecifico_Load()
SetData()
ShowReportTablaMasEspecifico()
FormaCategoria
FormaCategoria_Load()
Anexo 28.2. Paquete Interfaz de Usuario.
buttonAceptar_Click()
buttonEliminar_Click()
buttonAdicionar_Click()
buttonEditar_Click()
buttonActualizar_Click()
FormaPortal_Load()
SetData()
ShowReportTablaPortal()
VerificarRol()
FormaConsultasLibres
buttonMostrar_Click()
FormaConsultasLibres_Load()
Diagrama Modelo de datos
Calle
Cod_calle : VARCHAR(3)
nombre : VARCHAR(50)
Eje : CHAR(1)
<<PK>> PK_Calle()
<<Non-Identifying >>
<<FK>> FK_Calle_TEje()
0..*
1
TEje
IdEje : CHAR(1)
Eje : VARCHAR(20)
<<PK>> PK_TEje()
TBarrio
IdBarrio : VARCHAR(2)
Barrio : VARCHAR(50)
<<PK>> PK_TBarrio()
TCaracter
Codig o_Caracter : VARCHAR(2)
Caracter : VARCHAR(50)
Lote
Nro_Manzana : VARCHAR(3)
Nro_Unidad_Edificatoria : VARCHAR(10)
Nro_Lote : VARCHAR(2)
Nro_casa : VARCHAR(10)
Cod_Postal : VARCHAR(10)
cod_calle : VARCHAR(3)
1
<<Non-Identifying >> P_Principal : BIT
Valor : VARCHAR(2)
Caracter : VARCHAR(2)
Estado_Constructivo : VARCHAR(2)
Transformaciones : VARCHAR(2)
0..*
Epoca : VARCHAR(2)
IdEpocaUE : VARCHAR(2)
Area_Lote : DECIMAL(9, 2)
Long itud_Fachada : DECIMAL(9, 2)
Nro_Planta : INT
Cod_Uso : VARCHAR(3)
<<Non-Identifying >> Cod_Uso_Especifico : VARCHAR(3)
Cod_Uso_UE : VARCHAR(2)
Portal : VARCHAR(2)
Area_Construida : DECIMAL(9, 2)
0..*
1
Puntal : DECIMAL(5, 2)
<<Non-Identifying >>Nodo : CHAR(1)
Modificaciones_Estructura : BIT
0..* Modificaciones_Fachada : BIT
Modificaciones_Ampliacion : BIT
1
Modificaciones_Division : BIT
patio : BIT
barrio : VARCHAR(2)
<<Non-Identifying >>
0..* <<PK>>
<<FK>>
<<FK>>
<<FK>>
1
<<FK>>
<<FK>>
TEstado_Cosntructivo
<<FK>>
Codig o_Estado_Contructivo : VARCHAR(2)
<<FK>>
Estado_Cosntructivo : VARCHAR(30)
<<FK>>
<<FK>>
<<PK>> PK_TEstado_Cosntructivo()
<<FK>>
0..*
<<FK>>
<<Non-Identifying >>
<<PK>> PK_Carácter()
PK_Lote()
FK_Lote_Unidad_Edificatoria()
FK_Lote_TPortal()
FK_Lote_TValor()
FK_Lote_TCaracter()
FK_Lote_TEpoca()
FK_Lote_TBarrio()
FK_Lote_TMasEspecifico()
FK_Lote_TNodo()
FK_Lote_Calle()
FK_Lote_TEstado_Cosntructiv
o()
<<Identifying >>
FK_Lote_TTransformaciones()
0..*
TEpoca
Codig o_Epoca : VARCHAR(2)
0..*
IdEpocaUE : VARCHAR(2)
Epoca : VARCHAR(50)
Desde : INT
Hasta : INT
<<Identifying >>
<<PK>> PK_TTransformacionesUE()
<<PK>> PK_TEpoca()
<<Non-Identify
ing >>
<<FK>>
FK_TEpoca_TEpocaUE()
1
0..*
TMasEspecifico
IDmasespecifico : VARCHAR(3)
IDespecificacion : VARCHAR(3)
0..*
<<Non-Identifying
>>
IDUso
: VARCHAR(2)
0..* 1
masespecificacion : VARCHAR(50)
area_q ue_ocupa : DECIMAL(18, 0)
<<PK>> PK_TMasEspecifico_1()
<<Uniq
ue>> IX_TMasEspecifico()
<<Non-Identifying
>>
<<FK>> FK_TMasEspecifico_UsoEspecifico()
0..*
1
TTransformaciones
Codig o_Transformaciones : VARCHAR(2)
Transformaciones : VARCHAR(50)
<<Non-Identifying >>
<<PK>> PK_TTransformaciones()
0..*
1
TValor
Codig o_Valor : VARCHAR(2)
Valor : VARCHAR(50)
0..*
<<PK>> PK_Valor()
<<Non-Identifying >>
1
1
1
TPortal
IdPortal : VARCHAR(2)
Portal : VARCHAR(30)
<<PK>> PK_Portal()
Tipo_Edificacion
IdTipo : VARCHAR(2)
Tipo : VARCHAR(50)
<<PK>> PK_Tipo_Edificacion()
Unidad_Edificatoria
Nro_Manzana : VARCHAR(3)
Nro_Unidad_Edificatoria : VARCHAR(10)
Tipo_de_Planta : VARCHAR(2)
Tipo_Edificacion : VARCHAR(2)
Acceso_Secundario : BIT
Compatibilidad : BIT
Calle : VARCHAR(3)
Valor : VARCHAR(2)
Caracter : VARCHAR(2)
Estado_Constructivo : VARCHAR(2)
Transformaciones : VARCHAR(2)
Epoca : VARCHAR(50)
<<Non-Identifying >>
Uso : CHAR(1)
Area_Total_de_Parcela : DECIMAL(9, 2)
Long itud_Fachada : DECIMAL(9, 2)
Nro_de_Planta : INT
0..*
1
Portal : VARCHAR(50)
Area_total_construida : DECIMAL(9, 2)
Puntal : DECIMAL(5, 2)
Nodo : VARCHAR(50)
Modificaciones_en_la_Estructura : BIT
Modificaciones_en_la_Fachada : BIT
Modificaciones_en_la_Ampliacion : BIT
Modificaciones_en_la_Division : BIT
Barrio : VARCHAR(50)
Patio : BIT
camino : NVARCHAR(50)
Idobjeto : INT
<<PK>> PK_Unidad Edificatoria.()
<<FK>> FK_Unidad_Edificatoria_Tipo_Edificacion()
<<FK>> FK_Unidad_Edificatoria_Tipo_de_Planta ()
Anexo 29. Modelo de Datos.
TEpocaUE
1
IdEpocaUE : VARCHAR(2)
EpocaUE : VARCHAR(50)
TNodo
IdNodo : CHAR(1)
Nodo : VARCHAR(20)
<<PK>> PK_TNodo()
<<Non-Identifying >>
Tipo_de_Planta
0..*
1
Codig o_de_la_Planta : VARCHAR(2)
Planta : VARCHAR(50)
<<PK>> PK_Planta U/E()
<<Identifying >>
UsoEspecifico
IDEspecifico : VARCHAR(3)
1
IDUso : VARCHAR(2)
Especificacion : VARCHAR(30)
0..*
<<Uniq ue>> IX_UsoEspecifico()
<<Identifying >>
<<PK>> PK_UsoEspecifico()
<<FK>> FK_UsoEspecifico_TUso()
TUso
1
Codig o_Uso : VARCHAR(2)
Uso : VARCHAR(50)
<<PK>> PK_Uso()
Diagrama de Clase Persistentes.
T_Lote
T_TNodo
Nodo : String = ' '
1
0..*
1
T_Calle
nombre : String = ' '
0..*
0..*
1
T_TEje
Eje : String = ' '
T_TValor
Nro_casa : String = ' '
Cod_Postal : String = ' '
P_Principal : Boolean = 0
Area_Lote : Double = 0
Longitud_Fachada : Double = 0
Nro_Planta : Integer = 0
Area_Construida : Double = 0
Puntal : Single = 0
Modificaciones_Estructura : Boolean = 0
Modificaciones_Fachada : Boolean = 0
Modificaciones_Ampliacion : Boolean = 0
Modificaciones_Division : Boolean = 0
patio : Boolean = 0
0..*
Valor : String = ' '
1
T_TTransformaciones
Transformaciones : String = ' '
0..*
1
0..*
0..*
0..*
1
T_TEstado_Cosntructivo
Estado_Cosntructivo : String = ' '
0..*
1
1
0..*
T_TPortal
Portal : String = ' '
0..*
0..*
T_TMasEspecifico
masespecificacion : String = ' '
area_que_ocupa : Long = 0
0..*
1
1
T_TCaracter
Caracter : String = ' '
T_TEpoca
1
Epoca : String = ' '
Desde : Integer = 0
Hasta : Integer = 0
0..*
1
T_TEpocaUE
EpocaUE : String = ' '
Anexo 30. Clases Persistentes.
T_TBarrio
1
T_Unidad_Edificatoria
Acceso_Secundario : Boolean = 0
Compatibilidad : Boolean = 0
Calle : String = ' '
Valor : String = ' '
Caracter : String = ' '
Estado_Constructivo : String = ' '
Transformaciones : String = ' '
Epoca : String = ' '
Uso : String = ' '
Area_Total_de_Parcela : Double = 0
Longitud_Fachada : Double = 0
Nro_de_Planta : Integer = 0
Portal : String = ' '
Area_total_construida : Double = 0
Puntal : Single = 0
Nodo : String = ' '
Modificaciones_en_la_Estructura : Boolean = 0
Modificaciones_en_la_Fachada : Boolean = 0
Modificaciones_en_la_Ampliacion : Boolean = 0
Modificaciones_en_la_Division : Boolean = 0
Barrio : String = ' '
Patio : Boolean = 0
camino : String = ' '
Idobjeto : Integer = 0
Barrio : String = 0
1
T_UsoEspecifico
Especificacion : String = ' '
0..*
1
T_Tipo_de_Planta
1
Planta : String = ' '
T_TUso
0..*
0..*
Uso : String = ' '
1
T_Tipo_Edificacion
Tipo : String = ' '
Diagrama de despliegue
Servidor de Base de Datos
Servidor de Base
de Datos con
SQL-SERVER
2000
TCP/IP(LAN)
Aplicación cliente
Impresora
Anexo 31. Diagrama de Despliegue.
Aplicacion Cliente
programada en la
plataforma .NET,
con C#.
Diagrama de componentes
DUAC.exe
<<ConfigFile>>
Conn.INI
Interfaces
Logica de Negocio
Acceso a datos
Common
PRepo
rts.dll
Anexo 32. Diagrama de Componentes.
Zona_Protec_#2
Diagrama de componentes. Paquete Interfaces.
<<Unit>>
FormaGrad
oproteccion
<<Unit>>
FormaGradop
roteccionGral
<<Unit>>
ForaCate
goria
<<Unit>>
FormaUE
.cs
<<Unit>>
FormaCone
xiones.cs
<<Unit>>
FormaUs
uario.cs
<<Unit>>
FormaLot
e.cs
<<Unit>>
FormaPrincipal.cs
<<Unit>>
FormaIm
agen.cs
<<Unit>>
FormaAdmi
nistrar.cs
<<Unit>>
FormaEstadoCo
nstructiv o.cs
<<Unit>>
FormaEpoc
aGral.cs
<<Unit>>
FormaPor
tal.cs
<<Unit>>
FormaBar
rio.cs
<<Unit>>
FormaEpo
caEsp.cs
Anexo 33. Paquete Interfaz de Usuario.
<<Unit>>
FormaTip
oEdif .cs
<<Unit>>
FormaPla
ntas.cs
<<Unit>>
FormaVal
or.cs
<<Unit>>
FormaCar
acter.cs
<<Unit>>
FormaUs
o.cs
<<Unit>>
FormaUs
oCat.cs
<<Unit>>
FormaCal
le.cs
<<Unit>>
FormaTransf or
maciones.cs
<<Unit>>
FormaConsu
ltasLibres.cs
<<Unit>>
FormaUsoE
specif ico.cs
Diagrama de componentes. Paquete de Acceso a Datos.
<<Unit>>
DALLote.
cs
<<Unit>>
DALTVal
or.cs
<<Unit>>
DALEpoc
a.cs
<<Unit>>
DALTipo_Edi
ficacion.cs
<<Unit>>
DALTMas
Es pecifico
<<Unit>>
DALUs u
ario.cs
Anexo 34. Paquete de Acceso a Datos.
<<Unit>>
DALTBar
rio.cs
<<Unit>>
DALTCar
acter.cs
<<Unit>>
DALTEs tado_C
ons tructivo.cs
<<Unit>>
Cons ultas
Libres.cs
<<Unit>>
DALEpoc
aUE.cs
<<Unit>>
DALTipo_de
_Planta.cs
<<Unit>>
DALTPor
tal.cs
<<Unit>>
DALTTrans for
maciones .cs
<<Unit>>
DALUs oEs
pecifico.cs
<<Unit>>
DALTUs
o.cs
<<Unit>>
DALUnidad_E
dificatoria.cs
<<Unit>>
DALCall
e.cs
Diagrama de componentes. Paquete Lógica del Negocio.
<<Unit>>
BLLUsu
ario.cs
<<Unit>>
BLLCadena
FiltrosUE.cs
<<Unit>>
BLLTMasEs
pecifico.cs
<<Unit>>
BLLTCar
acter.cs
<<Unit>>
BLLLote.
cs
<<Unit>>
BLLTBar
rio.cs
<<Unit>>
BLLTEpo
caUE.cs
<<Unit>>
BLLTTransfor
maciones.cs
<<Unit>>
BLLTUs
o.cs
<<Unit>>
BLLCalle
.cs
<<Unit>>
BLLTPort
al.cs
<<Unit>>
BLLUsoEs
pecifico.cs
<<Unit>>
BLLTVal
or.cs
<<Unit>>
BLLTEpo
ca.cs
<<Unit>>
BLLTipo_de
_Planta.cs
<<Unit>>
BLLUnidad_E
dificatoria.cs
Anexo 35. Paquete Lógico de los Datos.
<<Unit>>
BLLTipo_Edi
ficacion.cs
<<Unit>>
BLLTEstado_C
onstructivo.cs
Diagrama de componentes. Paquete Common.
<<Unit>>
UsuarioN
oExiste.cs
<<Unit>>
Conversion
StrInt.cs
<<Unit>>
Constant
es.cs
Anexo 36. Paquete Common.
<<Unit>>
ExisteUsuario.cs
<<Unit>>
ImagenNoEn
contrada.cs
<<Unit>>
Conexio
nInfo.cs
<<Unit>>
SQLStop
<<Unit>>
EliminarElementoR
eferenciado.cs.cs
<<Unit>>
Unidad_Edif
icatoria.cs