Uso de modelos basados en arquitectura de software para el desarrollo de herramientas de composición más usables

(1)

U

NIVERSIDAD

V

ERACRUZANA

F

ACULTAD DE

E

STADÍSTICA E

I

NFORMÁTICA

Uso de Modelos basados en Arquitectura

de Software para el Desarrollo de

Herramientas de Composición mas

Usables

TESIS

QUE PARA OBTENER EL TÍTULO DE: MAESTRA EN SISTEMAS INTERACTIVOS

CENTRADOS EN EL USUARIO

PRESENTA:

YADIRA JARVIO HERNÁNDEZ

DIRECTORA DE TESIS

DRA. PERLA VELASCO ELIZONDO

CO-DIRECTOR DE TESIS

DR. EDGARD IVÁN BÉNITEZ GUERRERO

(2)

(3)

(4)

(5)

(6)

(7)

Resumen

Cada vez más personas realizan diversas tareas apoyándose de sistemas de software que son construidos a partir de la composición de componentes. A pesar de la popularidad del desarrollo centrado en composición y las herramientas existentes para soportarlo, existen problemas generales relacionados al proceso de composición que las hacen poco usables para los usuarios nales. En este trabajo se realizó una evaluación detallada para encontrar dichos problemas.

Estos problemas proveen una base de conocimiento que puede ser extendida en domi-nios especícos de aplicación para proponer la implementación de una herramienta de composición más usable para los usuarios nales.

Para implementar dicha herramienta se propone diseñar un proceso para la composición de componentes usando modelos basados en conceptos de arquitectura lo cual permite disminuir los problemas de usabilidad encontrados en las herramientas de composición actuales.

(8)

Abstract

Today most people perform dierent tasks using software systems which are constructed from the components composition. Despite the popularity of the development centered-composition and the tools to bear it, exist general problems related to the process of composition which make it few usable for end users. This paper has a detailed assessment conducted for nd these problems.

These problems provide a knowledge base that can be extended in specic application domains to propose the implementation of a usable composition tool for end users.

To implement such a tool is proposed to design a process for the components composition which use models based on architecture concepts to reduce the usability problems located in current composition tools.

(9)

Agradecimientos

Me gustaría que estas líneas sirvieran para expresar mi más profundo y sincero agradeci-miento a todas aquellas personas que con su ayuda han colaborado en la realización del presente trabajo.

A mi madre por ser un ejemplo de perseverancia y sobre todo por brindarme siempre su apoyo incondicional, a mi padre por creer en mí, a mis hermanos y a toda mi familia por todos sus buenos deseos.

A la Dra. Perla a quien quiero expresar mi más profundo agradecimiento, por hacer posible la realización de este trabajo. Además, quiero agradecer la paciencia, el tiempo y la dedicación que tuvo para que esto saliera de manera exitosa.

Al Dr. Edgard por su excelente codirección en este trabajo.

A mis Sinodales por sus excelentes comentarios ya que permitieron mejorar mi documento de tesis.

A la Maestría en Sistemas Interactivos Centrados en el Usuario (MSICU) por todo el apoyo brindado.

A todas esas personas que estoy olvidando mencionar pero que apoyaron directa o indi-rectamente el desarrollo de este trabajo.

Este trabajo fue nanciado por el Consejo de Ciencia y Tecnología (CONACYT). Por todo el apoyo económico para el desarrollo de esta investigación, se extiende el más sincero agradecimiento al CONACYT (No. de becario: 297377).

(10)

Índice general

Resumen vi

Abstract vii

Agradecimientos viii

Contenido ix

Lista de Figuras xi

Lista de Tablas xii

1. Introducción 1

1.1. Antecedentes . . . 1

1.2. Denición del problema . . . 2

1.3. Justicación . . . 6

1.4. Hipótesis . . . 7

1.5. Objetivos . . . 7

1.6. Metodología . . . 8

1.7. Organización del documento . . . 8

2. Evaluación de Herramientas de Composición Actuales 9 2.1. Herramientas seleccionadas . . . 9

2.2. Composición realizada . . . 14

2.3. Método de evaluación . . . 14

2.3.1. Evaluación heurística. . . 16

2.3.2. Heurísticas para la evaluación del funcionamiento . . . 16

2.3.3. Heurísticas para la evaluación de la usabilidad. . . 17

2.4. Participantes en la evaluación . . . 21

2.5. Resultados obtenidos . . . 21

2.5.1. Resultados de la evaluación funcional. . . 21

2.5.2. Resultados de la evaluación de usabilidad . . . 22

2.6. Reexiones nales . . . 26

3. Solución Propuesta 28 3.1. Especicación de las tareas . . . 31

3.2. Especicación de los modelos formales . . . 32

3.2.1. Arquitectura de software. . . 33

3.2.2. Estilos arquitectónicos . . . 33

(11)

Contenido x

3.2.3. Especicación formal de arquitectura de software . . . 35

3.3. Generación iterativa e incremental de la composición . . . 38

3.3.1. Generación de la composición utilizando planicación. . . 38

3.3.2. Evaluación de la composición utilizando teoría de utilidades . . . . 39

3.4. Resumen. . . 42

4. Implementación de la Solución 43 4.1. Caso de estudio . . . 43

4.2. Especicación de las tareas . . . 46

4.3. Especicación de los modelos formales . . . 46

4.3.1. Especicación del modelo formal general . . . 47

4.3.2. Especicación del modelo formal de dominio especíco . . . 51

4.4. Generación iterativa e incremental de una composición . . . 53

4.4.1. Generación de la composición . . . 53

4.4.2. Evaluación de la composición, con respecto a expectativas de calidad 56 4.5. Demostración de la herramienta . . . 57

4.5.1. Primera iteración . . . 58

4.5.2. Segunda iteración. . . 59

4.5.3. Última iteración . . . 61

4.6. Resumen. . . 62

5. Evaluación y Resultados Obtenidos 64 5.1. Resultados obtenidos de la evaluación heurística . . . 64

5.2. Resultados obtenidos de los cuestionarios. . . 68

5.3. Resumen. . . 70

6. Conclusiones y Trabajo Futuro 71 6.1. Resumen y conclusiones . . . 71

6.2. Trabajo futuro . . . 73

6.2.1. Automatización de la especicación del modelo formal de dominio especíco . . . 73

6.2.2. Aplicación de la solución en otros dominios de aplicación y con usuarios nales . . . 74

6.2.3. Mejoras a la herramienta desarrollada . . . 74

A. Especicación de Artefactos Utilizados en la Herramienta Propuesta 75 A.1. Especicación de tareas - Caso de estudio . . . 75

A.2. Especicación del modelo formal general . . . 83

(12)

Índice de guras

1.1. Construcción de un mashup en Yahoo Pipes!. . . 4

1.2. Otra representación de mashup en Yahoo Pipes! . . . 4

2.1. Gráca mostrando el promedio (R) de la evaluación heurística de usabilidad. 25 3.1. Estructura y funcionamiento de la herramienta para la generación iterativa e incremental de una composición. . . 30

3.2. Plantilla para la especicación de las tareas que pueden utilizarse en una composición. . . 32

3.3. Especicación de la Tarea Traducir comentarios. . . 32

3.4. Estilo data-ow . . . 35

3.5. Componentes candidatos en una composición . . . 41

4.1. Especicación de la Tarea Buscar comentarios. . . 46

4.2. Especicación de la Tarea Listar comentarios. . . 47

4.3. Resultado de la primera iteración.. . . 59

4.4. Resultado de la segunda iteración. . . 61

4.5. Resultado de la última iteración. . . 63

5.1. Gráca de comparación de resultados obtenidos de las herramientas de composición actuales y la solución propuesta. . . 67

5.2. Cuestionario para evaluar la solución propuesta - I. . . 69

5.3. Cuestionario para evaluar la solución propuesta - II. . . 70

A.1. Especicación de la Tarea Búscar comentarios. . . 76

A.2. Especicación de la Tarea Búscar imágenes. . . 76

A.3. Especicación de la Tarea Búscar mapas. . . 77

A.4. Especicación de la Tarea Traducción. . . 77

