FRAMEWORKS DE ARQUITECTURA SOPORTADOS BAJO UN ENFOQUE MDE:

(1)

1

FRAMEWORKS DE ARQUITECTURA

SOPORTADOS BAJO UN ENFOQUE MDE:

DESARROLLO DE VISTAS Y PUNTOS DE VISTA A PARTIR

DE UN METAMODELO.

Proyecto de Grado

Presentada al

Departamento de Ingeniería de Sistemas y Computación Por:

Mayerli Romero Díaz

Asesor: Dr. Mario Eduardo Sánchez Puccini

Universidad de los Andes. Bogotá – Colombia 14 de Enero de 2013

(2)

2

Contenido

1. Introducción……….7

2. Definiciones y estado del arte ………8

2.1. Definiciones……….……….8

2.2. Herramientas relacionadas………9

2.2.1. SAVE: Software Architecture Environment for Modeling Views……….9

2.2.2. El lenguaje ArchiFusion……….9

2.2.3. Archimate………..9

3. Descripción del problema y estrategia de solución……….……….10

4. Diseño de la solución……….12

4.1 Metamodelo del Punto de Vista……….…….13

4.2 Lenguaje mView………..13 4.2.1. Instrucciones Conjunto………..14 4.2.2. Instrucciones Relación..……….14 4.2.2.1. Instrucción addAll……….……….15 4.2.2.2. Instrucción addUnique ……….……….16 4.3 Interprete mView………18

4.4 Integración con Eclipse ……….19

4.4.1. Generación de vistas en Eclipse..………19

5. Ejemplos de validación………24

5.1 Ejemplo continentes……….………….…24

5.2 Ejemplo organización ..……….…………..29

5.3 Ejemplo procesos..……….……….33

5.4 Ejemplo transporte..……….……….38

6. Conclusiones y trabajo futuro……….……….43

7. Bibliografía……….………44

(3)

3

(4)

4

Lista de Figuras

1. Representación de la creación de vistas por parte de las herramientas actuales………11

2. Representación de la creación de vistas utilizando la solución planteada………12

3. Representación del diseño de la solución………12

4. Representación de ejemplo del script del usuario……….20

5. Representación del menú de generar las vistas………..20

6. Representación de la primera página del wizard encargado de cargar los archivos……….21

7. Ejemplo de cómo se debe cargar el metamodelo del punto de vista………..21

8. Ejemplo de cómo se debe cargar el metamodelo del modelo………...22

9. Ejemplo de cómo se debe cargar el modelo………..22

10. Representación de la segunda página del wizard encargada de establecer la ubicación del nuevo archivo……….23

11. Representación de la vista creada como un archivo XML……….…….23

12 Representación del caso de ejemplo del catálogo utilizado en las validaciones……….……24

13. Modelo del ejemplo continentes……….25

14. Metamodelo del modelo del ejemplo continentes……….25

15. Metamodelo del punto de vista del ejemplo continentes……….26

16. .Representación de la definición del punto de vista de la relación AddUnique……….26

17. Vista generada de la relación addUnique. ………26

18..Representación en la definición del punto de vista de la relación AddAll………..27

19. Vista generada de la relación addAll. ………..27

20 .Representación de la definición del punto de vista de la relación AddAl y addUnique………28

21. Vista generada de la relación addAll y addUnique………..28

22.Modelo del ejemplo organizaciones………..29

(5)

5

24. Metamodelo del punto de vista del ejemplo organizaciones……….…………30

25. Representación de la definición del punto de vista de la relación AddUnique……….30

26. Vista generada de la relación addUnique. ………30

27. Representación de la definición del punto de vista de la relación AddAll………..31

28. Vista generada de la relación addAll……….31

29. Representación de la definición del punto de vista de la relación addUnique y addAll…………..32

30. Vista de las relaciones addUnique y addAll………..32

31. Modelo del ejemplo procesos ……….33

32. Metamodelo del modelo del ejemplo procesos………..33

33. Metamodelo del punto de vista del ejemplo procesos………34

34. Representación de la definición del punto de vista de la relación AddUnique……….34

35. Vista generada de la relación addUnique………..35

36. Representación en la definición del punto de vista de la relación AddAll………..35

37. Vista generada de la relación addAll……….36

38. Representación en la definición del punto de vista de la relación addAll y dos relaciones addUnique ………..36

39. Vista de la relación addAll y dos relaciones addUnique………..37

40. Representación del caso de ejemplo del catálogo utilizado en la validación de transporte……….38

41. Modelo del ejemplo transporte………38

42. Metamodelo del modelo del ejemplo transporte………39

43. Metamodelo del Punto de Vista del ejemplo de transporte……….………..39

44. Representación de la definición del punto de vista de la relación addUnique………40

45. Vista generada de la relación addUnique………..40

46. Representación en la definición del punto de vista de la relación AddAll………..41

(6)

6

48. Representación en la definición del punto de vista de la relaciones addAll y addUnique………..42 49. Vista de la relación addAll y la relación addUnique………43 50. Ejemplo de la descripción de un punto de vista por parte de un usuario para el ejemplo organización………45 51. AST Resultado de la Figura 50. ……….46 52.Gramática escrita en xText para la creación del lenguaje ……….49

(7)

7

1. Introducción.

Una de las herramientas más usadas en el contexto de negocios es la arquitectura empresarial (AE), esta se define como un conjunto coherente de principios, métodos, y modelos que se utilizan en el diseño y la realización de la estructura organizacional de una empresa, sus procesos de negocio, sistemas de información e infraestructura [1]. La arquitectura es por lo tanto útil en la vigilancia de los elementos esenciales de la empresa, al tiempo que permite la máxima flexibilidad y adaptabilidad.

Al momento de modelar se realiza una representación de una arquitectura o un sistema. Generalmente plasmando los aspectos más importantes de este. Sin embargo, se pueden tener dificultades como por ejemplo que el modelo presente aspectos de poco interés o irrelevantes para los stakeholders o que sea difícil visualizar o clasificar los elementos característicos de un aspecto especifico.

Una vista es una representación específica de un sistema completo desde la perspectiva de varios grupos de stakeholders, dejando solamente información de interés y excluyendo la información innecesaria. Por lo cual un arquitecto desarrolla un conjunto de vistas a partir de un modelo original utilizando elementos y relaciones actuales del sistema o creando nuevos para representar y cumplir todas las expectativas requeridas por los stakeholders.

Un punto de vista agrupa un conjunto de vistas que expresan las preocupaciones e intereses de uno o varios stakeholders, para su construcción al igual que en las vistas, se utilizan elementos y relaciones ya existentes dentro del sistema modificando o extendiendo el sistema añadiendo nuevos elementos si se considera necesario.

Por ejemplo, en el caso de Arquitectura de Software un documento podría tener diferentes puntos de vista: Infraestructura, despliegue, etc., y cada una de estos puede tener diferentes diagramas o modelos que en este caso serían consideradas como las vistas.

El objetivo de este proyecto es diseñar y construir una herramienta soportada en un enfoque MDE1 (Model Driven Engineering) y con un lenguaje de dominio específico (DSL) que permita definir puntos de vista y generar vistas de modelos para una AE.

