Test suite for a generator of TVDI applications using ... · multimedia/hipermedia desarrolladas...

Suite de pruebas para un generador de aplicaciones TVDI usando modelos

de características

Test suite for a generator of TVDI applications using features models

Víctor Valentín, Sandra Casas, Franco Herrera, Franco Trinidad y Fernanda Oyarzo

GISP. Instituto de Tecnología Aplicada.

[email protected]

Universidad Nacional de la Patagonia Austral, Unidad Académica Río Gallegos

14 de Febrero de 2017

RESUMEN

Un generador de aplicaciones es una herramienta cuya salida es una especificación de código.

La prueba de un generador de código implica identificar las entradas válidas e inválidas que

producen esas especificaciones de salida. A la vez, cuando los procesos de construcción son

incrementales y producen versiones de los productos de software en las distintas etapas, se

requieren estrategias de generación de prueba que sistemáticamente puedan ser aplicadas y

replicadas para generar los test. Dr Nau es un generador de aplicaciones interactivas para TV

Digital, basado en el uso de patrones de diseño de interacción centrados en el usuario, que se

construye a partir de incrementos, obteniendo en cada uno de estos, una versión funcional de

la herramienta. Este trabajo presenta una suite de pruebas para el primer incremento de Dr

Nau, creada a partir de modelos de características y los diferentes patrones de diseño. La suite

representa el conjunto de posibles aplicaciones que puede desarrollar Dr Nau en la etapa en

que se encuentra. Al ser elaborada por medio de modelos de características, es posible

determinar su completitud y exactitud por medio de software automatizado para tal fin, como

Fama test suite, que es el que se utilizó en esta oportunidad. Se demuestra así que el trabajo

realizado manualmente es efectivo y contempla la totalidad de posibles aplicaciones.

Palabras clave: TV Digital; aplicaciones interactivas; generador de aplicaciones; modelo de

características; patrones de diseño de interacción; Líneas de producto de software.

ABSTRACT

An application generator is a tool whose output is a code of specification. Testing a code

generator involves identifying the valid and invalid inputs that these output specifications

produce. At the same time, when construction processes are incremental and produce versions

of software products in distant stages, test generation strategies are required that can be

systematically applied and replicated to generate the tests. Dr Nau is an interactive application

generator for Digital TV, based on the use of user-centered interaction design patterns, which

is built from increments, obtaining in each one of them a functional version of the tool. This

work presents a suite of tests for the first increment of Dr Nau, created from models of

characteristics and the different design patterns. The suite represents the set of possible

applications that Dr Nau can develop in the stage in which it is. Thus, it is possible to

determine their completeness and accuracy by the use of an automated software for such

purpose, like Fama test suite, that is the one that was used in this opportunity. Therefore we

Esta obra está bajo una Licencia Creative Commons Atribución-NoComercial-SinDerivar 4.0 Internacional.

115

ICT-UNPA-162-2017ISSN: 1852-4516

Aprobado por Resolución N° 0343/17-R-UNPA

conclude that the work done manually is effective and contemplates the totality of possible

applications.

Key words: Digital TV; Interactive Applications; Application Generator; Feature Model;

Interaction Design Patterns; Software Product Lines.

1 INTRODUCCION

Este trabajo aborda el problema de la generación de una suite de pruebas para un generador de

aplicaciones interactivas para TV Digital (TVDi), denominado Dr. Nau. Una aplicación TVDi

es un software multimedia a través del cual el televidente puede interactuar vía control

remoto. Significa que puede recibir video, audio, software, que posibilitan la interacción del

televidente con el contenido (Rodrigues y Soares, 2006). Se emplean diferentes medias (texto,

imágenes, sonido, animación y video) para informar al televidente, cuya creación es uno de

los aspectos que mayor tiempo demanda en el desarrollo de aplicaciones TVDi. NCL (Sitio

Oficial NCL) es un lenguaje de etiquetas para la codificación de aplicaciones TVDi,

interpretables por el middleware Ginga (Sitio Oficial Ginga.ar).

Un generador de aplicaciones es una herramienta que a partir de especificaciones de muy alto

nivel genera automática o semi-automáticamente el código (fuente o ejecutable) de otras

aplicaciones en un dominio especifico (Cleaveland, 1988).

Dr. Nau tiene dos objetivos principales, posibilitar que a partir de la selección y

parametrización de características de los elementos de la interfaz y/o interacción con el

televidente obtener automáticamente el código NCL. De esta forma, Dr. Nau brinda la

posibilidad de desarrollo fácil, rápido y a bajo costo de aplicaciones de TVDi a usuarios

carentes o con escasos conocimientos de programación, tales como productores de TV,

periodistas, etc. El otro objetivo importante de Dr. Nau, es garantizar que las aplicaciones

generadas cumplan con criterios de usabilidad aceptables. De manera que, estas reglas y

normas de usabilidad deben estar embebidas en la lógica de la herramienta, evitando que el

usuario requiera conocerlas para su aplicación. Por ello, las abstracciones de alto nivel, y las

