ceso para la composición de componentes. Este objetivo especíco se cumplió ya que el uso de arquitectura de software, planicación, teoría de utilidades y java permitieron desarrollar el proceso para generar la composición así como implemen- tar la herramienta que lo automatizó. Esto se puede comprobar a lo largo de los Capítulos3,4 y5.
Implementar una herramienta que automatice dicho proceso. Este objetivo espe- cíco se cumplió ya que como se puede ver en el Capítulo 4 se implementó una herramienta que automatiza el proceso propuesto en el Capítulo3.
Evaluar las capacidades funcionales de la herramienta implementada. Este objetivo especíco se cumplió ya que se realizó una evaluación tanto de funcionamiento como de usabilidad, la cual se puede observar en el Capítulo5, en donde se puede observar como la herramienta cumple con las capacidades funcionales que permiten realizar de forma correcta un composición de componentes.
Evaluar la usabilidad de la herramienta implementada. Este objetivo especíco se cumplió ya que se realizó una evaluación tanto de funcionamiento como de usabilidad, la cual se puede observar en el Capítulo5, en donde se puede observar como la herramienta disminuye los problemas de usabilidad presentados por las herramientas de composición mostradas en el Capítulo2.
De esta forma concluimos que la hipótesis de este trabajo:
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, es verdadera ya que como se pudo ver en el Capítulo 4 se mostró la herramienta que se desarrolló en este trabajo, la cual cuenta con un algoritmo ba- sado en modelos formales y planicación que permite al usuario nal crear sus propios sistemas basados en composición de componentes, disminuye signicativamente el nivel de severidad de los problemas descritos con anterioridad. Esto se logró principalmente haciendo transparente para el usuario el proceso de la generación iterativa e incremen- tal de la composición. Este proceso previene que se presenten incompatibilidades entre componentes y así como también que los usuarios deban estimar manualmente la cali- dad de servicio de la composición. Así mismo en la interfaz solo se utilizó un lenguaje e iconos conocidos para el usuario evitando así el uso de un lenguaje de bajo nivel de abstracción. Finalmente otro aspecto de la herramienta que logró disminuir un problema como la selección de componentes disponibles fue que se le pidió a los usuarios llenar una especicación de las tareas que utilizan en su dominio particular, de esta manera se pudo generar un repositorio de componentes que el usuario conoce.
Capítulo 6. Conclusiones y Trabajo Futuro 73 Como se mencionó la implementación del algoritmo de generación de la composición se realizó utilizando planicación, lo cual puede sugerir una desventaja ya que si en el dominio se tienen demasiados componentes, el algoritmo puede presentar problemas de funcionamiento, es decir, no va escalar correctamente. Sin embargo se debe aclarar que en los dominios de los usuarios nales es poco probable que existan más de 20 componentes en cada dominio, por lo que el uso de planicación sigue siendo una alternativa eciente en relación con la escalabilidad.
6.2. Trabajo futuro
Dentro de un trabajo de investigación es importante identicar las líneas de trabajo para dar continuidad al esfuerzo invertido. Por esto, esta sección pretende mostrar el trabajo futuro que es necesario realizar para seguir avanzando en el desarrollo de herramientas de composición de componentes más usables para el usuario nal. Estas líneas se explican en las siguientes secciones.
6.2.1. Automatización de la especicación del modelo formal de domi- nio especíco
Como se vio en el Capítulo 4 la especicación del modelo formal de dominio especíco se hace de forma manual, lo cual implica una desventaja ya que si el usuario desea agregar un nuevo dominio a la herramienta debe realizar la especicación de tareas para que posteriormente algún arquitecto de sistemas realice la especicación del modelo de dominio especíco. Esto puede ser problemático ya que si el arquitecto de sistemas no está disponible esta tarea se vuelve casi imposible de hacer sin él, además la realización de todo este proceso puede tomar tiempo.
Es por lo anterior que se propone implementar un módulo que permita generar automá- ticamente el modelo formal de dominio especíco. Esto se logra diseñando una plantilla editable en la que el usuario solo deberá ingresar aspectos como tipos de tareas y tipos de datos permitidos en el dominio, así como el nombre del componente y sus respectivas características descritas en4.2. Con estos datos será posible que el módulo genere el mo- delo formal del respectivo dominio especíco de forma automática. Con esto el usuario podrá prescindir del arquitecto de sistemas y ahorrar tiempo.
Capítulo 6. Conclusiones y Trabajo Futuro 74
6.2.2. Aplicación de la solución en otros dominios de aplicación y con usuarios nales
Como se vio en el Capítulo 4 solo se aplicó la herramienta desarrollada en un caso de estudio, esto puede suponer una desventaja ya que los dominios pueden llegar a ser muy diferentes entre sí, lo cual puede implicar que la solución propuesta no es generalizable a otros dominios. Además como se vio en el Capítulo5, la herramienta solo se probó con 10 usuarios nales, esto también implica que la herramienta pudiera no ser sucientemente usable para usuarios en general.
A pesar de lo anterior, se considera que la herramienta si es aplicable a diferentes domi- nios ya que, considerando este problema se diseñó el modelo formal general cuya función es precisamente la de validar aquellas características comunes a diferentes dominios. Sin embargo se sugiere aplicar la herramienta desarrollada a diferentes dominios para garan- tizar su generalidad, además de realizar otras evaluaciones considerando una cantidad mayor de usuarios nales que los contemplados en el Capítulo 5para así garantizar una mayor usabilidad.
6.2.3. Mejoras a la herramienta desarrollada
Como se vio en el Capítulo5, a pesar de que la herramienta desarrollada es mucho más usable en comparación con otras herramientas de composición. Sin embargo se puede mejorar la interfaz de usuario en el soporte que la herramienta brinda para prevenir errores. Así mismo se puede mejorar el lenguaje utilizado en estos mensajes y en general en toda la herramienta.
Lo anterior se puede corregir aumentando el nivel de detalle sobre la causa y la solución en los mensajes de error presentados al usuario y así poder garantizar que el usuario siempre conocerá porque ocurrió el error y en cierto grado poder evitarlo, además el usuario sabrá cómo resolver dicho error. Otra mejora a la herramienta es que en la interfaz se utilicen tanto términos menos técnicos como iconos más intuitivos, para lo cual se sugiere hacer varias propuestas de estos términos e iconos, y hacer varias evaluaciones para asegurar que sean los más usables.
Los trabajos propuestas permitirán que la herramienta implementada sea más usable, además de garantizar que dicha herramienta sea aplicable a una cantidad mayor de dominios.
Apéndice A
Especicación de Artefactos
Utilizados en la Herramienta
Propuesta
En este apéndice se muestra con mayor detalle los artefactos utilizados en Capítulo 4, estos artefactos son: la especicación de tareas del caso de estudio, la especicación del modelo formal general y la especicación del modelo formal de dominio especíco del caso de estudio.
A.1. Especicación de tareas - Caso de estudio
En esta sección se muestra la especicación de tareas para el caso de estudio mostrado en este trabajo.