Máster MNTI Desarrollo Dirigido por Modelos. Seminario 2 - Sintaxis concretas textuales

Transcripción

1 Máster MNTI Desarrollo Dirigido por Modelos Seminario 2 - Sintaxis concretas textuales Grupo Modelum Universidad de Murcia 10 de noviembre de 2010 Resumen Una vez que se ha creado la sintaxis abstracta o metamodelo de un DSL, la siguiente tarea es definir su sintaxis concreta o notación. Dicha notación puede ser gráfica o textual. En este seminario de presentará la herramienta EMFText, la cual permite dotar de una sintaxis concreta textual a la sintaxis abstracta de un DSL. 1

2 1. Introducción Una vez que se ha creado la sintaxis abstracta o metamodelo de un DSL, la siguiente tarea es definir su sintaxis concreta o notación. Dicha notación puede ser gráfica o textual. En este seminario veremos como crear una notación textual utilizando la herramienta EMFText. Esta herramienta permite crear una sintaxis concreta textual a partir de un metamodelo ya definido. 2. EMFText EMFText se integra en la plataforma Eclipse como un plugin y permite la definición de sintaxis textuales para lenguajes descritos por un metamodelo Ecore, ofreciendo un lenguaje de especificación de sintaxis textuales. A partir de un fichero descrito por dicho lenguaje, EM- FText genera un inyector para crear modelos conformes al metamodelo de sintaxis abstracta a partir de texto y un extractor para crear la representación textual a partir de un modelo de la sintaxis abstracta. También genera un editor de Eclipse con resaltado de sintaxis para la sintaxis textual, el cual incorpora también una vista outline y detección de errores. Este editor se genera como un plugin para Eclipse. Suponiendo que se dispone del metamodelo de la sintaxis abstracta, el proceso de desarrollo de un DSL textual en EMFText es el siguiente: (1) definir la sintaxis concreta para la sintaxis abstracta del DSL utilizando el lenguaje de especificación de sintaxis textuales ofrecido por EMFText y (2) generar el inyector y extractor para la especificación de la sintaxis abstracta, así como el editor de Eclipse para el DSL. El editor generado puede ser probado en una nueva instancia de Eclipse para ir refinando la especificación de la sintaxis concreta. Una vez finalizada, puede ser exportado como un plugin de Eclipse para utilizar el DSL de forma independiente. El funcionamiento de EMFText se ilustra en la Figura 1. En primer lugar, se define la sintaxis concreta para la sintaxis abstracta, dicha sintaxis concreta está representada por el elemento CS Specification. A partir de la sintaxis concreta y la abstracta, EMFText genera un conjunto de artefactos software. El elemento printer conforma el extractor para la sintaxis abstracta, este elemento permite extraer la representación textual a partir de un modelo conforme a la sintaxis abstracta. El elemento grammar permite crear el inyector para la sintaxis abstracta y es utilizado para crear un parser el cual permitirá reconocer la sintaxis concreta y generar los modelos conformes a la sintaxis abstracta. El elemento EMFText Resource es utilizado por la plataforma Eclipse para almacenar y cargar los modelos Ecore de la sintaxis abstracta, tal y como se explicará en la sección 5. Finalmente, los Resolvers se generan para ofrecer puntos de extensión al comportamiento predeterminado de EMFText para resolver las referencias entre elementos. Figura 1: Funcionamiento de EMFText 2