A.5. Especicación de la Tarea Eliminar információn textual. . . 78

A.6. Especicación de la Tarea Eliminar imágenes. . . 78

A.7. Especicación de la Tarea Eliminar ubicaciones. . . 79

A.8. Especicación de la Tarea Ordenar információn textual. . . 79

A.9. Especicación de la Tarea Ordenar imágenes. . . 80

A.10.Especicación de la Tarea Ordenar ubicaciones. . . 80

A.11.Especicación de la Tarea Listar információn textual. . . 81

A.12.Especicación de la Tarea Listar imágenes.. . . 81

A.13.Especicación de la Tarea Listar ubicaciones. . . 82

(13)

Índice de tablas

2.1. Herramientas seleccionadas . . . 13

2.2. Componentes utilizados para realizar la composición propuesta . . . 15

2.3. Conjunto de heurísticas y principios seleccionados para la evaluación . . . 18

2.4. Conjunto de sub-heurísticas seleccionadas para la evaluación . . . 20

2.5. Participantes en la evaluación heurística . . . 21

2.6. Resultados obtenidos de la evaluación heurística de funcionalidad - I . . . 22

2.7. Resultados obtenidos de la evaluación heurística de funcionalidad - II . . . 22

2.8. Resultados obtenidos de la evaluación heurística de usabilidad - I . . . 24

2.9. Resultados obtenidos de la evaluación heurística de usabilidad - II. . . 24

3.1. Equivalencias entre Planicación y Composición . . . 39

4.1. Componentes disponibles en el caso de estudio. . . 45

5.1. Resultados obtenidos de la solución propuesta en la evaluación heurística . 66

(14)

Capítulo 1

Introducción

1.1. Antecedentes

En la actualidad cada vez más personas realizan diversas tareas apoyándose en sistemas informáticos. Se puede observar que muchos de estos sistemas son construidos a partir de la composición de elementos de software. En este trabajo se reere a dichos elementos como componentes. En términos generales, un componente es un elemento informático pre-existente que implementa alguna funcionalidad, la cual es expuesta a través de inter-faces bien denidas. Usando mecanismos de composición especícos, estos componentes pueden combinarse para crear sistemas. Ejemplos de componentes en muchos de estos sistemas son los COTS (commercial O-The-Shelf) [1], los Servicios web [2], los Mashlets [3] o las (web) APIs.

Enfoques de desarrollo como el Desarrollo Basado en Componentes (CBD) [4], las Líneas de Productos de Software (SPL) [5], la Arquitectura Orientada a Servicios (SOA) [6] y más recientemente las arquitecturas de microservicios [7] han adquirido popularidad puesto que soportan el desarrollo de sistemas usando un enfoque centrado en la compo-sición. De forma similar, existen diversas herramientas, componentes y repositorios de componentes en dominios especícos que permiten el desarrollo de sistemas bajo este enfoque. Ejemplos de herramientas y repositorios incluyen:

BioCatalogue. Es un repositorio público de servicios web sobre biología [8].

Keio Bioinformatics Web Service (KBWS). Es un repositorio de bioinformática de servicios web populares [9].

(15)

Capítulo 1. Introducción 2

Taverna. Es una herramienta de composición y ejecución de workows 1 _basados en servicios web. Proporciona acceso a una amplia gama de servicios web y bases de datos principalmente de biología [11].

Yahoo Pipes!. Es una herramienta de composición y publicación de aplicaciones web tipo mashups 2_{. Proporciona varios componentes para la creación de dichas} aplicaciones [13].

AutoMap. Es una herramienta de minería de texto, permite extraer varios tipos de datos de documentos no estructurados [14].

API de Twitter. Es un componente de tipo web API el cual incluye métodos que permiten a los desarrolladores acceder a los datos básicos de Twitter, así como interactuar con Twitter Search [15].

API de Facebook. Es un componente de tipo web API que permite añadir contexto social a las aplicaciones mediante la utilización de perles, amigos, páginas, grupos, fotos y datos de eventos de Facebook [15].

API de Google Maps. Es un componente de tipo web API el cual permite la in-corporación de Google Maps en las páginas web de los desarrolladores externos [15].

1.2. Denición del problema

El incremento del uso de sistemas de software para automatizar tareas en diversos do-minios de aplicación, así como la disponibilidad de componentes y herramientas para soportar el desarrollo centrado en composición ha propiciado que nuevas comunidades de usuarios incursionen en el desarrollo de sistemas. Un ejemplo es la comunidad de usuarios nales [16] [17] [18]. En términos generales, este tipo de usuarios y los sistemas que construyen presentan tres características principales:

1. Son expertos en su dominio profesional pero inexpertos en materia de desarrollo de sistemas.

2. Soportan sus tareas diarias mediante sistemas de software que ellos mismos cons-truyen a partir de la composición de componentes de software que son generalmente provistos por terceras partes.

1_{Workow es un sistema hecho del ensamble de tareas de procesamiento de datos cientícos con}

dependencias de datos entre ellas [10].

2_{Mashup es una aplicación web hecha del ensamble de componentes reutilizables de datos, lógica de}

(16)

3. Los sistemas que construyen tienen una arquitectura data-ow. En términos ge-nerales, una arquitectura data-ow se caracteriza por tener un conjunto de com-ponentes que realizan una transformación sucesiva de ujos de datos [19] [20].

Un ejemplo de usuario en esta comunidad podría ser un sociólogo realizando análisis de redes sociales. Este análisis tiene que ver con el uso de la teoría de redes para analizar un conjunto de personas con énfasis en sus relaciones [21]. Existen varios métodos para generar, visualizar y analizar redes de personas así como también componentes de softwa-re que automatizan estas tasoftwa-reas, por ejemplo AutoMap. Muchos de estos componentes, en combinación con otros, son utilizados frecuentemente por sociólogos para construir sistemas que les permiten automatizar diversos análisis.

Otro ejemplo de usuario en esta comunidad podría ser un alumno universitario. Suponga que este alumno desea realizar una presentación de un tema con imágenes disponibles en la web. Existen varios componentes que se pueden encontrar disponibles en la web y se pueden utilizar en algunas herramientas de composición. Entre estas herramientas está Yahoo Pipes!, que permite la construcción de mashups en un ambiente visual de tipo drag-and-drop. En la Figura 1.1 se ilustra cómo se podría generar el mashup relacionado al interés del alumno universitario. Él podrá seleccionar de un repositorio de componentes uno que le permita especicar el tema a buscar, el tipo de imagen y el tipo de ltro que desea utilizar. Posteriormente, unir el resultado que arrojan estos componentes con otro componente que permita buscar dichas imágenes utilizando la API de Google (ver componente en la parte central de la Figura 1.1). Finalmente, el estudiante podría agregar un componente que permita mostrar las imágenes, (ver estos componentes en la parte Diseño de la composición de la Figura1.1)

(17)

Figura 1.1: Construcción de un mashup en Yahoo Pipes!

(18)

Si bien es cierto que la disponibilidad de componentes y herramientas ha promovido el desarrollo de sistemas basados en composición, existen problemas generales (no de dominio especíco) relacionados al proceso de composición que lo hace poco usable para los usuarios nales. A continuación se describen estos problemas:

1. Selección de componentes disponibles. En muchas ocasiones la cantidad de componentes, con el mismo funcionamiento, son tantos que los usuarios deben invertir mucho tiempo para la selección de uno en particular. Los usuarios deberán leer la especicación de cada componente, para determinar cuál es el que mejor satisface la funcionalidad necesaria. Retomando el ejemplo de la Figura 1.1 se puede observar que de lado izquierdo de la herramienta aparece un repositorio con varios componentes agrupados por categorías. En este ejemplo el alumno debe leer y entender el funcionamiento de cada componente disponible para determinar con cuáles puede construir el mashup de su interés. En el Capítulo 2 sección2.3.3, se explica con detalle como este problema está relacionado al principio de anticipación, que es frecuentemente usado para evaluar la usabilidad.

