TRABAJO FIN DE GRADO Sistema de Entrega Deliverit: Prototipo

Graduado en Ingeniería Informática

Universidad Politécnica de Madrid

Escuela Técnica Superior deIngenieros Informáticos

TRABAJO FIN DE GRADO

Sistema de Entrega Deliverit: Prototipo

Autor: Andrés Mareca

Director: Ángel Herranz

MADRID, ABRIL DE 2020

Este trabajo está dedicadoa mi primer CTO (Chief Technology Officer),

por enseñarme lo que es de verdad el desarrollo de sofware.

Sin la oportunidad que me diste no sería el desarrolladoren el que me he convertido.

Gracias.

Índice general

Resumen V

Abstract VII

1. Introducción 1

1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Estructura del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Glosario 7

3. Modelización del sistema 9

3.1. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2. Modelo de interacción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4. Arquitectura 31

4.1. Aplicaciones Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2. Lógica de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3. Persistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.4. Comprobación de entregas . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.5. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

I

4.6. Sobre Elixir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5. Implementación 37

5.1. Aplicación Umbrella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.2. Aplicaciones Phoenix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.3. Aplicaciones y bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.4. Librería Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6. Metodología 45

6.1. Agilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.2. Control de versiones Git y fujos de trabajo . . . . . . . . . . . . . . . . . . . 48

6.3. Traducciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7. Conclusiones y trabajo futuro 51

7.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.2. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Bibliografía 55

II

Índice de figuras

1.1. Arquitectura del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1. Diagrama entidad relación . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2. Modelo de interacción para alumnos . . . . . . . . . . . . . . . . . . . . . . 25

3.3. Modelo de interacción para profesores (i) . . . . . . . . . . . . . . . . . . . 25

3.4. Modelo de interacción para profesores (ii) . . . . . . . . . . . . . . . . . . . 26

3.5. Modelo de interacción para administradores (i) . . . . . . . . . . . . . . . . 27

3.6. Modelo de interacción para administradores (ii) . . . . . . . . . . . . . . . . 28

3.7. Modelo de interacción para administradores (iii) . . . . . . . . . . . . . . . . 28

3.8. Modelo de interacción para administradores (iv) . . . . . . . . . . . . . . . . 29

4.1. Diagrama de componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.1. Estructura de directorios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5.2. Estructura de directorios (aplicación) . . . . . . . . . . . . . . . . . . . . . . 39

5.3. Estructura de directorios (bibliotecas) . . . . . . . . . . . . . . . . . . . . . 41

5.4. Acciones Docker sobre imágenes . . . . . . . . . . . . . . . . . . . . . . . . 42

5.5. Acciones Docker sobre contenedores . . . . . . . . . . . . . . . . . . . . . . 43

III

IV

Resumen

En este trabajo he implementado un sistema de entrega y comprobación de prácticas de

programación seguro, flexible, usable y moderno. Su nombre: Deliverit (entrégalo). Cada una

de estas características se ha conseguido mediante la aplicación de diferentes tecnologías y

procesos de desarrollo:

Docker: Las prácticas entregadas por los estudiantes se ejecutarán en contenedores Docker.

De esta forma, potenciales errores o código malicioso en cada entrega se ejecutan de

forma aislada del resto del sistema. Esto ayuda en aspectos de seguridad y flexibilidad

(cada asignatura podrá emplear un entorno de ejecución diferente de las otras).

Erlang/OTP: Concurrencia, distribución y tolerancia a fallos son aspectos soportados por

la tecnología Erlang/OTP utilizada para desarrollar este proyecto. Esto nos ayuda en

aspectos de seguridad y modernización del sistema en comparación con otros sistemas

anteriormente implementados en Perl o PHP.

Phoenix/Elixir: Sobre Erlang/OTP se han construido el lenguaje de programación Elixir y

el framework de desarrollo Web Phoenix. Ambas tecnologías mejoran la productividad

y ayudan a introducir cambios de forma rápida, lo que a su vez ayuda a que el sistema

sea flexible y pueda ser usado bajo la exigencia de diferentes asignaturas.

Hay que ser consciente de que ninguna tecnología es una bala de plata en la lucha contra

las dificultades fundamentales del desarrollo del software. Además a toda tecnología debemos

añadir una buena arquitectura que también explicaré en detalle.

Este trabajo comencé a realizarlo con el profesor Ángel Herranz en julio de 2019 con la

construcción de un protoipo usable en menos de un mes. Dicho prototipo fue evolucionado

por mi compañero Aaron Contreras, que se centró en la mejora de la experiencia e interfaz

de usuario. En enero de 2020 retomé el trabajo centrándome en dar estabilidad y flexibilidad

al sistema, especialmente en relación a las entregas, ejecuciones y comprobaciones de las

mismas.

V

VI

Abstract

In this end of degree project I have implemented a modern, secure, flexible, usable and

modern programming practice delivery and testing system. His name: Deliverit (hand it in).

Each of these characteristics has been achieved through the application of different technolo-

gies and development processes:

Docker: The practices delivered by the students will be carried out in Docker containers. In

this way, potential errors or malicious code in each delivery are executed in isolation

from the rest of the system. This helps in security and flexibility aspects (each subject

may use a different execution environment from the others).

Erlang/OTP: Concurrency, distribution and fault tolerance are aspects supported by the Er-

lang/OTP technology used to develop this project. This helps us in aspects of security

and modernization of the system (using as reference other systems implemented in Perl

or PHP).

Phoenix/Elixir : The Elixir programming language and the Phoenix Web development frame-work have been built on Erlang/OTP. Both technologies improve productivity and help

to introduce changes quickly, which helps to make the system flexible and can be used

under the demands of different subjects.

I am aware that no technology is a silver bullet in the fight against the fundamental dif-

ficulties of software development. To all this we must add a good architecture that I will

explain in detail.

I started doing this project with Professor Ángel Herranz in July 2019 and then I built

a usable prototype in less than a month. This prototype was evolved by my partner Aaron

Contreras, who focused on improving the experience and user interface. In January 2020,

I resumed my work focusing on giving stability and flexibility to the system, especially in

relation to the deliveries, executions and checks of the same.

VII

VIII

1Introducción

En este capítulo voy a ofrecer una motivación y un listado de objetivos que el profesor

Herranz marcó al inicio del proyecto.

1.1 Motivación

En la Escuela Técnica Superior de Ingenieros Informáticos (ETSIINF) de la Universidad

Politécnica de Madrid (UPM) hay múltiples sistemas de entrega y comprobación de prácticas,

incluidos los que vienen empotrados en las plataformas institucionales como Moodle [19] o

Teams [17].

La mayor parte de estos sistemas se implementaron hace años, alguno tiene más de 20

años, en concreto el implementado por los profesores Manuel Collado y Ángel Herranz en la

unidad de programación del Departamento de Lenguajes y Sistemas Informáticos e Ingeniería

de Software (DLSIIS). Todos tienen un punto de anticuados desde los estándares actuales de

la Web y algunos ni siquiera tienen el más mínimo control de seguridad: el código de los

estudiantes es recogido y ejecutado sin ningún tipo de control por lo que un código incorrecto

o malicioso puede tener un impacto impredecible en la máquina en la que se ejecuta, el

servidor Web.

También en la unidad de programación, se heredó del Departamento de Arquitectura y

Tecnología de Sistemas Informáticos (DATSI) un sistema que sí ejecuta el código de las

1

1 Introducción

entregas de los alumnos en una jaula empleando el mandato chroot. Los avances en con-

tenedores [7] hacen que la técnica anterior nos parezca poco flexible para usarla en otras

asignaturas. Además, dicho sistema no tiene interfaz gráfico que ayude a estudiantes y sobre

todo a profesores y administradores del mismo.

Nuestra motivación es construir un nuevo sistema de entrega que pueda ser usado no sólo

por varias asignaturas si no en varios departamentos, incluso varias escuelas, incluso, ¿por

qué no?, varias universidades.

1.1.1 Un nuevo sistema de entrega: características

¿Qué características debería tener el nuevo sistema? En el resumen ofrecí una lista de

estas características y ahora profundizo en ellas:

Seguro Las prácticas de los estudiantes deben estar a salvo en el sistema para que nadie

más que los autores y los profesores puedan ver dichas entregas. Además, el propio

sistema debe estar a salvo del código entregado por los estudiantes: la ejecución del

código entregado podría afectar negativamente al sistema, o incluso a todo el sistema

operativo.

Flexible El objetivo es que el sistema sea lo suficientemente flexible como para que se pueda

usar en diferentes prácticas y diferentes asignaturas. Cada asignatura puede usar un

lenguaje de programación diferente, y en asignaturas avanzadas, las tecnologías qué se

enseñan pueden llegar a ser muy complejas. En otras palabras, cada asignatura exige

un entorno de construcción y pruebas diferente.

Usable Dentro de mis posibilidades he intentado cuidar al máximo la experiencia de usuario.

El sistema tiene que resultar atractivo para todos los usuarios del mismo, tanto profeso-

res como alumnos. Este quizás sea uno de los aspectos que me resultan especialmente

complicados de implementar.

Moderno Muy relacionado con lo anterior, he buscado que el sistema sea moderno. Des-

de el punto de vista del desarrollo, debemos emplear patrones de código, lenguajes y

herramientas orientadas a la productividad del desarrollo.

1.1.2 Tecnología

Soy consciente de que ninguna tecnología es una bala de plata [3] en la lucha contra

las dificultades fundamentales del desarrollo del software. Sin embargo, la seleccion de una

tecnología marca diferencias importantes en el resultado final. Ofrezco un detalle sobre las

tecnologías que he decido emplear para este desarrollo:

2

1.1 Motivación

Docker: [22] Las prácticas entregadas por los estudiantes se ejecutarán en contenedores

Docker. De esta forma, potenciales errores o código malicioso en cada entrega se eje-

cutan de forma aislada del resto del sistema. Esto ayuda en aspectos de seguridad y

flexibilidad, cada asignatura podrá emplear un entorno de ejecución diferente de lasotras.

