Qua

sarQuasar:

Die sd&m Standard-architekturTeil 1

Johannes Siedersleben (Hrsg.)

Zusammenfassung

Dieses Papier beschreibt die Standard-architektur betrieblicher Informationssysteme beisd&m. Der vorliegende Teil 1 behandelt folgendeThemen:● Grundsätze und Begriffe (Kapitel 1 und 2)● Quasar-Windmühle (Kapitel 3)● Standardarchitektur des Anwendungskerns

(Kapitel 4)

Teil 1 ist Ergebnis der Arbeitsgruppe Soft-ware-Architektur im Rahmen des Projekts „Themen-arbeit“. Mitglieder dieser Gruppe waren AndreasHess, Bernhard Humm, Stefan Scheidle und JohannesSiedersleben.

Teil 2 behandelt die Standardarchitekturenfür Transaktionen, Persistenz, GUI und Verteilung.

Von den zahllosen Reviewern seien namentlich genannt: Gerd Beneken, Manfred Broy,Olaf Deterding-Meyer, Roland Feindor, Olaf Fricke,Alex Hofmann, Christian Kamm, Oliver Juwig, Hanno Ridder, Rupert Stützle, Markus Uhlendahl und Boris Zech. Ihnen allen wird herzlich gedankt.

Qua

sar

Qua

lity

Soft

war

e A

rchi

tect

ure

1

Inhaltsverzeichnis

1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.1 Quasar: Qualitäts-Software-Architektur . . . . . 21.2 Kategorien (Blutgruppen) . . . . . . . . . . . . . . . . . . 31.3 Schnittstellen und Komponenten . . . . . . . . . . . 4

1.3.1 Schnittstellen . . . . . . . . . . . . . . . . . . . . . . 41.3.2 Komponenten . . . . . . . . . . . . . . . . . . . . . 41.3.3 Erzeugung von Komponenten . . . . . . . 51.3.4 Konfiguration . . . . . . . . . . . . . . . . . . . . . 51.3.5 Komponentenhierarchie . . . . . . . . . . . . 5

1.4 Schnittstellen im Detail . . . . . . . . . . . . . . . . . . . . 61.4.1 Callback-Schnittstellen . . . . . . . . . . . . . 61.4.2 Schnittstellenkategorien,

Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4.3 Stützschnittstellen . . . . . . . . . . . . . . . . . 7

1.5 Komponenten im Detail . . . . . . . . . . . . . . . . . . . . 71.5.1 Komponentenvertrag . . . . . . . . . . . . . . 71.5.2 Wie beschreibt man

Komponenten? . . . . . . . . . . . . . . . . . . . . 91.6 Weitere Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.6.1 Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.6.2 Baustein . . . . . . . . . . . . . . . . . . . . . . . . . 101.6.3 Schichten, Layer, Tier . . . . . . . . . . . . . 10

2 Architekturbegriffe . . . . . . . . . . . . . . . . . . . . . . 112.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 TI-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.3 A-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 T-Architektur und Standard-

T-Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Entwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . 13

3 Quasar-Windmühle . . . . . . . . . . . . . . . . . . . . . . . 14

4 Standardarchitektur des Anwendungskerns . . . . . . . . . . . . . . . . . . . 16

4.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Außensicht von A-Komponenten . . . . . . . . . . . 164.3 A-Datentypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4 A-Entitätstypen . . . . . . . . . . . . . . . . . . . . . . . . . . 184.5 A-Verwalter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.6 A-Fälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.7 A-Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . 214.8 A-Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . 22

AnhangQuasar-Konformität . . . . . . . . . . . . . . . . . . . . . 23

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2. Auflage 4/03

Vorwort zur zweiten Auflage

Die ersten 2500 Exemplare von Quasar Teil 1 waren nach 6 Monaten restlos vergriffen. Die vorliegende zweite Auflage enthält neben einigenredaktionellen Änderungen zwei wichtige Verbesse-rungen:

a) Die Darstellung der verschiedenen Archi-tekturbegriffe (Kapitel 2) gab Anlass zu Missver-ständnissen und Unklarheiten. Daher wurden Teilevon Kapitel 2 neu formuliert.

b) Die Begriffe Desaster sowie legale/illegale Zustände wurden von verschiedenen Seitenzu Recht kritisiert. Abschnitt 1.5.1 erläutert dieneuen Begriffe: Notfall statt Desaster, konsistent/inkonsistent statt legal/illegal.

München, im April 2003

Johannes Siedersleben

2

Eine ganze Reihe von allgemein akzeptierten Prin-zipien der Informatik gelten in der Literatur als Allge-meinplatz, werden aber in der Praxis bestenfallsoberflächlich angewandt. Ein Beispiel ist das Denkenin Komponenten: Der Begriff ist in aller Munde, aberdie meisten so genannten Komponenten vermen-gen Schnittstelle und Implementierung in unzuläs-siger Weise.

Die Prinzipien dieses Kapitels sind Allgemein-gut der Informatik, und sie sind für uns die Grund-lage des Software-Entwurfs. Wir haben versucht, sieso zu formulieren, dass klar wird, worauf es ankommt.Unser Ziel ist, dass jedes Projekt diese Prinzipienwirklich einhält.

Quasar: Qualitäts-1.1 Software-Architektur

Quasar definiert ein gemeinsames Verständnis vonSoftware-Qualität. Quasar hat nicht den geringstenAnspruch auf Originalität, sondern versucht, beson-ders wichtige Regeln und Mechanismen der Software-technik verständlich zu beschreiben, zu präzisierenund zum Standard zu erklären. Dies geschieht aufdrei Ebenen:a) Ideen und Konzepte. Dies sind die Grundprinzipien

der Softwaretechnik: Denken in Komponenten,Trennung der Zuständigkeiten usw. Damit befasstsich dieses Kapitel.

b) Begriffe: Die Informatik krankt an vielen unklarenoder mehrdeutigen Begriffen. Kapitel 2 definierteine Reihe von technikneutralen Begriffen, mitdenen wir über Softwarearchitektur sprechen kön-nen, ohne uns auf EJB oder CORBA festzulegen.

c) Standardarchitektur und Standardschnittstellen1.Die meisten Datenbankzugriffsschichten habenähnliche Schnittstellen. Quasar definiert für ver-schiedene Themen (wie den Datenbankzugriff)Standardschnittstellen mit Syntax und Semantik,auf denen jedes Projekt aufsetzen kann.

Zu diesen Standardschnittstellen entwickelnwir (sd&m Research) Komponenten in hoher Qualität,die den sd&m-Projekten zur Verfügung stehen2. Sokann jedes Projekt Quasar auf drei Ebenen einsetzen:a) Verwendung der Ideen, Konzepte und Begriffe,b) Verwendung der Standardschnittstellen,c) Verwendung von fertigen, auf Code-Ebene nutz-

baren Komponenten.

Warum brauchen wir Quasar? Es gibt doch J2EE, CCM, SOAP und anderes (etwa [D’Souza1999]). Dazu folgende Antworten:

1. Die Schnittstellen von Quasar sind wesentlich an-wendungsnäher als die technisch orientierten obengenannten Schnittstellen. Quasar definiert einenPuffer zwischen der Anwendung und der Technik.

2. Quasar lässt uns die Freiheit, diejenigen Produkte zunutzen, die uns gefallen (oder auf denen der Kundebesteht), und überall dort eigene Software zu verwen-den, wo es keine brauchbaren Produkte gibt oder wo wir etwas besseres haben. Quasar ist KEINE Kon-kurrenzveranstaltung zu J2EE, sondern lässt uns das Beste davon nutzen.

3. Quasar macht uns unabhängig von den schnellenund nicht beeinflussbaren Innovationszyklen imtechnischen Bereich (Wie sieht EJB in 4 Jahren aus?).

4. Quasar macht uns unabhängig von teuren, schwer-fälligen und in der Weiterentwicklung nicht beein-flussbaren Produkten: Weil wir Produkte als Kompo-nenten begreifen, die hinter Schnittstellen agieren,ist der Austausch von Produkten zwar nicht gratis,aber machbar.

5. Quasar-Ideen und Schnittstellen gelten sprachüber-greifend, und zwar ohne Einschränkung für Java,C++ und C#, mit geringen Einschränkungen für Cund mit größeren für Cobol.

6. Quasar hilft uns vor allem bei Nicht-Standard-Situationen, die ein Produkt niemals abdecken wird(etwa beim Zugriff auf Nachbarsysteme). Man kann keine Zugriffsschicht kaufen, die Änderungengleichzeitig in eine relationale Datenbank und in ein Nachbarsystem schreibt.

Argumente gegen QuasarZwei Argumente gegen Quasar versuchen wir schonan dieser Stelle zu entkräften:

1. Quasar schadet der Performance. Zusätzliche Schich-ten kosten tatsächlich ein paar Maschinenzyklen,aber das ist heute kein Problem; an dieser Front wirdder Performance-Krieg nicht gewonnen. Viel wich-tiger sind die Steuerungsmöglichkeiten, die ein nachQuasar-Ideen gebautes System bietet. Wir betrach-ten als Beispiel den Datenbankzugriff: Systeme sinddann langsam, wenn sie zum falschen Zeitpunkt zuviele Daten lesen. Wer den Quasar-Ideen folgt, derbehält die vollständige Kontrolle über diesen Zeitpunktund verfügt damit über viele Tuning-Möglichkeiten.

1 Grundlagen

1 Beschrieben in Quasar Teil 2.

2 Eine Übersicht der vor-handenen Komponenten findet sich in Kapitel 3.

3

2. Quasar schränkt die Menge der nutzbaren Funktionenein. Dies ist in doppelter Hinsicht falsch:a) Wir bleiben beim Beispiel der Zugriffsschicht:

Gerade weil die harten SQL-Anweisungen an einerStelle konzentriert sind, kann man ohne Bedenkenalle Spezialitäten des gegebenen DBMS verwen-den. Man hat also mehr Funktionen, nicht weniger.

b) Aus Anwendungssicht sind die technischenSchnittstellen viel zu kompliziert. Keine einzelneAnwendung braucht alle 6 Transaktionsmodi von EJB. Deshalb definiert Quasar eine einfacheTransaktionsschnittstelle mit den Operationencommit und rollback, und erst in einer technischenKomponenten wird entschieden, welcher Trans-aktionsmodus zur Anwendung kommt.

Quasar und MusterMuster sind Design in the Small, Quasar ist Design in the Large. Quasar verwendet zahlreiche Muster:Die verschiedenen Fabrikmuster, der Adapter und die Fassade kommen laufend vor und werden nichteigens erwähnt. Manche Quasar-Elemente könnteman als Muster verkaufen, aber das hat geringe Priorität (vgl. [Gamma1995], [Buschmann1996]).

Quasar und WissenschaftQuasar ist aus wissenschaftlicher Sicht unfertig: Alle Definitionen sind informell, manche fehlen ganz (wir sagen z.B. nicht, was wir unter der „Semantikeiner Schnittstelle“ verstehen). Viele Konzepte undIdeen sind zwar angedeutet, aber noch nicht in derTiefe beschrieben. So ist Quasar auch eine Agendafür weitere Forschung, die wir aber nicht aus der Praxis heraus leisten können, sondern lieber denUniversitäten überlassen. Als Themen bieten sich(mindestens) an: a) Software-Kategorien (Abschnitt 1.2)b) Komponenten und Schnittstellen (Abschnitt 1.3)c) Komponentenvertrag, konsistente und

inkonsistente Situationen (Abschnitt 1.5.1) d) Aufteilung der Softwarearchitektur in A-, T- und

TI-Architektur (Kapitel 2).Die Kluft zwischen Praxis und Wissenschaft

ist auch heute noch sehr breit. Wer baut die Brücke?Wir betrachten Quasar als einen praxisseitigenBrückenkopf. Auf der Seite der Wissenschaft sehenwir Arbeiten wie [Broy2001], wo ohne Anspruch auf unmittelbaren Praxisbezug ein rigides Gedanken-gebäude errichtet wird. Wird es gelingen, die beidenWelten zu verbinden?

1.2 Kategorien (Blutgruppen)

Trennung der Zuständigkeiten ist eine, wenn nichtdie Leitlinie für gute Software-Architektur: Software,die sich mit verschiedenen Dingen gleichzeitigbefasst, ist in jeder Hinsicht schlecht. Der Alptraumjedes Programmierers sind Returncodes verschie-dener technischer APIs (ist die Datenbank noch ver-fügbar?) vermischt mit Anwendungsproblemen(kann die Buchung noch storniert werden?), und alldies innerhalb weniger Programmzeilen. Diese Ideekann man formalisieren:

Jedes Software-System befasst sich mit derfachlichen Anwendung, denn dafür wurde es gebaut.Und es verwendet eine technische Basis (Betriebs-system, Datenbank, Verbindungssoftware), denn imluftleeren Raum kann es nicht laufen. Daher gehörtjede Komponente zu genau einer von fünf Katego-rien. Sie kann sein:● 0-Software ist unabhängig von Anwendung und

