Pgina 1 Pontificia Universidad Javeriana Documento de Arquitectura de Software Versin 0.8 Pgina 2 Control de Cambios Fecha Versin Descripcin Autor02-11-2008 0.2 PrimeraVersin,diagramasdedesplieguey de datos.Jos Yances13-11-2008 0.3 Diagrama de Mdulos y Paquetes Jos Yances25-11-2008 0.4 Diagrama de Clases Jos Yances30-11-20090.5Modelo de datosSamuel Murillo 16-01-2010 0.6 Vista de despliegue Jos Yances20-01-2010 0.7 Vista de implementacin y de Procesos Jos Yances21-01-20100.8Modelo de datos y normalizacinJosYancesSamuel Murillo Pgina 3 Tabla de contenido 1.Introduccin ................................................................................................................... 5 1.1 Propsito .............................................................................................................. 5 1.2 Alcance ................................................................................................................. 5 1.3 Glosario de Trminos .................................................................................... 6 1.4 Referencias ..................................................................................................... 7 1.5 Descripcin General ...................................................................................... 7 2.Representacin de la Arquitectura .............................................................................. 8 2.1 Descripcin del modelo 4+1 ......................................................................... 8 3.Metas y Restricciones de la Arquitectura .................................................... 10 4.Vista Funcional (Casos de Uso) ................................................................... 11 5. Vista de Implementacin ............................................................................................ 14 5.1 Arquitectura Paquetes y Subsistemas en Capas ................................ 14 6. Vista Lgica .................................................................................................................... 15 7. Vista de Procesos ......................................................................................................... 17 8. Vista de Distribucin ................................................................................................... 18 9. Vista Lgica de Datos ................................................................................................... 18 Pgina 4 Lista de Tablas Tabla1.Descripcindelasvistasqueintegranlaarquitecturadela aplicacinTabla 2. Vistas adicionales incluidas en la arquitectura de la aplicacin Tabla 3. Descripcin de los Componentes y Subsistemas. Lista de Figuras Figura 1. Modelo 4+ 1.Figura 2. Vista de Casos de Uso Figura 3. Vista de Implementacin. Figura 4. Vista de Lgica. Figura 5. Vista de procesos del sistema. Figura 6. Vista de Distribucin. Figura 7. Vista de Lgica de Datos. Figura 8.Modelo de datos inicial. Figura 9.Relaciones tabla Predio Figura 10.Relaciones tabla construccin Figura 11.Relaciones tabla persona Figura 12.Relaciones tabla actuacin Figura 13.Relaciones tabla avalo Figura 14.Relaciones tabla usuario Figura 15.Relaciones tabla Registro inmobiliario Pgina 5 1.Introduccin Estedocumentoproveeinformacindetalladelaarquitectura,necesaria paraeldesarrolloydiseodelaaplicacinWebsegnloacordadoenlos requerimientosespecificadosenel documento de SRS,el cual tiene como objetivoestablecerlasnecesidadesdelosactoresylasdiferentesvistas temticasqueintervienenenlaadministracindeprediosdelaUnidadde Parques Naturales de Colombia. 1.1 Propsito Sedescribedetalladamentelavisincompletadelaarquitecturadel sistema,usandodiferentesvistasarquitectnicas:lgica,procesos, implementacin,distribucinydatos(Modelo4+1),conlaintencinde reflejar las decisiones arquitectnicas ms relevantes que se tomaron para hacer la definicin del sistema. 1.2 Alcance Lavisinarquitectnicaquesedescribeenestedocumentoaplica nicamente para UAEPNNC.Este es un sistema que ha sido desarrollado por los responsables de este documento. Pgina 6 Esteserealizelaborandolosartefactosqueserequirieronsegnel modelo4+1permitiendodefinirlosmdulosdelaaplicacin,modelode datoseInterfacesconotrossistemasdetalformaquelaspersonas involucradaseneldesarrolloymantenimientodelproyectotenganuna visin general de la solucin implementada. 1.3 Glosario de Trminos ServidosdeAplicacionesJEE:EntornodeejecucindeaplicacionesJEE, proporciona el contenedor web y/o el contenedor de EJBs.JSF:JavaServletsFacesesunatecnologadeJavaparaconstruirinterfacesde usuario del lado del servidor. [5] ArcGISServer:PlataformadelaFirmaESRIparalaedicin,creacinyla visualizacin de servicios geogrficos. [6] FrameWork:Esundiseoreutilizableparaunsistemadesoftware,expresado como un conjunto de clases abstractas y la forma como colaboran entre ellas.[8]. JDNI:JavaNamingandDirectoryInterface.Servicioestndardenombradoy directorio en Java. [3] Proceso:Conjuntodeactividadesqueserealizanconelfindeproducirun software. Requerimientofuncional:Defineelcomportamientointernodelsoftware: clculos,detallestcnicos,manipulacindedatos yotrasfuncionalidadesque definen como los casos de uso sern satisfechos.[7] Requerimientonofuncional:Unrequerimientoqueespecificacriteriosque puedenusarseparajuzgarlaoperacindeunsistemaenlugardesus comportamientos especficos.[7] SDD:SoftwareDesignDocument(DocumentodeDiseodeSoftware) Documento que describe elmodelo de diseo del sistema [8] Pgina 7 1.4 Referencias 1. [KRU95]ArchitecturalBlueprints-The4+1ViewModelofSoftwareArchitecture. 2.[PIZ06] Pizard Sebastin. ClaNFi Clasificacin de Noticias Financieras - Documento delaArquitecturadelSistemaSAD.Disponibleenlnea: www.fing.edu.uy/~pgclanfi/archivos/SAD.pdf3. [BASS03]BassLen.Softwarearchitectureinpractice.Boston,Massachusetts Addison-Wesley. 20034.[UML07] Unified modeling language, http://www.uml.org/, 2007.5.SunMicroSystems,JavaServerFacestechnology. http://java.sun.com/javaee/javaserverfaces/ 6.ESRI, http://www.esri.com/software/arcgis/arcgisserver/index.html. 7.AndrewStellMan,JenniferGreene,2003,http://www.stellman-greene.com. 8. RalphJohnson,1997,http://st-www.cs.illinois.edu/users/johnson/frameworks.html. 1.5 Descripcin General El documento est organizado de acuerdo a cada una de las vistas utilizadas para la descripcin de la arquitectura que el equipo responsable consider necesarias. Enlaseccin2semuestraladescripcingeneraldelmodelo4+1vistas arquitectnicas, el cual se emplear para el diseo del sistema. En la seccin 3 se describirnlasmetasylasrestriccionesqueposeenmayorimpactoenla arquitectura del mismo. En la seccin 4 se muestran los casos de uso en el marco delavistadeescenarios,conelfindemostrarladinmicadelsistemaenlo referenteaactoresyrequerimientosfuncionales.Enlaseccin5sedescribela vista de implementacin la cual en forma explcita expresa como el sistema estar conformadoenelsentidodesuagrupacinydescomposicindeloselementos. Pgina 8 En la seccin 6 se describe la vista lgica del sistema, representado en diagramas declasesloscualesdenotanloselementosdelnegocioparalaarquitecturadel sistema. En la seccin 7 se describe la vista de procesos del sistema que muestra cmo las clases activas pueden ser representadas como procesos paraun mejor rendimiento.Enlaseccin8sedescribelavistadedesplieguemedianteun diagrama que muestra como el sistema se interrelacionara con su entorno fsico y como estar distribuido en el. 2.Representacin de la Arquitectura EstaarquitecturaestrepresentadapormodelosUMLaunaltonivelde abstraccin, cada modelo ilustra los elementos arquitectnicos ms significativos e identificanlasreasderiesgoquerequierenmayorelaboracinydetalle.La estructuradeestecaptulotieneencuentaestas5vistasyunaadicionaldel modelo de datos. Las suposiciones y restricciones que se van a tener en cuenta estn contempladas en el SRS. 2.1 Descripcin del modelo 4+1 A manera de ilustracin se describe brevemente el modelo 4+1 Figura 1 - Modelo 4+1 Pgina 9 Vista 4+1 Roleenla ArquitecturaVista Funcional (Casos de Uso) Describelosactoresyelcomportamientodelaspartesms significativasdelsistemaentrminosdesecuenciadeacciones, todo fundamentado en los requerimientos del usuario.Vista Lgica Descomposicindelsistemaensubsistemasypaquetesypor cadapaquete,sudescomposicinenclases.Documentalas clases del diseo del sistema ms significativas y sus relaciones. Se documentan los diagramas de clases relacionados con los mdulos o componentes de la aplicacin. Vista de Procesos Identificalos grandesprocesos necesarios para que la aplicacin funcione,entre los que se incluyen los procesos de comunicacin, de base de datos, de seguridad adems de los ms relevantes de la aplicacin. Seharunabreveexplicacindecmofuncionaelsistema teniendoencuentalosprocesosquesecorrendesdecada uno de los mdulos elaborados. Vista de Distribucin( Fsica)Describeladistribucinfsicadelsistemaatravsdel conjuntodenodos(servidoresoequipos) de procesamiento.Algunasconsideracionesdedistribucin pueden implicar restricciones sobre la arquitectura. Diagramas de Nodos o despliegue de la aplicacinVistade Implementacin(Desarrollo)Describeloscomponentesinvolucradoseneldesarrollodel sistemaentrminosdepaquetes,capasymanejode configuracin(estrategiadelanzamiento,propiedadde paquetes,etc.).Elusodeframeworksodirectivasde desarrollo se pueden incluir en esta seccin Se agregan diagramas de paquetes del producto base.Pgina 10 Tabla 1 - Descripcin de las vistas que integran la arquitectura de la aplicacin Adicionalalasperspectivasmencionadasanteriormente,eldocumentode arquitectura resalta la siguiente vista: Vista Rol en la arquitecturaVista Lgica de Datos Modelolgicoquedescribelaestructuradedatosque componeelsistema.EstavistasueleextenderalaVista Lgicaalpresentarconmayordetalle,laformaenquese compone la estructura de datos involucrada en el sistema. Modelo de Datos.Tabla 2 - Vistas adicionales incluidas en la arquitectura de la aplicacin 3.Metas y Restricciones de la Arquitectura Existenvariosrequerimientosquetienenunimpactodirectoenlaarquitectura seleccionada. REQ02:Elmodelodebecaracterizarmodularmentelosaspectos jurdico, econmico y fsico de cada predio. REQA02: El sistema debe mantener 3 modos de operacin y permitir las operaciones CRUD de acuerdo al rol del usuario. REQA03:Debepermitirquelosusuariosaccedanalsistemapor mediodeinternetydigitenlainformacinrecolectadaparasu almacenamiento y disponibilidad en el sistema. Pgina 11 REQA24: Permite al usuario CRUD realizar todo tipo de operaciones sobre los datos. 4.Vista Funcional (Casos de Uso) Esta seccin describelos casos o escenarios de uso que representan de manera significativalafuncionalidaddelsistemafinaloquetienenunaltoimpactoenla arquitectura porque involucranmuchos elementosy/o representan un alto riesgopara la aplicacin. Se identificaron 3 actores: UsuarioGeneral:Elusuariopordefectoesaquelquepuedeingresardatosal sistema, y adems puede realizar consultas sobre este. Este podr cargar datos a travs de formularios del aplicativo o a travs de un funcionalidad de cargador de archivos. Usuarios Consultor: El usuario tiene acceso a la aplicacin web pero con ciertas funcionalidadesrestringidasquedependendeltipodeconsultorquetengael usuario.Elusuariopuederealizarbsquedasespecializadasdepredios,y consultarcierta informacinpredialgeogrficayalfanumricadeacuerdoala dependenciaquealaquepertenezca dentrodelaUAESPNNC.Losdiferentes tipos de consultor: Fsico:nicamenteleinteresalainformacincartogrficadelas reas Protegidas. Usuario CRUD: Necesitan consultar toda la informacin y contar conreportes estadsticos para el anlisis de los datos. Es Necesario que tengan permisos CRUD sobre ciertas tablas en la base de datos.Jurdico:Necesitanconsultartodalainformacindelosconflictosy polticas de saneamiento predial.Pgina 12 Econmico:necesitansaberlosaspectospredialesqueimpliquen dinero para la entidad.Es el encargo de realizar valoraciones en las actuaciones. Administrador:Eladministradortienelaresponsabilidaddemantenerla integridaddelsistema,realizarlosBackupsdelosdatosyoperacionesde restauracin del sistema en caso que se caiga por cualquier razn, administrar los usuarios y establecer los permisos de estos.Pgina 13 Figura 2. Vista de Casos de Uso Pgina 14 5. Vista de Implementacin Se muestra entoncesuna vista de los componentes internos que hacen parte del sistema. 5.1 Arquitectura Paquetes y Subsistemas en Capas Figura 3. Vista de Implementacin. Tenemos una arquitectura multicapas, en donde se organizaron los paquetes visualmente como muestra la figura 1. Cada capa provee una funcionalidad bien definida y utiliza los servicios de la capa inferior. Pgina 15 6. Vista Lgica Lavistalgicarepresentaenlaarquitecturadelsistemaentrminosde componentesysubsistemas.Enlafigurasemuestracomocadaunodelos paquetes utilizan las funcionalidades de los otros haciendo uso de unas interfaces bien definidas. Figura 4. Vista de Lgica. Se explica a continuacin a nivel de responsabilidades cada uno de los paquetes que forman parte del sistema SIPREDIAL. Pgina 16 JSFJSF es la tecnologa utilizada para los componentes visuales del lado del servidor. Proporciona un patrn MVC para facilitar el desarrollo de cualquier aplicacin web.WEB Tienelaresponsabilidaddemapearlosformulariosdelaaplicaciny realizar lgica de presentacin de datos.SECURITYTienelaresponsabilidaddeautenticaralosusuariosyasegurarel control de acceso de la aplicacin, as como armar los querys a partir de loscriteriosdebsquedaqueingreseelusuarioatrevesdelformulario de bsqueda. CORETienelaresponsabilidaddeproveerlasfuncionalidadesdelaplicativo. Cada Manager que forma parte del core tiene la lgica de negocio para administrarcadacomponente.Estoshacenusodelacapade persistenciapararealizarlasconsultasalabasededatosatrevesde Hibrnate. MessageHelper mantiene la referencia al bundle y los querys delaaplicacin.Estepaqueteprestaserviciosalacapawebatravs del businessfacade.ADFProveelasfuncionalidadesdelosArcObjects.ComponentesdeArcGis Server para desarrollo en Java. PERSISTENCETienetodaslasentidadesdelabasededatosSIPREDIAL.Este paqueteprestaserviciosalacapasuperioratrevesdeHibOrclHelper quienmantienelosdatosdeconexinalabasededatosOraclepara realizarlasconsultasencargndosedehacerpersistentelasentidades del negocio.HIBERNATE Es un Framework open source que provee un servicio de persistencia y querys para el mapeo de tablas de la base de datos. Tabla 3. Descripcin de los Componentes y Subsistemas. Pgina 17 7. Vista de Procesos En la vista de proceso se ilustra la descomposicin del sistema en procesos, para esto se realiza el mapeo de los componentes y subsistemas primarios en procesos e hilos. Se muestra en la figura la representacin de procesos de los componentes queofrecenfuncionalidadactiva,yquepodranserEnterpriseJavaBeansy ofrecer un servicio el cual puede ser Configurado, Instalado, e Iniciado. ManagersEconomicoFisicoJuridicoFrontQuery Figura 5. Vista de procesos del sistema. Pgina 18 8. Vista de Distribucin La vista fsica tiene en consideracin los requerimientos no funcionales como disponibilidad, y desempeo. La figura 6, muestra el detalle de la distribucin de los nodos del sistema SIPREDIAL.

