CAPITULO I ASPECTO GENERAL DEL PROYECTO

1.1 .- TTULO DEL PROYECTO. Uso del Rational Rose, para el anlisis, diseo e implementacin del sistema Informtico para el control de Licencias de Edificacin de la municipalidad de Jan, Agosto- Noviembre 2009. 1.2 .- SITUACIN PROBLEMTICA. La tecnologa en la actualidad va adquiriendo gran importancia para las organizaciones en general ya que el cambio de un sistema manual a un sistema informtico acarrea grandes beneficios para aquellos que lo obtienen. El sistema manual que la municipalidad que actualmente utiliza, lleva consigo varios procesos que hacen del rea de licencias de edificacin realice un trabajo complejo, de manera que se realizan una serie de documentos que deben de entregarse a los fiscalizadores y contribuyentes en el periodo de tiempo mnimos haciendo un trabajo sin lmites de descanso. El no poseer un sistema informtico mecanizado, el rea de licencias de edificacin hace que no garantice un desenvolvimiento eficaz para lograr un nivel alto en comparacin a las exigencias de los usuarios, dando lugar a que se enfrente un serie de reclamos y criticas, a la vez afecta la toma de decisiones, razn por la cual se considera importante realizar la presente investigacin que permita obtener informacin para la elaboracin e implantacin del sistema que contribuya a la solucin problemtica existente. 1.3 .- ANLISIS DE LA EMPRESA. Actualmente la informacin se administra en 2 computadoras en hojas de clculo Excel, almacenado una acotacin por contribuyente, luego cuando se realiza la bsqueda de acotaciones, se invierte un tiempo considerado, causando espera en los fiscalizadores, dificultando prdida de tiempo en el desempeo de sus funciones. El problema que radica en esta rea de la municipalidad, es la eficiencia en la bsqueda de datos y en la demora cuando se generan los documentos como acotaciones, actas de compromiso y en bsqueda de ubicacin de los contribuyentes.

1.4 .- PROBLEMA. En qu medida el Rational Rose me permite analizar, disear e implantar un sistema informtico que contribuye al funcionamiento efectivo del rea de control de Licencias de Edificacin de la municipalidad de Jan.? 1.5.- HIPTESIS. El Rational Rose me permitir hacer un anlisis, diseo e implantacin de un sistema informtico contribuye al funcionamiento efectivo del rea de control de licencias de edificacin. 1.6.- OBJETIVOS. 1.6.1.- OBJETIVO GENERAL. Realizar el anlisis, diseo e implantacin del Sistema Informtico para el rea de licencias de edificacin de la Municipalidad de Jan, departamento de Cajamarca. 1.6.2.- OBJETIVOS ESPECFICOS. Realizar la investigacin preliminar para dar inicio al proyecto. Determinar los requerimientos bsicos que contemplar el sistema a implantar. Efectuar el diseo del sistema a implantar. Desarrollar el software perteneciente al sistema utilizando un lenguaje de programacin. Ejecutar la prueba del sistema para saber si necesita depuraciones o modificaciones. Implantar y documentar el sistema. Capacitar a los usuarios que estarn en contacto con el sistema. 1.7.- JUSTIFICACIN. La presente investigacin se considera importante porque con la implantacin de un Sistema Informtico, contribuye agilizar los procesos de registro de acotaciones y actas de compromiso de pagos y proporciona de esta forma informacin oportuna a los diferentes usuarios y al funcionamiento efectivo del personal responsable.

Con el anlisis, diseo e implantacin de un Sistema Informtico para el rea de Fiscalizacin de Licencias de Construccin de la municipalidad de Jan, se permite obtener grandes beneficios debido a la necesidad que actualmente el rea dispone ya que realizan todos sus procesos de forma manual por lo que disminuye su funcionamiento efectivo. Por tal razn, con el presente estudio se beneficia a: Al gerente de rea brindndoles un sistema informtico que le proporcione informacin oportuna para la toma de decisiones. Al personal de fiscalizacin orientndoles a la prctica de un sistema que ahorre tiempo y les permita dedicarse a sus labores especificas. Al personal administrativo permitindoles llevar un control de recaudaciones y de mejorar la presentacin de las mismas y que tambin realicen su trabajo de manera ms

efectiva y oportuna en el rea mencionada. A los contribuyentes, pues ellos adquieren informacin actualizada y oportuna para cuando realicen sus trmites pertinentes. Al municipio de manera que posean una mejor imagen ante la comunidad utilizando tecnologa de punta. A la Universidad de Chiclayo aumentando su volumen bibliotecario en beneficio de los usuarios.

CAPTULO II ASPECTOS GENERALES DE LA EMPRESA

2.1.-HISTORIA MUNICIPALIDAD PROVINCIAL DE JAN. Los primeros pobladores de la Antigua Provincia de Jan de Bracamoros fue habitada por Indios Aborgenes que vivan formando tribus independientes, en donde no haba predominio de una sobre la otra y entre las ms conocidas, tenemos, a los Pacamoros o Bracamoros, Huambisas y Aguarunas; habiendo existido otras ms que tomaban el nombre del lugar en donde moraban, hoy los estudios antropolgicos concluyen diciendo que dichas tribus fueron una sola familia, la de los Jbaros fundamentndolo en similitudes de costumbres, lenguas, historias, cuentos, mitos y artesana. Acerca de la procedencia, el historiador y antroplogo ecuatoriano Jacinto Jijn Caamao, sostiene que los Jbaros provienen de los Chimes o Tallanes; de otro lado, la mayora de los estudiosos y la misma tradicin aguaruna considera que proceden del llamo amaznico, a donde llegaron por el ro Amazonas, seguramente de otro Continente, que bien puede ser el Asitico.El Capitn Diego Palomino autorizado por el Pacificador D. Pedro de la Gasca, acomete la empresa de continuar con la conquista iniciada por D Pedro Vergara. Llega a las mrgenes del ro Chinchipe, lo explora, ubica el terreno en donde fundara una ciudad y en Abril de 1549 plant la cruz en lo que sera la Plaza de Armas, traz las calles y asign solares a 26 Colonos o futuros pobladores, de lo cual di cuenta a la Gasca y al Consejo de Indias el 21de Septiembre del ao citado. El nombre que se di a la ciudad recin fundada fu de JAEN DE BRACAMOROS, Jan por su parecido con la ciudad de Jan Espaa y Bracamoros, con el fin de perpetuar el nombre de los Pacamoros o Bracamoros, principal tribu aborigen de la regin. Estaba situada en una altura llamada Yuramarca o Juramarca, que dista 80 kilmetros del Jan actual. Como Patrono fu Institudo SAN LEANDRO.La gerencia de desarrollo urbano y rural es el mximo rgano administrativo del gobierno local, responsable de programar, administrar, dirigir y ejecutar, coordinar y controlar el cumplimiento de las actividades concernientes al desarrollo urbano infraestructura, obras y adjudicaciones; admitir autorizaciones, certificaciones, concesiones y adjudicaciones en el mbito de su competencia. Es el encargado de conducir los procesos de desarrollo urbano y rural, en sus aspectos de planeamiento de la infraestructura urbana y rural, administrar el catastro, realizar las habilitaciones y renovacin urbana, as como las obras municipales de acuerdo a la normatividad vigente. Est a cargo de un profesional como gerente quien depende de la Gerencia General y la Alcalda.
6

2.2.- ESTRUCTURA ORGNICA MUNICIPAL PROVINCIAL DE JAN.

Comit Ambiental Municipal

CONCEJO MUNICIPAL

Comisin de Regidores

Consejo de Coordinacin Local Comit Defensa Civil Comit Seguridad Ciudadana Asociacin de Municipalidades Comit de Participacin Vecinal

rgano de Control institucional

ALCALDIA

GERENCIA GENERAL

COPALE Comit Plan Urbanismo

Procuradura Municipal Secretaria Coop. Tcnica Internacional Oficina de Secretaria General Oficina de Imagen Institucional Oficina de Planificacin y Presupuesto Oficina de Asesora Jurdica

Comit Prog. Vaso de Leche Comit Prog. Sociales

U Planeacin e inversiones U. Presupuesto Participativo U. Estadstica Gerencia de Administracin Gerencia Adm. Tributaria U. de Racionalizacin

SG Logstica SG Contabilidad SG Tesorera SG Personal SG Inf. sistemas

SG Recaudacin SG Fis. Tributaria SG Ejec. Coactiva

GERENCIA DUR

G AMBIENTAL Ord.TERRITORIAL

GERENCIA DEL

G.DESARROLLO SOCIAL

GERENCIA ECRD

GERENCIA MAQUINARIA

GERENCIA SS. PBLICOS

SG obrasliquidacin

SG ACM y RRNN SG

SG Comercializacin

SG DEMUNA

SG Rec. deportes

SG Registro Civil

SG E y U.Formulad

Parques y Jardines SG

SG Des. Empresarial

SG PVL

SG Cult. turismo

SG Polica Municipal

SGCatastro urbano

Agua y saneamiento

SG Prom. fomento

SG Prog Sociales

SG CECUJ

SG Seg. Ciudadana

SG Defensa civil

SG Part Vecinal

SG Biblioteca

SG Cir. y Trnsito

SG C y P Drogas

SG Limpieza Pblica

SG OMAPED

SG Abas. Y Merca

MP

EPS Maran

P Radio y TV

2.3.- MISIN. Reglamentar, controlar y otorgar licencias de construccin, remodelacin, refaccin y demolicin de edificios pblicos y privados. 2.4.- VISIN. Al 2010 concientizar al contribuyente a realizar su tramitacin de sus licencias de manera voluntaria y superar las recaudaciones monetarias en aos anteriores. 2.5.- OBJETIVOS GENERALES. Mantener un proceso econmico y financiero que permita a la municipalidad de Jan obtener recursos para su planificacin urbana y rural, supervisin y sostenibilidad. Prestar un servicio de autoridad y credibilidad que permita la satisfaccin al vecino a travs de la agilidad y efectividad del trmite. 2.6.-MATRIZ FODA.
FACTORES

FORTALESAS
F1. Las normas municipales son el reglamento legal que rige para la administracin de la municipalidad de Jan. F2. Reglamentos de planificacin urbana y rural son normas que rigen para el desarrollo urbanstico y rural de la ciudad. F3. Fortalecimiento de la autoridad es darle mayor credibilidad al trmite con lo que se logra fortalecer la autoridad. Fortalecer municipales. las normas

DEBILIDADES
D1. Iniquidad en las cobranzas a los contribuyentes. D2.Variacin en el importe original del costo de la edificacin de la obra, con el importe que paga el contribuyente. D4. Deficiencia en la agilidad y efectividad del trmite es hacer que ste sea fcil y efectivo.

INTERNOS

FACTORES EXTERNOS OPORTUNIDADES.

O1. Mejor servicio, si se presenta un mejor servicio, el contribuyente demandar el proceso. O2. Seguridad en la inversin, si el trabajo es profesional hay seguridad que la inversin sea confiable.

Integrar nuevos modelos de fiscalizacin.

Disear medidas de cobranza equitativa sin favorecer a segmentos de contribuyentes. Automatizar la tramitacin de las licencias de edificacin.

