Sie sind auf Seite 1von 98

Entwurf

11 Entwurf der Architektur .... . . ...... . ............... .. 275

12 Architekturen verteilter Systeme . ........ . ...... . ..... 299

13 Anwendungsarchitekturen . . .......... ... .... . ........ 325

14 Objektorientierter Entwurf . . ... ......... .. . . .. ... .. .. 345

15 Entwurf von Echtzeitsoftware ....... . . .. ... ... ....... 371

16 Entwurf von Bedienoberflächen .. ..... .......... ..... 395


ENTWURF

Das Wesentliche beim Softwareentwurf besteht darin, Entscheidungen über die logische
Organisation der Software zu treffen. Manchmal stellen Sie diese logische Organisation
in einer definierten Modellierungssprache wie UML als Modell dar und manchmal nut-
zen Sie für den Entwurfs lediglich informelle Aufzeichnungen und Skizzen. Natürlich
beginnen Sie bei der Entscheidung über die Organisation der Software selten ganz von
vorne, sondern gründen Ihren Entwurf auf vorangegangene Erfahrungen.
Einige Autoren sind der Meinung, dass diese Entwurfserfahrungen in strukturierten
Methoden zusammengefasst werden sollten, wobei Sie einern definierten Entwurfspro-
zess folgen und Ihren Entwurf unter Verwendung verschiedener Typen von Modellen
beschreiben. Ich war nie ein großer Anhänger strukturierter Methoden, weil ich immer
festgestellt habe , dass sie zu einschränkend sind. Der Entwurf ist ein kreativer Prozess
und ich glaube stark daran, dass jeder von uns einen solchen kreativen Prozess auf
eigene Art und Weise in Angriff nimmt. Beim Softwareentwurf gibt es keinen richtigen
oder falschen Weg und weder ich noch jemand anderes kann Ihnen ein "Rezept" dafür
geben. Sie lernen zu entwerfen, indern Sie Beispiele vorhandener Entwürfe anschauen
und diese mit anderen besprechen.
Anstatt Erfahrung als "Entwurfsmodell" darzustellen, ziehe ich einen lose strukturier-
ten Ansatz vor. Die Kapitel in diesem Teil fassen Wissen über Softwarestrukturen zusam-
men, die in anderen Systemen erfolgreich eingesetzt wurden, bieten einige Beispiele und
geben Ihnen einige Hinweise zum Entwurfsprozess:
Kapitel 11 bis 13 handeln von den abstrakten Softwarestrukturen. Kapitel 11 erör-
tert strukturelle Perspektiven, die sich beim Softwareentwurf als nützlich erwiesen
haben, Kapitel 12 behandelt das Strukturieren von Software für verteilte Ausführung
und Kapitel 13 beschreibt generische Strukturen für verschiedene Arten von Anwen-
dungen. Kapitel 13 ist neu. Ich habe es in diese Aufgabe aufgenommen, weil ich fest-
gestellt habe, dass viele Studenten des Software Engineering keine Erfahrungen mit
Anwendungssoftware haben, mit Ausnahme der interaktiven Systeme, die sie täglich
auf ihren eigenen Computern einsetzen.
Die Kapitel 14 bis 16 behandeln spezifischere Fragen der Softwareentwicklung.
Kapitel 14 behandelt den objektorientierten Entwurf und befasst sich mit Überlegun-
gen zu Softwarestrukturen. Kapitel 15 über den Entwurf von Echtzeitsystemen erörtert
die Softwarestrukturen, die Sie in Systemen benötigen, in denen rechtzeitige Antwor-
ten die entscheidende Anforderung sind. Kapitel 16 fällt etwas aus der Reihe, da es
sich auf den Entwurf der Benutzerschnittstelle an Stelle von Softwarestrukturen kon-
zentriert. Als Entwickler müssen Sie über Systeme nachdenken - nicht nur über Soft-
ware - und die Menschen in den Systemen sind eine unentbehrlicher Bestandteil. Der
Entwurf hört nicht bei den Softwarestrukturen auf, sondern setzt sich in der Art und
Weise der Anwendung der Software fort.
Entwurf der Architektur

11.1 Architektonische Entwurfsentscheidungen . . . . .. 279


11.2 Systemorganisation . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 281
11.2.1 Das Datenspeichermodell . . . . . . . . . . . . . . . . . . . . .. 281
11.2.2 Das Client/Server-Modell . . . . . . . . . . . . . . . . . . . . . . 283
11.2.3 Das Schichtenmodell ........................ .. 284
11.3 Modulare Dekompositionen . ....... ... ...... . ... 286
11.3.1 Objektorientierte Dekomposition .. . ...... . . .. ... 287
11.3.2 Funktionsorientierte Pipeline. . . . . . . . . . . . . . . . . .. 288
11.4 Steuerungstypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 289
11.4.1 Zentrale Steuerung .. . . . . . . . . . . . . . . . . . . . . . . . .. 290
11.4.2 Ereignisgesteuerte Systeme. . . . . . . . . . . . . . . . . . . . . 292
11.5 Referenzarchitekturen . ............ ... .... ....... 294
Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 297
Ergänzende Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . .. 297
Übungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 297
ENTWURF DER ARCHITEKTUR

Lernziele Das Ziel dieses Kapitels ist eine Einführung in die Konzepte und den Entwurf
der Softwarearchitektur. Wenn Sie dieses Kapitel gelesen haben, werden Sie
• verstehen, warum der Entwurf der Softwarearchitektur von großer Bedeutung ist
111 die Entscheidungen verstehen, die während des Architekturentwurfs über die System-
architektur gefällt werden müssen
Grundlagenkenntnisse über drei sich ergänzende Architekturtypen besitzen, die die
gesamte Systemorganisation, die modulare Zerlegung und die Steuerung abdecken
• verstehen, wie Referenzarchitekturen zum Mitteilen architektonischer Konzepte und
zum Bewerten von Systemarchitekturen verwendet werden

Große Systeme sind immer in Subsysteme gegliedert, von denen jedes eine Anzahl
von Diensten bereitstellt. Der fundamentale Prozess zur Definition dieser Subsysteme
und zur Errichtung eines Rahmenwerkes für die Steuerung und Kommunikation die-
ser Subsysteme wird Entwurf der Architektur, manchmal auch Grobentwurf genannt,
und als Ergebnis dieses Entwurfsprozesses wird die Beschreibung der Softwarearchi-
tektur erstellt.
In dem in Kapitel 4 vorgestellten Modell ist der Entwurf der Architektur die erste
Phase im Entwurfsprozess, der eine entscheidende Verbindung zwischen dem Ent-
wurf und dem Prozess der Anforderungsspezifikation darstellt. Der Entwurf einer
Architektur ist mit der Aufstellung eines grundlegenden strukturellen Rahmenwerkes
für ein System verbunden, das die Bestimmung der Hauptkomponenten des Systems
und die zwischen ihnen stattfindende Kommunikation beinhaltet.
Bass et al. (Bass et al. 2003) erläutern drei Vorteile eines expliziten Entwurfs und
einer eindeutigen Dokumentation der Softwarearchitektur:
o Kommunikation zwischen den Projektbeteiligten: Die Architektur ist eine stark
vereinfachte Darstellung des Systems, die als Diskussionsgrundlage für verschie-
dene Projektbeteiligte dienen kann.
g Systemanalyse: Um die Systemarchitektur in einem frühen Stadium der System-
entwicklung klar darzustellen, sind verschiedene Analysen erforderlich. Entschei-
dungen zum Architekturentwurf haben einen tief greifenden Einfluss darauf, ob
das System die kritischen Anforderungen in Bezug auf die Leistungsfähigkeit, die
Zuverlässigkeit und die Wartbarkeit erfüllt.
D Wiederverwendung in großem Umfang: Das Modell einer Systemarchitektur ist
eine kompakte und zweckmäßige Beschreibung davon, wie ein System aufgebaut
ist und wie die einzelnen Komponenten miteinander zusammenarbeiten. Die
Systemarchitektur ist für Systeme mit ähnlichen Anforderungen oftmals gleich
und kann somit eine umfangreiche Wiederverwendung der Software unterstüt-
zen. Wie in Kapitel 18 dargestellt. ist es möglich, Produktlinienarchitekturen zu
entwickeln, bei denen die gleiche Architektur für eine größere Anzahl verwand-
ter Systeme angewendet werden kann.
Hofmeister et al. (Hofmeister et al., 2000) erörtern, wie die Phase des Architektur-
entwurfs Softwareentwickler dazu zwingt, grundlegende Entwurfsaspekte in einem
frühen Prozessstadium in Betracht zu ziehen. Sie schlagen vor, dass die Software-
architektur als Entwurfsplan dient, um über Systemanforderungen zu verhandeln,
und als Mittel, um Diskussionen mit Kunden, Entwicklern und Managern zu struktu-
rieren. Weiterhin empfehlen sie sie als wichtiges Werkzeug für das Komplexitäts-
management. Es verbirgt Einzelheiten und ermöglicht dem Entwickler, sich auf die
grundlegenden Systemabstraktionen zu konzentrieren.
Die Systemarchitektur beeinflusst die Leistungsfähigkeit, die Stabilität, die Verbrei-
tungsfähigkeit und die Wartbarkeit eines Systems (Bosch, 2000). Der für eine be-
stimmte Anwendung gewählte spezielle Typ und die Struktur können deshalb von
den nichtfunktionalen Systemanforderungen abhängen:
Leistungsfähigkeit: Wenn dies ein entscheidendes Merkmal ist, sollte der Architek-
turentwurf kritische Abläufe innerhalb einer möglichst kleinen Anzahl von Subsys-
temen konzentrieren, wobei so wenig Kommunikation wie möglich zwischen die-
sen Subsystemen stattfinden sollte. Das kann allerdings die Benutzung von relativ
großen statt von kleinen Komponenten suggerieren, um die Kommunikation zwi-
schen den Komponenten zu begrenzen.
lIiI ZugrifJsschutz: Wenn der Schutz vor Zugriffen von außen im Vordergrund steht, ist
eine Architektur mit Schichtenstruktur zu empfehlen, bei der die kritischsten
Inhalte geschützt in den untersten Schichten angeordnet und diese Schichten mit
einem hohen Schutzniveau ausgestattet werden.
Sicherheit: Wenn auf ein hohes Sicherheitsniveau Wert gelegt wird, sollte die Archi-
tektur so entworfen werden, dass alle sicherheitsrelevanten Aktivitäten in einem
Subsystem oder in einer möglichst kleinen Anzahl von Subsystemen angeordnet
sind. Das verringert die Kosten sowie Probleme der Sicherheitsvalidierung und
ermöglicht die Bereitstellung entsprechender Sicherheits systeme.
Verfügbarkeit: Wenn die Verfügbarkeit eine kritische Anforderung darstellt, sollte
die Architektur redundante Komponenten enthalten, damit es möglich ist, Kompo-
nenten zu aktualisieren und zu ersetzen, ohne das System abzuschalten. Fehlertole-
rante Systemarchitekturen für hochverfügbare Systeme werden in Kapitel 20 näher
behandelt.
• Wartbarkeit: Bei hohen Anforderungen an die Wartbarkeit sollte eine Systemarchi-
tektur mit kleinen, unabhängigen Komponenten geeignet sein, die schnell geändert
werden können. Erzeuger und Benutzer von Daten sollten getrennt, gemeinsame
Datenstrukturen vermieden werden.
Offensichtlich bestehen zwischen einigen dieser Architekturen potenzielle Konflikte.
Die Leistungsfähigkeit beispielsweise wird durch die Verwendung großer Komponenten
erhöht, während zur Verbesserung der Wartbarkeit kleine besser geeignet sind. Wenn
diese bei den Merkmale zu den wichtigen Systemanforderungen gehören, muss eine
Kompromisslösung gefunden werden. Wie schon erwähnt, ist dies manchmal durch die
Verwendung verschiedener Architekturtypen für verschiedene Teile des Systems mög-
lich.
Es gibt eine deutliche Überschneidung zwischen dem Prozess der Anforderungsana-
lyse und dem Architekturentwurf. Idealerweise sollte eine Spezifikation keinerlei
Festlegungen in Bezug auf den Entwurf enthalten. In der Praxis ist dies außer bei sehr
kleinen Systemen unrealistisch. Eine Dekomposition (Zerlegung) der Architektur ist

I 277
ENTWURF DER ARCHITEKTUR

notwendig, um die Spezifikation zu strukturieren und zu organisieren. Ein gutes Bei-


spiel dafür ist die in ~ Abbildung 2.8 vorgestellte Architektur eines Flugsicherungs-
systems. Das Architekturmodell ist häufig der Ausgangspunkt für die Spezifikation
der verschiedenen Teile des Systems.
Der Entwurf eines Subsystems ist eine abstrakte Zerlegung eines Systems in grob
strukturierte Komponenten, die alle das eigene Recht haben, selbst substanzielle Sys-
teme zu bilden. Oftmals werden Blockdiagramme verwendet, um die Entwürfe von
Subsystemen zu beschreiben, wobei jeder Block ein Subsystem darstellt. Blöcke inner-
halb von Blöcken bedeuten, dass ein Subsystem selbst wiederum aus Subsystemen auf-
gebaut ist. Pfeile deuten an, dass Daten oder Steuerungssignale zwischen den Subsyste-
men in Richtung der Pfeile übertragen werden. Das Blockdiagramm einer Architektur
gibt einen Überblick über die Systemstruktur. Es ist für die Mitarbeiter aus unter-
schiedlichen Fachbereichen, die in den Systementwicklungsprozess einbezogen sind,
einfach zu verstehen.
~ Abbildung 11.1 ist zum Beispiel ein abstraktes Modell der Architektur eines auto-
matischen Verpackungssystems und zeigt die zu entwickelnden Subsysteme an. Dieses
Robotersystem kann verschiedenartige Objekte verpacken. Es benutzt dazu ein opti-
sches Subsystem, um Objekte auf einem Förderband auszuwählen, den Typ des Objek-
tes zu bestimmen und die entsprechende Verpackungsart auszuwählen. Danach werden
die Objekte vom Förderband zur Verpackungseinheit transportiert. Verpackte Objekte
werden auf ein anderes Förderband gelegt. Weitere Beispiele von ArchitekturentwÜffen
in vergleichbarer Darstellung werden in Kapitel 2 gezeigt (I> Abbildungen 2.6 und 2.8).

System zur
Obj ekt-
bes timmung

Verpackungs-
auswahl-
system

Verpackungs- - I
Förderband- 11
system fl------~I steuerung JI
Abbildung 11.1: Blockdiagramm der Steuerung eines automatischen Verpackungssystems

Bass et al. (Bass et a1. 2003) stellten fest, dass einfache Block- und Liniendiagramme
als Darstellungen für Architekturen allein nicht ausreichen, weil sie weder die Art der
Beziehungen zwischen den Systemstrukturen noch deren von außen sichtbare Eigen-
schaften zeigen. Vom Standpunkt eines Softwareentwicklers aus ist das absolut rich-
tig. Dennoch eignet sich diese Darstellungsart sehr gut für die Diskussion mit allen
Systembeteiligten und für die Projektplanung. Da ein solches Diagramm nicht mit
11.1 Architektonische Entwurfsentscheidungen

Details überladen ist, können alle Beteiligten damit arbeiten und sich ein vereinfach-
tes Bild von dem System machen. Das Modell nennt die bestimmenden Subsysteme,
die unabhängig voneinander entwickelt werden müssen, so dass das Management mit
der Einteilung des Personals für die Planung der Implementierung dieser Systeme
beginnen kann. Block- und Liniendiagramme sollen durchaus nicht die einzigen
benutzten Darstellungen der Architektur sein, sie gehören vielmehr zu einer Reihe
anderer nützlicher Architekturmodelle.
Das allgemeine Problem, wie ein System in Subsysteme zerlegt werden kann, ist
schwierig. Natürlich stellen die Systemanforderungen einen Hauptfaktor dar, und Sie
sollten versuchen, einen Entwurf aufzustellen, in dem es eine enge Übereinstimmung
zwischen Anforderungen und Subsystemen gibt. Das bedeutet, dass im Falle einer
Anforderungsänderung diese Änderung wahrscheinlich begrenzt und nicht über meh-
rere Subsysteme verteilt ist. In Kapitel 13 beschreibe ich eine Anzahl generischer
Anwendungsarchitekturen, die als Startpunkt zum Erkennen von Subsystemen ver-
wendet werden können.

11.1 Architektonische Entwurfsentscheidungen


Der architektonische Entwurf ist ein kreativer Prozess, in dem Sie versuchen, eine Sys-
temorganisation aufzubauen, die die funktionalen und nichtfunktionalen System-
anforderungen erfüllt. Da es sich um einen kreativen Prozess handelt, unterscheiden
sich die Aktivitäten in diesem Prozess radikal je nach Art des zu entwickelnden
Systems, der Herkunft und Erfahrung des Systemarchitekten und den spezifischen
Systemanforderungen. Es ist daher nützlicher, den architektonischen Entwurfsprozess
aus der Perspektive der Entscheidung zu betrachten als aus einer Perspektive der Akti-
vität. Während dieses Prozesses müssen Systemarchitekten eine Reihe grundlegender
Entscheidungen treffen, die sich tiefgehend auf das System und seinen Entwicklungs-
prozess auswirken. Beruhend auf ihrem Wissen und ihrer Erfahrung müssen sie die
folgenden grundlegenden Fragen beantworten:
Gibt es eine allgemeine Anwendungsarchitektur, die als Schablone für das zu ent-
werfende System dienen kann?
Wie wird das System auf mehrere Prozessoren verteilt sein?
11 Welcher architektonische Typ oder welche Typen sind für das System geeignet?
Wie lautet der grundlegende Ansatz zur Strukturierung des Systems?
• Wie werden die strukturellen Einheiten im System in Module zerlegt?
Mit welcher Strategie wird der Betrieb der Systemeinheiten gesteuert?
Wie wird der architektonische Entwurf bewertet?
• Wie soll die Systemarchitektur dokumentiert werden?
Obwohl jedes Softwaresystem einzigartig ist, weisen Systeme desselben Anwendungs-
bereichs oftmals ähnliche Architekturen auf, die die grundlegenden Konzepte dieses
Bereichs darstellen. Diese Anwendungsarchitekturen können recht allgemein sein, wie
die Architektur von Systemen zur lnformationsverwaltung, oder sehr spezifisch.
Anwendungsproduktlinien sind z.B. Anwendungen, die um eine Kernarchitektur
herum aufgebaut sind und Varianten bilden, die spezifische Kundenanforderungen
erfüllen. Beim Entwurf einer Systemarchitektur müssen Sie entscheiden, was Ihr Sys-
ENTWURF DER ARCHITEKTUR

tem und weiter reichende Anwendungsklassen gemeinsam haben und wie viel Wissen
Sie von diesen Anwendungsarchitekturen wiederverwenden können. Ich behandle all-
gemeine Anwendungsarchitekturen in Kapitel 13 und Anwendungsproduktlinien in
Kapitel 18.
Eingebettete Systeme und für PCs entworfene Systeme nutzen in der Regel nur
einen einzelnen Prozessor, so dass Sie keine verteilte Architektur entwerfen müssen.
Bei den meisten großen Systemen handelt es sich heutzutage jedoch um verteilte
Systeme, bei denen die Systemsoftware über viele verschiedene Computer verteilt ist.
Die Wahl einer Verteilungsarchitektur ist eine Schlüsselentscheidung, die sich auf die
Leistung und Zuverlässigkeit des Systems auswirkt. Das ist ein eigenes Hauptthema,
das ich in Kapitel 12 gesondert behandeln werde.
Die Architektur eines Softwaresystems kann auf einem bestimmten architektoni-
schen Modell oder Typ beruhen. Ein architektonischer Typ ist ein Muster für eine Sys-
temorganisation (Garlan and Shaw, 1993), wie z.B. eine Client/Server-Organisation
oder eine Schichtenarchitektur. Die Kenntnis dieser Typen, ihrer Anwendungen
sowie ihrer Stärken und Schwächen ist von entscheidender Bedeutung. Die Architek-
turen großer Systeme lassen sich meistens jedoch nicht durch einen einzelnen Typ
darstellen. Verschiedene Teile des Systems können unter Benutzung unterschied-
licher Architekturtypen entworfen werden. Ferner kann man in manchen Fällen eine
zusammengesetzte Systemarchitektur verwenden. Das wird durch eine Kombination
verschiedenartiger Architekturmodelle ermöglicht.
Garlan and Shaws Idee eines architektonischen Typs deckt die drei nächsten Prob-
lemstellungen zum Entwurf ab. Sie müssen die am besten geeignete Struktur wählen, die
die Systemanforderungen erfüllen kann, wie z.B. eine Client/Server- oder Schichten-
architektur. Um strukturelle Systemeinheiten in Module zu zerlegen, entscheiden Sie
sich für eine Strategie zur Zerlegung von Subsystemen in ihre Komponenten oder
Module. Die Ansätze, die Sie verwenden können, ermöglichen das Implementieren ver-
schiedener Architekturtypen. Im Prozess zur Steuerungsmodellierung treffen Sie schließ-
lich Entscheidungen darüber, wie das Ausführen von Subsystemen gesteuert wird. Sie
entwickeln ein allgemeines Modell der Steuerbeziehungen zwischen den bestehenden
Systemteilen. Diese drei Themen behandle ich in den Abschnitten 11.2 bis 11.4.
Das Bewerten eines Architekturentwurfs ist schwierig, weil der wahre Test einer
Architektur darin besteht, wie gut es seine funktionalen und nichtfunktionalen Anfor-
derungen nach der Auslieferung erfüllt. In einigen Fällen können Sie jedoch eine Aus-
wertung vornehmen, indem Sie Ihren Entwurf mit Referenz- oder allgemeinen Archi-
tekturmodellen vergleichen. Ich behandle Referenzarchitekturen in Abschnitt 11.5
und allgemeine Architekturen in Kapitel 13.
Das Ergebnis des Architekturentwurfs ist ein Architekturentwurfsdokument. Dieses
kann eine Anzahl grafischer Darstellungen des Systems mit begleitendem, erklären-
dem Text enthalten. Es sollte beschreiben, wie das System in Subsysteme gegliedert
ist, welcher Ansatz verwendet wurde und wie jedes Subsystem in Module strukturiert
ist. Die grafischen Modelle des Systems stellen verschiedene Ansichten der Architek-
tur dar. Die Architekturmodelle können folgende Inhalte aufweisen:
ein statisches Strukturmodell, das die Subsysteme oder Komponenten darstellt, die
als separate Einheiten entwickelt werden sollen.
ein dynamisches Prozessmodell, das zeigt, wie das System zur Laufzeit in Prozesse
gegliedert wird. Dieses Modell kann sich von dem statischen unterscheiden.
11.2 Systemorganisation

• ein Schnittstellenmodell, das die Dienste darstellt, die jedes Subsystem über seine
öffentliche Schnittstelle bereitstellt.
. diverse Beziehungsmodelle, welche die Beziehungen zwischen den Subsystemen,
wie zum Beispiel die Datenflüsse, verdeutlichen .
• ein Vertei1ungsmodell, das angibt, wie Subsysteme über verschiedene Rechner ver-
teilt sein können.
Verschiedene Wissenschaftler haben die Anwendung spezieller Sprachen zur Archi-
tekturbeschreibung (Architectural Description Languages, ADLs) vorgeschlagen. Bass et
al. (Bass et a1. 2003) erläutern die Hauptvorteile dieser Sprachen. Die Grundelemente von
ADLs sind Komponenten und Verbindungselemente, und sie enthalten Regeln und Richt-
linien für wohlgeformte Architekturen. Wie bei allen spezialisierten Sprachen besteht ihr
Nachteil jedoch darin, dass sie nur von Sprachexperten beherrscht werden - für Spezia-
listen bestimmter Fachbereiche und Anwendungen sind sie unpraktikabel. Vom prakti-
schen Standpunkt aus sind sie deshalb schwierig zu handhaben. Aus diesem Grunde
nehme ich an, dass sie nur für eine kleine Anzahl von Projekten benutzt werden. Wahr-
scheinlicher ist, dass in den meisten Fällen informelle Modelle und Notationen wie die
UML (elements, et a1., 2002) für Architekturbeschreibungen benutzt werden.

11.2 Systemorgan isation


Die Organisation eines Systems spiegelt die grundlegende Strategie wider, die zur
Gliederung eines Systems verwendet wird. Sie müssen früh im architektonischen Ent-
wurfsprozess Entscheidungen über das gesamte Organisationsmodell eines Systems
treffen. Die Systemorganisation kann sich unmittelbar in der Struktur der Subsysteme
zeigen. Es ist jedoch oftmals der Fall, dass das Subsystemmodell mehr Einzelheiten
als das Organisationsmodell enthält, und es gibt nicht immer eine einfache Zuord-
nung von Subsystemen auf die organisatorische Struktur.
In diesem Abschnitt behandle ich drei weit verbreitete organisatorische Typen, näm-
lich einen Speichertyp für gemeinsam genutzte Daten, einen Typ für verteilte Dienste
und Server und einen Typ abstrakter Automaten oder geschichteten Typ, in dem das
System in funktionale Schichten gegliedert ist. Diese Schichten können getrennt oder
zusammen genutzt werden. Ein System kann z.B. auf einer gemeinsamen Datenbank
aufgebaut sein, aber darum dann Schichten bilden, um eine abstraktere Sicht auf die
Daten zu bieten.

11.2.1 Das Datenspeichermodell


Die Subsysteme, aus denen ein Gesamtsystem besteh~, müssen Informationen austau-
schen, um auf effektive Weise miteinander zu arbeiten. Es gibt zwei grundlegende
Methoden, wie dies geschehen kann:
o Alle gemeinsam benutzten Daten werden in einer zentralen Datenbank gespei-
chert, die für alle Subsysteme zugänglich ist. Ein Systemmodell, das auf einer
gemeinsamen Datenbank basiert, wird manchmal als Datenspeichermodell oder
Repository-Modell bezeichnet.
D Jedes Subsystem unterhält seine eigene Datenbank. Der Datenaustausch mit an-
deren Subsystemen erfolgt durch das Versenden von Nachrichten.

I 281
ENTWURF DER ARCHITEKTUR

Die Mehrzahl der Systeme, die große Datenmengen benötigen, ist auf einer gemeinsamen
Datenbank oder einem gemeinsamen Repository aufgebaut. Deshalb eignet sich dieses
Modell besonders für Anwendungen, bei denen Daten von einem Subsystem generiert
und von einem anderen verarbeitet werden. Systeme dieses Typs beinhalten Betriebsleit-
systeme, Produktionsplanungssysteme, CAD-Systeme und CASE-Werkzeugsammlungen.
~ Abbildung 11.2 zeigt ein Architekturbeispiel eines CASE-Werkzeugkastens, das auf
einem gemeinsamen Repository basiert. Der erste gemeinsame Datenspeicher für CA SE-
Werkzeuge ist wahrscheinlich in den frühen siebziger Jahren von einem britischen Unter-
nehmen mit dem Namen ICL entwickelt worden, um die eigene Systementwicklung zu
unterstützen (McGuffin et a1., 1979). Dieses Modell erlangte durch die Vorschläge größere
Verbreitung, die Brudon (Buxton, 1980) für die Stoneman-Umgebung bekannt machte, um
die Entwicklung von in der Sprache Ada geschriebenen Systemen zu fördern. Seitdem
sind zahlreiche CASE-Werkzeugsammlungen auf der Basis eines gemeinsamen Reposi-
tory entwickelt worden.

Projektarchiv

Abbildung 11.2: Die Architektur einer integrierten CASE-Werkzeugsammlung

Die Vor- und Nachteile eines gemeinsam genutzten Repository lassen sich wie folgt
gegenüberstellen:
• Es ist eine effiziente Methode, um große Datenmengen gemeinsam zu nutzen. Für eine
direkte Datenübertragung zwischen den Subsystemen besteht keine Notwendigkeit.
• Andererseits müssen die Subsysteme zum Datenspeichermodell passen. Das macht
Kompromisse in Bezug auf die speziellen Erfordernisse jedes Werkzeuges unver-
meidlich. Die Leistungsfähigkeit kann dadurch negativ beeinflusst werden. Das
Integrieren neuer Subsysteme kann schwierig oder sogar unmöglich sein, wenn
deren Datenstruktur nicht in das vereinbarte Schema passt.
• Subsysteme, die Daten generieren, brauchen keine Rücksicht darauf zu nehmen,
wie diese Daten von anderen Subsystemen verarbeitet werden.
• Dagegen kann die Weiterentwicklung schwierig werden, weil als Folge des verein-
barten Datenmodells eine große Informationsmenge erzeugt wird. Diese in ein
neues Modell zu übertragen, wird sicherlich nicht nur teuer, sondern auch schwie-
rig, wenn nicht sogar unmöglich sein.
• Aktivitäten wie Datensicherung, Schutz der Daten, Zugriffskontrolle und die Wieder-
herstellung der Daten nach Fehlfunktionen sind zentralisiert. Sie fallen in die Zustän-
digkeit des Datenspeichermanagers. Alle Werkzeuge können sich auf ihre grund-
legenden Funktionen konzentrieren und sind von den oben genannten Aktivitäten
unberührt.
11.2 Systemorganisation

• Nachteilig kann sich hingegen auswirken, dass die verschiedenen Subsysteme


unterschiedliche Anforderungen an die Datenschutz-, Wiederherstellungs- und Siche-
rungsrichtlinien haben können. Das Datenspeichermodell erfordert jedoch das gleiche
Vorgehen für alle Subsysteme.
• Das Modell der Gemeinsamkeit wird durch das Datenspeicherschema deutlich. Es
ist auf die Integration neuer Werkzeuge ausgerichtet, vorausgesetzt, dass sie mit
dem vereinbarten Datenmodell kompatibel sind.
• Allerdings kann es kompliziert sein, den Datenspeicher auf verschiedene Computer
zu verteilen. Obwohl die Aufteilung eines logisch zentralisierten Datenspeichers
möglich ist, können dadurch Probleme in Form von Datenredundanz und -inkon-
sistenz verursacht werden.
In dem gerade beschriebenen Modell ist der Datenspeicher passiv, und die Steuerung
erfolgt durch die Subsysteme, die ihn benutzen. Ein alternativer Ansatz wurde von KI-
Systemen abgeleitet, die ein "Wandtafelmodell" ("blackboard model") verwenden,
das Subsysteme aktiviert ("triggert"), wenn bestimmte Daten verfügbar werden. Solch
ein Modell ist empfehlenswert, wenn die Form der Speicherdaten weniger gut struk-
turiert ist. Eine Entscheidung darüber, welches Werkzeug zu aktivieren ist, kann erst
getroffen werden, nachdem die Daten analysiert worden sind. Dieses Modell wird von
Nii (Nii, 1986) erläutert, und Bosch (Bosch, 2000) fügt eine gute Erörterung darüber
hinzu, wie dieser Typ mit Systemqualitätsmerkmalen in Beziehung steht.

11.2.2 Das Client/Server-Modell


Das Client/Server-Architekturmodell ist ein Systemmodell, in dem das System aus einer
Anzahl von Diensten und zugehörigen Servern besteht, sowie aus Clients, die auf diese
Dienste zugreifen und sie nutzen. Die Hauptkomponenten dieses Systems sind:
• eine Gruppe von Servern, welche Dienste für andere Subsysteme anbieten. Solche
Server können beispielsweise Druckserver, die Druckerdienste anbieten, Datei-
server für Dateiverwaltungsdienste und Compiler-Server für die Kompilierung von
Programmiersprachen sein.
• eine Anzahl von Clients, welche die von den Servern angebotenen Dienste abrufen.
Dabei handelt es sich normalerweise um unabhängige Subsysteme. Es kann durch-
aus vorkommen, dass ein Clientprogramm mehrmals gleichzeitig ausgeführt wird.
• ein Netzwerk, über das die Clients auf die Dienste zugreifen können. Dies wäre
prinzipiell nicht erforderlich, weil sowohl die Clients als auch die Server auf dem-
selben Computer laufen könnten. In der Praxis sind die meisten Client/Server-Sys-
terne jedoch als verteilte Systeme implementiert.
Clients müssen die Namen der verfügbaren Server und der Dienste kennen, die diese
anbieten. Die Server benötigen jedoch keine Informationen über die Identität und die
Zahl der möglichen Clients. Die Clients greifen über remote procedure calls (RPC, Pro-
zeduraufrufe über das Netz) auf die Dienste der Server zu, indem sie ein Frage-Ant-
wort-Protokoll wie http im WWW verwenden. Im Wesentlichen macht der Client eine
Anfrage beim Server und wartet, bis er eine Antwort erhält.
~ Abbildung 11.3 zeigt ein System, das auf einem Client/Server-Modell aufbaut. Es
handelt sich um ein Hypertextsystem für viele Benutzer, das eine Film- und Fotobiblio-
thek anbietet. In diesem System verwalten mehrere Server die verschiedenen Medien-

283
ENTWURF DER ARCHITEKTUR

arten und zeigen sie an. Einzelbilder von Videos müssen schnell und synchron, aber
mit relativ geringer Auflösung übertragen werden. Sie können in einem Speicher kom-
primiert werden, so dass der Videoserver die Kompression und Dekompression der
Videos in verschiedene Formate vornehmen kann. Bei Standbildern ist dagegen eine
Übertragung in hoher Auflösung erforderlich, so dass es angebracht ist, sie auf einem
gesonderten Server zu verwalten.

I
TTTT Internet I

t
Abbildung 11.3: Die Architektur eines Bibliothekssystems für Filme und Bilder

Der Katalog muss in der Lage sein, eine Vielfalt von Anfragen zu bewältigen und Ver-
bindungen zu dem Hypertext-Informationssystem anzubieten, das Daten über den Film
und den Videoclip enthält, sowie ein E-Commerce-System, das den Verkauf von Filmen
und Videoclips unterstützt. Bei dem Clientprogramm handelt es sich lediglich um eine
integrierte Bedienoberfläche zu diesen Diensten, die einen Web-Browser verwendet
Der größte Vorteil des Client/Server-Modells besteht in seiner verteilten Architektur.
Netzwerksysteme mit vielen verteilten Prozessoren können sehr effektiv genutzt werden.
Das Hinzufügen und die Integration oder die transparente Erweiterung eines neuen Ser-
vers ist ohne Beeinträchtigung anderer Systemteile leicht möglich. Ich werde auf die ver-
teilten Architekturen einschließlich der Client/Server-Architekturen und der verteilten
Objektarchitekturen in Kapitel 12 näher eingehen.
Allerdings kann es notwendig sein, vorhandene Server und Clients zu modifizieren,
um Vorteile durch die Integration eines neuen Servers voll auszunutzen. Es kann sein,
dass es kein gemeinsames Datenmodell über die Server hinweg gibt, und Subsysteme
organisieren ihre Daten normalerweise nicht auf die gleiche Weise. Das bedeutet, dass
spezielle Datenmodelle für jeden Server eingerichtet werden können, um deren Leis-
tungsfähigkeit zu optimieren. Wenn eine XML-basierte Datendarstellung verwendet
wird , kann es natürlich relativ einfach sein, von einem Schema in ein anderes umzu-
wandeln. XML ist jedoch eine leistungsschwache Art der Datendarstellung, so dass in
diesem Fall Probleme mit der Leistungsfähigkeit auftreten können.

11.2.3 Das Schichtenmodell


Das Schichtenmodell einer Architektur (manchmal auch als Modell aus abstrakten
Automaten bzw. Maschinen bezeichnet) teilt das System in verschiedene Schichten
ein, die jeweils ein Paket von Diensten bereitstellen. Jede Schicht definiert eine abs-
trakte Maschine, deren Maschinensprache über die von der Schicht bereit gestellten
11.2 Systemorganisation

Dienste definiert wird. Diese "Sprache" wird genutzt, um die nächste abstrakte
Maschine zu implementieren. Eine übliche Methode zur Implementierung einer Spra-
che besteht beispielsweise darin, eine ideale "Sprachrnaschine" zu definieren und die
Sprache in Code für diese Maschine zu transformieren. Eine weitere Übersetzung
wandelt diese abstrakte Maschinensprache dann in wirklichen Maschinencode um.

Schicht des Konfigurationsmanagementsystems

Schicht des Objektmanagementsystems

Schicht des Datenbanksystems

Schicht des Betriebssystems

Abbildung 11.4: Schichtenmodell eines Versionsverwaltungssystems

Ein Beispiel eines Schichtenmodells ist das OSI-Referenzmodell von Netzwerkprotokol-


