"Als Entwickler verbringt man die meiste Zeit damit, den Code anderer Leute zu verstehen."

Eclipse Magazin: Eine wichtige Prämisse von Intent ist das, wofür sich Donald Knuth in seinem Buch „Literate Programming“ stark macht: „Statt sich einzureden, dass es unsere Hauptaufgabe sei, einem Computer beizubringen, was er tun soll, sollten wir uns darauf konzentrieren, Menschen zu erklären, was wir von dem Computer verlangen.“ Das Buch wurde 1984 geschrieben – warum, glaubst du, ist diese Aussage Knuths noch immer zutreffend?

Alex Lagarde: Donald E. Knuth war der wichtigste Ideengeber für Intent. Literate Programming ist eine Methode, die in einem einzigen Dokument, dem „Literate Program“, eine Programmiersprache mit einer Dokumentationssprache verbindet. Die Idee dahinter ist es, ein Programm als normale Lektüre aufzubereiten, die an Menschen, nicht an Computer gerichtet ist.

Natürlich ist die Idee heute noch immer sinnvoll, sogar sinnvoller als 1984. Wenn Code nur für Computer vorgesehen wäre, würden wir nur Assembler-Sprachen benutzen. Aber Programmieren ist eine Gemeinschaftsaufgabe: Code soll von anderen gelesen werden, auch von einem selbst zu einem späteren Zeitpunkt, und man sollte so lesbar wie möglich Coden. Nach Knuth sind die Intentionen hinter der Software, die Gründe, warum man eine Designentscheidung getroffen oder einen bestimmten Abschnitt Code geschrieben hat, genauso wichtig wie der Code selbst. Solche Intentionen können nur schlecht innerhalb des Codes (z. B. mit Javadoc) festgehalten werden, weil die Codestruktur zu engmaschig ist, um darin höhere Spezifikationen anzugeben.

Eclipse Magazin: Aber dieser Literate-Programming-Ansatz wird in Intent doch nicht eins zu eins umgesetzt?

Alex Lagarde: Es gibt drei Unterschiede: Bei Literate Programming ging es ja darum, Dokumentation und C-Code in einem Dokument zu verbinden. Mit Intent kann man die Dokumentation mit jeder Art von technischem Artefakt kombinieren: Modellen, Java-Code, C++-Code, Workspace-Konfiguration etc. Beim Juno-Release haben wir uns auf das konzentriert, was wir „Literate Modeling“ nennen: Wir haben Dokumentation mit allen möglichen EMF-Modellen kombiniert. In diesem Bereich gibt es schon Geschäftsmöglichkeiten. Intent wird für Enterprise-Architekturen, System-Engineering-Modelle (unter Verwendungen von SysML) eingesetzt.

Der zweite Unterschied: Bei Literate Programming kann man den Code nicht direkt verändern. Man muss das Literate Program aktualisieren und den Code dann neu generieren. Bei Intent geht es uns darum, dass der Code mit entsprechendem Tooling verändert werden kann und dass Modelle mit Modellierungswerkzeugen bearbeitet werden können – vorausgesetzt, man verwendet das richtige Tool für die richtige Task.

Drittens müssen bei Literate Programming Code und Dokumentation auf gleicher Höhe bleiben. Im Gegensatz dazu berücksichtigen wir bei Intent die unterschiedlichen Lebenszyklen von Code und Dokumentation. Es ist auch in Ordnung, wenn die Dokumentation nicht die Veränderungen von vor wenigen Tagen wiedergibt – wenn Dokumentation oder Code weiterentwickelt werden, werden Synchronisationsprobleme in den veralteten Teilen in jedem Fall angezeigt. Es bleibt einem dann selbst vorbehalten zu entscheiden, wann eine Änderung angebracht ist.

Eclipse Magazin: Wie erleichtert Intent das Teilen von Dokumenten?

Alex Lagarde: Dokumentation ist ebenfalls eine Gemeinschaftsaufgabe. Das Teilen von Dokumenten in Echtzeit ist nicht nur „nice to have“, sondern eine Notwendigkeit. Es ermöglicht Echtzeit-Reviews und -Feedback zu den eigenen Spezifikationen und Ideen. Das Teilen von Dokumenten via E-Mail oder Versionskontrollsystem deckt nicht den Bedarf an Echtzeitkollaboration. Intent schon.

Intent hat eine Client-Server-Architektur: Es gibt ein zentrales Repository, in dem wir das Intent-Dokument als Modell und viele andere nützliche Informationen ablegen (Validierung, Synchronisation, Rückverfolgbarkeit etc.). Jedes Intent-Feature wird von einem Client verwaltet, der Eclipse-Editor ist nur einer davon. Jeder Client kommuniziert mit den anderen durch einen Benachrichtigungsmechanismus, der vom Repository gewährleistet wird.

Dieses Repository-Konzept ist ganz abstrakt und kann durch konkrete Backends implementiert werden. Für das Kepler-Release arbeiten wir an einem CDO-basierten Intent Repository. Wer CDO [2] noch nicht kennt, sollte es definitiv mal ausprobieren, es ist eine großartige Technologie. Es ermöglicht es, kurz gesagt, Dokumente live zu teilen, mit Echtzeit-Updates und feingranularem Lock-Management, um Konflikte zu vermeiden. Mit einem CDO-basierten Repository können viele Nutzer gleichzeitig dasselbe Dokument lesen und bearbeiten. Sobald ein Nutzer das Dokument speichert, werden die Änderungen über das Repository verbreitet und damit für andere Nutzer sofort sichtbar.

Momentan deployen wir diese Technologie im Obeo SmartEA Tool [3], wo wir Intent mit einem CDO-Server verbinden, der Enterprise-Architektur-Modelle speichert. Das ist ein sehr guter Anwendungsfall für Intent, da EA-Modelle komplexe und geschäftskritische Informationen enthalten, die genau dokumentiert werden müssen. Intent is also eine gute Lösung, wenn es darum geht, EA-Modelle und die Dokumentation auf demselben Stand zu halten und die Folgen einer Migration der EA einzuschätzen. Der nächste Schritt ist es, an der Performance zu arbeiten, um mit sehr großen Modellen und Intent-Dokumenten arbeiten zu können.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.