Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

21.05.1999 - 

Componentware/Investitionsschutz und Migrationsweg durch Komponenten

Datev setzt bei Steuerprogrammen auf C++ und COM

Für die Umstellung bestehender DOS-Programme nach WIN32 machte man sich bei der Datev, DV-Dienstleister für die deutschen Steuerberater, auf die Suche nach einem Framework für die komponentenbasierte Entwicklung. Die Umsetzung dieser Ziele durch den Einsatz von C++- und COM-Komponenten beschreibt Jürgen Steiner* am Beispiel der Steuerprogramme für Windows.

Voraussetzung für die Tool-Auswahl bei Datev war, daß es die Integration existierenden C- und C++-Codes (Datenhaltung in Archivdateien, OO-Layer über das Datenbanksystem "Btrieve", ein eigenentwickeltes p-Code-Fachlogik-System) unterstützen würde, denn gerade die technologieunabhängige fachliche Logik der Datev-Anwendungen sollte sich in der Übergangszeit sowohl in den DOS-Programmen als auch in der neuen Windows-Version parallel nutzen lassen. Gewünscht war auch, die Anwendungsexperten produktiver als bisher in der Projektentwicklung einsetzen zu können und interdisziplinäres Teamwork einzuführen.

Zudem sollten sich die Oberfläche sowie das Verhalten der Applikation von fachlich versiertem Personal ohne Programmiererfahrung weitgehend eigenständig erstellen lassen, um so die zeitkritische und kostspielige Ressource der Windows-C++-Programmierer effizienter einzusetzen. Aus den schlechten Erfahrungen in Testprojekten sollte die neue Entwicklungsumgebung dabei eine strenge Trennung zwischen Oberfläche, fachlicher Logik und Datenhaltung gewährleisten. Die Idealvorstellung war deshalb für die Datev ein fachliches Komponentenmodell, das unabhängig von der Oberfläche einsetzbar und damit sehr leicht wiederzuverwenden und zu warten wäre.

Die Entscheidung fiel 1995 für die Entwicklungsumgebung "Framework++" der Frankfurter Newline Software Development GmbH. Dieses Produkt basiert auf dem Industriestandard Microsoft Foundation Classes (MFC) und erfüllte die gewünschten Anforderungen. Framework++ bestand zu jener Zeit bereits aus visuell montierbaren C++-Komponenten, die zudem sehr einfach zu modifizieren und zu erweitern waren. Die Assemblierung erfolgt rein visuell - ohne Codegenerierung - in einem zum Produkt gehörenden Editor, so daß Fachentwickler, Betriebswirte beziehungsweise Steuerexperten sehr einfach Steuerformulare als Eingabemasken und Druckformulare erstellen und mit Berechnungsformeln versehen konnten. C++-Entwickler konnten zudem neue Komponenten so integrieren, daß sie sich von den Fachentwicklern mit einem hohen Komfort verwenden ließen. Da zu diesem recht frühen Zeitpunkt COM nur in Form von OLE (Object Linking and Embedding) verbreitet war, realisierte man die gewünschten fachlichen Komponenten ausschließlich in Form von C++-Klassen in Visual C++, die im Framework++-Editor komfortabel eingebunden, parametrisiert und persistent gespeichert werden.

Framework++ bietet für die Applikationsentwicklung die technischen Basiskomponenten in Form von C++-Klassen an. Im Gegensatz zu vielen anderen Frameworks sind keine speziellen fachlichen Komponenten wie Buchung oder BLZ-Check enthalten, sondern erweiterte Benutzer-Interface-Komponenten, Ablaufsteuerungsklassen sowie eine abstrakte Datenschicht, die einen allgemeingültigen Zugriff auf eine beliebige Datenhaltung ermöglicht und die Fachlogik von der Oberfläche abkapselt. Als Beispiel für die Framework++-Standardkomponenten seien hier Eingabeelemente mit formatierter Eingabe, editierbare Grit-Controls, Object-relational Mapping über Business-Objekte und datengetriebene Aktionen genannt. Die Datenerfassung direkt in Steuerformularen am Bildschirm und der Ausdruck der Formulare als wesentliche Aspekte der Steuerprogramme für Windows ließen sich so bereits mit den Standardkomponenten des Tools grundsätzlich lösen. Eine Framework++-Komponente liegt in Form einer DLL vor, wobei eine Komponente nicht genau einer C++-Klasse entsprechen muß, sondern sich aus vielen Klassen zusammensetzen kann. Diese DLL muß nicht statisch gelinkt werden, sondern wird dynamisch zur Laufzeit geladen und kann damit genau wie eine COM-Komponente als robust und unabhängig angesehen werden.