AMENAZAS
A1. Tarifas mnimas; para el contribuyente pagar una tarifa reglamentada, que recurrir al soborno en el trmite. A2. Incumplimiento con los reglamentos; el contribuyente no cumple con los trmites debido a lo engorroso del trmite.

Incentivar al contribuyente, con descuentos, por tramitacin voluntaria. Tramitacin eficiente

Capacitar al fiscalizacin.

personal

de

Mediante la tecnologa hacer que el tramite sea de fcil manejo al contribuyente

2.7.- FUNCIONES ESPECFICAS. Planificar, dirigir, controlar, supervisar, evaluar las actividades de planificacin urbana del plan urbano de los planes de reordenamiento urbano y actividades de catastro urbano. Tener actualizado los registros catastrales, registros de licencia de construccin, registro de control urbano, registro de profesionales y otros propios de la divisin. Controlar el cumplimiento del reglamento nacional de construcciones referente a la presentacin, revisin, aprobacin y control posterior de las licencias de construccin, habitaciones urbanas, subdivisiones de lotes alineamientos, inspecciones oculares, tasaciones, valores arancelarios, declaratoria de fbrica y otras actividades propias de la divisin.

CAPITULO III MARCO TERICO

10

3.1.- EL LENGUAJE DE MODELADO UNIFICADO El UML (Unified Modeling Languaje o Lenguaje Unificado de Modelado) es un lenguaje grfico para la especificacin, visualizacin, construccin y

documentacin de piezas de informacin usadas o producidas durante el proceso de desarrollo de software. A estas piezas de informacin se les conoce como Artefactos. El UML provee un marco arquitectnico de diagramas para trabajar sobre anlisis y diseo orientado a objetos, as como tambin el modelamiento de negocios y otros sistemas que no son software. El UML es pues un lenguaje simblico para expresar modelos orientados a objetos y no una metodologa para desarrollarlos. Este lenguaje es el resultado de la convergencia de las mejores prcticas en la industria de tecnologa de software orientado a objetos, en especial de la simbologa utilizada por tres de los principales mtodos de anlisis y diseo orientado a objetos como son Booch (Booch), OMT (Rumbaugh), y OOSE (Jacobson) cuyos autores se agruparon en Rational Software para desarrollarlo. El UML surge pues como la unin de la simbologa utilizada por estos mtodos, pero es mucho ms, puesto que incluye formas adicionales para manejar problemas que el modelado con estos mtodos no abarcaba completamente. Muchas compaas estn incorporando el UML como estndar en sus procesos y productos, que cubren disciplinas tales como modelamiento del negocio, requisitos de gerencia, anlisis y diseo, programacin y pruebas. Larman, C. UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado. Segunda Edicin. Prentice-Hall, 2002

11

3.2.- El OMG El Objetc Management Group Inc. es una organizacin internacional que cuenta con ms de 800 miembros que incluyen vendedores de sistemas, desarrolladores de software y usuarios. Fue fundada en 1989 y promueve la teora y prctica de la tecnologa orientada a objetos en el desarrollo de software, esto incluye el establecimiento de las lneas maestras y el manejo de especificaciones para proveer un marco comn de trabajo para el desarrollo de aplicaciones. Sus objetivos primarios son la reusabilidad, portabilidad e interoperatibilidad del software basado en objetos distribuyendo entornas homogneos de desarrollo. Para que este desarrollo se produzca el OMG establece el OMA (Object Management Architecture). El OMA provee la infraestructura conceptual bajo la cual todas las especificaciones OMG son basadas. La OMG adopta al UML hacia 1997, para reducir el grado de confusin dentro de la industria y permitir el desarrollo de sistemas y herramientas orientadas a objetos. Larman, C. UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado. Segunda Edicin. Prentice-Hall, 2002 3.3.- CARACTERSTICAS GENERALES DEL UML El UML rene caractersticas deseables en los lenguajes de modelado, tales como: Definicin formal de un metamodelo comn que define el lenguaje para expresar modelos de anlisis y diseo, para representar su semntica, incluyendo modelos estticos, modelos de comportamiento, modelos de uso y modelos de arquitectura. Un metamodelo se define como un modelo que sirve para expresar otros modelos, y son indispensables para poder definiros sin ambigedades. El UML permite expresar modelos, inclusive se utiliza a s mismo para definirse formalmente. Los metamodelos son comnmente utilizados por investigadores y por desarrolladores de herramientas de modelado de software.
12

 La especificacin de un IDL (Interchange Data Languaje o Lenguaje de Intercambio de Datos) el cual contiene mecanismos de intercambio entre las distintas herramientas de software que implementan el Anlisis y Diseo Orientado a Objetos. Una notacin comprensible por el humano para representar modelos ADOO (Anlisis y Diseo Orientados a Objetos). EL UML incorpora conceptos claves orientados a objetos y adems permite ampliar el lenguaje mediante mecanismos de extensin. Kendall, A y Col., Anlisis y Diseo de Sistemas, Tercera Edicin. Editorial Limusa. Espaa 2004

3.4.- BENEFICIOS DEL UML Los beneficios aportados por el UML son: a) Provee a los desarrolladores un lenguaje de modelamiento visual listo para utilizar, es as como nosotros podemos desarrollar e intercambiar modelos orientados a objetos significativos. El UML consolida un conjunto de conceptos que son generalmente aceptados por muchos mtodos y herramientas de modelado y necesarios en una amplia gama de aplicaciones. Este es uno de los principales beneficios aportados por el UML, permitiendo el avance de la industria del software para construir modelos que puedan ser utilizados por diferentes herramientas, debido a su aceptacin como un estndar de modelado. b) Proporciona mecanismos de extensin y de especializacin para ampliar los conceptos bsicos. El UML puede ser ampliado para nuevas necesidades en un dominio especfico. Los conceptos no pueden ser cambiados mas de lo necesario, pues los usuarios necesitan construir modelos usando conceptos fundamentales para las aplicaciones ms comunes, sin necesidad de usar los mecanismos de extensin; pero, pueden aadir nuevos conceptos y notaciones
13

para usos no cubiertos por sus definiciones, escoger entre interpretaciones variables de conceptos existentes cuando no existe un claro consenso y, especializar conceptos, notaciones y restricciones de un particular dominio de la aplicacin. c) Es independiente de los lenguajes de programacin y de mtodos y procesos de desarrollo de software. UML puede y debe soportar todos los lenguajes de programacin y varios mtodos y procesos para construir modelos sin mayor dificultad. d) Proporciona una base formal para entender el lenguaje de modelado. Los usuarios usan la formalidad para ayudarse a comprender el lenguaje, pero el formalismo no debe requerir muchos niveles o capas y uso excesivo de matemticas. UML provee de una definicin formal del modelo esttico usando el Diagrama de Clases. Este diagrama es muy popular y ampliamente aceptado como aproximacin formal de un modelo y del intercambio de informacin, pero adems, el UML expresa las restricciones en OCL (Object Constraint Languaje) y las operaciones en un lenguaje natural muy preciso. e) Anima el crecimiento del mercado de las herramientas de Orientacin a Objetos, porque permite a los vendedores soportar un lenguaje estndar de modelado usado por muchas herramientas, en beneficio de la industria. La

interoperatibilidad requiere que los modelos puedan ser cambiados entre usuarios y herramientas sin perder informacin. Esto solo es posible cuando las herramientas manejan un conjunto de conceptos relevantes y ampliamente aceptados por la industria del software. . f) Utiliza conceptos de alto nivel de desarrollo tales como colaboraciones, armazones, modelos y componentes, definiendo claramente la semntica de estos conceptos lo cual es esencial para obtener los beneficios de la orientacin de objetos, colocando dentro de un contexto completo un lenguaje de modelado nico.
14

g) Integra las mejores prcticas de desarrollo de software. La motivacin clave para el desarrollo del UML es la integracin de las mejores prcticas de la industria, acompaados de variedades amplias de vistas en niveles de abstraccin, dominios, arquitecturas, ciclos de vida, tecnologas de

implementacin, etc. Larman, C. UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado. Segunda Edicin. PrenticeHall, 2002.

3.5.- ALCANCES DEL UML Primero, unifica los conceptos de los mtodos Booch, OMT y OOSE. El resultado es un simple, comn y ampliamente utilizable lenguaje para usuarios de estos y otros mtodos. Segundo, UML pone sobre el tapete lo que pueden hacer los mtodos existentes. Por ejemplo, los autores de UML modelaron sistemas distribuidos para asegurar que el UML trate adecuadamente estos dominios. Tercero, UML se centra en unificar el lenguaje de modelado, y no un proceso de desarrollo estndar. Aunque la experiencia demuestra que las diversas organizaciones y dominios del problema requieren diversos procesos de desarrollo UML puede ser utilizado en esos procesos. Sin embargo, el UML promueve el desarrollo de procesos manejados por casos de uso, centrado en arquitectura, iterativos e incrementales. Es por ello que los esfuerzos se centraron primero en crear un metamodelo comn y luego en una notacin comn. Liza C., Modelando CON UML PRINCIPIOS Y APLICACIONES. Primera Edicin. Limusa. Espaa. 2002

15

3.6.- LENGUAJES DE PROGRAMACIN El UML es un lenguaje de modelamiento visual, en el sentido del tener toda la ayuda visual y semntica necesaria para substituir lenguajes de programacin, sin embargo, no est pensado para ser un Lenguaje de Programacin Visual. El UML es un lenguaje para visualizar, especificar, construir, y documentar los artefactos de un sistema orientado a objetos donde se har uso intensivo del software, y solo le indica el camino cuando usted tenga que implementar el cdigo. El UML especifica mediante grficos lo que una familia de lenguajes Orientados a Objetos debe hacer. 3.7.- VISTAS DE UN MODELO Para desarrollar un sistema es necesario verlo desde diferentes perspectivas, lo que da lugar a diferentes vistas del sistema, dependiendo de lo que deseamos mostrar en un instante determinado.
Vista de diseo diseo Vista de los casos de uso Vista de despliegue Vista de implementacin

Vista de procesos

Fig. N 01.- Vistas de un Modelo La vista de casos de uso, muestra la descripcin del comportamiento del sistema tal como lo observan los usuarios finales. La vista de diseo, muestra los servicios que nuestro sistema debe proporcionar y como lo har. Comprende las clases, interfaces y colaboraciones. La vista de procesos, comprende los hilos y procesos que forman mecanismos de sincronizacin y concurrencia del sistema. La vista de implementacin, comprende los componentes que un sistema utiliza para hacer disponible el sistema fsico.
16

La vista de despliegue, contiene los nodos que forman la topologa del hardware sobre la que se ejecuta el sistema. Cada una de estas vistas se puede representar mediante los diagramas UML. Liza C., Modelando CON UML PRINCIPIOS Y APLICACIONES. Primera Edicin. Limusa. Espaa. 2002 3.8.- DIAGRAMAS UML El UML puede describir cualquier tipo de sistema en trminos de diagramas orientados a objetos. Entre los diferentes tipos tenemos sistemas de informacin, sistemas de tiempo real, sistemas embebidos, sistemas distribuidos, software de sistemas, sistemas de negocios. Los diagramas se utilizan para dar diferentes perspectivas del problema segn lo que nos interese representar en un determinado momento. Los diagramas que UML define son: 1.- Diagramas de Casos de Uso 2.- Diagramas de Clases 3.- Diagramas de Objetos 4.- Diagramas de Secuencia 5.-Diagramas de Colaboracin 6.- Diagramas de Estado 7.- Diagramas de Actividad 8.- Diagramas de Componente 9.- Diagramas de Despliegue

