1

Instituto de Computación – Facultad de Ingeniería – Universidad de la República

Automatización de Generación de Casos

de Prueba Informe Final de Proyecto de Grado

Proyecto de Grado 2011

Estudiante: Rodrigo Santana

Supervisor: Mónica Wodzislawski

Usuario Responsable: Pablo López - Tilsor, Rodrigo López - Tilsor

2

Resumen Este documento presenta el trabajo realizado en la asignatura Proyecto de Grado de la carrera Ingeniería en Computación de la UDELAR. Fue supervisado por la docente Mónica Wodzislawski del Instituto de Computación de la Facultad de Ingeniería (UDELAR), y tiene como contraparte externa la empresa Tilsor S.A. Por Tilsor S.A los usuarios responsables fueron los Ingenieros Pablo López y Rodrigo López. El objetivo de este proyecto ha sido crear una herramienta, denominada TestCU, que genera automáticamente un conjunto de casos de prueba abstractos para probar un caso de uso especificado en el lenguaje formal LFTestCU. Este lenguaje formal fue creado también en este proyecto, por no encontrarse en la investigación un lenguaje formal para especificar casos de uso. TestCU devuelve el conjunto de casos de prueba abstractos generados en una planilla Excel. Inicialmente se presentan en el Estado del Arte una introducción a las Pruebas de Software, una introducción a los Casos de Uso, la prueba de Casos de Uso, y el conjunto de las técnicas de procesamiento de Casos de Uso investigadas. A continuación en una revisión de las técnicas se describen: (a) las ideas tomadas para diseñar la solución, y (b) las decisiones de diseño. Posteriormente se describen la arquitectura y los componentes que componen TestCU. Por último, a través de un caso de estudio se ilustra la especificación de un caso de uso en LFTestCU y el procedimiento que ejecuta TestCU para generar el conjunto de los casos de prueba abstractos. Palabras claves: Caso de Uso, Prueba de los Casos de Uso, Lenguaje Formal, Caso de Prueba Abstracto.

3

Índice

Introducción ............................................................................................................. 5 1 Estado del Arte ................................................................................................. 8

1.1 Introducción a las Pruebas de Software ..................................................... 8 1.2 Introducción a los Casos de Uso .............................................................. 10 1.3 Introducción a la Prueba de los Casos de Uso ........................................ 11

1.4 Técnicas de Procesamiento de Casos de Uso ......................................... 13 1.4.1 Proceso ETUC ................................................................................... 13 1.4.2 Caso de Uso Extendido ..................................................................... 15 1.4.3 Diagrama de Actividades NDT........................................................... 19 1.4.4 Diagrama de Actividades Extendido .................................................. 25

1.4.5 RUCM (Restricted Use Case Modeling) ............................................ 26 1.4.6 Pruebas dirigidas por modelos usando el perfil de pruebas UML 2.0 30

2 Investigación .................................................................................................. 34

2.1 Ideas Preliminares.................................................................................... 34 2.2 Revisión de las Técnicas .......................................................................... 35

2.2.1 Proceso ETUC ................................................................................... 35

2.2.2 Caso de Uso Extendido ..................................................................... 36 2.2.3 Diagrama de Actividades NDT........................................................... 37 2.2.4 Diagrama de Actividades Extendido .................................................. 38

2.2.5 RUCM (Restricted Use Case Modeling) ............................................ 39 2.2.6 Pruebas dirigidas por modelos usando el perfil de pruebas UML 2.0 41

2.3 Decisiones de Diseño ............................................................................... 41 3 Construcción de TestCU ................................................................................ 43

3.1 LFTestCU ................................................................................................. 44

3.1.1 Aplicación al Ejemplo ......................................................................... 48

3.2 Diagrama de Análisis ............................................................................... 53 3.3 Generación de los CPA ............................................................................ 54 3.4 Arquitectura .............................................................................................. 59

4 Caso de Estudio ............................................................................................. 61 4.1 Especificación en Lenguaje Natural ......................................................... 61

4.2 Descripción utilizando la Plantilla LFTestCU ............................................ 63 4.3 Especificación en LFTestCU .................................................................... 67 4.4 Diagrama de Actividades ......................................................................... 73 4.5 Matriz con los Casos de Prueba Abstractos ............................................. 75

5 Conclusiones y Trabajos a Futuro .................................................................. 81

6 Glosario .......................................................................................................... 84 7 Referencias .................................................................................................... 87 Anexo A – Especificación LFTestCU de Load document from file ........................ 91 Anexo B – Especificación LFTestCU de Retiro ..................................................... 94

Anexo C – Manual de Usuario de TestCU .......................................................... 105

4

Lista de Ilustraciones Ilustración 1: Objetivos del Proyecto Ilustración 2: Las pruebas en el Tiempo Ilustración 3: Caso de Uso Anotarse a un curso Ilustración 4: Paso 1 - Generar los escenarios a probar Ilustración 5: Paso 2 - Identificar variables para escenarios básicos

Ilustración 6: Paso 3 - Caso de prueba con datos Ilustración 7: Proceso ETUC Ilustración 8: Diagrama de Actividades UC-01 Ilustración 9: Plantilla de RUCM Ilustración 10: RUCM, Caso de Uso Disconnect Ilustración 11: Generación de Casos de Prueba usando aToucan Ilustración 12: Información para el Oráculo según el Nivel de las Pruebas

Ilustración 13 Arquitectura del Sistema

Ilustración 14: Comportamiento del Sistema Ilustración 15: Pre y poscondición de OCL Ilustración 16: Arquitectura del Modelo de Pruebas

Ilustración 17: Diagrama de Secuencia del Caso de Prueba Ilustración 18: Diagrama de Actividades - Load document from file Ilustración 19: Arquitectura de TestCU

Ilustración 20: Diagrama de Actividades del CU Retiro Ilustración 21: Interface Gráfica de TestCU

Lista de Tablas Tabla 1: CU Establish Session Tabla 2: CU extendido Establish Session

Tabla 3: Plantilla NDT Tabla 4: Caso de Uso UC-01

Tabla 5: UC-01. Añadir nuevo enlace Tabla 6. Plantilla LFTestCU Tabla 7: Plantilla LFTestCU - Load document from file

Tabla 8: Matríz de los CPA Tabla 9: Plantilla LFTestCU - Retirar

5

Introducción Las pruebas de software (software testing) consisten en la verificación dinámica del comportamiento de un programa dado un conjunto finito de casos de prueba, elegidos apropiadamente del dominio usualmente infinito de las ejecuciones, contra el comportamiento esperado. En esta definición se pueden identificar las palabras claves:

Dinámica, las pruebas siempre implican ejecutar el programa con ciertos datos de entrada. Para ser preciso, el valor de entrada no es suficiente para determinar una prueba, desde que un sistema complejo y no determinista podría reaccionar diferente a la misma entrada, dependiendo del estado del sistema.

Finito, incluso en los programas simples, pueden ser tantos los casos de prueba teóricamente posibles, que una prueba exhaustiva podría requerir meses o años para ejecutarse. La prueba del software siempre implica una compensación entre los recursos limitados y los intrínsecamente ilimitados requerimientos para la prueba.

Elegido, las muchas técnicas de prueba propuestas difieren esencialmente en cómo seleccionan el conjunto de casos de prueba, se debe tener en cuenta que un criterio de selección diferente puede dar lugar a distintos grados de efectividad. La identificación del criterio de selección más apropiado bajo condiciones dadas, es un problema complejo. En la práctica se aplican las técnicas de análisis de riesgo y la habilidad de la ingeniería de las pruebas de software.

Esperado, debe ser posible, aunque no siempre es fácil, decidir si las salidas observadas en la ejecución del programa son aceptables o no, de otra manera el esfuerzo de las pruebas podría ser inútil. El comportamiento observado podría ser chequeado contra las expectativas del usuario (comúnmente a las que se hace referencia en las pruebas de validación), contra una especificación (pruebas para verificación), o, finalmente contra el comportamiento anticipado derivado de los requerimientos implícitos o expectativas razonables.

Esta definición de Pruebas de Software (software testing) se tomó de SWEBOK (Guide to the Software Engineering Body of Knowledge ) [SWEBOK], que es una guía creada por la IEEE Computer Society que busca resumir los conocimientos asociados a la materia Ingeniería de Software. Se puede resumir el procedimiento para probar el comportamiento de un sistema, o sea para diseñar sus pruebas funcionales, en los siguientes tres pasos:

1. Entender el comportamiento del sistema revisando los requerimientos funcionales. Uno de los objetivos de este proyecto es buscar la forma de representar estos requerimientos formalmente utilizando casos de uso (CU).

2. Pensar y diseñar los casos de prueba. Otro de los objetivos del proyecto es investigar la posibilidad de automatizar la generación de los casos de prueba a partir de la especificación formal de los CU.

3. Ejecución de las pruebas. Este paso consiste en la ejecución de los casos de prueba obtenidos en el paso anterior, y la comparación de los resultados

6

de la ejecución con los resultados esperados de los casos de prueba. Es importante destacar que la generación de datos requiere que el sistema a probar esté implementado, porque es necesario el mapeo entre éste y las variables operacionales de los casos de prueba. Una variable operacional (VO) representa un dato relevante en el caso de uso, o sea que puede hacer variar su comportamiento. Los valores de las variables operacionales determinan el resultado del caso de uso. Hay tres tipos de variables, las ingresadas por el usuario, las que determinan el estado del sistema, las que devuelve el sistema.

Análisis de Objetivos y Requerimientos Inicialmente el proyecto consistía en el diseño y construcción de un framework para generar casos de prueba automáticamente, utilizando un conjunto de técnicas de verificación predefinidas a partir de la especificación formal de casos de uso. El framework, denominado Framework TestCU, recibiría como entrada una especificación formal de los casos de uso, y generaría como salida un conjunto de scripts de pruebas en un lenguaje formal (denominados Scripts de Prueba Abstractos). Para generar los scripts de prueba específicos para cada plataforma de ejecución, el framework brindaría una interfaz que el desarrollador debería implementar con el objetivo de adaptar la herramienta a su propia plataforma. Dentro del marco del proyecto, como caso de estudio se construiría una implementación que generaría scripts de prueba en Oracle OpenScript para Oracle Forms sobre la plataforma Oracle Testing Suite. A poco de comenzar el proyecto uno de los dos alumnos tuvo que abandonarlo por razones personales, por lo que hubo que ajustar su alcance. El objetivo del proyecto pasó a ser: (a) diseñar y construir una herramienta, denominada TestCU, que automatizara la generación de un conjunto de casos de prueba abstractos (CPA), a partir de la especificación formal del caso de uso; y (b) decidir el lenguaje formal para especificar los CU. Los CPA son relaciones entre las condiciones de los datos y las salidas esperadas; razón por la que para realizar las pruebas del CU solamente es necesario seleccionar para cada CPA obtenido con TestCU, un conjunto de datos que cumplan con sus condiciones y verificar que al ejecutarlo se cumplen las salidas esperadas. En la Ilustración 1: Objetivos del Proyecto se representa el objetivo inicial del proyecto, Framework TestCU, y se puede observar la relación entre éste y el objetivo actual que se representa con Herramienta TestCU.

7

Ilustración 1: Objetivos del Proyecto

Estructura del Informe En el capítulo 2 se expone el estado del arte, con una introducción a las pruebas de software, una introducción a los casos de uso, y un resumen de cada una de las técnicas de procesamiento de casos de uso investigadas y que además fueron utilizadas en este proyecto. En el capítulo 3 se describen el objetivo de la investigación, las ideas preliminares que se utilizaron como guías de la investigación, se hace una revisión de las técnicas resumidas en el estado del arte para describir la contribución de cada una en el diseño de TestCU, y por último se describen las decisiones de diseño. En el capítulo 4 se describe a muy alto nivel la

8

construcción de TestCU, que incluye: el lenguaje formal para especificar los CU, el diagrama de análisis que se utiliza para modelar el CU, el algoritmo para generar los CPA, y la arquitectura de la solución. En el capítulo 5 se revisa un caso de estudio que se basa en el CU Retiro [iis cu] que se usa en la asignatura Introducción a la Ingeniería de Software de la Facultad de Ingeniería (UDELAR) para introducir a los estudiantes en los CU. Por último, en el capítulo 6 se muestran las conclusiones del proyecto y los posibles trabajos a futuro.

1 Estado del Arte El objetivo de este capítulo es hacer una introducción a los conceptos y técnicas a utilizar en el proyecto.

1.1 Introducción a las Pruebas de Software

Esta sección tiene como objetivo repasar las ideas principales sobre las pruebas del software y en particular las que son usadas en este documento para probar casos de uso. Ideas Básicas sobre las Pruebas El objetivo esencial de las pruebas es encontrar fallas. Una falla (failure) es un comportamiento no deseado del programa bajo prueba Y toda falla es consecuencia de una falta (fault), se entiende la falta como un defecto que puede causar el mal funcionamiento del programa; o sea que la falla es externa, la puede ver el tester, mientras que la falta es interna y puede no generar fallas durante la prueba. Por esta razón las pruebas demuestran la presencia de faltas nunca su ausencia, como lo señaló E.W. Dijkstra [iis VyV]. La Ingeniería de Software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, mantenimiento y operación del software. Debido a que los principios y prácticas de esta disciplina son esenciales para el desarrollo de sistemas grandes, complejos y confiables; las pruebas van tomando cada vez más importancia y protagonismo día a día, garantizando la satisfacción de los requisitos, y permitiendo ahorrar en el tiempo y recursos que lleva el proceso de desarrollo, cuanto antes se descubran las fallas. El tester busca minimizar los casos de prueba maximizando la probabilidad de encontrar faltas. Para esto el tester utiliza técnicas de prueba que definen una forma de construir y seleccionar casos de prueba. Un caso de prueba (test case) es un conjunto de datos de entrada (test data), condiciones de ejecución (pre y pos condiciones) y resultados esperados. Los datos de entrada son aquellos valores que el tester considera que son interesantes para probar el sistema. Pueden proceder de técnicas como particiones de equivalencia, valores límite o conjetura de errores, del conocimiento, experiencia, etc.

9

Se le llama conjunto de prueba (test suite) a un conjunto de casos de prueba, que usualmente se ejecutan en conjunto, y que tienen un propósito y una base de datos en común. El oráculo, es un agente humano o mecánico, que determina si el programa se comportó correctamente en un caso de prueba determinado, produce un veredicto de paso o de fallo. El más común es el oráculo de entrada / salida, que especifica la salida esperada para una entrada específica. Una de las principales dificultades con las que se encuentra la investigación en el área de testing, y que representa un gran obstáculo para avanzar en la automatización completa del proceso de pruebas, es la especificación del oráculo de las pruebas. Clasificación de las Pruebas En función de la utilización o no del conocimiento del código es posible clasificarlas en pruebas de caja negra y pruebas de caja blanca. Las pruebas de caja negra tienen como propósito validar si el comportamiento observado del producto cumple sus especificaciones de requerimientos, y son usadas cuando solo interesa la funcionalidad y no su implementación; el problema clave de estas pruebas es seleccionar un conjunto de prueba con alta probabilidad de hacer fallar al programa, porque porciones enteras de código pueden quedar sin ejecutar. Las pruebas de caja blanca consisten en seleccionar casos de prueba para examinar cada uno de los posibles flujos de ejecución del programa, por lo que su diseño está fuertemente ligado al código fuente, y cerciorarse de que se devuelven los valores de salida adecuados. Con las pruebas de caja blanca se comprueban los flujos de ejecución dentro de cada unidad (función, clase, módulo, etc.), pero también se pueden testear los flujos entre unidades durante la integración, e incluso entre subsistemas, durante las pruebas de sistema. A pesar de que este tipo de pruebas (pruebas de caja blanca) permite diseñar pruebas que cubran una amplia variedad de casos de prueba, podría pasar por alto partes incompletas de la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de todos los flujos de ejecución del código analizado. Las pruebas no se diseñan únicamente al comienzo del proceso de desarrollo, ni tampoco se ejecutan solamente al final de éste; sino que se van diseñando y ejecutando a lo largo del proceso de desarrollo:

Pruebas Unitarias, prueban los módulos o componentes del sistema, se ejecutan durante su desarrollo, y tienen como propósito descubrir las discrepancias entre su especificación y su comportamiento real. El módulo o componente puede ser probado como caja negra y/o caja blanca.

Pruebas de Integración, el propósito es identificar problemas en las interfaces cuando se integran los módulos o componentes para crear sistemas o subsistemas. La integración puede probarse como caja negra y/o caja blanca.

Pruebas Funcionales, el objetivo es comparar el comportamiento observado del software con el comportamiento esperado. Estas pruebas son de caja

10

negra y consideran el software bajo prueba como un conjunto de funcionalidades interrelacionadas.

Prueba del Sistema, comprueba el comportamiento del sistema (compuesto por el hardware y el software), incluyendo los requerimientos no funcionales. Se prueban las interfaces externas, los dispositivos de hardware asociados, o el ambiente de funcionamiento.

Prueba de Aceptación, es la prueba previa a poner en producción el software, y tiene como objetivo verificar que el software está listo y que el usuario final puede realizar las funciones y tareas para las que fue construido.

Ilustración 2: Las pruebas en el Tiempo

¿Cuándo terminar las pruebas? Existen distintos criterios para terminar las pruebas. Uno de los más importantes es que las pruebas se terminan cuando se alcanza la cobertura definida. Un criterio de cobertura permite medir si los casos de prueba han alcanzado el objetivo pre establecido para las pruebas. Por ejemplo entre los criterios de cobertura para probar el código fuente están: cubrir todas las sentencias, cubrir todas las decisiones, cubrir todas las condiciones, cubrir todas las decisiones/condiciones. El conocer la cobertura que un conjunto de casos de prueba alcanza sobre el sistema bajo prueba permite al tester determinar las porciones del sistema que no están siendo recorridas por los casos de prueba.

1.2 Introducción a los Casos de Uso

Los casos de uso describen la forma en que el sistema debe comportarse a partir de la secuencia de acciones e interacciones entre los actores y el sistema, dando un resultado de valor observable para un actor particular.

11

El caso de uso (CU) es un conjunto de escenarios posibles que puede encarar un actor (o varios) con el sistema para el logro de cierto objetivo. El escenario es una forma particular de usar el sistema, un camino a través de un caso de uso. Toda especificación de un caso de uso tiene como datos:

Nombre del caso de uso

Actores. El actor es una entidad externa, persona identificada por un rol o sistema externo, que interactúa con el sistema. En todo caso de uso debe haber un actor primario para el que se cumplen sus objetivos al ejecutar el caso de uso.

Precondiciones. Establecen las condiciones que deben ser siempre verdaderas antes de comenzar un caso de uso. No se verifican dentro del caso de uso ya que se asume que se mantienen verdaderas durante su transcurso.

Flujo principal (FP), es el escenario del caso de uso de mayor interés para el actor primario.

Flujos alternativos específicos (FAE), son todos los otros escenarios que constituyen bifurcaciones del flujo principal.

Flujos alternativos globales, son escenarios que se pueden disparar en cualquier momento durante la ejecución del caso de uso, no son bifurcaciones del flujo principal.

Poscondiciones, Establece las condiciones que ocurren al completar el caso de uso.

1.3 Introducción a la Prueba de los Casos de Uso

Cuando se prueban los casos de uso, o sea la funcionalidad del sistema, se considera que el sistema es una caja negra. En este proyecto para generar los casos de prueba a partir del caso de uso se utiliza el método presentado en el documento [JimHeumann]:

Paso 1: Generar los escenarios a probar.

Paso 2: Identificar variables para escenarios básicos. Se hace una matriz con los casos de prueba abstractos, escenario, variables, resultado esperado.

Paso 3: Casos de prueba datos. Se generan datos para la matriz del paso 2 En las figuras a continuación se muestra un ejemplo, tomado del documento [BPerez_MBT], con la aplicación del método.

12

Ilustración 3: Caso de Uso Anotarse a un curso

Ilustración 4: Paso 1 - Generar los escenarios a probar

Ilustración 5: Paso 2 - Identificar variables para escenarios básicos

