Ministerio de Justicia y del Derechocapacitacion.siac.ideam.gov.co/SIAC/Arquitectura/S_SNIF/... ·...

Arquitectura de SoftwareSistema Nacional de Información Forestal (SNIF)

CONTRATO 255 / 2014

ELABORÓ: Luis Carlos Guevara REVISÓ: APROBÓ:

Sistema Nacional de Información Forestal (SNIF)

Arquitectura de Software

Elaborado por:REDESIS LTDA

ContratistaIDEAM

Teléfono: 571 6364496Email:[email protected]

Versión del documento: 1.0

Arquitectura de Software SNIF


CONTRATO 255 / 2014


Periodicidad: Único



CONTRATO 255 / 2014


FORMATO PRELIMINAR AL DOCUMENTOFORMATO PRELIMINAR AL DOCUMENTO

Título: Arquitectura de Software SNIFFecha dd/mm/aaaa: 30/06/2015Sumario: Este documento contiene la arquitectura de la solucion SNIF

Palabras Claves: arquitectura Formato: DOCFecha de emisióndd/mm/aaaa:

30/06/2015 Fecha de modificación dd/mm/aaaa:

Dependencia:Código: Versión 1.0Autor (es):

Información Adicional:

HISTORIAHISTORIA

VERSIÓN FECHA CAMBIOS INTRODUCIDOS1.0 12/03/2015 Documento Inicial



CONTRATO 255 / 2014


Contenido

INTRODUCCION................................................................................................41. METAS Y RESTRICCIONES DE LA ARQUITECTURA..................................52. PERSPECTIVAS LÓGICAS............................................................................63. PERSPECTIVAS IMPLEMENTACIÓN..........................................................104. CAPAS Y SEGURIDAD.................................................................................13 CASO DE USO.................................................................................................16



CONTRATO 255 / 2014


INTRODUCCION

PropósitoEste documento provee un panorama comprensible de la Arquitectura del sistema Nacional de información Forestal – SNIF, Se describe la arquitectura identificada y propuesta para el Sistema. La arquitectura presentada se encuentra basada en la definición de requerimientos validados y formalizados.

La representación arquitectónica de la solución abarca el contexto de la situación a mejorar y un entendimiento del contexto actual y las expectativas del negocio.

La perspectiva lógica de la arquitectura muestra los componentes del sistema y describe las responsabilidades de cada componente con respecto a los requerimientos que son estructuralmente importantes dentro del sistema de información. Se podría comprender que esta vista es similar a la vista conceptual, pero refina la arquitectura mostrando los componentes de software que dentro de cada capa en la aplicación va a implementar los requerimientos del sistema, por lo tanto es una vista mucho más cercana a la solución final.

La perspectiva de despliegue muestra cómo se van a instalar los componentes de la aplicación dentro de la infraestructura en la cual va a operar el sistema, viendo desde este punto los servidores, máquinas cliente, características de red, y otras restricciones que van a definir cómo va a operar la solución final y como se integran los componentes entre sí y con sistemas externos.

La perspectiva de implementación muestra un refinamiento de los componentes mediante paquetes que van a contener clases con código fuente.

AlcanceEste documento describe la distribución de los diferentes componentes definidos para la arquitectura del sistema SNIF. Se describirá componente de la arquitectura propuesta y su distribución en las distintas capas, así como una descripción de estas últimas. El presente Documento de Arquitectura de Software, se basa en los requerimientos definidos y acordados por parte de los funcionarios de la subdirección de Aseguramiento de la calidad y la subdirección de Inspección y Vigilancia del Ministerio de Educación Nacional.

Definiciones, Acrónimos y Abreviaturas Ver Documento de glosario del proyecto.

Referencias Reporte HTML de diagramas de Arquitectura. Casos de uso del SNIF. Documento de requerimientos no funcionales del SNIF.

Modelo de datos y Diccionario de datos del SNIF.

Especificación de servicios Web propuestos para el SNIF.



CONTRATO 255 / 2014


1. METAS Y RESTRICCIONES DE LA ARQUITECTURA

Existen un conjunto de requerimientos claves, objetivos y restricciones del sistema que impactan la arquitectura del mismo, a continuación estos son indicados:

