Unidad 9. Implementación. M.C. Martín Olguín

Transcripción

1 Unidad 9 Implementación M.C. Martín Olguín

2 Implementación Es la traducción directa del diseño en un lenguaje de programación. Es decir, en la implementación se construyen los componentes: Archivos de código Scripts Ejecutables Tablas Etc.

3 Implementación

4 Estructurar el modelo de implementación Consiste en determinar el conjunto de subsistemas que pueden ser desarrollados independientemente. Un modelo bien organizado evitará problemas de administración de configuración y permitirá que el producto se vaya construyendo a partir de integraciones sucesivas de versiones cada vez mayores.

5 Pasos para estructurar el modelo de implementación I. Establecer la estructura del modelo de implementación. II. Ajustar los Subsistemas de la Implementación. III. Definir las dependencias para cada subsistema. IV. Decidir como tratar los ejecutables (y demás objetos derivados) V. Decidir como tratar los elementos de prueba. VI. Actualizar la vista de la implementación. VII. Evaluar el modelo de implementación.

6 I. Establecer el modelo de implementación Empezar por copiar la estructura del Modelo de Diseño en el Modelo de Implementación. Los Paquetes del Diseño tendrán su correspondiente Subsistema en la Implementación, los cuales a su vez tendrán uno o más directorios y archivos necesarios para implementar los elementos del diseño.

7 Establecer el modelo de implementación El mapeo entre el Modelo del Diseño y el Modelo de Implementación, cambiará conforme los subsistemas de la implementación se vayan ubicando en sus capas específicas en la arquitectura. Crear un diagrama de componentes.

8 II. Ajustar los subsistemas de la implementación Decidir los cambios en la organización de los subsistemas debido a cuestiones tácticas del ambiente de implementación, tales como: Organización del equipo de desarrollo Tipos de datos (declaraciones) Código legado existente Ajuste de dependencias

9 III. Definir las dependencias para cada subsistema. Para cada subsistema definir que subsistemas utiliza (importa). Generalmente las dependencias en Modelo de Implementación son iguales a las del Modelo de Diseño, a menos que se hayan hecho ajustes.

10 IV. Decidir como tratar los ejecutables Los ejecutables son el resultado de aplicar un proceso de creación (build) a los subsistemas de la implementación, por lo tanto, pertenecen a estos subsistemas. Sin embargo, el arquitecto puede decidir enviarlos a un subsistema aparte.

11 V. Decidir como tratar los recursos de prueba Los subsistemas y artefactos de prueba no son parte de los entregables al cliente. Se deben manejar de manera especial. Para efectos del modelado, se pueden representar como un subsistema. Para las pruebas de unidad, se pueden considerar como parte del subsistema. Para las pruebas de integración y de sistema se pueden ver como subsistemas pares.

12 VI. Actualizar la vista de la implementación. Cada cambio en el modelo de implementación deberá ser reflejado en el documento de arquitectura.

13 VII. Evaluar el modelo de implementación Están definidas las Interfaces y dependencias entre los subsistemas de implementación? Está balanceada la carga de trabajo para el equipo de implementación; los cuellos de botella potenciales se han identificado y el trabajo se ha redistribuido, se han creado planes de contingencia para permitir la redistribución del trabajo crítico si la asignación inicial de trabajo se desbalancea?

14 Evaluar el modelo de implementación No existen dependencias que cruzan más de una capa. Se han eliminado dependencias innecesarias en los subsistemas de capas inferiores Se ha reducido el impacto de las dependencias necesarias a subsistemas de capas inferiores al permitir que los subsistemas de capas medias re-exporten interfaces de los subsistemas de capas inferiores.

15 Evaluar el modelo de implementación El número de capas no es mayor a siete (más menos 2), o existe una razón bien entendida del por qué son necesarias más capas. La proporción entre el número de paquetes o subsistemas y el número de elementos de implementación es consistente con el tamaño y complejidad de la aplicación.

16 Evaluar el modelo de implementación La cantidad de código es consistente con la expectativa basada en el número de clases de diseño. (Por ejemplo, 100,000 líneas de código para 10 clases de diseño es signo de que el diseño, la implementación o ambos están mal). El esfuerzo de implementación real es cercano a lo estimado, si no, entonces las bases para la estimación tienen que ser revisadas.

17

18 Planear la Integración Objetivo: Para la iteración actual, planear cuales subsistemas deberán ser implementados y el orden en que dichos subsistemas deberán ser integrados. La integración se lleva a cabo por una persona o un equipo pequeño con habilidades en manejo en scripts o herramientas de integración.

19 Planear la Integración Pasos: I. Identifica los subsistemas. II. III. IV. Define los Conjuntos de Construcción (build sets) Define la secuencia de los builds (build series). Evalúa el Plan de Integración

20 I. Identifica los subsistemas. El Plan de la Iteración especifica que casos de uso y escenarios serán implementados. Hay que identificar cuales subsistemas corresponden a estos casos de uso y escenarios. Además hay que saber cuales otros subsistemas se requieren.

21 Identifica los subsistemas.

22 II. Define los Build Sets En un proyecto grande se pueden tener cientos de subsistemas de implementación. Se recomienda definir conjuntos de subsistemas con significado común desde el punto de vista de la integración

23 Define los Build Sets

24 III. Define la secuencia de los builds (build series). Se definen secuencias de construcción para integrar el sistema incrementalmente. Para cada build se definen los subsistemas que le pertenecen. Se definen los subsistemas que irán como stubs en el build.

25 Define la secuencia de los builds (build series).

26 IV. Evalúa el Plan de Integración El orden de integración facilita la localización de errores? El orden de integración mantiene el requerimiento de stubs al mínimo? Está coordinado el orden de la integración con el orden en el que están siendo desarrollados los componentes?

27

28 Implementa componentes El propósito es completar una parte de la implementación para que pueda ser entregada para integración. Conforme van implementando elementos del modelo de diseño, los implementadores escriben código, adaptan código existente, compilan, encadenan y realizan pruebas de unidad.

29 ...Implementa componentes Si los implementadores descubren defectos en el diseño, se retroalimenta a los diseñadores para que rehagan el trabajo. Los implementadores corrigen defectos de código y realizan pruebas de unidad para verificar los cambios. El código es revisado para evaluar el apego a los estándares de programación.

30 Actividades en la Implementación El Implementador: Implementa Elementos del Diseño. Analiza el comportamiento en tiempo de ejecución. Implementa elementos de prueba. Implementa pruebas de desarrollador. Ejecuta pruebas de desarrollador.

31 ...Actividades en la Implementación Revisor Técnico Revisa código Integrador Planea la integración del subsistema

32

33 Integra cada subsistema El propósito es integrar los cambios de múltiples implementadores para crear una nueva versión consistente de un subsistema. El Integrador es el responsable de integrar el subsistema y entregarlo al espacio de trabajo del sistema. Se deben realizar pruebas de integración.

34

35 Integra el sistema El propósito es integrar los subsistemas para crear una versión consistente del sistema completo. Cada integración deberá ser probada hasta completar el sistema entero. Se lleva a cabo por el Integrador.

36 Artefactos Modelo de Implementación