17

Estos diagramas proveen mltiples perspectivas del sistema bajo anlisis o desarrollo; adems, estos diagramas soportan una adecuada documentacin y algunas herramientas de software, pueden mostrar diferentes vistas a partir de estos diagramas. Este libro cubre la descripcin de estos diagramas mediante ejemplos que le permitirn adiestrarse en su construccin, y capacitarlo para poder enfrentar al mundo real construyendo sus propios modelos. El siguiente diagrama representa cmo los diferentes diagramas sirven para expresar modelos y, en qu captulo de esta obra trataremos cada uno de ellos.

3.9.- DIAGRAMAS DE CASOS DE USO En pocas palabras un Diagrama de Casos de Uso representa lo que hace el sistema y como se relaciona con su entorno. Un Diagrama de Casos de Uso representa los distintos requerimientos que le hacen los usuarios al sistema, especificando las caractersticas de funcionalidad y comportamiento durante su interaccin con los usuarios u otros sistemas. A dichas funcionalidades se le conocen como Casos de Uso propiamente dichos, mientras que a los que provocan su ejecucin se les conoce como Actores. Los Casos de Uso y Actores interactan produciendo Relaciones. CASOS DE USO

Fig. N 02.- Vistas de un Modelo de Caso de Uso Un Caso de Uso (Use Case) es una secuencia de acciones realizadas por el sistema que producen un resultado observable y valioso para alguien en particular. Todo sistema ofrece a sus usuarios una serie de servicios. Un caso de uso es
18

justamente una forma de representar como alguien (persona u otro sistema) usa nuestro sistema. El Caso de Uso al dar una respuesta a un evento que inicia un agente externo (llamado actor), deben ser desarrollados en funcin a lo que los usuarios necesitan. Un caso de uso es pues en esencia una interaccin tpica entre el usuario y el sistema, aunque un caso de uso tambin puede ser invocado por otro caso de uso. La idea fundamental en los Casos de Uso es definir los requerimientos desde el punto de vista de quien usa el sistema y no de quien lo construye. De esta manera, nos aseguramos que los Casos de Uso permitan conocer los requerimientos del usuario para poder construir el software y denotan una operacin completa desarrollada por el sistema. Debemos mencionar que se puede aplicar la tcnica de los Casos de Uso a todo el sistema, a partes del sistema incluyendo a sus subsistemas, o a un elemento individual como pueden ser las clases e interfaces. 3.10.- ACTORES. Un Actor es un conjunto uniforme de personas, sistemas o mquinas externos al sistema que estamos rol determinado y que interactan con l. El Actor, modela un tipo de objeto fuera del dominio, del sistema pero que interacta directamente con l; lo que significa que, al definirlos empezamos a dar los lmites a nuestro sistema. Un Actor es un rol que un usuario juega con respecto al sistema. El Rol es un concepto tomado del teatro y ci interpretar varios personajes, cada persona debemos confundir el trmino Actor con Usuario, Un usuario es aquel que accede al sistema pudiendo asumir diferentes roles (comprador, vendedor, cobrador, etc.); as, cada usuario puede acceder al sistema asumiendo el rol de diferentes actores. Un Actor tiene de Uso que se comunica con l.

19

Los dispositivos de hardware y sistemas que estamos modelando tambin pueden ser considerados Actores. 3.11.- REPRESENTACIN GRFICA DE UN ACTOR Los actores se representan mediante "hombres de palo" (stick man) tal como se muestra ms adelante. Usted puede utilizar los mecanismos de extensin previstos en el UML para estereotipar un Actor proveyendo un icono diferente que pueda ofrecer mejor visibilidad para su propsito. Por ejemplo puede representar un Actor mediante un rectngulo con el estereotipo actor. Recuerde que un actor tambin es un clasificador y por lo tanto puede representarse como una clase. Cada tipo actor tiene un conjunto de especificaciones idnticas a la especificacin de una clase esto es un conjunto de compartimentos, pero con el campo adicional del estereotipo actor. Cuando el Actor resulta ser un Sistema se suele representar mediante una computadora, para resaltar este hecho.

3.12.- DIAGRAMA DE CLASES Muestran un conjunto de clases (grupos de objetos que tienen las mismas caractersticas y comportamiento), as como sus relaciones. Estos diagramas son los ms comunes en el modelado de sistemas orientados a objetos y cubren la vista esttica de un sistema. Un diagrama de estructura esttica muestra el conjunto de clases y objetos importantes, que conforman un sistema, junto con las relaciones existentes entre los mismos, pero no como actan unos con otros, ni que mensajes se envan. Un diagrama de clases esta compuesto por los siguientes elementos: Clases: Las cuales contienen atributos y operaciones.

20

Relaciones: Que pueden ser Dependencia, Generalizacin y Asociacin. Otros diagramas de estructura esttica los constituyen los diagramas de objetos, de componentes y de distribucin. 3.13.- DIAGRAMA DE OBJETOS Dado que las clases son agrupaciones de cosas necesitamos un diagrama que nos muestre las ocurrencias de cada elemento que constituye la clase, a cada uno de estos elementos se les llama Objetos. Un Objeto se define como una instancia de una clase. As, estas ocurrencias se representan mediante un Diagrama de Objetos. Los Diagramas de Objetos muestran un conjunto de objetos y sus relaciones, son como fotos instantneas de los Diagramas de Clase y tambin cubren la vista de procesos esttica desde la perspectiva de ocurrencias reales o prototpicas. 3.13.1.- CLASE Una Clase es un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. En otras palabras, una clase describe un conjunto de objetos con caractersticas y comportamiento idntico, se puede decir que las clases son como una plantilla para formar objetos. Las clases sirven para abstraer objetos del mundo real y a travs de ella podemos modelar el entorno en estudio. La Clase es un concepto similar a Entidad en un modelo entidad/relacin esto es "un conjunto de objetos que tienen las mismas caractersticas", Sin embargo, al concepto de Clase a diferencia del concepto de Entidad, se le ha agregado el comportamiento, incluyendo las operaciones que puede realizar a travs de sus mtodos. 3.13.2.- REPRESENTACIN GRFICA En UML, una clase es representada mediante un rectngulo por lo general con tres divisiones internas llamadas compartimientos, en los cuales se indica el nombre de la clase, sus atributos y operaciones, tal como se muestra en el diagrama y en donde:
21

Fig. N 03.- Forma de Representar una Clase

Compartimiento Superior: Contiene el nombre de la Clase. Compartimiento Intermedio: Contiene los atributos que caracterizan a la Clase. Compartimiento Inferior: Contiene las operaciones, los cuales son la forma como interacta un objeto de la clase con su entorno. Adicionalmente, podemos colocar otros compartimientos en los cuales se pueden describir, en texto libre, otras caractersticas de las clases como pueden ser sus responsabilidades, esto es, los objetivos que persigue la clase. No es necesario mostrar todos los compartimentos a la vez, sino que ms bien depende de lo que queramos visualizar en un momento determinado, dejando a la herramienta de software que nos muestre u oculte las partes segn nuestra conveniencia.

3.14.- DIAGRAMA DE SECUENCIA Es un tipo de Diagrama de Interaccin que muestra justamente la interaccin de un conjunto de objetos, poniendo nfasis en el orden cronolgico del envo de mensajes entre objetos. Mediante los Diagramas de Secuencia podemos dar detalle a los Casos de Uso, aclarndolos al nivel de mensajes de los objetos existentes, como tambin muestra el uso de los mensajes de las clases diseadas en el contexto de una operacin.
22

La creacin de los Diagramas de Secuencia forma parte de la investigacin para conocer el sistema, por lo que es parte del anlisis del mismo. La creacin de los Diagramas de Secuencia depende de la formulacin de los casos de uso, por que durante la operacin del sistema, los actores generan eventos, solicitando alguna operacin. 3.14.1.- REPRESENTACIN GRFICA Los objetos que interactan se colocan a lo largo de una lnea horizontal imaginaria (el eje x), mientras que los mensajes enviados por estos objetos se van colocando a lo largo del eje Y, y segn su orden de aparicin cronolgica, donde mientras ocurran ms tarde, ms abajo se ubicarn. El objeto que inicia la interaccin se coloca en la parte superior izquierda del diagrama, mientras que los otros objetos se van colocando sucesivamente hacia la derecha del mismo. Para su representacin se hace uso de diferentes elementos tales como: objetos, actores, lneas de vida, focos de control y mensajes los cuales le dan el aspecto mostrado en la figura adjunta.

Fig. N 04.- Forma de Representar una Diagrama de Clase

23

A continuacin explicamos cada uno de estos elementos. Se representan mediante un rectngulo que contiene el nombre del objeto y el de su fase, en el formato nombreObieto: nombreClase. Segn se especifique el nombre completo o no, el objeto puede ser: Clase.- Si slo el nombre de la clase se muestra en el recuadro. Instancia annima.- Si el nombre se escribe de la forma :nombreClase Instancia con nombre.- Al nombrarlo as nomlnstancia:nomClase
nomObjeto:nomClase

3.14.2.- LNEA DE VIDA DE UN OBJETO Indica la vida de un objeto durante la interaccin y se representa como una lnea vertical punteada debajo del rectngulo del objeto, tal como se muestra en el diagrama de la derecha. Debe tenerse en cuenta que algunos objetos pueden ser creados y destruidos por la interaccin. La creacin se muestra mediante una lnea estereotipada con create, mientras que la destruccin se muestra mediante una X al final de su lnea de vida.

3.14.3.- ACTIVACIN O FOCO DE CONTROL Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operacin, bien sea por s mismo o por medio de delegacin a travs de alguno de sus procedimientos subordinados. Se representa mediante un rectngulo delgado

24

sobre la lnea de vida del objeto. El tope del rectngulo es alineado con el inicio de la accin, la parte inferior se alinea con su trmino. 3.14.4.- MENSAJE El envo de mensajes entre objetos se representa mediante una lnea slida

dirigida con cabeza de flecha abierta, desde el objeto emisor del mensaje hacia el objeto receptor. Este ltimo ejecutar la accin indicada por el emisor. Tambin es posible que un objeto se invoque a si mismo tal como se muestra en el diagrama adjunto. El UML permite variaciones al smbolo del mensaje para especificar algn comportamiento especfico, tal como explicamos a continuacin. Mensaje Asncrono.- El cliente enva un mensaje al proveedor para que lo procese, y contina con la ejecucin de su cdigo, sin esperar o sin contar con que el proveedor recepcione y procese el mensaje. Es representado mediante media cabeza de flecha abierta. Mensaje de llamada a procedimiento.- Una llamada a un procedimiento u otro flujo de control anidado es representado por una flecha con cabeza rellena. Toda la secuencia de anidamiento es completada antes de salir del nivel. Puede ser usado para llamadas a procedimientos ordinarios. El retorno es mostrado por una flecha discontinua con cabeza rellena. En un flujo de control procedimental, la flecha de retorno puede ser omitida, pues est implcito al termino de la activacin. Esto es asumido porque todas las llamadas retornan despus de haber sido invocadas. El valor de retorno puede ser mostrado sobre la flecha inicial. Para flujos de control no procedimentales como procesamiento paralelo y mensajes asncronos los valores retornados deben ser mostrados explcitamente. Mensajes Concurrentes.- En un sistema concurrente, una cabeza de flecha rellena muestra un mensaje correspondiente a un hilo de control y una media