len (Zimmermann, 1980), das in Abschnitt 11.5 beschrieben wird Ein anderes Beispiel
von größerer Bedeutung wurde von Buxton (Buxton, 1980) vorgestellt, der ein Drei-
Schichten-Modell für die Unterstützungsumgebung zur Ada-Prograrnrnierung (Ada Pro-
grarnming Support Environment, APSE) vorschlägt. ~ Abbildung 11.4 spiegelt die
APSE-Struktur wider und zeigt, wie ein Konfigurationsmanagementsystem integriert
werden kann, das diesen Ansatz abstrakter Maschinen benutzt.
Das Konfigurationsmanagementsystem verwaltet Versionen von Objekten und bietet
allgemeine Möglichkeiten für das Konfigurationsmanagement an (siehe Kapitel 29). Um
diese Funktionen zu unterstützen, benutzt es ein Objektrnanagementsystem, welches
Speicher- und Verwaltungs dienste für Konfigurationsgegenstände oder Objekte bereit-
stellt. Dieses System basiert auf einern Datenbanksystem, das die grundlegende Spei-
cherung der Daten und Dienste wie Transaktionsmanagement, Rückgängigmachung
und Wiederherstellung sowie Zugriffskontrolle anbietet. Das Datenbankrnanagement
benutzt die zugrunde liegenden Möglichkeiten des Betriebssystems und der Datei-
speicherung bei seiner Implementierung. Weitere Beispiele von Schichtenmodellen fin-
den Sie in Kapitel 13.
Der Schichtenansatz begünstigt die schrittweise Entwicklung von Systemen. Sobald
eine Schicht entwickelt worden ist, können einige der in dieser Schicht enthaltenen
Dienste für die Benutzer verfügbar gemacht werden. Diese Architektur ist zudem leicht
veränderbar und portierbar. Solange die Schnittstellen nicht verändert werden, kann
man eine Schicht komplett durch eine andere, gleichbedeutende ersetzen. Wenn sich
die Schnittstellen einer Schicht hingegen ändern, wird davon nur die angrenzende
Schicht betroffen. Da bei Schichtensystemen die maschinenabhängigen Eigenschaften
in den inneren Schichten angeordnet sind, können sie relativ leicht auf anderen Com-
putern implementiert werden, indern man die inneren, maschinenspezifischen Schich-
ten neu erstellt.

I 285
ENTWURF DER ARCHITEKTUR

Ein Nachteil des Schichtenansatzes besteht in den Schwierigkeiten. die mit der Struk-
turierung von Systemen dieser Art verbunden sein können. Grundlegende Funktionen
wie die Dateiverwaltung. die alle abstrakten Maschinen benötigen. werden eventuell
von den inneren Schichten bereitgestellt. Die von den Benutzern angeforderten Dienste
können somit den Zugriff auf eine abstrakte Maschine erforderlich machen. die mehrere
Ebenen unterhalb der äußeren Schicht angeordnet ist. Das steht im Widerspruch zu die-
sem Modell. weil dadurch eine äußere Schicht nicht mehr ausschließlich von der direkt
benachbarten Schicht abhängt.
Auch die Leistungsfähigkeit kann wegen der manchmal notwendigen zahlreichen
Ebenen der Befehlsinterpretation leiden. Bei einer großen Zahl von Ebenen muss eine
Dienstanfrage von einer oberen Schicht vor ihrer Verarbeitung möglicherweise meh-
rere Male in verschiedenen Schichten interpretiert werden. Um diese Schwierigkeiten
zu vermeiden. kann es nötig sein. dass Anwendungen direkt mit den inneren Schich-
ten kommunizieren. anstatt die Dienste der nächstgelegenen Schicht zu benutzen.

11.3 Modulare Dekompositionen


Nachdem eine Gesamtsystemorganisation ausgewählt wurde. müssen Sie eine Entschei-
dung über den Ansatz treffen. der zur Dekomposition (zum Zerlegen) von Subsystemen
in Module verwendet werden soll. Es gibt keine eindeutige Unterscheidung zwischen
der Systemdekomposition und der modularen Dekomposition. Die in Abschnitt 11 .2
behandelten Modelle können an dieser Stelle angewendet werden. Die Komponenten
von Modulen sind jedoch normalerweise kleiner als Subsysteme. was die Benutzung
alternativer Dekompositionstypen ermöglicht.
Es gibt keinen eindeutigen Unterschied zwischen Subsystemen und Modulen. ich
halte jedoch die folgende Unterscheidung für sinnvoll:
• Bei einem Subsystem handelt es sich um ein eigenständiges System. dessen Opera-
tionen nicht von den Diensten anderer Subsysteme abhängen. Subsysteme sind aus
Modulen aufgebaut und haben definierte Schnittstellen. die zur Kommunikation
mit anderen Subsystemen dienen .
• Ein Modul ist normalerweise eine Systemkomponente. die einen oder mehrere Dienste
für andere Module bereitstellt. Es macht von Diensten anderer Module Gebrauch und
wird gewöhnlich nicht als unabhängiges System angesehen. Module sind normaler-
weise aus einer Anzahl anderer. einfacherer Systemkomponenten aufgebaut.
Für die Zerlegung eines Subsystems in Module gibt es zwei Hauptstrategien:
o Objektorientierte Zerlegung. bei der Sie ein System in eine Anzahl miteinander
kommunizierender Objekte aufteilen.
D Funktionsorientierte Pipeline. bei der Sie ein System in funktionale Module zer-
legen. die Eingangsdaten empfangen und in Ausgabedaten umformen.
Beim objektorientierten Modell sind Module Objekte mit eigenem Zustand und mit
auf diesem Zustand definierten Operationen. im Pipelinemodell dagegen funktionale
Transformationen. In beiden Fällen können Module als sequenzielle Komponenten
oder als Prozesse implementiert werden.
11.3 Modulare Dekompositionen

Kunde Quittung
Kundennr. Rechnungsnr.
Name -c:- I
- .. Datum
Adresse Rechnung Betrag
Zahlungsziel Kundennr.
Rechnungsnr.
Datum
Betrag
Kundennr.
Zahlung

Rechnungsnr.
Datum
Betrag
- - .. issue ()
sendReminder ()
acceptPayment ()
sendReceipt ()
Kundennr.

Abbildung 11.5: Das Objektmodell eines Systems zur Rechnungsbearbeitung

Sie sollten vermeiden, zu früh Entscheidungen über die Nebenläufigkeit zu treffen.


Der Vorteil bei der Vermeidung nebenläufiger Systementwürfe besteht darin, dass
sequenzielle Systeme einfacher zu entwerfen, zu implementieren, zu verifizieren und
zu testen sind als parallele Systeme. Zeitliche Abhängigkeiten zwischen verschiede-
nen Prozessen sind schwierig zu formalisieren, zu steuern und zu verifizieren. Es ist
am besten, die Systeme in Module aufzuteilen und später während der Implementie-
rung zu entscheiden, ob diese nebenläufig oder sequenziell ausgeführt werden sollen.

11.3.1 Objektorientierte Dekomposition


Ein objektorientiertes architektonisches Modell strukturiert das System in eine Reihe
von lose gekoppelten Objekten mit genau definierten Schnittstellen. Objekte benutzen
die Dienste anderer Objekte. Ich habe in Kapitel 8 bereits Objektmodelle vorgestellt,
und ich werde auf den objektorientierten Entwurf noch ausführlicher in Kapitel 14
eingehen.
In ~ Abbildung 11.5 ist ein Beispiel eines objektorientierten Architekturmodells für
ein System zur Bearbeitung von Rechnungen dargestellt. Dieses System kann Rechnun-
gen an Kunden senden, Zahlungen verbuchen, Quittungen für eingegangene Zahlun-
gen ausstellen und Mahnungen für ausstehende Zahlungen veranlassen. Ich benutze
die in Kapitel 8 vorgestellte Notation der UML, wobei den Objektklassen Namen und
eine Anzahl von Attributen zugeordnet sind. Eventuell vorhandene Operationen sind
im unteren Teil des Rechtecks definiert. Gestrichelte Pfeile deuten an, dass ein Objekt
die von einem anderen Objekt bereitgestellten Attribute oder Dienste benutzt.
Eine objektorientierte Dekomposition bezieht sich auf Objektklassen sowie deren
Attribute und ihre Operationen. Durch die Implementierung werden Objekte aus diesen
Klassen erzeugt, und zur Koordination der Objektaktivitäten wird eine Art Steuerungs-
modell benutzt - in diesem speziellen Beispiel die Klasse Rechnung, der verschiedene
Operationen zugeordnet sind, welche die Systemfunktionalität implementieren. Diese
Klasse macht von anderen Klassen Gebrauch, welche Kunden, Zahlungen und Zah-
lungseingänge repräsentieren.
Die Vorteile des objektorientierten Ansatzes sind allgemein bekannt. Da die Objekte
nur lose gekoppelt sind, kann die Implementierung von Objekten geändert werden,
ohne andere Objekte zu beeinflussen. Objekte repräsentieren häufig real existierende

I 287
ENTWU RF DER ARCHITEKTU R

Gegenstände oder Personen, so dass die Struktur des Systems einfach zu verstehen ist.
Weil die real existierenden Entitäten in verschiedenen Systemen benutzt werden,
besteht die Möglichkeit, Objekte wieder zu verwenden. Es sind objektorientierte Pro-
grammiersprachen entwickelt worden, welche die direkte Implementierung von Archi-
tekturkomponenten ermöglichen.
Aber auch der objektorientierte Ansatz weist durchaus einige Nachteile auf. Die
Objekte müssen die Namen und Schnittstellen anderer Objekte kennen, um deren
Dienste nutzen zu können. Wenn notwendige Systemänderungen die Anpassung einer
Schnittstelle erforderlich machen, muss untersucht werden, wie sich dies auf sämt-
liche Benutzer des geänderten Objekts auswirkt. Während sich real existierende Enti-
täten kleineren Maßstabs eindeutig als Objekte darstellen lassen, sind komplexere
Dinge manchmal sehr schwierig als Objekte zu definieren.

11.3.2 Funktionsorientierte Pipeline


In einer funktionsorientierten Pipeline oder einem Datenflussmodell werden Eingangs-
daten von funktionalen Transformationen verarbeitet und in Ausgabedaten umgewan-
delt. Daten fließen von einem Prozess zum anderen und werden dabei verändert. Jeder
Prozessschritt wird als Umformung implementiert. Eingangsdaten durchlaufen diese
Umformungen, bis sie in Ausgabedaten konvertiert sind. Die Transformationen können
nacheinander oder parallel ablaufen. Eine Datenmenge kann von jeder Umformung
Posten für Posten oder als Gesamtpaket verarbeitet werden.
Wenn die Transformationen als separate Prozesse dargestellt werden, spricht man
manchmal von dem "Pipe and Filter"-Typ, der aus der Unix-Terminologie stammt. Das
Unix-System verfügt über so genannte Pipes, welche als Datenleitungen fungieren, und
einen Befehlssatz, der aus funktionalen Transformationen besteht. Systeme, die diesem
Modell entsprechen, können durch die Kombination von Unix-Befehlen, welche die
Pipes benutzen, mit den Steuerungsmöglichkeiten der Unix-Shell implementiert wer-
den. Die Bezeichnung Filter wird benutzt, weil eine Transformation die Daten, die sie
verarbeiten kann, aus dem Eingangsdatenstrom 'heraus filtert' .
Varianten dieses Pipelinemodells sind schon so lange bekannt, wie Computer für
automatische Datenverarbeitung verwendet werden. Wenn Transformationen sequen-
ziell auf in Stapeln (batches) verarbeitete Daten angewandt werden, befolgt diese
Architektur ein sequenzielles Stapelmodell. Wie ich in Kapitel 13 darlegen werde, ist
. dies für Daten verarbeitende Systeme wie Fakturierungssysteme eine gebräuchliche
Architektur. Datenverarbeitungssysteme geben in der Regel eine große Anzahl von
Berichten aus, die durch einfache Berechnungen aus einer großen Anzahl von Ein-
gangsdaten erstellt wurden.
Ein Beispiel dieser Systemarchitektur ist in ~ Abbildung 11.6 dargestellt. Eine Orga-
nisation hat Rechnungen an Kunden ausgestellt. Einmal pro Woche werden Zahlungs-
eingänge mit den Rechnungen abgeglichen. Für die bezahlten Rechnungen wird eine
Quittung ausgestellt. Für Rechnungen, die nicht innerhalb des vereinbarten Zahlungs-
zieles beglichen werden, wird eine Mahnung veranlasst.
Dieses Modell umfasst nur die Rechnungsbearbeitung. Für die Rechnungserstellung
müssten andere Transformationen benutzt werden. Beachten Sie die Unterschiede
zwischen diesem und dem entsprechenden objektorientierten Modell im vorigen
Abschnitt. Das Objektmodell ist abstrakter, weil es keine Information über die Reihen-
folge der Operationen enthält.
11.4 Steuerungstypen

Mahnunge:Jj

Abbildung 11.6: Das Pipelinemodell eines Systems zur Rechnungsbearbeitung

Die Vorteile dieser Architektur sind:


• Sie unterstützt die Wiederverwendung von Transformationen.
• Sie ist intuitiv, weil viele Menschen ihre Arbeit als eine Folge von Verarbeitungs-
schritten mit Eingaben und Ausgaben betrachten.
• Eine Weiterentwicklung des Systems kann normalerweise auf einfache Weise durch
das Hinzufügen neuer Transformationen erfolgen.
• Sie lässt sich sowohl als nebenläufiges als auch sequenzielles System einfach imple-
mentieren.
Der grundlegende Nachteil dieses Typs beruht auf der Notwendigkeit eines einheit-
lichen Datenformats, das alle Transformationen verarbeiten können. Jede Transforma-
tion muss sich entweder mit allen Transformationen, mit denen sie kommuniziert,
über das zu verarbeitende Datenformat abstimmen, oder es ist ein Standarddatenfor-
mat für die gesamte Kommunikation erforderlich. Der letztere Ansatz ist die einzige
Möglichkeit, wenn die Transformationen eigenständig und wieder verwendbar sind.
In Unix besteht das Standardformat schlicht aus einer Zeichenfolge. Jede Transforma-
tion muss ihre Ein- und Ausgabedaten an diese Form anpassen. Das erhöht den Auf-
wand im System und kann die Integration von Transformationen mit inkompatiblen
Datenformaten unmöglich machen.
Interaktive Systeme sind nach dem Pipelinemodell schwer zu entwickeln, weil sie
einen Datenstrom verarbeiten müssen. Während einfache textähnliche Ein- und Aus-
gaben auf diese Weise leicht modelliert werden können, haben die Ein- und Ausgabe-
formate und die Steuerung grafischer Bedienoberflächen eine komplexere Struktur,
die auf Ereignisse wie Mausklicks oder die Auswahl von Menüoptionen reagieren
muss. Dies kann nur schwer in eine Form gebracht werden, die mit dem Pipeline-
modell verträglich ist.

11.4 Steuerungstypen
Die Modelle zur Strukturierung eines Systems befassen sich mit der Gliederung des
Systems in Subsysteme. Um als einheitliches System arbeiten zu können, müssen die
Subsysteme so gesteuert werden, dass ihre Dienste zur richtigen Zeit am richtigen Ort
eingesetzt werden. Strukturmodelle enthalten keine Steuerungsinformationen (und
sollen es auch nicht). Vielmehr sollte der Architekt die Subsysteme anhand eines
Steuerungsmodells organisieren, welches das benutzte Strukturmodell ergänzt. Steue-
rungsmodelle auf Architekturebene beschäftigen sich mit den Steuerungsabläufen
zwischen den Subsystemen.

I 289
ENTWURF DER ARCHITEKTUR

In Softwaresystemen werden diese allgemeinen Steuerungstypen verwendet:


• Zentrale Steuerung: Hierbei ist ein einziges Subsystem für die Steuerung verant-
wortlich, d. h. es startet und stoppt die anderen Subsysteme. Es kann Steuerungs-
aktivitäten an ein anderes Subsystem delegieren, erwartet dann allerdings, dass
diese Steuerungszuständigkeit wieder zurückgegeben wird.
• Ereignisbasierte Steuerung: Anders als bei der Anordnung der Steuerungsinfor-
mation in einem speziellen Subsystem kann hier jedes Subsystem individuell auf
extern verursachte Ereignisse reagieren. Diese Ereignisse können von anderen Sub-
systemen oder von der Systemumgebung ausgelöst werden.
Die Steuerungstypen ergänzen die Strukturtypen. Alle erwähnten Strukturtypen können
sowohl mit zentralisierter als auch mit ereignisbasierter Steuerung realisiert werden.

11.4.1 Zentrale Steuerung


In einem zentralisierten Steuerungsmodell wird ein Subsystem für die Systemsteuerung
bestimmt und ist damit für die Ablaufsteuerung von anderen Subsystemen verantwort-
lich. Zentralisierte Steuerungsmodelle lassen sich in zwei Klassen einteilen, je nach-
dem, ob die steuernden Subsysteme ihre Steuerungsfunktionen sequenziell oder paral-
lel ausführen:
• Aufruf/Rückgabe-Modell: Dies ist das bekannte, eine Ablaufrichtung implizierende
Subroutinenmodell, bei dem die Steuerung an der Spitze einer Hierarchie von Sub-
routinen beginnt und sich durch Aufrufe von Subroutinen innerhalb der Hierarchie
nach unten bewegt. Das Subroutinenmodell ist nur auf sequenzielle Systeme
anwendbar.
• Managermodell: Dieses Modell ist auf nebenläufige Systeme anwendbar. Eine
Systemkomponente wird als Systemmanager bestimmt und steuert den Beginn, das
Ende und die Koordination anderer Systemprozesse. Ein Prozess ist ein Subsystem
oder ein Modul, das parallel mit anderen Prozessen ausgeführt werden kann. Eine
Variante dieses Modells lässt sich auch in sequenziellen Systemen anwenden, bei
denen eine Managementroutine abhängig von den Werten einiger Zustandsvariab-
len bestimmte Subsysteme aufruft. Dies wird normalerweise als case-Anweisung
implementiert.

17"""~1 I;"""e~ I
I
~----~~

Routine 1.1 II Routine 1.2 I ~----~~

Routine 3.1 Routine 3.2

Abbildung 11.7: Das Aufruf/Rückgabe-Steuerungsmodell


11.4 Steuerungstypen

~ Abbildung 11.7 zeigt das Aufruf/Rückgabe-Modell. Das Hauptprogramm kann die


Routinen 1,2 und 3 aufrufen, Routine 1 kann die Routinen 1.1 oder 1.2 aufrufen, Rou-
tine 3 kann die Routinen 3.1 oder 3.2 aufrufen und so weiter. Dies ist ein Modell der
Programmdynamik. Es ist kein Strukturmodell, denn es besteht nicht die Notwendig-
keit, dass beispielsweise die Routine 1.1 ein Teil von Routine 1 ist.
Dieses geläufige Modell findet in Programmiersprachen wie Ada, Pascal oder C Ver-
wendung. Die Steuerung bewegt sich innerhalb der Hierarchie von Routinen auf höhe-
ren Ebenen zu Routinen auf niedrigeren Ebenen. Sie kehrt dann zu dem Punkt zurück,
wo die Routine aufgerufen wurde. Die aktuell ausgeführte Subroutine ist für die Steue-
rung verantwortlich und kann entweder andere Routinen aufrufen oder die Steuerung
an ihre übergeordnete Routine zurückgeben. Zu einem anderen Punkt im Programm
zurückzugehen ist schlechter Programmierstil.
Dieses Aufruf/Rückgabe-Steuerungsmodell kann auf der Modulebene zur Steuerung
von Funktionen oder Objekten eingesetzt werden. Subroutinen in einer Programmier-
sprache, die durch andere Subroutinen aufgerufen werden können, sind natürlich
funktional. In vielen objektorientierten Systemen werden allerdings Operationen an
Objekten (Methoden) als Prozeduren oder Funktionen implementiert. Wenn beispiels-
weise ein Java-Objekt einen Dienst von einem anderen Objekt anfordert, geschieht
dies durch den Aufruf einer zugehörigen Methode.
In der starren und begrenzten Natur dieses Modells liegen Stärke und Schwäche
zugleich. Die Stärke besteht darin, dass Steuerungsabläufe relativ einfach zu analysie-
ren sind und leicht festgestellt werden kann, wie das System auf bestimmte Einflüsse
reagieren wird. Es ist aber eine Schwäche, dass Abweichungen vom normalen Betrieb
umständlich zu handhaben sind.
~ Abbildung 11.8 zeigt ein zentralisiertes Managementmodell der Steuerung eines
nebenläufigen Systems. Dieses Modell wird oft in so genannten "weichen" Echtzeit-
systemen benutzt, bei denen nicht sehr strenge zeitliche Bedingungen bestehen. Die
zentrale Steuerung regelt die Ausführung einer Reihe von Prozessen, die mit Sensoren
und Aktoren verbunden sind. Das System zur Gebäudeüberwachung, das in Kapitel
15 behandelt wird, entspricht diesem Steuerungsmodell.

Abbildung 11 .8: Ein zentrales Steuerungsmodell für ein Echtzeitsystem

Der Prozess der Systemsteuerung entscheidet in Abhängigkeit von den Systemzustands-


variablen, wann Prozesse gestartet oder beendet werden sollen. Er prüft, ob andere Pro-
zesse Informationen erzeugt haben, die verarbeitet werden, oder ob Informationen für die

I 291
ENTWURF DER ARCHITEKTUR

Verarbeitung an sie übergeben werden müssen. Die Steuerung arbeitet in einem kontinu-
ierlichen Kreislauf, in dem sie Sensoren und andere Prozesse systematisch auf Ereignisse
und Zustandsänderungen abfragt. Deshalb wird dieses Modell manchmal auch Ereignis-
schleifenmodell (event loop model) genannt.

11.4.2 Ereignisgesteuerte Systeme


In zentralisierten Steuerungsmodellen werden Steuerungsentscheidungen normaler-
weise durch Bestimmung der Werte von Zustandsvariablen gefällt. Im Gegensatz dazu
reagieren ereignis basierte Steuerungsmodelle auf extern verursachte Ereignisse. Die
Bezeichnung Ereignis bedeutet in diesem Zusammenhang nicht einfach nur ein binä-
res Signal, sondern ein Signal, das in einen Wertebereich liegen oder eine Befehls-
eingabe aus einem Menü annehmen kann. Der Unterschied zwischen einem Ereignis
und einem einfachen Eingangssignal ist, dass der Zeitpunkt, zu dem das Ereignis ein-
tritt, außerhalb der Kontrolle des Prozesses liegt, auf das dieses Ereignis reagiert.
Es gibt viele Arten ereignisgesteuerter Systeme. Dazu gehören Editoren, bei denen
Ereignisse der Benutzerschnittstelle Editierbefehle bedeuten, regelbasierte Produk-
tionssysterne, wie sie in der KI benutzt werden, bei denen das Wahrwerden einer
Bedingung eine Aktion auslöst, und aktive Objekte, bei denen die Änderung des Werts
eines Objektattributs eine Aktion auslöst. Garlan et al. (Garlan et al., 1992) befassen
sich mit diesen verschiedenen Systemtypen.
In diesem Abschnitt werde ich diese bei den ereignisbasierten Steuerungsmodelle
beschreiben:
• Broadcast-Modelle: Bei diesen Modellen besteht ein Ereignis normalerweise in
einer Versendung an alle Subsysteme. Jedes Subsystem, das dazu programmiert ist,
dieses Ereignis zu behandeln, kann darauf reagieren .
• Interrupt-getriebene Modelle: Diese werden ausschließlich in Echtzeitsystemen
benutzt, bei denen externe Interrupts von einem Interrupt-Handler festgestellt und
dann zur Verarbeitung an eine andere Komponente weitergeleitet werden.
Broadcast-Modelle eignen sich hervorragend zur Integration von Subsystemen, die auf
verschiedene Computer innerhalb eines Netzwerkes verteilt sind. Interrupt-basierte
Modelle werden in Echtzeitsystemen mit strengen Anforderungen an die zeitliche
Synchronisierung verwendet.
In einem Broadcast-Modell nach ~ Abbildung 11.9 melden Subsysteme ein Interesse
an bestimmten Ereignissen an. Wenn solche eintreten, werden Steuerbefehle an das
System gesendet, welches dieses Ereignis behandeln kann. Der Unterschied zwischen
diesem Modell und dem zentralisierten Modell in ~ Abbildung 11.8 besteht darin, dass
die Steuerungspolitik nicht in den Ereignis- und Nachrichten-Handler eingebettet ist.
Die Subsysteme entscheiden selbst, welche Ereignisse sie benötigen, und der Ereignis-
und Nachrichten-Handler sorgt dafür, dass ihnen diese Ereignisse zugesandt werden.

Ereignis- und Nachrichten-Handler

Abbildung 11.9: Ein auf selektivem Broadcasting basierendes Steuerungsmodell


11.4 Steuerungstypen

Im Prinzip könnten alle Ereignisse per Broadcast ("Rundfunk") an alle Subsysteme


gesandt werden, aber das würde eine enorme Menge überflüssiger Arbeitsprozesse
erzeugen. In der Mehrzahl der Fälle wird der Ereignis- und Nachrichten-Handler ein
Verzeichnis mit den Subsystemen und den für sie interessanten Ereignissen verwal-
ten. Subsysteme generieren Ereignisse, die (zum Beispiel) anzeigen, dass gewisse
Daten zur Verarbeitung bereitstehen. Der Ereignis-Handler stellt die Ereignisse fest,
sieht im Ereignisverzeichnis nach und sendet das Ereignis an diejenigen Subsysteme,
welche ein Interesse daran angemeldet haben. In einfachen Systemen, z.B. von Ereig-
nissen der Benutzerschnittstelle gesteuerten pes, gibt es explizite auf Ereignisse von
Maus, Tastatur usw. wartende Subsysteme, die diese Ereignisse in speziellere Befehle
übersetzen.
Der Ereignis-Handler unterstützt normalerweise auch die Punkt-zu-Punkt-Kommuni-
kation, d. h. ein Subsystem kann eine Nachricht ausschließlich an ein anderes Subsys-
tem senden. Es sind verschiedene Varianten dieses Modells verwirklicht worden, wie
zum Beispiel die Fjeld-Umgebung (Reiss, 1990) und Softbench von Hewlett-Packard
(Fromme und Walker, 1993). Beide Modelle dienten dazu, die Zusammenarbeit von
Werkzeugen in Softwareentwicklungsumgebungen zu steuern. Auch so genannte
Object Request Broker (ORB, wörtlich Objektanfragenvermittler), die in Kapitel 12
beschrieben werden, unterstützen dieses Steuerungsmodell für die verteilte Kommuni-
kation zwischen Objekten.
Der Vorteil dieses Broadcast-Ansatzes ist die relativ einfache Weiterentwicklung.
Ein neues Subsystem, das spezielle Klassen von Ereignissen behandeln kann, ist
leicht zu integrieren, indem seine Ereignisse beim Ereignis-Handler registriert wer-
den. Jedes Subsystem kann jedes beliebige andere Subsystem aktivieren, ohne dessen
Namen oder Standort zu kennen. Die Subsysteme können auf verschiedene Rechner
verteilt implementiert werden. Die Verteilung ist für andere Subsysteme transparent,
also nicht sichtbar.
Der Nachteil dieses Modells ist, dass die Subsysteme nicht wissen, ob und wann ein
Ereignis behandelt wird. Wenn ein Subsystem ein Ereignis erzeugt, weiß es nicht,
welches andere Subsystem ein Interesse daran registriert hat. Dadurch ist es natürlich
möglich, dass sich verschiedene Subsysteme für dieselben Ereignisse registrieren las-
sen. Das kann bei den Ergebnissen der Ereignisbehandlung zu Konflikten führen.
Echtzeitsysteme, die eine sehr schnelle Verarbeitung von extern generierten Ereig-
nissen verlangen, müssen ereignisbasiert sein. Wenn ein Echtzeitsystem zum Beispiel
zur Steuerung der Sicherheitssysteme eines Kraftfahrzeugs eingesetzt wird, muss es
einen möglichen Aufprall feststellen und eventuell den Airbag aktivieren, bevor der
Kopf des Fahrers auf das Lenkrad aufschlägt. Um diese blitzschnelle Reaktion auf
äußere Ereignisse zu gewährleisten, muss eine Interrupt-basierte Steuerung zum Ein-
satz kommen.
Ein Interrupt-basiertes Steuerungsmodell ist in ~ Abbildung 11.10 dargestellt. Es
gibt eine bekannte Anzahl von Interrupt-Typen mit jeweils einem zugeordneten Hand-
ler. Jeder Interrupt-Typ ist mit dem Speicherplatz verbunden, an dem die Adresse des
Handlers abgelegt ist. Wenn ein Interrupt eines bestimmten Typs ankommt, wird die
Steuerung durch einen Hardwareschalter unmittelbar auf den zugehörigen Handler
übertragen. Dieser Interrupt-Handler kann dann als Reaktion auf die vom Interrupt
signalisierten Ereignisse andere Prozesse ein- oder ausschalten.
Dieses Modell wird hauptsächlich in Echtzeitsystemen eingesetzt, bei denen eine
sofortige Reaktion auf bestimmte Ereignisse notwendig ist. Es kann mit dem zentrali-

I 293
ENTWURF DER ARCHITEKTUR

sierten Managementmodell kombiniert werden. Der zentrale Manager steuert die nor-
malen Arbeitsabläufe des Systems, während die Steuerung der Notfälle auf der Basis
von Interrupts erfolgt.
Interrupts

Interrupt-
Vektor

Abbildung 11.10: Ein Interrupt-basiertes Steuerungsmodell

Der Vorteil dieses Ansatzes liegt darin, dass er das Implementieren sehr schneller
Reaktionen auf Ereignisse ermöglicht. Der Nachteil liegt in der komplexen Program-
mierung und der schwierigen Validierung. Während des Systemtests können die zeit-
lichen Ablaufmuster von Interrupts eventuell nicht nachvollzogen werden. Es kann
schwierig sein, nach diesem Modell entwickelte Systeme zu ändern, wenn die Zahl
der Interrupts durch die Hardware begrenzt ist. Beim Erreichen dieser Grenze können
keine weiteren Ereignistypen mehr behandelt werden. Diese Begrenzung lässt sich in
manchen Fällen umgehen, indem verschiedene Typen von Ereignissen auf einen ein-
zigen Interrupt abgebildet werden und dann der Handler feststellt, um welches Ereig-
nis es sich handelt. Dieser Ausweg kann sich aber als unpraktikabel erweisen, wenn
sehr schnelle Reaktionen auf den Interrupt erforderlich sind.

11.5 Referenzarch itektu ren


Die bisher beschriebenen Architekturmodelle sind allgemeiner Art: Sie können für
eine Vielzahl verschiedener Anwendungsarten Verwendung finden. Ebenso wie diese
allgemeinen Modelle kann man aber auch Architekturmodelle für einen speziellen
Problembereich benutzen. Auch wenn sich Teile dieser Systeme im Detail unterschei-
den, kann die gemeinsame Struktur der Architektur für die Entwicklung neuer Sys-
teme erneut verwendet werden. Diese Architekturmodelle werden problembereichs-
spezifische Architekturen genannt.
Es gibt zwei Arten von problembereichsspezifischen Architekturen:
• Allgemeine Modelle stellen Abstraktionen einer Reihe von realen Systemen dar. Sie
beinhalten die prinzipiellen Charakteristika dieser Systeme. Beispielsweise können
in Echtzeitsystemen verschiedene allgemeine Architekturmodelle für verschiedene
Systemtypen wie etwa Datenerfassungs- oder Überwachungssysteme enthalten sein.
Ich behandle eine Reihe von allgemeinen Modellen in Kapitel 13, das sich mit
Anwendungsarchitekturen befasst. In diesem Abschnitt konzentriere ich mich auf
architektonische Referenzmodelle.
11.5 Referenzarchitekturen

• ReJerenzmodelle, die stärker abstrahiert sind und eine umfangreichere Klasse von
Systemen beschreiben. Sie informieren Entwickler über die allgemeine Struktur
dieser Systemklasse. Referenzmodelle werden normalerweise von einer Studie des
Anwendungsbereichs abgeleitet. Sie stellen eine idealisierte Architektur dar, wel-
che alle in den Systemen enthaltenen Leistungsmerkmale einschließt.

7 Anwendung Anwendung

6 Darstellung Darstellung

5 Sitzung Sitzung

4 Transport Transport

Vermittlung Vermittlung Vermittlung

2 Sicherung Sicherung Sicherung

Bitübertragung Bitübertragung Bitübertragung

Kommun ikationsmedium

Abbildung 11.11 : Die Architektur des OSI-Referenzmodells

Natürlich gibt es keine eindeutige Abgrenzung zwischen diesen Modellarten. Allge-


meine Modelle können auch als Referenzmodelle dienen. Ich benutze diese Unterschei-
dung hier, weil allgemeine Modelle in einem Entwurf direkt wieder verwendet werden
können. Referenzmodelle werden normalerweise benutzt, um Konzepte für bestimmte
Problembereiche darzustellen und mögliche Architekturen zu vergleichen oder zu
bewerten.
Referenzarchitekturen werden normalerweise nicht als Weg zur Implementierung
angesehen. Stattdessen stellen sie in ihrer Grundfunktion ein Mittel zur Erörterung
problembereichsspezifischer Architekturen und zum Vergleich verschiedener Sys-
teme in einem Problembereich dar. Ein Referenzmodellliefert ein Wörterbuch für den
Vergleich. Es dient als Basis, anhand derer Systeme bewertet werden können.
Das OSI-Modell ist ein aus sieben Schichten aufgebautes Modell für die Verbindung
offener Systeme. Dies wird in ~ Abbildung 11.11 veranschaulicht. Die genauen Funk-
tionen der Schichten sind hier nicht von Belang. Im Prinzip sind die unteren Schich-
ten für die physikalischen Verbindungen, die mittleren für den Datentransfer und die
oberen für den Transport von semantisch wichtigen Anwendungsinformationen, wie
zum Beispiel standardisierten Dokumenten, verantwortlich.

Toolslots ----r-----,~

Abbildung 11.12: Die ECMA-Referenzarchitektur für CASE-Umgebungen

I 295
ENTWURF DER ARCHITEKTUR

Die Designer des OSI-Modells hatten ein sehr praxisorientiertes Ziel für die Definition
eines Implementierungsstandards, nämlich konforme Systeme zur Kommunikation mit-
einander zu befähigen. Jede Schicht sollte nur von den jeweils angrenzenden Schichten
beeinflusst werden. Im Zuge der technologischen Weiterentwicklung kann dadurch eine
Schicht transparent reimplementiert werden, ohne die Systeme zu beeinflussen, die
andere Schichten benutzen.
In der Praxis waren allerdings die mit dem Schichtenansatz verbundenen Probleme
bei der Architekturmodellierung dafür verantwortlich, dass dieses Ziel nur teilweise
erreicht wurde. Auf Grund der enormen Unterschiede zwischen Netzwerken sind ein-
fache Verbindungen eventuell nicht möglich. Obwohl die funktionale Charakteristik
jeder Schicht genau definiert ist, sind die nicht funktionalen Charakteristika undefi-
niert. Die Systementwickler müssen eigene Funktionen auf höheren Schichten imple-
mentieren und einzelne Schichten des Modells überspringen. Als Alternative bleibt
ihnen die Entwicklung nicht standardisierter Verfahren, um die Leistungsfähigkeit
des Systems zu verbessern.
Daraus folgt, dass der transparente Austausch einer Schicht des Modells kaum mög-
lich sein wird. Das verringert jedoch nicht die Nützlichkeit des Modells, weil es eine
gute Basis für die abstrakte Strukturierung und die systematische Implementierung
von Kommunikation zwischen Systemen darstellt.
Zu den Beispielen vorgeschlagener Referenzmodelle gehört auch ein Modell für
CASE-Umgebungen (ECMA, 1991; Brown et a1., 1992), das fünf Dienstschichten fest-
legt, die eine CA SE-Umgebung bieten sollte. Es sollte auch die Möglichkeit eines P1ug-
Ins für einzelne CASE-Werkzeuge bieten, die diese Dienste nutzen. Das CASE-Refe-
renzmodell wird in ~ Abbildung 11.11 veranschaulicht. Die fünf Dienstschichten im
CASE-Referenzmodell sind:
• Datenspeicherungsdienste: Sie bieten Möglichkeiten zur Speicherung und Verwal-
tung von Daten und ihrer Beziehungen zueinander.
• Datenintegrationsdienste: Sie bieten Möglichkeiten zur Verwaltung von Gruppen
oder dem Aufbau von Beziehungen zwischen ihnen. Diese Dienste und die Daten-
speicherungsdienste bilden die Basis für die Datenintegration in die Umgebung.
• Dienste zur Aufgabenverwaltung: Sie bieten Möglichkeiten zur Definition und Ver-
ordnung von Prozessmodellen und unterstützen die Prozessintegration.
• Nachrichtendienste: Sie bieten Möglichkeiten für die Kommunikation der Werk-
zeuge untereinander, der Werkzeuge mit den Umgebungen sowie der Umgebungen
untereinander. Sie unterstützen die Steuerungsintegration.
• Benutzerschnittstellendienste: Sie bieten Möglichkeiten für die Entwicklung von
Benutzerschnittstellen und unterstützen die Darstellungsintegration.
Dieses Referenzmodell sagt uns, was in jeder einzelnen CA SE-Umgebung enthalten sein
kann, obwohl es wichtig ist zu betonen, dass nicht jede Eigenschaft einer Referenzarchi-
tektur in wirklichen architektonischen Entwürfen enthalten sein wird. Es bedeutet. dass
wir Fragen zu einem Systementwurf stellen können, wie z.B. "Wie sind die Datenspei-
cherungsdienste ausgestattet?" und "Bietet das System eine Aufgabenverwaltung?"
Der grundlegende Wert dieser Referenzarchitektur liegt wiederum darin, dass sie
ein Mittel zum Klassifizieren und Vergleichen integrierter CASE-Werkzeuge und
-Umgebungen sind. Darüber hinaus können Sie auch in der Ausbildung dazu verwen-
det werden, die Schlüsseleigenschaften dieser Umgebungen hervorzuheben und sie in
einer allgemeinen Form zu diskutieren.
Übungen

