AUTORIDAD PORTUARIA NACIONAL VENTANILLA ÚNICA PORTUARIA DISEÑO VUP. Versión 1.0. Agosto Versión 1.0 Diseño VUP Página 1 de 119

Transcripción

1 AUTORIDAD PORTUARIA NACIONAL VENTANILLA ÚNICA PORTUARIA DISEÑO VUP Versión.0 Agosto 2009 Versión.0 Diseño VUP Página de 9

2 Tabla de contenidos. DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA Definición de Niveles de Arquitectura Identificación de Requisitos de Diseño y Construcción Especificación de Excepciones Especificación de Estándares y Normas de Diseño y Construcción Identificación de Subsistemas de Diseño Especificación del Entorno Tecnológico Especificación de Requisitos de Operación y Seguridad DISEÑO DE CASOS DE USO REALES Identificación de Clases y diseño de la realización de los Caso de Uso CU_EDI_ CU_EDI_ CU_EDI_ CU_EDI_ CU_EDI_ CU_EDI_ CU_EDI_ CU_FRM_ CU_FRM_ CU_FRM_ CU_FRM_ CU_FRM_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ Versión.0 Diseño VUP Página 2 de 9

3 CU_ADM_ CU_ADM_ Revisión de la Interfaz de Usuario Revisión de Subsistemas de Diseño e Interfaces Subsistema Mensajería EDI Subsistema Gestión Escala y licencias de Operación Subsistema Formularios Subsistema Administración Sistema Subsistema Pasarela de pago Subsistema Consultas DISEÑO DE CLASES Identificación de Clases, Atributos, Operaciones, Asociaciones y Agregaciones CU_EDI_ CU_EDI_ CU_EDI_ CU_EDI_ CU_EDI_ CU_EDI_ CU_EDI_ CU_FRM_ CU_FRM_ CU_FRM_ CU_FRM_ CU_FRM_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_PP_ CU_ADM_0...3 Versión.0 Diseño VUP Página 3 de 9

4 CU_ADM_ Diseño de la Jerarquía Especificación de Necesidades de Migración y Carga Inicial de Datos DISEÑO FÍSICO DE DATOS Diseño del Modelo Físico de Datos Especificación de los Caminos de Acceso a los Datos Optimización del Modelo Físico de Datos Especificación de la Distribución de Datos VERIFICACIÓN Y ACEPTACIÓN DE LA ARQUITECTURA DEL SISTEMA Verificación de las Especificaciones de Diseño Análisis de Consistencia de las Especificaciones de Diseño GENERACIÓN DE ESPECIFICACIONES DE CONSTRUCCIÓN Especificación del Entorno de Construcción Definición de Componentes, Subsistemas de Construcción y Elaboración de Especificaciones de Construcción Subsistema de Gestión Escalas y licencias de operación Subsistema de Mensajería EDI Subsistema de Formularios Subsistema de Pasarela de Pago Subsistema de Administración del sistema Subsistema de Consultas ESPECIFICACIÓN TÉCNICA DEL PLAN DE PRUEBAS Especificación del Entorno de Pruebas Especificación Técnica de Niveles de Prueba Revisión de la Planificación de Pruebas ESTABLECIMIENTO DE REQUISITOS DE IMPLANTACIÓN Especificación de Requisitos de Documentación de Usuario Especificación de Requisitos de Implantación APROBACIÓN DEL DISEÑO DEL SISTEMA DE INFORMACIÓN Presentación y Aprobación del Diseño del Sistema de Información ANEXO I: GUÍA DE MENSAJES...3 Versión.0 Diseño VUP Página 4 de 9

5 . DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA En esta actividad se define la arquitectura general del sistema de información, especificando las distintas particiones físicas del mismo, la descomposición lógica en subsistemas de diseño y la ubicación de cada subsistema en cada partición, así como la especificación detallada de la infraestructura tecnológica necesaria para dar soporte al sistema de información... Definición de Niveles de Arquitectura En esta tarea se describen los niveles de la arquitectura software, mediante la definición de las principales particiones físicas del sistema de información, representadas como nodos y comunicaciones entre nodos. El siguiente diagrama de despliegue representa de forma esquemática la arquitectura del sistema con todos los elementos que intervienen: deployment Diagrama de despliegue DMZ Cluster de servidores de aplicaciones Clientes EDI Clientes WEB VUP VUP Navegador WEB Java Java SSI SSI Internet Internet Servidor de Aplicaciones Servidor de Aplicaciones Backup Backup 800 Sistema Operativo Sistema Operativo DMZ FireWall Router LAN LAN LAN Cluster de servidores de bases de datos Administradores de APN Usuarios de APN SGBD SGBD SSI SSI Backup Backup Sistema Operativo Sistema Operativo Versión.0 Diseño VUP Página 5 de 9

