Presentaci

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/writingdoccomment
  s/ javadoc
• http//root.cern.ch/root/Conventions.html
  convención de nombrado de C del CERN.
• http//www.cvshome.org CVS.