Eine technische Anwendungsarchitektur für Componentware

Der folgende Artikel beschreibt das Ergebnis eines Softwareprojekts zur Entwicklung einer technischen Anwendungsarchitektur. Ziel hierbei war der Entwurf eines Implementierungskonzepts für zukünftig zu entwickelnde Anwendungssysteme, so daß deren Dialoge, Funktionen und auch Daten als unabhängige, selbständige Komponenten auf unterschiedliche Rechnerknoten verteilt werden können (Client/Server-Architektur).

In diesem Bericht wird das zugrundeliegende technische Architekturkonzept sowie die aus dem Projekt hervorgegangene Werkzeugunterstützung beschrieben. Hierbei wird insbesondere ausführlich dargestellt, welche Überlegungen in den vorliegenden Ansatz eingeflossen sind, um die Erstellung von Komponenten für verteilte Anwendungen zu unterstützen.

Inhaltsübersicht

1 Motivation für die Entwicklung einer technischen Anwendungsarchitektur

2 Eigenschaften der technischen Architektur (TAA)

2.1 Technische Modularisierung

2.2 Schnittstellenregistrierung

2.3 Technische Infrastruktur

2.4 Modulkommunikation und Datenbereitstellung

3 Werkzeugunterstützung

4 Übergang zu einer Client/Server-Umgebung