Figura 6. Vista de Distribucin. 9. Vista Lgica de Datos Elsiguienteeselmodelodedatosquesediseoparaquealmacenala informacinquemanejarelaplicativo.Setuvoencuentalosrequerimientos analizados junto con la Informacin suministrada por los funcionarios. Pgina 19 Figura 7. Vista de Lgica de Datos. Parallegaralmodeloanteriorsellevaronacabounaseriedepasosnecesarios para normalizar el modelo hasta la tercera forma normal. Lasformasnormalespermitenagilizarsistemastransaccionalessoportadospor basesdedatosrelacionales.Estasformasnormalesseaplicansegnla necesidaddecadasistema,dependiendoelvolumendedatosenlas transacciones realizadas por los usuarios. Pgina 20 Primera forma normal: Esta regla establece que las columnas repetidas siempre sedebencolocarentablasseparadas,estoayudaalaorganizacindela informacin.Esta regla es de mnima exigencia en empresas que manejan bases de datos transaccionales con grandes volmenes de datos. Segundaformanormal:estaformanormalindicaquetodoslosatributos,sin excepcin, debern ser funcionalmente dependientes de la llave primaria que tiene latabla.Encasodequeunatributoseaparcialmentedependiente,deberser removidodelatabla,ycolocadoenunanuevarelacinconsurespectivallave fornea que relacione la tabla original. Terceraformanormal:unmodeloorelacinseencuentraenterceraformal normalsitodoslosatributossinclavesonfuncionalmentedependientesdela clave primaria, y se evitan las dependencias transitivas. En este estado se tiene un nivel de organizacin mayor, permitiendo dividir e identificar con mayor claridad las relaciones y los dominios de cada tabla. Setomcomobaseunmodeloinicialconstruidoconlacolaboracindelos ingenieros de la UAEPNNC (ver figura 8). Pgina 21 Figura 8.Modelo de datos inicial. Este modelo fue punto de partida para realizar tanto el proceso de normalizacin, comolaexpansindenuevasfuncionalidadesqueibanresultandodelas iteraciones del producto en cada fase. Seempezconlanormalizacindelastablasmsrelevantesenelmodelode datos, las cuales son: predio, construccin, persona, actuacin, avalo. Pgina 22 9.1 Tabla predio Figura 9.Relaciones tabla Predio En la tabla predio se empieza determinando cuales son los atributos dependientes delallaveprimaria.Eltipo,avaloydueodelpredionosonfuncionalmente dependientes, por lo cual se crean nuevas tablas de dominio para almacenar estos datos.Una vez construidasestas tablas, se puede verificar queya seencuentra enterceraformanormal,debidoaquenoexistenrelacionestransitivas. Eneste caso el tenedor actual en la tabla predio puede parecer un atributo funcionalmente independiente,peroteniendoencuentaqueestedatononecesariamente correspondealaceduladeunapersona,sinoacualquiertipodedato,comoun telfono,direccinocorreo,entoncesseconvierteenunatributodependiente.Pgina 23 Esto debido a que la UAEPNNC no recibe toda la informacin de un tenedor, sino cualquier atributo de este. 9.2 Tabla construccin Figura 10.Relaciones tabla construccin. Esta relacin se pasa a tercera forma normal, eliminando las relaciones transitivas entreconstruccinymateriales,estodebidoaqueunaconstruccinpuedetener unoomsmateriales,yunmaterialpuedeperteneceraunaoms construcciones.Setomaronlasllavesprimariasdeambastablas,yseconstruy unatablaintermediaquepermiteeliminartodaslasrelacionestransitivas.Lo mismo sucede entre la tabla construccin y servicio. Pgina 24 9.3 Tabla persona Figura 11.Relaciones tabla persona En esta tabla se eliminaron los atributos que no son funcionalmente dependientes, comoeltipodedocumento,yeltipodepersona,ysecrearonnuevastablasde dominio que permiten identificar las relaciones. 9.4 Tabla actuacin Figura 12.Relaciones tabla actuacin Pgina 25 Debidoaqueunaactuacinpuedeserejecutadaporunapersona(naturalo jurdica)oporunaentidaddelestado,sedecidisepararlainformacinentres tablas,evitandoladuplicidaddelainformacin,yloscamposnulosquepuedan existir,encasodequesemanejaraunasolatablaparalosdostiposde actuaciones(personaoentidad),permitiendoidentificardemejorformalas actuaciones de cada persona y entidad.Para las tablas resultantes, se determina que todos los atributos son funcionalmente dependientes de la llave primaria. 9.5 Tabla avalo Figura 13.Relaciones tabla avalo En esta tabla se separaron los avalos realizados alas construccionesya cada predio, esto con el nimo de evitar campos nulos que se presentaran en una sola tabla.Permitiendo ver de este modo las dependencia funcionales en los atributos de todas las tablas. Adicionalmentealanormalizacindelasanteriorestablas,seagregaronnuevas funcionalidadesenelmodelodedatos,permitiendoteneruncontrolmsestricto de todos los funcionarios que interactan con el aplicativo. Pgina 26 Figura 14.Relaciones tabla usuario Estas relaciones presentan tablas de dominio donde se determina que no existen atributosrepetidos,nitampocoexistenatributosquenoseanfuncionalmente dependientes de la llave primaria. Figura 15.Relaciones tabla Registro inmobiliario Pgina 27 Finalmentesepuededeterminarqueelmodeloplanteadoparaelaplicativo,se encuentraenterceraformanormal,loquepermiteagilizarlosdatosenun aplicativo deesteestilo donde latransaccionalidad seesperanosea tanalta (un mximo de 30 usuarios realizando operaciones simultneamente).