• Author / Uploaded
• Jesus Vidal

Citation preview

INSTITUTO TECNOLÓGICO SUPERIOR DE TIERRA BLANCA DOCENTE

MARIA DEL ROSARIO MORENO FERNANDEZ TRABAJO

UML Y EL PROCESO DE PRUEBAS ESTUDIANTE

JESUS VIDAL RODRIGUEZ CARRERA

INGENIERÍA EN SISTEMAS COMPUTACIONALES MATERIA

VERIFICACIÓN Y VALIDACION DE SOFTWARE UNIDAD 1

TIERRA BLANCA, VER. 03 DE MARZO DE 2016 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 requerimientos. Los modelos son, por definición, complementarios. Se presentan varios modelos porque, en general, cumplir uno sólo 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 cómo podemos, y debemos, utilizar los requerimientos como fuente de casos de prueba. La obligación surge de la necesidad de verificar que la implementación satisface los requerimientos. UML sólo exige que los requerimientos estén 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, ambigüedad e inconsistencia. También hemos visto como podemos analizar y mejorar las especificaciones de los requerimientos haciendo uso de mecanismos como las tablas de decisión y cuidado en la explicitación de un criterio de verificabilidad.

MODELO DE USO COMO FUENTE DE PRUEBAS El Modelo de Uso le describe al usuario cómo utilizar el sistema, poor lo que muchas 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 hacer pruebas de que la implementación 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 según 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, cuáles 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 específicos a un item del caso de uso; 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 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 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. Sin 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 hecho 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 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 implementación 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 explícita y verificable entre el Modelo Conceptual y el Modelo de Clases; en la práctica esta correspondencia suele estar documentada parcialmente y su verificabilidad es realizable sólo mediante inspecciones informales.

MODELO DE CLASES COMO FUENTE DE PRUEBAS Los defectos a los que está propensa la implementación de un modelo de clases incluyen:    

Errores en la multiplicidad de la asociación; Falta o sobra una asociación; Actualización anómala, típicamente en la actualización de información replicada; Eliminación anómala, como por ejemplo:

     

En la eliminación de un objeto que ayuda a definir una entidad débil; En la eliminación de un objeto que pertenece a una asociación 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 asociación es dueño que permite que cada perro tenga a lo sumo un dueño y que cada persona pueda tener cero o más perros. Esta asociación puede implementarse de las siguientes formas: Limitándose a dos clases (Persona, Perro), Note que esta implementación es poco elegante en su manejo de apuntadores a otras clases (sobre todo en la clase Perro, que requiere referenciar una persona y al próximo perro que comparte el mismo dueño). Usando tres clases (Persona, Perro, Es Dueño De). Usando tres clases (Persona, Perro, Dueño). En este caso la clase Dueño puede contener un atributo Persona y un atributo tipo vector o colección de Perro. Cuatro clases: Persona, Perro, Dueño (una interfaz), Veamos 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 que dos personas sean dueñas del mismo perro. Falta una asociación.



Dado un dueño podemos obtener sus perros, pero por error en la implementación no hay forma (eficiente) de encontrar el dueño de un perro.



Actualización anómala. Si cada objeto Perro incluye su propio objeto Persona que es su dueño, el dueño de cinco perros aparece replicado cinco veces. ¿Recordaremos actualizar las cinco réplicas al modificar alguna de ellas?



Eliminación anómala.

Si eliminamos el dueño, qué pasa con sus perros: o Si la eliminación es con nulificación, los perros dejan de tener dueño; o Si la eliminación fuerza una cascada, los perros se eliminan (irreal);  Asociaciones incorrectas entre objetos; El sistema incorrectamente registra a x como el dueño del perro y, en vez del perro z. Binder propone la siguiente estrategia de generación de casos de pruebas: 



 1. 2. 3. 4.