En primer lugar, se dará una definición de los conceptos importantes que se verán en el documento, luego se presentarán algunas soluciones existentes y se compararán con la solución planteada, se hará una descripción del problema y de la solución, una descripción del lenguaje de dominio especifico utilizado y de cómo se encuentra realizado el interprete para la generación de vistas, la integración con el IDE de Eclipse y finalmente unos ejemplos con los cuales se puede observar cómo funciona la herramienta.

1

(8)

8

2. Definiciones y estado del arte

Para dar una contextualización a la propuesta planteada se presentaran algunas definiciones importantes de los términos a utilizar en este documento. Además de esto, se expondrán algunas herramientas para modelar vistas y puntos de vista que realizan un trabajo similar al que se propone en este proyecto.

2.1 Definiciones

Modelo:

Un modelo es información en algo (contenida, significada) creada por alguien (transmisor) para alguien (receptor) y para algún propósito (Contexto de uso).

Este posee tres características principales: Es basado en un original, solo refleja una selección relevante del sistema y puede ser usado reemplazando al original con respecto a un propósito específico. [2]

Metamodelo:

Se entendería como un modelo del modelo, pero no un modelo del original. Describe o define un modelo y puede ser considerado (ya sea lingüísticamente u ontológicamente) como una definición de un lenguaje de dominio específico. [3]

Vista:

Es una representación de uno o más aspectos de una arquitectura que ilustra como la arquitectura se enfoca en una o más preocupaciones que tiene uno o más de sus stakeholders. Para decidir que incluir en una vista se deben tener en cuenta los siguientes detalles: alcance de lo que se desea representar, los tipos de elementos que hacen parte del sistema y como se pueden categorizar, los intereses de los stakeholders para quienes va dirigida la vista, el conocimiento técnico de los stakeholders, el alcance de las preocupaciones en la vista y el nivel de detalle de la misma. [4]

Punto de vista:

Es una colección de patrones, plantillas y convenciones para construir un tipo de vista. Este define para que stakeholders va dirigida una o varias vistas, reflejando sus preocupaciones en los puntos de vista, las directrices, principios y modelos de plantillas para la construcción de vistas. Por lo cual la definición de un puntos de vista podría incluir una o varias vistas conformes a lo establecido en el punto de vista [4]

DSL (Lenguaje de dominio específico):

Hace referencia a un lenguaje optimizado para una clase específica de problema, llamado un dominio. Este es basado en abstracciones alineadas con el dominio para cual el lenguaje se está construyendo. Los lenguajes especializados, también cuentan con una sintaxis adecuada para expresar estas abstracciones de manera concisa. En muchos casos son notaciones textuales, tablas, símbolos o gráficos que pueden ser muy útiles para realizar representaciones. [5]

(9)

9

2.2. Herramientas relacionadas

2.2.1. SAVE: Software Architecture Environment for Modeling Views

Es una herramienta desarrollada como un plug-in de Eclipse que se utiliza para modelar vistas y que puede ser utilizada para modelar arquitecturas de software basada en aproximaciones de puntos de vista ya existentes. En la herramienta cada punto de vista se modela como un lenguaje específico de dominio que aumenta la precisión formal de las vistas derivadas y permitiendo el desarrollo dirigido por modelos. [6].

Se considera que un punto de vista es el DSL y las vistas son modelos de ese lenguaje. A diferencia de la solución planteada, esta hace uso de la herramienta de modelamiento grafica GMF

2

(Graphical Modeling Framework). También se utiliza Eugenia la cual permite elevar el nivel de abstracción en GMF y EMFatic que permiten al modelador del punto de vista crear el metamodelo Ecore con información de una sintaxis concreta visual proporcionada por Eugenia.

2.2.2. El lenguaje ArchiFusion:

Este lenguaje permite diseñar puntos de vista y establecer relaciones entre conceptos de diferentes lenguajes utilizando un lenguaje de meta-modelado conocido como MEMO. [7] Para la definición de vistas y puntos de vista se definen metamodelos independientes para cada dominio de una arquitectura empresarial, en los cuales se permite la creación de nuevos conceptos y nuevas relaciones entre ellos.

Archifusion, se diferencia de la solución planteada utiliza GMF como herramienta de modelamiento grafica y así mismo permite modelar una empresa como una representación por capas integrando conceptos de negocio, aplicación y tecnología. ArchiMate proporciona otra dimensión de clasificación llamada aspectos, que representan diferentes preocupaciones empresariales que necesitan ser modeladas. A través de esta clasificación, es posible separar distintos conceptos clasificados en estructuras activas, comportamientos o estructuras pasivas dentro de cada capa. [8]

2.2.3. Archimate

Es un lenguaje que describe y permite visualizar las relaciones entre diferentes dominios de negocio. ArchiMate3 ofrece un lenguaje común para describir la construcción y operación de los

2

Graphical Modeling Framework (GMF). http://wiki.eclipse.org/GMF_Documentation_Index

(10)

10

procesos de negocio, estructuras organizacionales, los flujos de información, sistemas de TI e infraestructura técnica.

Este lenguaje permite mostrar al usuario diferentes especificaciones de vistas y puntos de vista para cada stakeholder dependiendo de lo que este requiera, estos también pueden ser sacados desde diferentes modelos planteados.

Archimate define puntos de vista de una manera muy formal y precisa. Sin embargo, a diferencia de la solución planteada no cuenta con ningún lenguaje de dominio específico para representar vistas sino con una interfaz gráfica mediante la cual el usuario puede especificar lo que requiera. Otra diferencia importante, es que no es un generador, solamente permite hacer representaciones graficas, pero no construir vistas a partir de modelos o puntos de vista existentes.

3. Descripción del problema y estrategia de

solución.

Analizar o visualizar la información mostrada por los diferentes modelos de una organización puede ser un proceso complicado cuando dichos modelos no son claros o son muy extensos. Así mismo, actualmente lo que hacen las organizaciones es tener una gran cantidad de información almacenada que les permite dar soporte y realizar sus procesos o actividades. Sin embargo, si no se encuentra organizada de manera correcta se podría mezclar causando dificultades en el momento de separarla para que represente los intereses de diferentes stakeholders.

Con la arquitectura empresarial de una organización se busca crear una diversidad de modelos y en cada uno de ellos representar la manera en la que los elementos del mismo están relacionados entre sí. Sin embargo, esta se convierte en una labor complicada cuando los modelos son grandes lo que dificulta la visualización, el análisis y el entendimiento de los mismos. Otro aspecto que normalmente no se tiene en cuenta al diseñar estos modelos a gran escala es que en ocasiones estos incluyen información irrelevante para algunos stakeholders pero de vital importancia para otros. [9]

Para dar una solución a este problema, existen herramientas como las anteriormente mencionadas en la sección 2.2 que realizan diferentes procedimientos para producir diferentes vistas. En general, lo que hacen estas herramientas es que a partir de la definición de un punto de vista sea posible calcular las vistas, sin embargo lo hacen con mucha dificultad y tienen poco éxito.

(11)

11

