EDITOR DE FLUJOS DE PROCESOS DE MEDIAS MEDIA PROCESSES FLOW EDITION Heidys Dueñas Pérez, Miguel Morciego Varona 1 Universidad de las Ciencias Informáticas, Cuba, [email protected], Universidad de las Ciencias Informáticas. Carretera a San Antonio de los Baños, Km. 2 ½. Torrens, municipio de La Lisa. La Habana, Cuba. CP.: 19370 2 Universidad de las Ciencias Informáticas, Cuba, [email protected]

RESUMEN: Un editor visual es parte de los sistemas de flujo de trabajo y tiene como objetivo la modelación de diagramas de flujo de procesos. La presente investigación contiene el proceso de desarrollo realizado para la obtención del módulo Editor de Flujo de Procesos de Medias que garantice con una arquitectura orientada a componentes, la incorporación de procesos y operaciones sobre ellos, posibilitando la edición de flujos de procesos de medias. El módulo forma parte del Sistema Gestor de Procesos de Medias que gestiona los procesos de medias llevados a cabo en el departamento Señales Digitales. Con el fin de obtener mejores resultados en la investigación el módulo se desarrolla bajo la metodología Proceso Unificado de Desarrollo y se utiliza para su implementación el lenguaje de programación C++ y el marco de trabajo para el desarrollo Qt 4.8. El resultado obtenido es el Editor de Flujo de Procesos de Medias desarrollado con una arquitectura orientada a componentes, con la incorporación de las operaciones ciclo, condicional y condicional múltiple. La importancia de la investigación radica en aumentar las oportunidades de negocio donde se requiera la presencia de las nuevas operaciones y que no resulte necesario modificar el código fuente del módulo para la inclusión de las mismas. Palabras Clave: Arquitectura, editor, flexible, operaciones, procesos.

ABSTRACT: A visual editor is part of workflow system and its objective is modeling processes flow diagrams. This research has made the development process for obtaining Media Processes Flow Edition guaranteeing a component oriented architecture, incorporating processes and operations on them, enabling the editing process flows stockings. The module is part of Media Processes Management System which manages the media processes carried out at Digital Signals department. In order to obtain better results in the research the module is developed under the Rational Unified Process methodology and is used for the implementation the programming language C++ and the framework for developing Qt4.8. The result obtained is a Media Processes Flow Edition developed with a component oriented architecture, incorporating the operations cycle, conditional and multiple conditional. The importance of research is to increase the business opportunities where the presence of new operations is required and is not necessary to modify the source code module for including these operations.

KeyWords: Architecture, editor, flexible, operations, processes.

1. INTRODUCCIÓN

Como consecuencia del avance de la ciencia y la tecnología se hace necesario que la mayoría de las “III Conferencia Internacional en Ciencias Computacionales e Informáticas”

Dueñas, Heidys.; Morciego, Miguel. | “EDITOR DE FLUJOS DE PROCESOS DE MEDIAS”

empresas precisen automatizar los procesos que realizan para lograr una mejor integración entre los mismos. Para llevar a cabo dicha automatización y facilitar la estructuración y orden de ejecución de las tareas a desarrollar aparece el flujo de trabajo (del inglés workflow). Con la aparición de los sistemas workflow se logra una automatización integral del entorno de los procesos donde serán coordinados sus elementos relacionados como son: actividades, recursos, usuarios y reglas de actuación [1]. Los sistemas workflow cuentan con un editor visual que tiene como principal objetivo modelar el diagrama de flujo de procesos. En este modelado son representados los procesos del flujo, el orden que poseen y las relaciones que se establecen entre ellos, además permite diseñarlos y modificarlos de manera visual. Los editores necesitan de estándares para la notación y descripción de los flujos de procesos entre los que se encuentra el Lenguaje de Ejecución de Procesos de Negocio (por sus siglas en inglés BPEL1), que consiste en un estándar diseñado para la orquestación de servicios web, y permite definir cuándo y cómo se ejecutará un determinado proceso [2]. El estándar permite a las empresas adaptarse a los cambios rápidamente y reducir la complejidad de sus procesos, además de alcanzar los objetivos del negocio con mayor flexibilidad y escalabilidad [2]. En el departamento Señales Digitales de la Universidad de las Ciencias Informáticas (UCI) existen diferentes proyectos encaminados al trabajo con procesos de medias. El proyecto Sistema Gestor de Procesos de Medias se encarga de gestionar y planificar estos procesos entre los que se encuentran: codificación de audio, codificación de video, extracción de fotogramas, por mencionar algunos. Esta gestión y planificación se realiza mediante el Gestor de Procesos de Medias. No obstante, la forma de definir estructuralmente el orden lógico de los procesos y las operaciones que los relacionan, es introducida al Gestor a través de un fichero XML que se crea manualmente. La elaboración de este fichero si el flujo de procesos es grande o complicado es prácticamente imposible, de lograrse se necesitaría de un experto y de mucho tiempo, aun así no se invalida la posibilidad de que el archivo contenga errores. Ante la problemática existente se decide centrar la investigación en desarrollar un módulo de edición de flujos de procesos de medias que garantice con una arquitectura orientada a componentes, la incorporación de nuevos procesos y operaciones que posibiliten la edición de flujos de procesos de medias, lo cual constituye el objetivo general. El estudio de la solución se realiza haciendo énfasis en la edición de flujos de procesos de medias. Para llevar