Technik. Beispiele sind Klassenbibliotheken, diesich mit Strings und Behältern befassen (etwa diezum C++-Standard gehörige Standard TemplateLibrary STL). Sie ist ideal wiederverwendbar, fürsich alleine aber ohne Nutzen.

● A-Software ist bestimmt durch die Anwendung,aber unabhängig von der Technik. Anwendungs-bestimmter Code kennt Begriffe wie „Fluggast“,„Buchung“ oder „Fluglinie“.

● T-Software ist unabhängig von der Anwendung,bestimmt durch die Technik: Ein solcher Bausteinkennt mindestens ein technisches API wie JDBCoder OCI.

● AT-Software ist bestimmt durch Anwendung undTechnik: leider eine häufig anzutreffende Form. Sieist schwer zu warten, widersetzt sich Änderungen,kann kaum wiederverwendet werden und ist daherzu vermeiden, es sei denn, es handelt sich um R-Software.

● R-Software transformiert fachliche Objekte inexterne Repräsentationen und wieder zurück. Bei-spiele für externe Repräsentationen sind Zeileneiner Datenbank-Tabelle, ein Bildschirmformatoder XML. Sie kann häufig aus Metainformationengeneriert werden.

Diese fünf Kategorien formalisieren dieTrennung der Zuständigkeiten nur auf der oberstenEbene. Selbstverständlich sollte sich jede T-Kom-ponente nur mit einem technischen API befassen undnicht gleichzeitig mit zwei oder drei; jede A-Kompo-nente sollte nur ein Anwendungsthema bearbeiten.Im nächsten Abschnitt befassen wir uns mit Schnitt-stellen und Komponenten: Jede Schnittstelle undjede Komponente gehört zu genau einer Kategorie.

4

Schnittstellen 1.3 und Komponenten

1.3.1 SchnittstellenJede Schnittstelle definiert eine Menge von Operationen mit● Syntax (Rückgabewert, Argumente, in/out, Typen)● Semantik (was bewirkt die Operation) ● Protokoll (z.B. synchron, asynchron)Zu einer Schnittstelle gehört ferner alle Typen, dieman braucht, um die Schnittstelle zu benutzen. Hier als Beispiel der TestListener aus JUnit(vgl. [Hightower2002]):

interface TestListener { public void addError(Test test, Throwable t); public void addFailure(Test test, Throwable t); public void endTest(Test test); public void startTest(Test test);

}

Die Semantik ist in diesem Fall überschaubar: Man kann jedem TestListener den Start und das Endeeines Testlaufs mitteilen, und man kann ihn über Error und Failure informieren. Test ist selbst eineCallback-Schnittstelle (vgl. Abschnitt 1.4.1),Throwable eine abstrakte Klasse.

Jede Schnittstelle kann nicht-funktionaleEigenschaften festlegen: z.B. Performance, Robustheit.Schnittstellen sind die Träger der Software-Archi-tektur. Man entwirft zuerst die Schnittstellen, unddann überlegt man, wie man sie implementiert (oder wie man sich eine Implementierung beschafft).

Nutz-SS

„darf der das?“

Admin-SS

Pflege derBenutzer undderen Rechte

Berechtigungs-komponente

RACF

Abbildung 1:Eine Komponente mit zwei exportiertenSchnittstellen

In welcher Form beschreibt man Schnitt-stellen? Bei der Syntax hat man die Wahl, z.B. JavaInterfaces wie im Beispiel oder Corba-IDL. DieSemantik und andere Eigenschaften notieren wir nachdem heutigen Stand der Praxis mit informellem,ungenauem Text – und sind nicht glücklich damit!Dieses Problem löst leider auch Quasar nicht.

1.3.2 KomponentenDie Komponente ist eine sinnvolle Einheit

des Entwurfs, der Implementierung und damit derPlanung. Der Begriff der Komponente ist unabhängigvon Bedienoberflächen und Datenbankzugriffen: Esgibt Komponenten mit oder ohne Bedienoberfläche,mit oder ohne Datenbankzugriff.

Die Komponente, über die wir hier sprechen,ist eine Architekturkomponente (also etwas Größeres,Substantielles). Sie ist nicht zu verwechseln mit der Komponente im GUI-Sinn. In Kapiteln 4 und inQuasar Teil 2 werden spezielle Komponenten definiert, z.B. die A-Komponente (vgl. Abschnitt 4.7).

Jede Komponente exportiert mindestenseine Schnittstelle und sie importiert beliebig vieleSchnittstellen (keine Komponenten!).

Der Export einer Schnittstelle bedeutet dietatsächliche Bereitstellung der in der Schnittstelleversprochenen Funktionen (und nicht nur dieBekanntgabe des Namens der Schnittstelle). JedeKomponente k, die die Schnittstelle s exportiert, ist eine Implementierung von s.

Der Import einer Schnittstelle bedeutet,dass die Komponente die Operationen dieserSchnittstelle benutzt. Sie ist erst lauffähig, wenn alleimportierten Schnittstellen zur Verfügung stehen,und dies ist Aufgabe der Konfiguration (sieheAbschnitt 1.3.4). Importierte Schnittstellen werdenmanchmal bekannt gegeben (öffentliche Konfigura-tion) oder auch nicht (private Konfiguration).

Zur Illustration betrachten wir eine Kom-ponente k, die die Schnittstellen s1 .. sn importiert.Die Konfiguration bindet k an bestimmte Imple-mentierungen h1, h2, .., hn, die natürlich selbst auchzu konfigurieren sind. Dabei gilt:a) Die importierende Komponente macht keine

Annahmen über die verwendete Implementierung.Sie läuft also klaglos mit verschiedenen Imple-mentierungen.

b) Verschiedene Implementierungen können sich inBezug auf Performance, Robustheit und – ingewissem Umfang – in der Semantik (man denkean Dummy-Implementierungen oder an Rechen-genauigkeit) unterscheiden. Dies beeinflusst das Verhalten der importierenden Komponente.

Konfiguration ist die Festlegung auf einebestimmte Implementierung: Entwurf und Program-mierung gegen Schnittstellen ist gut und schön, aber irgendwo muss man Farbe bekennen, und daspassiert in der Konfiguration.

5

JUnit liefert drei Implementierungen vonTestListener: ui.TestRunner, swingui.TestRunner undtextui.TestRunner, die sich – wie der Name verrät –in der Art der Ausgabe unterscheiden.

Viele Komponenten exportieren mehr alseine Schnittstelle. Standardbeispiel ist eine Berechti-gungskomponente (vgl. Abbildung 1), die eine Ad-ministrations- und eine Nutzschnittstelle exportiert.Die Administrationsschnittstelle dient zur Verwal-tung der Nutzer und deren Rechte; die Nutzschnitt-stelle hat als zentrale Operation die Abfrage: Ist Nutzer x zur Aktion y berechtigt?

1.3.3 Erzeugung vonKomponenten

Es gibt drei grundsätzliche Möglichkeiten, eine Kom-ponente zu implementieren:a) Statisch: Die Komponente existiert pro Umgebung

(z.B. JVM3) genau einmal.b) Einzelexemplar (Singleton): Die Komponente ist

im Prinzip mehrfach konstruierbar; der Konstruk-tor achtet darauf, dass höchstens ein Exemplarvorhanden ist.

c) Mehrfachexemplar (Multiton): Die Komponentekann in beliebig vielen Exemplaren existieren.

Beispiel für Mehrfachexemplar: Bei man-dantenfähigen Systemen kann man pro Mandant einExemplar der Berechtigungskomponente konstru-ieren, so dass jedes Exemplar nur einen Mandantenkennt. Dadurch wird die Berechtigungskomponenteselbst wesentlich einfacher.

Die Beliebtheit des Singleton-Muster führtleider oft dazu, dass ohne großes Nachdenken demEinzelexemplar der Vorzug gegeben wird.

1.3.4 KonfigurationDie Konfiguration definiert, welche Implementie-rungen tatsächlich verwendet werden. Dies geschiehtfrühestens zur Compile-Zeit und spätestens zur Aufrufzeit. Es gibt drei wichtige Implementierungs-varianten:a) direkter Aufruf eines Konstruktors,b) indirekter Aufruf eines Konstruktors über eine

(abstrakte) Fabrik,c) Verbindung mit einer auf einem Server vorhande-

nen Komponente über einen Namensdienst.

Es gibt drei wichtige Organisationsformender Konfiguration: a) Öffentliche Konfiguration: Die Konfiguration

liegt in der Verantwortung einer übergeordnetenSteuerung. Wichtiges Beispiel für öffentliche Konfiguration ist der Bindungsmechanismus vonVerbindungssoftware: Der Client (Steuerung) verbindet sich mit einem Namensserver, beschafftsich eine Referenz auf eine entfernte Implemen-

tierung, die er aber nicht kennt, und ab jetzt läuftalles gegen eine Schnittstelle. Oft ist es sinnvoll,alle öffentlichen Konfigurationen in einem Konfi-gurationsverwalter zusammenzufassen

b) Private Konfiguration: Die importierende Kompo-nente übernimmt die Konfiguration selbst. In demFall hat die Steuerung nichts mehr zu tun, aber siehat auch keine Möglichkeit des Eingriffs. Das istvor allem dann sinnvoll, wenn nicht-funktionaleEigenschaften (Performance) zugesichert sind,oder wenn die enthaltene Komponente für denAufrufer unerheblich ist (vgl. Abschnitt 1.3.5).

c) Vorkonfiguration: Die importierende Komponenteläuft standardmäßig mit einer bestimmten Imple-mentierung, die bei Bedarf von der Steuerunggeändert wird. Vorkonfiguration ist nichts anderesals öffentliche Konfiguration mit Vorbelegung.

Wir sprechen von einer Benutzt-Beziehung,wenn die Konfiguration außerhalb von k stattfindet:Komponente k benutzt h. Benutzt-Beziehungen kannman ohne Eingriff in die benutzenden Komponenteändern. Zyklische Benutzt-Beziehungen sind verbo-ten, weil sie ungewollte Abhängigkeiten erzeugen.

Wenn sich die Komponente k selbst um dieKonfiguration kümmert, sprechen wir von einer Ent-hält-Beziehung: Komponente k enthält h. Enthält-Beziehungen sind dauerhaft; Änderungen erforderneinen Eingriff in die enthaltende Komponente. Zykli-sche Enthält-Beziehungen gibt es nicht.

Bei jeder Benutzt-Beziehung ist zu ent-scheiden, wer die Verantwortung für die öffentliche Konfiguration der benutzten Komponente trägt: Sie kann liegen:a) bei der benutzten Komponente k odera) beim Aufrufer von k.

1.3.5 KomponentenhierarchieDie Enthält-Beziehung begegnet uns in zwei Varianten:a) Enthält-Beziehung Typ 1: Wir betrachten als Bei-

spiel eine Komponente k, die reguläre Ausdrückeverwendet, und sich dazu einer speziellen Biblio-thek (etwa gnuregexp) bedient. Der Benutzer vonk interessiert sich vermutlich nicht für reguläreAusdrücke, und deshalb ist die Verwendung von gnuregexp die Privatsache von k. k enthältgnuregexp, und gnuregexp ist in beliebig vielenKomponenten enthalten.

b) Enthält-Beziehung Typ 2: Oft macht es Sinn, meh-rere Komponenten k1, k2, .., kn zu einer einzigenKomponente k0 zusammenzufassen. Dann enthältk0 die Komponenten k1, k2, .., kn; der Benutzersieht nur noch die von k0 exportierten Schnittstel-len. k0 ist eine Fassade vor k1, k2, .., kn, die nurnoch diejenigen Operationen enthält, die außer-halb von k0 gebraucht werden, aber nicht mehrsolche, die nur zwischen k1, k2, .., kn Verwendungfinden.

3Java Virtual Machine

6

1.4 Schnittstellen im Detail

1.4.1 Callback-SchnittstellenJede Schnittstelle definiert Operationen; jede Opera-tion definiert Parameter. Spezielle Parameter sindCallback-Schnittstellen. Die JUnit-Schnittstelle Testist dafür ein Beispiel: Es gibt zahllose Klassen, dieTest implementieren. Das Paket java.util enthältviele kleine Schnittstellen (Comparable, Runnable,ActionListener und viele andere), die als Callback-Schnittstelle genutzt werden.

Callback-Schnittstellen sind eine Forderungder Schnittstelle an den Importeur: Der Importeurmuss die Callback-Schnittstelle implementieren, damitder Exporteur seine Arbeit tun kann. Dazu kann dieexportierende Komponente abstrakte Hilfsklassen lie-fern, die dem Importeur die Arbeit erleichtern (vgl.Template-Muster). Dabei ist es völlig unerheblich, obder Importeur von dieser Hilfestellung in Form einerabstrakten Klasse Gebrauch macht. Java-Beispiele sinddie AbstractList und das AppenderSkeleton (Log4J).