5 Schlußbemerkung

 

  1. Motivation für die Entwicklung einer technischen Anwendungsarchitektur
  2. Vor allem begründen folgende Sachverhalte die Durchführung des TAA-Projekts:

    · Alle wichtigen Qualitätseigenschaften eines Programmsystems hängen von Überlegungen auf Architekturebene ab, d.h. die Festlegung der Struktur eines Softwaresystems - also dessen Architektur - ist Voraussetzung für jede Art von Qualitätsüberlegungen und somit insbesondere für die Unterstützung von Wiederverwendbarkeit, Wartbarkeit und Verteilbarkeit. Darüber hinaus kann für verschiedene Problemklassen, wie z. B. die Klasse der interaktiven (online-) Systeme oder die Klasse der Batch-Probleme eine Standardsoftware-Architektur angegeben werden.

    · Der Bruch beim Übergang zwischen fachlicher Analyse und technischem Anwendungsdesign soll reduziert und ähnlich methodisch konstruktiv festgelegt werden, wie er im Bereich der Überführung logischer Datenmodelle in ein physisches Datenbankdesign heute bereits gelöst ist.

    · Softwaresysteme sollen so konstruiert werden, daß technologische Weiterentwicklungen in den Bereichen Hardware- und Softwaretechnik auch in bestehenden Anwendungen sukzessiv integriert werden können. Bei der Nutzung neuer Entwicklungen hilft eine Architektur dann, die relevanten Teile eines Anwendungssystems zu lokalisieren und die Wirkungen neuer Techniken genauer abzuschätzen.

    Vorrangiges Ziel des TAA-Projekts war es somit, eine Implementierungsplattform für Anwendungsentwicklungsprojekte zu entwerfen, auf Basis derer heute - mit vorhandener Hard- und Systemsoftware (hier: IBM/Mainframe-Umgebung unter MVS, CICS, COBOL und DB2) - neue Anwendungen entwickelt werden können, die zu einem späteren Zeitpunkt mit überschaubarem Aufwand auf neue Hardwareplattformen übertragen werden können. Während einer Übergangsphase soll auch die Koexistenz alter und neuer Umgebungen möglich sein.

    Da es zum Zeitpunkt der Projektinitiierung (1992) keine befriedigende Werkzeugunterstützung zur Entwicklung von verteilten Anwendungen für unterschiedliche Hard- und Softwarearchitekturen gab, wurde beschlossen, dafür eine eigene technische Infrastruktur bestehend aus Modularisierungs- und Schnittstellenstandards, graphischen Editoren, Generatoren sowie Laufzeitkomponenten zu erstellen.

  3. Eigenschaften der technischen Architektur (TAA)
  4. Mit der technischen Architektur wurde ein methodisches Konzept sowie eine Werkzeugunterstützung geschaffen, die aus Sicht des Software-Entwicklungsprozesses den Bruch beim Übergang zwischen fachlicher Analyse und technischem Anwendungsdesign reduziert. Wesentlicher Gegenstand der TAA ist somit:

    · zur Unterstützung der Softwareentwicklung: Methoden und Werkzeuge zur technischen Modularisierung.

    · zur Unterstützung der Zielumgebung: Eine technische Infrastruktur.

    1. Technische Modularisierung
    2. Während des technischen Designs wird eine Anwendung in einzelne Bausteine - auch Module genannt - zerlegt. Es wird hierbei über Werkzeuge die Möglichkeit geboten, Module als abstrakte Datentypen im Sinne von Parnas zu definieren, d.h. Bausteine sind gekennzeichnet durch Datenkapselung und funktionale Schnittstellen. Durch eine derartige Konstruktion von Modulen werden die folgenden wichtigen Software-Qualitätseigenschaften unterstützt:

      · Autonomie: Module beeinflussen sich in ihrer Wirkung nicht gegenseitig (standardisierte Schnittstellen - keine versteckten Fernwirkungen).

      · Austauschbarkeit: Einzelne Module können ersetzt werden ohne Auswirkungen auf andere Systemteile (wichtiger als Portierbarkeit).

      · Wiederverwendbarkeit/-auffindbarkeit: Da die technische Architektur auf einem Metamodell basiert, können qualifizierte Suchkriterien zum Wiederauffinden von Modulen in einem "Repository" spezifiziert werden.

      · Komplexitätsreduktion: Die möglichen Aufrufbeziehungen zwischen Modulen sind eingeschränkt, so daß Aufrufstrukturen innerhalb eines Software-Systems einfacher zu überschauen sind.

      · Flexibilität/Anpaßbarkeit: Änderungen der Ablaufreihenfolge von Aktivitäten haben ausschließlich Auswirkungen auf eine bestimmte Kategorie von Modulen, den sogenannten Steuerungsmodulen, und sind bei entsprechender Werkzeugunterstützung schnell durchführbar.

      Abb. 1 Modulstruktur der TAA

      Je nach Schwerpunktaufgabe der einzelnen Bausteine werden folgende Modultypen unterschieden (vgl. Abb. 1):

      · Datenzugriffsmodule - zur Beschaffung und Speicherung von Daten der Unternehmensdatenbank.

      · Interaktionsmodule - zur Durchführung von Aufgaben, die in direktem Bezug zum Aussehen und Verhalten der Anwendung dem Endbenutzer gegenüber stehen. Ein Interaktionsmodul hat keinen direkten Zugriff auf die Unternehmensdatenbank.

      · Autonome Funktionsmodule - zur Erledigung von fachbezogenen Aufgaben, beispielsweise die Berechnung von Prämien und Provisionen, die Durchführung von Risikoprüfungen oder komplexen Eingabeplausibilitäten. Diese Module führen keine Zugriffe auf die Unternehmensdatenbank durch und treten auch nicht in direkte Interaktion mit dem Endbenutzer.

      · Steuerungsmodule - haben als Aufgabe die Verknüpfung und Ansteuerung der Module aller Kategorien, die zur Realisierung eines Geschäftsvorfalls erforderlich sind. Die übrigen Module melden der Steuerungsebene lediglich ihren Datenbedarf und den aktuellen Zustand; über das weitere Vorgehen wird in Steuerungsmodulen entschieden. Jedes Modul weiß nur von sich selbst, welche Dienstleistung es bieten kann; die Steuerungsebene weiß, wie diese Dienstleistungen angefordert werden können. Somit besteht durch Steuerungsmodule grundsätzlich die Möglichkeit, vorhandene Dienstleistungen in neuen, bisher undefinierten Geschäftsvorfällen wiederzuverwenden. Auf keinen Fall soll auf Steuerungsebene eine Fachfunktion ausmodelliert werden, noch eine Dialogsteuerung oder der Ablauf eines Datenzugriffs. Die Steuerungsebene verknüpft ebenfalls die unterschiedlichen Systemwelten im Falle einer verteilten Verarbeitung und überwacht die Transaktionierung. Zusammen mit der Information über das technische Umfeld, in dem die einzelnen Modulen verfügbar sind, ist es der Steuerungsebene möglich, die gesamte Infrastruktur zu berücksichtigen und zu bedienen, in der die Anwendung läuft.

      Die dargestellte und über eine konventionelle Modularisierung hinausgehende Typisierung von Bausteinen bietet mehrere Vorteile:

      · Die Auffindbarkeit und Zuordnung von Modulen wird erleichtert.

      · Wenn die Schwerpunktaufgabe eines Moduls ausfindig gemacht wurde, können Standardaufgaben solcher Bausteine automatisch zur Verfügung gestellt werden (z.B. Historisierungsfunktionen für die Klasse der Datenzugriffsmodule oder Hilfefunktionen als Standardkomponente für Interaktionsmodule).

      · Seitens der Entwicklungswerkzeuge werden Annahmen bezüglich der Funktionsweise der Modulen getroffen.

    3. Schnittstellenregistrierung
    4. Eine der Voraussetzungen zur Modularisierung und »externen« Verknüpfung einzelner Modulen ist die zentrale Festlegung und Verfolgung der Schnittstellen der Modulen. Die Festlegung der Schnittstelle nach außen spielt in der technischen Anwendungsarchitektur eine doppelte Rolle:

      · Sie soll einerseits den Informationsbedarf, die Ergebnisse und die grobe Funktionalität des Moduls festlegen

      · und dadurch andererseits das Modul besser identifizierbar machen.

      In der Schnittstellenbeschreibung werden drei Aspekte festgelegt:

      · Auf welche Ereignisse kann das Modul reagieren?

      · Welche Parameterobjekte werden zum jeweiligen Ereignis in welcher Art (erzeugend, lesend, verändernd oder löschend) benutzt?

      · Welche Zustände können dem Aufrufer zurückgemeldet werden?

      Die in der Schnittstelle definierten Parameterobjekte werden in Form von Ausprägungen einzelner Objekttypen definiert (z.B. das Parameterobjekt NeuKunde vom Objekttyp Kunde).

      Abb. 2 Registrierung von Modulen und deren Schnittstellen

      Dieser ganze Prozeß (Kategorisieren mit anschließendem Beschreiben der Schnittstelle) wird als das »Registrieren« eines Moduls bezeichnet. Zur sinnvollen Nutzung wird die so festgelegte Rahmendefinition eines Moduls in einer Entwicklungsdatenbank gespeichert. Die einzelnen Attribute der Registrierung sind anschließend als Suchkriterien verwendbar, was die Wiederauffindbarkeit und damit die Wiederverwendbarkeit der Modulen steigert: Eine Suche wie z.B. "Welche Autonome Funktion liefert als Ergebnis ein Parameterobjekt des Typs Tarif unter Verwendung eines Parameterobjekts des Typs Lebensversicherungsvertrag?" wird wahrscheinlich eher Erfolg haben als eine Suche über Umschreibungstexte, die möglicherweise nur teilweise oder gar nicht mehr mit der Funktionalität des umschriebenen Moduls übereinstimmen.

      Um die Aktualität der Modulregistrierung sicherzustellen, sorgen Werkzeuge dafür, daß die Registrierungsinformationen direkt für die Realisierung genutzt werden; eine Änderung der Implementierung kann nicht ohne Änderung des "Repository"-Inhalts erfolgen (vgl. Abb. 2).

    5. Technische Infrastruktur
    6. Die technische Infrastruktur, die durch das TAA-Projekt erstellt wurde, deckt nahezu alle systemtechnischen Aspekte zur Laufzeitunterstützung einer Anwendung ab, wie z.B. Datenpufferung, Speichermanagement etc. Das heißt, daß alle durch das System bedingten Probleme und Besonderheiten - auch gegebenenfalls Performance-Tuning - an einer zentralen Stelle abgehandelt werden können.

      Zur Infrastruktur gehören die in Abbildung 1 dargestellten Layer sowie der Object-Manager. Generelle Aufgaben der Layer sind

      · die Kommunikationsschnittstelle zu den Modulebenen Datenzugriffe, Funktionen und Interaktionen aufzubauen und

      · im Falle einer verteilten Verarbeitung die Information zu speichern, auf welchem Rechner die von der Steuerungsebene gewünschte »Dienstleistung« verfügbar ist, d.h. ob ein aufgerufenes Modul lokal oder auf einem entfernten Rechner gespeichert ist.

      Der Object-Manager übernimmt neben der temporären Zwischenspeicherung von Daten zur Laufzeit einer Anwendung auch alle Probleme des Datentransports und der Datenformatierung, so daß die Programmierung auch von dieser Problematik entlastet wird. Man erreicht somit eine

      · Standardisierung des Datenaustausches zwischen Modulen sowie

      · eine optimierte Datenkommunikation zwischen Client- und Server-Komponenten einer Anwendung bei verteilter Verarbeitung.

      Zu beachten ist, daß der Object-Manager nur die Rolle eines Laufzeit-Datenservers spielt, der Aufträge von den Anwendungsmodulen entgegennimmt (z.B. "Besorge Daten zum Objekt NeuKunde") - selbst jedoch nie direkt auf die Unternehmensdatenbank zugreift (dies tun ausschließlich Datenzugriffsmodule).

    7. Modulkommunikation und Datenbereitstellung

    Wie etwa in dargestellt wird, ist eines der Probleme, welches bei Client/Server-Architekturen auftritt, der Kommunikationsaufwand zwischen verteilten Einheiten einer Anwendung. Aus diesem Grund wurde im Hinblick auf eine zukünftige verteilte Verarbeitung ein Konzept zur Datenverwaltung entwickelt, durch welches die Datenübertragung zwischen verschiedenen Rechnern im produktiven Umfeld einer Anwendung auf ein Minimum reduziert wird.

    Nach der Beschaffung der Daten durch ein Datenzugriffsmodul werden die Daten durch den Object-Manager übernommen. Die Übergabe der Daten zwischen Modulen erfolgt lediglich durch Angabe einer Referenz auf die Daten - eines sog. Handles. Anhand dieser Referenz kann das Modul, welches schließlich auf die Dateninhalte zugreifen und diese gegebenenfalls verändern will, die Dateninhalte vom Object-Manager anfordern.

    Es werden folglich keine Datensätze zwischen Modulen hin- und hergereicht. Dadurch wird die Menge an zu übergebenden Daten bei einem Modulaufruf drastisch reduziert, was in Anbetracht der Verteilung, der Modularisierung und der Aufrufstrukturen von großer Bedeutung ist.

    Die technische Optimierung wird ermöglicht durch eine bewußte Trennung von Kontroll- und Datenfluß beim Modularisierungsprozeß: Der Kontrollfluß einer Anwendung - also die spezifizierten Aufrufbeziehungen - werden über die Steuerungsebene definiert. Der tatsächliche Datenfluß zwischen Anwendungskomponenten wird jedoch erst zur Laufzeit aufgrund technischer Kriterien über die Infrastruktur festgelegt.

    Durch dieses Vorgehen wird die strukturelle Abhängigkeit der Anwendung von einer eventuellen Verteilung verringert. Auch wenn etwa Steuerungs- und Funktionsmodule für einen Geschäftsvorfall auf verschiedenen Rechnern liegen, müssen die Daten trotz auszuführender Aufrufstruktur womöglich nie übertragen werden. Ebenso kann es sein, daß anstelle von umfangreichen Datensätzen lediglich das Ergebnis von deren Auswertung an ein Modul auf einem anderen Rechner übertragen wird. Durch diese Technik kann in bestimmten Geschäftsvorfall- und Verteilungsszenarien die Übertragungshäufigkeit von Daten theoretisch bis auf ein Drittel reduziert werden.

  5. Werkzeugunterstützung
  6. Zur Unterstützung der Anwendungsentwicklung bei der Erstellung von Anwendungssystemen gemäß TAA wurden im einzelnen folgende Software-Komponenten entwickelt:

    · Graphische Entwicklungswerkzeuge unter Windows zur Spezifikation von Anwendungssteuerungen und Modulschnittstellen mit integrierter Anbindung an ein Host-Dictionary, so daß ein DV-technisches Design für ein Anwendungssystem PC-gestützt durchgeführt werden kann (vgl. Abb. 3).

    · Generatoren für die automatische Erzeugung von Steuerungsprogrammen und Programmskeletten für eine COBOL-Programmierumgebung.

    · Zentrale Infrastruktur-Komponenten zur Laufzeitunterstützung einer mittels der oben aufgeführten Werkzeuge generierten Anwendung für die MVS-Zielumgebungen CICS/DB2 und OS-BATCH/VSAM.

    Abb. 3 Editieren und Generieren von Steuerungsmodulen

    Durch diese Form der Werkzeugunterstützung wurde eine wesentliche Verbesserung bezüglich der Konsistenzwahrung zwischen Designergebnissen und zu erstellendem Sourcecode erzielt: Die Entwickler arbeiten unter TAA mit nur einem Programmiermodell, wobei sämtliche Designspezifikationen genau an einer Stelle gespeichert werden und die dargestellten Werkzeuge für die Konsistenz dieser Ergebnisse sorgen.

    Graphische Konstruktionen aus der Designphase werden direkt in Programmcode umgesetzt. Beim Füllen der Datenzugriffs-, Funktions- und Interaktionsmodule mit entsprechendem Verarbeitungscode stehen die abgeleiteten Sourceteile dann in Form von Programmskeletten zur Verfügung. Eine erfolgreiche Generierung von Programmen - und insbesondere von ganzen Anwendungssystemen - ist somit nur möglich, wenn die Designinformationen mit den daraus abgeleiteten Codeteilen und die seitens der Anwendungsentwicklung programmierten Sourceteile verträglich zueinander sind.

    Das bedeutet aber auch, daß die Designphase eines Projekts nicht vollständig abgeschlossen sein muß, bevor mit der Programmierung begonnen werden kann: Designresultate können "per Knopfdruck" in Sourcecode übersetzt werden, wie auch Erkenntnisse für ein Redesign, die nach wie vor bei der Programmierung entstehen, mit den Werkzeugen direkt einzuarbeiten sind. Insbesondere wird hierdurch eine zyklische und iterative Systementwicklung sowie die frühe Erstellung von Anwendungsprototypen unterstützt.

    Durch die automatische Generierung der kompletten Anwendungssteuerung und aller Programmskelette mit zum Teil schwierigem technischem Code (beispielsweise werden technische Wiedereinstiegsmechanismen sowie die komplette Programmkommunikation bereitgestellt) wird aufgrund erster Erfahrungen davon ausgegangen, daß sich der reine Programmieraufwand eines Projekts - also der noch "per Hand" zu erstellende Sourcecode - etwa halbiert.

  7. Übergang zu einer Client/Server-Umgebung
  8. Bereits in dem heute eingesetzten zentralisierten Umfeld verbessert die technische Anwendungsarchitektur die Überschaubarkeit, die Wartbarkeit und die Strukturiertheit von Anwendungen durch das Ausschalten von Fernwirkungen über Systemumfeld, Datenflüsse und Kontrollstrukturen.

    Darüber hinaus stellt die TAA-Entwicklung eine Investition in die Zukunftssicherung dar: Der ganze Nutzen aus der beschriebenen Infrastruktur kommt dann vollständig zum Tragen, wenn diese Architektur tatsächlich in einer verteilten Zielumgebung eingesetzt wird, da sie es erlaubt, eine Anwendung innerhalb einer verteilten Umgebung zu realisieren, wobei die Verteilungsproblematik in einem Stück Infrastruktur gebündelt wird. Die verschiedenen Anwendungsmodule stehen dann als Services in unterschiedlichen Umgebungen zur Verfügung, wie es in Abbildung 4 beispielhaft dargestellt ist. Sie können mit einem entfernten Modul-Aufruf ausgeführt werden und sind von der Verteilung strukturell nicht betroffen. Die Verteilung von Anwendungen ist somit aus Sicht des Anwendungsentwicklers transparent.

    Verteilungsschnitte durch eine mit TAA konstruierte Anwendung sind grundsätzlich zwischen allen Modulebenen möglich. Neben dem Szenario zentraler Datenhaltung aus Abbildung 4 kann beispielsweise auch nur die Präsentation auf Workstations, unter Beibehaltung zentraler Funktionen und Datenzugriffe, verlagert werden. Ja, sogar innerhalb einer Modulklasse kann eine Verteilung auf unterschiedliche Rechner erfolgen (etwa die Verteilung spartenspezifischer Funktionen auf verschiedene Abteilungs-Server).

    Seitens TAA wird somit kein spezielles Client/Server-Modell bevorzugt. Prinzipiell wird eine Vielzahl denkbarer Verteilungsmodelle unterstützt, deren Auswahl sich durch fachliche Anforderungen bestimmen soll.

    Abb. 4 Ein Beispiel für ein Client/Server-Szenario unter TAA: Zentrale Datenhaltung mit lokaler Präsentation und Funktionalität

  9. Schlußbemerkung

