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