La nueva norma UNE 153010. Una labor de consenso

La norma UNE 153010:2003 recogía requisitos para el subtitulado para personas sordas a través de teletexto. Fue el resultado de varios años de trabajo en el Subcomité 5 del Comité Técnico de Normalización (CTN) 153 de AENOR. Los cambios en los últimos años en cuanto a los medios audiovisuales llevaron a dicho Subcomité a plantearse en el año 2008 la posibilidad de actualizar los contenidos de esta norma, con el fin de adaptarse a nuevas tecnologías, como los DVD, la televisión digital o la televisión emitida a través de Internet. Inicialmente se planteó la posibilidad de realizar normas específicas de subtitulado para cada tecnología de emisión, pero finalmente se decidió desarrollar una norma general de subtitulado que fuera de aplicación general. Tras un largo periodo de trabajo, la nueva versión de la norma UNE 153010 está a punto de ver la luz, dado que se encuentra en periodo de información pública. En este artículo se narra el proceso de desarrollo de esta norma y se describe los aspectos más importantes de la misma, resultado de una intensa labor con gran voluntad de consenso por parte de las entidades implicadas.

Prototipo de e-store para un ecosistema y un framework de provisión de servicios

El trabajo realizado se encuentra enmarcado dentro del proyecto de I+D+I del 7o programa marco de la Comisión Europea Fi-WARE: The future Internet core platform que forma parte de la iniciativa Future Internet PPP. En concreto, se ha desarrollado la especificación de un Generic Enabler con funcionalidad de tienda virtual que de soporte a la publicación y adquisición o subscripción de aplicaciones y servicios dentro del denominado Business Framework Ecosystem (BFE), además de una implementación de referencia de este Generic Enabler (GE) que ha sido utilizada para la realización de una prueba de concepto con el objetivo de comprobar la adecuación del comportamiento de la especificación dentro del BFE. La primera tarea realizada ha consistido en un estudio de otras stores (o tiendas digitales) existentes, mirando aspectos tales como la funcionalidad proporcionada, la información mostrada de los distintos productos ofrecidos o la organización de la interfaz de usuario y la metáfora visual. Este estudio ha tenido como objetivo establecer un punto de partida desde el que empezar a analizar las distintas funcionalidades que deberá proveer el sistema.Utilizando como base el estudio anterior y las necesidades concretas de la plataforma Fi-WARE se paso a la educación de los requisitos generales del sistema en los cuales se especifica a grandes rasgos la funcionalidad que debe proveer esta tienda digital así como algunos aspectos concretos de la experiencia de usuario. Una vez definida la funcionalidad de la store se ha abordado el diseño del sistema. Para realizar este diseño se ha trabajado en dos tareas principales: La primera de estas tareas ha consistido en realizar el diseño de la arquitectura del Store GE, en el que se especifican todos los módulos que debe contener el sistema para poder satisfacer los requisitos, así como las distintas conexiones del Store GE con otros componentes del proyecto Fi-Ware y de sus interrelaciones con el resto de componentes de dicho proyecto. Esto ofrece una visión global de la ubicación del Store GE dentro de la arquitectura general del proyecto Fi-Ware. La segunda tarea ha consistido en el desarrollo de la especicación abierta (Open specication) del Store GE. Esta tarea es probablemente la más relevante de cara a cumplir con los objetivos del proyecto Fi-Ware, ya que Fi-Ware se propone como objetivo principal proporcionar las especificaciones de una plataforma tecnológica abierta para la Internet del futuro, formada por un conjunto de componentes (denominados Generic Enablers), entre los que se encuentra el Store GE. En este documento ha quedado descrito con todo detalle en que consiste el Store GE y cuales son sus APIs, sobre las que se construirán las aplicaciones de la futura Internet basadas en Fi-Ware, de manera que sea posible que cualquier empresa pueda realizar una implementación diferente a la que se está desarrollando en este proyecto (si bien ésta será su implementación de referencia). Para esta Open specication se han desarrollado un modelo de gestión de usuarios y roles, un modelo de datos, diagramas de interacción que definen todas las posibles comunicaciones de la store con otros Generic Enablers del proyecto Fi-Ware, la definición del ciclo de vida de una oferta y las APIs REST del Store GE, incluyendo el contenido de las peticiones y los tipos MIME soportados. En este punto se pudo comenzar a trabajar en la implementación de referencia del Store GE. La primera tarea ha consistido en realizar la integración con el Marketplace GE, otro de los Generic Enablers del proyecto Fi-Ware, para ello se definieron unos requisitos específicos y se realizó un diseño de bajo nivel de este móodulo seguido de la propia implementación y un conjunto exhaustivo de pruebas unitarias para comprobar su correcto funcionamiento. A continuación se pasó a realizar la integracióon con el Repository GE siguiendo los mismos pasos que con la integración con el Marketplace GE. La siguiente tarea realizada ha consistido en la realización de los móodulos necesarios para permitir crear nuevas ofertas en la implementación de referencia de Store GE incluyendo nuevamente una fase de educación de requisitos específicos, un diseño de bajo nivel, la propia implementación y una serie de pruebas unitarias. Una vez implementada la creación de nuevas ofertas, se pasó a la realización de la funcionalidad necesaria para la recuperación y visualizacion de estas ofertas así como a la realización del soporte necesario para el registro de recursos y para la vinculación de estos a determinadas ofertas, siguiendo nuevamente la metodología antes mencionada. Finalmente se ha dado el soporte para la publicación y la adquisición de ofertas. En este caso la adquisición de ofertas se ha realizado tan solo en la parte servidora de la aplicación y no se ha llegado a dar soporte a esta funcionalidad en la interfaz Web al no ser necesaria para la realización de la prueba de concepto prevista. No obstante esta funcionalidad será implementada junto con otras funcionalidades como el soporte de características sociales, ya fuera del ámbito de este Trabajo de fin de grado. Como paso previo a la realización de la prueba de concepto se ha trabajado en la plataforma Wirecloud, que es una implementación de referencia del denominado Application Mashup GE, modicando su funcionalidad para integrarla con la API de compras realizada dentro de la implementación de referencia del Store GE. La úultima tarea realizada para este Trabajo de fin de grado ha consistido por fin en la realización de la prueba de concepto del Store GE integrando su implementación de referencia con las del resto de Generic Enablers, lo cual ha permitido comprobar así el fucionamiento de la arquitectura y modelo propuestos.