13

Ilustración 6: Paso 3 - Caso de prueba con datos

Durante la lectura se vió: (a) que los casos de uso se describen en forma muy heterogénea, algunos con mucho detalle y otros con demasiado poco; y (b) que las pruebas de los casos de uso son:

Difíciles de automatizar

Pruebas muy genéricas

Técnicas no sistemáticas. Dependen mucho de la habilidad de quien las aplica.

1.4 Técnicas de Procesamiento de Casos de Uso

En esta sección se hace un resumen de las técnicas estudiadas para procesar casos de uso con el fin de modelarlos y probarlos. Además pueden ser de utilidad para automatizar la generación de casos de prueba.

1.4.1 Proceso ETUC

El proceso ETUC[SR04][SR05], es una técnica para generar pruebas a partir de casos de uso que se puede resumir en cuatro pasos. En la Ilustración 7, cada paso es un color, el paso 1 es la primera actividad:

1. Construir modelos manipulables automáticamente. En este paso se

construyen un modelo de comportamiento y se identifican las variables operacionales, a partir de las especificaciones escritas en lenguaje informal de los casos de uso y de los requisitos de información, que describen los datos del mundo real utilizados por el sistema. La construcción no es automática porque se hace a partir de requisitos escritos en lenguaje informal, lo cual es una de las causas principales de las dificultades que presenta.

2. Extraer objetivos de prueba. Un objetivo de prueba es un escenario

concreto de un caso de uso

14

3. Traducir los objetivos a casos de prueba abstractos. Una prueba abstracta verifica un objetivo de prueba y es expresada de una manera genérica, no atada a ninguna interfaz ni herramienta de prueba

4. Implementar los casos de prueba. Una prueba ejecutable es la

implementación de una prueba abstracta, que puede ejecutarse directamente contra la aplicación bajo prueba.

Este proceso se basa en la arquitectura dirigida por modelos (MDA, Model Driven Architecture)[MDA] para generar las pruebas. Se distinguen y utilizan los siguientes modelos:

Modelo independiente de la computación (Computational Independent Model, CIM), compuesto por las definiciones de los casos de uso y los requisitos de información, o sea los datos manipulados en el caso de uso.

Modelo independiente de la plataforma (Platform Independent Model, PIM), compuesto por un modelo de comportamiento que en este caso es un

Construcción del modelo de comportamiento

Generación de valores de prueba

Generación de secuencias de acciones

Construcción de casos de prueba

ejecutables

Definición de Interfaces abstractas

Construcción de árbitros

Construcción de casos de prueba

abstractos

Construcción de objetivos de prueba

Ilustración 7: Proceso ETUC

15

diagrama de actividades y un modelo de datos que en este caso està constituido por las variables operacionales y sus dominios.

Modelo dependiente de la plataforma (Platform Specific Model, PSM), compuesto en este caso por casos de prueba ejecutables en el software bajo prueba (Software Under Test, SUT)

Por lo tanto en el paso 1 se transforma el CIM en el PIM. En el paso 2 se combinan los datos de prueba y las secuencias de ejecución a probar aplicando un criterio de cobertura sobre los modelos de comportamiento y de datos, o sea se trabaja dentro del PIM. Se extraen así los objetivos de prueba. En el paso 3 se construye un modelo genérico de las interfaces que también forman parte del PIM y se traducen los objetivos de prueba en acciones. O sea se obtienen los casos de prueba abstractos. En la técnica los casos de prueba abstractos se obtienen escribiendo en un lenguaje para pruebas abstractas los objetivos de la prueba, y en el proyecto estos CPA se generan automáticamente a partir del diagrama de análisis y muestran las condiciones que deben cumplir los datos para generar la salida esperada; esto quedará más claro más adelante en el documento. En el paso 4 se construyen los casos de prueba ejecutables a partir de los casos de prueba abstractos, se está transformando el PIM en el PSM. En el documento [SR05] hay un ejemplo que muestra la forma de aplicar el proceso ETUC para la generación de casos de prueba a una aplicación web, y que puede ser de mucha ayuda para facilitar la comprensión del proceso. Es importante mencionar que a pesar de estar definido todo el proceso para generar los casos de prueba, según los autores, falta investigación para definir las transformaciones que automatizarían al proceso ETUC. Esto se puede verificar en el documento [SR05], porque entre los trabajos a futuro incluye:

la transformación del CIM al modelo de comportamiento y al modelo de datos de prueba

la transformación de los objetivos de prueba a los casos de prueba abstractos

Sin embargo en [SR04] se presenta la herramienta OjectGen[OG] para generar objetivos de prueba a partir de casos de uso. Los casos de prueba son escritos en archivos XML. Primero un diagrama de actividades (archivo XMI) es generado a partir del caso de uso para luego identificar los objetivos de prueba recorriendo este diagrama. La página oficial de la herramienta [OG], la ubica en una fase inicial de desarrollo que sin embargo considera funcional. La última versión es del 28 de setiembre del 2006.

1.4.2 Caso de Uso Extendido

Un caso de uso especifica una familia de respuestas que se producen para las combinaciones de entradas y estados del sistema. El Caso de Uso Extendido [ExRVB] modela estas relaciones como una tabla de decisión.

16

La implementación típica de un caso de uso es una cadena de mensajes entre los actores y el sistema. Se deben probar todas las combinaciones de mensajes que soporte el caso de uso para encontrar faltas. Asumiendo que la prueba de integración del sistema no encontró faltas para las combinaciones de mensajes asociados a la operativa básica del caso de uso, entonces si una falta existe, debe estar relacionada a alguna combinación entrada y estado. Probar las combinaciones de condiciones y los valores límites de las variables operacionales (VO), es el más efectivo enfoque para disparar una falla. Un caso de uso extendido incluye la siguiente información:

Un inventario completo de las variables operacionales

Una especificación completa de las limitaciones en el dominio de cada variable operacional

Una relación operacional para cada caso de uso

La relativa frecuencia de cada caso de uso. Este valor es opcional, y es usado para realizar pruebas de operaciones del sistema que están compuestas por varios CU. En el documento [BinderOP], Binder (que es el autor del documento [ExRVB]) presenta un ejemplo de este tipo de pruebas.

Procedimiento para generar los Casos de Prueba El conjunto de CP se diseña en cuatro pasos. Se va a tomar el caso de uso Establish Session, que es un cajero automático simplificado, para ilustrar el procedimiento.

Caso de Uso Actor Posible combinación de Entrada/Salida

Establish Session Cliente de Banco 1. Entrada de Pin incorrecto una vez, entrada de Pin correcto. Desplegar menú.

2. Pin ok, banco del cliente no está en línea. Desplegar “Intente luego”

3. Pin ok, cuenta del cliente está cerrada. Desplegar “Llame a su banco”

4. LA tarjeta insertada es robada, Pin insertado es válido. Retener tarjeta

Tabla 1: CU Establish Session

1. Identificar las variables operacionales. Las variables operacionales son los factores que varían de un escenario al siguiente, y determinan significativamente diferentes respuestas en el sistema. Las variables operacionales incluyen las siguientes 1. Salidas y entradas explícitas 2. Condiciones de entorno que resultan en un significativamente diferente

comportamiento del actor

17

3. Abstracciones del estado en el sistema bajo prueba (por ej, estado del cajero: fuera de servicio, sin efectivo, listo, etc)

En el caso de uso Establish Session, hay cuatro variables que determinan las respuestas del cajero para un cliente que inserta una tarjeta y un Pin: el Pin codificado en la tarjeta, el Pin entrado por el cliente, la respuesta del banco del cliente, y la condición de la cuenta de banco del cliente.

2. Definir los dominios de las variables operacionales. Los dominios se definen como el conjunto de los valores válidos e inválidos de cada variable. Por ejemplo, el dominio del PIN son cuatro dígitos en un rango entre 0000 y 9999. Los casos de prueba requieren que sean especificados tanto valores válidos como inválidos. Las definiciones de los dominios pueden ser usadas para generar casos de prueba adicionales para cada variante.

3. Desarrollar la Relación Operacional. Son modeladas las relaciones entre las variables operacionales que determinan las distintas clases de respuesta del sistema. Esta es una tabla de decisión, cuando se cumplen todas las condiciones de una fila, es causada la acción esperada. Cada fila en la tabla de decisión es una variant (variante). Las variantes deben ser mutuamente excluyentes, una y solamente una variante debe cumplirse para un posible conjunto de valores de las variables operacionales.

Variante Variables Operacionales Resultado Esperado

PIN leído de tarjeta

PIN ingresado por el Cliente

Respuesta del Banco del Cliente

Estado de la cuenta del Cliente

Mensaje Acción sobre tarjeta

1 Inválido DC (Don’t Care)

DC DC Inserte una tarjeta de cajero

Devolver

2 Válido Coincide con el PIN de la tarjeta

Reconoce la cuenta

Cerrada Contacte su banco

Devolver

3 Válido Coincide con el PIN de la tarjeta

Reconoce la cuenta

Abierta Seleccione una transacción

Ninguna

4 Válido DC NO reconoce la cuenta

DC Intente más tarde

Devolver

5 Válido NO coincide con el PIN

DC DC Reingrese el PIN

Ninguna

18

de la tarjeta

6 Revocado DC Reconoce la cuenta

DC Tarjeta Inválida

Retener

7 Revocado DC NO reconoce la cuenta

DC Tarjeta Inválida

Devolver

Tabla 2: CU extendido Establish Session

4. Generar los casos de prueba. Para toda variante debe haber un caso de prueba que la haga verdadera y uno que la haga falsa. Un caso de prueba hace la variante verdadera cuando el conjunto de todos los valores satisfacen todas las condiciones de la variante, y falsa cuando por lo menos una de las condiciones de la variante no se cumple (modificando la entrada o los estados, y haciendo que por lo menos una condición de la variante deje de cumplirse). Con frecuencia un caso falso para una variante podría ser un caso verdadero para otra variante. Hay que intentar seleccionar un caso falso que no califique como caso verdadero de alguna otra variante. Si una variable operacional tiene limitado el dominio, se pueden agregar casos de prueba adicionales.

Automatización El conjunto de CP puede utilizarse con una herramienta de automatización de pruebas. En el documento [BinderOP] el autor (Binder) comenta que tiene implementada una herramienta para hacer pruebas automatizadas a partir de los casos de uso extendidos. Desventajas

No hay un acuerdo en las metodologías apropiadas para la abstracción y especificación de un caso de uso. Sin embargo el diseño de la prueba debe resolver las ambigüedades. Decidir el nivel de abstracción puede generar trabajo extra al tester.

Los casos de uso no son usados para especificar requerimientos no funcionales como la performance o la tolerancia a las faltas, entre otras.

Existen las relaciones extend (extender) e include (incluir) para la construcción de los casos de uso. Para poder modelar un caso de uso con relaciones de este tipo este debe ser simplificado. Una alternativa es confiar en que las pruebas decididas para la ejecución a alto nivel ejecuten todas las dependencias del bajo nivel.

Ventajas

Los casos de uso extendidos proveen un enfoque sistemático para generar los datos de los casos de prueba. Sin un enfoque sistemático pueden quedar relaciones sin probar.

El formato de los casos de uso extendido soportan el diseño de pruebas basadas en lógica combinatoria y de confiabilidad del software.

19

Un caso de uso extendido hace explícita todas las relaciones de la implementación del caso de uso. Con frecuencia el desarrollo de los casos de uso extendidos es suficiente para encontrar errores y omisiones.

1.4.3 Diagrama de Actividades NDT

En el documento [Hito2] los autores presentan una plantilla para especificar casos de uso que extiende NDT (Navigational Development Techniques) [NDT], y un algoritmo automatizable para generar a partir de esta un diagrama de actividades (DA). Plantilla para Especificar Casos de Uso El modelo de requisitos NDT es una propuesta para definir requisitos funcionales mediante casos de uso. A continuación se enumeran brevemente los elementos propuestos por NDT para la definición de requisitos funcionales:

Identificador

Descripción

Precondiciones

Actores

Secuencia normal

Postcondición

Alternativas / Excepciones

Rendimiento

Frecuencia esperada Los elementos del modelo NDT que extiende la plantilla son: la secuencia normal y las alternativas / excepciones. Los nuevos elementos son: los resultados, prioridad y el disparador.

Disparador. Especifica en lenguaje natural la acción de un actor o un evento externo al sistema, que comienza el caso de uso. No es utilizado este elemento cuando el primer paso de la secuencia principal es el disparador.

Resultados. Define con precisión son los resultados esperados tras la ejecución de un caso de uso, tanto si se logra la meta como si no. Un resultado no es lo mismo que una postcondición. Una postcondición es una condición que el sistema cumple a la finalización exitosa del caso de uso, y esta puede no ser apreciable por el actor. Sin embargo un resultado es una acción del sistema observable por el actor.

Secuencia normal. La técnica propone un patrón lingüístico para especificar los pasos de la secuencia principal, esto evita la ambigüedad del lenguaje natural y permite manipular la especificación de manera automática. Todos los elementos entre corchetes son obligatorios: [Número]. [Artículo] [actor / sistema / el evento] [verbo de acción] [lo que hace].

Secuencias alternativas. La técnica también propone un patrón para expresar los pasos alternativos a la secuencia principal. Dicho patrón se describe a continuación:

20

[Identificador]. [Tipo] [Cuando / Si] X "entonces" Y {"con el resultado" Z} El primer elemento del patrón es el identificador, este está compuesto por el número del paso de la secuencia normal al que complementa seguido de un número que identifica a una alternativa concreta (dado que un mismo paso de la secuencia principal puede tener varias alternativas). El segundo elemento del patrón es el tipo de la alternativa. El tipo se asigna en función del orden de ejecución de la alternativa con respecto al paso principal:

o [Pre], se evalúa la alternativa antes de la ejecución del paso. o [Inv], se evalúa la alternativa durante la ejecución del paso. En el

instante en que esta alternativa se cumple, se detiene la ejecución del paso y se realiza la alternativa.

El tercer elemento es la palabra "Cuando" o "Sí". Se puede elegir la que case mejor con el texto de la alternativa. El elemento X del patrón describe en lenguaje natural la condición que debe ser cierta para que se ejecute la alternativa. El elemento Y del patrón describe las acciones a realizar cuando se ejecuta la alternativa. Opcionalmente, se puede añadir un elemento Z que indica qué debe pasar después de ejecutar el elemento Y del patrón. El elemento Z generalmente es uno de los Resultados. Cuando el resultado de la acción ya se indica en el elemento Y no es necesario incluir el elemento Z.

Excepción. Es una alternativa de la secuencia principal que es invocada desde otro caso de uso y nunca directamente por ningún actor. Estas siguen el mismo patrón lingüístico que las secuencias alternativas.

Prioridad. Este elemento valora la importancia y relevancia del caso de uso en el sistema. Si la prioridad la establecen los usuarios, indica la importancia que los usuarios otorgan al caso de uso. Si la prioridad la establecen los desarrolladores, indica la relevancia del caso de uso para determinar la arquitectura del sistema o la complejidad de diseño e implantación del caso de uso.

A continuación se muestra la plantilla de casos de uso para recoger todos los elementos propuestos por NDT junto a las extensiones descritas anteriormente.

Nombre UC-01. …

Precondición …

Disparador* …

Secuencia normal

1 The actor… **

2 The system …

… …

4 The system strores the new link

Alternativas / Excepciones

1.1.i If the system … then … and the result is …

2.1.p If the actor … then … and the result is …

3.1.i At any time, the [system/actor] may …

21

then … and the result is …

Resultados

1 System…

… …

Postcondición …

Rendimiento …

Prioridad …

* Sólo cuando existan más de uno.

** Si sólo hay un disparador, se coloca aquí.

Tabla 3: Plantilla NDT

Algoritmo para generar el Diagrama de Actividades A continuación se describe a grandes rasgos el proceso para generar diagramas de actividades a partir de las definiciones de casos de uso. Las plantilla a continuación muestra un caso de uso, UC-01, definido de una manera abstracta, usado como ejemplo.

Nombre UC-01. X

Precondición No relevant

Secuencia normal

1 The Actor A1

2 The System S1

3 The Actor A2

4 The System S2

Secuencias alternativas / Excepciones

2.1.i If the system X1 then Y1 and the result is to repeat step 2

2.2.i If the system X2 then the system Y2 and the result is to repeat step 2

3.1.i If the actor X3 then Y3 and the result is to repeat step 3

Resultados 4 R1

Postcondición No relevant

Tabla 4: Caso de Uso UC-01

Las reglas para convertir un caso de uso en un diagrama de actividades se enumeran a continuación.

1. El diagrama comienza en el paso 1 de la secuencia principal, el cuál debe ser realizado por un actor.

2. Cada uno de los pasos de la secuencia principal será una actividad. Las actividades siguen la misma secuencia de ejecución que el orden de los pasos.

3. Cada uno de los pasos de la secuencia alternativa será una decisión gobernada por la condición definida en el paso.

a. Si un paso de la secuencia alternativa es una precondición, debe evaluarse antes de ejecutar el paso, por tanto, el símbolo de decisión en el diagrama de actividades se dibuja antes de la actividad.

22

b. Si un paso de la secuencia alternativa es una invariante, el símbolo de decisión en el diagrama de actividades se dibuja después de la actividad.

c. Una secuencia de decisiones correlativas pueden unirse en una única decisión siempre que hagan referencia al mismo paso y sean del mismo tipo (invariante o precondición).

4. Si los elementos entonces de un paso de una secuencia alternativa implican la realización de alguna acción, dicha acción será una actividad.

5. El diagrama termina después de ejecutar los pasos marcados como resultado.

Aplicando estas reglas al caso de uso UC – 01, se ha obtenido el diagrama de actividades mostrado a continuación.

Ilustración 8: Diagrama de Actividades UC-01

Automatización de la generación del Diagrama de Actividades Los escritores de [Hito2] hicieron un prototipo para generar el diagrama de actividades a partir de la plantilla XML del caso de uso. En primer lugar, los casos de uso serán expresados mediante plantillas en XML. Esto facilita su tratamiento por parte de la herramienta generadora. Esta herramienta construirá un documento XML que contendrá un diagrama de actividades expresado siguiendo las reglas de la especificación XMI [XMI]. Este documento podrá visualizarse y manipularse en cualquier aplicación con soporte XMI para visualizarlo de manera gráfica (por ejemplo ArgoUML y StarUML, ambas de libre descarga). A continuación se muestra un caso de uso mediante una plantilla NDT extendida.

Name UC-01. Añadir nuevo enlace

Precondition No

23

Main sequence

0 The user select the option for introduce a new link.

1 The System select “top” category and shows the form to introduce the information of a link (SR-02).

2 The User introduces information of the new link and press insert button.

3 The System stores the new link and shows the main screen of the system.

Errors / alternatives

2.1.i If the user press cancel button then the use case ends.

2.2.i If the user selects a different category (SR-01) then system changes the category and the result is to show the form again and execute step 2.

3.1.i If the link name or link url is empty the system shows an error message with the result of execute step 2.

Results

3 El sistema muestra la pantalla principal

2.1.i El sistema muestra la pantalla principal

Postcondition New link added into the system

Tabla 5: UC-01. Añadir nuevo enlace

A continuación se expresa el caso de uso definido en una plantilla XML creada por los escritores del documento (este modelo no está especificado en el documento). <useCase id="02-AddLink">

<mainSequence> <step id="1"> The user select the option for introduce a new link. </step> <step id="2"> The System select “top” category and shows the form to introduce the information of a link (SR-02). </step> <step id="3"> The User introduces information of the new link and press insert button. </step> <step id="4"> The System stores the new link and shows the main screen of the system. </step>

</mainSequence> <alternative>

<step id="2.1.i" mainStep="2" type="inv" result="end">

If the user press cancel button then the use case ends.

24

</step> <step id="2.2.i"

mainStep="2" type="inv" result="2">

If the user selects a different category (SR-01) then system changes the category and the result is to show the form again and execute step 2. </step> <step id="3.1.i"

mainStep="3" type="inv" result="2">

