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 TAB B
 Familias de programas
 Base + Features
<<conformsTo>> <<transforms>> <<conformsTo>>
 Variabilidad
MA MB
5

6. Trabajo realizado
6

7. Trabajo realizado
 Estado del arte
 ¿Qué se ha hecho? ¿Cómo se han utilizado?
 Herramientas
 MetaEdit+, EMF, ATL, MOFScript, MDWorkbench,
Rhapsody, 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

10. Diseño de DSL
MetaEdit+ EMF
 Metamodelado  Metamodelado
10

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

17. Gestión

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

19. Conclusiones
21

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

23. ¿Preguntas?