Repository basierende Entwicklung
Die einzige Umsetzung des beschriebenen Ansatzes findet sich derzeit in Framework Studio der Firma Framework System aus der Umgebung von Konstanz. Das Werkzeug ist eine eigenständige Entwicklungsumgebung. Die Ebenen nennen sich hier Packages. Um die Verwaltung für die Klassen zu realisieren, wurde ein datenbankgestützter Ansatz gewählt. Dieser besitzt einige interessante Vorteile, die im Folgenden ausgeführt werden.
Im Repository werden alle Klassen in ihrer Struktur abgebildet. Die Editoren erzeugen und manipulieren diese Struktur, und das Werkzeug stellt die Konsistenz sicher. Geschäftslogik wird über Editoren in C# programmiert und ebenfalls im Repository gespeichert. Ein Codegenerator erzeugt dann aus dem Repository den Quellcode für das Programm. Dabei wird die komplette Infrastruktur für die Software generiert.
Abbildung 3 zeigt ein stark vereinfachtes Datenmodell zum Erfassen einer Klasse in einer Datenbank.
Eine Klasse besteht aus einem oder mehreren Datensätzen. Diese sind über eine PackageID der Ebene zugeordnet. Um eine Klasse abzuleiten, wird ein zusätzlicher Datensatz angelegt, welcher die Änderungen und Erweiterungen erfasst. Auf Strukturebene ist die Angabe der Basisklasse der Verweis auf einen anderen Datensatz und ist als solcher einfach zu verwalten. In dem Schema wird dieser in dem Feld Derived- From gespeichert. Auch eine Versionsverwaltung auf Klassenebene ist leicht umsetzbar. Um eine Klasse in einer neuen Version zu speichern, wird deren Datensatz mit einer inkrementierten Versionsnummer zusätzlich eingefügt. Die Klassen sind mit der aktuellen ClassVersion verschlüsselt. Mit dem Release einer Ebene wird die PackageVersion für die Ebene inkrementiert. Die Version einer Klasse kann damit eindeutig ihrem Release zugeordnet werden.
Durch die Codegenerierung und die strukturelle Erfassung der Klassen ergeben sich noch weitere Möglichkeiten. Framework Studio benutzt beispielsweise einen speziellen Klassen-Typ: ReportDocumentType. In diese Klasse werden alle Geschäftskomponenten als Properties aufgenommen, deren Daten in einem Report ausgegeben werden sollen. Zum Designen der Reports kann anschließend die Struktur der Geschäftskomponenten als XML-Schemadefinition (XSD) exportiert werden. Eine XSD ist selbst nicht vererbbar. Wie bei den normalen Klassen lässt sich aber die im Repository erfasste Struktur durch „Vererbung“ erweitern, also durch einen zusätzlichen Datensatz, welcher die Änderungen gegenüber dem ursprünglichen Datensatz festhält. Damit kann die Schemadefinition in einer anderen Ebene beliebig erweitert werden. Eine Ebene ist eine Menge an Datensätzen, welche über die PackageID und die Package- Version verschlüsselt sind. Um die Ebene weiterzugeben, müssen alle zugehörigen Datensätze als eine Art Datenbank-Dump exportiert und auf dem Zielsystem importiert werden. In Framework Studio übernimmt diese Aufgabe der Package- Manager, der die Erweiterungsmenge an Datensätzen zu einem Package zusammenfasst. Dieses kann dabei mit einem Lizenzmechanismus abgesichert werden, wodurch neben einem vollständigen Export auch die Möglichkeit besteht, nur die Struktur der Klassen weiterzugeben. Die Geschäftslogik ist dann beim Zielsystem nur noch als kompiliertes Assembly binär im Repository vorhanden. Um seine fertige Lösung zu erstellen, importiert der Kunde die gewünschten Packages, bringt sie in eine Hierarchie und lässt sich die Verbindungs- bzw. Kopfklassen generieren. Die Logikklassen der Packages werden unverändert als Assemblies in das Applikationsverzeichnis geschrieben.
Durch den auf einem Repository basierenden Entwicklungsansatz arbeiten alle Editoren mit einer Datenstruktur, nicht mit Quellcode. Die Entwicklung ist deshalb zum größten Teil deklarativ. Nur die Geschäftslogik wird in Codeeditoren geschrieben. Diese wiederum beschränkt sich in der Regel auf Operationen, welche Daten in ein Geschäftsdatenmodell editieren. Ein wichtiger Punkt ist dabei, dass in den Codeeditoren ein IntelliSense aus dem Repository-Schema bereitgestellt wird. Da die Verbindungs- und Kopfklassen generell erst bei der Codegenerierung vor dem Kompilieren erstellt werden, kann dieses nicht wie bei der auf Quellcode basierenden Entwicklung über Reflection oder Bean Introspection ermittelt werden. Vielmehr wird ein virtuelles Klassenschema benötigt, durch welches die Informationen für das IntelliSense bereits zur Design-Zeit bereitgestellt werden.
Die Codegenerierung erzeugt aus der Repository-Struktur die Programm-Infrastruktur und setzt in die Methoden- Rümpfe die in den Sourcecode-Editoren geschriebene Geschäftslogik ein. Die Geschäftslogik ist von der Infrastruktur strikt getrennt. Damit kann der Generierungprozess für die Infrastruktur zentral verändert werden. Eine Technik kann durch eine Variante ersetzt werden, wenn sie sich als unvorteilhaft erweist oder vielleicht technische Neuerungen bessere Ansätze liefern. Beispielweise stellte sich heraus, dass die früher durch Framework Studio bei der Codegenerierung genutzten Data-Sets zu einem nicht tragbaren Laufzeitverhalten der fertigen Applikationen führen. Aus diesem Grund wurde die Infrastruktur auf DataReader umgestellt. Da der Datenzugriff ein Teil der durch das Framework bereitgestellten Infrastruktur ist, war für diese tief greifende Änderung keine Anpassung des geschrieben Quellcodes erforderlich. In gleicher Weise ersetzen die mit dem .NET Framework 2.0 eingeführten generischen Datentypen einen bis dahin selbst implementierten Mechanismus für Collections. Durch die strikte Trennung kann auch eine Spezialisierung der Entwickler erfolgen. Integrationspartnern und Kunden fällt es damit leichter, Fachkräfte zu finden, welche fachspezifisches Knowhow mit einfachen Programmierkenntnissen verbinden und damit imstande sind, die Software auf die eigenen Anforderungen hin anzupassen.
Das größte Entwicklungsprojekt mit Framework Studio ist derzeit die ERPSoftware NVinity der Nissen & Velten Software GmbH. Mit dem Unternehmen verbundene Systemhäuser entwickeln auf der Basislösung aufbauende Erweiterungen und Branchenvarianten der Software. Dabei greifen sie auf die in der Basislösung implementierte Klassenbibliothek zu, um die Software um neue Dialoge, Logik und Funktionalität zu erweitern. Die Entwicklung kann unabhängig vom Hersteller erfolgen. Die Kunden wählen aus dem Pool von Packages die für sie relevanten Erweiterungen aus.
In Abbildung 4 ist die Auftragsmaske zu sehen, links aus dem Standard und rechts inklusive eines Packages, durch welches die Adressverwaltung erweitert wird.
In dem Package wurden unter anderem die Klassen Kunde, Lieferant und Adresse abgeleitet, um ihnen zusätzliche Properties hinzuzufügen. Da es sich nicht um Schlüsselfelder handelt, muss die Konsistenzsicherung auch nicht erweitert werden. Die neuen Felder sind Teil der Klasse und werden zusammen mit den originalen Feldern gelesen und gespeichert. Abgesehen davon, dass es sich um eine sehr einfache Erweiterung handelt, werden hier einige der zuvor erörterten Punkte deutlich: Es ist eine wirkliche Erweiterung. Die Felder sind im Standard nicht vorhanden. Die Strukturerweiterung beeinflusst die Geschäftslogik nicht, weshalb keine einzige Zeile Code angepasst werden muss. Für den einen Kunden mag diese Erweiterung sehr wichtig sein, ein anderer fühlt sich durch die vielen Felder mehr irritiert als dass sie ihm nützen. Nur Kunden, welche die Funktionalität auch wirklich wünschen, werden dieses Package installieren. Dabei spielt es keine Rolle, ob sie bereits zusätzliche Packages, wie das einer Branchenvariante, installiert haben. Die Erweiterung setzt auf den Standard auf und beeinflusst diesen nicht. Kundenwünsche können damit sofort durch die Systemhäuser umgesetzt werden. Anpassungen können bei Bedarf wiederverwendet oder sogar zu Speziallösungen ausgebaut werden.
Selbst der beste Customizing-Mechanismus hat seine Grenzen. Soll beispielsweise nur die Hintergrundfarbe eines Eingabefeldes geändert werden, wirkt eine Ableitung des Formulars, als wolle man mit Kanonen auf Spatzen schießen. Außerdem ist eine Formularableitung nicht zur Laufzeit durchführbar und auch nicht vom Benutzerkontext abhängig. Ein Laufzeit-Customizing ist aber in hohem Maße von der verwendeten Programmarchitektur abhängig, und muss deshalb Teil der erstellten Software sein.
Holger Rasch ist Projektmanager bei der Framework Systems GmbH. Seit 2004 berät er Software-Häuser beim Aufbau und in der Architektur ihrer Lösungen. Sein Spezialgebiet ist der Strukturaufbau von ERP-Systemen.
Fünf Fragen an die Entwickler von Framework Studio
Framework Studio ist bereits drei Jahre auf dem Markt. Welche Erfahrungen
konnten in dieser Zeit gesammelt werden?
Es stellt sich teilweise als Herausforderung dar, Framework Studio als
alternativen Entwicklungsansatz in den Köpfen zu verankern. In den
ersten zwei Jahren wurde die Basisfunktionalität ausgebaut. Erst seit einem
Jahr steht auch der Packaging-Mechanismus zur Verfügung. Dieser
verleiht dem Werkzeug einen strategischen Vorteil gegenüber anderen
Entwicklungsumgebungen und ist auch ein Alleinstellungsmerkmal. In
Bezug auf die Applikationsarchitektur kann festgestellt werden, dass
viele Softwarehersteller noch nicht die Notwendigkeit zum Wechsel, von
Client-Server zu einer webfähigen, mehrschichtigen Architektur erkennen.
Oft stehen Befürchtungen bezüglich des Bedienkomforts im Raum,
wobei diese gerade bei einer Smart Client-Architektur unbegründet sind.
Der ursprüngliche Entwurf von Framework Studio konnte wie geplant umgesetzt werden. Die Art und Weise der Umsetzung von Funktionalität wurde allerdings teilweise überdacht und angepasst. So war es beispielweise erfreulich, dass die mit dem .NET Framework 2.0 einhergehende Geschwindigkeitssteigerung in der XML-Kommunikation auch zu einem verbesserten Antwortverhalten des Clients geführt hat. Das Ziel von Framework Studio ist dabei weiterhin, neue technische Möglichkeiten für das eigene Architekturmodell nutzbar zu machen. Wenn Sie rückblickend ihre Einschätzung des damals brandneuen .NET Framework mit ihrem jetzigen Erfahrungsstand vergleichen, was sind die wichtigsten Unterschiede?
Wir haben den Vorteil, dass Microsoft mit seinem .NET Framework Ziele verfolgt, die den unseren sehr ähnlich sind. Der erste Entwurf von Framework Studio basierte ursprünglich auf einer Mischung aus COM und C sowie JavaScript im Client-Bereich. Mit der Veröffentlichung des .NET Framework zeichnete sich ab, dass dieses zu einem Umbruch in der Softwareentwicklung führen würde, und deshalb fiel uns der Wechsel auch nicht schwer. Aus heutiger Sicht hat sich die Entscheidung sicherlich bewährt. Auch die Erweiterungen wie WCF und WF, welche bekanntlich mit dem .NET Framework 3.0 verfügbar sind, werden für Framework Studio und damit für darauf basierende Applikationen eine große Rolle spielen. Der Datenbankzugriff spielt bei Framework Studio eine zentrale Rolle. Welche neuen Erkenntnisse haben die Entwickler über die verschiedenen Releases gesammelt?
Das .NET Framework bietet bekanntlich keine Datenbankunabhängigkeit. Diese ist aber eine zentrale Anforderung an Framework Studio. Das zentrale Pilotprojekt NVinity sollte zu seinem Vorgängersystem kompatibel sein. Deshalb mussten auch typische Probleme bei der Unterstützung verschiedener Datenbanksysteme gelöst werden, wie die Behandlung konkurrierender Updates, die Unterstützung der verschiedenen Dialekte und die Begrenzung der SQL-Funktionalität auf eine Untermenge, welche von allen anzubindenden Systemen unterstützt wird. Deshalb ist der Datenbankzugriff in Framework Studio mit einer eigenen Persistenzschicht realisiert, welche den Datenzugriff abbildet. Die ursprüngliche Implementierung mit DataSets wurde aus Performancegründen abgelöst. Jetzt wird für den Zugriff ein DataReader verwendet. Microsoft propagiert zur Zeit sehr stark LINQ. Gibt es Pläne, LINQ in Framework Studio zu integrieren?
Eine Unterstützung ist nicht in der kurzfristigen Release-Planung vorgesehen. Natürlich wird man verfolgen, wie sich diese Zugriffstechnik in der Zukunft etabliert, und welche konkreten Vorteile sich daraus für Framework Studio basierende Applikationen ergeben würden.
