Diagnostico urbano arquitectonico de CiuddadProyecto Urbano Arquitectónico VI, el que se vincula específicamente con los temas de la conservación y restauración. La creación de

RREESSUUMMEENN Automatización de los indicadores y variables patrimoniales, arquitectónicas y urbanas

para el manejo de las potencialidades del cambio de uso, restauración, conservación y

posibilidades de inversión en los inmuebles del Centro histórico de Camagüey.

Para la labor de refuncionalización de los centros histórico resulta necesario conocer el

potencial de cambio de uso con que cuenta en función de restablecer las estructuras

socioeconómicas devaluadas ante las exigencias contemporáneas para establecer una

estrategia que lejos de devaluar el centro histórico como Monumento Nacional, afiance

sus peculiaridades.

La creación de un sistema de indicadores y variables que sirva de estrategia al plan de

manejo del potencial de uso en los centros históricos exige de la interrelación de

indicadores patrimoniales arquitectónicos y urbanos que permitan la conservación del

centro por sus valores como conjunto urbano y no atendiendo a los monumentos

arquitectónicos.

Este software es de interés para todas aquellas entidades cuyo objeto se relaciona con

el planeamiento, control y gestión en las áreas de interés patrimonial, además de

permitirnos la proyección sobre bases reales en los análisis de la asignatura de

Proyecto Urbano Arquitectónico VI, el que se vincula específicamente con los temas de

la conservación y restauración. La creación de este instrumento, es de incuestionable

valor permitiéndonos la elaboración de una estrategia correcta en estas áreas.

En la actualidad no se cuenta con ningún Software que realice esta labor por lo que la

confección de este será de mucha ayuda para tratar las temáticas anteriormente dichas.

Con la realización de este software se podrá definir un sistema de indicadores y

variables patrimoniales y a partir de estos valorar la potencialidad de cambio de uso de

las edificaciones del Centro Histórico de la Ciudad de Camagüey

FUNDAMENTACION DEL TEMA .......................................................................................... 10

1.1 INTRODUCCIÓN .............................................................................................................. 10 1.2 ¿POR QUÉ ES NECESARIO AUTOMATIZAR EL CENTRO HISTORICO DE CAMAGUEY? ...... 10 1.3 SITUACION PROBLEMICA Y PROBLEMA ARESOLVER. ......................................................... 11 1.4 SOLUCIONES EXISTENTES. ...................................................................................................... 12 1.5 DESCRIPCIÓN DE LOS CONCEPTOS ASOCIADOS A LA SOLUCIÓN DEL PROBLEMA. ......... 13 1.6 TECNOLOGÍAS Y REFERENCIAS BIBLIOGRÁFICAS. ......................................................... 14 1.7 FUNDAMENTACIÓN DE LOS OBJETIVOS QUE SE PROPONE EL TRABAJO. ........................ 14

1.7.1 Objetivos generales ............................................................................................................... 14 1.7.2 Objetivos específicos ................................................................................................. 15 1.7.3 Objetivos específicos del sistema. ............................................................................. 12

1.8 APORTES PRÁCTICOS ESPERADOS DEL TRABAJO. .......................................................... 12 1.9 CONCLUSIONES. ............................................................................................................. 13

TENDENCIAS Y TECNOLOGÍAS ACTUALES A CONSIDERAR .................................... 14

2.1 INTRODUCCIÓN. ................................................................................................................... 14 2.2 LENGUAJE VISUAL C#.NET. ................................................................................................ 15 2.3 MICROSOFT SQL SERVER COMO GESTOR DE BASES DE DATOS. ......................................... 20 2.4 METODOLOGÍA RUP, LENGUAJE UML. ............................................................................... 23 2.5 CONCLUSIONES. ................................................................................................................... 24

DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA ............................................................... 28

3.1 INTRODUCCIÓN. ................................................................................................................... 28 3.2 ESTADO ACTUAL DEL NEGOCIO. .......................................................................................... 29 3.3 MODELO DEL NEGOCIO. ....................................................................................................... 30

3.3.1 Reglas del negocio. ....................................................................................................... 31 3.3.2 Modelo de casos de usos del negocio. .......................................................................... 32

3.4 REQUISITOS FUNCIONALES. ................................................................................................. 34 3.5 REQUISITOS NO FUNCIONALES. ............................................................................................ 40 3.6 DESCRIPCIÓN DEL SISTEMA PROPUESTO. ............................................................................. 43

3.6.1 Concepción General del Sistema .................................................................................. 43 3.7 MODELO CASO DE USO DEL SISTEMA. ................................................................................ 44

3.7.1Los actores del sistema. ................................................................................................. 42 3.7.2 Los casos de usos del sistema. ...................................................................................... 42 3.7.3 Descripción de los casos de usos del sistema. .............................................................. 44

3.8 DIAGRAMA DE CASOS DE USOS DEL SISTEMA. ..................................................................... 72 3.9 CONCLUSIONES. ................................................................................................................... 72

CONSTRUCCIÓN DE LA SOLUCIÓN PROPUESTA .......................................................... 73

4.1 INTRODUCCIÓN. ................................................................................................................... 73 4.2 MODELO DE DISEÑO. ........................................................................................................... 74 4.3 DIAGRAMA DE CLASES. ....................................................................................................... 74 4.4 DIAGRAMA MODELO DE DATOS. ......................................................................................... 74 4.5 DIAGRAMA DE CLASES PERSISTENTES. ............................................................................... 74 4.6 PRINCIPIOS DE DISEÑO......................................................................................................... 74

4.6.1 Estándares de Codificación. ......................................................................................... 72 4.6.2 Formato de los Reportes. ............................................................................................. 73 4.6.3 Concepción General de la Ayuda. ................................................................................ 73 4.6.4 Tratamiento de excepciones. ................................................................................................. 74

4.7 MODELO DE DESPLIEGUE. ................................................................................................... 76

4.8 MODELO DE IMPLEMENTACIÓN. ........................................................................................ 76 4.8.1 Diagrama de Componentes. ......................................................................................... 76

4.9 CONCLUSIONES. ................................................................................................................... 76

ESTUDIO DE FACTIBILIDAD ................................................................................................ 81

5.1 INTRODUCCIÓN. ................................................................................................................... 81 5.2 PLANIFICACIÓN. ................................................................................................................... 82 5.3 BENEFICIOS TANGIBLES E INTANGIBLES. ............................................................................. 83

5.3.1 Beneficios tangibles. ..................................................................................................... 83 5.3.2 BENEFICIOS INTANGIBLES. ............................................................................................... 84 5.4 ANÁLISIS DE COSTOS Y BENEFICIOS. ................................................................................... 84 5.5 CONCLUSIONES. ................................................................................................................... 85

CONCLUSIONES. ...................................................................................................................... 89

RECOMENDACIONES. ............................................................................................................ 90

REFERENCIAS BIBLIOGRÁFICAS. ..................................................................................... 91

BIBLIOGRAFÍA. ........................................................................................................................ 93

GLOSARIO DE TÉRMINOS. ................................................................................................... 94

ANEXOS. ........................................................................... ERROR! BOOKMARK NOT DEFINED.7

IINNTTRROODDUUCCCCIIÓÓNN

Los centros históricos constituyen la memoria viva de la evolución histórica y cultural de

los pueblos, en su interior sobreviven no solo las tradiciones y costumbres más antiguas

sino además están representados los valores arquitectónicos y urbanos más genuinos

del patrimonio edificado. La importancia que cobran hoy esos conjuntos, acrecienta la

necesidad de conocerles científicamente de ahí que se convierta en objeto de estudio

de investigadores e instituciones de todo el mundo, en particular en relación a la

búsqueda de respuesta a la demanda de su cuidado y protección en medio de una

puesta en valor que le haga rentable en coordenadas de incontrolable globalización y

desarrollo tecnológico.

Como áreas de especiales características dentro de la ciudad, los centros históricos son

consecuencia de una continua estratificación y compenetración de épocas distintas,

fruto de una rica yuxtaposición de lenguajes arquitectónicos y urbanos que evidencian la

correspondencia entre espacio físico y las necesidades generadas por un nuevo modo

de vida de sus habitantes. De modo que la continua relación entre la ciudad histórica y

el hombre actual da lugar al primordial problema de los centros históricos: el polémico

criterio de su conservación y rehabilitación. Se trata, como refiere Giorgio Piccinato, de

“lograr un equilibrio entre la permanencia y el reforzamiento de sus valores sin negar la

renovación de algunos de sus elementos, manteniendo su coherencia y riqueza de

expresión que la hace reconocible como tal”.

Por tanto el objeto de estudio de este trabajo es Plan Maestro y Gestión de la Oficina

del Historiador.

De aquí, se deriva que el campo de acción queda enmarcado en la automatización de

los procesos para la determinación de las potencialidades de cambio de uso, acciones

de mantenimiento y oportunidades de inversión en las edificaciones del centro histórico

de la ciudad de Camagüey.

El objetivo general de este trabajo será: Proponer un sistema de indicadores y variables

que integre los indicadores patrimoniales con los arquitectónicos y urbanos. Este

sistema permite trazar una estrategia de intervención general en los centros históricos

sobre la base de defender sus valores como conjunto urbano. Además que nos brinda

la posibilidad de clasificar las Unidades Edificatorias de acuerdo a sus potencialidades

para cambio de uso.

De aquí, se derivan los siguientes objetivos específicos:

• Realizar el proceso de análisis y diseño del sistema empleando la metodología

RUP y el lenguaje UML, esto implica realizar el modelo del negocio y el modelo

del sistema. Para la representación grafica de ambos modelos se empleara la

herramienta CASE (Racional Rose).

• Seleccionar los lenguajes de programación y gestor de base de datos que

permitan, darle solución a la problemática propuesta.

• Implementar en los lenguajes de programación y gestor de base de datos

seleccionados los algoritmos desarrollados en las fases de análisis y diseño.

• Poner a prueba el sistema.

Las tareas desarrolladas para cumplir los objetivos.

Para cumplir los objetivos desde el punto de vista arquitectónico se tomó como

referencia tesis de maestría de la arquitecta Elvira Sariol haciendo una revisión

bibliográfica de la misma.

Para la selección del tipo de aplicación, es decir una aplicación de escritorio, la

tecnología, como es el caso de la selección del lenguaje de programación y del tipo del

gestor de base de datos, y la metodología a utilizar, ADDOSI o RUP, se uso el MSDN

de Visual Studio de .NET.

Se realizaron entrevistas tanto físicas como a través del correo electrónico al usuario y a

personas interesadas en la confección de la aplicación para lograr la obtención de los

requerimientos. También a personal capacitado y actualizado en las nuevas tecnologías

de la informática para la selección de la tecnología a utilizar.

Se hizo un estudio de las ventajas del lenguaje, gestor de base de datos y herramienta

de análisis y diseño, llegando a la selección de C#, SQL-Server y RUP, con UML como

lenguaje.

La empresa esta orientada a la compilación, creación, estudio y puesta en práctica del

sistema de información que establece los parámetros de funcionalidad del centro

histórico, el uso potencial del suelo, controlando el comportamiento actual y perspectivo

de este, participa en la creación de las estrategias de intervención dirigidas a

transformar el medio, generando propuestas de intervención en todo tipo de

infraestructura, reglamentando y normalizando la forma de realizar las

transformaciones, apoyándose siempre en trabajos de investigación que van desde el

aspecto histórico del problema hasta las valoraciones sociológicas que este implica y

que de este emergen.

El contenido está estructurado en cinco capítulos fundamentales. El primero,

Fundamentación del Tema muestra aspectos generales del centro Histórico de la

Ciudad de Camagüey y su funcionamiento, así como el porqué de la informatización.

También se tratan elementos importantes relacionados con la necesidad del sistema

para una respuesta rápida, el estudio de tecnologías para el desarrollo de aplicaciones

eficientes, las soluciones de código abierto y los gestores de bases de datos.

En el segundo capítulo, Fundamentación teórica, criterio de selección de tecnología.

El tercer capitulo, Descripción de la Solución Propuesta, aborda los flujos de trabajo de

diseño donde se modelan un grupo de artefactos, se exponen los elementos

reutilizados, los estándares de programación y diseño de interfaz, así como las medidas

de seguridad a tener en cuenta. El cuarto capitulo es Construcción de la solución

propuesta, explicar el diseño del flujo de implementación, viéndolo desde ese punto de

vista.

El quinto y último capítulo, Estudio de Factibilidad, lleva a cabo la planificación del

proyecto, así como el análisis de costos y beneficios involucrados en la realización del

mismo.

Capítulo I Fundamentación del Tema DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

7

FFUUNNDDAAMMEENNTTAACCIIOONN DDEELL TTEEMMAA

1.1 Introducción En el presente capítulo se brinda una visión general de los aspectos relacionados con la

automatización de las variables del centro histórico de Camagüey. Se informa sobre la

descripción de los principales conceptos asociados al problema que son necesarios

para entender el negocio

Además se describen los procesos del negocio que se relacionan con el objeto de

estudio de este trabajo. Se identifican los principales problemas que fundamentan la

propuesta de solución, y se marcan los objetivos generales y específicos.

1.2 ¿Por que es necesario automatizar el Centro Histórico de Camagüey?

Existen cinco razones fundamentales por las cuales es necesario el sistema DUAC

versión 1.0:

1. Resulta muy complicado actualizar las planillas de registros de las oficinas del

centro histórico, pues solo puede hacerse borrando los datos en la misma cada vez que

C a p í t u l o

1


8

se modifica, por lo que todo gasto tanto de recursos humanos como los económicos es

considerable al de cursar del tiempo.

2. Es prácticamente imposible consultar esta información, son miles de inmuebles los

que se ubican en la ciudad, por muy organizado que se conserven los expedientes no le

es factible a los técnicos consultarlas con frecuencia, primero porque la actividad de

trámites tanto a particulares como estatales es muy operativa, o sea para cada trámite

evidentemente se necesita consultar la información, pero la planilla solo permite hacer

un análisis elemental de los datos que en ella se recogen, pues es necesario realizar

cruce entre las diferentes variables pare poder valorar los datos y, no obstante solo así

podemos tener resultados parciales, pues para un análisis a escala urbana se requiere

de conocer el comportamiento de un área de considerable dimensiones.

3. A pesar de contar con un archivo de datos este no puede explotarse como es

debido, el personal existente no da abasto para en el tiempo previsto emitir respuestas

correctas, generándose nuevos libros de control sobre la actividad.

4. Se dificulta hasta el extremo la elaboración del Plan Estratégico, pues este

instrumento debe contar con un diagnóstico detallado que nos permita evaluar el

territorio, por lo que se hace inoperante el manejo de la información, solo permite

trabajar temáticas a pequeña escala., donde toda la información se procesa

manualmente.

5. Así mismo se cuenta con una base cartográfica muy desactualizada, que nos impide

contar con los planos temáticos que requieren los diferentes análisis, o elaborarlos las

veces que son necesarios para ilustrar diferentes situaciones.

1.3 Situación problémica y problema a resolver. Necesidad imperiosa de agudizar los análisis a escala arquitectónica y urbanística, con

el objetivo de elaborar el Plan de Manejo de la ciudad total o parcialmente,

estableciendo así la estrategia de intervención a través del planeamiento, gestión y

correcto control del territorio. Pero para realizar un diagnostico confiable debemos


9

procesar el inventario y actualizarlo constantemente, eso solo es posible si se

computariza. Fue necesario crear una herramienta útil que garantice a través de un

programa computarizado aplicar una correcta metodología de análisis, partiendo de una

base de datos literal lo cual nos permite lograr la información necesaria con garantía,

rapidez y permanentemente actualizada. Los resultados obtenidos facilitan a los

técnicos además del estudio del territorio, emitir soluciones alternativas a las diferentes

demandas los cuales no siempre pueden prolongarse en tiempo y generalmente

comprometen el estudio urbano. Además el técnico le podrá brindar al usuario un

cuerpo de regulaciones sobre la acción a realizar que garantice el correcto uso del

inmueble.

1.4 Soluciones existentes. Se conoce de la existencia de un SIG actualizado por la Dirección del Plan Maestro de

la OHHV, 2004. Además de un fichaje y modo de presentación actualizado por la

Dirección Plan Maestro de la OCC en Santiago de Cuba, 2004. En el mundo existen

otros sistemas semejantes al que se desea implantar en el Centro Histórico de la

Ciudad de Camagüey, uno es un Sistema automatizado de Información o Inventario de

Monumentos y Sitios. Puebla, México.1996. Otro sistema es el de Inventario en España

para el centro histórico de Mondoñedo, Galicia, España, 1998.

Este software es de interés para todas aquellas entidades cuyo objeto se relaciona con

el planeamiento, control y gestión en las áreas de interés patrimonial, además de

permitirnos la proyección sobre bases reales en los análisis de la asignatura de

Proyecto Urbano Arquitectónico VI, el que se vincula específicamente con los temas de

la conservación y restauración. La creación de este instrumento, es de incuestionable

valor permitiéndonos la elaboración de una estrategia correcta en estas áreas.

En la actualidad no se cuanta con ningún Software que realice esta labor por lo que la

confección de este será de mucha ayuda para tratar las temáticas anteriormente dichas.


10

1.5 Descripción de los conceptos asociados a la solución del problema. Para la labor de refuncionalización de los centros histórico resulta necesario conocer el

potencial de cambio de uso con que cuenta en función de restablecer las estructuras

socioeconómicas devaluadas ante las exigencias contemporáneas para establecer una

estrategia que lejos de devaluar el centro histórico como Monumento Nacional, afiance

sus peculiaridades.

La creación de un sistema de indicadores y variables que sirva de estrategia al plan de

manejo del potencial de uso en los centros históricos exige de la interrelación de

indicadores patrimoniales arquitectónicos y urbanos que permitan la conservación del

centro por sus valores como conjunto urbano y no atendiendo a los monumentos

arquitectónicos.

Existen conceptos en el sistema que son de gran utilidad conocer su significado dentro

de los términos de la arquitectura de la ciudad:

Unidad Edificatoria: es el elemento clave para los análisis urbanos, es la unidad básica

en el patrimonio edificado., esta se dividen en lo que se llama desgloses.Luego de un

análisis valorativo de cada variable que se analiza en conjunto en la Unidad Edificatoria,

podremos evaluar la misma, para ello se validan los datos de cada desglose llegando a

valores únicos en cada variable para la Unidad Edificatoria.

Los indicadores y las variables seleccionadas para el análisis de los inmuebles de la