Se debe proponer una aplicación 100% web, que pueda ser ejecutada en su totalidad a través de un navegador de internet. Soporte a las versiones más recientes de los distintos navegadores del mercado.

Se debe hacer uso de estándares abiertos, y no debe contemplarse el uso de componentes, Framework, ni librerías comerciales que requieran la adquisición de licencias adicionales a las presentes en la entidad. Estándares aplicables:

o SQL 2008o W3Co HTML4 Y 5o SOAP 1.2o XML 1.0o J2EEo SERVLET 3.2o JSF 2.0

Las integraciones propuestas entre sistemas deben ser construidas mediante el enfoque tecnológico de servicios Web.

El esquema de actualización de la información deberá ser en línea, facilitando a otros usuarios la consulta inmediata de los datos introducidos en el sistema.

Debe ser propuesta una arquitectura que se soporte en los recursos de bases de datos (Oracle 11g) y de servidor de aplicaciones (JBOSS 6.2) existentes en la entidad.

Los requerimientos de rendimiento estipulados en los documentos de requerimientos no funcionales y de servicios Web, deben de ser considerados como parte de la arquitectura del sistema.



CONTRATO 255 / 2014




CONTRATO 255 / 2014


2. PERSPECTIVAS LÓGICAS

Se presenta la perspectiva conceptual del sistema, en la cual se describen los componentes de alto nivel con el fin de apoyar la comprensión de la solución, sus componentes externamente visibles y su interrelación, y donde cada uno de ellos implementa el conjunto de operaciones necesarias para suplir los requerimientos.

La solución esta implementada bajo el patrón MVC, en donde el proyecto esta subdividido en 3 componentes básicos definidos así:

Datos Modelo ER en Oracle (Referencie en diccionario y modelo ER)

Controlador: ideam-snif-ejb

Vista: ideam-snif-web

SNIF GeoReporteador

WebService: ideam-snif-ws

Donde el componente definido como “ideam-snif-ejb” gestiona toda la lógica de la aplicación se divide en los paquetes que se relacionan en la gráfica 1 en este conjunto de paquetes se dividen en:

json reporteador snif

model constante dao delegate dto entity excepcione locator service util

reporteador



CONTRATO 255 / 2014


Gráfica 1.

Sobre la capa de aplicación o vista, iniciamos exponiendo que se divide en tres partes a saber:

Aplicación Georeporteador WebService

Donde:“Aplicación” se refiere al los formularios de interacción del usuario construidos con primefaces y ManagerBeans. Los objetos se que afectan este componete se refieren a los paquetes:

json reporteador servlets snif

servlets parameters

view controller delegate menu



CONTRATO 255 / 2014


pageDefs secury util validations

En la gráfica 2 evidenciamos la interacción de estos paquetes.

Gráfica 2

“Georeporteador” Se refiere a a un formulario javascript y html que se soporta sobre un conjunto de Servlets. Este se ubica dentro del mismo contenedor expuesto en el parágrafo previo solo utiliza los paquetes

json reporteador servlets snif

servlets parameters

Su operación es a través de servlets que se consumen desde un javascript de nombre main.js el cual se invoca desde un html de nombre georeporteador.html.

“WebService” hace referencia a un soporte SOAP para permitir que clientes SOAP interaccionen con el sistema



CONTRATO 255 / 2014


Los paquetes se ubican dentro del proyecto denominado ideam-snif-ws donde los paquetes se parte

service dto

La gráfica 3 presenta la relación de WebService.

Gráfica 3



CONTRATO 255 / 2014


3. PERSPECTIVAS IMPLEMENTACIÓN

Se construyo como se menciono con el patrón Vista Controlador eta dentro del proyecto ideam-snif-web, donde cada componente se profundiza de la siguiente forma:

Vista AplicaciónLa solución SNIF contiene su componente de vista dentro del paquete denominado proyecto ideam-snif-web,

SNIFEste competente esta trabajado con PrimeFaces 5.1 en donde se crearon formularios xhtml que interaccionan la aplicación.

