Expresión y composición de representaciones gráficas para metamodelos

Texto completo

(1)Expresión y composición de representaciones gráficas para Metamodelos. Trabajo de Tesis. Presentado al Departamento de Ingeniería de Sistemas y Computación. Por. Iván Mauricio Melo Suarez Asesor Jorge Alberto Villalobos Salcedo Ph.D Coasesor Mario Eduardo Sánchez PucciniPh.D. Para optar por el título de. Magíster en Ingenieríade Sistemas y Computación. Jurados Darío Ernesto Correal TorresPh.D Germán VegaPh.D. Ingeniería de Sistemas y Computación Universidad de los Andes Enero de 2012.

(2) Contenido Índice de Tablas ................................................................................................................................... 5 Capítulo I – Introducción ..................................................................................................................... 6 Capítulo II – Contexto del Trabajo ....................................................................................................... 9 2.1 Composición y adaptación de Metamodelos ............................................................................ 9 2.2 Herramientas de adaptación y composición de metamodelos ................................................ 9 Atlas Model Weaver .................................................................................................................. 10 Kompose.................................................................................................................................... 11 EnAr-Fusion ............................................................................................................................... 12 2.3 Lenguajes Gráficos y Generación de Herramientas ................................................................ 15 MetaEdit+ .................................................................................................................................. 16 GMF ........................................................................................................................................... 16 Eugenia ...................................................................................................................................... 17 GenGMF .................................................................................................................................... 18 Capítulo III – Definición del Problema ............................................................................................... 19 3.1 Problema General ................................................................................................................... 19 3.2. Pregunta de Investigación ................................................................................................. 19. Capítulo IV – Visión Global de la Solución ......................................................................................... 20 4.1 Objetivos de la Propuesta ....................................................................................................... 20 4.2 El proceso genérico para la composición de representaciones gráficas................................. 20 S1: creación del metamodelo del proyecto .............................................................................. 20 S2: Creación de la representación gráfica para el nuevo metamodelo ................................... 21 S3: Generación del Editor Grafico ............................................................................................. 21 S4: Uso del editor grafico de sintaxis específica ....................................................................... 22 Capítulo V – EnAr-Picture .................................................................................................................. 23 5.1 Expresando la representación gráfica por medio de EnAr-Picture ......................................... 23 Tipos de Nodos .......................................................................................................................... 24 Tipos de relaciones .................................................................................................................... 24 Conceptos Adicionales detrás de EnAr-Picture ......................................................................... 25 5.2 Herramientas detrás de EnAr-Picture ..................................................................................... 26 Capítulo VI – EnAr-Gromp: lenguaje de composición de representaciones gráficas ........................ 27 6.1 Expresando la composición de descripciones gráficas por medio de EnAr-Gromp ................ 27.

(3) Instrucciones de import ............................................................................................................ 27 Instrucciones sobre Nodos ........................................................................................................ 27 Instrucciones sobre relaciones .................................................................................................. 31 6.2 Relación entre las operaciones gráficas y las de composición ................................................ 33 6.3 Herramientas detrás de EnAr-Gromp ..................................................................................... 34 Capítulo VII – Caso de Estudio ........................................................................................................... 35 Etapa 1 del proceso de creación de un Editor Grafico .................................................................. 35 Metamodelo M1: Estructura organizacional ............................................................................ 35 Metamodelo M2: BPA ............................................................................................................... 37 Metamodelo M3: Stake Holder Domain ................................................................................... 37 Etapa 2 del proceso de creación de un Editor Grafico: Selección representaciones Gráficas. ..... 38 Metamodelo M1 Estructura organizacional: script de picture ................................................ 38 Metamodelo M1 Estructura organizacional: editor grafico generado .................................... 41 Metamodelo M2 BPA: script de picture ................................................................................... 41 Metamodelo M2 BPA: editor grafico generado ....................................................................... 47 Metamodelo M3 Stake Holder Domain: script de picture ........................................................ 48 Metamodelo M3 Stake Holder Domain: editor grafico generado ........................................... 50 Etapa 2 del proceso de creación de un Editor Grafico: Composición de las representaciones Gráficas.......................................................................................................................................... 50 Capítulo VIII – Conclusiones .............................................................................................................. 55 Capítulo IX – Bibliografía ................................................................................................................... 56 Anexos ............................................................................................................................................... 59 Anexo 1 – EBNF EnAr-Picture ........................................................................................................ 59 Anexo 2 – EBNF EnAr-Gromp ........................................................................................................ 63.

(4) Índice de Figuras Ilustración 1 – Proceso propuesto para crear editores gráficos ......................................................... 7 Ilustración 2 - Proceso de adaptación y composición de metamodelos. ............................................ 9 Ilustración 3 - Metamodelo de Tejido de AMW ................................................................................ 10 Ilustración 4 - Metamodelos Ejemplo EnAr-Fusion ........................................................................... 12 Ilustración 5 – Proceso de un editor gráfico con GMF ...................................................................... 17 Ilustración 6 – Creación del metamodelo del proyecto. ................................................................... 21 Ilustración 7 – Etapa de Creación de la representación gráfica para un nuevo metamodelo .......... 21 Ilustración 8 – Generación del editor de Sintaxis especifica ............................................................. 22 Ilustración 9 - Resultado del proceso ................................................................................................ 22 Ilustración 10 – Metamodelo EnAr-Picture ....................................................................................... 24 Ilustración 11 – Herramientas detrás de EnAr-Picture ..................................................................... 26 Ilustración 12 - Operaciones EnAr-Gromp: UnLink ........................................................................... 33 Ilustración 13 - Herramientas detrás de EnAr-Gromp ...................................................................... 34 Ilustración 14 - Entradas y Salidas del motor de Composición gráfica ............................................. 35 Ilustración 15 - - Metamodelo Estructura Organizacional ................................................................ 36 Ilustración 16 – Metamodelo BPA..................................................................................................... 37 Ilustración 17 – Metamodelo Stake Holders ..................................................................................... 37 Ilustración 18 – Metamodelo Compuesto ........................................................................................ 38 Ilustración 19 – Imagen Editor de estructura Organizacional ........................................................... 41 Ilustración 20 – Imagen Editor BPA ................................................................................................... 47 Ilustración 21 - Imagen Editor StakeHolders ..................................................................................... 50 Ilustración 22 - Modelo de una representación Gráfica ................................................................... 53 Ilustración 23 - Imagen de Un editor creado por medio de Composición ........................................ 54.

(5) Índice de Tablas Tabla 1 – Operaciones EnAr-Fusion .................................................................................................. 15 Tabla 2 – Formas como se puede representar una relación con EnAr-Picture ................................. 25 Tabla 3 – Operación EnAr-Gromp Join Side Order ............................................................................ 28 Tabla 4 – Operación EnAr-Gromp Join Top Order............................................................................. 29 Tabla 5 – Operación EnAr-Gromp Merge .......................................................................................... 29 Tabla 6 – Operación EnAr-Gromp Or ................................................................................................ 30 Tabla 7 – Operación EnAr-Gromp: Replace....................................................................................... 30 Tabla 8 – Operación EnAr-gromp: Create ......................................................................................... 30 Tabla 9 – Operación EnAr-Gromp: Change ....................................................................................... 31 Tabla 10 – Operación EnAr-Gromp: Split .......................................................................................... 31 Tabla 11 – Operaciones EnArGromp: Contain Outside Position ....................................................... 32 Tabla 12 – Operaciones EnAr-Gromp: Contain Inside Position ......................................................... 32 Tabla 13 – Operaciones EnAr-Gromp: ToLink ................................................................................... 32.