2. Detección de incompatibilidades entre componentes. Debido a que en mu-chos de los casos los componentes son desarrollados por diferentes fabricantes, cada uno de estos podría tener características diferentes a las de los demás. Esto tiene como consecuencia que realizar una composición correcta sea complicado, por problemas relacionados con la incompatibilidad entre componentes. Un usuario po-dría seleccionar un conjunto de componentes, aparentemente compatibles, y darse cuenta durante el diseño o ejecución de la composición que no lo son. Ante esta situación tendrá que seleccionar otro conjunto de componentes. En el ejemplo de la Figura1.1se observa que los componentes se pudieron conectar adecuadamente en tiempo de diseño. Sin embargo en tiempo de ejecución el mashup produjo el error: Unable to create subpipe with pipe id...: Error fetching pipe denition for ... (ver Figura 1.2). Esto debido a un problema de la API de Google. En este caso la he-rramienta de composición no detectó y/o previno que ocurriera este error. En el Capítulo2sección2.3.3, se explica con detalle como el reconocimiento, diagnóstico y recuperación de errores son principios frecuentemente utilizados para evaluar la usabilidad.

(19)

el ejemplo anterior ilustrado en la Figura 1.1, si el alumno necesita que el mashup tenga una disponibilidad de al menos 90 % y se ejecute en al menos 1 segundo, tendrá que analizar cada componente y vericar que el rendimiento y la disponi-bilidad del mashup sean los deseados cuando el mashup se ejecute. Esto debido a que Yahoo Pipes! no cuenta con algún mecanismo para especicar y estimar dichas expectativas de calidad de servicio en tiempo de diseño. Este problema está rela-cionado con principio de anticipación, que es frecuentemente usado para evaluar la usabilidad. En el Capítulo2 sección2.3.3 se proveen los detalles correspondientes.

4. Uso de un lenguaje de bajo nivel de abstracción. Para poder realizar la composición de componentes, el usuario deberá usar un lenguaje de composición especíco. Por lo regular estos lenguajes son técnicos y de bajo nivel de abstracción. Aprender este tipo de lenguajes demanda tiempo y esfuerzo a los usuarios nales. Por ejemplo, en la Figura1.1se puede ver que el nombre de las categorías en las que están clasicados los componentes, incluso los nombres de los componentes y el de los parámetros necesarios para congurarlos no se encuentran en un lenguaje de alto nivel que el usuario pueda entender. Además, con respecto al error presentado en la Figura1.2, Unable to create subpipe with pipe id...: Error fetching pipe denition for ..., generalmente los usuarios nales no logran entender qué signica dicho error debido a que está expresado en lenguaje técnico, por lo cual tendrán que investigar cómo solucionarlo. En el Capítulo 2 sección 2.3.3 se explica que este problema está relacionado con principios como anticipación, reconocimiento antes que recuerdo o relación entre el sistema y el mundo real, que son frecuentemente usados para evaluar la usabilidad.

1.3. Justicación

(20)

1.4. Hipótesis

En la Ingeniería de Software los desarrolladores utilizan técnicas basadas en modelos basados en conceptos de arquitectura para apoyar varias actividades del desarrollo de un sistema, ej., diseño, implementación, pruebas. Si estos modelos están denidos usando una notación formal, muchas de estas actividades se pueden automatizar haciendo uso de técnicas como, por ejemplo, planicación [25], generación de modelos [26] o vericación de modelos [27].

Considerando lo anterior, la hipótesis de este trabajo es:

El uso de modelos formales basados en conceptos de arquitectura facilita el diseño e implementación de herramientas para la composición de componentes más usables para los usuarios nales.

1.5. Objetivos

Con base en lo descrito en las secciones anteriores el objetivo general de este trabajo es:

Diseñar un proceso para la composición de componentes que disminuya los problemas de usabilidad mencionados explícitamente en la sección 1.2 usando modelos basados en conceptos de arquitectura.

Los objetivos especícos son:

1. Identicar y seleccionar los conceptos y las técnicas que permitan diseñar el proceso para la composición de componentes.

2. Implementar una herramienta que automatice dicho proceso.

3. Evaluar las capacidades funcionales de la herramienta implementada.

(21)

1.6. Metodología

La metodología que se siguió para alcanzar los objetivos de este trabajo incluyó las siguientes etapas:

1. Revisión de la literatura y renamiento del problema. Esta etapa se enfocó en el renamiento de los conceptos particulares que permitan resolver el problema. Con el propósito de incorporar nueva información relevante al problema se realizó una revisión de la literatura.

2. Renamiento de la hipótesis del proyecto. En esta etapa se renó la hipótesis inicial planteada en este trabajo, ya que con la recopilación de nueva información fue necesario hacerlo.

3. Generación de la solución al problema. En esta etapa se generó una posible solución al problema planteado, seleccionando un conjunto de conceptos, técnicas y tecnologías.

4. Experimentación y validación. Esta etapa se enfocó en la validación nal de la hipótesis mediante la evaluación de la solución propuesta.

5. Comunicación de resultados. En esta etapa se realizó la escritura del documento de tesis, así como un artículo relacionado al proyecto.

1.7. Organización del documento

(22)

Capítulo 2

Evaluación de Herramientas de

Composición Actuales

En este capítulo, se presentará una evaluación de algunas herramientas representativas para soportar la composición automática de componentes. De esta forma, el propósito de este capítulo es presentar la información que permite apoyar la armación de que la mayoría de las herramientas seleccionadas para este trabajo presentan los problemas de usabilidad mencionados explícitamente en el Capítulo1, sección1.2.

2.1. Herramientas seleccionadas

Para realizar la evaluación se identicaron un conjunto de herramientas que permitie-ran desarrollar sistemas mediante la composición de componentes pre-existentes. Las herramientas permiten composiciones usando una arquitectura data-ow en la forma de worfklows o mashups. Este conjunto de herramientas son las siguientes:

1. Apache ODE. Es una herramienta que permite la creación de workows utilizando servicios web expresados en el lenguaje WS-BPEL [28].

Dominio: Propósito general. Ubicación: http://ode.apache.org/.

2. Apatar. Es una herramienta que permite crear workows integrando datos de varias fuentes [29].

Dominio: Propósito general.

Ubicación: http://www.apatar.com/

(23)

Capítulo 2. Estado del Arte 10

3. BonitaSoft. Es una herramienta que permite la creación de workows integrando componentes como servicios web [30].

Ubicación: http://www.bonitasoft.com/

4. Dapper. Es una herramienta que permite la creación de mashup utilizando APIS [31].

Dominio: Propósito general. Ubicación: No disponible.

5. Enhydra Shark. Es una herramienta que permite desarrollar workows utilizando servicios web [32].

Ubicación: http://www.together.at/prod/workow/tws

6. Google Mashup. Herramienta para la creación de mashups a partir de componentes de tipo API [31].

7. Intel Mash Maker. Es una herramienta que permite crear mashups que integra servicios web que permiten el acceso a información de otros sitios [31].

8. JawFlow. Es una herramienta que permite desarrollar aplicaciones de tipo workow utilizando servicios web [33].

9. JBoss. Es una herramienta que permite la creación de workows a partir de servicios web [34].

Dominio: Propósito general. Ubicación: http://www.jboss.org/

10. JackBe. Es una herramienta que permite la creación de mashups utilizando com-ponentes de tipo API [31].

(24)

11. JOpera. Herramienta de composición de servicios web [35]. Dominio: Propósito general.

Ubicación: http://www.jopera.org/

12. Loni pipeline. Es una herramienta que permite la construcción, validación, ejecución y difusión de workows cientícos a partir de componentes de tipo servicios web [36].

Dominio: Neuroimagen, genómica y bioinformática. Ubicación: http://pipeline.bmap.ucla.edu/

13. Marmite. Es una herramienta que permite construir mashups utilizando servicios web que permiten el acceso a bases de datos e información de páginas web [37]. Dominio: Propósito general.

Ubicación: No disponible.

14. Microsoft Popy. Es una herramienta que permite crear aplicaciones web y mashups utilizando servicios web[31].

15. OpenKapow. Es una herramienta que permite crear mashups utilizando servicios web [38].

Ubicación:http://www.kapowtech.com/

