Repositorio para Trabajos de Tesis

Documentación Arquitectural Proyecto Semestral - Repositorio para trabajos de Tesis, Arquitectura de Software, Magíster en Ingeniería Informática Universidad de La Frontera - 2017

Contenido:

Autores

• Claudio Navarro
• Jeremías Mora

Stakeholders

1. Usuario Profesor Guía : Profesores guía encargados de revisar Tesis de alumnos de pregrado de Universidades.
2. Usuario Alumno Tesista : Alumnos tesistas de pregrado que cuentan con un profesor guía.

Visión, Objetivos y Áreas

Vision

El proceso de monitoreo del estado de avance de los trabajos de muchos alumnos tesistas, es un problema no trivial para el profesor guía y podría ser simplificado de contar con una solución informática capaz de capturar y sistematizar el contenido a partir de los informes de avance reportados como archivos PDF por los alumnos.

Objetivos

• Implementar un sistema basado en arquitectura SOA capaz de capturar y analizar archivos PDF.

Área

El sistema está orientado a dar soporte a las necesidades de lectura en formato texto plano obtenido desde archivos PDF, para uso por parte de profesores y alumnos en contextos académicos.

Area de Historias de Usuario

A continuación de detallan las Historias de Usuario de un Profesor encargado de tesistas o también llamado profesor guía y un alumno tesista de pregrado.

Como	quiero	de modo que
profesor encargado de tesistas	acceder al sistema con mi email institucional y mi contraseña	pueda trabajar con las tesis de mis alumnos.
profesor encargado de tesistas	poder guardar los archivos PDF que me envíen los alumnos tesistas en la plataforma	pueda tener un reposit- torio de distintas tesis y sus distintas versiones.
profesor encargado de tesistas	que la plataforma automáticamente incremente las versiones de las revisiones de tesis	pueda ver de forma rápida cuantas iteraciones se han realizado.
profesor encargado de tesistas	poder asignar un estado a cada tesis	pueda distinguir entre las que ya fueron cerradas, calificadas, pendientes y las que están en corrección
profesor encargado de tesistas	poder extraer el contenido del archivo PDF	pueda leer el texto de la tesis dentro de la misma plataforma.
profesor encargado de tesistas	poder corregir y realizar comentarios a las tesis dentro de la plataforma	el alumno cuando acceda con su cuenta, pueda ver que correcciones dene realizar para la siguiente iteración.
profesor encargado de tesistas	poder ver la cantidad de caracteres que tiene el archivo PDF	inferir el volumen de trabajo ejecutado a partir de la cantidad de texto producido por el alumno tesista en las distintas iteraciones.
profesor encargado de tesistas	poder ver la cantidad de páginas que tiene el archivo PDF	inferir el volumen de trabajo ejecutado a partir de la cantidad de páginas producidas por el alumno tesista en las distintas iteraciones.
Alumno tesista	poder acceder a la plataforma con mi correo institucional y contraseña	pueda ver mi informacion personal con respecto a mi tesis.
Alumno tesista	ver los comentarios que ha hecho mi profesor guía	pueda tener claro lo que mi profesor guía me pidio corregir o agregar.
Alumno tesista	responder comentarios de mi profesor guía	podriamos tener una mejor comunicación del contenido y avances de la tesis

Selección de Historias de Usuarios

Las historias de usuarios seleccionadas para la primera versión de la plataforma son las siguientes:

Como	quiero	de modo que
profesor encargado de tesistas	poder extraer el contenido del archivo PDF	pueda leer el texto de la tesis dentro de la misma plataforma.
profesor encargado de tesistas	poder ver la cantidad de caracteres que tiene el archivo PDF	inferir el volumen de trabajo ejecutado a partir de la cantidad de texto producido por el alumno tesista en las distintas iteraciones.
profesor encargado de tesistas	poder ver la cantidad de páginas que tiene el archivo PDF	inferir el volumen de trabajo ejecutado a partir de la cantidad de páginas producidas por el alumno tesista en las distintas iteraciones.

Dichas Historias de Usuario consisten en subir un archivo para luego visualizar el contenido entregado por un servicio web, esto corresponde a un paso anterior a guardar el contenido en la plataforma, para así poder usar el contenido cuando se desee.

Mockups

Mediante la siguiente interfaz es posible iniciar el proceso de extracción del contenido de texto desde un archivo PDF:

El sistema despliega un cuadro de diálogo de selección de archivo PDF cuando el usuario hace clic en el botón Examinar:

Una vez que el archivo seleccionado es subido y el usuario hace clic en el botón Subir, el sistema presenta la siguiente interfaz, donde se despliega el conteo de caracteres de texto encontrados en el PDF y el contenido correspondiente en formato texto plano:

Para repetir el proceso y volver a subir un nuevo archivo PDF, el usuario puede hacer clic en el botón Volver y el sistema desplegará la interfaz inicial.

Diseño - Modelo 4+1 - Documento 1 (Software Architecture Document)