25

cabeza de flecha muestra el envo de un mensaje fuera de su correspondiente hilo de control.

3.15.- DIAGRAMA DE COLABORACIN Es un tipo de Diagrama de Interaccin que muestra justamente la interaccin de un conjunto de objetos, poniendo nfasis en la estructura organizacional de los objetos que envan y reciben mensajes. Los Diagramas de Colaboracin muestran la colaboracin entre los objetos para realizar una tarea mediante el uso de mensajes enviados entre ellos. A diferencia de los Diagramas de Secuencia, stos diagramas pueden mostrar el contexto de la operacin, y no reservan una dimensin para el tiempo, sino que enumeran los mensajes para indicar la secuencia.

3.15.1.- OBJETO Se representa con un rectngulo, que contiene el nombre y la clase del objeto en un formato
nomObieto:nomClase

nombreObieto: nombreClase. Cuando slo se hace referencia a la clase no se subraya. Los mensajes enviados a estas clases se utilizan para invocar a los mtodos de clase. En otras ocasiones se hace referencia a una instancia de la clase pero no se indica el nombre. La forma ms comn es darle un nombre a una instancia indicando su clase.
nomObjeto:nomClase :NombreClase NombreClase

26

3.15.2.- FORMAS EN QUE SE PRESENTAN LOS OBJETOS

En los Diagramas de Colaboracin, los objetos pueden presentarse de diversas formas, estos pueden ser: Objetos Comunes, Objetos Activos, Objetos Multiobjetos y Objetos Compuestos.

Fig. N 05.- Forma de Representar objetos en Diagramas de Colaboracin 3.16.- DIAGRAMA DE ESTADO Un Diagrama de Estados muestra el conjunto de estados por los cuales pasa un nico objeto durante su vida dentro de una aplicacin, junto con los eventos que provocan las transiciones que permiten pasar de un estado a otro. En los Diagramas de Estado suponemos que se procesa un evento a la vez y termina con todas las consecuencias antes de pasar a otro. Los eventos no interaccionan con otros eventos y conceptual mente las acciones son instantneas (esto significa atmicas y no interrumpibles) y los eventos nunca son simultneos. Si un objeto recibe un evento mientras esta ejecutando una accin, el evento se pone en cola hasta que finalice la accin. Un Diagrama de Estado, se utiliza para describir el comportamiento de un elemento de nuestro modelo, mostrando la posible secuencia de estados en los que puede entrar el objeto y como cambia al reaccionar ante un evento durante su ciclo de vida, as un Diagrama de Estados representa a entidades capaces de un comportamiento dinmicos en respuesta a un evento recibido. Comnmente, es
27

utilizado para describir el comportamiento de Clases, pero los Diagramas de Estados pueden describir el comportamiento de otros elementos como casos de uso, actores, subsistemas, operaciones o mtodos, etc. 3.16.1.- REPRESENTACIN GRFICA

Un Diagrama de Estados muestra diversos elementos como pueden ser: estados, eventos, transiciones, etc., que le dan el aspecto como el mostrado en la figura adjunta.

Fig. N 06.- Forma de Representar un Diagrama de Estado 3.16.2.- ESTADO Un Estado queda definido por ciertas caractersticas que un objeto mantiene en un periodo de tiempo, en el cual el objeto puede recibir cierto tipo de estmulos como alguna condicin, operacin u evento. Los estados no son instantneos, sino que tienen un tiempo de duracin. Se representa mediante un rectngulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre del estado, otro para las variables de estado (que son los valores caractersticos de los atributos del objeto en ese estado), y otro para las acciones.
28

Por lo general se muestra solo el nombre del estado, a veces incluyendo las acciones y muy pocas veces las variables de estado, pero tenemos la libertad de usarlos segn el nivel de detalle que deseemos. 3.17.- DIAGRAMA DE ACTIVIDAD Un Diagrama de Actividad muestra la realizacin de operaciones para conseguir un objetivo. Presentan una visin simplificada de lo que ocurre en un proceso, mostrando los pasos que se realizan, constituyndose en uno de los diagramas que modelan los aspectos dinmicos del sistema. Como recordar otros diagramas que muestran los aspectos dinmicos de un sistema son los Diagramas de Estado, de Secuencia y Colaboracin. Los Diagramas de Actividad difieren de los de Interaccin (Secuencia y Colaboracin) en que no muestran como los objetos se pasan mensajes. Sin embargo, los Diagramas de Actividad, son una extensin de los Diagramas de Estado. Los Diagramas de Estado resaltan los estados y muestran las actividades que dan lugar a cambios de estado, mientras que los Diagramas de Actividad, resaltan justamente las actividades. Un Diagrama de Actividad es un caso especial d~ un Diagrama de Estados, pues representan los estados de ejecucin no los estados propiamente dichos de un objeto. Comnmente los Diagramas de Actividad se utilizan en dos formas. En el modelado de flujos de trabajo, haciendo hincapi en las actividades tal y como son vistas por los actores que colaboran con el sistema, esto es, modelando procesos de negocios. En el modelado de una operacin, utilizando los diagramas de actividades como diagramas de flujo para mostrar detalles de un algoritmo, haciendo amplio uso de las condiciones y modelado de procesos concurrentes. Cuando se usa los Diagramas de Actividad para modelar operaciones es muy fcil obtener el cdigo del programa (esto se conoce como ingeniera directa), asimismo si tuviramos el cdigo fuente podemos obtener su respectivo Diagrama de Actividades (esto es ingeniera reversa). En este sentido los Diagramas de Actividad son un excelente va para lograr la ingeniera de ida y vuelta.

29

Los Diagramas de Actividades, pueden pues, ser utilizados para modelar cualquier situacin y dar detalle a casos de uso. Cada caso de uso que fue descrito como texto informal ahora puede detallarse con cero, uno o varios Diagramas de Actividad. 3.17.1.- REPRESENTACIN GRFICA Grficamente un Diagrama de actividad es una coleccin de rectngulos redondeados, lneas gruesas, crculos rellenos, rombos, pentgonos, etc. que representan actividades, acciones, barras de sincronizacin, indicadores de inicio y trmino, decisiones, carriles, flujo y estados de objetos, recepcin y envo de seales, eventos diferidos, que le dan el aspecto mostrado en el diagrama adjunto.

Fig. N 07.- Forma de Representar un Diagrama de Actividades

30

3.17.2.- ACTIVIDAD Una Actividad representa la realizacin de una o varias tareas que causa un cambio en el sistema. Una Actividad puede estar compuesta por otras actividades y por acciones, y puede ser descompuesta en otros Diagramas de Actividad, es decir una Actividad no es atmica, pueden ser interrumpidas y, se considera que toma algn tiempo en completarse. 3.17.3.- ACCIN Una Accin es una de Actividad que no se puede descomponer ms. Las acciones son atmicas y aunque ocurran eventos, no se interrumpe su ejecucin, dicha ejecucin toma un tiempo insignificante y permiten modelar un paso dentro de un algoritmo. Una accin puede ser descrita como lenguaje natural, pseudocdigo o en la sintaxis de algn lenguaje de programacin. 3.17.4.- REPRESENTACIN DE ACTIVIDADES Y ACCIONES Tanto la actividad como la accin, se representan por un rectngulo con bordes redondeados que son ms ovalados que el smbolo de estado y no debe confundirse con l. En realidad una actividad o una accin son estados en los cuales se esta ejecutando algo, es por eso que, a las actividades tambin se les conoce como Estados de Actividad y a las Acciones tambin se les llama Estados de Accin; sin embargo, nosotros las nombraremos simplemente como Actividad y Accin para evitar confusiones con los estados, y usaremos el trmino genrico Actividad para referimos a ambas cuando no sea importante su distincin.

31

3.17.5.- TRANSICIONES Cuando se completa la ejecucin de una actividad, el flujo de control pasa a la siguiente actividad dando lugar a una transicin. Este paso se representa mediante Una lnea dirigida que va de la actividad que finaliza hacia la actividad a ejecutar. Las flechas entre actividades representan transiciones, las cuales no deben ser etiquetadas pues son disparadas automticamente por la finalizacin de la primera actividad. 3.17.6.- DECISIONES En los diagramas de actividad se puede incluir caminos alternativos segn se cumpla alguna condicin. Esta condiciones se representa mediante un rombo al cual llega la transicin de la actividad origen y del cual salen las mltiples transiciones a cada actividad destino, cada una con una condicin diferente y sin un evento que las dispare. Se puede incluir la palabra else que indica que ninguna de las expresiones de guarda es verdad. Una expresin de guarda es aquella que puede tomar un valor de verdadero o falso. Alternativamente, podemos representar las decisiones sin el rombo, tal como se muestra en la figura. Sin embargo, el rombo es un smbolo de uso muy comn para estos casos, por lo que es preferible su uso, para darle ms claridad a los diagramas. 3.17.7.- REUNIN DE UNA BIFURCACIN Las decisiones implican dividir un flujo de control en varios caminos, as es que el UML tambin proporciona la forma de volver a unir estos flujos mediante el mismo smbolo. Esta accin de unir dos flujos que han sido separados se conoce como merge. Un merge tiene dos o ms flujos entrantes pero solo un saliente. Esto no debe confundirse con unir los flujos de procesos que fueron divididos por su capacidad de poder ejecutarse en paralelo, en estos casos se debe hacer mediante las barras de sincronizacin que explicamos a continuacin.

32

3.17.8.- BARRAS DE SINCRONIZACIN Cuando modelamos flujos de procesos, especialmente en los procesos de negocio, nos encontramos con actividades que se pueden realizar

simultneamente. Los Diagramas de Actividad tienen un smbolo que indica la ejecucin de procesos al mismo tiempo (concurrentes), que lo diferencia de los diagramas de flujo tradicionales, los cuales no pueden modelar procesos que pueden realizarse en paralelo. Estas actividades se pueden modelar con ayuda de las Barras de Sincronizacin. Una barra de sincronizacin se representa como una lnea vertical u horizontal gruesa. En el diagrama de la derecha se muestra que el flujo de actividades se divide en dos, cada una de las cuales es independiente de la otra y se ejecuta por separado. Al terminar la ejecucin de ambas, el flujo se vuelve a unir mediante otra barra de sincronizacin. 3.17.9.- INICIO Y TERMINACIN Un flujo de control debe de empezar en algn sitio y terminar en otro a menos que se trate de un flujo infinito. El inicio se representa mediante un crculo completamente relleno, mientras que el trmino se representa con un crculo relleno dentro de una circunferencia. 2.18.- DIAGRAMAS DE COMPONENTES Los Diagramas de Componentes permiten visualizar las partes de un sistema, mostrando las diversas formas en que pueden ensamblarse para construir ejecutables. Un Diagrama de Componentes muestra las dependencias entre componentes fsicos de software, tales como archivos de cdigo fuente, binarios, de configuracin, de instalacin y des instalacin, ejecutables, tablas, etc. Los Diagramas de Componentes modelan la vista esttica de los sistemas, es decir solo los componentes y sus conexiones, y no como funcionan. Asimismo, este diagrama facilita la realizacin de ingeniera directa (del diagrama al software), puesto que representan cosas fsicas que se implementan directamente en
33