If the link name or link url is empty the system shows an error message with the result of execute step 2. </step>

</alternative> </useCase> La plantilla XML anterior es un prototipo, no es aún la versión definitiva. Por este motivo se han añadido atributos adicionales para simplificar la implementación de la herramienta de conversión. OMG define una especificación para definir modelos y elementos de UML mediante documentos en XML. Por cuestiones de simplicidad los escritores optaron por utilizar su propio modelo (el cual no está especificado) para diagramas de actividades. El diagrama de actividades resultante se muestra a continuación. <?xml version = '1.0' encoding = 'UTF-8' ?> <XMI xmi.version = '1.2' xmlns:UML = 'org.omg.xmi.namespace.UML' timestamp = 'Mon Mar 20 21:38:11 CET 2006'> <XMI.header> <XMI.documentation> <XMI.exporter>ArgoUML (using Netbeans XMI Writer version 1.0)</XMI.exporter> <XMI.exporterVersion>0.20.x</XMI.exporterVersion> </XMI.documentation> <XMI.metamodel xmi.name="UML" xmi.version="1.4"/> </XMI.header> <XMI.content> <UML:Model xmi.id = '.:0000000000000821' name = 'untitledModel' isSpecification = 'false' isRoot = 'false' isLeaf = 'false' isAbstract = 'false'> <UML:Namespace.ownedElement> <UML:ActivityGraph xmi.id = '.:0000000000000822' isSpecification = 'false'> <UML:StateMachine.context> <UML:Model xmi.idref = '.:0000000000000821'/> </UML:StateMachine.context> <UML:StateMachine.top>

25

<UML:CompositeState xmi.id = '.:0000000000000823' name = 'top' isSpecification = 'false' isConcurrent = 'false'> <UML:CompositeState.subvertex> <UML:ActionState xmi.id="5" name="The System shows a confirmation message" visibility="public" isSpecification="false" isDynamic="false"/> <UML:ActionState xmi.id="4" name="The System adds the annotation at the end of the annotation list." visibility="public" isSpecification="false" isDynamic="false"/> <UML:ActionState xmi.id="3" name="The User writes the text." visibility="public" isSpecification="false" isDynamic="false"/> <UML:ActionState xmi.id="2" name="The System asks the text of the annotation" visibility="public" isSpecification="false" isDynamic="false"/> <UML:ActionState xmi.id="1" name="The User asks system to add a new annotation" visibility="public" isSpecification="false" isDynamic="false"/> </UML:CompositeState.subvertex> </UML:CompositeState> </UML:StateMachine.top> </UML:ActivityGraph> </UML:Namespace.ownedElement> </UML:Model> </XMI.content> </XMI> Los escritores de [Hito2] hicieron un prototipo para generar el XMI a partir de la plantilla XML del caso de uso, pero comentan que este es completamente desechable. Por rapidez, generaron el código XMI de una manera artesanal. Sin embargo, esta aproximación es muy difícil de mantener y extender. Comentan que en las versiones definitivas de su conjunto de herramientas, utilizarán alguna librería existente (como Netbeans XMI, utilizada por la herramienta ArgoUML).

1.4.4 Diagrama de Actividades Extendido

Esta técnica [SERP05] plantea entre otras cosas: (a) un modelo formal para especificar los casos de uso como diagramas de actividades extendidos (DAE), y (b) un algoritmo para generar casos de prueba abstractos. Un diagrama de actividades (DA) puede representarse como un grafo en el que los nodos son usados para representar las acciones, las decisiones, el comienzo (fork) y la finalización (join) de ejecuciones concurrentes (fork); y las aristas del grafo representan las transiciones del diagrama de actividades. Con el objetivo de poder hacer un análisis de riesgo del caso de uso es que esta técnica extiende el DA asociándole a cada transición una probabilidad (P) y el costo (C) de un error en la transición. Estos valores debe asignarlos un experto que conozca la probabilidad de que ocurran los escenarios de CU y el costo de los flujos alternativos que contiene:

Probabilidad (P). Si el nodo origen de la transición es una decisión, entonces se asigna una probabilidad mayor a cero y menor a uno; en caso

26

contrario (el nodo origen no es una decisión) entonces la probabilidad es uno. Y dado un nodo de decisión, la suma de las probabilidades de las transiciones que nacen en él es uno.

Costo de un error en la transición (C). Primero se debe elegir el rango al que pertenecen los costos, en este caso es un valor entre cero y cinco. Si el nodo origen de la transición es una decisión, entonces el costo es cero; en caso contrario el costo es un valor perteneciente al rango elegido.

En el documento [SERP05] este análisis fue usado para escribir dos algoritmos: uno en el que se realiza un ranking de los caminos del DAE, y otro para evaluar el tiempo de operación de un escenario del CU. El que se muestra a continuación es el algoritmo usado para construir un ranking de los caminos del DAE, recordar que cada camino de estos es un caso de prueba:

1. Construir S, como el conjunto de los caminos del DAE. 2. Para cada camino p de S se calculan la probabilidad y el costo con las

funciones P(p) y C(p) respectivamente.

TD es el conjunto de las transiciones con origen en una decisión

3. Generar el rango para cada camino p (caso de prueba) usando una función

f(P(p),C(p)).

1.4.5 RUCM (Restricted Use Case Modeling)

El documento [YUE1] presenta un modelo para definir casos de uso denominado RUCM (Restricted Use Case Modeling). Este modelo lo componen un conjunto de reglas bien definidas de restricción y una plantilla de caso de uso. Tiene como objetivos: (1) restringir la forma en que los usuarios pueden documentar el caso de uso, para reducir la ambigüedad; y (2) facilitar el análisis automatizado con el objetivo de dar soporte a las herramientas que generan modelos de análisis, los cuales en UML están típicamente compuestos de diagramas de clase, diagramas de interacción, y posiblemente otros tipos de diagramas y restricciones. Plantilla de Casos de Uso En la Ilustración 9 se muestra la plantilla propuesta por los autores de [YUE1]. Los primeros siete campos de la plantilla se encuentran en la mayoría de las plantillas utilizadas para definir CU:

Use Case Name, el nombre del CU.

Brief Description, describe en forma resumida el CU en lenguaje natural.

Precondition, la condición que debe cumplirse para que comience la ejecución del CU.

Primary Actor, es el actor primario del CU.

Secondary Actors, otros actores en los que se basa el sistema para ejecutar el CU.

Dependency, son las relaciones Include y Extend con otros CU.

27

Generalization, son las relaciones Generalization con otros CU Y los últimos cuatro campos describen los flujos del CU: Basic Flow es el flujo principal; los otros tres (Specific Alternative Flows, Bounded Alternative Flows, Global Alternative Flows) son los flujos alternativos, que se diferencian en la cantidad de pasos en que se bifurcan de otro flujo denominado flujo de referencia. Un flujo alternativo específico (Specific Alternative Flow) referencia solamente un paso en el flujo de referencia, un flujo alternativo ligado (Bounded Alternative Flow) referencia más de un paso en el flujo de referencia, y un flujo alternativo global (Global Alternative Flow) referencia a cualquier paso en el flujo de referencia. Los flujos se especifican en la plantilla con los campos:

Steps, es la secuencia de pasos del flujo. Los pasos están numerados secuencialmente, y cada paso es completado antes de que comience el siguiente.

Postcondition, es la condición que debe cumplirse al terminar la ejecución del flujo.

RFS (Reference Flow Step), es la lista de los pasos del flujo de referencia en que se bifurca el flujo. Este campo solamente se utiliza en la especificación de los flujos alternativos específicos (solamente referencian un paso) y en la de los flujos alternativos ligados (referencian más de un paso).

Los pasos pueden ser una de las siguientes cinco interacciones:

1. Actor primario sistema: el actor primario envía una solicitud y datos al sistema

2. Sistemasistema: el sistema valida una solicitud y los datos de esta

3. Sistemasistema: el sistema altera su estado interno (por ej, grabando o modificando algo)

4. Sistemaactor primario: el sistema responde al actor primario con un resultado

5. Sistemaactor secundario: el sistema envía una solicitud a un actor secundario

28

Reglas de Restricción Este modelo consta de 26 reglas de restricción clasificadas en dos grupos: las restricciones al lenguaje natural para reducir la ambigüedad, y las restricciones de aplicación de palabras claves para especificar estructuras de control que facilitan la generación automática de los modelos de análisis. Como ya se mencionó el segundo grupo de reglas restringen el uso de estructuras de control:

Todo flujo (principal o alternativo) debe tener su propia poscondición.

Las dependencias entre los casos de uso, incluir (include) y extender (extend); se describen con sentencias que contienen las palabras claves INCLUDE USE CASE y EXTENDED BY USE CASE.

La palabra clave RFS es usada en un flujo alternativo específico / ligado, para hacer referencia a un paso / conjunto de pasos de un flujo de referencia a partir del que este flujo alternativo se bifurca.

Las palabras claves usadas para especificar sentencias condicionales (IF-THEN-ELSE-ELSEIF-ENDIF), sentencias de concurrencia (MEANWHILE), sentencias de chequeo de condición (VALIDATE THAT), y sentencias de iteración (DO-UNTIL).

La palabra clave VALIDATES THAT (va seguida de una condición) es usada para especificar sentencias en las que el sistema evalúa una condición, y que esta tiene que cumplirse para proceder con el siguiente

Ilustración 9: Plantilla de RUCM

29

paso del flujo. En la especificación del CU es necesario un flujo alternativo que describa que sucede cuando la condición no se cumple.

Las palabras claves ABORT y RESUME STEP (va seguida del número del paso de retorno) son usadas para describir una acción de finalización del caso de uso (o sea una salida excepcional) y que un flujo alternativo vuelve a su correspondiente flujo de referencia, respectivamente.

Aplicar este conjunto de reglas facilita la automatización del procesamiento del lenguaje natural y la generación de modelo de análisis, especialmente los diagramas de secuencia los cuales además ayudan a reducir la ambigüedad de las especificaciones de los casos de uso. La descripción detallada de las veintiséis reglas de restricción se puede ver en el apéndice A del documento [YUE1]. Ejemplo de una Especificación con RUCM En la Ilustración 10 se muestra el ejemplo de un caso de uso especificado con RUCM. Este ejemplo se tomó del documento [YUE3].

Ilustración 10: RUCM, Caso de Uso Disconnect

Evaluación de RUCM Los creadores de RUCM mencionan en el documento [YUE1], que hicieron un par de experimentos controlados, mostrando los resultados que RUCM es fácil de aplicar y que los resultados de aplicarlo implican significantes mejoras sobre las planillas de casos de uso estándar (que no tienen restricciones para el uso del LN), en términos de la calidad de los diagramas de clases y de secuencia generados. Transición automatizada hacia una Máquina de estados UML En el documento [YUE3] los autores, algunos fueron también autores del documento [YUE1], presentan una herramienta denominada aToucan que muestra la posibilidad de automatizar la generación de un modelo de análisis UML a partir de un modelo de casos de uso (UCMods) escrito en RUCM. El modelo de análisis

30

generado lo componen la máquina de estados UML, un diagrama de clases, un conjunto de diagramas de secuencia y de actividades. Y según los autores de [YUE3] la máquina de estados puede ser refinada a mano a un costo razonable para poder realizar un testeo basado en modelos (MBT model-based testing) [MBT]. En la Ilustración 11 se muestran los tres pasos que realiza aToucan para transformar UCMod en la máquina de estados UML, y los pasos para generar a partir de esta los casos de prueba.

Ilustración 11: Generación de Casos de Prueba usando aToucan

1.4.6 Pruebas dirigidas por modelos usando el perfil de pruebas UML 2.0

El documento [UMLTP] presenta una propuesta para la generación automática de casos de prueba en el contexto de la Arquitectura Dirigida por Modelos (MDA, Model Driven Architecture) [MDA]. Esta propuesta define una transformación con QVT (Query / View / Transformation, es un conjunto de lenguajes definidos por OMG) [QVT] de el modelo del sistema a probar, en un modelo de pruebas (MBT, Model Based Testing) [MBT]; en el documento [UMLTP] los autores comentan que si bien la transformación en QVT no ha sido implementada aún, sí se cuenta con el pseudocódigo que realiza la correspondencia entre ambos modelos. El comportamiento del sistema se modela con un conjunto de diagramas de secuencia extendidos (uno por cada escenario a probar), la arquitectura del sistema con un diagrama de clases, y el modelo de pruebas con el Perfil de Pruebas UML (UMLTP, UML Testing Profile) [UMLTP_OMG]. Se extiende cada

31

diagrama de secuencia con las pre y pos condiciones escritas en OCL [OCL], para poder automatizar la generación de los oráculos. En la Ilustración 12 se pueden observar los distintos puntos donde se pueden poner pre y poscondiciones. Por ejemplo, la pareja pre1 y pos 1, tienen la información necesaria para construir el oráculo para todo el diagrama, lo que se conoce como una prueba funcional. La pareja pre2 y pos2 dan la información necesaria para construir el oráculo para probar la interacción entre B y C, mientras que la pareja pre3 y pos3 permite realizar pruebas unitarias de C. A partir del diagrama de clases (que representa la arquitectura del sistema) y de los diagramas de secuencia extendidos con pre y postcondiciones (que representan el comportamiento), se realizan las transformaciones para llegar al modelo de pruebas. Primero se construye la arquitectura del modelo de pruebas a partir de la arquitectura del sistema y de los modelos que representan el comportamiento. Una vez construida la arquitectura de sistema de pruebas se genera el comportamiento asociado a cada uno de los casos de prueba mediante un diagrama de secuencia.

Ilustración 12: Información para el Oráculo según el Nivel de las Pruebas

Ejemplo A continuación se presenta un ejemplo tomado del documento [UMLTP] que usará la representación que modela el escenario principal de la funcionalidad de autenticación de un usuario del sistema, este modelo es una simplificación del entorno real en el que aparecerían múltiples escenarios. La Ilustración 13 muestra el diagrama de clases con la arquitectura que implementa esta funcionalidad y la Ilustración 14 representa el diagrama de

32

secuencia del comportamiento del sistema durante el escenario de ejecución principal. Las pre y postcondiciones que extienden el diagrama para este ejemplo se describen en la Ilustración 15. En la propuesta, los modelos de diseño en UML son transformados al modelo de prueba basado en el perfil de pruebas de UML utilizando QVT. En la Ilustración 16 se muestra la arquitectura de pruebas para este ejemplo una vez realizada dicha transformación. Como se mencionó anteriormente la transformación en QVT no ha sido implementada aún, aunque los autores del documento [UMLTP] dicen tener el pseudocódigo que realiza la correspondencia entre ambos modelos. Obsérvese que las diferentes clases están estereotipadas según el metamodelo de pruebas de UMLTP y que diversos elementos se nombran de manera que hacen referencia a lo que se está probando, tanto la funcionalidad, como su escenario de ejecución. También se pueden observar las diferentes relaciones entre el sistema de pruebas y el sistema. El diagrama de la Ilustración 17 muestra el comportamiento del caso de prueba testCaseValidLogin(). El diagrama está compuesto de tres partes, la primera es la obtención de los datos de prueba, donde el dataPool tendrá que tener en cuenta las precondiciones anotadas en OCL del diagrama de secuencia origen (ver Ilustración 15) para generar lo datos de prueba del testContext. La segunda parte contiene la ejecución de la funcionalidad a probar, por lo que se inician los testComponents y se ejecutan en el mismo orden los mensajes que aparecían en el diagrama original que partían o llegaban a un actor, solo que ahora parten o llegan a los testComponents que representan a esos actores. Y la última parte es la de actualización del veredicto, en la cual los testComponents tendrán que tener en cuenta las postcondiciones anotadas en OCL del diagrama origen (ver Ilustración 15).

Ilustración 13 Arquitectura del Sistema

33

Ilustración 14: Comportamiento del Sistema

Ilustración 15: Pre y poscondición de OCL

Ilustración 16: Arquitectura del Modelo de Pruebas

34

Ilustración 17: Diagrama de Secuencia del Caso de Prueba

2 Investigación El objetivo de la investigación en este proyecto era decidir la forma de diseñar TestCU. Para la investigación se fijaron como guías algunas ideas e interrogantes que se tenían al comenzar el proyecto, estas se detallan en la sección Ideas Preliminares3.1 Ideas Preliminares. En la sección 3.2 Revisión de las Técnicas se muestra el análisis hecho sobre las técnicas estudiadas. Este muestra la evaluación de cada técnica y su aporte al proyecto. Y por último en la sección 3.3 Decisiones de Diseño se sintetizan las ideas de la sección 3.2 Revisión de las Técnicas en las decisiones de diseño. A modo ilustrativo se incluye como anexo el documento [RSBorInv] con los apuntes elaborados durante la investigación1.

2.1 Ideas Preliminares

Antes de comenzar el estudio ya se tenían decisiones e interrogantes sobre el diseño que fueron las guías de la investigación. Entre las primeras decisiones estuvo el procesar la especificación formal del CU con un analizador sintáctico, con el objetivo de obtener la información necesaria para generar el diagrama de análisis automáticamente y los casos de prueba abstractos (CPA). Esta decisión exigía al lenguaje formal (LF) tener una semántica formal para interpretar las sentencias. Entre las principales interrogantes estuvo el saber si era posible utilizar un diagrama de actividades (DA) como diagrama de análisis, porque se sabía (por lo

1 Durante le período transcurrido algunas de las técnica vistas pudo haber avanzado.

35

estudiado en varias materias de Facultad) que este se podría implementar con un grafo, y los CPA se derivarían de los caminos simples que tienen como origen el vértice inicial del DA. Entre los vértices de este grafo estarían los:

vértices de actividad, que representarían los pasos del CU en los que NO se bifurcan flujos alternativos.

vértices de decisión, que representarían los pasos que son referenciados por un flujo alternativo (o sea que SÍ se bifurcan flujos alternativos en un vértice de decisión).

Esto implicaba resolver la forma de especificar los pasos del CU para que pudieran ser interpretados semánticamente por el analizador sintáctico.

2.2 Revisión de las Técnicas

Para hacer la revisión de las técnicas estudiadas, se hizo un análisis basado en una abstracción que relaciona sus características con los puntos a resolver en el proyecto. Esta abstracción ilustra la evaluación de la técnica y su aporte al proyecto. Se consideraron las siguientes propiedades:

Especificación, es la forma de especificar la información que necesita la técnica como entrada para poder aplicarse.

Diagrama de Análisis, es el modelo del caso de uso generado (manual o automáticamente) a partir de la especificación, y es en base a este modelo que se obtienen los resultados.

Generación de Pruebas, describe la forma de derivar los casos de prueba, si la técnica lo permite.

Automatización, describe el nivel de automatización logrado para generar los componentes de la técnica que son: el diagrama de análisis, los casos de prueba abstractos, los casos de prueba con datos y los scripts para ejecutar los casos de prueba con datos. En caso de existir una herramienta implementada para la aplicación de la técnica también se menciona en esta propiedad.

Aplicación, consiste en las sugerencias o ideas surgidas de esta técnica para el diseño de la herramienta TestCU.

2.2.1 Proceso ETUC

Este proceso se basa en la arquitectura dirigida por modelos (MDA, Model Driven Architecture) para generar las pruebas, como se mencionó en la sección 2.4.1 Proceso ETUC:

Modelo independiente de la computación (CIM), compuesto por las definiciones de los casos de uso y los requisitos de información, o sea los datos manipulados en el caso de uso.

Modelo independiente de la plataforma (PIM), compuesto por un modelo de comportamiento que en este caso es un diagrama de actividades y un modelo de datos que en este caso está constituido por las variables operacionales y sus dominios.

Modelo dependiente de la plataforma (PSM), compuesto en este caso por casos de prueba ejecutables en el software bajo prueba

36

Especificación Para especificar el caso de uso se utiliza una plantilla NDT extendida [SR04] con los requisitos de información que componen el CIM [NDT]. Diagrama de Análisis El PIM generado a partir de la información especificada en el CIM, está compuesto por

Un modelo de comportamiento, que es un diagrama de actividades