Callback-Schnittstellen haben einen völliganderen Charakter als die Nutzschnittstellen für dieFunktionen, um die es wirklich geht.

1.4.2 Schnittstellenkategorien,Adapter

Jede Schnittstelle gehört zu genau einer der Kate-gorien 0, A, T oder R: 0-Schnittstellen enthalten nurelementare Datentypen oder (in Java) die Standard-schnittstellen des SDK (wie List, Map). A-Schnitt-stellen enthalten zusätzlich fachliche Datentypen(wie ISBN) oder fachliche Schnittstellen (wie IKonto),aber keine fachlichen Klassen (also kein Konto). T-Schnittstellen enthalten technische Datentypenund technische Schnittstellen; Beispiele für R-Schnitt-

stellen sind aus einer IDL generierte Schnittstellenmit technischen Elementen (wie die Holder-Klassenvon CORBA).

Jeder Typ, der in einer Schnittstelle vor-kommt, erzeugt eine neue Abhängigkeit und machtdie Schnittstelle komplizierter. Deshalb unterschei-den wir innerhalb von A-Schnittstellen weitere Kate-gorien. Ein wichtiger Spezialfall ist die AF-Schnitt-stelle (F wie flach oder flat), die im Gegensatz zur A-Schnittstelle nur fachliche Datentypen enthält.

Noch restriktiver sind 0-Schnittstellen. Dortgibt es nur einfache Datentypen wie String und Integersowie Schlüssel-Wert-Paare. In der Regel wird man auchgängige Typen wie Date und Money zulassen, reguläreAusdrücke machen ebenfalls Sinn. Aber ISBN undFahrgestellnummer sind in 0-Schnittstellen verboten.

Beispiele:

/* A-Schnittstelle */interface ICheckIn {

public RC begin(IPassenger passenger, IFlight flight); ...

}

/* AF -Schnittstelle */interface ICheckIn {

public RC begin(PassengerId passenger, FlightId flight); ...

}

/* 0-Schnittstelle */interface ICheckIn {

public RC begin(Map passenger, Map flight); // Schlüssel und Wert vom Typ String...

}

Die A-Schnittstellen gibt es immer; sie werden zuerst entworfen. Hier kann es sinnvoll sein,dem Passenger oder dem Flight zwei Schnittstellenzu geben, z.B. eine RW-Schnittstelle für den internenGebrauch und eine RO-Schnittstelle für die Benut-zung außerhalb der heimischen Komponente. DerZugriff auf eine A-Schnittstelle ist technisch einfachund effizient, bedeutet aber eine enge Koppelung,denn der Importeur sieht die gesamte Datenwelt desExporteurs, und er hat Zugriff auf weitere Methoden(im Beispiel die von IPassenger und IFlight).

Dies ist nicht immer wünschenswert. Sobraucht man für Standarddialoge nur Schlüssel-Wert-Paare und ein paar Zusatzinformationen (wie Feld-länge). Deshalb kann man neben den A-Schnittstellenbei Bedarf auch die entsprechende 0-Schnittstelleanbieten, die durch einen einfachen Adapter imple-mentiert wird.

Abbildung 2: Callback-Schnittstellen

abstract classTimplements t

s

hk

t

Die Umsetzung von einer Schnittstellenkatego-rie auf die andere besorgen Adapter (vgl. Abbildung 3),die man nach Bedarf baut, und die man auch hinter-einander schalten kann. Wir nennen Adapter derBauart A2AF und AF2A Typadapter (vgl. Abbildung 3).

Technische Adapter (also A2T, T2A, AF2T,T2AF) gestatten es, eine A-Schnittstelle über CORBAoder COM anzusprechen: In Abbildung 3 liegt h3auf einem anderen Rechner als k; ein A2T-Adapterbildet s auf die technische (z.B. CORBA-) Schnittstelles’’ ab, CORBA übernimmt die Kommunikation, undein T2AF-Adapter transformiert s’’ zurück nach AF.

1.4.3 StützschnittstellenStützschnittstellen zeichnen sich dadurch aus, dassdie importierte Schnittstelle (das ist die Stützschnitt-stelle) mit Hilfe eines Stützadapters (Wrapper, gluecode) auf eine exportierte Schnittstelle abgebildetwird. Stützschnittstellen entkoppeln Importeur undExporteur optimal. Dies ist eine spezielle Form derlosen Koppelung.

Im einfachsten Fall – wenn nämlich impor-tierte und exportierte Schnittstelle übereinstimmen– besteht der Stützadapter aus einfachen Delega-tionsaufrufen.

In Abbildung 4 sind s1 und s2 Stützschnitt-stellen der Komponente k; a1 und a2 sind Stützadap-ter, die s1 und s2 auf s1’ bzw. s2’ abbilden. Hinweise:a) Stützschnittstellen stehen im Paket des Importeurs

(Java). So ist der Importeur ohne import-Anwei-sung auf irgendeine Implementierung kompilierbar.

b) Bei allgemein akzeptierten Schnittstellen (List,Map, TestListener) machen Stützschnittstellen keinen Sinn.

Stützschnittstellen sind u. a. für folgende Aufgabenbesonders geeignet:a) Datentransformation: Oft kennt der Importeur

andere Datenstrukturen als der Exporteur. In die-sem Fall sind Datentransformationen erforderlich,die weder beim Importeur noch beim Exporteurihren Platz haben. Diese Transformationen kannman hart codieren oder man kann Mechanismenwie XML und XSLT verwenden.

b) Anpassung (Customizing; maximale/minimaleSchnittstellen): Oft stehen Schnittstellen zur Verfügung, die wesentlich mehr leisten als manim Projekt eigentlich braucht. Das liegt in derNatur der Sache, denn jeder Hersteller und jedesNormierungsgremium ist bestrebt, möglichst alleEventualitäten zu berücksichtigen. Im Projektbraucht man aber oft nur einen Bruchteil der vorhandenen Funktionen. In einem solchen Fallwird die Stützschnittstelle nur die wirklichbenötigten Operationen anbieten; alle anderenbleiben hinter dem Stützadapter verborgen.

c) Behandlung von Notfällen: Damit befasst sich der nächste Abschnitt über den Komponenten-vertrag.

1.5 Komponenten im Detail

1.5.1 KomponentenvertragJeder Aufruf einer Operation einer Komponentekann aus zwei Gründen scheitern:a) Intern: Die Komponente befindet sich aufgrund

eines Programmierfehlers in einer inkonsistentenSituation.

a) Extern: Die Komponente befindet sich in einerinkonsistenten Situation, weil eine benutzte Komponente gescheitert ist.

Was sind konsistente und inkonsistente Situa-tionen? Konsistente Situationen sind solche, auf diedie Komponente vorbereitet ist, die sie erwartet, woklar ist, wie es weiter geht. Inkonsistente Situationensind aus Sicht der betroffenen Komponente ausweg-los, nicht korrigierbar, nicht vorgesehen. Die zentraleForderung dieses Abschnitts lautet: Unterscheidestrikt zwischen konsistenten und inkonsistenten Situa-tionen. Die weiter unten vorgestellte Emergency-Klas-se ist eine mögliche Implementierung dieser Idee.

h1 h2 h3

k

s‘ A2AF s A2T s‘‘ T2AF s‘

s eine A-Schnittstelle A2AF Adapter A nach AFs‘ s als AF-Schnittstelle A2T Adapter A nach Ts‘‘ s als T-Schnittstelle T2AF Adapter T nach AF

h1, h3 sind lose an k gekoppelt, h2 ist eng an k gekoppelt

s‘‘

Konfiguration

k

t1

t2

s1

s2

a1

a2

s1‘

s2‘

h1

h2

Das alles gehört k und das h2 und das h1

Abbildung 3: Schnittstellen-Kate-gorien und Adapter

Abbildung 4: Stützschnittstellen undStützadapter

8

Bei inkonsistenten Situationen hat die Kom-ponente das Recht die Arbeit einzustellen, ja sie hatkeine andere Wahl. Das heißt aber nicht, dass sie einfach abstürzt, sondern es gibt eine Notfall-Behand-lung für Aufräumarbeiten und Protokollierung. Inso-fern sind auch inkonsistente Situationen nicht gänz-lich unerwartet. Ein Vergleich mit dem Auto: JederAutofahrer stellt sich darauf ein, dass er gelegentlichtanken muss (konsistent). Nach dem Tanken kann erganz normal weiterfahren. Höchst unerwünscht undgottlob auch selten sind Autounfälle (inkonsistent).Dafür gibt es den Airbag (EmergencyHandling), der hoffentlich das Schlimmste verhütet. Nach einemUnfall kann man bestenfalls in einem Ersatzautooder mit dem Taxi weiterfahren.

Der Grundsatz lautet also: Jede Komponen-te hat ein Notverfahren (EmergencyHandler), dassich um Schadensbegrenzung und Protokollierungkümmert. Tabelle 1 zeigt den Zusammenhang: Normalerweise gibt es nur erkannte konsistenteSituationen. Nicht erkannte konsistente Situationengibt es nicht. Erkannte Inkonsistenzen landen imNotverfahren, nicht erkannte Inkonsistenzen führenzum Absturz des Systems, und dies wäre eine echteKatastrophe. Es geht also darum, Notfälle möglichstflächendeckend zu erkennen.

erkannt nicht erkannt

konsistent normaler Ablauf gibt es nicht

inkonsistent Notverfahren Absturz

Tabelle 1: Konsistente und inkonsistente Situationen

Runtime-Ausnahmen in Java sind Beispielefür Situationen, die immer als inkonsistent betrachtetwerden: Ausnahmen wie ClassCastException oderIndexOutOfBoundsExcpetion sind die Folge eines zurLaufzeit irreparablen Programmierfehlers. Grund-sätzlich ist jeder Programmierfehler ein Notfall.

Der Softwarearchitekt legt fest, ob einebestimmte Situation konsistent oder inkonsistent ist.Das Standardbeispiel ist der Zugriff auf ein Nachbar-system, das u. U. nicht verfügbar ist. Hier hat manzwei Möglichkeiten:a) Die Nicht-Verfügbarkeit des Nachbarsystems ist

inkonsistent. Dann hat das eigene System dasRecht, die Arbeit einzustellen.

b) Die Nicht-Verfügbarkeit des Nachbarsystems istkonsistent. Dann muss das eigene System weiter-laufen, evtl. im Notbetrieb. In diesem Fall ist dieNicht-Verfügbarkeit vorgesehen und vorbereitet.

Offensichtlich ist die zweite Möglichkeitwesentlich teurer als die erste, und deshalb ist dieEntscheidung konsistent vs. inkonsistent eine wich-tige Weichenstellung für das Projekt.

Die Begriffe konsistent/inkonsistent sindAnlass für zahlreiche Missverständnisse. Daher nochfolgende Hinweise:a) Die Unterscheidung konsistent/inkonsistent hat

mit dem Begriff des Fehlers nichts zu tun. Benut-zer machen bei der Eingabe selbstverständlichFehler, aber diese Fehler sind vorgesehen, das Ver-halten bei Fehleingaben ist spezifiziert und des-halb sind Benutzerfehler konsistent. Ähnlichesgilt auch für die Kommunikation mit Nachbarsys-temen: Nachbarsysteme haben in aller Regelandere Vorstellungen von Datenintegrität, unddeshalb wird man sich auf fehlerhafte Daten vonNachbarsystemen einstellen.

b) Der Systemfehler bei [Denert 1991] ist in unsererTerminologie die erkannte Inkonsistenz.

c) Der Notfall ist nicht zu verwechseln mit der Assertion z.B. in Java 1.4 oder in Python. Asser-tions werden für Prüfungen verwendet, die nur fürDebug-Zwecke vorgesehen sind und in der Pro-duktion ausgeschaltet werden. Unsere Idee istausdrücklich, dass Notfälle auch in der Produktionbehandelt werden. Anmerkung: Viele Assertionsrealer Programme sind in Wirklichkeit Notfälle.

Das Zusammenspiel von Importeur undExporteur unterliegt also den folgenden Regeln:

1. Der Importeur rechnet damit, dass die benutzteKomponente scheitert. Er kann sich aber darauf ver-lassen, dass die benutzte Komponente im Fall desScheiterns ihr eigenes Notverfahren aufgerufen hat.Aufräumarbeiten und Protokollierung haben alsostattgefunden.

2. Der Importeur entscheidet, ob er diese Situation alskonsistent oder inkonsistent betrachtet. Im erstenFall geht der Ablauf ganz normal weiter (das nenntman Deeskalation). Im zweiten Fall befindet sich derImporteur selbst in einer inkonsistenten Situation: Er ruft sein eigenes Notverfahren auf und überlässtder nächsten Instanz die Entscheidung darüber wiees weitergeht (das nennt man Propagation).