archivos, e ingeniera reversa (del software al diagrama) que permite obtener el diagrama de componentes a partir del software, aunque esto ltimo no sea un proceso perfecto, pues el software no muestra por s mismo muchas de las relaciones entre componentes. Siempre que construya un diagrama de componentes debe pensar en que esta modelando una dimensin fsica del software; esto es, cmo los componentes se almacenan en archivos de disco. Un componente de software constituye en una entidad real y no solo en un concepto. Tambin en este diagrama, debemos mostrar la realizacin de un conjunto bien definido de interfaces e implementar las clases que trabajan juntas para proveer dichas interfaces. Los diagramas de componentes estn formados por: componentes, interfaces y relaciones entre ellos. Estas relaciones pueden ser de dependencia,

generalizacin y asociacin; adems, pueden contener los elementos comunes a todos los diagramas UML como son las notas y paquetes. 3.18.1.- COMPONENTES Son cada una de las partes fsicas y reemplazables de un sistema formados por un conjunto de elementos lgicos como las clases y colaboraciones que proveen la realizacin de un conjunto de interfaces. Se dice que es parte fsica en el sentido en que viven en el mundo de bits y no slo en el mundo lgico de los esquemas conceptuales, as un componente se encuentra en la computadora y no en la mente del analista. Se dice que es reemplazable pues puede ser sustituido por un nuevo componente que mejore la funcionalidad o aada alguna otra, sin que afecte a otros componentes. Esto se logra mediante el uso de interfaces bien definidas. As pues, los componentes no se ejecutan solos, sino que necesitan de otros componentes para poder hacer que el sistema cumpla su cometido, constituyendo una parte importante en cualquier software. El beneficio que se busca al crear componentes es proveer de interfaces bien definidas, haciendo posible el fcil mantenimiento y reemplazo de los componentes por otros nuevos, mejores y compatibles sin mayor riesgo. Si
34

tenemos una clase podemos especificar la interfaz para utilizarla, los componentes justamente implementan esta interfaz para poder utilizar a la clase. As, cada componente puede ser fcilmente rehusado por otros sistemas, siempre y cuando dichos componentes provean de un claro conjunto de interfaces que faciliten su utilizacin. 3.18.2.- REPRESENTACIN DE COMPONENTES Los componentes se representan con un rectngulo que tiene en uno de sus lados dos pequeos rectngulos sobresalientes, tal como se muestra en la figura adjunta. Todo componente debe tener un nombre que lo distinga de otros. Estos nombres pueden ser simples (simple name) o nombres camino (path name). Sern nombres simples cuando solo colocamos el nombre, mientras que sern nombres camino si indicamos el paquete al que pertenece. Por ejemplo system::kerneI32.dll ser un path name, mientras que kernel32.dll ser un simple name. En ocasiones es conveniente mostrar las clases que implementa el componente dentro de l, ya sea solo con su nombre o con los rectngulos representativos de las clases.

Fig. N 08.- Forma de Representar un Diagrama de Componentes

35

3.18.3.- TIPOS DE COMPONENTES Se pueden distinguir tres tipos de componentes: Componentes de trabajo.- Son aquellos componentes que contienen el cdigo del programa, como los archivos de cdigo fuente. Componentes de distribucin.- Son aquellos que se instalan con la versin ejecutable del sistema como DLLs, ejecutables, controles Active X, Java Beans, etc. Componentes creados en tiempo de ejecucin.- Son aquellos producto de la ejecucin del software, como los archivos de ndice de las ayudas, los archivos temporales, etc. 3.18.4.- ESTEREOTIPOS DEFINIDOS UML define cinco estereotipos estndar para los componentes, los cuales se indican a continuacin y se muestra su icono el cual es de Uso comn entre los desarrollado res aunque el UML no los especifica. 1. executable.- son aquellos componentes que pueden ejecutarse en un nodo. 2. library.- son las libreras de nuestros programas ya sean estas del tipo estticas o dinmicas. 3. table.- un componente que es una tabla de una base de datos. 4. file.- un componente que es un archivo de cdigo fuente, datos o simplemente texto. 5. document.- un componente que es un documento, como las ayudas, archivos word, etc. Los mecanismos de extensin del UML, permiten definir cualquier otro estereotipo que sea necesario para su sistema y asignarle el icono apropiado, lo nico que debe tener en cuenta es que sea usado de manera consistente. .
36

3.19.- DIAGRAMAS DE DESPLIEGUE El Diagrama de Despliegue, modela la topologa del hardware sobre el cual correr nuestro aplicacin y nos indica en donde se ejecutar cada uno de nuestros componentes; esto es, muestra las relaciones fsicas entre los componentes de software y el hardware de nuestro sistema. Los Diagramas de Despliegue muestran la forma en que fsicamente lucir nuestro sistema, slo deben mostrarse los nodos y componentes que se utilizarn en su versin ejecutable. Los componentes que no existen en tiempo de ejecucin no se muestran en este diagrama, sin embargo, pueden ser mostrados en sus respectivos Diagramas de Componentes. 3.19.1.- NODOS Es un elemento fsico que representa un recurso computacional, generalmente cuentan con memoria y capacidad de proceso y tambin pueden incluir recursos humanos o procesos mecnicos. En palabras menos formales podemos decir que un nodo es la representacin de cualquier tipo de hardware sobre el cual correr nuestro sistema. 3.19.2.- REPRESENTACIN DE NODOS Un nodo se representan mediante un cubo en cuyo interior se incluye un nombre que lo distinga de otros.

Fig. N 09.- Forma de Representar un Nodo

37

Estos nombres pueden ser simples (simple name) o nombres camino (path name). Sern nombres simples cuando solo colocamos el nombre, mientras que sern nombres camino si indicamos el paquete al que pertenece. Por ejemplo, server::backup ser un path name, mientras que backup ser un simple name. En los nodos podemos indicar valores etiquetados, o mostrar compartimientos adicionales para visualizar sus detalles. Por ejemplo, si el nodo es una computadora, podemos mostrar su velocidad, memoria y operaciones como prenderla, apagarla o suspenderla.

3.19.3.- TIPOS DE NODOS Los nodos pueden ser de dos tipos: Procesador (Processof).- Es un tipo de nodo que tiene capacidad de proceso. Tenemos por ejemplo: la computadora cliente, la computadora servidor, etc. Dispositivo (Device).- Este tipo de nodo no tiene capacidad de proceso y representa las interfaces con el mundo real. Tenemos por ejemplo: el fax, la impresora, el telfono, etc. Segn el tipo de nodo, el cubo que lo representa puede estereotiparse como processor o device indicando de esta manera, si el ndo es un procesador o un dispositivo. Como veremos a continuacin podemos cambiar la figura del cubo por otra ms representativa.

38

3.19.4.- CONEXIONES ENTRE NODOS Los nodos se conectan mediante asociaciones de comunicacin. Una asociacin entre nadas, representa una conexin no necesariamente fsica, entre nadas. Como ejemplos de conexiones fsicas tenemos una conexin serial RS232, una 10-T Ethernet, una lnea de bus, un cable telefnico. Como ejemplos de conexiones inalmbricas tenemos una conexin satelital, una infrarroja, etc. Cada una de estas conexiones puede ser indicada estereotipndola con una descripcin adecuada. Como toda asociacin se puede aadir detalles segn se necesite, tales como roles, multiplicidad, restricciones, etc. Fuente: Larman, C. UML y Patrones: Una introduccin al anlisis y diseo orientado a objetos y al proceso unificado. Segunda Edicin. Prentice-Hall, 2002 3.20.- INTRODUCCION AL SQL SERVER 3.20.1.- BASE DE DATOS Introduccin Los sistemas orientados a los datos se caracterizan porque los datos no son de una aplicacin sino de una Organizacin entera que los va a utilizar. Se tiende a integrar las aplicaciones, evitando aplicaciones aisladas. Se diferencian las estructuras lgicas y fsicas, de manera que el usuario final solo se vincule con las estructuras lgicas. La descripcin de la estructura lgica se separa de los lenguajes de programacin. Definicin Martin: Coleccin integrada y generalizada de datos, estructurada atendiendo a las relaciones naturales de modo que suministre todos los caminos de acceso necesarios a cada unidad de datos con objeto de poder atender todas las necesidades de los diferentes usuarios. Date: Una base de datos consiste en alguna coleccin de datos persistentes e independientes usados por una organizacin determinada
39

 Caractersticas a. Integrada: Una base de datos puede considerarse como una unificacin de varios archivos de datos independientes, donde se elimina parcial o totalmente cualquier redundancia entre los mismos. b. Compartida: La Base de Datos pueden compartirse entre varios usuarios distintos, en el sentido que cada uno de ellos puede tener acceso a la misma parte de la Base de Datos y utilizarla con propsitos diferentes.

Objetivos a. Independencia de Datos (Flexibilidad): Los cambios en las aplicaciones no deben imponer un nuevo diseo o viceversa. b. Coste mnimo: Adaptacin rpida y con coste mnimo a las nuevas caractersticas de una organizacin. c. Consistencia y mnima redundancia (Integridad): Evitar repeticin innecesaria de datos y la incoherencia entre ellos. d. Datos Compartidos: Permitir una mayor disponibilidad de los datos. e. Versatilidad en la representacin de los datos: Distintos usuarios quieren ver de manera distinta los datos. f. Integridad: Garantizar la exactitud y veracidad de los datos. g. Tolerancia a fallos y seguridad: Proteccin de los datos ente acceso no autorizados y fallos.

Ventajas.

Facilidad de manejo de grandes volumen de informacin. Gran velocidad de respuesta a requerimientos en muy poco tiempo. Independencia del tratamiento de informacin. Seguridad de la informacin (acceso a usuarios autorizados), proteccin de informacin, de modificaciones, inclusiones, consulta.
40

No hay duplicidad de informacin, comprobacin de informacin en el momento de introducir la misma.

Integridad referencial el terminar los registros.

Desventajas.

El costo de actualizacin del hardware y software son muy elevados. Costo (salario) del administrador de la base de datos es costoso. Tanto el mal diseo de esta puede como el un mal adiestramiento a los usuarios originan problemas a futuro.

3.20.2.- Sistema de Gestin de Bases de Datos(SGBD) Los Sistemas Gestores de Bases de Datos son un tipo de software muy especfico, dedicado a servir de interfaz entre la Base de datos y el usuario, las aplicaciones que la utilizan. Se compone de un lenguaje de definicin de datos, de un lenguaje de manipulacin de datos y de un lenguaje de consulta. El objetivo principal de un SGBD es proporcionar un entorno que sea a la vez conveniente y eficiente para ser utilizado al extraer y almacenar informacin en la base de datos.

Existen distintos objetivos que deben cumplir los SGBD:

Abstraccin de la informacin. Los usuarios de los SGBD ahorran a los usuarios detalles acerca del almacenamiento fsico de los datos. Da lo mismo si una base de datos ocupa uno o cientos de archivos, este hecho se hace transparente al usuario.

41