especificaciones de entrada del generador, siguen y permiten aplicar patrones de diseño de

interactividad centrados en el usuario para TVDi (Kunert, 2009).

En este contexto, se plantea la necesidad de aplicar un método para la creación de los test de

prueba, que permitan validar la herramienta, que pueda ser replicado sistemáticamente en las

diferentes etapas del proyecto con las diferentes versiones de la misma.

Debido a que existen conceptualmente similitudes entre los generadores de aplicaciones y las

líneas de productos de software (LPS) (Clements y Northrop, 2001), proponemos adoptar una

estrategia coincidente para la creación de la suite de pruebas de Dr. Nau. Es así que

planteamos la generación de la suite de pruebas (sub-conjunto de aplicaciones y sus

especificaciones de alto nivel) a partir del modelado y diseño de modelo de características Sitio

(Oficial Lenguaje LUA).

A continuación se presentan los conceptos preliminares de TV Digital, Ginga, NCL, los

Patrones de diseño de interactividad centrados en el usuario para aplicaciones TVDi y Modelo

de Características. En la sección tercera se presentan trabajos relacionados, seguidos, en la

sección cuarta, por una breve reseña del Proyecto Dr-Nau. y la propuesta de la suite de

prueba En la sección quinta, se expone la validación de los resultados obtenidos a partir de la

utilización de la herramienta FAMA test suite, finalizando con las y conclusiones.


116

ICT-UNPA-162-2017ISSN: 1852-4516


2 NOCIONES PRELIMINARES

2.1 TV DIGITAL

La TV Digital (Sitio Oficial Red AUTI) es el conjunto de tecnologías de generación,

transmisión y recepción de imagen y sonido a través de información digital. Esto permite que

los errores en la transmisión y recepción de la TV analógica (“fantasmas” y “lluvia”) se

corrijan y de esta manera no existan interferencias ni distorsiones en pantalla, generando una

imagen y sonido superior a la TV actual (analógica).

El Sistema Argentino de Televisión Digital Terrestre (SATVD-T) (Sitio Oficial Red AUTI),

como todos los otros sistemas de televisión, respeta el modelo broadcasting. Este modelo se

basa en la existencia de: un conjunto reducido de emisores de contenido (canales de

televisión) y un conjunto suficientemente grande de receptores (televidentes). En este modelo,

los receptores no tienen control directo sobre el contenido emitido, sino que, lo tienen sobre la

sintonización de un programa dado. Esto implica que el modelo puede implementarse sin un

canal de retorno que conecte a los televidentes a los emisores u otros servicios.

El SATVD-T está basado en la norma Integrated Service Data Broadcasting (ISDB-Tb) o

Transmisión Digital de Servicios Integrados. El mismo consiste en un conjunto de normas

japonesas adaptadas por Brasil, que definen formas para transmitir contenidos digitales por

aire. Esta norma utiliza el middleware denominado Ginga (Sitio Oficial Ginga Brasil) que

permite ejecutar aplicaciones NCL (Sitio Oficial NCL)/ LUA (Oficial Lenguaje LUA).

El decodificador (o set-top-box) es un dispositivo que permite la recepción tanto de la señal

digital como la analógica, y genera la señal de video y audio que alimenta el televisor o

display. Su objetivo es realizar todas las operaciones necesarias para que las señales recibidas

a modo de radio frecuencia se transformen en video y audio: captación de las señales,

decodificación, descompresión, etc. El set-top-box del SATVD-T implementa el middleware

Ginga.ar (Sitio Oficial Ginga.ar).

Las aplicaciones que son parte de la transmisión digital respetan el mismo modelo, pero son

los televidentes los que tienen el control sobre el uso de las mismas, dado que generalmente la

aplicación puede ser desactivada, o el televidente puede cancelar la ejecución de la aplicación

cambiando el canal que sintoniza. Las mismas están asociadas al video principal del canal en

el cual se transmiten y por ende aumenta la experiencia del televidente respecto de la

televisión tradicional, con nuevos tipos de interacciones entre el cliente y los contenidos. Es

por esto que suele hablarse de TV Digital interactiva.

2.2 GINGA

Ginga (Barbosa y Soares, 2008) es el nombre que recibe el middleware que permite ejecutar

aplicaciones interactivas dentro de un STB (Set-Top Box). Cómo en el mercado existen STBs

de distintos fabricantes y puede variar la plataforma de hardware/software de los mismos,

surge la necesidad de contar de un middleware que permita correr aplicaciones sin importar

que STB se disponga.

El middleware abierto Ginga se subdivide en dos subsistemas principales interrelacionados,

que permiten el desarrollo de aplicaciones siguiendo dos paradigmas de programación

diferentes. Estos dos subsistemas se llaman Ginga-J (para aplicaciones procedurales Java) y

Ginga- NCL (para aplicaciones NCL).


117

ICT-UNPA-162-2017ISSN: 1852-4516


En Argentina, se trabaja sobre la versión Ginga-NCL (Soares y Otros, 2007) y esto se debe a