ciudad se clasifican en 4 grupos: localización (no. de UBIT, no. de manzana, no de

desglose), arquitectónicas (valor, carácter, estado constructivo, transformaciones, estilo,

época, uso, modificaciones, no. de plantas), urbanas(área de lote, área construida,

puntal, longitud de la fachada, si la fachada da a plaza, existencia de portal, presencia

de galería, sociales(cantidad de habitantes y nivel de vida).

Existen cuatro conceptos fundamentales en los cuales se sustenta el sistema:

Grado de protección (I, II, III, IV), si el inmueble constituye potencial o no para cambio

de uso, categoría tipológica que presenta, y su estado constructivo.


11

1.6 Tecnologías y referencias bibliográficas. La tecnología utilizada para el desarrollo del sistema:

SQL-SERVER, como gestor de Base de Datos.

C#, como lenguaje de programación.

RUP, con lenguaje UML, para el análisis y diseño del sistema.

La referencias bibliográficas utilizadas como fuente de información para el caso de la

información arquitectónica se tomo el Trabajo presentado en opción del título de

maestría en Conservación del Patrimonio Edificado de la arquitecta Elvira Sariol

Hernández, profesora de arquitectura de la Universidad de Camagüey.

Para obtener información acerca de la tecnología, metodología y del tipo de aplicación a

utilizar se uso el MSDN de Visual Studio.NET, el texto El proceso unificado de

desarrollo de software, volumen 1, Jacobson, Booch, Rumbaugh, y el de Ingeniería de

software con UML, Leyton Eduardo, tutoriales extraídos de Internet sobre C# y SQL-

SERVER.

1.7 Fundamentación de los objetivos que se propone el trabajo. Para darle respuesta a la situación problemática planteada, se propone para este

trabajo un conjunto de objetivos:

1.7.1 Objetivos Generales: Proponer un sistema de indicadores y variables que integre los indicadores

patrimoniales con los arquitectónicos y urbanos. Este sistema permite trazar una

estrategia de intervención general en los centros históricos sobre la base de defender

sus valores como conjunto urbano. Además que nos brinda la posibilidad de clasificar

las Unidades Edificatorias de acuerdo a sus potencialidades para cambio de uso.

1.7.2 Objetivos específicos: 1. Realizar el proceso de análisis y diseño del sistema empleando la metodología RUP y

el lenguaje UML, esto implica realizar el modelo del negocio y el modelo del sistema.


12

Para la representación grafica de ambos modelos se empleara la herramienta CASE

(Racional Rose).

2. Seleccionar los lenguajes de programación y gestor de base de datos que permitan,

darle solución a la problemática propuesta.

3. Implementar en los lenguajes de programación y gestor de base de datos

seleccionados los algoritmos desarrollados en las fases de análisis y diseño.

4. Poner a prueba el sistema.

1.7.3 Objetivos específicos del sistema. 1. Determinar los indicadores y variables patrimoniales y arquitectónicas que se deben

tener en cuenta para establecer un manejo del potencial de uso de los inmuebles

ubicados en el centro histórico de Camagüey.

2. Establecer un sistema de indicadores y variables que posibilite trazar una estrategia

en el manejo del potencial de uso en correspondencia con su ubicación en la estructura

urbana, las categorías tipológicas y los valores patrimoniales.

3. Definir la clasificación tipológica y las funciones compatibles en los inmuebles del

centro histórico de acuerdo a su potencial de cambio de uso.

1.8 Aportes prácticos esperados del trabajo. 1. Con la realización de este software se podrá definir un sistema de indicadores y

variables patrimoniales y a parir de estos valorar la potencialidad de cambio de uso de

las edificaciones del Centro Histórico de la Ciudad de Camagüey.

2. Determinar un conjunto de categorías tipológicas en base a metodologías

internacionales aplicadas a la formación y evolución de la arquitectura y el urbanismo de


13

la ciudad de Camagüey en busca de probada cientificidad y aplicabilidad en los análisis

del centro histórico.

3. Contar con una base de datos, que posibilita realizar una serie de consultas,

cuantitativa y cualitativa, acerca de las unidades edificatorias del centro histórico.

1.9 Conclusiones. En el presente capítulo se muestra cuán grande es el volumen de la información que se

maneja y cuán extensa es la labor que realiza el personal que trabaja en el centro

histórico de la ciudad de Camagüey por la Dirección de Plan Maestro de l Oficina del

Historiador de la Ciudad, elementos que, entre otros, demuestran la necesidad del

tratamiento informatizado de las variables para el inventario

Capitulo II Tendencias y Tecnologías Actuales a Considerar. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

14

TTEENNDDEENNCCIIAASS YY TTEECCNNOOLLOOGGÍÍAASS AACCTTUUAALLEESS AA

CCOONNSSIIDDEERRAARR..

2.1 Introducción. La aplicación se realizará en Visual Studio .Net específicamente en C#. Como gestor de

base de datos el SQL-Server con T-SqlServer como lenguaje y para la metodología de

análisis y diseño se usará la metodología RUP, con el lenguaje UML.

Los sistemas gestores de base de datos (SGBD) son los encargados de manipular la

información almacenada en las bases de datos y definir las estructuras para su

almacenamiento. En estos sistemas existe sólo una copia de los datos para que todos

los programas trabajen con ella. Otra de sus características es la capacidad de

interactuar en un ambiente cliente/servidor donde los usuarios trabajan con un conjunto

único de datos alojados en un servidor y al mismo tiempo.

El lenguaje de programación C#, fue el lenguaje nativo que surgió con el Visual Studio

y no es una adaptación como el caso de las ultimas versiones de Delphi y el Visual C++

.NET.

C a p í t u l o

2


15

Aunque es posible escribir código para la plataforma .NET en muchos otros lenguajes,

C# es el único que ha sido diseñado específicamente para ser utilizado en ella, por lo

que programarla usando C# es mucho más sencillo e intuitivo que hacerlo con

cualquiera de los otros lenguajes ya que C# carece de elementos heredados

innecesarios en .NET. Por esta razón, se suele decir que C# es el lenguaje nativo de .NET.

2.2 Lenguaje Visual C#.NET. C# supone una mejora respecto a otros lenguajes existente por que es el último, y por lo

tanto, el más adaptado a las necesidades actuales del programador y el que más ha

aprendido de los demás, heredando lo mejor de cada entorno, y añadiendo las cosas

que los programadores solicitaban.

Una de las características principales de C# es que se trata de un lenguaje que compila

(por defecto) a un formato intermedio, al estilo de Java, denominado Intermediate

Language (IL), que posteriormente, debe de ser interpretado por un entorno de

ejecución, una máquina JIT (just-in-time), también al estilo de Java. La gran diferencia

respecto a Java es que, ése intérprete será común a todos los lenguaje soportados por

el entorno de ejecución y mediante este mecanismo permitirá que los componentes

realizados en cualquier lenguaje puedan comunicarse entre sí.

Se trata pues, de una extensión del concepto inicial que dio origen a Java: en lugar de

un único lenguaje para muchas plataformas, se pretende un entorno común

multiplataforma, que soporte muchos lenguajes, basándose en que todos ellos compilen

a un mismo código intermedio. Para hacer viable esta idea, se ha optimizado

considerablemente la velocidad, respecto a Java y ya se están anunciando los primeros

.NET Framework para otras plataformas.

Permite la integración de los diferentes lenguajes soportados por el entorno común de

ejecución (CLR), se basa en la existencia un conjunto común de tipos de datos que

coinciden para cualquier lenguaje La principal ventaja que tiene un sistema de tipos

común radica en la seguridad. Seguridad en la conversión de tipos y garantía de que


16

cualquier lenguaje que utilizará el CTS podrá interpretar e interactuar con módulos

creados en otros lenguajes sin traducciones.

Sin duda, una de las novedades del lenguaje C# en comparación con sus similares

(C++, Java) es la presencia de las propiedades, también llamadas campos inteligentes,

que no son sino métodos de acceso a los campos de una clase, que se ven como

campos desde el cliente de esa clase. Se trata de un mecanismo más elegante de

acceso al estado de una clase, y una de las aportaciones que el lenguaje C# realiza a la

mejora de las técnicas de encapsulación en los lenguajes OOP.

Bases sobre las que se asienta la construcción de un programa escrito en C#:

1) Todo programa compilado para el entorno común de ejecución (CLR) comparte un

mismo código intermedio (Intermediate Language ó IL) que debe ser ejecutado por un

intérprete JIT que resida en la plataforma de ejecución. Aunque pueden distinguirse

entre componentes y ejecutables, en éste último caso, el formato resultante es

independiente del lenguaje que se utilizó en su escritura. El formato de los ejecutables

independientes se denomina PE (Portable Executable).

2) El entorno común de ejecución (CLR) es invocado por cualquier programa escrito en

el formato PE, y es quien se hace cargo del mantener la zona de memoria en la que se

ejecuta el programa y suministra un sistema de tipos de datos común (Common Type

System), que describe los tipos soportados por el intérprete y cómo estos tipos pueden

interactuar unos con otros y cómo puede ser almacenados en meta datos.

3) Los servicios del sistema operativo se suministran mediante librerías (DLL)

dispuestas por el CLR cuando se instala .NET Framework en una plataforma (Windows,

McIntosh, Linux, etc.). Dichas librerías son referenciadas en el código de C# mediante la

sentencia using seguida del nombre de la librería deseada. Tales declaraciones reciben

el nombre de Espacios Calificados o Espacios con Nombre Namespaces (un

namespace es una forma adecuada de organizar clases y otros tipos de datos en una

jerarquía. Podríamos decir que sirven al mismo tiempo para 3 propósitos: organizar

(dentro de la jerarquía), para firmar (o marcar de forma única) fragmentos de código


17

como pertenecientes a ese namespace, evitando colisiones con otros fragmentos que

puedan contener definiciones iguales, y como método de abreviación, ya que una vez

declarado el namespace podemos referirnos a sus contenidos en el código sin

necesidad de repetir toda la secuencia jerárquica).

4) En C#, todo puede ser tratado como un objeto, aunque no obligatoriamente, y sin la

penalización que supone esta característica en lenguajes orientados a objetos "puros",

como SmallTalk. Por tanto cualquier código en C# estará incluido en una clase, ya sea

esta instanciada o no. Además, se protege la inversión realizada previamente en

desarrollo, ya que permite la llamada a componentes COM, a librerías nativas del API

de Windows (DLL's), permite el acceso de bajo nivel cuando sea apropiado y los

ejecutables y componentes producidos con él se integran perfectamente con otros

ejecutables o componentes realizados en otros lenguajes del entorno.

5) La sintaxis de C# recuerda bastante la de Java, si bien los conceptos implicados en

la construcción de objetos, tipos, propiedades, métodos, y eventos no suelen ser

idénticos teniendo -en ocasiones- notables diferencias conceptuales. La mayor similitud

se encuentra, como cabía esperar, en el tratamiento de las estructuras de control del