16. Potluck. Es una herramienta que permite la creación de mashups combinando datos de diferentes fuentes [31].

17. QedWiki. Es una herramienta para crear mashups a partir de servicios web [37]. Dominio: Propósito general.

Ubicación: No disponible.

18. RSSBus. Es una herramienta para la creación de mashups extrayendo datos de noticias, publicaciones en blogs, o datos empresariales [39].

(25)

19. RUNA WFE. Es una herramienta que permite la creación de workows utilizando componentes precargados [40].

Dominio: Propósito general. Ubicación: http://wf.runa.ru/

20. Taverna. Es una herramienta de composición y ejecución de workows basados en servicios web [11].

Dominio: Bioinformática.

Ubicación: http://www.taverna.org.uk/

21. WaveMaker. Es una herramienta que permite la creación de aplicaciones web uti-lizando servicios web además de otros componentes [41] [42].

Ubicación: http://www.wavemaker.com/

22. Yahoo Pipes!. Es una herramienta de composición y publicación de aplicaciones basadas en la web. Proporciona varios componentes para la creación de dichas aplicaciones [13].

Ubicación: https://pipes.yahoo.com/pipes/

Una vez identicadas las herramientas se realizó una selección sobre este conjunto. Para la selección se consideraron las características que se describen a continuación. Se considera que estas características son las mínimas deseables que una herramienta debe tener para poder dar soporte en el proceso de composición de componentes a los usuarios nales.

1. Acceso a servicios pre-existentes (SP). Que permitan acceder a componen-tes pre-existencomponen-tes provistos por terceras parcomponen-tes, debido a que los usuarios nales generalmente no desarrollan sus propios componentes, casi siempre utilizan com-ponentes pre-existentes.

2. Soporte Drag and drop (DD). Que provean un ambiente gráco de composi-ción de componentes de tipo drag and drop, ya que los usuarios nales carecen de conocimientos en el área de desarrollo de sistemas y se considera que este ambiente permite de forma práctica e intuitiva seleccionar los componentes que se requieren en la composición.

(26)

debido a que en un contexto de desarrollo basado en composición se construyen sistemas basados en estas arquitecturas [43].

4. Disponibilidad de la herramienta (DI). Que se encuentren disponibles actual-mente, ya que existe una gran cantidad de herramientas para la composición de componentes sin embargo algunas de estas ya no se encuentran disponibles o son herramientas propietarias.

Tabla 2.1: Herramientas seleccionadas

No. Herramienta _{SP DD WM DI}Características

1 Apache ODE X X X X

2 Apatar × X X X

3 BonitaSoft X X X X

4 Dapper X × X ×

5 Enhydra Shark X × X X 6 Google Mashup X × X ×

7 Intel Mash Maker X × × ×

8 JawFlow X × X ×

9 JBoss X × X X

10 JackBe X X X ×

11 JOpera X × X X

12 Loni pipeline X X X X

13 Marmite X X × ×

14 Microsoft Popy X X X ×

15 OpenKapow X X X ×

16 Potluck × × X ×

17 QedWiki X × X ×

18 RSSBus × × X ×

19 RUNA WFE × × X X

20 Taverna X X X X

21 WaveMaker X X X X

22 Yahoo Pipes! X X X X

Después de analizar las características de cada herramienta, como se puede ver la Tabla

2.1, las únicas que cumplen con las características establecidas, son las siguientes:

Apache ODE.

BonitaSoft.

Loni pipeline.

Taverna.

Yahoo Pipes!.

(27)

2.2. Composición realizada

Para evaluar estas herramientas se considera un sistema, creado a partir de la composición de componentes de software, que debe automatizar lo siguiente: Se desea obtener una lista de comentarios de Twitter. Dichos comentarios deben estar ordenados por fecha de forma ascendente y traducidos al español. Además se necesita que la composición se ejecute en un tiempo aproximado de 900-1000 milisegundos y que tenga una disponibilidad de al menos 95 %. Para poder crear ese sistema, se asume que se cuenta con componentes de tipo servicio web que son provistos por diferentes fabricantes. Estos componentes se describen con mayor detalle en la Tabla 2.2.

Es importante mencionar que los atributos de calidad de cada componente se obtuvieron de la página del fabricante de cada servicio, y en el caso de los componentes desarrollados por los autores de este trabajo, sus respectivos atributos de calidad se calcularon de forma manual.

2.3. Método de evaluación

Se pretende detectar un conjunto general, (no de dominio especíco) de problemas en el proceso de composición de componentes. Se preeren métodos prácticos, efectivos y con poca demanda en tiempo, esto debido a la naturaleza, alcance y tiempo disponible para el desarrollo de este trabajo. Es por esto que los métodos de inspección se consi-deran adecuados para este trabajo, ya que son métodos en donde un grupo de expertos examinan aspectos relacionados con la usabilidad de la interfaz y el funcionamiento del software [44]. Entre los métodos de inspección se encuentran la Evaluación heurística, Recorrido cognitivo, Inspección de estándares y Recorrido de usabilidad plural.

Después de analizar las ventajas y desventajas de los métodos de inspección, se considera que la evaluación heurística, es un método apropiado para este trabajo, ya que permite hallar problemas tanto mayores como menores. Aunque su principal desventaja sea ig-norar problemas especícos del dominio, esto no tiene impacto negativo en este trabajo ya que como se mencionó con anterioridad se desea descubrir un conjunto de problemas generales para algunos dominios propuestos y no en alguno en particular. En la sección

(28)

Capítulo 2. Estado del A rte 15

Tabla 2.2: Componentes utilizados para realizar la composición propuesta

Componente Operación Descripción Calidad de_Servicio Ubicación

C1 Búsqueda de_{información textual}

Recibe el tema a buscar, realiza una búsqueda en twitter del tema indicado y devuelve una lista de comentarios.

Rendimiento: 483 ms

Disponibilidad: 100 % https://dev.twitter.com/

C2 Búsqueda de_imágenes

Recibe el tema a buscar, realiza una búsqueda en instagram del tema indicado y devuelve una lista de imágenes.

Rendimiento: 485 ms

Disponibilidad: 100 % http://developers.instagram.com/

C3 Traducción de_{inglés a español}

Recibe una lista de información textual y devuelve la lista traducida al idioma español.

Rendimiento: 400 ms

Disponibilidad: 100 % https://developers.google.com/

C4

Ordena información textual de forma ascendente

Recibe la lista de comentarios y la ordena de forma ascendente tomando en cuenta la fecha de creación.

Rendimiento: 150 ms Disponibilidad: 90 %

Este componente fue desarrollado por los autores de este trabajo

C5

Ordena información textual de forma ascendente

Recibe la lista de comentarios y la ordena de forma descendente tomando en cuenta la fecha de creación.

Rendimiento: 90 ms Disponibilidad: 100 %

(29)

2.3.1. Evaluación heurística

La evaluación heurística es un método en el cual un grupo de expertos inspecciona algún producto de software con el n de determinar si se adhiere o no a un conjunto de principios o heurísticas de diseño [45]. La palabra heurística viene de la griega eureka, y en el contexto de la evaluación heurística, se reere a una serie de principios generales que consideran los expertos para llevar a cabo dicha evaluación. Estos principios se adecúan para asegurar que se adaptan al contexto de la interfaz del software que se va evaluar [45].

Para realizar este tipo de evaluación Nielsen arma que entre tres y cinco expertos bastan para encontrar aproximadamente el 75 % de los problemas de usabilidad.

La evaluación heurística es considerada económica, intuitiva y utilizable en las primeras fases del proceso de desarrollo, esto para detectar la mayor cantidad posible de proble-mas de usabilidad antes de que el software esté en producción. Además permite hallar tanto problemas mayores como menores. Una desventaja es que puede ignorar problemas especícos del dominio de aplicación.

En las siguientes secciones se denen un conjunto de heurísticas relevantes que permi-tan evaluar el funcionamiento y la usabilidad de las herramientas de composición de componentes seleccionadas.

2.3.2. Heurísticas para la evaluación del funcionamiento

Las características funcionales son aquellas que se consideran básicas y que todas las herramientas deberían tener para poder dar soporte al proceso de composición de com-ponentes de software.