que Ginga-NCL es en la actualidad el único middleware estándar internacional tanto para

IPTV como para TV Digital (en todos los tipos de dispositivo). Y también es el único

estándar abierto. El mismo fue creado en la Pontifícia Universidade Católica do Río de

Janeiro (PUC-Rio) y ofrece una infraestructura de presentación de aplicaciones de

multimedia/hipermedia desarrolladas sobre el paradigma declarativo, escritas en el lenguaje

NCL y el lenguaje de scripting LUA.

Prácticamente todos los middleware para TV Digital terrestre ofrecen soporte para el

desarrollo de aplicaciones usando dos paradigmas de programación.

Ginga.ar (Sitio Oficial Ginga.ar) es una implementación estándar Ginga-NCL, desarrollada

por el equipo de TV Digital del LIFIA-UNLP, a partir de la implementación de referencia

Ginga-NCL. El middleware Ginga.ar fue portado a la arquitectura ST e instalado en Set Top

Boxes comerciales diseñados y producidos en Argentina. Estos Set Top Boxes son

distribuidos por el proyecto de TV Digital del Gobierno Argentino. Ginga.ar es Software

Libre, las licencias utilizadas son GPLv2 y LGPLv2, e incluye librerías con otras licencias

libres.

2.3 NEXTED CONTEXT LANGUAJE (NCL)

NCL (Soares y Rodrigues, 2005) (Sitio Oficial club NCL) es un lenguaje declarativo basado

en el modelo conceptual NCM (Fig. 1), básicamente es un documento XML. El lenguaje

define claramente cómo los objetos media (elementos de contenido multimedial, es decir, los

elemento a mostrar como por ejemplo videos, imágenes, sonidos, etc.) son estructurados y

relacionados, en el tiempo y en espacio.

Como es un lenguaje de marcado, no especifica los tipos del contenido de los objetos media

de una aplicación.

Figura 1: Entidades NCM y elementos del lenguaje NCL

2.4 PATRONES DE DISEÑO DE INTERACCION CENTRADOS EN EL USUARIO PARA

APLICACIONES TVDi

Kunert (Kunert, 2009) ha propuesto patrones de diseño de interacción centrados en el usuario

para aplicaciones TVDi. Presenta 41 patrones, organizados en diez grupos, que contemplan

usabilidad e identificación de las tareas que el usuario realiza de manera habitual. Los cuales


118

ICT-UNPA-162-2017ISSN: 1852-4516


han sido muy empleados en aplicaciones TVDi que ofrece la Corporación Británica de

Radiodifusión (BBC - British Broadcasting Corporation). Estos se basan en el método de

enfoque de grupo; este concepto permite el análisis de tareas y necesidades de los contenidos

de los usuarios en aplicaciones de TVDi. Los resultados de los grupos se refieren a tipos

específicos de contenido y se clasifican en tareas de usuarios genéricas de TVDi, requisitos de

contenido general y en requisitos generales de usabilidad. A continuación se indican los

grupos y patrones correspondientes.

A. PAGE LAYOUT (Diseño de pantalla): Según el contenido se clasifican en:

Superposición (overlay): el video se sigue transmitiendo en el fondo de la pantalla,

mientras la aplicación se ejecuta sobre el video cubriendo una parte pequeña de la pantalla,

dejando el video visible.

Pantalla completa con video: el video ocupa ¼ de tamaño de la pantalla, mientras que

la aplicación ocupa el resto.

Pantalla completa sin video: la aplicación cubre toda la pantalla, mientras que el video

queda detrás de la aplicación, solo se escucha el audio.

B. NAVIGATION (Navegación): a partir del diseño de pantalla seleccionado se elige la forma

de navegar:

Menú: proporciona acceso a diversos contenidos y funciones organizadas

jerárquicamente. Un elemento del menú lleva al submenú.

Vídeo Multi-Pantalla: una pantalla múltiple ofrece acceso a varios flujos de vídeo

presentados simultáneamente.

Índice: permite acceder a una visión general organizada alfabéticamente de los

elementos de contenido y funciones.

Números de página: proporcionan acceso directo a las páginas individuales. Al igual

que en el teletexto analógico, determinados tipos de contenido tienen números de página

consistentes a través de aplicaciones.

Tabs: son pestañas que facilita el acceso a los elementos y funciones de contenido,

similar al menú.

C. REMOTE CONTROL KEYS (Teclas de control remoto): a partir del diseño de pantalla y

navegación se elige la configuración de las teclas de uso:

Teclas de flechas: en un control remoto estándar son cuatro las teclas: arriba, abajo,

izquierda y derecha.

Teclas Ok-Select: es la tecla OK, generalmente se encuentra en el centro de las cuatro

teclas de flecha, muchas veces no etiquetado.

Teclas de color: en un control remoto estándar son cuatro las teclas de colores: rojo,

verde, amarillo y azul. No solo los colores están estandarizados, sino también, el orden que

se encuentran alineados en forma horizontal.

Teclas numéricas: se cuenta con diez teclas del 0 al 9 en un control remoto estándar y