Figura 1. Representación de la creación de vistas por parte de las herramientas actuales.

Para solucionar este problema y tomando lo anteriormente mencionado como base, este trabajo plantea una estrategia para lograr que a partir de un modelo se puedan generar nuevos modelos más pequeños (Vistas) que incluyan únicamente la información de interés para un grupo específico de stakeholders.

Esta solución, llamada mView, incluye en primer lugar, un lenguaje de dominio específico mediante el cual el usuario puede especificar los puntos de vista que le interesen a los stakeholders. En segundo lugar, mView incluye un intérprete capaz de generar las vistas a partir de cuatro elementos:

1. El modelo, que contiene la información de la organización o una parte especifica de la

misma.

2. El metamodelo al cual es conforme el modelo y que contiene los conceptos y relaciones

pertinentes.

3. El metamodelo del punto de vista, el cual incluye solamente conceptos y relaciones que

deberían aparecer en las vistas correspondientes. Los elementos de este metamodelo deben ser un subconjunto de los elementos del metamodelo conforme al modelo.

(12)

12

Figura 2. Representación de la creación de vistas utilizando la solución planteada.

En este caso, para la definición de los modelos y metamodelos se asume que estos se encuentran soportados bajo la tecnología de EMF[10] (Eclipse Modeling Framework) y que los archivos mencionados que tiene en cuenta el intérprete para la generación de vistas tienen como extensión .ecore y que pueden también ser vistos como archivos en formato XML. También, se asume que el metamodelo del punto de vista es conforme al metamodelo del modelo y al modelo. Y así mismo, que estos dos últimos son conformes entre sí.

4. Diseño de la solución.

Para la elaboración de la herramienta se realizó el siguiente diseño:

(13)

13

En esta sección se explicará el diseño de la solución. En primer lugar se especificarán las

restricciones de los parámetros que necesita el intérprete para funcionar correctamente como lo son el metamodelo del punto de vista y la descripción del punto de vista , para la cual se realizará una explicación de cómo es la estructura y la sintaxis del lenguaje de dominio específico utilizado para su creación. También se mostraran en detalle los elementos que hacen parte del intérprete, como este funciona y como se llevó a cabo la integración de este proyecto con el IDE de Eclipse.

4.1. Metamodelo del punto de vista

El primer elemento que es importante mencionar es el metamodelo del punto de vista. Este debe estar construido a partir de las especificaciones y requerimientos de uno o varios stakeholders de acuerdo a sus intereses. A partir de este metamodelo se pueden construir modelos conformes al punto de vista definido, en este caso el modelo seria la definición del punto de vista realizada con el lenguaje de dominio especifico.

El cual debe cumplir con las siguientes restricciones.

 Se debe basar en el framework EMF y ser un archivo .ecore.

 Todos los elementos en el metamodelo del punto de vista deben existir y ser validos en el modelo y en el metamodelo del modelo. Así mismo, Las relaciones derivadas que se creen en el metamodelo del punto de vista deben corresponder y estar formadas por relaciones directas existentes en el modelo.

4.2 Lenguaje mView

La herramienta utiliza un lenguaje de dominio específico (DSL) realizado bajo el framework de xText4 y que permite modelar y definir los puntos de vista que desea obtener el usuario. Debido a que es necesario establecer los elementos de la vista y relaciones entre ellos se crearon dos tipos de instrucciones: instrucciones conjunto e instrucciones relación.

Las instrucciones conjunto se utilizan para definir conjuntos con diferentes elementos en un punto de vista y las instrucciones relación para definir las relaciones entre elementos de diferentes conjuntos. Inicialmente, el modelo del punto vista este vacío, por lo cual utilizamos este lenguaje para realizar una descripción y especificar los elementos que lo componen.

El script del usuario siempre debe iniciar con un corchete abierto seguido de una instrucción conjunto, que indica en la vista el conjunto desde el cual se inicia; Luego, se pueden tener una o varias instrucciones relación indicando el camino hacia el elemento final o hacia un elemento de un conjunto intermedio (Según sea el caso) y finalmente otra instrucción conjunto que hará referencia al conjunto al cual se desea llegar seguida de un corchete cerrado.

4

(14)

14

Todas las instrucciones definidas cuentan con una primera parte en donde se realiza la definición de los elementos de la instrucción y una segunda parte donde se especifica una expresión booleana como condición que dicha instrucción debe cumplir.

Para mostrar cómo se encuentra actualmente estructurado el lenguaje, se mostraran ejemplos de las instrucciones.

4.2.1. Instrucciones conjunto

Estas instrucciones definen los conjuntos que hacen parte de la vista y los elementos que contiene cada conjunto. Estos elementos corresponden a elementos del modelo filtrados por unas

características dadas. Las instrucciones conjunto se definen de la siguiente manera:

𝑪𝒐𝒏𝒋𝒖𝒏𝒕𝒐 𝒗𝒊𝒔𝒕𝒂 = 𝑫𝒆𝒇𝒊𝒏𝒊𝒄𝒊𝒐𝒏 𝒆𝒍𝒆𝒎𝒆𝒏𝒕𝒐𝒔 𝑪𝒐𝒏𝒅𝒊𝒄𝒊𝒐𝒏 𝒆𝒔 𝒃𝒐𝒐𝒍𝒆𝒂𝒏𝒂 𝒔 ∗ }

En este caso las convenciones de esta instrucción serian las siguientes:

v.A= Define que en el punto de vista hay un conjunto llamado A.

a:m.A= Se refiere a que los elementos correspondientes al conjunto A que se define en la vista hacen referencia a los elementos de tipo A del modelo.

a.name==”Edificio1”= Indica características de filtrado en los elementos que pertenezcan al modelo y se vayan a agregar al conjunto A de la vista que estamos haciendo. En esta parte de comparaciones se pueden realizar comparaciones a valores numéricos o a cadenas de caracteres y uniendo todas las comparaciones realizadas con símbolos (|| | &&) según el resultado que se desee obtener. También podría existir el caso en el usuario no deseara realizar comparaciones por lo cual esto se puede manejar colocando la palabra reservada null indicando que no se realizan comparaciones.

NOTA: En este caso las palabras v y m se refieren a palabras reservadas

4.2.2. Instrucciones Relación:

Estas instrucciones definen las relaciones entre dos conjuntos. Utilizando estas instrucciones se puede saber la relación directa que hay entre los conjuntos o si se desea, las relaciones intermedias por donde se pasa hasta llegar al conjunto destino.

(15)

15

Al igual que en las instrucciones conjunto, en estas relaciones se pueden realizar filtros. En este tipo de instrucciones se definieron dos tipos alternativos de relaciones AddAll y AddUnique.

4.2.2.1. Relaciones AddAll:

Este tipo de relaciones se utilizan cuando el usuario desea saber además del elemento origen, el elemento destino, los elementos por los cuales pasa durante todo el camino y las relaciones derivadas y directas entre estos elementos.