Un modelo de datos compuesto por las variables operacionales, y sus dominios.

Sin embargo la transformación no es automática porque la construcción de estos modelos se hace a partir de requisitos escritos en lenguaje informal, lo cual es una de las causas principales de las dificultades que presenta. Generación de Pruebas Las transformaciones se realizan dentro del PIM, extrayendo los objetivos de prueba y los casos de prueba abstractos en los siguientes tres pasos:

1. Extraer objetivos de prueba. Los objetivos de prueba se construyen combinando las secuencias de acciones con los valores de prueba.

2. Traducir los objetivos a casos de prueba abstractos. Los casos de prueba abstractos se obtienen escribiendo en un lenguaje para pruebas abstractas los objetivos de prueba. Estos reflejan las acciones sobre una interfaz.

3. Implementar los casos de prueba. Este paso es la transformación del PIM al PSM.

Automatización En [SR04] se presenta la herramienta OjectGen[OG] para generar objetivos de prueba a partir de casos de uso. Los casos de prueba son escritos en archivos XML. Primero un diagrama de actividades (archivo XMI) es generado a partir del caso de uso para luego identificar los objetivos de prueba recorriendo este diagrama. Aplicación Es aplicable el uso de variables operacionales para representar los datos de la especificación que son usados en los casos de prueba. Estas variables tienen un dominio y un tipo. Modelar el comportamiento con un diagrama de actividades facilita la generación de secuencias de acciones a partir de un criterio de cobertura del diagrama. Cada secuencia representa un camino dentro del diagrama, y cada camino puede ser usado para generar casos de prueba asignando valores a las variables operacionales de forma que se pueda recorrer el camino.

2.2.2 Caso de Uso Extendido

Esta técnica se presenta en el documento [ExRVB], y la componen: (a) un procedimiento para generar una especificación formal de un CU, denominada

37

Caso de Uso Extendido; y (b) la forma de generar CP a partir de esta especificación. Especificación En esta técnica se modela el CU a probar como una tabla de decisión, que se denomina Caso de Uso Extendido. Diagrama de Análisis Dada una especificación del CU, la tabla de decisión se construye en tres pasos:

1. Identificar las VO. 2. Definir los dominios de las VO 3. Desarrollar la relación operacional. Son modeladas las relaciones entre las

variables operacionales y las distintas clases de respuesta del sistema, cuando se cumplen todas las condiciones de una fila es causada la acción esperada (la respuesta del sistema en el caso de uso). Cada fila de la tabla de decisión es una variant (variante), estas deben ser mutuamente excluyentes y solamente una debe cumplirse para un posible conjunto de valores de las variables operacionales.

Generación de Pruebas Para toda variante debe haber un CP que la haga verdadera y uno que la haga falsa. Un caso de prueba hace la variante verdadera cuando el conjunto de todos los valores satisfacen todas las condiciones de la variante, y falsa cuando por lo menos una de las condiciones de la variante no se cumple. Hay que intentar seleccionar un caso falso que no califique como caso verdadero de alguna otra variante. Si una variable operacional tiene limitado el dominio, casos de prueba adicionales pueden ser agregados. Automatización El conjunto de CP puede utilizarse con una herramienta de automatización de pruebas. En el documento [BinderOP] el autor (Binder) comenta que tiene implementada una herramienta para hacer pruebas automatizadas a partir de los casos de uso extendidos. Aplicación El objetivo de TestCU es automatizar la generación de esta tabla de decisión, siendo cada una de las variantes un CPA.

2.2.3 Diagrama de Actividades NDT

Esta técnica se presenta en el documento [Hito2], y la componen: (a) una plantilla para definir casos de uso (CU); y (b) un algoritmo para generar un diagrama de actividades (DA) a partir del CU definido en la plantilla. Especificación

38

Se usa una plantilla que extiende NDT, para definir los CU. Los elementos del modelo NDT que se extienden son el flujo principal, el flujo alternativo; y se agregan los elementos resultados, prioridad, disparador. Los elementos de la plantilla se pueden clasificar en función de la forma de redactarlos:

Los que se redactan en lenguaje natural sin restricciones: nombre, precondición, disparadores (acciones del actor o eventos externos al sistema que disparan el CU), prioridad (relevancia del CU en el sistema), poscondición

Los que se redactan siguiendo un patrón lingüístico para evitar la ambigüedad del lenguaje natural: flujo principal, flujos alternativos / errores, resultados esperados.

Diagrama de Análisis Es un diagrama de actividades en el que las actividades son los pasos del flujo principal, y cada paso de los flujos alternativos es una decisión. En el documento [Hito2] se presenta el algoritmo para generar el DA. Automatización El algoritmo para generar el DA es automatizable, los autores de [Hito2] implementaron un prototipo que recibe la plantilla en un archivo XML, y devuelve el diagrama en un archivo XMI [XMI]. Aplicación Presenta dos ideas para especificar formalmente un CU:

1. La plantilla que especifica el caso de uso se puede representar en un archivo XML.

2. El usar un patrón lingüístico para las sentencias usadas en la plantilla. Además presenta un algoritmo, que es posible automatizar, para convertir el CU especificado en la plantilla en un DA. Pero esta técnica ni genera casos de prueba, ni procesa la información en las sentencias de los pasos del CU (o sea que no interpreta semánticamente las sentencias).

2.2.4 Diagrama de Actividades Extendido

Esta técnica presenta en el documento [SERP5] una forma de especificar formalmente un CU como un diagrama de actividades extendido (DAE), a partir del que se puede realizar un análisis de riesgo para el CU. El documento muestra como ejemplo un análisis para crear un ranking con los caminos del DAE (cada camino es un caso de prueba); y se puede utilizar este ranking para decidir el criterio de cobertura. Especificación

39

La especificación es un grafo que representa al DAE:

El conjunto de vértices contiene entre otros los subconjuntos NA (conjunto de vértices que representan las actividades del DAE) y ND (conjunto de vértices que representan las decisiones del DAE). Todo vértice de NA tiene asociado la lista de los datos a ser considerados en la técnica.

Las aristas representan las transiciones del DAE, y cada una tiene asociada: (a) una condición cuando su origen es un vértice de ND, (b) la probabilidad de que se ejecute, y (c) el costo de que suceda un error al ejecutarse.

Diagrama de Análisis El diagrama de análisis es un DA UML extendido (DAE), en el que los caminos entre el vértice inicial y los finales representan los escenarios del CU, y cada escenario tiene asignado un riesgo. El riesgo de un camino se calcula utilizando una función que tiene como parámetros el costo y la probabilidad de cada camino, recordar que cada una de las aristas del grafo tiene asignado un costo y una probabilidad. En [SERP5] se definen las funciones para calcular la probabilidad de que se ejecute un camino, y el costo de un camino. Generación de Pruebas Esta técnica da la posibilidad de generar los casos de prueba a partir de un análisis de riesgo. Sin embargo las pruebas pueden también generarse seleccionando los caminos a partir de un criterio de cubrimiento de grafos, en el que no se toman en cuenta ni los riesgos ni los costos ni las probabilidades. Automatización En el documento [SERP5] no se trabaja la automatización para la generación de casos de prueba, lo que presenta el documento son algoritmos para realizar cálculos de riesgo y de tiempo de operación de los escenarios del CU. Aplicación Esta técnica vuelve a confirmar lo simple que es modelar un CU formalmente con un diagrama de actividades UML. También que es posible extender el DA para realizar por ejemplo un análisis de riesgo del CU para generar los casos de prueba.

2.2.5 RUCM (Restricted Use Case Modeling)

Es un modelo, propuesto en [YUE1], para especificar los casos de uso utilizando una plantilla y un conjunto de restricciones. En el documento [YUE3] los autores mencionan la existencia de la herramienta aToucan, que genera un modelo de análisis a partir de una especificación en RUCM. El modelo de análisis generado lo componen una máquina de estados UML, un diagrama de clases, un conjunto de diagramas de secuencia y uno de actividades. Especificación

40

Se utiliza una plantilla en la que se escriben los pasos del CU en un lenguaje natural restringido por el conjunto de restricciones de RUCM. Las restricciones están pensadas para reducir la ambigüedad de las especificaciones y facilitar la generación automática de los modelos de análisis. En el documento [YUE1] se describen los experimentos hechos por los autores para probar lo fácil que es escribir en RUCM y generar de un diagrama de análisis manualmente. Diagrama de Análisis Modela la especificación de los casos de uso, no propone un modelo de análisis. Generación de Pruebas RUCM no propone un algoritmo para generar los CP. Pero el documento [YUE3] propone generar CP refinando la máquina de estados generada por aToucan (esto debe ser hecho por un especialista en modelado y otro en dominios), para que a partir de esta máquina de estados se puedan generar los CP. En el documento se menciona que esta generación de CP es simple, aunque no aclara ni cómo hacerlo ni sugiere herramientas para hacerlo. Automatización Uno de los objetivos de las restricciones de RUCM es facilitar la derivación automática de un modelo de análisis, pero RUCM no describe la forma de hacerla. Sin embargo en el documento [YUE3] se menciona la existencia de la herramienta aToucan, que deriva un modelo de análisis a partir de una especificación en RUCM. El modelo de análisis generado lo componen una máquina de estados UML, un diagrama de clases, un conjunto de diagramas de secuencia y uno de actividades. Aplicación Presenta una forma de especificar un CU reduciendo la ambigüedad a través de una plantilla y un conjunto de restricciones. La plantilla se puede escribir en un archivo XML, por ser similar a la usada por la técnica Diagrama de Actividades NDT. Las sentencias de la plantilla son en lenguaje natural, y aunque están restringidas por un conjunto de restricciones, no es simple la interpretación automática de estas instrucciones (ver documento [YUE_UCMeta]). Lo que se toma es la idea de que es posible utilizar palabras claves para definir la estructura de control del CU, y así facilitar la derivación automática de un diagrama de análisis.

41

2.2.6 Pruebas dirigidas por modelos usando el perfil de pruebas UML 2.0

El documento [UMLTP] presenta una técnica que transforma un modelo del sistema a probar en un modelo de pruebas basado en el Perfil de Pruebas UML (UMLTP, UML Testing Profile) [UMLTP_OMG]. La arquitectura del sistema se modela con un diagrama de clases, y el comportamiento con diagramas de secuencia extendidos con pre y pos condiciones. Un diagrama de clases modela la arquitectura del modelo de pruebas, y el comportamiento de cada caso de prueba se modela con un diagrama de secuencia. Especificación Un diagrama de clases que modela la arquitectura del sistema a probar y un conjunto de diagramas de secuencia que modelan el comportamiento. Cada uno de los diagramas de secuencia se extiende con su pre y su pos condiciones usando OCL [OCL]. Y dependiendo del punto en que se ubican estas en el diagrama, se define el tipo de prueba (unitaria, integración, funcional). Diagrama de Análisis La especificación ya descrita es el diagrama de análisis. Generación de Pruebas Se utiliza una transformación QVT (Query / View / Transformation) [QVT] para transformar la especificación del sistema en un modelo de pruebas UMLTP. Este modelo lo componen la arquitectura con un diagrama de clases, y el comportamiento de cada caso de pruebas con un diagrama de secuencia. Automatización Los autores comentan en el documento [UMLTP] que no tienen implementada la transformación, pero sí un pseudocódigo. Aplicación Esta técnica mostró un enfoque distinto para realizar pruebas a un sistema, pero no trabaja con casos de uso.

2.3 Decisiones de Diseño

Para construir TestCU fue necesario implementar los requerimientos presentados en el capítulo 1 Introducción, utilizando las ideas obtenidas durante la investigación, que tuvo como guías las ideas presentadas en la sección 3.1 Ideas Preliminares. Esta implementación implicaba encontrar un lenguaje formal para especificar los CU, que debía ser procesado por un analizador sintáctico para generar automáticamente un diagrama de análisis. A partir de este diagrama debía ser posible derivar los CPA automáticamente; se tenía la idea de investigar si era posible que este fuera un diagrama de actividades (DA) porque a partir de este se podría automatizar la generación de los CPA (cada camino simple de este diagrama que tiene como origen el vértice inicial del DA es un CPA).

42

Lenguaje Formal Se definió el lenguaje formal LFTestCU para especificar los casos de uso, con la propiedad de que a partir de la interpretación semántica de las sentencias de un CU se pueda crear un DA. En este lenguaje una sentencia de LFTestCU es un documento XML (o sea la especificación en LFTestCU del CU) mientras que una forma sentencial es una cadena de terminales y no terminales. Dentro de una sentencia de LFTestCU se identifican diferentes formas sentenciales:

Las que especifican las acciones del sistema / usuario.

Las que especifican la estructura del CU.

Las que especifican condiciones. Una forma sentencial puede ser una combinación de otras formas sentenciales. Otra de las características de LFTestCU es el uso de las variables operacionales para representar los datos relevantes del CU que determinan los resultados. Para facilitar la escritura en LFTestCU, porque las sentencias son archivos XML, se definió una plantilla denominada Plantilla LFTestCU (ver Tabla 6. Plantilla LFTestCU), sirvió de inspiración la plantilla utilizada por la técnica RUCM (Restricted Use Case Modeling). Este lenguaje tiene entre las principales características:

puede escribirse como un archivo XML, similar al de la técnica Diagrama de Actividades NDT, que permite la generación automática de un DA.

la especificación de un Flujo Alternativo Específico (FAE) tiene asociados: (a) un atributo denominado RFS (Reference Flow Step) que referencia al paso del flujo en el que se bifurca; y (b) el atributo Poscondición que indica el estado en el que queda el sistema al terminar la ejecución del flujo.

la especificación de un Flujo Alternativo Global (FAG) tiene asociado el atributo Disparador que es una cadena de caracteres que describe el evento que dispara la ejecución de este flujo.

Diagrama de Análisis Se decidió utilizar un diagrama de actividades (DA) como diagrama de análisis, porque las técnicas Diagrama de Actividades NDT y Diagrama de Actividades Extendido confirman que es posible generar automáticamente:

un DA que modele al CU a partir de una especificación de este en un archivo XML.

el archivo XML para especificar el CU a partir de la Plantilla LFTestCU.

los CPA recorriendo los caminos simples que tienen como origen el vértice inicial el DA.

En este DA hay cuatro tipos de vértices, es importante destacar que el número de paso de la especificación en LFTestCU coincide con el identificador del vértice que lo representa (o sea con el que mapea) en el DA:

vértice inicial, en este se originan el flujo principal (FP) y cada uno de los FAG. Toda ejecución comienza en el FP, y en cualquier momento durante

43

la ejecución puede dispararse la ejecución de un FAG cuando sucede el evento especificado en el atributo Disparador que tiene asociado.

vértice de decisión, cada uno de los pasos de la especificación que tiene el terminal VALIDATES_THAT mapea con un vértice de decisión. La condición asociada a este terminal es la guarda de la opción para seguir ejecutando el flujo al que pertenece este paso. Las otras opciones asociadas a este vértice son los flujos alternativos específicos (FAE) que lo referencian (o sea que en el atributo RFS tienen como valor el identificador de este vértice), y la guarda de cada opción es la condición especificada en el atributo Condición de Flujo del FAE.

vértice de actividad, estos vértices mapean con los pasos de la especificación del CU que son acciones del actor/ sistema, o con los pasos que tienen el terminal RESUME_STEP. En los vértices de actividad no se bifurcan flujos alternativos, y los vértices asociados al terminal RESUME_STEP deben ser los últimos de un flujo alternativo (FAE o FAG).

vértice final, puede ser: (a) el último paso del FP, o (b) mapea con un paso de la especificación que tiene el terminal ABORT. El terminal ABORT solamente puede ser el último paso de un flujo alternativo (FAE o FAG).

Generación de los CPA La decisión de utilizar un DA como diagrama de análisis, permitió tomar la decisión de utilizar como criterio de cobertura el recorrer los caminos simples que tienen como origen el vértice inicial del DA. Esto implica que cada decisión (guarda de un vértice de decisión) toma al menos una vez el valor true y otra el valor false. Y como toda decisión está compuesta por una sola condición (porque en LFTestCU toda condición tiene como máximo dos operandos), este criterio coincide con el denominado Criterio de cubrimiento de decisión/condición que es considerado como bastante fino en el documento Verificación y Validación [iis VyV] de la materia Introducción a la Ingeniería de Software de la Facultad de Ingeniería de la UDELAR. El conjunto de los CPA generados se pueden representar en una tabla de decisión, parecida a la utilizada en la técnica Caso de Uso Extendido, que en este proyecto se la denomina Matriz de los CPA. En la sección 4.3 Generación de los CPA se muestra en detalle la implementación de este criterio.

3 Construcción de TestCU Como se menciona en la sección 3.3 Decisiones de Diseño la construcción de TestCU implicó:

Definir el lenguaje formal LFTestCU para especificar casos de uso.

Definir un conjunto de reglas para modelar automáticamente un CU especificado en LFTestCU, como un diagrama de actividades (DA).

Implementar un algoritmo para derivar automáticamente los casos de prueba abstractos (CPA) a partir del DA.

44

Para facilitar la comprensión se va a ir desarrollando un ejemplo durante el desarrollo de este capítulo. La especificación en lenguaje natural del CU de este ejemplo se tomó del documento Hito 2: Definición de casos de uso para procesos de generación automática de pruebas del sistema [Hito2]: Description Load document from file Precondition No Main scenario 1 User select “Open file” option. 2 System asks for the file to open. 3 User selects a file. 4 System loads the file and shows the document. Alternative / errors 3.1.i User may cancel the loading operation at any time. 4 If file does not exist or there is an error, system shows an error message. Postcondition No.

3.1 LFTestCU

La especificación de un CU en LFTestCU es un documento XML, que se puede escribir fácilmente a partir de la Plantilla LFTestCU (ver la Tabla 6. Plantilla LFTestCU), como ya se mencionó en la sección 3.3 Decisiones de Diseño. En esta plantilla los campos relevantes en la generación del DA y de los CPA son:

Identificadores del Actor Primario / Sistema, son las palabras con la que se identifican a los actores primario / sistema en TestCU.

Variables Operacionales, es una tabla con las variables operacionales (VO) usadas en la especificación del CU y en los CPA. Los valores de estas variables son los usados por TestCU para generar los CPA:

o Nombre, es una palabra para identificarla. o Tipo, indica si la variable es de entrada (E), de salida (S) o si es una

del estado del sistema (EDS). o El resto de los valores son los que necesita el tester para generar los

CP con Datos (casos de prueba con datos) que se muestran en la Ilustración 1: Objetivos del Proyecto. Entre estos valores están las condiciones de validez e invalidez, que indican en el CPA las condiciones que debe cumplir el dato cuando el valor de la variable es válido o inválido respectivamente.

Flujos, cada uno de los flujos es una tabla que tiene asociada: o El nombre del caso de uso. o El identificador, es la palabra usada por TestCU para identificarlo. o La secuencia de pasos que lo componen.

45

o La poscondición, es la cadena de caracteres que describe las condiciones que se deben cumplir al momento de finalizar la ejecución del flujo.

o Pero hay datos que son propios de cada tipo de flujo: Un Flujo Alternativo Específico (FAE) tiene asociado además:

(a) RFS – Reference Flow Step, es el identificador del paso en el que se bifurca del flujo que referencia, y (b) la Condición de Flujo, escrita en LFTestCU, que especifica la condición que debe cumplirse en RFS para que se ejecute el flujo alternativo.

Sin embargo un Flujo Alternativo Global (FAG) tiene asociado un Disparador, que describe en lenguaje natural el evento que dispara la ejecución del flujo global.

Nombre del CU

Cadena de caracteres que especifica el nombre del CU.

Descripción Cadena de caracteres que resume al CU.

Precondición Cadena de caracteres que especifica las condiciones que se cumplen al momento de comenzar la ejecución el CU.

Actor Primario Nombre Cadena de caracteres con que especifica el nombre del actor.

Identificador Palabra que usada en las sentencias del CU para identificar al actor primario.

Sistema Nombre Cadena de caracteres que especifica el nombre del sistema.

Identificador Palabra que usada en las sentencias del CU para identificar al sistema.