Cada temática se componen de tres formularios donde se clasifican así: lista???????.xhtml : Corresponde al listado de pendientes por cada

temática

d_??????.xhtml: Formulario de lectura presenta registros pendientes de forma detallada. Y adicionar si es el caso contiene el dialogo para adicionar registros de especies vinculados a la temática.

f_??????.xhtml:Formulario de creación o modificación presenta registros pendientes de forma detallada. Así como el dialogo para la gestión de puntos o coordenadas geográficas.

Estos formularios operan con unos Managed Bean ubicados en el paquete Controller en donde hay un BK por cada temática.

Estos BK son los que interactuan con lo Beans ubicados en el ejb los cuales están en el proyecto ideam-snif-ejb.

GEOREPORTEADORAsí mismo sobre el mismo paquete esta nivel también se ubica el georeporteador, el cual parte de un html el cual invoca un componente javascript asociado a la gráfica 4 en donde asocia la capa de negocio a través de servlets, los cuales están en el paquete de servlets los cuales ejecutan servlets que se comunican con cadenas JSON con el Java Script.



CONTRATO 255 / 2014


Gráfica 4

Este componete solo es de consulta. El Java Script se relaciona con el servidor geográfico para visualizar los resultados en el mapa.

Así mismo también ase uso de librerias estandar de Java Script como lo son: ext-4.2 GeoExt2 OpenLayers 2.13

Estas librerías se utilizan ext para pintar datos estadísticos en gráficas tales como las tortas, barras, lineas de tendencia entre otros. Por otro lado el GeoExt 2 — JavaScript Toolkit for Rich Web Mapping Applications, para visualizar mapas apoyandose en el Openlayers par visualización de tiles sobre los mapas.

Lógica de negocio La solución SNIF contiene su lógica de negocio dentro del paquete denominado proyecto ideam-snif-ejb, el cual contiene los siguente paquetes:



CONTRATO 255 / 2014


json reporteador snif

model constante dao delegate dto entety exception locator service util

Modelo de datosEn la base de datos existen un conjunto de tablas asociadas por temática como se presenta a continuación:

TEMATICAS TABLASAPROVECHAMIENTO FORESTAL SNFT_UBICACION_APROV

APROVECHAMIENTO FORESTAL SNFT_ESPECIE_APROV

APROVECHAMIENTO FORESTAL SNFT_APROVECHAMIENTO

MOVILIZACION FORESTAL SNFT_ESPECIE_MOVILIZACION

MOVILIZACION FORESTAL SNFT_MOVILIZACION

DECOMISO FORESTAL SNFT_ESPECIE_DECOMISO

DECOMISO FORESTAL SNFT_DECOMISO

PLANTACION FORESTAL PROTECTORA SNFT_UBICACION_PLANT_PROT

PLANTACION FORESTAL PROTECTORA SNFT_ESPECIE_PLANT_PROT

PLANTACION FORESTAL PROTECTORA SNFT_PLANTACION_PROT

PLANTACION FORESTAL PRODUCTORA SNFT_UBICACION_PLANT_PROD

PLANTACION FORESTAL PRODUCTORA SNFT_ESPECIE_PLANT_PROD

PLANTACION FORESTAL PRODUCTORA SNFT_PLANTACION_PROD

INCENDIOS DE LA COBERTURA VEGETAL SNFT_UBICACION_INCENDIO

INCENDIOS DE LA COBERTURA VEGETAL SNFT_INCENDIO

REMISION MOVILIZACION ICA SNFT_ESPECIE_REMIS_MOVILIZ

REMISION MOVILIZACION ICA SNFT_REMIS_MOVILIZ_ICA



CONTRATO 255 / 2014


Registros de aprovechamientosEn relación a aprovechamientos el modelo cuenta con la tabla SnftpAprovechamiento en el que se registran los datos propios del acto administrativo con el que se dio su aprobación y la información de la persona responsable del reporte de la Autoridad ambiental.

Dicha tabla tiene relaciones con MtmvClaseAprov para indicar la clase de aprovechamiento, con MtmvFormOtorAprv para indicar la forma de aprovechamiento, SnftEspecieAprov para construir la lista de especies de aprovechamiento, con SnftUbicacionAprov para determinar las coordenadas o listas de coordenadas asociadas al mismo y MtmvMunicipio y MtmvDepartamento para indicar su ubicación a nivel departamental.