Erlang/OTP: [16] Concurrencia, distribución y tolerancia a fallos son aspectos soportados

por la tecnología Erlang/OTP utilizada para desarrollar este proyecto. Esto nos ayuda

en aspectos de seguridad y modernización del sistema comparado con otros sistemas

implementados anteriormente en Perl o PHP). OTP (Open Telecom Platform), es un

conjunto de librerías, herramientas y patrones que nos permiten gestionar procesos y

concurrencia con mucha más facilidad. Con OTP, y utilizando también Elixir, podemos

conseguir controlar todas estas características de los sistemas distribuidos de forma

robusta.

Phoenix/Elixir: Sobre Erlang/OTP se han construido el lenguaje de programación Elixir [15]

y el framework de desarrollo Web Phoenix [6]. Ambas tecnologías mejoran la produc-

tividad y ayudan a introducir cambios de forma rápida, lo que a su vez ayuda a que el

sistema sea flexible y pueda ser usado bajo la exigencia de diferentes asignaturas.

1.1.3 Arquitectura

Deliverit va a ofrecer todos sus servicios y funcionalidades a través de una aplicación

Web, por lo que el sistema se va a dividir en una parte de back-end (código que ejecutará en

el servidor) y una parte front-end (código que se ejecutará en los navegadores) [2].

La aplicación está compuesta por tres aplicaciones distintas: una para alumnos, otra pa-

ra profesores y una última aplicación Web que hará de panel de administración global del

sistema. Estás tres aplicaciones van a compartir tres librerías que se usarán tanto para inter-

accionar con la base de datos, como para interaccionar con Docker y una última librería que

contendrá toda la lógica de negocio.

Aunque veremos la arquitectura en detalle en el capítulo 4, adelanto en la figura 1.1 un

diagrama en la que represento los tres niveles con los que he trabajado.

El lenguaje de implementación elegido para el desarrollo ha sido Elixir y las tres principa-

les herramientas que me han ayudado en la arquitectura han sido Phoenix (framework Web),

Umbrella (estructura de aplicaciones) y Ecto (adaptador a bases de datos SQL). Entraré en

sus detalles a lo largo de los capítulos 4 y 5.

Mencionaré que la biblioteca que conecta Elixir con Docker se ha decido extraer fuera del

sistema ya que puede ser utilizada por cualquier otro proyecto fuera de Deliverit. Y ademas

3

1 Introducción

Aplicaciones Web

Web de estudiantes Web de profesores Web de administración

Componentes front-end

Lógica del sistema (logic)

Asignaturas Prácticas Alumnos Entornos . . .

Persistencia y comprobaciones

Nivel de acceso a datos (database)Entornos y comprobaciones

(dockerex)

Figura 1.1: Arquitectura del sistema

entendemos que con esa librería podemos ayudar a otros desarrolladores a usar Docker desde

Elixir sin necesidad de programarselo ellos mismo.

1.2 Objetivos

Inicialmente, el profesor Herranz planteó el desarrollo de un sistema con tres subsiste-

mas: una aplicación Web para estudiantes (entrega de prácticas), una aplicación Web para

profesores (alta de asignaturas y prácticas) y un cuadro de mandos para los administradores

del sistema (instalación y configuraciones del sistema).

Voy a listar en las siguientes secciones las historias de usuario tal y como fueron conce-

bidas hace ya casi un año.

1.2.1 Aplicación de estudiantes

1. Como estudiante quiero acceder con mi número de matrícula y una contraseña.

4

1.2 Objetivos

2. Como estudiante quiero recuperar mi contraseña por correo electrónico.

3. Como estudiante quiero darme de alta en las prácticas sólo o en grupo.

4. Como estudiante quiero entregar mi práctica.

5. Como estudiante quiero recibir información sobre la comprobación de mi práctica.

6. Como estudiante quiero ver las entregas realizadas y sus resultados en cualquier mo-

mento.

1.2.2 Aplicación de profesores

1. Como profesor quiero crear una asignatura.

2. Como profesor quiero registrar alumnos en una asignatura.

3. Como profesor quiero crear y configurar una práctica en una asignatura (número de

alumnos por grupo, fechas de entrega, ficheros a entregar, ficheros de comprobaciones,

entorno de ejecución, etc.).

4. Como profesor quiero ver las entregas realizadas y los resultados.

5. Como profesor quiero configurar el sistema de recepción y pruebas para las entregas

de una práctica.

6. Como profesor quiero extraer informes sobre las entregas.

7. Como profesor quiero extraer el código entregado por los estudiantes.

8. Como profesor quiero duplicar una práctica.

1.2.3 Cuadro de mando de administración

1. Como administrador quiero registrar estudiantes en el sistema (en masa, usando fiche-

ros “oficiales” como las preactas).

2. Como administrador quiero dar de alta diferentes entornos de ejecución que puedan

usarse en las prácticas.

3. Como administrador quiero dar de alta profesores.

5

1 Introducción

1.3 Estructura del trabajo

Uno de los objetivos de mi trabajo es facilitar la participación de otros compañeros en el

desarrollo del sistema. La estructura del trabajo está orientada a acelerar el entendimiento del

sistema.

El capítulo 2 contiene un glosario de términos ubicuos1. El capítulo puede usarse como

referencia por lo que no es necesario leerse todos los términos en una primera lectura

del trabajo.

El capítulo 3 se presenta el modelo de datos y el modelo de interacción del sistema.

En el capítulo 4 podremos ver los detalles de las decisiones arquitectónicas, los dife-

rentes niveles y componentes.

En el capítulo 5 expondré ciertos detalles de la implementación relacionados con el

lenguaje y la tecnología empleada.

En el capítulo 6 quiero mencionar aspectos metodológicos que he seguido en el trabajo

y que creo que pueden ser inspiradores para los desarrolladores futuros.

Termino con conclusiones y propuestas de trabajos futuros en el capítulo 7.

1Usamos la palabra como reminiscencia al concepto de ubiquous language de Eric Evans en su libro sobre

desarrollo dirigido por modelos.

6

2Glosario

Este capítulo ofrece un glosario de términos inspirado en el concepto ubiquous languagede Eric Evans [14]. El glosario debe servir al equipo de desarrollo para hablar un lenguaje

común. En palabras del propio autor:

The UBIQUITOUS LANGUAGE can help to tie the two components together.

Although it is a lot of work, and mapping may seem to make it unnecessary,

corresponding elements in the objects and the relational tables should be na-

med meticulously the same and have the same associations. Subtle differences

in relationships will cause a lot of confusion. The tradition of refactoring that

has increasingly taken hold in the object world has not really affected relational

database design much. What’s more, serious data migration issues discourage

frequent change. This may create a drag on the refactoring of the object model,

but if the object model and the database model start to diverge, transparency can

be lost quickly. Domain-Driven Design Tackling Complexity in the Heart of

Software. Eric Evans

Assistant: Hace referencia a cualquier persona encargada de las prácticas de una o varias

asignaturas. No es necesario que sea un profesor, puesto que en muchas ocasiones son

los estudiantes de Doctorado los que se dedican a esta labor.

Base (Código de apoyo): Este término hace referencia al código que es necesario añadir

dentro de un entorno, para poder ejecutar el código de un alumno.

7

2 Glosario

Environment (Entorno): Conjunto de características que definen el contexto en el que se

va a ejecutar el código base junto con el código de un alumno.

From (Desde): Indica la fecha a partir de la cual un alumno puede comenzar a realizar en-

tregas.

Mark (Calificación): Nota que obtiene un alumno después de la ejecución de su entrega.

Max Mark (Calificación Máxima): Se establece a la hora de crear una práctica y se corres-

ponde a la máxima calificación que puede obtener un alumno al entregar dicha práctica.

Group (Grupo): Correspondiente al conjunto de alumnos que realizan una práctica y que

pueden efectuar entregas sobre ella.

Member (Miembro): Participación de un alumno dentro de un grupo.

Project (Práctica): Proyecto software de código a realizar dentro de una asignatura.

Registration number (Número de matrícula): Identificador propio de un alumno dentro

de una organización.

Step (Paso): Instrucción a ejecutar dentro de un entorno correspondiente a una entrega.

Subject (Asignatura): Permite agrupar tanto a los alumnos como a los proyectos para una

mejor gestión de los mismos.

Submission (Entrega): Acción del sistema donde el estudiante entrega su código de la prác-

tica en un momento específico.

To (Hasta): Indica la fecha a partir de la cual un alumno no puede realizar más entregas.

Note: Comentarios que un profesor realiza dentro de un grupo.

Mandatory (Requerido): Término dentro de una práctica que establece como necesario el

éxito de un paso para ejecutar el siguiente.

Regex (Project): Expresión regular encargada de buscar en la salida de un paso dos ente-

ros, que deberán devolver los tests exitosos de los alumnos y el numero total de tests

respectivamente.

8

3Modelización del sistema

En este capítulo se presentan dos modelos del sistema: un modelo de datos (incluye el

modelo conceptual y el modelo lógico) y un modelo dinámico que captura las interacciones

esperadas de los usuarios con el sistema.

Para la realización de una aplicación de esta envergadura se requiere diseñar un modelo de

datos el cual englobe a todas los individuos que puedan realizar acciones sobre este sistema

y todas las acciones que se pueden llevar en el sistema. Estableceremos cómo se relacionan

entre ellas y cuales son su propiedades. Antes de empezar el capítulo quiero advertir al lector

que he decido emplear los términos del glosario del capítulo 2.

3.1 Modelo de datos

Una parte muy importante de cualquier sistema o aplicación son los datos que utiliza para

sustentarla. El diseño del modelo de datos pasa por tres fases distintas. En un primer momento

se lleva acabo un modelo conceptual de la aplicación en el cual mediante el uso de la palabra,

se identifican las relaciones de más alto nivel entre las diferentes entidades, incluyendo las

entidades importantes y las relaciones entre ellas, se hace sin especificar ningún atributo y

tampoco se especifica ninguna clave principal. Posteriormente se describe un modelo lógico

