Tema 9 Clase 9 Proceso Unificado - Implementacion y Prueba

Vista previa del material en texto

CLASE 8
MODELO DE DESARROLLO DE PROGRAMAS Y PROGRAMACION 
CONCURRENTE
FAC.DE INGENIERIA – UNJu – 2.019
Proceso Unificado - IMPLEMENTACION Y PRUEBA
IMPLEMENTACIÓN (UML)
Codifica los resultados del Diseño en términos de componentes tales como ficheros 
fuente, ejecutables, scripts, etc. Los objetivos de la implementación son:
• Implementar las clases encontradas durante el diseño. En concreto, se 
implementan dentro de componentes (ficheros) que contienen código fuente
• Asignar los componentes ejecutables a los nodos del diagrama de despliegue
• Probar los componentes individualmente e integrarlos en uno o más 
ejecutables
• Integrar los componentes en el sistema siguiendo un enfoque
IMPLEMENTACIÓN (UML)
Flujo de trabajo en la etapa de implementación
Responsabilidades del 
Ingeniero de componentes 
en la implementación
IMPLEMENTACION (UML) - ETAPAS
4 Implementación
4.1 Implementar la Arquitectura
4.1.1 Identificar componentes e Incorporarlos al modelo: 
diagrama de componentes
4.1.2 Asignar componentes a los nodos
4.2 Implementar las Clases de Diseño
4.2.1 Implementar las clases de diseño
4.2.1.1 Generar código fuente
4.2.1.2 Implementar las operaciones
4.2.1.3 Realizar pruebas de unidad de los 
componentes individuales
4.2.1.4 Integrar al Sistema
4.1IMPLEMENTAR LA ARQUITECTURA
4.1.1 IDENTIFICAR COMPONENTES E INCORPORARLOS AL MODELO: 
DIAGRAMA DE COMPONENTES
• Agrupa clases x tipos en 1componente 
(ficheros .java, .h y .cpp en lenguaje C++)
• A c/clase activa se le asignará un 
componente ejecutable
• 1componente describe 1elemento físico 
del sist. (archivos, cabeceras, bibliotecas 
compartidas, módulos, ejecutables, o 
paquetes)
• Muestra las dependencias entre los 
componentes; se representan a través de 
cajas q representan los módulos y flechas 
q indican 1 relación de utilización (el 
módulo q es origen de la flecha utiliza al 
módulo q es destinatario de la misma)
Ejemplo de 
1 Diagr.de
Componen
tes p/las 
clases 
Ficha, 
ListaFichas, 
FichaPelicu
las y Ficha 
Clientes
4.1.2 ASIGNAR COMPONENTES A LOS NODOS
De acuerdo con el Modelo de Despliegue se asigna las Clases activas a los 
nodos independientes
Ejemplo en el q el 
componente 
Procesamiento de 
solicitudes de 
pago implementa 
la clase 
Procesamiento de 
Solicitudes de 
Pago en el nodo 
servidor del 
comprador
4.2.1 IMPLEMENTAR LAS CLASES DE DISEÑO
4.2.1.1 GENERAR CÓDIGO FUENTE
Se Indica cuáles son las operaciones de las clases de diseño (no se las 
implementa). Las operaciones en sí se implementan más adelante.
En cuanto a las asociaciones y agregaciones, su generación es delicada. Lo 
normal es q 1 asociación q se recorre en 1dirección se implemente con 
1referencia, representada con 1atributo en el objeto q referencia y el nombre del 
atributo será el rol del extremo opuesto. La multiplicidad del extremo opuesto 
indicará si la referencia será 1puntero simple o 1colección de punteros.
Ejemplo de la declaración de la clase 
FichaCliente en C++
4.2.1.2 IMPLEMENTAR LAS OPERACIONES
C/operación definida x la clase de diseño se implementa mediante métodos 
utilizando el lenguaje correspondiente.
Implementa
ción del 
método 
Actualizar 
Películas
4.2.1.3 REALIZAR PRUEBAS DE UNIDAD DE LOS 
COMPONENTES INDIVIDUALES
Se procede a probar c/u de los componentes. P/ello se realizan:
Pruebas de especificación o pruebas de caja negra 
Verifican el comportamiento de la unidad observable externamente. Tiene como objetivo 
realizar la completa especificación de casos de prueba, p/así detectar fallas en el SW.
El Responsable de Verificación, junto con los Asistentes de Verificación realiza la 
especificación de los casos de prueba p/la verificación de los distintos módulos del Sist.y el 
Sist. en sí.
Se basan en los CU p/diseñar los casos de pruebas p/pruebas de caja negra, y buscar 
combinaciones de actores, entradas, salidas y estados iniciales q generen escenarios 
interesantes q empleen los objetos participantes en los diagramas.
4.2.1.3 REALIZAR PRUEBAS DE UNIDAD DE LOS 
COMPONENTES INDIVIDUALES
Pruebas de especificación o pruebas de caja negra (cont) 
La especificación de c/caso de prueba debe contener: 
• Nro. de caso de prueba
• Módulo sobre el q se realiza
• Funcionalidad q se verifica
• Entrada
• Especificación de Requerimientos
• Requerimientos Suplementarios
• Modelo de CU
• Plan de Verificación y Validación
• Plan de Verificación de la Iteración
• Salida esperada
• Salida real
• Rol responsable de Verificación
Se utiliza como 
Salida el Modelo 
de Casos de 
Prueba
4.2.1.3 REALIZAR PRUEBAS DE UNIDAD DE LOS 
COMPONENTES INDIVIDUALES
Pruebas de estructura o pruebas de caja blanca o pruebas de caja de cristal 
Verifican la implementación interna de la unidad. P/c/componente se estudia su 
implementación interna y trata de verificar su correcto comportamiento algorítmico. Se 
centran en los detalles procedimentales del SW, x lo q su diseño está ligado al código fuente
Los casos de prueba:
• Garantizan q se ejerciten x lo menos 1vez todos los caminos independientes de 
c/módulo, programa o método.
• Se ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
• Se ejecuten todos los bucles en sus límites operacionales.
• Se ejerciten las estructuras internas de datos para asegurar su validez.
Las principales técnicas de diseño de pruebas de caja blanca son:
• Pruebas de flujo de control
• Pruebas de flujo de datos
• Pruebas de bifurcación o branch testing
• Pruebas de caminos básicos
4.2.1.4 Integrar al Sistema
Los objetivos de la integración del Sistema son:
• Crear un plan de integración de construcciones q describa las construcciones 
necesarias en c/iteración y los requisitos de c/construcción
• Integrar c/construcción antes de q sea sometida a pruebas de integración
4.2.1.4 Integrar al Sistema (cont)
Para realizar la integración completa del Sist. se debe:
• Crear 1 plan de integración de los componentes en el Sist.
• Integrar c/componente antes de q sea sometido a las pruebas de integración
• Incluir algunos componentes como stubs (código adicional q se incorpora al 
código fuente p/agregar alguna funcionalidad adicional) p/poder desarrollar las 
pruebas de integración
• Implementar CU completos y de ser posible los + importantes
• C/CU podrá requerir varios componentes
PRUEBAS (UML)
Responsables 
q intervienen 
en las 
pruebas
El objetivo de esta fase es realizar pruebas sobre la estructura del sist.q se va 
formando con los módulos implementados.
Las pruebas que deben hacerse son de dos tipos: de integración y del sistema.
PRUEBAS (UML) - ETAPAS
5.1 Planificar y Diseñar las Pruebas de Integración y de Sist.
5.2 Realizar las Pruebas de Integración y de Sistema
ARTEFACTO
Un artefacto es el método o proceso utilizado p/c/prueba, en él se establece:
a) Casos de Prueba
Indica 1manera de probar el sist. Incluye q probar junto con su entrada o salida y bajo q 
condiciones probar.
Los casos de prueba pueden ser:
• Parecidos o Similares, diferenciándose únicamente en algún dato de entrada y/o salida
• De Instalación en 1 plataforma: verifican q el sist.pueda ser instalado en la plataf.del cliente
• De Configuración, sobre distintas plataformas: verifican q el sist.funciona correctamente en 
diferentes configuraciones
• Negativos, intentando que el sistema falle, por ejemplo utilizando datos no esperados
• De Tensión o Stress, probando el sist.cuando los recursos son insuficientes o hay 
competencias x ellos
Introducción o visión general: contiene la siguiente información general 
acerca de los Casos de Prueba:
• Identificador
• Dueño o Creador del Caso de prueba
• Versión
• Nombre del Caso de Prueba
• Identificador de requerimientos
• Propósito: con una breve descripción del propósito de la prueba, y la funcionalidad 
que chequea
• Dependencias: indicando qué otros subsistemas están involucrados y en qué grado
a) Casos de Prueba:Estructura de los casos de Prueba
• Ambiente de prueba/configuración: información acerca de la configuración del HW 
o SW en el cuál se ejecutará el caso de prueba
• Inicialización: acciones, q deben ser ejecutadas antes de q los casos de prueba se 
hayan inicializado. Por ejemplo, abrir algún archivo
• Finalización: describe acciones, q deben ser ejecutadas después de realizado el 
caso de prueba
• Acciones: pasos a realizar para completar la prueba
• Descripción de los datos de entrada
a) Casos de Prueba: Actividades de los casos de prueba
• Salida esperada
• Salida obtenida
• Resultado: indica el resultado cualitativo de la ejecución del caso de prueba, a menudo 
con un Correcto/Fallo
• Severidad: indica el impacto del defecto en el sistema: Grave, Mayor, Normal, Menor
• Evidencia: en los casos que aplica, contiene un link al print de pantalla (screenshot) 
donde se evidencia la salida obtenida
• Seguimiento: si un caso de prueba falla, frecuentemente la referencia al defecto 
implicado se debe enumerar en esta columna. Contiene el código correlativo del defecto, 
a menudo corresponde al código del sist. de tracking de bugs que se esté usando
• Estado: indica si el caso de prueba está: No iniciado, En curso, o terminado
a) Casos de Prueba: Resultados
a) Casos de Prueba
Ejemplo de un Caso de 
Prueba de la Carga de 
Documentos
Especifica cómo realizar 1 o varios casos de prueba. 
Son las instrucciones q los actores q realizan las pruebas deben seguir. 
Puede ser 1 instrucción para q 1 individuo realice la prueba manualmente o 1 especificación 
de como interaccionar con 1 herramienta de automatización de pruebas.
b) Procedimientos de Prueba
Relación q 
puede haber 
entre los 
procedimientos 
de prueba y los 
casos de prueba: 
n a n
Describe como se prueban los componentes ejecutables en el modelo de implementac.con
pruebas de integración y de sist.. Es la colección formada x los casos de prueba y 
procedimientos de prueba.
c) Modelo de Pruebas
Es una evaluación de los resultados de la prueba realizada, en ella se indica la cobertura del 
caso de prueba, la cobertura del código y el estado de los defectos.
d) Evaluación de la Prueba
Diagrama 
con los 
responsables 
del flujo de 
trabajo 
durante la 
prueba.
Verifican q los componentes interaccionan entre sí de 1 modo apropiado después de haber 
sido integrados en el sist. Se toman como Casos de Prueba los CU del diseño.
Se usa el Diagr.de Secuencia correspondiente y se diseñan combinaciones de entrada y 
salida del sist.q lleven a distintas utilizaciones de las clases, y en consecuencia de los 
componentes, q participan en el diagr.
Pruebas de Integración de Componentes
Ejemplo de un 
Diagr.de
Secuencia 
p/la 
realización de 
un CU de 
Diseño Pagar 
Factura
Prueban q el sist.funciona globalmente de forma correcta. C/prueba del sist.trabaja
combinaciones de CU bajo condiciones diferentes. Se prueba el sist.como un todo probando 
CU, unos detrás de otros y, si es posible, en paralelo. Se trata de ver que c/CU funciona 
adecuadamente en distintas configuraciones HW, de carga, con varios actores a la vez, en 
distinto orden, etc. La prueba de sist.puede empezar cuando las pruebas de integración son 
satisfactorias.
Pruebas del Sistema
Esquema general de 
las Pruebas del 
Sistema
• El Proceso Unificado de Desarrollo de Software. De Gustavo Torossi. 
Pág:40:53
• El Proceso Unificado de Desarrollo de Software. 2000. De Ivar Jacobson, 
Grady Booch y James Rumbaugh. Capítulo 9, 10 y 11. Pág.: 165:199
• Métrica 3. Técnicas y Prácticas. Ministerio de Administraciones Públicas. 
De Alarcos.
BIBLIOGRAFÍA RECOMENDADA