Marcos López Sanz Ingeniería del Software de Gestión Tema 9: Proceso Unificado: Índice Visión general de Descripción de la (vista del modelo de ) de construcciones de la el un sub una Realizar pruebas de 1
Visión general Flujos de trabajo Planificación Anál. Riesgos Preparación Elaboración Fases Construcción Verificación Transición Requisitos Análisis Diseño Prueba Iteración(es) Inicial(es) #1 #2 #3 #4 #5 #6 #7 (Adaptado de Jacobson, 1999) Visión general análisis diseño casos de uso despliegue pruebas 2
Visión general Requisitos Casos de Uso Dependencia de traza Análisis Análisis Diseño Diseño Despliegue Pruebas Pruebas Diagramas UML Casos de Uso Análisis Diseño Despliegue Pruebas Casos de Uso Clases Objetos Secuencia Colaboración Estados Actividad Incluidos paquetes Interacción 3
Visión general El modelo de describe cómo los elementos de diseño se implementan en componentes (ficheros de código fuente, de código binario, ejecutable, scripts) Objetivo fundamental: Desarrollar la y el como un todo Objetivos del flujo de trabajo de : Planificar integraciones del Distribuir el en nodos Se basa en las s activas encontradas en diseño s y subs En particular las s se implementan como componentes de fichero que contienen código fuente Probar componentes individualmente los compilándolos y enlazándolos en uno o más ejecutables : 1 Sistema de Sub de Componente Interfaz 4
diseño Es el empaquetamiento físico de los elementos del modelo de diseño Estereotipos estándar: <<executable>>, <<file>>, <<library>>, <<table>>, <<document>> Relación de traza con las s de diseño Un componente puede implementar varios elementos Proporcionan las mismas interfaces que los elementos que implementan Dependencias de compilación Tranferencia entre cuentas <<trace>> <<file>> TransferenciaEntreCuentas.java <<compilation>> Transferencia Transferencia <<executable>> TransferenciaEntreCuentas.class 9 de Organizan los elementos del modelo de Se entienden como mecanismos de empaquetamiento del lenguaje de paquete en Java, proyecto en VisualBasic, directorio de ficheros en C++, paquete en Rational Rose,... Los subs de tienen una relación de traza 1 a 1 con los subs de diseño El sub de debe: Definir dependencias sobre otros subs o interfaces de otros subs Proporcionar las interfaces que han de ser proporcionadas por el Definir qué componentes, u otros subs de, deben proporcionar las interfaces proporcionadas por el sub. 5
de <<desing subsystem>> <<implementation subsystem>> <<trace>> (1:1) <<trace>> <<file>> <<file>> alfa beta beta alfa Operaciones implementadas por componentes y subs de Dependencias de uso DISEÑO IMPLEMENTACIÓN realiza de diseño realiza Interfaz Sub de Interfaz realiza realiza Clases de diseño Componente 6
Descripción de la Descomposición del modelo en subs, sus interfaces y dependencias entre ellos clave: Traza de las s de diseño significativas para la ejecutables generales y centrales de los que dependen muchos otros componentes Se utilizan para modelar la vista de estática de un Contienen: Relaciones de dependencia, generalización, asociación y realización Notas y restricciones Paquetes o subs Detalles del interfaz exportado omitidos Diagrama de componentes que muestra la versión ejecutable de un robot autónomo 7
despliegue (diseño): Se utilizan para modelar los aspectos físicos de los s orientados a objetos Muestra la configuración de nodos que participan en la ejecución y de los componentes que residen en ellos Contienen: Nodos Relaciones de dependencia y asociación Notas y restricciones que residen en algún nodo clientes servidores Multiplicidades explícitas Nodos estereotipados Diagrama de despliegue de un cliente/servidor de construcciones El software se construye en pequeños incrementos o pasos para tener pequeños problemas de y pruebas. Concepto de Construcción : versión ejecutable del Varias construcciones en una iteración Cada construcción es somete a pruebas de Es necesario Control de versiones por si la construcción falla, volver a la anterior Beneficios del enfoque incremental: Versión ejecutable muy pronto para enseñar y discutir Más fácil localizar defectos Pruebas de tienden a ser más minuciosas describe construcciones necesarias en una iteración: Funcionalidad esperada: lista de casos de uso o escenarios o parte de ellos. Requisitos adicionales y componentes necesarios para implementar esa funcionalidad 8
sub del flujo de trabajo de de la el un sub una Realizar prueba de sub de la Identificar componentes significativos. 1 a 1 Asignar componentes ejecutables a nodos: s activas diseño: nodo y sus objetos activos : nodo y sus instancias de componentes :Nombre del nodo :Nombre del nodo :Tranferencia implica <<executable>> :Transferencia 9
sub el Objetivos: Crear plan de de construcciones cada construcción antes de pruebas de Pasos: Planificación de una construcción Integración de una construcción sub el Planificación de una construcción Criterios de creación de una construcción: Debe añadir funcionalidad implementando casos de uso o escenarios. No debe incluir demasiados componentes nuevos o refinados Las construcciones deben expandirse hacia arriba y hacia los lados en la jerarquía de subs La 1ª construcción debe empezar en las capas inferiores (intermedia y de software del ), después hacia las capas general de aplicación y específica de aplicación. Para cada caso de uso: 1. Considerar el diseño del caso de uso (traza) 2. Identificar subs y s de diseño que participan en la realización del caso de uso-diseño 3. Identificar subs y componentes de que siguen la traza de los de diseño. 4. Considerar el impacto de implementar estos subs y componentes 10
sub el Integración de una construcción Recopilar versiones correctas de subs de y componentes Compilarlos y enlazarlos La construcción pasa después a las pruebas de sub un sub Objetivos: Asegurar que los requisitos (escenarios o casos de uso) implementados en la construcción se implementan correctamente por componentes u otros subs Pasos: Cada implementada por un componente Cada interfaz del sub de diseño debe ser proporcionada por el sub de Debe existir un componente que proporcione la interfaz 11
sub una Objetivos: una de diseño en un componente fichero/físico Pasos: Esbozo de componente fichero <<file>> que contendrá el código fuente Generar código fuente a partir de la de diseño y de las relaciones en que participa operaciones de la de diseño como métodos Asociaciones como referencias/atributos cuyo nombre es el nombre del rol del extremo opuesto de la asociación La multiplicidad del extremo opuesto indica si es un puntero simple o una colección de punteros Comprobar que el componente proporciona las mismas interfaces que la de diseño Reparación de defectos Importante Cuidar que el código de la cumple con el diagrama de estados asociado (si existe) sub Realizar prueba de Objetivo: Probar los componentes implementados como es individuales: Tipos de pruebas Pruebas de especificación o caja negra: verifican el comportamiento de la observable externamente sin tener en cuenta como se implementa ese comportamiento Pruebas de estructura o caja blanca: verifican la interna de la Otras pruebas: de rendimiento, utilización de memoria, carga y capacidad Pruebas posteriores De De 12