Borlands neueste Version der Delphi-Familie, Ende letzten Jahres auf den Markt gekommen, ist eine vollwertige .Net-Entwicklungsumgebung und stellt zusammen mit seinem Brudersystem C# Builder die erste ernstzunehmende Konkurrenz zu Microsofts Visual Studio .Net dar, soviel wissen wir aus zahlreichen Pressemeldungen von Borland. In Sachen .Net-Integration sowie Ausstattung von Editor, Compiler und Codierhilfen schenken sich die beiden Kontrahenten tatsächlich wenig. Beide Seiten sind recht gut ausgereift, was den Stand der Technik darstellt. Selbst der grosse Teil der mitgelieferten Bibliotheken unterscheidet sich nicht gross und entspricht dem, was bei einem Entwickler-Tool der gehobenen Klasse erwartet werden darf. Als Kompliment an Microsoft darf verstanden werden, dass Borland erstmals nicht nur sein eigenes GUI Framework VCL (Visual Component Library) mitliefert, sondern gleichberechtigt auch die Microsoft-eigenen WinForms verwendet. Bisher war ja die Borland VCL einer der Gründe, weshalb man Applikationen mit grafischer Benutzeroberfläche besser mit Delphi als mit C++ und dem Microsoft-GUI-Konstrukt MFC (Microsoft Foundation Classes) entwickelte. Microsoft hat hier kräftig aufgeholt und das .Net GUI Framework zum Beispiel mit durchgängig unterstützten Databinding-Fähigkeiten ausgestattet, die man in der VCL vergeblich sucht. Weshalb denn überhaupt noch Borland, wenn Visual Studio .Net bereits zum besseren Delphi geworden ist?
Neu gibt es da einen Unterschied, welcher Borland noch für einige Zeit einen wesentlichen Vorsprung vor den Redmondern sichern dürfte: Das mit Delphi 8 Architect mitgelieferte MDA-Framework (Model Driven Architecture) mit Namen ECO. Das Akronym steht für Enterprise Core Objects und benennt die aktuellste Version der Borlandschen Interpretation von MDA. ECO basiert auf der Delphi-Komponentensammlung Bold (Business Object Layer for Delphi) der schwedischen Firma Boldsoft, welche sich Borland Ende 2002 einverleibt hat. Mit der Akquisition hat sich Borland die Erfahrung aus über 10 Jahren Entwicklung modellbasierter Werkzeuge sowie eine bereits existierende Anwenderbasis eingekauft. Angesichts der spärlichen Dokumentation, die zu ECO mitgeliefert wird, springt diese Anwenderbasis zuweilen in die Bresche, ist doch der Erfahrungsaustausch mit langjährigen Bold-Anwendern für Neulinge oft unentbehrlich. Die entsprechenden Newsgroups stehen auf dem Borland-Server unter nntp://newsgroups.borland.com/modeldriven-architecture.general zur Verfügung.
Bevor wir uns konkret anschauen, was mit ECO alles möglich ist, ein kurzer Exkurs zum Thema MDA. Der modellbasierte Entwicklungsansatz verspricht verschiedene Vorzüge. Einer der wichtigsten ist, dass das Programmierhandwerk durch Automatisierung einfacher, schneller und fehlerfreier werden soll. Die Anwendungslogik eines Programms wird unabhängig von technischen Details, eben als Modell, formuliert. Ausgehend von diesem Modell generiert die MDA-Umgebung weitgehend automatisch ein lauffähiges Programm. Natürlich lässt sich kaum eine ernsthafte Anwendung komplett auf Knopfdruck generieren, insbesondere bei der Gestaltung der Benutzeroberfläche fällt normalerweise noch einiges an Handarbeit an, wobei das Modell, das ja in maschinenlesbarer Form vorliegt, Unterstützung bei der Anbindung der Oberfläche bietet. Wesentlich ist aber, dass technische Implementierungsdetails wie zum Beispiel die Art der Datenspeicherung oder die ins Auge gefasst Zielplattform nicht in die Gestaltung des Modells einfliessen.
Die Trennung zwischen Applikationslogik (Modell) und technischer Umsetzung (MDA Generator, Framework) fördert die klare Strukturierung eines Softwareprojekts. Der Hauptteil des Programmieraufwands kommt der Applikationslogik und der Gestaltung der Oberfläche zugute, während allgemeinere Aspekte wie Oberflächenanbindung, Zugriffskontrolle oder Datenbank-Kopplung quasi automatisch zur Verfügung stehen. Viele Fehlerquellen in häufig wiederkehrendem technischem Code können durch die Codegenerierung vermieden werden. Abgesehen von der gegenüber traditionellen Methoden höheren Produktivität, kann der MDA-Programmierer sich auf die Applikationslogik konzentrieren und somit der eigentlichen Aufgabe seines Programms vermehrt Beachtung schenken. Nicht zuletzt unterstützt der modellbasierte Ansatz auch die Dokumentation der Programmentwicklung. Ein Modell, grafisch in UML formuliert, ist in den meisten Fällen deutlich aussagekräftiger als reiner Code. Ausserdem garantiert ein MDA-basiertes Entwicklungsvorgehen, dass diese Art der Dokumentation immer aktuell ist, das Programm entsteht schliesslich aus dem Modell.
Tönt paradiesisch, aber wie funktioniert denn nun ein solch geheimnisvolles MDA-Tool? Der offizielle MDA Standard wird von der Object Management Group (OMG) beschrieben und besagt, dass die Funktionalität und die anwendungsspezifischen Datenstrukturen einer Software in einem UML-Modell beschrieben werden sollen. Dieses Modell soll möglichst frei von technischen Details sein und die Anwendungsdomäne einer Applikation so beschreiben, dass sie ein Fachmann des betreffenden Gebiets verstehen kann. Die OMG nennt dieses Modell "plattformunabhängiges Modell" (PIM).
Nun kommt das MDA-Tool ins Spiel. Von ihm wird verlangt, dass es aus dem PIM irgendwie eine lauffähige Applikation erzeugt oder zumindest dabei behilflich ist. OMG schlägt dazu vor, das Modell durch eine Transformation in ein "plattformspezifisches Modell" (PSM) umzusetzen, aufgrund dessen dann Code für einen Compiler erzeugt werden kann. Diese Modelltransformation erlaubt es, ausgehend von einer Anwendungsspezifikation, ein spezifisches Modell für eine bestimmte Plattform, zum Beispiel CORBA, J2EE oder .Net zu erzeugen. Ausserdem ist in der Modelltransformation die Anwendung bestimmter Entwurfsmuster (Patterns) vorgesehen. Damit können auch technische Details der Umsetzung - zum Beispiel welches Oberflächen-Framework verwendet wird oder wie die Daten gespeichert werden - in den Aufgabenbereich der Modelltransformation fallen.
Der OMG-Ansatz für MDA ist ziemlich umfassend und gleichzeitig auch sehr allgemein gehalten. Dadurch lässt er sich auf fast alle Arten von Softwareprojekten und Plattformen anwenden. Andererseits bietet er für kleine und mittlere Entwicklungsprojekte wenig Anhaltspunkte und kaum konkrete Hilfestellungen. Hier setzt Borland mit seinen MDA-Tools an. Bold und ECO bieten sich für mittelgrosse Projekte auf Microsofts Windows-Plattformen an. Bei den meisten Entwicklungsvorhaben in diesem Bereich stellen sich Fragen nach Plattformauswahl wie J2EE oder Corba gar nicht. Es geht einfach darum, ein Programm, meist mit Datenbankanbindung, unter Windows zu entwickeln. Die Zielplattform ist dabei auf .Net beziehungsweise Win32 festgelegt. Das Delphi7 beigepackte Bold erzeugt Programme für Win32, während ECO von Delphi8 sich auf .Net als Zielsystem versteht. Bei der Unterstützung von Entwurfsmustern bieten beide Tools vergleichbare Möglichkeiten, die wesentlichen sind Objekt-relationales Datenbank-Mapping, Oberflächenanbindung und ein Interpreter für objektorientierte Abfragen.
Das plattformunabhängige Modell wird in Borlands MDA als eine Sammlung von sogenannten "Businessklassen" modelliert. Dabei stehen UML-Mechanismen wie Vererbung von Klassen und Verknüpfungen zwischen verschiedenen Objekten zur Verfügung. Eine Klasse kann dabei als speicherbar (persistent) markiert werden. Eine Modelltransformation stellt die Objekte aus den Businessklassen anschliessend als Delphi- beziehungsweise .Net-Objekte zur Verfügung. Dabei wird nur ein minimaler Anteil an Interface- und Initialisierungscode generiert. Die eigentliche Implementation der plattformspezifischen Klassen ist bereits im Framework-Code vorhanden. Die Applikationsobjekte konfigurieren sich aufgrund der Modellinformationen zur Laufzeit.
Das Modell ist nicht nur Quelle für das fertige Programm, es ist eigentlicher Bestandteil des fertigen Programms. Die Integration des Modells ermöglicht Dinge, die bei einer reinen Codegenerierung nur schwierig möglich wären. Zum Beispiel hat der im Framework enthaltene objektorientierte Abfrage-Interpreter direkten Zugriff auf die Modellinformationen und kann so bei der Formulierung von Abfragen zur Laufzeit behilflich sein und deren Gültigkeit überprüfen. Auch das Abspeichern von persistenten Objekten in eine Datenbank geschieht aufgrund der Informationen aus dem Modell.
Genug der grauen Theorie, bekanntlich sagt ein Beispiel mehr als lange Beschreibungen. Stellen wir uns die Aufgabe, mit Hilfe von Delphi8 und ECO ein kleines Programm zu erstellen, welches unsere Kontakte, das heisst Firmen und Personen, verwalten soll. Ausser den üblichen Angaben möchten wir noch darstellen können, welche Personen bei welchen Firmen im Verwaltungsrat sitzen. Der erste Schritt nach MDA-Ansatz ist, für diesen Sachverhalt ein UML-Modell zu erstellen. Dafür müssen wir zuerst eine neue ECO-Applikation in Delphi erzeugen. Anschliessend öffnen wir per Doppelklick auf die standardmässig vorhandene Unit CoreClasses den Delphi-eigenen Modell-Editor. Das Modell für unser Beispiel zeigt Abbildung 1.
Wir haben eine Klasse namens Kontakt sowie die zwei Subklassen Firma und Person definiert. Ein Kontakt besitzt die allgemeinen Angaben Name, Adresse und Ort. Bei der Firma können wir noch den Jahresumsatz angeben, die Person erhält die zusätzlichen Attribute Vorname und Geburtstag. Nun führen wir noch eine Verknüpfung zwischen Person und Firma ein, auch dies geschieht durch einfaches Ziehen im Modell-Editor. Die Verknüpfung soll einer Firma Verwaltungsräte zuordnen. Von der Person ausgehend, sollen Firmen als Verwaltungsratsitze zugeordnet werden können. Wir konfigurieren die Verknüpfung so, dass in beiden Richtungen mehrere Zuordnungen möglich sind, das heisst, eine bestimmte Person kann bei verschiedenen Firmen im VR sitzen, während auch eine bestimmte Firma mehrere Verwaltungsräte hat. Da es sich hier um eine m:n-Verknüpfung handelt, müssen wir der Verknüpfung noch einen Klassennamen für die automatisch generierte Link-Klasse geben (VRMandat). Hiermit ist unser plattformunabhängiges Modell bereits fertig.
Damit wir unsere Applikation ausführen können, brauchen wir nur noch eine rudimentäre Oberfläche. Die Projektvorlage enthält dafür schon ein leeres WinForms Unit, das wir nun mit Inhalt füllen können. Für unser Beispiel beschränken wir uns auf eine Listenansicht und zwei Buttons zum Erzeugen von Personen und Firmen (Abbildung 2).
Abbildung 2: Die rudimentäre GUI des Beispiels baut auf ein leeres WinForms Unit.
Zusätzlich zu diesen visuellen Elementen braucht unser Oberflächen-Form noch eine Datenquelle, ein sogenanntes Handle, welches der Liste sagt, was sie anzeigen soll. Wir ziehen dafür aus der ECO-Palette ein Expression-Handle auf unser Form und nennen es KontakteHandle. Hier zeigt sich einer der grossen Vorteile des .Net-Teilsystems WinForms, dessen Controls alle eine Databinding-Eigenschaft haben. ECO nutzt den generellen .Net-Databinding-Mechanismus zur Anbindung von Oberflächenelementen. Während für Bold unter Delphi7 noch spezielle bold-aware-Controls benötigt wurden, ist unter .Net jedes WinForms-Control MDA-fähig.
Unser KontakteHandle braucht nun noch selbst eine Quelle, wir nehmen dafür das automatisch generierte rhRoot, das Stamm-Handle unseres EcoSpace, sowie eine Expression, das heisst eine Objektabfrage. Als Expression setzen wir Kontakt.allInstances ein, das ist OCL (Object Constraint Language) und heisst soviel wie "zeig mir alle Objekte der Klasse Kontakt". Schliesslich binden wir die Liste an unser KontakteHandle und teilen ihr über die Einstellung DisplayName mit, sie solle in jeder Zeile den Wert der Objekt-Eigenschaft name anzeigen.
Für unsere 2 Buttons neue Person und neue Firma schreiben wir je eine Zeile Eventcode, im Falle von neue Person lautet dieser Person.Create(EcoSpace), was besagt, dass wir ein neues Objekt der Klasse Person erzeugen wollen, und zwar in unserem Standard EcoSpace. Für die Firma funktioniert das analog.
Weil wir uns das Gestalten von Detailformularen sparen wollen, benutzen wir den von ECO zur Verfügung gestellten Service EcoAutoForms. Dank den aspektorientierten Eigenschaften von .Net kennt unsere Liste bereits die entsprechenden Einstellungen, wir müssen nur die Eigenschaft EcoAutoForms der Liste auf wahr setzen. Dies bewirkt, dass bei Doppelklick auf eine Zeile ein automatisch generiertes Form für die aktuelle Klasse angezeigt wird.
An dieser Stelle ist unsere Mini-Applikation bereits fertig und sollte sich compilieren und starten lassen. Das Programm zeigt nach dem Start ein Fenster mit einer leeren Liste an. Ein Druck auf neue Person fügt eine Zeile in die Liste ein, allerdings steht da noch nichts drin. Doppelklicken auf die neue Zeile zeigt die autogenerierte Editiermaske für alle Eigenschaften unserer Person-Klasse an (Abbildung 3).
Dasselbe lässt sich auch mit neu zu erfassenden Firmen machen. Die VR-Zuordnung erledigen wir ebenfalls ohne weiteren Aufwand mittels Drag and Drop. Dazu enthalten die Masken für Person und Firma jeweils eine Liste mit verknüpften Objekten. Durch Ziehen aus der Kontakteliste in die Verknüpfungslisten können wir beliebig Zuordnungen vornehmen, natürlich nur solche, die unser Modell vorsieht.
Ein Problem bleibt noch: Nach dem Beenden der Applikation sind alle Daten wieder weg. Was uns noch fehlt, ist ein Speichermechanismus, in ECO-Sprache Persistence Mapper genannt. Mitgeliefert wird eine ganze Palette von Persistence Mappers, jeweils für verschiedene Datenbank-Zugriffsschichten (BDE, ADO). Für unsere Zwecke am geeignetsten ist der XML Persistence Mapper, da dieser unsere Daten im XML-Format in ein Textfile abspeichert. Der Ort zum Einsetzen des Persistence Mapper ist wiederum der EcoSpace, der "Lebensraum" unserer MDA-Objekte (Abbildung 4).
Dem EcoSpace selbst muss durch Auswahl des eingefügten Persistence Mapper mitgeteilt werden, wohin er Daten speichern soll. Schliesslich braucht unser Form noch einen Close Eventhandler, welcher das Speichern der Daten veranlasst, dies geschieht mit der Zeile EcoSpace.UpdateDataBase. Dieser einfache Methodenaufruf sorgt dafür, dass alle seit dem letzten Speichern veränderten Eigenschaften unserer Objekte gespeichert werden. Ob die Speicherung in ein simples XML-File oder in eine ausgewachsene SQL-Datenbank erfolgt, interessiert uns an dieser Stelle nicht mehr.
Wir haben nun innert weniger Minuten eine lauffähige Applikation zusammengestellt. Es mag einzuwenden sein, dass dies auch mit anderen Entwicklungsumgebungen oder mit gewissen 4.-Generations-Sprachen mit vergleichbarem Aufwand möglich gewesen wäre. Wesentlich beim vorliegenden Ansatz ist jedoch, dass das Ergebnis vollständig in .Net-Code vorliegt. Ausserdem liesse sich unsere Applikation durch wenige Mausklicks von XML-File auf SQL-Server-Unterstützung erweitern, sie erraten es, durch einfaches Austauschen des Persistence Mapper. Falls eine Framework-Komponente, wie zum Beispiel der Persistence Mapper, unseren Ansprüchen nicht genügen sollte, können wir uns mittels Klassenvererbung eine eigene, massgeschneiderte Version herstellen und diese anstelle der mitgelieferten Version verwenden.
Borland liefert mit Delphi und C#-Builder zwei MDA-Tools, die zwar die MDA-Architekturvorgaben nicht komplett nach Lehrbuch umsetzen, dafür jedoch verhältnismässig schnell zu brauchbaren Ergebnissen führen. Die neueste Entwicklung ECO zeigt vorbildlich auf, wie MDA unter .Net aussehen kann. Es verwendet konsequent die .Net-eigenen Features wie Databinding oder Attributes zur Integration des MDA-Ansatzes. Im Vergleich zum grundsoliden Bold-Paket, welches mit Delphi 7 mitkommt, scheint ECO noch etwas neu. Gewisse Möglichkeiten, das Framework an die eigenen Bedürfnisse anzupassen, welche Bold bietet, fehlen dem jüngeren Bruder noch. Unverständlich ist, dass sowohl Bold als auch ECO in Borlands Marketing-Prosa immer nur am Rande erwähnt werden. Wahrscheinlich verstehen auch bei Borland nur wenige, wozu diese Komponenten zu gebrauchen sind. Es wird wohl noch ein paar Jahre dauern, bis sich MDA als Entwicklungsansatz durchgesetzt hat. Objektorientiertes Design hat ja auch 20 Jahre gebraucht, um allgemein akzeptiert zu werden. Allerdings ist jetzt ein guter Zeitpunkt, auf den Zug aufzuspringen, die passenden Tools stehen jedenfalls zur Verfügung.
Samuel Iseli hat als Entwicklungsleiter der Zürcher Vertec, welche dieStandardsoftware "tim office" herstellt, sechs Jahre Erfahrung in modellbasierter Entwicklung.