programa (prácticamente idénticas a C++ y Java.

2.3 Microsoft SQL Server como gestor de Bases de Datos. SQL Server es un sistema administrador para Bases de Datos relacionales basadas en

la arquitectura Cliente / Servidor (RDBMS) que usa Transact-SQL para mandar

peticiones entre un cliente y el SQL Server.

SQL Server usa la arquitectura Cliente / Servidor para separar la carga de trabajo en

tareas que corran en computadoras tipo Servidor y tareas que corran en computadoras

tipo Cliente:

• El Cliente es responsable de la parte lógica y de presentar la información al usuario.

Generalmente, el cliente corre en una o más computadoras Cliente, aunque también

puede correr en una computadora Servidor con SQL Server.

• SQL Server administra Bases de Datos y distribuye los recursos disponibles del

servidor (tales como memoria, operaciones de disco, etc.) entre las múltiples peticiones.


18

Éste es una versión de SQL (Structured Query Languaje) usado como lenguaje de

programación para SQL Server. SQL es un conjunto de comandos que permite

especificar la información que se desea restaurar o modificar. Con Transact – SQL se

puede tener acceso a la información, realizar búsquedas, actualizar y administrar

sistemas de Bases de Datos Relacionales.

SQL Server está integrado con el sistema de seguridad de Windows NT. Esta

integración permite acceder tanto a Windows NT como a SQL Server con el mismo

nombre y contraseña. Además SQL Server una las características de encriptación que

Windows NT para la seguridad en red. SQL Server está provisto de su propia seguridad

para clientes no-Microsoft.

SQL Server usa una arquitectura de comunicación por capas para aislar aplicaciones

internas de red y protocolos. Esta arquitectura permite desplegar la misma aplicación

en diferentes ambientes de red. Los componentes en la arquitectura de comunicación

incluyen:

• APLICACIÓN: Una aplicación es desarrollada usando una aplicación de interfaz de

programación para Base de Datos (API). La aplicación no tiene conocimiento de los

protocolos internos de red usados para la comunicación con SQL Server.

• INTERFAZ DE LA BASE DE DATOS: Esta es una interfaz usada por una aplicación

para mandar peticiones a SQL Server y procesar los resultados devueltos por SQL

Server.

• LIBRERÍA DE RED: Este es un componente de Software de comunicación que

empaqueta las peticiones de la Base de Datos y los resultados para transmitirlos por

medio del protocolo de red apropiado. Una librería de Red, también conocida como

Net-Library, debe ser instalada tanto en el cliente como en el servidor. Tanto Clientes

como Servidores pueden usar más de una Net-Library al mismo tiempo, pero deben

usar una Librería de Red común para comunicarse satisfactoriamente. SQL Server

soporta protocolos de red tales como TCP/IP, Novell, IPX/SPX, Banyan VINES/IP,

Named Pipes, y Apple Talk ADSP.

• TABULAR DATA STREAM: (TDS) Es un protocolo por niveles de aplicación usado

para la comunicación entre un Cliente y SQL Server. Los paquetes TDS son

encapsulados en los paquetes de red hechos por la protocolo stak usada por las Net-

Libraries.


19

• SERVICIOS OPEN DATA: Este es un componente de SQL Server que se encarga

de las conexiones de red, pasando las peticiones del cliente al SQL Server para

procesar y regresar cualquier resultado a los Clientes.Open Data escucha

automáticamente en todas las Net-Libraries que están instaladas en el servidor.

SQL Server valida a los usuarios con 2 niveles de seguridad; autentificación del login y

validación de permisos en la Base de Datos de cuentas de usuarios y de roles. La

autentificación identifica al usuario que está usando una cuenta y verifica sólo la

habilidad de conectarse con SQL Server. El usuario debe tener permiso para acceder a

las Bases de Datos en el Servidor. Esto se cumple para asignar permisos específicos

para la Base de Datos, para las cuentas de usuario y los roles. Los permisos controlan

las actividades que el usuario tiene permitido realizar en la Base de Datos del SQL

Server.

Después de que los usuarios han sido autentificados, y se les ha permitido conectarse

al SQL Server, deben tener cuentas en la Base de Datos. Las cuentas de usuario y los

roles, identifican permisos para ejecutar tareas.

Las cuentas de usuario utilizadas para aplicar permisos de seguridad son las de

usuarios, o grupos de Windows NT o las de SQL Server. Las cuentas de usuario son

específicas para cada Base de Datos.

Permiten reunir a los usuarios en una sola unidad a la cual se le pueden aplicar

permisos. SQL Server contiene roles de servidor y de Base de Datos predefinidos, para

tareas administrativas comunes, de manera que pueden asignársele determinados

permisos administrativos a un usuario en particular. También se pueden crear roles de

Base de Datos definidos por el usuario. En SQL Server, los usuarios pueden

pertenecer a varios roles:

• Roles fijos del Servidor: Proveen agrupamientos con privilegios administrativos a

nivel del Servidor. Son administrados independientemente de las Bases de Datos de

usuarios a nivel servidor.

• Roles fijos de la Base de Datos: Proveen agrupamientos con privilegios

administrativos a nivel de Base de Datos.

• Roles de usuarios definidos en la Base de Datos: También se pueden crear roles

para Base de Datos, para representar un trabajo desarrollado por un grupo de

empleados dentro de una organización. No es necesario asignar y quitar permisos a


20

cada persona. En función de que cambia un rol, se pueden cambiar fácilmente los

permisos del rol y hacer que los cambios se apliquen automáticamente a todos los

miembros del rol.

Implementar una Base de Datos en SQL Server significa planear, crear y mantener un

número de componentes interrelacionados. La naturaleza y complejidad de una

aplicación de Base de Datos, así como el proceso de planearla puede variar enormente.

Por ejemplo, una Base de Datos puede ser relativamente simple, diseñada para ser

usada por una sola persona, o puede ser grande y compleja, diseñada para atender

todas las transacciones de cientos o miles de clientes.

En cuanto al tamaño y complejidad de la Base de Datos, generalmente la

implementación de una Base de Datos involucra:

1. Diseñar la Base de Datos de manera que la aplicación optimice el uso de Hardware

y permita crecimiento futuro, identificar y modelar objetos de la Base de Datos y

aplicaciones de lógica, y especificar tipos de información para cada objeto y tipo de

relación.

2. Crear la Base de Datos y los objetos, incluyendo tablas, mecanismos de integridad

de datos, entrada de datos y objetos, índices y seguridad.

3. Probar la aplicación y la base de Datos. Cuando se diseña una Base de Datos, se

desea asegurar que la Base de Datos realiza las funciones importantes en forma rápida

y correcta.

4. Planear el funcionamiento, lo que incluye analizar la carga de trabajo y recomendar

una configuración óptima para la Base de Datos de SQL Server.

5. Administrar la aplicación, lo que incluye configurar a los clientes y servidores,

monitorear el funcionamiento del Server, administrar tareas, alertas y operadores,

administrar seguridad y procedimiento de backup de la Base de Datos.

ADMINISTRACIÓN DE UNA BASE DE DATOS DE SQL SERVER:

Abarca 3 puntos importantes:

1. Instalar y configurar SQL Server y establecer la seguridad de red.

2. Construir las Bases de Datos: incluye asignar espacio en disco para la Base de Datos

y la conexión, transferir datos de y hacia la Base de Datos, definir e implementar la

seguridad de la base de Datos y crear trabajos automatizados para ciertas tareas.


21

3. Administrar actividades entrantes, como la importación y exportación de datos,

respaldar y restaurar la base de Datos y la conexión, y monitorear la Base de Datos. Una

tarea opcional es automatizar algunas de estas tareas administrativas recurrentes.

LOS PRO:

SQL Server está plagado de nuevas características. Vamos a repasar algunas de las

más significativas.

Asignación Dinámica de Recursos. La asignación dinámica de recursos del SQL Server

es una característica muy útil. La asignación dinámica de recursos permite la

escalabilidad del uso del disco y memoria para acomodarse a las necesidades de la

base de datos en cada momento. Esta flexibilidad permite un mejor rendimiento y

simplifica la administración del software. La eliminación de dispositivos también es una

ventaja añadida.

El Soporte 9x para Windows. El soporte para la plataforma Win9x aumenta

significativamente la base de aplicaciones posibles para el SQL Server. Al usarlo con la

replicación distribuida de fusión del SQL Server, el soporte Win9x permite que las

empresas con sucursales pequeños que incluyen solo unos pocos sistemas Win9x en

cada oficina remota aprovechen de las aplicaciones del Servidor SQL a través de la

empresa entera.

El Analizador Gráfico de Consultas. El programa ISQL/w del Servidor SQL 6.5 es una

herramienta útil y a menudo necesaria para construir y ejecutar las sentencias

interactivas de SQL. El nuevo Analizador de Sentencias del SQL Server representa un

paso adelante dentro de este programa. No solo se puede construir unos

procedimientos guardados y ejecutar unas consultas interactivas, sino que también se

puede enseñar gráficamente los pasos que el procesador de consultas usa para

ejecutar la consulta.

Los Servicios OLAP del Servidor SQL de Microsoft. Después de toda la incertidumbre

acerca de si Microsoft iba a añadir un servidor OLAP a SQL Server, o si por el contrario

iba a ofrecerlo por separado, disponer por fin de los Servicios OLAP para SQL Server

es casi como recibir un producto gratis. Con la inclusión de los Servicios OLAP como

parte del Servidor SQL, Microsoft ha abierto el mercado del data warehousing, data


22

mart, y el soporte a tomas de decisión a muchas empresas pequeñas o medianas que

no habrían pensado en usar este tipo de herramienta dados sus elevados costes.

Los Servicios de Transformación de Datos (DTS). La nueva característica DTS del SQL

Server es una poderosa herramienta y muy flexible. Aunque Microsoft la ha diseñado

pensando en facilitar el almacenamiento de datos, la utilidad del producto no acaba allí.

DTS simplifica la importación y la exportación de datos entre dos bases de datos

compatibles con OLE DB. DTS también genera scripts Visual Basic (VBScript) que se

puede ejecutar desde el WSH (Windows Scripting Host) u otros entornos COM

(Component Object Model).

Las funciones del Enterprise Manager (EM). Además de implementar el SQL Server

Enterprise Manager como un snap-in del MMC (Microsoft Management Console),

Microsoft ha mejorado sus funciones y ha incorporado de nuevas. La característica que

nos más nos ha llamado la atención es la posibilidad de mirar los contenidos de una

tabla directamente desde el EM. Otra función muy útil es la posibilidad de cambiar

directamente los tipos de datos de las tablas existentes.

LOS CONTRAS:

Y aunque el SQL Server tenga muchas ventajas, también tiene varias desventajas. Aquí

tiene algunas áreas en las cuales debe mejorar en próximas versiones...

La instalación y operación requiere del Internet Explorer (IE) 4.0. Le guste o no, la

interfaz del navegador de Web sigue siendo cada vez más habitual, y su uso es lo

último en desarrollo de interfaces. Podemos entender por qué Microsoft quiere usarlo

con el Servidor SQL, ya que también es un produce de la compañía. Sin embargo, no

tenemos ninguna utilidad para un navegador de Web en nuestro servidor de la base de

datos, y su instalación es un problema que posiblemente, a más de uno le gustaría

evitar.

La migración requiere un reinicio de la base de datos. El reinicio de todos los datos en

una base de datos es un trabajo serio que invita a la potencial pérdida de datos. Cuanto

más grande sea la base de datos, más onerosa será esta obligación. Sin embargo,


23

después de mirar las herramientas de migración del SQL Server, es obvio que Microsoft

se ha planteado esta operación como algo muy serio.

Ausencia de integridad referencial declarativa en cascada (DRI). La ausencia de una

integridad referencial en cascada podría ser la desventaja más grande del Servidor SQL

en comparación con las otras bases de datos dentro del mercado NT. Incluso Access

ofrece soporte de este estilo. Se pueden utilizar triggers para compensar esta

desventaja, aunque en otras bases de datos esta técnica no es necesaria, así que no es

lógico que deba utilizar para trabajar con SQL Server. Al considerar las otras nuevas

características de SQL Server, es una pena que ésta no esta incluida.

2.4 Metodología RUP, lenguaje UML. RUP es una propuesta de proceso para el desarrollo de software orientado a objeto que

utiliza el Lenguaje Unificado de Modelado (UML), un lenguaje para la visualización,

especificación y documentación de los componentes de un sistema. Básicamente UML,

permite a los desarrolladores del sistema visualizar su los resultados de su trabajo en

esquemas o diagramas.

UML se quiere convertir en un lenguaje estándar con el que sea posible modelar todos

los componentes del proceso de desarrollo de aplicaciones. No pretende definir un

modelo estándar de desarrollo, sino únicamente un lenguaje de modelado. [Leyton,

2000]

UML proporciona a los desarrolladores un vocabulario que incluye tres categorías:

elementos, relaciones y diagramas. De elementos hay cuatro tipos: estructurales, de

comportamiento, de agrupación y de notación.

De elementos estructurales hay sietes: casos de uso, clases, clases activas, interfaces,

componentes, colaboraciones y nodo.

De la categoría relación tenemos tres tipos: de dependencia, de asociación y de

generalización.


24

De la categoría de los diagramas hay nueve tipos: diagramas de caso de uso, de

clases, de secuencia, de colaboración, de estados, de actividad, de componentes y de

despliegue.

2.5 Conclusiones. En este capitulo se realizo un estudio de las tecnologías utilizadas, las ventajas y

desventajas de cada una de ellas, así como su forma de empleo en aplicaciones. Se

destacan cualidades del gestor de Base de Datos SQL-Server, utilizada en el software

implementado, la programación en la plataforma .NET, con el lenguaje de programación

C#, por las potencialidades que ofrecen.

Capítulo III Descripción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

25

DDEESSCCRRIIPPCCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN PPRROOPPUUEESSTTAA

3.1 Introducción. El desarrollo de la aplicación en cuestión se ha basado en el Proceso Unificado de

Desarrollo de Software (RUP por sus siglas en inglés) que hace uso del Lenguaje

Unificado de Modelado (UML por sus siglas en inglés) para la modelación de los

artefactos que se presentan. Ha sido de vital importancia la utilización, además, de la

herramienta case Rational Rose que asiste el desarrollo de software aumentando la

productividad y calidad del mismo. La combinación anterior ha tomado mucho auge

desde su surgimiento y ha demostrado sus potencialidades al unificar muchas

metodologías y lenguajes que, con la finalidad del desarrollo del software, se han venido

presentando. Poniendo en práctica dicho proceso y, con vista a entender el contexto del

sistema a desarrollar, se llevó a cabo un estudio de la estructura y la dinámica de las

oficinas del centro Histórico de la ciudad de Camagüey, y de forma más detallada, del

funcionamiento de cada una de sus secciones de trabajo.

Teniendo en cuenta lo anterior, se elaboró el presente capítulo que expone,

primeramente, un listado de las dificultades más relevantes que podemos encontrar

actualmente en las oficinas del historiador y el modelo del negocio que constituye un

punto de partida importante para el desarrollo y comprensión del sistema que se

pretende implementar. Inmediatamente, el capítulo muestra la variante de

automatización propuesta que contiene el modelo de casos de uso del sistema con los

C a p í t u l o

3


26

actores del sistema, los casos de uso del sistema y las relaciones entre ellos, así como

un listado de requisitos adicionales (fiabilidad, seguridad, rendimiento, software,

hardware, etc.).

3.2 Estado actual del negocio. En la actualidad, en la oficina del historiador de la ciudad de Camagüey, se presentan

numerosas dificultades que afectan directamente los trámites que en ellas se realizan.

Se pueden citar las siguientes:

1. Resulta muy complicado actualizar las planillas, pues solo puede hacerse borrando

los datos en la misma cada vez que se modifica, lo que implica todo tipo de gastos,

tanto de recursos humanos como económicos

2. Es prácticamente imposible consultar esta información, son miles de inmuebles los

que se ubican en la ciudad, por muy organizado que se conserven los expedientes

no le es factible a los técnicos consultarlas con frecuencia, primero porque la

actividad de trámites tanto a particulares como estatales es muy operativa, o sea

para cada trámite evidentemente se necesita consultar la información, pero la

planilla solo permite hacer un análisis elemental de los datos que en ella se recogen,

pues es necesario realizar cruce entre las diferentes variables pare poder valorar los

datos y, no obstante solo así podemos tener resultados parciales, pues para un

análisis a escala urbana se requiere de conocer el comportamiento de un área de

considerable dimensiones.

3. A pesar de contar con un archivo de datos este no puede explotarse como es

debido, el personal existente no da abasto para en el tiempo previsto emitir

respuestas correctas, generándose nuevos libros de control sobre la actividad.

4. Se dificulta hasta el extremo la elaboración del Plan Estratégico, pues este

instrumento debe ser contar con un diagnóstico detallado que nos permita evaluar el

territorio, por lo que se hace inoperante el manejo de la información, solo permite

trabajar temáticas a pequeña escala., donde toda la información se procesa

manualmente.


27

5. Así mismo se cuenta con una base cartográfica muy desactualizada, que nos impide

contar con los planos temáticos que requieren los diferentes análisis, o elaborarlos

las veces que son necesarios para ilustrar diferentes situaciones.

El inversionista llega a la oficina y le pide al técnico especialista que le muestre todos

los inmuebles que presenten determinadas características que el desea que posean

para efectuar su inversión, el técnico le hace entrega de un modelo que el debe llenar

para registrar su solicitud en un libro de control, se toman sus datos, que es lo que

desea hacer con ese inmueble, cual es el uso que le va a dar, y si afecta el patrimonio

de la ciudad. De ahí se hace una copia del documento se le entrega al cliente, y es

entonces que el técnico según capacidad hace cruzamientos entre las variables, es de

suponer que no tiene toda la claridad requerida el análisis que se hace. Entonces

podemos concluir diciendo que es ineficiente y demorado el negocio actualmente, y se

puede dar el caso de perder al inversionista.

Cuando el restaurador o el inversionista o el historiador llegan a la oficina piden la

información referente a todas las Unidad edificatoria que se encuentren en el centro

histórico, de ahí se hace un análisis, se buscan las planillas, se llenan libros de control

sobre el usuario interesado en esos datos y toda esa información es archivada por

técnicos especialistas en el libro de control de pedido de información.

Como parte de la inserción del Centro Histórico de Camagüey en el programa de

informatización de la sociedad, este organismo ha decidido crear toda una

infraestructura debidamente equipada que soporte un sistema cuyo objetivo sea

automatizar la actividad de las oficinas del centro histórico y que ofrezca una solución

efectiva a los problemas planteados anteriormente.

3.3 Modelo del negocio. Como primer paso para el desarrollo de software, RUP propone que se comprenda el

contexto que se desea automatizar como fuente que aporta información muy importante

para la obtención de los requerimientos que debe cumplir el sistema a desarrollar e

identificación de los actores del mismo. Con este fin se han recogido las reglas del

negocio indicando las mejoras que se proponen con la aplicación y se ha realizado una


28

modelación del negocio que tiene lugar en las oficinas del Centro Histórico de la ciudad

de Camagüey, dicho modelo esta formado por el modelo de casos de usos del negocio.

3.3.1 Reglas del negocio. En las oficinas del Centro Histórico de la ciudad de Camagüey el proceso surge ante la

necesidad de procesar toda la información referente a los inmuebles de la ciudad, emitir

rápidas respuestas ante la operatividad que demanda la ciudad fundamentalmente en

cuanto a las potencialidades de los cambios de uso, de inversiones, de restauraciones,

y de prioridad de conservación. Estos aspectos requieren respuestas urgentes, para lo

cual es necesario contar con el conocimiento de todos los elementos exigidos para

tener un plan de manejo, evitando así en la medida de lo posible compromisos que se

conviertan en transformaciones irreversibles y que afecten el patrimonio edificado. En

estas oficinas se implanta la aplicación y la base de datos estará en una oficina central

de la cual se tomara la información que desee el usuario que la solicite; el inversionista

llegara y pedirá unidades edificatorias con características que el determino con

anterioridad, y la aplicación le generara los reportes con esos datos, la ubicación, la

cantidad de esas unidades edificatorias y el por ciento que representan del total,

dándole la posibilidad de elegir entre todas las unidades edificatorias que el sistema le

muestra, además ya no tiene que trasladarse hasta la entidad elegida para observarla,

el sistema es capaz de mostrarle la imagen de la misma. Si es un restaurador el que

llega a la oficina, el técnico especialista sabe que lo que le interesa a este usuario son

las unidades edificatorias que presenten determinados grados de protección, se buscan

los datos de la misma y se les da una respuesta rápida mediante el cruzamiento de

variables. Si es el historiador de la ciudad el que solicita la información, el técnico

especialista sabe que tiene que darle todas las unidades edificatorias con todos sus

datos.

Además el sistema es capaz de permitirle a los técnicos especialistas la inserción de

toda la información de todos los inmuebles del centro histórico, así como la eliminación

o modificación de los datos.


29

3.3.2 Modelo de casos de usos del negocio. Este modelo de casos de uso describe los procesos del negocio en términos de casos

de uso del negocio y actores del negocio, representando en estos últimos a los clientes.

Dicho modelo se describe mediante diagramas de casos de uso que muestran cómo los

actores del negocio y los casos de uso del negocio se encuentran relacionados.

[Jacobson, 2000].

Los actores del negocio, que representan a los clientes de las oficinas historiador, son

los siguientes:

Actores Justificación

Inversionista Es la persona que se presenta en la Oficina del Historiador para

solicitar determinada información con el fin de realizar una inversión

en una determinada unidad edificatoria.

Historiador Es la persona que se encarga de la investigación histórica de una

determinada localidad y que se presenta para obtener toda la

información existente sobre los distintos inmuebles del centro

histórico.

Restaurador Es la persona que se dedica a la restauración de inmuebles de

interés histórico-cultural y patrimonial, que se presenta a la Oficina

del Historiador para obtener toda la información que se dispone

sobre los mismos y partiendo de estos datos proponer la

restauración del inmueble en cuestión.

Usuario General. Es un actor abstracto del cual heredan los actores del negocio para

realizar el mismo caso de uso del negocio (Obtener información de

las unidades edificatorias).

Por su parte, los trabajadores del negocio, que representan a los técnicos de las

oficinas del historiador del Centro Histórico de la Ciudad de Camagüey, aparecen a

continuación:


30

Trabajadores Justificación Técnico especialista del Dpto.

de Planeamiento y Gestión.

Es la persona que se encarga de desarrollar las

investigaciones inherentes al territorio y proponer las

estrategias de desarrollo, además de todo lo

relacionado con el proceso de gestión y los talleres de

barrios.

Técnico especialista del Dpto.

Control del Territorio.

Es el responsable de mantener actualizada la

información, todo lo relacionado con el inventario, así

como de controlar el territorio, atender a la población y

las entidades, además de elaborar la maqueta de la

ciudad.

DIAGRAMA DE CASO DE USO DEL NEGOCIO.

Inversionista

Obtener informacion sobre Unidad Edificatoria.Usuario General

Historiador RestauradorProponer Informacion para obtener Unidad

Edificatoria.


31

Casos de usos del negocio: Proponer información para obtener Unidad Edificatoria. El caso de uso inicia

cuando el inversionista llega a la oficina y pide todas las unidades edificatorias que

existan con ciertas características que el trae decididas. El Técnico especialista, llena

un modelo con los datos del inversionista y las caracteristicas de las unidades

edificatorias que desea, asienta los datos en un libro de control de solicitudes. Busca las

unidades edificatorias en los archivos, si existen hace una copia de este modelo. El

inversionista recoge el modelo con los datos y decide visitar las unidades edificatorias

que contiene el modelo. Fin del poceso .Si no existen unidades edificatorias con estas

caracteristicas, se le informa al inversionista, concluye asi el proceso.

La automatización de este proceso permitirá una mejora considerable en la velocidad de

los trámites para recoger la información de las unidades edificatorias que propone el

inversionista, mayor eficiencia y confianza en los datos, y no se toma el riesgo de perder

al inversionista por una demora en la respuesta que debe emitir la oficina.

Obtener información sobre Unidad Edificatoria. El caso de uso inicia cuando el

usuario general llega a la oficina y pide todas las unidades edificatorias que existan en

los archivos de la misma. El usuario general llega a la oficina y solicita los datos de las

unidades edificatorias archivadas. El Técnico especialista, llena un modelo con los

datos del usuario general, cual es el interes en eso datos, asienta los datos en un libro

de control de solicitudes Busca las unidades edificatorias en los archivos El usuario

recoge el modelo con los datos de las unidades edificatorias. El usuario general decide

visitar las unidades edificatorias que contiene el modelo. Fin del poceso.

La automatización de este proceso permitirá una mejora considerable en la velocidad de

los trámites para recoger la información de las unidades edificatorias que existan con

mayor eficiencia y confianza en los datos,


32

Diagrama de actividad. Obtener Información sobre Unidad Edificatoria.

Recibir Modelo resumen de UE

inicio

Solicitar modelo para Obtener Unidad Edificatoria

Llenar modelo de Solicitud de UE

Devolver Modelo de Solicitud de UE

Modelo de Solicitud de UE

[Lleno]

Visitar UE propuestas

Fin

Entregar Modelo para Obtener Unidad Edificatoria

Modelo de Solicitud de UE

[Vacio]

Revisar Modelo de Solicitud de UE

Asentar en Libro de Control de Certificaciones

Libro de control de Solicitudes[Unidad Edificatoria, Usuario General]

Buscar UE

Emitir modelo resumen de UE

Modelo resumen de UE

[Encontradas]

Devoler Modelo resumen de UE

Técnico especialista del Dpto. de Control de Territorio : T...Usuario General : Usuario General


33

Diagrama de actividad. Proponer Información para obtener Unidad Edificatoria.

Modelo de UE propuesta[Unidades Edificatorias propuestas]

Solicitar modelo para obtener Unidad Edificatoria

Llenar modelo

Devolver modeo de Solicitud de UE

Modelo de solicitud de UE.

[Lleno]

Recibir Modelo de UE propuesta

Visitar Unidades Edificatorias propuestas

Entregar modelo de Solicitud de UE.

Modelo de solicitud de UE.

[vacio]

Revisar modelo

Buscar UE segun modelo

Emitir Modelo de Unidad Edificatoria propuestas

[Encontrada]

Entregar Modelo de UE propuesta

Emitir error

[No encontrada]

Asienta en el Libro de Control de Solicitudes.

Libro de Control de Solicitudes[Unidad Edificatoria, Inversionista]

Técnico especialista del Dpto. de Planeamiento y GestiónInv esrionista


34

3.4 Requisitos funcionales. A partir de la modelación del negocio realizada, se determinaron las funcionalidades

que debe desarrollar el sistema. Estas se recogen en el siguiente listado:

1 Actualizar unidad edificatoria

1.1 Adicionar unidad edificatoria.

1.2 Eliminar unidad edificatoria.

1.3 Modificar unidad edificatoria.

2 Verificar que no existen desglose de la unidad edificatoria que voy a eliminar.

3. Actualizar desglose.

3.1 Adicionar desglose de la unidad edificatoria ya existente.

3.2 Eliminar desglose.

3.3 Modificar desglose.

4. Mostrar imagen por cada unidad edificatoria.

5. Mostrar imagen por cada desglose.

6. Actualizar las imágenes.

6.1 Adicionar una imagen.

6.2 Eliminar una imagen.

6.3 Modificar una imagen.

7 Mostrar reporte de todas las unidades edificatorias.

8. Mostrar reporte de todos los desglose.

9. Mostrar la cantidad de unidades edificatorias.

10. Mostrar la cantidad de desglose.

11. Mostrar reporte de valor.

12. Mostrar reporte con carácter.

13. Mostrar reporte de estado constructivo.

14. Mostrar reporte de uso de redes.

15. Mostrar reporte de uso de categorías.

16. Mostrar reporte de uso.

17. Mostrar reporte de época por unidad edificatoria.


35

18. Mostrar reporte por época de los desgloses.

19. Mostrar reporte de 1, 2, 3, 4 plantas.

20. Mostrar reporte según el tipo de planta arquitectónica.

21. Mostrar cada una de las consultas con relación a una calle.

22. Mostrar reporte de con categoría A.

23. Mostrar reporte de categoría B1...B4.

24. Mostrar reporte de categoría C1...C3.

25. Mostrar reporte de categoría D1...D3.

26. Mostrar reporte de grado de protección de la I...IV.

27. Mostrar reporte que tengan un grado de protección, una categoría y un estado

constructivo determinado.

28. Mostrar reportes de unidad edificatoria que constituyen potencial para el cambio

de uso.

29. Automatizar el llenado de la tabla unidad edificatoria.

30. Confeccionar una ayuda de la aplicación.

31. Calcular el por ciento que representa cada una de las consultas del total de las

unidad edificatoria que existen.

32. Mostrar unidad edificatoria por ejes (calles).

33. Gestionar Búsquedas Especializadas.

34. Busquedas libres.

35. Obtener grado de proteccion.

36. Obtener categorias predefinidas.

37. Obtener grados de proteccion predefinido.

38. Administrar Sistema.

39. Autenticar usuario.

40. Mostrar Indicadores patrimoniales.

41. Gestionar Calles.


36

41.1 Insertar Calle

41.2 Modificar Calle

41.3 Eliminar Calle

42. Gestionar Carácter.

42.1 Insertar Carácter.

42.2 Modificar Carácter.

42.3 Eliminar Carácter.

43. Gestionar Valor.

43.1 Insertar Valor.

43.2 Modificar Valor.

43.3 Eliminar Valor.

44. Gestionar Transformaciones.

44.1 Insertar Transformaciones.

44.2 Modificar Transformaciones.

44.3 Eliminar Transformaciones.

45. Gestionar Estado Constructivo.

45.1 Insertar Estado Constructivo.

45.2 Modificar Estado Constructivo.

45.3 Eliminar Estado Constructivo.

46. Gestionar Épocas de los Desglose

46.1 Insertar Épocas de los Desglose

46.2 Modificar Épocas de los Desglose

46.3 Eliminar Épocas de los Desglose

47. Gestionar Épocas de la unidad edificatoria

47.1 Insertar Épocas de la unidad edificatoria

47.2 Modificar Épocas de la unidad edificatoria

47.3 Eliminar Épocas de la unidad edificatoria


37

48. Gestionar Usos

48.1 Insertar Usos

48.2 Modificar Usos

48.3 Eliminar Usos

49. Gestionar Portales.

49.1 Insertar Portales

49.2 Modificar Portales

49.3 Eliminar Portales

50. Gestionar Barrio

50.1 Insertar Barrio

50.2 Modificar Barrio

50.3 Eliminar Barrio

51. Gestionar Tipo Planta.

51.1 Insertar Tipo Planta

51.2 Modificar Tipo Planta

51.3 Eliminar Tipo Planta

52. Gestionar Tipo de Edificación.

52.1 Insertar Tipo de Edificación.

52.2 Modificar Tipo de Edificación.

52.3 Eliminar Tipo de Edificación.

3.5 Requisitos no funcionales. Los requerimientos no funcionales pueden ser agrupados de acuerdo a:

Requerimientos de apariencia o interfaz externa: La aplicación propuesta consta de pantallas con distribución uniforme de sus elementos.

Se pretende una aplicación que sea sencilla de utilizar, donde los controles y elementos


38

se encuentren correctamente distribuidos y que cumplan con los buenos estándares de

la programación basura y diseño siguiendo por ejemplo las interfaces tipo Windows,

además de brindar una imagen profesional del producto que se pretende implementar.

Se desea una interfaz legible, amigable, poco cargada y fácil de usar para todos los

tipos de usuarios

Requerimientos de usabilidad:

Debido al sector de personas a la que va dirigida esta aplicación se pensó en

desarrollar una interfaz de fácil uso y manejo, donde se manipulen los conceptos de una

manera asequible para todos sin dejar por esto que se pierda la seriedad y

profesionalidad. Esta aplicación reúne los conceptos tratados por los especialistas

haciéndola más comprensible y manejable.

Requerimientos de Rendimiento.

Se debe garantizar que la respuesta a solicitudes de los usuarios del sistema sea en un

período de tiempo breve (de segundos) para evitar la acumulación de trabajo por parte

de técnicos en las oficinas pues la labor en estas entidades se caracteriza por una gran

dinámica.

Requerimientos de Soporte:

Una vez terminada la aplicación se someterá a una fase de pruebas con el fin de

detectar todas las fallas posibles para ser corregidas.

Se requiere un servidor de bases de datos con las siguientes características:

Soporte para grandes volúmenes de datos y velocidad de procesamiento.

Tiempo de respuesta rápido.

Plataforma .NET versiones 1.0 / 1.1 o bien plataforma Mono.

Requerimientos de portabilidad:

El sistema propuesto esta pensado par ser usado en distintas plataformas, dado al

amplio auge que va tomando el sistema operativo LINUX y a la política que se esta

siguiendo de su implementación en el territorio nacional, todo esto posible gracias al

Proyecto Mono (Implementación del FrameWork .NET para LINUX) de la comunidad de

LINUX.


39

Esta aplicación puede ser migrada rápidamente de un sistema operativo a otro sin

mayores complicaciones gracias a las facilidades del FrameWork.

Requerimientos de seguridad:

La información manejada por el sistema esta protegida de acceso no autorizado y

divulgación. Debido a la importancia de la información manipulada, esta será objeto de

cuidadosa protección contra la corrupción y estados inconsistentes mediante técnicas

de criptografía. El acceso a los distintos usuarios a la información será restringido

mediante el empleo de roles donde se separan los distintos privilegios según el tipo de

usuario.

Por la gran importancia de la información que se maneja en este sistema se hace

imprescindible mantener varias salvas de la misma tanto en otro disco duro del mismo

nodo servidor donde radica la base de datos como en otras computadoras conectadas a

otra fuente de alimentación eléctrica. Identificar al usuario antes de que pueda realizar

cualquier acción sobre el sistema.

Garantizar que la información sea vista únicamente por quien tiene derecho a verla.

Garantizar que las funcionalidades del sistema se muestren de acuerdo al nivel de

usuario que este activo.

Protección contra acciones no autorizadas o que puedan afectar la integridad de los

datos.

Verificación sobre acciones irreversibles (eliminaciones).

Requerimientos Políticos y Culturales

Se debe respetar la política y la cultura organizativa del centro y sus características

propias, en cuanto a la organización económica de la universidad.

Requerimientos Legales

El trabajo en estas oficinas está regido por leyes y normativas establecidas por lo que

de igual forma el sistema debe respetar todos los procedimientos y estructuras de

documentos que se encuentran legislados. De igual forma existen documentos que por

su valor como “originales” no serán sustituidos con el sistema.


40

Requerimientos de confiabilidad

La información debe estar disponible en todo momento para todas las Oficinas del

centro Histórico de la Ciudad. Es importante garantizar este acceso debido a la

respuesta rápida que se desea brindar a los ciudadanos que asisten a estas unidades y

a la consistencia y actualización que se requiere tenga la información. Además existen

trámites a realizar dentro de un determinado período de tiempo, de lo contrario se

tornan más complejos, lo cual se traduce en insatisfacción del público que solicita el

servicio. Por otra parte, siempre se almacena la información con la referencia al

registrador que la suministró de forma tal que, ante cualquier eventualidad, se pueda

saber quién realizó el trámite o asiento.

Requerimientos de Ayudas y Documentación en línea. El sistema debe implementar una ayuda online disponible al usuario en todo momento

de forma tal que el usuario que esté en el sistema pueda visitarla en caso de cualquier

duda, esta debe brindarle información de todas las actividades a realizar por él.

El software debe tener la documentación completa de todas las tareas y operaciones

que realiza así como todo sobre su implementación.

Requerimientos de Software. Esta aplicación ha sido diseñada para que funcione sobre la familia Windows, 2000 o

superior, estando presenta el Microsoft FrameWork v1.0. También para que ejecute

correctamente sobre LINUX y el FrameWork de Proyecto Mono. Microsoft SQL Server

2000 y Plataforma .NET 1.0 o posterior.

Requerimientos de Hardware. Se requiere de un microprocesador Pentium II o superior, con XXX Mb de RAM;

CDROM Drive para la instalación del producto, etc. Para el servidor seria una

3.6 Descripción del sistema propuesto. 3.6.1 Concepción General del Sistema. El sistema que se propone es una aplicación de desarrollada con C# como lenguaje de

programación que esté conectada a una base de datos de SQL-Server central que


41

radique en la oficina del centro Histórico de la Ciudad de Camagüey y que contenga la

información de todos los inmuebles de la ciudad, Dicha aplicación podrá ser accedida

por las oficinas del centro histórico a través de un dominio que se cree con este fin. Esta

variante que se propone automatizará los procedimientos de trabajo en el flujo de

información.

Se pretende que con esta aplicación se recoja todos los elementos necesarios que

deben ser considerados y garantice la validez de los mismos, aunque como es lógico

existen restricciones para su modificación, pero esto facilitara que todas las entidades

involucradas en el manejo y gestión de los territorios elaboren sus propuestas de forma

colegiada y con todos los datos necesarios.

Con el desarrollo de esta aplicación se espera disminuir notablemente el tiempo de

respuesta al usuario. De igual forma se espera simplificar el trabajo de los técnicos

especialistas y crear una nueva y rápida vía de actualización de la información.

Por otra parte los gastos de la entidad se verán reducidos en cuanto al pago del servicio

telefónico y el de postal.

Además la entidad para la que proponemos este trabajo tiene una gran responsabilidad

en el territorio, los datos que han sido manejados para el diseño de este programa

pueden ser generalizados a otras ciudades , o para el uso también de otras entidades

que de alguna manera se involucran en estas tareas como pueden ser las Direcciones

de Patrimonio, Planificación Física, las Direcciones de Vivienda, como herramienta en

los estudio en las facultades de arquitectura para desarrollar habilidades en las

asignaturas relacionadas con los proyectos arquitectónicos y urbanos y, como es lógico

sirve para que les entidades relacionadas con el proceso inversionista conozcan las

potencialidades de los inmuebles sobre todo en el proceso de cambio de uso de los

mismos.

3.7 Modelo Caso de Uso del Sistema. El modelo de los casos de uso del sistema representa un esquema donde se recogen

las funcionalidades del negocio que se automatiza y determina cómo será utilizado


42

desde la perspectiva del usuario (Actor) pues se construye sobre la base de sus

necesidades. A través de este modelo se puede establecer comunicación, más o menos

fluida en dependencia de la claridad del mismo, con los usuarios finales y clientes

expertos del sistema en desarrollo, e informarles acerca de su comportamiento futuro.

[Jacobson, 2000].

3.7.1Los actores del sistema. Los actores representan los usuarios del sistema e incluyen otra aplicaciones que

puedan interactuar con el. Una vez identificados se tiene el entorno externo del externo

del sistema.

3.7.2 Los casos de usos del sistema. Los casos de usos son fragmentos de funcionalidad que el sistema ofrece para aportar

un resultado de valor para sus actores, un caso de usos especifica una secuencia de

acciones que el sistema puede llevar a cabo interactuando con sus actores, un caso de

uso es una especificación.

Actores Descripción Técnico especialista del Dpto. de Planeamiento y Gestión.

Es la persona que se encarga de desarrollar las investigaciones inherentes al territorio y proponer las estrategias de desarrollo, además de todo lo relacionado con el proceso de gestión y los talleres de barrios.

Técnico especialista del Dpto. Control del Territorio.

Es el responsable de mantener actualizada la información, todo lo relacionado con el inventario, así como de controlar el territorio, atender a la población y las entidades, además de elaborar la maqueta de la ciudad.

Administrador de Sistema Persona encargada de la administración del sistema como entidad computacional.

Usuario Actor abstracto del que heredan todos los demás actores para tomar sus funcionalidades (Autenticar Usuario).

Técnico general Actor abstracto del que heredan los técnicos especialistas para obtener sus funcionalidades (Gestionar Búsquedas.)


43

1. Gestionar unidad edificatoria.

2. Gestionar Desglose.

3. Gestionar Imagenes.

4. Gestionar Calles

5. Gestionar Valor.

6. Gestionar Caracter.

7. Gestionar Transformaciones.

8. Gestionar Estado Constructivo.

9. Gestionar Epoca en los Desgloses.

10. Gestionar Epoca en las Unidad edificatoria.

11. Gestionar Tipo de Planta.

12. Gestionar Tipo de Edificaciona

13. Gestionar Barrio.

14. Gestionar Portal.

15. Mostrar unidad edificatoria por ejes (calles).

16. Generar reportes.

16.1 Generar reportes de todos los desgloses.

16.2 Generar reporte de todas las Unidad edificatoria.

16.5. Generar reporte de unidad edificatoria con valor.

16.6. Generar reporte de unidad edificatoria sin valor.

16.7. Generar reporte unidad edificatoria con caracter excepcional o

relevante.

16.8. Generar reporte de unidad edificatoria en buen estado.

16.9. Generar reporte de unidad edificatoria en mal estado.

16.10. Generar reporte de unidad edificatoria segun susu usos

16.11. .Generar reporte de unidad edificatoria por epoca.

16.12. Generar reporte de unidad edificatoria de 1, 2, 3, 4 plantas.


44

16.13. Generar reporte de unidad edificatoria segun el tipo de planta

arquitectonica

16.14. Generar reporte de unidad edificatoria modificadas.

16.15. Generar reporte de unidad edificatoria con tipologia A.

16.16. Generar reporte de unidad edificatoria con tipologia B1...B7.

16.17. Generar reporte de unidad edificatoria con tipologia C1...C7.

16.18. Generar reporte de unidad edificatoria con tipologia D1...D7.

16.19. Generar reporte de unidad edificatoria con grado de proteccion I..IV.

16.20. Generar reporte de unidad edificatoria con un grado de proteccion, una

tipologia y un estado constructivo determinado.

16.21. Generar reporte de unidad edificatoria que constituyen potencial para

cambio de uso.

17. Gestionar Búsquedas.

17.5. Busquedas libres.

17.6. Obtener grado de proteccion.

17.7. Obtener categorias predefinidas.

17.8. Obtener grado de proteccion predefinidos.

18. Administrar Sistema.

19. Autenticar usuario.

3.7.3 Descripción de los casos de usos del sistema. Caso de Uso Gestionar unidad edificatoria.

Actores Técnico especialista del Dpto. Control del Territorio.(Inicia)

Propósito Permitir al Técnico especialista del Dpto. Control del Territorio

actualizar la información de las unidad edificatoria dentro de la

base de datos, ya sea eliminando, adicionando o modificando las

tuplas existentes.

Resumen El caso de uso se inicia cuando el Técnico especialista del Dpto.

Control del Territorio decide realizar una operación sobre la unidad


45

edificatoria. Según su requerimiento podrá insertar, eliminar o

modificar unidad edificatoria para lo cual el sistema le mostrará y

actualizará respectivamente el registro de las mismas.

Concluyendo, así el caso de uso.

Precondiciones Para el Técnico especialista del Dpto. Control del Territorio pueda

eliminar o modificar alguna de las unidad edificatoria tiene que

asegurarse primero de que ésta exista, y si va a adicionar una

nueva debe asegurarse también de que ya no esté en la base de

datos y estar autenticado como tal en el sistema.

Referencias R1

Poscondiciones Las unidades edificatorias en el sistema se actualizan.

Requerimientos

especiales

-

Prototipo (Ver en Anexo 1 los prototipos de interfaz de usuario del caso de uso)

Caso de Uso Gestionar Desglose.



actualizar la información de los Desglose dentro de la base de

datos, ya sea eliminando, adicionando o modificando las tuplas

existentes.


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.


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


46

Poscondiciones Los Desgloses en el sistema se actualizan.

Requerimientos

especiales

-


Caso de Uso Gestionar Imágenes.



actualizar las imágenes dentro de la base de datos, ya sea

eliminando, adicionando o modificando las existentes.


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




eliminar o modificar alguna de las imágenes tiene que asegurarse

primero de que ésta exista, y si va a adicionar una nueva debe

asegurarse también de que ya no esté en la base de datos.

Referencias R4, R5, R6

Poscondiciones Las imágenes en el sistema se actualizan.

Requerimientos

especiales

El prototipo de este caso de uso esta ubicado en el prototipo de la

Unidad Edificatoria, en la opción imagen.

Caso de Uso Gestionar Calles.



actualizar las calles dentro de la base de datos, ya sea eliminando,

adicionando o modificando las existentes.


Control del Territorio decide realizar una operación sobre las calles.

Según su requerimiento podrá insertar, eliminar o modificar las


47

calles para lo cual el sistema le mostrará y actualizará

respectivamente el registro de las mismas, concluyendo así el caso

de uso.


eliminar o modificar alguna de las calles tiene que asegurarse

primero de que ésta exista, y si va a adicionar una nueva debe


Referencias R37

Poscondiciones Las calles en el sistema se actualizan.

Requerimientos

especiales

-


Caso de Uso Gestionar Valor.



actualizar los valores dentro de la base de datos, ya sea

eliminando, adicionando o modificando los existentes.



valores. Según su requerimiento podrá insertar, eliminar o

modificar los valores para lo cual el sistema le mostrará y




eliminar o modificar alguna de los valores tiene que asegurarse

primero de que éste exista, y si va a adicionar uno nuevo debe


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)