1

a cabo la investigación el equipo de trabajo desarrolla un módulo de edición de flujos de procesos basado en el estándar BPEL para que pueda ser interpretado por el Gestor. En el mundo existen herramientas informáticas que entre sus funcionalidades se halla la edición de flujos de procesos. Las soluciones informáticas que realizan dicha edición referente a archivos de medias son reducidas y casi todas privativas. En el caso de las soluciones privativas se encuentran MPM Flow-Builder/Editor y Vantage. Sin embargo, también existen soluciones que no son privativas como es el caso de Slate pues con el auge de la tecnología libre se hizo necesario contar con herramientas que llevaran a cabo la edición de flujo de procesos. MPM Flow-Builder/Editor es un módulo que genera los flujos de medias y metadatos sin el empleo de cintas magnéticas. La herramienta incluye métodos de planificación para los flujos y el pre procesado de los mismos. La forma de planificar el comportamiento de los procesos es mediante operaciones que pueden ser condicionales, secuenciales o en paralelo, además permite crear nuevos flujos de procesos a partir de otros ya realizados y efectuar optimizaciones en los mismos. Vantage es un producto de Telestream y cuenta con una amplia variedad de formatos de archivos de entrada y es una solución altamente concentrada que acelera la transcodificación y embalaje para la entrega multipantalla. Brinda una gama de procesos que facilitan el trabajo con los archivos de medias en el flujo haciéndolo de forma agradable y sencilla. Estos flujos deben ser activados para que queden listos y se puedan mandar a ejecutar las tareas. En el caso de Slate pertenece a QVision que es una biblioteca libre y de código abierto con la cual se realiza procesamiento de imágenes y video, además de aplicaciones de cálculo científico [3]. Dicha herramienta permite al usuario analizar y modificar la estructura de la ruta de los datos mientras la aplicación se encuentra en ejecución. Con esta herramienta el usuario puede añadir o eliminar los nodos y enlaces entre los mismos, esta facilidad que se le brinda al usuario servirá de guía para la propuesta de solución. Sin embargo, esta herramienta crea el flujo de procesos automáticamente a diferencia de la forma en la que se realiza en el proyecto donde quien lo crea es el usuario, además de que no permite crear relaciones condicionales entre los procesos. De manera general el análisis de estas tres soluciones arroja como resultado que la utilización de ellas no resuelve la problemática planteada pues no exportan el flujo de procesos de medias a un archivo XML bajo una codificación entendible por el Sistema Gestor de Procesos de Medias. Otro aspecto negativo es que los procesos que manejan son diferentes a los del proyecto Sistema Gestor de Procesos

BPEL: Business Process Execution Language “III Conferencia Internacional en Ciencias Computacionales e Informáticas”

Dueñas, Heidys.; Morciego, Miguel. | “EDITOR DE FLUJOS DE PROCESOS DE MEDIAS”

de Medias, detalle importante a tener en cuenta. Otro aspecto a señalar es que en el caso de las dos primeras soluciones por ser privativas implicarían una inversión adicional para el proyecto. Aun cuando no son escogidas ninguna de las herramientas antes expuestas se seleccionan de ellas ideas que tributan a la confección del módulo.

