INSTITUTO TECNOLGICO

SUPERIOR DE TIERRA
BLANCA
DOCENTE

MARIA DEL ROSARIO MORENO

FERNANDEZ
TRABAJO

UML Y EL PROCESO DE PRUEBAS

ESTUDIANTE

JESUS VIDAL RODRIGUEZ

CARRERA

INGENIERA EN SISTEMAS
COMPUTACIONALES
MATERIA

VERIFICACIN Y VALIDACION DE
SOFTWARE
UNIDAD 1

TIERRA BLANCA, VER. 03 DE MARZO DE

2016
INTRODUCCIN
En general, la implementacin 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 requerimientos.
Los modelos son, por definicin, complementarios. Se presentan varios modelos
porque, en general, cumplir uno slo de ellos no es suficiente. As se previenen
problemas que pueden surgir a largo plazo y se obtiene un beneficio que afecta
directamente al producto.

REQUERIMIENTOS COMO FUENTE DE PRUEBAS

Ya hemos visto cmo podemos, y debemos, utilizar los requerimientos como
fuente de casos de prueba. La obligacin surge de la necesidad de verificar que la
implementacin satisface los requerimientos.
UML slo exige que los requerimientos estn descritos en lenguaje informal y ya
en el curso hemos visto los problemas asociados a especificaciones en lenguaje
informal: necesidad de reagrupamiento de requerimientos, incompletitud,
ambigedad e inconsistencia. Tambin hemos visto como podemos analizar y
mejorar las especificaciones de los requerimientos haciendo uso de mecanismos
como las tablas de decisin y cuidado en la explicitacin de un criterio de
verificabilidad.

MODELO DE USO COMO FUENTE DE PRUEBAS

El Modelo de Uso le describe al usuario cmo utilizar el sistema, poor lo que
muchas veces constituye el ncleo del manual del usuario. En principio tanto el
modelo de uso como el manual del usuario pueden servir de base para hacer
pruebas de que la implementacin se usa de acuerdo con ellos.
Cada caso de uso describe una tarea que debe llevar a cabo un actor; por lo que
pueden generarse casos de prueba para validar que las tareas se llevan a cabo
segn lo indica el caso de uso. El caso de uso es una narrativa en lenguaje
informal, con los consabidos inconvenientes que esto trae. Adicionalmente el caso
de uso describe un flujo de control que describe qu pasos pueden repetirse,
cules son opcionales, qu cursos alternos hay: flujos que deben probarse. I.
Jacobson fue el primero en proponer que se generen los siguientes casos de
prueba:
1.
2.
3.
4.

Casos correspondientes al curso normal del caso;

Casos correspondientes a cursos excepcionales;
Casos que surgen de requerimientos especficos a un item del caso de uso;
Casos asociados a la prueba de caractersticas descritas en documentos
asociados al caso de uso.

Esta propuesta no constituye una estrategia, sino a lo sumo una descripcin de

ciertos principios generales que debe cumplir una clase de estrategias razonables.
Adicionalmente, considero que es preferible generar los casos tipo 3, a partir de
otros artefactos, como por ejemplo los contratos, si estos se utilizan.

Binder propone construir tablas de decisin para cada caso de uso, usando
variables operacionales como variables de decisin y generar los casos de
pruebas segn las estrategias o modelos de defectos asociados a tablas de
decisin. Una variable operacional es visible en la frontera del sistema, y
tpicamente es una entrada o salida del sistema o abstrae parte del estado del
sistema.
En la prctica las narrativas de los casos de uso describen inteligiblemente flujos
sencillos de control; las tablas de decisin permiten manejar inteligiblemente un
alto nmero de opciones con poca dependencia sobre el estado del sistema. Sin
embargo, para flujos de cierta complejidad es conveniente recurrir a un autmata
de interaccin. Este autmata puede tener un componente informal (tpicamente a
este nivel, las acciones se describen informalmente a bastante alto nivel), pero el
hecho de precisar el flujo, permite aplicar las estrategias de generacin de casos
de prueba a partir de autmatas, probablemente con ciertas dificultades para
precisar el estado en que se encuentra o queda el sistema, as como que se
llevaron a cabo las acciones asociadas a las transiciones correctamente.

MODELO CONCEPTUAL COMO FUENTE DE PRUEBAS

No es conveniente usar el modelo conceptual como fuente de pruebas. La
implementacin eventualmente cumple es con el Modelo de Clases, por lo que es
conveniente que se utilice el Modelo de Clases como fuente de pruebas.
Idealmente debe existir una correspondencia explcita y verificable entre el
Modelo Conceptual y el Modelo de Clases; en la prctica esta correspondencia
suele estar documentada parcialmente y su verificabilidad es realizable slo
mediante inspecciones informales.