Independencia. La independencia de los datos consiste en la capacidad de modificar el esquema (fsico o lgico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella.

Redundancia mnima. Un buen diseo de una base de datos lograr evitar la aparicin de informacin repetida o redundante. De entrada, lo ideal es lograr una redundancia nula; no obstante, en algunos casos la complejidad de los clculos hace necesaria la aparicin de redundancias.

Consistencia. En aquellos casos en los que no se ha logrado esta redundancia nula, ser necesario vigilar que aquella informacin que aparece repetida se actualice de forma coherente, es decir, que todos los datos repetidos se actualicen de forma simultnea.

Seguridad. La informacin almacenada en una base de datos puede llegar a tener un gran valor. Los SGBD deben garantizar que esta informacin se encuentra asegurada frente a usuarios

malintencionados, que intenten leer informacin privilegiada; frente a ataques que deseen manipular o destruir la informacin; o simplemente ante las torpezas de algn usuario autorizado pero despistado.

Normalmente, los SGBD disponen de un complejo sistema de permisos a usuarios y grupos de usuarios, que permiten otorgar diversas categoras de permisos.

Integridad. Se trata de adoptar las medidas necesarias para garantizar la validez de los datos almacenados. Es decir, se trata de proteger los datos ante fallos de hardware, datos introducidos por usuarios descuidados, o cualquier otra circunstancia capaz de corromper la informacin almacenada.

42

Respaldo y recuperacin. Los SGBD deben proporcionar una forma eficiente de realizar copias de seguridad de la informacin almacenada en ellos, y de restaurar a partir de estas copias los datos que se hayan podido perder.

Control de la concurrencia. En la mayora de entornos, lo ms habitual es que sean muchas las personas que acceden a una base de datos, bien para recuperar informacin, bien para almacenarla. Y es tambin frecuente que dichos accesos se realicen de forma simultnea. As pues, un SGBD debe controlar este acceso concurrente a la informacin, que podra derivar en inconsistencias.

Tiempo de respuesta. Se espera reducir el tiempo que el SGBD tarda en darnos la informacin solicitada y en almacenar los cambios realizados.

3.20.3.- FASES PARA LA CREACIN DE UNA BASE DE DATOS

Permiten obtener una buena construccin de una base de datos logrando atender las necesidades de una organizacin o empresa:

a).- Anlisis de Requerimientos y Diseo Conceptual La fase de anlisis de requerimientos produce una descripcin operacional de la base de datos. Su objetivo es asegurar que la base de datos contenga los datos necesarios para las funciones y aplicaciones donde se usara la base de datos. Esta fase es realizada normalmente por los diseadores de bases de datos a travs de entrevistas con los usuarios del sistema que ser realizado. En este sentido se dice que esta fase es una fase de: Adquisicin de Conocimiento. La salida de esta fase son los requerimientos del sistema.
43

La fase de Diseo Conceptual se alimenta del Anlisis de Requerimientos y produce un diseo que trata de reflejar como son los datos. Es una prctica comn que estas dos primeras fases sean hechas de manera participativa y a travs de refinamientos sucesivos a travs de la interaccin de los diseadores y los usuarios del sistema. El diseo conceptual trata de crear un Modelo Parcial donde se trata de capturar lo suficiente para poder soportar todas las funciones a las que servir el sistema final. El resultado final de esta fase es un Esquema de la Base de Datos. No necesariamente este esquema puede ser implementado directamente en algn manejador de base de datos. Dentro de esta fase es comn el uso del modelo Entidad Relacin. Una vez recogidos todos los requerimientos, el siguiente paso es crear un esquema conceptual para la base de datos mediante un modelo de datos conceptual de alto nivel. El esquema conceptual contiene una descripcin detallada de los requerimientos de informacin de los usuarios, y contiene descripciones de los tipos de datos, relaciones entre ellos y restricciones. Nosotros utilizaremos para el diseo de esquemas conceptuales el modelo E-R (entidad - relacin), que describe los datos como entidades, vnculos y atributos. El objetivo es comprender: La perspectiva que cada usuario tiene de los datos. La naturaleza de los datos, independientemente de su

representacin fsica. El uso de los datos a travs de las reas de aplicacin.

44

b).- Diseo Lgico El siguiente paso en el proceso de diseo consiste en implementar de hecho la base de datos con un Sistema Gestor de Base de datos comercial, transformando el modelo conceptual al modelo de datos empleados por el Sistema Gestor de Base de datos (jerrquico, red o relacional). El diseo lgico es el proceso de construir un esquema de la informacin que utiliza la empresa, basndose en un modelo de base de datos especfico, independiente del Sistema Gestor de Base de datos concreto que se vaya a utilizar y de cualquier otra consideracin fsica. En esta etapa, se transforma el esquema conceptual en un esquema lgico que utilizar las estructuras de datos del modelo de base de datos en el que se basa el Sistema Gestor de Base de datos que se vaya a utilizar, como puede ser el modelo relacional, el modelo de red, el modelo jerrquico o el modelo orientado a objetos. Conforme se va desarrollando el esquema lgico, ste se va probando y validando con los requisitos de usuario. La normalizacin es una tcnica que se utiliza para comprobar la validez de los esquemas lgicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no tienen datos redundantes. Esta tcnica se presenta en el captulo dedicado al diseo lgico de bases de datos. El esquema lgico es una fuente de informacin para el diseo fsico. Adems, juega un papel importante durante la etapa de mantenimiento del sistema, ya que permite que los futuros cambios que se realicen sobre los programas de aplicacin o sobre los datos, se representen correctamente en la base de datos. Tanto el diseo conceptual, como el diseo lgico, son procesos iterativos, tienen un punto de inicio y se van refinando continuamente. Ambos se deben ver como un proceso de aprendizaje en el que el diseador va comprendiendo el funcionamiento de la empresa y el significado de los datos que maneja.
45

El diseo conceptual y el diseo lgico son etapas clave para conseguir un sistema que funcione correctamente. Si el esquema no es una representacin fiel de la empresa, ser difcil, sino imposible, definir todas las vistas de usuario (esquemas externos), o mantener la integridad de la base de datos. Tambin puede ser difcil definir la implementacin fsica o el mantener unas prestaciones aceptables del sistema. Adems, hay que tener en cuenta que la capacidad de ajustarse a futuros cambios es un sello que identifica a los buenos diseos de bases de datos. Por todo esto, es fundamental dedicar el tiempo y las energas necesarias para producir el mejor esquema que sea posible. En esencia esta fase transforma el modelo Entidad - Relacin en tablas que podrn ser implementadas en un sistema manejador de base de datos particular.

c).- Diseo Fsico En este paso se especifican las estructuras de almacenamiento internas y la organizacin de los archivos de la base de datos. El diseo fsico es el proceso de producir la descripcin de la implementacin de la base de datos en memoria secundaria: estructuras de almacenamiento y mtodos de acceso que garanticen un acceso eficiente a los datos. Para llevar a cabo esta etapa, se debe haber decidido cul es el Sistema Gestor de Base de Datos que se va a utilizar, ya que el esquema fsico se adapta a l. Entre el diseo fsico y el diseo lgico hay una realimentacin, ya que algunas de las decisiones que se tomen durante el diseo fsico para mejorar las prestaciones, pueden afectar a la estructura del esquema lgico. Una vez que tenemos las tablas resultantes del Diseo Lgico es importante el decidir tanto la estructura de almacenamiento y las estrategias de acceso.
46

La estructura de almacenamiento se refiere a como almacenar los datos, y la estrategia de acceso se refiere a como llegar a los datos. Cada vez es ms comn que los sistemas manejadores de base de datos tengan ya predefinida la estructura de almacenamiento y estrategia de acceso. En general, el propsito del diseo fsico es describir cmo se va a implementar fsicamente el esquema lgico obtenido en la fase anterior. Concretamente, en el modelo relacional, esto consiste en: Obtener un conjunto de relaciones y las restricciones que se deben cumplir sobre ellas. Determinar las estructuras de almacenamiento y los mtodos de acceso que se van a utilizar para conseguir unas prestaciones ptimas. Disear el modelo de seguridad del sistema. Reducir el espacio de almacenamiento Optimizar los recursos de software y hardware 3.20.4.- ADMINISTRADOR DE BASE DE DATOS SQL SERVER a).- Qu es SQL Server? Microsoft SQL Server es un sistema de Administrador de Base de Datos Relacional cuya arquitectura es la de Cliente/Servidor basado en el Lenguaje de Consulta Estructurada. Las caractersticas de Cliente/Servidor: El procesador de divide una parte en el cliente y otra en el servidor El servidor se encarga de administrar las tablas, los ndices y la seguridad de los datos El cliente se encarga de mostrar los datos, solicitar y recoger los datos y actualizarlos.

47

b).- Base de Datos SQL Server Una base de datos est dividido en varios componentes lgicos, como tablas, ndices, vistas y otros elementos entre los principales son: Base de datos Tablas Diagramas de base de datos ndices Vistas Procedimientos almacenados Disparadores ndices Full-text Utilizando con SQL Server

c).- El Administrador de Servicios: se utiliza para iniciar, detener y pausar SQL Server (servicio MSSQLServer), el Agente SQL Server y el Coordinador de transacciones distribuidas de Microsoft (MS DTC). Servicio MSSQLServer.- SQL Server se ejecuta como servicio en Microsoft Windows NT con el nombre del MSSQLServer. En Windows 95 y 98 no se ejecuta como servicio, ya que el sistema operativo no acepta los servicios. Servicio SQLServerAgent.Admite caractersticas que permiten

programar actividades peridicas en SQL Server o la notificacin de los problemas que ocurren en el servidor a los administradores del sistema. Servicio MS DTC.- El Coordinador de transacciones distribuidas de Microsoft (MS DTC) en un administrador de transacciones que permite que las aplicaciones cliente incluyen varios orgenes de datos en una transaccin. MS DTC coordina la confirmacin de la transaccin distribuida entre todos los servidores que intervienen en dicha transaccin.

48

d).- El Administrador Corporativo: Facilita la configuracin y administracin de SQL Server y sus objetos. A travs de esta herramienta se puede hacer lo siguiente: Administrar inicios de sesin, permisos y usuarios Crear secuencia de comandos Administrar dispositivos de copia de seguridad y base de datos Crear una copia de seguridad de base de datos y registros de transacciones Administrar tablas, vistas, procedimientos almacenados, ndices, reglas, valores predeterminados y tipos definidos por el usuario. Importar y exportar datos Transformar datos Realizar diversas tareas de administracin Web

e).- El Analizador de Consultas: es una herramienta de consulta grfica que permite analizar el plan de una consulta, ejecutar mltiples consultas simultneamente, visualizar datos y manipular ndices.

3.20.5.- ARQUITECTURAS DE SQL SERVER a).- Arquitectura Cliente-Servidor Microsoft SQL Server est diseado para operar de forma eficiente en varios entornos: Como sistema de base de datos cliente-servidor Los sistemas cliente-servidor estn construidos de tal modo que la base de datos puede residir en un equipo central, llamado servidor y ser compartida entre variosusuarios. Los usuarios tienen acceso al servidor a travs de una aplicacin de cliente o de servidor:

49