2. CONTENIDO XPDL XPDL es un estándar muy utilizado actualmente que tiene por objetivo el archivo de los diagramas de procesos y el intercambio o portabilidad de estos entre distintas herramientas que trabajen en el entorno de ejecución [4]. Es un formato de archivo XML que almacena la configuración del flujo de procesos creado. Contiene el tamaño del nodo y sus coordenadas, además de tener un concepto de líneas que señalan el camino a seguir. En el fichero son guardados un conjunto de atributos los cuales son: identificador, nombre, tipo de proceso, valores de las propiedades de entrada de cada proceso y propiedades gráficas del flujo. La función de estas propiedades gráficas es permitir que después de salvada la configuración esta pueda ser cargada por la aplicación en cualquier otro momento [4]. XPDL se usa de forma parcial y a la vez contiene modificaciones que se ajustan a las necesidades de la solución. BPEL BPEL es un estándar basado en el Lenguaje de Marcas Extensible (por sus siglas en inglés XML2) diseñado para la orquestación de servicios web [2]. Surge como un estándar para que las empresas puedan optimizar sus procesos añadiendo variedad de aplicaciones independientemente de las tecnologías asociadas a cada actividad y puedan cumplir con sus objetivos de negocios. Combina los mejores puntos del Lenguaje de Flujo de Sevicios Web (por sus siglas en inglés WSFL3) y del XLANG, ambos lenguajes XML de procesamiento de negocios. Brinda mayor flexibilidad y escalabilidad en cuanto a los cambios y el dinamismo propio de los negocios actuales [2]. Se utiliza para crear en un fichero XML el flujo de procesos. En el fichero se almacenan las secuencias de ejecución de los procesos y atributos donde a diferencia de XPDL no se guardan las propiedades gráficas del flujo pues no son relevantes a la hora de orquestar los procesos. El lenguaje BPEL presenta mecanismos que permiten el procesamiento paralelo, manejo de excepciones e interacciones sincrónicas y asincrónicas. Uno de los beneficios de utilizar este estándar es que permite inte2 3

XML: Extensible Markup Language WSFL: Web Services Flow Language

grar un conjunto de servicios heterogéneos para llevar a cabo la implementación de los procesos de negocio. Para utilizar este estándar se realizan modificaciones que permiten adaptarlo a las necesidades de la solución. Arquitectura orientada a componentes La arquitectura orientada a componentes está enfocada a descomponer el diseño del software en componentes funcionales o lógicos que presenten interfaces de comunicación que se encuentren bien definidas. La definición de la arquitectura orientada a componentes cubre solamente aspectos lógicos y es independiente de la tecnología que se va a emplear para implementar los componentes. El aspecto lógico permite razonar respecto a las consecuencias de reemplazar o modificar un componente, además mide el nivel de acoplamiento del sistema. La independencia tecnológica brinda la posibilidad de elegir la tecnología más adecuada para el desarrollo del sistema. Esta arquitectura se encuentra encaminada a la reutilización de código a través de un diseño centrado en interfaces y componentes [5]. La arquitectura orientada a componentes se estructura a partir de tres aspectos esenciales:  Nombre de los componentes: Debe identificar la funcionalidad y el uso que presenta como software. La mayoría de las veces es usado algún tipo de convención que facilite la identificación del componente, fundamentalmente cuando se trabaja en grandes proyectos.  Interface de los componentes: Representa el área de intercambio entre el exterior e interior de un componente. Permite acceder a funcionalidades y datos que son especificados en el interior del componente (acceder funcionalmente, no a su especificación). Además de la interface existe documentación que presenta información respecto a cómo usar el componente.  Cuerpo y código de implementación: Parte del componente que proporciona la forma en que el componente puede realizar sus servicios y funcionalidades. Esta área debe cumplir el principio de encapsulación.

2.1 Materiales y Métodos Para el desarrollo de la investigación se emplea la metodología de desarrollo RUP pues está basada en casos de uso lo que ayuda a que la implementación de las funcionalidades del sistema se realice de manera más sencilla. Como framework de desarrollo se utiliza Qt pues presenta un conjunto de módulos como QtCore para el trabajo con los objetos no visuales, QtGui para los objetos visuales y QtXML para el manejo de ficheros XML, facilitando la implementación de la solución. El lenguaje de programación empleado es C++ ya que además de

“III Conferencia Internacional en Ciencias Computacionales e Informáticas”

Dueñas, Heidys.; Morciego, Miguel. | “EDITOR DE FLUJOS DE PROCESOS DE MEDIAS”