A continuación se indican con letras negritas cursivas las heurísticas que han sido pro-puestas para la evaluación de las características funcionales:

i. Generación de la Composición Automáticamente (CA). Denota la capaci-dad de la herramienta para generar el código de la composición de componentes de forma automática.

(30)

iii. Escalabilidad (ES). Denota la capacidad de la herramienta de permitir al au-mento de componentes y/o operaciones, garantizando la correcta ejecución de la composición.

2.3.3. Heurísticas para la evaluación de la usabilidad

En el contexto de la Ingeniería de Software, la usabilidad es un atributo de calidad que, en términos generales, se reere a la facilidad de uso de un sistema de software. Existen diversas deniciones de usabilidad. El estándar ISO 9241 la dene como el grado en el que un producto puede ser utilizado por usuarios especícos para conseguir objetivos especícos con efectividad, eciencia y satisfacción en un determinado contexto de uso [46]. Similarmente, la usabilidad ha sido denida como la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones especícas de uso [47].

La usabilidad puede ser medida y evaluada [48]. Sin embargo, como se puede concluir de las deniciones de la sección anterior, la evaluación de la usabilidad es relativa al contexto de conjunto de usuarios especíco.

(31)

Tabla 2.3: Conjunto de heurísticas y principios seleccionados para la evaluación

Categoría Heurísticas o Principios por Autor_{Nielsen [}₄₉_] _{Tognazzini [}₅₀_] _{Shneiderman [}₅₁_]

Retroalimentación Visibilidad del estado del_sistema Navegación visible_{Anticipación} Retroalimentación_informativa

Control sobre el ambiente Control y libertad del usuario Eciencia del usuarioAutonomía Interfaces explorables

Revertir acciones Control por parte del usuario

Manejo de errores Prevención de erroresAyudar a los usuarios a Manejo de errores reconocer, diagnosticar y

recuperarse de los errores Manejo de errores

Valores por defecto

Aprendizaje

Relación entre el sistema y el mundo real

Aprendizaje Uso de metáforas Objetos humanos Reconocimiento antes

que recuerdo

Aprendizaje Uso de metáforas Objetos humanos

Reducir la carga de memoria de corto plazo

Flexibilidad y eciencia Uso de atajos

Consistencia y estándares Consistencia Consistencia Ayuda y documentación

Valores por defecto Estética y diseño minimalista

Daltonismo Ley de Fitts Reducción de la latencia

Legibilidad

(32)

El principio de anticipación, denido por Tognazzini [50], hace referencia a que los sis-temas deberían anticiparse a las necesidades y deseos del usuario. Se debe evitar que los usuarios tengan que buscar o recordar mucha información durante el uso del sistema y, en cambio, mostrarle la información y herramientas necesarias para realizar su trabajo. De esta forma, la consideración de este principio en el diseño de las herramientas de compo-sición facilitaría a un usuario nal realizar la selección de los componentes que satisfagan no solo las características funcionales requeridas (problema: selección de componentes disponibles), sino también los que satisfagan la calidad de servicio de la composición requeridas para la composición (problema: especicación de la calidad de servicio de la composición).

Como se observa en la Tabla2.3, en la categoría manejo de errores se han agrupado heu-rísticas y principios, propuestos por los tres autores, relacionados con este tema. En todos estos se comparte la visión de que el sistema debe ser capaz de reconocer, diagnosticar y recuperarse de errores. Así, el considerar las heurísticas y principios en esta categoría en el diseño de las herramientas de composición evitaría que el usuario nal tuviera que detectar, diagnosticar y resolver manualmente incompatibilidades entre los componentes que va a utilizar (problema: detección de incompatibilidades entre componentes).

Heurísticas como relación entre el sistema y el mundo real y reconocimiento antes que recuerdo, propuestas por Nielsen [49], establecen que el sistema debe hablar el lenguaje de los usuarios preriendo las conceptos y frases familiares a ellos. Por otra parte el principio de aprendizaje de Tognazzini indica que se debe reducir la curva de aprendizaje del uso sistema. De esta forma, estas heurísticas y principios en el diseño de las herramientas de composición contribuye a mejorar el nivel abstracción del lenguaje utilizado (problema: uso de un lenguaje de bajo nivel de abstracción).

(33)

Tabla 2.4: Conjunto de sub-heurísticas seleccionadas para la evaluación

Problema Heurísticas y Principios Sub-Heurísticas

Selección de componentes disponibles

Estimación de calidad de servicio de la composición

Anticipación

A1. Al inicio del proceso de composición el usuario puede especicar los aspectos funcionales y de calidad del servicio que espera de la composición

A2. Durante el proceso de composición se sugiere al usuario los componentes que satisfacen la funcionalidad y calidad del servicio

Detección de

incompatibilidades entre componentes

Prevención de errores

Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de los errores Manejo de errores

E1. Durante el proceso de composición se previene que los usuarios cometan errores

E2. Durante el proceso de composición, si se detectan errores se informan las posibles causas

E3. Durante el proceso de composición, si se detectan errores se sugieren posibles soluciones para resolverlos

E4. Los mensajes de error, e información relacionada, se comunican usando un lenguaje poco técnico

Uso de un lenguaje de bajo nivel de abstracción

Relación entre el sistema y el mundo real

Reconocimiento antes que recuerdo

Aprendizaje

L1. Los íconos son claros y usa un lenguaje visual intuitivo y poco técnico

(34)

Tabla 2.5: Participantes en la evaluación heurística

Experto Perl

E1 Experto 1 Licenciatura en Informática y actualmente alumno delcuarto semestre un programa de Maestría en Sistemas Interactivos Centrados en el Usuario

E5 Experto 5 Maestría en Redes y Sistemas Integrados, experiencialaboral en el desarrollo de sistemas basados en componentes

2.4. Participantes en la evaluación

Con base en lo descrito en la sección 2.3.1 con respecto al número de participantes, en la Tabla 2.5, se describe el perl de los 5 expertos (como los llama Nielsen [49]) que realizaron la evaluación heurística de las herramientas seleccionadas.

2.5. Resultados obtenidos

En las siguientes secciones, se muestran los resultados consolidados de las evaluaciones realizadas por los expertos.

2.5.1. Resultados de la evaluación funcional

En esta sección se muestran los resultados obtenidos de la evaluación funcional realizada a las herramientas de composición de componentes. En las Tablas 2.6 y 2.7 se pueden observar los resultados obtenidos por los cinco expertos. Si la herramienta cumple con la heurística se denota con un 1 y si no con un 0.

(35)

Tabla 2.6: Resultados obtenidos de la evaluación heurística de funcionalidad - I. Ge-neración de la Composición Automáticamente (CA), Vericación de la Composición

Automáticamente (VA) y Escalabilidad (ES).

Heurística

_{E1 E2 E3 E4 E5 E1 E2 E3 E4 E5 E1 E2 E3 E4 E5}

Apache ODE

BonitaSoft

Loni Pipeline

CA

1 1 1 1 1 1 1 1 1 1 0 0 0 0 0

VA

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

ES

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Tabla 2.7: Resultados obtenidos de la evaluación heurística de funcionalidad - II. Generación de la Composición Automáticamente (CA), Vericación de la Composición

Automáticamente (VA) y Escalabilidad (ES).

Heurística

_{E1 E2 E3 E4 E5 E1 E2 E3 E4 E5 E1 E2 E3 E4 E5}

Taverna

Wave Maker

Yahoo Pipes!

CA

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

VA

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

ES

1 1 1 1 1 1 1 1 1 1 0 0 0 0 0

2.5.2. Resultados de la evaluación de usabilidad

En esta sección se muestran los resultados obtenidos de la evaluación heurística de usa-bilidad de las herramientas de composición seleccionadas. En las Tablas 2.8 y 2.9, se observan dichos resultados los cuales deben ser interpretados considerando la siguiente fórmula que calcula el nivel de severidad del error detectado en la evaluación:

N S= (F)x(I)

Donde:

F denota la frecuencia con la que se incurre en el error.

I denota el impacto asociado a cada sub-heurística.

