Esquema y planificación de la memoria 1. Introducción - La limitación del hardware obligaba a a hacer un esfuerzo de optimización - La necesidad de optimización causó que hubiera despreocupación por el diseño y falta de previsión - Los programas crecían de tamaño y complejidad y ésto dificultaba elmantenimiento - Con la ingeniería de software se indican unas pautas para el desarrollo de software profesional - Dos corrientes de la ingeniería de software son el extreme programming y el free software - El extreme programming es una corriente de metodologías ágiles que simplifica elproceso de creación del sistema - Dos prácticas del XP son el refactoring y el testing - Optimización de software: diseño Vs implementación - Free software es un conjunto de metodologías open source: sistema de control de configuración, bugtracking, mailing lists,... - Formas de medir el tiempo de ejecución de un proceso y sus problemas - Cómo valgrind soluciona alguno de esos problemas - Cómo calcular la eficiencia de las partes de código que me interesan - Qué es la regresión, cuál es su utilidad y cómo llevarla a cabo 2. Conceptos Fundamentales 2.1. La eficiencia en metodologías Extreme Programming 2.1.1. Explicación general sobre XP - Definición de extreme programming - Qué beneficios tengo al crear mi sistema usando dichas metodologías - Explicación superficial de las prácticas más comunes 2.1.2. Refactoring y Test driven development - Definición de refactoring y explicaciones basándome En el libro de Fowler - Definición de Test driven development basándome en el libro de Beck - Explicar la relación entre ambas prácticas y la necesidad del refactoring dentro del testing - Mostrar la relación entre estas dos prácticas y los tests de eficiencia - Cómo, a partir de los tests de eficiencia, el refactoring tiene dos dependencias: eficiencia y diseño 2.1.4. Eficiencia Vs Diseño. - Ventajas del diseño (mantenimiento del software) - Ventajas de la eficiencia y posibles problemas de un software no eficiente - Importanceia de mantener un equilibrio entre eficiencia y mantenimiento 2.1.5. Proceso de optimizacion en un entorno XP - Explicar como a partir del framework de eficiencia se puede realizar la optimización de un proceso - Recalcar la posibilidad de regresión necesaria para comparar la evolución de eficiencia 2.2. Medida de la eficiencia. 2.2.1. Medidas de eficiencia. (está escrito) - La eficiencia se mide respecto al tiempo - qué cuatro medidas de tiempo son las más frecuentes - Que problemas tiene la medida de eficiencia: Dependencias de la arquitectura y velocidad del procesador - Posible solución para solucionar ciertas dependencias 2.2.2. Modos de medición - Cronometrados - profiling - instrumentación 2.2.3. Valgrind/Callgrind - Qué es Valgrind - Qué ventajas tiene - Qué es callgrind - Explicación del fichero creado por callgrind - Cómo relacionar los tests de eficiencia con el fichero de callgrind. Cómo podemos saber quélíneas de código nos interesan para calcular la eficiencia de una o varias funciones 2.3. Simulación 2.3.1. Máquinas Virtuales. 2.4. Modelo de desarrollo open source - Qué es el open source - diferencias entre el open source y los códigos cerrados ("El bazar y la catedral") - Que requisitos son necesarios para llevar a cabo un proyecto open source (organización de trabajo, herramientas necesarias) - Ventajas e inconvenientes de este modelo de desarollo - Metodologías ágiles --> extreme programming - Qué beneficios conlleva que nuestro framework de eficiencia sea un proyecto open source 3. Requisitos del sistema 3.1. Requisitos Funcionales 3.1.1. Data collector - El sistema ha de ser capaz de extraer la eficiencia de un fragmento de uno o varios fragmentos de código concretos - Se debe mantener el historial de cada test - Una máquina debe ejecutar los tests automáticamente. - los tests se deben ejecutar cada vez que hay un cambio en el repositorio - Los tests también pueden ser ejecutados en local sin necesidad de hacer commits en el repositorio - Monitorizar la ejecución mediante una web 3.1.2. Interfaz Web - El sistema debe permitir configurar las alarmas - El sistema debe mostrar gráficos del desarrollo de la eficiencia - El sistema debe dar diferentes tipos de avisos en el caso que el descenso de eficiencia sea considerado grave 3.2. Requisitos no Funcionales 3.2.1. Data collector - El sistema no debe estar sujeto a un sistema de control concreto. - Debe dar soporte mínimo a CVS y Subversion - La medida a partir de la cual se calcula la eficiencia debe ser fiable ante condiciones como independencia de velocidad de cpu para obtener unos valores fiables - El sistema sólo funciona en Linux e INTEL 32 3.2.2. Interfaz Web 4. Herramientas 4.1. Valgrind 4.2. CVS 4.3. PyUnit 4.4. Python 5. Diseno e Implementación 5.1. Data Collector 5.1.1. FrameWork de ejecución de tests 5.1.2. Intérprete de la salida de Callgrind 5.1.3. Ejecución Diaria de tests 5.2. Base de Datos 5.2.1. Editor de Base de Datos 5.2.2. Importador de datos 5.2.3. Exportador de Datos 5.3. Interfaz Web 5.3.1. Creación del mapa de alertas 5.3.2. WebApp 6. Conclusiones