Active Knowledge Modeling

The Graphical Modeling Framework (GMF) of Eclipse is a promising open source platform for building your own model editors. We’ve performed a preliminary analysis of GMF as a platform for our methodologies for model-driven applications, and this post highlights its strengths and weaknesses. We also propose directions for future development of GMF that would simplify the use of the framework and extend its capabilities for view management and model execution.

The upside of GMF is that basic functionality can be put together without programming, based on your own domain specific metamodel. Through additional mappings, different diagrams can be integrated into a coherent architecture, and graphical symbols can be customized. Open source makes it easier for software developers to extend the framework.

On the downside, the programming paradigm of Eclipse is at odds with our end user driven approach. Our direct model execution ambition seems difficult to implement inside a framework based on extensive code generation. While we emphasize queries and views for generating role and purpose specific interfaces, GMF relies more on transformation.

Overview of GMF

GMF provides a set of tools that makes it easy to utilize GEF (Graphical Editing Framework) and EMF (Eclipse Modeling Framework). It includes wizards for generating intermediary graphical, tools and mapping definitions based on an initial metamodel (EMF ecore), as well as the final runtime code. The different representations involved in this process are depicted below. 

Overview of configuration models in GMF

The starting point is the domain model, a metamodel defined using conventional object oriented concepts like classes with attributes and references to other classes. A class may specialize any number of other classes, inheriting their features. Basic code for manipulating these classes is generated directly from the domain model.

The graphical model defines the symbols used for representing the different object classes visually (as nodes), as well as labels for displaying and editing attribute values. Classes and references may also be mapped to connections (links between nodes), and some references may be defined as containment for decomposition of a node into subnodes in compartments. One class also has to represent the underlying diagram of the editor, and it needs containment references to all the classes that are to be edited. A wizard helps you generate a basic graphical model from the domain model, though custom figures and decomposition must be added manually. Graphical definitions for classes that are not leaf nodes in the specialization hierarchy are also for some reason left out of the generated model.

The tools model defines the services for creating new nodes and connectors in the model editor. A wizard helps you select which of the object classes in the domain model that you would like to make available. To customize the tools palette you may group the tools, and define your own icons.

The mapping model connects the domain, tools, and graphical models, defining which node and connector symbols are used for representing which domain model class, and which tools create new elements. If you use the GMF wizards, the basic mappings are established automatically, though you need to add decomposition rules and links between different diagrams manually. The Java code for editing diagrams is generated from the mapping model. It uses the basic code generated from the domain model.

The blue arrows in the figure above reflect the additional configuration of the model editor that the user may input at each stage. The letters refer to the aspects that are defined, according to our basic knowledge architecture language IRTV (Information, Role, Task, View). The domain model reflect the information content aspect, while the graphical and tools models represent the view aspects of model elements and tools (tasks or services), respectively. IVT in the arrow in to the mapping model reflects that the information, view and task aspects are interconnected at this stage.

The role aspect of IRTV, which we use for filtering information content and services according to the responsibilities of each user, is not covered by GMF. Additional services (the task aspect) can only be defined through programming, there is no task modeling interface where services may be composed visually from basic operations. The tools model identify services for creating new model elements, but all other kinds of tasks are implicit.

Information and Data Modeling

Let us first look at the domain modeling of GMF and EMF, its basic concepts and implementation.

Concepts

EMF follows conventional object oriented class modeling. The core concept is class, and classes may have attributes. References are similar to attributes, but point to other objects, rather than data values. Attributes and references may have multiple values, subject to cardinality constraints defined by the modeller. A strong point is the support for multiple inheritance, which caters for aspect oriented separation of concerns. Classes may be defined as abstract.

Relationships reflect dependencies between the model elements, and we regard it as the most important kind of element in a knowledge model, more so than objects. They should be treated as first class primitives, not as secondary elements owned by objects. Though the lack of a first class relationship construct is a weakness of EMF’s data modeling, the mapping between data and their visual representation of GMF is quite flexible, and you can easily create your own relationship class with two references pointing to the source and target. Such a relationship class would also be capable of being the source or target of other relationships. We were for instance able to use the same set of relationships between objects and relationships in our trial model, by introducing an abstract ancestor class common to objects and relationships.