6 Como se puede observar en el diagrama de despliegue la arquitectura consta de dos clusters de servidores que conforma la zona desmilitarizada. Uno de los cluster contendrá la VUP y otro contendrá la base de datos. Ambos cluster estarán conectados mediante una red LAN. Dentro de cada cluster se configurarán dos servidores en espejo definiendo uno de ellos como maestro y otro como esclavo. Todos los servidores estarán protegidos tanto de caídas como de subidas de tensión eléctrica mediante sistemas SAI (sistemas de alimentación ininterrumpida). Los administradores y los usuarios de la APN accederán a través del firewall mientras que el resto de usuarios, clientes EDI o web, accederán al sistema mediante un router conectado al firewall para evitar accesos no deseados. Las líneas de comunicaciones también estarán duplicadas para evitar caídas y cortes de la red. Los sistemas clientes pueden ser de 3 tipos: clientes para acceso web que únicamente necesitarán un navegador web, clientes con mensajería EDI o sistemas externos que se comunicarán mediante Web Services. La finalidad del firewall y el router es filtrar los accesos desde direcciones y puertos que sean sospechosos y permitir tener control sobre quién, cuándo y desde donde accede al sistema..2. Identificación de Requisitos de Diseño y Construcción Debido al uso de arquitecturas y plataformas ampliamente aceptadas y herramientas estándares no se ha detectado ningún requisito específico que deba cumplirse para la implementación del sistema. No obstante existen algunas consideraciones que deben ser tenidas en cuenta. El empleo de ésta arquitectura permite tener sistemas espejo lo que nos posibilita el tener tolerancia a fallos y balanceo de carga aunque implica realizar copias diferenciales entre los servidores, lo cual mantendrá ocupados a los servidores durante las horas de menos acceso por parte de los usuarios. Los servidores que conformen el cluster deberán tener la misma versión del mismo sistema operativo y realizar las mismas actualizaciones sobre los dos servidores para evitar diferencias entre ambos. También será necesario definir las reglas que el firewall aplicará definiendo los puertos y direcciones IP que estarán abiertos hacia el exterior y desde el exterior. Respecto a los sistemas de los clientes esta arquitectura permite que sean sistemas ligeros y no dependientes, sin tener que soportar ningún tipo de lógica de negocio ni tener que Versión.0 Diseño VUP Página 6 de 9

7 realizar ninguna instalación. Para el acceso web el único requisito para los clientes es tener un navegador web actualizado instalado en su sistema. En el caso de comunicación vía mensajería EDI el sistema de mensajería EDI del cliente puede ser construido en cualquier tecnología y sobre cualquier arquitectura que soporten el envío, la recepción y el tratamiento de ficheros XML..3. Especificación de Excepciones Dentro de la arquitectura definida se pueden dar una serie de situaciones anómalas que afectan en mayor o menor grado al comportamiento del sistema pudiendo llegar incluso a denegar el servicio a los clientes de la VUP. Dichas situaciones anómalas son: caídas de los servidores de bases de datos, fallos en las comunicaciones con la base de datos, fallos en las comunicaciones de los servidores de aplicación con los clientes administradores, fallos de las comunicaciones con el firewall y caídas de los servidores de aplicación. A continuación se explica la situación normal de cada uno de los sistemas existentes en la arquitectura y su comportamiento en caso de que se produzca una excepción dentro de cada uno. El estado habitual de los servidores de bases de datos será tener el servidor maestro levantado y respondiendo a las solicitudes que le lleguen y el servidor esclavo estará en stand by. Cuando se produzca una caída del servidor maestro el software SSI detecta la caída y levanta el servidor de base de datos esclavo redireccionando todas las peticiones que se reciban hacia el servidor esclavo. Este tipo de excepción de negación de servicio es muy grave ya que afecta al subsistema de gestión de escalas y licencias de operación afectando directamente al comportamiento del sistema. Ante esta situación, con la información del fallo que proporcione el software de base de la máquina, será necesario detectar los motivos de la caída y restaurar los servicios lo antes posible, ya que si se cayera el servidor esclavo muchas de las funciones de la VUP no podrían llevarse a cabo. La comunicación entre el cluster de servidores de aplicación y el cluster de servidores de bases de datos debe estar de forma habitual levantada y transmitiendo información entre ambos puntos. Cuando se produzca una caída de servicio del sistema de red la electrónica de red detectará dicha excepción hardware y redirigirá las comunicaciones por la línea secundaria. Esta excepción es igual de grave que la de denegación de servicio de la base de datos ya que los efectos son los mismos: inaccesibilidad de la base de datos afectando también al subsistema de gestión de escalas y licencias con las mismas consecuencias citadas anteriormente. Al igual que en el caso anterior, es determinante detectar el origen del fallo y proceder a su rápida subsanación. La comunicación entre el cluster de servidores de aplicación y los clientes de administradores debe estar de forma habitual levantada y transmitiendo de forma que se permita la comunicación entre ambos puntos. En caso de fallo, la electrónica de red deberá de Versión.0 Diseño VUP Página 7 de 9