que permite el trabajo con la programación orientada a objetos el hecho de ser compilado y no interpretado lo convierte en un lenguaje rápido. El entorno integrado de desarrollo que se emplea es QtCreator el cual posee varias herramientas como: QtAssistant, QtDesigner, entre otras lo cual lo hacen más viable para la implementación y desarrollo de la solución. La herramienta CASE para el modelado es Visual Paradigm para UML quien soporta todo el ciclo de vida del desarrollo del software, además de ahorrar tiempo considerablemente y de posibilitar una alta calidad en el proceso. Patrón arquitectónico Para la realización del Editor de Flujo de Procesos de Medias se utiliza el patrón arquitectónico En capas, específicamente en tres capas: Presentación, Lógica y Acceso a Datos. La capa de presentación es la responsable de la presentación visual de la aplicación, comunica información al usuario y recolecta la que es suministrada por el mismo. La capa lógica se encarga del procesamiento que tiene lugar en la aplicación y la de acceso a datos es la que se encarga de garantizar la persistencia de los mismos. Se escoge el patrón debido a que distribuye por capas el trabajo donde cada una provee de servicios a las otras. La arquitectura en tres capas permite hacer más sencillo el desarrollo de las aplicaciones para luego brindarle un mejor mantenimiento. Este patrón permite organizar el sistema en diferentes conjuntos de abstracción, lo cual garantiza entre varios aspectos proporcionar amplia reutilización y admitir refinamientos y optimizaciones.

2.2 Resultados y Discusiones Para el desarrollo del módulo se propone una arquitectura orientada a componentes que permita que cada actividad (proceso u operación) se cargue dinámicamente de un plugin y se incorpore al sistema en tiempo de ejecución. Estas actividades proporcionan al sistema su estructura correspondiente para que este la agregue al flujo resultante. De esta manera se logra que el sistema no tenga conocimiento de los datos específicos de cada actividad. Ambos aportes contribuyen a la flexibilidad del sistema ya que si se necesitara aumentar el número de actividades no habría que modificar el código fuente del sistema ni se requeriría de la presencia de un experto o de tiempo para comprender la aplicación, simplemente desarrollar un plugin que sea entendible por la aplicación. Se utilizan los estándares BPEL y XPDL para la confección del fichero XML que tiene por objetivo ser interpretado por el Gestor para ejecutar procesos. Las operaciones agregadas al Editor de Flujo de Procesos de Medias son ciclo, condicional y condicional múltiple pues estas son las más usadas al editar un flujo de procesos. En la Figura 1 se representa un flujo de procesos

con una operación. Este flujo inicia con el proceso “Codificar_Audio” y seguidamente la operación “Ciclo” que se encarga de ejecutar n veces el proceso “Extraer Fotogramas”, luego de terminado este ciclo se ejecuta una vez el proceso “Fragmentar_Media”.

Figura. 1: Flujo de procesos de medias

Otro resultado es que permite exportar el flujo de procesos creado a una imagen con formato .bmp, .jpg y .png. Esto hace más comprensible el propósito del flujo que se describe pues resulta muy difícil interpretar el fichero exportado ya que se encuentra en un lenguaje no comprensible para todo tipo de usuario. Se agrega además, la posibilidad de ir a estados anteriores y siguientes, lo cual contribuye a la usabilidad del sistema pues en caso de que el usuario cometiera un error al editar el flujo esto le permite deshacer el error y no tener que definir el flujo de procesos desde el comienzo. Finalmente integrando los elementos anteriores se obtiene un módulo capaz de elaborar un flujo sin limitaciones de complejidad ni errores, de procesos y operaciones entre ellos, entendible por el Sistema Gestor de Procesos de Media.

2.3 Validación de la solución Para verificar que las funcionalidades del sistema cumplan con sus objetivos satisfactoriamente se realizan pruebas de caja negra a los casos de uso y se utiliza para ello la técnica de caja negra partición equivalente. Esta técnica consiste en dividir el campo de entrada de un programa en clases de datos de los que se derivan los casos de prueba. Permite definir casos de prueba que se basan en una evaluación de las clases de equivalencia para una condición de entrada, estas clases de equivalencia representan un conjunto de estados válidos o no válidos para condiciones de entrada [6]. Tabla I: Resultados de las pruebas de caja negra. Iteraciones Iteración 1 Iteración 2

No conformidades 3 no conformidades 0 no conformidades

A partir de realizar las pruebas de caja negra a los

“III Conferencia Internacional en Ciencias Computacionales e Informáticas”

