Post on 21-Mar-2020
RREESSUUMMEENN 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
1.1 INTRODUCCIÓN .............................................................................................................. 10 1.2 ¿POR QUÉ ES NECESARIO AUTOMATIZAR EL CENTRO HISTORICO DE CAMAGUEY? ...... 10 1.3 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
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
IINNTTRROODDUUCCCCIIÓÓNN
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 ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
7
FFUUNNDDAAMMEENNTTAACCIIOONN DDEELL TTEEMMAA
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
C a p í t u l o
1
Capítulo I Fundamentación del Tema DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
8
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
Capítulo I Fundamentación del Tema DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
9
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.
Capítulo I Fundamentación del Tema DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
10
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.
Capítulo I Fundamentación del Tema DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
11
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 SQL-
SERVER.
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.
Capítulo I Fundamentación del Tema DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
12
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
Capítulo I Fundamentación del Tema DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
13
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
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
14
TTEENNDDEENNCCIIAASS YY TTEECCNNOOLLOOGGÍÍAASS AACCTTUUAALLEESS AA
CCOONNSSIIDDEERRAARR..
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.
C a p í t u l o
2
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
15
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
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
16
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
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
17
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.
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
18
É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 Net-
Libraries.
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
19
• 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
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
20
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.
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
21
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
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
22
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,
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
23
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.
Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
24
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
25
DDEESSCCRRIIPPCCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN PPRROOPPUUEESSTTAA
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
C a p í t u l o
3
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
26
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
27
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
28
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
29
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:
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
30
Trabajadores Justificación Técnico especialista del Dpto.
de Planeamiento y Gestión.
Es la persona que se encarga de desarrollar las
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.
Control del Territorio.
Es el responsable de mantener actualizada la
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.
Inversionista
Obtener informacion sobre Unidad Edificatoria.Usuario General
Historiador RestauradorProponer Informacion para obtener Unidad
Edificatoria.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
31
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,
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
32
Diagrama de actividad. Obtener Información sobre Unidad Edificatoria.
Recibir Modelo resumen de UE
inicio
Solicitar modelo para Obtener Unidad Edificatoria
Llenar modelo de Solicitud de UE
Devolver Modelo de Solicitud de UE
Modelo de Solicitud de UE
[Lleno]
Visitar UE propuestas
Fin
Entregar Modelo para Obtener Unidad Edificatoria
Modelo de Solicitud de UE
[Vacio]
Revisar Modelo de Solicitud de UE
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]
Devoler Modelo resumen de UE
Técnico especialista del Dpto. de Control de Territorio : T...Usuario General : Usuario General
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
33
Diagrama de actividad. Proponer Información para obtener Unidad Edificatoria.
Modelo de UE propuesta[Unidades Edificatorias propuestas]
Solicitar modelo para obtener Unidad Edificatoria
Llenar modelo
Devolver modeo de Solicitud de UE
Modelo de solicitud de UE.
[Lleno]
Recibir Modelo de UE propuesta
Visitar Unidades Edificatorias propuestas
Entregar modelo de Solicitud de UE.
Modelo de solicitud de UE.
[vacio]
Revisar modelo
Buscar UE segun modelo
Emitir Modelo de Unidad Edificatoria propuestas
[Encontrada]
Entregar Modelo de UE propuesta
Emitir error
[No encontrada]
Asienta en el Libro de Control de Solicitudes.
Libro de Control de Solicitudes[Unidad Edificatoria, Inversionista]
Técnico especialista del Dpto. de Planeamiento y GestiónInv esrionista
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
34
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
35
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
36
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
37
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
38
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
39
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
40
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
41
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
42
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.
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.
Actores Descripción Técnico especialista del Dpto. de Planeamiento y Gestión.
Es la persona que se encarga de desarrollar las 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. Control del Territorio.
Es el responsable de mantener actualizada la 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.
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.)
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
43
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
44
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
45
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
46
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
especiales
El prototipo de este caso de uso esta ubicado en el prototipo de la
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
47
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)
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
48
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 el registro de las mismas,
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
49
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)
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
50
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
51
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
-
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
52
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á
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
53
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)
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
54
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
55
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
56
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 -
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
57
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
58
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
59
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
60
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
61
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
62
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
63
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
64
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)
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
65
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
66
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
67
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
especiales
Se necesita una velocidad grande para efectuar las consultas y
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.
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
68
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
Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
69
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
Capitulo IV Construcción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
70
CCOONNSSTTRRUUCCCCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN PPRROOPPUUEESSTTAA
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.
C a p í t u l o
4
Capitulo IV Construcción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
71
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.
Capitulo IV Construcción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
72
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.
Capitulo IV Construcción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
73
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
Capitulo IV Construcción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
74
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.
Capitulo IV Construcción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
75
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:
Capitulo IV Construcción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
76
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
Capitulo IV Construcción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
77
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.
Capitulo V Estudio de Factibilidad. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
78
EESSTTUUDDIIOO DDEE FFAACCTTIIBBIILLIIDDAADD
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.
C a p í t u l o
5
Capitulo V Estudio de Factibilidad. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
79
Nombre de la entrada externa
Cantidad de Ficheros
Cantidad de Elementos de datos
Clasificación (Simple, Media y compleja)
Autenticación. 1 2 Simple
Adicionar Unidad Edificatoria.
1 28 Medio
Eliminar unidad Edificatoria.
1 28 Medio
Adicionar Desgloses. 1 29 Medio Eliminar Desgloses 1 29 Medio Adicionar calles 1 2 Simple Eliminar calles. 1 2 Simple Adicionar valor 1 2 Simple Eliminar valor 1 2 Simple Adicionar carácter 1 2 Simple Eliminar carácter 1 2 Simple Adicionar barrio 1 2 Simple Eliminar barrio 1 2 Simple Adicionar transformaciones
1 2 Simple
Eliminar transformaciones 1 2 Simple Adicionar usos 3 8 Medio
Eliminar usos. 3 8 Medio
Adicionar épocas 2 6 Medio Eliminar épocas 2 6 Medio Adicionar estado constructivo.
1 2 Simple
Eliminar estado constructivo
1 2 Simple
Adicionar tipo de planta 1 2 Simple
Eliminar tipo de planta 1 2 Simple Adicionar tipo de edificación
1 2 Simple
Eliminar tipo de edificación
1 2 Simple
Tabla1. Entradas externas
Nombre de la salida externa
Cantidad de Ficheros
Cantidad de Elementos de datos
Clasificación (Simple, Media y compleja)
Listado de las Unidades Edificatorias.
1 2 Simple
Capitulo V Estudio de Factibilidad. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
80
Listado de los Desgloses. 1 3 Simple Listado de las calles. 1 2 Simple Listado de los estados constructivos.
1 2 Simple
Listado de la épocas de las unidades edificatorias.
1 2 Simple
Listado del portal. 1 2 Simple Listado del tipo de edificación.
1 2 Simple
Listado del tipo de planta. 1 2 Simple Listado de las transformaciones.
1 2 Simple
Listado del uso. 1 2 Simple Listado del valor. 1 2 Simple Listado del barrio. 1 2 Simple
Listado del carácter. 1 2 Simple Tabla 2. Salidas Externas Nombre de la petición Cantidad de
Ficheros Cantidad de Elementos de datos
Clasificación (Simple, Media y compleja)
Obtener Unidades Edificatorias dada una o varias variables.
1 2 Simple
Obtener Categorías predefinidas
1 2 Simple
Obtener grados de Protección.
1 3 Simple
Obtener Grados de Protección predefinidos.
1 2 Simple
Tabla 3. Peticiones Nombre del fichero interno Cantidad
de record Cantidad de Elementos de datos
Clasificación (Simple, Media y compleja)
Tabla Unidad Edificatoria 1 28 Medio Tabla Desgloses. 1 29 Medio Tabla Calles. 1 3 Simple Tabla Valor. 1 2 Simple Tabla Carácter. 1 2 Simple Tabla Época de las Unidades edificatorias.
1 2 Simple
Tabla Época de los Desgloses.
1 5 Simple
Tabla Barrios. 1 2 Simple Tabla Estado Constructivo. 1 2 Simple Tabla Portal. 1 2 Simple Tabla Tipo de Edificación. 1 2 Simple
Capitulo V Estudio de Factibilidad. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
81
Tabla Tipo de Planta. 1 2 Simple Tabla Transformaciones. 1 2 Simple Tabla Uso por Redes. 1 2 Simple Tabla Uso por Categorías. 1 5 Simple Tabla Uso unidad Edificatoria de Inf. Territorio.
1 3 Simple
Tabla eje 1 2 Simple Tabla nodo 1 2 Simple Tabla rol 1 2 Simple Tabla usuario 1 3 Simple Tabla 4. Ficheros Internos Elementos Simples Medios Complejos Subtotal de puntos de
función No X Peso No X Peso No X Peso Ficheros lógicos internos
18 7 2 10 0 15 146
Entradas externas 17 3 8 4 0 6 83 Salidas externas 13 4 0 5 0 7 52 Peticiones 4 3 0 4 0 6 12 Total 293
Tabla 5. Puntos de función desajustados. 5.2 Costos.
Características Valor Puntos de función desajustados 293 Lenguaje C# (80 %)
SQL (20%) Instrucciones fuentes por puntos de función (59)
(39) Instrucciones fuentes por lenguaje (miles de instrucciones) (14,694)
(1,7141)
Instrucciones fuentes (miles de instrucciones) 16,41 Tabla 6. Cantidad de Instrucciones Fuentes Factores Valor Justificación
PREC 4,96 Este sistema presenta un análisis y diseño que lo hace totalmente diferente.
Capitulo V Estudio de Factibilidad. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
82
FLEX 3,04 Existe cierta flexibilidad entre los analistas del sistema, los programadores y el cliente.
TEAM 3,29 Los miembros del equipo que desarrollan el software son altamente cooperativos, con poca experiencia en los compromisos.
RESL 4,24 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.
PMAT 6,24 El sistema presenta un nivel de madurez alto.
Tabla 7. Factores de escala
Cálculo de: Valor Justificación Esfuerzo 81,53 ΠEMi ≈ 1,69
E ≈ 1,13 ∑SFi = 21,77 PREC = 4,96 FLEX = 3,04 RESL = 4,24 TEAM = 3,29 PMAT = 6,24
Tiempo de desarrollo 15 meses PM ≈ 81,53 F ≈ 0,32
Cantidad de personas 5 Se necesita 5 personas para la realización del sistema.
Costo 91 721,25 C =CHM * PM CHM = 5 * 225 = 1125 PM ≈ 81,53
Salario medio 225 El salario mínimo es de 225 pesos.
RCPX 1,00 RELY = BASICO
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
Capitulo V Estudio de Factibilidad. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
83
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.
Capitulo V Estudio de Factibilidad. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
84
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.
Capitulo V Estudio de Factibilidad. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
85
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.
Conclusiones. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
86
CCoonncclluussiioonneess..
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.
Recomendaciones. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
87
RReeccoommeennddaacciioonneess..
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.
Referencias Bibliograficas. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
88
RReeffeerreenncciiaass BBiibblliiooggrrááffiiccaass..
[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.
Referencias Bibliograficas. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
89
[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
Bibliografía. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
90
BBiibblliiooggrraaffííaa..
• 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: yanesky@uci.cu - Ing. Yorlenis Dominguez Núñez. Departamento Gestion Hotelera. Escuela de Hoteleria Turismo Santa Lucia , Cuba e-mail: yorlenis@ehtstl.co.cu
Bibliografía. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
91
Glosario de Términos. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
92
GGlloossaarriioo ddee TTéérrmmiinnooss..
Termino. Concepto Accesos Acceso principal:
Ubicación del acceso principal del inmueble. Acceso secundario: Caracteriza al inmueble por la presencia de un acceso secundario
Áreas Área de parcela: Área de lote: Área construida: Área construidas en primer nivel. Área ocupada: Área total útil construida que posee el edificio.
Carácter 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.
Categoría tipológica
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)
Eje 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.
Estado constructivo
Ruinoso: Edificio en alto grado de deterioro, La cubierta esta seriamente afectada, Esta en peligro la estabilidad del mismo.
Glosario de Términos. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
93
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.
Fachada a plaza Caracteriza la relación directa del inmueble con una plaza.
Grado de protección
Indicadores de la categoría cultural de los inmuebles que integran un conjunto urbano de valor histórico-cultural.(I, II, III, IV)
indicadores 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
Lote 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.
Longitud de la fachada
Ancho de fachada del inmueble.
Manzana 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.
Nodo 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.
Parcela 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
Parcelación 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
Potencial de uso 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.
Puntal Altura mayor que alcanza el edificio en fachada.
Tiene galería Caracteriza el inmueble partir de la presencia o no de galería.
Tiene portal (publico o privado)
Caracteriza el inmueble a partir de la presencia o no del portal.
Tipo de planta Rectangular, cuadrada, U, C, L, trapezoidal
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.
Glosario de Términos. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯
94
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.
Anexo 1. Gestionar Unidad Edificatoria.
Anexo 2. Gestionar Calles.
Anexo 3. Gestionar Desgloses.
Anexo 4. Gestionar Valor. Anexo 5 Gestionar Transformaciones.
Anexo 6. Gestionar Estado Constructivo. 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 12. Gestionar Portal.
Anexo 13. Gestionar Tipo de Edificación. 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.
Tecnico General
Técnico especialista ...
(f rom Actors)
Reportes
Gestionar Busquedas
Mostrar UBIT por calles
Autenticar Usuario
Usuario
Administrar Sistema
Administrador de Sistema
(f rom Actors)
Técnico especialista ...
(f rom Actors)
Gestionar Variables.
Anexo 20. Diagrama de Caso de Uso del Sistema.
Diagrama de casos de uso del sistema. Paquete Búsquedas Libres.
Obtener Grado de Protección predefinidos.
Búsquedas Libres
Obtener Grado de Protección
Obtener Categorías Predefinidas.
Tecnico General
(f rom Use-Case Model)
Anexo 21. Paquete Búsqueda.
Anexo 22. Paquete Gestionar Variables.
Diagrama de casos de uso del sistema. Paquete Gestionar Variables.
Gestionar Desglose
(f rom Use-Case Model)Gestionar Unidad Edificatoria
(f rom Use-Case Model)
Gestionar Epoca de los Desgloses
Gestionar Uso
Gestionar Uso por Categorias.
Gestionar Uso por Redes
Gestionar Epoca de las Unidades Edificatorias
Gestionar Imagenes
(f rom Use-Case Model)
Gestionar Calles
Gestionar Valor
Gestionar Transformaciones
Gestionar Tipo Planta
Gestionar Estado Constructivo
Gestionar CarácterGestionar BarrioGestionar Portal
Gestionar Tipo Edificacion
Técnico especial ista ...
(from Actors)
Diagrama de casos de uso del sistema. Paquete Gestionar Reportes.
Anexo 23. Paquete Gestionar Reportes.
Generar Reporte
Generar reporte de Barrio.
Generar reporte de Carácter.
Generar reporte de Tipo de Edificacion.
Generar reporte de todas las Unidades Edificatorias.
Generar reporte de Transformaciones.
<<extend>>
<<extend>>
<<extend>><<extend>>
<<extend>>
Generar reporte de Unidad Edificatoria con categoría A1..A3
<<extend>>
Generar reporte de Unidad Edi ficatoria con categoría B1...B4.
<<extend>>
Generar reporte de Unidad Edi ficatoria con categoría C1...C3.
<<extend>>
Generar reporte de Unidad Edificatoria con categoría D1...D7.
<<extend>>
Generar reporte de Unidad Edificatoria con grado de protecc...
<<extend>>
Generar reporte de Unidad Edificatoria de 1, 2, 3, 4 plantas.
<<extend>>
Generar reporte de Unidad Edificatoria Estado Constructivo
<<extend>>
Generar reporte de Unidad Edificatoria modificadas.
<<extend>>
Generar reporte de Unidad Edificatoria según tipo pla...
<<extend>>
Generar reporte de Unidad Edi ficatoria según Usos
<<extend>>
Generar reporte de Unidad Edificatoria según Usos 1
Generar reporte de Unidad Edi ficatoria según Usos 2
<<extend>>
Generar reporte por época de las Unidad Edificatoria
<<extend>>
Generar reporte por época de los desgloses.
<<extend>>
Generar reporte Tipo Planta.Generar reportes de todos los
desgloses.
<<extend>>
Generar reportes de Unidad Edificatoria que consti tu...
<<extend>>
<<extend>>
Diagrama de clases.
Diagrama de clase BLL
Diagrama de clases Common
Diagrama de clases DAL
Diagrama de clases de Interfaz
Anexo 24. Relación entre paquetes.
Diagrama de clases
CTUsoUso : String
ConexionInfoBaseDatos : StringConnStr : Stringcontraseña : StringName : StringServidor : StringTipoConexion : BooleanUsuario : String
MiConexion()BuildConnSrt()
ConstantesBoolNull : BooleanCadNull : StringDecimalNull : DecimalFloatNull : FloatIntNull : Integer
CCallenombre : String
CTPortalPortal : String
CTEpocaUEEpoca : String
CTValorValor : String
CTEpocaEpoca : StringDesde : StringHasta : String
CTBarrioBarrio : String
CTipoPlantaPlanta : String
CTipoEdificacionTipo : String
CTTransformacionesTransformaciones : String
CTEstadoConstructivoEstado : String
CTMasEspecificoespecificacion : Stringarea : Double
CUsoEspecificoespecificacion : String
CLoteNroCasa : StringCod_Postal : StringP_Principal : BooleanAreaLote : DoubleLongitudFachada : DoubleNroPlantas : Integerpatio : Boolean
CUnidadEdificatoriaAcceso_Secundario : BooleanCompatibilidad : BooleanCalle : StringValor : StringCaracter : StringEstado : StringTransformaciones : StringEpoca : StringUso : String
Anexo 25. Paquete Common.
Anexo 26. Paquete de Acceso a Datos.
Diagrama de clases. Paquete de Acceso a Datos.
DALTValor
ActualizarValor()EliminarValor()AdicionarValor()ObtenerIdValorDadoValor()ObtenerValorDadoIDValor()ObtenerTablaValor()
DALCalle
ActualizarCalle()AdicionarCalle()BorrarCalle()ObtenerCalleDadoIdCalle()ObtenerEjeDadoId()ObtenerIdDadoCalle()ObtenerIdDadoEje()ObtenerIdDadoIdCalle()ObtenerTablaCalle()ObtenerTablaEje()
DALLote
AdicionarDesglose()EliminarDesglose()ActualizarDesglose()ObtenerDesgloseDadoUE()ObtenerIdDadoNodo()ObtenerNodoDadoId()ObtenerTablaLote()ObtenerTablaNodo()
DALTBarrio
ActualizarBarrio()EliminarBarrio()ActualizarBarrio()ObtenerBarrioDadoIdBarrio()ObtenerIdDadoBarrio()ObtenerTablaBarrio()
DALTCaracter
AdicionarCaracter()EliminarCaracter()ActualizarCaracter()ObtenerIdDadoCaracter()ObtenerCaracterDadoId()ObtenerTablaCaracer()
DALTTransformaciones
ActualizarTransf()EliminarTransf()AdicionarTransf()ObtenerTransfDadoID()ObtenerIdDadoTransform()ObtenerTablaTransf()
DALTUso
AdicionarUso()EliminarUso()ActualizarUso()ObtenerIdDadoUso()ObtenerTablaUso()ObtenerUsoDadoId()ObtenerUsoDadoDadoMasEspecifico()
DALTipo_Edificacion
ActualizarTipoEdificacion()EliminarTipoEdificacion()AdicionarTipoEdificacion()ObtenerIdDadoTipoEdifi()ObtenerTipoDadoId()ObtenerTablaTipoEdificaciono()
DALTEpocaUE
ActualizarEpocaUE()EliminarEpocaUE()AdicionarEpocaUE()ObtenerEpocaUEDadoEpoca()ObtenerEpocaUEDadoIDEpocaUE()ObtenerIdEpocaUEDadoEpocaUE()ObtenerTablaEpocaUE()
DALTMasEspecifico
ActualizarMasEspecifico()EliminarMasEspecifico()AdicionarMasEspecifico()ObtenerEspecDadoIdMasEspe()ObtenerIdDadoEspecif()ObtenerIdDadoIdEspeci()ObtenerTablaMasEspecifico()
DALUsuario
AdicionarUsuario()EliminarUsuario()ObtenerIdRolDadoRol()ObtenerRol()ObtenerTablaRol()ObtenerTablaUsuario()VerificarUsuario()
DALTipo_Planta
ActualizarTipoPlanta()EliminarTipoPlanta()AdicionarTipoPlanta()ObtenerIdDadoPlanta()ObtenerTipoPlantaDadoId()ObtenerTablaTipoPlanta()
DALTEpoca
ActualizarEpoca()AdicionarEpoca()EliminarEpoca()ObtenerIdDadoEpoca()ObtenerIdEpocaDadoIdEpocaUE()ObtenerTablaEpoca()ObtenertablaEpocaDadoEpocaUE()
DALTPortal
ActualizarPortal()EliminarPortal()AdicionarPortal()ObtenerIdDadoPortal()ObtenerPoratlDadoId()ObtenertablaPortal()
DALTEstadoConstructivo
ActualizarEdoConstructivo()EliminarEdoConstructivo()ActualizarEdoConstructivo()ObtenerEdoDadoIdEdo()ObtenerIdDadoEdo()ObtenerTablaEdoCons()
DALUsoEspecifico
ActualizarEspecifico()EliminarEspecifico()AdicionarEspecifico()ObtenerEspecificacionDadoId()ObtenerEspecDadoMasEspec()ObtnerIdEspecDadoEspecificacion()ObteneridDadoIdUso()ObtenerTablaUsoEspecifico()ObtenerTablaEspecificoDadoUso()
DALUnidad_Edificatoria
ActualizarCompatibilidad()ActualizarUnidadEdif()EliminarUnidadEdif()AdicionarUnidadEdif()Area_total_construida()Area_total_parcela()Barrio()Calle()Caracter()CategoriaA1()CategoriaA2()CategoriaA3()CategoriaB1()CategoriaB1a()CategoriaB1b()CategoriaB2()CategoriaB2a()CategoriaB2b()CategoriaB3()CategoriaB3a()CategoriaB3b()CategoriaC1()CategoriaC2()CategoriaC3()CategoriaA1()CategoriaA2()CategoriaA3()Epoca()Estado_Constructivo()GradoProteccion1()GradoProteccion2()GradoProteccion3()GradoProteccion4()Longitud_Fachada()ModificacionesAmpliacion()ModificacionesDivision()ModificacionesFachada()ModificacionesEstrac()Nodo()NroPlantas()ObtenerTablaUE()Patio()Portal()Puntal()Transformaciones()Uso()Valor()
Diagrama de clases. Paquete Lógico de los Datos. .
Anexo 27. Paquete Lógico de los Datos.
BLLCalle
ActualizarCalle()AdicionarCalle()BorrarCalle()ObtenerCalleDadoIdCalle()ObtenerEjeDadoId()ObtenerIdDadoCalle()ObtenerIdDadoEje()ObtenerIdDadoIdCalle()ObtenerTablaCalle()ObtenerTablaEje()
BLLLote
AdicionarDesglose()EliminarDesglose()ActualizarDesglose()ObtenerDesgloseDadoUE()ObtenerIdDadoNodo()ObtenerNodoDadoId()ObtenerTablaLote()ObtenerTablaNodo()
BLLTBarrio
ActualizarBarrio()EliminarBarrio()ActualizarBarrio()ObtenerBarrioDadoIdBarrio()ObtenerIdDadoBarrio()ObtenerTablaBarrio()
BLLTCaracter
AdicionarCaracter()EliminarCaracter()ActualizarCaracter()ObtenerIdDadoCaracter()ObtenerCaracterDadoId()ObtenerTablaCaracer()
BLLTEpoca
ActualizarEpoca()AdicionarEpoca()EliminarEpoca()ObtenerIdDadoEpoca()ObtenerIdEpocaDadoIdEpocaUE()ObtenerTablaEpoca()ObtenertablaEpocaDadoEpocaUE()
BLLTEpocaUE
ActualizarEpocaUE()EliminarEpocaUE()AdicionarEpocaUE()ObtenerEpocaUEDadoEpoca()ObtenerEpocaUEDadoIDEpocaUE()ObtenerIdEpocaUEDadoEpocaUE()ObtenerTablaEpocaUE()
BLLTEstado_Contructiv o
ActualizarEdoConstructiv o()EliminarEdoConstructiv o()ActualizarEdoConstructiv o()ObtenerEdoDadoIdEdo()ObtenerIdDadoEdo()ObtenerTablaEdoCons()
BLLTipo_Planta
ActualizarTipoPlanta()EliminarTipoPlanta()AdicionarTipoPlanta()ObtenerIdDadoPlanta()ObtenerTipoPlantaDadoId()ObtenerTablaTipoPlanta()
BLLTipo_Edif icacion
ActualizarTipoEdif icacion()EliminarTipoEdif icacion()AdicionarTipoEdif icacion()ObtenerIdDadoTipoEdif i()ObtenerTipoDadoId()ObtenerTablaTipoEdif icaciono()
BLLTMasEspecif ico
ActualizarMasEspecif ico()EliminarMasEspecif ico()AdicionarMasEspecif ico()ObtenerEspecDadoIdMasEspe()ObtenerIdDadoEspecif ()ObtenerIdDadoIdEspeci()ObtenerTablaMasEspecif ico()
BLLTPortal
ActualizarPortal()EliminarPortal()AdicionarPortal()ObtenerIdDadoPortal()ObtenerPoratlDadoId()ObtenertablaPortal()
BLLTTransf ormaciones
ActualizarTransf ()EliminarTransf ()AdicionarTransf ()ObtenerTransf DadoID()ObtenerIdDadoTransf orm()ObtenerTablaTransf ()
BLLTValor
ActualizarValor()EliminarValor()AdicionarValor()ObtenerIdValorDadoValor()ObtenerValorDadoIDValor()ObtenerTablaValor()
BLLUnidad_Edif icatoria
ActualizarCompatibilidad()ActualizarUnidadEdif ()EliminarUnidadEdif ()AdicionarUnidadEdif ()Area_total_construida()Area_total_parcela()Barrio()CalcularPorciento()Calle()Caracter()CategoriaA1()CategoriaA2()CategoriaA3()CategoriaB1()CategoriaB1a()CategoriaB1b()CategoriaB2()CategoriaB2a()CategoriaB2b()CategoriaB3()CategoriaB3a()CategoriaB3b()CategoriaC1()CategoriaC2()CategoriaC3()CategoriaA1()CategoriaA2()CategoriaA3()DesUso()Epoca()Estado_Constructiv o()GradoProteccion1()GradoProteccion2()GradoProteccion3()GradoProteccion4()Longitud_Fachada()Modif icacionesAmpliacion()Modif icacionesDiv ision()Modif icacionesFachada()Modif icacionesEstrac()Nodo()NroPlantas()ObtenerTablaUE()Ocupado()ParcialmenteOcupado()Patio()PerteneceEjePrimerOrden()PerteneceEjeSegundoOrden()PerteneceNodoSegundoOrden()PerteneceNodoPrimerOrden()Portal()Puntal()Transf ormaciones()Uso()Valor()
BLLTUso
AdicionarUso()EliminarUso()ActualizarUso()ObtenerIdDadoUso()ObtenerTablaUso()ObtenerUsoDadoId()ObtenerUsoDadoDadoMasEspecif ico()
BLLUsoEspecif ico
ActualizarEspecif ico()EliminarEspecif ico()AdicionarEspecif ico()ObtenerEspecif icacionDadoId()ObtenerEspecDadoMasEspec()ObtnerIdEspecDadoEspecif icacion()ObteneridDadoIdUso()ObtenerTablaUsoEspecif ico()ObtenerTablaEspecif icoDadoUso()
BLLUsuario
AdicionarUsuario()EliminarUsuario()ObtenerIdRolDadoRol()ObtenerRol()ObtenerTablaRol()ObtenerTablaUsuario()Verif icarUsuario()
CadenaFiltros
AdicionarFiltro()ApFiltro()AppFiltroAnd()EliminarFiltro()Filtrar()FiltrarGeneral()
Diagrama de clases. Paquete Interfaz de Usuario.
Anexo 28. Paquete Interfaz de Usuario.
FormaAdministrarConf : Stringnombre : Stringpass : Stringrol : String
FormaAddUsuario_Load()listView_SelectedIdexChanged()MostrarFormaAddUsuario()MostrarUsuario()
FormaUsuario
buttonAceptar_Click()buttonCancelar_Click()GetData()
FormaGradoProteccion
FormaGradoProteccion_Load()ShowReportGradoProteccion()comboBoxGrado_SelectedIdexChanged()
FormaEstado_Constructiv o
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaEpocaLote_Load()SetData()ShowReportTablaEpocaLote()Verif icarRol()
FormaBarrio
ShowReportTablaBarrio()Verif icarRol()buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()
FormaTransf ormaciones
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaTransf ormaciones_Load()SetData()ShowReportTransf ormaciones()Verif icarRol()
FormaEpocaUE
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()
FormaPrincipalnombre : Stringpass : Stringrol : String
FormaPrincipal_Load()Main()ShowWindows()toolBar1_ButtonClick()
Diagrama de clases. Paquete Interfaz de Usuario.
Anexo 28.1. Paquete Interfaz de Usuario.
FormaCaracter
ShowReportTablaBarrio()VerificarRol()buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()
FormaConeccion
FormaConexion_Load()radioButtonUsuario_CheckedChanged()
FormaValor
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaValor_Load()SetData()ShowReportTablaValor()VerificarRol()
FormaTipoEdificacion
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaTipoEdificacion_Load()SetData()ShowReportTablaTipoEdificacion()VerificarRol()
FormaTipoPlanta
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaTipoPlanta_Load()SetData()ShowReportTablaTipoPlanta()VerificarRol()
FormaPrincipalnombre : Stringpass : Stringrol : String
FormaPrincipal_Load()Main()ShowWindows()toolBar1_ButtonClick()
FormaGradoproteccionGral
FormaGradoProteccion_Load()ShowReportGradoProteccion()comboBoxGrado_SelectedIdexChanged()
FormaLoteMZGlobal : StringUEGlobal : String
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaLote_Load()SetData()ShowReportTablaLote()
FormaUEcompatibilidad : BooleanEdoConst : Booleanparcialmente : Booleansinuso : Boolean
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaUE_Load()SetData()ShowReportTablaUE()VerificarRol()
FormaImagen
FormaImagen_Load()SetDataFileName()ShowImagen()
FormaPrincipalnombre : Stringpass : Stringrol : String
FormaPrincipal_Load()Main()ShowWindows()toolBar1_ButtonClick()
FormaUsoEspecificoCod_UsoGlobal : String
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaUsoEspecifico_Load()SetData()ShowReportTablaUsoEspecifico()
FormaUso
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaUso_Load()SetData()ShowReportTablaUso()VerificarRol()
FormaMasEspecificoUsoEspecificoGlobal : StringUsoGlobal : String
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaMasEspecifico_Load()SetData()ShowReportTablaMasEspecifico()
FormaCategoria
FormaCategoria_Load()
FormaPortal
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaPortal_Load()SetData()ShowReportTablaPortal()VerificarRol()
FormaCalle
buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaCalle_Load()SetData()ShowReportTablaCalle()VerificarRol()
FormaConexiones
FormaConexiones_Load()listBox_SelectedIndexChanged()
FormaAddUsuario
FormaAddUsuario_Load()GetData()LlenarComponentes()
FormaConsultasLibres
buttonMostrar_Click()FormaConsultasLibres_Load()
Anexo 28.2. Paquete Interfaz de Usuario.
Diagrama Modelo de datos
Anexo 29. Modelo de Datos.
LoteNro_Manzana : VARCHAR(3)Nro_Unidad_Edificatoria : VARCHAR(10)Nro_Lote : VARCHAR(2)Nro_casa : VARCHAR(10)Cod_Postal : VARCHAR(10)cod_calle : VARCHAR(3)P_Principal : BITValor : VARCHAR(2)Caracter : VARCHAR(2)Estado_Constructivo : VARCHAR(2)Transformaciones : VARCHAR(2)Epoca : VARCHAR(2)IdEpocaUE : VARCHAR(2)Area_Lote : DECIMAL(9, 2)Longitud_Fachada : DECIMAL(9, 2)Nro_Planta : INTCod_Uso : VARCHAR(3)Cod_Uso_Especifico : VARCHAR(3)Cod_Uso_UE : VARCHAR(2)Portal : VARCHAR(2)Area_Construida : DECIMAL(9, 2)Puntal : DECIMAL(5, 2)Nodo : CHAR(1)Modificaciones_Estructura : BITModificaciones_Fachada : BITModificaciones_Ampliacion : BITModificaciones_Division : BITpatio : BITbarrio : VARCHAR(2)
<<PK>> PK_Lote()<<FK>> FK_Lote_Unidad_Edificatoria()<<FK>> FK_Lote_TPortal()<<FK>> FK_Lote_TValor()<<FK>> FK_Lote_TCaracter()<<FK>> FK_Lote_TEpoca()<<FK>> FK_Lote_TBarrio()<<FK>> FK_Lote_TMasEspecifico()<<FK>> FK_Lote_TNodo()<<FK>> FK_Lote_Calle()<<FK>> FK_Lote_TEstado_Cosntructivo()<<FK>> FK_Lote_TTransformaciones()
TEjeIdEje : CHAR(1)Eje : VARCHAR(20)
<<PK>> PK_TEje()
TEpocaUEIdEpocaUE : VARCHAR(2)EpocaUE : VARCHAR(50)
<<PK>> PK_TTransformacionesUE()
Tipo_EdificacionIdTipo : VARCHAR(2)Tipo : VARCHAR(50)
<<PK>> PK_Tipo_Edificacion()
Tipo_de_Planta Codigo_de_la_Planta : VARCHAR(2)Planta : VARCHAR(50)
<<PK>> PK_Planta U/E()
CalleCod_calle : VARCHAR(3)nombre : VARCHAR(50)Eje : CHAR(1)
<<PK>> PK_Calle()<<FK>> FK_Calle_TEje()
10..* 10..*
<<Non-Identifying>>
TBarrioIdBarrio : VARCHAR(2)Barrio : VARCHAR(50)
<<PK>> PK_TBarrio()
TCaracterCodigo_Caracter : VARCHAR(2)Caracter : VARCHAR(50)
<<PK>> PK_Carácter()
TEpocaCodigo_Epoca : VARCHAR(2)IdEpocaUE : VARCHAR(2)Epoca : VARCHAR(50)Desde : INTHasta : INT
<<PK>> PK_TEpoca()<<FK>> FK_TEpoca_TEpocaUE()
10..* 10..*<<Identifying>>
TEstado_CosntructivoCodigo_Estado_Contructivo : VARCHAR(2)Estado_Cosntructivo : VARCHAR(30)
<<PK>> PK_TEstado_Cosntructivo()
TNodoIdNodo : CHAR(1)Nodo : VARCHAR(20)
<<PK>> PK_TNodo()
TPortalIdPortal : VARCHAR(2)Portal : VARCHAR(30)
<<PK>> PK_Portal()
TTransformacionesCodigo_Transformaciones : VARCHAR(2)Transformaciones : VARCHAR(50)
<<PK>> PK_TTransformaciones()
TValorCodigo_Valor : VARCHAR(2)Valor : VARCHAR(50)
<<PK>> PK_Valor()
Unidad_EdificatoriaNro_Manzana : VARCHAR(3)Nro_Unidad_Edificatoria : VARCHAR(10)Tipo_de_Planta : VARCHAR(2)Tipo_Edificacion : VARCHAR(2)Acceso_Secundario : BITCompatibilidad : BITCalle : VARCHAR(3)Valor : VARCHAR(2)Caracter : VARCHAR(2)Estado_Constructivo : VARCHAR(2)Transformaciones : VARCHAR(2)Epoca : VARCHAR(50)Uso : CHAR(1)Area_Total_de_Parcela : DECIMAL(9, 2)Longitud_Fachada : DECIMAL(9, 2)Nro_de_Planta : INTPortal : VARCHAR(50)Area_total_construida : DECIMAL(9, 2)Puntal : DECIMAL(5, 2)Nodo : VARCHAR(50)Modificaciones_en_la_Estructura : BITModificaciones_en_la_Fachada : BITModificaciones_en_la_Ampliacion : BITModificaciones_en_la_Division : BITBarrio : VARCHAR(50)Patio : BITcamino : NVARCHAR(50)Idobjeto : INT
<<PK>> PK_Unidad Edificatoria.()<<FK>> FK_Unidad_Edificatoria_Tipo_Edificacion()<<FK>> FK_Unidad_Edificatoria_Tipo_de_Planta ()
1 0..*1 0..*
<<Non-Identifying>>10..* 10..*
<<Non-Identifying>>
TUsoCodigo_Uso : VARCHAR(2)Uso : VARCHAR(50)
<<PK>> PK_Uso()
1
0..*
1
0..*
<<Non-Identifying>>
1 0..*1 0..*
<<Non-Identifying>>
1
0..*
1
0..*
<<Non-Identifying>>
1
0..*
1
0..*
<<Non-Identifying>>
1
0..*
1
0..*<<Non-Identifying>>
1
0..*
1
0..*
<<Non-Identifying>>
1
0..*
1
0..*<<Non-Identifying>>
10..*
10..*
<<Non-Identifying>>
10..* 10..*
<<Non-Identifying>>
10..*1
0..*
<<Identifying>>
UsoEspecificoIDEspecifico : VARCHAR(3)IDUso : VARCHAR(2)Especificacion : VARCHAR(30)
<<Unique>> IX_UsoEspecifico()<<PK>> PK_UsoEspecifico()<<FK>> FK_UsoEspecifico_TUso()
1
0..*
1
0..*
<<Identifying>>
TMasEspecificoIDmasespecifico : VARCHAR(3)IDespecificacion : VARCHAR(3)IDUso : VARCHAR(2)masespecificacion : VARCHAR(50)area_que_ocupa : DECIMAL(18, 0)
<<PK>> PK_TMasEspecifico_1()<<Unique>> IX_TMasEspecifico()<<FK>> FK_TMasEspecifico_UsoEspecifico()
10..* 10..*<<Non-Identifying>> 10..* 10..*
<<Identifying>>
Diagrama de Clase Persistentes.
T_Unidad_EdificatoriaAcceso_Secundario : Boolean = 0Compatibilidad : Boolean = 0Calle : String = ' 'Valor : String = ' 'Caracter : String = ' 'Estado_Constructivo : String = ' 'Transformaciones : String = ' 'Epoca : String = ' 'Uso : String = ' 'Area_Total_de_Parcela : Double = 0Longitud_Fachada : Double = 0Nro_de_Planta : Integer = 0Portal : String = ' 'Area_total_construida : Double = 0Puntal : Single = 0Nodo : String = ' 'Modificaciones_en_la_Estructura : Boolean = 0Modificaciones_en_la_Fachada : Boolean = 0Modificaciones_en_la_Ampliacion : Boolean = 0Modificaciones_en_la_Division : Boolean = 0Barrio : String = ' 'Patio : Boolean = 0camino : String = ' 'Idobjeto : Integer = 0
T_TEjeEje : String = ' '
T_TEpocaUEEpocaUE : String = ' '
T_Tipo_EdificacionTipo : String = ' '
T_Tipo_de_Planta Planta : String = ' '
T_Callenombre : String = ' '
1
0..*
1
0..*
T_TBarrioBarrio : String = 0
T_TCaracterCaracter : String = ' '
T_TEpocaEpoca : String = ' 'Desde : Integer = 0Hasta : Integer = 0
1
0..*
1
0..*
T_TEstado_CosntructivoEstado_Cosntructivo : String = ' '
T_TNodoNodo : String = ' '
T_TPortalPortal : String = ' '
T_TTransformacionesTransformaciones : String = ' '
T_TValorValor : String = ' '
10..* 10..*
10..*
10..*
T_TUsoUso : String = ' '
T_LoteNro_casa : String = ' 'Cod_Postal : String = ' 'P_Principal : Boolean = 0Area_Lote : Double = 0Longitud_Fachada : Double = 0Nro_Planta : Integer = 0Area_Construida : Double = 0Puntal : Single = 0Modificaciones_Estructura : Boolean = 0Modificaciones_Fachada : Boolean = 0Modificaciones_Ampliacion : Boolean = 0Modificaciones_Division : Boolean = 0patio : Boolean = 0
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
10..*
10..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
1
0..*
T_UsoEspecificoEspecificacion : String = ' '
1
0..*
1
0..*
T_TMasEspecificomasespecificacion : String = ' 'area_que_ocupa : Long = 0
1
0..*
1
0..*
1
0..*
1
0..*
Anexo 30. Clases Persistentes.
Diagrama de despliegue
Servidor de Base de Datos
ImpresoraAplicación cliente
Servidor de Base de Datos con SQL-SERVER 2000
Aplicacion Clienteprogramada en la plataforma .NET, con C#.
TCP/IP(LAN)
Anexo 31. Diagrama de Despliegue.
Diagrama de componentes
DUAC.exe
Acceso a datos
Zona_Protec_#2
Logica de NegocioInterfaces
Common
Conn.INI<<ConfigFile>>
PReports.dll
Anexo 32. Diagrama de Componentes.
Diagrama de componentes. Paquete Interfaces.
FormaPrincipal.cs<<Unit>>
FormaConexiones.cs
<<Unit>>
FormaUsuario.cs
<<Unit>>
FormaBarrio.cs
<<Unit>>
FormaCaracter.cs
<<Unit>>FormaCalle.cs
<<Unit>>
FormaEstadoConstructiv o.cs
<<Unit>>FormaPortal.cs
<<Unit>>FormaTipoEdif .cs
<<Unit>>FormaPlantas.cs
<<Unit>>FormaTransf ormaciones.cs
<<Unit>>
FormaLote.cs
<<Unit>>
FormaUso.cs
<<Unit>>FormaValor.cs
<<Unit>>
FormaUsoCat.cs
<<Unit>>FormaUsoEspecif ico.cs
<<Unit>>
FormaImagen.cs
<<Unit>>
FormaAdministrar.cs
<<Unit>>
FormaEpocaEsp.cs
<<Unit>>
FormaEpocaGral.cs
<<Unit>>FormaConsultasLibres.cs
<<Unit>>
FormaUE.cs
<<Unit>>FormaGradoproteccion
<<Unit>>FormaGradoproteccionGral
<<Unit>>ForaCategoria
<<Unit>>
Anexo 33. Paquete Interfaz de Usuario.
Diagrama de componentes. Paquete de Acceso a Datos.
DALUsoEspecifico.cs
<<Unit>>
DALTValor.cs
<<Unit>>DALTCaracter.cs
<<Unit>>
DALEpoca.cs
<<Unit>>
DALEpocaUE.cs
<<Unit>>
DALTEstado_Constructivo.cs
<<Unit>>
ConsultasLibres.cs
<<Unit>>DALLote.cs
<<Unit>>DALTBarrio.cs
<<Unit>>
DALTipo_de_Planta.cs
<<Unit>>
DALTipo_Edificacion.cs
<<Unit>>
DALTUso.cs
<<Unit>>
DALTMasEspecifico
<<Unit>>
DALTPortal.cs
<<Unit>>DALTTransformaciones.cs
<<Unit>>
DALUnidad_Edificatoria.cs
<<Unit>>DALUsuario.cs
<<Unit>>DALCalle.cs
<<Unit>>
Anexo 34. Paquete de Acceso a Datos.
Diagrama de componentes. Paquete Lógica del Negocio.
BLLTPortal.cs
<<Unit>>
BLLCadenaFiltrosUE.cs
<<Unit>>
BLLCalle.cs
<<Unit>>
BLLLote.cs
<<Unit>>
BLLTBarrio.cs
<<Unit>>
BLLTCaracter.cs
<<Unit>>BLLTEpoca.cs
<<Unit>>
BLLTEpocaUE.cs
<<Unit>>
BLLTEstado_Constructivo.cs
<<Unit>>
BLLTipo_de_Planta.cs
<<Unit>>
BLLTipo_Edificacion.cs
<<Unit>>
BLLTMasEspecifico.cs
<<Unit>>
BLLTTransformaciones.cs
<<Unit>>
BLLTUso.cs
<<Unit>>
BLLTValor.cs
<<Unit>>
BLLUnidad_Edificatoria.cs
<<Unit>>
BLLUsoEspecifico.cs
<<Unit>>
BLLUsuario.cs
<<Unit>>
Anexo 35. Paquete Lógico de los Datos.
Anexo 36. Paquete Common.
Diagrama de componentes. Paquete Common.
UsuarioNoExiste.cs
<<Unit>>ExisteUsuario.cs<<Unit>>
EliminarElementoReferenciado.cs.cs
<<Unit>>
SQLStop<<Unit>>
ConversionStrInt.cs
<<Unit>>ImagenNoEncontrada.cs
<<Unit>>
ConexionInfo.cs
<<Unit>>Constantes.cs
<<Unit>> Unidad_Edificatoria.cs
<<Unit>>