Desarrollo sistemático de elementos composicionales para Mashup de aplicaciones

Este Trabajo fin de grado ha tomado como punto de partida el escenario y los casos de uso que han sido seleccionados para el demostrador ("live demo") del proyecto europeo de I+D+I FI-WARE para, a través del diseño y de la implementación del conjunto de widgets y operadores que forman parte de dicho demostrador, deducir los principios subyacentes al Desarrollo sistemático de los elementos composicionales que conforman un mashup de aplicaciones Web 2.0. En concreto, con el escenario escogido se quiere demostrar, en un contexto de Smart Cities, como puede monitorizarse el estado y la geolocalización de un conjunto de máquinas de vending y de los técnicos y reponedores que les dan soporte. Este trabajo fin de grado se ocupa, en concreto, de crear todos los componentes de interfaz necesarios para poder ofrecer un mashup de aplicación que ofrezca un cuadro de mando personalizable para llevar a cabo la monitorización y el control de máquinas de vending, técnicos y reponedores. Teniendo en cuenta el documento de casos de uso para ese escenario, se hizo una revisión de los diferentes widgets y operadores que había que diseñar y desarrollar. El conjunto inicial de widgets se mantuvo invariable, ya que las vistas que hay que mostrar deben ser las que se especifican en el documento anteriormente citado. No obstante, los operadores necesarios para el mashup han ido cambiando a lo largo del desarrollo como consecuencia de las necesidades de los tipos de datos tratados y de las características propias de la plataforma utilizada. El diseño del mashup se ha dividido en dos tipos de diseños distintos: Diseño de vistas: Es un disño de alto nivel donde se pueden observar las distintas vistas que vería el usuario en cada uno de los widgets (los operadores no tienen vista). Diseño de interacciones: Es un diseño de alto nivel donde se representa esquemáticamente el ujo de datos entre los elementos composicionales del mashup (tanto widgets como operadores). Al mismo tiempo que se planteaba el diseño del mashup, y como consecuencia de la experiencia ganada, se han podido ir realizando trabajos como la creación de la "Guía de desarrollo de widgets y operadores" y la "Guía de estilo para el desarrollo de widgets y operadores".Estos documentos, por su importancia, dan pie al título del presente trabajo ya que suponen una ayuda metodológica al desarrollo sistemático de elementos composicionales para mashup de aplicaciones. Durante ese periódo, simultaneamente, se pudieron encontrar y consultar diferentes fuentes de información que completan el "Estado del arte" y el documento de "Principios de diseño de aplicaciones composicionales orientadas a mashups" y se realizaron varias herramientas que facilitan la tarea del programador de crear un nuevo widget u operador desde cero. Entre estas últimas, destacan: una herramienta para crear y mantener la estructura de directorios y archivos de un widget y de un operador; y una herramienta que empaqueta todos los ficheros del widget u operador en un solo fichero WGT, dejándolo preparado para ser desplegado en la plataforma. La mayor parte del trabajo ha consistido en la implementación de los widgets y operadores. Los widgets implementados son los siguientes: Map Viewer. Issues List. Technicians List. Technicians Info. Los operadores implementados son los siguientes: Poi2Issue Issue2Poi Poi2vCard Vcard2Poi TechnicianSource IssuesSource También se han realizado tres tipos de tests: unitarios, de integracion y de sistema. Además se ha creado documentación de cada elemento composicional para el usuario. En dicha documentación se explica cuales son las funcionalidades de cada uno de los elementos composicionales y cuales son las capacidades de conexión con otros elementos. El resultado de mi trabajo puede observarse en: http://www.youtube.com/watch?v=r8 Vv ehJSw