Análisis de Lenguajes Específicos de Dominio

para Sistemas Embebidos

Ander ZubizarretaDonostia, 23 Julio 2009

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

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

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

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)

Familias de programas

Base + Features

Variabilidad

5

MMA

MBMA

MMBTAB

<<conformsTo>><<conformsTo>>

<<transforms>>

Trabajo realizado

6

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

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

Definición del ejemplo

Sistema de control de inundaciones Sistema embebido ficticio

Varios subsistemas para controlar diferenteselementos (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

Diseño de DSLMetaEdit+

Metamodelado

EMF

Metamodelado

10

Utilización de DSLMetaEdit+

Modelado con DSL

EMF

Modelado con DSL

11

Model-to-text con MOFScript

Generación de código C++ desde modelo definido en EMF

12

C++

Modelo TransformaciónCódigo

Model-to-model con ATL

Trans. Modelo EMF en clases UML

13

Modelo TransformaciónModelo

C++

IBM/TL Rhapsody + RulesComposer

Generación de código y doc. de modelo Rhapsody

14

Modelo Transformación

Docs

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 necesaria la variabilidad en metamodelos y

transformaciones Ejemplos: añadir nuevos tipos de elementos o generar

código para diferentes plataformas

15

¿es suficiente?

1st International

Workshop on

Model-Driven Product

Line Engineering,

Twente, Netherlands

JISBD‘09: On the refinement of M2T transformations

Aplicación de la variabilidad a las

transformaciones de modelo a texto

16

XIV Jornadas de

Ingeniería del Software

y Bases de Datos,

Donostia-San Sebastián

Gestión

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

Conclusiones

21

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

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

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

¿Preguntas?