Diseño - Modelo 4+1 - Documento 2 (Software Design Guidelines)

Repositorio para trabajos de Tesis Software Design Guidelines:
 

Change History

Versión 1.0, Versión inicial completa, jmora, cnavarro, Diciembre de 2017.

1. Scope

Este documento muestra los principales elementos que componen la arquitectura del sistema Repositorio para Trabajos de Tesis. La arquitectura propuesta, es una versión parcial de todo el sistema acotada exclusivamente a los componentes que que abordan las historias de usuario seleccionadas.

2. References

Este documento se encuentra estructurado de acuerdo a las recomendaciones provistas en:

[1] Kruchten, P. (1995). Architectural blueprints—The “4+ 1” view model of software architecture. Tutorial Proceedings of Tri-Ada, 95, 540-555.

[2] http://www.soa-manifesto.org/default_spanish.html, consultado el 18 de diciembre de 2017.

3. Software Architecture

Para el diseño del sistema se ha definido utilizar una arquitectura orientada a servicios (SOA).

4. Architectural Goals & Constraints

La razón para utilizar SOA se fundamenta en la necesidad de independizar los componentes del sistema, para separar aspectos que pueden variar a velocidades diferentes. Por ejemplo, un proceso relevante que efectúa el sistema es el análisis de archivos pdf, cuyos estándares pueden variar en una línea totalmente independiente del modo como podrían cambiar las necesidades de eventuales cambios en la interfaz de usuario del sistema, por tanto se estima conveniente separar estos aspectos. Una desventaja relevante de utilizar SOA está asociada a los tiempos de respuesta dependientes de la velocidad con que logren interoperar los componentes a implementar, se deberá poner atención en los volúmenes de datos a intercambiar en términos de parámetros y resultados en la interacción con los servicios.

5. Logical Architecture

Las historias de usuario seleccionadas están enfocadas en el proceso de upload y análisis de archivos PDF. El modelo lógico refleja por tanto los elementos del sistema que permiten al usuario especificar el archivo pdf a subir y analizar el archivo pdf, mediante las clases Index() y ProcesadorTesisPdf() respectivamente, las cuales acceden al servicio web implementado en la clase AnalizadorPdf().

El uso de estas clases, permite la implementación encapsulada en sus atributos y métodos de las características y comportamientos específicos requeridos, como el despliegue de la página de subida, el despliegue de resultados y el análisis de los archivos pdf.

El propósito de la clase index es implementar la interfaz de usuario que permite efectuar el upload de archivo mediante un formulario html. El proceso de autentificación del usuario del sistema no es crítico para esta parte del sistema cuya arquitectura se desea describir y por tanto no está reflejado en las vistas, sin embargo, se asume que será posible acceder a los atributos del usuario autentificado (por ejemplo mediante clase hipotética). La clase contempla además un atributo adicional para especificar dónde será enviado el archivo seleccionado por el usuario.

_images/index.png

La clase ProcesadorTesisPdf() se encarga de recibir el archivo pdf enviado para análisis y dejarlo disponible en una URL visible para el Web Service. El método principal para desplegar_resultados() invocará al web service de análisis de archivos pdf y desplegará los resultados de contenido en formato txt, conteo de caracteres y página, para el usuario.

_images/procesadorTesisPdf.png

La clase AnalizadorPdf() debe implementar el servicio web que será utilizado por la aplicación. Los parámetros de entrada encapsulan la autentificación y la ubicación (enlace http) al archivo pdf que debe ser analizado. Mediante el método obtener_atributos_pdf(), se debe obtenerel pdf remoto, almacenar en un archivo temporal y luego se debe proceder con el análisis. Para este análisis se debe utilizar la clase Parser() que implementa métodos de análisis de archivos pdf, como por ejemplo, la extracción del contenido en formato texto (getText), el conteo de páginas y caracteres (getDetails).

_images/parser.png

6. Process Architecture