8 redirigir las comunicaciones a la segunda línea. Este tipo de excepción de error en las transmisiones provoca que no se puedan realizar labores de mantenimiento y/o actualización en el sistema por lo que el problema hay que solventarlo antes de que se realicen estas tareas. Es necesario revisar la instalación para detectar la causa y evitar retrasos en el mantenimiento del sistema. El estado habitual del cluster de servidores de aplicación es el servidor maestro levantado y sirviendo las peticiones que le lleguen y el esclavo en stand by. En caso de caída del servidor maestro el software SSI debe detectarlo inmediatamente y debe levantar el servidor esclavo, redirigir las peticiones a dicho servidor esclavo y notificar a los administradores de dicho error. Este error de denegación de servicio es el más grave de todos, junto con la denegación de servicio de la base de datos, ya que afecta al servicio ofrecido a los usuarios de la VUP y para todo el sistema afectando a todos los subsistemas existentes. Dicho error debe detectarse y corregirse inmediatamente ya que en caso de que también se cayera el servidor esclavo se pararía todo el sistema y se dejaría de prestar servicio. Otro punto clave para que se ofrezca el servicio es la comunicación entre el cluster de servidores de aplicación y el firewall para accesos externos. El estado habitual de la línea de comunicaciones es estar levantada y transmitiendo las peticiones que lleguen del exterior al cluster de servidores de aplicación. En caso de que ésta falle se debe redireccionar las transmisiones por la segunda línea e informar inmediatamente a los administradores del sistema ya que éste error tiene la misma gravedad que la caída de un servidor de aplicaciones al afectar a todos los subsistemas e impedir ofrecer servicio a los clientes. Todos estos errores se verán reflejados en los logs específicos que proporciona el software de base de los diferentes nodos indicando la fecha, la hora, el tipo de error, una descripción del mismo..4. Especificación de Estándares y Normas de Diseño y Construcción Como marco normativo a cumplir seguiremos lo ya definido en el documento de análisis aplicando en cada caso aquellas normas o leyes del Estado Peruano que afecten al diseño de la ventanilla única portuaria y su posterior explotación. Adicionalmente al marco normativo se aplicará el estándar definido por Métrica versión 3 en su actividad de Diseño de Sistemas Informáticos (DSI) en lo que refiere a notación, actividades y tareas. Versión.0 Diseño VUP Página 8 de 9

9 .5. Identificación de Subsistemas de Diseño Con el fin de organizar y facilitar el diseño, se realiza una división del sistema de información en subsistemas de diseño. Estos pueden ser subsistemas específicos y subsistemas de soporte, con la finalidad de independizar, en la medida de lo posible, las funcionalidades a cubrir por el sistema de información de la infraestructura que le da soporte. Los subsistemas específicos contemplan las funcionalidades propias del sistema de información, mientras que los de soporte cubren servicios comunes, proporcionando un acceso transparente a los distintos recursos. Tomando como referencia el modelo de subsistemas realizado en el análisis y la arquitectura definida en el punto. Definición de Niveles de Arquitectura se obtiene el siguiente modelo de subsistemas de diseño: pkg SoloSubsistemas sistema gestor de bases de datos Administración del Sistema Gestión Escalas y Licencias de Operación Consultas Formularios Mensajería EDI Pasarela de Pago Contingencias Servidor de Aplicaciones Comunicaciones Software base Versión.0 Diseño VUP Página 9 de 9