el cual contiene representaciones de entidades y atributos, relaciones, identificadores exclu-

sivos, subtipos y supertipos y restricciones entre relaciones. Por ultimo quedaría el modelo

9

3 Modelización del sistema

físico, en nuestro caso no es necesario ya que disponemos de la tecnología necesaria, que

describiremos más adelante para pasar automáticamente del modelo lógico al modelo físico.

3.1.1 Modelo Conceptual

Como se ha mencionado anteriormente, el sistema pretende agrupar en una única aplica-

ción todas las acciones que tengan que realizar tanto los estudiantes como los profesores, por

lo que desde un primer momento vemos dos claras entidades que van a componer el sistema.

Como el propio título de este trabajo indica, es un sistema que permitirá la entrega de

prácticas, por lo que claramente debemos añadir una entidad práctica encargada de almace-

nar toda la información necesaria para la ejecución de una práctica tanto por parte del alumno

como por parte del sistema a la hora de realizar la entrega. Como el sistema tiene que alma-

cenar todas las entregas que realiza un alumno hemos de crear también una entidad entrega,

la cual almacene lo entregado por el alumno. Esta entidad ha de llevar un registro de cuando

se ha realizado esa entrega, también hay que guardar cuál es el contenido entregado por el

alumnos, y por ultimo, hay que guardar cual ha sido el resultado de dicha entrega.

Como las prácticas no tienen porque ser individuales nace otra entidad que formará parte

del sistema, la cual llamaremos grupo. Un grupo estará formado de uno a N alumnos y un

grupo será el que se una a una práctica y el que realice entregas en esa práctica. Cómo está

establecido que el grupo será el que realice entregas sobre una práctica, toda la información

necesaria para el control de ese grupos, ha de residir sobre la práctica.

Uno de los requisitos principales es que el sistema pueda ser utilizado por múltiples asig-

naturas, por lo que necesitamos añadir otra entidad que será asignatura. La entidad asignatura

nos servirá para poder agrupar las prácticas y facilitará tanto a los alumnos como los profe-

sores la creación y entrega de dichas prácticas.

Siguiendo con el análisis del sistema, las prácticas se ejecutan en entornos. Esos entornos

serán compartidos por las practicas y por lo tanto actuarán de base para las prácticas.

Modelo Entidad Relación

El modelo entidad relación [5] es una herramienta que permite representar de manera

simplificada los componentes que participan en un proceso de negocio y el modo en el que

estos se relacionan entre sí. El modelo entidad relación tiene tres elementos principales:

Entidades: El modelo contará con una entidad por cada uno de los componentes del

proceso de negocio

10

3.1 Modelo de datos

Atributos: Los atributos, componente fundamental de cada modelo entidad-relación,

nos permiten describir las propiedades que tiene cada entidad.

Relaciones: Con las relaciones se establecen vínculos entre parejas de entidades.

Gracias al diagrama entidad relación, podemos representar el modelo con el siguiente dia-

grama. Para una mayor simplicidad del mismo se decidió extraer los atributos de las entidades

fuera del diagrama y serán descritos en la sección modelo lógico y físico en Ecto.

*

*

*

*

1..n

*

*

1

*

1

*

1

*

1Assistant

Subject

Student

Group

Project

Submission

EnvironmentTeach

Enrolled

Member

Has

Send

On

Runs

Figura 3.1: Diagrama entidad relación

3.1.2 Modelo lógico y físico en Ecto

Como se ha comentado en capítulos anteriores vamos a hacer uso del lenguaje Elixir para

el desarrollo de esta aplicación. Elixir cuenta con una librería muy potente para la interacción

con las bases de datos, esa librería es Ecto [13]. Ecto permite trabajar en todo momento con

el modelo lógico abstrayéndonos del sistema gestor de bases de datos que se encuentre por

debajo.

11


Gracias a que Ecto trabaja directamente con el modelo lógico vamos a utilizarlo para

ilustrar el modelo lógico de nuestra aplicación. Creemos que a pesar de ser código, la me-

taprogramación usada en Ecto hace que las descripciones de los esquemas sean sencillas de

entender por cualquier profesional.

Schemas y Changesets

A la hora de describir el modelo lógico, Ecto nos permite introducir construcciones lla-

madas esquemas (schemas). Cada esquema acabará siendo una tabla del modelo físico pero

el nivel de descripción es más elevado. En particular, cada esquema, además del nombre,

describe atributos (field) y relaciones del modelo conceptual (has_many, many_many and

belongs_to). Dichas construcciones y su parámetros permiten a Ecto, además, regalarnos

código de comprobaciones de consistencia y precarga de las entidades relacionadas.

La construcción changeset en Ecto permite construir o modificar entidades del nivel lógi-

co con comprobaciones que anticipan posibles errores en la base de datos. Se usan además,

para hacer conversiones de datos del exterior: por ejemplo, permiten introducir un entero en

la base de datos a pesar de que en origen fuera una cadena de caracteres.

Subject

Como se puede observar en el diagrama entidad relación de la Figura 3.1, la asignatura

es el nexo de unión entre los profesores y los estudiantes. Gracias a la entidad asignatura po-

demos agrupar las prácticas por asignatura y facilitar la navegabilidad de los usuarios dentro

del sistema. La entidad asignatura nos permite que el sistema puede ser utilizado a nivel de

universidad. Los campos que almacenaremos serán: el nombre de la asignatura, un flag que

nos permita activar y desactivar dicha asignatura y por último un código que la identificará

internamente.

1 defmodule Database.Subjects.Subject do

2 use TypedEctoSchema

3 import Ecto.Changeset

4

5 @primary_key {:id, :binary_id}

6 @foreign_key_type :binary_id

7 typed_schema "subjects" do

8 field(:code, :string)

9 field(:name, :string)

10 field(:active, :boolean, default: true)

11

12

3.1 Modelo de datos

12 # Extra data

13 timestamps()

14

15 # References

16 has_many(:projects, Database.Subjects.Project, foreign_key: :subject_id

, references: :id)

17 many_to_many(:students, Database.Students.Student, join_through:

Database.Students.Enrolled)

18 many_to_many(:assistants, Database.Assistants.Assistant, join_through:

Database.Assistants.Teach)

19 end

20

21 @doc false

22 def changeset(subject, attrs) do

23 subject

24 |> cast(attrs, [:id, :code, :name, :active])

25 |> validate_required([:name, :code])

26 |> unique_constraint(:id, name: :subjects_pkey)

27 |> unique_constraint(:code)

28 end

29 end

Assistant

Los profesores son uno de los grandes grupos que van a interactuar con el sistema, son

una entidad tan grande que tienen su propio portal para realizar todas sus actividades. Los

campos que componen a un profesor son: Su nombre completo, un identificador único para

el profesor (Se utilizará para iniciar sesión), y una contraseña. A parte de estos campos,

utilizaremos otros para controlar tanto lo cambios de esa entidad como los accesos al sistema

de esa entidad.

1 defmodule Database.Assistants.Assistant do



4

5 @primary_key {:id, :binary_id}


7 typed_schema "assistants" do

8 field(:username, :string)

9 field(:email, :string)

13


10

11 field(:first_name, :string)

12 field(:last_name, :string)

13 field(:password, :string)

14

15 # Security

16 field(:last_login, :naive_datetime)

17 field(:last_login_ip, :string)

18

19 # Relations

20 many_to_many(:subjects, Database.Subjects.Subject, join_through:

Database.Assistants.Teach)

21

22 timestamps()

23 end

24

25 @doc false

26 def changeset(assistant, attrs) do

27 assistant

28 |> cast(attrs, [

29 :id, :username, :email, :first_name,

30 :last_name, :password, :last_login, :last_login_ip

31 ])

32 |> validate_required([

33 :username, :email, :first_name,

34 :last_name, :password, :last_login, :last_login_ip

35 ])

36 |> unique_constraint(:id, name: :assistants_pkey)

37 |> unique_constraint(:username)

38 |> unique_constraint(:email)

39 end

40 end

Teach

Se encarga de almacenar la relación que existe entre los profesores y las asignaturas, ya

que un profesor puede enseñar varias asignaturas y una asignatura puede ser enseñada por

varios profesores.

1 defmodule Database.Assistants.Teach do

14

3.1 Modelo de datos



4

5 @primary_key false

6 typed_schema "teach" do

7 belongs_to(:assistant, Database.Assistants.Assistant, type: :

binary_id, primary_key: true)

8 belongs_to(:subject, Database.Subjects.Subject, type: :binary_id,

primary_key: true)

9 end

10

11 @doc false

12 def changeset(teach, attrs) do

13 teach

14 |> cast(attrs, [:assistant_id, :subject_id])

15 |> validate_required([:assistant_id, :subject_id])

16 |> unique_constraint(:assistant_id, name: :

teach_assistant_id_subject_id_index)

17 end

18 end

Student

Otro de los principales grupos que van a hacer uso de nuestro sistema son los estudiantes,

son una entidad tan grande que también tienen su propio portal para realizar todas sus activi-

dades. Los campos que compone a un estudiante son: Su nombre completo, un identificador

único para el alumno (Se utilizara para iniciar sesión), una contraseña y un correo (se utilizará

para comunicarle el resultado de las acciones importantes). A parte de estos campos, utiliza-

remos otros para controlar tanto los cambios de esa entidad como los accesos al sistema de la

misma.

1 defmodule Database.Students.Student do



4

5 @primary_key {:id, :binary_id, autogenerate: true}


7 typed_schema "students" do

8 field(:id_number, :string)

9 field(:registration_number, :string)

15


10 field(:email, :string)

11 field(:first_name, :string)

12 field(:last_name, :string)

13 field(:password, :string)

14 field(:active, :boolean, default: true)

15 field(:avatar, :string)

16

17 # Security

18 field(:last_login, :naive_datetime)

19 field(:last_login_ip, :string)

20

21 # Extra data

22 timestamps()

23

24 # References

25 many_to_many(:subjects, Database.Subjects.Subject, join_through:

Database.Students.Enrolled)

