8/19/2019 UML Proceso de Pruebas

1/10

DOCENTE

MARIA DEL ROSARIO MORENO

FERNANDEZ TRABAJO

UML Y EL PROCESO DE PRUEBAS

ESTUDIANTE

 JESUS VIDAL RODRIGUEZ

CARRERA

INGENIERÍA EN SISTEMASCOMPUTACIONALES

MATERIA

VERIFICACIÓN Y VALIDACION DESOFTWARE

UNIDAD 1

INSTITUTO TECNOLÓGICOSUPERIOR DE TIERRA

8/19/2019 UML Proceso de Pruebas

2/10

TIERRA BLANCA, VER. 03 DE MARZO DE201

INTRODUCCIÓN

En general, la implementación de modelo de pruebas puede satisfacer un modelo

y no otro: por ejemplo puede satisfacer el Modelo de Clases y no el de Uso (o vice

versa); incluso puede satisfacer varios modelos sin satisfacer los reuerimientos!

"os modelos son, por definición, complementarios! #e presentan varios modelos

porue, en general, cumplir uno sólo de ellos no es suficiente! $s% se previenen

problemas ue pueden surgir a largo pla&o y se obtiene un beneficio ue afecta

directamente al producto!

8/19/2019 UML Proceso de Pruebas

3/10

REQUERIMIENTOS COMO FUENTE DE PRUEBAS

'a emos visto cómo podemos, y debemos, utili&ar  los reuerimientos como

fuente de casos de prueba! "a obligación surge de la necesidad de verificar ue la

implementación satisface los reuerimientos!

UM" sólo eige ue los reuerimientos est*n descritos en lenguaje informal y ya

en el curso emos visto los problemas asociados a especificaciones en lenguaje

informal: necesidad de reagrupamiento de reuerimientos, incompletitud,

ambig+edad e inconsistencia! ambi*n emos visto como podemos anali&ar y

mejorar las especificaciones de los reuerimientos aciendo uso de mecanismos

como las tablas de decisión y cuidado en la eplicitación de un criterio de

verificabilidad!

MODELO DE USO COMO FUENTE DE PRUEBAS

El Modelo de Uso le describe al usuario cómo utili&ar el sistema, poor lo ue

mucas veces constituye el n-cleo del manual del usuario! En principio tanto el

modelo de uso como el manual del usuario pueden servir de base para acer 

pruebas de ue la implementación se usa de acuerdo con ellos!

Cada caso de uso describe una tarea ue debe llevar a cabo un actor; por lo ue

pueden generarse casos de prueba para validar ue las tareas se llevan a cabo

seg-n lo indica el caso de uso! El caso de uso es una narrativa en lenguaje

informal, con los consabidos inconvenientes ue esto trae! $dicionalmente el caso

de uso describe un flujo de control ue describe u* pasos pueden repetirse,

cu.les son opcionales, u* cursos alternos ay: flujos ue deben probarse! /!

0acobson fue el primero en proponer ue se generen los siguientes casos de

prueba:

1! Casos correspondientes al curso normal del caso;2! Casos correspondientes a cursos ecepcionales;3! Casos ue surgen de reuerimientos espec%ficos a un item del caso de uso;4! Casos asociados a la prueba de caracter%sticas descritas en documentos

asociados al caso de uso!

Esta propuesta no constituye una estrategia, sino a lo sumo una descripción de

ciertos principios generales ue debe cumplir una clase de estrategias ra&onables!

 $dicionalmente, considero ue es preferible generar los casos tipo 3, a partir de

otros artefactos, como por ejemplo los contratos, si estos se utili&an!

http://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testReqs.html

8/19/2019 UML Proceso de Pruebas

4/10

5inder propone construir tablas de decisión para cada caso de uso, usando

variables operacionales como variables de decisión y generar los casos de

pruebas seg-n las estrategias o modelos de defectos asociados a tablas de

decisión! Una variable operacional es visible en la frontera del sistema, y

t%picamente es una entrada o salida del sistema o abstrae parte del estado del

sistema!

En la pr.ctica las narrativas de los casos de uso describen inteligiblemente flujos

sencillos de control; las tablas de decisión permiten manejar inteligiblemente un

alto n-mero de opciones con poca dependencia sobre el estado del sistema! #in

embargo, para flujos de cierta complejidad es conveniente recurrir a un autómata

de interacción! Este autómata puede tener un componente informal (t%picamente a

este nivel, las acciones se describen informalmente a bastante alto nivel), pero el

eco de precisar el flujo, permite aplicar las estrategias de generación de casos

de prueba a partir de autómatas, probablemente con ciertas dificultades para

precisar el estado en ue se encuentra o ueda el sistema, as% como ue se

llevaron a cabo las acciones asociadas a las transiciones correctamente!

MODELO CONCEPTUAL COMO FUENTE DE PRUEBAS

6o es conveniente usar el modelo conceptual como fuente de pruebas! "a

implementación eventualmente cumple es con el Modelo de Clases, por lo ue es

conveniente ue se utilice el Modelo de Clases como fuente de pruebas!