10 De éstos subsistemas los específicos son: Gestión Escalas y Licencia de operación Administración del Sistema Consulta Formularios Mensajería EDI Pasarela de pago Dentro de estos subsistemas se ha tenido en cuenta no sólo la lógica de negocio sino también cuestiones como: Facilidad de mantenimiento. Reutilización de elementos del propio sistema. Optimización de recursos. Características de ejecución. Funcionalidad común. Acceso a base de datos. Como subsistemas de soporte se han definido: Comunicaciones. Contingencia. Software de base. Servidor de aplicaciones. Sistema gestor de Base de datos. Dentro del subsistema de comunicaciones se incluirán tanto el hardware como el software necesario para que el sistema pueda comunicarse, con los parámetros establecidos, con el resto de elementos de la arquitectura. Dichos elementos incluirán los sistemas necesarios para garantizar la transmisión de la información entre los distintos subsistemas específicos. El subsistema de contingencia recoge los elementos que gestionan las transacciones, la sincronización de los servidores y el comportamiento ante errores. Estos elementos permitirán el balanceo de carga y la tolerancia a fallos dentro del cluster. El subsistema de software de base incluye todo aquel software necesario para que la máquina sea funcional y permita ejecutar correctamente el sistema. Dicho software está formado por el Sistema operativo y la parte Java. Versión.0 Diseño VUP Página 0 de 9

11 La parte Java estará formada por el JRE, las librerías J2EE y aquellos frameworks que sean necesarios para el funcionamiento del sistema. Dichos frameworks serán definidos en el punto.6 Especificación del Entorno Tecnológico. Las librerías J2EE, normalmente, vienen incluidas en el servidor de aplicaciones pero es posible que se necesite incluir alguna librería específica a la hora de construir el sistema. El Java runtime enviroment (JRE) también suele venir incorporado en el sistema operativo pero es posible que se tenga que instalar una versión superior o una actualización para evitar discrepancias entre el entorno de desarrollo y el entorno de software..6. Especificación del Entorno Tecnológico El entorno tecnológico se divide en dos grandes bloques: el entorno Hardware y el entorno Software. El entorno hardware se compone de las máquinas que soportarán la base de datos y el servidor de aplicaciones. Aunque la finalidad es muy distinta, las necesidades desde el punto de vista hardware son muy parecidas ya que deberán soportar lo siguiente: Sistemas espejo para soportar tolerancia a fallos. Líneas de comunicaciones redundantes para asegurar la conectividad entre la VUP y las Entidades y la VUP los usuarios. Protección de todos los sistemas ante caídas de energía eléctrica. Para el almacenamiento de la base de datos es necesario conocer, aunque sea de forma aproximada, el crecimiento que va a tener dicha base de datos. El tamaño de almacenamiento para la base de datos viene dado por el espacio en disco que ocupa la información de una escala, de un pasajero y de un contenedor multiplicado por el número de escalas, número de pasajeros y número de contendores que hay en un año. Espacio de disco= (Escalas/año x espacio/ escala) + (Pasajeros/año x espacio/pasajero) + (Contenedores/año x espacio/contenedor) Según nuestra experiencia con las ventanillas únicas de España, Portugal y Marruecos estimamos que el espacio necesario puede ser: Por cada Escala un espacio medio requerido: 500 Kb Por cada Pasajero un espacio medio requerido: 20 Kb Por cada Contenedor un espacio medio requerido: 30 Kb Los datos obtenidos de la APN (Reporte de naves 2009, estadísticas de movimiento de naves a nivel nacional) y de DIGEMIN (Datos Extraídos de la Base de Datos DIGEMIN el ) sobre las escalas, los contendores y los pasajeros del año 2008 son: Número de escalas en un año: 8.8 Versión.0 Diseño VUP Página de 9

12 Número de pasajeros en un año: Número de contenedores en un año: Por lo que el espacio requerido sería: (8.8 x 500) + (34.99 x 20) + ( x 30) = Kb Aprox. 52 Gigas. Adicionalmente puede aplicarse un factor corrector a modo de margen de seguridad para realizar compras de equipos a más largo plazo. Así mismo establecemos el uso de discos duros en sistema RAID 5 para evitar los problemas físicos de disco y la consecuente pérdida de información asociada a ellos. Para poder dimensionar la capacidad de procesamiento necesaria para el sistema se ha tenido en cuenta que el sistema será utilizado por.000 usuarios totales, es decir, usuarios de mensajería EDI y de la gestión web, con un tráfico anual de manifiestos. Para poder ofrecer un buen rendimiento en estas circunstancias es necesario disponer de unos servidores con una capacidad de memoria no inferior a los 6Gb y procesamiento múltiple, con un mínimo de 4 procesadores de doble núcleo. Se recomienda que la arquitectura sea de tipo Blade ya que facilita la escalabilidad y permite un crecimiento hardware sencillo. Las líneas de comunicaciones también deberán ser capaces de soportar dicho tráfico por lo que recomendamos emplear una red Gigabit Ethernet duplicada para evitar pérdida de conectividad entre los servidores. Como nota adicional al hardware recomendamos que se establezca un mantenimiento con el proveedor o fabricante para poner tener acceso a las actualizaciones así como poder solventar de la forma más rápida posible los problemas que puedan surgir. El entorno software se divide a su vez en dos grandes grupos, el software específico y el de soporte. El software de soporte se compone del sistema operativo que gestionará las máquinas, un middleware SSI (Single System Image) para el balanceo de carga y tolerancia a fallos, un software que gestione los backup, el servidor de aplicaciones y el sistema gestor de bases de datos. El servidor de aplicaciones será JBoss versión Enterprise ya que asegura actualizaciones y soporte profesional y el gestor de bases de datos será Oracle g por su probada fiabilidad y rendimiento en todo tipo de entornos. Versión.0 Diseño VUP Página 2 de 9