Variables Operacionales

Nombre Tipo Descripción Dominio Condiciones de Validez

Condiciones de Invalidez

Cadena de caracteres que especifica el nombre de la variable.

E – variable de entrada. EDS – variable de estado del sistema. S – variable de salida.

Cadena de caracteres que describe la variable.

Cadena de caracteres que describe el dominio de la variable.

Cadena de caracteres que describe las condiciones que debe cumplir la variable para ser válida

Cadena de caracteres que describe las condiciones que debe cumplir la variable para ser inválida

Flujo Principal Nombre Cadena de caracteres que especifica el nombre del flujo.

46

Identificador Palabra que identifica al flujo.

Pasos Secuencia de pasos que componen el flujo. Cada paso es una sentencia de LFTestCU.

Poscondición Cadena de caracteres que describe las condiciones que se cumplen al momento de finalizar la ejecución del flujo.

Flujos Alternativos Específicos

Nombre Cadena de caracteres que especifica el nombre del flujo.

Identificador Palabra que identifica al flujo.

Condición de Flujo Es una condición de LFTestCU, esta debe cumplirse para que comience la ejecución de este flujo. Esta se verifica en el campo especificado en el campo RFS.

RFS Es el identificador del paso en el que se bifurca este flujo. Este paso es una sentencia VALIDATES_THAT en la que se verifica si se cumple la condición especificada en el campo Condición de Flujo.

Pasos Secuencia de pasos que componen el flujo. Cada paso es una sentencia de LFTestCU.

Poscondición Cadena de caracteres que describe las condiciones que se cumplen al momento de finalizar la ejecución del flujo.

Flujos Alternativos Globales

Nombre Cadena de caracteres que especifica el nombre del flujo.

Identificador Palabra que identifica al flujo.

Disparador Cadena de caracteres que describe el evento que dispara la ejecución del flujo.

Pasos Secuencia de pasos que componen el flujo. Cada paso es una sentencia de LFTestCU.

Poscondición Cadena de caracteres que describe las condiciones que se cumplen al momento de finalizar la ejecución del flujo.

Tabla 6. Plantilla LFTestCU

47

Pero además de esta plantilla, es necesario que la gramática formal de LFTestCU tenga una semántica formal asociada para poder interpretar semánticamente con un analizador sintáctico las sentencias. Semántica Formal Se describen a continuación los tres tipos de formas sentenciales usadas en los pasos de la especificación en LFTestCU. Las formas sentenciales que especifican las acciones del actor / sistema tienen la forma

<identificador del paso>.<acción> Se procuró que las acciones fueran lo más genéricas posible para poder especificar formalmente diversos CU. Las acciones que brinda la gramática son

a. ingresaDatos (<id actor>, {<variable operacional>}); representa un ingreso de datos que realiza el actor, estos datos son el conjunto de las variables operacionales que recibe la acción como parámetro. En este proyecto el actor es el actor primario, pero se deja como parámetro para el trabajo a futuro cuando se trabaje con actores secundarios.

b. generaDatos(<id sistema>, IN {<variable operacional >}, OUT {<variable operacional >}); representa un proceso realizado por el sistema para generar el conjunto de valores de las VO del tercer parámetro (a continuación del OUT), a partir de los valores del conjunto de VO del segundo parámetro (a continuación del IN).

c. muestraMensaje(<id sistema>, “<cadena de caracteres>”); representa que el sistema muestra al actor el mensaje del segundo parámetro.

d. muestraDominio (<id sistema>, <variable operacional>); representa que el sistema muestra al actor el dominio (o sea el conjunto de todos los valores posibles) de la variable operacional pasada como parámetro.

e. muestraDatos(<id sistema>, {<variable operacional>}); usada para representar que el sistema muestra al actor el conjunto de valores de las variable operacionales ingresadas como parámetro.

Las formas sentenciales para especificar la estructura del CU, se toman muchas ideas del lenguaje RUCM (Restricted Use Case Modeling) [YUE1]. Estas formas sentenciales usan las siguientes palabras claves (terminales de LFTestCU):

VALIDATES_THAT (<condición LFTestCU>), es usada para especificar que el sistema chequea la condición escrita en LFTestCU. Si esta condición se cumple, entonces el sistema continúa con el siguiente paso del flujo que se está ejecutando; en caso contrario el sistema continúa con el primer paso del flujo alternativo específico que referencia este paso en RFS y que además cumple la Condición de Flujo.

ABORT, es usada en los flujos alternativos para especificar que termina la ejecución del CU

48

RESUME_STEP (<id de un paso>), es usada en los flujos alternativos específicos para indicar el siguiente paso a ejecutar. Esta forma sentencial solamente puede ser usada en último paso un flujo alternativo.

RFS (reference flow step), es usada en un flujo alternativo específico para referenciar el paso VALIDATES_THAT (en otro flujo) en el que se evalúa si se cumple la Condición de Flujo que determina que debe comenzar la ejecución de este flujo alternativo.

Existen además dos tipos formas sentenciales para especificar condiciones, (a) las que utilizan un operador binario (con dos operandos) y (b) las que utilizan un operador unitario (con solamente un operando):

a. <variable operacional 1> <operador binario> (<variable operacional 2> | <constante>)

b. <variable operacional> <operador unitario> Los posibles operadores binarios son:

o = o <> o < o <= o >= o >

Mientras que los unitarios son o IS_VALID, es verdadera cuando la variable operacional cumple

las Condiciones de Validez que tiene definidas (ver Tabla 6. Plantilla LFTestCU).

o IS_NOT_VALID es verdadera cuando la variable operacional cumple las Condiciones de Invalidez que tiene definidas (ver Tabla 6. Plantilla LFTestCU).

o IS_NULL, es verdadera cuando la variable operacional NO tiene un valor asociado (o sea que el valor es null).

o IS_NOT_NULL, es verdadera cuando la variable operacional tiene un valor asignado.

3.1.1 Aplicación al Ejemplo

A continuación se muestra el análisis realizado para construir la especificación en LFTestCU del CU Load document from file. Presentado al comienzo de este capítulo. Este análisis consistió en procesar la especificación en lenguaje natural del CU para construir la Tabla 7: Plantilla LFTestCU - Load document from file utilizando la Plantilla LFTestCU. Como ya se mencionó en la sección 4.1 LFTestCU, esta tabla simplificó la especificación en LFTestCU; esta especificación se muestra en el Anexo A – Especificación LFTestCU de Load document from file. Es importante resaltar que no hay una única forma de especificar un CU en LFTestCU, siempre dependerá del grado de correctitud y completitud de esta especificación formal.

49

Lo primero fue llenar en la plantilla los campos con los datos que no se consideran relevantes para la generación de los CPA: Nombre del CU, Descripción, Precondición. Aunque los nombres del actor primario y del sistema no son relevantes, si lo son los identificadores de estos que son usados en las acciones (como por ejemplo ingresaDatos, muestraDominio, etc). El siguiente paso fue identificar las variables operacionales. En este CU el usuario selecciona (o sea que ingresa al sistema) una opción entre un conjunto de opciones disponibles que muestra en el sistema, esto llevó a definir la variable operacional Opcion de tipo E (Entrada) que tiene como dominio el Conjunto {Open File, …}. El otro dato relevante es el nombre del archivo (que es una cadena de caracteres) que el usuario le indica al sistema que desea cargar, por lo que se definió la VO NombreDeArchivo como una cadena de caracteres de tipo E, que es válida solamente si existe en el sistema un archivo con este nombre. Una vez definidas las VO y llenados los datos varios, se realizó la escritura de los flujos. Flujo Principal Se comenzó con el flujo principal:

Se le asignó el Nombre Flujo Principal y el Identificador FP, el único requisito del identificador es que fuera una palabra.

En la Poscondición se indicó que al terminar la ejecución del flujo principal el sistema debía mostrar el archivo con el nombre NombreDeArchivo.

En relación a los pasos: o se utilizaron las formas sentenciales acción (ingresaDatos,

muestraMensaje, etc) para definir las instrucciones en las que el actor / sistema realiza alguna acción. En el ejemplo se representó que el usuario selecciona una opción a través de dos pasos: (1) el FP_1prima en el que el sistema muestra el conjunto de opciones mostrando el dominio de la VO Opcion; y (2) el FP_1 en el que el usuario ingresa la opción en la variable Opcion.

o los pasos FP_2prima y FP_3prima son los que representan: (a) las condiciones que deben cumplir las VO para que se termine de ejecutar el FP,y (b) que se bifurcan en el FP los flujos alternativos específicos.

Flujos Alternativos Específicos Una vez definido el flujo principal FP, se continuó con la de los flujos alternativos específicos que se bifurcan de este, que son FA1 y FA2. Para definir estos, además de los campos usados en la definición del flujo principal, se necesitaron: (a) los datos Condición de Flujo y RFS; y (b) como último paso la instrucción ABORT cuando el flujo debía terminar la ejecución del CU, o RESUME_STEP(<id_paso>) si al terminar la ejecución del flujo, debía continuar la ejecución del CU en el paso <id_paso>.

50

El flujo FA1 se ejecuta cuando el usuario no ingresa la opción ‘Open File’, y al terminar su ejecución debe terminar la ejecución del CU; o sea que RFS es FP_2prima, la Condición de Flujo es Opcion<>’Open File’, y el último paso tiene una instrucción ABORT. El flujo FA2 se ejecuta cuando el nombre del archivo ingresado por el usuario no existe en el sistema, o sea que RFS es FP_3prima y Condición de Flujo es NombreDeArchivo IS_NOT_VALID. En este flujo el sistema le indica al usuario que no existe un archivo con ese nombre (paso FA2_1), y vuelve el sistema a pedirle al usuario que ingrese el nombre del archivo (paso FA2_2 RESUME_STEP (FP_2)). Flujo Alternativo Global Por último se definió el flujo alternativo global FG1. Este comienza a ejecutarse (el evento del Disparador) cuando el usuario presiona cualquiera de los botones cancelar. Y al terminar su ejecución termina de ejecutarse el CU, por esto es que tiene como último paso una instrucción ABORT, y como Poscondición que el sistema descarta los cambios realizados.

51

Nombre del CU

Load document from file

Descripción Carga un documento a partir de un archivo

Precondición

Actor Primario

Nombre User

Identificador Usuario

Sistema Nombre System

Sistema Sistema

Variables Operacionales

Nombre Tipo Descripción Dominio Condiciones de Validez

Condiciones de Invalidez

Opcion E Indica las opciones disponibles.

Conjunto {Open File, ...}

NombreDeArchivo E Nombre del archivo a abrir.

Cadena de Caracteres

Existe en el sistema un archivo con este nombre

NO existe en el sistema un archivo con este nombre

Flujo Principal Nombre Flujo Principal

Identificador FP

Pasos FP_1prima muestraDominio(Sistema , Opcion) FP_1 ingresaDatos(Usuario , {Opcion}) FP_2prima VALIDATES_THAT (Opcion = ‘Open File’) FP_2 muestraMensaje(Sistema, ‘Ingresar nombre del archivo’) FP_3 ingresaDatos(Usuario, {NombreDeArchivo}) FP_3prima VALIDATES_THAT (NombreDeArchivo IS_VALID) FP_4 muestraMensaje(Sistema, ‘El archivo se está cargando...’)

Poscondición El sistema muestra el archivo con nombre NombreDeArchivo.

Flujos Alternativos Específicos

Nombre FA1

Identificador FA1

Condición de Flujo

Opcion <>'Open File'

52

RFS FP_2prima

Pasos FA1_1 muestraMensaje(Sistema, ‘Seleccionar la opción “Open File”’) FA1_2 ABORT

Poscondición

Nombre FA2

Identificador FA2

Condición de Flujo

NombreDeArchivo IS_NOT_VALID

RFS FP_3prima

Pasos FA2_1 muestraMensaje(Sistema, 'No existe un archivo con ese nombre') FA2_2 RESUME_STEP(FP_2)

Poscondición

Flujos Alternativos Globales

Nombre FG1

Identificador FG1

Disparador El usuario presiona cualquiera de los botones Cancelar usados en el CU.

Pasos FG1_1 muestraMensaje(Sistema, 'Se cancela la operación de carga de archivos') FG1_2 ABORT

Poscondición El sistema descarta los cambios realizados

Tabla 7: Plantilla LFTestCU - Load document from file

53

3.2 Diagrama de Análisis

Como ya mencionó en la sección 3.3 Decisiones de Diseño el diagrama de análisis de TestCU es un diagrama de actividades que se genera a partir de la especificación en LFTestCU. En la Ilustración 18 se muestra el generado para el ejemplo. El vértice inicial se utiliza en el DA para representar el comienzo del flujo principal y el de cada uno de los flujos alternativos globales. Toda ejecución comienza en el primer paso del flujo principal, y un flujo alternativo global se puede disparar en cualquier momento de la ejecución ni bien suceda el evento especificado en el campo Disparador asociado a este flujo. En el ejemplo, hay una bifurcación en el vértice inicial por existir solamente un flujo alternativo global con nombre FG1. Cada vértice actividad del DA representa un paso de tipo acción de la especificación, que utiliza como identificador el mismo del paso. En el ejemplo los pasos de tipo acción se representan con las actividades FP_1prima, FP_1, FP_2, FP_3, FP_4, FG1_1, FA1_1 y FA2_1. Un paso con la forma sentencial RESUME_STEP (<id de un paso>) se representa como una actividad que es origen de una arista con destino en el vértice con identificador <id de un paso>. En el ejemplo hay solamente un RESUME_STEP en el paso FA2_2 que tiene como destino el vértice FP_2. Cada paso con la forma sentencial VALIDATES_THAT (<condición LFTestCU>) se representa en el DA como un vértice de decisión, en el que se bifurcan el flujo que se viene ejecutando del conjunto de flujos alternativos que referencian en el RFS este vértice. La condición asociada al VALIDATES_THAT determina la guarda del camino que continúa la ejecución del flujo que se viene ejecutando, y cada flujo alternativo específico que nace en este vértice tiene como guarda la Condición de Flujo que tiene asociada. Una ejecución del CU termina cuando alcanza el paso final del flujo principal, o cuando alcanza un paso con la forma sentencial ABORT. Por esto se utilizan los vértices finales para representar los pasos ABORT y la finalización del flujo principal. En el ejemplo hay tres vértices finales: FA1_2 y FG1_1 que representan los pasos ABORT; y el que se agrega a continuación del paso FP_4 que es el último paso del flujo principal.

54

Ilustración 18: Diagrama de Actividades - Load document from file

3.3 Generación de los CPA

Una vez generado el diagrama de análisis se derivan los CPA utilizando el criterio de cobertura Verificación y Validación, como se mencionó en la sección 3.3 Decisiones de Diseño. El algoritmo que se implementó para aplicar el criterio se resume en dos pasos:

1. Generar de los caminos simples con el algoritmo Búsqueda Primero en Profundidad (DFS - Depth First Search)[FING_IO].

2. Interpretar semánticamente estos caminos para generar los CPA.

55

Generación de los Caminos Simples usando DFS Usando DFS se toma el vértice inicial del DA como raíz y se comienza a construir un camino. El camino continúa hasta que se llega a un vértice final o hasta que se llega a un vértice RESUME_STEP, porque los caminos que se generan con DFS son caminos simples (o sea que no pueden tener vértices repetidos). Una vez que termina el camino, se retrocede hasta el vértice de decisión previo (backtrack), y se comienza a construir un nuevo camino utilizando otra decisión. Este algoritmo se resume en el siguiente pseudocódigo:

x, v pertenecen al conjunto de vértices del DA. DFS(x)

Visite y marque x Mientras exista un vértice v no marcado adyacente a x

DFS(v) fin mientras

fin Interpretación Semántica para generar los CPA Cada uno de estos caminos generados se interpreta semánticamente para derivar un CPA; recordar que un camino representa el conjunto de pasos del CU que se ejecutan para un CPA. Como ya se mencionó en la sección 1 Introducción , en este proyecto se utiliza el término Caso de Prueba Abstracto (CPA) para referenciar los casos de prueba que se generan con TestCU. Estos se diferencian de los casos de prueba con datos (que son los que se ejecutan para realizar las pruebas) en que en vez de los datos muestran las condiciones que deben cumplir estos para generar la salida esperada. A un CPA lo componen los siguientes atributos:

Nombre, es una cadena de caracteres para identificarlo.

Disparador, es el evento que dispara la ejecución del camino que tiene asociado, el camino debe ser un flujo alternativo global.

El conjunto de las condiciones que deben cumplir las variables operacionales (hay una columna por VO) para que se ejecute el camino asociado. Las VO de salida forman parte del resultado esperado.

Mensajes de Salida, es la secuencia de mensajes que se espera que despliegue el sistema durante la ejecución del camino asociado. Estos forman parte del resultado esperado.

Siguiente Paso, cuando el camino asociado no termina en un vértice final del DA, este atributo es el identificador del siguiente paso del CU que se debería ejecutar.

Poscondición, es el conjunto de condiciones que deben cumplirse al terminar la ejecución del camino asociado.

Cada camino simple se interpreta semánticamente, para derivar el CPA que tiene asociado, con el siguiente algoritmo:

56

Para cada camino simple que comienza en el vértice inicial del DA y que finaliza en el último paso de un flujo:

1. Se llenan las Variables Operacionales en función de las guardas que cumple camino. Una VO queda sin valor asignado cuando no influye en el resultado esperado del CPA.

2. Los Mensajes de Salida se llenan con los pasos del camino que tienen las acciones muestraMensaje, muestraDominio y muestraDatos.

3. Si el último paso del camino tiene la forma sentencial RESUME_STEP entonces el identificador del paso asociado a esta es el valor del Siguiente Paso.

4. La Poscondición es la poscondición (valor del campo Poscondición de la Plantilla LFTestCU) que tiene asociada el flujo al que pertenece el último de los pasos del camino.

5. Si el camino corresponde a un flujo alternativo global, entonces el Disparador del CPA es el valor que tiene asociado el flujo en el campo Disparador de la Plantilla LFTestCU.

La Tabla 8 muestra el conjunto de los CPA que se derivan en el ejemplo.

57

Nombre del Caso de Prueba

Disparador Opcion NombreDeArchivo Mensajes de Salida

Siguiente Paso

Poscondición

FP =’Open File’ IS_VALID 1) El sistema muestra el dominio de la variable: Opcion.

2) Ingresar nombre del archivo.

3) El archivo se está cargando...

El sistema muestra el archivo de la variable Archivo.

FP+FA1 <>’Open File’ 1) El sistema muestra el dominio de la variable: Opcion.

2) Seleccionar la opción “Open File”’

FP+FA2 =’Open File’ IS_NOT_VALID 1) El sistema muestra el dominio de la variable: Opcion.

2) Ingresar nombre del

FP.2

58

Nombre del Caso de Prueba

Disparador Opcion NombreDeArchivo Mensajes de Salida

Siguiente Paso

Poscondición

archivo. 3) No existe

un archivo con ese nombre

FG1 El usuario presiona cualquiera de los botones Cancelar usados en el CU.

1) Se cancela la operación de carga de archivos

El sistema descarta los cambios realizados

Tabla 8: Matríz de los CPA

59

3.4 Arquitectura

En esta sección se describe a muy alto nivel los módulos (subsystem) que componen TestCU y su interacción, no busca especificar el funcionamiento de estos. Son cuatro los módulos que componen TestCU:

Vista

Analizador Sintáctico

Caso de Uso