Zusammenfassung
• Die Softwarearchitektur ist das grundlegende Rahmenwerk für die Strukturierung eines Sys-
tems. Systemeigenschaften wie Leistung, Sicherheit und Verfügbarkeit werden von der verwen-
deten Architektur beeinflusst.
• Zu architektonischen Entwurfentscheidungen gehören Entscheidungen über die Art der Anwen-
dung, die Verteilung des Systems, der zu verwendende architektonische Typ sowie die Art und
Weise, auf die die Architektur dokumentiert und bewertet werden sollte.
• Während der Entwurfsphase können verschiedene Architekturmodelle, wie zum Beispiel Struk-
tur-, Steuerungs- und Dekompositionsmodelle, entwickelt werden.
• Zu den Organisationsmodellen eines Systems gehören Datenspeichermodelle, ClientlServer-
Modelle und Modelle aus abstrakten Maschinen. Datenspeichermodelle benutzen die Daten
eines gemeinsamen Datenspeichers. ClientlServer-Modelie dienen im Allgemeinen der Vertei-
lung von Daten. Modelle aus abstrakten Automaten sind aus Schichten aufgebaut, wobei jede
Schicht durch Benutzung der Dienste der darunter liegenden Schicht implementiert wird.
• Dekompositionstypen werden in objektorientierte und funktionsorientierte Modelle unterteilt.
Pipelinemodelle sind funktional strukturiert, während Objektmodelle aus lose gekoppelten Ein-
heiten bestehen, die ihre Zustände und Operationen selbst unterhalten.
• Steuerungsmodelle umfassen zentralisierte Steuerungsmodelle und ereignisbasierte Modelle.
Bei zentralisierten Modellen werden die Steuerbefehle in Abhängigkeit vom Systemzustand
erzeugt; bei ereignisbasierten Modellen steuern äußere Ereignisse das System
• Referenzarchitekturen können als Medium genutzt werden, um problembereichsspezifische
Architekturen zu erörtern und um architektonische Entwürfe einzuschätzen und zu vergleichen.

Ergänzende Literatur
Software Architecture in Practice, 2nd ed. Hier findet sich eine praxis orientierte
Erläuterung von Softwarearchitekturen, die den Ansatz nicht überbewertet und klar
darstellt, warum Architekturen wichtig sind. (L. Bass et ai., 2003 , Addison-Wesley.)
Design and Use 0/ Software Architectures. Obwohl sich dieses Buch auf Produkt-
linienarchitekturen konzentriert, stellen die ersten Kapitel eine hervorragende Einfüh-
rung in den Softwarearchitekturentwurf dar. (]. Bosch, 2000, Addison-Wesley.)
Software Architecture: Perspectives on an Emerging Discipline. Dies war das erste
Buch zum Thema Softwarearchitektur. Es enthält eine gute Abhandlung über ver-
schiedene Architekturtypen. (M. Shaw und D. Garlan, 1996, Prentice-Hall.)

Übungen Kapitel 11
liD Erklären Sie, warum es notwendig sein kann, die Systemarchitektur vor
der Spezifikation der Anforderungen zu entwerfen.
liD Erläutern Sie, warum beim Entwerfen einer Architektur, bei der die Ver-
fügbarkeits- und Sicherheits anforderungen die wichtigsten funktionalen
Anforderungen darstellen, Entwurfskonflikte auftreten können.

I 297
ENTWURF DER ARCHITEKTUR

IID Erstellen Sie eine Vergleichstabelle mit den Vor- und Nachteilen der in
diesem Kapitel beschriebenen Strukturmodelle.

DD Schlagen Sie jeweils ein geeignetes Strukturmodell für die folgenden Sys-
teme vor, und begründen Sie Ihre Antwort:
- ein Fahrscheinausgabesystem für die Passagiere auf einem Bahnhof
- ein computergesteuertes Videokonferenzsystem, welches ermöglicht,
Video-, Audio- und Computerdaten mehreren Teilnehmern gleichzeitig
sichtbar zu machen
- ein Reinigungsroboter, der zum Reinigen relativ freier Flächen wie z.B.
Gängen eingesetzt werden soll. Das Gerät muss in der Lage sein, Wände
und andere Hindernisse zu erkennen.
IIIJ Entwerfen Sie Architekturen für die oben angeführten Systeme auf der
Basis Ihrer Modellauswahl. Treffen Sie begründete Annahmen über die Sys-
temanforderungen.
IID Echtzeitsysteme nutzen in der Regel ereignisorientierte Steuerungsmodelle.
Unter welchen Umständen würden Sie für ein Echtzeitsystem ein Aufruf/
Rückgabe-Modell vorschlagen?

IID Schlagen Sie jeweils ein geeignetes Steuerungsmodell für die folgenden
Systeme vor, und begründen Sie Ihre Antwort:
- ein System, das Daten über geleistete Arbeitsstunden und Stunden-
löhne stapelweise verarbeitet und Gehaltsabrechnungen und Bank-
anweisungen ausdruckt
- einen Satz von Softwarewerkzeugen, die von verschiedenen Software-
häusern entwickelt werden, aber zusammenarbeiten sollen
- eine Fernsehersteuerung, die auf Fernbedienungssignale reagiert

IID Erläutern Sie Vor- und Nachteile des Datenfluss- und des objektorientier-
ten Modells in Bezug auf die Verteilungsfähigkeit. Gehen Sie davon aus,
dass die Anwendung sowohl auf einzelnen als auch auf verteilten Rech-
nern zum Einsatz kommen wird.
liD Sie bekommen zwei integrierte CASE-Werkzeugsammlungen und erhalten
den Auftrag, diese zu vergleichen. Erklären Sie, wie Sie ein Referenz-
modell für CA SE (Brown et a1., 1992) verwenden können, um diesen Ver-
gleich durchzuführen.

iIIIlJ Sollte es den speziellen Beruf eines "unabhängigen Softwarearchitekten"


geben, dessen Aufgabe es wäre, mit dem Kunden eine Softwarearchitektur
zu entwerfen? Dieses System würde dann durch irgendein Softwareunter-
nehmen implementiert werden. Welche Schwierigkeiten würden voraus-
sichtlich bei der Etablierung eines solchen Berufs auftreten?

Lösungen für ausgewählte Übungen dieses Kapitels finden Sie unter www.pearson-
studium.de auf der Companion Website zum Buch.
Architekturen verteilter
Systeme

12.1 Mehrprozessorarchitekturen . . . . . . . . . . . . . . . . . . .. 302


12.2 Client/Server-Architekturen............ . ... . .... 303
12.3 Verteilte Objektarchitekturen . . . . . . . . . . . . . . . . . .. 308
12.3.1 CORBA ............. . ... . .... . . . .......... .. 311

12.4 Interorganisationale verteilte Systeme. . . . . . . . .. 315


12.4.1 Peer-to-Peer-Architekturen......... .... .. . ..... 315
12.4.2 Dienstorientierte Systemarchitektur . . . . . . . . . . . . . . 318

Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 322
Ergänzende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Übungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 323
ARCHITEKTUREN VERTEILTER SYSTEME

Lernziele Das Ziel dieses Kapitels ist es, Softwarearchitekturmodelle für verteilte Systeme
zu erörtern. Wenn Sie dieses Kapitel gelesen haben, werden Sie
• über die wichtigsten Vor- und Nachteile verteilter Systemarchitekturen Bescheid wissen
• die zwei grundlegenden Modelle für verteilte Systeme, nämlich ClientiServer- und ver-
teilte Objektsysteme verstehen
• das Konzept eines Object Request Brokers (Objektanfragevermittlers) und die Prinzipien
des CORBA-Standards verstehen
• eine Einführung in Peer-to-Peer- und dienstorientierte Architekturen als Mittel zum Im-
plementieren interorganisationaler bzw. unternehmensübergeordneter verteilter Systeme
erhalten haben

Im Grunde handelt es sich heute bei allen großen computerbasierten Systemen um


verteilte Systeme. Man spricht von verteilten Systemen, wenn die Informationsver-
arbeitung nicht auf einem einzigen, sondern auf einer Anzahl verschiedener Compu-
ter verteilt abläuft. Zwischen der Entwicklung verteilter Systeme und anderen Arten
der Softwareentwicklung gibt es viele Gemeinsamkeiten, bei verteilten Systemen müs-
sen jedoch besondere Sachverhalte berücksichtigt werden. Ich habe einige davon
bereits bei der Behandlung von Client/Server-Architekturen in Kapitel 11 vorgestellt
und werde jetzt näher auf dieses Thema eingehen. Coulouris et a1. (Coulouris et a1.,
2001) erörtern die grundlegenden Merkmale verteilter Systeme. Sie stellen die folgen-
den Vorteile beim Einsatz verteilter Systeme zur Systementwicklung heraus:
o Ressourcenteilung: Ein verteiltes System erlaubt die gemeinsame Benutzung von
Hard- und Softwareressourcen wie Festplatten, Druckern, Dateien, Compilern
usw., die zu Computern innerhalb eines Netzwerkes gehören.
D Offenheit: Verteilte Systeme sind normalerweise offene Systeme. Das bedeutet, das
sie auf der Basis von Standardprotokollen entworfen sind, so dass sowohl Hard- als
auch Software von verschiedenen Herstellern kombiniert werden können.
D Nebenläufigkeit: In einem verteilten System können verschiedene Prozesse gleich-
zeitig auf getrennten Computern des Netzwerkes ablaufen. Diese Prozesse können
während ihrer normalen Aktivität miteinander kommunizieren, müssen dies aber
nicht.
D Skalierbarkeit: Verteilte Systeme sind - zumindest prinzipiell - dadurch skalier-
bar, dass die Kapazität des Systems durch das Hinzufügen von weiteren Ressour-
cen erweitert werden kann, um an neue Anforderungen angepasst zu werden. In
der Praxis kann die Skalierbarkeit durch das Netzwerk, das die einzelnen Compu-
ter des Systems verbindet, begrenzt sein. Durch die Integration vieler zusätzlicher
Computer kann man irgendwann an die Grenzen der Netzwerkkapazität stoßen.
D Fehlertoleranz: Das Vorhandensein verschiedener Computer und die Möglichkeit
der Replizierung von Informationen bedeutet, dass verteilte Systeme in der Lage
sein können, manche Hard- und Softwarefehler zu tolerieren (siehe Kapitel 20). In
den meisten verteilten Systemen kann bei auftretenden Fehlern zumindest ein
eingeschränkter Dienst aufrechterhalten werden. Ein kompletter Ausfall ist nur im
Falle eines Netzwerkausfalls zu erwarten.
Für große Unternehmens systeme bedeuten diese Vorteile, dass verteilte Systeme zum
großen Teil die zentralisierten Legacy-Systeme ersetzt haben, die in der BDer und gDer
Jahren des letzten Jahrhunderts entwickelt wurden. Verglichen mit Systemen, die auf
einem einzelnen Prozessor oder einem Cluster ausgeführt werden, haben verteilte
Systeme jedoch auch eine Reihe von Nachteilen:
• Komplexität: Verteilte Systeme sind komplexer aufgebaut als zentralisierte Systeme.
Das erschwert das Verständnis ihrer Verhaltensweise und den Systemtest. Beispiels-
weise ist die Leistungsfähigkeit des Systems nicht mehr von der Arbeitsgeschwindig-
keit eines einzelnen Prozessors abhängig, sondern von der Bandbreite des Netzwerks
und der Geschwindigkeit der Prozessoren. Die Leistungsfähigkeit des Systems kann
durch die Verschiebung von Ressourcen von einem Teil des Netzwerks in einen
anderen sehr stark beeinflusst werden.
• ZugriJfsschutz: Das System wird von vielen verschiedenen Computern benutzt,
und der Datentransport im Netzwerk könnte belauscht werden. Das erschwert die
Sicherstellung der Datenintegrität im System sowie den Schutz vor einer Ver-
schlechterung der Systemdienste auf Grund von Denial-of-Service-Angriffen.
• Verwaltbarkeit: Die Computer des Systems können von unterschiedlichem Typ sein
und verschiedene Betriebssystemversionen benutzen. Fehler in einem Computer
können sich auf andere übertragen und unerwartete Konsequenzen haben. Das
macht einen höheren Aufwand für die Verwaltung und Wartung des Systems wäh-
rend des Betriebs erforderlich.
• Unvorhersagbarkeit: Wie alle Benutzer des WWW aus Erfahrung wissen, sind die
Reaktionen verteilter Systeme nicht vorhersagbar, sondern hängen von der allge-
meinen Auslastung des Systems, seiner Organisation und der Netzwerkbelastung
ab. Da sich diese Faktoren jederzeit kurzfristig ändern können, sind die Antwort-
zeiten auf Benutzeranfragen höchst unterschiedlich.
Die Herausforderung besteht darin, eine Hard- und Software zu entwickeln, welche die
gewünschten Eigenschaften des verteilten Systems realisiert und zugleich die Probleme
minimiert, die mit solchen Systemen einhergehen. Um das zu beherrschen, müssen Sie
die Vor- und Nachteile verschiedener Architekturen verteilter Systeme verstehen. Ich
werde hier zwei grundlegende Typen verteilter Systemarchitekturen erläutern:
o ClientiServer-Architekturen: Bei diesem Ansatz kann man sich das System als
eine Anzahl von Diensten vorstellen, die verschiedenen Clients zur Benutzung
zur Verfügung gestellt werden. Server und Clients werden in diesen Systemen
unterschiedlich behandelt.
D Architekturen verteilter Objekte: In diesem Falle gibt es keine Unterscheidung
zwischen Clients und Servern, und das System kann als eine Menge von Objek-
ten betrachtet werden, deren Standort ohne Bedeutung ist. Es gibt keine Unter-
scheidung zwischen einem Dienstanbieter und einem Benutzer dieser Dienste.
Sowohl Client/Server- als auch die Architekturen verteilter Objekte sind in der Indus-
trie weit verbreitet, doch die Verteilung der Anwendungen findet im Allgemeinen in
einer einzelnen Organisation statt. Die unterstützte Verteilung ist daher intraorganisa-
tional bzw. unternehmens bezogen. Ich behandle auch zwei weitere Typen verteilter
Architekturen, die für interorganisationale bzw. unternehmenübergeordnete Verteilun-
gen besser geeignet sind: Peer-to-Peer- (P2P) und dienstorientierte Architekturen. Peer-

I 301
ARCHITEKTUREN VERTEILTER SYSTEME

ta-Peer-Systeme wurden bislang hauptsächlich für persönliche Systeme verwendet,


kommen aber neuerdings auch für Geschäftsanwendungen in Einsatz. Zum aktuellen
Zeitpunkt befinden sich dienstorientierte Systeme gerade in der Einführungsphase,
doch dieser Ansatz wird ab dem Jahr 2005 ein wichtiges Verteilungsmodell sein.
Die Komponenten eines verteilten Systems können mit jeweils anderen Program-
miersprachen implementiert werden und auf unterschiedlichen Prozessoren laufen.
Die Datenmodelle, die Informationsdarstellung und Kommunikationsprotokolle kön-
nen alle verschieden sein. Ein verteiltes System benötigt deshalb eine Software, die
diese verschiedenen Teile verwalten und sicherstellen kann, dass sie miteinander
kommunizieren und Daten austauschen können. Solch eine Software wird als MiddJe-
ware bezeichnet, weil sie sich in der Mitte zwischen den diversen verteilten Kompo-
nenten des Systems befindet.
Bernstein (Bernstein, 1996) hat Typen von Middleware zusammengefasst, die für
die Unterstützung verteilter Systeme zur Verfügung stehen. Bei Middleware handelt
es sich um Software für allgemeine Zwecke, die normalerweise fertig gekauft werden
kann und nicht speziell für einen bestimmten Zweck entwickelt wird. Beispiele für
Middleware finden sich bei der Kommunikation mit Datenbanken, der Transaktions-
steuerung, Datenkonvertern, der Kommunikationssteuerung usw. Auf Object Request
Broker, die einen besonders wichtigen Typ von Middleware darstellen, werde ich wei-
ter unten in diesem Kapitel eingehen.
Verteilte Systeme werden in der Regel nach einem objektorientierten Ansatz entwi-
ckelt. Sie sind aus lose integrierten, unabhängigen Teilen aufgebaut, von denen jedes
direkt mit Benutzern oder anderen Systemteilen in Verbindung treten kann. Teile des
Systems müssen eventuell auf unabhängige Ereignisse reagieren können. Software-
objekte spiegeln diese Eigenschaften wider und stellen damit eine natürliche Abstrak-
tion der verteilten Systemkomponenten dar.

12.1 Mehrprozessorarchitekturen
Das einfachste Modell eines verteilten Systems ist ein Mehrprozessorsystem, dessen
Software aus einer Anzahl von Prozessen besteht, die auf separaten Prozessoren aus-
geführt werden können (aber nicht müssen). Dieses Modell ist bei großen Echtzeitsys-
temen üblich. Wie ich in Kapitel 15 noch beschreiben werde, sammeln diese Systeme
Informationen, treffen auf der Basis dieser Informationen Entscheidungen und senden
Signale an Aktoren, welche die Systemumgebung verändern.
Im Prinzip könnten alle Prozesse für das Sammeln der Informationen, das Treffen
von Entscheidungen und die Steuerung der Aktoren auf einem einzigen Prozessor lau-
fen, der von einem Zeitgeber gesteuert wird. Der Einsatz vieler Prozessoren verbessert
jedoch die Leistungsfähigkeit und "Elastizität" des Systems. Die Verteilung der Pro-
zesse auf die Prozessoren kann im Voraus festgelegt werden (das ist bei kritischen Sys-
temen üblich), oder sie obliegt der Kontrolle durch einen Verteiler bzw. Dispatcher,
der entscheidet, welche Prozesse den einzelnen Prozessoren zugeordnet werden.
Ein Beispiel dieses Systemtyps zeigt ~ Abbildung 12.1. Dabei handelt es sich um ein
vereinfachtes Modell für ein System zur Verkehrs steuerung. Eine Anzahl verteilter
Sensoren erfasst Informationen über den Verkehrsfluss und verarbeitet diese an Ort
und Stelle, bevor sie zu einer Leitstelle übertragen werden. Die Bediener in der Leit-
stelle treffen auf der Basis dieser Informationen Entscheidungen und beeinflussen das
Programm für die Ampelsteuerung. In diesem Beispiel gibt es separate logische Pro-
12.2 Client/Server-Architekturen

zesse zur Verwaltung der Sensoren, der Leitstelle und der Verkehrsampeln. Diese logi-
schen Prozesse können aus einzelnen Prozessen oder aus einer Gruppe von Prozessen
bestehen. In diesem Beispiel werden sie von separaten Prozessoren ausgeführt.
Bei Softwaresystemen, die aus mehreren Prozessen aufgebaut sind, handelt es sich
nicht unbedingt um verteilte Systeme. Wenn mehr als ein Prozessor vorhanden ist,
kann eine Verteilung implementiert werden, aber es ist nicht notwendig, dass die Sys-
tementwickler während des Entwurfsprozesses permanent diese Gesichtspunkte im
Auge haben. Der Entwurfsansatz für diesen Systemtyp ist im Grunde derselbe wie der
für die in Kapitel 15 beschriebenen Echtzeitsysteme.

Sensorprozessor Verkehrsfluss- Ampelsteuerungs-


prozessor prozessor

Ampeln
Kameras und Sensoren zur
Überwachung des Verkehrsflusses Bedienerterminals

Abbildung 12.1: Ein Mehrprozessor-Verkehrsleitsystem

12.2 Client/ Server-Architekt uren


In Kapitel 11 habe ich bereits das Konzept von Client/Server-Architekturen vorgestellt.
In einer solchen Architektur wird eine Anwendung als eine Anzahl von Diensten, die
von Servern bereitgestellt werden, und eine Anzahl von Clients, die diese Dienste
benutzen, modelliert (Orfali und Harkey, 1998). Die Clients kennen die verfügbaren
Server, wissen aber normalerweise nichts über die Existenz anderer Clients. Clients
und Server sind voneinander getrennte Prozesse, wie in ~ Abbildung 12.2 anhand
eines logischen Modells einer verteilten Client/Server-Architektur dargestellt wird.
Auf einem einzelnen Serverprozessor können mehrere Serverprozesse ausgeführt
werden, so dass im System nicht unbedingt Deckungsgleichheit zwischen Prozessen
und Prozessoren besteht. ~ Abbildung 12.3 zeigt die physikalische Architektur eines
Systems mit sechs Client- und zwei Servercomputern. Auf diesen Rechnern können
die in ~ Abbildung 12.2 dargestellten Client- und Serverprozesse ablaufen. Wenn ich
von Clients und Servern spreche, meine ich damit die logischen Prozesse und nicht die
physischen Computer, auf denen sie ausgeführt werden.
Der Entwurf von Client/Server-Systemen sollte die logische Struktur der zu entwi-
ckelnden Anwendung widerspiegeln. Eine Betrachtungsmöglichkeit ist in ~ Abbildung
12 .4 anhand einer in drei Schichten gegliederten Anwendung dargestellt. Die Darstel-
lungsschicht dient der Darstellung von Informationen für die Benutzer und dem Umgang
mit den Benutzerinteraktionen. Die Schicht für die Anwendungsprozesse ist für die Im-
plementierung der Anwendungslogik verantwortlich, und die Schicht für die Datenhal-
tung bearbeitet alle Datenbankoperationen. In zentralisierten Systemen müssen diese Ak-
tivitäten nicht streng getrennt sein. Sie sollten jedoch beim Entwurf eines verteilten

I 303
ARCHITEKTUREN VERTEILTER SYSTEME

Systems eine eindeutige Unterscheidung zwischen ihnen treffen, weil es dadurch mög-
lich wird, jede der Schichten auf einen anderen Computer zu verteilen.

D
Serverprozess

o
Clientprozess

Abbildung 12.2: Ein ClientJServer-System

Die einfachste Client/Server-Architektur nennt man eine zweischichtige Client/Server-


Architektur: Die Anwendung besteht aus einem Server (oder einer Vielzahl von iden-
tischen Servern) und einer Anzahl von Clients. Wie ~ Abbildung 12.5 zeigt, können
zweischichtige Client/Server-Architekturen in zwei Versionen vorkommen:
• Thin-Client-Model1: Dabei werden alle Anwendungsprozesse und die gesamte Daten-
haltung auf dem Server durchgeführt. Der Client ist nur für den Ablauf der Darstel-
lungssoftware verantwortlich .
• Fat-Client-Model1: In diesem Modell sorgt der Server lediglich für die Datenhal-
tung. Die Software auf dem Client implementiert die Anwendungslogik und die
Interaktionen mit dem Benutzer.
Eine zweischichtige Thin-Client-Architektur ist der einfachste Ansatz, wenn zentrali-
sierte Legacy-Systeme, wie in Kapitel 2 behandelt, in Richtung auf eine Client/Server-
Architektur weiterentwickelt werden. Die Bedienoberflächen dieser Systeme werden
auf PCs übertragen, und die Anwendung selbst fungiert als Server und bearbeitet alle
Anwendungs- und Datenmanagementprozesse. Ein Thin-Client-Modell kann ebenfalls
implementiert werden, wenn es sich bei den Clients nicht um PCs oder Workstations ,
sondern um einfache Netzwerkterminals handelt, die lediglich einen Internet-Browser
und die Bedienoberfläche ausführen, die dadurch implementiert wird.

c3,c4

DServer-
Rechner

o
Client-
Rechner

Abbildung 12.3: Computer in einem ClientJServer-Netzwerk


12.2 Client/Server-Architekturen

Darstellungsschicht

Anwenderschicht

Abbildung 12.4: Anwendungsschichten

Ein wesentlicher Nachteil des Thin-Client-Modells besteht in der starken Belastung


sowohl des Servers als auch des Netzwerks mit Prozessen. Der Server muss alle Rechen-
prozesse ausführen, was einen umfangreichen Datentransport zwischen Client und Ser-
ver verursacht. Moderne Rechner weisen eine enorme Datenverarbeitungskapazität auf,
die beim Thin-Client-Modell weitgehend ungenutzt bleibt.
Das Fat-Client-Modell macht von dieser verfügbaren Kapazität Gebrauch und über-
trägt sowohl die Prozesse der Anwendungslogik als auch die Darstellung auf die
Clients. Der Server ist im Prinzip nur ein Transaktionsserver, der alle Datenbankpro-
zesse bearbeitet. Ein Beispiel dieses Architekturtyps sind Geldautomatensysteme, bei
denen der Automat als Client fungiert und der zentrale Computer als Server die Daten-
bank für die Kundenkonten verwaltet. Die Hardware im Geldautomaten führt eine Viel-
zahl der mit der Transaktion verbundenen kundenbezogenen Verarbeitung aus.

Darstellung

~l Server Server
Thin·Client Datenhaltung
Modell ~,....-------~ Anwendungs-
verarbeitung

Darstellung Server
Anwendungsprozesse Server
Fat-Client
Modell Datenmanagement

Abbildung 12.5: Thin- und Fat-Clients

Dieses Geldautomatensystem ist in ~ Abbildung 12.6 dargestellt. Beachten Sie, dass die
Geldautomaten nicht direkt mit der Datenbank, sondern mit einem Monitor für die
Fernübertragung verbunden sind. Dieser Monitor oder auch Transaktionsmanager ist
ein Middleware-System, das die Kommunikation mit entfernten Clients organisiert
und die Transaktionen der Clients für die Verarbeitung durch die Datenbank seriell
anordnet. Die Verwendung serieller Transaktionen führt dazu, dass sich das System
nach Fehlern selbst wiederherstellen kann, ohne dass dabei die Systemdaten verfälscht
werden.

I 305
ARCHITEKTUREN VERTEILTER SYSTEME

Kontenserver

Monitor Datenbank
für die Fern- für Kunden-
über tragung konten

Abbildung 12.6: Ein ClientJServer-Geldautomat

Obwohl ein Fat-Client-Modell die Prozesse effektiver als ein Thin-Client-Modell verteilt,
ist das Management eines solchen Systems komplexer. Die Funktionalität der Anwen-
dung ist über viele Computer verteilt. Änderungen der Anwendungssoftware machen
eine Neuinstallation auf sämtlichen Computern erforderlich. Das kann einen wesentli-
chen Kostenfaktor darstellen, wenn das System Hunderte von Clients beinhaltet.
Das Aufkommen von portablem (mobile) Code (wie z.B. Java-Applets und Active X-
Controls), die von einem Server zu einem Client herunter geladen werden können, hat
die Entwicklung eines Client/Server-Modells ermöglicht, das irgendwo zwischen
Thin- und Fat-Client-Modellen anzusiedeln ist. Ein Teil der Software für die Anwen-
dungsprozesse kann auf den Client als portabler Code herunter geladen werden und
senkt dadurch die Belastung des Servers. Die Bedienoberfläche basiert auf einem Web-
Browser, der die Möglichkeit bietet, den herunter geladenen Code auszuführen.
Das grundsätzliche Problem beim zweischichtigen Client/Server-Ansatz besteht
darin, dass die drei logischen Schichten - Darstellung, Anwendungsprozesse und
Datenhaltung - auf zwei Computersysteme abgebildet werden müssen - den Client
und den Server. Dabei können sich beim Thin-Client-Modell Probleme mit der Ska-
lierbarkeit und der Leistungsfähigkeit bzw. beim Fat-Client-Modell Schwierigkeiten
mit dem Systemmanagement ergeben. Um diese Probleme zu vermeiden, kann man
alternativ einen Ansatz für eine dreischichtige Client-Server-Architektur benutzen
(siehe ~ Abbildung 12.7) . In dieser Architektur werden die Darstellung, die Anwen-
dungsprozesse und die Datenhaltung als separate logische Prozesse auf verschiedenen
Prozessoren ausgeführt.
Ein Beispiel für eine dreischichtige Client/Server-Architektur ist ein Homebanking-
System (~ Abbildung 12.8). Die Kundendatenbank des Kreditinstituts (die normaler-
weise auf einem Großrechner als Host angesiedelt ist) sorgt für das Datenmanagement,
ein Web-Server stellt die Anwendungsdienste wie Überweisungen, Kontoauszüge,
Abbuchungen usw. zur Verfügung, und der Computer des Kunden mit einem Web-
Browser fungiert als Client. Das System ist skalierbar, denn es ist relativ einfach, es
durch Hinzufügen weiterer Web-Server einer steigenden Kundenzahl anzupassen.

Darstellung
Server Server

'.I ~
Anwendungs-
I. ~
Daten-
prozesse management

Abbildung 12.7: Eine dreischichtige ClientJServer-Architektur


12.2 Client/Server-Architekturen

HTTP Interaktion

Web Server SQL- Dalenbankserver


Abfrage Datenbank
Kontendienst
SQL für Kunden-
konten

Abbildung 12.8: Die Verteilungsarchitektur eines Homebankingsystems

Durch die Verwendung einer dreischichtigen Architektur kann in diesem Fall die
Informationsübertragung zwischen dem Web- und dem Datenbankserver optimiert
werden. Die Kommunikation zwischen diesen Systemen kann schnelle Kommunika-
tionsprotokolle auf niedriger Ebene verwenden. Zum Abrufen der Informationen aus
der Datenbank wird eine leistungsfähige Middleware eingesetzt, die Datenbankabfra-
gen in SQL (Structured Query Language) unterstützt.
In einigen Fällen kann es zweckmäßig sein, das Dreischichtenmodell in ein Multi-
schichtenmodell zu erweitern, indem weitere Server zum System hinzugefügt werden.
Multischichtenmodelle bieten sich an, wenn Anwendungen auf verschiedene Daten-
banken zugreifen müssen. In diesem Falle wird zwischen dem Anwendungsserver und
den Datenbankservern, auf die zugegriffen werden soll, ein Integrationsserver angeord-
net. Dieser sammelt die verteilten Daten und leitet sie in einer Form an die Anwen-
dung weiter, als würden sie von einer einzigen Datenbank stammen.
Dreischichtige Client/Server-Architekturen und Multischichtenvarianten, welche
die Anwendungsprozesse auf mehrere Server verteilen, sind prinzipiell besser skalier-
bar als zweischichtige Anordnungen. Im Vergleich zu zweischichtigen Thin-Client-
Architekturen wird die Netzwerklast verringert. Die Anwendungsprozesse bilden den
Teil des Systems mit den häufigsten Veränderungen und können leicht aktualisiert
werden, weil sie zentral angeordnet sind. In manchen Fällen können die Prozesse auf
die Anwendungslogik- und die Datenhaltungsserver aufgeteilt werden, was eine Ver-
kürzung der Antwortzeiten für die Anfragen von Clients zur Folge hat.
Entwickler von Client/Server-Architekturen müssen bei der Wahl der zweckmäßigs-
ten Architektur viele Faktoren berücksichtigen. Situationen, für die sich die beschrie-
benen Architekturen jeweils anbieten, sind in ~ Abbildung 12.9 aufgelistet.

Architektur Anwendungen
Zweischichtige CIS-Archi- Anwendungen mit Legacy-5ystemen, bei denen die Trennung von
tektur mit Thin-Clients Anwendungsprozessen und Datenmanagement nicht praktikabel ist
Rechenintensive Anwendungen wie zum Beispiel Compiler mit geringem
oder keinem Datenmanagement
Datenintensive Anwendungen (Browser oder Abfragesysteme) mit wenigen
oder keinen Anwendungsprozessen

Abbildung 12.9: Die Verwendung verschiedener ClientiServer-Architekturen

I 307
ARCHITEKTUREN VERTEILTER SYSTEME

Architektur Anwendungen
-~-------
Zweischichtige C/S-Archi- Anwendungen, bei denen die Prozesse durch Standardanwendungen
tektur mit Fat-Clients (z. 8. Microsoft Excel) auf dem Client bearbeitet werden
Anwendungen mit rechenintensiver Datenverarbeitung (z. 8. Daten-
visualisierung)
Anwendungen mit relativ stabiler Endbenutzerfunktionalität, die in einer
Umgebung mit gut strukturiertem System management angeordnet sind
Drei- oder mehrschich- Anwendungen großen Umfangs mit Hunderten oder Tausenden von Clients
tige CIS-Architektur Anwendungen, bei denen sowohl die Daten als auch die Anwendung selbst
ständigen Veränderungen unterliegen
Anwendungen, bei denen Daten aus vielfältigen Quellen verarbeitet werden

Abbildung 12.9: Die Verwendung verschiedener ClientlServer-Architekturen (Forts.)

12.3 Verteilte Objektarchitekturen


In einern Client/Server-Modell eines verteilten Systems wird zwischen Clients und
Servern unterschieden. Die Clients erhalten ihre Dienste von Servern und nicht von
Clients. Server können sich auch wie Clients verhalten, indern sie Dienste von ande-
ren Servern benutzen, aber sie fordern niemals Dienste von Clients an. Clients müssen
die von speziellen Servern angebotenen Dienste kennen und wissen, wie man auf die
betreffenden Server zugreift. Dieses Modell ist für viele Anwendungsarten gut geeig-
net. Allerdings begrenzt es die Flexibilität der Entwickler durch die notwendige Fest-
legung, wo die Dienste angeboten werden sollen. Sie müssen außerdem eine ausrei-
chende Skalierbarkeit einplanen, damit die Möglichkeit besteht, die Belastung der
Server einer wachsenden Anzahl von Clients anzupassen und zu verteilen.
Ein allgemeinerer Ansatz für den Entwurf verteilter Systeme besteht darin, die Unter-
scheidung zwischen Servern und Clients aufzuheben und die Systemarchitektur als ver-
teilte Objektarchitektur zu gestalten. In einer solchen Architektur nach ~ Abbildung
12.10 werden die grundlegenden Systemkomponenten durch Objekte realisiert, welche
eine Schnittstelle für die von ihnen angebotenen Dienste bereitstellen. Andere Objekte
rufen diese Dienste ab, ohne dass ein logischer Unterschied zwischen Clients (den
Benutzern von Diensten) und Servern (den Anbietern von Diensten) besteht.
Die Objekte können auf eine Anzahl von Computern innerhalb eines Netzwerks ver-
teilt sein und kommunizieren über eine Middleware. Man nennt diese Middleware
einen Object Request Broker (Objektanfragevermittler). Seine Aufgabe besteht darin,
für eine reibungslos funktionierende Schnittstelle zwischen den Objekten zu sorgen.
Er bietet eine Anzahl von Diensten, die die Kommunikation zwischen sowie das Hin-
zufügen und Entfernen von Objekten ermöglichen. Ich werde Object Request Broker in
Abschnitt 12.3 .1 behandeln.
12.3 Verteilte Objektarchitekturen

01 02 03 04

S (01) S (02) S (03) S (04)

l l Softwal'ebus
I
-I

J I
05 06

S (05) S (06)

Abbildung 12.10: Verteilte Objektarchitektur

Die Vorteile dieses verteilten Objektmodells sind folgende:


• Sie erlaubt es den Entwicklern, die Entscheidung, wo und wie die Dienste angeboten
werden, auf spätere Entwicklungsphasen zu verschieben. Objekte, welche Dienste
anbieten, können an jedem beliebigen Netzknoten ausgeführt werden. Dadurch wird
die Unterscheidung zwischen Fat- und Thin-Clients irrelevant, weil keine Notwen-
digkeit besteht, im Voraus zu entscheiden, wo logische Anwendungsobjekte angesie-
delt werden sollen.
• Es ist eine sehr offene Systemarchitektur, die es erlaubt, neue Ressourcen bedarfs-
orientiert hinzuzufügen. Wie ich im folgenden Abschnitt beschreiben werde, hat
man Standards für die Objektkommunikation entwickelt und implementiert, die es
ermöglichen, dass mit diversen Programmiersprachen entworfene Objekte mitein-
ander kommunizieren und sich gegenseitig Dienste anbieten können.
• Das System ist flexibel und skalierbar. Um unterschiedlichen Systembelastungen
Rechnung zu tragen, kann man verschiedene Exemplare des Systems mit dem glei-
chen Dienst erstellen, der durch unterschiedliche oder replizierte Objekte angeboten
wird. Wenn sich die Belastung des Systems erhöht, können neue Objekte hinzuge-
fügt werden, ohne die Funktion anderer Objekte des Systems zu beeinträchtigen.
• Es ist möglich, das System dynamisch neu zu konfigurieren, indem Objekte bei
Bedarf an anderen Stellen des Systems angeordnet werden. Das kann wichtig sein,
wenn sich die Bedarfsstruktur der Dienste verändert. Ein Dienste anbietendes
Objekt und die Objekte, welche diese Dienste benutzen, können zum Beispiel auf
demselben Prozessor angeordnet werden und so die Leistungsfähigkeit des Systems
beträchtlich erhöhen.
Eine verteilte Objektarchitektur kann als logisches Modell verwendet werden, mit
dem das System strukturiert und organisiert werden kann. Für die Überlegung, wie
die Funktionalität der Anwendung realisiert werden soll , stellt man sich das System
in diesem Falle ausschließlich in Form von Diensten und der Kombination von Diens-
ten vor. Danach wird herausgearbeitet, wie diese Dienste unter Verwendung einer
Anzahl verteilter Objekte bereitgestellt werden. In dieser Phase handelt es sich norma-
lerweise um grob strukturierte Objekte (man spricht auch von Geschäftsobjekten, engl.
business objectsJ, die bereichsspezifische Dienste bereitstellen. In einer Anwendung
für den Einzelhandel kann es zum Beispiel Geschäftsobjekte geben, die für die Lager-

I 309
ARCHITEKTUREN VERTEILTER SYSTEME

haltung, die Kommunikation mit den Kunden, die Warenbestellung usw. verantwort-
lich sind. Dieses logische Modell kann später selbstverständlich für die Implementie-
rung benutzt werden.

Abbildung 12.11: Die Verteilungsarchitektur eines Data-Mining-Systems

Alternativ können Sie für die Implementierung von Client/Server-Systemen einen


verteilten Objektansatz verwenden. In diesem Fall stellt das logische Modell des Sys-
tems ein Client/Server-Modell dar, aber sowohl die Clients als auch die Server sind in
Form von verteilten Objekten realisiert, die über einen Softwarebus miteinander kom-
munizieren. Dadurch wird es möglich, das System auf einfache Weise zu verändern,
indem man zum Beispiel ein Zwei- zu einem Multischichtensystem weiterentwickelt.
In diesem Falle werden Server und Client nicht als einzelne verteilte Objekte imple-
mentiert, sondern sind aus einer Anzahl kleinerer Objekte gebildet, die spezialisierte
Dienste bereitstellen.
Ein Beispiel für einen Systemtyp, für den die verteilte Objektarchitektur geeignet sein
könnte, wäre ein System, das nach Beziehungen zwischen Daten sucht, die in mehreren
Datenbanken gespeichert sind (siehe ~ Abbildung 12.11). Als mögliche Anwendung für
ein solches so genanntes Data-Mining-System kann man sich beispielsweise eine
Ladenkette vorstellen, die verschiedene Arten von Einzelhandelsgeschäften betreibt
(z. B. für Lebensmittel und Haushaltswaren) und versucht, für den Einkauf der unter-
schiedlichen Warentypen Gemeinsamkeiten herauszufinden. So könnten zum Beispiel
Kunden, die Babynahrung einkaufen, auch an speziellen Tapeten für Kinderzimmer
interessiert sein. Auf Grund solcher Erkenntnisse wäre das Unternehmen in der Lage,
Kombinationsangebote für Käufer von Babynahrung anzubieten.
In diesem Beispiel kann jede Datenbank als verteiltes Objekt mit einer Schnittstelle
gekapselt werden, die lediglich einen Lesezugriff auf ihre Daten erlaubt. Die Integra-
torobjekte befassen sich jeweils mit speziellen Arten von Beziehungen und sammeln
Informationen von allen Datenbanken, um Beziehungen daraus abzuleiten. Beispiels-
weise könnte ein Integratorobjekt die saisonalen Veränderungen beim Verkauf von
Waren untersuchen, während ein anderes sich mit den Beziehungen zwischen ver-
schiedenen Warenkategorien beschäftigt.
Visualisierungsobjekte arbeiten mit Integratorobjekten zusammen, um Darstellun-
gen oder Berichte der gefundenen Beziehungen zu erstellen. Wegen der großen Menge
12.3 Verteilte Objektarchitekturen

der zu verarbeitenden Daten werden die Visualisierungsobjekte die festgestellten


Beziehungen in der Regel grafisch darstellen. Dies werde ich in Kapitel 16 behandeln.
Eine verteilte Objektarchitektur ist aus den drei folgenden Gründen für diesen Anwen-
dungstyp besser geeignet als eine Client/Server-Architektur:
• Im Gegensatz zu einem Geldautomatensystem dient dieses logische Modell nicht
zur Bereitstellung von Diensten über festgelegte Dienste für das Datenmanagement.
• Sie können dem System ohne größere Unterbrechungen weitere Datenbanken hinzu-
fügen. Jede Datenbank ist einfach ein weiteres verteiltes Objekt. Die Datenbankobjekte
können eine vereinfachte Schnittstelle anbieten, die den Zugriff auf die Daten steuert.
Die Datenbanken, auf die zugegriffen wird, können sich auf unterschiedlichen Rech-
nern befinden.
• Sie hilft, neue Arten von Beziehungen zu erschließen, indem weitere Integrator-
objekte hinzugefügt werden. Teile des Unternehmens, die an speziellen Beziehun-
gen interessiert sind, können das System durch das Hinzufügen von Integrator-
objekten erweitern. Diese laufen auf ihren Computern, ohne dass sie irgendwelche
Kenntnisse über andernorts benutzte Integratorobjekte benötigen.
Der Hauptnachteil verteilter Objektarchitekturen besteht in dem komplexeren Ent-
wurf im Vergleich zu Client/Server-Systemen. Client/Server-Systeme scheinen eine
ziemlich nahe liegende Art zu sein, wie man sich Systeme vorstellt. Sie spiegeln viele
menschliche Transaktionen wider, bei denen Menschen Dienste anfordern und erhal-
ten, die von anderen Menschen angeboten werden, die sich darauf spezialisiert haben.
Viel schwieriger ist es, sich eine allgemeine Bereitstellung von Diensten vorzustellen,
und bisher gibt es noch keine weit reichenden Erfahrungen beim Entwurf grob struk-
turierter Geschäftsobjekte.

12.3.1 CORBA
Wie ich im vorigen Abschnitt erklärt habe, benötigt die Implementierung verteilter
Objekte eine Middleware (in Form von Object Request Brokers), um die Kommunika-
tion zwischen den verteilten Objekten handhaben zu können. Im Prinzip können die
Objekte innerhalb des Systems unter Benutzung verschiedener Programmiersprachen
implementiert und auf unterschiedlichen Plattformen ausgeführt werden, und sie
müssen keinem der anderen Objekte des Systems bekannt sein. Die Middleware als
"Klebstoff" übernimmt dabei vielfältige Aufgaben, um eine nahtlose Kommunikation
zwischen den Objekten zu gewährleisten.
Middleware zur Unterstützung verteilter Objektsysteme wird auf zwei Ebenen benö-
tigt:
• Auf der Ebene der logischen Kommunikation bietet sie eine Funktionalität, die es
Objekten auf verschiedenen Computern ermöglicht, Daten auszutauschen und Infor-
mationen zu steuern. Zur Erleichterung der logischen Objektkommunikation auf
unterschiedlichen Plattformen wurden Standards wie CORBA und COM (Pritchard,
1999) entwickelt.
• Auf der Komponentenebene bietet sie eine Basis für die Entwicklung kompatibler
Komponenten. Standards wie EJB, CORBA-Komponenten oder Active X (Szyperski,
2002) bieten eine Basis für das Implementieren von Komponenten mit Standard-
methoden, die von anderen Komponenten angefragt und genutzt werden können.
Komponentenstandards werde ich in Kapitel 19 behandeln.

I 311
ARCHITEKTUREN VERTEILTER SYSTEME

Anwendungs- Anwendungs- Horizontal e


objekte bereichs- CORBA-
funktionen Funktionen

Object Request Broker

Abbildung 12.12: Die Struktur einer CORBA-basierten verteilten Anwendung

In diesem Abschnitt konzentriere ich mich auf Middleware für logische Objektkommu-
nikation und lege dar, wie sie von den CORBA-Standards unterstützt wird. Sie wurden
von der Object Management Group (OMG) definiert, die Standards für die objektorien-
tierte Entwicklung herausgibt. Diese Standards werden öffentlich und kostenlos über
die Web-Seiten der OMG angeboten.
Die von der OMG verfolgte Vision einer verteilten Anwendung ist in ~ Abbildung
12.12 dargestellt, die ich von Siegels Diagramm der Objektmanagementarchitektur abge-
leitet habe (Siegel , 1998). Daraus geht hervor, dass eine verteilte Anwendung aus folgen-
den Komponenten aufgebaut werden sollte:
• Anwendungsobjekte, die speziell für diese Anwendung entworfen und implemen-
tiert worden sind.
• Standardobjekte, die von der OMG für einen bestimmten Bereich definiert wurden.
Diese Standards decken die Bereiche Finanzen/Versicherungen, E-Commerce,
Gesundheitswesen und weitere Gebiete ab.
• Elementare CORBA-Dienste, die grundlegende verteilte Computerdienste wie Ver-
zeichnisse und Zugriffsverwaltung anbieten.
• Horizontale CORBA-Funktionalität wie zum Beispiel verschiedene Lösungen für
Bedienoberflächen, Systemmanagement usw. Die Bezeichnung horizontale Funk-
tionalität bedeutet, dass diese auf verschiedenen Gebieten und in zahlreichen
unterschiedlichen Anwendungen zum Einsatz kommen kann.
Die CORBA-Standards decken alle Aspekte dieses Konzepts ab. Zu ihnen gehören vier
wichtige Elemente:
• ein Objektmodell für Anwendungsobjekte, bei dem ein CORBA-Objekt die Kapse-
lung eines Zustands mit einer wohl definierten, sprachneutralen Schnittstelle dar-
stellt, die in einer IDL (Interface Definition Language) beschrieben ist
• ein Object Request Broker (ORB), der Anfragen nach Objektdiensten vermittelt. Der
ORB findet das Objekt, welches den betreffenden Dienst anbietet, kündigt ihm die
Anfrage an, sendet sie ihm zu und gibt das Ergebnis an den Absender der Anfrage
zurück
• eine Reihe allgemeiner Objektdienste, von denen angenommen wird, dass sie von
zahlreichen verteilten Anwendungen benötigt werden. Beispiele dafür sind unter
anderem Verzeichnis-, Transaktions- und Persistenz-Dienste
12.3 Verteilte Objektarchitekturen

• eine Anzahl gemeinsamer Komponenten, die auf diesen Diensten aufgebaut sind
und von den Anwendungen benötigt werden. Dabei kann es sich entweder um ver-
tikale bereichsspezifische oder aber horizontale Komponenten für allgemeine Zwe-
cke handeln, die in vielen Anwendungen zum Einsatz kommen
Beim CORBA-Objektmodell wird ein Objekt wie allgemein üblich als Kapselung von
Attributen und Diensten betrachtet. Allerdings müssen CORBA-Objekte eine separate
Schnittstellendefinition besitzen, welche die öffentlichen Attribute und Operationen
des Objekts definiert. Schnittstellen von CORBA-Objekten werden mit Hilfe einer stan-
dardisierten, sprachneutralen Schnittstellendefinitionssprache (Interface Definition
Language - IDL) definiert. Wenn ein Objekt die Dienste eines anderen Objekts in
Anspruch nehmen möchte, benutzt es dazu die IDL-Schnittstelle. CORBA-Objekte besit-
zen einen eindeutigen Bezeichner, der Interoperable Object Reference (IOR) genannt
wird. Diese IOR wird verwendet, wenn Objekte Dienste voneinander anfordern.
Der ORB kennt die Objekte, die Dienste anfordern, und deren Schnittstellen. Er
steuert die Kommunikation zwischen den Objekten. Die Objekte kennen weder die
Standorte der anderen Objekte, mit denen sie kommunizieren, noch wissen sie irgend-
etwas über deren Implementierung. Da die IDL-Schnittstelle die Objekte vom ORB iso-
liert, kann man die Implementierung von Objekten auf völlig transparente Weise
ändern. Auch der Standort von Objekten kann zwischen den Zugriffen auf das Objekt
unsichtbar für die anderen Systemobjekte geändert werden.
~ Abbildung 12.13 zeigt, wie zwei Objekte, 01 und 02, über einen ORB miteinander
kommunizieren. Das aufrufende Objekt (01) hat einen zugehörigen IDL-Stub, der die
Schnittstelle des Objekts definiert, das den benötigten Dienst bereitstellt. Der Pro-
grammierer von 01 fügt Aufrufe dieses Stubs in seine Objektimplementierung ein,
wenn ein Dienst benötigt wird. Die IDL ist eine Obermenge von C++, so dass der
Zugriff auf diesen Stub sehr einfach ist, wenn Sie in C++ programmieren, aber auch in
C oder Java ist dies nicht schwierig. Anpassungen der IDL an andere Sprachen wie
zum Beispiel Ada oder COBOL sind ebenfalls definiert worden.
Das Dienste anbietende Objekt (Server-Objekt) 02 besitzt ein zugehöriges IDL-Skele-
ton, welches die Schnittstelle mit der Implementierung der Dienste verbindet. Einfach
ausgedrückt: Wenn ein Dienst über die Schnittstelle aufgerufen wird, übersetzt das
IDL-Skeleton dies in einen Aufruf für diesen Dienst, und das unabhängig von der
Sprache, in der er implementiert wurde. Wenn die Methode oder Prozedur ausgeführt
ist, werden die Ergebnisse von dem IDL-Skeleton wieder in IDL zurückübersetzt, so
dass sie vom anrufenden Objekt empfangen werden können. Wenn ein Objekt sowohl
Dienste anbietet als auch andernorts angebotene Dienste benutzt, braucht es ein IDL-
Skeleton und einen IDL-Stub. Im Client-Objekt wird ein IDL-Stub für jedes benutzte
Server-Objekt benötigt.

01 02

s (01) s (02)

Obiact Request Broker

Abbildung 12.13: Objektkommunikation über einen ORB

I 313
ARCHITEKTUREN VERTEILTER SYSTEME

Object Request Broker sind gewöhnlich nicht als separate Prozesse, sondern als Anzahl
von Bibliotheken implementiert, die mit anderen Objektimplementierungen verbunden
werden können. Deshalb muss in einem verteilten System jeder Computer, der verteilte
Objekte bearbeitet, einen eigenen ORB zur Handhabung aller lokalen Zugriffe besitzen.
Eine Anfrage nach einem Dienst eines entfernten Objekts erfordert jedoch eine Kommu-
nikation zwischen verschiedenen ORBs.
Diese Situation ist in ~ Abbildung 12.14 dargestellt. Wenn in diesem Beispiel eins
der Objekte 01 oder 02 einen Dienst von 03 oder 04 anfordert, müssen die jeweiligen
ORBs miteinander Verbindung aufnehmen. Eine CORBA-Implementierung unterstützt
ORB~zu-ORB-Kommunikation, indem sie allen ORBs den Zugriff auf alle IDL-Schnitt-
stellendefinitionen ermöglicht und das Generic Inter-ORB-Protocol (GIOP) nach dem
OMG-Standard verwendet. Dieses Protokoll definiert Standardnachrichten, die ORBs
austauschen können, um den Zugriff auf entfernte Objekte und den Informationstrans-
fer zu implementieren. In Verbindung mit TCP/IP-Protokollen ermöglicht GIOP die
Kommunikation von ORBs über das Internet.
Die CORBA-Initiative wurde schon 1980 begonnen, und die ersten Versionen von
CORBA beschäftigten sich lediglich mit der Unterstützung verteilter Objekte. Im Zuge
der Entwicklung wurden die Standards jedoch immer umfangreicher. Neben einem
Mechanismus für die Kommunikation verteilter Objekte definieren die CORBA-Stan-
dards mittlerweile einige normierte Dienste, die Anwendungen mit verteilten Objek-
ten unterstützen. CORBA-Dienste werden wahrscheinlich von den meisten verteilten
Systemen benötigt.
Sie können sich die CORBA-Dienste als Funktionen vorstellen, die wahrscheinlich
von vielen verteilten Systemen benötigt werden. Die Standards definieren etwa 15 all-
gemeine Dienste, wie zum Beispiel:
• Benennungs- und Vermittlungsdienste, die es Objekten ermöglichen, andere Objekte
innerhalb des Netzwerkes zu finden und zu kontaktieren. Der Benennungsdienst ist
ein Verzeichnisdienst, der es erlaubt, die Objekte mit Namen zu versehen, er ent-
spricht den Seiten eines Telefonbuchs. Die Vermittlungs dienste lassen sich mit den
gelben Seiten eines Branchenverzeichnisses vergleichen. Objekte können hier her-
ausfinden, was andere Objekte beim Vermittlungsdienst registriert haben, und somit
auf die Spezifikation dieser Objekte zugreifen.
• Benachrichtigungsdienste, mit deren Hilfe Objekte anderen Objekten mitteilen kön-
nen, dass ein bestimmtes Ereignis eingetreten ist. Objekte können ihr Interesse an
bestimmten Ereignissen registrieren lassen und werden bei deren Eintritt automa-
tisch benachrichtigt. Nehmen wir zum Beispiel an, dass in einem System ein Dru-
ckerspooler vorhanden ist, der die Reihenfolge der zu druckenden Dokumente
regelt sowie eine Reihe von Druckerobjekten verwaltet. Der Spooler lässt registrie-
ren, dass er an dem Ereignis "Druckvorgang beendet" eines Druckerobjekts interes-
siert ist. Sobald der Ausdruck fertig gestellt ist, versendet der Benachrichtigungs-
dienst dann eine entsprechende Mitteilung, so dass der Spooler den nächsten
Druckauftrag für den betreffenden Drucker starten kann.
• Transaktionsdienste unterstützen automatische Transaktionen und das Rücksetzen
(rollback) im Falle von Fehlern. Transaktionen sind fehlertolerante Prozesse, wel-
che die Wiederherstellung nach Fehlern während eines Aktualisierungsvorgangs
unterstützen. Falls die Aktualisierung eines Objekts misslingt, kann der Objekt-
zustand auf den Stand vor Beginn der Aktualisierung zurückgesetzt werden.
12.4 Interorganisationale verteilte Systeme

01 02 03 04

5 (01) 5 (02) 5 (03) 5 (04)

Object Request Broker Object Request Broker

Netzwerk

Abbildung 12.14: Kommunikation zwischen ORBs

Die CORBA-Standards enthalten Schnittstellendefinitionen für eine große Auswahl


horizontaler und vertikaler Komponenten, die von den Herstellern verteilter Anwen-
dungen benutzt werden können. Vertikale Komponenten sind für bestimmte Anwen-
dungsbereiche charakteristisch. Horizontale Komponenten, wie zum Beispiel Schnitt-
stellenkomponenten, sind für den allgemeinen Gebrauch konzipiert. Die Entwicklung
von Spezifikationen für horizontale und vertikale CORBA-Komponenten ist eine lang-
fristige Tätigkeit, und die aktuell verfügbaren Spezifikationen sind auf den Webseiten
der OMG veröffentlicht.

12.4 Interorganisationale verteilte Systeme


Aus Gründen der Sicherheit und des Zusammenarbeitens wurden verteilte Systeme in
erster Linie auf der Ebene von Organisationen bzw. Unternehmen implementiert. Eine
Organisation besitzt eine Anzahl von Servern, auf denen sie die Rechenlast verteilt.
Da sich alle innerhalb derselben Organisation befinden, können lokale Standards und
Arbeitsabläufe angewendet werden. Bei Web-basierten Systemen liegen Client-Com-
puter jedoch oftmals außerhalb der Organisationsgrenzen und ihre Funktionalität ist
auf das Ausführen einer Software für die Benutzerschnittstelle beschränkt.
Es sind inzwischen jedoch neuere Modelle verteilter Systeme verfügbar, die im
Gegensatz zu intraorganisationalen auch interorganisationale also unternehmensüber-
geordnete verteilte Systeme ermöglichen. Ich werde diese bei den Ansätze in diesem
Abschnitt erörtern. Peer-to-Peer-Systeme basieren darauf, dass die Rechenleistung auf
einzelnen Netzwerkknoten ausgeführt wird. Dienstorientierte Systeme sind auf ver-
teilte Dienste und nicht auf verteilte Objekte angewiesen, sowie auf XML-basierte Stan-
dards zum Datenaustausch.

12.4.1 Peer-to-Peer-Architekturen
Peer-to-Peer-Systeme (P2P) sind dezentralisierte Systeme, in denen die Rechenleis-
tung auf jedem Knoten im Netzwerk ausgeführt werden kann und bei denen zumin-
dest im Prinzip keine Unterscheidung zwischen Clients und Servern vorgenommen
wird. In Peer-to-Peer-Anwendungen ist das Gesamtsystem so entworfen, dass es die
Rechenleistung und den verfügbaren Speicher eines möglicherweise riesigen Compu-
ternetzwerks nutzt. Die Standards und Protokolle, die die Kommunikation der Knoten
untereinander ermöglichen, sind in die Anwendung selbst eingebettet, und auf jedem
Knoten muss eine Kopie dieser Anwendung ausgeführt werden.

I 315
ARCHITEKTUREN VERTEILTER SYSTEME

Bis zum heutigen Zeitpunkt wurden Peer-to-Peer-Technologien hauptsächlich für per-


sönliche Systeme eingesetzt (Oram, 2001). So werden zum Beispiel File-Sharing-Sys-
terne, die auf dem Gnutella- oder Kazaa-Protokoll basieren, dazu verwendet, Dateien
auf den PCs der Benutzer untereinander auszutauschen, und Instant-Messaging-Sys-
terne wie ICQ oder Jabber bieten eine direkte Benutzerkommunikation ohne einen
dazwischen geschalteten Server. SETI@home ist ein Langzeitprojekt zur Verarbeitung
der Daten von Radioteleskopen auf Heim-PCs, um nach Anzeichen außerirdischen
Lebens zu suchen, und Freenet ist eine dezentralisierte Datenbank, die dazu entwi-
ckelt wurde, Informationen anonym zu veröffentlichen, und es Behörden schwierig
macht, diese Informationen zu unterdrücken.
Es gibt jedoch Anzeichen dafür, dass diese Technologie in wachsendem Maße von Fir-
men genutzt wird, um die Leistungsfähigkeit ihrer PC-Netzwerke nutzbar zu machen
(McDougall, 2000). Sowohl Intel als auch Boeing haben P2P-Systeme für recheninten-
sive Anwendungen implementiert. Für kooperative Anwendungen, die verteiltes Arbei-
ten unterstützen, scheint das die effektivste Technologie zu sein.
Sie können die Architektur von P2P-Systemen aus zwei Blickwinkeln betrachten.
Die logische Netzwerkarchitektur beschreibt die Verteilung des Systems, wohingegen
die Anwendungsarchitektur die allgemeine Organisation der Komponenten eines
jeden Anwendungstyps darstellt. In diesem Kapitel konzentriere ich mich auf die
zwei Haupttypen logischer Netzwerkarchitekturen, die im Einsatz sind - dezentrali-
sierte und halbzentralisierte Systeme.
Im Prinzip kann in Peer-to-Peer-Systemen jeder Netzwerkknoten jeden anderen ken-
nen , Verbindungen mit ihm aufnehmen und Daten mit ihm austauschen. In der Praxis
ist das natürlich unmöglich, so dass Knoten in lokale Bereiche organisiert sind, wobei
einige Knoten als Brücken zu anderen lokalen Bereichen fungieren. ~ Abbildung
12.15 zeigt diese dezentralisierte P2P-Architektur.

Abbildung 12.15: Dezentralisierte P2P-Architektur:

In einer dezentralisierten Architektur sind die Knoten im Netzwerk nicht einfach


funktionale Elemente, sondern auch Kommunikationsschalter (switches), die Daten
und Steuerungssignale von einem zum anderen Knoten leiten können. Nehmen wir
z.B. an, dass ~ Abbildung 12.15 ein dezentralisiertes System zur Dokumentenverwal-
tung darstellt. Dieses System wird von einer Gruppe von Forschern genutzt, um Doku-
mente auszutauschen, und jedes Mitglied der Gruppe unterhält seinen eigenen Doku-
mentenvorrat. Wenn jedoch ein Dokument abgerufen wird, stellt es der abrufende
Knoten den anderen ebenfalls zur Verfügung. Wer ein Dokument benötigt, gibt einen
12.4 Interorganisationale verteilte Systeme

Suchbefehl aus, der an Knoten in diesem Bereich geschickt wird, die dann überprü-
fen, ob sie das Dokument haben, und es in diesem Fall an den Anfragenden schicken.
Wenn sie es nicht haben, geben sie die Suche an andere Knoten weiter. Wurde das
Dokument schließlich gefunden, kann der Knoten es an den ursprünglichen Fragestel-
ler zurückleiten. Wenn daher n1 eine Suche nach einem Dokument ausgibt, das auf
n10 gespeichert ist, wird die Suche durch n3, n6 und n9 nach n10 geleitet.
Diese dezentralisierte Architektur hat die offensichtlichen Vorteile, dass sie hoch-
gradig redundant und daher fehlertolerant ist, sowie tolerant gegenüber Knoten, die
sich vom Netzwerk trennen. Es gibt jedoch auch einen erkennbaren Overhead im Sys-
tem, da dieselbe Suche von vielen verschiedenen Knoten ausgeführt werden kann und
die Kommunikation zwischen den einzelnen Rechnern mehrfach stattfindet. Ein alter-
natives P2P-Architekturmodell, das von der reinen P2P-Architektur abweicht, ist
halbzentralisiert, wobei ein oder mehrere Knoten im Netzwerk als Server fungieren,
um die Kommunikation der Knoten zu erleichtern. ~ Abbildung 12.16 veranschau-
licht dieses Modell.
In einer halbzentralisierten Architektur hat der Server die Aufgabe, bei der Kontakt-
aufnahme zwischen Knoten im Netzwerk behilflich zu sein oder die Ergebnisse einer
Berechnung zu koordinieren. Wenn z.B. ~ Abbildung 12.16 ein Instant-Messaging-
System darstellt, kommunizieren die Netzwerkknoten mit dem Server (durch die
gestrichelten Linien angezeigt), um herauszufinden, welche weiteren Knoten verfüg-
bar sind. Sobald diese ausfindig gemacht wurden, kann die direkte Kommunikation
aufgenommen werden und die Verbindung zum Server ist nicht mehr erforderlich.
Daher treten die Knoten n2, n3, n5 und n6 in direkte Kommunikation.
In einem P2P-Berechnungssystem, in dem eine prozessorintensive Berechnung über
eine Vielzahl von Knoten verteilt ist, ist es üblich, dass einige Knoten eine Sonderrolle
einnehmen, indem sie Arbeit an andere Knoten verteilen und die Rechenergebnisse
einsammeln und überprüfen.

8/
/",",== = = =!J

Abbildung 12.16: Eine halbdezentralisierte P2P-Architektur

Obwohl es in Peer-to-Peer-Systemen einen offensichtlichen Overhead gibt, stellen sie


einen wesentlich leistungsfähigeren Ansatz für interorganisationale Systeme dar als
der dienstbasierte Ansatz, den ich im nächsten Abschnitt behandeln werde. Es gibt
immer noch Probleme beim Einsatz von P2P für unternehmensübergreifende Systeme,
da Fragen wie Sicherheit und Vertrauen weiterhin ungelöst sind. Das bedeutet, dass
P2P-Systeme am ehesten entweder für nichtlcritische Informationssysteme eingesetzt
werden oder dann, wenn es bereits funktionierende Beziehungen zwischen Organisa-
tionen gibt.

I 317
ARCHITEKTUREN VERTEILTER SYSTEME

12.4.2 Dienstorientierte Systemarchitektur


Die Entwicklung des WWWbedeutete, dass Client-Computer einen Zugriff auf entfernte
Server außerhalb ihrer eigenen Organisation hatten. Wenn diese Organisationen ihre
Informationen in HTML umwandelten, konnten die Computer darauf zugreifen. Der
Zugriff erfolgte jedoch ausschließlich über einen Web-Browser, und der direkte Zugriff
auf die Informationsspeicher mit anderen Programmen war nicht praktikabel. Das
bedeutete, dass außergewöhnliche aber zweckmäßige Verbindungen zwischen Servern,
bei denen z.B. ein Programm eine Anzahl von Katalogen abfragte, nicht möglich waren.
Um dieses Problem zu umgehen, wurde der Begriff eines Web dienstes vorgeschla-
gen. Unter Verwendung eines Web dienstes können Organisationen, wenn gewünscht,
ihre Informationen für andere Programme durch Definition und Veröffentlichung einer
Web dienst-Schnittstelle zugänglich machen. Diese Schnittstelle definiert die verfügba-
ren Daten und den Zugriff darauf. Allgemeiner gesprochen ist ein Webdienst eine Stan-
darddarstellung für eine Rechen- oder Informationsressource, die von anderen Pro-
grammen genutzt werden kann. Daher könnten Sie einen Steuerdienst definieren, über
den die Benutzer ihre Steuererklärung ausfüllen können, die dann automatisch über-
prüft und an das Finanzamt übertragen wird.
Ein Webdienst ist eine Instanz eines allgemeineren Dienstbegriffs, der von Lovelock
et al. (Lovelock et al. , 1996) wie folgt definiert wird:

Binden

Abbildung 12.17: Die konzeptionelle Architektur eines dienstorientierten Systems

eine Handlung oder Leistung, die ein Beteiligter einem anderen anbietet. Obwohl
der Prozess an ein physisches Produkt gekoppelt sein kann, ist die Leistung im
Wesentlichen immateriell und führt in der Regel nicht zum Besitz irgen dein er
der Produktionsfaktoren.
Das Wesen des Dienstes besteht daher darin, dass seine Bereitstellung unabhängig von
der Anwendung ist, die diesen Dienst nutzt (Turner et al., 2003). Dienstanbieter können
spezialisierte Dienste entwickeln und diese einer Vielzahl von Nutzern aus verschiede-
nen Organisationen anbieten. Durch Einbinden der Dienste verschiedener Anbieter kön-
nen Anwendungen erstellt werden, entweder unter Verwendung einer Standardprogram-
miersprache oder einer spezialisierten Dienstorchestrierungssprache wie BPEL4WS.
Es gibt verschiedene Dienstmodelle, vom JINI-Modell (Kumaran, 2001) bis hin zu
Web- (Stal, 2002) und Grid-Diensten (Foster et al., 2002). Konzeptionell arbeiten alle
diese Modelle wie das in ~ Abbildung 12.17 gezeigte, das eine Verallgemeinerung des
von Kreger (Kreger, 2001) beschriebenen konzeptionellen Webdienstmodell ist. Ein
Dienstanbieter bietet einen Dienst an, indem er seine Schnittstelle definiert und die
Funktionalität implementiert. Ein Nutzer des Dienstes bindet ihn in seine Anwendung
ein. Das bedeutet, dass diese Anwendung Code enthält, um den Dienst aufzurufen und
12.4 Interorganisationale verteilte Systeme

die Ergebnisse des Aufrufs zu verarbeiten. Um sicherzustellen, dass externe Nutzer auf
den Dienst zugreifen können, nimmt der Dienstanbieter einen Eintrag in der Dienst-
registratur vor, die Informationen über die Dienste und ihre Funktionen enthält.
Im Folgenden sind die Unterschiede zwischen diesem Dienstmodell und dem ver-
teilten Objektansatz für die verteilten Systemarchitekturen dargestellt:
• Jeder Dienstanbieter innerhalb oder außerhalb einer Organisation kann Dienste an-
bieten. Unter der Annahme, dass diese Dienste bestimmte Standards erfüllen (siehe
weiter unten), können Organisationen Anwendungen durch Integration von Diens-
ten mehrerer Anbieter erstellen. Ein Fertigungsunternehmen könnte zum Beispiel
direkt Verknüpfungen zu Diensten herstellen, die ihre Zulieferer anbieten.
• Der Dienstanbieter veröffentlicht Informationen zu dem Dienst, so dass jeder be-
rechtigte Nutzer ihn verwenden kann. Der Dienstanbieter und der -nutz er müssen
nicht über die Funktionalität des Dienstes verhandeln, bevor er in ein Anwen-
dungsprogramm integriert werden kann.
• Anwendungen können das Einbinden der Dienste verzögern, bis sie ausgeliefert sind
oder ausgeführt werden. Daher könnte z.B. eine Anwendung, die einen Aktienkurs-
dienst nutzt, während der Ausführung den Dienstanbieter dynamisch wechseln.
• Die unsystematische Erstellung neuer Dienste ist möglich. Ein Dienstanbieter kann
neue Dienste erkennen, die durch Einbinden vorhandener Dienste auf innovative
Art erstellt werden können.
• Dienstnutzer können für die Dienste nach dem Umfang der Nutzung anstatt für die
Bereitstellung bezahlen. Daher kann der Anwendungsautor einen externen Dienst
verwenden, den er nur bei Bedarf bezahlt, anstatt eine selten genutzte Komponente
käuflich zu erwerben.
• Anwendungen können verkleinert werden (was wichtig ist, wenn sie in andere
Geräte eingebettet werden sollen), da sie die Ausnahmebehandlung als externe
Dienste implementieren können.
• Anwendungen können reaktiv sein und ihre Arbeitsweise an die Umgebung anpas-
sen, indem sie bei Veränderungen ihrer Umgebung unterschiedliche Dienste ein-
binden.
Zum Zeitpunkt der Arbeit an diesem Buch haben diese Vorteile ein enormes Interesse
an Webdiensten als Basis für das Erstellen lose gekoppelter, verteilter Anwendungen
ausgelöst. Es gibt jedoch immer noch nur begrenzte praktische Erfahrungen mit
dienstorientierten Architekturen, so dass wir die praktischen Auswirkungen dieses
Ansatzes noch nicht kennen.
Die Wiederverwendung von Software war mehrere Jahre lang ein Forschungsthema,
und, wie ich in Kapitel 18 und 19 darlegen werde, dennoch bleiben dabei immer noch
viele praktische Schwierigkeiten bestehen. Eines der Hauptproblerne war, dass Stan-
dards für wiederverwendbare Komponenten erst vor kurzem entwickelt wurden und
dass mehrere Standards in Benutzung sind. Die Initiative für die Webdienste wurde
jedoch von Beginn an von Standards angetrieben, und es sind Standards in Entwick-
lung, die viele Aspekte von Webdiensten abdecken. Die drei fundamentalen Stan-
dards, die die Kommunikation zwischen Webdiensten ermöglichen, sind:

I 319
ARCHITEKTUREN VERTEILTER SYSTEME

o SOAP (Simple Object Access Protocol) Dieses Protokoll definiert eine Organisa-
tion für den strukturierten Datenaustausch zwischen Webdiensten.
o WSDL (Web Services Description Language) Dieses Protokoll definiert, wie die
Schnittstelle von Webdiensten dargestellt werden kann.
D UDDI (Universal Description, Discovery and Integration) Hierbei handelt es sich
um einen Webdienstpublikationsstandard, der definiert, wie die Information zu
Dienstbeschreibungen organisiert werden können, die von Dienstanfragenden
zum Auffinden von Diensten verwendet werden.
Alle diese Standards basieren auf XML - eine menschen- und maschinenlesbare Aus-
zeichnungs sprache (Skonnard and Gudgin, 2002). Um das Konzept der Webdienste zu
verstehen, benötigen Sie jedoch keine Detailkenntnisse über diese Standards.
Architekturen von Webdienstanwendungen sind lose gekoppelte Architekturen, bei
denen sich die eingebundenen Dienste während der Ausführung ändern können. Einige
Systeme werden nur unter Verwendung von Webdiensten erstellt und andere mischen
Webdienste mit lokal entwickelten Komponenten. Zur Veranschaulichung, wie Anwen-
dungen organisiert sein können, betrachten Sie bitte das folgende Szenario:

Mobiler Informationsdienst Dienstermittlung


Finden verfüg-
Sammelt Informationen baren Dienst

Koordinaten

Empfänger Sender Benutzerschnittstelle


Empfängt Sendet Position Empfängt
Informationsstream und Informations- Anforderung
von Diensten anfrage an Dienst vom Benutzer

Funk Lokalisierer
Übersetzt digitalen Ermittelt
Informationsstream Autoposition
in Funksignal
In-car software system
Abbildung 12.18: Ein dienstbasiertes Auto-Informationssystem
12.4 Interorganisationale verteilte Systeme

Ein fest installiertes Kfz-Informationssystem versorgt den Fahrer mit Angaben zum
Wetter, zu Verkehrs bedingungen, lokalen Informationen usw. Es ist mit dem Auto-
radio verbunden, so dass diese Informationen als Signal über einen bestimmten
Radiokanal ausgegeben werden. Das Auto ist zur Positionsbestimmung mit einem
GPS-Sender ausgestattet, und anhand dieser Angaben greift das System auf eine
Anzahl von Informationsdiensten zu, die in der Sprache des Fahrers ausgegeben wer-
den können.
~ Abbildung 12.18 zeigt eine mögliche Organisation eines solchen Systems. Die
Software enthält fünf Module, die die Kommunikation mit dem Fahrer, dem GPS-
Empfänger, der die Position des Autos meldet, und dem Autoradio handhaben. Die
Module Transmitter und Receiver sorgen für die Kommunikation mit externen Diens-
ten.
Das Auto kommuniziert mit einem extern angebotenen mobilen Informationsdienst,
der Informationen aus einer Anzahl anderer Dienste zusammenfasst, die Auskünfte
über das Wetter, Verkehrshinweise und lokale Infrastruktur anbieten. Dieser Dienst
wird von unterschiedlichen Anbietern in verschiedenen Orten angeboten, und das
Autosystem nutzt einen Erkennungsdienst, um die geeigneten Informationen zu orten
und einzubinden. Der Erkennungsdienst wird ebenfalls vom mobilen Informations-
dienst genutzt, um die geeigneten Wetter-, Verkehrs- und Infrastrukturdienste ein-
zubinden. Die Dienste tauschen SOAP-Nachrichten aus, die GPS-Positionsangaben
enthalten, welche von den Diensten verwendet werden, um die geeigneten Informa-
tionen auszuwählen. Die gesammelten Informationen werden über einen Dienst
zurück an das Fahrzeug übergeben, der die Informationssprache in die Sprache des
Fahrers übersetzt.
Dieses Beispiel veranschaulicht einen der Hauptvorteile des dienstorientierten
Ansatzes. Bei der Entwicklung oder Herausgabe des Systems sind keine Kenntnisse
darüber vonnpten, welcher Dienstanbieter verwendet und auf welche Dienste zuge-
griffen wird. Beim Fahren nutzt die im Fahrzeug befindliche Software den Erken-
nungsdienst, um den am besten geeigneten Informationsdienst zu finden und ihn ein-
zubinden. Dank des Übersetzungsdienstes kann es sich über Grenzen hinausbewegen
und lokale Informationen für Personen zugänglich machen, die der Landessprache
nicht mächtig sind.
Diese Version dienstorientierter Systeme ist mit den aktuell verfügbaren Webdiens-
ten noch nicht realisierbar, bei denen das Einbinden von Diensten in Anwendungen
noch ziemlich statisch ist. Es ist jedoch wahrscheinlich, dass wir während der Lebens-
dauer dieser Auflage dynamischere Möglichkeiten zur Einbindung und entsprechende
Anwendungsarchitekturen kennen lernen werden. Es steht außer Frage, dass das
dienstorientierte Modell eine sehr wichtige neue Methode zum Implementieren ver-
teilter, interorganisationaler Systeme darstellt.

I 321
ARCHITEKTUREN VERTEILTER SYSTEME

Zusammenfassu ng
• Verteilte Systeme unterstützen Ressourcenteilung, Offenheit, Nebenläufigkeit, Skalierbarkeit,
Fehlertoleranz und Transparenz.
• ClientJServer-Systeme sind verteilte Systeme, bei denen das System als eine Menge von Diens-
ten modelliert ist, die von Servern für die Prozesse der Clients bereitgestellt werden.
• In einem ClientJServer-System ist die Bedienoberfläche immer bei einem Client angesiedelt, und
das Datenmanagement wird immer von einem gemeinsamen Server übernommen. Die Anwen-
dungsfunktionalität kann auf dem Computer des Clients oder auf dem Server implementiert
werden.
• In einer verteilten Objektarchitektur gibt es keinen Unterschied zwischen Clients und Servern.
Objekte stellen allgemeine Dienste bereit, die von anderen Objekten abgerufen werden kön-
nen. Dieser Ansatz kann auch bei der Implementierung von ClientJServer-Systemen zur Anwen-
dung kommen.
• Verteilte Objektsysteme benötigen eine Middleware zum Handhaben der Objektkommunikation
sowie zum Hinzufügen und Entfernen von Objekten.
• Die CORBA-Standards bestehen aus mehreren Standards für Middleware, die verteilte Objekt-
architekturen unterstützen und die Definitionen für Objektmodelle, für einen Object Request
Broker und für gemeinsame Dienste umfassen. Es sind unterschiedliche Implementierungen der
CORBA-Standards verfügbar.
• Peer-to-Peer-Architekturen sind dezentralisierte Architekturen, bei denen es keine erkennbaren
Clients und Server gibt. Berechnungen können über viele Systeme in unterschiedlichen Organi-
sationen verteilt sein.
• Dienstorientierte Systeme werden durch Verknüpfen von Softwarediensten verschiedener Soft-
wareanbieter erstellt. Ein wichtiger Gesichtspunkt dienstorientierter Architekturen besteht
darin, dass das Einbinden von Diensten an die Architekturkomponenten aufgeschoben werden
kann, bis das System ausgeliefert oder ausgeführt wird.

Ergänzende Literatur
Turning software into a service. Ein guter Übersichtsartikel, der die Prinzipien dienst-
orientierter Systeme darstellt. Im Gegensatz zu anderen Veröffentlichungen zu diesem
Thema verbirgt er diese Prinzipien nicht durch Diskussionen zu den beteiligten Stan-
dards. (M. Turner et al., IEEE Computer, 36 (10), October 2003.)
Peer-to-Peer: Harnessing the Power of Disruptive Technologies Obwohl dieses Buch
nicht viel zu P2P-Architekturen sagt, ist es eine hervorragende Einführung in P2P-Sys-
terne und erörtert Organisation und Ansatz vieler P2P-Systeme. (A. Oram (Hrsg.),
2001, O'Reilly and Associates, Inc.)
Distributed Systems: Concepts and Design, 3rd ed. Ein umfassendes Handbuch, das
alle Aspekte des Entwurfs und der Implementierung verteilter Systeme behandelt.
Insbesondere die ersten beiden Artikel sind für das hier behandelte Material relevant.
(G. Couloris et al., 2001, Addison-Wesley.)
Übungen

Middleware: A model for distributed systems services. Dieser Artikel enthält einen
ausgezeichneten Überblick, der die Funktion von Middleware in verteilten Systemen
zusammenfasst und den möglichen Einsatzbereich von Middleware-Diensten erörtert.
(P. A. Bernstein, Comm. ACM, 39(2), Februar 1996.)

Übungen Kapitel 12
IW Erklären Sie, warum verteilte Systeme prinzipiell besser skalierbar sind als
zentralisierte Systeme. Wodurch wird die Skalierbarkeit unter Umständen
begrenzt?
IEII Was ist der grundlegende Unterschied zwischen einem Fat-Client- und ei-
nem Thin-Client-Ansatz für die Systementwicklung? Erklären Sie, warum
durch den Einsatz von Java als Implementierungssprache der Unterschied
zwischen diesen Ansätzen an Bedeutung verliert.
lf!I Ihr Kunde möchte ein Informationssystem für Aktien entwickeln, das
Wertpapierhändlern Informationen über Unternehmen liefert und ihnen
mit Hilfe eines Simulationssystems die Bewertung verschiedener Invest-
mentszenarien ermöglicht. Jeder Händler nutzt diese Simulation auf unter-
schiedliche Weise, je nach seinen individuellen Kenntnissen und der Art
seiner Aktienanlagen. Schlagen Sie eine Client/Server-Architektur für die-
ses System vor, aus der erkennbar ist, an welcher Stelle des Systems die
Funktionalität angesiedelt ist. Begründen Sie, warum Sie ein Client/Ser-
ver-Modell gewählt haben.
lf!J Erläutern Sie (bezogen auf das Anwendungsmodell aus ~ Abbildung 12.4)
Probleme, die sich bei der Umstellung eines in den achtziger Jahren zur
Bearbeitung von Versicherungspolicen auf einem Großrechner installier-
ten Legacy-Systems zu einer Client/Server-Architektur ergeben könnten.
lfII Für welche grundlegenden Aktivitäten ist ein Object Request Broker ver-
antwortlich?
lf!I Erklären Sie, warum die Implementierung skalierbarer Client/Server-Sys-
terne durch die Verwendung verteilter Objekte in Verbindung mit einem
Object Request Broker vereinfacht wird. Belegen Sie Ihre Antwort mit
einem Beispiel.
lfII Wie wird die CORBA-IDL angewendet, um die Kommunikation zwischen
Objekten zu unterstützen, die mit Hilfe verschiedener Sprachen program-
miert wurden? Erklären Sie, warum dieser Ansatz die Leistungsfähigkeit
des Systems beeinträchtigen kann, falls zur Implementierung der Objekte
verschiedene Programmiersprachen verwendet werden, die sich sehr stark
unterscheiden.

I 323
ARCHITEKTUREN VERTEILTER SYSTEME

mII Schlagen Sie unter Verwendung eines Ansatzes mit verteilten Objekten
eine Architektur für ein nationales Theaterbuchungssystem vor, bei dem
die Benutzer die Platzverfügbarkeit überprüfen und Sitzplätze bei einer
Gruppe von Theatern buchen können. Das System sollte die Eintrittskar-
tenrückgabe unterstützen, so dass Eintrittskarten für den Last-Minute-Ver-
kauf an andere Kunden zurückgegeben werden können.
Im Geben Sie zwei Vor- und zwei Nachteile dezentralisierter und halbdezent-
ralisierter Peer-to-Peer-Architekturen an.
ifIIl] Was sind die Vorteile des dynamischen Einbindens in ein dienstorientier-
tes System?
i!ID Erläutern Sie, warum es für das Autoinformationssystem am besten ist,
dass die Software mit einem Sammeldienst anstatt direkt mit den Infor-
mationsdiensten kommuniziert. In Ihrer Antwort sollten Sie Fragen wie
die Zuverlässigkeit der Kommunikation berücksichtigen.
ifI!) Die Entwicklung dienstorientierter Systeme basiert auf den frühen Spezi-
fikationen und der Annahme von Standards. Erläutern Sie die allgemeine
Bedeutung der Standardisierung für die Unterstützung bzw. Behinderung
des Wettbewerbs und der Innovation auf dem Softwaremarkt.