MODELO DE CLASES COMO FUENTE DE PRUEBAS

Los defectos a los que est propensa la implementacin de un modelo de clases
incluyen:

Errores en la multiplicidad de la asociacin;

Falta o sobra una asociacin;
Actualizacin anmala, tpicamente en la actualizacin de informacin
replicada;
Eliminacin anmala, como por ejemplo:

En la eliminacin de un objeto que ayuda a definir una entidad dbil;

En la eliminacin de un objeto que pertenece a una asociacin 1 a N (por el
lado del 1);
En el manejo de nulificaciones (nullifies), cascadas y restricciones;
Asociaciones incorrectas entre objetos;
Inserciones incorrectas;
En general, no se satisfacen las restricciones de integridad.

Binder proporciona un ejemplo interesante. Supongamos que existen dos

clases Persona y Perro, cuya asociacin es dueo que permite que cada perro
tenga a lo sumo un dueo y que cada persona pueda tener cero o ms perros.
Esta asociacin puede implementarse de las siguientes formas:
Limitndose a dos clases (Persona, Perro), Note que esta implementacin es poco
elegante en su manejo de apuntadores a otras clases (sobre todo en la
clase Perro, que requiere referenciar una persona y al prximo perro que comparte
el mismo dueo).
Usando tres clases (Persona, Perro, Es Dueo De).
Usando tres clases (Persona, Perro, Dueo). En este caso la clase Dueo puede
contener un atributo Persona y un atributo tipo vector o coleccin de Perro. Cuatro
clases: Persona, Perro, Dueo (una interfaz),
Veamos cmo luciran, en este ejemplo, algunos de los defectos mencionados
previamente:

Errores en la multiplicidad de la asociacin.

Errneamente se permite que dos personas sean dueas del mismo perro.
Falta una asociacin.

Dado un dueo podemos obtener sus perros, pero por error en la

implementacin no hay forma (eficiente) de encontrar el dueo de un perro.

Actualizacin anmala.
Si cada objeto Perro incluye su propio objeto Persona que es su dueo, el
dueo de cinco perros aparece replicado cinco veces. Recordaremos
actualizar las cinco rplicas al modificar alguna de ellas?

Eliminacin anmala.

Si eliminamos el dueo, qu pasa con sus perros:

o Si la eliminacin es con nulificacin, los perros dejan de tener dueo;
o Si la eliminacin fuerza una cascada, los perros se eliminan (irreal);
Asociaciones incorrectas entre objetos;
El sistema incorrectamente registra a x como el dueo del perro y, en vez del
perro z.
Binder propone la siguiente estrategia de generacin de casos de pruebas:

1.
2.
3.
4.

Considere la multiplicidad como una condicin. Aplquele el modelo de

defectos de fronteras de un rango, recordando que en la prctica una
multiplicidad 1..*, tiene un mximo implementado.
Para detectar problemas de consistencia en la actualizacin de objetos
replicados en asociaciones i..*, cree una instancia de la asociacin asoc de
multiplicidad i..n (con n>2). Actualice los i objetos de las asociacin y liste la
informacin asociada a todos los elementos del conjunto obji.asoc.asoc1 para revisar que fueron actualizados consistentemente. As en el ejemplo
mencionado se debe generar un dueo de, digamos cinco perros, actualizar
la informacin del dueo y revisar si la informacin asociada al dueo de
cada uno de esos cinco perros es igual.
Para detectar problemas con la eliminacin del objeto fuente de una
asociacin 1..*:
Cree una asociacin 1..n(con n>2),
Elimine el objeto fuente y revise que pas con los objetos destinos.
Vuelva a crear la asociacin y borre los n objetos destino y revise qu pas
con el objeto fuente.
Elimine el objeto fuente y revise a ver si todos los objetos y la asociacin
fueron eliminados.

En general propongo que todas las restricciones de integridad deben considerarse

como predicados y deben generarse los casos de prueba sugeridos por los
modelos de defectos que se escojan para esos predicados.

CONTRATOS COMO FUENTE DE PRUEBAS

Pueden aplicarse los modelos de defectos pertinentes sobre las precondiciones y
pos condiciones de los contratos. La visibilidad de las salidas (recuerde que las
salidas de un contrato especifican qu objetos y asociaciones se crean, modifican
o eliminan) puede requerir escribir cdigo especial para las pruebas.
En principio luce atractivo desarrollar una herramienta de apoyo a este tipo de
pruebas que valide la ejecucin de una implementacin de un evento de sistema
contra el contrato.