MovilizacionesEn relación a movilizaciones el modelo cuenta con la tabla SnftpMovilización en el que se registran los datos del acto administrativo con el cual se autoriza, fecha, medio de transporte, volumen, datos del salvoconducto, identificación del origen y destino de la movilización, y las especies amparadas por el salvoconducto.



CONTRATO 255 / 2014


Dicha tabla tiene relaciones con MntmMedioTransporte para indicar el medio de transporte, SnftEspecieMovilizacion para construir las especies que están autorizadas

Decomisos Para el trabajo con decomisos el Sistema hace uso de la tabla SnftDecomiso en el cual se relaciona las cusas del decomiso, entidades que participaron, el medio de trasporte, el salvoconducto si existía, el origen y destino de la carga así como el lugar en el que se realizó el decomiso y el listado de especies.

Dicha tabla tiene relaciones con MntmMedioTransporte para indicar el medio de transporte en el que se movilizaba la carga, MtmvCausaDecomiso para indicar la causa, con MtmvTipoDecomiso para indicar si el decomiso es de tipo preventivo, con SnftEspecieDecomiso para construir las especies que fueron decomisadas.



CONTRATO 255 / 2014


Incendios forestales En relación a Incendios forestales el sistema usa la tabla SnftIncendio para reportar la ubicación del evento, el tipo de incendio, hora, causa del incendio, áreas afectadas. Las coordinadas del Incendio se registran en la tabla SnftUbicaciónIncendio

SnftIncendio se relaciona con MtmvCausaIncendio para indicar la causa, con MtmvTipoIncendio para documentar el tipo. Asimismo se emplean las tablas SnftAreaIncendio y MntvTipoAreaAfec para indicar si el ecosistema afectado es: Bosque natural, Bosque intervenido, Bosque plantado, Cultivos, paramos, Sabanas y pastizales, Pastos, Rastrojos, Vegetación seca, o Coberturas si determinar.

Plantaciones protectoras



CONTRATO 255 / 2014


En el SNIF se registran las Plantaciones protectoras a través de la tabla SnftPlantacionProt en donde se relaciona el nombre del proyecto, fecha de establecimiento de la plantación, objetivo que persigue (tipo y modelo de intervención), valor del proyecto, área que cubren las especies, fuentes de financiación, ubicación geográfica del proyecto a nivel de divipola o lista de coordinadas geográficas a través de SnftUbicacionPlantProt, y lista de especies a través de SnftEspeciePlanProt.

SnftPlantacionProt se relaciona con MtmvTipoInterv y MtmvModeloInterv para indicar el tipo de intervencion, MtmvMunicipio y MtmvDepartamento para indicar su ubicación a nivel departamental, MtmvFuenteFinanc

Así mismo existe una tabla usuarios en donde se almacena la información referida a los usuarios.



CONTRATO 255 / 2014


4. CAPAS Y SEGURIDAD

En relación a la aplicación SNIF se puede decidir por las capas funcionales, se componen como los layes expuestas en la gráfica 5.

Gráfica 5

La capa core o de aplicación contiene los componentes encargados de la lógica de negocio y gestión de datos, sirve como mediadora entre la user interface layer y la data layer, recibe las peticiones de datos de la capa de interface de usuario y realizar invocación a los componentes de dominio de la capa de datos. Así mismo ejercen el control sobre algún aspecto determinado del sistema.

Componente Core EJBSe propone construir clases EJB de sesión con tecnología EJB 3.0 que sirven de fachada de los servicios de persistencia suministrados por la capa de datos.

EJBLos EJB proporcionan un modelo de componentes distribuido estándar del lado del servidor. El objetivo de los EJB es dotar al programador de un modelo que le permita abstraerse de los problemas generales de una aplicación empresarial (concurrencia, transacciones, persistencia, seguridad, etc.) para centrarse en el desarrollo de la lógica de negocio en sí. El hecho de estar basado en componentes permite que éstos sean flexibles y sobre todo reutilizables.