Los componentes aplicación (App) y Servicio Web (Ws) interactúan para permitir al usuario completar el proceso de subida de archivos pdf, revisión del texto y número de caracteres. El proceso se inicia cuando el usuario sube un archivo pdf. La App debe almacenar el archivo en una ubicación que debe quedar visible en internet para el Ws, luego debe preparar la solicitud para el Ws especificando en la solicitud la ubicación del archivo en internet (en la solicitud se debe enviar parámetros abreviando la URL real del archivo pdf que debe ser analizado, además de un token para controlar el acceso autorizado). Una vez construida la solicitud debe ser enviada por la App al Ws, el cual podría reconstruir la URL del archivo pdf, descargarlo desde internet, analizarlo y si todo sale bien devolver el resultado empaquetado en formato JSON. Es posible que muchas App consuman el Ws, por tanto se deberá disponerse la infraestructura necesaria para soportar la concurrencia requerida. El prototipo a implementar debeutilizar archivos temporales para almacenar y analizar el pdf y debe tener la precaución de utilizar nombres de archivos temporales únicos para evitar colisiones. Debe considerarse asignar los recursos de procesamiento necesarios para que el Ws efectúe el análisis del pdf en un tiempo apropiado, que debe estar evidentemente por debajo del timeout de la conexión http Ws y considerar el tiempo de espera aceptable para el usuario objetivo y la concurrencia esperada por el lado de la App. Debe establecerse y configurarse límites apropiados también para el tamaño del archivo pdf, debido a que se detectó mediante pruebas preliminares de la clase Parser() que esta variable impacta directamente en los tiempos requeridos para el procesamiento. El proceso puede verse interrumpido por diversos eventos asociados a la naturaleza de los servicios Web, por tanto estos eventos deben ser adecuadamente capturados, codificados e informados por la App. Por ejemplo, cuando aplique, se debería implementar al menos códigos de mensajes de error http como los siguientes:

  • 503 ‘Service Unavailable’
  • 405 ‘Method Not Allowed’
  • 400 ‘Unauthorized’‘
  • 401 ‘Bad Request’
  • 404 ‘Not Found’
  • 500 ‘Internal Server Error’

7. Development Architecture

El sistema estará basado en dos componentes que deben interactuar a través de una jerarquía donde la aplicación debe consumir los servicios del web service para entregar al usuario los resultados de análisis requeridos respecto a un pdf.

_images/d_componentes.png

El componente asociado a la aplicación debe implementar lo relacionado con la interfaz de usuario y el control de las solicitudes (y sus resultados) efectuadas al Web service (todos asociados al dominio específico de necesidades de revisión de trabajos de tesis). Es posible identificar paquetes de trabajo para la etapa de codificación, donde se deberá abordar la construcción elementos interfaz de usuario, comunicaciones con web service y análisis de archivos pdf. El componente correspondiente al servicio web no está asociado a un dominio específico, sino al propósito genérico de analizar archivos pdf, razón por la cual el componente es reutilizable y a la vez abre posibilidades de incorporar componentes genéricos desarrollados por terceros. Una ventaja muy relevante de utilizar servicios web, consisten en la independencia de la tecnología a utilizar para su implementación, sin embargo se debe tener en cuenta las posibilidades de infraestructura y los perfiles disponibles a su vez en el equipo de desarrollo. Los aspectos de seguridad son relevantes toda vez que los datos intercambiados con el servicio web pueden quedar expuestos en un canal no seguro, por lo cual se recomienda el uso de https, además de los mecanismos de autentificación usuales. Deberá considerarse paquetes de trabajo asociados a aspectos de seguridad, en particular la configuración y verificación de https y autenticación.

8. Physical Architecture

La implementación de los componentes debe efectuarse para operar en máquinas o servidores diferentes. La aplicación podrá operar en un servidor A y el servicio web podrá operar en un servidor B. La comunicación podrá efectuarse a través de internet pero bajo estándares mínimos de protocolo seguro como https. En concreto ambos componentes quedan separados físicamente (aunque la “separación física” puede referirse también a máquinas virtuales distintas).

_images/d_despliegue.png

