diff options
| -rwxr-xr-x | memoria.tex | 137 |
1 files changed, 128 insertions, 9 deletions
diff --git a/memoria.tex b/memoria.tex index f14d7db..57538c3 100755 --- a/memoria.tex +++ b/memoria.tex @@ -289,7 +289,7 @@ verá en el apartado \ref{sec:tactics}. Para poder razonar sobre distribuciones de probabilidad, EasyCrypt proporciona un tipo (\rawec{'a distr}) que representa sub-distribuciones discretas sobre \rawec{'a}. La principal herramienta para trabajar sobre sub-distribuciones es -el operador (\rawec{op mu : 'a distr -> ('a -> bool) -> real}), que devuelve la +el operador \\ (\rawec{op mu : 'a distr -> ('a -> bool) -> real}), que devuelve la probabilidad de un evento. Por ejemplo, la distribución uniforme sobre booleanos está definida en la biblioteca estándar de EasyCrypt de la siguiente manera (\rawec{charfun} es la función característica de p evaluado en x, es decir, @@ -764,14 +764,14 @@ encuentre los identificadores `cost` y `caxiom`, respectivamente: \begin{code} \begin{minted}{ocaml} let _keywords = [ -"admit" , ADMIT; -"forall", FORALL; -"exists", EXIST; -"pragma", PRAGMA; -(* ... *) - -"cost" , COST; -"caxiom", CAXIOM + "admit" , ADMIT; + "forall", FORALL; + "exists", EXIST; + "pragma", PRAGMA; + (* ... *) + + "cost" , COST; + "caxiom", CAXIOM ] let keywords = Hastbl.create 100 @@ -1016,28 +1016,147 @@ class File(models.Model): project = models.ForeignKey(Project) # ... \end{minted} + \caption{models.py} \end{code} +Una vez definidos los modelos, Django genera automáticamente la base de datos +(modelo $\rightarrow$ tabla, atributo $\rightarrow$ columna, ...) y la reifica +(representando cada entrada en la base de datos como un objeto en Python), para +poder hacer un uso totalmente transparente de ella. Además, Django incluye +varios controladores de gestores de bases de datos que abstraen su acceso y +hacen posible intercambiarlos sin mayor problema. En nuestro caso, debido a la +facilidad de uso y la poca carga que tendrá el sistema, usaremos el gestor de +bases de datos \textbf{SQLite}\footnote{\url{http://www.sqlite.org/}}, aunque +debería ser trivial cambiarlo en el futuro por cualquier otro gestor. + \subsection{Vista} +\label{sec:vista} + +La vista es el subsistema encargado de generar y servir la parte visual de la +web: ficheros HTML (posiblemente incluyendo también código JavaScript y/o CSS). + +En Django, la vista la implementa un sistema de plantillas (<<templates>>). Una +plantilla no es más que un fichero HTML incompleto que Django rellena en tiempo +de ejecución sustituyendo ciertas meta-directivas por código HTML válido. Las +plantillas se almacenan normalmente en un directorio ``/templates'', separadas +del resto del código del proyecto. + +Para desarrollar la interfaz web ha sido necesario escribir un total de 4 +plantillas, descritas a continuación junto con una captura de pantalla de su +resultado una vez servidas: + +\begin{itemize} +\item \textbf{base.html}, donde se define la estructura HTML básica del sitio + web y se cargan recursos externos como el tema CSS, bibliotecas de JavaScript, + etc. No se usa directamente, sino que se importa desde otras plantillas usando + la directiva \textbf{extends} de Django. +\item \textbf{login.html}, servida cuando se accede a la página de inicio de + sesión. Un ejemplo de su resultado final: + + TODO captura de pantalla +\item \textbf{register.html}, servida cuando se accede a la página de registro + de usuarios. Su resultado: + + TODO captura de pantalla +\item \textbf{index.html}, la plantilla que sirve la pantalla principal. Cuando + no hay ninguna sesión iniciada, se muestra un mensaje de bienvenida: + + TODO captura de pantalla + + Una vez el usuario ha iniciado sesión, se muestra la página principal de la + interfaz web, con navegador de proyectos, editor de texto y resultados de la + evaluación. +\end{itemize} \subsection{Controlador} +\label{sec:controlador} + +Por último, el controlador es la parte que coordina las otras dos (modelo y +vista) e implementa la lógica del sitio web como tal. En Django esto se lleva a +cabo fundamentalmente en dos ficheros: + +\begin{itemize} +\item \textbf{views.py}. En este fichero se definen las \textbf{vistas}, que es, + curiosamente, el término que usa Django para denominar a las funciones que + reciben una petición y devuelven una respuesta HTTP conteniendo, normalmente, + una plantilla ya procesada. Este es el mecanismo básico que controla el + comportamiento del sitio web: al acceder a una URI concreta se ejecuta una + vista que decide, en función de los datos contenidos en la petición (sesión, + usuario autenticado, método HTTP, etc.) qué plantilla servir y cómo + rellenarla. + + Para implementar la funcionalidad del sitio web se han tenido que implementar + varias vistas, tratando dentro de lo posible que cada vista esté asociada a un + recurso, y haga una cosa u otra en función del método HTTP (arquitectura + REST). Debido a que la mayor parte de la funcionalidad del sistema se + encuentra en la interfaz del usuario (cliente pesado), la interacción con el + servidor se reduce prácticamente al intercambio de datos: proyectos y + ficheros. +\item \textbf{urls.py}. En este fichero se configura qué vista ha de invocarse + cuando el usuario accede a una determinada URI. El formato es bastante + sencillo: las URI se especifican usando expresiones regulares, y cuando la + solicitud coincide con una de ellas, se invoca la vista correspondiente + pasándole como argumentos la solicitud en cuestión y, opcionalmente, + argumentos especificados en la expresión regular. + + Pongamos un ejemplo real de nuestra implementación. Esta línea en urls.py se + encarga de gestionar las solicitudes relacionadas con un fichero en concreto + (obtener su contenido, actualizarlo, eliminarlo, etc.): + + \begin{code} + \begin{minted}{python} +url(r'^files/(?P<file_id>\d+)', views.file_mgr) + \end{minted} + \caption{urls.py} + \end{code} + + El primer campo es la expresión regular. Los paréntesis a continuación de la + barra <</>> indican un campo cuyo valor es de uno o más dígitos y que se le + debe pasar a la vista como argumento de nombre <<file_id>>. En este caso, un + acceso a ``/files/13/'' devolvería el resultado de ejecutar la vista de la + siguiente forma: + + \begin{code} + \begin{minted}{python} +views.file_mrg(request, file_id=13) + \end{minted} + \end{code} + + (Que devuelve el contenido del fichero cuyo atributo ``id'' es 13). + + Dentro de las URI que se han diseñado para interactuar con nuestro sistema, + algunas están pensadas para que el usuario pueda acceder directamente o forman + parte de la navegación normal (``/login'', ``/logout'', etc) y cuya respuesta + es siempre HTML, mientras que otras se usan como interfaz directa a los datos + (``/files'', ``/projects'', etc) y devuelven información en formato JSON. De + estas segundas hablaremos con más detalle en la sección siguiente (TODO + seguro?) (\ref{sec:impl-cliente}). + +\end{itemize} \section{Implementación: cliente} +\label{sec:impl-cliente} TODO \section{Implementación: servidor EasyCrypt} +\label{sec:impl-serv-easycrypt} TODO +% A dormir! + \emptypage \chapter{RESULTADOS Y CONCLUSIONES} +\label{cha:result-y-concl} \emptypage \chapter{CONTRIBUCIONES} +\label{cha:contribuciones} \emptypage \chapter{ANEXOS} +\label{cha:anexos} \pagebreak \bibliography{bib}{} \bibliographystyle{ieeetr} |