𝒏𝒐𝒎𝒃𝒓𝒆 𝒓𝒆𝒍𝒂𝒄𝒊𝒐𝒏 = 𝒂𝒅𝒅𝑨𝒍𝒍 𝑫𝒆𝒇𝒊𝒏𝒊𝒄𝒊𝒐𝒏 𝒆𝒍𝒆𝒎𝒆𝒏𝒕𝒐𝒔 < 𝑜𝑟𝑖𝑔𝑒𝑛, 𝑑𝑒𝑠𝑡𝑖𝑛𝑜, <

𝒊𝒅𝒆𝒏𝒕𝒊𝒇𝒊𝒄𝒂𝒅𝒐𝒓: 𝑹𝒆𝒍𝒂𝒄𝒊𝒐𝒏 𝒅𝒊𝒓𝒆𝒄𝒕𝒂 ∗≫

𝒊𝒅𝒆𝒏𝒕𝒊𝒇𝒊𝒄𝒂𝒅𝒐𝒓

𝒊

: 𝑫𝒆𝒇𝒊𝒏𝒊𝒄𝒊𝒐𝒏 𝒆𝒍𝒆𝒎𝒆𝒏𝒕𝒐𝒔 𝑪𝒐𝒏𝒅𝒊𝒄𝒊𝒐𝒏 𝒆𝒔 𝒃𝒐𝒐𝒍𝒆𝒂𝒏𝒂 𝒔 ∗; }

v.A.cbcc= Indica el nombre de la relación del conjunto definido en la instrucción conjunto previa a esta instrucción relación (Como se menciono anteriormente, antes de una instrucción relación debe ir una instrucción conjuto, en donde se indica el conjunto origen definido en el punto de vista desde el cual se parte). Esta seria por lo tanto una relación derivada formada concatenando las relaciones directas existentes entre el conjunto origen y el conjunto destino al cual queremos llegar.

a:v.A= Se refiere a los elementos correspondientes al conjunto A definido en la vista.

c1:m.c= Se refiere a que los elementos correspondientes al conjunto C del modelo.

<a, c, …>= Indica una tupla donde sus elementos son: origen, destino y … indica el

camino que se explicara cómo se construye a continuación.

…<id1: A.cb, id2: B.cc>= Muestra el camino correspondiente entre un conjunto

origen y un conjunto destino. La parte A.cb indica que hay una relación llamada cb desde el conjunto A al siguiente conjunto, esta parte se encuentra asociada a un indicador, en este caso id1. La parte B.cc indica que hay una relación llamada cc

(16)

16

desde el conjunto B al siguiente conjunto, esta parte se encuentra asociada al indicador id2.

Id1: [a:v.A, b:m.B] = Indica para esta relación los elementos origen y destino de

cada una de las relaciones directas establecidas. Se realiza lo mismo para el otro identificador, se ´pueden tener tantos identificadores como sea necesario.

a.name==”Edificio1”= Indica características de filtrado en los elementos de a pertenezcan al modelo y que hagan parte del camino para llegar desde un elemento origen a un elemento destino. En esta parte de comparaciones se pueden realizar comparaciones a valores numéricos o a cadenas de caracteres y uniendo todas las comparaciones realizadas con símbolos (|| | &&) según el resultado que se desee obtener. También podría existir el caso en el usuario no deseara realizar comparaciones por lo cual esto se puede manejar de dos formas: la primera igualando el valor del atributo a el mismo (i.e. a.name==a.name) o bien colocando la palabra reservada null indicando que no se realizan comparaciones.

NOTA: Las palabras v y m se refieren a palabras reservadas. En el caso mostrado se tienen solamente tres conjuntos, uno inicial, uno intermedio y otro especifico. Sin embargo, se pueden tener más conjuntos y tener diferentes relaciones entre ellos. Una restricción del lenguaje es que no se puede hacer solo una comparación booleana, se tienen que hacer por lo tanto todas o ninguna y en el caso de que el usuario no desee realizar el filtro puede como ya se observo igualarlo al mismo elemento dando como resultado todos los elementos.

4.2.2.2. Relaciones AddUnique:

Este tipo de relaciones se utilizan cuando el usuario desea saber únicamente el elemento origen, el elemento destino y las relaciones directas entre estos elementos.

v.A.cbcc= Indica el nombre de la relación del conjunto definido en la instrucción conjunto previa a esta instrucción relación (Como se menciono anteriormente, antes de una instrucción relación debe ir una instrucción conjuto, en donde se

(17)

17

indica el conjunto origen definido en el punto de vista desde el cual se parte). Esta seria por lo tanto una relación derivada formada concatenando las relaciones directas existentes entre el conjunto origen y el conjunto destino al cual queremos llegar.

a:v.A= Se refiere a los elementos correspondientes al conjunto A definido en la vista.

c:m.c = Se refiere a que los elementos correspondientes al conjunto A que se define en la vista tienen que pertenecer a un conjunto A definido en el modelo.

<a,c> = Es una tupla que indica el origen y el destino de la relación.

[d:m.B] = Indica un posible conjunto de elementos por los cuales podría pasar la relación, pero no es seguro, por tanto se definen algunas características de filtrado por si llega a pasar por este conjunto.

d.name==”Planta Infra”= Indica características de filtrado en los elementos de d pertenezcan al modelo y que posiblemente hagan parte del camino entre el origen y el destino definidos. En esta parte de comparaciones se pueden realizar comparaciones a valores numéricos o a cadenas de caracteres y uniendo todas las comparaciones realizadas con símbolos (|| | &&) según el resultado que se desee obtener. También podría existir el caso en el usuario no deseara realizar comparaciones por lo cual esto se puede manejar de dos formas: la primera igualando el valor del atributo a el mismo (i.e. a.name==a.name) o bien colocando la palabra reservada null indicando que no se realizan comparaciones.

NOTA: En este caso las palabras v y m se refieren a palabras reservadas; Es decir, en el editor, el usuario tendrá que poner estas palabras tal cual se muestra en el ejemplo, de otro modo, el editor podría dar resultados inesperados. Además de eso se deben hacer todas las comparaciones especificadas con los indicadores. Otras Advertencias importantes acerca del lenguaje:

 El usuario que despliegue el plug-in debe contar con la herramienta de xText en su eclipse para realizar un correcto funcionamiento del mView.

 Se supone que el usuario que está utilizando esta herramienta y leyendo este manual podrá hacer un uso sencillo y efectivo de esta. Aunque el plug-in muestra en algunos casos advertencia de que el usuario tuvo un error en la gramática señalando en rojo o bien sea con advertencias de wizards. Puede que si no se maneja bien la herramienta ocurran como resultado valores inesperados.

Teniendo en cuenta que la definición de este lenguaje se realizo utilizando xText, es importante resaltar en este caso que XText siempre genera un Antlr-Parser de la definición de una gramática y

(18)

18

genera de este modo un AST convirtiéndolo en el modelo semántico a procesar. Para más información favor remitirse al Anexo 1 al final del documento.

4.3 Intérprete mView

En esta sección se explica cómo fue realizado el intérprete. En primer lugar, haré un breve resumen de lo que hacen los otros paquetes y clases para tener bases para explicar y centrarme exclusivamente en lo que hace este en especifico.