La solución presenta el uso de roles los cuales permiten acceder a módulos funcionales con características asociadas a ese rol presentando opciones de acceso a formularios. (Referirse al manual del usuario para ahondar en el tema).

Definición tomada de Wikipedia



CONTRATO 255 / 2014


http://es.wikipedia.org/wiki/Enterprise_JavaBeans

Apache POI 3.0Apache POI, a project run by the Apache Software Foundation, and previously a sub-project of the Jakarta Project, provides pure Java libraries for reading and writing files in Microsoft Office formats, such as Word, PowerPoint and Excel

Definición tomada de Wikipedia http://en.wikipedia.org/wiki/Apache_POI

Data Layer

Ilustración 1. Perspectiva de Implementación – Data Layer y Search Engine

Esta capa describe los componentes que permiten la persistencia de los datos gestionados por el sistema.

Componente DatabaseRepresenta el motor de base de datos donde es implementado el modelo de datos el sistema, acorde a los requerimientos no funcionales, el sistema debe estar soportado sobre una base de datos Oracle 11g con esquema clúster, Oracle Real Application Clusters (RAC).

Componente JPA / HibernateEste componente permite la persistencia de los datos gestionados por el sistema en la base de datos relacional descrita por el componente Database, este componente permite a la aplicación convertir objetos java gestionados por las capas superiores en registros de tablas de una base de datos relacional. Se propone su construcción haciendo uso del framework JPA 2.0 a través de su implementación de Hibernate 4.0.

JPA 2.0Java Persistence API, más conocida por sus siglas JPA, es la API de persistencia desarrollada para la plataforma Java EE


http://en.wikipedia.org/wiki/Apache_POI

http://es.wikipedia.org/wiki/Enterprise_JavaBeans


CONTRATO 255 / 2014


Es un framework del lenguaje de programación Java que maneja datos relacionales en aplicaciones usando la Plataforma Java en sus ediciones Standard (Java SE) y Enterprise (Java EE).

Definición tomada de Wikipedia http://es.wikipedia.org/wiki/Java_Persistence_API

Hibernate 4.0es una herramienta de Mapeo objeto-relacional (ORM) para la plataforma Java (y disponible también para .Net con el nombre de NHibernate) que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML) o anotaciones en los beans de las entidades que permiten establecer estas relaciones.

Definición tomada de Wikipedia http://es.wikipedia.org/wiki/Hibernate

Funciones de negocio

Las tareas de lógica de negocio se ubican todas en el EJB, esta comparte entre la vista y el WebService.


http://es.wikipedia.org/wiki/Hibernate

http://es.wikipedia.org/wiki/Java_Persistence_API


CONTRATO 255 / 2014


5 CASOS DE USOLos caso a solucionar en esta fase de la solucion son:

CU 001-1-1 Gestión de Tabla de parametrización CU 001-1-2 Captura datos de consulta (con base en parametrizacion) CU 001-1-3 Validación reglas según parámetros seleccionados CU 001-2-1 Armar consulta CU 001-2-2 Ejecutar consulta CU 001-2-3 Devolver información consultas CU 001-3-1 Desplegar resultados en mapa CU 001-3-2 Desplegar resultado en tabulado CU 001-3-3 Desplegar resultado en Gráfica CU 001-3-4 Exportar información

CU 001-1-1 Gestión de Tabla de parametrización

Este caso se asocia a los siguientes casos: CU 001-2-1 Armar consulta (con base en datos entrada capturados) CU 001-2-2 Ejecutar consulta CU 001-2-3 Devolver información consultas

Permite generar los campos a mostrar en la tabla de control, con el fin de ser utilizada como medio de consulta de los formularios por temática.

Usuario ROL:Administrador

Gráfica 6



CONTRATO 255 / 2014


Se componete por los objetos:

Gráfica 7

CU 001-1-2 Captura datos de consultaEste caso se asocia a los siguientes casos:

Parametrización y captura entrada de datos

Permite generar los campos a mostrar en la tabla de control, con el fin de ser utilizada como medio de consulta de los formularios por temática.

Este es una tarea de Backen.

El acceso a este modulo es a través de la opción variables temática,