(6) Capítulo I – Introducción Hoy en día, en muchos contextos diferentes es común el uso de lenguajes de modelado que permiten la construcción de diagramas especializados. En estos contextos, la modularización de conceptos es un mecanismo ampliamente utilizado ya que permite separar diferentes intereses en varios metamodelos y luego, reutilizarlos por medio de una función de composición para crear un nuevo metamodelo que se ajuste el alcance e interés del proyecto, permitiendo ahorrar tiempo y esfuerzo. Sin embargo, crear un metamodelo compuesto es solo una parte del problema, debido a que después se hace necesario crear editores gráficos que permitan crear modelos conformes con el metamodelo del proyecto. Adicionalmente estos lenguajes de modelado pueden requerir representaciones gráficas particulares, cuando la representación genérica provista por las herramientas no es la adecuada, por ejemplo cuando hay un estándar establecido o cuando es deseable tener diferentes representaciones gráficas que se ajusten a las necesidades de diferentes usuarios. Sin embargo en las herramientas actuales que permiten componer metamodelos, las representaciones gráficas de estos no han sido consideradas. Debido a esto no es fácil crear una representación gráfica para un metamodelo compuesto, basándose en las representaciones originales de los metamodelos utilizados para crear el compuesto. Por lo tanto sería interesante modularizar la construcción de editores gráficos utilizando el mismo enfoque que se sigue en la construcción de metamodelos, pero aplicado a las representaciones gráficas de dichos metamodelos. Dicho enfoque permitiría reutilizar las representaciones gráficas existentes en nuevos proyectos, y facilitaría la generación de editores para metamodelos compuestos, permitiendo tener herramientas que se ajusten a necesidades específicas y visualizaciones de cada proyecto. Hoy en día en la industria, existen varias herramientas que facilitan la creación de editores gráficos, utilizando una estrategia de modularización, que separa los metamodelos de las representaciones gráficas. Debido a que esta independencia facilita la evolución de las partes y la adaptación a nuevos requerimientos que pueden afectar tanto la representación gráfica como la estructura misma del lenguaje. La propuesta presentada en este documento, utiliza la separación de intereses (como se representan los conceptos de un metamodelo y el metamodelo mismo) de otras propuestas, pero al mismo tiempo introduce la noción de composición de representaciones gráficas con el fin de facilitar la reutilización de las mismas y hacer más fácil y rápido el proceso de crear un nuevo editor gráfico. Para lograr esto debemos incluir nuevos pasos adicionales en el proceso: Durante el primer paso para cada metamodelo involucrado en la composición por ejemplo: M1 y M2, el usuario debe seleccionar la representación gráfica que desea utilizar, la cual puede ser una genérica u otra seleccionada del conjunto de representaciones existentes para cada metamodelo..

(7) En el presente ejemplo se supone que el usuario selecciona la representación gráfica GRi-M1 para el metamodelo M1 y GRj-M2 para el metamodelo M2. Durante el segundo paso, el usuario debe describir como desea adaptar (script A1 y A2) y después componer (script C12’) los metamodelos, para crear el metamodelo anotado M12’. En el tercer paso, el usuario debe describir cómo adaptar las representaciones gráficas seleccionadas (scripts GA-1, GA-2) y luego componer por medio de otro script (CG-12’), de forma que corresponda con la composición realizada con los metamodelos. De esta forma cuando el usuario llega al último paso del proceso, cuenta con el metamodelo compuesto (M12’) y una representación gráfica que describe como pintar los conceptos de dicho metamodelo, de forma que se pueda generar un editor gráfico. Esta idea se encuentra ilustrada en la Ilustración 1.. Ilustración 1–Proceso propuesto para crear editores gráficos. En el presente documento se proponen 3 cosas: (1) un lenguaje para expresar las representaciones gráficas, basado en las tecnologías actuales, pero ajustado para resolver los desafíos relacionados con la adaptación y composición; (2) un lenguaje para componer representaciones gráficas de acuerdo con la composición de metamodelos, el cual se encuentra basado en EnAr-Fusion, lenguaje propuesto en una tesis anterior [1]; (3) La infraestructura necesaria para llevar acabo la aproximación propuesta..

(8) Finalmente, ilustramos nuestra propuesta en el contexto de los proyectos de arquitectura empresarial, donde existen extensos catálogos de metamodelos, cada uno de los cuales representa una faceta particular del problema como los procesos de negocio, la estructura organizacional, el modelo estratégico, la infraestructura de TI, etc. Estos metamodelos no son necesariamente disyuntos y es usual que cada uno refleje un estándar diferente: ARMOR [9], BMM [10], ArchiMate [8], BPMN [11], KAOS [12], etc. Y es en el momento de iniciar un proyecto de arquitectura empresarial, que el arquitecto debe seleccionar los dominios que se encuentran dentro del alcance del proyecto y luego adaptarlos y componerlos hasta llegar a un metamodelo que refleje la estructura de los modelos que se quieren construir.Esto crea la necesidad de disponer de un editor gráfico que le ayude al arquitecto y los analistas a expresar el estado actual o deseo de la organización a través de un modelo..

(9) Capítulo II – Contexto del Trabajo 2.1 Composición y adaptación de Metamodelos La construcción de metamodelos por medio de la reutilización de otros existentes permite ahorrar tiempo y esfuerzo. Este proceso de reutilización se lleva a cabo por medio de 2 operaciones: la adaptación, la cual es una transformación que permite agregar, modificar o eliminar elementos del metamodelo base, y la composición que permite unir dos o más metamodelos. Este proceso se puede ver, en la Ilustración 2, donde se parte de los metamodelos base M1 y M2, los cuales se adaptan por medio de las operaciones A1, A2 para obtener los metamodelos adaptados M1’ y M2’. Los cuales después son compuestos por medio de C12’ para obtener el metamodelo deseado M12’.. Ilustración 2 - Proceso de adaptación y composición de metamodelos.. Debido a esto podemos ver los lenguajes de adaptación y composición de metamodelos, como una sintaxis a través de la cual se pueden expresar un conjunto de transformaciones que se deben aplicar sobre un conjunto de metamodelos iniciales para construir un nuevo metamodelo.. 2.2 Herramientas de adaptación y composición de metamodelos Hoy en día existen diversos lenguajes y herramientas que permiten realizar transformaciones sobre modelos. Entre las herramientas más conocidas se encuentra Atlas Model Weaver (AMW) [5] herramienta que permite por medio de un lenguaje conocido como ATL establecer relaciones entre conceptos de diferentes modelos, de forma que después se puedan entretejer en un nuevo modelo compuesto. Otra herramienta es Kompose [7], la cual tiene un enfoque diferente a (AMW), pues en esta las relaciones son inferidas por la herramienta gracias a las firmas, las cuales se pueden definir como un conjunto de propiedades por medio de las cuales se puede definir si.

(10) conceptos de dos modelos diferentes pueden componerse, de lo contrario simplemente son agregados al modelo resultante. Atlas Model Weaver Atlas Model Weaver (AMW) cuenta con un metamodelo llamado “Weaving Metamodel” el cual puede ser extendido por cualquier usuario. Este metamodelo describe las clases de relación que se pueden establecer entre elementos de diferentes modelos, de forma que después puedan ser utilizadas para crear un nuevo metamodelo. Durante un proyecto de composición, se crea un modelo conforme al Weaving Metamodel, en el cual se describen todas las relaciones que se desean establecer entre los diferentes metamodelos del proyecto. En la imagen 3 se presenta Weaving Metamodel, el cual en un proyecto normal de composición cuenta con dos tipos básicos de relación: Matching, que especifica las equivalencias o similitudes entre diferentes elementos y Composition, el cual define como los elementos relacionados tienen que ser compuestos.. Ilustración 3 - Metamodelo de Tejido de AMW. Los modelos que se pueden generar con esta herramienta tienen aplicación en diferentes escenarios, como lo pueden ser: 1. Comparación de modelos: permite migrar modelos conformes a diferentes versiones de un metamodelo y representar las diferencias entre dos metamodelos similares..

