Nálisis De Lenguajes Específicos De Dominio Para Sistemas Embebidos

Análisis

de Lenguajes Específicos de Dominio para Sistemas Embebidos

Ander Zubizarreta Donostia, 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 TAB Lines) MMB MMA  Familias de programas <> <>  Base + Features  Variabilidad MA

<>

MB 5

Trabajo realizado

6

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

Indice 1. 2. 3. 4. 5. 6. 7. 8.

Definición del ejemplo Diseño de DSL Utilización de DSL Model-to-text con MOFScript Model-to-model con ATL Rhapsody + RulesComposer MDPLE JISBD

8

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

Diseño de DSL MetaEdit+  Metamodelado

EMF  Metamodelado

10

Utilización de DSL

MetaEdit+  Modelado con DSL

EMF  Modelado con DSL

11

Model-to-text con MOFScript  Generación de código C++ desde modelo definido en EMF Modelo

Transformación

Código C++

12

Model-to-model con ATL  Trans. Modelo EMF en clases UML Modelo

Transformación

Modelo

13

IBM/TL Rhapsody + RulesComposer  Generación de código y doc. de modelo Rhapsody Modelo

Transformación

C++

Docs

14

MDPLE’09: Is model variability enough?  Hasta ahora  La variabilidad en el MDD se ha centrado en la variabilidad de modelos ¿es

 Nuestra posición

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

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

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

19

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

20

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 21

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

22

¿Preguntas?