26 many_to_many(:groups, Database.Students.Group, join_through: Database

.Students.Member)

27 end

28

29 @doc false

30 def changeset(student, attrs) do

31 student

32 |> cast(attrs, [

33 :id, :id_number, :registration_number, :email, :first_name,

34 :last_name, :password, :active, :avatar, :last_login, :

last_login_ip

35 ])


37 :id_number, :registration_number, :email,

38 :first_name, :last_name, :password

39 ])

40 |> unique_constraint(:id, name: :students_pkey)

41 |> unique_constraint(:id_number)

42 |> unique_constraint(:registration_number)

43 |> unique_constraint(:email)

44 end

45 end

16

3.1 Modelo de datos

Enrolled

Se encarga de almacenar la relación que existe entre los alumnos y las asignaturas, ya

que un alumno puede participar en varias asignaturas y una asignatura puede incluir varios

alumnos.

1 defmodule Database.Students.Enrolled do



4


6 typed_schema "enrolled" do

7 belongs_to(:student, Database.Students.Student, type: :binary_id,

primary_key: true)

8 belongs_to(:subject, Database.Subjects.Subject, type: :binary_id,

primary_key: true)

9 end

10

11 @doc false

12 def changeset(enrolled, attrs) do

13 enrolled

14 |> cast(attrs, [:student_id, :subject_id])

15 |> validate_required([:student_id, :subject_id])

16 |> unique_constraint(:student_id, name: :

enrolled_student_id_subject_id_index)

17 end

18 end

Environment

Como uno de los puntos fuertes de nuestro sistema es la ejecución en entornos indepen-

dientes, necesitamos guardar referencias a los entornos Docker que se han construido. Los

entornos Docker pueden venir de tres fuentes distintas: una imagen Docker desde un registry

[8] de Docker, desde un respositorio git que contenga un Dockerfile [9] en el primer nivel o

desde un fichero comprimido en formato tar que cumpla la misma condición que el reposito-

rio git. A parte del tipo, mencionado anteriormente, también se guarda un nombre, la salida

de la creación del entorno, el estado en el que se encuentra y el identificador de la imagen

Docker resultado.

1 defmodule Database.Tools.Environment do


17



4


6 typed_schema "environments" do

7 field(:id, :binary_id, primary_key: true)

8 field(:name, :string, null: false)

9 field(:type, Database.Custom.Atom, null: false)

10 field(:data, :string, null: false)

11 field(:status, Database.Custom.Atom, null: false, default: :

in_progress)

12 field(:output, :string, null: false)

13 field(:image, :string)

14

15 timestamps()

16

17 # References

18 has_many(:projects, Database.Subjects.Project, references: :id)

19 end

20

21 @doc false

22 def changeset(project, attrs) do

23 project

24 |> cast(attrs, [

25 :id, :name, :type, :data,

26 :status, :output, :image

27 ])


29 :id, :name, :type, :status

30 ])

31 |> unique_constraint(:name)

32 |> validate_inclusion(:type, types())

33 end

34

35 def types, do: [:file, :registry, :git]

36 end

18

3.1 Modelo de datos

Project

Las practicas son el núcleo principal de la aplicación por lo que tienen su propia entidad.

Las prácticas pertenecen a una asignatura y guardan información sobre: El entorno sobre le

que van a ejecutar, el limite tanto superior como inferior de estudiantes por grupos, la nota

máxima, el nombre y la ruta de todos los ficheros que tiene que entregar un alumno, los

comandos a ejecutar dentro del entorno, el rango de fechas en los cuales estará disponible

para entregar como el número máximo de entregas y el identificador a la imagen de Docker

que contiene el entorno junto al código del profesor.

1 defmodule Database.Subjects.Project do



4


6 typed_schema "projects" do


8 field(:name, :string, null: false)

9 field(:mark, :decimal, null: false)

10 field(:files, {:array, {:map, :string}}, null: false)

11

12 # Docker Options

13 field(:image, :string)

14 belongs_to(:environment, Database.Tools.Environment, type: :binary_id

)

15 field(:steps, {:array, Database.Custom.Step}, default: [])

16

17 # Control

18 field(:min_students, :integer, default: 1)

19 field(:max_students, :integer, default: 1)

20 field(:max_submisions, :integer, default: nil)

21 field(:from, :naive_datetime, null: false)

22 field(:to, :naive_datetime, null: false)

23 field(:active, :boolean, default: false)

24

25 # Extra data

26 timestamps()

27

28 # References

29 belongs_to(:subject, Database.Subjects.Subject, type: :binary_id)

30 has_many(:groups, Database.Students.Group, references: :id)

19


31 end

32

33 @doc false

34 def changeset(project, attrs) do

35 project

36 |> cast(attrs, [

37 :id, :name, :mark, :files, :image, :environment_id,

38 :min_students, :max_students, :max_submisions, :from,

39 :to, :active, :subject_id, :steps

40 ])


42 :id, :name, :mark, :files,

43 :from, :to, :subject_id, :steps

44 ])

45 end

46

47 @spec status(project :: t()) :: :open | :closed | :inactive

48 def status(project) do

49 now = NaiveDateTime.utc_now()

50

51 cond do

52 project.active == false ->

53 :inactive

54

55 NaiveDateTime.diff(project.from, now) < 0 and NaiveDateTime.diff(

project.to, now) > 0 ->

56 :open

57

58 true ->

59 :closed

60 end

61 end

62 end

Group

Como se ha mencionado anteriormente, las prácticas las realizan grupos comprendidos

entre uno y N usuarios por lo tanto necesitamos almacenar esa relación entre todos los usua-

rios que forman un grupo y una práctica. También almacenaremos la última nota que ha

20

3.1 Modelo de datos

obtenido el grupo junto un campo para almacenar anotaciones realizadas por el profesor.

1 defmodule Database.Students.Group do



4


6 typed_schema "groups" do


8 field(:mark, :decimal, default: Decimal.new(0))

9 field(:note, :string)

10

11 timestamps()

12

13 # References

14 belongs_to(:project, Database.Subjects.Project, type: :binary_id)

15 many_to_many(:students, Database.Students.Student, join_through:

Database.Students.Member)

16 has_many(:submissions, Database.Subjects.Submission, references: :id)

17

18 # Virtual fields

19 field(:name, :string, virtual: true)

20 end

21

22 @doc false

23 def changeset(student, attrs) do

24 student

25 |> cast(attrs, [

26 :id,

27 :project_id,

28 :mark,

29 :note

30 ])

31 |> validate_required([:id, :project_id])

32 |> unique_constraint(:id, name: :groups_pkey)

33 end

34

35 def name(group) do

36 case group.name do

37 nil ->

38 group.students

21


39 |> Enum.sort()

40 |> Enum.map(fn st -> st.registration_number end)

41 |> Enum.join("+")

42

43 name ->

44 name

45 end

46 end

47 end

Member

Se encarga de almacenar la relación que existe entre los alumnos y los grupos, ya que un

alumno puede ser miembro de varios grupos y un grupo puede incluir varios alumnos.

1 defmodule Database.Students.Member do



4


6 typed_schema "members" do

7 belongs_to(:student, Database.Students.Student, type: :binary_id,

primary_key: true)

8 belongs_to(:group, Database.Students.Group, type: :binary_id,

primary_key: true)

9 end

10

11 @doc false

12 def changeset(enrolled, attrs) do

13 enrolled

14 |> cast(attrs, [:student_id, :group_id])

15 |> validate_required([:student_id, :group_id])

16 |> unique_constraint(:student_id, name: :members_pkey)

17 end

18 end

22

3.1 Modelo de datos

Submission

Las entrega la realizan los grupos, de esta manera cualquier miembro del grupo puede

realizar una entrega y ver el resultado de la misma sin necesidad de compartir las credenciales

con el resto de miembros del grupo que ha realizado dicha entrega. Una entrega por lo tanto

contiene el resultado en forma de nota de dicha entrega, una referencia a la práctica y al grupo

que la ha realizado y fuera del modelo de datos almacena la salida estándar de la ejecución

de los pasos que componen esa práctica.

1 defmodule Database.Subjects.Submission do



4


6 typed_schema "submissions" do


8 field(:mark, :decimal)

9 # Extra data

10 timestamps()

11 # References

12 belongs_to(:project, Database.Subjects.Project, type: :binary_id)

13 belongs_to(:group, Database.Students.Group, type: :binary_id)

14 end

15

16 @doc false

17 def changeset(submission, attrs) do

18 submission

19 |> cast(attrs, [

20 :id,

21 :mark,

22 :project_id,

23 :group_id

24 ])


26 :id,

27 :project_id,

28 :group_id

29 ])

30 end

31 end

23


3.2 Modelo de interacción

El sistema está compuesto por tres aplicaciones distintas, una para que los alumnos reali-

cen toda su actividad, otra para que los profesores puedan llevar a cabo su labor dentro del

sistema y por último un panel de administración global. Cada sistema puede realizar unas ac-

tividades concretas con unos flujos que permitan al usuario realizarlos con la mayor facilidad

posible.

3.2.1 Acciones alumnos

Las acciones que puede realizar un alumno quedan reflejadas en la Figura 3.2 y son limi-

tadas dentro del sistema, debido a que el alumno es dado de alta directamente por el profesor

y es añadido directamente dentro de las asignaturas a las que pertenece. Por otro lado un

alumno es unicamente capaz de crear grupos dentro de las prácticas de una asignatura, es

capaz de realizar entregas dentro de esas prácticas, y también puede ver los resultados de las

entregas que han realizado todos los miembros de los grupos de los que es miembro.

Para poder realizar las acciones anteriormente descritas el usuario tiene que ser capaz de

poder iniciar sesión dentro del sistema y además ser capaz de editar ciertos campos desde su

perfil, como por ejemplo la contraseña.

El alumno en ningún momento puede irse de un grupo, ni tampoco puede irse de una

asignatura. Todas las acciones las tiene que hacer o bien un administrador o bien un profesor

ligado a esa asignatura.

