Universidad de Chile Facultad de Ciencias Físicas y Matemáticas Departamento de Ciencias de la Computación ADAPTACION DE SOFTWARE DE APLICACIÓN AL PARADIGMA DE LA INGENIERIA DE LINEA DE PRODUCTOS DE SOFTWARE MEMORIA PARA OPTAR AL TITULO DE INGENIERO CIVIL EN COMPUTACIÓN GONZALO IGNACIO URROZ URZÚA PROFESOR GUIA: MARÍA CECILIA BASTARRICA PIÑEYRO MIEMBROS DE LA COMISIÓN: NANCY VIOLA HITSCHFELD KAHLER MARÍA CECILIA RIVARA ZÚÑIGA SANTIAGO DE CHILE MAYO, 2012
Transcript
Universidad de Chile Facultad de Ciencias Físicas y Matemáticas Departamento de Ciencias de la Computación
ADAPTACION DE SOFTWARE DE APLICACIÓN AL PARADIGMA
DE LA INGENIERIA DE LINEA DE PRODUCTOS DE SOFTWARE
MEMORIA PARA OPTAR AL TITULO DE INGENIERO CIVIL EN COMPUTACIÓN
GONZALO IGNACIO URROZ URZÚA
PROFESOR GUIA: MARÍA CECILIA BASTARRICA PIÑEYRO
MIEMBROS DE LA COMISIÓN:
NANCY VIOLA HITSCHFELD KAHLER MARÍA CECILIA RIVARA ZÚÑIGA
SANTIAGO DE CHILE
MAYO, 2012
I
Resumen En el actual mercado globalizado las grandes compañías de desarrollo de software están entregando a sus clientes distinta variedad de productos y con cada vez menos distancia de tiempo entre un producto y otro. Esto se debe a gran parte en la reutilización de sus productos para la generación de los nuevos. Esto responde a una creciente demanda por la variedad en los productos o su customización. Para llevar esto a cabo, las empresas de tecnología desarrollan lo que se conoce como “familia de productos” que se generan a partir de un paradigma de desarrollo conocido como SPL o línea de productos de software. Sus ventajas son la de tener un bajo Time to Market, además de disminuir los costos de producción y mejorar la mantenibilidad de los productos, entre muchas otras. Se pretende aplicar este paradigma en base a dos aplicaciones que actualmente comparten gran parte de su implementación. Estas aplicaciones son “Face animator” y “Tree grow simulator”, las cuales básicamente son aplicaciones que permiten visualizar mallas geométricas y manipularlas según distintos parámetros y algoritmos. “Face animator” es una aplicación pensada en la manipulación de mallas geométricas que modelan rostros humanos, permitiendo el movimiento de distintas partes del rostro. Por otro lado la aplicación “Tree grow simulator” está pensada para la manipulación de mallas geométricas que modelan troncos de árboles, permitiendo crear una animación para ver su crecimiento mediante la distribución de una hormona. Para lograr generar una familia de productos en base a estas dos aplicaciones, se tuvo que estudiar el código fuente de ambos y hacer correcciones en el código fuente de una de estas, para poder hacer una aplicación genérica. Para esto se identificaron los puntos en común (commonalities) y las distintas opciones para una funcionalidad (puntos de variabilidad). Para esto se utilizó una herramienta web llamada “S.P.L.O.T.”, que permite generar un modelo de características o “features” y aplicar reglas lógicas entre las distintas opciones para mantener la consistencia de los productos. Esta herramienta también cuenta con un catalogo o configurador de productos, donde se permite elegir las opciones (variantes) de los puntos de variabilidad, así generando una configuración para una aplicación especifica. El paso siguiente fue la creación de una nueva aplicación, que permite seleccionar las variantes para los puntos variables pre definidos. Luego esta herramienta compila el código fuente y genera un archivo de configuración y un ejecutable, que es la nueva aplicación configurada con las opciones seleccionadas. Dentro de las dificultades encontradas, el actual diseño no permite la separación de componentes de manera de que estos sean independientes, importante al momento de compilar, por lo que se propone como un futuro desarrollo la restructuración en las clases de la interfaz grafica y donde se implementan los distintos puntos de variabilidad. También se puede agregar funcionalidades como lectura de un archivo XML directamente desde la herramienta “S.P.L.O.T.” cargando así automáticamente la selección de opciones. También se hace necesario agregar funcionalidades que existen en la aplicación “Tree grow simulator” y no se encuentran implementados en el código fuente de “Face Animator”.
II
Agradecimientos
Quería partir agradeciendo a mi madre y abuela, quienes pusieron todo de sí para que yo
pudiese terminar este largo proceso. Son a ellas a quien más debo, tanto en lo material
como en lo emocional, ya que siempre tuvieron la mayor confianza en mis capacidades y
compartían mi sueño de poder lograr esta tarea. También quiero agradecer a mi novia por
su paciencia y palabras de aliento cuando lo necesitaba.
También quiero reconocer la ayuda de mis amigos y familiares por comprender el escaso
tiempo del que disponía. Termino estas palabras de agradecimiento, reconociendo a mis
Figura 4.2.10: Versión B, solo se presenta el algoritmo de des refinamiento “Área Cara Minima”. 39
Figura 5.2: Nuevo diagrama de clases de aplicación legados [FaceAnimator] ................................. 44
1
Capitulo 1
1. Introducción En el siguiente capítulo se explica la problemática que el presente trabajo de memoria
pretende resolver. Se presenta una visión general de distintos temas para contextualizar al
lector, para luego definir los objetivos que se pretenderán lograr.
1.1 Antecedentes generales
Actualmente el desarrollo de software es cada vez más complejo debido al gran impacto
que tiene este en distintos aspectos de la vida, así como también por la evolución
acelerada que tiene la tecnología día a día. Es por esto que es un desafío para los
desarrolladores de software generar un producto de calidad y lo suficientemente flexible
para poder escalar en el tiempo. Nace así un nuevo paradigma en el desarrollo de
software, “Líneas de Productos de Software” (LPS o SPL en ingles). Este paradigma se basa
en la reutilización de código y otros artefactos de software de forma sistemática de
manera de orientar la producción de software de manera masiva.
El Instituto de Ingeniería de Software (SEI) define de la siguiente manera una SPL: “Es un
conjunto de sistemas de software compartiendo características comunes y administradas
que satisface las necesidades específicas de un segmento de mercado particular o misión
y que son desarrollados de forma prescrita a partir de un conjunto común de elementos
clave”. Como lo indica la definición, una SPL consiste en un conjunto de elementos clave
para producir sistemas de software que comparten características comunes (llamadas
similitudes o commonalities), pero al mismo tiempo mantienen características propias
(llamada variabilidad) [Montilva2006].
Es con este paradigma en mente que se pretende desarrollar el tema de memoria,
basándose en los sistemas “FaceAnimator” y “TreeGrowSimulator”, los cuales consisten
en una aplicación que permite manejar y mover correctamente las especificaciones de
una malla geométrica. Estas mallas pueden representar figuras como rostros humanos
[FaceAnimator], donde se modelan como una malla de puntos de la parte frontal o de la
totalidad de la cabeza, con el fin de poder simular el comportamiento de los rostros
humanos, ya sea en el contexto de una video-conferencia, para representar a la persona al
2
otro lado de la línea sin tener que enviar todo el video, o bien para tener un avatar1 más
realista de un usuario en alguna determinada aplicación. Otra representación posible es el
modelamiento de superficies de troncos de árboles [TreeGrowSimulator], mediante
mallas cilíndricas, esto con el fin de poder simular y estudiar el comportamiento a través
del tiempo de la superficie en función de la concentración de una hormona, la cual se
calcula a través de una ecuación que modela su comportamiento.
1.2 Motivación
La animación de rostros humanos es un tema ampliamente estudiado y de importancia en
distintas áreas de la ciencia, tales como biología y computación gráfica. Diversos trabajos
se han realizado en esta área, en los cuales se aborda el problema desde distintas
perspectivas y dando distintas soluciones según el resultado que se necesita. Esto se debe
a que existen distintos modelos de entendimiento del rostro humano y por ende distintas
maneras de simular su comportamiento. Es por esto que estos modelos de entendimiento
irán evolucionando durante el tiempo, dando por resultado el refinamiento de las técnicas
de simulación, así como también la creación de nuevas técnicas.
Dada esta problemática, el desarrollo de un software de animación de rostros como
“FaceAnimator” está determinado por la complejidad de la elección de alguna técnica en
específico, sesgando el alcance del software así como también su usabilidad. Es por esto
que es indispensable que sistemas como estos permitan la flexibilidad de implementación
de distintas técnicas, según se requiera por el usuario para un resultado específico.
Para poder lograr esto, existe la posibilidad de desarrollar un sistema que contenga todas
las técnicas posibles, pero esto se hace infactible debido a que la cantidad de técnicas va
creciendo año a año. Además el producto nunca alcanzaría la etapa de producción ya que
los tiempos de desarrollo y mantenimiento evolutivo para agregar las nuevas técnicas
aumentarían considerablemente.
Además se agrega la complejidad de que el actual sistema también se puede utilizar para
el modelamiento de otro tipo de problemas, como por ejemplo, la simulación del
crecimiento de ramas de árboles [TreeGrowSimulator], y existen funcionalidades que sólo
sirven exclusivamente para un tipo de malla, la cuales pueden ser mallas de triángulos o
mallas de cuadriláteros, dejando la impresión de un sistema inestable.
1 Avatar: La imagen o icono que simboliza a una persona en relaciones por Internet o entornos
virtuales compartidos.
3
Es por esto que una solución promisoria para este tipo de problemas va por desarrollar
software que siga las bases de la línea de productos de software, las cuales permiten la
reutilización de código u objetos, lo cual permite tener los siguientes beneficios:
• Disminución en los costos del software.
• Disminución en el esfuerzo requerido para la producción del software.
• Incremento en la calidad.
• Disminución en el tiempo de publicación del software al mercado.
• Aumento en la flexibilidad para modificar el software para otros usos y de esta
manera entrar en nuevos mercados.
1.3 Objetivo general
El objetivo general de la presente memoria es la construcción de una interfaz gráfica que
permita al usuario la configuración de las herramientas o funcionalidades a las cuales
quiere tener acceso al utilizar el sistema “FaceAnimator” o “TreeGrowSimulator” o un
visualizador de mallas genérico, esto mediante la ingeniería de línea de productos de
software.
Objetivos específicos
Dentro de los objetivos específicos requeridos para poder lograr la satisfacción del
objetivo general se encuentran:
• Estudiar y analizar los sistemas “FaceAnimator” y “TreeGrowSimulator” así como
también su código fuente.
• Rediseñar la herencias de las clases “MovimientoNodos”, “RegistrationMethod” e
“Interpolator” ya que actualmente sus herencias no están bien reflejadas lógicamente y
no se integran al diseño de clases orientado a objetos que implementan ambas
aplicaciones.
• Determinar los puntos de similitud dentro del diseño de estos sistemas y
asegurarse de que la arquitectura del sistema sea consistente y apropiada. Adaptar la
arquitectura en caso que la existente se encuentre que no es adecuada.
4
• Determinar un conjunto de puntos de variabilidad dentro del diseño de este
sistema para poder encapsularlos dentro de la arquitectura, generando funcionalidades
“reemplazables”.
• Generación de una interfaz gráfica que permita seleccionar entre las distintas
alternativas existentes para poder utilizar el sistema, según las funcionalidades o
herramientas que se necesiten.
• Repetir el ciclo de desarrollo enfocándose gradualmente en implementar los
distintos puntos de variabilidad en el sistema.
1.4 Organización de la memoria
El presente documento esta divido por capítulos, en los cuales se agrupa el contenido
comenzando por una introducción al tema de esta memoria. Se continúa en el capítulo 2
detallando los antecedentes necesarios para una mejor compresión del documento,
donde se encuentra un mejor acercamiento a lo que es el paradigma de “Línea de
productos de software”, la aplicación “S.P.L.O.T.” e información sobre los sistemas en que
se trabajó. Luego en el capítulo 3 se detalla el trabajo realizado, identificando los distintos
pasos que se dieron para el desarrollo y diseño de esta memoria. Los resultados se
pueden apreciar en el capítulo 4, donde se presentan ejemplos y discusiones del resultado
obtenido. Finalmente, en el capítulo 5, se presentan conclusiones y reflexiones del trabajo
realizado y las posibilidades de extensión de este trabajo.
5
Capitulo 2
2. Antecedentes En el siguiente capítulo se exponen las nociones de los distintos temas asociados al trabajo
desarrollado en el presente documento, con mayor detalle. En él se explican temas como
las líneas de producto, o las aplicaciones “FaceAnimator”, “TreeGrowSimulator” y
“S.P.L.O.T.”, de manera de que el lector tenga un antecedentes para comprender la
problemática y el desarrollo del trabajo.
2.1 Línea de producto de software
La producción de bienes se ha ido transformando a través de la historia conforme avanza
la tecnología y la industrialización. En un comienzo, los productos se manufacturaban para
un cliente acorde a sus necesidades específicas. A medida que el poder adquisitivo de los
consumidores fue creciendo, la demanda también. Es en este ambiente donde Henry Ford
concibe lo que se conoce como “Línea de producción”, con la cual consigue producir para
un mercado masivo a menores costos que la producción manual.
En el ámbito de la producción de software también nos encontramos con este modelo,
produciendo lo que se conoce como software estándar. Este desarrollo de un producto de
software presenta la ventaja de disminuir los costos de producción, pero carece en
principio de adaptabilidad. Por otro lado tenemos los softwares desarrollados a medida,
los cuales permiten satisfacer de mejor manera las necesidades de un consumidor en
específico, pero tienen un alto costo.
Aun cuando los consumidores utilizaban el software estándar, sus necesidades no se veían
resueltas completamente con estas herramientas. Fue por esto que la industria comenzó a
incluir las distintas necesidades de los consumidores a su producción. Con esto nace lo
que se conoce como “Customización Masiva” que se define como “La producción a gran
escala de bienes hechos a medida de las necesidades de los clientes” [SPLE05].
Para poder desarrollar este modelo de producción, se necesita poder definir lo que se
conoce como una plataforma, la cual se define a grandes rasgos como “la base
tecnológica en la que otras tecnologías o procesos son construidos” [SPLE05]. En el
ámbito del desarrollo de software, las plataformas se definen como “una colección de
artefactos reusables, como por ejemplo requerimientos, diseño, test, clases, etc.”
6
[SPLE05]. Se refiere entonces a la plataforma como los ladrillos con los cuales construir el
producto deseado. Para conseguir esto, es necesario que la creación de estas plataformas
sea lo suficientemente flexible como para habilitar la construcción de una amplia gama de
productos. Esto se conoce como Variabilidad.
Para que las empresas puedan implementar este modelo de producción exitosamente, se
necesita una organización constante de los procesos y plataformas que desarrollan.
Algunas prácticas que facilitan la adopción de este modelo de producción en el ámbito del
software son:
• Desarrollo Orientado a Objetos (OOP)
• Configuración Tardía
• Buenas metodologías de desarrollo (CMMI)
• Técnicas de Modelamiento (Basadas en UML)
• Conocimiento del dominio del software
Las motivaciones que tienen las empresas para adoptar este modelo, entre otras, son:
Reducir el costo de desarrollo: Estudios independientes indican que aunque el
costo de mantener un sistema basado en líneas de producción requiere de un
costo mayor al comienzo, estadísticamente se observa que a partir del tercer
sistema desarrollado se igualan los costos como si el software fuese producido
desde cero. Desde ahí en adelante los costos de producir un sistema a través de la
Ingeniería de líneas de productos de software son menores que la producción de
aplicaciones bases.
Aumento de la calidad: Al mantener un sistema mediante plataforma, se reutilizan
componentes, con lo cual los errores disminuyen ya que el uso y pruebas de las
distintas componentes aumentan
Disminuye el Time To Market: Debido a la disponibilidad de un sistema base, la
producción de un nuevo sistema requiere menores recursos, tanto monetarios
como en tiempo, permitiendo el desarrollo de un sistema en menor tiempo.
Mejor estimación de costos: Al mantener un sistema base que fue desarrollado
con anterioridad, la producción de un nuevo sistema puede basar sus costos en los
registrados anteriormente; además los desarrollos adicionales son menores y por
lo tanto menos complejos de estimar.
7
Usabilidad: Permite a los usuarios familiarizarse con el uso del sistema, ya que
mantiene funcionalidades en común.
Es así como podemos definir la Ingeniería de líneas de productos de software (LPS o SPL
en ingles) como un paradigma para desarrollar aplicaciones de software utilizando
plataformas y la customización en masa.
2.1.1. Framework
El paradigma de desarrollo propuesto por [SPLE05] se separa en 2 procesos: la Ingeniería
de dominio y la Ingeniería de aplicación. Esto permite separar los esfuerzos en crear una
aplicación robusta y entregar software hechos a medida en un corto tiempo.
Tanto el proceso de dominio como el proceso de aplicación se sub componen de varios
procesos: Requerimientos, Diseño, Implementación y Pruebas. Estos subprocesos siguen
un orden cíclico como se puede apreciar en la siguiente figura:
Figura 2.1.1 - Flujo de Procesos de Dominio y de Aplicación
8
Dentro de este ciclo existe el proceso de “Administración de Producto (Product
Management)”, el cual define el alcance de la familia de productos a desarrollar y generar
la planificación para el futuro de los productos dependiendo de los artefactos que se
encuentran disponibles y los que se requerirán. Esta planificación se conoce como
“RoadMap” u “Hoja de ruta tecnológica”.
Luego, este proceso se conecta con la Ingeniera de requerimientos de dominios, la cual
recibe el roadmap de los productos a desarrollar y busca identificar y describir los
requerimientos que son comunes entre aplicaciones y los que son particulares. Los
productos que genera este proceso son los artefactos conceptuales, como documentos de
requerimientos, donde se estudia la potencial variabilidad de estos requisitos.
El Diseño de dominio busca generar una arquitectura de referencia para la línea del
producto. Para esto es necesario identificar los puntos de variabilidad en la arquitectura,
permitiendo la aplicación o configuración de estas en el futuro. El producto que genera es
un diseño de partes reutilizables.
La Realización de dominio genera la fabricación de componentes independientes para el
uso en distintas aplicaciones. Además debe incorporar opciones de configuración para
soportar la variabilidad identificada. Dentro de los productos de este proceso se
encuentran código fuente, archivos de configuración, makefiles, etc.
Finalmente, dentro del ciclo de la Ingeniería de Dominio, se encuentra las Pruebas de
dominio, donde se verifica que la fabricación de los componentes en la realización del
dominio cumple con lo especificado en el proceso de requerimientos y de diseño. El
producto que genera estos casos de prueba son casos de pruebas detallados y planes de
prueba para cada artefacto.
Con estos artefactos definidos, la Ingeniería de aplicación busca hacer el mayor uso de
estos. Para esto el proceso de Ingeniería de requerimientos de aplicación determina qué
requerimientos de dominio sirven para conseguir la implementación específica
(determinada también por el RoadMap). En este punto si existen requerimientos
específicos que no se encuentren en los de dominio, se debe buscar beneficiar lo general,
para disminuir el esfuerzo de adaptar la aplicación específica.
Luego se continúa con el Diseño de la aplicación, la cual toma el diseño de dominio y hace
las elecciones de variabilidad para la aplicación especifica a construir. Se debe evitar
dentro de lo posible hacer cambios en la arquitectura que signifiquen un esfuerzo igual a
generar la misma aplicación desde cero.
9
A continuación se procede a la configuración de los artefactos seleccionados en el proceso
anterior, denominado como Realización de la aplicación. Se debe mantener una buena
documentación de la configuración seleccionada, ya que permite hacer un seguimiento a
los artefactos seleccionados, facilitando de esta manera la mantención.
Finalmente, las Pruebas de la aplicación se deben documentar y deben referenciar a las
pruebas de dominio.
2.1.2. Principios de Variabilidad
La variabilidad se define en los procesos de dominio, por lo que esto implica que la
variabilidad debe ser administrada: definiéndola, resolviéndola, administrando la
documentación y referencias.
Para poder identificar la variabilidad, primero se debe hacer el ejercicio de formular las
siguientes preguntas:
• ¿Qué es lo que varia?
• ¿Por qué varia?
• ¿Cómo varia?
Esto permite definir el sujeto variable, que es el ítem variable o una propiedad de este.
Como ejemplo, un sujeto de variabilidad es el color en un auto.
Luego se puede definir el objeto variable, el cual es una instancia en particular del sujeto
de variabilidad. Siguiendo con el ejemplo, un objeto variable seria el color rojo.
Es así como en el ambiente de la producción de software, un Punto de variabilidad es
“una o más locaciones donde exista un sujeto de variabilidad”. Luego se conoce como
variante al objeto variable. Para poder identificar los puntos de variabilidad dentro de un
sistema primero hay que identificar el sujeto de variabilidad en el mundo real, luego
identificar el punto variable que represente el sujeto de variabilidad en el dominio y
finalmente definir las variantes posibles.
De esta misma manera se define las semejanzas o “Commonalities” identificando los
puntos que no son variables y que funcionan de la misma manera para toda la familia de
producto. Cabe destacar que la identificación de commonalities precede a la de la
variabilidad.
10
Se pueden distinguir distintos tipos de variabilidad. Una de estas es la variabilidad en el
tiempo. Esta variabilidad se define como “la existencia de diferentes versiones de un
artefacto que son válidos en distintos momentos” [SPLE05]. Esta variabilidad responde a
un proceso natural en los productos de software, la evolución de los sistemas. Un ejemplo
de variabilidad en el tiempo se puede apreciar, continuando con el ejemplo del auto, el
sistema de bloqueo o apertura de las puertas. Actualmente este punto de variabilidad
puede tener las variantes de “Llaves” o “Tarjetas magnéticas” y a medida que la
tecnología avanza, puede tener otras, por ejemplo “Lectores de huella digital”,
“Reconocimiento de Voz”, etc.
Otra definición de variabilidad es la variabilidad en el espacio. Este tipo de variabilidad se
define como “la existencia de un artefacto en diferentes formas en un mismo espacio de
tiempo” [SPLE05]. Un ejemplo de esto puede ser la manera de ingresar texto a un editor
de texto. Se puede hacer mediante “Teclado”, “Voz”, etc. Generalmente, este es el tipo de
variabilidad que más se estudia, debido a que los productos generados desde una familia
de software se comercializan al mismo tiempo.
También se puede definir la variabilidad dependiendo del origen de esta, ya que estas
pueden ser definidas de manera Externa o Interna. La variabilidad Externa obedece a los
cambios percibidos como necesarios por el cliente. Luego se puede definir como “la
variabilidad de artefactos de dominios que es visible a los clientes” [SPLE05]. La causa de
la variabilidad externa generalmente proviene desde necesidades específicas del cliente,
pero a veces puede resultar exigible dado el marco legal de la aplicación. Un ejemplo de
variabilidad externa es el artefacto por el cual se controla el acceso a una puerta. Esta
pueda ser un teclado numérico o/y un lector biométrico, dependiendo de la seguridad que
exija el cliente o las normas dentro del ambiente donde se encuentra este artefacto.
Por otro lado, se puede definir la variabilidad Interna como “la variabilidad de artefactos
de dominio que permanecen escondidos al cliente” [SPLE05]. La causa de la variabilidad
Interna nace al momento de implementar o refinar las variabilidades externas. Esto a su
vez genera más refinamiento, cada vez de más bajo nivel. Como al cliente le interesan los
aspectos del sistema de más alto nivel, es necesario “esconder” ciertos puntos que no
ayudan a la utilización ni comercialización del producto, ya que lo hacen más complejo. Un
ejemplo de esto puede ser dado un lector de huellas digitales, saber qué tipo de
almacenamiento y algoritmos de compresión utiliza el sistema para almacenar las
imágenes.
Es necesario destacar, que entre más variabilidades externas se definan mayor va a ser el
número de variabilidades internas definidas, creciendo en lo que se conoce como un
modelo piramidal, ya que por cada variabilidad externa necesariamente se debe refinar a
11
una o más variabilidades internas, las cuales a su vez pueden ser refinadas hasta llegar a
niveles más bajos de abstracción. Es por esto que es importante mantener al mínimo las
variabilidades externas ya que estas traen consigo un aumento de la complejidad y los
costos de los sistemas.
2.2. S.P.L.O.T.
[S.P.L.O.T.] (http://www.splot-research.org/) es un sistema web Opensource
desarrollado en Java que permite crear un modelo altamente interactivo de razonamiento
y configuración de productos.
El sistema está orientado a la utilización por parte de académicos y practicantes del
paradigma de [SPL], entregando una herramienta poderosa que permite analizar y
configurar modelos de decisión basados en características de los productos y
modelándolas a través de clausulas lógicas, como se puede ver en la figura 2.2.1.
Esta herramienta contiene implementados eficientes sistemas de razonamiento y
heurísticas de resolución de problemas SAT2, lo que permite contar
configuraciones válidas y calcular el grado de variabilidad de las características de los
productos.
Actualmente [S.P.L.O.T.] proporciona dos funcionalidades: el razonamiento automático y
la configuración de un catálogo de productos. El razonamiento automático se enfoca
principalmente en automatizar los cálculos estadísticos (por ejemplo, la profundidad de
los árboles de características, cantidad de características) así como también en tareas
críticas de depuración, como la comprobación de la coherencia de los modelos y la
detección de la presencia de características muertas (nunca podrán seleccionadas).
Además el sistema entrega más información como la cantidad de configuraciones
permitidas y el grado de variabilidad del modelo.
2 SAT: Problema de satisfacibilidad booleana. Es un tipo de problema de complejidad Np-completo.
12
Figura 2.2.1 Creación de clausulas lógicas en forma CNF
Con respecto a la configuración del producto, el sistema cuenta con la funcionalidad de
generar una configuración de un producto de manera interactiva a través de la toma de
decisiones por parte de los usuarios y la autoconfiguración que genera el sistema
propagando las reglas definidas. Por ejemplo, si la configuración de un automóvil
considera el motor como punto de variabilidad y sus variantes son “Eléctrico” y
“Mecánico”, al seleccionar la opción “Eléctrico” todas las variantes y puntos de
variabilidad que no correspondan (según las reglas definidas en clausulas lógicas) se
desactivaran automáticamente. Un ejemplo de esto se puede apreciar en la figura 2.2.2, la
cual permite seleccionar las distintas partes para armar una bicicleta según las opciones
que da el fabricante.
13
Figura 2.2.2 Configuración de producto de modelo de bicicletas TREK
También el sistema cuenta con la ventaja de que tiene propagación retroactiva, lo que
permite que no se tenga que volver sobre decisiones pasadas.
Esta herramienta cuenta con un repositorio gratuito y abierto que permite almacenar los
modelos generados (archivos XML).
Estas características fueron las principales ventajas identificadas para optar por este
sistema para especificar la variabilidad del sistema. Esto sobre algunas notaciones para
documentar la variabilidad como los propuestos en [FODA], los cuales permiten expresar
las distintas componentes de buena manera, pero carecen de componentes interactivos
como el de [S.P.L.O.T.]. Además se necesita tener conocimiento técnico de las sintaxis de
las expresiones. Existen también herramientas parecidas a [S.P.L.O.T.] como [FAMAFW] o
[XFEATURE], los cuales necesitan de una inscripción previa y/o son programas que se
descargan al computador.
La herramienta provista por [S.P.L.O.T] fue seleccionada para la descripción de los puntos
de variabilidad del sistema, permitiendo mantener en un repositorio centralizado las
especificaciones del sistema y de fácil acceso.
14
2.3. TreeGrowSimulator
El sistema [TreeGrowSimulator] fue desarrollado en la Universidad de Chile, por la
profesora Nancy Hitschfeld y un equipo de memoristas. Este sistema sirve como base para
la implementación de [FaceAnimator], ya que utilizan la misma arquitectura y
herramientas de computación gráfica.
Este software sienta las bases para el desarrollo de la presente memoria, ya que en él se
encuentran implementadas las clases bases (artefactos) que permiten sentar una
plataforma base en la cual construir una aplicación que trabaje con mallas geométricas.
Este sistema fue desarrollado en C++, y su objetivo principal (como lo indica su titulo) fue
el estudio del crecimiento de troncos de árboles provocado por la aplicación de una
hormona. Existe la funcionalidad de ver paso a paso los cambios en la corteza del árbol o
ver los cambios de forma continua.
Este sistema contiene muchas funcionalidades genéricas y extensibles, como la de cargar
una malla geométrica y visualizarla desde diferentes ángulos y distancias. Las mallas
pueden estar compuestas por triángulos o cuadriláteros.
Originalmente, el sistema permite cargar mallas de formatos definidos: Comsol, Matlab,
nxyzu, Geomview.
Otras funcionalidades genéricas son la de refinar, desrefinar y mejorar la malla cargada.
Estas funcionalidades se implementan con la aplicación de algoritmos, que en el caso de
refinar y desrefinar se pretende aumentar o disminuir la cantidad de puntos que
conforman la malla. En el caso de mejoramiento, está disponible el criterio de Delaunay
para mejorar una triangulación.
Dentro de las funcionalidades especificas de este sistema, se encuentra la deformación de
malla, la cual permite generar el movimiento del crecimiento de una rama de un árbol a
partir de la concentración de hormona moviendo cada nodo según la dirección de la
normal del punto. También permite crear una malla cilíndrica que modela la corteza del
tronco de un árbol.
2.4. FaceAnimator
El sistema [FaceAnimator] estuvo inmerso dentro de un proyecto de mayor envergadura,
que involucra a equipos de trabajo de la Universidad Nacional de Rosario, en Argentina y
del INRIA Nancy - Grand Est, en Francia. Este proyecto global tuvo como nombre BAVI:
Bio-inspired Audio/Visual Information Integration, que involucra el descubrimiento de
características de movimiento humano a través de un enfoque bio inspirado por parte del
15
equipo francés, junto a la participación del equipo argentino, mediante la extracción de
parámetros de movimiento a partir de información auditiva.
Este sistema basado en la implementación de [TreeGrowSimulator], mejora y adapta el
sistema para un nuevo objetivo, el cual es la visualización de rostros humanos. Durante el
trabajo desarrollado en este sistema, se agregaron funcionalidades específicas para la
manipulación de rostros y también se hicieron mejoras a las funcionalidades ya existentes.
Dentro de las funcionalidades existentes anteriormente, se tuvo que eliminar algunas
funcionalidades especificas para el manejo de crecimiento de hormonas en cortezas de
arboles.
Las nuevas funcionalidades agregadas exigieron cambios en la arquitectura del sistema,
agregando nuevas clases y modificando clases bases para poder implementar la
visualización de rostros. Como ejemplo, se tuvo que agregar textura a las clases bases para
construir mallas geométricas.
También se tuvo que habilitar la carga de mallas específicas, ya que las mallas geométricas
que soportaba el sistema no incluían los formatos que tienen las mallas que representan
rostros. Para manipular de buena manera los rostros se agregó la funcionalidad de “calce”
de puntos entre la malla cargada y una malla estándar que permite aplicar movimiento de
manera más fácil. Así se agregó un menú que permite mover puntos del rostro
previamente definidos (en base a la plantilla “Candide-3” [Candidade3]). Esto permitiría
generar deformaciones a los rostros. Para poder guardar estas deformaciones y poder
cargarlas nuevamente, se especificó un archivo que contiene las instrucciones de
deformaciones. Luego este archivo se puede cargar para que los movimientos sean leídos
por la aplicación todos de una vez y genere las deformaciones sobre el rostro para ser
visualizadas paso a paso o en forma continua.
Además de estas nuevas funcionalidades, el sistema mantiene las funcionalidades
genéricas como las de refinar, desrefinar y mejorar la malla. Así también permite ver los
vértices sin texturas o con texturas y ver información estadística de la malla geométrica.
16
Capitulo 3
3. Diseño e Implementación En el presente capitulo se describen los pasos llevados a cabo para la ejecución de la
solución planteada según los objetivos a cumplir, desde la instalación del código fuente de
la aplicación [FaceAnimator], el rediseño de clases, hasta la utilización de la aplicación
[S.P.L.O.T] para identificar las variabilidades de la aplicación, permitiendo el desarrollo
completo de la solución final, llamada “Meshing Tool Generator”.
3.1 Actualización librerías
El primer trabajo llevado a cabo en esta memoria, fue instalar el código fuente de ambos
programas [FaceAnimator] y [TreeGrowSimulator] debido que fue necesario examinar el
código de ambas aplicaciones. Para efectos de todos los cambios en el código fuente se
eligió modificar el código fuente de la aplicación [FaceAnimator] ya que su
implementación es más reciente y mantiene el código de la aplicación
[TreeGrowSimulator] pero no es utilizado. Los requisitos para la instalación, además de
las básicas del lenguaje C++, son:
gtkmm
gtkglextmm
gsl
geomview
Una vez instaladas estas librerías, se compiló el sistema sin éxito, ya que existían
problemas con las librerías instaladas. El depuramiento del código fuente permitió
identificar que la librería libsigc++ se encontraba en una versión mayor que en la que fue
desarrollado en primera instancia el sistema. Al no saber la versión con la cual el sistema
era estable, se procedió a actualizar el sistema a la nueva librería. Esta librería permite la
llamada de funciones callback mediante la asignación de señales a distintos eventos. La
versión de la librería actualizada es 2.0. Los cambios necesarios para que el sistema
pudiese compilar con éxito fueron:
17
Se comentó la inclusión del header #include
<sigc++/compatibility.h> ya que en esta nueva versión no se utiliza.
Se cambiaron las apariciones de SigC::slot por sigc::mem_fun .
Además se tuvo que incluir algunos headers que en algunas clases no permitían la
ejecución de la aplicación, la lista de errores y su solución se detallan a continuación:
numeric_limits not defined : Hacer include de #include <limits>.
Fopen not declared: Hacer include de #include <stdio.h>.
Find not declared: Hacer include de #include<vector>
#include<iterator>
#include<algorithm>
#include<iostream>
Con estos cambios, se pudo ejecutar la aplicación exitosamente.
3.2 Rediseño de clases
Otro de los objetivos iniciales de esta memoria era la de corregir la estructura de ciertas
clases que no se encontraban bien diseñadas con respecto al modelo orientado a objetos
y el ideal discutido en el punto 3.2.1. Aun cuando funcionalmente estas clases están bien
implementadas y proporcionan un buen funcionamiento a las aplicaciones, lógicamente y
conceptualmente sus dependencias no son correctas. A continuación se presenta el
diagrama de clases inicial de la aplicación [FaceAnimator], para luego continuar con la
explicación de los cambios realizados sobre este diagrama para poder conseguir un diseño
de clases consistentes con los ideales perseguidos.
3.2.1. Diseño General
El diseño de la aplicación [FaceAnimator] se construyó a partir del diseño de otras
aplicaciones con funcionalidades similares. En efecto, [FaceAnimator] es el resultado de
un trabajo basado en la aplicación [TreeGrowSimulator]. Aún cuando los problemas que
intentan resolver ambas aplicaciones son de naturaleza distinta, utilizan herramientas
comunes para su resolución, ya que básicamente son aplicaciones capaces de manipular
mallas geométricas compuestas por triángulos o cuadriláteros. Es el buen diseño de esta
base lo que permitió poder expandir y/o reemplazar las funcionalidades de un sistema en
18
pos de conseguir el otro. El diseño de esta aplicación se baso en perseguir las ventajas que
se consiguen al tratar de implementar el paradigma de líneas de productos.
El diseño básico comienza con la primera abstracción, la cual es la clase “Malla” que es el
punto común de las aplicaciones. Para esto también se implementaron las clases “Nodo”,
“Arco” y “Cara” que permiten construir una malla y operar sobre esta. La estrategia
utilizada se pensó para que se pudiese construir una malla inicial según distintos criterios,
como la geometría de la malla, la densidad de esta, y la posible aplicación de algoritmos
de refinamiento o mejoramiento sobre esta malla [MeshTools2005]. Dado que pueden
existir distintas implementaciones para cada uno de estos pasos, se diseñaron como clases
separadas entre sí, como por ejemplo dada la definición la clase “Triangulo”, un posible
diseño era el de implementar como método de esta clase las estrategias de refinamientos
o como un componente separado de esta clase. Se eligió esta segunda estrategia
principalmente por 2 razones [MeshTools2005]:
Existen varias maneras de implementar el mismo proceso
y se requiere que sean intercambiables
La aplicación final debe ser extensible a fin de ser capaces de generar nuevas
miembros de la familia mediante la incorporación de nuevas estrategias y criterios
y hacer muy pocas modificaciones al código fuente.
Como se puede ver en la figura 3.2.1, el diseño final es un diseño modular donde se
implementa una gran cantidad de interfaces, lo que permite intercambiar la
implementación final de los distintos algoritmos. Como por ejemplo, se puede ver que la
clase “Comando” es una interfaz que permite la ejecución de métodos sobre el objeto
malla, haciendo transparente e independiente la implementación de esta con la de los
algoritmos. Dentro del diseño se pueden apreciar distintas interfaces para distintos
objetivos, como la de deformar la malla, guardar la malla en algún formato establecido o
ver información de la malla, entre otros. Estas interfaces a su vez instancian interfaces
hijas hasta llegar a las diferentes implementaciones de las opciones de los algoritmos o
criterios que puede a llegar a tener uno de estos comandos.
19
Figura 3.2.1: Diagrama de clases [FaceAnimator].
20
3.2.2. Modificación de Clases
Aun cuando la gran mayoría del diseño se mantuvo con la estrategia comentada en el
punto 3.2.1, existen casos en que la implementación de funcionalidades específicas para la
aplicación [FaceAnimator] no siguió la estrategia ideal. En el caso de la clase
“MovimientoNodos” (Figura 3.2.2), la cual es una interfaz para la implementación de
movimiento de nodos según distintos métodos, su ubicación en el diseño es
conceptualmente errónea ya que se puede apreciar que depende directamente de la clase
“Malla”, siendo que ya existe una clase que funciona como interfaz de movimientos de
nodos, en especifico de mallas de triángulos, la clase “AlgDesplazamientoMallaTriangulo”.
Es por eso que se eliminó y colgaron sus hijos directamente de
“AlgDesplazamientoMallaTriangulo”, como se puede ver en la figura 3.2.3. Para poder
lograr esto se debió modificar parte de la clase malla, la cual implementaba el método
“moverNodosSegunParametro”, donde se hacía inclusión de la clase
“MovimientosFromFile” directamente. Luego para poder incluir esta clase como clase hija
de “AlgDesplazamientoMallaTriangulos” se debió declarar este método en esta clase de
manera virtual, y la implementación se hizo en todos los hijos. Esto permitió “desacoplar”
la clase “MovimientosFromFile” de la clase Malla ya que generaba una dependencia
circular al tratar de definirla directamente como clase hija de
“AlgDesplazamientoMallaTriangulos”.
Figura 3.2.2: Dependencia original de la clase MovimientosNodos.
21
Figura 3.2.3: Diseño final de dependencia de clase AlgDesplazamientoMallaTriangulos
Las otras clases que necesitaban modificación eran las clases “RegistrationMethod” e
“Interpolator”, ya que estas no se insertaban dentro del diseño general y no dependían de
ninguna clase padre, como se aprecia en la figura 3.2.4. Ambas clases son utilizadas para
generar un “calce” entre la malla de rostro seleccionada y una malla de rostros estándar,
lo que permite generar movimientos en esta malla. Dado que estas clases son especificas
para la aplicación [FaceAnimator] su dependencia no puede ser directa a una clase base
de la aplicación. Por esta razón se crea una nueva clase padre, llamada
“GenerarMallaInicial”, la cual contiene como hijos a las clases “RegistrationMethod” e
“Interpolator”, como se puede ver en la figura 3.2.5. Esta clase reemplaza a la clase
Generar y absorbe todos sus hijos. La idea de esta clase es crear un método virtual que
genera la malla inicial con la que se va a trabajar, permitiendo utilizar las clases necesarias
según el tipo de malla escogida.
Figura 3.2.4: Clases sueltas sin dependencias en la arquitectura
22
Figura 3.2.5: Diseño final de herencia de clase GenerarMallaInicial
El diagrama de clases final se puede apreciar en el apéndice A.
3.3 Definición de Variabilidades
Para poder desarrollar una aplicación que permitiera “configurar” las opciones que
tendría la aplicación a generar, primero se debió identificar estas “opciones” o puntos de
variabilidad. Utilizando la herramienta provista por [S.P.L.O.T.] esta definición se pudo
hacer de manera transparente, en base a las actuales funcionalidades de las aplicaciones
[TreeGrowSimulator] y [FaceAnimator]. La idea inicial era poder incluir las commonalities
o funcionalidades en común que presentaban ambas aplicaciones y que se entiende que
son bases para la familia de productos que se quiere construir, una aplicación que sea
capaz de manejar mallas geométricas y que a la vez pueda ser extensible para aplicaciones
específicas como lo son [TreeGrowSimulator] y [FaceAnimator]. Dada las limitaciones
propias del presente trabajo, tanto la identificación como la implementación de estas
variabilidades no son definitivas, ya que no se considera la variabilidad en el tiempo que
pueden tener estos sistemas, solo considerando las actuales funcionalidades presentes.
Los puntos de variabilidad identificados construyen el total de la aplicación, estos puntos
se explican a continuación, con el detalle de cada variante:
23
Algoritmo de refinamiento: Algoritmo que permite refinar la malla geométrica, aumentando la cantidad de puntos que la construyen. Sus posibles opciones (variantes) son :
o DELAUNAY LONGEST EDGE BISECTION
o LEPP-DELAUNAY
Algoritmo de deformación: Presenta funcionalidades que permiten generar movimientos de conjuntos de puntos en la malla geométrica, las opciones (o variantes) actuales son:
o CREAR ANIMACIÓN
o CREAR DEFORMACIÓN DESDE ARCHIVO CD3
Opciones de Visualización: Presentan funcionalidades que actúan sobre la visualización de las mallas geométricas de manera específica para cada aplicación, sus variantes son.
o ACTIONUNITS
o CONCENTRACIÓN HORMONA
Aplicaciones Específicas: Funcionalidad especifica que se aplican sobre la malla para fines específicos de cada aplicación, sus variantes actuales son:
o DISTRIBUCIÓN DE HORMONA
Idioma: Idioma en cual los mensajes y las interfaces graficas son presentadas, sus variantes son:
o INGLES
o ESPAÑOL
Algoritmo de desrefinamiento: Algoritmo permite componer las mallas en menos puntos. Sus variantes son:
o ÁREA MÍNIMA
o LARGO ARCO MÍNIMO
Algoritmo de Mejoramiento: Algoritmo para mejorar la composición de las mallas, actualmente existe una sola variante implementada:
o EDGE-COLAPSE
Manejo de Archivos: Herramientas que permiten seleccionar las distintas acciones para manejar archivos de mallas geométricas, sus variantes son:
o GUARDAR
o ABRIR : Si esta variante es seleccionada, se debe seleccionar el tipo de archivo a abrir, sus variantes son:
24
MATLAB
OFF
TXT
WRL
CMS_1
Algoritmo de Malla Inicial: Esto permite seleccionar al algoritmo que se aplica a la malla que se genera al momento de abrir un archivo.
o REGISTRATION METHOD
o DUMMY ALGORITHM
Características de Visualización: Distintas funcionalidades que permiten visualizar información sobre la malla.
o MOSTRAR CARAS
o MOSTRAR ARCOS
o MOSTRAR ESTADISTICAS MALLA
o BORRAR MALLA
Modificación de Geometría: Permite cambiar la geometría de una malla.
o TRIANGULAR
o CUADRANGULAR
Junto con la definición de variabilidades, los commonalities o puntos en común que se
mantendrán en toda la familia de productos son los siguientes:
Algoritmo de refinamiento: Se debe seleccionar un algoritmo de refinamiento para aplicar sobre la malla.
Idioma: Se debe seleccionar un idioma para la aplicación
Abrir: Se debe seleccionar al menos una opción de formato para poder abrir una malla y trabajar sobre esta.
Algoritmo de Malla Inicial: Se debe seleccionar un algoritmo de malla inicial para poder cargar la malla.
Nombre Aplicación: Se debe asignar un nombre a la aplicación.
25
Una vez definidos los puntos de variabilidad, se definieron las reglas lógicas que permiten excluir o
incluir puntos variables en base a los seleccionados anteriormente. Como ejemplo, si se selecciona
que se utilizará el formato de archivo OFF, esto excluye la utilización de la aplicación de
Registration Method al momento de generar la malla inicial.
Para generar estas reglas lógicas, se utiliza a través del sistema [S.P.L.O.T.] la herramienta “Create
Constraint” donde se selecciona las funcionalidades relacionadas. Existen básicamente 2 reglas
lógicas, de exclusión y de inclusión:
Exclusión: Si la funcionalidad A excluye a la funcionalidad b, se debe definir una regla lógica como : ~A V ~B
Inclusión: Si la funcionalidad A requiere de la funcionalidad B, se debe definir la siguiente regla lógica: ~A V B
Las reglas lógicas que se generaron en base a las funcionalidades identificadas son (Figura 3.3.1):
Si se selecciona algún formato de archivo a abrir, distinto de WRL, se excluye el uso de REGISTRATION METHOD.
Si se selecciona alguna la opción de Algoritmo Deformación, se incluye el uso del formato WRL, y se excluye el resto.
Si se DISTRIBUCION DE HORMONA, se excluye el formato WRL, además de incluir CONCENTRACION DE HORMONA.
Figura 3.3.1: Reglas lógicas definidas en la aplicación S.P.L.O.T.
26
El archivo fuente de modelo actual se encuentra en el Apéndice F. Este archivo se encuentra en
formato SXFM3, el cual se puede cargar a la herramienta ingresando el archivo SXFM mediante una
URL.
3.4 Generación de aplicaciones específicas en base a
configuraciones
Uno de los objetivos del presente trabajo era el desarrollo de una interfaz que pudiese
permitir elegir la configuración de las funcionalidades presentes en el software a
construir. Se hará referencia a esta interfaz como la aplicación Meshing Tool Generator,
ya que su fin es la de construir aplicaciones especificas para el manejo de mallas
geométricas.
Meshing Tool Generator es una aplicación sencilla que permite a través de un menú
seleccionar las variantes para cada punto variable. Luego con los valores seleccionados el
programa genera un archivo llamado “build_option.txt”, en el cual se encuentran las
instrucciones para construir la aplicación que se desea. Como se puede apreciar en la
figura 3.4.1 este archivo se utiliza tanto en el momento de compilación como el momento
de ejecución de la
aplicación.
Figura 3.4.1: Flujo de construcción de aplicación en base a archivo de configuración
3 Simple XML Feature Model http://gsd.uwaterloo.ca:8088/SPLOT/sxfm.html
Meshing Tool
Generator
build_op
tion.txt MakeFile
Aplicación
27
El archivo “build_option.txt” es un archivo de texto plano donde cada línea refiere a un
punto variable, en la cual se escribe el valor de cada variante. La estructura y la lista de
valores que se aceptan se encuentran en el Apéndice C.
Una vez creado el archivo, la aplicación Meshing Tool Generator ejecuta el makefile el
cual recibe como parámetro de entrada el archivo “build_option.txt” y permite compilar
utilizando solo las clases que se necesitan según las variantes seleccionadas. Un ejemplo
de un makefile que utiliza esta estrategia se puede encontrar en el Apéndice E.
Actualmente muchos puntos de variabilidad se implementan directamente en una sola
clase o su actual diseño no permite separar la implementación al momento de compilar.
Por esto fue necesario modificar el código fuente para que fuese capaz de leer el archivo
“build_option.txt” y pudiese configurar la aplicación según lo especificado. Para lograr
esto, se necesitó estudiar el código fuente de las aplicaciones [TreeGrowSimulator] y
[FaceAnimator] para lograr identificar dónde se implementaba las variantes para los
distintos puntos variables.
En el presente trabajo sólo se modifico el código fuente de la aplicación [FaceAnimator] y
se le agregó la opción de deformación CREAR ANIMACIÓN que no se encontraba
implementada en esta aplicación pero sí en [TreeGrowSimulator]. Solo faltó traspasar la
implementación del algoritmo de aplicación DISTRIBUCIÓN DE HORMONA, por lo que la
selección de esta variante no está disponible aún. Tampoco está disponible la selección de
variantes de Idioma.
28
Capitulo 4
4. Resultados En el siguiente capítulo se encuentran imágenes que muestran el resultado del trabajo
realizado para esta memoria. En él se puede verificar las distintas estadísticas del
resultado del modelo de variabilidad propuesto en la herramienta [S.P.L.O.T.], así también
se puede apreciar el resultado final de la aplicación “Meshing Tool Generator”, donde se
muestra como se produce una versión de la aplicación [FaceAnimator], según distintos
parámetros escogidos. Finalmente se presenta una pequeña discusión de los resultados
obtenidos en comparación con los objetivos propuestos.
4.1 Herramienta de visualización de Variabilidad
La herramienta [S.P.L.O.T.] nos permite acceder vía web al repositorio donde se
encuentra almacenado el modelo generado. Su edición también es online y es abierta a
cualquier persona. Para editar el modelo se debe acceder a la herramienta de edición de
modelo (http://gsd.uwaterloo.ca:8088/SPLOT/feature_model_edition.html) y buscar el
modelo bajo el nombre “Faceanimator”.
El análisis automatizado del modelo actual generado por la aplicación es el siguiente:
De manera de ejemplo, se crearon 2 versiones de la aplicación [FaceAnimator] para poder
contrastar las distintas configuraciones posibles.
Versión A: Figura 4.2.3, 4.2.5, 4.2.7 y 4.2.9.
Solo tiene la opción de abrir mallas geométricas
Los formatos aceptados son MATLAB, OFF y CMS_1
No ejecuta “REGISTRATION METHOD” al momento de abrir una malla
El algoritmo de refinamiento es el de “LEPP-DELAUNAY”
El criterio de des refinamiento es de “LARGO ARCOS MINIMO”
34
Permite mostrar las caras de las mallas
Existe solo la opción de “TRIANGULAR MALLAS”
Existe la opción de mostrar “ESTADISTICAS DE LA MALLA”
No permite ejecutar el algoritmo de mejoramiento
El archivo de configuración build_options.txt que genera la aplicación es el siguiente:
FaceAnimator -- Nombre de la aplicación
LEPP –- Variantes de Algoritmo de refinamiento
NULL –-Variantes de Algoritmo de deformación
NULL –-Variantes de Opciones de Visualización
NULL -–Variante de algoritmo de Mejoramiento
ARCO -–Variante DESREFINAR de Algoritmo de desrefinamiento
NULL -–Variante GUARDAR de Manejo de archivo
MATLAB -–Variante MATLAB de Formatos a abrir
OFF –-Variante OFF de Formatos a abrir
NULL –-Variante TXT de Formatos a abrir
NULL –-Variante WRL de Formatos a abrir
CMS -–Variante CMS_1 de Formatos a abrir
NULL --Variantes de Algoritmos Malla Inicial
CARAS -–Variante CARA de Características Visualización
NULL -–Variante ARCOS de Características Visualización
INFO -–Variante INFORMACION de Características Visualización
NULL -–Variante ELIMNAR de Características Visualización
TRIANG -–Variante TRIANGULACION de Modificación Geometría
NULL -–Variante CUADRANGULAR de Modificación Geometría
Versión B: Figura 4.2.4, 4.2.6, 4.2.8, 4.2.10.
Tiene las opciones de abrir mallas geométricas
Los formatos aceptados son WFM y WRL
Ejecuta “REGISTRATION METHOD” al momento de abrir una malla
El algoritmo de refinamiento es el de “DELAUNAY LONGEST EDGE BISECTION”
El criterio de des refinamiento es de “AREA CARA MINIMA”
Permite las opciones de “TRIANGULAR” y “CUADRANGULAR”
Permite la opción de ejecutar el algoritmo de mejoramiento “EDGE-COLAPSE”
Permite “MOSTRAR ARCOS”
35
El archivo de configuración build_options.txt que genera la aplicación es el siguiente:
FaceAnimator -- Nombre de la aplicación
DELAUNAY –- Variantes de Algoritmo de refinamiento
CD3 –-Variantes de Algoritmo de deformación
AU–-Variantes de Opciones de Visualización
MEJORAR -–Variante de Algoritmo de Mejoramiento
AREA -–Variante DESREFINAR de Opción de Algoritmo de desrefinamiento
NULL -–Variante GUARDAR de Manejo de archivo
NULL -–Variante MATLAB de Formatos a abrir
NULL –-Variante OFF de Formatos a abrir
NULL –-Variante TXT de Formatos a abrir
WRL –-Variante WRL de Formatos a abrir
NULL -–Variante CMS_1 de Formatos a abrir
REG --Variantes de Algoritmos Malla Inicial
CARAS -–Variante CARA de Características Visualización
ARCOS -–Variante ARCOS de Características Visualización
INFO -–Variante INFORMACION de Características Visualización
NULL -–Variante ELIMNAR de Características Visualización
TRIANG -–Variante TRIANGULACION de Modificación Geometría
CUAD -–Variante CUADRANGULAR de Modificación Geometría
Figura 4.2.3: Versión A, solo se permite abrir formatos MATLAB, OFF y CMS_1
36
Figura 4.2.4: Versión B, solo se permiten los formatos WFM y WRL
Figura 4.2.5: Versión A, se permiten mostrar caras y controlar la deformación de animación.
37
Figura 4.2.6: Versión B, Se permite ver caras y arcos además de la estadística de la malla.
Figura 4.2.7: Versión A, al presionar deformar ejecuta la deformación de animación.
38
Figura 4.2.8: Versión B, al cargar la malla se ejecuta Registration Method.
Figura 4.2.9: Versión A, solo se presenta el algoritmo de des refinamiento “Largo Arcos Mínimos”
39
Figura 4.2.10: Versión B, solo se presenta el algoritmo de des refinamiento “Área Cara Mínima”.
La aplicación actual no tiene implementado la selección de variantes del punto de
variabilidad “Idioma” (Inglés, español) y tampoco tiene implementado la selección del
punto de variabilidad Algoritmos de aplicación (Distribución Hormona).
4.3 Discusión de resultados
Los resultados obtenidos cumplen parcialmente los objetivos trazados, principalmente
debido a que la arquitectura de la aplicación [FaceAnimator] no permite la separación de
sus componentes de manera de que estos sean independientes y puedan ser compilados
restando clases según la configuración elegida. Un ejemplo de esto sucede cuando se
requiere compilar las clases asociadas al algoritmo de refinamiento, donde básicamente
existen dos clases leppdelaunay.cpp y
delaunaylongestedgebisection.cpp. Al tratar de compilar sin una de estas
clases, la clase fabricaalgoritmosmallatriangulos.cpp arroja un error ya que
dentro de su implementación utilizan directamente los constructores de ambas clases.
Este tipo de problemas también se pudo apreciar al momento de modificar las herencias
de la clase movimientosFromFile.cpp ya que se detectó que en la clase
malla.cpp existen muchos métodos, que sus funcionalidades son principalmente las
40
transformaciones a la malla, que se implementan directamente a esta clase y para esto
requieren la utilización de objetos directamente en la clase, lo que conlleva incluir estas
clases directamente en la clase malla. Para este caso en específico el problema era el
método moverNodosSegunParametro, el cual se implementaba en la clase
Malla.cpp. Para poder sacar esta dependencia de la clase
movimientosFromFile.cpp, se implemento el método dentro de esta clase, con la
diferencia de que el método ahora recibe un puntero a la malla y luego se aplica el
movimiento sobre esta. Existen al menos una transformación mas que no debiese ir en la
clase malla, el método moverNodosSegunConcentracion que se encuentra
implementado en esta clase bajo el comentario de “Tranformaciones”, ya que no es
genérica y las transformaciones no debiesen estar implementada ahí, aun cuando no
genere una dependencia innecesaria, ya que utiliza la clase nodo, la cual se utiliza en otros
métodos.
Además de este tipo de problemas, se encontró que para poder reflejar las
configuraciones escogidas para la aplicación a generar, se necesita modificar la
construcción de los menús para que no aparezcan disponibles cuando no se seleccionan.
Esto es debido a que actualmente la construcción de la interfaz principal del programa se
hace en una sola clase (GUIVentanaPrincipal_glade.cc) lo que hace necesaria
la estrategia de leer los parámetros al momento de ejecución para saber cuál es la
configuración de menús a mostrar. Se tiene también que esta clase adjunta eventos a los
menús asociados y estos eventos están implementados principalmente en 2 clases
GUIVentanaFaceModeling.cc y GUIVentanaTreeGrowth.cc. Actualmente
solo se utiliza una clase (GUIVentanaFaceModeling), ya que se debe instanciar al
comienzo para generar la interfaz principal, dejando afuera la implementación de algunos
eventos propios de la clase GUIVentanaTreeGrowth.
La consecuencia de estos problemas son dos: primero que hace necesario la inclusión de
la mayoría de las clases al momento de compilar la aplicación, dejando aplicaciones con
implementaciones iguales, que solo cambian en la organización del menú. El segundo
problema es que necesariamente el programa a ejecutar necesita un archivo con
parámetros para saber qué elementos del menú mostrar, lo cual aumenta la complejidad
y disminuye su robustez ya que permite que este archivo sea modificado, afectando
directamente en la ejecución de la aplicación.
Aún cuando existen estos problemas, el objetivo general se pudo cumplir, generando una
aplicación que permite configurar las aplicaciones, aún la construcción de la aplicación
según las opciones seleccionadas suceda solo a nivel de la construcción del menú y no de
la compilación de clases.
41
Capitulo 5
5. Conclusiones y trabajo futuro
El presente trabajo permitió lograr un primer acercamiento a la generación de una familia
de productos para los sistemas [TreeGrowSimulator] y [FaceAnimator]. Aun cuando el
resultado no ha sido ideal, se ha podido hacer tangible cuáles son los topes para poder
generar aplicaciones a partir de la configuración de opciones presentes en éstas. Es
entonces importante el trabajo realizado en cuanto a que es un primer paso para generar
un sistema más completo para la definición e implementación de variabilidades sobre
estos sistemas.
El trabajo futuro sobre esta aplicación se puede dividir en dos áreas principalmente, una
es la extensibilidad de la aplicación “Meshing Tool Generator” y la otra es la de la revisión
e implementación de mejoras en las clases que componen la estructura de las aplicaciones
[TreeGrowSimulator] y [FaceAnimator]. En detalle las extensiones posibles para el
presente trabajo son:
Adición de las funcionalidades que no se encuentran implementadas en la
aplicación [FaceAnimator] que existen en [TreeGrowSimulator], de manera de
dejar un solo código fuente que implemente todas las funcionalidades, para poder
hacer la implementación de todas las variantes de los puntos variables.
Revisar la arquitectura de las clases que implementan los distintos puntos de
variabilidad y modificarlos de manera que no exista una dependencia innecesaria
con las clases que son candidatas a ser retiradas de la compilación si es que no son
necesarias para las funcionalidades de la aplicación.
Rediseñar y re implementar las clases asociadas a la interfaz gráfica de la
aplicación [FaceAnimator] ya que para poder adaptar las opciones seleccionadas a
la interfaz del usuario al momento de compilar, es necesario que los distintos
puntos de variabilidad tengan sus variantes gráficas implementadas en clases
distintas.
Implementación de los puntos variables pendientes al momento de seleccionarlos
en la aplicación “Meshing Tool Generator”. Estos puntos de variabilidad son
algoritmo de aplicación, para el cual hay que traer la funcionalidad de distribución
42
de hormona desde la aplicación [TreeGrowSimulator] a [FaceAnimator] y
modificar el código fuente para que aparezca esta opción sólo cuando es
seleccionada. El segundo punto de variabilidad es el idioma, el cual debe ser
implementado ya que actualmente no existe una diferenciación o configuración de
idioma para los mensajes y títulos de la aplicación. Actualmente el idioma es
español.
Proveer una lectura del archivo XML o CVS (que se puede descargar del catálogo
de producto en la herramienta [S.P.L.O.T.], una vez seleccionados todas las
funcionalidades requeridas (ver Apéndices D y E) en la aplicación “Meshing Tool
Generator” que cargue la configuración directamente, ahorrando tiempo ya que
no es necesario re implementar la interfaz de “Meshing Tool Generator” para
cada nuevo punto de variabilidad que se quiera agregar.
Cambiar el archivo de instrucciones “build_option.txt” a un archivo de intercambio
de información más estándar como un archivo formato XML. Esto le daría una
mayor potencialidad al momento de leer desde la aplicación [FaceAnimator] las
variantes seleccionadas, permitiendo un mejor manejo de esta estructura. Esto es
necesario sólo si se desea mantener la lógica de pasar parámetros durante
ejecución, la cual no debiese seguir existiendo si es que se hace un rediseño de
clases para que la construcción de la aplicación se haga completamente durante el
tiempo de compilación
La experiencia adquirida permite reflexionar sobre la necesidad de tener un sistema de
trabajo o workflow, para la mantención del código fuente de esta familia de productos,
según se plantea en el punto 2.1. Es sobre todo necesario tener esto en cuenta cuando se
trabaja sobre un producto ya construido, donde se requiere la modificación de sus partes
para poder lograr el objetivo de poder construir plataformas y artefactos que permitan la
creación de aplicaciones individuales y especializadas, esto ya que la arquitectura inicial de
las aplicaciones puede no haber sido orientada a la generalización. Aun cuando esté
construido orientado a objeto, la interacción entre ellos hace que el código fuente en sí
esté muy entrelazado y sea difícil de separar.
También este trabajo proporciona una alternativa a cómo abordar la generación de
aplicaciones automáticamente mediante la selección de alternativas predefinidas. La
aplicación implementa un flujo que se basa en la diversificación de las aplicaciones a
construir en el momento de compilación, aun cuando para este caso también se necesitó
la diversificación al momento de ejecución. Este enfoque se potencia de las características
del lenguaje c++, el cual posee polimorfismo y herencias lo cual permite generar esta
diversificación al momento de compilación.
43
Referencias
[FaceAnimator] Valenzuela, Renato “Creación de una herramienta para la visualización de animaciones de rostros”. Memoria Ingeniería Civil, Universidad de Chile, Departamento de Ciencias de la Computación. Octubre 2009, Santiago, Chile.
[Candidade3] Valenzuela, Renato “Creación de una herramienta para la visualización de animaciones de rostros”. Memoria Ingeniería Civil, Universidad de Chile, Departamento de Ciencias de la Computación. Octubre 2009, Santiago, Chile, pp. 11-13.
[TreeGrowSimulator] Melo, Cristina “Desarrollo de una herramienta que genera mallas de superficie compuestas de cuadriláteros para modelar el crecimiento de arboles”. Memoria Ingeniería Civil, Universidad de Chile, Departamento de Ciencias de la Computación. Abril 2008, Santiago, Chile.
[SPL] SEI “Líneas de productos de software” URL http://www.sei.cmu.edu/productlines/frame_report/index.html. 3 de Diciembre 2010.
Tools.” OOPSLA 2009, October 2009, Orlando, Florida, USA.
[Montilva2006] Jonás A. Montilva C., Ph.D. IEEE Member “Desarrollo de Software Basado en Líneas de Productos” Conferencia DVP IEEE Computer Society Región 9 - Capítulo Argentina URL http://www.ieee.org.ar/downloads/2006-
montilva-productos-prt.pdf. 3 de Diciembre 2010.
[MeshTools2005] Maria Cecilia Bastarrica, Nancy Hitschfeld-Kahler “Designing a product family of meshing tools“. En “Advances in Engineering Software 2006” 1-10, n° 37. pp. 3-7.
[SPLE05] Klaus Pohl, Gunter Bockle, Frank van der Linder “Software Product Line Engineering”. Springer Berling Heidelberg, NY, USA. 2005. Cap 1-4.
[FAMAFW] URL http://www.isa.us.es/fama/ 25 de Junio, 2011.
F Modelo de puntos de variabilidad herramienta [S.P.L.O.T.]
formato SXML
<!-- This model was created online using SPLOT's Feature Model Editor (http://www.splot-research.org) on Thu, Sep 22, 2011 - 1:22 AM --><feature_model name="FaceAnimator"><meta><data name="description">FaceAnimator</data><data name="creator">Gonzalo U</data><data name="address"/><data name="email">[email protected]</data><data name="phone"/><data name="website"/><data name="organization">U. de Chile</data><data name="department"/><data name="date"/><data name="reference"/></meta><feature_tree>
