Pruebas, conclusiones, plani cación y presupuesto.

Parte V
Pruebas, conclusiones, planicación
y presupuesto.
Capítulo 16
Pruebas realizadas.
16.1. Introducción.
En esta sección se comentan las pruebas que se han realizado a LinceVisión. Las pruebas van
a consistir en vericar que:
Se cumple con la funcionalidad especicada en la parte III, Diseño de la aplicación cliente ,
en la sección de Funcionalidad . Es decir, se verica que la aplicación es ecaz.
No se producen errores inesperados ni excepciones descontroladas, es decir, se verica que
la aplicación es able.
El rendimiento de la aplicación es aceptable, es decir, se verica que la aplicación es eciente.
Se han realizado las pruebas principalmente en dos tipos de escenarios:
Pruebas haciendo uso de un emulador de terminal móvil.
Pruebas sobre un dispositivo real.
A continuación se verá cuáles son los requisitos previos que se necesitan para probar LinceVisión,
los cheros de prueba utilizados, se detallarán los escenarios de prueba y se mostrará los resultados
obtenidos.
16.2. Requisitos previos.
Los requisitos para realizar las pruebas son:
Emulador/terminal móvil real.
Disponer de una implementación de la JSR-272.
Ficheros de prueba ESG.
Además para las pruebas en el dispositivo real se necesita:
Terminal móvil con receptor de señal de DVB-H.
1
Máquina virtual de JavaME que disponga de al menos :
1 La
ˆ
CLDC1.1/MIPD2.0 con sus librerías.
ˆ
JNI.
explicación de estos requisitos se da en la parte III, Diseño de la aplicación cliente , en la sección 7.4.
254
Pruebas realizadas.
Disponer de una señal emitida en DVB-H que el terminal sea capaz de capturar y de la que
sea capaz de extraer el chero ESG.
Sin embargo no se dispone de algunos de los requisitos iniciales arriba listados. La carencia más
notable es la falta de una implementación libre y completa de la JSR-272. En el capítulo primero,
Introducción, se comentó que este proyecto surge en conjunto con otro proyecto de realización
paralela que se encarga de realizar una implementación libre de la API JSR-272. Ambos conforman
el proyecto de Minerva 3C-048 Cliente DVB-H modular y de código abierto . Para realizar estas
pruebas se ha utilizado esta implementación, la cual aún está desarrollándose por lo que no está
completa. Las funcionalidades que es capaz de realizar esta implementación de la API JSR-272
son:
Lectura de ESG a partir de contenedores FLUTE almacenados en el sistema de cheros del
emulador/terminal móvil. Esta característica nos obliga a disponer de la API JSR-75 en la
KVM.
Selección de la ESG por defecto.
Consultas a la base de datos según la especicación para la obtención de la información
relativa a los servicios de televisión y descarga y de la EPG. Es decir, implementación de las
clases y métodos del paquete
javax.microedition.broadcast.esg.
Consulta de la interactividad de tipo voto y link externo.
Lo que implica que esta librería aún no implementa:
Búsqueda de plataformas.
Sintonización de plataforma.
Obtención de diversas ESG que se puedan enviar en dicha plataforma.
Mecanismos de actualización y de aviso de cambio de la información obtenida de la ESG.
Funcionalidad de descarga de archivos enviados por el canal de difusión (ya sea por FLUTE
o RTP).
Obtención y descodicación de la señal de vídeo/audio del ujo RTP a partir de la información contenida en el fragmento Acquisition de la ESG.
Esto quiere decir que a día de escritura de este proyecto se han podido realizar pruebas en
relación con la presentación de la información leída de la ESG, pero no de:
Actualización de la ESG.
Obtención y presentación del vídeo.
Búsqueda de plataformas y su selección.
Cambio de ESG.
Descarga de cheros.
Toda esta funcionalidad, como se ha visto en la parte anterior, está implementada, pero no ha
podido ser probada.
Para poder probar al menos la reproducción del vídeo en la interfaz gráca (aunque no su
captura de la señal difundida) la parte de LinceVisión que se encarga de la reproducción de vídeo
de hecho se ha tenido que codicar para dos casos diferentes:
En el caso de los emuladores, los cuales soportan la librería MMAPI, se han codicado las
clases
VideoMenuManager y VideoMenu
para que reproduzcan un vídeo obtenido del sistema
de cheros en vez de la señal difundida por DVB-H.
16.3 Ficheros de prueba.
255
En el caso de los terminales móviles reales, cuyas KVMs no soportan MMAPI, se han codicado las clases anteriores para que muestren una imagen estática en lugar de un vídeo.
Ambas funcionalidades están presentes en el código. Para habilitar una u otra se ha hecho
uso de directivas de preprocesado. Según el tipo de dispositivo (real o emulado) donde se fuera a
realizar la prueba, se ha compilado la aplicación con unas directivas de preprocesado u otras.
Se espera que conforme vaya evolucionando el proyecto de Minerva 3C-048 se vayan implementando las funcionalidades de las que carece actualmente la JSR-272, por lo que en un futuro será
posible realizar pruebas del resto de funcionalidades.
Por último hay que señalar que para probar la funcionalidad del voto interactivo es necesaria la
® para Guadaltel® , empresa que se encarga de proveer contenidos de
existencia de un servidor de votaciones. Actualmente existe activo un servidor de votaciones HTTP
creado por la empresa CITIC
interactividad para DVB-H. Este servidor es el que se ha utilizado para las pruebas. La dirección
® y el grupo que se encarga de la implementación
donde se encuentra este servidor se contiene en los cheros de ESG utilizados en las pruebas,
codicados según lo acordado entre Guadaltel
de la JSR-272 del área de Telemática de la Escuela de Ingenieros de la Universidad de Sevilla.
® no implementa un servidor de votaciones SMS, por lo que esta fun-
Sin embargo, CITIC
cionalidad tampoco ha podido probarse.
Esto quiere decir que la funcionalidad que se va a probar se corresponde con la listada en la
parte III: Diseño de la aplicación cliente , en la sección 7.1: Funcionalidad , cuyos números son:
2 - Presentación de plataformas.
5 - Presentación de ESGs.
7 - Lectura y presentación de servicios de televisión contenidos en la ESG.
8 - Lectura de los eventos de televisión programados contenidos en la ESG.
9 - Presentación en forma de lista y de cuadro de los eventos de televisión programados
obtenidos en el punto anterior.
2
13 - Presentación del vídeo de un servicio de televisión .
14 - Lectura y presentación de los servicios interactivos tipo voto y link externo.
3
15 - Ejecución de funcionalidad de los anteriores servicios interactivos .
16 - Lectura de los servicios de descarga y sus contenidos asociados procedentes de la ESG,
así como su presentación al usuario.
18 - Conguración de LinceVisión: cambio de idioma y denición de plataforma por defecto.
16.3. Ficheros de prueba.
Como se ha comentado en la sección anterior, la implementación de la JSR-272 de la que se
dispone necesita de los contenedores que genera FLUTE con los distintos archivos que se difunden.
Entre esos archivos se encuentra la ESG que describe el contenido tanto del ujo de audio/vídeo
y otros cheros que se mandan por RTP como todos los archivos que se difunden por FLUTE. Se
han utilizado dos cheros de ESG para realizar las pruebas. Cada uno de ellos conformará cada
una de las pruebas a realizar en cada escenario. Como disponemos de dos cheros de prueba, esto
quiere decir que se realizarán dos pruebas por cada escenario, la Prueba 1 hará referencia al
primer chero y la Prueba 2 hará referencia al segundo. Los cheros de ESG utilizados son:
2 Se presentará un vídeo obtenido
3 A excepción del voto tipo SMS.
del sistema de cheros.
256
Pruebas realizadas.
1) Fichero
esg_10_hoy.xml
(Prueba 1).
Se corresponde con un chero que representa a una ESG completa que comúnmente se podría
enviar por el canal de difusión.
Este chero contiene:
10 servicios de televisión, cada uno con su correspondiente EPG desde el inicio del día actual
hasta el n del día. Cada servicio contiene una EPG con una cantidad de programas variable,
siendo su media de unos 11 programas denidos por servicio de televisión, y un logotipo de
televisión codicado en Base16, incluido en la ESG.
4 servicios de descarga, cada uno con su correspondiente programación de descarga, compuesta por 8 programas de descarga, 4 para la primera mitad del día y los restantes 4 para
la segunda mitad.
1 SDP por cada servicio, incrustado en la ESG, lo que hace un total de 14 segmentos SDP.
8 de los servicios de televisión contienen interactividad asociada, los cuales:
ˆ
2 servicios contienen un servicio de votación asociado.
ˆ
2 servicios contienen un link interactivo asociado.
ˆ
2 servicios contienen tanto un servicio de votación como un link asociado simultáneos.
Este chero, al que se le ha eliminado mucho contenido, es el siguiente:
<? xml v e r s i o n=" 1 . 0 "
e n c o d i n g="UTF−8" ?>
<ESGMain xml:lang=" e n g "
r i g h t s O w n e r=" t h a l e s b m "
p u b l i s h e r=" t h a l e s b m "
p u b l i c a t i o n T i m e=" 2009 − 06 − 29 T 1 4 : 0 8 : 0 5 Z "
x m l n s : m p e g 7=" u r n : m p e g : m p e g 7 : s c h e m a : 2 0 0 1 "
x m l n s : t v a=" u r n : t v a : m e t a d a t a : 2 0 0 5 "
x m l n s : x s i=" h t t p : / /www . w3 . o r g / 2 0 0 1 /XMLSchema− i n s t a n c e "
x m l n s=" u r n : d v b : i p d c : e s g : 2 0 0 5 "
x m l n s : e s g=" u r n : d v b : i p d c : e s g : 2 0 0 5 ">
<C o p y r i g h t N o t i c e>T h a l e s
C o p y r i g h t</ C o p y r i g h t N o t i c e>
<ESG>
<C o n t e n t T a b l e>
<C o n t e n t
c o n t e n t I D=" d v b i p d c : / / e x a m p l e . com/ RingTone1 ">
<T i t l e
xml:lang=" en ">Ri ng
<Genre
h r e f=" u r n : t v a : m e t a d a t a : c s : C o n t e n t C S : 2 0 0 5 : 5 . 4 . 5 " />
Tone
1</ T i t l e>
<D u r a t i o n>PT20S</ D u r a t i o n>
</ C o n t e n t>
<C o n t e n t
c o n t e n t I D=" d v b i p d c : / / e x a m p l e . com/ RingTone2 ">
<T i t l e
xml:lang=" en ">Ri ng
<Genre
h r e f=" u r n : t v a : m e t a d a t a : c s : C o n t e n t C S : 2 0 0 5 : 5 . 6 " />
Tone
2</ T i t l e>
<D u r a t i o n>PT30S</ D u r a t i o n>
</ C o n t e n t>
[ . . . ]
</ C o n t e n t T a b l e>
<S c h e d u l e E v e n t T a b l e>
<S c h e d u l e E v e n t
x m l n s=" u r n : d v b : i p d c : e s g : 2 0 0 5 "
s c h e d u l e I D=" c b m s : / / thomson . n e t / s c h e d u l e e v e n t / p u s h 1 ">
<P u b l i s h e d S t a r t T i m e>2009 − 06 − 29 T 0 9 : 0 0 : 0 0 Z</ P u b l i s h e d S t a r t T i m e>
<P u b l i s h e d E n d T i m e>2009 − 06 − 29 T 1 5 : 0 0 : 0 0 Z</ P u b l i s h e d E n d T i m e>
<S e r v i c e R e f
IDRef=" d v b i p d c : / / e x a m p l e . com/ Push " />
<C o n t e n t F r a g m e n t R e f
IDRef=" d v b i p d c : / / e x a m p l e . com/ RingTone1 " />
<C o n t e n t L o c a t i o n> h t t p : / / e x a m p l e . com/ RingTone1 . mp3</ C o n t e n t L o c a t i o n>
<C o n t e n t F r a g m e n t R e f
IDRef=" d v b i p d c : / / e x a m p l e . com/ RingTone2 " />
<C o n t e n t L o c a t i o n> h t t p : / / e x a m p l e . com/ RingTone2 . mp3</ C o n t e n t L o c a t i o n>
<C o n t e n t F r a g m e n t R e f
IDRef=" d v b i p d c : / / e x a m p l e . com/ RingTone3 " />
<C o n t e n t L o c a t i o n> h t t p : / / e x a m p l e . com/ RingTone3 . mp3</ C o n t e n t L o c a t i o n>
</ S c h e d u l e E v e n t>
<S c h e d u l e E v e n t
x m l n s=" u r n : d v b : i p d c : e s g : 2 0 0 5 "
s c h e d u l e I D=" c b m s : / / thomson . n e t / s c h e d u l e e v e n t / p u s h 2 ">
<P u b l i s h e d S t a r t T i m e>2009 − 06 − 29 T 1 5 : 0 0 : 0 0 Z</ P u b l i s h e d S t a r t T i m e>
16.3 Ficheros de prueba.
257
<P u b l i s h e d E n d T i m e>2009 − 06 − 29 T 2 3 : 0 0 : 0 0 Z</ P u b l i s h e d E n d T i m e>
<S e r v i c e R e f
IDRef=" d v b i p d c : / / e x a m p l e . com/ Push " />
<C o n t e n t F r a g m e n t R e f
IDRef=" d v b i p d c : / / e x a m p l e . com/ RingTone4 " />
<C o n t e n t L o c a t i o n> h t t p : / / e x a m p l e . com/ RingTone4 . mp3</ C o n t e n t L o c a t i o n>
<C o n t e n t F r a g m e n t R e f
IDRef=" d v b i p d c : / / e x a m p l e . com/ RingTone5 " />
<C o n t e n t L o c a t i o n> h t t p : / / e x a m p l e . com/ RingTone5 . mp3</ C o n t e n t L o c a t i o n>
<C o n t e n t F r a g m e n t R e f
IDRef=" d v b i p d c : / / e x a m p l e . com/ RingTone6 " />
<C o n t e n t L o c a t i o n> h t t p : / / e x a m p l e . com/ RingTone6 . mp3</ C o n t e n t L o c a t i o n>
</ S c h e d u l e E v e n t>
[ . . . ]
</ S c h e d u l e E v e n t T a b l e>
<S e r v i c e T a b l e>
<S e r v i c e
s e r v i c e I D=" d v b i p d c : / / e x a m p l e . com/ Push ">
<S e r v i c e N a m e>Push
S e r v i c e</ S e r v i c e N a m e>
<S e r v i c e N u m b e r>5 0</ S e r v i c e N u m b e r>
<S e r v i c e T y p e
h r e f= ' u r n : d v b : i p d c : e s g : c s : S e r v i c e T y p e C S : 1 . 3 . 2 '
<S e r v i c e T y p e
h r e f= ' u r n : d v b : i p d c : e s g : c s : S e r v i c e T y p e C S : 2 . 2 '
<A c q u i s i t i o n R e f
/>
/>
IDRef=" d v b i p d c : / / e x a m p l e . com/ A c q u i s i t i o n / Push " />
</ S e r v i c e>
<S e r v i c e
s e r v i c e I D=" c b m s : // thomson . n e t / s e r v i c e / 1 0 "
f r e e T o A i r=" t r u e "
c l e a r T o A i r=" t r u e ">
<S e r v i c e N a m e>La10</ S e r v i c e N a m e>
<S e r v i c e N u m b e r>1 0</ S e r v i c e N u m b e r>
<S e r v i c e L o g o>
<m p e g 7 : T i t l e I m a g e>
<m p e g 7 : I n l i n e M e d i a
t y p e=" i m a g e / png ">
<m p e g 7 : M e d i a D a t a 1 6>8 9 5 0 4 e 4 7 0 d 0 a 1 a 0 a 0 0 0 0 0 0 0 d 4 9 4 8 4 4 5 2 0 0 0 0 0 0 6 e 0 0 0 0 0 0
4 f08030000003d75005a00000060504c5445f68a337dcaa0109e53b3b
2 b2f79c519cd7b75654552b27285cbd89f7f2effcd6b7716e6ff9ba86
40 b 1 7 4 f 5 7 f 2 0 e f f 8 f 3 c f e b d c 3 0 a b 6 9 2 0 a 5 5 d 8 4 8 2 8 2 e 7 e 4 e 1 a f d e c 5 b f e
5 d1918f8fc8c7c7d6d5d59e9d9ddff2e8918f90009847009746ffffffb
[ . . . ]
c9502f80000004068495354000f004400150024000f002300430058002
30 e 6 2 9 c f 8 c 8 0 6 a 4 a 6 b f d 7 7 1 3 f 6 9 f f 0 1 d 6 7 2 c 5 3 1 b 8 e 3 1 c d 3 0 0 0 0 0 0 0 0 4 9 4
54 e 4 4 a e 4 2 6 0 8 2
</ m p e g 7 : M e d i a D a t a 1 6>
</ m p e g 7 : I n l i n e M e d i a>
</ m p e g 7 : T i t l e I m a g e>
</ S e r v i c e L o g o>
< S e r v i c e D e s c r i p t i o n>C a n a l
<S e r v i c e G e n r e
<S e r v i c e T y p e
de
television
de
A n d a l u c i a</ S e r v i c e D e s c r i p t i o n>
h r e f=" u r n : t v a : m e t a d a t a : c s : C o n t e n t C S : 2 0 0 4 : 3 . 5 " />
h r e f=" u r n : d v b : i p d c : e s g : c s : S e r v i c e T y p e C S : 1 . 1 " />
<P a r e n t a l G u i d a n c e>
<mpeg7:MinimumAge>0</ mpeg7:MinimumAge>
</ P a r e n t a l G u i d a n c e>
<S e r v i c e L a n g u a g e>e n g</ S e r v i c e L a n g u a g e>
< S e r v i c e P r o v i d e r>
<P r o v i d e r N a m e>svm</ P r o v i d e r N a m e>
</ S e r v i c e P r o v i d e r>
<A c q u i s i t i o n R e f
IDRef=" c b m s : // thomson . n e t / a c q u i s i t i o n / A 4 7 1 7 3 2 1 0 1 4 9 0 4 8 " />
<R e l a t e d M a t e r i a l>
<HowRelated
h r e f=" u r n : t h o m s o n : i p d c : e s g : c s : C o n t e n t T y p e C S : 2 0 0 6 : 6 " />
<M e d i a L o c a t o r>
<m p e g 7 : M e d i a U r i> h t t p : / /www . h o t m a i l . com</ m p e g 7 : M e d i a U r i>
</ M e d i a L o c a t o r>
<P r o m o t i o n a l T e x t
xml:lang=" e s p ">C o n s u l t a
tu
c o r r e o</ P r o m o t i o n a l T e x t>
</ R e l a t e d M a t e r i a l>
<R e l a t e d M a t e r i a l>
<HowRelated
h r e f=" u r n : t h o m s o n : i p d c : e s g : c s : V o t i n g C S : 2 0 0 6 : 1 " />
<M e d i a L o c a t o r>
<m p e g 7 : M e d i a U r i> h t t p : / / 1 9 3 . 1 4 7 . 1 6 5 . 8 6 / e u i s v m m o b i l e / v o t e R e s u l t s . do ?
v o t e I d = 5 7 1 6 5 1 0 3 4 1 3 7 8 8 7 7 7 3 2</ m p e g 7 : M e d i a U r i>
</ M e d i a L o c a t o r>
<P r o m o t i o n a l T e x t
</ R e l a t e d M a t e r i a l>
xml:lang=" e n g ">Vota
aqui
t a m b i e n !</ P r o m o t i o n a l T e x t>
258
Pruebas realizadas.
<R e l a t e d M a t e r i a l>
<HowRelated
h r e f=" u r n : t h o m s o n : i p d c : e s g : c s : V o t i n g C S : 2 0 0 6 : 3 " />
<M e d i a L o c a t o r>
<m p e g 7 : M e d i a U r i>s m s t o : + 3 4 6 0 0 0 0 0 0 0 0 ? v o t e I d = 5 7 1 6 5 1 0 3 4 1 3 7 8 8 7 7 7 3 2 &amp ;
a n s w e r I d = 8 1 6 2 6 4 9 1 5 9 0 7 2 5 3 7 5 3</ m p e g 7 : M e d i a U r i>
</ M e d i a L o c a t o r>
<P r o m o t i o n a l T e x t
xml:lang=" e n g ">O p c i o n
1</ P r o m o t i o n a l T e x t>
</ R e l a t e d M a t e r i a l>
<R e l a t e d M a t e r i a l>
<HowRelated
h r e f=" u r n : t h o m s o n : i p d c : e s g : c s : V o t i n g C S : 2 0 0 6 : 3 " />
<M e d i a L o c a t o r>
<m p e g 7 : M e d i a U r i>s m s t o : + 3 4 6 0 0 0 0 0 0 0 0 ? v o t e I d = 5 7 1 6 5 1 0 3 4 1 3 7 8 8 7 7 7 3 2 &amp ;
a n s w e r I d = 2 5 2 2 3 5 0 8 5 5 6 3 0 0 7 6 4 8 7</ m p e g 7 : M e d i a U r i>
</ M e d i a L o c a t o r>
<P r o m o t i o n a l T e x t
xml:lang=" e n g ">O p c i o n
2</ P r o m o t i o n a l T e x t>
</ R e l a t e d M a t e r i a l>
<R e l a t e d M a t e r i a l>
<HowRelated
h r e f=" u r n : t h o m s o n : i p d c : e s g : c s : V o t i n g C S : 2 0 0 6 : 4 " />
<M e d i a L o c a t o r>
<m p e g 7 : M e d i a U r i> h t t p : / / 1 9 3 . 1 4 7 . 1 6 5 . 8 6 / e u i s v m m o b i l e / v o t e R e s u l t s . do ?
v o t e I d = 5 7 1 6 5 1 0 3 4 1 3 7 8 8 7 7 7 3 2</ m p e g 7 : M e d i a U r i>
</ M e d i a L o c a t o r>
</ R e l a t e d M a t e r i a l>
</ S e r v i c e>
[ . . . ]
</ S e r v i c e T a b l e>
< A c q u i s i t i o n T a b l e>
<A c q u i s i t i o n
contentMimeType=" a u d i o /mp3"
a c q u i s i t i o n I D=" d v b i p d c : // e x a m p l e . com/ A c q u i s i t i o n / Push ">
<C o m p o n e n t D e s c r i p t i o n>
<C o m p o n e n t C h a r a c t e r i s t i c
<S e s s i o n D e s c r i p t i o n
x s i : t y p e =" FileDownloadComponentType " />
x s i : t y p e =" I n l i n e d S D P T y p e ">
<SDP>< ! [CDATA[ v=0 o=e x a m p l e . com
FE80::1:4D3E
0
a=f l u t e
incl
IN
s=Rin g
−t s i : 9 5 3 2
IP6
*
FLUTE/UDP 0
tone
751092616
download
a=f l u t e
−c h : 1
751111042
service
IP6
IP6
a=s o u r c e − f i l t e r :
F E 8 0 : : 2 : : 7 0 C A m=a p p l i c a t i o n
c=IN
IN
t =0
FF15::1:141B
12345
] ]>
</SDP>
</ S e s s i o n D e s c r i p t i o n>
</ C o m p o n e n t D e s c r i p t i o n>
</ A c q u i s i t i o n>
[ . . . ]
</ A c q u i s i t i o n T a b l e>
</ESG>
</ESGMain>
En este chero se aprecia la estructura principal del XML que describe a la ESG, donde se
incluyen los cuatro fragmentos que componen la ESG:
Content
Schedule
Service
Acquisition
El primer Service se corresponde con un servicio de descarga. El Acquisition asociado es el mostrado
al nal del chero. En él se incrusta el SDP donde se reeja la sesión FLUTE por el que se está
emitiendo dicho servicio.
El segundo Service mostrado contiene la descripción de una interactividad tipo voto y otra de
tipo link externo a partir de los campos RelatedMaterial incluidos. Además se incluye el logotipo
del servicio de televisión, codicado en Base16.
16.4 Escenarios de pruebas.
2) Fichero
esg_carga.xml
259
(Prueba 2).
Se corresponde con un chero que representa a una ESG pesada, es decir, una aproximación de
la máxima información que se recibirá por el canal de difusión. Se utilizará para realizar pruebas
de carga.
Este chero se corresponde con tres veces el chero anterior, es decir:
30 servicios de televisión, cada uno con su correspondiente EPG desde el inicio del día actual
hasta el n del día y un logotipo de televisión codicado en Base16, incluido en la ESG. En
total se denen 356 programas de televisión y 30 logotipos.
12 servicios de descarga, cada uno con su correspondiente programación de descarga, compuesta por 8 programas de descarga, 4 para la primera mitad del día y los restantes 4 para
la segunda mitad. Por tanto en total se describen 96 programas de descarga.
1 SDP por cada servicio, incrustado en la ESG. Esto hace un total de 42 segmentos SDP.
24 de los servicios de televisión contienen interactividad asociada:
ˆ
6 servicios contienen un servicio de votación asociado.
ˆ
6 servicios contienen un link interactivo asociado.
ˆ
6 servicios contienen tanto un servicio de votación como un link asociado simultáneos.
16.4. Escenarios de pruebas.
Como se ha comentado anteriormente se han realizado pruebas principalmente en dos escenarios:
Emulador de terminal móvil.
Terminal móvil real.
16.4.1. Pruebas en el emulador.
Se han utilizado dos emuladores de terminales móviles simultáneamente, debido a que ambos
aportan una característica de la que el otro carece:
4
Emulador DefaultColorPhone de Sun Java WirelessToolkit 2.5.2 . Aporta un monitor de
memoria y de creación de objetos. Hay que hacer notar que el monitor de memoria resulta
poco útil para medir la carga en el sistema aportada únicamente por LinceVisión. Debido
a que la librería JSR-272 utilizada no está incluida dentro de la máquina virtual de la que
hace uso el emulador, sino que se distribuye en el mismo paquete junto con LinceVisión, los
resultados relativos a la memoria serán siempre compartidos entre la memoria de la que hace
uso la JSR-272 y la memoria de la que hace uso la aplicación LinceVisión. Sin embargo el
monitor de creación de objetos que aporta este emulador sí que se puede utilizar para medir
los objetos instanciados únicamente por LinceVisión, ya que el espacio de nombres de sus
clases es distinto al utilizado por la API JSR-272 utilizada.
5
Emulador HTCTouch de Sprint WirelessToolkit 3.3.2 . Aporta emulación de pantalla táctil.
Ambos emuladores se pueden integrar en el IDE utilizado: NetBeans IDE 6.5. Igualmente ambos
emuladores cuentan con las siguientes características:
Implementación total de CLDC1.1/MIDP2.0.
4 Enlace
5 Enlace
web:
web:
http://java.sun.com/products/sjwtoolkit/.
http://developer.sprint.com/site/global/develop/technologies/java_me/p_java_me.jsp.
260
Pruebas realizadas.
Soporte de transparencias e imágenes codicadas en formatos diferentes a PNG.
Soporte a las librerías MMAPI y JSR-75.
6
Sin embargo, ninguno de los emuladores soporta JNI .
Los códigos de las pruebas realizadas en este escenario serán los siguientes:
Código
Descripción prueba.
EMUL-DEF-01
EMUL-DEF-02
EMUL-HTC-01
EMUL-HTC-02
Prueba 1 en el emulador DefaultColorPhone de Wireless
Toolkit 2.5.1.
Prueba 2 en el emulador DefaultColorPhone de Wireless
Toolkit 2.5.1.
Prueba 1 en el emulador HTCTouch de Sprint
WirelessToolkit 3.3.2.
Prueba 2 en el emulador HTCTouch de Sprint
WirelessToolkit 3.3.2.
Cuadro 16.1: Códigos de pruebas para el escenario de emuladores.
16.4.2. Pruebas en el terminal real.
Los terminales reales de los que se han dispuesto son:
Teléfono GSmart t600 de la compañía Gigabyte. Su sistema operativo es Windows Mobile
5. Cuenta con una pantalla táctil TFT VGA a 260.000 colores, de 2,6 (480x640 píxeles).
Incorpora un receptor multi-estándar DVB-T / DVB-H / T-DMB.
PDA Fujitsu-Siemens Loox N520. Su sistema operativo es Windows Mobile 5. Cuenta con
una pantalla táctil TFT de 3.5" (240x320 píxeles).
En ambos terminales se ha instalado la misma máquina virtual:
Máquina virtual J9 de IBM CLDC1.1 y MIDP2.0, con soporte a JNI y API JSR-75. Esta
es una máquina virtual creada por IBM para dar soporte a JNI. La versión utilizada es la
gratuita de pruebas para proyectos de investigación. Como características cabe resaltar su
limitada potencia gráca (baja calidad de presentación de grácos que provoca serrado en
las líneas curvas, no da soporte a imágenes distintas a PNG ni a transparencias, ni incluye
la librería MMAPI para la reproducción de audio/vídeo), y la integración de la softBar
nativa en la máquina virtual, es decir, los eventos relacionados con los comandos los relega
al sistema operativo en vez de ser tratados por la máquina virtual.
Los códigos de las pruebas realizadas en este escenario serán los siguientes:
Código de la
prueba
Descripción prueba.
REAL-GS-01
Prueba 1 en el terminal GSmart t600 de GigaByte.
REAL-GS-02
Prueba 2 en el terminal GSmart t600 de GigaByte.
REAL-FS-01
Prueba 1 en el terminal Loox N520 de Fujitsu-Siemens.
REAL-FS-02
Prueba 2 en el terminal Loox N520 de Fujitsu-Siemens.
Cuadro 16.2: Códigos de pruebas para el escenario de terminales
reales.
6 Característica
que no es de extrañar ya que JNI es totalmente incompatible con el modelo de seguridad espe-
cicado por JavaME. Más información en la parte II, Tecnologías Implicadas , en la sección de JavaME .
16.5 Resultados.
261
16.5. Resultados.
Los resultados de las distintas pruebas se muestran en el siguiente cuadro:
Código
Ecacia
Fiabilidad
Eciencia
EMUL-DEF-01
OK
OK
OK
EMUL-DEF-02
OK
EMUL-HTC-01
OK
OK
OK
EMUL-HTC-02
OK
OK
OK
REAL-GS-01
OK
OK
KO
REAL-GS-02
KO
KO
KO
REAL-FS-01
OK
OK
KO
REAL-FS-02
KO
KO
KO
OK
7
OK
Cuadro 16.3: Resultados de las distintas pruebas realizadas a LinceVisión.
Del cuadro anterior hay que resaltar los siguientes puntos:
El emulador de Sprint tiene un mejor comportamiento que el emulador de Sun. Esto puede
ser porque el emulador de Sun sea más restrictivo en cuanto a la emulación de la memoria
volátil asignada a la máquina virtual.
Eciencia en los terminales reales: El tiempo de respuesta de los terminales es lento para
la satisfacción de un usuario. Es necesario seguir trabajando en conjunto con el equipo
de implementación de la JSR-272 para mejorar los aspectos de eciencia en los terminales
móviles reales. Como ya se ha comentado, hay que tener en cuenta que la máquina virtual con
la que se está trabajando en los dispositivos reales (J9 de IBM) es una máquina virtual base
cuya capacidad gráca es muy limitada. Para una aplicación cuya interfaz gráca y lógica
requiere tantos recursos, tanto de procesamiento como de memoria, como es LinceVisión (y
más si se distribuye la implementación de la JSR-272 junto con ella, por lo que esta también
consumirá recursos) es muy recomendable el uso de otra máquina virtual más potente. Por
norma general las máquinas virtuales que vienen de facto con los terminales móviles (cuyo
sistema operativo es distinto a Windows Mobile) suelen ser más potente, sin embargo, no
disponen de JNI, por lo que no sería posible el uso del link interactivo.
Prueba de carga en terminales reales: Los terminales reales no pasaron la prueba de carga
(Prueba 2), ya que se lanzó una excepción de tipo
OutOfMemoryException
durante la ini-
cialización de LinceVisión. Es decir, que ni siquiera se llegó a mostrar la pantalla inicial con
la lista de servicios. Esto signica que la excepción se lanzó por parte de la librería JSR-272,
8
mientras procesaba la información de la ESG, y no por parte de LinceVisión . Este hecho
impide que se valore el comportamiento de LinceVisión en un escenario real en una situación
de carga.
7 Para
el caso de la presentación de la EPG en forma de cuadro KO. Se obtiene una excepción de tipo
OutOfMemoryException.
Esto causa que no se muestre la EPG, pero a pesar de ello el sistema sigue funcionan-
do satisfactoriamente.
8 Hay
que señalar que durante el proceso de inicialización LinceVisión carga las librerías para Localización y
para la interfaz gráca, lo que supone una pequeña disminución de memoria total de la que dispone la JSR-272.
Desgraciadamente no se puede disminuir la memoria ocupada por estas librerías, por lo que todo el trabajo estará
en la optimización de la implementación de la API JSR-272.
262
Pruebas realizadas.
Capítulo 17
Conclusiones y líneas futuras de
trabajo.
17.1. Conclusiones.
La aplicación desarrollada proporciona una solución única para la visualización del contenido
informativo presente en la Guía Electrónica de Servicios enviada por el canal de datos en un
entorno de difusión de señal DVB-H.
Así mismo esta aplicación va más allá, pues es capaz de entender, representar y proveer la
lógica necesaria para hacer uso del contenido interactivo presente también en la ESG, como son
los servicios de descarga, el voto interactivo o el link externo, lo que supone un inmenso valor
añadido con el que muchas del resto de aplicaciones disponibles no cuentan.
Otras bondades de la aplicación desarrollada son su capacidad de actualización automática
conforme el contenido informativo presente en la ESG va cambiando y su habilidad para representar
la Guía Electrónica de Programas en forma de cuadro. Este es otro aspecto diferenciador de
LinceVisión con respecto a otros clientes que se encuentran actualmente en el mercado, junto con
su apariencia única y distinguible.
Pero sobre todo la principal ventaja de LinceVisión con respecto al resto de la oferta en el
sector es la consecución del principal objetivo marcado en el desarrollo de este cliente, listado en
el capítulo 1 de Introducción:
Desarrollo de un
cliente modular de código libre y abierto para la representación
del contenido difundido por una señal DVB-H.
El hecho de que LinceVisión se haya desarrollado a partir de una API estandarizada para la
recepción de servicios DVB-H, la API JSR-272, supone una apertura universal de la aplicación,
ya que se aumenta exponencialmente su portabilidad. Esta característica se ve incrementada por
el hecho de poder utilizarse libremente bajo licencia GPL2.0 y, mejor aún, por el hecho de ser
personalizable para cada necesidad en concreto, ya que el código se distribuye de manera abierta.
Esto implica que LinceVisión supone una solución casi-universal, lejos de todas las soluciones
particulares que hoy en día se está dando a las necesidades de cada servidor de contenidos. Para
conseguir la universalidad total es necesario que LinceVisión implemente el estándar OMA-BCAST
en oposición al ahora implementado IPDC, ya que como se ha visto en este documento, IPDC no
provee de una especicación estandarizada para la interactividad, mientras que este aspecto en
1 entre
el estándar OMA-BCAST está bien denido, logrando así una interoperatividad casi total
todos los servidores de contenidos que hagan uso de OMA-BCAST para describir los contenidos que
generen. La ampliación de LinceVisión para que albergue igualmente al estándar OMA-BCAST se
considera como una línea futura de trabajo para una segunda fase en el desarrollo de la aplicación.
1 Habría
que superar el escollo de la falta de estandarización de gran parte de la interactividad en la JSR-272.
264
Conclusiones y líneas futuras de trabajo.
A continuación se va a particularizar para cada característica deseable en LinceVisión comentadas en la parte II Diseño de la aplicación cliente , analizándose hasta qué punto se han cumplido
los objetivos marcados:
Funcionalidad. La totalidad de la funcionalidad que en un principio se consideró implementar en LinceVisión ha sido cubierta a excepción de la representación del vídeo difundido en la
señal DVB-H. Esta última no ha podido implementarse por motivos ajenos a este proyecto.
Usabilidad.
LinceVisión resulta una aplicación de fácil manejo e intuitiva. Esto se debe
al uso de una interfaz gráca que cumple con el paradigma WIMP. Aún así la medida
de la usabilidad está sujeta a gran subjetividad, ya que cada usuario tendrá una opinión
personal acerca de este aspecto de la aplicación. Será necesario obtener un feedback de
estas opiniones para mejorar lo más posible la usabilidad de la aplicación.
Eciencia. Este es el principal aspecto a mejorar por LinceVisión. En el apartado Pruebas
se concluyó que la aplicación no es del todo eciente en terminales móviles reales, sobre todo
en situaciones de alta carga. Esto se debe en gran medida a el uso de una máquina virtual
poco potente y a la ejecución en conjunto con la implementación de la API JSR-272 realizada
por la Universidad de Sevilla.
Portabilidad. LinceVisión posee una alta portabilidad debido a que se trata de una aplicación MIDlet. Como se ha comentado en este documento, JavaME conforma una plataforma
de uso universal y el uso de la API JSR-272 aumenta aún más la portabilidad de este MIDlet. Se espera que en los meses venideros empiecen a comercializarse terminales móviles que
dispongan de facto de una implementación de la JSR-272.
Mantenibilidad.
LinceVisión ha sido concebido y desarrollado como un cliente modular
con una amplia documentación (esta memoria, JavaDoc, código abierto y comentado, etc.)
por lo que este aspecto se ve totalmente satisfecho.
Fiabilidad. LinceVisión se ha sometido a muchas pruebas unitarias a lo largo de su desarro-
®
llo. Así mismo se han realizado pruebas de integración con la API JSR-272 y de interconexión
con el servidor de contenidos Guadaltel
, resultando satisfactorias a excepción de los pro-
blemas de eciencia en situaciones de alta carga ya comentados. Como se concluyó en el
capítulo de Pruebas de esta memoria, en un escenario de uso normal LinceVisión se prueba
como una aplicación able.
Por último comentar que este proyecto a nivel personal ha supuesto un gran aporte de conocimientos en relación con JavaME y, sobre todo, en relación a la arquitectura de software y los patrones
de diseño, algo de vital importancia en la carrera de cualquier profesional de las tecnologías de la
información. Además me ha dado la oportunidad de profundizar en un campo en auge como es
la televisión móvil, encontrándolo bastante interesante y considerándolo como un posible campo
en el que trabajar a partir de ahora. La realización de este proyecto ha sido una experiencia muy
enriquecedora a nivel profesional, pero no he de olvidar el nivel personal. Durante el transcurso de
este proyecto he colaborado con un grupo de personas muy trabajadoras y competentes que me
han servido de mucha ayuda a la hora de elaborar este proyecto.
17.2. Líneas futuras de trabajo.
Todo el trabajo que se ha llevado a cabo en este proyecto n de carrera se considera una
primera fase en el desarrollo del cliente nal DVB-H. Se concibe una segunda fase en la que se
planica realizar el siguiente trabajo:
Búsqueda de una máquina virtual más potente que incorpore JNI para Windows Mobile.
Esta tarea es complicada (durante la búsqueda de una máquina virtual válida solo se encontró
la comentada en el capítulo de Pruebas) y posiblemente se salga con mucho de la cantidad
presupuestada para el proyecto.
17.2 Líneas futuras de trabajo.
265
Optimización del cliente para aumentar las prestaciones de LinceVisión, de forma que pase
todas las pruebas en los dispositivos reales, incluidas las pruebas de carga. Esta optimización
pasará sobre todo por la optimización del código en cuanto a:
ˆ
Entidades de Modelo almacenadas: puede que sea necesario evitar el almacenamiento
en entidades de la información obtenida de la JSR-272 para disminuir el consumo de
memoria, lo que implica una consulta a base de datos cada vez que se requiera información. Esto irá en detrimento de la usabilidad, pero mejorará la eciencia. En cualquier
caso, la siguiente aproximación es preferible a esta.
ˆ
Habilidades de la interfaz gráca: para aligerar la carga de procesamiento, puede que
sea necesario simplicar las interfaces grácas utilizadas. Esto implica la eliminación
de listas dinámicas, imágenes, etc.
Soporte para la interactividad denida en OMA-BCAST. Además de implementar IPDC, se
contempla que LinceVisión se extienda para poder dar soporte al estándar OMA-BCAST.
Este estándar permite una mayor interoperatividad, ya que la interactividad pasa de ser
particular a universal.
Nuevas pruebas conforme vaya avanzando la implementación de la JSR-272 llevada a cabo
por el Área de Telemática, para probar la funcionalidad que aun estando implementada, no
se ha podido probar.
Modicación del código para mostrar el vídeo de la señal de difusión en vez de un vídeo
obtenido del sistema de cheros.
®
Implementación de nuevas formas de interactividad conforme la empresa Guadaltel
las
vaya incorporando en su servidor de contenidos. Algunas de estas nuevas interactividades
pueden ser:
ˆ
Representación del resultado provisional de las votaciones que el usuario registra.
ˆ
Representación de estadísticas de partidos deportivos, elecciones, votaciones, etc.
ˆ
Presentación de noticias contenidas en la ESG en la misma aplicación.
Ampliación de la funcionalidad del cliente para soportar el resto de capacidades de las que
2
la API JSR-272 provee . A saber:
2 Estas
ˆ
Gestión de compras de paquetes de servicios.
ˆ
Posibilidad de salto en el tiempo en la señal de vídeo.
ˆ
Grabación de la señal de televisión.
ˆ
Programación de grabación de la señal con PushRegistry.
capacidades se comentaron en el capítulo 6: JSR-272 de la parte II: Tecnologías Implicadas .
266
Conclusiones y líneas futuras de trabajo.
Capítulo 18
Planicación y presupuesto.
18.1. Planicación.
Este proyecto se ha planicado para tener una duración total de seis meses, la misma duración
que la beca asignada al ingeniero encargado de desarrollar la aplicación. Estos seis meses se corresponden con una primera fase en el desarrollo del cliente. Se concibe una segunda fase en paralelo
con una segunda fase en la implementación de la JSR-272, ambos proyectos pertenecientes al mismo proyecto de Minerva. Durante esta segunda fase se planica implementar la funcionalidad de
vídeo en streaming obtenido de la señal de DVB-H así como la ampliación de funcionalidad para
dar cobertura a otras nuevas formas de interactividad y a otras habilidades que se denen en la
especicación de la JSR-272. En la sección Líneas Futuras del capítulo siguiente se recoge más
información acerca de la segunda fase de este proyecto.
La planicación de este proyecto n de carrera se puede dividirse en las siguientes fases:
Preparación. En esta fase se toman los requisitos del problema que se quiere abarcar y estudia
el estado del proyecto Minerva en el que este se enmarca. También se lee la documentación
asociada. Asimismo se realiza un análisis y un primer boceto de la estructuración que tendrá
el proyecto.
Documentación y estudio previo. Aquí se recogió toda la documentación que en un principio
se creyó que iba a ser necesaria. Se realizo un amplio estudio acerca de aspectos iniciales que
se debían conocer tales como:
ˆ
Conocimientos de JavaME.
ˆ
Estudio de la API JSR-272.
ˆ
Análisis de las librerías gratuitas de interfaces grácas para JavaME.
ˆ
Estudio de librería LWUIT.
Desarrollo de la aplicación. Esta tarea corresponde con la instalación del IDE y los emuladores
y la codicación de la aplicación cliente. Las tareas a destacar en esta fase son:
ˆ
Codicación de las principales pantallas de la interfaz gráca, con especial mención del
cuadro de EPG.
ˆ
Conexión con la JSR-272: uso, creación de entidades de datos y mecanismos de actualización.
ˆ
Implementación de la interactividad: Modelo de datos y representación gráca.
ˆ
Lógica e interfaces grácas asociadas a la selección de plataforma y de ESG.
ˆ
Reproducción de vídeo si se dispone de MMAPI.
268
Planicación y presupuesto.
ˆ
Funcionalidad de conguración de LinceVisión.
ˆ
Servicios de descarga: interfaces grácas y conexión con la JSR-272.
Pruebas. Esta parte de la planicación hace referencia a las pruebas de interconexión realizadas con el grupo que se encarga de la implementación de la JSR-272 del Área de Telemática
®
de la Escuela de Ingenieros de la Universidad de Sevilla y con el servidor de contenidos
implementado por la empresa Guadaltel
.
Documentación. Esta fase comprende la creación del JavaDoc del código, del manual de
usuario y la redacción de la memoria
En la tabla de la gura 18.1 se muestra una ejecución estimada del proyecto:
Figura 18.1: Diagrama de Gantt para la planicación del proyecto.
18.2 Presupuesto.
269
18.2. Presupuesto.
Podemos distinguir dos apartados en el presupuesto de este proyecto. Un apartado es el asociado
a los recursos humanos invertidos y el otro a los recursos materiales.
En cuanto a los recursos humanos empleados serían 6 meses a jornada completa de un ingeniero,
lo que supone un sueldo de aproximadamente 3600¿, suponiendo una categorización de becario
con una asignación de 600¿ al mes. Por otro lado el presupuesto asociado a los recursos hardware,
software y a los consumibles empleados es el mostrado en el siguiente cuadro:
Coste Unitario
Unidades
Elemento
PC Pentium Core 2 Duo 2 Ghz, 2 Gb
(
¿)
¿)
Coste (
1
799
Microsoft Windows XP SP2.
1
93,14
94
Microsoft Visio Standard 2007.
1
329
329
Impresora HP Color Laser Jet CP1215.
1
149
149
6 meses
10
60
6 meses
35
210
1
50
50
1
610
610
1
110
110
RAM.
799
Consumibles
Gasto Eléctrico
Conexión ADSL.
Material de ocina.
Terminal GSmart t600 de Gigabyte
Terminal PDA Fujitsu-Siemens Loox
N520
Cuadro 18.1: Costes materiales asociados al proyecto.
El resto de herramientas utilizadas han sido gratuitas. Estas herramientas son:
Elemento
NetBeans IDE 6.5 con Mobility Pack integrado.
Sprint Wireless Toolkit 3.3.2.
GIMP 2 (The GNU Image Manipulation Program) para Windows.
Editor de textos Lyx 1.6.1.
1
MySQL Server 5.1 .
2
Apache HTTP Server 2.2 .
Plataforma de emisión DVB-H proporcionada por Minerva para
generación de ESGs y pruebas reales.
Cuadro 18.2: Herramientas gratuitas.
Luego el presupuesto total sería:
1 Para pruebas iniciales de registro
2 Idem que la anterior nota al pie.
de votación HTTP.
270
Planicación y presupuesto.
¿)
Tipo de recurso
Coste (
Recursos humanos
Recursos materiales
Total
Cuadro 18.3: Presupuesto total.
3600
2411
6011