A knowledge architecture also needs more powerful property and value modeling features than EMF supports out of the box. We’d like to define relationships between properties, to define reusable property classes independently of object classes, to specialize and compose property definitions (and not just datatype definitions). Though multi-valued attributes in EMF offer more support for this than the most constrained frameworks, we are still required to define our property concept as a class to get what we want. In general, object oriented frameworks tend to force you to define everything as a class …

We have earlier argued against class-based metamodeling, on the grounds that the separation of data and metadata is artificial from a user perspective. Instead we favor a single level instance based framework where any element can contain both data and metadata, and where both data and metadata can be inherited in the same manner. Rather than creating new elements through instantiation, which is difficult to grasp for non-programmers, we apply a simple copy mechanism. Templates are used for defining reusable and generic model elements, filling the role of classes in Eclipse. All the software code of the underlying platform should thus be defined in a metamodel agnostic manner. The current implementation of GMF makes it very difficult to handle typical evolution scenarios like an instance changing its class or becoming member of another class.

Implementation

Eclipse follows the conventional approach of data modeling in IT, where data are defined by programmers, and any change to the data model requires regeneration and rebuilding of software code. Each new modeling element class that you define, will result in new Java classes and methods being generated. Our active knowledge modeling approach aims to let end users define their own metadata dynamically, in a platform that automatically handles the updates without the need for any code generation or even a restart of the application. Would this approach be feasible in GMF, GEF, and/or EMF?

The simple and direct solution would be to regenerate code, recompile and rebuild new diagram editor classes for each metamodel update. Though this approach could be sufficient in a prototyping environment, it would not offer a useable operational solution for model driven end user applications.

An alternative approach is to define a basic set of core concepts as EMF classes, and then add custom code that implements dynamic metamodeling as a layer on top of the static EMF and Java classes. By default, GMF bindsall functionality to the EMF classes, for information storage, graphical views, and tools. The extensible type registry of GMF supports slightly more flexible typing and binding. The binding mechanisms should however be replaced with a more flexible assignment of view and controller functionality to model elements, e.g. defined by queries over property values and relationships, not just the object class.

To enable user defined metamodels with the expressiveness required for an active knowledge architecture, we’d have to write custom code for a number of features:

• Creation of nodes from templates, rather than class definitions. Given that a copy operation already exists, this should be feasible
• Creates of connections from templates may be more difficult, as a relationship copy operation is not available out of the box.
• Template management functionality that enables the users to create, apply and update the templates for their own modeling types.
• Template updates should as well change the tool palettes currently controlled by the tools model. This requires data driven user interfaces, with a refresh mechanism.
• More dynamic selection of symbols for objects and relationships, based on all the characteristics of the element, not just its class.
• More dynamic rules for containment and linking between diagrams. Ideally, any relationship could be used to define containment in one diagram, even if it is shown as a connection in another.
• More dynamic connections to behavior, allowing e.g. different types of relationships and part nodes to be created from templates.
• Custom property sheets, with extensible property sets, providing immediate editing of values even if the properties are defined as classes, and with operations for adding and removing properties.
• A repository for sharing models (and metamodels).
• Change management and deployment control for when changes made by one user is to influence the workspace of other users.

In addition to these basic services, role-based customization and access control, task, rule, and process execution, and more sophisticated view management functionality is needed. This we explore below.

View Management

View management deals with the selection and presentation of model elements in diagrams and textual views. We often find that modeling frameworks rely on a too close mapping between data and view. Although GMF uses a mapping model as insulation between data and view definitions, this functionality is still inflexible and coarse-grained.  Runtime changes are not facilitated, and all mapping is based on the classes. This means that you cannot have specific symbols for instances, or make the symbols depend on the attributes or relationships of the element. In this area, GMF could learn a lot from information visualization.

There is however some flexibility. Each model element can have multiple views, in what the GMF people call non-canonical diagrams. You could also define that a class is visualized as a connection in one view, and as a node in another. This seems to require custom programming of the creation tools, though. In other areas, the framework is rigidly constrained. There is no recursive containment, so if you want to be able to model e.g. a process hierarchy over N levels, you have to define N node mappings for the type.