generalmente, están puestas en una cuadrícula de 3 por 3 con el 0 centrada.

Teclas especiales: algunos controles ofrecen este tipo de teclas, pueden ser, “text”,

“interactive”.

D. BASIC FUNTIONS (Funciones básicas): a partir de la elección de los tres primeros grupos

se clasifica en:

Inicio (Starting): la aplicación tiene que ser fácil para que el usuario no la abandone.

Indicador de carga: los usuarios deben ser informados que la aplicación se está

cargando. Esto se debe al tiempo de los STB.


119

ICT-UNPA-162-2017ISSN: 1852-4516


Salida (Exiting): es una forma de aviso que finaliza la aplicación.

Ocultar la aplicación.

Subir un nivel: indica en qué lugar se encuentra el usuario dentro de la aplicación.

E. CONTENT PRESENTATION (Presentación de contenido): a partir de la elección de los

tres primeros grupos se clasifica en:

Caja de contenido (ContentBox): presenta el tipo de media, diseño de página,

transparencia, audio

Paginado.

Barras de Desplazamiento: permite desplazarse por la pantalla en forma vertical u

horizontal

Switch entre ítems de contenido

Contenido sincronizado (Synchronised)

F. USER PARTICIPATION (Participación de usuario): le permite al usuario la votación y

elección de opción múltiple, asignación de temas y completar texto.

Votación y selección múltiples

Ubicación de ítems

Completado de texto

Aprobación para conectar

G. TEXT INPUT (Entrada de textos)

Teclado en pantalla

Teclado de dispositivo móvil

H. HELP (Ayuda)

Instrucciones en pantalla

Sección de ayuda

I. ACCESSIBILITY & PERSONALISATION (Accesibilidad y personalización)

Accesibilidad

Personalización

J. SPECIFIC USER

2.5 MODELO DE CARACTERISTICAS Un modelo de características (MC) es definido formalmente como una estructura de árbol

representada como una tupla de 6 componentes (característica, característica raíz,

características obligatorias, características opcionales, relaciones alternativas, relaciones

disyuntivas). Un MC permite identificar las funcionalidades comunes y variantes entre los

productos de una LPS y establecer las relaciones entre las mismas (González y Otros, 2014).

El concepto principal de esta técnica es denominado “característica” (feature). Las

características son propiedades identificables unívocamente de un dominio de aplicación

según el punto de vista del usuario o desarrollador. Es la unidad funcional en la que se

descompone un sistema de software para satisfacer un requisito, representa una decisión de

diseño, y proporciona una potencial opción de configuración.


120

ICT-UNPA-162-2017ISSN: 1852-4516


Por lo general, a partir de un conjunto de características, muchos sistemas de software

diferentes pueden ser generados compartiendo características comunes y difiriendo en otras.

El MC aparece estrechamente ligado al concepto de un LPS dado que la primera es un

excelente mecanismo para modelar, diseñar e implementar el segundo. Usando MC, muchas

de las variabilidades existentes en una LPS pueden implementarse como características.

Los MC organizan el conjunto de características en una estructura jerárquica en forma de

árbol mediante relaciones entre ellas:

1- Relación Jerárquica: es definida entre una característica padre y un conjunto de

características hijas o sub-características. Una característica hija solamente puede formar

parte de los productos en los que la característica padre aparece. Fueron propuestas cinco

tipos de relaciones jerárquicas:

Obligatoria (Mandatory): indica que cuando la característica padre es parte de un producto

particular, la característica hija también debe ser parte del producto.

Opcional (Optional): indica que cuando la característica padre es parte de un producto

particular, la característica hija, puede o no, ser incluida en el producto.

Alternativa (Alternative): es la relación entre una característica padre y un conjunto de

característica hijas que indica que cuando la característica padre forma parte de un producto

particular, sólo una de las características del grupo de hijas debe formar parte del producto.

Relación-OR (OR-Relation): la característica hija en una relación OR puede o no formar

parte de un producto si su característica padre está incluida. Entonces, al menos una

característica del conjunto de características hijas puede estar presente en el producto.

Relación-AND (AND-Relation): si la característica padre forma parte de un producto,

entonces todas las características hijas deben ser incluidas.

2- Relación no Jerárquica: Si la característica A aparece, entonces la característica B se debe

incluir (o excluir) o una característica A requiere de una B.

Excluye (Excludes): Una característica X que excluye a la característica Y significa que si la

característica X es incluida en el producto, la característica Y no debe ser incluida, y

viceversa. La selección de una de ellas (no importa cuál) implica que la otra característica no

será incluida en el producto.

Requiere (Requires): Una característica X que requiere de una característica Y, significa que

si la característica X es incluida en el producto, la característica Y también debe ser incluida,

pero no viceversa.

Una vez que todas las características identificadas en el análisis son definidas, entonces un

modelo jerárquico puede ser creado clasificando y estructurando las características utilizando

la relación “se-compone-de”. Para esto se utiliza lo que se denomina un modelo de