Als Beispiel betrachten wir das Zusammen-spiel von Anwendungskern und Batch-Steuerung:Die Batch-Steuerung beauftragt den Anwendungs-kern mit der Bearbeitung eines fachlichen Objekts.Wenn der Anwendungskern einen Notfall erkennt,wird die Batch-Steuerung die laufende Transaktionzurücksetzen und am nächstmöglichen Punkt aufset-zen (Deeskalation).

Der Stützadapter ist – falls vorhanden – die geeignete Stelle, um inkonsistente Situationenbenutzter Komponenten zu behandeln.

Notfälle in JavaDie Diskussion über Java-Ausnahmen im Allgemeinenund ungeprüfte Ausnahmen (unchecked exceptions)im Speziellen ist mittlerweile etwas ermüdend.

9

Immerhin scheint in zwei Punkten Konsens zu bestehen:a) Ausnahmen gleich welcher Art werden nur aus-

nahmsweise geworfen (exceptions are exceptional).a) Ungeprüfte Ausnahmen sind immer dann ange-

messen, wenn der Aufrufer nicht mehr vernünftigreagieren kann.

Daher schlagen wir vor, Notfälle in der hierbeschriebenen Bedeutung mithilfe einer von Runtime-Exception abgeleiteten Ausnahme zu signalisieren:

public class EmergencyException extends RuntimeException { }

Das Notverfahren steckt in einer komponentenspezi-fischen Klasse:

public class Emergency {public static void ifTrue(boolean b, String info) {

if (b) handle(info);}

public static void ifNull(Object x, String info) { if (null == x) handle(info);

}

...private static void handle(String info) {

// Aufraeumarbeiten// Protokollierungthrow new EmergencyException(info);

}

}

Im Anwendungscode würde das etwa so aussehen:

public void foo() {...Account a = (Account) db.get(...);Emergency.ifNull(a, “no account“);...

}

Auf diese Weise erkennt man sofort, welcheSituationen der Programmierer als inkonsistent be-trachtet. In seltenen Fällen wird man von Emergency-Exception noch einige wenige weitere komponenten-spezifische Ausnahmeklassen ableiten, um verschie-dene Notfall-Möglichkeiten zu unterscheiden.

Abbildung 5 zeigt das Zusammenspiel: Kom-ponente h2 ruft in inkonsistenten Situationen ihreigenes Notverfahren. Dort geschieht das Nötige;eine Ausnahme wird an den Stützadapter a2 weiter-gereicht. Dieser kann – wenn er es für richtig hält –die Situation als inkonsistent betrachten und an dasNotverfahren des Importeurs weitergeben.

Hinweis: Wir machen an dieser Stelle keine Aussage zurBehandlung von konsistenten Situationen (Ausnah-men, Returncodes, ...). Wichtig ist nur, dass man Java-(oder sonstige) Ausnahmen auf der einen Seite undinkonsistente Situationen auf der anderen Seitegenau auseinander hält.

1.5.2 Wie beschreibt man Komponenten?

Das geschieht von außen nach innen: Zuerst dieÜbersicht, dann die Außensicht, dann die Innensichtund schließlich die Variabilitätsanalyse.

Übersicht: Zu jeder Komponente gibt es eineIdee, die man auf ein bis zwei Seiten darstellen kann.Das ist die Sicht des Managements: Die Komponente,die ja Geld kostet, stiftet einen Nutzen, und das istdarzustellen. Ohne Idee keine Komponente.

Außensicht: Hier werden die Schnittstellender Komponente beschrieben. Die Außensicht rich-tet sich an die späteren Nutzer der Komponente (dasbetrifft Dialog-Benutzer genauso wie Anwendungs-programmierer). Die Außensicht wird geschriebenwie ein Benutzerhandbuch: Was muss der Benutzertun, was mute ich ihm zu, welche Arbeit nehme ichihm ab? Die Außensicht ist der wichtigste Teil derDokumentation, denn sie hat mit Abstand die mei-sten Leser. Die vom Benutzer zu leistende, alsoöffentliche Konfiguration gehört zur Außensicht.

Ein wichtiger, oft vernachlässigter Benutzerist der Betrieb. Komponenten wie DB-Zugriff oderBatch-Steuerung haben breite Schnittstellen zumBetrieb. Die Beschreibung dieser Schnittstellen istBestandteil der Außensicht.

Konfiguration

k

t1

t2

s1

s2

a1

a2

s1‘

s2‘

h1

h2

Emergency HdlEmergency Hdl

Abbildung 5: Komponenten undNotverfahren

10

1.6 Weitere Begriffe

1.6.1 ModulDie Komponente hat den Modul als Begriff weit-gehend verdrängt. „Modul“ bedeutet zweierlei:a) [Denert 1991]: eine atomare Komponente

(also nicht weiter sinnvoll teilbar)b) Netbeans: eine Komponente, die dynamisch einem

bestehenden System zugeordnet werden kann.In diesem Papier wird der Begriff „Modul“ nicht weiter verwendet.

1.6.2 BausteinDie strikte Trennung von Schnittstelle und Implemen-tierung wird in der Praxis nicht immer eingehalten.So sind die meisten real existierenden Zugriffsschich-ten – leider – meist so gebaut, dass der Austauschder Implementierung auf ein Reengineering-Projekthinausläuft. Deshalb brauchen wir einen Namen fürSoftware-Stücke, die zwar irgendwie zusammen-gehören, aber aus guten oder schlechten Gründendie Kriterien für einen Modul oder eine Komponentenicht erfüllen: So etwas nennen wir Baustein.

1.6.3 Schichten, Layer, TierAls Schicht bezeichnen wir eine Menge von gleicharti-gen Komponenten. So bilden alle A-Komponenteneines Systems (vgl. Abschnitt 4) die Anwendungs-schicht (oder Anwendungskern). Der Begriff Layer istdie englische Übersetzung von Schicht; beide Begrif-fe bedeuten genau dasselbe, und beide haben nichtszu tun mit der Verteilung von Software auf verschie-dene Rechner. Damit befassen sich die Tiers (deutsch:Rechnerstufe): In einer Drei-Tier-Architektur z.B. gibt es drei Ebenen von Rechnern: die GUI-Clients,den oder die Anwendungsrechner sowie den oderdie Datenbankrechner.

Innensicht: Sie beschreibt den inneren Auf-bau der Komponente und richtet sich an die Entwick-ler der Komponente bzw. das Wartungsteam. DieInnensicht ist austauschbar. Deshalb hat sie eingeringeres Gewicht als die Außensicht. Es ist nichterforderlich, alle Erwägungen, die zu einer bestimm-ten Implementierung geführt haben, und alle Irrwe-ge, die man verworfen hat, in 500-seitigen Wälzernfestzuhalten. Die Enthält-Beziehungen gehören zurInnensicht.

Variabilitätsanalyse: Software ist flexibel,wartbar und änderungsfreundlich – das behauptenalle Software-Hersteller. Aber wie kann man dieseEigenschaften belegen? Das tut man mit Hilfe vonÄnderungsszenarien. Jeder Software-Architekt solltesich eine sinnvolle Anzahl von Szenarien ausdenkenund durchspielen. Dabei sind technische Änderun-gen interessant (etwa der Wechsel von CORBA zuSOAP), aber auch fachliche (eine geändertes Ver-fahren der Rechnungsstellung). Bei jedem Szenariosind drei Antworten möglich:

a) Die Änderung ist vorbereitet; sie lässt sich ohne nennenswerten Aufwand durchführen (etwa durch geeignete Parametrierung).

b) Die Änderung ist konform zur vorhandenen Archi-tektur, erfordert aber ein gewisses, planbares Maß an Umbauten (bei unseren Zugriffsschichtengehört der Wechsel des DBMS normalerweise zudieser Kategorie).

c) Die Änderung ist nicht konform zur vorhandenenArchitektur; sie erfordert den Neubau oder denUmbau der ganzen Komponenten.

Ein solcher Szenarienkatalog macht dieEigenschaft Änderbarkeit noch lange nicht messbar,aber er ist eine gute Basis bei der Suche nach derangemessenen Architektur.

11

● Neben der A-Architektur besitzt jedes Informati-onssystem eine Technikarchitektur (T-Architektur),die den sachgemäßen Umgang mit der Techniksicherstellt. Die T-Architektur beschreibt all die-jenigen Komponenten eines Systems, die von derAnwendung unabhängig sind: Zugriffsschicht,GUI-Rahmen, Fehlerbehandlung und anderesmehr. Die T-Architektur verbindet die A-Architek-tur mit der TI-Architektur; die T-Software ist dieAblaufumgebung für die A-Software.

Jedes System hat seine Systemarchitektur,und die A-, T- und TI-Architekturen sind verschie-dene Sichten darauf. Die A-Architektur wird in jedemProjekt eigens entwickelt – Wiederverwendung aufder A-Ebene ist bei sd&m die Ausnahme: sd&m hatbestimmt schon über hundert Kundenverwaltungengebaut, aber es scheint wenig aussichtsreich zu sein,daraus eine wieder verwendbare Standard-A-Archi-tektur zu destillieren. Anders verhält es sich bei denallgemeinen Entwurfsprinzipien und bei der T-Archi-tektur: Hier wollen wir Standards setzen, denn es ist nicht erforderlich, in jedem Projekt eine eigeneZugriffsschicht und ein eigenes GUI-Framework zu erfinden. Diese Standards sind auf zwei Ebenenfestgelegt:

a) Die Quasar-Standardarchitektur (oder kurz Stan-dardarchitektur) ist die Vorlage für alle sd&m-Pro-jekte. Sie besteht aus der Windmühle als Verall-gemeinerung der konventionellen Schichtenarchi-tektur (Kapitel 3) und den Standardarchitekturenfür Anwendungskern (Kapitel 4), Transaktionen(Kapitel 5), Persistenz (Kapitel 6), GraphischeOberflächen (Kapitel 7), Verteilte Verarbeitung(Kapitel 8) und schließlich für Basisdienste wieFehlerbehandlung und Berechtigung. Dort stehendie ewigen Wahrheiten, die – so hoffen die Autoren – für alle Anwendungen und für alle TI-Architekturen richtig sind. Sie ist die sd&m-Prä-zisierung der bekannten Drei-Schichten-Architek-tur, die sich ähnlich flächendeckend eingebürgerthat wie die Aufteilung in Lexer und Parser bei den Compilern.

b) Standard-T-Architekturen für Standard-TI-Archi-tekturen (z.B. EJB-Server, .NET). Diese Standard-T-Architekturen sind zu verstehen als vorgefertigteKonstruktionsbausteine, die in jedem Projekt mit passender TI-Architektur unverändert oderangepasst einsetzbar sind. Standard-T-Architektu-ren lohnen sich nicht für exotische Umgebungen– Projekte, die solche Umgebungen verwenden,können sich aber an vorhandenen Standard-T-Architekturen orientieren.

Standardarchitektur und Standard-T-Archi-tekturen sind gedacht als Vorlage und Muster fürInformationssysteme bei sd&m und beschreiben dieArchitektur soweit, wie man das unabhängig von der jeweiligen Anwendung überhaupt tun kann. Im

2 Architekturbegriffe

4Dynamic Link Library

2.1 Übersicht

Wir benutzen verschiedene Architekturbegriffe:Systemarchitektur, Softwarearchitektur, Anwen-dungsarchitektur, Facharchitektur, Schichtenarchitek-tur u. v. a. m. In diesem Kapitel versuchen wir, eineinheitliches Verständnis dieser Begriffe herzustellen.

Ein Informationssystem oder kurz System istein sinnvolles Ganzes, das der Anwender als techni-sche und fachliche Einheit begreift. Wir meinen damitsowohl betriebliche Informationssysteme (die alsonur von Mitarbeitern eines Unternehmens genutztwerden) als auch überbetriebliche Informationssys-teme (das schließt ein B2B, B2C, C2B). Den BegriffSubsystem verwenden wir informell für Teile einesSystems, die man etwa zum Zweck der Integrationoder der Einführung bildet. Subsysteme können überalle Schichten gehen, aber das muss nicht so sein.

Die Systemarchitektur, also die Architektureines Informationssystems, kann man aus verschie-denen Winkeln betrachten:● Die Architektur der technischen Infrastruktur

(TI-Architektur) beschreibt die technische Infra-struktur des Informationssystems. Dazu gehörendie physischen Geräte (Rechner, Netzleitungen,Drucker etc.), die darauf installierte System-Software(Betriebssystem, Transaktionsmonitor, Applica-tion-Server, Verbindungssoftware) und das Zusam-menspiel von Hardware und System-Software. DieTI-Architektur definiert auch die verwendete(n)Programmiersprache(n).

● Die Software-Architektur beschreibt die Strukturendes Software-Systems, d.h. die Komponenten, aus denen das System besteht und deren Zusam-menspiel. Sie existiert in verschiedenen Ebenender Konkretion, die jeweils eigene Darstellungsele-mente besitzen: von Komponenten, Klassen undSchnittstellen bis hin zu Dateien und DLLs4. Jededieser Ebenen kann Details zeigen oder unter-drücken.