Fehlt Funktionalität, ist der C++-Entwickler durch Framework++ fast gezwungen, eine Komponente zu programmieren. Die Erstellung einer DLL-Komponente unterscheidet sich nicht wesentlich vom Erstellen eines "normalen" COM-Pendants. Assistenten erzeugen ein DLL-Projekt und innerhalb dieser Komponente wiederum eine oder mehrere Klassen. Die C++-Interfaces für die dynamische Anbindung der DLL und der Klas- sen werden automatisch erzeugt. Handelt es sich um eine Ableitung einer bestehenden Klasse, werden nach modifizierbaren Vorlagen sofort auch gewünschte Methoden überladen und implementiert.

Durch Standardmechanismen kann eine Komponente im Framework++-Editor sofort mit Parametern versehen werden. Für die Fachentwickler wird jedoch in der Regel noch eine komfortablere Editierung in Form einer Dialogseite zur Verfügung gestellt. Auch die Editoranbindung wird assistentengestützt in einer separaten DLL generiert. Dadurch wird der Ressourcenbedarf der Applikation minimiert, sofern die Editierung der Komponenten zur Laufzeit beim Kunden nicht benötigt wird.

Für die Steuerberechnung selbst sollten das bestehende und bewährte DOS-Logikmodul in die Steuerprogramme für Windows integriert und die existierenden Mechanismen zur Datenhaltung in Form von Archiven weiterhin verwendet werden. Bei der Umsetzung dieser Ziele wurden die Datev-Entwickler durch die Architektur von Framework++ fast schon automatisch auf das gewünschte Komponentenmodell gehoben. Das Wrappen einer existierenden Komponente ist mit Framework++ nach ihrer Erfahrung einfach zu lösen.

Wrapping durch Ableitung von Basisklassen

Die dynamische Anbindung erfolgt durch Laufzeitinformationen (vergleichbar C Runtime Class in den MFC). Daher ist lediglich eine Ableitung von einer bestimmten Framework++-Basisklasse nötig, um eine Komponente zu wrappen und damit innerhalb von Framework++ wiederverwendbar zu machen - inklusive visueller Assemblierung und Parametrisierung.

Die Datev-C++-Entwickler konnten also ohne größere Schwierigkeiten die bisher vorhandenen C++-Module in Komponenten "umwandeln" und damit den Fachentwicklern im Editor zur Verfügung stellen. Durch den Mechanismus der normalen Ableitung entfiel auch eine Einarbeitung in komplexe neuartige Interface-Definitionen und Objektmodelle, die Übernahme des bestehenden Codes ging sehr schnell und produktiv vonstatten. Dabei waren oft nur kleine C++-Wrapper-Klassen nötig, die die bestehenden Funktionen an das C++-Interface der Framework++-Basisklassen anpaßten. Auf diese Art und Weise wurde neben der Logikkomponente auch die bereits existierende Datenhaltung in Binärarchiven an die Datenschicht von Framework++ angebunden. Durch die Verwendung von Standardkomponenten für das UI und das Wrapping bestehender und bewährter Komponenten für Logik und Datenhaltung stand so nach kurzer Zeit eine Basisversion der Steuerprogramme für Windows zur Verfügung, die die Feinabstimmung mit Kunden schon in einer frühen Phase ermöglichte.

Bei der Assemblierung ließen sich die mitgelieferten sowie eigenentwickelte C++-Klassen im visuellen Framework++-Editor komfortabel parametrisieren, ohne Code zu generieren. Die Speicherung erfolgte durch Serialisierung in MFC-Archiven, die dynamisch zur Laufzeit geladen werden. Dies bedeutet, daß bei Änderungen Turnaround-Zeiten ausbleiben, da kein Kompilier- oder Link-Prozeß nötig ist. Der Mechanismus der Serialisierung benötigt keinen Interpreter, da echte C++-Objekte erzeugt werden, die ihre eigenen Informationen sehr performant laden können. Durch die enthaltenen Ablaufsteuerungsklassen ist es möglich, die kompletten Steuerprogramme für Windows aus den C++-Komponenten zu montieren und zu verändern, ohne einmal mit dem C++-Compiler in Berührung gekommen zu sein.