13 El sistema operativo vendrá suministrado por el fabricante de la máquina pero se debe tener en cuenta que en función del sistema operativo escogido se tendrá que escoger el software de backup y el de SSI. Debido a esto no se va establecer ningún software en concreto aunque si se van a marcar los requisitos mínimos que deben cumplir. El software SSI debe permitir la disponibilidad de los datos, la disponibilidad en los procesos y la consistencia de éstos entre el servidor maestro y el servidor esclavo. El software para realizar los backup debe permitir realizar copias incrementales y completas en horario programado con anterioridad. También debe permitir la recuperación de la información a partir de un día concreto. La realización de copias de seguridad en caliente nunca debe afectar al funcionamiento del sistema de una forma sensible. El software específico será construido ex profeso para el sistema pero dado que se va a construir sobre la plataforma J2EE la máquina donde se ubique la VUP, tanto para desarrollo como para producción, deberá tener instalado la última versión de JRE (Java Runtime Enviroment) y los siguientes frameworks. JavaServer Faces JavaServer Faces es el estándar presentado por Sun para la capa de presentación Web. Forma parte de la especificación J2EE 5 -que deberán cumplir todos los servidores de aplicaciones- y se erige como una evolución natural de los frameworks actuales hacia un sistema de componentes. Es un estándar sencillo que aporta los componentes básicos de las páginas web además de permitir crear componentes más complejos (menús, pestañas, árboles, etcétera). Ya hay disponibles diferentes implementaciones de la especificación, tanto comerciales como de código abierto, así como librerías de componentes adicionales que amplían la funcionalidad de esos componentes iniciales. JSF ha sido acogida por la comunidad como el framework que hacía falta. Muchos de los proyectos de código abierto y las compañías con más influencia lo han identificado como el framework de presentación web del futuro. MyFaces MyFaces es un proyecto de la fundación Apache que ofrece una implementación en código abierto de JavaServer Faces, así como un amplio conjunto de componentes adicionales. Entre ellos se dispone de un menú, árboles, pestañas, tablas navegables, componentes para gestionar el estado de los diálogos, etc. A lo largo del tiempo se van incorporando componentes cada vez más potentes y ya se encuentran en pruebas Versión.0 Diseño VUP Página 3 de 9

14 componentes basados en Ajax, aunque para esta última opción finalmente nos decantaremos hacia RichFaces. Realmente el uso de MyFaces no impide emplear otras librerías de componentes, así que su uso depende tan solo de la utilidad que encontremos en la funcionalidad que ofrece. Spring Spring es un conjunto de librerías a la carta de entre las que podemos escoger aquellas que faciliten el desarrollo de nuestra aplicación. Entre sus posibilidades más potentes está su contenedor de Inversión de Control (Inversión de Control, también llamado Inyección de Dependencias, es una técnica alternativa a las clásicas búsquedas de recursos vía JNDI. Permite configurar las clases en un archivo XML y definir en él las dependencias. De esta forma la aplicación se vuelve muy modular y a la vez no adquiere dependencias con Spring), la introducción de aspectos, plantillas de utilidades para Hibernate, ibatis y JDBC así como la integración con JSF. Es uno de los proyectos más sorprendentes en el panorama actual en Java en el grado en que ayuda a que los diferentes componentes que forman una aplicación trabajen entre sí, pero no establece apenas dependencias consigo mismo. Esta es la primera característica de este framework. Sería posible retirarlo sin prácticamente cambiar líneas de código. Lo único que sería necesario es, lógicamente, añadir la funcionalidad que provee, ya sea con otro framework similar o mediante nuestro código. A nivel de soporte de la comunidad, Spring es uno de los proyectos con más actividad, con desarrollos dentro y fuera del propio framework (de hecho Acegi, el sistema de seguridad empleado y ahora llamado Spring Security, fue realizado por colaboradores ajenos al framework). Actualmente dispone de soporte comercial a través de Interface2, la empresa creadora, así como otros fabricantes que dan soporte en su área. Spring Security Antiguamente llamado Acegi, desde su versión 2.0 su nomenclatura cambia a Spring Security. Es un gestor de seguridad que está diseñado fundamentalmente para ser usado con Spring y en el que destaca su versatilidad. Spring Security proporciona una capa que envuelve diversos estándares de seguridad presentes en Java y ofrece una forma unificada de configuración a través de un descriptor en XML. Cubre la capa web y la de negocio. A nivel Web captura todas las peticiones mediante la implementación de un filtro y a nivel de métodos mediante interceptación a través de AOP. En ambos casos permite aplicar los criterios de seguridad que trae de serie o añadir nuevas opciones de forma sencilla implementando los interfaces diseñados a tal fin. Versión.0 Diseño VUP Página 4 de 9