Lösungen für ausgewählte Übungen dieses Kapitels finden Sie unter www.pearson-
studium.de auf der Companion Website zum Buch.
Anwendungsarchitekturen

13.1 Datenverarbeitende Systeme . . . . . . . . . . . . . . . . . .. 328

13.2 Transaktionsverarbeitende Systeme . . . . . . . . . . . . .331


13.2.1 Informations- und ressourcenverwaltende Systeme.. 333

13.3 Ereignisverarbeitende Systeme. . . . . . . . . . . . . . . . .. 337

13.4 Sprachverarbeitende Systeme . . . . . . . . . . . . . . . . . . . 340

Zusammenfassung .. ................. .. . ....... . 342

Ergänzende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . .. 343

Übungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
ANWENDUNGSARCHITEKTUREN

Lernziele Das Ziel dieses Kapitels besteht in der Einführung von Architekturmodellen für
bestimmte Klassen von Anwendungssoftwaresystemen. Wenn Sie dieses Kapitel gelesen
haben, werden Sie
• zwei grundlegende Organisationsarchitekturen kommerzieller Systeme kennen, nämlich die
Stapel- (bateh) und Transaktionsverarbeitung
• die abstrakte Architektur von Systemen zur Informations- und Ressourcenverwaltung ver-
stehen
• verstehen, wie befehlsgesteuerte Systeme, Z.B. Editoren, als ereignisverarbeitende Systeme
strukturiert werden können
• die Struktur und Organisation von sprachverarbeitenden Systemen kennen

Wie ich in Kapitel 11 dargelegt habe, können Sie Systemarchitekturen aus unter-
schiedlichen Blickwinkeln betrachten. Bislang konzentrierte sich die Erörterung von
Systemarchitekturen in den Kapiteln 11 und 12 auf architektonische Perspektiven
und Fragestellungen wie Steuerung, Verteilung und Systemstruktur. In diesem Kapitel
verfolge ich jedoch einen alternativen Ansatz und betrachte die Architekturen aus
einer Anwendungsperspektive.
Anwendungssysteme sind darauf ausgelegt, kommerzielle oder organisatorische
Bedürfnisse zu befriedigen. Alle Geschäftsbetriebe haben viel gemeinsam - sie müs-
sen Mitarbeiter einstellen, Rechnungen ausstellen, Konten verwalten usw. - und das
gilt insbesondere für Firmen aus derselben Branche. Daher benötigen Telefongesell-
schaften neben allgemeinen Geschäftsfunktionen Systeme um Anrufe zu verbinden,
ihr Netzwerk zu verwalten, Rechnungen an Kunden herauszugeben usw. Folglich
erhalten die von ihnen genutzten Anwendungssysteme viele Gemeinsamkeiten.
In der Regel haben Systeme desselben Typs ähnliche Architekturen und die Unter-
schiede zwischen diesen Systemen liegen in ihrer speziellen Funktionalität. Diese
Tatsache kann durch das Wachstum von ERP-Systemen (ERP, Enterprise Resource
Planning) wie SAP R/3 (Appelrath and Ritter, 2000) und vertikaler Softwarelösungen
für bestimmte Anwendungen veranschaulicht werden. Bei allen diesen Systemen, die
ich in Kapitel 18 kurz behandeln werde, wird ein Standardsystem konfiguriert, um
eine spezifische Geschäftsanwendung zu erstellen. Zum Beispiel kann ein System zur
Wertschöpfungskettenverwaltung an verschiedene Arten von Lieferanten, Waren und
Vertragsvereinbarungen angepasst werden.
In der vorliegenden Erörterung von Anwendungsarchitekturen stelle ich allgemeine
Strukturmodelle mehrerer Anwendungstypen vor. Ich erläutere die grundlegende Orga-
nisation dieser Anwendungstypen und schlüssele, wenn möglich, die High-Level-
Architektur auf, um Subsysteme zu zeigen, die normalerweise in Anwendungen enthal-
ten sind.
Als Softwareentwickler können Sie diese allgemeinen Anwendungsarchitekturen
auf vielfältige Weise nutzen:
• als Ausgangspunkt für den architektonische Entwurfsprozess: Wenn Sie mit dieser
Art von Anwendung nicht vertraut sind, können Sie Ihre anfänglichen Entwürfe
auf die allgemeinen Architekturen gründen. Sie müssen natürlich für spezielle Sys-
teme angepasst werden, sind aber ein guter Ausgangspunkt für ihren Entwurf.
• als Kontrollliste für den Entwurf: Wenn Sie eine Systemarchitektur entworfen haben,
können Sie sie anhand der allgemeinen Anwendungsarchitektur daraufhin überprü-
fen, ob sie eine wichtige Komponente vergessen haben.
• als Möglichkeit, die Arbeit im Entwicklungsteam zu organisieren: Die Anwendungs-
architekturen erkennen stabile strukturelle Merkmale der Systemarchitekturen, und
in vielen Fällen ist es möglich, diese parallel zu entwickeln. Sie können Aufgaben an
Gruppenmitglieder delegieren, um verschiedene Subsysteme innerhalb der Architek-
tur zu implementieren.
• als Mittel zur Bewertung der Wiederverwendbarkeit von Komponenten: Wenn Sie
Komponenten haben, die Sie möglicherweise wieder verwenden können, können Sie
diese mit den allgemeinen Strukturen vergleichen, um zu beurteilen, ob eine Wieder-
verwendung in der zu entwickelnden Anwendung infrage kommt.
• als Wörterbuch für Gespräche über Anwendungstypen: Wenn Sie eine bestimmte
Anwendung erörtern oder versuchen, Anwendungen desselben Typs zu vergleichen,
können Sie die in der allgemeinen Architektur erkannten Konzepte nutzen, um über
diese Anwendungen zu sprechen.
Es gibt viele Arten von Anwendungssystemen, die oberflächlich betrachtet alle sehr
unterschiedlich zu sein scheinen. Wenn Sie jedoch die architektonische Organisation
von Anwendungen untersuchen, haben viele dieser oberflächlich unähnlichen Anwen-
dungen vieles gemeinsam. Ich veranschauliche das hier, indem ich die Architekturen
von vier weit verbreiteten Anwendungstypen beschreibe:

o Datenverarbeitende Anwendungen: Bei ihnen handelt es sich um datengesteuerte


Anwendungen. Sie verarbeiten Daten in Stapeln (Batch- Verarbeitung) ohne expli-
zite Benutzereingriffe während der Verarbeitung. Die genauen Tätigkeiten, die die
Anwendung vornimmt, hängen von der Art der zu verarbeitenden Daten ab. Sta-
pelverarbeitende Systeme sind in kommerziellen Anwendungen weit verbreitet,
bei denen ähnliche Vorgänge für umfangreiche Datenmengen durchgeführt wer-
den. Sie decken einen großen Bereich von Verwaltungstätigkeiten wie Gehalts-
abrechnung, Rechnungsschreibung, Abrechnung und Werbung ab.
o Transaktionsverarbeitende Anwendungen: Diese Anwendungen sind datenbank-
zentriert. Sie verarbeiten Benutzeranfragen nach Informationen und aktualisieren
diese in einer Datenbank. Es sind die am meisten verbreiteten Arten interaktiver
kommerzieller Systeme. Sie sind so organisiert, dass die Benutzeraktionen sich
nicht gegenseitig behindern und die Integrität der Datenbank gewahrt wird. Zu
dieser Klasse von Systemen gehören interaktive Banken-, E-Commerce-, Informa-
tions- und Buchungssysteme.
D Ereignisverarbeitende Systeme: Dies ist eine sehr große Klasse von Anwendun-
gen, wobei die Aktivitäten des Systems von der Auswertung von Ereignissen in
seiner Umgebung abhängen. Ein solches Ereignis kann die Eingabe eines Befehls
durch einen Systembenutzer oder die Änderung einer Variablen sein, die vom
System überwacht wird. Viele PC-basierte Anwendungen, beispielsweise Spiele,
Editiersysteme wie Textverarbeitungsprogramme, Tabellenkalkulationen, Bildver-
arbeitungsprogramme und Präsentationssysteme sind ereignisverarbeitende Sys-
teme. Auch Echtzeitsysteme, die in Kapitel 15 behandelt werden, fallen in diese
Kategorie.

I 327
ANWENDUNGSARCHITEKTUREN

D Sprachverarbeitende Systeme: Hierbei handelt es sich um Systeme, in denen die


Absichten des Benutzers in einer formalen Sprache (wie z.B. Java) ausgedrückt
sind. Ein sprachverarbeitendes System wandelt diese Sprache in ein internes
Format um und interpretiert dann diese interne Darstellung. Die bekanntesten
sprachverarbeitenden Systeme sind Compiler, die in High-Level-Sprachen ver-
fasste Programme in Maschinencode umwandeln. Sprachverarbeitende Systeme
werden jedoch auch verwendet, um Befehlssprachen für Datenbanken, Informa-
tionssysterne und Markup-Sprachen wie XML (Harold and Means, 2002) zu inter-
pretieren, die ausgiebig zur Beschreibung strukturierter Daten eingesetzt werden.
Ich habe diese speziellen Systemtypen ausgesucht, weil sie den Großteil der heute ge-
nutzten Systeme bilden. Kommerzielle Systeme sind im Allgemeinen entweder daten-
oder transaktionsverarbeitende Systeme, und der größte Teil der PC-Software basiert auf
einer ereignisverarbeitenden Architektur. Auch Echtzeitsysteme sind ereignisverarbei-
tende Systeme; diese Architekturen behandle ich in Kapitel 15. Die komplette Software-
entwicklung stützt sich auf sprachverarbeitende Systeme wie Compiler.
Stapel- und transaktionsverarbeitende Systeme sind beide datenbankzentriert. Auf-
grund der zentralen Wichtigkeit der Daten ist es üblich, dass Anwendungen verschiede-
nen Typs auf dieselbe Datenbank zugreifen. Zum Beispiel nutzt ein kommerzielles daten-
verarbeitendes System, das Kontoauszüge druckt, dieselbe Kundenkontendatenbank wie
ein transaktionsverarbeitendes System, das einen Web-basierten Zugang zu Kontoinfor-
mationen anbietet.
Wie ich in Kapitel 11 dargelegt habe, folgen komplexe Anwendungen selten einem ein-
zelnen, einfachen Architekturmodell. Stattdessen haben sie oftmals eine Hybrid-
architektur, wobei verschiedene Teile der Anwendung auf unterschiedliche Art struktu-
riert sind. Beim Entwurf dieser Systeme müssen Sie daher sowohl die Architektur
einzelner Subsysteme als auch ihre Integration in die Architektur des Gesamtsystems in
Betracht ziehen.

13.1 Datenverarbeitende Systeme


Unternehmen sind auf datenverarbeitende Systeme angewiesen, die viele Aspekte ihres
Geschäfts wie Gehaltsabrechnung, Aufstellen und Drucken von Rechnungen, das Unter-
halten von Konten und die Ausgabe von Verlängerungen für Versicherungspolicen aus-
führen. Wie der Name schon sagt, konzentrieren sich diese Systeme auf Daten, und die
Datenbanken, auf die sie angewiesen sind, sind in der Regel um Größenordnungen größer
als sie selbst. Datenverarbeitende Systeme sind stapelverarbeitende Systeme, bei denen
die Ein- und Ausgabe stapelweise aus einer Datei anstatt von einem Benutzerterminal
erfolgt. Diese Systeme wählen Daten aus den Eingabesätzen aus und führen in Abhängig-
keit von den Werten der entsprechenden Felder einige im Programm angegebene Aktio-
nen aus. Sie können das Ergebnis der Berechnung dann in die Datenbank zurückschrei-
ben sowie die Ein- und die berechnete Ausgabe für den Ausdruck formatieren.
Die Architektur von stapelverarbeitenden Systemen umfasst drei Hauptkomponen-
ten, wie in ~ Abbildung 13.1 dargestellt. Eine Eingabekomponente sammelt Eingaben
aus einer oder mehreren Quellen, eine verarbeitende Komponente führt unter Verwen-
dung dieser Eingaben Berechnungen durch und eine Ausgabekomponente erstellt eine
Ausgabe, die in die Datenbank zurückgeschrieben und ausgedruckt wird. Ein System
zur Abrechnung von Telefonkosten verwendet zum Beispiel die Kundendatensätze
13.1 Datenverarbeitende Systeme

und die Werte des Gebührenzählers einer Vermittlungsstelle (Eingabe), berechnet die
Kosten für die einzelnen Kunden (Verarbeitung) und erzeugt dann gedruckte Rech-
nungen (Ausgabe).
Die Eingabe-, Verarbeitungs- und Ausgabekomponenten können selbst weiter in
eine Eingabe-Verarbeitung-Ausgabe-Struktur zerlegt werden. Zum Beispiel:
• Eine Eingabekomponente könnte einige Daten (Eingabe) aus einer Datei oder Daten-
bank lesen, die Gültigkeit der Daten prüfen und einige Fehler korrigieren (Verarbei-
tung) und dann die gültigen Daten zur Verarbeitung in eine Warteschlange stellen
(Ausgabe).
• Eine Verarbeitungskomponente könnte eine Transaktion aus einer Warteschlange
nehmen (Eingabe), einige Berechnungen an den Daten durchführen und einen neuen
Datensatz erzeugen, in dem die Ergebnisse der Berechnung aufgezeichnet werden
(Verarbeitung), und diesen neuen Datensatz dann in eine Druckwarteschlange stellen
(Ausgabe). Manchmal wird die Berechnung in der Systemdatenbank vorgenommen
und manchmal handelt es sich um ein eigenes Programm.
• Eine Ausgabekomponente könnte Datensätze aus einer Warteschlage lesen (Eingabe),
diese in Übereinstimmung mit dem Ausgabeformat formatieren (Verarbeitung) und
dann an einen Drucker senden oder neue Datensätze zurück in die Datenbank schrei-
ben (Ausgabe).

Datenbank

Abbildung 13.1: Eingabe-Verarbeitung-Ausgabe-Modell eines datenverarbeitenden Systems

Die Eigenschaft datenverarbeitender Systeme, dass Datensätze oder Transaktionen seri-


ell verarbeitet werden und kein Zustand über Transaktionen hinweg verwaltet werden
muss, bedeutet, dass diese Systeme von Natur aus funktions- und nicht objektorientiert
sind. Funktionen sind Komponenten, die keine internen Zustands informationen von
einem Aufruf zum anderen verwalten. Die in Kapitel 8 eingeführten Datenflussdia-
gramme sind eine gute Möglichkeit, die Architektur kommerzieller datenverarbeitender
Systeme zu beschreiben.
Mit Hilfe dieser Diagramme können Sie funktionsorientierte Systeme darstellen,
wobei jedes abgerundete Rechteck im Datenfluss eine Funktion anzeigt, die eine Daten-
umwandlung ausführt, und jeder Pfeil ein Datenobjekt bedeutet, dass von der Funktion
verarbeitet wird. Dateien oder Datenspeicher sind als Rechtecke dargestellt. Der Vorteil
von Datenflussdiagrammen besteht darin, dass sie die Verarbeitung von Anfang bis
Ende zeigen. Das heißt, Sie sehen alle Funktionen, die auf Daten einwirken, während
sie sich durch die verschiedenen Stufen des Systems bewegen. Die grundlegende Struk-
tur des Datenflusses besteht aus einer Eingabefunktion, die Daten an eine Verarbeitungs-
funktion und dann an eine Ausgabefunktion übergibt.

I 329
ANWENDUNGSARCHITEKTUREN

~ Abbildung 13.2 veranschaulicht, wie Datenflussdiagramme verwendet werden kön-


nen, um eine genauere Sicht auf die Architektur eines datenverarbeitenden Systems
zu geben. Sie zeigt den Entwurf eines Gehaltsabrechnungssystems. Bei diesem System
werden die Informationen über die Mitarbeiter der Organisation in das System einge-
lesen, das Monatsgehalt und die Abzüge berechnet sowie die Zahlungen ausgeführt.
Sie können sehen, wie dieses System der grundlegenden Eingabe-Verarbeitung-Aus-
gabe-Struktur folgt:

S teuerab z ug +
SoziaJvel'sich erungs -
nummer + Fin an zamt

Ahzug fü r Sozial versich erun g


+ Sozi aJvcl's icherungs nummer

Abbildung 13.2: Datenflussdiagram eines Gehaltsabrechnungssystems

• Die auf der linken Seite des Diagramms befindlichen Funktionen Mitarbeiterdaten-
satz lesen, Monatliche Zahlungsdaten lesen und Mitarbeiterdaten validieren lesen
die Daten für die einzelnen Mitarbeiter ein und prüfen diese Daten.
• Die Funktion Gehalt berechnen bestimmt das Gesamtbruttogehalt der einzelnen
Mitarbeiter und die verschiedenen anfallenden Abzüge von diesem Gehalt. Dann
wird das monatliche Nettogehalt berechnet.
• Die Ausgabefunktionen schreiben in eine Reihe von Dateien, welche die Daten über
die vorgenommenen Abzüge und das zu zahlende Gehalt enthalten. Diese Dateien
werden von anderen Programmen verarbeitet, sobald die einzelnen Beträge für alle
Mitarbeiter berechnet worden sind. Eine Gehaltsmitteilung für den Mitarbeiter, auf
dem die Nettozahlung und die vorgenommenen Abzüge verzeichnet sind, wird
vom System ausgedruckt.
Das Architekturmodell eines datenverarbeitenden Programms ist recht einfach. In sol-
chen Systemen steckt die Komplexität jedoch oftmals in den zu verarbeitenden Daten.
Der Entwurf der Systemarchitektur umfasst daher sowohl ein Nachdenken über die
Datenarchitektur (Bracket, 1994) als auch über die Programmarchitektur. Der Entwurf
der Datenarchitektur liegt allerdings außerhalb des Rahmens dieses Buchs.
13.2 Transaktionsverarbeitende Systeme

13.2 Transaktionsverarbeitende Systeme


Das Ziel transaktionsverarbeitender Systeme ist die Verarbeitung von Benutzeranfra-
gen nach Informationen aus einer Datenbank oder Anfragen zum Aktualisieren der
Datenbank (Lewis et a1., 2003). Technisch ist eine Datenbanktransaktion eine Abfolge
von Verarbeitungen, die als Einheit (atomare Einheit) angesehen wird. Alle Operatio-
nen einer Transaktion müssen abgeschlossen sein, bevor die Änderungen in der
Datenbank dauerhaft gemacht werden. Das bedeutet, dass Verarbeitungsfehler inner-
halb einer Transaktion nicht zu Inkonsistenzen in der Datenbank führen.
Ein Beispiel für eine Transaktion ist eine Kundenanfrage zum Geldabheben von
einem Bankkonto über einen Geldautomaten. Dazu gehört die Abfrage von Konto-
details, das Überprüfen des Saldos, das Ändern des Saldos um den abgehobenen
Betrag und das Senden von Befehlen an den Geldautomaten zur Ausgabe des Bar-
gelds. Solange diese Schritte nicht alle abgeschlossen sind, ist die Transaktion unvoll-
ständig und die Kundenkontendatenbank wird nicht verändert.
Aus der Sicht eines Benutzers ist eine Transaktion jede zusammenhängende Abfolge
von Prozessen, die ein Ziel erfüllen, wie z.B. "finde die Flugzeiten von London nach
Paris". Wenn die Benutzertransaktion keine Datenbankänderung erfordert, kann es
unnötig sein, sie als technische Datenbanktransaktion zu verpacken.
Transaktionsverarbeitende Systeme sind in der Regel interaktive Systeme, bei denen
Benutzer asynchrone Dienstanfragen tätigen. ~ Abbildung 13.3 veranschaulicht die
allgemeine Struktur der Architektur dieser Anwendungen. Zunächst führt ein Benut-
zer über eine EI A-verarbeitende Komponente eine Anfrage an das System durch, die
dann von einer anwendungsspezifischen Logik verarbeitet wird. Es wird eine Transak-
tion erstellt und an den Transaktionsmanager überreicht, der in der Regel im Daten-
bankmanagementsystem enthalten ist. Nachdem der Transaktionsmanager sicherge-
stellt hat, dass die Transaktion ordnungsgemäß beendet ist, meldet er der Anwendung,
dass die Verarbeitung abgeschlossen ist.

Abbildung 13.3: Die Struktur transaktionsverarbeitender Anwendungen

Die Eingabe-Verarbeitung-Ausgabe-Struktur, die wir in datenverarbeitenden Anwen-


dungen sehen, kann auch auf viele transaktionsverarbeitende Systeme angewendet
werden. Einige dieser Systeme sind interaktive Versionen stapelverarbeitender Sys-
teme. Früher nahmen Banken z.B. alle Eingaben zu Kundentransaktionen offline vor
und führten sie dann jeden Abend als Stapelverarbeitung auf ihrer Kontendatenbank
aus. Dieser Ansatz wurde größtenteils durch interaktive, transaktionsbasierte Systeme
ersetzt, die die Konten in Echtzeit aktualisieren.
Ein Beispiel für ein transaktionsverarbeitendes System ist ein Bankensystem, das den
Kunden ermöglicht, ihre Konten abzufragen und Geld von einern Geldautomaten abzu-
heben. Das System besteht aus zwei zusammenarbeitenden Software-Subsystemen - der
Geldautomatensoftware und der Kontoverarbeitungssoftware im Datenbankserver der
Bank. Die Ein- und Ausgabesubsysteme sind als Software im Geldautomaten implemen-
tiert, wohingegen sich das verarbeitende Subsystem im Datenbankserver befindet. ~ Ab-
bildung 13.4 zeigt die Architektur dieses Systems. Ich habe dem grundlegenden Eingabe-
Verarbeitung-Ausgabe-Diagramrn weitere Einzelheiten hinzugefügt, die bei den Eingabe-,

I 331
ANWENDUNGSARCHITEKTUREN

Verarbeitungs- und Ausgabetätigkeiten beteiligt sein können. Ich habe dabei bewusst
nicht festgelegt, wie diese internen Komponenten miteinander zusammenspielen, da die
Abfolge der Prozesse von einem Rechner zum anderen unterschiedlich sein kann.
Eingabe Verarbeitung Ausgabe

Geldautomat Datenbank Geldautomat


Abbildung 13.4: Die Softwarearchitektur eines Geldautomaten

In Systemen wie dem Kundenkontensystem der Bank kann es verschiedene Möglich-


keiten zur Interaktion geben. Viele Kunden greifen über Geldautomaten darauf zu,
aber Bankangestellte nutzen Schalterterminals für den Zugriff. Es kann mehrere Arten
von Geldautomaten und Schalterterminals geben, und einige Kunden und Mitarbeiter
könnten über Web-Browser auf die Kontodatenbank zugreifen.
Um die Verwaltung verschiedener Terminalkommunikationsprotokolle zu vereinfa-
chen, können groß dimensionierte transaktionsverwaltende Systeme eine Middleware
enthalten, die mit allen Arten von Terminals kommuniziert, die Daten von den Termi-
nals organisiert, serialisiert und zur Verarbeitung weiterschickt. Diese Middleware,
die ich in Kaptitel 12 kurz behandelt habe, kann Monitor für die Fernübertragung oder
Transaktionsverwaltungssystem genannt werden. eIes von IBM (Horswill and Miller,
2000) ist ein weit verbreitetes Beispiel für ein solches System.
~ Abbildung 13.5 zeigt eine andere Sicht auf die Architektur eines Kundenkontensys-
tems, das persönliche Kontotransaktionen von Geldautomaten und Schalterterminals in
einer Bank verarbeitet. Der Monitor für die Fernübertragung verarbeitet die Eingabe und
serialisiert Transaktionen, die er in Datenbankabfragen umwandelt. Diese Abfragen wer-
den im Datenbankmanagementsystem durchgeführt. Die Ergebnisse werden zurück an
den Monitor für die Fernübertragung übermittelt, der die Monitore verfolgt, die Abfra-
gen vornehmen. Das System bringt sie dann in eine Form, die von der Terminalsoftware
verarbeitet werden kann und übermittelt ihr die Ergebnisse der Transaktion.

Kontoabfr agen und


-aktualisierungen
Serialisierte

Geldautomaten und Terminals


Abbildung 13.5: Middleware für die Transaktionsverwaltung
13.2 Transaktionsverarbeitende Systeme

13.2.1 Informations- und ressourcenverwaltende Systeme


Alle Systeme, die mit einer gemeinsam genutzten Datenbank arbeiten, können als
transaktionsbasierte Informationssysteme betrachtet werden. Ein Informationssystem
ermöglicht einen kontrollierten Zugriff auf eine große Informationsbasis, wie z.B.
einen Bibliothekskatalog, einen Flugplan oder die Patientenakten in einem Kranken-
haus. Die Entwicklung des WWW führte dazu, dass eine Vielzahl von Informations-
systemen sich von spezialisierten Unternehmenssystemen zu allgemein zugänglichen
Allzwecksystemen wandelte.
~ Abbildung 13.6 ist ein sehr allgemeines Modell eines Informationssystems. Das Sys-
tem wird unter Verwendung eines Schichtenansatzes oder eines Ansatzes abstrakter
Automaten modelliert (siehe Abschnitt 11.2.3), bei dem die obere Schicht die Benutzer-
schnittstelle und die untere die Systemdatenbank darstellt. Die Benutzerkommunika-
tionsschicht verarbeitet die gesamte Ein- und Ausgabe der Benutzerschnittstelle, und
die Informationsabfrageschicht enthält eine anwendungsspezifische Logik für den
Zugriff und für Aktualisierungen der Datenbank. Wie wir später sehen werden, können
die Schichten dieses Modells direkt auf Server eines Internet-basierten Systems abgebil-
det werden.
Als Beispiel einer Realisierung dieses Schichtenmodells zeigt ~ Abbildung 13.7 die
Architektur des LIBSYS-Systems. Erinnern Sie sich daran, dass dieses System den
Benutzern einen Zugriff auf Dokumente in entfernten Bibliotheken und das Herunter-
laden dieser Dokumente zum Drucken ermöglicht. Ich habe jeder Schicht im Modell
Details hinzugefügt, indem ich die Komponenten identifiziert habe, die die Benutzer-
kommunikation sowie die Informationsanfrage und den Zugriff unterstützen. Sie soll-
ten auch beachten, dass die Datenbank eine verteilte Datenbank ist. Die Benutzer ver-
binden sich normalerweise über das System mit den Datenbanken von Bibliotheken,
die Dokumente zur Verfügung stellen.