In general, the selection of which nodes and connections to include in a diagram is too static. Every element included must have a direct containment reference from the object that the diagram represents. Our approach of defining views explicitly as model elements is thus mandatory in GMF. However, direct containment is just the simplest and least powerful approach to content selection. A more general approach would be to select the content of a diagram based on a query definition. Some of the queries should be context-independent, selecting content from the whole model. Other queries should start with a context, e.g. one or more selected model elements, and traverse the model structures from there. Basic containment is just the simplest of hardcoded contextual queries. This approach also allows multiple subviews for each model element, e.g. to focus on different aspects.

The final piece of the content selection puzzle is to select and filter the tools, services or tasks that are made available in different contexts of the user interface. This will be covered in the section on model execution below.

Inheritance

The lack of reuse is one of the most annoying aspects of the view definition framework of GMF. While inheritance is supported between classes in the EMF data models, it does not influence the graphical, tools, and mapping definitions, where the specifications for every class have to be defined separately. To duplicate these specifications requires quite a lot of unnecessary manual labor. Though GMF lets you provide your own templates for code generation, we haven’t found a way to customize the generation of intermediary graphical, tools, and mapping models, short of altering the GMF source code. At the same time, the code generation is quite flexible, allowing you to even remove inherited features. This corresponds to cancellation inheritance, a degree of flexibility that we need both for data and behavior modeling.

Change Management

Once you’ve made changes to the tools, graph, and/or mapping models, you face change management barriers the next time you update your domain model. While the graph and mapping models are quite easy to extend manually to cover added classes, our tools model had to be regenerated. (The tutorial shows simple editing of the tools model, creating tools for new types manually, but we were unable to make this work). Regeneration of the tools model causes problems in the mapping model, because all of its references to tools become corrupted. The mapping model refers to elements in the tools model using Xpath expressions that refer to their number in the tools list. Any change to the tools model that changes the order of the tools thus break the links from the mapping model. The way the mapping model refers to elements in the graph model and the domain model, by name, is much more robust over typical change scenarios.

While these issues with inheritance and change management are annoying in the normal use of Eclipse, they would be devastating to a future dynamic model execution platform, where far more frequent updates would have to be managed in a highly robust way.

Towards Model Execution

In addition to overcoming the limitations of GMF in the areas of information modeling and view management outlined above, a model execution platform requires

• Task modeling and execution, including task patterns such as processes, rules and other event-driven behavior,
• Role management, filtering content based on responsibilities and interests, and controlling access to information and services according to organizational constraints.

Basic tasks for creating new model elements are today represented in the tools model of GMF, but there is limited support for building applications from these component services. Packaging your own program code for custom actions into the diagram runtime is possible, but no standard vocabulary of basic actions is provided. Also, the contexts in which actions can be made available are limited. With active knowledge architecture, we derive the set of services to make available in a given usage context from the information, role, task and view aspects of the current user interface situation. This multi-dimensional approach greatly simplifies the customization of the application behavior. Rules and processes further allow composition of basic actions or services into higher level tasks.

Role models typically put a crucial finishing touch on a model driven user interface. After a set of content, presentation, and service elements have been selected based on the models of what the user is doing, the role aspect may filter out some content or services that the user should have no access to, or add more elements to support the specific concern of the role, or the personal preferences of the user. GMF offers absolutely no support for this aspect of model driven applications, yet it should influence core features like what is presented to the user where. This implies that role driven customization probably would require rewriting or extension of core components of the GMF and GEF implementation.

Workplace for Configuring Workplaces

In our previous work with the Metis/Troux model editor, we applied the IRTV framework to define a workplace for configuring workplaces, where all of the setup from domain modeling to graphical definition, tools modeling as tasks etc. could be performed in the same environment as the one used by end users. The effects of changes could be experienced without any code generation or compilation steps. By utilizing inheritance of all the four IRTV aspects, and merging these aspects together in the runtime environment, we greatly reduced the amount of configuration needed to develop custom editor functionality. As soon as the users defined a new type in their domain model, it was immediately useable, through default mechanisms specified for generic classes in the IRTV dimensions.

Above we have outlined some of the functionality that Eclipse GMF lacks in order to provide a fully model driven modeling editor, and we have pointed out some core modeling principles that GMF follows, which raise barriers against more flexible solutions. At the same time, GMF promotes a model driven approach, and it provides core features like multiple inheritance, removal of inherited features, multi-valued attributes, and flexible mapping of relationships.