15 Spring Security se ha elegido como opción frente a los sistemas propietarios de los diferentes vendedores por la universalidad de su uso no es necesario cambiar nada si se cambia de proveedor en los servidores- así como por su potencia que engloba los API s de seguridad de Java-. Hibernate Hibernate es un motor de persistencia de código abierto. Permite mapear un modelo de clases a un modelo relacional sin imponer ningún tipo de restricción en ambos diseños. Cuenta con una amplia documentación, tanto a nivel de libros publicados como disponibles gratuitamente en su Web. A nivel comercial está respaldado por JBoss, que proporciona servicios de soporte, consultoría y formación en el mismo. Actualmente es el rey indiscutible de la persistencia. Desde su versión.0, el motor no ha parado de evolucionar, incorporando todas las nuevas ideas que se iban incorporando en este campo. JUnit Estándar actual en Java en código abierto para la creación de tests unitarios. Su limpieza de diseño, la amplia documentación existente y lo estandarizado de su uso lo hace la mejor opción para este tipo de tests. Actualmente, para pruebas unitarias, JUnit es prácticamente la opción universal. C3PO C3PO es un pool de conexiones de código abierto. Su uso está muy estandarizado, la documentación disponible sobre él es abundante y tiene un desarrollo continuo por parte de la comunidad. Siendo un simple pool de conexiones, C3PO es sencillo de emplear y rápido de configurar. Es soportado por Hibernate de forma trivial y su uso es transparente. Ant Ant es una herramienta de código abierto para ensamblar aplicaciones y, de forma general, realizar cualquier operación repetitiva del desarrollo que se pueda mecanizar mediante un script. Otra opción muy interesante -disponible también por parte de Apache- es Maven. El problema es que uso no está muy extendido y, en esencia, ambos tienen las mismas funciones aunque con distinta filosofía. Versión.0 Diseño VUP Página 5 de 9

16 Log4Java Log4Java, otra de las librerías de código abierto de Apache, es la opción de referencia para gestionar todos los aspectos de los logs de desarrollo. Aunque se ha visto reemplazada en el API de Java por las nuevas funcionalidades del log en el JDK.5 su uso ampliamente extendido en todas las áreas- y su probado comportamiento en grandes aplicaciones la mantienen todavía como la más usada. Log4Java es empleado de forma casi universal como gestor de logs. Si bien ya se comienza a emplear el API para logs de Java, su funcionalidad es muy similar a Log4Java. RichFaces RichFaces proporciona una serie de librerías que vienen a extender la funcionalidad de JSF. Actualmente se encuentra en su versión 3.3 y trabaja con JSF.2 (versiones inferiores no son soportadas desde la versión 3.2). La principal funcionalidad que aporta es una serie de componentes basados en ajax, extremadamente útiles y que permiten la introducción de ajax en nuestra aplicación sin ningún tipo de complicación. Incluso permite decidir que componentes o zonas se actualizan ante una petición de ajax, y cuáles no. Por otro lado proporciona un sistema de esquemas que facilita una mejor interfaz gráfica que, si bien es configurable, por lo general es bastante atractivo estéticamente como para no necesitar apenas ninguna modificación. Facelets Sistema simplificado de presentación, en donde es posible diseñar de forma libre una página web y luego asociarle los componentes JSF precisos. Aporta mayor libertad al diseñador y mejora los informes de errores que tiene JSF entre otras cosas. Al igual que titiles en struts, facelets aporta un sistema de plantillas exquisito, que permite la definición incluso de plantillas recursivas, por lo que se puede partir de una plantilla base y hacer subplantillas. Posteriormente los programadores pueden hacer uso de cualquier plantilla para elaborar las pantallas. De este modo se gana en mantenimiento del código y homogeneidad en la presentación. Versión.0 Diseño VUP Página 6 de 9