Obwohl Framework++ ein effizientes Komponentenmodell für die Datev bietet, steht dieses als C++-Modell nur innerhalb von Framework++-Projekten zur Verfügung. Die C++-Komponenten sind also weder für Datev-Produkte, die nicht mit Framework++ arbeiten, noch für Produkte von Drittherstellern ohne Änderung verwendbar. Im Markt der Steuerberater und damit auch innerhalb der Datev-Produkt- entwicklung setzt Microsoft mit dem Betriebssystem Windows den De-facto-Standard, so daß man die Komponententechnologie COM zur Bereitstellung und Verwendung abteilungsübergreifender Datev-Komponenten in unterschiedlichen Anwendungen heranzog. Hierbei sind Aspekte der Identifikation und Granularität von Komponenten wichtig. Viele Anwendungskomponenten sind zwar innerhalb einer Applikation problemlos wiederverwendbar, anwendungsübergreifend aber nur sehr beschränkt einzusetzen.

Sukzessive wird die COM-Technologie nun überall dort eingesetzt, wo es um die Bereitstellung von Datev-Business-Komponenten an andere Abteilungen und Systemhauspartner geht, die ihre eigenen Produkte mit den Datev-Anwendungen integrieren. Zur Integration von COM-Komponenten in ein Framework++-Projekt stehen Klassen zur Verfügung, die die in C++ üblicherweise nötige Erzeugung einer Wrapper-Klasse überflüssig machen. Eine OCX-Basisklasse gestattet die Verbindung des abstrakten Datenmodells mit beliebigen Properties jeder gewünschten OCX-/Active-X-Komponente und damit den visuellen Zugriff auf deren Eigenschaften ohne Programmierung. Eine COM-Aktionsklasse verbindet Ereignisse (Menüauswahl, Datenänderungen) mit Interface-Methoden jeder beliebigen COM-Komponente. Dabei wird die Verbindung wieder rein visuell im Editor hergestellt und ist so auch für Fachentwickler leicht zugänglich.

Da diese Anbindung durch das dynamische Auslesen der Standard-COM-Interfaces erfolgt, ist es unnötig, eine C++-Wrapper-Klasse für die einzubindenden COM-Komponenten von C++-Programmierern erzeugen zu lassen. Andererseits gibt es eine Fwactive-OCX, die den umgekehrten Weg beschreitet und eine Framework++-Applikation oder einen Teilaspekt davon als eine komplexe Komponente zur Verfügung stellt, inklusive einer Schnittstelle für die wichtigsten Funktionalitäten. So können Steuerformulare einschließlich der dazugehörigen Logik und Datenhaltung als Komponente zum Beispiel in HTML-Seiten integriert und über Scriptsprachen von außen gesteuert werden..

Projekt

Die Steuerprogramme für Windows gehören zu den meistgenutzten Anwendungen bei den rund 37000 Datev-Mitgliedern. Sie sind in der Regel auch mehrfach innerhalb einer Kanzlei installiert. Die Entwicklung der Version 1.0 hat zirka zwei Jahre inklusive einer sechsmonatigen, breit angelegten Pilotphase gedauert. In Spitzenzeiten waren an der Entwicklung für die Steuerprogramme für Windows bis zu 60 Mitarbeiter beteiligt.

Angeklickt

Der Einsatz von C++-und COM-Komponenten hat es der Datev erlaubt, in interdisziplinären Teams schnell anwendergerechte Windows-Software zu entwickeln. Die Dynamik und Flexibilität des objektorientierten C++-Komponentenmodells des genutzten Frameworks hat sich bei der Entwicklung der Steuerprogramme für Windows bewährt. Wo es um die programmiersprachenunabhängige Verwendung von Anwendungskomponenten durch Dritte - interne oder externe - geht, wird Datev sukzessive COM-Schnittstellen zur Verfügung stellen. Erst die beiden Technologien zusammen bilden die Basis für die hohe Akzeptanz von "WIN Steuern" bei den Datev-Steuerberatern und halten Migrationswege - und damit den Investitionsschutz - für zukünftige technologische Entwicklungen offen.

*Jürgen Steiner ist Gruppenleiter Entwicklung Steuerprogramme für Windows bei der Datev.