3.2.2 Acciones profesores

Los profesores tienen su propia aplicación en la cual se tienen que autenticar con su propio

usuario al igual que los alumnos y tiene la posibilidad de editar algunos campos de su perfil,

como es la contraseña.

Los profesores tienen dos grandes funciones dentro del sistemas. Una de ellas es la de

administrar los alumnos (Figura 3.3) de las asignaturas de las que son profesores. El profesor,

mediante un archivo debidamente formateado, es capaz de dar de alta los alumnos que falten

dentro del sistema y posteriormente los añade a la asignatura.

Otra de las labores que realiza el profesor (Figura 3.4) pasa por la creación, edición y

eliminación de prácticas. Para poder facilitar dicha tarea, el profesor tiene la opción de du-

plicar la estructura de una práctica ya existente independientemente de la asignatura a la que

pertenezca siempre que el profesor participe en ambas asignatura.

24


� Login Home

Creación de grupo

Perfillogout

Prática Nueva Entrega

Resultado de la entrega

Figura 3.2: Modelo de interacción para alumnos

� Login Home

Perfillogout

Asignatura

Prácticas

(Figura 3.4)Dar de alta alumnos

Dar de baja alumnos

Figura 3.3: Modelo de interacción para profesores (i)

25


Dentro de las prácticas, se le permite dar de alta a grupos de alumnos, exportar las notas

de esa practica a nivel de alumnos, de tal manera que se pueda unir fácilmente a cualquier

base de datos externa de la asignatura, también se le permite exportar el código final de todos

los grupos.

A parte de poder interactuar con los grupos, también puede interactuar de manera indivi-

dual con las entregas que se han realizado: puede exportar una entrega en concreto, las puede

volver a mandar a la cola de ejecución y por último la puede eliminar.

Como el entorno de ejecución de Deliverit puede diferir con el usado por el profesor para

el desarrollo del corrector, se ha añadido una opción para que el profesor pueda ejecutar el

corrector sin necesidad de darse de alta en el portal de alumnos.

� Prácticas

Dar de alta práctica

Práctica

eliminar

Grupo Dar de alta un grupo

Exportar códigos

Exportar grupos

Duplicar

Entregas Ejecutar

Exportar

Eliminar

ComprobarEditar práctica

Figura 3.4: Modelo de interacción para profesores (ii)

3.2.3 Acciones administradores

A parte de los profesores y los alumnos se plantea un tercer grupo de personas que pueden

realizar acciones dentro del sistema y que no se ve representada su existencia en la base

26


� Entornos

Dar de alta entorno

Entorno

eliminar

Editar entorno

Reconstruir

Figura 3.5: Modelo de interacción para administradores (i)

de datos, debido a que el número de personas de este grupo es limitado y por esa razón,

su autenticación se puede hacer mediante BasicAuth directamente sobre el Gateway. Como

administradores que son, las acciones que pueden realizar se dividen en 4 grandes grupos.

Un primer grupo de acciones, engloba todas las relacionadas con los entonos (Figura

3.5). Los entornos son imágenes de Docker preparados para ejecutar prácticas sobre ellos a

la falta de añadirle el código que utilice el profesor para comprobar el código del alumno,

y del código que entregue el alumno. Como ya se ha comentado, un entorno puede venir de

tres fuentes distintas y puede reconstruirse en cualquier momento desde este panel.

Un segundo grupo de acciones están relacionadas con los alumnos (Figura 3.6). Los pro-

fesores solo pueden controlar aquellos alumnos que se encuentren dentro de una asignatura

en la impartan clase, por eso a los administradores se les da la posibilidad de visualizar todos

los alumnos, también se les permite editarlos y eliminarlos en cualquier momento. A parte de

añadir un alumnos cada vez, se ha habilitado la opción de cargarlos masivamente. La carga

masiva de alumnos es idéntica a la que disponen los profesores pero con una pequeña dife-

rencia, se les da la opción de añadir dentro del fichero una linea que indique la asignatura en

la que se quiere añadir a todos esos alumnos.

Un tercer grupo de acciones está relacionado con el control de las asignaturas (Figura 3.7).

El administrador puede dar tanto de alta como de baja asignaturas dentro del sistema. Como

se ha comentado en las acciones del panel de profesores, ellos ya están dados de alta dentro de

las asignaturas y por eso, es el administrador el que debe de llevar acabo esa acción. También

tiene la posibilidad de añadir alumnos ya existente a una asignatura de manera grupal.

Por último, un cuarto grupo de acciones relacionadas con el tema principal de este trabajo,

las prácticas (Figura 3.8). Al igual que los profesores, un administrador puede realizar la

27


� Alumnos

Dar de alta alumno

Bulk de alumnos

Alumno

eliminar

Editar alumnos

Figura 3.6: Modelo de interacción para administradores (ii)

� Asignaturas

Dar de alta asignatura

Asignatura

eliminar

Editar asignatura

Bulk de alumnos

Figura 3.7: Modelo de interacción para administradores (iii)

28


� Prácticas

Dar de alta práctica

Práctica

eliminar

Groupo Dar de alta un grupo

Exportar codigos

Exportar grupos

Duplicar

Entregas Ejecutar

Exportar

Eliminar

ComprobarEditar práctica

Figura 3.8: Modelo de interacción para administradores (iv)

creación, edición y eliminación de prácticas, para poder facilitar dicha tarea, el profesor tiene

la opción de duplicar la estructura de una práctica ya existente independientemente de la

asignatura a la que pertenezca siempre que el profesor participe en esa asignatura.

Dentro de las prácticas, se le permite dar de alta grupos de alumnos, exportar las notas de

esa practica a nivel de alumnos, de tal manera que se pueda unir fácilmente a cualquier base

de datos externa de la asignatura, también se le permite exportar el código final de todos los

grupos.

A parte de poder interactuar con los grupos, también puede interactuar de manera indivi-

dual con las entregas que se han realizado: puede exportar una entrega en concreto, las puede

volver a mandar a la cola de ejecución y por último la puede eliminar.

Como el entorno de ejecución de Deliverit puede diferir con el usado por el administrador

para el desarrollo del corrector, se ha implementado una opción para que el administrador

pueda ejecutar el corrector sin necesidad de darse de alta en el portal de alumnos.

29


30

4Arquitectura

En este capítulo voy a presentar la arquitectura del sistema. La siguiente tabla muestra los

componentes que hemos identificado y con los que vamos a trabajar a lo largo del capítulo:

Aplicaciones Web






Nivel de acceso a datos (database)Entornos y comprobaciones

(dockerex)

31

4 Arquitectura

Como muestra la figura anterior, hemos estructurado la arquitectura en tres niveles: apli-

caciones web, lógica del sistema, y persistencia y comprobaciones. Analizamos cada nivel en

una sección.

4.1 Aplicaciones Web

Aplicaciones Web



Para aislar las funcionalidades de cada tipo de usuario (alumnos, profesores y adminis-

tradores) hemos decidido crear tres aplicaciones Web. Para ofrecer una uniformidad en el

interfaz de usuario se ha diseñado un subsistema que ofrece componentes de la interfaz para

que sean usados en todos los front-ends de las aplicaciones.

Las aplicaciones Web han sido implementadas utilizando el framework Phoenix en el

lenguaje de programación Elixir. Ya hemos hablado en el capítulo 1 tanto de Phoenix como

de Elixir. Aunque entraremos en detalles en el capítulo 5, los nombres de las aplicaciones y

del componente con componentes de front-end son:

client. Aplicación web de estudiantes sin artefactos puros de front-end (CSS [11] o Javas-

cript [12]).

assistant. Aplicación Web de profesores sin artefactos puros de front-end (CSS o Javas-

cript).

admin. Cuadro de mando para administración del sistema sin artefactos puros de front-end(CSS o Javascript).

components. Exposición de componentes de interfaz de usuario usados en todos los front-ends de las aplicaciones anteriores. Incluye código HTML [11] común, CSS y Javas-

cript y no tiene artefactos puros de back-end (como controladores con lógica del siste-

ma).

32

4.2 Lógica de la aplicación

4.2 Lógica de la aplicación



Toda la lógica del sistema se ha encapsulado en este componente. Cada módulo en dicho

componente se encarga de un contexto de la aplicación, desde los alumnos hasta las entregas

pasando por asignaturas o prácticas.

El componente es una aplicación Elixir con supervisores y construcciones OTP que per-

miten controlar la escalabilidad del sistema de forma sencilla.

4.3 Persistencia


Nivel de acceso a datos (database)

Como hemos visto en el capítulo 3, nuestro model lógico de datos está directamente

basado en Ecto (sección 3.1.2). Este componente es un nivel que aísla la lógica del sistema

de Ecto, implementando funciones agrupadas por contextos, que hablan el idioma de esa

lógica. Es un data access layer clásico. Nuestra convención es no realizar llamadas directas

a Ecto desde los niveles superiores.

33

4 Arquitectura

4.4 Comprobación de entregas


Entornos y comprobaciones

(dockerex)

Finalmente, nuestro último componente es el que nos permite ejecutar comprobaciones de

forma segura sobre el código entregado por los alumnos. Todo el código de los estudiantes, y

también el código de los profesores, se ejecutarán en contenedores Docker (ya hemos hablado

de esto en el capítulo 1). Para ello, he desarrollado una biblioteca en Elixir que es capaz de

manejar las construcciones de Docker (imágenes, contenedores, volúmenes, etc.).

4.5 Diagrama de componentes

Terminamos el capítulo con un diagrama UML de componentes en el que el lector puede

ver que las interacciones entre los componentes son llamadas de bibliotecas y aplicaciones

de Elixir. Se puede ver dicho diagrama en la figura 4.1.

4.6 Sobre Elixir

Elixir es un lenguaje dinámico y funcional diseñado para crear aplicaciones escalables y

mantenibles. Elixir aprovecha la máquina virtual Erlang, conocida por ejecutar sistemas de

baja latencia, distribuidos y tolerantes a fallos, a la vez que se utiliza con éxito en el desarrollo