La frecuencia (F) puede tomar los siguientes valores:

0 = nunca.

1 = a veces.

(36)

El impacto (I) puede tomar los siguientes valores:

0 = No es problema de usabilidad.

1 = Problema sin importancia, no es necesario arreglarlo a menos que haya tiempo.

2 = Problema de poca importancia, arreglarlo no tiene mucha importancia.

3 = Problema grave, es importante arreglarlo.

4 = Problema catastróco, es vital arreglarlo.

El nivel de severidad (NS) puede tomar los siguientes valores:

0 = No es un error.

1 - 2 = Error sin importancia.

3 - 4 = Error de grado medio.

5 - 6 = Error grave.

7 - 8 = Error catastróco.

El valor mostrado en las columnas E1, E2, E3, E4, E5 de las Tablas 2.8y2.9, indica el nivel de severidad del error detectado por cada experto.

(37)

Tabla 2.8: Resultados obtenidos de la evaluación heurística de usabilidad - I

Sub-heurística

_{E1 E2 E3 E4 E5 R E1 E2 E3 E4 E5 R E1 E2 E3 E4 E5 R}

Apache ODE

BonitaSoft

Loni Pipeline

A1

8 6 8 6 6 6.8 8 6 8 2 6 6 8 6 8 1 8 6.2

A2

8 6 8 3 6 6.2 6 6 6 1 6 5 8 1 8 2 6 5

E1

6 3 6 3 8 5.2 3 4 4 3 6 4 6 1 3 2 6 3.6

E2

6 3 6 8 6 5.8 6 6 6 3 6 5.4 6 1 6 3 6 4.4

E3

8 6 8 8 8 7.6 6 8 8 8 6 7.2 6 2 8 6 6 5.6

E4

8 8 8 8 8 8 8 3 8 8 6 6.6 6 3 8 3 6 5.2

L1

8 8 8 6 6 7.2 8 3 6 1 6 4.8 6 2 3 2 6 3.8

L2

8 6 8 3 8 6.6 8 2 8 2 6 5.2 6 2 3 3 6 4

Tabla 2.9: Resultados obtenidos de la evaluación heurística de usabilidad - II

Sub-heurística

_{E1 E2 E3 E4 E5 R E1 E2 E3 E4 E5 R E1 E2 E3 E4 E5 R}

Taverna

Wave Maker

Yahoo Pipes!

A1

8 6 8 3 6 6.2 8 6 8 2 6 6 8 6 8 2 6 6

A2

8 6 8 3 6 6.2 8 6 8 2 6 6 6 6 8 3 6 5.8

E1

6 6 2 3 6 4.6 8 3 8 4 6 5.8 6 2 8 4 6 5.2

E2

6 3 6 6 6 5.4 6 2 8 3 6 5 6 2 8 6 6 5.6

E3

8 8 8 4 6 6.8 8 4 8 6 6 6.4 8 4 8 6 6 6.4

E4

8 6 6 6 6 6.4 8 8 8 6 6 7.2 8 3 6 8 6 6.2

L1

8 8 8 3 6 6.6 8 3 8 2 6 5.4 8 2 8 6 6 6

L2

8 3 8 2 6 5.4 8 8 8 2 6 6.4 8 2 8 6 6 6

(38)

Capítulo

2.

Estado

del

A

rte

25

(39)

La anticipación es un problema que va de grave a catastróco (nivel de severidad de 5 a 7), debido a que ninguna de las herramientas ofrece soporte para especicar, al inicio del proceso de composición, los aspectos funcionales y de calidad del servicio que se espera del sistema a construir (sub-heurística A1). Como consecuencia de lo anterior, ninguna de las herramientas evaluadas ofrece soporte para realizar la selección de componentes considerando los aspectos funcionales y de calidad de servicio requeridos (sub-heurística A2). El usuario nal tiene siempre que resolver todo esto de forma manual.

En lo que se reere al manejo de errores se detectó que es un problema que va de grado medio a catastróco (nivel de severidad de 4 a 8), ya que algunas herramientas brindan cierto soporte para prevenir errores (sub-heurística E1), sin embargo cuando se presentan errores los mensajes de error no brindan información de la causa y tampoco de cómo resolver el error presentado (sub-heurísticas E2 y E3), además el mensaje se comunican al usuario usando un lenguaje técnico (sub-heurística E4).

Finalmente, el uso de un lenguaje de bajo nivel en la composición es un problema que va desde grado medio hasta catastróco (nivel de severidad de 4 a 7), esto porque todas las herramientas utilizan íconos poco intuitivos y un lenguaje muy técnico para los usuarios nales (sub-heurísticas L1 y L2), sin embargo algunas herramientas utilizan un lenguaje que puede ser más técnico que el utilizado en otras y dado que los evaluadores tienen conocimientos en desarrollo de sistemas, no calicaron este lenguaje como un lenguaje muy técnico.

2.6. Reexiones nales

A partir de los resultados de la evaluación realizada se puede concluir que las herramien-tas evaluadas presentan problemas de usabilidad para un usuario nal. Entre los más importantes se encuentran el nulo soporte ofrecido para la especicación de aspectos funcionales y de calidad del servicio del sistema a construir y para la selección de com-ponentes basada en dichas especicaciones. Además de que las herramientas no proveen mecanismos que brinden el soporte necesario a los usuarios para resolver los errores que puedan tener al hacer una composición, ya que como se observó, las herramientas no muestran las causas ni las posibles soluciones a dichos errores.

Aunque estos problemas son generales, se considera que es importante conocerlos pues proveen un conjunto inicial que puede ser estudiado con más detalle considerando con-textos más especícos a determinados tipos de usuarios nales ej., sociólogos, biólogos.

(40)

(41)

Capítulo 3

Solución Propuesta

En el capítulo anterior se discutieron aspectos relacionados con el problema de la falta de usabilidad de varias herramientas de composición de componentes. En este capítulo se discute la solución propuesta a este problema, además se muestran los conceptos y técnicas relacionados a esta solución. La solución es un proceso que involucra el uso de (i) especicación formal de modelos de arquitectura data-ow para el modelado de composiciones, (ii) planicación como en inteligencia articial para la generación de la composición y (iii) teoría de utilidades para el cálculo de la calidad de servicio de la composición. A través de una herramienta, que se describe con detalle en el Capítulo4, este proceso puede ser semi-automatizado.

A continuación se describe este proceso.

1. Especicación de las tareas. El usuario nal deberá realizar, de forma manual y solo una vez, la especicación de las tareas que pueden realizarse en la composición. Dicha especicación es en un lenguaje de alto nivel de abstracción. Para realizar esta especicación se propone utiliza una plantilla en donde el usuario describe cierta información importante de la tarea.

2. Especicación de los modelos formales. El arquitecto de sistemas, deberá tomar la especicación de las tareas realizada por el usuario nal y utilizando conceptos de arquitectura de software la traducirá de forma manual en dos modelos formales: uno general y otro de domino especíco. El modelo general se generará solo una vez y se podrá reutilizar para la generación de varias composiciones, ya que en el se describirán características de las arquitecturas data-ow que todas las composiciones comparten. Como su nombre lo sugiere el modelo de domino especíco describirá las características especícas de cada composición, por lo que se debe generar para cada composición. Sin embargo, una vez generado el primer

(42)

Capítulo 3. Solución Conceptual 29

modelo para una composición, generar los de las demás es una tarea trivial. Ya que solo se deben modicar los componentes utilizados en cada dominio, y en su caso agregar restricciones propias del dominio. El modelo general y el de domino especíco se generan utilizando conceptos de arquitectura de software y un lenguaje basado en lógica.

3. Generación iterativa e incremental de la composición. Esto se hace de forma semi-automática mediante una herramienta, cuya estructuración y funcionamiento general se muestra en la Figura 3.1. Esta herramienta implementa varios algorit-mos para soportar un sub-proceso que permite al usuario nal construir de forma iterativa e incremental la composición considerando funcionalidad y expectativas de calidad. Este sub-proceso está denido como sigue:

3.1. Generación de la composición. Este algoritmo automatiza la generación de una composición a partir de componentes seleccionados por el usuario.