Para funcionar, el interprete recibe cuatro parámetros: el modelo del punto de vista (representado como la descripción del punto de vista utilizando el lenguaje mView), el metamodelo del punto de vista, el modelo inicial y el metamodelo del modelo inicial. Estos tres últimos entran como parámetro al componente del cores Procesor; Este, lo que hace es cargar toda la información que contienen los parámetros (modelo y metamodelos) y parsearla a través de un parser XML de tal modo que se puedan poblar las estructuras de datos base para manejar los datos luego en el interprete. En este caso estas estructuras base se manejaron como objetos del tipo ArrayList. En el paquete Script Procesor podemos encontrar las clases: Script Procesor, View Creator, ViewResult, la interfaz Comparer y los diferentes tipos de clases comparer que se crearon para manejar las comparaciones que se realizan dentro de las instrucciones. Este paquete podemos considerarlo como el core central del intérprete ya que es el que realiza la lógica y permite generar la vista a partir de un algoritmo de búsqueda recursivo en un grafo.

La clase Script procesor toma la descripción del punto de vista que hizo el usuario a partir de un archivo de texto con un lenguaje de dominio especifico implementado en xText. Utilizando el parser que posee esta herramienta se puede obtiene un AST5(Abstract Syntax Tree), con esta información se procede a construir un nuevo grafo en la clase ViewResult con las diferentes instrucciones definidas en el DSL parseandolas a las estructuras de datos para finalmente ser ejecutadas usando las instrucciones del DSL implementadas en java. Esto contemplando el caso de las comparaciones definidas en la descripción del punto de vista, las cuales se realizarían utilizando las clases comparer, que se encargan de la lógica en java.

La clase View Creator se encarga de sacar la información de las estructuras de datos, además de realizar la inteligencia de procesamiento en java de la instrucción conjunto. Por otro lado tenemos la clase View Result que tiene una función similar al viewcreator pero trabaja sobre las instrucciones addAll y AddUnique. Es importante resaltar aquí que estas instrucciones pueden ser acumulativas. Es decir, todas estas instrucciones se realizan sobre un mismo grafo resultado, lo cual implica que sus respuestas pueden sobrescribirse sobre unas ya existentes (En caso de que haya una relación en común entre las dos instrucciones con diferente nombre, debido a que son instrucciones uno a uno).

5

Para más información dirigirse a la sección 4.2.Lenguaje mView donde se explica más a fondo como funciona un árbol AST.

(19)

19

Para procesarlas instrucciones relación addAll y addUnique se uso un algoritmo de búsqueda recursivo con marcas en cada nodo sobre una matriz arreglo de NxN. A continuación se describirá qué hace cada una de las clases comparer:

Comparación Relaciones: Se utiliza únicamente para la instrucción addAll y permite saber por medio de un identificador a qué lugar del camino hace referencia en caso de que le usuario las haya colocado en desorden.

Comparación Nodo: Esta clase se utiliza únicamente para la instrucción addUnique y permite saber en qué conjuntos debo o no realizar una comparación.

Comparación a otro atributo: Esta clase se utiliza para comparar el valor de un atributo con el

valor de otro atributo.

Comparación a valor: Esta clase se utiliza para comparar el valor de un atributo con un valor dado por el usuario.

Finalmente se procesan las relaciones obtenidas del árbol en la clase Script Procesor y se procede a instanciar el grafo resultado creado en el View Result, según los resultados de los procesamientos de las instrucciones. La clase Script Procesor es referida mediante un wizard, permite al usuario seleccionar los archivos necesarios para usar en el software y de este modo obtener como resultado el .XML con el grafo final. Este archivo .XML se genera actualmente por simplicidad; Sin embargo, es equivalente a un modelo EMF y posteriormente se podría transformar a este.

4.4 Integración con Eclipse

La integración con Eclipse de este proyecto se realizó mediante la implementación de wizards para que el usuario pudiera interactuar con la aplicación de una manera más amigable. El wizard implementado cuenta con dos páginas. En la primera, llamada Page Crear, el usuario puede seleccionar por medio de una ventana los archivos necesarios para que el intérprete pueda funcionar; en la segunda llamada Page Destination, el usuario puede seleccionar cual va a ser el destino de su archivo de la vista que se va a crear y le da un nombre (El archivo creado quedara con la extensión .view) y al darle click en finish el wizard llama a un método que indica si el pageflow fue terminado exitosamente. Si es así, se abre una nueva pestaña que muestra como resultado el grafo representado en XML generado por el ScriptProcesor. En el Anexo 2 se encuentra la gramática que se creó para establecer el lenguaje.

4.4.1. Generación de vistas en Eclipse.

El proceso de generación de vistas es muy sencillo para el usuario y se realizaría siguiendo la siguiente serie de pasos. A continuación se muestra la pantalla inicial que visualiza el usuario cuando utiliza el plug-in. En esta pantalla se encuentra el script donde el usuario describe el punto de vista. Esto se guarda en un archivo .mView. Para generar una vista se hace click izquierdo sobre el archivo .mView del cual se quiere generar.

(20)

20

Figura 4. Representación de ejemplo del script del usuario.

Luego de hacer click se desplegará un menú en donde podemos ver la opción en la parte inferior de generar y luego la opción de vista.

(21)

21

A continuación encontraremos una ventana que nos permitirá añadir los archivos necesarios a .mView para generar la vista. Estos archivos son 4 (Modelo, metamodelo del Modelo, metamodelo del punto de vista y la descripción del punto de vista que es la que se encuentra seleccionada actualmente).

Figura 6. Representación de la primera pagina del wizard encargado de cargar los archivos.

De esta manera, al hacer click sobre los botones correspondientes se abrirá una ventana mediante la cual podremos seleccionar la ubicación del archivo que nos interesa en cada caso.

(22)

22

Figura 8. Ejemplo de cómo se debe cargar el metamodelo del modelo.

Figura 9. Ejemplo de cómo se debe cargar el modelo.

A continuación y al darle click en Next nos aparecerá la siguiente ventana, que corresponde a la segunda página del wizard donde debemos establecer el nombre y la ubicación del archivo que deseamos crear, en este caso, la vista.

(23)

23

Figura 10. Representación de la segunda página del wizard encargada de establecer la ubicación del nuevo archivo. Finalmente y después de realizar todo el procesamiento mView muestra como resultado la vista correspondiente como un archivo XML para el usuario con las características que el específico anteriormente.

(24)

24

5. Ejemplos de validación

A continuación se muestran dos ejemplos de cómo funciona la herramienta. Debido a que pueden existir muchos casos posibles de modelos, vistas y puntos de vistas a representar. Se plantearon algunos casos en un catalogo previamente realizado, para mostrar el funcionamiento del programa la construcción de los siguientes ejemplos se basan en el siguiente caso:

Figura 12. Representación del caso de ejemplo del catálogo utilizado en las validaciones.

Inicialmente se cuenta con un metamodelo con respecto al cual se pueden realizar uno o varios modelos conformes a este. La elaboración del modelo debe ser consistente y tener elementos del tipo que se definieron en el metamodelo. Así mismo, se cuenta con un metamodelo que representa los intereses de uno o varios stakeholders en un punto de vista (este metamodelo debe ser acorde y contar con los mismos elementos del metamodelo del modelo). Como resultado del uso de la herramienta se obtiene una vista conforme al metamodelo del punto de vista con los elementos del modelo.