Web y el dominio de software integrado. Todo el código de Elixir se ejecuta dentro de hilos

de ejecución livianos (llamados procesos) que están aislados e intercambian información

a través de mensajes. Debido a su naturaleza liviana, no es raro tener cientos de miles de

procesos ejecutándose simultáneamente en la misma máquina. El aislamiento permite que

los procesos se recojan de forma independiente, reduciendo las pausas en todo el sistema y

utilizando todos los recursos de la máquina de la manera más eficiente posible.

La verdad inevitable sobre el software que se ejecuta en producción es que si las cosas

pueden salir mal, saldrán mal. Aún más cuando tenemos en cuenta la red, los sistemas de

archivos y otros recursos de terceros. La combinación de escalabilidad, tolerancia a fallos

34

4.6 Sobre Elixir

Deliverit

databasedatabase

logiclogic

clientclient

adminadmin

assistansassistans

componentscomponents DockerExDockerEx

Lib

Lib

Lib

Lib

Lib

Lib

Lib

Lib

Figura 4.1: Diagrama de componentes

y programación basada en eventos a través del envío de mensajes hace que Elixir sea una

excelente opción para Programación Reactiva y Arquitecturas.

Gracias a Elixir podemos crear una arquitectura que soporte múltiples clientes realizando

múltiples operaciones, desde profesores dando de alta prácticas, como a alumnos haciendo

entregas de esas prácticas de manera concurrente.

Aplicaciones de gran envergadura están compuestas por varios clientes junto con librerías

a las que dan soporte para evitar el código duplicado entre clientes. Para hacer mucho más

sencillo el desarrollo, se requiere agrupar aplicaciones distintas dentro de un mismo proyecto.

Esto ayudará al desarrollador a olvidarse de actualizar la versión de las librerías implemen-

tadas en cada uno de los clientes debido a que se actualizan automáticamente. Elixir cuenta

con tecnología dentro del lenguaje que permite realizar todo lo listado anteriormente. Esa

tecnología se llama Umbrella y nos permite separar nuestro código en varias aplicaciones y

hacer que nuestros proyectos de Elixir sean más manejables a medida que van creciendo

35

4 Arquitectura

4.6.1 Phoenix

Como hemos comentado al inicio de este capitulo, Elixir está preparado para levantar

cientos de miles de procesos ligeros, que en nuestro caso serán hilos escuchando peticiones

HTTP. Como Elixir no es de propósito especifico para Web, es necesario hacer uso de algu-

na librería que aproveche toda la potencia del lenguaje y además sea sencillo de aprender y

programar evitando la duplicidad de código. En este caso nos hemos decantado por Phoenix.

Phoenix es un framework de desarrollo Web escrito en Elixir, patrón MVC [18]. Muchos de

sus componentes y conceptos se parecen al de otros framework como Ruby on Rails o Djan-

go. Phoenix ofrece lo mejor de ambos mundos - alta productividad en ámbitos de desarrollo y

un alto rendimiento de la aplicación. Basado en la biblioteca Plug y, en última instancia, en el

marco Cowboy Erlang. Se desarrolló para proporcionar aplicaciones Web altamente escala-

bles y de alto rendimiento. Además de la funcionalidad de solicitud / respuesta proporcionada

por el servidor Cowboy subyacente, Phoenix proporciona comunicación suave en tiempo real

a clientes externos a través de WebSockets o sondeos largos utilizando su función de canales

independientes del idioma.

4.6.2 Contenedores

Necesitamos también encontrar una tecnología que nos permita ejecutar todas las prác-

ticas en un entorno estanco en el que cualquier intento por parte del alumno por acceder a

la máquina quede imposibilitado. También necesitamos un sistema escalable y portable. Una

tecnología que cumple esta función es la de los contenedores. Los contenedores ofrecen un

modo estándar de empaquetar el código, las configuraciones y las dependencias de su apli-

cación en un único objeto. Los contenedores comparten un sistema operativo instalado en

el servidor, y se ejecutan como procesos aislados de los recursos, lo que garantiza imple-

mentaciones rápidas, fiables y consistentes sea cual sea el entorno en el que se realizan. Los

contenedores empaquetan su código junto a los archivos de configuración y las dependencias

que necesita para que se ejecute de forma coherente en cualquier entorno. Los contenedores

permiten aislar procesos, lo que le permite ajustar con detalle el uso de CPU y de memoria

para aprovechar mejor el uso de recursos informáticos. Cada contenedor se ejecuta como un

proceso separado que comparte los recursos del sistema operativo subyacente. Esto permite

que los contenedores se puedan arrancar y detener con rapidez.

36

5

Implementación

Después del diseño y elección de las diferentes tecnologías a utilizar en el desarrollo

de este proyecto tenemos que establecer todos los estándares que vamos a seguir durante el

desarrollo. Estos estándares no solo me van a ayudar a mí como primer desarrollador de este

trabajo, si no que ayudaran a los alumnos que continúen con él mismo.

5.1 Aplicación Umbrella

Todo el núcleo principal se encuentra bajo una aplicación umbrella de Elixir, por lo que

dentro de ella residen casi todos los proyectos. La Figura 5.1 muestra la estructura de ficheros

del núcleo de la aplicación.

37

5 Implementación

core

apps

admin

assistans

client

components

database

logic

config

config.exs

dev.exs

prod.exs

test.exs

mix.exs

mix.lock

rel

config.exs

plugins

vm.args

Figura 5.1: Estructura de directorios

Un primer directorio llamado apps en el que encuentran todas las aplicaciones y librerías

que componen el sistema. Un segundo directorio llamado config que almacena todas las

configuraciones, cabe destacar que las configuraciones están dividas por entorno: dev.exs,

prod.exs y test.exs, y una configuración global a todos los entornos config.exs. Estos

archivos de configuración son comunes a todas las aplicaciones que cuelgan del proyecto

umbrella. También existen dos ficheros mix.exs y mix.lock los cuales contienen las depen-

dencias globales y las versiones que se están ejecutando en ese momento respectivamente.

Por último, hay un directorio rel que contiene todos los archivos requeridos para poder sacar

una release de la aplicación. Una release es una version del código ensamblada, se puede

empaquetar e implementar en un destino, siempre que se ejecute en la misma distribución y

versión del sistema operativo (SO) que la máquina que ejecuta el comando de generación.

5.2 Aplicaciones Phoenix

Por otro lado, existen los proyectos Phoenix que tienen una estructura de directorios (Fi-

gura 5.2) un poco distinta a la anterior. En este caso, hay directorios y fichero comunes

(config, mix.exs y mix.lock) pero otros que son exclusivos tanto de la aplicación mas alta

38

5.2 Aplicaciones Phoenix

en el árbol de directorios (rel) o exclusivos de la aplicación umbrella (apps).