El método 4+1 nos permitirá describir la arquitectura de sistemas software llamado Repositorio para Trabajos de Tesis, basados en el uso de múltiples vistas concurrentes. Estas vistas nos permitirán analizar el problema y describir el sistema desde el punto de vista de distintos interesados, como lo son los usuarios finales (Usuario profesor guía y Usuario estudiante tesista), los desarrolladores y/o jefes de proyecto.

Las cuatro vistas del modelo son:

1. Vista lógica.
2. Vista de desarrollo.
3. Vista de proceso.
4. Vista física.
5. Además, una selección de casos de uso o que se utilizará para ilustrar la arquitectura sirviendo como una vista más.

Dichas vistas se mencionan a continuación:

1. Vista lógica

Está enfocada en describir la estructura y funcionalidad del sistema, y para éste sistema se utilizó un diagrama de Clases para representar esta Vista. El cual está separado en 2 package:

1. Package AppAnalizarTesis:

• Clases 1: Index
• Clase 2: ProcesarTesisPdf

1. Package WS-AnalizarPDF (Servicio Web):

• Clase 1: AnalizarPdf
• Clase 2: Parser

La siguiente imágen fue creada con la herramienta draw.io

La siguiente imágen fue creada mediante código con la herramienta codetouml http://londres.ceisufro.cl/codetouml

2. Vista de desarrollo

Ilustra el sistema de la perspectiva del programador y está enfocado en la administración de los artefactos de software. El Diagrama Componentes UML se utiliza para describir los componentes del sistema. El cual contiene dos componentes

1. Componente 1: App Analizar Tesis
2. Componente 2: Servicio Web Analizar PDF

Ambos conectados mediante el protocolo HTTP.

La siguiente imágen fue creada con la herramienta draw.io

No fue posible generar este diagrama con codetouml ya que no se encontró en la herramienta los componentes y conectores requerido para esta representación.

3. Vista de proceso

Explica los procesos de sistema y cómo se comunican. se enfoca en el comportamiento del sistema en tiempo de ejecución

Esta vista se representará con un diagrama de Actividad.

En él se detallan tres actores:

1. Usuario
2. App
3. Servidor Web

La siguiente imágen fue creada con la herramienta draw.io

La siguiente imágen fue creada mediante código con la herramienta codetouml http://londres.ceisufro.cl/codetouml. El diagrama se encuentra incompleto ya que no se logró asociar correctamente las actividades de los distintos roles.

4. Vista fisica

Describe el sistema desde el punto de vista de un ingeniero de sistemas. Está relacionada con la topología de componentes de software en la capa física (hardware), así como las conexiones físicas entre estos componentes.

En el se muestra dos nodos, como capa física y dentro de ellos sus artefactos o componentes de software:

1. Nodo 1: Workstation

• Componente Web Browser.

2. Nodo 2: Web Server App

• Componente App Analizar Tesis.

3. Nodo 3: Web Server Web Service

• Componente Servicio web Analizar PDF
• Componente Parser (Librería PHP que permite leer un archivo PDF)

La siguiente imágen fue creada con la herramienta draw.io

No fue posible generar este diagrama con codetouml ya que no se encontró en la herramienta los componentes y conectores requerido para esta representación.

5. Escenarios

Los escenarios describen secuencias de interacciones entre objetos, y entre procesos. Se utilizan para identificar y validar el diseño de arquitectura. También sirven como punto de partida para pruebas de un prototipo de arquitectura. La descripción de la arquitectura se ilustra utilizando un conjunto de casos de uso.

En él, se modelan tres casos de uso y un actor del sistema.

1. Sistema:

• Repositorio para Trabajos de Tesis

2. Actor:

• Profesor Guía

3. Casos de uso:

• Mostrar formulario upload tesis.
• Subir Archivo PDF.
• Mostrar resultado análisis tesis pdf.

La siguiente imágen fue creada con la herramienta draw.io

La siguiente imágen fue creada mediante código con la herramienta codetouml http://londres.ceisufro.cl/codetouml. El diagrama se encuentra incompleto ya que no se logró asociar correctamente el actor Profesor Guía con el caso de uso “Mostrar formulario upload tesis”.

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.

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.

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).

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.

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).

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.

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

2. 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.

3. 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 .

Implementación y Testing

Fue implementado un prototipo de aplicación y servicio Web hosteado en un servidor visible en internet. Se utilizó PHP 5.6 sobre Apache 2.0 sobre un servidor virtual.

A continuación el resumen de casos de prueba ejecutados:

Estado	Equipo Responsable	Casos de prueba	Comportamiento esperable	Iteración 1 (Fecha)	Evaluacion	Iteración 2 (Fecha)	Evaluacion
Resuelto	Claudio Jeremías	Subir archivo pdf y comprobar que queda almacenado para ser accedido por el webservice desde internet	El archivo debe quedar almacenado en el directorio visible desde internet y se debe utilizar un nombre de archivo que incorpore una marca de microtime para evitar colision	20/12/2017	NO Ok: archivo visible pero no incorpora marca de tiempo	21/12/2017	Ok: Opera Correctamente
Resuelto	Claudio Jeremías	Verificar que las llamadas al Ws sean consistentes en métodos y parametros.		19/12/2017	Ok: llamada construida de forma correcta.
Resuelto	Claudio Jeremías	Comprobar operación de aplicacioón cuando el Ws se encuentra inaccesible		20/12/2017	No Ok: aplicacion presenta mensajes de error y no controla ejecucion cuando el Ws no responde o no existe.	20/12/2017	Ok: Opera Correctamente
Resuelto	Claudio Jeremías	Implementar mensajes de error basado en códigos http para cada tarea ejecutada por el webservice	Implementar por lo menos 503 Service Unavailable 405 Method Not Allowed 400 Unauthorized 401 Bad Request 404 Not Found 500 Internal Server Error	21/12/2017	Ok: Simulados y verificados los mensajes de error del webservice.
Resuelto	Claudio Jeremías	Comprobar que el texto desplegado es consistente con el contenido del documento pdf		19/12/2017	Ok: texto es consistente.	21/12/2017
Resuelto	Claudio Jeremías	Comprobar que el conteo de páginas es consistente con el contenido del documento pdf		19/12/2017	Ok: texto es consistente.	21/12/2017
Resuelto	Claudio Jeremías	Comprobar que el conteo de caracteres es consistente con el contenido del documento pdf		19/12/2017	Ok: texto es consistente.	21/12/2017

Deployment

La aplicación se encuentra disponible en:

http://35.192.225.221/lab/repo_tesis/

El servicio web está en línea en:

http://35.192.225.221/lab/pdfparser-master/analizadorpdf.php

Las solicitudes al servicio web deben efectuarse usando el método GET, considerando los siguientes parámetros:

http://35.192.225.221/lab/pdfparser-master/analizadorpdf.php/servidor_donde_esta_el_pdf/ruta_pdf/archivo_pdf/token

Ejemplo:

Por ejemplo esta solicitud:

http://35.192.225.221/lab/pdfparser-master/analizadorpdf.php/mi.dominio.com/lab.repo_tesis.files/capitulo1.pdf/1AEFB345EFA

analiza el archivo que se encuentra en:

http://mi.dominio.com/lab/repo_tesis/files/capitulo1.pdf

Repositorio Github de la aplicación y documentación arquitectónica:

https://github.com/jero21/template

Anexos

A. Código Diagrama de Clases con CodeToUml

[package AppAnalizarTesis|

[ Index |nombreUsuario: String |udEstaAqui: String |urlUpload: String ||desplegarFormUpload()

]

[ ProcesadorTesisPdf |nombreArchivo: String |rutaArchivo: String |nombreServidor: String |url_ws: String |contenido_tesis_txt: String |numero_caracteres_tesis: number |numero_paginas_tesis: number ||desplegarResultado(String nombreUsuario, String udEstaAqui, String token) ]

]

[package WS-AnalizarPDF|

[ AnalizadorPdf

|cantidad_paginas: number |cantidad_caracteres: number |contenido: String |url_pdf: String ||obtener_atributos_pdf(String token): json

] +–> [ Parser

|parseFile(String path): json |getText(): String |getDetails(): String |desplegarFormUpload()

]

]

B. Código Diagrama Actividad con CodeToUml

[Sistema de repositorio y versionado de tesis|

[Usuario|

[<start> start] – [<state> Accede al;sistema] [<state> Accede al;sistema]–> [<state> Subir archivo; PDF de Tesis]| [<state> Visualizar y analiza; resultados de la tesis] –> [<end> end]

] [Aplicacion|

[<state> Generar nombre;de archivo a partir;fecha y hora]–> [<state> Crear copia de archivo; en carpeta temporal] [<state> Crear copia de archivo; en carpeta temporal] —> [<state> Construir URL para; llamado del web service] [<state> Construir URL para; llamado del web service] –> [<state> Realiza petición; GET y espera; respuesta] [<state> Realiza petición; GET y espera; respuesta]

] [Servicio Web|

[<state> Valida solicitud; GET]–> [<state> Obtener ;parámetros] [<state> Obtener ;parámetros] –> [<state> Validar Token] [<state> Validar Token] –> [<state> Construír URL ;para buscar PDF] [<state> Construír URL ;para buscar PDF] –> [<state> Valida si ;existe URL] [<state> Valida si ;existe URL] –> [<state> Obtiener texto del; pdf, cantidad de; caracteres y ;de páginas] [<state> Obtiener texto del; pdf, cantidad de; caracteres y ;de páginas] –> [<state> Retorna respuesta; en formato JSON]

]

]

C. Código Diagrama de Casos de Uso con CodeToUml

[<actor> Profesor Guía] -> [<frame> Repositorio para Trabajos de; Tesis] [<frame> Repositorio para Trabajos de; Tesis |

[<usecase> Mostrar formulario; upload tesis] <– <<extend>> [<usecase> Subir archivo; PDF]

[<usecase> Subir archivo; PDF] <<include>> –> [<usecase> Mostrar resultado; análisis tesis pdf]

]

Indices and tables

• Index