Fig. N 10.- Arquitectura del SQL Server En un sistema cliente-servidor de dos estratos, los usuarios ejecutan una aplicacin en su equipo local, llamado cliente, que se conecta a travs de la red con el servidor que ejecuta SQL Server. La aplicacin de cliente ejecuta las reglas de la compaa y el cdigo necesario para presentar el resultado al usuario; tambin se conoce como cliente amplio. En un sistema cliente-servidor de varios componentes, la lgica de la aplicacin de cliente se ejecuta en dos ubicaciones: El cliente reducido se ejecuta en el equipo local del usuario y se encarga de presentar resultados al usuario. La lgica de la compaa se encuentra en aplicaciones de servidor que se ejecutan en un servidor. Los clientes reducidos solicitan funciones a la aplicacin de servidor, que, a su vez, es una aplicacin multiproceso capaz de operar con varios usuarios simultneos.

El tener los datos almacenados y administrados en una ubicacin central ofrece varias ventajas: Todos los elementos de datos estn almacenados en una ubicacin central en donde todos los usuarios pueden trabajar con ellos.
50

 Las reglas de la organizacin y las reglas de seguridad se pueden definir una sola vez en el servidor para todos los usuarios. Los servidores de base de datos relacionales optimizan el trfico de la red al devolver slo los datos que la aplicacin necesita. Los gastos en hardware se pueden minimizar. Las tareas de mantenimiento como las copias de seguridad y restauracin de los datos son ms sencillas porque estn concentradas en el servidor central. En los sistemas cliente-servidor grandes, miles de usuarios pueden estar conectados con una instalacin de SQL Server al mismo tiempo. SQL Server tiene una proteccin completa para dichos entornos, con barreras de seguridad que impiden problemas como tener varios usuarios intentando actualizar el mismo elemento de datos a la vez. SQL Server tambin asigna eficazmente los recursos disponibles entre los distintos usuarios, como la memoria, el ancho de banda de la red y la E/S de disco.

Como sistema de base de datos de escritorio Aunque SQL Server funciona muy eficientemente como servidor, tambin se puede utilizar en aplicaciones que necesiten bases de datos independientes almacenadas de forma local en el cliente. SQL Server se puede autoconfigurar dinmicamente para que se ejecute ms

eficientemente con los recursos disponibles en el cliente, sin tener que dedicar un administrador de bases de datos a cada cliente. Cuando los clientes utilizan bases de datos SQL Server locales, una copia del motor de bases de datos de SQL Server se ejecuta en el cliente y administra todas las bases de datos de SQL Server de dicho cliente. Las aplicaciones conectan con el motor de la base de datos casi de la misma forma en que se conectan a travs de la red con un motor de base de datos que se ejecuta en un servidor remoto.
51

Arquitectura de una Base de Datos Los datos de Microsoft SQL Server estn guardados en bases de datos. Los datos de una base de datos estn organizados en los componentes lgicos visibles por los usuarios. Adems, una base de datos est implementada fsicamente como dos o ms archivos de disco. Al utilizar una base de datos, se trabaja principalmente con los componentes lgicos, como tablas, vistas, procedimientos y usuarios. La implementacin fsica de los archivos es casi enteramente transparente. Normalmente, slo el administrador de la base de datos tiene que trabajar con la implementacin fsica. Cada instalacin de SQL Server tiene varias bases de datos. SQL Server tiene cuatro bases de datos del sistema (master, model, tempdb y msdb) y cada instalacin de SQL Server tiene una o varias bases de datos de usuario.

Arquitectura del servidor El servidor es el componente de Microsoft SQL Server que recibe las instrucciones SQL de los clientes y realiza las acciones necesarias para completar las instrucciones. Tiene las siguientes caractersticas:

Cmo el servidor compila cada una de las instrucciones SQL de proceso por lotes en un plan de ejecucin que indica al servidor cmo procesar la instruccin. Cmo el servidor administra los recursos de Microsoft Windows como memoria, subprocesos y tareas. Cmo el servidor transmite las llamadas a procedimientos almacenados remotos a los servidores remotos.

52

 Las caractersticas que permiten a SQL Server escalar desde pequeos equipos porttiles a los grandes servidores que proporcionan el principal almacenamiento de datos para las grandes empresas. Cmo el componente SQLMail integra SQLServer con los servidores de correo electrnico para permitir que el servidor enve correo y pginas cuando se produce un determinado suceso Fuente: Coronado, D. Anlisis y Diseo del Sistema Acadmico e Implementacin del Mdulo de Matrcula y Control de Pagos del Instituto de Educacin Superior Privado Cosmos- Piura. Universidad Pedro Ruiz Gallo Lambayeque, Per. 2004

3.20.6.- IMPLEMENTACIN DE UNA BASE DE DATOS Diseo de una Base de Datos Consideraciones acerca del diseo de bases de datos Es importante disear una base de datos para modelar con precisin las funciones empresariales, dado que la modificacin posterior del diseo de una base de datos ya implementada puede ser muy laboriosa. Por otra parte, una base de datos bien diseada ofrecer un mejor rendimiento. Cuando disee una base de datos, considere lo siguiente: Las reglas de normalizacin de la base de datos para evitar errores en el diseo de la base de datos. La proteccin de la integridad de los datos. Los requisitos de seguridad de la base de datos y los permisos de los usuarios. Los requisitos de rendimiento de la aplicacin. Deber asegurarse de que el diseo de la base de datos aprovecha las posibilidades que ofrece Microsoft SQL
53

 El mantenimiento. La estimacin del tamao de la base de datos.

Normalizacin El diseo lgico de la base de datos, que incluye las tablas y sus relaciones, es la clave de una base de datos relacional optimizada. La normalizacin de un diseo lgico de base de datos implica la utilizacin de mtodos formales para separar los datos en varias tablas relacionadas. Las bases de datos normalizadas se caracterizan por tener un mayor nmero de tablas estrechas (con pocas columnas). Un nmero escaso de tablas anchas (con ms columnas) suele ser caracterstico de las bases de datos no normalizadas. La normalizacin ofrece diversas ventajas: Mayor rapidez en la ordenacin y en la creacin de ndices. Un nmero mayor de ndices agrupados. Para obtener ms informacin. ndices ms estrechos y compactos. Menos ndices por tabla, con lo que se mejora el rendimiento de las instrucciones INSERT, UPDATE y DELETE. Menos valores NULL y reduccin de las posibilidades de incoherencia, con lo que la base de datos resulta ms compacta.

En la teora del diseo de bases de datos relacionales, las reglas de normalizacin identifican ciertos atributos que deben estar presentes en una base de datos bien diseada. A continuacin se hay algunas reglas que

pueden ayudarle a mejorar el diseo: Una tabla debe tener un identificador. La regla fundamental en la teora del diseo de bases de datos es que cada tabla tenga un slo identificador de filas, una columna o un conjunto de

54

columnas que puedan utilizarse para diferenciar a un registro de cualquier otro de la tabla. Una tabla slo debe almacenar datos para un nico tipo de entidad. Si intenta almacenar demasiada informacin en una tabla, la confiabilidad y la eficiencia en la administracin de los datos de la tabla pueden verse afectadas. En una tabla deben evitarse las columnas que acepten valores NULL. Las tablas pueden tener columnas definidas para permitir valores NULL. Un valor NULL indica que no hay ningn valor. Si bien puede resultar til permitir valores NULL en determinados casos, es preferible no utilizarlos muy a menudo, dado que necesitan un tratamiento especial que aumenta la complejidad de las operaciones con datos. Integridad de los datos Precisin y fiabilidad de los datos. La integridad de los datos es importante en los entornos de un solo usuario y de varios usuarios. En entornos multiusuario, en los que se comparten los datos, tanto el potencial como el costo de daos en los datos son elevados. En entornos de sistemas de administracin de bases de datos relacionales (RDBMS) a gran escala, la integridad de los datos es un aspecto muy importante. Seguridad de los datos Una de las funciones de una base de datos consiste en proteger los datos; para ello, se impide que determinados usuarios vean o modifiquen datos importantes y se evita que los usuarios en general cometan errores graves. El sistema de seguridad de Microsoft SQL Server controla qu usuarios pueden trabajar con qu tipo de datos y qu usuarios pueden realizar determinadas actividades en la base de datos.

55

 Rendimiento de la base de datos Cuando disee una base de datos, deber asegurarse de que realice todas las operaciones importantes rpida y correctamente. Cuando disee e implemente una base de datos, deber identificar las tablas de gran tamao y los procesos ms complejos que vaya a realizar la base de datos, y prestar atencin especial al rendimiento al disear esas tablas. Considere tambin los efectos que puede tener en el rendimiento el aumento del nmero de usuarios con acceso a la base de datos. Los siguientes cambios, entre otros, pueden contribuir a mejorar el rendimiento: Si una tabla que contiene cientos de miles de filas tiene que resumirse en un informe diario, puede agregar una o varias columnas que contengan datos previamente agregados para utilizarlos nicamente en el informe. Se puede aplicar una normalizacin exhaustiva en las bases de datos, lo que significa que se definen un gran nmero de tablas pequeas interrelacionadas. Adems de un diseo adecuado de la base de datos, el uso correcto de los ndices, sistemas RAID (matriz redundante de discos independientes) y los grupos de archivos es importante para conseguir un buen rendimiento.

Mantenimiento Despus de crear una base de datos, y cuando se hayan agregado y estn operativos todos los objetos y datos, ser necesario realizar determinadas operaciones de mantenimiento. Por ejemplo, es importante realizar copias de seguridad de la base de datos peridicamente. Es posible que tambin necesite crear algunos ndices adicionales para mejorar el rendimiento. A continuacin, se ofrecen algunas indicaciones para el mantenimiento:

56

 Disear la base de datos para que sea lo ms pequea posible y excluya la informacin redundante. (La normalizacin de la base de datos puede ayudarle a conseguirlo). Disear particiones de tablas en vez de tablas nicas, si la tabla debe contener un gran nmero de filas. Microsoft SQL Server proporciona el Asistente para planes de

mantenimiento de bases de datos con el fin de automatizar muchas de estas tareas, con lo que se reduce o se elimina el trabajo necesario para el mantenimiento de la base de datos.

Estimar el tamao de una base de datos Cuando disee la base de datos, puede que necesite realizar una estimacin del tamao que tendr la base de datos cuando est llena. Esta estimacin puede ayudarle a determinar la configuracin de hardware que necesitar para: Conseguir el rendimiento que necesitan sus aplicaciones. Asegurar la cantidad fsica adecuada de espacio en disco para almacenar los datos y los ndices. Asimismo, la estimacin del tamao de la base de datos puede ayudarle a determinar si el diseo de su base de datos necesita reajustes. Para realizar una estimacin del tamao de una base de datos, efecte una estimacin de cada tabla por separado y sume los valores obtenidos.

Fuente: Coronado, D. Anlisis y Diseo del Sistema Acadmico e Implementacin del Mdulo de Matrcula y Control de Pagos del Instituto de Educacin Superior Privado Cosmos- Piura. Universidad Pedro Ruiz Gallo Lambayeque, Per. 2004

57

