Añadido un poco de texto mñas y cambiado las dobles comillas

Resources/Memoria/main.tex

@@ -1485,7 +1485,7 @@ En este apartado se describen los casos de uso detectados durante la fase de an
             \end{minipage} } \\
          Postcondición & \\
          Secuencias alternativas & {3a | 5a | 7a | 9a. Root cancela FIN DEL CASO DE USO \\
-3a. Root selecciona nuevo instrumento CASO DE USO ``Añadir modelo de instrumento'' \\
+3a. Root selecciona nuevo instrumento CASO DE USO ''Añadir modelo de instrumento'' \\
 7a. Root desea añadir otro paso IR A 4 \\
 9a. Root no confirma IR A 4 \\
 } \\
@@ -1888,13 +1888,13 @@ FIN CASO USO \\
 IR A 2 \\
 6a Root no confirma. \\
  1a Root quiere asignar el grupo a una sala \\
- CASO DE USO "Asignar grupo a sala" \\
+ CASO DE USO ''Asignar grupo a sala'' \\
  IR A 5 \\
  1b Root quiere asignar IP al grupo \\
- CASO DE USO "Asignar IP a grupo" \\
+ CASO DE USO ''Asignar IP a grupo'' \\
  IR A 5 \\
  1c Root quiere asignar investigadores al grupo \\
- CASO DE USO "Asignar Investigadores al grupo" \\
+ CASO DE USO ''Asignar Investigadores al grupo'' \\
  IR A 5 \\
 } \\
          Comentarios & \\
@@ -2132,7 +2132,7 @@ FIN CASO DE USO \\
          Precondición & \\
          Secuencia normal & {\begin{minipage}{\hsize}
             \begin{enumerate}
-				\item Caso De Uso "Ver lista Instrumentos"
+				\item Caso De Uso ''Ver lista Instrumentos''
 				\item Investigador selecciona un instrumento
 				\item SYSTEM muestra la ficha del instrumento
 				\end{enumerate}
@@ -2733,7 +2733,7 @@ En este apartado, describiremos los distintos tipos de actores que pueden intera
         }
          AC-002& \SetCell{c}Investigador \\
          Descripción & Actor más común. Representa a cualquier trabajador en un laboratorio. Podrá realizar las acciones de comprobar calibraciones, calibrar y visualizar los registros anteriores\\
-         Comentarios & Contiene toda la funcionalidad del actor "Usuario"\\
+         Comentarios & Contiene toda la funcionalidad del actor ''Usuario''\\
     \end{tblr}
     \caption{Actor AC-002, Investigador}
     \label{tab:AC-002}
@@ -2752,7 +2752,7 @@ En este apartado, describiremos los distintos tipos de actores que pueden intera
         }
          AC-003& \SetCell{c}Investigador principal \\
          Descripción & El investigador principal se encargara de la gestión de un grupo de investigación y, por ende, de sus investigadores.\\
-         Comentarios & Contiene toda la funcionalidad del actor "Investigador".\\
+         Comentarios & Contiene toda la funcionalidad del actor ''Investigador''.\\
     \end{tblr}
     \caption{Actor AC-003, Investigador principal}
     \label{tab:AC-003}
@@ -2804,13 +2804,18 @@ Para gestionar los distintos procedimientos que pueden presentar los instrumento
 \item Variable Procedimiento: Son las representaciones de las distintas acciones que hay que contabilizar cuando se realiza un paso. Es por ejemplo el peso que da una balanza al poner una pesa de 100g sobre ella.
 \item Formulario Procedimiento: Es el resultado del procedimiento, con todos los valores de los pasos que almacenaremos en los registros.
 \end{itemize}