Innerhalb der Software-Architektur unter-scheiden wir zwei Sichten:● Die Anwendungsarchitektur (A-Architektur) struk-

turiert die Software aus der Sicht der Anwendung.So besitzt ein Reisebuchungssystem einen Kata-logverwalter, eine Buchungsmaschine, einen Preis-rechner und andere Anwendungskomponenten.Worauf es ankommt: Die Funktionen und dasZusammenspiel dieser Komponenten entwirft manohne jeden Bezug zu Technik, aber in genauerKenntnis der fachlichen Abläufe – ungefähr so,wie man auch das Zusammenwirken von mensch-lichen Sachbearbeitern organisieren würde. Beider A-Architektur macht man sich frei von techni-schen, produktbezogenen Sachzwängen.

12

2.2 TI-Architektur

Die TI-Architektur entsteht in mehreren Schritten:● Man beginnt mit den Grundfragen: Browser-Ober-

fläche oder Fat Client? Client-Server-System oderGroßrechner? Application Server ja oder nein?

● Dann beschreibt man Hardware und Systemsoft-ware, zunächst ohne konkrete Produkte und Produktversionen: Rechner, Verbindungen (auf derEbene Unix-Anwendungsserver, Mainframe, PC,LAN, WAN) und Systemsoftware (EJB ApplicationServer, Browser, CORBA, CICS). Schließlich präzisiert man – je nach Situation – Anzahl der Prozessoren, Cluster, Platten- und Speicherbedarf, Firewalls etc.

● Zum Schluss bestimmt man die technischen Komponenten bis zur Versionsnummer und zumPatchlevel. etc.

Abbildung 7 zeigt ein Beispiel einer TI-Archi-tektur. Die Notation verwendet boxes and arrows5.

Im Rahmen der TI-Architektur werden diezentralen Probleme des Betriebs behandelt:● Verfügbarkeit● Sicherungen● Versionswechsel● Verhalten beim Ausfall einer Komponente● Lastverteilung● Clusterfähigkeit usw.

Diese Probleme werden entweder von deneingesetzten Produkten selbst gelöst, oder sie werden als Anforderung an die T-Architektur weitergereicht und dort erledigt, denn es kann nicht sein,dass man beim Entwurf einer Anwendungsklasse(z.B. Konto) an Lastverteilung denken muss.

2.3 A-Architektur

Die A-Architektur ist die Architektur der Anwen-dung. Sie beschreibt die anwendungsspezifischenBestandteile des Systems, deren Schnittstellen undBeziehungen (also z.B. Kunde und Konto). Sie abstra-hiert von technischen Details und von 0-Software.Die A-Architektur entsteht in drei Schritten:a) Übersicht: Im ersten Schritt legt man die A-Kom-

ponenten fest und beschreibt für jede A-Kompo-nente, was sie leistet und welche Daten sie ver-waltet. Das in der Spezifikation erstellte Daten-modell ist eine wichtige Vorgabe.

b) Außensicht: Im zweiten Schritt definiert man dieSchnittstellen der A-Komponente auf der Ebenevon Operationen. Dies geschieht bereits in derZielsprache (z.B. Java).

PCU

nix-

ode

r NT-

Rech

ner

Uni

x- o

der N

T-Re

chne

r

Datenbank

Legende

Protokoll

Maschine

Software-Baustein

Nachbarsystem

DB2 V 6.1

Browser

http

Web-Server/ServletEngine(Servlet 2.2, JSP 1.1)

Präsentations-Dialogschicht

Präsentationsmodell

RMI

Application ServerBEA WebLogic Server 5.1

Anwendungskern(A-Fälle und A-Entitäten)

Trägersystem

Nachbarsystemxyz

Corba

Abbildung 7: TI-Architektur (Beispiel)

5 Wir arbeiten an einemStandard

konkreten Projekt wird diese Vorlage für die gegebeneTI-Architektur und die fachlichen Anforderungenangepasst. Dies illustriert Abbildung 6.

Eine projektspezifische T-Architektur kannStandardarchitektur und Standard-T-Architekturen inpassender Technologie als Vorlage nutzen oder sogarCode wieder verwenden.

Anmerkung: Neben den reinen A- bzw. T-Darstellungen sindArchitekturbilder, die A- und T-Elemente in ihremZusammenwirken zeigen, selbstverständlich erlaubtund sinnvoll.

Quasar

Standard-T-Architekturen

Standard-TI-Architekturen

Systemarchitektur

beeinflusst

Vorgabe

Spezifikation T-ArchitekturA-Architektur TI-Architektur

Standardarchitekturen• Anwendungskern• Transaktionen• Persistenz• GUI• Verteilte Verarbeitung

Abbildung 6: Zusammenspiel der ver-schiedenen Architekturen

13

c) Innensicht: Schließlich überlegt man sich, mit wel-chen Klassen die A-Komponente realisiert wird.Dabei verlässt man sich darauf, dass die T-Kompo-nenten die von Quasar definierten 0-Schnittstel-len implementieren.

T-Architektur und2.4 Standard-T-Architektur

Vorgabe für die T-Architektur sind die Standard-architekturen für Transaktionen, Persistenz, GUI undVerteilung. Diese Dinge sind in (fast) jedem Projektzu erledigen; andere, bisher von Quasar nicht be-handelten Themen (etwa Batch) kommen möglicher-weise hinzu. Die T-Architektur entsteht im Prinzipgenauso wie die A-Architektur: Übersicht, Außen-sicht, Innensicht. Trotzdem gibt es einen wichtigenUnterschied: Während die A-Architektur für jedesProjekt im Wesentlichen neu erfunden wird, schautdie T-Architektur immer wieder gleich aus: Siebesteht aus einigen Standardkomponenten wie Zu-griffsschicht, die immer wieder nach denselben Prinzipien gebaut werden, und immer wieder diesel-ben 0-Schnittstellen implementieren. Im Idealfallreduziert sich die Erstellung der T-Architektur auf dieAuswahl einer passenden Standard-T-Architektur,doch im Allgemeinen sind mehr oder weniger großeAnpassungen nötig.

Abbildung 8 zeigt die T-Architektur für einenWeb-Client auf Ebene von Komponenten.

2.5 Entwicklungsprozess

Die Architektur eines Systems entsteht in mehrerenSchritten (vgl. Abbildung 9):

Ein Projekt bearbeitet zunächst die A-Archi-tektur: Anforderungen werden gesammelt; eineerste Zerlegung in Subsysteme und eine Analyse derNachbarsysteme ergeben die grobe A-Architektur.Auf dieser Basis gestaltet man im Rahmen der Frei-heitsgrade des Projekts die TI-Architektur.

Aufbauend auf diesen beiden Ergebnissenund ausgehend von der Quasar-Standardarchitekturbeginnt nun die Arbeit an der projektspezifischen T-Architektur. Abstrahierend von konkreten Anwen-dungselementen werden Schichten und Komponen-ten bis hin zu Klassen verfeinert und Schnittstellendefiniert. Die Detaillierung dieser Sicht wird durchdie weiter fortschreitende Arbeit an der A-Architek-tur beeinflusst und mündet in die Ausarbeitung von0/T-Komponenten.

Anwendungs-kern Anwendungsfall

Präsentations-modell

Dialog

Http-Request

forward Layout ServletsServlet

Aufruf

erstellt

AnwendungsfallAnwendungsfall

Http-ResponseuseBean

In-ServletServlet

Out-JSPJSP

Legende

Komponenten

Schicht

Dialog-Controller

Kommunikator PM-Ergebnis

Java-Bean

<<Bean>Java-Bean

Präsentation

verwaltet &wertet aus

Liest Beans ausund stellt siein Request ein

ruft

valueobjects

PmEingabePmErgebnis

Abbildung 8: T-Architektur (Beispiel)

A-Architektur grobAnforderungen

TeilsystemNachbarsysteme

SpezifikationAnwendungsfälle

DatenmodellDialogspezifikation

etc.

Teilsysteme,Komponenten,Schnittstellen,

Klassen/Module

A-Komponenten

Zeit T-Architektur TI-ArchitekturA-Architektur

Standard-(T)-Architektur als

Fundgrube

Pakete, DLLs,Programmier-

sprachendateien

SchichtenKomponenten

Klassen/Module

Pakete, DLLs,Programmier-

sprachendateien

Auswahleiner geeigneten

Technologie

logischer Rechner,Netze,

Trägersysteme

konkrete technischeProdukte

T-Komponenten

Abbildung 9: Architektur im Zeitverlauf

14

Die Quasar-Windmühle zeigt das Zusammenspiel des Anwendungskerns mit den umgebenden Kompo-nenten: Wohl jede Anwendung benutzt ein Daten-banksystem und eine GUI-Bibliothek, kommuniziertmit Nachbarsystemen und versorgt evtl. ein Data-Warehouse. Diese umgebenden Komponenten nennenwir Partner oder die Flügel der Windmühle.

Diese Partner sollen den Anwendungskernmöglichst wenig beeinflussen, denn er ist für sichallein schon kompliziert genug. Die zusätzliche Kom-plexität, die jeder Partner verursacht, wird an genaueiner Stelle behandelt. Der Anwendungskern kom-muniziert mit seinen Partnern (den Flügeln) übereinen zweistufigen Mechanismus: Außen sitzt einExperte (z.B. für die Datenbank), der für den jeweili-ge Partner geschrieben ist. Eine eigene Komponentevermittelt zwischen der Anwendung und dem Experten. Deren wichtigste Aufgabe ist die Transfor-mation der Datentypen (vgl. Abschnitt 4.3). So lebtjeder Windmühlenflügel in seiner eigenen Daten-welt. Die Transformation wird im besten Fall durchMetainformationen gesteuert; in diesem Fall wird siedurch eine 0-Komponente implementiert (wie in der Abbildung angegeben). Wenn dies nicht möglichist, dann ist die Transformation vom Typ R.

Die Windmühle zeigt nur einen bestimmtenAspekt der Standardarchitektur, nämlich die Kom-munikation der Anwendung mit ihren Partnern. Dasklassische Schichtenmodell ist ein Spezialfall derWindmühle mit nur zwei Partnern, dem GUI und derDatenbank.

Die von sd&m Research gelieferten Quasar-Komponenten sind selbstverständlich quasar-kon-form. Dies ist eine Sammlung von weitgehend unab-hängig voneinander nutzbarer Komponenten, diekonsequent über Stützschnittstellen kommunizieren.Abbildung 11 zeigt eine mögliche Konfiguration. Derdargestellte Fall zeigt eine komplexe T-Architektur,in der auch Dienste eines typischen Application Ser-vers (Transaktionen, Sessions und Kommunikation)von eigenen Komponenten übernommen werden. Essind eine ganze Reihe von Abhängigkeiten zwischenden Komponenten zu erkennen, die alle über Stütz-schnittstellen ausgeführt sind und damit im Rahmender Konfiguration bestimmt werden. In der vorlie-genden Konfiguration arbeitet die Persistenzkompo-nente mit der Berechtigungskomponente zusam-men, um nicht autorisierte Zugriffe auf A-Entitätenzu unterbinden.

Wenn in einem Projekt diese Funktion nichtverlangt ist, dann wird die entsprechende Stütz-schnittstelle leer implementiert.

Auch stellt sich z.B. eine Abhängigkeit zueinem Transaktionsverwalter und damit die ent-sprechende Stützschnittstelle vollständig anders dar,wenn als Laufzeitumgebung ein J2EE Application-Server gewählt wird.

Die Komponenten der obersten Ebene definieren die Struktur des Gesamtsystems: DiesesBild haben alle Projektmitglieder im Kopf; es hängtüber allen Schreibtischen. Komponenten bestehen inder Regel (und auf der obersten Ebene wohl immer)aus Subkomponenten. Es ist wichtig, die richtigeDarstellungsebene zu finden: So bestehen alle Kom-ponenten von Abbildung 11 ihrerseits aus Subkom-ponenten.

3 Quasar-Windmühle

A-SoftwareO-SoftwareT-SoftwareR-Software

NBSystem

-Expert

MFC-Expert

QUI

Anwendung=

A-Fälle+

A-Entitäten

QDI

OracleOCI

Berechti-gungs-System

Workflow Nachbar-system1

Nachbar-system2

NBSystem

-Expert

GUI(e.g. MFC)

OCI-Expert

BusinessComponent

View

Die Beziehungen zwischen Komponenten inverschiedenen SubSystemen werden über Stütz-schnittstellen ausgeführt und stellen damit keinezwingende, sondern eine mögliche Integration dar.

BusinessComponent stellt ein Repository für die Elemente des Anwendungskernsdar, d.h. strukturiert A-Komponenten, A-Fälle, A-Entitätstypen, etc. Diese verwendendann die Schnittstellen der gezeigten T-Architektur für die Erbringung ihrer Dienste.

User Interface

Component

Communication

Channel

ProxyViewServer

ModelView ModelViewServer