3.21.-IBM RATIONAL ROSE. Herramienta de desarrollo basada en modelos que se integra con las bases de datos y los IDE de las principales plataformas del sector. Si necesita soporte para UML 2.0 y el mejor modelado de datos, incluido el modelo de entidad-relacin, consulte IBM Rational Software Architect, IBM Rational Software Modeler o IBM Rational Data y Application Modeling Bundle. IBM Rational Rose Enterprise es uno de los productos ms completos de la familia Rational Rose. Todos los productos de Rational Rose dan soporte a Unified Modeling Language (UML), pero no son compatibles con las mismas tecnologas de implementacin. Rational Rose Enterprise es un entorno de modelado que permite generar cdigo a partir de modelos Ada, ANSI C++, C++, CORBA, Java/J2EE, Visual C++ y Visual Basic. Al igual que todos los productos de Rational Rose, ofrece un lenguaje de modelado comn que agiliza la creacin del software. Incluye tambin estas funciones:

Soporte a modelos de anlisis, ANSI C++, Rose J y Visual C++ segn el documento "Design Patterns: Elements of Reusable Object-Oriented Software".

Los componentes del modelo se pueden controlar independientemente, lo que permite una gestin y un uso de modelos ms granular.

NUEVO: Soporte para compilacin y descompilacin de las construcciones ms habituales de Java 1.5.

Generacin de cdigo en lenguaje Ada, ANSI C++, C++, CORBA, Java y Visual Basic, con funciones configurables de sincronizacin entre los modelos y el cdigo.

Soporte para Enterprise Java Beans 2.0. Funciones de anlisis de calidad de cdigo.
58

Complemento de modelado Web que incluye funciones de visualizacin, modelado y herramientas para desarrollar aplicaciones Web.

Modelado en UML para disear bases de datos, que integra los requisitos de datos y aplicaciones mediante diseos lgicos y analticos.

Creacin de definiciones de tipo de documento DTD en XML. Integracin con otras herramientas de desarrollo de IBM Rational. Integracin con cualquier sistema de control de versiones compatible con SCC, como IBM Rational ClearCase.

Posibilidad de publicar en la Web modelos e informes para mejorar la comunicacin entre los miembros del equipo. fuente:Espaa, Comunidades IBM Bussines, http://www-

142.ibm.com/software/products/es/es/enterprise/ (Consultado 20/03/2010)

59

CAPITULO IV DESARROLLO DE LA SOLUCIN PROPUESTA

60

4.1. PICTOGRAMA.

Fig. N 11. Pictograma gestin de una licencia de edificacin

61

4.2.-MODELO DE PAQUETES.

SISTEMA DE CONTROL DE LICENCIAS DE EDIFICACION

GESTION DE ACOTACION

GESTION DE ACTA DE COMPROMISO DE PAGO

GESTION DE REGISTRO DE PAGOS

Fig. N 12. Representacin de paquetes del sistema. 4.3.-CASOS DE USO DE LOS PROCESOS DEL NEGOCIO

gestion de acotacion

fiscalizador

gestion de A.C.P Operador del sistema Contribuyente

gestion de registro de pagos Cajero

Fig. N 13. Representacin de los casos de uso general del sistema.

62

4.4.-MODELO DE OBJETOS.

contribuyente_ b usca/resgistra b usca/registra

inm ueble

registra tipos de acotacion b usca/registra

fis calizador
(f rom Logical View)

operador del s is tema

b usca/registra

trabajador

diagrama de objeto de acotacion

registra/genera

registra registra

categoria de edificacion

derechos acotacion

obra

Fig. 14: Diagrama de Modelo de Objetos. Gestin de acotacin

contribuyente* verifica/registra

actualiza acotacion consulta verifica/registra

contribuyente

operador de sistem a lista/registra

Disgrama de objetos de Acta de comprom iso de Pago

obra

detalle de obra

Fig. 15: Diagrama de Modelo de Objetos. Gestin de acta de compromiso de pago

63

contribuyente* verifica

asigna reporta obra

registra cajero* diagram a de objetos de regis tro de pagos operador del s is tema

regis tro de pagos

Fig. 16: Diagrama de Modelo de Objetos. Gestin de registro de pagos 4.5.- DIAGRAMA DE CASOS DE USO DEL SISTEMA.

obras menores demolicion

verificar trabajador <<include>>

obra nueva regostrar trabajador <<include>> registrar tipo de acotacion

verificar categoria de edificacion

<<include>>

verificar inmueble registrar categoria de edificacion registrar inmueble <<include>> registrar area de obra verificar contribuyente registrar contribuyente gestion de acotacion_ registrar derechos

verificar area de obra <<include>>

<<include>>

verificar derechos

base presunta registrar fuente actualizar medidor de luz registrar nota base real

registrar observacion

P.U

Fig. 17: Diagrama de casos de uso. Gestin de acotacin

64

verificar contribuyente

registra acotacion

<<include>>

<<include>>

registrar contribuyente

registrar acotacion

<<include>> verificar obra registrar obra

<<include>> gestion de A.C.P

(from Logical Vi ew)

registrar detalle de acta

verificar detalle de acta

Fig. 18: Diagrama de casos de uso. Gestin de acta de compromisos de pago.

registrar nro licencia <<extend>> asignar detalle de obra registrar pagos verificar registro de pagos asignar importe

verificar contribuyente asignar fecha registrar fecha

gestion de registro de pago

Fig. 19: Diagrama de casos de uso. Gestin de acta de Registro de Pagos.

65

4.6.- DIAGRAMA DE SECUENCIAS.

2.4 DIAGRAMA DE SECUENCIA DE GENERAR UNA ACOTACION

contribuyentes : OPERADOR DEL SISTEMA

jnmueble

acotacion 1. autogeneracion de nro

trabajadores

obras

Elementos de edificacion

derechos

2. verifica/registra

3. verifica/registra ubicacion 4. registrar fecha 5. verifica/registra 6.registra medidas 7. verifico categorias de elementos de edificacion 8. verificas 9. calculo de valor de licencia

10. registramos observaciones

12. verifico/actualizo medidor de luz

13. verifico responsable de busqueda

Fig. 20: Diagrama de secuencias. Gestin de acotacin.

acotacion : OPERADOR DEL SISTEMA verificar/consulta

contribueyente

inm ueble

A.C.P

2. verifico/actualizo datos

3.verifico/actualizo ubicacion 4.registro nro de cuotas 5. registro cronograma de pago

6. registro importe por cuota 7. registro estado de cuota

Fig. 21: Diagrama de secuencias. Gestin de Acta de compromiso de pago.

66

: operador del sistema busca/verifica

contribuyente

obra

registro de pago

asigna

registrar licencia de obra registrar fecha registra importe de cuota registra observaciones de pago

Fig. 22: Diagrama de secuencias. Gestin de Registro de Pagos. 4.7.- DIAGRAMA DE ACTIVIDADES.

Fig. 23: Diagrama de Actividad. Calculo de una acotacin.

67

CONTRIBUYENTE

AREA DE FISCALIZACION

COBRANZAS MUNICIPALES

FISCALIZAR OBRA

[ no hay contribuyente ] REGISTRO MEDIDOR DE LUZ [existe contribuyente] DATOS DEL CONTRIBUYENTE

BUSCAR DATOS DEL CONTRIBUYENTE

TERMINOS P.U: Predio Urbano A.C.P: Acta de compromiso de pago

CONSULTAR

DIRECCION INMUEBLE

PAGOS

P.U

REALIZAR MEDIDAS DE LA OBRA

[no pago]entonces

[ edificacion antes de 1992 ]

EXONERADO RECIVE NOTIFICACIONES GENERAR NOTIFICACION

ACUDE A LEGALIZAR SU OBRA

INFORMA TIPOS DE PAGOS Y DESCUENTOS PAGO EN UNA SOLA CUOTA PAGO MEDIANTE A.C.P

RECIBE DOCUMENTO DE PAGO

GENERA DOCUMNETO DE PAGO REALIZA EL COBRO

ACUDE A REALIZAR EL PAGO

REGISTRAR PAGOS Y EXONERADOS

EMITE REPORTE DE PAGOS

Figura 2.8

Fig. 24: Diagrama de Actividad. Tramite de una licencia de edificacin.

2.9 DIAGRAMA DE ESTADOS DE UN 4.8.- DIAGRAMA DE ESTADOS. ACTA DE COMPROMISO DE PAGO

ACTIVO

retras o en cuota de pago

INACTIVO

efectua pagos por licecnia

Fig. 25: Diagrama de Estados. De una cuota de pago.

68

4.9.-DIAGRAMA DE CLASES.

Fig. 26: Diagrama de Clases.

69

4.10.-DIAGRAMA DE DESPLIEGUE.
SQL server 2005 Developer

<<Application>> sistema de control de licencias de edificacion.pb

SGF.exe

BD_CLE MUDULOS *Acotacion *Acta de compromiso. *Registro de Pagos

<<Main_programa>> SGF.pb

acotaciones

*Menu.pbl. *Ventanas.pbl *Reportes.

<<Sub program Body>> SGF.pbl

<<ActiveX>> DOC acta de compromiso de pago

Fig. N 27. Diagrama de despliegue. 4.11.-DIAGRAMA DE COMPONENTES.

intel pentium (R) IV 3.0 GHZ. disco duro samsung 250 gb RAM 1GB. SOFTWARE windows xp sp3. Sql severv 2005 developer. office 2007 PC-EXODO

IMPRESORA

hp inyecion

preemptive <process name> <thread name>

Encore. 4 puertos

Switch

ESTABILIZ ADOR

solido auvoltage regurable

Fig. N 28 Diagrama de Componentes.

70

4.12.- DISEO DE BASE DE DATOS.

Fig. N 29 Modelo Fsico de la Base de datos.

Fig. 30 Modelo Lgico de Base de Datos.

71

Fig. 31. Modelo Entidad Relacin de la base de datos. 4.13.- DISEO DE INTERFAZ DE USUARIO.

Fig. 32. Interfaz de acceso al sistema.

72

4.13.1.-DISEO DE INTERFAZ DE USUARIO DE MANTENIMIENTOS.

Fig. N. 33. Interfaz del men opcin mantenimientos, aqu tenemos la lista de todos los mantenimientos que a continuacin se van a detallar.

Grafico 5.15 Fig. N. 34. Interfaz de mantenimiento de contribuyente.

73

Fig. N. 35. Interfaz de mantenimiento de Inmueble.

Fig. N. 36. Interfaz de mantenimiento de obras.

74

Fig. N. 37. Interfaz de mantenimiento de Derechos.

Fig. N. 38. Interfaz de mantenimiento de valores de edificacin.

75

Grafico 5.35 Fig. N. 39. Interfaz de mantenimiento de Elementos de edificacin.

Fig. N. 40. Interfaz de mantenimiento de Trabajador.

76

Fig. N. 41. Interfaz de mantenimiento de Categoras. 4.13.2.-DISEO DE INTERFAZ DE USUARIO DE OPERACIONES.

Fig. N. 42. Opcin de men operaciones

77

Fig. N. 43. Interfaz de acotacin.

Fig. N. 44. Interfaz de acta de compromiso de pago.

78

Fig. N. 45. Interfaz de Registro de Pagos.

4.13.3.-DISEO DE INTERFAZ DE USUARIO DE REPORTES.

Fig. N. 46. Opcin del men o reportes/consultas.

79

Fig. N. 47. Reporte de bsqueda de pagos.

Fig. N. 48. Reporte de pagos pendientes.

80

Fig. N. 49. Bsqueda de contribuyentes

81

CAPITULO V CONCLUSIONES Y RECOMENDACIONES.

82