Benutzerschnittstelle

Benutzerkommunikation

Abrufen und Ändern von Informationen

Transaktionsverwaltung
Datenbank
~==================~~~
I
Abbildung 13.6: Schichtenmodell eines Informationssystems

I 333
ANWENDUNGSARCHITEKTUREN

Webbrowserschnittstelle

LIBSYS- Formulare und Druck-


Anmeldung Abfragemanager m anager

Verteilte Dokument- Rechte-


Buchhaltung
Suche abruf manager

Bibliotheksindex

Abbildung 13.7: Die Architektur des L1BSYS-Systems

Die Benutzerkommunikationsschicht in ~ Abbildung 13.7 enthält drei Hauptkompo-


nenten:
D Die LIBSYS-Login-Komponente identifiziert und beglaubigt Benutzer. Alle Informa-
tionssysteme, die den Zugang auf eine Anzahl bekannter Benutzer beschränken, be-
nötigen eine Benutzerauthentifizierung als wesentlichen Bestandteil ihrer Benutzer-
kommunikationssysteme. Die Benutzerauthentifizierung kann persönlich sein, benö-
tigt in E-Commerce-Systemen jedoch möglicherweise auch Kreditkartenangaben.

o Die Komponente Formular- und Abjragemanager verwaltet die Formulare, die der
Benutzer zu sehen bekommen kann, und bietet Abfragemöglichkeiten, die ihm das
Anfordern von Informationen aus dem System ermöglichen. Wiederum müssen alle
Informationssysteme eine Komponente enthalten, die diese Funktionen zur Ver-
fügung stellt.
D Die Druckmanagerkomponente ist kennzeichnend für LIBSYS. Sie steuert den Aus-
druck von Dokumenten, deren Gebrauch aus Urheberrechtsgründen eingeschränkt
sein kann. Zum Beispiel wäre es möglich, dass einige Dokumente nur einmal auf den
Druckern der registrierten Bibliothek gedruckt werden dürfen.
Die Informationsabfrage- und Änderungsschichten im LIBSYS-System enthalten an-
wendungsspezifische Komponenten , die die Systemfunktionalität implementieren,
und zwar die folgenden:
• Verteilte Suche: Diese Komponente sucht als Antwort auf Benutzeranfragen in allen
Bibliotheken, die sich bei dem System registriert haben, nach Dokumenten. Die
Liste der bekannten Bibliotheken wird vom Bibliotheksindex verwaltet.
• Dokumentenabruf: Diese Komponente ruft das Dokument oder die Dokumente ab ,
die der Benutzer bei dem Server angefragt hat, auf dem das LIBSYS-System ausge-
führt wird.
• Rechtemanager Diese Komponente kümmert sich um alle Fragen der digitalen
Rechteverwaltung und des Urheberrechts. Es verfolgt, wer Dokumente angefordert
hat und stellt Z.B. sicher, dass niemand mehrere Anfragen nach demselben Doku-
ment vornehmen kann.
13.2 Transaktionsverarbeitende Systeme

• Abrechnung: Diese Komponente protokolliert alle Anfragen und verarbeitet alle


Gebühren, die die Bibliotheken des Systems erheben. Sie erstellt auch Manage-
mentberichte über die Auslastung des Systems.
Dieselbe allgemeine Vierschichtenarchitektur können wir in einem anderen Typ von
Informationssystem erkennen, nämlich in Systemen, die zur Unterstützung von Res-
sourcenzuweisungen entworfen wurden. Ressourcenzuordnungssysteme verwalten
einen festen Betrag einer gegebenen Ressource, wie z.B. Eintrittskarten für ein Konzert
oder ein Fußballspiel. Diese werden Benutzern zugewiesen, die diese Ressource von
dem Anbieter anfordern. Buchungssysteme für Eintrittskarten sind ein nahe liegendes
Beispiel für ein Ressourcenzuordnungssystem, doch eine Vielzahl auf den ersten Blick
verschiedenartiger Systeme stellen in Wirklichkeit auch Ressourcenzuordnungssys-
teme dar. Einige Beispiele für diese Klasse von Systemen sind:
• Timetabling-Systeme, die Klassen an freie Stellen in einem Zeitplan zuweisen. Die
hier zuzuweisende Ressource ist ein Zeitintervall, und es gibt in der Regel eine
Vielzahl von Beschränkungen für jede Nachfrage nach der Ressource.
• Bibliothekssysteme, die die Ausleihe und das Zurückbringen von Büchern oder
anderer Artikel verwalten. In diesem Fall stellen die ausleihbaren Gegenstände die
zuzuweisenden Ressourcen dar. Bei diesem Systemtyp werden die Ressourcen nicht
einfach zugewiesen, sondern müssen den Benutzern auch manchmal wieder weg-
genommen werden.
• Luftverkehrsmanagementsysteme, bei denen die zuzuweisende Ressource ein Seg-
ment eines Luftraums ist, so dass ein Abstand zwischen den vom System verwalteten
Flugzeugen gewahrt bleibt. Auch hier ist ein dynamisches Zuweisen und Wegneh-
men der Ressource erforderlich, die hier virtuell und nicht physisch ist.
Ressourcenzuweisungssysteme sind eine breit genutzte Anwendungsklasse. Wenn wir
uns das Architekturmodell genau anschauen, erkennen wir, wie es sich dem in
~ Abbildung 13.6 gezeigten Informationssystem anpasst. Die Komponenten eines (in
~ Abbildung 13.8 gezeigten) Ressourcenzuweisungssystems umfassen:

D eine Ressourcendatenbank, die Einzelheiten über die zuzuweisenden Ressourcen


enthält. Ressourcen können zur Datenbank hinzugefügt oder aus ihr entfernt wer-
den. In einem Bibliothekssystem enthält die Ressourcendatenbank z.B. Einzelheiten
zu allen Gegenständen, die ein Benutzer der Bibliothek ausleihen kann. Normal-
erweise wird diese Komponente unter Verwendung eines Datenbankmanage-
mentsystems implementiert, das ein System zur Transaktionsverarbeitung enthält.
Das Datenbankmanagementsystem enthält auch Funktionen zum Sperren von Res-
sourcen, so dass ein- und dieselbe Ressource nicht zweimal Benutzern zugewiesen
werden kann, die gleichzeitig Anfragen ausführen.
D ein R egel werk, das die Regeln für die Ressourcenzuweisung beschreibt. Ein
Bibliothekssystem beschränkt in der Regel den Kreis derjenigen, denen eine Res-
source zugewiesen werden kann (die registrierten Bibliotheksnutzer), die Dauer
für die ein Buch oder ein anderer Artikel ausgeliehen werden kann, die maximal
ausleihbare Anzahl Bücher usw. Diese Informationen sind in der Richtlinie für die
Ressourcensteuerung enthalten.

I 335
ANWENDUNGSARCHITEKTUREN

D eine Ressourcenverwaltungskomponente, die es dem Ressourcenanbieter ermög-


licht, Ressourcen zu bearbeiten, hinzuzufügen oder aus dem System zu löschen.

D eine Ressourcenzuweisungskomponente, die die Ressourcendatenbank aktuali-


siert, wenn Ressourcen zugewiesen werden, und diese Ressourcen mit den Ein-
zelheiten des Anfordernden verknüpft.

D ein Benutzerauthentifizierungsmodul, mit dessen Hilfe das System überprüfen


kann, dass Ressourcen einem angemeldeten Benutzer zugeordnet werden. Bei ei-
nem Bibliothekssystem kann das ein maschinenlesbarer Bibliotheksausweis sein,
in einem Eintrittskartenbuchungssystem eine Kreditkarte, mit der überprüft wer-
den kann, ob der Benutzer für die Ressource bezahlen kann.

D ein Abfrageverwaltungsmodul, mit dem die Benutzer feststellen können, welche


Ressourcen verfügbar sind. In einem Bibliothekssystem wäre das typischerweise
auf Abfragen nach bestimmten Artikeln gestützt, ein Eintrittskartenbuchungs-
system könnte eine grafische Anzeige enthalten, aus der ersichtlich ist, welche
Karten für ein bestimmtes Datum verfügbar sind.

D eine Ressourcenauslieferungskomponente, die die Ressourcen zur Auslieferung


an den Anfragenden vorbereitet. Bei einem Eintrittskartenbuchungssystem können
dazu die Vorbereitung einer E-Mail-Bestätigung und das Senden einer Anfrage an
einen Drucker gehören, um die Karten und Versand details auszudrucken.
D eine Benutzerschnittstellenkomponente (oftmals ein Web-Browser), die sich au-
ßerhalb des Systems befindet und dem Anfragenden das Eingeben von Abfragen
und Anforderungen für die zuzuweisende Ressource ermöglicht.

Benutzerschnittstelle

Benutzer- Ressourcen-
authentifizierung auslieferung

Ressourcen- Steuerung der Ressourcen-


I verwaltung Ressourcenrichtlinien zuweisung

Transaktionsverwaltung
Ressourcendatenbank
--
Abbildung 13.8: Schichtenmodell eines Ressourcenzuweisungssystems

Diese geschichtete Architektur kann auf mehrere Arten realisiert werden. Software von
Informationssystemen kann so aufgebaut werden, dass jede Schicht eine umfangreiche
Komponente ist, die auf einem gesonderten Server ausgeführt wird. Jede Schicht defi-
niert ihre externen Schnittstellen, über die sämtliche Kommunikation stattfindet. Wenn
alternativ das gesamte Informationssystem auf einem einzelnen Computer ausgeführt
wird, sind die mittleren Schichten in der Regel als einzelnes Programm implementiert,
13.3 Ereignisverarbeitende Systeme

das mit der Datenbank über seine API kommuniziert. Eine dritte Alternative besteht
darin, feinere Komponenten wie gesonderte Web-Dienste aufzusetzen (siehe Kapitel 12)
und diese dynamisch gemäß der Anfragen des Benutzers zu entwerfen.

I Webbmw", H Web,e,ve'
Anwendungs-
server
Datenbank-
server

Abbildung 13.9: Mehrschichtiges transaktionsverarbeitendes Internet-System

Heutzutage sind auf Internetprotokollen basierende Implementierungen von Informa-


tions- und Ressourcenverwaltungssysteme die Norm; die Benutzerschnittstelle bildet
ein Web-Browser. Die Anordnung der Server in diesen Systemen spiegelt das in
~ Abbildung 13.6 vorgestellte allgemeine Vierschichtenmodell wider. Die Systeme sind
normalerweise als vielschichtige Client/Server-Architekturen implementiert, wie in
Kapitel 12 erörtert. Der Systemaufbau ist in ~ Abbildung 13.9 gezeigt. Der Webserver ist
für die komplette Benutzerkommunikation, der Anwendungsserver sowohl für die Imp-
lementierung der anwendungsspezifischen Logik als auch für die Informationsspeiche-
rung und die Anfragen zuständig, und der Datenbankserver befördert die Informationen
in die und aus der Datenbank. Der Einsatz mehrerer Server ermöglicht einen hohen
Durchsatz und ermöglicht das Verarbeiten Hunderter Transaktionen pro Minute.
E-Commerce-Systeme sind Internet-basierte Ressourcenverwaltungssysteme, die dazu
entworfen sind, elektronische Bestellungen für Waren oder Dienstleistungen anzuneh-
men und dann dafür zu sorgen, diese an den Kunden auszuliefern. Heutzutage ist ein
weites Feld dieser Systeme im Einsatz, von Systemen, die Dienstleistungen wie Autover-
mietungen erledigen, bis hin zu Systemen, die die Bestellung materieller Artikel wie
Bücher oder Lebensmittel unterstützen. In einem E-Commerce-System enthält die
anwendungsspezifische Schicht eine zusätzliche Funktionalität, die einen "Einkaufs-
wagen" unterstützt, in den die Benutzer mehrere Gegenstände in getrennten Transaktio-
nen hineinlegen können, und dann alle zusammen in einer einzelnen Transaktion bezah-
len können.

13.3 Ereignisverarbeitende Systeme


Ereignisverarbeitende Systeme reagieren auf Ereignisse in der Systemumgebung oder
der Benutzerschnittstelle. Wie ich in Kapitel 11 dargelegt habe, besteht die wichtigste
Eigenschaft solcher Systeme darin, dass der Zeitpunkt von Events unbestimmt ist und
das System in der Lage sein muss, diese Ereignisse beim Auftreten zu bewältigen.
Wir alle nutzen solche ereignisbasierten Systeme auf unseren eigenen Rechnern:
Textverarbeitungsprogramme, Präsentationssysteme und Spiele werden alle von Ereig-
nissen der Benutzerschnittstelle gesteuert. Das System erkennt und interpretiert Ereig-
nisse. Ereignisse der Benutzerschnittstelle stellen implizite Befehle an das System dar,
das einen Vorgang ausführt, um den Befehl zu befolgen. Wenn Sie z.B. ein Textverar-
beitungsprogramm verwenden und einen Doppelklick auf ein Wort ausführen, bedeu-
tet das "wähle dieses Wort aus".
Echtzeitsysteme, die Handlungen in "Echtzeit" als Antwort auf einen externen
Anstoß ausführen, sind ebenfalls ereignisbasierte Systeme. In diesem Fall kommen
die Ereignisse jedoch in der Regel nicht von einer Benutzerschnittstelle, sondern sind
mit zum System gehörigen Sensoren oder Auslösern verbunden. Aufgrund der Not-
wendigkeit der unmittelbaren Antwort auf unvorhersehbare Ereignisse sind diese

I 337
ANWENDUNGSARCHITEKTUREN

Echtzeitsysteme normalerweise als eine Anzahl kooperierender Prozesse aufgebaut.


Ich behandle allgemeine Architekturen für Echtzeitsysteme in Kapitel 15.
In diesem Abschnitt konzentriere ich mich auf die allgemeine Architektur von Edi-
tiersystemen. Hierbei handelt es sich um Programme, die auf pes oder Workstations
ausgeführt werden, und dem Benutzer das Bearbeiten von z.B. Textdokumenten, Dia-
grammen oder Bildern ermöglichen. Einige Editoren beschränken sich auf die Bearbei-
tung eines einzigen Dokumenttyps, wie z.B. Bilder von einer Digitalkamera oder einem
Scanner. Andere, und hierzu zählen die meisten Textverarbeitungsprogramme, sind
Mehrfacheditoren und enthalten eine Unterstützung zum Bearbeiten verschiedener
Typen wie Text und Diagrammen. Sie können sich sogar eine Tabellenkalkulation als
Editiersystem vorstellen, bei dem sie die Felder der Tabelle editieren. Natürlich haben
Tabellenkalkulationen die zusätzliche Funktionalität, Berechnungen auszuführen.
Editiersysteme haben einige Eigenschaften, die sie von anderen Systemtypen unter-
scheiden und die ihren Architekturentwurf beeinflussen:
• Sie sind meistens Einbenutzersysteme. Sie müssen sich daher nicht mit den Prob-
lemen beschäftigen, die durch mehrfachen gleichzeitigen Zugriff auf Daten entstehen
und haben eine einfachere Datenverwaltung als transaktionsbasierte Systeme. Auch
dort, wo Daten gemeinsam genutzt werden, wird in der Regel keine Transaktionsver-
waltung verwendet, da Transaktionen eine lange Zeit benötigen und alternative Ver-
fahren zur Wahrung der Datenintegrität zum Einsatz kommen.
• Sie müssen auf Benutzeraktionen wie "Auswählen" oder "Löschen" schnell reagie-
ren. Das bedeutet, dass sie mit einer Datendarstellung arbeiten, die im Hauptspeicher
und nicht auf der Festplatte vorgehalten wird. Da sich die Daten im temporären Spei-
cher befinden, können sie bei einem Systemfehler verloren gehen, so dass Editiersys-
terne einige Vorkehrungen zur Wiederherstellung vornehmen sollten.
• Editiersitzungen dauern in der Regel wesentlich länger als ein Online-Wareneinkauf
oder das Durchführen einer anderen Transaktion. Das bedeutet wiederum, dass ein
größeres Risiko für den Datenverlust bei Problemen besteht. Daher enthalten viele
Editiersysteme Funktionen, die die aktuelle Arbeit automatisch sichern und sie im
Falle eines Systemfehlers für den Benutzer wieder herstellen.
~ Abbildung 13.10 zeigt eine allgemeine Architektur eines Editiersystems als Anzahl
wechselwirkender Objekte. Die Objekte im System sind aktiv statt passiv (siehe Kapi-
tel 14) und können gleichzeitig und autonom arbeiten. Im Wesentlichen werden Bild-
schirmereignisse verarbeitet und als Befehle interpretiert, was eine Datenstruktur
aktualisiert, die dann erneut auf dem Bildschirm angezeigt wird.
Die in ~ Abbildung 13.10 gezeigten Zuständigkeiten der Architekturkomponenten sind:
D Bildschirm: Dieses Objekt überwacht das Bildschirmspeichersegment und erkennt
auftretende Ereignisse. Diese Ereignisse werden dann zusammen mit ihren Bild-
schirmkoordinaten an das ereignisverarbeitende Objekt übergeben.
D Ereignis: Dieses Objekt wird durch ein von Bildschirm ankommendes Ereignis aus-
gelöst. Es verwendet das Wissen darüber, was angezeigt wird, zur Interpretation
dieses Ereignisses und um es in den entsprechenden Editierbefehl zu übersetzen,
der dann an das für die Befehlsinterpretation zuständige Objekt übergeben wird.
Bei vielen verbreiteten Ereignissen, wie z.B. Mausklicks oder Tastaturanschlägen,
kann das Ereignisobjekt direkt mit der Datenstruktur kommunizieren, was eine
schnellere Aktualisierung dieser Struktur ermöglicht.
13.3 Ereignisverarbeitende Systeme

Dateisystem I'
Speichern
Öffnen

Hilfsdaten Editordaten I]
1
Hilfsbefehle 11 - Bearbeitungs-
befehle
T-
11
- I

Befehl
Anzeige
Interpretieren
Aktualisieren
- -j- _.
- Ereignis
~

Verarbeiten
Bildschirm
-I
Aktualisieren

--
Abbildung 13.10: Architekturmodell eines Editiersystems

D Befehl: Dieses Objekt verarbeitet einen Befehl vom Ereignisobjekt und ruft die
entsprechende Methode im Editordatenobjekt auf, um den Befehl auszuführen.

11 Editordaten: Wenn die zugehörige Befehlsmethode im Editordatenobjekt aufgeru-


fen wird, aktualisiert sich die Datenstruktur und ruft die Methode Aktualisieren
in Anzeige auf, um die veränderten Daten anzuzeigen.
D HiIfsdaten: Editoren verwalten neben der eigentlichen Datenstruktur auch andere
Daten wie Formate oder Einstellungen. In diesem einfachen Architekturmodell habe
ich diesen Punkt unter Hilfsdaten zusammengefasst. Einige Editorbefehle, wie z.B.
der Befehl, eine Rechtschreibprüfung zu beginnen, sind durch eine Methode in die-
sem Objekt implementiert.

D Dateisystem: Dieses Objekt behandelt das Öffnen und Speichern von Dateien, die
entweder Editordaten oder Hilfsdaten enthalten. Um Datenverlust zu vermeiden,
haben viele Editoren Autospeicherfunktionen, die die Datenstruktur automatisch
speichern, so dass sie im Falle eines Systemfehlers wieder hergestellt werden kann.
o Anzeige: Dieses Objekt verfolgt den Aufbau der Bildschirmanzeige. Es ruft die
Methode Aktualisieren in Bildschirm auf, wenn sich die Anzeige geändert hat.

I 339
ANWENDUNGSARCHITEKTUREN

Da Editoren schnell auf Benutzerbefehle antworten müssen, haben sie keine zentrale
Steuereinheit, die die Komponenten aufruft. Stattdessen werden die kritischen Sys-
temkomponenten gleichzeitig ausgeführt und können direkt miteinander kommuni-
zieren (d.h. der Ereignisverarbeiter kann unmittelbaren Kontakt mit der Datenstruktur
aufnehmen), so dass eine schnellere Leistung erreicht wird.

13.4 Sprachverarbeitende Systeme


Sprachverarbeitende Systeme nehmen eine natürliche oder künstliche Sprache als
Eingabe entgegen und erzeugen als Ausgabe eine andere Darstellung dieser Sprache.
In der Softwareentwicklung sind die am häufigsten verwendeten Systeme Compiler,
die eine künstliche High-Level-Programmiersprache in Maschinencode übersetzen.
Andere sprachverarbeitende Systeme setzen eine in XML vorliegende Datenbeschrei-
bung in Befehle um, die eine Datenbank abfragen, und natürliche Sprachverarbei-
tungssysteme versuchen, eine natürliche Sprache in eine andere zu übersetzen.
~ Abbildung 13.11 zeigt die Architektur eines sprachverarbeitenden Systems auf der
abstraktesten Ebene. Die Anweisungen beschreiben, was zu tun ist, und werden vom
Übersetzer in ein internes Format überführt. Sie entsprechen den Maschinenanweisun-
gen für eine abstrakte Maschine. Diese Anweisungen werden dann von einer anderen
Komponente interpretiert, die sie ausführen und sie unter Verwendung von Umge-
bungsdaten ausführt, falls erforderlich. Die Ausgabe des Prozesses ist das Ergebnis der
Auswertung der Anweisungen auf den Eingabedaten. Bei vielen Compilern ist der Inter-
preter eine Hardwareeinheit, die Maschinenanweisungen ausführt, und die abstrakte
Maschine ist ein tatsächlicher Prozessor. Bei großen Systemen wie Java ist der Inter-
preter jedoch eine Softwarekomponente.
Sprachverarbeitende Systeme werden in Fällen eingesetzt, in denen der einfachste
Weg zur Problemlösung darin besteht, die Lösung als Algorithmus oder als Beschreibung
der Systemdaten anzugeben. Zum Beispiel sind Meta-CASE-Werkzeuge Programmgene-
ratoren, die für das Erstellen bestimmter CASE-Werkzeuge verwendet werden, um
Methoden des Software Engineering zu unterstützen. Meta-CASE-Werkzeuge enthalten
eine Beschreibung der Methodenkomponenten, ihren Regeln usw., geschrieben in einer
speziellen Sprache, die zur Konfiguration des erzeugten CASE-Werkzeugs geparst und
analysiert wird.

Übersetzer

Syntax prüfen
Semantik prüfen
Erstellen

Interpreter

H--~ Abrufen
Ausführen

Abbildung 13.11: Die abstrakte Architektur eines sprachverarbeitenden Systems


13.4 Sprachverarbeitende Systeme

Übersetzer in sprachverarbeitenden Systemen haben eine allgemeine Architektur


( ~ Abbildung 13.12), die die folgenden Komponenten enthält:

• ein lexikalisches Analyseprogramm, das die Zeichen der Eingangssprache in eine


interne Form konvertiert.
• eine Symboltabelle, welche Informationen über die im zu übersetzenden Text benutz-
ten Namen von Entitäten (Variablen, Klassennamen, Objektnamen usw.) enthält.
• ein Modul zur Syntaxanalyse, das die Syntax der zu übersetzenden Sprache prüft. Es
benutzt eine definierte Grammatik dieser Sprache und erstellt einen Syntaxbaum.
• einen Syntaxbaum, der die interne Struktur des zu kompilierenden Programms
repräsentiert.
• ein Modell zur Semantikanalyse, das die Informationen des Syntaxbaums und der
Symboltabelle zur Prüfung des Eingangtexts auf semantische Korrektheit benutzt.
• einen Codegenerator, der auf dem Syntaxbaum "entlang wandert" und zunächst
abstrakten Maschinencode erzeugt.
Zusätzlich können andere Komponenten eingefügt werden, die den Syntaxbaum
umformen, um die Effektivität zu verbessern und Redundanzen aus dem erzeugten
Maschinencode zu entfernen. In anderen Arten sprachverarbeitender System, wie z.B.
Übersetzungsprogrammen für natürliche Sprache, ist der erstellte Code tatsächlich der
in eine andere Sprache übersetzte Eingabetext.
Die Komponenten, aus denen ein sprachverarbeitendes System besteht, können nach
unterschiedlichen Architekturmodellen angeordnet werden. Wie von Garlan und Shaw
(Garlan and Shaw, 1993) festgestellt wurde, können Compiler anhand eines Komponen-
tenmodells implementiert werden. Eine Datenflussarchitektur kann benutzt werden, bei
der die Symboltabelle als Speicher für gemeinsam genutzte Daten dient. Wie in ~ Abbil-
dung 13.12 dargestellt, erfolgen die Phasen für lexikalische, Syntax- und Semantik-
analyse nacheinander.

Abbildung 13.12: Datenflussmodell eines Compilers

Dieses Datenflussmodell der Kompilierung wird noch immer vielfach angewendet. Es


ist sehr effektiv in Umgebungen, in denen Daten stapelweise verarbeitet und Programme
ohne Eingriff von Benutzern kompiliert und ausgeführt werden. Weniger effektiv ist es,
wenn der Compiler mit anderen sprachverarbeitenden Werkzeugen wie beispielsweise
einem strukturierten Editor, einem interaktiven Debugger, einem Prettyprinter usw. inte-
griert werden muss. In diesem Fall können die allgemeinen Systemkomponenten in
einem speicherbasierten Modell nach ~ Abbildung 13.13 angeordnet werden.
Die ~ Abbildung verdeutlicht, wie ein sprachverarbeitendes System Bestandteil einer
integrierten Menge von Programmierunterstützungswerkzeugen sein kann. In diesem Bei-
spiel dienen die Symboltabelle und der Syntaxbaum als zentraler Informationsspeicher,

I 341
ANWENDUNGSARCHITEKTUREN

der von Werkzeugen oder Werkzeugteilen für die Kommunikation genutzt wird. Andere
Informationen, die manchmal in Werkzeugen eingebettet ist, wie zum Beispiel die Defini-
tion der Grammatik und das Ausgabeformat für das Programm wurden aus den Werk-
zeugen entfernt und im Speicher abgelegt. Daher kann ein syntaxgerichteter Editor bei der
Eingabe überprüfen, ob die Syntax eines Programms korrekt ist, und ein Prettyprinter
kann den Programmcode in einem einfach zu lesenden Format ausgeben.

( Editor r

Repository

Abbildung 13.13: Die abstrakte Architektur eines sprachverarbeitenden Systems

Zusammenfassung
• Allgemeine Modelle von Anwendungssystemen helfen dabei, die Funktion von Anwendungen
zu verstehen, Anwendungen desselben Typs zu vergleichen, Systementwürfe für Anwendungen
zu vergleichen und die Wiederverwendbarkeit umfangreicher Komponenten einzuschätzen.
• Viele Anwendungen fallen entweder in eine der genannten Klassen allgemeiner Anwendungen
oder sind Kombinationen daraus. Die vier hier behandelten Arten von allgemeinen Anwendun-
gen sind daten-, transaktions-, ereignis- und sprachverarbeitende Systeme.
• Datenverarbeitende Systeme arbeiten im Stapelmodus und haben im Allgemeinen eine Ein-
gabe-Verarbeitung-Ausgabe-Struktur. Es werden Datensätze in das System eingegeben, die
Information wird verarbeitet und Ausgaben werden erzeugt.
• Transaktionsverarbeitende Systeme sind interaktive Systeme, die den entfernten Zugriff auf
Informationen in einer Datenbank und ihre Veränderung durch eine Anzahl von Benutzern
ermöglichen. Informations- und Ressourcenverwaltungssysteme sind Beispiele für transaktions-
verarbeitende Systeme.
• Zu ereignisverarbeitenden Systemen zählen Editier- und Echtzeitsysteme. In einem Editiersystem
werden Ereignisse der Benutzerschnittstelle ausgewertet und eine vorgehaltene Datenstruktur
verändert. Textverarbeitungs- und Präsentationsprogramme sind Beispiele für Editiersysteme.
• Sprachverarbeitende Systeme werden zur Übersetzung von Text aus einer Sprache in eine andere
verwendet und führen die in der Eingabesprache enthaltenenen Anweisungen aus. Sie enthalten
einen Übersetzer und einen abstrakten Automaten, der die erzeugte Sprache ausführt.
Ergänzende Literatur

Ergänzende Literatur
Das Thema der Anwendungsarchitekturen wurde weitgehend vernachlässigt; Autoren
von Büchern und Artikeln über Softwarearchitekturen neigen dazu, sich auf abstrakte
Prinzipien oder Produktlinienarchitekturen zu konzentrieren.
Databases and Transaction Processing: An Application-oriented Approach. Das ist
eigentlich kein Buch über Software architektur, es erörtert aber die Grundlagen trans-
aktionsverarbeitender und datenbezogener Anwendungen. (P. M. Lewis et al., 2003,
Addison-Wesley.)
Design and Use oi Software Architectures. Dieses Buch verfolgt den Produktlinien-
ansatz für Softwarearchitekturen und behandelt die Architektur daher aus einer
Anwendungsperspektive. (]. Bosch, 2000, Addison-Wesley.)

Übungen Kapitel 13
l1li Erläutern Sie, wie die hier beschriebenen Anwendungsarchitekturen dem
Benutzer bei Entscheidungen über die Wiederverwendbarkeit von Soft-
ware helfen können.

IID Klassifizieren Sie unter Verwendung der vier in diesem Kapitel eingeführ-
ten grundlegenden Anwendungstypen die folgenden Systeme und erläu-
tern Sie Ihre Klassifizierung:
- ein Kassensystem in einem Supermarkt
- ein System, das Zahlungsermahnungen über zu zahlende Zeitschrif-
tenabonnementsgebühren versendet.
- ein Fotoalbum, das Funktionen zur Wiederherstellung alter Fotografien
bietet.
- ein System, das sehbehinderten Benutzern Web-Seiten vorliest
- ein interaktives Spiel, in dem Figuren sich bewegen, Hindernisse über-
winden und Schätze sammeln
- ein Bestandsaufnahmesystem, das verfolgt, welche Waren auf Lager
sind, und automatisch Bestellungen für neue Ware ausgibt, wenn der
Vorrat unter einen bestimmten Wert fällt.

UD Erweitern Sie basierend auf einem Eingabe-Verarbeitung-Ausgabe-Modell


die Funktion Gehalt berechnen aus ~ Abbildung 13.2 und zeichnen Sie
ein Datenflussdiagramm, das die in dieser Funktion ausgeführten Berech-
nungen anzeigt. Dafür brauchen Sie folgende Informationen:
- Der Angestelltendatensatz gibt den Dienstrang eines Angestellten an.
Diese Rangstufe wird dann in der Gehaltstabelle nachgeschlagen.
- Bis zu einer gewissen Stufe bekommen die Mitarbeiter möglicherweise
Überstunden in der Höhe ihres normalen Stundenlohns bezahlt. Die
Überstunden, die bezahlt werden müssen, sind in ihrem Mitarbeiter-
datensatz angegeben.

I 343
ANWENDUNGSARCHITEKTUREN

- Die abgezogenen Steuern hängen von der (im Datensatz angegebenen)


Steuerklasse des Mitarbeiters und seinem Jahresgehalt ab. Monatliche
Abzüge für die einzelnen Steuerklassen sind in den Steuertabellen
angegeben. Diese steigen oder sinken in Abhängigkeit vom Bruttogehalt
(Steuerprogression) .

l1li Erläutern Sie, warum in Systemen, bei denen Benutzereingaben zu Daten-


bankänderungen führen können, eine Transaktionsverwaltung erforder-
lich ist.
IID Zeigen Sie unter Verwendung des in ~ Abbildung 13.6 gezeigten Basis-
modells die Komponenten einen Informationssystems, das den Benutzern
die Anzeige der Abflug- und Ankunftszeiten eines bestimmten Flughafens
ermöglicht.
UD Zeigen Sie unter Verwendung der in ~ Abbildung 13.8 gezeigten Schicht-
architektur die Komponenten eines Ressourcenverwaltungssystems, das
für Hotelzimmerbuchungen verwendet werden könnte.

liD Bei einem Editiersystem können alle Ereignisse der Benutzerschnittstelle in


implizite oder explizite Befehle übersetzt werden. Erläutern Sie, warum das
Ereignisobjekt in ~ Abbildung 13.10 daher direkt mit der Editordatenstruk-
tur sowie dem Befehlsobjekt kommuniziert.
IID Verändern Sie ~ Abbildung 13.10, so dass es die allgemeine Architektur ei-
nes Tabellenkalkulationssystems zeigt. Gründen Sie Ihren Entwurf auf die
Eigenschaften irgendeiner Tabellenkalkulation, mit der Sie gearbeitet haben.

l1li Was ist die Funktion der Syntaxbaumkomponente in einem sprachver-


arbeitenden System?
lIIIll Entwerfen Sie unter Verwendung des hier vorgestellten allgemeinen Mo-
dells eines sprachverarbeitenden Systems die Architektur eines Systems,
das Befehle in natürlicher Sprache entgegennimmt und diese zur Erstel-
lung von Datenbankabfragen in eine Sprache wie SQL übersetzt.

Lösungen für ausgewählte Übungen dieses Kapitels finden Sie unter www.pearson-
studium.de auf der Companion Website zum Buch.
Objektorientierter Entwurf

14.1 Objekte und Objektklassen . ........... . .. . ...... 348


14.1.1 Nebenläufige Objekte. . . . . . . . . . . . . . . . . . . . . . . . .. 351

14.2 Ablauf eines objektorientierten Entwurfs . . . . . .. 352


14.2. 1 Systemkontext und Verwendungsmodelle . . . . . . . .. 355
14.2.2 Entwurf der Architektur. . . . . . . . . . . . . . . . . . . . . .. 357
14 .2.3 Bestimmung der Objekte. . . . . . . . . . . . . . . . . . . . . .. 358
14 .2 .4 Entwurfsmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 360
14.2.5 Spezifikation der Objektschnittstelle . . . . . . . . . . . .. 365

14.3 Weiterentwicklung des Entwurfs . . . . . . . . . . . . . . .. 366

Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 367

Ergänzende Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . .. 368

Übungen . ....................................... 368


OBJEKTORIENTIERTER ENTWURF

Lernziele Das Lernziel dieses Kapitels besteht darin, ein Verfahren für den Softwareent-
wurf einzuführen, bei dem der Entwurf in Form von zusammenspielenden Objekten struktu-
riert ist. Wenn Sie dieses Kapitel gelesen haben, werden Sie
• verstehen, wie der Softwareentwurf als Menge von interagierenden Objekten dargestellt
werden kann, die ihren eigenen Zustand und ihre Handlungen verwalten
• die wichtigsten Aktivitäten eines allgemeinen objektorientierten Entwurfsprozesses ken-
nen
• die verschiedene Modelle verstehen, die verwendet werden, um einen objektorientierten
Entwurf zu dokumentieren
• mit der Darstellung dieser Modelle mit Hilfe der Unified Modeling Language (UML) ver-
traut sein

Ein objektorientiertes System besteht aus zusammenspielenden Objekten, die ihren