Die Entwicklung einer technischen Anwendungsarchitektur sowie deren Unterstützung durch eigenentwickelte Werkzeuge hat sich im Einsatz bei den Auftraggebern als sehr wirkungsvoll erwiesen. Es hat sich gezeigt, daß typische Probleme von Anwendungsentwicklungsprojekten anhand eines vorliegenden "technischen Bauplans" fruchtbar diskutiert und einer effizienten Lösung zugeführt werden können. Somit kann eine solche Architektur einen direkten und auch spürbaren Beitrag für eine verbesserte Zielerreichung bei DV-Entwicklungsvorhaben leisten.

Zur erfolgreichen Unterstützung solcher Architekturen reicht allerdings ein alleiniges "Konzept" nicht aus. Es ist dringend erforderlich, dem Anwendungsentwickler auch Werkzeuge zur Verfügung zu stellen, die die hohe Komplexität einer solchen Architektur zu einem Großteil verbergen. Darüber hinaus führt die Durchführung eines werkzeug-gestützten Anwendungsdesigns einen weiteren Schritt hin zu dem Ziel, für eine anschließende Programmierphase "benutzbare" Spezifikationen zu erzeugen. In der Projektpraxis ist leider auch heute noch allzu oft ein reiner "Papierberg" das einzige Ergebnis von Analyse- und Designprozessen.