Considere la multiplicidad como una condición. Aplíquele el modelo de defectos de fronteras de un rango, recordando que en la práctica una multiplicidad 1..*, tiene un máximo implementado. Para detectar problemas de consistencia en la actualización de objetos replicados en asociaciones i..*, cree una instancia de la asociación asoc de multiplicidad i..n (con n>2). Actualice los i objetos de las asociación y liste la información 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 dueño de, digamos cinco perros, actualizar la información del dueño y revisar si la información asociada al dueño de cada uno de esos cinco perros es igual. Para detectar problemas con la eliminación del objeto fuente de una asociación 1..*: Cree una asociación 1..n(con n>2), Elimine el objeto fuente y revise que pasó con los objetos destinos. Vuelva a crear la asociación 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 asociación 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 código especial para las pruebas. En principio luce atractivo desarrollar una herramienta de apoyo a este tipo de pruebas que valide la ejecución de una implementación de un evento de sistema contra el contrato.

DIAGRAMAS DE COLABORACIÓN COMO FUENTE DE PRUEBAS La implementación de un evento de sistema debe cumplir con su diagrama de colaboración. Para revisar si efectivamente cumple, debería ejecutarse la implementación, revisando que los mensajes enviados corresponden a lo indicado por el diagrama de colaboración. Idealmente se debería determinar las secuencias de mensajes esperados y luego comparar estas secuencias contra las trazas o secuencias generadas por la implementación. Nótese que hay herramientas que generan estas trazas, indicando no sólo el mensaje sino el objeto que envía y el objeto que recibe. Generar manualmente las trazas esperadas a partir de los diagramas de colaboración, no necesariamente es factible. El problema radica en que los diagramas de colaboración no especifican cómo cambia el estado de un objeto al recibir un mensaje m. Por 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 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 sólo se resuelve si se realiza alguna de las siguientes acciones: Se 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. Adicionalmente hace falta especificar los parámetros y respuestas asociadas a los mensajes, ya que las guarniciones pueden depender de sus valores.

Se puedan ejecutar los diagramas de colaboración a la par que la implementación, tomando valores de la implementación cuando sean necesarios. No tengo información que tal herramienta exista. Esto sugiere la posibilidad de invertir el orden de determinación de las trazas. Es decir, primero generar las trazas de la implementación, junto con los valores de las guarniciones asociadas a cada elemento de la traza. Esto permitiría verificar que la traza esperada o anticipada por el diagrama de colaboración es el mismo que la traza generada por la implementación. Resultado de las guarniciones. Una herramienta de apoyo a esta actividad debería instrumentar el código de la implementación 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 parámetros del evento del sistema, es decir la generación de los casos utilizan una estrategia caja negra respecto al diagrama de colaboración. Sin 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. Por ende podemos generar casos de prueba caja blanca para lograr una cierta cobertura del grafo asociado al diagrama de colaboración. Es conveniente hacer notar que sospecho que controlar las entradas de estos casos de prueba puede ser sumamente difícil. Binder es muy pesimista respecto a la utilidad de los diagramas de colaboración en el proceso de prueba --¡y el proceso de diseño! Muchas de sus críticas son igualmente válidas para cualquier otro artefacto de diseño, como veremos.

CONCLUSIÓN En general, los únicos roles que se usan en un Diagrama de Colaboración son cuando se omite el nombre de un objeto. Esto ocurre cuando hay un sólo objeto de esa clase, o cuando se trata de un objeto tipo Catálogo que fue introducido para apoyar la implementación eficiente de una asociación conceptual. Considero que estos roles constituyen abreviaciones en contextos bien delimitados que no representan dificultades significativas. Todo artefacto de diseño representa una abstracción que puede llevar a confusión entre abstracción e implementación; no veo que el diagrama de colaboración sea más o menos propenso a conducir a esta confusión que otros artefactos. El diagrama de colaboración representa un punto intermedio entre un contrato y la implementación, punto útil para reducir el tamaño del paso entre los otros dos artefactos. En mi experiencia, el diagrama de colaboración es muy útil para identificar donde introducir patrones de diseño; algunos de mis compañeros han encontrado que es un artefacto útil en las discusiones entre programadores. Por supuesto que cualquier artefacto de diseño puede usarse para hacer diseños deficientes y diseños extraordinarios, pues estos artefactos son herramientas cuyo buen o mal manejo depende también de cómo y quién las maneja.

BIBLIOGRAFÍA

Bibliografía Binder, R. (2000). Sistemas orientados a objetos, modelos y herramientas software. España: Addison-Wesley.