CULTURA EN LA NEGOCIACIÓN CONCEPTOS Y DEFINICIONES
20090723 Presentacion Pfc
1. Análisis de Lenguajes
Específicos de Dominio
para Sistemas Embebidos
Ander Zubizarreta
Donostia, 23 Julio 2009
2. Contexto
Ikerlan Research Centre
Centro de investigación Aplicada
Dentro del Grupo Mondragón
Aprox. 250 personas
Equipo de trabajo
Area de Tecnologias de la Informacion
Equipo de Líneas de Producto Software
2
3. Sistemas embebidos
¿Qué son?
Sistemas de computación “escondidos” dentro del producto
Parte integral del sistema entero
Se utilizan en todo tipo de productos
Características
Propósito específico
Tiempo real
Hardware con restricciones
Conectados a ambientes físicos
Confiabilidad
3
4. Problemas
Complejidad
Los sistemas cada vez son mas complejos
En la funcionalidad inherente que proporcionan
En el numero creciente de funcionalidades
Reutilización
Cómo reutilizar funcionalidad en sistemas nuevos
Customización
Cómo customizar funcionalidad para cada cliente
Otros
Confiabilidad, mantenibilidad, etc
4
5. Paradigmas de Ingeniería de Software
DSL (Domain Specific Language)
Representación del problema en términos del dominio
Mayor expresividad y nivel de abstracción
MDD (Model Driven Development)
El desarrollo se centra en los modelos
Los modelos conforman a metamodelos
Transformaciones para generar código u otros modelos
SPL (Sofware Product Lines) MM
MMA TAB B
Familias de programas
Base + Features
<<conformsTo>> <<transforms>> <<conformsTo>>
Variabilidad
MA MB
5
7. Trabajo realizado
Estado del arte
¿Qué se ha hecho? ¿Cómo se han utilizado?
Herramientas
MetaEdit+, EMF, ATL, MOFScript, MDWorkbench, Rh
apsody, RulesComposer
Casos de estudio
Definición de DSL
Modelado
Transformaciones
• T. de modelo a modelo
• Generación de código
• Generación de documentación
Investigación
Variabilidad en el MDD
7
8. Indice
1. Definición del ejemplo
2. Diseño de DSL
3. Utilización de DSL
4. Model-to-text con MOFScript
5. Model-to-model con ATL
6. Rhapsody + RulesComposer
7. MDPLE
8. JISBD
8
9. Definición del ejemplo
Sistema de control de inundaciones
Sistema embebido ficticio
Varios subsistemas para controlar diferentes
elementos (temperatura, precipitaciones…)
Cada subsistema varias entradas y salidas
Ejemplo: UK01
Sistema de control de inundaciones con 3
subsistemas:
• TenpKont (control de temperatura)
– 3 entradas, 1 salida
• PrezKont (control de precipitaciones)
– 3 entradas, 1 salida
• PresaKont (control de la presa)
– 2 entradas, 1 salida
9
11. Utilización de DSL
MetaEdit+ EMF
Modelado con DSL Modelado con DSL
11
12. Model-to-text con MOFScript
Generación de código C++ desde modelo definido en EMF
Modelo Código
Transformación
C++
12
13. Model-to-model con ATL
Trans. Modelo EMF en clases UML
Modelo Modelo
Transformación
13
14. IBM/TL Rhapsody + RulesComposer
Generación de código y doc. de modelo Rhapsody
Modelo C++
Transformación
Docs
14
15. MDPLE’09: Is model variability enough?
Hasta ahora
La variabilidad en el MDD se ha centrado en la
variabilidad de modelos
Nuestra posición ¿es suficiente?
Es necesaria la variabilidad en metamodelos y
transformaciones
Ejemplos: añadir nuevos tipos de elementos o generar
código para diferentes plataformas
1st International
Workshop on
Model-Driven Product
Line Engineering,
Twente, Netherlands
15
16. JISBD‘09: On the refinement of M2T transformations
Aplicación de la variabilidad a las
transformaciones de modelo a texto
XIV Jornadas de
Ingeniería del Software
y Bases de Datos,
Donostia-San Sebastián
16
18. Gestión
Reuniones
Reuniones entre el tutor y el alumno cada semana
Seguimiento
Reuniones de seguimiento cada 4 semanas
Planificación
Como en todos los proyectos, cambios en la
planificación inicial
18
20. Contribución
Contribución técnica
Estudio de herramientas
Análisis de los paradigmas (DSL, MDD, SPL)
Contribución científica
Aplicación de la variabilidad a transformaciones y
metamodelos
Papers
22
21. Conclusiones
Conclusiones generales
Beneficios de utilizar MDD, DSL y SPL
• Centrarse en ¿qué hace? un programa, no ¿cómo lo hace?
• Generación automática de código y documentación
• Reutilización
Limitaciones
• Diseñar un DSL puede resultar costoso
Conclusiones personales
Experiencia muy positiva
• Aprendizaje de conceptos totalmente nuevos
• Introducción al mundo de investigación
• Introducción al mundo laboral
• Buen entorno de trabajo
23
22. Trabajo futuro
Herramientas que den buen soporte a todas las
fases del MDD
Técnicas y herramientas que den soporte a la
aplicación de la variabilidad
Generación automática de transformaciones
24
Hola, me llamo Ander y a continuación os presentaré mi proyecto fin de carrera. El título del proyecto es Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos, y se ha realizado bajo la dirección de Oscar Diaz por parte de la universidad y Salvador Trujillo por parte de la empresa.
Este proyecto ha sido realizado en la empresa Ikerlan, que es un Centro de Investigación Aplicada del Grupo Mondragón donde trabajan unas 250 personas.Este proyecto se ha llevado a cabo en el área de Tecnologías de la Información junto a un equipo que desarrolla Líneas de Producto Software
Tal como indica el título del proyecto, éste proyecto se sitúa en el contexto de sistemas embebidos.Los sistemas embebidos son sistemas de computación que están integrados en un producto, siendo una parte integral del sistema entero. Hoy en dia son utilizados en una amplia gama de productos, muchos de ellos de uso cotidiano.Las características de los sistemas embebidos difieren de las características de los ordenadores personales. Los sistemas embebidos son creados para un propósito específico. Muchas veces tienen restricciones de tiempo real, es decir, tienen que actuar en un determindo tiempo en unas determinadas situaciones. El hardware suele ser más restringido y muchas veces están conectados a ambientes físicos mediante sensores para recavar información. Los sistemas embebidos deben ser además confiables.
A la hora de trabajar con este tipo de sistemas podemos encontrarnos con varios problemas.Por una parte está la complejidad. Los sistemas son cada vez más complejos, tanto por su propia naturalidad como porque cada vez ofrecen más funcionalidades.Por otra parte está la reutilización, es decir, cómo reutilizar funcionalidades ya existentes en sistemas nuevo.También está la customización del sistema para cada cliente, si estos piden características específicas.Por ultimo están los problemas de confiabilidad, mantenibilidad etc.
Con el objetivo de dar solución a los distintos problemas, en este proyecto se han analizado diferentes paradigmas.Por una parte están los lenguajes específicos de dominio o DSL. Estos son lenguajes creados para dar solución a problemas de un dominio determinado. Permiten representar los problemas utilizando terminos propios del dominio y se consiguen una mayor expresividad y un mayor nivel de abstracción.Por otra parte está el desarrollo de software dirigido por modelos con el cual se busca la automatización de la generación de código desde modelos. En este paradigma el desarrollo se centra en los modelos, con los cuales se representa un programa. Los modelos son definidos mediante lenguajes de modelado y conforman a un metamodelo. Se utilizan transformaciones para generar código u ogros modelos. Una transformación mapea los elementos del metamodelo de entrada con el metamodelo de salida o texto para generar otros modelos del mismo sistema, código o documentación.Por último están las Líneas de Producto Software o SPL. Éstas permiten definir una base común para todos los programas y diferentes “features” que componiendolos con la base dan como resultado diferentes productos finales. Las SPL introducen la variabilidad en el desarrollo de software.
Una vez presesntado el contexto en el que se sitúa el proyecto, procederé a exponer el trabajo que se ha realizado en el mismo
La primera tarea de este proyecto ha sido la de analizar cual es el estado de arte de los paradigmas presentados. Es decir, qué se ha hecho hasta ahora con ellos, cómo se han utilizado, qué beneficios han traido en los casos que se han utilizado etc.También se ha hecho un estudio de diferentes herramientas, algunas para diseñar DSL y modelar con ellos, otras para definir transformaciones de modelos, modelar con UML y generar código etc.Para analizar las herramientas, aprender a utilizarlas y ver las capacidades y limitaciones que ofrecen se han realizado diferentes casos de estudio. Se han definido DSL, se han definido modelos tanto con DSL como con UML, y tambien se han definido transformaciones, tanto de modelo a modelo como de modelo a texto para generar código y documentaciónSe han dedicado los meses finales del proyecto a la investigación y se ha analizado cómo aplicar la variabilidad a los distintos elementos que participan en el MDD, y se ha presentado alguna solucion.
En las siguientes diapositivas se presentan por un lado diferentes casos de estudio que se han realizado, zerrendatu.Por otro lado, también se presenta la labor que se ha realizado en la parte de investigación
Mediante la técnica de metamodelado se ha definido por una parte un DSL de modelado para modelar sistemas de control de inundaciones utilizando la herramienta MetaEdit+, y por otro lado otro DSL utilizando en este caso la herramienta EMF.Este es el ejemplo de MetaEdit+ donde se han definido los distintos tipos de elementos que pueden aparecer en un modelo, sur relaciones y cardinalidades, como se puede ver se han definido elementos del tipo sistema, subsistema, input y output.EMF también ofrece la posibilidad de definir un metamodelo de forma parecida, como se puede ver, también se ha definido…
Una vez definido un lenguaje de modelado, podemos utilizarlo para crear modelos. Aquí vemos por una parte el sistema descrito modelado con MetaEdit+ utilizando el lenguaje de modelado que hemos creado. Como vemos tenemos un sistema con 3 subsistemas cada uno con sus inputs in outputs.En el caso de EMF, éste es el modelo que hemos creado con él. Este modelo representa el mismo sistema que el modelo anterior.
Como ya hemos comentado, uno de los objetivos del MDD es la generación automática de código. Para eso se utilizan transformaciones de modelo a texto. En este caso se ha definido una transformación con la herramienta MOFScript para transformar el modelo creado con EMF en código C++.En la transformación se mapean elementos del metamodelo de entrada con texto, y aplicándolo al modelo obtenemos el código de implementación.
Otra opción es la de transformar modelos en otros modelos, para obtener una representación distinta del mismo sistema. Para eso, en este ejemplo se ha utilizado la herramienta ATL. Partiendo del mismo modelo de entrada que en el ejemplo anterior hemos generado un modelo de clases de UML representando el mismo sistema de control de inundaciones.En la transformacion hemos definido el metamodelo de entrada y de salida, y mediante reglas se han definido mapeos entre los metamodelos para asignar los valorer del modelo de entrada al de salida. En este caso se ha creado una clase UML por cada subsistema y los inputs y outputs son los atributos.Con la aplicación de la transformación obtenemos el siguiente diagrama.
Dejando a un lado los DSL también os mostraré un ejemplo realizado con TL Rhapsody. Este es un potente entorno de modelado que junto RulesComposer ofrece una solución muy completa para la generación automática de código y documentación.En este caso se ha modelado el sistema UK01 descrito utilizando UML. Con RulesComposer se ha definido por una parte una transformación de modelo a texto para generar código C++. En este caso se combinan plantillas de texto con elementos del metamodelo. Por otro lado, de forma parecida se pueden combinar los elementos del metamodelo con plantillas de word, lo que facilita la generación de la documentación.Aplicando la primera transformación obtenemos código C++ parecido al que habiamos obtenido con la transformación de MOFScript. Con la aplicación de la segunda, obtenemos documentos de word, en los que además es posible insertar directamente diagramas de los modelos.
Dejando a un lado los casos de estudio, la parte de la investigación del proyecto se ha centrado en la aplicación de la variabilidad en el MDD. En este sentido ya se han realizado diversos trabajos, pero la mayoría de ellos se han centrado en la aplicación de la variabilidad a los modelos.Nuestra posición, en cambio, es que la variabilidad también puede ser necesaria en metamodelos y transformaciones. Esto puede ser por ejemplo cuando no utilizamos metamodelosestándare y quermos extenderlos añadiendo, o también cuando queremos definir transformaciones para generar código para distintas plataformas o distintos lenguajes, ya que todas las transformaciones compartirán alguna parte comun.Presentando esta necesidad de la variabilidad se envió una positonpaper al ….
En este sentido se presentó una solución para aplicar la variabilidad a las transformaciones de modelo a texto definidos con la herramienta MOFScript y se envió un paper a las ….En este caso se ha aplicado la idea de las SPL a las transformaciones de modelo a texto.
Dejando a un lado el aspecto técnico del proyecto, en cuanto a su gestión se refiere….
Desde el inicio del proyecto se hanrealizadoreunionescadasemana entre el tutor y el alumno, en los cuales se analizabanlastarearrealizadas y se adquiriannuevoscompromisosAparte de estasreuniones, cadacuatrosemanas se hanrealizadoreuniones de seguimiento, paraanalizar el rumbo del proyecto y hacercambios en la planificaciónsifuesenecesario.Como la mayoria de los proyectos, estetambién ha sufridocambiosdesdesuplanificacióninicial. Los cambioshansidocausados en parte por la introducción de la investigación.
Para ir finalizando os presentaré algunas conclusiones que se han obtenido durante la realización del proyecto
Para ir finalizando presentaré algunas conclusiones que se han obtenido durante la realización del proyecto
Empezaré con la contribución que se ha realizado ….
En cuanto a conclusiones generales, se puede decir que se ha visto que la utilizacion de