48

Caso de Uso Gestionar Carácter.



actualizar los caracteres dentro de la base de datos, ya sea




caracteres. Según su requerimiento podrá insertar, eliminar o

modificar los caracteres para lo cual el sistema le mostrará y




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

-


Caso de Uso Gestionar Transformaciones.



actualizar las transformaciones dentro de la base de datos, ya sea




transformaciones. Según su requerimiento podrá insertar, eliminar

o modificar las transformaciones para lo cual el sistema le mostrará

y actualizará respectivamente el registro de las mismas,


49

concluyendo así el caso de uso.


eliminar o modificar alguna de las transformaciones tiene que



datos.

Referencias R40

Poscondiciones Las transformaciones en el sistema se actualizan.

Requerimientos

especiales

-


Caso de Uso Gestionar Estado Constructivo.



actualizar los estados constructivos dentro de la base de datos, ya

sea eliminando, adicionando o modificando los existentes.



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.


eliminar o modificar alguna de los estados constructivos tiene que



datos.

Referencias R41

Poscondiciones Los estados constructivos en el sistema se actualizan.

Requerimientos

especiales

-



50

Caso de Uso Gestionar Época en los Desgloses.



actualizar las épocas de los desgloses dentro de la base de datos,

ya sea eliminando, adicionando o modificando los existentes.



épocas de los desgloses. Según su requerimiento podrá insertar,

eliminar o modificar las épocas para lo cual el sistema le mostrará




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

-


Caso de Uso Gestionar Época en las Unidad edificatoria.



actualizar las épocas de las Unidad edificatoria dentro de la base

de datos, ya sea eliminando, adicionando o modificando las

existentes.



épocas de las Unidad edificatoria. Según su requerimiento podrá

insertar, eliminar o modificar las épocas para lo cual el sistema le


51

mostrará y actualizará respectivamente el registro de las mismas,



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

-


