MOFLON History

In the seventies and eighties, graph grammars were an area of pure theory, experiment and beauty. Considering the available computation power in these days, one could only dream of being able to generate serious programs from visual specifications, that would be easy to understand and much more expressive than textual programming languages (cf. [Nag79]). However, as software systems became increasingly complex, developers needed better tool support in order to increase their productivity. During the eighties and early nineties, this led to different approaches in the area of integrated software development environments, which allowed developers to create, understand, analyse and edit software more easily than before (cf. [ES89]). At the RWTH Aachen¹, it was recognized that many software engineering problems could be described formally by means of graph theory. So graph grammars turned out to be able to provide elegant solutions to a number of these problems, which were realized in the IPSEN project [Nag96].

PROGRES was the first fully implemented environment to allow programming through graph transformations and was developed in the setting of the IPSEN project. The language syntax and semantics have been formally defined in [Sch91] and a corresponding syntax-directed editor and analyzer have been implemented. As there did not yet exist a standard modeling language, a proprietary notation had to be invented. Later on, an interpreter and compiler were added which allowed to execute PROGRES specifications [Zue96]. During the years, a huge amount of research was performed by the PROGRES group, and many additional concepts have been incorporated into its implementation, including a special purpose graph database called GRAS [KSW95], rule application strategies including backtracking, an OCL-like path expression language, a module concept based on an improved UML 1.1 package concept [Win00], parametric polymorphism, an incremental constraint checker with repair actions [Mue03], etc. During this time, triple graph grammars have been invented as a declarative means to describe consistency between two related models [Sch94], though they never made it into the PROGRES implementation².

From a scientific point of view, PROGRES was a huge achievement and contributed a lot to the graph grammar community (cf. [Roz97, EEK99]). However, it has become more and more difficult to maintain. Lacking a widely known, standardized modeling language, it has been designed following the Programming-in-the-Large paradigm described in [Nag90]. It is written in Modula-2³, which was a well-designed, modern programming language when the PROGRES project started, but meanwhile has been displaced by more popular languages like C++ and Java. It only runs on a limited set of Sun Solaris and Linux operation systems. Besides the underlying database is a limiting factor with respect to the size of specification in terms of performance⁴. Consequently, it is difficult to "sell" the tool to potential users in industry and even more to attract skilled students to work on the project.

This insight led to the development of FUJABA [Zue01]. It is a completely redesigned graph transformation environment based on Java and UML (Unified Modeling Language). Java was and still is one of the most popular programming languages with many skilled programmers available. UML has become the industry standard language for designing software systems. The aim of this project was to adopt modern, standardized technologies and restrict the environment to the essentials in order to gain simplicity and performance and convince practitioners that graph transformations are a powerful, useful and versatile means to deal with (software) engineering problems. The current stable Release 4.3 features fast in-memory instance graphs, a simplified graph transformation language called SDM (Story Driven Modeling) and Java code generation. SDM is based on a customized UML 1.4-like metamodel, which uses class diagrams as schema language, collaboration diagrams to define atomic graph transformations and activity diagrams to combine these to determine their control flow in larger transactions. Besides, the metamodel incorparates many artifacts of the Java programming language and additionally project information.

Compared to PROGRES, FUJABA abandons syntax-directed editing, backtracking, path expressions⁵, a module concept⁶ and constraint checking. With respect to the latter, it should be mentioned that the Object Constraint Language (OCL) had already been defined on top of UML 1.x, but has not been supported by Fujaba. Nevertheless, FUJABA became very popular and grew a considerable community of research groups that use FUJABA and contribute to it. Since 2003, the community meets regularly during the annual FUJABA Days and twice a year during the FUJABA Developer Days. As a technical consequence, Fujaba has been provided with a plugin mechanism since Release 4.0, which allows contributors to extend FUJABA with individual features based on the fixed core meta model. Starting from Release 5.0, plugins may introduce their own meta models, as long as they are mapped to the newly defined interface required by the graph transformation engine. In the long run, FUJABA will probably evolve towards a feature for the widely adopted Eclipse platform.

Meanwhile, the industrial standardization efforts have continued and resulted in a number of new standards and modeling concepts not yet covered by the approaches described before: UML 1.x used to be defined by itself as a monolithic specification. Later on, it was suggested to separate modeling languages (like UML) to model systems and metamodeling languages to model modeling languages. Therefore, a new language called MOF (Meta Object Facility) has been introduced to specify UML 1.x. In the setting of the NetBeans project, SUN as the provider of the widely-used Java language introduced a standard mapping of MOF 1.4 to Java code called JMI (Java Metadata Interface). The upcoming Model Driven Architecture^® (MDA^®) initiative also resulted in another language to specify not only static models, but also model analysis, transformation and integration: QVT (Query View Transformation).

The UML 2.0 Superstructure specification has been defined in MOF 2.0 by means of an intricate hierarchy of subspecifications. Thereby, recently introduced association and package refinement features are heavily used. They allow to define a family of models in a modular way and to reuse common subspecifications in different models. For instance, both the UML 2.0 Superstructure and the MOF 2.0 (Meta Object Facility) specification are built upon the UML 2.0 Infrastructure Specification. However there still is no official mapping of MOF 2.0 to Java, though it is quite different from MOF 1.4 and has to deal not only with the new association and package refinement features mentioned before, but also has to support a completely revised association concept introduced in UML 2.0.

Obviously, someone had to investigate the impact of these developments on graph transformations. This was the starting point of the MOFLON project in late 2002. The vision was to create a meta modeling and graph transformation environment, which would be as close to the MOF 2.0, JMI, OCL 2.0 and QVT standards as possible and at the same time would integrate state-of-the-art graph transformation techniques in a consistent way [AKRS03]. On the one hand, the goal was to evaluate the correctness, completeness and usefulness of the new UML 2.0 specification and its implications on graph transformations, on the other hand MOFLON should provide a complete toolset to create reusable specifications to build domain-specific CASE tools for the purpose of model analysis, transformation and integration.

However, this vision was quite ambitious for a small and young research group like us. Building the whole prototype from scratch would have been plain crazy and probably not brought us where we are today. Fortunately, there has been some preparatory work in place: In the context of the MOMoC project during the years before, some work had already been performed to generate not only JMI interfaces, but complete in-memory repositories from MOF 1.4 models [Bic04]. The DresdenOCL project had produced an analyzer and code generator for OCL 1.x and was ready to migrate it to the latest OCL 2.0 standard. Finally, FUJABA provided a Java-based graph transformation engine for UML specifications and a plugin mechanism to extend it. Consequently, we decided to build MOFLON on top of FUJABA⁷. A feasibility study showed that it was possible to modify the Fujaba core so that graph transformations would work with a MOF 2.0 graph schema [Roe04]. The proof of concept has been released as MOFLON 0.9 on top of a modified version of Fujaba 4.

The following work packages had to be performed to create MOFLON on top of these prerequisites:

MOFLON has been presented to the public on the ECMDA 2006 conference [AKRS06] and the GRABATS 2006 workshop [AR06]. MOFLON 1.0 has been released in December 2006 and provides nearly complete MOF 2.0 support for the official Fujaba 5.0 release.