DIAGRAMAS DE COLABORACIN COMO FUENTE DE PRUEBAS

La implementacin de un evento de sistema debe cumplir con su diagrama de
colaboracin. Para revisar si efectivamente cumple, debera ejecutarse la
implementacin, revisando que los mensajes enviados corresponden a lo indicado
por el diagrama de colaboracin. Idealmente se debera determinar las secuencias
de mensajes esperados y luego comparar estas secuencias contra las trazas o
secuencias generadas por la implementacin. Ntese que hay herramientas que
generan estas trazas, indicando no slo el mensaje sino el objeto que enva y el
objeto que recibe.
Generar manualmente las trazas esperadas a partir de los diagramas de
colaboracin, no necesariamente es factible. El problema radica en que los
diagramas de colaboracin no especifican cmo cambia el estado de un objeto al
recibir un mensaje m. Por ende si ese objeto enva mensajes m1, m2 como parte
de la reaccin a m, pero slo si se satisface una guarnicin que depende del
estado del objeto, es muy probable que sea imposible determinar el estado: en
consecuencia no es posible determinar si m1, m2 deben agregarse a la traza
esperada. Este problema slo se resuelve si se realiza alguna de las siguientes
acciones:
Se especifican los cambios al estado ocurrido como reaccin a la recepcin de un
mensaje y previo a cada envo de un mensaje de reaccin. Adicionalmente hace
falta especificar los parmetros y respuestas asociadas a los mensajes, ya que las
guarniciones pueden depender de sus valores.

Se puedan ejecutar los diagramas de colaboracin a la par que la implementacin,

tomando valores de la implementacin cuando sean necesarios. No tengo
informacin que tal herramienta exista.
Esto sugiere la posibilidad de invertir el orden de determinacin de las trazas. Es
decir, primero generar las trazas de la implementacin, junto con los valores de
las guarniciones asociadas a cada elemento de la traza. Esto permitira verificar
que la traza esperada o anticipada por el diagrama de colaboracin es el mismo
que la traza generada por la implementacin. Resultado de las guarniciones. Una
herramienta de apoyo a esta actividad debera instrumentar el cdigo de la
implementacin apropiadamente: nuevamente no conozco herramienta que apoye
esta tarea.

Hasta ahora se ha sugerido generar casos de prueba a partir de la estructura de

los parmetros del evento del sistema, es decir la generacin de los casos utilizan
una estrategia caja negra respecto al diagrama de colaboracin. Sin embargo, el
diagrama de colaboracin puede verse como un diagrama de flujo de alto nivel,
donde las guarniciones corresponden a puntos de decisin. Por ende podemos
generar casos de prueba caja blanca para lograr una cierta cobertura del grafo
asociado al diagrama de colaboracin. Es conveniente hacer notar que sospecho
que controlar las entradas de estos casos de prueba puede ser sumamente difcil.
Binder es muy pesimista respecto a la utilidad de los diagramas de colaboracin
en el proceso de prueba --y el proceso de diseo! Muchas de sus crticas son
igualmente vlidas para cualquier otro artefacto de diseo, como veremos.

CONCLUSIN
En general, los nicos roles que se usan en un Diagrama de Colaboracin son
cuando se omite el nombre de un objeto. Esto ocurre cuando hay un slo objeto
de esa clase, o cuando se trata de un objeto tipo Catlogo que fue introducido
para apoyar la implementacin eficiente de una asociacin conceptual. Considero
que estos roles constituyen abreviaciones en contextos bien delimitados que no
representan dificultades significativas.
Todo artefacto de diseo representa una abstraccin que puede llevar a confusin
entre abstraccin e implementacin; no veo que el diagrama de colaboracin sea
ms o menos propenso a conducir a esta confusin que otros artefactos. El
diagrama de colaboracin representa un punto intermedio entre un contrato y la
implementacin, punto til para reducir el tamao del paso entre los otros dos
artefactos. En mi experiencia, el diagrama de colaboracin es muy til para
identificar donde introducir patrones de diseo; algunos de mis compaeros han
encontrado que es un artefacto til en las discusiones entre programadores. Por
supuesto que cualquier artefacto de diseo puede usarse para hacer diseos
deficientes y diseos extraordinarios, pues estos artefactos son herramientas cuyo
buen o mal manejo depende tambin de cmo y quin las maneja.

BIBLIOGRAFA

Bibliografa
Binder, R. (2000). Sistemas orientados a objetos, modelos y herramientas
software. Espaa: Addison-Wesley.