9.- Flujo de Implementación Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

1. 9.- Flujo de Implementación Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

2. Introducción • Los objetivos de la implementación son: • Planificar las integraciones del sistema requeridas en cada iteración. El enfoque adoptado consiste en realizarlo de manera incremental, de manera que el sistema se implementa como una sucesión de pasos de tamaño manejable. • Distribuir el sistema, mapeando componentes de ejecución en los nodos. • Implementar clases y subsistemas de diseño. • Integrar los componentes y realizar las primeras pruebas de unidad.

3. Pasos • El arquitecto delinea los principales componentes del modelo de implementación. • El integrador de sistemas planea las integraciones de sistemas requeridas en esta iteración como una secuencia de “builds”. • Para cada “build” describe las funcionalidades esperadas y qué partes del modelo de implementación se ven afectadas. • Entonces los ingenieros de componentes crean/actualizan los componentes/subsistemas necesarios. • Los componentes se prueban juntos y se pasan al integrador de sistemas que crea el nuevo “build” y se lo pasa al equipo de pruebas de integración.

4. Actividades de Implementación • Implementación desde el punto de vista de la arquitectura. • Integrar el sistema. • Realizar las pruebas de unidad.

5. Actividad: Implementación • Objetivos: • Identificar componentes significativos desde el punto de vista de la arquitectura. • Mapear componentes a nodos.

6. Actividad: Integrar el Sistema • Objetivos: • Crear un plan de “builds” describiendo los builds para cada iteración y los requerimientos para cada build. El objetivo aquí es que cada build sea lo suficientemente pequeño para ser manejable. • Importante: no fraccionar casos de uso. Cada build debe tratar nuevos casos de uso enteros. • Las primeras builds deben centrarse en las capas más inferiores (se va de abajo a arriba). • Integrar cada build antes de que sea sometida a las pruebas de integración. Si se ha hecho bien el plan, esto debería ser inmediato. • Tras esto, entran en ejecución las actividades de implementación de subsistemas, y clases específicas.

7. Herramientas de Gestión de Versiones

8. Actividad: Realizar las pruebas de Unidad • Objetivo: • Probar los componentes implementados como unidades individuales. • Tipos de pruebas: • Pruebas de especificación. Verifican el funcionamiento desde el punto de vista externo. Caja negra. • Pruebas de estructura. Verifican la implementación interna de la unidad. Caja blanca. Probar todos los caminos.

9. Modo de trabajar • Implementar es la parte que más recursos lleva en un proyecto -aunque no sea realmente la más importante-. • Es necesario por tanto tener un control exhaustivo de QUÉ se está haciendo, y CÓMO. • Para ello debemos tener un MODO DE TRABAJAR. • A continuación mostramos las características más comunes.

10. Convenciones (I) • Se utilizarán convenciones de codificación y documentación del código. • P.e. JAVA: • Código: Java Code Conventions de SUN • Documentación: Javadoc.

11. Convenciones (y II) • Guías de estilo de codificación: • Cabeceras • Comentarios • Alineación de columnas • Nombres de clases • Nombres de atributos • Nombres de función/método • Espaciado entre los paréntesis • Número de líneas de código de un módulo • Situación de elementos dentro de un módulo • Ausencia de números en el código

12. Builds (I) • Sucesión de builds en una iteración: • En cada iteración, para el flujo de tareas de implementación se hará un plan de builds que tendrá que ser aprobado por el jefe de proyecto. • Se proporcionan una serie de criterios de guía para establecer las builds del plan: • Se dividen los casos de uso a tratar en la iteración en grupos más o menos relacionados. Cada grupo irá a una build. • Las primeras builds deben ocuparse de las capas más inferiores. • Cada build debería tratar casos de uso enteros, y no partes de casos de uso.

13. Builds (y II) • Antes de pasar al repositorio su parte de una build, el desarrollador hará las pruebas de unidad. • Una vez finalizada una build, uno de los desarrolladores asume el rol de "integrador", que es el encargado de comprobar que la build es básicamente correcta.

14. Lista de Defectos • Aparte de la documentación del flujo de implementación, se debe mantener también una Lista de defectos: • Incluye los defectos del software relevantes en el momento actual. Esta lista no formará parte normalmente del documento de implementación, pero este documento deberá explicar como acceder a ella. • Para cada defecto de la lista se incluirán los siguientes campos (generalmente): • Caso de prueba que ha fallado (si lo hay) • Fecha de alta en la lista • Fecha de solución • Código del defecto • Descripción • Responsable de solucionar el defecto (si lo hay) • Estado actual del defecto

15. Ejemplo • Plan de builds

16. Bibliografía • Enlaces: • http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html: convenciones de nombrado para Java. • http://java.sun.com/j2se/javadoc/writingdoccomments/: javadoc • http://root.cern.ch/root/Conventions.html: convención de nombrado de C++ del CERN. • http://www.cvshome.org: CVS.