/dealmente debe eistir una correspondencia epl%cita y verificable entre elModelo Conceptual y el Modelo de Clases; en la pr.ctica esta correspondencia

suele estar documentada parcialmente y su verificabilidad es reali&able sólo

mediante inspecciones informales!

MODELO DE CLASES COMO FUENTE DE PRUEBAS

"os defectos a los ue est. propensa la implementación de un modelo de clases

incluyen:

• Errores en la multiplicidad de la asociación;

• 7alta o sobra una asociación;

•  $ctuali&ación anómala, t%picamente en la actuali&ación de información

replicada;

• Eliminación anómala, como por ejemplo:

http://ldc.usb.ve/~teruel/ci4713/clases2001/testAutomata.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testAutomata.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testAutomata.htmlhttp://ldc.usb.ve/~teruel/ci4713/clases2001/testAutomata.html

8/19/2019 UML Proceso de Pruebas

5/10

• En la eliminación de un objeto ue ayuda a definir una entidad d*bil;

• En la eliminación de un objeto ue pertenece a una asociación 1 a 6 (por el

lado del 1);

• En el manejo de nulificaciones (nullifies), cascadas y restricciones;

•  $sociaciones incorrectas entre objetos;

• /nserciones incorrectas;

• En general, no se satisfacen las restricciones de integridad!

5inder proporciona un ejemplo interesante! #upongamos ue eisten dos

clases 8ersona y 8erro, cuya asociación es due9o ue permite ue cada perro

tenga a lo sumo un due9o y ue cada persona pueda tener cero o m.s perros!

Esta asociación puede implementarse de las siguientes formas:

"imit.ndose a dos clases (8ersona, 8erro), 6ote ue esta implementación es poco

elegante en su manejo de apuntadores a otras clases (sobre todo en la

clase 8erro, ue reuiere referenciar una persona y al próimo perro ue comparteel mismo due9o)!

Usando tres clases (8ersona, 8erro, Es ue9o e)!

Usando tres clases (8ersona, 8erro, ue9o)! En este caso la clase ue9o puede

contener un atributo 8ersona y un atributo tipo vector o colección de 8erro! Cuatro

clases: 8ersona, 8erro, ue9o (una interfa&),

eamos cómo lucir%an, en este ejemplo, algunos de los defectos mencionados

previamente:

• Errores en la multiplicidad de la asociación!

• Erróneamente se permite ue dos personas sean due9as del mismo perro!

•

7alta una asociación!

• ado un due9o podemos obtener sus perros, pero por error en la

implementación no ay forma (eficiente) de encontrar el due9o de un perro!

8/19/2019 UML Proceso de Pruebas

6/10

•  $ctuali&ación anómala!

#i cada objeto 8erro incluye su propio objeto 8ersona ue es su due9o, el

due9o de cinco perros aparece replicado cinco veces!

• Eliminación anómala!

#i eliminamos el due9o, u* pasa con sus perros:o #i la eliminación es con nulificación, los perros dejan de tener due9o;

o #i la eliminación fuer&a una cascada, los perros se eliminan (irreal);

•  $sociaciones incorrectas entre objetos;

El sistema incorrectamente registra a como el due9o del perro y, en ve& del

perro &!

5inder propone la siguiente estrategia de generación de casos de pruebas:

• Considere la multiplicidad como una condición! $pl%uele el modelo de

defectos de fronteras de un rango, recordando ue en la pr.ctica una

multiplicidad 1!!?, tiene un m.imo implementado!

• 8ara detectar problemas de consistencia en la actuali&ación de objetos

replicados en asociaciones i!!?, cree una instancia de la asociación asoc demultiplicidad i!!n (con n@2)! $ctualice los i objetos de las asociación y liste la

información asociada a todos los elementos del conjunto obji!asoc!asocA

1 para revisar ue fueron actuali&ados consistentemente! $s% en el ejemplo

mencionado se debe generar un due9o de, digamos cinco perros, actuali&ar 

la información del due9o y revisar si la información asociada al due9o de

cada uno de esos cinco perros es igual!

• 8ara detectar problemas con la eliminación del objeto fuente de una

asociación 1!!?:1! Cree una asociación 1!!n(con n@2),

2! Elimine el objeto fuente y revise ue pasó con los objetos destinos!3! uelva a crear la asociación y borre los n objetos destino y revise u* pasó

con el objeto fuente!4! Elimine el objeto fuente y revise a ver si todos los objetos y la asociación

fueron eliminados!

8/19/2019 UML Proceso de Pruebas

7/10

En general propongo ue todas las restricciones de integridad deben considerarse

como predicados y deben generarse los casos de prueba sugeridos por los

modelos de defectos ue se escojan para esos predicados!

CONTRATOS COMO FUENTE DE PRUEBAS

8ueden aplicarse los modelos de defectos pertinentes sobre las precondiciones y

pos condiciones de los contratos! "a visibilidad de las salidas (recuerde ue las

salidas de un contrato especifican u* objetos y asociaciones se crean, modifican