Caso de Uso Gestionar Tipo de Planta.



actualizar los tipos de planta dentro de la base de datos, ya sea



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




eliminar o modificar alguna de los tipos de planta tiene que



datos.

Referencias R6

Poscondiciones Los tipos de planta en el sistema se actualizan.

Requerimientos

especiales

-


52


Caso de Uso Gestionar Tipo de Edificación.



actualizar los tipos de edificación dentro de la base de datos, ya

sea eliminando, adicionando o modificando los existentes.


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á




eliminar o modificar alguna de los tipos de edificación tiene que



datos.

Referencias R48

Poscondiciones Los tipos de edificación el sistema se actualizan.

Requerimientos

especiales

-


Caso de Uso Gestionar Barrio.



actualizar los barrios dentro de la base de datos, ya sea




barrios. Según su requerimiento podrá insertar, eliminar o modificar

los barrios para lo cual el sistema le mostrará y actualizará


53

respectivamente el registro de las mismas, concluyendo así el caso

de uso.


eliminar o modificar alguna de los barrios tiene que asegurarse



Referencias R46

Poscondiciones Los barrios en el sistema se actualizan.

Requerimientos

especiales

-


Caso de Uso Gestionar Portal.



actualizar los portales dentro de la base de datos, ya sea




portales. Según su requerimiento podrá insertar, eliminar o

modificar los portales para lo cual el sistema le mostrará y




eliminar o modificar alguna de los portales tiene que asegurarse



Referencias R45

Poscondiciones Los portales en el sistema se actualizan.

Requerimientos

especiales

-



54

Caso de Uso Mostrar unidad edificatoria por calles

Actores -

Propósito Una vez generados los reportes, es necesario mostrar las Unidad

edificatoria que pertenecen al tipo de reporte que se quiere

mostrar.

Resumen El caso de uso es iniciado por el caso de uso Generar Reporte o

alguno de los casos de uso extendidos que le pertenecen. Según

el tipo de reporte que se desea generar se busca en la base de

datos todas las Unidad edificatoria que correspondan con lo que se

desea mostrar, obteniéndose de estas los datos más relevantes y

mostrándose en el reporte. De esta manera termina el caso de uso.

Precondiciones Para que el caso de uso sea iniciado, es necesario que el Técnico

especialista del Dpto. Control del Territorio este autenticado en el

sistema como tal, y que el caso de uso sea llamado por el caso de

uso Generar Reportes.

Referencias R32

Poscondiciones Que las unidades edificatorias aparezcan en los reportes en los

reportes con sus respectivas calles.

Requerimientos

especiales

-

Caso de Uso Autenticar Usuario

Actores Usuario (Inicia)

Propósito Garantizar la autenticación de usuarios al sistema así como la

seguridad del mismo en cuanto a los niveles de acceso que tengan

a la información.

Resumen El caso de uso comienza cuando el usuario requiere autenticarse

al sistema, para lo cual suministra los datos necesarios. El sistema

verifica que sea usuario y en caso de no serlo se le comunica y

finaliza el caso de uso. Si es usuario del sistema le muestra, según

su nivel de acceso, la sección de trabajo a la que tiene permiso,

finalizando así el caso de uso.


55

Precondiciones Que el usuario esté registrado en el sistema con sus privilegios

asignados(Sea reconocido como Administrador de Sistema)

Referencias R35

Poscondiciones El sistema se personaliza para el usuario que se autenticó y a la (s)

sección (es) de trabajo a la que tiene acceso.

Requerimientos

especiales

-


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

-


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.


56

Resumen El caso de uso comienza cuando el Técnico especialista del Dpto.

Control del Territorio desea obtener un reporte sobre un inmueble

determinado. Para ello ofrece los datos necesarios para luego

obtener los inmuebles que se corresponden con los datos

suministrados consultando la base de datos y generar el reporte.

Este caso de uso debe ser capaz de calcular el por ciento que

representa la variable en cuestión del total existente en la base de

datos; así como la cantidad de éstas que hay. De esta forma

concluye el caso de uso.

Precondiciones Que el Técnico especialista del Dpto. Control del Territorio este

autenticado en el sistema; que los datos que se suministren estén

correctos y que se encuentren sus correspondencias en la base de

datos.

Referencias R7, Caso de Uso Mostrar unidad edificatoria por calles.

Poscondiciones Se muestra el reporte generado.

Requerimientos

especiales

-

Caso de Uso Generar Reporte por época de unidad edificatoria.

Actores -

Propósito Generar Reporte de Unidad edificatoria por épocas.

Resumen El caso de uso comienza cuando es invocado por Generar Reportes. Activado el caso de uso en cuestión, se le suministra la

época a la que se le desea obtener el reporte de sus Unidad

edificatoria, la que es validada y al verificarse que es correcta se

consulta la base de datos obteniendo los valores para generar el

reporte. Se calculan los por cientos que representan estas unidad

edificatoria del total y la cantidad y se muestra luego el reporte,

concluyendo el caso de uso.

Precondiciones Que se haya llamado al caso de uso Generar Reportes.



Requerimientos -


57

especiales

Caso de Uso Generar Reporte por época de los desgloses.

Actores -

Propósito Generar Reporte por época de los desgloses.


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




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.





58

Requerimientos

especiales

-

Caso de Uso Generar Reporte de los usos por categorias.

Actores -

Propósito Generar Reporte de los usos agrupados por cada uso de red al

cual pertenece.


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.




Requerimientos

especiales

-

Caso de Uso Generar Reporte con caracter.

Actores -

Propósito Generar Reporte de Unidad edificatoria con carácter.


específica del menú generar reportes con carácter, se consulta la

base de datos obteniendo los valores para generar el reporte. Se



caso de uso.

Precondiciones Que el se haya llamado al caso de uso Generar Reportes.



59


Requerimientos

especiales

-

Caso de Uso Generar Reporte de Estado Constructivo,

Actores -

Propósito Generar Reporte de Estado Constructivo.


específica del menú generar reportes de Estado Constructivo, se








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.


específica del menú generar reportes de los usos por redes, se








60


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








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.




61


Requerimientos

especiales

-

Caso de Uso Generar Reporte de los Desgloses.

Actores -

Propósito Generar Reporte de todos los desgloses.


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.




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.


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


62






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






Requerimientos

especiales

-

Caso de Uso Generar Reporte de Unidad edificatoria modificadas.

Actores -

Propósito Generar Reporte de todas las Unidad edificatoria modificadas.


generar reportes y se pide esta opción, la que es validada y al



63







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








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


64








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.


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



caso de uso.




Requerimientos

especiales

-



65

Caso de Uso Generar Reporte de Unidad edificatoria con categoría C1...C3.

Actores -

Propósito Generar Reporte de todas las Unidad edificatoria con tipología

C1…C3.


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








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





66



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








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



67







Requerimientos

especiales

-

Caso de Uso Búsquedas libres.

Actores Técnico General.

Propósito Buscar las variables según los parámetros deseados.

Resumen El caso de uso comienza cuando se desea buscar los elementos

que se encuentran en la Base de Datos según parámetros dados.

Se suministran los valores a los parámetros y luego se consulta la

base de datos obteniendo las tuplas deseadas, y de esta manera

termina el caso de uso.

Precondiciones Que se encuentren las unidades edificatorias con estos datos.

Referencias R34

Poscondiciones -

Requerimientos

especiales

Se necesita una velocidad grande para efectuar las consultas y

que la espera no sea demasiado larga.


Caso de Uso Obtener grado de protección.


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.


68

Precondiciones Que se encuentren los grados de protección en la BD.

Referencias R35

Poscondiciones -

Requerimientos

especiales

-


Caso de Uso Obtener categorías predefinidas.


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.


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


69

Poscondiciones -

Requerimientos

especiales

-

Prototipo (Ver en Anexo 18 los prototipos de interfaz de usuario del caso de uso.)

3.8 Diagrama de casos de usos del sistema. El diagrama de Caso de Uso del sistema esta encapsulado en tres paquetes, uno para

las Búsquedas, uno para los Reportes y otro para Gestionar las variables del sistema.

Además de otros casos de uso que interactúan con sus respectivos actores. De este

análisis realizado sale como resultado el siguiente Diagrama de Casos de Uso del

Sistema. (Ver anexo 20- 23)

3.9 Conclusiones. En el presente capítulo, y sobre la base de la propuesta de RUP para el desarrollo de

software, se realizó una modelación del negocio donde se pudo comprender la

estructura de las oficinas del Centro Histórico de Camagüey así como los problemas

actuales existentes, y se determinaron las mejoras potenciales que puede aportar, al

negocio, el sistema a desarrollar. Como resultado del proceso anterior se obtuvo un

diagrama de casos de uso del negocio donde se identificaron los actores del negocio y

casos de uso del negocio así como las relaciones entre los mismos.

Este capítulo contempla la captura de los requerimientos del sistema. La entrada

principal para este flujo de trabajo la constituye la modelación del negocio realizada,

obteniendo del mismo el conjunto de funcionalidades que debe desarrollar el sistema.

En este flujo se definió un grupo de paquetes y para cada uno se muestra el diagrama

de casos de uso del sistema con los actores del sistema, casos de uso del sistema y

relaciones entre ellos, así como una descripción en formato de alto nivel y los prototipos

de interfaz de usuario de cada caso de uso

Capitulo IV Construcción de la Solución Propuesta. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

70

CCOONNSSTTRRUUCCCCIIÓÓNN DDEE LLAA SSOOLLUUCCIIÓÓNN PPRROOPPUUEESSTTAA

4.1 Introducción. El presente capitulo recoge todo el flujo de diseño e implementación, es decir se expone

la construcción de la solución propuesta.

En el diseño, el sistema es modelado y se conforma para que soporte todos los

requisitos que se le suponen, adquiriendo una comprensión en profundidad de los no

funcionales, restricciones relacionadas con el lenguaje de programación a utilizar,

componentes reutilizables, entre otros. [Jacobson, 2000]. Para este flujo de trabajo se

presenta primeramente el diagrama de clases del diseño agrupado según los casos de

usos, se modelan los nodos sobre los cuales se distribuye la aplicación mediante el

modelo de despliegue, se presenta el diagrama de clases persistentes y el de modelo

de datos, obtenido a partir de este ultimo.

La implementación, por su parte, toma los resultados del diseño e implementa el

sistema en términos de componentes. [Jacobson, 2000]. Se ha modelado el diagrama

de componentes, además se hace referencia a los estándares de programación y

diseños de interfaz que se siguen, y de forma general la política de seguridad bajo la

que se debe regir la implantación del sistema.

C a p í t u l o

4


71

4.2 Modelo de Diseño. El modelo de diseño es un modelo de objetos que describe la realización física de los

casos de uso centrándose en cómo los requisitos funcionales y no funcionales, junto

con otras restricciones relacionadas con el entorno de programación, tienen impacto en

el sistema a considerar, siendo una entrada fundamental para las actividades de

implementación. [Jacobson, 2000].

4.3 Diagrama de Clases. Para la elaboración del diagrama de clases se organizo por paquetes de las capas de

programación, el Paquete Common, Paquete Acceso a Datos, Paquete Lógico de

Datos, Paquete Interfaz de Usuario. (Ver anexo 24 - 28)

4.4 Diagrama Modelo de Datos. Las entidades mostradas en este diagrama, obtenidas después de la normalización,

donde se tienen entidades débiles de otras, tal es el caso de la entidad época de las

Unidad edificatoria que es una entidad débil de Época, desgloses que es una entidad

débil de la Unidad edificatoria, otro caso es el de los usos donde hay dos relaciones de

entidades débiles. (Ver anexo 29)

4.5 Diagrama de Clases Persistentes. En el sistema se generan documentos que no serán destruidos, solo quedaran

archivados como material de consulta, tal es el caso de los reportes generados. (Ver

anexo 30)

4.6 Principios de Diseño. El diseño ha sido elaborado pensando en los usuarios finales, que serán: técnicos

especialistas en los datos que se manejaran en el software, pero que poseen, no en

todos los casos, conocimientos mínimos de computación, por tanto, se ha elegido una

interfaz amigable e intuitiva. Se ha mantenido un diseño consistente en todas las

formas, para lograr que el usuario se sienta cómodo y logre acostumbrarse rápidamente

a la aplicación.


72

4.6.1 Estándares de Codificación. Hoy día se hallan estándares de codificación para aplicaciones desarrolladas en la

mayoría de las plataformas existentes. Estos definen un conjunto de convenciones a ser

aplicadas por los programadores, que les permiten generar código más comprensible y

fácil de mantener en menos tiempo.

Resulta ventajoso utilizar un estándar para escribir código, entre dichas ventajas,

tenemos las siguientes:

1. Reducir errores

2. Escribir un código comprensible y fácil de leer.

3. Garantizar una buena comunicación entre los programadores del equipo.

4. Facilitar el mantenimiento del software.

En el diseño de la base de datos, las tablas se han nombrado igual que la entidad que

almacenan. Los campos de estas tablas, siguen la misma regla, y están nombrados

igual que las propiedades de las entidades.

Se ha tenido especial cuidado para nombrar clases, variables, y demás elementos,

precediendo cada nombre con un prefijo para su fácil identificación.

Un código fuente completo debe reflejar un estilo armonioso, como si un único

programador hubiera escrito todo el código de una sola vez. Al comenzar un proyecto

de software, establezca un estándar de codificación para asegurarse de que todos los

programadores del proyecto trabajen de forma coordinada.

La legibilidad del código fuente repercute directamente en lo bien que un

programador comprende un sistema de software. La mantenibilidad del código es la

facilidad con que el sistema de software puede modificarse para añadirle nuevas

características, modificar las ya existentes, depurar errores, o mejorar el rendimiento.

Aunque la legibilidad y la mantenibilidad son el resultado de muchos factores, una

faceta del desarrollo de software en la que todos los programadores influyen

especialmente es en la técnica de codificación. El mejor método para asegurarse de

que un equipo de programadores mantenga un código de calidad es establecer un

estándar de codificación sobre el que se efectuarán luego revisiones del código de

rutinas.


73

4.6.2 Formato de los Reportes. El formato de los reportes, es legible para el usuario, con los campos necesarios para la

comprensión de lo que el usuario desea, los colores dentro del reporte son claros, con

una letra clara y de tamaño adecuado a la hoja en la cual se va a imprimir, los campos

están organizados por columnas dentro del reporte con nombres conocidos por el

usuario que trabajara con ellos. Un ejemplo que ilustra el formato de estos reportes es

el que se muestra a continuación:

4.6.3 Concepción General de la Ayuda. Puesto que esta destinada una gran variedad de usuarios, el diseño debe ser a la ves

sencillo, atractivo, y de una fácil usabilidad. Por otra parte el módulo de administración

no debe ser muy complejo de manipular.

Para la implementación del sistema no se siguió una estándar conocido pero se

planifico una guía a la hora de escribir el código con el objetivo de


74

1. Reducir los errores.

2. Garantizar la obtención de un código claro y comprensible.

3. Garantizar una buena comunicación entre los programadores del equipo.

4. Facilitar el mantenimiento del software.

5. Facilitar la implementación del sistema por otro equipo de trabajo.

4.6.4 Tratamiento de excepciones. El sistema trata de minimizar al máximo los posibles errores que puedan existir, para

ello se decidió:

- En el caso de los datos introducidos por los usuarios, se trata que los usuario no tenga

que teclear la información, sino que el usuario pueda seleccionar la información y en

caso contrario se hace una validación utilizando las facilidades que brinda C# y la

plataforma .Net para la validación de datos entrados por los formularios.

- A la hora de realizar operaciones de modificación o eliminación de elementos, se

muestra los mismos en una lista donde el usuario pueda seleccionar los mismos. De

esta manera siempre serán válidos los datos de entrada.

Excepciones del sistema:

Cuando el usuario se va a autenticar en el sistema, se verifica que coincidan el usuario

y la contraseña.

Cuando se va a insertar algún valor en las tablas de la base de datos que ya existe

captura una excepción no permitiéndole al usuario duplicar los identificadores de las

tablas permitiéndole al usuario.


75

Cuando se va a conectar la aplicación con el servidor SQL y este no se encuentra en

ejecución.

Cuando se crea un nuevo usuario y la contraseña no es la misma en las dos ocasiones

que la piden:

Al ocurrir una de estas excepciones se manipulan con las posibilidades que nos brinda

el lenguaje utilizado, mostrando al usuario una información correcta y explicativa sobre

el posible error cometido.

Además los mensajes de advertencia, de errores, de seguridad, tienen un contenido

legible, fácil de comprender, y de orientación al usuario. Ejemplo:


76

4.7 Modelo de Despliegue. El modelo de despliegue es un modelo de objetos que describe la distribución física del

sistema en términos de cómo se distribuyen la funcionalidad entre los nodos del

computo. El modelo de despliegue se utiliza como entrada fundamental en la

actividades de diseño e implementación debido a que la distribución del sistema tiene

una influencia principal en su diseño [Jacobson, 2000]. (Ver anexo 31)

4.8 Modelo de Implementación. El modelo de implementación describe cómo los elementos del modelo de diseño, como

las clases, se implementan en términos de componentes. Describe también cómo se

organizan los componentes de acuerdo con los mecanismos de estructuración

disponibles en el entorno de implementación y en el lenguaje o lenguajes de

programación utilizados, y cómo dependen los componentes unos de otros. [Jacobson,

2000].

4.8.1 Diagrama de Componentes. Un componente se puede definir como el empaquetamiento físico de los elementos de

un modelo, como son las clases en el modelo de diseño. [Jacobson, 2000] .El diagrama

de los componentes que participan en la ejecución del presente sistema se muestra con

cada uno de sus paquetes, el Paquete Interfaces, el Paquete Lógica del Negocio y el

Paquete Acceso a Datos. (Ver anexos 32 - 36)

4.9 Conclusiones. En el presente capítulo se han desarrollado los flujos de trabajo de diseño e

implementación que propone RUP, modelándose un grupo de artefactos en cada uno

de ellos. Como resultado de este capítulo se obtuvo el diagrama de clases del sistema.

Es importante señalar que UML (Lenguaje Unificado De Modelado) permite a los

desarrolladores visualizar los resultados de su trabajo en esquemas o diagramas

estandarizados. Se modelaron los nodos en los que se distribuye la aplicación. Se


77

muestra además el diagrama de clases persistentes a partir del cual se obtuvo el

modelo de datos señalando las consideraciones que se tuvieron en cuenta en dicho

proceso. El modelo de datos fue representado elaborando una descripción de cada

tabla de la base de datos. Como parte de la implementación fue elaborado el diagrama

de componentes en los que se estructura la aplicación. Para mayor claridad en cuanto a

los componentes se muestra una tabla descriptiva de cada uno. Este capítulo, además,

presentó los estándares de programación y de diseño de interfaz que se siguen para el

desarrollo del sistema, así como las medidas de seguridad a tener en cuenta.

Capitulo V Estudio de Factibilidad. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

78

EESSTTUUDDIIOO DDEE FFAACCTTIIBBIILLIIDDAADD

5.1 Introducción. Resulta de vital importancia conocer, desde los primeros momentos del desarrollo de un

software, los beneficios que este aporta en todos los sentidos con el objetivo de