características (feature model) que describe todas las posibles variantes de productos de

software que se pueden obtener.

La Figura 2 muestra un MC que describe las variantes que pueden existir en la producción de

un automóvil. La raíz del árbol denota el concepto que es modelado, las otras cajas


121

ICT-UNPA-162-2017ISSN: 1852-4516


representan características en donde las características hijas dependen de las características

padres. Cada automóvil tiene un cuerpo, la transmisión y el motor (círculo relleno), pero no

todos tienen necesariamente un enganche para remolque (círculo vacío) o el motor puede ser

alimentado con gasolina o con electricidad o con ambos (arco lleno), las características de

transmisión automática y manual de un automóvil son alternativas y mutuamente excluyentes

(arco vacío).

Figura 2: Ejemplo de MC

3 TRABAJOS RELACIONADOS Los modelos de características se han difundido masivamente para el desarrollo y

construcción de Líneas de Producto Software (LPS), en diversos dominios como textil,

automotriz, telefonía móvil, robótica, aplicaciones geográficas, gestores de venta y otros.

(González, 2012) (Deursen y Klint, 2002) (Gherardi y Brugali, 2011) (González y Otros,

2014) (Kang y Otros, 1990) (Capilla y Otros, 2014) (Clements y Northrop, 2002) (Garcés y

Otros, 2007). El uso de modelos de características para obtener aplicaciones de pruebas no ha

sido muy difundido. Por otro lado, una suite de pruebas consiste del conjunto de pruebas al

que se va someter una aplicación, generalmente obtenidas con técnicas tradicionales de

pruebas de software. No ha sido posible acceder a métodos para desarrollar suite de pruebas

para generadores de código.

4 PROYECTO DR. NAU Y PROPUESTA

Dr. Nau, es un proyecto de I+D, ejecutado por el Laboratorio de TV Digital de la UNPA(*)

, el

mismo está acreditado como Proyecto de Desarrollo Tecnológico y Social – PDTS – CIN –

CONICET, en el Banco de PDTS nacional del Ministerio de Ciencia, Tecnología e

Innovación Productiva Argentina.

Dr. Nau tiene dos objetivos principales. El primero de ellos es posibilitar que a partir de la

selección y parametrización de características de los elementos de la interfaz y/o interacción

producir automáticamente el código NCL. De esta forma Dr. Nau brinda la posibilidad de

desarrollo fácil, rápido y a bajo costo de aplicaciones de TVDi a usuarios carentes o con

escasos conocimientos de programación, tales como productores de TV independientes,

cooperativas y asociaciones pequeñas y medianas de producción de contenidos audiovisuales,

etc. El otro objetivo importante de Dr. Nau, es garantizar que las aplicaciones generadas

cumplan con criterios de usabilidad aceptables. De manera que, estas reglas y normas de

usabilidad deben estar embebidas en la lógica de herramienta, evitando que el usuario

requiera conocerlas para su aplicación.

_____________________________________ (*)

https://sites.google.com/site/laboratoriodetvdigital/


122

ICT-UNPA-162-2017ISSN: 1852-4516


Por ello, las abstracciones de alto nivel, y las especificaciones de entrada del generador,

siguen y permiten aplicar patrones de diseño de interactividad centrados en el usuario para

TVDi. (Kunert, 2009).

La construcción de Dr. Nau está dividida en etapas (incrementos o iteraciones), por lo que al

finalizar cada una se obtiene una versión de la herramienta, que tiene sentido funcional para el

usuario, dado que permite obtener un subconjunto de aplicaciones de TVDi. A partir del

primer incremento se plantea el requerimiento de probar su funcionalidad. Para ello, se debe

diseñar una suite de pruebas que permita probar su correcta funcionalidad en la generación

del sub-conjunto de las aplicaciones TVDi objeto de la primer versión.

En este sentido, es que se plantea la necesidad de usar y aplicar un método que pueda ser

replicado sistemáticamente para las próximas versiones obtenidas de los consecuentes

incrementos.

Debido a que existen conceptualmente similitudes entre los generadores de aplicaciones y las

líneas de productos software (LPS) (Clements y Northrop, 2001), como ser:

Ambos enfoques tienen por objeto crear productos o aplicaciones software en un

dominio específico, a partir de un conjunto de elementos comunes, que se diferencian

en otros elementos anticipadamente conocidos (variabilidad).

Ambos enfoques buscan la reutilización de esquemas de diseño y código. Dado que el

desarrollo de software orientado en características (FOSD) es un paradigma para la

construcción, la personalización y la síntesis de las LPS (Apel S. y Otros, 2013).

Proponemos aplicar una estrategia coincidente para la creación de la suite de pruebas de Dr.

Nau. Es así que planteamos la generación de la suite de pruebas (sub-conjunto de aplicaciones

y sus especificaciones de alto nivel) a partir del modelado y diseño de modelo de

características (González y Otros, 2014).

4.1 SUITE DE PRUEBAS PARA DR. NAU El primer incremento de Dr. Nau, cumple con el requerimiento de generar aplicaciones de