17 .7. Especificación de Requisitos de Operación y Seguridad El objetivo de esta tarea es definir los procedimientos de seguridad y operación necesarios para no comprometer el correcto funcionamiento del sistema y garantizar el cumplimiento del servicio que exigirá el sistema en cuanto a la gestión de operaciones. Dentro de los procedimientos de seguridad se definen los siguientes puntos: La identidad del usuario está garantizada mediante el binomio Clave SOL y RUC del usuario que acceda al sistema. Dicho binomio será validado por los sistemas de la SUNAT y su resultado será notificado a la VUP. Una vez estén los usuarios logados en el sistema sólo podrán acceder a aquella funcionalidad definida para el rol al cual esté asignado el usuario La configuración del firewall deberá poder bloquear accesos de direcciones no permitidas así como bloquear puertos que sean susceptibles de recibir ataques. Para ello es necesario definir las reglas de acceso y qué direcciones estarán bloqueadas. Como procedimientos de operación se establecen los siguientes: Las copias de seguridad que se realizarán serán copias incrementales diarias (en caliente) con una primera copia completa (en frio), ésta última se repetirá con carácter semanal. El sistema generará un fichero de log por día. En dicho fichero se almacenará además de los errores que se han definido en el punto.3 los siguientes eventos: o Acceso de usuario. o Actividad del usuario: creación, modificación o eliminación de mensajes o datos maestros. Dentro de cada evento definido se incluirá la fecha y hora del evento. Las copias diferenciales entre el servidor maestro y el esclavo para dar soporte al sistema espejo se realizarán durante los periodos de inactivada y justo antes de los periodos definidos como periodos críticos, momentos en los que más actividad y más usuarios accederán al sistema. Versión.0 Diseño VUP Página 7 de 9

18 2. DISEÑO DE CASOS DE USO REALES Esta actividad tiene como propósito especificar el comportamiento del sistema de información para un caso de uso, mediante objetos o subsistemas de diseño que interactúan, y determinar las operaciones de las clases e interfaces de los distintos subsistemas de diseño. Para ello, una vez identificadas las clases participantes dentro de un caso de uso, es necesario completar los escenarios que se recogen del análisis, incluyendo las clases de diseño que correspondan y teniendo en cuenta las restricciones del entorno tecnológico, esto es, detalles relacionados con la implementación del sistema. 2.. Identificación de Clases y diseño de la realización de los Caso de Uso El objetivo de esta tarea es definir cómo interactúan entre sí los objetos para realizar, desde un punto de vista técnico, un caso de uso del sistema de información y por tanto también quedan identificadas las clases que intervienen en cada caso de uso. En esta tarea se han unificado los puntos de identificación de clases y el diseño de la realización de los casos de uso con el objetivo de simplificar el documento ya que en el diseño de la realización de los casos de uso se incluye de forma implícita la identificación de las clases CU_EDI_0 Utilizando como base los escenarios y las interacciones definidas en el documento de análisis y teniendo en cuenta el entorno de desarrollo escogido han surgido las siguientes clases de diseño: EntradaMsg, TypeMsg, ValidaMsg y Guia_Mensaje. Dichas clases se interrelacionan tal y como se explica en el siguiente diagrama de secuencia correspondiente al flujo principal. sd Secuencia Principal EntradaMsg TypeMsg ValidaMsg Guia_Mensaje CU_EDI_02 Actor RecibirMsg(Msg) :TypeMsg Parser(archivo: file) :TypeMsg ValidarMsg(Msg: TypeMsg) :boolean getguia(tipomsg: String) :TypeGuia validate(tipoguia, Msg) :boolean ValidarTemp(tipoguia, Msg) Versión.0 Diseño VUP Página 8 de 9

