trabajo fin de grado sistema de entrega deliverit: prototipo
TRANSCRIPT
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
3 Modelización del sistema
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
2 use TypedEctoSchema
3 import Ecto.Changeset
4
5 @primary_key {:id, :binary_id}
6 @foreign_key_type :binary_id
7 typed_schema "assistants" do
8 field(:username, :string)
9 field(:email, :string)
13
3 Modelización del sistema
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
2 use TypedEctoSchema
3 import Ecto.Changeset
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
2 use TypedEctoSchema
3 import Ecto.Changeset
4
5 @primary_key {:id, :binary_id, autogenerate: true}
6 @foreign_key_type :binary_id
7 typed_schema "students" do
8 field(:id_number, :string)
9 field(:registration_number, :string)
15
3 Modelización del sistema
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 ])
36 |> validate_required([
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
2 use TypedEctoSchema
3 import Ecto.Changeset
4
5 @primary_key false
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
2 use TypedEctoSchema
17
3 Modelización del sistema
3 import Ecto.Changeset
4
5 @primary_key false
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 ])
28 |> validate_required([
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
2 use TypedEctoSchema
3 import Ecto.Changeset
4
5 @primary_key false
6 typed_schema "projects" do
7 field(:id, :binary_id, primary_key: true)
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
3 Modelización del sistema
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 ])
41 |> validate_required([
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
2 use TypedEctoSchema
3 import Ecto.Changeset
4
5 @primary_key false
6 typed_schema "groups" do
7 field(:id, :binary_id, primary_key: true)
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
3 Modelización del sistema
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
2 use TypedEctoSchema
3 import Ecto.Changeset
4
5 @primary_key false
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
2 use TypedEctoSchema
3 import Ecto.Changeset
4
5 @primary_key false
6 typed_schema "submissions" do
7 field(:id, :binary_id, primary_key: true)
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 ])
25 |> validate_required([
26 :id,
27 :project_id,
28 :group_id
29 ])
30 end
31 end
23
3 Modelización del sistema
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
3.2 Modelo de interacción
� 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
3 Modelización del sistema
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
3.2 Modelo de interacción
� 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
3 Modelización del sistema
� 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
3.2 Modelo de interacción
� 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
3 Modelización del sistema
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
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)
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
Web de estudiantes Web de profesores Web de administración
Componentes front-end
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
Lógica del sistema (logic)
Asignaturas Prácticas Alumnos Entornos . . .
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
Persistencia y comprobaciones
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
Persistencia y comprobaciones
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.
5.4 Librería Docker
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
5.4 Librería Docker
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)