Facultad de Informática       Informatika Fakultatea              TITULACIÓN: Ingeniería Informática   Analisis de Lenguaj...
Facultad de Informática de San Sebastián                                Donostiako Informatika Fakultatea                 ...
Facultad de Informática       Informatika Fakultatea              TITULACIÓN: Ingeniería Informática   Analisis de Lenguaj...
Resumen   Un lenguaje específico de dominio (DSL) es un lenguaje creado para dar solución aun problema de un dominio determ...
Gako-hitzak: domeinuko lengoaia espezifikoak, modelo bidezko software garapena,sistema txertatuakSummary    A domain specifi...
Índice generalÍndice general                                                                             IÍndice de figuras...
ÍNDICE GENERAL         2.9.2. Reuniones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .     12         2.9.3. ...
ÍNDICE GENERAL        5.2.4. MOFScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . .      46        5.2.5. MDW...
ÍNDICE GENERAL   8.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   78Bibliografía     ...
Índice de figuras 2.1. Diagrama EDT inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . .     9 2.2. Diagrama de ...
ÍNDICE DE FIGURAS  6.3.   Transformación base (representación XMI)       .   .   .   .   .   .   .   .   .   .   .   .   ....
Índice de tablas 2.1. Asignación de recursos en la planificación inicial . . . . . . . . . . . . .    9 4.1. Elementos del ...
ÍNDICE DE TABLAS                   VIII
Capítulo 1Introducción    En las siguientes líneas se presenta el contexto en el que se sitúa este proyecto, mos-trando un...
CAPÍTULO 1. INTRODUCCIÓNabstracción y términos propios del dominio, lo cual facilita su aprendizaje por parte depersonas f...
1.3. METODOLOGÍAEstado del arte    Por una parte se quiere analizar el estado del arte tanto de los DSL como del MDD.Aunqu...
CAPÍTULO 1. INTRODUCCIÓNacordó realizar una reunión de seguimiento del proyecto cada semana con el tutor, paraanalizar el ...
1.4. ORGANIZACIÓN DEL DOCUMENTOción de este documento y su respectiva presentación.1.4.     Organización del documento    ...
CAPÍTULO 1. INTRODUCCIÓN                           6
Capítulo 2Documento de Objetivos del Proyecto2.1.     Descripción    Continuamente se buscan nuevas técnicas para el desar...
CAPÍTULO 2. DOCUMENTO DE OBJETIVOS DEL PROYECTO       su utilización, sus capacidades y sus limitaciones.       Desarrolla...
2.4. DIAGRAMA EDT       Entregable: memoria y presentación       Tipo: documento PDF y presentación PPT       Fecha: 15/07...
CAPÍTULO 2. DOCUMENTO DE OBJETIVOS DEL PROYECTO2.6.     Tareas2.6.1. Gestión       Documento de objetivos del proyecto: re...
2.7. DIAGRAMA DE GANTT2.6.5.    Cierre       Memoria: realización del documento que se entregará como resultado final del  ...
CAPÍTULO 2. DOCUMENTO DE OBJETIVOS DEL PROYECTO       Que haya demasiada carga de trabajo y que no de tiempo a finalizar la...
Capítulo 3Conceptos básicos    En este capítulo se introducen algunos conceptos básicos que ayudarán a situarnos enel proy...
CAPÍTULO 3. CONCEPTOS BÁSICOSde control de una central nuclear. A la hora de trabajar con sistemas embebidos encon-tramos ...
3.1. SISTEMAS EMBEBIDOS                   Figura 3.1: Sistema embebido en un aerogenerador         5. Seguridad informátic...
CAPÍTULO 3. CONCEPTOS BÁSICOS                      Figura 3.2: Fases en el desarrollo de software    Un aerogenerador pued...
3.2. INGENIERÍA DE SOFTWARE      Análisis de requisitos: La primera etapa del software es la extracción de requisi-      t...
CAPÍTULO 3. CONCEPTOS BÁSICOSetapas del desarrollo de software, tanto en el análisis de requisitos, diseño y modelado dels...
3.2. INGENIERÍA DE SOFTWARE                        Figura 3.3: Línea de Producto SoftwareUML    Unified Modeling Language (...
CAPÍTULO 3. CONCEPTOS BÁSICOS3.2.3. Ingeniería de software vs. ingeniería de sistemas    La ingeniería de sistemas es la d...
Capítulo 4Lenguajes Específicos de Dominio4.1.     Estado del arte4.1.1.   Introducción a los DSL    Dentro del mundo de la...
CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO<html ><body><h1>My F i r s t H e a d i n g < / h1><p>My f i r s t p a r a g r...
4.1. ESTADO DEL ARTE                          Figura 4.2: Diagrama de tres niveles    La utilización de DSL gráficos va muy...
CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO      resultar una opción más económica, por lo que es conveniente buscar alte...
4.1. ESTADO DEL ARTE                Figura 4.3: DSL para desarrollar aplicaciones para Nokia4.1.3.    Uso de DSL en la ind...
CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO       Trabajar en términos del dominio, permitiendo a los desarrolladores un ...
4.2. HERRAMIENTAS                      MetaEdit+            Eclipse EMF             M3        GOPPRR                  Ecor...
CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO                           Figura 4.5: Modelado con MetaEdit+4.2.1. MetaEdit+D...
4.2. HERRAMIENTAS    Aparte de la herramienta gráfica para definir metamodelos, MetaEdit+ también ofreceuna herramienta basa...
CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO                         Figura 4.6: Metamodelado con EcoreEstos elementos se ...
4.2. HERRAMIENTAS                             Figura 4.7: Modelado con EMFun lenguaje de modelado que permita representar ...
CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIOinteroperabilidad de EMF con ellas.4.2.3. Comparativa    Aunque el lenguaje de...
4.3. CASO DE ESTUDIOfactores muy influyentes.4.3.     Caso de estudio   A continuación se muestra un caso de estudio simpli...
CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO   En este ejemplo, después de definir el metamodelo se ha personalizado la apa...
4.3. CASO DE ESTUDIOEMF    La Figura 4.7 muestra el modelo del sistema de control de inundaciones UK01 defini-do con EMF. E...
CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO                              36
Capítulo 5Desarrollo de Software Dirigido porModelos    El Desarrollo de Software Dirigido por Modelos o Model Driven Deve...
CAPÍTULO 5. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOStienen especial importancia, ya que no son solo elementos de diseño...
5.1. CONCEPTOS BÁSICOS5.1.3.   Metamodelo    Un modelo es normalmente una instancia que conforma a un metamodelo (Figura4....
CAPÍTULO 5. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOSentre modelos. Algunos ejemplos son ATL (Bézivin et al., 2003), Rub...
5.2. HERRAMIENTAS                         Figura 5.2: Transformacion MetaEdit+Características    MetaEdit+ trae algunas tr...
CAPÍTULO 5. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOStales como if, foreach o dowhile. También ofrece algunos comandos p...
5.2. HERRAMIENTASreside más en la creación de metamodelos y modelos que en la definición de las transfor-maciones.5.2.2.   ...
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos
Upcoming SlideShare
Loading in...5
×

PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos

370

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
370
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "PFC: Análisis de Lenguajes Específicos de Dominio para Sistemas Embebidos"

  1. 1. Facultad de Informática Informatika Fakultatea TITULACIÓN: Ingeniería Informática Analisis de Lenguajes Específicos de Dominio para Sistemas EmbebidosAlumno/a: D./Dña. Ander Zubizarreta GarciaDirector/a: D./Dña. Oscar Diaz Garcia Proyecto Fin de Carrera, julio de 2009
  2. 2. Facultad de Informática de San Sebastián Donostiako Informatika Fakultatea ACTA DE CALIFICACIÓN KALIFIKATZEKO AKTA IKASTURTEA KODEA CURSO CÓDIGO IKASLEA N.A.N. ALUMNO/A D.N.I.Reunido el tribunal examinador en el día de la fecha, Egunean bildurik ondorengo partaideek osatutakoconstituido por: epaimahiak:Presidentea /Presidente/a:Idazkaria / Secretario/a:Batzordekidea / Vocal:para juzgar el siguiente proyecto de Fin de Carrera: ondorengo Karrera Bukaerako Proiektua epaitzeko:presentado por -k aurkeztuadirigido por -k zuzenduaacordó otorgar la siguiente calificación: ondorengo kalifikazioa ematea erabaki zuen:Y para que conste, y a los efectos oportunos, extiende, Horrela ager dadin, eta dagozkion ondorioak sor ditzan,firmada por todos los comparecientes del tribunal, la bertaraturiko batzordekideek sinatutako ebaluazio-aktapresente acta hau ematen du Donostian, __________(e)ko ______________________ren _____(e)(a)n En Donostia, a _____ de _______________________ de __________ Presidentea / El/La Presidente/a Batzordekidea / Vocal Idazkaria / El/La Secretario/a________________________________ ________________________________ ________________________________
  3. 3. Facultad de Informática Informatika Fakultatea TITULACIÓN: Ingeniería Informática Analisis de Lenguajes Específicos de Dominio para Sistemas EmbebidosAlumno/a: D./Dña. Ander Zubizarreta GarciaDirector/a: D./Dña. Oscar Diaz Garcia Proyecto Fin de Carrera, julio de 2009
  4. 4. Resumen Un lenguaje específico de dominio (DSL) es un lenguaje creado para dar solución aun problema de un dominio determinado. Los DSL permiten expresar problemas o solu-ciones más claramente que otros lenguajes de propósito general. Normalmente son menoscompletos, pero más expresivos, permitiendo un mayor nivel de abstracción. El desarrollo dirigido por modelos (MDD) es un paradigma para la automatización dela generación de código. Los programas son representados mediante modelos que con-forman a un metamodelo. Mediante el uso de transformaciones, los modelos pueden sertransformados en otros modelos o en código de implementación. El uso del desarrollo dirigido por modelos en las líneas de producto software (SPL)introduce la variabilidad al MDD. En este proyecto se analizan el estado del arte de estos paradigmas y las herramientasdisponibles para trabajar con ellos, mediante casos de estudio. También se muestra cómopuede ser introducida la variabilidad al MDD.Palabras clave: lenguajes específicos de dominio, desarrollo dirigido por modelos, sis-temas embebidosLaburpena Domeinuko lengoaia espezifikoak (DSL) domeinu jakin bateko arazoari soluzioa ema-teko garatutako lengoaiak dira. DSLek bai problemak eta baita soluzioak ere beste xedeorokorreko lengoaiek baino modu argiagoan irudikatzea ahalbidetzen dute. Normaleansinpleagoak izan arren, adierazgarriagoak dira, abstrakzio maila altuagoa onartzen dute-larik. Modelo bidezko software garapena (MDD) inplementazio kodea modeloetatik au-tomatikoki sortzea helburu duen paradigma bat da. Softwarea metamodelo jakin batezzehaztutako modelo bidez irudikatzen da. Transformazioen erabilerarekin modelo batsistema beraren beste modelo batean eraldatu daiteke, sistemaren beste irudikapen batizateko, edo inplementazio kodea sor daiteke. Modelo bidezko software garapenaren eta software produktu lerroen (SPL) artekokonbinaketarekin MDDaren arloan aldakortasuna ahalbidetzen da. Proiektu honetan paradigma hauen artearen egoera eta beraiekin lan egitea ahalbide-tzen duten tresnak analizatzen dira, kasu-azterketen bitartez. Aldakortasuna MDDarenarloan nola gauzatu ere erakusten da.
  5. 5. Gako-hitzak: domeinuko lengoaia espezifikoak, modelo bidezko software garapena,sistema txertatuakSummary A domain specific language (DSL) is a language created to solve a problem in a spe-cific domain. The DSL allow to express problems or solutions more clearly than othergeneral purpose languages. They are usually more expressive, allowing a higher level ofabstraction. Model driven development (MDD) is a paradigm for the automation of code genera-tion from models. The programs are represented by models that conform to a metamodel.Using transformations, models can be transformed into other models or implementationcode. The use combination of MDD with software product lines (SPL) introduces variabilityto the MDD. This project analyzes the state of the art of these paradigms and the tools available towork with them, through case studies. It also shows how the variability can be introducedto the MDD.Keywords: domain specific languages, model driven development, embedded systems
  6. 6. Índice generalÍndice general IÍndice de figuras VÍndice de tablas VII1. Introducción 1 1.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3. Metodología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.4. Organización del documento . . . . . . . . . . . . . . . . . . . . . . . . 52. Documento de Objetivos del Proyecto 7 2.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Alcance: entregas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Diagrama EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5. Asignación de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.6. Tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6.1. Gestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6.2. Estudio de estado del arte . . . . . . . . . . . . . . . . . . . . . 10 2.6.3. Análisis de herramientas . . . . . . . . . . . . . . . . . . . . . . 10 2.6.4. Desarrollo de prototipo . . . . . . . . . . . . . . . . . . . . . . . 10 2.6.5. Cierre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.7. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.8. Factores de riesgo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.9. Método de trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.9.1. Miembros del equipo del proyecto . . . . . . . . . . . . . . . . . 12 I
  7. 7. ÍNDICE GENERAL 2.9.2. Reuniones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.9.3. Seguimiento del proyecto. . . . . . . . . . . . . . . . . . . . . . 123. Conceptos básicos 13 3.1. Sistemas embebidos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. Características de los sistemas embebidos . . . . . . . . . . . . . 13 3.1.2. Ejemplo de sistema embebido . . . . . . . . . . . . . . . . . . . 15 3.2. Ingeniería de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2.1. Fases en el desarrollo de software . . . . . . . . . . . . . . . . . 16 3.2.2. Automatización del desarrollo . . . . . . . . . . . . . . . . . . . 17 3.2.3. Ingeniería de software vs. ingeniería de sistemas . . . . . . . . . 204. Lenguajes Específicos de Dominio 21 4.1. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.1. Introducción a los DSL . . . . . . . . . . . . . . . . . . . . . . . 21 4.1.2. Diseño de DSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.1.3. Uso de DSL en la industria . . . . . . . . . . . . . . . . . . . . . 25 4.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.1. MetaEdit+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2.2. EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.3. Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3.2. Definición del lenguaje de modelado . . . . . . . . . . . . . . . . 33 4.3.3. Utilización del lenguaje de modelado . . . . . . . . . . . . . . . 34 4.3.4. Beneficios obtenidos . . . . . . . . . . . . . . . . . . . . . . . . 355. Desarrollo de Software Dirigido por Modelos 37 5.1. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.1. MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.1.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.1.3. Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 5.1.4. Transformaciónes de modelos . . . . . . . . . . . . . . . . . . . 39 5.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2.1. MetaEdit+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2.2. Eclipse Modeling Framework . . . . . . . . . . . . . . . . . . . 43 5.2.3. ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 II
  8. 8. ÍNDICE GENERAL 5.2.4. MOFScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2.5. MDWorkbench . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.2.6. IBM Telelogic Rhapsody . . . . . . . . . . . . . . . . . . . . . . 51 5.2.7. RulesComposer . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 5.2.8. Comparativa y conclusiones . . . . . . . . . . . . . . . . . . . . 54 5.3. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.3.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.3.2. Transformación de modelo a texto con MOFScript . . . . . . . . 55 5.3.3. Transformación de modelo a modelo con ATL . . . . . . . . . . 56 5.3.4. Ejemplo con Rhapsody y RulesComposer . . . . . . . . . . . . . 57 5.3.5. Beneficios obtenidos . . . . . . . . . . . . . . . . . . . . . . . . 596. Variabilidad en el MDD 61 6.1. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.1.1. MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.1.2. SPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.2. Necesidad de la variabilidad . . . . . . . . . . . . . . . . . . . . . . . . 64 6.2.1. Escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.2.2. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.3. Refinamiento de transformaciones . . . . . . . . . . . . . . . . . . . . . 65 6.3.1. Transformación base . . . . . . . . . . . . . . . . . . . . . . . . 66 6.3.2. Refinamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.3.3. Composición de la base y el refinamiento . . . . . . . . . . . . . 69 6.4. Trabajo relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 707. Gestión del proyecto 71 7.1. EDT inicial vs EDT final . . . . . . . . . . . . . . . . . . . . . . . . . . 71 7.2. Estimación de recursos inicial vs recursos invertidos . . . . . . . . . . . . 72 7.2.1. Tabla de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.2.2. Diagrama de Gantt real . . . . . . . . . . . . . . . . . . . . . . . 748. Conclusiones 75 8.1. Contribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 8.2. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 8.2.1. Conclusiones generales . . . . . . . . . . . . . . . . . . . . . . . 76 8.2.2. Conclusiones personales . . . . . . . . . . . . . . . . . . . . . . 77 III
  9. 9. ÍNDICE GENERAL 8.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Bibliografía 79 IV
  10. 10. Índice de figuras 2.1. Diagrama EDT inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2. Diagrama de Gantt inicial . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Sistema embebido en un aerogenerador . . . . . . . . . . . . . . . . . . 15 3.2. Fases en el desarrollo de software . . . . . . . . . . . . . . . . . . . . . 16 3.3. Línea de Producto Software . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Ejemplos de DSL textual y gráfico . . . . . . . . . . . . . . . . . . . . . 22 4.2. Diagrama de tres niveles . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3. DSL para aplicaciones Nokia . . . . . . . . . . . . . . . . . . . . . . . . 25 4.4. Metamodelado utilizando GOPPRR en MetaEdit+ . . . . . . . . . . . . . 27 4.5. Modelado con MetaEdit+ . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.6. Metamodelado con Ecore . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.7. Modelado con EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.1. Escenario MDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2. Transformacion MetaEdit+ . . . . . . . . . . . . . . . . . . . . . . . . . 41 5.3. Transformación ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.4. Transformación MOFScript . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.5. Transformacion utilizando TGL . . . . . . . . . . . . . . . . . . . . . . 49 5.6. Plantilla para generar documentación en Word . . . . . . . . . . . . . . . 50 5.7. Representación del sistema UK01 en Rhapsody . . . . . . . . . . . . . . 51 5.8. Navegación de modelos en RulesComposer . . . . . . . . . . . . . . . . 53 5.9. Fichero TenpKont.cpp generado con MOFScript . . . . . . . . . . . . . . 56 5.10. Modelo UML generado con ATL . . . . . . . . . . . . . . . . . . . . . . 57 5.11. Documentación generada con RulesComposer . . . . . . . . . . . . . . . 58 6.1. Modelo de control de temperatura . . . . . . . . . . . . . . . . . . . . . 62 6.2. Definición de transformación con MOFScript . . . . . . . . . . . . . . . 63 V
  11. 11. ÍNDICE DE FIGURAS 6.3. Transformación base (representación XMI) . . . . . . . . . . . . . . . . 66 6.4. Refinamiento para Ada con XAK . . . . . . . . . . . . . . . . . . . . . . 67 6.5. Composición de la transformación . . . . . . . . . . . . . . . . . . . . . 68 6.6. Código generado: (a) Ada; (b) Java . . . . . . . . . . . . . . . . . . . . . 69 7.1. Diagrama EDT final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 7.2. Diagrama de Gantt real . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 VI
  12. 12. Índice de tablas 2.1. Asignación de recursos en la planificación inicial . . . . . . . . . . . . . 9 4.1. Elementos del diagrama de 3 niveles en cada herramienta . . . . . . . . . 27 5.1. Características del las herramientas de MDD . . . . . . . . . . . . . . . . 54 7.1. Tabla comparativa de horas planificadas frente a horas invertidas . . . . . 73 VII
  13. 13. ÍNDICE DE TABLAS VIII
  14. 14. Capítulo 1Introducción En las siguientes líneas se presenta el contexto en el que se sitúa este proyecto, mos-trando una visión general del mismo. Se detallan los objetivos que persigue el proyecto yla metodología utilizada para cumplirlos.1.1. Contexto El desarrollo de software ha ido evolucionando, introduciendo nuevos lenguajes yparadigmas que ofrecen mejoras al desarrollo. Simultáneamente también los lenguajes ylas herramientas de modelado han ido adquiriendo cada vez más importancia. No obstanteestos últimos son muchas veces utilizados como herramientas de documentación y nocomo herramientas de diseño de software. La mayoría de los lenguajes utilizados actualmente en el desarrollo de software, tantolenguajes de programación (Java, C/C++, etc.) como lenguajes de modelado (UML, etc.),son lenguajes de propósito general. Aunque la utilización de cada lenguaje pueda sermás o menos apropiada en una situación determinada, todos los lenguajes de este tipopermiten, en general, dar solución a cualquier problema, sin que importe el dominio en elque se sitúa el mismo. Aunque los lenguajes hayan ido evolucionando, la forma de desarrollar el software noha sufrido grandes cambios. Con la introducción de los lenguajes específicos de dominioo DSL (Domain Specific Languages) y el desarrollo dirigido por modelos o MDD (ModelDriven Development), se pretende dar un salto cualitativo en la evolución del desarrollode software. Los DSL son lenguajes definidos para dar solución a problemas en un dominio deter-minado. Estos lenguajes permiten representar la solución a un problema en un nivel de 1
  15. 15. CAPÍTULO 1. INTRODUCCIÓNabstracción y términos propios del dominio, lo cual facilita su aprendizaje por parte depersonas familiarizadas con ese dominio. El MDD es un paradigma en el que el software es representado mediante modelos,a partir de los cuales, aplicando transformaciones, se pueden obtener nuevos modelos,o bien código de implementación. En el MDD los modelos no son utilizados sólo paradiseñar o documentar el software, sino con el objetivo de generar el código automática-mente a partir de los mismos. Al igual que con los programas, los modelos pueden serrepresentados utilizando lenguajes de modelado de propósito general o específicos de do-minio. Estos últimos tienen la ventaja de permitir un mayor nivel de abstracción en larepresentación gráfica de un programa. Actualmente, en el desarrollo de software, es frecuente hablar de familias de pro-gramas que consisten en un mismo producto que admite distintas variaciones. En estecontexto se sitúan las Líneas de Producto Software o SPL (Software Product Lines). LasSPL permiten la reutilización de código, mediante la definición de distintos componentesque se componen en distintas combinaciones para generar diferentes productos finales. La combinación de las SPL con el MDD añade a este último el concepto de la varia-bilidad. En este caso se modela la parte común de los distintos productos por una parte,y las posibles variaciones por otra, pudiendo crear los modelos de los distintos productosfinales mediante la composición del modelo base con diferentes variaciones. Este proyecto se sitúa en un contexto en el que se quiere generar de forma automáticael código para una familia de programas para sistemas embebidos a partir de modelos, enun dominio específico. La utilización del MDD es esencial en el modelado del softwarepara la posterior generación automática de código, y su combinación con los DSL y lavariabilidad puede ofrecer una solución interesante al problema. Es precisamente esa lacuestión que se aborda en este trabajo.1.2. Objetivos El objetivo principal que persigue el proyecto es analizar los lenguajes específicos dedominio. En particular, analizar el estado del arte y las herramientas existentes, centrán-dose en el tema de Desarrollo Dirigido por Modelos y generación de código para sistemasembebidos. Los objetivos del proyecto se pueden dividir en tres partes: 2
  16. 16. 1.3. METODOLOGÍAEstado del arte Por una parte se quiere analizar el estado del arte tanto de los DSL como del MDD.Aunque no sean conceptos novedosos, su implantación en el mundo de la ingeniería desoftware no está muy extendida todavía. Aún así, son conceptos que van adquiriendocada vez más importancia, y es por ello por lo que es conveniente conocer qué se hahecho y cómo se han utilizado hasta ahora, así como analizar qué herramientas existen enel mercado para trabajar con ellos. El objetivo es estudiar qué ventajas nos pueden ofrecertanto los DSL como el MDD respecto a cómo se desarrolla el software habitualmente.Herramientas Existen diversas herramientas para MDD. Algunas ofrecen utilidades para generaciónautomática de código desde modelos definidos con lenguajes de propósito general, ta-les como UML. Otras combinan el MDD con los DSL, pudiendo utilizar lenguajes demodelado diseñados por uno mismo. También existen herramientas que ofrecen ambasposibilidades. En este proyecto se plantea analizar una serie de herramientas, tanto comerciales comode licencia libre, con el objetivo de conocer las capacidades que ofrecen, y comparar lasventajas y desventajas de cada una de ellas. También se analiza cómo se puede introducir la variabilidad en el MDD utilizandoalguna de las herramientas.Variabilidad La combinación del MDD con los SPL introduce la variabilidad a los modelos, pu-diendo tener familias de productos representados por modelos. Otro de los objetivos quese persigue en este proyecto es analizar cómo se puede introducir la variabilidad en otroselementos del MDD, tales como metamodelos o transformaciones de modelos.1.3. Metodología A continuación se explica la metodología que se ha seguido a la hora de realizar esteproyecto. El proyecto empezó a finales de octubre de 2008. En una primera reunión entre elalumno y el tutor de la empresa se hizo una planificación de cómo transcurriría el pro-yecto, marcando los objetivos y las tareas a realizar durante el transcurso del mismo. Se 3
  17. 17. CAPÍTULO 1. INTRODUCCIÓNacordó realizar una reunión de seguimiento del proyecto cada semana con el tutor, paraanalizar el trabajo realizado y los compromisos a adquirir para la siguiente semana. Trascada reunión se redactaba su correspondiente acta. El primer trabajo tras iniciar el proyecto fue el de documentación. Dada la novedad delos conceptos de DSL y MDD para el alumno, el trabajo de las primeras semanas consis-tió en buscar documentación y definiciones de los distintos conceptos dentro del MDD.También se leyeron diversos artículos con el fin de contextualizar adecuadamente el pro-yecto. La lectura de artículos y trabajos de investigación ha sido una constante durantetodo el proyecto. La lectura acaparó gran parte del tiempo durante el inicio del proyecto (aunque nohaya sido poco el tiempo que se le ha dedicado posteriormente), con el fin de, por unaparte entender bien todos los conceptos que se trabajarían durante el proyecto, y por otra,ver el trabajo que se había realizado hasta el momento en el tema, y cuál era el estado delarte. A continuación se procedió a la instalación de diversas herramientas y a aprender autilizarlas realizando pequeños ejemplos con ellas. Las primeras herramientas utilizadasfueron MetaEdit+ y Eclipse Modeling Framework (EMF) para diseñar DSL de modelado.Posteriormente se utilizaron MDWorkbench, ATL y MOFScript, todas ellas herramientaspara definir transformaciones de modelos. Por último, se ha utilizado la herramienta demodelado IBM Telelogic Rhapsody, la cual ofrece un potente entorno para el modeladode sistemas o software, y que junto con su complemento RulesComposer para la trans-formación de modelos facilita la generación automática de código desde los modelosdefinidos. Los primeros ejemplos realizados con las herramientas fueron ejemplos peque-ños, normalmente sacados de sus propios tutoriales, con el fin de aprender cómo usarlas.Posteriormente, se han venido realizando ejemplos más grandes, con el fin de analizar lasposibilidades que ofrece cada herramienta y hacer un análisis más detallado de cada unade ellas para obtener sus capacidades y limitaciones de uso. Sin dejar a un lado el análisis de las diferentes herramientas, durante los últimos me-ses del proyecto se ha introducido una parte de investigación. La base de la investigaciónha sido la introducción de la variabilidad en el MDD. Se ha analizado cómo puede afectarla variabilidad a los distintos elementos que forman parte del MDD, especialmente có-mo pueden ser refinados, y se han escrito varios artículos sobre ello que se especificaránen su correspondiente capítulo. En esta parte del proyecto, ha sido el tutor quien ha pro-puesto las ideas a trabajar, mientras que el alumno ha elaborado ejemplos para ver quéherramientas usar y cómo avanzar en el tema. Tal y como se había previsto en la planificación del proyecto, éste acaba con la redac- 4
  18. 18. 1.4. ORGANIZACIÓN DEL DOCUMENTOción de este documento y su respectiva presentación.1.4. Organización del documento El resto del documento se organiza de la siguiente forma. El capítulo 2 es el documento de objetivos del proyecto, donde se indican los objetivosprincipales y la planificación del mismo. En el capítulo 3 se ofrece una definición de los conceptos básicos para situar el proyec-to. En una primera sección dentro de este capítulo se introducen los sistemas embebidos.Después se hace una introducción a la ingeniería de software, donde se presentan algunosconceptos que ayudarán en la comprensión del trabajo. En el capítulo 4 se introducen los DSL. El capítulo está dividido en tres secciones.Primero se explica el estado del arte. A continuación se detalla qué herramientas se hananalizado y cómo se trabaja con ellas. Seguidamente, se hace una comparativa de losdistintos aspectos de las herramientas y para finalizar se muestra un caso de estudio conun ejemplo. En el siguiente capítulo se hace una introducción al MDD. Este cuarto capítulo siguela misma estructura que el anterior: conceptos básicos, herramientas, caso de estudio. En el capítulo 6 se muestra la parte de investigación de este proyecto, es decir, la in-troducción de la variabilidad en el MDD. Este capítulo está basado en uno de los artículosescritos como resultado de la investigación y en él se presenta una solución para aplicarla variabilidad a las transformaciones de modelo a texto. En el capítulo 7 se ofrecen detalles sobre la gestión del proyecto, donde se comparanlas alteraciones sufridas en la planificación respecto al plan inicial detallado en el capítulo2. El capítulo 8 recoge las contribuciones que se han realizado en este trabajo, las prin-cipales conclusiones que se han sacado durante la ejecución del proyecto y las líneas detrabajo futuro. 5
  19. 19. CAPÍTULO 1. INTRODUCCIÓN 6
  20. 20. Capítulo 2Documento de Objetivos del Proyecto2.1. Descripción Continuamente se buscan nuevas técnicas para el desarrollo de software con el obje-tivo de aumentar la productividad. En este proyecto se analiza cómo pueden ayudar loslenguajes específicos de dominio (DSL) y el desarrollo dirigido por modelos (MDD) enel cumplimiento de ese objetivo. Los DSL no son muy utilizados actualmente en la industria del software. Aún asíexisten cada vez más casos exitosos de su utilización en el desarrollo de software. En esteproyecto se analizará cuál es el estado de arte, cómo se han utilizado, los beneficios queaportan, y sus limitaciones. También se utilizarán varias herramientas para trabajar conDSL con el objetivo de analizar sus capacidades y limitaciones. Para analizar la viabilidad de la utilización de DSL en el contexto del proyecto, seimplementará un prototipo demostrador. Para realizar el prototipo demostrador se utilizaráun DSL ya existente o se definirá uno, y se definirán transformaciones del DSL a códigode implementación, con los cuales el código será generado automáticamente.2.2. Objetivos Los objetivos que se plantean en este proyecto son los siguientes: Analizar el estado del arte de los DSL y del MDD. Analizar el trabajo que se ha realizado en estos áreas y cómo se han utilizado para desarrollar software. Estudiar sus ventajas y desventajas. Analizar las herramientas disponibles para trabajar con DSL y MDD para estudiar 7
  21. 21. CAPÍTULO 2. DOCUMENTO DE OBJETIVOS DEL PROYECTO su utilización, sus capacidades y sus limitaciones. Desarrollar un prototipo demostrador utilizando los DSL y MDD.2.3. Alcance: entregas A continuación se detallan las entregas referentes a las diferentes tareas que se irándesarrollando durante la realización del proyecto: Entregable: planificación del proyecto Tipo: documento Word Fecha: 5/11/2008 Entregable: informe de seguimiento del proyecto Tipo: documento Word Fecha: cada cuatro semanas Entregable: documento de resultado del análisis del estado de arte Tipo: documento Word Fecha: 28/01/2009 Entregable: análisis de herramientas Tipo: documento Word Fecha: 25/03/09 Entregable: comparativa de herramientas Tipo: documento Word Fecha: 25/03/2009 Entregable: presentación de las ideas del prototipo Tipo: presentación PPT Fecha: 18/12/2008 Entregable: código y modelos del prototipo Tipo: código fuente y modelos de diseño Fecha: 1/06/2009 8
  22. 22. 2.4. DIAGRAMA EDT Entregable: memoria y presentación Tipo: documento PDF y presentación PPT Fecha: 15/07/20092.4. Diagrama EDT Figura 2.1: Diagrama EDT inicial2.5. Asignación de recursos Tabla 2.1: Asignación de recursos en la planificación inicial 9
  23. 23. CAPÍTULO 2. DOCUMENTO DE OBJETIVOS DEL PROYECTO2.6. Tareas2.6.1. Gestión Documento de objetivos del proyecto: realización de la planificación del proyecto. Reuniones: reuniones semanales con el tutor de la empresa. Seguimiento: análisis del estado del proyecto y posibles replanificaciones.2.6.2. Estudio de estado del arte Análisis de DSL: concepto, diferentes tipos, paradigmas, DSM, MDD. Estudio de mercado de herramientas existentes: estudio de mercado de herra- mientas existentes para trabajar con DSL.2.6.3. Análisis de herramientas Instalar herramientas: instalación de las distintas herramientas a analizar. Realizar ejemplos existentes: realización de ejemplos ya existentes para aprender a utilizar las herramientas. Definir ejemplos nuevos: definición de un ejemplo para analizar las capacidades y limitaciones de las herramientas.2.6.4. Desarrollo de prototipo Concepción: definición de la idea. Captura de requisitos: requisitos del prototipo demostrador. Diseño: diseño del prototipo. Implementación: definición de transformaciones de DSL a código. Testeo: testeo del funcionamiento del prototipo. 10
  24. 24. 2.7. DIAGRAMA DE GANTT2.6.5. Cierre Memoria: realización del documento que se entregará como resultado final del proyecto. Presentación: realización de la presentación que se utilizará en la defensa del pro- yecto.2.7. Diagrama de Gantt Figura 2.2: Diagrama de Gantt inicial2.8. Factores de riesgo A continuación se muestran los posibles factores de riesgo que se preveen durante larealización del proyecto y las respuestas que se darán si se producen. Que la herramienta no provea las capacidades esperadas para la realización del prototipo demostrador. Probabilidad: baja Acciones a llevar a cabo: analizar la posibilidad de usar otra herramienta para hacer el prototipo o cambiar la definición del prototipo Que los requisitos del prototipo no sean completos. Probabilidad: media Acciones a llevar a cabo: definir el prototipo más exhaustivamente hasta lograr unos requisitos completos 11
  25. 25. CAPÍTULO 2. DOCUMENTO DE OBJETIVOS DEL PROYECTO Que haya demasiada carga de trabajo y que no de tiempo a finalizar las tareas Probabilidad: media Acciones a llevar a cabo: ajustar el alcance del proyecto al tiempo disponible2.9. Método de trabajo2.9.1. Miembros del equipo del proyecto El equipo del proyecto constará de tres personas: director, tutor en la empresa yalumno. El contacto entre el alumno y el tutor de la empresa sera directo o por correoelectrónico. El contacto entre alumno y director, o tutor de la empresa y director se reali-zará por correo electrónico. Los miembros del proyecto son los siguientes: Director del proyecto: Oscar Diaz (oscar.diaz@ehu.es) Tutor en la empresa: Salvador Trujillo (strujillo@ikerlan.es) Alumno: Ander Zubizarreta (ander.zubizarreta@ikerlan.es)2.9.2. Reuniones Cada miércoles se realizará una reunión entre el tutor de la empresa y el alumno con elobjetivo de analizar el trabajo realizado durante la semana y definir nuevos compromisos.En caso de que no sea posible la realización de una reunión en la fecha indicada, éstapodrá ser cambiada a otra fecha cercana. Después de cada reunión el alumno redactará surespectivo acta.2.9.3. Seguimiento del proyecto. Cada cuatro semanas se realizará una reunión de seguimiento del proyecto entre elalumno y el tutor de la empresa con el objetivo de analizar el estado del proyecto y definiruna replanificación si fuese necesario. Estas reuniones darán como resultado documentosde seguimiento. 12
  26. 26. Capítulo 3Conceptos básicos En este capítulo se introducen algunos conceptos básicos que ayudarán a situarnos enel proyecto. En la primera sección se hace una introducción a los sistemas embebidos. Enla segunda se introduce brevemente la ingeniería de software, describiendo dentro de sucontexto algunos conceptos que facilitarán la comprensión de este trabajo.3.1. Sistemas embebidos Los microprocesadores han ido evolucionando con el tiempo. Existen microprocesa-dores cada vez más pequeños y baratos. Esto ha hecho que hayan sido “embebidos” enuna gran gama de productos que usamos a diario, con la intención de hacerlos “inteligen-tes” (Simon, 1999). Productos tales como relojes digitales, teléfonos móviles, ascensores,equipamiento de control industrial etc. son controlados mediante estos microprocesadoresy su software. Se suele llamar sistema embebido a cualquier sistema de computación queesté “escondido” dentro de otro producto, es decir, que sea una parte integral del sistemaentero.3.1.1. Características de los sistemas embebidos A diferencia de los ordenadores personales, que pueden usarse para una gran variedadde tareas dependiendo de su programación, los sistemas embebidos suelen ser normal-mente sistemas creados para un propósito específico, con el objetivo de cumplir con al-gunas funciones concretas, por lo que suelen ser normalmente sistemas preprogramados.Pueden ser sistemas muy simples, con un solo microcontrolador, o sistemas grandes ycomplejos que pueden estar compuestos de varias unidades de procesamiento, periféricosy redes, pudiendo ser encontrados tanto en un reloj digital de pulsera, como en el sistema 13
  27. 27. CAPÍTULO 3. CONCEPTOS BÁSICOSde control de una central nuclear. A la hora de trabajar con sistemas embebidos encon-tramos características propias que no son compartidas con los ordenadores personales oservidores. Estas son algunas de sus principales características: Los sistemas embebidos se construyen para un propósito específico, por lo que normalmente ofrecen un mayor rendimiento en las tareas para las que han sido diseñados. Muchas veces pueden requerir restricciones de tiempo real. Es decir, en determi- nadas situaciones deben reaccionar en un intervalo de tiempo definido, ya sea por cuestiones de seguridad o de usabilidad. Los recursos de hardware son normalmente limitados para reducir costes. Se busca el equilibrio entre el rendimiento y el coste según cuál sea el cometido del sistema. La interfaz de usuario suele ser normalmente dedicada y puede ser desde nula (sin ratón, monitor, teclado...) o muy limitada (LEDs, displays digitales...) en sistemas simples preprogramados para realizar pocas tareas, a conexiones de serie para inter- actuar desde un ordenador personal o hasta complejos sistemas gráficos con panta- llas táctiles. Hoy en día muchos sistemas embebidos permiten interactuar con ellos mediante una interfaz web a través de una conexión de red (e.g. configuración de routers). Están frecuentemente conectados a ambientes físicos mediante sensores para reco- lectar la información y actuadores para controlarla. Deben ser eficientes, tanto energéticamente como en el tamaño de código a ejecutar. Los sistemas embebidos son muchas veces creados para estar trabajando continua- mente durante años, por lo que tienen que ser confiables. La confiabilidad reúne los siguientes aspectos de un sistema (Marwedel, 2006): 1. Fiabilidad: Probabilidad de que el sistema trabaje correctamente y no falle. 2. Mantenibilidad: Probabilidad de que el sistema vuelva a trabajar correctamen- te en un intervalo dado de tiempo después de un fallo. 3. Disponibilidad: Probabilidad de que el sistema esté funcionando en un mo- mento dado. 4. Seguridad física: Que un fallo en el sistema no cause ningún daño. 14
  28. 28. 3.1. SISTEMAS EMBEBIDOS Figura 3.1: Sistema embebido en un aerogenerador 5. Seguridad informática: Confidencialidad y autenticación de las comunicacio- nes.No todos los sistemas embebidos cumplen todas las características anteriormente comen-tadas, ya que éstas pueden variar bastante dependiendo de la utilización que se le va a daral sistema. Por ejemplo en el sistema de control de una central nuclear lo más importantepuede ser tener un sistema confiable, aunque ésto requiera utilizar un sistema menos efi-ciente. En cambio, en un teléfono móvil un sistema eficiente energéticamente puede sermás importante. En Beuche (2003) se describen también las características de este tipo de sistemas;se muestra cuales son las diferencias entre el software para sistemas embebidos y noembebidos, y cuáles son los requisitos a seguir a la hora de desarrollar software parasistemas embebidos.3.1.2. Ejemplo de sistema embebido A continuación se muestra un ejemplo de sistema embebido imaginario y simplifica-do, pero basado en un caso real. Durante el proyecto se ha utilizado como ejemplo unsistema para el control de un aerogenerador, es decir, un sistema embebido en un molinode viento que se encarga de controlarlo. La figura 3.1 muestra los principales elementos por los que se compone un aerogene-rador. Como se puede apreciar, el sistema de control va insertado dentro del propio molinoy forma parte del aerogenerador. 15
  29. 29. CAPÍTULO 3. CONCEPTOS BÁSICOS Figura 3.2: Fases en el desarrollo de software Un aerogenerador puede tener varios elementos que tienen que ser controlados y mo-nitorizados. En este caso el sistema hace uso de distintos sensores colocados en distintospuntos del aerogenerador para recavar información del ambiente, como pueden ser la tem-peratura, la velocidad, etc. Entre los requisitos que tiene que cumplir el sistema embebidoen el aerogenerador están el de que tiene que ser un sistema en tiempo real y que tieneque estar trabajando continuamente los 24 horas al día, los 7 días de la semana.3.2. Ingeniería de software El mundo que nos rodea depende cada vez más de ordenadores y de software quelos controle. Grandes infraestructuras, sistema financiero y procesos industriales estáncomputerizados en su mayor parte. Por eso, la producción y el mantenimiento de softwarede calidad a un coste reducido adquiere gran importancia. La ingeniería de software es la disciplina que trata todos los aspectos relacionadoscon la producción de software, desde las primeras etapas de especificación, hasta el man-tenimiento una vez puesto en marcha el sistema (Sommerville, 2007). A fin de mejorarla productividad durante el desarrollo y la calidad del software, desde hace tiempo se haintentado encontrar metodologías que sean sistemáticas, predecibles y repetibles para laproducción de software.3.2.1. Fases en el desarrollo de software El proceso de desarrollo de software se divide normalmente en las siguientes fases: 16
  30. 30. 3.2. INGENIERÍA DE SOFTWARE Análisis de requisitos: La primera etapa del software es la extracción de requisi- tos. Partiendo de los requisitos especificados por el cliente y evitando que haya requisitos incompletos, ambiguos o contradictorios se obtiene como resultado la Especificación de los Requisitos del Sistema. Especificación: Es la tarea de describir el comportamiento esperado en el software que va a ser desarrollado. Diseño y arquitectura: En esta etapa se determina cómo funcionará el sistema de forma general y las funciones que realizará. Programación: Es la etapa donde se implementa el código en un lenguaje de pro- gramación, a partir del diseño Prueba: Consiste en comprobar que el software realiza correctamente las tareas indicadas en la especificación del problema. Documentación: Consiste en la documentación del software, del proceso de desa- rrollo y de la gestión del proyecto, con el fin de facilitar la inserción de correcciones, usabilidad, mantenimiento futuro o ampliaciones al sistema. Mantenimiento: Una vez finalizado el producto de software es importante el mante- nimiento. Éste puede consistir en corregir errores o extender el sistema para cumplir nuevos requisitos.Dependiendo del paradigma que se siga, estas fases pueden seguir una orden secuencial ono. Por ejemplo el desarrollo en cascada define el orden estrictamente secuencial, dondeuna fase no empezará hasta que se haya terminado la anterior (ver Figura 3.2). En cambio,en el desarrollo en espiral se vuelve una y otra vez a la misma fase.3.2.2. Automatización del desarrollo Desde los inicios de la ingeniería de software se ha tratado de automatizar en la medidade lo posible la producción de software. Con este objetivo se han utilizado diferentesmétodos, paradigmas y herramientas.CASE CASE es el acrónimo de Computer Aided Software Engineering o Ingeniería de Soft-ware Asistida por Ordenador y se ha utilizado durante años para referirse a las herramien-tas utilizadas en la ingeniería de software. Existen programas para ayudar en las distintas 17
  31. 31. CAPÍTULO 3. CONCEPTOS BÁSICOSetapas del desarrollo de software, tanto en el análisis de requisitos, diseño y modelado delsistema, como en la fase de documentación, prueba y mantenimiento con herramientasde generación de documentación, testeo o debugging. Cada vez más herramientas CA-SE incluyen además generadores que pueden generar, al menos en parte, el código deimplementación a partir de los modelos.MDD MDD es el acrónimo de Model Driven Development o Desarrollo de Software Diri-gido por Modelos. Éste es un paradigma emergente, donde el desarrollo del software secentra en los modelos con el objetivo de elevar el nivel de abstracción y automatizar la ge-neración del código de implementación. Aunque en el Capítulo 5 se profundiza sobre esteparadigma, a continuación se hace una breve exposición de los elementos que participanen él.Modelos: Los modelos son utilizados para representar un sistema. Se utilizan paraello lenguajes de modelado que normalmente son gráficos, y que pueden ser tanto depropósito general como específicos de dominio. Los elementos que pueden ser definidosen un modelo se especifican en el metamodelo.Metamodelos: Un metamodelo es el modelo de un lenguaje de modelado. Los len-guajes de modelado se definen utilizando metamodelos, en los cuales se especifica quéelementos puede tener un modelo, sus atributos, relaciones, restricciones etc. Es decir, unmetamodelo define la sintaxis abstracta de un lenguaje de modelado.Transformaciones de modelos: Las transformaciones de modelos definen transforma-ciones de unos modelos en otros, o generar código desde los modelos. Dependiendo dela salida de la transformación éstas pueden ser transformaciones de modelo a modelo, ode modelo a texto. Con una transformación de modelo a modelo se obtiene un modelodistinto del mismo sistema. Con una transformación de modelo a texto, en cambio, lasalida obtenida es texto, y normalmente suele usarse para generar código de implementa-ción. Las transformaciones se definen a nivel de metamodelado, mapeando los elementosdefinidos en él. 18
  32. 32. 3.2. INGENIERÍA DE SOFTWARE Figura 3.3: Línea de Producto SoftwareUML Unified Modeling Language (UML) es el lenguaje de modelado propuesto por el Ob-ject Management Group (OMG) para el modelado de sistemas de software (OMG, 2005).UML ofrece 13 tipos de diagramas divididos en dos grupos para modelar un sistema desoftware. Por una parte están los diagramas de estructura, que son utilizadas para repre-sentar la estructura estática del sistema. Entre ellos el diagrama de clases es uno de losmás utilizados, sobre todo cuando se trabaja en programación orientada a objetos. Por otraparte están los diagramas de comportamiento que son utilizados para describir el compor-tamiento dinámico del sistema. Entre ellos se encuentran el diagrama de casos de uso, deestados y de secuencia.SPL SPL es el acrónimo de Software Product Lines o Líneas de Producto Software. LasSPL proponen un sistema de producción basado en la reutilización de componentes enun determinado dominio. Ofrecen un paradigma para la creación de una familia de pro-ductos de software, donde se definen por un lado partes comunes de todos lo productos ypor otro las distintas variantes. Los distintos productos finales se consiguen mediante lacomposición de diferentes componentes. Una Linea de Producto Software puede ser definido como una colección de sistemasde software enmarcados en un dominio o segmento de mercado específico que compartenvarias características (Clements & Northrop, 2001; Pohl et al., 2006). La Figura 3.3 ilustra la idea de las Líneas de Producto Software, donde existen varioscomponentes que se componen dependiendo de las decisiones de producto, dando comoresultado diferentes productos finales (Krueger, 2008). Las SPL introducen la variabilidad en el desarrollo del software. Se profundiza sobreeste tema en el Capítulo 6. 19
  33. 33. CAPÍTULO 3. CONCEPTOS BÁSICOS3.2.3. Ingeniería de software vs. ingeniería de sistemas La ingeniería de sistemas es la disciplina que engloba todos los aspectos del desarrolloy evolución de un sistema complejo, donde el software puede jugar un rol importante.La ingeniería de sistemas engloba aparte de la ingeniería de software, el desarrollo delhardware y la puesta en marcha de todo el sistema. El trabajo de un ingeniero de sistemasconsiste en especificar el sistema, definir su arquitectura general e integrar las distintaspartes del sistema, sin participar en las partes específicas del sistema como pueden ser elhardware o software (Sommerville, 2007). La ingeniería de sistemas es una disciplina más antigua que la ingeniería de software.Pero con el incremento del uso del software en distintos sistemas, muchas veces se usantécnicas parecidas para ambas disciplinas. Ejemplo de ello es SysML (OMG, 2008a), unlenguaje de modelado de sistemas, creado como perfil de UML que se usa para modelarsoftware. 20
  34. 34. Capítulo 4Lenguajes Específicos de Dominio4.1. Estado del arte4.1.1. Introducción a los DSL Dentro del mundo de la informática los lenguajes son clasificados en distintas catego-rías. Por una parte se hace la distinción entre lenguajes de programación y lenguajes demodelado, por ejemplo Java y UML. La frontera entre estas dos categorías es cada vezmás borrosa debido a que muchas veces los programas son tratados como modelos, o losmodelos pueden ser ejecutables. Por otra parte, se distingue entre lenguajes de propósi-to general y lenguajes específicos de dominio, también llamados DSL, y en los que secentrará este capítulo. Tanto UML como Java pueden ser algunos ejemplos de la primeracategoría, mientras que SQL o HTML pueden ser ejemplos de DSL. Aún así, al igual queen la anterior clasificación, en este caso la frontera tampoco es tan clara ya que existenlenguajes específicos de dominio que han evolucionado hasta convertirse en lenguajes depropósito general. Tanto los lenguajes de propósito general, como los específicos de do-minio pueden clasificarse dentro de otras categorías, dependiendo de que sean gráficos otextuales, el paradigma que sigan, o sean imperativos o declarativos. Aunque el de los DSL no sea un concepto nuevo, ha sido en la última década cuandoha aumentado el interés por ellos, gracias sobre todo al surgimiento del paradigma dedesarrollo dirigido por modelos, donde se trabaja muchas veces con modelos específicosde dominio, y que es donde se centrará sobre todo este trabajo. 21
  35. 35. CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO<html ><body><h1>My F i r s t H e a d i n g < / h1><p>My f i r s t p a r a g r a p h . < / p>< / body>< / html > (a) (b) Figura 4.1: Ejemplos de DSL. (a) textual; (b) gráficoVentajas y desventajas A diferencia de los lenguajes de propósito general, que son diseñados para ser utili-zados en una gran variedad de tareas, los DSL son diseñados para ser útiles en un deter-minado area o dominio (e.g. SQL en bases de datos). Los DSL son normalmente menoscompletos, pero más expresivos en su dominio. Al usar el lenguaje términos propios deldominio para el que ha sido diseñado, se obtiene un mayor nivel de abstracción, facili-tando la expresión de problemas o soluciones más claramente que con otros lenguajes depropósito general. Esto facilita su aprendizaje por parte de las personas que trabajan en elámbito del dominio. La popularidad de los DSL va incrementando gracias al auge del modelado específicode dominio, ya que sus ventajas son numerosas. La utilización de los DSL ayuda a mejo-rar la calidad, productividad, fiabilidad, mantenibilidad, portabilidad y reutilización. Noobstante, no todos son ventajas, sobre todo a la hora de diseñar el lenguaje, ya que esta-blecer el alcance apropiado del lenguaje puede ser una tarea difícil y requiere un análisismuy profundo del dominio, al que hay que sumarle el coste de diseño, implementación ymantenimiento.DSL gráficos vs DSL textuales Como ya se ha comentado, los lenguajes específicos de dominio pueden ser tantográficos como textuales. Ejemplos de DSL textuales pueden ser SQL para la interaccióncon bases de datos, o HTML para visualización de páginas web, mostrado en la Figura4.1a. En este ejemplo se puede ver como se define la visualización de un título o de unpárrafo en un documento HTML (W3C, 1999). 22
  36. 36. 4.1. ESTADO DEL ARTE Figura 4.2: Diagrama de tres niveles La utilización de DSL gráficos va muy unido al desarrollo de software dirigido pormodelos. Normalmente los DSL gráficos suelen ser lenguajes de modelado, desde los quese puede generar código de implementación o documentación, y que se analizará más afondo en el siguiente capítulo. La utilización de lenguajes de modelado específicos dedominio permite elevar aún más el nivel de abstracción. Como ejemplo de DSL gráficosse puede comentar por ejemplo SPEM (Software Process Engineering Meta-Model), quees un lenguaje para la definición de procesos de ingeniería de software (OMG, 2008b). Enla Figura 4.1b se puede ver un ejemplo de la definición de un proceso mediante SPEM.4.1.2. Diseño de DSL El diseño de lenguajes específicos de dominio requiere aparte de conocimientos rela-cionados con el desarrollo de lenguajes, un profundo conocimiento del dominio para elque se va a diseñar el lenguaje. Esto supone un gran esfuerzo, por lo que es importantesaber cuándo conviene utilizar un DSL y cuándo no. Además, no hay ninguna metodolo-gía definida para el diseño de estos lenguajes, aunque sí que se ha escrito sobre algunaspropuestas de pasos a seguir y buenas prácticas (Mernik et al., 2005; Völter, 2008). Mernik et al. (2005) diferencian cinco fases en el proceso de desarrollo de un DSL:decisión, análisis, diseño, implementación, y puesta en marcha. Este proceso no tieneporque ser secuencial, ya que, por ejemplo, la decisión de crear un DSL puede ser conse-cuencia de un análisis previo. Decisión: Tomar la decisión de crear un DSL no es una tarea fácil, y puede depender de muchos factores. Un DSL se crea con la intencionalidad de mejorar la producti- vidad, ahorrando costes en el desarrollo y mantenimiento de software, pero su uso no está siempre justificado, ya que el coste de la creación del DSL puede ser mayor que el ahorro que supondrá en un futuro. La adopción de un DSL ya existente puede 23
  37. 37. CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO resultar una opción más económica, por lo que es conveniente buscar alternativas antes de empezar el diseño de un DSL desde cero. Análisis: En la fase de análisis se identifica el dominio del problema y se obtiene el conocimiento necesario desde diversas fuentes, como pueden ser documentos téc- nicos, conocimiento de los expertos del dominio, código ya existente en lenguajes de propósito general, etc. Como resultado del análisis se obtiene una terminología específica del dominio y una semántica expresada de manera más o menos abstrac- ta. Diseño: El diseño de un DSL puede hacerse partiendo desde cero, pero esto puede resultar una tarea extremadamente difícil. Una opción más fácil es la de partir de un lenguaje ya existente, ya sea utilizando parte de sus características, restringiéndolo para hacerlo más simple, o extendiéndolo para añadirle nuevas características. Cua- drado et al. (2006) y Hudak (1996) presentan algunos ejemplos de DSL embebidos en otros lenguajes de propósito general. Implementación: La implementación de un DSL como si fuese un lenguaje de pro- pósito general puede ser algo muy costoso. En este trabajo la implementación se ha realizado mediante técnicas de metamodelado, es decir, creando modelos del lenguaje. Puesta en marcha: Para la puesta en marcha de un DSL después de realizar los pasos previos es muy importante facilitar al usuario la implantación del DSL en su entorno de desarrollo.Como se ha comentado, durante el transcurso de este proyecto se han utilizado las he-rramientas de metamodelado para crear los DSL. En el siguiente capítulo, dedicado aldesarrollo dirigido por modelos, se profundizará más en el concepto de metamodelo, pe-ro éste es básicamente un modelo del DSL. En un metamodelo se definen los elementosque puede tener un DSL o modelo, y cómo se relacionan entre ellos, es decir, una sinta-xis abstracta. El metamodelo es definido utilizando los elementos que han sido definidosanteriormente en el meta-metamodelo. Los elementos comentados se representan en undiagrama de tres niveles, tal y como muestra la Figura 4.2 (Kurtev et al., 2006). Al diseñarun DSL se trabaja en el nivel M2, es decir, hay que crear el metamodelo. El usuario finaldel DSL trabajará en el nivel M1. 24
  38. 38. 4.1. ESTADO DEL ARTE Figura 4.3: DSL para desarrollar aplicaciones para Nokia4.1.3. Uso de DSL en la industria Aunque la implantación de los DSL en la industria no es muy grande, existen ejemplosexitosos de su utilización (DSM-Forum, 2008). Un ejemplo de uso de DSL en empresases el de Nokia, compañía dedicada a los aparatos de telefonía móvil (MetaCase, 2007).Ejemplo: Nokia Con el aumento de usuarios de telefonía móvil en los últimos años, éste se ha conver-tido en un sector realmente competitivo. Los aparatos de telefonía móvil continuamenteincluyen nuevas características, y el software que lleva el aparato se ha convertido en unaspecto crítico desde el punto de vista del consumidor, ya que es el que proporcionarálas distintas características del teléfono. Para los fabricantes, el tiempo de salida al mer-cado es sumamente importante, ya que el lanzamiento de un producto un mes antes queel competidor se puede traducir en grandes cantidades de ingresos. En este sentido, laproductividad en el proceso de desarrollo es vital. Con el objetivo de incrementar su competitividad, Nokia buscaba un método paramejorar la productividad aplicando las siguientes estrategias: Trabajar a un mayor nivel de abstracción, centrándose en el diseño en vez de en la implementación. 25
  39. 39. CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO Trabajar en términos del dominio, permitiendo a los desarrolladores un aprendizaje mas rápido de las herramientas de desarrollo, gracias a su familiarización con el dominio. Generación automática de código desde los diseños.La solución implementada por Nokia ha sido el de crear su propio DSL de modeladoy definir generadores de código y documentación que automaticen el proceso de imple-mentación. Para ello, Nokia ha utilizado la herramienta MetaEdit+, que se presenta enla siguiente sección. Esta solución permite a los desarrolladores de Nokia trabajar direc-tamente con conceptos propios del dominio en los modelos que diseñan, sin tener querelacionar cada concepto del dominio con un elemento del lenguaje de modelado comoocurriría al usar UML. La Figura 4.3 muestra un modelo definido con un DSL para desa-rrollar aplicaciones para teléfonos Nokia. La aplicación de los DSL ha supuesto importantes beneficios a esta compañia entrelos que se encuentran los siguientes: Disminución de tiempo de desarrollo y aumento de productividad por 10 veces. Posibilidad de centrarse en la funcionalidad del software a producir, y no en la implementación. Generación automática desde los modelos casi al 100 %. Generación automática de documentación. Reducción de costes de formación para nuevos desarrolladores de 6 meses a 2 se- manas, gracias al nivel de abstracción y la familiaridad con el dominio.Viendo los grandes beneficios en la producción que ha traído a varias compañias la incor-poración de los DSL, es previsible que su utilización vaya en aumento los próximos años,ligado probablemente a la utilización del MDD.4.2. Herramientas Existen varias herramientas para la creación de DSL. En este trabajo se han analizadodos de ellos, que permiten la creación de lenguajes específicos de modelado medianteel metamodelado. La primera herramienta utilizada ha sido MetaEdit+, una herramien-ta comercial que facilita el diseño de DSL gráficos. La otra ha sido Eclipse Modeling 26
  40. 40. 4.2. HERRAMIENTAS MetaEdit+ Eclipse EMF M3 GOPPRR Ecore M2 DSL definido con GOPPR DSL definido con Ecore M1 Modelo definido con DSL Modelo definido con DSL Tabla 4.1: Elementos del diagrama de 3 niveles en cada herramienta Figura 4.4: Metamodelado utilizando GOPPRR en MetaEdit+Framework (EMF), herramienta libre, integrada en Eclipse, que ofrece un entorno paratrabajar con modelos. Ambas herramientas permiten definir los metamodelos utilizandoun lenguaje de metamodelado o meta-metamodelo. En este capítulo solo se analiza parte de las herramientas, ya que éstas ofrecen másfuciones aparte del diseño de DSL. Se hace una breve descripción de las herramientas y semuestran sus características más importantes relacionadas con el diseño de lenguajes demodelado. Las ventajas y limitaciones de cada herramienta se detallan en el siguiente ca-pítulo, dedicado al MDD, donde se completa el análisis de las herramientas. Para finalizaresta sección se hace una breve comparativa de ambas herramientas. 27
  41. 41. CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO Figura 4.5: Modelado con MetaEdit+4.2.1. MetaEdit+Descripción MetaEdit+ es una herramienta comercial desarrollada por MetaCase1 . Esta herramien-ta ofrece un entorno para diseñar lenguajes de modelado específicos de dominio, con loscuales se pueden definir modelos y generar código de implementación a partir de ellos.Este capítulo se centra sólo en la parte de diseño de DSL que ofrece esta herramienta,dejando la parte de la generación de código para el siguiente capítulo.Características MetaEdit+ permite definir gráficamente y de manera fácil un DSL de modelado. Dis-pone para ello de su propio lenguaje de metamodelado llamado GOPPRR (Graph, Object,Property, Port, Relationship, Role), que engloba todos los tipos de elementos que se pue-den definir en un metamodelo. Con GOPPRR se definen los diferentes tipos de elementos que podrá tener un modelo,con sus propiedades. Se definen también las relaciones entre los distintos tipos de objetos,y el rol que cada objeto jugará en una relación. También se pueden definir puertos en losobjetos, para especificar la forma que tendrán las relaciones, como por ejemplo de quéparte de un objeto podrá salir una relación. 1 http://www.metacase.com/ 28
  42. 42. 4.2. HERRAMIENTAS Aparte de la herramienta gráfica para definir metamodelos, MetaEdit+ también ofreceuna herramienta basada en formularios para el mismo propósito. Esta herramienta estáen realidad compuesta por seis herramientas, y permite definir más detalles a la hora dediseñar un DSL: Object tool: para especificar tipos de objetos del metamodelo Relationship tool: para indicar los conectores entre tipos de objetos Role tool: para indicar el rol que juega un determinado tipo de objeto en una deter- minada relación Port tool: para especificar cómo los tipos de roles se conectan con los tipos de objetos Graph tool: para establecer las reglas para la conexión de objetos, relaciones, roles y puertos definidos Property tool: para modificar las propiedades de cualquier tipo de elemento y para crear nuevos tipos de datosOtra utilidad de la que dispone esta herramienta es la de diseñar figuras propias parautilizarlas en los modelos, pudiéndose crear de esta manera elementos con aparienciarelacionada con lo que representan dentro del dominio, haciendo que el lenguaje diseñadosea más intuitivo y más representativo. Una vez definido el lenguaje de modelado, podemos exportarlo en formato MetaEdit+XML Types (MXT). Al exportarlo se crea un fichero con la extensión .mxt, que contie-ne toda la información del lenguaje de modelado definido. Importando el metamodelootra vez a MetaEdit+ podremos utilizar el lenguaje diseñado para crear nuestros modelosespecíficos de dominio. Los formatos utilizados por MetaEdit+ para exportar metamodelos y modelos sonpropios, por lo que no son compatibles con otras herramientas. Aún así, esta herramientaofrece una API que permite acceder a la información de los modelos definidos en ella. La Figura 4.4 muestra un metamodelo creado con MetaEdit+ que se describirá másprofundamente más adelante, en la seccíon donde se muestra un caso de estudio. La Fi-gura 4.5 muestra un modelo creado utilizando el lenguaje definido en la Figura 4.4. Ladefinición de modelos es también totalmente gráfica y se realiza con el editor de diagra-mas que para ello ofrece la herramienta. En resúmen, esta herramienta ofrece un lenguaje de metamodelado, con el que defi-nimos un DSL de modelado que se usará para definir modelos específicos de dominio. 29
  43. 43. CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO Figura 4.6: Metamodelado con EcoreEstos elementos se muestran en la Tabla 4.1, cada uno en uno de los niveles descritos enla Figura 4.2.4.2.2. EMFDescripción Eclipse Modeling Framework (EMF) es también una herramienta que permite definirDSL de modelado gráficamente. Esta herramienta es el framework que ofrece Eclipsepara el MDD (Eclipse, 2009) y es software libre. Es una herramienta extensible medianteplugins, que ofrece también herramientas para transformaciones de modelos y generaciónde código. En este capítulo nos centramos en la utilidad de esta herramienta para crearDSL de modelado, para el cual dispone del lenguaje de metamodelado llamado Ecore.Características El diseño de un DSL de modelado con EMF se puede realizar gráficamente medianteel lenguaje de metamodelado Ecore. La herramienta dispone para ello de un editor dediagramas donde se permite definir diagramas Ecore. Un diagrama Ecore consiste básica-mente en un diagrama de clases, donde se definen mediante clases los tipos de elementosque se podrán incluir en un modelo con el lenguaje creado. También se definen en eldiagrama los atributos que tendrán los distintos elementos, y cómo estarán relacionadosentre ellos. La Figura 4.6 muestra el metamodelo creado en EMF utilizando ecore, para definir 30
  44. 44. 4.2. HERRAMIENTAS Figura 4.7: Modelado con EMFun lenguaje de modelado que permita representar sistemas. Este metamodelo se describemás adelante en la sección donde se muestra un caso de estudio. Aparte de crear los DSL utilizando directamente Ecore, es posible importar DSL dise-ñados en otros lenguajes. Es posible definir un lenguaje utilizando el diagrama de clasesde UML, el lenguaje de metamodelado KM3 o XML Schema, e importarlo a EMF, el cualgenerará automáticamente un modelo Ecore desde el fichero importado. Una vez definido el metamodelo, EMF ofrece la opción de generar un plugin parapoder utilizar el editor de modelos para definir modelos específicos de dominio. La Figura4.7 muestra el editor de modelos para crear modelos en el lenguaje definido en la Figura4.6. El modelo de la Figura 4.7 conforma al metamodelo de la Figura 4.6. EMF también ofrece la posibilidad de crear un editor totalmente gáfico con la aparien-cia de los elementos personalizada, al estilo de lo que ofrece MetaEdit+. Dispone para ellode la herramienta Graphical Modeling Framework (GMF). Esta herramienta permite crearun editor de diagramas para el lenguaje de modelado definido con Ecore, especificandopara ello cuáles serán los elementos y relaciones que podrán aparecer en un diagrama delmodelo y cómo. El formato utilizado para exportar e importar metamodelos y modelos por EMF esXML Metadata Interchange (XMI). XMI (OMG, 2007) es una especificación definidapor MOF y que es también implementada por otras herramientas, lo que hace posible la 31
  45. 45. CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIOinteroperabilidad de EMF con ellas.4.2.3. Comparativa Aunque el lenguaje de metamodelado disponible en cada herramienta sea distinto, elproceso de definición de un lenguaje de modelado es muy similar con ambas herramien-tas. Este proceso trata básicamente de definir elementos, propiedades y relaciones que sepodrán utilizar en un modelo. Se puede decir, en este aspecto, que la facilidad de uso deambas herramientas es más o menos la misma. Donde existe más diferencia entre las dos herramientas analizadas, es a la hora deutilizar el DSL de modelado diseñado. Mientras MetaEdit+ ofrece automáticamente uneditor gráfico de diagramas para dibujar modelos con el lenguaje diseñado, el editor demodelos ofrecido por EMF no es tan expresivo, ya que en éste el modelo se define enforma de árbol, y no con un diagrama. Como se ha comentado, EMF ofrece la posibilidadde crear un editor de diagramas con GMF para nuestro lenguaje de modelado, pero estatarea puede resultar bastante difícil. Se puede decir que en este aspecto la herramientaMetaEdit+ es más completa y está bastante más lograda. Durante el proyecto hacer unejemplo con MetaEdit+ ha requerido menos tiempo que hacer el mismo ejemplo conEMF. Una baza a favor de EMF es su extensibilidad, ya que mediante el uso de pluginsse puede obtener una herramienta muy completa con una gran variedad de utilidades.Además dispone de una gran comunidad de desarrolladores y usuarios que mantienenmuy activo el portal de noticias de EMF, donde se puede obtener ayuda de cualquier tipo.También comentar a favor de esta herramienta su compatibilidad con otras herramientastanto libres como comerciales gracias al formato XMI que utiliza. Otro aspecto a favor de EMF y que ha sido muy útil durante la realización de esteproyecto es la posibilidad de crear DSL desde XML Schema, pudiendo tratar ficherosXML que conforman al Schema como modelos. Existen trabajos que muestran cómo hacer compatibles las dos herramientas presen-tadas. En Kern (2008) se muestra cómo se pueden intercambiar metamodelos y modelosentre ambas herramientas. Como conclusión se puede decir que aunque EMF sea una herramienta más completay versátil, la facilidad ofrecida por MetaEdit+ para la definición y utilización de DSL demodelado es superior a la ofrecida por EMF. Es importante analizar para qué se va a usarla herramienta y qué se quiere obtener de ella antes de decidirse por una u otra. Ademásal ser una comercial y la otra libre, el precio y el soporte ofrecido pueden ser también 32
  46. 46. 4.3. CASO DE ESTUDIOfactores muy influyentes.4.3. Caso de estudio A continuación se muestra un caso de estudio simplificado para ilustrar cómo se defineun DSL de modelado para diseñar un sistema de control de inundaciones. Primero sedescribe el caso de estudio y se presenta cuál es el sistema a definir. A continuación semuestra cómo hemos definido un lenguaje de modelado con MetaEdit+ y otro con EMFpara describir este tipo de sistemas y cómo se han utilizado.4.3.1. Descripción Este caso de estudio se basa en un sistema de control de inundaciones. Se trata deun sistema embebido compuesto por varios subsistemas que controlan diferentes partesdel sistema. Este sistema de control de inundaciones recoge información del ambiente, ybasándose en los datos recopilados fija unos niveles de alerta y ejecuta unas determinadasacciones. Por ejemplo, puede disponer de un subsistema que controle las precipitaciones,y que puede indicar un nivel de alerta alto en caso de que sean abundantes. Un sistema está básicamente compuesto por subsistemas que reciben unos datos deentrada y en base a los cuales generan unos datos de salida o ejecutan alguna acción.Es decir, los elementos principales de un sistema son los subsistemas, las entradas y lassalidas, y son éstos los que serán definidos en los metamodelos.4.3.2. Definición del lenguaje de modeladoMetaEdit+ La Figura 4.4 muestra el metamodelo definido en MetaEdit+ utilizando su lenguajeGOPPRR. En este metamodelo se han definido los elementos principales que puede tenerun sistema mediante objetos, a los que se les han añadido sus respectivos atributos. Tam-bién se han añadido las diferentes relaciones entre los distintos objetos. En cada relaciónse ha definido a su vez el rol que juega cada objeto que participa en él, y donde se indica lacardinalidad. Como se puede ver, un subsistema estará compuesto de varios subsistemasque tendrán al mismo tiempo varias entradas y salidas. Para poder utilizar el lenguaje definido primero hay que importarlo a MetaEdit+. Estose puede hacer con el botón Build (ver Figura 4.4), el cual exporta el metamodelo en unfichero MXT y lo importa a MetaEdit+ para poder empezar a usarlo. 33
  47. 47. CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO En este ejemplo, después de definir el metamodelo se ha personalizado la aparienciaque tendrá cada objeto en los modelos con la herramienta Object Tool.EMF La Figura 4.6 muestra el metamodelo que se ha definido utilizando Ecore en EMF,donde se han utilizado clases, atributos y relaciones. Se ha definido una clase para cadatipo de elemento que tendrá un modelo que represente un sistema de control de inun-daciones. Como se puede ver, se ha especificado una clase llamada System que tiene unnombre y una descripción. Tal y como se ve en la Figura 4.6, el sistema puede tener variossubsistemas y siempre tendrá al menos uno. Igualmente, un subsistema también tiene unnombre y una descripción, y se compone de varias entradas y salidas, que se definen conlas clases Input y Output respectivamente. A cada una de estas clases se le han definidotres atributos para indicar el nombre, la descripción y el tipo de datos. Una vez definido el metamodelo con EMF se genera el plugin para crear el editorde modelos que se utilizará para diseñar nuestro tipo de sistemas. Utilizando este editorpodemos definir diferentes sistemas de control de inundaciones.4.3.3. Utilización del lenguaje de modeladoMetaEdit+ Una vez definido el metamodelo, MetaEdit+ ofrece un editor de diagramas para definirmodelos que conformen al metamodelo. En la Figura 4.5 se muestra el modelo de unsistema de control de inundaciones llamado UK01. Este modelo contiene los elementosdefinidos en el metamodelo, y como se puede apreciar, cada tipo de elemento tiene unaapariencia diferente que hemos definido utilizando el Object Tool. En el modelo se puede ver que el sistema UK01 está compuesto por tres subsistemasque sirven para controlar la temperatura, las precipitaciones, y el nivel de la presa. Elprimero recibe como entrada los valores de temperatura medidas en tres puntos diferentesy devuelve como salida un nivel de alarma. El segundo hace lo propio, pero en este casorecibe como entrada datos de precipitaciones. El tercero controla la compuerta de la presabasándose en sus estado y en el nivel del agua. Es posible extender el sistema añadiendo más subsistemas al modelo, o añadiéndolemás entradas o salidas a los subsistemas existentes. 34
  48. 48. 4.3. CASO DE ESTUDIOEMF La Figura 4.7 muestra el modelo del sistema de control de inundaciones UK01 defini-do con EMF. Este modelo conforma al metamodelo definido anteriormente. Este modelocontiene los mismos elementos definidos en el modelo de MetaEdit+, es decir, tres sub-sistemas, de temperatura, de precipitaciones y de la presa, cada uno con sus entradas ysalidas. Este modelo es una instancia particular del metamodelo definido con Ecore. Se pue-den definir tantos sistemas como se quiera, cada uno con sus subsistemas, entradas ysalidas correspondientes. También se puede completar el modelo definido añadiéndolemás subsistemas que controlen otros componentes.4.3.4. Beneficios obtenidos Con el estudio de este caso se pueden observar algunos de los beneficios obtenidospor la utilización de un DSL. Aunque la definición de un DSL requiera esfuerzo y tiempo, se ha conseguido definirun sistema con términos propios del dominio. Eso hace que el nivel de abstracción con-seguido sea mayor, obteniendo como resultado una mayor expresividad en los modelos.Utilizando UML, por ejemplo, podríamos empezar enseguida a definir nuestro sistema,pero tendríamos que asociar cada elemento de UML a un elemento del dominio, y laexpresividad lograda no sería muy alta. En cambio, con la utilización de un DSL repre-sentamos directamente elementos del dominio con elementos del lenguaje. La expresividad lograda permite reducir el tiempo de formación de nuevos desarrolla-dores, ya que utilizar el DSL se hace más intuitivo. Eso permite, además, reducir el costede desarrollo, que se traduce en un incremento de la productividad. Si añadimos a todo loanterior la generación automática de código, los beneficios pueden ser aún mayores, tal ycomo se verá en el siguiente capítulo. 35
  49. 49. CAPÍTULO 4. LENGUAJES ESPECÍFICOS DE DOMINIO 36
  50. 50. Capítulo 5Desarrollo de Software Dirigido porModelos El Desarrollo de Software Dirigido por Modelos o Model Driven Development (MDD)es un paradigma de desarrollo de software donde éste se centra en los modelos. En estecapítulo se presentan los principales elementos que participan en el MDD. Seguidamentese analiza una serie de herramientas para la definición de modelos y generación de código,y finalmente se muestra un caso de estudio que se ha realizado durante el proyecto.5.1. Conceptos básicos5.1.1. MDD El MDD es un paradigma donde el desarrollo de software está dirigido por modelosy transformaciones de modelos. Los programas son representados mediante modelos quepueden ser transformados en otros modelos o en texto. En este paradigma los modelos Figura 5.1: Escenario MDD 37
  51. 51. CAPÍTULO 5. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOStienen especial importancia, ya que no son solo elementos de diseño o documentación,sino que son también parte de la implementación. Las transformaciones se definen nor-malmente para la generación automática de código desde los modelos. Esta generaciónautomática permite al desarrollador centrarse en definir “qué” hace un sistema de softwa-re en vez de definir “cómo” lo hace, sin entrar en detalles de la implementación ademásde facilitar tareas muy repetitivas a la hora de implementación y evitar la inserción invo-luntaria de errores que se puede producir al escribir código a mano. Además, al trabajar anivel de modelos se consigue un mayor nivel de abstracción. Según Kontio (2005), los beneficios que ofrece el MDD son el aumento de la pro-ductividad, la reducción de costes, la reducción de tiempo de desarrollo, y una mejoríade la calidad. Generalmente la razón más importante para utilizar el MDD es el aumentode la productividad, por las ventajas económicas que ello supone (OMG, 2009; Herst &Roman, 2003). Los modelos utilizados en el MDD son mayoritariamente específicos de dominio, porlo que el MDD va muy unido a los DSL. La utilización de modelos durante el diseño delsoftware ha ido creciendo, sobre todo gracias a UML, y los intentos de generar códigoautomáticamente desde los modelos UML también han sido muchos. Pero al ser UML unlenguaje de modelado de propósito general no es fácil definir una transformación generalque valga para generar código de implementación desde cualquier modelo. Existen he-rramientas que lo hacen parcialmente, sobre todo la generación de la estructura o de lasclases, pero no todo el programa. Al definir los programas utilizando modelos específicosdel dominio, es más fácil definir transformaciones que puedan generar el código deseado,además de que el nivel de abstracción se eleva aún más y se consigue mayor expresivi-dad. Los elementos que pueda tener un modelo específico de dominio son definidos pormetamodelos. La Figura 5.1 muestra los principales elementos que participan en el MDD, que sonlos modelos, metamodelos y transformaciones de modelos.5.1.2. Modelo Un modelo es una representación de la realidad mediante abstracciones. Un modelomuestra la representación de un sistema o parte de él con el objetivo de ofrecer infor-mación para un propósito específico (Kurtev, 2005). Para ello se utiliza un lenguaje demodelado, que es definido mediante un metamodelo. En las Figuras 4.5 y 4.7 se mostra-ban dos modelos de un mismo sistema. 38
  52. 52. 5.1. CONCEPTOS BÁSICOS5.1.3. Metamodelo Un modelo es normalmente una instancia que conforma a un metamodelo (Figura4.2). Un metamodelo es el modelo de un lenguaje de modelado en el que el lenguajees especificado (Kurtev, 2005). En otras palabras, el metamodelo describe los elementosdel dominio, sus relaciones y algunas restricciones básicas. En el Capítulo 4 se mostrabacómo se definía un metamodelo para crear un lenguaje de modelado (ver Figuras 4.4 y4.6).5.1.4. Transformaciónes de modelos Las transformaciones de modelos son un elemento clave en el MDD. Una transfor-mación es el proceso de convertir un modelo en otro modelo del mismo sistema (OMG,2003). Generalmente mediante una definción de transformación de modelos se generaun modelo de salida a partir de un modelo de entrada. El modelo de salida puede seruna representación distinta del mismo sistema, o bien la implementación del mismo. Lastransformaciones son definidas mediante lenguajes de transformación, que permiten defi-nir mapeos entre el modelo de entrada y de salida, o entre el modelo de entrada y el textode salida (Kurtev, 2005; Sendall & Kozaczynski, 2003). Dependiendo de la salida, una transformación de modelos se puede clasificar comotransformación de modelo a modelo, o transformacion de modelo a texto. El primero tomacomo entrada uno o varios modelos que conforman a un metamodelo, y devuelve comosalida uno o varios modelos que conforman al mismo u otro metamodelo. El segundoproduce texto como salida, que puede ser código de implementación, documentación ocualquier otro tipo de texto.Transformación de modelo a modelo Las transformaciones de modelo a modelo normalmente definen mapeos entre losmetamodelos de entrada y salida. Los metamodelos de entrada y salida pueden ser losmismos o diferentes, y aplicando la transformación al modelo de entrada se consiguecomo salida otra representación del sistema. Las transformaciones se definen utilizandolenguajes de transformación. Algunos lenguajes son declarativos y permiten mapear ele-mentos del metamodelo de entrada con el de salida. Otros son imperativos y permitengenerar el modelo de salida mediante la utilización de reglas. Muchos lenguajes permi-ten la definición de transformaciones usando ambos estilos de programación. Existen unagran variedad de lenguajes, tanto libres como comerciales, para definir transformaciones 39
  53. 53. CAPÍTULO 5. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOSentre modelos. Algunos ejemplos son ATL (Bézivin et al., 2003), RubyTL (Cuadradoet al., 2006), y ATC (Sánchez-Barbudo et al., 2008). En este trabajo se han utilizado ATLy MQL que es el lenguaje que utilizan las herramienta comerciales MDWorkbench (So-dius, 2009a) y RulesComposer (Sodius, 2009b).Transformación de modelo a texto Las transformaciones de modelo a texto definen el mapeo entre uno o varios metamo-delos de entrada y texto de salida. Normalmente son definidos mediante la combinaciónde reglas y plantillas de texto. Suelen ser utilizados, en general, para la generación au-tomática de código de implementación a partir de un modelo de entrada, pero tambiénpueden ser utilizados para generar documentación a base de la información que ofreceel modelo, o para generar cualquier otro tipo de texto. Los lenguajes de transformaciónde modelo a texto analizados durante el proyecto han sido MERL utilizada por MetaE-dit+ (MetaCase, 2009), MOFScript (SINTEF, 2009) y TGL, éste ultimo utilizado por lasherramientas MDWorkbench y RulesComposer anteriormente citadas.5.2. Herramientas Durante el transcurso de este proyecto se han utilizado varias herramientas para traba-jar con MDD. Algunas de esas herramientas ya se han analizado en parte en el Capítulo 4,dedicado a los lenguajes específicos de dominio, ya que combinan ambos conceptos. Eneste capítulo se analizarán las herramientas desde el punto de vista del MDD. Tambiénse analizan otras herramientas; algunas de ellas incorporan el entorno completo para eldesarrollo dirigido por modelos; otras son plugins o add-ons que trabajan conjuntamentecon otras herramientas y dependen de ellas. En esta sección se analizarán todas inde-pendientemente, pero especificando como interactúan con otras y se hará una pequeñacomparativa.5.2.1. MetaEdit+Descripción En el capítulo anterior se mostraba cómo utilizar esta herramienta para crear DSLgráficos que podían ser utilizados para definir modelos de un sistema. MetaEdit+ ofrecetambién un generador de texto que permite generar ficheros textuales desde los modelos. 40
  54. 54. 5.2. HERRAMIENTAS Figura 5.2: Transformacion MetaEdit+Características MetaEdit+ trae algunas transformaciones ya definidas que pueden ser útiles para ob-tener información de los modelos; entre ellas se encuentran las que generan listas con loselementos del modelo, o exportan el modelo a un fichero HTML o a un documento Word.Aparte de estas transformaciones, MetaEdit+ también permite definir transformaciones demodelo a texto utilizando su propio lenguaje de transformaciones llamado MERL (Me-taEdit+ Reporting Language). La Figura 5.2 muestra la herramienta de MetaEdit+ utilizada para definir las transfor-maciones. La forma de definir una transformación en MetaEdit+ es realizando una itera-ción de todos los objetos del modelo, obteniendo la información de los distintos elementose introduciéndolos en una plantilla de texto. El lenguaje MERL ofrece varios comandospara acceder a los distintos elementos de un modelo. Una transformación comienza conla definición de la transformación y del fichero de salida. Normalmente toda la definiciónde la transformación va dentro de una sentencia foreach() donde se itera en un tipo deelementos definidos en el modelo. Por ejemplo, en la Figura 5.2 se itera en los objetosdel tipo Controllable que se encuentran en el modelo. A partir de ahí se navega sobretodo el modelo obteniendo la información de los diferentes elementos. El lenguaje MERLofrece algunas sentencias de control y navegación existentes en la mayoria de lenguajes, 41
  55. 55. CAPÍTULO 5. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOStales como if, foreach o dowhile. También ofrece algunos comandos para obtener lainformación de los elementos del modelo que se están recorriendo, tales como type, id,objectid etc. Se puede generar cualquier tipo de texto utilizando el generador de MetaEdit+ yasea código, documentación o cualquier otro fichero textual, pero en cambio no ofrece laposibilidad de definir transformaciones entre modelos. En Kelly & Tolvanen (2008) se pueden encontrar varios ejemplos realizados con estaherramienta.Ventajas y limitaciones Entre los aspectos positivos de esta herramienta cabe destacar la facilidad de uso aldefinir lenguajes específicos de modelado con GOPPRR. La definición de modelos conel DSL creado es también muy fácil. La herramienta permite realizar todas las tareasgráficamente de forma muy sencilla, además de facilitar la creación de iconos propios parautilizar en los modelos, haciendo que éstos sean identificados fácilmente como elementosdel dominio. La expresividad conseguida a la hora de modelar con esta herramienta esmuy alta. Otro aspecto positivo a comentar es que la herramienta está muy bien documentadacon varios ejemplos y tutoriales, lo que posibilita su fácil entendimiento y uso.. Así como la creación de lenguajes y el modelado se hacen sin dificultad con estaherramienta, no ocurre lo mismo a la hora de generar código. La definición de una trans-formación utilizando el lenguaje MERL resulta más complicada que cuando se utilizanotros lenguajes de transformación que ofrecen más posiblidades a la hora de navegar entrelos elementos de los modelos. La sintaxis tampoco es tan clara como en otros lenguajes, yel estilo de programación difiere bastante, al definir toda la transformación dentro de unaiteración donde la navegación entre los elementos del modelo puede resultar complicadoen muchos casos. Otro aspecto negativo de la herramienta es el uso de formatos propios para exportarmodelos y metamodelos, haciendo incompatible su uso en otras herramientas, a no serque estos permitan la importación de modelos de MetaEdit+. La interoperabilidad conotras herramientas sería más fácil si se utilizara el formato XMI. De este modo seríaposible importar modelos de MetaEdit+ en otras herramientas y utilizar otros lenguajespara definir las transformaciones. Finalmente, como ya se ha comentado, con está herramienta se puede transformar demodelo a texto, pero no así de modelo a modelo. El punto fuerte de esta herramienta 42
  56. 56. 5.2. HERRAMIENTASreside más en la creación de metamodelos y modelos que en la definición de las transfor-maciones.5.2.2. Eclipse Modeling FrameworkDescripción Eclipse Modeling Framework (EMF) es el framework que ofrece Eclipse para MDD.En el capítulo anterior se ha visto como utilizar el lenguaje de metamodelado Ecore queofrece EMF para definir lenguajes de modelado específicos de dominio. Eclipse es unentorno de desarrollo extensible al que se le pueden añadir gran variedad de plugins1 ,que fue desarrolado inicialmente por IBM y en la actualidad se distribuye como softwarelibre.Características generales En el anterior capítulo se ha descrito cómo utilizar esta herramienta para diseñar len-guajes específicos de modelado y crear un editor para definir modelos. Como se ha comentado, esta herramienta es extensible, lo que significa que se le pue-den añadir nuevas funcionalidades para trabajar en el mismo entorno. Es posible exten-derlo para trabajar con modelos de UML, para los que ofrece un editor, y que se puedenutilizar en distintas transformaciones. Aunque EMF trae algunas herramientas para definirlas transformaciones de modelos, en nuestro caso se le han añadido ATL para transfor-maciones entre modelos y MOFScript para transformaciones de modelo a texto. Esasherramientas serán analizadas posteriormente de forma individual.Ventajas y limitaciones Entre los aspectos positivos de esta herramienta hay que resaltar su extensibilidad.Existe una gran variedad de plugins que pueden ser añadidos para extender la funcio-nalidad de la herramienta. Esto posibilita hacerlo “todo” en el mismo entorno, desde ladefinición del metamodelo hasta la generación de código, o incluso la edición y compila-ción del código generado. La documentación de la herramienta es bastante completa, aunque dependa mucho decada plugin, ya que estos tienen documentación propia. Además la ayuda ofrecida por lacomunidad resulta muy útil. Durante el transcurso del proyecto se han utilizado los grupos 1 http://www.eclipseplugincentral.com/ 43

×