TVDi que apliquen los patrones indicados en la Tabla 1.

Tabla 1: Patrones utilizados en la generación de la suite de pruebas


123

ICT-UNPA-162-2017ISSN: 1852-4516


Por lo tanto la suite de pruebas para esta primer versión del generador debe consistir en el

conjunto de aplicaciones de TVDi que se pueden desarrollar a partir de la aplicación de estos

patrones.

Se han adoptado algunas convenciones para la construcción del MC. En cuanto a la

derivación (mapeo) de patrones a características, y teniendo en consideración además las

futuras versiones, se analiza hacer una correspondencia:

En el primer nivel (raíz) la aplicación de prueba

En el segundo nivel las características corresponden a los grupos de patrones

Desde el tercer nivel, los patrones y sus variantes son características concretas.

Las decisiones para el diseño del DF originan el diagrama de la Figura 2.

Figura 3: Modelo de Características para Dr. Nau (primera versión)

Para el diseño y construcción del MC se establecieron las siguientes reglas:

Regla 1: Todas las aplicaciones TVDi de prueba presentan un diseño de pantalla, uso de

teclas de control remoto para la interacción con el usuario, funciones para iniciar y finalizar la

interactividad como también manejo y sincronización del contenido, por lo que estas

características son obligatorias.

Regla 2: El MC expresa que todas las aplicaciones TVDi comparten como características

comunes, los patrones Overlay, Color, Starting, exiting ContentBox y Synchronised (núcleo

de Dr. Nau - etapa 1).

Regla 3: Grupo PAGELAYOUT (Abstracto), este posee tres patrones como características

secundarias concretas (Overlay, Full-Screen With Video y Full-Screen Without Video). Dada

esta etapa de Dr. Nau, solo es posible seleccionar Overlay, que presenta tres opciones como

características secundarias, de ubicación en pantalla (Bottom, Left y Right) y cada una de

estas posee tres características más, de contenido (Texto, Imagen o Texto e Imagen).

Regla 4: Grupo REMOTECONTROL (Abstracto), solo cuenta con un patrón como

característica secundaria (Color) y es de tipo mandatory, se repetirá en la totalidad de las

posibles aplicaciones.


124

ICT-UNPA-162-2017ISSN: 1852-4516


Regla 5: Grupo BASICFUNTIONS (Abstracto), cuenta con dos patrones como características

secundarias (Starting y Exiting), relacionadas mediante AND, y su característica padre es de

tipo mandatory, por ello estarán presentes en todas las aplicaciones de prueba.

Regla 6: Grupo CONTENT PRESENTATION (Abstracto), en este caso hay tres patrones

como características secundarias (TextDesing, ContentBox y Sinchronised ), la característica

padre es de tipo mandatory, pero solo ContentBox y Sinchronised son mandatory y deben

estar incluidas, TextDesing es optional, su presencia está condicionada por una

RESTRICCION en función de la existencia de únicamente texto en el patrón OVERLAY.

Manualmente se derivan las aplicaciones que forman parte de la suite de pruebas, a partir de

la especificación del diagrama y se documentan en forma aplanada y matricial (). El plan de

pruebas queda conformado por 9 aplicaciones, cuya especificación se presenta en el apartado

siguiente.

Tabla 2: Patrones utilizados en la generación de la suite de pruebas

4.2 SUITE DE PRUEBAS

La Suite de pruebas queda conformada por 9 pruebas (aplicaciones), a partir de una simple

plantilla es posible especificarlas.

ID: Aplicación uno (App1)

Entradas: {Overlay [Botton, Texto], Colour, Starting, Exiting, TextDesign, ContentBox, Synchronise}


125

ICT-UNPA-162-2017ISSN: 1852-4516


Salida esperada:

Una sección de texto se desplegara horizontalmente en la parte inferior de la pantalla con formatos de fuente pre-

seleccionados.

-------------------------------------------------------------------------------------------------------------------------------------------------------

ID: Aplicación dos (App2)

Entradas: {Overlay [Botton, Imagen], Colour, Starting, Exiting, ContentBox, Synchronise}

Salida esperada:

Descripción: La aplicación de prueba se despliega sobre el video (programa de tv) que figura en el fondo de la

pantalla, presentará un botón en el extremo inferior izquierdo para inicializar, que aparece por intervalos de tiempo pre-

seleccionados.

Iniciada la interacción, el mismo botón cambia su función a finalización de la interactividad.

Una sección de imagen se desplegará horizontalmente en la parte inferior de la pantalla. -------------------------------------------------------------------------------------------------------------------------------------------------------

ID: Aplicación tres (App3)

Entradas: {Overlay [Botton, Imagen/Texto], Colour, Starting, Exiting, TextDesign, ContentBox, Synchronise}

Salida esperada:

Descripción: La aplicación de prueba se despliega sobre el video (programa de tv) que figura al fondo de la pantalla,

presentará un botón en el extremo inferior izquierdo para inicializar, que aparece por intervalos de tiempo pre-

seleccionados.