CU 001-1-3 Validación reglas según parámetros seleccionadosEste caso se asocia a los siguientes casos:

Parametrización y captura entrada de datos

Permite generar los resultados de acuerdo a las variables sobre las cuales quiere realizar la consulta.



CONTRATO 255 / 2014


Gráfica 8

Como se visualiza estos casos operan de manera interelacionada

CU 001-2-1 Armar consultaEste caso se asocia a los siguientes casos:

CU 001-1-1 Gestión de Tabla de parametrización CU 001-1-2 Captura datos de consulta (con base en parametrización) CU 001-1-3 Validación reglas según parámetros seleccionados

Permite estructurar las posibles consultas, de acuerdo a los parámetros establecidos (consulta comparativa, consulta especifica)

Consulta especificaHace referencia a tomar variables y generar SQL que permite generar tabulado asociado a la relación de esa variable en un rango de tiempo definido.



CONTRATO 255 / 2014


consulta comparativaHace referencia a tomar 2 variables de 2 temáticas las cuales generar tabulados comparativo entre ellas. asociado a la relación de esa variable en un rango de tiempo definido.

CU 001-2-2 Ejecutar consultaEste caso se asocia a los siguientes casos:


Permite llevar a cabo la consulta de acuerdo a las variables establecidas en los parámetros de consulta.

Este componente que opera atrás de la vista del georeporteador.

CU 001-2-3 Devolver información consultasEste caso se asocia a los siguientes casos:


Valida y trasforma el resultado de la ejecución del SQL sobre la base de datos convirtiéndolas para que puedan ser visualizados los resultados.

CU 001-3-1 Desplegar resultados en mapaEste caso se asocia a los siguientes casos:

CU 001-2-3 Devolver información consultas

Permite proporcionar un amplio análisis de los datos de entrada, visualizados en el mapa.



CONTRATO 255 / 2014


CU 001-3-2 Desplegar resultado en tabulado

Este caso se asocia a los siguientes casos: CU 001-2-3 Devolver información consultas CU 001-3-1 Desplegar resultados en mapa

Permite realizar el análisis geo estadístico, partiendo del análisis exploratorio de los datos.

Gráfica 9

CU 001-3-4 Exportar informaciónEste caso se asocia a los siguientes casos:

CU 001-2-3 Devolver información consultas

Permite exportar el tabulado a un archivo xls.



CONTRATO 255 / 2014


6 PESPECTIVA DE DESPLIEGUE

Está sección describe las configuraciones físicas sobre las cuales se realiza el despliegue del software y es ejecutado, así como la infraestructura necesaria para su instalación. Se divide este apartado del documento en cuatro secciones internas: sección Artefactos, en donde se describen los artefactos construidos en el sistema y su composición; sección Perspectiva de despliegue base, en donde se describen los componentes de hardware y software base requeridos para un correcto funcionamiento del sistema; sección perspectiva de despliegue de alto rendimiento, disponibilidad y escalabilidad, en donde se proponen dos esquemas de como configurar el sistema para que soporte estos requerimientos; por ultimo las Características de Hardware en donde se describe el requerimiento para cada tipo de servidor descrito en las secciones anteriores.

ArtefactosSe compone de un EAR, el cual se subdivide en:- ideam-snif-ejb- ideam-snif-web- ideam-snif-ws

Donde

ideam-snif-ejbLas logica de toda la aplicación es un jar

ideam-snif-webComponete WEB y Georeporteador es un war

ideam-snif-wsComponete de WebService es un war



CONTRATO 255 / 2014


Gráfica 10

Perspectiva Despliegue BaseSe describe el hardware y software base mínimo requerido para el correcto despliegue del sistema.

Nodo Servidor de Base de DatosSobre este nodo se despliega el modelo de base de datos que da soporte a los distintos módulos de todo el sistema, las especificaciones de software de este nodo a continuación:

Red Hat Enterprise Linux 6 Oracle Database 11g Release 11.2.0.1

Nodo Servidor ConexionesSobre este nodo se despliega un servidor Web que permite un esquema de publicación de la aplicación Web SNIF, permitiendo únicamente el acceso a la aplicación a través de los puertos HTTP y HTTPS. Las especificaciones de software de este nodo a continuación:



CONTRATO 255 / 2014


Red Hat Enterprise Linux 6 Red Hat JBOSS servidor Aplicaciones



CONTRATO 255 / 2014


7 PERSPECTIVA DE DATOS

Se referencia el documento de Modelo de datos y diccionario de datos del sistema.



CONTRATO 255 / 2014


8 CALIDAD TECNICAS ARQUITECTONICASLa calidad del software se puede medir a través de sus atributos de calidad, según definición de ISO 8402 son “La totalidad de las características de una entidad que influyen en su aptitud para satisfacer las necesidades establecidas e implícitas”. Se referencia el documento de Requerimientos No funcionales en donde se capturan aquellos requisitos del sistema que no son fácilmente identificados en la realización del modelo de casos de uso y que hacen relación a las características del sistema que aplican de manera general como un todo, más que a rasgos particulares del mismo. Estos requerimientos son adicionales a los requerimientos funcionales que debe cumplir el sistema, y corresponden a aspectos tales como la Funcionalidad, Fiabilidad, Usabilidad, Eficiencia, Mantenibilidad y Portabilidad.

A continuación se indican las tácticas arquitectónicas que fueron seleccionadas e incluidas dentro de la arquitectura propuesta para darles solución a los requerimientos no funcionales identificados; se utilizó el modelo SEI (Software Engineering Institute) para la definición de tácticas, entiéndase táctica como “la manera en que los diseñadores y arquitectos deciden organizar los componentes del sistema, así como asignarles características específicas a cada uno de ellos para controlar su comportamiento y salidas, para así soportar uno o varios atributos de calidad específicos, es decir, al establecer una táctica para manejar un atributo de calidad, lo que realmente se está haciendo es limitando o restringiendo las posibles respuestas del sistema de acuerdo a estímulos específicos”, acorde al modelo SEI se indica el atributo de calidad, la táctica principal y las especificas aplicada:

RendimientoEs el grado en el cual el sistema o componente lleva a cabo una funcionalidad específica dada una restricción de velocidad, precisión, etc. y el uso eficiente de los recursos. El producto de software debe estar en capacidad de ejecutar en forma predecible dentro de un perfil de performance definido y en capacidad de procesar volúmenes incrementados de carga.

Administración de recursosLas tácticas de administración de recursos se encargan de controlar el uso de estos y por tanto reducir los tiempos de respuesta.



CONTRATO 255 / 2014


Introducir concurrenciaConsiste en introducir mecanismos que permitan manejar varias solicitudes en paralelo, con esto se logra reducir el tiempo de bloqueo. Los mecanismos aplicados son:

Configuración de alto rendimiento de servidor de aplicaciones. Configuración de alto rendimiento de servidor de base de datos. Configuración de alto rendimiento de servidor de conexiones. Arreglo de discos soportados en una SAN. Soportado en la optimización y afinamiento del framework de

persistencia JPA / Hibernate. Uso de memoria cache y gestión de objetos.

Mantener múltiples copias de datosEl propósito de mantener replicas es reducir la carga de los cálculos computacionales o accesos a los datos realizados en un servidor. Los mecanismos aplicados son:

Arreglo de discos soportados en una SAN. Configuración de alta disponibilidad / alto rendimiento de servidores de

base de datos.

Aumentar recursos disponiblesConsiste en aumentar los recursos – como procesador, memoria, redes, etc que permitan reducir el tiempo de espera. Los mecanismos aplicados son:

La configuración propuesta para base de datos, servidor de aplicaciones, y conexiones es escalable en la medida que pueden ser incluidos nuevos recursos de procesamiento de manera transparente para el sistema.

DisponibilidadEs el grado de operabilidad de un sistema o componente. El producto de software debe estar en capacidad de estar completa o parcialmente



CONTRATO 255 / 2014


operacional cuando se lo requiera y gestionar efectivamente fallas que puedan afectar su disponibilidad.

Detección de FallasConsiste en encontrar una falla o excepción dentro de la ejecución de un componente del sistema, indicando el tipo de falla que ha ocurrido o un componente especifico que se encarga de tratar la falla. Los mecanismos aplicados son:

Soportado por el lenguaje java a través del manejador de excepciones, en la implementación deben ser escritos manejadores de excepciones para cada capa propuesta, de manera que el error no sea propagado a capas superiores sin el control necesario.

Los mecanismos implementados por Oracle RAC. Configuración de un controlador de dominio de alta disponibilidad para

servidores de aplicaciones para soporte de fallas de infraestructura o aplicación.

Configuración de un arreglo de discos SAN para aseguramiento de los repositorios de datos.

Recuperación de FallasConsiste en implementar componentes dentro de una configuración que permita recuperar y reparar el sistema. Los mecanismos aplicados son:

Para funciones de acceso a datos en la aplicación debe utilizarse las funcionalidades de checkpoint y rollback implementadas por el manejador de transacciones soportado en los frameworks EJB 3 / JPA.

Los mecanismos implementados por Oracle RAC.

Prevención de FallasConsiste en definir un conjunto de medidas preventivas considerando un conjunto de fallas a ocurrir. Los mecanismos aplicados son:

Para funciones de acceso a datos en la aplicación debe utilizarse el manejador de transacciones soportado en los frameworks EJB 3 / JPA.



CONTRATO 255 / 2014


ModificabilidadEstá relacionado con costo del cambio. Los aspectos a tener en cuenta son: qué hay que cambiar, cuándo y quien. El producto de software debe estar en capacidad de ser flexible frente a cambios inevitables durante su desarrollo y luego del despliegue.

Localización de las modificacionesConsiste en minimizar el número de módulos que necesitan ser modificados en iteraciones posteriores del desarrollo.

Generalizar el moduloLos módulos pueden ser configurados para poder recibir distintos tipos de parámetros e interoperar de manera general con varios módulos. Los mecanismos aplicados son:

Implementación de funcionalidades de parametrización del sistema, para cada módulo fueron identificados los puntos susceptibles de cambios futuros y se especificaron como elementos configurables, por ejemplo: para el módulo de Conservación y restauración se parametrizó los tipos de actividades.

Limitar opciones posiblesLas modificaciones pueden afectar muchos módulos. Los mecanismos aplicados son:

Definición de listas de entradas controladas y administrables a partir de dominios del sistema.

Prevención de efecto ondaSe refiere a la necesidad de realizar cambios a módulos que no son afectados directamente por el cambio, es decir, si es necesario modificar un componente de software pero existen componentes que dependen de este, entonces estos



CONTRATO 255 / 2014


deben ser modificados para poder operar con la nueva implementación del componente del cual dependen.

EncapsulamientoConsiste en la descomposición de responsabilidades y elementos de una entidad o componente de software, en donde parte de estas responsabilidades son ocultadas para el resto de los componentes, permitiendo manipular únicamente a los que son públicos. Los mecanismos aplicados son:

Soportado por el lenguaje java a través de la definición de clases, atributos y métodos

Definición de capas del sistema con funcionalidades y puntos de interacción claramente definidos. Los puntos de interacción únicamente ofrecen las funciones de negocio requeridas por las capas superiores o inferiores y encapsulan la lógica de negocio propia de la capa. Se propone el uso de frameworks para desacoplar funcionalidades propias de cada capa: User Interface: JSF, Seguridad: Spring Security, Acceso a Datos: JPA / Hibernate, Acceso a Servicios: JAX – WS.

Uso de IntermediariosConsiste en introducir un componente específico entre dos módulos para deshacer la dependencia entre ellos. Los mecanismos aplicados son:

Acceso desde la User Interface Layer u otras aplicaciones a implementación de funciones de negocio mediante el patrón Session Facade de EJB 3.

Implementación del componente de notificación con el patrón Facade para la gestión de notificaciones acorde a una configuración.


Ministerio de Justicia y del Derechocapacitacion.siac.ideam.gov.co/SIAC/Arquitectura/S_SNIF/... ·...

Documents

Transcript of Ministerio de Justicia y del Derechocapacitacion.siac.ideam.gov.co/SIAC/Arquitectura/S_SNIF/... ·...