eigenen lokalen Zustand verwalten und Operationen für diesen Zustand zur Verfügung
stellen (~ Abbildung 14.1). Die Darstellung dieses Zustands ist privat und von außer-
halb des Objekts ist kein direkter Zugriff auf ihn möglich. Ein objektorientierter Ent-
wurf beinhaltet den Entwurf der Objektklassen und der Beziehungen zwischen ihnen.
Diese Klassen definieren die Objekte des Systems und ihre Wechselwirkungen. Wenn
der Entwurf in ein Programm umgesetzt wird, werden die erforderlichen Objekte dyna-
misch mit Hilfe der Klassendefinitionen erzeugt.
Der objektorientierte Entwurf ist Teil der objektorientierten Entwicklung, bei der
während des Entwicklungsprozesses eine objektorientierte Strategie verwendet wird:
• Die objektorientierte Analyse beschäftigt sich mit der Entwicklung eines objektori-
entierten Modells des Problembereichs der Anwendung. Die Objekte in diesem
Modell stellen Entitäten und Vorgänge dar, die mit dem zu lösenden Problem zu
tun haben.
• Der objektorientierte Entwurf befasst sich mit der Entwicklung eines objektorientier-
ten Modells eines Softwaresystems, um die festgelegten Anforderungen zu implemen-
tieren. Die Objekte in einem objektorientierten Entwurf stehen in Zusammenhang mit
der Lösung des Problems. Obwohl enge Beziehungen zwischen Problembereichs- und
Lösungsobjekten bestehen können, muss der Designer unvermeidlich neue Objekte
hinzufügen und Problembereichsobjekte umformen, um die Lösung zu implemen-
tieren.
• Die objektorientierte Programmierung beschäftigt sich mit der Umsetzung eines
Softwareentwurfs unter Verwendung einer objektorientierten Programmiersprache
wie z.B. Java. Eine objektorientierte Programmiersprache stellt Konstrukte für die
Definition von Objektklassen zur Verfügung, sowie ein Laufzeitsystem, um aus die-
sen Klassen Objekte zu erstellen.
Der Übergang zwischen diesen Entwicklungsstufen sollte idealerweise nahtlos sein.
Auf jeder Stufe sollte dieselbe Notation verwendet werden. Um eine zusätzliche
Funktionalität zu bieten, schließt der Schritt zur nächsten Stufe die Verfeinerung der
vorhergehenden Stufe ein, indem Details zu bestehenden Objektklassen hinzugefügt
und neue Klassen gebildet werden. Da die Information innerhalb von Objekten verbor-
gen ist, können detaillierte Entwurfsentscheidungen zur Darstellung von Daten bis zur

346
1
Implementierung des Systems aufgeschoben werden. In einigen Fällen gilt dies auch
für Entscheidungen über die Verteilung von Objekten sowie darüber, ob Objekte
sequenziell oder nebenläufig sein können.
Das bedeutet, dass Software designer Entwürfe definieren können, die sich an andere
Ausführungsumgebungen anpassen lassen. Das wird durch den Ansatz der modellge-
steuerten Architektur (MDA-Ansatz, Model Driven Architecture) veranschaulicht, der
vorschlägt, dass Systeme explizit auf zwei Ebenen entworfen werden sollten (Kleppe et
al., 2003), einer implementierungsunabhängigen und einer -abhängigen. Ein abstraktes
Systemmodell wird auf der implementierungsunabhängigen Ebene entworfen, und das
wird auf ein detaillierteres plattformabhängiges Modell abgebildet, das als Basis für die
Quelleodeerstellung verwendet werden kann. Momentan ist der MDA-Ansatz noch
experimentell, und es ist nicht klar, wie weit er angenommen wird.
Objektorientierte Systeme sind einfacher zu ändern als mit anderen Ansätzen entwi-
ckelte, da die Objekte unabhängig sind. Sie können als alleinstehende Entitäten ange-
sehen und verändert werden. Die Veränderung der Objektimplementierung sowie das
Hinzufügen von Diensten sollten andere Systemobjekte nicht beeinflussen. Da Objekte
Dingen entsprechen, gibt es oft eine deutliche Zuordnung zwischen Entitäten der rea-
len Welt (wie Hardwarekomponenten) und deren Steuerobjekten im System. Dies ver-
bessert die Verständlichkeit und damit die Wartbarkeit des Entwurfs.

01: Cl 03:C3 04:C4 1