3 3. Lenguaje de especificación de sintaxis textual Este lenguaje permite dotar de una sintaxis concreta textual a la definición de sintaxis abstracta. Las definiciones de sintaxis textuales se almacenan en ficheros con extensión.cs y están compuestas principalmente por tres bloques: 1. Bloque de configuración, el cual contiene el nombre, el metamodelo base y la metaclase que actúa como raíz. Opcionalmente puede importar otras sintaxis y metamodelos, así como también pueden establecerse atributos para parametrizar la generación. 2. Un bloque opcional de tokens léxicos. Estos tokens son utilizados por el analizador léxico. También puede incluirse, opcionalmente, un bloque que indique el estilo de los tokens. 3. Un bloque de reglas, las cuales defines la sintaxis concreta para cada metaclase. En las secciones siguiente veremos en detalle cada uno de estos bloques. En al apéndice A se muestra un ejemplo de este lenguaje para la sintaxis abstracta de los Blogs del primer seminario Bloque de configuración Los elementos obligatorios de este bloque son los siguientes: Nombre de la definición de la sintaxis concreta. Además de dar un nombre a la sintaxis concreta, este atributo indica la extensión de los ficheros de este DSL. SYNTAXDEF fileextension URI del metamodelo que contiene las metaclases a las que se quiere dotar de una sintaxis textual. También se puede indicar la ruta para localizar el metamodelo, pero es opcional. Si no se indica, EMFText busca en primer luegar en el registro de EMF y, en segundo lugar, en el directorio donde se encuentre el fichero.cs (buscará el fichero con el mismo nombre pero con extensión.genmodel). FOR < genmodeluri > < locationofyourgenmodel > El elemento raiz del metamodelo o símbolo de inicio. Si es múltiple, deben enumerarse utilizando la coma como caracter separador. START nameofametaclass Los elementos opcionales de este bloque son los siguientes: Importación de otros metamodelos y sintaxis. La lista de elementos a importar debe contener al menos una entrada. Cada entrada indica el prefijo a utilizar para referirse a los elementos que se importan, la URI del metamodelo y opcionalmente el nombre de la sintaxis concreta definida para dicho metamodelo. Indicar las rutas para localizar el metamodelo y la sintaxis es opcional. IMPORTS { prefix : < genmodeluri > < locationofthegenmodel > WITH SYNTAX syntaxuri < locationofthesyntax >;... 3

4 Parametrización de la generación. Las opciones para parametrizar la generación del código llevada a cabo por EMFText se indican en esta sección. En el Apéndice B se puede encontrar un listado con las opciones más importantes. OPTIONS { // options go here in the following form : optionname = " optionvalue "; 3.2. Bloque de tokens léxicos Durante la fase de reconocimiento de la sintaxis textual, los caracteres de entrada son convertidos a tokens, que son la unidad mínima que procesa el parser. Por defecto, EMFText proporciona los siguientes tokens predefinidos: TEXT : ( A.. Z a.. z _ - )+ LINEBREAK : ( \r\n \r \n ) WHITESPACE : ( \t \f ) Sin embargo, el desarrollador puede definir sus propios tokens haciendo uso del bloque de tokens léxicos. Cada token definido en este bloque esta compuesto por un nombre (que debe comenzar por mayúscula) y por una expresión regular (conforme al formato de ANTLRv3). TOKENS { // token definition go here in the form : DEFINE MY_TOKEN $someregularexpression$ ; Opcionalmente, se puede incluir un bloque para indicar el estilo de los token en el editor textual de Eclipse. Esta característica permite asignar un color y formato a los tokens. Las palabras clave para indicar el formato pueden ser BOLD, ITALIC, STRIKETHROUGH, UNDERLINE. TOKENSTYLES { // show MY_TOKEN in black " MY_TOKEN " COLOR #000000; // show keyword public in red and bold font face " public " COLOR # FF0000, BOLD ; 3.3. Bloque de reglas Las reglas sintácticas se definen para cada metaclase concreta de la sintaxis abstracta. Cada regla especifica la representación textual de una metaclase y tiene dos partes: la parte izquierda y la parte derecha. La parte izquierda indica el nombre de la metaclase a la cual se va a indicar la sintaxis concreta. La parte derecha define los elementos sintácticos que conforman la representación textual de la metaclase. La regla más básica es MyMetaClass ::= " somekeyword " ; Esta regla indica que siempre que se encuentre el texto somekeyword se creará una instancia de MyMetaClass. Los elementos sintácticos también pueden incluir partes opcionales o repetición. Por ejemplo, en la siguiente regla: MyMetaClass2 ::= ("#")? " somekeyword " ; Las instancias de MyMetaClass2 pueden ser representadas por somekeyword y #somekeyword. Del mismo modo, pueden ser utilizados los operadores + y *. Por otro lado, la especificación de la sintaxis para los atributos de las metaclases se realiza añadiendo los corchetes al final del nombre del atributo. Por ejemplo: 4

5 MyMetaClass3 ::= " Mymeta " myattribute [] ; Opcionalmente se puede especificar el token que debe reconocerse para el atributo. Por ejemplo MyMetaClassWithAttributes ::= myattribute [ MY_TOKEN ] ; Si no se indica el token, EMFText utiliza TEXT por defecto. La cadena de texto reconocida es convertida automáticamente al tipo del atributo. Finalmente, para la sintaxis de las referencias se debe distinguir entre referencias contenedoras y no contenedoras. En un metamodelo Ecore, las referencias contenedoras de un elemento padre incluyen a los elementos a los que referencian. De esta forma, EMFText supone que la sintaxis textual de los elementos referenciados estén también contenidos en la sintaxis textual del padre. Por otra parte, los elementos referenciados por referencias no contenedoras solamente apuntan a los elementos. En este caso, los elementos referenciados son representados normalmente por un identificador. Un ejemplo para definir una regla para una metaclase que tiene una referencia contenedora sería: MyContainerMetaClass ::= " CONTAINER " mycontainmentreference * ; Esta regla permite representar instancias de MyContainerMetaClass utilizando la palabra clave CONTAINER seguida de una o más instancias del tipo mycontainmentreference, es decir, la representación textual de dicha metaclase. Para el caso de referencias no contenedoras, un ejemplo sería: MyPointerMetaClass ::= " POINTER " mynoncontainmentreference []* ; Esta regla es parecida a la anterior, sin embargo, utiliza los corchetes después del nombre de la referencia, indicando el token que debe utilizarse para representar el identificador que apunta a la metaclase de la referencia. Por defecto, el tipo de token es TEXT. Un ejemplo de representación textual para la metaclase MyPointerMetaClass sería POINTER a. Dado que a es un identificador para MyNonContaimentReference, se buscaría una instancia (representación textual) de dicha metaclase para resolver la referencia. 4. Creación de DSLs en EMFText La definición de la sintaxis textual para un metamodelo o sintaxis abstracta debe estar incluida en un proyecto de tipo EMF. Este proyecto debe ser creado a partir de la sintaxis abstracta, produciendo de esta manera la creación del modelo generador (fichero.genmodel). Una vez creado el proyecto, se debe incluir el fichero de definición de sintaxis textual para definir la sintaxis concreta y utilizar el generar de EMFText Resumen de comandos File New... EMF Project Crear proyecto EMF a partir de un metamodelo Ecore File New... Other... EMFText.cs file Crear un fichero de especificación de sintaxis textual 5

6 Click der. (.cs) Generate Text Resource Generar la infraestructura de EMFText Click der. (proyecto generado) Run As Eclipse Application Ejecutar el plugin con el editor para la sintaxis concreta 5. Extracción de modelos conformes a la sintaxis abstracta Por defecto, EMFText ofrece un entorno de edición para la sintaxis concreta textual definida ocultando el trabajo con los modelos que representan la sintaxis abstracta para una determinada definición textual. Sin embargo, en algunos casos es necesario obtener dichos modelos, por ejemplo, para independendizarse de la plataforma Eclipse o para realizar tareas con estos modelos, como aplicar transformaciones de modelos. Durante el proceso de generación, EMFText crea un conjunto de recursos EMF que permiten trabajar con los ficheros de sintaxis textual sin necesidad de ejecutar el entorno de edición. De esta forma, se puede acceder programáticamente para leer un fichero definido textualmente y obtener su modelo Ecore conforme a la sintaxis abstracta. Una vez se dispone de dicho modelo, se podrían aplicar transformaciones para obtener otros modelos o generar código. Para obtener los modelos de la sintaxis concreta se debe crear una clase Java que realice la lectura de la sintaxis textual y genere el modelo. Se deberá utilizar el recurso de EMF creado por EMFText para cargar el modelo conforme a la sintaxis abstracta a partir del fichero textual y luego utilizar el recurso de EMF para almacenar dicho modelo en formato Ecore. El código de la clase que realiza estas tareas para el ejemplo de los Blog se puede encontrar en el Apéndice C. 6

7 6. Ejercicios Ejercicio 1. Especificar la sintaxis textual para la sintaxis abstracta definida en el seminario 1 de metamodelado. Un ejemplo de instancia de la sintaxis textual sería el siguiente: application_menu MyMenu ; tree_menu File ( visible : true, active : true, iconpath : / icons / file. gif ) { action_menu new ( visible : true ) action_menu saveas ( visible : true, active : false ) checkbox_menu autosave ( checked : true, visible : true, active : false ) action_menu close ( visible : true, active : true ) link_menu filefasthelp links Help ( visible : false, active : true ) tree_menu Edit ( visible : true, active : true, iconpath : / icon / edit. gif ) { action_menu undo ( visible : false, active : true ) action_menu redo ( visible : false, active : false ) link_menu mysearch links Search ( visible : false ) link_menu editfasthelp links Help ( active : true ) tree_menu Search ( visible : true, active : true, iconpath : / icon / search. gif ) { action_menu searchinproject action_menu searchfile ( visible : false, active : true ) tree_menu Window ( visible : true, active : true, iconpath : / icon / search. gif ) { action_menu newwindow ( active : true ) link_menu WinFastHelp links Help action_menu Help ( visible : true, active : true, iconpath : / icon / help. gif ) profile AdvancedUser { use File use Edit use Window profile NoviceUser extends AdvancedUser { use File { block : autosave hide : saveas use Edit { merge : mysearch, editfasthelp -> mylinks use Window { hide : newwindow i18n { spanish { File ( showedname : " Fichero ", tooltip : " Menu Fichero ", mnemonic : f, shortcut : ctrl +f) new ( showedname : " Nuevo ", tooltip : " Crea un fichero ", mnemonic : n, shortcut : ctrl +n) saveas ( showedname : " Salvar como ", tooltip : " Salvar con otro nombre ", mnemonic : s, shortcut : ctrl +s) autosave ( showedname : " Autosalvar ", tooltip : " Autosalvar ", mnemonic : a, shortcut : ctrl +a) filefasthelp ( showedname : " Ayuda Fichero ", tooltip : " Ayuda contextual ", mnemonic : h, shortcut : ctrl +h) Edit ( showedname : " Edicion ", tooltip : " Menu Edicion ", mnemonic : e, shortcut : ctrl +e) undo ( showedname : " Deshacer ", tooltip : " Deshace el ultimo cambio ", mnemonic : u, shortcut : ctrl +u) redo ( showedname : " Rehacer ", tooltip : " Rehace el ultimo cambio 7

8 deshecho ", mnemonic : r, shortcut : ctrl +r) mysearch ( showedname : " Buscar ", tooltip : " Busqueda ", mnemonic : s, shortcut : ctrl +s) editfasthelp ( showedname : " Ayuda Edicion ", tooltip : " Ayuda contextual ", mnemonic : h, shortcut : ctrl +h) Search ( showedname : " Buscar ", tooltip : " Menu Busqueda ", mnemonic : b, shortcut : ctrl +b) searchinproject ( showedname : " Buscar en proyecto ", tooltip : " Busca en proyecto ", mnemonic : p, shortcut : ctrl +p) searchfile ( showedname : " Buscar fichero ", tooltip : " Busca un fichero ", mnemonic : f, shortcut : ctrl +f) Window ( showedname : " Ventana ", tooltip : " Menu Ventana ", mnemonic : v, shortcut : ctrl +v) newwindow ( showedname : " Nueva ventana ", tooltip : " Abre una nueva ventana ", mnemonic : n, shortcut : alt +n) WinFastHelp ( showedname : " Ayuda ventana ", tooltip : " Ayuda contextual ", mnemonic : h, shortcut : ctrl +h) Help ( showedname : " Ayuda ", tooltip : " Ayuda contextual ", mnemonic : h, shortcut : ctrl +h) El fichero de definición de la sintaxis textual (fichero.cs) junto con el fichero de la sintaxis abtracta (fichero.ecore) deberán ser enviados por correo electrónico a jlcanovas@um.es. Se valorará la correcta definición de las reglas de definición de sintaxis textual así como la definición de tokens léxicos apropiados. Es recomendable probar el correcto reconocimiento del ejemplo textual anterior para validar la definición de sintaxis concreta textual. 8

9 A. Ejemplo de EMFText para el metamodelo de los Blogs SYNTAXDEF Blog FOR <http : // modelum. es / imaci09 / blog > START Blogosphere OPTIONS { overridepluginxml = " false "; overridemanifest = " false "; reloadgeneratormodel = " true "; generatecodefromgeneratormodel = " true "; generatetestaction = " true "; TOKENS { DEFINE STRING_LITERAL $ \ ( \\ ( n r t b f " \ \\ > u ( a.. f A.. F )( a.. f A.. F )( a.. f A.. F )( a.. f A.. F ).) ~( \ \\ ))( \\ ( n r t b f " \ \\ > u ( a.. f A.. F )( a.. f A.. F )( a.. f A.. F )( a.. f A.. F ).) ~( \ \\ ) )* \ $; RULES { Blogosphere ::= blogs *; Blog ::= " Blog " ( name [])? "{" posts * categories * ""; Post ::= " Post " name [] "{" " Content :" value [ STRING_LITERAL ] comments * trackbacks *""; Category ::= " Category " name [] ";"; Comment ::= " Comment " author [] " Content :" value [ STRING_LITERAL ]; Trackback ::= " Trackback " link [] " Content :" value [ STRING_LITERAL ]; 9

10 B. Opciones para parametrizar la generación de EMFText overridepluginxml. Es un booleano que indica si debe sobreescribirse el fichero plugin.xml cada vez que EMFText genere el nuevo proyecto. overridemanifest. Es un booleano que indica si debe sobreescribirse el fichero manifest.mf cada vez que EMFText genere el nuevo proyecto. reloadgeneratormodel. Es un booleano que indica si debe cargarse el metamodelo cada vez que se guarde el fichero de sintaxis concreta. usepredefinedtokens. Es un booleano que activa o desactiva el uso de los tokens léxicos predefinidos. tokenspace. Es un valor entero que indica el número de espacios en blanco que pueden permitirse entre tokens. La lista completa de opciones se encuentra en current release/emftext/org.emftext.sdk.concretesyntax/src-gen/org/emftext/sdk/concretesyntax/ OptionTypes.java 10

11 C. Clase Java para la obtención del modelo de la sintaxis abstracta Para poder utilizar esta clase Java y que se resuelvan correctamente las referencias, debe estar situada en el proyecto que genera automáticamente EMFText y además incluir la dependencia con org.eclipse.emf.ecore.xmi en la pensaña Dependencies del fichero plugin.xml. package blog.resource; import java.io.ioexception; import java.util.collections; import java.util.iterator; import org.eclipse.emf.common.util.uri; import org.eclipse.emf.ecore.eobject; import org.eclipse.emf.ecore.resource.resource; import org.eclipse.emf.ecore.resource.resourceset; import org.eclipse.emf.ecore.resource.impl.resourcesetimpl; import org.eclipse.emf.ecore.xmi.impl.ecoreresourcefactoryimpl; import blog.resource.blog.blogresourcefactory; public class ExtractEcore { public static String EXTENSION = "Blog"; public static String TEXTUAL_FILE_PATH = "../../runtime-eclipseapplication/asfd/mine.blog"; public static String RESULT_MODEL_PATH = "result.ecore.xmi"; public static void main(string[] args) throws IOException { // This Resource Factory must be set BlogResourceFactory factory = new BlogResourceFactory(); ResourceSet rs = new ResourceSetImpl(); rs.getresourcefactoryregistry().getextensiontofactorymap().put(extension, factory); Resource resourceload = rs.createresource(uri.createfileuri(textual_file_path)); resourceload.load(collections.empty_map); traversereferences(resourceload); ResourceSet rs2 = new ResourceSetImpl(); rs2.getresourcefactoryregistry().getextensiontofactorymap().put( "xmi", new EcoreResourceFactoryImpl()); Resource r2 = rs2.createresource(uri.createfileuri(result_model_path)); try { r2.getcontents().add(resourceload.getcontents().get(0)); r2.save(null); catch (IOException e) { e.printstacktrace(); /** * Traverse the non-containment references in order to force to EMFText to resolve them resource */ private static void traversereferences(resource resource) { Iterator<EObject> contents = resource.getallcontents(); while (contents.hasnext()) { EObject object = contents.next(); Iterator<EObject> crossref = object.ecrossreferences().iterator(); while(crossref.hasnext()) { crossref.next(); 11