NOTA:

1. Si se desean crear o representar nuevas vistas del catalogo o vistas personalizadas con otros metamodelos del modelo y metamodelo del punto de vista lo único que se debe hacer es crear los nuevos .ecore y cargarlos mediante el wizard como se explica en el manual de usuario.

2. Los elementos en minúscula representan elementos de los conjuntos, según el conjunto que representen. (i.e. los elementos 𝑎𝑖 pertenecen al conjunto A del modelo).

5.1. Ejemplo continentes:

A continuación se muestran las entradas que se especificaron que recibía el programa mView. Es decir, el modelo, el metamodelo del modelo, el metamodelo del punto de vista y la descripción del punto de vista.

NOTA: En este caso las relaciones en GMF se representaron como contenencias, ya que si se hubieran representado con relaciones direccionadas entre elementos los metamodelos hubieran cambiado. Es decir, serian a los diferentes planteados en el catalogo.

(25)

25

Figura 13. Modelo del ejemplo continentes

En este caso podemos ver en el modelo los elementos que se encuentran y las relaciones que hay entre ellos; Es decir, por ejemplo continente1 tiene pais1 y pais2 y así mismo, país1 tiene ciudad1 y país2 tienen ciudad2 y ciudad3.

(26)

26

Figura 15. Metamodelo del punto de vista del ejemplo continente.

A continuación se muestra como mediante el lenguaje de dominio específico se puede realizar la descripción del punto de vista. Para este caso, se ilustrará según eso los diferentes resultados dependiendo del tipo de relación que se utilice.

Relación AddUnique:

En este caso, en el resultado de la vista se deberían mostrar únicamente el origen, el destino y la relación derivada entre ellos. El camino no importaría para este tipo de relación.

{ v.Continente={a:m.Continente|a.nombre=="continente1"} v.Continente.xy=AddUnique{[a:v.Continente, c:m.Ciudad]<a,c>| [k:m.Pais] k.nombre=="pais2"||k.nombre=="pais1";} v.Ciudad={c:m.Ciudad|c.nombre=="ciudad3"} }

Figura 16. .Representación de la definición del punto de vista de la relación AddUnique

Al generar la vista (Más información en el manual de usuario mView) esta nos da el siguiente resultado.

<Vista nombre=PVista1.ecore> <Elementos>

<Elemento id=0 Conjunto=Continente> <Atributos>

<Atributo nombre=nombre id=true>continente1</Atributo> </Atributos>

</Elemento>

<Elemento id=5 Conjunto=Ciudad> <Atributos>

<Atributo nombre=nombre id=true>ciudad3</Atributo> </Atributos>

</Elemento> </Elementos> <Relaciones>

<Relacion idElementoOrigen=0 idElementoDestino=5>xy</Relacion> </Relaciones>

</Vista>

(27)

27

RelaciónAddAll:

En este caso, en el resultado de la vista se deberían mostrar el origen, el destino, las relaciones directas y derivadas que existen entre los elementos y los elementos intermedios por los cuales paso la relación.

{

v.Continente={a:m.Continente|a.nombre=="continente1"}

v.Continente.xy=AddAll{[a:v.Continente, c1:m.Ciudad]<a,c1,<id1: Continente.x, id2: Pais.y>>| id1: [a:v.Continente, b:m.Pais] b.nombre == "pais2"; id2: [b, c:m.Ciudad] c.nombre == "ciudad3"; }

v.Ciudad={c:m.Ciudad|c.nombre=="ciudad3"} }

Figura 18. Representación en la definición del punto de vista de la relación AddAll

</Elemento>

<Elemento id=3 Conjunto=Pais> <Atributos>

<Atributo nombre=nombre id=true>pais2</Atributo> </Atributos>

</Elemento>

<Relacion idElementoOrigen=0 idElementoDestino=3>x</Relacion> <Relacion idElementoOrigen=0 idElementoDestino=5>xy</Relacion> <Relacion idElementoOrigen=3 idElementoDestino=5>y</Relacion> </Relaciones>

</Vista>

(28)

28

Relaciones combinadas:

En este caso, se realiza la combinación de reglas addAll y addUnique por lo que en el resultado de la vista debería aparecer el resultado de los elementos filtrados por la primera condición addAll y luego de ese filtro debería realizarse sobre ese mismo el filtro con la condición addUnique. Lo que daría como resultado una respuesta con la combinación de las dos relaciones.

{

v.Continente={a:m.Continente|a.nombre=="continente1"}

v.Continente.xy=AddAll{[a:v.Continente, c1:m.Ciudad]<a,c1,<id1: Continente.x, id2: Pais.y>>| id1: [a:v.Continente, b:m.Pais] b.nombre == "pais2"; id2: [b, c:m.Ciudad] c.nombre == "ciudad3"; }

v.Continente.xy=AddUnique{[a:v.Continente, c:m.Ciudad]<a,c>|[k:m.Pais] k.nombre=="pais2"||k.nombre=="pais1";}

v.Ciudad={c:m.Ciudad|c.nombre=="ciudad3"} }

Figura 20 .Representación de la definición del punto de vista de la relación AddAl y addUnique. Al generar la vista esta nos da el siguiente resultado.

</Elemento>

<Elemento id=3 Conjunto=Pais> <Atributos>

<Atributo nombre=nombre id=true>pais2</Atributo> </Atributos>

</Elemento>

</Vista>

(29)

29

5.2 Ejemplo organizaciones:

NOTA: Para este caso, el caso de ejemplo corresponde al mismo caso del catalogo mostrado para el ejemplo de continentes, visto en el inciso anterior.

Figura 22. Modelo del ejemplo organizaciones

(30)

30

Figura 24. Metamodelo del punto de vista del ejemplo organizaciones

RelaciónAddUnique:

{

v.Edificio={a:m.Edificio|a.nombre=="Edificio1" || a.nombre== "Edificio 2"||a.nombre== "Edificio 4"} v.Edificio.xy=AddUnique{[a:v.Edificio, c:m.Empleado]<a,c>|[d:m.Planta] d.nombre == "Planta Infra";} v.Empleado={c:m.Empleado|c.nombre=="Empleado1"||c.nombre=="Empleado 2"||c.nombre=="Empleado4"} }

Figura 25. Representación de la definición del punto de vista de la relación AddUnique

<Elemento id=0 Conjunto=Edificio> <Atributos>

<Atributo nombre=nombre id=true>Edificio1</Atributo> </Atributos>

</Elemento>

<Elemento id=2 Conjunto=Empleado> <Atributos>

<Atributo nombre=nombre id=true>Empleado1</Atributo> </Atributos>

<Relacion idElementoOrigen=0 idElementoDestino=2>xy</Relacion> </Relaciones>

</Vista>

(31)

31

Relación AddAll:

{

v.Edificio={a:m.Edificio|a.nombre=="Edificio1" || a.nombre== "Edificio 2"||a.nombre== "Edificio 4"} v.Edificio.xy=AddAll{[a:v.Edificio, c1:m.Empleado]<a,c1,<id1: Empleado.x, id2: Planta.y>>|

id1: [a:v.Edificio, b:m.Planta] a.nombre==a.nombre && a.nombre=="Edificio1" && b.nombre=="Planta Infra";

id2: [b, c:m.Emlpeado] c.nombre == b.nombre || b.nombre=="Planta Infra" || c.nombre == "Empleado 2" || c.nombre == "Empleado 3"; }

v.Empleado={c:m.Empleado|c.nombre=="Empleado1"||c.nombre=="Empleado 2"||c.nombre=="Empleado4"}

}

Figura 27. Representación de la definición del punto de vista de la relación AddAll Al generar la vista esta nos da el siguiente resultado.

</Elemento>

<Elemento id=1 Conjunto=Planta> <Atributos>

<Atributo nombre=nombre id=true>Planta Infra</Atributo> </Atributos>

</Elemento>

</Vista>

(32)

32

Relaciones combinadas:

En este caso, se realiza la combinación de reglas addUnique y addAll por lo que en el resultado de la vista debería aparecer el resultado de los elementos filtrados por la primera condición addUnique y luego de ese filtro debería realizarse sobre ese mismo el filtro con la condición addAll. Lo que daría como resultado una respuesta con la combinación de las dos relaciones.

{

v.Edificio={a:m.Edificio|a.nombre=="Edificio1" || a.nombre== "Edificio 2"||a.nombre== "Edificio 4"} v.Edificio.xy=AddUnique{[a:v.Edificio, c:m.Empleado]<a,c>|[d:m.Planta] d.nombre == d.nombre;} v.Edificio.xy=AddAll{[a:v.Edificio, c1:m.Empleado]<a,c1,<id1: Empleado.x, id2: Planta.y>>|

id1: [a:v.Edificio, b:m.Planta] a.nombre==a.nombre && a.nombre=="Edificio1" && b.nombre=="Planta Infra"; id2: [b, c:m.Emlpeado] c.nombre == b.nombre || b.nombre=="Planta Infra" || c.nombre == "Empleado 2" || c.nombre == "Empleado 3"; }

v.Empleado={c:m.Empleado|c.nombre=="Empleado1"||c.nombre=="Empleado 2"||c.nombre=="Empleado4"} }

Figura 29. Representación de la definición del punto de vista de la relación addUnique y addAll. Al generar la vista esta nos da el siguiente resultado.

</Elemento>

<Elemento id=1 Conjunto=Planta> <Atributos>

<Atributo nombre=nombre id=true>Planta Infra</Atributo> </Atributos>

</Elemento>

</Vista>

(33)

33

5.3 Ejemplo procesos:

NOTA: Para este caso, el metamodelo del modelo y el metamodelo del punto de vista serian los mismos que en el ejemplo de continentes, por lo cual si desea referirse a ellos los podrá encontrar en el inciso anterior.

Figura 31. Modelo del ejemplo procesos

(34)

34

Figura 33. Metamodelo del punto de vista del ejemplo procesos

Relación AddUnique:

{ v.MacroProceso={a:m.MacroProceso|a.nombre=="Macro Proceso 1"} v.MacroProceso.xy=AddUnique{[a:v.MacroProceso, c2:m.Actividad]<a,c2>|[b:m.Proceso] b.atributo1 == "Principal";} v.MacroProceso.xy=AddUnique{[a:v.MacroProceso, c3:m.Actividad]<a,c3>|[d:m.Proceso] d.atributo2 > "1";} v.Actividad={c:m.Actividad|c.atributo2=="Sistema"} }

(35)

35

<Elemento id=0 Conjunto=Macro Proceso> <Atributos>

<Atributo nombre=nombre id=true>Macro Proceso 1</Atributo> <Atributo nombre=atributo1>Grande</Atributo>

<Atributo nombre=atributo2>2</Atributo> </Atributos>

</Elemento>

<Elemento id=2 Conjunto=Actividad> <Atributos>

<Atributo nombre=nombre id=true>Actividad 2</Atributo> <Atributo nombre=atributo1>Larga</Atributo>

<Atributo nombre=atributo2>Sistema</Atributo> </Atributos>

</Elemento>

<Atributo nombre=nombre id=true>Actividad 4</Atributo> <Atributo nombre=atributo1>Mediana</Atributo> <Atributo nombre=atributo2>Sistema</Atributo> </Atributos> </Elemento> </Elementos> <Relaciones>

<Relacion idElementoOrigen=0 idElementoDestino=2>xy</Relacion> <Relacion idElementoOrigen=0 idElementoDestino=4>xy</Relacion> </Relaciones>

</Vista>

Figura 35. Vista generada de la relación addUnique

Relación AddAll:

{

v.MacroProceso={a:m.MacroProceso|a.nombre=="Macro Proceso 1"}

v.MacroProceso.xy=AddAll{[a:v.MacroProceso, c1:m.Actividad]<a,c1,<e1: MacroProceso.x, e2: Proceso.y>>| e1: [a:v.MacroProceso, b:m.Proceso] a.atributo2<b.atributo2; e2: [b, c:m.Actividad] c.atributo1 == "Larga"; }

v.Actividad={c:m.Actividad|c.atributo2=="Sistema"} }

(36)

36

</Elemento>

<Elemento id=1 Conjunto=Proceso> <Atributos>

<Atributo nombre=nombre id=true>Proceso 1</Atributo> <Atributo nombre=atributo1>Principal</Atributo> <Atributo nombre=atributo2>3</Atributo> </Atributos>

</Elemento>

<Atributo nombre=nombre id=true>Actividad 2</Atributo> <Atributo nombre=atributo1>Larga</Atributo> <Atributo nombre=atributo2>Sistema</Atributo> </Atributos> </Elemento> </Elementos> <Relaciones>

</Vista>

Figura 37. Vista generada de la relación addAll

Relaciones combinadas:

En este caso, se realiza la combinación de reglas addAll y addUnique por lo que en el resultado de la vista debería aparecer el resultado de los elementos filtrados por la primera condición addAll y luego de ese filtro debería realizarse sobre ese mismo el filtro con las condiciones addUnique. Lo que daría como resultado una respuesta con la combinación de las relaciones.

{

v.MacroProceso={a:m.MacroProceso|a.nombre=="Macro Proceso 1"}

v.MacroProceso.xy=AddAll{[a:v.MacroProceso, c1:m.Actividad]<a,c1,<e1: MacroProceso.x, e2: Proceso.y>>| e1: [a:v.MacroProceso, b:m.Proceso] a.atributo2<b.atributo2; e2: [b, c:m.Actividad] c.atributo1 == "Larga"; } v.MacroProceso.xy=AddUnique{[a:v.MacroProceso, c2:m.Actividad]<a,c2>|[b:m.Proceso] b.atributo1 == "Principal";} v.MacroProceso.xy=AddUnique{[a:v.MacroProceso, c3:m.Actividad]<a,c3>|[d:m.Proceso] d.atributo2 > "1";} v.Actividad={c:m.Actividad|c.atributo2=="Sistema"} }