(11) 2. Trazabilidad: Registro de elementos del modelo fuente que fueron usados para producir un elemento del modelo objetivo. 3. Composición de modelos: Cuando diferentes personas o equipos trabajan en la creación de modelos en forma paralela y se desea unir estos modelos en uno único modelo. 4. Anotación de modelos: Adición de información extra a los modelos. 5. Interoperabilidad: Se enfoca en la representación de heterogeneidades semánticas entre modelos usados para resolver problemas similares. Muchas veces es necesario usar datos generados por una herramienta como entrada para otra. 6. Especificación de transformación: El modelo weaving actúa como especificación de las transformaciones entre los diferentes modelos al permitir describir los mapeos entre los elementos de ellos. Para componer modelos por medio de esta herramienta, lo primero que se debe hacer es crear un modelo de tejido (conforme con el metamodelo deweaving), en el cual se establezcan las relaciones entre los modelos que se desea componer. Una vez creado este modelo, se realiza una transformación de alto nivel, en la cual sus entradas y salidas son otras transformaciones, las cuales pueden ser ejecutadas realizando la composición de modelos. Kompose Kompose es otra herramienta para la composición de modelos, en la cual a diferencia de AMW donde las relaciones son instanciadas a través de elementos de modelos, en esta se usa el concepto de firma como forma de inferir las relaciones. En esta herramienta, si dos elementos tienen una firma con cierto nivel de similitud se considera que hacen “Match” y por tal razón serán fusionados en un elemento compuesto. Esta propuesta se centra en dos conceptos fundamentales, el primero es el concepto de Firma, el cual es un conjunto de propiedades sintácticas, que son atributos o asociaciones establecidas en el metamodelo de UML. El segundo concepto de la propuesta es el Matching, el cual se basa en las propiedades de la firma, y por medio de este concepto si 2 elementos tienen la misma firma se hace una fusión de las propiedades para crear un nuevo elemento. Sin embargo como durante esta fusión pueden existir conflictos se utilizan diferentes directivas para solucionarlos. El tercer concepto de esta propuesta son las directivas de composición, las cuales pueden ser usadas para modificar modelos, agregar nuevos elementos a los modelos compuestos o para sobrescribir reglas de composición por defecto, para poder producir los modelos compuestos deseados. Las directivas que modifican modelos pueden ser vistas como transformaciones en los modelos, las directivas que afectan a los modelos a componer son aplicadas antes de realizar la fusión y las que agregan elementos a los modelos compuestos así como las que sobrescriben reglas de composición, son aplicadas durante la fusión..

(12) A continuación se listan las directivas de elementos: - Creación de nuevos elementos - Adición de elementos a un espacio de nombre - Borrado de elementos de un espacio de nombre - Cambio de propiedades - Reemplazo de referencias de un elemento en un espacio de nombre - Sobreescritura de elementos - Sobreescritura de reglas de composición EnAr-Fusion EnAr-Fusion es un lenguaje de composición que permite describir por medio de un conjunto de 17 instrucciones de alto nivel, la forma como deben componerse diferentes metamodelos a fin de llegar a generar un metamodelo compuesto. Entre sus principales ventajas están la simplicidad y abstracción de alto nivel de sus operaciones y el hecho de que a diferencia de Kompose, en este si es posible establecer de forma directa las composiciones y adaptaciones que se desea realizar para llegar a construir un metamodelo compuesto. Como dentro de la propuesta de generación de editores que se presenta en este documento, se necesita un motor de composición, se ha incluido esta propuesta, a continuación en la tabla 1 presentamos las operaciones más significativas para nuestra propuesta, utilizando como ejemplo los metamodelos MM1 y MM2 ilustrados en la imagen X.. Ilustración 4 - Metamodelos Ejemplo EnAr-Fusion.

(13) La anterior figura muestra 2 metamodelos los cuales se van a componer de diferentes formas por medio de las operaciones de ArchiFusion [1].. Instrucción. DeleteEntity. RenameEntit y. NewEntity. Link. Descripción Elimina una entidad para que no aparezca en el metamodelo compuesto. Cambia el nombre de una Entidad. Crea una nueva entidad en el metamodelo compuesto. Esta entidad no tiene ni atributos ni relaciones con otros elementos, pero estos pueden ser agregados por medio de las otras operaciones de ArchiFusion. Establece una nueva relación entre 2 entidades. Entre los atributos de una relación se encuentra su identificador, la cardinalidad, si es una relación de contenencia, y la relación inversa que. Ejemplo de uso DeleteEntity exampleMM1.B En este ejemplo la entidad B no aparecerá en el metamodelo compuesto.. RenameEntity exampleMM1.D { newName = “C” } En este ejemplo la entidad original D recibe el nuevo nombre “C”. NewEntity E En este ejemplo se agrega una nueva entidad llamada “E”.. Link theB { metaEntitySource = exampleMM2.W metaEntityTarget = exampleMM1.B containment = true minCard = 1 maxCard = 1 associatedLink = theW } En este ejemplo se agrega una nueva relación llamada “theB” entre las entidades “W” y “B”. Este ejemplo asume que también se va a crear una relación inversa llamada “theW”..

