\chapter{Requisitos del sistema}

Los requisitos los dividiremos en varios bloques dependiendo del tipo de ejecución y de la posterior visualización de los datos.

Como explicaremos con más detalle en el capítulo de {\bf Diseño e Implementación de Efficiency Guardian}
\footnote{{\it Efficiency Guardian} es el nombre dado al proyecto presentado y con el cual se ha creado el proyecto en {\it Sourceforge} \cite{sourceforge}}
\ref{sec:DisenyoImplementacion},
el proyecto presentado puede ejecutarse de dos maneras,
una primera ejecución en la que el propio usuario ejecuta se encarga de ejecutar los tests (ejecución explícita) y otra en la cual el usuario realiza un commit en un sistema de control de versión y, a partir de {\it testfarm} \ref{sec:testfarm}, la ejecución se realiza sin que el usuario deba iniciarla (ejecución implícita).

\section{Requisitos generales}
Antes de entrar en los requisitos específicos de cada tipo de ejecución, agruparemos varios requisitos que son generales a la hora de realizar el testeo de eficiencia. Los {\bf requisitos funcionales} son:

\begin{enumerate}
\item Los tests pueden ser ejecutados en local sin necesidad de realizar commits en el repositorio
\item El sistema ha de ser capaz de extraer la eficiencia de uno o varios métodos de código concretos.
\item Los valores obtenidos por el testeo deben poder ser repetibles en otras ejecuciones.
\item Los tests deben verificar sus resultados de manera automática.
\item El sistema está bajo las normativas GPL
\end{enumerate}

Los {\bf requisitos no funcionales} son:
\begin{enumerate}
\item Los fragmentos de código de los cuales se extraerá la eficiencia están estructurados mediante tests basados en la estructura de cppUnit.
\item Los tests serán realizados para el lenguaje de programación C/C++.
\item La extracción de los valores de eficiencia se realizará mediante un parser programado en Python.
\item Los ficheros generados por {\it EfficiencyGuardian} están estructurados en {\it Yaml}
\item Para la obtención de valores fiables y repetibles se usará un plug-in de Valgrind llamado Callgrind.
\item El sistema simula sitemas Linux e INTEL 32
\item El historial de los datos se almacenará a partir de una base de datos
\item La conexión con el servidor se realizará mediante apache/modpython.
\end{enumerate}


\section{Requisitos Ejecución Explícita}
Como ya hemos comentado, la ejecución explícita es la realizada directamente por el usuario a través de comandos por consola.
En la figura \ref{fig:UCExplicit}, se muestran los casos de uso del usuario para esta ejecución.

\begin{figure}[!ht] 
	\centering
	\fbox{\pdfimage width 6in {Imagenes/UseCaseExplicit.pdf}}
	\caption{Casos de uso de la ejecución explícita} 
	\label{fig:UCExplicit}
\end{figure} 

Los {\bf casos de uso} son los siguientes:

\begin{itemize}
\item {\bf Escribir Tests}.
\item {\bf Tomar Referencia}. Toma del servidor el fichero de referencia a partir del cual se comprobará el progreso de eficiencia de cada uno de los tests.
\item {\bf Tomar fichero de alarmas}. Toma del servidor el fichero donde se indican las alarmas para cada test.
\item {\bf Ejecutar EfficiencyGuardian}. Realiza la ejecución de los tests de eficiencia y  compara los resultados con el fichero de referencia.
\item {\bf Subir datos a historial}. Después de haber ejecutado {\it EfficiencyGuardian} sube el fichero de salida al servidor
\item {\bf Cambiar Referencia}. Después de haber ejecutado {\it EfficiencyGuardian}, la referencia pasa a ser la última ejecución
\item {\bf Visualizar resultado}. La ejecución de {\it EfficiencyGuardian} de manera explícita muestra la progresión de la última ejecución comparando los resultados con los valores de referencia
\end{itemize}


Partiendo de los casos de uso, los {\bf requisitos funcionales} son:

\begin{enumerate}
\item El usuario puede tomar del servidor el fichero de referencia con el que se realizará el cálculo del progreso de eficiencia.
\item El usuario puede modificar el valor de referencia del test cambiando la referencia por la última ejecución.
\item El usuario puede modificar el valor de referencia del test tomando del servidor el valor de una ejecución diferente a la de referencia.
\item El usuario podrá tomar del servidor el fichero de alarmas.
\item El usuario podrá subir los datos de la última ejecución al servidor.
\item El usuario podrá visualizar para cada uno de los tests una granulación de los ciclos de manera que se pueda aportar mayor información sobre los motivos de la posible variación de eficiencia.
\item El usuario podrá visualizar el listado de tests ejecutados mostrando para cada uno de ellos las variaciones de eficiencia en cada uno de sus valores.
\end{enumerate}

