Proteo : lenguaje para la especificación de lenguajes específicos de dominio

UNIVERSIDAD DE LAS PALMAS DE GRAN CANARIA M´aster Oficial en Sistemas Inteligentes y Aplicaciones Num´ericas en Ingenier´ıa Trabajo Final de Master Proteo, lenguaje para la especificaci´on de lenguajes espec´ıficos de dominio Bycor S´anchez S´anchez Tutores: Jos´e Juan Hern´andez Cabrera Jos´e ´ Evora G´omez 31 de diciembre de 2014 Agradecimientos A mis padres y hermanos, quienes en todo momento me han brindado su apoyo incondicional, a mis tutores Jos´e Juan Hern´andez y Jos´e ´ Evora, por la gran ayuda prestada, y finalmente a mi novia, por alentarme en todo momento a seguir adelante. A todo ellos, muchas gracias. i ii Resumen En el sector del desarrollo software surge la necesidad de mejorar la productividad y garantizar la evoluci´on flexible del software, de tal forma que el producto satisfaga las necesidades del cliente con el menor coste posible. Model Driven Engineering (MDE) es una metodolog´ıa que surge con estos objetivos. Para lograrlo, MDE se apoya en el uso de Lenguajes Espec´ıficos de Dominio (Domain Specific Language, DSL) para expresar l´ogicas de negocio con un lenguaje cercano al ´ambito de aplicaci´on. El desarrollo de sistemas complejos ha potenciado el uso de MDE en contextos muy diversos. Por tanto, es necesaria la creaci´on de lenguajes espec´ıficos para cada contexto. En este trabajo se plantea la hip´otesis de la existencia de una gram´atica capaz de representar m´ultiples DSLs. Esta gram´atica constituye la base de un superlenguaje al que llamamos Proteo. En el contexto de este trabajo, un super-lenguaje es un lenguaje abstracto que puede ser extendido para definir DSLs. Como trabajo instrumental se ha implementado la gram´atica, abordando la fase de an´alisis del compilador. ´ Esta comprende la concepci´on de un analizador l´exico abstracto y los analizadores sint´actico y sem´antico del super-lenguaje. Las herramientas desarrolladas permitir´an abordar una futura fase de experimentaci´on donde evaluar la hip´otesis planteada. iii iv Resumen ´ Indice general 1. Motivaci´on y contextualizaci´on 1 2. Estado del arte 5 2.1. Modelos y metamodelos . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Arquitectura de niveles . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Model Driven Engineering . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. Dominios donde se aplica . . . . . . . . . . . . . . . . . . . . 9 2.3.2. Investigaci´on ........................... 10 2.4. L´ınea de investigaci´on de GMDE SIANI . . . . . . . . . . . . . . . . 11 2.5. Domain Specific Languages . . . . . . . . . . . . . . . . . . . . . . . 15 3. Hip´otesis 17 4. Marco Tecnol´ogico 21 4.1. Compilador ................................ 21 4.2. Gram´atica................................. 23 4.3. Analizadores sint´acticos . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.4. Abstract Syntax Tree . . . . . . . . . . . . . . . . . . . . . . . . . . 26 5. Definici´on del super-lenguaje 29 5.1. Relaciones................................. 31 5.2. Caracter´ısticas .............................. 33 v vi ´ INDICE GENERAL 5.2.1. Direcciones ............................ 33 5.2.2. Variables ............................. 34 5.2.3. Facetas .............................. 35 5.2.4. Anotaciones............................ 35 6. Trabajo instrumental 37 6.1. Herramientas desarrolladas . . . . . . . . . . . . . . . . . . . . . . . 37 6.1.1. An´alisis l´exico . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.1.2. An´alisis sint´actico . . . . . . . . . . . . . . . . . . . . . . . . 42 6.1.3. An´alisis sem´antico . . . . . . . . . . . . . . . . . . . . . . . . 48 6.2. Recursos.................................. 50 6.3. Metodolog´ıas de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . 53 6.3.1. Iterativo incremental . . . . . . . . . . . . . . . . . . . . . . . 53 6.3.2. Specification-by-example . . . . . . . . . . . . . . . . . . . . . 54 7. Resultado 55 8. Conclusiones 57 ´ Indice de figuras 2.1. Ilustraci´on de Meta-Object Facility. . . . . . . . . . . . . . . . . . . . 7 2.2. Ejemplo UML de la arquitectura de niveles. . . . . . . . . . . . . . . 8 2.3. Mapa de instituciones que investigan MDE. . . . . . . . . . . . . . . 12 2.4. Paradigma cl´asico en MDE. . . . . . . . . . . . . . . . . . . . . . . . 13 2.5. Visi´ondelGMDE. ............................ 15 4.1. Etapas del proceso de compilaci´on. . . . . . . . . . . . . . . . . . . . 22 4.2. Contenci´on de tipos de gram´aticas. . . . . . . . . . . . . . . . . . . . 24 4.3. Ejemplo ´arbol, asignaci´on de variables. . . . . . . . . . . . . . . . . . 25 4.4. Recorrido descendente. . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.5. Recorrido ascendente. . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.6. Ejemplo Parse Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.7. EjemploAST................................ 26 5.1. Niveles del lenguaje. . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.2. Estructura de Proteo. . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3. Relacion de composici´on. . . . . . . . . . . . . . . . . . . . . . . . . 32 5.4. Relaci´on de agregaci´on. . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.5. Generalizaci´on entre elementos. . . . . . . . . . . . . . . . . . . . . . 32 5.6. Descripci´on de una concreci´on entre modelos. . . . . . . . . . . . . . 33 5.7. Descripci´on de una abstracci´on entre modelos. . . . . . . . . . . . . 34 vii 4CAP´ ITULO 1. MOTIVACI ´ ON Y CONTEXTUALIZACI ´ ON Cap´ıtulo 2 Estado del arte La forma habitual de gestionar la complejidad del desarrollo de software es mediante el uso de la abstracci´on, la descomposici´on del problema y la separaci´on de asuntos (separation of concerns)[46]. El desarrollo de software dirigido por modelos (MDE)[43] es una aproximaci´on que enfoca la gesti´on de la complejidad mediante el uso de otro tipo de lenguajes. En lugar de usar lenguajes pr´oximos a la tecnolog´ıa (3GL)[41], la idea es usar lenguajes m´as expresivos y cercanos al dominio del problema, Lenguajes Espec´ıficos de Dominio (DSL). Con estos lenguajes se pueden realizar descripciones precisas y detalladas del mundo real con el que el software tiene que tratar. Estas descripciones son modelos que representan alg´un aspecto del mundo. Por ello, tambi´en se les llama lenguajes de modelado. En este apartado se describen los conceptos m´as relevantes, as´ı como el estado actual de los mismos. 5 6CAP´ ITULO 2. ESTADO DEL ARTE 2.1. Modelos y metamodelos De manera general un modelo se describe como una abstracci´on de la realidad que la representa de una manera simplificada[26]. Los modelos permiten representar una parte de la realidad vista por las personas que lo utilizan para entender, cambiar, manejar y controlar esa parte de la realidad[38]. En el contexto de la ingenier´ıa de software, el modelo de dominio es un modelo conceptual que representa los elementos que existen en el contexto de un problema espec´ıfico. Este modelo describe las diferentes entidades, sus atributos, roles y relaciones entre ellas, as´ı como las limitaciones que gobiernan el dominio del problema. Un metamodelo se describe como un modelo que define otro modelo. Los metamodelos representan y especifican modelos, es decir, describen los elementos v´alidos de un modelo. De manera m´as precisa, un metamodelo enuncia qu´e puede ser expresado en los modelos v´alidos de un cierto lenguaje de modelado[44]. Por tanto, un metamodelo constituye la especificaci´on de un lenguaje de modelado[44]. Un lenguaje, descrito por un metamodelo, puede tener un prop´osito espec´ıfico o dominio en donde se aplica. De este modo, es posible capturar la sem´antica de todos los modelos disponibles para un determinado ´ambito de conocimiento a trav´es de un lenguaje[16]. 2.2. Arquitectura de niveles El concepto de metamodelo se basa en la arquitectura de metadatos adoptada por el consorcio OMG en la especificaci´on del Meta-Object Facility (MOF)[34]. MOF est´a dise˜nado como una arquitectura de cuatro niveles o capas: informaci´on o sistema, modelos, metamodelos y meta-metamodelos. La figura 2.1 representa esta arquitectura. 2.3. MODEL DRIVEN ENGINEERING 7 Figura 2.1: Ilustraci´on de Meta-Object Facility. El nivel M3 constituye el meta-metamodelo. Este nivel es utilizado para construir los metamodelos, nivel M2. Un ejemplo es el metamodelo UML[35] (Unified Modeling Language), que define al propio UML. Los elementos de M2 describen los modelos descritos del nivel M1. Ejemplos de modelos son, por ejemplo, dise˜nos espec´ıficos escritos en UML. El ´ultimo nivel es M0, donde est´an los objetos del mundo real. La figura 2.2 ilustra esta arquitectura de niveles para el dominio concreto sistemas de informaci´on. En el nivel de metamodelo (M2) se definen agentes y entidades. Asimismo, los elementos de M1 permitir´ıan, por ejemplo, realizar un censo de qui´en vive en qu´e edificio. La especificaci´on MOF es an´aloga en el caso de los lenguajes. De este modo habr´ıa un lenguaje primigenio y lenguajes derivados de ´el en niveles inferiores. 2.3. Model Driven Engineering El dise˜no de sistemas software en ciertos ´ambitos de conocimiento puede resultar una tarea ardua, especialmente cuando el dominio del problema tiene una especial complejidad y est´a en continua evoluci´on. 8CAP´ ITULO 2. ESTADO DEL ARTE Figura 2.2: Ejemplo UML de la arquitectura de niveles. En este sentido el Model Driven Engineering[43] (MDE) ofrece mecanismos para afrontar estos problemas. MDE es una metodolog´ıa para el desarrollo de software basada en modelos. Es decir, la funcionalidad del software es descrita en modelos y el c´odigo es generado en base a dichos modelos. MDE utiliza diversos niveles de abstracci´on entre el dise˜no del software y su implementaci´on. Estos niveles permiten dise˜nar el software en un lenguaje de alto nivel donde se describen los elementos con una sem´antica cercana al dominio del problema. En este sentido, no solo los desarrolladores, sino tambi´en los expertos en el dominio pueden tener un papel importante en el desarrollo del software. Asimismo, la combinaci´on de diversas tecnolog´ıas MDE permiten solventar el problema de la complejidad en los sistemas[43]. Principalmente, MDE se basa en los siguientes conceptos: Domain-specific modelling language (DSML). Lenguajes que permiten formalizar la estructura, comportamiento y requisitos del software en un dominio particular[27]. Los DSMLs son descritos utilizando metamodelos que definen los conceptos y las relaciones entre ellos para un dominio concreto. 2.3. MODEL DRIVEN ENGINEERING 9 La idea principal es describir los elementos de manera declarativa, en lugar de imperativa. Generadores o motores (engines) que analizan los modelos escritos en un determinado DSML para generar el c´odigo fuente o representaciones alternativas del modelo. Los DSMLs son utilizados en la actualidad para dotar de mayor expresividad sint´actica y sem´antica del dominio al software. De este modo, se reduce la curva de aprendizaje y facilita a los expertos a asegurarse que el sistema cumple los requisitos[44]. Adem´as, las herramientas de MDE imponen restricciones al dominio que permiten detectar y prevenir errores en las etapas iniciales de desarrollo. 2.3.1. Dominios donde se aplica Existen ´ambitos de conocimiento muy diversos en los que se utiliza MDE. Un ejemplo es el campo de la simulaci´on. El framework Tafat[15] usa MDE para la creaci´on de simuladores de sistemas complejos. Su objetivo es acelerar el proceso de construcci´on de simuladores. Concretamente, el uso de esta metodolog´ıa ha sido explotada en Tafat para la construcci´on de simulaciones de “Smart Grids” [14], facilitando as´ı la toma de decisiones en la implantaci´on de estrategias para la eficiencia energ´etica de las redes el´ectricas. Otro ejemplo es la aplicaci´on de MDE en eBusinesses. En la investigaci´on [24] se orienta la ayuda de peque˜nas organizaciones que disponen de medios limitados para definir su proyecci´on organizativa y tecnol´ogica. La investigaci´on concluye que esta aproximaci´on ayuda a este tipo de organizaciones y a administraciones p´ublicas a modelar sus estructuras de servicio. El MDE tambi´en se ha adentrado en el campo de la bioinform´atica. En [32] eval´uan su uso para resolver problemas surgidos en el estudio de los caminos de se˜nales (reacciones en una c´elula como reacci´on a un est´ımulo). Los autores afirman 10 CAP´ ITULO 2. ESTADO DEL ARTE que MDE aporta una mayor eficiencia en el desarrollo, mayor claridad de los datos y un manejo muy intuitivo de los mismos. En el ´ambito industrial hay empresas que aplican t´ecnicas de MDE. Es el caso de Motorola[17] que lleva cerca de veinte a˜nos utiliz´andolas. A lo largo de estos a˜nos han visto como la introducci´on de t´ecnicas de coordinaci´on y control han supuesto un gran aumento en t´erminos de calidad y productividad. Una investigaci´on realizada en [49] eval´ua la posibilidad de utilizar MDE para el desarrollo de aplicaciones en redes de sensores. Los autores buscan un enfoque completamente diferente al resto de propuestas de su mismo ´ambito. Como resultado obtienen una aplicaci´on que reduce sensiblemente el esfuerzo y tiempo de producci´on. En el campo de desarrollo de aplicaciones m´oviles tambi´en se plantea el uso de MDE. En concreto para predecir el rendimiento de un determinado dise˜no[47], donde esta metodolog´ıa posibilite a los desarrolladores entender r´apidamente las consecuencias de decisiones arquitect´onicas. Otro estudio introduce el uso de MDE en el dise˜no de sistemas multi-agentes[21]. A partir de los resultados extra´ıdos de un caso de uso concluyen que MDE aporta principalmente flexibilidad. 2.3.2. Investigaci´on MDE constituye un campo de investigaci´on en auge para investigadores de todo el mundo. Resulta interesante conocer qu´e otras entidades u organizaciones trabajan con MDE, as´ı como el ´ambito de sus investigaciones. A continuaci´on se detallan algunas de las instituciones cuyos investigadores publican un mayor n´umero de trabajos sobre MDE. A. Institut National de Recherche en Informatique et en Automatisme (INRIA). Algunas de sus investigaciones comprenden el dise˜no de lenguajes de 2.4. L´ INEA DE INVESTIGACI ´ ON DE GMDE SIANI 11 modelado[25] o la creaci´on de frameworks basados en MDE para ´ambitos espec´ıficos como, por ejemplo, la paralelizaci´on de sistemas empotrados[18]. B. Universite Lille nord de France. Investigadores de esta universidad buscan la manera de garantizar la interoperabilidad entre modelos de diferentes plataformas[48]. C. Universidad de Murcia. Estudian aspectos como la creaci´on de lenguajes espec´ıficos de dominio basados en los principios de MDE[10] o la posible aplicaci´on de MDE en peque˜nas empresas de desarrollo software[9]. D. Universite de Toulouse. Trabajan con MDE para crear modelos de sistemas multi-agentes adaptativos[42], optimizar de sistemas de tiempo real[22] o para el desarrollo de sistemas empotrados distribuidos[29]. E. Universidad de Oviedo. Una de sus l´ıneas de investigaci´on trata la construcci´on de un framework para el desarrollo de todo tipo de aplicaciones[20][19]. Para ello mezclan diversos enfoques del MDE. La figura 2.3 recoge la localizaci´on de estas instituciones. Se ha incluido el Instituto Universitario SIANI[11] (punto F), en el cual desarrollamos diversas l´ıneas de investigaci´on entorno al MDE. Toda esta informaci´on se ha obtenido de las bases de datos de investigaci´on Web Of Science[40] y Scopus[13], buscando por los t´erminos “Model-Driven Engineering” y ”MDE” publicaciones recientes (´ultimos 5 a˜nos). 2.4. L´ınea de investigaci´on de GMDE SIANI En general, cualquier aplicaci´on opera con alg´un modelo de la realidad (M0). Normalmente, este modelo es persistente en alg´un tipo de base de datos u otro medio de almacenamiento. As´ı, todo software se dise˜na para interpretar un tipo 12 CAP´ ITULO 2. ESTADO DEL ARTE Figura 2.3: Mapa de instituciones que investigan MDE. modelo, por tanto podemos decir que el software incorpora un metamodelo (M1). Es decir, un modelo del modelo (figura 2.4). En el MDE cl´asico, un metamodelo expresado en un lenguaje espec´ıfico de dominio (DSL) se transforma en un software. Conceptualmente es correcto, dado que una aplicaci´on puede concebirse como un metamodelo capaz de interpretar un modelo. Para poder llevar a cabo este enfoque, deben existir herramientas que soporten la transformaci´on autom´atica de los metamodelos. Incluso, estas herramientas deben, no s´olo ofrecer la posibilidad de aplicar transformaciones predefinidas, sino ofrecer tambi´en un lenguaje que permita a los desarrolladores 2.4. L´ INEA DE INVESTIGACI ´ ON DE GMDE SIANI 13 M0 Metamodelo Modelo Proceso de la aplicación M1 Aplicación Persistencia Esquema de Persistencia transformaciones Figura 2.4: Paradigma cl´asico en MDE. definir sus propias transformaciones y ejecutarlas bajo demanda. Existen diversas aproximaciones a la transformaci´on de modelos: Direct Model Manipulation (Pull transformation). Herramientas que ofrecen al usuario acceso a la representaci´on del modelo y la capacidad para transformarlos mediante APIs. Intermediate Representation. El modelo se exporta a una representaci´on est´andar (XML) que puede ser usada por otra herramienta para transformarlo. Transformation Language Support. Se ofrece un lenguaje que permite expresar y componer transformaciones. Podemos afirmar que para realizar estas transformaciones es necesario que estos procesos interpreten a su vez de alguna forma el metamodelo. En cierto modo, el conocimiento para interpretar el metamodelo y transformarlo en software est´a incorporado en estos procesos de transformaci´on. No obstante, cabe la posibilidad de plantear otra alternativa que permita usar estos metamodelos para producir software que no se base estrictamente en la transformaci´on. Concretamente, la visi´on de la l´ınea de investigaci´on en la que 20 CAP´ ITULO 3. HIP ´ OTESIS Cap´ıtulo 4 Marco Tecnol´ogico Este apartado introduce los conceptos de compilador, gram´atica, analizador sint´actico y ´arbol de sintaxis abstracta. El concepto de compilador define la fase de an´alisis que seguir´a el trabajo. La gram´atica es un elemento clave, pues definir´a la sintaxis del super-lenguaje. Se identifica tambi´en los analizadores sint´acticos, que utilizan las gram´aticas para evaluar la validez de los datos. Finalmente, se describen los ´ Arboles de Sintaxis Abstracta (Abstract Syntax Tree), estructuras para una mejor representaci´on de los datos. 4.1. Compilador Un compilador es un programa inform´atico que traduce un programa escrito en un lenguaje de programaci´on a otro lenguaje de programaci´on, generando c´odigo interpretable por la m´aquina[2]. Debido a su capacidad de transformar el lenguaje a c´odigo ejecutable, los compiladores permiten a los programadores el uso de lenguajes de alto nivel. Este tipo de lenguajes se asemejan m´as al lenguaje humano, lo que dota de mayor sem´antica al programa escrito. Las etapas involucradas en el proceso de traducci´on son: 21 22 CAP´ ITULO 4. MARCO TECNOL ´ OGICO 1. An´alisis. Esta etapa comprueba la validez del programa fuente. Su funcionamiento se divide en tres sub-etapas: L´exico. El programa original se descompone en s´ımbolos o “tokens”, peque˜nos fragmentos indivisibles que conforman el lenguaje. Sint´actico. Se agrupan los “tokens” en frases gramaticales, de tal forma que se cumplan las reglas definidas por el lenguaje (gram´atica). Sem´antico. Se comprueba la validez sem´antica del c´odigo fuente. 2. S´ıntesis . Esta etapa genera la salida expresada en el lenguaje objeto (lenguaje de salida del compilador). Se compone de: Optimizaci´on de c´odigo. Trata de mejorar la eficiencia del c´odigo. Generaci´on de c´odigo. Genera el c´odigo m´aquina o c´odigo intermedio. La figura 4.1 ilustra las diferentes etapas. Análisis léxico Análisis sintáctico Análisis semántico Optimización Generación de código objeto Programa objeto Programa fuente Análisis Síntesis Figura 4.1: Etapas del proceso de compilaci´on. 4.2. GRAM ´ ATICA 23 4.2. Gram´atica La gram´atica comprende el estudio de las reglas y principios que gobiernan el uso de las lenguas y la organizaci´on de las palabras dentro de las oraciones. De manera formal una gram´atica se define como una cu´adrupla[5]: G = (VT, VN, S, P). donde: VT= conjunto finito de s´ımbolos terminales. VN=conjunto finito de s´ımbolos no terminales. S es el s´ımbolo inicial y pertenece a VN. P= conjunto de producciones o de reglas de derivaci´on. En el ´ambito de las ciencias de la computaci´on, cada lenguaje de programaci´on se define a trav´es de una gram´atica formal[39]. Una gram´atica formal es una estructura compuesta por un conjunto de reglas de formaci´on que definen las cadenas de caracteres admisibles en un determinado lenguaje. Cabe destacar que estas gram´aticas no atienden al significado de las f´ormulas bien formadas, sino a la forma en que dichas f´ormulas se combinan. La jerarqu´ıa de Chomsky[5] es una clasificaci´on jer´arquica de distintos tipos de gram´aticas formales que generan lenguajes formales. La tabla 4.1 recoge esta jerarqu´ıa. Tipo Tipo de gram´atica Complejidad 0 Gram´aticas no restringidas Indeterminada 1 Gram´aticas dependientes del contexto Exponencial 2 Gram´aticas libres del contexto Polin´omica 3 Gram´aticas regulares Lineal Cuadro 4.1: Jerarqu´ıa de Chomsky. La jerarqu´ıa comienza con un tipo de gram´aticas que pretende ser universal (tipo 0). Aplicando restricciones a sus reglas se van obteniendo los otros tres tipos. 24 CAP´ ITULO 4. MARCO TECNOL ´ OGICO En la clasificaci´on de la tabla 4.1 cada tipo de gram´atica contiene a todos los tipos siguientes (figura 4.2). Las gram´aticas tipo 2 y 3 son utilizadas m´as frecuentemente, puesto que su menor complejidad permite el desarrollo de analizadores sint´acticos m´as eficientes. Tipo 0 Tipo 1 Tipo 2 Tipo 3 Figura 4.2: Contenci´on de tipos de gram´aticas. 4.3. Analizadores sint´acticos El analizador sint´actico o reconocedor (parser) pertenece a la fase an´alisis sint´actico del compilador. Su objetivo es comprobar si la sucesi´on de s´ımbolos de entrada pertenecen a un determinado lenguaje[2]. Para ello, parte de la definici´on sint´actica del lenguaje (gram´atica). Asimismo, el analizador sint´actico trata de obtener la relaci´on entre los elementos del lenguaje en una estructura en forma de ´arbol. Dos de los m´etodos de an´alisis, en funci´on de la estructura, son: Descendente. Estrategia de reconocimiento que parte del nivel m´as alto del ´arbol de representaci´on. A partir de ah´ı, desciende recursivamente por las reglas de derivaci´on de la gram´atica hasta obtener los s´ımbolos terminales. Los analizadores sint´acticos LL utilizan esta estrategia, partiendo de izquierda a derecha. El n´umero de s´ımbolos utilizados para predecir a qu´e rama acceder 4.3. ANALIZADORES SINT ´ ACTICOS 25 puede ser variable. Este hecho se indica como LL(K), siendo K el n´umero de s´ımbolos. Se da tambi´en el caso de LL(*), las cuales buscan el mayor n´umero de s´ımbolos posible para desambiguar. Ascendente. Estrategia de reconocimiento que parte de los nodos hoja del ´arbol. A partir de ellos trata de escalar por los s´ımbolos terminales hasta llegar a su ra´ız. Los analizadores sint´acticos LR utilizan esta estrategia, recorren el ´arbol de representaci´on de las hojas hacia la ra´ız. Existen tres tipos de parsers LR: SLR (K), LALR (K) y LR (K) can´onico. El ´arbol de la figura 4.3 representa la asignaci´on del valor de una suma a una variable. Para este ejemplo, la figura 4.4 enumera el recorrido que realiza un analizador descendente. A partir de la ra´ız del ´arbol accede a los nodos hoja. Por su parte, el recorrido seguido por un analizador ascendente (figura 4.5) parte de los nodos hoja y va escalando por el ´arbol. B C var2var3 A = product1product2 var1equals sums assign Figura 4.3: Ejemplo ´arbol, asignaci´on de variables. 26 CAP´ ITULO 4. MARCO TECNOL ´ OGICO 9 12 8 11 3 5 7 10 2 4 6 1 Figura 4.4: Recorrido descendente. 5 8 6 9 1 3 7 10 2 4 11 13 Figura 4.5: Recorrido ascendente. 4.4. Abstract Syntax Tree Un Abstract Syntax Tree (´ Arbol de Sintaxis Abstracta) es una estructura en forma de ´arbol que representan el c´odigo fuente de forma simplificada, es decir, omite aquellos detalles poco importantes o irrelevantes. Este tipo de ´arboles no debe ser confundido con los Parse Tree (´arboles de derivaci´on o ´arboles de sintaxis concreta). En contraste con los AST, los ´arboles de derivaci´on representan el c´odigo fuente seg´un la estructura sint´actica definida por la gram´atica, sin omitir ning´un tipo de detalle. Las figuras 4.6 y 4.7 ilustran la sutil diferencia entre estas dos estructuras. En ambos casos se ha representado la asignaci´on de una suma de variables a otra variable. C + D X = var2plus var3 var1equals sum statement Figura 4.6: Ejemplo Parse Tree. equals Xsums C D Figura 4.7: Ejemplo AST. 4.4. ABSTRACT SYNTAX TREE 27 En la figura 4.6 se puede ver un ´arbol de derivaci´on con todas las reglas que conforman la gram´atica. Por su parte, el AST de la figura 4.7 representa la misma informaci´on omitiendo parte de la informaci´on que no es relevante. Los AST son ampliamente utilizados en los compiladores, pues permiten representar eficientemente la informaci´on del c´odigo fuente. En concreto son especialmente ´utiles en la fase de an´alisis sem´antico. 28 CAP´ ITULO 4. MARCO TECNOL ´ OGICO Cap´ıtulo 5 Definici´on del super-lenguaje En el presente trabajo se introduce el concepto de super-lenguaje. En este contexto, un super-lenguaje se define como un lenguaje abstracto que puede ser extendido para definir diferentes Lenguajes Espec´ıficos de Dominio (DSL). El super-lenguaje es an´alogo a una superclase en un lenguaje de programaci´on orientado a objetos, ya que permite la creaci´on de un lenguaje derivado heredando todas las propiedades y estructura del mismo. De manera general, el estudio de un lenguaje se divide en una estructura de niveles. En el ´ambito de la inform´atica, crear un lenguaje de programaci´on requiere centrarse fundamentalmente en tres de estos niveles: morfolog´ıa, sintaxis y sem´antica. La morfolog´ıa se denota como la identificaci´on, an´alisis y descripci´on de la estructura de los morfemas, unidades m´as peque˜nas de un lenguaje (palabras). Dentro del estudio de las palabras se encuentra tambi´en la lexicolog´ıa, que estudia el conjunto de palabras que conforman un lenguaje. Por su parte, la sintaxis comprende el estudio de los principios y procesos a trav´es de los cuales se construyen las estructuras de un lenguaje[6] (frases). Finalmente, el sem´antico estudia el significado, centrando su atenci´on en la relaci´on 29 36 CAP´ ITULO 5. DEFINICI ´ ON DEL SUPER-LENGUAJE Component. Restringe la instancia del elemento a ser componente de otro elemento. Es decir, el elemento no podr´a ser ra´ız del modelo. Aggregated. Permite especificar la relaci´on de agregaci´on entre dos elementos del modelo. Por defecto es de composici´on. Property. Tiene la propiedad de component y single. Adem´as, un elemento property no puede ser aggregated. Addressed. Obliga a que la instancia tenga una direcci´on en formato IPv4. Intention. Una intenci´on es una declaraci´on de una funcionalidad que puede tener un instanciable. No tienen contenido, pero permiten especializaci´on. Facet. Anota un elemento como faceta. Todas las anotaciones se heredan, excepto abstracto. Por su parte, las variables tambi´en pueden tener ciertas anotaciones. Estas son: Terminal. Permite no dar valor a la variable hasta el nivel terminal (M0). Local. Esta anotaci´on es solo aplicable a las variables de tipo referencia. Limita el espectro de la referencia a componentes del elemento ra´ız en el que se encuentra el que se est´a instanciando. Cap´ıtulo 6 Trabajo instrumental 6.1. Herramientas desarrolladas En este trabajo se plantea la hip´otesis de la posible existencia de una gram´atica capaz de representar m´ultiples lenguajes para el modelado en diferentes ´ambitos de conocimiento. Por tanto, este apartado se centra en la b´usqueda y desarrollo de una gram´atica gen´erica que defina el conjunto de reglas admisible en el lenguaje. Esta gram´atica constituye la base del super-lenguaje Proteo. En el contexto de este trabajo, un super-lenguaje es un lenguaje abstracto que puede ser extendido para definir otros lenguajes, heredando todas las propiedades y estructura. Proteo tiene como prop´osito ser un super-lenguaje para la especializaci´on de Lenguajes Espec´ıficos de Dominio (DSLs), los cuales ser´an utilizados bajo la metodolog´ıa Model Driven Engineering[43]. Proteo define una estructura con un l´exico abstracto, sobre la cual se sustenta una sintaxis y sem´antica com´un para todos los lenguajes derivados (figura 6.1). El l´exico comprende un cat´alogo de las palabras del lenguaje. Proteo define ciertas palabras reservadas, sin embargo, cada DSL especificado deber´a incluir los elementos instanciables que pueden ser definidos en ´el. 37 38 CAP´ ITULO 6. TRABAJO INSTRUMENTAL LÉXICO SINTAXIS SEMÁNTICA Figura 6.1: Estructura de Proteo. Por su parte, la sintaxis y la sem´antica ser´a la misma para los DSLs derivados. La sintaxis comprende la forma que adopta estructuralmente el lenguaje, mientras que la sem´antica comprueba el correcto significado de los diversos elementos que lo componen. Bajo este enfoque, la creaci´on de nuevos lenguajes espec´ıficos se reduce a completar el l´exico abstracto de Proteo con los elementos instanciables en cada ´ambito de conocimiento. Estos instanciables son definidos en los metamodelos inherentes a cada lenguaje, nivel M2 de la arquitectura de niveles (apartado 2.2). Por ejemplo, en el contexto de sistemas de informaci´on los elementos instanciables podr´ıan ser formularios, colecciones, campos o cat´alogos. El super-lenguaje requiere de analizadores que validen la composici´on estructural, as´ı como la coherencia sem´antica de los lenguajes derivados. Los siguientes apartados abordan estos aspectos siguiendo la fase de an´alisis, propia de la construcci´on de un compilador. Esta fase comprende an´alisis l´exico, sint´actico y sem´antico para Proteo. 6.1.1. An´alisis l´exico El an´alisis l´exico constituye la primera fase de un compilador. Su principal funci´on consiste en leer el modelo escrito por el usuario y, en base a ´el, elaborar como salida una secuencia de “tokens” o s´ımbolos. Estos tokens indican el conjunto de posibles secuencias de caracteres aceptadas por el lenguaje. 6.1. HERRAMIENTAS DESARROLLADAS 39 La construcci´on de un analizador l´exico para Proteo requiere la especificaci´on l´exica del super-lenguaje. A lo largo de este apartado se muestran las diferentes partes que conforman el l´exico abstracto desarrollado. El c´odigo 6.1 contiene la declaraci´on de algunas de las palabras clave que conforman el l´exico de Proteo. Su formaci´on es sencilla pues el token, a la izquierda, se corresponde directamente con una cadena de texto, a la derecha. C´odigo 6.1: Palabras clave. SUB : ’sub’ ; VAR : ’var’ ; EXTENDS : ’extends’; ABSTRACT : ’abstract ’ ; SINGLE : ’single ’ ; REQUIRED : ’ required ’ ; COMPONENT : ’component ’ ; AGGREGATED : ’aggregated ’ ; INT TYPE : ’integer’; DOUBLE TYPE : ’double ’ ; STRING TYPE : ’string ’ ; . . . Entre la multitud de palabras reservadas se encuentran las anotaciones (single, required, aggregated, etc), los tipos de variables (enteros, reales, cadenas de texto, etc), declaraci´on de herencia entre elementos (sub, extends), entre muchos otros. Cada lenguaje que se especializa a trav´es de Proteo dispone de sus propios elementos instanciables, propios para su ´ambito de aplicaci´on. El l´exico dispone de un token gen´erico que los identifica. Este token toma el nombre de METAIDENTIFIER. El c´odigo 6.2 contiene un ejemplo cumplimentado de este token para un DSL en el contexto de los sistemas de informaci´on. N´otese que la barra representa un operador booleano OR. 40 CAP´ ITULO 6. TRABAJO INSTRUMENTAL C´odigo 6.2: Elementos instanciables. METAIDENTIFIER : ’Collection ’ |’Form ’ |’Catalog’; Tambi´en existen una serie de s´ımbolos en el super-lenguaje, como los definidos en el c´odigo 6.3. ´ Estos son utilizados con m´ultiples fines en Proteo. Un ejemplo es el s´ımbolo igual (‘=’) para la asignaci´on de valores a variables. El tratamiento l´exico de estas reglas es id´entico al de las palabras clave. C´odigo 6.3: S´ımbolos. LEFT PARENTHESIS : ’(’ ; RIGHT PARENTHESIS : ’)’ ; LEFT SQUARE : ’[’ ; RIGHT SQUARE : ’]’ ; EQUALS : ’=’ ; . . . El l´exico tambi´en identifica los posibles valores a los que puede ser inicializada una variable en el lenguaje. En el c´odigo 6.4 quedan reflejados algunos de ellos. Por ejemplo, un booleano puede ser verdadero o falso, un n´umero negativo dispone del s´ımbolo ‘-’ seguido de un uno o m´ultiples d´ıgitos o que una cadena de texto es todo aquello entrecomillado. N´otese la notaci´on utilizada, donde el signo de interrogaci´on (‘?’) corresponde a 0 o 1 elementos de ese token, el s´ımbolo de suma (‘+’) es de 1 a n elementos y el asterisco (‘*’) de 0 a n elementos. C´odigo 6.4: Valores. BOOLEAN VALUE : ’true’ |’false ’ ; NATURAL VALUE : PLUS? DIGIT+; NEGATIVE VALUE : DASH DIGIT+ ; DOUBLE VALUE : (PLUS |DASH) ? DIGIT+ DOT DIGIT+; STRING VALUE : APHOSTROPHE (˜ ’\‘ ’ )∗APHOSTROPHE; . . . 6.1. HERRAMIENTAS DESARROLLADAS 41 Otro elemento muy importante en los lenguajes es el identificador (c´odigo 6.5). Este token representa el nombre que toma un elemento o una variable en el DSL. Se compone de una serie de letras, n´umeros y/o barras, con la restricci´on de que debe comenzar por una letra. C´odigo 6.5: Identificador. IDENTIFIER : LETTER (DIGIT |LETTER |DASH |UNDERDASH) ∗; En Proteo se identifican los bloques de c´odigo. En lenguajes como C++ ´estos se definen con llaves (‘{’ y ‘}’). Sin embargo, para mejorar la expresividad, se ha decidido utilizar una estructura similar al lenguaje Python, donde los bloques son definidos por tabulaciones. Los tokens NEW LINE INDENT y DEDENT del l´exico (c´odigo 6.6) identifican estos bloques. Ninguno de ellos dispone de reglas, sino que son emitidos cuando el nivel de indentaci´on aumenta o disminuye. Estos niveles de indentaci´on son controlados por una clase propia, encargada de evaluar cu´ando se cumplen los requisitos y emitir el token NEW LINE INDENT cuando comienza un bloque o DEDENT cuando finaliza. C´odigo 6.6: Indentaciones. NEWLINE: NL+ SP∗{newlinesAndSpaces() ; }; SP: ( ’ ’ |’\t’ ) ; NL: ( ’\r’?’\n’ |’\r’ ) ; NEW LINE INDENT: ’indent ’ ; DEDENT : ’dedent ’ ; Para la creaci´on del analizador l´exico se ha utilizado ANTLR[36], herramienta software para el trabajo con lenguajes (apartado 6.2). A partir de una especificaci´on l´exica como la anterior, ANTLR genera autom´aticamente el analizador en Java. Cabe destacar que los fragmentos de c´odigo mostrados son solo una peque˜na parte del l´exico desarrollado. 42 CAP´ ITULO 6. TRABAJO INSTRUMENTAL 6.1.2. An´alisis sint´actico La fase de an´alisis sint´actico trata de evaluar si una sucesi´on de s´ımbolos, suministrados por el l´exico, siguen una determinada estructura sint´actica definida por el lenguaje. El desarrollo de un analizador sint´actico requiere definir una gram´atica. Las gram´aticas son estructuras con un conjunto de reglas de formaci´on que definen las cadenas de caracteres admisibles en un determinado lenguaje. La hip´otesis de este trabajo se centra en la existencia de una gram´atica gen´erica que permita la definici´on de m´ultiples DSLs para diversos dominios. Por tanto, esta etapa resulta crucial para su posible validaci´on. La gram´atica dise˜nada corresponde a una gram´atica libre del contexto, tipo 2 de la jerarqu´ıa de Chomsky[5] (apartado 4.2). En este tipo de gram´aticas cada regla de producci´on sigue la forma: V→w siendo V un s´ımbolo no terminal y w una cadena de terminales y/o no terminales. A continuaci´on se describen las estructuras principales que conforman la gram´atica del super-lenguaje Proteo. La gram´atica dise˜nada comparte las mismas notaciones que el l´exico para expresar multiplicidad (‘+’ y ‘*’) y opcionalidad (‘?’). Variables Las variables son los par´ametros de los que dispone un elemento. En Proteo se han predefinido ciertos tipos primitivos de variables, como los n´umeros naturales, enteros o reales, booleanos, cadenas de texto, fechas, words (enumerados) y referencias. La manera en que son expresadas las variables es mediante la palabra clave “var”, tipo primitivo (como “string”, “integer”, “boolean”, etc), identificador y 6.1. HERRAMIENTAS DESARROLLADAS 43 la asignaci´on de un valor determinado. La asignaci´on es opcional. El ejemplo 6.7 ilustra una variable de tipo cadena de texto. C´odigo 6.7: Ejemplo variable. var string nombre = "Antonio" La gram´atica para todos los primitivos es muy similar, salvo por el token que indica el tipo y el valor que pueden tener. Las ´unicas excepciones son los enumerados, que requieren m´ultiples valores, y las referencias, que requieren el nombre de un elemento al que referenciar. La gram´atica 6.8 detalla la regla para la formaci´on de variables y especifica c´omo es la asignaci´on para el caso de las cadenas de texto. La figura 6.2 ilustra el ejemplo 6.7 a trav´es del ´arbol de derivaci´on. C´odigo 6.8: Sintaxis variable. v a r i a b l e : VAR ( i n t e g e r At t r i b u t e |doubleAttribute |booleanAttribute |stringAttribute |dateAttribute |r e f e r e n c e |word ) ; s t r i n g A t t r i b u t e : STRING TYPE LIST? IDENTIFIER (EQUALS STRING VALUE+)? ; string nombre = "Antonio" STRINGTYPE IDENTIFIER EQUALS stringValue stringAttribute variable Figura 6.2: ´ Arbol de derivaci´on de una variable. 44 CAP´ ITULO 6. TRABAJO INSTRUMENTAL Elementos Los elementos son los principales protagonistas del super-lenguaje, pues son el elemento b´asico de definici´on (de ah´ı su nombre). Sint´acticamente conforman una estructura bastante compleja. La definici´on de un elemento en el lenguaje dispone de tres aspectos importantes: 1. Firma (signature) 2. Anotaciones y facetas (annotationsAndFacets) 3. Cuerpo (body) Gramaticalmente, estos tres aspectos conforman la regla de un elemento, como refleja el c´odigo 6.9. De entre las tres reglas, la ´unica obligatoria es la firma. C´odigo 6.9: Sintaxis elemento. element: s ign atur e annotationsAndFacets ? body? ; Firma. La firma del elemento corresponde a la declaraci´on misma del elemento y sus propiedades. En ella se declaran los siguientes aspectos: 1. Elemento instanciable. 2. Identificador (nombre) del elemento declarado. 3. Inicializaci´on de los posibles par´ametros contenidos por el instanciable. 4. Posible herencia de otro elemento declarado en el lenguaje. En el c´odigo 6.10 se puede ver el ejemplo de una firma. En concreto, se declara un elemento formulario (instanciable Form) que toma el nombre de FichaTecnica. Asimismo, inicializa su etiqueta (par´ametro que tiene en el metamodelo el instanciable Form) con el valor “Formulario 001” y hereda las propiedades de otro elemento llamado FichaGenerica. Gramaticalmente, la firma del modelo queda como en el c´odigo 6.11. 6.1. HERRAMIENTAS DESARROLLADAS 45 C´odigo 6.10: Ejemplo firma. Form FichaTecnica ( l a b e l=" Formulario 001" )extends FichaGenerica C´odigo 6.11: Firma elemento. s i g n a t u r e : METAIDENTIFIER IDENTIFIER parameters ? (EXTENDS identifierReference)?; Destacar el token METAIDENTIFIER que indica el tipo de elemento instanciable a utilizar en la declaraci´on del elemento. La regla “parameters” representa a una posible lista de par´ametros, mientras que “identifierReference” es el nombre o ruta de un elemento definido en el modelo. El ´arbol de derivaci´on de la figura 6.3 aclara la firma del ejemplo anterior. g label=IFormularioE001I ) Form FichaTecnica LP parameter RP extends FichaGenerica METAIDENTIFIER IDENTIFIER parameters EXTENDS identifierReference signature Figura 6.3: ´ Arbol de derivaci´on, ejemplo firma. Anotaciones yfacetas. Las anotaciones permiten dotar a un elemento de una determinada propiedad, por ejemplo, que sea de solo lectura. Por su parte, las facetas son elementos no instanciables que aportan funcionalidades o comportamientos a otros elementos. En ambos casos son aplicados con la palabra reservada “is” junto a la firma del elemento. En 6.12 se expone un ejemplo de un elemento con m´ultiples anotaciones. C´odigo 6.12: Anotaciones elementos. Form FichaTecnica i s named single 52 CAP´ ITULO 6. TRABAJO INSTRUMENTAL Figura 6.7: Recorrido por el ´arbol de derivaci´on. JRE, Java Runtime Environment. JRE incluye la JVM, librer´ıas y componentes que son necesarios para ejecutar programas escritos en Java. JRE est´a disponible para m´ultiples plataformas, entre las que se encuentran MAC, Windows y Unix. JDK, Java Development Kit. Es un kit de desarrollo de software (SDK) para la creaci´on de programas en Java. Intellij IDEA. Es un entorno de desarrollo integrado (IDE) multiplataforma para la programaci´on en Java. Entre sus caracter´ısticas se encuentran: el autocompletado inteligente de c´odigo, integraci´on con sistemas de control de versiones, modularidad y posibilidad de ampliaci´on usando plugins. Durante el desarrollo de este trabajo se ha utilizado un plugin de ANTLR para Intellij que integra ciertas funcionalidades, como el reconocimiento de gram´aticas ANTLR o la generaci´on del reconocedor (parser). Sistema operativo. El uso de Java, ANTLR e Intellij Idea no condiciona la elecci´on del sistema operativo, pues todos ellos se encuentran disponibles en diversas plataformas. En este trabajo se utiliz´o un sistema operativo Windows 7 de 64 bits que el autor ten´ıa instalado previamente. 6.3. METODOLOG´ IAS DE DESARROLLO 53 Recursos Hardware A continuaci´on se expone el hardware empleado para el desarrollo del trabajo. Cabe destacar que el software utilizado no requiere el uso de hardware de alto rendimiento. Equipo inform´atico. Se utiliz´o un ordenador port´atil HP Envy 14 con las siguientes caracter´ısticas: •CPU: Intel Core i7-720QM •Memoria RAM: 4 GB •Disco duro: 500 GB 6.3. Metodolog´ıas de desarrollo Durante el desarrollo del trabajo se han seguido una metodolog´ıa iterativa incremental, aplicando el enfoque Specification by Example. Se han escogido estas metodolog´ıas para seguir un desarrollo paulatino y mediante ejemplos de uso real. 6.3.1. Iterativo incremental El desarrollo iterativo incremental[30] se compone de un conjunto de tareas agrupadas en peque˜nas etapas repetitivas (iteraciones). El comportamiento deseado es que en cada iteraci´on el producto evolucione con respecto al resultado de las iteraciones antecesoras, introduciendo nuevos requisitos y logrando as´ı una mejora paulatina. Las tareas definidas en este trabajo para cada iteraci´on son las siguientes: 1. Definici´on del super-lenguaje. 2. Desarrollo del analizador l´exico. 3. Desarrollo del analizador sint´actico. 4. Desarrollo del analizador sem´antico. 54 CAP´ ITULO 6. TRABAJO INSTRUMENTAL Finalmente, tras terminar todas las etapas, se eval´ua el resultado y deciden nuevos requisitos a introducir en la iteraci´on siguiente. 6.3.2. Specification-by-example En el entorno de las metodolog´ıas ´agiles, Specification by Example[1] (SBE) es un enfoque para la definici´on de los requisitos de software impulsado por usuarios. Se encuadra dentro del proceso de desarrollo software denominado BehaviourDriven Development (desarrollo basado en el comportamiento). SBE requiere de expertos en el dominio que proporcionen escenarios realistas de c´omo se utilizar´a el software, as´ı como posibles ejemplos de uso. De este modo, el desarrollo del software se enfoca en ejemplo de uso reales. Este enfoque dispone de dos ventajas principales: 1. Fomenta la comunicaci´on continua entre las compa˜n´ıas de negocio y el equipo de desarrollo software. 2. Ayuda a los desarrolladores a especificar el software con pruebas de uso real. La aplicaci´on de SBE permite conocer desde el inicio los requisitos del software. Ello evita rehacer trabajo, mejorando as´ı la productividad y aumentando el tiempo de respuesta ante cambios del software[1]. En este trabajo se han utilizado ejemplos de uso reales de sistemas de informaci´on y de simulaci´on[15] para la definici´on del super-lenguaje desarrollado (apartado 5). Cap´ıtulo 7 Resultado El resultado de este trabajo es un super-lenguaje para facilitar la creaci´on de de lenguajes espec´ıficos de dominio. El super-lenguaje es an´alogo a una superclase en un lenguaje de programaci´on orientado a objetos, ya que permite la creaci´on de un lenguaje derivado heredando todas las propiedades y estructura del mismo. A continuaci´on es posible ver dos ejemplos de Lenguajes Espec´ıficos de Dominio (DSL) implementados a partir del super-lenguaje Proteo, donde ambos disponen de la gram´atica gen´erica dise˜nada. El primero de ellos corresponde a un lenguaje espec´ıfico para el ´ambito de los sistemas de informaci´on. El modelo descrito (c´odigo 7.1) representa la definici´on de un formulario de ficha t´ecnica, el cual dispone de un campo nombre, una fecha de nacimiento y una secci´on en la cual cumplimentar la direcci´on. C´odigo 7.1: Modelo de formulario. Form Ficha ( l a b e l="FichaTecnica" ) TextField Nombre( "nombre " ) DateField FechaNacimiento ( l a b e l="Fecha de nacimiento " , precision= DAYS) CompositeField Dir ecc ion ( l a b e l="Direccion " ) TextField Ca ll e ( " Calle" ) TextField Numero ( "Numero " ) 55 56 CAP´ ITULO 7. RESULTADO Por su parte, el segundo DSL pertenece al dominio de los sistemas de simulaci´on. El modelo (c´odigo 7.2) define los distintos tipos de lugares que existen, donde cada uno de ellos dispone de un clima. C´odigo 7.2: Modelo de lugares. D e f i n i t i o n Place i s named var Weather weather = empty sub Neighborhood sub District has Neighborhood sub Urbe has District sub Region has City sub Country has Region Ambos lenguajes toman al super-lenguaje Proteo como base. A partir de ´el, cada DSL especifica en su l´exico los elementos instanciables en su ´ambito de conocimiento particular. Por ejemplo, en el lenguaje para los sistemas de informaci´on (c´odigo 7.1) se habr´an definidos los instanciables: Form, TextField, DateField y CompositeField. Por su parte, la gram´atica y sem´antica es igual en ambos DSLs. Cap´ıtulo 8 Conclusiones Este trabajo es consecuencia de la problem´atica existente en el ´ambito del desarrollo de software. Uno de ellos es la falta de flexibilidad de los equipos de desarrollo para adoptar cambios en los requisitos del cliente. Otro problema es la complejidad existente tanto a nivel tecnol´ogico como en las propias necesidades de los usuarios. Estas dos dimensiones requieren fortalecer la comunicaci´on entre usuarios y desarrolladores. El enfoque de este trabajo para aportar soluciones a esta problem´atica es una metodolog´ıa llamada Generative Models Driven Engineering. Este enfoque es una l´ınea de investigaci´on del SIANI[11] en MDE, en la que se define un motor de prop´osito general capaz de interpretar modelos de una misma familia de metamodelos. Este motor puede operar sobre estos modelos ya que comparten la misma estructura profunda definida en un metametamodelo. En general, MDE se apoya en el uso de Lenguajes Espec´ıficos de Dominio (DSL) con los que se pueden expresar los modelos con un lenguaje m´as cercano al dominio de aplicaci´on. Estos lenguajes pueden disponer de una curva de aprendizaje suave, no obstante, diferentes DSLs disponen de diferentes mecanismos para expresar los modelos. El coste de aprendizaje de cada uno de ellos conlleva un coste de tiempo y esfuerzo considerable. Debido a esta problem´atica, en este trabajo se plantea la posibilidad de reducir la curva de aprendizaje entre diferentes DSLs. 57 58 CAP´ ITULO 8. CONCLUSIONES Un estudio del estado del arte ha permitido comprobar en qu´e estado se encuentran los conceptos manejados en el documento. Al mismo tiempo, nos da una visi´on completa de los diversos enfoques y aplicaciones que realizan otros investigadores que trabajan con MDE. La problem´atica existente lleva a formular la siguiente pregunta ¿Podr´ıa existir un lenguaje abstracto a partir del cual pudieran derivarse lenguajes espec´ıficos para cada dominio? De ser as´ı, todos los lenguajes ser´ıan expresables mediante una misma sintaxis, variando solo el catalogo de palabras (l´exico) propio de cada dominio. Una gram´atica gen´erica da pie a la creaci´on de un super-lenguaje, entendido ´este como un lenguaje abstracto que puede ser extendido para definir DSLs. Por tanto, la hip´otesis que sigue esta l´ınea de investigaci´on es “si los dominios son expresables como un conjunto de elementos instanciables, asociados entre s´ı por relaciones de composici´on, agregaci´on, abstracci´on y concreci´on; debiera ser posible la existencia de una gram´atica com´un a todos los dominios y, por tanto, la creaci´on de un super-lenguaje.”. En este trabajo se ha creado un super-lenguaje con el nombre de Proteo. El prop´osito Proteo es permitir la definici´on de Lenguajes Espec´ıficos de Dominio para el modelado bajo la metodolog´ıa Model Driven Engineering. Proteo constituye la base com´un para todos los DSLs. Asimismo, se han desarrollado diversos analizadores para comprobar la validez de los modelos. La validaci´on de la hip´otesis conlleva probar que la gram´atica construida permita crear DSLs para todos los dominios del mundo. Esto no es posible, al ser el n´umero de dominios infinito. Por ello, se llevar´an a cabo futuras experimentos que permitan observar que la hip´otesis es v´alida para aquellos ´ambitos aplicados. Sin embargo, nunca se tendr´a la certeza de que sea v´alido para todos. Ser´a misi´on de otros investigadores encontrar ´ambitos en los que no se aplicable y, por tanto, puedan refutar la hip´otesis. 59 Este proyecto aporta la base para construir lenguajes espec´ıficos de dominio. A trav´es de estos DSLs, el desarrollador modela la realidad utilizando elementos de su contexto. Ello ayuda a mejorar la comunicaci´on entre el equipo de desarrollo y los expertos en el dominio. Asimismo, este enfoque aporta eficiencia y productividad a aquellas personas que trabajen con m´ultiples DSL al reducir la curva de aprendizaje. Como continuaci´on a este trabajo se deber´a validar la capacidad de la gram´atica dise˜nada para describir DSLs en otros dominios. Ello dar´a pie al inicio de una investigaci´on en la cual se creen nuevos lenguajes en ´ambitos a´un no contemplados. De manera complementaria, esto permitir´a refinar los mecanismos ya existentes del super-lenguaje e introducir algunos no planteados hasta el momento. Adicionalmente, se tratar´a de mejorar la expresividad del super-lenguaje para conseguir lenguajes cada vez m´as sencillos de manejar y entender. 60 CAP´ ITULO 8. CONCLUSIONES Bibliograf´ıa [1] G Adzic. Specification by Example: How Successful Teams Deliver the Right Software. Manning Pubs Co Series. Manning, 2011. [2] AV Aho, R Sethi, and JD Ullman. Compilers: Principles. Techniques, and Tools, 1986. [3] JW Backus. The syntax and semantics of the proposed international algebraic language of the Zurich ACM-GAMM conference. Proceedings of the International Comference on . . . , 1959. [4] C Brooks, TH Feng, EA Lee, and R van Hanxleden. Multimodeling: A preliminary case study. 2008. [5] N Chomsky. Three models for the description of language. Information Theory, IRE Transactions on, 1956. [6] N Chomsky. Syntactic structures. 2002. [7] Noam Chomsky. Aspects of the theory of syntax. Technical report, DTIC Document, 1964. [8] Microsoft Corporation. Microsoft Software Factories. http://msdn.microsoft.com/en-us/library/ff699235.aspx. [9] JS Cuadrado. Applying model-driven engineering in small software enterprises. Science of Computer . . . , 2014. 61