Validation

Rules Persistence

Author-ization

Session

Transaction

Portal

Model-based User Interface

15Abbildung 11: Eine komponentenorien-tierte T-Architektur

Abbildung 10:Die Quasar-Windmühle

16

Jeder A-Entitätstyp ist genau einer A-Kom-ponente zugeordnet, genauso jeder A-Verwalter. JederA-Verwalter verwaltet mindestens einen A-Entitäts-typ; jeder A-Fall gehört zu genau einer A-Komponen-te. Die A-Fälle regeln den Zugang zu den A-Entitäts-typen und den A-Verwaltern; nur in ganz trivialenFällen sind A-Fälle entbehrlich.

Die Schnittstelle einer jeden A-Komponenteist die Vereinigung der Schnittstellen ihrer A-Fälle,eventuell erweitert um Schnittstellen von A-Entitäts-typen bzw. A-Verwaltern. A-Komponenten können –wie im Beispiel die A-Komponente 1 – ohne weiteresauch nur aus A-Fällen bestehen; in diesem Fall wirddie eigentliche Arbeit an andere A-Komponentendelegiert.

A-Komponenten können sich gegenseitigaufrufen, und zwar über die jeweiligen Schnitt-stellen. Die A-Datentypen sind in dem Bild nicht dar-gestellt; mit ihnen befasst sich der Abschnitt 4.3.

Anmerkungen:a) Wir erinnern daran, dass jede Komponente eine

oder mehrere Schnittstellen exportiert. Typisch istdie Trennung in Erzeuger- und Verbraucher-Schnittstelle: Die Erzeuger-Schnittstelle enthältdie Operationen zum Pflegen der Daten, alsoletztlich Einfügen, Ändern, Löschen. Die Verbrau-cher-Schnittstelle enthält die Lese-Operationenund die Abfragen.

b) Schnittstellen von Komponenten sind zunächst A-Schnittstellen: Sie können also selbst wiederSchnittstellen wie IPassenger oder IFlight enthal-ten. Bei enger Koppelung stehen also auchSchnittstellen von A-Entitätstypen zur Verfügung.Bei loser Koppelung (Schnittstelle nur noch vom Typ AF oder 0) ist das nicht mehr der Fall (vgl. hierzu Abschnitt 1.4.2).

c) Komponentenübergreifende Kommunikationläuft grundsätzlich über Schnittstellen. Diese sindin Abbildung 12 aus Gründen der Übersichtlich-keit nicht eingezeichnet.

d) Aus technischen Gründen gibt es in der Regel einentechnischen Verwalter, der den Zugang zu denbenötigten A-Komponenten herstellt. Auch dieserVerwalter ist in Abbildung 12 nicht dargestellt.

Außensicht von4.2 A-Komponenten

A-Komponenten werden ausschließlich über Schnitt-stellen angesprochen. Implementierte A-Entitäts-typen sind an den Schnittstellen niemals sichtbar.Das heißt z.B., dass man A-Entitäten von außen nurüber Fabrik-Methoden wie „anlegen“, „erzeugen“konstruiert, niemals über den direkten Aufruf einesKonstruktors. A-Entitätstypen derselben Komponen-te rufen sich direkt (also ohne Schnittstelle).

4 Standardarchitektur des Anwendungskerns

GUI, Batch, Nachbarsysteme

A-Komponente 1

A-Fall 1

A-Fall 3A-Fall 1 A-Fall 1

A-Verwalter+

A-Entitätstypen

Anwendungskern = A-Fälle + A-Entitätstypen + A-Verwalter

A-Komponente 3A-Komponente 2

A-Fall 2

A-Verwalter+

A-Entitätstypen

A-Verwalter+

A-Entitätstypen

A-Fall 2 A-Fall 3A-Fall 2

A-Verwalter+

A-Entitätstypen

Abbildung 12: Standardarchitektur des Anwendungskerns

4.1 Einführung

Dieses Kapitel beschreibt die Nabe der Windmühle:den Anwendungskern mit seinen Schnittstellen. Wir befassen uns nur am Rande mit der Architekturder Bedienoberfläche und des Datenbankzugriffs,sondern tun so, als gäbe es nichts außerhalb desAnwendungskerns. Dessen wichtigste Elemente sind:1. Anwendungsdatentyp (A-Datentyp)2. Anwendungs-Entitätstyp (A-Entitätstyp) 3. Anwendungs-Entitätstyp-Verwalter (A-Verwalter)4. Anwendungsfall (A-Fall) 5. Anwendungskomponente (A-Komponente) 6. Anwendungstransaktion (A-Transaktion)

Diese Elemente werden zum Teil bereits inder Spezifikation vorbereitet. Bei der Ausarbeitungder A-Architektur auf Ebene von Klassen undSchnittstellen werden sie anwendungsspezifisch prä-zisiert. Abbildung 12 zeigt das Zusammenspiel zwischen diesen Elementen:

Wir erläutern Abbildung 12 zunächst kompakt und im Überblick; weitere Informationen zuden A-Begriffen liefern die folgenden Abschnitte.

Jede Anwendung besteht aus mindestenseiner A-Komponente. Typische A-Komponenten sind z.B. „Lagerhaltung“ und „Inventur“, „Rechnungs-stellung“ und „Inkasso“.

17

Hinweis: Man gestalte die Paketstruktur so, dass der Impor-teur nur die Schnittstellen sieht und nicht die Imple-mentierung.

Der Standard-Zugang zur A-Komponentenist der A-Fall. Beispiel: Der A-Fall Check-In hat z.B. die Operationen „beginne-Check-In-Vorgang“,„reserviere-Sitzplatz“, „setze-auf-Warteliste“. Derdirekte Zugang von außen zu einem A-Entitätstypoder einem A-Verwalter funktioniert nur bei engerKoppelung: Die A-Schnittstellen der A-Fälle könnenSchnittstellen von A-Entitätstypen und A-Verwal-tern enthalten.

Jede Schnittstelle ist also entweder dieSchnittstelle eines A-Falls, eines A-Entitätstyps odereines A-Verwalters. Es kann durchaus sein, dass z.B. ein A-Fall oder ein A-Entitätstyp mehr als eineSchnittstelle anbietet (z.B. eine nur zum Lesen, die andere für die Pflege).

Diese Schnittstellen sind alle vom Typ A im Sinn von Abschnitt 1.4.2. Nach Bedarf kann manAdapter vorschalten, die Schnittstellen andererKategorien (AF, 0, R) bereitstellen.

Die sinnvolle Gestaltung von Schnittstellenist die wichtigste Entwurfsaufgabe überhaupt: EineRiesenschnittstelle, die alle Aufrufer sehen, istgenauso abwegig wie der Versuch, jedem Aufruferseine ganz persönliche Schnittstelle anzubieten.

4.3 A-Datentypen

Wichtiges Element der Anwendungen sind Attribut-und Parametertypen. Diese Typen sind zwar wichtigfür die Anwendung, sind aber keine Entitätstypen.Die anwendungsspezifischen Datentypen nennenwir A-Datentypen.

Beispiele für A-Datentypen sind:● Klassiker: Geld, Datum, Zeit● Enumerationstypen (fest oder erweiterbar)● Mini-Grammatiken: ISBN, Artikelnummer mit

Prüfziffer, Fahrgestellnummer, Flugfrequenz● Zusammengesetzte Typen: Adresse, Bank-

verbindungA-Datentypen genügen immer dem für sie

spezifizierten Format, wobei es verschiedene externeDarstellungen (auf der Benutzeroberfläche, in derDatenbank) geben kann. Formate können beispiels-weise durch eine Aufzählung (Beispiel Land), eineIntervall-Angabe (Beispiel Prozentsatz) oder einestrukturierte Formatangabe (Beispiel Adresse, beste-hend aus Straße, Hausnummer, Postleitzahl, ...) fest-gelegt sein.

Eine weiterführende Darstellung dieses Themas findet man in Kapitel 8 in [Siedersleben2002];dort heißen die A-Datentypen „fachliche Daten-typen“.

T-DatentypenDie Abgrenzung zwischen A- und T-Datentypenhängt vom Projekt ab. Wir betrachten als Beispiel die IP-Adresse. Sie ist nur dann ein A-Datentyp, wennsie eine fachliche Bedeutung hat, etwa in einemSystem zur Verwaltung von Hardware-Komponen-ten. In allen anderen Fällen wäre sie ein T-Datentyp, für den sich der Anwender nicht interessiert. Das Kriterium für A-Datentypen lautet: Es macht Sinn,den Datentyp in der Spezifikation zu definieren; man kann mit dem Anwender über Bedeutung undFormat diskutieren.

Implementierung von A-DatentypenA-Datentypen lassen sich in jeder Programmier-sprache als abstrakte Datentypen implementieren(auch Cobol, vgl. [Denert 1991]). In objektorientier-ten Sprachen implementiert man A-Datentypen als Klassen. Für die Architektur spielen Entitätstypenund Datentypen jedoch unterschiedliche Rollen,weshalb uns ihre Unterscheidung wichtig ist – auchwenn dies nicht in jedem Fall Standard ist: In UMLgibt es z.B. nur Klassen; die Unterscheidung „Entitäts-typ“ und „Datentyp“ gibt es nicht, jedenfalls nicht inunserem Sinn. In einzelnen Fällen kann es sinnvollsein, einen A-Datentyp auch durch mehrere pro-grammiersprachliche Klassen abzubilden (vgl. hierzudie Enumerationstypen in [Siedersleben 2002]).

Man kann A-Datentypen auch in der Weiseimplementieren, dass alle Funktionen als statischeMethoden geeigneter Hilfsklassen zur Verfügungstehen, und die Werte selbst direkt z.B. als String oderInteger abgelegt werden. Den Performance-Vor-teilen (weniger erzeugte Objekte) stehen Nachteilegegenüber:a) Reduzierte Flexibilität (die interne Darstellung

ist öffentlich und kann nicht geändert werden)b) Schlechtere Dokumentation c) Möglichkeit des Missbrauchs: Da die interne

Darstellung offen liegt, kann jeder Programmierertun, was ihm gefällt.

Diese Vor- und Nachteile sind im Projektabzuwägen.

Zur Reduzierung der Abhängigkeiten ver-lagert man A-Datentypen zweckmäßigerweise ineigenständige Programmbibliotheken (Pakete, DLLs)– wer nur eine ISBN braucht, will nicht die ganzeBuch-Komponente sehen.

Für A-Datentypen gelten zwei Regeln, vondenen man nur in Einzelfällen abweicht:a) Sie sind unveränderbar (nach dem Muster der Java-

Wrapper-Klassen). Das macht das Leben leichter,weil mit unveränderbaren Objekten bestimmteFehler einfach nicht auftreten können. Bei Perfor-mance-Problemen kann man eine zweite, verän-derbare Klasse zur Seite stellen (analog zu String/StringBuffer in Java).

18

b) Sie werden direkt verwendet, also nicht durchInterfaces geschützt. Das ist einfach pragmatisch:Interfaces sind schön und gut, aber alles mit Maßund Ziel. A-Datentypen sind also in AF-Schnitt-stellen zulässig.

Die Transformation in und aus externen Formaten implementiert man nur in einfachen Fällenin der Klasse selbst (z.B. toString). Andere Trans-formationen (z.B. to/fromSQL, to/fromXML) pro-grammiert man in eigenen evtl. modellgesteuertenTransformatoren oder man benützt die Transforma-tionsmechanismen kommerzieller Mapping-Tools(z.B. Toplink).

Anmerkung: A-Datentypen sind gedacht als Erleichterung für das Projekt und nicht als dogmatischer Ballast: Dieinterne Darstellung des Datentyps und die Standard-abfragen (etwa die Abfrage auf die Landessprachebei der ISBN) sollten in den jeweiligen Klassen ver-borgen sein.

4.4 A-Entitätstypen

A-Entitätstypen sind die Pfeiler, an denen eineAnwendung hochgezogen wird: das Konto, der Kunde,die Bestellung, der Artikel (vgl. [Siedersleben 2002],p. 137 ff.). Den Entitätsbegriff verwenden wir imSinne der Datenmodellierung (also Dinge, die mananlegen, löschen und ändern kann und die einenfachlichen Schlüssel besitzen). A-Entitätstypen ent-stehen bereits in der Spezifikation. Sie werdenbeschrieben durch Attribute, wobei jedes Attribut ent-weder elementar ist (String, Integer, ...) oder zu einemA-Datentyp gehört. Beispiel: Der Kunde hat eineRechnungsadresse, eine Lieferadresse und ein Frei-text-Feld. Dann sind die beiden Adressen vom Typ„Adresse“, das Freitext-Feld vom Typ „String“. DerEntitätstyp ist ein abstrakter Begriff (wie die Klasse);konkret sind die Exemplare (der Kunde 4711).

A-Entitätstypen besitzen in der Regel dieüblichen get- und set-Operationen sowie Instanz-Operationen wie z.B. konto.abheben, buchung.stor-nieren.