Diagrama de Actividades La Vista es el módulo que implementa la interfaz con el usuario. La componen: (a) una ventana en la que el usuario ingresa los nombres de los archivos de entrada y de salida, y un botón para ejecutar el procedimiento de generación de la planilla Excel que representa los CPA; y (b) el procedimiento. Este procedimiento primero solicita al módulo Analizador Sintáctico que genere el modelo del caso de uso, a partir de la especificación, escrita en el lenguaje LFTestCU, del archivo de entrada. El módulo Analizador Sintáctico construye el modelo del CU utilizando el módulo Caso de Uso. El procedimiento termina generando la planilla Excel como archivo de salida, solicitando al módulo Caso de Uso el conjunto de los CPA a probar. El módulo Analizador Sintáctico es un analizador sintáctico y semántico que genera, utilizando el módulo Caso de Uso, un modelo de CU a partir de su especificación en LFTestCU. El módulo Caso de Uso modela y gestiona toda la información asociada al CU. Este incluye la información que no es relevante para generar los CPA (por ej: nombre del CU, descripción, precondiciones) y el diagrama de análisis. Este diagrama es el encargado de obtener los escenarios a probar e interpretarlos semánticamente para generar los CPA. La estructura del diagrama de análisis la representa el módulo Diagrama de Actividades como un diagrama de actividades, en el que cada vértice representa un paso del CU. Por esto cada camino del diagrama de actividades representa un escenario del CU. Para generar los CPA el módulo Caso de Uso obtiene a partir del módulo Diagrama de Actividades los caminos que representan los escenarios a probar, y luego los interpreta semánticamente.

60

Ilustración 19: Arquitectura de TestCU

Implementación de los Módulos La herramienta TestCU es una aplicación de escritorio (desktop) que ejecuta totalmente en la máquina del usuario. Se implementó para Java 1.6, y se utilizaron en su implementación la herramienta JavaCC [JavaCC_soft] para el módulo Analizador Sintáctico, y la librería Apache POI [POI] de Java para el procedimiento del módulo Vista que genera la planilla Excel. JavaCC (Java Compiler Compiler – Metacompilador en Java) es una herramienta para generar analizadores sintácticos descendentes, que tiene como principales características:

Las especificaciones léxicas y sintácticas se ubican en un solo archivo, por esto la gramática puede ser leída y mantenida más fácilmente.

Admite el uso de estados léxicos y la capacidad de agregar acciones léxicas incluyendo un bloque de código Java tras el identificador de un token.

Adopta una notación BNF [BNF] propia mediante la utilización de símbolos propios de expresiones regulares, tales como (A)*, (A)+.

Genera por defecto un analizador sintáctico LL(1) [fing_dc]. No obstante, puede haber porciones de la gramática que no sean LL(1), lo que es resuelto en JavaCC mediante la posibilidad de resolver las ambigüedades desplazar/desplazar localmente en el punto del conflicto. En otras palabras, permite que el a.si. se transforme en LL(k) [fing_dc] sólo en tales puntos, pero se conserva LL(1) en el resto de las reglas mejorando la eficiencia.

JavaCC está siendo mantenido actualmente por el grupo java.net de código abierto, y la documentación oficial puede encontrarse en el sitio https://javacc.dev.java.net. Dicha documentación es demasiado formal y no incorpora ningún tutorial de aprendizaje.

Apache POI - the Java API for Microsoft Documents es un API (Application Programming Interface) desarrollado por Apache Software Foundation, que provee librerías Java para leer y escribir documentos Microsoft como por ejemplo Word, Excel y PowerPoint.

61

4 Caso de Estudio Se utiliza este capítulo para mostrar una forma de especificar formalmente con el lenguaje LFTestCU el caso de uso Retiro para el cajero automático [iis cu], y el procedimiento que realiza la herramienta TestCU para generar los CPA. Se selecciona el CU Retiro por ser utilizado en la materia Ingeniería de Software de la Facultad de Ingeniería de la UDELAR, para introducir a los alumnos en los CU. Este capítulo está compuesto por las siguientes secciones:

Especificación del CU presentada en el documento del que se tomó el ejemplo.

Descripción del CU utilizando la Plantilla LFTestCU.

Representación XML de la plantilla LFTestCU

Diagrama de Actividades que se obtiene transformando la plantilla XML

Matriz con los Casos de Prueba Abstractos generados El caso de uso Retiro para el Cajero Automático

o Ejemplo sacado del documento http://www.fing.edu.uy/inco/cursos/iis/wikiIIS/uploads/Material/IngReq2010-P3.ppt de la página de materiales de la materia Introducción a la Ingeniería de Software de la Facultad de Ingeniería de la UDELAR

o Se selecciona este CU por ser usado por la UDELAR para introducir a los estudiantes en los CU

o Para mostrar la forma de representar en LFTestCU los pasos del CU que involucran actores secundarios

4.1 Especificación en Lenguaje Natural

En esta es la especificación del CU presentada en el documento [iis cu] del que se tomó el ejemplo. Actor principal: Cliente Actores: Servicio de Cajeros (SC) Caso de Uso: Retirar Descripción: Un cliente de un banco retira dinero de una cuenta a través del cajero automático utilizando una tarjeta bancaria, el Servicio de Cajeros verifica que el PIN sea válido y que el monto de la cuenta sea suficiente para realizar el retiro Flujo principal:

1. Cliente inserta una tarjeta bancaria en el lector del CA. 2. El CA lee el código de la tarjeta y verifica que es correcto 3. El CA pide el código de PIN de 4 dígitos 4. EL Cliente ingresa el PIN 5. El CA envía código de Tarjeta y PIN al SC 6. El SC verifica que el PIN sea correcto y contesta: OK

62

7. El CA despliega las distintas alternativas disponibles: retiro, depósito, consulta

8. El Cliente elige Retiro 9. El CA pide cuenta y monto 10. El Cliente los ingresa 11. CA envía código de Tarjeta, PIN, cuenta y monto al SC 12. El SC contesta: OK 13. El CA dispensa el dinero 14. El CA devuelve la tarjeta 15. El CA imprime el recibo

Flujos Alternativos: 2A. La tarjeta no es válida

1. El CA devuelve la tarjeta con el mensaje “tarjeta no válida” 2. Fin CU

6A. PIN inválido y menos de 3 intentos El Cliente puede realizar tres intentos para ingresar el PIN válido. Sino, el CA retiene la tarjeta.

1. El SC contesta indicando PIN inválido 2. El CA muestra el mensaje “PIN incorrecto” y sigue en punto 3

6B. PIN inválido y 3 intentos El CA debe retener la tarjeta

1. El SC contesta indicando PIN inválido 2. El CA muestra el mensaje “Se le retiene la tarjeta” 3. Fin CU

9A. El CA no tiene dinero

1. La opción “Retiro” en esta situación no es una alternativa posible, y el CA despliega la advertencia: “Sin dinero”.

2. Fin CU 11A. Monto insuficiente para el cajero El monto indicado por el cliente no puede obtenerse a partir de los billetes de que dispone el CA

1. El CA despliega el mensaje “No se cuenta con ese monto en este cajero” 2. Vuelve a 9.

12A. No hay suficiente saldo en la cuenta

1. CA despliega mensaje “Su saldo no permite extraer ese monto” 2. El CA devuelve la tarjeta 3. Fin CU

12B. No hay contacto con el Servicio de Cajeros (SC)

1. CA despliega el mensaje “sin conexión a la red de cajeros”

63

2. El CA devuelve la tarjeta 3. Fin CU

12C. Enlace con el computador central se cae durante la transacción Hay que asegurar que el SC considera sólo los retiros efectivamente realizados 14A. El dinero no es retirado de la bandeja

1. Si después de YY segundos el dinero está todavía en la bandeja, el CA lo recupera y lo deja en el depósito de dinero usado

2. Sigue en 14 14B. La tarjeta se tranca al intentar devolverla

1. CA trata de devolverla durante xx segundos. 2. Si en ese tiempo no puede devolverla, CA avisa a mantenimiento 3. Fin CU

4.2 Descripción utilizando la Plantilla LFTestCU

Nombre del CU

Retirar

Descripción Un cliente de un banco retira dinero de una cuenta a través del cajero automático utilizando una tarjeta bancaria, el Servicio de Cajeros verifica que el PIN sea válido y que el monto de la cuenta sea suficiente para realizar el retiro

Precondición

Actor Primario Nombre Cliente

Identificador Cliente

Sistema Nombre Cajero Automático

Identificador CA

Variables Operacionales

Nombre Tipo Descripción Dominio Condiciones de Validez

Condiciones de Invalidez

CodigoDeTarjeta

E Tiene el valor del código que lee el CA en la tarjeta ingresada por el cliente.

Código que se lee de la tarjeta introducida por el Cliente en el CA.

El código en la tarjeta ingresada por el usuario cumple con los requisitos que verifica el CA.

No cumple la CV

PIN E PIN ingresado al cliente por el Cliente

4 dígitos

Alternativa E Tiene las alternativas

{'Retiro', 'Depósito',

64

que permite realizar el CA.

'Consulta'}

Cuenta E Nro de cuenta ingresado por el cliente al CV

Conjunto de las cuentas pertenecientes a los bancos asociados al CA.

Monto E Monto ingresado al CA por el cliente

Número racional

El monto indicado por el cliente puede obtenerse a partir de los billetes de que dispone el CA.

No cumple la CV

PINCorrecto

EDS Es el resultado de la validación del PIN hecha por el SC .

'OK' o string distinto de 'OK'

HayDinero EDS Indica si hay dinero en el CV.

El CV tiene dinero.

No cumple la CV

RetiroCorrecto

EDS Indica el resultado de la solicitud de retiro ingresada por el usuario.

{'OK', 'No hay saldo', 'Sin conexión a SC'}

TiempoDesdeQueDispensaElDinero

EDS Indica el tiempo que lleva el dinero en la bandeja desde que el CA lo dispensó.

Cadena de Caracteres

TiempoDesdeQueDe

EDS Indica el tiempo que

Cadena de

65

vuelveLaTarjeta

lleva CA tratando de devolver la tarjeta.

Caracteres

NroDeIntentos

EDS Indica el nro de intentos del cliente para ingresar el PIN válido

Nro entero menor o igual a 3.

Flujo Principal Nombre Flujo Principal

Identificador FP

Pasos FP_1 ingresaDatos(Cliente, {CodigoDeTarjeta}) FP_2 VALIDATES_THAT (CodigoDeTarjeta IS_VALID) FP_3 muestraMensaje(CA, 'Ingrese el código de PIN de 4 dígitos') FP_4 ingresaDatos(Cliente, {PIN}) FP_6 generaDatos(CA, IN {PIN, CodigoDeTarjeta}, OUT {PINCorrecto}) FP_6_1 VALIDATES_THAT (PINCorrecto = 'OK') FP_7 muestraDominio(CA, Alternativa) FP_8 ingresaDatos(Cliente, {Alternativa}) FP_8_1 VALIDATES_THAT (Alternativa='Retiro') FP_8_2 generaDatos(CA, IN{}, OUT{HayDinero}) FP_8_3 VALIDATES_THAT (HayDinero IS_VALID) FP_9 muestraMensaje(CA, 'Ingese la cuenta y el monto a retirar') FP_10 ingresaDatos(Cliente, {Cuenta, Monto}) FP_10_1 VALIDATES_THAT (Monto IS_VALID) FP_11 generaDatos(CA, IN {CodigoDeTarjeta, PIN, Cuenta, Monto}, OUT {RetiroCorrecto}) FP_12 VALIDATES_THAT (RetiroCorrecto = 'OK') FP_13 generaDatos(CA, IN {}, OUT{TiempoDesdeQueDispensaElDinero}) FP_13_1 VALIDATES_THAT (TiempoDesdeQueDispensaElDinero <= 'YY segundos') FP_14 generaDatos(CA, IN {}, OUT{TiempoDesdeQueDevuelveLaTarjeta}) FP_14_1 VALIDATES_THAT (TiempoDesdeQueDevuelveLaTarjeta <= 'XX segundos') FP_14_2 muestraMensaje(CA, 'El retiro terminó correctamente')

Poscondición (1) El CA dispensa el monto (2) El CA devuelve la tarjeta (3) El CA imprime recibo

Flujos Alternativos

Nombre La tarjeta no es válida

66

Específicos

Identificador FA2A

Condición de Flujo CodigoDeTarjeta IS_NOT_VALID

RFS FP_2

Pasos FP2A_1 muestraMensaje(CA, 'Tarjeta no válida') FP2A_ ABORT

Poscondición El CA devuelve la tarjeta.

Nombre PIN inválido y menos de 3 intentos

Identificador FA6A

Condición de Flujo PINCorrecto <> ‘OK’

RFS FP_6_1

Pasos FA6A_1 generaDatos(CA, IN{NroDeIntentos},OUT{NroDeIntentos}) FA6A_2 VALIDATES_THAT (NroDeIntentos < '3') FA6A_3 muestraMensaje(CA, 'PIN incorrecto') FA6A_4 RESUME_STEP (FP_3)

Poscondición

Nombre PIN inválido y 3 intentos

Identificador FA6B

Condición de Flujo NroDeIntentos = '3'

RFS FA6A_2

Pasos FA6B_1 muestraMensaje(CA, 'Se le retiene la tarjeta') FA6B_2 ABORT

Poscondición El cajero retiene la tarjeta

Nombre El CA no tiene dinero

Identificador FA9A

Condición de Flujo HayDinero IS_NOT_VALID

RFS FP_8_3

Pasos FA9A_1 muestraMensaje(CA, 'Sin dinero') FA9A_ ABORT

Poscondición

Nombre Monto insuficiente para el cajero

Identificador FA11A

Condición de Flujo Monto IS_NOT_VALID

RFS FP_10_1

Pasos FA11A_1 muestraMensaje(CA,'No se cuenta con ese monto en este cajero') FA11A_2 RESUME_STEP(FP_9)

Poscondición

Nombre No hay suficiente saldo en la cuenta

67

Identificador FA12A

Condición de Flujo RetiroCorrecto = ‘No hay saldo’

RFS FP_12

Pasos FA12A_1 muestraMensaje(CA, 'Su saldo no permite extraer ese monto') FA12A_2 ABORT

Poscondición El CA devuelve la tarjeta

Nombre No hay contacto con el Servicio de Cajeros (SC)

Identificador FA12B

Condición de Flujo RetiroCorrecto = ‘Sin conexión a SC’

RFS FP_12

Pasos FA12B_1 muestraMensaje(CA, 'Sin conexión a la red de cajeros') FA12B_2 ABORT

Poscondición El CA devuelve la tarjeta

Nombre El dinero no es retirado de la bandeja.

Identificador FA14A

Condición de Flujo TiempoDesdeQueDispensaElDinero > 'YY segundos'

RFS FP_13_1

Pasos FP14A_1 RESUME_STEP (FP_14)

Poscondición El CA recupera el dinero y lo deja en el depósito de dinero usado.

Nombre La tarjeta se tranca al intentar devolverla

Identificador FA14B

Condición de Flujo TiempoDesdeQueDevuelveLaTarjeta > 'XX segundos'

RFS FP_14_1

Pasos FP14B_1 ABORT

Poscondición El CA avisa a mantenimiento

Flujos Alternativos Globales

Tabla 9: Plantilla LFTestCU - Retirar

4.3 Especificación en LFTestCU

En esta sección se muestra una parte de la especificación del CU escrita en LFTestCU. No se muestra toda por la cantidad de líneas, se puede ver la especificación completa en el Anexo B – Especificación LFTestCU de Retiro. <CU nombre="Retirar"

68

descripcion="Un cliente de un banco retira dinero de una cuenta a través del cajero automático utilizando una tarjeta bancaria, el Servicio de Cajeros verifica que el PIN sea válido y que el monto de la cuenta sea suficiente para realizar el retiro"> <precondicion> "" </precondicion> <actorPrimario id="Cliente" nombre="Cliente"/> <sistema id="CA" nombre="Cajero Automático"/> <variablesOperacionales> <VO id="CodigoDeTarjeta" tipo="E" descripcion="Tiene el valor del código que lee el CA en la tarjeta ingresada por el cliente."> <dominio>

"Código que se lee de la tarjeta introducida por el Cliente en el CA."

</dominio> <CV>

"El código en la tarjeta ingresada por el usuario cumple con los requisitos que verifica el CA."

</CV> <CI> "No cumple la CV" </CI> </VO> . . . <VO id="NroDeIntentos" tipo="EDS"

descripcion="Indica el nro de intentos del cliente para ingresar el PIN válido">

<dominio> "Nro entero menor o igual a 3." </dominio> <CV>

69

"" </CV> <CI> "" </CI> </VO> </variablesOperacionales> <flujoPrincipal id="FP" nombre="Flujo Principal"> <paso id="FP_1"> ingresaDatos(Cliente, {CodigoDeTarjeta}) </paso> <paso id="FP_2"> VALIDATES_THAT (CodigoDeTarjeta IS_VALID) </paso> <paso id="FP_3"> muestraMensaje(CA, 'Ingrese el código de PIN de 4 dígitos') </paso> <paso id="FP_4"> ingresaDatos(Cliente, {PIN}) </paso> <paso id="FP_6"> generaDatos(CA, IN {PIN, CodigoDeTarjeta}, OUT {PINCorrecto}) </paso> <paso id="FP_6_1"> VALIDATES_THAT (PINCorrecto = 'OK') </paso> <paso id="FP_7"> muestraDominio(CA, Alternativa) </paso> <paso id="FP_8"> ingresaDatos(Cliente, {Alternativa}) </paso> <paso id="FP_8_1"> VALIDATES_THAT (Alternativa='Retiro') </paso>

70

<paso id="FP_8_2"> generaDatos(CA, IN{}, OUT{HayDinero}) </paso> <paso id="FP_8_3"> VALIDATES_THAT (HayDinero IS_VALID) </paso> <paso id="FP_9"> muestraMensaje(CA, 'Ingese la cuenta y el monto a retirar') </paso> <paso id="FP_10"> ingresaDatos(Cliente, {Cuenta, Monto}) </paso> <paso id="FP_10_1"> VALIDATES_THAT (Monto IS_VALID) </paso> <paso id="FP_11"> generaDatos(CA, IN {CodigoDeTarjeta, PIN, Cuenta, Monto}, OUT {RetiroCorrecto}) </paso> <paso id="FP_12"> VALIDATES_THAT (RetiroCorrecto = 'OK') </paso> <paso id="FP_13"> generaDatos(CA, IN {}, OUT{TiempoDesdeQueDispensaElDinero}) </paso> <paso id="FP_13_1">

VALIDATES_THAT (TiempoDesdeQueDispensaElDinero <= 'YY segundos')

</paso> <paso id="FP_14"> generaDatos(CA, IN {}, OUT{TiempoDesdeQueDevuelveLaTarjeta}) </paso> <paso id="FP_14_1"> VALIDATES_THAT (TiempoDesdeQueDevuelveLaTarjeta <= 'XX segundos') </paso>

71

<paso id="FP_14_2"> muestraMensaje(CA, 'El retiro terminó correctamente') </paso> <poscondicion> " (1) El CA dispensa el monto (2) El CA devuelve la tarjeta (3) El CA imprime recibo " </poscondicion> </flujoPrincipal> <flujosAlternativosEspecificos> <FAE id="FA2A" nombre="La tarjeta no es válida"> <condicionFAE> CodigoDeTarjeta IS_NOT_VALID </condicionFAE> <RFS id="FP_2"/> <paso id="FP2A_1"> muestraMensaje(CA, 'Tarjeta no válida') </paso> <paso id="FP2A_"> ABORT </paso> <poscondicion> "El CA devuelve la tarjeta." </poscondicion> </FAE> . . . <FAE id="FA14B" nombre="La tarjeta se tranca al intentar devolverla"> <condicionFAE> TiempoDesdeQueDevuelveLaTarjeta > 'XX segundos' </condicionFAE> <RFS id="FP_14_1"/>

72

<paso id="FP14B_1"> ABORT </paso> <poscondicion> "El CA avisa a mantenimiento" </poscondicion> </FAE> </flujosAlternativosEspecificos> <flujosAlternativosGlobales> </flujosAlternativosGlobales> </CU>

73

4.4 Diagrama de Actividades

El diagrama de actividades que se muestra a continuación se genera a partir de la especificación en LFTestCU presentada en la sección 5.3 Especificación en LFTestCU.

74

Ilustración 20: Diagrama de Actividades del CU Retiro

75

4.5 Matriz con los Casos de Prueba Abstractos

Id del CP

Disparador

PIN Correcto

Nro De Intentos

Cuenta Tiempo Desde Que Devuelve La Tarjeta