seleccionados. Iniciada la interacción, el mismo botón cambia su función a finalización de la interactividad.


126

ICT-UNPA-162-2017ISSN: 1852-4516


Una sección de imagen y texto se desplegará horizontalmente en la parte inferior de la pantalla con formatos de fuente

pre-seleccionados.

----------------------------------------------------------------------------------------------------------------------------------------

ID: Aplicación cuatro (App4)

Entradas: {Overlay [Left, Texto], Colour, Starting, Exiting, TextDesign, ContentBox, Synchronise}

Salida esperada:



seleccionados.


Una sección de texto se desplegara verticalmente sobre el margen izquierdo de la pantalla con formatos de fuente pre-

seleccionados.

-------------------------------------------------------------------------------------------------------------------------------------------------------

ID: Aplicación cinco (App5)

Entradas: {Overlay [Left, Imagen], Colour, Starting, Exiting, ContentBox, Synchronise}

Salida esperada:



seleccionados.


Una sección de imagen se desplegara verticalmente sobre el margen izquierdo de la pantalla.

-------------------------------------------------------------------------------------------------------------------------------------------------------

ID: Aplicación seis (App6)

Entradas: {Overlay [Leftt, Imagen/Texto], Colour, Starting, Exiting, TextDesign, ContentBox, Synchronise}


127

ICT-UNPA-162-2017ISSN: 1852-4516


Salida esperada:



seleccionados.


Una sección de imagen y texto se desplegará verticalmente sobre el margen izquierdo de la pantalla con formatos de

fuente pre-seleccionados.

-------------------------------------------------------------------------------------------------------------------------------------------------------

ID: Aplicación siete (App7)

Entradas: {Overlay [Right, Texto], Colour, Starting, Exiting, TextDesign, ContentBox, Synchronise}

Salida esperada:



seleccionados.


Una sección de texto se desplegará verticalmente sobre el margen derecho de la pantalla con formatos de fuente pre-

seleccionados.

-------------------------------------------------------------------------------------------------------------------------------------------------------

ID: Aplicación ocho (App8)

Entradas: {Overlay [Right, Imagen], Colour, Starting, Exiting, ContentBox, Synchronise}


128

ICT-UNPA-162-2017ISSN: 1852-4516


Salida esperada:



seleccionados.


Una sección de imagen se desplegara verticalmente sobre el margen derecho de la pantalla.

-------------------------------------------------------------------------------------------------------------------------------------------------------

ID: Aplicación nueve (App9)

Entradas: {Overlay [Right, Imagen/Texto], Colour, Starting, Exiting, TextDesign, ContentBox, Synchronise}

Salida esperada:


presentara un botón en el extremo inferior izquierdo para inicializar, que aparece por intervalos de tiempo pre-

seleccionados.


Una sección de imagen y texto se desplegará verticalmente sobre el margen derecho de la pantalla con formatos de

fuente pre-seleccionados.

5 VALIDACION

La suite de pruebas obtenida fue validada mediante el software FAMA TEST SUITE (Segura

y Otros, 2009), que implementa el análisis de modelos de características de manera

automática, dicho software puede ser implementado de diferentes maneras, en este caso, fue

implementado como Plug-in del IDE Eclipse.

En principio recibe como entrada un archivo de extensión XML, que representa el modelo de

características y un archivo de extensión FM, especificando relaciones y restricciones entre

características del modelo.

Valiéndose de los métodos propios de FAMA, se validó el modelo, lo que determinó que este

bien formado, luego se determinó el número posible de productos y su conformación, que

para este problema constituyen el conjunto de pruebas y el resultado fue el que se presenta en

la figura 4.


129

ICT-UNPA-162-2017ISSN: 1852-4516


Figura 4: Resultados calculados por F.A.M.A.

Se observan 9 productos posibles, descriptos como aplicaciones (APP) y entre { }

especificando cada característica participante.

De esta manera validamos automáticamente la suite de pruebas obtenida de forma manual.

6 CONCLUCIONES

La aplicación de modelos de características para la generación de una suite de pruebas

permite diseñar y modelar el conjunto de especificaciones de cada aplicación que es parte de

la suite. Además favorece la identificación de distintos tipos de relaciones entre las

propiedades y elementos funcionales de la herramienta a probar. La modificación del modelo

de características, para incorporar nuevas características (patrones) para versiones futuras de

Dr. Nau es un proceso de bajo costo y esfuerzo y por ende replicable a todo el proceso de

desarrollo de Dr. Nau.

El trabajo a futuro refiere a continuar refinando la suite de pruebas generada. El proceso que

sigue, busca encontrar para cada prueba obtenida las posibles variantes de pruebas, para lo

cual en principio planteamos aplicar técnicas convencionales de la teoría de pruebas.

REFERENCIAS

APEL S., BATORY D., KÄSTNER C., and SAAKE G. (2013) Feature-Oriented Software

Product Lines: Concepts and Implementation, Springer. https://doi.org/10.1007/978-3-