19 El flujo principal de interacción entre dichas clases de diseño comienza al recibir la clase EntradaMsg el archivo con el mensaje EDI mediante la operación RecibirMsg(). El siguiente paso es convertir dicho archivo XML en un objeto en memoria, esto se realiza mediante el método Parser() de la clase TypeMsg. Una vez se tiene el mensaje EDI en memoria la clase EntradaMsg invoca a la clase ValidaMsg mediante el método ValidarMsg(). La clase ValidaMsg obtiene la guía asociada al mensaje mediante la operación getguia() la Cual invoca a la clase Guia_Mensaje que devolverá la guía que se debe aplicar al mensaje EDI. Una vez obtenida la guía se valida con el método validate(). Si el mensaje es válido se invoca al caso de uso CU_EDI_02 mediante el método ValidarTemp() para continuar con la validación. Existe una secuencia alternativa de interacción entre dichas clases de diseño que comienza al recibir la clase EntradaMsg el archivo con el mensaje EDI mediante la operación RecibirMsg(). El siguiente paso es convertir dicho archivo XML en un objeto en memoria, esto se realiza mediante el método Parser(archivo) de la clase TypeMsg. Una vez se tiene el mensaje EDI en memoria la clase EntradaMsg invoca a la clase ValidaMsg mediante el método ValidarMsg(). La clase ValidaMsg obtiene la guía asociada al mensaje mediante la operación getguia() la Cual invoca a la clase Guia_Mensaje que devolverá la guía que se debe aplicar al mensaje EDI. Una vez obtenida la guía se valida con el método validate(). Si el mensaje no es válido la clase ValidaMsg crea un objeto de la clase Error mediante el uso de métodos Throw() y lo envía al caso de uso CU_EDI_04 mediante el método NotificarError() para indicar que ha habido una sd Secuencia Alternativa EntradaMsg TypeMsg ValidaMsg Error Guia_Mensaje CU_EDI_04 Actor RecibirMsg :file Parser(archivo: file) :TypeMsg ValidarMsg(Msg: TypeMsg) getguia(tipomsg: String) : TypeGuia validate(tipoguia: TypeGuia, Msg: TypeMsg) :boolean Throw Throw(e: Exception) NotificarError(tipoerror: int) excepción con el mensaje. Versión.0 Diseño VUP Página 9 de 9

20 2..2. CU_EDI_02 Utilizando como base los escenarios y las interacciones definidas en el documento de análisis y teniendo en cuenta el entorno de desarrollo escogido han surgido las siguientes clases de diseño: EntradaMsg, TypeMsg, ValidaMsgTemp y TipoMensaje. Dichas clases se interrelacionan tal y como se explica en el siguiente diagrama de secuencia correspondiente al flujo principal. sd Secuencia principal EntradaMsg TypeMsg ValidaMsgTemp TipoMensaje CU_EDI_03 Actor RecibirMsg :TypeMsg gettipo :String validatmp(msg: TypeMsg, tipo: String) getplazo(tipo: String) :String validartmp(plazo: String, Msg: TypeMsg) :boolean ValidarIdentidad(Msg: TypeMsg) (from CU_EDI_0) El flujo principal de interacción entre dichas clases de diseño comienza al recibir la clase EntradaMsg el mensaje de tipo TypeMsg mediante la operación RecibirMsg(). El siguiente paso es obtener el tipo de mensaje, esto se realiza mediante el método gettipo() de la clase TypeMsg. Una vez se tiene el tipo del mensaje la clase EntradaMsg invoca a la clase ValidaMsgTemp mediante el método ValidarTmp(). La clase ValidaMsgTmp obtiene los plazos del mensaje mediante la operación getplazo() la cual invoca a la clase TipoMensaje que devolverá los plazos que se deben aplicar al mensaje EDI. Una vez obtenidos los plazos se valida con el método valídatemp(). Si el mensaje es válido se invoca al caso de uso CU_EDI_03 mediante el método ValidarIdentidad() para continuar con la validación. Existe una secuencia del flujo alternativo de interacción entre dichas clases de diseño que comienza al recibir la clase EntradaMsg el mensaje de tipo TypeMsg mediante la operación RecibirMsg(). El siguiente paso es obtener el tipo de mensaje, esto se realiza mediante el método gettipo() de la clase TypeMsg. Una vez se tiene el tipo del mensaje la clase EntradaMsg invoca a la clase ValidaMsgTemp mediante el método ValidarTmp(). La clase ValidaMsgTmp obtiene los plazos del mensaje mediante la operación getplazo() la cual invoca a la clase TipoMensaje que devolverá los plazos que se deben aplicar al mensaje EDI. Una vez obtenidos los plazos se valida con el método valídatemp(). Si el mensaje no es válido la clase ValidaMsgTemp crea un objeto Versión.0 Diseño VUP Página 20 de 9