Dueñas, Heidys.; Morciego, Miguel. | “EDITOR DE FLUJOS DE PROCESOS DE MEDIAS”

casos de uso del sistema se detectan tres no conformidades en los requisitos: RF9: Modificar propiedades de operación condicional múltiple, RF15: Exportar flujo de procesos de medias a imagen y RF16: Exportar flujo de procesos de medias a archivo XML. La no conformidad referente al RF9 consiste en que al disminuir la cantidad de salidas de la condicional múltiple se pierden las relaciones establecidas con los procesos. En el caso de las no conformidades referentes al RF15 y RF16 radica en que si el sistema operativo es GNU/Linux no se exporta el flujo de procesos de medias a una imagen ni a un archivo XML. Se realiza una segunda iteración de pruebas para verificar la eliminación de los problemas antes mencionados y para encontrar nuevas no conformidades que puedan surgir en el funcionamiento del sistema. Esta segunda iteración concluye satisfactoriamente pues se comprueba el correcto funcionamiento del Editor de Flujo de Procesos de Medias. Otro de los resultados que se obtiene con estas pruebas es la demostración de la flexibilidad del sistema con los casos de prueba pues se valida la capacidad del módulo de asimilar nuevos procesos y operaciones con características diferentes a través de plugins, sin la necesidad realizar cambios en el código fuente del sistema para agregar dichas actividades (procesos u operaciones).

3. CONCLUSIONES Al concluir la presente investigación se obtienen resultados que dan cumplimiento satisfactorio al objetivo general planteado inicialmente. A partir de estos resultados se arriba a las siguientes conclusiones:  El estudio del estándar BPEL permite implementar operaciones de forma tal que la información que brindan al módulo se encuentre correctamente estructurada para que el fichero XML a exportar no contenga errores.  Con la realización del módulo se logra proveer al Sistema Gestor de Procesos de Medias de una herramienta capaz de generar flujos de procesos de medias que incluyan operaciones.  Las operaciones desarrolladas al módulo amplían las oportunidades de negocio donde se requiera la presencia de las mismas.





La arquitectura orientada a componentes posibilita el desarrollo de un módulo flexible, lo que se percibe en la posibilidad de incorporar plugins que agregan nuevas actividades (procesos u operaciones) sin realizar modificaciones al sistema, además de incrementar las capacidades del mismo. Las pruebas realizadas al módulo demuestran el correcto funcionamiento de las especificaciones trazadas.

4. REFERENCIAS BIBLIOGRÁFICAS 1. Lorca, Jesús González: Sistemas workflow: Funcionamiento y metodología de implantación. sl.: Ediciones Trea, 2006. 8497042190. 2. Cientec. 2013. Cientec. Cientec. [En línea] 2013. [Citado el: 10 de 11 de 2013.] http://www.cientec.com/management/managementbpel.html. 3. QVision. 2010. QVision. QVision. [En línea] 2010. [Citado el: 20 de 11 de 2013.] http://qvision.sourceforge.net/TheDesignerGUI.html. 4. BPM, Club. 2011. El libro del BPM 2011. Tecnologías, Conceptos, Enfoques Metodológicos y Estándares. Madrid: Club BPM, 2011. 9788461483679. 5. Sommerville, Ian. 2005. Ingeniería del Software. Séptima edición. 2005. 8478290745. 6. Pressman, Roger S. 2005. Ingeniería del Software. Un enfoque práctico. sl.: Interamericana Editores, 2005. 9701054733.

5. SÍNTESIS CURRICULARES DE LOS AUTORES Heidys Dueñas Pérez: Nacida el 22 de febrero de 1991 en Cárdenas, Matanzas. Es graduada en Ingeniería en Ciencias Informáticas desde el 2014 en la Universidad de las Ciencias Informáticas. Trabaja en el centro GEYSED de la facultad 6 de la Universidad de las Ciencias Informáticas, donde se desempeña como Especialista en Vigilancia Tecnológica y Desarrollo Humano. Dirección electrónica [email protected]. Miguel Morciego Varona: Nacido el 16 de noviembre de 1990 en Camagüey. Es graduado en Ingeniería en Ciencias Informáticas desde el 2014 en la Universidad de las Ciencias Informáticas. Trabaja en el centro GEYSED de la facultad 6 de la Universidad de las Ciencias Informáticas, donde se desempeña como Líder del proyecto AGORAV. Dirección electrónica [email protected]

“III Conferencia Internacional en Ciencias Computacionales e Informáticas”