determinar si su implementación resulta factible o no. Con este estudio se determinarán,

además, parámetros que ayudan a planificar el trabajo a realizar en cuanto a cantidad

de personas que se necesitan y estimar el tiempo de duración del mismo teniendo en

cuenta el tamaño del sistema, experiencia en otras aplicaciones del mismo tipo,

reusabilidad, características de la plataforma a utilizar, trabajo en equipo, entre otros

aspectos.

5.2 Planificación. En esta primera etapa de la técnica, se definen cinco tipos de funciones de usuario y se

clasifican según su complejidad. Estas funciones son: entradas de usuario al sistema

que aportan datos a la aplicación, salidas de usuario que le brindan a éste información

de la aplicación, peticiones de usuario, ficheros lógicos internos y ficheros o interfaces

externas que en este sistema no existen. [De la Fuente, 1999] La clasificación que se

realiza de cada función es en simple, media o compleja.

C a p í t u l o

5


79

Nombre de la entrada externa

Cantidad de Ficheros

Cantidad de Elementos de datos

Clasificación (Simple, Media y compleja)

Autenticación. 1 2 Simple

Adicionar Unidad Edificatoria.

1 28 Medio

Eliminar unidad Edificatoria.

1 28 Medio

Adicionar Desgloses. 1 29 Medio Eliminar Desgloses 1 29 Medio Adicionar calles 1 2 Simple Eliminar calles. 1 2 Simple Adicionar valor 1 2 Simple Eliminar valor 1 2 Simple Adicionar carácter 1 2 Simple Eliminar carácter 1 2 Simple Adicionar barrio 1 2 Simple Eliminar barrio 1 2 Simple Adicionar transformaciones

1 2 Simple

Eliminar transformaciones 1 2 Simple Adicionar usos 3 8 Medio

Eliminar usos. 3 8 Medio

Adicionar épocas 2 6 Medio Eliminar épocas 2 6 Medio Adicionar estado constructivo.

1 2 Simple

Eliminar estado constructivo

1 2 Simple

Adicionar tipo de planta 1 2 Simple

Eliminar tipo de planta 1 2 Simple Adicionar tipo de edificación

1 2 Simple

Eliminar tipo de edificación

1 2 Simple

Tabla1. Entradas externas

Nombre de la salida externa

Cantidad de Ficheros

Cantidad de Elementos de datos


Listado de las Unidades Edificatorias.

1 2 Simple


80

Listado de los Desgloses. 1 3 Simple Listado de las calles. 1 2 Simple Listado de los estados constructivos.

1 2 Simple

Listado de la épocas de las unidades edificatorias.

1 2 Simple

Listado del portal. 1 2 Simple Listado del tipo de edificación.

1 2 Simple

Listado del tipo de planta. 1 2 Simple Listado de las transformaciones.

1 2 Simple

Listado del uso. 1 2 Simple Listado del valor. 1 2 Simple Listado del barrio. 1 2 Simple

Listado del carácter. 1 2 Simple Tabla 2. Salidas Externas Nombre de la petición Cantidad de

Ficheros Cantidad de Elementos de datos


Obtener Unidades Edificatorias dada una o varias variables.

1 2 Simple

Obtener Categorías predefinidas

1 2 Simple

Obtener grados de Protección.

1 3 Simple

Obtener Grados de Protección predefinidos.

1 2 Simple

Tabla 3. Peticiones Nombre del fichero interno Cantidad

de record Cantidad de Elementos de datos


Tabla Unidad Edificatoria 1 28 Medio Tabla Desgloses. 1 29 Medio Tabla Calles. 1 3 Simple Tabla Valor. 1 2 Simple Tabla Carácter. 1 2 Simple Tabla Época de las Unidades edificatorias.

1 2 Simple

Tabla Época de los Desgloses.

1 5 Simple

Tabla Barrios. 1 2 Simple Tabla Estado Constructivo. 1 2 Simple Tabla Portal. 1 2 Simple Tabla Tipo de Edificación. 1 2 Simple


81

Tabla Tipo de Planta. 1 2 Simple Tabla Transformaciones. 1 2 Simple Tabla Uso por Redes. 1 2 Simple Tabla Uso por Categorías. 1 5 Simple Tabla Uso unidad Edificatoria de Inf. Territorio.

1 3 Simple

Tabla eje 1 2 Simple Tabla nodo 1 2 Simple Tabla rol 1 2 Simple Tabla usuario 1 3 Simple Tabla 4. Ficheros Internos Elementos Simples Medios Complejos Subtotal de puntos de

función No X Peso No X Peso No X Peso Ficheros lógicos internos

18 7 2 10 0 15 146

Entradas externas 17 3 8 4 0 6 83 Salidas externas 13 4 0 5 0 7 52 Peticiones 4 3 0 4 0 6 12 Total 293

Tabla 5. Puntos de función desajustados. 5.2 Costos.

Características Valor Puntos de función desajustados 293 Lenguaje C# (80 %)

SQL (20%) Instrucciones fuentes por puntos de función (59)

(39) Instrucciones fuentes por lenguaje (miles de instrucciones) (14,694)

(1,7141)

Instrucciones fuentes (miles de instrucciones) 16,41 Tabla 6. Cantidad de Instrucciones Fuentes Factores Valor Justificación

PREC 4,96 Este sistema presenta un análisis y diseño que lo hace totalmente diferente.


82

FLEX 3,04 Existe cierta flexibilidad entre los analistas del sistema, los programadores y el cliente.

TEAM 3,29 Los miembros del equipo que desarrollan el software son altamente cooperativos, con poca experiencia en los compromisos.

RESL 4,24 Existen riesgos críticos, que son identificados, generalmente con la tecnología, la misión de la empresa, interfaz con el usuario y el desempeño de los programadores. Para estos riesgos se traza un plan de acción.

PMAT 6,24 El sistema presenta un nivel de madurez alto.

Tabla 7. Factores de escala

Cálculo de: Valor Justificación Esfuerzo 81,53 ΠEMi ≈ 1,69

E ≈ 1,13 ∑SFi = 21,77 PREC = 4,96 FLEX = 3,04 RESL = 4,24 TEAM = 3,29 PMAT = 6,24

Tiempo de desarrollo 15 meses PM ≈ 81,53 F ≈ 0,32

Cantidad de personas 5 Se necesita 5 personas para la realización del sistema.

Costo 91 721,25 C =CHM * PM CHM = 5 * 225 = 1125 PM ≈ 81,53

Salario medio 225 El salario mínimo es de 225 pesos.

RCPX 1,00 RELY = BASICO

DOCU = ALTO

CPLX = ALTO

DATA = NOMINAL

RUSE 1,00 Existe concordancia entre la documentación y las necesidades del ciclo de vida.

PDIF 1,00 El .NET es una plataforma estable, no hay restricciones fuertes de memoria o tiempo


83

nominal

PREX 1.00 Los desarrolladores tienen buena experiencia en la plataforma y herramientas de desarrollo. Lleva 1 año.

FCIL 0,87 Se hace un uso notable de herramientas CASE para documentar implementar el sistema.

SCED 1,00 Las exigencias para el cumplimiento de cronograma son normales.

PERS 0,83 ACAP = ALTO

PCAP = ALTO

PCON = ALTO

Tabla 8. Cálculos Finales de La Estimación de Costos y Esfuerzos.

5.3 Beneficios tangibles e intangibles. 5.3.1 Beneficios tangibles. No es un software con fines comerciales, aunque puede ampliarse con estos fines,

adaptarse a otras empresas u organismos que trabajen con datos del patrimonio

histórico-arquitectónico de la ciudad de Camagüey, además puede ser empleado en

otras ciudades del país.

Los beneficios tangibles que se observan con esta aplicación en la empresa son, una

reducción en el costo telefónico, en los recursos materiales que se empleaban para

archivar toda la información de los inmuebles de la ciudad, además del costo por

empleados que debían tener para poder satisfacer las necesidades del cliente.

En cuanto al tiempo de demora en la realización de los trámites, si se compara como se

realizan actualmente los trámites.


84

El tiempo que se toma un técnico especialista para realizar una búsqueda con el

sistema propuesto es mucho menor, ahora solo tiene que pedirle al sistema que lo que

desea, no tiene que realizar la búsqueda manual en los grandes archivos que existen en

el centro histórico de Camagüey, a esto se suma que ya el cliente no tendrá que

trasladarse hasta el inmueble que desee observar, si no que el propio sistema le

mostrara un a imagen del mismo. Así se gana en tiempo, y no tienen el riesgo de perder

al inversionista por la demora en la respuesta que debe recibir. El sistema brinda la

posibilidad de realizar las búsquedas por múltiples conceptos, facilitando la localización

de la información necesitada de forma eficiente.

Es apreciable la disminución del tiempo de respuesta al usuario para la realización de

un trámite, estimándose se invierta sólo la cuarta parte del tiempo que se invertía

anteriormente llenando todos los modelos, buscando en los archivos, haciendo

cruzamientos de las variables patrimoniales.

5.3.2 Beneficios intangibles. Por otra parte, con la puesta en práctica de este sistema se logra centralizar la

información de todos los inmuebles del centro histórico de la ciudad de Camagüey, lo

cual se traduce en una disminución notable de los errores que se cometen en los

valores de cada una de las variables. De igual forma se simplificará el trabajo de los

técnicos especialistas y se creará una nueva y rápida vía de comunicación entre todas

las oficinas, así como de actualización y búsqueda de información.

5.4 Análisis de costos y beneficios. El desarrollo de este sistema no supone grandes gastos de recursos, ni tampoco de

tiempo; la base de datos que contiene la información, puede ser alojada en un servidor

central. La tecnología utilizada para el desarrollo del sistema es .NET, que es gratis. El

sistema se ha diseñado pensando en los usuarios, en un fácil aprendizaje, no hay que

incurrir en gastos de contratar a un especialista del sistema para educar a los

trabajadores en el empleo del mismo.


85

El gasto radica más bien en la compra de un nuevo equipamiento tecnológico para las

oficinas del centro histórico, ahora toda la información estará almacenada en la base de

datos, y se tendrá acceso a ella a través de los técnicos especialista de la empresa.

Se investigaron otras soluciones existentes sobre el almacenamiento de todas las

variables de los inmuebles, y se llegó a la conclusión de que no se ajustan a las

características del entorno de la ciudad, además podría resultar muy costoso invertir en

ellas para después adaptarlas a las condiciones de la ciudad.

El sistema puede ser extendido para uso general, obteniéndose un producto

comercializable que puede ser fuente de ingresos.

El costo del sistema asciende a un total de 91 721,25 pesos, a pesar del precio se

considera que va aprestar muchos beneficios para el centro histórico de Camagüey, y

para la ciudad en su conjunto.

5.5 Conclusiones. Del estudio realizado anteriormente, y a partir del análisis de los beneficios, tanto

tangibles como intangibles, se concluye que es factible el desarrollo de esta aplicación,

por todos los aportes económicos y sociales que brinda.

Conclusiones. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

86

CCoonncclluussiioonneess..

Con la implantación exitosa del sistema, se dará solución a los problemas actuales

existentes en las oficinas del Centro Histórico de la Ciudad de Camagüey, lo cual

implica un mejoramiento en el servicio que se ofrece a los usuarios, en las condiciones

de trabajo de los técnicos, en la comunicación entre las distintas oficinas, así como una

reducción de costos relacionados con los recursos materiales empleados para realizar

anteriormente los servicios.

Se ha puesto en práctica una solución con un diseño y una implementación fácil de

manipular por los usuarios y futuros programadores que puedan darle mantenimiento al

sistema.

El desarrollo del sistema se ha basado en el Proceso Unificado de Desarrollo de

Software, como parte de lo cual se realizó una modelación del negocio con vista a

entender el contexto donde se va a implantar el sistema y se presentó un grupo de

artefactos para los flujos de trabajo de requisitos, diseño e implementación que propone

dicho proceso.

Con los beneficios expuestos, tanto tangibles como intangibles, se determinó que el

desarrollo de la aplicación es realmente factible, siendo indudable la revolución que

experimentará este servicio en nuestro país y en especial en la Ciudad Agramontina.

Recomendaciones. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

87

RReeccoommeennddaacciioonneess..

Se recomienda la puesta en práctica del sistema en las oficinas del Centro Histórico de

la ciudad de Camagüey en el menor tiempo posible con vista a facilitar el trabajo en las

mismas.

Es importante elevar el software a una nueva versión que perfeccione sus

funcionalidades con elementos que surjan en la fase de explotación del mismo.

Una recomendación imprescindible lo constituye el asegurarse que, para la puesta en

marcha del sistema, se tomen las medidas de seguridad expuestas debido a la

importancia de la integridad de la información que se maneja.

Se continúe con el programa de informatización de la sociedad que prevé la cercanía de

la población a los servicios que ofrecen los diferentes sectores, lo cual se traduce en

satisfacción de los ciudadanos.

Referencias Bibliograficas. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

88

RReeffeerreenncciiaass BBiibblliiooggrrááffiiccaass..

[De la Fuente, 1999] De la Fuente Moya, Antonio. Cómodo v.2 “Modelo de estimación

de costes para proyectos de software”. Mayo 1999. [Fecha de consulta: 11 de abril de

2005] Disponible en: \\ceis\Clases\pregrado\4to\1er semestre\Ingenieria de Software

I\Curso 03-04\06 Planificación y Estimación

[Información sobre Bases de Datos]Historia de los sistemas de bases de datos, V [Fecha de consulta 15 de mayo 2005] Disponibles en: http://www3.uji.es/~mmarques/f47/apun/node6.html. (14/02/2004).

http://www3.uji.es/~mmarques/f47/apun/node39.html. (14/02/2004)

[Inei, 2004] Arquitectura Cliente Servidor. [Fecha de consulta: 16 de febrero de 2005]

Disponible en: http://www.inei.gob.pe/cpimapa/banco pub/libfree/lib616/cap0302.htm

[Jacobson, 2000] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. “El Proceso

Unificado de Desarrollo de Software”. 2000. Addison Wesley.

[Leyton, 2000] Leyton Eduardo: “Ingeniería de software con UML. Auditorias de

tecnología de la información. [Fecha de consulta: 5 de abril de 2005]. Disponible en:

http://www.eduardoleyton.com/Uml.pdf

MIC-Informatización, 2004] Ministerio de la Informática y las Comunicaciones de Cuba.

“Informatización de la Sociedad”. [Fecha de consulta: 10 de mayo de 2005] Disponible

en: http://www.mic.gov.cu/sitiomic/hinfosoc.asp

[Sariol, 2004] Sariol Hernández, Elvira. “Sistema de indicadores y variables

patrimoniales, arquitectónicas y urbanas para el manejo de las potencialidades del

cambio de uso en los inmuebles del Centro histórico de Camagüey.”. Tesis en opción

del título de maestría en Conservación del Patrimonio Edificado. Camagüey. Julio 2004.

Referencias Bibliograficas. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

89