A-Entitätstypen haben einen Lebenszyklus,der in der Regel durch ein Zustandsmodell beschrie-ben wird. Die UML-Begriffe Assoziation und Aggre-gation gelten für A-Entitätstypen genauso.

A-Entitätstypen sind persistent. Sie könnenin einer oder mehreren Datenbanken, Nachbarsyste-men oder auch flachen Dateien liegen.

T-EntitätstypenOb es noch andere Entitätstypen als A-Entitätstypengibt, hängt vom Projekt und von der Methode ab. Ein Beispiel für einen T-Entitätstyp: Viele Nummern-Server arbeiten mit einer Tabelle, die für jede mitNummern zu versorgende Einheit die nächste zu ver-gebende Nummer enthält. Der Entitätstyp, aus demeine solche nur aus technischen Gründen erforder-liche Tabelle abgeleitet wird, wäre ein T-Entitätstyp.

Implementierung von A-EntitätstypenA-Entitätstypen lassen sich in jeder Programmier-sprache als abstrakte Datentypen implementieren(auch in Cobol, vgl. [Denert 1991]). In objektorien-tierten Sprachen entspricht jeder A-Entitätstyp inerster Näherung einer Klasse (einer A-Entitätstyp-Klasse). Häufig ist es aber zweckmäßig, einen A-Entitätstyp durch mehrere programmiersprach-liche Klassen abzubilden. In der Datenbank wirdjeder A-Entitätstyp durch eine oder mehrere Tabel-len dargestellt. Die verwendete Datenbankzugriff-schicht bestimmt die Freiheitsgrade des OR-Map-ping6. In jedem Fall hat der A-Entitätstyp die Hoheitüber seine Ablage in der Datenbank: Schreibopera-tionen am A-Entitätstyp vorbei sind streng verboten.Im Idealfall gilt das auch für Leseoperationen; hiersind aber auch abgeschwächte Formen mit Hoheitauf Ebene der A-Komponente vorstellbar. In jedemFall gilt aber, dass Leseoperationen an der A-Kompo-nente vorbei zu vermeiden sind (vgl. hierzu die Hin-weise in Abschnitt 4.5).

A-Entitätstypen und AssoziationenA-Entitätstypen derselben A-Komponente sehen sichdirekt; sie sind nicht durch Interfaces getrennt.Daher werden Assoziationen zwischen A-Entitäts-typen derselben A-Komponente direkt durch Refe-renzen auf Objekte dargestellt. Beispiel: Die Bestel-lung hat eine Collection ihrer Bestellpositionen(in derselben A-Komponente), die Bestellpositioneine Referenz auf ihre Bestellung.

A-Entitätstypen verschiedener eng gekop-pelter A-Komponenten sehen sich über Referenzenauf Schnittstellen. Beispiel: Der Kunde hat eine Referenz auf IKonto in der eng gekoppelten Kompo-nente Buchhaltung.

A-Entitätstypen verschiedener lose gekop-pelter A-Komponenten sehen sich gar nicht. Beispiel:Der Kunde sieht eine TarifId (A-Datentyp mit einpaar Formatprüfungen), hat aber keine Kenntnis vonTarifen – obwohl im Datenmodell eine Assoziationzwischen Kunde und Tarif dargestellt ist.

6 Object-Relational-Mapping

19

4.5 A-Verwalter

Operationen, die man keiner einzelnen A-Entitätzuordnen kann, nennen wir Verwalter-Operationen.Die A-Verwalter implementieren diese Operationen.Jeder verwaltet mindestens einen A-Entitätstyp,aber oft macht es Sinn, einen A-Verwalter für dieganze A-Komponente vorzusehen. Beispiele für Ver-walter-Operationen sind:● Operationen zum Erzeugen von Exemplaren,● Operationen, die alle Exemplare eines A-Entitäts-

typs betreffen,● Suche nach unterschiedlichen Kriterien.

Dazu braucht man in der Regel Verwalter-Daten, z.B.: ● Anzahl der vorhandenen Exemplare● Summe von Attributwerten● Konstanten, die für alle Exemplare gelten

(z.B. Default-Werte).

Hinweis 1: Die Schnittstelle von A-Verwaltern ähnelt demHome Interface von EJB; allerdings befreien wir unsvon der EJB-Maßgabe, dass zu jeder Entity Beangenau ein Home Interface verlangt ist.

Hinweis 2: Oft wird gefragt, wie man Abfragen implementiert,vor allem im Hinblick auf Joins quer über die ganzeDatenbank. Hier eine kurze Zusammenfassung einerseit Jahrzehnten geführten Diskussion:

1. Verstecke die Query-Implementierung hinter einerSchnittstelle, so dass eventuell erforderliche Tuning-Maßnahmen lokal möglich sind.

2. Verwende eine intelligente Zugriffsschicht, die den95%-Fall löst, ohne dass man von Hand SQL pro-grammiert, und die es im 5%-Fall ermöglicht, hand-geschriebenes SQL organisch zu verwenden.

3. Viele Performance-Probleme kommen daher, dassman zum falschen Zeitpunkt zuviel liest. Wir verwei-sen hier auf die Standardarchitektur des DB-Zugriffs(eager oder lazy).

4. Abfragen beziehen sich im Normalfall auf die voneiner A-Komponente verwalteten Daten. Wenn dasnicht der Fall ist, sollte man zunächst prüfen, ob dieA-Komponenten richtig geschnitten sind. Kompo-nentenübergreifende Queries kann man nicht ver-bieten; sie sind bei den von uns entwickelten opera-tiven Systemen aber nicht die Regel. Anders etwabei Data Warehouses: Da machen A-Komponentenwenig Sinn, die meisten Abfragen gehen quer überden ganzen Datenbestand.

5. Dynamisch aus Benutzereingaben erzeugte Abfra-gen kümmern sich nicht um Komponentengrenzenund werden dementsprechend komponentenüber-greifend implementiert.

6. Es gibt auch die Situation, dass z.B. eine Cobol-Komponente schreibt und eine Java-Komponenteaus denselben DB-Tabellen liest. Natürlich macht es keinen Sinn, nur der reinen Lehre wegen denCobol-Teil nach Java zu portieren (oder umgekehrt).Offensichtlich sind der Java- und der Cobol-Teil alsBestandteil einer Komponente zu verstehen. DerChefdesigner stellt sicher, dass die Komponenten-Geschwister aufeinander abgestimmt sind.

Trotz dieser Einschränkungen ist das Prinzipder Hoheit über die Daten eine wichtige Leitlinie.

4.6 A-Fälle

A-Fälle sind die Use Cases von UML. Sie legen fest, welche Operationen der Anwendungskern zurVerfügung stellt, und sie werden bereits in der Spezifikation definiert. A-Fälle werden gerufen● im Dialog,● im Batch,● von Nachbarsystemen,● von anderen Komponenten.

Verarbeitungsschritt und ZustandDer A-Fall ist von der Idee her kurz und transient: Er wird in wenigen Verarbeitungsschritten erledigt;dabei ist jeder Verarbeitungsschritt eine eigene Ope-ration des A-Falls. Jeder Dialogschritt eines Dialogskann einen oder mehrer Verarbeitungsschritte aus-führen. A-Fälle mit mehreren Verarbeitungsschrittenhaben in der Regel ein Gedächtnis; jeder Verarbei-tungsschritt sieht das Ergebnis des vorangegangenenSchrittes. A-Fälle mit nur einem Verarbeitungsschrittbrauchen kein Gedächtnis.

TransaktionenA-Fälle laufen innerhalb einer A-Transaktion (vgl.Abschnitt 4.8). Technisch kann man das so gestal-ten, dass beim Aufruf der einzelnen Verarbeitungs-schritte der Transaktionskontext als Parameter übergeben wird. Eine Alternative ist die Festlegungdes Transaktionskontextes bei der Konstruktion derKomponente. Der A-Fall selbst entscheidet lediglich,ob der gegenwärtige Verarbeitungszustand konsi-stent ist oder nicht. Der Abschluss der Transaktionkann nur in einem konsistenten Zustand erfolgen.

20

GeschäftsprozessWir verstehen unter einem Geschäftsprozess einenfachlichen Ablauf in Teilschritten, wobei einzelneTeilschritte von einem System unterstützt werdenkönnen. Ein solcher Teilschritt ist dann ein Anwen-dungsfall. Ggf. kommt auch eine übergeordneteWorkflow-Steuerung zum Einsatz. Wir vermeiden indiesem Papier den Begriff Geschäftsvorfall.

Wenn Anwendungsfälle über einen längerenZeitraum ablaufen, besitzen sie Persistenzcharakter.In diesem Fall werden sie als spezielle A-Entitäts-typen implementiert. So wäre z.B. in einem Versiche-rungssystem der Versicherungsvertrag ein klassischerA-Entitätstyp. Wir nehmen nun an, dass sich derAnwendungsfall „Vertragsabschluss“ über mehrereWochen hinzieht und ein bestimmtes Genehmi-gungsverfahren durchläuft. Dann wäre der Vertrags-abschluss ebenfalls ein A-Entitätstyp, in dem dasentsprechende Zustandsmodell niedergelegt ist.

A-Fälle als Schnittstelle der A-KomponenteDie A-Fälle sind der Zugang zur Anwendung. DieMenge der A-Fälle einer A-Komponente definiert,was die Komponente leistet, und zwar ohne Bezugauf den konkreten Nutzer: Dem A-Fall ist es egal, ob seine Daten am Bildschirm angezeigt oder in einNachbarsystem übertragen werden. Nur so istgewährleistet, dass ein und derselbe A-Fall im Batchund in verschiedenen Dialogen verwendbar ist.Trotzdem darf ein A-Fall, der nur in einem einzigenDialog verwendet wird, der zugehörigen Maske ähn-lich sehen. In Abschnitt 4.2 wurde dargestellt, wieman die Schnittstelle von A-Komponenten gestaltet.

A-Fälle als Zugang zu A-Entitätstypen und A-Verwaltern

A-Fälle garantieren den sachgemäßen Zugriff auf A-Entitätstypen und A-Verwalter. Dahinter stecktder folgende Gedanke: Die Operationen von A-Enti-tätstypen und auch A-Verwaltern funktionieren nur, wenn bestimmte Vorbedingen erfüllt sind. Diesist fast immer eine nichttriviale Angelegenheit, vorallem dann, wenn Zustandsmodelle im Spiel sind. Wirbetrachten als Beispiel die Operation buchung.stor-nieren des A-Entitätstyps Buchung. Diese setzt vor-aus, dass die angesprochene Buchung (a) noch nichtstorniert ist und (b) der Passagier noch nicht geflogenist. Es gibt mehrere sinnvolle Möglichkeiten für dasAufrufprotokoll zwischen dem Aufrufer und dem A-Entitätstyp Buchung, aber auf keinen Fall darf die-ses Protokoll in verschiedenen Dialogen, Batchesund Nachbarsystemen mehrfach programmiert sein.Man beachte, dass im Fall der engen Koppelung dieSchnittstellen der A-Entitätstypen auch außerhalbder A-Komponente sichtbar sind. Bei loser Koppelungist das nicht der Fall.

Implementierung von A-FällenAuch A-Fälle werden in der Regel als objektorientier-te Klasse implementiert (A-Fall-Klasse); unter EJB häufig als Session-Bean mit oder ohne Zustand(state). Die A-Fall-Klassen einer A-Komponenteimplementieren deren Schnittstelle. Die A-Fall-Klas-sen sehen die A-Entitätstypen und A-Verwalter dereigenen Komponente direkt ohne dazwischenliegen-de Schnittstelle, denn sie befinden sich in derselbenKomponente, und die Austauschbarkeit der Imple-mentierung ist nur hinter den Schnittstellen vonKomponenten gefordert. Bei der Implementierungvon A-Fällen verdienen zwei Punkte eine besondereWürdigung: Der Zustand (oder das Gedächtnis) vonA-Fällen und die Persistenz.● Zustand: Die Zustandsverwaltung von A-Fällen ist

unproblematisch, solange das A-Fall-Objekt wäh-rend der gesamten Verarbeitung am Leben bleibtund für den Nutzer exklusiv zur Verfügung steht.Im anderen Fall empfiehlt sich ein Zustandsverwal-ter, der den Zustand der A-Fälle von einem Verar-beitungsschritt zum nächsten rettet. Dafür bietensich z.B. an: die lokale Platte, die Datenbank, einCookie. Dies kann auch unter EJB Sinn machen,wenn man – aus welchen Gründen auch immer –Session Beans vermeiden will. Einen zustands-behafteten A-Fall sollte man immer so gestalten,dass sich die Zustandsverwaltung mit geringemAufwand ändern lässt. Selbstverständlich sindzustandsbehaftete A-Fälle schwieriger zu verwaltenals zustandslose (z.B. im Fall der Lastverteilung auf verschiedene Server). Trotzdem vermeide manes, einen zustandsbehafteten A-Fall mit Gewalt zu einem zustandslosen zu machen.