Zustand 01
,I Zustand 03 0( Zustand 04 I

r
Op10 I Op30 Op4 () 1
" -

02:C3
1 06:Cl o5:C5
11 I.
Zustand 02 11 Zustand 06 Zustand 05 !I
Op5 ()
Op30
- li Opl0
--
!I

Abbildung 14.1: Ein System aus wechselwirkenden Objekten

Objekte sind potenziell wiederverwendbare Komponenten, weil sie unabhängige Kapse-


lungen von Zustand und Operationen darstellen. Entwürfe können unter Verwendung
von Objekten entwickelt werden, die in früheren Entwürfen erstellt wurden. Damit wer-
den die Kosten für Entwurf, Programmierung und Validierung gesenkt. Dies kann außer-
dem zur Verwendung von Standardobjekten führen (und damit zu einem verständliche-
ren Entwurf) und reduziert die Risiken bei der Softwareentwicklung. Manchmal jedoch
ist die Wiederverwendung mit Hilfe einer Objektsammlung (Komponenten oder Anwen-
dungsrahmen) besser zu implementieren als unter Verwendung einzelner Objekte (wie in
Kapitel 18 und 19 dargestellt).
Mittlerweile sind mehrere objektorientierte Entwurfsmethoden vorgeschlagen wor-
den (Coad und Yourdon, 1990; Jacobson et al., 1993; Graham, 1994; Booch, 1994). Die
UML ist eine Vereinheitlichung der in diesen Methoden verwendeten Notationen. Der
Rational Unified Process (RUP), den ich in Kapitel 4 erläutert habe, wurde zur Ausnut-
zung der Modelle entwickelt, die in der UML ausgedrückt werden können (Rumbaugh
et al., 1999). Ich verwende die UML im gesamten Kapitel.
Wie ich in Kapitel 17 darlegen werde, kann eine auf extensivem Up-Front-Entwurf
basierende Systementwicklung kritisiert werden, weil die umfangreiche Analyse und die
Entwurfsbemühungen für inkrementelle Entwicklung und Auslieferung nicht geeignet

I 347
OBJEKTORIENTIERTER ENTWURF

sind. Um dieses Problem anzugehen, wurden sogenannte agile Methoden entwickelt,


und sie verringern die objektorientierte Entwurfstätigkeit erheblich oder beseitigen sie
vollständig. Meine Meinung ist, dass ein extensiver, "schwergewichtiger" Entwurf für
kleine oder mittlere kommerzielle Systeme unnötig ist. Für große, insbesondere kritische
Systeme, ist es jedoch unentbehrlich sicherzustellen, dass die Arbeitsgruppen, die an
verschiedenen Teilen des Systems arbeiten, ordentlich organisiert sind. Aus diesem
Grund verwende ich in diesem Kapitel nicht die vorausgehenden Beispiele des Biblio-
theks- oder Insulindosiersystems, da es sich bei ihnen um relativ kleine Systeme handelt.
Statt dessen verwende ich ein Beispiel, das Bestandteil eines wesentlich größeren Sys-
tems ist, bei dem ein objektorientierter Up-Front-Entwurf nützlicher ist.
Diese Ansicht spiegelt sich zu einem gewissen Grad im Rational Unified Process
wider, der auf die iterative Entwicklung und die inkrementellen Auslieferung großer
Softwaresysteme abgestimmt ist. Dieser Prozess ist ein auf Anwendungsfällen basieren-
der iterativer Entwicklungsprozess. Er drückt Anforderungen und objektorientierten
Entwurf aus, mit einem besonderen Schwerpunkt auf architekturbezogenen Entwurf.
Der Entwurfsprozess, den ich in Abschnitt 14.2 behandle, hat einige Dinge mit dem
RUF gemeinsam, jedoch mit einer geringeren Betonung auf anwendungsfallgesteuer-
ter Entwicklung. Die Verwendung von Anwendungsfällen bedeutet, dass der Entwurf
sicherlich benutzerzentriert ist und auf Interaktionen des Benutzers mit dem System
basiert. Das Darstellen der Anforderungen von Prozessbeteiligten, die keine direkten
Benutzer des Systems sind, als Anwendungsfälle ist jedoch schwierig. Anwendungs-
fälle spielen in objektorientierter Analyse und Entwurf sicherlich eine Rolle, aber sie
müssen um andere Techniken ergänzt werden, um indirekte und nichtfunktionale
Systemanforderungen zu erkennen.

14.1 Objekte und Objektklassen


Die Begriffe Objekt und objektorientiert werden auf verschiedene Entitätstypen, Ent-
wurfsmethoden, Systeme und Programmiersprachen angewandt. Es besteht eine allge-
meine Übereinstimmung darin, dass ein Objekt eine Kapselung von Informationen ist.
Dies spiegelt sich auch in meinen Definitionen eines Objekts und einer Objektklasse
wider:
Ein Objekt ist eine Entität. Es besitzt einen Zustand sowie eine definierte Menge
von Handlungsmöglichkeiten (Operationen), die auf diesem Zustand aufset-
zen. Der Zustand wird als Menge von Objektattributen dargestellt. Die Operati-
onen dieses Objekts bieten anderen Objekten (Clients) ihre Dienste an, um z. B.
Berechnungen auszuführen.
Objekte werden gemäß der Definition einer Objektklasse erzeugt. Eine solche
Klassendefinition ist sowohl eine Typspezifikation als auch eine Vorlage für die
Erstellung von Objekten und beinhaltet Deklarationen aller Attribute und Ope-
rationen, die einem Objekt dieser Klasse zugeordnet werden sollten .
In der UML wird eine Objektklasse als benanntes Rechteck mit zwei Abschnitten dar-
gestellt. Die Objektattribute werden im oberen und die dem Objekt zugeordneten Ope-
rationen im unteren Abschnitt dargestellt. ~ Abbildung 14 .2 verdeutlicht diese Nota-
tion am Beispiel einer Objektklasse, die einen Mitarbeiter einer Firma darstellt. In der
UML dient der Begriff Operation zur Spezifikation einer Aktion. Der Begriff Methode
wird verwendet, um auf die Implementierung dieser Operation zu verweisen.
14.1 Objekte und Objektklassen

Die Klasse Mitarbeiter definiert eine Anzahl von Attributen, die Informationen über
Mitarbeiter enthalten, einschließlich ihres Namens, ihrer Adresse, der Sozialversiche-
rungsnummer, der Steuerklasse usw. Die drei Punkte (. .. ) weisen darauf hin, dass es
weitere Attribute der Klasse gibt, die hier jedoch nicht aufgeführt sind. Dem Objekt
zugeordnete Operationen sind ei nstell en (wird aufgerufen, wenn der Mitarbeiter in
die Firma eintritt), ausscheiden (wenn der Mitarbeiter die Firma verlässt), i nRente-
Gehen (wenn der Mitarbeiter in Ruhestand geht) und ei genschaftenÄndern (wenn die
Mitarbeiterinformation geändert werden muss).
Objekte kommunizieren, indem sie Dienste von anderen Objekten anfordern (deren
Methoden aufrufen) und, falls notwendig, für die Bereitstellung des Dienstes benö-
tigte Informationen austauschen. Die Kopien der Informationen, die benötigt werden,
um den Dienst auszuführen, sowie die Ergebnisse der Dienstausführung werden als
Parameter übergeben. Beispiele für diese Kommunikationsart sind:

Mitarbeiter

Name: String
Adresse: String
Geburtsdatum: Date
PersonalNr: integer
SozVersNr: integer
Abteilung: Abteilung
Vorges etzter: Mitarbeiter
Gehalt: integer
Status : (aktiv, ausgeschieden, inRente l
Steuerklasse : integer
."

einstellen 0
ausscheidenO
inRenteGeh enO
eigenschaftenÄndern()

Abbildung 14.2: Ein Mitarbeiterobjekt

11 Aufru f ein er Met hode, die ei nem Pu ffero bjekt zugeord net
11 i st und den näc hste n Wert i m Pu ffe r zurückg i bt
v = circularBu f f er.Ge t () ;
11 Auf ruf ein er Met hod e , di e ei nem Th ermos ta tob j ek t zuge or dn et
11 ist und die So ll temperatur au f ei nen ge wün sc hten Wert se t zt
t hermos t at . setTemp (2 0) ;

In dienstbasierten Systemen wird die Kommunikation zwischen Objekten direkt in


Form von XML-Textnachrichten implementiert, die von Objekten ausgetauscht werden.
Das empfangende Objekt liest die Nachricht, identifiziert den Dienst und die zugeord-
neten Daten und führt den angeforderten Dienst aus. Wenn Objekte im selben Programm
vorkommen, werden Methodenaufrufe wie Prozedur- oder Funktionsaufrufe in einer
Sprache wie C implementiert.
Wenn Dienstanforderungen auf diese Art und Weise implementiert werden, erfolgt
die Kommunikation zwischen den Objekten synchron. Das aufrufende Objekt wartet
auf den Abschluss der Dienstanforderung. Wenn Objekte jedoch als nebenläufige Pro-
zesse oder Threads implementiert werden, kann die Objektkommunikation auch asyn-
chron erfolgen, d. h. das aufrufende Objekt kann seine Arbeit fortsetzen, während der
angeforderte Dienst ausgeführt wird. Später in diesem Abschnitt werde ich erläutern,
wie Objekte als nebenläufige Prozesse implementiert werden können.

I 349
OBJEKTORIENTIERTER ENTWURF

Wie bereits in Kapitel 8 erörtert, in dem ich eine Anzahl möglicher Objektmodelle
beschrieben habe, können Objektklassen in einer Verallgemeinerungs- oder Vererbungs-
hierarchie angeordnet werden, die die Beziehung zwischen allgemeinen und spezielle-
ren Objektklassen verdeutlicht. Die speziellere Objektklasse stimmt mit der allgemeinen
überein, enthält aber zusätzliche Informationen. In der UML wird die Verallgemeine-
rung durch einen Pfeil angedeutet, der auf die übergeordnete Klasse zeigt. In objektori-
entierten Programmiersprachen wird die Verallgemeinerung für gewöhnlich durch die
Verwendung des Vererbungsmechanismus implementiert. Die untergeordnete Klasse
erbt Attribute und Vorgänge von der übergeordneten Klasse.

I Mitarbeiter
I
~
I I
Manager Programmierer

verwalteteBudgets projekt
ernennungsDatum programmiersprachen

y
I I I
Projekt- Abteilungs- Strategie-
Manager leiter Manager
projekte abteilung verantwortungs-
bereiche

Abbildung 14.3: Eine Verallgemeinerungshierarchie

~ Abbildung 14.3 zeigt ein Beispiel einer solchen Hierarchie. Darin sind verschiedene
Mitarbeiterklassen zu sehen. Klassen am unteren Ende der Hierarchie besitzen diesel-
ben Attribute und Vorgänge wie ihre übergeordneten Klassen, können aber neue Attri-
bute und Vorgänge hinzufügen oder Attribute und Vorgänge ihrer übergeordneten
Klasse ändern. Es besteht also eine einseitige Austauschbarkeit. Wenn der Name einer
übergeordneten Klasse in einem Modell verwendet wird, bedeutet das, dass das
Objekt im System entweder als Exemplar dieser Klasse oder als Exemplar einer ihrer
Abkömmlinge definiert werden kann
Die Klasse Manager in ~ Abbildung 14.3 verfügt über alle Attribute und Vorgänge der
Klasse Mitarbeiter, besitzt zusätzlich aber zwei neue Attribute, die die vom Manager
kontrollierten Budgets sowie den Zeitpunkt speichern, an dem der Manager seinem
Aufgabengebiet zugeordnet wurde. Entsprechend fügt die Klasse Programmi erer neue
Attribute hinzu, die das Projekt, an dem der Programmierer arbeitet, sowie seine Fer-
tigkeiten im Gebrauch der Programmiersprachen definieren. Objekte der Klassen
Manager oder Programmi erer können überall da verwendet werden, wo ein Objekt der
Klasse Mi ta rbei ter erforderlich ist.
Objekte, die einer Objektklasse angehören, stehen in Beziehung zu anderen Objek-
ten. Diese Beziehungen werden durch eine Beschreibung der so genannten Assoziatio-
nen zwischen den Objektklassen modelliert. In der UML werden Assoziationen durch
einen Strich zwischen Objektklassen gekennzeichnet. Dieser kann wahlweise mit
14.1 Objekte und Objektklassen

Anmerkungen versehen werden, die Informationen über die Assoziation enthalten.


Dies wird in ~ Abbildung 14.4 veranschaulicht, in der die Assoziation zwischen
Objekten der Klasse Mi ta rbei ter und der Klasse Abtei 1 ung sowie zwischen Objekten
der Klasse Mitarbeiter und der Klasse Manag er zu sehen ist.
Eine Assoziation ist eine sehr allgemeine Beziehung und wird in der UML häufig
verwendet, um entweder anzuzeigen, dass ein Objektattribut ein assoziiertes Objekt ist
oder dass die Implementierung einer Objektmethode vom assoziierten Objekt abhängt.
Zumindest im Prinzip ist jede Art der Assoziation möglich. Eine der gebräuchlichsten
Assoziationen ist die Aggregation. Sie veranschaulicht, wie sich Objekte aus anderen
Objekten zusammensetzen können. Eine Erläuterung dieser Assoziationsart finden Sie
in Kapitel 8.

Mitarbeiter
I Abteilung
Iist-Angehöriger-der
- --
wird -geleitet-d urch

leitet
Manager

'!
Abbildung 14.4: Ein Assoziationsmodell

14.1.1 Nebenläufige Objekte


Begrifflich betrachtet fordert ein Objekt einen Dienst von einem anderen Objekt an,
indem es eine Nachricht, genannt "Dienstanfrage" , an dieses Objekt sendet. Eine seri-
elle Ausführung, bei der ein Objekt auf die Beendigung eines angeforderten Dienstes
wartet, ist nicht erforderlich. Folglich erlaubt das allgemeine Modell der Objektinter-
aktion Objekten, nebenläufig als parallele Prozesse ausgeführt zu werden. Diese Objekte
können auf demselben Computer oder als verteilte Objekte auf verschiedenen Compu-
tern ausgeführt werden.
In der Praxis orientieren sich die meisten objektorientierten Programmiersprachen
standardmäßig an einem seriellen Ausführungsmodell, bei dem die Anforderungen
von Objektdiensten wie Funktionsaufrufe implementiert sind. Wenn ein Objekt, ge-
nannt t heLi st, aus einer normalen Objektklasse erzeugt wird, schreibt man zum Bei-
spiel in Java:
t heLis t. append ( 17)

Dieser Befehl ruft die Methode app end des Objekts theL i st auf, um das Element 17 zu
theL i st hinzuzufügen. Die Ausführung des aufrufenden Objekts wird so lange unterbro-
chen, bis der Hinzufügevorgang beendet ist. Java enthält einen sehr einfachen Mechanis-
mus (Threads), der es ermöglicht, Objekte zu erzeugen, die nebenläufig ausgeführt wer-
den. Threads werden in Java durch Verwendung der integrierten Klasse Thre ad als
übergeordnete Klasse in der Klassendeklaration erzeugt. Threads müssen eine Methode
namens run enthalten. Diese wird durch das Laufzeitsystem von Java gestartet, wenn
Objekte, die als Threads definiert sind, erzeugt werden. Daher ist es einfach, sich einen
objektorientierten Entwurf vorzunehmen und eine Implementierung zu erstellen, bei der
die Objekte nebenläufige Prozesse sind.

I 351
OBJEKTORIENTIERTER ENTWURF

Es gibt zwei Arten der nebenläufigen Objektimplementierung:

o Server, bei denen das Objekt als paralleler Prozess mit Methoden umgesetzt wird,
die den definierten Objektoperationen entsprechen. Methoden werden als Ant-
wort auf eine externe Nachricht gestartet und können parallel zu Methoden aus-
geführt werden, die anderen Objekten zugeordnet sind. Wenn die Ausführung
der Methoden beendet ist, geht das Objekt in den Ruhezustand und wartet auf
weitere Dienstanfragen.

o Aktive Objekte, bei denen der Objektzustand durch interne Vorgänge, die inner-
halb des Objekts selbst ausgeführt werden, geändert werden kann. Der Prozess,
der das Objekt darstellt, führt diese Vorgänge ständig aus, so dass er nie in einen
Wartezustand übergeht.
Server sind vor allem in einer verteilten Umgebung von Nutzen, in der das aufrufende
und das aufgerufene Objekt auf verschiedenen Computern ausgeführt werden. Die
Antwortzeit für den angeforderten Dienst kann nicht vorausgesagt werden, so dass Sie
das System nach Möglichkeit so entwerfen sollten, dass das Objekt, das einen Dienst
angefordert hat, nicht auf die Beendigung dieses Dienstes wartet. Server können auch
auf einem einzelnen Computer verwendet werden, auf dem die Beendigung eines
Dienstes einige Zeit in Anspruch nimmt (z. B. beim Drucken eines Dokuments) und
der Dienst von verschiedenen Objekten angefordert werden kann.
Aktive Objekte werden verwendet, wenn ein Objekt in bestimmten Intervallen sei-
nen eigenen Zustand aktualisieren muss. Das ist in Echtzeitsystemen üblich, in denen
Objekte Hardwaregeräten zugeordnet sind, die Informationen über die Systemumge-
bung erfassen. Die Objektmethoden gestatten anderen Objekten den Zugriff auf die
Zustandsinformation.
~ Abbildung 14.5 verdeutlicht, wie ein aktives Objekt in Java definiert und implemen-
tiert werden kann. Die Objektklasse stellt einen Transponder in einem Flugzeug dar. Der
Transponder hält sich mit Hilfe eines Satellitennavigationssystems über die Position des
Flugzeugs auf dem Laufenden. Er kann auf Meldungen von Flugsicherungscomputern
antworten und stellt die aktuelle Flugzeugposition als Antwort eines Aufrufs der
Methode gi vePositi on zur Verfügung. Dieses Objekt ist als Thread implementiert. Eine
Endlosschleife in der Methode run beinhaltet den Code, um die Position des Flugzeugs
mit Hilfe von Satellitensignalen zu berechnen.

14.2 Ablauf eines objektorientierten Entwurfs


In diesem Abschnitt veranschauliche ich den Ablauf eines objektorientierten Entwurfs
durch die Entwicklung eines Beispiels für Steuerungssoftware, die in einer automati-
sierten Wetterstation zum Einsatz kommt. Wie ich bereits in der Einleitung erörtert
habe, gibt es mehrere objektorientierte Entwurfsmethoden, jedoch keine "beste"
Methode und keinen "besten" Entwurfsablauf. Der Ablauf, den ich hier behandle, ist
ein allgemeiner Ablauf, der Aktivitäten einschließt, die bei den meisten objektorien-
tierten Entwurfsmethoden üblich sind.
Der allgemeine Ablauf, den ich hier für den objektorientierten Entwurf verwende,
besteht aus mehreren Phasen:
14.2 Ablauf eines objektorientierten Entwurfs

• Verstehen und Definieren des Kontextes und der Verwendungsmodelle für das System
• Entwurf der Systemarchitektur
• Bestimmung der wichtigsten Objekte im System
• Entwicklung von Entwurfsmodellen
• Spezifizieren von Objektschnittstellen

cla ss Tr ans ponder ex t end s Thre ad {

Po s ition cur ren t Po si t ion


Coord s cl c2 ;
Sa tell i te sa tl . sat2 ;
Navigator t heNavigato r

publi c Po sition giv ePos i t ion ()


{
re t urn

publi c void r un ( )
(
whil e Ctrue )
f
cl = satl. po si t ion ( ) ;
c2 = sat 2.po s i t i on () ;
cur ren t Posi tion = theNavi gat or .compu t e (c l . c2)

l i /T ra nsponder
Abbildung 14.5: Implementierung eines aktiven Objekts mit Hilfe von Java-Threads

Ich habe diese Phasen absichtlich nicht als einfaches Ablaufdiagramm dargestellt, da
dies implizieren würde, das in diesem Ablauf eine klar definierte Reihenfolge der Aktivi-
täten besteht. Tatsächlich können jedoch alle oben genannten Aktivitäten als sich über-
schneidende Aktivitäten angesehen werden, die sich gegenseitig beeinflussen. Nach dem
Definieren der Systemarchitektur können Objekte bestimmt und Schnittstellen ganz oder
teilweise spezifiziert werden. Wenn Objektmodelle erzeugt worden sind, können die ein-
zelnen Objektdefinitionen verfeinert werden, was wiederum zu Änderungen an der Sys-
temarchitektur führt.
Ich werde dieses Vorgehen als separate Phase des Entwurfsablaufs später in diesem
Abschnitt erörtern. Sie sollten jedoch nicht annehmen, dass der Entwurf ein einfacher,
gut strukturierter Prozess ist. In Wirklichkeit entwickeln Sie einen Entwurf, indem Sie
Lösungen vorschlagen und diese Lösungen verfeinern, sobald Informationen erhältlich
sind. Sie müssen unvermeidlich denselben Weg zurückgehen und einen neuen Ver-
such starten, wenn Probleme auftreten. Manchmal gehen Sie schon sehr früh ins
Detail, um zu sehen, ob Ihre Lösungsansätze funktionieren, bei anderen Gelegenheiten
befassen Sie sich hingegen erst sehr spät mit den Einzelheiten.
Ich verdeutliche diese Aktivitäten, indem ich ein Beispiel eines objektorientierten
Entwurfs entwickle. Das Beispiel, das ich verwende, ist Teil eines Systems für die
Erzeugung von Wetterkarten mit Hilfe automatisch erfasster meteorologischer Daten.

I 353
OBJEKTORIENTIERTER ENTWURF

Die detaillierten Anforderungen an ein solches Wetterberichtssystem würden viele Sei-


ten in Anspruch nehmen. Jedoch kann aus einer relativ kurzen Systembeschreibung
eine Architektur des Gesamtsystems entwickelt werden:

Datendarstellungsschicht, in der
Objekte die Vorbereitung und Dar-
stellung der Daten in einer für den
Menschen lesbaren Form übernehmen

Datenarchivierungsschicht, in der
Objekte Daten für die zukünftige
Verarbeitung speichern

Datenverarbeitungsschicht, in der
Objekte die erfassten Daten über-
prüfen und integrieren

Datenerfassungsschicht, in der
Objekte Daten von entfernten
Quellen beziehen

Abbildung 14.6: Schichtenarchitektur für ein Wetterberichtssystem

Ein Wetterberichtssystem dient der regelmäßigen Erzeugung von Wetterkarten


mit Hilfe von Daten, die von entfernten, unbeaufsichtigten Wetterstationen und
anderen Datenquellen wie Wetterbeobachtern, Ballons und Satelliten erfasst
werden. Die Wetterstationen übertragen ihre Daten als Antwort auf die Anfrage
eines Bereichscomputers an diesen Rechner.
Der Bereichscomputer prüft die erfassten Daten auf Gültigkeit und integriert
Daten aus verschiedenen Quellen. Die integrierten Daten werden archiviert,
und mit Hilfe der Archivdaten und einer digitalisierten Karten datenbank wird
ein Satz lokaler Wetterkarten erstellt. Die Karten können für den Vertrieb auf
einem speziellen Kartendrucker gedruckt oder in einer Vielzahl verschiedener
Formate angezeigt werden.
Die Beschreibung verdeutlicht, dass sich ein Teil des Gesamtsystems mit der Erfas-
sung von Daten, ein Teil mit der Zusammenführung von Daten verschiedener Quellen,
ein Teil mit der Archivierung dieser Daten und ein Teil mit der Erstellung von Wetter-
karten beschäftigt. ~ Abbildung 14.6 veranschaulicht eine mögliche Systemarchitek-
tur, die aus dieser Beschreibung abgeleitet werden kann. Es handelt sich dabei um
eine Schichtenarchitektur (erörtert in Kapitel 11), die die Ablaufphasen im System,
das heißt Datenerfassung, Datenintegration, Datenarchivierung und Kartenerstellung,
darstellt. Eine Schichtenarchitektur ist in diesem Fall angebracht, weil die Ausfüh-
rung jeder Stufe auf der Verarbeitung der vorhergehenden Stufe aufbaut.
In ~ Abbildung 14.6 habe ich die verschiedenen Schichten gezeigt und den Schich-
tennamen in ein Symbol für ein UML-Paket (package) aufgenommen, das als Subsys-
tem gekennzeichnet wird. Ein UML-Paket stellt eine Sammlung von Objektklassen
und anderen Paketen dar. Ich habe es hier verwendet, um zu zeigen, dass jede Schicht
eine Anzahl anderer Komponenten beinhaltet.
14.2 Ablauf eines objektorientierten Entw urfs

Abbildung 14.7: Subsysteme des Wetterberichtssystems

In ~ Abbildung 14.7 habe ich dieses abstrakte Architekturmodell weiter ausgeführt,


indem ich die Komponenten der Subsysteme eingezeichnet habe. Diese sind immer noch
abstrakt und wurden aus den Informationen der Systembeschreibung abgeleitet. Ich setze
das Entwurfsbeispiel fort, indem ich mich auf das Subsystem für die Wetterstation kon-
zentriere, das Teil der Datenerfassungsschicht ist.

14.2.1 System kontext und Verwendungsmodelle


Die erste Stufe jedes Softwareentwurfsprozesses besteht darin, sich die Beziehungen
zwischen der entworfenen Software und der Umwelt klarzumachen. Die Entwicklung
dieses Verständnisses unterstützt Sie in der Entscheidung, wie die erforderliche Funk-
tionalität des Systems gewährleistet und das System strukturiert werden muss , damit
es mit seiner Umwelt kommunizieren kann.
Der Systemkontext und das Verwendungs- bzw. Applikationsmodell eines Systems
stellen zwei sich ergänzende Modelle für die Beziehungen zwischen einem System
und seiner Umwelt dar:

O Der Systemkontext ist ein statisches Modell, das die anderen Systeme in dieser
Umgebung beschreibt.
o Das Verwendungsmodell eines Systems ist ein dynamisches Modell, das be-
schreibt, wie das System tatsächlich mit seiner Umwelt zusammenspielt.
Das Kontextmodell eines Systems kann mit Hilfe von Assoziationen dargestellt werden
(siehe ~ Abbildung 14.4). Dabei wird im Prinzip lediglich ein einfaches Blockdiagramm
der gesamten Systemarchitektur erzeugt. Dieses kann durch die Darstellung eines Sub-
systemmodells mit Hilfe von UML-Paketen erweitert werden (siehe ~ Abbildung 14 .7),
die verdeutlicht, dass der Kontext des Systems der Wetterstation innerhalb eines Sub-
systems, das sich mit der Datenerfassung beschäftigt, enthalten ist. Außerdem sind
andere Subsysteme zu sehen, die gemeinsam das Wetterberichtssystem bilden.

I 355
OBJEKTORIENTIERTER ENTWURF

Abbildung 14.8: Anwendungsfälle der Wetterstation

Wenn Sie das Zusammenspiel eines Systems mit seiner Umwelt nachbilden, sollten Sie
ein abstraktes Verfahren verwenden, das nicht zu sehr ins Detail geht. Der RUP schlägt
vor, hierfür ein Modell der Anwendungsfälle zu entwickeln, in dem jeder Anwendungs-
fall eine Interaktion mit dem System darstellt. In Anwendungsfallmodellen (die auch in
Kapitel 7 erläutert wurden) wird jede mögliche Interaktion in einer Ellipse aufgeführt.
Die daran beteiligte externe Entität wird durch ein Strichmännchen dargestellt. Im Fall
der Wetterstation ist die externe Entität kein Mensch, sondern das Datenverarbeitungs-
system für die Wetterdaten.
Das Anwendungsfallmodell für die Wetterstation ist in ~ Abbildung 14.8 zu sehen.
Diese Darstellung veranschaulicht, dass die Wetterstation beim Starten und Herunter-
fahren, bei der Meldung der erfassten Wetterdaten sowie beim Kalibrieren und Testen
der Messgeräte mit externen Entitäten zusammenspielt.
Jeder dieser Anwendungsfälle kann in einer strukturierten natürlichen Sprache
beschrieben werden. Dies erleichtert es Entwicklern, Objekte im System zu bestimmen,
und sagt ihnen, was das System tun soll. Ich verwende eine stilisierte Beschreibungs-
form, die eindeutig bestimmt, welche Information ausgetauscht wird, wie das Zusam-
menspiel initiiert wird usw. In ~ Abbildung 14.9 wird dies veranschaulicht. Darin wird
der Anwendungsfall Beri cht aus ~ Abbildung 14.8 beschrieben.
Die Beschreibung des Anwendungsfalls trägt zur Bestimmung von Objekten und
Vorgängen im System bei. Aus der Beschreibung des Anwendungsfalls Beri cht geht
hervor, dass Objekte zur Erfassung von Wetterdaten (Messgeräte) sowie ein Objekt für
die Zusammenfassung der Wetterdaten erforderlich sind. Außerdem werden Vorgänge
benötigt, die Wetterdaten anfordern und senden.

System Wetterstation
Anwen- Bericht
dungsfall
Aktoren Erfassungssystem für Wetterdaten, Wetterstation
Daten Die Wetterstation sendet eine Zusammenfassung der Wetterdaten, die mit Hilfe von Mess-
geräten in der Erfassungsperiode zusammengetragen wurden, an das Erfassungssystem für
die Wetterdaten. Die gesendeten Daten umfassen Höchst-, Tiefst- und Durchschnittswerte für
die Temperatur des Bodens und der Luft sowie des Luftdrucks und der Windgeschwindigkeit,
ferner Gesamtniederschlag und die Windrichtung. Sie werden alle fünf Minuten abgefragt.

Abbildung 14.9: Beschreibung des Anwendungsfalls "Bericht"


14.2 Ablauf eines objektorientierten Entwurfs

System Wetterstation
Auslöser Das Erfassungssystem für Wetterdaten erstellt eine Modemverbindung und fordert die Über-
tragung der Daten an.
Antwort Die zusammengefassten Daten werden an das Erfassungssystem für Wetterdaten gesendet.
Kommen- Wetterstationen werden normalerweise stündlich um Meldung gebeten, aber die Häufigkeit
tare kann von Station zu Station variieren und zukünftig geändert werden .

Abbildung 14.9: Beschreibung des Anwendungsfalls "Bericht" (Forts.)

14.2.2 Entwurf der Architektur


Sobald das Zusammenspiel zwischen dem zu entwerfenden Softwaresystem und der
Systemumgebung definiert ist, können Sie diese Informationen als Grundlage für den
Entwurf der Systemarchitektur verwenden. Natürlich müssen Sie diese Informationen
mit Ihren allgemeinen Kenntnissen über die Prinzipien des Architekturentwurfs sowie
detailliertem Wissen bezüglich des Problembereichs verbinden.
Die automatisierte Wetterstation ist ein relativ einfaches System. Ihre Architektur
kann ebenfalls als Schichtenmodell dargestellt werden. Ich habe dies in ~ Abbildung
14.10 in Form von drei UML-Paketen innerhalb des allgemeineren Pakets Wetterstation
verdeutlicht. Beachten Sie, wie ich UML-Anmerkungen bzw. -Annotationen verwendet
habe (Text in Rechtecken mit geknickter Ecke), um zusätzliche Informationen darzu-
stellen.
Die drei Schichten in der Software für die Wetter station sind:

o die Schnittstellenschicht, welche die Kommunikation mit anderen Systemkom-


ponenten und die Versorgung externer Systemschnittstellen zur Aufgabe hat

D die Datenerfassungsschicht, welche die Erfassung der Daten durch Messgeräte


verwaltet und die Wetterdaten vor der Übertragung an das Berichtssystem zusam-
menfasst
D die Messgeräteschicht, bei der es sich um eine Kapselung aller Messgeräte handelt,
die verwendet werden, um Rohdaten über die Wetterbedingungen zu erfassen

Wetterstation
I
11
»Subsystem « I V.,waltet . ~
Schnittstelle Kommunikation
I nach außen

11
»Subsystem « I Sammelt ~~
Daten erfassung I Wetterdaten und
fasst diese zusammen

11
»Subsystem « I Messge'ätepaket:~
Messgeräte für die Erfassung
I von Rohdaten

Abbildung 14.10: Die Architektur der Wetterstation

I 357
OBJEKTORIENTIERTER ENTWURF

Im Allgemeinen sollten Sie versuchen, ein System so weit wie möglich zu zerlegen,
damit die Architektur so einfach wie möglich wird. Eine gute Faustregel besagt, dass
nicht mehr als sieben grundlegende Entitäten in ein Architekturmodell aufgenommen
werden sollten. Jede dieser Entitäten kann getrennt beschrieben werden, aber natür-
lich können Sie auch die Struktur der Entitäten aufzeigen, so wie ich es in ~ Abbil-
dung 14.7 getan habe.

14.2.3 Bestimmung der Objekte


Auf dieser Stufe des Entwurfsprozesses sollten Sie schon einige Ideen zu wesentli-
chen Objekten des im Entwurf befindlichen Systems haben. Im System der Wettersta-
tion wird deutlich, dass die Messgeräte Objekte sein sollten und Sie auf jeder Archi-
tekturebene zumindest ein Objekt benötigen. Dies spiegelt ein allgemeines Prinzip
wider. Objekte neigen dazu, während des Entwurfsprozesses zu entstehen. Jedoch
müssen Sie normalerweise auch nach anderen Objekten, die relevant sein könnten,
schauen und diese dokumentieren.
Obwohl ich diesen Abschnitt "Bestimmung der Objekte" genannt habe, hat dieser
Prozess in der Praxis mit der Bestimmung von Objektklassen zu tun. Der Entwurf wird
in Form dieser Klassen beschrieben. Sie müssen auf jeden Fall die Objektklassen, die
Sie anfangs bestimmt haben, verfeinern und diese Stufe des Prozesses erneut betreten,
wenn Sie ein besseres Verständnis für den Entwurf entwickeln.
Es gibt verschiedene Ansätze, wie Objektklassen bestimmt werden können:
• Verwenden Sie eine grammatikalische Analyse für eine Systembeschreibung in einer
natürlichen Sprache. Objekte und Attribute sind Substantive, Vorgänge und Dienste
Verben (Abbot, 1983). Dieses Verfahren ist in der HOOD-Methode für den objektori-
entierten Entwurf (Robinson, 1992) enthalten, die in der europäischen Raumfahrt-
industrie weit verbreitet war.
• Verwenden Sie greifbare Entitäten (Dinge) aus dem Problembereich, wie zum Bei-
spiel Flugzeuge, Rollen wie die des Managers, Ereignisse wie Anfragen, Interaktio-
nen wie Besprechungen, Standorte wie einzelne Büros, Organisationseinheiten wie
beispielsweise Firmen, usw. (Shlaer und Mellor, 1988; Coad and Yourdon, 1990;
Wirfs-Brock et a1., 1990). Unterstützen Sie dies durch die Bestimmung von Spei-
cherstrukturen (abstrakter Datenstrukturen) in der Lösungsdomäne, die zur Unter-
stützung dieser Objekte erforderlich sein können.
• Verwenden Sie einen Verhaltensansatz, bei dem der Entwickler zuerst das gesamte
Systemverhalten versteht. Unterschiedliches Verhalten wird verschiedenen System-
teilen zugeordnet. Das Verständnis darüber, wer dieses Verhalten auslöst und sich
daran beteiligt, wird daraus abgeleitet. Teilnehmer, die bedeutsame Rollen überneh-
men, werden als Objekte betrachtet (Rubin und Goldberg, 1992).
• Führen Sie eine Szenarioanalyse durch, in der mehrere Szenarien für die Systemnut-
zung der Reihe nach bestimmt und analysiert werden. Wenn jedes Szenario analy-
siert worden ist, muss die für die Analyse verantwortliche Gruppe die erforderlichen
Objekte, Attribute und Vorgänge bestimmen. Die Analysemethode der so genannten
CRC-Karten, bei der Analysten und Entwickler die Rollen von Objekten aufgreifen,
ist als Unterstützung dieses szenariobasierten Ansatzes sehr effektiv (Beck und
Cunningham, 1989).
14.2 Ablauf eines objektorientierten Entwurfs

Diese Ansätze helfen Ihnen bei der Bestimmung der Objekte. In der Praxis müssen Sie
vermutlich verschiedene Wissensquellen für die Entdeckung von Objekten und Objekt-
klassen verwenden. Objekte und Objektklassen, die zuerst durch die informelle System-
beschreibung bestimmt werden, können den Ausgangspunkt für den Entwurf darstel-
len. Weitere Informationen aus dem Wissen über den Problembereich der Anwendung
oder der Szenarioanalyse können daraufhin genutzt werden, um die Anfangsobjekte zu
verfeinern und zu erweitern. Diese Informationen können aus Anforderungsdokumen-
ten, aus Diskussionen mit Benutzern und aus der Analyse bestehender Systeme gewon-
nen werden.
Ich habe hier ein gemischtes Verfahren zur Bestimmung der Objekte der Wettersta-
tion verwendet. Es würde den Rahmen sprengen, alle Objekte zu beschreiben, aber in
~ Abbildung 14.11 zeige ich Ihnen fünf Objektklassen. BodenThermometer, Wi ndmesser
und Ba rometer stellen Objekte des Problembereichs der Anwendung dar. Die Objekt-
klassen WetterStati on und WetterDaten sind durch die System- und die Szenario-
beschreibung (Anwendungsfall) bestimmt worden.
Diese Objekte beziehen sich auf die unterschiedlichen Ebenen der Systemarchitek-
tur.
o Die Objektklasse WetterStati on stellt die grundlegende Schnittstelle der Wetter-
station zu ihrer Umwelt zur Verfügung. Ihre Operationen spiegeln daher die in
~ Abbildung 14.8 gezeigten Interaktionen wider. In diesem Fall verwende ich
eine einzelne Objektklasse, um all diese Interaktionen zu kapseln. In anderen
Entwürfen kann es durchaus angebrachter sein, mehrere Klassen zu verwenden,
um die Systemschnittstelle bereitzustellen.

o Die Objektklasse WetterDaten kapseIt die zusammengefassten Daten von den


verschiedenen Messgeräten in der Wetterstation. Die ihr zugeordneten Vorgänge
betreffen die Erfassung und Zusammenfassung der benötigten Daten.

D Die Objektklassen BodenThermometer, Wi ndmes s er und Ba rometer beziehen sich


direkt auf Messgeräte im System. Sie spiegeln greifbare Hardware-Entitäten im
System wider. Die Operationen befassen sich mit der Steuerung der Hardware.

WetterStation WetterDaten

Bezeichner luftTemperaturen
bodenTemperaturen
wetterBerichten ()
windGeschwindigkeiten
kalibrieren (messgeräte)
windRichtungen
testen ()
drücke
hochfahren (messgeräte)
niederschlag
herunterfahren (messgeräte)
erfassen ()
zusammenfassen ()

Boden- Windmesser Bar ometer


thermom eter druck
windGeschwindigkeit
temperatur windRichtung höhe
testen () testen ()
testen ()
kalibrieren () kalibrieren ()

Abbildung 14.11: Beispiele für Objektklassen im Wetterstationssystem

I 359
OBJEKTORIENTIERTER ENTWURF

Auf dieser Stufe des Entwurfsprozesses nutzen Sie Wissen über den Problembereich der
Anwendung zur Bestimmung weiterer Objekte und Dienste. Wir wissen, dass sich Wet-
terstationen oft an entfernten Orten befinden. Sie schließen verschiedene Messgeräte ein,
die manchmal kaputtgehen. Das Versagen von Messgeräten sollte automatisch gemeldet
werden. Dies hat zur Folge, dass Sie Attribute und Vorgänge zur Überprüfung der ein-
wandfreien Funktionsweise benötigen. Es gibt offensichtlich viele entfernte Wetterstatio-
nen. Sie müssen die von jeder Station erfassten Daten bestimmen, so dass jede Wetter-
station ihren eigenen Bezeichner haben sollte.
In diesem Beispiel habe ich mich dazu entschieden, die die einzelnen Messgeräte
darstellenden Objekte nicht zu aktiven Objekten zu machen. Die Operation e r f ass en
der Objektklasse WetterDaten fordert Messgeräteobjekte bedarfsorientiert zu einem
Lesevorgang auf. Aktive Objekte steuern sich selbst. In diesem Fall bedeutet das, dass
jedes Messgerät entscheiden würde, wann es den Lesevorgang ausführt. Der Nachteil
dieses Ansatzes besteht darin, dass neue Objektklassen eingeführt werden müssten,
wenn eine Entscheidung getroffen wird, das Timing der Datenerfassung zu ändern,
oder wenn verschiedene Wetterstationen Daten unterschiedlich erfasst haben. Wenn
die Messgeräteobjekte Lesevorgänge auf Anfrage starten, können alle Änderungen der
Erfassungsstrategie einfach implementiert werden, ohne die mit den Messgeräten ver-
bundenen Objekte zu verändern.

14.2.4 Entwurfsmodelle
Entwurfsmodelle zeigen Objektklassen in einem System sowie ggf. verschiedene Bezie-
hungsarten zwischen diesen Entitäten. Sie sind im Wesentlichen der Entwurf. Sie
schlagen die Brücke zwischen den Systemanforderungen und der Systemimplemen-
tierung. Das bedeutet, dass widersprüchliche Anforderungen an diese Modelle beste-
hen. Sie müssen abstrakt sein, damit unnötige Details nicht die Beziehungen zwischen
ihnen und den Systemanforderungen verbergen. Andererseits müssen sie ausreichend
Details enthalten, damit Programmierer Entscheidungen zur Implementierung treffen
können.
Im Allgemeinen umgehen Sie dieses Problem, indem Sie Modelle auf verschiede-
nen Detailebenen entwickeln. Wenn enge Verbindungen zwischen den Anforderungs-
analytikern, Entwicklern und Programmierern bestehen, sind allein abstrakte Modelle
erforderlich. Spezifische Entscheidungen zum Entwurf können dann bei der Imple-
mentierung des Systems getroffen werden. Wenn die Beziehungen zwischen den für
die Spezifikation zuständigen Personen, den für den Entwurf Verantwortlichen und
den Programmierern eher indirekt sind (zum Beispiel, wenn der Entwurf eines Sys-
tems in einem Bereich des Unternehmens stattfindet, die Implementierung jedoch in
einem anderen), sind detailliertere Modelle erforderlich.
Ein wichtiger Schritt im Entwurfsprozess ist daher die Entscheidung, welche Ent-
wurfsmodelle benötigt werden und wie ausführlich diese sein müssen. Dies hängt
vom zu entwickelnden Systemtyp ab. Ein sequenzielles Datenverarbeitungssystem
wird auf andere Art als ein eingebettetes Echtzeitsystem entworfen, so dass verschie-
dene Entwurfsmodelle benötigt werden. Es gibt sehr wenige Systeme, bei denen alle
Modelle notwendig sind. Die Minimierung der Anzahl der zu erstellenden Modelle
senkt die Entwurfskosten sowie die für den Abschluss des Entwurfsprozesses benö-
tigte Zeit.
14.2 Ablauf eines objektorientierten Entwurfs

Es gibt zwei Arten von Entwurfsmodellen, die normalerweise erstellt werden sollten,
um einen objektorientierten Entwurf zu beschreiben.
• Statische Modelle beschreiben die statische Systemstruktur in Form von Objektklas-
sen und ihrer Beziehungen. Wichtige Beziehungen, die auf dieser Stufe dokumentiert
werden können, sind Verallgemeinerungs-, Verwendet/Wird-verwendet-von- sowie
Kompositionsbeziehungen.
• Dynamische Modelle beschreiben die dynamische Systemstruktur und zeigen das
Zusammenspiel zwischen den Systemobjekten (nicht den Objektklassen). Interak-
tionen, die dokumentiert werden können, sind zum Beispiel die Abfolge von Dienst-
anfragen durch Objekte sowie die Art, wie der Systemzustand mit diesen Objekt-
interaktionen in Verbindung steht.
Die UML stellt zwölf verschiedene statische und dynamische Modelle zur Verfügung, die
aufgestellt werden können, um einen Entwurf zu dokumentieren. Ich habe in diesem
Buch nicht die Möglichkeit, jedes dieser Diagramme zu erläutern. Außerdem sind nicht
alle für das Beispiel der Wetterstation geeignet. Ich erläutere in diesem Abschnitt die
folgenden Modelle:
• Subsystemmodelle, die logische Objektgruppierungen in zusammenhängenden Sub-
systemen zeigen und mit Hilfe eines Klassendiagramms dargestellt werden. Jedes
Subsystem wird als Paket dargestellt. Subsystemmodelle gehören zu den statischen
Modellen.
• Abfolgemodelle, die den Ablauf von Objektinteraktionen zeigen. Sie werden mit Hilfe
eines UML-Sequenzdiagramms oder eines Kooperationsdiagramms dargestellt. Abfol-
gemodelle gehören zu den dynamischen Modellen.
• Zustandsmodelle, die zeigen, wie einzelne Objekte ihren Zustand als Reaktion auf
Ereignisse ändern. Sie werden in der UML mit Hilfe von Zustandsdiagrammen dar-
gestellt. Zustandsmodelle gehören zu den dynamischen Modellen.

»Subsystem « »Subsystem «
Schnittstelle Datenerfassung

»Subsystem«
Messgeräte

Barometer

Abbildung 14.12: Pakete der Wetterstation

I 361
OBJEKTORIENTIERTER ENTWURF

Ich habe bereits andere Modellarten erörtert, die für den objektorientierten Entwurf und
die Analyse entwickelt werden können. Anwendungsfallmodelle zeigen das Zusammen-
spiel mit dem System ( ~ Abbildung 14.8 sowie die ~ Abbildungen 7.6 und 7.7 aus Kapi-
tel 7), Objektmodelle beschreiben Objektklassen ( ~ Abbildung 14.2), Verallgemeine-
rungs- oder Vererbungsmodelle ( ~ Abbildungen 8.10, 8.11 und 8.12, Kapitel 8) zeigen,
wie Klassen Verallgemeinerungen anderer Klassen sein können, und Aggregationsmo-
delle ( ~ Abbildung 8.13) veranschaulichen, wie Objektsammlungen zusammenhängen.
~ Abbildung 14.12 zeigt die Objekte in den Subsystemen der Wetterstation. Außer-
dem stelle ich in diesem Modell einige Assoziationen dar. Das Objekt Komm St eue run g
steht beispielsweise mit dem Objekt Wette rS tati on in Verbindung und das Objekt
WetterStati on mit dem Paket Dat enerf ass ung. Das heißt, dass dieses Objekt mit
einem oder mehreren Objekten in diesem Paket assoziiert wird. Ein Paket- und ein
Objektklassenmodell können also in Kombination verwendet werden, um die logi-
schen Gruppierungen im System zu beschreiben.
Ein Subsystemmodell ist ein nützliches statisches Modell, da es angibt, wie der Ent-
wurf in logisch verknüpfte Objektgruppen aufgebaut werden kann. Ich habe diesen
Modelltyp bereits in ~ Abbildung 14.7 verwendet. Dort wurden die Subsysteme im Wet-
terberichtssystem gezeigt. Die UML-Pakete enthalten Kapselungskonstrukte und wirken
sich nicht direkt auf Entitäten im zu entwickelnden System aus. Sie können sich jedoch
in Strukturierungskonstrukten, zum Beispiel Java-Bibliotheken, widerspiegeln.
Abfolgemodelle wie z. B. das Sequenzdiagramm sind dynamische Modelle, die für
jeden Interaktionsmodus die Abfolge der stattfinden Objektwechselwirkungen dokumen-
tieren. ~ Abbildung 14.13 ist ein Beispiel für ein Sequenzdiagramm, das die beim Ein-
sammeln der Daten von einer Wetterstation beteiligten Vorgänge zeigt. Für ein Sequenz-
diagramm gelten folgende Aussagen:

I:KommSteuerung II :WetterStation I:WetterDaten


anfordern (B ericht) :
..
bestätigen 0
:
:
berichten 0 ...:.
zusammenfassen (

f-oc --------
senden (bericht)
"lI(
a ntworten (bericht)
"lI(

b es tätigen 0

Abbildung 14.13: Abfolge der Operationen - Datensammlung

o Die in das Zusammenspiel einbezogenen Objekte werden waagerecht angeordnet,


mit einer senkrechten gestrichelten Linie unter jedem Objekt.
D Die Zeit wird senkrecht dargestellt, was bedeutet, dass die Zeit abwärts entlang
der gestrichelten Linie - der "Lebenslinie" des Objekts - fortschreitet. Daher
kann die Abfolge der Vorgänge einfach aus dem Modell abgelesen werden.
14.2 Ablauf eines objektorientierten Entwurfs

D Die Interaktion zwischen Objekten wird durch beschriftete Pfeile dargestellt, die
die senkrechten Linien verbinden. Dies sind keine Datenströme, sondern darge-
stellte Nachrichten oder Ereignisse, die für das Zusammenspiel von grundlegen-
der Bedeutung sind.
D Das schmale Rechteck entlang der Lebenslinie eines Objekts stellt die Zeit dar, für
die das Objekt das steuernde Objekt im System ist. Ein Objekt übernimmt die Steu-
erung am oberen Ende des Rechtecks und gibt sie am unteren wieder ab. Wenn
eine Aufrufhierarchie existiert, wird die Steuerung so lange beibehalten, bis die
letzte Rückkehr vom ersten Methodenaufruf erfolgt ist.
Beim Dokumentieren eines Entwurfs sollten Sie für jede bedeutende Interaktion ein
Sequenzdiagramm erstellen. Falls Sie ein Anwendungsfallmodell entwickelt haben,
sollte es für jeden identifizierten Anwendungsfall ein Sequenzdiagramm geben.
~ Abbildung 14.13 zeigt die Abfolge der Interaktionen, wenn das externe Berichts-
system Daten von der Wetterstation abfragt. Sie lesen Sequenzdiagramme von oben
nach unten:
• Ein Objekt, das ein Exemplar von Komm Steuerung (: Komm Steuerung) ist, erhält aus
seiner Umgebung die Anfrage, einen Wetterbericht zu senden. Es bestätigt den
Erhalt dieser Anfrage. Die halbe Pfeilspitze an der bestätigten Nachricht zeigt an,
dass der Sender der Nachricht keine Rückantwort erwartet (asynchrone Nachricht).
• Dieses Objekt sendet dann eine Nachricht an ein Objekt der Klasse Wetter Stati on,
um einen Wetterbericht zu erstellen. Die Instanz von Komm Steuerung versetzt sich
anschließend selbst in einen Wartezustand (da das untere Ende des Steuerkäst-
chens erreicht ist). Der Stil der verwendeten Pfeilspitze zeigt an, dass die Objektins-
tanz von Komm Steuerung und die Objektinstanz von Wetter Stati on Objekte sind, die
nebenläufig ausgeführt werden können.
• Das Objekt der Klasse Wetter Stat i on sendet eine Nachricht an ein Objekt der
Klasse Wet terDat en, um die Wetterdaten zusammenzufassen. In diesem Fall zeigt
die geschlossene, ausgefüllte Form der Pfeilspitze an, dass die Instanz von Wette r-
Stati on auf eine Rückantwort wartet.
• Diese Zusammenfassung wird berechnet und die Steuerung an das Wetter Stat i on-
Objekt zurückgegeben. Der gestrichelte Pfeil zeigt die Rückgabe der Steuerung an.
• Dieses Objekt sendet eine Nachricht an die Instanz von Komm Steuerung und bittet
diese um Übertragung der Daten an das entfernte System. Das Objekt der Klasse
Wett e r Station versetzt sich daraufhin selbst in einen Wartezustand.
• Das Objekt der Klasse Komm Steu e rung sendet die zusammengefassten Daten an das
entfernte System, erhält eine Bestätigung und geht dann selbständig in einen War-
tezustand über, der bis zur nächsten Anfrage andauert.
Aus dem Sequenzdiagramm können wir entnehmen, dass die Objekte der Klassen
Komm St euerung und Wetter Sta t i on tatsächlich nebenläufige Prozesse sind, bei denen
die Ausführung ausgesetzt und wieder aufgenommen werden kann. Im Wesentlichen
wartet die Objektinstanz von Komm Steu erung auf Nachrichten des externen Systems,
dekodiert sie und löst Vorgänge der Wetterstation aus.
Sequenzdiagramme werden verwendet, um das gemeinsame Verhalten einer Objekt-
gruppe zu modellieren, aber Sie können auch das Verhalten eines einzelnen Objekts als
Erwiderung auf Nachrichten, die es verarbeiten kann, zusammenfassen. Um dies zu

I 363
OBJEKTORIENTIERTER ENTWURF

tun, können Sie ein Zustandsmodell verwenden, das zeigt, wie die Objektinstanz ihren
Zustand in Abhängigkeit von den eintreffenden Nachrichten verändert. Die UML ver-
wendet Zustandsdiagramme, die ursprünglich von Harel (Harel, 1987) erfunden wor-
den, um Zustandsmodelle zu beschreiben.
~ Abbildung 14.14 zeigt ein Zustandsdiagramm für ein Objekt der Klasse WetterSta -
ti 0 n, das zeigt, wie diese Instanz auf Anforderungen von verschiedenen Diensten reagiert.
Sie können dieses Diagramm folgendermaßen lesen:
• Im Zustand Heruntergefahren kann das Objekt nur auf die Nachricht hochfahren ()
reagieren. Es geht dann in einen Zustand über, in dem es auf weitere Nachrichten
wartet. Der unbezeichnete Pfeil mit dem schwarzen Kreis zeigt an, dass der Zu-
stand Heruntergefahren der anfängliche Zustand ist.
• Im Zustand Wa rtend erwartet das System weitere Nachrichten. Falls die Nachricht
herunterfahren() empfangen wird, kehrt das Objekt in den Zustand Herunterge -
fa h ren zurück.
• Wenn die Nachricht wetterBeri chten () empfangen wird, begibt sich das System in
den Zustand Zusammenfassend und danach, wenn die Zusammenfassung abgeschlos-
sen ist, in einen Zustand Übe rt ra gend, in dem die Information durch den KommSteue-
rung übertragen wird. Es kehrt anschließend in den Zustand Wa rtend zurück.
• Wenn die Nachricht ka 1i bri eren ( ) empfangen wird, geht das System in den Zustand
InKalibrierung über, anschließend in den Zustand ImTest, dann in den Zustand
Übertragend, ehe es in den Zustand Wartend zurückkehrt. Falls die Nachricht tes-
ten () empfangen wird, begibt sich das System direkt in den Zustand ImTest.
• Zu bestimmten Zeiten begibt sich das System in den Zustand, in dem es Daten von
den Messgeräten einholt. Jedes Messgerät wird in diesem Schritt angewiesen, seine
Daten zu erfassen.

Betrieb kalibrieren ()

hoch-
fahren ()

herunter-
fahren ()

Uhrimpuls Erfassend
Wetter-
Berichten
Wetterzusammen-
fassung
abgeschlossen

Abbildung 14.14: Zustandsdiagramm für WetterStation

Normalerweise ist es nicht notwendig, für alle von Ihnen bestimmten Objekte ein Zu-
standsdiagramm zu erstellen. Viele der Systemobjekte sind relativ einfach, so dass ein
Zustandsmodell den Programmierern das Verständnis dieser Objekte nicht erleichtern
würde.
14.2 Ablauf eines objektorientierten Entwurfs

14.2.5 Spezifikation der Objektschnittstelle


Ein wichtiger Bestandteil jedes Entwurfsprozesses ist die Spezifikation der Schnittstel-
len zwischen den Komponenten des Entwurfs. Sie müssen Schnittstellen dermaßen
spezifizieren, dass Objekte und Subsysteme parallel dazu entworfen werden können.
Sobald eine Schnittstelle spezifiziert worden ist, können die Entwickler anderer Objekte
davon ausgehen, dass diese Schnittstelle genau so implementiert werden wird.
Sie sollten die genaue Repräsentation der Schnittstelle in ihrem Schnittstellenentwurf
außen vor lassen. Die Einzelheiten sollten verborgen und Objektoperationen zur Ver-
fügung gestellt werden, um Daten zu aktualisieren und auf sie zuzugreifen. Wenn die
Repräsentation verborgen ist, kann sie geändert werden, ohne die Client-Objekte, die
diese Attribute verwenden, zu beeinflussen. Dies führt zu einem Entwurf, der besser
wartbar ist. Beispielsweise könnte die Darstellung eines Stapels von einem Array in
einer Liste umgeändert werden, ohne andere Objekte zu beeinflussen, die den Stack ver-
wenden. Im Gegensatz dazu ist es oft sinnvoll, Attribute in einem statischen Entwurfs-
modell aufzuzeigen, da dies die kürzeste Methode ist, wesentliche Objekteigenschaften
zu veranschaulichen.

interface Wetterstation f
public void Wetterstation () ;
public void hochfahren ()
public void hochfahren (Messgerät m) ;
public void herunterfahren C) ;
public void herunterfahren (Messgerät m)
public void wetterBerichten ' () ;
public void testen () ;
public void testen (Messgerät m)
public void kalibrieren (Messgerät m)
public int getIO () ;
//Wetterstation
Abbildung 14.15: Beschreibung der Wetterstationsschnittstelle in Java

Es gibt nicht immer eine einfache l:l-Beziehung zwischen Objekten und Schnittstel-
len. Dasselbe Objekt kann mehrere Schnittstellen besitzen. Jede dieser Schnittstellen
verkörpert einen Blickwinkel auf die Methoden, die das Objekt anbietet. Dies wird in
Java direkt unterstützt. Schnittstellen werden hier getrennt von Objekten deklariert
und durch die Objekte "implementiert". Gleichermaßen kann auf eine gesamte
Objektgruppe durch eine einzelne Schnittstelle zugegriffen werden.
Der Entwurf von Objektschnittstellen befasst sich mit der Spezifikation der Details
einer Schnittstelle in Bezug auf ein Objekt oder eine Objektgruppe. Das bedeutet, dass
die Signaturen und die Semantik der Dienste festgelegt werden, die von einem Objekt
oder einer Objektgruppe bereitgestellt werden. Schnittstellen können in der UML mit
derselben Notation, die auch für Klassen verwendet wird, spezifiziert werden. Es gibt
dabei jedoch keinen Attributsabschnitt. Der UML-Stereotyp <i nterface > sollte im
Namensteil enthalten sein.
Eine alternative Methode, eine die ich bevorzuge, ist die Definition der Schnittstelle
in einer Programmiersprache. Dies wird in ~ Abbildung 14.15 verdeutlicht. Sie zeigt
die Spezifikation der Wetterstationsschnittstelle in Java. Bei komplexeren Schnittstel-
len wird diese Methode immer effektiver, weil die Möglichkeiten zur Syntaxüberprü-

I 365
OBJEKTORIENTIERTER ENTWURF

fung im Compiler verwendet werden können, um Fehler und Widersprüche in der


Schnittstellenbeschreibung zu entdecken. Die Java-Beschreibung zeigt, dass einige
Methoden eine unterschiedliche Anzahl von Parametern besitzen können. So kann
zum Beispiel die Methode zum Herunterfahren entweder auf die Station als Ganzes
angewendet werden, falls sie keine Parameter besitzt, oder auf ein einzelnes Messgerät.

WetterStation
LuftQualität
Bezeichner
stickoxidDaten
wetterBerichten () rauchDaten
luftQualitätBerichten () benzolDaten
kalibrieren (messgeräte)
testen () erfassen 0
hochfahren (messgeräte) zusammenfassen 0
herunterfahren (messgeräte)

Messgeräte zur Überwachung der


Umweltverschmutzung I
I Stickox id-
Messgerät
I IRauchMessgerät I

I BenzolMessgerät

Abbildung 14.16: Neue Objekte zur Überwachung der Umweltverschmutzung

14.3 Weiterentwicklung des Entwurfs


Nach der Entscheidung über die Entwicklung eines Systems wie dem Wetterdaten-
erfassungssystems ist es unvermeidlich, dass Vorschläge zu Systemänderungen gemacht
werden. Ein wichtiger Vorteil einer objektorientierten Methode für den Entwurf besteht
darin, dass es einfacher ist, Änderungen am Entwurf vorzunehmen. Dies ist darauf
zurückzuführen, dass die Art der Darstellung eines Objektzustandes nicht den Entwurf
beeinflusst. Die Veränderung innerer Details eines Objekts wirkt sich kaum auf andere
Systemobjekte aus. Außerdem ist es für gewöhnlich einfach, neue Objekte einzuführen
und dabei kaum Auswirkungen auf das restliche System zu riskieren, da Objekte nur
lose gekoppelt sind.
Um zu zeigen, wie ein objektorientierter Ansatz Entwurfsänderungen erleichtert, neh-
men Sie einmal an, dass allen Wetterstationen die Möglichkeit zur Überwachung von
Umweltverschmutzungen hinzugefügt wird. Dies führt zur Hinzunahme eines Messge-
rätes für die Luftqualität, das die Menge verschiedener Schadstoffe in der Atmosphäre
berechnet. Die Verschmutzungsdaten werden zur selben Zeit wie die Wetterdaten über-
tragen. Um den Entwurf zu modifizieren, müssen die folgenden Änderungen vorgenom-
men werden:
• Eine Objektklasse namens LuftOual itä t sollte als Teil der Objektklasse Wetter-
Stat i on auf derselben Ebene wie WetterDaten eingeführt werden .
• Der Klasse WetterStat i on sollte eine Operation 1 uftOua 1 i tätBeri chten hinzuge-
fügt werden, um die Verschmutzungsinformationen an den Zentralcomputer zu sen-
Zusammenfassung

den. Die Steuerungs software der Wetterstation muss modifiziert werden, damit die
Verschrnutzungswerte automatisch erfasst werden, falls dies vom übergeordneten
Wette rStat i on-Objekt so gefordert wird .
• Es sollten Objekte für die verschiedenen Arten von Messgeräten zur Überwachung
der Umweltverschmutzung hinzugefügt werden. In diesem Fall können Stickoxid,
Rauchpartikel und Benzol gemessen werden.
Die Objekte zur Überwachung der Umweltverschmutzung sind in einern gesonderten
Paket namens Umwel tverschmut zungsMessgeräte gekapselt. Es hat Beziehungen zu
LuftOu a 1 ität und WetterStat i on, jedoch mit keinem der Objekte zum Erfassen der
Wetterdaten. ~ Abbildung 14.16 zeigt die Klasse Wetter Stati on und die neuen Objekte,
die zum System hinzugefügt wurden. Abgesehen von der höchsten Systemebene
(Wetter Stat i on) werden in den ursprünglichen Objekten der Wetterstation keine Ände-
rungen der Software verlangt. Das Hinzufügen der Erfassung der Verschmutzungsdaten
beeinflusst die Erfassung der Wetterdaten nicht.

Zusammenfassung
• Der objektorientierte Entwurf ist eine Methode des Softwareentwurfs, bei dem die grundlegen-
den Komponenten Objekte darstellen, die einen eigenen Zustand und statt Funktionen Opera-
tionen besitzen.
• Ein Objekt sollte einen Konstruktor sowie Prüfoperationen besitzen, die es ermöglichen, seinen
Zustand zu überprüfen und zu ändern. Die Objekte stellen Dienste (Operationen, die Zustands-
informationen verwenden) für andere Objekte zur Verfügung. Objekte werden zur Laufzeit mit
Hilfe einer Objektklassendefinition erzeugt.
• Objekte können sequenziell oder nebenläufig implementiert werden. Ein nebenläufiges Objekt
kann ein passives Objekt, dessen Zustand nur über seine Schnittstelle verändert wird, oder ein
aktives Objekt sein, das seinen Zustand ohne äußere Eingriffe ändern kann .
• Die Unified Modeling Language (UML) wurde definiert, damit ein Satz von grafischen Notatio-
nen bereitgestellt wird, um einen objektorientierten Entwurf zu dokumentieren.
• Der Ablauf des objektorientierten Entwurfs schließt Aktivitäten zum Entwurf der Systemarchi-
tektur, zur Bestimmung von Objekten im System, zur Beschreibung des Entwurfs mit Hilfe
verschiedener Objektmodelle und zur Dokumentation der Objektschnittstellen ein.
• Während eines objektorientierten Entwurfsprozesses kann ein Satz verschiedener Modelle
erstellt werden. Dieser enthält statische Modelle (z. B. Klassen-, Verallgemeinerungs- und Asso-
ziationsmodelle) und dynamische Modelle (z. B. Abfolge- und Zustandsmodelle).
• Objektschnittstellen müssen präzise definiert werden, damit sie von anderen Objekten verwen-
det werden können . Eine Programmiersprache wie Java kann benutzt werden, um Objekt-
schnittsteIlen zu dokumentieren.
• Ein wichtiger Vorteil des objektorientierten Entwurfs besteht darin, dass er die Weiterentwick-
lung des Systems vereinfacht.

I 367
OBJEKTORIENTIERTER ENTWURF

Ergänzende Literatur
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design
and the Unified Process, 2nd ed. Eine gute Einführung in die Verwendung von UML
innerhalb eines objektorientierten Entwurfsprozesses. Die Behandlung von Entwurfsmus-
tern ist auch für Kapitel 18 relevant. (c. Larman, 2001, Prentice Hall.)
The Unified Modelling Language User Guide. Der maßgebliche Text zur UML und
zu ihrer Verwendung für die Beschreibung objektorientierter Entwürfe. Dieses Buch
hängt unmittelbar mit zwei weiteren Texten zusammen: mit dem UML-Referenzhand-
buch und dem Vorschlag für einen objektorientierten Entwicklungsprozess. (G. Coulo-
ris et al., 1999, Addison-Wesley.)
Mitte 2003 wurde ein neuer UML-Standard (UML 2.0) verabschiedet, doch die genann-
ten Bücher wurden diesbezüglich bislang noch nicht aktualisiert. Ich erwarte, dass Aus-
gaben, die diesen neuen Standard enthalten, demnächst verfügbar sein werden.
Weiterhin gibt es im Internet eine riesige Auswahl von Einführungen und Lehrmate-
rial zu UML. Ich habe einige Links auf den Web-Seiten zum Buch angegeben.

Übungen Kapitel 14
DIll Erklären Sie, warum die Wahl eines Entwurfsansatzes, der auf lose gekop-
pelten Objekten basiert, die ihre innere Darstellung verbergen, zu einern
Entwurf führen soll, der leicht modifiziert werden kann.

eo Erklären Sie unter Verwendung von Beispielen den Unterschied zwischen


einern Objekt und einer Objektklasse.

IID Unter welchen Bedingungen könnte es angebracht sein, einen Entwurf zu


entwickeln, bei dem Objekte nebenläufig ausgeführt werden?

IID Entwerfen Sie mit Hilfe der UML-Notation die im Folgenden angegebenen
Objektklassen einschließlich ihrer Attribute und Operationen. Lassen Sie
bei der Bestimmung der Attribute und Operationen Ihre eigenen Erfahrun-
gen einfließen:
- ein Telefon
- einen Drucker für einen PC
- eine Stereoanlage
- ein Bankkonto
- einen Bibliothekskatalog
IID Entwickeln Sie einen detaillierten Entwurf einer Wetterstation, indern Sie
Schnittstellenbeschreibungen für die in ~ Abbildung 14.11 gezeigten Ob-
jekte vorschlagen. Diese können in Java, C++ oder in der UML ausge-
drückt werden.
IID Entwickeln Sie den Entwurf einer Wetterstation, um das Zusammenspiel
zwischen dem Subsystem "Datenerfassung" und den Messgeräten zu zei-
gen, die die Wetterdaten erfassen. Verwenden Sie zur Veranschaulichung
dieses Zusammenspiels Sequenzdiagramme.
Übungen

II1II Bestimmen Sie in den folgenden Systemen mögliche Objekte und entwi-
ckeln Sie dafür einen objektorientierten Entwurf. Sie können bei der Her-
leitung des Entwurfs begründete Annahmen zum System treffen.
- Geplant sind ein Gruppenterminkalender und ein Zeitmanagementsys-
tem, die gemeinsam die Zeitplanung für Besprechungen und Termine in
einer Gruppe von Mitarbeitern unterstützen sollen. Wenn ein Termin,
der eine bestimmte Anzahl von Menschen einschließt, getroffen werden
muss, findet das System in jedem der Terminkalender eine gemeinsame
Lücke und legt den Termin auf diesen Zeitpunkt. Wenn keine gemeinsa-
men freien Zeiten verfügbar sind, verständigt sich das System mit den
Mitarbeitern, um deren persönlichen Terminkalender zu ändern und
Platz für einen Termin zu finden.
- Eine Tankstelle soll vollständig automatisiert werden. Fahrer stecken
ihre Kreditkarte in ein Lesegerät, das mit der Zapfsäule verbunden ist.
Die Karte wird per Kommunikation mit dem Computer einer Kreditkar-
tengesellschaft überprüft und eine Benzinhöchstmenge festgelegt. Der
Fahrer kann dann den benötigten Kraftstoff tanken. Wenn der Tankvor-
gang beendet und der Schlauch zurück in die Halterung gesteckt ist,
wird das Kreditkartenkonto des Fahrers mit den Kosten für den entnom-
menen Kraftstoff belastet. Die Kreditkarte wird nach der Abbuchung
ausgegeben. Falls die Karte ungültig ist, gibt das Lesegerät sie zurück,
bevor Kraftstoff entnommen werden kann.

eo Fertigen Sie für die in der Übung 14.7 bestimmten Objekte genaue Schnitt-
stellenbeschreibungen in Java oder C++ an.
IID Zeichnen Sie ein Sequenzdiagramm, das das Zusammenspiel von Objek-
ten in einem Terminplanungssystem aufzeigt, wenn eine Gruppe von
Menschen einen Termin vereinbart.

iIIIll Zeichnen Sie ein Zustandsdiagramm, das die möglichen Zustandsände-


rungen in einem oder in mehreren der in Übung 14.7 bestimmten Objekte
aufzeigt.

Lösungen für ausgewählte Übungen dieses Kapitels finden Sie unter www.pearson-
studium.de auf der Companion Website zum Buch.

I 369