[Tutorial de C#, 2003] Introducción al lenguaje C#. [Fecha de consulta 10 de junio 2005]

Disponible en: http://www.microsoft.com/C#.pdf

[Tutorial de .NET]Características de Visual Studio .NET. Microsoft Corp. 2005. [Fecha

de consulta 5 de abril 2005] Disponible en

http://www.microsoft.com/latam/vstudio/producto/caracteristicas.pdf

Bibliografía. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

90

BBiibblliiooggrraaffííaa..

• Arquitectura Cliente/Servidor http://www.inei.gob.pe/cpi-mapa/bancopub/libfree/lib616/cap0301.HTM (11/5/2005)

• Curso de iniciación a la programación con c#. pdf.

• Elvira Sariol Hernández. Sistema de indicadores y variables patrimoniales,

arquitectónicas y urbanas para el manejo de las potencialidades del cambio de

uso en los inmuebles del Centro histórico de Camagüey.”. Tesis en opción del

título de maestría en Conservación del Patrimonio Edificado. Camagüey. Julio

2004.

• Object Management Group. Unified Modeling Language Specification. V1.5.

Marzo 2005.

• Rumbaugh, J.; Jacobson, I. y Booch, G.; “El Lenguaje Unificado de Modelado. Manual de Referencia. 2000. Addison-Wesley.

AUTORES - Ing.Yanesky Montero Martínez. Universidad de las Ciencias Informaticas, Cuba. e-mail: [email protected] - Ing. Yorlenis Dominguez Núñez. Departamento Gestion Hotelera. Escuela de Hoteleria Turismo Santa Lucia , Cuba e-mail: [email protected]

Bibliografía. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

91

Glosario de Términos. DUAC ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯

92

GGlloossaarriioo ddee TTéérrmmiinnooss..

Termino. Concepto Accesos Acceso principal:

Ubicación del acceso principal del inmueble. Acceso secundario: Caracteriza al inmueble por la presencia de un acceso secundario

Áreas Área de parcela: Área de lote: Área construida: Área construidas en primer nivel. Área ocupada: Área total útil construida que posee el edificio.

Carácter Excepcional: Cuando está considerado como edifico único, raro, exponente máximo de una época o estilo. Relevante: Cuando representa un edificio de gran importancia porque sus significados ilustran aspectos importantes de la obra, tales como función y sistema constructivo, entre otros. Representativo o típico: Cuando se considera un edificio común de su época o estilo, cuyas características pueden observarse en otros de su mismo origen. Armónicos con elementos típicos: Cuando se trata de edificios pobres estéticamente o que han perdido sus valores por transformaciones sufridas pero conservan aún algunos elementos de valor. Armónicos: Cuando no rompen con el conjunto en el que se ubican Inarmónicos: Edificios sin valores que rompen la imagen visual del conjunto.

Categoría tipológica

El grupo de edificios que mantienen características esenciales del tipo, diferenciándose en una variable no esencial. Siguiendo ese principio se hace una individualización de tipos arquitectónicos por medio de análisis de las características estructurales, dimensiónales y distributivas (organización espacial) y las necesidades de uso (organización funcional). El conjunto físico del centro histórico se dividió en tres categorías tipológicas que ofrecen una base, lo más rigurosa posible, en lo que respecta a la refuncionalización y utilización de los edificios(A, A1, A2, A3, B1, B2, B3, B4, C1, C2, C3)

Eje La senda que, caracterizada por el papel desempeñado en un momento histórico, resulta contenedora de fuerza identitaria, la calle vehicular y peatonal con potencial de movimiento. Dentro de los ejes urbanos se denominan principales o claves, aquellos que portan identidad singular que las distingan de los canales circundantes por una concentración de uso o una actividad especial a lo largo de su márgenes, una cualidad espacial característica, una textura especial de piso o fachada, un trazado particular de alumbrado, un conjunto singular de olores o sonidos, un detalle típico o un modo de arbolado.

Estado constructivo

Ruinoso: Edificio en alto grado de deterioro, La cubierta esta seriamente afectada, Esta en peligro la estabilidad del mismo.


93

Malo: Edificio en alto grado de deterioro, La cubierta esta afectada, No peligra la estabilidad del mismo. Regular: Edificio con deterioros importantes, el estado de la cubierta permite filtraciones. Requiere reparaciones importantes que interesan la estructura del mismo Bueno: Edificio en buen estado técnico que solo requiere medianas y pequeñas reparaciones.

Fachada a plaza Caracteriza la relación directa del inmueble con una plaza.

Grado de protección

Indicadores de la categoría cultural de los inmuebles que integran un conjunto urbano de valor histórico-cultural.(I, II, III, IV)

indicadores Patrones a seguir, los mismos pueden variar en dependencia de cada región a estudiar y expresan la forma de manifestarse los elementos de mayor significación por períodos reflejando el comportamiento de cada uno de estos, desde el punto de vista evolutivo

Lote Estratigrafía de la parcela tradicional, considerando como unidad del lote la porción o parte de la unidad edificatoria que, desde el punto de vista jurídico —Registro de la propiedad— funciona como entidad independiente. Bajo este criterio la sumatoria de los lotes conforma la parcela tradicional con su correspondiente unidad edificatoria.

Longitud de la fachada

Ancho de fachada del inmueble.

Manzana Unidad básica de información territorial (UBIT) y se corresponde con la tradicional concepción de un área delimitada por ejes viales o elementos naturales.

Nodo Los focos estratégicos a los que puede entrar el observador, tratándose típicamente de confluencias de sendas o de concentraciones de determinadas características. Serán nodos principales aquellos que históricamente determinaron un recorrido cultural en la ciudad; mientras que los secundarios serían aquellos que, por ser formalmente pequeños y jugar un papel colateral en las tradiciones de los habitantes de la ciudad, resultan contenedoras de funciones socioculturales de secundarias.

Parcela Punto de partida los resultados acerca del estudio de la cuadrícula en América, sello identitario del proceso de poblamiento, que indica que el modelo de ciudad incluye una forma típica de parcelación consistente en dividir las manzanas en cuatro partes cuadradas iguales

Parcelación Se utiliza en su carácter histórico, es decir, el espacio de terreno que, perteneciente a una manzana, se corresponde con el área en la cual quedó emplazada la unidad edificatoria

Potencial de uso Funciona como un registro que detalla el uso de suelo de cada inmueble y que pueden recuperarse para nuevas inversiones, este contempla los locales vacíos subutilizados o explotados por un uso agresivo, siendo susceptibles de ser refuncionalizados. El uso del suelo juega un papel “regenerador, catalizador, e integrador del desarrollo” de ahí que deban fijarse oportunamente las pautas a seguir dentro de las políticas de intervención urbana, máxime si en el caso cubano se ha heredado el enfoque de Uso y no el de valor del suelo. En la actualidad se trata de lograr la optimización económica, financiera, social y ambiental con los recursos disponibles.

Puntal Altura mayor que alcanza el edificio en fachada.

Tiene galería Caracteriza el inmueble partir de la presencia o no de galería.

Tiene portal (publico o privado)

Caracteriza el inmueble a partir de la presencia o no del portal.

Tipo de planta Rectangular, cuadrada, U, C, L, trapezoidal

Transformaciones Sin transformar: Edificio que no tiene añadidos desvalorizantes La estratificación puede estar presente armónicamente. Transformación reversible: Edificios que han sufrido cambios inadecuados que se pueden revertir.


94

Transformación irreversible: Edificios que han sufrido cambios inadecuados que no se pueden revertir

Unidad edificatoria

La construcción que por sus elementos y propiedades mantiene una unidad armónica en relación con su valor patrimonial, unidad básica en el patrimonio edificado para la intervención a escala urbana en el centro histórico.

uso Baldío: Terreno sin construir. Sin uso: Edificio que no está en uso por diferentes razones funcionales o técnicas, de propiedad, etc. Industria: Dedicado a funciones productivas industriales Talleres: Dedicado a funciones productivas ligeras. Administrativo: Dedicados a funciones de organización, planificación y dirección. Salud: Servicios de salud en los diferentes niveles. Educación: Edificios dedicados a la función educacional Servicios: Cuya función es ofrecer servicios de diferente tipo Comercio MN: Red comercial en moneda nacional Comercio MLC: Red comercial en dólares. Alojamiento: Instalación pública o privada que ofrezca alojamiento. Cultura: Servicios culturales Gastronómico: Edificios dedicados a la función de restauración Deporte: Instalaciones deportivas Vivienda: Edificios residenciales Mixto: Edificios que combinan la vivienda y otro servicio generalmente en planta baja Religioso: Edificios dedicados al culto religioso de cualquier denominación, incluyendo logias. Militar: Edificios de uso militar o de policía.

Valor Arquitectónico: Está determinado por sus características distintivas de un tipo, período, estilo o forma de construcción. Representa el trabajo de un maestro y se distingue el carácter de su autoría. Artístico: Está en función de sus valores estéticos, visuales y simbólicos. Contenga obras de arte como parte del edificio Histórico: Está asociado o vinculado con la historia del país o patrones socio-culturales distintivos de una región o de la nación. Como fuente de información y conocimiento de la sociedad pasada. Asociado con la vida de personalidades significativas desde el punto de vista histórico. Contextual: Está determinada por la armonía de la obra en el entorno en que se encuentra enclavada aunque no posea valores arquitectónicos e históricos. Inmueble: Edificios que carecen de valor.

Variable Propiedades que pueden tomar una serie de valores, en este caso patrimoniales, arquitectónicos o urbanos dentro de ciertos límites, y que definen aspectos básicos del objeto de estudio.

Anexo 1. Gestionar Unidad Edificatoria.

Anexo 2. Gestionar Calles.

Anexo 3. Gestionar Desgloses.

Anexo 4. Gestionar Valor. Anexo 5 Gestionar Transformaciones.

Anexo 6. Gestionar Estado Constructivo. Anexo 7. Gestionar Carácter.

Anexo 8. Gestionar Época de los desgloses.

Anexo 9. Gestionar Época de las UE. Anexo 10. Gestionar Tipo de Planta.

Anexo 11. Gestionar Barrio. Anexo 12. Gestionar Portal.

Anexo 13. Gestionar Tipo de Edificación. Anexo 14. Autenticarse.

Anexo 15. Administrar sistema.

Anexo 16. Categorías Tipológicas. (Ejemplo, existe la de las A, C, D)

Anexo 17. Búsquedas libres.

Anexo 18. Grado de protección predefinido.

Anexo 19. Obtener Grado de Protección.

Diagrama de casos de uso del sistema.

Tecnico General

Técnico especialista ...

(f rom Actors)

Reportes

Gestionar Busquedas

Mostrar UBIT por calles

Autenticar Usuario

Usuario

Administrar Sistema

Administrador de Sistema

(f rom Actors)

Técnico especialista ...

(f rom Actors)

Gestionar Variables.

Anexo 20. Diagrama de Caso de Uso del Sistema.

Diagrama de casos de uso del sistema. Paquete Búsquedas Libres.

Obtener Grado de Protección predefinidos.

Búsquedas Libres

Obtener Grado de Protección

Obtener Categorías Predefinidas.

Tecnico General

(f rom Use-Case Model)

Anexo 21. Paquete Búsqueda.

Anexo 22. Paquete Gestionar Variables.

Diagrama de casos de uso del sistema. Paquete Gestionar Variables.

Gestionar Desglose

(f rom Use-Case Model)Gestionar Unidad Edificatoria


Gestionar Epoca de los Desgloses

Gestionar Uso

Gestionar Uso por Categorias.

Gestionar Uso por Redes

Gestionar Epoca de las Unidades Edificatorias

Gestionar Imagenes


Gestionar Calles

Gestionar Valor

Gestionar Transformaciones

Gestionar Tipo Planta

Gestionar Estado Constructivo

Gestionar CarácterGestionar BarrioGestionar Portal

Gestionar Tipo Edificacion

Técnico especial ista ...

(from Actors)

Diagrama de casos de uso del sistema. Paquete Gestionar Reportes.

Anexo 23. Paquete Gestionar Reportes.

Generar Reporte

Generar reporte de Barrio.

Generar reporte de Carácter.

Generar reporte de Tipo de Edificacion.

Generar reporte de todas las Unidades Edificatorias.

Generar reporte de Transformaciones.

<<extend>>

<<extend>>

<<extend>><<extend>>

<<extend>>

Generar reporte de Unidad Edificatoria con categoría A1..A3

<<extend>>

Generar reporte de Unidad Edi ficatoria con categoría B1...B4.

<<extend>>

Generar reporte de Unidad Edi ficatoria con categoría C1...C3.

<<extend>>

Generar reporte de Unidad Edificatoria con categoría D1...D7.

<<extend>>

Generar reporte de Unidad Edificatoria con grado de protecc...

<<extend>>

Generar reporte de Unidad Edificatoria de 1, 2, 3, 4 plantas.

<<extend>>

Generar reporte de Unidad Edificatoria Estado Constructivo

<<extend>>

Generar reporte de Unidad Edificatoria modificadas.

<<extend>>

Generar reporte de Unidad Edificatoria según tipo pla...

<<extend>>

Generar reporte de Unidad Edi ficatoria según Usos

<<extend>>

Generar reporte de Unidad Edificatoria según Usos 1

Generar reporte de Unidad Edi ficatoria según Usos 2

<<extend>>

Generar reporte por época de las Unidad Edificatoria

<<extend>>

Generar reporte por época de los desgloses.

<<extend>>

Generar reporte Tipo Planta.Generar reportes de todos los

desgloses.

<<extend>>

Generar reportes de Unidad Edificatoria que consti tu...

<<extend>>

<<extend>>

Diagrama de clases.

Diagrama de clase BLL

Diagrama de clases Common

Diagrama de clases DAL

Diagrama de clases de Interfaz

Anexo 24. Relación entre paquetes.

Diagrama de clases

CTUsoUso : String

ConexionInfoBaseDatos : StringConnStr : Stringcontraseña : StringName : StringServidor : StringTipoConexion : BooleanUsuario : String

MiConexion()BuildConnSrt()

ConstantesBoolNull : BooleanCadNull : StringDecimalNull : DecimalFloatNull : FloatIntNull : Integer

CCallenombre : String

CTPortalPortal : String

CTEpocaUEEpoca : String

CTValorValor : String

CTEpocaEpoca : StringDesde : StringHasta : String

CTBarrioBarrio : String

CTipoPlantaPlanta : String

CTipoEdificacionTipo : String

CTTransformacionesTransformaciones : String

CTEstadoConstructivoEstado : String

CTMasEspecificoespecificacion : Stringarea : Double

CUsoEspecificoespecificacion : String

CLoteNroCasa : StringCod_Postal : StringP_Principal : BooleanAreaLote : DoubleLongitudFachada : DoubleNroPlantas : Integerpatio : Boolean

CUnidadEdificatoriaAcceso_Secundario : BooleanCompatibilidad : BooleanCalle : StringValor : StringCaracter : StringEstado : StringTransformaciones : StringEpoca : StringUso : String

Anexo 25. Paquete Common.

Anexo 26. Paquete de Acceso a Datos.

Diagrama de clases. Paquete de Acceso a Datos.

DALTValor

ActualizarValor()EliminarValor()AdicionarValor()ObtenerIdValorDadoValor()ObtenerValorDadoIDValor()ObtenerTablaValor()

DALCalle

ActualizarCalle()AdicionarCalle()BorrarCalle()ObtenerCalleDadoIdCalle()ObtenerEjeDadoId()ObtenerIdDadoCalle()ObtenerIdDadoEje()ObtenerIdDadoIdCalle()ObtenerTablaCalle()ObtenerTablaEje()

DALLote

AdicionarDesglose()EliminarDesglose()ActualizarDesglose()ObtenerDesgloseDadoUE()ObtenerIdDadoNodo()ObtenerNodoDadoId()ObtenerTablaLote()ObtenerTablaNodo()

DALTBarrio

ActualizarBarrio()EliminarBarrio()ActualizarBarrio()ObtenerBarrioDadoIdBarrio()ObtenerIdDadoBarrio()ObtenerTablaBarrio()

DALTCaracter

AdicionarCaracter()EliminarCaracter()ActualizarCaracter()ObtenerIdDadoCaracter()ObtenerCaracterDadoId()ObtenerTablaCaracer()

DALTTransformaciones

ActualizarTransf()EliminarTransf()AdicionarTransf()ObtenerTransfDadoID()ObtenerIdDadoTransform()ObtenerTablaTransf()

DALTUso

AdicionarUso()EliminarUso()ActualizarUso()ObtenerIdDadoUso()ObtenerTablaUso()ObtenerUsoDadoId()ObtenerUsoDadoDadoMasEspecifico()

DALTipo_Edificacion

ActualizarTipoEdificacion()EliminarTipoEdificacion()AdicionarTipoEdificacion()ObtenerIdDadoTipoEdifi()ObtenerTipoDadoId()ObtenerTablaTipoEdificaciono()

DALTEpocaUE

ActualizarEpocaUE()EliminarEpocaUE()AdicionarEpocaUE()ObtenerEpocaUEDadoEpoca()ObtenerEpocaUEDadoIDEpocaUE()ObtenerIdEpocaUEDadoEpocaUE()ObtenerTablaEpocaUE()

DALTMasEspecifico

ActualizarMasEspecifico()EliminarMasEspecifico()AdicionarMasEspecifico()ObtenerEspecDadoIdMasEspe()ObtenerIdDadoEspecif()ObtenerIdDadoIdEspeci()ObtenerTablaMasEspecifico()

DALUsuario

AdicionarUsuario()EliminarUsuario()ObtenerIdRolDadoRol()ObtenerRol()ObtenerTablaRol()ObtenerTablaUsuario()VerificarUsuario()

DALTipo_Planta

ActualizarTipoPlanta()EliminarTipoPlanta()AdicionarTipoPlanta()ObtenerIdDadoPlanta()ObtenerTipoPlantaDadoId()ObtenerTablaTipoPlanta()

DALTEpoca

ActualizarEpoca()AdicionarEpoca()EliminarEpoca()ObtenerIdDadoEpoca()ObtenerIdEpocaDadoIdEpocaUE()ObtenerTablaEpoca()ObtenertablaEpocaDadoEpocaUE()

DALTPortal

ActualizarPortal()EliminarPortal()AdicionarPortal()ObtenerIdDadoPortal()ObtenerPoratlDadoId()ObtenertablaPortal()

DALTEstadoConstructivo

ActualizarEdoConstructivo()EliminarEdoConstructivo()ActualizarEdoConstructivo()ObtenerEdoDadoIdEdo()ObtenerIdDadoEdo()ObtenerTablaEdoCons()

DALUsoEspecifico

ActualizarEspecifico()EliminarEspecifico()AdicionarEspecifico()ObtenerEspecificacionDadoId()ObtenerEspecDadoMasEspec()ObtnerIdEspecDadoEspecificacion()ObteneridDadoIdUso()ObtenerTablaUsoEspecifico()ObtenerTablaEspecificoDadoUso()

DALUnidad_Edificatoria

ActualizarCompatibilidad()ActualizarUnidadEdif()EliminarUnidadEdif()AdicionarUnidadEdif()Area_total_construida()Area_total_parcela()Barrio()Calle()Caracter()CategoriaA1()CategoriaA2()CategoriaA3()CategoriaB1()CategoriaB1a()CategoriaB1b()CategoriaB2()CategoriaB2a()CategoriaB2b()CategoriaB3()CategoriaB3a()CategoriaB3b()CategoriaC1()CategoriaC2()CategoriaC3()CategoriaA1()CategoriaA2()CategoriaA3()Epoca()Estado_Constructivo()GradoProteccion1()GradoProteccion2()GradoProteccion3()GradoProteccion4()Longitud_Fachada()ModificacionesAmpliacion()ModificacionesDivision()ModificacionesFachada()ModificacionesEstrac()Nodo()NroPlantas()ObtenerTablaUE()Patio()Portal()Puntal()Transformaciones()Uso()Valor()

Diagrama de clases. Paquete Lógico de los Datos. .

Anexo 27. Paquete Lógico de los Datos.

BLLCalle

ActualizarCalle()AdicionarCalle()BorrarCalle()ObtenerCalleDadoIdCalle()ObtenerEjeDadoId()ObtenerIdDadoCalle()ObtenerIdDadoEje()ObtenerIdDadoIdCalle()ObtenerTablaCalle()ObtenerTablaEje()

BLLLote

AdicionarDesglose()EliminarDesglose()ActualizarDesglose()ObtenerDesgloseDadoUE()ObtenerIdDadoNodo()ObtenerNodoDadoId()ObtenerTablaLote()ObtenerTablaNodo()

BLLTBarrio

ActualizarBarrio()EliminarBarrio()ActualizarBarrio()ObtenerBarrioDadoIdBarrio()ObtenerIdDadoBarrio()ObtenerTablaBarrio()

BLLTCaracter

AdicionarCaracter()EliminarCaracter()ActualizarCaracter()ObtenerIdDadoCaracter()ObtenerCaracterDadoId()ObtenerTablaCaracer()

BLLTEpoca

ActualizarEpoca()AdicionarEpoca()EliminarEpoca()ObtenerIdDadoEpoca()ObtenerIdEpocaDadoIdEpocaUE()ObtenerTablaEpoca()ObtenertablaEpocaDadoEpocaUE()

BLLTEpocaUE

ActualizarEpocaUE()EliminarEpocaUE()AdicionarEpocaUE()ObtenerEpocaUEDadoEpoca()ObtenerEpocaUEDadoIDEpocaUE()ObtenerIdEpocaUEDadoEpocaUE()ObtenerTablaEpocaUE()

BLLTEstado_Contructiv o

ActualizarEdoConstructiv o()EliminarEdoConstructiv o()ActualizarEdoConstructiv o()ObtenerEdoDadoIdEdo()ObtenerIdDadoEdo()ObtenerTablaEdoCons()

BLLTipo_Planta

ActualizarTipoPlanta()EliminarTipoPlanta()AdicionarTipoPlanta()ObtenerIdDadoPlanta()ObtenerTipoPlantaDadoId()ObtenerTablaTipoPlanta()

BLLTipo_Edif icacion

ActualizarTipoEdif icacion()EliminarTipoEdif icacion()AdicionarTipoEdif icacion()ObtenerIdDadoTipoEdif i()ObtenerTipoDadoId()ObtenerTablaTipoEdif icaciono()

BLLTMasEspecif ico

ActualizarMasEspecif ico()EliminarMasEspecif ico()AdicionarMasEspecif ico()ObtenerEspecDadoIdMasEspe()ObtenerIdDadoEspecif ()ObtenerIdDadoIdEspeci()ObtenerTablaMasEspecif ico()

BLLTPortal

ActualizarPortal()EliminarPortal()AdicionarPortal()ObtenerIdDadoPortal()ObtenerPoratlDadoId()ObtenertablaPortal()

BLLTTransf ormaciones

ActualizarTransf ()EliminarTransf ()AdicionarTransf ()ObtenerTransf DadoID()ObtenerIdDadoTransf orm()ObtenerTablaTransf ()

BLLTValor

ActualizarValor()EliminarValor()AdicionarValor()ObtenerIdValorDadoValor()ObtenerValorDadoIDValor()ObtenerTablaValor()

BLLUnidad_Edif icatoria

ActualizarCompatibilidad()ActualizarUnidadEdif ()EliminarUnidadEdif ()AdicionarUnidadEdif ()Area_total_construida()Area_total_parcela()Barrio()CalcularPorciento()Calle()Caracter()CategoriaA1()CategoriaA2()CategoriaA3()CategoriaB1()CategoriaB1a()CategoriaB1b()CategoriaB2()CategoriaB2a()CategoriaB2b()CategoriaB3()CategoriaB3a()CategoriaB3b()CategoriaC1()CategoriaC2()CategoriaC3()CategoriaA1()CategoriaA2()CategoriaA3()DesUso()Epoca()Estado_Constructiv o()GradoProteccion1()GradoProteccion2()GradoProteccion3()GradoProteccion4()Longitud_Fachada()Modif icacionesAmpliacion()Modif icacionesDiv ision()Modif icacionesFachada()Modif icacionesEstrac()Nodo()NroPlantas()ObtenerTablaUE()Ocupado()ParcialmenteOcupado()Patio()PerteneceEjePrimerOrden()PerteneceEjeSegundoOrden()PerteneceNodoSegundoOrden()PerteneceNodoPrimerOrden()Portal()Puntal()Transf ormaciones()Uso()Valor()

BLLTUso

AdicionarUso()EliminarUso()ActualizarUso()ObtenerIdDadoUso()ObtenerTablaUso()ObtenerUsoDadoId()ObtenerUsoDadoDadoMasEspecif ico()

BLLUsoEspecif ico

ActualizarEspecif ico()EliminarEspecif ico()AdicionarEspecif ico()ObtenerEspecif icacionDadoId()ObtenerEspecDadoMasEspec()ObtnerIdEspecDadoEspecif icacion()ObteneridDadoIdUso()ObtenerTablaUsoEspecif ico()ObtenerTablaEspecif icoDadoUso()

BLLUsuario

AdicionarUsuario()EliminarUsuario()ObtenerIdRolDadoRol()ObtenerRol()ObtenerTablaRol()ObtenerTablaUsuario()Verif icarUsuario()

CadenaFiltros

AdicionarFiltro()ApFiltro()AppFiltroAnd()EliminarFiltro()Filtrar()FiltrarGeneral()

Diagrama de clases. Paquete Interfaz de Usuario.

Anexo 28. Paquete Interfaz de Usuario.

FormaAdministrarConf : Stringnombre : Stringpass : Stringrol : String

FormaAddUsuario_Load()listView_SelectedIdexChanged()MostrarFormaAddUsuario()MostrarUsuario()

FormaUsuario

buttonAceptar_Click()buttonCancelar_Click()GetData()

FormaGradoProteccion

FormaGradoProteccion_Load()ShowReportGradoProteccion()comboBoxGrado_SelectedIdexChanged()

FormaEstado_Constructiv o

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaEpocaLote_Load()SetData()ShowReportTablaEpocaLote()Verif icarRol()

FormaBarrio

ShowReportTablaBarrio()Verif icarRol()buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()

FormaTransf ormaciones

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaTransf ormaciones_Load()SetData()ShowReportTransf ormaciones()Verif icarRol()

FormaEpocaUE

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaEpocaUE_Load()SetData()ShowReportTablaEpocaUE()Verif icarRol()

FormaEpocaLote

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaEpocaLote_Load()SetData()ShowReportTablaEpocaLote()

FormaPrincipalnombre : Stringpass : Stringrol : String

FormaPrincipal_Load()Main()ShowWindows()toolBar1_ButtonClick()

Diagrama de clases. Paquete Interfaz de Usuario.

Anexo 28.1. Paquete Interfaz de Usuario.

FormaCaracter

ShowReportTablaBarrio()VerificarRol()buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()

FormaConeccion

FormaConexion_Load()radioButtonUsuario_CheckedChanged()

FormaValor

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaValor_Load()SetData()ShowReportTablaValor()VerificarRol()

FormaTipoEdificacion

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaTipoEdificacion_Load()SetData()ShowReportTablaTipoEdificacion()VerificarRol()

FormaTipoPlanta

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaTipoPlanta_Load()SetData()ShowReportTablaTipoPlanta()VerificarRol()



FormaGradoproteccionGral

FormaGradoProteccion_Load()ShowReportGradoProteccion()comboBoxGrado_SelectedIdexChanged()

FormaLoteMZGlobal : StringUEGlobal : String

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaLote_Load()SetData()ShowReportTablaLote()

FormaUEcompatibilidad : BooleanEdoConst : Booleanparcialmente : Booleansinuso : Boolean

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaUE_Load()SetData()ShowReportTablaUE()VerificarRol()

FormaImagen

FormaImagen_Load()SetDataFileName()ShowImagen()



FormaUsoEspecificoCod_UsoGlobal : String

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaUsoEspecifico_Load()SetData()ShowReportTablaUsoEspecifico()

FormaUso

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaUso_Load()SetData()ShowReportTablaUso()VerificarRol()

FormaMasEspecificoUsoEspecificoGlobal : StringUsoGlobal : String

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaMasEspecifico_Load()SetData()ShowReportTablaMasEspecifico()

FormaCategoria

FormaCategoria_Load()

FormaPortal

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaPortal_Load()SetData()ShowReportTablaPortal()VerificarRol()

FormaCalle

buttonAceptar_Click()buttonEliminar_Click()buttonAdicionar_Click()buttonEditar_Click()buttonActualizar_Click()FormaCalle_Load()SetData()ShowReportTablaCalle()VerificarRol()

FormaConexiones

FormaConexiones_Load()listBox_SelectedIndexChanged()

FormaAddUsuario

FormaAddUsuario_Load()GetData()LlenarComponentes()

FormaConsultasLibres

buttonMostrar_Click()FormaConsultasLibres_Load()

Anexo 28.2. Paquete Interfaz de Usuario.

Diagrama Modelo de datos

Anexo 29. Modelo de Datos.

LoteNro_Manzana : VARCHAR(3)Nro_Unidad_Edificatoria : VARCHAR(10)Nro_Lote : VARCHAR(2)Nro_casa : VARCHAR(10)Cod_Postal : VARCHAR(10)cod_calle : VARCHAR(3)P_Principal : BITValor : VARCHAR(2)Caracter : VARCHAR(2)Estado_Constructivo : VARCHAR(2)Transformaciones : VARCHAR(2)Epoca : VARCHAR(2)IdEpocaUE : VARCHAR(2)Area_Lote : DECIMAL(9, 2)Longitud_Fachada : DECIMAL(9, 2)Nro_Planta : INTCod_Uso : VARCHAR(3)Cod_Uso_Especifico : VARCHAR(3)Cod_Uso_UE : VARCHAR(2)Portal : VARCHAR(2)Area_Construida : DECIMAL(9, 2)Puntal : DECIMAL(5, 2)Nodo : CHAR(1)Modificaciones_Estructura : BITModificaciones_Fachada : BITModificaciones_Ampliacion : BITModificaciones_Division : BITpatio : BITbarrio : VARCHAR(2)

<<PK>> PK_Lote()<<FK>> FK_Lote_Unidad_Edificatoria()<<FK>> FK_Lote_TPortal()<<FK>> FK_Lote_TValor()<<FK>> FK_Lote_TCaracter()<<FK>> FK_Lote_TEpoca()<<FK>> FK_Lote_TBarrio()<<FK>> FK_Lote_TMasEspecifico()<<FK>> FK_Lote_TNodo()<<FK>> FK_Lote_Calle()<<FK>> FK_Lote_TEstado_Cosntructivo()<<FK>> FK_Lote_TTransformaciones()

TEjeIdEje : CHAR(1)Eje : VARCHAR(20)

<<PK>> PK_TEje()

TEpocaUEIdEpocaUE : VARCHAR(2)EpocaUE : VARCHAR(50)

<<PK>> PK_TTransformacionesUE()

Tipo_EdificacionIdTipo : VARCHAR(2)Tipo : VARCHAR(50)

<<PK>> PK_Tipo_Edificacion()

Tipo_de_Planta Codigo_de_la_Planta : VARCHAR(2)Planta : VARCHAR(50)

<<PK>> PK_Planta U/E()

CalleCod_calle : VARCHAR(3)nombre : VARCHAR(50)Eje : CHAR(1)

<<PK>> PK_Calle()<<FK>> FK_Calle_TEje()

10..* 10..*

<<Non-Identifying>>

TBarrioIdBarrio : VARCHAR(2)Barrio : VARCHAR(50)

<<PK>> PK_TBarrio()

TCaracterCodigo_Caracter : VARCHAR(2)Caracter : VARCHAR(50)

<<PK>> PK_Carácter()

TEpocaCodigo_Epoca : VARCHAR(2)IdEpocaUE : VARCHAR(2)Epoca : VARCHAR(50)Desde : INTHasta : INT

<<PK>> PK_TEpoca()<<FK>> FK_TEpoca_TEpocaUE()

10..* 10..*<<Identifying>>

TEstado_CosntructivoCodigo_Estado_Contructivo : VARCHAR(2)Estado_Cosntructivo : VARCHAR(30)

<<PK>> PK_TEstado_Cosntructivo()

TNodoIdNodo : CHAR(1)Nodo : VARCHAR(20)

<<PK>> PK_TNodo()

TPortalIdPortal : VARCHAR(2)Portal : VARCHAR(30)

<<PK>> PK_Portal()

TTransformacionesCodigo_Transformaciones : VARCHAR(2)Transformaciones : VARCHAR(50)

<<PK>> PK_TTransformaciones()

TValorCodigo_Valor : VARCHAR(2)Valor : VARCHAR(50)

<<PK>> PK_Valor()

Unidad_EdificatoriaNro_Manzana : VARCHAR(3)Nro_Unidad_Edificatoria : VARCHAR(10)Tipo_de_Planta : VARCHAR(2)Tipo_Edificacion : VARCHAR(2)Acceso_Secundario : BITCompatibilidad : BITCalle : VARCHAR(3)Valor : VARCHAR(2)Caracter : VARCHAR(2)Estado_Constructivo : VARCHAR(2)Transformaciones : VARCHAR(2)Epoca : VARCHAR(50)Uso : CHAR(1)Area_Total_de_Parcela : DECIMAL(9, 2)Longitud_Fachada : DECIMAL(9, 2)Nro_de_Planta : INTPortal : VARCHAR(50)Area_total_construida : DECIMAL(9, 2)Puntal : DECIMAL(5, 2)Nodo : VARCHAR(50)Modificaciones_en_la_Estructura : BITModificaciones_en_la_Fachada : BITModificaciones_en_la_Ampliacion : BITModificaciones_en_la_Division : BITBarrio : VARCHAR(50)Patio : BITcamino : NVARCHAR(50)Idobjeto : INT

<<PK>> PK_Unidad Edificatoria.()<<FK>> FK_Unidad_Edificatoria_Tipo_Edificacion()<<FK>> FK_Unidad_Edificatoria_Tipo_de_Planta ()

1 0..*1 0..*

<<Non-Identifying>>10..* 10..*

<<Non-Identifying>>

TUsoCodigo_Uso : VARCHAR(2)Uso : VARCHAR(50)

<<PK>> PK_Uso()

1

0..*

1

0..*

<<Non-Identifying>>

1 0..*1 0..*

<<Non-Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

1

0..*

1

0..*<<Non-Identifying>>

1

0..*

1

0..*

<<Non-Identifying>>

1

0..*

1

0..*<<Non-Identifying>>

10..*

10..*

<<Non-Identifying>>

10..* 10..*

<<Non-Identifying>>

10..*1

0..*

<<Identifying>>

UsoEspecificoIDEspecifico : VARCHAR(3)IDUso : VARCHAR(2)Especificacion : VARCHAR(30)

<<Unique>> IX_UsoEspecifico()<<PK>> PK_UsoEspecifico()<<FK>> FK_UsoEspecifico_TUso()

1

0..*

1

0..*

<<Identifying>>

TMasEspecificoIDmasespecifico : VARCHAR(3)IDespecificacion : VARCHAR(3)IDUso : VARCHAR(2)masespecificacion : VARCHAR(50)area_que_ocupa : DECIMAL(18, 0)

<<PK>> PK_TMasEspecifico_1()<<Unique>> IX_TMasEspecifico()<<FK>> FK_TMasEspecifico_UsoEspecifico()

10..* 10..*<<Non-Identifying>> 10..* 10..*

<<Identifying>>

Diagrama de Clase Persistentes.

T_Unidad_EdificatoriaAcceso_Secundario : Boolean = 0Compatibilidad : Boolean = 0Calle : String = ' 'Valor : String = ' 'Caracter : String = ' 'Estado_Constructivo : String = ' 'Transformaciones : String = ' 'Epoca : String = ' 'Uso : String = ' 'Area_Total_de_Parcela : Double = 0Longitud_Fachada : Double = 0Nro_de_Planta : Integer = 0Portal : String = ' 'Area_total_construida : Double = 0Puntal : Single = 0Nodo : String = ' 'Modificaciones_en_la_Estructura : Boolean = 0Modificaciones_en_la_Fachada : Boolean = 0Modificaciones_en_la_Ampliacion : Boolean = 0Modificaciones_en_la_Division : Boolean = 0Barrio : String = ' 'Patio : Boolean = 0camino : String = ' 'Idobjeto : Integer = 0

T_TEjeEje : String = ' '

T_TEpocaUEEpocaUE : String = ' '

T_Tipo_EdificacionTipo : String = ' '

T_Tipo_de_Planta Planta : String = ' '

T_Callenombre : String = ' '

1

0..*

1

0..*

T_TBarrioBarrio : String = 0

T_TCaracterCaracter : String = ' '

T_TEpocaEpoca : String = ' 'Desde : Integer = 0Hasta : Integer = 0

1

0..*

1

0..*

T_TEstado_CosntructivoEstado_Cosntructivo : String = ' '

T_TNodoNodo : String = ' '

T_TPortalPortal : String = ' '

T_TTransformacionesTransformaciones : String = ' '

T_TValorValor : String = ' '

10..* 10..*

10..*

10..*

T_TUsoUso : String = ' '

T_LoteNro_casa : String = ' 'Cod_Postal : String = ' 'P_Principal : Boolean = 0Area_Lote : Double = 0Longitud_Fachada : Double = 0Nro_Planta : Integer = 0Area_Construida : Double = 0Puntal : Single = 0Modificaciones_Estructura : Boolean = 0Modificaciones_Fachada : Boolean = 0Modificaciones_Ampliacion : Boolean = 0Modificaciones_Division : Boolean = 0patio : Boolean = 0

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

10..*

10..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

1

0..*

T_UsoEspecificoEspecificacion : String = ' '

1

0..*

1

0..*

T_TMasEspecificomasespecificacion : String = ' 'area_que_ocupa : Long = 0

1

0..*

1

0..*

1

0..*

1

0..*

Anexo 30. Clases Persistentes.

Diagrama de despliegue

Servidor de Base de Datos

ImpresoraAplicación cliente

Servidor de Base de Datos con SQL-SERVER 2000

Aplicacion Clienteprogramada en la plataforma .NET, con C#.

TCP/IP(LAN)

Anexo 31. Diagrama de Despliegue.

Diagrama de componentes

DUAC.exe

Acceso a datos

Zona_Protec_#2

Logica de NegocioInterfaces

Common

Conn.INI<<ConfigFile>>

PReports.dll

Anexo 32. Diagrama de Componentes.

Diagrama de componentes. Paquete Interfaces.

FormaPrincipal.cs<<Unit>>

FormaConexiones.cs

<<Unit>>

FormaUsuario.cs

<<Unit>>

FormaBarrio.cs

<<Unit>>

FormaCaracter.cs

<<Unit>>FormaCalle.cs

<<Unit>>

FormaEstadoConstructiv o.cs

<<Unit>>FormaPortal.cs

<<Unit>>FormaTipoEdif .cs

<<Unit>>FormaPlantas.cs

<<Unit>>FormaTransf ormaciones.cs

<<Unit>>

FormaLote.cs

<<Unit>>

FormaUso.cs

<<Unit>>FormaValor.cs

<<Unit>>

FormaUsoCat.cs

<<Unit>>FormaUsoEspecif ico.cs

<<Unit>>

FormaImagen.cs

<<Unit>>

FormaAdministrar.cs

<<Unit>>

FormaEpocaEsp.cs

<<Unit>>

FormaEpocaGral.cs

<<Unit>>FormaConsultasLibres.cs

<<Unit>>

FormaUE.cs

<<Unit>>FormaGradoproteccion

<<Unit>>FormaGradoproteccionGral

<<Unit>>ForaCategoria

<<Unit>>

Anexo 33. Paquete Interfaz de Usuario.

Diagrama de componentes. Paquete de Acceso a Datos.

DALUsoEspecifico.cs

<<Unit>>

DALTValor.cs

<<Unit>>DALTCaracter.cs

<<Unit>>

DALEpoca.cs

<<Unit>>

DALEpocaUE.cs

<<Unit>>

DALTEstado_Constructivo.cs

<<Unit>>

ConsultasLibres.cs

<<Unit>>DALLote.cs

<<Unit>>DALTBarrio.cs

<<Unit>>

DALTipo_de_Planta.cs

<<Unit>>

DALTipo_Edificacion.cs

<<Unit>>

DALTUso.cs

<<Unit>>

DALTMasEspecifico

<<Unit>>

DALTPortal.cs

<<Unit>>DALTTransformaciones.cs

<<Unit>>

DALUnidad_Edificatoria.cs

<<Unit>>DALUsuario.cs

<<Unit>>DALCalle.cs

<<Unit>>

Anexo 34. Paquete de Acceso a Datos.

Diagrama de componentes. Paquete Lógica del Negocio.

BLLTPortal.cs

<<Unit>>

BLLCadenaFiltrosUE.cs

<<Unit>>

BLLCalle.cs

<<Unit>>

BLLLote.cs

<<Unit>>

BLLTBarrio.cs

<<Unit>>

BLLTCaracter.cs

<<Unit>>BLLTEpoca.cs

<<Unit>>

BLLTEpocaUE.cs

<<Unit>>

BLLTEstado_Constructivo.cs

<<Unit>>

BLLTipo_de_Planta.cs

<<Unit>>

BLLTipo_Edificacion.cs

<<Unit>>

BLLTMasEspecifico.cs

<<Unit>>

BLLTTransformaciones.cs

<<Unit>>

BLLTUso.cs

<<Unit>>

BLLTValor.cs

<<Unit>>

BLLUnidad_Edificatoria.cs

<<Unit>>

BLLUsoEspecifico.cs

<<Unit>>

BLLUsuario.cs

<<Unit>>

Anexo 35. Paquete Lógico de los Datos.

Anexo 36. Paquete Common.

Diagrama de componentes. Paquete Common.

UsuarioNoExiste.cs

<<Unit>>ExisteUsuario.cs<<Unit>>

EliminarElementoReferenciado.cs.cs

<<Unit>>

SQLStop<<Unit>>

ConversionStrInt.cs

<<Unit>>ImagenNoEncontrada.cs

<<Unit>>

ConexionInfo.cs

<<Unit>>Constantes.cs

<<Unit>> Unidad_Edificatoria.cs

<<Unit>>

Documents

Diagnostico urbano arquitectonico de CiuddadProyecto Urbano Arquitectónico VI, el que se vincula específicamente con los temas de la conservación y restauración. La creación de