+Aquí tenemos que explicar un par de cosas, como por que separamos los formularios de procedimientos del propio procedimiento.
+A la hora de modelar esta parte, encontramos un par de dependencias cíclicas, generadas por la parte de los instrumentos, el registro y los procedimientos. Teniendo en cuenta que antes no estaba el formulario, y el registro conectaba directamente con la instancia de instrumento y el procedimiento. Pero claro, como tal, nosotros podíamos acceder al procedimiento a través del instrumento (dirigiéndonos al modelo), con lo cual podíamos cortar esa relación.
+Pero al cortarla, perdíamos acceso o el lugar donde guardar los valores que se habían sacado durante ese procedimiento, con lo que necesitábamos un lugar donde almacenar las copias con los valores de las variables y que este conectado con el registro, sin hacer un bucle cíclico. Así surgió la clase FormProcedimiento
 \subsection{Gestión de instrumentos}
 Para modelar la parte de los instrumentos tenemos 3 clases:
 \begin{itemize}
 \item Tipo instrumento: Es la clase más general, aquí estaríamos hablando de los tipos generales, como son balanzas, pesas, etc.
 \item Modelo Instrumento: Aquí ya especificamos más a los modelos de los instrumentos, con números de modelo por fabricante. Estos modelos son los que tendrán distintos tipos de procedimientos asignados a ellos.
 \item Instancia Instrumento: Son cada una de las unidades de los distintos modelos de instrumentos que hay presentes en los laboratorios de los grupos de investigación.
+\item Atributos: Son la representación de una entrada, como si de un mapa se tratase, siendo el nombre la clave, y el valor el tipo.
 \end{itemize}
+Los atributos se han modelado de esta manera y no como un mapa porque el problema se encontraba cuando especificábamos el valor de los atributos en el modelo. Tuvimos que idear este parche para que tuviese sentido tener algo parecido a un mapa de ternas.
 
 \section{Costes del proyecto}
 Todo proyecto tiene un coste asociado. Aunque este proyecto se haya realizado bajo un ámbito no comercial, tiene un valor asociado, incluyendo gastos del personal que ha trabajado en el, o los materiales que se han utilizado para su desarrollo. En esta sección comentaremos que se ha utilizado para el desarrollo del proyecto y el precio que se le ha asignado, dando una ligera idea de cuanto podría costar un proyecto de esta índole en el mercado.
@@ -2906,6 +2911,7 @@ Esto es lo que vamos a tratar en los siguientes puntos.
 
 \section{Diseño de la interfaz}
 Aquí vamos a mostrar los mock-ups que hemos desarrollado para crear las interfaces que tendremos en la aplicación y el razonamiento detrás de ellos.
+La base de la que partiremos para desarrollar las interfaces son las guías de diseño de Material Design 3 \cite{mew_learning_2015} que ofrece Google con la intención crear las mejores prácticas para el diseño de interfaces.
 \subsection{Pantalla principal}
 Para esta pantalla, queremos un diseño simple, sin mucha cosa. Y es por eso que decidimos que lo mejor sería poner las funcionalidades principales en todo el centro con botones grandes. Algunos expertos nos sugirieron utilizar un menú hamburguesa, escondiendo los botones grandes. Lo rechazamos pues de aquella manera, a parte de esconder funcionalidad, nos quedaría un espacio en blanco muy grande y realmente no tenemos nada que poner ahi. 
 \begin{figure}[H]
@@ -3089,7 +3095,7 @@ Una de las restricciones ha sido el tamaño del disco, que era pequeño y, junto
 
 \subsection{Implementar el servicio de usuarios de la UVA}
 %TODO: No me se el nombre
-Una gran idea que estuvimos barajando era utilizar el sistema de usuarios para grupos de investigación que ya se usa dentro de la universidad. Pensamos que era buena idea para tener ya poblada la base de datos y que la aplicación estuviese "viva", pero debido a restricciones en el diseño de nuestro sistema y el de la UVA, era una posibilidad que se nos iba de plazos. 
+Una gran idea que estuvimos barajando era utilizar el sistema de usuarios para grupos de investigación que ya se usa dentro de la universidad. Pensamos que era buena idea para tener ya poblada la base de datos y que la aplicación estuviese ''viva'', pero debido a restricciones en el diseño de nuestro sistema y el de la UVA, era una posibilidad que se nos iba de plazos. 
 
 \subsection{Localización}
 Algo que se puede realizar es añadir localización al sistema de tal forma que el usuario pueda escoger el idioma en el que el quiera ver el sistema. Pero al tener datos introducido por los usuarios (las descripciones de los procedimientos, por ejemplo) habría que encontrar una manera con la que podamos identificar y buscar la cadena en ese idioma dentro de la base de datos.