Entradas: repositorio de componentes, los modelos formales previamente generados, los componentes seleccionados por el usuario y la composición actual (la composición actual aparece como entrada a partir de la segunda iteración).

Funciones realizadas:

a. Agregar los componentes seleccionados por el usuario a la composición actual y vericar que ésta atiende las especicaciones de los modelos formales.

b. A partir del contenido del repositorio de componentes, generar una lista de componentes no clasicada (sin contemplar expectativas de calidad) que atienden las especicaciones de los modelos formales y que el usuario podría agregar a la composición actual.

Salidas: Composición actual y lista de componentes no clasicada. 3.2. Evaluación de la composición, con respecto a expectativas de

cali-dad. Este algoritmo automatiza la estimación de calidad servicio de la com-posición, descrito en la sección1.2.

Entradas: Composición actual y lista de componentes no clasicada. Funciones realizadas:

a. Calcular la utilidad de la composición actual.

(43)

Figura 3.1: Estructura y funcionamiento de la herramienta para la generación iterativa e incremental de una composición.

c. Una vez que el usuario selecciona algún componente de la lista clasi-cada, repetir el paso 3.1. Este proceso se termina cuando el usuario agrega un componente de n a la composición.

Salidas: Composición actual y lista de componentes clasicada. Técnicas utilizadas: Teoría de utilidades.

(44)

3.1. Especicación de las tareas

En esta sección se describen los conceptos relacionados a la etapa 1 del proceso propuesto, es decir, los conceptos relacionados a la especicación de las tareas.

Como ya se ha mencionado, el usuario nal carece de conocimientos técnicos en el área de desarrollo de sistemas. Por ello se propone utilizar una plantilla fácil de llenar para él, en donde podrá especicar las tareas que pueden realizarse en la composición utilizando un lenguaje de alto nivel de abstracción.

En la Figura3.2se muestra dicha plantilla y se puede observar que requiere información de dos grandes categorías que a continuación se explican:

Denición abstracta de la tarea: En esta categoría se especica información de alto nivel de abstracción que permite saber la secuencia de tareas en la composición.

− Nombre de la tarea. Especíca el nombre que el usuario le da a la tarea.

− Descripción de la tarea. Especíca de forma breve la función de la tarea.

− Tareas sucesoras. Especíca las tareas que pueden realizarse antes de esta

tarea.

− Tareas predecesoras. Especíca las tareas que pueden realizarse después de

esta tarea.

Denición técnica de la tarea: En esta categoría se especica información téc-nica sobre la tarea.

− Tipo de dato de entrada. Especíca el tipo de dato que la tarea requiere.

− Concepto de entrada. Especíca el signicado del tipo de dato de entrada.

− Parámetros requeridos. Especíca otros parámetros además del tipo de dato

que la tarea debe recibir para funcionar adecuadamente, por ejemplo el idioma origen de la información textual y el idioma destino, en el caso de la tarea de traducción.

− Ruta. Especíca la dirección url en donde se puede invocar dicha tarea.

− Tipo de dato de salida. Especíca el tipo de dato que la tarea provee.

− Concepto de salida. Especíca el signicado del tipo de dato de salida.

− Tipos y valores de atributos de calidad (QoS). Especíca los nombres y los

valores de los atributos de calidad de la tarea.

(45)

Figura 3.2: Plantilla para la especicación de las tareas que pueden utilizarse en una composición.

Figura 3.3: Especicación de la Tarea Traducir comentarios.

3.2. Especicación de los modelos formales

(46)

3.2.1. Arquitectura de software

En el contexto de la Ingeniería de Software, la arquitectura es un modelo que describe las estructuras de un sistema de software en términos de componentes, relaciones y las propiedades de ambos [19], [20], [52]. A continuación se describen estos elementos:

Componentes: representan los elementos computacionales de un sistema. Cada componente tiene un tipo y dene un conjunto de puertos, que son las interfaces de ese componente, a través de los cuáles interactúa con otros componentes del modelo. Por ejemplo, un componente de tipo servidor puede tener un número de puertos de tipo receptor de servicios que le permiten interactuar con componentes de tipo cliente.

Relaciones: representan elementos encargados de efectuar y regular las interaccio-nes entre los componentes. Esto es, los conectores entre ellos. Cada relación dene un conjunto de roles que sirven como interfaces para soportar las interacciones entre componentes. Por ejemplo, una relación que conecta un cliente a un servidor puede denir del lado del cliente un rol de tipo invocador y del lado del servidor un rol de tipo invocado.

Propiedades de los componentes: son aquellas características del componente, que permiten renar su naturaleza y por lo tanto entenderlos mejor. Por ejemplo una propiedad de un componente de tipo servidor es la cantidad de clientes que puede atender por minuto.

Propiedades de las relaciones: son aquellas características que permiten renar la naturaleza de las relaciones y por lo tanto comprenderlas mejor. En el modelo cliente-servidor una propiedad de la relación que conecta un cliente a un servidor puede ser el tipo de seguridad que tiene este canal de comunicación.

Aunque en esta denición de arquitectura solo se distinguen de forma explícita las pro-piedades de componentes y conectores, conceptos como roles y puertos también pueden denir propiedades.

3.2.2. Estilos arquitectónicos

Un modelo de arquitectura puede denirse reutilizando conocimiento de diseño previo, lo que ha dado lugar al concepto de estilo arquitectónico [53].

(47)

el tipo de relaciones y los componentes permitidos. Algunos ejemplos de estilos arquitec-tónicos son el cliente-servidor, el data-ow, etc.

Particularmente el estilo data-ow está caracterizado por un tener una cadena de componentes que hacen una transformación sucesiva de (ujos de) datos. Los datos llegan a un componente, a través de un conector, este los transforma y los envía a través de un conector al siguiente componente en la cadena. En la Figura 3.4 se aprecia un ejemplo de este estilo. En su forma más simple, por ejemplo, este estilo se puede denir en términos de la siguiente información:

Componentes: Un conjunto de componentes de tipo Tarea que se dividen en: una de tipo Inicial, una de tipo Final y más de una de tipo Intermedia. Cada tarea tiene un puerto de entrada de información y uno de salida de información.

Relaciones: Relaciones de tipo Enlace con un rol de ujo de entrada que trans-mite información de entrada a las Tareas y el rol de ujo de salida que recibe la información de salida de una Tarea y la transmite.

Propiedades de los componentes: Las Tareas realizan una función.

Propiedades de las relaciones: El tipo de dato que se envía o recibe a través de los Enlaces es de tipo cadena.

(48)

Figura 3.4: Estilo data-ow

3.2.3. Especicación formal de arquitectura de software

Ya se ha mencionado, al inicio de este capítulo, que un modelo de arquitectura puede especicarse utilizando diversas notaciones, normalmente se especica usando notaciones visuales como por ejemplo UML o bien notaciones formales como los lenguajes de des-cripción de arquitectura (ADL por sus siglas en inglés) [54]. Los ADLs usan un lenguaje basado en lógica de predicados de primer orden. El Listado3.1ilustra un ejemplo de par-te de una especicación, en lenguaje de descripción de arquipar-tectura, de una arquipar-tectura data-ow.

En el Listado 3.1se puede observar la especicación formal de los términos descritos en la Figura3.4.

Componentes: De la línea 2 a la línea 34 se encuentra la especicación de compo-nentes de tipo Tarea.

Relaciones: La denición de una relación de tipo Enlace se pueden ver de la línea 35 a la 38.

Propiedades de los componentes: Un ejemplo de una propiedad de un componente se puede ver en las líneas 4 y 5, donde se especica una tarea sucesora y una predecesora respectivamente.

(49)

Invariantes del estilo: Se pueden observar de la línea 43 a la 48. Por ejemplo, en las líneas 44 y 45, se especica que para ser una tarea inicial no debe tener tareas predecesoras y para ser una tarea nal no debe tener tareas sucesoras.

(50)