Figura 38. Representación en la definición del punto de vista de la relación addAll y dos relaciones addUnique .

(37)

37

</Elemento>

<Elemento id=1 Conjunto=Proceso> <Atributos>

<Atributo nombre=nombre id=true>Proceso 1</Atributo> <Atributo nombre=atributo1>Principal</Atributo> <Atributo nombre=atributo2>3</Atributo> </Atributos>

</Elemento>

<Atributo nombre=nombre id=true>Actividad 2</Atributo> <Atributo nombre=atributo1>Larga</Atributo>

<Atributo nombre=atributo2>Sistema</Atributo> </Atributos>

</Elemento>

<Atributo nombre=nombre id=true>Actividad 4</Atributo> <Atributo nombre=atributo1>Mediana</Atributo> <Atributo nombre=atributo2>Sistema</Atributo> </Atributos> </Elemento> </Elementos> <Relaciones>

<Relacion idElementoOrigen=0 idElementoDestino=1>x</Relacion> <Relacion idElementoOrigen=0 idElementoDestino=2>xy</Relacion> <Relacion idElementoOrigen=0 idElementoDestino=4>xy</Relacion> <Relacion idElementoOrigen=1 idElementoDestino=2>y</Relacion> </Relaciones>

</Vista>

(38)

38

5.4 . Ejemplo transporte.

Para mostrar que mView es un programa flexible a cualquier representación .ecore de metamodelos. Se presentará también el siguiente caso.

Figura 40. Representación del caso de ejemplo del catalogo utilizado en la validación de transporte. A continuación se muestran las entradas que se especificaron que recibía el programa mView. Que corresponden a las mismas de los ejemplos de continentes, organizaciones y procesos.

NOTA:

1. Si se desean crear o representar nuevas vistas del catalogo o vistas personalizadas con otros metamodelos del modelo y metamodelo del punto de vista lo único que se debe hacer es crear los nuevos .ecore y cargarlos mediante el wizard como se explica en el manual de usuario.

2. Los elementos en minúscula representan elementos de los conjuntos, según el conjunto que representen. (i.e. los elementos 𝑎_𝑖 pertenecen al conjunto A del modelo).

(39)

39

Figura 42. Metamodelo del modelo del ejemplo transporte

(40)

40

Relación AddUnique:

{

v.Empresa={a:m.Empresa|a.nombre=="Empresa Transporte 1"} v.Empresa.xw=AddUnique{[a:v.Empresa, c:m.Carro]<a,c>|

[d:m.TransporteCarga] d.atributo2 == "2";[e:m.TransportePasajeros] e.atributo2 == "2";} v.Carro={c:m.Carro|c.atributo2>="2"}

}

Figura 44. Representación de la definición del punto de vista de la relación AddUnique

<Elemento id=0 Conjunto=Empresa> <Atributos>

<Atributo nombre=nombre id=true>Empresa Transporte 1</Atributo> <Atributo nombre=atributo1>3</Atributo>

<Atributo nombre=atributo2>Intl</Atributo> </Atributos>

</Elemento>

<Elemento id=2 Conjunto=Carro> <Atributos>

<Atributo nombre=nombre id=true>Carro 5</Atributo> <Atributo nombre=atributo1>Camion</Atributo> <Atributo nombre=atributo2>3</Atributo> </Atributos>

</Elemento>

<Atributo nombre=nombre id=true>Carro 4</Atributo> <Atributo nombre=atributo1>Tractomula</Atributo> <Atributo nombre=atributo2>6</Atributo> </Atributos> </Elemento> </Elementos> <Relaciones>

<Relacion idElementoOrigen=0 idElementoDestino=2>xw</Relacion> <Relacion idElementoOrigen=0 idElementoDestino=3>xw</Relacion> </Relaciones>

</Vista>

(41)

41

Relación AddAll:

{

v.Empresa={a:m.Empresa|a.nombre=="Empresa Transporte 1"} v.Empresa.yq=AddAll{[a:v.Empresa, c1:m.Carro]<a,c1,<id1: Empresa.y, id2: TransportePasajeros.q>>| id1: [a:v.Empresa, b:m.TransportePasajeros] b.atributo1=="Ligera";id2: [b, c:m.Carro] b.atributo2 == b.atributo2 ; } v.Carro={c:m.Carro|c.atributo2>="2"}

}

Figura 46. Representación en la definición del punto de vista de la relación AddAll

</Elemento>

<Elemento id=6 Conjunto=TransportePasajeros> <Atributos>

<Atributo nombre=nombre id=true>Transporte Pasajeros 1</Atributo> <Atributo nombre=atributo1>Ligera</Atributo>

</Elemento>

<Atributo nombre=nombre id=true>Carro 2</Atributo> <Atributo nombre=atributo1>Bus</Atributo> <Atributo nombre=atributo2>2</Atributo> </Atributos> </Elemento> </Elementos> <Relaciones>

<Relacion idElementoOrigen=0 idElementoDestino=6>y</Relacion> <Relacion idElementoOrigen=0 idElementoDestino=7>yq</Relacion> <Relacion idElementoOrigen=6 idElementoDestino=7>q</Relacion> </Relaciones>

</Vista>

(42)

42

Relaciones combinadas:

En este caso, se realiza la combinación de reglas addAll y addUnique por lo que en el resultado de la vista debería aparecer el resultado de los elementos filtrados por la primera condición addAlly luego de ese filtro debería realizarse sobre ese mismo el filtro con la condición addUnique. Lo que daría como resultado una respuesta con la combinación de las dos relaciones.

{

v.Empresa={a:m.Empresa|a.nombre=="Empresa Transporte 1"} v.Empresa.yq=AddAll{[a:v.Empresa, c1:m.Carro]<a,c1,<id1: Empresa.y, id2:

TransportePasajeros.q>>| id1: [a:v.Empresa, b:m.TransportePasajeros] b.atributo1=="Ligera"; id2: [b, c:m.Carro] b.atributo2 == b.atributo2 ; }

v.Empresa.xw=AddUnique{[a:v.Empresa, c:m.Carro]<a,c>|[d:m.TransporteCarga] d.atributo2 == "2";[e:m.TransportePasajeros] e.atributo2 == "2";}

v.Carro={c:m.Carro|c.atributo2>="2"} }

Figura 48. Representación en la definición del punto de vista de la relaciónes addAll y addUnique.

</Elemento>

<Atributo nombre=nombre id=true>Carro 5</Atributo> <Atributo nombre=atributo1>Camion</Atributo> <Atributo nombre=atributo2>3</Atributo> </Atributos>

</Elemento>

<Atributo nombre=nombre id=true>Carro 4</Atributo> <Atributo nombre=atributo1>Tractomula</Atributo> <Atributo nombre=atributo2>6</Atributo>

</Atributos> </Elemento>

<Elemento id=6 Conjunto=TransportePasajeros> <Atributos>

<Atributo nombre=nombre id=true>Transporte Pasajeros 1</Atributo> <Atributo nombre=atributo1>Ligera</Atributo>