client (ejemplo de organización de aplicación Phoenixconfig

config.exs

dev.exs

prod.exs

test.exs

mix.exs

lib

client

application.ex

...

client.ex

client_web

channels

controllers.ex

controllers

login_controller.ex

...

endpoint.ex

router.ex

templates

login

index.html.eex

...

...

views

login_view

...

client_web.ex

Figura 5.2: Estructura de directorios (aplicación)

Como se trata de una aplicación normal de elixir, consta de una carpeta lib la cual va a

contener todo el código fuente. Como además de trata de un proyecto Phoenix, las carpetas se

dividen a su vez en dos, una para almacenar todo el código relacionado con la lógica de nego-

cio más las configuraciones de arranque del supervisor de la aplicación (application.ex), y

otra que va a almacenar todo lo relacionado con las vistas (que dentro de Phoenix se llaman

templates que se procesan con la ayuda de las views) y los controladores (controllers).

Los archivos que se crean dentro de esas carpetas, tiene que tener unos nombre muy espe-

39

5 Implementación

cíficos para que la aplicación funcione a la perfección. La convención de nombres es la que

sigue:

*_controller.ex: En este fichero está todo el código del controlador de la entidad a

la que se esté dando soporte.

*_view.ex: Contiene el código necesario para renderizar la vista, no suele ser necesario

añadir código en este solamente inicializar el módulo, con las funciones por defecto son

suficiente.

*/*.html.eex: Se encuentra la plantilla HTML (embedded Elixir) con la que se va a

renderizar la vista.

5.3 Aplicaciones y bibliotecas

En cuanto a las librerías, no hay ningún consenso en lo que es la organización dentro de

los directorios, por eso hemos decidido seguir lo establecido por gran parte de la comunidad

como se muestra la Figura 5.3.

40

5.4 Librería Docker

logic

config

...

mix.

lib

logic.ex

logic

application.ex

environments

build.ex

create.ex

update.ex

groups

...

projects

...

students

...

subjects

...

submissions

...

...

Figura 5.3: Estructura de directorios (bibliotecas)

Como se puede ver, hemos decidido, que cada módulo se vea representado con un archivo

.ex y si tiene submodulos, se creara una carpeta con el nombre del módule padre al mismo

nivel que el fichero que representa al módulo padre al igual que se puede ver con el modulo

logic, que tiene el archivo que define su modulo y la carpeta que almacena los módulos hijos.

Dentro de la carpeta logic, se han creado módulos vacíos con los mismos nombres de las

entidades, y dentro ellos está implementada la lógica para interactuar con ella, se le ha puesto

como nombre al modulo el de la acción que está realizando.


La librería de Docker es uno de los grandes puntos de esta aplicación y por eso esta im-

plementado como una libraría independiente. Para la realización del sistema no era necesario

41

5 Implementación

Imagenes

Listar imaginesVer una imagen

Crear una imagenConstruir un imagen

Borrar todas las imaginesBorrar una imagen

Figura 5.4: Acciones Docker sobre imágenes

implementar una integración completa con Docker para que funcione nuestro sistema, so-

lo hemos implementado una integración completa con las acciones para imágenes y con las

acciones para contenedores.

Las integración con imágenes (Figura 5.4) es necesaria para hacer funcionar los entornos

y para crear las imágenes cuando un profesor crea una práctica, y cuando un alumnos sube

su código para ser comprobado.

La otra integración que se ha realizado es para poder controlar los contenedores (Figura

5.5). Necesitábamos poder crear y poner en marcha un contenedor, también necesitamos

esperar a que el contenedor termine de ejecutar para saber cual ha sido su resultado, otra

acción importante es la de coger tanto la salida estándar como la salida de error del contenedor

para mostrársela al usuario. Para no bloquear el numero de slots disponibles para la entrega,

se ha añadido la opción de poder parar o llegar a matar un contenedor a partir de cierto tiempo

de utilización.

42


Contenedores

Poner contenido

de un contenedor

Crear un contenedor

Ver un contenedor

Logs de un contenedor

Arrancar un contenedor

Listar contenedores

Para un contenedor

Matar un contenedor

Borrar todos

los contenedoresBorrar una contenedor

Esperar a un contenedor

Obtener contenido

de un contenedor

Figura 5.5: Acciones Docker sobre contenedores

43

5 Implementación

44

6Metodología

En este capítulo voy a presentar ciertos aspectos sobre los métodos seguidos para el de-

sarrollo del proyecto. Esperamos que otros desarrolladores que se unan puedan usar las refe-

rencias como inspiración y ayuda,

6.1 Agilidad

Para el desarrollo de este trabajo, se instauraron prácticas y procedimientos inspirados

en marcos de implementación de metodologías ágiles, como Scrum [20] o Kanban [4]. Es-

tas surgen para dar respuesta al cambio de manera rápida y efectiva durante el desarrollo

de proyectos software [21]. Motivadas por la naturaleza evolutiva de las necesidades de los

proyectos, establecen estrategias para el desarrollo iterativo e incremental. La decisión para

adoptar estas técnicas venía motivada por diferentes factores.

Dueño del producto y equipo de desarrollo. Ángel Herranz, tutor del proyecto, cumpliría

con las funciones de dueño del producto. Entre estas cabe destacar que el dueño del producto

es la persona responsable de formalizar y transmitir al equipo de desarrollo las necesidades

del proyecto y sus prioridades. Como se ha comentado anteriormente, tanto unas como otras

pueden variar en cualquier momento.

45

6 Metodología

Por su parte, el autor de este trabajo constituiría el equipo de desarrollo. Su principal

responsabilidad es la de desarrollar el sistema. Para ello, también es necesaria su participación

en la concreción de las necesidades. El diálogo entre el equipo de desarrollo y el dueño del

producto debe ser continua y fluida para garantizar que las necesidades se entienden y se

pueden llevar a cabo.

Granularidad de las unidades de trabajo. Las necesidades del proyecto se empezaron a

descomponer en unidades de trabajo de una granularidad suficiente para ser abordadas du-

rante un único ciclo de desarrollo. Esto obligaba a traer a tierra las necesidades, que muchas

veces llegaban en términos demasiado generales o con muchos detalles pendientes de ser

definidos. Se estableció la siguiente clasificación para las necesidades del proyecto:

Épicas: Son las necesidades de más alto nivel del sistema. Por ejemplo, Librería enElixir para la integración con Docker.

Historias de usuario: Son funcionalidades más concretas, formuladas desde el punto

de vista de un usuario de la aplicación. Una épica puede englobar muchas historias de

usuario. Siguiendo con el ejemplo anterior, algunas de las historias de usuario derivadas

de la épica podrían ser: realizar las operaciones CRUD sobre los contenedores, o,

realizar las operaciones CRUD sobre las imagenes Docker.

Tareas: Son las unidades de trabajo mínimas que componen una historia de usuario.

Por ejemplo, implementar la creación de un contenedor, y, implementar la parada deun contenedor dado.

Errores: Utilizamos esta categoría para reportar los distintos problemas que se detec-

taban durante el desarrollo o las pruebas del sistema. Por lo general, la granularidad de

los errores los hace asequibles en un único ciclo de desarrollo.

Tanto el dueño del producto como el equipo de desarrollo colaboraban para definir las his-

torias de usuario necesarias para satisfacer una épica. Cuando se quería abordar una historia

de usuario, si era necesario, esta se descomponía en tareas que se abordarían en subsiguientes

ciclos de desarrollo.

Product Backlog y ciclo de vida de la unidad de trabajo. El Product Backlog es un listado

de todas las necesidades conocidas del sistema que deben ser implementadas. Las tareas se

ordenan según su prioridad, de modo que el equipo de desarrollo pueda anticiparse y prever

las necesidades de los siguientes ciclos. El dueño del producto es el responsable último de

mantener este listado actualizado.

46

6.1 Agilidad

Por su parte, el equipo de desarrollo debe asegurarse de que las tareas incluidas en el

Product Backlog contienen toda la información necesaria para ser desarrolladas, de modo

que puedan abordarse en los ciclos de desarrollo.

Se estableció el siguiente ciclo de vida para las unidades de trabajo:

Por hacer: Son las tareas que se deben abordar en el ciclo de desarrollo actual.

En progreso: Son aquellas tareas en las que el equipo de desarrollo ya ha empezado a

trabajar.

Bloqueada: Son tareas para las que se han encontrado dificultades durante su desarro-

llo, sean técnicas o por falta de definición, que impiden completarlas.

Hecha: Son aquellas tareas que ya han sido abordadas por el equipo de desarrollo y se

considera que están finalizadas.

Validada: Una vez las tareas hechas se validan con el dueño del producto, pasan a este

último estado.

Este ciclo de vida se implementó utilizando un tablero Kanban. Estos tableros consisten

en una serie de columnas y tarjetas. Las columnas se corresponden con los distintos estados

(empezando con el Product Backlog), mientras que las tarjetas se corresponden con unidades

de trabajo o tareas. Las tarjetas se van moviendo de unas columnas a otras, de manera que

tanto el dueño del producto como los desarrolladores pueden, de un simple vistazo, ver el

estado en el que se encuentran las distintas tareas del ciclo de desarrollo actual.

Ciclos de desarrollo cortos. Se establecieron reuniones periódicas cada semana y ciclos de

desarrollo de la misma duración. Estos ciclos de desarrollo reciben comúnmente el nombre

de sprints.

Durante cada reunión, el dueño del producto y el equipo de desarrollo validan conjun-

tamente los avances del último ciclo de desarrollo. El dueño del producto puede aceptar los

desarrollos llevados a cabo en esta iteración, o rechazarlos en caso de que estos no cumplan

con sus expectativas. Si una tarea es aceptada se marca como Validada, mientras que si se

rechaza volverá al estado por hacer y se refinará durante el siguiente ciclo. Para estas últimas,

se establecen los puntos pendientes o los cambios necesarios para darlas como válidas. Este

procedimiento recibe comúnmente el nombre de sprint review.

Una vez revisados los avances del último ciclo de desarrollo, se establecen los objetivos

para el siguiente. Aquí se tienen en cuenta dos factores. Por una parte, el dueño del producto

establece cuáles son las prioridades para el nuevo ciclo. Estas pueden variar, por ejemplo, por

47

6 Metodología

la detección de nuevas necesidades o de errores graves en las aplicaciones. Este procedimien-

to recibe comúnmente el nombre de sprint planning.

Por su parte, el equipo de desarrollo debe asegurarse de que todas las tareas que se vayan

a abordar se encuentran suficientemente definidas para ser desarrolladas. Este procedimiento

recibe comúnmente el nombre de refinamiento.

6.2 Control de versiones Git y fujos de trabajo

Aparte de las metodologías utilizadas para ayudar al desarrollador a saber qué tareas tiene

que desarrollar en cada momento y cuáles son las especificaciones de dicha tarea, también se

ha decidido establecer una metodología a nivel de código que ayude al desarrollador organizar

mejor el repositorio. Para mantener un orden dentro de lo que es repositorio en el que se

almacena el código se ha decidido utilizar Git-Flow [1]. Git Flow es ideal para proyectos que

tienen un ciclo de lanzamiento programado. Esta metodología de trabajo no agrega ningún

concepto o comando nuevo más allá de los que se utilizan comúnmente cuando trabajas con

Git (status, add, commit, checkout, merge, pull y push). Lo que sí hace, es asignar roles muy

específicos a diferentes ramas y define cómo y cuándo deben interactuar. Cuando trabajas

con Git Flow, en lugar de trabajar solamente con la rama master (cosa que es muy poco

recomendable hacer), utilizas dos ramas para registrar el historial del proyecto: master y

develop. Mientras que la primera de ellas contiene el historial de lanzamiento oficial, y por

tanto, el código que está en producción, la rama develop sirve como una rama de integración

de funcionalidades.

Las distintas ramas con las que trabajamos son:

Feature: Este tipo de ramas, se utilizan para añadir nuevas funcionalidades a tu pro-

yecto, en futuras versiones. Estas ramas, dependerán de la rama develop y se creará una

por cada funcionalidad que se quiera incorporar al proyecto.

Hotfix: Mientras que las ramas feature se van a utilizar para planificar nuevas funcio-

nalidades para tu proyecto (o mejora de las existentes), hotfix servirán para corregir

errores que se hayan encontrado en el código (ya sean de rendimiento o de seguridad)

y que no puedan esperar a una nueva versión para ser arreglados.

Release: En estas ramas es donde se va a preparar todo para el lanzamiento de una

nueva versión para el proyecto, o dicho de otra forma, donde se incorporarán todas

las funcionalidades de las ramas feature y se terminarán de testar antes de sacarlas a

producción.

48

6.3 Traducciones

6.3 Traducciones

Por lo general, los programas están escritos y documentados en inglés, y usa el inglés

en el momento de la ejecución para interactuar con los usuarios. Esto es cierto no solo en

Deliverit, sino también en una gran cantidad de software propietario y libre. Usar un lenguaje

común es bastante útil para la comunicación entre desarrolladores, mantenedores y usuarios

de todos los países. Por otro lado, la mayoría de las personas se sienten menos cómodas con

el inglés que con su propio idioma nativo, y prefieren usar su lengua materna para el trabajo

diario, en la medida de lo posible. A muchos simplemente les encantaría ver que la pantalla

de su ordenador muestra mucho menos inglés y mucho más de su propio idioma.

Gettext [10] es un paso importante para el Proyecto de traducción de Deliverit, ya que

es un activo sobre el cual podemos construir muchos otros pasos. Este paquete ofrece a los

programadores, traductores e incluso usuarios, un conjunto bien integrado de herramientas

y documentación. Específicamente, las utilidades gettext de GNU son un conjunto de herra-

mientas que proporciona un marco para ayudar a otros paquetes de GNU a producir mensajes

en varios idiomas. Estas herramientas incluyen un conjunto de convenciones sobre cómo

deben escribirse los programas para admitir catálogos de mensajes, un directorio y una orga-

nización de nombres de archivos para los propios catálogos de mensajes, una biblioteca en

tiempo de ejecución que admite la recuperación de mensajes traducidos y algunos programas

independientes para dar masajes de varias maneras los conjuntos de cadenas traducibles, o

cadenas ya traducidas.

Las traducciones en Gettext se almacenan en archivos de objetos portátiles (.po). Di-

chos archivos deben colocarse en priv /gettext/LOCALE/LC_MESSAGES/DOMAIN.po, donde

LOCALE es la configuración regional y DOMAIN es el dominio (el dominio predetermi-

nado se llama default). Por ejemplo, la traducción a es_ES se debe colocar en el archivo

priv/gettext/es_ES/LC_MESSAGES/default.po.

Traducciones en el proceso

Todos los cambios relacionados con el fraseo (wording) y traducciones tienden a generar

conflictos en Git en los ficheros .po. Mi recomendación es que todos esos cambios se realicen

fuera de las ramas feature. Es decir, se pueden introducir los cambios en los textos en inglés

en las ramas que exigen dichos cambios pero las actualizaciones de los ficheros .po es mejor

hacerlas sobre la rama develop para evitar fuertes conflictos en el cierre de las ramas.

49

6 Metodología

50

7Conclusiones y trabajo

futuro

Termino el último capítulo de esta memoria con mis conclusiones. Incluiré además algu-

nas de las necesidades identificadas para darle continuidad al proyecto. Esperamos que éstas

sirvan de inspiración para los alumnos que se incorporen, permitiéndoles obtener ideas sobre

el modo en que pueden contribuir al proyecto.

7.1 Conclusiones

Este trabajo implementa un sistema de entrega de prácticas que empecé con la esperanza

de que fuera utilizado por el profesorado de la ETSIINF. Me alegra poder escribir que desde

marzo de 2020 la asignatura Concurrencia lo ha estado usando con 400 alumnos, en 10

ejercicio cortos y 2 prácticas con pruebas no triviales.

Sigo teniendo la esperanza de que el sistema mejore lo suficiente como para que pueda

empezar a usarse en otras asignaturas, otras escuelas e incluso otras universidades.

Dicho sistema lo componen, de momento, dos aplicaciones Web: el portal de alumnos y el

panel de administración. El trabajo ha abarcado el diseño del modelo de datos y de interacción

de la aplicación entera aunque a la hora de llevarlo a código, solo nos ha dado tiempo a

51

7 Conclusiones y trabajo futuro

implementar los clientes listados previamente. Junto a esos paneles se ha implementado toda

la lógica y la librería para interactuar con Docker.

En el ámbito del desarrollo, mis principales aportaciones al proyecto a través del presente

trabajo fin de grado han sido:

Creación del modelo de datos e interacción.

Implementación de los clientes de alumnos y administradores.

Creación de una librería para interactuar con Docker.

Implementación de la lógica que hace funcionar ambos clientes.

Corrección de errores + soporte en la segunda interacción con este proyecto.

Además del desarrollo en sí mismo, una parte importante del trabajo ha consistido en

estructurar bien el código y escribir buena documentación. El objetivo principal: que otros

alumnos de la escuela puedan incorporarse al proyecto con una curva de aprendizaje reducida.

Esperamos que este libro sirva para ello.

Este trabajo me ha permitido aportar mi granito de arena a la universidad que tantas cosas

buenas me ha dado durante los últimos 4 años y espero que los posteriores trabajos sobre este

proyecto consigan aportar todavía mas.

7.2 Trabajo futuro

Componentes. Aunque este trabajo ha empezado la elaboración de componentes, es nece-

sario seguir trabajando sobre la factorización, extracción e implementación de más compo-

nentes y plantillas.

Pruebas. Aunque consideramos que el desarrollo basado en pruebas (test-driven design) es

una buena práctica en el proceso de desarrollo, no han sido aplicada en este desarrollo. Queda

como propuesta elaborar tests unitarios y tests de integración utilizando las herramientas que

ofrece Phoenix/Elixir.

Integración. Es importantísimo estudiar los puntos de integración del sistema con otros

sistemas. Detallamos una lista de los que consideramos fundamentales para mejorar la expe-

riencia de usuario de alumnos, profesores y administradores:

52

7.2 Trabajo futuro

Integración con servicios de directorio de la universidad, como por ejemplo LDAP:

https://www.etsiinf.upm.es/?pagina=1521.

Integración con servicios Web de la universidad, como por ejemplo apiUPM: https:

//www.upm.es/apiupm/webServices.html.

Integración con servidores de fichero remotos para almacenar los artefactos fruto de las

entregas, como por ejemplo UPMdrive del CESVIMA o S3 en AWS.

Integración con sistemas de hosting de control de versiones como fuentes de códigos de

comprobación y de artefactos de las entregas. Por nombrar algunos de estos sistemas:

GitLab (https://about.gitlab.com), Gitea (https://gitea.io) o Gitolite (https:

//gitolite.com).

Sobre la aplicación de profesores. Por el momento, el panel de administración es el que

servirá a todos los profesores que deseen usar el sistema. Sin embargo, es necesario desa-

rrollar dentro del sistema una nueva aplicación para profesores. Dicha aplicación tendrá un

control de acceso y cada profesor podrá encargarse de sus asignaturas y prácticas de forma

aislada del resto.

53

7 Conclusiones y trabajo futuro

54

Bibliografía

[1] Altassian. Gitflow Workflow. URL: https://www.atlassian.com/git/tutorials/

comparing-workflows/gitflow-workflow.

[2] Carlos Arturo. Explicando que es Front-End, que es Back-End y sus caracteristicas.

URL: http://www.falconmasters.com/web-design/que-es-front-end-y-que-

es-back-end/.

[3] Jr. Brooks, F.P. «No Silver Bullet Essence and Accidents of Software Engineering».

En: Computer 20.4 (abr. de 1987), págs. 10-19. ISSN: 0018-9162. DOI: 10.1109/MC.

1987.1663532. URL: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?

arnumber=1663532.

[4] M. Burrows y L. Hohmann. Kanban from the Inside. Blue Hole Press, 2014. ISBN:

9780985305192.

[5] Peter P. Chen. «The Entity-Relationship Model - Toward a Unified View of Data.»

En: ACM Trans. Database Syst. 1.1 (1976), págs. 9-36. URL: http://dblp.uni-

trier.de/db/journals/tods/tods1.html#Chen76.

[6] Bruce Tate Chris McCord y José Valim. Programming Phoenix 1.4. 1st. O’Reilly UK

Ltd., 2019. ISBN: 1680502263.

[7] Google Cloud. Contenedores en Google. URL: https://cloud.google.com/containers.

[8] Docker Registry. URL: https://docs.docker.com/registry/.

[9] Dockerfile reference. URL: https : / / docs . docker . com / engine / reference /

builder/.

[10] Ulrich Drepper. GNU gettext tools: Native Language Support Library and Tools. Sa-

murai Media Limited, 2015. ISBN: 9888381563.

[11] Jon Duckett. HTML and CSS: Design and Build Websites. 1.a ed. Wiley Publishing,

2014. ISBN: 1118871642.

55

BIBLIOGRAFÍA

[12] Jon Duckett. JavaScript and JQuery: Interactive Front-End Web Development. 1st.

Wiley Publishing, 2014. ISBN: 1118531647.

[13] Ecto. URL: https://github.com/elixir-ecto/ecto.

[14] Eric Evans. Domain-Driven Design: Tackling Complexity in the Heart of Software.

Addison Wesley, 2003, pág. 529. ISBN: 0321125215.

[15] Benjamin Tan Wei Hao. The Little Elixir and Guidebook. 1st. USA: Manning Publica-

tions Co., 2016. ISBN: 1633430111.

[16] Fred Hebert. Learn You Some Erlang for Great Good! A Beginner’s Guide. USA: No

Starch Press, 2013. ISBN: 1593274351.

[17] Microsoft Teams Site. URL: https://www.microsoft.com/es- es/microsoft-

365/microsoft-teams/group-chat-software.org/.

[18] Modelo vista controlador (MVC). URL: https://si.ua.es/es/documentacion/

asp-net-mvc-3/1-dia/modelo-vista-controlador-mvc.html.

[19] Moodle Site. URL: https://moodle.org/.

[20] Ken Schwaber y Mike Beedle. Agile Software Development with Scrum. 1st. USA:

Prentice Hall PTR, 2001. ISBN: 0130676349.

[21] James Shore y Shane Warden. The Art of Agile Development. First. O’Reilly, 2007.

ISBN: 9780596527679.

[22] James Turnbull. The Docker Book: Containerization Is the New Virtualization. James

Turnbull, 2014. ISBN: 9780988820203.

56

Este documento esta firmado porFirmante CN=tfgm.fi.upm.es, OU=CCFI, O=Facultad de Informatica - UPM,

C=ES

Fecha/Hora Sun Jun 07 20:22:43 CEST 2020

Emisor delCertificado

[email protected], CN=CA Facultad deInformatica, O=Facultad de Informatica - UPM, C=ES

Numero de Serie 630

Metodo urn:adobe.com:Adobe.PPKLite:adbe.pkcs7.sha1 (Adobe Signature)

Documents

TRABAJO FIN DE GRADO Sistema de Entrega Deliverit: Prototipo