(14) permite la navegación en la dirección opuesta.. MergeEntitie s. SplitEntity. Esta operación sirve para crear una nueva entidad a partir de 2 entidades existentes. La nueva entidad es una mezcla de las dos entidades anteriores y agrupa todos los atributos y relaciones que existían anteriorment e.. Crea 2 nuevas entidades a partir de una existente. Los atributos y referencias de la entidad original deben repartirse entre las entidades recién creadas.. MergeEntities { metaEntity1 exampleMM1.D metaEntity2 exampleMM2.X NewEntity DX } En este ejemplo las entidades originales D y X se mezclan para producir la nueva entidad DX.. SplitEntity exampleMM2.X { NewEntity X1 Attributes { Description AttX } References { theW } NewEntity X2 Attributes { Name } References { theZ } En este ejemplo la entidad X se divide y da origen a las entidades X1 y X2..

(15) AddSimpleAttr att2 { metaEntitySource = exampleMM1.B type = int isIntrinsic = true minCard = 0 maxCard = 1 } AddSimpleAt ribute. Agrega un atributo simple a una entidad.. En este ejemplo se le agrega el atributo “att2” a la entidad B.. Tabla 1 – Operaciones EnAr-Fusion. 2.3 Lenguajes Gráficos y Generación de Herramientas Con respecto a un lenguaje textual, un lenguaje gráfico ofrece varias ventajas como por ejemplo sermás comunicativo, conciso y de facil entendimiento para los stake holders[13][14]. El inconveniente que presentan es que requieren herramientas mucho más complicadas de desarrollar, mientras que un lenguaje textual puede ser utilizado incluso con un editor de texto plano, un lenguaje gráfico no puede ser utilizado a menos que se cuente con un editor especializado. Es por esto que en los últimos años han surgido herramientas que intentan facilitar la creación de editores e intérpretes de la misma forma que en décadas pasadas surgieron herramientas para lenguajes textuales..

(16) MetaEdit+ MetaEdit+ es una de las herramientas más avanzadas en el area de editores graficos de sintaxis específicas. Es una herramienta propietaria, y su utilidad ha sido demostrada en varias aplicaciones industriales [15]. Entre sus características más importantes es que permite por medio de diálogos, editores, lenguajes y restricciones definir de forma sencilla avanzados editores graficos para la creacion de modelos, conformes a un metamodelo definido en la propia herramienta. Adicionalmente provee un repositorio para almacenar todos los modelos y modificarlos a medida que existan cambios en el metamodelo. Sin embargo entre sus limitaciones esta, que los metamodelos deben ser modelados dentro de su lenguaje: GOPRR, razón por la cual no es compatible con ecore, o MOF ni ninguna de las herramientas desarrolladas para los mismos. Esto presenta una limitación importante pues solo se pueden utilizar las herramientas de MetaEdit, y estas están completamente enfocadas a la generación de código.. GMF Sobre la plataforma Eclipse hay también un conjunto de herramientas y librerías que permiten la descripción de representaciones gráficas y la generación de herramientas. Uno de los más usados es GMF – Graphical Modeling Framework, el cual permite crear editores gráficos para metamodelos. GMF integra dos elementos de Eclipse. Por un lado está EMF – Eclipse Modeling Framework, el framework que permite manejar modelos y metamodelos, y sobre el cual se apoyan otras herramientas que permiten trabajar con los modelos, por ejemplo usando transformaciones. Por otro lado está GEF – Graphical Editing Framework, el framework para crear editores visuales basados en grafos. Este framework ofrece facilidades tanto para manejar la representación gráfica de los elementos, como para manejar la interacción de los usuarios con los grafos. GMF surgió para integrar EMF y GEF, permitiendo así que editores basados en GEF sirvan para construir modelos conformes a metamodelos EMF. Adicionalmente, GMF provee los elementos necesarios para que la construcción de los editores sea tan automática como sea posible y para que se aprovechen al máximo las ventajas ofrecidas por EMF y GEF: mientras que el primer framework se encarga de todo lo que tiene que ver con la consistencia y la persistencia de los modelos, el segundo ofrece una altísima flexibilidad para describir las representaciones gráficas y manejar las interacciones. Para generar un editor gráfico para un nuevo lenguaje utilizando GME es necesario contar con los siguientes artefactos. En primer lugar, se debe tener el modelo EMF que describe la sintaxis abstracta del lenguaje (el metamodelo para el lenguaje). Cuando el editor esté completo, los modelos que sean construidos usándolo serán conformes a este metamodelo. Luego, es necesario contar con un conjunto de archivos que describen las características que se necesitan en el editor. El primer archivo es el GMFGraphModel donde en un modelo de figuras geometricas, labels y conectores se describe como se va a pintar ciertos nodos..

(17) El segundo archivo es el GMFToolModel y en este se describe por medio de otro modelo independiente qué botones van a existir en el editor, al igual que sus nombres, descripciones y pocisiones.Finalmente el archivo llamado GMFMapModel se encarga de describir la relacion entre elementos de diferentes modelos como lo son el modelo que describe la forma de pintar el concepto, la herramienta de creacion y el concepto. A partir de estos artefactos, el framework de GMF genera un modelo intermedio, el Map2GenModel, y finalmente genera el código Java del editor. Este último paso se basa en un conjunto de plantillas incluidas en el framework.. Ilustración 5 – Proceso de un editor gráfico con GMF. Sin embargo tal como lo presenta Kolovos et al [2], el hecho de que existan tantos artefactos para describir la representación gráfica hace que esta descripción se vuelva propensa a errores y de muy difícil administración frente al cambio, puesto que ante cualquier modificación en el metamodelo se deben revisar todos los modelos de descripción gráfica. Eugenia Para solucionar lo anterior, fue desarrollada la herramienta Eugenia [2], la cual unifica la descripción de los metamodelos con la descripción de las representaciones gráficas. Esto se logra a través de anotaciones sobre el metamodelo como forma de describir su representación gráfica. De esta forma se reduce la complejidad de crear una descripción gráfica y la dificultad de introducir cambios. Sin embargo esta propuesta tiene dos tradeoffs importantes: En primer lugar, hay menos artefactos que mantener, lo cual facilita la evolución, pero a cambio de contaminar el metamodelo con anotaciones que no tienen relación con su dominio. Por otra parte, Eugenia aumenta el nivel de abstraccion de GMF para facilitar la creación de nuevos editores; esto hace que el framework sea menos expresivo que GMF y permita una menor personalización. Eugenia está construido sobre GMF por tal razón para la generación de código requiere de los mismos modelos que GMF,.

(18) sin embargo en su caso estos se generan de forma automática por medio de un plugin que utiliza las anotaciones incluidas en el metamodelo. GenGMF Otro lenguaje de descripción gráfica existente es GenGMF el cual al igual que Eugenia, es una herramienta construida sobre GMF que similar a Eugenia busca disminuir la dificultad de describir editores gráficos. Su premisa es que en las descripciones gráficas de GMF hay muchas descripciones gráficas que a pesar de ser iguales en la mayoria de conceptos, se deben escribir muchas veces. Razón por la cual proponen incluir todos estos conceptos en un modelo llamado genGmf, de forma que para describir las representaciones gráficas de un metamodelo, solo se debe trabajar con 2 modelos adicionales. De esta manerareduce la complejidad con respecto a GMF. Sin embargo, esta herramienta, presenta los mismos problemas de GMF, puesto que al tener que administrar varios modelos para una representacion gráfica, su evolución es muy difícil..

(19) Capítulo III – Definición del Problema 3.1 Problema General El principal problema que se presenta actualmente a la hora de construir editores gráficos, es que si se utiliza GMF el hecho de que existan múltiples artefactos para describir una sola representación gráfica, hace muy difícil su administración e imposible de administrar para futuras evoluciones. Si por el contrario se utiliza el enfoque provisto por Eugenia, se liberan problemas de administración, gracias a que se reduce el número de artefactos a mantener, sin embargo a cambio de esto, se debe contaminar los metamodelos con información que no tiene nada que ver con el dominio del metamodelo. Adicionalmente en cualquiera de los 2 enfoques, no existe el concepto de reutilización de representaciones gráficas, en nuevos proyectos, por lo que se gasta más tiempo y esfuerzo en la creación de nuevos editores.. 3.2. Pregunta de Investigación. Es posible crear Representaciones gráficas del Metamodelo Compuesto a partir de las representaciones gráficas de los metamodelos existentes? Para resolver esta pregunta es necesario preguntarse por los requerimientos que se desprenden de la misma: Las representaciones gráficas de los metamodelos deben ser descritas como archivos independientes del metamodelo, de forma que puedan existir múltiples representaciones para cada metamodelo. Debe existir una herramienta capaz de recibir como entradas un metamodelo y una representación gráfica y generar como salida un editor grafico, para el metamodelo. Se debe poder describir por medio de un archivo la forma en que se deben componer las representaciones gráficas, guiadas por la composición del metamodelo. Debe existir una herramienta capaz de componer representaciones gráficas para crear una nueva..

(20) Capítulo IV–Visión Global de la Solución 4.1 Objetivos de la Propuesta La propuesta presentada en este documento, busca resolver los problemas relacionados con la definición y creación de editores gráficos a través de la modularización del problema. Concretamente se desea poder generar editores tan avanzados como sea posible para lenguajes especializados. Adicionalmente, se desea poder almacenar las definiciones de estos lenguajes y editores en depósitos de forma que puedan ser reutilizados en futuros proyectos o durante la evolución de los lenguajes. Para alcanzar este objetivo, es importante separar los concerns involucrados en la construcción de editores gráficos por diferentes usuarios con diferentes experticias. Con el fin de lograr esta separación se debe separar la definición de la sintaxis de la forma como ésta se pinta, y almacenar los 2 archivos en depósitos. Gracias a esta separación de metamodelo y representación gráfica es posible tener múltiples representaciones gráficas para un mismo metamodelo y seleccionar la más conveniente según el proyecto. Sin embargo esto también implica que en la solución debe existir una forma simple de relacionar los elementos gráficos del lenguaje (representación gráfica) con los elementos propios del lenguaje (metamodelo). Finalmente, la composición de metamodelos debe servir de guía para expresar la composición de representaciones gráficas, esto quiere decir que se debe poder seleccionar algunos lenguajes (metamodelos) y sus respectivas representaciones gráficas y por medio de operaciones de adaptación y composición llegar a un nuevo lenguaje grafico.. 4.2 El proceso genérico para la composición de representaciones gráficas Durante la siguiente sección se describe el proceso que se debe seguir para generar el editor grafico de un proyecto usando un conjunto de herramientas genéricas. Para ilustrar este proceso, se debe asumir que existe un repositorio con metamodelos para múltiples dominios y que además existen múltiples descripciones de representaciones gráficas para cada uno de estos. S1: creación del metamodelo del proyecto Durante la primera etapa del proceso (S1), el primer usuario en intervenir en el proceso es el metamodelador, cuya misión es seleccionar de un repositorio los metamodelos que mejor describen los dominios de interés para el proyecto en cuestión. Después este mismo usuario debe usar una herramienta para expresar la forma en que este desea adaptar y componer los metamodelos seleccionados con el fin de construir el metamodelo del proyecto. A continuación el metamodelador debe por medio de un motor de adaptación y composición crear el metamodelo deseado y guardarlo de nuevo en el repositorio junto con la descripción utilizada para crearlo, de forma que se pueda utilizar en futuros proyectos. Este proceso se muestra en la ilustración 6..

(21) Ilustración 6 – Creación del metamodelo del proyecto.. S2: Creación de la representación gráfica para el nuevo metamodelo En la segunda Etapa del proceso interviene un usuario diferente: el modelador grafico, cuya misión es describir como representar los conceptos y relaciones del metamodelo creado en la etapa anterior. Esto implica describir por medio de un script como desea adaptar y componer las representaciones gráficas seleccionadas para cada metamodelo inicial (antes de ser compuesto) para obtener una nueva representación gráfica que describa como pintar todos los conceptos del metamodelo compuesto. Una vez el usuario crea el script, necesita de un motor capaz de interpretar las instrucciones descritas y componer las representaciones gráficas, para obtener una nueva que se ajuste al nuevo metamodelo. Finalmente, la nueva representación gráfica y el script utilizado para crearla deben ser agregadas al repositorio de forma que puedan servir en futuros proyectos. Esta etapa se puede ver en la Ilustración 7.. Ilustración 7 – Etapa de Creación de la representación gráfica para un nuevo metamodelo. S3: Generación del Editor Grafico En la tercera etapa del proceso, después de que ya existe al menos una representación gráfica para el metamodelo del proyecto en el repositorio, entra un tercer usuario el administrador de herramientas. Su misión es producir el editor grafico del metamodelo por medio de una.

(22) herramienta capaz de producir un modelo de herramienta específico para algún framework de generación de editores gráficos. Una vez el modelo es generado, este usuario tiene la responsabilidad de afinar el modelo y generar por medio de un framework el editor deseado. Este paso se encuentra en la Ilustración 8.. Ilustración 8 – Generación del editor de Sintaxis especifica. S4: Uso del editor grafico de sintaxis específica Finalmente en la etapa 4 un usuario modelador, puede utilizar el editor antes creado para hacer modelos para el proyecto, conformes al metamodelo y con la sintaxis gráfica específica diseñada durante la segunda etapa del proceso. Esto se puede ver en la Ilustración 9.. Ilustración 9 - Resultado del proceso.

(23) CapítuloV – EnAr-Picture Durante este capítulo se describe el lenguaje utilizado para describir representaciones gráficas al igual que las herramientas utilizadas por el mismo.. 5.1 Expresando la representación gráficapor medio de EnAr-Picture En el Capitulo anterior se dijo que durante la segunda etapa del proceso (S2), el Modelador debe seleccionar unas representaciones gráficas de cada metamodelo que se compuso a fin de poder crear la nueva representación gráfica. Estas representaciones gráficas se describen por medio del lenguaje creado dentro la propuesta y conocido como EnAr-Fusion. EnAr-Fusion es un lenguaje declarativo basado en las anotaciones de Eugenia [3] el cual permite por medio de propiedades describir de forma individual la manera en que se debe representar gráficamente cada concepto de un metamodelo en particular. Una de sus principales características es que permite importar el metamodelo que representa de forma que se puede establecer una relación entre cada concepto del metamodelo y la descripción de cómo se debe pintar el concepto en particular. Para la construcción de EnAr-Picture, se asumió que el principal interés en las representaciones gráficas es describir como se deben pintar los conceptos de los metamodelos y las relaciones entre estos. Debido a esto EnAr-Picture tiene 3 elementos principales: -. Node: representa un concepto. AttLink: representa una relación entre 2 conceptos. NodeLine: representa los conceptos que por algún motivo se desean pintar como relaciones.. Para expresar de forma simple las variaciones de esos conceptos, se crearon otras entidades, las cuales se encuentran en la Ilustración10..

(24) Ilustración 10 – Metamodelo EnAr-Picture. Tipos de Nodos Aunque en general cada modelo tiene nodos, para la descripción de la representación gráfica se tomo la decisión de especializar el concepto de nodo en tres tipos diferentes de representación debido a que en los editores gráficos existen 3 formas diferentes de representar un concepto, los cuales son: -. PictureFigure: Por medio de una imagen RegularFigure:Representaciones estándar: cuadrados, cuadrados redondeados, o elipses. ComplexFigure: Representaciones Personalizadas.. Cada uno de estos conceptos especializados de Nodo, tiene un conjunto de propiedades adicionales que permiten, de una forma simple describir el label que tendrá la representación gráfica, al igual que su posición, tamaño, borde, relaciones, botón dentro del editor, color, botón del editor, y concepto que referencia. Tipos de relaciones EnAr-Picture permite describir de forma sencilla las relaciones entre conceptos, para esto proveen 3 formas diferentes de pintar dichas relaciones, las cuales se encuentran descritas a continuación en la Tabla 1..

(25) Nombre en EnArPicture. Tipo de Representación. Descripción. InterNode. Visualmente representa la referencia como un nodo que contiene al otro. Muy utilizado para describir relaciones de contenencia.. ExternalNode. Visualmente representa la relacion, como un nodo proximo al otro.. NodeLine. Representa la relacion por medio de una linea con cierta decoracion, que une a los 2 conceptos. Tabla 2 – Formas como se puede representar una relación con EnAr-Picture. De igual forma que las entidades creadas para representar nodos, los conceptos creados para representar las relaciones tienen una referencia a la referencia del metamodelo que describen. Conceptos Adicionales detrás de EnAr-Picture EnAr-Picture tiene 23 conceptos que permiten expresar diferentes variaciones alrededor de la representación gráfica, como lo son: -. Tipos de línea Color Layout Grupo de Herramienta Borde Etc.. También provee diferentes puntos de extensión que permiten incluir nuevas características a la representación gráfica. En el Anexo 1, se puede encontrar el EBNF del lenguaje..

(26) 5.2 Herramientas detrás de EnAr-Picture. Ilustración 11 – Herramientas detrás de EnAr-Picture. Como se describió de forma genérica en el capítulo 4, el lenguaje EnAr-Picture cuenta con una herramienta que permite crear descripciones gráficas y crear modelos de herramienta para que se pueda construir un editor grafico. Esta herramienta a la que llamaremos Generador de Modelos de Herramienta o GTM por sus siglas en ingles, fue desarrollada como un plugin de Eclipse [18], y cuenta con un editor de texto creado con Xtext [17], que auxilia a los usuarios encargados de describir la forma en que se deben crear las descripciones gráficas utilizando el lenguaje EnAr-Picture. Una vez existe un script de picture y un metamodelo, es posible llamar al intérprete del lenguaje el cual se encarga de interpretar la descripción gráfica y generar un modelo de herramienta, el cual en esta implementación es un proyecto de GMF, al que se le adicionan las clases java necesarias para manejar las representaciones gráficas de cada concepto del metamodelo de forma separada, un archivo SVG, para cada concepto del metamodelo (bien sean los que agrega el usuario de forma manual, o los que el interprete genera de forma automática para pintar cada concepto que sea descrito como una figura básica en Picture), y una copia del metamodelo original al cual se le agregan las anotaciones de Eugenia [3] necesarias para que el modelador de la herramienta pueda utilizar el framework de Eugenia para generar el editor final. Adicionalmente este modelo de herramienta que sirve de entrada al motor de Eugenia, incluye las librerías necesarias para que se pueda trabajar con SVG, y scripts propios de Eugenia, para que en caso que el usuario lo desee, pueda terminar de personalizar el editor..

(27) Capítulo VI – EnAr-Gromp: lenguaje de composición de representaciones gráficas 6.1 Expresando la composición de descripciones gráficas por medio de EnAr-Gromp El segundo lenguaje de la propuesta se llama EnAr-Gromp y fue creado para describir las operaciones que se pueden realizar sobre representaciones gráficas con el fin de componerlas. Las operaciones gráficas no son iguales a las operaciones de composición sobre metamodelos, debido a que en estas en vez de establecer relaciones sobre conceptos diferentes, se le debe dar significado a estas a un nivel netamente grafico. EnAr-Gromp es un lenguaje imperativo que extiende de EnAr-Picture y permite componer diferentes representaciones gráficas usando un conjunto de instrucciones simples que permiten esconder la complejidad y extensión de las representaciones gráficas, reduciendo el tiempo necesario para crear un nuevo script de EnAr-Picture. A continuación se describen todas las instrucciones que hacen parte de EnAr-Gromp. Instrucciones de import En EnAr-Gromp existen 2 instrucciones de tipo import, la primera y más importante tiene el nombre de importMM, por medio de esta se importa el metamodelo al cual va a hacer referencia la representación gráfica que se va a componer. Como es de suponer esta instrucción solo se llama una vez al inicio del script de Gromp. La segunda instrucción de tipo import que existe en EnAr-Gromp es importPicture, la cual como su nombre lo indica, se utiliza para importar una representación gráfica existente, de forma que después se pueda hacer referencia a alguna descripción existente en la misma, debido a esto esta instrucción también contiene un alias de forma que a la representación gráfica importada se le pueda asignar un sobrenombre, para ser utilizado durante las composiciones. Instrucciones sobre Nodos El segundo conjunto de operaciones disponible en EnAr-Gromp, busca operar sobre los nodos (descripción de la representación gráfica de un concepto del metamodelo), permitiendo alterar gráficamente la representación gráfica, cambiando el concepto que representa, la imagen, o alguna característica del mismo. Todas las operaciones que actúan sobre nodos, tienen ciertas características en común, como lo son que en caso que estas compongan dos representaciones gráficas existentes, automáticamente se guardan las relaciones, y demás características que no cambien de las anteriores. A continuación presentamos las diferentes operaciones que existen, presentándolas sobre una representación arbitraria de un concepto cualquiera..

(28) Join Side Order Esta operación permite unir 2 representaciones gráficas diferentes en una nueva que contenga a las 2 anteriores, de forma que una quede al lado de la otra. Es muy útil cuando en la composición del metamodelo, se unieron 2 conceptos diferentes y visualmente se desea conservar las 2 operaciones. Esta operación permite especificar no solo la unión de las dos representaciones gráficas, sino que también permite especificar el tamaño del nodo de la derecha, y la posición del mismo con respecto al otro, la cual puede ser en la esquina superior derecha, en el centro, o en la esquina inferior derecha. Como ejemplo para esta operación, supongamos que tenemos 2 representaciones gráficas, una persona y un cuadrado, y se desean componer por medio de la operación antes descrita, el resultado se encuentra en la columna derecha de la siguiente tabla. Antes. Después. Tabla 3 – Operación EnAr-GrompJoin Side Order. Join Top Order Al igual que la operación anterior, esta permite unir 2 representaciones gráficas en una nueva que contiene a las 2 anteriores. La diferencia radica en que por medio de esta, una de las representaciones queda encima de la otra. Adicionalmente al igual que con la anterior operación, por medio de esta, se puede especificar el tamaño del segundo nodo y la posición con respecto al primer nodo, de forma que este puede quedar en la esquina superior izquierda, en el centro, o en la esquina superior derecha. La siguiente tabla presenta 2 representaciones gráficas a las cuales se les aplica la operación descrita a fin de obtener el resultado de la columna de la derecha..

(29) Antes. Después. Tabla 4 – OperaciónEnAr-Gromp Join Top Order. Merge Esta operacióntambiénactúa sobre nodos, sin embargo a diferencia de las 2 anteriores, esta busca sobreponer 2 representaciones gráficas, creando una nueva que contenga a las 2 anteriores. De la misma forma que las anteriores instrucciones, esta operación también permite especificar el tamaño de la representación gráfica que va a estar incluida en el interior, sin embargo no se puede especificar la posición de la misma. Antes. Después. Tabla 5 – Operación EnAr-Gromp Merge. Or Esta Instrucción permite seleccionar una de dos representaciones gráficas Existentes para la nueva descripción compuesta. Es especialmente útil cuando un concepto existe en más de un metamodelo y se desea seleccionar solo una de las 2 representaciones para la nueva descripción gráfica. En el ejemplo presentado en la siguiente tabla se tienen 2 representaciones gráficas y se desea solo quedarse con una de estas..

(30) Antes. Después. Tabla 6 – Operación EnAr-Gromp Or. Replace Esta operación permite reemplazar dos representaciones gráficas antes existentes por una nueva definida dentro del script de Gromp. La siguiente tabla muestra gráficamente lo que implica su utilización. Antes. Después. Tabla 7 – Operación EnAr-Gromp: Replace. Create Por medio de esta operación es posible crear una nueva representación gráfica desde cero, es especialmente útil cuando dentro de la composición de metamodelos se creó un nuevo concepto para el cual no existe ninguna representación gráfica. Antes. Después. No existe. Tabla 8 – Operación EnAr-gromp: Create. Change Operación que permite cambiar alguna característica de un nodo presente en alguna de las representaciones gráficas antes importadas..

(31) Antes. Después. Tabla 9 – Operación EnAr-Gromp: Change. Split Por medio de esta operación es posible separar la representación gráfica de un concepto en múltiples, especificando cada una de estas a que concepto del metamodelo va a representar y que relaciones va a tener. Antes. Después. Tabla 10 – Operación EnAr-Gromp: Split. Instrucciones sobre relaciones Como se dijo en la sección anterior las relaciones existentes en las diferentes representaciones gráficas que existen en el metamodelo compuesto son pasadas de forma automática, sin embargo como durante la creación por medio de composición del nuevo metamodelo puede incluir nuevas relaciones, EnAr-Gromp, tiene 3 operaciones para definir de una forma sencilla la forma como se va a representar una nueva relación. De igual forma EnAr-Gromp tiene una operación que permite eliminar la representación de cualquier relación, en caso de que esta no se desee mostrar en el editor. A continuación se presentan las diferentes operaciones que se pueden realizar sobre las representaciones de las relaciones, durante la composición de descripciones gráficas. Contain Outside Position Instrucción que permite expresar que una relación se debe pintar por medio de un ExternalNode de EnAr-Picture, esta instrucción también permite especificar el tamaño que debe tener el segundo nodo, y el layout que se va a utilizar para ordenar los nodos. En la siguiente tabla se muestra el resultado de esta instrucción por medio de dos nodos a los cuales se les invoca la función en cuestión. Los círculos punteados alrededor del segundo nodo indican las posibles posiciones donde es posible colocar la representación gráfica del concepto para indicar que estos se encuentran relacionados..

(32) Antes. Después. Tabla 11 – Operaciones EnArGromp: Contain Outside Position. Contain Inside Position La segunda operación sobre relaciones, es muy parecida a la anterior, sin embargo con esta se busca declarar una relación de cierto concepto hacia otro, se debe pintar por medio de un InterNode en EnAr-Picture. Adicionalmente, al igual que con la primera operación, en esta se debe incluir el tamaño que tendrá por defecto el otro nodo y el layout que se utilizará para ordenar las relaciones. Antes. Después. Tabla 12 – Operaciones EnAr-Gromp: Contain Inside Position. ToLink Por medio de esta instrucción es posible describir que una relación se debe pintar por medio de algún tipo de línea que represente la relación entre los conceptos. Esta operación a diferencia de las anteriores no tiene Layout, pero si otras propiedades para poder describir el color, tipo y decorados de la línea que va a relacionar los conceptos. Antes. Después. Tabla 13 – Operaciones EnAr-Gromp: ToLink.

(33) UnLink Esta última operación de EnAr-Gromp, permite hacer lo contrario de las anteriores, por medio de esta es posible especificar que se desea que se elimine la representación gráfica de cierta relación entre dos conceptos. Para esto solo se debe escribir el nombre de los 2 conceptos y el de la relación que se desea eliminar. Antes. Después. Ilustración 12 - Operaciones EnAr-Gromp: UnLink. La sintaxis de EnAr-Gromp puede ser consultada en el Anexo 2.. 6.2 Relación entre las operaciones gráficas y las de composición Dentro del proceso propuesto para la creación de editores gráficos, en la primera etapa se debe usar composición de metamodelos, se tomo la decisión de utilizar EnAr-Fusion como el lenguaje y motor de composición que se usará dentro de la propuesta, debido a que es un lenguaje simple, y permite aumentar el nivel de Abstracción de la composición. A pesar de que EnAr-Gromp posee un conjunto de operaciones para la composición de representaciones gráficas, se debe tener en cuenta que estas no tienen significado en todos los casos, razón por la cual no todas las instrucciones tienen sentido en todas las composiciones y se presenta la siguiente tabla donde con base en las instrucciones principales de EnAr-fusion se presenta en que caso que instrucciones tienen sentido..

(34) 6.3 Herramientas detrás de EnAr-Gromp. Ilustración 13 - Herramientas detrás de EnAr-Gromp. Al igual que EnAr-Picture, el segundo lenguaje de nuestra propuesta cuenta con una serie de herramientas que permiten llevar a cabo la composición de imágenes. Este conjunto de herramientas, recibe el nombre de motor de composiciónGráfica o GCM por sus siglas en inglés y fue desarrollado como un plugin[18] de Eclipse. La primera de estas herramientas es el editor de texto de EnAr-Gromp, el cual fue desarrollado por medio de Xtext[17], y permite ayudar al modelador grafico a editar los archivos de Gromp. La segunda herramienta del lenguaje es el interprete de EnAr-Gromp, el cual se encarga de interpretar el Script de Gromp y crear un nuevo modelo de picture por medio de adaptación y composición de los picture anteriores. Para esto el motor de composición recibe como entradas los proyectos de picture que se desean componer y el metamodelo compuesto para el cual se desea realizar la representación gráfica, y su salida es un nuevo proyecto de picture donde se encuentra el modelo de picture compuesto (nueva representación Gráfica), los archivos svgs que se van utilizar y nuevos archivos svgs, donde se define como se deben pintar las imágenes compuestas. Para lograr esto el intérprete hace uso de un tercer proyecto, que recibe el nombre de SVG-Handler, el cual es el encargado de crear nuevos archivos svg que incluyen las imágenes compuestas para la nueva representación gráfica. Esto se puede ver en la siguiente imagen, donde se observan las entradas y salidas del motor de composición..

(35) Ilustración 14 - Entradas y Salidas del motor de Composición gráfica. La Ilustración 14, muestra las entradas y salidas del motor de composición gráfica, el cual, como se puede ver en la imagen recibe como entrada los picture que intervienen en la composición y el script de Gromp, el cual importa el metamodelo compuesto. También como se puede ver en la imagen su salida es otro proyecto picture, el cual tiene un nuevo modelo conforme con Picture y un conjunto de archivos svg.. Capítulo VII – Caso de Estudio Etapa 1 del proceso de creación de un Editor Grafico Dentro de un nuevo proyecto de arquitectura empresarial se desea analizar cierta organización desde unidades organizacionales, roles, personas, macro procesos, stakeholders y los intereses de los mismos. Razón por la cual el metaarquitecto del proyecto ha seleccionado de un repositorio de metamodelos de diferentes dominios, los siguientes metamodelos, los cual considera que mejor se adaptan a los intereses del proyecto. Metamodelo M1: Estructura organizacional Metamodelo que describe el dominio de la estructura organizacional, en este se puede ver como una organización está compuesta de unidades organizacionales, roles y personas..

(36) Ilustración 15 - - Metamodelo Estructura Organizacional.

(37) Metamodelo M2: BPA Metamodelo que describe el dominio de la cadena de valor y procesos de una organización.. Ilustración 16 – Metamodelo BPA. Metamodelo M3: Stake Holder Domain. Ilustración 17 – Metamodelo Stake Holders. Una vez el metaarquitecto del proyecto ha seleccionado los metamodelos de interés para el proyecto, su siguiente tarea consiste en adaptar y componer estos metamodelos con el fin de adaptarlos al proyecto en cuestión. A continuación se presenta el metamodelo creado con EnAr-Fusion[1], por medio de la composición y adaptación de los metamodelos antes presentados:.

(38) Ilustración 18 – Metamodelo Compuesto. Etapa 2 del proceso de creación de un Editor Grafico: Selección representaciones Gráficas. Durante la segunda etapa del proceso de creación de editores gráficos, el modelador grafico debe escoger una representación gráfica para cada uno de los modelos que el metamodelador selecciono para crear el metamodelo del proyecto por medio de la composición. A continuación presentamos las descripciones gráficas de cada metamodelo, e imágenes de como se vería cada una de estas descripciones gráficas si se utilizaran para crear un editor grafico: Metamodelo M1 Estructura organizacional: script de picture import"models/organizationalStructure2.ecore"as M1 /*this is a graphical representation for metamodel organizationalStructure2 that used * customs images for concept Rol and Person */ GraphicalRepresentation graphicalRepresentation1 { referencePackage OrganizationalStructureA /*this is the Eclass that has all the concepts to be painted*/ root Organization /*Graphical Representation for the concept Organizational Unit*/ PictureFigure OrganizationalUnitGR{ label name labelIconfalse labelPlacementinternal.

(39) width50 height70 toolName"Organizational Unit" toolDescription"A Organizational Unit is ..." imagePAth"D:/xtext1workspace/Test1Picture/data/rectRounded.svg" atts {RespondTo , belongsTo} referenceClass<- OrganizationalUnit phantomtrue toolGroup OrganizationalUnits } /* * Graphical Description of the concept Rol */ PictureFigure figureRol{ label name labelIconfalse labelPlacementinternal width50 height70 toolName"Rol" toolDescription"A rol in the organization" imagePAth"D:/xtext1workspace/Test1Picture/data/elipse.svg" atts {isAsigned} referenceClass<- Role phantomtrue toolGroup OrganizationalUnits } Color black{ red0 green0 blue0 } /*reference of a OrganizationalUnit to Other OrganizationalUnit * saying whos subordinate to whom*/ NodeLine RespondTo { sourceDecorationnone targetDecorationarrow styledash width1 reference -> respondsTo colorLine black label"respondTo" toolName"Subordinate" toolDescription"Describes to who responds" toolGroup OrganizationalUnits } /* * Graphical Representation of a relation to the Graphical Representation * of Person */ NodeLine isAsigned{ sourceDecorationnone targetDecorationarrow styledash width1.

(40) reference -> isAsigned colorLine black label"isAsigned" toolName"Subordinate" toolDescription"asdfsd fsdf sdf toolGroup OrganizationalUnits. ". } /* * Graphical Representation of a Relation to the graphicalRepresentation of Rol as a InterNode */ InterNode belongsTo { reference -> contains layout listLayout toolGroup OrganizationalUnits } /* * Graphical Representation of a Person Using an iamge */ PictureFigure FigurePerson{ label name labelIconfalse labelPlacementexternal width50 height70 toolName"Person In the Organization" toolDescription"A Person of the Organization" imagePAth"D:/xtext1workspace/Test1Picture/data/person.svg" referenceClass<- Person phantomtrue toolGroup OrganizationalUnits } //Graphical Representations of the references in the Metamodel /*existings layout in the model*/ ListLayout listLayout toolGoup OrganizationalUnits{ label"OrganizationalUnits" } }.

(41) Metamodelo M1 Estructura organizacional: editor grafico generado. Ilustración 19 – Imagen Editor de estructura Organizacional. Metamodelo M2 BPA: script de picture import"models/bpa.ecore"as M2 /*this is a graphical representation for metamodel BPA that used */ GraphicalRepresentation graphicalRepresentationBPAComplete1{ referencePackage BusinessProcessArchitecture /*this is the Eclass that has all the concepts to be painted*/ root Organization /*style:--------------------------------------------------*/ Color white{ red0 green0 blue0 } Color black{ red255.

(42) green255 blue255 } Color yellow{ red255 green255 blue0 } NodeBorder borderBlack{ width4 borderStylesolid color black } /*style:-------------------------------------------------END*/ toolGoup bpaUnits{ label"BPA-Elements" } /*existings layout in the model*/ ListLayout listLayout /*Graphical Representation for the concept Business Object*/ PictureFigure BusinessObjectGR{ label name labelIconfalse labelPlacementexternal width50 height70 toolName"Business Object" toolDescription"Business Object: artefact that..." imagePAth"D:/xtext1workspace/BPA_picture/data/BusinessObject.svg" referenceClass<- BusinessObject phantomtrue toolGroup bpaUnits } /*Graphical Representation for the concept Business Object ----END*/ /*Graphical Representation for the concept Role-----------------*/ RegularFigure RoleRepresent{ label name labelIconfalse labelPlacementinternal width50 height70 toolName" Role" toolDescription"A Role" figureRectangle border borderBlack color white referenceClass<- Role phantomtrue toolGroup bpaUnits } /*Graphical Representation for the concept Role-----------------END*/ /*GR: concept activity------------------------------*/ RegularFigure ActivityRep{ label name.

(43) labelIconfalse labelPlacementinternal width50 height70 toolName"Activity" toolDescription"An Activity" figureRectangle border borderBlack atts {assignedTo,manipulatesGR} color white referenceClass<- Activity phantomtrue toolGroup bpaUnits } NodeLine assignedTo { sourceDecorationnone targetDecorationnone stylesolid width3 reference -> assignedTo colorLine black label"assignedTo" toolName"assignedTo" toolDescription"assignedTo" toolGroup bpaUnits } NodeLine manipulatesGR { sourceDecorationnone targetDecorationarrow styledot width3 reference -> manipulates colorLine black label"manipulates" toolName"manipulates" toolDescription"manipulates some business object" toolGroup bpaUnits } /*GR: concept activity------------------------------END*/ /*GR:concept Process-------------------------------*/ RegularFigure ProcessN{ label name labelIconfalse labelPlacementinternal width50 height70 toolName" Process" toolDescription"A Process" figureRounded border borderBlack atts {subprocessGR_relation,consistOfActivities } color white referenceClass<- Process.

(44) phantomtrue toolGroup bpaUnits } NodeLine subprocessGR_relation { sourceDecorationnone targetDecorationarrow stylesolid width3 reference -> subprocess colorLine black label"subprocess" toolName"subprocess" toolDescription"subprocess of the Process" toolGroup bpaUnits } InterNode consistOfActivities { reference -> consistsOf layout listLayout toolGroup bpaUnits } /*GR:concept Process-------------------------------END*/ /*GR: MacroProcess -----------------------------------*/ RegularFigure figureMacroProcess{ label name labelIconfalse labelPlacementinternal width50 height70 toolName"Organizational Unit" toolDescription"A Organizational Unit is ..." figureRectangle border borderBlack atts {flowToN,childrenN} color yellow referenceClass<- OrganizationalUnit phantomtrue toolGroup bpaUnits } NodeLine flowToN { sourceDecorationnone targetDecorationarrow styledash width3 reference -> flowTo colorLine black label"flowTo" toolName"flowTo" toolDescription"flowTo" toolGroup bpaUnits } NodeLine childrenN { sourceDecorationarrow.

(45) targetDecorationnone stylesolid width3 reference -> children colorLine black label"children of" toolName"children of" toolDescription"children of" toolGroup bpaUnits } /*GR: MacroProcess --------------------------------END*/ /*GR: OrganizationalUnit --------------------------------*/ RegularFigure OrganizationalUnitGR { label name labelIconfalse labelPlacementinternal width50 height70 toolName"OrganizationalUnit " toolDescription"An OrganizationalUnit" figureRectangle border borderBlack atts {belongsTo , owns} color white referenceClass<- OrganizationalUnit phantomtrue toolGroup bpaUnits } NodeLine owns { sourceDecorationnone targetDecorationarrow styledash width1 reference -> owns colorLine black label"owns" toolName"owns" toolDescription"owns description" toolGroup bpaUnits } NodeLine belongsTo { sourceDecorationnone targetDecorationarrow stylesolid width1 reference -> owns colorLine black label"belongsTo" toolName"belongsTo" toolDescription"belongsTo descript" toolGroup bpaUnits } /*GR: OrganizationalUnit --------------------------------END*/.

(46) /*GR: ValueChain Link:Prymary Link --------------------------------*/ PictureFigure FigurePrimaryLink{ label name labelIconfalse labelPlacementexternal width50 height70 toolName"PrimaryLink" toolDescription"A Primary Link in the value chain" imagePAth"D:/xtext1workspace/BPA_picture/data/PrimaryLink.svg" atts {flowTo, childrenPLGR} referenceClass<- PrimaryLink phantomtrue toolGroup bpaUnits } NodeLine flowTo { sourceDecorationnone targetDecorationarrow stylesolid width3 reference -> flowTo colorLine black label"flow To" toolName"flowTo" toolDescription"flowTo: next link" toolGroup bpaUnits } InterNode childrenPLGR { reference -> children layout listLayout toolGroup bpaUnits } /*GR: ValueChain Link:Prymary Link --------------------------------END*/ /*GR: ValueChain Link:Suport Link --------------------------------*/ PictureFigure FigureSuportLink{ label name labelIconfalse labelPlacementexternal width50 height70 toolName"SuportLink" toolDescription"A Suport Link in the value chain" imagePAth"D:/xtext1workspace/BPA_picture/data/SuportLink.svg" atts {flowTo, childrenPLGR} referenceClass<- SupportLink phantomtrue toolGroup bpaUnits } /*GR: ValueChain Link:Prymary Link --------------------------------END*/ /*GR: ValueChain ------------------------------------*/ RegularFigure ValueChainGR { label name labelIconfalse.

(47) labelPlacementinternal width50 height70 toolName"ValueChain " toolDescription"The value Chain" figureRectangle border borderBlack atts {childrenValueChain } color white referenceClass<- ValueChain phantomtrue toolGroup bpaUnits } InterNode childrenValueChain { reference -> has layout listLayout toolGroup bpaUnits } /*GR: ValueChain --------------------------------END*/ }. Metamodelo M2 BPA: editor grafico generado. Ilustración 20 – Imagen Editor BPA.