Retiro Correcto

Hay Dinero

Monto PIN TiempoDesde Que Dispensa El Dinero

Alternativa

Codigo De Tarjeta

Mensajes de Salida

Siguiente Paso

Poscondición

CP1 IS_NOT_VALID

(1) Tarjeta no válida

El CA devuelve la tarjeta.

CP2 = 'OK' > 'XX segundos'

= 'OK' IS_VALID

IS_VALID

<= 'YY segundos'

= 'Retiro'

IS_VALID

(1) Ingrese el código de PIN de 4 dígitos. (2) El sistema muestra el dominio de la variable: Alternativa. (3) Ingese la cuenta y el monto a retirar

El CA avisa a mantenimiento

CP3 <> 'OK' = '3' IS_VALID

(1) Ingrese el código de PIN de 4 dígitos.

El cajero retiene la tarjeta

76

Id del CP

Disparador

PIN Correcto

Nro De Intentos

Cuenta Tiempo Desde Que Devuelve La Tarjeta

Retiro Correcto

Hay Dinero

Monto PIN TiempoDesde Que Dispensa El Dinero

Alternativa

Codigo De Tarjeta

Mensajes de Salida

Siguiente Paso

Poscondición

(2) Se le retiene la tarjeta

CP4 = 'OK' IS_VALID

IS_NOT_VALID

= 'Retiro'

IS_VALID

(1) Ingrese el código de PIN de 4 dígitos. (2) El sistema muestra el dominio de la variable: Alternativa. (3) Ingese la cuenta y el monto a retirar. (4) No se cuenta con ese monto en este cajero

FP_9

CP5 <> 'OK' < '3' IS_VALID

(1) Ingrese el

FP_3

77

Id del CP

Disparador

PIN Correcto

Nro De Intentos

Cuenta Tiempo Desde Que Devuelve La Tarjeta

Retiro Correcto

Hay Dinero

Monto PIN TiempoDesde Que Dispensa El Dinero

Alternativa

Codigo De Tarjeta

Mensajes de Salida

Siguiente Paso

Poscondición

código de PIN de 4 dígitos. (2) PIN incorrecto

CP6 = 'OK' = 'OK' IS_VALID

IS_VALID

> 'YY segundos'

= 'Retiro'

IS_VALID

(1) Ingrese el código de PIN de 4 dígitos. (2) El sistema muestra el dominio de la variable: Alternativa. (3) Ingese la cuenta y el monto a retirar

FP_14 El CA recupera el dinero y lo deja en el depósito de dinero usado.

CP7 = 'OK' = 'No hay saldo'

IS_VALID

IS_VALID

= 'Retiro'

IS_VALID

(1) Ingrese el código de PIN de 4 dígitos.

El CA devuelve la tarjeta

78

Id del CP

Disparador

PIN Correcto

Nro De Intentos

Cuenta Tiempo Desde Que Devuelve La Tarjeta

Retiro Correcto

Hay Dinero

Monto PIN TiempoDesde Que Dispensa El Dinero

Alternativa

Codigo De Tarjeta

Mensajes de Salida

Siguiente Paso

Poscondición

(2) El sistema muestra el dominio de la variable: Alternativa. (3) Ingese la cuenta y el monto a retirar. (4) Su saldo no permite extraer ese monto

CP8 = 'OK' = 'Sin conexión a SC'

IS_VALID

IS_VALID

= 'Retiro'

IS_VALID

(1) Ingrese el código de PIN de 4 dígitos. (2) El sistema muestra el dominio de la variable: Alternativa.

El CA devuelve la tarjeta

79

Id del CP

Disparador

PIN Correcto

Nro De Intentos

Cuenta Tiempo Desde Que Devuelve La Tarjeta

Retiro Correcto

Hay Dinero

Monto PIN TiempoDesde Que Dispensa El Dinero

Alternativa

Codigo De Tarjeta

Mensajes de Salida

Siguiente Paso

Poscondición

(3) Ingese la cuenta y el monto a retirar. (4) Sin conexión a la red de cajeros

CP9 = 'OK' <= 'XX segundos'

= 'OK' IS_VALID

IS_VALID

<= 'YY segundos'

= 'Retiro'

IS_VALID

(1) Ingrese el código de PIN de 4 dígitos. (2) El sistema muestra el dominio de la variable: Alternativa. (3) Ingese la cuenta y el monto a retirar. (4) El

(1) El CA dispensa el monto (2) El CA devuelve la tarjeta (3) El CA imprime recibo

80

Id del CP

Disparador

PIN Correcto

Nro De Intentos

Cuenta Tiempo Desde Que Devuelve La Tarjeta

Retiro Correcto

Hay Dinero

Monto PIN TiempoDesde Que Dispensa El Dinero

Alternativa

Codigo De Tarjeta

Mensajes de Salida

Siguiente Paso

Poscondición

retiro terminó correctamente

CP10 = 'OK' IS_NOT_VALID

= 'Retiro'

IS_VALID

(1) Ingrese el código de PIN de 4 dígitos. (2) El sistema muestra el dominio de la variable: Alternativa. (3) Sin dinero

81

5 Conclusiones y Trabajos a Futuro Resultaron de este proyecto: (a) un análisis de un conjunto de técnicas para procesar casos de uso, (b) un lenguaje, denominado LFTestCU, para especificar formalmente casos de uso, y (c) una herramienta, denominada TestCU, que a partir de la especificación formal de un CU en LFTestCU, genera automáticamente un conjunto de casos de prueba abstractos para probar el CU. En el documento [RSBorInv], que es el resumen de la investigación, se puede revisar con mayor detalle las técnicas. Revisión de los Objetivos del Proyecto En la Introducción se presentaron los objetivos del proyecto en función de un resumen del procedimiento de pruebas funcionales, y este procedimiento se utiliza a continuación para revisar los objetivos:

1. Entender el comportamiento del sistema revisando los requerimientos funcionales. Se creó el lenguaje formal LFTestCU para especificar formalmente casos de uso, estos son utilizados para especificar el comportamiento del sistema. Esto se decidió porque, como lo muestra el documento [RSBorInv], se investigó mucho material pero no se encontró un lenguaje formal para especificar casos de uso que pueda interpretarse semánticamente. Lo más cercano a un lenguaje formal que se encontró es RUCM (Restricted Use Case Modeling), que es un modelo para especificar los casos de uso utilizando una plantilla y un conjunto de reglas que restringen el lenguaje natural de la especificación.

2. Pensar y diseñar los casos de prueba. La automatización de este paso es la contribución del proyecto. Se logró crear la herramienta TestCU que a partir de la especificación de un CU en LFTestCU, genera automáticamente una planilla Excel con el conjunto de los CPA.

3. Ejecución de las pruebas. La principal causa de que no se invirtiera tiempo investigando sobre la automatización de esta ejecución, fue el abandono de uno de los alumnos al comenzar el proyecto. Sin embargo es importante aclarar que esta investigación implica un alto costo de tiempo, por los temas que la componen (ver la Ilustración 1: Objetivos del Proyecto):

o Determinar la información complementaria a la especificación del CU, necesaria para automatizar la generación del script de prueba.

o Investigar por un lenguaje formal para especificar los Scripts de Prueba Abstractos.

o Diseñar e implementar el Framework TestCU, que extiende la herramienta TestCU, y brinda una interface que el desarrollador debe implementar con el objetivo de generar los scripts de pruebas específicos para una plataforma de pruebas específica. Entre los objetivos iniciales del proyecto estaba utilizar como plataforma de pruebas Oracle Testing Suite [OATS].

o Investigar la posibilidad de automatizar la generación de oráculos que automáticamente realicen la evaluación de la ejecución de las pruebas.

82

Desarrollo del Proyecto Etapas del proyecto:

04/2011 – 02/2012, se investigaron: (a) la existencia de lenguajes formales para especificar casos de uso; (b) técnicas para modelar formalmente casos de uso; y (c) técnicas para probar casos de uso.

03/2012 – 07/2012, se definió la gramática formal del lenguaje LFTestCU.

07/2012 – 02/2013, se realizó la implementación. Que consistió en: (a) la investigación de herramientas para construir analizadores lexicográficos y sintácticos, (b) el diseño de TestCU, (c) la implementación del procedimiento para modelar automáticamente los CU, (d) la implementación del procedimiento para generar los CPA a partir del modelo del CU, y (e) el analizador sintáctico que genera automáticamente el modelo del CU a partir de la especificación en LFTestCU.

02/2013 – al día de hoy, la generación del informe final del proyecto. Evaluación personal del Proyecto Cumplí con los objetivos del proyecto al lograr implementar la herramienta TestCU, ver en este capítulo la Revisión de los Objetivos del Proyecto. No hay mucha documentación sobre lenguajes formales para especificar casos de uso, como muestra el documento [RSBorInv] que es el resumen de la investigación realizada en este proyecto. Logré desarrollar una técnica que me ayuda en mi trabajo, soy un técnico en desarrollo de software:

Utilizo LFTestCU para especificar el CU que describe la funcionalidad a implementar / modificar

A partir del diagrama de actividades y el algoritmo genero los CPA a utilizar en la prueba funcional.

En relación a la investigación:

Me aportó mucho el tener que revisar temas en los que no tenía mucho conocimiento: (a) técnicas para modelar el comportamiento de un sistema, (b) técnicas para probar el comportamiento de un sistema, (c) definición de lenguajes formales y su interpretación semántica; entre otros.

Despertó mi interés por seguir investigando. Por ejemplo el procesamiento del lenguaje natural.

Comprendí que la investigación es toda una ciencia. La falta de conocimientos sobre investigación influyó en la duración del proyecto.

Trabajos a Futuro Las dos principales limitaciones del lenguaje LFTestCU, que están entre los primeros trabajos a futuro, son: (a) que no permite representar la interacción del sistema con actores secundarios, sin embargo se puede representar el procesamiento del sistema de los datos de esta interacción utilizando una acción

83

generaDatos; y (b) no permite representar las relaciones entre casos de uso [iis cu], son Extend, Include, Generalization. Otro de los trabajos a futuro es desarrollar una GUI (Graphic User Interface) que haga más amigabe TestCU automatizando la generación de la especificación a partir de la Plantilla LFTestCU. La especificación es un archivo XML, y aunque es simple generarla a partir de la Plantilla LFTestCU, el usuario debe escribir la especificación a mano. En el capítulo 5 Caso de Estudio se utiliza el caso de uso Retirar para el cajero automático [iis cu], que fue seleccionado por ser utilizado en la materia Introducción a la Ingeniería de Software de la Facultad de Ingeniería de la UDELAR para introducir a los estudiantes en los Casos de Uso. En este caso de estudio se busca mostrar:

a. que no es difícil llenar una Plantilla LFTest y escribir la especificación a mano, que es un archivo XML, a partir de esta plantilla. Pero es importante resaltar que depende del que escribe saber qué especificar del CU. Por ejemplo: las variables operacionales a utilizar; la forma de escribir algunos de los pasos escritos en el lenguaje natural utilizando el lenguaje formal LFTestCU.

b. el procedimiento que realiza TestCU para generar automáticamente los CPA a partir de la especificación en LFTestCU.

Pero es necesario realizar un estudio sobre de la utilidad, simplicidad y dominio de las especificaciones escritas en LFTestCU. Quedan planteadas como extensiones a este trabajo:

Investigar la posibilidad de agregar a LFTestCU instrucciones para trabajar con actores secundarios, e instrucciones para interactuar con otros casos de uso (incluir, extender y generalizar) [iis_cu]

Investigar el nivel de automatización al que se puede llegar para generar un script de pruebas a partir de la especificación del CU en LFTestCU:

o Qué información adicional es necesaria para complementar la especificación del CU (ver ilustración)

o Cuáles son los tipos de diagrama de análisis que se pueden usar para representar los casos de uso y qué formas ha de recorrerlos para generar casos de prueba.

84

6 Glosario

A Automatizar, tareas entorno al objetivo de generar pruebas implementadas de tal manera que se puedan ejecutar de forma desatendida.

C Camino, en este proyecto un camino es una secuencia de vértices dentro de un diagrama de actividades tal que exista una arista entre cada vértice y el siguiente. Camino Simple, Un camino es simple cuando no repite vértices. Caso de Prueba (CP), en inglés test case, es un conjunto de datos de entrada, condiciones de ejecución y resultados esperados. Para hacer una prueba se ejecuta el caso de prueba y se compara el resultado esperado con el obtenido. Caso de Prueba Abstracto (CPA), en este proyecto se define con este concepto a un caso de prueba usado para probar uno de los escenarios de un caso de uso particular. Consta de (a) un nombre para referenciarlo, (b) un disparador, (c) un conjunto de valores de las variables operacionales, (d) los resultados esperados. Los resultados esperados lo componen, la secuencia de los mensajes de salida, el siguiente paso del caso de uso a ejecutar cuando termina la prueba, las condiciones que deben cumplirse al terminar la prueba. Criterio de Cobertura, en este proyecto se define este concepto como el conjunto de los escenarios del caso de uso seleccionados para hacer las pruebas. Este es una medida de la cantidad que estamos probando. Correctitud, es una adaptación de la palabra inglesa correctness. Un programa es funcionalmente correcto si se comporta de acuerdo a la especificación de las funciones (especificación de requerimientos funcionales) que debería proveer.

D Derivación, las pruebas dirigidas por modelos (model-driven testing) requieren derivación sistemática y en lo posible automatizada de las pruebas a partir de modelos Diagrama de Análisis de un Caso de Uso, es una forma de representar el caso de uso de forma que permita automatizar el procesado de la información que este brinda.

E

85

Escenario, es una forma particular de usar el sistema, un camino a través de un caso de uso.

F Falta, en inglés fault, se entiende como la causa de un mal funcionamiento del programa. Falla, en inglés failure, es un comportamiento no deseado de alguno de los servicios brindados por el programa, sin embargo debe ser tenido en cuenta que toda falla es causa de una falta. Forma Sentencial, dada una gramática formal, una forma sentencial es una tira de símbolos terminales y no terminales que compone una sentencia de la gramática.

I Interpretación Semántica, dado un lenguaje formal, la interpretación es básicamente una asignación de significados a sus palabras.

L Lenguaje Formal (LF), es un conjunto (finito o infinito) de cadenas finitas de símbolos, dichas cadenas están formadas gracias a un alfabeto y a una gramática que están formalmente especificados. El alfabeto es un conjunto finito no vacío de símbolos, y la gramática es un conjunto finito de reglas para formar cadenas finitas juntando símbolos del alfabeto. A cada cadena de símbolos de un lenguaje formal se le llama palabra del lenguaje.

P Perfil de Pruebas de UML (UMLTP), en inglés UML Testing Profile, es un lenguaje estandarizado basado en el Lenguaje de Modelado Unificado (UML) de OMG. Es usado para diseñar, visualizar, especificar, analizar, construir y documentar los artefactos de un sistema de pruebas. Y se basa en el metamodelo de UML y reutiliza su sintaxis definiendo conceptos para observar el comportamiento de las pruebas y las actividades durante las pruebas, arquitectura de las pruebas, datos de pruebas y tiempo. Producción, es una regla perteneciente a una gramática formal. A partir del conjunto de producciones de la gramática se derivan las sentencias del lenguaje representado por la gramática. Prueba, en inglés test, es el proceso de ejecutar un programa con el fin de encontrar fallas. La prueba demuestra la presencia de faltas, nunca su ausencia.

86

S Script de Prueba, código de un caso de prueba implementado en algún lenguaje de programación o lenguaje propio de alguna herramienta. Semántica es el estudio del significado que se comunica a través del lenguaje. Semántica Formal, es el estudio de las interpretaciones semánticas de los lenguajes formales. Sentencia, Dada una gramática formal, se le llama sentencia a una cadena de símbolos terminales que se deriva de esta gramática. Sintaxis, estudio de la estructuración (orden y agrupamiento) de las palabras en unidades mayores.

T Técnica Tester, persona encargada de ejecutar tareas relacionadas con la verificación de un programa. Transformación de Modelos, es el proceso de convertir un modelo en otro para el mismo sistema, usándose un lenguaje para describir dicha transformación. Una transformación establece un conjunto de reglas que describen como un modelo expresado en un lenguaje origen puede ser transformado en un modelo en un lenguaje destino.

V Validación, es el proceso de evaluar un sitema o componente de este durante o al final del proceso de desarrollo, para determinar si el sistema cumple con los requerimientos especificados (funcionales y no funcionales). Verificación, es el proceso de evaluar un sitema o componente para dererminar si los productos de una fase del desarrollo cumple las condiciones fijadas al comienzo de la fase. Variable Operacional (VO), representa un dato relevante en el caso de uso. Los valores de las variables operacionales determinan el resultado del caso de uso. Hay tres tipos de variables, las ingresadas por el usuario, las que determinan el estado del sistema, las que devuelve el sistema.

87

7 Referencias [SWEBOK] IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK), versión 2004, capítulo 5 Software Testing. Disponible en línea en http://www.computer.org/portal/web/swebok/2004guide, consultado en mayo del 2012. [iis ir] ppt-P1, materia Introducción a la Ingeniería de Software, Facultad de Ingeniería, UDELAR. Disponible en línea en http://www.fing.edu.uy/inco/cursos/iis/wikiIIS/uploads/Material/IngReq2010-P1.ppt, consultado en mayo de 2012. [iis cu] ppt-P3, materia Introducción a la Ingeniería de Software, Facultad de Ingeniería, UDELAR. Disponible en línea en http://www.fing.edu.uy/inco/cursos/iis/wikiIIS/uploads/Material/IngReq2010-P3.ppt, consultado en mayo de 2012. [iis VyV] Verificación y Validación, materia Introducción a la Ingeniería de Software, Facultad de Ingeniería, UDELAR. Disponible en línea en http://www.fing.edu.uy/inco/cursos/iis/wikiIIS/uploads/Material/10-Verificacion-Validacion.pdf, consultado en mayo de 2012. [ExRVB] Extracto del libro de Robert V. Binder Testing Object-Oriented System: Models, Patterns, and Tools, Addison-Wesley, 1999. Disponible en línea en robkuijt.nl/testdesignpatterns/pdf/TestPatternXUC.pdf, consultado en mayo del 2011. [BinderOP] Robert V. Binder, mVerify Corporation. Automated Testing with an Operational Profile. Disponible en línea en http://www.mverify.com/resources/AutoProfileTesting.pdf, consultado en mayo del 2011. [SR04] Javier Gutiérrez, De los casos de uso a los casos de prueba. Proceso ETUC. Disponible en línea en http://www.lsi.us.es/~javierj/cursos_ficheros/04.SR.pdf, consultado en junio del 2011. [SR05] Javier Gutiérrez, De los casos de uso a los casos de prueba. Caso práctico. Aplicación WEB. Disponible en línea en http://www.lsi.us.es/~javierj/cursos_ficheros/05.SR.pdf, consultado en junio del 2011. [SERP05] Pedro José Lara Bercial, Juan José Escribano Otero, Luis Fernández Sanz, José Ramón Hilera González. A Study of the Relationship between Usability and Test Cases Precedence Based on a Formal Model for Activity Diagrams. Disponible en línea en http://www.esp.uem.es/~plaraber/Investigacion/SERP05.pdf, consultado en enero del 2011.

88

