CLASE 8

MODELO DE DESARROLLO DE PROGRAMAS / MODELADO ORIENTADO A

OBJETOS
FAC.DE INGENIERIA – UNJu – 2.023

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 1 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.1 IMPLEMENTAR LA ARQUITECTURA
4.1.1 IDENTIFICAR COMPONENTES E INCORPORARLOS AL MODELO:
DIAGRAMA DE COMPONENTES
• Agrupa clases x tipos en Ej.1Diagr.de Componentes
1componente (ficheros .java, .h y p/las clases Ficha, ListaFichas, Ej.1Diagr.de Componentes
.cpp en lenguaje C++)
FichaPeliculas y Ficha Clientes p/las clases Ficha,
• A c/clase activa se le asigna un ListaFichas, Ficha Socio y
componente ejecutable Ficha Comprobantes

• 1componente describe
1elemento físico del sist.
(archivos, cabeceras, bibliotecas
compartidas, módulos,
ejecutables, o paquetes)

• Muestra las dependencias entre

los componentes; a través de
cajas s representan los módulos y
flechas q indican 1 relac.d
utilización (el módulo origen de
la flecha utiliza al módulo q es
destinatario de la misma)
4.1.2 ASIGNAR COMPONENTES A LOS NODOS
De acuerdo con el Modelo de Despliegue se asigna las Clases activas a los
nodos independientes
Ej.en el q el
componente
Procesamiento de
solicitudes de
pago implementa
la clase
Procesamiento de
Solicitudes de
Pago en el nodo
servidor del
comprador

Ej.seguido en clase
4.2.1 IMPLEMENTAR LAS CLASES DE DISEÑO
4.2.1.1 GENERAR CÓDIGO FUENTE
Indica 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.

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 Se utiliza como
• Especificación de Requerimientos Salida el Modelo
de Casos de
• Requerimientos Suplementarios Prueba
• 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
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.3 REALIZAR PRUEBAS DE UNIDAD DE LOS
COMPONENTES INDIVIDUALES
Ej.de pruebas de unidad
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)
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.

Responsables
q intervienen
en las
pruebas
 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 Config: sobre distintas plataf: verifican q el sist.funciona correctamente en difer.config

• 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
 a) Casos de Prueba: Estructura de los casos de Prueba
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

• 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: Resultados
• 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) o
captura de pantalla 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

Ejemplo de un Caso de
Prueba de la Carga de
Documentos
 b) Procedimientos de Prueba

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.

Relación q
puede haber
entre los
procedimientos
de prueba y los
casos de prueba:
nan
 c) Modelo de Pruebas
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.
 d) Evaluación de la Prueba
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.

Diagrama
con los
responsables
del flujo de
trabajo
durante la
prueba.
 Pruebas de Integración de Componentes
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.

Ejemplo de un
Diagr.de
Secuencia
p/la
realización de
un CU de
Diseño Pagar
Factura
Pruebas de Integración
de Componentes

Ej. de Pruebas de
Integración de
Componentes
 Pruebas del Sistema
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.

Esquema
general de
las Pruebas
del Sistema
BIBLIOGRAFÍA RECOMENDADA

• 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.