1 System data - flow = { 2 Component Tarea = {

3 Property operation : string = ``buscar ''; 4 Property succesortask : string = ``traducir ''; 5 Property predecessortask : string = null ; 6 Property performance : int = 430;

7 Property availability : int = 97; 8 Port entrada ={

9 Property datatype : string = ``cadena ''; 10 Property concept : string = ``tema '';

11 };

12 Port salida ={

13 Property datatype : string =``lista ''; 14 Property concept : string = `` comentarios '';

15 };

16 };

17

18 ...

19

20 Component Tarea = {

21 Property operation : string = ``traducir ''; 22 Property succesortask : string = ``listar ''; 23 Property predecessortask : string = ``buscar ''; 24 Property performance : int = 300;

25 Property availability : int = 94; 26 Port entrada ={

27 Property datatype : string = ``lista ''; 28 Property concept : string = `` comentarios '';

29 };

30 Port salida ={

31 Property datatype : string =``lista '';

32 Property concept : string = `` comentariostraducidos '';

33 };

34 };

35 Connector Enlace = {

36 Property protocol : string = ``tcp ''; 37 role flujosalida ={}; role flujoentrada ={};

38 };

39 Attachments {

40 Tarea . entrada to Enlace . flujoentrada ; 41 Tarea . salida to Enlace . flujosalida ;

42 }

43 invariant

44 for all t : Tarea | inicial (t) -> Tarea . predecessortask = null ; 45 for all t : Tarea | final (t) -> Tarea . succesortask = null ; 46 for all t1 , t2 : Tarea | conectado (t1 , t2 ) ->

47 t1. entrada . datatype = t2. salida . datatype AND 48 t1. entrada . concept = t2. salida . concept ; 49 }

(51)

3.3. Generación iterativa e incremental de la composición

En las siguientes secciones se describen los conceptos relacionados a la etapa 3 del proceso propuesto, ilustrado en la Figura3.1, es decir, los conceptos relacionados a la generación de la composición y la evaluación de la composición considerando expectativas de calidad.

3.3.1. Generación de la composición utilizando planicación

En el área de Inteligencia Articial (IA) existe un proceso llamado planicación el cual permite generar un plan para alcanzar un objetivo. Por ejemplo, se puede generar un plan para denir la trayectoria de un turista para llegar de una ciudad a otra. Los programas que generan estos planes se llaman planicadores. Algunos ejemplos de estos programas son SHOP [55], Haley [56] y O-Plan [57]. Para la implementación de un planicador generalmente se utiliza un lenguaje de programación lógica.

En diversos trabajos de planicación [58], [59], [25] se ha utilizado para soportar el proceso de composición automática de componentes considerando las equivalencias mostradas en la Tabla 3.1.

Considerando la Figura3.4un ejemplo de composición automática usando planicación requeriría especicarle al planicador, entre otra información, lo siguiente:

Una especicación de la operación inicial: Buscar comentarios en inglés.

Una especicación de la operación nal: Listar comentarios en español.

Conjunto de operaciones. Una especicación de un conjunto de operaciones posi-bles para alcanzar la operación nal. Por ejemplo, se podría utilizar la operación Traducir para traducir al español los comentarios encontrados y así alcanzar la operación nal. Para esta operación la precondición es que el tamaño de la lista de los comentarios no debe ser igual a cero y que los comentarios estén escritos en español. La postcondición es que el tamaño de la lista de los comentarios no debe ser igual a cero y que los comentarios estén escritos en inglés.

Utilizando programación lógica, la especicación de la operación traducir podría reali-zarse de la siguiente forma:

Operación: (Traducir (c: comentarios),

Precondición:¬Tamaño (c, 0)∧ Idioma (c, Español)

(52)

Tabla 3.1: Equivalencias entre Planicación y Composición

Término en planicación IA Denición en composición de componentes

Acción inicial Operación que realiza un componente y que debeser considerada por el planicador como acción inicial del plan.

Acciones Operaciones que realizan los componentes quedeben ser consideradas por el planicador para ir desde la acción inicial hasta la nal.

Acción nal Operación que realiza un componente y que debeser considerada por el planicador como acción nal del plan.

En la operación Traducir especicada anteriormente se indica que una se recibe una lista de comentarios c en español y estos son traducidos al inglés. La precondición¬Tamaño

(c, 0), indica que el tamaño de la lista de comentarios c no tiene que se igual a cero, y la precodición Idioma (c, Español), indica que los comentarios c deben estar en español. La postcondición¬ Tamaño (c, 0) especica que el tamaño de la lista de comentarios c

tiene que seguir siendo diferente a cero y la postcondición Idioma (c, Inglés), indica que los comentarios c ahora deben estar en inglés.

3.3.2. Evaluación de la composición utilizando teoría de utilidades

En el área de economía y nanzas la teoría de utilidades proporciona un marco meto-dológico para la evaluación de opciones propuestas por los individuos, las empresas y organizaciones. El término utilidad se reere a la satisfacción que cada opción ofrece al tomador de decisiones. Por lo tanto, la teoría de utilidades asume que cualquier decisión se hace sobre la base del principio de maximización de la utilidad, esto es, la mejor opción es la que proporciona la mayor satisfacción para la toma de decisiones. [60].

En teoría de utilidades, una función de utilidad de la forma: U: X→R, se puede utilizar

para especicar la utilidad de un conjunto de alternativas.

Donde:

X denota el conjunto de opciones alternativas.

R denota el conjunto de valores de utilidad.

(53)

se ha denominado como, Utilidad Total Agregada (UTXAG) y se expresa de la siguiente manera:

U T XAG=

q

X

i=1

wi∗(agQSi)

Donde:

qdenota los atributos de calidad que el usuario necesita que la composición cumpla,

por ejemplo rendimiento y disponibilidad.

w denota los pesos que el usuario le da a cada atributo de calidad, por ejemplo

60 % rendimiento y 40 % disponibilidad.

agQSdenota la utilidad de la composición total, la cual es el resultado de la fórmula

particular para calcular cada atributo de calidad.

El resultado de aplicar la fórmula anterior puede ir de 0 a 1, en donde 0 signica que la composición tiene utilidad nula y 1 que tiene la utilidad máxima.

Para calcular cada atributo de calidad indicado por el usuario, se utilizan diferentes fórmulas, como ya se mencionó. Particularmente se tomaron las siguientes fórmulas para calcular el rendimiento y la disponibilidad de [63]:

Rendimiento=maxn

i=1Xt(oi)

Donde:

Xtdenota el tiempo de ejecución.

oi denota la operaciónidel ensamblaje.

Disponibilidad=

n

Y

i=1 Av(oi)

Donde:

Av denota la disponibilidad.

oi denota la operaciónidel ensamblaje.

(54)

Figura 3.5: Componentes candidatos en una composición

Para entender como la teoría de utilidades permite elegir entre un conjunto de compo-nentes al que mejor satisfaga la calidad que el usuario necesita, se va suponer que en la composición ya se tienen dos componentes de tipo Tarea, uno que realiza la función de buscar comentarios y otro que traduce comentarios, y se desea agregar un tercer compo-nente que realice la función de listar comentarios, sin embargo se tienen dos compocompo-nentes que realizan esta función, tal y como se puede observar en la Figura3.5.

Para empezar resolver lo anterior se debe ocupar la fórmula de Utilidad Total Agregada, para lo cual primero se debe calcular la calidad de cada atributo en la composición, esto se hace utilizando las fórmulas particulares que se explicaron con anterioridad, de este modo se tiene:

Listar comentarios 1 (LC1):

• Rendimiento(Xt) = m´ax(0.430,0.300,0.200) = 0.430

• Disponibilidad(Av) =Y(0.97 + 0.94 + 0.95) = 0.95

Listar comentarios (LC2):

• Rendimiento(Xt) = m´ax(0.430,0.300,0.400) = 0.430

• Disponibilidad(Av) =Y(0.97 + 0.94 + 0.97) = 0.96

Finalmente se puede resolver la fórmula de la siguiente manera:

U T XAG(LC1) =wXt∗(agQSXt) +wAv∗(agQSAv)

=0.60∗0.430 + 0.40∗0.95 = 0.63

U T XAG(LC2) =wXt∗(agQSXt) +wAv∗(agQSAv)