[Hito2] Javier J. Gutiérrez, María J. Escalona, Manuel Mejías. Hito 2: Definición de casos de uso para procesos de generación automática de pruebas del sistema. Disponible en línea en http://www.lsi.us.es/~javierj/publications/Hito02.pdf, consultado en enero del 2011. [NDT] M.J. Escalona, J.Torres, M.Mejías, A.M. Reina. DESDE LOS REQUISITOS AL MODELO CONCEPTUAL EN NDT, Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Sevilla. Disponible en línea en http://www.onekin.org/webe03/Papers/1Escalona.pdf, consultado en junio del 2011. [MDA] Object Management Group (OMG), MDA - The Architecture of Choice for a Changing World, Disponible en línea en http://www.omg.org/mda/, consultado en febrero del 2013. [YUE3] Tao Yue, Shaukat Ali, Lionel Briand, Automated Transition from Use Cases to UML State Machines to Support State-based Testing. Disponible en línea http://modelme.simula.no/assets/ecmfa2011-tao.pdf,consultado en setiembre del 2011. [YUE1] Yue, T., Briand, L.C., Labiche, Y. A Use Case Modeling Approach to Facilitate the Transition Towards Analysis Models: Concepts and Empirical Evaluation. (Mayo 2009). Disponible en línea en http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.176.3895&rep=rep1&type=pdf, consultado en julio del 2013. [MBT] Wikipedia, Model-based Testing (MBT). Disponible en línea en http://en.wikipedia.org/wiki/Model-based_testing, consultado en febrero del 2012. [POS] Wikipedia, Part-Of-Speec (POS). Disponible en línea en http://es.wikipedia.org/wiki/Part-of-speech_tagging, consultado en febrero del 2012. [UMLTP] B. Pérez Lamancha, P. Reales Mateo, I. García-Rodríguez de Guzmán, M. Polo Usaola. Propuesta para pruebas dirigidas por modelos usando el perfil de pruebas de UML 2.0. Universidad de la República de Uruguay, Universidad de Castilla-La Mancha. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos, Vol. 2, No. 4, 2008. [UMLTP_OMG] Marc-Florian Wendland, Ina Schieferdecker, Markus Schacher, Armin Metzger, UML Testing Profile Tutorial, MBT User Conference, 18th of October 2011. Disponible en línea en http://www.model-based-testing.de/mbtuc11/presentations/Wendland_etal-UTP-Tutorial_1.pdf, consultado en marzo 2013. [OMG] Página oficial de OMG (Object Management Group), disponible en línea en http://www.omg.org/, consultado en febrero 2013.

89

[OOS] Rick Santos, Mary Anna Brown, Oracle Application Testing Suite Getting Started Guide, Version 9.10 for Microsoft Windows (32-Bit), abril 2010. [RSBorInv] Rodrigo Santana, Resumen de Investigación de Proyecto de Grado, Automatización de Generación De Casos de Prueba. Proyecto de Grado 2011. [LFTestCU] Rodrigo Santana, Lenguaje Formal LFTestCU, Automatización de Generación de Casos de Prueba. Proyecto de Grado 2011. [XMI] Pérez J. García M. XMI: XML Metadata Interchange. Facultad de Informática – Universidad Politécnica de Valencia. Disponible en línea en www.dsic.upv.es/asignaturas/facultad/lsi/trabajos/192000.doc, consultado en junio del 2011. [OG] Javier Gutiérrez, ObjectGen, disponible en línea en http://www.lsi.us.es/~javierj/ObjectGen.htm, consultado en junio del 2011. [LF] José Luis Sierra, Federico Peinado, Repaso. Lenguajes formales, Procesadores de Lenguaje, Facultad de Informática, Universidad Complutense de Madrid, Curso 2009 – 20010. Disponible en línea http://www.fdi.ucm.es/profesor/fpeinado/courses/compiling/Repaso-LenguajesFormales.pdf, consultado en marzo 2013. [OCL] Object Constraint Language, Version 2.0, OMG Available Specification, mayo 2006. Disponible en línea en http://www.omg.org/spec/OCL/2.0/PDF, consultado en marzo 2013. [YUE_UCMeta] Tao Yue, Lionel C. Briand, Yvan Labiche, Automatically Deriving a UML Analysis Model from a Use Case Model, Simula Research Laboratory, Technical Report 2010-15 (Version 2). Disponible en línea en http://simula.no/publications/Simula.simula.12/simula_pdf_file, consultado en marzo 2013. [XML_WF] W3C (World Wide Web Consortium), Extensible Markup Language (XML) 1.0, W3C Recommendation 10-February-1998. Disponible en línea en http://www.w3.org/TR/1998/REC-xml-19980210#sec-well-formed, consultado en abril 2013. [IPLN] Materia Introducción al Procesamiento de Lenguaje Natural, Curso 2011, Facultad de Ingeniería, UDELAR. Disponible en línea en http://www.fing.edu.uy/inco/cursos/intropln/, consultado en abril del 2013. [FING_IO] Repartido Teórico de la materia Introducción a la Investigación de Operaciones, Facultad de Ingeniería, UDELAR. Disponible en línea en http://www.fing.edu.uy/inco/cursos/io/archivos/teorico/todo.pdf, consultado en mayo de 2013.

90

[JimHeumann] Jim Heumann, Generating Test Cases From Use Cases, 2001. The Rational Edge. The e-zine for the Rational community. [BPerez_MBT] Macario Polo Usaola, Beatriz Pérez Lamancha. Técnicas y herramientas para testing basado en modelos. Curso dado en agosto 2011 en la Facultad de Ingeniería, UDELAR. [JavaCC] Sergio Gálvez Rojas, Miguel Ángel Mora Mata: Java a Tope: Traductores y Compiladores con Lez/Yacc, JFlex/CUP y JavaCC. Dpto. de Lenguajes y Ciencias de la Computación, E.T.S. de Ingeniería Informática, Universidad de Málaga, 2005. [JavaCC_soft] Java Compiler Compiler tm (JavaCC tm) - The Java Parser Generator, es una página en la que se puede obtener la herramienta. La URL es http://javacc.java.net/, consultado en febrero 2013. [POI] Apache POI - the Java API for Microsoft Documents, es una página en la que se puede obtener la herramienta. La URL es http://poi.apache.org/ y fué consultada en mayo de 2013. [BNF] Wikipedia, Notación de Backus-Naur (BNF). Disponible en línea en http://es.wikipedia.org/wiki/Notaci%C3%B3n_de_Backus-Naur, consultado en agosto del 2013. [fing_dc] Parsing Top Down, materia Diseño de compiladores, Facultad de Ingeniería, UDELAR. Disponible en línea en http://www.fing.edu.uy/inco/cursos/compil/teorico.html, consultado en aagosto de 2012. [OATS] Oracle® Application Testing Suite, Getting Started Guide, Getting Started Guide. Version 9.10 for Microsoft Windows (32-Bit), abril 2010.

91

Anexo A – Especificación LFTestCU de Load document from file En este anexo se muestra el CU Load documento from file, que es el que se usa como ejemplo en el capítulo 4 Construcción de TestCU, escrito en LFTestCU. <CU nombre="Load document from file" descripcion="Carga un documento a partir de un archivo"> <precondicion> "" </precondicion> <actorPrimario id="Usuario" nombre="Usuario Primario"/> <sistema id="Sistema" nombre="Nombre del Sistema"/> <variablesOperacionales> <VO id="Opcion" tipo="E" descripcion="Indica las opciones disponibles." > <dominio> "Conjunto {Open File, ...}" </dominio> <CV> "" </CV> <CI> "" </CI> </VO> <VO id="NombreDeArchivo" tipo="E" descripcion="Nombre del archivo a abrir."> <dominio> "Cadena de Caracteres" </dominio> <CV> "Existe en el sistema un archivo con este nombre" </CV> <CI> "NO existe en el sistema un archivo con este nombre" </CI>

92

</VO> </variablesOperacionales> <flujoPrincipal id="FP" nombre="Flujo Principal"> <paso id="FP_1prima"> muestraDominio(Sistema,Opcion) </paso> <paso id="FP_1"> ingresaDatos(Usuario,{Opcion}) </paso> <paso id="FP_2prima"> VALIDATES_THAT (Opcion = 'Open File') </paso> <paso id="FP_2"> muestraMensaje(Sistema,'Ingresar nombre del archivo') </paso> <paso id="FP_3"> ingresaDatos(Usuario,{NombreDeArchivo}) </paso> <paso id="FP_3prima"> VALIDATES_THAT (NombreDeArchivo IS_VALID) </paso> <paso id="FP_4"> muestraMensaje(Sistema,'El archivo se está cargando...') </paso> <poscondicion> "El sistema muestra el archivo con nombre NombreDeArchivo." </poscondicion> </flujoPrincipal> <flujosAlternativosEspecificos> <FAE id="FA1" nombre="FA1"> <condicionFAE> Opcion <>'Open File' </condicionFAE> <RFS id="FP_2prima"/> <paso id="FA1_1"> muestraMensaje(Sistema,'Seleccionar la opción "Open File"') </paso> <paso id="FA1_2"> ABORT </paso> <poscondicion> "" </poscondicion> </FAE> <FAE id="FA2"

93

nombre="FA2"> <condicionFAE> NombreDeArchivo IS_NOT_VALID </condicionFAE> <RFS id="FP_3prima"/> <paso id="FA2_1"> muestraMensaje(Sistema,'No existe un archivo con ese nombre') </paso> <paso id="FA2_2"> RESUME_STEP(FP_2) </paso> <poscondicion> "" </poscondicion> </FAE> </flujosAlternativosEspecificos> <flujosAlternativosGlobales> <FAG id="FG1" nombre="FG1"> <disparadorFAG> "El usuario presiona cualquiera de los botones Cancelar usados en el CU." </disparadorFAG> <paso id="FG1_1"> muestraMensaje(Sistema, 'Se cancela la operación de carga de archivos') </paso> <paso id="FG1_2"> ABORT </paso> <poscondicion> "El sistema descarta los cambios realizados" </poscondicion> </FAG> </flujosAlternativosGlobales> </CU>

94

Anexo B – Especificación LFTestCU de Retiro En este anexo se muestra la especificación completa en LFTestCU del CU Retiro de Cajero Automático del capítulo Caso de Estudio 4 Construcción de TestCU. <CU nombre="Retirar" descripcion="Un cliente de un banco retira dinero de una cuenta a través del cajero automático utilizando una tarjeta bancaria, el Servicio de Cajeros verifica que el PIN sea válido y que el monto de la cuenta sea suficiente para realizar el retiro"> <precondicion> "" </precondicion> <actorPrimario id="Cliente" nombre="Cliente"/> <sistema id="CA" nombre="Cajero Automático"/> <variablesOperacionales> <VO id="CodigoDeTarjeta"

tipo="E" descripcion="Tiene el valor del código que lee el CA en la tarjeta ingresada por el cliente.">

<dominio>

"Código que se lee de la tarjeta introducida por el Cliente en el CA."

</dominio> <CV>

"El código en la tarjeta ingresada por el usuario cumple con los requisitos que verifica el CA."

</CV> <CI> "No cumple la CV" </CI> </VO> <VO id="PIN" tipo="E" descripcion="PIN ingresado al cliente por el Cliente"> <dominio> "4 dígitos"

95

</dominio> <CV> "" </CV> <CI> "" </CI> </VO> <VO id="Alternativa" tipo="E" descripcion="Tiene las alternativas que permite realizar el CA."> <dominio> "{'Retiro', 'Depósito', 'Consulta'}" </dominio> <CV> "" </CV> <CI> "" </CI> </VO> <VO id="Cuenta" tipo="E" descripcion="Nro de cuenta ingresado por el cliente al CV"> <dominio>

"Conjunto de las cuentas pertenecientes a los bancos asociados al CA."

</dominio> <CV> "" </CV> <CI> "" </CI> </VO> <VO id="Monto" tipo="E" descripcion="Monto ingresado al CA por el cliente">

96

<dominio> "Número racional" </dominio> <CV>

"El monto indicado por el cliente puede obtenerse a partir de los billetes de que dispone el CA."

</CV> <CI> "No cumple la CV" </CI> </VO> <VO id="PINCorrecto" tipo="EDS"

descripcion="Es el resultado de la validación del PIN hecha por el SC .">

<dominio> "'OK' o string distinto de 'OK'" </dominio> <CV> "" </CV> <CI> "" </CI> </VO> <VO id="HayDinero" tipo="EDS" descripcion="Indica si hay dinero en el CV."> <dominio> "" </dominio> <CV> "El CV tiene dinero." </CV> <CI> "No cumple la CV" </CI> </VO> <VO id="RetiroCorrecto"

97

tipo="EDS" descripcion="Indica el resultado de la solicitud de retiro ingresada por el usuario.">

<dominio> "{'OK', 'No hay saldo', 'Sin conexión a SC'}" </dominio> <CV> "" </CV> <CI> "" </CI> </VO> <VO id="TiempoDesdeQueDispensaElDinero" tipo="EDS"

descripcion="Indica el tiempo que lleva el dinero en la bandeja desde que el CA lo dispensó.">

<dominio> "Cadena de Caracteres" </dominio> <CV> "<" </CV> <CI> "" </CI> </VO> <VO id="TiempoDesdeQueDevuelveLaTarjeta" tipo="EDS"

descripcion="Indica el tiempo que lleva CA tratando de devolver la tarjeta.">

<dominio> "Cadena de Caracteres" </dominio> <CV> "" </CV> <CI> ""

98

</CI> </VO> <VO id="NroDeIntentos" tipo="EDS"

descripcion="Indica el nro de intentos del cliente para ingresar el PIN válido">

<dominio> "Nro entero menor o igual a 3." </dominio> <CV> "" </CV> <CI> "" </CI> </VO> </variablesOperacionales> <flujoPrincipal id="FP" nombre="Flujo Principal"> <paso id="FP_1"> ingresaDatos(Cliente, {CodigoDeTarjeta}) </paso> <paso id="FP_2"> VALIDATES_THAT (CodigoDeTarjeta IS_VALID) </paso> <paso id="FP_3"> muestraMensaje(CA, 'Ingrese el código de PIN de 4 dígitos') </paso> <paso id="FP_4"> ingresaDatos(Cliente, {PIN}) </paso> <paso id="FP_6"> generaDatos(CA, IN {PIN, CodigoDeTarjeta}, OUT {PINCorrecto}) </paso> <paso id="FP_6_1"> VALIDATES_THAT (PINCorrecto = 'OK')

99

</paso> <paso id="FP_7"> muestraDominio(CA, Alternativa) </paso> <paso id="FP_8"> ingresaDatos(Cliente, {Alternativa}) </paso> <paso id="FP_8_1"> VALIDATES_THAT (Alternativa='Retiro') </paso> <paso id="FP_8_2"> generaDatos(CA, IN{}, OUT{HayDinero}) </paso> <paso id="FP_8_3"> VALIDATES_THAT (HayDinero IS_VALID) </paso> <paso id="FP_9"> muestraMensaje(CA, 'Ingese la cuenta y el monto a retirar') </paso> <paso id="FP_10"> ingresaDatos(Cliente, {Cuenta, Monto}) </paso> <paso id="FP_10_1"> VALIDATES_THAT (Monto IS_VALID) </paso> <paso id="FP_11">

generaDatos(CA, IN {CodigoDeTarjeta, PIN, Cuenta, Monto}, OUT {RetiroCorrecto})

</paso> <paso id="FP_12"> VALIDATES_THAT (RetiroCorrecto = 'OK') </paso> <paso id="FP_13"> generaDatos(CA, IN {}, OUT{TiempoDesdeQueDispensaElDinero}) </paso>

100

<paso id="FP_13_1"> VALIDATES_THAT (TiempoDesdeQueDispensaElDinero <= 'YY segundos')

</paso> <paso id="FP_14"> generaDatos(CA, IN {}, OUT{TiempoDesdeQueDevuelveLaTarjeta}) </paso> <paso id="FP_14_1">

VALIDATES_THAT (TiempoDesdeQueDevuelveLaTarjeta <= 'XX segundos')

</paso> <paso id="FP_14_2"> muestraMensaje(CA, 'El retiro terminó correctamente') </paso> <poscondicion> " (1) El CA dispensa el monto (2) El CA devuelve la tarjeta (3) El CA imprime recibo " </poscondicion> </flujoPrincipal> <flujosAlternativosEspecificos> <FAE id="FA2A" nombre="La tarjeta no es válida"> <condicionFAE> CodigoDeTarjeta IS_NOT_VALID </condicionFAE> <RFS id="FP_2"/> <paso id="FP2A_1"> muestraMensaje(CA, 'Tarjeta no válida') </paso> <paso id="FP2A_"> ABORT </paso> <poscondicion> "El CA devuelve la tarjeta."

101

</poscondicion> </FAE> <FAE id="FA6A" nombre="PIN inválido y menos de 3 intentos"> <condicionFAE> PINCorrecto <> 'OK' </condicionFAE> <RFS id="FP_6_1"/> <paso id="FA6A_1"> generaDatos(CA, IN{NroDeIntentos},OUT{NroDeIntentos}) </paso> <paso id="FA6A_2"> VALIDATES_THAT (NroDeIntentos < '3') </paso> <paso id="FA6A_3"> muestraMensaje(CA, 'PIN incorrecto') </paso> <paso id="FA6A_4"> RESUME_STEP (FP_3) </paso> <poscondicion> "" </poscondicion> </FAE> <FAE id="FA6B" nombre="PIN inválido y 3 intentos"> <condicionFAE> NroDeIntentos = '3' </condicionFAE> <RFS id="FA6A_2"/> <paso id="FA6B_1"> muestraMensaje(CA, 'Se le retiene la tarjeta') </paso> <paso id="FA6B_2">

102

ABORT </paso> <poscondicion> "El cajero retiene la tarjeta" </poscondicion> </FAE> <FAE id="FA9A" nombre="El CA no tiene dinero"> <condicionFAE> HayDinero IS_NOT_VALID </condicionFAE> <RFS id="FP_8_3"/> <paso id="FA9A_1"> muestraMensaje(CA, 'Sin dinero') </paso> <paso id="FA9A_"> ABORT </paso> <poscondicion> "" </poscondicion> </FAE> <FAE id="FA11A" nombre="Monto insuficiente para el cajero"> <condicionFAE> Monto IS_NOT_VALID </condicionFAE> <RFS id="FP_10_1"/> <paso id="FA11A_1">

muestraMensaje(CA,'No se cuenta con ese monto en este cajero')

</paso> <paso id="FA11A_2"> RESUME_STEP(FP_9) </paso>

103

<poscondicion> "" </poscondicion> </FAE> <FAE id="FA12A" nombre="No hay suficiente saldo en la cuenta"> <condicionFAE> RetiroCorrecto = 'No hay saldo' </condicionFAE> <RFS id="FP_12"/> <paso id="FA12A_1"> muestraMensaje(CA, 'Su saldo no permite extraer ese monto') </paso> <paso id="FA12A_2"> ABORT </paso> <poscondicion> "El CA devuelve la tarjeta" </poscondicion> </FAE> <FAE id="FA12B" nombre="No hay contacto con el Servicio de Cajeros (SC)"> <condicionFAE> RetiroCorrecto = 'Sin conexión a SC' </condicionFAE> <RFS id="FP_12"/> <paso id="FA12B_1"> muestraMensaje(CA, 'Sin conexión a la red de cajeros') </paso> <paso id="FA12B_2"> ABORT </paso> <poscondicion>

104

"El CA devuelve la tarjeta" </poscondicion> </FAE> <FAE id="FA14A" nombre="El dinero no es retirado de la bandeja."> <condicionFAE> TiempoDesdeQueDispensaElDinero > 'YY segundos' </condicionFAE> <RFS id="FP_13_1"/> <paso id="FP14A_1"> RESUME_STEP (FP_14) </paso> <poscondicion>

"El CA recupera el dinero y lo deja en el depósito de dinero usado."

</poscondicion> </FAE> <FAE id="FA14B" nombre="La tarjeta se tranca al intentar devolverla"> <condicionFAE> TiempoDesdeQueDevuelveLaTarjeta > 'XX segundos' </condicionFAE> <RFS id="FP_14_1"/> <paso id="FP14B_1"> ABORT </paso> <poscondicion> "El CA avisa a mantenimiento" </poscondicion> </FAE> </flujosAlternativosEspecificos> <flujosAlternativosGlobales> </flujosAlternativosGlobales> </CU>

105

Anexo C – Manual de Usuario de TestCU La interface gráfica de TestCU es la que se muestra en la figura a continuación, y en la que se debe ingresar en el campo Entrada el nombre del archivo XML con la especificación del CU a probar. Y en el campo Salida se debe especificar el nombre del archivo Excel (extensión xls) en el que se va a generar la matriz con los CPA.

Ilustración 21: Interface Gráfica de TestCU