642-37521-7 BARBOSA S.D.J. y SOARES L.F.G. (2008) TV digital interativa no Brasil se faz com

Ginga: Fundamentos, Padroes, Autoria Declarativa e Usabilidade. Em T.

Kowaltowsky & K Breitman (orgs). Atualizacoes em Informática 2008. Rio de

Janeriro, RJ. Editora PUC-Rio. pp 105-174.

CAPILLA R., BOSCH J., TRINIDAD P., RUIZ CORTÉS A. y HINCHEYD M. (2014) An

overview of Dynamic Software Product Line architectures and techniques:

Observations from research and industry, The Journal of Systems and Software 91, pp.

3–23. https://doi.org/10.1016/j.jss.2013.12.038

CLEAVELAND J. (1988) Building application generators. IEEE Software. 5, 4, 25–33. https://doi.org/10.1109/52.17799

CLEMENTS P., NORTHROP L. (2001) Software Product Lines: Practices and Patterns,

Addison-Wesley.

CLEMENTS P., NORTHROP L. (2002) Software Product Lines: Practices and Patterns

Journal of Advanced Nursing, Addison-Wesley Professional, ISBN: 0201703327, pp.

608.


130

ICT-UNPA-162-2017ISSN: 1852-4516


https://doi.org/10.1007/978-3-642-37521-7

https://doi.org/10.1007/978-3-642-37521-7

https://doi.org/10.1016/j.jss.2013.12.038

https://doi.org/10.1109/52.17799

DEURSEN A., KLINT P. (2002) Domain-Specific Language Design Requires Feature

Descriptions, Journal of Computing and Information Technology. Vol 10, pp.1-17. https://doi.org/10.2498/cit.2002.01.01

GARCÉS K., PARRA C., ARBOLEDA H., YIE A. y CASALLAS R. (2007) Administración

de Variabilidad en una línea de producto basado en modelo, Congreso Colombiano de

Computación, Bogotá, Colombia.

GHERARDI L., BRUGALI D. (2011) An eclipse-based Feature Models toolchain. An

eclipse-based feature diagrams toolchain, The Sixth Workshop of the Italian Eclipse

Community, pp. 242-253. In Eclipse-IT.

GONZÁLEZ A., LUNA C., ZORZAN F. y SZASZ N. (2014) Automatic Derivation of

Behavior of Products in a Software Product Line, IEEE LATIN AMERICA

TRANSACTIONS, Vol 12, No 6. https://doi.org/10.1109/TLA.2014.6894009

GONZÁLEZ C. (2012) Software product lines using FODA: a formal approach.

KANG K., COHEN S., HESS J., NOVAK W. y PETERSON S. (1990) Feature-oriented

domain analysis (FODA) feasibility study (No. CMU/SEI-90-TR-21). Carnegie-

Mellon Univ Pittsburgh Pa Software Engineering Inst.

KUNERT T. (2009) User-Centered Interaction Design Patterns for Interactive Digital

Television Applications, Springer – ISBN 978-1-84882-274-0. https://doi.org/10.1007/978-1-84882-275-7

RODRIGUES R. y SOARES R. (2006) Producción de Contenido Declarativo para TV

Digital. XXXIII SemiSH, Brasil.

SEGURA S., BENAVIDES D. and RUIZ-CORTÉS A. (2009) Applied Software Engineering

Research Group University of Seville, Technical Report ISA-09-TR-01, Spain

February.

Sitio Oficial club NCL http://club.ncl.org.br/

Sitio Oficial Ginga.ar (LIFIA) http://tvd.lifia.info.unlp.edu.ar/ginga.ar/

Sitio Oficial Ginga Brasil. http://www.ginga.org.br

Sitio Oficial Lenguaje LUA. http://www.lua.org

Sitio Oficial NCL http://www.ncl.org.br/

Sitio Oficial Red AUTI (Red Temática en Aplicaciones y Usabilidad en Televisión Digital

Interactiva) http://redauti.net/

SOARES L.F.G, RODRIGUES R.F. y MORENO M.F. (2007) Ginga-ncl: the declarative

environment of the brazilian digital TV system. In Journal of the Brazilian Computer

Society, v.12,pp 37-46. http://www.telemidia.puc-rio.br/ https://doi.org/10.1590/S0104-

65002007000100005 SOARES L.F.G y RODRIGUES R.F. (2005) Nested Context Model 3.0: Part 1 – NCM

Core, Technical Report, Departamento de Informática. PUC-Rio. ISSN:0103-9741


131

ICT-UNPA-162-2017ISSN: 1852-4516


https://doi.org/10.2498/cit.2002.01.01

https://doi.org/10.1109/TLA.2014.6894009

https://doi.org/10.1007/978-1-84882-275-7

http://tvd.lifia.info.unlp.edu.ar/ginga.ar/

http://www.ncl.org.br/

https://doi.org/10.1590/S0104-65002007000100005

https://doi.org/10.1590/S0104-65002007000100005

Date post:	17-Aug-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Test suite for a generator of TVDI applications using ... · multimedia/hipermedia desarrolladas...

Documents