y los {\bf requisitos no funcionales}:
\begin{enumerate}
\item Las operaciones realizadas por el usuario se realizarán mediante línea de comandos.
\item La estimación de ciclos consta de los siguientes valores: Fetch de instrucción(Ir), lectura de instrucciones (Dr), escritura de instrucciones (Dw), fallos de búsqueda de instrucción en la cache de nivel 1 (I1mr), fallos de lectura en la cache de nivel 1 (D1mr), fallos de escritura en la cache de nivel 1 (D1mw), fallos de búsqueda de instrucción en la cache de nivel 2 (I2mr), fallos de lectura en la cache de nivel 2 (D2mr), fallos de escritura en la cache de nivel 2(D2mw) 
\end{enumerate}


\section{Requisitos Ejecución Implícita}
Como ya hemos comentado, la ejecución implícita es la realizada ajena al usuario después de realizar un commit al código.
En la figura \ref{fig:UCImplicit}, se muestran los casos de uso del usuario para esta ejecución.

\begin{figure}[!ht] 
	\centering
	\fbox{\pdfimage width 6in {Imagenes/UCImplicit.pdf}}
	\caption{Casos de uso de la ejecución implícita} 
	\label{fig:UCImplicit}
\end{figure} 

Los {\bf casos de uso} están separados en dos escenarios. El escenario de testeo, en el cual están los casos de uso relacionados con la ejecución tests, y el escenario de visualización, donde se agrupan los casos de uso de la visualización de datos por el usuario.

Los {\bf casos de uso} del escenario {\it testeo de eficiencia} son:

\begin{itemize}
\item {\bf Escribir Tests}.
\item {\bf Hacer commit}. El usuario hace commit del código en un sistema de control de versiones.
\item {\bf Ejecución de tests}. testfarm \ref{sec:testfarm} detecta el commit e inicia la ejecución de tests.
\item {\bf Visualización de datos}. testfarm visualiza los resultados del cálculo de progreso de eficiencia en su interfaz web (diferente a la interfaz de EfficiencyGuardian)
\end{itemize}

Los {\bf casos de uso} del escenario {\it visualización} son:

\begin{itemize}
\item {\bf Visualizar Alarmas}. El usuario visualiza las alarmas lanzadas para cada uno de los tests
\item {\bf Configurar Alarmas}.  El usuario modifica el valor a partir del cual se lanzará la alarma
\item {\bf Visualizar progreso del test}.  El usuario visualiza el progreso de eficiencia de cada uno de los tests desde su primera ejecución hasta la última.
\item {\bf Visualizar tests}.  El usuario visualiza la lista de todos los tests
\item {\bf Configurar referencia}. El usuario modifica  los valores de referencia que son comparados con los valores de las nuevas ejecuciones
\end{itemize}


Partiendo de los casos de uso, los {\bf requisitos funcionales} son:

\begin{enumerate}
\item El usuario podrá visualizar el listado de tests ordenados por proyecto al cual pertenecen y, para cada proyecto, por variación de eficiencia.
\item El usuario podrá visualizar las alarmas lanzadas para cada uno de los tests ordenadas por proyecto y por tipo de alarma.
\item El usuario podrá visualizar gráficamente el progreso de la eficiencia de cada test para cada uno de los valores.
\item El usuario podrá marcar como valor de referencia de un test cualquier valor dado en alguna ejecución anterior.
\item El usuario podrá configurar los valores para cada una de las alarmas
\end{enumerate}

y los {\bf requisitos no funcionales}:
\begin{enumerate}
\item Debe dar soporte mínimo los sistemas de control de versión CVS y Subversion.
\item La visualización gráfica se realizará mediante una interfaz web
\item Las alarmas pueden ser de dos tipos: {\it red alarms} en el caso que indiquen un descenso importante de eficiencia o {\it green alarms} en el caso que indiquen un aumento de eficiencia.
\item Los gráficos de progreso se realizarán con la herramienta open source {\it Ploticus}
\end{enumerate}