Herramientas de modelado vs herramientas de meta modelado

4.1 Herramientas de modelado vs. herramientas de meta- modelado

La mayoría de las herramientas de modelado que se utilizan actual- mente, tanto las herramientas que soportan al lenguaje UML (por ejem- plo ArgoUML [ArgoUML] y Rational Modeler [Rational Modeler]) como las herramientas que brindan soporte a otros lenguajes de modelado (por ejemplo diagramas de entidad relación [ER]), están basadas en una arquitectura de dos niveles (figura 4-1): los modelos son almace- nados en archivos o en un repositorio cuyo esquema está programado y compilado dentro de la herramienta. Esto determina la clase de mo- delos que se pueden hacer y la manera en que se procesan y no pue- de ser modificado. Solamente la empresa proveedora de la herramienta puede modificar el lenguaje de modelado, ya que está definido en el código.

La tecnología basada en metamodelos elimina esta limitación y permite lenguajes de modelado flexibles. Esto se lleva a cabo adoptando la ar- quitectura de capas definida por el OMG que describimos en el capítulo anterior, lo cual agrega un nivel sobre el nivel de los lenguajes de mode- lado, como se ve en la figura 4-1. El nivel más bajo, el nivel del modelo, es similar al de las herramientas de modelado. El nivel intermedio con- tiene el modelo del lenguaje, es decir, el metamodelo. A diferencia de las demás herramientas, una herramienta basada en metamodelo permite al usuario acceder y modificar las especificaciones del lenguaje. Esto es posible ya que se tiene un nivel superior (correspondiente a M3 en la arquitectura del OMG) que incluye al lenguaje de metamodelado para especificar lenguajes de modelado. Este nivel es la parte fija de la herra- mienta. Actualmente la mayoría de las herramientas utilizan alguna va- riante de MOF como lenguaje de metamodelado en su capa superior.

Figura 4-1. Herramientas de modelado en la Arquitectura 4 capas

4.2 ¿Qué debe proveer una herramienta de soporte al metamodelado?

Antes de mostrar las herramientas para dar soporte a un lenguaje de modelado es útil discutir la funcionalidad necesaria que deben proveer: - Para poder definir un nuevo lenguaje de modelado, es necesario que la herramienta nos permita especificar la sintaxis abstracta del len- guaje, es decir que nos permita definir su metamodelo indicando cuá-

les son los elementos del lenguaje y sus relaciones, así como tam- bién las propiedades para cada elemento.

- Generalmente, cuando se define un nuevo lenguaje también se defi- nen restricciones que se deben verificar para que las instancias de este nuevo lenguaje estén correctamente formadas. Por lo tanto, es preciso que la herramienta permita especificar reglas básicas, como por ejemplo, que objetos se pueden conectar a través de cuál relación. - Para que este lenguaje sea más amigable al usuario, sería deseable que se pudiera instanciar de manera gráfica. Para esto, debe permitir- se que en su definición sea posible especificar símbolos gráficos para los elementos, de manera gráfica, declarativa o en código.

- Debe ofrecer al menos la funcionalidad básica esperada de cualquier herramienta de edición. Estas funciones incluyen almacenar y recupe- rar un modelo del disco, deshacer y rehacer de muchos niveles, cortar, copiar, pegar, borrar. También deberían permitir manipular directamente los elementos a editar, imprimir y exportar en varios formatos, distribuir los elementos en el diagrama de manera automática, visualizar en distinta escala (zoom).

- En algunas herramientas se requiere que el metamodelador especifi- que los iconos, el tipo de paleta y a veces los menús en forma manual. Incluso en algunas herramientas se pedía al metamodelador que cree iconos de diferentes tamaños para diferentes usos, plataformas o con- figuraciones de la pantalla. Para incrementa la productividad del metamodelador es necesario automatizar estas tareas, por ejemplo brindarle la posibilidad de que un icono escale automáticamente a una variedad de tamaños. Generar todos estos elementos automáticamente asegura que todas las partes de la herramienta de modelado perma- nezcan sincronizadas con la definición del lenguaje de modelado. Por lo tanto, sería deseable que la herramienta proveyera una definición automática de los iconos, la paleta, los menús y los diálogos.

- Actualmente la probabilidad de trabajar con una sola herramienta en el desarrollo de un software es baja. Por lo tanto debe ser posible el intercambio de metamodelos y modelos, es decir la importación y exportación de modelos y metamodelos para el intercambio de infor- mación entre otras instancias de la herramienta y de otras herra- mientas.

- Es muy común que a medida que se use un lenguaje se noten defi- ciencias que hacen necesario cambiar su definición. Por lo tanto, es muy útil que la herramienta permita modificar los metamodelos cuando existen instancias de estos, actualizando sus instancias automáticamente. Esto permite que el metamodelador trabaje para perfeccionar la definición de su metamodelo, mientras construye el

lenguaje, y que aún antes de haber terminado los modeladores ya puedan utilizarlo.

Lo más importante, es que estas herramientas reducen el trabajo reque- rido para desarrollar una herramienta que soporte un nuevo lenguaje de modelado. La tarea es actualmente mucho más sencilla. Simplemente hay que definir la sintaxis del lenguaje y a partir de ella, la herramienta generará automáticamente el editor para crear instancias de ese len- guaje, sin que se tenga que escribir ni una sola línea de código. Como mencionamos anteriormente, las herramientas de modelado ba- sadas en metamodelo han adoptado una arquitectura de 4 capas, sin embargo no todas ellas han aceptado al lenguaje MOF como el estándar para metamodelado y en lugar de ello utilizan sus propias notaciones. Esto origina diferencias difíciles de conciliar entre las propuestas actua- les dificultando la interoperabilidad entre los modelos creados utilizando distintas herramientas.

En las siguientes secciones describiremos tres de los principales enfo- ques: la propuesta de Eclipse que adopta una versión simplificada de MOF llamada Ecore, la propuesta de Metacase que usa un lenguaje de metamodelado llamado GOPPRR y finalmente la propuesta de Microsoft a través de sus DSL Tools.