● Persistenz: A-Fälle sind ihrer Natur nach transient.Jedoch gestattet der eben eingeführte Zustands-verwalter (natürlich nur bei geeigneter Implemen-tierung), A-Fälle nicht nur wenige Sekunden oderMinuten aufzubewahren, sondern auch Stundenoder Tage. So kommt man preiswert zu langen Dialogen: Der Benutzer speichert und unterbrichtseinen Dialog am Abend und nimmt ihn am nächsten Morgen (oder nach dem Urlaub) wiederauf. Lange Dialoge garantieren – im Gegensatz zu langen Transaktionen – nicht die ACID-Eigen-schaft (vgl. Standardarchitektur Transaktionen).

21

4.7 A-Komponenten

A-Komponenten realisieren das Prinzip der Trennungvon Zuständigkeiten und der Kapselung von Infor-mation. Sie bilden in erster Linie eine logische Grup-pierung von A-Fällen, A-Entitätstypen und A-Verwal-tern. Die Schnittstelle einer A-Komponente ist dieVereinigung der Schnittstellen ihrer A-Fälle.

Nachbarsysteme werden im Anwendungs-kern durch A-Komponenten gekapselt, die selbst perAdapter und Experte mit dem physischen Nachbar-system kommunizieren (vgl. Abbildung 10).

A-Komponenten sind verwandt mit Kompo-nentenmodellen wie CORBA Component Model. DerKomponentenbegriff von EJB (also die EnterpriseJava Bean) ist im wesentlichen die Java-Klasse undsomit für unsere Zwecke ungeeignet, da zu klein.

A-Komponenten sind also zunächst einmalKomponenten im Sinn von Abschnitt 1.3.2. Sie sindkein Zusatzaufwand: Eine kleine Anwendung mitwenigen A-Entitätstypen besteht per Definition ausnur einer A-Komponente. Bei großen Anwendungenverhindern A-Komponenten die Entstehung vonMonolithen: Wir sehen eine überschaubare Zahl von A-Komponenten mit genau definierten Schnittstel-len anstelle einer amorphen Masse von mehrerenTausend Klassen. A-Komponenten sind eine logischeEinheit und haben als solche keinen Einfluss auf diePerformance: Ein Aufruf über Komponentengrenzenist so schnell oder so langsam wie ein anderer. Inmanchen Fällen ist zu überlegen, wie man die A-Kom-ponente auf technische Komponenten abbildet.Wenn – wie in EJB 1.1 – jeder Aufruf einer EntityBean über RMI erfolgt, dann sind A-Komponentenetwas anderes als Entity Beans.

KomponentenhierarchieJede A-Komponente kann andere A-Komponentenbenutzen und sie kann wieder andere enthalten.Es gilt wie im allgemeinen Fall: Enthaltene Kompo-nenten sind Implementierungsgeheimnis, benutzteKomponenten werden nur über die offizielle An-wendungsfall-Schnittstelle angesprochen. Die Ent-hält-Beziehung definiert eine Hierarchie von A-Komponenten (vgl. Abschnitt 1.3.5). Dies struk-turiert die Anwendung: Komponenten der unterstenEbene enthalten wenige, eng verknüpfte Entitäts-typen (Bestellung/Bestellposition). Sie entsprechenweitgehend den Sachbearbeitern bei [Denert 1991].

Hoheit über die DatenJede A-Komponente definiert durch die enthaltenenA-Entitätstypen auch einen Bereich der Datenbank,der nur über Operationen der A-Komponentezugänglich ist. Die A-Komponente hat die Hoheit(oder Ownership) in diesem Bereich (vgl. hierzuAbschnitt 4.5)

Man beachte, dass A-Komponenten nichtsmit der Dialogoberfläche zu tun haben. Ein und der-selbe Dialog kann also ohne weiteres verschiedeneA-Komponenten benutzen.

Enge und lose Koppelung von KomponentenA-Komponenten kommunizieren mit anderen A-Kom-ponenten aus demselben und/oder aus anderenSystemen, und sie sprechen mit lokalen oder entfern-ten Nachbarsystemen. Immer gilt: Die Kommuni-kation erfolgt über Schnittstellen; A-Verwalter- undA-Entitätstyp-Klassen sind außerhalb ihrer Kom-ponente niemals direkt sichtbar, sondern nur überSchnittstellen. A-Datentypen erscheinen in derSchnittstelle als solche, ohne Interface. Diese direkteNutzung einer A-Komponente über A-Schnittstellen(vgl. Abschnitt 1.4.2) nennen wir enge Koppelung.Enge Koppelung macht immer dann Sinn, wenn die beteiligten A-Komponenten dieselbe Sprachesprechen: Sie verwenden dieselben A-Datentypen,sie sind Teil desselben Datenmodells.

Enge Koppelung ist schädlich, wenn diebeteiligten Komponenten zu verschiedenen Weltengehören. In diesem Fall wäre die rufende Komponentegezwungen, die Begriffswelt einer jeden gerufenenKomponente zu verstehen und zu interpretieren.Deshalb gibt es neben der engen auch die lose Koppe-lung. Bei der losen Koppelung sieht die rufendeKomponente nur eine AF-Schnittstelle.

Die Koppelung von Nicht-A-Komponentenund A-Komponenten ist immer lose.

Transformation der DatenBei loser Koppelung kommunizieren Komponenten,die verschiedene Sprachen sprechen: die eigeneAnwendung mit einem Nachbarsystem, dem GUIoder der Zugriffsschicht (vgl. Kapitel 3). Die Nutzungneutraler Schnittstellen ist ein erster Schritt zur Entkoppelung, aber nicht der letzte. Wir braucheneine Transformation der Daten zwischen den beidenWelten: Beim Datenbankzugriff transformiert mandie Daten der Anwendung in die SQL-Datentypen(und wieder zurück), beim GUI sind es im wesentlichennur Strings, die am Bildschirm sichtbar sind.

Diese Transformation ist auch dann nötig,wenn die beteiligten Komponenten auf einem Rech-ner laufen; sie hat nichts zu tun mit Client-Server-Kommunikation.

Eine eigene Komponente besorgt die eigent-liche Aufgabe der Transformation. Hier gibt es zweiMöglichkeiten der Implementierung: von Hand undmodellgesteuert. Im ersten Fall schreibt man eineFülle von gleichartigen Funktionen, die ein Objektder Anwendung in eine Swing- oder SQL-Darstellungtransformieren und umgekehrt. Dies ist typische R-Software. Man kann aber ohne weiteres auch eineoder mehrere 0-Komponenten schreiben, die dieseTransformationen auf der Basis von Datenkatalogenautomatisch durchführen. Wir sprechen in diesem

22

Fall von modellgesteuerten Transformationen. DasFormat eines solchen Datenkatalogs ist beliebig;XML liegt natürlich nahe. Bei vielen verschiedenenDarstellungen ist es sinnvoll, die Anzahl der Trans-formationen mit Hilfe eines Standardformats (z.B.XML) zu reduzieren (also n+m statt n*m Transfor-mationen).

In jedem Fall sieht der Aufrufer nur eineSchnittstelle; es ist ihm egal, ob dahinter eine hand-geschriebene oder eine modellgesteuerte Transfor-mation abläuft.

Die A-Datentypen sollten solche Transfor-mationen gerade nicht kennen – sonst versammeltsich Wissen über unterschiedliche Darstellungen(z.B. XML) in allen zu transformierenden A-Daten-typen.

4.8 A-Transaktionen

Wir unterscheiden zwischen der Transaktion ausAnwendersicht (A-Transaktion) und der technischenTransaktion (T-Transaktion), die der TP-Monitor, die Datenbank oder eine andere technische Kompo-nente implementiert. Es ist Sache der T-Architektur,A- auf T-Transaktionen geeignet abzubilden (z.B.durch die optimistische Transaktionsstrategie); vgl.hierzu das Kapitel über Standardarchitektur Transak-tion. Es sei noch darauf hingewiesen, dass A-Trans-aktionen auch und gerade dann sinnvoll sind, wenn– wie bei EJB – die Steuerung der T-Transaktionennur noch deklarativ in den Bean-Deskriptoren steht.Es wäre schlecht, wenn die diversen Varianten derEJB-Transaktionen auf der A-Ebene sichtbar wären.

Hoheit über die TransaktionenDie Kontrolle über die A-Transaktionen liegt beim Aufrufer eines Anwendungsfalles; diese kann auchimplizit durch entsprechende Angaben im Bean-Deskriptor geschehen. Er gibt den Transaktionskon-text beim Aufruf mit.

Operationen von TransaktionenJede Transaktion verfügt über die OperationenBestätigen und Verwerfen. Bestätigen ist nur mög-lich, wenn alle laufenden A-Fälle dies gestatten; Verwerfen ist normalerweise immer möglich, aberdas muss nicht so sein.

TransaktionskontextJede A-Transaktion gehört zu einem Transaktions-kontext. Dies ist eine Transaktionsfabrik: Sie liefertTransaktionen (genauer: Exemplare von Transaktio-nen), unter deren Kontrolle jede Änderung erfolgt.Die Transaktion veranlasst beim Bestätigen im ein-fachsten Fall einen harten Datenbank-Commit, aberman kann sich auch ganz andere Mechanismen vor-

stellen. Im Batch könnte die Transaktion nur aufeinen Cache wirken, und die Batch-Steuerung würdediesen Cache in festen Abständen (z.B. nach jeweils1000 Verarbeitungsschritten) in die Datenbankübertragen. Ein Transaktionskontext kann in unter-schiedlicher Form vorliegen: implizit durch entspre-chende Angaben in einem Bean-Deskriptor oderexplizit durch eine Schnittstelle vom Typ 0.

A-Transaktionen und A-KomponentenA-Komponenten baut man so, dass sie mit unter-schiedlichen Transaktionskontexten mehrfach konstruierbar sind (vgl. Abschnitt 1.3.3). Das kostetnichts, führt zu klarem Code und eröffnet eine ganze Dimension von Möglichkeiten (z.B. paralleleDialoge, die jeweils ihre eigenen Transaktionskon-text besitzen).

Geschachtelte A-TransaktionenGeschachtelte Transaktionen sind für viele Anwen-dungen unverzichtbar (etwa für „Was-wäre-wenn-Analysen“). Aus Sicht der Anwendung langt es z.B.,wenn die A-Transaktion selbst ein Transaktions-kontext ist: Dann liefert jede A-Transaktion selbstwieder eingebettete A-Transaktionen, deren Ablaufsie kontrolliert. Das ist nicht ganz einfach zu implementieren, aber aus Anwendungssicht leichtzu nutzen.

23

Quasar-KonformitätWie kann man prüfen, ob ein gegebenes System denQuasar-Kriterien entspricht? Die folgenden Fragen7

sollen dabei helfen:

1. Wo ist die A-Architektur? Aus welchen A-Kom-ponenten besteht das System? Wer benutzt wen;welche Abhängigkeiten existieren?

2. Wo ist die TI-Architektur?

3. Wo ist die T-Architektur? Aus welchen T-Komponen-ten besteht das System? Wer benutzt wen; welcheAbhängigkeiten existieren?

4. Wird zwischen Fehlern (konsistent) und Notfällen(inkonsistent) unterschieden?

5. Für jede Komponente k:a) Was tut k (maximal drei Sätze) ?b) Zu welcher Kategorie gehört k ?c) Welche Schnittstellen exportiert k ?d) Welche Schnittstellen importiert k ? e) Welche Kategorien haben die Schnittstellen ?f) Wo ist das EmergencyHandling ?g) Welche Änderungen von k sind vorgesehen/

nicht möglich?

Anhang

7 Diese Liste ist noch unvollständig

24

Literatur

[Siedersleben 2002] J. Siedersleben: Software-Technik. Hanser Verlag, 2002.

[Broy 2001] M. Broy, K. Stolen: Specification and Development of Interactive Systems.Springer, 2001.

[Buschmann 1996] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad,M. Stal: Pattern Oriented Software Architecture – A System of Patterns. Wiley, 1996.

[Denert 1991] E. Denert, J. Siedersleben: Software-Engineering. Springer Verlag, 1991.

[D’Souza 1999] D. F. D’Souza, A. C. Wills: Objects, Components and Frameworks with UML: The Catalysis Approach. Addison-Wesley, 1999.

[Gamma 1995] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Design Patterns, Elements of Reusable Object-orientedSoftware. Addison-Wesley, 1995.

[Hightower 2002] R. Hightower, N. Lesiecki: Java Tools for Extreme Programming. Wiley, 2002.

©sd

&m

-Res

earc

h, A

pril

2003

Ges

talt

ung

:Stu

dio

Qui

tta,

Mün

chen

Qua

sar

sd&m ResearchThomas-Dehler-Straße 27 81737 München Telefon 089 638129-00Telefax 089 638129-11

www.sdm-research.deQ

uasa

r