Eclipse Magazin: Ed, du bist der Leiter des Eclipse Modeling Framework (EMF) und des Eclipse Modeling Projekts. Was genau ist Deine Rolle in diesem Kontext und was ist der Unterschied zwischen den beiden Projekten?
Ed Merks: Das Eclipse Modeling Framework ist ein Unterprojekt des Eclipse Modeling Toplevel-Projekts. EMF wird seit 2002 bei Eclipse gehosted und war vorher Teil des Toplevel-Projekts Tools. Ich war von Anfang an der technische Leiter von EMF. In dieser Rolle bin ich ein Committer und habe z.B. Zugriff auf das CVS-Repository, um für EMF Änderungen vorzunehmen. Außerdem habe ich den Überblick über die Aktivitäten aller anderen EMF-Committer.
EMF wird von einer großen und weiterhin wachsenden Zahl anderer Projekte bei Eclipse genutzt, beispielsweise von XML Schema Definition (XSD), von Unified Modeling Language (UML) und von dem Web Tools Project (WTP). Deshalb ist es wichtig, sich auf Qualität und Stabilität zu konzentrieren, wenn wir an Erweiterungen arbeiten, die EMF noch flexibler und effizienter machen sollen. Im Laufe der Zeit entstanden verwandte Projekte wie das Graphic Modeling Framework (GMF) und das Generative-Modeling-Tools- (GMT-)Projekt, und es wurde schnell klar, dass ein übergeordnetes Toplevel-Modeling-Projekt wichtig sein würde, um all diese verwandten Unterprojekte überblicken zu können. Rich Gronback von Borland und ich, damals bei IBM beschäftigt, wurden die Co-Leiter (PMC – Project Management Committe) des neuen Dachprojekts. Man kann sich das Modeling-Projekt als Zwiebel mit vielen Schalen vorstellen, wobei EMF das Kernstück bildet.
In der Rolle des PMC-Leiters nahmen Rich und ich am Eclipse Architecture Council und dem Eclipse Planning Council teil. Wir veranstalteten monatlich offene Treffen mit anderen Modeling-Projektleitern, um Themen zu diskutieren, die alle unsere Projekte betrafen, und um verschiedene Arbeiten des Projektmanagements durchzuführen. Die Rolle des EMF-Leiters ist vorwiegend eine technische Rolle, während die des PMC-Leiters vorwiegend das Management betrifft. Ich bin außerdem gewählter Committer Representative im Eclipse Board of Directors und habe als solcher Einfluss auf viele Aktivitäten bei Eclipse, angefangen bei den technischen Details von EMF bis hin zu den großen Richtungsentscheidungen der Eclipse Foundation. Es ist wirklich spannend, bei Eclipse zu sein, und ich finde es toll, dass ich hier als Einzelperson all diese Rollen innehaben kann. Auch als ich IBM nach 16 Jahren verlassen habe und begann, eng mit den innovativen Leuten bei itemis zusammenzuarbeiten, hat sich an meiner Rolle bei Eclipse nichts geändert.
Eclipse Magazin: Du hast das jetzt schon eine sehr lange Zeit gemacht und mit jedem Jahr ist EMF noch erfolgreicher geworden. Was denkst du, ist EMFs Schlüssel zum Erfolg?
Ed Merks: EMF begann intern bei IBM als Implementierung der von der Object Management Group (OMG) entwickelten Meta-Object-Facility- (MOF-)Spezifikation. EMF sollte in IBM-Projekten genutzt werden um sicherzustellen, dass eine große Zahl von geografisch verstreuten Teams eine integrierte und geschlossene Sammlung von miteinander verknüpften Modellen entwickeln würde. Natürlich war es ein langer Weg bis dorthin, denn das MOF-Modell war sehr groß und komplex und die Code Generation Patterns sollten generierten und handgeschriebenen Code sauber auseinanderhalten. Sie erzeugten deshalb riesige Mengen an kompliziertem Code, der völlig anders aussah als das, was jemand mit einem sauberen, handgeschriebenen Design produzieren würde. EMF wurde also im Großen und Ganzen als komplex, aufgeblasen und schwerfällig wahrgenommen, sodass die Kunden immer unglücklicher damit wurden.
Frank Budinsky und ich wurden damit beauftragt, klaren Tisch zu machen. Wir haben das MOF-Meta-Modell, d.h. Ecore, drastisch vereinfacht und haben die Runtime mit einem geradezu manischen Fokus auf Einfachheit und Performance neu geschrieben. Auch die Generator Patterns haben wir überarbeitet, um einfachen, sauberen Code zu erhalten, der Merging unterstützt, damit die Kunden bedenkenlos generierten und handgeschriebenen Code mischen konnten. Unsere Ecore-Vereinfachungen führten letztlich zu einer Aufspaltung von MOF in Essential MOF (EMOF) und Complete MOF (CMOF). Ecore ist tatsächlich isomorph zu EMOF, sodass wir Standard-EMOF-Serialisierungen schreiben und lesen können. Der Runtime Jar Footprint wurde um zwei Drittel reduziert, und die Performance des generierten Codes war wohl optimal.
Beispielsweise ist die reflektive Suche nach dem Wert eines Objekt-Features schneller als eine Hash-Map-Suche. All das zeigt uns, dass Flexibilität, Qualität und Performance die entscheidenden Ausgangspunkte auf dem Weg zum Erfolg sind. Die Arbeit an EMF im Kontext einer überwiegend negativen Wahrnehmung zu beginnen, die ja teilweise auch gerechtfertigt war, hat die Sache natürlich zu einer noch größeren Herausforderung werden lassen. Menschen ändern ihre Wahrnehmung nicht so schnell, nicht einmal, wenn sich vor ihren Augen drastische Veränderungen abspielen. Es ist einfach, einen guten Ruf zu ruinieren, aber sehr schwierig, ihn wieder herzustellen. Wenn man eine Basisinfrastruktur bereitstellt, wird man auch sehr schnell zum Sündenbock für schlechte Designs gemacht, die auf der Infrastruktur aufbauen. Beispielsweise wird ein Design mit Listen, die eine Million Elemente enthalten, keine gute Performance aufweisen, egal ob man EMF benutzt oder nicht.
Leider ist es so, dass es bezüglich Modeling im Allgemeinen viele Missverständnisse gibt. Es hat viele Jahre gedauert, mehr Leute von den Vorteilen zu überzeugen, und es scheint so, als würde diese Aufgabe niemals enden. Die zurückliegenden Herausforderungen bewältigt zu haben, hat mich auf jeden Fall stärker gemacht: Probleme werden einfach aus dem Weg geräumt. Mit anderen Worten: Stößt man auf ein Hindernis, ist es wichtig, Entschlossenheit zu zeigen, will man auf dem Weg des Erfolgs bleiben. Vielleicht ist das Hindernis sogar nötig für den Erfolg. Zeige den Leuten, die behaupten, etwas ließe sich nicht machen, dass es doch geht. Eigentlich sagen sie nur, dass sie nicht wissen, wie sie etwas machen sollen – also musst du es ihnen zeigen.
Und zu guter Letzt: Unterschätze niemals die Kraft deiner Community! Höre den Leuten gut zu und lerne von ihnen – dein Erfolg ist eng mit dem ihrigen verbunden. Höre aufmerksam ihren Problemen zu und nutze ihre kollektive Stimme als Leitfaden für deine Bemühungen. Vergiss aber trotz allem nicht, dass du die Community leitest und nicht umgekehrt – es bringt nichts, sich mit jeder Kleinigkeit zu beschäftigen. Zeige Entschlossenheit durch deine Taten. Mache es zur obersten Priorität, Bugs schnell zu beheben. Die Art, wie du deine Kommunikationswege gestaltest, wird immer auf dich persönlich und generell auf dein Projekt zurückwirken. Beim Eclipse Summit Europe sagten mir einige Ph.D.-Studenten aus München: "Wenn wir zur EMF-Newsgroup kommen und du unsere Fragen beantwortest, wissen wir, dass du dich um unsere Probleme kümmerst, aber wenn wir zu einer anderen Newsgroup gehen und keine Antwort erhalten, fühlen wir uns einfach nicht willkommen." Die Wahrnehmung ist die Realität.
Eclipse Magazin: Aus der Perspektive der Softwareentwicklung geht es beim Modeling immer um modellgetriebene Softwareentwicklung. Kennst du vielleicht interessante oder vielleicht auch "exotische" Projekte aus der Industrie oder aus der akademischen Forschung, die Eclipse-Modeling-Technologien nutzen, aber nichts mit Softwareentwicklung zu tun haben?
Ed Merks: Ein interessantes Beispiel, das mir einfällt, ist Daniel Ford mit seiner Arbeit in der IBM-Forschung am Spatiotemporal Epidemiological Modeler (STEM). STEM nutzt EMF, um verschiedene Faktoren zu modellieren, die bei der Ausbreitung von Krankheiten beteiligt sind, z.B. das Wetter oder Verkehrsmuster, Inkubationszeiten, Infektionsraten und so weiter. Diese Modelle werden dann zusammengesetzt, um die wahrscheinliche Ausbreitung einiger hypothetischer Krankheitsereignisse zu simulieren. Entscheidungsträger können STEM einsetzen, um sich auf Ereignisse wie eine globale Grippeepidemie oder Terroranschläge mit biologischen Waffen vorzubereiten. EMF hilft nicht nur, Software effektiver zu entwickeln, sondern sogar um Krankheiten vorzubeugen und die Welt sicherer zu machen. Fehlt nur noch, dass es mir hilft, meinen Garten zu jäten!
Eclipse Magazin: Vor ein paar Jahren gab es diese große Vision der "Model Driven Architecture", angetrieben von der OMG und der Software-Tools-Industrie. Die Idee basierte auf dem starken Glauben, dass es möglich sei, ein vollständiges Softwaresystem auf einem hochabstrakten Level zu entwickeln, um dann quasi per Knopfdruck alle relevanten technischen Artefakte abzuleiten. Warum ist diese Vision fehlgeschlagen?
Ed Merks: Vielleicht ist sie gar nicht fehlgeschlagen und wir sind tatsächlich noch immer auf dem Weg dorthin. Ich glaube durchaus, dass MDA viel zu früh viel zu viel versprochen hat, und ich mache diesen unangemessenen Hype verantwortlich für viele der Missverständnisse, die die Zukunft des Modeling betreffen. Eclipse-Modeling war erfolgreich, weil wir uns darauf konzentriert haben, klein anzufangen, aber dabei Großes zu planen. Wir haben als Kernstück ein solides Metamodell gebaut – Ecore ist die De-facto-Referenzimplementierung von EMOF – und haben dann eine Reihe von darüberliegenden Modellen entwickelt wie UML, XSD, OCL, BPMN.
Wenn man darüber nachdenkt, taucht vieles aus der OMG-Landschaft allmählich bei Eclipse auf. Vielleicht schaut die OMG auf Eclipse und betrachtet Eclipse als Beweis des Erfolgs ihrer Vision. Ich würde das nicht bestreiten, obwohl ich persönlich denke, dass es noch lange Zeit nötig sein wird, Programme in universellen Programmiersprachen zu schreiben. Ich sehe das Modeling eher als Ergänzung. Wenn wir damit weitermachen, bessere Abstraktionsmöglichkeiten zu finden, werden Domain Specific Languages (DSLs) immer attraktiver werden. Aber ich glaube nicht, dass es so wichtig ist vorauszusehen, wo wir am Ende stehen werden. Stattdessen sollten wir uns darauf konzentrieren, kleine Schritte in die richtige Richtung zu machen.