o eliminan) puede reuerir escribir código especial para las pruebas!

En principio luce atractivo desarrollar una erramienta de apoyo a este tipo de

pruebas ue valide la ejecución de una implementación de un evento de sistema

contra el contrato!

DIAGRAMAS DE COLABORACIÓN COMO FUENTE DE PRUEBAS

"a implementación de un evento de sistema debe cumplir con su diagrama de

colaboración! 8ara revisar si efectivamente cumple, deber%a ejecutarse la

implementación, revisando ue los mensajes enviados corresponden a lo indicado

por el diagrama de colaboración! /dealmente se deber%a determinar las secuencias

de mensajes esperados y luego comparar estas secuencias contra las tra&as o

secuencias generadas por la implementación! 6ótese ue ay erramientas ue

generan estas tra&as, indicando no sólo el mensaje sino el objeto ue env%a y el

objeto ue recibe!

Benerar manualmente las tra&as esperadas a partir de los diagramas de

colaboración, no necesariamente es factible! El problema radica en ue los

diagramas de colaboración no especifican cómo cambia el estado de un objeto al

recibir un mensaje m! 8or ende si ese objeto env%a mensajes m1, m2 como parte

de la reacción a m, pero sólo si se satisface una guarnición ue depende del

estado del objeto, es muy probable ue sea imposible determinar el estado: en

consecuencia no es posible determinar si m1, m2 deben agregarse a la tra&a

esperada! Este problema sólo se resuelve si se reali&a alguna de las siguientes

acciones:

#e especifican los cambios al estado ocurrido como reacción a la recepción de un

mensaje y previo a cada env%o de un mensaje de reacción! $dicionalmente ace

falta especificar los par.metros y respuestas asociadas a los mensajes, ya ue las

guarniciones pueden depender de sus valores!

8/19/2019 UML Proceso de Pruebas

8/10

 

#e puedan ejecutar los diagramas de colaboración a la par ue la implementación,

tomando valores de la implementación cuando sean necesarios! 6o tengo

información ue tal erramienta eista!

Esto sugiere la posibilidad de invertir el orden de determinación de las tra&as! Es

decir, primero generar las tra&as de la implementación, junto con los valores de

las guarniciones asociadas a cada elemento de la tra&a! Esto permitir%a verificar 

ue la tra&a esperada o anticipada por el diagrama de colaboración es el mismo

ue la tra&a generada por la implementación! =esultado de las guarniciones! Una

erramienta de apoyo a esta actividad deber%a instrumentar el código de la

implementación apropiadamente: nuevamente no cono&co erramienta ue apoye

esta tarea!

asta aora se a sugerido generar casos de prueba a partir de la estructura de

los par.metros del evento del sistema, es decir la generación de los casos utili&an

una estrategia caja negra respecto al diagrama de colaboración! #in embargo, el

diagrama de colaboración puede verse como un diagrama de flujo de alto nivel,

donde las guarniciones corresponden a puntos de decisión! 8or ende podemos

generar casos de prueba caja blanca para lograr una cierta cobertura del grafo

asociado al diagrama de colaboración! Es conveniente acer notar ue sospeco

ue controlar las entradas de estos casos de prueba puede ser sumamente dif%cil!

5inder es muy pesimista respecto a la utilidad de los diagramas de colaboración

en el proceso de prueba AADy el proceso de dise9o Mucas de sus cr%ticas son

igualmente v.lidas para cualuier otro artefacto de dise9o, como veremos!

8/19/2019 UML Proceso de Pruebas

9/10

CONCLUSIÓN

En general, los -nicos roles ue se usan en un iagrama de Colaboración son

cuando se omite el nombre de un objeto! Esto ocurre cuando ay un sólo objeto

de esa clase, o cuando se trata de un objeto tipo Cat.logo ue fue introducido

para apoyar la implementación eficiente de una asociación conceptual! Consideroue estos roles constituyen abreviaciones en contetos bien delimitados ue no

representan dificultades significativas!

odo artefacto de dise9o representa una abstracción ue puede llevar a confusión

entre abstracción e implementación; no veo ue el diagrama de colaboración sea

m.s o menos propenso a conducir a esta confusión ue otros artefactos! El

diagrama de colaboración representa un punto intermedio entre un contrato y la

implementación, punto -til para reducir el tama9o del paso entre los otros dos

artefactos! En mi eperiencia, el diagrama de colaboración es muy -til para

identificar donde introducir patrones de dise9o; algunos de mis compa9eros anencontrado ue es un artefacto -til en las discusiones entre programadores! 8or 

supuesto ue cualuier artefacto de dise9o puede usarse para acer dise9os

deficientes y dise9os etraordinarios, pues estos artefactos son erramientas cuyo

buen o mal manejo depende tambi*n de cómo y ui*n las maneja!

8/19/2019 UML Proceso de Pruebas

10/10

BIBLIOGRAFÍA

B!"#!$%&'()'Binder, R. (2000). Sistemas orientados a objetos, modelos y herramientas

software. España Addis!n"#es$e%.