Este mapeo otorga flexibilidad e implica mínimo impacto en el código fuente. Es altamente recomendable utilizar infraestructura en la nube, de modo que los aspectos de disponibilidad, confiabilidad, rendimiento y escalabilidad, sean manejables en función de los recursos asignados.

9. Scenarios

Las cuatro vistas lógica, desarrollo, proceso y física convergen en la vista de escenario mediante un diagrama de caso de uso, que destaca los comportamientos relevantes del sistema que a su vez presentan resultados observables para el profesor guía, como el despliegue del formulario de upload por parte de la aplicación, que permitirá gatillar el proceso de subida de archivos pdf, el cual a su vez mediante el consumo del servicio web de análisis de archivos pdf, deberá entregar los resultados de análisis de la tesis reportada por el usuario en el archivo pdf.

_images/d_casos_uso.png

10. Quality

Los esfuerzos en términos de recursos computacionales a asignar deberán apuntar a minimizar los Tiempos de Respuesta requeridos por el sistema para el proceso de análisis y presentación de resultados. Ante la variabilidad del comportamiento de los servicios remotos en función de aspectos como la conectividad disponible, tráfico, concurrencia y volumen de datos, etc., los métodos de despliegue deben implementar controles para detectar eventuales excepciones e informarlas oportunamente al usuario mediante adecuado feedback basado en códigos de error estándar http.

11. Size and Performance

La arquitectura planteada, basada en servicios, posee límites en tamaño y rendimiento dados principalmente por las capacidades de cómputo de la infraestructura, las cuales normalmente pueden ser bien controladas en entornos de plataforma como servicio (en la nube). En el caso de utilizar servidores propios, por tratarse de un servicio compartido, es posible que el componente correspondiente al servicio web que implementa análisis de pdf, se convierta en un cuello de botella que limite el rendimiento, sin embargo, dado que la solución está basada en servicios, es también compatible con una infraestructura de alto rendimiento, a implementar mediante un cluster de servidores y balanceador de carga, sin requerir ningún cambio a nivel de aplicación ni servicio web.

Se debe disponer además de espacio de almacenamiento suficiente para el manejo de archivos temporales que pueden ser eliminados en cuanto concluye su análisis, por tanto deberá separarse la capacidad necesaria para el peor caso en términos de concurrencia y tamaño de los upload aceptados.

Appendices

  1. Acronyms and Abreviations

En este documento se utiliza acrónimos y abreviaciones para referirse a:

  • HTTP: El Protocolo de transferencia de hipertexto es el protocolo de comunicación que permite las transferencias de información en la World Wide Web.
  • PDF: (sigla del inglés Portable Document Format, «formato de documento portátil») es un formato de almacenamiento para documentos digitales independiente de plataformas de software o hardware.
  • HTTPS: Hypertext Transfer Protocol Secure (en español: Protocolo seguro de transferencia de hipertexto), más conocido por sus siglas HTTPS, es un protocolo de aplicación basado en el protocolo HTTP, destinado a la transferencia segura de datos de Hipertexto, es decir, es la versión segura de HTTP.
  • WS: (del inglés Web Service) Servicio Web
  • APP: (del inglés Application) Aplicación
  1. Definitions

SOA: Service Oriented Architecture (SOA) es un paradigma para organizar y utilizar capacidades distribuidas que pueden estar bajo el control de diferentes dominios de propiedad.

  1. Design Principles

El diseño arquitectural presentado, se basa en SOA y responde a las prioridades y principios expuestos en su Manifesto [2], con especial énfasis para el alcance de este en los siguientes aspectos

  • Priorizar la descomposición de la arquitectura en componentes independientes por sobre una estructura monolítica.
  • Implementar servicios tan independientes como sea posible del dominio específico, de modo de permitir posteriormente su reutilización.
  • Se prioriza la interoperabilidad para disminuir el acoplamiento.
  • Se busca el uso de servicios compartidos en vez de la implementación de uso exclusivo.
  • Se aspira a la mejora evolutiva por sobre la búsqueda de la perfección inicial .