Das objektorientierte Konstruktionshandbuch

1 1 Einleitung 1.1 Das Thema des Buches 1 Einleitung »Die wirtschaftliche Situation motiviert viele Unternehmen,...

Author: Heinz Züllighoven | Dirk Bäumer | Wolf-Gideon Bleek | Carola Lilienthal

373 downloads 3789 Views 7MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

1

1

Einleitung

1.1

Das Thema des Buches

1

Einleitung

»Die wirtschaftliche Situation motiviert viele Unternehmen, sich an ihren Kunden zu orientieren. Die Kundenwünsche und -anforderungen gewinnen einen zentralen Stellenwert für die Unternehmenstrategie. Produkte und Dienstleistungen werden darauf abgestimmt. Je individueller diese Produkte und Dienstleistungen sein sollen, um so spezialisierter müssen die Anwendungssysteme an den unterschiedlichen Arbeitsplätzen sein. Diese Flexibilität stellt hohe Ansprüche an die Softwareentwicklung.« So könnte eine der Ankündigungen für einen Vortrag über den Werkzeug & Material-Ansatz beginnen. Dieser ökonomische Hintergrund soll potentielle Zuhörer oder Leser natürlich motivieren, sich mit diesem Ansatz zu beschäftigen. Aber dahinter steht mehr als eine Marketingstrategie. Kundenorientierung ist in den letzten Jahren nicht nur ein aktuelles Schlagwort geworden, sondern dieser Begriff

Federführung: Heinz Züllighoven Ko-Autor: Thomas Slotos

Kundenorientierung

1

Einleitung

1.1


2

bezeichnet auch eine sichtbare Veränderung in vielen Unternehmen. Dahinter steht die Einsicht, daß erfolgreiche Unternehmen sich von anderen oft durch ihre Kundenorientierung (vgl. [Fittkau 98]) unterscheiden. Diese Feststellung in [Peters & Waterman 82] kann aus folgenden Gründen als Auslöser für die aktuellen Reorganisationsprozesse gelten: ❑ Der zunehmend härtere Wettbewerb zwingt zum Umdenken in

der Unternehmensleitung. ❑ Viele Produkte und Dienstleistungen von hohem Reifegrad

drängen auf den Markt und werden aus der Sicht der Kunden austauschbar. ❑ Schlechter Service führt oft zur Abwanderung von Kunden,

wobei die Neuakquisition als teurer gegenüber der langfristigen Kundenbindung eingeschätzt wird. ❑ Unternehmen suchen nach neuen Differenzierungsmöglich-

keiten durch überdurchschnittlichen Service oder das Angebot zusätzlicher Dienstleistungen mit dem Ziel höherer Kundenzufriedenheit und gesteigerter Kundenbindung.

1

Einleitung

1.1


Kundenorientierung bedeutet in diesem Spannungsfeld ein kontinuierliches Bemühen, die Kundenzufriedenheit zu verbessern, um zu einer langfristigen Kundenbindung zu gelangen und damit den Unternehmenserfolg sicherzustellen. In der Folge werden Arbeitsprozesse, Organisationsstrukturen und Unternehmensstrategien kritisch hinterfragt. Dabei rückt auch die Informationstechnologie ins Blickfeld. Rasch wird klar, daß Informationstechnologie immer Mittel zum Zweck und nie Selbstzweck sein darf. In der Softwareentwicklung stellt sich die Frage, welchen Beitrag traditionelle Vorgehensweisen, Methoden und Prinzipien zu dieser Kundenorientierung leisten. Die Antwort ist für den Praktiker oft unklar. Deutliche Zweifel kommen mit Blick auf die Techniken und Werkzeuge auf, die in der Praxis verwendet werden. Lassen hier die neuen Produkte und Ansätze auf eine entscheidenden Besserung des gegenwärtigen Zustands hoffen? Wenn man die Euphorie betrachtet, mit der heute Java und das Internet-Computing diskutiert werden, dann könnte man daran glauben. Die Autoren dieses Buches sehen dies kritischer. Auch Methoden, Techniken und Werkzeuge sind Mittel zum Zweck. Wesentlich ist für uns, daß die Idee der Kundenorientierung eines Unternehmens zu einer Anwendungsorientierung für die Informationstechnologie führen muß. Damit meinen wir, daß die Mitarbeiter eines Unternehmens nur

3

Anwendungsorientierung

1

Einleitung

1.1


dann kundenorientiert agieren können, wenn sie eine entsprechende informationstechnische Unterstützung am Arbeitsplatz vorfinden. Betrachten wir Anwendungssoftware als einen relevanten hier interessierenden Bestandteil dieser Informationstechnologie, dann stellt sich die Frage, wie diese Anwendungssoftware gestaltet werden muß, damit sie ihren Beitrag zur Kundenorientierung leisten kann. Unsere kurzgefaßte Antwort lautet, daß nur eine anwendungsorientierte Softwareentwicklung die notwendigen Voraussetzungen dazu liefert. Das zentrale Anliegen dieses Buches ist daher, zu erläutern, was anwendungsorientierte Softwareentwicklung ist und wie sie konzeptionell und konstruktiv mit den Mitteln der Objektorientierung realisiert werden kann. Wenn wir in diesem Buch über Anwendungssoftware schreiben, meinen wir große und langlebige Softwaresysteme. Groß sind für uns objektorientierte Softwaresysteme, an denen ein Team von fünf bis zehn Personen mehr als ein Jahr entwickelt und die jenseits von 1000 Klassen umfassen. Langlebig bedeutet, daß diese Anwendungssoftware über mehrere Jahre eingesetzt und kontinuierlich an die veränderten Randbedingungen angepaßt werden muß. Schließlich ist für uns Anwendungssoftware dann groß, wenn mehr als ein Projekt im gleichen Anwendungsbereich an Komponenten oder Ausbaustufen dieses Systems arbeitet.

4

Große Anwendungssoftware

1

Einleitung

1.1


5

In diesen Dimensionen sind heute aus unserer Sicht Rahmenwerke (Frameworks) ein unersetzlicher Bestandteil. Sie bilden das architektonische Rückgrat, ohne das große Softwaresysteme nicht mehr mit vertretbarem Aufwand und mit befriedigender softwaretechnischer Qualität gebaut werden können. Rahmenwerke sind aber kein Allheilmittel. Die Entwicklung und der Einsatz von großen Rahmenwerken sind so komplex, daß viele Softwareprojekte damit überfordert sind. Daher wollen wir eine Anleitung geben, wie Rahmenwerke entwickelt und eingesetzt werden können. Es wird den Leser dieses Buches nicht verwundern, daß dabei die Anwendungsorientierung wieder eine entscheidende Rolle spielt. Als ein zentrales Problem bestehender Rahmenwerke schätzen wir ihre rein technische Ausrichtung ein. Wir zeigen, wie auf der Mikro- und der Makroebene anwendungsfachliche Konzepte und Strukturen die Architektur von Softwaresystemen beeinflussen können. Bei der Beschreibung dieser Konzepte spielen Muster eine große Rolle. Aufbauend auf [Gamma et al. 96] und unseren eigenen Arbeiten, beschreiben wir im Hauptteil dieses Buches Konzeptions- und Entwurfsmuster für die Entwicklung interaktiver Anwendungssoftware. Unter interaktiver Anwendungssoftware verstehen wir zunächst Software, die als Mittel zum Zweck hilft, fachliche Aufgaben in einem Anwendungsbereich zu erledigen. Dabei wird die Programmausfüh-

1

Einleitung

1.1


rung von Benutzereingaben oder Signalen technischer Systeme beeinflußt (s. [Floyd & Züllighoven 97]). Aber wir wollen nicht bei der Architektur eines Softwaresystems und seiner Konstruktion stehenbleiben. Wir meinen, daß Anwendungsorientierung insgesamt eine veränderte Herangehensweise an die Softwareentwicklung erfordert. Diese Herangehensweise führt zu anderen Softwareprodukten und einem gewandelten Entwicklungsprozeß. Von beidem handelt dieses Buch. Daraus ergibt sich folgende Gliederung:

6

Aufbau des Buchs

❑ Die Herangehensweise des WAM-Ansatzes ist nicht ad hoc

oder ohne Konzept entstanden. Den notwendigen Hintergrund dazu liefert der erste Teil bestehend aus Kapitel 1 und 2. Hier sind die wesentlichen Konzepte der Objektorientierung ebenso zu finden wie Grundzüge der Modellierung oder einer evolutionären Vorgehensweise. ❑ Teil 2 gibt in Kapitel 3 eine Konstruktionsanleitung für den

Bau interaktiver Arbeitsplatzsoftware. Zunächst erläutern wir detailliert, wie Werkzeuge und die anderen Komponenten einer Anwendung nach dem WAM-Ansatz entworfen und realisiert werden können. Der wesentliche Abschnitt beschreibt dann eine rahmenwerkbasierte Architektur für große Anwendungs-

1

Einleitung

1.1


7

systeme. In weiteren Abschnitten von Kapitel 4 skizzieren wir neue Ansätze und Konstruktionen, die über diesen bewährten Kern des WAM-Ansatzes hinausgehen: Themen sind die Unterstützung von Kooperation und Koordination, die Persistenz und die Ausweitung des WAM-Ansatzes auf technische Systeme. ❑ Teil 3 geht in Kapitel 5 auf den Entwicklungsprozeß und die

dabei verwendeten Dokumentationstypen ein. Wir beschreiben, wie wir industrielle Softwareprojekte unter Managementaspekten betrachten und wie sie im Rahmen einer evolutionären Vorgehensweise geplant werden können. Anwendungsorientierung erfordert dabei einige neue Dokumenttypen, die eine Zusammenarbeit von Softwareentwicklern und Anwendern erst ermöglichen. Die Beschreibung dieser anwendungsorientierten Dokumenttypen und der Art und Weise, wie sie im Entwicklungsprozeß eingesetzt werden können, bildet den Schwerpunkt dieses Teils.

1

Einleitung

1.2

1.2

Der Werkzeug & Material-Ansatz

8


1.2.1 Der WAM-Ansatz kurz gefaßt Wir haben in den letzten Jahren viel über die allgemeine Herangehensund Sichtweise geschrieben, die hinter dem WAM-Ansatz steht (z.B. [Kilberth et al. 94]). Der folgende Abschnitt soll dem Leser einen raschen Überblick geben. Der WAM-Ansatz strebt die Anwendungsorientierung in der Softwareentwicklung an. Anwendungsorientierte Software zeichnet sich durch hohe Gebrauchsqualität aus, die wir so charakterisieren: ❑ Die Funktionalität des Systems orientiert sich an den Aufgaben

aus dem Anwendungsbereich. ❑ Die Handhabung des Systems ist benutzergerecht. ❑ Die im System festgelegten Abläufe und Schritte lassen sich je

nach Anwendungssituation problemlos an die tatsächlichen Anforderungen anpassen. Auf der Grundlage objektorientierter Entwurfs- und Konstruktionstechniken vereinigt der Ansatz so verschiedene Bestandteile wie ein

1

Einleitung

1.2


Leitmotiv mit Entwurfsmetaphern, anwendungsorientierte Dokumente und eine evolutionäre Vorgehensweise mit Prototyping. Die zentrale Idee des Werkzeug & Material-Ansatzes ist, die Gegenstände und Konzepte des Anwendungsbereichs als Grundlage des softwaretechnischen Modells zu nehmen. Das Ergebnis soll eine enge Korrespondenz zwischen dem anwendungsfachlichen Begriffsgebäude und der Softwarearchitektur sein. Diese Strukturähnlichkeit hat zwei entscheidende Vorteile: Die Anwender finden die Gegenstände ihrer Arbeit und die Begriffe ihrer Fachsprache im Anwendungssystem repräsentiert. Sie können entsprechend ihre Arbeit in gewohnter Weise organisieren. Die Entwickler können Softwarekomponenten und Anwendungskonzepte bei fachlichen und softwaretechnischen Änderungen zueinander in Beziehung setzen und somit die wechselseitigen Abhängigkeiten erkennen. Interaktive Anwendungssoftware muß eine aufgabengerechte Funktionalität mit einer geeigneten Handhabung und Präsentation zusammenbringen. Aus dieser Sicht ist Softwareentwicklung eine Gestaltungsaufgabe im ursprünglichen Sinne: Form und Inhalt müssen zueinander passen. Dadurch tritt neben die traditionelle softwaretechnische Aufgabe, einen geeigneten Algorithmus zur Erledigung einer fachlichen »Funktion« zu finden und zu implementieren, die Frage, welche »Gestalt« ein Softwareprodukt annehmen und wie es bei der

9

Strukturähnlichkeit

Leitbild und Entwurfsmetaphern

1

Einleitung

1.2


10

Aufgabenerledigung gehandhabt werden soll. Bei dieser Gestaltungsaufgabe müssen Softwareentwickler unterstützt werden. Dies soll im Rahmen des Werkzeug & Material-Ansatzes das Leitbild leisten. Ein Leitbild ist in unserem Zusammenhang eine explizite Sichtweise bei der Softwareentwicklung. Es hilft den Anwendern und Entwicklern, die Anwendungssoftware zu verstehen und zu entwerfen. Unser häufigstes Leitbild ist der Arbeitsplatz für qualifizierte und eigenverantwortliche Tätigkeiten. Dieses Leitbild hat sich in unseren zahlreichen Kooperationsprojekten im Banken- und Dienstleistungsbereich bewährt. Dort wird vorrangig Bürotätigkeit qualifizierter Mitarbeiter und Mitarbeiterinnen unterstützt – Tätigkeiten also, die neben Fachwissen und Erfahrung auch eine gewisse Eigenständigkeit und Initiative bei der Erledigung der täglichen Aufgaben verlangen. Ein allgemeines Leitbild sollte »griffig« sein, damit es wirklich anschaulich wird. Dazu dient ein Satz von passenden Entwurfsmetaphern, die durch ihre »Bildhaftigkeit« ein Leitbild konkretisieren. Eine Entwurfsmetapher beschreibt ein Konzept oder eine Komponente des Anwendungssystems durch einen Gegenstand der Alltagswelt. So schafft die Entwurfsmetapher eine Verständigungsbasis für Entwickler und Anwender – sie bezieht sich anschaulich auf den gemeinsamen Erfahrungshintergrund und stellt einen verständlichen Begriff zur Verfügung. Passend zu dem Leitbild des Arbeitsplatzes sind

1

Einleitung

1.2


die Entwurfsmetaphern Werkzeug, Material, Automat und Arbeitsumgebung. Offensichtlich stammen diese zentralen Metaphern aus dem Kontext menschlicher Arbeit. Menschen treffen bei der Arbeit eine intuitive Unterscheidung zwischen den Dingen, die ihre Arbeitsgegenstände darstellen und den Dingen, die sie zur Bearbeitung als Arbeitsmittel verwenden. Entsprechend haben wir die grundlegenden Metaphern Werkzeug und Material so definiert: Ein Werkzeug unterstützt wiederkehrende Arbeitsabläufe und -handlungen. Es ist bei unterschiedlichen Aufgaben und Zielsetzungen nützlich. Ein Werkzeug wird von seinem Benutzer je nach den Erfordernissen einer Situation gehandhabt oder wieder zur Seite gelegt. Es schreibt keine festen Arbeitsabläufe vor. Als Softwarewerkzeug ermöglicht es den interaktiven Umgang mit den Arbeitsgegenständen. Materialien sind die Arbeitsgegenstände, die schließlich zum Arbeitsergebnis werden. Materialien werden mit Werkzeugen entsprechend bearbeitet. Softwarematerialien verkörpern »reine« anwendungsfachliche Funktionalität. Sie werden niemals direkt benutzt und stellen sich auch nicht selbst dar. Ein Softwarematerial ist durch sein Verhalten, nicht durch seine Struktur charakterisiert. In einer Büroumgebung gibt es nicht nur Werkzeuge und Materialien. Viele lästige Arbeitsroutinen werden heute maschinell, d.h. auto-

11

Werkzeug

Material

1

Einleitung

1.2


matisch, erledigt. Wir haben dazu die Entwurfsmetapher Automat eingeführt: Ein Automat erledigt eine vorab vollständig festgelegte Aufgabe und produziert ein definiertes Ergebnis. Einmal eingestellt, kann ein Automat über einen längeren Zeitraum ohne Eingriff von außen ablaufen. Softwareautomaten laufen meist im Hintergrund. Sie werden von ihren Benutzern initial eingestellt oder im Notfall gestoppt und haben darüber hinaus keine interaktive Schnittstelle. Werkzeuge, Automaten und Materialien benötigen einen Ort, an dem sie bereitgestellt, angeordnet und aufbewahrt werden. Dies leistet die Metapher von der Arbeitsumgebung: Eine Arbeitsumgebung ist der Ort, an dem Arbeitsaufgaben erledigt und die dazu benötigten Arbeitsgegenstände und -mittel bereitgestellt werden. Arbeitsumgebungen verkörpern ein Raumkonzept und Ordnungsprinzipien. Wir unterscheiden zwischen persönlichen Arbeitsplätzen, die Privatheit und eine individuelle Anordnung der Dinge ermöglichen, und den allgemein zugänglichen Räumen einer Arbeitsumgebung. Im Kontext von Büroarbeit, aber auch in vielen anderen Anwendungsbereichen, reicht es heute nicht mehr aus, nur individuelle Arbeit zu unterstützen. Anwendungssysteme für kooperative Arbeit stellen neue Herausforderungen an die Softwareentwicklung. Unsere ersten

12 Automat

Arbeitsumgebung

Kooperative Arbeit

1

Einleitung

1.2


Erfahrungen in diesem Bereich legen die Schlußfolgerung nahe, daß kooperative Arbeit in ähnlicher Weise durch Arbeitsmittel und -gegenstände unterstützt werden kann, wie wir das für den individuellen Arbeitsplatz gezeigt haben. Neue Ressourcen kommen allerdings hinzu, die dem speziellen Charakter arbeitsteiliger aber weitgehend selbstorganisierter Arbeit gerecht werden. Dazu gehören Entwurfsmetaphern wie Archiv, Vorgangsmappe und Laufzettel. Diese Erweiterung des Repertoires an Entwurfsmetaphern für die Unterstützung kooperativer Arbeit paßt in den Kontext unseres Leitbilds. Auch bei kooperativer Arbeit sind die Benutzer Experten im Anwendungsbereich, die je nach Situation entscheiden, ob sie einen vorformulierten Standardvorgang bearbeiten oder ob spezifische Änderungen im Ablauf und in der Arbeitsaufteilung sinnvoll sind. Dieses Bild steht im Gegensatz zur prozeßorientierten Automatisierung, die von den meisten Workflow-Management-Systemen verfolgt wird. Hier werden die Benutzer oft als »Bediener« betrachtet, deren Aktionen vom System detailliert vorgegeben und kontrolliert werden. Für die Entwickler bedeutet Anwendungsorientierung, daß sie die Aufgaben verstehen müssen, die sie durch entsprechende Arbeitssysteme unterstützen sollen. Dazu müssen sie sich den Zugang zum Fachwissen und zur Erfahrung der Anwendungsexperten verschaffen. Das Schlüsselwort heißt hier »evolutionäre Systementwicklung«, da

13

Evolutionäre Systementwicklung

1

Einleitung

1.2


diese auf eine enge Zusammenarbeit der Entwickler mit den Anwendern ausgerichtet ist. Zusammenarbeit muß aber eine Grundlage haben. Deshalb setzen wir anwendungsorientierte Dokumenttypen und das Konzept des Prototyping ein. Anwendungsorientierte Dokumenttypen als notwendige Basis zum Verständnis der Konzepte und Aufgaben im Anwendungsbereich sind nichts Neues. Aus unserer Sicht ist dabei wesentlich, diese Dokumenttypen in der Fachsprache des Anwendungsbereichs zu formulieren. Wir verwenden folgende anwendungsorientierte Dokumenttypen: Szenarios beschreiben die aktuelle Arbeitssituation. Dabei liegt der Augenmerk auf den Aufgaben im Anwendungsbereich und der Art und Weise, wie die jeweiligen Aufgaben unter Verwendung von Arbeitsmitteln und Arbeitsgegenständen erledigt werden. Szenarios werden von den Entwicklern auf der Grundlage von Interviews mit Anwendern und anderen beteiligten Gruppen im Anwendungsbereich geschrieben. Ein Glossar definiert und rekonstruiert das Begriffsgebäude der jeweiligen Fachsprache. Die Glossareinträge werden von den Entwicklern parallel zu den Szenarios geschrieben. Sie geben erste Hinweise auf Materialien für den Systementwurf. Systemvisionen stehen am Übergang zwischen der Analyse des Anwendungsbereichs und der Konstruktion des zukünftigen Systems.

14

Anwendungsorientierte Dokumenttypen

Szenarios

Glossar

Systemvisionen

1

Einleitung

1.2


Auf der Basis der Szenarios antizipieren sie zukünftige Arbeitssituationen. Sie richten sich vorrangig an Entwickler und helfen, eine gemeinsame »Vision« des Systems aufzubauen. Sie beschreiben die Vorstellungen über die fachliche Funktionalität und die Handhabung von Werkzeugen, Materialien, Automaten und den anderen Komponenten des Systems. Prototypen sind die wesentliche konstruktive Ergänzung der Systemvisionen. Durch sie werden die Ideen über das System »anfaßbar«. Vor allem sogenannte funktionelle Prototypen sind nicht nur für die Kommunikation mit den Anwendern von zentraler Bedeutung, sondern geben den Entwicklern die notwendige Erfahrungs- und Experimentiergrundlage für die technische Konstruktion des Systems. Damit spielt Prototyping in unserer Herangehensweise eine zentrale Rolle (s. auch Kapitel 5.2.4). Für die Analyse kooperativer Arbeit und den Entwurf entsprechender Anwendungssoftware ist es notwendig, das Repertoire der beschriebenen Dokumenttypen zu erweitern. Wir haben festgestellt, daß sich mit Szenarios, Glossaren und Systemvisionen die verschiedenen Aufgaben und Aktivitäten sehr gut aus der Sicht der einzelnen Arbeitsplätze beschreiben lassen. Was fehlt ist die Gesamtsicht. Um diesem Problem zu begegnen, haben wir erfolgreich z.B. sogenannte Kooperationsbilder eingesetzt. Diese Bilder basieren im wesentlichen

15

Prototypen

Kooperationsbilder

1

Einleitung

1.2


auf allgemeinverständlichen Piktogrammen und stellen dar, welche Arbeitsgegenstände und Informationen auf welchem Weg zwischen den Beteiligten ausgetauscht werden. Mit dem Leitbild, den Entwurfsmetaphern, den Dokumenttypen und dem Bau von Prototypen haben wir einen Satz zusammengehöriger Konzepte und Hilfsmittel, um Softwareentwicklung mit dem Fokus auf den Anwendungsbereich zu ermöglichen. Die Entwickler haben damit die Voraussetzungen an der Hand, um das gesteckte Ziel einer hohen Gebrauchsqualität anzusteuern. Aber erst die richtige Umsetzung der Konzepte und der Einsatz der Hilfsmittel im Entwicklungsprozeß entscheiden darüber, ob sich dieses Ziel wirklich erreichen läßt. Aus unserer Sicht ist es daher unerläßlich, den Entwicklern auch eine Anleitung für die Gestaltung dieses Prozesses zu geben. Das Grundprinzip dabei ist, Softwareentwicklung nicht als eine vorrangig technische oder formale Aufgabe, sondern als einen Kommunikationsund Lernprozeß zu betrachten. Lernen und Kommunikation sind evolutionäre Prozesse, die durch ständige Rückkopplung zwischen den Beteiligten vorwärts getrieben werden. In diesem evolutionären Prozeß zwischen Bearbeitung und Rückkopplung sind prinzipiell alle Dokumente eines Projektes einbezogen. Es geht nicht darum, eine festgelegte Folge von Meilensteindokumenten sequentiell abzuarbeiten, sondern analysierende, modellierende

16

Der Entwicklungsprozeß

1

Einleitung

1.2


und bewertende Aktivitäten je nach Erfordernissen zu verknüpfen. Dies widerspricht erkennbar den Prinzipien der klassischen Wasserfall- oder Phasenmodelle (vgl. Kapitel 5.1.1), ist aber aus unserer Erfahrung eine wesentliche Voraussetzung für das Gelingen eines anwendungsorientierten Entwicklungsprojektes. Der evolutionäre Prozeß spielt sich in unseren Projekten in der Form sog. Autor-Kritiker-Zyklen ab. Die Entwickler sind meist die Autoren. Ihre Arbeitsgegenstände sind die bereits genannten Dokumenttypen und Prototypen. Als Kritiker treten die Beteiligten auf, die jeweils das notwendige Fachwissen besitzen. Im Sinne der Anwendungsorientierung sind dies meist die Anwender. Der Autor-KritikerZyklus ist also ein Wechsel zwischen Analysieren, Modellieren und Bewerten. Zum Verständnis unserer Vorgehensweise ist es wichtig zu sehen, daß die jeweils identifizierten Probleme im Rückkopplungsprozeß die nachfolgenden Aktivitäten und die Auswahl der zu bearbeitenden Dokumente bestimmen. In diesem Sinne gibt es keine vordefinierte Reihenfolge von Dokumenten und Phasen. Als Idealvorstellung kann zu jedem Zeitpunkt prinzipiell jedes Dokument bearbeitet werden. Daß die Aktivitäten insgesamt in einem konkreten Projekt geplant und kontrolliert werden müssen und nicht einer individuellen Beliebigkeit ausgeliefert sind, steht außer Frage. Es sollte aber klar werden, daß der

17

Autor-Kritiker-Zyklen

1

Einleitung

1.2


18

grundlegende Prozeß selbst wieder von anwendungsorientierten Fragestellungen und nicht von einem softwaretechnisch zentrierten Mechanismus bestimmt wird.

1.2.2 WAM als Methode Wir sprechen in diesem Handbuch vom WAM-»Ansatz«. Was ist damit gemeint? Sollten wir nicht einfacher von der WAM-Methode reden? Nun ist der Methodenbegriff gerade in der Objektorientierung ziemlich vorbelegt – und das in einem Sinne, den wir kritisch beleuchten wollen. Vielfach finden wir im Kern von »Methodenbüchern« eine Sammlung von grafischen Notationen und zugehörigen Benutzungsanleitungen. So wird verständlich, daß auch die UML (s. [Burkhardt 97]) vielfach als »Methode« verkauft wird. Nun geben Notationen, Grafiken und mitgelieferte grafische CASE-Tools noch recht wenig Unterstützung im fachlichen und softwaretechnischen Entwicklungsprozeß. Auf der anderen Seite des Spektrums stehen Methodenbücher, die wie Kochbücher oder Bastelanleitungen für einen Modellbaukasten geschrieben sind »Nimm das, tu jenes, achte auf ein Drittes und fertig ist das objektorientierte Anwendungssystem«. Diese Bücher erfüllen

Der Methodenbegriff

1

Einleitung

1.2


uns mit einem gewissen Mißtrauen, da uns fast 30 Jahre SoftwareEngineering-Geschichte und unsere eigene Erfahrung sagen, daß diese Art von Vorschriften in der Praxis nicht funktioniert. Wir fassen den Methodenbegriff also im Sinne von [Gryczan 96] weiter: »Eine Methode stellt einen Satz von Werkzeugen und Darstellungsmitteln zur Verfügung. Dazu beinhaltet sie eine Vorgehensweise, die den Einsatz der Werkzeuge und Darstellungsmittel als Menge von Regeln anleitet.« Die tieferliegenden Gründe für das Scheitern allgemeiner Verfahrensvorschriften liefert z.B. Christiane Floyd in ihren Arbeiten (s. [Floyd 94]). Die Quintessenz ist: Jedes Softwareprojekt ist trotz aller Gemeinsamkeiten konkret anders als seine Vorgänger. Wenn wir also diesen Unterschieden gerecht werden wollen, bleibt die Schlußfolgerung: Eine erfolgreiche Methode wird nicht einfach angewendet, sie wird im Projekt erarbeitet. Der WAM-Ansatz ist daher keine Methode zur fertigen Verwendung, sondern:

19

Methodenarbeit

Der WAM-Ansatz als Methodenrahmen

❑ eine Sicht der objektorientierten Anwendungsentwicklung, ❑ eine Sammlung bewährter Konstruktions-, Analyse- und

Dokumentationstechniken,

1

Einleitung

1.2


20

❑ eine Beschreibung zusammenpassender Konzepte, ❑ eine Auswertung unterschiedlicher und umfangreicher Projekt-

erfahrungen, ❑ eine Anleitung, um eine konkrete Konstruktionstechnik und

eine dazu passende Vorgehensweise zu entwickeln. Damit ist der WAM-Ansatz eher als eine »Meta-Methode« oder eine »Methode 2. Ordnung« zu bezeichnen. C. Floyd hat hierfür das Wort Methodenrahmen verwendet. [Gryczan 96] erläutert: »Ein Methodenrahmen verkörpert (1) eine grundlegende Sichtweise der Softwareentwicklung, bezieht sich auf (2) eine Klasse von Anwendungsbereichen und gibt (3) Richtlinien vor für die Auswahl von Methoden, Werkzeugen und Organisationsformen.« Kurz gesagt soll der WAM-Ansatz helfen, für ein konkretes Projekt und eine konkrete Entwicklungsorganisation die passende Methode zu erarbeiten. Die Voraussetzung dazu ist, daß der Leser die Sichtweise der Autoren teilt oder zumindest ausreichend nachvollziehen kann. Sichtweisen entstehen auf dem Hintergrund von Erfahrungen und Wertvorstellungen. Dieser Hintergrund kann im Rahmen eines Handbuches nicht ausführlich dargestellt werden. Trotzdem muß dieses Grundverständ-

Sichtweisen

1

Einleitung

1.3

Die Leser

nis zwischen Autoren und Lesern geschaffen werden. Deshalb kommentieren wir die Konzepte und Konstruktionen, bringen Beispiele und berichten über Erfahrungen aus konkreten Projekten. Erst das schafft, so meinen wir, den richtigen Kontext, in dem der WAMAnsatz verstanden und für die tägliche Arbeit des Lesers konkretisiert werden kann. Schließlich noch ein Wort zur Originalität. Wir wollten mit dem WAM-Ansatz nie etwas völlig Neues schaffen oder uns bewußt von anderen abgrenzen. Wenn der Leser daher bekannte Konstruktionen, Darstellungsmittel und Ideen wiederentdeckt, dann ist das in unserem Sinne. Denn als Softwaretechniker wollen wir keine »Originalgenies« sein, sondern Bewährtes und Sinnvolles zusammentragen und verfügbar machen.

1.3

21

Originalität von WAM

Die Leser

Welche Leser wollen wir mit diesem Handbuch ansprechen? Hier haben wir uns ein hohes Ziel gesteckt und gleich mehrere, recht unterschiedliche Lesergruppen ins Auge gefaßt:

Praktiker

❑ Erfahrene Praktiker, die objektorientierte Anwendungssoft-

ware entwickeln. Damit meinen wir Personen, die sich in min-

1

Einleitung

1.3

Die Leser

22

destens einer gängigen objektorientierten Sprache zu Hause fühlen und erste Projekterfahrungen gesammelt haben. Sie stehen vor der Aufgabe, in kommenden Projekten Rahmenwerke zu entwickeln, bestehende einzusetzen und fertige Komponenten zu integrieren. Sie haben die grundlegende Bedeutung von Entwurfsmustern erkannt. Vor diesem Hintergrund suchen sie nach einem Ansatz, die verschiedenen Konzepte und Techniken mit der eigenen Erfahrung zu verbinden und in eine geeignete Vorgehensweise einzubetten. Diesen erfahrenen Entwicklern und »Software-Architekten« versuchen wir, die gesuchten Zusammenhänge zu zeigen. Wir geben aber auch immer wieder konkrete Hinweise bei Konstruktionsansätzen und Vorgehensweisen, die auf diesem Erfahrungsstand aufbauen. ❑ Erfahrene Projektmanager von objektorientierten Projekten,

Projektmanager

die für die Ideen einer evolutionären Vorgehensweise aufgeschlossen sind, aber nach einer planbaren und nachvollziehbaren Projektorganisation suchen. Sie haben festgestellt, daß rigide Wasserfallmodelle nur die Illusion eines kontrollierbaren Projektes schaffen. Sie wissen, daß softwaretechnisches Know-how und Werkzeugeinsatz ohne anwendungsfachliches Verständnis wirkungslos bleiben. Sie haben aber auch begrif-

1

Einleitung

1.3

Die Leser

23

fen, daß nachhaltige Softwareentwicklung und hohe Gebrauchsqualität der Produkte ohne technische Konzepte und ein gutes Handwerkszeug nicht zu erreichen sind. Diesen Projektmanagern liefern wir die Konzepte, Richtlinien und Dokumenttypen, um eine anwendungsorientierte Vorgehensweise für das eigene Team oder die ganze Organisation zu erarbeiten. Die Vorgehensweise zielt auf präzise Planbarkeit, hohe Flexibilität gegenüber Veränderungen und konstruktive Qualitätssicherung des Softwareproduktes. ❑ Engagierte Studenten, die eine solide Informatikgrundausbil-

Studenten

dung haben und nach einer integrierenden Sicht auf die verschiedenen Aspekte der objektorientierten Softwareentwicklung suchen. Sie haben ihr softwaretechnisches Handwerkszeug gelernt und können in einer objektorientierten Sprache programmieren. Diesen Studenten versuchen wir, unsere Sichtweise und unsere Erfahrungen zu vermitteln. Wir haben oft in der Ausbildung von Softwaretechnikern die Erfahrung gemacht, daß viel von der direkten Zusammenarbeit und gemeinsamen Erfahrung in Projekten abhängt. Aber dies reicht nicht aus. Die systematische »Zusammenschau« in einem

1

Einleitung

1.3

Die Leser

24

Buch, aus der sich der Lernende sein Bild machen kann, scheint immer noch unersetzlich. ❑ Diskussionsbereite Methodenentwickler, die sich dafür interes-

Methodenentwickler

sieren, was es mit dem Werkzeug & Material-Ansatz auf sich hat. Wir haben in den letzten Jahren einiges über unseren Ansatz veröffentlicht. Vieles davon ist nicht einfach zugänglich; nichts wird dem Anspruch auf ein ausreichend detailliertes Gesamtbild gerecht. Dieses Handbuch ist zumindest ein Versuch, den aktuellen Wissens- und Diskussionsstand der verschiedenen Gruppen und Personen zusammenzutragen, die aktiv den WAM-Ansatz vorantreiben. An wen richtet sich dieses Buch nicht? ❑ Programmiernovizen, die eine objektorientierte Sprache erler-

Kein Programmierlehrbuch

nen wollen. Dieses Konstruktionshandbuch ist nicht als Programmierlehrbuch gedacht. Die Programmbeispiele sind nur Skizzen zur Illustration von Konstruktionsideen. Sie sind deshalb noch nicht einmal als Beispiele für besonders »ausgefuchste« Konstruktionen in der jeweiligen Programmiersprache zu verstehen. Weil sie sich an erfahrene Programmierer richten, werden diese die Ideen in ihrem eigenen »Idiom« umsetzen. Da

1

Einleitung

1.3

Die Leser

25

es uns um die Konzepte hinter den Konstruktionen geht, haben wir gegenüber der ursprünglichen Planung darauf verzichtet, in diesem Handbuch umfangreiche Codebeispiele zu bringen. Oft haben wir statt dessen nur Klassen- oder Interaktionsdiagramme verwendet. Lesern ohne eigene Programmiererfahrung werden viele Erläuterungen oder Hinweise in diesem Handbuch unverständlich bleiben. ❑ IT-Manager, die sich einen Überblick über die Objektorientie-

rung als Sichtweise in ihren verschiedenen Facetten verschaffen wollen. Die grundlegenden Fragen, »Was ist Objektorientierung?« und »Ist Objektorientierung praxistauglich?«, sprechen wir hier nicht an. Dies haben wir in [Kilberth et al. 94] versucht. Das vorliegende Handbuch geht über diese Fragen hinaus. Selbst die Konzeptabschnitte im ersten Teil sind für die festgeschriebene Diskussion über Objektorientierung gedacht. Was ist also die Grundlage, um dieses Buch mit Gewinn zu lesen?

Keine allgemeine Einführung in Objektorientierung

Erforderliche Grundlagen

❑ Grundlegende Kenntnisse im Bereich Softwaretechnik, ❑ Programmierkenntnisse in einer objektorientierten Sprache,

1

Einleitung

1.4

Die Handhabung

26

❑ »Zugriff« auf das Buch [Gamma et al. 96]. Dieses Buch über

Entwurfsmuster hat mittlerweile die Fachsprache der objektorientierten Softwareentwickler weltweit geprägt. Auch wir haben uns von Anfang an mit den dort beschriebenen Mustern auseinandergesetzt und sie in unseren eigenen Entwurfsmustern referenziert.

1.4

Die Handhabung

Dieses Buch ist als Handbuch gedacht, d.h., es soll ein thematisch geordnetes Nachschlagewerk sein. Wir haben uns entsprechend bemüht, jedes Kapitel weitgehend in sich geschlossen zu formulieren. Bezüge zu anderen Kapiteln sind als Ergänzungen oder Vertiefungen gedacht. Natürlich setzen die einzelnen Kapitel unterschiedliches Vorwissen voraus. Doch generell sollte der interessierte Leser im jeweiligen Abschnitt oder Kapitel die Antworten zu seinen Fragen finden, ohne dazu das ganze Buch lesen zu müssen. Nichts spricht jedoch dagegen, dieses Buch »von Deckel zu Dekkel« zu lesen. Wir haben die Abschnitte so angeordnet, daß eine »Entwicklungsrichtung« erkennbar sein sollte. Auch hoffen wir, keine störenden Redundanzen in den Text gebracht zu haben. Allerdings steht

Das Buch als Handbuch

1

Einleitung

1.4

Die Handhabung

der Handbuchcharakter im Vordergrund. Deshalb haben wir keine durchgängige Darstellung zwischen den Kapiteln gewählt. Der erste Konzeptteil des Buchs hat einführenden Charakter. Dort finden Leser, die mit den verschiedenen Themen der Objektorientierung und des WAM-Ansatzes noch nicht vertraut sind, die notwendigen Grundlagen, um die weiteren Teile mit Gewinn lesen zu können. Erfahrene Leser werden sich hier über die Begriffe und Konzepte informieren, die im weiteren verwendet werden. Die Muster zu Beginn des zweiten Teils sind in der Art eines Musterkatalogs aufeinander bezogen. Sie sollen zwar einzeln verständlich sein, gehören aber doch zu einer »Gesamtsicht«. Sie bilden den konstruktiven Kern des WAM-Ansatzes. Der folgende Abschnitt über eine rahmenwerkbasierte Musterarchitektur richtet sich an Leser, die das Handwerkszeug der objektorientierten Konstruktion schon beherrschen. Hier zeigen wir, wie Systeme im Großen entworfen und in Schichten aufgebaut werden können. Die weiteren Abschnitte behandeln Aspekte, die über den Kern des WAM-Ansatzes hinausgehen. Die Aspekte »Kooperation und Kommunikation«, »Persistenz« und »technische Systeme« richten sich an den entsprechenden Leserkreis. Hier sollten keine »endgültigen« Antworten erwartet werden. Wir legen Zwischenstände, gegründet auf

27 Grundlagen im 1. Teil

Die WAM-Muster

Eine WAMModellarchitektur

Kooperation, Kommunikation, Persistenz, technische Systeme

1

Einleitung

1.4

Die Handhabung

Projekterfahrungen und unserem Konzeptwissen, vor. Da die angesprochenen Themen aber in vielen Projekten drängen, sollen diese Zwischenstände schon über die größten Hürden hinweghelfen. Der dritte Teil wendet sich an Projektmanager und an Leser, die sich mit der Vorgehensweise in Projekten beschäftigen. Neben verschiedenen Themen der Projektplanung, -gestaltung und -kontrolle stellen wir ausführlich unsere anwendungsorientierten Dokumenttypen vor. Diese Dokumenttypen sind ein wesentlicher Bestandteil des WAM-Ansatzes und sollten unbedingt in Projekten berücksichtigt werden. Weitgehend durch alle Teile des Buches geht das Beispiel des Pausenplans, das wir gleich skizzieren. Dieses Beispiel ist bewußt so klein und handlich gewählt, daß sich jeder Leser in den fachlichen und technischen Aspekten zurechtfinden sollte. Da es nur zur Illustration der Grundideen des WAM-Ansatzes dienen soll, haben wir gar nicht erst versucht, im Buch daraus ein »realistisches« Anwendungssystem zu entwickeln. Obwohl wir dieses Beispiel im Rahmen von Studentenprojekten und -arbeiten mehrfach realisiert haben, sind nur Skizzen aus diesen Arbeiten im Buch zu finden. Die tatsächliche Implementatierung in Java, C++ oder Smalltalk ist so umfangreich, daß sie Konzepte im Rahmen eines Handbuchs eher verstellt als deutlich gemacht hätte. Passagen, in denen wir auf das Pausenplanbeispiel eingehen, sind durch ein Symbol am Rand gekennzeichnet.

28

Projektmanagement, -gestaltung, -kontrolle, Dokumenttypen

Die Beispiele

1

Einleitung

1.5

Das Pausenplan-Beispiel

Die »Realitätsnähe« wollen wir durch Beispiele aus unserer Projektpraxis herstellen. So haben wir immer wieder Entwürfe aus dem Banken- oder Krankenhausbereich beschrieben, die mit leichter Verallgemeinerung direkt aus einzelnen Projekten stammen. Auch hier verwenden wir entsprechende Symbole am Rand. In den Konstruktionsbeispielen des zweiten Teils verwenden wir die Programmiersprachen C++, Java und Smalltalk. Wie bereits gesagt, haben wir nicht die Absicht, das Programmieren in diesen Sprachen zu vermitteln. Der Leser soll nur einen Eindruck erhalten, wie Konstruktionen in der jeweiligen Sprache aussehen können. Die Notationen schließen sich dem De-facto-Standard an, der mit OMT begründet wurde und jetzt in der UML beschrieben ist. Wir haben uns weitgehend den Varianten angeschlossen, die in [Gamma et al. 96] verwendet werden, da wir davon ausgehen, daß die meisten Leser mit diesem Buch vertraut sind. Eine Beschreibung der Notationen unseres Handbuchs findet sich in Kapitel 5.2.7.

1.5

29

Die verwendeten Programmiersprachen und Notationen


Nach dem Gesetz sind Schulen dazu verpflichtet, für jede Pause, die länger als 5 Minuten dauert, Lehrer als Pausenaufsicht abzustellen.

1

Einleitung

1.5


30

Die Anzahl der Lehrer pro Pause hängt dabei von der Größe des zu beaufsichtigenden Gebäudes und des Schulhofes ab. Am Anfang eines jeden Schulhalbjahres wird vom einem Lehrer, dem Pausenplanersteller, für ein Schulhalbjahr der Pausenplan ausgearbeitet. Der Pausenplan legt die Pausenaufsicht auf Wochenebene fest. Dabei muß er berücksichtigen, wann Lehrer anwesend sind und in welchem Umfang sie beschäftigt sind. Ein Ausschnitt eines Pausenplans, der sich auf einen Pausenort bezieht, könnte so aussehen:

kleiner Schulhof

Mo

Di

Mi

Do

Fr

1. Pause

Langer

Schulze

Müller

Specht

Fröhlich

2. Pause

Fröhlich

Specht

Langer

Toller

Bunt

Für jeden Lehrer der Schule hat der Pausenplanersteller eine Lehrerkarte angelegt. Dies ist eine Karte, auf der die für die Pauseneinteilung benötigten Informationen wie Name, Kürzel, Ausschlußzeiten und Beschäftigungsgrad für jeden Lehrer zu finden sind.

1

Einleitung

1.6

Entstehung und Quellen

31

Der Pausenplanersteller ordnet diese Karten so auf einem leeren Pausenplan an, daß die von einem Lehrer angegebenen Kriterien (z.B. Ausschlußzeiten) und die allgemeinen Rahmenbedingungen (z.B., daß ein Lehrer nicht gleichzeitig zwei Pausenorte beaufsichtigen kann), berücksichtigt werden. Obwohl ein Pausenplan generell für ein Schuljahr gedacht ist, können sich z.B. durch Krankheiten und Versetzungen Änderungen ergeben, die einen neuen Pausenplan erfordern.

1.6


Das Handbuch ist aus einer mißlichen Lage entstanden. Mit [Kilberth et al. 94] haben wir ein Buch über den WAM-Ansatz vorgelegt, das dem Stand der Diskussion von vor 1994 entsprach. Mittlerweile hat sich einiges getan – worüber wir natürlich froh sind. Viele Entwurfsdiskussionen in den verschiedenen Kooperationsprojekten, neue Konstruktionsideen und veränderte technische Grundlagen haben auch auf den WAM-Ansatz abgefärbt. Allerdings haben wir in sehr unterschiedlichen Gruppen diskutiert und Erfahrungen ausgewertet. So kam es dann, daß »unsere« Studenten in ihren Studienarbeiten und Seminarvorträgen Dinge vorgestellt haben, zu denen wir leider

Motivation

1

Einleitung

1.6


sagen mußten, »Das ist aber Schnee von gestern«. Wenn sie dann ebenso freundlich konterten »Und wo steht, wie man das besser macht?«, konnten wir nur ziemlich betreten dreinschauen. Vieles war in der Form noch gar nicht aufgeschrieben, anderes war nur für den »Kenner« in einem Artikel angedeutet. Die Zeit war reif für ein neues Buch zu WAM. Und wenn schon, dann sollte es auch gleich ein richtiges Konstruktionshandbuch sein. Eine möglichst konkrete Anleitung also, wie interaktive Anwendungssoftware entworfen und konstruiert werden kann. In diesem Konstruktionshandbuch wollten wir unseren »Stand der Kunst« zusammentragen und damit begannen die Arbeit und die Probleme. Kaum hatten wir mit der Arbeit am Buch begonnen, merkten wir, daß sich im Laufe von wenigen Jahren doch einiges an Material und Ergebnissen angesammelt hatte. Das war die gute Nachricht. Die schlechte Nachricht war, daß dieses Material nicht in schön ausformulierter und ausgearbeiteter Form vorlag. Unsere Studenten hatten schon recht: Viel zu viele Dinge waren eher in unseren Köpfen als auf dem Papier. Die Menge des unaufbereiteten Materials war dann die eine Seite der Probleme. Die andere zeigte sich bei der Frage, wer das Handbuch denn wie schreiben sollte. Viele Personen hatten in ihren Projekten und Arbeiten wichtige Einzelergebnisse erzielt. Daher konnte dieses

32

Probleme

1

Einleitung

1.6


Handbuch nicht von einem Autor alleine geschrieben werden. Wir wollten andererseits vermeiden, daß sich das Buch wie ein Konferenzband als Sammlung loser Artikel präsentiert. In einigen Workshop- und E-Mail-Diskussionen haben wir dann das vorliegende Editionskonzept erarbeitet, das für die richtige Einschätzung des Handbuchs wesentlich ist:

33

Das Editionskonzept

Federführender Autor: Wir haben uns auf eine Liste von zentralen Themen geeinigt. Jedes Thema wurde von einer oder zwei Personen in der Rolle des federführenden Autors übernommen. Sie haben den Text inhaltlich zusammengestellt, teils selbst geschrieben und die Arbeit der anderen Autoren koordiniert. Ko-Autor: Jeder Ko-Autor hat substantiell zu dem Abschnitt oder Kapitel beigetragen, für den er aufgeführt ist. Hauptautor: Heinz Züllighoven hat alle Teile überarbeitet, in hoffentlich einheitlichem Stil formuliert und die Querbezüge hergestellt. Mit dieser etwas komplizierten und praktisch recht aufwendigen Einteilung hoffen wir, den verschiedenen Personen und ihren Beiträgen zur Entwicklung des WAM-Ansatzes gerecht geworden zu sein, ohne daß der Leser auf ein Buch »aus einem Guß« verzichten muß. Aber mit dieser Autorenregelung sind noch lange nicht alle »Quellen« des

1

Einleitung

1.6


34

WAM-Ansatzes und dieses Handbuchs erschlossen. Deshalb haben wir im folgenden die Personen aufgelistet, die durch ihre Publikationen und Ideen ihren Beitrag zu diesem Buch geleistet haben. Dirk Bäumer und Guido Gryczan haben durch ihre Dissertationen ([Bäumer 98, Gryczan 96]) wesentlich zur Weiterentwicklung des WAM-Ansatzes beigetragen.

Wesentliche Quellen

Wichtige Veröffentlichungen der letzten Jahre zum WAM-Ansatz: [Bäumer & Riehle 98], [Bäumer et al. 95a, b, c, 96a, b, 97], [Bürkle et al. 95], [Budde & Züllighoven 90], [Gryczan et al. 96, 97], [Krabbel et al. 96b, c, 97a, b], [Lilienthal & Züllighoven 96, 97], [Riehle 95b], [Riehle et al. 98], [Riehle & Züllighoven 95, 96], [Roock et al. 97], [Strunk & Fröse 96].

Veröffentlichungen

1

Einleitung

1.6


35

Die folgenden Studien- und Diplomarbeiten am Arbeitsbereich Softwaretechnik waren besonders einflußreich: Wolf-Gideon Bleek [Bleek 97] Boris Fittkau [Fittkau 98] Michael Gatzhammer, Valentino Kyriakides [Gatzhammer & Kyriakides 96] Thorsten Görtz [Görtz 98] Andreas Hartmann [Hartmann 98] Timm Krauß [Krauß 98] Sabine Ratuski [Ratuski 97] Dirk Riehle [Riehle 95a] Stefan Roock, Henning Wolf [Roock & Wolf 96, 98] Wolf Siberski [Siberski 95] Horst-Peter Traub [Traub 95] Ulfert Weiss [Weiß 97] Dirk Weske, Martina Wulf [Weske & Wulf 94, Weske 96, Wulf 95]

Studien- und

Wichtige Ideen haben beigetragen: Renate Gunesch (RWG, Stuttgart) KMU-Desktop Team (SBG, Zürich) Frank Schneider (RWG, Stuttgart) Herwig Scheidel (RWG, Stuttgart)

Ideen

Diplomarbeiten

1

Einleitung

1.6


36

Miriam Wicisk (Südwest-Landesbank, Stuttgart) Mareile Wilkens (Studentin am Arbeitsbereich Softwaretechnik, Universität Hamburg)

1

Einleitung

2

37

Grundlagen des Werkzeug & Material-Ansatzes

2


2.1

Das WAM-Objekt-Metamodell

Obwohl die Grundbegriffe der Objektorientierung heute vermeintlich schon zum selbstverständlichen Vorwissen jedes Softwareentwicklers gehören und es damit unnötig scheint, darüber einen Abschnitt in einem objektorientierten Konstruktionshandbuch zu schreiben, ist selbst für diese Grundbegriffe ein genaueres Hinsehen angebracht. Denn bereits in den Grundbegriffen unterscheiden sich die verschiedenen Autoren, was in einigen Methodenbüchern zu impliziten Annahmen über die Bedeutung der Grundbegriffe führt. Dies hat für die Leser dann die unangenehme Folge von Mißverständnissen und Unverständlichkeiten. Dem wollen wir vorbeugen. In diesem Kapitel erläutern wir insgesamt unser Verständnis der Konzepte, die dem WAM-Ansatz zugrunde liegen. Wir beginnen in diesem Abschnitt mit dem Objekt-Metamodell.

2

Federführung: Heinz Züllighoven Ko-Autor: Dirk Riehle, Wolf Siberski, Wolfgang Strunk


2.1


38

2.1.1 Objekt-Metamodell Die Objektorientierung stellt ein Begriffsgerüst für die Beschreibung 1 fachlicher und technischer Modelle zur Verfügung. Wie jedes Begriffsgerüst zur Modellierung umfaßt auch das objektorientierte Begriffsgerüst:

Was ist ein ObjektMetamodell?

❑ Elemente, ❑ Beziehungen, ❑ Eigenschaften der Elemente und ❑ Bildungsgesetze für die Modelle.

Besonders der letzte Punkt ist wichtig, da für eine saubere softwaretechnische Verwendung der Elemente die Bildungsregeln von großer Bedeutung sind. Sie geben uns eine Anleitung, wie wir die verschiedenen Elemente und Beziehungen bei der Modellierung verwenden sollen.

1.

Wenn wir im weiteren von technischen Modellen sprechen, meinen wir durchgängig softwaretechnische Modelle. Wenn wir die Modellierung technischer Systeme diskutieren, machen wir dies explizit.

2


2.1


39

Objekt-Metamodell: Ein Objekt-Metamodell beschreibt die Elemente und deren Verknüpfungen, die für die objektorientierte Modellierung zur Verfügung stehen. Zentrale Elemente sind Objekt und Klasse. Die Verknüpfungen sind die Benutzt-Beziehung und die Vererbung. Darüber hinaus werden Bildungsregeln festgelegt, die die Modellierung anleiten.

Ein zentrales Element unseres Objekt-Metamodells ist die Klasse. Sie hat bestimmte Eigenschaften, z.B. eine Schnittstelle mit zulässigen Operationen und eine verborgene Beschreibung von Attributen und Implementierungen von Operationen. Eine wesentliche Verknüpfung von Klassen ist die Vererbungsbeziehung. Auch diese hat wieder Eigenschaften: So erbt z.B. eine Unterklasse alle Attributbeschreibungen ihrer Oberklasse. Die Vererbung läßt sich als rein softwaretechnisches Konzept sehr unterschiedlich realisieren. Eine wichtige Bildungsregel unseres Objekt-Metamodells besagt, daß mit der Vererbung vor allem anwendungsfachliche Ober- und Unterbegriffe modelliert werden sollen. Daher ist in unserem Pausenplan-Beispiel der Pausenplanordner eine Spezialisierung des allgemeinen Konzepts Ordner.

2

Beispiel aus dem Objekt-Metamodell


2.1


In der Literatur findet sich gelegentlich der Begriff Objektmodell für das Begriffsgerüst, das wir als Objekt-Metamodell bezeichnen. Das ist nicht präzise und kann zur Verwirrung führen. Denn Objekte repräsentieren in unseren Anwendungsprogrammen ja zunächst die Konzepte und Gegenstände des Anwendungsbereichs. Wenn wir also von einem Objektmodell sprechen, dann meinen wir ein Modell der Objekte, die in einem Anwendungssystem unser anwendungsfachliches Modell darstellen. Sprechen wir über ein Objekt-Metamodell, dann beziehen wir uns auf ein Modell der Elemente, die wir bei der objektorientierten Modellierung überhaupt verwenden können. Wir reden also auf einer Metaebene darüber, welche Ausdrucksmöglichkeiten objektorientierte Modelle generell besitzen und nicht etwa über ein konkretes objektorientiertes Anwendungsmodell. Dies ist vergleichbar mit einer Abhandlung über die Grammatik der deutschen Sprache, in der wir über Substantive als Subjekte eines Satzes und die Regeln des Satzbaus reden. Etwas komplizierter wird diese Unterscheidung zwischen ObjektMetamodell und Objektmodell, wenn wir beides in einer Programmiersprache oder sogar in einem laufenden Programm zur Verfügung haben. Dies diskutieren wir in Kapitel 2.1.15. Wir betrachten die objektorientierte Anwendungsentwicklung im Rahmen dieses Buches aus dem Blickwinkel eines Softwaretechnikers

2

40 Was heißt Metamodell?

Wozu ein Objekt-Metamodell?


2.1


vor allem als Modellbildung (mehr zu Modellen in Kapitel 2.5). Der Kern des WAM-Ansatzes ist ja gerade, ausgehend von den Gegenständen und Begriffen des Anwendungsbereichs, ein fachliches und ein technisches objektorientiertes Modell zu erstellen und daraus ein objektorientiertes Programm abzuleiten. Dabei benötigen wir eine genaue Vorstellung davon, was die Grundbegriffe der objektorientierten Modellierung bedeuten und wie sie verwendet werden sollen. Nun kann natürlich die Frage aufkommen, weshalb wir uns diese Mühe machen, da doch jede Programmiersprache ein solches ObjektMetamodell praktisch realisiert. Dort sind die Elemente definiert und jedes Programm in dieser Sprache zeigt, was diese Elemente in ihrer Verwendung bedeuten. Doch mit den objektorientierten Sprachen ist das wie mit den Methodenbüchern: In den vergangenen Jahren haben wir in den verschiedenen Softwareprojekten nach dem WAM-Ansatz unterschiedliche objektorientierte (und konventionelle) Programmiersprachen eingesetzt. Wir haben festgestellt, daß jede Sprache ein mehr oder minder unterschiedliches Objekt-Metamodell realisiert. Daraus ergeben sich Möglichkeiten, die wir weder softwaretechnisch noch fachlich sinnvoll finden. Es hat sich bewährt, in den Projekten ein einheitliches Objekt-Metamodell zur Grundlage von Konventionen und Programm-Makros zu machen, um ein gemeinsames Verständnis von Modellierung und Programmierung zu erreichen.

2


41

2.1


Für das Objekt-Metamodell ergeben sich daraus Forderungen: Es muß so festgelegt werden, daß die fachlichen Konzepte des jeweiligen Anwendungsbereichs damit beschrieben werden können. Es muß nah genug an den Konzepten einer objektorientierten Programmiersprache definiert sein, damit ein fachliches Modell auch implementiert werden kann. Schließlich sollte die Verwendung eines Objekt-Metamodells softwaretechnische Qualitätsmerkmale wie Verständlichkeit und Veränderbarkeit fördern.

2.1.2 Klassifikation von Programmiersprachen Fragt man nach den unumstrittenenen Elementen eines Objekt-Metamodells, dann gehen wir von der mittlerweile gängigen Einteilung von Programmiersprachen [Wegner 90] aus. Wegner definiert ein dreistufiges Modell, bei dem jede Stufe die programmiersprachlichen Kennzeichen umfaßt, die eine Sprache auf dieser Ebene ausweist. Die Einteilung führt von objektbasiert über klassenbasiert bis zur letzten Stufe der objektorientierten Programmiersprachen (s. Abbildung 2-1). Als objektbasiert bezeichnet Wegner eine Sprache, in der Objekte als primäres Sprachmittel erzeugt und verwaltet werden können. Bei klassenbasierten Sprachen kommt zum Objektkonzept das Klassen-

2


42

2.1


konzept hinzu. Dies bedeutet, daß gleichartige Objekte in entsprechenden Klassen beschrieben werden können, die damit für die Erzeugung ihrer Objekte oder Exemplare zuständig sind. Schließlich ergänzt eine objektorientierte Sprache die Eigenschaften einer klassenbasierten um das Vererbungskonzept, das eine hierarchische Anordnung von Unter- und Oberklassen erlaubt. Diesen Klassenhierarchien muß ein entsprechendes polymorphes Typsystem zur Seite stehen, damit Objekte einer Unterklasse auch im Kontext einer Oberklasse, d.h. über einen so typisierten Bezeichner, angesprochen werden können. Im weiteren betrachten wir nur objektorientierte Sprachen. Ausgehend von dieser Einteilung werden wir die wesentlichen Elemente unseres Objekt-Metamodells ausführlicher beschreiben.

2


43

2.1


44 Abb. 2-1

objektbasiert

Objekte + Klassen

Objekte + Klassen + Vererbung

Klassifikation von Programmiersprachen nach Wegner

klassenbasiert

objektorientiert z.B. Ada (Packages) Modula (Modules)

z.B. Simula Smalltalk C++ Eiffel Beta Java

z.B. CLU Euclid Mesa

2.1.3 Objekt-Metamodell und softwaretechnisches Modell Ein Kennzeichen des WAM-Ansatzes ist, daß die Begriffe des softwaretechnischen Modells zu den Begriffen des Anwendungsbereichs in Beziehung gesetzt werden können. Abbildung 2-2 zeigt, wie die Elemente des fachlichen und des technischen Modells zusammenhängen. Durch die Prozesse von Generalisierung, Spezialisierung und Komposition entsteht ein auf den fachlichen Gegenständen und Konzepten

2


2.1


des Anwendungsbereichs beruhendes Begriffsmodell. Dieses Begriffsmodell läßt sich in ein softwaretechnisches Modell abbilden, das aus den Komponenten und Bezügen des Objekt-Metamodells besteht. Die Abbildung des Begriffsmodells in das softwaretechnische Modell erfolgt dabei weitgehend ohne Modellbruch, da die verwendeten Modellelemente beider Modelle struktur- und bedeutungsähnlich sind (vgl. [Kilberth et al. 94], [Jacobson 92]). Genau diese Ähnlichkeit ist aber eine zentrale Regel im ObjektMetamodell. So entsprechen die Modellelemente Begriff, Generalisierung, Spezialisierung, Komposition und Begriffshierarchie des Begriffsmodells den Modellelementen Klasse, Vererbung, Aggregation, Assoziation und Klassenhierarchie im Objekt-Metamodell. Gegenstände werden als Objekte, ihre Umgangsformen durch Operationen modelliert (vgl. Abbildung 2-2). Dieser Zusammenhang wird in diesem Abschnitt dadurch deutlich werden, daß wir den Elementen des Objekt-Metamodells eine fachliche und eine technische Interpretation geben. Detaillierter ausgearbeitet haben wir allerdings die softwaretechnische Seite des ObjektMetamodells, da wir uns im Hauptteil dieses Konstruktionshandbuchs auf die Gesichtspunkte konzentrieren, die für die Erstellung des softwaretechnischen Modells relevant sind. Trotzdem werden wir die fachliche Modellierung und den Zusammenhang von fachlichem und

2


45

2.1


46

technischem Modell auch in den weiteren Kapiteln immer wieder ansprechen (s. Kapitel 2.5 und 3.3). Im Vordergrund stehen diese Aspekte in [Kilberth et al. 94, Züllighoven 92]. Zusammenhänge im Objekt-Metamodell:

Abb. 2-2

fachliches Modell

softwaretechnisches Modell

Im Objekt-Metamodell

Gegenstand Umgangsform Begriff Generalisierung, Spezialisierung Komposition Begriffshierarchie

Objekt Operation Klasse Vererbung Aggregation, Assoziation Klassenhierarchie

festgelegte Zusammenhänge zwischen fachlichem und technischem Modell

2.1.4 Objekt Objekte entsprechen den für die Anwendung relevanten Gegenständen. Die Gegenstände sind charakterisiert durch ihre Umgangsformen, d.h. durch die Art und Weise, wie mit ihnen gearbeitet werden kann. Dabei unterscheiden wir folgende Leitfragen:

Fachliche Sicht auf Objekte

❑ Welche Information läßt sich an ihnen ablesen?

2


2.1


47

❑ Welche Veränderungen können an ihnen vorgenommen werden,

ohne daß sie zerstört oder in andersartige Gegenstände transformiert werden? Für »aktive« Objekte läßt sich dies so formulieren: Welche Aktionen können an ihnen ausgelöst werden? Objekte kapseln die fachlich zusammengehörigen Umgangsformen und Informationen und bieten diese nach außen in einem Satz von Operationen an. In Abbildung 2-3 haben wir dies an einem Pausenplanordner aus unserem Pausenplan-Beispiel (s. Kapitel 1.5) illustriert. Abb. 2-3 Fachlich-objektorientierte Beschreibung eines Pausenplanordner – Pausenplan entnehmen – Pausenplan einfügen – mit Text beschriften – Pausenplan auswählen – das Register aufschlagen – voll? ...

Softwaretechnisch besteht eine objektorientierte Anwendung zur Laufzeit aus Objekten. Jedes Objekt besitzt ein Verhalten, einen Zustand und eine Identität. Das Verhalten ist durch die Menge der

2

Ordners

Softwaretechnische Sicht auf Objekte


2.1


zulässigen Operationen festgelegt; der Zustand durch den individuellen Speicherbereich jedes Objekts. Die Identität ist im Laufzeitsystem gegeben und muß nicht vom Programmierer konstruiert werden. Die Struktur und das Verhalten gleichartiger Objekte sind in ihrer gemeinsamen Klasse definiert (vgl. [Meyer 97]). Dort ist auch festgelegt, welche Merkmale eines Objekts sichtbar und welche verborgen sind. Softwaretechnisch stellt sich die Frage, in welchem Umfang die Kapselung der Merkmale eines Objekts von der verwendeten Sprache unterstützt wird. So ist es z.B. in C++ bei entsprechender Deklaration möglich, von außen auf die Struktur eines Objekts zuzugreifen; in Smalltalk können keine Operationen vor dem Aufruf durch Klienten geschützt werden. Jedem Objekt ist ein Typ zugeordnet. In den meisten statisch typisierten objektorientierten Programmiersprachen (wie C++) ist der Typ durch die Klassenzugehörigkeit festgelegt.

2

48

Sichtbarkeit und Kapselung

Klasse und Typ


2.1


49

Objekt: Die konkreten oder ideellen Gegenstände der täglichen Arbeit bilden den Ausgangspunkt, um eine Anwendung in Objekten zu modellieren. Objekte kapseln Daten und Operationen zu einer Programmkomponente. Sie sind die Einheiten des laufenden Softwaresystems. Ein Objekt ist systemweit eindeutig identifizierbar und hat einen Zustand, der in einem privaten Speicherbereich des Objekts repräsentiert ist. Dem Objekt sind Operationen zugeordnet, die Informationen über das Objekt liefern und den Zustand des Objektes verändern können. Der Zustand eines Objektes kann nur mit Hilfe dieser Operationen gelesen oder verändert werden. Operationen werden über passende Botschaften an das jeweilige Objekt aktiviert. Die von außen sichtbaren Operationen eines Objekts bilden die Schnittstelle. Diese Operationen sind über ihre Signatur bekannt. Im Rahmen eines Vertrages (s. Kapitel 2.1.10) können Zusicherungen über das Verhalten eines Objekts an der Schnittstelle gemacht werden.

Jedes Objekt muß zur Laufzeit explizit erzeugt werden. Dies geschieht durch den Aufruf einer Erzeugungsoperation einer Klasse. Beim Erzeugen werden Objekte im Speicher angelegt, evtl. initialisiert und

2

Erzeugung eines Exemplars


2.1


an einen Bezeichner gebunden. Ein Objekt ist durch seine Erzeugung 2 Exemplar einer Klasse, solange es »lebt«. Auch der Typ eines Objekts bleibt über die gesamte Lebenszeit gleich. Um ein Objekt im Programm verwenden zu können, muß es über eine Referenz an einen Bezeichner gebunden werden. Dieser Bezeichner erhält (in statisch typisierten Sprachen) durch Deklaration einen Typ, auch statischer Typ genannt. Zur Laufzeit können aufgrund der Polymorphie durch Zuweisung oder Parameterübergabe auch Objekte eines Subtyps an einen entsprechenden Bezeichner gebunden werden. Man spricht dabei auch vom dynamischen Typ eines Bezeichners.

2.

50

Bezeichner, statischer und dynamischer Typ

Der englische Ausdruck für »Exemplar« ist »instance«. Im deutschen Entwicklerjargon finden wir aber häufig die sinnentstellende Übersetzung »Instanz«.

2


2.1


51

Statischer und dynamischer Typ eines Bezeichners: Bei der Deklaration wird der statische Typ eines Bezeichners im Programmtext festgelegt. Durch Zuweisung oder Parameterübergabe können zur Laufzeit Objekte an einen Bezeichner gebunden werden. In statisch typisierten Sprachen können dies Objekte des statischen Typs oder konformer Subtypen sein. Diese legen den dynamischen Typ des Bezeichners fest.

Objekte sind direkte Exemplare ihrer erzeugenden Klasse. Daher besitzen Objekte zur Laufzeit die in der Klasse festgelegte Struktur von Attributen (auch Felder genannt). Die Attribute können Werte (s. Kapitel 2.1.14) und Referenzen auf andere Objekte enthalten. Die jeweilige Belegung der Attribute mit Werten und Referenzen definiert den Zustand eines Objekts. Der Zustand eines Objekts ist vor dem äußeren Zugriff geschützt (s. S. 29) und kann nur über Operationen der Schnittstelle sondiert oder verändert werden. Jede für ein Objekt deklarierte Operation legt den Namen der Operation, die Argumentobjekte und die Rückgabeobjekte fest. Alle zusammen bilden die Signatur der Operation. Die Menge aller Signaturen der öffentlichen, d.h. von außen sichtbaren Operationen eines

2

Zustand

Schnittstelle, Sichtbarkeit


2.1


52

Schnittstelle

{

Abb. 2-4 Schnittstelle eines Objekts als Menge aller Signaturen

Operation1 Rückgabeobjekte

Signatur

Operationsname

Argumentobjekte

Objekts bildet seine Schnittstelle (Interface, vgl. Abbildung 2-4). Daneben gibt es auch eine »interne« Schnittstelle, die nur dem Objekt selbst zugänglich ist (s. S. 32).

Operation2

...

OperationN

Die Schnittstelle eines Objekts legt seine Dienstleistungen (Services) fest. Wir fordern, daß ein Objekt einen Satz fachlich motivierter Dienstleistungen anbieten soll. Die an der Schnittstelle angebotenen Dienstleistungen eines Objekts werden intern oft so realisiert, daß Dienstleistungen von anderen assoziierten, d.h. referenzierten Objekten in Anspruch genommen werden. In diesem Zusammenhang

2

Dienstleistungen


2.1


spricht man auch von einem Call-In und einem Call-Out-Interface (vgl. [Luckham et al. 95]). Daraus ergibt sich eine grundlegende Interpretation der Benutzt-Beziehung zwischen Objekten: Ein Objekt bietet 3 als Anbieter Dienstleistungen an, die ein anderes Objekt als Klient verwendet. Ein Objekt kann gleichzeitig Anbieter und Klient für andere sein (s. Abbildung 2-5).

3.

In der Literatur heißt es statt »Klient« oft »Kunde«. Da wir hier häufig über Kunden von Banken sprechen, übersetzen wir »client« stets mit »Klient«.

2


53

2.1


Abb. 2-5

Anbieter

Klient

54 Objekte als Anbieter und

benutzt

Dienstleistung Dienstleistung

Klienten Referenz

Dienstleistung

Klient

Anbieter Dienstleistung

Begrifflich und konzeptionell müssen wir zwischen der Schnittstelle eines Objekts und dem Aufruf der Dienstleistungen dieser Schnittstelle unterscheiden. Wir nennen die Elemente der Schnittstelle abstrahierend Operationen, d.h. ausführbare Arbeitsschritte oder Tätigkeiten, die einem Computer übertragen wurden. Programmiersprachlich werden diese

2

Operation, Botschaft, Nachricht, Routine, Prozedur, Funktion


2.1


Operationen durch die jeweiligen Sprachkonstrukte realisiert. Diese heißen dann Prozeduren, Methoden oder Routinen. Der Aufruf einer Operation wird oft auch als das Senden einer Botschaft oder Nachricht an das gerufene Objekt dargestellt. Dabei umfaßt die Botschaft den Bezeichner des Objekts (als dem Adressaten), den Namen der Operation und die Aufrufparameter. Wird Polymorphie verwendet, dann wird die jeweilige Operation mit ihrer konkreten Implementatierung erst zur Laufzeit ausgewählt. Dies nennt man spätes oder dynamisches Binden (late oder dynamic binding). Objekte haben, wie gesagt, einen Zustand. Dieser kann verändert und sondiert werden. Nicht jede Veränderung ist fachlich und technisch zu jedem Zeitpunkt möglich, sondern ist abhängig vom konkreten Zustand des Objekts. Um diese Zusammenhänge im fachlichen und technischen Modell geeignet zu verdeutlichen, ist es sinnvoll, schon die Beschreibung fachlicher Objekte wie folgt einzuteilen (vgl. Abbildung 2-6): ❑ Anweisungen (im Sinne von Befehlen, Aktionen), die den

Zustand des Objekts verändern. (Daraus werden dann technisch die Prozeduren.) ❑ Anfragen, die Informationen über das Objekt in Form fach-

licher Ergebnisobjekte liefern. (Dies führt technisch zu Funktionen).

2


55

2.1


56

❑ Tests sind eine spezielle Form von Anfragen, die den fachlichen

Zustand des Objekts prüfen und eine Ja/Nein-Antwort liefern. (Dies werden die in Zusicherungen verwendeten Prädikate.) Pausenplan-Ordner

Abb. 2-6 Einteilung einer

füge Pausenplan ein

Schnittstelle in

beschrifte mit Text

Anweisungen, Anfragen

Anweisung Anfrage Test

und Tests

gib Beschriftung ist voll?

Diese Einteilung muß technisch sinnvoll umgesetzt werden: ❑ Prozeduren verändern den (von außen sichtbaren) Zustand

eines Objekts. Diese Zustandsveränderung muß nicht zu jedem Zeitpunkt zulässig sein. Sie ist meist abhängig vom vorliegenden Zustand eines Objekts. ❑ Funktionen liefern Ergebnisobjekte, ohne den von außen sicht-

baren Zustand des Objekts zu verändern, d.h., eine Funktion liefert bei gleichbleibendem Zustand und unveränderten Argumenten immer das gleiche Ergebnis. Eine Funktion kann par-

2


2.1


57

tiell sein, d.h., sie liefert nur für bestimmte Argumente und Objektzustände ein Ergebnis. ❑ Prädikate sondieren den Zustand eines Objekts und liefern ein

Boolesches Ergebnis. Sie verändern den Zustand nicht und sind zu jedem Zeitpunkt aufrufbar. Wir unterscheiden Prozeduren, Funktionen und Prädikate konzeptionell und nicht anhand der syntaktischen Einteilung einer Signatur in Eingabe-, Ein-/Ausgabe- und Ergebnisparameter. Trotzdem ist es für die Lesbarkeit und das Verständnis wichtig, inwieweit diese Unterscheidung von der Programmiersprache unterstützt wird. So hat in C++ jede Operation die syntaktische Form einer Funktion und es gibt (bisher) keinen Basistyp Boolean. Auch in Smalltalk liefert jede Operation ein Ergebnisobjekt. Bei den Prozeduren und Funktionen haben wir festgestellt, daß sie vielfach nicht für jeden Zustand eines Objekts aufgerufen werden können. Dahinter steht ein bestimmtes Benutzungs- oder Zustandsmodell eines Objekts. Dieses kann explizit (z.B. als endlicher Zustandsautomat) oder nur implizit gegeben sein. Wir sprechen in diesem Zusammenhang von dem Protokoll eines Objekts. Damit ist dann nicht nur eine Menge von Signaturen definiert, sondern auch eine bestimmte Reihenfolge, in der abhängig vom Zustand eines Objekts die Operationen

2

Protokoll


2.1


58

dieses Protokolls gerufen werden müssen. Dieser Protokollbegriff ist dem Bereich der verteilten Systeme entlehnt. Dort beschreibt er in vergleichbarer Weise das Zusammenspiel zwischen zwei Partnerinstanzen, die in unserem Sinne ein Bündel von Dienstleistungen erbringen sollen (vgl. [Mühlhäuser 97]). Allerdings gibt es in gängigen objektorientierten Programmiersprachen bis auf die Zusicherungen von Eiffel keine Möglichkeit, ein Protokoll an der Schnittstelle zu repräsentieren. Protokoll: Unter dem Protokoll eines Objekts verstehen wir eine Menge von Regeln, festgelegten Abläufen oder Operationsaufrufen, die von einem Klienten befolgt werden müssen, damit das Objekt bestimmte Dienstleistungen erbringen kann. Um ein Protokoll einhalten zu können, muß mindestens die entsprechende Schnittstelle bekannt sein.

Gelegentlich wird in der Literatur über Objektorientierung auch Protokoll mit Schnittstelle gleichgesetzt. Während die Schnittstelle eines Objekts festlegt, welche Operationen und ggf. Attribute dieses Objekts von außen sichtbar sind, bedeu-

2

Kapselung, Geheimnisprinzip


2.1


tet Kapselung, daß auf alle nicht explizit exportierten Eigenschaften von außen nicht direkt zugegriffen werden kann. Kapselung dient in objektorientierten Sprachen wesentlich dazu, die konkrete Repräsentation des Zustands eines Objekts, d.h. seine Struktur, zu verbergen. Dieses Konzept bezeichnet man auch als Geheimnisprinzip (Information Hiding, s. [Parnas72]). Die Klienten eines Objekts sind nur noch von den Elementen der Schnittstelle abhängig; die Implementation kann geändert werden, ohne daß dadurch die Konsistenz des Objekts aus Sicht des Kunden verlorengeht. Zu dem Konzept der Kapselung zählt weiterhin, daß den Klienten zwar die Signatur einer Operation bekannt ist und im Vertragsmodell (s. Kapitel 2.1.10) Aussagen über das Verhalten der Operation an der Schnittstelle eines Objekts gemacht werden, die Implementation aber komplett verborgen bleibt. Unter diesem Gesichtspunkt sollten Veränderungen der Implementation so erfolgen, daß sie sich nicht auf das von außen erkennbare spezifizierte Verhalten auswirken. Der Begriff der Identität eines Objekts ist deutlich vom Begriff der Adressierbarkeit zu trennen. Mit der Adressierbarkeit wird erreicht, daß auf ein Objekt evtl. von verschiedenen Kontexten aus zugegriffen werden kann (was dann zu den Problemen des sog. dynamischen Alias [Meyer 97] führen kann). Adressierbarkeit ist eine externe Objektqualität, die kontextabhängig ist.

2

59

Objektidentität, Adressierbarkeit


2.1


Das Konzept der Identität ermöglicht es, ein Objekt eindeutig identifizieren zu können, unabhängig von dem Weg, über den das Objekt erreichbar ist. Identität bedeutet zunächst technisch, daß auf programmiersprachlicher Ebene eindeutig festzustellen ist, ob zwei Bezeichner auf dasselbe Objekt verweisen oder »nur« auf zwei Objekte mit gleichem Zustand. Damit ist Identität eine »innere Objektqualität«, d.h., sie gehört zum Objekt, unabhängig von seinem Kontext und der Art und Weise, wie die Struktur und die Operationen eines Objekts definiert sind. Darüber hinaus müssen wir aber zu einem Konzept der fachlichen Identität kommen. Diese fachliche Identität muß unabhängig von der technischen gesehen werden. Zwei Objekte mit unterschiedlicher technischer Identität können fachlich betrachtet sehr wohl für eine Identität stehen: So kann ein Bankkunde in einem Kontext ein Kreditnehmer sein, an anderer Stelle aber als Depotbesitzer geführt werden. Trotz des im jeweiligen Kontext unterschiedlichen Verhaltens muß die Identität der dahinterstehenden Person gewährleistet sein. Der Entwickler muß also ausdrücken können, was er unter Identität versteht und wie sich diese Identität zur Gleichheit verhält: Meint er Wertgleichheit, gleiches Verhalten von Objekten oder zielt er auf die fachliche Identität eines Gegenstands. Die fachliche Identität kann dabei keine globale Eigenschaft eines Objekts sein; sie kann nur in Abhängigkeit vom

2


60

2.1


Anwendungsbereich sinnvoll modelliert werden. Eine mögliche konstruktive Lösung für dieses Problem stellen wir in Kapitel 3.3.4 vor.

2.1.5 Klasse Ausgehend von gemeinsamen Umgangsformen bestimmen wir in der fachlichen Modellierung Ähnlichkeiten von unterschiedlichen Gegenständen. Diese Gemeinsamkeit drücken wir abstrahierend in einem Begriff und dem dahinterstehenden Konzept aus. Begriffe lassen sich generalisieren oder spezialisieren. So entstehen Begriffshierarchien. Sie bilden als Teil der jeweiligen Fachsprache die Grundlage zur Zusammenarbeit zwischen den beteiligten Gruppen und fördern das Verständnis eines Anwendungsbereichs. Im Rahmen unseres Objekt-Metamodells haben wir die konkreten Gegenstände durch Objekte repräsentiert. So wie die Gegenstände »auf den Begriff« gebracht werden, modellieren Klassen unter einem fachlichen Gesichtspunkt die Abstraktion von gleichartigen Objekten und stellen dadurch eine eindeutige Beziehung zwischen fachlichen Konzepten und softwaretechnischen Komponenten dar.

2


61

2.1


Klasse: Fachlich modellieren Klassen die Konzepte und Begriffe, die hinter den Gegenständen der täglichen Arbeit stehen. Eine Klasse ist damit, auf der Basis gemeinsamer Umgangsformen von verschiedenen fachlichen Gegenständen, eine Abstraktion von gleichartigen Objekten. Die Gemeinsamkeiten zwischen Begriffen werden sprachlich als Oberbegriff aufgefaßt. Solche Generalisierungen oder Begriffshierarchien bilden als Teil der jeweiligen Fachsprache die Grundlage zur Zusammenarbeit und fördern das Verständnis eines Anwendungsbereichs. Begriffshierarchien werden durch Unter- und Oberklassen modelliert. Technisch beschreibt eine Klasse als Programmtext die prinzipiellen Eigenschaften der Objekte, die sie erzeugen kann. Diese Eigenschaften umfassen die Schnittstelle der Objekte und deren interne Realisierung durch Algorithmen und Datenstrukturen. Eine Klasse definiert also das Erzeugungs- und Verhaltensmodell ihrer Exemplare. Ein Objekt ist immer Exemplar genau einer Klasse.

Technisch sind Klassenbeschreibungen die wesentlichen Bestandteile eines objektorientierten Programmtextes. Eine Klasse ist definiert durch ihren Namen, ihre Vererbungsbeziehung zu ihren Oberklassen und durch eine Menge von Merkmalen, d.h. Operationen und Attri-

2


62

2.1


buten (s. Abbildung 2-7). Von außen gesehen reduzieren sich die Merkmale auf die Elemente der Schnittstelle, d.h. der sichtbaren und verwendbaren Signaturen. Eine Klasse definiert, wie sich die Exemplare der Klasse verhalten können. Zudem ist in einer Klasse meist festgelegt, wie die Exemplare der Klasse erzeugt und initialisiert werden. Klassen bilden demnach die »Erzeugungs- und Verhaltensmodelle« für Objekte. Jedes erzeugte Objekt unterscheidet sich von allen anderen Exemplaren der Klasse durch einen eigenen Speicherbereich. Im Beispiel von Abbildung 2-7 ist dies der Verweis auf die jeweilige Liste der Pausenpläne PlanList.

2


63

2.1


64

Klasse Pausenplanordner Pausenplanordner B

füge Pausenplan ein beschrifte mit Text

füge Pausplan ein beschrifte mit Text

IF PlanList.empty THEN PlanList.add(Pausenplan)



… PlanList

PlanList: LIST [Pausenplan] Pausenplanordner A füge Pausenplan ein beschrifte mit Text

PlanList


Abb. 2-7

Kapselung schützt die interne Repräsentation eines Objekts vor nichtintendiertem Gebrauch. Der Verweis auf das Objekt mit dem Bezeichner PlanList in Abbildung 2-7 ist Objekten der Klasse Pausenplanordner von außen nicht anzusehen; er gehört zur internen Repräsentation. Nun finden wir in der Literatur und in Programmierumgebungen immer wieder die Technik, zu jedem Attribut einer Klasse eine lesende

2

Klassen beschreiben Schnittstelle und Repräsentation ihrer Exemplare Generische Operationen


2.1


und eine schreibende Operation bereitzustellen. Diese Operationen nennt man auch generische Operationen (was nicht mit »generischen Bausteinen« oder »Generizität« verwechselt werden sollte). Auf den ersten Blick brechen diese generischen Operationen an der öffentlichen Klassenschnittstelle das Geheimnisprinzip, da sie die interne Struktur eines Objekts zumindest teilweise bekanntmachen. Zudem zerstören sie leicht die fachliche Konsistenz eines Objekts. Generell raten wir also von der Verwendung solcher generischer Operationen ab. Nehmen wir z.B. eine Klasse Konto. Die generischen Operationen wären setzeSaldo und gibSaldo. Der Entwickler der Klasse wird große Schwierigkeiten haben, mit diesen Operationen den bankfachlichen Umgang mit einem Konto zu realisieren. Verwendet er statt dessen einzahlen, auszahlen und gebuehrenBerechnen, kann er fachlich festlegen, unter welchen Bedingungen ein Saldo verändert werden darf.

2


65

2.1


Generische Operationen: Häufige Bezeichnung für das Paar von Schreibe- und Lese-Operationen (set und get) für jedes Attribut einer Klasse. Generische Operationen werden in grafischen interaktiven Programmierumgebungen (z.B. VisualAge) verwendet, um Anwendungsobjekte für grafische Oberflächenelemente »zugänglich« zu machen. Ähnliches gilt oft für datenbankbasierte Anwendungssoftware.

Allerdings kann es im Rahmen des WAM-Ansatzes durchaus generische Operationen geben, wenn sie an der internen Schnittstelle verwendet werden. Interne Schnittstelle einer Klasse: Unter der internen Schnittstelle einer Klasse verstehen wir die sog. Vererbungsschnittstelle, die nur für Unterklassen einer Oberklasse, aber nicht für Klienten gedacht ist. In vielen Sprachen kann diese interne Schnittstelle durch ein Sprachkonstrukt in ihrer Sichtbarkeit vor Klienten geschützt werden (z.B. durch protected in C++).

2


66

2.1


Softwaretechnisch hat es sich bewährt, alle sondierenden und zustandsverändernden Operationen mit Hilfe der generischen Operationen zu implementieren. Dies gilt für Operationen der eigenen Klasse und aller Unterklassen. Die generischen Operationen werden jeweils in der Klasse definiert, die das entsprechende Attribut einführt. Damit stellt sich die Frage, ob diese generischen Operationen durch die Mechanismen der Programmiersprache als interne Schnittstellen geschützt werden können. Während z.B. C++ hierfür ein eigenes Sprachkonstrukt (protected) anbietet, kann dies in Smalltalk nur durch entsprechende Kategorien und damit verbundene Programmierkonventionen umgesetzt werden. Im Beispiel von Abbildung 2-8 bietet die Klasse Notiz die Operation numeriere mit einem Parameterobjekt der Klasse Nummer an. Intern verwendet diese Operation die generische Operation setze_nr, um das gekapselte Attribut nr vom Typ INTEGER zu setzen. Dadurch wird eine Form von Datenabstraktion im Binnenverhältnis von Klassen eingeführt. Dieser Ansatz kann zu einer weitergehenden Abstraktion eingesetzt werden. So lassen sich generische Operationen als Schablonenoperationen in Oberklassen abstrakt definieren, deren Attribute erst in Unterklassen hinzugefügt werden.

2


67

2.1


Abb. 2-8

einer Klasse

public numeriere (Nummer n) { ... setze_nr (nr); ... } } // class Notiz

gib_nr

(int n) {...} int {...} (String a) {...} String {...}

der internen Schnittstelle

setze_nr

setze_nr gib_nr : setze_an gib_an :

Generische Operationen an

numeriere

public class Notiz { private int nr; private String an; protected protected protected protected

68

Im Zusammenspiel von Objekt und Klasse gibt es einige Operationen, die den Lebenszyklus eines Objekts begrenzen und als »kritische Situationen« für Modellierung und Konstruktion gelten:

Der Lebenszyklus von Objekten

❑ Erzeugen, ❑ Löschen, ❑ Transformieren in ein anderes Objekt.

2


2.1


Alle diese Operationen sind konzeptionell nicht dem Objekt selbst zuzuordnen, da ein Objekt sich selbst weder erzeugen, löschen noch (auf einfache Art und Weise) in ein anderes transformieren kann. Diese Operationen gehören auf eine Metaebene (s. Kapitel 2.1.15). In Programmiersprachen, in denen Klassen selbst als Objekte im System verfügbar sind, wird das Erzeugen meist als Klassenoperation realisiert, d.h., zu jeder Klasse gibt es mindestens eine Operation (Konstruktor), die Exemplare dieser Klasse erzeugen kann. In Compilersprachen, in denen Klassen nicht als Objekte repräsentiert sind, wird Code für die Objekterzeugung vom Compiler generiert und die eigentliche Instanziierung wie üblicherweise vom Laufzeitsystem übernommen. Die erzeugende Prozedur wird dabei meist als eine ausgezeichnete Operation innerhalb des Klassentextes definiert. Vielfach bewährt es sich, neben der erzeugenden Operation noch eine weitere Operation zu implementieren, die das Objekt in einen initialen Zustand versetzt. Diese Initialisierungsoperation kann beim Erzeugen und bei Bedarf während der weiteren Lebenszeit des Objekts aufgerufen werden. Wenn wir das Benutzungsmodell (s. Kapitel 2.2, S. 71) eines interaktiven Systems entwerfen, müssen wir ebenfalls klären, wie Objekte erzeugt werden können. Dem Benutzer muß klar sein, wie und wo er neue fachliche Exemplare als Arbeitsmittel oder -gegenstand erhalten kann. Es hat sich bewährt, neue Materialien mit Hilfe von Werkzeugen

2

69

Erzeugen von Objekten


2.1


oder fachlichen Behältern (z.B. Formularordnern) zu erzeugen. Werkzeuge können selbst über Werkzeugschränke oder Werkzeugverwalter erzeugt werden. Das Löschen legt technisch fest, wie ein Objekt aus dem Laufzeitspeicher entfernt wird. Dies ist in objektorientierten Systemen zweistufig zu betrachten:

70

Löschen von Objekten

❑ Ein Objekt ist an keiner Stelle des Anwendungssystems mehr

referenziert; es kann damit im Anwendungssystem nicht mehr 4 erreicht werden . ❑ Ein Objekt wird vom Heap gelöscht. Dies kann, soweit vorhan-

den, vom Garbage Collector übernommen werden, wenn das Objekt nicht mehr referenziert wird. Sonst muß das Löschen explizit programmiert werden. Dabei sind Probleme wie Lost Object, Dangling Pointer und die richtige Reihenfolge beim Löschen abhängiger Objekte zu beachten (vgl. [Sebesta 96]).

4.

Wir gehen an dieser Stelle nicht auf die Problematik von Objekten ein, die in einer Datenbank gespeichert sind und dort als Ergebnis von Anfragen erreichbar sind.

2


2.1


Neben diesen technischen Aspekten stellt sich wie beim Erzeugen die Frage, welches fachliche Bild sich ein Benutzer vom »Löschen« eines Gegenstandes machen kann. Wir erkennen schnell, daß zwischen der technischen und fachlichen Sicht hier ein deutlicher Unterschied sein kann. Damit ein Benutzer aber einfach ausdrücken kann, daß er für einen Gegenstand keine Verwendung mehr sieht, empfehlen wir wieder, einen expliziten »Platz« für das fachliche Löschen vorzugeben, etwa in einem Werkzeug oder einem fachlichen Behälter (z.B. Papierkorb). Ein Benutzer erstellt einen Pausenplan mit einem entsprechenden Werkzeug und legt ihn in einen Pausenplanordner. Dann beendet er das Werkzeug. Im Benutzungsmodell geht er davon aus, daß sowohl der Pausenplan als auch das Werkzeug noch für die weitere Arbeit zur Verfügung stehen. Technisch können aber in dieser Situation nach dem Sichern des Pausenplans und der Werkzeugeinstellung in einer Datenbank beide Objekte aus dem Laufzeitsystem gelöscht werden. Wirft er aber eine alte Arbeitskopie des Pausenplans in den Mülleimer und leert ihn auch aus, dann drückt er damit aus, daß er keine Verwendung mehr für diesen Plan hat. Der Zeitpunkt des tatsächlichen technischen Löschens kann dann z.B. auf das Herunterfahren des Systems verschoben werden. Das Transformieren überführt ein Objekt in ein anderes. Dies ist meist dann der Fall, wenn ein Gegenstand so bearbeitet wird, daß er

2

71

Transfomieren von Objekten


2.1


durch eine bestimmte Handlung seinen »Charakter« verändert. Für die Beteiligten ist dabei klar, daß jetzt ein »anderer« Gegenstand vorliegt. Ein Bankberater bereitet ein Kundengespräch vor, indem er ein Antragsformular über einen Kleinkredit mit Kundendaten ausfüllt. Im Kundengespräch werden die restlichen Kreditdaten ins Formular eingetragen. Dann wird das Formular ausgedruckt, und der Kunde, der Bankberater sowie ein zweiter Bankberater zeichnen den Ausdruck ab. Damit ist für die Beteiligten aus dem Antragsformular ein Vertrag geworden. Der Bankberater wählt im Formulareditor die Aktion »Vertrag unterschrieben«. An diesem Vertragsobjekt darf nun nichts mehr verändert werden. Diese fachlich meist begründbare Überführung eines Gegenstands in einen anderen ist objektorientiert nicht einfach nachzuvollziehen. Technisch bedeutet dies oft, daß das Objekt seine Klassen- und Typzugehörigkeit wechseln muß. In stark typisierten objektorientierten Sprachen wird dies nicht unterstützt. Ein Klassenwechsel wird technisch meist so erreicht, daß zunächst ein neues Exemplar der »Ziel«-Klasse erzeugt wird, dann die benötigten Werte aus dem alten Objekt in das neue übertragen werden und anschließend das alte Objekt gelöscht wird. Diese einfache Lösung ist nicht unproblematisch, da mit der technischen leicht auch die fachliche Identität des ursprünglichen Objekts verlorengehen kann.

2

72

Klassenwechsel


2.1


Eine Alternative zum Klassenwechsel ist die Verwendung unterschiedlicher Umhüller um einen »Objektkern«. Eine aufwendigere Technik stellen wir für das Modellieren von Rollen in Kapitel 3.3.4 vor. Diese Rollen um ein Kernobjekt können dann z.B. »Vertrag« und »Formular« sein.

2.1.6 Vererbung Die Vererbungsbeziehung ist technisch ein wesentliches Merkmal, das objektorientierte Sprachen von konventionellen unterscheidet. Mit ihr lassen sich Klassenbeschreibungen zu hierarchischen Strukturen anordnen. Im Rahmen des WAM-Ansatzes drücken wir durch Vererbung fachliche Begriffshierarchien, also Generalisierung und Spezialisierung, aus. Vererbung bedeutet technisch zunächst, daß alle Beschreibungen der Oberklasse für die Unterklassen gelten. Damit ist die Vererbungseinheit die Klasse. In ihr wird statisch festgelegt, von welchen Oberklassen sie erbt. Die Vererbungsbeziehung bleibt zumindest in statisch typisierten Sprachen während der Laufzeit unveränderlich. In einer Unterklasse können Beschreibungen einer Oberklasse spezialisiert werden. Dabei werden Operationen

2


73

2.1


❑ implementiert (man spricht auch von definiert), die in einer der

Oberklassen nur spezifiziert sind; ❑ redefiniert, wenn eine neue Implementation in der Unterklasse

eine vorliegende Implementation in einer Oberklasse ersetzt (überschreibt, verdeckt); ❑ hinzugefügt, wenn noch keine namensgleiche Operation in

einer Oberklasse existiert.

2


74

2.1


Vererbung: Die Vererbungsbeziehung organisiert Klassen fachlich in hierarchischen Strukturen. Dadurch lassen sich Begriffsgebäude von Generalisierungen und Spezialisierungen modellieren. Technisch erleichtert Vererbung die Wiederverwendung von Klassen. Alle Beschreibungen einer Oberklasse sind im Rahmen der Vererbung zunächst auch Beschreibungen der Unterklassen selbst. Eine Unterklasse modifiziert die geerbten Merkmale: ❑ geerbte Operationen können redefiniert oder implementiert werden, ❑ Attribute (Speicherstrukturbeschreibungen) und Operationen können neu hinzugefügt werden, ❑ Zugriffsrechte für die Merkmale können verändert werden. Sind Vererbungshierarchien baumförmig, d.h. hat eine Klasse nur eine direkte Oberklasse und beliebig viele Unterklassen, dann sprechen wir von Einfachvererbung. Hat eine Klasse mehr als eine direkte Oberklasse, sprechen wir von Mehrfachvererbung.

Vererbung läßt sich als ein Mechanismus zur Wiederverwendung von Spezifikationen und Code betrachten. In Simula 67 heißt sie auch

2


75

2.1


Program Concatenation. In Verbindung mit dem entsprechenden Typsystem ist Vererbung auch die Grundlage der Polymorphie. Die unterschiedliche Art und Weise der Verwendung entscheidet darüber, was Vererbung fachlich und softwaretechnisch bedeuten kann. Zunächst gibt es eine schon lange andauernde Diskussion über Einfach- und Mehrfachvererbung. Diese wird von Sprachentwicklern gelegentlich mit fundamentalistischem Eifer geführt und in der jeweiligen Sprache festgeschrieben. So erlauben Sprachen wie Smalltalk, Java oder Beta nur Einfachvererbung, während Eiffel und C++ Mehrfachvererbung besitzen. Wir gehen pragmatisch davon aus, daß im Rahmen der fachlichen Modellierung von Konzepten und Begriffen durchgängig Einfachvererbung eingesetzt werden sollte. Dies fördert die Klarheit der Begriffsbildung. Baumförmige Begriffsgebäude sind nun einmal leichter zu verstehen als netzförmige Beziehungsgeflechte, obwohl unsere Alltagssprache viele Beispiele vernetzter Begriffe aufweist. Wir bilden in unseren Anwendungssystemen nicht einfach die Alltagssprache nach, sondern wir rekonstruieren eine Fachsprache. Diese Rekonstruktion sollte im Anwendungsbereich unmittelbar verständlich sein. Gleichzeitig sollte sie so klar wie möglich und minimal in ihrem Umfang sein.

2

76

Einsatz von Vererbung

Einfach- und Mehrfachvererbung


2.1


In der technischen Konstruktion dagegen erweist sich die Mehrfachvererbung durchaus als nützlich, wenn sie diszipliniert eingesetzt wird und durch eine entsprechende Sprachimplementierung ohne große Kosten unterstützt wird. Ein Beispiel für unsere Verwendung von Mehrfachvererbung findet sich in Kapitel 3.2.1. Dabei zeigt sich, daß das Konzept benannter Schnittstellen, wie es in Java mit seinen Interfaces angeboten wird, vielfach eine Alternative zur Mehrfachvererbung darstellt. Die Modellierung von Begriffshierarchien ist die primäre fachliche Motivation zum Einsatz von Vererbung. Softwaretechnisch tritt daneben die Trennung von Spezifikation und Implementation in Oberklasse und Unterklassen (vgl. Kapitel 2.1.13). Ebenfalls technisch motiviert ist die Verwendung von Vererbung zur inkrementellen Übernahme und Modifikation von Merkmalen aus vorgegebenen und nicht mehr im Quelltext veränderbaren Klassenbeschreibungen. Dieser Fall tritt häufig bei kommerziell erworbenen Klassenbibliotheken auf. Soll dort ein Merkmal verändert werden, dann bleibt oft nur die Unterklassenbildung, bei der dann dieses Merkmal überschrieben wird. Auf diese Art und Weise lassen sich auch Änderungen vornehmen, wenn deren Auswirkungen auf Klientenobjekte nicht voll einschätzbar sind. In diesem Fall kapseln wir die Änderung in einer Unterklasse, da durch dynamisches Binden sowohl

2

77

Begriffshierarchien durch Vererbung

Inkrementelle Modifikationen durch Vererbung


2.1


die Exemplare der neuen als auch der alten Klasse (polymorph) verwendet werden können. Der letzte von uns methodisch vertretene Einsatz von Vererbung dient der Abstraktion gemeinsamer Merkmale aus vorhandenen Klassen. Dabei ist aber Vorsicht angesagt. Es sollte immer darauf geachtet werden, daß diese Gemeinsamkeit sich auch fachlich motivieren läßt und nicht nur in einem mehrfach auftretenden »Codestück« besteht, das herausgezogen werden soll. Denn es geht aus unserer Sicht bei der Vererbung eben nicht um Codewiederverwendung, sondern um die Abstraktion eines gemeinsamen Verhaltens. Damit läßt sich auch unsere Kritik am »Herausziehen« gemeinsamer Attribute in Oberklassen begründen. Diese Oberklassen orientieren sich an der inneren Struktur und zeigen wenig verhaltensbezogene Abstraktionen. Strukturbedingte Vererbungshierarchien finden sich oft in Projekten, die aus der »Tradition« der Datenmodellierung kommen. Insgesamt zeigt die Erfahrung, daß an Codewiederverwendung und an der Struktur orientierte »künstliche« Oberklassen nach kurzer Zeit unverständlich werden und sich in der Weiterentwicklung des Systems als Hemmschuh erweisen.

2

78 Vorsicht bei Codewiederverwendung und Herausziehen von Attributen


2.1


79

Methodischer Einsatz der Vererbung zur ❑ Modellierung von Begriffshierarchien, ❑ Trennung von Spezifikation und Implementation, insbesondere als eine Form der Realisierung von Aspekten, ❑ inkrementellen Übernahme und Veränderung vorhandener Klassenbeschreibungen sowie ❑ Abstraktion gemeinsamer Merkmale. Eine selektive (d.h. auslassende) Vererbung ist in unserem Ansatz nicht vorgesehen.

Viele objektorientierte Sprachen erlauben die Einschränkung des Zugriffs auf geerbte Merkmale (besonders für Operationen):

Einschränkung der Schnittstelle bei Vererbung

❑ durch generelle Einschränkung der Schnittstelle für Klienten,

d.h., ein geerbtes und in der Oberklasse sichtbares Merkmal gehört nicht mehr zur öffentlichen Schnittstelle der Unterklasse. Beispiele sind das private Erben in C++, wobei die Unterklassenrelation verlorengeht, oder der Nicht-Export in Eiffel, wo es durch die Unterklassenrelation zu Typfehlern kommen kann,

2


2.1


❑ durch Einschränkung der Schnittstelle mit Ausnahme von

bestimmten Klassen, d.h., nur bestimmte Klienten-Klassen können auf Merkmale zugreifen, der Rest nicht. Dies ist z.B. durch selektiven Export in Eiffel möglich. Vergleichbar ist der Bruch der Datenkapselung zwischen Klassen, z.B. durch das friend-Konstrukt in C++. Diese Technik sollte mit Vorsicht eingesetzt werden. Gerade bei der Konstruktion von Rahmenwerken oder bei der Implementierung von komplexen Mustern wird eine generelle oder gezielte Einschränkung oft eine Konstruktionsalternative sein. Andererseits sollte bedacht werden, daß dies oft zu unverständlichen Entwürfen führt. Sehr problematisch sind mögliche Typ- bzw. Laufzeitprobleme und die »Nichtvererbbarkeit« von friend-Konstrukten in C++. Für den Pausenplaner ist es wichtig, daß er sowohl die aktuellen Informationen zu einem Lehrer als auch zum Pausenplan drucken kann. Deshalb sieht der Klassenentwurf zum Pausenplan-Beispiel ein Klasse Druckbar mit den Operationen gibAlsASCII() für einen Schnellausdruck und gibAlsPS() für einen besser formatierten Ausdruck vor. Diese beiden Operationen erben nun sowohl die Klasse Lehrer als auch Pausenplan. Die Implementierung der Operationen ist jedoch unterschiedlich, da Informationen über einen Lehrer in der

2


80

2.1


Darstellung als auch im Umfang von denen des Pausenplans abweichen. Wir haben gesagt, daß wir die Vererbungsbeziehung vorrangig zur Begriffsmodellierung einsetzen. Dabei interpretieren wir Ober- und Unterklassen als eine »Ist ein«- oder »Verstehen wir als«-Beziehung. Ein Ordner ist in diesem Sinne für uns eine spezielle Form eines Behälters. Bei der Entwicklung großer Anwendungssysteme zeigt sich aber ein Problem, das wir auf diese Weise nicht elegant lösen können. Wenn in einer Organisation mehrere Abteilungen oder Gruppen auf einen Arbeitsgegenstand in verschiedenen Kontexten schauen, dann resultieren daraus oft unterschiedliche Sichten, die sich viel eher durch unterschiedliche Rollen als durch Generalisierung und Spezialisierung eines Begriffes modellieren lassen. Die Generalisierungsbeziehung verbindet Objekte (oder Gegenstände) nur über ihre gemeinsame Abstraktion. Ein Ordner ist ein Behälter und eine Mappe ist ein Behälter. Ansonsten haben diese Objekte nichts miteinander zu tun. Ein Ordner ist keine Mappe, nur weil beide Behälter sind. Anders verhält es sich mit wechselnden Rollen. So tritt ein Kunde der Bank gegenüber je nach Situation sowohl als Kreditnehmer als auch als Depotbesitzer auf. Wir sagen, er spielt verschiedene Rollen. Je nach Rolle hat der Kunde für die Bank eine andere Bedeutung, man könnte sagen, er hat unterschiedliche Umgangsformen. Trotzdem muß

2

81 Rollen als zusätzliche Beziehung zwischen Klassen


2.1


bei der Abbildung des Kunden und seiner Rollen im Anwendungssystem die fachliche Identität des Kunden in den verschiedenen Rollen gewährleistet sein. Da sich Rollen weder über reine Vererbung noch über Benutzung günstig konstruieren lassen, haben wir ein eigenes Rollenmuster entwickelt (s. Kapitel 3.3.4). Damit kommt für die Anwendungsentwicklung das Rollenverhältnis zur Spezialisierung und Generalisierung hinzu (vgl. [Reenskaug et al. 96]).

2.1.7 Benutzt-Beziehung Die Benutzt-Beziehung ist die einzige Verbindung, in der Objekte zueinander stehen können; dagegen ist sie neben der Vererbung die zweite Form der Klassenbeziehung, die unmittelbar programmiersprachlich unterstützt wird. Da die Benutzt-Beziehung der traditionellen Aufrufbeziehung oder dem Modulimport entspricht, ist sie die klassische Form der Verbindung von zwei Programmkomponenten.

2


82

2.1


83

Benutzt-Beziehung: Die Benutzt-Beziehung realisiert fachlich das Verhältnis von Klienten und Dienstleistungsanbietern. Dieses Verhältnis kann im Rahmen eines Vertrages (s. Kapitel 2.1.10) geregelt werden. Technisch verbindet sie sowohl Objekte untereinander als auch Klassen. Auf der Klassenebene wird die Benutzt-Beziehung durch eine (statische) Typdeklaration ausgedrückt. Zur Laufzeit können unterschiedliche aber typkonforme Objekte mittels Polymorphie über einen Bezeichner aufgerufen werden.

In der softwaretechnischen Diskussion um Modularisierung ist viel Erfahrung und Wissen über die sinnvolle Verwendung dieser Form der Komponentenbeziehung zusammengetragen worden. Dies schien in der ersten euphorischen Phase der objektorientierten Konstruktion in Vergessenheit geraten zu sein. So widmen sich auch heute noch viele Methoden- und Konstruktionsbücher ausführlich dem Für und Wider der Vererbungsbeziehung und ignorieren gleichzeitig die Benutzung. Wir messen der Benutzt-Beziehung zwischen Klassen einen hohen Stellenwert zu und gehen auf die methodische Verwendung in den Kapiteln 2.1.9 und 2.1.10 näher ein.

2

Modularisierung und Benutzt-Beziehung


2.1


Im objektorientierten Modell basiert die Benutzt-Beziehung also prinzipiell auf Verweisen oder Referenzen. Ein Bezeichner erhält statisch eine Typdeklaration. Zur Laufzeit kann dieser Bezeichner an Verweise oder Referenzen auf Exemplare von typkonformen Klassen gebunden werden. Dahinter steht das Konzept der Referenzsemantik. Dieses Bild wird auch beispielsweise in der Smalltalk-Literatur [Goldberg & Robson 89] gezeichnet. Allerdings stellen wir rasch fest, daß dieses Bild für (arithmetische) Berechnungen nicht aufrecht erhalten werden kann. Hier benötigen wir Werte im mathematischen Sinne. Was dies für unser Objekt-Metamodell bedeutet, zeigen wir in Kapitel 2.1.14. Im Pausenplan-Beispiel möchte der Pausenplaner gelegentlich einen Pausenplan oder Informationen zu einem Lehrer ausdrucken. Er benutzt dazu einen Postscript-Drucker. Um den Pausenplan oder die Informationen zu einem Lehrer in PS-Format vom Postscript-Drucker ausdrucken zu lassen, müssen diese eine Operation gibAlsPS() bereitstellen. Alle weiteren Operationen der Klassen Pausenplan und Lehrer sind für den Postscript-Drucker uninteressant. Daher ist in der Klasse PostscriptDrucker ein Bezeichner vom Typ Druckbar deklariert. Zur Laufzeit werden an diesen Bezeichner wahlweise Objekte der typkonformen Klassen Pausenplan und Lehrer gebunden.

2

84 Referenzsemantik


2.1


85

2.1.8 Polymorphie Auf Klassenebene bedeutet die Benutzt-Beziehung, daß im Klassentext statisch festgelegt ist, welche Beziehungen prinzipiell zwischen den Objekten dieser Klasse und anderen möglich sind. Zur Laufzeit wird die tatsächliche Beziehung zwischen den Objekten durch das Prinzip der Polymorphie bestimmt: Polymorphie ist in diesem Zusammenhang die programmiersprachliche Eigenschaft, daß Bezeichner zur Laufzeit an unterschiedliche Objekte gebunden werden können. In einer statisch typisierten Sprache wird diese polymorphe Bindung durch die Vererbungsbeziehung kontrolliert. Dies bedeutet, daß an einen Bezeichner Objekte der deklarierten Klasse und aller Unterklassen gebunden werden können. Dadurch ist diese Art der Polymorphie typsicher: Solange das Verhältnis von Ober- und Unterklassen eine Typ-Subtypbeziehung ist, können alle Operationen der deklarierten Klasse auch an ihren Unterklassen aufgerufen werden. Dynamisch typisierte Sprachen wie Smalltalk lassen eine uneingeschränkte Polymorphie zu – ein Bezeichner kann an jedes beliebige Objekt gebunden werden. Erst der Operationsaufruf entscheidet, ob das Objekt diese Operation auch unterstützt. Wenn nicht, tritt ein Laufzeitfehler auf. Für die Konstruktion bedeutet dies, daß uneinge-

2

Eingeschränkte Polymorphie

Uneingeschränkte Polymorphie


2.1


86

schränkte Polymorphie durch Programmierkonventionen kontrolliert eingesetzt werden muß. Denn im Klassentext geht allenfalls aus den Bezeichnernamen hervor, welche Objekte zur Laufzeit tatsächlich gebunden werden. Polymorphie: Polymorphie heißt Vielgestaltigkeit. In objektorientierten Programmen ist Polymorphie die Fähigkeit eines Bezeichners, zur Ausführungszeit an Objekte unterschiedlichen Typs gebunden werden zu können. Wenn die Typen der Objekte zum statisch deklarierten Typ des Bezeichners in einer Subtypbeziehung stehen, spricht man von eingeschränkter oder kontrollierter Polymorphie.

Dynamisches Binden ist die Voraussetzung für Polymorphie in Verbindung mit der Redefinition von Operationen in Unterklassen: Wenn an einen Bezeichner zur Laufzeit unterschiedliche Objekte gebunden werden können, dann können diese unter dem gleichen Operationsnamen auch unterschiedliche Implementierungen anbieten. Damit wird im statischen Programmtext nur festgelegt, welche Botschaft an ein Ob-

2

Dynamische Bindung


2.1


87

jekt gesendet wird. Erst zur Laufzeit wird entschieden, welche implementierte Operation ausgeführt wird (s. [Wegner 90]). Im Beispiel des Postscript-Druckers haben wir die Aspektklasse Druckbar verwendet. Zur Laufzeit können Exemplare der Klassen Lehrer und Pausenplan polymorph an Bezeichner dieses Typs gebunden werden. Die Botschaft gibAlsPS() wird je nachdem an die Implementation der Operation in der Klasse Lehrer oder Pausenplan gebunden.

2.1.9 Modularisierung Softwaretechnisch betrachtet können Klassen als eine Weiterentwicklung des Modulkonzeptes verstanden werden (»Classes should be the only modules.« [Meyer 97]). Damit gelten für die Benutzt-Beziehung auf den ersten Blick die gleichen Prinzipien der maximalen Kohäsion und minimalen Kopplung wie für die Modularisierung. Diese traditionellen Modularisierungsprinzipien können nicht einfach auf die Objektorientierung übertragen werden. Zunächst sind Klassen oder Objekte von einer anderen Granularität als gängige Module. Während es üblich und möglich ist, ein Anwendungssystem aus deutlich weniger als 100 Modulen zu bauen, geht die Anzahl der

2

Module und Klassen


2.1


Klassen oder gar Objekte bei halbwegs komplexen Anwendungen leicht in die nächsthöhere Größenordnung. Jede einzelne Klasse zeigt dabei eine sehr überschaubare Menge von Operationen. Betrachen wir Objekte und Klassen daher als die »Atome« des objektorientierten Entwurfs, so eröffnet sich eine andere Sicht. Offenbar entwerfen und konstruieren wir in Einheiten oder Komponenten, die aus mehr als einer Klasse oder einem Objekt gebildet werden und die eine sehr enge konzeptionelle Einheit darstellen. Eine solche Einheit stellt ein Behälter mit Inhaltsverzeichnis und Marker oder Iteratoren dar (vgl. Kapitel 3.2.7). Zu ihrer Realisierung benötigen wir wechselseitige Benutzt-Beziehungen. Auch einige der erfolgreichen Muster (z.B. in [Gamma et al. 96]) wie Besucher, Beobachter oder Vermittler basieren auf wechselseitiger Benutzung. In der Diskussion der letzten Jahre hat sich die Einsicht, daß die konzeptionellen Entwurfs- und Konstruktionseinheiten der Objektorientierung oft jenseits einer Klasse liegen, im Begriff der Entwurfsmuster, Cluster, Subsysteme und Rahmenwerke (Frameworks) niedergeschlagen. Die Modularisierungsprinzipien in unserem Objekt-Metamodell müssen also mit Blick auf diese Entwurfs- und Konstruktionseinheiten reformuliert werden. Dies leisten wir für die elementaren Entwurfseinheiten in Kapitel 3.2 und für Rahmenwerke in Kapitel 3.3.

2

88

Objektorientierte Entwurfsund Konstruktionseinheiten


2.1


89

Kohäsion und Kopplung:

Kohäsion: »Innerer Zusammenhalt« zwischen den Merkmalen einer Entwurfs- oder Konstruktionseinheit. Das Prinzip der maximalen Kohäsion fordert eine möglichst hohe Bindungsstärke innerhalb einer Entwurfs- oder Konstruktionseinheit. Kopplung: Zusammenhang zwischen unterschiedlichen Entwurfs- oder Konstruktionseinheiten. Minimale Kopplung zielt auf die Reduktion der Bindung zwischen den Einheiten, insbesondere die Vermeidung zyklischer Benutzung.

B. Meyer hat in [Meyer 97] Kriterien und Regeln für die Übertragung des Modulkonzepts auf die Objektorientierung zusammengestellt, von denen wir die aus unserer Sicht relevanten hier zusammenfassen. Wesentliche Kriterien, die eine Entwurfs- und Konstruktionseinheit erfüllen sollte, sind:

Kriterien

❑ Zerlegbarkeit: Ein Entwurfsproblem sollte sich in kleinere,

weniger komplexe Teilprobleme zerlegen lassen, die entsprechend als Entwurfs- und Konstruktionseinheiten abgebildet werden. Diese sollten eine einfache Struktur bilden und weitgehend unabhängig konstruiert werden können.

2


2.1


90

❑ Kombinierbarkeit: Die Entwurfs- und Konstruktionseinheiten

sollten sich durch einfache Rekombination zu neuen Softwaresystemen in verschiedenen Anwendungsbereichen zusammenfügen lassen. ❑ Verständlichkeit: Jede Entwurfs- und Konstruktionseinheit

eines Softwaresystems sollte weitgehend unabhängig von den anderen verständlich sein. ❑ Kontinuität: Eine Änderung des Entwurfsproblems, die aus

dem Anwendungsbereich oder dem technischen Kontext eines Softwaresystems resultiert, sollte Änderungen nur in einer oder wenigen Entwurfs- und Konstruktionseinheiten erfordern. Um diese Kriterien erfüllen zu können, müssen wir folgende Regeln beachten:

Regeln

❑ Direkte Abbildung: Die Struktur des Softwaresystems sollte im

engen Zusammenhang mit den im Anwendungsbereich identifizierten Strukturen stehen. ❑ Wenige Schnittstellen: Jede Entwurfs- und Konstruktionsein-

heit sollte mit möglichst wenig anderen interagieren.

2


2.1


❑ Kleine Schnittstellen: Wenn zwei Entwurfs- und Konstruk-

tionseinheiten interagieren, sollten sie so wenig Information wie möglich und nötig austauschen. ❑ Explizite Schnittstellen: Wenn zwei Entwurfs- und Konstrukti-

onseinheiten interagieren, sollte dieser Austausch explizit sein. ❑ Geheimnisprinzip: Nur relevante Merkmale einer Entwurfs-

und Konstruktionseinheit sollten für Klienten sichtbar und zugänglich sein. ❑ Offen-Geschlossen-Prinzip: Entwurfs- und Konstruktionsein-

heiten sollten sowohl offen als auch geschlossen sein. Offen-Geschlossen-Prinzip: Eine Entwurfs- oder Konstruktionseinheit ist offen, wenn sie weiterentwickelt werden kann. Eine Entwurfs- oder Konstruktionseinheit ist geschlossen, wenn sie stabil von Klienten verwendet werden kann.

2


91

2.1


92

2.1.10 Vertragsmodell Wir wollen mit Hilfe einer objektorientierten Vorgehensweise nicht nur erweiterbare, wiederverwendbare und änderbare, sondern auch korrekte und robuste Klassen entwickeln. Robustheit wollen wir hierbei vor allem dadurch erhalten, daß Objekte verhaltensorientiert, d.h. nach ihrem Umgang und nicht nach ihrer inneren Struktur, den Attributen, modelliert werden. Mit dem Vertragsmodell wird im folgenden ein Konzept skizziert, das es erlaubt, das Verhalten von Operationen »halbformal« zu spezifizieren. Durch die Angabe von Zusicherungen im Zusammenspiel von Klienten und Dienstanbietern können wir einen deutlichen Schritt in Richtung Korrektheit von Software gehen. Korrektheit bezieht sich hier auf die Übereinstimmung von Spezifikation und Implementation. Wir wollen mit Hilfe von Invarianten, Vor- und Nachbedingungen Teile einer Verhaltensspezifikation im Klassentext beschreiben und überprüfbar machen.

2

Zusicherungen


2.1


93

Vertragsmodell: Das Vertragsmodell betrachtet die Benutzt-Beziehung zwischen Klassen als ein Verhältnis von Leistungsanbietern und Klienten, das durch einen formalen Vertrag geregelt ist. Der Vertrag legt fest, welche Vorbedingungen ein Klient erbringen muß, damit der Anbieter seine Leistungen erfüllt. Verträge sind beim Anbieter beschrieben und bestehen aus Vor- und Nachbedingungen sowie Invarianten.

Das Vertragsmodell hilft, ❑ Entwurfs- und Konstruktionsfehler zu reduzieren, ❑ die Verständlichkeit von Klassen zu erhöhen und ❑ in Verbindung mit einem entsprechenden Ausnahmemechanis-

mus Laufzeitfehler frühzeitig abzufangen. Programmiertechnisch sollen Klassen Implementierungen von abstrakten Datentypen sein. Mit den uns bekannten Sprachmitteln der meisten objektorientierten Programmiersprachen können wir aber nur Operationen und Attribute beschreiben. Wollen wir mit Hilfe von Typen »eine

2

Klassen als abstrakte Datentypen


2.1


Menge von programmiersprachlichen Objekten mit gleichartigem Verhalten« modellieren, benötigen wir hierzu ein adäquates Ausdrucksmittel. Denn zur Spezifikation abstrakter Datentypen gehört eine axiomatische Semantik, die meist durch Axiome und Gleichungen ausgedrückt wird. Dies läßt sich in einer objektorientierten Programmiersprache nicht unmittelbar realisieren. Die Kluft zwischen Spezifikation und Implementation abstrakter Datentypen kann durch das Vertragsmodell, das als »Design by Contract«, z.B. in [Meyer 97] beschrieben ist, zum Teil überwunden werden. Die Benutzt-Beziehung zwischen Klassen wird als ein Dienstleistungsverhältnis zwischen Klient und Anbieter interpretiert (s. Abbildung 2-9). Ein Klasse bietet dabei eine Dienstleistung an, die eine andere Klasse als Klient gebrauchen kann. Zwischen den beiden Klassen wird dabei ein Vertrag geschlossen, der Zusicherungen enthält. Beiden Seiten erwachsen daraus Rechte und Pflichten, da mit den Zusicherungen festgelegt wird, unter welchen Bedingungen welche Leistung erbracht wird.

2

94

Klient und Anbieter


2.1


Anbieter

Klient Dienstleistung

Abb. 2-9 Anbieter und Klient

Vertrag mit Zusicherungen

Das Vertragsmodell interpretiert und definiert die Benutzt-Beziehung zwischen Klassen. Es wird realisiert durch Vor- und Nachbedingungen sowie Klasseninvarianten, die jeweils die Form eines Booleschen Ausdrucks haben und in der Anbieterklasse notiert sind. Die zwischen den Klassen geschlossenen Verträge beziehen sich immer auf einen Aufruf einer Operation, also die Anforderung einer Dienstleistung. Die für einen Vertrag festgelegte Vor- oder Eingangsbedingung legt fest, was gelten muß, damit eine Operation aufgerufen werden kann. Verantwortlich für die Einhaltung der Vorbedingung ist der Klient. Er muß sicherstellen, daß die entsprechenden Bedingungen gelten. Damit er dies kann, müssen die in der Vorbedingung verwendeten Prädikate als Testfragen an der Schnittstelle des Anbieters zugänglich sein. Dann ist der Klient in der Lage, vor dem Aufruf einer

2

95 im Vertragsmodell

Operationen als Verträge


2.1


96

Operation die Einhaltung der Vorbedingung zu überprüfen und gegebenenfalls den geforderten Zustand erst herzustellen. class Stack feature

Abb. 2-10

Vorbedingung pop is (d.h. Voraussetzungen) require not empty do number_of_elements := number_of_elements - 1; ensure not full Nachbedingung end; (d.h. Verpflichtungen) ••• invariant empty implies (number_of_elements = 0) end -- class Stack Invariante

in Eiffel

Beispiel für Zusicherungen

(d.h. Randbedingung)

Ist die Vorbedingung eingehalten, wird die Operation durchgeführt, und der Anbieter erklärt, daß er die Nach- oder Ausgangsbedingung garantiert. Diese ebenfalls aus Booleschen Ausdrücken zusammengesetzte Bedingung muß vom Klienten nicht überprüft werden. Er kann davon ausgehen, daß die Bedingung nach dem Abarbeiten einer Operation gilt.

2


2.1


Als insgesamt konsistenzwahrende Eigenschaft wird für eine Klasse die Invariante formuliert. Diese gilt für jede Dienstleistung, die angeboten wird, d.h., ihre Einhaltung wird bei jedem Aufruf geprüft. Die Einhaltung eines Vertrags muß überprüft werden. Eine Vertragsverletzung muß entsprechende Folgen haben. Das Vertragsmodell ist nur dann mehr als eine reine Dokumentation, wenn Vertragsverletzungen sanktioniert werden. Deshalb sollten Zusicherungen mit einem entsprechenden Ausnahmemechanismus gekoppelt werden. Die Verletzung einer Vorbedingung muß eine Ausnahme beim Klienten auslösen; die Verletzung von Nachbedingungen und Invarianten führt zu Ausnahmen beim Anbieter. Das Vertragsmodell ist programmiersprachlich bisher unter den objektorientierten Sprachen nur von Eiffel unterstützt, wo Zusicherungen als eigene Subsprache formulierbar sind (s. [Meyer 97] und Abbildung 2-10). Es hat sich allerdings in Projekten sehr bewährt, das Zusicherungskonzept auch in anderen Programmiersprachen »nachzuimplementieren«.

2

97 Invarianten

Vertragsverletzungen


2.1


2.1.11 Typ In gängigen objektorientierten Programmiersprachen werden Klasse und Typ gleichgesetzt. Dies ist praktisch, verwischt aber die konzeptionellen Unterschiede, die wir im Auge behalten müssen, wenn wir softwaretechnisch sauber arbeiten wollen. Dies gilt besonders dann, wenn wir eine dynamisch typisierte Programmiersprache wie Smalltalk verwenden. Typ: Ein Typ bezeichnet in objektorientierter Interpretation eine Spezifikation des Verhaltens von Objekten im Sinne eines abstrakten Datentyps. Ein Typ ist eine syntaktische und semantische Abstraktion. Er dient zur Deklaration von Bezeichnern und Größen eines Programms zum Zwecke der Überprüfung ihrer (typsicheren) Verwendung. Ein Typ spezifiziert syntaktisch eine Schnittstelle, d.h. benennt die Operationen, mit denen ein Exemplar des Typs aufrufbar ist. Darüber hinaus kann ein Typ im Sinne eines Protokolls das Verhalten von Objekten beschreiben Ein Typ enthält keine Information über die Repräsentation des Zustands und die Implementierung der Operationen.

2


98

2.1


Das Typkonzept ist vor allem softwaretechnisch motiviert. Wir spezifizieren damit Eigenschaften unserer Konstruktionseinheiten. Nach der allgemeinen Formulierung von Cardelli und Wegner [Cardelli & Wegner 85] bezeichnet ein Typ eine Menge von Objekten mit gleichartigem Verhalten. Dabei haben sie nicht die objektorientierten Komponenten Klasse und Objekt im Auge, sondern meinen allgemein programmiersprachliche Objekte. Übertragen wir dies auf Objektorientierung, dann können wir beispielsweise sagen, daß die beiden Ordner A und B in der Abbildung 2-11 dieselbe Schnittstelle besitzen und sich ähnlich verhalten. Daher können sie durch den Typ Ordner beschrieben werden. Mit der Typdefinition haben wir auf jeden Fall festgelegt, welche prüfbare Schnittstelle Exemplare dieses Typs haben. Dies bedeutet, daß ein Bezeichner, den wir mit diesem Typ deklarieren, immer nur an Objekte gebunden werden kann, die diese Schnittstelle erfüllen. Ein Typ sollte also geprüft werden. Wir verwenden deshalb gern typisierte Sprachen, weil deklarierte Bezeichner und Größen eines Programms dann auf typsichere Verwendung statisch (zur Übersetzungszeit) oder dynamisch (im Ablauf) geprüft werden können. Darüber hinaus möchten wir in den möglichen Grenzen das Verhalten dieser Exemplare festlegen. Wie wir im Abschnitt über das Vertragsmodell gesehen haben, ist es nicht einfach, die axiomatische

2

99 Typkonzept

Typ und Verhalten


2.1


100

Semantik der abstrakten Datentypen auf die objektorientierte Konstruktion zu übertragen. Trotzdem erwarten wir, daß sich die Exemplare eines Typs semantisch »verträglich« verhalten. Entprechend gehören Zusicherungen auch zur Definition eines Typs. Typ Ordner

Ordner B

Abb. 2-11 Von den Objekten

füge Dokument ein

füge Dokument ein

zum Typ

beschrifte mit Text

beschrifte mit Text



Ordner A füge Dokument ein beschrifte mit Text gib Beschriftung ist voll?

2


2.1


101

Ein Typ im Sinne eines abstrakten Datentyps macht aber keinerlei Aussage zur konkreten Realisierung des Schnittstelle und ihres Verhaltens. Damit gehören Implementierungen und Aussagen über die innere Struktur nicht zur Definition eines Typs. Prüfbare Eigenschaften eines Typs: Ein Typ ist charakterisiert durch eine Menge von Eigenschaften. Ein Objekt x hat den Typ T genau dann, wenn Objekt x die Eigenschaften erfüllt, durch die Typ T charakterisiert ist. Folgende Eigenschaften können durch einen Typ beschrieben werden: ❑ Aussagen über die Klasse eines Objekts, ❑ Aussagen über die Namen der Operationen oder über die gesamten Signaturen eines Objekts, ❑ Aussagen über das Verhalten der Operationen (z.B. Vor- und Nachbedingungen, Invarianten). Konkrete Typsysteme bieten meist nur einen Ausschnitt dieser Eigenschaften.

2


2.1


Traditionell darf (etwa im Sinne von [Hoare72]) ein programmiersprachliches Objekt nur zu genau einem Typ gehören. Das objektorientierte Prinzip der Vererbung erfordert eine Ausweitung des Typbegriffs. Danach ist ein Objekt genau Exemplar einer (erzeugenden) Klasse; kann aber beliebig vielen Typen angehören. Typen lassen sich durch Subtypenbildung in Typhierarchien anordnen. Die Bildung von Subtypen ist vorrangig ein Konzept zur Spezifikation, mit dem wir ausdrücken, daß sich Objekte gleichartig verhalten. Dies geht über die vielfach nur geprüfte Gleichnamigkeit der Schnittstelle hinaus. Es reicht also nicht aus, daß die gerufene Operation durch das Objekt überhaupt interpretiert werden kann. Denn das heißt doch nur, daß der Aufruf nicht unmittelbar zu einem Laufzeitfehler führt. Vielmehr ist es meist erforderlich, daß alle vom Typ spezifizierten Operationen auf »ähnliche« Weise interpretiert werden, was zum Begriff der Verhaltensähnlichkeit führt. Verhaltensähnlichkeit ist eine viel »weichere« Formulierung als die von vielen Theoretikern geforderte Verhaltensgleichheit. Sie läßt sich leider kaum formal überprüfen. Vielmehr erwarten wir von einem Objekt, daß es sich bei der Implementierung und Redefinition von Eigenschaften nicht nur formal »typkonform«, sondern »im Sinne« der Spezifikation verhält.

2

102

Typhierarchien


2.1


103

Typhierarchie (nach [Liskov 88]): Eine Typhierarchie besteht aus Sub- und Supertypen. Ein Subtyp bietet zumindest die Operationen an, die von seinem Supertyp spezifiziert sind. Dabei kann es folgende Varianten geben: ❑ Die Operationen stimmen genau in ihren Signaturen überein. ❑ Die Typen der Parameter- und Ergebnisobjekte können selbst von einem Sub- oder Supertyp des ursprünglichen Typs sein (Ko- und Kontravarianz). Ein Exemplar eines Subtyps muß zur Laufzeit immer die Stelle eines Exemplars des Supertyps einnehmen können. Dabei ist entweder Verhaltensgleichheit oder -ähnlichkeit gefordert: ❑ Ein Exemplar eines Subtyps führt zur keiner feststellbaren Veränderung des Programms. ❑ Ein Exemplar des Subtyps ist insofern verhaltensähnlich, als es das erwartete Verhalten und niemals einen Laufzeitfehler produziert.

Konzeptionelle Ansätze zur Verhaltensspezifikation von Subtypen finden sich in [Liskov 88, Liskov & Wing 93]. Das Problem der

2


2.1


104

kovarianten Redefinition von Parametertypen und einen möglichen Lösungsansatz behandelt [Meyer 97].

2.1.12 Klasse und Typ Fachlich sind Klassen unsere elementaren Entwurfs- und Konstruktionseinheiten. Im Entwurf modellieren wir in Klassen die Gemeinsamkeit gleichartiger Objekte. Diese Gemeinsamkeit umfaßt die Objekte in ihrem gesamten Umgang. Dazu gehört das Verhalten ebenso wie der Zustand und die Identität. Klassenhierarchien sollen hier den fachlichen Begriffshierarchien entsprechen. Auf der Konstruktionsebene legt eine Klasse fest, wie sich ihre Exemplare verhalten und wie sie aufgebaut sind. Dabei drücken Klassenhierarchien die Generalisierung oder Spezialisierung dieses Verhaltens und des Aufbaus aus. Compiler und Laufzeitsystem stellen sicher, daß die richtigen Exemplare von »vollständigen« Klassenbeschreibungen erzeugt werden. Demgegenüber ist ein Typ vor allem ein Spezifikationskonzept, das eine »äußere« Sicht auf deklarierte Bezeichner und Programmobjekte festlegt. Die Betonung liegt weniger auf der fachlichen Seite von Modellierung und Konstruktion als mehr auf der softwaretechni-

2

Typ als Spezifiaktionskonzept


2.1


schen Umsetzung. Ein Typ legt für die Struktur des Programms fest, welche syntaktischen und (eingeschränkt) welche semantischen Merkmale garantiert werden können. Schauen wir uns die Unterschiede näher an:

105

Unterschiede Klasse – Typ

❑ Eine Klasse definiert neben der Schnittstelle das Verhalten und

den Aufbau ihrer Exemplare, d.h. ihren internen Zustand und die Implementierung der Operationen. ❑ Ein Typ dient zur Spezifikation von Objekten und zur Deklara-

tion von Bezeichnern. Dadurch stellt er sicher, daß an typisierte Bezeichner nur typkonforme Objekte gebunden werden können. ❑ Der Typ eines Objekts zur Laufzeit bezieht sich zunächst nur

auf seine Schnittstelle, d.h. die Menge der Botschaften, auf die das Objekt reagieren kann. ❑ Um neben der Schnittstelle auch das Verhalten von Exempla-

ren eines Typs festzulegen, können Typen durch Klassen realisiert werden. Wenn die Typhierarchie der Klassenhierarchie entspricht, kann über Zusicherungen und kontrollierte Redefinitionen eine Verhaltensähnlichkeit von Objekten erreicht werden.

2


2.1


106

❑ Ein Objekt kann verschiedene Typen haben, und Objekte von

unterschiedlichen Klassen können denselben Typ haben. ❑ Ein Teil der Schnittstelle eines Objekts kann durch einen Typ

charakterisiert sein und andere Teile durch andere Typen. ❑ Zwei Objekte des gleichen Typs brauchen nur mit einem Teil

ihrer Schnittstellen übereinzustimmen. Daraus folgt, daß Klasse und Typ völlig separate Konzepte sein können, wenn der Typ sich auf die reine Schnittstellendefinition bezieht. Wenn ein Typ nur eine benannte Schnittstellendefinition darstellt, ist damit nur garantiert, daß Exemplare des Typs eine bestimmte Menge von Botschaften erkennen. Jeder Typ benennt Operationen, die an irgendeiner Stelle des Programms definiert werden müssen. Eine Klasse kann dann angeben, welche Typen, im Sinne benannter Schnittstellen, sie erfüllt. Irrelevant und unabhängig von der Klassenhierarchie ist, in welcher Klasse diese Operationen definiert sind. Verkoppelt die Programmiersprache das Klassen- und das Typkonzept, besteht natürlich ein Zusammenhang zwischen Klasse und Typ. Die Klasse legt dann per Definition einen Typ fest. Die Formulierung »ein Objekt ist Exemplar einer Klasse« impliziert, daß das Objekt die Schnittstelle unterstützt, die durch die Klasse definiert ist.

2

Trennung von Klasse und Typ

Zusammenhang Klasse – Typ


2.1


107

Der typkonforme Aufruf einer Botschaft verlangt, daß das Objekt die Botschaft versteht, d.h., daß die Klasse des Objekts die entsprechende Operation implementiert. Darüber hinaus entsteht ein weiterer Zusammenhang zwischen Klasse und Typ, wenn mit der Typdefinition das Verhalten der Exemplare festgelegt werden soll. In diesem Fall liegt es nahe, das Verhalten der Exemplare eines Typs über eine entsprechende Klasse zu definieren. Wenn die Typhierarchie der Klassenhierarchie entspricht, dann kann das konkrete oder abstrakte Verhalten von Objekten eines Typs durch die Klassenhierarchie festgelegt und begrenzt werden. Mittel dazu sind das Vertragsmodell und die Abbildung von Begriffsgebäuden in fachlichen Klassenhierarchien, die nach den Prinzipien von Generalisierung und Spezialisierung entworfen werden. In den gängigen objektorientierten Sprachen finden wir verschiedene Realisierungen des Typ- und Klassenkonzepts: ❑ Die Trennung von Klasse und Typ finden wir in Java mit seinen

Interfaces und in Objective C mit seinen Protocols. Hier kann eine Klasse neben ihrer Oberklasse angeben, welche benannten Schnittstellen sie erfüllt. Klassen können nicht nur nach Klassenhierarchien, sondern auch nach ihren Schnittstellen gruppiert werden. Damit können Klassen, die nicht in einer Ver-

2

Java, Objective C: benannte Schnittstelle


2.1


108

erbungsbeziehung stehen, unter eine gemeinsame benannte Schnittstelle fallen. ❑ C++ und Eiffel benutzen das Klassenkonstrukt, um sowohl den

Typ eines Objekts als auch seine Implementierung festzulegen. Allerdings gibt es auch die Möglichkeit, reine Spezifikationsklassen zu schreiben, von denen keine Exemplare erzeugt werden können. ❑ In Smalltalk gibt es keine Typdeklarationen für Bezeichner und

Programmeinheiten, d.h., bei der Übersetzung erfolgt keine Typkontrolle. Folglich wird auch nicht geprüft, ob ein Objekt über einen Bezeichner mit der »passenden« Botschaft gerufen wird. Kennt ein Objekt eine gerufene Operation nicht, führt dies zu einem Laufzeitfehler.

C++, Eiffel: Klasse als Typ

Smalltalk: fehlende Typdeklaration

Was folgt daraus? Wir müssen uns im klaren darüber sein, welche Möglichkeiten uns Klasse und Typ als Konstrukte bieten und was wir konzeptionell in unseren Anwendungen umsetzen möchten. Wollen wir eine Trennung zwischen einer benannten Schnittstelle und der Festlegung ihres Verhaltens? Soll es neben der Klassenhierarchie eine Hierarchie benannter Schnittstellen geben und was drücken wir damit konzeptionell aus? Welche Sicherheit beim Aufruf einer Botschaft möchten

2


2.1


wir haben und zu welchem Zeitpunkt (Compilezeit oder Laufzeit) wollen wir uns diese Sicherheit verschaffen? Die Antwort auf diese Fragen bestimmt, ob wir mit den Konstrukten einer gegebenen Sprache zurechtkommen, wie wir sie nutzen und ob wir eigene Mechanismen, etwa eine Laufzeittypprüfung in Smalltalk, hinzubauen. Erste Antworten zeichnen sich aus den Erfahrungen mit dem WAM-Ansatz ab: Typsysteme stellen eine große Unterstützung für die sichere Konstruktion von Softwaresystemen dar. Dynamisch typisierte Sprachen wie Smalltalk bieten während der reinen Entwicklungsphase mehr Flexibilität als statisch typisierte Sprachen. Es ist aber sinnvoll, auch in Smalltalk so zu konstruieren, als ob Smalltalk statisch getypt wäre. Zur Sicherheit bauen wir deshalb an entscheidenden Stellen von Softwaresystemen dynamische Typprüfungen ein. Vererbungshierarchien sollten fachlichen Hierarchien entsprechen und damit auch ein ähnliches Verhalten festlegen. Damit streben wir in den meisten Fällen Klassenhierarchien als Typhierarchien an. Wenn wir für die technische Realisierung von Softwarearchitekturen nicht auf Mehrfachvererbung zurückgreifen können oder wollen, sind benannte Schnittstellen eine sinnvolle Alternative. Über Entwurfskonventionen müssen wir dann sicherstellen, daß eine Verhaltensähnlichkeit in der Verwendung gewährleistet ist.

2

109

Erfahrungen


2.1


110

2.1.13 Spezifikation und Implementation In objektorientierten Sprachen nutzen wir oft die Möglichkeit, Spezifikation und Implementation zwischen Klassen zu trennen: ❑ Spezifikation in einer Oberklasse, d.h. Vorgabe von Verhalten

auf abstrakter Ebene. ❑ Implemention in zugehörigen Unterklassen, d.h. Realisierung

des Verhaltens auf konkreter Ebene. Auf der technischen Ebene setzen wir Spezifikationen entweder durch abstrakte Klassen oder über benannte Schnittstellen wie bei Java um. Wir haben auf das Problem hingewiesen, daß bei benannten Schnittstellen die Möglichkeit fehlt, Verhalten zu spezifizieren oder schon im Supertyp eine Implementation vorzusehen.

2


2.1


111

Abstrakte Klasse: Abstrakte Klassen sind Klassen, die zumindest eine nicht-implementierte Operation haben, so daß von ihnen keine Exemplare erzeugt werden können. Sie dienen zur Spezifikation einer gemeinsamen Schnittstelle und eines abstrakten Verhaltens für alle Unterklassen, die von diesen implementiert werden müssen. Die abstrakte Klasse kann selbst bereits einen Teil der Operationen implementieren, die dann vererbt werden. Alle nicht implementierten Operationen der abstrakten Klasse definieren wenigstens eine Fehlernachricht.

Die Trennung von Spezifikation und Implementation ist eine wesentliche Art, die Vererbung einzusetzen. Eine gemeinsame Oberklasse spezifiziert die Schnittstelle und das abstrakte Verhalten aller Unterklassen. Wir nennen eine solche Klasse abstrakt (auch »aufgeschoben« oder deferred), weil mindestens eine ihrer Operationen abstrakt ist. In einigen objektorientierten Sprachen (z.B. Java und Eiffel) können Klassen explizit als abstrakt markiert werden. In anderen Spra-

2

Trennung von Spezifikation und Implementation


2.1


chen müssen abstrakte Klassen durch Konvention oder implizit über eine aufgeschobene Methode erkennbar gemacht werden. Da von einer abstrakten Klasse keine Objekte erzeugt werden können, wird deutlich, daß sie nicht direkt verwendet werden kann. Es ist Aufgabe der Unterklassen, die Schnittstelle und das konkrete Verhalten zu implementieren. Andererseits reicht für die Verwendung meist aus, die abstrakte Klasse mit ihrem abstrakten Umgang zu kennen. So kann ein ganzer Klassenbaum »hinter« der abstrakten Oberklasse verborgen werden. Abstrakte Klassen mit verborgenem Klassenbaum bilden die Grundidee eines elementaren Entwurfsmusters (Design Pattern) der Objektorientierung (vgl. das Familienmuster in [Gamma 92]). Auch weiterentwickelte Konstruktionen wie das Brückenmuster [Gamma et al. 96] funktionieren so. Im WAM-Ansatz läßt sich die Realisierung von Aspekten (s. Kapitel 3.2.1) mit Hilfe von Aspektklassen so einordnen. Abstrakte Klassen im Sinne der vorausgegangenen Diskussion sind mehr als reine Schnittstellenbeschreibungen. Die in einer abstrakten Klasse deklarierten Operationen können dort bereits verwendet werden. Dabei können neben den abstrakten Operationen bereits einige Operationen implementiert sein. Sie können als Schablonenoperationen oder Standardimplementationen von Klientenklassen

2

112

Muster mit abstrakten Klassen

Verhaltensspezifikation in abstrakten Klassen


2.1


113

aufgerufen werden. Diese Technik hat für den Bau von Rahmenwerken eine große Bedeutung. Wir gehen darauf in Kapitel 2.3.2 ein. Abstrakte Klassen mit ihren Schnittstellen- und Verhaltensspezifikationen legen bereits in gewissem Umfang den Umgang mit ihren Unterklassen fest und definieren damit in Grenzen auch den Entwurf des restlichen Systems.

2


2.1


114

Operationen abstrakter Klassen: Im Sinne von [Johnson & Russo 91] unterscheiden wir drei Arten von Operationen bei abstrakten Klassen: ❑ Abstrakte Operationen sind nicht implementiert. Dies ist Aufgabe der Unterklassen. Die abstrakten Operationen spezifizieren aber die für alle Unterklassen verbindliche Schnittstelle. Wenn eine Operation nur eine Standardimplementation (default) vorgibt, aber für die Redefinition in Unterklassen vorgesehen ist, wird sie oft Einschub-Operation (Hook) genannt. ❑ Schablonenoperationen (Template Methods) implementieren einen Algorithmus basierend auf abstrakten Operationen. Der Algorithmus wird vollständig angegeben, zur Ablauffähigkeit fehlen ihm aber die Implementationen der abstrakten Operationen. ❑ Basisoperationen sind Operationen, die bereits in der abstrakten Klasse vollständig und ablauffähig implementiert sind.

Abstrakte Klassen müssen in einer Anwendung spezialisiert werden, um daraus ein vollständiges Programm zu machen. Hierzu müssen mindestens die abstrakten Operationen in der spezialisierten Klasse implementiert werden.

2


2.1


In Abbildung 2-12 haben wir eine abstrakte Klasse dargestellt, die die Schnittstelle Schablonenoperation, AbstrakteOperation und Basisoperation besitzt. Schablonenoperation ist mit Hilfe von Basisoperation und AbstrakteOperation implementiert. AbstrakteOperation wird selbst erst in der erbenden Klasse implementiert. Abstrakte Klasse Schablonenoperation()

AbstrakteOperation()

... Basisoperation(); AbstrakteOperation(); ...

115 Beispiel

Abb. 2-12 Spezialisierung einer abstrakten Klasse

Basisoperation()

Erbende Klasse AbstrakteOperation()

Die Unterklassen der abstrakten Oberklassen werden grundsätzlich polymorph verwendet. Allerdings ergibt sich oft die fachliche oder technische Notwendigkeit, im Rahmen der Spezialisierung die Schnittstelle in den Unterklassen zu erweitern. Sollen die Exemplare der

2


2.1


Unterklassen dann sowohl polymorph als auch unter ihrem dynamischen Typ benutzt werden, entsteht rasch der Bedarf nach einem Metaobjekt-Protokoll (vgl. Kapitel 2.1.15). Die Verwendung von abstrakten Klassen ist ein Beispiel, um Systeme mit einer losen Kopplung der einzelnen Komponenten zu erreichen. Die Motivation zur losen Kopplung geht auf die Diskussion um Modularisierungskonzepte zurück (vgl. Kapitel 2.1.9). Hier gilt, daß Komponenten »nach außen« geringe Abhängigkeiten haben sollten, während »innen« ein starker inhaltlicher Zusammenhang besteht. Eine Technik, um lose Kopplung zwischen Komponenten zu erreichen, ist, bei der Benutzung anderer Komponenten nur deren Typ oder Schnittstelle anzusprechen, ohne die konkrete Klassen und deren Implementierung zu kennen (»Programmiere auf eine Schnittstelle hin, nicht auf eine Implementierung« [Gamma et al. 96]). Wir gehen einen Schritt weiter und reduzieren bei der losen Kopplung die Benutzung auf den Ausschnitt der Schnittstelle, der für die Benutzung minimal notwendig ist.

2

116

Lose Kopplung


2.1


117

Lose Kopplung: Eine Komponente ist dann lose an eine zweite gekoppelt, wenn der Klient nicht die gesamte Schnittstelle des Anbieters kennt, sondern auf der Basis eines Typs nur den Ausschnitt der Schnittstelle (und ihres Verhaltens), der die notwendigen Operationen für diese Kopplung beschreibt.

Als Ergebnis der losen Kopplung können sowohl einzelne Klassen im Programmtext als auch Objekte über polymorphe Bindung zur Laufzeit leicht gegen entsprechende Komponenten mit gleicher Schnittstelle und ähnlichem Verhalten aber unterschiedlicher Implementation ausgetauscht werden. Wir werden in Kapitel 3.2.1 die Aspekte als eine Realisierung der losen Kopplung von Werkzeug und Material vorstellen. Ein Konstruktionsproblem muß bei der losen Kopplung zwischen Klientenklasse und der von ihr benutzten abstrakten Oberklasse gelöst werden. An der Stelle, wo ein Objekt erzeugt werden soll, muß die konkrete Unterklasse bekannt sein. Dies widerspricht auf den ersten Blick dem Entkopplungsgedanken. Also sind eine Reihe von Mechanismen vorgeschlagen worden, um unter Wahrung der Entkopplung doch spezielle Objekte erzeugen zu können. Diese sind in [Gamma et

2

Lose Kopplung und Objekterzeugung


2.1


118

al. 96] als Erzeugungsmuster beschrieben. Ein aus unserer Sicht für den WAM-Ansatz besonders geeignetes Erzeugungsmuster, den Produkthändler, stellen wir in Kapitel 3.3.4 vor.

2.1.14 Wert und Objekt Wir haben bereits darauf hingewiesen, daß Werte und Objekte zwei grundlegende Konzepte darstellen, die für die Entwicklung interaktiver Software unerläßlich sind. In diesem Abschnitt geht es uns darum darzustellen, daß die Unterscheidung von Werten und Objekten keine terminologische Spitzfindigkeit ist, sondern wichtig für den Entwurf und die Konstruktion von Softwaresystemen ist. Imperative und damit auch objektorientierte Programmiersprachen bieten häufig beide Konzepte als Sprachmerkmale an. Die Unterscheidung ist aber meist nur implizit und wird selten auf dieser Ebene diskutiert. Wie wir in Kapitel 2.1.7 schon angedeutet haben, ist die konzeptionelle Trennung in einer objektorientierten Programmiersprache wie Smalltalk oft am wenigsten deutlich. Und das, obwohl letztlich alle objektorientierten Sprachen neben der Referenzsemantik eine saubere Wertsemantik anbieten (müssen). Wir werden im folgenden zunächst auf diesen konzeptionellen Unterschied abheben, um

2


2.1


dann in einem zweiten Teil auf die konstruktiven Konsequenzen einzugehen. Wenn wir im folgenden über die Begriffe Wert und Objekt sprechen, dann macht es Sinn, sich zunächst die Unterschiede zwischen diesen beiden Begriffen klarzumachen. Die folgende Anordnung ist daher schematisch und ohne besondere Reihenfolge gewählt (s. Abbildung 2-13). Sie stützt sich auf den für dieses Thema grundlegenden Artikel [MacLennan 82].

119 Wert und Objekt als Konzepte

Abb. 2-13 Wert

Objekt

zeit- und ortlos

existiert in Raum und Zeit

abstrakt, ohne Identität, nur Gleichheit

konkret, mit Identität und Gleichheit

definiert oder undefiniert, aber nicht veränderlich

veränderbar bei Wahrung der Identität

kann nicht gemeinsam benutzt werden

kann über Verweise gemeinsam genutzt werden

2

Eigenschaften von Wert und Objekt


2.1


Ein Wert ist zeit- und ortlos:

120 Eigenschaften eines Werts

❑ Begriffe wie Zeit, Dauer und Ort sind nicht anwendbar. Werte

haben keinen Anfang und kein Ende, und sie existieren an keinem bestimmten Platz. In Ausdrücken entstehen keine Werte, und sie werden nicht verbraucht. Beispiel: 40 + 2 = 42 In dieser Gleichung macht es keinen Sinn, über Zeit zu reden oder darüber, daß durch die Addition ein neuer Wert »erzeugt« wird. Es ist auch sinnlos, von »der 42 oben« zu reden, wenn wir den Wert und nicht seine konkrete Repräsentation durch Ziffern meinen. ❑ Dagegen existieren Objekte in Zeit und Raum und haben einen

Anfang und ein Ende. Zwei Objekte können sich nur dadurch unterscheiden, daß sie an verschiedenen Orten sind. Beispiel: Ein Ordner kann erzeugt werden. Zwei ansonsten gleiche Ordner können sich an verschiedenen Orten befinden. Es macht Sinn, über »mein Ordner gestern« zu reden.

2


2.1


121

Ein Wert ist abstrakt und ohne Identität: ❑ Ein Wert abstrahiert von allen konkreten Kontexten. Er ist

nicht an die Existenz konkreter Dinge gebunden. Da er keine Identität, sondern nur die Gleichheit besitzt, macht es keinen Sinn, über mehrere Exemplare eines Wertes (wohl aber seiner Repräsentation) zu reden. Beispiel: 50 DM sind ein Wert. Es gibt zwar viele Banknoten, die diesen Wert repräsentieren, aber nicht mehrere Exemplare des Werts selbst. Es ist auch nur sinnvoll, darüber zu reden, ob eine Banknote 50 DM wert ist oder nicht. Dagegen sind Objekte konkrete Exemplare eines allgemeinen Konzepts (einer Klasse), die eine Identität haben. Es kann viele gleichwertige, aber verschiedene Exemplare einer Klasse geben. Beispiel: Auf einem elektronischen Schreibtisch lassen sich mehrere Exemplare eines Antragsfomulars erzeugen, die sich nur dadurch unterscheiden, daß sie in verschiedenen Mappen liegen.

2


2.1


122

Ein Wert ist unveränderlich: ❑ Werte können zwar berechnet und aufeinander bezogen wer-

den; sie verändern sich dabei nicht. Werte können benannt werden. Dadurch kann der Wert eines Bezeichners oder eines Namens (einer »Unbekannten«) noch nicht berechnet oder auch undefiniert sein. Mit dem gleichen Namen kann je nach Kontext ein anderer Wert verbunden werden. Beispiel: 40 + x = 42; pi = 3,14 Hier ist die Vorstellung falsch, daß die Zahl 40 durch Addition von x ihren Wert zu 42 verändert. x ist in diesem Sinne auch keine Variable, sondern hat einen berechenbaren Wert. Wir können der Zahl 3,14 den Namen pi geben, und wir können mit pi in einem anderen Kontext den Wert 3,1415 verbinden. ❑ Dagegen kann ein Objekt in der Zeit verändert werden, d.h., sein Zustand kann sich ändern, ohne daß seine Identität verlorengeht. Diese Identität muß auch nicht an einen bestimmten Namen geknüpft sein. Beispiel: Das gestern erzeugte Antragsformular kann heute bearbeitet und morgen unterschrieben werden. Dabei kann es von »Neuer Antrag« in »Bearbeiteter Antrag« umbenannt werden, ohne daß es seine Identität verlieren würde.

2


2.1


123

Ein Wert kann nicht gemeinsam benutzt werden: ❑ Da ein Wert keine Identität und keinen Ort hat und da er unver-

änderlich ist, läßt sich auf der Basis reiner Werte Kommunikation und Kooperation schlecht aufbauen, denn Werte können nicht ausgetauscht und bearbeitet werden. Wenn trotzdem auf der Basis von Werten kommuniziert und kooperiert werden muß, wird oft ein ausgewiesener Wert zur »Konstruktion« einer Identität verwendet. Beispiel: Der abstrakte Wert 500 DM nützt im Bankgeschäft wenig. Erst wenn er im Zusammenhang eines Kontos verwendet wird und wenn dieses Konto in seiner zeitlichen Veränderung gesehen wird, dann läßt sich kooperativ damit arbeiten. Um ein Konto z.B. in einer wertbasierten Datenbank zu konstruieren, wird die Kontonummer zur eindeutigen Identifikation der mit dem Konto verbundenen anderen Werte verwendet. ❑ Objekte lassen sich dann gemeinsam nutzen, wenn sie über

Referenzen zugänglich sind. Dann können sie über Namen an verschiedenen Orten bekannt sein. So dienen sie als gemeinsamer Arbeitsgegenstand. Damit verbunden ist dann allerdings das Alias-Problem: Ein Objekt kann in einem Kontext verändert werden, ohne daß dies unmittelbar im anderen Kontext bemerkt wird.

2


2.1


124

Beispiel: Ein Formular ist auf zwei elektronischen Schreibtischen über Bezeichner zugänglich. Dann können zwei Mitarbeiter nach Absprache wechselweise daran arbeiten und ihre Arbeit auch über dieses Formular koordinieren. Es wird aber problematisch, wenn ein Mitarbeiter nicht weiß, daß ein Kollege Zugang zu diesem Formular hat und es vielleicht ohne Absprache geändert hat. Wenn wir an die Verwendung von Werten denken, fallen uns vielleicht als erstes die Mathematik oder die Ingenieurwissenschaften ein. Dort steht die numerische Analyse im Vordergrund: Mathematische Probleme werden durch Operationen auf Zahlen, als einer Form von Werten, gelöst. Aber im Alltagsleben haben Werte und Zahlen eine viel umfassendere Bedeutung. Sie dienen auch dazu, Dinge zu identifizieren, zu charakterisieren, abzuzählen und zu ordnen und schließlich als meßbare Größen zu repräsentieren. Wir verwenden Werte allgemein gesprochen immer dann, wenn wir abstrakte Größen modellieren und dabei weitgehend von allen konkreten und gegenständlichen Eigenschaften absehen wollen. Dabei wird auch vom Kontext des Gegenstandes abstrahiert, für den ein Wert steht. In diesem Sinne können die Autoren eines verbreiteten

2

Verwendung von Werten


2.1


125

Lehrbuchs über funktionale Programmierung [Bird & Wadler 92] auch formulieren: »Vielleicht gibt es irgendwo im Weltraum ein Universum abstrakter Werte. Für unseren Planeten gilt auf jeden Fall, daß Werte nur durch ihre Repräsentationen erkannt und manipuliert werden können. Es gibt viele Repräsentationen für ein und denselben Wert.« Was bedeutet das praktisch? Wir benötigen Werte und Zahlen immer dann, wenn wir rechnen und ordnen müssen. Unbestritten brauchen wir dann ganze oder reelle Zahlen, aber auch DM-Beträge oder Zeiträume. Auch wenn wir von den konkreten Umständen eines Gegenstandes absehen und meßbare Größen darstellen wollen, sind uns Werte wie eine Bankleitzahl oder der aktuelle Wert des DAX (Deutscher Aktien-Index) nützlich. In diesem Handbuch behandeln wir immer wieder Fragen der objektorientierten Programmierung. Wenn wir über Werte reden, müssen wir festhalten, daß eine wirklich glatte Übertragung des abstrakten Wertbegriffs auf Programmiersprachen halbwegs nur bei rein funktionalen Sprachen wie Miranda oder Hope geglückt ist. Wenn wir die Merkmale funktionaler Programmierung in diesen Sprachen betrachten, können wir einen wertorientierten Programmierstil identifizieren. Diesen wertorientierten Programmierstil verwenden wir immer dann,

2

Wertorientierter und objektorientierter Programmierstil


2.1


126

wenn wir mit Werten in Programmen umgehen müssen, und sie mit den Möglichkeiten einer objektorientierten Programmiersprache in Einklang bringen. Ein wertorientierter Programmierstil ist gekennzeichnet durch: ❑ Verwendung »reiner« Ausdrücke auf der Basis von Funktionen ohne Seiteneffekte, ❑ mit Nähe zu an algebraischen Ausdrücken und ❑ mit mathematischem Variablenbegriff. Konzeptionell bedeutet das referentielle Transparenz: ❑ Ein Ausdruck kann vollständig auf der Basis seiner Teilausdrücke verstanden werden. ❑ Jeder Teilausdruck ist unabhängig von seinem Kontext. ❑ Eine Variable ist ein Name für einen (bekannten oder unbekannten) unveränderlichen Wert.

Von einem wertorientierten Programmierstil sprechen wir dann, wenn die folgenden Merkmale gelten:

Merkmales eines wertorientierten Programmierstils

2


2.1


127

❑ Auswertung »reiner« Ausdrücke, die aus Funktionen bestehen.

Funktionen haben keine Nebeneffekte und sind nahe am Konzept algebraischer Ausdrücke. ❑ Einen mathematischen Variablenbegriff, d.h., eine Variable ist

ein Name für einen bekannten oder noch nicht bekannten Wert (wie in »Gleichung mit zwei Unbekannten«). Dieser Wert kann sich aber nicht verändern. ❑ Referentielle Transparenz, d.h., ein Ausdruck kann vollständig

auf der Basis seiner Teilausdrücke verstanden werden, und jeder Teilausdruck läßt sich unabhängig von seinem Kontext durch einen wertgleichen ersetzen. In diesem Kapitel über das WAM-Objekt-Metamodell haben wir die Grundzüge eines objektorientierten Programmierstils skizziert. Das bedeutet in diesem Zusammenhang: ❑ Verwendung von Objekten, die einen inneren Zustand kap-

seln, der nur über zulässige Operationen sichtbar und veränderbar ist. ❑ Verwendung des imperativen Variablenkonzepts, d.h., eine

Variable ist ein Bezeichner für einen Speicher oder Behälter,

2


2.1


128

dessen Zustand (oder Wert) sich durch Zuweisung verändern läßt. ❑ Jeder Ausdruck ist abhängig von seinem Kontext, d.h. von dem

Zustand aller beteiligten Objekte. Da ein Objekt unter mehreren Namen in verschiedenen Kontexten bekannt sein kann, lassen sich die Teile eines Ausdrucks selten nebenwirkungsfrei austauschen. Schon auf dieser Ebene wird klar, daß der wertorientierte und der objektorientierte Programmierstil grundlegend voneinander abweichen. Wenn wir also mit den Mitteln einer objektorientierten Programmiersprache wertorientiert arbeiten wollen, dann müssen wir überlegen, ob wir diese Eigenschaften nachmodellieren können. Betrachten wir objektorientierte Programmiersprachen, dann stellen wir fest, daß viele Sprachen Werte als sogenannte primitive oder eingebaute Typen zur Verfügung stellen. Beispiele sind Integer, Floating Point Number oder Boolean. Diese Werttypen verhalten sich, wie wir es von Werten oder Zahlen erwarten (wenn man einmal von den Präzisionsfehlern durch die notwendige Repräsentation in einem endlichen Rechner absieht). Einige »puristische« Sprachen wie Java, Eiffel oder Smalltalk betten diese Werttypen in das normale Klassenkonzept ein. Diese Einbet-

2

Werte im Objekt-Metamodell


2.1


tung kann aber nicht bruchlos sein, da bestimmte Eigenschaften von Objekten nicht einfach auf »Wertobjekte« übertragen werden können. So würden arithmetische Ausdrücke ihre mathematische Semantik verlieren, wenn das Objekt »3« über eine Operation den internen Wert 4 erhalten könnte. In diesem Sinne finden wir es verwirrend, wenn, wie im Smalltalk-Handbuch [Goldberg & Robson 89] als eines der ersten Beispiele für Objekte und ihre Operationen die Zahlenarithmetik verwendet wird. Wir wollen Zahlen haben, die sich wie Werte verhalten, und Objekte, die alle Objekteigenschaften haben. Während die eingebauten Werttypen in ihrer Verwendung unproblematisch sind, stellt sich das eigentliche Konstruktionsproblem erst dann, wenn wir benutzerdefinierte, d.h. eigene Werttypen einführen wollen. Solche Werte wollen wir »Fachwerte« nennen, da sie aus dem jeweiligen Anwendungsbereich unseres Systems motiviert sind. Die Motivation für Fachwerte dürfte offensichtlich sein. Schon in den frühen Programmiersprachen wollten die Sprachentwickler solche Datentypen bereitstellen, die im Anwendungsbereich benötigt wurden. Dies war nur nicht so offensichtlich, da die frühen Anwendungen mathematisch-numerisch ausgerichtet waren. Im Rahmen des WAM-Ansatzes kommt den Fachwerten aber eine herausragende Bedeutung zu. Wenn wir sagen, daß wir mit Klassen und Objekten die Konzepte und Gegenstände des Anwendungsbe-

2

129

Benutzerdefinierte Werttypen


2.1


130

reichs modellieren wollen, dann gilt dies in geeigneter Weise auch für die Werte, die im jeweiligen Anwendungsbereich eine Rolle spielen. Verdeutlichen wir die Idee der Fachwerte gegenüber der konventionellen Konstruktionsweise an einem Beispiel: Ein Konto hat bekanntlich eine Kontonummer. In einem objektorientierten Anwendungssystem ist ein konkretes Konto Exemplar der Klasse Konto. Die Kontonummer sollte in diesem Objekt ein Fachwert vom Typ Kontonummer sein. Das entsprechende Attribut hat den Bezeichner Kontonummer. Üblich ist dagegen, ein Attribut vom Typ Integer zu deklarieren. Daß dies eine Kontonummer repräsentiert, ist nur am Bezeichner Kontonummer zu erkennen. Fachwert: Ein Fachwert ist ein benutzerdefinierter Wert. Er repräsentiert Werte im Anwendungsbereich. Ein Fachwert ist ein Werttyp mit definierter Wertemenge und festgelegten Operationen. Seine innere Repräsentation ist verborgen. Fachwerte werden in objektorientierten Sprachen als Klassen definiert. Wichtig ist, daß die Exemplare eines Fachwerts immer Wertsemantik besitzen, d.h. daß ein einmal gesetzter Wert nicht mehr verändert werden kann.

2


2.1


Zur Konstruktion benutzerdefinierter Fachwerte haben wir in objektorientierten Sprachen das Klassenkonstrukt zur Verfügung. Nur durch Klassen können neue Typen und gleichzeitig Exemplare dieser Typen ins System hineinkommen. Dies bietet zunächst Vorteile: In einer benutzerdefinierten Klasse kann der Entwickler festlegen, welche Wertemenge als Exemplare des Typs erzeugt werden kann. Dazu kann eine Klasse eine externe Repräsentation des gewünschten Wertes nehmen und nur dann ein entsprechendes Fachwertobjekt erzeugen, wenn die angebotene Repräsentation in einen gültigen Wert überführt werden kann. In diesem Zusammenhang lassen sich weiterführende Konzepte realisieren, wie die Einführung des sogenannten »undefinierten Werts« (Bottom) und anderer besonderer Werte in die Menge der gültigen Werte. Dies hat den Vorteil, explizit zwischen den definierten und den besonderen Werten unterscheiden zu können (vgl. [Cunningham 95]). Viele Entwickler behelfen sich nämlich bisher so, daß sie z.B. für eine noch nicht bekannte Kontonummer, die sie als Integer repräsentieren, den Wert 999 verwenden. Damit haben sie dann einen definierten Wert des Typs Integer per Konvention zum undefinierten Wert gemacht. In Programmen, die sich nicht an diese Konvention halten, kann dies dann zu schweren fachlichen Fehlern führen, ohne daß dies einfach

2

131 Realisierung von Fachwerten


2.1


abzufangen wäre. Das dahinterstehende Problem läßt sich dadurch lösen, daß Fachwerte nicht als reine Wertemenge betrachtet werden. Schon seit den Arbeiten von Hoare (vgl. [Hoare72]) wissen wir, daß zum Typbegriff nicht nur die definierende Wertemenge, sondern auch die auf den Werten dieses Typs zulässigen Operationen gehören. Während dies für benutzerdefinierte Typen in den klassischen imperativen Sprachen nur schwer zu realisieren war, erhalten wir diese Möglichkeit in objektorientierten Sprachen sozusagen »frei Haus«. Wir können z.B. darüber nachdenken, welche Operationen auf Werten des Typs Kontonummer zulässig sind. Dies ist nur auf den ersten Blick trivial. Denn neben der Vergleichsoperation müssen sich Kontonummern auch addieren lassen, da die Summe der Kontonummern im Rahmen einer Sammelüberweisung zwischen Banken als Prüfziffer mitgegeben wird. In einigen Banken ist es zudem üblich, einer Kontonummer zusätzliche Informationen mitzugeben. So lassen sich aus einer Kontonummer etwa die Kundennummer oder die Art des Kontos herauslesen. Auch dies sind dann zulässige Operationen des Typs. Mit der Einführung der besonderen Werte läßt sich auch eine entsprechende Semantik für den Umgang mit diesen Werten festlegen. In unserem Beispiel könnte der Versuch, eine undefinierte Kontonummer

2

132 Operationen auf Wertobjekten


2.1


133

zu einer »normalen« zu addieren, zu einer Ausnahme (Exception) führen. Fachwerte als Klassen zu realisieren hat allerdings auch einige Fußangeln, auf die geachtet werden muß. Darauf hat schon Cunningham in einem Artikel [Cunningham 95] hingewiesen. Vorrangig ist zu beachten, daß Werte von Fachwertklassen immer mit Wert- und nicht mit Referenzsemantik behandelt werden. Das bedeutet, daß ein Fachwertobjekt nicht über zwei Bezeichner veränderbar zugänglich sein darf. Genau genommen sollte ein Fachwertobjekt überhaupt nicht veränderbar zugänglich sein. Nur so läßt sich die geforderte referentielle Transparenz von Werten aufrechterhalten. Verschiedene Lösungen bieten sich an, von denen wir einige in Kapitel 3.2.8 detaillierter betrachten: ❑ Fachwerte sind Exemplare »normaler« Klassen. Fachwertob-

jekte werden immer nur als Kopien weitergegeben. Dies ist eine unsichere Programmierkonvention.

Konstruktion von Fachwerten

❑ Fachwerte werden über Klassen konstruiert, die nur einmal

eine wertsetzende Operation zulassen und ansonsten nur sondierende Operationen anbieten. Dies ist speicherintensiv.

2


2.1


134

❑ Verfeinerte Techniken der Konstruktion von Wertobjekten

sind unter dem Namen Body/Handle in der Literatur bekannt (vgl. [Coplien 92]). ❑ Ein Muster, das Wertobjekte mit minimalem Platzbedarf reali-

sierbar macht, ist das Fliegengewicht (s. [Gamma et al. 96]).

2.1.15 Metaobjekt-Protokolle Objektorientierte Programmiersprachen haben ein polymorphes Typsystem, das durch Vererbung und dynamisches Binden realisiert ist. Dazu kommt meist das Kapselungsprinzip, d.h., die Repräsentation des Objektzustands und die Implementierung von Operationen sind im Inneren eines Objekts und der definierenden Klassen verborgen. Diese softwaretechnisch sehr wünschenswerten Eigenschaften objektorientierter Sprachen können sich als Beschränkungen beim Entwurf und der Programmierung herausstellen. Welche Beschränkungen dies sind und wie sie durch die Mechanismen eines sogenannten Metaobjekt-Protokolls aufgehoben werden können, diskutieren wir in diesem Abschnitt. Dabei weisen wir auch auf die Folgen hin, die der (undisziplinierte) Einsatz dieser Mechanismen haben kann.

2


2.1


135

Bei der objektorientierten Anwendungsentwicklung haben wir, vereinfacht gesprochen, Objekte dazu verwendet, Gegenstände eines Anwendungsbereichs zu modellieren. Wir wollen jetzt einmal Softwaretechnik als einen möglichen Anwendungsbereich betrachten. Dies tun wir immer dann, wenn wir Programmierwerkzeuge oder andere Hilfsmittel zur Softwareentwicklung konstruieren. Ist Softwaretechnik unser Anwendungsbereich, dann spricht nichts dagegen, ein objektorientiertes Programm als Gegenstand der Modellierung zu wählen. Merkmale dieses Gegenstands sind dann die Konstrukte der Programmiersprache, in der das Programm geschrieben ist. Diese Konstrukte können wir selbst wieder als Objekte modellieren. Solche Objekte werden Metaobjekte genannt. Wie jedes Objekt sind auch Metaobjekte Exemplare von Klassen, den sog. Metaklassen. Die Menge der Schnittstellen dieser Metaklassen bildet ein MetaobjektProtokoll (MOP). Dies ist z.B. für einen Smalltalk-Programmierer nichts Neues.

2


2.1


ausführbares Programm mit MOP Anwendungsbereich

ausführbares Programm

Modell des Anwendungsbereichs

136 Abb. 2-14 Modellierung eines Anwendungsbereichs und Modellierung eines Programms

Programm

Modell des Programms

Meta-Konstrukte

Metaobjekte lassen sich in zwei Kategorien einteilen: ❑ Objekte, die das (statische) Anwendungsmodell repräsentieren

(z.B.: Welche Operationen bietet ein Objekt?). ❑ Objekte, die das Laufzeitsystem repräsentieren (z.B.: Wie wird

eine Operation ausgeführt? Wie greift ein Objekt auf seine Attribute zu?). Die Organisation von Metaklassen und das Verhalten von Metaobjekten wird durch eine Metaebenen-Architektur beschrieben. Metaebenen-Architekturen können für ganz unterschiedliche technische Zwecke eingesetzt werden. Sie werden aber zumeist nur bei sehr gro-

2


2.1


137

ßen Anwendungssystemen benötigt. Im folgenden beschreiben wir deswegen nur die bekanntesten Anwendungen genauer und verweisen den Leser auf die entsprechende Literatur [Kiczales et al. 92, Maes & Nardi 88, Yonezawa & Smith 92, Zimmermann 96]. Repräsentation des Anwendungsmodells

Die Ausnutzung der Polymorphie bringt es mit sich, daß die Referenz, die man auf ein Objekt hält, nicht denselben Typ hat wie das Objekt selbst, sondern einen Supertyp des Objekttyps. Es gibt einige Situationen, in denen diese Supertyp-Referenz nicht mehr ausreicht, und daher ein sogenanntes Downcast, d.h. die Umwandlung einer Supertyp-Referenz in eine Subtyp-Referenz, erforderlich ist:

Runtime Type Information (RTTI) zur Realisierung des Downcasts

❑ In einem spezialisierten Team von Klassen erhält ein Partner

die Referenz auf einen anderen Partner als Referenz mit dem Typ der abstrakten Oberklasse, benötigt aber die volle (erweiterte) Schnittstelle. ❑ Ein Behälter, der Objekte verschiedener Klassen enthält, kann

nur eine Referenz auf die gemeinsame Oberklasse der enthaltenen Objekte zurückgeben. Wenn auf ein aus dem Behälter

2


2.1


138

genommenes Objekt über seine volle Schnittstelle zugegriffen werden muß, ist ein Downcast erforderlich. ❑ Ein Spezialfall ist die Einrichtung einer systemweiten Objekt-

tabelle, die Referenzen auf alle im System vorhandenen Objekte enthält und ständig aktualisiert wird (s. [Gamma 92]). Mit Hilfe einer solchen Tabelle kann man datenbankartige Abfragen über die Objekte realisieren (z.B. »Suche alle Pausen, in denen Lehrer Müller ein Beaufsichtiger ist«). Dazu muß die Klassenzugehörigkeit jedes Objekts abfragbar sein, und die Referenzen der Objekte, die typkompatibel zur abgefragten Klasse sind, müssen auf den abgefragten Typ konvertiert werden (Downcast: im Beispiel von einer Referenz auf Object zu einer Referenz auf Pause) Um die ursprüngliche Typinformation wiederzugewinnen, bietet daher jedes MOP die Möglichkeit, den Typ eines Objekts zur Laufzeit zu erfragen. Meistens repräsentiert man den Typ eines Objekts durch das bereits erwähnte Klassenobjekt. Ein Downcast auf Objektebene führt zur Überprüfung einer Vererbungsbeziehung auf Klassenobjektebene (Metaebene) Aus Bequemlichkeitsgründen, um die Komplexität der Metaebene zu verstecken, bieten die MOPs typisierter Sprachen für den Downcast

2


2.1


einen speziellen Operator an, der intern auf die Klassen-Metaobjekte zugreift und die Zulässigkeit des Casts prüft, bevor er ihn durchführt. Ohne diesen Schutz kann der Downcast zu schweren Fehlern in Programmen führen und sollte nur im Rahmen streng kontrollierter Programmierkonventionen verwendet werden. Üblicherweise ist der direkte Zugriff auf die Zustandsrepräsentation von Objekten unter Umgehung ihrer Schnittstelle eine der größten softwaretechnischen Sünden, die man begehen kann. Voraussetzung für dieses Diktum ist, daß die Klasse eine Menge von aufgabenangemessenen Operationen anbietet, welche den Zugriff auf die Zustandsrepräsentation verstecken. Es gibt aber auch technische Aufgabenstellungen, für welche die angemessene Schnittstelle den direkten Zugriff auf die Zustandsrepräsentation ermöglicht. Beispiele für Aufgaben, welche auf die Zustandsrepräsentation eines Objekts zugreifen müssen, sind:

139

Information über die Zustandsrepräsentation zur Realisierung generischer Operationen

❑ Generische Vergleichs- und Kopieroperationen; so kann z.B.

das Kopieren von Pausen und Pausenaufsichtsorten in eine Zwischenablage und das anschließende Einfügen der Kopie in den Pausenplan mit Hilfe generischer Kopieroperationen realisiert werden;

2


2.1


140

❑ Objekt-Ein- und -Ausgabe, z.B. zum Speichern in Dateien,

Anschluß an relationale Datenbanken, Transportieren von Objekten in einem verteilten System; ❑ Garbage Collection.

Ist der Zugriff auf die Repräsentation des Objektzustands möglich, dann läßt sich ein für alle Klassen gültiger Algorithmus für diese Dienstleistungen angeben. Andernfalls müssen für jede Klasse die entsprechenden Operationen neu programmiert werden. Der Zugriff auf den Objektzustand kann auf zwei Arten erfolgen: ❑ Die benötigte Information steht implizit zur Verfügung, indem

die notwendigen Operationen automatisch generiert werden. In Eiffel werden z.B. Vergleichs-, Kopier- und Ein-/Ausgabeoperationen für jede Klasse ohne Zutun des Entwicklers zur Verfügung gestellt. Dieser Ansatz hat mehrere Vorteile: Der Entwickler muß nichts selbst programmieren. Die Kapselung der Objekte kann nicht mehr verletzt werden. Schließlich ist insbesondere bei Compilersprachen das Laufzeitverhalten deutlich besser. Der Nachteil besteht in der fehlenden Flexibilität: Die Zugriffsoperationen können vom Entwickler weder modifiziert noch können neue Operationen hinzugefügt werden.

2


2.1


141

❑ Dem Entwickler steht die Repräsentation des Objektzustands

als sog. Attribute Dictionary zur Verfügung. Das Verzeichnis enthält für jedes Attribut ein Attribut-Metaobjekt, das (je nach Sprache unterschiedlich) folgende Informationen anbietet: – Name der Variablen – Typ der Variablen – Größe der Variablen – Referenz auf die Variable (für den eigentlichen Zugriff) – sonstige Attribute (z.B. Kennungen wie »persistent« / »nicht persistent«). Auf dieser Basis und der Information über die Oberklassen kann der Entwickler selbst Operationen schreiben, die über die Attribut-Metaobjekt-Liste iterieren und für jede Variable eine bestimmte Aktion durchführen (z.B. Kopieren, Vergleichen, in Datenbank speichern). Nachteile dieser Variante sind die aufgehobene Zustandskapselung und ein verschlechtertes Laufzeitverhalten. In vielen Fällen ist es erwünscht, eine Anwendung nach »außen« zu öffnen, d.h., es soll ermöglicht werden, daß andere Anwendungen beliebige öffentliche Operationen aufrufen. So kann ein externer Interpreter zur Programmierung häufig vorkommender Abläufe in einem Script verwendet werden (vgl. [Kofler et al. 94]).

2

Information über die Schnittstellen zur Realisierung des dynamischen Operationsaufrufs


2.1


142

Falls zum Beispiel eine Pause in einem nicht wöchentlich wiederkehrenden Zeitraum vorkommt (z.B. Theater-AG alle zwei Wochen, Beaufsichtigung vom Ende der letzten Stunde bis Beginn der AG erforderlich), könnte per Script in einer Schleife die erste Pause kopiert, das Datum modifiziert und die kopierte Pause in den Pausenplan eingefügt werden. Um diese Flexibilität zu ermöglichen, muß ein MOP analog zum Attributverzeichnis ein Operationsverzeichnis zur Verfügung stellen, das Abfragen über die vorhandenen Operationen und ihren Aufruf erlaubt. Ein solches Verzeichnis enthält für jede Operation ein Operations-Metaobjekt mit folgenden Informationen: ❑ Name der Operation ❑ Signatur der Operation ❑ sonstige Attribute

Der Aufruf der Operation erfolgt entweder über das OperationsMetaobjekt oder über eine spezielle Operation (Meta-Call) am nach außen geöffneten Objekt, die als Argumente einen Operationsnamen und weitere Parameter erhält. Diese Operation ruft die eigentliche Operation, die den übergebenen Namen trägt, mit den übergebenen Parametern auf.

2


2.1


143

Repräsentation des Laufzeitsystems

Wenn auch der Softwareentwickler üblicherweise froh ist, daß er über die Implementierung einer Sprache nichts wissen muß, so gibt es doch manche Situationen, in denen er einen Eingriff in die Implementierung vornehmen muß. Dazu kann ihm ein MOP eine wohldefinierte Schnittstelle zur Verfügung stellen, die eine Umlenkung des Kontrollflusses innerhalb des Laufzeitsystems gestattet. Dies ist an zwei Stellen interessant: ❑ Speicherung der Exemplarvariablen ❑ Operationsaufruf

Um den Speicherungsalgorithmus von Exemplarvariablen offenzulegen, bedarf es nur zweier zusätzlicher Operationen: einer Operation zum Lesen einer Exemplarvariablen und einer weiteren zum Setzen. In Smalltalk z.B. gibt es die Methode instVarAt: i, die den Wert der i-ten Exemplarvariablen zurückliefert. Die Methode instVarAt: i put: value weist der i-ten Exemplarvariablen den Wert value zu. Diese beiden Methoden werden bei jedem Zugriff auf eine Exemplarvariable aufgerufen. Durch Überladen dieser Methoden läßt sich der Standard-Speicherungsalgorithmus für alle Klassen oder Teile des Klassenbaums durch einen eigenen Algorithmus

2

Eingriff in die Speicherung von Exemplarvariablen


2.1


ersetzen. Dies kann entweder aus Effizienzgründen sinnvoll sein oder wenn Objekte extern gespeichert werden sollen. Für Objekte, die viele Exemplarvariablen haben, die aber selten benutzt werden, kann es platzsparender sein, die Exemplarvariablen nicht in einem zusammenhängenden Speicherblock abzulegen, sondern für jede Exemplarvariable eine Hashtabelle anzulegen und sie dort zu speichern. Wenn der Objektzustand unmittelbar bei jeder Änderung in einer Datenbank aktualisiert werden soll, ist ebenfalls ein Eingriff in den Speicherungsmechanismus erforderlich (mit den Mechanismen der Repräsentation des Anwendungsmodells (s. S. 65) läßt sich nur eine Speicherung des Gesamtobjektes durch expliziten Operationsaufruf realisieren). Der Zugriff auf den Operationsaufruf-Mechanismus wird durch eine Metaoperation ermöglicht, an die jeder Operationsaufruf umgelenkt wird. Diese Meta-Operation kann sowohl vor als auch nach der eigentlichen Ausführung beliebige Aktionen ausführen. Operationsumlenkung ist für folgende Anwendungsbereiche sinnvoll:

144

Eingriff in den Operationsaufruf (Operationsumlenkung)

❑ Verteilte Anwendungen. In diesem Fall bietet der Mechanis-

mus die Möglichkeit, Operationsaufrufe an ein Objekt auf einen anderen Rechner umzulenken. Dazu werden vor dem

2


2.1


145

Aufruf der Operationsname und die Argumente verpackt und an den Server verschickt. Dort wird die eigentliche Operation ausgeführt und das Ergebnis zurückgeschickt. Das Ergebnis wird auf dem Client wieder ausgepackt und an den Aufrufer zurückgegeben. Die statische CORBA-Schnittstelle ist meist auf diese Weise implementiert. ❑ Persistente Objekte. Vergleichbar dem Mechanismus für ver-

teilte Objekte wird bei einem Operationsaufruf auf einem sich nicht im Hauptspeicher befindlichen Objekt der Aufruf abgefangen. Dann wird auf Basis der Objektreferenz das dereferenzierte Objekt aus einer Datenbank geladen, bevor der eigentliche Operationsaufruf auf dem frisch instantiierten Objekt ausgeführt wird. In CORBA entspricht dies der »Incarnation« eines Objekts durch einen Objektadapter. ❑ Zusätzliche Bearbeitung von Operationsaufrufen. Es gibt eine

Vielfalt von Algorithmen, welche man auf einen Operationsaufruf vor oder nach seiner Ausführung anwenden möchte. Einfache Beispiele sind das Mitprotokollieren (Logging, Auditing) von Operationsaufrufen. Ein anderer, schon anspruchsvollerer Algorithmus ist das Überprüfen der Authentizität eines Aufrufers und die Gewährleistung einer bestimmten Sicherheit

2


2.1


146

darüber, ob die Operation von einem bestimmten Klienten auch wirklich aufgerufen werden kann. Praktisch kann hier allen technischen Systemaspekten Rechnung getragen werden. Es gibt unterschiedliche Implementierungstechniken, um einen Operationsaufruf abzufangen und von einem Metaobjekt vor oder nach seiner Ausführung auf dem eigentlichen Zielobjekt bearbeiten zu lassen. Die bekannteste besteht darin, das Zielobjekt vor seinem Klienten durch ein zwischengeschaltetes Proxy-Objekt zu verstecken. Das Proxy fängt den Operationsaufruf ab und leitet ihn an das zuständige Metaobjekt weiter. In einfachen Fällen kann es die Metabearbeitung auch selbst ausführen, siehe zum Beispiel die Sicherheit-Proxies in [Gamma et al. 96, Buschmann et al. 96]. Bei einer zweiten Implementierung wird die einer Sprache zugrundeliegende virtuelle Maschine so verändert, daß sie mit erweiterten Objektreferenzen arbeiten kann. Die Erweiterung besteht darin, daß bei Dereferenzierung der Aufruf direkt an ein entsprechendes Metaobjekt weitergeleitet wird (Pointer Swizzling). Zum Beispiel arbeitet die objektorientierte Datenbank ObjectStore so, wenngleich bei ihr der Aufruf nicht an ein allgemein zugängliches Metaobjekt weitergeleitet wird, sondern lediglich der ObjectStore-spezifische Mechanismus zur Wiederherstellung des bis dato friedlich in der Datenbank schlummernden Objekts aufgerufen wird.

2


2.2

2.2

Leitbilder und Entwurfsmetaphern

147


Ein objektorientiertes Modell definiert, welche Elemente überhaupt bei der Modellierung von Software verwendet werden können. Damit sind die Ausdrucksmittel festgelegt, aber es ist noch nicht gesagt, was und wie modelliert werden soll. Dies ist zunächst eine anwendungsfachliche Frage. Denn ohne ein passendes fachliches Modell des Anwendungsbereichs und seine konstruktive Umsetzung in ein lauffähiges System hat Anwendungssoftware keine Existenzberechtigung. Ein rein fachliches Modell gibt jedoch keine Antwort auf die Frage, wie denn ein interaktives Anwendungssystem nach unseren Vorstellungen gestaltet werden soll. Gestaltung bezieht sich zunächst auf das Layout der Oberfläche (Präsentation) oder die Nutzung der unterschiedlichen Möglichkeiten der Interaktion (Handhabung) mit dem Computer, also auf das, was heute oft Look & Feel heißt. Darüber hinaus bedeutet Gestaltung für uns vor allem das Benutzungsmodell, d.h. die Vorstellung oder das Bild, das sich Anwender und auch die Entwickler vom Einsatz im jeweiligen Anwendungskontext machen. Das Benutzungsmodell soll verdeutlichen, mit welchen Mitteln und auf welche Weise die anstehenden Aufgaben unterstützt werden.

2

Federführung: Heinz Züllighoven Ko-Autor: Guido Gryczan

Gestaltung eines Anwendungssystems


2.2


148

Benutzungsmodell: Ein Benutzungsmodell ist ein fachlich orientiertes Modell darüber, wie Anwendungssoftware bei der Erledigung der anstehenden Aufgaben im jeweiligen Einsatzkontext benutzt werden kann. Das Benutzungsmodell umfaßt eine Vorstellung von der Handhabung und Präsentation der Software aber auch von den fachlichen Gegenständen, Konzepten und Abläufen, die von der Software unterstützt werden. Es ist sinnvoll, ein Benutzungsmodell auf der Grundlage eines Leitbilds mit Entwurfsmetaphern zu realisieren.

Das Bild, das ein Benutzungsmodell bei den Beteiligten hervorruft, sollte nicht nur zweckgebunden sein. Es muß in sich so stimmig sein, daß wir auch bei Anwendungssoftware von einer Einheit von Form und Inhalt sprechen können. Wir suchen daher nach einer Anleitung, wie das gewünschte stimmige Benutzungsmodell bei der Softwareentwicklung gestaltet werden kann. Offensichtlich helfen uns dabei Kenntnisse über die reinen objektorientierten Modellelemente nicht entscheidend weiter. Ein Blick in die Methodenliteratur ist in dieser Beziehung auch wenig hilfreich. Denn zu diesem Thema fassen sich andere Autoren

2

Benutzungsmodell


2.2


objektorientierter Methoden sehr kurz, obwohl hier nach unserer Ansicht ein wirkliches Problem liegt. Ein Rückgriff auf die Gestaltung konventioneller Anwendungssoftware führt zu einem ebenfalls ernüchternden Ergebnis: Die Dominanz der Analyse von Arbeitsprozessen und ihrer ablauforientierten Modellierung verbunden mit Methoden der hierarchischen Dekomposition haben zu einer Unzahl von eher einförmigen Systemen geführt, die alle Menübäume mit Maskenfolgen verknüpfen. An dieser Form von sequentieller Systemgestaltung haben auch die Arbeitsplatzrechner mit ihren grafischen Oberflächen wenig geändert. Menüs und Masken der Großrechneranwendungen feiern ihre fröhliche Wiederkehr in Form von Menüleisten und modalen Dialogen. Wenn wir die Möglichkeiten der Objektorientierung und der heute verfügbaren Systemplattformen wirklich ausnutzen wollen, dann müssen wir Gestaltungsrichtlinien haben, wie ein solches System aussehen sollte. Diese Gestaltungsrichtlinien sollten nicht vorrangig technisch orientiert sein, da es uns um die Unterstützung der täglichen Arbeit geht. Jenseits der Technik finden wir Ansätze, beispielsweise in der Software Ergonomie oder im Bereich CSCW (Computer Supported Cooperative Working), die sich mit softwareergonomischen Hinweisen zur menschengerechten und aufgabenangemessenen Gestaltung von Benutzungsschnittstellen beschäftigen.

2

149

Gestaltungsrichtlinien


2.2


150

Ein weitergehendes Benutzungsmodell für objektorientierte Anwendungssysteme hat die Firma Taligent mit »People, Places, and Things« (vgl. [Cotter & Potel 95]) vorgelegt. Dies ist schon ein deutlicher Schritt in die Richtung, die wir hier beschreiben. Doch uns geht es um mehr als ein »Human Interface«. Wir wollen die Einheit der fachlichen Inhalte mit den Formen, in denen sie sich präsentieren. Uns geht es wie den Werkzeugmachern (vgl. [Brooks 96]) und den Maschinenkonstrukteuren. Nur mit dem Unterschied, daß uns die jahrzehnteoder jahrundertealte Tradition dieser Berufe fehlt. Wir wissen zu wenig darüber, wie gute interaktive Software für die Unterstützung von Arbeit aussehen muß. In diesem Zusammenhang gewinnt die von uns geforderte Anwendungsorientierung eine neue Dimension. Was uns fehlt, ist eine gestalterische Sicht und eine Sprache, um über die tägliche Arbeit, die damit verbundenen Aufgaben und deren Unterstützung nachdenken und reden zu können. Da das Benutzungsmodell nicht festgelegt ist, muß es erst als eine Art »Vision« in den Köpfen der Entwickler entstehen. Unser Ansatz bietet hier Leitbilder und Entwurfsmetaphern an. Sie formen das Bild, das uns beim Entwurf interaktiver Anwendungssoftware Orientierung gibt, und sie liefern die Begriffe der Sprache, mit der wir über Entwürfe und Systeme reden können.

2


2.2


151

2.2.1 Leitbilder für Anwendungssoftware Unser Ausgangspunkt für ein Benutzungsmodell ist, daß die Entwickler ein konkretes Bild von der Handhabung und den möglichen Arbeitsformen des zukünftigen Systems entwickeln sollen. Wie dieses konkrete Bild aussieht, läßt sich vorab und allgemein natürlich nicht sagen. Aber wir können Vorstellungen darüber anbieten, wie Arbeit betrachtet und prinzipiell unterstützt werden kann. Eine solche grundlegende Vorstellung bezeichnen wir mit dem Begriff Leitbild. Dieser Begriff war ursprünglich eher in der Psychologie oder der Philosophie zuhause. Heute wird er zunehmend auch im Zusammenhang mit Softwareentwicklung diskutiert.

Leitbild

Leitbild (allgemein): Ein Leitbild ist eine benennbare, grundsätzliche Sichtweise, anhand derer wir einen Ausschnitt von Realität wahrnehmen, verstehen und gestalten. Ein Leitbild repräsentiert immer auch eine Wertvorstellung.

Ein Leitbild im allgemeinen Sinne war für viele Intellektuelle im ausgehenden 19. Jahrhundert sicherlich »der Wissenschaftler« – eine Person, die ohne Vorurteile und religiöse Weltanschauungen nur anhand

2


2.2


152

objektiver mathematischer oder empirischer Erkenntnisse die Phänomene der Welt analysiert und erklärt. Leitbild in der Softwarentwicklung: Ein Leitbild in der Softwareentwicklung gibt im Entwicklungsprozeß und für den Einsatz einen gemeinsamen Orientierungsrahmen für die beteilgten Gruppen. Es unterstützt den Entwurf, die Verwendung und die Bewertung von Software und basiert auf Wertvorstellungen und Zielsetzungen. Ein Leitbild kann konstruktiv oder analytisch verwendet werden.

Da ein Leitbild in der Softwareentwicklung den Entwicklern dabei helfen soll, das fachliche Modell eines Anwendungsbereichs in einen Entwurf des zukünftigen Anwendungssystems zu übertragen, hat es eine konstruktive Funktion. Wir können ein Leitbild aber auch analytisch einsetzen, wenn wir es heranziehen, um bestehende Anwendungssoftware dagegen zu halten und zu bewerten (vgl [Maaß 94]). Eine ähnliche Rolle spielt ein Leitbild, wenn es von Anwendern benutzt wird, um ein Anwendungsprogramm besser zu verstehen und einzusetzen. Im weiteren verwenden wir Leitbilder vorrangig konstruktiv, d.h. für die Softwareentwicklung.

2

Leitbild: konstruktive und analytische Funktion


2.2


153

In der Softwareentwicklung gibt es verschiedene explizite oder implizite Leitbilder. So finden wir etwa in [Maaß & Oberquelle 92, Maaß 94] das Leitbild der Fabrik (s. S. 76) oder das Leitbild vom Computer als Kommunikationspartner. Wir wollen hier nicht den verschiedenen Leitbildern nachgehen, sondern anhand einzelner, besonders für die Objektorientierung wesentlicher Leitbilder klarmachen, welche Merkmale dabei relevant sind (vgl. Abbildung 2-15). Das erste Merkmal, auf das wir hinweisen wollen, ist die wertende Rollenverteilung, die ein Leitbild für die beteiligten Personengruppen, besonders für Entwickler und Anwender, mit sich bringt.

2


2.2

Leitbild

Gestaltungsziel


Rolle der Anwender

Rolle der Entwickler

Objektwelten

Objektorientierung unmittelbar auf den Entwurf übertragen

Impulsgeber, der die Objekte aktiviert

Schöpfer von Miniwelten

Direkte Manipulation von Arbeitsgegenständen

bekannte Arbeitsgegenstände selbstverständlich manipulieren

Akteur, Bearbeiter

Konstrukteur von Artefakten

Fabrik

menschliche Arbeit automatisieren und kontrollieren

Maschinenbediener, Störfaktor

Maschinenbauer, Maschineneinrichter

Arbeitsplatz für eigenverantwortliche Expertentätigkeit

qualifizierte Arbeit durch geeigneten Arbeitsplatz unterstützen

eigenverantwortlicher Experte, der Fachsprache spricht

Werkzeugbauer, Arbeitsplatzgestalter

154 Abb. 2-15 Leitbilder in der Softwareentwicklung

Leitbild Objektwelten

Nehmen wir einmal das Leitbild der Objektwelten, wie wir es z.B. bei [Wirfs-Brock et al. 90] finden. Hier ist Objektorientierung sozusagen selbst zum Leitbild geworden. Betrachtet werden virtuelle Welten von aktiven und miteinander kommunizierenden Objekten eines Systems. Diese Objekte erhalten gelegentlich Anstöße von »außen« und agie-

2


2.2


ren dann entsprechend ihren jeweiligen Rollen als »Akteure« oder »Agenten«. Dieses Leitbild, das wir auch bei [Jacobson 92] finden, paßt gut zur Vorstellung von künstlichen, intelligenten »Artefakten«. Die Benutzer solcher Systeme geraten dabei eher zu Randfiguren, die nur noch Impulse geben, aber mit dem eigentlichen Geschehen im System wenig zu tun haben. Dagegen sind die Entwickler die Schöpfer dieser Miniwelten. Sie überblicken die Zusammenhänge und planen das ganze »Spiel«. Versuchen wir das Leitbild der Objektwelten auf unser Beispiel des Pausenplaners zu übertragen, stoßen wir auf Probleme. Wir hätten dann vielleicht Lehrer und Pausen und Aufsichtsorte als Objekte. Nur fehlt uns eine einfache Vorstellung, wie denn die Pausenplanung vor sich gehen soll. Wenn sich etwa Pausen und Lehrer darüber verständigen sollen, wann ein Lehrer eine Pause beaufsichtigen kann, dann wird das im Konfliktfall recht kompliziert. Alle Regeln und Sonderfälle für die Pausenaufsicht müßten dann entweder bei den Pausenobjekten oder bei den Lehrerobjekten definiert sein. Ist dies nicht der Fall, müssen wir die Person des Pausenplanerstellers »ins Spiel« bringen, was nicht einfach gelingt. Ähnliche Entwurfsprobleme haben wir in einem Einsatzkontext wie dem Bankgeschäft. Die einzelnen Aufgaben etwa des Kredit-

2

155 Akteure, Agenten, Artefakte


2.2


156

geschäfts oder der Anlagenberatung sind in ihrer Erledigung so komplex, daß wir nicht recht wissen, wie wir sie an aktive Objekte delegieren sollen. In der Praxis finden wir daher am ehesten die sogenannten Business Objects. Business Objects sind komplexe anwendungsfachlich motivierte Objekte (wie ein konkretes Bankprodukt oder ein Geschäftskonto), die einen Übergang von der Welt der Datenmodellierung zur Objektorientierung darstellen. Sie bieten fachliche Funktionalität, aber sie werden über eine eigene »Prozeßschicht« aktiviert. Leitbild direkte Manipulation von Arbeitsgegenständen

Bei interaktiven Systemen ist das Leitbild direkte Manipulation von Arbeitsgegenständen [Shneiderman 83] verbreitet. Hier sollen, oft als direktes (mimetisches) Abbild, die einzelnen Arbeitsgegenstände eines gesamten Anwendungssystems so gestaltet werden, daß wir sie scheinbar mit unseren Händen direkt bearbeiten können. Ein in der Praxis durchaus bekanntes Beispiel ist das HyperCard-System auf dem Macintosh, das in den achtziger Jahren das erste und sicherlich verbreitetste Hypertextsystem war. Die Grundidee von HyperCard sind Karteikästen, in denen benutzerdefinierte Karteikarten durch direkte Manipulation angelegt, bearbeitet und durch sogenannte Links verknüpft werden können.

2


2.2


Übertragen wir das Leitbild von der direkten Manipulation auf den Pausenplaner, dann kann der Pausenplanersteller Pausenpläne und Lehrerkarten erzeugen, sie durch direkte Manipulation bearbeiten und in Ordner und Kästen ablegen. Ein Pausenplan kann dann so entstehen, daß der Pausenplanersteller eine Lehrerkarte (mit Drag & Drop) auf ein Feld des Pausenplans zieht. Wir sehen, daß dieses Leitbild durchaus einfach und verständlich ist. In der Einfachheit liegen aber auch seine Grenzen. Komplexere Funktionalität, wie die Statistiken über Pausenverteilung, Wochenstundenberechnungen und ähnliches lassen sich so einfach nicht durch direkte Manipulation erstellen. Dies erweist sich z.B. im Bankenkontext als hinderlich, wenn komplexe Finanzoperationen, wie die Analyse und Bewertung einer Geschäftsbilanz in Rahmen dieses Leitbilds realisiert werden sollen. Ist das Leitbild der direkten Manipultation von Arbeitsgegenständen aus unserer Sicht für Anwendungssysteme vielfach zu begrenzt, so kommt uns doch die Rollenverteilung hier sehr viel stärker entgegen als bei den aktiven Objekten der Objektwelten. Denn bei der direkten Manipulation sind die Benutzer immer die Hauptpersonen, die selbsttätig bestimmen, was mit den Arbeitsgegenständen zu geschehen hat. Die Entwickler sind in der Rolle der Lieferanten von solchen sinnvollen Gegenständen. Sie werden zu Konstrukteuren von »Artefakten

2

157

Diskussion des Leitbilds


2.2


158

nach der Natur«, also von Abbildungen bekannter Arbeitsgegenstände. Was ihnen im Rahmen dieses Leitbildes fehlt, ist die Kontrolle über das gesamte System. Sie sind auf die Entwicklung einzelner Komponenten beschränkt. Diese aus unserer Sicht angenehme Selbstbeschränkung bringt aber gelegentlich den Nachteil mit sich, daß die einzelnen Komponenten sehr schlecht zusammen passen. Fachlich und technisch fehlt ein übergeordneter Zusammenhalt. So sind die verschiedenen Karten aus dem HyperCard-System ohne erheblichen Mehraufwand kaum miteinander verwendbar. Erst allmählich wird das Problem angegangen, Dokumente aus verschiedenen direkt-manipulativen Anwendungssystemen einfach untereinander auszutauschen. Insgesamt zeigen uns die Beispiele jedoch ein weiteres wichtiges Merkmal von Leitbildern: Sie können durch die Verwendung von passenden Metaphern wie Karteikasten oder Formular »plastischer« werden. Leitbild Fabrik

Fast klassisch zu nennen ist das Leitbild Fabrik. Darüber haben wir in unseren Arbeiten wiederholt geschrieben [Budde & Züllighoven 90,

2


2.2


Gryczan 96], denn dieses Leitbild ist für die traditionelle Softwareentwicklung von großer Bedeutung. Mit dem Leitbild der Fabrik ist das Bild des nach starren Regeln arbeitenden Fabrikarbeiters verbunden. Menschliche Arbeit wird tayloristisch modelliert, d.h. aus ihrem Zusammenhang gelöst und auf die wiederholte Bewegung reduziert. Übertragen auf die Benutzung eines Anwendungssystems bedeutet dies, daß die Benutzer – wie am Fließband – durch starre Regeln in ihrem Arbeitsprozeß geführt werden. Der Benutzer des Softwaresystems wird zum Maschinenbediener. Die Maschine (das Softwaresystem) gibt den Takt (die geforderten Eingaben) vor, um den Arbeitsprozeß zu steuern (vgl. [Maaß 94]). Kennzeichnend für das Leitbild Fabrik ist, daß der arbeitende Mensch als potentielle Stör- und Fehlerquelle betrachtet wird. Als Konsquenz soll diese Fehlerquelle entweder durch Automatisierung beseitigt oder durch Kontrolle möglichst weitgehend reduziert werden (vgl. [Floyd et al. 89]). Dabei sehen sich die Softwareentwickler als Maschinenbauer, die diese Softwaremaschinen oder -automaten entwerfen und konstruieren. Vor Ort sind dann minder qualifizierte Maschineneinrichter damit beschäftigt, die möglichen Einstellungen der Maschine auf die jeweilig konkrete Arbeitssituation anzupassen.

2

159

Der Benutzer als Bediener


2.2


160

Wenn wir das Leitbild der Fabrik auf das Pausenplanbeispiel anwenden, ergibt sich folgendes Bild: Der Pausenplanersteller wählt im Hauptmenü den Punkt »Aktuellen Pausenplan ändern«. Im folgenden Untermenü wählt er den Punkt »Pausenaufsicht ändern«. Dann erscheint eine Auswahlliste aller Lehrernamen und die Aufforderung »Wählen Sie die Lehrer, deren Pausenaufsicht geändert werden soll«. Nach Doppelklick auf einen Lehrernamen erscheint die Liste der von diesem Lehrer zu beaufsichtigenden Pausen verbunden mit der Auswahl »Pausenaufsicht löschen / Pausenaufsicht hinzufügen / Pausenaufsicht verändern«. Nach der Auswahl von »Pausenaufsicht verändern« gibt der Pausenplanersteller in einer Maske die gewünschten neuen Daten für eine Pausenaufsicht ein. Anschließend berechnet das Programm, ob die geänderte Pausenaufsicht mit den eingegebenen Randbedingungen (Pausenraster, Befugnissen der Lehrer, Stundenplan) übereinstimmt und gibt im positiven Fall eine entsprechende Meldung aus. Im negativen Fall wird die Inkonsistenz gemeldet und erneut das Eingabemenü dargestellt. Sollte der Pausenplanersteller keinen Überblick darüber haben, welcher Stundenplan zu dem entsprechenden Lehrer gehört, muß er in das Hauptmenü zurück und dort die Option »Stundenpläne bearbeiten« wählen. In dieser Art wird die gesamte Funktionalität des Pausenplansystems sequentiell mit starrer Benutzerführung angeboten.

2


2.2


Das Beispiel zeigt den Charakter und die Begrenztheit des Leitbilds Fabrik. Der Benutzer wird Schritt für Schritt vom Programm geführt und hat nach jeder Auswahl wenige vorgegebene Eingabemöglichkeiten. Durch diese starke Benutzerführung kann ein solches Anwendungsprogramm auch von Personen »bedient« werden, die wenig Umgang mit Computern und nur über recht oberflächliches Anwendungswissen verfügen. Andererseits behindert die starre Ablaufsteuerung ein flexibles und situationsangemessenes Handeln. So ist im Beispiel eine parallele Sicht auf Pausenaufsichten und Lehrpläne nicht vorgesehen und daher auch nicht möglich. Der Lehrplanersteller muß seine Arbeitsweise dem Programmablauf anpassen. Im Bereich der Softwareentwicklung selbst ist das Leitbild der Fabrik unter dem bezeichnenden Namen Software-Fabrik (software factory) immer noch ein aktuelles Thema. Interessant ist, daß als treibendes Motiv für die Einführung der Software-Fabrik der Mangel an qualifizierten Programmierern genannt wird. Das Leitbild Fabrik ist die bekannteste Ausprägung einer generellen ablaufsteuernden Sichtweise (s. [Gryczan 96]). Diese Sichtweise ist für die konventionelle Entwicklung von Anwendungssoftware durchgängig prägend.

2

161 Diskussion des Leitbilds


2.2


Anwendungssoftware mit einer ablaufsteuernden Sicht zu entwickeln bedeutet, Operationen zu implementieren, die menschliche Arbeit ersetzen oder regeln und kontrollieren. Die Kontrolle über den Ablauf der Arbeitsschritte des Menschen liegt beim Programm. Die ablaufsteuernde Sichtweise steht damit hinter der Automatisierung, die generell das Ziel verfolgt, menschliche Arbeit durch Maschinen zu ersetzen oder bis auf notwendige Dateneingabe (Input) zu reduzieren. Dazu werden Pläne und Vorschriften verwendet, die, soweit dies möglich ist, durch Algorithmen auf Computern implementiert werden.

162 Die ablaufsteuernde Sichtweise

Die ablaufsteuernde Sichtweise bei der Softwareentwicklung: 1. Analysiere die Arbeitsabläufe im Anwendungsbereich und erkenne die wiederholbaren Anteile. 2. Bilde daraus einen optimalen, allgemeingültigen Ablauf. 3. Übertrage den algorithmisierbaren Anteil auf den Computer. 4. Steuere die menschlichen Arbeitsanteile (Dateneingabe, Reaktion auf Datenausgabe) durch das Programm.

Diese Idee der Ablaufsteuerung wurde und wird nicht nur in der klassischen Fabrik Fordscher Prägung verwirklicht. Im Bürobereich hält

2

Workflow-ManagementSysteme


2.2


163

sie unter dem aktuellen Schlagwort »Workflow-Management-System« Einzug. Hinter der ablaufsteuernden Sichtweise steht auch hier das Ziel, einzelne Handlungen soweit zu verfeinern, daß sie von einer Maschine ausgeführt oder kontrolliert werden können. Wir wollen an dieser Stelle betonen, daß diese Sichtweise nicht prinzipiell schlecht oder verwerflich ist. Für viele Arbeitstätigkeiten, die mühsam, aufwendig, gesundheitsschädlich sind oder schlicht als störend empfunden werden, wurden erfolgreich Softwaremaschinen gebaut. Heute stellen sich aber viele Arbeitssituationen als zu komplex dar, um sie entsprechend der ablaufsteuernden Sichtweise formalisieren und als Software implementieren zu können. Wir werden diesen Punkt in Kapitel 2.2.3 weiter behandeln.

2.2.2 Entwurfsmetaphern Metaphern sind ein sprachliches Ausdrucksmittel, das wir täglich so oft verwenden, daß es uns kaum noch auffällt. Wer denkt schon bei dem Satz, »das war hart an der Grenze«, an die Trennlinie zwischen zwei Ländern oder Gebieten. Erst wenn jemand eine etwas ungewöhnliche Metapher wie »er ist ein Trampeltier« verwendet, bemerken wir das.

2

Metapher, allgemein


2.2


164

Metapher (allgemein): ist ein sprachliches Ausdrucksmittel, bei dem ein bildhafter Ausdruck (z.B. »Müll«) aus einem Kontext (»Haushalt«) genommen und an die Stelle des eigentlichen Ausdrucks (»ungenutzter Speicherplatz«) in einem anderen Zusammenhang gestellt wird. Metaphern heben bestimmte Eigenschaften oder Gesichtspunkte am ursprünglichen Ausdruck hervor (»ungenutzter Speicherplatz, der möglichst schnell freigegeben werden sollte«).

In unserem Kontext setzten wir Metaphern bewußt ein, um Leitbilder anschaulicher und damit in ihrer Wirkung deutlicher zu machen. Wenn wir also bespielsweise vom Leitbild der direkten Manipulation sprechen, dann helfen uns die Metaphern vom Karteikasten und den darin enthaltenen Karteikarten zu verstehen, was damit gemeint ist. Um zu verdeutlichen, daß wir hier Metaphern zur Gestaltung von Softwaresystemen heranziehen, sprechen wir von Entwurfsmetaphern.

2

Entwurfsmetaphern


2.2


165

Entwurfsmetapher: Eine Entwurfsmetapher ist eine bildhafte, gegenständliche Vorstellung, die ein Leitbild fachlich und konstruktiv »ausgestaltet«, d.h. konkretisiert. Eine Entwurfsmetapher strukturiert die Wahrnehmung und trägt zur Begriffsbildung bei. Sie leitet die Vorstellung und Kommunikation über das, was fachlich analysiert, modelliert und technisch realisiert werden soll. Eine Entwurfsmetapher dient der Gestaltung von Softwaresystemen, indem sie Handhabung und Funktionalität für die Beteiligten verständlicher macht. Eine Entwurfsmetapher hat im WAM-Ansatz immer auch eine technisch konstruktive Interpretation in Form von Konstruktionsanleitungen und Entwurfsmustern.

Entwurfsmetaphern aus dem Bürobereich sind für entsprechende Anwendungssysteme auf den ersten Blick sehr eingängig und sprechend. Das haben wir schon beim Leitbild der direkten Manipulation gesehen. Wir sind schnell daran gewöhnt, auf einem elektronischen Schreibtisch Mappen hin und her zu schieben, Dokumente in Mappen zu legen und andere in den Papierkorb zu werfen. Doch bald merken wir die Beschränkung dieser Metaphern, wenn sie als einzige zur Verfügung stehen: Die »nackte« Hand hift uns nur bei elementaren Aufgaben. In kom-

2


2.2


166

plexeren Anwendungen, wie einem Grafikeditor, kann das Leitbild nur mühsam aufrecht erhalten werden. Dazu müssen wir entweder unseren elektronischen »Zeigefinger« durch das Berühren von entsprechenden Feldern mit besonderen Fähigkeiten (Ovale zeichnen) versehen, oder das Hantieren wird zur lästigen Routinetätigkeit (wiederholtes Verbinden von Rechtecken mit Ovalen durch Pfeile). Hier fehlt die Funktionalität eines Automaten oder eines speziellen Werkzeugs.

2.2.3 WAM-Leitbild und Entwurfsmetaphern Wir suchen für den WAM-Ansatz ein Leitbild, das uns bei der Umsetzung des fachlichen Modells in den Entwurf des zukünftigen Systems anleitet. Dieses Leitbild soll durch plastische Entwurfsmetaphern konkretisiert werden, die uns im Detail Anleitung zur Ausgestaltung der einzelnen Systemkomponenten geben. Schließlich soll die Rollenverteilung, die mit dem Leitbild verbunden ist, zu den Wertvorstellungen passen, die die verschiedenen beteiligten Gruppen von Softwareentwicklung und -einsatz haben.

2


2.2


167

Anforderungen an ein Leitbild und seine Entwurfsmetaphern: Leitbild und Entwurfsmetaphern müssen bruchlos zueinander passen. Sie müssen die Analyse des Anwendungsbereichs, den Entwurf und die Verwendung des Systems durchgängig unterstützen. Die Entwurfsmetaphern müssen neben ihrer fachlichen auch eine technische Interpretation haben.

Leitbild Arbeitsplatz für eigenverantwortliche Expertentätigkeit

Der WAM-Ansatz hat zwei historische und konzeptionelle Wurzeln – die Arbeit von Softwareentwicklern sowie die Büroarbeit im Finanzund Dienstleistungsbereich. Für diese Anwendungsbereiche oder Domänen verwenden wir als explizites Leitbild den Arbeitsplatz für eigenverantwortliche Expertentätigkeit (s. Abbildung 2-15, S. 74). Beispiele sind etwa der Arbeitsplatz einer Kundenberaterin in einer Bank, eines Softwareentwicklers in einem Softwarehaus oder des Pausenplanerstellers an einer Schule. Das gerade vorgestellte Leitbild ist mit einer primären Zielsetzung und Wertvorstellung verbunden, die wir unterstützende Sichtweise nennen (s. [Gryczan 96]). Qualifizierte menschliche Arbeit wird dabei in vielen

2

Die unterstützende Sichtweise


2.2


168

Bereichen als unersetzlich betrachtet. Viele Arbeitswissenschaftler und Ökonomen gehen heute davon aus, daß die Ziele der ablaufsteuernden Sichtweise nicht mehr durchgängig anzustreben sind. Vielmehr wird menschliche Arbeit als wesentlicher Faktor betrachtet, der Marktpositionen sichern kann und hochwertige Dienstleistungen erbringen hilft. Wo diese Ziele im Vordergrund stehen, soll menschliche Arbeit eben nicht durch Softwaremaschinen ersetzt, sondern durch entsprechend flexible Softwarekomponenten unterstützt werden. Damit wandelt sich das Bild vom »naiven« Benutzer oder »Bediener« zum fachlichen Experten, der weder von Software ersetzt werden kann noch soll. Charakteristisch für die unterstützende Sichtweise ist ferner, daß für die Modellierung des Anwendungssystems die Arbeitsgegenstände und -mittel von zentraler Bedeutung sind und nicht kontextfreie Routinen und Abläufe. Denn der fachliche Experte soll je nach Situation in der Lage sein, aufgrund seiner Erfahrung und seines Könnens kreativ das zu tun, was dazu dient, die anstehende Aufgabe mit den vorhandenen Mitteln zu erledigen. Dieses wesentliche Merkmal von Expertentätigkeit muß durch ein unterstützendes Anwendungssystem gefördert und nicht unterbunden werden. Für unseren Ansatz folgt, daß die Kontrolle über den Einsatz der verwendeten Gegenstände immer beim Menschen verbleibt.

2


2.2


Expertentätigkeit ist nicht planlos. Doch Pläne sind dabei keine starren Handlungsanweisungen. Sie helfen den Experten als eine Form von vergegenständlichter Erfahrung. Wie ein Stadtplan geben sie eine Orientierung, ohne jeden Schritt festzulegen. Wie ein Kochrezept liefern sie eine punktuelle Anleitung im Handeln und sind nicht Handlungsvorschriften für den völlig Unkundigen, die jedes Detail vorgeben. Entsprechend werden wir in Kapitel 4.1.3 Möglichkeiten diskutieren, wie Pläne im Rahmen einer unterstützenden Sichtweise in den WAM-Ansatz integriert werden können.

2

169 Expertentätigkeit und Pläne


2.2


170

Merkmale der unterstützenden Sichtweise: ❑ Experten erledigen häufig wechselnde Aufgaben von hoher Komplexität. ❑ Die Arbeit erfordert einen hohen Grad an Qualifikation, Kenntnissen und Erfahrung, der nicht formalisiert werden kann. ❑ Die Erledigung von Aufgaben orientiert sich zielgerichtet an vorhandenen Arbeitsmitteln und -gegenständen und nicht an vorgegebenen Routinen. ❑ Die situative Auswahl von Arbeitsschritten wird durch die vorhandenen Mittel unterstützt und führt zu jeweils adäquaten Ergebnissen. ❑ Pläne werden zur Orientierung und nicht als ausführbare Handlungsvorschrift betrachet. ❑ Die Kontrolle über die Handlung verbleibt beim Menschen.

Das Leitbild Arbeitsplatz für eigenverantwortliche Expertentätigkeit basiert also auf einer unterstützenden Sichtweise. Experten werden in ihrer Arbeit dadurch unterstützt, daß für sie eine geeignete Arbeitsumgebung geschaffen wird. In dieser Arbeitsumgebung sollen sie je nach den Anforderungen der konkreten Situation die Arbeitsmittel und Arbeitsgegenstände vorfinden, die sie zur Erledigung der anstehenden Aufgabe benötigen.

2


2.2


Das Leitbild vom Arbeitsplatz für eigenverantwortliche Expertentätigkeit konkretisieren wir zunächst durch die Entwurfsmetaphern Werkzeug und Material. Während die Mappen, Formulare oder auch Programmtexte unter den Begriff Material fallen, rechnen wir Debugger, Rendite-Modellrechner und Pausenplaner zu den Werkzeugen. In Abbildung 2-16 ist beispielsweise der vereinfachte Arbeitsplatz eines Kundenberaters in einer Bank skizziert.

2

171 Werkzeug und Material


2.2


172

Kulturgeschichtliche und philosphische Anmerkung zu Werkzeug und Material: Menschliche Arbeit ist kulturgeschichtlich durch den Umgang mit Werkzeugen und Materialien geprägt. Obwohl die Frage offen ist, ob Werkzeuggebrauch ursächlich zur Menschwerdung beigetragen hat, herrscht in der Anthropologie doch weitgehende Einigung darüber, daß menschliche Arbeit wesentlich auf dem Werkzeuggebrauch basiert. Für die Erkenntnistheorie hat Heidegger in »Sein und Zeit« die komplementäre Bedeutung von Werkzeug- und Materialverwendung im Arbeitszusammenhang herausgehoben. Er betont besonders die Selbstverständlichkeit, mit der wir bei der täglichen Arbeit mit Arbeitsmitteln und -gegenständen als Werkzeugen und Materialien (dem »Zeug«) umgehen. Dies gilt bezeichnenderweise nicht nur in handwerklichen oder produzierenden Bereichen, sondern auch bei der Büroarbeit. Autoren wie [Mumford77] haben auf die wichtige Rolle von Behältern für die menschliche Kultur hingewiesen.

Bei Ausbildungsseminaren und Kursen hat sich für uns immer wieder bestätigt, daß die Zuordnung von Gegenständen der täglichen Arbeit zu den Kategorien Werkzeug und Material offenbar intuitiv ohne größere Überlegungen möglich ist. Gelegentlich gibt es Diskussionen darüber, ob ein Karteikasten eher zu Werkzeug oder zu Material zu rechnen ist, oder es fällt auf, daß ein Bleistift beim Schreiben auf Papier als

2


2.2


173

Werkzeug betrachtet wird, nicht aber, wenn wir ihn mit einem Spitzer anspitzen. Diese je nach Arbeitssituation wechselnde Zuordnung müssen wir im weiteren im Auge behalten. Grundsätzlich gilt aber die vorläufige Aussage, daß Fachleute bei der Erledigung ihrer täglichen Aufgaben mit Werkzeugen an Materialien arbeiten. Diese Materialien gehen dann in das fertige Arbeitsergebnis ein.

2


2.2


174 Abb. 2-16 Beispiele für Werkzeuge und Materialien auf einem

Hamburger Sparkasse Datum, Unterschrift Kontonummer

BLZ

Kreditinstitut

Empfänger

Betrag

Verwendungszweck

alphabetisch-sortierte Mappe

Formularblock

Bankenarbeitsplatz Kontentrog

Überweisung Post-It-Zettel Stapel

Modellrechner

Vertrag Schreibgerät Terminmappe Kalender

Entwurfsmetaphern helfen uns, den Anwendungsbereich zu verstehen und zu analysieren. Sie spielen auch eine große Rolle, wenn wir über Entwürfe und fertige Anwendungssysteme sprechen. Damit ist die anwendungsfachliche Bedeutung von Entwurfsmetaphern beschrieben. Aber das reicht uns als Softwaretechnikern nicht aus. Denn

2

Metaphern und Muster


2.2


175

schließlich wollen wir es nicht dem einzelnen Entwickler überlassen, wie eine Metapher in einen Softwareentwurf umgesetzt wird und wie dieser Entwurf konstruktiv realisiert werden soll. Bei aller fachlichen Differenzierung, die für jedes konkrete Anwendungssystem notwendig ist, wollen wir zu unseren Entwurfsmetaphern bereits eine Anleitung geben, wie daraus softwaretechnische Entwürfe und passende Architekturen werden. Dazu helfen uns Entwurfsmuster und Rahmenwerke, die mit Hilfe solcher Entwurfsmuster beschrieben sind. In Kapitel 2.3 beschreiben wir die grundlegenden Konzepte von Entwurfsmustern und Rahmenwerken. In Kapitel 3 gehen wir dann auf die konstruktive Umsetzung der Entwurfsmetaphern im WAM-Ansatz ein. Zunächst betrachten wir jedoch die Entwurfsmetaphern genauer, die sich im Rahmen des WAM-Leitbilds vom Arbeitsplatz für eigenverantwortliche Expertentätigkeit bewährt haben. Entwurfsmetapher Werkzeug

Unter einem Werkzeug verstehen wir einen Gegenstand, mit dem wir in einer bestimmten Arbeitssituation andere Gegenstände, die Materialien, bearbeiten, indem wir sie verändern oder ihren Zustand sondieren. Dies gilt im Handwerklichen wie im Haushalt oder bei der Büroarbeit.

2


2.2


Wir halten fest, daß sich die Veränderung nicht von der Sondierung des Zustands trennen läßt. Nur wenn wir das Geräusch des Hammers hören, den Widerstand des Nagels spüren und sehen, wie weit wir den Nagel schon in die Wand geschlagen haben, können wir mit einiger Erfahrung unproblematisch hämmern. Mit einem Werkzeug verbinden wir sowohl eine fachliche Funktionalität (»es ist zu etwas gut«) als auch eine bestimmte Art der Handhabung (»es muß gut in der Hand liegen«). Dabei ist offenkundig die fachliche Funktionalität primär. Wenn wir einen Nagel in die Wand schlagen wollen, dann muß das Werkzeug überhaupt dazu geeignet sein. Erst wenn wir mehr als eine Möglichkeit haben, diese Aufgabe zu erledigen, werden wir zwischen einer Zange, einem 50Gramm-Hammer und einem Vorschlaghammer wählen. Vielfach will der Umgang mit Werkzeug gelernt sein. Ein Stechbeitel kann nicht von jedem Laien sofort eingesetzt werden, um Holz gleichmäßig spanweise abzutragen. Bei der Arbeit entscheiden wir situationsabhängig, wann wir ein Werkzeug zur Hand nehmen und wann wir es auf die Seite legen. Wir werden meist im Rahmen einer Aufgabe mit mehreren Werkzeugen im Wechsel an unseren Materialien arbeiten. Ein Werkzeug vergegenständlicht eine körperliche Routine oder Tätigkeitsfolge. Der Hammer verkörpert sozusagen das Hämmern.

2

176 Verändern und sondieren

Umgang mit Werkzeug


2.2


177

Wenn wir nicht wissen, was Hämmern ist, bleibt der Hammer für uns ein unverständliches Ding. Werkzeug: Werkzeuge sind Gegenstände, mit denen Menschen im Rahmen einer Aufgabe Materialien verändern oder sondieren können. Werkzeuge eignen sich meist für verschiedene fachliche Zwecke und für die Arbeit an unterschiedlichen Materialien. Sie müssen geeignet gehandhabt werden. Werkzeuge vergegenständlichen wiederkehrende Arbeitshandlungen. Viele konzeptionelle Eigenschaften von (Hand-) Werkzeugen lassen sich auf Softwarewerkzeuge übertragen. Eine direkte Abbildung der Handhabung und Gestalt ist aber selten sinnvoll.

Wenn wir jetzt von den Werkzeugen des Alltags zu Softwarewerkzeugen im Computer übergehen, können wir zunächst die genannten Merkmale übernehmen. Ein Softwarewerkzeug soll Material sondieren oder verändern. Wir müssen es je nach Situation ergreifen und zur Seite legen können. Es sollte für verschiedene Zwecke und Materialien geeignet sein.

2

Softwarewerkzeuge


2.2


178

Allerdings können wir bei der Vielfalt der »normalen« handgreiflichen Werkzeuge selten eine unmittelbare simulierende Abbildung eines (Hand-) Werkzeugs in Software vornehmen. Zwar läßt sich oft das fachliche Konzept hinter der Routine eines Werkzeugs übertragen, aber die Handhabung verändert sich. Und mit der veränderten Handhabung muß sich auch die Gestalt des Werkzeugs wandeln. Es macht keinen Sinn, einen Bleistift im Rechner in seiner Gestalt und Handhabung zu simulieren. Der Versuch, einen solchen elektronischen Bleistift mit der Maus zu packen und zum Schreiben zu verwenden, endet (wie man leicht am Beispiel der alten Version des Zeichenprogramms MacDraw feststellen konnte, wo es einen solchen mimetischen Bleistift gab) in unlesbarem, umständlichem Gekrakel. Dagegen ist es wichtig, die verschiedenen fachlichen Funktionen eines Bleistifts zu erkennen – Schreiben, Zeichnen, Markieren, Zeigen, Ausstreichen –, um diese geeignet in ein oder mehrere Softwarewerkzeuge umsetzen zu können. Im Pausenplanbeispiel werden vom Pausenplanersteller bisher nur wenige einfache, aber universelle Werkzeuge eingesetzt – Bleistift, Lineal, Radiergummi. Bei der Übertragung in einen fachlichen Entwurf müssen wir die »Funktionalität« dieser Werkzeuge für die anstehenden Aufgaben erkennen: Der Pausenplan muß aktualisiert werden; Lehrerlisten und Stundenpläne müssen abgeglichen werden. Viele

2


2.2


179

Dinge, die der Pausenplanersteller vorher umständlich auf Zetteln oder im Kopf »zusammenstellen« mußte, sollen durch Softwarewerkzeuge besser unterstützt werden. Ein Pausenplaner soll nicht nur wie ein Bleistift benutzt werden können, um Lehrernamen in entsprechende Pausenfelder einzutragen, sondern das Werkzeug soll sondieren, ob ein solcher Eintrag mit dem Stundenplan der Lehrer verträglich ist und dies geeignet anzeigen. Entwurfsmetapher Material

Unter einem Material verstehen wir einen Gegenstand, der in einer bestimmten Arbeitssituation zum Bestandteil des Arbeitsergebnisses wird. Dazu wird das Material von Werkzeugen oder, wie wir sehen werden, von einem Automaten bearbeitet. Auch ein Material hat eine fachliche Funktionalität und es muß für die Bearbeitung durch Werkzeuge geeignet sein. Im Rahmen einer Aufgabe werden wir oft verschiedene Materialien bearbeiten, um das gewünschte Ergebnis zu erzielen.

2


2.2


180

Material: Materialien sind Gegenstände, die im Rahmen einer Aufgabe Teil des Arbeitsergebnisses werden. Materialien werden durch Werkzeuge und Automaten bearbeitet und verkörpern fachliche Konzepte. Sie müssen für die Bearbeitung geeignet sein. Die Eigenschaften vorhandener Arbeitsgegenstände lassen sich oft sinnvoll auf Softwarematerialien übertragen.

Was Werkzeug und was Material ist, erkennen wir erst in einer Arbeitssituation; dort allerdings eindeutig. Es kann aber durchaus sein, daß ein Gegenstand in einer Situation als Werkzeug gebraucht wird (»wir schreiben mit dem Bleistift«) und in einer anderen zum Material wird (»wir spitzen den Bleistift an«). Die Übertragung von Arbeitsgegenständen aus dem Anwendungsbereich auf den Computer ist weniger problematisch als sich das bei Werkzeugen herausgestellt hat. Als erste Orientierung empfiehlt es sich immer, die bereits am Arbeitsplatz vorhandenen Materialien als potentielle Kandidaten für Software-Materialien zu betrachten.

2

Unterscheidung von Werkzeug und Material

Softwarematerialien


2.2


181

Für das Pausenplan-Beispiel bieten sich einige Materialien auf den ersten Blick an – der Pausenplan selbst und die Listen oder Karteikarten mit den Angaben zu den Lehrern, ihrer Verfügbarkeit und Zuständigkeit sowie die Stundenpläne. Bei der Betrachtung dieser konventionellen Materialien ist wichtig, daß wir den spezifischen Umgang mit ihnen erkennen und uns nicht mit »generischen Operationen« wie »anlegen«, »ändern«, »löschen« zufrieden geben. So werden Freistunden verschoben, Pausen neu zugeordnet und die Stundenzahl eines Lehrers reduziert. Entwurfsmetapher Arbeitsumgebung

Betrachten wir das Leitbild vom Arbeitsplatz für Expertentätigkeit, dann wird klar, daß zu den wesentlichen Entwurfsmetaphern auch der Arbeitsplatz und seine Umgebung zählt. Denn wir müssen ja den Ort der Arbeit vergegenständlichen. Die Arbeitsumgebung ist der Ort, an dem Werkzeuge, Materialien und andere Gegenstände der täglichen Arbeit ihren Platz haben. Dabei unterscheiden wir den unmittelbaren Arbeitsplatz, an dem die Arbeit selbst stattfindet, und die Arbeitsumgebung, die auch noch die Orte mit einschließt, die um den Arbeitsplatz herum zugänglich und »in Reichweite« sind. Es ist für uns selbstverständlich, daß wir uns unse-

2

Arbeitsumgebung


2.2


182

ren Arbeitsplatz entsprechend unserer Aufgaben, Ordnungsprinzipien und Gewohnheiten einrichten. Wenn wir arbeiten, dann legen wir uns die Gegenstände zurecht, die wir benötigen, um das aktuell angestrebte Arbeitsergebnis herzustellen. Andere Dinge, die wir im seltenen Fall oder wenn Probleme auftreten benötigen, sind in der Arbeitsumgebung zumindest in Reichweite, oder wir wissen, wo sie zu finden sind. Da wir zunächst von der Unterstützung eines einzelnen Arbeitsplatzes ausgehen, an der also nur eine Person arbeitet, gebrauchen wir vielfach die Begriffe Arbeitsumgebung und Arbeitsplatz synonym. Erst mit der Unterstützung von kooperativer Arbeit werden wir den Unterschied zwischen Umgebung und Arbeitsplatz deutlicher herausarbeiten (s. Kapitel 4.1).

2


2.2


183

Arbeitsumgebung: Die Arbeitsumgebung ist der Ort, wo Werkzeuge, Materialien und andere Gegenstände, die bei der Erledigung von Aufgaben griffbereit sein müssen, fachlich motiviert angeordnet sind. Dabei findet die eigentliche Arbeit am Arbeitsplatz statt, während zur Umgebung noch die Orte gehören, die unmittelbar zugänglich sind. Der (individuelle) Arbeitsplatz ist gegen den Zugriff von außen geschützt. Wenn nur die Arbeit eines einzelnen Benutzers unterstützt werden soll, fallen Arbeitsplatz und -umgebung meist zusammen.

Mit der Metapher der Arbeitsumgebung kommt der Raumbegriff in unseren Ansatz. Dieses Verständnis von Umgebung als Ort, den wir uns für unsere Arbeit eingerichtet haben, paßt gut in den Rahmen unseres Leitbilds. Die Umgebung stellt eine wichtige konzeptionelle und räumliche Begrenzung dar. Zunächst können wir unseren individuellen Arbeitsplatz als unsere private Arbeitssphäre betrachten. Dort können wir mit mehreren Werkzeugen an Materialien arbeiten. In der Umgebung des Arbeitsplatzes haben wir weitere Werkzeuge und die nicht unmittelbar benötigten Materialien für die Bearbeitung bereitgelegt.

2

Raumbegriff


2.2


184

Es ist nicht leicht vorstellbar, mit Werkzeugen, die sich auf verschiedenen Arbeitsplätzen befinden, gleichzeitig an einem Material zu arbeiten. Ebenso wenig ist einsichtig, daß ein und dasselbe Material gleichzeitig in zwei Umgebungen sein soll. Hier deutet sich an, daß wir für kooperative Arbeitsprozesse den Umgebungsbegriff in einem größeren Zusammenhang stellen müssen. Dann macht es Sinn, den individuellen Arbeitsplatz von gemeinschaftlich genutzten Räumen zu unterscheiden. Trotzdem wollen wir die Einheit von Ort und Zeit wahren. Im Pausenplanbeispiel werden wir die Arbeitsumgebung als einen elektronischen Schreibtisch vergegenständlichen. Da im wesentlichen Büroarbeit geleistet werden muß, entspricht ein Schreibtisch am ehesten seiner Alltagserfahrung. Auf dem elektronischen Schreibtisch stellen wir die Werkzeuge und Materialien bereit, die bei der Arbeit an Pausenplänen sinnvoll und notwendig sind. Der Pausenplanersteller kann diese Gegenstände nach seinen Vorstellungen auf dem Schreibtisch anordnen und zurechtlegen. Entwurfsmetapher Automat

Nicht alles, was in einer Arbeitsumgebung bei der Erledigung von Aufgaben nützlich ist, läßt sich in die Kategorien Werkzeug und Material

2


2.2


einteilen. Ob im Büro oder in einer Werkstatt, überall finden wir Maschinen, die uns lästige Routinetätigkeiten abnehmen. Diese Maschinen nennen wir in unserer Alltagssprache auch Automaten. So sprechen wir von einem Getränkeautomat oder bezeichnen die heute verwendeten Waschmaschinen als »Vollautomaten«. Im Kontext von Büroarbeit finden wir Kopier- oder Frankierautomaten. Kennzeichnend für Automaten ist, daß sie ihre Aufgaben auf der Basis von wenigen Einstellmöglichkeiten auch über längere Zeiträume ohne äußere Eingriffe erledigen. Sie funktionieren sozusagen »auf Knopfdruck«. Das paßt aber nur dann bruchlos in unsere Arbeitswelt, wenn diese Automaten eine Routinetätigkeit oder einen festgelegten Prozeß mit genau bekanntem Ergebnis ausführen. So einfach Automaten im Standardfall verwendet werden können, so schwierig wird es, sie im Störungsfall wieder in Gang zu setzen. Dazu müssen sie meist durch Fachleute geöffnet und eingestellt werden. Diese Entwurfsmetapher des Automaten fügt sich ebenfalls gut in unser Leitbild vom Arbeitsplatz für eigenverantwortliche Tätigkeit ein, da er die Routinen übernimmt, die ihm vom Anwender zugewiesen werden. Damit überträgt der Anwender explizit die lästigen Abläufe oder Arbeitsprozesse auf einen Automaten, mit denen er sich in der jeweiligen Situation nicht selbst beschäftigen will. Damit geht die Kontrolle für den Einsatz des Automaten vom Anwender aus.

2

185

Kennzeichen von Automaten

Kleine Automaten


2.2


186

Automaten, die so funktionieren, nennen wir auch »kleine Automaten«. Sie unterscheiden sich damit von »großen Automaten«, die in Fabriken und Steuerungsanlagen »den Takt angeben.« Automaten arbeiten wie Werkzeuge auf Materialien und sie haben ebenso eine fachliche Funktionalität. Allerdings werden sie nicht im eigentlichen Sinne von Benutzern gehandhabt, sondern gestartet und, wenn nötig, kontrolliert. Sie laufen »unauffällig im Hintergrund«. Dies legt eine softwaretechnische Modellierung als weitgehend eigenständige Prozesse nahe.

2


2.2


187

Automat: Automaten sind im Rahmen einer zur erledigenden Aufgabe ein Arbeitsmittel, um Material zu bearbeiten. Sie erledigen lästige Routinetätigkeiten als eine definierte Folge von Arbeitsschritten mit festem Ergebnis ohne weitere äußere Eingriffe. Automaten laufen unauffällig im Hintergrund, wenn sie einmal vom Benutzer oder von der Arbeitsumgebung gestartet sind. Sie können auf ihren Zustand überprüft und im vorgegebenen Rahmen eingestellt werden.

Ein Automat ist im Pausenplanbeispiel nicht auf den ersten Blick erkennbar. Allerdings werden die verschiedenen Statistiken und Kennzahlen über das Pausendeputat immer nach dem gleichen Verfahren in Relation zu dem Anstellungsverhältnis und den abgeleisteten Pausenaufsichten erstellt. Diese Aufgabe könnte ein Automat »im Hintergrund« bei jeder Änderung eines entsprechenden Material erledigen.

2


2.2


188

Entwurfsmetapher Behälter

Bei der Entwicklung des Werkzeug & Material-Ansatzes haben wir Behälter zunächst als Materialien wie alle anderen betrachtet. Sie enthielten andere Materialen und wurden auch von Werkzeugen bearbeitet. Deutlich war nur, daß sie in vielen Anwendungskontexten eine große Rolle spielen (etwa als Ordner oder Mappen) und daß sie in der Objektorientierung explizit für Sammlungen von Materialien modelliert werden müssen. Mit der Zeit wurde ihre besondere Stellung deutlich. Zunächst fassen sie verschiedene Materialien zu einem fachlichen Ganzen zusammen, z.B. in einer Kredit- oder Kundenakte. Diese Funktion, etwas zusammenzufassen, zeigt sich oft am Inhaltsverzeichnis, das ein solcher Behälter hat. Hier wird nämlich angezeigt, welche Dokumente oder Schriftstücke sich derzeit im Behälter befinden und welche nicht. Viele fachliche Behälter helfen auf diese Weise, die Konsistenz des Materials zu wahren: Der Sachbearbeiter erkennt, welche Unterlagen noch beigebracht werden müssen oder ob eine Unterlage temporär herausgenommen worden ist.

2

Inhaltsverzeichnis


2.2


189

Behälter: Ein (fachlicher) Behälter kann Materialien aufnehmen, verwalten, ordnen und herausgeben. Dazu führt der Behälter oft Verzeichnisse. In einem Behälter können viele gleichartige oder ein definierter Satz von unterschiedlichen Gegenständen verwahrt werden. Behälter vergegenständlichen oft Prozesse als sogenannte Vorgänge (z.B. Kreditakte) und dienen der Kooperation und Koordination.

Damit verbunden ist die Funktion fachlicher Behälter, eine oder mehrere Ordnungen zu repräsentieren. Die Register von Ordnern und Mappen zeigen dies. Über die reine Anordnung der enthaltenen Materialien z.B. nach Alphabet oder Datum, können fachliche Behälter auch verschiedene Arbeitszustände darstellen. So ist es üblich, Anträge und Formulare, die in Arbeit sind, in eigenen Mappen aufzubewahren. Bekannt sind auch die Pultmappen, in denen Dokumente »auf Termin« gelegt werden. In Archiven hingegen werden abgeschlossene Vorgänge aufbewahrt, weil sie später als Hintergrundinformation dienen oder weil dies aus juristischen Gründen sein muß. Das Beispiel der Kreditakte verdeutlicht einen weiteren wichtigen Aspekt. Fachliche Behälter vergegenständlichen oft einen anwen-

2

Ordnungen eines Behälters

Behälter und Vorgänge


2.2


190

dungsfachlichen Vorgang – hier die Vergabe und Abwicklung eines Kredits. Sie machen damit einen Prozeß verständlich und nachvollziehbar. Wie wichtig fachliche Behälter für den WAM-Ansatz sind, wird deutlich, wenn wir uns vor Augen führen, daß Vorgänge in konventionellen Ansätzen nicht vergegenständlicht werden. Dort werden sie als Prozesse im Sinne eines Programmablaufs (als Anwendung von Funktionen auf Daten) modelliert. Auf die Rolle von Behältern bei der Kooperation und Koordination werden wir in Kapitel 4.1 näher eingehen. Behälter sind ohne Zweifel eine konzeptionelle und sprachliche Bereicherung unseres Repertoires an Entwurfsmetaphern. Fachliche Behälter für das Pausenplanbeispiel sind recht offensichtlich. Das Lehrkörper stellt die konzeptionelle Einheit aller beschäftigten Lehrer dar. Entsprechend werden wir die verschiedenen Lehrer für die Pausenaufsicht auch als eine solche fachliche Sammlung modellieren. Wir benötigen zudem einen Behälter, um aktuelle und alte Pausenpläne aufzubewahren.

2


2.2


191

2.2.4 Rollenverteilung Wir betrachten in diesem Abschnitt die Rollenverteilung, die zu dem von uns vorgeschlagenen Leitbild paßt. Der Arbeitsplatz ist für qualifizierte menschliche Tätigkeiten gedacht. Er ist ausgestattet mit einer für die zu erledigenden Aufgaben sinnvollen Anordnung von Werkzeugen, Materialien und Automaten. Damit sind einige Rollen vorgegeben. Da ist zunächst der Benutzer, der die Anwendungssoftware am Arbeitsplatz einsetzt. Dann der Entwickler, der die Anwendungssoftware konstruiert. Dazu kommen aber noch die anderen, am Arbeitsprozeß Beteiligten. Rolle Benutzer

Im vorgestellten Leitbild sind die Benutzer die kompetenten Akteure. Diesen Expertenstatus haben sie gegenüber den Entwicklern unabhängig vom Grad ihrer formalen fachlichen Qualifikation. Wir gehen davon aus, daß sie wissen, wie »das Geschäft läuft«. Sollte diese Voraussetzung nicht zutreffen, dann stimmt unser Leitbild nicht. Man kann sich dann natürlich fragen, ob eine Situation, in der die Mitarbeiter nicht wissen, was sie fachlich an Aufgaben wie zu erledigen haben, überhaupt ein primärer Fall für Softwareentwicklung ist. Oftmals

2


2.2


müssen in diesem Fall ein Reorganisationsprozeß oder andere betriebswirtschaftliche Maßnahmen der eigentlichen Softwareentwicklung zumindest logisch vorangehen. Wir gehen also von Fachleuten in ihrem Arbeitsgebiet aus, die mit der Handhabung selbst komplizierter Werkzeuge und Automaten vertraut sind und die passenden Materialien situationsgerecht wählen. Sie wissen, in welchen Behältern sich welche Dinge befinden und wozu diese gut sind. Diesen Umgang mit Werkzeugen und anderen Gegenständen haben Benutzer erlernt; dies gilt für die »normalen« Gegenstände ebenso wie für Softwarewerkzeuge und -materialien. Daraus folgt, daß die Arbeitsmittel und -gegenstände nicht für »naive« Benutzer entwickelt worden sind, d.h. es besteht kein Anspruch, daß jeder ohne Vorkenntnisse und Übung sich einfach ein Werkzeug greifen und mit der Arbeit beginnen kann. Damit die Softwarewerkzeuge wie andere Werkzeuge je nach Situation benutzt und wieder zur Seite gelegt werden können, dürfen sie keine kompletten Arbeitssequenzen oder -abläufe implementieren. Jede mögliche Aktion mit einem Softwarewerkzeug muß vom Benutzer als »atomar« empfunden werden.

2

192

Benutzer als Fachleute


2.2


193

Benutzer von Softwarewerkzeugen: Benutzer sind Fachleute in ihrem Arbeitsgebiet. Der Umgang mit neuen Softwarewerkzeugen und -materialien ist für Benutzer zunächst ungewohnt. Er erfordert Übung und Wissen. Da die hier betrachteten Aufgaben situationsabhängig und eigenverantwortlich erledigt werden müssen, dürfen die dabei verwendeten Softwarewerkzeuge keine durchgängigen Arbeitsabläufe implementieren. Je nach Ausbildungsumfang der Benutzer und Häufigkeit des Einsatzes können Werkzeuge unterschiedlich komplex in Funktionalität und Handhabung gestaltet sein.

Da die Benutzer der Werkzeuge und Materialien die eigentlichen Fachleute sind, müssen sich die Gegenstände am Arbeitsplatz auch immer wieder neu im Einsatz bewähren. Denn die Verwendbarkeit in der Arbeit und die gute Handhabbarkeit sind die entscheidenden Merkmale von Gebrauchsqualität, die sich nicht formal oder abstrakt überprüfen lassen. Gebrauchsqualität steht im engen Zusammenhang mit dem Umfang der Ausbildung und der Häufigkeit des Einsatzes. Wird ein Arbeitsgegenstand oder -mittel jeden Tag eingesetzt oder hat der Benutzer eine umfangreiche Schulung erhalten, dann sind andere

2

Gebrauchsqualität


2.2


Merkmale wichtig, als bei einem Werkzeug, das nur einmal im Quartal eingesetzt wird und das daher weitgehend »selbsterklärend« sein muß. Schließlich ist für unseren Ansatz wichtig, daß die Benutzer als Experten ihre Fachsprache beherrschen. Die Begriffe dieser Fachsprache sind die Basis für unseren objektorientierten Entwurf. Dadurch spielen die Benutzer nicht nur beim Einsatz eines Anwendungssystems die entscheidende Rolle. Ihre Integration in den Entwicklungsprozeß ist gleichfalls unverzichtbar, da letztlich nur die »gelebte« Fachsprache und das tatsächliche Verständnis der Konzepte die Grundlage eines anwendungsorientierten Entwicklungsprozesses sein sollten.

194

Fachsprache

Rolle Entwickler

Damit wären wir bei der Rolle der Entwickler. Sie sind im Sinne von [Brooks 96] vorrangig die Werkzeugmacher und Lieferanten von Materialien. Deshalb müssen sie einerseits viel von der Werkzeugkonstruktion und der »Materialherstellung« verstehen, aber sie müssen auch genau darauf achten, was der Bedarf im Anwendungsbereich ist. Obwohl sie nicht die fachliche Qualifikation ihrer »Kunden« erreichen werden, müssen sie doch sehr viel fachlichen Sachverstand besitzen. Wir haben bei der Betrachtung der Benutzerrolle auf die Bedeu-

2


2.2


tung der Fachsprache hingewiesen. Um im Bild zu bleiben, heißt dies, daß die Entwickler diese Fachsprache als eine Fremdsprache lernen müssen, da sie sonst keine Chance haben, die damit verbundenen Begriffe zu modellieren. Gewisse arbeitsteilige Spezialisierungen deuten sich ebenfalls an: Einige Entwickler werden mehr von der Werkzeugkonstruktion verstehen, andere kennen sich besser mit den Materialien und Behältern aus. Schließlich werden sich einige auf die Bereitstellung und Einrichtung von Arbeitsumgebungen beschränken. Doch bei aller Spezialisierung wird keine Entwicklergruppe ohne grundlegende Anwendungskenntnisse auskommen können; und für alle gilt, daß der Kunde König ist, also letztlich darüber entscheidet, welche Gegenstände sich für die tägliche Arbeit eignen und welche nicht.

195

Arbeitsteilung

Andere Rollen

Unser Leitbild ist plastisch genug, um auch die weiteren Rollen für die beteiligten Gruppen zu bestimmen: Organisatoren legen fest, welche Art von Arbeitsplätzen in einer Organisation mit welchen Werkzeugen und Materialien ausgestattet werden sollen. Planer wollen Angaben über die an den einzelnen Arbeitsplätzen erstellten Arbeitsergebnisse haben, d.h., sie greifen mit speziellen Werkzeugen auf Materialien zu.

2

Organisatoren, Planer, Produktentwickler


2.2


196

Auf der Entwicklerseite wird es vielleicht eine Gruppe geben, die sich um die Erarbeitung einer »Produktlinie« kümmert oder die den Anwendern bei der Einführung von neuen Werkzeugen am Arbeitsplatz hilft. Betrachten wir die bisher aufgezeigten Merkmale des vorgestellten Leitbilds, dann wird deutlich, daß wir uns konzeptionell sehr stark an alltäglicher Arbeit orientieren. Im Rahmen der bestehenden Arbeitskontexte sollen neue oder ergänzende Werkzeuge und Materialien integriert werden. Auch wenn dadurch völlig neue Arbeitsplätze entstehen, so sollen sie im Arbeitszusammenhang kein Fremdkörper sein. Durch die unterstützende Sichtweise verliert der Einsatz von Computern, sprich von Anwendungssoftware, seine Sonderstellung. Die Fachleute eines Anwendungsbereichs müssen sich nicht mehr auf das neue und fremde »Computersystem« einstellen und ihre Arbeit darauf abstimmen. Vielmehr müssen die Entwickler dafür sorgen, daß die fachlichen Anforderungen möglichst bruchlos in verständliche und verwendbare Gegenstände zur Unterstützung der betrieblichen Aufgaben umgesetzt werden.

2


2.2


197

2.2.5 Weitere WAM-Leitbilder Wir haben darauf hingewiesen, daß der Werkzeug & Material-Ansatz ursprünglich für Einzelarbeitsplätze in der Softwareentwicklung und im Finanz- und Dienstleistungsbereich ausgearbeitet worden ist. Dazu kamen mit der Zeit Anwendungen im eher technischen Bereich, z.B. Laborsysteme, und stark kooperativ angelegte Arbeitssituationen, wie die medizinische Versorgung und Pflege im Krankenhaus. Dies brachte uns dazu, das Leitbild vom Arbeitsplatz für eigenverantwortliche Expertentätigkeit zu überdenken. Wir wollten nicht ein universelles Leitbild vorgeben und dann auf alle Anwendungsbereiche übertragen, sondern, im Sinne unserer Idee der Anwendungsorientierung, aus der jeweiligen Situation heraus festlegen, welches Leitbild diesem Anwendungsbereich dienlich ist. In Kapitel 4.1 gehen wir auf die Erweiterungen ein, die wir besonders bei den Entwurfsmetaphern machen mußten, um Kooperation und Koordination zu unterstützen. In Kapitel 4.3 stellen wir erste Erfahrungen bei der Konstruktion von Automaten für technische Systeme vor. Hier wollen wir diese Erfahrungen so auswerten, daß die Veränderungen im Leitbild und die Konsequenzen für die Entwurfsmetaphern zumindest skizziert werden.

2


2.2


198

Leitbild Funktionsarbeitsplatz für eigenverantwortliche Expertentätigkeit

Aus dem Kontext Krankenhaus oder Medizinallabor kommt das Leitbild Funktionsarbeitsplatz für eigenverantwortliche Expertentätigkeit. Beispiele wären ein Röntgenanalysearbeitsplatz für einen Röntgenarzt oder ein Laborarbeitsplatz für eine aufwendige halbautomatische Blutbildanalyse durch eine ausgebildete Laborantin (s. Abbildung 2-17). Wir sehen rasch, daß hier ein anderes Leitbild gewählt werden muß. Bestehen bleibt das Grundkonzept des elektronischen Arbeitsplatzes. Auch die Eigenverantwortlichkeit des Benutzers wird dadurch nicht in Frage gestellt. Differenziert werden muß aber hinsichtlich der Vielfalt der Aufgaben und dem Umfang ihrer Unterstützung, der Anforderungen an die Flexibilität und der Kenntnisse über Software und Computer. In [Frei et al. 96] sind in ähnlicher Weise grundsätzliche Wahlmöglichkeiten bei der Gestaltung von Technologie genannt:

Leitbild

Kriterien der Technologiegestaltung

❑ Grad der Verkopplung von Mensch und Maschine, d.h. in

unserem Kontext der Umfang in dem die Aufgaben von der Anwendungssoftware unterstützt oder automatisiert werden.

2


2.2


199

❑ Produktdistanz meint in unserem Zusammenhang das Ausmaß

in dem eine Dienstleistung oder ein Produkt vom Anwender eigenverantwortlich realisiert werden kann. ❑ Prozeßverkettung bedeutet, inwieweit die einzelnen Arbeits-

schritte durch die Software vorgegeben und in einen Gesamtvorgang (im Sinne von Workflow) eingebunden sind. Der bisher betrachtete Arbeitsplatztyp, z.B. ein Beraterarbeitsplatz, zeichnet sich durch mittlere Verkopplung, geringe Produktdistanz und minimale Prozeßverkettung aus. Anders bei Funktionsarbeitsplätzen: Ein Funktionsarbeitsplatz ist auf die Erledigung einer vorgegebenen Aufgabe zugeschnitten. Diese Aufgabe muß teils mit hoher Geschwindigkeit und einer entsprechend hohen Zahl an Wiederholungen durchgeführt werden. Die eigentlichen Arbeitsmittel (Röntgengerät, Blutbildanalysator) und Arbeitsgegenstände (Patient, Blutprobe) stehen oft gar nicht unmittelbar im Computer zur Verfügung. Die Anwendungssoftware ist hier noch viel deutlicher Mittel zum Zweck. Weder der Röntgenarzt noch die Laborantin wollen sich mit Details der Anwendungssoftware befassen. Das wesentliche ist, daß sie sich auf ihre eigentliche Arbeit, nämlich die Analyse von Röntgenbildern oder von Blutproben, konzentrieren können und daß die Erstellung des Befunds oder die

2

Arbeitsmittel


2.2


Dokumentation der Analyseergebnisse mit minimalem Aufwand von der Hand gehen. Daraus ergeben sich wesentliche Verschiebungen gegenüber dem Arbeitsplatz für eigenverantwortliche Expertentätigkeit (s. Kapitel 2.2.3). Zunächst läßt sich die Vielfalt der Werkzeuge und Materialien auf die viel besser bekannte Arbeitssituation mit ihrer festgelegten Aufgabe zuschneiden. Die Werkzeuge haben den Charakter von Spezialwerkzeugen. Dazu kommt ein Steuerungsautomat, der für alle Standardsituationen ohne Aufwand Werkzeuge und Materialien miteinander verbindet und für die Bearbeitung bereithält. Im Sonderfall kann dieser Steuerungsautomat vom Benutzer ausgeschaltet werden – dann kann der Benutzer »im Handbetrieb« arbeiten. Verallgemeinern wir dies im Sinne der oben vorgestellten Einteilung stellen wir fest: Für die jeweils relevante Aufgabe haben wir eine hohe Verkopplung von Mensch und Maschine; die Produktdistanz soll nach wie vor gering sein; die Prozeßverkettung erhöht sich.

2

200 Spezialwerkzeuge und Steuerungsautomat

Einordnung in die Kriterien der Technologiegestaltung


2.2

Funktions- Benutzer arbeitsplatz


unterstützte Aufgabe

Entwurfsmetaphern

Abb. 2-17 Beispiele zum Leitbild

Röntgenanalysearbeitsplatz

Röntgenfacharzt, der Schreiben vieler eigenverantwortlich schematischer täglich die Aufgabe Befunde erledigt

Material (z.B. Röntgenaufnahme, Patientenakte, Befund) Spezialwerkzeug (z.B. Röntgenbildanalysator) Steuerungsautomat, der Patientenakte, Werkzeuge und Textbausteine verknüpft

Laborarbeitsplatz

ausgebildete Laborantin, die eigenverantwortlich täglich die Aufgabe erledigt

Materialien (z.B. Blutprobe, Analysewerte, Analyseergebnis) Spezialwerkzeug (z.B. grafischer Meßwertebrowser) Steuerungsautomat zur Ansteuerung des Analysegeräts, Auswahl und Steuerung der Blutproben, Erstellung des Analyseergebnisses

Dokumentation der Analyseergebnisse von speziellen Blutbildanalysen

2

201 Funktionsarbeitsplatz


2.2


202

Leitbild Gruppenarbeitsplatz für eigenverantwortliche, kooperative Aufgabenerledigung

Im Krankenhaus haben wir ein weiteres Leitbild entwickelt, den Gruppenarbeitsplatz für eigenverantwortliche, kooperative Aufgabenerledigung. Als Beispiel kann das Stationszimmer einer Abteilung (s. Abbildung 2-18) oder das Gruppenzimmer einer Intensivstation gelten. Hier kommen viele komplexe Faktoren zusammen, die die Analyse und den Systementwurf in diesem Bereich erschweren. Gruppenarbeitsplatz

Benutzer

unterstützte Aufgaben

Entwurfsmetaphern

Stationszimmer

Krankenschwester, Pfleger, Arzt

Behandlung des Patienten, Koordination der Gruppenarbeit, Dokumentation u. Abrechnung der Behandlung

Materialien (z.B. Patientenakte) Kooperationswerkzeuge (z.B. Bettenplaner) Signale (z.B. neue Medikamentenverordnung) Impulse (z.B. Bestätigung für Röntgentermin) Gruppenraum (z.B. Stationszimmer mit allgemeinen und inividuellen Ablagen)

Zunächst ist offenkundig, daß an einem Ort im häufigen Wechsel mehrere Personen mit unterschiedlicher Qualifikation arbeiten (z.B.

2

Abb. 2-18 Beispiel für Gruppenarbeitsplatz

Arbeitsteilung


2.2


Krankenschwestern, Pfleger, Ärzte). Die Arbeit selbst ist hochgradig arbeitsteilig (z.B. Behandlung eines Patienten). Die einzelnen Arbeitshandlungen sind meist recht kurz und kommen wiederholt vor (z.B. Verbandswechsel). Die Koordination bei der Arbeit findet durch direkten Informationsaustausch (z.B. bei der Visite), oft über gemeinsam genutzte Gegenstände (z.B. Patientenakte) statt (s. Kapitel 4.1.4 ). Es zeigt sich also, daß die verschiedenen Formen der Arbeitsteilung und ihre Unterstützung für die Ausgestaltung eines Gruppenarbeitsplatzes von großer Bedeutung sind. Dies schlägt sich sowohl in der Gestaltung der einzelnen Materialien als auch der Werkzeuge nieder. So muß am Material nicht nur die fachliche Substanz (etwa die Anordnung von Medikamenten auf einem Krankenblatt) modelliert werden, sondern auch die koordinierende Funktion des Materials im Kooperationsprozeß (z.B. das Signal durch einen Reiter, daß sich eine Anordnung verändert hat). Werkzeuge müssen Impulse oder Signale für den Gruppenarbeitsplatz und die einzelnen Personen erzeugen, die die Aufmerksamkeit und den geregelten Arbeitsablauf gewährleisten. Schließlich muß der Gruppenarbeitsplatz allen Gruppenmitgliedern leicht zugänglich sein (z.B. muß jedes Gruppenmitglied sofort eine kritische Veränderung am Patientenzustand erkennen können), jedoch ihre jeweilige Qualifikation und

2

203

Kooperation und Koordination

Die Gegenstände


2.2


Kompetenz berücksichtigen (nur ein Arzt darf z.B. eine bestimmte Behandlung anordnen). In dem allgemeinen Schema für die Gestaltung von Technologie können wir diesen Arbeitsplatztyp so einordnen: Der Grad der Verkopplung von Mensch und Maschine ist nicht sehr hoch; die Produktdistanz soll sehr gering sein; die Prozeßverkettung schwankt je nach Aufgabe von sehr niedrig bis zu einem mittleren Wert.

204 Einordnung in die Kriterien der Technologiegestaltung

Leitbild Selbstbedienungsautomat

Ein ganz anderes Leitbild verkörpert der Selbstbedienungsautomat, den wir beispielsweise als Kundenselbstbedienungsautomat (s. Abbildung 2-19) oder Homebanking-Anwendung im Bankenbereich finden. Ein Selbstbedienungsterminal ist zunächst kein Arbeitsplatz, da er nur gelegentlich im Rahmen einer Dienstleistung von einem Kunden in Anspruch genommen wird. Er macht für diesen Kunden genau die Dienstleistungen verfügbar, die von der Organsation dafür zugeschnitten worden sind (z.B. Aus- und Einzahlung plus Geldüberweisungen).

2


2.2

Selbstbedienungsautomat

Benutzer

Kundenselbst- Bankkunde, der bedienungsohne bankfachliche automat Detailkenntnisse BankdienstHome Banking leistungen in Anwendung Anspruch nimmt


unterstützte Aufgaben

Entwurfsmetaphern

Zahlungsverkehr, eingeschränktes Angebot an Finanzdienstleistungen

Materialien (z.B. Konto, Überweisung) Dienstleistungen als Beratungsprozesse (z.B. Kreditvergabe) Informationsmaterial (z.B. über Kleinkredite) Hilfewerkzeug (z.B. über Bedienung des Terminals) Steuerungsautomat (z.B. zur Verknüpfung von Materialien, Dienstleistungen, Informationsmaterialien)

205 Abb. 2-19 Beispiel für einen Selbstbedienungs-

Der Benutzer ist zwar verantwortlich für das, was er vom Dienstleistungsanbieter will, aber er ist auch immer in der Rolle des Kunden, der ohne vertiefte anwendungsfachliche Kenntnisse die Dienstleistungsangebote auf einfache und schnelle Weise in Anspruch nehmen will. Des weiteren können wir nicht davon ausgehen, daß der Kunde über detaillierte Kenntnisse im Umgang mit dieser Art von Anwendungssoftware verfügt. Daher hat der Dienstleistungsanbieter eine

2

automaten

Der Benutzer


2.2


gewisse Sorgfalts- und Informationspflicht, die sich in einer passenden Benutzerführung und in einer ausreichenden Information niederschlagen muß. Anders als beim Beraterarbeitsplatz in der Bank werden die einzelnen Materialien nicht im freien Zugriff zur Verfügung gestellt. Sie werden jeweils den Services zugeordnet, so daß z.B. zunächst »Kontoführung« gewählt werden muß, ehe ein Konto verfügbar ist. Nur so läßt sich umgehen, daß der Kunde wissen muß, welche Materialien bei der Inanspruchnahme einer Dienstleistung vorhanden sein müssen. Diese Dienstleistungen werden vergegenständlicht, um sie anschaulich handhaben zu können. Dazu dient ein entsprechender Steuerungsautomat, der dem Kunden soviel Handlungsfreiheit wie möglich bietet. Damit der Kunde so individuell wie möglich mit dem Selbstbedienungsautomaten arbeiten kann, muß der Automat umfangreiche Informations- und Hilfemöglichkeiten bereitstellen, die nicht nur die anwendungsfachliche Seite, sondern auch das Anwendungssystem selbst beschreiben. Die Gestaltungsspielräume für diesen Arbeitsplatztyp sehen so aus: Der Grad der Verkopplung zwischen Mensch und Maschine ist für die entsprechenden Aufgaben sehr hoch, da je nach Umstand keine andere Möglichkeit besteht, die Aufgaben ohne Computerunterstützung zu erledigen. Die Produktdistanz bleibt sehr gering, da der Kunde

2

206

Benutzerführung

Einordnung in die Kriterien der Technologiegestaltung


2.3

Muster und Rahmenwerke

207

ein gutes Verständnis von den Produkten und Dienstleistungen haben soll, die ihm angeboten werden. Die Prozeßverkettung ist dagegen sehr hoch, da Standardabläufe weitgehend vorgegeben und nur in geringem Umfang modifizierbar sind.

2.3


Dieses Kapitel behandelt die Konzepte und Begriffe zu den Themen Entwurfsmuster und Rahmenwerke. Beide sind insofern eng miteinander verwandt, als sie aus der »2. Generation« der Objektorientierung nicht mehr wegzudenken sind. Wir betrachten die 1. Generation als die Periode, in der sich die »einfache« objektorientierte Programmierung zu einer umfassenden Vorgehensweise von der Analyse über den Entwurf bis zur Konstruktion ausweitete. Die 2. Generation ist gekennzeichnet durch den Übergang von reinen objektorientierten Programmen und einzelnen Klassenbibliotheken zu Rahmenwerken (Frameworks) und höheren Entwurfseinheiten. Zur Beschreibung dieser Rahmenwerke und höheren Entwurfseinheiten haben sich Entwurfsmuster (Design Patterns) durchgesetzt. Da wir im weiteren sowohl die für WAM relevanten Entwurfsmuster als auch ein Konzept

2

Federführung: Heinz Züllighoven Ko-Autoren: Dirk Bäumer, Dirk Riehle


2.3


208

für eine rahmenwerkbasierte WAM-Architektur vorstellen, bildet dieser Abschnitt dazu die Grundlage.

2.3.1 Entwurfsmuster Entwurfsmuster sind spätestens seit [Gamma et al. 96] ein aktuelles Diskussionsthema in der objektorientierten Softwareentwicklung. Wir haben die Diskussion von Anfang an aktiv mitverfolgt, weil wir hier einen Ansatz sehen, Erfahrungen und die Aufarbeitung dieser Erfahrungen im Bereich Softwarearchitekturen für die praktische Softwareentwicklung nutzbar zu machen. Aus diesem Grund wird der konstruktive Kern dieses Buches – die Beschreibung der wesentlichen Elemente einer WAM-Modellarchitektur –, in Musterform präsentiert. Wir wollen hier nicht auf die verschiedenen Richtungen und Diskussionen über Muster eingehen (vgl. [Riehle & Züllighoven 96]), sondern die Begriffe und Konzepte zusammenstellen, die zum Verständnis unseres Musterbegriffes und unserer Verwendung von Mustern notwendig sind.

2


2.3


209

Der allgemeine Musterbegriff Muster (allgemein): Ein Muster (Pattern) ist eine Abstraktion von einer konkreten Form, die wiederholt in bestimmten, nicht willkürlichen Kontexten auftritt.

Der allgemeine Musterbegriff, der unseren Überlegungen zugrunde liegt, ist weder auf Softwareentwicklung noch auf eine bestimmte Verwendung von Mustern zugeschnitten. Die bekannte Definition, nach der Muster Problemlösungen für bestimmte Situationen sind, [Gamma et al. 96], ist schon auf Entwurfssituationen ausgerichtet. Alexander, auf den sich viele Informatiker mittlerweile beziehen, 5 schreibt in [Alexander 79] : »Jedes Muster ist eine dreiteilige Regel, die einen Zusammenhang zwischen einem bestimmten Kontext, einem Problem und einer Lösung beschreibt«. Er führt weiter aus, daß ein Muster eine Relation ist zwischen unterschiedlichen Kräften, die in bestimmten Kontexten immer wieder vorkommen, und einer Konfiguration, die diese Kräfte bindet. Außerdem ist ein Muster bei ihm auch 5.

Übersetzung von uns.

2


2.3


210

eine Regel, die beschreibt, wie diese Konfiguration geschaffen werden kann, die die Kräfte bindet. Form und Inhalt eines Musters Form und Inhalt eines Musters: Die Form eines Musters besteht aus einer endlichen Anzahl von erkennbaren und unterscheidbaren Komponenten und deren Verbindungen. Der Zweck eines Musters besteht im Erzeugen, Identifizieren und Vergleichen von Exemplaren dieses Musters. Es liefert einen Begriff, um über eine Problemlösung zu reden. Ein Muster tritt nur in bestimmten Kontexten auf, die die Kräfte bestimmen, die das Muster erst in seiner spezifischen Form hervorbringen. Während die Form eines Musters endlich ist, muß dies nicht für die Anzahl der Exemplare gelten; auch der Kontext eines Musters ist potentiell unbegrenzt. Dies steht der vollständigen Formalisierung entgegen. Ein Muster kann nur auf dem Hintergrund von Erfahrung und Reflexion im Anwendungsbereich seines Kontextes verstanden werden. Ein Muster sollte in den Begriffen und Konzepten des Anwendungsbereichs präsentiert werden, für den es gedacht ist.

2


2.3


Im Kern definieren wir die Form eines Musters durch seine Repräsentation, d.h. durch die repräsentierenden Elemente, ihr Zusammenspiel und ihre weiteren Beziehungen untereinander. Damit hat ein Muster sowohl strukturelle als auch dynamische Eigenschaften. Die Elemente eines Musters sind nicht notwendigerweise Softwarekomponenten, sondern können auch andere technische und nicht-technische Gegenstände sein. Im weiteren werden wir erläutern, welche Art von Mustern aus welchen Elementen zusammengesetzt sind. Nehmen wir unser Pausenplanerbeispiel: Wenn wir den Anwendungsbereich analysieren, werden wir bewußt oder unbewußt die dort vorgefundenen Gegenstände wie Pausenplan, Kopierer, Stundenpläne in Werkzeuge und Materialien einteilen. Daß wir mit Werkzeugen auf geeigneten Materialien arbeiten, ist die relevante Beziehung zwischen den Elementen. In diesem Sinne können wir die WAM-Entwurfsmetaphern Werkzeug und Material auch als Elemente eines Muster verstehen. Den Übergang von Entwurfsmetaphern zu technischen Entwurfsmustern bilden dann die Konzeptionsmuster (s. S. 104 und Kapitel 3.1). Ein Muster ist, allgemein betrachtet, ein Konzept, das auf unserer Erfahrung beruht. Auf der Grundlage von Erfahrung und der Reflexion darüber können wir wiederkehrende Muster erkennen. Wenn

2

211 Form eines Musters

Zweck eines Musters


2.3


212

diese Muster einmal erkannt sind, wenn sie sozusagen ein eigenes Konzept bilden, dann leiten solche Muster unsere Wahrnehmung. Dann benutzen wir ein Muster, um seine Ausprägungen oder Exemplare zu erkennen. Genaugenommen existieren Muster konkret immer nur in Form ihrer Exemplare. Ein Muster kann aber auch konstruktiv zur Erzeugung seiner Exemplare eingesetzt werden. Da Muster unsere Wahrnehmung prägen, dienen sie uns zur Orientierung in unserer Umwelt. Wenn wir einem Muster einen Namen geben, dann führen wir einen Begriff ein, der sowohl das mit dem Muster verbundene Problem als auch seine Lösung kennzeichnet. Muster sind »sprachbildend«. Damit sind Muster sowohl in der Alltagswelt als auch in unseren »Softwarewelten« von Bedeutung. In unserem Pausenplanbeispiel hilft uns das Konzeptionsmuster Trennung von Werkzeug und Material, seine konkreten Ausprägungen zu erkennen. Deshalb betrachten wir einen Bleistift als Werkzeug, mit dem wir im Pausenplan, als dem passenden Material, Einträge ändern können. Wir können mit dem Pausenplanersteller über »Werkzeug und Material« als relevante Bestandteile seiner Arbeit und des zukünftigen Systems reden. Hier sehen wir, daß Muster sowohl in der Analyse zur Interpretation und zum Verständnis eines Anwendungsbereichs beitragen können.

2


2.3


Aber auch die konstruktive oder generative Funktion von Mustern kann an diesem Beispiel gezeigt werden: Das Konzeptionsmuster Trennung von Werkzeug und Material dient nicht nur zur Analyse, sondern soll ja gerade den Entwurf unterstützen. Wir werden also den Pausenplaner, d.h. einen spezialisierten Grafikeditor, als ein Werkzeug entwerfen, das dann auf einem elektronischen Pausenplan arbeitet. Ausgehend von diesem fachlich konzeptionellen Entwurf benötigen wir dann weitere Entwurfsmuster, die uns zu einer tragfähigen Softwarearchitektur führen, in der wiederum Werkzeuge und Materialien die entscheidenden Komponenten auf Objekt- und Klassenebene sind. Ein Muster ist eine Form in einem bestimmten Kontext. Wir können auch sagen, daß ein Muster immer vor einem Hintergrund erscheint. Diese Unterscheidung wird vielleicht klarer, wenn wir an die Zeichnungen von M. C. Escher denken oder an Vexierbilder, wie das Doppelbild von Gesicht und Vase, die in der Psychologie verwendet werden. Beiden ist gemeinsam, daß wir erst einmal erkennen müssen, was überhaupt der Hintergrund ist, ehe wir die Form im Vordergrund identifizieren können. Hintergrund oder Kontext und Muster bedingen sich also gegenseitig. Ein Kontext definiert das Muster; er bringt es hervor, während umgekehrt ein Muster nur in einen bestimmten Kon-

2

213

Kontext eines Musters


2.3


214

text paßt. Ändern wir den Kontext, dann verändert sich das Muster, während eine Veränderung des Musters den Kontext beeinflußt. Dabei dürfen wir nicht vergessen, daß die Form und der Kontext eines Musters Abstraktionen unserer Erfahrungen sind. Jede Anwendung eines Musters bringt dieses Muster aber wieder in einen neuen konkreten Zusammenhang. Dort werden neue Kräfte auftreten, die durch eine passende Musterform gebunden werden müssen. Wenn wir die jeweiligen Verwendungszusammenhänge nicht richtig in Rechnung stellen, wird es zu Brüchen und Anpassungsproblemen zwischen dem Muster und seinem Verwendungszusammenhang kommen. Verdeutlichen wir dies wieder an unserem Beispiel: Wenn wir den Pausenplan als Material identifizieren, das bisher noch manuell mit einem Bleistift als Werkzeug bearbeitet wird, dann verbinden wir damit auch eine bestimmte Form von Arbeitszusammenhang. Wir gehen davon aus, daß der Pausenplanersteller seine Aufgabe versteht; daß er eigenverantwortlich die Einteilung der Pausenaufsichten vornimmt; daß er in der Wahl seiner Arbeitsmittel ebenso frei ist wie in der Entscheidung, wann was für die Ausarbeitung eines neuen Pausenplans getan werden muß. So ist das Konzeptionsmuster Trennung von Werkzeug und Material vor dem Hintergrund eines bestimmten Typs menschlicher Arbeit erkennbar und verständlich.

2


2.3


Bei der Entwicklung eines Pausenplansystems zur Unterstützung der Aufgaben in diesem Arbeitszusammenhang müssen wir darauf achten, daß sich die neuentwickelten Softwarekomponenten auch in dieses Muster aus Werkzeug und Material einpassen. Anderfalls werden sich die Arbeitsmöglichkeiten vielleicht so verändern, daß eine eigenverantwortliche und zum großen Teil selbstbestimmte Pausenplanerstellung gar nicht mehr möglich ist. Die Form, die ein Muster beschreibt, besteht aus einer endlichen Anzahl von Elementen und Beziehungen. Die konkrete Ausprägung eines Musters kann allerdings beliebig viele Elemente haben, die rekursiv definiert sind und bei Bedarf erzeugt werden. Zudem ist der Kontext potentiell unendlich, was bedeutet, daß sich die Einflußfaktoren und Kräfte, die in einem Muster wirksam werden, nicht allgemein abschließend beschreiben lassen. Dies schränkt natürlich die Anwendung formaler Ansätze erheblich ein. Es ist kaum zu erwarten, daß ein Werkzeug oder eine formale Methode in der Lage ist, aufgrund einer Liste von Einflußgrößen und Kräften das »richtige« Muster zu ermitteln. In vielen Fällen können wir die relevanten Kräfte eines Musters aufgrund unserer Erfahrung beschreiben und die weniger relevanten unberücksichtigt lassen. Dies wird aber wohl kaum zu einem deterministischen Muster-Algorithmus führen.

2

215

Umfang eines Musters


2.3


In unserem Beispiel sind Pausenplaner und Pausenplan die beiden Elemente des Musters. Konkret kann es aber eine nicht festgelegte Anzahl von Pausenplänen geben. In [Gamma et al. 96] hat das Muster Zuständigkeitskette die Elemente Klient, Bearbeiter und Nachfolger. Dieses endliche Muster läßt sich zu einer beliebig langen rekursiven Kette von Bearbeiter – Nachfolger – Paaren »instanziieren«. In welchem Zusammenhang wir welches Muster wählen, hängt sehr von unserer Erfahrung ab. Sicherlich ließe sich die Erstellung eines Pausenplans aufgrund der Angaben über Ausschlußzeiten, Pausen, Pausenaufsichtsort etc. nach dem Röhren-und-Filter-Muster (Pipes and Filters; s. [Shaw & Garlan 96]) beschreiben, aber uns scheint hier Trennung von Werkzeug und Material eher angebracht. Muster erwachsen aus Erfahrung und können nur mit Erfahrung eingesetzt werden. Dies hängt mit der potentiellen Unendlichkeit des Kontextes zusammen. Denn der Autor einer Musterbeschreibung wird ja nur das an Merkmalen des Kontextes aufnehmen, was er als relevant und sinnvoll erachtet. Dies kann für einen Neuling in diesem Bereich bedeuten, daß er das Problem gar nicht versteht, für das ein Muster eine Lösung anbietet. Auch bei der Anwendung des Musters muß immer genügend Erfahrung vorhanden sein, um die richtige Ausprägung für den jeweiligen Kontext zu entwickeln. Doch unbestritten

2

216

Verständlichkeit von Mustern


2.3


sind die in einem Muster »kondensierten« Erfahrungen von großem Nutzen auch für Anfänger. Das Muster Trennung von Werkzeug und Material setzt voraus, daß sich der Anwender dieses Musters mit den Grundzügen der Entwicklung interaktiver Software für Arbeitsplatzsysteme vertraut gemacht hat. Denn sonst kann der Zusammenhang zwischen Werkzeug und Material mit interaktiver Software nicht hergestellt werden. Sind diese Voraussetzungen aber gegeben, hilft das Muster, die Elemente im Anwendungsbereich zu identifizieren und als potentielle Komponenten eines Softwareentwurfs zu übernehmen. Auch wenn wir die Anwendung von Mustern nicht auf die Softwareentwicklung einschränken, ist die Anwendungsorientierung von Bedeutung. Offensichtlich sollen Muster zunächst die Arbeit des Musterautors erleichtern. Aber sein wirkliches Potential zeigt ein Muster dann, wenn es von anderen akzeptiert und (wieder-) verwendet wird. Dann tritt es den Beweis an, eine abstrahierte Form für die Lösung eines wiederkehrenden Problems in einem bestimmten Kontext zu sein. Im Zusammenhang mit dem sprachbildenden Charakter von Mustern müssen wir Wert auf die Namensgebung legen. Die durch Muster neu eingeführten Begriffe sollten für alle Beteiligten verständlich sein.

2

217 Beispiel

Anwendungsorientierung von Mustern


2.3


Konzeptionsmuster wie Trennung von Werkzeug und Material sind nach Begriffen der Alltagssprache benannt. Damit stellen wir sicher, daß diese Muster in möglichst vielen Anwendungsbereichen verstanden werden. Generell läßt sich aus der Anwendungsorientierung des WAM-Ansatzes ableiten, daß zumindest alle Konzeptionsmuster mit Begriffen der jeweiligen Fachsprache benannt werden.

218 Beispiel

Einteilung von Mustern

In Kapitel 2.5 erläutern wir die verschiedenen Modelle, die für unseren Ansatz bei der Softwareentwicklung eine Rolle spielen. Dabei unterscheiden wir auf einer allgemeinen Ebene zwischen dem Modell des Anwendungsbereichs, dem Entwurfs- und dem Implementierungsmodell. Es hat sich als sinnvoll erwiesen, auch verschiedene Arten von Mustern zu unterscheiden, die sich in ihren jeweiligen Zwecken an diesen Modellen orientieren. Nachdem wir im letzten Abschnitt die allgemeinen Merkmale von Mustern beschrieben haben, differenzieren wir jetzt unterschiedliche Musterarten für den Kontext der Softwareentwicklung.

2


2.3


219

Einteilung von Mustern:

Konzeptionsmuster sind Muster, deren Form mit Begriffen und Konzepten eines Anwendungsbereichs beschrieben sind. Sie basieren auf den entsprechenden Entwurfsmetaphern und unterstützen die Analyse und fachliche Modellierung eines Anwendungsbereichs. Entwurfsmuster sind Muster, die die Elemente des technischen Entwurfs aus fachlicher und technischer Sicht beschreiben. Im Zusammenhang dieses Buches verwenden wir Entwurfsmuster auf unterschiedlichen Abstraktionsebenen: ❑ Allgemeine Entwurfsmuster, die die verfügbaren Elementen für den Softwareentwurf unabhängig von einer bestimmten Programmiersprache beschreiben. Sie verwenden dazu die allgemeinen objektorientierten Konzepte (Umgangsform, Rolle, Komponente, Generalisierung, Spezialisierung). ❑ Entwurfsmuster, die konstruktiv die Elemente des Softwareentwurfs technisch beschreiben. Die Form ist an den Konzepten der gewählten Programmiersprache ausgerichtet (z.B. Prozedur, Objekte, Klassen, Vererbung). Wir sprechen daher auch von Konstruktionsansätzen.

Programmiermuster sind Muster, deren Form durch (abstrakte oder konkrete) programmiersprachliche Konstrukte beschrieben sind, z.B.: for (i=0; i<max; i++) {...}

2


2.3


Die Bedeutung des Modells des Anwendungsbereichs heben wir in Kapitel 2.5.1 hervor. Hier ist wichtig, daß beim Modell des Anwendungsbereichs die Verständlichkeit für alle Beteiligten im Vordergrund steht. Muster können die Verständlichkeit des Modells erhöhen, wenn sie Konzepte und Begriffe des Anwendungsbereichs aufgreifen. Diese Art von Mustern nennen wir Konzeptionsmuster. Sie werden auch im Benutzungsmodell verwendet.

220 Konzeptionsmuster

Konzeptionsmuster: Konzeptionsmuster sind für Entwickler gedacht und unterstützen die Modellierung des Anwendungsbereichs. Sie basieren auf den für alle Beteiligten verständlichen Entwurfsmetaphern und sind auf einen begrenzten Anwendungsbereich ausgerichtet.

Konzeptionsmuster gehen über die Entwurfsmetaphern hinaus, da sie für Entwickler gedacht sind und auf die einzelnen Aktivitäten bei der Modellierung des Anwendungsbereichs ausgerichtet sind. Sie leiten uns bei der Analyse des Anwendungsbereichs. Mit ihrer Hilfe erken-

2


2.3


nen wir, welche Gegenstände des Anwendungsbereichs und welche Beziehungen zwischen diesen Gegenständen für das Modell relevant sind. Wir erschließen uns die Aufgaben und die Art und Weise ihrer Erledigung im Anwendungsbereich und machen dies im Modell explizit. Gleichzeitig werden wir solche Elemente und Muster für unser Modell wählen, die wir beim fachlichen und technischen Entwurf für das zukünftige System verwenden können. Konzeptionsmuster umfassen sowohl eine Sichtweise als auch eine Richtlinie, um den Anwendungsbereich wahrzunehmen, zu interpretieren und zu verändern. Hier zeigt sich erneut, daß für einen Entwickler die Analyse und Modellierung des Anwendungsbereichs immer mit dem Entwurf des künftigen Systems verbunden ist. In unserem Ansatz ist dies aber nicht die alleinige Aufgabe der Entwickler. Die Prinzipien einer evolutionären Vorgehensweise und die Autor-Kritiker-Zyklen fordern, daß alle Beteiligten aktiv am Gestaltungsprozeß mitwirken können. Dazu ist es notwendig, daß die Konzeptionsmuster in enger Verwandschaft zu den Entwurfsmetaphern stehen. Das Konzeptionsmuster Zusammenhang von Werkzeug und Material (s. Kapitel 3.1.1) ist ein grundlegendes Muster für die Anwendungsmodellierung. Bereits in Szenarios (s. Kapitel 5.2) verwenden wir Aus-

2

221

Beispiel


2.3


222

prägungen dieses Musters wie Pausenplan und Bleistift, um zu beschreiben, wie aktuelle Aufgaben mit Hilfe von Werkzeugen und Materialien erledigt werden. Beim Entwurf des zukünftigen Systems achten wir darauf, daß etwa in den Systemvisionen der Zusammenhang so erhalten bleibt, daß auch dort mit einem Werkzeug, dem Pausenplaner, auf dem Material Pausenplan in ähnlicher Weise gearbeitet werden kann wie bisher. Da Konzeptionsmuster wie alle anderen Muster nicht allgemeingültig sind, müssen auch sie einem bestimmten Kontext zugeordnet werden. Der Autor eines Konzeptionsmusters bewegt sich dabei zwischen zu großer Allgemeinheit und zu starker Spezialisierung. Ist ein Konzeptionsmuster zu abstrakt, dann trifft es auf alles oder nichts zu – es leitet nicht mehr an. Ein zu spezielles Muster dagegen wird vielleicht nur in einem einzigen Projekt nützlich sein, kann aber nicht Bestandteil einer wachsenden »Entwicklungskultur« werden. Deshalb ist es wichtig, Konzeptionsmuster zwar auf einen Anwendungsbereich, jedoch nicht zu speziell auszurichten. Die Warnung vor einer zu großen Spezialisierung sollte nicht ausschließen, daß Konzeptionsmuster für spezifische Anwendungsbereiche zugeschnitten werden. So können wir uns durchaus ein Muster Kunden haben Konten im Bankenbereich vorstellen. Man spricht in diesem Zusammenhang auch von Business Patterns (vgl. [Fowler 97, Hay 96, Boyd 98]; eine kurze Bibliographie

2


2.3


findet sich unter: http://www.riehle.org/BusinessPatterns/Bibliography.html). Das Muster aktive kooperierende Objekte scheint uns zu abstrakt, um ein wirklich nützliches Konzeptionsmuster zu sein. Aus dem Paar Pausenplaner und Pausenplan ein Konzeptionsmuster zu machen, ist auch wenig sinnvoll, da wir es außerhalb unseres Beispiels wohl nicht mehr verwenden werden. Dagegen hat sich Zusammenhang von Werkzeug und Material als Konzeptionsmuster für Arbeitsplatzsysteme im Bürobereich sehr bewährt. Es steht auf einer Ebene mit anderen Konzeptionsmustern wie Agent oder Medium (vgl. [CACM 94]). Die Übertragung des Musters Zusammenhang von Werkzeug und Material auf Echtzeitsysteme mit harten Zeitvorgaben hingegen ist nur begrenzt möglich. Das Entwurfsmodell steht an zentraler Stelle zwischen dem fachlichen Modell des Anwendungsbereichs und der Implementation (s. Kapitel 2.5.1). Es repräsentiert unser Verständnis des Anwendungsbereichs, berücksichtigt aber bereits die Restriktionen und formalen Anforderungen eines Softwaresystems. Wir benutzen Entwurfsmuster, um das Entwurfsmodell zu beschreiben und zu verstehen. Entwurfsmuster definieren die Struktur und Dynamik der Elemente dieses Modells und verdeutlichen das Zusammenspiel und die Verantwortlichkeiten der Elemente. Sie konkretisieren die konzeptionellen und

2

223 Beispiel

Entwurfsmuster


2.3


224

strukturellen Vorgaben der Konzeptionsmuster unter konstruktiven Gesichtspunkten. Aus unserer Sicht ist wichtig, daß das fachliche Modell des Anwendungsbereichs und das Entwurfsmodell möglichst wenig semantische Differenz aufweisen (vgl. [Bäumer 98]). Damit dies auch auf der Ebene der Beschreibungen gilt, sollten die Entwurfsmuster zu den Konzeptionsmustern und den dahinterstehenden Entwurfsmetaphern in enger Verbindung stehen. Die durch Entwurfsmuster definierten Elemente und Beziehungen sollten sich dann anhand eindeutiger Vorschriften strukturerhaltend auf das Implementationsmodell abbilden lassen.

2


2.3


225

Entwurfsmuster:

Entwurfsmuster (Design Patterns) verbinden die fachlichen Aussagen der Konzeptionsmuster mit den konstruktiven Anforderungen eines objektorientierten Entwurfs. Sie helfen, existierende Softwareentwürfe zu analysieren und zu reorganisieren. Sie erleichtern die Einarbeitung in Softwarearchitekturen (z.B. Klassenbibliotheken, Rahmenwerke), wenn diese auf der Basis von bekannten Entwurfsmustern dokumentiert sind. Entwurfsmuster sind »Mikroarchitekturen«, die sich von erfahrenen Entwicklern als Bausteine innerhalb größerer Softwarearchitekturen strukturerhaltend auf die Implementation abbilden lassen (Wiederverwendung von Design-Lösungen statt Wiederverwendung von Code). Sie stellen die Elemente einer Sprache dar, in der wir über Softwarearchitekturen nachdenken und kommunizieren können (z.B. Beobachter, Fabrik). Entwurfsmuster unterstützen die Ausarbeitung des Entwurfsmodells und helfen, die softwaretechnische Qualität von Entwürfen zu erhöhen (z.B. ihre Wiederverwendbarkeit und Erweiterbarkeit).

2


2.3


Entwurfsmuster stehen in engem Zusammenhang mit Rahmenwerken. Rahmenwerke enthalten und instanziieren Entwurfsmuster. Im besten Fall sind sie anhand von Konstruktionsmustern entwickelt worden. Zumindest sollten die Beschreibungen eines Rahmenwerks klarmachen, welche Entwurfsmuster im Rahmenwerk wie zusammenspielen. Damit »erzwingen« solche Rahmenwerke die Anwendung der Muster und ihrer ausgedrückten Entwurfsprinzipien auf konstruktive Weise [Beck & Johnson 94]. Entwurfsmuster sind in der Literatur und Praxis auf sehr unterschiedlichen Ebenen angesiedelt. Dies kann von Problemen großer Softwarearchitekturen [Garlan & Perry 95] bis zu sog. Mikroarchitekturen reichen. Die bekannteste Sammlung an Entwurfsmustern ist derzeit sicherlich [Gamma et al. 96]. Vergleichbar sind auch [Buschmann et al. 96] und mit höherem Abstraktionsgrad [Pree 95]. Das Konzeptionsmuster Zusamamenhang von Werkzeug und Material beschreibt die grundlegenden Entwurfselemente Werkzeug und Material vor dem Hintergrund eigenverantwortlicher Arbeit von Fachleuten. Mit dem Entwurfsmuster Werkzeug- und Materialkopplung gehen wir einen konstruktiven Schritt weiter (s. Kapitel 3.2.1). Wir beschreiben die explizite Schnittstellengestaltung der beiden Entwurfskomponenten und legen fest, daß sie lose gekoppelt werden sollen. Dazu bieten wir konkrete objektorientierte Konstruktionen an.

2

226 Entwurfsmuster und Rahmenwerke

Beispiel


2.3


Schließlich zeigen wir in unserer rahmenwerkbasierten Modellarchitektur, an welcher Stelle das grundsätzliche Zusammenspiel von Werkzeugen und Materialien in einem Rahmenwerk gekapselt werden kann (s. Kapitel 3.3). Für die Zwecke dieses Buches wollen wir die Entwurfsmuster weiter ausdifferenzieren. Dies ergibt sich aus dem Anspruch des WAMAnsatzes, der sich zwar an dem allgemeinen Anwendungsbereich Dienstleistungs- und Finanzsektor, nicht aber an einem bestimmten Programmiermodell orientiert. Diesen allgemeinen Anwendungsbereich haben wir fachlich durch unser Leitbild Arbeitsplatz für eigenverantwortliche Expertentätigkeit charakterisiert (s. Kapitel 2.2.3). Auf der softwaretechnischen Seite ist damit zwar ein Objekt-Metamodell (s. Kapitel 2.1), aber kein an einer bestimmten Sprache orientiertes Programmiermodell verbunden. Daraus ergibt sich, daß wir eine Anleitung für die Entwicklung von Entwurfsmodellen benötigen, die diese Allgemeinheit der Methodik berücksichtigt. Dazu wollen wir aber auch konstruktive Lösungen anbieten, die die Besonderheiten konkreter Programmiermodelle beachten. Dies führt zu Entwurfsmustern, die auf zwei Konkretisierungsebenen beschrieben sind – dem allgemeinen Beschreibungsteil und den Konstruktionsansätzen. Jedes Entwurfsmuster ist zunächst auf einer allgemeinen, von Programmiersprachen unabhängigen Ebene beschrieben. Dort wird das entsprechende Konzeptionsmuster auf die prinzipiellen Ausdrucks-

2

227

Ausdifferenzierung der Entwurfsmuster

Der allgemeine Beschreibungsteil eines Entwurfsmusters


2.3


228

möglichkeiten eines objektorientierten Entwurfs abgebildet, ohne schon die Besonderheiten einer konkreten Sprache zu berücksichtigen. Generalisierung und Spezialisierung sind beispielsweise Konzepte für Entwurfsmuster, ohne daß damit schon die Entscheidung getroffen ist, diese Relationen durch Vererbung zu realisieren. Weiter verwenden wir hier Gegenstände, Rollen oder Komponenten mit ihren Umgangsformen sowie Komposition statt Klassen, Objekte, Prozeduren und die Benutzt-Beziehung. So wird es möglich, die grundlegende Aufteilung der Dienstleistungen zwischen Entwurfskomponenten und ihr allgemeines Zusammenspiel zu beschreiben, ohne dabei bereits die Schnittstellen oder den konkreten Kontrollfluß festzulegen. Allenfalls kann es sinnvoll sein, hier das Typkonzept so zu verwenden, wie wir es in Kapitel 2.1.11 vorgestellt haben. Entwurfsmuster verdeutlichen auf dieser Ebene, welche grundlegenden konstruktiven Ideen hinter Konzepten wie z.B. Werkzeug, Material und Automat in einer Arbeitsumgebung stehen. Sie sind damit in ihrer Beschreibung »abstrakter« als Entwurfsmuster, die vom Charakter her an konkreten Programmiersprachen orientiert sind. Solche Teile der Beschreibung von Entwurfsmustern haben für ein Methoden- und Konstruktionsbuch eine große Bedeutung, da sie den Entwicklern den »Gestaltungsraum« der Elemente für die Entwicklung eines technischen Modells im Rahmen der Methode aufspannen.

2


2.3


Für die konkrete Projektarbeit müssen Entwurfsmuster durch jeweils passende konstruktive Teile ergänzt werden. Entwurfsmuster dienen also der Methodenarbeit. In Kapitel 3.2.1 gibt es das Entwurfsmuster Werkzeug- und Materialkopplung, das in seinem allgemeinen Teil die Entwurfskomponenten Werkzeug, Material und Aspekt zueinander in Beziehung setzt. Anschließend wird dieses Muster durch fünf unterschiedliche Konstruktionsansätze konkretisiert. Dabei wird gezeigt, wie sich Aspekte in unterschiedlichen Sprachen realisieren lassen.

229

Beispiel

Der allgemeine Teil eines Entwurfsmusters: ❑ beschreibt die abstrakten Modellierungselemente und Bezüge für den softwaretechnischen Entwurf, ❑ ist unmittelbar auf ein Konzeptionsmuster bezogen, ❑ muß durch unterschiedliche Konstruktionsansätze konkretisiert werden.

Ein Konstruktionsansatz verwendet die Elemente und Beziehungen des gewählten Programmiermodells, um damit die Struktur und Dynamik des Entwurfs zu verdeutlichen. Ein Konstruktionsansatz ist immer konkretisierender Teil eines Entwurfsmusters. Er zeigt die Rea-

2

Die Konstruktionsansätze eines Entwurfsmusters


2.3


230

lisierungsalternativen für ein Entwurfsmuster auf. Im Rahmen dieses Buches haben wir zu jedem Entwurfsmuster ein oder mehrere beispielhafte Konstruktionsansätze für die Programmiermodelle der Sprachen C++, Java oder Smalltalk angefügt. In der konkreten Projektarbeit werden Entwurfsmuster oft schon direkt in der Form von Konstruktionsmustern beschrieben, besonders dann, wenn die programmiersprachliche Basis fixiert ist. In der Praxis wird es immer wieder notwendig sein, Konstruktionsansätze auch für nicht-objektorientierte Sprachen zu entwickeln. Wir haben dies schon in einigen Fällen getan. Dabei war stets im Einzelfall zu klären, ob und welche objektorientierten Entwurfskonzepte auch auf der Implementierungsebene aufrechterhalten werden sollen. Da diese Fagestellung nicht in den Rahmen dieses Buches paßt, haben wir derartige Konstruktionsansätze ausgeklammert. Konstruktionsansätze sind natürlich bei der Rahmenwerkentwicklung von größter Bedeutung (s. Kapitel 2.3.2 und 3.3.3). Sie legen eine Implementierung oft schon detailliert fest. In der Praxis werden oft Teile einer erfolgreichen Anwendung als Kandidaten für

2


2.3


231

die Integration in ein vorhandenes Anwendungsrahmenwerk anhand von Konstruktionsansätzen überarbeitet. Konstruktionsansatz Ein Konstruktionsansatz ist der konstruktive Teil eines Entwurfsmusters. Er beschreibt die konkreten Elemente und Bezüge des softwaretechnischen Entwurfs. Konstruktionsansätze können unmittelbar in eine programmiersprachliche Implementation umgesetzt werden.

In Kapitel 3.2.1 gibt es zum Entwurfsmuster Werkzeug- und Materialkopplung unterschiedliche Konstruktionsansätze zur Realisierung von Aspekten: mit Hilfe von Vererbung, mit dem Adaptermuster, dem Dekorierermuster, als benannte Schnittstelle und mit Werkzeugunterstützung. Hier zeigt sich auch, daß wir zur Konkretisierung eines Entwurfsmusters (z.B. Werkzeug- und Materialkopplung) andere Entwurfsmuster (z.B. Adapter und Dekorierer) verwenden.

Beispiel

Neben dem Benutzungs- und dem Entwurfsmodell ist das Implementationsmodell das dritte Softwareentwicklungsmodell. Meist wird es nicht vom Programmcode getrennt, sondern ist in den Programmquel-

Programmiermuster

2


2.3


232

len »verkörpert«. Die gewählte Programmiersprache liefert die Notationen für dieses Modell. Zur Beschreibung und zum Verständnis dieses Modells benutzen wir Programmiermuster. Anders formuliert: Wenn wir Programmentwürfe und die tatsächlichen Implementationen schreiben, dann verwenden wir Programmiermuster. Programmiermuster sind in jeder Programmiersprache und -kultur unterschiedlich. Es ist bemerkenswert, daß auch auf dieser relativ »niedrigen« technischen Ebene so etwas wie Programmierkulturen und -stile existieren. Die Diskussion solcher Programmiermuster geht über den Rahmen dieses Buches hinaus (vgl. dazu [Coplien 92], der von Idioms spricht). Ein Beispiel für ein Programmiermuster ist folgende bekannte C-artige Schleifenstruktur, die sich fast in jedem C- und C++-Programm findet.

Beispiel

for (i=0; i<max; i++) {...}

Etwas oberhalb einer konkreten Programmiersprache angesiedelt ist die Einteilung von Klassenschnittstellen nach dem Programmiermuster Prozedur – Funktion – Prädikat, die wir in Anlehnung an [Meyer97] in Kapitel 2.1.4 Objekt vorschlagen. Dieses Muster paßt

2


2.3


233

zum Meyerschen Vertragsmodell (vgl. Kapitel 2.1.10 und [Meyer 97]), das als Entwurfsmuster aufgefaßt werden kann. Modelle, Metaphern und Muster

Offensichtlich besteht im WAM-Ansatz ein Zusammenhang zwischen Entwurfsmetaphern, den unterschiedlichen Arten von Mustern und den Modellen bei der Softwareentwicklung. Wir haben eine Entwurfsmetapher als eine bildhafte, gegenständliche Vorstellung definiert, die ein Leitbild fachlich und konstruktiv »ausgestaltet«, d.h. konkretisiert. Sie dient den an der Gestaltung von Softwaresystemen Beteiligten zur Wahrnehmungs- und Verständigungsgrundlage. Im Bereich der Alltagssprache angesiedelt machen Entwurfsmetaphern den Anwendungsbereich durchschaubarer und die Handhabung und Funktionalität des entwickelten Anwendungssystems verständlicher. Dies gilt, wie gesagt, für alle beteiligten Personen, nicht nur für die Entwickler. Dagegen sind die hier beschriebenen unterschiedlichen Muster vorrangig auf der Ebene der Softwareentwicklung angesiedelt und beziehen sich auf die Aktivitäten der Entwickler. Schon bei der fachlichen Modellierung müssen wir als Entwickler die Entwurfsmetaphern konkreter fassen. Denn bereits hier stellt sich die Frage, welche Gegenstände des Anwendungsbereichs mit Blick auf das zukünfige System

2


2.3


234

überhaupt und mit welcher Detaillierung beschrieben werden sollen. Bei der Beantwortung dieser Frage bieten die Konzeptionsmuster Hilfestellung. Für den WAM-Ansatz ist wichtig, daß unsere Entwurfsmetaphern immer auch eine technische Interpretation in der Form von Konstruktionsanleitungen besitzen, auf deren Basis sie sich effizient implementieren lassen. In diesem Buch sind die grundlegenden Elemente des technischen Entwurfs durch die allgemeinen Teile der Entwurfsmuster beschrieben. Diese werden für den technischen Entwurf und das Implementationsmodell konkretisiert durch Konstruktionsansätze und Programmiermuster. Die Entwurfsmetaphern und die allgemeinen Teile der Entwurfsmuster werden je nach Kontext und Leitbild angepaßt und erweitert. Die Konstruktionsansätze und die Programmiermuster werden mit Blick auf die gewählte Programmiersprache und die Systembasis erstellt. Daraus läßt sich eine Leitlinie für den Umgang mit Mustern ableiten: Analysiere bei der Entwicklung von Anwendungssoftware den Anwendungsbereich und erarbeite das fachliche Modell mit Hilfe von Konzeptionsmustern, erstelle den technischen Entwurf mit Entwurfsmustern und implementiere mit Hilfe von Programmiermustern.

2


2.3


Wir greifen wieder das Beispiel von Werkzeug und Material auf. Diese sind als Entwurfsmetaphern alltagssprachlich z.B. wie in Kapitel 2.2.3 beschrieben. Das auf dieser Ebene angesiedelte Konzeptionsmuster ist Zusammenhang von Werkzeug und Material, so wie es in Kapitel 3.1.1 beschrieben und hier in Abbildung 2-20 dargestellt ist: In einem büroartigen Arbeitskontext von eigenverantwortlicher Expertentätigkeit ist es sinnvoll, zum Verständnis der anstehenden Aufgaben den Umgang mit Arbeitsmitteln und Arbeitsgegenständen als die Arbeit mit Werkzeug auf Material zu betrachten. Dies drückt das Konzeptionsmuster aus. Für den Entwurf präzisieren wir dieses Konzept dahingehend, daß wir zunächst die beiden Entwurfskomponenten Werkzeug und Material einführen. Ihr Zusammenspiel, das Zueinanderpassen, wird durch die Aspekte ausgedrückt. Ein Aspekt gibt an, was ein Material an Eigenschaften besitzen muß, damit ein Werkzeug darauf arbeiten kann. Andererseits kennt ein Werkzeug alle seine Materialien nur unter dem entsprechenden Aspekt. Dieser Zusammenhang wird im allgemeinen Teil des Entwurfsmusters vorgegeben. In unserem Beispiel können wir uns eine naive Konkretisierung des Musters so vorstellen, daß ein Pausenplaner nur den Aspekt kennt, nicht aber das konkrete Material Pausenplan.

2

235 Beispiel


2.3


236

Schließlich muß der Entwurf noch auf der konstruktiven Ebene umgesetzt werden. Wir müssen festlegen, wie sich Aspekte mit programmiersprachlichen Mitteln realisieren lassen. Dies wird durch einen Konstruktionsansatz beschrieben. In Abbildung 2-20 ist eine Lösung mit Aspektklassen und Mehrfachvererbung gewählt worden. Dabei benutzt eine Werkzeugkomponente entsprechende Aspektklassen. Ein für das Werkzeug passendes Material muß die in den Aspektklassen definierten Schnittstellen erben und materialspezifisch implementieren. In unserem Beispiel verwendet das Werkzeug Pausenplaner zwei Aspektklassen, die vom Material Pausenplan geerbt und implementiert werden. Dazu kommt eine weitere Aspektklasse, die in einem anderen Zusammenhang (z.B. von einem Datenbankautomat) von diesem Material gefordert wird.

2


2.3

Kontext: Büroarbeit

Werkzeug bearbeitet

Material

Konzeptionsmuster


237

Werkzeug z.B. Pausenplaner


benutzt

Aspekt z.B. von_Pausenplaner_bearbeitbar

Aspektklasse1 z.B. Druckbar

Aspektklasse2 z.B. Editierbar

Aspektklasse3 z.B. Speicherbar

konkretisiert Material z.B. Pausenplan

Material z.B. Pausenplan

Entwurfsmuster

Konstruktionsansatz Abb. 2-20

Mustersammlungen

Zusammenhang zwischen

Muster, so wie wir sie hier beschreiben, stehen nicht isoliert da. Sie sind schon durch den gemeinsamen Anwendungsbereich verbunden. Im WAM-Ansatz kommt dazu, daß die Entwurfsmetaphern innerhalb eines Leitbilds schon ein Beziehungsgefüge bilden. Daher sind auch die dazu passenden Muster miteinander verknüpft: Ein Muster enthält ein anderes oder interagiert mit einem anderen.

2

Konzeptionsmuster, Entwurfsmuster und einem Konstruktionsansatz


2.3


Soweit Muster wieder Muster enthalten, können sie zu Mustersammlungen geordnet werden. Dabei bedeutet »ein Muster enthält ein anderes«, daß der Kontext des einen Musters den des anderen umfaßt oder daß das eine Muster zum Verständnis des anderen vorausgesetzt wird. In diesem Sinne geht das umfassendere Muster dem anderen logisch und in der Beschreibung voraus. Dies gilt auch innerhalb einer Musterart (z.B. Konzeptionsmuster). Generell umfassen die anwendungsorientierten Muster die technischen Muster. Entsprechend kommen Konzeptionsmuster vor Entwurfsmustern und vor Programmiermustern. Das Konzeptionsmuster Zusammenhang von Werkzeug und Material beschreibt den Kontext, in dem Werkzeuge und Materialien zusammenspielen. Erst auf dieser Grundlage läßt sich sinnvoll diskutieren, was einen Werkzeugentwurf charakterisiert. Dies wiederum ist die konzeptionelle Basis, um als Entwurfsmuster die Trennung von Interaktion und Funktion verstehen zu können. Dieses Muster geht dem Entwurfsmuster Rückkopplung zwischen Interaktion und Funktion voraus, das in ähnlicher Form für die Werkzeugkomposition eingesetzt wird. Die jeweilige Konkretisierung greift in ihren Konstruktionsansätzen auf bekannte Muster wie den Beobachter aus [Gamma et al. 95] zurück.

2

238

Beispiel


2.3


239

Konzeptionsmuster

Abbildung 2-21 zeigt den großen Zusammenhang der verschiedenen WAM-Muster, wie er in den Kapiteln 3.1 und 3.2 beschrieben ist. Zusammenhang von Werkzeug und Material Werkzeugentwurf Arbeitsumgebung

Materialentwurf Behälter

Automat Werkzeug- und Materialkopplung

Entwurfsmuster

Trennung Interaktion und Funktion Rückkopplung zwischen Funktion und Interaktion

fachliche Behälter

technische Behälter

Werkzeugkomposition Trennung von Handhabung und Präsentation

Umgebung

Fachwerte

Ereignis- MaterialMaterialverwalter verwalter koordinator

Abb. 2-21 Die WAM-Musterhierarchie

2


2.3


Wenn wir Muster in Sammlungen hierarchisch anordnen, dann stellt sich die Frage nach dem »äußeren Rand« dieser Beschreibung. Das ist insofern interessant als das »oberste« Muster einer Sammlung nicht den Kontext beschreiben kann, da dieser, wie wir sagten, potentiell unbegrenzt ist. Damit sind wir an einem bekannten Problem der Systemtheorie angekommen: Um ein System zu definieren, muß meist auf Begriffe und Konzepte zurückgegriffen werden, die nicht Teil des Systems und seiner Definition sind. Diese Begriffe oder Konzepte müssen aber in irgendeiner Weise selbst wieder definiert werden, wozu andere Begriffe nötig sind. Dies führt zu einem endlosen Regress von ineinander geschachtelten Kontexten und Begriffsgebäuden. Da wir also auf diese Weise den Kontext nicht als äußerstes Muster beschreiben können, bleibt uns nur eine pragmatische Lösung: Der äußere Kontext eines Musters oder einer Mustersammlung kann nur durch einen gemeinsamen Erfahrungshintergrund von Musterautor und -lesern verständlich werden. Einen Erfahrungshintergrund können wir aber mit anderen nur teilen, nicht definieren. Der Hintergrund wird gebildet von der kulturellen, sozialen und individuellen Vergangenheit, den Erfahrungen und den Kenntnissen der Personen, die Muster beschreiben und in ihrem Bereich einsetzen. Dies alles läßt sich nicht in einer einfachen Beschreibung des Hintergrunds fassen und vermitteln. Hier stellt sich der Zusammenhang zum Anwendungswissen und unserem Leitbild her. Erst eine möglichst genaue Kenntnis des Anwen-

2

240 Musterkontext


2.3


241

dungsbereichs bringt das nötige Anwendungswissen, um die Aufgaben mit ihren Problemen und Lösungen zu verstehen, die die Grundlage für die entsprechenden Muster waren. Dazu kommt ein Leitbild, das eine gemeinsame eingrenzende Sicht auf ein Softwaresystem eröffnet. Anwendungswissen und Leitbild schaffen die Basis, um an einen gemeinsamen Erfahrungshintergrund für Muster zu »appellieren«. Damit soll nicht gesagt werden, daß Muster nur von denen verstanden werden können, die gemeinsame Erfahrungen sowie ein gleiches Ausbildungs- und Wissensniveau teilen. Ein recht erfolgreiches Vehikel, um einen gemeinsamen Hintergrund anzusprechen, sind z.B. Fallstudien (vgl. [Gamma et al. 96]). Muster und Kontext: Muster können nur dann ausgetauscht und im notwendigen Ausmaß verstanden werden, wenn die Musterautoren und -leser einen gemeinsamen Hintergrund haben. Jedes Muster ist auf einen bestimmten fachlichen und technischen Anwendungsbereich ausgerichtet. Deshalb werden seine Verwendbarkeit und Konsequenzen nur für die einschätzbar sein, die genügend Erfahrung und Wissen in diesem Bereich besitzen. Fallstudien können einen Zugang zu diesem Hintergrund schaffen.

2


2.3


242

Musterbeschreibungen

Hoare hat einmal festgestellt, daß jede Abstraktion eine Notation braucht, die ihr die notwendige Form gibt [Hoare72]. Dieser Satz trifft auch auf Muster zu. Allgemein herrscht in der Literatur Übereinstimmung darin, daß Muster auch in einer strukturierten Musterform beschrieben werden sollten. Dies hat schon Alexander getan und es ist bei Entwurfsmustern üblich (vgl. [Alexander et al. 77, Gamma et al. 96, Coplien & Schmidt 95]). In diesem Sinne haben wir unterschiedliche Musterbeschreibungen untersucht (s. [Riehle & Züllighoven 96]). Als wesentliches Ergebnis läßt sich feststellen, daß die Wahl der geeigneten Form einer Musterbeschreibung vom angestrebten Zweck abhängt. Dies ist sicher nicht überraschend, doch offenbar nur wenigen der Musterautoren wirklich klar geworden. In [Coplien & Schmidt 95] haben wir und andere eine minimalistische Form gewählt, die im wesentlichen die Abschnitte Problem, Kontext und Lösung enthält. Der Problemabschnitt beschreibt in einer knappen Form das anstehende Problem. Der Kontextabschnitt erläutert typische Situationen, in denen das Problem auftritt und die Kräfte und Randbedingungen, die die Lösung beeinflussen. Und schließlich

2


2.3


243

gibt der Lösungsabschnitt Auskunft darüber, wie sich die Kräfte im jeweiligen Kontext binden lassen. Die klassische Musterbeschreibung (nach Alexander): besteht aus den Abschnitten Problem, Kontext, Lösung. Diese Form bewährt sich, wenn mit Hilfe des Musters für ein gegebenes Problem Lösungen erarbeitet werden sollen.

Diese Musterform nennen wir klassisch, da sie in dieser Art von [Alexander et al. 77] selbst vorgeschlagen wurde. Charakteristisch für diese Form ist, daß sie generativ, das heißt zur Problemlösung eingesetzt werden kann. Die Lösung ist meist so beschrieben, daß das Muster für ein konkretes Problem auf einfache Art und Weise »instanziiert« werden kann. So geben [Buschmann et al. 96] eine schrittweise Anleitung für die Implementierung der von ihnen beschriebenen Muster. Andere Musterbeschreibungen sind primär »deskriptiv«; ihr Fokus liegt auf Struktur und Dynamik des Musters einer Konstruktion, die dadurch erklärt werden soll.

2


2.3


244

In diesem Konstruktionshandbuch verwenden wir eine Musterbeschreibung, die flexibel an die Form in [Gamma et al. 96] angelehnt ist. Für die Musterbeschreibungen in diesem Buch verwenden wir die folgenden Einteilungen, wobei nicht jedes Muster alle Teile enthalten muß: ❑ Namen des Musters, ❑ Problem, das mit Hilfe des Musters gelöst werden soll, ❑ Kontext, in dem sich das Problem stellt und für den unterschiedlich wirkende Kräfte aufgezeigt werden, ❑ Lösung, in der die Elemente des Musters in ihrer Rolle und Beziehung untereinander dargestellt und die Gestaltung ihrer Interaktion vorgegeben werden, ❑ Beispiel, in dem meist das Pausenplanbeispiel verwendet wird; wir greifen auch auf Beispiele aus unseren Kooperationsprojekten zurück, ❑ Diskussion der unterschiedlichen Konstruktionsansätze, ❑ die positiven und negativen Konsequenzen der Musteranwendung.

2


2.3


245

2.3.2 Rahmenwerke Schon mit der Verbreitung der ersten objektorientierten Programmiersprachen war die Wiederverwendung ein wichtiges Thema. In klassischen prozeduralen Sprachen können Konstruktionseinheiten, wie Module, nur so benutzt werden, wie sie vorgegeben sind. Um das damit verbundene Konzept in ähnlicher Form zu verwenden, muß der Programmtext kopiert und modifiziert werden. Die objektorientierten Konstrukte Klasse und Vererbung ermöglichen, eine Klasse in einer Unterklasse durch Redefinition und Ergänzung in ähnlicher Weise zu verwenden, ohne die ursprüngliche Klasse verändern und damit für ihre Klienten unbrauchbar machen zu müssen. Meyer spricht in diesem Zusammenhang von dem Offen-Geschlossen-Prinzip der Objektorientierung: Eine Klasse steht als geschlossene, d.h. stabile Konstruktionseinheit für ihre Klienten zur Verfügung, ist aber als Entwurfseinheit für Unterklassenbildung offen (s. [Meyer 97]). Das Offen-Geschlossen-Prinzip führte dazu, daß Klassenbibliotheken ein fester Bestandteil von objektorientierten Programmiersprachen wurden. Sie stehen nicht nur wie Modulbibliotheken als eine ungeordnete Sammlung von fertigen Bausteinen zur Verfügung, sondern sie bilden eine flexible Hierarchie von erweiterbaren Bausteinen und Konzepten. Damit wird einerseits die gegebene Programmierspra-

2

Klassenbibliotheken


2.3


246

che auf der Typebene erweitert, andererseits bilden Klassenbibliotheken die Basis für neue benutzerdefinierte Typ- und Klassenhierarchien. In der Regel ist jede Klasse einer Klassenbibliothek unabhängig von anderen Klassen der Bibliothek verwendbar. Objekte, die von Klassen einer Bibliothek erzeugt werden, kooperieren daher auch nicht von selbst mit weiteren aus der Bibliothek instanziierten Objekten. Das Zusammenspiel zwischen den Objekten, d.h. der Kontrollfluß, wird im Programmcode des Anwendungssystems festgelegt. Eine Behälterbibliothek repräsentiert ein typisches Beispiel für eine Klassenbibliothek. Sie wird meist wie eine Modulbibliothek unmittelbar mit ihren einzelnen Bausteinen wiederverwendet. Darüber hinaus lassen sich aber daraus benutzerdefinierte Behälter ableiten, die dann genau wie die vorgegebenen Behälter benutzt werden können. Klassenbibliothek: Eine Klassenbibliothek (Class Library) faßt eine Menge von einzeln verwendbaren Klassen zu einer Einheit zusammen. Klassenbibliotheken werden bei der Verwendung spezialisiert oder direkt benutzt. Eine Klassenbibliothek gibt keinen Kontrollfluß für das Anwendungssystem vor.

2


2.3


Mit der Entwicklung ganzer Familien von objektorientierten Anwendungssystemen in einer Domäne zeigten sich Ähnlichkeiten zwischen diesen Anwendungen nicht nur auf der Ebene von Klassen oder Typen. Diese Ähnlichkeiten beziehen sich auf das Zusammenspiel von mehreren Konstruktionselementen, d.h. Klassen oder Objekten, die im Anwendungsbereich ein wiederkehrendes Problem auf vergleichbare Weise lösen. Dies läßt sich gut am Beispiel neuerer Behälterbibliotheken demonstrieren, die die »klassischen« Datenstrukturbibliotheken (Collection Classes) weiterentwickelt haben. Dort werden nicht passive Datenstrukturen mit Zugriffsoperationen zusammengefaßt, sondern die Behälter werden um explizite Marker, Cursors oder sogenannte robuste Iteratoren ergänzt (vgl. [Kofler 93, Traub 95]), mit denen sich Behälter durchsuchen und bearbeiten lassen. Wir haben also nicht nur eine Behälterklasse, sondern ein Zusammenspiel eines Behälters mit einem oder mehreren Iteratoren vor uns. Auch an die im Behälter verwalteten Elemente werden jetzt bestimmte Anforderungen in einer abstrakten Oberklasse formuliert. Dieses Zusammenspiel läßt sich allgemein in Klassenstrukturen und den daraus erzeugten Objekten ausdrücken. Hierfür verwendet man den Begriff Rahmenwerk. In diesem Sinne schreiben [Birrer et al. 95]: »Ein Framework besteht aus einer Menge

2

247 Rahmenwerke


2.3


von Objekten, die eine generische Lösung für eine Reihe verwandter Probleme implementieren«. Hier wird die Verbindung zu den Mustern sehr deutlich. Denn wir haben gesagt, daß ein Muster eine Abstraktion von einer konkreten Form ist, die wiederholt in bestimmten, nicht willkürlichen Kontexten auftritt. Der wesentliche Unterschied zwischen Rahmenwerk und Muster ist, daß sich die erkannte Abstraktion nicht nur in Textform, sondern als eine »halbfertige« Klassenstruktur beschreiben läßt. Die Klassenstruktur eines Rahmenwerks gibt einerseits die Architektur und den Kontrollfluß des Anwendungssystems vor, sie hat andererseits definierte Stellen (Pree spricht von »Hot Spots«, [Pree 95]), an denen der Anwendungsentwickler seine konkrete Lösung festmachen kann.

248 Zusammenhang Rahmenwerk und Muster

Rahmenwerk (nach [Weiß97]): Ein Rahmenwerk (Framework) ist eine Architektur aus Klassenhierarchien, die eine allgemeine generische Lösung für ähnliche Probleme in einem bestimmten Kontext vorgibt. Wiederverwendet werden dabei nicht einzelne Klassen, sondern die gesamte Konstruktion aus zusammenspielenden Komponenten. Ein Rahmenwerk gibt so den Kontrollfluß für die Anwendung vor. Ein Rahmenwerk wird zu einer konkreten Anwendung, indem dafür vorgesehene Klassen spezialisiert oder vorgegebene Parameterobjekte erzeugt werden.

2


2.3


Die unterschiedliche Art, wie aus einem Rahmenwerk eine Anwendung erzeugt wird, führt zur Unterscheidung von Black-box- und White-box-Rahmenwerken (siehe nachfolgenden Abschnitt). Rahmenwerke können Problemlösungen für jeden Bereich verkörpern. Geben sie den Entwurf und wesentliche Konstruktionen zur Entwicklung eines kompletten Anwendungssystems vor, spricht man von Anwendungsrahmenwerken. Verbreitet sind bisher eher softwaretechnische Rahmenwerke, die zur Realisierung von grafischen Oberflächen oder eines Persistenzmechanismus gedacht sind. Anwendungsrahmenwerke sind wesentlich komplexer und auch komplizierter, da sie sowohl eine Abstraktion über einen konkreten Anwendungsbereich als auch eine geeignete softwaretechnische Architektur vorgeben müssen. Daher wird ein Anwendungsrahmenwerk meist durch mehrere Rahmenwerke realisiert, die jeweils einen separierbaren Aspekt der Anwendung verkörpern. In Kapitel 3.3 stellen wir Entwurfs- und Architekturprinzipien für ein WAM-Anwendungsrahmenwerk vor.

2

249 Einteilung von Rahmenwerken


2.3


250

Anwendungsrahmenwerk: Ein Anwendungsrahmenwerk (Application Framework) ist für die Entwicklung von Anwendungssoftware in einem fachlich eingegrenzten Anwendungsbereich gedacht. Es gibt die softwaretechnische Architektur und die relevanten fachlichen Abstraktionen in Form einer generischen Lösung vor. Konstruktiv wird ein Anwendungsrahmenwerk meist durch mehrere Rahmenwerke realisiert.

Black-box- und White-box-Rahmenwerke

In der Literatur (vgl. [Johnson & Foote 88]) werden Rahmenwerke anhand der Art ihrer Verwendung in Black-box- und White-box-Rahmenwerke unterschieden. Bei der Entwicklung eines Anwendungssystems mit Hilfe eines Black-box-Rahmenwerks werden von speziell dafür vorgesehenen Rahmenwerkklassen Objekte erzeugt. Diese Objekte lassen sich häufig mit Hilfe von weiteren Objekten konfigurieren. Solche Konfigurationsobjekte werden ebenfalls von Klassen desselben oder eines anderen Black-box-Rahmenwerks instanziiert.

2

Black-box-Rahmenwerk


2.3


251

Black-box-Rahmenwerk: Die Verwendung eines Black-box-Rahmenwerks ist so gedacht, daß Objekte von darin enthaltenen Klassen erzeugt werden, die sich in der Regel durch Konfigurationsobjekte den anwendungsspezifischen Erfordernissen anpassen lassen.

Am Beispiel eines Konto-Verzinsers erläutern wir die Verwendung von Konfigurationsobjekten (s. Abbildung 2-22): Möchte ein Softwareentwickler ein Sparbuch mit einer nachschüssigen Verzinsung erzeugen, so verwendet er das Konto- und das Verzinser-Rahmenwerk. Er instanziiert zunächst ein Objekt der Klasse Sparbuch, dem er dann ein Objekt der Klasse NachschussVerzinser übergibt. Dadurch konfiguriert er die Zinsberechnung des Sparbuchs auf eine nachschüssige Verzinsung. Der Aufruf von berechneZinsen am Sparbuch führt dazu, daß an der Zinsstrategie NachschussVerzinser die Operation rechne gerufen wird. Die Bezeichnung Black box bringt dabei zum Ausdruck, daß der Anwender bei der Verwendung des Rahmenwerks keine Kenntnisse über die Interna des Rahmenwerks benötigt.

2


2.3


Komponente Verzinser-Rahmenwerk

Komponente Konto-Rahmenwerk

Verzinser

(Konto) eineZinsStrategie

setzeZinsstrategie(Verzinser*) berechneZinsen(Laufzeit)

GiroKonto

Sparbuch

252

rechne(Betrag, Laufzeit)

Vorschuss Verzinser

Kreditkonto

rechne(Betrag, Laufzeit)

Nachschuss Verzinser rechne(Betrag, Laufzeit)

.. . Zinsen = eineZinsStragegie-> rechne(Saldo,Laufzeit); .. .

Abb. 2-22 Das Konto-VerzinserBeispiel

2


2.3


Die Verwendung eines White-box-Rahmenwerks hingegen ist nur mit Wissen über den internen Aufbau des Rahmenwerks, insbesondere über das in den Klassen modellierte Zusammenspiel der Objekte, möglich. Mit Hilfe von White-box-Rahmenwerken werden Anwendungen so entwickelt, daß ausgezeichnete Klassen des Rahmenwerks in Unterklassen spezialisiert werden und dadurch den Anschluß an die übrigen Klassen des Anwendungssystems herstellen. Die von den Unterklassen eines White-box-Rahmenwerks erzeugten Objekte lassen sich auf zwei unterschiedliche Arten verwenden:

253 White-boxRahmenwerk

❑ Die erzeugten Objekte werden direkt in einem Anwendungs-

system benutzt. Das Konto-Rahmenwerk könnte beispielsweise so gestaltet sein, daß es die Klasse Konto und das abstrakte Zusammenspiel mit Objekten der Klasse Verzinser implementiert. Konkrete Unterklassen von Konto wären in dem Rahmenwerk nicht enthalten und müßten daher in den Anwendungssystemen durch Unterklassenbildung konstruiert werden. Vom Rahmenwerk erbt eine Unterklasse dann das Zusammenspiel mit Verzinsern, das sie demnach nicht selber implementieren muß.

2


2.3


254

❑ Die Objekte der Subklassen werden zur Konfiguration einge-

setzt. Das Rahmenwerk könnte etwa konkrete Kontoklassen (Girokonto, Sparbuch, usw.), aber keine Verzinsungsstrategien bereitstellen. In einem Anwendungssystem müßte daher eine geeignete Unterklasse der abstrakten Klasse Verzinser gebildet werden, deren Objekte dann zur Konfiguration konkreter Kontoobjekte benutzt werden. White-box-Rahmenwerk: White-box-Rahmenwerke sind dazu konzipiert, daß von speziell dafür vorgesehenen Klassen Unterklassen gebildet werden. Objekte dieser Unterklassen lassen sich direkt in Anwendungssystemen oder weiteren Rahmenwerken benutzen. Sie können auch zur Konfiguration von Objekten eingesetzt werden, die ebenfalls von Klassen eines Rahmenwerks erzeugt wurden.

Wie die vorherigen Beispiele zeigen, sind Black-box-Rahmenwerke einfach zu erlernen und einzusetzen, während White-box-Rahmenwerke in der Verwendung flexibler sind. Erfahrungen zeigen, daß Black-box-Rahmenwerke häufig durch eine sukzessive Erweiterung von White-box-Rahmenwerken um weiterreichende Standardlösun-

2

Vergleich Black box, White box


2.3


255

gen entstehen (vgl. [Johnson & Foote 88]). Rahmenwerke werden in der Softwareentwicklung also nicht nur zur Konstruktion von Anwendungssystemen eingesetzt, sondern sind auch die Basis für die Entwicklung weiterer Rahmenwerke. Black-box- und White-box-Rahmenwerke werden nicht starr unterschieden. Die Einteilung ergibt sich vielmehr aus dem jeweiligen Verwendungszusammenhang bei der Softwareentwicklung. Zwar werden Rahmenwerke, die für eine White-box-Verwendung konzipiert sind, hauptsächlich auch so verwendet. Sie können aber auch vorgefertigte Standardlösungen enthalten, die Softwareentwickler black-box-artig verwenden. Umgekehrt erlauben Black-box-Rahmenwerke natürlich meist eine White-box-Verwendung. Verbindungsstücke zwischen Rahmenwerken

In Kapitel 2.3.1 haben wir dargelegt, daß sich Entwurfsmuster zur Beschreibung von komplexen Zusammenhänge zwischen Komponenten einsetzen lassen. So beschreiben Entwurfsmuster beispielsweise die Verantwortlichkeiten und die Zusammenarbeit einer Reihe von Klassen, die ein konkretes Entwurfsproblem lösen. Teilen sich nun die Klassen des Entwurfsmuster auf mehrere miteinander zu koppelnde

2


2.3


256

Rahmenwerke auf, so beschreibt das Entwurfsmuster das Protokoll, mit dem die einzelnen Rahmenwerke interagieren. Kopplung von Rahmenwerken: Interagierende Rahmenwerke können durch einfachen Aufruf der Schnittstelle einer entsprechenden Rahmenwerksklasse gekoppelt werden. Oft ist die Interaktion aber komplexer und kann auf Schnittstellenebene durch ein Entwurfsmuster beschrieben werden.

Um dies zu verdeutlichen, betrachten wir erneut die Rahmenwerke Konto und Verzinser (s. Abbildung 2-23). Das Verzinser-Rahmenwerk ist ein Black-box-Rahmenwerk und wird zur Konstruktion des Konto-Rahmenwerks verwendet. Die Verzinser-Klassen lassen sich als Strategien in den Konto-Klassen einsetzen. Um das Beispiel zu vereinfachen, werden die entsprechenden Strategie-Objekte in den konkreten Konto-Klassen erzeugt. Betrachtet man nun das Strategie-Muster (s. [Gamma et al. 96]) als Verbindungsstück, so wird deutlich, welche Klassen des Konto- und Verzinser-Rahmenwerks welche Verantwortlichkeiten des Strategie-Musters übernehmen. Die Konto-Klasse nimmt innerhalb des Strategie-Musters die Verantwortlichkeiten des

2


2.3


257

Kontextes wahr, die Verzinser-Klasse übernimmt die Verantwortlichkeit als Strategie. Abb. 2-23

KontoRahmenwerk Konto als Kontext

VerzinserRahmenwerk Verzinser als Strategie

Strategie

Das Strategie-Muster als Verbindungsstück zwischen zwei Black-boxRahmenwerken

Mit dieser Konstruktion ist noch nicht festgelegt, welche konkrete Verzinsungsstrategie aus dem Verzinser-Rahmenwerk für die Implementierung einer Konto-Klasse im Konto-Rahmenwerk verwendet wird. Diese Information hat keine Auswirkung auf die Architektur, sondern stellt ein fachliches Detail dar, dessen Umsetzung bei der Konstruktion der konkreten Konto-Klassen zu leisten ist.

2


2.4

2.4

Anwendungsorientierte Softwareentwicklung

258


Wir skizzieren kurz unser Verständnis von anwendungsorientierter Softwareentwicklung als einer Ausprägung der Objektorientierung. Aus unserer Sicht ist viel Verwirrendes und oft Falsches über objektorientierte Softwareentwicklung geschrieben worden. Die Argumente gehen in unterschiedliche Richtungen. Ein Argument besagt, daß objektorientierte Programmierung als Technik deshalb bessere Softwareprodukte gewährleistet, weil die Programme sehr verständlich, leicht änderbar und im hohen Maße wiederverwendbar seien. In eine andere Richtung wird diskutiert, daß durch die bessere objektorientierte Konstruktionstechnik eine klarere Phasenaufteilung des Entwicklungsprozesses möglich wird. Wir argumentieren wie folgt:

Federführung: Heinz Züllighoven Ko-Autoren: Dirk Bäumer, Guido Gryczan, Thomas Slotos

❑ Objektorientierte Softwareentwicklung sollte primär auf die

Gebrauchsqualität des Produktes abzielen. ❑ Hohe Gebrauchsqualität läßt sich nur durch einen anwen-

dungsorientierten evolutionären Entwicklungsprozeß erreichen.

2.4.1 Anwendungssoftware Wir behandeln in diesem Buch die Entwicklung interaktiver Anwendungssoftware. Dabei gelten einige Voraussetzungen:

2


2.4


259

❑ Objektorientierte Entwicklung von Anwendungssoftware ist

professionelle Teamarbeit. ❑ Es besteht ein enger Zusammenhang zwischen dem Software-

produkt und seinem Entwicklungsprozeß.

Anwendungssoftware (s. [Floyd & Züllighoven 97]): Anwendungssoftware ist ein Mittel zum Zweck, um fachliche Aufgaben in einem oder mehreren Anwendungsbereichen zu erledigen. Dazu werden vorhandene oder neue Problemlösungsstrategien durch Software realisiert. Sie modelliert einen Ausschnitt der realen Welt und orientiert sich an einem Einsatzkontext, der konkret vorgegeben sein kann (dediziertes System) oder allgemein gehalten wird (Standardsoftware). Anwendungssoftware dient der Steuerung von technischen Prozessen oder der Unterstützung von Arbeitsprozessen. Bei ihrer Gestaltung ist sowohl auf die fachliche Stimmigkeit als auch auf die menschengerechte Handhabung und Präsentation zu achten. Die Realisierung von Anwendungssoftware setzt eine Systembasis voraus, die aus Hardware und der zugrundeliegenden Basissoftware besteht.

2


2.4


260


Traditionell (und erfolgreich) hat Anwendungssoftware menschliche Routinetätigkeiten automatisiert. Menschliche Arbeit wurde durch Software weitgehend ersetzt oder bis auf wenige notwendige Dateneingaben reduziert (s. Kapitel 2.2.1, S. 78). Beispiele im Bankenbereich sind Programme zur Geldüberweisung oder zur Berechnung von Kontogebühren. Diese Programme zeigten wenig anwendungsorientierte Merkmale oder Gebrauchsqualität und waren vorrangig auf »Datenverarbeitung« ausgerichtet. Betrachten wir ihre Benutzungsschnittstelle, so kann die typische großrechnerorientierte Kombination von Menüs und Bildschirmmasken kurz als »Fenster auf Daten« bezeichnet werden. Mit der Verbreitung grafischer Anwendungen auf Arbeitsplatzrechnern und PCs verschob sich auch der Fokus von der Automatisierung menschlicher Routine zur Unterstützung alltäglicher Arbeitsaufgaben. Dies lag nahe, denn die ersten grafischen Schnittstellen für Büroanwendungen waren ja bewußt nach der Metapher des Schreibtischs konzipiert worden (s. Kapitel 2.2.2). Grafische Benutzungsschnittstellen waren also ein entscheidender Schritt auf dem Weg zur Gebrauchsqualität von Anwendungssoftware. Auf einmal wurde das Design von Software als »Gestaltung« sichtbar und erfahrbar. Alltäg-

2

Rückblick und Motivation


2.4


liche Arbeitsformen ließen sich auf den Rechner übertragen: Ein Benutzer konnte gleichzeitig mit mehreren Werkzeugen an unterschiedlichen Gegenständen zur Erledigung einer Aufgabe arbeiten, um je nach Situation etwas »zur Seite« zu legen und es später im selben Zustand wieder aufzugreifen. Für die Softwareentwickler hatte das ebenfalls Konsequenzen. Offensichtlich mußten sie sich intensiver mit der Frage beschäftigen, welche Aufgaben Menschen im Rahmen ihrer Arbeit zu erledigen haben, und vor allem, was sie dabei an Gegenständen verwenden. Damit kristallisierte sich die Anwendungsorientierung als eine zentrale Anforderung und Ausrichtung für die Softwareentwicklung heraus. Wir haben Anwendungsorientierung in der Form eines Leitbilds mit Entwurfsmetaphern konkretisiert (s. Kapitel 2.2.3).

261


Anwendungsorientierung: Anwendungsorientierung bei der Softwareentwicklung zielt auf folgende Merkmale der Software ab: ❑ Die Funktionalität des Softwaresystems orientiert sich an den Aufgaben im Anwendungsbereich. ❑ Die Handhabung des Softwaresystems ist benutzergerecht. ❑ Die im System festgelegten Abläufe und Schritte lassen sich je nach Anwendungssituation problemlos den tatsächlichen Erfordernissen anpassen.

2


2.4


262

Gebrauchsqualität

Die Konzentration auf die Entwicklung von Werkzeugen und Materialien auf einem elektronischen Schreibtisch hat auch zur Folge, daß es nicht mehr notwendig ist, in der Software Routinen für die Erledigung einer Aufgabe festzuschreiben. Die Benutzer bestimmen selbst, wann sie mit welchem Werkzeug welchen Gegenstand bearbeiten wollen. Eine zentrale Schwierigkeit bei der Softwareentwicklung ist damit behoben – die Algorithmisierung komplexer und situationsabhängiger Arbeitsabläufe. Wenn die Softwarekomponenten aber für die unterschiedlichen konkreten Arbeitssituationen verwendbar sein sollen, dann wird ihre Gebrauchsqualität zum entscheidenden Qualitätsmerkmal. Gebrauchsqualität (s. [Floyd & Züllighoven 97]):

Gebrauchsqualität ist für die Verwendung von interaktiver Anwendungssoftware wesentlich. Sie wird anhand äußerer Qualitätsmerkmale durch die Benutzer und andere Anwendergruppen letztlich im tatsächlichen Einsatz festgestellt. Die bewerteten Merkmale sind nach DIN 66234 Aufgabenangemessenheit, Transparenz, Steuerbarkeit, Fehlertoleranz, Selbstbeschreibungsfähigkeit, Erwartungskonformität und Fehlerrobustheit.

2


2.4


263

Strukturähnlichkeit

Die zentrale Idee des WAM-Ansatzes ist, relevante Gegenstände und Konzepte des Anwendungsbereichs als Grundlage des softwaretechnischen Modells zu nehmen. Das Ergebnis soll aber nicht nur ein anwendungsorientiertes System aus Anwendersicht sein. Wir fordern auch eine enge Korrespondenz zwischen dem anwendungsfachlichen Begriffsgebäude und der Softwarearchitektur. Strukturähnlichkeit: Strukturähnlichkeit bezieht sich im WAM-Ansatz auf das Verhältnis von Software und Anwendungsbereich: Die softwaretechnischen Komponenten eines Softwaresystems modellieren die relevanten Konzepte und Gegenstände des Anwendungsbereichs. Die Architektur des Anwendungssystems spiegelt die wesentlichen Bezüge zwischen den Konzepten und Gegenständen des Anwendungsbereichs wider.

Diese Strukturähnlichkeit bringt zwei entscheidende Vorteile: Die Anwender finden die Gegenstände ihrer Arbeit und die Begriffe ihrer Fachsprache im Anwendungssystem repräsentiert. Sie können dem-

2


2.4


264

entsprechend ihre Arbeit in gewohnter Weise organisieren. Die Entwickler können Softwarekomponenten und Anwendungskonzepte bei fachlichen und softwaretechnischen Änderungen zueinander in Beziehung setzen und somit die wechselseitigen Abhängigkeiten erkennen.

2.4.2 Der Entwicklungsprozeß Wenn Anwendungsorientierung, Gebrauchsqualität und Strukturähnlichkeit wesentliche Merkmale von Anwendungssoftware sind, dann hat dies Auswirkungen auch auf den Prozeß der Softwareentwicklung. Softwareentwicklung (s. [Floyd & Züllighoven 97]): Softwareentwicklung bezeichnet die Gesamtheit aller Aktivitäten, die zu einem Softwaresystem im Einsatz führen. Unterscheiden lassen sich ❑ produktbezogene Aktivitäten – z.B. Analyse, Entwurf und Programmierung –, deren Ergebnisse – z.B. als definierende Dokumente - direkt in das Produkt eingehen, ❑ prozeßorientierte Aktivitäten, die die produktbezogenen Aktivitäten ermöglichen und die Kooperation und Koordination im Projekt, die Produktverwaltung und die Qualitätssicherung umfassen.

2


2.4


265

Schon die Anforderungsermittlung ist von diesen Merkmalen geprägt, da hier die Orientierung an alltäglichen Arbeitssituationen der Ausgangspunkt ist: ❑ Anwendungsorientierung bedeutet für die Entwickler, die an

den einzelnen Arbeitsplätzen im Anwendungsbereich anfallenden Aufgaben zu verstehen. ❑ Um die fachlichen Aufgaben zu identifizieren und verstehen zu

können, analysieren die Entwickler an den Arbeitsplätzen den jeweiligen Umgang mit den Gegenständen der Anwendung. ❑ Das Ziel für die Modellierung ist die Rekonstruktion der Fach-

sprache der Anwender. Da das neue Anwendungssystem oft entscheidend die Arbeitssituationen, die Aufgaben und die Art ihrer Erledigung beeinflußt, und da sich der Einsatzkontext im Projekt oft verändert, ist es notwendig, nicht nur das Produkt anwendungsorientiert zu gestalten, sondern dies in einem anwendungsorientierten Entwicklungsprozeß sicherzustellen.

2

Anwendungsorientierter Entwicklungsprozeß


2.4


266

Merkmale eines anwendungsorientierten Entwicklungsprozesses: Verstärkte Einbeziehung der Benutzer über die gesamte Projektlaufzeit. Ständige Rückkopplung der Ergebnisse durch verständliche Dokumente und Prototypen. Neuorientierung der Entwickler weg von rein technischer Konstruktion am Rechner zur Interaktion mit Benutzern und anderen beteiligten Gruppen.

Um einen anwendungsorientierten Entwicklungsprozeß zu ermöglichen, sind verschiedene Voraussetzungen zu schaffen, die wir in diesem Buch detaillierter ansprechen werden: ❑ Ein evolutionäres Vorgehensmodell muß einerseits sehr flexibel

die notwendige Beteiligung der Betroffenen in den konkreten Projekten gewährleisten. Es muß also auf wechselnde Situationen anpaßbar sein. Andererseits wollen wir kontrollierbare und planbare Projekte (s. Kapitel 5.1). ❑ Anwendungsorientierte

Analyse- und Entwicklungsdokumente müssen die Voraussetzung für die aktive Mitarbeit aller Beteiligten schaffen (s. Kapitel 5.2).

❑ Die Strukturählichkeit zwischen fachlichen und technischen

Modellen muß für die Entwickler konstruktiv umsetzbar sein (s. Kapitel 3.2).

2


2.4


Häufig wird die Objektivität und Personenunabhängigkeit des Entwicklungsprozesses gefordert. Damit verbunden sind zwei Annahmen: Die erste Annahme ist, daß Anwendungssoftware die Lösung für ein vorgegebenes Problem ist, in dem Sinne, wie es in der Mathematik die Lösung zu einer Differentialgleichung gibt. Auf die grundlegende Problematik dieser Annahme sind wir in Kapitel 2.2.3 eingegangen und werden dies auch im Zusammenhang mit Vorgehensmodellen in Kapitel 5.1 diskutieren. Die zweite Annahme hängt mit der ersten zusammen. Sie geht davon aus, daß Software auf der Basis eindeutiger Beschreibungen arbeitsteilig und in einer fließbandartigen zeitlichen Reihenfolge erstellt werden kann. In Kapitel 5.1.1 werden wir auch diese Annahme detailliert kritisch betrachten. Dem stellen wir unsere Sichtweise gegenüber, daß Softwareentwicklung zunächst und grundlegend ein Kommunikations- und Lernprozeß zwischen den Beteiligten ist. Denn nur so können die Entwickler, die ja keine Anwendungsfachleute sind, das notwendige Wissen und das Verständnis für die Aufgaben im Anwendungsbereich und die Art und Weise ihrer Erledigung erwerben. Dies ist die Grundlage, um ein Anwendungssystem mit hoher Gebrauchsqualität entwickeln zu können. Doch das zukünftige System ist keine »eindeutige Lösung«

2

267 Objektivität und Personenunabhängigkeit von Softwareentwicklung

Softwareentwicklung als Kommunikations- und Lernprozeß


2.4


für ein wohldefiniertes Problem. Die einzelnen Gruppen müssen sowohl die zukünftig anstehenden Aufgaben als auch deren angemessene Unterstützung im Entwicklungsprozeß aushandeln. Nur einzelne Aspekte dieses Prozesses lassen sich in Dokumenten ausreichend detailliert beschreiben, so daß diese Dokumente für andere zur Arbeitsgrundlage werden können. Wesentliche Erfahrungen, Einsichten und Wertvorstellungen, die unabdingbar mit jedem Entwicklungsprojekt verbunden sind, können nicht in Dokumenten »objektiviert« werden. Der von uns vorgeschlagene anwendungsorientierte Entwicklungsprozeß ist in seinem Vorgehen nicht beliebig nach dem Motto »Durchwursteln, Hauptsache, wir haben darüber geredet, und die Stimmung ist gut«. Der WAM-Entwicklungsprozeß ist »dokumentgetrieben«, d.h., die Arbeit an Dokumenten steht im Vordergrund. Durch die geeignete Auswahl der Dokumente (vgl. Kapitel 5.2) soll gewährleistet werden, daß die wesentlichen fachlichen und softwaretechnischen Themen und Gesichtspunkte systematisch ins Auge gefaßt und bearbeitet werden. Anwendungsorientierte Dokumenttypen in Verbindung mit einem Leitbild und passenden Entwurfsmetaphern geben den Entwicklern die Voraussetzungen an die Hand, um das gesteckte Ziel einer hohen Gebrauchsqualität anzusteuern. Aber erst die richtige Umsetzung der

2

268

Dokumentgetriebener Entwicklungsprozeß


2.4


269

Konzepte und der Einsatz der Hilfsmittel im Entwicklungsprozeß entscheiden darüber, ob sich dieses Ziel wirklich erreichen läßt. Autor-Kritiker-Zyklus

Aus unserer Sicht ist es daher unerläßlich, den Entwicklern eine Anleitung für die Gestaltung des Entwicklungsprozesses zu geben. Das Grundprinzip, Softwareentwicklung als einen Kommunikations- und Lernprozeß zu betrachten, muß durch die ständige Rückkopplung zwischen den Beteiligten vorwärts getrieben werden. In diesem evolutionären Prozeß zwischen Bearbeitung und Rückkopplung sind prinzipiell alle Dokumente eines Projektes einbezogen. Denn es geht nicht um die sequentielle Abarbeitung einer festgelegten Folge von Meilensteindokumenten, sondern um die Verknüpfung von analysierenden, modellierenden und bewertenden Aktivitäten (s. Abbildung 2-24). Dies steht erkennbar im Widerspruch zu den Prinzipien der klassischen Wasserfall- oder Phasenmodelle (vgl. Kapitel 5.1.1), ist aber aus unserer Erfahrung eine wesentliche Voraussetzung für das Gelingen eines anwendungsorientierten Entwicklungsprojektes.

2


2.4


270

Vision Entwurf

Glossar Szenario

Bewerten

Klasse

Analysieren

Bibliothek

Prototyp

Modellieren

Abb. 2-24 Autor-Kritiker-Zyklus

2


2.4


271

Der anwendungsorientierte Entwicklungsprozeß spielt sich in unseren Projekten in der Form sogenannte Autor-Kritiker-Zyklen ab. Dabei werden die verschiedenen Dokumente und Prototypen so bearbeitet, daß ein ständiger Wechsel zwischen Analysieren, Modellieren und Bewerten stattfindet. Durch die Analyse der Aufgaben im Anwendungsbereich erhalten die Entwickler einen ersten Zugang zu den Anwendungskonzepten, den damit verbundenen Gegenständen und Abläufen. Dieses Verständnis wird als fachliches oder technisches Modell in den Dokumenten und Prototypen repräsentiert. Zur Bewertung der unterschiedlichen modellierten Aspekte kommen jetzt die »Kritiker« ins Spiel. Als solche fungieren vorrangig die Anwender und zukünftigen Benutzer, aber auch technische Experten, wie DV-Organisatoren und Netzadministratoren, die aus ihrem jeweiligen Arbeitsbereich heraus am Entwicklungsprozeß beteiligt sind. Für das Verständnis unserer Vorgehensweise ist die Einsicht wichtig, daß die jeweils identifizierten Probleme im Rückkopplungsprozeß die nachfolgenden Aktivitäten und die Auswahl der zu bearbeitenden Dokumente bestimmen. In diesem Sinne gibt es keine vordefinierte Reihenfolge von Dokumenten und Phasen. Idealerweise kann zu jedem Zeitpunkt jedes Dokument bearbeitet werden. Daß die Aktivitäten insgesamt in einem konkreten Projekt geplant und kontrolliert

2


2.4


272

werden müssen und nicht einer individuellen Beliebigkeit ausgeliefert sind, steht außer Frage. Es sollte aber klar werden, daß der grundlegende Prozeß selbst wieder von anwendungsorientierten Fragestellungen und nicht von einem softwaretechnisch zentrierten Mechanismus bestimmt wird. Nehmen wir das Pausenplanbeispiel: Ein Entwicklerteam interviewt die für die Pausenplanung zuständige Lehrperson an ihrem Arbeitsplatz (Analyse). Die Ergebnisse des Interviews werden in Szenarios und Glossareinträgen festgehalten (Modellierung). Diese Dokumente werden von dem Interviewpartner und anderen Lehrern kommentiert (Bewertung). Die Kommentare veranlassen die Entwickler, sich weiter in die Problematik der Pausenplanung einzuarbeiten und einzelne Nachinterviews zu führen. Dann schreiben sie Systemvisionen und erstellen einen ersten Handhabungsprototyp. Der Handhabungsprototyp wird in einem Workshop von Lehrern bewertet. Die Beteiligten kommen zu dem Ergebnis, daß die Arbeit der Schulsekretärin bisher im Projekt vernachlässigt worden ist. Ein Interviewtermin mit der Schulsekretärin wird vereinbart etc. Auf diese Weise kommen die Autor-Kritiker-Zyklen zustande.

2


2.4


273

Evolutionäre Systementwicklung

Die hier vertretene Sichtweise des Softwareentwicklungsprozesses paßt gut zu dem bereits vorgestellten Leitbild und seinen Entwurfsmetaphern (s. Kapitel 2.2.3). Die Diskussion der Rollenverteilung hat dort erbracht, daß die Entwickler nicht die allwissenden Spezialisten sind, die ihren Benutzern die perfekte Problemlösung liefern, sondern sie sind die Partner in einem Dialog zwischen den beteiligten Gruppen. Damit umfaßt das WAM-Konzept nicht nur eine neue Konstruktionsmethode, sondern eine dazu passende anwendungsorientierte Vorgehensweise. Diese Vorgehensweise ordnet sich ein in die allgemeinen Prinzipien einer evolutionären Systementwicklung. Evolutionäre Systementwicklung (s. [Floyd & Züllighoven 97]): Evolutionäre Systementwicklung ist eine bewußte Vorgehensweise, die sich am evolutionären Charakter von Software orientiert. Weil Software ständigen Änderungen unterliegt, orientiert sich evolutionäre Systementwicklung am sinnvollen Umgang mit Änderungen: ❑ Das wechselseitige Lernen zwischen Entwicklern und Anwendern wird in die Vorgehensweise einbezogen. ❑ Die Veränderungen im fachlichen und technischen Kontext werden systematisch berücksichtigt. ❑ Der Einsatz des Systems führt zu neuen Anforderungen, die weitere Entwicklungszyklen anstoßen.

2


2.4


274

2.4.3 Dokumentation im Entwicklungsprozeß Ehe wir auf die spezielle Thematik anwendungsorientierter Dokumente eingehen, beschäftigen wir uns mit Softwaredokumentation allgemein. Obwohl Dokumentation im Zusammenhang mit Softwareentwicklung sicherlich einer der am häufigsten verwendeten Begriffe ist, gibt es unter Softwaretechnikern keine übereinstimmende Vorstellung darüber, welche Bedeutung und Verwendung der Dokumentation bei der Erstellung von Software zukommt. Dokumentation:

Dokumentation bezeichnet zum einen den Prozeß, der die Tätigkeiten umfaßt, die nötig sind, um Dokumente zu erstellen oder zu modifizieren (»Ich muß noch die Spezifikation zu Ende schreiben«). Dokumentation bezeichnet auch das Produkt, das eine Konfiguration von Dokumenten zu einem gegebenen Zeitpunkt und für einen bestimmten Zweck darstellt (»Das sind die Dokumente, die für das Review herangezogen werden«). Ein Dokument ist ein Beleg, d.h. eine Repräsentation von einem Sachverhalt unter Verwendung von Zeichen. Im Kontext Softwareentwicklung dienen Dokumente zur Darstellung des Softwaresystems in seiner Dynamik und Statik und des Softwareprojekts. Dazu gibt es auch Dokumente auf der Meta-Ebene (z.B. Dokumente über Dokumentation).

2


2.4


Einigkeit besteht in der Softwaretechnik im wesentlichen nur darüber, daß Dokumentation wichtig aber problembelastet ist: Aus Sicht der Personen, die an der Konzeption und Weiterentwicklung eines Softwareproduktes beteiligt sind, stellt die Dokumentation eine Störgröße dar. Für die Entwickler in der Rolle potentieller Autoren ist Dokumentation eine lästige und zusätzliche Aufgabe, die von der eigentlichen Entwicklung abhält. Für die Benutzer führt sie zu Frustration im Umgang mit Prototypen und Anwendungssystemen, wenn die Dokumentation nicht (adäquat) vorhanden ist. Traditionelle Meilensteindokumente mit ihren vorgegebenen Erstellungszeitpunkten haben sich als zu starr für die Softwareentwicklung herausgestellt. Doch ohne systematische Dokumentation kann Software nicht professionell entwickelt werden. Projektbegleitende Dokumentation kostet viel Zeit, was nicht immer gerechtfertigt ist. Wenn entworfene Teilsysteme schon dokumentiert sind, aber vom Anwender nicht akzeptiert werden, ist auf den ersten Blick unnötige Arbeit in die Dokumentation investiert worden. Die im Laufe eines Softwareprojektes entstandenen Dokumente weisen eine hohe inhaltliche wie strukturelle Komplexität auf. Während der Softwareentwicklung ist es daher schwierig zu beurteilen, ob durch die vorhandenen Dokumente die unterschiedlichen Modelle des Anwendungsbereiches so vollständig und konsistent beschrieben sind,

2

275 Dokumentationsprobleme


2.4


276

daß sie nach Projektende noch verstanden werden können. Dabei neigen Entwickler zu Fehleinschätzungen. Die Folge ist, daß wesentliche Entwicklungsentscheidungen und -ergebnisse nicht mehr rekonstruiert und deshalb auch nicht in der Nachdokumentation festgehalten werden können. Anwendungsorientierte Entwicklungsdokumente

Die Probleme, die wir gerade geschildert haben, gelten für die Dokumentation allgemein. Nun haben wir in den vorausgegangenen Abschnitten die Bedeutung der Anwendungsorientierung für unseren Ansatz hervorgehoben. Mit der Forderung, die wesentlichen Entwicklungsdokumente zum gemeinsamen Arbeitsgegenstand von Entwicklern und Anwendern zu machen, kommt ein weiteres zu lösendes Problem hinzu. Vergegenwärtigen wir uns zunächst einen wesentlichen Gesichtspunkt der Anwendungsorientierung – die Herausbildung einer gemeinsamen Projektkultur. Dies bedeutet vor allem, daß die beteiligten Gruppen eine »gemeinsame Sprache« sprechen. Kann dieses Ziel erreicht werden, dann verstehen die Entwickler die jeweiligen Aufgaben und Probleme im Anwendungsbereich, und die Anwender können einschätzen, wie und in welchem Umfang sie vom zukünftigen Anwendungssystem unterstützt werden.

2

Gemeinsame Projektkultur


2.4


Diese Projektkultur kommt aber nicht von selbst zustande. Wenn sie überhaupt je etabliert werden kann, dann nur über die schon angesprochenen Kommunikations- und Lernprozesse. Die idealen Lernziele ließen sich so formulieren: Die Entwickler einer Softwarekomponente kennen die entsprechenden Aufgaben und Tätigkeiten im Anwendungsbereich so genau, daß sie die fachlichen Auswirkungen jeder technischen Entwurfsentscheidung abschätzen und zur Diskussion stellen können. Die beteiligten Anwender haben ein so präzises Bild von den Möglichkeiten des sich entwickelnden Softwaresystems, daß sie ihre fachlichen Anforderungen bereits mit Blick auf die technischen Möglichkeiten artikulieren können. Um in ausreichende Nähe dieses Ideals zu kommen, werden verschiedene anwendungsorientierte Entwicklungsdokumente eingesetzt. Sie werden zum Gegenstand gemeinsamer Arbeit, d.h., sie werden in den beschriebenen Autor-Kritiker-Zyklen erstellt, bewertet und revidiert. Dazu müssen diese Dokumente aber für alle Beteiligten verständlich sein, da sie sonst keine gemeinsame Arbeitsgrundlage bilden. Hier konkretisieren wir das Konzept der Anwendungsorientierung auf die im Prozeß verwendeten Entwicklungsdokumente. Alle Entwicklungsdokumente, die in der Zusammenarbeit von Anwendern und Entwicklern verwendet werden, müssen in der Sprache des Anwendungsbereichs verfaßt sein. Dabei stellen die jeweiligen Doku-

2

277

Anwendungsorientierte Entwicklungsdokumente


2.4


278

mente keinen Wert an sich dar, sondern sind die Grundlage für die gemeinsame Bearbeitung und die damit verbundenen Kommunikations- und Lernprozesse. Anwendungsorientierte Entwicklungsdokumente: Anwendungsorientierte Dokumente sind gemeinsame Arbeitsgegenstände für Entwickler und Personen aus dem Anwendungsbereich. Die dabei verwendeten Darstellungsmittel, Konzepte und Begriffe orientieren sich an der Fachsprache des Anwendungsbereichs. Anwendungsorientierte Entwicklungsdokumente modellieren die fachlichen Aufgaben, Gegenstände und Konzepte in einer für alle Beteiligten verständlichen Art und Weise. Sie werden in Autor-Kritiker-Zyklen erstellt, bewertet und überarbeitet. Das primäre Ziel der Arbeit an den Dokumenten sind die Kommunikationsund Lernprozesse. Um das Ziel zu erreichen, müssen die Dokumente des Anwendungsbereichs, das Anwendungssystem und den Entwicklungsprozeß in adäquater Form darstellen.

Die Arbeit mit anwendungsorientierten Dokumenten ist keine Beschäftigungstherapie. Sie dient letztlich dem Ziel, unter optimaler Nutzung der verfügbaren personellen und materiellen Ressourcen ein Anwen-

2


2.4


dungssystem mit maximaler Gebrauchsqualität zu erstellen. Dazu muß die Dokumentation verschiedene Bereiche von Softwareentwicklung repräsentieren. Entsprechend unserer Vorstellung von Softwareentwicklung sind das die produktbezogenen und die entwicklungsprozeßbezogenen Bereiche. Bei den produktbezogenen Bereichen unterscheiden wir weiter die Modellierung des vorhandenen Anwendungsbereichs und des zu entwickelnden Anwendungssystems. Alle Dokumente, die zu einem eingesetzten Anwendungssystem bestehen, werden unter dem Aspekt der konstruktiven Qualitätssicherung erstellt. Das heißt, daß bereits bei der Ausarbeitung eines Dokuments seine Qualität konstruktiv gesichert und im Autor-KritikerZyklus geprüft wird. Wie das jeweils gewünschte Qualitätsniveau über Referenzlinien festgehalten und damit zum Gegenstand der Projektplanung gemacht werden kann, beschreiben wir in Kapitel 5.1.3 Diese Form der konstruktiven Qualitätssicherung ist auch im Zusammenhang mit der ISO9000-Zertifizierung von großer Bedeutung.

2

279

Konstruktive Qualitätssicherung


2.4


280

2.4.4 Dokumente des WAM-Ansatzes Wir geben im folgenden einen Überblick über die Dokumente des WAM-Ansatzes. Da es sich bei der Beschreibung nicht um konkrete Dokumente, sondern um die dahinterstehenden Konzepte und ihr Schema handelt, sprechen wir hier von Dokumenttypen im objektorientierten Sinne.

Dokumenttyp: Ein Dokumenttyp definiert eine Menge gleichartiger Dokumente im objektorientierten Sinne: Die Beschreibung eines Dokumenttyps legt fest, wie sich Exemplare eines solchen Typs verhalten. Wie bei jeder Typdefinition kommt es nicht auf die innere Struktur der einzelnen Dokumente an, sondern vor allem auf die Umgangsformen, die mit ihnen möglich und sinnvoll sind. Soweit wir Strukturhinweise geben, sind diese als exemplarisch zu verstehen.

Viele Dokumenttypen fallen unter die Kategorie der bisher diskutierten anwendungsorientierten Dokumente. Darüber hinaus gibt es auch im WAM-Ansatz die Dokumenttypen, die softwaretechnische oder

2


2.4


281

Verwaltungsaspekte repräsentieren. Solche Dokumenttypen werden in diesem Buch nur am Rande besprochen, da sich der WAM-Ansatz in diesem Punkt nicht von anderen bewährten Entwicklungsmethoden unterscheidet. Im Einzelfall geben wir entsprechende Literaturverweise. Die von uns vorgeschlagenen Dokumenttypen sind als fester Bestandteil der WAM-Methode und der damit verbundenen evolutionären Vorgehensweise zu sehen. Daher ist es nicht sinnvoll, sie als losgelöste Dokumenttypen zu betrachten, die beliebig ausgewählt und isoliert eingesetzt werden können. Dies heißt andererseits nicht, daß sie ausschließlich in diesem methodischen Rahmen eingesetzt werden müssen. Allerdings verlangt ihre Übertragung in andere Kontexte eine sorgfältige Anpassung und Handhabung. Viele der hier vorgestellten Dokumenttypen tauchen in der Literatur in ähnlicher Form aber mit anderen Namen auf. Umgekehrt werden auch Namen wie »Szenario« für ganz unterschiedliche Dokumenttypen verwendet. Wir verzichten hier auf eine Diskussion im Detail und geben nur gelegentliche Hinweise. Hinter den Vorschlägen zu Dokumenttypen steht auch nicht der Anspruch, daß alles neu und unvergleichlich sei. Uns kommt es vielmehr darauf an, den jeweils neuen Akzent oder die neue Herangehensweise in den Vordergrund zu stellen, um so den angestrebten »Umdenkprozeß« zu fördern.

2


2.4


282

In diesem Sinne ein Wort der Vorsicht: Wer mit traditionellen Dokumenttypen, sogenannten Meilensteindokumenten, vertraut ist, wird dazu neigen, die in diesem Buch beschriebenen Dokumenttypen auf diesen Hintergrund zu übertragen, um dann zu dem Schluß zu kommen, daß hier nichts »wirklich« Neues vorgeschlagen wird. Dies führt dann zu der Konsequenz, die bisherige Analyse-, Entwurfs- und Dokumentationspraxis beizubehalten. Darin liegt eine nicht zu unterschätzende Gefahr. Vielfach wird übersehen, daß eine Methode nur aus dem Zusammenspiel einer Sichtweise mit einem Einsatzbereich und den eingesetzten Verfahren, Techniken und Hilfsmitteln zustande kommt. In dieser Hinsicht unterscheiden sich die hier vorgestellten Dokumenttypen erheblich von konventionellen, da sie passend zur vorgestellten Sichtweise und den unterschiedlichen Anwendungssituationen in verschiedenen Projekten entwickelt wurden. Wir stellen immer wieder fest, daß die Arbeit mit unseren Dokumenttypen für die meisten Entwickler am Anfang gewöhnungsbedürftig ist, daß aber die Projekterfolge zu einem wesentlichen Teil auf diese Form der Dokumentation zurückgehen.

2


2.4


283

Zusammenhang der WAM-Dokumenttypen

Der WAM-Ansatz ist, wie wir in der Einleitung zu diesem Buch festgestellt haben, eigentlich eine Methode zweiter Ordnung. Das soll nicht erschrecken oder sehr theoretisch klingen, sondern besagt nur, daß die allgemeinen Vorgaben und Leitlinien zusammen mit den Techniken, Verfahren und Darstellungsmitteln immer auf die jeweilige Projektsituation angepaßt werden müssen. Diese Konkretisierung können wir natürlich nicht in einem Buch leisten und damit auch nicht für die verschiedenen Dokumenttypen. Trotzdem halten wir es für sehr nützlich, in Kapitel 5.2 immer wieder konkrete Projekterfahrungen und Beispiele vorzustellen und zu diskutieren. In diesem Abschnitt ist uns zunächst wichtig darzustellen, daß die einzelnen Dokumenttypen nicht isoliert betrachtet werden dürfen, sondern in inhaltlichen Bezügen stehen.

2


2.4


284

Abb. 2-25 Der Zusammenhang der Dokumenttypen Projektdokumente

Einflußgrößen

Leitbild

Kooperationsbilder

Szenarios

Auftrag

WozuTabellen

Glossar

Protokolle

Visionen Ausbaustufen Anwendungswissen

Entwicklungsdokumente

Entwürfe

Kernsystem Prototypen

Anwendergruppen

Drehbücher

Ermittelte Anforderungen

Pilotsystem

Referenzlinien

Klassen Bibliotheken

Projektetappen

Rahmenwerke

Pilotorganisationen

Dokumentationsrichtlinien


Programmierrichtlinien

Entwurfsmuster

Dokumentationsdokumente

2


2.4


285

Die Abbildung 2-25 ist in vier Bereiche gegliedert, von denen drei Abstraktionen über die vorgeschlagenen Dokumenttypen im objektorientierten Sinne darstellen: ❑ Auf der linken Seite stehen die Einflußgrößen, die entscheidend

die jeweilige Sicht auf den Anwendungsbereich und das Softwaresystem prägen. Einflußgrößen sind natürlich keine Dokumenttypen, aber sie beeinflussen die Dokumente in ihrem Inhalt und Entstehungsprozeß.

Zusammenhang der Dokumenttypen

❑ In der Mitte stehen die Entwicklungsdokumente, die das sich

entwickelnde Anwendungssystem in seinen verschiedenen Aspekten beschreiben. Sie sind vorrangiger Gegenstand der Autor-Kritiker-Zyklen. ❑ Auf der rechten Seite stehen die Projektdokumente, die der Darstellung, Planung und Kontrolle des Softwareprojekts in der zeitlichen Entwicklung dienen. Auch sie werden regelmäßig revidiert. ❑ Am unteren Rand sind die Dokumente zur Dokumenterstel-

lung, also die »Metadokumente«, dargestellt, die beschreiben, nach welchen Konzepten und Richtlinien die Entwicklungsdokumente und die Dokumente zur Projektsteuerung zu erstellen sind.

2


2.4


286

Für jeden der vier Bereiche haben wir beispielhaft die wesentlichen bisher erarbeiteten Dokumenttypen angegeben. Im folgenden werden wir die einzelnen Bereiche im Überblick so beschreiben, daß die Zusammenhänge zwischen den Bereichen und den darin zusammengefaßten Dokumenten klar werden. Eine detaillierte Vorstellung der einzelnen Dokumenttypen findet sich in Kapitel 5.2. Die Einflußgrößen

Den Rahmen oder den Anschluß der Dokumenttypen an den jeweiligen Anwendungsbereich bilden die Einflußgrößen. Dabei ist das gewählte Leitbild (s. Kapitel 2.2) mit seinen Entwurfsmetaphern von zentraler methodischer Bedeutung. Da ein Leitbild implizit oder explizit in den Köpfen des Entwicklerteams und des Entwicklermanagements eine Vorstellung davon erzeugt, wie das spätere System zu gestalten ist, sollte es bei jeder Entwicklung eines Anwendungssystems explizit gemacht werden. Dies gilt unabhängig davon, ob die verwendete Konstruktionsmethode objektorientiert oder traditionell ist. Das gewählte Leitbild hat Konsequenzen für das fachliche Anwendungswissen der Entwickler. Wenn ein Arbeitsplatz für eigenverantwortliche und qualifizierte Sacharbeit in einer Organisation analysiert

2

Leitbild

Anwendungswissen


2.4


und modelliert werden soll, dann müssen die Entwickler diesen Arbeitsplatz in gewissem Umfang kennen oder kennen lernen. Dies haben wir generell unter dem Begriff Anwendungsorientierung beschrieben. Hier ist wichtig, daß Anwendungsorientierung ein anwendungsfachliches Verständnis der Entwickler erfordert. Damit können wir dieses Konzept nicht vernachlässigen. Das fachliche Know-how der Entwickler entscheidend darüber, was bei Analyse und Entwurf überhaupt »sichtbar« wird. Anders formuliert, wer nichts von der Sache versteht, kann bei der Bestandsaufnahme im Anwendungsbereich auch nur begrenzt fachliche Fragen stellen und Antworten einschätzen. Entwickler, denen es an einem »Gefühl« für die Aufgaben im Anwendungsbereich mangelt, können letztlich eine Arbeitssituation nicht adäquat modellieren. Auch hier gilt wieder, daß Systementwicklung ein Lernprozeß für alle Beteiligten ist, der um so aufwendiger und sorgfältiger geplant und gefördert werden muß, je größer die gegenseitigen Wissens- und Erfahrungsdefizite sind. Arbeitskreise, informelle Meetings oder die feste Mitarbeit von Anwendern im eigentlichen Projektteam sind mögliche Organisationsformen des gemeinsamen Projekts aus Entwicklern und Anwendergruppen. Aus diesem Kreis werden die Gesprächspartner für die fachliche Bestandsaufnahme ausgesucht. Hier werden die entsprechenden

2

287

Anwendergruppen


2.4


anwendungsorientierten Dokumente und die Prototypen ausgewertet und fachliche und strategische Entscheidungen zumindest vorbereitet. Es hat sich als sehr wichtig erwiesen, in den Arbeitsgruppen nicht nur über die anwendungsfachlichen Fragen und das sich entwickelnde Anwendungssystem zu sprechen, sondern auch die verwendete Methode selbst zum Thema zu machen. So wird den Beteiligten klar, welche Rolle sie jeweils im Rahmen der gewählten Vorgehensweise spielen und welchen tatsächlichen Einfluß sie auf die Gestaltung des Systems haben. Zudem fällt es den beteiligten Anwendern mittelfristig viel leichter, sich ein stimmiges Bild vom Anwendungssystem zu machen, das auch zu den Vorstellungen der Entwickler paßt. Die Pilotorganisationen sind für größere Entwicklungsvorhaben mit vielen beteiligten Anwenderorganisationen von großer Bedeutung. Sie sind diejenigen Organisationen, bei denen das entstehende System zuerst als wirkliches Produkt im täglichen Arbeitsprozeß eingesetzt wird. Durch ihre intensive vorherige Arbeit mit den Prototypen haben sie sich meist für die Auswahl als Pilotorganisation ausgewiesen. Das im produktiven Betrieb eingesetzte System kann ein weitgehend funktionstüchtiger Prototyp sein, der dann Pilotsystem genannt wird (s. Kapitel 5.2.4); es kann aber auch ein Kernsystem in einer seiner Ausbaustufen sein (s. Kapitel 5.1.3).

2

288

Pilotorganisationen


2.4


289

Pilotorganisationen haben großen Einfluß auf die Weiterentwicklung des Pilotsystems oder weiterer Prototypen (vgl. [Kieback et al. 92]) und stellen daher auch relevante Anforderungen an die Entwicklung des Anwendungssystems. Als Basis der erfolgreichen Zusammenarbeit mit den Pilotorganisationen ist es besonders wichtig, daß die Beteiligten einen guten Einblick in die verwendete Methode haben. Dadurch können sie in der Zusammenarbeit mit den Entwicklern gezielte Anregungen geben und sie werden, wie sich in Projekten gezeigt hat, auch besser mit den Schwächen und Fehlern eines Pilotoder Anwendungssystems umgehen können. Denn gerade in der Arbeit mit Pilotsystemen ist die Kenntnis des jeweiligen Stellenwerts von Bedeutung. Erfahrungen zeigen, daß Anwender ansonsten sehr unwillig auf Systemfehler reagieren, da diese ihre Arbeit unterbrechen oder gar partiell vergeblich machen können. Die Entwicklungsdokumente

Die Entwicklungsdokumente repräsentieren das Anwendungssystem bei seiner Erst- und Weiterentwicklung. Sie haben damit einen anderen Stellenwert als die Benutzungsdokumente (z.B. Handbücher, Hilfetexte), die wir in diesem Buch nicht betrachten.

2


2.4


In der historischen Entwicklung des WAM-Ansatzes waren Szenarios, Glossareinträge und Systemvisionen der »Keim« der anwendungsorientierten Dokumenttypen. Wir skizzieren sie kurz im Vorgriff auf Kapitel 5.2, um einen Eindruck von den damit verbundenen Konzepten zu geben:

290 Szenario, Glossar, Systemvision

❑ Szenarios beschreiben die aktuelle Arbeitssituation. Dabei liegt

das Augenmerk auf den Aufgaben im Anwendungsbereich und der Art und Weise, wie die jeweiligen Aufgaben unter Verwendung von Arbeitsmitteln und Arbeitsgegenständen erledigt werden. ❑ Ein Glossar definiert und rekonstruiert das Begriffsgebäude

der jeweiligen Fachsprache. ❑ Systemvisionen stehen am Übergang zwischen der Analyse des

Anwendungsbereichs und der Konstruktion des zukünftigen Systems. Auf der Basis der Szenarios antizipieren sie zukünftige Arbeitssituationen. Entwicklungsdokumente lassen sich unter verschiedenen Gesichtspunkten unterteilen. Da sind die Dokumenttypen (z.B. Szenarios, Kooperationsbilder, Wozu-Tabellen und große Teile des Glossars), die im wesentlichen den Anwendungsbereich in seinem Ist-Zustand

2

Einteilung von Entwicklungsdokumenten


2.4


291

beschreiben, d.h. so, wie es sich jeweils zum Zeitpunkt der Bestandsaufnahme eines Projektes darstellt. Wir weisen schon hier auf die große Bedeutung dieser Dokumente für den Entwurf des zukünftigen Systems hin (s. auch Kapitel 2.5.1 und 5.2). Dem gegenüber stehen die Dokumenttypen (wie Systemvisionen, Entwürfe und andere eher technisch orientierte Dokumente), die das Anwendungssystem in seinen verschiedenen (zukünftigen) Entwicklungsstadien vom Entwurf bis zum ausgelieferten Kernsystem und seinen Ausbaustufen beschreiben. Eher modelltheoretisch von Interesse ist die Unterscheidung in Statik und Dynamik. So wie wir für (objektorientierte) Programme die dynamischen Eigenschaften zur Laufzeit und die statische Struktur eines Systems durch z.B. Interaktions- und Klassendiagramme festhalten, so konzentrieren wir uns auch bei den Dokumenttypen auf eine der beiden Aspekte. Dabei zeigt sich, daß wir ein viel umfangreicheres Repertoire an anwendungsorientierten Entwicklungsdokumenten zur Beschreibung der Dynamik (z.B. Szenarios, Systemvisionen, WozuTabellen) als zur Beschreibung von Statik (z.B. Glossar, einige Formen von Kooperationsbildern) haben. Bei den technischen Entwicklungsdokumenten hält sich dies eher die Waage. Ein wesentlicher Gesichtspunkt ist die Einteilung der Dokumente nach ihrer Stellung im Kommunikationsprozeß. Dabei sind auf den ersten Blick die anwendungsorientierten Dokumenttypen (z.B. Szena-

2


2.4


292

rios, Glossar, Kooperationsbilder und Prototypen) wichtiger als diejenigen Dokumenttypen, die sich wie Klassenbeschreibungen und Rahmenwerke vorrangig an die Entwickler richten. Doch gewinnen mit der Forderung nach Strukturähnlichkeit die eher technisch orientierten Dokumenttypen eine große Bedeutung. Nicht von ungefähr widmen wir den Hauptteil dieses Konstruktionshandbuchs den Prinzipien und Konstruktionen der Modelle, die in diesen Dokumenten beschrieben werden. Mit der wachsenden Bedeutung der Unterstützung von kooperativer Arbeit entsteht ein Bedarf nach solchen Dokumenttypen, die sich besonders für Softwareentwicklung in diesem Bereich eignen. Im Rahmen des WAM-Ansatzes beschäftigen wir uns erst seit kurzer Zeit mit der Entwicklung von Anwendungssoftware für kooperative Arbeit. Das entsprechende Konstruktionskapitel 4.1 faßt die bisherigen konzeptionellen und technischen Ansätze zusammen. Allerdings haben wir schon umfangreichere Erfahrung im Einsatz geeigneter Dokumenttypen (wie Kooperationsbilder und Wozu-Tabellen) gesammelt, die wir in Kapitel 5.2.5 und 5.2.6 vorstellen.

2


2.4


293

Projektdokumente

Ein Projekt muß auch in seinem Prozeß und Ablauf dokumentiert werden, damit es geplant, gesteuert und in seiner Vorgehensweise bewertet werden kann. Dieses Thema wird in der objektorientierten Literatur bisher entweder vernachlässigt oder am Rande behandelt. Die Arbeiten zu diesem Thema sind bis auf wenige Ausnahmen (vgl. [Booch 95, Goldberg & Rubin 95]) sehr vage oder orientieren sich an traditionellen Projektmanagementkonzepten. Aus diesem Grund haben wir der Frage der Projektsteuerung ein eigenes Kapitel gewidmet (s. Kapitel 5.1.2). Hier wollen wir wieder nur einen allgemeinen Überblick über die Dokumenttypen geben, die für dieses Thema relevant sind. Ein Projekt oder Teilprojekt sollte explizit initialisiert werden. Auch für sogenannte In-house-Entwicklungen sollte es einen Projektauftrag oder mit mehr Details einen Vertrag geben, der den Beschluß enthält, ein Projekt durchzuführen. Entsprechend gibt es faktisch immer eine verantwortliche Person oder ein entscheidendes Gremium. Für die Handlungssicherheit in einem Projekt ist es wesentlich, explizit zu wissen, wer für ein Projekt letztlich verantwortlich ist. Mit dem Auftrag sind auch Entscheidungsbefugnisse verbunden. Wichtig ist, daß in den Projekten Klarheit darüber herrscht, wer über Mittel, Per-

2

Projektauftrag


2.4


sonal, Entwurfsalternativen und die Akzeptanz des Systems entscheidet. Der Auftrag sollte dokumentieren, welches System von wem unter Einsatz welcher Mittel entwickelt werden soll. Dabei fordern die Prinzipien der evolutionären Systementwicklung, den Auftrag als eine Absichtserklärung und nicht als eine vollständige Projektspezifikation zu formulieren. Im Mittelpunkt steht das Ziel und die »Vision« und nicht eine Beschreibung der genauen Merkmale eines Systems und dem Wie ihrer Umsetzung. Wir sagen dies aufgrund der Erfahrung, daß zu Beginn vieler Projekte detaillierte Festlegungen zu technischen Aspekten gemacht werden, die im anschließenden Projektverlauf nur schwer mit den sich klärenden Anforderungen zur Deckung gebracht werden können. In einem Dokumenttyp von der Art ermittelte Anforderung werden, bezogen auf das System, die Vorstellungen, Merkmale und Wünsche beschrieben, die sich im Projektverlauf ergeben. Die ermittelten Anforderungen sind eine Art Tagebuch über die Diskussionsergebnisse, die sich auf Systemcharakteristika beziehen. Systemcharakteristika können sowohl fachliche als auch technische Aspekte umfassen. Im Gegensatz zum Vertrag werden die ermittelten Anforderungen kontinuierlich fortgeschrieben, um die Historie der sich verändernden Anforderungen zu dokumentieren.

2

294

Ermittelte Anforderungen


2.4


Für die tägliche Arbeit im Projekt sind die eigentlichen Dokumente der Projektsteuerung wichtig, in denen die sogenannten Referenzlinien und die Projektetappen festgelegt sind. Auf diese Art der Projektsteuerung über zeitliche und qualitative Richtlinien gehen wir in Kapitel 5.1.3 ein.

295 Dokumente der Projektsteuerung

Dokumenttypen zur Dokumentation

Kein Projekt wird von sich aus die verschiedenen Dokumente in einer einheitlichen und geordneten Form erstellen. Dazu sind Anleitungen nötig, in denen der Dokumentationsprozeß und das sich entwickelnde gemeinsame Verständnis über die verschiedenen eingesetzten Dokumenttypen beschrieben sind. Diese Beschreibungen finden sich in Dokumenttypen zur Dokumentation. Für alle diese »Metadokumenttypen« gilt die Regel: Je knapper sie im Umfang sind und je praxisgerechter sie geschrieben sind, desto besser. In diesem Sinne versteht es sich von selbst, daß immer nur die aktuelle Version eines solchen Dokumenttyps im Umlauf sein sollte. In den Dokumentationsrichtlinien werden die einzelnen Dokumentationstypen beschrieben. Dies bezieht sich auf die äußere Form, den strukturellen Aufbau und die inhaltlichen Kriterien, die zu berücksichtigen sind. Dazu kommen Verfahrensvorschriften und Hin-

2

Dokumentationsrichtinien


2.4


weise über den Dokumentationsprozeß selbst, d.h. Hinweise über die Art und Weise, wie diese Dokumenttypen erstellt werden sollen. Als allgemeines Beispiel kann Kapitel 5.2 gelten. Auch in vielen konventionellen Projekten gibt es Gestaltungsrichtlinien für den Entwurf von interaktiven Systemen und ihrer Benutzungsschnittstellen wie z.B. CUA von IBM. In Projekten haben wir festgestellt, daß sich Gestaltungsrichtlinien sehr gut und knapp formulieren lassen, wenn ein Leitbild mit seinen Entwurfsmetaphern Teil der Entwicklungskultur eines Unternehmens ist. Dann wird auch deutlich, daß Gestaltungsrichtlinien nicht nur das Layout der Oberfläche, sondern grundsätzliche software-ergonomische Aspekte interaktiver Systeme umfassen. Bei der professionellen Entwicklung interaktiver Systeme ist zumindest die Bedeutung dieses Themas, das wir in diesem Buch nicht weiter vertiefen wollen, erkannt worden, auch wenn erst wenige Firmen dazu ausreichend qualifiziertes Personal zur Verfügung haben. Verbreitet, doch hier nicht weiter behandelt, sind Programmierrichtlinien, ohne die heute kein größeres Softwareprojekt auf die Dauer arbeiten wird. Dagegen steht die Beschreibung von Entwurfsmustern im Mittelpunkt dieses Buches (s. Kapitel 3.2).

2

296


Programmierrichtlinien und Entwurfsmuster


2.5

2.5

Softwareentwicklung als Modellbildung

297


In Kapitel 2.4 haben wir die Anwendungsorientierung als ein zentrales Merkmal des WAM-Ansatzes hervorgehoben. Dabei steht die Zusammenarbeit und der wechselseitige Lernprozeß zwischen Entwicklern und den Anwendern im Vordergrund. In diesem Abschnitt betrachten wir Anwendungsentwicklung aus softwaretechnischer Sicht. Die dabei hervortretenden Merkmale sollen uns helfen, die Aufgaben in unserem eigenen Fachgebiet, Softwaretechnik, zu erledigen. Um bereits hier praxisrelevante Probleme zu demonstrieren, verwenden wir neben unserem Pausenplanbeispiel des öfteren Beispiele aus dem Kontext unserer Kooperationsprojekte im Bankenbereich. Aus Sicht der Softwaretechnik ist Softwareentwicklung vorrangig ein Modellierungsprozeß, denn im Projektverlauf werden unterschiedliche ausführbare und nicht-ausführbare Modelle erstellt. Im Rahmen des WAM-Ansatzes bedeutet objektorientierte Softwareentwicklung die Rekonstruktion der fachlichen Begriffe des Anwendungsbereichs. Das setzt trivialerweise voraus, daß diese Begriffe und die dahinterstehenden Konzepte vom Entwickler verstanden werden. Für unser Thema heißt dies, daß der Entwickler ein Modell des Anwendungsbereichs anhand der fachlichen Gegenstände, Begriffe und Beziehungen erstellt. Um ein solches Modell in seinem Umfang

2

Federführung: Dirk Bäumer Ko-Autor: Heinz Züllighoven



2.5


298

eingrenzen zu können, muß in einem Abstimmungsprozeß zwischen den beteiligten Gruppen zumindest der fachliche Rahmen des zu entwikkelnden Softwaresystems festgelegt sein. Wir können zwei scheinbar widersprüchliche Zwischenergebnisse festhalten: ❑ Zur Entwicklung eines Anwendungssystems ist ein fachliches

Modell des entsprechenden Anwendungsbereichs erforderlich. ❑ Zur Modellierung des Anwendungsbereichs muß der fachliche

Rahmen des zukünftigen Anwendungssystems bekannt sein. Die im Modell des Anwendungsbereichs verwendeten Begriffe werden zueinander in Beziehung gesetzt. Das Objekt-Metamodell (s. Kapitel 2.1) stellt prinzipiell zwei Beziehungsarten zur Verfügung (s. Abbildung 2-26 und [Odell 92]): Zunächst werden die modellierten Gegenstände des Anwendungsbereichs »auf den Begriff« gebracht. Dann werden Gemeinsamkeiten, die über verschiedene Begriffe hinweg existieren, durch Generalisierung in einem allgemeineren Konzept, dem Oberbegriff, zusammengefaßt. Die durch Generalisierung und Spezialisierung entstehende Struktur von Ober- und Unterbegriffen bildet eine Begriffshierarchie.

2

Generalisierung, Spezialisierung


2.5


299

Sie drückt, wie es in der Literatur oft heißt, eine »ist-ein«-Beziehung aus. Abb. 2-26

Plan

Beispiel für Generalisierung ist-ein

und Komposition

Pausenplan benutzt

Lehrkörper

Pause Lehrer

Zeitraum

Den Mechanismus, Gegenstände aus anderen Gegenständen zusammenzusetzen, diese zu verwalten oder deren Dienstleistungen zu nutzen, bezeichnen wir als Komposition. Die Komposition als Beziehung zwischen Gegenständen wird auf der Modellierungsebene zwischen

2

Komposition


2.5


den Begriffen beibehalten, da das Objekt-Metamodell natürlich diese grundlegende Benutzt-Beziehung anbietet. Am Rande sei hier bemerkt, daß diese beiden Beziehungsformen im weiteren ergänzt werden müssen, da sich auf diese Weise verschiedene Sichten und Arbeitskontexte in einem Anwendungsbereich nicht elegant modellieren lassen. Wir haben dieses Problem mit dem Rollenkonzept gelöst, das wir in Kapitel 3.3.4 beschreiben. Doch hier sind die genannten Beziehungsarten für ein fachliches Modell des Anwendungsbereichs ausreichend. Auf der Grundlage des Modells des Anwendungsbereichs wird ein Modell des Anwendungssystems erstellt. Für dieses Modell des Anwendungssystems haben wir in Kapitel 2.4 eine hohe Strukturähnlichkeit gefordert. Entsprechend übertragen wir die modellierte fachliche Begriffshierarchie in ein ähnliches Klassenmodell. Doch schon eine erste Sichtung zeigt, daß das Modell des Anwendungssystems nicht nur Klassen und Operationen enthält, die bereits im Begriffsmodell modelliert worden sind, sondern auch solche, die durch die verwendete Technik motiviert sind.

300

Modell des Anwendungssystems

Die Analyse des Anwendungsbereichs Schule hat ergeben, daß für die zu unterstützende Aufgabe der Pausenplanung dem Gegenstand Pau-

2


2.5


301

senplan eine besondere Bedeutung zukommt. Typische fachliche Umgangsformen mit dem Pausenplan sind z.B.: ❑ einen Lehrer einer Pause zuordnen, ❑ prüfen, ob ein Lehrer eine Pause beaufsichtigen kann, ❑ prüfen, ob alle Pausen beaufsichtigt sind, ❑ alle nicht beaufsichtigten Pausen markieren.

Ein Softwareentwickler, der die Arbeit mit einem Pausenplan verstanden hat, ist auf der Basis unseres Leitbilds und seiner Entwurfsmetaphern schon in der Lage, aus dem fachlichen Modell ein strukturähnliches Klassenmodell zu erstellen. Darin wird es dann z.B. eine Materialklasse Pausenplan mit Operationen wie LehrerZuordnen, ExistierenAufsichtskonflikte, AllePausenBeaufsichtigt und GibAufsichtsort geben. Für ein lauffähiges Anwendungssystem reichen diese rein fachlich motivierten Operationen aber nicht aus. Dort soll ein Pausenplan auf den elektronischen Schreibtisch, d.h. den Arbeitsplatz des Pausenplaners, gelegt werden können (vgl. Kapitel 2.2.3). Um den Pausenplan auf dem Schreibtisch als Material zu repräsentieren, will der Entwickler ein Piktogramm (Icon) verwenden. Dazu muß er im System die Verbindung zwischen dem fachlichen Material Pausenplan und seiner

2


2.5


302

grafischen Repräsentation herstellen. Eine einfache Lösung ist die Erweiterung der Klassenschnittstelle von Pausenplan um die Operation gibPiktogramm. In der Diskussion mit dem Pausenplanersteller erfährt der Entwickler, daß die Zuordnung von Lehrern zu Pausen abhängig von der beruflichen Position ist. Je nachdem, ob die betreffende Lehrperson Volontär, Referendar oder fertig ausgebildet ist, wird sie unterschiedlich für die Pausenaufsicht berücksichtigt. Zudem erzählt der Pausenplanersteller, daß sich das Zuordnungsverfahren aufgrund der Beschlüsse des Lehrkörpers in den letzten Jahren mehrfach geändert hat. Daraufhin entscheidet sich der Entwickler, die unterschiedlichen Algorithmen nicht in der Klasse Pausenplan direkt zu implementieren, sondern dazu ein Strategiemuster (vgl. [Gamma et al. 96]) zu benutzen. Dabei wählt er die Implementatierungsvariante, einem Pausenplan-Objekt ein Strategiemuster-Objekt beim Aufruf der Operation zuordnen über einen zusätzlichen Parameter mitzugeben. Bei der Modellierung eines Anwendungssystems sind außer den anwendungsfachlichen noch weitere Gesichtspunkte zu berücksichtigen. Diese beeinflussen die Struktur des Anwendungssystems und

2

Kontexte der Softwareentwicklung


2.5


303

seine Funktionalität. Die Gesichtspunkte kommen aus unterschiedlichen Kontexten. Wir haben folgende Kontexte identifiziert: ❑ den Anwendungsbereich (z.B. Schule), ❑ die Handhabungs- und Präsentationsformen und deren tech-

nische Realisierung (z.B. elektronischer Schreibtisch mit Materialien als verschiebbaren Piktogrammen, realisiert durch ein GUI-System), ❑ die verwendete Technik, die im Rahmen einer Entwicklungs-

methode eingesetzt wird. Dazu gehören etwa die Entwurfsmuster und eine Softwarearchitektur (z.B. das Strategiemuster und seine programmiersprachliche Implementation). Wenn wir zum Thema Anwendungsorientierung festgestellt haben, daß die anwendungsfachlichen Kenntnisse des Entwicklers die Voraussetzung für ein qualitativ hochwertiges Softwaresystem bilden, dann gilt dies auch für die anderen Kontexte, die die Softwarekonstruktion beeinflussen. Je nach Arbeitszusammenhang wird ein bestimmter Kontext im Vordergrund stehen und die Struktur und die Dynamik des Systems prägen. So ist für die Diskussion unter Entwicklern wichtig, welche Entwurfsmuster bei Implementierung der fachlichen Klassen eingesetzt werden.

2


2.5


Trotz dieser Differenzierung soll das Grundprinzip unseres Ansatzes bei der Modellierung gewahrt bleiben: Die anwendungsfachliche Modellierung bestimmt die technische. Dies geschieht nicht durch eine einfache Eins-zu-eins-Transformation aller fachlichen Begriffe in Klassen und aller Umgangsformen in Operationen. Trotzdem läßt sich das im Modell des Anwendungsbereichs realisierte Begriffsgebäude ohne Modellbruch und erkennbar strukturähnlich in Klassen und Klassenbeziehungen übertragen. Die Strukturähnlichkeit beschränkt sich allerdings auf die in Kapitel 2.1 skizzierten Modellelemente wie Gegenstand – Objekt oder Begriff – Klasse. In Softwaresystemen bezeichnen wir diese Modellelemente als Mikroelemente. Große Softwaresysteme mit mehreren tausend Klassen sind anhand dieser Mikroelemente alleine praktisch nicht mehr verständlich und damit auch nicht mehr weiterentwickelbar. Wir benötigen höhere Strukturierungsformen, also Makrostrukturen, um Systeme in dieser Dimension noch zu beherrschen. Die Anwendungsorientierung des WAM-Ansatzes zeigt die Richtung, in der wir nach solchen Makrostrukturen suchen müssen. In Kapitel 3.3 diskutieren wir, welche Makrostrukturen im Anwendungsbereich analog zu den fachlichen Gegenständen und Begriffen Ausgangspunkt für eine strukturähnliche Gestaltung großer Softwaresysteme sein können.

2

304 Anwendungsorientierung und Strukturähnlichkeit

Mikroelemente und Makrostrukturen


2.5


305

Im weiteren werden wir immer wieder auf den Zusammenhang von fachlichen Strukturen und den Modellen bei der Softwareentwicklung eingehen. Jedes Modell ist zunächst durch seine Strukturen und Bezüge definiert. Darüber hinaus ist für uns wichtig, daß ein Modell auch eine geeignete Abbildung des von uns gewählten (Anwendungs-) Bereichs ist. Mit »geeignet« meinen wir, daß das Modell aufgrund seines Umfangs und seiner Komplexität noch konstruierbar und verständlich ist. Wir suchen darüber hinaus nach inhaltlichen Abstraktionskriterien, die dem Modell eine innere Konsistenz geben. Wenn dieser Zusammenhang von Modell und fachlichem Modellierungsprozeß gemeint ist, sprechen wir von einer Modellierungseinheit. Modellierungseinheit: Eine Modellierungseinheit faßt ein konstruierbares und verständliches Modell mit fachlichen Abstraktionskriterien zusammen. Ein Modell ist durch seine Struktur, d.h. Elemente und Beziehungen, die Eigenschaften der Elemente und durch Bildungsgesetze gegeben. Für eine Modellierungseinheit werden Abstraktionskriterien angegeben, die den Zusammenhang zwischen Modell und modelliertem Bereich festlegen. Dadurch wird die fachliche Konsistenz des Modells sichergestellt.

2


2.5


In der Softwaretechnik ist ein Modul eine klassische Modellierungseinheit. Es hat einerseits eine bestimmte Struktur und Repräsentation: In einer modularen Programmiersprache lassen sich Variablen, Konstanten, Operationen und Typen in einer benannten Einheit kapseln, die dadurch vor ungewolltem Zugriff geschützt sind. Ein Modul wird zudem nach bestimmten Bildungsgesetzen entwickelt, die etwa mit Kohäsion und Kopplung bezeichnet werden. Diese sagen etwas darüber aus, welche Bezüge innerhalb und zwischen Modulen herrschen sollen. Gleichzeitig achten wir darauf, daß ein Modul von seinem Umfang her noch als eine handliche und verständliche Konstruktionseinheit realisiert wird. Die anwendungsfachlichen Zusammenhänge kommen ins Spiel, wenn wir z.B. das Geheimnisprinzip dazunehmen, d.h., wenn wir fordern, daß jeweils eine fachliche oder softwaretechnische Entwurfsentscheidung in einem Modul verborgen werden soll. Dies hat nichts mehr mit der Struktur oder den Bezügen der Elemente eines Moduls zu tun, sondern gibt an, wie wir den zu modellierenden Bereich betrachten und im Modul abbilden wollen.

2

306 Beispiel Modellierungseinheiten


2.5


307

2.5.1 Ein vereinfachtes Modell der Softwareentwicklung In diesem Abschnitt stellen wir ein vereinfachtes Modell des objektorientierten Softwareentwicklungsprozesses vor, um daran den Zusammenhang der gerade beschriebenen Modelle und Kontexte diskutieren zu können. Wir wollen hier bewußt kein Vorgehensmodell präsentieren, das in konkreten Softwareprojekten Anleitung geben soll, was wann von wem zu tun ist. Auf diese Fragen gehen wir vielmehr in Kapitel 5.1.1 ein. Hier benötigen wir ein beschreibendes Modell, das die bisher aufgeworfenen Themen und Fragen im Zusammenhang darstellen und diskutierbar machen kann. Die bisherigen Überlegungen zur Softwareentwicklung als Modellierungsprozeß haben wir in Abbildung 2-27 zusammengefaßt. In der Abbildung sind die bisher identifizierten Modelle und die Kontexte dargestellt. Offensichtlich kommt dem Anwendungsbereich die dominierende Position im Modellierungs- und damit Entwicklungsprozeß zu. Eine Differenzierung in einzelne Modellierungsaktivitäten oder die geforderten Autor-Kritiker-Zyklen sind weggelassen. Die Abbildung ist auch insofern vereinfacht, als daß die Rückwirkungen des sich entwickelnden Anwendungssystems (z.B. als Prototyp) auf die Modelle und den Anwendungsbereich fehlen.

2

Ein beschreibendes Modell der Softwareentwicklung


2.5


Verwendete Technik

Handhabung & Präsentation

beeinflußt

beeinflußt


Anwendungsbereich

ist Basis für

308

beeinflußt


ist Basis für

Anwendungssystem

Abb. 2-27 Ein vereinfachtes Modell der objektorientierten Softwareentwicklung

2


2.5


309

Der Anwendungsbereich

Bevor mit der Entwicklung eines Softwaresystems begonnen werden kann, muß der inhaltlich betroffene Anwendungsbereich festgelegt werden. Er bildet den Ausgangspunkt und zugleich den Kontext, in dem das zukünftige System eingesetzt wird. Beispiele für Anwendungsbereiche sind die Pausenplanung in einer Schule, das Kreditgeschäft einer Bank oder die Patientenaufnahme in einem Krankenhaus. Wir messen dem Anwendungsbereich deshalb so große Bedeutung bei, weil er für unsere Art der Softwareentwicklung entscheidend ist. Nach den Prinzipien der Anwendungsorientierung (s. Kapitel 2.4) analysieren und beschreiben die Entwickler in der Fachsprache der Anwendung die aktuellen Arbeitsaufgaben und Situationen, die den Anwendungsbereich charakterisieren. Dies entspricht einer Ist-Analyse (vgl. [Kieback et al. 94, Floyd et al. 97]), bei der die typischen Arbeitsabläufe und die dabei verwendeten Gegenstände in ihrem fachlichen Verwendungszusammenhang z.B. in Szenerios oder Glossareinträgen dargestellt werden (s. dazu Kapitel 5.2). Der Anwendungsbereich ist gleichzeitig Grundlage für die Konstruktion des fachlichen Modells. Mit der Analyse und Beschreibung des Ist-Zustands im Anwendungsbereich formt sich auch das Modell des Anwendungs-

2

Analyse des Anwendungsbereichs


2.5


310

bereichs. Dieses Modell repräsentiert den Ausschnitt des tatsächlichen Anwendungsbereichs, der durch das Softwaresystem unterstützt werden soll. Es ist somit zunächst ein Kandidat für eine Modellierungseinheit. Im weiteren werden wir die Frage untersuchen, ob es vom Umfang her als ein Modell unseren Anforderungen an Verständlichkeit und Konstruierbarkeit entspricht. Anwendungsbereich: Der Anwendungsbereich ist Ausgangsbasis für die Ist-Analyse und für die Erstellung des fachlichen Modells des Anwendungsbereichs. Der Anwendungsbereich kann eine Organisation, ein Bereich innerhalb einer Organisation oder eine Arbeitsplatz sein. Der Anwendungsbereich ist weit genug gefaßt, um die für die Konstruktion von Modellen relevanten fachlichen Zusammenhänge während der Ist-Analyse zu verstehen. Durch einen Anwendungsbereich ist typischerweise auch eine entsprechende Anwendungsfachsprache festgelegt.

Die Beschäftigung der Entwickler mit dem Anwendungsbereich umfaßt somit nicht nur die Ausschnitte, die in dem fachlichen Modell

2


2.5


311

abgebildet werden, sondern auch die Bereiche, die notwendig sind, um innerhalb der Ist-Analyse ein Bild von der momentanen Arbeitssituation festzulegen. Die Gefahr und die Kunst besteht darin, diese IstAnalyse richtig einzugrenzen und nicht zeitlich und thematisch ausufern zu lassen. Erfahrungen aus traditionellen Datenmodellierungsprojekten haben zur Genüge gezeigt, daß eine flächendeckende und vollständige Analyse des gesamten Anwendungsbereichs nicht machbar ist. Das »Abbruchkriterium« ist hierbei mit Blick auf das zukünftige Anwendungssystem zu gewinnen. Die Entwickler müssen sehr schnell eine erste vage Vorstellung darüber bekommen, an welchen Stellen des Anwendungsbereichs eine Softwareunterstützung sinnvoll und machbar ist. Bei der Diskussion um die Pausenplanung in der Schule wurde rasch klar, daß die Softwareunterstützung für die dort anstehenden Verwaltungs- und Planungsaufgaben eher dürftig war. Nachdem die Lehrer einmal die Möglichkeiten der Unterstützung ihrer Arbeit erkannt hatten, kam bald der Wunsch ins Gespräch, ein umfangreicheres Planungssystem zu entwerfen. Die Entwickler stellten aber fest, daß die dadurch hinzukommenden fachlichen Fragen und Probleme den Horizont des eigenen Fachwissens und die Ressourcen des Projektes bei weitem überstiegen. Daher wurde die Analyse der schulischen Aufga-

2


2.5


312

ben bewußt auf die eigentliche Pausenplanung und das Zusammenspiel mit dem Schulsekretariat reduziert. Themen wie Unterrichtsplanung und -einteilung wurden nicht weiter betrachtet. Das fachliche Modell des Anwendungsbereichs

Im fachlichen Modell des Anwendungsbereichs werden die Komponenten und Bezüge des Anwendungsbereichs beschrieben, die durch Anwendungssoftware unterstützt werden sollen. Im Kontext des WAM-Ansatzes werden ausgehend von den Aufgaben die dabei relevanten Gegenstände und deren Umgangsformen identifiziert. Umgangsform: Eine Umgangsform ist eine charakteristische Handlung an oder mit einem Gegenstand.

Die so identifizierten Gegenstände und Umgangsformen werden durch Abstraktion auf die Begriffe der jeweiligen Fachsprache abgebildet und dann in ihren Beziehungen modelliert. Dabei stehen im Bereich der objektorientierten Modellierung Generalisierung und Komposition zur Verfügung.

2


2.5


313

Modell des Anwendungsbereichs: Das Modell des Anwendungsbereichs umfaßt aus anwendungsfachlicher Sicht diejenigen Aspekte des Anwendungsbereichs, die durch ein Anwendungssystem unterstützt werden sollen. Das Modell orientiert sich an den Aufgaben und den dabei relevanten Gegenständen mit ihren Umgangsformen. Die damit verbundenen Begriffe werden durch Generalisierung und Komposition in einem fachlichen Begriffsmodell dargestellt. Die Ausarbeitung des Modells orientiert sich an einem entsprechenden Leitbild mit seinen Entwurfsmetaphern. Das Modell des Anwendungsbereichs besteht neben dem Begriffsmodell aus ausgewählten anwendungsorientierten Dokumenten (z.B. Szenarios, Glossareinträgen und Kooperationsbildern in Kapitel 5.2).

Die Modellierung des Anwendungsbereichs schlägt sich zunächst in einer Sammlung von Szenerios und Glossareinträgen (s. Kapitel 5.2.1, 5.2.2) nieder. Mit zunehmender konzeptioneller Durchdringung des Anwendungsbereichs durch die Entwickler wird das begriffliche Gerüst hinter diesen Dokumenten in einem eigenen Begriffsmodell herausgearbeitet. Bei der Identifikation der relevanten Gegenstände,

2

Szenarios, Glossar, Begriffsmodell


2.5


314

Begriffe und Bezüge helfen das Leitbild und seine Entwurfsmetaphern (s. Kapitel 2.2). Sie geben dem Entwickler die Orientierung, vorgefundene Dinge am Arbeitsplatz in Kategorien wie Werkzeug, Material oder Automat zu unterteilen und nach entsprechenden Merkmalen zu ihrer Charakterisierung zu suchen. Begriffsmodell: Ein Begriffsmodell ist ein auf den fachlichen Gegenständen des Anwendungsbereichs beruhendes Begriffssystem, in dem die Begriffe in Generalisierungs- und Kompositionsbeziehungen zueinander in Beziehung gesetzt und durch Umgangsformen beschrieben werden. Oft werden Begriffsmodelle als Netz von Dienstleistungsbeziehungen (z.B. in Form von CRC-Karten) oder als reine Begriffshierarchien aus Ober- und Unterbegriffen dargestellt.

In Abbildung 2-26 auf S. 143 haben wir ein sehr »frühes« und einfaches Begriffsmodell aus dem Bereich Pausenplanung dargestellt. Offenkundig sind zwar schon Benutzt-Beziehungen identifiziert, aber die Generalisierung ist noch nicht systematisch eingesetzt. Abbildung 2-28 zeigt einen Ausschnitt aus einem »gereiften« bankfachlichen

2


2.5


315

Begriffsmodell: die Sicherheitenhierarchie für ein Kreditvergabesystem. Eine Sicherheit wird von einer Bank für die Vergabe eines Kredites verlangt, um bei einer Zahlungsunfähigkeit des Kreditnehmers offene Forderungen abdecken zu können. Die ausgewogene Differenzierung in Breite und Tiefe deutet darauf hin, daß hier schon einige Autor-Kritiker-Zyklen durchlaufen wurden.

Sicherheit

Abtretung

Pfandrecht

Grundpfand- Verpfändungsrecht recht

Bürgschaft

Bewegliche Sache

Übereignung

Übereignung Maschine

Übereignung KFZ

Verpflichtungserklärung

Übereignung Warenlager

Abb. 2-28 Ein Ausschnitt aus einem

Auf dem Weg zu Begriffshierarchien hilft die Arbeit mit CRC-Karten (vgl. [Beck & Cunningham 89]). Auf ihnen werden die Dienstleistun-

2

bankfachlichen Begriffsmodell


2.5


316

gen notiert, die ein fachlicher Gegenstand anbietet. Dazu werden auch diejenigen Gegenstände festgehalten, die ein Gegenstand selbst in Anspruch nimmt, um die eigenen Dienstleistungen zu erbringen. Abbildung 2-29 zeigt eine CRC-Karte aus dem Pausenplan-Beispiel

Pausenplan zur neuen Bearbeitung vorbereiten / leeren Lehrer einer Pause zuordnen prüfen, ob Lehrer Pause beaufsichtigen kann Lehrer von Pause entfernen prüfen, ob alle Pausen beaufsichtigt sind alle nicht beaufsichtigten Pausen liefern Pausen ermitteln, die ein Lehrer beaufsichtigt Lehrer ermitteln, der eine Pause beaufsichtigt prüfen, ob Konflikte in den Pausenaufsichten vorliegen alle Pausen mit Konflikten in der Lehrerzuordnung liefern

Lehrer Pause

Abb. 2-29 Beispiel für eine CRC-Karte Pausenplan

2


2.5


317

Das Modell des Anwendungssystems

Das durch die Analyse entstandene Modell des Anwendungsbereichs wird im Entwurf in ein Modell des Anwendungssystems überführt. Dort werden zu den anwendungsfachlichen Merkmalen die für die Konstruktion des Systems notwendigen technischen Charakteristika ergänzt, die zum Beispiel durch die eingesetzte Programmiersprache oder die verwendete Datenbank gegeben sind. Das Modell des Anwendungssystems repräsentiert die softwaretechnische Vergegenständlichung des Anwendungsmodells. Wieder, wie beim Modell des Anwendungsbereichs, müssen wir im weiteren untersuchen, ob es ein gesamtes Modell als Modellierungseinheit geben kann oder ob eine Substrukturierung sinnvoll ist. Beschrieben wird das Modell des Anwendungssystems vorrangig anhand der Modellelemente, die das Objekt-Metamodell (s. Kapitel 2.1) zur Verfügung stellt. Dabei spielt der enge Zusammenhang von Entwurfsmetaphern und Mustern eine große Rolle (s. Kapitel 2.3.1). So können Gegenstände, die im Modell des Anwendungsbereichs bereits als Werkzeuge oder Materialien identifiziert wurden, fachlich und strukturell ähnlich in die passenden Konzeptions- und Entwurfsmuster übertragen werden. Daraus folgt, daß das Benutzungsmodell (s. Kapitel 2.2, S. 71) ein wichtiger anwendungsfachlicher Teil des

2

Benutzungsmodell


2.5


Modells des Anwendungssystems ist. Das Benutzungsmodell wird selten explizit formuliert, sondern durch die nachfolgenden softwaretechnischen Modelle realisiert. An der Grenzlinie zwischen dem Modell des Anwendungsbereichs und dem des Anwendungssystems stehen die Systemvisionen (s. Kapitel 5.2.3). Sie sollen den eigentlichen Entwurfsprozeß fördern. Dazu greifen sie in ihren fachlichen Ausprägungen Konzepte und Begriffe des Anwendungsmodells auf und übertragen diese in ihren technischen Ausprägungen in ein Softwaremodell. Das Modell des Anwendungssystems wird konkret in zwei softwaretechnischen Modellen repräsentiert, dem Entwurfsmodell und dem Implementierungsmodell. Während das Entwurfsmodell an den verschiedenen fachlichen und technischen Konzepten ausgerichtet ist, wird das Implementierungsmodell als Programmtext in der gewählten Programmiersprache verfaßt.

318

Systemvisionen

Entwurfsmodell, Implementierungsmodell

Entwurfsmodell: Das Entwurfsmodell repräsentiert als softwaretechnisches Modell die Zusammenhänge zwischen den softwaretechnischen Konstruktionskomponenten (z.B. Klassen, Mustern, Rahmenwerken) sowie ihre fachlichen und technischen Eigenschaften. Dazu werden geeignete Diagrammarten verwendet, wie zum Beispiel Klassen-, Objekt-, Zustandsübergangs- oder Interaktionsdiagramm.

2


2.5


319

Es muß nicht notwendigerweise für das gesamte Modell des Anwendungssystems ein Entwurfsmodell geben. Gerade bei Entwicklungen in bekannten Anwendungsbereichen werden oft die Strukturen des fachlichen Anwendungsmodells direkt in Programmcode übersetzt, und ein eigenes Entwurfsmodell fällt weg. Wenn ein Entwurfsmodell erstellt wird, macht es im Rahmen des WAM-Ansatzes Sinn, ein explizites Benutzungsmodell unter softwareergonomischen Gesichtspunkten zu erarbeiten. Implementierungsmodell: Ein Implementierungsmodell setzt die fachlichen und die Entwurfsmodelle in Programmcode um. Dieser wird durch geeignete Werkzeuge (Compiler und Linker) in ausführbare Anwendungssoftware transformiert.

In Abbildung 2-30 haben wir das Begriffsmodell von Abbildung 2-28 aufgegriffen und als entsprechendes Klassenmodell der Sicherheitenhierarchie dargestellt. Hier wird die Strukturähnlichkeit zwischen den fachlichen Begriffsgebäuden und dem softwaretechnischen Modell besonders deutlich.

2


2.5


320

Sicherheit

Sicherheit_Impl

Abtretung

Grundpfandrecht

Pfandrecht

Verpfändungsrecht

Bürgschaft

Bewegliche Sache

Übereignung Maschine

Übereignung

Übereignung KFZ

Vernichtungserklärung Übereignung Warenlager

Abb. 2-30 Ein Ausschnitt aus einem bankfachlichen Klassenmodell

In Abbildung 2-31 haben wir eine Schnittstellenbeschreibung der Klasse Pausenplan abgebildet, die sehr ähnlich zur fachlichen Beschreibung des Pausenplans auf der CRC-Karte von Abbildung 2-29 ist.

2


2.5


Void PausenplanLeeren() // Umgang mit Lehrkoerper void SetzeLehrkoerper(tLehrkoerper *) VB: !HatLehrkoerper() NB: HatLehrkoerper() tLehrkoerper * GibLehrkoerper() BOOL HatLehrkoerper() // Umgang mit Lehrer unsigned int AnzahlAufsichten (tLehrer *) unsigned int AnzahlAufsichtspflichten (tLehrer *) LIST LehrerMitFreierKapazitaet() LIST LehrerZuordnen (tPause *)

321 Abb. 2-31 Fachliche Schnittstelle der Klasse Pausenplan

// Umgang mit Pausen tPausenliste * GibPausenliste() tPausenliste NichtBeaufsichtigtePausen() unsigned int AnzahlPausen() BOOL AllePausenBeaufsichtigt() BOOL IstPauseBeaufsichtigt(tPause *) // Umgang mit Zuordnung BOOL ExistierenAufsichtskonflikte() tPausenliste KonfliktbehaftetePausen() // Umgang mit Aufsichtsorten void AufsichtsortAufnehmen (tAufsichtsort *) void AufsichtsortEntfernen () void GeheZumErstenAufsichtsort () void GeheZumLetzenAufsichtsort () void GeheZumNaechstenAufsichtsort () VB: !IstLetzterAufsichtsort () void GeheZumVorigenAufsichtsort () VB: !IstErsterAufsichtsort () tAufsichtsort * GibAufsichtsort () unsigned int AnzahlAufsichtsorte () BOOL IstLetzterAufsichtsort () BOOL IstErsterAufsichtsort () BOOL HatAufsichtsort (tLehrer *)

2


2.5


322

Das Anwendungssystem

Ist das Modell des Anwendungssystems soweit konkretisiert, daß ein Implementierungsmodell vorliegt, kann daraus zusammen mit den notwendigen Bibliotheken und Rahmenwerken und mit Hilfe von Entwicklungswerkzeugen wie Compiler und Linker die ablauffähige Anwendungssoftware erzeugt werden. Die Anwendungssoftware bildet zusammen mit den angebundenen Teilen der Systembasis das Anwendungssystem als dem Produkt des Entwicklungsprozesses. Das Anwendungssystem beeinflußt schon vor seiner Fertigstellung die Modelle des Anwendungsbereichs und des Anwendungssystems, da es sich als Idee oder »Vision« schon während der Analyse und bei der fachlichen Modellierung in den Köpfen der Entwickler herausbildet. Das tatsächlich eingesetzte Anwendungssystem verändert unmittelbar die Situation und die Arbeitsprozesse im Anwendungsbereich. Dies muß besonders bei einer evolutionären Vorgehensweise berücksichtigt werden, bei der Systemversionen schrittweise ausgeliefert werden.

2

Zusammenhang zu den Modellen


2.5


323

Anwendungssystem: Das Anwendungssystem umfaßt die neu erstellte und die in Form von Bibliotheken und Rahmenwerken wiederverwendete Anwendungssoftware mit ihren Verbindungen zu den Komponenten der Systembasis. Das Anwendungssystem vergegenständlicht die fachlichen und softwaretechnischen Modelle und beeinflußt diese Modelle als Idee in den Köpfen der Entwickler schon vor seiner Fertigstellung. Im Einsatz verändert es den Anwendungsbereich.

Die verwendete Technik

Das aus dem Anwendungsbereich abgeleitete fachliche Modell sollte weitgehend frei von technischen Faktoren erstellt werden. Diese prägen aber unmittelbar die Konstruktion des Modells des Anwendungssystems. So führt zum Beispiel die Verwendung der Programmiersprache C++ dazu, daß im softwaretechnischen Modell die Freigabe von nicht mehr benötigten Objekten berücksichtigt werden muß. Wird eine Programmiersprache wie Java eingesetzt, die über einen GarbageCollector verfügt, so ist dies nicht notwendig. Trotzdem wird die verwendete Technik bereits das fachliche Modell beeinflussen, denn nur wenn die Realisierungsmöglichkeiten

2


2.5


324

und -mittel bekannt sind, kann das Modell des Anwendungssystems auf das Machbare eingegrenzt werden. Verwendete Technik: Die verwendete Technik umfaßt: ❑ Technik, die unabhängig von den gestellten fachlichen Anforderungen zur Entwicklung eines Anwendungssystems benötigt wird. ❑ Technik, die eingesetzt wird, um das Anwendungssystem so zu gestalten, daß es den gestellten fachlichen Anforderungen bestmöglich genügt. Technik kann als konkrete Komponente oder konzeptionell als Technologie verwendet werden.

Die verwendete Technik ist auf zwei Ebenen angesiedelt: ❑ Sie umfaßt alle Hilfsmittel und Verfahren, die bei der Software-

entwicklung eine Rolle spielen, aber nicht selbst in das Anwendungssystem eingehen. Beispiele hierfür sind die Entwicklungsumgebung und Textverarbeitungswerkzeuge, das Objekt-Metamodell sowie Werkzeuge, die ausführbare Anwendungssysteme erzeugen.

2

Verwendete Technik ... zur Unterstützung der Softwareentwicklung


2.5


❑ Unmittelbaren Einfluß hat diejenige Technik, die zur Realisie-

rung von Gestalt und Funktionalität des Anwendungssystems eingesetzt wird, d.h., sie geht direkt oder indirekt in das Produkt ein. Dazu gehören z.B. das GUI-System, die dazu verfügbaren Gestaltungsrichtlinien, das relationale Modell und eine entsprechende Datenbank. Diese technischen Konzepte und Mittel sind nicht losgelöst von den fachlichen Anforderungen zu sehen. So führt beispielsweise die Anforderung, daß alle Mitarbeiter ein gemeinsames Aktenarchiv benutzen sollen, zum Einsatz einer Datenbank und entsprechenden Client- und Serverrechnern. Soweit die für das Anwendungssystem verwendete Technik als reale Komponente vorliegt, kann sie direkt eingesetzt werden. Im Implementierungsmodell werden diese Komponenten dann über Schnittstellen-Bibliotheken oder Rahmenwerke verwendet. Diese Komponenten nennen wir Systembasis. Um ein Softwaresystem in unterschiedlichen Hardware- und Softwareumgebungen einsetzen zu können, wird die Systembasis in der Regel durch eine Portabilitätsschicht gekapselt.

2

325 ... zur Realisierung des Anwendungssystems

Systembasis


2.5


326

Systembasis: Die Systembasis enthält die Menge aller Schnittstellen zu den im Implementierungsmodell verwendeten (externen) technischen Komponenten.

Die verwendeten technischen Konzepte und deren Beschreibung gehen über das Modell des Anwendungssystems in das Produkt ein. Dies gilt etwa für Programmierrichtlinien. Vielfach hängen die Systembasis und die verwendeten technischen Konzepte zusammen. Denn für die Konstruktion eines Entwurfs- oder Implementierungsmodells muß der Entwickler Modelle der verwendeten Technik besitzen.

Technologie

Technologie: Technologie bezeichnet das konzeptionelle Wissen der Entwickler um die verwendete Technik. Wird das Modell des Anwendungssystems erstellt, muß sich dieses Wissen in einem expliziten oder impliziten Modell der verwendeten Technik niederschlagen.

2


2.5


Soll beispielsweise das fachlich motivierte Aktenarchiv mit Hilfe einer relationalen Datenbank realisiert werden, dann reicht es nicht aus, eine solche Datenbank zu installieren. Der Softwareentwickler muß auch ein implizites oder explizites Modell dieser Technik haben. Nur so wird er die Notwendigkeit erkennen, die fachlichen Klassen seines Modells um zusätzliche Operationen zum Anschluß der Datenbank zu erweitern. Gleiches gilt für die Verwendung von Programmbibliotheken oder Rahmenwerken, die ohne eine modellhafte Vorstellung von Softwarearchitekturen und Entwurfsmustern kaum einsetzbar sind. Dieses Wissen um die hinter den konkreten technischen Komponenten stehenden Konzepte nennen wir Technologie.

327 Beispiel für Technologie

Handhabung und Präsentation

Bei der Entwicklung interaktiver Anwendungssoftware ist der dritte, hier relevante Kontext die Handhabung und Präsentation. In unserer Terminologie sprechen wir auch vom Umgang mit Software; im sonstigen Programmiererjargon heißt dies auch Look and Feel. Auch dazu gibt es eigene Konzepte und Modelle. Offensichtlich sind Konzepte wie elektronischer Schreibtisch, direkte Manipulation von grafischen Symbolen und Mausinteraktion Bestandteile von Präsentation und Handhabung.

2

Umgang mit Software


2.5


Um die verschiedenen Konzepte von Handhabung und Präsentation zu einem einheitlichen Bild zusammenzufügen, wählen wir ein Leitbild mit dazu passenden Entwurfsmetaphern (s. Kapitel 2.2.3). Ein Leitbild gibt mit seinen Metaphern zwar noch kein konkretes Benutzungsmodell eines Anwendungssystems vor, aber bietet dem Entwickler eine Orientierung bei der Gestaltung der Software. Oft wird übersehen, daß Handhabung und Präsentation einen ähnlich eigenständigen Kontext bilden, wie der Anwendungsbereich und die verwendete Technik. Dies liegt zum einen an der Selbstverständlichkeit, mit der wir heute interaktive Software benutzen und vielleicht auch an der Uniformität aktueller Arbeitsplatzsysteme, was diesen Aspekt anbetrifft.

328 Leitbild und Entwurfsmetaphern

Bei der Gestaltung von Anwendungssystemen wie dem Pausenplansystem entpuppt sich gerade die Frage nach dem Umgang als offenes Problem. Wie soll der Pausenplan und der Lehrkörper repräsentiert werden? Welche Handhabung erlauben die verschiedenen Werkzeuge? Wie spielt der Pausenplaner mit dem Lehrkörpereditor zusammen? Diese Fragen können bei gleichem Anwendungsbereich und festgelegter Technik sehr unterschiedlich beantwortet werden, tragen aber aus unserer Erfahrung wesentlich zur Gebrauchsqualität eines Anwendungssystems bei.

2


2.5


329

2.5.2 Die Kontexte der Softwareentwicklung Im folgenden fassen wir das bisher vorgestellte Modell der Softwareentwicklung mit seinen drei Kontexten zusammen (s. Abbildung 2-32): Der Anwendungsbereich, der den späteren Einsatzkontext des zu konstruierenden Softwaresystems bildet, ist die fachliche Ausgangsbasis für die Konstruktion des fachlichen Modells des Anwendungsbereichs und damit auch für das technische Modell des Anwendungssystems. Der Anwendungsbereich ist der primäre Kontext unseres Modells der Softwareentwicklung. Die verwendete Technik ist der Kontext, der vor allem das Modell des Anwendungssystems prägt. Durch die hier angesiedelten architektonischen Konzepte, Gestaltungsrichtlinien und Modelle von Technik (im Sinne von Technologie) sowie den konkreten technischen Komponenten der Systembasis gewinnt das Anwendungssystem eine eigenständige Dimension. Diese ist nicht völlig vom anwendungsfachlichen Kontext unabhängig, wie wir am Beispiel des Aktenarchivs und seiner Realisierung mit Hilfe einer relationalen Datenbank gesehen haben. Dennoch bietet die verwendete Technik einen eigenen Gestaltungsspielraum, der berücksichtigt werden muß.

2

Anwendungsbereich

Verwendete Technik


2.5


Schließlich haben wir den Kontext der Handhabung und Präsentation von Anwendungssystemen identifiziert, der für die Gestaltung des Benutzungsmodells interaktiver Anwendungen eine immer wichtigere Rolle spielt.

2

330 Handhabung und Präsentation


2.5


Verwendete Technik

Handhabung & Präsentation Architekturen & Entwurfsmuster

Leitbild & Entwurfsmetaphern

Anwendungsbereich

Analyse

331



Technologie der Systembasis

Modell des Anwendungssystems Benutzungsmodell

Entwurf Entwurfsmodell

Systembasis

Implementationsmodell

Rahmenwerke & Bibliotheken

Abb. 2-32 Die Kontexte und Modelle Anwendungssystem

der Softwareentwicklung

In Abbildung 2-32 haben wir wieder zyklische Rückwirkungen weg-

2


2.5


gelassen, da es uns um einige generelle Aussagen geht, die bereits an diesem einfachen Bild klar werden: Wenn diese drei Kontexte den Entwicklungsprozeß und sein Ergebnis, das Anwendungssystem, entscheidend prägen, dann sollten wir sie jeweils beachten und zum expliziten Gegenstand der Diskussion und Planung in Softwareprojekten machen. Da die einzelnen Kontexte relativ eigenständig sind, können sie sich jeweils unabhängig voneinander verändern. Dies zeigt auch die Erfahrung: Fenstersysteme kommen mit neuer Funktionalität auf den Markt; die fachlichen Anforderungen im Anwendungsbereich verändern sich; Benutzer möchten neue Interaktionsformen (z.B. Hyperlink-Navigation wie im Web) auch in ihrer Anwendung einsetzen. Bei der Ausarbeitung unseres Architekturmodells sollten wir Vorsorge für diese Änderungen treffen. Veränderungen in einem Kontext müssen so in entsprechenden Komponenten des Anwendungssystems gekapselt sein, daß die anderen Komponenten möglichst nicht betroffen sind. Schließlich hat das vorgestellte Modell der Softwareentwicklung noch einen weiteren Vorzug. Wir haben festgestellt, daß die drei Kontexte der Softwareentwicklung zwar eigenständig, aber nicht vollständig unabhängig voneinander sind. Entsprechend können wir uns bei jeder Änderung in einem Kontext fragen, wie sich diese Änderung auf das Anwendungssystem und die anderen beiden Kontexte auswirkt.

2

332 Bedeutung der Kontexte

Relative Unabhängigkeit

Wechselbeziehungen


2.5


333

Dies erleichtert im Projekt die Einschätzung von Aufwendungen, Problemen und Auswirkungen, die eine gewünschte oder notwendige Änderung nach sich zieht. Verdeutlichen wir dies an Beispielen: In der Planungsphase des Pausenplan-Projekts wird vorgeschlagen, statt C++ Smalltalk einzusetzen. Dies ist auf den ersten Blick nur eine Veränderung im Kontext der verwendeten Technik, die sich auf das Implementierungsmodell niederschlägt. Bei genauerer Betrachtung zeigt sich, daß nicht alle vorhandenen Komponenten der technischen Basis mit Smalltalk verknüpft werden können. Da Smalltalk ein anderes Objekt-Metamodell gegenüber C++ besitzt (z.B. keine Mehrfachvererbung), müssen auch Änderungen an der Softwarearchitektur und den eingesetzten Mustern vorgenommen werden. Schließlich wird deutlich, daß durch die Smalltalk-Programmierumgebung mit ihrem interaktiven GUI-Builder bestimmte bisher verwendete Handhabungs- und Präsentationsformen nicht mehr mit vertretbarem Aufwand realisiert werden können, andere sich dagegen neu anbieten. Eine Auswirkung auf das fachliche Anwendungsmodell ist nur gering. Da ein interaktives Anwendungssystem ohne besondere Echtzeit- oder Sicherheitsanforderungen entwickelt werden soll, ist dies ein für Smalltalk gut geeigneter Anwendungsbereich. Überträgt man diese Zusammenhänge auf ein

2


2.5


334

simplifizierendes Dimensionenmodell der drei Aspekte, ergibt sich ein Bild wie in Abbildung 2-33. Abb. 2-33


Beispiele für Installation eines 2. Pausenplansystems Einsatz von Smalltalk

Wechselbeziehungen zwischen den Entwicklungskontexten

Anwendungsbereich

verwendete Technik

Nachdem das Pausenplansystem erfolgreich am Arbeitsplatz des Pausenplanerstellers eingesetzt wurde, macht er den Vorschlag, das System auch für die Schulsekretärin zugänglich zu machen. Auf diese

2


2.5


335

Weise wäre es möglich, die Veränderungen im Unterrichtsplan, für deren Verwaltung die Schulsekretärin zuständig ist, gleich in ihren Auswirkungen auf den Pausenplan einzuschätzen. Die daraus resultierende Veränderung im Anwendungsbereich betrifft natürlich unmittelbar das fachliche Modell. Eine Realisierung erfordert zumindest ein einfaches Client/Server-Modell und eine entsprechende Implementierung. Es stellt sich zudem heraus, daß nun auf der Handhabungsebene zumindest ein minimales Kooperationsmodell realisiert werden muß, damit der Pausenplanersteller und die Schulsekretärin gleichzeitig koordiniert an Lehrerlisten oder Pausenplan arbeiten können. Diese primär fachliche Änderung hat wieder Auswirkungen auf die anderen Kontexte (s. Abbildung 2-33), und es muß überlegt werden, in welchem Umfang die Änderungen in den anderen Dimensionen wünschenswert sind und wie sie sich auf das Anwendungssystem auswirken.

2


2.5


2

336


3

3

Konstruktion interaktiver Systeme

337


In diesem Kapitel greifen wir unmittelbar die Entwurfsmetaphern des WAM-Leitbilds (s. Kapitel 2.2.3) wieder auf und beschreiben sie als Muster: ❑ Werkzeug und Material ❑ Arbeitsumgebung ❑ Behälter ❑ Automat

Diese Muster bilden den konstruktiven Kern des WAM-Ansatzes. Sie werden in zwei Schritten erläutert. Zunächst werden alle genannten Metaphern als Konzeptionsmuster beschrieben. Anschließend werden

3


3.1

Die WAM-Konzeptionsmuster

338

die zentralen Konzeptionsmuster Werkzeug und Material sowie Arbeitsumgebung als Entwurfsmuster detailliert. Dabei benutzen wir wieder die Unterteilung in allgemeine Entwurfsmuster und Konstruktionsansätze, um die Konzeption der Muster von den möglichen Realisierungen in unterschiedlichen Programmiersprachen zu trennen. Für die Konzeptionsmuster Behälter und Automat haben wir auch jeweils einen Abschnitt vorgesehen. In unserer bisherigen Arbeit haben wir zwar oft Behälter und Automaten konstruiert, aber die damit verbundenen Konzepte und Konstruktionen sind noch nicht soweit konsolidiert, daß sich daraus allgemein verbindliche Entwurfsmuster ableiten lassen. Wir haben zwar eine musterartige Form der Beschreibung auch für diese Abschnitte gewählt, aber die Diskussion über Probleme und mögliche Lösungen hat einen viel offeneren Charakter als in den eigentlichen Musterabschnitten.

3.1


Während die Entwurfsmetaphern eine allgemeine Sichtweise und die Begriffe für die Diskussion über den Anwendungsbereich liefern, richten sich Konzeptionsmuster an den Entwickler. Sie greifen die Gegenstände und Konzepte des Anwendungsmodells auf und helfen uns,

3

Federführung: Wolfgang Strunk Ko-Autor: Heinz Züllighoven


3.1


339

Visionen des zukünftigen Systems zu entwerfen. Konzeptionsmuster sind damit Hilfsmittel an der entscheidenden Nahtstelle zwischen Analyse und Entwurf oder Ist und Soll. Die WAM-Konzeptionsmuster beschreiben daher keine Details der inneren Konstruktion von Anwendungssystemen. Dazu dienen dann die Entwurfsmuster. Die Konzeptionsmuster beschreiben die für einen Anwender sichtbaren Elemente des Anwendungssystems. Sie skizzieren damit aus fachlicher Sicht den Entwurf im Großen oder die Architektur. Im Entwicklungsprozeß setzen sie dort an, wo wir uns die fachlichen Konzepte des Anwendungsbereichs erschließen und anhand der WAM-Metaphern die relevanten Gegenstände der täglichen Arbeit identifiziert haben. Betrachten wir die Situation logisch und nicht als zeitliche Projektphase: ❑ Der Anwendungsbereich ist identifiziert, und es ist klar, welche

Arbeitsplätze in welcher Abteilung durch Anwendungssoftware unterstützt werden sollen. ❑ Die Aufgaben an den Arbeitsplätzen und die Art und Weise ih-

rer Erledigung sind verstanden. ❑ Die bei der Erledigung der Aufgaben relevanten Gegenstände

sind erkannt und fachlich beschrieben.

3


3.1


340

❑ Die hinter den Aufgaben und Gegenständen stehenden Kon-

zepte sind verstanden. Jetzt müssen wir das zukünftige System in seinen Komponenten und ihrem Zusammenspiel entwerfen, um es dann technisch zu konstruieren. Als Repertoire für die Modellierung stehen uns dabei die Entwurfsmetaphern zur Verfügung. Allerdings haben wir schon bei der Diskussion der WAM-Metaphern (s. Kapitel 2.2.3) festgestellt, daß eine unmittelbare Übertragung von Gegenständen der täglichen Arbeit in softwaretechnische Komponenten nicht immer sinnvoll oder möglich ist. Konzeptionsmuster sollen uns also helfen, folgende Entwurfsaufgaben zu lösen: ❑ Wie läßt sich ein Anwendungssystem in überschaubare Kom-

ponenten aus Sicht der Anwendung aufteilen? Wie lassen sich Werkzeuge, Materialien, Automaten und Behälter zu einer fachlich motivierten Arbeitsumgebung arrangieren? ❑ In welchem Verhältnis stehen die Gegenstände und Konzepte

des bisherigen Anwendungsbereichs zu den Komponenten des Anwendungssystems? Was ist übertragbar, was nicht? ❑ Wie werden Arbeitsprozesse durch die Komponenten des

Anwendungssystems unterstützt? Welche Abläufe werden im

3


3.1


341

System etwa als Automaten modelliert; welche werden nur durch Werkzeuge unterstützt? Natürlich können die Antworten zu diesen Fragen im Rahmen dieses Buches nicht allgemein gegeben werden, aber wir bemühen uns in der Diskussion um die Konzeptionsmuster, Hinweise zu geben, in welcher Richtung Antworten zu suchen sind. Die Muster dieses Kapitels lassen sich in eine Hierarchie bringen (s. Abbildung 3-1). Das zentrale Muster ist der Zusammenhang von Werkzeug und Material. Daraus ergeben sich die »Teilmuster« Werkzeugentwurf und Materialentwurf. Sie sind so eng mit dem übergeordneten Muster verbunden, daß sie keine vollständige Musterform haben, sondern als eigener Teil in das Muster eingebettet sind. Die beiden Muster Automat und Behälter grenzen sich vom Muster Zusammenhang von Werkzeug und Material ab. Das zentrale Muster Zusammenhang von Werkzeug und Material ist auch Voraussetzung zum Verständnis des Musters Arbeitsumgebung.

Die WAMKonzeptionsmuster

Abb. 3-1

Zusammenhang von Werkzeug und Material

Hierarchie der WAMKonzeptionsmuster

Werkzeugentwurf Arbeitsumgebung


Automat

3


3.1


342

Im weiteren dient Abbildung 3-1 als Orientierung zu Beginn jeder Musterbeschreibung.

3.1.1 Zusammenhang von Werkzeug und Material

Zusammenhang von Werkzeug und Material Werkzeugentwurf Arbeitsumgebung


Automat

Werkzeuge und Materialien sind die zentralen Komponenten eines interaktiven Anwendungssystems nach dem WAM-Ansatz. Da Werkzeuge und Materialien im jeweiligen Arbeitszusammenhang unterschieden werden, ist es wichtig, sie auch komplementär zu entwerfen. Teile ein interaktives Anwendungssystem so in Komponenten auf, das ein Anwender seine Aufgaben je nach Arbeitssituation erledigen kann. Die Komponenten sollen fachlich motiviert sein und in einem erkennbaren Zusammenhang mit den bereits am Arbeitsplatz vorhandenen

3

Problem


3.1


343

Gegenständen stehen. Übertrage die Metaphern Werkzeug und Material auf ein Anwendungssystem. In der täglichen Arbeit benutzen wir Gegenstände, um unsere Aufgaben zu erledigen. Diese Gegenstände ordnen wir an unserem Arbeitsplatz so an, daß sie je nach Arbeitssituation verfügbar sind. Es fällt uns nicht schwer, die meisten dieser Gegenstände als Werkzeuge und Materialien einzugliedern. Je nach Arbeitszusammenhang wählen wir die geeigneten Werkzeuge, um damit die Materialien so zu bearbeiten, daß das gewünschte Arbeitsergebnis entsteht. Das Konzeptionsmuster Zusammenhang von Werkzeug und Material hilft, diese Arbeitszusammenhänge so auszuweiten, daß entsprechende Komponenten eines Anwendungssystems auch als Werkzeuge und Materialien verstanden und entsprechend konstruiert werden können. Da eine unmittelbare Übertragung von vorhandenen handgreiflichen Werkzeugen und Materialien in Software nicht möglich ist und auch nicht angestrebt wird, müssen Werkzeuge und Materialien im Rechner erst konzipiert werden. Dazu sind bestimmte Randbedingungen zu berücksichtigen. Zunächst gehen wir davon aus, daß die Analyse des Anwendungsbereichs zu einem fachlichen Modell führt. Dort sind die relevanten Arbeitsgegenstände und ihre Umgangsformen dargestellt. Die Um-

3

Kontext

Von der Analyse zum fachlichen Modell


3.1


gangsformen ergeben sich aus der Art und Weise, wie die Gegenstände bei der Erledigung der verschiedenen Arbeitsaufgaben verändert und sondiert werden. Damit ist der fachliche Kern der Materialien definiert. Denn wir gehen davon aus, daß die wesentlichen Aufgaben auch nach Einführung des Anwendungssystems erhalten bleiben. Bei der Abbildung von Arbeitsgegenständen aus der Anwendungswelt in das fachliche Modell legen wir fest, daß der Anwender bei der aktiven Erledigung von Aufgaben seine Materialien immer nur mit Hilfe eines Werkzeugs betrachten und verändern kann. Es ist also nicht möglich, das Material direkt in die Hand zu nehmen oder diesen Eindruck zu vermitteln. Wir müssen für jede Handhabung ein geeignetes Werkzeug entwerfen. Damit wird aus Anwendungssicht nochmals deutlich, daß ein Material derjenige Gegenstand ist, der in einer Arbeitssituation durch ein Werkzeug bearbeitet wird. Andererseits ist ein Werkzeug nur dadurch zu verstehen, daß wir die Art und Weise kennen, in der wir Materialien bearbeiten können. Werkzeuge präsentieren Materialien passend für den Verwendungszusammenhang und bieten dem Anwender eine geeignete Sondierung und Veränderung. Ein Werkzeug vergegenständlicht immer wiederkehrende Arbeitshandlungen an Materialien. Die Qualität der Arbeitsergebnisse hängt entscheidend davon ab, wie gut die Werkzeuge zur Herstellung der Ergebnisse sind. Werkzeugqualität wie-

3

344

Arbeitsgegenstände und Materialien

Werkzeug und Material


3.1


derum ist abhängig von Eigenschaften wie Handhabbarkeit, Effizienz und Konsistenz. Damit sind Werkzeuge und Materialien so eng aufeinander bezogen, daß wir sie immer im Zusammenhang verstehen müssen. Das gleiche gilt auch beim Entwurf von Werkzeugen und Materialien für ein Anwendungssystem. Ein Werkzeug kann nur über die Arbeit an Materialien verstanden werden; ein Material ist fachlich das, was wir mit ihm unter Verwendung von Werkzeugen tun können. Da wir eine direkte Übertragung von vorhandenen Gegenständen in Softwarekomponenten ausschließen, bleiben uns die Konzepte, die wir mit vorhandenen Materialien im Anwendungsbereich verbinden und die Arbeitstätigkeiten, die wir zur Erledigung der verschiedenen Aufgaben ausführen. Sie stellen die Arbeitszusammenhänge dar, die wir beim Entwurf von Werkzeugen und Materialien für ein Anwendungssystem als Anleitung verwenden können. Wir gehen weiter davon aus, daß ein Material in verschiedenen Zusammenhängen sondiert und bearbeitet werden kann. Das entspricht einer normalen Arbeitssituation. Abhängig von der gestellten Aufgabe interessieren den Anwender nur bestimmte Eigenschaften dieses Materials. Deshalb wird ein Material meist mit Hilfe unterschiedlicher Werkzeuge bearbeitet. Umgekehrt ist ein Werkzeug nicht nur für genau eine Handhabung oder »Funktion« geeignet. Es ist inso-

3

345

Arbeitszusammenhänge als Entwurfshilfe


3.1


346

fern »generisch«, als es für unterschiedliche Aufgaben und Zwecke eingesetzt werden kann und mehr als eine Funktion besitzt. Damit kann ein Werkzeug auch meist unterschiedliche Materialien bearbeiten. Modelliere ein Anwendungssystem aus Anwendersicht im Kern als eine sinnvolle Ansammlung von Materialien und Werkzeugen, die dazu geeignet sind, die verschiedenen Aufgaben an einem Arbeitsplatz zu erledigen. Dazu lege zunächst fest, welche der bisherigen Aufgaben vom zukünftigen System unterstützt werden sollen und welche weiterhin konventionell zu erledigen sind. Die zu unterstützenden Aufgaben definieren den Kontext der jeweiligen Arbeitszusammenhänge, in denen Benutzer je nach Situation mit geeigneten Werkzeugen die entsprechenden Materialien bearbeiten. Aufgaben sollten mit Hilfe des Anwendungssystems so erledigt werden können, daß die Nähe zur bisherigen Arbeit erkennbar ist. Diese Ähnlichkeit schlägt sich zunächst im fachlichen Kern der Materialien nieder. Wichtige Materialien im Anwendungsbereich bilden damit den Ausgangspunkt für die Modellierung von (Software-) Materialien. Wir stellen uns als Materialien Arbeitsgegenstände im Rechner vor, die je nach Arbeitssituation in ähnlicher Weise wie bisher aufgenommen, bearbeitet und abgelegt werden.

3

Lösung

Ähnlichkeit der Materialien


3.1


Dabei verwenden wir Werkzeuge, die uns den relevanten Aspekt der bearbeiteten Materialien zeigen und uns die notwendigen Arbeitsmöglichkeiten bieten. Während wir mit Werkzeugen hantieren, sollen diese so selbstverständlich »in der Hand liegen«, daß wir den Eindruck haben, direkt auf den Materialien zu arbeiten. Wir wollen uns auf die Materialien konzentrieren können, wobei das Werkzeug, welches erst den Zugang und die Interaktion mit dem Material ermöglicht, in den Hintergrund tritt. Werkzeuge werden ausgehend von Arbeitsaufgaben entworfen. Sie sind geeignet, die jeweilige Aufgabe in den verschiedenen Arbeitssituationen zu erledigen. Sie sind kein Abbild vorhandener Werkzeuge, sondern verkörpern zunächst das fachliche Prinzip, nach dem Aufgaben erledigt werden. Dazu bieten sie Arbeitsformen, die den jeweiligen Materialien angemessen sind und die möglichen Interaktionen mit Software berücksichtigen. Werkzeuge lassen sich als vergegenständlichte Unterstützung für immer wiederkehrende, aber je nach Situation unterschiedliche Arbeitstätigkeiten mit bestimmten Materialien verstehen.

3

347 Werkzeuge


3.1


348

3.1.2 Materialentwurf Zusammenhang von Werkzeug und Material Werkzeugentwurf Arbeitsumgebung


Automat

Materialien werden sondiert, manipuliert und in andere Materialien eingebettet. Sie sind Gegenstand und Ergebnis der Arbeitstätigkeiten. Während der Arbeit konzentrieren sich Anwender auf ihre Bearbeitung. Mit Hilfe der Entwurfsmetaphern haben wir uns in der Analyse die Materialien der Anwendungswelt erschlossen und die mögliche Arbeit mit ihnen in Umgangsformen modelliert. Wir haben den Materialien einen fachlich motivierten Namen gegeben. Darüber hinaus haben wir allgemeine Konzepte auf den Begriff gebracht, die für den Anwendungsbereich wichtig sind. Diese vorhandenen Materialien und die allgemeinen Konzepte bilden die Grundlage für den Entwurf von Materialien auch auf der Ebene von Materialklassen.

3


3.1


Da in unserem Ansatz Materialien immer durch Werkzeuge oder Automaten bearbeitet werden, ist bei ihnen die Frage der Präsentation und Handhabung kein primäres Problem, denn die Präsentation und Handhabung werden ja stets durch ein Werkzeug vermittelt. Also können wir uns beim Entwurf von Materialien auf die fachliche Funktionalität konzentrieren. Für jedes vorhandene Material muß allerdings geprüft werden, welchen tatsächlichen Beitrag es bei der Erledigung von Aufgaben leistet. Vielfach stellen wir nämlich fest, daß Arbeitsgegenstände allein deshalb verwendet werden, weil diese von den vorhandenen (maschinellen und manuellen) Formen der »Datenverarbeitung« so gefordert werden. Nur so ist die Existenz vieler Kontrollisten und Änderungsformulare zu erklären. Oft werden sie durch anwendungsorientierte Softwareunterstützung hinfällig. Eine wesentliche Idee des WAM-Ansatzes ist, nicht nur die handgreiflichen Dinge des Anwendungsbereichs als Ausgangspunkt für Materialien im System zu nehmen, sondern auch abstrakte Konzepte, die dann als Material »vergegenständlicht« werden. Wir haben schon des öfteren Beispiele aus dem Bankenbereich wie Konto oder Kredit genannt. Als konkrete Gegenstände treten diese Begriffe nicht auf. In einer Bank können wir ein Konto als »Ding« nicht mehr finden. Was wir an den Arbeitsplätzen sehen sind Formu-

3

349 Konzentration auf fachliche Funktionalität


3.1


lare beispielsweise für eine Kontoeröffung oder Einzahlung sowie Repräsentationen auf dem Bildschirm, die den Kontostand oder das sogenannte Gesamtengagement anzeigen. Trotzdem haben Bankangestellte je nach Abteilung und Arbeitsplatz einen bestimmten Umgang mit einem Konto und eine deutliche Vorstellung davon. Dies legt nahe, das abstrakte Konzept Konto als eigenes Material zu vergegenständlichen und nicht nur als eine Ansammlung von darauf bezogenen Gegenständen und Repräsentationen zu modellieren. Materialien bieten nicht nur einen bestimmten fachlichen Umgang, der sich durch Operationen einer Klasse modellieren läßt. Materialien verkörpern darüber hinaus auch eine konzeptionelle Einheit, die im Entwurf gekapselt wird und durch äußeren Eingriff nicht einfach zerstört werden soll. Im Entwurf definieren wir also auch die fachliche Integrität eines Materials. Um dies sicherzustellen, kapseln wir die inneren Zustände einer Materialklasse vor dem direkten Zugriff. Darüber hinaus können wir bestimmte Abhängigkeiten von Materialzustand und möglichen Umgangsformen festlegen. Diese definieren dann das Protokoll einer Materialklasse und damit die innere fachliche Konsistenz eines Materials. Die innere Konsistenz wird über das Vertragsmodell (s. Kapitel 2.1.10) durch Zusicherungen an den verändernden Operationen einer Klasse abgesichert.

3

350

Materialien als konzeptionelle Einheit


3.1


Der Umgang mit einem Material wird erst durch ein Werkzeug möglich. Damit können wir beim Entwurf eines Materials zunächst alle Überlegungen außen vor lassen, die die interaktive Präsentation und Handhabung des Materials betreffen, da dies in die Zuständigkeit der Werkzeuge fällt. Trotzdem müssen wir beim Entwurf berücksichtigen, daß ein Material auch für die Interaktion geeignet sein muß. Hierzu muß das Material für alle Eigenschaften, die der Anwender an einem Material sehen möchte, sondierende Operationen anbieten. Diese werden dann von einem Werkzeug benutzt, um dem Benutzer den Materialzustand zu präsentieren. Hier zeigt sich, daß neben den anwendungsfachlichen Umgangsformen im Entwurf eines Materials auch solche Operationen zu berücksichtigen sind, die durch seine interaktive Handhabung und Präsentation mit einem Werkzeug motiviert sind. Obwohl der Umgang mit einem Material im Computer immer erst durch Werkzeuge ermöglicht wird, existieren Materialien unabhängig von diesen. Die fachlichen Umgangsformen sind für uns bei der Modellierung die stabilen Elemente, und wir klassifizieren und gruppieren Materialien nach der Ähnlichkeit ihrer Umgangsformen. Wenn wir bisher die Umgangsformen eines Materials in den Vordergrund gestellt haben, so ist keinesfalls zu vernachlässigen, daß der Materialzustand explizit durch Werte modelliert werden muß. Die

3

351 Material und Interaktion

Materialzustand


3.1


strukturellen Informationen sind notwendig, wenn wir überhaupt einen Zustand von Materialien realisieren wollen. Jede Sondierung an einem Material gibt Zustandsinformationen nach außen, die auf der Basis der materialeigenen Werte ermittelt werden. Für den Entwurf sollte die Realisierung des inneren Zustands von den nach außen präsentierten Zustandsinformationen entkoppelt werden. Dieses Geheimnisprinzip wird vorrangig durch die sogenannten Fachwerte (s. Kapitel 3.2.8) realisiert. Jede Veränderung an einem Material wird durch die Veränderung von strukturellen Informationen vollzogen. Wir haben in Kapitel 2.1.5 gesehen, daß Klassen generische Operationen definieren können, mit denen klasseneigene Operationen auf die innere Struktur eines Exemplars dieser Klasse zugreifen. Obwohl es oft nahe liegt und durch verschiedene Entwicklungsumgebungen wie VisualAge unterstützt wird, achten wir bei der Modellierung von Materialien besonders darauf, daß diese generischen Operationen nicht die fachliche Schnittstelle eines Materials ausmachen. Es ist ein typisches Zeichen für ein zu geringes anwendungsfachliches Verständnis, wenn ein Material nur eine solche generische Schnittstelle hat oder nur eine Werteliste liefert und akzeptiert. In diese Richtung gehen auch Materialentwürfe, die »von der Oberfläche her« entwickelt wurden. Dabei wird zunächst ein Werkzeug aus Oberflächenelementen interaktiv

3

352

Generische Operationen


3.1


353

erstellt. In diesen Oberflächenelementen werden dann Informationen des Materials präsentiert und manipulierbar gemacht. Bei solchen Entwürfen wandert die gesamte fachliche Funktionalität und die Integrität des Materials in das Werkzeug und seine Oberfläche, während das Material zu einem Behälter für Wertelisten degeneriert. Beim Entwurf des Pausenplansystems analysieren wir zunächst die vorhandenen Aufgaben und wie sie bisher erledigt werden (s. S. 15). Offenkundig geht der Pausenplanersteller mit verschiedenen Materialien um: Pausenplan, Lehrerkarten, Pausenstatistik. Der Umgang mit diesen Materialien läßt sich fachlich beschreiben. Die vorhandenen Werkzeuge sind elementar. Außer einem Schreibstift und eventuell einem Radierer wird nichts benötigt. Einige Konzepte werden verwendet: Pause, Lehrer, Aufsicht, Vertretung. Die verschiedenen Situationen und Arbeitsschritte sind erkennbar: Der Pausenplan wird neu erstellt; Änderungen müssen im Pausenplan berücksichtigt werden; die Pausenstatistik wird ausgewertet. Daraus ergeben sich bereits einige Orientierungen für den Materialentwurf. Soweit sinnvoll, können die vorhandenen Materialien und ihr fachlicher Umgang übernommen werden. Bei der Analyse der Lehrerkarten und des Konzepts Lehrer wird deutlich, daß die Karten eine spezielle Repräsentation des allgemeinen Konzepts Lehrer sind.

3


3.1


354

Wir überlegen daher, ob nicht eine Klasse Lehrer modelliert wird, deren Exemplare dann über Werkzeuge in ähnlicher Weise repräsentiert werden wie bisher die Lehrerkarten. Offenbar spielt auch der Kartenstapel eine Rolle. Entsprechend könnten wir unmittelbar eine Klasse Kartenstapel oder als allgemeineres Konzept eine Klasse Lehrkšrper als Material entwerfen. Ebenso scheint es sinnvoll, über die Vergegenständlichung der Konzepte Pause, Aufsicht und Vertretung nachzudenken. Einige fachliche Umgangsformen können explizit herausgearbeitet werden. So schaut der Pausenplanersteller auf die Lehrerkarte, um festzustellen, ob der Lehrer für eine bestimmte Pause als Aufsicht einsetzbar ist. Diese Überprüfung, die der Pausenplanersteller bisher im Kopf vornimmt, kann nun an das Material übertragen werden. Die Lehrerkarte oder das Lehrerobjekt kann Auskunft auf die Frage geben, ob es für eine bestimmte Pause einsetzbar ist. Damit entwickeln wir fachliche Umgangsformen am Material, die über die Eigenschaften des bisher vorhandenen Materials hinausgehen.

3


3.1


355

3.1.3 Werkzeugentwurf Zusammenhang von Werkzeug und Material Werkzeugentwurf Arbeitsumgebung


Automat

Werkzeuge präsentieren Materialien und ermöglichen, Materialien auf werkzeugspezifische Art und Weise zu sondieren und zu verändern. Sie stellen spezielle Anforderungen an den Entwurf, da sie, wie wir feststellten, selten ein unmittelbares Urbild in vorhandenen Werkzeugen haben. Wir müssen also zwei Designprobleme lösen: Wir müssen den fachlichen Gehalt oder die Funktionalität eines Werkzeugs festlegen und dem Werkzeug eine Gestalt geben, die dem Medium Software auf z.B. einem grafischen Arbeitsplatzrechner angemessen ist. Offenbar können die beiden Fragen nicht unabhängig voneinander beantwortet werden. Leider sind die Bezüge auch nicht so eindeutig, wie uns das Motto des Bauhauses »Form Follows Function« glauben machen will. Welche Gestalt folgt denn aus der fachlichen Funktiona-

3


3.1


lität eines Kundenberatungswerkzeugs oder eines Werkzeugs für die Pausenplanung? Da wir es mit Software als dem Grundstoff unserer Werkzeuge zu tun haben, gibt es auch wenige »materialbedingte« Restriktionen, die wir zu berücksichtigen hätten. Wir sind also im wesentlichen bei der Gestaltung von Softwarewerkzeugen auf die (wenigen) guten Vorbilder, unsere Einsicht in die Möglichkeiten interaktiver Arbeitsformen und unseren Einfallsreichtum angewiesen. Die anwendungsfachliche Funktionalität eines Werkzeugs erwächst aus der Erfahrung mit immer wiederkehrenden Tätigkeiten. Für jedes neue Werkzeug müssen zunächst diejenigen wiederkehrenden Tätigkeiten identifiziert werden, die als Werkzeugfunktion verkörpert werden sollen. Ziel dabei ist, diese Tätigkeiten durch ein Werkzeug zu vereinfachen, sie aber nicht vollständig zu automatisieren. Somit vergegenständlichen Werkzeuge die algorithmisierbaren, ausgeführten Tätigkeiten. Die Frage stellt sich, was der Unterschied zwischen der Automatisierung einer Tätigkeit und ihrer Unterstützung ist. Ohne dies hier tiefergehend abhandeln zu wollen (vgl. [Gryczan 96]), liegt die Antwort in der Granularität der jeweils modellierten Werkzeugfunktionen. Jede angebotene Funktionalität sollte aus Sicht des Anwenders atomar sein, d.h. sich in keine kleineren Teilfunktionen oder Arbeitshandlun-

3

356

Funktionalität eines Werkzeugs

Automatisierung und Unterstützung


3.1


gen mehr zerlegen lassen. Dies kann nur anwendungsfachlich bestimmt werden und nicht auf der Ebene programmiersprachlicher Ausdrücke. So ist die Bewegung eines Lehrernamens auf dem Pausenplan in ein freies Pausenfeld sicherlich ebenso atomar, wie die Berechnung einer Rendite, nach Eingabe der Kenndaten für eine Lebensversicherung. Dabei spielt es keine Rolle, daß die Bewegung des Lehrernamens programmiertechnisch aufgrund einzelner Veränderungen der Mausposition realisiert wird und daß der Algorithmus zur Renditeberechnung aus Einzelanweisungen besteht. Die vollständige Erstellung eines Pausenplans wird auf der anderen Seite aber wohl ebenso als Automatismus empfunden wie die monatliche Abbuchung der Lebensversicherungsbeiträge durch ein Dauerauftragsprogramm. Zur Erledigung einer Aufgabe werden die jeweils sinnvollen Tätigkeiten miteinander kombiniert. Werkzeuge definieren aber keine Funktionsketten oder Abläufe. Ein Werkzeug wird zwar für eine bestimmte Aufgabe oder Teilaufgabe modelliert. Da die konkreten Arbeitssituationen aber unterschiedlich sein können, kann die genaue Reihenfolge von Arbeitsschritten nicht festgelegt werden. Wir müssen auch darauf achten, daß eine Aufgabe selten »auf einen Sitz« erledigt wird, d.h. ohne Unterbrechungen und Zwischenschritte. Soll ein Werkzeug den Anwender bei einer Tätigkeit unterstützen, müssen wir darauf achten, daß der Anwender darüber entscheiden kann, in wel-

3

357

Werkzeug und Abläufe


3.1


cher Reihenfolge er welche Operation des Werkzeugs aufruft, und wann er seine Arbeit unterbricht. Dies macht die Flexibilität eines Werkzeugs aus. Die Operationen eines Werkzeugs sollten unabhängig voneinander aufzurufen sein. Gibt es zwischen den Operationen eines Werkzeugs logische Abhängigkeiten, so werden diese im softwaretechnischen Modell mit Hilfe des Vertragsmodells ausgedrückt und dem Anwender an der Benutzungsschnittstelle sichtbar gemacht. Offenbar ist es sinnvoll, dem Werkzeug einen vom Material unabhängigen Werkzeug- und Bearbeitungszustand zu geben. So läßt sich durch ein Vertragsmodell realisieren, daß bestimmte Werkzeugfunktionen nicht zu jedem Zeitpunkt auf einem Material ausgeführt werden können. Ein Werkzeug ist für eine Art von Aufgabenerledigung oder Tätigkeit gut und nicht für alles, was im Kontext einer bestimmten Arbeit anfällt. Das gibt schon einen ersten Hinweis über die Größe der zu entwerfenden Werkzeuge. Genauso wie in der Arbeitsorganisation eine Trennung zwischen unterschiedlichen Aufgaben und Tätigkeiten zu erkennen ist, werden Werkzeuge für fachlich überschaubare und konsistente Aufgaben und Tätigkeiten entwickelt. Die Arbeit wird insgesamt durch das Zusammenspiel der verschiedenen Tätigkeiten und Aufgaben erledigt – dabei helfen entsprechend geeignete Werkzeugsammlungen. Werkzeuge werden also nicht als hoch-komplexe Mega-

3

358

Werkzeugzustand

Größe eines Werkzeugs


3.1


tools entworfen, sondern als gut kombinierbare Einzelwerkzeuge. Auch hier kann keine konkrete Angabe darüber gemacht werden, wann ein Werkzeug zu komplex und wann es zu simpel ist. Wir können nur feststellen, daß Werkzeuge, die nur eine fachliche Funktion anbieten, ebenso schlecht konzipiert sind, wie ein Werkzeug, das alleine alle Anforderungen eines komplexen Arbeitsplatzes abdeckt. Wie entwirft man also ein Werkzeug? Wir gehen von den identifizierten Aufgaben und ihrer Erledigung aus. In den verschiedenen Szenarios zeigen sich unterschiedliche Abläufe, in denen die gleichen Materialien auftauchen. Dort wird ja jeweils beschrieben, wie bestimmte Aufgaben erledigt werden. Dabei lassen sich zwischen den verschiedenen Szenarios oft Ähnlichkeiten im Umgang oder gleichartige elementare Handlungen mit Materialien identifizieren. Diese »Überschneidungen« in den an Handlungen und Abläufen orientierten Szenarios bilden die ersten Kristallisationspunkte für Werkzeuge. Wir gruppieren also gleichartige Handlungen an (ähnlichen) Materialien und überlegen, ob sich daraus ein stimmiges Werkzeug entwerfen läßt. Dies ist in Abbildung 3-2 angedeutet.

3

359

Entwurf von Werkzeugen


3.1


360 Abb. 3-2

Szenario C

Von Abläufen zu Werkzeugen

Szenario A

Szenario D

Szenario B

Material X

Kristallisationspunkt für potentielles Werkzeug

3


3.1


Damit haben wir allerdings noch keine Anhaltspunkte über die Gestaltung von Werkzeugen. Diese ergeben sich eher aus der Metapher Werkzeug. Einige allgemeine Gestaltungsmerkmale lassen sich daraus ableiten:

361 Gestaltungsmerkmale eines Werkzeugs

❑ Ein Werkzeug kann immer als solches identifiziert werden. Es

hat einen Namen und eine grafische Repräsentation. Es kann über sein grafisches Symbol aktiviert werden. ❑ Ein Werkzeug zeigt immer eine Sicht auf das gerade bearbeitete Material und gibt unmittelbare Rückkopplung über die Veränderung des Materials. Das Werkzeug verdeckt nie das Material. ❑ Bei der Benutzung bleibt ein Werkzeug selbst »im Blick«, d.h., bei der Bearbeitung des Materials ist immer erkennbar, mit welchem Werkzeug es bearbeitet wird. Der Eindruck, daß das Material direkt, also ohne erkennbares Werkzeug bearbeitet werden kann, wird nur für die Bewegung und Anordnung der Materialien auf einer Arbeitsoberfläche vermittelt. Das entsprechende »Schreibtischwerkzeug« wird meist nur durch den Mauszeiger repräsentiert. ❑ Ein Werkzeug bietet die möglichen Handhabungen an, um das Material unterschiedlich zu bearbeiten. Dabei muß diese fach-

3


3.1


362

liche Funktionalität gegenüber traditionellen Handwerkszeugen meist explizit gemacht werden. Dazu dienen grafische Elemente wie Knöpfe und Regler sowie Einträge in Menüs. ❑ Da ein Werkzeug ein »Gedächtnis« hat und auf bestimmte Materialien und Grundfunktionen eingestellt werden kann, zeigt es besonders die Einstellungen, die die Präsentation des Materials bestimmen. Zudem hat sich eine »Statusanzeige« für Werkzeuge bewährt, die kontextsensitiv entweder anzeigt, was die Aktivierung von Knöpfen und Menüeinträgen bewirkt, oder Auskunft über den »Arbeitsfortschritt« einer Werkzeugfunktion gibt. Abbildung 3-3 zeigt ein einfaches Werkzeug als Schema der Werkzeuggestaltung, aber nicht als exemplarisches Layout.

3


3.1


363 Abb. 3-3

Namen

Beispiel für den schematischen Aufbau Einstellung Materialsicht

graphisches Symbol

Handhabung

Auflister

Wichtig für den Werkzeugentwurf ist, wie Material präsentiert wird und welche Rückmeldungen die Benutzer über ihre Arbeit an Materialien erhalten. Beides ist vorrangig vom jeweiligen Werkzeug bestimmt. Bei der Konstruktion eines Werkzeugs legen wir fest, welche möglichen Zustandsänderungen eines Materials relevant sind und wie sie

3

Materialdarstellung und Rückkopplung


3.1


angezeigt werden. Die inhaltliche Entscheidung darüber fällen wir aus der Sicht der Anwender und der jeweils unterstützten Arbeitstätigkeit. Wir müssen also die Frage beantworten, was ein Anwender sehen will, wenn er ein Material mit einem Werkzeug bearbeitet. Daher ist es so wichtig, die Verwendungszusammenhänge zu verstehen, für die Werkzeuge entworfen werden. Ein häufiges Problem stellt sich, wenn ein Werkzeug initial ohne ein bestimmtes Material gestartet werden soll. Aus der Windows-Tradition hat sich zwar als übliche Arbeitsweise ergeben, daß der Anwender immer zuerst ein Material markiert, um darüber das zugeordnete Werkzeug zu starten. Aber für einen wirklich flexiblen Umgang ist es oft sinnvoll, ein Werkzeug direkt zu starten. Eine schlechte Entwurfsentscheidung ist es, ein solches Werkzeug »leer«, also ohne Material, zu präsentieren. Eine gute Lösung stellt dagegen die Präsentation eines Blankomaterials dar, wenn sich ein »Standard«-Material anbietet. Als Alternative kommt hier ein Auswahldialog in Frage, in dem die für dieses Werkzeug geeigneten Materialien angezeigt werden.

364

Initiale Darstellung eines Werkzeugs

In unserem Pausenplanbeispiel ist der Werkzeugentwurf keine einfache Angelegenheit. Eine simple Übertragung des Bleistifts zur Ausfüllung eines Pausenplans können wir ausschließen. Wir brauchen zunächst ein Werkzeug, das eine Unterstützung bei den verschiedenen

3


3.1


365

Teilaufgaben mit dem Pausenplan bietet. Dazu schauen wir uns in den verschiedenen Szenarios an, bei welchen Aufgaben und Handlungen der Pausenplan benötigt wird. Lehrer müssen Pausen zugeordnet werden. Dabei muß die Liste der verfügbaren Lehrer sichtbar sein. Ein passendes Werkzeug sollte nicht nur einen neuen Pausenplan erstellen, sondern auch Änderungen vornehmen können. Außerdem kann es sinnvoll sein, ein zweites Werkzeug für die Pflege der Lehrerliste oder des Lehrkörpers zu entwerfen. In diesem zweiten Werkzeug sollen dann Ausschlußzeiten, Charakteristika der Arbeitsstelle und potentielle Verantwortlichkeiten einer Lehrperson bearbeitet und angezeigt werden. Dies erscheint uns besser als ein komplexes Werkzeug, das Pausenplanung und Verwaltung des Lehrkörpers gleichzeitig anbietet. Zu klären bleibt noch, wie mit der Pausenstatistik umgegangen werden soll. Wird die Statistik im Werkzeug für die Arbeit am Pausenplan angezeigt oder erledigt dies ein eigenes kleines Werkzeug. Aus den allgemeinen Überlegungen ziehen wir Schlüsse auf die Gestaltung des Werkzeugs für die Arbeit mit dem Pausenplan. Das Werkzeug, wir nennen es Pausenplaner, soll weitgehend unauffällig sein – so wie wir beim Eintragen eines Lehrernamens nicht bewußt darauf achten, daß wir einen Bleistift in der Hand haben. Andererseits ist die einfache Abbildung des Schreibvorgangs auf dem Pausenplan eine mangelnde Nutzung der technischen Möglichkeiten. Der Lehr-

3


3.1


366

Abb. 3-4 Entwurf des Werkzeugs Pausenplaner

planersteller soll schon beim »Hin- und Herschieben« von Lehrernamen auf Pausenfeldern merken, ob eine solche Belegung potentiell möglich oder konfliktbehaftet ist. Hier merken wir wieder, daß Werkzeuge und Materialien mehr an Funktionalität anbieten, als dies mit vorhandenen Arbeitsformen möglich war. Abbildung 3-4 zeigt einen ersten Entwurf des Pausenplaners, der die gerade skizzierte Funktionalität umfaßt. Links ist die Lehrerliste erkennbar, rechts der Pausenplan für die Woche. Ein Lehrer, Heinz Zuellighoven, ist in der Liste markiert. Für die Belegung relevante

3


3.1


367

Kenndaten zeigt das Lehrerinfo-Feld. Im Pausenplan sind bereits zwei Pausen für Montag und Dienstag mit einer Aufsichtsperson belegt. An der Farbe des Kürzels ist zu erkennen, ob die Belegung konfliktbehaftet (im Original rot) ist oder nicht. Die Punkte in den Pausenfeldern beziehen sich auf die aktuell gewählte Lehrperson und signalisieren ebenfalls durch ihre Farbe, für welche potentielle Belegung Konflikte bestehen. Die eigentliche Arbeit mit dem Pausenplaner erfolgt direkt mit der Maus. Ein Lehrer wird markiert, der Mauszeiger wird durch das Kürzel der Person repräsentiert, und durch Mausklick kann ein entsprechendes Pausenfeld belegt werden. Bewegt sich der Mauszeiger über einem Pausenfeld zeigt dieses durch roten oder grünen Hintergrund an, ob die Pause noch mit (weiteren) Aufsichtspersonen belegt werden muß oder nicht. Schließlich müssen wir unseren Werkzeugentwurf noch mit den Materialien abstimmen. Wir prüfen, ob der Pausenplan und das Lehrerobjekt bereits die sondierenden und verändernden Umgangsformen besitzen, die wir im Werkzeug benötigen. Dazu gehört die sondierende Frage nach dem Kürzel am Lehrerobjekt ebenso wie eine Liste der Ausschlußzeiten für Pausenaufsicht. Wir fassen alle Umgangsformen, die ein Werkzeug wie der Pausenplaner von einem Material wie dem Lehrerobjekt erwartet, zu einem Aspekt (z.B. DurchPausenplanerBearbeitbar) zusammen.

3


3.1


368

3.1.4 Arbeitsumgebung Zusammenhang von Werkzeug und Material Werkzeugentwurf Arbeitsumgebung


Automat

Werkzeuge und Materialien treten nicht isoliert auf; sie werden in einer Arbeitsumgebung eingesetzt und liegen dort bereit. Die Arbeitsumgebung realisiert einen für Softwaresysteme angemessenen Ortsbegriff und stellt gleichzeitig eine konzeptionelle Hülle für die Organisation von Arbeit dar. Schaffe einen bestimmten Ort, an dem Menschen arbeiten können. Sie müssen sich an diesem Ort ihre Arbeitsumgebung und ihren Arbeitsplatz einrichten können. Dort sollen sie ihre Arbeit organisieren, indem sie die dazu benötigten Gegenstände in der Arbeitsumgebung zurechtlegen, ordnen und an geeigneten Orten aufbewahren können. Die räumliche Orientierung spielt dabei eine große Rolle. Softwaresysteme besitzen keinen physikalischen Begriff von Raum. Somit fehlt

3

Problem


3.1


369

ihnen eine zentrale Kategorie, welche von Menschen zur Strukturierung ihres Arbeitsplatzes eingesetzt wird. Übertrage die Metapher der Arbeitsumgebung auf Anwendungssoftware. Benutzer bearbeiten bei der Erledigung der ihnen übertragenen Aufgaben verschiedene Materialien mit unterschiedlichen Werkzeugen. Diese Werkzeuge und Materialien müssen ihren Ort haben, meist ist es der persönliche Arbeitsplatz. Auch wenn kein individueller Arbeitsplatz verfügbar ist, müssen die Arbeitsgegenstände und Arbeitsmittel abgelegt, aufgenommen und gefunden werden. Als Metapher beschreibt die Arbeitsumgebung den Ort, an dem Werkzeuge und Materialien ihren Platz haben. Wir müssen in der Lage sein, diesen Ort entsprechend unseren Aufgaben, Ordnungsprinzipien und Gewohnheiten einzurichten. Dabei ist neben der räumlichen Anordnung oft sowohl eine Abgrenzung als auch eine konzeptionelle Ordnung in der Arbeitsumgebung vorhanden. Die Arbeitsumgebung muß damit eine konzeptionelle Einheit sein. Wir sprechen oft von »unserer« Arbeitsumgebung. Damit müssen in einer Umgebung die Dinge repräsentiert werden, die zur Arbeit einer Person oder einer Gruppe gehören. Eine Arbeitsumgebung ist kein all-

3

Kontext

Arbeitsumgebung als Ort

Arbeitsumgebung als konzeptionelle Einheit


3.1


gemein zugänglicher Ort und sollte damit gegen den freien Zugang von außen geschützt sein. Eine Umgebung hilft uns, die Arbeit zu organisieren. Wir legen Dinge, die wir als nächstes erledigen wollen, auf einen Stapel, während ein zweiter Stapel die nicht so dringenden Unterlagen enthält. Ähnlich legen wir uns die Werkzeuge zurecht. Die Organisation von Werkzeugen, Materialien und anderen für die Erledigung von Aufgaben notwendigen Gegenständen ist wichtiger Bestandteil qualifizierter menschlicher Arbeitstätigkeit und muß individuell möglich sein. Die Merkmale der Organisation von Arbeit sollen in angemessener Form auf interaktive Anwendungssysteme übertragen werden. Darüber hinaus ist die Arbeitsumgebung der Ort für Zusammenarbeit. Wir legen Dinge für andere bereit. In Ablagen und Postfächern finden wir Unterlagen vor, die wir weiterbearbeiten sollen. Auch diese Ansätze der Unterstützung von Kooperation wollen wir auf Anwendungssoftware übertragen. Die grundlegenden Kategorien des Ortes und der räumlichen Anordnung sind in Software nicht unmittelbar nachzuvollziehen. Dort haben wir mit den Namensräumen nur ein abstraktes Konzept zur Verfügung, das zudem technisch motiviert ist. Entsprechend hatten und haben traditionelle Anwendungssysteme auf Großrechnern kein Raumkonzept. Der Anwender gibt einen Befehl mit Hilfe von Menüs

3

370 Organisieren von Arbeit

Ort für Zusammenarbeit

Darstellungsprobleme


3.1


371

oder Kommandozeilen ein und erhält als Antwort Daten in Maskenoder Tabellenform. Erst mit einem hierarchischen Dateisystem wie im Unix-Betriebssystem konnte der Anwender sich eigene Ordnungen schaffen, auch wenn diese als abstrakte Bäume realisiert und repräsentiert werden. Grafische Anwendungssysteme ermöglichen, Arbeitsumgebungen annähernd so zu modellieren, daß sie einem intuitiven Anwendungsmodell entsprechen. Der elektronische Schreibtisch oder »Desktop« mit seinen grafischen Symbolen war hier ein entscheidender Schritt. Dinge konnten außer durch ihren expliziten Namen durch Zeigehandlungen mit der Maus angeordnet und identifiziert werden. Trotzdem haben grafische Benutzungsoberflächen so viele Restriktionen gegenüber einer normalen Arbeitsumgebung, daß wir sie nicht »naiv« unmittelbar abbilden können. Dem stehen schon die meist fehlende dritte Dimension, die geringe Größe der Arbeitsfläche und die schlechte Auflösung entgegen. Wir müssen also Gestaltungsrichtlinien finden, die eine Realisierung des Umgebungskonzeptes ermöglichen und gleichzeitig dem Medium Software auf heutigen Arbeitsplatzrechnern und PCs entsprechen. Aktuell bleibt die Gestaltung normaler elektronischer Schreibtische meist hinter den Möglichkeiten zurück. Selten werden Arbeitsgegenstände und -mittel gleichwertig dargestellt. Oft herrscht die klas-

3


3.1


372

sische Smalltalk-Handhabung »Objekt – Aktion« vor, d.h. wir wählen ein Objekt aus und aktivieren dann eine der daran angebotenen Aktionen. Der Ortsbegriff ist in vielen Systemen ebenfalls durchgängig rudimentär: eine Schreibtischoberfläche mit Mappen oder anderen recht generischen Behältern. Die Mappen sind meist ähnlich wie Verzeichnisstrukturen beliebig rekursiv schachtelbar. Eine Unterscheidung in den individuellen Arbeitsplatz und allgemein zugängliche Orte wird nur implizit getroffen. Diese Begrenzungen wollen wir für Anwendungssoftware nach dem WAM-Ansatz schrittweise überwinden. Modelliere eine explizite personalisierbare Arbeitsumgebung, in der Werkzeuge, Materialien und die anderen zur Erledigung der anstehenden Arbeitsaufgaben notwendigen Gegenstände ihren Platz haben. Repräsentiere in der Arbeitsumgebung ein anwendungsfachlich motiviertes Raumkonzept, das auch eine konzeptionelle Einheit gegenüber dem Systemkontext darstellt. Die Arbeitsumgebung definiert die zur Organisation von Werkzeugen und Materialien verwendbaren räumlichen und logischen Dimensionen. Sie erfüllt folgende Anforderungen:

Lösung

Anforderungen an eine ❑ Eine Arbeitsumgebung muß angemessen umsetzen, wie Men-

Arbeitsumgebung

schen die verschiedenen räumlichen Organisationsformen wahrnehmen. Dazu gehört, daß wir Gegenstände ohne zeitliche

3


3.1


373

Verzögerung bearbeiten können und daß die Effekte unmittelbar sichtbar sind. Eine Arbeitsumgebung stellt dafür die notwendigen Mechanismen bereit und verwaltet die enthaltenen Komponenten vom Start bis zur Beendigung der Anwendung. ❑ Eine Arbeitsumgebung gruppiert Werkzeuge, Materialien und

Automaten zu einer Einheit, die sinnvolle Erledigung der Aufgaben im jeweiligen Einsatzkontext ermöglicht. Eine Arbeitsumgebung ist entsprechend individualisierbar. Sie kann z.B. personen-, rollen- oder gruppenbezogen sein. ❑ Die logischen Ordnungsprinzipien einer Arbeitsumgebung

werden explizit verkörpert. Die Umgebung sichert die dadurch entstehenden Konsistenzbedingungen zwischen den Werkzeugen und Materialien. ❑ Die Einheit einer Arbeitsumgebung wird gewahrt, indem die

Umgebung den Zugriff und die Sichtbarkeit von außen reguliert. ❑ Soweit dies erforderlich ist, muß die Arbeitsumgebung die ver-

schiedenen Formen der Kooperation anbieten und vergegenständlichen.

3


3.1


374

Der erste gerade genannte Punkt ist wesentlich: Die Arbeitsumgebung ist der Ort, an dem unmittelbar gearbeitet wird. Alles, was eine Fachkraft in der Arbeitsumgebung mit Werkzeugen und Materialien tut, soll direkt Wirkung zeigen und erkennbar sein. Wir müssen also ein Rückkopplungsproblem lösen, das in Kapitel 3.2.3 aufgegriffen wird. Für das Benutzungsmodell gilt, daß nur solche Aktionen unmittelbare Wirkung haben, die sich auf die Gegenstände innerhalb einer Arbeitsumgebung beziehen. Der Benutzer soll sich ein Bild davon machen, was »innerhalb« und »außerhalb« bedeutet. Als Beispiel nehmen wir wieder einen Bankberaterarbeitsplatz. Dort kann ein Formular direkt ausgefüllt und bearbeitet werden, da es innerhalb der Arbeitsumgebung ist. Die Neuanlage eines Kontos ist aber etwas, was außerhalb stattfindet. Der Berater wird sich nur über entsprechende Werkzeuge ein Bild davon machen, ob ein Konto bereits angelegt ist oder nicht. Er soll aber nie den Eindruck erhalten, daß er ein Konto »auf seinem Arbeitsplatz« hat, da sich dieses Modell technisch und fachlich nicht aufrechterhalten läßt. Bei der Realisierung des Raumbegriffes fällt uns oft die bekannte Schreibtischmetapher ein. Werkzeuge und Materialien werden als Piktogramme oder Präsentationssymbole (Icons) dargestellt und durch direkte Manipulation, also durch Zeigehandlungen, in räumliche

3

Realisierung des Raumbegriffs


3.1


Beziehungen gesetzt und ergriffen, d.h. aktiviert. Der Schreibtisch wird durch eine Arbeitsfläche repräsentiert, die den Ort für Werkzeuge und Materialien in einer der menschlichen Wahrnehmung angemessenen Präsentation bietet. Bei der Konstruktion ist darauf zu achten, daß der Schreibtisch für den Anwender zwar die Arbeitsumgebung visualisiert, er aber nicht mit der Umgebung gleichzusetzen ist. Ein elektronischer Schreibtisch kann heutzutage im Softwareentwurf weitgehend von vorhandener Systemsoftware übernommen werden. Unsere Erwartung, einen Schreibtisch am nächsten Tag so vorzufinden, wie wir ihn am Vorabend verlassen haben, gilt auch bei Beendigung und Neustart eines Anwendungssystems. Die Arbeitsumgebung ist dafür zuständig, diesen Zustand zu sichern und wiederherzustellen. Das konkrete Sichern und Erzeugen von Werkzeugen, Materialien und Automaten kann sie dabei an eigene Komponenten (wie die Materialverwaltung) delegieren. Aus technischer Sicht ist es ebenfalls sinnvoll, das Starten und Beenden einzelner Werkzeuge oder Automaten über die Umgebung zu verwalten. Der elektronische Schreibtisch ist nicht die einzige denkbare Form der Repräsentation einer Arbeitsumgebung und der darin angeordneten Gegenstände. Wenn potentiell viele Materialien und unterschiedliche Werkzeuge bereitliegen müssen, ist eine Strukturierung der

3

375

Sichern des Arbeitszustandes


3.1


Arbeitsumgebung nützlich. Hier haben wir gute Erfahrungen mit Werkzeugkisten und Material- oder Aktenschränken gesammelt. Darüber hinaus geht das Konzept der vielfältigen Arbeitskontexte, die insgesamt vom Benutzer eingerichtet und dann gewechselt werden können. Eine mögliche Realisierung sind die virtuellen Schreibtischoberflächen, die von Unix-Fenstersystemen wie Fvwm angeboten werden. Hier wird das Bild von mehreren wechselbaren Schreibtischoberflächen erzeugt. Ein anderes Konzept ist der Arbeitskontext, der vom Benutzer explizit für jeden neuen Geschäftsprozeß gestartet, benannt und dann auch wieder gewechselt werden kann. In diesem Fall definiert etwa ein Versicherungsangestellter für die Bearbeitung einer Kundenakte einen neuen Arbeitskontext mit diesem Kundennamen. Muß er seine Arbeit an diesem Vorgang beispielsweise durch den Anruf eines anderen Kunden unterbrechen, kann er diesen Kontext mit allen inzwischen benutzten Werkzeugen und Materialien »beiseite legen«, um während des Kundengesprächs in einem neuen Kontext die gewünschten Werkzeuge und Materialien zu benutzen. Hinterher kann der Versicherungsangestellte den zweiten Kontext abschließen und den beiseite gelegten wieder vornehmen. Zulässige Handlungen an und mit Gegenständen in einer Arbeitsumgebung müssen unmittelbar sein: Sie können direkt ausgeführt werden und zeigen sofort einen Effekt. Der Anwender muß also erken-

3

376 Arbeitskontexte

Unmittelbarkeit


3.1


377

nen können, welche Werkzeuge und Materialien in der Arbeitsumgebung sind und diese dann auch ohne weiteren »Zugriffsschutz« benutzen können. Bei der Arbeit in einer Umgebung muß der unmittelbare Wechsel zwischen verschiedenen Werkzeugen möglich sein. Ebenso sind Effekte, die ein Werkzeug an einem Material bewirkt, sofort über ein zweites Werkzeug feststellbar, das auf demselben Material arbeitet. Eine Arbeitsumgebung bezieht sich immer auf den jeweiligen Einsatzkontext. Dieser ist spezifischer als der allgemeine Anwendungsbereich (s. Kapitel 2.5.1). Denn hier sind die Aufgaben und Arbeitssituationen entscheidend, für die diese Umgebung konzipiert ist. Wir gehen entsprechend davon aus, daß es innerhalb eines Anwendungsbereichs unterschiedliche Arbeitsumgebungen gibt, die sich vor allem in ihrer Zusammenstellung von Werkzeugen, Materialien und Automaten unterscheiden. Den Charakter der Arbeitsumgebung bestimmt damit der jeweilige Ausschnitt des Anwendungsbereichs, der unterstützt werden soll und der gewählte Arbeitsplatztyp, der vom gewählten Leitbild abhängt (s. Kapitel 2.2.3). Mit den unterschiedlichen Arbeitsumgebungen stellt sich auch die Frage der Individualisierbarkeit. In vielen Anwendungsbereichen ist es fachlich notwendig, daß sich der Anwender als Person gegenüber dem System identifiziert oder legitimiert. Im WAM-Ansatz führt das viel-

3

Realisierung des Einsatzkontexts

Individualisierbarkeit der Arbeitsumgebung


3.1


378

fach zu einer persönlichen Arbeitsumgebung, die dem Anwender bei jedem Systemstart die letzte oder die gewünschte Zusammenstellung von Arbeitsmitteln und -gegenständen bietet. In vielen Fällen ist darüber hinaus der Funktionsumfang eines Werkzeugs abhängig vom Anwender. Dabei ist dort dann nicht die Person, sondern meist nur die funktionelle Rolle (vgl. [Floyd 97]), die jeweils eingenommen wird, ausschlaggebend. Für beide Konstruktionsaufgaben ist die Umgebung die geeignete Lösung. Hier meldet sich der Anwender an und ab, und hier können die Werkzeuge bei ihrer Erzeugung den Berechtigungsstatus eines Anwenders abfragen. Wenn das grundlegende Modell der Benutzeridentifikation einmal bei der Umgebung realisiert worden ist, dann lassen sich weitergehende Konzepte wie Benutzergruppen, die bei der Unterstützung kooperativer Arbeit (s. Kapitel 4.1) sinnvoll sind, auf dieser Basis realisieren. Wenn wir einen Arbeitsplatztyp wählen, in dem eine explizite Arbeitsumgebung modelliert ist, hat das Auswirkungen auf das Benutzungsmodell. Denn ebensowenig wie der Raum, in dem Arbeit verrichtet wird, die Reihenfolge der Arbeitsschritte oder der zu benutzenden Gegenstände festlegt, so wenig macht die Arbeitsumgebung Vorgaben für Handlungsreihenfolgen innerhalb von Arbeitsprozessen.

3


3.1


In einer traditionellen Arbeitsumgebung achten wir darauf, wo bestimmte Dinge hingehören und wie sie zusammen passen. Diese Ordnungsprinzipien machen wir bei der Übertragung in Anwendungssoftware explizit. Dies erleichtert dem Anwender den Umgang mit der Umgebung. Ein einfacher Mechanismus ist das »Aufräumen«. Wenn wir eine Grundordnung für eine Arbeitsumgebung vorgeben können, die auch benutzerdefiniert sein kann, so schafft das Übersicht in komplexen und »beladenen« Arbeitsumgebungen. Dazu ist es auch notwendig, daß der Benutzer die Umgebung in ihrer Anordnung speichern und wiederherstellen kann. Zu den elementaren Ordnungsprinzipien gehört auch, daß die Gegenstände in einer Arbeitsumgebung bekannt sind. Wenn der Benutzer ein Material »verlegt« hat, kann er über die Umgebung danach suchen. Verzeichnisse der Materialien und Werkzeuge, die in einem bestimmten Zeitraum benutzt wurden, zählen ebenso zu den Ordnungsprinzipien. Die meisten darüber hinausgehenden Organisationsarbeiten werden allerdings nicht durch direkte Manipulation in der Arbeitsumgebung, sondern mit Hilfe spezifischer Werkzeuge ausgeführt. So werden Unterlagen in einer Kundenakte mit einem Kundenaktenwerkzeug bearbeitet. Mit einem solchen Werkzeug können wir komplexere Konsistenzbedingungen prüfen und für den Benutzer verständlich dar-

3

379 Realisierung von Ordnungsprinzipien

Konsistenzprüfungen


3.1


stellen. So stellen wir aus dem Zusammenspiel des Werkzeugs mit den Materialien sicher, daß ein Kreditvertrag nach Gegenzeichnung in einem anderen Register liegt als vorher und daß nur auf Kopien eines Vertrages in einem weiteren Register noch Änderungen vorgenommen werden können. Werkzeuge sind nur für bestimmte Materialien geeignet und umgekehrt. In einer Umgebung muß erkennbar sein, welche Werkzeuge und Materialien zueinander passen. Auch wenn dies technisch von der Umgebung an entsprechende Verwalter oder etwa an das fragliche Werkzeug delegiert wird, sollte das Benutzungsmodell der Arbeitsumgebung dieses Zusammenpassen enthalten. Üblich ist der Darstellungswechel des grafischen Symbols, wenn z.B. ein Material auf ein Werkzeug bewegt wird und von diesem bearbeitet werden kann. Ähnlich verhält es sich mit Materialien und Behältern. Nicht jedes Material soll in jeden Behälter kommen. Auch müssen Behälter nicht beliebig schachtelbar sein. Wenn wir schon die Unterscheidung von Aktenordner und Aktenschrank in einer Umgebung realisiert haben, dann macht es wenig Sinn, daß ein Aktenschrank in einen Aktenordner gesteckt werden kann, statt umgekehrt. Ein anspruchsvolles Ordnungs- oder eigentlich schon Konsistenzkonzept ist der aktuelle Arbeitsgegenstand. Der aktuelle Arbeitsgegenstand ist immer umgebungslokal und fachlich motiviert. Dies kann

3

380

Aktueller Arbeitsgegenstand


3.1


beispielsweise der Kunde sein, den ein Bankmitarbeiter bearbeitet. Obwohl verschiedene Werkzeuge durchaus unterschiedliche Materialien in Arbeit haben, ist dieser aktuelle Arbeitsgegenstand in der Umgebung bekannt. Das kann durch einen expliziten Operationsaufruf bei der Umgebung (»setze aktuellen Kunden«) oder über ein ausgewiesenes Werkzeug (»der Kundensucher«) geschehen. Gibt es in einer Arbeitsumgebung einen solchen aktuellen Arbeitsgegenstand, dann können wir in den verschiedenen Werkzeugen Operationen wie »übernimm aktuelle Daten« realisieren. Damit kann ein Formulareditor z.B. Namen, Kundennummer und Anschrift eines Kunden in ein Formular eintragen, ohne daß eine weitere explizite Handlung des Benutzers erforderlich ist. Schließlich gibt es für bestimmte Arbeitssituationen Konsistenzbedingungen, die sich nicht mehr auf der Ebene eines Werkzeugs oder eines Materials formulieren lassen. So ist die Arbeit an einem Kreditvertrag nicht dadurch wirklich abgeschlossen, daß der Anwender ein entsprechendes Softwareformular mit dem geeigneten Werkzeug ausgefüllt und elektronisch unterschrieben hat. Juristische Wirksamkeit erlangt der Vorgang erst, wenn die Vertragsdaten vom Arbeitsplatzsystem in die operativen Datenbestände des Großrechners übertragen worden und dort akzeptiert sind. Um daraus ein stimmiges Benutzungsmodell zu machen, hilft uns die Arbeitsumgebung. Sie kann Ver-

3

381

Vorgangsprüfung


3.1


tragseditoren, Kundenakten, Postausgangskorb und den Automaten für die Hostkommunikation so miteinander verknüpfen, daß der Anwender ein anwendungsfachliches Bild über den Zustand eines Vertragsabschlusses hat und erkennt, daß aufgrund von Übertragungsproblemen der Vertrag zwar schon vollständig bearbeitet, aber noch nicht formal akzeptiert worden ist. Dieses Beispiel illustriert ein allgemeines Prinzip für die Prüfung von Konsistenzen: Die Konsistenzprüfung geschieht »von innen nach außen« und jeweils lokal zum jeweiligen Kontext. So werden zunächst die einzelnen fachlichen Daten kontextfrei als Fachwerte (s. Kapitel 3.2.8) geprüft. Dann werden die Fachwerte in ihrem Zusammenspiel innerhalb und von einem Dokument kontrolliert. Daran anschließend untersucht das Werkzeug, ob ein Dokument in der aktuellen Arbeitssituation von der Kundenakte aufgenommen werden kann. Der gesamte Arbeitszusammenhang wird dann über die Umgebung abgesichert. Diese ist aber wiederum von der Konsistenzprüfung im Großrechner abhängig. So wird in jedem Kontext geprüft, was dort prüfbar ist; alle darüber hinausgehenden Prüfungen werden »nach oben« delegiert. Daraus folgt für ein sicheres Benutzungsmodell, daß der Anwender diese geschachtelten Kontexte nachvollziehen muß, damit er versteht, welche Reaktion wo und wann zu erwarten ist. Wir kommen dieser Forderung dadurch nach, daß wir die verschiedenen Kontexte als

3

382

Prinzip der Konsistenzprüfung


3.1


383

Werkzeuge und Materialien vergegenständlichen und indem wir einen Ortsbegriff als Arbeitsumgebung realisieren. Die Arbeitsumgebung stellt immer eine äußere Hülle dar und schirmt die verwendeten Werkzeuge und Materialien nach außen hin ab. Damit sind diese Gegenstände vor externem Zugriff und äußerer Sicht geschützt. Was außen und was innen ist, wird durch die Art der Arbeitsumgebung bestimmt. Der individuelle Arbeitsplatz ist gegenüber allen anderen Arbeitsplätzen und Anwendern geschützt. Damit ist die Arbeitsumgebung eine fachliche Interpretation eines Namensraums. Entsprechend gelten die bekannten Schutz- und Kapselungsmechanismen: Gegenstände in einer Arbeitsumgebung sind nicht einfach von außen sichtbar und zugänglich. Technisch hat dies die Konsequenz, daß die meisten Arbeitsplätze sequentiell oder sogar als Einprozeßsysteme realisiert werden können. Unabhängig von dieser technischen Lösung gibt es generell keinen Zugriff auf ein Material etwa durch ein Werkzeug aus einer anderen Umgebung. Der Wechsel eines Gegenstandes von einer Arbeitsumgebung in eine andere wird immer durch eine explizite Aktion oder Operation bewerkstelligt. Sind Arbeitsplätze nicht nur als reine Einzelplatzsysteme angelegt, dann kann die Kapselung nicht vollständig sein. Vergleichbar mit den

3

Realisierung der Kapselung

Kapselung und Datenaustausch


3.1


384

Export- und Importschnittstellen eines Moduls schaffen wir dann definierte Aus- und Eingänge für Arbeitsplätze und -umgebungen, die sie mit der Außenwelt verbinden. Vielfach verwenden wir Automaten, um die Anschlüsse an technisch anders geartete Systemkomponenten wie etwa einen Großrechner zu realisieren. Diese Form der Öffnung nach »außen« geht im Benutzungsmodell nicht über ein Einzelplatzsystem hinaus, weil der Anwender nur implizit über Daten mit anderen kooperieren kann. Ein explizit erweitertes Raumkonzept oder Kooperationsmodell ist noch nicht vorhanden. Wenn der Austausch mit anderen Arbeitsumgebungen oder die Sicht auf andere Arbeitsplätze nicht nur Bestandteil der Arbeit, sondern auch expliziter Teil des Anwendungssystems ist, dann müssen wir uns Gedanken über passende Benutzungsmodelle machen. Heute werden wir in den meisten Fällen zumindest einfache Kooperations- und damit verbundene Koordinationsmechanismen in Anwendungssystemen vorsehen müssen. Solche Konzepte zur Kooperation und Koordination, die den Umgebungsbegriff verändern, sind Postkörbe oder gemeinsame Materialsammlungen und -ablagen. Mit Einführung der Raummetapher wird der Umgebungsbegriff dann qualitativ ausgeweitet. Gemeinsam zugängliche Räume und Arbeitsumgebungen entstehen. Da hier nur

3

Realisierung von Kooperation


3.1


385

begrenzte praktische Erfahrungen und Konzepte vorliegen, wollen wir dies an dieser Stelle nicht weiter behandeln. Die damit verbundenen Fragen werden detaillierter in Kapitel 4.1 angesprochen. Die Arbeitsumgebung eines Pausenplanerstellers ist auf den ersten Blick einfach strukturiert: ein aktueller Pausenplan, der Lehrkörper, eventuell einzelne Lehrerkarten und die beiden Werkzeuge für die Pausenplanung und die Bearbeitung der Lehrerkarten. Dazu kommt noch das Archiv, in dem alte Pausenpläne, Statistiken und Lehrerkarten aufgehoben werden können, und der Papierkorb. Alle Gegenstände sind auf einer Arbeitsfläche als grafische Symbole repräsentiert. Abbildung 3-5 zeigt den Prototyp der Arbeitsumgebung des Pausenplanerstellers mit zwei aktiven Werkzeugen. Diese Arbeitsumgebung unterscheidet sich von der Umgebung im Schulsekretariat, wo Lehr- und Stundenpläne verwaltet werden und potentielle Konflikte mit der Pausenplanung identifiziert werden sollen. Elementare Ordnungen sind dadurch eingeführt, daß Lehrerkarten nur auf den Schreibtisch, in den Lehrkörper, ins Archiv oder in den Papierkorb gelegt werden können. Sie sind mit dem Lehrkörperwerkzeug und dem Drucker zu bearbeiten, nicht aber unmittelbar mit dem Pausenplaner. Dagegen ist der Lehrkörper ein Material, das für alle Werkzeuge geeignet ist. Lehrkörper lassen sich aber nicht ineinander schachteln. Es gibt nur »alte« und »aktuelle« Lehrkörper.

3


3.1


386 Abb. 3-5 Die Arbeitsumgebung des Pausenplanerstellers

Die Konsistenz in der Arbeit mit den Werkzeugen zeigt sich daran, daß die Änderungen am Lehrkörper, die im Lehrkörperwerkzeug vorgenommen werden, unmittelbar im Pausenplaner sichtbar sind, falls dort der entsprechende Ausschnitt des Materials Lehrkörper gezeigt wird. Ob ein Pausenplan konsistent ist oder nicht, zeigt nur der Pausenplaner an. Er prüft dies anhand des Pausenplans, der aber eine kon3


3.1


387

fliktäre Belegung zuläßt. Das Werkzeug wiederum stellt sicher, daß keine Lehrer in den Pausenplan eingetragen werden können, die nicht im Lehrerkollegium sind. Ob aber ein Pausenplan bereits in der aktuellen Fassung archiviert ist oder nicht, stellt der Anwender erst fest, wenn er versucht, einen Pausenplan ins Archiv zu legen. Da das Archiv als Datenbank realisiert ist, haben wird sie als externe Komponente nicht in die laufenden Konsistenzprüfungen der Arbeitsumgebung einbezogen.

3.1.5 Behälter Zusammenhang von Werkzeug und Material Werkzeugentwurf Arbeitsumgebung


Automat

Mit der Möglichkeit, Werkzeuge und Materialien in Softwaresystemen zu repräsentieren, kommt die Forderung auf, diese Gegenstände auch zu verwahren und zu ordnen. Diese Ordnungen sollen beim Transport der Gegenstände erhalten bleiben. Behälter sind fachliche Sammlungen und Aufbewahrungsgegenstände für Materialien und Werkzeuge.

3


3.1


Schaffe einen Gegenstand, in dem Materialien von einem Ort zum anderen bewegt werden können. Sie müssen abgelegt und wieder aufgenommen werden können. Oftmals müssen Sammlungen von gleichartigen oder zusammengehörigen Materialien bearbeitet oder bewegt werden. Diese Sammlungen sind anwendungsfachlich und nicht rein technisch motiviert. Sie haben andere Umgangsformen als die der softwaretechnischen Datentypen. Übertrage die Metapher des Behälters auf Anwendungssoftware. Das Aufbewahren von Materialien gehört zu den elementaren menschlichen Tätigkeiten ebenso wie das Sammeln. Dazu dienen Behälter, für die wir eine entsprechende Entwurfsmetapher eingeführt haben. Wichtig ist, daß Behälter anwendungsfachlich motiviert und als eigenständige Gegenstände Teil des Benutzungsmodells sind. Fachliche Behälter stehen im WAM-Ansatz an der Grenze zwischen Materialien und Werkzeuge oder Automaten. Sie werden bearbeitet, was sie zum Material macht; sie bearbeiten andere Gegenstände im Sinne von verwalten, sondieren, kontrollieren und erstellen, was sie in die Nähe von Werkzeugen und Automaten bringt. Konzeptionell und konstruktiv können Behälter demnach als Material verstanden werden. Generell gehen wir sogar davon aus, daß die meisten komplexeren Werkzeuge auf einem oder mehreren Behäl-

3

388 Problem

Kontext

Behälter und Materialien


3.1


tern arbeiten, um dem Benutzer die Auswahl der gewünschten Materialien zu erleichtern. Andererseits haben Behälter eine Sonderstellung gegenüber »normalen« Materialien, da sie andere Materialien enthalten, diese organisieren und hierzu Operationen der Materialien aufrufen. Hierdurch ergab sich in Projekten immer wieder das Problem, daß Behälter »werkzeugartig« mit entsprechenden Schnittstellen und einem Beobachtermechanismus (s. Kapitel 3.2.3) modelliert wurden. Fachliche Behälter (z.B. eine Kontensammlung) übernehmen in den nach WAM entwickelten Arbeitsplatzsystemen Verwaltungs- und aggregierende Aufgaben wie das Führen von Kontenverzeichnissen oder das Summieren von täglichen Umsatzzahlen. Dadurch entfernten sie sich von den klassischen Datenstrukturen und Collection Classes. Aus der Sicht des Entwicklers müssen die anwendungsfachlich motivierten Behälter von den technischen Datenstrukturen unterschieden werden. Für den Entwickler sind Datenstrukturen typische softwaretechnische »Behälter«, mit denen er in der Programmierung ständig zu tun hat. Listen, Bäume und Hashtabellen sind aus dieser Sicht »fachliche« Behälter, in denen er Daten verwaltet. In der Softwaretechnik wurden Datenstrukturen einerseits funktional als abstrakte Datentypen definiert, anderseits als imperative zusammengesetzte Datentypen einer Programmiersprache gesehen. Erst mit objektorien-

3

389

Behälter und Datenstrukturen


3.1


tierten Sprachen kamen aktive technische Behälter auf, die neben einem gekapselten Zustand mit entsprechenden Zugriffsoperationen ein eigenes Navigationskonzept (mit Operationen wie first und next) über Marker anboten (vgl. Kapitel 3.2.7). Diese technischen Behälter wurden als sogenannte Collection Classes in vielen objektorientierten Anwendungen direkt als Behälter verwendet. Im WAM-Ansatz heben wir demgegenüber die anwendungsfachliche Bedeutung von fachlichen Behältern als eigenständige Arbeitsgegenstände heraus. Wir identifizieren für fachliche Behälter die aus dem Anwendungsbereich motivierten Umgangsformen in Abhängigkeit von den zu erledigenden Aufgaben. Außerdem entwerfen wir anwendungsspezifische Ausprägungen von Behältern und beschränken uns nicht auf ein generisches Mappen- oder Ordnerkonzept. Behälter müssen noch aus einem weiteren Grund explizit modelliert werden. In objektorientierten Sprachen ist im Gegensatz zu relationalen Datenbanken mit der Klasse (hier als Relation oder Tabelle interpretiert) die Sammlung aller Exemplare der Klasse (ihre sog. Extension) gegeben. Dies kann zwar über metasprachliche Eigenschaften, wie sie z.B. Smalltalk bietet, ebenfalls erreicht werden, doch ist das kein fachlich modellierter Mechanismus, den wir nutzen wollen. Es ist ja gerade ein Merkmal des relationalen Modells, daß mit einer Relation, die als Tabelle realisiert wird, auch alle zugehörigen Tupel

3

390

Fachliche Umgangsformen und Spezialisierungen von Behältern


3.1


oder Datensätze angesprochen werden können. Demgegenüber wollen wir anwendungsfachlich die verschiedenen Exemplare einer Klasse an unterschiedlichen Orten aufbewahren. Erst dadurch lassen sich fachliche Konzepte, wie verschiedene Stapel für erledigte und offene Vorgänge oder Anträge, elegant modellieren und in einem Benutzungsmodell repräsentieren. Modelliere fachliche Behälter als explizite Gegenstände, in denen Materialien verwahrt werden können. Behälter können wie andere Materialien durch Werkzeuge bearbeitet werden. Sie haben eigene Umgangsformen zur Verwaltung und Bearbeitung der verwahrten Materialien. Behälter bieten im WAM-Ansatz folgende Dienstleistungen: ❑ In Behältern können Materialien aufbewahrt, gesammelt und

391

Lösung

Dienstleistungen eines Behälters

angeordnet werden. ❑ Ein Behälter kann die aufbewahrten Materialien verwalten

und über die Sammlung fachliche Auskunft geben. ❑ Materialien können mit ihren Behältern an verschiedene Orte

transportiert werden. Damit bieten Behälter den Ansatz zur Kooperation und Koordination.

3


3.1


Behälter vergegenständlichen zunächst Sammlungen von Materialien. Vielfach sind im Anwendungsbereich solche Sammlungen im Gebrauch, und es existieren bereits Behälter in der Form von Mappen, Ordnern, Boxen, Ablagen, Karteien usw. Diese vorhandenen fachlichen Behälter sind gute Kandidaten für entsprechende Komponenten im Anwendungssystem. Allerdings werden auch hier selten die vorhandenen Eigenschaften eines Behälters unmittelbar übertragen, sondern es wird untersucht, welche angemessenen neuen Operationen zu den bewährten Umgangsformen hinzukommen sollen. Wir dürfen nicht vergessen, auch solche Sammlungen zu vergegenständlichen, die konventionell einfach durch Zusammentragen oder -legen entstehen – die Stapel auf unseren Schreibtischen sind dafür ein gutes Beispiel. Wenn wir einen Stapel aktueller Unterlagen modellieren wollen, dann müssen wir dafür eine Klasse Stapel konstruieren, die Objekte vom Typ Unterlage aufbewahren kann. Eine Sammlung folgt immer einem Auswahlprinzip. Wir wissen, was in eine Sammlung gehört und was nicht. Technisch führt das zu der Frage, ob nur gleichartige, ähnliche (im Sinne von Polymorphie) oder verschiedenartige Objekte in einem Behälter verwahrt werden. Es trägt erheblich zum technisch und fachlich sauberen Umgang mit Behältern bei, wenn das Auswahlprinzip explizit vom Behälter geprüft wird und der Benutzer in der Handhabung feststellen kann, ob ein

3

392 Realisierung einer Sammlung

Behälterinhalt


3.1


bestimmtes Objekt in den Behälter »paßt« oder nicht. Die sicherste Lösung ist hier eine entsprechende Typisierung, die auch eingeschränkt polymorph sein kann. Dabei wird eine abstrakte Klasse angegeben, die als Supertyp die minimal erwartete Schnittstelle aller verwahrten Objekte eines Behälters festlegt. Stellen Programmiersprachen dies nicht zur Verfügung, dann muß das Auswahlprinzip dynamisch zur Laufzeit geprüft werden. Der Benutzer kann so bei der direkten Manipulation (z.B. beim Drag & Drop) feststellen, ob ein Objekt in einem Behälter abgelegt werden kann. Polymorphe Behälter haben in stark typisierten Sprachen die für die Benutzung oft unangenehme Eigenschaft, daß die aufbewahrten Objekte aus Sicht des Behälters nur über ihren Supertyp (und damit der entsprechenden abstrakten Oberklasse) bekannt sind. Dies ist für die Verwahrung im Behälter auch sinnvoll. Nur wollen wir mit solchen Objekten meist wieder in ihrer speziellen Form umgehen, wenn wir sie aus diesem Behälter herausgenommen haben. Dies bedeutet z.B., daß ein Ordner von Dokumenten auch Briefe aufnehmen kann, wenn Dokument eine Oberklasse von Brief ist. Der Ordner wird einem Werkzeug dann aber auch nur Objekte vom Typ Dokument herausgeben können. Will das Werkzeug auf Briefen arbeiten, dann muß eine entsprechende Typumwandlung (sogenanntes Downcasting oder Reverse Assignment) vorgenommen werden.

3

393

Polymorphe Behälter


3.1


Behälter verkörpern meist Ordnungen. Nur wenige konventionelle Behälter sind als »Wühlkisten« gedacht, auch wenn sie es im Gebrauch gelegentlich werden. Um diese Gefahr zu bannen, konstruieren wir diese Ordnungen explizit bei den fachlichen Behältern. Ein Behälter kennt also das Ordnungsprinzip, das er verkörpert, und sorgt für seine Einhaltung. Entsprechend werden die verwahrten Objekte bereits beim Einfügen an die richtige Stelle gebracht, die dann auch bei anderen verändernden Operationen erhalten bleibt. Wir sind schon bei der Diskussion der Entwurfsmetapher Behälter darauf eingegangen, daß fachliche Behälter Verwaltungsfunktion haben. Konventionell verwaltet der Benutzer eines Behälters die verwahrten Objekte durch eigene Aktionen und Dokumente manuell. Diese aufwendige und fehleranfällige Verwaltungsarbeit können wir als Merkmale fachlicher Behälter vorsehen. Dazu gehören Inhaltsverzeichnisse ebenso wie Konsistenzprüfungen und Operationen, die sich auf die Sammlung als Ganzes beziehen. Ein Beispiel wäre ein Wertpapierdepot als ein bankfachlicher Behälter, das anhand der aktuellen Aktienkurse den Gesamtwert des Depots berechnet. Einen Schritt weiter in Richtung Verwaltung kombiniert mit Konsistenzwahrung gehen spezialisierte Behälter wie eine Kreditakte. Der Inhalt eines solchen Behälters ist zwar heterogen, aber in engen Grenzen festgelegt. Wir modellieren solche Behälter oft mit Fächern oder

3

394 Ordnungsprinzipien

Realisierung einer Verwaltung

Spezialisierte Behälter


3.1


Laschen, die im Benutzungsmodell verdeutlichen, daß eine bestimmte Zusammenstellung von Dokumenten oder Unterlagen in diesem Behälter verwaltet werden. Diese Festlegung von Inhalten und inneren Konsistenzen ermöglicht, daß eine Reihe von Anfragen an die Inhalte bereits auf der Ebene des Behälters beantwortet werden können. So kann eine Kreditakte Auskunft darüber geben, ob der Kreditvertrag bereits abgeschlossen ist und wie die Fälligkeit aussieht. Ein Behälter bietet sich in der Modellierung auch dort an, wo angeforderte Materialien zusammengestellt und für die Bearbeitung weitergegeben werden sollen. Häufig kommt dies bei Datenbankenanwendungen vor. Der Benutzer will eine Menge von Kunden nach einem bestimmten Auswahlkriterium zusammenstellen. Eine konventionelle Datenbankabfrage führt zu einer Ergebnismenge. Diese muß in einer objektorientierten Welt anwendungsfachlich motiviert vergegenständlicht werden. Oft bietet sich an, diese Ergebnismenge als Sammlung von gleichartigen Materialien in einem bekannten Behälter, etwa einer Mappe, zu realisieren. Das führt zu der weitergehenden Frage, wie nicht-objektorientierte Datenbanken in WAM-Systemen modelliert werden. Wenn wir eine solche Datenbank im wesentlichen nur zur Speicherung von Objekten verwenden, dann bietet sich zur Kapselung ein Automat an (vgl. Kapitel 4.2).

3

395

Realisierung als Transportmedium


3.1


Eine Alternative ist die Modellierung eines Archivs oder einer Materialverwaltung in einem allgemein zugänglichen Raum der Arbeitsumgebung. Sind auf diesen Archiven Anfragen möglich, die zu einer Ergebnismenge führen (»die Menge aller Kunden, die in diesem Jahr das Rentenalter erreichen«), dann besteht eine elegante Lösung darin, diese Ergebnismenge selbst wieder in einem »kleineren« Archiv unterzubringen, auf dem dann wiederum weitere einschränkende Anfragen erfolgen können, falls die Ergebnismenge noch zu unspezifisch oder zu groß ist. Den Transportgesichtspunkt haben wir bisher nur angedeutet. Auf einem Arbeitsplatz spielt er auch eine untergeordnete Rolle. Natürlich ist es günstig, eine Materialsammlung als Ganzes in einem Behälter hin und her bewegen zu können. Wichtiger ist dieser Gesichtspunkt, wenn Sammlungen zwischen verschiedenen Räumen einer Umgebung oder zwischen verschiedenen Arbeitsumgebungen transportiert werden sollen. Dann sind Behälter die »natürlichen« Transportmedien, die die Alltagserfahrung mit Gittermappen und Versandtaschen oder Containern nachbilden (s. Kapitel 4.1.2 und 4.1.3). Diese Transportbehälter bieten sich auch an, wenn es um die Koordination von Arbeitsteilung geht. Wenn wir Unterlagen auf den Schreibtisch eines Kollegen legen, dann ist damit vielfach klar, was zu tun ist,

3

396 Archiv und Materialverwaltung

Materialtransport


3.1


397

und wer im Moment die Verantwortung für die Erledigung der Aufgabe hat. Aus unserem Pausenplanbeispiel haben wir in Abbildung 3-6 drei Behälter aufgelistet: den Lehrkörper, den Papierkorb und das Archiv. Alle drei entsprechen nur ansatzweise den herkömmlichen Behältern. Der Lehrkörper ist eine vergegenständlichte Abstraktion. Er enthält zunächst die Sammlung der sog. Lehrerkarten, übt aber auch bestimmte Verwaltungsfunktionen aus. So lassen sich Lehrer suchen und Fragen nach freien Kapazitäten beantworten. Dazu wird die Pausenstatistik verwaltet und aktualisiert. Abb. 3-6 Behälter und Werkzeuge am PausenplanerArbeitsplatz

3


3.1


398

Der Papierkorb ist hinlänglich aus anderen Anwendungen mit einem elektronischen Schreibtisch bekannt. Wir wollen nur darauf hinweisen, daß er neben seiner Speicherfunktion auch »selbstreinigend« ist und dabei bestimmte Schutz- und Verwendungsbedingungen der enthaltenen Objekte berücksichtigt. Er wird nicht ohne weiteres geschützte oder in Arbeit befindliche Objekte löschen. Das Archiv kann je nach Ausprägung des Anwendungssystems unterschiedlichen Charakter haben. Wenn der Pausenplaner-Arbeitsplatz nur als Einzelplatzsystem realisiert ist, verkörpert er »nur« den Ort, an dem Pausenpläne und andere Materialien aufbewahrt und verwaltet werden. Daß technisch dahinter eine Datenbank oder ein Dateisystem steht, ist für den Anwender weder erkennbar noch von Interesse. Schließlich sollen auch die anderen Behälter ihre Materialien persistent halten und dauerhaft zur Verfügung stellen. Wenn das Archiv in einem verteilten Anwendungssystem, etwa mit einem Sekretariatsarbeitsplatz, eingesetzt wird, muß es darüber hinausgehende Eigenschaften besitzen. Dann werden sowohl der Pausenplanersteller als auch der Sekretär auf dieses Archiv zugreifen. Entsprechend ist zumindest ein einfaches Kooperationsmodell (s. Kapitel 4.1) notwendig, damit zwischen diesen beiden Anwendern Handlungssicherheit besteht. Konkret bedeutet dies, daß der Sekretär erkennen muß, welcher Pausenplan aktuell ist und ob an einem weite-

3


3.1


399

ren gearbeitet wird. Auch der Pausenplanersteller muß über die Arbeit des Sekretärs informiert werden, damit er bei einer geänderten Unterrichtseinteilung Auswirkungen auf den Pausenplan berücksichtigen kann. Diese Koordination kann in einem minimalen Kooperationsmodell mit Hilfe von Statusinformationen am Archiv modelliert werden.

3.1.6 Automat Zusammenhang von Werkzeug und Material Werkzeugentwurf Arbeitsumgebung


Automat

Nicht jede Arbeitshandlung oder Aufgabe wird ausschließlich mit Hilfe von Werkzeugen erledigt. »Kleine« Automaten übernehmen lästige Routinetätigkeiten. In Anwendungssystemen lassen sie sich für verschiedene Zwecke einsetzen, ohne daß der grundlegende Charakter eines Arbeitsplatzes für eigenverantwortliches Handeln zerstört wird.

3


3.1


Schaffe eine Möglichkeit, wiederkehrende Handlungsabfolgen, die nicht unterbrochen werden müssen, zu unterstützen. Dazu eignen sich Werkzeuge schlecht, da Benutzer dort »Automatismen« immer aufs neue durch wiederholte Handhabungsabfolgen erledigen müssen. Es stellt sich die Frage, unter welchen Bedingungen und wie solche Arbeitsroutinen als Automaten im Sinne der WAM-Metapher realisiert werden können. Werkzeuge unterstützen die Erledigung von Aufgaben. Wenn wiederholt Aufgaben in der gleichen Weise erarbeitet werden, dann bilden sich die damit verbundenen Handlungsabfolgen als Arbeitsroutinen heraus. Führen Handlungsabfolgen in diesen Fällen auf gleiche Weise zum selben Ergebnis, dann können sie routinisiert werden, d.h., sie können in schematischer Weise ablaufen. Steht dem Benutzer dazu nur ein Werkzeug zur Verfügung, dann müssen die gleichen Werkzeugoperationen immer wieder ausgeführt werden. Diese Arbeitsroutinen bieten sich als Kandidaten für die Automatisierung an. Das heißt im Rahmen des WAM-Ansatzes, daß ein Automat entworfen wird. Oft stellt sich die Frage, was die implementierte Routine eines Automaten von dem Algorithmus einer Werkzeugoperation unterscheidet. Auf den ersten softwaretechnischen Blick nichts. Denn sowohl die Routine eines Automaten als auch der Algorithmus einer Werkzeugoperation werden durch Anweisungen oder Operationsfol-

3

400 Problem

Kontext

Automat und Werkzeug


3.1


gen implementiert, die einen festgelegten Effekt auf einem Objekt haben oder ein definiertes Ergebnis liefern. Der wesentliche Unterschied zwischen Werkzeug und Automat besteht im Verwendungszusammenhang und im Umfang der implementierten Operation aus fachlicher Sicht. Im einzelnen:

401 Unterschied Werkzeug – Automat

❑ Das Handlungsziel vor Augen, ist für den Benutzer das Werk-

zeug nur Mittel zum Zweck, und sein Einsatz ist abhängig vom Arbeitsfortgang und den Umständen. Der Werkzeugbenutzer hat für jeden fachlichen Arbeitsschritt die Kontrolle über den Arbeitsprozeß und entscheidet, ob er den nächsten Schritt mit Hilfe des Werkzeugs unternimmt oder nicht. In diesem Sinne ist die Aussage von [Bahr 83] zu verstehen, daß sich ein Werkzeug nicht selbst bewegt, sondern von der Hand geführt wird. Der Umgang mit einem Werkzeug ist also immer eine »Handhabung«. Dazu muß eine Werkzeugoperation aus Sicht des Benutzers atomar sein. Sie muß, wie eine Elementarhandlung mit einem Handwerkszeug, aus Sicht des Benutzers nicht mehr sinnvoll weiter unterteilbar sein. So ist die Operation »sortiere« an einem Werkzeug für die Bearbeitung von Lehrerkarten atomar. Es interessiert den Benutzer nicht, daß zur Implementierung dieser Operation die verschiedenen Schritte des gewählten Sortieralgorithmus ausgeführt werden müssen.

3


3.1


402

❑ Demgegenüber bedeutet der Einsatz eines Automaten, daß für

den darin festgelegten Handlungsablauf die Kontrolle vom Benutzer an den Automaten übergeht. Der Benutzer ist dabei nicht daran interessiert, die Einzelschritte eines Arbeitsprozesses aktiv durchzuführen. Wenn die Standardsituation, für den der Automat gebaut ist, und das festgelegte Ergebnis mit den Vorstellungen des Benutzers übereinstimmen, hat er kein Interesse, in den Ablauf einzugreifen. Automaten im Sinne des WAM-Ansatzes entsprechen oft unserem Verständnis von technischen Prozessen als Automatismen. In Computern laufen aus Sicht des Anwenders viele automatische Prozesse, die die Funktionalität sichern, ohne daß sie darüber hinaus von Interesse wären. Wir nutzen dieses Verständnis von Prozessen im Computer, um Prozesse, die für eine Anwendung relevant sind, geeignet zu vergegenständlichen. Implementiere als Automat die formalisierbaren Anteile einer Routine, die aus der Sicht des Anwenders auf die kontextfreie Abfolge von Einzelschritten und ein festgelegtes Ergebnis reduzierbar ist und ohne Unterbrechung ablaufen kann. Konstruiere Automaten so, daß sie wie Werkzeuge auf Materialien arbeiten und in ihrer Eingabe auf wenige Einstellungen oder Interaktionen begrenzt sind.

3

Lösung


3.1


Die Vergegenständlichung von Routinen und Prozessen in Automaten hat sich in folgenden Bereichen bewährt:

403 Kriterien für Automaten

❑ Zur Automatisierung lästiger menschlicher Routinehandlun-

gen. Dabei ersetzt der Automat wiederholte Arbeitsschritte mit Werkzeugen an Materialien. ❑ Zur Kapselung technischer Schnittstellen zu anderen System-

komponenten der Systembasis. Hier repräsentiert ein Automat technische Komponenten, die außerhalb einer Arbeitsumgebung existieren, um so z.B. Materialien in eine Arbeitsumgebung importieren oder sie exportieren zu können. ❑ Zur Steuerung von Arbeitsprozessen an Funktionsarbeitsplät-

zen. Dabei fordert der Automat vom Benutzer wenige Eingaben, um ein festgelegtes Arbeitsergebnis an bestimmten Materialien zu erzielen. ❑ Zur Abbildung von technischen Prozessen, die als eingebettete

Systeme in relativer Unabhängigkeit vom Anwendungssystem laufen. Dabei repräsentiert ein Automat Abläufe oder technische Komponenten, die unter harten oder weichen Echtzeitbedingungen vom Anwendungssystem gesteuert, kontrolliert oder repräsentiert werden müssen.

3


3.1


Die Automatisierung von lästigen Routinetätigkeiten ist ein wesentlicher Entwurfsgesichtspunkt bei der Entwicklung interaktiver Anwendungssysteme nach dem WAM-Ansatz. Aus Sicht der Anwender muß zunächst geklärt werden, welche Routinetätigkeiten überhaupt als Kandidaten in Frage kommen. Entwickler sind hier immer sehr vorschnell, wenn sie eine scheinbar »lästige« wiederholte Handlungsfolge identifiziert haben. Neben der zentralen Frage, welche Routinetätigkeiten aus Sicht der Anwender durch Automaten ersetzt werden sollen, können wir einige Voraussetzungen nennen, die dazu auch gegeben sein müssen:

404 Automatisierung von Arbeitshandlungen

Kriterien für Automatisierung von Routinen

❑ Die Handlungsfolgen laufen in festgelegter, schematischer

Weise ab. Es gibt nur wenige vorab bestimmbare Handlungsalternativen. ❑ Die Arbeitshandlung produziert ein vorher in Art und Umfang

festgelegtes Ergebnis. Dazu sind bestimmte gleiche oder ähnliche Materialien Voraussetzung. ❑ Nachdem die zu bearbeitenden Materialien geklärt und die

Handlungsalternativen gewählt sind, kann der Arbeitsprozeß als Automatismus ablaufen. ❑ Das Arbeitsergebnis läßt sich bruchlos in größere Handlungs-

einheiten einpassen.

3


3.1


Wir haben solche Automaten »kleine Automaten« genannt. Sie können vom Anwender nach eigenem Ermessen innerhalb einer Arbeitsumgebung aus Werkzeugen, Materialien und Behältern eingesetzt werden. Soweit die Automaten für die Materialien geeignet sind, lassen sie sich beliebig wie Werkzeuge zu größeren Arbeitszusammenhängen rekonfigurieren. Sie decken dabei den Standardfall ab. Dazu werden sie mit einigen wenigen Parametern eingestellt und laufen dann ohne weitere äußere Eingriffe ab. Das schränkt ihren Einsatz ein. In einer gut sortierten Arbeitsumgebung sollten für die Sonderfälle entsprechende Spezialwerkzeuge bereitliegen, die die notwendige Flexibilität bei der Aufgabenerledigung herstellen. Offen ist die Frage, ob Automaten für die Einstellung und das Wiederaufsetzen im Störungsfall eine eigene Präsentation und Handhabung anbieten, oder ob sie selbst von Einstellwerkzeugen bearbeitet werden. Beide Lösungen sind technisch und anwendungsfachlich zu motivieren. In fast jedem Anwendungssystem werden Automaten zur Kapselung von nicht-objektorientierten Komponenten der Systemplattform, z.B. einer relationalen Datenbank, verwendet (s. Kapitel 4.2). Sie kapseln auf der einen Seite das konkrete Protokoll und die Schnittstelle. Andererseits realisieren sie eine anwendungsfachliche Interpretation einer technischen Komponente innerhalb des WAM-Handhabungs-

3

405 Kleine Automaten

Kapselung technischer Schnittstellen und Komponenten


3.1


modells. So kann ein Automat für die Großrechnerkommunikation nicht nur den konkreten Transport von operativen Daten aus einem objektorientierten Anwendungssystem leisten. Dieser Automat kann auch selbst oder mittels eines entsprechenden Werkzeugs dem Anwender signalisieren, ob die Verbindung zum Großrechner steht und ob ein Vertrag beispielsweise bereits in die operativen Datenbestände übertragen und dort akzeptiert worden ist. In ähnlicher Weise lassen sich z.B. Transportmechanismen über ein lokales Netz zur Client/Server-Anbindung oder zur Realisierung eines Postversandsystems in Automaten kapseln. In diesen Fällen haben wir den Automaten selbst nicht vergegenständlicht, sondern wir haben ihn hinter einem Transportmedium wie beispielsweise einem Postausgangskorb oder einem gemeinsamen Archiv »verborgen«. Im Bereich von Funktionsarbeitsplätzen haben wir bisher nur begrenzte Erfahrung. Die Grundidee ist schon in Kapitel 2.2.5 beschrieben. Wenn im wesentlichen vorab festgelegte Handlungsfolgen optimal unterstützt werden sollen, entwerfen wir einen Automaten, der die einzelnen Komponenten integriert. Diese Integration kann unterschiedlich stark sein. In einem lockeren Verbund werden einzelne Werkzeuge in den »Rahmen« eines Automaten gestellt. Dabei haben die Werkzeuge noch ihre eigene Interaktionskomponente, aber die

3

406

Automaten an Funktionsarbeitsplätzen


3.1


Verbindung zwischen ihnen und der Materialaustausch wird über den Automaten geregelt. In einer stärkeren Integration greift der Automat direkt über die Funktionskomponente auf die einzelnen Werkzeuge zu und präsentiert selbst eine Interaktionskomponente. Schließlich können die eigenständigen Werkzeuge völlig verschwinden, und der Automat verwendet für einzelne Aufgaben einzelne Subwerkzeuge, implementiert aber selbst wesentliche Teile der fachlichen Funktionalität. Je höher die Integration ist, desto mehr gewinnt der Automat eines Funktionsarbeitsplatzes den Charakter eines »großen Automaten«, d.h., er bestimmt aktiv den Handlungsablauf zur Erledigung einer vordefinierten Aufgabe. Im Sinne der zentralen Charakteristik aller unserer Leitbilder, nämlich der Eigenverantwortlichkeit, müssen wir uns im klaren sein, daß diese großen Automaten die Eigenverantwortlichkeit wesentlich einschränken. Daher ist es notwendig, beim Entwurf nach Ergänzungen zu suchen, die die Vorteile eines optimal unterstützten vorformulierten Arbeitsablaufs mit der notwendigen Flexibilität bei der Behandlung von Sonderfällen verbinden. So können neben den Automaten eines Funktionsarbeitsplatzes zusätzliche Einzelwerkzeuge angeboten werden, die nur in Sonderfällen benutzt werden müssen. Alternativ können wir zumindest Kooperationsmöglichkeiten bereitstellen, um die Bearbeitung von Sonderfällen an anderen Arbeitsplätzen anzustoßen und entsprechend zu koordinieren.

3

407

Große Automaten


3.1


Immer häufiger werden nicht nur im Produktionsbereich technische Geräte eingesetzt, die mit Anwendungssoftware kombiniert werden sollen. Beispiele sind Analyseautomaten in medizinischen Labors oder Telefoniesysteme für große Telefonanlagen, die Leistungen oder Informationen an den Arbeitsplätzen zur Verfügung stellen sollen. Das Kennzeichen solcher Prozesse oder technischer Komponenten ist, daß sie weitgehend unabhängig von den einzelnen Arbeitsplätzen funktionieren und im Dauerbetrieb unter Echtzeitanforderungen eingesetzt werden. Die Telefonieanlage eines Call Centers soll ebenso wie die Automaten eines medizinischen Labors idealerweise ununterbrochen einsatzbereit sein und einen optimalen »Durchsatz« der bearbeiteten Materialien, etwa Anrufen oder Laborproben, ermöglichen. Parallel gibt es aber Arbeitsplätze, die diese Geräte steuern und von ihnen Dienstleistungen sowie Informationen verarbeiten sollen. Im Call Center gibt es neben den Funktionsarbeitsplätzen für die Telefonarbeit auch den Arbeitsplatz des Gruppenleiters, an dem Beratungsteams zusammengestellt und die Auslastung der Telefonarbeitsplätze gesteuert werden sollen. Entsprechend sollen an Laborarbeitsplätzen die Analyseautomaten überwacht und Spezialanalysen durchgeführt werden. Es hat sich als sinnvoll erwiesen, aus Sicht dieser Arbeitsplätze die technischen Prozesse oder Komponenten in eigenen Automaten zu

3

408 Repräsentation von technischen Prozessen und Komponenten

Technische Prozesse als Automaten


3.1


409

kapseln. Sie unterscheiden sich von den bisher beschriebenen dadurch, daß sie prinzipiell als verteilte und nebenläufige Systeme modelliert werden müssen. Sie sind ununterbrochen selbst aktiv und können sinnvoll nur über asynchrone Kommunikationsmechanismen angesprochen werden. Dieses Konzept eines sogenannten »technischen Automaten« (s. [Bleek 97]) scheint dem reaktiven Charakter der nach dem WAM-Ansatz entwickelten Arbeitsplätze auf den ersten Blick zu widersprechen. Zur Integration in das bisher vorgestellte Modell haben wir zwei ergänzende Metaphern verwendet – das Einstellwerkzeug und die Sonde. Sie vergegenständlichen die beiden grundlegenden Umgangsformen an Gegenständen, nämlich das Verändern und das Sondieren. Mit einem Einstellwerkzeug kann der Anwender einen technischen Automaten in seiner Einstellung verändern. Die Sonde ist am technischen Automaten angebracht und liefert in einstellbaren Abständen oder für Schwellwerte vordefinierte Werte über den Zustand des Automaten. Mit Einstellwerkzeugen am Arbeitsplatz und Sonden an den technischen Automaten lassen sich Echtzeitsysteme in das Konzept von Arbeitsplätzen nach dem WAM-Ansatz integrieren. Im Pausenplanbeispiel ist zunächst kein anwendungsfachlicher Automat erkennbar. Alle Tätigkeiten werden mit Werkzeugen auf den entsprechenden Materialien erledigt. Doch wenn wir die Materialien

3


3.1


410

speichern und zusätzlich ein Mehrbenutzerkonzept realisieren wollen, verändert sich die Situation. Wir gehen davon aus, daß wir keine objektorientierte Datenbank zur Verfügung haben und zur Realisierung verschiedene Arbeitsplatzrechner verwenden. Im fachlichen Entwurf bedeutet das Mehrbenutzerkonzept, daß das Schulsekretariat und der Pausenplanersteller auf ein gemeinsames Archiv von Pausenplänen und Lehrerkarten zugreifen sollen. Wir modellieren zwei Arten von Automaten: Ein Speicherautomat kapselt die Realisierung des Persistenzkonzepts. Dies kann eine einfache Lösung mit Hilfe eines Dateisystems sein. Dann serialisiert der Automat die zu speichernden Objekte und schreibt sie »flach« in die Datei, um sie entsprechend umgekehrt auslesen zu können (s. Kapitel 3.3.4). Benutzen wir eine relationale Datenbank, dann werden wir die serialisierten Objekte nach einem geeigneten Verfahren in die Tabellen der Datenbank schreiben (s. Kapitel 4.2.3). Dieser Speicherautomat wird an der Benutzungsschnittstelle nicht selbständig repräsentiert, sondern über Menüeinträge (»speichern«, »öffnen«) in den verschiedenen Werkzeugen angestoßen. Wenn wir das Archiv einführen, bedeutet dies ein minimales Kooperationsmodell (s. Kapitel 4.1.1). Denn jetzt soll am Archiv zumindest erkennbar sein, daß Materialien an einer anderen Stelle bearbeitet werden. Wir repräsentieren das Archiv dazu als »Ort« in

3


3.2

Die WAM-Entwurfsmuster

411

der Arbeitsumgebung. Da das Archiv von jedem Arbeitsplatz ständig zugreifbar sein soll, realisieren wir das Archiv auf jeden Fall als eigenen Prozeß und eine eigenständige »Dienstleistung«. Zwischen jedem Arbeitsplatz und dem getrennt laufenden Archiv muß daher ein Materialversorgungskonzept umgesetzt werden. Dazu wird jede Umgebung einen Automaten enthalten, der den Materialaustausch zwischen Arbeitsplatz und Archiv regelt.

3.2


Im folgenden beschreiben wir ausgehend von den Konzeptionsmustern die WAM-Entwurfsmuster. Im Mittelpunkt stehen solche Entwurfsmuster, nach denen wir interaktive Softwarewerkzeuge konstruieren. Dabei wird auch der Zusammenhang von Werkzeug und Material aufgezeigt. Wir stellen klar, was Softwarewerkzeuge sind, was sie von Materialien und Behältern unterscheidet und wie sie in eine Umgebung eingebettet werden können. Dann diskutieren wir die Realisierungsmöglichkeiten und -probleme für Behälter und Fachwerte. Ein allgemeines Architekturkonzept für Softwarewerkzeuge nach dem WAM-Ansatz wurde schon in [Budde & Züllighoven 89] vorgeschlagen. Wesentliche Merkmale sind die Kopplung von Werkzeug

3

Federführung: Carola Lilienthal, Wolfgang Strunk Ko-Autoren: Guido Gryczan, Rolf Knoll, Daniel Megert, Martina Wulf, Heinz Züllighoven


3.2


412

und Material, die Trennung von Funktionskomponente und Interaktionskomponente und ein Schema für die innere Struktur der Interaktions- und Funktionskomponente. Zentrale Akzente in diesem Kapitel sind: ❑ Das WAM-Architekturkonzept für interaktive Werkzeuge

wird durchgängig als Muster beschrieben. Dabei verwenden wir die in Kapitel 2.3.1 vorgeschlagene Struktur und die generelle Unterteilung in allgemeine Entwurfsmuster und konkrete Konstruktionsansätze. ❑ Innerhalb eines Konstruktionsansatzes verwenden wir allge-

meine Entwurfsmuster, die in [Gamma et al. 96] beschrieben sind. ❑ Wir haben für die Beispiele verschiedene Programmierspra-

chen (C++, Smalltalk, Java) verwendet. Dabei stellen wir alternative Lösungsmöglichkeiten gegenüber, wenn sie sich in den verschiedenen Sprachen konzeptionell wesentlich unterscheiden, diskutieren die Vor- und Nachteile und geben Anleitungen, wann welche Alternative verwendet werden sollte. ❑ Das Architekturkonzept läßt sich in ein rahmenwerkbasiertes

Architekturmodell für große Softwaresysteme einbetten. Dieses Architekturmodell diskutieren wir in Kapitel 3.3.

3


3.2


Die Entwurfsmuster berücksichtigen dabei bewährte und im konzeptionellen Teil dieses Handbuchs beschriebene softwaretechnische Prinzipien. Diese werden jeweils an den Erfordernissen der industriellen Praxis gemessen und entsprechend konkretisiert. Wir haben die Konzeptionsmuster im Entwicklungsprozeß logisch nach der Modellierung des Anwendungsbereichs und vor der softwaretechnischen Konstruktion angeordnet. Stark vereinfachend können wir jetzt die Entwurfsmuster logisch nach den Konzeptionsmustern einordnen. Das würde bedeuten, daß erst fachlich vollständig klar sein muß, aus welchen Komponenten ein interaktives Anwendungssystem besteht, ehe wir uns Gedanken über seine Realisierung machen können. Die Praxis zeigt allerdings, daß sich die verschiedenen Aktivitäten im Entwicklungsprozeß nicht vollständig logisch und schon gar nicht zeitlich voneinander trennen lassen (vgl. Kapitel 2.4). Unsere Vorstellungen über ein Werkzeug lassen sich eben nicht in eine anwendungsfachliche Komponente und in die Handhabung und Präsentation an der Benutzungsschnittstelle aufteilen. Das eine bedingt das andere. Entsprechend erleben wir in den Projekten immer wieder, daß Entwickler bei Diskussionen über die fachliche Funktionalität gleichzeitig »Oberflächenskizzen» malen. Trotzdem verlangt eine softwaretechnisch saubere Konstruktion, daß wir Funktionalität und die interaktiven Komponenten einer Anwendung voneinander trennen.

3

413

Stellenwert der Entwurfsmuster


3.2


414

Wir halten also analytisch und konstruktiv diese Gesichtspunkte auseinander. Daher lassen sich Entwurfsmuster auch getrennt beschreiben und ihre Auswahl und Realisierung ist eine eigene Aufgabe in Softwareprojekten. Wir haben schon allgemein darauf hingewiesen, daß Entwurfsmuster in einer Softwarearchitektur oberhalb von einzelnen Klassen angeordnet sind und das Zusammenspiel von Vererbungs- und Benutzt-Beziehungen beschreiben (vgl. Kapitel 2.3.1). Ein Entwurfsmuster läßt sich aber nicht alleine aus den formalen Klassenbeziehungen gewinnen und auch nicht so beschreiben; dazu muß auch der dynamische Verwendungszusammenhang bekannt sein. Für unseren Kontext heißt das: Wir beschreiben immer beide Aspekte eines Musters – seine Statik und seine Dynamik und motivieren das Muster aus seiner Bedeutung für die Anwendung, z.B. eines Werkzeugs. Abbildung 3-7 zeigt einerseits, daß Entwurfsmuster die Konzeptionsmustern konkretisieren und zum anderen wird der Zusammenhang der verschiedenen Entwurfsmuster zur Werkzeugkonstruktion deutlich. Im weiteren verwenden wir Abbildung 3-7 wieder als eine Art »Landkarte«, die dem Leser zeigen soll, wo er sich in den Musterbeschreibungen befindet. Während das Konzeptionsmuster Zusammenhang von Werkzeug und Material die Komplementarität von Werkzeugen und Materialien

3


3.2


415

im menschlichen Arbeitsprozeß heraushebt, betont das Entwurfsmuster Werkzeug- und Materialkopplung das Zusammenpassen der beiden Komponenten. Die folgenden Muster detaillieren die Werkzeugkonstruktion. Das Muster Trennung Interaktion und Funktion beschreibt die grundlegende Aufteilung in fachliche Funktionalität sowie Handhabung und Präsentation. Davon leitet sich das Muster Rückkopplung zwischen Interaktion und Funktion ab, das eine Lösung des Rückkopplungsproblems bei reaktiven Komponenten liefert. Auf der Basis des Musters Rückkopplung zwischen Interaktion und Funktion läßt sich rekursive Konstruktion komplexer Werkzeuge aus Teilkomponenten durchführen. Dies leistet das Muster Werkzeugkomposition. Das Muster Trennung von Handhabung und Präsentation führt die Separierung der Interaktion von der Funktion eine Stufe weiter. Gleichzeitig muß aber auch hier die notwendige Rückkopplung zwischen den Komponenten sichergestellt werden. Bei der Beschreibung dieser allgemeinen Entwurfsmuster verwenden wir einige Konstruktionsansätze, um die Realisierungsalternativen aufzuzeigen.

3


Konzeptionsmuster

3.2


Abb. 3-7

Zusammenhang von Werkzeug und Material Werkzeugentwurf Arbeitsumgebung

416

Hierarchie der WAM-Entwurfsmuster



Entwurfsmuster

Trennung Interaktion und Funktion Rückkopplung zwischen Funktion und Interaktion

fachliche Behälter

Werkzeugkomposition Trennung von Handhabung und Präsentation

Umgebung Ereignisverwalter

Materialverwaltung


Fachwerte

Materialkoordinator

3


3.2


417

Neben diesen Mustern zum Bau von Werkzeugen werden in diesem Kapitel Entwurfsmuster vorgestellt, die das Konzeptionsmuster Umgebung konkretisieren. Dabei wird der Ereignisverwalter, die Materialverwaltung und der Materialkoordinator vorgestellt. Auch das Konzeptionsmuster Behälter wird in diesem Abschnitt konkretisiert. Dazu werden die Konstruktionen fachliche Behälter und technische Behälter eingeführt. Schließlich greifen wir die Diskussion über Fachwerte aus dem Kapitel 2.1.14 wieder auf und stellen entsprechende Konstruktionsansätze vor. In beiden Fällen verwenden wir im wesentlichen die Musterform. Allerdings sind unsere Erfahrungen über fachliche Behälter und Fachwerte so vielfältig, daß sie sich nicht auf ein oder wenige ausgereifte Muster reduzieren lassen.

3


3.2


418

3.2.1 Werkzeug- und Materialkopplung Zusammenhang von Werkzeug und Material



Automat

WerkzeugWerkzeug-und undMaterialkopplung Materialkopplung Trennung Interaktion und Funktion

Rückkopplung zwischen Funktion und Interaktion

fachliche Behälter


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte

Trennung von Handhabung und Präsentation

Umgebung

Materialkoordinator

3


3.2


419

Die WAM-Methode unterscheidet mit Werkzeugen und Materialien diejenigen Komponenten eines Anwendungssystems, die im Rahmen von Arbeitstätigkeiten bearbeitet werden und in das Ergebnis der Arbeit eingehen, sowie diejenigen Komponenten, mit denen das Ergebnis hervorgebracht wird. Dieser rein fachliche Bezug von Werkzeugen und Materialien setzt voraus, daß die Werkzeuge und Materialien zueinander passen. In diesem Abschnitt stellen wir die in der WAM-Methode gewählte Lösung vor, mit der das Zusammenpassen von Werkzeugen und Materialien ausgedrückt werden kann. Wir verwenden zu diesem Zweck Aspekte. Es gibt mehrere Möglichkeiten, die Kopplung von Werkzeugen und Materialien über Aspekte zu realisieren. Diese Möglichkeiten hängen zunächst von den Ausdrucksmitteln der verwendeten Programmiersprachen ab. Sie unterscheiden sich auch in dem Ausmaß, in dem sie das Verhalten des Materials spezifizieren. In den folgenden Abschnitten zeigen wir daher, wie sich Aspekte in verschiedenen Konstruktionsansätzen realisieren lassen: ❑ durch Mehrfachvererbung, ❑ durch das Adaptermuster, ❑ durch das Dekorierermuster, ❑ indem benannte Schnittstellen simuliert werden, ❑ mit Werkzeugunterstützung

3


3.2


420

Wir gehen kurz auf die Frage ein, unter welchen Umständen Aspekte entbehrlich sind. Aspekte Zusammenhang von Werkzeug und Material



Automat

Werkzeug- und Materialkopplung Trennung Interaktion und Funktion Aspekte Rückkopplung zwischen Funktion und Interaktion

fachliche Behälter


Werkzeugkomposition Fachwerte

Trennung Umgebung Ereignisverwalter

Materialverwaltung

von Handhabung und Präsentation Materialkoordinator

Bei der Erledigung von Aufgaben arbeitet der Anwender mit Werkzeugen auf Materialien. Dabei können Werkzeuge und Materialien nicht 3


3.2


beliebig miteinander kombiniert werden, denn nicht jedes Werkzeug paßt zu jedem Material und umgekehrt. Suche nach einem Konstruktionsprinzip, welches sicherstellt, daß Werkzeuge und Materialien zusammenpassen. Dieses Prinzip soll schon für den Entwurf und nicht erst in der konkreten Programmierung gelten. Dabei ist es sinnvoll, Werkzeuge nicht nur für ein einziges Material passend zu machen (und umgekehrt). Das Konzeptionsmuster Zusammenhang von Werkzeug und Material soll soweit verfeinert werden, daß die fachlichen Bezüge zwischen Werkzeugen und Materialien auch im technischen Entwurf sichtbar sind. Der Zusammenhang von Werkzeugen und Materialien im Arbeitsprozeß ist von zentraler Bedeutung für das Verständnis menschlicher Arbeit. Die handwerkliche Tradition und entsprechende Normen stellen dabei sicher, daß Handwerkszeug zu entsprechenden Materialien paßt. Der richtige Umgang mit Handwerkszeug und Material gehört zur Ausbildung in der Lehre jedes Handwerkers. Für viele Handwerkzeuge und Materialien, wie Schraubenschlüssel, Schrauben und Muttern, legen Normen (z.B. die DIN- und ISI-Normen) das Zusammenpassen fest. Für Softwarewerkzeuge und -materialien gibt es weder eine solche Tradition, noch entsprechende Normen; von wenigen Ansätzen (z.B. CORBA als Schnittstellendefinition für Dienstleistungen) einmal abgesehen. Daher müssen wir konstruktiv absichern, daß

3

421 Problem

Kontext


3.2


Softwarewerkzeuge und -materialien zusammenpassen und kombinierbar sind. Wenn wir Werkzeuge und Materialien als Komponenten unserer Anwendungssysteme verstehen, dann bedeutet dieses Zusammenpassen, daß entsprechende Schnittstellen vorhanden sein müssen. Da Anwender vom Benutzungsmodell her mit Werkzeugen auf Materialien arbeiten sollen, muß offenbar das Material eine Schnittstelle anbieten, die von einem Werkzeug verwendet werden kann. Aus dem Konzeptionsmuster Zusammenhang von Werkzeug und Material (s. Kapitel 3.1.1) wird klar, daß ein Werkzeug auch für unterschiedliche Materialien geeignet sein soll. Damit ist die Schnittstelle eines Werkzeugs zu einem Material schmaler oder abstrakter als die volle Schnittstelle des konkreten Materials. Sind die Schnittstellen zwischen einem Werkzeug und einem Material nicht ausdrücklich spezifiziert, so stellt sich die Frage, welcher Ausschnitt einer Materialschnittstelle von einem Werkzeug verwendet wird. Aus dem Entwurf läßt sich diese Information nicht ohne weiteres herausziehen. Denn die Schnittstelle, die ein Werkzeug erwartet, ist nicht einfach durch fachliche Abstraktion aus dem Material »herauszuziehen«, sondern sie ist durch die Anforderungen des Werkzeugs bestimmt. Wenn wir keine weiteren Komponenten in den Entwurf einführen, wird sich die Schnittstelle zwischen Werkzeug und Material nur durch Analyse des Programmtextes des Werkzeugs feststellen lassen.

3

422

Ein Werkzeug für unterschiedliche Materialien


3.2


Gibt es nun verschiedene Werkzeuge, die auf einem Material arbeiten, dann verschärft sich das Problem. Die konkrete Schnittstelle des Materials wird entsprechend »breiter« werden, und der Bezug zwischen Werkzeugen und Materialien ist noch undeutlicher. Sollen neue Materialien in ein bestehendes Anwendungssystem integriert werden, so steht der Entwickler des Materials vor dem folgenden Problem: Damit das neue Material von bestehenden Werkzeugen bearbeitet werden kann, muß der Entwickler feststellen können, welche Schnittstelle das Material haben muß. Diese Information ist aber weder im Werkzeug noch in anderen von diesem Werkzeug benutzen Materialien zu finden. Entwirf eine Komponente Aspekt, die den Verwendungszusammenhang zwischen einem Werkzeug und den dafür geeigneten Materialien repräsentiert. Dieser Aspekt soll sowohl die syntaktische Schnittstelle als auch möglichst viel von der Semantik dieses Zusammenhangs darstellen. Sorge dafür, daß ein Material die im Aspekt formulierten Anforderungen für die Benutzung durch ein Werkzeug erfüllt. Sorge ebenfalls dafür, daß das entsprechende Werkzeug seine Materialien nur unter der im Aspekt spezifizierten Schnittstelle verwendet. Löse das technische Problem – unterschiedliche Protokolle oder Schnittstellen zusammenzufassen – explizit im Entwurf. Damit sind die Grundkomponenten des Musters und ihre Beziehungen gegeben (s. Abbildung 3-8). Ein Werkzeug benutzt einen

3

423 Verschiedene Werkzeuge für ein Material

Lösung

Musterschema


3.2


424

Aspekt. Dieser Aspekt spezifiziert, welche Leistungen ein Material aus Sicht des Werkzeugs erbringen muß. Das Material erfüllt die vom Aspekt versprochene Schnittstelle und das in der Schnittstelle definierte Verhalten. Wir wollen an dieser Stelle explizit nicht davon sprechen, daß das Material von dem Aspekt erbt, weil unterschiedliche Konstruktionsansätze für das Muster in den verschiedenen Programmiersprachen teilweise mit und teilweise ohne Vererbung zwischen Material und Aspekt arbeiten (s. S. 209, 214, 219, 223, 228, 230). Abb. 3-8


Musterschema Werkzeugund Materialkopplung

benutzt

Aspekt z.B. Auflistbar_Lehrkörper

erfüllt Schnittstelle

Material z.B. Lehrkörper

3


3.2


425

Am Beispiel des Pausenplaners wollen wir die Kopplung zwischen Werkzeug und Material mit Hilfe eines Aspekts noch einmal erläutern. Abb. 3-9 Das Werkzeug

Pausenplaner

Pausenplaner arbeitet auf dem Material Lehrkörper Welchen Teil der Schnittstelle benutzt der Pausenplaner?

Lehrkörper

Das Werkzeug Pausenplaner benutzt das Material Lehrkšrper (s. Abbildung 3-9). Der Pausenplaner benötigt aber nur einen Teil der Eigenschaften, die der Lehrkšrper zur Verfügung stellt. Die Aufgabe des Pausenplaner besteht darin, den Lehrkšrper so zu präsentieren, daß der Anwender einen Lehrer auswählen und mit diesem dann eine Pause belegen kann. In Abbildung 3-10 wird einerseits die Schnittstelle des Materials Lehrkšrper dargestellt und anderseits der Teil der

3


3.2


426

Schnittstelle als Aspekt Auflistbar_Lehrkšrper zusammengefaßt, der für den Pausenplaner interessant ist.

Lehrkörper AnzahlLehrer(); GibLehrerListe(); MarkiereLehrer(index); GibMarkiertenLehrer(); MarkiereErstenLehrer(); MarkiereNächstenLehrer(); IstMarkierungAmAnfang(); IstMarkierungAmEnde(); IstMarkierungGültig(); NimmLehrerAuf (Lehrer); EntferneMarkiertenLehrer(); SetzeMarkierungAufLehrer(Lehrer); GibLehrkörpername(); SetzeLehrkörpername(Name);

Auflistbar_Lehrkörper

Abb. 3-10 Materialschnittstelle und Aspektschnittstelle

GibLehrerListe(); MarkiereLehrer(index); GibMarkiertenLehrer();

IstMarkierungGültig();

GibLehrkörpername();

Bei dieser Modellierung wird davon ausgegangen, daß der Pausenplaner den Namen des Lehrkšrpers anzeigt, den er als Liste darstellt. Außerdem läßt sich der Pausenplaner die Liste der Lehrer geben, um ihre Namen darzustellen und markiert am Lehrkšrper, welchen Lehrer der Benutzer ausgewählt hat. Soll der markierte Lehrer bearbeitet werden, so kann der Pausenplaner über die Operation GibMarkiertenLehrer() den gerade ausgewählten Lehrer erfragen. Bei einer

3


3.2

427


detaillierteren Modellierung wäre noch zu klären, ob der Pausenplaner lediglich eine Liste von Namen erhält, wenn er nach der Liste der Lehrer fragt, und ob die Markierung des Lehrers tatsächlich am Lehrkšrper erfolgen soll oder im Werkzeug vorgehalten werden sollte. Im Sinne von [Wirfs-Brock et al. 90] definieren Aspekte eine »responsibility«, d.h. eine Verantwortlichkeit; wir nennen dies eher ein »Dienstleistungsbündel«. Ein Material ist dafür zuständig, eine Menge von aufeinander abgestimmten Operationen anzubieten, die das Werkzeug verwendet, um eine bestimmte Aufgabe zu erfüllen. Dazu sollte ein Aspekt Eigenschaften spezifizieren, die über die rein syntaktische Schnittstelle hinausgehen und das Verhalten der Materialien beschreiben. Durch diese Eigenschaften sind Aspekte auch geeignet, den Zusammenhang zwischen Automaten und den von ihnen benötigten Materialien zu definieren. Damit können Automaten und Werkzeuge in gleicher Weise mit Materialien kombiniert werden. Die Mittel der Verhaltensspezifikation von Aspekten sind in objektorientierten Programmiersprachen beschränkt. Wir wollen einen Aspekt aber wenigstens zur Spezifikation einer Schnittstelle einsetzen. Um abzusichern, daß die Schnittstelle erfüllt wird, sollte sie als Typ definiert sein. Dies leisten im Prinzip alle Sprachen mit einem statischen Typkonzept. In statisch typisierten Sprachen kann ein Aspekt als

3

Diskussion

Verhaltensspezifikation von Aspekten


3.2


abstrakte Klasse realisiert werden [Budde & Züllighoven 90]. Die Realisierung der Werkzeug- und Materialkopplung mit Hilfe von Vererbung basiert auf der Erfahrung aus Projekten, in denen Sprachen wie C++ und Eiffel eingesetzt wurden. Da Sprachen wie Java ein InterfaceKonzept anbieten, das wie eine abstrakte Klassendefinition wirkt, kann diese Konstruktion auch dort einfach nachvollzogen werden. Bei den Sprachen, die nur Einfachvererbung kennen, bereitet die Realisierung von Aspekten über einen Typ Schwierigkeiten. Wenn zwischen Werkzeugen und Materialien keine Eins-zu-eins-Beziehung besteht, muß das Material von mehreren Aspektklassen erben. In Smalltalk gibt es beispielsweise nur Einfachvererbung und dazu tritt noch das Problem auf, daß Smalltalk keine statische Typprüfung hat. Wir müssen die Schnittstellen von Materialien dort entweder zur Laufzeit auf Konformität prüfen oder in den Entwicklungsprozeß eingreifen und den Programmtext entsprechend untersuchen und verändern. Das Verhalten von Materialien läßt sich durch Aspekte ebenfalls unterschiedlich festlegen. Ein Möglichkeit sind sicherlich Klassen mit abstrakten Implementationen und entsprechenden Einschuboperationen. Soll das Verhalten weniger stark festgelegt werden, dann bietet sich zumindest das Vertragsmodell mit seinen Zusicherungen an, um die Bedingungen für Operationsaufrufe und die zulässigen Zustände eines Materials zu definieren (s. Kapitel 2.1.10). Diese Lösungen sind

3

428

Aspekte und Einfachvererbung

Aspekte und Material


3.2


nur möglich, wenn Aspekte als Klassentypen realisiert werden. Ansonsten bleibt nur die reine Schnittstellenprüfung. Für ein allgemeines Konzept der Werkzeug- und Materialkopplung hat es sich als eher hinderlich erwiesen, daß wir bisher in der Literatur zum WAM-Ansatz dieses Muster immer durch eine feste Klassenstruktur umgesetzt haben. Sprachen, die keine Mehrfachvererbung zulassen, erzwingen eine Überarbeitung der Lösungsidee. Im Lichte der Diskussion um Objective C und Java und der dort vorhandenen Möglichkeit, Schnittstellen zu definieren, stellt sich die Frage, ob Aspekte überhaupt als Klassen oder besser nur als eine benannte Sammlung von Operationen definiert werden sollen. In den folgenden Abschnitten beantworten wir die hier aufgeworfenen Fragen, indem wir unterschiedliche Konstruktionsansätze für Aspekte vorstellen. Abschließend fassen wir die Überlegungen zusammen und diskutieren, in welchen Situationen auf Aspekte verzichtet werden kann.

3

429 Konstruktionsansätze für Aspekte


3.2


430

Aspektkonstruktion durch Aspektvererbung Zusammenhang von Werkzeug und Material



Automat

Werkzeug- und Materialkopplung Trennung Interaktion und Funktion Aspekte Rückkopplung zwischen Funktion Aspektund Interaktion vererbung

fachliche Behälter




Materialverwaltung


Wird die Schnittstelle eines Aspekts als Klasse modelliert, kann ein Material diesen Aspekt direkt erben. Dabei wird Vererbung so eingesetzt, daß alle Operationen einer Aspektklasse an der Schnittstelle

3

Lösung


3.2


des Materials sichtbar sind. Da das Material die vollständige Schnittstelle des Aspekts erbt, besteht eine echte Typ-Subtypbeziehung zwischen Aspekt und Material. An jeder Stelle, an der ein Objekt des Aspekttyps eingesetzt wird, kann auch jedes Objekt einer zum Aspekt typkonformen Materialklasse eingesetzt werden. Aspektklassen, wie sie unser existierendes Architekturmodell für C++ enthält, erlauben, die Aspektschnittstelle zwischen einem Werkzeug und seinem Material in einer abstrakten Klasse festzuhalten. Damit können Aspektklassen zwar als Typ verwendet werden, von ihnen lassen sich aber keine direkten Objekte erzeugen. Trotzdem achten wir darauf, daß die Werkzeugklassen nie direkt mit einer Materialklasse, sondern nur mit den abstrakten Aspektklassen arbeiten (s. Abbildung 3-11). Die Materialklassen erben von Aspektklassen und implementieren die ererbten Eigenschaften. Durch die Ausnutzung von Polymorphie rufen die Werkzeugklassen die in den Materialien implementierten Operationen auf.

3

431

Musterschema


3.2


432 Abb. 3-11

Werkzeug 1

Werkzeug 2

Werkzeug 3

Werkzeug M

Werkzeuge benutzen Materialien über Aspektklassen

benutzt

Aspekt 1

Aspekt 2

Aspekt 3

Aspekt M

... erbt_von Material 1

Material 2

Material N

Materialien werden in der Regel nicht nur von einem einzigen Werkzeug bearbeitet. Wie Abbildung 3-11 andeutet, hat dies zur Folge, daß ein Material von mehreren Aspektklassen erbt. Umgekehrt kann ein Werkzeug auch auf mehreren Materialien arbeiten. Die gesamte Schnittstelle eines Materials umfaßt damit die einzelnen Schnittstellen der jeweiligen Aspekte. Hier ist also Mehrfachvererbung erforderlich. Abbildung 3-11 ist insofern vereinfachend, als jedes Werkzeug über eine Aspektklasse auf ein Material zugreift. Komplexe Werk-

3


3.2


433

zeuge werden aber meist mehr als ein Material verwenden. Ebenso ist es üblich, elementare Aspektklassen selbst wieder durch Mehrfachvererbung zu komplexeren zusammenzustellen. Durch die Modellierung der Aspekte in eigenen Klassen können wir schon Standardimplementationen für Operationen festlegen, was der Grundidee der Aspekte entspricht. Denn je genauer das Verhalten der Materialien beschrieben ist, desto höher ist die Wahrscheinlichkeit, daß ein Werkzeug sowohl syntaktisch als auch semantisch passend mit einem Material arbeiten kann. Diese Standardimplementationen ermöglichen zudem, den aus der Sicht des Werkzeugs notwendigen Materialzustand schon in der Aspektklasse zu modellieren. Die Materialklassen können die vorgegebenen Operationen überschreiben und den Zustand erweitern, indem sie Attribute hinzufügen. Allerdings sollte eine Konstruktion, bei der auch Attribute in den Aspektklassen definiert werden, mit Vorsicht gebraucht werden. Sie widerspricht der Idee, daß Aspekte Schnittstellen sind, und dem objektorientierten Entwurfsprinzip, abstrakte Klassen so leichtgewichtig wie möglich zu konstruieren. Folglich werden alle abgeleiteten Materialklassen mit diesen Attributen »belastet«. Auch wenn dies im ursprünglichen Entwurf eines Anwendungssystems zu rechtfertigen ist, heißt das noch lange nicht, daß auch zukünftige Materialklassen unter einer Aspektklasse wirklich auf diese Attribute festgelegt werden sollten. Nehmen wir wieder unser Pausenplanbeispiel, um uns anzusehen, wie Aspektklassen in C++ realisiert werden können. 3


3.2


434

class Auflistbar_Lehrkoerper { public: virtual virtual virtual virtual };

List<String*> GibLehrerListe() = 0; void MarkiereLehrer(int index) = 0; Lehrer GibMarkiertenLehrer() = 0; String GibLehrkoerpername() = 0;

class Lehrkoerper : public Auflistbar_Lehrkoerper { public: //Konstruktor und Destruktor Lehrkoerper(); virtual ~Lehrkoerper(); // Aspekt: Auflistbar_Lehrkoerper virtual List<String*> GibLehrerListe(); virtual void MarkiereLehrer(int index); virtual Lehrer GibMarkiertenLehrer(); virtual String GibLehrkoerpername(); virtual bool IstMarkierungGueltig(); // Aspekt: ... virtual int AnzahlLehrer(); virtual void MarkiereErstenLehrer(); virtual void MarkiereNaechstenLehrer(); virtual bool IstMarkierungAmAnfang(); virtual bool IstMarkierungAmEnde(); virtual void NimmLehrerAuf (Lehrer aLehrer); virtual void EntferneMarkiertenLehrer(); virtual bool SetzeMarkierungAufLehrer(Lehrer pLehrer); virtual void SetzeLehrkoerpername(String aName); private: List Lehrerlist; Cursor Markierung; String Lehrkoerpername; };

3


3.2


435

Das Konzept des Cursors, das die Markierung realisiert und die verschiedenen technischen Behältervarianten (hier: List) werden wir in Kapitel 3.2.7. näher vorstellen. Statische Typisierung durch Verwendung einer Aspektklasse hat den Vorteil, daß die Konformität eines Materials zu einem Aspekt schon zur Übersetzungszeit geprüft wird (im Sinne von »implementiert das Material den Typ, der im Aspekt definiert worden ist?«). Darüber hinaus wird sichergestellt, daß ein Werkzeug »seine« Materialien nur unter diesem Aspekt verwenden kann (im Sinne von »benutzt ein Werkzeug nur Materialien dieses Aspekttyps?«). In Aspektklassen lassen sich durch Standardimplementationen oder Schablonenoperationen bereits Verhaltensspezifikationen vorgeben. Schließlich läßt sich mit entsprechender Vorsicht auch schon ein Zustand für die Materialien implementieren. Die Idee der Aspekte muß nicht auf die Kopplung zwischen Werkzeugen und Materialien eingeschränkt werden. Wir haben sie schon auf den Zusammenhang von Automaten und Materialien ausgeweitet. Wenn wir Aspekte allgemeiner im Sinne eines Protokolls betrachten, das eine Klasse erfüllen soll, lassen sich weitere Einsatzbereiche für diese Art der Modellierung finden. Beispiele sind das Protokoll für die Benutzung von Behälterklassen oder zwischen Behältern und verwal-

3

Diskussion

Generalisierung von Aspekten


3.2


teten Objekten oder das Verteilen von Objekten. In allen Fällen wird von Objekten ein bestimmtes Protokoll erwartet, d.h. in der Regel mehr als eine Operation, damit sie bearbeitet werden können. Gleichzeitig stellt sich die Frage, ob jeweils eigene Klassen für diese Protokolle nicht zu aufwendig und letztlich verständnismindernd sind. Die Modellierung von Aspekten als abstrakte Oberklassen zu den Materialien bringt auch Probleme mit sich. Bei der Anbindung von Aspekten an die Materialien wird der Mechanismus der Vererbung anders eingesetzt als bei der fachlichen Modellierung: Um den Zusammenhang zwischen fachlichem und technischem Entwurf zu verdeutlichen, setzen wir Vererbung vorrangig zur Modellierung fachlicher Begriffshierarchien ein. Dabei ist die Einfachvererbung eine wesentliche Kompositionsregel. Wenn wir Aspektklassen mit Hilfe von Vererbung realisieren, wird dabei das Zusammenpassen von Werkzeugen und Materialien in einem Arbeitszusammenhang beschrieben. Dies ist ein völlig anderer Gesichtspunkt. Ein Aspekt kann nämlich Materialien unter sich vereinen, die fachlich keine Ähnlichkeit aufweisen. Sie haben nichts miteinander zu tun, außer daß sie von ein und demselben Werkzeug bearbeitet werden können. So kann ein Drucker die verschiedensten Materialien drucken und ein Mülleimer (-Werkzeug) kann sie löschen. Dies ist mit dem Muster des Klassenadapters (s. [Gamma et al. 96]) vergleichbar.

3

436

Probleme des Konstruktionsansatzes


3.2


Die unterschiedliche Verwendung von Vererbung kann das Verständnis der Entwürfe leicht erschweren. Eine Abhilfe schaffen Namenskonventionen. So benennen wir alle Klassen, die fachliche Gegenstände modellieren, mit Substantiven (z.B. Ordner, Formular, Konto). Dagegen werden die Aspektklassen durch Adjektive meist mit der Endung »-bar« gekennzeichnet (z.B. editierbar, speicherbar). Allgemeiner ist die Frage, ob Materialien nicht durch ererbte Aspekte zu fest an die entsprechenden Werkzeuge gebunden sind. Ein Material realisiert dadurch statische Schnittstellen, die vielleicht nur zeitweise und in bestimmten Verwendungszusammenhängen benötigt werden. Nicht zu vernachlässigen bei der Arbeit mit Aspektklassen und Mehrfachvererbung in großen Systemen sind außerdem die Kosten beim Compilieren und Linken in Sprachen wie C++ sowie die Flut an Oberklassen und dem daraus resultierenden Verlust an Übersichtlichkeit. Wird ein komplexes Rahmenwerk nach dem WAM-Ansatz entwickelt und werden entsprechende Mechanismen zur Strukturierung dieser Rahmenwerke eingesetzt (s. Kapitel 3.3.2), so ergeben sich Schwierigkeiten bei der Zuordnung von Aspektklassen zu den verschiedenen Subsystemen.

3

437

Aspektklassen und Subsysteme


3.2


438

Da Aspektklassen die Schnittstelle eines Werkzeugs zu einem oder mehreren Materialien beschreiben, gehören sie eigentlich zu den sie benutzenden Werkzeugklassen. Die Materialklassen müssen aber von den Aspektklassen erben. So wären die Materialsubsysteme von den Werkzeugsubsystemen abhängig, da das Materialsubsystem von Klassen aus dem Werkzeugsubsystem erbt. Wir können einen Aspekt auch nicht einfach einer Materialklasse zuordnen, da er ja prinzipiell für viele Materialien gut sein soll. Wird ein eigenes Subsystem für Aspektklassen gebildet, so muß der fachliche Zusammenhang mühsam rekonstruiert werden und die Materialsubsysteme sind von den Aspektsubsystemen abhängig.

3


3.2


439

Aspektkonstruktion mit Hilfe des Objektadaptermusters Zusammenhang von Werkzeug und Material



Automat

Werkzeug- und Materialkopplung Trennung Interaktion und Funktion Aspekte Rückkopplung zwischen Funktion AspektObjektund Interaktion vererbung adapter

fachliche Behälter




Materialverwaltung


Wir haben schon auf das Problem der Sprachen mit Einfachvererbung hingewiesen. Dort lassen sich Aspekte nicht als Oberklassen der Materialien konstruieren. Dies verhindert die flexible Kombinierbarkeit von Werkzeugen und Materialien. Wir schlagen als eine alternative Lösung die Verwendung eines Adapters vor.

3


3.2


440

Das Adaptermuster (s. [Gamma et al. 96]) läßt Klassen zusammenarbeiten, die sonst wegen inkompatibler Schnittstellen dazu nicht in der Lage wären. Allgemein betrachtet, paßt ein Adapter eine bestimmte Schnittstelle (die des zu adaptierenden Objekts) an eine andere von einem Klienten erwartete Schnittstelle an. Es gibt zwei Ausprägungen des Adaptermusters: den Klassenadapter, der auf Mehrfachvererbung beruht (und unserer Aspektklasse entspricht), und den Objektadapter. Hier kommt nur der Objektadapter infrage:

Lösung

Ein Objektadapter verwendet eine Objektkomposition (s. Abbildung 3-12). Er besteht im Kern aus zwei Objekten: dem Adapterobjekt und dem adaptierten Objekt. Die Klasse Adapter erbt die geforderte Schnittstelle von der Klasse Ziel. Sie implementiert diese Schnittstelle mit Hilfe von AdaptierteKlasse. Klienten verwenden Adapter nur über eine abstrakte Zielklasse. Ruft ein Klient über Polymorphie eine Operationen des Adapterobjekts auf, dann ruft das Adapterobjekt die Operationen des adaptierten Objekts, welche die gewünschte Dienstleistung liefern.

Musterschema

3


3.2

Klient

Ziel Operation()


Adaptierte Klasse SpezifischeOperation()

441 Abb. 3-12 Allgemeine Struktur des Objektadapters

adaptiertes Objekt Adapter Operation()

adaptiertesObjekt-> SpezifischeOperation()

Für die Realisierung von Aspekten mit Hilfe eines Adapters ersetzen wir die allgemeine Klasse Ziel durch eine Aspektklasse und AdaptierteKlasse durch ein Material. Für jede anzupassende Materialklasse wird dann eine konkrete Adapterklasse als Unterklasse der abstrakten Aspektklasse gebildet. In dieser Adapterklasse werden die Operationen der Aspektklasse unter Verwendung von Operationen, die das Material bereitstellt, definiert. Der Objektadapter läßt sich sehr gut in Smalltalk einsetzen, um dem Material eine zusätzliche Schnittstelle zu geben. Da Smalltalk nur Einfachvererbung unterstützt und wir für die fachlichen Begriffshierarchien vorrangig Vererbung einsetzen, haben die fachlichen Klassen meist bereits eine Oberklasse, bevor Aspekte eingeführt werden. Damit können wir in Smalltalk Aspekte nicht über Vererbung realisie-

3

Verwendung


3.2


442

ren. Die Lösung ist hier, eine Aspektklasse zur Definition der Schnittstelle zu benutzen, von der aber keine Objekte erzeugt werden. Zu jedem Material, das wir mit diesem Aspekt versehen wollen, modellieren wir nun eine Unterklasse zu der abstrakten Aspektklasse. Diese kapselt ein Objekt der Materialklasse und implementiert die Operationen des Aspekts mit Hilfe der Materialoperationen. Das Werkzeug Pausenplaner arbeitet mit einem Objekt der Klasse AuflistbarerLehrkoerper unter der abstrakten Schnittstelle der Aspektklasse Auflistbar_Lehrkoerper. Das Objekt der Klasse AuflistbarerLehrkoerper leitet alle Aufrufe an das LehrkoerperObjekt weiter, auf das es eine Referenz besitzt (s. Abbildung 3-13).

Pausenplaner

Auflistbar_Lehrkoerper gibLehrerListe

Lehrkoerper gibLehrerListe

Abb. 3-13 Der Aspekt »Auflistbar_Lehrkoerper« als Objektadapter

einLehrkoerper AuflistbarerLehrkoerper gibLehrerListe

einLehrkoerper gibLehrerListe.

Den Objektadapter für den Lehrkörper stellen wir hier in einer Smalltalk-Lösung vor. In Smalltalk ist ein Objektadapter eine mögliche Lösung für eine Modellierung mit Aspektklassen. Dazu modellieren wir zunächst die Klasse Lehrkoerper: 3


3.2


443

Object subclass: #Lehrkoerper instanceVariableNames: 'lehrerListe lehrkoerpername cursor' ... initialize lehrerListe := OrderedCollection new. cursor := -1. lehrkoerpername := ''. anzahlLehrer ^lehrerListe size. gibLehrerListe ^lehrerListe collect: [:lehrer | lehrer name]. markiereLehrer: index cursor := index. gibMarkiertenLehrer ^lehrerListe at: cursor. markiereErstenLehrer cursor := 0. markiereNaechstenLehrer cursor := cursor + 1. istMarkierungGueltig ^not(cursor == -1). istMarkierungAmAnfang ^(cursor == 0). istMarkierungAmEnde ^(cursor >= (lehrerListe size)). nimmLehrerAuf: aLehrer lehrerListe add: aLehrer. entferneMarkiertenLehrer lehrerListe remove: (lehrerListe at: cursor). setzeMarkierungAufLehrer: aLehrer cursor := lehrerListe indexOF: aLehrer. gibLehrkoerpername ^lehrkoerpername. setzeLehrkoerpername: aName lehrkoerpername = aName.

3


3.2


444

Der Aspekt Auflistbar_Lehrkoerper, unter dem das Werkzeug das Material verwendet, besteht aus einer Klasse, die lediglich Operationen definiert, aber keine Implementation besitzt. Object subclass: #Auflistbar_Lehrkoerper gibLehrerListe. markiereLehrer: index. gibMarkiertenLehrer. istMarkierungGueltig. gibLehrkoerpername.

Wir entwerfen jetzt einen Objektadapter, der die Schnittstelle des Aspekts Auflistbar_Lehrkoerper realisiert. Das folgende Listing verdeutlicht das Prinzip des Objektadapters: Implementiere Operationen des Aspektes mit Hilfe der Operationen, die das Material schon zur Verfügung stellt.

3


3.2


445

Auflistbar_Lehrkoerper subclass: #AuflistbarerLehrkoerper instanceVariableNames: 'einLehrkoerper' gibLehrerListe êinLehrkoerper gibLehrerListe. markiereLehrer: index einLehrkoerper markiereLehrer: index. gibMarkiertenLehrer êinLehrkoerper gibMarkiertenLehrer. istMarkierungGueltig êinLehrkoerper istMarkierungGueltig gibLehrkoerpername êinLehrkoerper gibLehrkoerpername.

In dieser Realisierung wird davon ausgegangen, daß die Klasse Lehrkoerper bereits die für den Aspekt vorgesehene Schnittstelle hat, so daß die Aspektklasse die Aufrufe lediglich an das von ihr referenzierte Objekt einLehrkoerper weitergeben muß. Es wäre auch denkbar, daß die Klasse Lehrkoerper eine vom Aspekt Auflistbar_Lehrkoerper abweichende Schnittstelle hat und der Aspekt die beiden Schnittstellen auch noch angleicht.

3


3.2


Die offensichtlichen Vorteile der Verwendung des Objektadapters für die Realisierung von Aspekten bestehen darin, daß die Aspekte als eigenständige Klassen klar im Entwurf erkennbar sind und daß diese Lösung auch für Sprachen mit Einfachvererbung funktioniert. Dazu kommt, daß der Objektadapter ebenfalls eingesetzt werden kann, wenn die Schnittstelle des Materials nicht der für das Werkzeug benötigten Schnittstelle entspricht, der Aspekt aber mit Hilfe der vom Material gebotenen Operationen so implementiert werden kann, daß er die benötigte Schnittstelle realisiert. Diese Form, Aspektklassen so umzusetzen, daß dabei die Materialschnittstelle für ein Werkzeug angepaßt wird, läßt sich auch dort gewinnbringend einsetzen, wo Aspektvererbung möglich ist. Die in der abstrakten Aspektklasse deklarierten Operationen sind dann nicht in den Materialien zu sehen. Die Materialien bleiben auf ihre rein fachlich motivierte Schnittstelle beschränkt. Die werkzeugspezifischen Umgangsformen sind in den speziellen Adaptern definiert. Auch für die Weiterentwicklung eines Systems bietet diese Lösung gegenüber dem auf Seite 209ff. beschriebenen Konstruktionsansatz mit Hilfe der Aspektvererbung Vorteile. Soweit entsprechende Umgangsformen am Material überhaupt vorhanden sind, läßt sich ein Material ohne direkte Veränderung an einen neuen Aspekt anpassen.

3

446 Diskussion


3.2


Die Lösung mit Hilfe des Adaptermusters hat die negative Folge, daß für jedes Material eine konkrete Unterklasse des Adapters realisiert werden muß. Bei der Realisierung von allgemeinen Werkzeugen, wie z.B. eines Editors oder eines Auflisters, mit denen sehr viele unterschiedliche Materialien bearbeitet werden können, führt das zu einer »Inflation« von konkreten Adapterklassen. Damit werden Entwürfe undurchsichtig, was den Vorteil der expliziten Aspektklassen relativiert. Gravierender sind in vielen Kontexten die Probleme, die sich aus den zwei Objekten ergeben, aus denen das Material dann eigentlich besteht – Adapterobjekt und Materialobjekt. Das erste Problem ist der Verlust der Identität: Ein Material hat aus Sicht des Werkzeugs eine andere technische Identität als sein Adapter. In vielen Situationen benötigen wir aber die fachliche Identität von Materialien. Daher muß sichergestellt werden, daß trotz unterschiedlicher technischer Identität die fachliche Identität eines Materials auch nach der »Ankopplung« eines Adapters erhalten bleibt. Eine gangbare, aber recht komplexe Lösung bietet das in Kapitel 3.3.4 beschriebene Rollenmuster. Ein weiteres Problem kann auftreten, wenn die Idee ausgebaut wird, den fachlichen Kern eines Materials von seinen werkzeugbedingten Umgangsformen zu trennen. Dann liegt es nahe, Adapterobjekte neben ihrem Verweis auf das adaptierte Material mit weiteren

3

447 Probleme


3.2


448

Attributen zu versehen, um genau diese werkzeugbedingten Dienstleistungen zu realisieren. Dabei ist zu klären, wie ein Material abgespeichert werden soll. Dies mag bei Verwendung objektorientierter Datenbanken irrelevant sein, da dort ein Material Verweise auf all seine Adapterobjekte besitzt, nicht aber z.B. bei relationalen Datenbanken. Aus unserer Sicht sind dabei einige offene Fragen zu klären, wie beispielsweise: Muß ein Material immer mit allen seinen Adaptern gespeichert und wiederhergestellt werden? Was passiert, wenn verschiedene Adapterobjekte eines Materials in ihren Schnittstellen und ihren Attributen überlappend sind? Schließlich müssen wir das konstruktive Problem lösen, wie und von wem die Aspektobjekte erzeugt werden. Bei der Konstruktion über direkte Aspektvererbung können wir das Material einfach dem Werkzeug übergeben – jetzt müssen die zusätzlichen Adapterobjekte für die jeweilige Werkzeug-Material-Kopplung vorhanden sein. Das Werkzeug sollte das spezielle Adapterobjekt nicht kennen und somit auch nicht erzeugen. Es soll lediglich die abstrakte Aspektklasse benutzen. Eine mögliche Lösung wäre, ein »Klassenobjekt« der abstrakten Aspektklasse als Instanz für die späte Erzeugung von konkreten Adaptern zu verwenden. Diesem Aspektklassenobjekt kann dann das jeweilige Material als Spezifikation für den konkreten Adapter mitgegeben werden (s. Kapitel 3.3.4).

3


3.2


449

Aspektkonstruktion mit Hilfe des Dekorierermusters

Zusammenhang von Werkzeug und Material



Automat

Werkzeug- und Materialkopplung Trennung Interaktion und Funktion Aspekte Rückkopplung zwischen Funktion AspektObjekt- Dekorierer und Interaktion vererbung adapter

fachliche Behälter


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte


Umgebung Materialkoordinator

Wir haben zwei wesentliche Probleme der Aspektvererbung erkannt: Sie ist bei Sprachen mit Einfachvererbung nicht einsetzbar, und sie

3


3.2


450

erweitert das Material statisch um die durch den Aspekt festgelegten Eigenschaften. Besonders diese statische Festlegung ist diskussionswürdig. Wenn wir eine Aspektklasse als Oberklasse eines Materials definieren, muß die Materialklasse die Schnittstelle der Aspektklasse implementieren. Dabei wird ein Material aber z.T. um Eigenschaften erweitert, die sich nicht aus rein fachlichem Umgang mit diesem Material herleiten lassen, sondern die aus den Anforderungen eines interaktiven Werkzeugs resultieren. Jedes Materialexemplar hat diese Eigenschaften dann während seines gesamten Lebenszyklus. Tendenziell wird ein Material immer umfangreicher, je mehr Werkzeuge dieses Material bearbeiten können. Das Dekorierermuster (s. Abbildung 3-14 und [Gamma et al. 96]) ermöglicht, den Materialien Eigenschaften erst zur Laufzeit bei Bedarf hinzuzufügen.

3

Lösung


3.2


451

Musterschema Komponente Operation()

KonkreteKomponente

Dekorierer

Operation()

Operation()

Komponente Komponente->Operation();

KonkreterDekoriererA

KonkreteDekoriererB

Operation()

Operation()

ZusatzZustand

ZusatzFunktion()

Dekorierer::Operation(); ZusatzFunktion();

Abb. 3-14 Struktur des Dekorierermusters

3


3.2


452

Da ein Dekorierer für Klienten sowohl an Stelle des ursprünglichen Objekts als auch in einer polymorphen Spezialisierung agieren kann, ist er für die Anwendung weniger auffällig als ein Adapter. Diese Eigenschaften machen wir uns zunutze, um Aspekte dynamisch zu realisieren. In Abbildung 3-15 haben wir ein Material als konkrete Komponente des Dekorierermusters eingesetzt. Die für dieses Material relevanten Aspekte sind als Baum von Dekorierern angeordnet. Damit können wir die Aspekte eines Materials unabhängig vom Material realisieren. Voraussetzung ist wie beim Objektadapter, daß das Material die erforderliche Basisfunktionalität für die Aspekte zur Verfügung stellt.

3


3.2


453 Abb. 3-15 Realisierung von

Material

dynamischen Aspekten mit dem Dekorierermuster

WerkzeugA

Konkretes Material

Aspekt Dekorierer

WerkzeugB

Aspekt DekoriererA

Aspekt DekoriererB

In dieser »reinen« Form ist das Muster auch ohne Mehrfachvererbung einsetzbar und somit ähnlich wie das Adaptermuster zur Realisierung von Aspekten in Sprachen ohne Mehrfachvererbung verwendbar. Allerdings geht dann eine wesentliche Eigenschaft der Aspekte verloren, nämlich daß sie nur die Schnittstelle zeigen, die aus Sicht eines

3

Diskussion


3.2


454

Werkzeugs erforderlich ist. Denn die Aspektdekorierer haben immer die volle Schnittstelle des Materials. Ein weiterer Nachteil ist, daß die Werkzeuge die konkreten Aspektdekorierer jedes Materials kennen müssen und die Aspektklasse nicht mehr eine reine Schnittstellendefinition ist, auf die sich das Werkzeug beziehen kann. Wir können in Sprachen mit Mehrfachvererbung die Aspektdekorierer von einer abstrakten Aspektklasse erben lassen. Dies haben wir in Abbildung 3-16 wieder am Pausenplanbeispiel illustriert.

PausenPlaner

Lehrerkarten -Werkzeug

FachlicherBehälter

Abb. 3-16 Aspektdekorierer mit Mehrfachvererbung

Sammlung _Auflistbar

AuflistbarDekorierer

Lehrkörper

Sammlung _Editierbar

AspektDekorierer

EditierbarDekorierer

3


3.2


455

Diese Verwendung des Dekorierermusters bietet uns eine flexible Möglichkeit, Materialobjekten Funktionalität dynamisch hinzuzufügen. Dies können wir mit statischer Aspektvererbung nicht erreichen. Zur Laufzeit können einem Material die Eigenschaften eines Aspekts hinzugefügt und wieder entfernt werden, indem einfach der entsprechende Aspektdekorierer hinzufügt und wieder entfernt wird. Eine konkrete Materialklasse unterstützt dann nicht mehr jede potentiell geforderte Funktionalität. Sie kann auf einen fachlichen Kern reduziert werden, dem die benötigte Funktionalität inkrementell durch Aspektdekorierer-Objekten hinzugefügt wird. Dies zahlt sich besonders dann aus, wenn Klassen und Objekte in mehreren Anwendungen eingesetzt werden. Sie tragen dann keine unbenutzte Funktionalität. Weiterhin lassen sich neue Aspektdekorierer unabhängig von den Materialklassen definieren. Generell gilt aber der Nachteil von Dekorierern. Ein Entwurf, der das Dekorierermuster häufig verwendet, führt oftmals zu Systemen, die aus vielen kleinen und auch noch gleichartig aussehenden Objekten zusammengesetzt sind. Die Objekte unterscheiden sich nur durch die Art und Weise ihrer Verbindung, nicht aber durch ihre Klasse oder den Wert ihrer Variablen. Obwohl diese Systeme leicht angepaßt werden können, sind sie schwer zu verstehen und zu debuggen.

3


3.2


Ein grundlegendes Problem teilt das Dekorierermuster mit dem Adaptermuster. Außer dem eigentlichen Materialobjekt existiert immer noch ein Stellvertreterobjekt. Damit wären wir wieder bei dem Identitätsproblem angekommen, das wir schon bei der Realisierung der Aspekte durch Adapter beschrieben haben. Insgesamt stellt sich die Frage, wann diese aufwendige und problematische Konstruktion sinnvoll ist. Denn das Dekorierermuster ist dort gut einsetzbar, wo der Dekorierer auch an Stelle des dekorierten Objekts verwendet werden soll. Aber genau das ist ja bei Aspekten nicht der Fall. Aspekte sind ja kein spezielles Material, sondern spezifizieren nur benötigte Eigenschaften aus Sicht eines Werkzeugs. Ein Vorteil ist dennoch erkennbar: Die Aspektkonstruktion mit Hilfe des Dekorierermusters vereinfacht die Subsystem-Bildung. Werkzeuge und die Aspektdekorierer können in ein Subsystem, während die Materialien in ein anderes untergebracht werden.

3

456

Einsetzbarkeit


3.2


457

Aspektkonstruktion durch Schnittstellendefinition Zusammenhang von Werkzeug und Material



Automat

Werkzeug- und Materialkopplung Trennung Interaktion und Funktion Aspekte Rückkopplung zwischen Funktion AspektObjekt- Dekorierer Schnittund Interaktion vererbung adapter stellendefinition

fachliche Behälter


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte



Eine Alternative zur Modellierung von Aspekten als Klassen bieten eigene Schnittstellendefinitionen. Mit dieser Konstruktion lassen sich benannte Schnittstellen zwischen Werkzeugen und Materialien ohne

3

Lösung


3.2


458

Verwendung von Klassenbeziehungen modellieren. Einer Klasse kann dann eine Schnittstelle hinzugefügt werden, ohne daß sie dazu von einer anderen erben müßte (s. Kapitel 2.1.12). Schnittstellen dieser Art 6 stellen die Protocols der Sprache Objective C und die Interfaces der Sprache Java dar. Damit sind auch die beiden Konstruktionsmöglichkeiten zur Realisierung von Aspekten vorgezeichnet. Bietet eine Programmiersprache wie Java als Compilersprache das Sprachmittel einer benannten Schnittstelle (Interface), dann kann jeder Aspekt als eigene Schnittstelle definiert werden. In Abbildung 3-17 sind dies Aspekt1 und Aspekt2. Werkzeuge können sich bei der Deklaration von Attributen auf diese Aspekte beziehen. Materialien, die diesen Aspekt erfüllen, deklarieren dies in ihrer Klassenschnittstelle. Der Compiler überprüft, ob die Werkzeuge nur Operationen der jeweiligen Schnittstelle benutzen und ob die Schnittstellen in den entsprechenden Materialklassen vorhanden sind. Wichtig ist, daß die Interfaces in Java unabhängig von der Klassenhierarchie, die in Java auf Einfachvererbung beruht, verwendet werden können. Dies soll in Abbildung 3-17 dadurch zum Ausdruck kommen, daß z.B. Material2 6.

Benannte Schnittstellen als statisches Sprachmittel

Das Sprachmittel Protocol soll im weiteren absichtlich nicht mit Protokoll (s. S. 28) übersetzt werden.

3


3.2


459

und Material3 nicht in einer gemeinsamen fachlichen Klassenhierar7 chie stehen. Werkzeug1

Werkzeug2

benutzt

Aspekt1

Aspekt2

Aspekt1 Schnittstelle erfüllt_Schnittstelle

Aspekt2 Aspekt2

Material2 erbt_von

Material1 Material3

Abb. 3-17 Aspekte als benannte

7.

Natürlich haben beide Klassen die gemeinsame Oberklasse Object.

3

Schnittstellen (Interfaces)


3.2


460

Eine alternative Konstruktion für Aspekte bieten die Schnittstellen von Objective C, Protocols genannt. Dort werden Protocols vom Compiler in gleicher Weise wie Interfaces in Java geprüft. Darüber hinaus sind Protocols wie Klassen in Smalltalk zur Laufzeit Objekte des Systems. Diese Grundidee kann dann auf Smalltalk übertragen werden, um dort Aspekte als benannte und geprüfte Schnittstellen zu realisieren. Zunächst wird für jeden Aspekt eine eigene Klasse konstruiert. Damit läßt sich eine Sammlung von Operationen unter einem definierten Namen zusammenzufassen. Als weiteres wird eine Oberklasse Aspekt realisiert, die eine Operation conformsTo: zur Verfügung stellt (s. unten). Diese Operation kann bereits in der Oberklasse implementiert werden. Sie prüft für alle Operationen des konkreten Aspekts, bei dem conformsTo: aufgerufen wird, ob diese auch bei dem als Parameter übergebenen (Material-) Objekt vorhanden sind. Damit kann zur Laufzeit an einem konkreten Material oder seiner Klasse überprüft werden, ob es einen Aspekt erfüllt. Diese Konstruktion basiert darauf, daß in Smalltalk auch Klassen Objekte sind und es mit den Klassen Behaviour, ClassDescription, MetaClass und Class einen festgelegten Mechanismus für den Zugriff auf ein umfangreiches Metaobjekt-Protokoll (s. Kapitel 2.1.15) zur Laufzeit gibt. Dieser Mechanismus erlaubt, auf das sogenannte

3


3.2


461

MethodDictionary, eine Tabelle aller Operationen einer Klasse, zuzugreifen und zu überprüfen, ob das zugehörige Objekt bestimmte Operationen zur Verfügung stellt. Es wird deshalb mit der Methode getSelectors diese Methodentabelle an die Variable protocols zugewiesen. conformsTo: einAspekt protocol := einAspekt getSelectors. ^protocol conform: [:selector | self respondsTo: selector].

Die Variable protocol hält eine Liste aller Operationen der Aspektklasse. Für jede einzelne dieser Operationen wird überprüft, ob das an conformsTo: übergebene Material diese Operation ebenfalls versteht. Hat das Material alle Operationen, die auch der Aspekt deklariert hat, so wird True, andernfalls False zurückgegeben. Nach dem oben gezeigten Schema wird die Kopplung von Werkzeugen und Materialien im Projekt KMU-Desktop der UBS konstruiert. Die Protocols werden bei der Klassendeklaration angegeben. Ansonsten gibt es eine eigene Typprüfung, die sicherstellt, daß ein Material zu einem Werkzeug paßt. Ein Test auf Methodenebene gibt es also

3


3.2


462

nicht. Aspekte werden als Protocols realisiert und bei jedem Material wird angegeben, welche Protocols es unterstützt. Die Grundideen sind: ❑ Jedes Protocol ist als Smalltalk-Klasse ohne Exemplarvaria-

blen definiert. ❑ In einer Protocol-Klasse werden Operationen als Standardim-

plementationen vorgegeben. Alle Protocol-Klassen haben eine gemeinsame Oberklasse. ❑ Klassen, die ein Protocol erfüllen sollen, erben ebenfalls von

einer gemeinsamen Oberklasse, der Klasse BaseObject. Die Materialklassen deklarieren an ihrer Schnittstelle, welche Protocols sie erfüllen, und implementieren die Schnittstelle des Protocol. Soweit Standardimplementationen von Protocol in den »erfüllenden« Klassen nicht redefiniert sind, werden 8 sie über einen sogenannten Mixin-Mechanismus hinzugefügt . Damit ist Mehrfachvererbung ohne eigene Zustände realisiert.

8.

Die konzeptionellen Ideen dazu und Teile der Implementation gehen auf Arbeiten von Bruno Schäffer und Martin Schnyder am UBILAB der UBS zurück.

3


3.2


463

❑ Tests, die sich auf die Metaebene beziehen (z.B. ob ein Material

aufgrund seines Protocol von einem Werkzeug bearbeitet werden kann, werden in einer eigenen neuen Metaklasse (der sogenannten MetaBaseClass) behandelt. Im einzelnen sieht dies so aus: Die Oberklasse von Klassen (BaseObject), die Protocols haben können, unterstützt u.a. die folgende Schnittstelle: allProtocols "Return an array of all protocol classes supported by the receiver and the superclasses of its class. Superclasses of supported protocol classes are not listed." supportsProtocol: aProtocol "Check whether the receiver supports a protocol."

Im folgenden Beispiel wird eine Geschäftsfallmappe als Unterklasse von FachlicherBehaelter konstruiert. Der Aspekt, den diese Mappe unterstützt, ist IstGenerierbar. Dieses Protocol wird explizit bei der Deklaration der Klasse angegeben.

3


3.2


464

FachlicherBehaelter subclass: #GeschaeftsfallMappe protocolNames: 'IstGenerierbar' classInstanceVariableNames: '' instanceVariableNames: 'status bearbeitungsHistorie kundenInformation ' classVariableNames: '' poolDictionaries: 'EventList '

In Smalltalk werden neue Klassen mit Hilfe von Meta-Klassen erzeugt. Die Klasse GeschaeftsfallMappe wird durch Aufruf der Methode subclass:protocolNames:classInstanceVariableNames:instanceVariableNames:poolDictionaries: am Klassenobjekt FachlicherBehaelter deklariert. Um die Protocols einer Klasse bereits bei ihrer Erzeugung beschreiben zu können, muß die Klasse Class neben den üblichen Klassenerzeugungsmethoden nun eine weitere Methode, subclass:protocolNames:classInstanceVariableNames:instanceVariableNames: poolDictionaries:, zur Verfügung stellen. Ein Exemplar der Klasse GeschaeftsfallMappe läßt sich nun nach seinen Protocols fragen (allProtocols) oder danach, ob es ein bestimmtes Protocol unterstützt (supportsProtocol:).

3


3.2


465

Da im Projekt KMU-Desktop alle Materialien unter eine Oberklasse angeordnet sind (damit sie Aspekte als Protocols haben können), kann dies in der Werkzeugkonstruktion ausgenutzt werden. Ein Werkzeug ist nicht nur in der Lage zu prüfen, ob ein übergebenes Material einen Aspekt (als Protocol) erfüllt; das Werkzeug kann sich von der Umgebung auch alle Materialien zu einem Aspekt geben lassen, wie das nachfolgende Codefragment zeigen soll. Dadurch kann erreicht werden, daß der Benutzer mit Hilfe des Werkzeugs alle vom Werkzeug bearbeiteten Materialien direkt erzeugen kann. Damit nicht jedes Werkzeug die Überprüfung selbst implementieren muß, ist ein Materialhändler realisiert worden, der in Analogie zum Produkthändler (s. Kapitel 3.3.4) die Vermittlung der entsprechenden Materialien übernimmt. MaterialHaendler>>gibPassendZuProtokoll: aProtocol ^self rootClass withAllSubclasses select: [:subclass| subclass supportsProtocol: aProtocol]

Die Operation gibPassendZuProtokoll: iteriert über alle Unterklassen der abstrakten Materialoberklasse. Jede Materialklasse wird

3


3.2


466

gefragt, ob es das gewünschte Protocol unterstützt. Wenn ja, wird es in die Collection der Materialklassen aufgenommen, die die Operation als Ergebnis zurückliefert. Aspektkonstruktion durch Werkzeugunterstützung Zusammenhang von Werkzeug und Material



Automat

Werkzeug- und Materialkopplung Trennung Interaktion und Funktion Aspekte Rückkopplung zwischen fachliche Funktion Behälter AspektObjekt- Dekorierer Schnitt- Werkzeug und Interaktion untervererbung adapter stellendefinition stützung


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte



3


3.2


467

Wir haben die Aspektkonstruktion mit Hilfe von Aspektobjekten vorgestellt. Dabei wird zur Laufzeit geprüft, ob sich Materialien und Werkzeuge »aspektkonform« verhalten: Jedes Material bietet die Operationen seiner Aspekte an; jedes Werkzeug benutzt nur die Materialoperationen, die im Aspekt deklariert sind. Der wirklich laufzeitkritische Teil dieser Prüfung muß konzeptionell aber nur einmal vorgenommen werden, nämlich dann, wenn ein Werkzeug oder ein Material erzeugt wird. Ist einmal sichergestellt, daß ein Material alle geforderten Aspektoperationen anbietet oder daß ein Werkzeug nur Aspektschnittstellen benutzt, wird sich dies während seiner Lebenszeit nicht mehr verändern. Bei der Verwendung muß dann nur noch die richtige Zuordnung von Werkzeugen und Materialien sichergestellt werden. Wenn wir eine Sprache wie Smalltalk benutzen, dann lassen sich die aufwendigen Überprüfungen vom Erzeugungszeitpunkt eines Objekts auf den Zeitpunkt seiner Klassendefinition verschieben. Statt zur Laufzeit des Programms findet die Prüfung auf Aspektkonformität bei der Programmerstellung statt. Dazu müssen entsprechende Entwicklungswerkzeuge bereitgestellt werden. Dies ist in Smalltalk kein großes Problem, da die verbreiteten Smalltalk-Versionen mit einer offenen Entwicklungsumgebung angeboten werden. In einer solchen Umge-

3

Lösung


3.2


468

bung lassen sich die Browser und Programmtexteditoren so modifizieren, daß Aspekte als eigene Kategorien bekannt sind und entsprechend beim Parsen mitgeprüft werden können. Ein Entwicklungswerkzeug zum Bearbeiten von Aspekten, kurz Aspekt-Browser, wird eingesetzt, um die Operationen eines Aspektes in die Materialklassen hinein zu kopieren (s. Abbildung 3-18). So können sowohl Aspekte als abstrakte Oberklassen realisiert als auch Standardimplementationen für Operationen vorgegeben werden.

3


3.2


469 Abb. 3-18 Das Smalltalk-Werkzeug Aspekt-Browser

Mit dem Aspekt-Browser können zunächst neue Aspektklassen definiert werden. Hierzu werden Aspekte als eigene Klassen modelliert, die nur aus Methodenrümpfen bestehen. Die Methodenrümpfe setzen

3


3.2


470

sich aus einem Operationsnamen und einer textuellen Beschreibung dessen, was die Operation bewirken soll, zusammen. Ist für einen Aspekt eine Standardimplementation vorhanden, so wird sie ebenfalls eingetragen. Diese Standardimplementation dient lediglich als Vorlage für die materialspezifische Implementation. Um den Zusammenhang zwischen einer Aspekt- und einer Materialklasse festzulegen, wird ebenfalls der Aspekt-Browser verwendet. Soll ein Material einem Aspekt genügen, wählt man erst das Material und dann den Aspekt aus der Menge der in der Bibliothek vorhandenen Aspekte aus. Der Aspekt-Browser kopiert dann alle Operationen aus der entsprechenden Aspektklasse in die Materialklasse. In der Materialklasse werden alle Operationen eines Aspekts in einer nach 9 dem Aspekt benannten Message Category geführt. Danach ist es die Aufgabe des Entwicklers, die kopierten Operationen zu implementieren, wenn sie nur als textuelle Beschreibung vorliegen, oder die Standardimplementation aus der Aspektklasse durch eine materialspezifische zu ersetzen. Im Anschluß daran kann der Aspekt-Browser verwendet werden, um zu prüfen, ob alle Operationen implementiert sind. 9.

Eine Message Category (auch Protocol genannt!) ist in Smalltalk eine Sammlung von zusammengehörigen Operationen.

3


3.2


471

Der Aspekt-Browser stellt durch das Kopieren und Prüfen von Code einen »implementiert die Schnittstelle von« Zusammenhang zwischen zwei Klassen her. Dadurch bietet er eine Möglichkeit, in Smalltalk Aspekte zu verwenden. Eine ausführliche Diskussion des Aspekt-Browsers findet sich in [Riehle & Schnyder 94]. Diskussion der Konstruktionsansätze zur Werkzeugund Materialkopplung

Wir haben das Konzept der Aspekte zur Modellierung der Kopplung zwischen Werkzeug und Material vorgestellt. Aspekte machen das Zusammenpassen von Werkzeugen und Materialien explizit. Sie zeigen im Entwurf, welche Eigenschaften ein Werkzeug von seinen Materialien erwartet. Aspekte lassen sich ebenso zwischen Automaten und Materialien einsetzen. Eingeschränkt können sie für jede fachlich wichtige Beziehung zwischen Entwurfskomponenten verwendet werden. Die verschiedenen Konstruktionsansätze zur Realisierung von Aspekten sind: ❑ Aspektvererbung: Materialklassen erben von ihren Aspekt-

klassen. Die Werkzeuge verwenden die konkreten Materialien polymorph unter der jeweiligen Schnittstelle der Aspektklasse.

3


3.2


472

– Wesentliche Vorteile: Bereits zur Übersetzungszeit kann statisch geprüft werden, ob ein Material einen Aspekt erfüllt und ob ein Werkzeug seine Materialien nur unter dem entsprechenden Aspekt verwendet. Das Verhalten der Materialien läßt sich eingegrenzt vorgeben. – Wesentliche Nachteile: Der Konstruktionsansatz basiert auf Mehrfachvererbung. Dabei wird die Vererbung allerdings nicht zur fachlichen Klassifikation eingesetzt, was verwirrend sein kann. Aspektvererbung bindet die Eigenschaften eines Aspekts statisch an die Materialien, so daß tendenziell neue Werkzeuge die Schnittstelle des Materials »aufblähen«. Die Aufteilung in Subsysteme ist schwierig. – Einsatz: Bei Sprachen mit Mehrfachvererbung empfiehlt sich der Ansatz für mittlere Arbeitsplatzanwendungen mit mehreren Werkzeugen, die auf unterschiedlichen Materialien arbeiten. ❑ Verwendung

des Objektadaptermusters: Das Werkzeug benutzt eine allgemeine Aspektklasse. Davon werden spezielle Aspektadapterklassen abgeleitet. Deren Exemplare bieten die geforderte Schnittstelle des Aspekts und realisieren sie mit Hilfe der Operationen des benutzten Materialobjekts.

3


3.2


473

– Wesentliche Vorteile: Die Aspektkonformität kann statisch geprüft werden, und die Aspekte sind als eigene Klassen im Entwurf erkennbar. Die Materialschnittstelle muß nur prinzipiell für den Aspekt geeignet sein; sie kann entsprechend in der Aspektadapterklasse angepaßt werden. Damit bleibt das Material »schlank«. Dieser Ansatz erleichtert auch die inkrementelle Weiterentwicklung. – Wesentliche Nachteile: Viele konkrete Adapterklassen führen zu unübersichtlichen Entwürfen. Durch das zusätzliche Adapterobjekt entsteht ein Identitätsproblem. »Schwergewichtige« Adapterobjekte mit eigenen Zuständen müssen u.U. gesondert zum Material gespeichert werden. Die Adapterobjekte müssen geeignet erzeugt werden. – Einsatz: Für Sprachen mit Einfachvererbung und für große Anwendungen mit unterschiedlichen Arbeitsplatztypen, zwischen denen Materialobjekte »migrieren«, ist dieser Ansatz gut geeignet. Er kann evtl. in Kombination mit Aspektvererbung eingesetzt werden. ❑ Verwendung des Dekorierermusters: Zu jedem Material wird

ein allgemeiner Aspektdekorierer modelliert. Er erbt die Schnittstelle des Materials und ist Wurzel des konkreten

3


3.2


474

Aspektdekoriererbaums. Die konkreten Aspektdekorierer erweitern die Materialschnittstelle ggf. um zusätzlich geforderte Aspektoperationen. – Wesentliche Vorteile: Dieser Konstruktionsansatz ist eingeschränkt auch bei Sprachen mit Einfachvererbung verwendbar. Er fügt aspektbedingte Eigenschaften additiv zum Material hinzu. Aspektdekorierer können zur Laufzeit ausgetauscht werden. Die Aufteilung eines Rahmenwerks in Subsysteme wird erleichtert. – Wesentliche Nachteile: Wie beim Objektadapter bringt das Stellvertreterobjekt ein Identitätsproblem. Der Aspektdekorierer hat zudem die gesamte Schnittstelle des Materials. Viele konkrete Aspektklassen und -objekte machen den Entwurf statisch und dynamisch unübersichtlich. Der Ansatz ist nur bei Mehrfachvererbung wirklich softwaretechnisch sauber. – Einsatz: Für rahmenwerkbasierte Systeme mit häufig wechselnden interaktiven Einsatzkontexten geeignet, zwischen denen Materialobjekte möglichst leichtgewichtig ausgetauscht werden müssen.

3


3.2


475

❑ Verwendung einer benannten Schnittstellendefinition: Statt

einer Aspektklasse wird eine benannte Schnittstelle definiert. Jedes Material deklariert die von ihm erfüllten Schnittstellen. Werkzeuge kennen ihre Materialien nur über die entsprechende Schnittstelle. In Sprachen mit ausreichendem Metaobjekt-Protokoll können benannte Schnittstellen als Schnittstellenobjekte modelliert werden. – Wesentliche Vorteile: Benannte Schnittstellen als Sprachmittel ermöglichen, Aspekte durch ein eigenes Modellierungsmittel im Entwurf zu verdeutlichen. Die statische Prüfung der Aspektkonformität gleicht der Aspektvererbung. Schnittstellenobjekte sind ein Ansatz, in Sprachen mit Einfachvererbung Aspekte zur Laufzeit zu realisieren und zu prüfen. – Wesentliche Nachteile: Benannte Schnittstellen können kein Verhalten festlegen. Schnittstellenobjekte führen zu mehr oder minder aufwendigen Laufzeitprüfungen und zusätzlichem Konstruktionsaufwand. – Einsatz: Bei Verwendung von Sprachen wie Java oder Objective C als Alternative zur Aspektvererbung. In Smalltalk als gangbarer Konstruktionsansatz für Aspekte.

3


3.2


476

❑ Werkzeugunterstützung: Bei der Programmierung von Werk-

zeugen und Materialien sichern Entwicklungswerkzeuge die Aspektkonsistenz. Aspekte mit Schnittstellen und Standardimplementationen können vorgegeben werden. Das Entwicklungswerkzeug prüft, ob ein Werkzeug nur die deklarierten Aspektschnittstellen verwendet und ob ein Material alle erforderlichen Aspektoperationen implementiert. – Wesentliche Vorteile: In einer Sprache wie Smalltalk läßt sich die Prüfung von Aspektkonformität von der Laufzeit auf die Entwicklungszeit verlagern. – Wesentliche Nachteile: Ohne Werkzeugunterstützung ist dieser Ansatz nicht realisierbar. Er setzt voraus, daß eine Sprache als Laufzeitsystem in sich selbst weiterentwickelt werden kann und ein mächtiges Metaobjekt-Protokoll besitzt. Auch mit Werkzeugunterstützung ist der Ansatz unsicher, da die Standardwerkzeuge der Entwicklungsumgebung keine Aspekte kennen und ihr Einsatz zu inkonsistenten Systemen führen kann. – Einsatz: Für Smalltalk sicher eine Alternative zu Schnittstellenobjekten, da keine Laufzeiteffekte entstehen.

3


3.2


477

❑ Keine Aspekte: Werkzeuge benutzen ihr Material direkt. Ein

Werkzeug kennt die volle Schnittstelle des Materials. Polymorphie wird nur dann ausgenutzt, wenn das Material selbst eine Vererbungshierarchie bildet. – Wesentliche Vorteile: Der Verzicht auf Aspekte vereinfacht natürlich zunächst die Werkzeug- und Materialkopplung, da konstruktiv und konzeptionell für die Verwendung eines Materials durch ein Werkzeug kein zusätzlicher Aufwand erforderlich ist. Die Kopplung ist zudem typsicher. – Wesentliche Nachteile: Wenn mehr als ein Material von einem Werkzeug verwendet werden soll, ist konstruktiver Aufwand und die Pflege mehrfacher Schnittstellen erforderlich. Wenn ein Material von mehreren Werkzeugen bearbeitet werden soll, ist unklar, welche Teile der Materialschnittstelle für welches Werkzeug geeignet sind. Die Kopplung von Werkzeugen und Materialien ist im Entwurf nicht ausdrücklich gemacht. Der Verzicht auf Aspekte macht Entwürfe recht änderungsunfreundlich und wenig weiterentwickelbar. – Einsatz: Für kleine und »junge« Projekte ist der Verzicht auf Aspekte tragbar. Noch nicht sehr ausgereifte Entwürfe zeigen oft eine Eins-zu-eins-Beziehung zwischen Werkzeug

3


3.2


478

und Material. In Sprachen wie Smalltalk mit dynamischer Typisierung werden oft Prototypen oder erste Pilotsysteme ohne Aspekte entwickelt. Sehr spezielle Materialien erfordern gelegentlich eine enge Werkzeugkopplung: Das Werkzeug muß die volle Materialschnittstelle kennen. Dies gilt auch für Spezialwerkzeuge, die nur für ein Material eingesetzt werden.

3


3.2


479

3.2.2 Trennung von Funktion und Interaktion Zusammenhang von Werkzeug und Material




Trennung TrennungInteraktion Interaktion und undFunktion Funktion Rückkopplung zwischen Funktion und Interaktion

fachliche Behälter


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte


Umgebung

Materialkoordinator

Der WAM-Ansatz greift ein wichtiges Architekturprinzip interaktiver Softwaresysteme auf – die Trennung von Interaktion und Funktion.

3


3.2


480

Diese Trennung ist bereits exemplarisch im sogenannten Model-ViewController-Paradigma des Smalltalk-Systems realisiert worden (s. [Krasner & Pope 88, Goldberg 90] – wir haben schon im Vorwort auf diesen wichtigen Einfluß hingewiesen. Das Konzeptionsmuster Zusammenhang von Werkzeug und Material definiert die grundlegende Aufgabenverteilung von Werkzeug und Material: Ein Werkzeug läßt sich handhaben. Es präsentiert dabei das Material und ermöglicht dessen Bearbeitung. Durch geeignete Funktionalität wird das Material für die Bearbeitung zugänglich. Im Entwurfsmuster Werkzeug- und Materialkopplung haben wir dargestellt, daß Aspekte das Zusammenpassen des interaktiven Werkzeugs mit der Funktionalität des Materials definieren. Jedes Werkzeug läßt sich seinerseits in Interaktion und Funktion aufteilen. Ein Werkzeug soll so in einen interaktiven und einen funktionellen Teil aufgeteilt werden, daß beide Teile softwaretechnisch weitgehend unabhängig voneinander modelliert und konstruiert werden können. Besonders wichtig ist, daß wir den interaktiven Teil verändern können, ohne den funktionellen Teil anpassen zu müssen.

Problem

Wir haben Softwarewerkzeuge als interaktiv definiert. Dazu haben wir jedem Werkzeug eine fachliche Funktionalität sowie eine Handhabung und Präsentation zugewiesen. Die Leitfragen dabei waren:

Kontext

3


3.2


481

❑ Funktion: Zu was ist ein Softwarewerkzeug fachlich gut? ❑ Handhabung: Wie wird ein Softwarewerkzeug gehandhabt? ❑ Präsentation: Wie wird ein Softwarewerkzeug und das bear-

beitete Material dargestellt? Offenkundig muß ein Werkzeug zu etwas gut sein. Es versetzt uns in die Lage, Aufgaben dadurch zu erledigen, daß wir mit seiner Hilfe geeignete Materialien bearbeiten. Ein Werkzeug hat also eine fachliche Funktionalität. Das Konzeptionsmuster Zusammenhang von Werkzeug und Material gibt Hinweise, wie die Funktionalität eines Werkzeugs entworfen werden kann. Da das Werkzeug nie von sich aus aktiv wird, sondern immer vom Benutzer gehandhabt wird, ist Handhabung ein elementares Merkmal. Die fachliche Funktionalität eines Werkzeugs ist nur über seine Handhabung zugänglich. Im Konzeptionsmuster Zusammenhang von Werkzeug und Material haben wir darauf hingewiesen, daß die fachliche Funktionalität durch unterschiedliche Arten der Handhabung realisiert werden kann. Dies zeigt, daß die Handhabung zwar auf die Funktionalität bezogen ist, aber doch relativ unabhängig von ihr umgesetzt werden kann.

3


3.2


482

Damit ein Werkzeug benutzt werden kann, muß es selbst eine Repräsentation besitzen. Da ein Werkzeug den Bearbeitungszustand seines Materials anzeigt, muß es das Material präsentieren. Nur über diese Präsentation kann ein Werkzeug seinem Benutzer die Rückkopplung geben, die dieser für ein sicheres Arbeiten mit Werkzeug an Material benötigt. Handhabung und Präsentation gehören eng zusammen. Damit ergibt sich folgende konzeptionelle Aufteilung: ❑ Die fachliche Funktionalität eines Werkzeugs bezeichnen wir

als seine Funktion. ❑ Die Art und Weise der Handhabung und die Form der Präsen-

tation eines Werkzeugs bezeichnen wir als seine Interaktion. Zu den fachlichen Überlegungen kommen softwaretechnische hinzu: Bei der Entwicklung eines Werkzeugs zeigt sich die Qualität von Handhabung und Präsentation erst im Gebrauch. Entsprechende Forderungen nach einer veränderten Handhabung oder Präsentation sollten demnach umgesetzt werden können, ohne daß die fachliche Funktionalität angepaßt werden muß. Die Präsentation eines Werkzeugs ist abhängig von den konkreten Oberflächenelementen. Auch hier sind Änderungen einzukalkulieren. Es sollte möglich sein, die Interaktion eines Werkzeugs durch den Aus-

3


3.2


483

tausch von Fenstersystemen oder GUI-Rahmenwerken zu verändern, ohne daß davon die Funktion betroffen ist. Unterteile ein Werkzeug grundsätzlich in eine Funktionskomponente (FK) und eine Interaktionskomponente (IAK). Die FK realisiert die Funktion eines Werkzeugs; die IAK die Interaktion. Kombiniere FK und IAK so, daß eine IAK ihre FK kennt und benutzt, während die FK möglichst keinerlei Kenntnis von ihrer IAK haben soll. Dadurch wird die primäre Kontrollflußrichtung vom Benutzer in das System hinein abgebildet und die Entkopplung der IAK von der FK möglich. Aus der Diskussion im Abschnitt Kontext ergibt sich folgende Aufgabenteilung zwischen FK und IAK:

Lösung

❑ Die Funktionskomponente ist der bewirkende und sondie-

rende Teil des Werkzeugs. In ihr wird die fachliche Funktionalität des Werkzeugs festgelegt. Die FK bearbeitet das Material und kennt den Arbeitszusammenhang, der durch das Werkzeug unterstützt wird. Zur Bearbeitung von Materialien benutzt die Funktionskomponente Operationen, die in einer oder in mehreren Aspekten spezifiziert sind. Um den Arbeitszusammenhang unterstützen zu können, verwaltet die FK einen Arbeitszustand, das Werkzeuggedächtnis.

3


3.2


484

❑ Die Interaktionskomponente legt die Benutzungsschnittstelle

des Werkzeugs fest. Dazu nimmt sie Ereignisse entgegen, ruft die FK und steuert die Präsentation an der Oberfläche. Damit die IAK von den konkreten Handhabungsformen und dem verwendeten Fenstersystem abstrahieren kann, benutzt sie im Regelfall für die konkrete Handhabung und Präsentation sogenannte Interaktionstypen (vgl. Kapitel 3.2.4). Ein Werkzeug ist technisch als ein sogenanntes reaktives System aufgebaut: Jede Werkzeugaktivität wird durch eine explizite Aktion des Benutzers, z.B. durch einen Mausklick oder einen Tastenanschlag, ausgelöst. Diese Aktionen werden als ein Strom von Ereignissen an das Werkzeug geleitet. Das Werkzeug reagiert auf jede Benutzeraktion. Dazu werden diese Ereignisse von der IAK interpretiert. Die IAK setzt die Ereignisse in Aufrufe der FK oder in eine geänderte Präsentation um. Die FK bearbeitet in geeigneter Weise über die entsprechenden Aspekte das Material. Damit ist die primäre Kontollflußrichtung in einem Werkzeug festgelegt (s. Abbildung 3-19). Die bisher skizzierte Aufteilung in FK und IAK legt Zuständigkeitsbereiche innerhalb eines Werkzeugs fest. Dies trägt zur besseren Verständlichkeit des Entwurfs bei. Die Entwurfsziele Flexibilität und Wiederverwendbarkeit werden unterstützt.

3

Werkzeug als reaktives System


3.2


485

Benutzeraktionen

Strom von Ereignissen

Abb. 3-19 Ein Werkzeug als reaktives Interaktionskomponente

System Softwarewerkzeug

Funktionskomponente

Aspekt

Material

Die Benutzungsschnittstelle eines Werkzeugs kann weitgehend unabhängig von der Funktionalität des Werkzeugs verändert werden. Da die fachlichen Komponenten des Systems – nämlich Funktionskomponente, Aspekte und Materialien – keine Annahmen über die interaktive Umgebung machen, in der sie eingebettet sind, können sie mit überschaubarem Aufwand auf unterschiedliche Systemplattformen portiert werden.

3


3.2


486

Konstruktion der Interaktionskomponente Zusammenhang von Werkzeug und Material




Trennung TrennungInteraktion Interaktion und undFunktion Funktion Rückkopplung zwischen Funktion Interaktionskomponente und Interaktion

fachliche Behälter


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte


Umgebung

Materialkoordinator

Konstruiere für jede konkrete Interaktionskomponente eine eigene Klasse, die die Aufgaben der IAK kapselt. Die Aufgaben der IAK sind durch ihre Zuständigkeit für die Interaktion innerhalb eines reaktiven Systems festgelegt. Jede Aktion eines

3

Lösung


3.2


Benutzers kommt über die Eingabekanäle als sogenanntes Systemereignis (z.B. der linke Mausknopf wurde auf einem bestimmten Punkt des Bildschirms gedrückt) in den Ereigniskontext eines Werkzeugs. Dazu nutzen wir heute den Event Dispatcher, d.h. den normalen Verteilungsmechanismus für Systemereignisse in Fenstersystemen. Die Ereignisse gelangen von außen nicht unmittelbar in die IAK eines Werkzeugs. Die Interaktionskomponente verwendet für die Realisierung der Interaktion vorgefertigte Bausteine, die Interaktionstypen (s. Entwurfsmuster Interaktionstypen, Kapitel 3.2.4). Interaktionstypen kapseln das konkrete Fenstersystem und wandeln die Systemereignisse (das sind von der Systembasis generierte Ereignisse) in Programmereignisse (darunter versteht man die innerhalb des Anwendungsprogramms generierten Ereignisse) um. Dadurch abstrahieren wir von der konkreten Systembasis. Die Interaktionskomponente ist damit eine Hülle um Interaktionstypen-Objekte.

3

487

Interaktionstypen


3.2


488

Interaktionskomponente (IAK): Die Interaktionskomponente realisiert Handhabung und Präsentation eines Softwarewerkzeugs. Sie abstrahiert mit Hilfe von Ein- und Ausgabekomponenten, den sogenanntenInteraktionstypen (z.B. Knöpfe, Menüs), vom zugrundeliegenden Fenstersystem und ruft diese Interaktionstypen zur Darstellung und Benutzereingabe auf. Eine Interaktionskomponente nimmt einen Strom von Systemereignissen, die durch Aktionen des Benutzers ausgelöst werden, als Programmereignisse entgegen und interpretiert sie. Dabei setzt sie präsentationsbezogene Ereignisse (z.B. neue Farbeinstellungen) selbst um und leitet anwendungsbezogene Ereignisse als Aufrufe an ihre FK weiter.

Als zentrale Aufgaben der Interaktionskomponente verbleiben damit die Interpretation der Programmereignisse und die Verwaltung der Benutzungsoberfläche. Die Interpretation von Programmereignissen bedeutet, daß die IAK entscheidet, ob ein Ereignis als Aufruf an die Funktionskomponente weitergegeben wird, oder ob daraus nur eine

3


3.2


489

veränderte Präsentation an der Oberfläche folgt. Um die Oberfläche zu aktualisieren, aktiviert die IAK geeignete Interaktionstypen. Die konkrete Präsentation der Interaktionstypen und ihre Anordnung nach bestimmten Layoutstrategien (horizontal, vertikal, proportional etc.) ist in heutigen Fenstersystemen nicht mehr Aufgabe der IAK. Dieser Teil der Werkzeuggestaltung wird separat mit einem Entwicklungswerkzeug (GUI-Builder) festgelegt. Die daraus resultierende Oberfläche wird erst zur Laufzeit mit den Interaktionstypen verknüpft. Um die Aufgabenteilung zwischen IAK und FK aufrecht zu erhalten, darf die Interaktionskomponente keine Annahmen über den logischen Zusammenhang von Operationen der Funktionskomponente oder Ergebnisse von Operationsaufrufen machen. So wird die IAK nach dem Aufruf einer verändernden Operation der Funktionskomponente die Darstellung von Informationen an der Oberfläche nicht ohne weiteres von sich aus verändern. Denn dies würde bedeuten, daß die IAK die Wirkung eines Operationsaufrufs auf den Zustand der FK kennt. Damit wäre die semantische Kapselung von Operationen in der FK aufgehoben. Eine Lösung für das so entstehende Rückkopplungsproblem diskutieren wir im Entwurfsmuster Rückkopplung zwischen Funktion und Interaktion (s. Kapitel 3.2.3).

3

Aufgabenteilung zwischen IAK und FK


3.2


490

Konstruktion der Funktionskomponente Zusammenhang von Werkzeug und Material




Trennung TrennungInteraktion Interaktion und undFunktion Funktion Rückkopplung zwischen Funktion Interaktionskomponente Funktionskomponente und Interaktion

fachliche Behälter

Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte


Umgebung


Materialkoordinator

Konstruiere für jede konkrete Funktionskomponente eine eigene Klasse, die die Aufgaben der FK kapselt.

3

Lösung


3.2


491

Die Funktionskomponente ist der bewirkende und sondierende Teil eines Werkzeugs. Hier werden die Leistungen eines Werkzeugs implementiert. Wir legen in der FK fest, welche anwendungsbezogenen Handlungen mit dem Werkzeug verrichtet werden können.

Funktionskomponente (FK): Die Funktionskomponente realisiert die fachliche Funktionalität eines Softwarewerkzeugs. Sie bearbeitet das Material über die Schnittstellen der entsprechenden Aspekte. Eine Funktionskomponente bietet mittels sondierender Operationen Informationen über den eigenen Bearbeitungszustand und den Bearbeitungszustand des Materials an. Sie verwaltet den eigenen Bearbeitungszustand, das Werkzeuggedächtnis, das von den Aktivitäten des Benutzers und dem Materialzustand abhängig ist.

In der Funktionskomponente werden die folgenden Entwurfsentscheidungen gekapselt:

3

Zuständigkeit der FK


3.2


492

❑ Zugriff auf das konkrete bearbeitete Material. Die Interak-

tionskomponente ruft zur Bearbeitung des Materials immer die FK und übergibt ihr entsprechende Informationen. Umgekehrt erhält die IAK über eine materialunabhängige Schnittstelle von der FK Informationen zur Präsentation des Materials. Die IAK hat keinen direkten Zugriff auf das Material. ❑ Veränderungen am Material durch die FK. Die IAK kann sich

nur insofern über den Bearbeitungszustand des Materials informieren, als an der FK entsprechende sondierende Operationen angeboten werden. Das Material veranlaßt nie direkt eine Darstellungsänderung. ❑ Der Arbeitszusammenhang zwischen verschiedenen Materia-

lien während der Bearbeitung durch ein Werkzeug. Die FK stellt für einen Arbeitszusammenhang sicher, daß die verschiedenen beteiligten Materialien konsistent bearbeitet werden. Daher kann die IAK nicht zu jedem Zeitpunkt alle verändernden oder sondierenden Operationen der FK aufrufen, sondern nur, wenn die FK in einem dafür geeigneten Arbeitszustand ist. Entsprechende Tests an der Schnittstelle ermöglichen, den Arbeitszustand der FK festzustellen.

3


3.2


Um die Trennung zwischen Interaktion und Funktion zu garantieren, darf die Funktionskomponente keine Annahmen über die Handhabung und Präsentation der Interaktionskomponente machen. Hier gilt die Argumentation verstärkt, die wir zur Unabhängigkeit der IAK vorgetragen haben. Eine FK soll nicht wissen, was auf welche Weise an der Oberfläche präsentiert ist und wie die Handhabung realisiert ist. Deshalb ruft die FK die IAK auch nicht direkt, um Darstellungsveränderungen zu bewirken. Damit sind wir wieder bei dem Rückkopplungsproblem zwischen den beiden Komponenten, das wir im Entwurfsmuster Kopplung von FK und IAK behandeln.

493 Trennung IAK und FK

Vorgehen bei der Entwicklung von IAK und FK

Die Trennung in Funktions- und Interaktionskomponente führt zu der Frage, in welcher Reihenfolge diese Komponenten entwickelt werden sollten. Auch hier gilt, was wir zur generellen Leitlinie unseres Ansatzes erhoben haben: Eine feste Reihenfolge von Arbeitsschritten kann nicht vorab definiert werden (s. Kapitel 2.4.2). Allerdings lassen sich Schwerpunkte setzen. Viele Entwicklungsumgebungen (z.B. VisualAge) bieten eine attraktive Unterstützung für die grafische Programmierung an. GUIWerkzeuge erlauben das einfache »Zusammenziehen« von Oberflä-

3

Grafische Programmierung


3.2


chenelementen. Diese Oberflächenelemente werden dann schrittweise um Funktionalität ergänzt. Wir haben bereits auf die Gefahr dieser Vorgehensweise für den Materialentwurf hingewiesen (s. Kapitel 3.1.2). Auf den Werkzeugbau übertragen, führt dieser Weg zu Werkzeugen, die von der Interaktionskomponente aus entwickelt werden. Unsere Erfahrungen zeigen, daß dabei der fachliche Gehalt eines Werkzeugs zu kurz kommt. Das Werkzeug wird leicht zu einer »Sicht« auf das Material, das dann scheinbar direkt manipuliert wird. Das Werkzeug hat keine eigenen komplexen fachlichen Funktionen, die über die des Materials hinausgehen. Zusätzlich entstehen Eins-zueins-Beziehungen zwischen Werkzeug und Material. In Diskussionen mit zukünftigen Benutzern eines Werkzeugs legen wir daher großen Wert auf die mit dem Werkzeug möglichen fachlichen Umgangsformen. Folglich macht es Sinn, zunächst die Funktionskomponente eines Werkzeugs zu entwerfen. Über die Art der Handhabung und die gewünschte Präsentation sollte im Entwicklungsprozeß anschließend entschieden werden. So läßt sich sicherstellen, daß Werkzeuge fachlich motiviert sind, und daß die Verantwortlichkeiten von FK und IAK konzeptionell klar getrennt sind. Diese Leitlinie zur Vorgehensweise widerspricht nicht unserer Verwendung des Prototyping – etwa wenn anhand von Handhabungsprototypen Entscheidungen über die weitere Gestaltung des Anwen-

3

494

FK als Ausgangspunkt


3.2


495

dungssystems getroffen werden. Denn diese Prototypen, die im wesentlichen Präsentation und Handhabung zeigen, werden erst auf der Grundlage eines anwendungsfachlichen Werkzeugentwurfs als Diskussionsgrundlage mit den Anwendern konstruiert. Das folgende Beispiel ist bewußt vereinfacht, um die prinzipielle Aufgabenteilung zwischen FK und IAK zu zeigen. Zusätzlich soll das Rückkopplungsproblem deutlich werden. Das Material ist eine Liste mit Lehrernamen. Der Benutzer will dieser Liste einen Namen hinzufügen. Dazu verwendet er einen einfachen Listeneditor (s. Abbildung 3-20). Der Editor zeigt die Liste der Namen und hat ein Eingabefeld, um einen weiteren Namen eingeben zu können. Dazu ist ein entsprechender Aktionsknopf vorhanden.

3


3.2


496 Abb. 3-20 Einfacher Listeneditor

Der Benutzer gibt einen neuen Lehrernamen in das Texteingabefeld ein. Dann drückt er den Knopf HinzufŸgen. Das entsprechende Systemereignis wird vom Interaktionstyp Knopf in ein Programmereignis umgewandelt und an die IAK geschickt. Die Interaktionskomponente liest den Namen aus dem Texteingabefeld. Dann ruft sie die

3


3.2


Operation NamenEinfuegen() der FK auf. Die FK prüft zunächst an der Liste der Lehrernamen, ob der übergebene Namen eingefügt werden kann. Da dies möglich ist (z.B. weil der Name noch nicht vorhanden ist), ruft die FK die entsprechende Operation der Liste der Lehrernamen auf. Die Aktion des Benutzers hat damit zu einer gewünschten Bearbeitung des Materials geführt. Was noch fehlt ist die Rückkopplung über den Erfolg der Aktion. Wichtig dabei sind folgende Konstruktionsrichtlinien: Die IAK entscheidet, ob und auf welche Weise sie die veränderte Liste der Lehrernamen darstellen will. Dazu muß sie aber die Information erhalten, daß die Liste wirklich verändert wurde. Die IAK fügt den neuen Namen nicht unmittelbar selbständig in die am Bildschirm dargestellten Listen ein und stellt die Veränderung auch nicht unmittelbar dar. Ihr fehlt die Information, daß die FK den neuen Namen tatsächlich ans Material weitergegeben hat und daß dieser vom Material akzeptiert wurde. Andererseits zeigt die FK das neue Listenelement nicht selbst durch Aufruf einer Operation der IAK in der Listbox an. Dies ist Aufgabe der IAK. Die FK hat keine Information darüber, daß die Namensliste überhaupt dargestellt wird. Sie bietet nur eine Namensliste über eine sondierende Operation an. Diese Namensliste ist von dem Mate-

3

497

Rückkopplungsproblem


3.2


498

rial Liste der Lehrernamen vollständig entkoppelt. Die FK entscheidet, in welcher Form sie aus dem Material die Namensliste erstellt. Hier fehlt noch ein Mechanismus, durch den die FK signalisieren kann, daß sie das Material erfolgreich bearbeitet hat. Dieser Rückkopplungsmechanismus sollte die Trennung von FK und IAK aufrechterhalten. Sehen wir uns das Zusammenspiel von Interaktions- und Funktionskomponente sowie Material am Pausenplanbeispiel einmal genauer an. Das Werkzeug Pausenplaner soll den Pausenplanersteller bei den fachlichen Aufgaben unterstützen, die auf der CRC-Karte in Abbildung 3-21 gezeigt sind.

3


3.2


499 Abb. 3-21 Aufgaben des Pausenplanerstellers

Diese fachlichen Umgangsformen werden als Operationen der Funktionskomponente des Pausenplaners realisiert. Hinzu kommen Operationen, die aus der Sicht der Interaktionskomponente notwendig sind, um den Zustand des bearbeiteten Materials darstellen zu können. Ausgehend von der in Kapitel 3.1.3 entwickelten Vision des Pausenplanerwerkzeugs können wir feststellen, daß unterschiedliche Mate-

3


3.2


500

rialien bearbeitet werden: zum einen der Pausenplan mit seinen Pausen, dann die Lehrer, die für die Pausen eingeteilt werden. Die Lehrer werden aus dem Lehrkšrper ausgewählt. Der Pausenplaner bearbeitet also insgesamt vier Materialien. Wir haben dies im Klassendiagramm von Abbildung 3-22 dargestellt, wobei wir zur besseren Übersicht die Aspekte weggelassen haben. Abb. 3-22 PausenplanerIAK

Pausenplaner mit Materialien

PausenplanerFK

Lehrer

Lehrkörper

Pausenplan

Pause

Da die PausenplanerIAK zu jeder Zeit den Materialzustand zeigen soll, aber nicht direkt das Material verändern darf, sind an der Klasse PausenplanerFK Operationen notwendig, um die entsprechende Materialrepräsentation nach außen zu geben.

3


3.2


501

So ist die PausenplanerIAK alleine für die Darstellung des Pausenplans zuständig. Die PausenplanerFK liefert folgenden Teil der Schnittstelle, damit der Pausenplan von der Interaktionskomponente geeignet visualisiert werden kann: void GeheZurErstenPause(); tPause* GibPause(); void GeheZurNaechstenPause(); BOOL IstAmEndeDerPausen();

Diese auf den ersten Blick an eine Liste erinnernde Schnittstelle wird von der IAK benutzt, um die Tabelle in Abbildung 3-23 aufzubauen. Ähnlich muß auch eine Repräsentation des Materials Lehrkšrper geeignet an der Schnittstelle der FK zur Verfügung stehen, damit die Interaktionskomponente die Liste der Lehrer darstellen kann. Diese Materialrepräsentation besorgt sich die PausenplanerFK ihrerseits über sondierende Operationen an den einzelnen Materialien.

3


3.2


502 Abb. 3-23 Entwurf des Werkzeugs Pausenplaner

Die in der Systemvision beschriebenen Probleme bei der Zuordnung eines Lehrers zu einer Pause werden vom Werkzeug Pausenplaner im Original durch Einfärben hervorgehoben. Dies ist in Abbildung 3-23 durch unterschiedliche Grauwerte verdeutlicht. Es werden zwei Arten der Markierung unterschieden: Ist eine Pause problembehaftet, so wird sie komplett in einer besonderen Farbe hinterlegt. Ist ein

3


3.2


503

bestimmter Lehrer die Ursache eines Konfliktes, so wird sein Kürzel farbig hervorgehoben. Diese Arten der Markierung werden gegebenenfalls kombiniert. Die Wahl der entsprechenden Farbe zur Kennzeichnung eines Konfliktes ist Aufgabe der IAK. Die PausenplanerIAK verwendet die Farbe rot, um problembehaftete Pausen oder Lehrer als Ursache eines Konflikts hervorzuheben. Die FK weiß nicht, wie ein Konflikt dargestellt wird, sie stellt aber Operationen zur Verfügung, um einen Konflikt zu ermitteln. BOOL IstKonfliktfreieBelegung( tPause* _pPause, tLehrer* _pLehrer ); BOOL IstPausenplanKonfliktfrei();

3


3.2


504

3.2.3 Rückkopplung zwischen Funktion und Interaktion Zusammenhang von Werkzeug und Material



Automat Werkzeug- und Materialkopplung Trennung Interaktion und Funktion


fachliche Behälter


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte


Umgebung

Materialkoordinator

Ein Werkzeug soll nicht nur die Aktionen des Benutzers in geeignete Formen der Materialbearbeitung umsetzen, es soll auch eine adäquate

3


3.2


505

Rückkopplung bei der Arbeit geben. FK und IAK müssen so gekoppelt werden, daß sie diese Rückkopplung gewährleisten, ohne die Aufgabentrennung aufzuheben. Der schematische Aufbau der Benutzt-Beziehungen zwischen Werkzeug und Material (s. Kapitel 3.2.1) offenbart schon das Grundproblem eines interaktiven Werkzeugs: Das Werkzeug soll an der Benutzungsschnittstelle ständig Rückkopplung über geändertes Material und den Zustand der Funktionskomponente liefern. Gleichzeitig soll die FK maximal von der IAK entkoppelt sein. Wie erfährt die Interaktionskomponente eines Werkzeugs, welche Auswirkungen eine von ihr angeforderte Änderung tatsächlich hatte, um entsprechend die Präsentation zu aktualisieren?

Problem

Im Entwurfsmuster Trennung Funktion und Interaktion haben wir die wesentliche Aufgabenteilung der Funktions- und der Interaktionskomponente eines Werkzeugs festgelegt. Das Material wird von der Funktionskomponente des Werkzeugs über einen Aspekt benutzt. Die Interaktionskomponente liefert eine Repräsentation des Materials und bietet Operationen zu dessen Handhabung an, die in der Funktionskomponente realisiert werden. FK und IAK müssen nun zu einem Werkzeug zusammengesetzt werden. Klar ist, daß die Interaktionskomponente die Funktions-

Kontext

3


3.2


506

komponente unter ihrer vollen Schnittstelle kennen muß; sie ist ja dafür zuständig, die externen Ereignisse in Aufrufe von Operationen der Funktionskomponente umzusetzen. Wir haben andererseits gefordert, daß die FK soweit von der IAK entkoppelt ist, daß die IAK ohne Auswirkungen auf die FK ausgetauscht werden kann. Damit das Werkzeug seine Aufgaben als reaktives System erfüllen kann, müssen wir also das prinzipielle Rückkopplungsproblem lösen (s. Abbildung 3-24). Rückkopplungsproblem: Zwei Komponenten sind so miteinander gekoppelt, daß eine Komponente der Dienstleistungsanbieter und die andere der Klient ist. Der Klient sei für die Darstellung der Ergebnisse der Dienstleistungen verantwortlich. Dann muß der Klient erfahren, wie sich der Zustand des Anbieters verändert hat, wenn Dienstleistungen in Anspruch genommen wurden. Diese Umkehrung des Kontrollflusses nennen wir Rückkopplungsproblem.

3


3.2


507 Abb. 3-24

Benutzeraktionen

Rückkopplungsproblem Strom von Ereignissen

Werkzeugreaktion

eines reaktiven Werkzeugs

Interaktionskomponente SoftwareWerkzeug

Rückkopplung Funktionskomponente

Material

Im folgenden werden wir die Lösung in mehreren Stufen vorstellen und dabei die Vor- und Nachteile diskutieren Die einfachste Möglichkeit zur Lösung des Rückkopplungsproblems besteht in der engen Verkopplung von IAK und FK. Zwei Konstruktionen bieten sich an: Die IAK kennt die Effekte von Operationen der FK, oder die FK weiß, welche Darstellungen die IAK präsentiert. Konstruiere die Interaktionskomponente so, daß sie die Effekte kennt, die der Aufruf einer verändernden Operation bei der

3

Diskussion: Enge Kopplung von IAK und FK

IAK kennt Effekte bei der FK


3.2

IAKLehrerEditor


508

Lehrkoerper

FKLehrerEditor

Abb. 3-25 FuegeNeuenLehrerHinzu(Name)

neuen Lehrer mit diesem Namen erzeugen

IAK fragt gezielt nach geänderten Zuständen

LehrerEinfuegen(neuerLehrer)

GibLehrerListe

GeheZumAnfang GibLehrer

LehrerListe

... schrittweises Aufbauen einer Liste für die IAK

neueLehrerliste darstellen

Funktionskomponente auslöst. Die IAK kann dann gezielt nach der Rückkehr des Kontrollflusses eine sondierende Operation der FK aufrufen, um den veränderten Zustand abzufragen und darzustellen. Der in Abbildung 3-25 skizzierte Ablauf dieses Konstruktionsansatzes bezieht sich wieder auf das in Abbildung 3-20 auf S. 242 gegebene Beispiel des einfachen Listeneditors. Das Interaktionsdiagramm zeigt, daß die IAK sehr eng an die Implementation der FK gebunden 3


3.2


ist. Die IAK weiß, welche Zustandsänderungen eingetreten sein können, wenn der Knopf HinzufŸgen gedrückt wird (hier muß die Liste neu dargestellt werden), und daß andere Attribute der FK nicht betroffen sind. Aufgrund dieser engen Kopplung müssen wir in der IAK Vorkehrungen für den Fall treffen, daß der Lehrer schon im Lehrkörper eingetragen ist. Wir verwerfen diese auf den ersten Blick einfachste Lösungsmöglichkeit, da hierbei die Interaktionskomponente um die Zusammenhänge von Operationen der Funktionskomponente weiß. Damit ist die Kapselung der Funktionskomponente durchbrochen. Jede Änderung der Implementation der FK muß in der IAK nachgezogen werden. Darüber hinaus muß Wissen über das Material, das in der FK gekapselt sein soll, ebenfalls in der IAK berücksichtigt werden. Denn nur so kann die IAK auf die potentiellen Folgen eines Operationsaufrufs an der FK reagieren. Die Funktionskomponente muß also so konstruiert werden, daß die FK der Interaktionskomponente die tatsächlich durchgeführten Änderungen mitteilt und sie direkt zu veränderten Darstellungen auffordert. Die IAK ist dann ausschließlich für die Interaktion zuständig.

3

509

Konsequenz

FK kennt Darstellungen der IAK


3.2

IAKLehrerEditor


Lehrkoerper

FKLehrerEditor

510 Abb. 3-26 Direkter Aufruf

FuegeNeuenLehrerHinzu(Name)

der IAK durch die FK

neuen Lehrer mit diesem Namen erzeugen LehrerEinfuegen(neuerLehrer)

GeheZumAnfang

GibLehrer StelleLehrerListeDar(LehrerListe) neueLehrerliste darstellen


In Abbildung 3-26 ruft die IAK zunächst die FK mit einer verändernden Operation (FuegeNeuenLehrerHinzu) auf. Nachdem die FK das Material erfolgreich geändert hat, ruft sie ihrerseits die IAK und teilt ihr den geänderten Materialzustand mit (StelleLehrerListeDar).

3


3.2


Der zweite Konstruktionsansatz zur Lösung des Rückkopplungsproblems läßt sich technisch sehr einfach umsetzen. Die FK ruft direkt Operationen der IAK auf, um ihr mitzuteilen was sich geändert hat. Doch die enge Kopplung widerspricht der von uns geforderten Aufgabentrennung: Die FK kennt die Präsentation der IAK. Die FK weiß, welcher Teil des Material- und des Werkzeugzustands gerade dargestellt wird, und übergibt der Interaktionskomponente die veränderten Werte. Die FK ist damit so auf die IAK zugeschnitten, daß diese nicht ohne größeren Änderungsaufwand gegen eine andere ausgetauscht werden kann. Bei einem dritten Lösungsansatz muß die IAK so konstruiert werden, daß sie keine Kenntnisse über die Effekte hat, die der Aufruf einer verändernden Operation bei der FK bewirkt. Die IAK fragt daher nach jeder potentiell verändernden Operation alle sondierenden Operationen der FK-Schnittstelle ab, um einen eventuell veränderten Zustand darzustellen. Abbildung 3-27 zeigt das Prinzip des ständigen Abfragens oder »Polling«. Nach dem Aufruf einer verändernden Operation (FuegeNeuenLehrerHinzu) ruft die Interaktionskomponente alle sondierenden Operationen (IstLehrkoerperVeraendert? oder für jeden einzelnen Lehrer IstLehrerVeraendert?) der FK auf, um eine Änderung des Zustandes festzustellen. Diese Änderung stellt die IAK dar.

3

511 Konsequenz

Diskussion: Lose Kopplung durch »Polling«


3.2

IAKLehrerEditor


512

Lehrkoerper

FKLehrerEditor

Abb. 3-27 FuegeNeuenLehrerHinzu(Name)

Die IAK ruft alle

neuen Lehrer mit diesem Namen erzeugen

sondierenden Operationen

LehrerEinfuegen(neuerLehrer)

der FK

IstLehrkoerperVeraendert? boolean GibLehrerListe

GeheZumAnfang GibLehrer

LehrerListe


neueLehrerliste darstellen

3


3.2


513

Die Lösung des Rückkopplungsproblems durch ständiges Abfragen ist softwaretechnisch bisher die sauberste Konstruktion, da die Interaktionskomponente gegenüber der Funktionskomponente weiterhin ein anonymer Klient bleibt. Die Interaktionskomponente macht keine Annahmen über mögliche Auswirkungen einer ändernden Operation. Aus dem Beispiel in Abbildung 3-27 läßt sich leicht der Nachteil dieser Polling-Lösung erkennen: Die Interaktionskomponente muß erst einmal herausbekommen, ob und welche Veränderungen eingetreten sind. Sie ruft dazu alle modellierten sondierenden Operationen (wie IstLehrkoerperVeraendert?) auf. Wir stellen bei genauerem Hinsehen fest, daß die IAK wirklich alle sondierenden Operationen aufrufen muß, wenn sie keine Annahmen über die Effekte in der FK machen und eine konsistente Darstellung an der Benutzungsschnittstelle erreichen will. Aus den bisher diskutierten Konstruktionsansätzen lassen sich folgende Schlüsse ziehen: ❑ Die enge Kopplung von FK und IAK ist zwar einfach zu kon-

struieren, sie zerstört aber das Kapselungsprinzip und hebt die Aufgabenteilung zwischen FK und IAK auf. Als Vorteil können wir vermerken, daß die IAK nur dann gezielt ihre Darstellung aktualisiert, wenn tatsächlich eine Zustandsänderung eingetreten ist.

3


3.2


514

❑ Die lose Kopplung mit Polling ist softwaretechnisch sauber

und berücksichtigt die aufgestellten Konstruktionsprinzipien für FK und IAK. Negativ ist zu verbuchen, daß die Lösung weder elegant noch effizient ist. Im folgenden stellen wir zwei Konstruktionsansätze vor, die die Konsequenzen aus der Diskussion ziehen: ❑ Das Beobachtermuster ❑ Das Ereignismuster

3


3.2


515

Das Beobachtermuster für FK und IAK Zusammenhang von Werkzeug und Material





Beobachter

Materialverwaltung





fachliche Behälter

Materialkoordinator

Das Rückkopplungsproblem zwischen FK und IAK wird durch lose Kopplung gelöst. Die FK benachrichtigt die IAK anonym über jede relevante Zustandsänderung.

3


3.2


516

Konstruiere die Funktionskomponente so, daß sie die Interaktionskomponente benachrichtigen kann, wenn eine Veränderung stattgefunden hat. Die FK darf dabei die IAK nicht unter ihrer vollen Schnittstelle kennen, sondern möglichst »anonym«.

Problem

Wir greifen an dieser Stelle die Idee auf, Komponenten lose zu koppeln, um sie austauschbar zu machen. Dieser Mechanismus läßt sich verallgemeinern und auch an anderen Stellen der Werkzeugkonstruktion verwenden (s. Muster Werkzeugkomposition, Kapitel 3.2.5). Das Prinzip der losen Kopplung (Weak Coupling) strebt an, die Bindung zwischen kollaborierenden Komponenten möglichst gering zu halten (s. Kapitel 2.1.13, S. 56). Wir entwickeln im folgenden einen Konstruktionsansatz auf der Basis der losen Kopplung und der Benachrichtigung. Dabei soll die FK nicht wissen, wie die IAK auf Änderungen reagiert und was sie präsentiert. Die FK soll nur wissen, daß die IAK potentiell auf Änderungen reagieren kann. Die Idee ist, daß die FK die IAK unter minimaler Kenntnis der Schnittstelle benachrichtigt, wenn sich ihr eigener oder der Materialzustand geändert hat. Da wir keine Sprachen betrachten, bei denen ein anonymer Signalmechanismus eingebaut ist (vergleichbar etwa mit den Events in HyperTalk), müssen wir den normalen Aufrufmechanismus für diese Benachrichtigung verwenden.

Kontext

3


3.2


Konstruiere eine minimale Verbindung zwischen FK und IAK. Wenn eine Zustandsänderung eingetreten ist, signalisiert die FK dies durch Aufruf genau einer festgelegten Operation an der IAK. Dazu muß die IAK der FK nicht konkret, sondern nur abstrakt als »Beobachter« bekannt sein. Die Verbindung zwischen FK und IAK wird zur Laufzeit eines Werkzeugs hergestellt. Die IAK trägt sich bei der FK als Beobachter, d.h. als Empfänger des Signals, ein. Die hier gewählte Lösung entspricht dem Beobachtermuster aus [Gamma et al. 96]. Da es eine allgemeine Eigenschaft von Funktionskomponenten ist, daß sie Beobachter haben, können wir z.B. das Setzen und Entfernen des Beobachters als Operationen einer Oberklasse zu allen Funktionskomponenten modellieren (s. Abbildung 3-28).

3

517 Lösung


3.2


518

Beobachtbar

Beobachter

• RegistriereBeobachter • DeregistriereBeobachter • MeldeAenderung

• BeachteAenderung

List* pBeobachterListe; Cursor BeobachterCursor(pBeobachterListe); meldeAenderung() { while (BeobachterCursor.Forth()) { BeobachterCursor.Current()->BeachteAenderung(); } }

IAKLehrerEditor • BeachteAenderung

FKLehrerEditor

BeachteAenderung() BeachteAenderung() {{ pFK->WelcheAenderung(); pFK->WelcheAenderung(); }}

• WelcheAenderung

Die Lösung in Abbildung 3-28 ist in C++ realisiert. Dabei führt die Oberklasse Beobachtbar eine Liste von Beobachtern und läuft in der Operation MeldeAenderung mit einem Cursor über die Liste. An jedem Listenelement, das der Cursor referenziert, wird die Operation BeachteAenderung aufgerufen. Auf diese Weise kann sich der Beobachter, hier IAKLehrerEditor, über die Änderungen informieren.

3

Abb. 3-28 Lose Kopplung von FK und IAK über das Beobachtermuster


3.2


519

Im folgenden beschreiben wir an einem Beispiel die Dynamik der gewählten Lösung mit Hilfe des Beobachtermusters. Die Klassen IAKLehrerEditor und FKLehrerEditor erben jeweils von den Oberklassen Beobachter und Beobachtbar.

3


3.2


520

class IAKLehrerEditor : public Beobachter { public : void BeachteAenderung() { // Aenderung wird von der FK erfragt und // an der Oberflaeche angezeigt. }; } class FKLehrerEditor : public Beobachtbar { public : void FuegeNeuenLehrerHinzu(String Lehrername) { if (!IstLehrerEnthalten(Lehrername)) { Lehrer* pNeuerLehrer(Lehrername); pLehrerliste->FuegeLehrerEin(pNeuerLehrer); LehrkoerperVeraendert := true; // Aufruf der Operation MeldeAenderung(); // aus der Oberklasse // Beobachtbar!! } }; bool IstLehrkoerperVeraendert() { return LehrkoerperVeraendert; }; };

3


3.2


521

In der Implementation der Operation FuegeNeuenLehrerHinzu läßt sich erkennen, daß die Klasse FKLehrerEditor mit dem Aufruf von MeldeAenderung() den Beobachtermechanismus in Gang setzt. Da die Oberklassen Beobachter und Beobachtbar schon den gesamten Code für die Benachrichtigung enthalten, muß der Anwendungsentwickler in der FKLehrerEditor lediglich die Operation BeachteAenderung() implementieren und in IAKLehrerEditor die Operation MeldeAenderung() an den richtigen Stellen aufrufen. Abbildung 3-29 zeigt, wie sich die IAK als Beobachter anmeldet und wie die FK eine Änderung signalisiert.

3


3.2


522

FKLehrerEditor

IAKLehrerEditor RegistriereBeobachter(this)

FuegeNeuenLehrerHinzu (Name) BeachteAenderung

neuen Lehrer erzeugen Lehrer in den Lehrkörper einfügen

IstLehrkoerperVeraendert? true GibLehrerListe Liste der Lehrer aufbauen LehrerListe Darstellung der veränderten Lehrerliste

Abb. 3-29 Dynamik des Beobachtermechanismus

3


3.2


523

Wie in Abbildung 3-29 zu sehen ist, meldet sich die IAKLehrerEditor mit dem Aufruf RegistriereBeobachter(this) bei der FKLehrerEditor an und übergibt sich dabei selbst als Argument. Die Operation RegistriereBeobachter(Beobachter* pBeobachter) ist in der Oberklasse Beobachtbar implementiert und bewirkt, daß die IAKLehrerEditor in die Liste der Beobachter aufgenommen wird. Die FKLehrerEditor kennt hierdurch die IAKLehrerEditor nur unter der Schnittstelle des Typs Beobachter. Ruft jetzt die IAKLehrerEditor die Operation FuegeNeuenLehrerHinzu an der FKLehrerEditor auf, so wird der Zustand der FK und des Materials entsprechend verändert (z.B. neuer Lehrer wird erzeugt und in den Lehrkörper eingefügt; vgl. den Programmtext zu FKLehrerEditor). Anschließend ruft die FKLehrerEditor sich selbst mit der Operation MeldeAenderung() auf. MeldeAenderung() ist in der Oberklasse Beobachtbar so realisiert, daß sie bei allen Beobachtern aus der Liste der Beobachter die Operation BeachteAenderung() aufruft. Da sich die IAKLehrerEditor vorher bei der FKLehrerEditor als Beobachter registriert hatte, wird sie so von der Änderung verständigt. Ist die Kontrolle nach dem Aufruf von BeachteAenderung() in der IAKLehrerEditor angelangt, so kann diese an der FKLehrerEditor sondieren, was sich geändert hat. Unter anderem ruft sie dazu Ist-

3


3.2


524

LehrkoerperVeraendert() auf, fragt die veränderten Werte durch GibLehrerliste() ab und aktualisiert die Darstellung. Eine IAK kennt ihre FK und ruft an ihr verändernde und sondierende Operationen auf, um die Aktionen des Benutzers in Programmereignisse umzusetzen. Der Mechanismus der Rückkopplung arbeitet in umgekehrte Richtung, d.h., die FK benachrichtigt die IAK über den Beobachtermechanismus, daß eine relevante Zustandsänderung eingetreten ist. Wir müssen Maßnahmen ergreifen, um eine ungewolltes »Oszillieren« zwischen Interaktions- und Funktionskomponente zu vermeiden. Denn wenn die IAK als Reaktion auf die Benachrichtigung durch die FK bei dieser wieder eine Zustandsveränderung hervorruft, wird dies eine Benachrichtigung zur Folge haben. Offensichtlich kann dieser Prozeß leicht unendlich weiterlaufen, ohne zu terminieren. Zur Lösung des Problems unterteilen wir die Operationen an der Schnittstelle einer Klasse (s. Kapitel 2.1.4, S. 27) in Anweisungen, Anfragen und Tests. Wir wenden dies auf das Zusammenspiel von IAK und FK an:

Diskussion

Lösung des Problems der unkontrollierten Benachrichtigung

❑ Anfragen und Tests sind sondierende, nebeneffektfreie Opera-

tionen (Funktionen). Anfragen liefern der rufenden Interaktionskomponente Informationen z.B. zum Zustand des Materials und zu den Einstel-

3


3.2


525

lungen des Werkzeugs. Tests werden oft eingesetzt, um anzuzeigen, ob andere Operationen der Funktionskomponente aufrufbar sind, d.h. um Vorbedingungen für andere Operationen zu prüfen. Sondierende Operationen dürfen keinen an der Schnittstelle der Funktionskomponente sichtbaren Nebeneffekt bewirken. Insbesondere dürfen sie nicht zu einer Benachrichtigung der IAK als Beobachter führen. Anfragen und Tests können jederzeit als Reaktion auf eine Benachrichtigung an der FK aufgerufen werden. ❑ Anweisungen sind zustandsverändernde Operationen (Proze-

duren). Sie werden von der IAK dazu verwendet, um mit Hilfe der Funktionskomponente das Material zu bearbeiten oder den Arbeitszustand des Werkzeugs zu verändern. Nach einer Anweisung kann die IAK eine sondierende Funktion aufrufen, um zu überprüfen, ob der letzte Aufruf der FK erfolgreich durchgeführt werden konnte. Eine Anweisung wird im Regelfall zu einer Benachrichtigung führen. Deshalb darf eine Anweisung immer nur aufgrund einer Benutzeraktion, aber nie als Reaktion auf eine Benachrichtigung gerufen werden.

3


3.2


Wenn diese Regeln befolgt werden, kann der Beobachtermechanismus sicher verwendet werden. Denn in sequentiellen Systemen werden äußere Ereignisse solange blockiert, bis alle aus einem Ereignis resultierenden Operationen abgearbeitet sind. Bei komplexen Werkzeugen führt die einfache Benachrichtigung des Beobachters oft zu Laufzeiteffekten, weil eine Vielzahl möglicher Zustandsänderungen bei der FK abgefragt werden müssen. Damit unterscheidet sich diese Form der Benachrichtigung nicht wesentlich vom vorher beschriebenen Polling-Ansatz. Wir können die Benachrichtigung effizienter gestalten, indem wir beim Aufruf der Operation MeldeAenderung eine Konstante oder ein Objekt als Parameter mitgeben, um die Änderung näher zu beschreiben. In der IAK muß dieser Parameter dann den möglichen Änderungen zugeordnet werden. Nach wie vor wird bei dieser Lösung jeder Beobachter informiert, auch diejenigen, die an der konkreten Zustandsänderung gar nicht interessiert sind. Dieses Problem läßt sich erst über das auf Seite 258ff. vorgeschlagene Ereignismuster lösen. Ein weiteres Problem liegt in der einheitlichen Typisierung aller Beobachter und Beobachtbar-Komponenten. Wenn wir mehrere Werkzeuge haben, dann sind die jeweiligen FKs Subtypen von Beobachter und die IAKs sind Subtypen von Beobachtbar. Wir müssen dar-

3

526

Erweiterte Benachrichtigung

Problem der richtigen Zuordnung


3.2


527

auf achten, daß die richtigen FKs und IAKs miteinander kombiniert werden, da sie auf Typebene nicht unterschieden werden. Generalisierung des Beobachtermechanismus

Die bisher skizzierte Lösung einer losen Kopplung von Interaktionsund Funktionskomponente läßt sich allgemein auf Komponenten übertragen, die bidirektional miteinander kommunizieren, um die Eigenschaften eines reaktiven Systems zu realisieren. Dabei verläuft die Kommunikation in eine Richtung über die volle Schnittstelle und in der anderen Richtung mit loser Kopplung. Anders formuliert: Eine Komponente nimmt als Klient die Dienste eines Anbieters in Anspruch. Der Klient muß Informationen über die tatsächlichen Änderungen am Anbieter weiterleiten; sei es an die Benutzungsschnittstelle oder in Form einer Nachricht an einen anderen Prozeß. Dann muß der Anbieter den Klienten über Änderungen informieren, ohne Annahmen darüber zu machen, wie der Klient auf diese Änderungsinformation reagiert. In [Roock & Wolf 96] wird diese Technik der losen Kopplung Reaktionsmechanismus genannt.

3


3.2


528

Reaktionsmechanismus: Ein Reaktionsmechanismus ermöglicht, Klienten abstrakt über Änderungen an einem Dienstleistungsanbieter zu informieren, so daß diese Klienten auf die Änderungen reagieren können.

Reaktionsmechanismen können danach unterschieden werden, ob der Klient allgemein über eine Änderung des Anbieters informiert wird oder ob der Anbieter differenziert über die Art der Zustandsänderung informiert. Eine andere Unterscheidung ist, ob der Reaktionsmechanismus vom Anbieter oder vom Klienten ausgeht. Bei der Beobachtungssicht nennen wir das Subjekt den Beobachteten (Beobachtbar) und das abhängige Objekt den Beobachter und gehen davon aus, daß der Beobachter die aktive und der Beobachtete die passive Komponente ist. Bei der Benachrichtigungssicht sprechen wir vom Benachrichtiger und dem Benachrichtigten – hier ist der Benachrichtiger aktiv und der Benachrichtigte passiv.

3


3.2


529 Abb. 3-30

Beobachter Benachrichtigter Abhängiger

Beobachteter Benachrichtiger Subjekt

Beobachtung und Benachrichtigung

Damit sind einerseits Subjekt, Beobachtbar und Benachrichtiger äquivalent und andererseits Abhängiger, Beobachter und Benachrichtigter. Je nach Sichtweise ist mal das Subjekt aktiv und die abhängige Komponente passiv (Benachrichtigung) oder umgekehrt (Beobachtung). Die Klassifikation nach der Sichtweise ist rein konzeptionell. Im konkreten Fall gehören Beobachter und Beobachteter oder Benachrichtiger und Benachrichtigter immer zusammen. Der eine kann ohne den anderen nicht existieren. Die Einteilung in eine allgemeine Änderungsmeldung oder in unterscheidbare Ereignisse ist dagegen konstruktiv wirksam. Die jeweilige Entscheidung beeinflußt den konkreten Mechanismus und muß in der Implementation berücksichtigt werden.

3


3.2


530

Das Ereignismuster für FK und IAK Zusammenhang von Werkzeug und Material





Beobachter

fachliche Behälter


WerkzeugEreignis komposition Fachwerte Trennung von Handhabung und Präsentation


Materialverwaltung

Materialkoordinator

Bei diesem Muster stehen im Gegensatz zum Beobachtermuster nicht die Beobachtung im Vordergrund, sondern die Ereignisse, welche verschickt, empfangen und interpretiert werden. Ereignisse sind dabei eigenständige Objekte, die von der FK angeboten werden.

3


3.2


531

Interaktions- und Funktionskomponente sollen im Rahmen eines reaktiven Werkzeugs zusammenarbeiten. Dabei soll die Konsistenz zwischen Werkzeug- und Materialzustand einerseits und der Präsentation und Handhabung des Werkzeugs andererseits aufrechterhalten werden. Die Komponenten sollen jedoch nicht eng gekoppelt werden, weil ihre Wiederverwendbarkeit dadurch eingeschränkt wird. Gegenüber dem Beobachtermuster soll hier ein zusätzliches Konstruktionsproblem gelöst werden: Unterschiedliche Zustandsveränderungen an der FK sollen zu verschiedenen Ereignissen führen, die schon bei der FK unterschieden werden. Die IAK hat dann die Möglichkeit, sich für bestimmte Ereignisse gezielt zu registrieren.

Problem

Das hier vorgestellte Muster (vgl. [Riehle & Züllighoven 96]) basiert auf dem Ansatz von [Notkin et al. 93], wobei der Aspekt des impliziten Prozeduraufrufs in den Hintergrund tritt. Gerade bei komplexen Werkzeugen zeigt sich, daß die einfache Benachrichtigung des Beobachters zu merklichen Laufzeiteffekten führt. Eine Vielzahl möglicher Zustandsänderungen muß bei der FK abgefragt oder, bei differenzierten Nachrichten, durch Fallunterscheidungen in der IAK erkannt werden. Folglich liegt die Idee nahe, den Reaktionsmechanismus in eigene Ereignisklassen auszulagern. Dann ist keine explizite BeobachterOberklasse mehr notwendig.

Kontext

3


3.2


Konstruiere eine Ereignisklasse. Erzeuge in der Funktionskomponente für jede relevante Zustandsänderung ein eigenes Ereignisobjekt. Erweitere die Schnittstelle der FK so, daß jedes Ereignis an der Schnittstelle erfragt werden kann. Die IAK kann sich bei den Ereignissen anmelden, die an der Schnittstelle der FK verfügbar sind. Sie kann dem Ereignis eine Operation mitgeben, mit der sie gerufen werden möchte. Verwende dieses Muster immer dann, wenn auch das Beobachtermuster sinnvoll ist. Zusätzlich gilt:

532 Lösung

❑ Die FK nimmt viele unterschiedliche fachliche Zustände ein.

Hier hilft die explizite Deklaration der möglichen Ereignisse an der FK, um zu verdeutlichen, welche Zustandsänderungen von der IAK beachtet werden müssen. ❑ Die Unterscheidung der verschiedenen Zustände und der dar-

auf basierenden Ereignisse ist nach dem Beobachtermuster zu aufwendig. Die IAK soll gezielt bei bestimmten Zustandsänderungen gerufen werden. Die Anmeldung der IAK erfolgt meist direkt bei den einzelnen Ereignissen. In vielen Sprachen (z.B. C++ oder Java) kann die vom Ereignis aufzurufende Operation typsicher mitgegeben werden.

3


3.2


533

Im folgenden beschreiben wir am Pausenplanbeispiel, wie das Ereignismuster für IAKLehrerEditor und FKLehrerEditor in Java umgesetzt werden könnte. Ähnlich wie beim Beobachtermechanismus erben die Werkzeugklassen IAKLehrerEditor und FKLehrerEditor jeweils von den Oberklassen Beobachter und Beobachtbar. Allerdings müssen sie in diesem Fall keine Operationen implementieren. Beobachter und Beobachtbar dienen lediglich der Typisierung und verbergen den Mechanismus, um Ereignisse zu versenden.

3


3.2


534

public class IAKLehrerEditor implements Beobachter { public IAKLehrerEditor (...) { fk.eventLehrkoerperVeraendert().register(this, "reactOnLehrkoerperAnders"); ... } public void reactOnLehrkoerperAnders (evtObject event) { // auf Event reagieren, die FK sondieren } public class FKLehrerEditor implements Beobachtbar { public FKLehrerEditor(...) { _lehrkoerperVeraendert = new evtObject(this); ... } public evtObject eventLehrkoerperVeraendert() { return _lehrkoerperVeraendert; } public void fuegeNeuenLehrerHinzu(String lehrername) { if (!istLehrerEnthalten(lehrername)) { Lehrer neuerLehrer(lehrername); _lehrerListe.fuegeLehrerEin(neuerLehrer); // Aussenden des _lehrkoerperVeraendert.announce(); // Ereignisses an // die Beobachter } } }

3


3.2


535

Die FKLehrerEditor bietet an ihrer Schnittstelle für jedes Ereignis (Event), das sie aussendet, eine Operation an – in unserem Beispiel die Operation eventLehrkoerperVeraendert(). Diese Operation gibt ein entsprechendes Ereignis zurück. Die IAKLehrerEditor meldet sich nicht beim FKLehrerEditor an, sondern direkt bei diesem speziellen Ereignis, das sie interessiert. Das Ereignis wird im Konstruktor von FKLehrerEditor erzeugt. Wird die Operation fuegeNeuenLehrerHinzu gerufen, schickt die FKLehrerEditor das Ereignis durch den Aufruf der Operation announce() an alle Beobachter.

3


3.2

IAKLehrerEditor


LehrkoerperVeraendert

536

FKLehrerEditor

– Ereignis-Objekt – eventLehrkoerperVeraendert() _lehrkoerperVeraendert register(this, “reactOnLehrkoerperAnders“) IAKLehrerEditor als Beobachter eintragen

fuegeNeuenLehrerHinzu (Name) reactOnLehrkoerperAnders

announce

neuen Lehrer erzeugen Lehrer in den Lehrkörper einfügen

gibLehrerListe Liste der Lehrer aufbauen

_lehrerListe Darstellung der veränderten Lehrerliste

Abb. 3-31

Wie in Abbildung 3-31 zu sehen ist, erfragt die IAKLehrerEditor bei der FKLehrerEditor das Ereignis-Objekt für die spezielle Änderung, bei der FK das Ereignis, das sie interessiert. Bei diesem Ereignis-Objekt

3

Dynamik des Ereignismusters


3.2


537

(LehrkoerperVeraendert) meldet sich die IAKLehrerEditor mit register(this, "reactOnLehrkoerperAnders") an. Da das Beispiel in Java umgesetzt ist, kann sich die IAKLehrerEditor mit dem Operationsnamen als String anmelden. Das Ereignis-Objekt ist in der Lage über die Java-eigene Metainformation (CoreReflection) festzustellen, ob diese Operation existiert und kann sie auch gegebenenfalls ausführen (Callback). Ruft jetzt die IAKLehrerEditor die Operation fuegeNeuenLehrerHinzu an der FKLehrerEditor auf, so werden die entsprechenden Zustandsänderungen (z.B. Erzeugen eines neuen Lehrers, Einfügen in den Lehrkörper) durchgeführt (s. Programmtext zu FKLehrerEditor). Anschließend ruft die FKLehrerEditor am Ereignis-Objekt LehrkoerperVeraendert die Operation announce() auf. Es werden also nicht, wie beim Beobachtermechanismus, alle Beobachter der FKLehrerEditor von der erfolgten Änderung informiert, sondern lediglich die Beobachter, die sich für dieses spezielle Ereignis-Objekt angemeldet haben. Das Ereignis-Objekt benachrichtigt dann alle Beobachter, die sich bei ihm registriert haben. Ist die Kontrolle durch den Aufruf von reactOnLehrkoerperAnders() in der IAKLehrerEditor angelangt, so kann diese auf die Benachrichtigung reagieren. Die IAKLehrerEditor wird dabei mit ihrer eigenen speziellen Operation und nicht durch ein anonymes

3


3.2


538

BeachteAenderung() zurückgerufen. Sie weiß also, welche Zustandsänderung an der FKLehrerEditor eingetreten ist und kann direkt die veränderten Werte durch gibLehrerliste() abfragen und die Darstellung aktualisieren. Im Gegensatz zum Beobachtermechanismus, bei dem alle Beobachter von einer Änderung informiert werden, erlaubt das Ereignismuster eine Differenzierung der Ereignisse. Ein Beobachter meldet sich nicht mehr für alle Zustandsänderungen eines Beobachteten an, sondern nur noch für die Ereignisse, die ihn tatsächlich interessieren. So kann ein erheblicher Aufwand bei der Benachrichtigung von Zustandsänderungen eingespart werden. Die verschiedenen Zustände einer Funktionskomponente sind an ihrer Schnittstelle erkennbar. Wir können eine Interaktionskomponente gezielt auf die möglichen Veränderungen hin entwickeln, die an der Schnittstelle der FK spezifiziert sind. Verwenden wir den Beobachtermechanismus, so muß über Programmierkonventionen sichergestellt sein, daß bestimmte Konstanten oder Objekte eine bestimmte Zustandsänderung repräsentieren. In der Praxis zeigt sich, daß Funktionskomponenten mit ihren Ereignissen stark auf existierende Interaktionskomponenten zugeschnitten sind. Das heißt, daß FKs ohnehin nur die Ereignisse anbie-

3

Diskussion


3.2


539

ten, die zur Präsentation in einer IAK benötigt werden. Damit ist die FK dann doch wieder stärker an die IAK gekoppelt und ein Austausch der IAKs in Frage gestellt. Wir können diese implizite Abhängigkeit vermeiden, wenn wir die Zustände einer FK rein fachlich modellieren.

Hier hat sich der Entwurf von Zustandsautomaten für die FK bewährt. Dazu legen wir fest, welche fachlichen Zustände eine FK einnehmen kann und welche verändernden Operationen die Zustandsübergänge bilden. Jeder Zustandsübergang wird zu einem Ereignis. Auf diese Weise lassen sich FKs in weitgehender Unabhängigkeit von einer konkreten IAK konstruieren.

3


3.2


540

3.2.4 Trennung von Handhabung und Präsentation Zusammenhang von Werkzeug und Material





fachliche Behälter


Werkzeugkomposition Umgebung

Ereignisverwalter

Materialverwaltung

Materialkoordinator

Trennung Trennung von vonHandhabung Handhabung und undPräsentation Präsentation

Fachwerte

Im Muster Trennung von Interaktion und Funktion haben wir gezeigt, daß es sinnvoll ist, die Funktionalität eines interaktiven Werkzeugs

3


3.2


541

von der Interaktion zu trennen. Da wir uns hauptsächlich mit der Konstruktion interaktiver Arbeitsplatzsysteme beschäftigen, wird die Interaktion in der Regel vom Benutzer ausgehen und als grafische Benutzungsschnittstelle realisiert. Für den Entwurf von grafischen Benutzungsschnittstellen gibt es eine Reihe kommerzieller und öffentlich zugänglicher Bibliotheken und Entwicklungskomponenten, die wir unter dem Name User Interface Toolkits, kurz Toolkits, zusammenfassen. Bei der Konstruktion der Interaktionskomponente wollen wir so wenig Abhängigkeit wie möglich vom jeweiligen Toolkit eingehen. Wir zeigen, wie wir von den verschiedenen Toolkits abstrahieren können. Zu diesem Zweck stellen wir den Konstruktionsansatz der Interaktionstypen vor. Zwischen Interaktionskomponente und Interaktionstypen definieren wir eine Form der Zusammenarbeit, die in der einen Richtung aus einer Benutzt-Beziehung und in der anderen aus einer Rückkopplung besteht. Wie zwischen Interaktions- und Funktionskomponente können wir den Beobachtermechanismus einsetzen. Das Befehlsmuster eignet sich an dieser Stelle aber noch besser.

3


3.2


542

Interaktionstypen Zusammenhang von Werkzeug und Material






fachliche Behälter


Ereignisverwalter

Materialverwaltung

Fachwerte

Trennung Trennung von vonHandhabung Handhabung und undPräsentation Präsentation

Materialkoordinator Interaktionstypen

Es gibt eine große Anzahl von Toolkits für die Konstruktion grafischer Benutzungsschnittstellen. Wir können die in diesen Toolkits enthalte-

3


3.2


543

nen fertigen Bausteine verwenden, um einfach und schnell Benutzungsschnittstellen zu entwickeln. Um die IAKs unabhängig von einem bestimmten Toolkit zu machen, fügen wir sogenannte Interaktionstypen zwischen Interaktionskomponenten und Toolkit ein. Toolkits lassen sich bei der Entwicklung der Interaktionskomponente gut verwenden, weil sie grafische Bausteine auf einfache Art und Weise verfügbar machen. Die verschiedenen Toolkits haben aber spezielle Merkmale und Schnittstellen, von denen die Interaktionskomponente abhängig wird, wenn diese in der Konstruktion benutzt werden. Wie können Toolkits gekapselt werden, so daß die Abhängigkeit der Interaktionskomponente von einem speziellen Toolkit weitgehend reduziert wird?

Problem

Die wesentliche Aufgabe des Anwendungsentwicklers besteht darin, die fachliche Funktionalität eines Werkzeugs geeignet in Umgangsformen umzusetzen, und daraus geeignete Handhabungs- und Präsentationsformen mit Hilfe von vorhandenen Grafikbausteinen zu realisieren. Toolkits, wie z.B. Motif [Heller & Ferguson 94], TCL/TK [Ousterhout 94] oder die StarView-Klassenbibliothek [Star Division 92], bieten eine Reihe vorgefertigter Bausteine, meist Widgets genannt, zur Erstellung grafischer Benutzungsschnittstellen an. Die Verwendung dieser vorgefertigten Bausteine für die Konstruktion

Kontext

3


3.2


544

einer Benutzungsschnittstelle bringt Vorteile. Wir können mit wenig Programmieraufwand komplexe Benutzungsschnittstellen in kurzer Zeit realisieren. Vorgefertigte Bausteine fördern zudem einheitliche Benutzungsschnittstellen (das sogenannte Look & Feel) und erleichtern dadurch den Umgang mit dem Anwendungssystem.

Interaktionskomponente

Abb. 3-32

Funktionskomponente

Anbindung eines Werkzeugs an ein User Interface Toolkit

User Interface Toolkit

Sehen wir uns zunächst an, wie die Bausteine eines Toolkit für den Bau von Werkzeugen verwendet werden können (s. Abbildung 3-32). Die Oberfläche einer Interaktionskomponente wird durch die Kombination von Elementen des Toolkit konstruiert. Einige Punkte haben dabei einen entscheidenden Einfluß auf die Konstruktion der Interaktionskomponente:

3


3.2


545

❑ Jedes Toolkit macht Annahmen darüber, wie der Kontrollfluß

in einer Anwendung aussehen muß. Dies kann im Widerspruch zu den Vorstellungen eines Werkzeugentwicklers stehen. ❑ Die Art der Anbindung der Widgets an die Interaktionskompo-

nente ist durch die Konstrukteure des Toolkit festgelegt. Dabei müssen je nach Toolkit unterschiedliche Systemereignisse mit sogenannten Callback-Operationen verknüpft werden. Diese Callback-Operationen müssen in der Interaktionskomponente implementiert werden. Ein weiteres Motiv für die lose Kopplung von Interaktionskomponenten an das verwendete Toolkit ist dessen Veränderlichkeit: In der Geschichte der Entwicklung verschiedener Toolkits hat sich gezeigt, daß wiederholt Schnittstellen bis zu einem kompletten Redesign verändert wurden oder daß einige Toolkits ganz vom Markt verschwunden sind. Abbildung 3-33 zeigt einen Ausschnitt des Klassenbaumes der StarView-Bibliothek (s. [Star Division 92]). Wesentliches Merkmal dieser Bibliothek ist, daß die Bausteine in einem Vererbungsbaum angeordnet sind. Vererbung wird hierbei zum Zweck der Implementation eingesetzt; die einzelnen Bausteine sind nicht konzeptionell aufgrund ähnlicher Umgangsformen in einer Typhierarchie angeordnet.

3

Beispiel für ToolkitBibliothek


3.2


546 Abb. 3-33

Window

Bausteine der StarViewBibliothek Control

Button

ListBox

MultiListBox CheckBox

PushButton

RadioButton

So sieht der Knopf RadioButton weder aus wie ein Fenster (Window), noch ist seine Handhabung vergleichbar mit der eines Fensters: Er kann üblicherweise nicht in der Größe verändert werden; weitere Oberflächenelemente können nicht auf ihm plaziert werden; er kann auch nicht geschlossen werden. Es ist daher unverständlich, warum der RadioButton eine Spezialisierung des Fensters ist. Erst ein Blick in die Implementation von RadioButton zeigt, daß er in weiten Teilen ähnlich wie Window implementiert ist. Im Kontext wird deutlich, daß

3


3.2


547

Window eine Oberklasse zu Control, ChildApplicationWindow, und TopApplicationWindow ist. Daher hätte sich eher die Abstraktion Ereigniskontext angeboten. Kapsele die verschiedenen Arten der möglichen Handhabung eines Werkzeugs als Interaktionstypen. Realisiere einen Interaktionstyp durch die konkrete Präsentation, die die grafischen Bausteine eines Toolkit dafür anbieten. Setze eine Interaktionskomponente aus den Exemplaren der verschiedenen Interaktionstypen zusammen. Sorge dafür, daß die Interaktionskomponente nur Fachwerte (s. Kapitel 3.2.8) mit ihren Interaktionstypen austauscht.

Lösung

Interaktionstyp (IAT): Ein Interaktionstyp ist eine abstrakte Form der Handhabung eines Werkzeugs. Er kapselt die konkrete Präsentation und den Interaktionsmechanismus, den die grafischen Bausteine eines User Interface Toolkit anbieten. Dabei wandelt ein IAT Systemereignisse in Programmereignisse um. Ein IAT präsentiert und liefert nur Fachwerte. Er hat also keine globalen Effekte. Ein IAT wird von einer Interaktionskomponenten verwendet und macht sie damit unabhängig vom gewählten Toolkit.

3


3.2


548 Abb. 3-34

ITSelect

Beispiel gängiger Interaktionstypen IT_1_Select

ITRadioButtonGroup

IT_N_Select

ITListBox

MultiListBox

ITCheckBoxGroup

Beim Bau einer Interaktionskomponente trifft der Entwickler mit der Auswahl der Interaktionstypen die Entscheidung, wie die Funktionalität der Funktionskomponente in sinnvolle Benutzerinteraktionen umgesetzt werden kann. Er erzeugt für jede Handhabungsform ein Objekt aus der Menge der vorhandenen Interaktionstypen. Die Darstellungen eines Interaktionstyps an der Oberfläche und die Ergebnisse, die er liefert, sind ausschließlich Fachwerte. Diese werden von der Interaktionskomponente geliefert und entgegengenommen. Damit kann ein Interaktionstyp aus Sicht der Interaktionskomponente nebeneffektfrei und zustandslos betrieben werden. Eine Anpassung an die speziellen Erfordernisse der zu gestaltenden Benutzungsschnittstelle, wie z.B. die Größe oder die Position eines Elementes, werden nicht in den Interaktionstypen selbst beschrieben.

3


3.2


549 Abb. 3-35 Interaktionsform IATListBox im Lehrerkarten-Werkzeug

Wir verwenden hierzu separate Beschreibungen, sogenannte Ressourcen, in eigenen Dateien, die erst zur Laufzeit mit den erzeugten Objekten verknüpft werden. Für unser Pausenplanbeispiel wollen wir die Auswahl einer Lehrerkarte im Lehrerkarten-Werkzeug betrachten. In Abbildung 3-34 ist ein Interaktionstyp für die Auswahl eines Elementes aus einer vorgegebenen Menge von Elementen abgebildet: die IATListBox. Wir haben eine solche Auswahl im Lehrerkarten-Werkzeug (s. Abbildung 3-35) verwendet. Die Liste der Lehrernamen wird IATListBox mitgegeben. Nach einem Doppelklick wird die IAK über den ausgewählten Namen informiert. 3


3.2


Interaktionstypen bilden eine gute Abstraktionsmöglichkeit von konkreten Toolkits. Sie entkoppeln zudem das Material von seiner interaktiven Bearbeitung. Damit Interaktionstypen wirklich kontextunabhängig eingesetzt werden können, ist es notwendig, daß sie gegenüber ihrer IAK Wertsemantik zeigen, d.h. Fachwerte mit der IAK austauschen. Nur dann hat die IAK die volle Kontrolle über das, was ein IAT darstellt und welche Ergebnisse er liefert. Die Abstraktion von den verschiedenen Toolkits ist aber keine leichte Aufgabe. Wir müssen eine überschaubare Menge von Interaktionstypen benennen und ihre Schnittstellen so spezifizieren, daß sie tatsächlich unabhängig von einem bestimmten Toolkit sind und als Kapsel für verschiedene Toolkits verwendet werden können. Allein die verschiedenen Plattformen, wie Windows, Macintosh und X-Windows, aber auch die verschiedenen Windows-Versionen haben viele unterschiedliche grafische Bausteine. Es ist noch relativ leicht möglich, die Schnittmenge der Bausteine in den gängigen Fenstersystemen zu bilden. In jedem Fenstersystem existieren Bausteine, wie Knöpfe, Listboxen, Editierfelder und Menüs. Aber diese Schnittmenge bildet in der Regel nicht alle Arten der Interaktion ab, die zwischen Benutzer und Werkzeugen eingesetzt werden. Die Interaktion über grafische Darstellungen ist z.B. in keiner Weise standardisiert.

3

550 Diskussion


3.2


551

Auch die verschiedenen Look & Feels der einzelnen Plattformen lassen sich nur schlecht abstrahieren. So sind zum Beispiel in Systemen, die unter Windows laufen, am jeweiligen Programmfenster die Menü- und Knopfleisten angebracht. Auf dem Macintosh sind die Menü- und Knopfleisten für das aktive Programm immer in der allgemeinen Programmleiste am oberen Rand des Bildschirms zu finden. Ähnlich unterschiedlich verhält es sich mit den Knöpfen, die unter Windows 95 oder unter Windows 3.1 bei jedem Fenster zur Verfügung standen. Ein weiteres Problem stellen Annahmen von Toolkits dar, die über die Arten der Widgets und ihre Umgangsformen hinausgehen. Viele Toolkits setzen voraus, daß sie die Hauptklasse der Anwendung erzeugen und im Besitz der Hauptereignisschleife (Event Loop) sind. Dazu kommen weitere Eigenarten der verschiedenen Ereignismodelle. Um diese Eigenschaften der Toolkits zu kapseln, müssen in Rahmenwerken meist einige Toolkit-spezifische Klassen enthalten sein. Legt das Toolkit außerdem fest, daß es als White-box-Rahmenwerk (s. Kapitel 2.3.2, S. 121) über Unterklassenbildung und Überschreiben von aufgeschobenen Operationen verwendet werden muß, so sind aufwendige Konstruktionen notwendig, etwa mit Hilfe des Brückenmusters [Gamma et al. 96].

3


3.2


552

Bei der Betrachtung der Interaktionstypen stellen wir fest, daß jeder Interaktionstyp genau einen grafischen Baustein kapselt. Ein weiterer Schritt weg von einem konkreten Toolkit kann darin bestehen, von den konkreten grafischen Bausteinen zu abstrahieren und lediglich die allgemeine Handhabung, die mit einem Baustein verbunden ist, zu modellieren. Die konkrete Präsentation der Interaktion kann dann von der allgemeinen Handhabung unabhängig gemacht werden. Beispielsweise werden Knöpfe und Menüpunkte für dieselbe Handhabung verwendet, nämlich um eine Aktion des Werkzeugs zu starten. Aus Sicht der Interaktionskomponente ist es unerheblich, ob diese Aktion durch das Anklicken eines Knopfes oder durch die Anwahl eines Menüpunkts gestartet wird. Diese weitergehenden Ansätze werden derzeit in Prototypen erprobt (s. [Görtz 98]).

3


3.2


553

Rückkopplung zwischen Interaktionstypen und Interaktionskomponente Zusammenhang von Werkzeug und Material






fachliche Behälter


Ereignisverwalter

Materialverwaltung

Fachwerte

Trennung Trennung von vonHandhabung Handhabung und undPräsentation Präsentation Materialkoordinator Interaktionstypen

Rückkopplung zwischen Interaktionstypen und IAK

Die Interaktionskomponente benutzt die Interaktionstypen unter Verwendung ihrer vollen Schnittstelle, um einem Interaktionstyp den

3


3.2


554

initialen Wert mitzugeben, die Art der Präsentation einzustellen oder das Ergebnis einer Benutzerinteraktion auszulesen. Damit die Interaktionskomponente von Benutzeraktionen erfährt, muß es eine Rückkopplung zwischen Interaktionstyp und Interaktionskomponente geben. Diese Rückkopplung muß lose erfolgen, weil die Interaktionstypen den konkreten Typ der Interaktionskomponente, mit der sie zusammenarbeiten, nicht kennen dürfen. Andernfalls wären Interaktionstypen nicht mit verschiedenen Interaktionskomponenten zu benutzen. Für das Problem der losen Rückkopplung stellen wir zuerst eine Lösung mit dem Befehlsmuster vor. Anschließend diskutieren wir eine zweite, aber weniger empfehlenswerte Lösungsmöglichkeit mit dem Beobachtermuster (s. S. 251ff.). Wie können nun Ereignisse, die vom Benutzer ausgelöst werden und zu den Interaktionstypen gelangen, an die Interaktionskomponente weitergegeben werden, ohne daß der Interaktionstyp die Interaktionskomponente direkt kennt?

Problem

Aktionen des Benutzers mit der Maus oder der Tastatur werden vom Fenstersystem entgegengenommen. Das Fenstersystem wandelt diese Aktionen in Systemereignisse um, die es an die Interaktionstypen weiterleitet. Die Interaktionstypen sind zu diesem Zweck meist über einen Callback (oder über Unterklassenbildung und Brückenmuster) mit

Kontext

3


3.2


555

den entsprechenden Widgets des Fenstersystems verbunden. Die Interaktionstypen setzen die Systemereignisse in Programmereignisse um, indem sie die Interaktionskomponente verständigen. Dazu ist eine Anbindung eines Interaktionstyps an die Interaktionskomponente notwendig. Die Interaktionskomponente entscheidet dann, welche Operationen der Funktionskomponente aufgerufen werden müssen (s. Abbildung 3-36). Interaktionskomponente

Funktionskomponente

Abb. 3-36 Ereignisfluß in einem Werkzeug mit

Interaktionsform

Interaktionstypen

Interaktionsform

User Interface Toolkit

Benutzerereignisse

aktualisierte Präsentation

3


3.2


556

Wie bei der Rückkopplung zwischen Funktions- und Interaktionskomponente (s. Kapitel 3.2.3) haben wir das Problem der losen Kopplung zwischen interaktiven Komponenten. Für die Konstruktion der Interaktionstypen ist wesentlich, daß sie den konkreten Typ der Interaktionskomponente, von der sie abhängen und die sie über Ereignisse informieren wollen, nicht kennen dürfen. Andernfalls könnten Interaktionstypen nicht mit unterschiedlichen Interaktionskomponenten verwendet werden. In letzter Konsequenz müßten wir für jede neue Interaktionskomponente alle Interaktionstypen neu implementieren. Kopple Interaktionstypen über das Befehlsmuster an die Interaktionskomponente an. Definiere für die verschiedenen Programmereignisse, die von Interaktionstypen an Interaktionskomponenten verschickt werden, je eine eigene Befehlsklasse (z.B. ItemSelectedCommand, ActivateCommand). Konstruiere die Befehlsklassen so, daß sie vom Interaktionstyp mit den entsprechenden Fachwerten (s. Kapitel 3.2.8) versorgt werden, die für die Weiterverarbeitung des Ereignisses in der Interaktionskomponente benötigt werden (vgl. [Weinand 91]).

3

Lösung


3.2

IAKLehrkoerper Init() Schliessen()


IATMenuItem

Command

RegisterCommand()

Do()

557 Abb. 3-37 Kopplung von Interaktionstyp und Interaktionskomponente über Befehlsmuster

IAK erzeugen

pIATSchliessen = new IATMenuItem(pParent,"Schliessen"); pSchliessenCmd = new ActivateCommand(this, Schliessen); pIATSchliessen->RegisterCommand(pSchliessenCmd);

ActivateCommand Do()

IAK->DoProc();

Will eine Interaktionskomponente von einem Interaktionstyp-Objekt über eine Aktion des Benutzers informiert werden, so erzeugt sie sich ein geeignetes Befehlsobjekt. Diesem Befehlsobjekt übergibt die Interaktionskomponente einen Verweis (z.B. einen Methoden-Pointer) auf diejenige Operation, die gerufen werden soll, wenn das Befehlsobjekt aktiviert wird. Anschließend registriert die Interaktionskomponente das Befehlsobjekt bei dem entsprechenden Interaktionstyp-Objekt. Die verschiedenen Interaktionstypen nehmen jeweils den Satz an Befehlsobjekten entgegen, der zu ihren Interaktionen paßt. Das Inter-

3


3.2


558

aktionstyp-Objekt aktiviert das bei ihm registrierte Befehlsobjekt, wenn die entsprechende Benutzeraktion eintritt. Daraufhin ruft das Befehlsobjekt seinerseits die Operation der Interaktionskomponente auf, die bei ihm registriert wurde. Dazu benutzt das Befehlsobjekt allerdings nicht den direkten Operationsaufruf, den es ja nicht kennen soll, sondern die Schablonenoperation DoProc der Oberklasse von IAKLehrkoerper. Ist die Benutzeraktion mit der Eingabe oder Auswahl von Fachwerten verbunden (z.B. Eingabe einer Kontonummer), so benötigt die Interaktionskomponente diese Werte. Befehlsklassen, die für solche Benutzeraktionen verwendet werden, erwarten vom Interaktionstyp einen Parameter. Die Operation, die die Interaktionskomponente dem Befehlsobjekt übergeben hat, muß die entsprechenden Argumente vom Befehlsobjekt entgegennehmen. Betrachten wir das Beispiel des Lehrerkarten-Werkzeugs. In diesem Werkzeug ist es möglich, Lehrerkarten aus dem Lehrkörper zu löschen. Für diese Aktion des Benutzers gibt es im Lehrerkarten-Werkzeug einen Knopf (Button). Ein Knopf ist ein Interaktionstyp, der nur einen Typ von Befehlsobjekt, nämlich ActivateCommand, entgegennimmt. ActivateCommand ist eine Befehlsklasse, die keinen Parameter erwartet.

3


3.2


559

Der folgende Beispielcode stammt aus einer Implementation des Pausenplaners in Java. Im Konstruktor werden das InteraktionstypObjekt für den Knopf und das Befehlsobjekt erzeugt. Außerdem wird das Befehlsobjekt von der Interaktionskomponente des LehrerkartenWerkzeugs bei dem Knopf registriert. public class iakLehrerkartenWerkzeug { // Konstruktor public iakLehrerkartenWerkzeug() { // Interaktionstyp Knopf erzeugen _lehrerLoeschen = new iatButton(..); // Befehlsobjekt erzeugen und dabei Operation // ÔlehrerLoeschenÕ registrieren _lehrerLoeschenCmd = new cmdActivate (this, "lehrerLoeschen"); // Befehlsobjekt beim Interaktionstyp registrieren _lehrerLoeschen.registerCmd(_lehrerLoeschenCmd); ... } // Operation fuer das Befehlsobjekt public void lehrerLoeschen() { ... } // Attribute // Interaktionstyp private iatButton _lehrerLoeschen; // Command private cmdActivate _lehrerLoeschenCmd; ...

3


3.2


560

Wird der Knopf zum Löschen eines Lehrers gedrückt, so löst der Knopf das bei ihm registrierte Befehlsobjekt aus und das Befehlsobjekt ruft die Operation lehrerLoeschen in der Interaktionskomponente des Lehrerkarten-Werkzeugs auf. Bei einer reflexiven Sprache wie Java kann der Name der aufzurufenden Operation einfach als Zeichenkette übergeben werden. In anderen Sprachen, wie C++, muß mit einem Methoden-Pointer gearbeitet werden. Eine Interaktionskomponente stellt dieselbe Umgangsform eines Werkzeugs oft an unterschiedlichen Stellen der Benutzungsschnittstelle dar. Die einfache Operation des Löschens eines Lehrers im Lehrerkarten-Werkzeug könnte sowohl über einen Knopf als auch über einen Menüpunkt oder durch einen Eintrag in einem Popup-Menü aktiviert werden. In diesem Fall kann die Interaktionskomponente bei den drei Interaktionstypen dasselbe Befehlsobjekt anmelden. Egal von welchem der drei Interaktionstypen das Befehlsobjekt ausgelöst wird, es wird in allen drei Fällen dieselbe Operation der Interaktionskomponente zum Löschen eines Lehrers aufgerufen. Wir können auch ein Befehlsobjekt bei mehreren gleichartigen Interaktionstypen anmelden. Wird z.B. in einem Fenster die Liste der bisher angezeigten Dokumente dargestellt, so hat diese Liste eine variable Länge. Wir können also nicht von vornherein festlegen, wie

3

Diskussion


3.2


561

viele Elemente in der Liste angezeigt werden. In diesem Fall können wir ein Befehlsobjekt bei jedem der Menüeinträge anmelden, die die Liste darstellen. Wird ein Menüeintrag ausgewählt, so aktiviert er das Befehlsobjekt und die IAK kann mit Hilfe des Befehlsobjekts herausfinden, welcher Menüeintrag aktiviert wurde. Ein wichtiger Vorteil von Befehlsobjekten ist die Möglichkeit, Undo-und Redo-Mechanismen direkt am Befehlsobjekt zu realisieren. Dort kann der relevante Kontext für die Umkehrung des Befehls gespeichert werden. Einmal ausgeführte Befehlsobjekte werden in einer Liste, die die Abfolge der Befehle festhält, gespeichert. Durch das Traversieren dieser Liste vorwärts und rückwärts können wir ein unbegrenztes Undo und Redo realisieren. Realisierungsansatz: Beobachtermechanismus

Kopple Interaktionstypen über den Beobachtermechanismus an die Interaktionskomponente (vgl. S. 251ff.). Die Interaktionskomponente wird den Interaktionstypen als abstrakter Beobachter bekannt gemacht (s. Abbildung 3-38). Je nach verwendetem Mechanismus wird die Interaktionskomponente über ein spezielles Ereignis oder über eine allgemeine Benachrichtigung von einer Benutzeraktion informiert.

3

Lösung


3.2

Beobachter

• BeachteÄnderung


562

Beobachtbar • RegistriereBeobachter • DeregistriereBeobachter • MeldeÄnderung

List* pBeobachterListe; Cursor BeobachterCursor(pBeobachterListe); MeldeAenderung() { while (BeobachterCursor.Forth()) { BeobachterCursor.Current()->BeachteAenderung(); } }

IAKLehrerEditor • BeachteÄnderung

IATMenuItem

BeachteAenderung() BeachteAenderung() {{ if if (pIATSchliessen->Selektiert()) (pIATSchliessen->Selektiert()) this->Schliessen(); this->Schliessen(); }}

• Selektiert

Abb. 3-38 Der Beobachtermechanismus zwischen IAT und IAK

3


3.2


Die Kopplung der Interaktionstypen mit der Interaktionskomponente über den Beobachtermechanismus wurde in WAM-Konstruktionen zu Beginn oft eingesetzt. Ein offensichtlicher Vorteil ist, daß der Beobachtermechanismus universell zur Kopplung von interaktiven Komponenten verwendet wird. Dadurch kann er sehr allgemein in einem Rahmenwerk gekapselt werden, wie dies z.B. das Smalltalk-System (VisualWorks) zeigt. Aus unserer Sicht sprechen trotzdem einige Gründe gegen diese Lösung: Bei der Verwendung von anonymen Ereignissen wird lediglich ein relativ unspezifisches Ereignis vom Interaktionstyp an die Interaktionskomponente geschickt. Die IAK muß nach der Benachrichtigung bei dem entsprechenden Interaktionstyp nach den geänderten oder eingegebenen Werten fragen. Da die Interaktionskomponente weiß, für welche Art der Interaktion sie die jeweiligen Interaktionstypen verwendet, ist diese Nachfrage im Prinzip überflüssig. Der Interaktionstyp sollte die Werte besser direkt mit der Benachrichtigung mitschikken, wie es bei der Lösung mit dem Befehlsmuster möglich ist. Benutzen wir die Kopplung über eine Ereignisklasse, dann muß jeder IAT die Semantik der jeweiligen Ereignisobjekte selbst bestimmen. Die IAK kann lediglich über den Namen des Ereignisobjekts feststellen, um welche Art von Interaktion es sich handelt. Werden

3

563 Diskussion


3.2


564

Befehlsklassen verwendet, so gibt es für jede Art von Befehl, der von den verschiedenen IATs ausgelöst werden kann, ein spezielle Klasse. Dieser speziellen Klasse können spezifische Parameter mitgegeben werden. Sie hat entsprechende Umgangsformen für genau diese Art der Interaktion zwischen Benutzer und System. Wir gehen zudem beim Beobachtermechanismus davon aus, daß ein Objekt potentiell von mehreren anderen Objekten beobachtet wird. Bei Interaktionstypen und Interaktionskomponente ist das niemals der Fall. Alle IAT-Objekte, die von einer Interaktionskomponente erzeugt werden, werden nur von dieser benutzt und müssen nur ihr Rückkopplung geben. Der Beobachtermechanismus ist sozusagen eine zu mächtige Lösung.

3


3.2


565

3.2.5 Werkzeugkomposition Zusammenhang von Werkzeug und Material





fachliche Behälter

WerkzeugWerkzeugkomposition komposition

Ereignisverwalter

Materialverwaltung

Fachwerte


Umgebung


Materialkoordinator

Zur Konstruktion komplexer Werkzeuge stellen wir einen Konstruktionsansatz vor, der es erlaubt, Komponenten als Substrukturen zu

3


3.2


566

größeren Einheiten zusammenzuführen und diese dabei lose zu koppeln. Dazu setzen wir den Beobachtermechanismus ein, den wir schon beim Muster Rückkopplung zwischen Funktion und Interaktion verwendet haben. Bei der Kopplung von Funktionskomponenten benutzen wir ein weiteres Muster, die Zuständigkeitskette (Chain-OfResponsibility, [Gamma et al. 96]), um Anforderungen an übergeordnete Komponenten weiterzuleiten. Ein Werkzeug, das aus mehreren Komponenten besteht, soll einen definierten Abschluß haben. Dazu schließen wir das Werkzeug gegenüber seinem Kontext durch ein Werkzeug-Objekt ab. Im folgenden Abschnitt zeigen wir, wie komplexe Werkzeuge aus einfacheren Werkzeugen zusammengesetzt werden können. Wir beschreiben die Zusammenarbeit zwischen umgebenden und eingebetteten Funktionskomponenten sowie zwischen den entsprechenden Interaktionskomponenten. Zum Abschluß stellen wir das WerkzeugObjekts und die Zuständigkeitskette vor.

3


3.2


567

Kombi- und Sub-Werkzeuge Zusammenhang von Werkzeug und Material






fachliche Behälter


Kombi- und EreignisMaterialSub-Werkzeug verwalter verwaltung

Fachwerte


Umgebung

Materialkoordinator

3


3.2


568

Komplexe Werkzeuge nur aus einer Funktions- und einer Interaktionskomponente aufzubauen, ist nicht sinnvoll. Diese Komponenten werden mit wachsender Komplexität immer unüberschaubarer. Zudem muß jedes Werkzeug von Grund auf neu entwickelt werden, auch wenn ähnliche Teilfunktionen realisiert werden. Werkzeuge sollen daher soweit wie möglich auf der Basis existierender Werkzeugkomponenten konstruiert werden. So läßt sich die Komplexität der einzelnen Komponenten reduzieren und gleichzeitig ein hohes Maß an Wiederverwendung der Bausteine erzielen. Wie soll ein Werkzeug in Teilwerkzeuge untergliedert werden und auf welche Art und Weise sollen diese Teilwerkzeuge zu einem Werkzeug integriert werden?

Problem

Werkzeuge für die Unterstützung komplexer Handlungen sind meist so aufgebaut, daß sie ein Material und den dazugehörenden Behälter oder sogar mehrere Materialien und Behälter bearbeiten. Die Arbeit mit dem Werkzeug läßt sich in diesen Fällen in Teilaufgaben zerlegen – Arbeit mit den einzelnen Materialien und den Behältern.

Kontext

Wir geben in Abbildung 3-39 ein Beispiel für ein komplexes Werkzeug: das mittlerweile bekannte Lehrerkarten-Werkzeug. Das Werkzeug zeigt auf der linken Seite eine Liste der Lehrerkarten eines Lehr-

3


3.2


569 Abb. 3-39 Ein Werkzeug für Lehrerkarten

körpers. Gleichzeitig wird die in der Liste jeweils ausgewählte Lehrerkarte rechts in einen Lehrerkarten-Editor geladen. Wir könnten das Werkzeug auf unterschiedliche Weise konstruieren: ❑ Wir entwerfen zwei getrennte Werkzeuge. ❑ Wir konstruieren ein komplexes Werkzeug, das die Lehrerkar-

ten sowohl auflistet als auch editieren kann. ❑ Wir setzen das komplexe Werkzeug aus einzelnen Komponen-

ten zusammen. 3


3.2


570

Wenn wir zwei getrennte Werkzeuge, einen Lehrerkarten-Auflister und einen Lehrerkarten-Editor, bauen, ist es schwierig, den Zusammenhang zwischen den Werkzeugen herzustellen. Denn die Auswahl im Lehrerkarten-Auflister bestimmt ja, welches Material im Lehrerkarten-Editor geladen werden soll. Um diesen Zusammenhang herzustellen, müßten wir entweder die beiden Werkzeuge koppeln oder die Verbindung über das Material herstellen. Eine direkte Kopplung zwischen den beiden Werkzeugen würde bedeuten, daß eins der beiden Werkzeuge (z.B. der Lehrerkarten-Auflister) das andere Werkzeug kennen muß. Das ist keine gute Lösung, denn damit verliert der Lehrerkarten-Auflister seine Selbständigkeit und ist nur noch in Kombination mit dem Lehrerkarten-Editor zu verwenden. Die Verbindung der Werkzeuge über das Material scheidet nach unseren Konstruktionsprinzipien auch aus, da dann das Material etwas von der Existenz der Werkzeuge wissen oder zumindest einen Benachrichtigungsmechanismus besitzen müßte. Die Konstruktion eines einzigen komplexen Werkzeugs ist zwar möglich, aber softwaretechnisch unbefriedigend, weil wir die erkennbaren Einzelteile, nämlich den Lehrerkarten-Auflister und den Lehrerkarten-Editor, nicht einzeln wiederverwenden können. Wir müßten

3


3.2


571

z.B. für einen Pausenplaner, in dem auch Lehrerkarten aufgelistet werden sollen, wieder einen neuen Lehrerkarten-Auflister schreiben. Aus diesen Gründen liegt es nahe, die einzelnen Teilaufgaben in eigene Werkzeugkomponenten zu kapseln. Werkzeuge können dann nach dem Bausteinprinzip zusammengesetzt werden. Bestehende Werkzeuge sollen also ❑ als Komponenten in neuen Werkzeugen einsetzbar sein, d.h.,

ihre Funktionalität kann in einem erweiterten Kontext als SubWerkzeug wiederverwendet werden, ❑ als Kombi-Werkzeuge die Funktionalität von neuen Kompo-

nenten verwenden können.

3


3.2


572

Einfaches Werkzeug, Kombi-Werkzeug, Sub-Werkzeug, KontextWerkzeug: Ein einfaches Werkzeug besitzt anwendungsfachlich eine elementare Funktionalität. Softwaretechnisch besitzt es keine Sub-Werkzeuge. Ein Kombi-Werkzeug kombiniert verschiedene fachliche Dienstleistungen zur Erledigung einer komplexen Aufgabe. Softwaretechnisch ist es aus existierenden Sub-Werkzeugen zusammengesetzt. Ist ein Werkzeug als technische Komponente innerhalb eines anderen Werkzeugs eingesetzt, so wird es als Sub-Werkzeug bezeichnet. Ein Kontext-Werkzeug bildet den technischen und konzeptionellen Abschluß für Sub-Werkzeuge. Es realisiert damit ein fachliches Kombi-Werkzeug. Kombi-Werkzeug und einfaches Werkzeug sind anwendungsfachliche Begriffe des Benutzungsmodells. Sub- und Kontext-Werkzeug sind Begriffe, die bei der technischen Konstruktion von Werkzeugen verwendet werden.

Wir suchen eine Konstruktion, bei der einfache Werkzeuge nach einem einheitlichen Schema zu Kombi-Werkzeugen zusammengesetzt werden können.

3


3.2


573 Abb. 3-40

Werkzeug

Werkzeuge als Sub- und Kombi-Werkzeuge

Sub-Werkzeug einfaches Werkzeug

Kombi-Werkzeug

Entwickle Werkzeuge so, daß sie für eine definierte Aufgabe oder Handlungseinheit zuständig sind. Integriere die Teilaufgaben einfacher Werkzeuge zu einem Kombi-Werkzeug. Konstruiere ein KontextWerkzeug, das mehrere Sub-Werkzeug integriert. Jedes Werkzeug kann prinzipiell in den Kontext eines umgebenden Werkzeugs eingebettet werden und wird damit zum Sub-Werkzeug. Das Schema von Abbildung 3-40 verdeutlicht die begrifflichen Zusammenhänge – es stellt kein Klassendiagramm dar!

Lösung

Auf unser Beispiel mit dem Lehrerkarten-Werkzeug bezogen bedeutet die gerade vorgestellte Aufteilung, daß das Lehrerkarten-Werkzeug ein Kombi-Werkzeug ist, welches durch ein Kontext-Werkzeug und zwei Sub-Werkzeuge implementiert wird. Die beiden Sub-Werkzeuge

3


3.2


574

Lehrerkarten-Auflister und Lehrerkarten-Editor wissen nichts voneinander. Sie werden vom Kontext-Werkzeug so gesteuert, daß die Gesamtaufgabe des Kombi-Werkzeugs – nämlich Lehrerkarten zu bearbeiten – erfüllt wird.

3


3.2


575

Rückkopplung zwischen Sub-FK und Kontext-FK Zusammenhang von Werkzeug und Material






fachliche Behälter

WerkzeugWerkzeugkomposition komposition Umgebung

Fachwerte


Kombi- und Rückkopplung EreignisMaterialSub-Werkzeug zwischen Materialverwalter verwaltung koordinator Sub- und Kontext-FK

Werkzeuge bestehen in ihrer Konstruktion aus Funktions- und Interaktionskomponenten (s. Kapitel 3.2.2). Dieses Prinzip soll auch bei

3


3.2


576

der Realisierung von Kombi-Werkzeugen aufrecht erhalten werden. Die Zusammenarbeit zwischen Sub-FK und den sie umgebenden Kontext-FK wird ähnlich wie die Kopplung zwischen Funktions- und Interaktionskomponente mit Hilfe des Ereignismusters oder des Beobachtermechanismus konstruiert. Bei der Konstruktion von Sub-Werkzeugen und Kontext-Werkzeugen, die zusammen ein Kombi-Werkzeug bilden, stellt sich die Frage, wie sich die Funktionskomponenten der bisher betrachteten einfachen Werkzeuge im Rahmen eines Kombi-Werkzeugs verhalten sollen. Zur Realisierung eines Kombi-Werkzeugs greifen wir auf einfache Werkzeuge zu, die die entsprechende Funktionalität bereitstellen. Entsprechend werden die Funktionskomponenten der einfachen Werkzeuge als Sub-FKs verwendet. Für die Kombination von mehreren Sub-FKs wird zusätzlich eine Kontext-FK konstruiert. Die Kontext-FK realisiert das Zusammenspiel der Sub-FKs und delegiert die Teilaufgaben an die jeweils zuständige Sub-FK.

Problem

Kontext

Kontext-FK, Sub-FK: Eine Funktionskomponente wird zur Kontext-FK, indem sie Teilaufgaben an eine oder mehrere Sub-FKs delegiert und diese in ihrem Zusammenspiel koordiniert. Eine Sub-FK dient zur Erledigung einer definierten Teilaufgabe. Sie wird fachlich unabhängig von einer potentiellen Kontext-FK oder weiterer SubFKs konstruiert.

3


3.2


577

Die Delegation von Teilaufgaben an die Sub-FKs bedeutet eine klare Aufgabenteilung zwischen den Komponenten. Die Kontext-FK soll sich nicht selbst um alle Teilaufgaben kümmern müssen. Damit die Kontext-FK ihre koordinierende Funktion wahrnehmen kann, muß sie aber Informationen darüber erhalten, welche relevanten Veränderungen bei den Sub-FKs eingetreten sind. Wir haben hier ein vergleichbares Rückkopplungsproblem wie zwischen Funktions- und Interaktionskomponente (s. Kapitel 3.2.3) und lösen es auch in ähnlicher Weise (s. Diskussion weiter unten). In einer Richtung, nämlich von der Kontext-FK zu den Sub-FKs muß eine enge Kopplung gegeben sein, da die Kontext-FK bestimmte Aufgaben an die Sub-FKs delegiert, also deren fachliche Schnittstelle kennen muß. In der anderen Richtung setzen wir die lose Kopplung eine, da die Kontext-FK über Änderungen an der Sub-FK benachrichtigt werden muß. Dennoch sollen Sub-FKs unabhängig von der Kontext-FK konstruiert werden und in unterschiedlichen Kontexten einsetzbar sein. Wenn wir wiederverwendbare Werkzeugkomponenten bauen wollen, dann ist schließlich bei der Konstruktion einer Funktionskomponente nicht klar, daß sie später einmal als Sub-FK in einer bestimmten Kontext-FK integriert wird.

3


3.2


Entwickle die Funktionskomponente eines Einzelwerkzeugs so, daß sie auch als Sub-FK eingesetzt werden kann. Dazu muß die Funktionskomponente eine definierte Teilaufgabe unterstützen. Integriere SubFKs mit Hilfe einer Kontext-FK zu einem Kombi-Werkzeug. Die Kontext-FK delegiert entsprechend Teilaufgaben an ihre Sub-FKs und koordiniert sie. Löse das dabei entstehende Rückkopplungsproblem durch das Ereignismuster oder den Beobachtermechanismus.

578 Lösung

Abb. 3-41

Kontext-FK

Rückkopplung zwischen Kontext-FK und Sub-FK

Sub-FK 1

Sub-FK 2

In Abbildung 3-41 ist zu sehen, wie der Beobachtermechanismus (s. S. 251ff.) umgesetzt wird. Die Kontext-FK wird hier zu einem Beobachter und die Sub-FKs sind die Beobachteten. Auf diese Weise ist jede

3


3.2


579

Kontext-FK sowohl Beobachter als auch Beobachteter. Gegenüber ihren Sub-FK übernimmt die Kontext-FK die Rolle des Beobachters, gegenüber ihren Interaktionskomponenten dagegen hat sie die Rolle eines Beobachteten inne. In unserem Beispiel des Lehrerkarten-Werkzeugs koordiniert die Kontext-FK FKLehrerkarten die beiden Sub-FKs FKLehrerAuflister und FKLehrerEditor. Wird das Lehrerkarten-Werkzeug aufgerufen, so übergibt die Kontext-FK FKLehrerkarten der Sub-FK FKLehrerAuflister den Behälter der Lehrerkarten unter dem Aspekt Auflistbar. Wird im Lehrerkarten-Auflister eine Karte ausgewählt, so benachrichtigt die Funktionskomponente des Lehrerkarten-Auflisters ihre Kontext-FK von dieser Veränderung. Die Kontext-FK reagiert auf diese Benachrichtigung, indem sie der Funktionskomponente FKLehrerEditor die entsprechende Lehrerkarte zur Anzeige übergibt. Wird im Lehrerkarten-Editor eine Lehrerkarte geändert (s. Abbildung 3-42), so benachrichtigt die Funktionskomponente des Lehrerkarten-Editors die Kontext-FK über diese Veränderung. Die Kontext-FK wird nun dafür sorgen, daß im Lehrerkarten-Auflister die Liste der Lehrer neu angezeigt wird.

3


3.2

IAKLehrerEditor

FKLehrerEditor


FKLehrerKarten

580

FKLehrerAuflister

Lehrer verändern BeachteAenderung IstLehrerVeraendert? true SetzeLehrkoerper Benachrichtigung der IAKLehrerAuflister Update der Anzeige

Abb. 3-42

An dieser Stelle kann es sein, daß im Lehrerkarten-Editor der Name des Lehrer geändert wurde und diese Änderung tatsächlich zu einer veränderten Liste im Lehrerkarten-Auflister führt. Es kann aber auch sein, daß an der Lehrerkarte nur solche Daten geändert wurden, die im Lehrerkarten-Auflister nicht angezeigt werden. Wir könnten daher versucht sein, FKLehrerEditor so zu konstruieren, daß nur dann eine Benachrichtigung der Kontext-FK erfolgt, wenn tatsächlich etwas geändert wurde, was für den Lehrerkarten-Auflister relevant ist. Die

3

Kontrollfluß bei Änderung einer Lehrerkarte


3.2


581

Entscheidung, ob eine Veränderung für den Kontext einer Funktionskomponente interessant ist, sollte aber nie die Sub-FK selbst treffen, weil sie sonst nicht allgemein wiederverwendbar ist. Benachrichtigt die Funktionskomponente des Lehrerkarten-Editors ihre Kontext-FK nur bei der Änderung des Lehrernamens, so kann der LehrerkartenEditor nicht in ein Werkzeug integriert werden, das in einem anderen Sub-Werkzeug mehr als den Lehrernamen anzeigen soll. Wir setzen für die Kopplung von Kontext-FK und Sub-FK genau wie bei der Kopplung von FK und IAK den Beobachtermechanismus oder das Ereignismuster ein, obwohl ein Unterschied zwischen diesen beiden Arten der Kopplung besteht. Bei der Kopplung von FK und IAK gehen wir davon aus, daß es sich möglicherweise um eine Eins-zu-nBeziehung handelt, weil auf einer Funktionskomponente mehrere Interaktionskomponenten arbeiten können. Für die Beziehung von Kontext-FK und Sub-FK ist dies nicht gegeben. Eine Sub-FK hat immer nur genau eine Kontext-FK. Wäre dies nicht der Fall, würde die Einheit von Werkzeugen aufgehoben und ein Teilwerkzeug müßte zu mehreren Werkzeugen gehören. Das Ereignismuster oder der Beobachtermechanismus werden an dieser Stelle trotzdem eingesetzt, weil die Sub-FK ihrer Kontext-FK keinen Befehl, sondern eine fachliche Zustandsänderung mitteilt. Der

3

Diskussion


3.2


582

Beobachtermechanismus oder das Ereignismuster sind genau zu diesem Zweck entwickelt worden. Das Befehlsmuster, das zwischen IATs und IAK eingesetzt wird, ist hier nicht zu gebrauchen, weil es nicht zur Meldung von Zustandsänderungen konzipiert ist. Es liefert einen Befehl aus einem vorgegebenen Satz und einen definierten Wert. Damit ist aber bereits festgelegt, was eine Benutzeraktion für einen IAT bedeutet. Je nach Kontext-FK ist aber völlig offen, wie eine Zustandsänderung der Sub-FK interpretiert wird und welche Informationen die Kontext-FK von ihrer Sub-FK haben will. Wenn wir zwischen Sub-FK und Kontext-FK den Beobachtermechanismus oder das Ereignismuster einsetzen, können wir die gleichen Ereignisse auch für die abhängigen IAKs verwenden. Meldet eine SubFK eine Zustandsänderung, so muß die Sub-FK nicht entscheiden, welche Zustandsänderungen für ihre Kontext-FK und welche für die IAKs von Bedeutung sind. Vielmehr melden sich Kontext-FK und IAKs nach einem Schema für jeweils relevante Ereignisse an. Diese Gleichbehandlung von Kontext-FK und IAKs aus Sicht der Sub-FK können wir nur realisieren, wenn Kontext-FK und IAK an der gleichen Schnittstelle für Ereignisse angemeldet werden können. Diese Entwurfsentscheidung ist nicht unumstößlich. In den RWGProjekten wurden aus Effizienzgründen zwei Ereigniskanäle realisiert – einer zwischen FK und IAK und einer zwischen Sub- und Kontext-

3


3.2


583

FK. Die Abwägung zwischen einer eleganten und einheitlichen Lösung oder einer effizienteren Lösung muß im Einzelfall getroffen werden. Rückkopplung zwischen Sub-IAK und Kontext-IAK Zusammenhang von Werkzeug und Material






fachliche Behälter


Fachwerte

Trennung von Handhabung und Präsentation Rückkopplung Kombi- und Rückkopplung EreignisMaterialzwischen Sub-Werkzeug zwischen Materialverwalter verwaltung koordinatorSub- und Kontext-IAK Sub- und Kontext-FK Umgebung

3


3.2


584

Sind wir in der Lage, die Funktionskomponenten von Sub-Werkzeugen mit Blick auf ein Kombi-Werkzeug zu verbinden, so können wir uns dem gleichen Problem bei den Interaktionskomponenten zuwenden. Auch hier kommt der Beobachtermechanismus zum Einsatz. Wie koppeln wir die Interaktionskomponenten eines Kombi-Werkzeugs?

Problem

Entsprechend der Konstruktion der Funktionskomponenten entwikkeln wir für die Sub-Werkzeuge auch jeweils eigene Interaktionskomponenten. Da ein Kontext-Werkzeug für die Erfüllung seiner Aufgaben mehrere Sub-Werkzeuge integriert, muß es eine KontextInteraktionskomponente geben, die diese Kombination visualisiert. Wir können hier die gleiche Konstruktion wählen, wie bei der Integration der Funktionskomponenten. Dazu verwenden wir die vorhandenen Interaktionskomponenten der Sub-Werkzeuge und bauen sie in eine Kontext-IAK ein.

Kontext

Entwickle die Interaktionskomponente eines Einzelwerkzeugs so, daß sie auch als Sub-IAK von Kombi-Werkzeugen eingesetzt werden kann. Dazu muß sie einen einheitlichen Interaktionsstil zu anderen IAKs aufweisen. Integriere Sub-IAKs mit Hilfe einer Kontext-IAK. Verbinde die

Lösung

3


3.2


585

Sub-IAKs mit ihrer Kontext-IAK durch den Beobachtermechanismus. Diese Konstruktion ist in Abbildung 3-43 dargestellt. Kontext-IAK

Kontext-FK

Abb. 3-43 Kombi-Werkzeug aus symmetrischen Sub- und Kontextkomponenten

Sub-IAK 1

Sub-FK 1

Sub-IAK 2

Sub-FK 2

Diese Lösung ist in ihren Komponenten symmetrisch: Die Integration der Sub-Werkzeuge wird von einer Kontext-IAK und einer KontextFK geleistet. Für jedes Sub-Werkzeug haben wir jeweils eine Sub-IAK und eine Sub-FK. Jede FK ist über einen Reaktionsmechanismus mit »ihrer« IAK verbunden. Die Sub-IAKs und die Sub-FKs werden über den gleichen Mechanismus von ihren jeweiligen Kontextkomponenten koordiniert.

3


3.2


586

Konstruktionsansatz: Keine Kopplung von Kontext- und Sub-IAKs

Diese symmetrische Zusammensetzung von Komponenten ist sehr elegant. Allerdings können wir meist darauf verzichten, die Kontext-IAK und ihre Sub-IAKs durch direkte Benutzung und die Beobachtungsbeziehung zu verbinden. Alle fachlichen Veränderungen werden über die Funktionskomponente durchgeführt und von ihr signalisiert. Bei der Funktionskomponente ist das fachliche Wissen eines Werkzeugs angesiedelt. Funktionskomponenten sind für ihre Rolle als Sub-FK bereits vorbereitet, weil sich bei ihnen durch das Muster Rückkopplung zwischen Funktion und Interaktion (s. Kapitel 3.2.3) beliebig viele Beobachter anmelden können. Kontext-IAK

Kontext-FK

Lösung

Abb. 3-44 Komposition von FKs und IAKs

Sub-IAK 1

Sub-FK 1

Sub-IAK 2

Sub-FK 2

3


3.2


587

Die Beziehung zwischen Kontext-IAK und Sub-IAKs wird nur aus technischen Gründen benötigt. Ältere Fenstersysteme stellen den Entwickler vor die Aufgabe, beim Verschieben von überlappenden Fenstern explizit für eine aktualisierte Darstellung (redraw oder refresh) sorgen zu müssen. Dazu benötigt eine Kontext-IAK den direkten Zugriff auf ihre Sub-IAKs. Da die meisten modernen Fenstersysteme diese Aufgabe selbständig durchführen, ist dieser Grund praktisch kaum noch relevant. Der andere technische Grund, der eine direkte Beziehung zwischen Kontext-IAK und Sub-IAKs erfordert, hängt mit der Erzeugung und dem Löschen von Sub-Werkzeugen zusammen (s. S. 289 und S. 291). Wird ein Werkzeug erzeugt oder gelöscht, so muß eine Komponente dies für die Sub-IAKs leisten. Diese Aufgabe wird in der Regel von der Kontext-IAK übernommen. Die meisten Konstruktionen verbergen diese Mechanismen allerdings in den Oberklassen eines Rahmenwerks (s. Kapitel 2.3.2), so daß für den Anwendungsentwickler bei der fachlichen Konstruktion von Interaktionskomponenten tatsächlich der Eindruck entsteht, es gäbe keine Beziehung zwischen Kontext-IAK und Sub-IAKs.

3


3.2


588

Konstruktionsansatz: Kombination mit neuer IAK

Wir können Kombi-Werkzeuge auch bauen, indem wir mehrere FK mit einer komplexen IAK verbinden. Die bisher beschriebene Konstruktion, bei der zu einer FK immer genau eine IAK gehört, hat in manchen Fällen einen Nachteil: Jede Sub-IAK legt für ihre Präsentation die Umsetzung von Systemereignissen in anwendungsspezifische Ereignisse, d.h. geänderte Darstellungen oder Aufrufe ihrer Sub-FK, fest. Diese Interpretation ist bei der Wiederverwendung des Sub-Werkzeugs in anderen Werkzeugen vor der Kontext-FK verborgen. Damit hat der Entwickler des Kombi-Werkzeugs ohne Eingriff in das SubWerkzeug keinen Einfluß darauf, ob die Handhabung und Präsentation zwischen den Sub-Werkzeugen und dem einbettenden Kontext einheitlich sind. Ein gewisses Maß an Einheitlichkeit im Interaktionsverhalten läßt sich sicherlich über Gestaltungsrichtlinien (Style Guides) erreichen. Um aber die Kontrolle über Sub-FKs vollständig bei der Kontext-FK zu halten, wählen wir eine Konstruktion entsprechend Abbildung 3-45.

3

Lösung


3.2


589 Abb. 3-45

Kontext-IAK

Kombi-Werkzeug mit eigener IAK

Kontext-FK

Sub-FK 1

Sub-FK 2

Abbildung 3-45 zeigt ein Kombi-Werkzeug mit einer komplexen Kontext-IAK. Für die jeweiligen Sub-Werkzeuge gibt es keine eigenen SubIAKs. Die Kontext-IAK kennt nur die Schnittstelle der Kontext-FK. Diese leitet alle Aufrufe, die in den Zuständigkeitsbereich der Sub-FKs fallen, geeignet an diese weiter.

3


3.2


Der Vorteil dieses Konstruktionsansatzes liegt in der großen Flexibilität, die der Anwendungsentwickler bei der Gestaltung von Handhabung und Präsentation hat. Damit können auch Werkzeuge als SubWerkzeuge integriert werden, die ursprünglich abweichende oder überflüssige Oberflächenelemente (wie z.B. eigene Hauptmenüs) aufweisen. Der Ansatz hat aber auch schwerwiegende Nachteile, weil die Kontext-FK die Sub-FKs vollständig von der Kontext-IAK abschirmt. Deshalb muß jede Benutzeraktion, die im Rahmen der Aufgabenteilung des Kombi-Werkzeugs eigentlich als Aufruf an eine Sub-FK gerichtet ist, zunächst von der Kontext-IAK an die Kontext-FK gehen, um von dort in einem zweiten Aufruf an die entsprechende Sub-FK weitergeleitet zu werden. Ein ähnlicher Doppelaufwand ist für die Rückkopplung zu leisten, da der Reaktionsmechanismus zwischen Sub-FKs und Kontext-FK verläuft und erst von dort zur Kontext-IAK besteht.

590 Diskussion

Zusammenfassende Diskussion der Varianten

Ob die Konstruktion mit einer gemeinsamen IAK oder mit individuellen IAKs je Sub-Werkzeug gewählt wird, hängt von der Gestaltung und der Zusammenarbeit der Werkzeuge ab. Wenn wir Sub-Werk-

3


3.2


591

zeuge als eigenständige (Teil-) Fenster betreiben wollen und wenn wir das Kombi-Werkzeug hauptsächlich mit Hilfe der Kontext-FK integrieren können, so wählen wir die Konstruktion mit je einer IAK pro FK. Eine Kopplung zwischen Sub-IAKs und Kontext-IAK werden wir selten benötigen. Steht die einheitliche Handhabung des gesamtes Kombi-Werkzeugs im Vordergrund, und unterscheidet sie sich wesentlich von den vorhandenen Einzelwerkzeugen, so entscheiden wir uns für eine neue gemeinsame IAK. Haben wir einen Auflister als vorgefertigtes Werkzeug, dann können wir ihn ohne großen Aufwand in das Lehrerkarten-Werkzeug integrieren. Soll der Lehrerkarten-Auflister seine Lehrerkarten nicht als übliche Auswahlliste präsentieren, sondern als Karteikarten in einem Kasten mit den Namenskürzeln der Lehrer als »Reiter« auf den Karten, so läßt sich zwar die Funktionskomponente des LehrerkartenAuflisters als Sub-FK wiederverwenden, nicht jedoch die Interaktionskomponente. Der Mehraufwand bei der Konstruktion der KontextIAK und der Kontext-FK muß allerdings in Betracht gezogen werden.

3


3.2


592

Werkzeugabschluß Zusammenhang von Werkzeug und Material






fachliche Behälter

WerkzeugWerkzeugkomposition komposition Trennung von Handhabung und Präsentation Rückkopplung Kombi- und Rückkopplung EreignisMaterialzwischen Sub-Werkzeug zwischen Materialverwalter verwaltung koordinatorSub- und Kontext-IAK Sub- und Kontext-FK

Fachwerte

Umgebung

Werkzeugabschluß

Die Konstruktion von Werkzeugen aus Sub-Werkzeugen zeigt, daß Werkzeuge aus einer rekursiven Struktur von Werkzeugkomponenten

3


3.2


593

bestehen. Um das Werkzeug als Ganzes anzusprechen, hat es sich in vielen WAM-Architekturen durchgesetzt, ein fachlich motiviertes Kombi-Werkzeug auch technisch durch ein Werkzeug-Objekt abzuschließen. Wenn Werkzeugkomponenten vollständig rekursiv konstruiert sind, läßt sich der Werkzeugabschluß konstruktiv nicht einfach festlegen. Anders gefragt: Welche Komponenten im FK/IAK-Baum eines Werkzeugs sollen für das gesamte Werkzeug stehen und gegebenenfalls Informationen tragen, die das gesamte Werkzeug betreffen?

Problem

Ein Werkzeug ist fachlich betrachtet eine recht gut zu definierende Einheit. Im Konzeptionsmuster Zusammenhang von Werkzeug und Material haben wir eine Reihe von Kriterien angegeben, die ein Werkzeug als Ganzes charakterisieren. Durch die Aufteilung eines Werkzeugs in Funktion und Interaktion und die rekursive Konstruktion von Kombi-Werkzeugen aus Sub- und Kontextkomponenten ist diese konzeptionelle Einheit technisch nicht mehr einfach festzustellen. Dies zeigt sich an mehreren Stellen: Von der fachlichen Handhabung her sollte jedes Werkzeug einen Mechanismus haben, der es erlaubt, Änderungen an dem Material, das sich gerade in der Bearbeitung befindet, wieder zurückzunehmen. Zu diesem Zweck muß im Werkzeug eine Arbeitskopie des Materials

Kontext

3


3.2


594

angelegt oder die Veränderungen müssen jeweils protokolliert werden. Bei der Konstruktion von Werkzeugen, die lediglich aus FK- und IAKBäumen bestehen, ist nicht klar, welche FK eine Arbeitskopie oder ein Protokoll anfertigt. Es macht wenig Sinn, daß jede Funktionskomponente ihre eigene Kopie anfertigt und so ein hoher Kopieraufwand und ein entsprechender Änderungsaufwand entsteht. Gäbe es eine Komponente, die für das gesamte Werkzeug steht, so könnten wir ihr diese Aufgabe übertragen. Ein Werkzeug muß weitere technische und fachliche Zuständigkeiten als Ganzes erfüllen, die wir entsprechend bei einer dafür vorgesehenen Instanz (!) verwalten möchten. Einfache Beispiele für diese Zuständigkeiten sind Informationen über Werkzeugnamen, Präsentationssymbol (Icon), Herstellernamen und Version des Werkzeugs sowie ggf. eine Auflistung der Aspekte, die das Werkzeug bearbeiten kann. Diese Informationen könnten bei der Kontext-FK eines Werkzeugs abgelegt werden. Es läßt sich aber auch argumentieren, daß sich diese Informationen eher auf das Werkzeug als Ganzes beziehen und die Kontext-FK nur ein Teil des Werkzeugs ist. Zudem suchen wir nach einer Instanz, die dafür zuständig ist, die jeweilige Kontext-FK und Kontext-IAK eines Werkzeugs zu erzeugen und gegebenenfalls auch zu löschen. Lagern wir diese Zuständigkeit bei der Umgebung an, dann muß dort das Wissen vorhanden sein, daß

3


3.2


595

Werkzeuge aus Funktions- und Interaktionskomponenten bestehen und wie diese auf- und abgebaut werden. Diese Zusammenhänge sind für die Umgebung eigentlich nicht relevant, und eine Lösung wäre sinnvoll, bei der die Umgebung nur mit Werkzeugen als Ganzes arbeitet. Entwickle eine Klasse Werkzeug für jedes eigenständige Werkzeug. Übergib dieser Klasse die Aufgabe, die Kontext-FK und Kontext-IAK zu erzeugen, und lagere andere auf das Gesamtwerkzeug bezogene Aufgaben bei ihr an. Mache die Werkzeugklasse bei der Umgebung bekannt, so daß die Umgebung mit Hilfe dieser Werkzeugklasse ein Werkzeug erzeugen und initialisieren kann.

Lösung

Für das Lehrerkarten-Werkzeug, das bisher aus je einer Kontext-FK und Kontext-IAK sowie zwei Sub-FKs und Sub-IAKs bestand, läßt sich eine Klasse Lehrerkarten-Werkzeug entwickeln. Ein Objekt dieser Klasse umschließt das gesamte Lehrerkarten-Werkzeug.

3


3.2


596

Lehrerkarten-Werkzeug

Lehrerkarten-IAK

LK-Auflister-IAK

Lehrerkarten-FK

LK-Auflister-FK

LK-Editor-IAK

LK-Editor-FK

Abb. 3-46 Werkzeug-Objekt als Abschluß des LehrerkartenWerkzeugs (LK steht für Lehrerkarten)

3


3.2


597

Reaktionsmechanismus: Zuständigkeitskette Zusammenhang von Werkzeug und Material






fachliche Behälter

WerkzeugWerkzeugkomposition komposition Trennung von Handhabung und Präsentation Rückkopplung Kombi- und Rückkopplung EreignisMaterialzwischen Sub-Werkzeug zwischen Materialverwalter verwaltung koordinatorSub- und Kontext-IAK Sub- und Kontext-FK

Fachwerte

Umgebung

Werkzeugabschluß

Zuständigkeitskette

Wenn wir den Beobachtermechanismus zwischen Sub-FKs und ihrer Kontext-FK verwenden, stellen wir fest, daß es Nachrichten von einer

3


3.2


598

Sub-FK an ihre Kontext-FK gibt, die nicht auf einer Zustandsänderung der Sub-FK beruhen. Vielmehr signalisiert die Sub-FK, daß sie eine geforderte Dienstleistung nicht erfüllen kann. Um diese Nachrichten zu übermitteln, kann zwischen Sub-FK und Kontext-FK eine Zuständigkeitskette (Chain of Responsibility, s. [Gamma et al. 96]) aufgebaut werden, über die diese Nachrichten verschickt werden können. Eine Funktionskomponente erhält über ihre Interaktionskomponente eine Anforderung vom Benutzer, die sie nicht erfüllen kann und die deshalb auch zu keiner Zustandsänderung bei ihr führt. Die Funktionskomponente will diese Anforderung an ihren Kontext, der aus einer Kontext-FK oder einem Werkzeug-Objekt bestehen kann, weitergeben. Welcher Mechanismus soll dazu verwendet werden?

Problem

Werkzeuge haben wie Materialien einen Zustand. Dieser Zustand, das Werkzeuggedächtnis, ist in der Funktionskomponente des Werkzeugs angesiedelt. Eine Interaktionskomponente oder eine Kontext-FK können verändernde Operation der Funktionskomponente aufrufen und damit den Zustand des Werkzeugs verändern. Zustandsänderungen an der Funktionskomponente werden den beobachtenden Interaktionskomponenten und der Kontext-FK mit Hilfe eines Reaktionsmechanismus übermittelt.

Kontext

3


3.2


599

Es gibt aber auch Operationsaufrufe von der Interaktionskomponente an ihre Funktionskomponente, die dort nicht zu einer Zustandsänderung führen. Will ein Benutzer z.B. ein Werkzeug schließen, so wird auf seinen Knopfdruck hin die Interaktionskomponente bei ihrer Funktionskomponente z.B. die Operation schlie§en aufrufen. Die Funktionskomponente kann aber weder sich selbst noch ihre Interaktionskomponente beenden. Sie weiß auch nicht, ob der Kontext möglicherweise gegen das Schließen Einwände hat. Sie muß diese Aufgabe daher an ihren Kontext delegieren. Der Kontext kann, je nach Konstruktion, aus einer Kontext-FK, dem Werkzeug-Objekt oder der Umgebung bestehen. Wählt die Funktionskomponente einen Reaktionsmechanismus, um ihrem Kontext diese Anforderung zu übermitteln, so verstößt sie gegen einige Prinzipien eines Reaktionsmechanismus: ❑ Der Zustand der Funktionskomponente hat sich nicht geän-

dert. Trotzdem wird ein Ereignis verschickt. ❑ Ein Reaktionsmechanismus sollte nur zum Signalisieren ver-

wendet werden und nicht, um Leistungen – im Sinne eines Operationsaufrufs – vom Kontext anzufordern.

3


3.2


Verwende neben einem Reaktionsmechanismus eine Zuständigkeitskette (s. [Gamma et al. 96]), die die Funktionskomponenten in einen Werkzeugbaum einbindet. Über diese Zuständigkeitskette können Anforderungen (Request) verschickt werden. Entwirf eine Klasse Request, von der speziellere Request-Klassen abgeleitet werden können. So kann für den Vorgang des Schließens ein spezieller Request eingeführt werden.

600 Lösung

Da beim Lehrerkarten-Werkzeug die Sub-Werkzeuge in das KontextWerkzeug integriert sind, wird dieses Werkzeug nur als Ganzes zu schließen sein. Veranlaßt der Benutzer also eine Sub-IAK des Lehrerkarten-Werkzeugs die Schließen-Operation an ihrer Sub-FK aufzurufen, so wird diese Sub-FK einen Schließen-Request an ihre Kontext-FK verschicken. Diese gibt den Request weiter an das darüber sitzende Werkzeug-Objekt, das den Request weiter an die Umgebung schickt. Die Umgebung ist in der Lage, diese Anforderung auszuführen. Sie fordert das Werkzeug-Objekt auf, seine Sub-Komponenten zu schließen. Das Werkzeug-Objekt fordert wiederum seine Sub-Komponenten auf ihre Sub-Komponenten zu schließen. Auf diese Weise wird der Werkzeugbaum von unten nach oben abgebaut, d.h. die Umgebung, die über diese Aktion entscheiden kann, löst sie auch aus. Zum Schluß

3


3.2


601

löscht die Umgebung das Werkzeug-Objekt, d.h. ihre Referenz auf das Werkzeug-Objekt. Unabhängig von der Verwendung der Zuständigkeitskette wirft das Löschen von Objekten in einigen Programmiersprachen Probleme auf – besonders dann, wenn noch Operationsaufrufe an zu löschende Objekte auf dem Callstack liegen. Bei Sprachen wie C++, bei denen das Löschen von Objekten explizit erfolgen muß, entstehen dadurch Probleme mit dem Abarbeiten des Callstacks. Um zu vermeiden, daß der Callstack von Objekten abgebaut werden muß, die bereits gelöscht sind, bietet es sich an, ein Objekt in das System zu integrieren, das eine Art »Mülleimer«-Funktion aufweist. Soll ein Objekt gelöscht werden, so wird es in den Mülleimer gestellt. Der Callstack kann dann abgearbeitet werden, und auch Beobachter usw. können abgemeldet werden. Erst wenn der Mülleimer geleert wird, werden die in ihm enthaltenen Objekte tatsächlich aus dem System gelöscht. Das Leeren des Mülleimers siedeln wir vor der erneuten Abfrage der Ereignisschleife des Fenstersystems an, weil an dieser Stelle im Ablauf des Kontrollflusses davon ausgegangen werden kann, daß kein Objekt mehr aktiv ist. Bei einer Sprache wie Java, die über einen eigenen Garbage Collector verfügt, funktioniert das Löschen von Werkzeughierarchien auch

3

Löschen von Objekten


3.2


602

ohne einen Mülleimer problemlos. Der Garbage Collector von Java löscht nur dann Objekte, wenn sie von keinem Thread, der in der virtuellen Maschine läuft, mehr erreichbar sind. Diese Vorgabe schließt aus, daß Objekte abgeräumt werden, die auf dem Callstack noch referenziert werden.

3


3.2


603

3.2.6 Umgebung Zusammenhang von Werkzeug und Material





fachliche Behälter


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte


Umgebung Umgebung Materialkoordinator

Bei der Konstruktion von Werkzeugen haben wir gesagt, daß eine Funktionskomponente eines Werkzeugs Beobachter der Funktions-

3


3.2


604

komponenten ihrer Sub-Werkzeuge sein kann (vgl. Kapitel 3.2.5). Sie bildet damit den Kontext ihrer Sub-Werkzeuge. In einem anderen Konstruktionsansatz haben wir in ähnlicher Weise ein WerkzeugObjekt als Gesamtkontext eines Werkzeugs verwendet. Auf der nächsthöheren Ebene können wir nun die Arbeitsumgebung als Kontext aller in ihr enthaltenen Werkzeuge verstehen. Wenn die Umgebung den Kontext ihrer Werkzeuge darstellt, muß sie den fachlichen Zusammenhang aller in ihr enthaltenen Werkzeuge implementieren. Wir beschreiben hier den für die Einbettung von Werkzeugen in die Arbeitsumgebung notwendigen Einsatz eines Ereignisverwalters. Dann stellen wir das Konzept der Materialverwaltung vor, das die Kapselung unterschiedlicher »Datenquellen« und Persistenzmedien vor Umgebung, Werkzeugen und Automaten ermöglicht. In Kapitel 3.1.4 haben wir begründet, daß wir interaktive Anwendungssysteme heute nicht mehr nur als Einzelarbeitsplätze entwickeln. Vielmehr ist ein Austausch von Materialien zwischen verschiedenen Umgebungen notwendig und aus verschiedenen Umgebungen wird auch konkurrierend auf Materialien zugegriffen. Wir erläutern deshalb, wie die Materialverwaltung eingesetzt werden kann, um die Arbeit von mehreren Benutzern mit denselben Materialien zu koordinieren.

3


3.2


605

Ereignisverwalter Zusammenhang von Werkzeug und Material





fachliche Behälter


Werkzeugkomposition

Umgebung Umgebung

Fachwerte


Ereignisverwalter

Um Änderungen, die ein Werkzeug innerhalb einer Arbeitsumgebung an einem Material ausgelöst hat, unmittelbar sichtbar zu machen,

3


3.2


606

benutzen wir einen sogenannten Ereignisverwalter. Seine Aufgabe besteht darin, Änderungsmeldungen an alle Werkzeuge zu verteilen, die mit dem betroffenen Material arbeiten. Wird ein Werkzeug vom Ereignisverwalter über eine Materialänderung informiert, so kann es sein Material neu anzeigen und dem Benutzer Rückkopplung über die Veränderung geben. Der Zugriff auf dasselbe Material aus verschiedenen Arbeitsumgebungen wird auf S. 302ff. beschrieben. Wird innerhalb einer Arbeitsumgebung dasselbe Material von verschiedenen Werkzeugen benutzt, so sollen Änderungen am Material möglichst unmittelbar in allen Werkzeugen sichtbar werden.

Problem

Bei der Arbeit mit Handwerkszeug und Materialien ist es uns selbstverständlich, daß wir unmittelbare Rückkopplung über die Änderungen am Material durch den Gebrauch von Werkzeugen erhalten. Der Arbeitsfortschritt am Material ist sofort sichtbar. Die Arbeit erfolgt schließlich in derselben »Arbeitsumgebung«. Glätten wir beispielsweise die Kanten einer Delle im Kotflügel eines PKW mit einem Schwingschleifer, gehen wir selbstverständlich davon aus, daß die Kanten der Delle glatt sind, wenn wir anschließend die Delle mit einem Spatel und Füllspachtel zuspachteln. Auf den WAM-Ansatz übertragen sind die Werkzeuge innerhalb einer Arbeitsumgebung immer einem Benutzer zugeordnet. Eine

Kontext

3


3.2


607

wesentliche Aufgabe eines Werkzeugs ist es, »sein« Material darzustellen. Bei der Arbeit mit verschiedenen Werkzeugen an einem Material geht der Benutzer davon aus, daß Änderungen, die er mit einem Werkzeug vornimmt, augenblicklich auch in den anderen Werkzeugen sichtbar werden. Regele den simultanen Zugriff durch verschiedene Werkzeuge oder Automaten auf ein Material durch einen Reaktionsmechanismus. Delegiere diesen Mechanismus an einen Ereignisverwalter, der bei der Umgebung angesiedelt ist.

Lösung

Das Grundkonzept dieser Benachrichtigung haben wir in Kapitel 3.2.2 beschrieben. Da die Umgebung neben dieser Benachrichtigungsfunktion auch noch andere Aufgaben hat, wird das Verteilen der Ereignisse an die Werkzeuge in eine eigenständige Komponente ausgelagert. Wir ergänzen die Umgebung daher um einen Ereignisverwalter. Dort können sich Funktionskomponenten anmelden, wenn sie sich für bestimmte Materialänderungen interessieren. Im einzelnen bedeutet das: ❑ Jede Umgebung benutzt einen Ereignisverwalter und stellt ihn

auf Anfrage zur Verfügung. Werkzeuge einer Umgebung beobachten den Ereignisverwalter.

3


3.2


608

❑ Die Funktionskomponenten eines Werkzeugs tragen beim

Ereignisverwalter Ereignisse für diejenigen Materialien ein, von deren Änderung sie benachrichtigt werden wollen. ❑ Funktionskomponenten melden dem Ereignisverwalter, wenn

sie ihre Materialien verändert haben. Konstruktionsansätze

Wird ein Ereignis über eine Materialänderung von einer Werkzeug–FK ausgelöst, so wandert es den FK-Baum hoch, bis es zur obersten FK bzw. bis zum Werkzeug-Objekt (s. Kapitel 3.2.5) gelangt. Von dort wird das Ereignis an die Umgebung weitergeleitet. Die Umgebung gibt das Ereignis an den Ereignisverwalter weiter, und dieser benachrichtigt alle Werkzeuge (außer dem auslösenden), die sich für dieses Ereignis angemeldet haben. Eine andere Möglichkeit, die bei der RWG realisiert wurde, gibt dem Ereignisverwalter noch umfassendere Aufgaben. Der Ereignisverwalter erhält von jeder Funktionskomponente alle Ereignisse über eine Beobachtungsschnittstelle zugesandt, die die Funktionskomponenten an ihre Kontext-FK weitergeben wollen. Der Ereignisverwalter prüft das Ereignis und fragt die Funktionskomponenten nach ihrer KontextFK oder dem Werkzeug-Objekt. Daraufhin übergibt der Ereignisverwalter das Ereignis an die Kontext-FK zur Bearbeitung und fragt sie, ob die Bearbeitung erfolgt ist. Konnte die Kontext-FK das Ereignis

3


3.2


609

nicht bearbeiten, so läßt sich der Ereignisverwalter bei der Kontext-FK wiederum deren Kontext-FK geben. Dabei kann es sich auch um das Werkzeug-Objekt oder die Umgebung handeln. Auf diese Weise traversiert der Ereignisverwalter den Werkzeugbaum, bis er ein Objekt gefunden hat, das das Ereignis bearbeiten konnte. Ereignisse, die sich auf Materialänderungen beziehen, verschickt der Ereignisverwalter auf jeden Fall auch noch an alle anderen Werkzeuge, die sich für solche Materialänderungen angemeldet haben. Abb. 3-47 Umgebung

Zusammenhang von SubWerkzeugen, Werkzeugen, Umgebung und Ereignisverwalter

Kontext-FK

Kontext-FK

Sub-FK

Sub-FK

Ereignisverwalter

3


3.2


610

In Abbildung 3-47 ist die zweite Lösungsvariante dargestellt, bei der jedes Werkzeug, d.h. jede FK, dem Ereignisverwalter Ereignisse übergeben kann. Das Versenden von Ereignissen zwischen den verschiedenen Funktionskomponenten, der Umgebung und dem Ereignisverwalter ist mit gestrichelten Pfeilen dargestellt, weil die Funktionskomponenten dazu nur einen schmalen Ausschnitt der Schnittstelle des Ereignisverwalters benötigen. Der Ereignisverwalter kennt die verschiedenen Funktionskomponenten und die Umgebung auch nicht unter ihrer vollen Schnittstelle. So muß er lediglich Funktionskomponenten Ereignisse übergeben und nach der erfolgreichen Bearbeitung und nach der nächsthöheren Kontext-FK fragen können. Auch diese Benutzt-Beziehung ist nach dem Prinzip der losen Kopplung realisiert und wird deshalb durch einen gestrichelten Pfeil dargestellt. In unserem Beispiel hat der Benutzer sowohl das Pausenplaner-Werkzeug als auch den Lehrerkarten-Editor geöffnet und verändert im Lehrerkarten-Editor eine Lehrerkarte. Von dieser Änderung muß auch das Pausenplaner-Werkzeug informiert werden. Der Lehrerkarten-Editor als Werkzeug ist so konstruiert, daß er eine Änderung des Materials, auf dem er arbeitet, immer an seinen Kontext meldet, allerdings nichts davon weiß, ob und wer sich für diese Information interessiert. Beide

3


3.2


611

Werkzeuge sind wiederum so realisiert, daß sie sich beim Ereignisverwalter für das Ereignis registriert haben, das für die Änderung an den Lehrerkarten verschickt wird. FKLehrerEditor

Ereignisverwalter

FKPausenplaner

AnmeldenFuerEreignistyp(e)

Abb. 3-48 Eintrag in Liste vornehmen

Anmelden von FKs beim Ereignisverwalter und

AnmeldenFuerEreignistyp(e)

Verschicken von Ereignissen über den

Eintrag in Liste vornehmen

Ereignisverwalter

VersendeEreignis(e) MeldeEreignis(e) Reaktion auf das Ereignis

Benachrichtigung weiterer an diesem Ereignis interessierter FKs

3


3.2


612

Die Funktionskomponente des Lehrerkarten-Editors sendet, nachdem sie eine Lehrerkarte verändert hat, ein Ereignis aus, das die Information enthält, welches Material von welchem Werkzeug geändert wurde. Hat dieses Ereignis den Ereignisverwalter erreicht, so benachrichtigt der Ereignisverwalter das Pausenplaner-Werkzeug. Der Lehrerkarten-Editor selbst wird nicht benachrichtigt, weil der Ereignisverwalter feststellt, daß das Ereignis von ihm verschickt wurde. Das Pausenplaner-Werkzeug zeigt, sobald es das Ereignis erhält, die Lehrerkarten neu an, so daß die Änderung sofort sichtbar wird.

3


3.2


613

Materialverwaltung Zusammenhang von Werkzeug und Material





fachliche Behälter


Werkzeugkomposition

Umgebung Umgebung Ereignisverwalter

Fachwerte


Materialverwaltung

Neben der Koordination von Werkzeugen, die in einer Umgebung auf Materialien arbeiten, wird bei der Umgebung auch die Aufgabe angesiedelt, Materialien, die von Werkzeugen bearbeitet werden sollen,

3


3.2


614

von externen Persistenzmedien (s. Kapitel 4.2.3) zu beschaffen. Die entsprechende Komponente nennen wir Materialverwaltung. Werkzeuge und Automaten benötigen Materialien, auf denen sie arbeiten. Um den Ort und die Art der Speicherung von Materialien zu kapseln, muß eine geeignete Abstraktion eingeführt werden.

Problem

Materialien, die in einer Arbeitsumgebung benötigt werden, sind oft in verteilten und nicht-objektorientierten Medien oder Datenquellen gespeichert. Die Werkzeuge und Automaten sollen aber nicht direkt auf Datenbank- oder Dateisysteme zugreifen müssen, um dann die Materialien objektorientiert zu rekonstruieren. Ebenfalls wollen wir vermeiden, daß die Werkzeuge und Automaten Kenntnis darüber haben, in welchem konkreten Persistenzmedium sich ein bestimmtes Material befindet. Diese Aufgabe ist gut abgrenzbar und kann von der Umgebung übernommen werden.

Kontext

Konstruiere für jede Umgebung eine Materialverwaltung, die für die Werkzeuge und Automaten dieser Umgebung die benötigten Materialien bereitstellt. Nur die Materialverwaltung kennt den Ort und die Formate der entsprechenden Materialien außerhalb der Umgebung.

Lösung

3


3.2


615 Abb. 3-49

Umgebung

Entwurfskomponenten zur Materialversorgung

Werkzeug-FK

Materialverwalter

Materialversorger

Materialmagazin [verwaltbar]

Materialsammlung [verwaltbar]

Für die Materialverwaltung besitzt jede Umgebung: ❑ Einen Materialverwalter: Ein Materialverwalter ist ein Auto-

mat, der in jeder Umgebung existiert. Er bildet für die Werkzeuge in einer Umgebung die Komponente, bei der Materialien angefordert werden können. Materialanforderungen sind

3


3.2


616

möglich, wenn das jeweilige Material identifiziert ist. Identifikatoren für Materialien sind beispielsweise deren Name oder deren Typ. Hier können aber auch komplexe Ausdrücke einer Object Query Language verwendet werden. Der Materialverwalter verwaltet die Materialien in einem umgebungslokalen Materialmagazin. Der Materialverwalter wird den Werkzeugen und Automaten von der Umgebung bekanntgemacht. Das Ergebnis einer Anfrage an den Materialverwalter wird in Form einer Materialsammlung geliefert. Eine Materialsammlung ist ein Behälter, der genau die Materialien enthält, die die Anfrage erfüllen. In der Materialsammlung sind Materialien unter dem Aspekt verwaltbar bekannt. ❑ Ein Materialmagazin: Ein Materialmagazin ist ein Behälter, der

die Identifikationen aller in einer Umgebung verwalteten Materialien enthält. Dazu erhalten alle derartigen Materialien den Aspekt verwaltbar. Die Einführung des Materialmagazins verhindert, daß ein Materialverwalter dasselbe Material mehrfach von einem Materialversorger anfordert. ❑ Einen oder mehrere Materialversorger: Der Materialversorger

beschafft die Materialien aus Datenbanken oder anderen Persi-

3


3.2


617

stenzmedien. Er ist ein Automat, der die Transformation eines Materials von einer externen Repräsentation in eine interne Repräsentation (und umgekehrt) übernimmt (vgl. die Darstellung der Anbindung einer relationalen Datenbank in Kapitel 4.2.3). Dabei kann das Serialisierermuster verwendet werden (s. Kapitel 3.3.4). Über den Materialversorger lassen sich Materialien in konventionelle Systeme speichern oder mit ihnen austauschen. Der Materialversorger kennt als einzige Komponente der Umgebung die konkreten Schnittstellen zu den externen Systemen. Da eine Umgebung von mehreren externen Datenquellen mit Material versorgt werden kann, jeder Materialversorger aber nur ein Transformationsprotokoll implementiert, können dem Materialverwalter mehrere Materialversorger zugeordnet werden. Materialversorger haben eine Schnittstelle, über die ein Materialverwalter den Typ der bereitgestellten Materialien abfragen kann. Abbildung 3-49 veranschaulicht die Zusammenhänge zwischen den bisher besprochenen Entwurfskomponenten. Beim Start einer Umgebung wird ein Materialverwalter erzeugt. Diesem Materialverwalter werden die entsprechenden Materialversorger von der Umgebung zugeordnet. Im weiteren Ablauf greift die Umgebung nicht mehr auf die Materialversorger zu.

3


3.2


618

Den Werkzeugen einer Umgebung (in Abbildung 3-49 als WerkzeugÐFK dargestellt) wird jeweils bei ihrer Erzeugung der Materialverwalter bekanntgemacht. Die Werkzeuge fordern Material beim Materialverwalter an. Daß ein Material in der Umgebung existiert, wird vom Materialverwalter im Materialmagazin festgehalten. Materialien werden zwischen Materialverwalter und Materialversorger über eine Materialsammlung ausgetauscht. Sowohl dem Materialverwalter als auch dem Materialversorger sind Materialien nur unter dem Aspekt verwaltbar bekannt. Funktionskomponenten, die ein Material angefordert haben, führen eine Typkonversion (z.B. mittels eines Downcast s. Kapitel 2.1.15) auf dem verwaltbaren Material durch, um das Material unter dem Aspekt bearbeiten zu können, der für das Werkzeug definiert wurde (s. Kapitel 3.2.1).

3


3.2


619

Materialkoordinator Zusammenhang von Werkzeug und Material





fachliche Behälter


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte


Umgebung Umgebung Materialkoordinator

Werden Materialien zentral gelagert und in verschiedenen Arbeitsumgebungen verwendet, dann muß der konkurrierende Zugriff auf Materialien aus verschiedenen Arbeitsumgebungen geregelt werden. Dazu dient ein Materialkoordinator.

3


3.2


620

Der Zugriff verschiedener Benutzer auf gemeinsame Materialien soll so geregelt werden, daß Materialien weiterhin ihren Ort behalten und somit nicht gleichzeitig in zwei Umgebungen vorhanden sein und bearbeitet werden können.

Problem

Es gibt Materialien, die lokal an einem Arbeitsplatz existieren. Andere Materialien finden wir an allgemein zugänglichen Orten in unserer Arbeitsumgebung. Der Umgang mit den lokalen Materialien ist unter dem Gesichtspunkt des gleichzeitigen Zugriffs unkritisch und wird, wie auf S. 295ff. beschrieben, über den Ereignisverwalter koordiniert. Anders sieht es bei den Materialien aus, die von verschiedenen Arbeitsumgebungen gleichzeitig zugreifbar sein müssen, d.h., um die mehrere Benutzer konkurrieren (s. Kapitel 4.1). Materialien sollen im gesamten Anwendungssystem ihren gegenständlichen Charakter behalten. Wir modellieren sie so, daß sich ein Material immer nur an einem Ort befinden und an einem Ort bearbeitet werden kann. Daraus folgt, daß es von verschiedenen Arbeitsumgebungen aus keinen simultanen Zugriff auf Materialien geben darf. Das bedeutet jedoch nicht, daß wir einen konkurrierenden Zugriff auf Materialien ausschließen. Konkurrierend bedeutet hier, daß ein Material von einem Benutzer angefordert wird, obwohl es bereits an

Kontext

3


3.2


621

einem anderen Arbeitsplatz bearbeitet wird. Wir wollen diese fachliche Anwendungssituation explizit machen. Realisiere konkurrierende Zugriffe auf ein Material über das Konzept von Original und Kopie. Konstruktiv ist dafür der Materialkoordinator zuständig. Zur Lösung der Probleme des konkurrierenden Zugriffs hat sich in der Praxis das Konzept von Original und Kopie von Materialien bewährt (s. Kapitel 4.1.1). Für die technische Realisierung bedeutet dieses Konzept, daß in einem nach dem WAM-Ansatz entwickelten Anwendungssystem eine Instanz dafür sorgt, daß bei einem konkurrierenden Zugriff der zweite Zugreifende lediglich eine Kopie erhält. Das Original ist nur erhältlich, wenn kein anderer Benutzer dieses Original angefordert hat. Um das Konzept von Original und Kopie zu realisieren, erweitern wir die Materialversorgung. Zur Abstimmung konkurrierender Zugriffe auf Materialien setzen wir einen Materialkoordinator ein. Ein Materialkoordinator ist ein zentraler Automat, der unter Verwendung eines lokalen Behälters die in den verschiedenen Arbeitsumgebungen enthaltenen Materialien verwaltet. Der Materialkoordinator wird in einer Administrationsumgebung erzeugt. Eine Administrationsumgebung ist eine ausgezeichnete

3

Lösung


3.2


622

Arbeitsumgebung. Sie stellt Dienstleistungen zur Verfügung, wie z.B. den Materialkoordinator, die in anderen Arbeitsumgebungen verwendet werden können. Bei der Erzeugung der anderen Arbeitsumgebungen erhält jede – neben dem Materialverwalter und den Materialversorgern – ein Materialkoordinator-Proxy. Die zentrale Aufgabe des Materialkoordinators ist die Koordination konkurrierender Materialzugriffe. Dazu registriert der Materialkoordinator, welche Arbeitsumgebung welches Material mit welchem Status (als Original oder als Kopie) enthält. Materialien werden einem Werkzeug auf Anforderung nach folgendem Schema zugeordnet: ❑ Ein Werkzeug fordert über eine Materialidentifikation Mate-

rial beim zugeordneten Materialverwalter an. ❑ Der Materialverwalter benutzt seinen lokalen Materialkoordi-

nator (d.h. das Proxy des zentralen Materialkoordinators), um festzustellen, ob das Material bereits in einer anderen Arbeitsumgebung enthalten ist. Wird das Material bereits in einer anderen Arbeitsumgebung benutzt, wird in Abhängigkeit von der Kopierbarkeit des Materials der anfragende Materialverwalter entsprechend unterrichtet.

3


3.2


623

❑ Findet ein Erstzugriff auf das Material statt, wird der anfra-

gende Materialverwalter als Halter des Originals registriert. Ist eine Kopie erforderlich und möglich, wird die Existenz der Kopie in der anfragenden Umgebung registriert. (Dieses Schema gilt entsprechend, wenn weitere Anfragen für dasselbe Material gestellt werden.) Abb. 3-50 Umgebung

Materialversorgung mit Materialkoordinator–Proxy

Ereignisverwalter

Werkzeug-FK

Materialverwalter

Materialkoordinator-Proxy

Materialversorger

Materialmagazin [verwaltbar]

Materialsammlung [verwaltbar]

3


3.2


624

Abbildung 3-50 zeigt den schematischen Zusammenhang zwischen den Entwurfskomponenten. Dabei ist gegenüber der Materialversorgung aus Abbildung 3-49 das Materialkoordinator-Proxy Bestandteil der Arbeitsumgebung. Materialverwalter und MaterialkoordinatorÐProxy sind über einen Reaktionsmechanismus verbunden. Wir haben einen Reaktionsmechanismus (im Bild wieder durch gestrichelte Pfeile dargestellt) gewählt damit das MaterialkoordinatorÐ Proxy signalisieren kann, daß sich ein Material in einer anderen Arbeitsumgebung verändert hat. Der Ereignisverwalter ist ebenfalls über einen Reaktionsmechanismus mit dem Materialverwalter verbunden. Der Materialverwalter informiert den Ereignisverwalter, wenn er vom Materialkoordinator-Proxy über eine Materialveränderung benachrichtigt worden ist. Die Nachricht des Materialkoordinators wird nur dann an den Materialverwalter verschickt, wenn in der Umgebung des Materialverwalters ein Werkzeug existiert, das ein gerade verändertes Material als Kopie angefordert hat. Hat sich das Werkzeug, das diese Kopie bearbeitet, beim Ereignisverwalter für Änderungsereignisse angemeldet, so informiert der Ereignisverwalter das Werkzeug über diese Änderung. Das Werkzeug kann jetzt dem Benutzer mitteilen, daß das Original geändert wurde. Der Benutzer hat daraufhin die Möglichkeit, sein Material zu aktualisieren.

3


3.2


625

Fachlich ist es auch denkbar, daß das Werkzeug auf einer Kopie arbeitet und nicht an Veränderungen des Originals interessiert ist.

3.2.7 Fachliche und technische Behälter Behälter dienen der Aufnahme von Objekten. Bei der Modellierung nach dem WAM-Ansatz unterscheiden wir zwei Arten von Behältern: fachliche und technische Behälter. Fachliche Behälter werden anhand von existierenden Behältern (z.B. Ordner) entworfen, die wir bei der Analyse des Anwendungsbereichs vorfinden (s. Kapitel 2.2.3 und 3.1.5). Technische Behälter dagegen entsprechen elementaren Datenstrukturen, wie Listen, Arrays oder komplexeren technischen Strukturen, wie WeakArray in Smalltalk, und werden meist dazu verwendet, fachliche Behälter zu implementieren. Fachliche und technische Behälter unterscheiden sich nicht nur in ihrer Modellierung, sondern auch in der Konstruktion erheblich. Für fachliche Behälter können nur begrenzt Aussagen über die Konstruktion gemacht werden, weil die Schnittstelle einer fachlichen Behälterklasse wesentlich durch die fachlichen Umgangsformen mit diesem Behälter bestimmt wird. Technische Behälter, also etwa sortierte und unsortierte Listen, Schlangen oder Mengen, sind dem Entwickler soft-

3


3.2


626

waretechnisch vertraut, denn mit diesen Behältern hat er in der Programmierung ständig zu tun. Im folgenden stellen wir Konstruktionsansätze für fachliche Behälter vor. Wir erläutern auch unsere Sichtweise von technischen Behältern und beschreiben verschiedene Implementierungsmöglichkeiten.

3


3.2


627

Fachliche Behälter Zusammenhang von Werkzeug und Material





fachliche fachliche Behälter Behälter


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte


Umgebung

Materialkoordinator

Wir wollen fachliche Behälter als eine besondere Art von Materialien modellieren, die anderen Materialien einen Ort geben, sie aufbewahren und ein Ordnungsprinzip für die Materialien festlegen.

3

Problem


3.2


628

Während in der Literatur und in Klassenbibliotheken technische Behälter modelliert und realisiert werden, ist weitgehend unklar, was fachliche Behälter sind und wie sie entworfen werden. Bei der Analyse von Anwendungsbereichen stellen wir immer wieder fest, daß Sammlungen und Ordnungen von Materialien große Bedeutung zukommt. Bei der Umsetzung von anwendungsfachlich bereits vorhandenen Behälterkonzepten in das Modell des Anwendungssystems können wir allerdings verstärkt die Möglichkeiten von interaktiven Softwarekomponenten nutzen.

Kontext

Konstruiere einen fachlichen Behälter als eigenen fachlichen Gegenstand, der zwar Materialcharakter hat, aber durchaus eigene Umgangsformen aufweist. Diese Umgangsformen können die Fähigkeiten von Softwarekomponenten ausnutzen. Größere fachliche Behälter sollten z.B. eigenständig ein Inhaltsverzeichnis führen. Fachliche Behälter können auch einen Persistenzmechanismus kapseln. Realisiere fachliche Behälter durch technische Behälter, aber leite sie nicht als Spezialisierung von ihnen ab. Zu den elementaren Umgangsformen mit fachlichen Behältern zählt, daß wir eine Menge von Materialien aufbewahren, bearbeiten und auf Elemente dieser Menge zugreifen können.

Lösung

3


3.2


629

Behälter sind Materialien und Materialien können Materialien enthalten. Daher können wir in einen Behälter auch andere Behälter einfügen und so den Behälterinhalt strukturieren. Fachliche Behälter haben eine Identität und meist einen benutzerdefinierten Namen. Sie sind aktiv in dem Sinne, daß sie ein eigenes »Navigationsmodell« besitzen, d.h. eine bestimmte Art und Weise, wie wir von einem Element zum nächsten gelangen können. Sie verwalten ihre Elemente im Innern selbst. Diese Umgangsformen lassen sich allgemein an fachlichen Behältern modellieren. Darüber hinaus hat sich bei der Konstruktion von fachlichen Behältern gezeigt, daß es bestimmte Umgangsformen gibt, die an den vorhandenen Behältern der Anwendungswelt aufgrund von physikalischen Beschränkungen nicht zu finden sind. Sie lassen sich aber gut an einem fachlichen Behälter ansiedeln. Ein fachlicher Behälter läßt sich als eine Zusammenfassung von Materialien zu einer Menge verstehen. Oft soll eine fachliche Handlung oder Operation nicht nur an einem einzelnen Element, sondern an der Gesamtmenge der Materialien ausgeführt werden. Dies läßt sich gut am Behälter modellieren. Der Behälter erhält dadurch eine Umgangsform, die fachlich motiviert ist, aber an konventionellen Behältern so nicht möglich ist.

3


3.2


630

Im Pausenplanbeispiel könnten wir am fachlichen Behälter Lehrkšrper die Gesamtstundenzahl der Lehrer verwalten. Der Behälter Lehrkšrper kann dann Auskunft über die Gesamtstundenzahl geben. Er berechnet die Gesamtstundenzahl neu, wenn sich die Stundenzahl eines enthaltenen Lehrers geändert hat. Konstruktionsansatz: Inhaltsverzeichnis

Wenn wir in einem Anwendungsbereich mit großen Sammlungen arbeiten, stellen wir fest, daß wir uns diese Sammlungen über Verzeichnisse zugänglich machen. Inhaltsverzeichnisse führen wir meist als ein eigenes Material, das getrennt von der Sammlung existiert. Vom fachlichen Standpunkt aus läßt sich daher argumentieren, Inhaltsverzeichnisse in der Konstruktion als eigenständige Komponenten aufzufassen. Auch aus technischer Sicht läßt sich die Trennung von Inhaltsverzeichnis und Sammlung begründen. Behälter enthalten meist große Mengen von komplexen Materialien. Aus Effizienzgründen müssen wir deshalb technisch oft darauf verzichten, alle Materialien, die in Behältern verwaltet werden, in den Hauptspeicher zu laden. Um dem Benutzer diesen Zusammenhang deutlich zu machen, verwenden wir das Konzept des eigenständigen Inhaltsverzeichnisses. Das Inhaltsverzeichnis bietet dem Benutzer eine

3


3.2


631

Übersicht über die Materialien (Behälterelemente), die im jeweiligen Behälter zugreifbar sind. Wenn das Inhaltsverzeichnis als Gegenstand für den Benutzer greifbar ist, vermeiden wir den Eindruck, der Benutzer könnte auf die Elemente des Behälters direkt zugreifen. Außerdem wird für den Benutzer deutlich, daß die Behälterelemente nicht ohne Verzögerung verfügbar sind. Das Inhaltsverzeichnis eröffnet dem Benutzer einen strukturierten Zugang zum Inhalt des Behälters. Jeder Behälter ist in der Lage, auf Anforderung ein Inhaltsverzeichnis zu erstellen, das eine festgelegte Menge von Informationen über die Behälterelemente enthält. Um Behälterelemente aufzulisten, wird nur ein kleiner Teil der Informationen eines Behälterelements benötigt. Meist wird die Bezeichnung und ein weiteres Attribut, oft ein Fachwert (s. Kapitel 3.2.8), angezeigt. Wird ein Behälterelement über das Inhaltsverzeichnis zur Bearbeitung ausgewählt, so wird das Element zu diesem Zeitpunkt vollständig geladen oder instanziiert (vgl. den folgenden Abschnitt). Betrachten wir den Lehrkörper als Beispiel für einen fachlichen Behälter, so könnte das Inhaltsverzeichnis die Namen der Lehrer und ihre Kürzel enthalten. Erst auf Anforderung liefert der Behälter die ganze Lehrerkarte.

3


3.2


632

Konstruktionsansatz: Nachladen von Materialien

Sollen die Materialien nicht alle im Hauptspeicher vorgehalten werden, so ist die Frage, welche Komponente dafür verantwortlich ist, das Material auf Bedarf nachzuladen. Bisher sind im Rahmen des WAMAnsatzes zwei Strategien umgesetzt worden. Eine Möglichkeit besteht darin, dem Behälter das Nachladen der Materialien zu übertragen. Mit Hilfe der im Inhaltsverzeichnis vermerkten identifizierenden Fachwerte (s. Kapitel 3.2.8) kann sich der Behälter an einen Datenbankautomaten (s. Kapitel 4.2.3) wenden und das Material dort anfordern. Wird dieser Konstruktionsansatz gewählt, so muß der Behälter die Schnittstelle der Datenbankautomaten kennen, und es muß festgelegt sein, bis zu welcher Tiefe das Material nachgeladen wird. Die Materialien in einem Behälter können aus komplexen Strukturen von Submaterialien bestehen, die verhältnismäßig viel Speicherplatz und Ladezeit beanspruchen. Da beim Laden meist nicht klar ist, welche Teile des Materials der Benutzer bearbeiten möchte, muß hier das gesamte Material geladen werden. Die zweite Möglichkeit verbirgt das Nachladen vor dem Behälter und dem Inhaltsverzeichnis. Bei dieser Variante befindet sich hinter jedem Verweis, der ein Material-Objekt referenziert, ein Proxy-Objekt als Platzhalter. Dieses Proxy-Objekt verhält sich wie eine Smart-Refe-

3

Behälter lädt nach

Proxy-Objekte


3.2


633

rence (s. [Gamma et al. 96]). Wenn dieses Proxy-Objekt dereferenziert wird, lädt es das Material-Objekt in den Speicher. Auch dieses Material-Objekt kann über eine Reihe von Verweisen auf Proxy-Objekte verfügen, so daß auch die tieferen Ebenen des Materials nur bei Bedarf nachgeladen werden müssen. Konstruktionsansatz: Änderungen am Behälterinhalt

Läßt sich ein Benutzer das Inhaltsverzeichnis eines Behälters anzeigen und arbeitet er zur selben Zeit mit einem Werkzeug auf einem Behälterelement, so kann es passieren, daß der Benutzer das Material so verändert, daß sich diese Änderung auf das Inhaltsverzeichnis auswirkt. Eine einfache Lösung für dieses Änderungsproblem können wir aus den Metaphern Material und Behälter ableiten: Zur Veränderung muß ein Material aus seinem Behälter entfernt werden. Im Inhaltsverzeichnis wird dieses Material dann als entnommen gekennzeichnet. Der Entnahmevorgang des Materials bedeutet eine Veränderung des Behälters durch ein Werkzeug. Dieses Werkzeug benachrichtigt über die Umgebung (s. Kapitel 3.2.6) alle auf diesem Behälter arbeitenden Werkzeuge. Die benachrichtigten Werkzeuge können selbst entscheiden, ob sie ihre Darstellung des Behälters erneuern müssen oder nicht. Wird das aus dem Behälter entfernte Material von einem Werkzeug

3


3.2


634

verändert, so werden nur die Werkzeuge verständigt, die sich für Änderungen an dem speziellen Material interessieren. Erst wenn das Werkzeug das Material wieder an den Behälter zurückgibt, wird die Veränderung auch für den Behälter wirksam und eine entsprechende Benachrichtigung wird verschickt. Eine Lehrerkarte wird aus dem Behälter Lehrkšrper herausgenommen. Der Name auf der Karte wird verändert, da die Lehrperson geheiratet und dabei ihren Namen geändert hat. Anschließend wird die Karte in den Behälter zurückgegeben, der sein Inhaltsverzeichnis aktualisiert. Bei der Entnahme durch das Lehrerkarten-Werkzeug werden alle Werkzeuge (z.B. der Pausenplaner) informiert, die auf Lehrkšrper arbeiten. Bei der Korrektur der Lehrerkarte erhält das Pausenplaner-Werkzeug nur dann eine Nachricht, wenn es gerade diese Lehrerkarte anzeigt und sich für Änderungen dieses Materials angemeldet hat. Erst wenn die Karte in den Behälter zurückgegeben wird, erhalten wieder alle Werkzeuge, die auf Lehrkšrper arbeiten, eine entsprechende Information und können das geänderte Inhaltsverzeichnis darstellen.

3


3.2


635

Alternative Ansätze

Eine mögliche Lösungsalternative wäre, das Inhaltsverzeichnis über einen Beobachtermechanismus (s. Kapitel 3.2.3) an das Material anzuschließen. In den Konstruktionen nach dem WAM-Ansatz wird ein Reaktionsmechanismus bisher nur zwischen den interaktiven Komponenten, d.h. zwischen Werkzeugen, Automaten und der Umgebung, eingesetzt. Materialien werden als Komponenten betrachtet, die frei von interaktiven Charakteristika auf ihre fachliche Funktionalität beschränkt sind. Der Grund für dieses Konstruktionsprinzip liegt einerseits in der Metapher des Materials begründet. Materialien befinden sich an einem Ort und sind dort verfügbar. Sie wenden sich nicht von sich aus an ihren Kontext, wenn sie verändert worden sind. Andererseits hat sich auch bei der technischen Umsetzung als sinnvoll erwiesen, Materialien von dem Wissen über Arbeitszusammenhänge freizuhalten. Ein Material soll nicht wissen, ob seine Änderung für andere Komponenten relevant ist. Schließlich müßte entschieden werden, ob die Änderung nur für die direkt auf einem Material arbeitenden Werkzeuge relevant sind oder auch für die Werkzeuge, die auf dem entsprechenden Behälter arbeiten. Die Verallgemeinerung des Beobachtermechanismus führt schließlich dazu, daß auch alle Materialien informiert

3


3.2


636

werden, die in einer Benutzt-Beziehung zu einem veränderten Material stehen. Auf diese Weise entsteht eine unüberschaubare Kaskade von Benachrichtigungen, die die gesamte Konstruktion verkompliziert. Gleichzeitig haben wir damit einen Mechanismus generalisiert, der nur für interaktive Anwendungen relevant ist. Schon bei der Aufteilung in Client- und Server-Systeme ist dies nicht sinnvoll. Deshalb schließen wir diese Lösung generell für Materialien in Behältern aus. Komplizierter wird die Sache, wenn wir komplexe zusammengesetzte Materialien haben, deren Teile fachliche Querbezüge enthalten, aber einzeln in Werkzeugen bearbeitet werden können. Dann kann der Behälter die fachliche Konsistenz des zusammengesetzten Materials sicherstellen. Die Änderungen an einer Materialkomponente sollen aber unmittelbar Auswirkungen auf andere Teile haben, auch wenn diese derzeit nicht von einem Werkzeug bearbeitet werden. In diesem Fall geht kein einfacher Weg an einem Beobachtermechanismus vorbei. Wir dürfen aber nicht übersehen, daß wir dabei das Behälterkonzept schon sehr ausgeweitet haben. Der Behälter verwaltet die Konsistenz von Materialien, die entweder »in ihm« oder »außerhalb« verändert werden. Aber auch dann sollte das Inhaltsverzeichnis nicht in die Benachrichtigung mit einbezogen werden, sondern die einzelnen Materialkomponenten sollten über den Behälter koordiniert werden, der seinerseits das Inhaltsverzeichnis aktualisiert.

3


3.2


637

Technische Behälter Zusammenhang von Werkzeug und Material





fachliche Behälter

technische technische Behälter Behälter

Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte


Umgebung

Materialkoordinator

Technische Behälter werden im Rahmen des WAM-Ansatzes als Abstraktionen von üblichen Datenstrukturen verstanden. Sie entstammen zwar einer softwaretechnischen Sicht auf Datenstrukturen, aber wir versuchen, sie anhand der Umgangsformen mit Datenstrukturen zu modellieren und zu klassifizieren.

3


3.2


IntOrdTable Zugriffsmethode?

Table

OrdTable Ordnung?

UOrdTable

638

SortedTable

Art der Ordnung?

ExtOrdTable

AssocList

Dictionary

Stack

Container

Queue

DQueue Bag

Array

Duplikate?

UOrdCol Set Collection

Ordnung?

IntOrdCol

SList

ExtOrdCol

List

OrdCol

Art der Ordnung?

Abb. 3-51

In [Traub 95] wird eine Klassifikation für technische Behälter vorgeschlagen, die sich rein an dem Umgang mit den einzelnen Behältern orientiert (s. Abbildung 3-51).

3

Klassenbaum der Behälterbibliothek ConLib (nach [Traub95])


3.2


639

Die erste Ebene der Klassifikation orientiert sich an der Art des Zugriffs auf die Behälterelemente. Hier können fünf verschiedene Arten des Zugriffs identifiziert und entsprechenden Klassen zugeordnet werden: wahlfreier Zugriff (Collection), indizierter Zugriff (Array), Zugriff über Schlüssel (Table) und eingeschränkter Zugriff in zwei verschiedenen Varianten (Stack und Queue). Auf der nächsten Stufe der Vererbungshierarchie werden die Behälterklassen danach unterschieden, ob sie eine Ordnung besitzen (OrdCol, OrdTable) oder ob die Elemente ungeordnet in dem Behälter verwahrt werden (UOrdCol, UOrdTable). Auf der letzten Stufe werden schließlich Behälter mit extern bestimmter Ordnung (ExtOrdCol, ExtOrdTable) und mit intern bestimmter Ordnung (IntOrdCol, IntOrdTable) gegeneinander abgegrenzt. Ein Behälter mit extern bestimmter Ordnung erlaubt das freie Einfügen und Entfernen von Elementen, während ein Behälter mit intern bestimmter Ordnung dies nicht zuläßt. Die konkreten Klassen in Abbildung 3-51 sind durch doppelte Umrahmung deutlich gemacht (z.B. SList, List etc.). Im Vergleich zu anderen Behälterbibliotheken, wie den SmalltalkCollectionClasses und den Behälterbibliotheken der MFC oder ET++, wird bei dieser Art der Klassifikation an keiner Stelle Implementationsvererbung verwendet. In den Smalltalk-CollectionClasses erbt z.B. SortedCollection von der OrderedCollection. In der

3


3.2


640

OrderedCollection gibt es eine Methode at:put: die in der SortedCollection durch eine Fehlermeldung überschrieben ist. An dieser Stelle wurde also Implementationsvererbung eingesetzt, um eine sortierte Liste auf der Basis der Implementation einer geordneten Liste zu implementieren. In der in [Traub 95] beschriebenen (und implementierten) ConLib stehen diese beiden Listentypen nebeneinander. Sie werden als geordnete Listen betrachtet, die aber eine unterschiedliche Art der Ordnung besitzen. Ähnlich wird in der ET++ strukturiert, bei der eine SortedObjList von einer ObjList erbt und Operationen zum Einfügen von Elementen an einer bestimmten Position nicht unterstützt. In der ConLib sind darüber hinaus eine Reihe von Abstraktionen eingeführt worden, die den Umgang mit verschiedenen konkreten Behältern unter einer gemeinsamen Schnittstelle erlauben. Eine sortierte Liste (SList) kann unter der Schnittstelle eines geordneten Behälters (OrdCol) auf die gleiche Art und Weise verwendet werden wie eine normale Liste (List), deren Ordnung allein durch das Einfügen und Entnehmen von Elementen entsteht. In anderen Behälterbibliotheken sind diese Formen der Abstraktion meist nicht sehr stark ausgeprägt. Die konkrete Implementierung der Behälterbibliothek aus [Traub 95] macht Gebrauch von einer Reihe von Entwurfsmustern. Das Brückenmuster wird eingesetzt, um verschiedene Implementationsvarianten mit den Behälterklassen in der Vererbungshierarchie aus Abbildung 3-51 zu verbinden. So gibt es z.B. für eine sortierte Liste 3


3.2


641

eine Array-basierte, eine auf einer Linked List aufbauende und eine als AVL-Baum realisierte Implementationsvariante. Um Behälterklassen mit unterschiedlichen Mechanismen für den Vergleich von Elementen auszurüsten, wird das Strategiemuster verwendet. Konstruktionsansatz: Cursor

In allen Behälterbibliotheken finden wir Iteratoren, die den Zugriff auf die einzelnen Elemente und das Weiterrücken von einem Element zum nächsten umsetzen. Das Konzept des Iterators stammt aus der funktionalen Welt, in der eine Funktion auf alle Elemente eines Behälters anwendbar sein sollte. Neben den Iteratoren wird im WAM-Kontext das Konzept des Cursors verwendet. Ein Cursor ist vergleichbar mit einer Positionsmarke oder einem Lesezeichen. Mit dem Modell des Cursors trennen wir uns von der funktionalen Sichtweise des Iterators und realisieren ein objektorientiertes Konzept: Wir navigieren mit einer Positionsmarke auf einem Behälter. Als Objekt hat ein Cursor einen Zustand, ein wohldefiniertes Verhalten und eine eindeutige Identität. Der Zustand eines Cursors wird durch seine Position in der Elementmenge eines Behälters bestimmt. Abbildung 3-52 stellt in einem Statechart (s. [Harel 87]) das Zustandsmodell des Cursors nach [Traub 95] dar.

3


3.2


642

Die Cursor nach [Traub 95] sind als Marken realisiert, die jeweils auf einem Behälterelement positioniert sind. Der Cursor referenziert immer genau ein Element, oder er befindet sich am linken bzw. am rechten Rand der Elementmenge. Alternativ könnte der Cursor jeweils zwischen den Elementen stehen. Die Positionierung zwischen den Elementen setzen wir nicht ein, weil sie nach unserer Erfahrung für Anwendungsentwickler nicht intuitiv verständlich ist. Eine Marke auf den Elementen zu positionieren, erscheint als die »natürlichere« Variante. Ein Beispiel soll diese Einschätzung verdeutlichen. Eine typische Umgangsform mit Ordnern und den darin abgelegten Dokumenten ist das Anheften von Notizzetteln an Dokumenten. Er wäre relativ umständlich, die Notizen zwischen zwei Dokumente zu heften und auf die Notiz zu schreiben, ob das rechte oder das linke Dokument gemeint ist. Cursor, die zwischen Elementen positioniert sind, zeigen zudem folgendes Problem: Ein Element, das wir in einem Suchvorgang mit dem Cursor gefunden und markiert haben (der Cursor steht z.B. links neben dem Element), soll über einen anderen Cursor gelöscht werden. Greifen wir jetzt über den ersten Cursor auf das links vermutete Element zu, so werden wir nur den Nachfolger und nicht mehr das markierte Element vorfinden. Um Verwirrung zu verhindern, müßten wir eine Benachrichtigung des Benutzers einbauen.

3


3.2


643

Im Rahmen des WAM-Ansatzes haben wir uns für Cursor entschieden, die auf Elementen positioniert sind. Das Problem des Löschens beseitigen wir durch ein Zustandsmodell (s. Abbildung 3-52): Abb. 3-52 Logged

Zustandsmodell des Cursors (nach [Traub95])

Valid Back(Empty), GoOffLeft Forth(Empty), GoOffRight

Erzeugen

Forth(~Empty)

Unlogged

Login

OffLeft

Inside Back(First), GoOffLeft

Forth(Last), GoOffRight

OffRight

Back(~Empty)

Logout, Behälter gelöscht

Back(First), GoOffLeft

Entfernen (Current)

Forth(~Last), Back(~First)

Forth(Last), GoOffRight

Invalid

An einem Cursor-Objekt läßt sich mit Hilfe von sondierenden Operationen der jeweilige Zustand des Cursors erfragen. Wir unterscheiden

3


3.2


644

zwei grundsätzliche Zustände: Logged und Unlogged. Diese Zustände machen deutlich, ob ein Cursor bei einem Behälter angemeldet ist oder nicht. Im eingeloggten Zustand kann ein Cursor entweder gültig (Valid) oder ungültig (Invalid) sein. Ist ein Cursor gültig, so steht er entweder auf dem linken oder rechten Rand (OffLeft, OffRight), der die Elementmenge begrenzt, oder er befindet sich innerhalb der Elementmenge (Inside). Der Zustand ungültig ist notwendig, um ein sauberes Modell für das Löschen von Elementen vorzusehen, auch dann, wenn ein Cursor auf dem gelöschten Element steht. Wird das Element, auf dem der Cursor steht, gelöscht, so ändert sich der Cursor-Zustand von gültig nach ungültig. Abhängig vom Cursor-Zustand lassen sich nur die zulässigen verändernden Operationen aufrufen, die den Cursor in einen möglichen Folgezustand überführen. Im Statechart von Abbildung 3-52 sind die verändernden Operationen an den Pfeilen notiert, die von einem Zustand zum nächsten führen. Einige Zustandsübergänge sind nur möglich, wenn eine Bedingung gilt. In Abbildung 3-52 sind die jeweiligen Bedingungen in Klammern angegeben. Operationsaufrufe, die einen Zustand auf sich selbst abbilden, also den Cursor-Zustand nicht verändern, sind in Abbildung 3-52 nicht dargestellt. Dieser Entwurf macht die verschiedenen Möglichkeiten, mit einem Cursor zu arbeiten und dabei ungültige oder besondere

3


3.2


645

Zustände zu erkennen, explizit. Der Anwendungsentwickler kann eine nicht zulässige Verwendung des Cursor vermeiden, indem er vor einer Veränderung des Cursors dessen Zustand überprüft. Diskussion fachliche und technische Behälter

Steht den Anwendungsentwicklern eine Behälterbibliothek zur Verfügung, so stellt sich die Frage, auf welche Weise die fachlichen Behälter mit den technischen Behältern in Zusammenhang gebracht werden sollen. Sollen fachliche Behälter von den technischen Behältern erben oder sollen sie sie benutzen? Aus der in diesem Handbuch geführten Diskussion sollte deutlich geworden sein, daß die Vererbungsbeziehung bei der fachlichen Modellierung nur dann eingesetzt wird, wenn die beiden zu verbindenden Klassen in einer Sub-Supertypbeziehung stehen. Ein fachlicher Behälter sollte nicht als ein Subtyp eines technischen Behälters betrachtet werden. Seine Schnittstelle sollte vorrangig aus anwendungsfachlich motivierten Operationen bestehen, die mit der Schnittstelle eines technischen Behälters nicht ohne weiteres konform sind. Wir verwenden die Benutzt-Beziehung zwischen fachlichen und technischen Behältern. Die technischen Behälter dienen also zur Implementierung von fachlichen Behälter. Damit können wir bei der Imple-

3


3.2


646

mentierung ungeachtet der anwendungsfachlichen Schnittstelle des fachlichen Behälters das gesamte softwaretechnische Repertoire an Varianten und Umgangsformen der technischen Behälter nutzen.

Lehrkörper

OrdCol

Lehrer

LinkedList

Abb. 3-53 Fachliche und technische Behälter

Lehrer Cursor Lehrer

Lehrer

Betrachten wir wieder den Lehrkšrper als einen fachlichen Behälter (s. Abbildung 3-53). Dieser fachliche Behälter benutzt einen technischen Behälter, um die Menge der Lehrer zu verwalten. Dabei kennt die Klasse Lehrkörper nicht den konkreten Typ der Liste (LinkedList), die verwendet wird, sondern arbeitet mit der Liste nur unter der abstrakten Schnittstelle einer Ordered Collection (OrdCol). Außerdem kann sich der Lehrkšrper bei Bedarf Cursor erzeugen, mit denen er die Menge der Lehrer traversieren kann.

3


3.2


647

3.2.8 Fachwerte Zusammenhang von Werkzeug und Material





fachliche Behälter


Werkzeugkomposition

Ereignisverwalter

Materialverwaltung

Fachwerte Fachwerte


Umgebung

Materialkoordinator

Bei der Entwicklung von größeren Systemen mit objektorientierten Programmiersprachen wird nach kurzer Zeit ein Defizit deutlich: Die

3


3.2


648

in den Sprachen vorhandenen Standard-Datentypen reichen nicht aus, um die in einem Anwendungsbereich vorhandene Bandbreite von Basiswerten zu realisieren. Schon ein so einfacher Wert wie ein Geldbetrag läßt sich auf keinen Standard-Datentyp befriedigend abbilden. Der in den meisten Sprachen vorhandene Typ REAL weist beliebig viele Nachkommastellen auf, während wir für einen Geldbetrag zur Darstellung genau zwei Nachkommastellen benötigen. Auch die für die Standard-Datentypen definierten arithmetischen Operationen passen in der Regel nicht zu den für den Anwendungsbereich benötigten arithmetischen Operationen. So gibt es für die Umrechnung von DM auf Euro bereits genaue Rechenvorschriften, die sich von der REALArithmetik unterscheiden. Gleichzeitig können wir nicht einfach Klassen und Objekte verwenden, um die Menge der Standard-Datentypen zu erweitern, weil die Exemplare von Klassen Referenzsemantik besitzen und StandardDatentypen der Wertsemantik genügen müssen (vgl. Kapitel 2.1.14). Im Umfeld des WAM-Ansatzes hat sich aus diesen Gründen das Konzept der Fachwerte gebildet, die nach Wertsemantik verwendet werden können. Im folgenden wird das Konzept »Fachwert« erläutert, die Umsetzung mit Hilfe von Entwurfsmustern beschrieben sowie die Verwendung von Fachwerten in Konstruktionen nach WAM vorgestellt.

3


3.2


649

Wie läßt sich der Satz an elementaren Datentypen, die in Programmiersprachen normalerweise zu finden sind, um solche Datentypen erweitern, die für den jeweiligen Anwendungsbereich relevant sind?

Problem

Programmiersprachen bieten meist nur einen kleinen Satz von Datentypen an, die der Wertsemantik folgen. Diese Standard-Datentypen, wie INTEGER, REAL, BOOLEAN, sind entweder mathematisch oder häufiger an Implementierungsgesichtspunkten orientiert. Der Versuch, schon in die Programmiersprache anwendungsfachliche Datentypen einzuführen, hat sich, wie COBOL und die sogenannten Sprachen der 4. Generation zeigen, nur als begrenzt tauglich erwiesen. Trotzdem benötigen wir für ein Anwendungssystem fachlich orientierte Datentypen, die nach der Wertsemantik verwendet werden können.

Kontext

Realisiere Fachwerte genau wie andere Datentypen als Klassen, wobei bei der Implementierung sichergestellt werden muß, daß sich die Exemplare dieser Klassen wie Werte verhalten. Die als Fachwerte neu entstehenden Datentypen lassen sich nach allgemeinen Prinzipien der Typisierung in zwei Gruppen unterteilen: die elementaren und die zusammengesetzten Fachwerte. Ein elementarer Fachwert (z.B. Uhrzeit) kapselt genau einen »atomaren« Fachwert, der intern als gekapselter Standard-Datentyp realisiert wird. An seiner Schnittstelle werden nur Operationen angeboten, die fachlich für den

Lösung

3


3.2


Umgang mit Werten dieses Typs relevant sind (z.B. Uhrzeit vorstellen und zurückstellen). Zusammengesetzte Fachwerte bauen auf elementaren und anderen zusammengesetzten Fachwerten auf. Sie stellen also eine Zusammenfassung von verschiedenen Werten zu einem neuen Wert dar (z.B. Zeitraum besteht aus zwei Uhrzeiten). An ihrer Schnittstelle gibt es neben den fachlichen Operationen immer solche, um die Fachwerte zusammenzusetzen und gezielt auf einzelne Bestandteile zugreifen zu können (Konstruktoren, Selektoren). Neben dieser Aufteilung kann auch eine Unterteilung anhand der Kardinalität in endliche und unendliche Fachwerte vorgenommen werden. Endliche Fachwerte entsprechen einem Aufzählungstyp und haben daher eine feststehende Anzahl von Werten (z.B. Wochentag). »Unendliche« Fachwerte hingegen sind entweder nicht eingrenzbar (wie z.B. Datum) oder spannen einen Wertebereich auf, der in beliebig viele Teile unterteilt werden kann (wie z.B. Uhrzeit). Die Klassen dieser verschiedenen Fachwerte werden in einer Klassenhierarchie angeordnet, deren oberste Klasse die Klasse Fachwert ist. Diese Oberklasse ist eine abstrakte Klasse, die ihren konkreten Unterklassen die folgende Funktionalität vorschreibt:

650

Die Klasse Fachwert

❑ Operationen, die überprüfen, ob der übergebene Parameter

einen gültigen Wert für eine Fachwert-Klasse darstellt. Als

3


3.2


651

Parameter kann eine String-Repräsentation oder ein Zahlenwert verwendet werden (z.B. Zinssatz.IstGueltigerWert("2,5") oder Zinssatz.IstGueltigerWert(2,5)). Bei zusammengesetzten Fachwerten bezieht sich diese Prüfung auf die einzelnen Elemente. Diese Operationen müssen abhängig von der verwendeten Programmiersprache in der Schnittstelle der Klasse oder als Klassenoperationen realisiert werden. Sind Klassen, wie in Smalltalk, Objekte erster Ordnung und werden Klassenmethoden vererbt, so sollten diese Operationen als Klassenmethoden implementiert werden. In C++ oder Java realisieren wir ein prototypisches Objekt. Klienten rufen dieses prototypische Objekt, das für das Klassenobjekt steht, auf, um dort die Prüfung durchzuführen. ❑ Die Operationen HatEndlichVieleWerte(), GibAlleWerte()

erlauben es, die Menge der für einen Fachwert-Typ gültigen Werte zu erfragen, falls diese Menge endlich ist. Mit diesen Operationen kann der Anwendungsentwickler feststellen, ob es sich um einen endlichen oder einen »unendlichen« fachlichen Wert handelt. Dieser Aspekt ist bei der Darstellung der Fachwerte durch eigene Interaktionstypen relevant.

3


3.2


652

❑ Die Operation GibAlsString() gibt den Wert eines Fachwertes

als String nach außen. Die meisten Fenstersysteme nehmen nur Standard-Datentypen an ihrer Schnittstelle entgegen. Daher muß ein Fachwert in der Lage sein, eine Zeichenketten-Repräsentation seines Werts zu liefern. ❑ In C++ und Smalltalk, die das Überladen von Operatoren

erlauben, können in der Klasse Fachwert Vergleichsoperationen für Fachwerte definiert werden. Als Vergleichsoperatoren könnten angeboten werden: =, == und !=. Schon Hoare hat darauf hingewiesen, daß nur == und != semantisch notwendig für alle Datentypen sind (s. [Hoare72]). Jedenfalls ist zu beachten, daß diese Operationen mit einem Test versehen werden, der feststellt, ob zwei Werte tatsächlich vergleichbar sind. Dieser Test kann sicherstellen, daß nur Fachwerte von Klassen mit gleicher Oberklasse verglichen werden. Er kann auch verhindern, daß die Vergleichsoperatoren an Fachwertklassen ausgeführt werden, deren Objekte nicht miteinander vergleichbar sind (der Größer-Vergleich auf Kontonummer macht z.B. wenig Sinn). Vergleiche mit Objekten der Oberklasse sind ebenfalls nicht zugelassen.

3


3.2


653

Je nach Anwendungsbereich wird die Klasse Fachwert Wurzel verschiedener Vererbungsstrukturen von Fachwert-Klassen sein. Die einzelnen Fachwert-Klassen müssen die in der Oberklasse Fachwert spezifizierten Operationen jeweils für ihren speziellen Wert implementieren. Damit der Wert eines Fachwert-Objekts, sobald es einmal erzeugt ist, nicht mehr verändert werden kann, darf z.B. in C++ der Standard-Konstruktor der Fachwert-Klasse nicht in der öffentlichen Schnittstelle angeboten werden. Statt dessen müssen ein oder mehrere spezielle Konstruktoren mit den entsprechenden Parametern zur Verfügung stehen. Um sicherzustellen, daß Fachwert-Objekte nach Wertsemantik verwendet werden, existieren zwei unterschiedliche Lösungsansätze, die je nach eingesetzter Programmiersprache geeigneter sind: unveränder10 liche und veränderliche Fachwert-Objekte. Der erste Lösungsansatz sieht vor, daß Fachwerte als unveränderliche Objekte implementiert werden. Veränderungen an Fachwert-

Wertsemantik und Speicherverwaltung

Unveränderliche Fachwert-Objekte

10. Der Ausdruck »veränderliches Objekt« ist eigentlich vergleichbar mit »weißer Schimmel«, da Objekte prinzipiell veränderlich sind. Wir verwenden den Ausdruck allerdings bewußt, um den Konstruktionsansatz von Fachwerten durch »normale« Objekte zu charakterisieren.

3


3.2


654

Objekten werden dadurch ausgeschlossen, daß wir an der Schnittstelle der Fachwert-Klassen keine verändernden Operationen zulassen. Diese Lösung kann in allen objektorientierten Programmiersprachen verwendet werden und sowohl mit einer dynamischen Erzeugung von Objekten (in Java und Smalltalk) als auch mit einer statischen Erzeugung von Objekten (in C++) umgesetzt werden. Die Nachteile dieser Lösung besteht darin, daß einerseits bei jeder Veränderung eines Fachwerts neuer Speicherplatz angefordert werden muß und andererseits daß die programmiertechnische Handhabung von Fachwert-Objekten, deren Klassen keine verändernden Operationen anbieten, nicht sehr elegant ist. Bei jeder Veränderung muß ein neuer Bezeichner angelegt werden und ihm das Ergebnis der Veränderung zugewiesen werden. Das Speicherplatzproblem, das bei der Lösung mit unveränderlichen Fachwerten auftritt, läßt sich auf technischer Ebene durch die Verwendung der Entwurfsmuster, Fliegengewicht (Flyweight) und Fabrik (Factory) beseitigen. Diese Entwurfsmuster stellen sicher, daß technisch nicht bei jeder Veränderung eine Kopie angelegt wird. Das Fliegengewichtmuster aus [Gamma et al. 96] stellt sicher, daß von den konkreten Fachwert-Objekten jeweils nur ein Objekt für jeden speziellen Wert existiert. Zum Erzeugen der Objekte wird eine Fabrik (s. [Gamma et al. 96]) verwendet, die an ihrer Schnittstelle entsprechende

3


3.2


655

Operationen zur Verfügung stellt. Innerhalb der Fabrik werden alle bereits erzeugten Fachwert-Objekte gespeichert. Wenn ein neuer Fachwert angefordert wird, wird überprüft, ob ein Objekt für diesen Fachwert bereits von der Fabrik erzeugt worden ist. Ist dies der Fall, so wird das entsprechende Objekt zurückgegeben, anderenfalls muß ein neues Fachwert-Objekt erzeugt werden. Auf diese Weise können wir sicherstellen, daß sich verschiedene Komponenten, die denselben Fachwert verwenden, ein Fachwert-Objekt teilen können. In Abbildung 3-54 sind als elementare Fachwerte Wochentag, Uhrzeit und Datum zu erkennen. Der Zeitraum kann als zusammengesetzter Fachwert verstanden werden. Die beiden Pausenobjekte kleinePause und grossePause teilen sich über das Fliegengewichtmuster den gleichen Wochentag und das Datum.

3


3.2


656 Abb. 3-54

Pausenplan

Fachwert-Objekte beim Pausenplaner

kleinePause

grossePause

fachliche Werte Zeitraum

10:40

Mittwoch

10:50

30.07.1997

11:30

Zeitraum

11:45

Die Verwaltung der Fachwert-Objekte über das Fliegengewichtmuster eignet sich besonders für Fachwerte, die einen endlichen und relativ kleinen Wertebereich besitzen, wie z.B. Wochentag oder Monat. Die Fachwert-Objekte für diese Klassen werden oft schon beim Starten der Anwendung erzeugt und erst beim Beenden wieder gelöscht. Wollen wir das zweite oben erwähnte Problem, die programmiertechnische Handhabung von unveränderlichen Fachwert-Objekten, vermeiden, so müssen wir den zweiten Lösungsansatz mit veränderlichen Fachwert-Objekten einsetzen.

3

Veränderliche Fachwert-Objekte


3.2


657

Bei dieser Lösung bieten die Fachwert-Klassen alle benötigten verändernden Operationen an. Um sicherzustellen, daß die von diesen Klassen erzeugten Fachwert-Objekte nach Wertsemantik benutzt werden, muß entweder vom Anwendungsprogrammierer vor jeder verändernden Operation das Fachwert-Objekt kopiert werden oder die Fachwert-Klassen müssen über einen internen Kopiermechanismus verfügen. Prinzipiell ist die Variante, bei der der Anwendungsprogrammierer die benötigten Kopien herstellt, funktionsfähig und kann mit Hilfe des Fliegengewichtmusters (siehe oben) auch performant umgesetzt werden. Allerdings kann nur durch Programmierrichtlinien sichergestellt werden, daß der Anwendungsprogrammierer tatsächlich vor einer Veränderung an einem Fachwert-Objekt eine Kopie anlegt. Um das Kopieren der Objekte in den Fachwert-Klassen selbst anzusiedeln, läßt sich das Body/Handle-Muster einsetzen. Das Body/Handle-Muster wird sowohl in [Coplien 92, Koenig & Moo 97] beschrieben als auch in [Gamma et al. 96] im Rahmen des Proxymusters als »Copy-on-write« erläutert. Die Idee des Body/HandleMusters besteht darin, zu einem vorhandenen Klassenbaum einen zweiten Baum derselben Struktur, einen sogenannten Schattenbaum, aufzubauen. Der Klassenbaum der Fachwerte ist der Body-Baum. Dazu existiert ein isomorpher Handle-Baum. Ein Beispiel ist in Abbildung 3-55 dargestellt.

3


3.2


Handle-Baum

Body-Baum

FachlicherWert

FachWertBody

658 Abb. 3-55 Body/Handle-Bäume für

Datum

Fachwerte

DatumBody Uhrzeit

UhrzeitBody

Jede Handle-Klasse besitzt als Exemplarvariable lediglich einen Verweis auf die zugehörige Body-Klasse. Der Aufruf einer Operation an der Handle-Schnittstelle wird in den Handle-Klassen direkt an den Body weitergeleitet und dort abgehandelt. In der Anwendung sind die Handle-Objekte »Platzhalter« für die Body-Objekte. Wie bei dem Fliegengewichtmuster wird auch hier ein Objekt von mehreren anderen benutzt. Ein Handle-Objekt erhält über eine Fabrik das benötigte Body-Objekt, das es sich, wenn möglich, mit anderen Handle-Objekten teilt. In der Regel wird das Body/Handle-Muster mit einem Mechanismus zum Zählen der Referenz auf den Body kombiniert (Reference

3


3.2


659

Counting). Jede Body-Klasse hat einen Zähler, in dem festgehalten wird, wie viele Handle-Objekte auf ein Body-Objekt verweisen. Wird an einem Handle-Objekt eine verändernde Operation aufgerufen und der Referenzzähler des eingebetteten Body-Objekts ist größer als eins, so erzeugt das Handle-Objekt eine neue Kopie des Body-Objekt und führt an diesem die Veränderung durch. Außerdem wird der Zähler des alten Body-Objekts um eins erniedrigt und die Referenz des Handles auf das neue Body-Objekt gesetzt, das für seinen Referenzzähler den Wert eins erhält. Um sicherzustellen, daß das Handle-Objekt nicht mehr als einmal referenziert und so die Wertsemantik verletzt werden kann, muß das Handle-Objekt seinerseits jeweils kopiert werden, bevor es als Parameter übergeben werden kann oder bevor das Objekt, das eine Referenz auf ein Handle-Objekt besitzt, kopiert wird. Die Lösung mit dem Body/Handle-Muster erscheint daher nur dann sinnvoll einsetzbar, wenn das Kopieren der Handle-Objekte automatisch passiert. Daher wird diese Lösung hauptsächlich in C++ verwendet, wo die Handles als statische Objekte implementiert werden können. Der Aufruf des new-Operator für die Handle-Klasse muß in diesem Fall verhindert werden, indem der new-Operator als private deklariert wird. Der Vorteil dieser Lösung besteht darin, daß er sehr ausgewogen ist und daß speziell in C++ die Speicherplatzverwaltung sehr einfach

3


3.2


660

über das Zählen der Referenzen im Body-Objekt implementiert werden kann. Der wesentliche Nachteil ist, daß die Handle-Objekte nicht per Referenz verwendet werden dürfen und dieses Verbot wiederum nur durch Programmierrichtlinien sicherzustellen ist. Sowohl die Lösung mit unveränderlichen als auch die Lösung mit veränderlichen Fachwert-Objekten hat Vor- und Nachteile. Da sich aber nicht alle Lösungen für die gängigen objektorientierten Programmiersprachen eignen, ist hier schon ein gutes Kriterium gegeben, um sich für eine Lösung zu entscheiden. Darüber hinaus sollte aus organisatorischen Gründen eine Lösung gewählt werden, die die geringste Anfälligkeit für Programmierfehler aufweist.

Diskussion

Im Kontext des WAM-Ansatzes werden Fachwerte als Bestandteile von Materialien verwendet. Wenn wir uns ein Material als einen Baum von Objekten vorstellen, dann sind die Blätter in diesem Baum Fachwert-Objekte, die wiederum Standard-Datentypen für ihre Implementierung benutzen. Für jeden speziellen Anwendungsbereich müssen wir daher entsprechende Fachwert-Klassen konstruieren, die als elementare Bestandteile der Materialien verwendet werden können. Beim Werkzeugbau sind Fachwerte neben Standard-Datentypen die einzigen Objekte, die von der Funktionskomponente an die Interaktionskomponente weitergegeben werden. An dieser Stelle wird ein

Verwendung

3


3.2


661

weiterer Grund deutlich, warum Fachwerte nach Wertsemantik konstruiert werden sollen. Das Material soll nur von der Funktionskomponente direkt bearbeitet werden (s. Kapitel 3.2.2). Daher darf auf konzeptioneller Ebene die Funktionskomponente der Interaktionskomponente keine Verweise auf das Material übergeben. Werden Fachwerte von der Funktionskomponente an die Interaktionskomponente weitergegeben, so erhält die Interaktionskomponente jeweils Kopien der Fachwert-Objekte. Hat der Benutzer einen Wert verändert, so übergibt die Interaktionskomponente diesen Wert an die Funktionskomponente. Die FK verändert das Material entsprechend. Um die Fachwerte in der Interaktionskomponente anzuzeigen, können spezialisierte Interaktionstypen (s. Kapitel 3.2.4) eingesetzt werden. Diese Interaktionstypen für Fachwerte sind jeweils passend zu einer Fachwert-Klasse konstruiert und können die Eingaben des Benutzers direkt auf ihre Gültigkeit überprüfen. Dadurch kann verhindert werden, daß z.B. bei der Eingabe eines Datums erst in der Funktionskomponente überprüft wird, ob das Datum überhaupt syntaktisch korrekt ist, um dann Rückmeldungsmechanismen an den Benutzer zu aktivieren. Ist ein Interaktionstyp in der Lage, die eingegebenen Zeichen auf ihre (kontextfreie) Gültigkeit für einen bestimmten Fachwert zu überprüfen, so haben wir erreicht, daß die Funktionskomponente nur noch Fachwerte erhält. Diese müssen dann allerdings

3


3.3

Eine rahmenwerkbasierte Modellarchitektur

662

noch auf ihre Gültigkeit im jeweiligen Zusammenhang geprüft werden. Wenn z.B. in einem Formular ein Geburts- und eine Eheschließungsdatum eingetragen werden sollen, so kann ein plausibles Verhältnis zwischen den beiden nur innerhalb der Funktionskomponente oder vom Formular selbst geprüft werden, da dies Kontextwissen erfordert.

3.3


In Kapitel 2.5 haben wir die wesentlichen Modelle und Kontexte der Systementwicklung skizziert. Dabei haben wir für den WAM-Ansatz vor allem die Anwendungsorientierung und Strukturähnlichkeit der verwendeten Modelle und der Anwendungssysteme gefordert. Wir haben festgestellt, daß die Elemente des Objekt-Metamodells von Kapitel 2.1 die Mikroelemente für die Modellierung von Anwendungssystemen darstellen. Für die Entwicklung großer objektorientierter Systeme benötigen wir aber Makrostrukturen, die eine überschaubare und handhabbare Organisation dieser Systeme erlauben. Diese Makrostrukturen müssen wir auf entsprechende Modellierungseinheiten abbilden (s. [Bäumer et al. 97]). Eine solche Strukturierung

3

Federführung: Dirk Bäumer


3.3


von Software nach Modellierungseinheiten, die Makrostrukturen entsprechen, nennen wir Softwarearchitektur. Softwarearchitekturen sind in unserem Verwendungszusammenhang immer konkret und projektspezifisch, da sie den Aufbau eines Softwaresystems festlegen. Dazu müssen die Modellierungseinheiten definiert, die fachlichen und softwaretechnischen Komponenten der verschiedenen Modelle identifiziert und zueinander in statische und dynamische Beziehungen gebracht werden.

663 Softwarearchitekturen

Softwarearchitektur: Eine Softwarearchitektur bezeichnet die Modelle und die konkreten Komponenten eines Softwaresystems in ihrem statischen und dynamischen Zusammenspiel. Sie kann selbst als explizites Modell dargestellt werden. Eine Softwarearchitektur beschreibt ein konkretes System in seinem Anwendungskontext.

Natürlich können wir in diesem Buch keine konkrete Softwarearchitektur vorgeben, die dann für eine Menge von Projekten verbindlich und sinnvoll wäre. Aber wir können Verallgemeinerungen ähnlicher Softwarearchitekturen beschreiben und mit Beispielen illustrieren. In der Diskussion unter Entwicklern wird das Wort »Softwarearchitektur« oft auch im allgemeinen Sinne gebraucht, etwa wenn wir von

3


3.3


664

einer Client/Server-Architektur reden. Um Verwirrung zu vermeiden, werden wir das in diesem Handbuch nicht tun. Oft wollen wir die Gestaltungs- und Konstruktionsprinzipien herausheben, die für die definierten Modellierungseinheiten hinter einer konkreten Softwarearchitektur gelten. Dann sprechen wir über eine Abstraktion. Jenseits einer konkreten Softwarearchitektur stellen wir sozusagen ein allgemeines Gesamtmodell einer Softwarearchitektur vor, das wir entsprechend Modellarchitektur nennen. Andere ([Bäumer 98, Monroe et al. 97]) sprechen von Architekturstil, wenn es um die grundlegenden Elemente, ihre Verknüpfungen und deren Regelhaftigkeit geht. Unser Begriff Modellarchitektur besagt darüber hinaus, daß hier ein anleitendes Modell für die Anwendungssysteme nach dem WAM-Ansatz gemeint ist. Damit erfüllt eine Modellarchitektur für die softwaretechnische Konstruktion eine ähnliche Funktion wie das Leitbild mit seinen Entwurfsmetaphern für die anwendungsfachliche Modellierung. Modellarchitektur: Eine Modellarchitektur beschreibt die allgemeinen Prinzipien hinter einer Softwarearchitektur. Sie umfaßt die grundlegenden Elemente, deren Verknüpfungen und die Regeln, die für eine Softwarearchitektur gelten. Eine Modellarchitektur gibt Anleitung bei der softwaretechnischen Realisierung eines Softwaresystems.

3


3.3


Aus den vorangegangenen Abschnitten sollte deutlich geworden sein, daß eine solche Modellarchitektur für objektorientierte Systeme aus unserer Sicht heute nur rahmenwerkbasiert sein kann, da anders die Entwicklung großer und langlebiger Systeme nicht mehr sinnvoll zu bewerkstelligen ist. Auch eine Modellarchitektur ist nicht anwendungsunabhängig. Wir haben den Anwendungsbereich von WAM bereits durch unser Leitbild auf interaktive Arbeitsplatzsoftware zugeschnitten. Im folgenden Abschnitt schränken wir den Anwendungsbereich für die dort beschriebene rahmenwerkbasierte Modellarchitektur noch weiter ein. Wir argumentieren, daß Organisationen, die nach Sparten, Produkten oder anderen objektbezogenen Prinzipien aufgebaut sind, anwendungsorientierte Makrostrukturen für rahmenwerkbasierte Architekturen im Sinne von WAM vorgeben. Davon ausgehend diskutieren wir, wie eine rahmenwerkbasierte Modellarchitektur für WAMAnwendungssysteme aussehen kann. Schließlich beschreiben wir zwei Entwurfsmuster, die für die Realisierung einer konkreten rahmenwerkbasierten Architektur wichtig sind.

3

665

Anwendungsbereich der WAM-Modellarchitektur


3.3


666

3.3.1 Softwarearchitektur und Organsiationsstrukturen Wir fassen die Anforderungen aus Kapitel 2.5 für die Strukturierung großer Softwaresysteme stichpunktartig zusammen: ❑ Die fachliche Modellierung des Anwendungsbereichs be-

stimmt das technische Modell des Anwendungssystems. ❑ Das im Modell des Anwendungsbereichs aufgebaute Begriffs-

gebäude soll ohne Bruch in Klassen und Klassenbeziehungen übertragen werden. Dazu müssen Konzepte und Darstellungen erkennbar strukturähnlich sein. Klassen und ihre Beziehungen bilden die Mikroelemente einer Softwarearchitektur. ❑ Gesucht werden Makrostrukturen im Anwendungsbereich, die

analog zu den fachlichen Gegenständen und Begriffen Ausgangspunkt für Modellierungseinheiten sein können, die einer strukturähnlichen Gestaltung großer Softwaresysteme dienen. Konventionell wurden große Softwaresysteme im wesentlichen aufgrund der Erfahrung der Entwickler strukturiert. Anleitung dabei gaben die Prinzipien der Modularisierung, wie sie etwa in [Parnas72] aufgestellt worden sind. Doch sind Module eher mit den Klassen objektorientierter Systeme zu vergleichen als mit den Makrostrukturen, die wir suchen.

3


3.3


667

Die von uns propagierte Anwendungsorientierung legt nahe, nach solchen Makrostrukturen im Anwendungsbereich zu suchen. Mit der Eingrenzung des Anwendungsbereichs auf Organisationen oder Teile davon kommen bei dieser Suche die Strukturen einer Unternehmensorganisation in den Blick. Dabei sind solche Strukturen in Organisationen von Interesse, die ebenfalls Makrostrukturen darstellen und eine relativ hohe Geltungsdauer (wünschenswert sind mehr als 10 Jahre) aufweisen. Die Betriebswirtschaft unterscheidet klassisch zwischen Aufbau- und Ablauforganisation. Für uns ist die Ablauforganisation weniger von Interesse, da sich in der Dynamik der Aufgabenzuordnung und -erledigung ja gerade durch die Informationstechnologie rasche Verschiebungen ergeben. Das gleiche gilt für die Arbeitsorganisation, die sich mit der Organisation von Einzel- und Gruppenarbeit beschäftigt. Damit rückt die Aufbauorganisation in den Mittelpunkt, da sie den statischen Aspekt eines Unternehmens repräsentiert. Dies entspricht dem Konzept der Softwarearchitekturen, die ja primär die statischen Aspekte eines Softwaresystems, nicht dessen dynamisches Verhalten zur Laufzeit beschreiben. Im folgenden skizzieren wir einige elementare Modelle der Unternehmensorganisation, um daran klarzumachen, welcher Typ von

3


3.3


668

Unternehmensorganisation Grundlage der Makrostrukturen ist, die wir in unserer Modellarchitektur verwendet haben. Wir wollen damit nicht sagen, daß sich andere Organisationstypen nicht zur Strukturierung von Softwarearchitekturen eignen. Es geht nur darum, den Organisationstyp zu charakterisieren, der hinter dem von uns gewählten Anwendungsbereich des rahmenwerkbasierten Architekturmodells steht, damit die Übertragbarkeit unseres Modells deutlich wird. Organisationsmodelle von Unternehmen

Die Betriebswirtschaftslehre unterscheidet verschiedene Modelle für die Unternehmensorganisation. Damit soll das Ziel erreicht werden, ein Unternehmen einerseits arbeitsteilig zu gliedern, auf der anderen Seite sicherzustellen, daß die einzelnen Organisationseinheiten mit möglichst geringen Reibungsverlusten ein gemeinsames Unternehmensziel verfolgen (s. [Frese 92]). Für unseren Zusammenhang sind vor allem zwei Organisationsmodelle wichtig, die gegensätzliche Prinzipien verkörpern – das Verrichtungs- und das Objektprinzip (vgl. [Bleicher 91, Engelmann 95]). ❑ Das Verrichtungsprinzip entspricht unserem Leitbild der Fa-

brik (s. Kapitel 2.2.1). Die Grundidee ist, anstehende Aufgaben in Einzelschritte zu zerlegen und jeweils einem Arbeitsplatz

3


3.3


669

oder einer Organisationseinheit zuzuweisen. Diese Einheit erledigt dann eine »Funktion« oder »Verrichtung« an den unterschiedlichen Produkten, die das Unternehmen anbietet. Als Beispiel dient eine Fahrzeugfabrik, die LKWs und PKWs herstellt. Sie ist in die Abteilungen Planung, Beschaffung, Produktion, Vertrieb und Rechnungswesen aufgeliedert (s. Abbildung 3-56a) ❑ Beim Objektprinzip stehen die Arbeitsgegenstände im Mittel-

punkt. Jeder Arbeitsplatz und damit die zugehörige Organisationseinheit ist für die Erledigung einer zusammenhängenden Aufgabe an dem Arbeitsgegenstand zuständig. Das Objektprinzip paßt zu unserem WAM-Leitbild (s. Kapitel 2.2.3). In unserem Beispiel wäre die Fahrzeugfabrik in die zwei Abteilungen PKW-Bau und LKW-Bau unterteilt (s. Abbildung 3-56b)

3


3.3

670


Abb. 3-56

a) Verrichtungsprinzip

Unternehmensorganisation nach dem Verrichtungs-

Leitung

und Objektprinzip

Planung

Beschaffung

Produktion

b) Objektprinzip

Vertrieb

Rechnungswesen

Leitung

PKW-Bau

LKW-Bau

Für unser Beispiel der Pausenplanung können wir überlegen, nach welchem Prinzip das »Unternehmen Schule« organisiert ist. Die traditionelle Einteilung nach Schulklassen entspricht sicherlich dem Objektprinzip, wobei das »Objekt« die Gruppe der Schüler einer Klasse ist. Nach einem vorgegebenen Stundenplan kommen die jeweiligen Lehrer an einen festen Ort, das Klassenzimmer, um dort der Klasse ihre wechselnden Dienstleistungen anzubieten.

3


3.3


671

Das reine Kurssystem der Gymnasien und Gesamtschulen kommt dagegen dem Verrichtungsprinzip sehr nahe, da dort die Kurse als »Funktionen« die vorherrschende Organisationsstruktur ausmachen. Entsprechend müssen sich die Schüler im Laufe des »Ausbildungsprozesses« jeweils an einen anderen Ort begeben. Natürlich spiegelt das Verrichtungs- und das Objektprinzip nur eine grobe Einteilung von Organisationsmodellen wider. Aber daraus lassen sich für konkrete Unternehmen doch wichtige Schlüsse ziehen. So sind die Finanz- und Dienstleistungsunternehmen, mit denen wir in Projekten häufig zusammengearbeitet haben, meist nach Geschäftsbereichen oder sogenannten Sparten organisiert. Dabei werden Produkte, Regionen oder Kundengruppierungen als Objekte betrachtet, die die Unternehmensorganisation bestimmen. Jede Abteilung soll ihre Aufgaben weitgehend unabhängig von den anderen erledigen können. [Frei et al. 96] sprechen in diesem Zusammenhang von »Primäraufgaben« einer Abteilung oder organisatorischen Einheit. Am Beispiel einer Bank sind dies die Kredit-, die Wertpapier- und die Kontoführungsabteilung. Aktuell ist das Prozeßprinzip in Zusammenhang mit dem Business Process Reengineering in die Diskussion gekommen (vgl. [Engelmann 95, Frei et al. 96]). Die Grundidee besteht darin, einen Prozeß ausgehend von äußeren (Kunden-) Anforderungen durchgängig in einer

3


3.3


672

Organisationseinheit zu erledigen. Für den von uns betrachteten Zusammenhang ergibt sich daraus keine wesentliche neue Einteilung. Denn wenn sich die Prozesse auf bestimmte Produkte oder Dienstleistungen beziehen, dann schlagen sich Objekt- und Produktprinzip in ähnlichen Organisationsstrukturen nieder. Das zentrale Kritierium bleibt gewahrt: Organisationseinheiten werden nach den jeweiligen Primäraufgaben gebildet. Am Beispiel einer Bank kann Prozeßorientierung zweierlei bedeuten: Ein Kundenwunsch, z.B. eine Baufinanzierung, wird umfassend in der Kreditabteilung erledigt. Dies ist die klassische Spartenorganisation. Alternativ gibt es ein Servicezentrum, wo der Kunde in allen Standarddienstleistungen der Bank von einer Person beraten und betreut wird. Wir werden im weiteren zeigen, daß beide Arten von Unternehmensorganisation elegant zur Grundlage einer Softwarearchitektur gemacht werden können. Zusammenhang unternehmensbezogener Strukturen und Softwarearchitekturen

Wir haben bisher im wesentlichen zwei unterschiedliche Organisationsprinzipien für Unternehmen identifiziert – das Verrichtungs- und das Objektprinzip. Das Verrichtungsprinzip geht von einem fabrik-

3


3.3


673

artig organisierten Produktionsprozeß aus, bei dem die einzelnen Abteilungen eine Funktion oder Teilaufgabe im Prozeß bereitstellen. Das Objektprinzip ist gegenstandsorientiert, wobei die Gegenstände konkrete Produkte oder zusammengehörige Dienstleistungen für Kundengruppierungen sein können. In unserem Sinne können wir in beiden Fällen von Arbeitsgegenständen sprechen. Das Objektprinzip verfolgt das Ziel, ein Produkt oder eine Dienstleistung so innerhalb einer Abteilung anzusiedeln, daß diese weitgehend unabhängig von den anderen Abteilungen ihre Aufgaben erledigen kann. Diese Unabhängigkeit der Abteilungen hat zur Folge, daß Arbeitsgegenstände eines Bereichs nur geringe oder keine Beziehungen zu Arbeitsgegenständen in anderen Bereichen aufweisen. Diese Art von Unternehmensorganisation stellt eine Makrostruktur dar, wie wir sie als Ausgangspunkt für unsere Modellarchitektur gesucht haben. Sie ist relativ langlebig und stabil. Zudem bietet sie ein ähnliches Organisationsprinzip wie die Modularisierungsprinzipien von Parnas und Yourdon. Die Konzepte von minimaler Kopplung und maximaler Kohäsion sind in [Meyer 97] auf den objektorientierten technischen Entwurf übertragen worden. Wir werden sie hier auch auf die Makrostrukturen einer Softwarearchitektur anwenden. Um die Strukturähnlichkeit zu gewährleisten, wird das softwaretechnische Modell des Anwendungssystems auf der Basis der Gegen-

3


3.3

674


stände des Anwendungsbereichs gebildet, die auch im Sinne der Organisationstheorie Arbeitsgegenstände darstellen. Für Organisationseinheiten und Entwurfskomponenten gilt das Prinzip, die jeweils betrachteten Gegenstände so zu (Modellierungs-) Einheiten zu gruppieren, daß zwischen den Gegenständen zweier Einheiten möglichst geringe wechselseitige Abhängigkeiten existieren. Wir können daher die Strukturähnlichkeiten zwischen Anwendungsbereich und ObjektMetamodell weiterführen, wie dies in Abbildung 3-57 dargestellt ist. Dazu führen wir den Begriff Produktbereich ein. Anwendungsbereich

softwaretechnisches Modell

Mikrostrukturen

Strukturähnlichkeit zwischen Anwendungs-

Gegenstand

Objekt

Umgangsform

Operation

Begriff

Klasse

Generalisierung, Spezialisierung

Vererbung

Komposition

Aggregation, Assoziation

Begriffshierarchie

Abb. 3-57

bereich und softwaretechnischem Modell

Klassenhierarchie

Makrostrukturen Produktbereich

Subsystem

geringe Interdependenz,

minimierte Kopplung,

innerer Zusammenhalt

maximierte Kohäsion

3


3.3


675

Produktbereich

Unter Produktbereich fassen wir zunächst alle Formen von Unternehmensorganisationen zusammen, die nach dem Objektprinzip gebildet sind. Vielfach finden wir im Dienstleistungsbereich die so gestaltete Sparten- oder (Fach-) Abteilungsorganisation. Die jeweilige Organisationseinheit gruppiert sich um ein Produkt- oder eine Dienstleistungsart. Beispiele im Bankenbereich sind die Kredit- und die Wertpapierabteilung. Diese Gliederung hat den Vorteil, daß fachlich homogene Einheiten vorliegen, die in sich kohärent sind und keine großen Querbezüge zu den Produkten und Dienstleistungen der anderen Einheiten besitzen. Auch Unternehmen, die im Rahmen einer Organisationsentwicklung nach dem Business Process Reegineering umstrukturiert werden und deren Prozesse sich an Produkten orientieren, haben solche Produktbereiche. Ist ein Unternehmen nach Produktbereichen gegliedert, stellen diese für uns eine Modellierungseinheit dar, die wir als Makrostruktur unserer Modellarchitektur nutzen wollen.

3


3.3


676

Produktbereich: Ein Produktbereich ist eine Organisationsform, die nach dem Objektprinzip oder nach einem an Produkten ausgerichteten Prozeßprinzip aufgebaut ist. Er ist ein Teil des Anwendungsbereichs, der weitgehend unabhängig vom Rest analysiert, modelliert und konstruiert werden kann. Ein Produktbereich ist eine für die Softwarearchitektur relevante Makrostruktur, die als Modellierungseinheit verwendet werden kann.

Einsatzkontext

Wir haben bereits festgestellt, daß die unmittelbare Abbildung der verschiedenen Produktbereiche auf die Organisationsstruktur eines Unternehmens einer eher traditionellen Einteilung entspricht. Während viele Dienstleistungsunternehmen zwar im »inneren Aufbau« noch nach den entsprechenden Sparten oder Fachabteilungen gegliedert sind, sind die kundennahen Bereiche bereits umorganisiert worden. Dies hängt damit zusammen, daß sich die Marktbedingungen und damit das Kundenverhalten geändert hat. Mit dem zunehmenden Wettbewerb und der internationalen Marktöffnung wandelt sich der Verkäufermarkt zum Käufermarkt. Statt eines produktorientierten Verkaufs oder Dienstleistungsangebots steht die Kundenorientierung im Mittelpunkt.

3


3.3


677

Kundenorientierung bedeutet, daß der Kunde mit seinen Bedürfnissen und Anforderungen im Mittelpunkt steht. Grundsätzlich wird Kundenorientierung so umgesetzt, daß das jeweilige Unternehmen nicht nur seine Produkt- und Dienstleistungsangebote, sondern auch die Organisation ihrer »Schnittstelle« zur Außenwelt vorrangig an den Bedürfnissen und Wünschen der Kunden ausrichtet. Im Bankenbereich stellen wir beispielsweise fest, daß die Bank zum umfassenden Finanzdienstleister wird, der mehr als die traditionellen Bankangebote offeriert. Zusätzlich zu den klassischen passiven Dienstleistungsangeboten (der Kunde kommt auf die Bank zu) tritt die Bank neuerdings gezielt mit aktiven Dienstleistungsangeboten an den Kunden heran. So wird eine Hausfinanzierung nicht mehr nur als Kredit realisiert. Dazu werden in der Kapitalaufbauphase Investitionsmöglichkeiten und zur Kreditabsicherung und langfristigen Tilgung Lebensversicherungen angeboten. Gleichzeitig ändert sich das Kundenbild. Es gibt nicht mehr den Kunden, sondern die Kunden werden in unterschiedliche Gruppen segmentiert. Diese Kundensegmentierung soll dazu beitragen, aufgeteilt nach Bedürfnissen und Potentialen, möglichst homogene Kundengruppen zu identifizieren und anzusprechen. Daraus folgt, daß das gleiche Produkt- oder Dienstleistungsangebot auf vielfältige Weise angeboten werden kann.

3


3.3


678

Bleiben wir beim Bankenbeispiel. Hier finden wir die Kreditvergabe im persönlichen Beratungsgeschäft zugeschnitten auf den einzelnen Kunden; als standardisiertes Angebotsspektrum im Servicezentrum oder als einfachen Konsumentenkredit im Homebanking oder Internet-Banking. Was folgt aus diesen Überlegungen zur Kundenorientierung für die Organisationsstruktur eines Unternehmens? In vielen Unternehmungen bilden sich kundenorientierte Arbeitsplätze heraus, die nicht mehr an den einzelnen Produktbereichen orientiert sind, sondern eher prozeßorientiert die Bedürfnisse der Kunden in den Mittelpunkt stellen. So entsteht eine breite Produkt- oder Dienstleistungspalette, die an verschiedenen Arbeitsplätzen teils unterschiedlich präsentiert und bearbeitet werden muß. Sollen für diese Arbeitsplätze Anwendungssysteme entwickelt werden, dann müssen diese Systeme ebenfalls eine differenzierte Unterstützung über mehrere Produktbereiche hinweg anbieten. Dazu kommen Anwendungssysteme, die direkt durch die Kunden benutzt werden sollen. Wir nennen den Teil des Anwendungsbereichs, in denen die konkrete Arbeit mit Unterstützung durch ein Anwendungssystem erledigt wird, den Einsatzkontext. In einem Einsatzkontext werden bei der Erledigung von Aufgaben oft Produkte und Dienstleistungen aus verschiedenen Produktbereichen angeboten; außerdem müssen in ver-

3


3.3


679

schiedenen Einsatzkontexten häufig Produkte desselben Produktbereichs unterschiedlich präsentiert werden. Einsatzkontext: Ein Einsatzkontext umfaßt den konkreten Arbeitszusammenhang, in dem ein Anwendungssystem in einem Unternehmen eingesetzt wird. Dieser Arbeitszusammenhang definiert die Menge der Aufgaben, die mit Hilfe des Anwendungssystems im Einsatzkontext erledigt werden. Dabei können Produkte und Dienstleistungen aus unterschiedlichen Produktbereichen angeboten und bearbeitet werden. Je nach Arbeitszusammenhang kann auch ein Produkt unterschiedlich bereitgestellt werden. Die Loslösung des Einsatzkontextes vom Produktbereich vereinfacht eine kundenorientierte Unternehmensorganisation. Der Einsatzkontext ist eine Modellierungseinheit.

Im Bankenbereich sind beispielsweise folgende Einsatzkontexte für Anwendungssysteme erkennbar: ❑ Arbeitsplätze für persönliche Kundenberater: Diese Arbeits-

plätze sind für den Individualkunden gedacht. Nach dem Prinzip »alles aus einer Hand« werden Produkte des Kredit-,

3


3.3


680

Anlage- und Wertpapiergeschäfts angeboten. Ziel ist es, den Individualkunden persönlich bei einem Großteil seiner Bankgeschäfte zu betreuen. ❑ Arbeitsplätze für Produktspezialisten: Diese Arbeitsplätze bie-

ten eine spezialisierte Unterstützung für einzelne Produktbereiche wie Kredit-, Anlage- und Wertpapiergeschäft. Die jeweiligen Bankspezialisten bearbeiten die Kundenforderungen, die von den Kundenberatern aufgrund der fachlichen Komplexität nicht erledigt werden können. ❑ Arbeitsplätze im Schalterbereich und für das Massengeschäft:

Bei diesen Arbeitsplätzen kommt es darauf an, standardisierte Dienstleistungen schnell und sicher zu unterstützen. Beispiele hierfür sind der Arbeitsplatz in einem Servicezentrum oder die Überwachung des Überweisungsverkehrs einer Bank im BackOffice-Bereich. ❑ Homebanking und Selbstbedienungsterminals: Diese Anwen-

dungssysteme bieten einerseits standardisierte Bankdienstleistungen für bankfachliche Laien an; sie müssen aber auch auf den wenig erfahrenen Softwarebenutzer zugeschnitten sein.

3


3.3


681

Diese verschiedenen Anwendungskontexte erfordern nicht nur unterschiedliche Anwendungssysteme, sie orientieren sich zum Teil auch an verschiedenen Leitbildern: Der Arbeitsplatz des individuellen Kundenberaters entspricht ebenso wie der des Produktexperten dem von uns vorgestellten Leitbild des Arbeitsplatzes für eigenverantwortliche Expertentätigkeit. Ein entsprechendes Anwendungssystem muß den Berater oder Produktexperten optimal bei der Erledigung der verschiedenen Aufgaben unterstützen und darf wenig Vorgaben für den Arbeitsablauf machen. Während das System für den Kundenberater ein breites Spektrum von Produkten aus verschiedenen Produktbereichen für den sogenannten 80%-Fall anbietet, muß das System des Produktspezialisten alle Details eines Produktbereichs zugänglich machen. Die Arbeitsplätze im Schalterbereich und für das Massengeschäft entsprechen eher dem, was wir in Kapitel 2.2.5 unter Funktionsarbeitsplätzen beschrieben haben. Hier steht die rasche eigenverantwortliche Erledigung von standardisierten Aufgaben im Mittelpunkt. Die entsprechenden Anwendungssysteme müssen entweder mehrere Standardprodukte aus unterschiedlichen Bereichen auf einfache Art und Weise anbieten oder eine Aufgabenerledigung hochoptimiert unterstützen.

3


3.3


682

Im Homebanking und Selbstbedienungsbereich trifft am ehesten das Leitbild vom Selbstbedienungsautomaten zu. Bankfachlich müssen unterschiedliche Produktbereiche abgedeckt, aber auf allgemeinverständliche Art und Weise präsentiert werden. Dazu kommen hohe Anforderungen an den Bedienungskomfort und die Klarheit des Benutzungsmodells. Ein letzter Gesichtspunkt bezieht sich potentiell auf alle Anwendungssysteme, die an den verschiedenen Bankarbeitsplätzen eingesetzt werden. Wir haben festgestellt, daß die verschiedenen Anwendungssysteme je nach Einsatzkontext unterschiedlich gestaltet werden müssen, um den jeweiligen Anforderungen zu entsprechen. Damit bilden unterschiedliche Einsatzkontexte jeweils eine Modellierungseinheit. Gleichzeitig ist aber wichtig, daß diese Systeme einheitlich benutzt werden können und ausreichend viele gemeinsame fachliche Konzepte erkennen lassen. Denn oft wechseln Bankmitarbeiter zwischen den verschiedenen Arbeitsplätzen, gelegentlich mehrfach an einem Tag. Dies erfordert, daß den verschiedenen Anwendungssystemen ein gemeinsames Benutzungsmodell zugrunde liegt, damit Umgangsformen, die ein Benutzer an einem System erlernt hat, auf die anderen Systeme übertragbar sind. Gemeinsame Entwurfsmetaphern und -muster helfen, Anwendungssysteme integriert und einheitlich zu gestalten. Damit sind aber

3


3.3


683

nicht nur Komponenten für das Benutzungsmodell vorgegeben. Werkzeuge, Materialien, Automaten und die anderen Elemente einer Anwendung nach WAM bilden auch die konstruktiven Einheiten der Softwareentwicklung. Wir fordern, daß sich die Anwendungssysteme für die verschiedenen Einsatzkontexte durch weitgehende Kombination von Elementen, die bereits in den einzelnen Produktbereichen realisiert worden sind, zusammenstellen lassen. Als Ergebnis der Diskussion des Bankbeispiels halten wir fest: ❑ Einsatzkontexte und Produktbereiche stimmen häufig nicht

überein; sie lassen sich nicht ineinander einbetten. ❑ Ein Einsatzkontext muß oft mehrere Produktbereiche abdek-

ken. ❑ Ein Produktbereich muß in verschiedenen Einsatzkontexten

unterschiedlich präsentiert und bearbeitbar gemacht werden. ❑ Es ist sinnvoll, die fachlichen und softwaretechnischen Kom-

ponenten, die in den verschiedenen Produktbereichen konstruiert werden, in den Einsatzkontexten zu entsprechenden Anwendungssystemen kombinieren zu können.

3


3.3


684

❑ Auf der Grundlage gemeinsamer Metaphern und Entwurfs-

muster lassen sich die verschiedenen Anwendungssysteme in einer Organisation einheitlich und ähnlich gestalten. ❑ Neben den Produktbereichen stellen die Einsatzkontexte eine

zweite anwendungsfachliche Makrostruktur eines Unternehmens dar. Der Gegenstandsbereich

Wird die Struktur der Produktbereiche auf das fachliche Modell übertragen, so wird dieses in getrennte Bereiche zerlegt. Dies funktioniert nur dann problemlos, wenn sich die jeweils modellierten fachlichen Gegenstände genau einem Produktbereich zuordnen lassen. Eine solche Struktur wäre unter dem Gesichtspunkt der Softwareentwicklung, insbesondere der Aufteilung der Aufgaben auf einzelne Projekte, optimal. Unsere Projekterfahrung zeigt allerdings, daß die disjunkte Aufteilung von fachlichen Gegenständen auf die Produktbereiche nicht verwirklicht werden kann. So existieren etwa im Bankenbereich einige Überschneidungen zwischen den Bereichen Kredit- und Wertpapiergeschäft. Beide Bereiche benötigen Gegenstände wie z.B. Konto oder Betrag. Daneben gibt es Überschneidungen, die nicht auf den ersten Blick sichtbar sind, da sich Begriffe wie Kreditnehmer und Wertpapierinhaber auf denselben Kunden beziehen können.

3


3.3


685

Im letzten Abschnitt haben wir auf die Bedeutung der einheitlichen Gestaltung der unterschiedlichen Anwendungssysteme hingewiesen. Diese Einheitlichkeit muß eine technische und eine fachliche Basis haben. Es genügt nicht nur, daß sich alle Komponenten dieser Anwendungssysteme z.B. werkzeug- oder materialartig verhalten. Dahinter muß auch ein einheitliches fachliches Begriffs- und Konzeptgebäude stehen. Dies müssen wir noch jenseits der bereits diskutierten Einsatzkontexte und Produktbereiche sicherstellen, da dort ja gerade die aufgaben- und fachspezifischen Differenzierungen im Vordergrund standen. Dieses einheitliche Begriffs- und Konzeptgebäude ist noch aus einem anderen Grund wesentlich. Nur so ist eine arbeitsplatz- und produktbereichsübergreifende Arbeitsteilung und Kooperation möglich. Denn Kooperation erfordert, daß die Beteiligten zunächst einmal eine gemeinsame Sprache sprechen. Darüber hinaus funktioniert Zusammenarbeit aber nur dann, wenn auch vergleichbare Arbeitsgegenstände und -mittel vorhanden sind (vgl. [Gryczan 96]). Nur wenn ein Bankmitarbeiter z.B. ein Überweisungsformular in einer elektronischen Mappe weitergibt und dies auch auf dem elektronischen Schreibtisch des Kollegen wieder so erscheint, ist eine ungestörte Zusammenarbeit möglich. Wenn diese fachliche Gemeinsamkeit fehlt, dann sind die verschiedenen Anwendungssysteme höchstens über

3


3.3


686

technische Schnittstellen miteinander verbunden, über die dann Daten, aber keine Informationen mehr ausgetauscht werden können. In einer Bank muß in fast allen Anwendungssystemen eine Information über Kunden in aufbereiteter Form vorhanden sein. Dies heißt fachlich ein Kundengrundbild. Im Wertpapierbereich enthält dieses Grundbild die zu diesem Kunden gehörenden Depots und die darin enthaltenen Aktienbestände sowie allgemeine Informationen zum Kunden, wie seine Adresse, seine Kundennummer und sein Gesamtengagement. Für das Kundengrundbild im Kreditbereich werden keine detaillierten Informationen zu den Depots benöigt. Dort ist neben den Kreditkonten und den Daten zu den vereinbarten Krediten vorwiegend interessant, welche Sicherheiten der Kreditnehmer der Bank übereignet hat, um damit die Kredite abzusichern. Für beide Bereiche ist aber entscheidend, daß in den verschiedenen Kundengrundbildern erkennbar derselbe Kunde mit seinen relevanten für beide Bereiche gemeinsamen Informationen dargestellt ist. Zu diesen gemeinsamen Informationen zählen der Kundenname, die Kundennummer und das Gesamtengagement aller Konten. Ohne diese gemeinsame fachliche Basis könnten sich zwei Bankmitarbeiter in den verschiedenen Bereichen nicht über den Kunden verständigen. Nach dem bisherigen Stand unserer Diskussion über die Modellierung der verschiedenen Unternehmensstrukturen wird aber hier klar,

3


3.3


687

daß diese Gemeinsamkeiten eines Kunden doppelt in den beiden Produktbereichen Kreditgeschäft und Wertpapiergeschäft modelliert werden müßten. Dies ist softwaretechnisch und fachlich unbefriedigend und trägt die Gefahr von inkonsistenten Weiterentwicklungen in sich. Wir benötigen also für die Konstruktion von fachlich integrierten Anwendungssystemen eine gemeinsame fachliche Basis. Diese realisieren wir über eine eigene Modellierungseinheit, die wir Gegenstandsbereich nennen.

Gegenstandsbereich: Der Gegenstandsbereich umfaßt die fachlichen Konzepte, die grundlegend für die unterschiedlichen Produktbereiche sind. Er charakterisiert das Geschäft eines Unternehmens. Der Gegenstandsbereich bildet die fachliche und konstruktive Basis für alle Produktbereiche. Er ist eine Modellierungseinheit.

Der Gegenstandsbereich bildet die fachliche und konstruktive Basis für die unterschiedlichen Produktbereiche. Er enthält die gemeinsamen Grundbegriffe der Produktbereiche und definiert dadurch die für

3


3.3


688

die Verständigung notwendige Fachsprache sowie die gemeinsamen Arbeitsgegenstände. Konstruktiv repräsentiert der Gegenstandsbereich ein für alle Produktbereiche gemeinsames Modell. Die in diesem Modell enthaltenen Elemente und deren Beziehungen sind für alle Produktbereiche verbindlich. Dies klingt zunächst ziemlich ähnlich wie die Ansprüche, die mit einer unternehmensweiten Datenmodellierung verbunden sind. Nun ist uns wohl bewußt, daß unternehmensweite Datenmodellierung sehr problematisch ist. Gerade im Bankenbereich, um bei diesem Beispiel zu bleiben, haben sich ja Versuche, bankübergreifende, sogar internationale Daten- und Begriffsmodelle zu realisieren, als wenig erfolgreich (zumindest für die Anwender solcher Modelle) erwiesen. Um nicht mit ähnlichen Problemen konfrontiert zu werden, müssen folgende Punkte beachtet werden: ❑ Der Gegenstandsbereich muß alle Begriffe und Gegenstände

enthalten, die für eine Verständigung und Zusammenarbeit zwischen den einzelnen Produktbereichen notwendig sind. Diese Begriffe müssen in gemeinsam verwendbaren Konstruktionseinheiten repräsentiert werden. Ist der Umfang des Gegenstandsbereichs zu gering, dann ist die Verständigung zwischen den Produktbereichen entweder erschwert oder es müssen

3


3.3


689

fachliche Komponenten in den verschiedenen Produktbereichen mehrfach modelliert werden. Dies behindert die Entwicklung integrierter Anwendungssysteme. ❑ Der Gegenstandsbereich sollte in seinem Umfang minimal sein,

d.h., er sollte möglichst keine Begriffe und Gegenstände enthalten, die nur in wenigen Produktbereichen benötigt werden. Dies würde die Idee des Gegenstandsbereichs unklar machen und die konstruktiven Abhängigkeiten zwischen Gegenstandsbereich und Produktbereichen unnötig erhöhen. ❑ Die im Gegenstandsbereich enthaltenen Begriffe und Gegen-

stände sollten weitgehend als Konzepte und Abstraktionen konstruktiv realisiert werden, um keine Implementationsentscheidungen vorzugeben, die sich in den Produktbereichen als ungünstig erweisen. Entsprechend werden nur wenige Elemente des Gegenstandsbereichs »schwergewichtig«, d.h. mit implementierten Operationen und Attributen, realisiert werden. Eine der wohl wichtigsten Eigenschaften des Gegenstandsbereichs ist, daß er kein unmittelbares Vorbild im Anwendungsbereich hat. Er wird nur im Modell des Anwendungsbereichs und des Anwendungssystems

3


3.3


690

repräsentiert. Es gibt keine Organisationseinheit in einem Unternehmen, die diesen Gegenstandsbereich verkörpert. Natürlich könnte man argumentieren, daß das Unternehmen als solches diesen Gegenstandsbereich darstellt. Aber dies ist nicht konstruktiv, da wir nicht das Unternehmen als solches modellieren können. Wir sind immer nur mit konkreten Arbeitsplätzen oder Produktbereichen als Organisationseinheiten konfrontiert. Das Problem wird deutlich, wenn wir uns z.B. mit dem Gegenstand »Konto« in einer Bank beschäftigen. In fast allen Abteilungen und an fast allen Arbeitsplätzen wird mit Kunden und Konten gearbeitet. Aber es gibt, wie wir gesehen haben, sehr unterschiedliche Ansichten darüber, was Kunden und Konten charakterisiert und welche Aufgaben in welcher Form damit erledigt werden müssen. Im Fall des Kontos zeigt sich ein verschärfendes Problem. Es gibt keinen Ort in einer Bank, wo wir als Entwickler ein Konto »als solches« sehen können. Die Zeiten, in denen Konten als Eintragungen in Haupt- und Kassenbüchern existierten, sind lange vorbei. Ein Konto ist zu einem virtuellen Artefakt geworden, das in heutigen Banken letztlich nur noch rekonstruiert und verstanden werden kann, wenn wir die Art und Weise, wie an den verschiedenen Arbeitsplätzen damit gearbeitet wird, analysieren. Denn in konventioneller Banksoftware auf Großrechnern ist der fachliche Gegenstand Konto durch seine Daten an unterschied-

3


3.3


691

lichen Stellen gespeichert und wird mit einer Vielzahl von verstreuten Programmen bearbeitet. Die Modellierung eines Gegenstandsbereichs ist prinzipiell nicht problemlos. Abhilfe schafft eine geeignete Vorgehensweise. So ergibt sich die Notwendigkeit, einen eigenen Gegenstandsbereich zu bilden, nur dann, wenn mindestens zwei sich überlappende Produktbereiche mit entsprechenden Anwendungssystemen unterstützt werden müssen. Ist dies absehbar, werden die Entwickler schon bei der Konstruktion des ersten Produktbereichs durch Generalisierung potentielle Kandidaten für einen Gegenstandsbereich identifizieren und geeignet modellieren. Hier ist von den Entwicklern neben der Fähigkeit, gute objektorientierte Entwürfe zu machen, vor allem anwendungsfachliches Wissen gefordert, um vorausschauend die Gegenstände und Begriffe zu identifizieren, die in den Gegenstandsbereich wandern werden. Aus Projekterfahrungen können wir feststellen, daß bei der Modellierung eines zweiten Produktbereichs gleich mit der Entwicklung des gemeinsamen Gegenstandsbereichs begonnen werden muß. Denn nur so läßt sich sicherstellen, daß die beiden Produktbereiche genügend unabhängig voneinander sind. Gerade unter Termindruck liegt die Versuchung nahe, den zweiten Produktbereich auf der Basis des ersten zu entwickeln (s. Abbildung 3-58). Damit werden die zwei

3


3.3


692

Produktbereiche aber so miteinander verknüpft, daß Änderungen im ersten Prouktbereich unter Umständen ungewollte Auswirkungen im zweiten nach sich ziehen. Dies verhindert, daß sich beide Produktbereiche unabhängig voneinander entwickeln können. Dies war aber eine der wesentlichen Gründe für unsere Suche nach Makrostrukturen als Basis unserer Modellarchitektur.

3


3.3


693 Abb. 3-58

Produktbereich Anlagegeschäft

Problematische Konto

Girokonto

Produktbereiche Anlagegeschäft & Kreditgeschäft (neu)

Verknüpfung zweier Produktbereiche

Konto

Sparkonto

Girokonto

Sparkonto

Produktbereiche Anlagegeschäft (verändert) & Kreditgeschäft Konto

Kreditkonto

Gehaltskonto

Anlagekonto

Girokonto

Sparkonto

Kreditkonto

3


3.3


694

Für eine Bank ist der Produktbereich Anlagegeschäft bereits modelliert und ein entsprechendes Anwendungssystem wurde gebaut. Dabei wurde eine einfache Begriffshierarchie Konto erarbeitet, die durch eine Oberklasse Konto und zwei konkrete Klassen Girokonto und Sparkonto realisiert wurden (s. Abbildung 3-58). Als das Kreditgeschäft nun ebenfalls unterstützt werden soll, stellen die Entwickler fest, daß in der Klasse Girokonto schon wesentliche Merkmale eines Kreditkontos modelliert worden sind. Sie fügen in der Unterklasse Kreditkonto zum Girokonto lediglich die Verwaltung der Sicherheiten hinzu und stellen über eine Vorbedingung sicher, daß das Kreditkonto nicht in den Haben-Bereich kommt. Als sich später im Anlagegeschäft herausstellt, daß statt einer Klasse Girokonto die zwei differenzierten Klassen Anlagekonto und Gehaltskonto besser die fachlichen Begriffe und Zusammenhänge beschreiben würden, wird klar, daß diese fachlich sinnvolle Änderung ungewollte Auswirkungen auf die Anwendung im Kreditgeschäft hat. Für die schrittweise Entwicklung integrierter Anwendungssysteme ist es also von zentraler Bedeutung, daß wir für jeden neu hinzukommenden Produktbereich gleichzeitig den Gegenstandsbereich weiterentwickeln. Konzeptionelle Änderungen aufgrund eines neuen Produktbereichs sind dann wenig problematisch, wenn ein bereits im Gegenstandsbereich vorhandenes Konzept für den neuen Produktbe-

3


3.3


695

reich erweitert werden muß. Der Gegenstandsbereich muß dann im softwaretechnischen Modell des Anwendungssystems so konstruiert sein, daß er Erweiterungen seiner Konzepte zuläßt, ohne selbst verändert werden zu müssen. Dieser Forderung entspricht das von Meyer definierte Offen-Geschlossen-Prinzip (vgl. Kapitel 2.1.9, S. 44 und [Meyer 97]). Änderungen können wir nur dann nicht grundsätzlich ausschließen, wenn ein Begriff aus einem bestehenden Produktbereich jetzt als Generalisierung in den Gegenstandsbereich verschoben werden muß. Dann müssen Gegenstands- und Produktbereich modifiziert werden. Bei der Modellierung des Wertpapiergeschäfts bietet es sich an, den Gegenstandsbereich um den allgemeinen Begriff Produkt zu erweitern, um damit die allgemeinen Umgangsformen mit einem Bankprodukt zu beschreiben. Zu diesen Umgangsformen gehören etwa die Verwaltung einer Verkaufsinformation und eine Modellrechnung. Diese Generalisierung muß für die bereits modellierten Produkte Geldanlage und Kredit nachvollzogen werden. Fassen wir die Überlegungen zum Gegenstandsbereich zusammen: ❑ Der Gegenstandsbereich entspricht in seinen Begriffen und

Gegenständen dem allgemeinen Geschäft eines Unternehmens. Er repräsentiert aber eine Abstraktion über das gesamte Unter-

3


3.3


696

nehmen und hat kein konkretes Gegenstück in einer existierenden Organiationseinheit. Er wird daher nur im Modell des Anwendungssystems fachlich und technisch rekonstruiert. ❑ Der Gegenstandsbereich bildet mit seinen Konzepten die

Grundlage für die verschiedenen Produktbereiche. Er wird aber seinerseits anhand der bereits modellierten Produktbereiche entwickelt. ❑ Sollen im Gesamtsystem schrittweise neue Produktbereiche

modelliert werden, so muß auch der Gegenstandsbereich angepaßt werden. Dabei sind mögliche Rückwirkungen auf bereits vorhandene Produktbereiche zu berücksichtigen. Durch eine entsprechende Konstruktionstechnik sind die notwendigen Änderungen zu minimieren. Zusammenhang der verschiedenen Bereiche

Zur Strukturierung großer Softwaresysteme haben wir die vorhandenen Organisationsstrukturen im Anwendungsbereich analysiert. Dabei haben wir solche Unternehmen ausgewählt, die nach dem Objektprinzip organisiert sind oder deren Prozeßorientierung auf Produkte oder Dienstleistungen ausgerichtet ist.

3


3.3


697

Für diese Unternehmen haben wir als wesentliche Makrostruktur die verschiedenen Produktbereiche identifiziert. Auf der Ebene der unterschiedlichen Arbeitsplätze betrachten wir die sogenannten Einsatzkontexte. Schließlich haben wir die grundlegenden Konzepte eines Unternehmes im Gegenstandsbereich rekonstruiert. Wenn wir diese Strukturen auf die potentiellen Modellierungseinheiten übertragen, ergeben sich folgende Zusammenhänge: Der Gegenstandsbereich wird je Anwendungsbereich nur einmal modelliert. Er enthält als Konzepte die grundlegenden Begriffe und Gegenstände, die das Geschäft eines Unternehmens ausmachen. Betreibt ein Unternehmen mehrere Geschäfte (z.B. ein Krankenhaus mit klinischen Abteilungen und einer Schwesternschule), dann ist zu prüfen, ob nicht auch mehrere Gegenstandsbereiche modelliert werden müssen. Der Gegenstandsbereich wird auf der Basis mehrerer Produktbereiche rekonstruiert. Er ist als Modellierungseinheit Teil des Modells des Anwendungssystems, da er kein unmittelbares Gegenstück in einer Organsationseinheit hat. Die Produktbereiche modellieren entsprechende Einheiten der Unternehmensorganisation. Jeder Produktbereich wird als Modellierungseinheit sowohl im Modell des Anwendungsbereichs als auch im softwaretechnischen Modell repräsentiert. Als Ziel sollen diese

3


3.3


698

Modellierungseinheiten der verschiedenen Produktbereiche unabhängig voneinander sein. Die Modellierung eines neuen Produktbereichs erweitert entweder vorhandene Konzepte des Gegenstandsbereichs oder führt neue Konzepte nur für diesen Produktbereich ein. Entsprechend den unterschiedlichen Arbeitsplätzen in einem Unternehmen gibt es verschiedene Einsatzkontexte. Jeder Einsatzkontext verbindet einen Arbeitsplatz mit dem dafür geeigneten Anwendungssystem. Jeder Einsatzkontext wird im Modell des Anwendungsbereichs als Modellierungseinheit berücksichtigt. Je Anwendungssystem wird ebenfalls ein softwaretechnisches Modell erstellt. Ein Einsatzkontext kann fachlich mehrere Produktbereiche abdecken. Entsprechend werden die Anwendungssysteme im wesentlichen aus Komponenten der benötigten Produktbereiche zusammengesetzt. Am Beispiel aus dem Anwendungsbereich Bank zeigen wir, welche Komponenten in welchen Modellen angesiedelt sind (s. Abbildung 3-59). In der Bank gibt es Einsatzkontexte, die an bestimmte Arbeitsplatztypen gebunden sind, z.B. Beraterarbeitsplatz, Wertpapierspezialist oder Schalterarbeitsplatz. Dazu kommen die Selbstbedienungsterminals für Bankkunden. Auf die traditionellen Produktbereiche einer Bank sind wir schon eingegangen. Dies sind z.B. Kredit-, Anlage-, Wertpapier- und Schal-

3


3.3


tergeschäft. Allen Produktbereichen sind die Konzepte Kunde und Konto gemeinsam. Konkret verwenden sie auch alle den Gegenstand Girokonto, da hier keine spezifische Modifikation in den verschiedenen Produktbereichen erforderlich ist. Dagegen wird das Konzept Kunde etwa im Kreditbereich zum Kreditnehmer erweitert. Als wesentliche neue Umgangsform kommt die Verwaltung der Sicherheiten hinzu.

699

Abb. 3-59 Gegenstandsbereich, Produktbereiche und Einsatzkontexte in einer Bank

Beraterarbeitsplatz

Wertpapierspezialist

Selbstbedienung

Einsatzkontext

...

Produktbereich Kredit Sicherheiten

Kreditprodukte

fachliche Werte

Kreditnehmer Kreditkonto

...

Person Kunde

Produktbereich Wertpapier Depot

Chartanalyse

Dauerauftrag

...

Ein- und Auszahlungen

Wertpapierinhaber

Konto

Produktbereich Schalter

Produkt

Devisen ...

Sicherheit

3

Formularwesen

...

...

Gegenstandsbereich Bank


3.3


700

Im Gegenstandsbereich sind zunächst die bankfachlichen Werte wie Betrag, Zinssatz und Kontonummer angesiedelt. Dazu kommen elementare Konzepte wie Person und Kunde, wobei der Kunde bereits das Konzept Person erweitert. Nicht nur als Konzept, sondern bereits als konkreter Gegenstand ist hier, wie gesagt, das Girokonto angesiedelt.

3.3.2 Konzepte und Elemente einer WAM-Modellarchitektur Bisher haben wir unternehmensorganisatorische Strukturen beschrieben und die Möglichkeit aufgezeigt, diese für den Modellierungsprozeß nutzbar zu machen. Dabei sind Makrostrukturen und Modellierungseinheiten herausgekommen, die vorrangig das Modell des Anwendungsbereichs betrafen, aber auch schon Strukturen für das softwaretechnische Modell vorgaben. Wir haben aber weder die Systembasis noch die zur Programmierung verwendete Technologie oder die Handhabung und Präsentation explizit berücksichtigt. Für die Konstruktion der hier betrachteten Anwendungssysteme nach WAM muß die zugrundeliegende Softwarearchitektur die wesentlichen objektorientierten Merkmale wie Abstraktion, Polymorphie oder dynamisches Binden (vgl. Kapitel 2.1) verkörpern. Dazu haben wir allgemeingültige softwaretechnische Prinzipien wie Kohäsion und Kopplung oder das Offen-Geschlossen-Prinzip für die Komponentenbildung genannt.

3


3.3


701

Wir haben zu Beginn von Kapitel 3.3 festgestellt, daß eine Softwarearchitektur das fachliche und softwaretechnische Modell als eine Menge interagierender Komponenten organisiert und strukturiert. Diese Komponenten werden über Verbindungsstücke gekoppelt und in ihrem Zusammenspiel festgelegt. Beispiele für Verbindungsstücke sind ein Operationsaufruf an einem Objekt oder der Benachrichtigungsmechanismus zwischen Funktions- und Interaktionskomponente. Verbindungsstück: Verbindungsstücke beschreiben, wie die Komponenten einer Softwarearchitektur auf Schnittstellenebene untereinander verknüpft werden und wie sie miteinander interagieren. Zur Kopplung von Rahmenwerken werden neben einfachen Operationsaufrufen auch komplexere Verbindungsstücke, die wir als Muster beschreiben, eingesetzt.

Komponenten werden über Verbindungsstücke zu Modellierungseinheiten gruppiert. Im Rahmen einer Modellarchitektur können wir die grundsätzliche Art der Komponenten und der Verbindungstücke und

3


3.3


702

die Prinzipien ihres Zusammenspiels beschreiben. Darüber hinaus können wir Kriterien für die Auswahl von Modellierungseinheiten angeben. Es ist nicht möglich, eine Semantik der Komponenten und ihrer Verbindung anzugeben, da wir ja keinen konkreten Anwendungsbereich vorgeben. Wir werden allerdings wieder Beispiele und Muster vorstellen, die sich bei der Realisierung wesentlicher Komponenten bewährt haben. Modellarchitektur: Eine Modellarchitektur abstrahiert von den charakteristischen Merkmalen einer Menge ähnlicher Softwarearchitekturen. Sie definiert die Art der verwendeten Entwurfskomponenten, deren Verbindung und Regeln für diese Kombination. Dazu kommen Kriterien für die Zusammenstellung der Komponenten in Modellierungseinheiten sowie Anleitungen für den Entwurf und die Qualitätsbewertung einer konkreten Architektur.

Bestandteile der WAM-Modellarchitektur

Im folgenden beschreiben wir, wie eine WAM-Modellarchitektur aufgebaut ist. Als Bestandteile einer solchen Modellarchitektur lassen

3


3.3


703

sich aufgrund der Diskussion in den vorausgegangenen Abschnitten folgende Komponenten und Verbindungsstücke zusammentragen (s. Kapitel 2.3.2): ❑ Als Komponenten kommen zunächst Klassenbibliotheken

sowie Black-box- und White-box-Rahmenwerke in Frage. Denn dies sind softwaretechnische Makroelemente, die sich oberhalb der Mikrostrukturen aus Klassen und Objekten bewegen. ❑ Verbindungsstücke sind dementsprechend Entwurfsmuster,

Vererbung und Benutzt-Beziehung. Während Rahmenwerke durch alle drei Arten von Verbindungsstücken gekoppelt werden können, sind es bei Klassenbibliotheken im wesentlichen die Vererbung und Benutzung. Aufgrund softwaretechnischer Prinzipien und Projekterfahrung lassen sich folgende allgemeine Kombinationsregeln für die Entwurfskomponenten aufstellen: ❑ Rahmenwerke können über mehrere Verbindungsstücke, ins-

besondere über mehrere Entwurfsmuster, miteinander verbunden sein. Dabei ist aber auf eine Minimierung der Kopplung zu achten. Eine lose Kopplung ist einer festen vorzuziehen (vgl. Kapitel 2.1.13, S. 56).

3


3.3


704

❑ Zyklische Strukturen sollten vermieden werden, da ansonsten

die Entwicklung und Konfiguration neuer Komponenten erschwert wird (vgl. [Lakos 96]). Müssen Strukturen wechselseitig verknüpft werden, so sollte in einer Richtung eine lose Kopplung verwendet werden (vergleichbar dem Beobachtermuster zwischen Funktions- und Interaktionskomponente in Kapitel 3.2.3). ❑ Klassenbibliotheken dürfen nur als Basiskomponenten ver-

wendet werden. Sie können nicht als Ergebnis einer Kombination von Entwurfselementen entstehen. ❑ Neue Verbindungsstücke unter Verwendung von bereits exi-

stierenden Entwurfselementen dürfen nicht einfach hinzukommen. Für jede konkrete Softwarearchitektur muß ein festgelegtes und ausreichend dokumentiertes Repertoire an zulässigen Entwurfsmustern verfügbar sein. Dieses Repertoire darf nur schrittweise nach sorgfältiger Abstimmung erweitert werden, da sie sonst nicht Teil der gemeinsamen Entwicklungskultur sind.

3


3.3


705

Merkmale einer Schichtenarchitektur

Mit den Komponenten (Bibliotheken und Rahmenwerken) und den Verbindungsstücken (Benutzt-Beziehung, Vererbung, Entwurfsmuster) haben wir die Elemente für unsere Modellarchitektur zusammengestellt. Dazu haben wir einige generelle Regeln für die Organisation einer solchen Architektur genannt. Wir gehen jetzt weiter auf den Zusammenhang zwischen den organisatorischen Strukturen im Anwendungsbereich und dem Aufbau unserer Modellarchitektur ein. Abbildung 3-59 auf S. 342 zeigt eine Struktur mit drei Ebenen: Die allgemeinen fachlichen Abstraktionen des Gegenstandsbereichs, die verschiedenen parallelen Produktbereiche und darüber die Einsatzkontexte. Diese Ebenen sind nicht getrennt voneinander, sondern die jeweils höhere basiert auf den darunterliegenden. Betrachten wir diese Bereiche als Modellierungseinheiten, dann habe wir eine Struktur, die in der Softwaretechnik traditionell als Schichtenarchitektur (vgl. [Dijkstra 68]) genannt wird. Das wohl bekannteste Beispiel einer Schichtenarchitektur ist das ISO Open Systems Interconnection protocol model, kurz OSI-Referenzmodell, das einem Kommunikationsvorgang zwischen einem Sen-

3


3.3


706

der und einem Empfänger beschreibt (vgl. [McClain 91, Coulouris et al. 94]). gesendete Nachricht

Abb. 3-60

empfangene Nachricht

Das OSI-Referenzmodell

Application Layer

Anwendungsschicht

nach [Coulouris et al. 94]

Presentation Layer

Präsentationsschicht

Session Layer

Sitzungsschicht

Transportschicht

Transport Layer

Netzwerkschicht

Network Layer

Data Link Layer

Datenverbindungsschicht

Physical Layer

Physikalische Schicht

Sender

Empfänger

3


3.3


707

Dabei wird in den Schichten ausgehend von der konkreten Hardware über den Datentransport bis hin zur Anwendungsschicht stufenweise ein höheres Protokoll definiert. Dies bedeutet, daß jede Schicht ihrer nächsthöheren eine Schnittstelle anbietet, die eine Dienstleistung darstellt und von bestimmten Merkmalen der Schicht darunter »abstrahiert«. Im OSI-Referenzmodell abstrahiert jede Schicht mehr von den Merkmalen des physikalischen Datentransports und bietet eine anwendungsnähere Dienstleistung an. So arbeitet die Transportschicht (realisiert z.B. durch TCP) beim Senden und Empfangen mit Nachrichten, wogegen die Netzwerkschicht (z.B. IP) nur noch Datenpakete behandelt. Am OSI-Schichtenmodell lassen sich gut die Merkmale einer bestimmten Art von Schichtenarchitektur aufzeigen, die wir protokollbasiert nennen: ❑ Eine protokollbasierte Schichtenarchitektur gruppiert fachlich

zusammengehörige Komponenten in einer Schicht. Diese Schicht stellt ein Protokoll für die Verwendung eines möglichst kohärenten Dienstleistungsbündels zur Verfügung. ❑ Die verschiedenen Schichten sind hierarchisch organisiert. Dies

bedeutet, daß die Dienstleistungen einer Schicht den eigenen Elementen und der nächsthöheren Schicht zur Verfügung ste-

3


3.3


708

hen. Damit kennt eine Schicht nur die darunterliegende, aber idealerweise keine höhere Schicht. Wie das OSI-Referenzmodell zeigt, muß beim Empfangen einer Nachricht die jeweils untere Schicht die nächsthöhere zumindest benachrichtigen. Dies sollte durch einen minimalen Signalmechanismus geschehen. ❑ Die Hierarchie drückt eine Abstraktion zwischen den Schich-

ten aus. Die unterste Schicht ist die konkrete Basis für die Abstraktion. Höherliegende Schichten abstrahieren von den Merkmalen der tieferen, indem sie abstraktere und umfangreichere Protokolle zur Verfügung stellen. ❑ Für die Kommunikation nach »unten« ist es daher sinnvoll, die

Benutzung nur auf die unmittelbar darunterliegende Schicht zu begrenzen, da die tieferen Schichten ja genau durch anwendungsnähere Protokolle verborgen werden sollen. ❑ Jede Schicht wird meist als ein Modul realisiert, das an seiner

Schnittstelle das Protokoll anbietet, die Implementierung des Protokolls aber streng kapselt. Mit der Trennung von Protokoll und seiner Implementierung sollen Änderungen der Implementation nach dem Geheimnisprinzip keine Auswirkungen

3


3.3


709

auf die Benutzung dieser Schicht haben. Änderungen am Protokoll wirken sich allerdings auf die benutzenden Elemente in den höheren Schichten aus. Protokollbasierte Schichtenarchitektur: Eine protokollbasierte Schichtenarchitektur organisiert ein System hierarchisch. Eine Schicht stellt als Protokoll definierte Leistungen für die Elemente der eigenen oder der nächsthöheren Schicht zur Verfügung. Dabei abstrahiert jede Schicht von der darunterliegenden, in dem sie ein »höheres«, d.h. anwendungsnäheres Protokoll zur Verfügung stellt. Die jeweiligen Schichten sind meist als Module realisiert. Durch die Trennung von Protokoll und Implementierung sollen Änderungen an einer Schicht möglichst lokale Auswirkungen haben, damit eine unabhängige Entwicklung der einzlnen Schichten gewährleistet werden kann.

Wenn wir die Merkmale einer protokollbasierten Schichtenarchitektur auf unsere Modellarchitektur übertragen wollen, sind einige Entwurfsentscheidungen klar. Der Aufbau entlang protokollbasierter Schichten eignet sich besonders dann, wenn technische Komponenten oder Konzepte gekapselt und anwendungsfachlich zur Verfügung

3


3.3


710

gestellt werden sollen. Dabei lassen sich technische Komponenten in einer Schicht kapseln und als abstrakteres Protokoll für die höheren Schichten anbieten. Ebenso streben wir an, die einzelnen protokollbasierten Schichten durch strenge Kapselung weitgehend unabhängig voneinander entwickeln zu können und Änderungen lokal zu halten. Wir müssen noch klären, was eine protokollbasierte Schichtenarchitektur objektorientiert bedeutet. Zunächst dürfte aus dem bisherigen Diskussionszusammenhang klar werden, daß wir zur Realisierung der Schichten keine Module, sondern Rahmenwerke und Klassenbibliotheken verwenden. Eine Schicht organisiert diese Elemente zu einer logischen Einheit, ist aber selbst keine eigenständige softwaretechnische Komponente. Dies heißt konkret, daß eine Schicht keine eigene Schnittstelle hat, sondern nur die Schnittstellen ihrer Komponenten anbieten kann. Da diese Komponenten unserer Modellarchitektur in ihren Mikrostrukturen aus Klassen bestehen, heißt das weiter: Die Klassen einer Schicht dürfen nur Klassen der eigenen oder darunterliegender Schichten benutzen. Wir werden im weiteren begründen, daß es sinnvoll ist, die Benutzung nicht nur auf die nächst tiefere Schicht zu beschränken. Soweit es notwendig wird, eine Interaktion von Elementen einer niederen zur nächsthöheren Schicht zu realisieren, darf dies nur über eine abstrakte Schnittstelle wie beim Beobachtermechanismus (s. Ka-

3


3.3


711

pitel 3.2.3) geschehen. Dabei muß allerdings das Konzept des Beobachtermechanismus (mit den abstrakten Klassen Beobachter und Beobachteter) in einer Schicht angeordnet sein. Nur die Objekte, die dieses Muster zur Laufzeit realisieren, können dann verschiedenen Schichten angehören. Da sie ja nur mit dem Typ ihres abstrakten Mechanismus bekannt sind, entsteht keine ungewollte Abhängigkeit zwischen Schichten. Mit der protokollbasierten Schichtenarchitektur haben wir aber die Möglichkeiten der Objektorientierung noch nicht ausgereizt. Wie wir sagten, ist diese Architektur durchaus mit den Mitteln der modularen Programmierung zu realisieren. Wir wollen im folgenden betrachten, wie wir das Konzept von Generalisierung und Spezialisierung auf eine objektorientierte Schichtenarchitektur übertragen können und wie sich das mit einer protokollbasierten Schichtenarchitektur verträgt. Generalisierung und Spezialisierung werden bekanntlich objektorientiert durch die Vererbungsbeziehung ausgedrückt. Dies ist für die Klassen innerhalb einer Schicht offensichtlich. Was bedeutet dies aber, wenn die Oberklasse und ihre Unterklassen in unterschiedlichen Schichten sind? In Abbildung 3-61 ist ein vereinfachter Ausschnitt aus einer objektorientierten Schichtenarchitektur mit dem Produktbereich An-

3


3.3


712

lagegeschäft und dem bankfachlichen Gegenstandsbereich sowie drei Klassen dargestellt. Aufgrund unserer Diskussion in Kapitel 3.3.1 ist klargeworden, daß der Gegenstandsbereich die Kernabstraktionen eines Unternehmens enthält, die in den jeweiligen Produktbereichen spezialisiert und dann im jeweiligen Einsatzkontext geeignet repräsentiert werden. Wenn wir für die objektorientierte Schichtenarchitektur die Ausrichtung der protokollbasierten beibehalten, dann liegt der Gegenstandsbereich als Basis »unter« dem jeweiligen Produktbereich und die anwendungsnahen Einsatzkontexte liegen darüber. Auf der Ebene der Klassen ist im Beispiel die Klasse Konto im Gegenstandsbereich angesiedelt. In der Schicht des Produktbereichs sind davon die Klassen Anlagekonto und Sparkonto abgeleitet. Dies ist konzeptionell im Sinne unserer bisherigen Diskussion; ungewöhnlich ist nur die Darstellung, in der Ober- und Unterklassen auf den Kopf gestellt sind.

3


3.3


Produktbereich Anlagegeschäft Anlagekonto

713 Abb. 3-61 Schichtenarchitektur und

Sparkonto

Vererbung

Konto Gegenstandsbereich Bankgeschäft

Als Ergebnis halten wir fest: Es ist sinnvoll, in einer objektorientierten Schichtenarchitektur Vererbung über Schichten hinweg zu erlauben. Dabei spezialisieren die Konzepte in einer höheren, d.h. anwendungsnäheren Schicht die generellen Konzepte einer unteren. Die Frage, ob Vererbung zwischen den Schichten einer Architektur sinnvoll ist, kann auch noch weitergehend mit Blick auf das in Kapitel 2.1.9 diskutierte Offen-Geschlossen-Prinzip begründet werden. Angewandt auf eine objektorientierte Schichtenarchitektur bedeutet dieses Prinzip, daß eine Schicht mit ihren Elementen offen für Erweiterungen, aber gleichzeitig in ihrer Verwendung geschlossen sein soll.

3


3.3


714

Diese Forderung läßt sich dann in einer objektorientierten Schichtenarchitektur erfüllen, wenn die Vererbung zwischen Schichten zulässig ist. Dadurch kann ein allgemeines Konzept wie Konto im Gegenstandsbereich als »geschlossene« Klasse zur Verfügung gestellt werden. Ihre jeweils notwendigen Spezialisierungen werden dann über Vererbung in die höhere Schicht des Produktbereichs verlagert. Realisieren wir diese Generalisierungs- und Spezialisierungsbeziehung zwischen den Klassen verschiedener Schichten mit den üblichen Konstruktionsmitteln abstrakte Klasse, Vererbung, Polymorphie und dynamisches Binden, dann tritt ein interessanter Effekt gegenüber einer protokollbasierten Schichtenarchitektur auf: Objekte, die Exemplare von Klassen einer übergeordneten Schicht sind, werden von Objekten einer untergeordneten Schicht verwendet. Die Oberklasse in einer untergeordneten Schicht definiert in unserem Objekt-Metamodell (s. Kapitel 2.1.11) einen Typ. An Variablen dieses Typs lassen sich zur Laufzeit polymorph Objekte eines Subtyps, also einer Unterklasse, zuweisen. Diese Unterklasse kann dabei Element einer übergeordneten Schicht sein. Die Operationen, die an den Objekten aufgerufen werden, sind dabei durch die Oberklasse definiert. Soweit die Vererbungshierarchie eine Typhierarchie darstellt, ist diese Realisierung des Offen-Geschlossen-Prinzips problemlos.

3


3.3


715

In Abbildung 3-62 ist das Offen-Geschlossen-Prinzip an einer Variante des Bankbeispiels dagestellt. Im Gegenstandsbereich verwaltet eine Klasse Kunde die zu einem Kunden gehörenden Konten in einer Liste. Die Konten sind dabei vom generalisiertem Typ Konto, Abb. 3-62

Produktbereich

Das Offen-GeschlossenAnlagekonto

Sparkonto

GibSaldo()

GibSaldo()

Einzahlen()

Einzahlen()

Auszahlen()

Auszahlen()

BerechneZinsen()

BerechneZinsen()

Kunde GibGesamtEngagement() List Konten

•

Prinzip am Beispiel von Kunde und Konto

Konto GibSaldo() Einzahlen() Auszahlen() BerechneZinsen()

Für alle Konten k do b := b + k -> GibSaldo() return b;

Gegenstandsbereich

3


3.3


716

der als abstrakte Klasse realisiert wurde. In einem Produktbereich werden die beiden Subtypen Anlagekonto und Sparkonto definiert. Diese sind als Unterklassen der Klasse Konto realisiert. Die Operation GibGesamtEngagement der Klasse Kunde wird implementiert, indem an jedem Kontoobjekt, das in der Liste enthalten ist, die Operation GibSaldo aufgerufen und das Ergebnis aufsummiert wird. Die Vererbungsbeziehung zwischen der Klasse Konto und den Klassen Anlagekonto sowie Sparkonto bildet eine Typhierarchie. Denn an allen Stellen, an denen in der Klasse Kunde ein Objekt vom Typ Konto erwartet wird, kann ein Objekt vom Typ Anlagekonto oder Sparkonto verwendet werden. Das Objektdiagramm in Abbildung 3-63 zeigt, daß das Kundenobjekt im Gegenstandsbereich angesiedelt ist. Es greift über die Liste auf Kontoobjekte zu, die im Produktbereich erzeugt wurden. Damit wird die Semantik der Kunden-Operation GibGesamtEngagement letztlich durch die jeweilige Realisierung der aufgeschobenen KontoOperation GibSaldo in den Unterklassen des Produktbereichs definiert. Diese Veränderung funktioniert ebenso, wenn die Klasse Konto vollständig implementiert ist und die entsprechenden Operationen in den Unterklassen überschrieben sind.

3


3.3


Produktbereich

717 Abb. 3-63 Ein Objektdiagramm für

einAnlagekonto

einSparkonto

120.000

50.000

1,5%

3,2%

Kunde und Konto

einKunde Konten

eineListe

Erika Mustermann

Gegenstandsbereich

Wir können also durch die Vererbung über Schichten hinweg eine Schicht »geschlossen« für die Verwendung anbieten und sie gleichzeitig für Erweiterungen in höheren Schichten »öffnen«.

3


3.3


718

Schichten, Rahmenwerke oder Klassen, lassen sich durch den Mechanismus der Vererbung nicht beliebig an veränderte Umstände anpassen. Denn Erweiterungen müssen in den Entwurfselementen explizit vorgesehen werden. Dazu bilden wir über die Menge der denkbaren Erweiterungen eine oder mehrere Abstraktionen, die wir geeignet realisieren. Eine häufige Form der Realisierung sind abstrakte Klassen. Wir werden die Diskussion darüber nochmals aufgreifen und zeigen, welche Festlegungen in den Schichten unserer Modellarchitektur getroffen wurden. Schicht in der WAM-Modellarchitektur: Eine Schicht organisiert die softwaretechnischen Komponeten einer Modellarchitektur zu einer fachlich und technisch motivierten Entwurfs- und Kontruktionseinheit. Eine Schicht hat selbst keine Schnittstelle und keine Beziehung zu anderen Schichten; Schnittstellen und Beziehungen über Verbindungsstücke haben nur die enthaltenen Komponenten. Die verschiedenen Schichten einer Modellarchitektur sind hierarchisch aufgebaut. Je nach Sichtbarkeit und Verwendungszusammenhang sprechen wir von einer protokollbasierten oder objektorientierten Schicht. Als Komponenten innerhalb einer Schicht verwenden wir Klassenbibliotheken und Rahmenwerke. Die Verbindungsstücke sind durch Konstruktionsmuster, Benutzt-Beziehung oder Vererbung realisiert.

3


3.3


719

Vererbung, Polymorphie und dynamisches Binden stellen nur eine Möglichkeit dar, das Offen-Geschlossen-Prinzip technisch zu realisieren. Änderungen und Erweiterungen lassen sich z.B. auch durch Callback-Methoden, die durch Funktionszeiger verwirklicht werden können, umsetzen. Eine andere Möglichkeit stellen reflexive Architekturen dar, die es wie etwa beim Smalltalk-System erlauben, Komponenten zur Laufzeit zu verändern. Eine weiteres, für uns wichtiges Mittel der Veränderung haben wir mit dem Rollenkonzept vorgesehen, das wir in Kapitel 3.3.4 beschreiben. Durch das Rollenkonzept können wir konzeptionell und anwendungsfachlich Gegenstände zur Laufzeit dynamisch verändern – dies wird softwaretechnisch allerdings mit den Mitteln der Vererbung und Polymorphie realisiert.

Das Offen-Geschlossen-Prinzip einer objektorientierten Schichtenarchitektur: Vererbung, Polymorphie und dynamisches Binden überbrücken den Widerspruch zwischen Offen- und Geschlossenheit von Komponenten. In Schichtenarchitekturen mit zulässiger Vererbung zwischen Schichten lassen sich daher vorhergesehene Erweiterungen an einer Schicht auch in übergeordneten Schichten realisieren.

3


3.3


720

Wir diskutieren jetzt, wie sich eine objektorientierte Schichtenarchitektur mit einer protokollbasierten zusammenbringen läßt. Aus den gerade angestellten Überlegungen wird deutlich, daß die benachbarten Schichten einer objektorientierten Architektur nach dem Generalisierungsprinzip aufgebaut sind. Wir konnten daher sagen, daß die Schicht des Gegenstandsbereichs allgemeine Konzepte enthält, die in den Produktbereichen spezialisiert werden können. Dieses Verhältnis trifft zwischen den Schichten einer protokollbasierten Architektur eher selten zu. Die Transportschicht des OSI-Referenzmodells benutzt die Netzwerkschicht mit ihren Datenpaketen, um ganz andere abstraktere Konzepte, nämlich Nachrichten, für die nächsthöhere Schicht zur Verfügung zu stellen. Wichtig ist auch die Frage der Durchsichtigkeit von Schichten. Protokollbasierte Schichten sind in ihrer Benutzung opak, d.h., sie zeigen ein Protokoll, verbergen aber die darunterliegenden Schichten, da sie von deren Realisierung abstrahieren. Objektorientierte Schichten sind hingegen nach dem Prinzip von Generalisierung und Spezialisierung eher transparent im Sinne von »durchscheinend« aufgebaut. Hier sollen tiefere Schichten ja gerade für höhere Schichten sichtbar sein, damit der Entwickler entscheiden kann, ob er vorhandene Konzepte, soweit sie als instantiierbare Klassen vorliegen, benutzen kann oder wo eine Spezialisierung im Klassenbaum ansetzen muß.

3


3.3


721

Konto

Abb. 3-64

GibGesamtEngagement()

GibSaldo()

Die objektorientierte

List Konten

Einzahlen()

Schicht Gegenstands-

Auszahlen()

bereich benutzt die

Kunde

Gegenstandsbereich

BerechneZinsen()

protokollbasierte Schicht Systembasis

List

Systembasis

GetFirst() GetNext()

Insofern ist es konzeptionell und konstruktiv problematisch, in einer Schicht beide Schichtarten zu vereinigen. Eine einfache Lösung besteht darin, daß die objektorientierten Schichten getrennte protokollbasierte Schichten benutzen, soweit deren Dienstleistungen verwendet, aber »nach oben« gekapselt werden sollen. In Abbildung 3-64 benutzt die Klasse Kunde des Gegenstandsbereichs zur Realisierung der Dienstleistung GibGesamtEngagement() die generische Klasse List , die als Teil einer CollectionBibliothek in der Schicht Systembasis zur Verfügung gestellt wird. Zwischen Gegenstandsbereich und Systembasis gibt es dabei nur Protokollverwendung aber keine Generalisierungsbeziehung. 3


3.3


722

Der Nachteil der einfachen Lösung ist offenbar, daß eine Schicht, die Konzepte repräsentiert, unmittelbar auf eine technische Basisschicht zugreift. Jede Veränderung am Protokoll dieser Basis schlägt auf die Konzeptschicht durch. Objektorientierte Techniken erlauben eine elegantere Lösung als die direkte Benutzung. Das Brückenmuster (s. [Gamma et al. 96]) eignet sich beispielsweise gut, um ein technologisches Konzept von seiner technischen Realisierung zu trennen. Damit ergibt sich die Möglichkeit, eine fachliche konzeptionelle Schicht, wie den Gegenstandsbereich, auf eine softwaretechnisch konzeptionelle Schicht, wie den Technologiebereich, zugreifen zu lassen und die eigentliche Implementation der technologischen Konzepte in die Schicht der Systembasis zu verlagern. Damit verhält sich die Systembasis, obwohl dort objektorientierte Konstruktionstechniken verwendet werden, nach außen gegenüber dem Technologiebereich wie eine protokollbasierte Schicht. Oft ist eine klare Trennung dieser beiden Konzepte in der Praxis aber nicht einfach. Dies liegt in der Art, wie heute Klassenbibliotheken oder technische Rahmenwerke realisiert sind. So erfordern viele GUIRahmenwerke eine gemeinsame Wurzelklasse Object. Diese muß im Regelfall von allen Klassen geerbt werden, die mit Oberflächenelementen interagieren. Gleichzeitig wird man für viele objektorientierte Schichten eine Klasse Object haben wollen, die ein Metaobjekt-Proto-

3


3.3


723

koll enthält. Hier stellt sich also die Frage, ob eine oder zwei Klassen Object im System vorliegen sollen, wie dann die erste, rein technisch bedingte, »verpackt« werden kann usw. Im konkreten Fall sind also pragmatische Kompromisse erforderlich, die aber nichts an der grundlegenden Unterscheidung der beiden Schichtenarten für eine Modellarchitektur ändern. Wir haben das Bankenbeispiel von Abbildung 3-64 in Abbildung 3-65 so verändert, daß die Klasse Kunde jetzt auf das abstrakte Konzept und Protokoll der Klasse Behaelter im Technologiebereich zugreift. Diese Klasse ist über ein Brückenmuster mit der Wurzelklasse Collection einer Implementationshierarchie verbunden.

3


3.3


724 Abb. 3-65

Kunde

Konto

Entkopplung eines


GibSaldo() Einzahlen()

Protokolls von seiner

Behälter Konten

Gegenstandsbereich

Auszahlen()

Implementierung über ein

BerechneZinsen()

Brückenmuster

Technologiebereich Behaelter GibErstes() GibNaechstes()

Systembasis

BehaelterImpl

Collection

Brückenmuster

GetFirst() GetNext()

DynamicColl

StaticColl

GetFirst()

GetFirst()

GetNext()

GetNext()

Die Drei-Schichten-Architektur

Auf der Suche nach einer WAM-Modellarchitektur für große interaktive Anwendungssysteme liegt es nahe, sich an bewährten existieren-

3


3.3


725

den Architekturen auszurichten. Wir haben bisher die Elemente einer solchen Modellarchitektur zusammengetragen. Im letzten Abschnitt wurde deutlich, daß vom grundlegenden Aufbau her nur eine Schichtenarchitektur in Frage kommt. Im folgenden Abschnitt werden wir deshalb die aktuell verbreitetste Schichtenarchitektur vorstellen und auf ihre Eignung prüfen. In der Literatur und in der Praxis wird immer wieder eine Architektur herausgestellt, die im Umfeld von Client/Server-Anwendungen »Three Tier Architecture« genannt wird. Sie unterteilt ein Softwaresystem in die Schichten Präsentationsschicht, funktionale Schicht und Datenschicht. Die Präsentationsschicht ist für die grafische Darstellung einer Anwendung verantwortlich. In der funktionalen Schicht wird die Anwendungslogik implementiert. Die unterste Datenschicht repräsentiert die Daten und bildet gleichzeitig die Schnittstelle zu einer eventuell eingesetzten Datenbank (vgl. [Cook & Daniels 94, Tracz 95]). Häufig werden die einzelnen Schichten als eigene Prozesse, teils auf separaten Computern, realisiert. Die Präsentationsschicht übernimmt die Rolle eines Clients, die funktionale Schicht spielt die Rolle eines Servers für die Benutzungsschnittstelle und die eines Clients in Verbindung mit den Datenobjekten. Die Datenschicht ist nur Server.

3


3.3


726 Abb. 3-66

Präsentationsschicht (Client)

Eine Drei-SchichtenArchitektur

funktionale Schicht (Server / Client)

Datenschicht (Server)

Eine Drei-Schichten-Architektur erfüllt eine unserer Forderungen an eine Schichtenarchitektur: Elemente dürfen nur auf Elemente der eigenen oder einer tieferen Schicht zugreifen. Eine hierarchische Organisation, die der im OSI-Schichtenmodell vorhandenen Abstraktion von der Physik hin zur fachlichen Anwendung vergleichbar wäre, ist aber nicht vorhanden. Obwohl dies oft behauptet wird, erfüllt eine derartige Architektur auch nicht die Forderung, daß Änderungen möglichst schichtenlokal

3


3.3


727

bleiben sollen. So ziehen Änderungen an der Benutzungsschnittstelle fast immer entsprechende Änderungen an der fachlichen Funktionalität und den Datenobjekten nach sich. Denn neu zu präsentierende Informationen führen zu neuen Attributen in den Datenobjekten. Fachliche Änderungen in der Handhabung des Systems, die etwa durch neue Menüeinträge repräsentiert werden, bedingen Erweiterungen an der funktionalen Schicht. Im Gegenzug führen Änderungen an den Datenobjekten ihrerseits zu Anpassungen an der Präsentation, da beispielsweise hinzugekommene Attribute meist an der Benutzungsschnittstelle darzustellen sind. Die entstandenen Schichten sind demnach in keiner Richtung wirklich unabhängig voneinander und sie können kaum getrennt entwickelt werden. Die drei Schichten zerlegen demnach ein Anwendungssystem auch nicht in unabhängige Modelle oder Makrostrukturen. Trotzdem ist es eine übliche Vorgehensweise bei dieser Architektur, die Benutzungsschnittstelle, die Funktionalität und die Datenobjekte getrennt voneinander zu entwickeln. Dies führt in Anwendungssystemen oft dazu, daß die fachliche Funktionalität softwaretechnisch als reine Datenobjekte abgebildet wird, wobei dann große Teile der fachlichen Dynamik implizit in der Oberflächenkomponente realisiert werden. Architekturen dieser Art sind schwer verständlich und kaum weiterentwickelbar (vgl. [Bäumer et al. 96]).

3


3.3


728

Eine Drei-Schichten-Architektur schließt Vererbung zwar nicht grundsätzlich aus, aber auf Grund fehlender »Ist-ein«-Beziehungen (s. Kapitel 2.1.6) ist dies zwischen den einzelnen Schichten kaum möglich. So macht es wenig Sinn, Klassen der funktionalen Schicht als Unterklassen der Klassen von Datenschicht zu bilden. Analog verhält es sich mit der Präsentationsschicht und der funktionalen Schicht. Probleme der Drei-Schichten-Architektur: Eine an der Dreiteilung in Benutzungsschnittstelle, fachliche Funktionalität und Datenobjekte ausgerichteten Drei-Schichten-Architektur eignet sich nicht, große Anwendungssysteme in getrennte Modellierungseinheiten zu zerlegen. In dieser Architektur werden die Kontexte des Anwendungsbereichs, der verwendeten Technik und der Handhabung und Präsentation vermischt. Vererbung zwischen den Schichten ist auf Grund fehlender Generalisierungsbeziehungen kaum möglich. Die Schichten lassen sich daher nicht nach dem Offen-Geschlossen-Prinzip erweitern.

Die Drei-Schichten-Architektur ist von ihrem Charakter her also eine protokollbasierte Schichtenarchitektur. Das aus unserer Sicht wesent-

3


3.3


729

liche Problem besteht in der Vermischung dreier Kontexte – anwendungsfachliche Modellierung, Handhabung und Präsentation sowie der softwaretechnischen Realisierung. Wir haben in Kapitel 2.5.2 darauf hingewiesen, daß wir diese Kontexte in unserer Modellarchitektur soweit voneinander trennen wollen, daß eine weitgehend unabhängige Entwicklung dieser Kontexte möglich wird. Die genauere Betrachtung zeigt also, daß die verbreitete Drei-Schichten-Architektur nicht geeignet ist, die Grundlage für eine allgemeine WAM-Modellarchitektur zu bilden. Ihre Eignung als System bzw. Prozeßarchitektur soll durch die Diskussion allerdings nicht kritisiert werden. Als Grundlage besser geeignet ist da schon eine Architektur, wie sie bei ET++ gewählt worden ist (vgl. [Weinand & Gamma 95, Bäumer 98]). Die bisherigen Ergebnisse werden im folgenden Abschnitt zu einem Vorschlag für eine WAM-Modellarchitektur zusammengetragen.

3.3.3 Die WAM-Modellarchitektur Wir fassen jetzt zusammen, welche Gesichtspunkte und Kriterien wir bisher für eine WAM-Modellarchitektur im Bereich großer interaktiver Anwendungssysteme herausgearbeitet haben. Dazu orientieren wir uns an den Kontexten der Softwareentwicklung aus Kapitel 2.5.2 und ordnen diesen Kontexten die Elemente einer Modellarchitektur zu (s. Abbildung 3-67).

3


3.3


730 Abb. 3-67


Die Kontexte der Softwareentwicklung

Bereich Handhabung & Präsentation

bezogen auf die Modellarchitektur

Leitbilder Entwurfsmetaphern fachliche Begriffshierarchie ObjektMetamodell

Einsatzkontext Produktbereiche Gegenstandsbereich

Anwendungsbereich

Systembasis Technologiebereich

verwendete Technik

Wir haben im vorausgegangenen Abschnitt einige generelle Prinzipien einer Schichtenarchitektur zusammengestellt:

3


3.3


731

❑ Unsere Modellarchitektur wird als Schichtenarchitektur auf-

gebaut. Dabei sollen nach Möglichkeit protokollbasierte und objektorientierte Schichten voneinander getrennt werden. ❑ Protokollbasierte Schichten kapseln die Realisierung von

Dienstleistungen, die für die höheren Schichten angeboten werden. Soweit protokollbasierte Schichten selbst hierarchisch angeordnet werden, sind die Protokolle der höheren Schichten anwendungsnäher und abstrahieren von der Realisierung der Dienstleistungen in den niederen Schichten. ❑ Objektorientierte Schichten sind durch Vererbungs- und

Benutzt-Beziehungen miteinander verbunden. Auch hier sind die höheren Schichten anwendungsnäher als die niederen, allerdings in dem Sinne, daß sie Konkretisierungen und Spezialisierungen der Konzepte der niederen Schichten realisieren. Vererbt wird nur innerhalb einer Schicht und von den niederen zu den höheren Schichten. Vererbung kann dabei über mehr als eine Schichtgrenze hinweggehen oder eine Schicht überspringen. Ähnliches gilt umgekehrt für die Benutzt-Beziehung, die immer innerhalb (einer Modellierungseinheit) einer Schicht und von einer höheren Schicht auf eine niedere geht.

3


3.3


732

In Kapitel 2.5.2 haben wir die Kontexte der Softwareentwicklung genannt, die auf die verschiedenen Modelle und damit auch auf das Modell des Anwendungssystems einwirken. In Kapitel 3.3.1 haben wir die Makrostrukturen einer Organisation als Kandidaten für mögliche Modellierungseinheiten identifiziert. Dies läßt sich folgendermaßen für unsere Zwecke auswerten: ❑ Die zur Konstruktion eines Softwaresystems verwendete Tech-

nik zerfällt in eine Systembasis und die verwendete Technologie. Diese beiden Schichten stellen als Grundlage sicher, daß die anwendungsfachlich in verschiedenen Bereichen entwickelten Komponenten technisch kombiniert und integriert werden können. Dazu muß das in Kapitel 2.1 vorgestellte ObjektMetamodell in diesen Schichten um die Teile ergänzt werden, die nicht schon in der eingesetzten Programmiersprache vorhanden sind. ❑ Die Technologie umfaßt elementare Konzepte (wie Konstruk-

tionsmuster), Modelle der verwendeten Technik (wie Persistenz) und allgemein verwendbare softwaretechnische Gegenstände. Diese stehen für die Spezialisierung und Verwendung allen anwendungsfachlichen Schichten zur Verfügung. Eine Architektur muß die Technologieschicht geeignet mit der Systembasis verbinden und für die anwendungsfachlichen Schichten als Basis der Implementation bereitstellen.

3


3.3


733

❑ Die Systembasis kapselt als protokollbasierte Schicht alle tech-

nischen Komponenten, die für die Realisierung des Anwendungssystems und seine Anbindung an existierende Systeme notwendig sind. ❑ Handhabung und Präsentation bestimmen den möglichen

Umgang mit dem Anwendungssystem. Sie orientieren sich in unserem Ansatz an dem entsprechenden Leitbild und seinen Entwurfsmetaphern. Die konstruktive Umsetzung geschieht über Entwurfsmuster. Diese sollen als eigene Schicht zur Verfügung gestellt werden. Da hier sowohl allgemeine Konzepte (z.B. Kopplung zwischen Werkzeug und Material) als auch ausformulierte Gegenstände (z.B. Ordner) repräsentiert werden, muß dies eine objektorientierte Schicht sein. ❑ Die Strukturen des Modells der Anwendungssoftware sollen

an den Strukturen des Anwendungsbereichs orientiert sein. Dies bedeutet zunächst, daß die fachliche Begriffshierarchie des Anwendungsbereichs im technischen Modell abgebildet werden muß. Neben diesen Mikroelementen muß sich die in Kapitel 3.3.1 erarbeitete Makrostruktur von Produktbereichen und Einsatzkontexten daher in den Schichten der Modellarchitektur widerspiegeln. Einsatzkontexte benutzen im wesent-

3


3.3


734

lichen die Gegenstände und Konzepte der Produktbereiche; allerdings sind in der Praxis durchaus Generalisierungsbeziehungen festzustellen. Daher werden sie meist als objektorientierte Schichten abgebildet. ❑ Das Konzept des Gegenstandsbereichs, als fachliche Basis der

verschiedenen Produktbereiche, garantiert die fachliche Integration von Komponenten unterschiedlicher Produktbereiche in verschiedenen Anwendungssystemen. Der Gegenstandsbereich enthält die grundlegenden Generalisierungen für die Produktbereiche. Damit Änderungen, die aus Sicht eines Produktbereichs am Gegenstandsbereichs notwendig erschienen, nicht zu Anpassungsschwierigkeiten in anderen Produktbereichen führen, muß der Gegenstandsbereich geschlossen aber gleichzeitig für Erweiterungen offen sein. Der Gegenstandsbereich muß daher als objektorientierte Schicht realisiert werden. Damit ist die Grundstruktur unserer Modellarchitektur charakterisiert. Genaugenommen müßten wir von einem Modell der Modellarchitektur sprechen. Dies bezieht sich auf die gesamte statische Struktur, die bei der Entwicklung von Anwendungssystemen nach WAM vorhanden sein sollte.

3


3.3


735 Abb. 3-68

Einsatzkontextschicht

Die Schichten der WAM-Modellarchitektur Produktbereichsschicht

Gegenstandsbereichsschicht

Handhabungs- und Präsentationsschicht Technologieschicht Systembasisschicht

Im folgenden verdeutlichen wir die verschiedenen Schichten und ihr Zusammenspiel. Einen schematischen Überblick gibt Abbildung 3-68. Die Systembasisschicht realisiert die in Kapitel 2.5.1, S. 156f. identifizierte Systembasis. Sie enthält damit alle Schnittstellen zu den vorgegebenen (vorhandenen) Komponenten. Die Komponenten selbst sind über Black-box-Rahmenwerke und Klassenbibliotheken gekapselt und für die darüberliegenden Schichten nicht sichtbar. In dieser Schicht werden z.B. folgende Dienstleistungen angeboten:

3

Systembasisschicht


3.3


736

❑ Kapselung von Betriebs- und Fenstersystem, einer eventuell

eingesetzten Client/Server-Middleware oder persistenter Datenspeicher, wie etwa relationale und hostbasierte Datenbanken sowie elektronische Archive. ❑ Allgemeine Komponenten zur objektorientierten Konstruktion

wie etwa Container-Klassen, einen Garbage Collector oder Serialisierungsmechanismen zur Transformation von Objektgeflechten in flache Strukturen und zu deren umgekehrter Erzeugung (vgl. Kapitel 3.3.4). Aus technischen Gründen wird es oft erforderlich sein, hier auch ein Metaobjekt-Protokoll anzusiedeln. Die Rahmenwerke und Klassenbibliotheken dieser Schicht sind dabei vollkommen unabhängig von einem speziellen Anwendungsbereich. Sie können daher zur Konstruktion verschiedenster interaktiver Anwendungssysteme eingesetzt werden. Da die einzelnen Komponenten dieser Schicht meist Fremdprodukte und Standardsoftware kapseln, ist hier mit Änderungen zu rechnen. Entsprechend muß diese Schicht besonders sorgfältig protokollorientiert realisiert werden. Die verschiedenen Protokolle sind allgemein zu halten, so daß ein möglicher Austausch der realisierenden Komponente keine Auswirkungen hat.

3


3.3


737

Benutzt werden die Komponenten dieser Schicht von allen höherliegenden Schichten, insbesondere von der Technologieschicht. Die Technologieschicht vergegenständlicht die Konzepte, die in Kapitel 2.5.1, S. 157 unter dem Begriff Technologie subsummiert wurden. Hier sind also alle Modelle der verwendeten Technik zusammengefaßt. Das Verhältnis zwischen dieser Schicht und der Systembasis wird durch das häufig verwendete Brückenmuster charakterisiert. Während sich die verschiedenen Schnittstellen von Implementationskomponenten in der Systembasisschicht befinden, werden hier die technologisch allgemeineren Konzepte versammelt. Diese Technologieschicht besteht größtenteils aus White-box-Rahmenwerken, die vereinzelt um erweiterbare Black-box-Rahmenwerke ergänzt werden, um bereits vorgefertigte Standardlösungen anzubieten. Innerhalb dieser Schicht befinden sich z.B.:

Technologieschicht

❑ ein Rahmenwerk zum Speichern und Laden von Objekten in

und aus einem Persistenzmedium, d.h. ein allgemeines Datenhaltungskonzept, ❑ ein Rahmenwerk zur Kommunikation mit anderen Umgebun-

gen oder Prozessen, d.h. ein allgemeines Kommunikationskonzept, ❑ ein Rahmenwerk zur Entwicklung fachlicher Werte (s. Kapitel

3.2.8).

3


3.3


738

Auch diese Schicht kann weitgehend anwendungsunspezifisch wiederverwendet werden. Allerdings ist hier schon eine bestimmte Zusammenstellung von technologischen Konzepten vorgegeben, die den Charakter der zu entwickelnden Systeme festlegen. So wird mit dem Persistenzkonzept und der gewählten Kommunikationsart der Bereich von vernetzten Arbeitsplatzsystemen mit heterogenen Datenhaltungssystemen ins Auge gefaßt. Die Schicht, in der Handhabung und Präsentation festgelegt werden, enthält sowohl Konzepte als auch konkrete Gegenstände. Hier werden das jeweilige Leitbild und seine Entwurfsmetaphern konstruktiv beschrieben. Sie ist damit eng an den WAM-Ansatz gebunden. Da hier Werkzeuge, Materialien, Automaten und andere Metaphern den Umgang mit interaktiver Anwendungssoftware bestimmen, ist die Repräsentation dieser Grundkomponenten in einer eigenen Schicht sinnvoll. Dazu gehören

Handhabungs- und Präsentationsschicht

❑ der jeweils gewählte Umgebungsbegriff mit elektronischem

Schreibtisch oder anderen Ortsbegriffen, ❑ der Umgang mit Strukturierungselementen (Behältern, Map-

pen und Stapeln) zur Organisation des Arbeitsplatzes, ❑ Standardimplementierungen der Entwurfsmuster für Werk-

zeug, Material und Automaten,

3


3.3


739

❑ Anbindung der Werkzeuge an das Fenstersystem über Inter-

aktionstypen und ❑ Implementierungen von generischen Werkzeugkomponenten

wie Auflister. Diese Schicht ist noch nicht an einem konkreten Anwendungsbereich orientiert und kann daher für alle Systeme verwendet werden, die dem gewählten Leitbild und den Entwurfsmetaphern entsprechen. Wird allerdings ein ganz anderer Anwendungstyp, etwa eine Datenbankanwendung, entwickelt, dann steht diese Schicht natürlich zur Disposition und wird ggf. durch eine datenbankspezifische Schicht ersetzt. Die Handhabungs- und Präsentationsschicht greift auf die Technologieschicht und partiell auf die Systembasisschicht zu. Die Rahmenwerke dieser Schicht werden weitgehend als White-box-Rahmenwerke verwendet. In unserer Terminologie handelt es sich hier also um eine objektorientierte Schicht. Die Gegenstandsbereichsschicht realisiert das Konzept des in Kapitel 3.3.1, S. 335ff. eingeführten Gegenstandsbereichs. Wie beschrieben werden hier die Kernkonzepte aus den verschiedenen Produktbereichen zusammengeführt. Offensichtlich können diese Generalisierungen nur als White-Box-Rahmenwerke konstruiert werden. Daneben

3

Gegenstandsbereichsschicht


3.3


740

wird es einzelne Gegenstände geben, die so universell im Anwendungsbereich eingesetzt werden, daß sie bereits in dieser Schicht realisiert werden können. Im Bankbereich kann das beispielsweise die Klasse Girokonto sein. Ein weiterer Kandidat für diese Schicht sind die in Kapitel 3.2.8 beschriebenen Fachwerte. Da die Fachwerte zwar anwendungsspezifisch aber innerhalb eines Anwendungsbereichs »universell« sein sollen, gehören sie in den Gegenstandsbereichs. Entsprechend werden allgemein einsetzbare Gegenstände und die Fachwerte als offene Black-box-Rahmenwerke konstruiert. Die Gegenstandsbereichsschicht basiert selbst auf den technischen Schichten. Dabei ist anzustreben, daß die Systembasisschicht minimal verwendet wird und möglichst viele Dienstleistungen über die Kapselungen in der Technologieschicht in Anspruch genommen werden. Die Gegenstandsbereichsschicht enthält auch nur wenig Ausprägungen bezogen auf die gewählte Handhabung und Präsentation. Entsprechend gering sind ihre Bezüge zu dieser Schicht. Offensichtlich ist die Gegenstandsbereichsschicht eng mit einem Anwendungsbereich verbunden. Die Frage stellt sich also, ob diese Gegenstandsbereichsschicht nur für ein spezielles Unternehmen oder für eine ganze Branche, auch Domäne genannt, entwickelt werden kann. Sicherlich gibt es Konzepte und Begriffe, die das Geschäft einer Branche generell charakterisieren. Ansonsten wäre schließlich eine

3


3.3


741

Kooperation oder Fusion zwischen Unternehmen etwa im Bankenbereich gar nicht möglich. Andererseits hat sich in Projekten gezeigt, daß auch innerhalb einer Branche ausreichende Differenzen im Kerngeschäft bestehen, die eine einfache Übertragung eines Gegenstandsbereichs ausschließen. Diese Einsichten sind nicht neu, da sie schon das Ergebnis der Bemühungen um unternehmens- oder branchenweite Datenmodelle waren. So hat sich im Bankenbereich gezeigt, daß übergreifende Modelle zu abstrakt waren, um sie konkret nutzbringend einsetzen zu können. Wenn dies aber schon für Datenmodelle galt, dann sehen wir für verhaltensbezogene objektorientierte Modelle noch größere Probleme. Im Einzelfall sollte also sorgfältig geprüft werden, welche der fachlichen Konzepte eines Gegenstandsbereichs über den Anwendungsbereich hinaus gültig sind, für den der Gegenstandsbereich modelliert worden ist. Erst nach dieser anwendungsfachlichen Klärung kann darüber nachgedacht werden, welche Rahmenwerke der Gegenstandsbereichsschicht weiterverwendet werden können. Wir haben in Kapitel 3.3.1, S. 330ff. erläutert, daß für jede anwendungsfachliche Abteilung, die nach dem Objektprinzip oder einem an Produkten ausgerichteten Prozeßprinzip aufgebaut ist, ein eigener Produktbereich modelliert wird. Diese verschiedenen Produktbereiche

3

Produktbereichsschicht


3.3


742

werden in der Produktbereichsschicht realisiert. Sie bilden aber jeweils eine eigene Modellierungseinheit. Dies bedeutet, daß die Konzepte und Gegenstände in einem Produktbereich möglichst überschneidungsfrei, d.h. ohne Bezüge zu anderen Produktbereichen, realisiert werden müssen. Die Komponenten der Produktbereiche in dieser Schicht sind vor allem Black-box-Rahmenwerke. Sie sind konzeptionell auf der Basis der White-box-Rahmenwerke des Gegenstandsbereichs und der Handhabungs- und Präsentationsschicht aufgebaut. Ebenso verwenden sie die Technologie- und in Grenzen die Systembasisschicht. Die Spezialisierungen und Erweiterungen müssen dabei stets unter Berücksichtigung des Offen-Geschlossen-Prinzips erfolgen. Sie dürfen nicht zur Öffnung des Gegenstandsbereichs oder der anderen Bereiche führen. Rahmenwerke eines Produktbereichs spezialisieren meist gleichzeitig mehrere White-box-Rahmenwerke aus anderen Bereichen. Wesentlich ist, wie gesagt, daß keine Rahmenwerke aus benachbarten Produktbereichen verwendet werden. Dies gilt sowohl für die Benutzung als auch für die Vererbung. Fachlich sollte aus der bisherigen Argumentation klar geworden sein, daß ein Produktbereich in noch höherem Maß auf den konkreten Anwendungsbereich zugeschnitten ist als der Gegenstandsbereich. Hier werden schließlich die Grundprinzipien des Geschäfts eines Unternehmens auf die konkreten

3


3.3


743

Produkte und Prozesse abgebildet. An dieser Stelle manifestieren sich gerade die Unterschiede zwischen den verschiedenen Unternehmen einer Branche, so daß eine einfache Übernahme der Komponenten dieser Schicht schon unternehmensstrategisch ausscheidet. In der Produktbereichsschicht werden nur dann eigene Whitebox-Rahmenwerke entwickelt, wenn sie zur Konstruktion anderer Rahmenwerke im gleichen Produktbereich wiederverwendet werden können. Die nachfolgende Einsatzkontextschicht verwendet ausschließlich Black-box-Rahmenwerke aus den verschiedenen Produktbereichen. Die Einsatzkontextschicht entspricht dem in Kapitel 3.3.1, S. 331ff. vorgestellten Konzept der Einsatzkontexte und unterteilt sich daher analog in unterschiedliche Modellierungseinheiten. Daher gilt auch für die Einsatzkontexte das gleiche, was wir gerade über die Produktbereiche gesagt haben, nämlich daß die einzelnen Komponenten keine kontextübergreifenden Bezüge in dieser Schicht haben dürfen. Die Konstruktion entsprechender Anwendungssysteme erfolgt auf der Basis der Black-box-Rahmenwerke, die in den verschiedenen Produktbereichen entwickelt wurden. Eine eigene Entwicklung von Rahmenwerken findet nur dann statt, wenn die Einsatzkontexte besondere technologische oder fachliche Anforderungen aufweisen.

3

Einsatzkontextsschicht


3.3


744

Beispielsweise die Verwendung von Touch-Screens bei Selbstbedienungsterminals. Regeln für den Aufbau einer Schichtenarchitektur

Die WAM-Modellarchitektur definiert fünf logische Schichten. Jede Schicht besteht aus den für eine Modellarchitektur definierten Komponenten und Verbindungsstücken. Eigene Verbindungsstücke auf Schichtenebene werden nicht festgelegt. Daher lassen sich auch keine speziellen, auf die Schichten bezogenen Regeln angeben. Allerdings lassen sich die Beziehungen zwischen Komponenten (d.h. Klassenbibliotheken, Black- und White-box-Rahmenwerke) unterschiedlicher Schichten durch einige Abhängigkeitsregeln einschränken: ❑ Komponenten einer Schicht dürfen nur Komponenten der-

selben oder der nächsttieferenen protokollorientierten Schicht verwenden. ❑ Komponenten einer Schicht dürfen nur Komponenten der-

selben oder einer beliebigen tieferen objektorientierten Schicht verwenden. ❑ Komponenten eines Produktbereichs oder Einsatzkontextes

dürfen keine Komponenten eines anderen Produktbereichs oder Einsatzkontextes verwenden.

3


3.3


745

❑ Klassen einer anwendungsfachlichen Schicht dürfen nicht

gleichzeitig von einer anwendungsfachlichen Klasse und einer softwaretechnischen Klasse abgeleitet sein. Dies soll sicherstellen, daß eine Klasse konzeptionell entweder fachlich oder technisch ausgerichtet ist. Damit wird aber nicht verhindert, daß eine Klasse sowohl anwendungsfachliche als auch softwaretechnische Komponenten benutzt. Die Konstruktion der Rahmenwerke in den verschiedenen Produktbereichen auf der Grundlage der Schichten Technologie, Handhabung und Präsentation und Gegenstandsbereich stellt deren technische und fachliche Kombinier- und Integrierbarkeit bei der Entwicklung von Anwendungssystemen in den unterschiedlichen Einsatzkontexten sicher und fördert ein gemeinsames Erscheinungsbild. Der Technologiebereich sorgt dabei für die technische, der Gegenstandsbereich für die fachliche Kombinier- und Integrierbarkeit. Die Handhabungs- und Präsentationsschicht sichert außer dem »Look & Feel« den einheitlichen Umgang und die damit verbundenen Entwurfsmetaphern. In allen drei Bereichen werden die entsprechenden Grundkonzepte und die Möglichkeiten ihrer Erweiterbarkeit im Rahmen des OffenGeschlossen-Prinzips definiert.

3


3.3


746

Beispielarchitektur aus den GEBOS-Projekten

Als Beispiel für die Konkretisierung der WAM-Modellarchitektur skizzieren wir kurz die Schichtenarchitektur, die in den GEBOS-Projekten erarbeitet wurde. Dazu haben wir das vorhandene System in den Begriffen und der Darstellungsform der vorangegangenen Abschnitte beschrieben (s. Abbildung 3-69).

3


3.3


Abb. 3-69

Einsatzkontextschicht Beraterarbeitsplatz

Wertpapierspezialist

Schalter

Kredit

Wertpapier

Sicherheiten Kreditnehmer Kreditkonto Kreditprotokoll

Depot Chartanalyse Wertpapierinhaber

Die GEBOS-

Homebanking

Schichtenarchitektur ...

fachl. Behälter

Produktbereichsschicht ...

Person Kunde

Konto

Produkt

Formularwesen

fachl. Werte

Werkzeugbau

Gegenstandsbereichsschicht Wert und Objekt

Datenbank

CollectionKlassen

Handhabungsund Präsentationsschicht

elektr. Schreibtisch Hostkommunikation

MOP

Kommunikation

747

Technologieschicht GUI

...

Systembasisschicht

3


3.3


748

Das White-box-Rahmenwerk für den Werkzeugbau aus der Handhabungs- und Präsentationsschicht garantiert z.B., daß sich alle Werkzeuge, die auf dessen Basis erstellt werden, in einen elektronischen Schreibtisch eines Anwendungssystems einfügen lassen. Analog sorgt das Datenbank-Rahmenwerk der Technologieschicht für eine gleichartige Speicherung von Objekten in einer relationalen Datenbank. Dadurch kann jedes Anwendungssystem auf die dort gespeicherten Objekte zugreifen. Die beiden White-box-Rahmenwerke Person/Kunde und Konto aus dem Gegenstandsbereich bilden die fachliche Basis für die Konstruktion des Kreditnehmer/Kreditkonto-Rahmenwerks. Die Whitebox-Rahmenwerke der Gegenstandsbereichsschicht stützen sich auf vorhandene Rahmenwerke der Schichten Technologie sowie Handhabung- und Präsentation ab. Diese Schichtung der Rahmenwerke garantiert die technische Kombinier- und Integrierbarkeit von Rahmenwerken der Produktbereichsschicht, die ausschließlich auf Rahmenwerken der Gegenstandsbereichsschicht beruhen. Rahmenwerke der Gegenstandsbereichsschicht können zudem fachliche Konzepte in eine gemeinsame technische Basis einbetten und so deren einheitliche technische Verwendung garantieren. Alle Rahmenwerke der Gegenstands- und Produktbereichsschicht definieren eigene fachliche Materialien und Werkzeuge. Sie sind daher

3


3.3


749

über das Entwurfsmuster Werkzeug- und Materialkopplung mit dem Werkzeugbau-Rahmenwerk verbunden. Die Rahmenwerke des Technologieschicht bilden den technischen Rahmen für die Produktbereiche und die Einsatzkontexte, die der Gegenstandsbereichsschicht den fachlichen Rahmen. Beide sorgen somit für deren Kombinierbarkeit in unterschiedlichen Anwendungssystemen. Um die Verbindung zwischen den Schichten zu verdeutlichen, geben wir noch ein Beispiel: Wir zeigen wie das Kreditnehmer/Kreditkonto-Rahmenwerk der Produktbereichsschicht mit den anderen Schichten zusammenhängt. Zunächst wird das Person/Kunde-Rahmenwerk der Gegenstandsberichsschicht durch das Black-box-Rahmenwerk für Kreditnehmer und Kreditkonten der Produktbereichsschicht konkretisiert. Als Verbindungsstück wird das Rollenmuster verwendet (siehe Kapitel 3.3.4). Das Kreditkonto-Rahmenwerk spezialisiert das Konto-Rahmenwerk aus der Gegenstandsbereichsschicht durch einfache Unterklassenbildung. Letztlich konkretisiert das Rahmenwerk für Kreditnehmer und Kreditkonten aber auch das Werkzeug-Rahmenwerk aus der Handhabungs- und Präsentationsschicht und das Datenbank-Rahmenwerk

3


3.3


750

aus der Technologieschicht. Auf Basis dieser beiden Rahmenwerke werden entsprechende interaktive grafische Werkzeuge für die Materialien Kreditnehmer und Kreditkonto sowie ein Automat, der die Materialien in einer relationalen Datenbank speichert und aus ihr lädt, konstruiert. Die Spezialisierung findet durch die beiden Entwurfsmuster Werkzeug- und Materialkopplung sowie Serialisierer statt (vgl. Kapitel 3.2.1 und 3.3.4). Handhabung & Präsentation

Technologie Produktbereich

Datenbank

Kreditnehmer Kreditkonto

Abb. 3-70 Zusammenhang des Kreditnehmer/Kreditkonto-Rahmenwerks

Rolle Serialisierer

Werkzeugbau

WZ - Mat.Kopplung

Person Kunde

Konto

Gegenstandsbereich

3


3.3


751

Technische Realisierung der Modellarchitektur

Der fachliche und technische Entwurf von Rahmenwerken aus den Komponenten einer WAM-Modellarchitektur war in den vorangegangenen Abschnitten unser Thema. Ein anderer Gesichtspunkt ist die Aufteilung und Konfektionierung eines Anwendungssystems für die Auslieferung in die verschiedenen Einsatzkontexte. Hier müssen weitere Gesichtspunkte berücksichtigt werden: Das System muß in verschiedenen Versionen ausgeliefert werden und jede Version sollte minimalen Umfang haben. Grundsätzlich müssen dazu die einzelnen Schichten und ihre dort logisch zusammengefaßten Komponenten in eine physikalische Struktur von statischen und dynamischen Bibliotheken aufgeteilt werden. Bei der Abbildung in die physikalische Struktur sollen die fachlichen Strukturen weitgehend beibehalten werden.

3


3.3


752

Statische und dynamische Bibliothek: Eine statische Bibliothek, auch Programmbibliothek genannt, faßt vorübersetzte sogenannte Object-Dateien zu größeren Einheiten zusammen, ohne dabei die Referenzen zwischen den Dateien aufzulösen. Dies ist Aufgabe des Binders (Linker). Das ausführbare Anwendungssystem enthält den Programmcode aus den Object-Dateien. Eine dynamische Bibliothek, auch Dynamic Link Library (DLL) genannt, ist eine ablauffähige Einheit mit aufgelösten Referenzen zwischen den einzelnen Komponenten. Sie wird erst zur Laufzeit zum eigentlichen Anwendungsprogramm hinzugeladen, das daher auch keinen Programmcode aus der dynamischen Bibliothek enthält. Geladene dynamische Bibliotheken können von verschiedenen Anwendungssystemen gemeinsam benutzt werden.

Rahmenwerke, als »halbfertige« Softwaresysteme, werden bei Verwendung der Programmiersprache C++ sinnvollerweise als dynamische Bibliotheken realisiert. Dies führt einerseits zu kürzeren Bindezeiten bei großen Systemen. Andererseits werden die Rahmenwerke insgesamt vor änderndem Zugriff durch Anwendungsentwickler geschützt, die dann nicht mehr einfach Klassen im Rahmenwerk austauschen können. Eine simple Lösung für die Aufteilung von Rahmenwerken wäre, jedes Rahmenwerk in eine eigene dynamische Bibliothek zu packen.

3


3.3


753

Dann blieben zwar die Strukturen des Entwurfs und der Konstruktion erhalten, weitere technische Anforderungen blieben aber unberücksichtigt. Folgende Gründe sprechen für eine andere Aufteilung als die genannte Eins-zu-eins-Abbildung: ❑ Überflüssige Übersetzung: Bei der Verwendung von dynami-

schen Bibliotheken kann es zu einer Neuübersetzung einer Bibliothek A auch dann kommen, wenn sich in einer Bibliothek B, von der die Bibliothek A abhängig ist, Klassen ändern, die von der Bibliothek A nicht verwendet werden. ❑ Verständlichkeit: Auf Ebene der Bibliotheken ist nicht mehr

erkennbar, welche Benutzt- und Vererbungsbeziehungen wirklich bestehen. ❑ Konfektionierung: Ein Anwendungssystem enthält bei der

Eins-zu-eins-Aufteilung immer das gesamte Rahmenwerk, auch wenn nur Teile daraus verwendet werden. Dies gilt besonders für eine technische Aufteilung in Client- und Server-Komponenten, die fachlich ja in einem Rahmenwerk zusammengefaßt sind. ❑ Zuordnung: Wir haben jedes Rahmenwerk genau einer Schicht

unserer Modellarchitektur zugeordnet. Es kann softwaretechnisch sinnvoll sein, dynamische Bibliotheken schichtenübergreifend zu bilden.

3


3.3


754

Im Sinne von [Bäumer 98] schlagen wir daher vor, Rahmenwerke in einen Konzeptteil und einen oder mehrere Realisierungsteile zu zerlegen. Der Konzeptteil wird im wesentlichen die abstrakten Klassen des Rahmenwerks enthalten, in denen aber schon das Zusammenspiel der Komponenten zur Laufzeit festgelegt ist. Die Realisierungsteile enthalten die konkreten Klassen mit unterschiedlichen Implementationsvarianten. Sowohl Konzept- als auch Realisierungsteile haben eine Schnittstellendefinition und eine Implementation. Dadurch können nach den bekannten Modularisierungsprinzipien jeweils passende Konzeptteile verschiedener Rahmenwerke in Konzeptbibliotheken und entsprechend passende Realisierungsteile in Realisierungsbibliotheken zusammengefaßt werden. Dies soll durch Abbildung 3-71 verdeutlicht werden. Konzeptbibliothek 1

Konzeptbibliothek 2

Aufteilung von

Rahmenwerk A Konzeptteil

Rahmenwerk B Konzeptteil

Rahmenwerk B Konzeptteil

Rahmenwerk A Realisierungsteil 1

Rahmenwerk B Realisierungsteil 1

Rahmenwerk B Realisierungsteil 2

Realisierungsbibliothek 1

Abb. 3-71 Rahmenwerken in dynamische Bibliotheken


3


3.3


755

Die in den vorausgegangenen Abschnitten beschriebene Schichtenarchitektur wird technisch durch ein entsprechend strukturiertes Verzeichnis umgesetzt. Jede Schicht wird in einem eigenen Teilverzeichnis abgebildet. Dabei sind die verschiedenen Einsatzkontexte und Produktbereiche wiederum Subverzeichnisse des entsprechenden Verzeichnisses Produktbereich oder Einsatzkontext. Ebenso sind die jeweiligen Rahmenwerke Substrukturen zu ihren Schichtenverzeichnissen. Die Struktur der Bibliotheken wird als eine zweite Verzeichnisstruktur realisiert. Diese Verzeichnisstruktur repräsentiert eine zweite Sicht auf die einzelnen Dateien oder Komponenten. Technisch stehen hierfür meist symbolische Verweise oder virtuelle Dateisysteme zur Verfügung. Durch diese Trennung von Rahmenwerken in eine Schichtenarchitektur und eine Bibliotheksstruktur lassen sich unterschiedliche Gesichtspunkte eines Projektes in verschiedenen Bibliotheksstrukturen abbilden. Beispielsweise können für das Entwicklerteam viele kleine Bibliotheken entlang der aktuellen Entwicklungsarbeiten gebildet werden, so daß Änderungen möglichst lokal zu einer Bibliothek gehalten werden können, was die Übersetzungs- und Bindezeiten reduziert. Dagegen werden für die Auslieferung möglichst wenige große Bibliotheken zusammengestellt, um die Nachteile durch erhöhten Speicherbedarf und längere Ladezeiten zu minimieren.

3


3.3


756

Beispiel der Realisierung in den GEBOS-Projekten

Um die im letzten Abschnitt diskutierte problematische Eins-zu-einsAbbildung von Rahmenwerken auf Bibliotheken zu verdeutlichen, stellen wir ein vereinfachtes Beispiel aus dem GEBOS-Kontext vor (s. Abbildung 3-72).

Papier

Kundenakte Rahmenwerk Person/Kunde

Fachlicher Wert

enthält

Bankinfo

enthält

Dokument

Erfassungsmedium

Betrag

Rahmenwerk Elektr. Formularwesen

Zinssatz

... Rahmenwerk Fachliche Werte

Modellrechenblatt

Unterschriftsformular

Vollmacht

Vertragsformular

Abb. 3-72 Ein Beispiel aus

Antragsformular

Kundenakte, Papieren und fachlichen Werten

3


3.3


757

Eine Kundenakte ist Element des bereits vorgestellten Person/Kunde-Rahmenwerks. Sie enthält überwiegend Schriftstücke in Papierform. Diese Benutzt-Beziehung wird zwischen der Klasse Kundenakte und der Klasse Papier festgelegt. Die Klasse Papier stellt dabei die aufgeschobene Wurzelklasse des Rahmenwerks für das elektronische Formularwesen dar und basiert selbst auf der Klasse FachlicherWert. Die gängigen Fachwerte für die Konstruktion eines Banksystems sind in dem entsprechenden Rahmenwerk fachliche Werte enthalten. Die im letzten Abschnitt genannten Probleme stellen sich hier konkret so dar: ❑ Unnötige Übersetzung: Die Klasse Kundenakte hat lediglich

eine Referenz auf die Klasse Papier, die für die Kundenakte alle Unterklassen des Rahmenwerks elektronisches Formularwesen kapselt. Eine Änderung an der Klasse Vollmacht des Rahmenwerks elektronisches Formularwesen, führt bei einer Eins-zu-eins-Abbildung dazu, daß die dynamische Bibliothek des Rahmenwerks Person/Kunde unnötigerweise neu erstellt wird, da diese von der dynamischen Bibliothek elektronisches Formularwesen abhängig ist. Eine neue Übersetzung wäre aber nur notwendig, wenn sich die Klasse Papier ändert.

3


3.3


758

❑ Verständlichkeit: Nur durch Analyse des Programmtextes

kann ein Softwareentwickler feststellen, daß die Klasse Kundenakte lediglich die Oberklasse Papier der Bibliothek elektronisches Formularwesen und keine Unterklassen verwendet. ❑ Konfektionierung: Wird die Kundenakte in einen Serverteil

und einen Clientteil aufgespalten (etwa weil auf dem Server der Anschluß an die Datenbank realisiert wird), so enthält eine Eins-zu-eins-Bibliothek sowohl den Client- als auch den Serverteil. ❑ Zuordung: Es macht softwaretechnisch Sinn, die Klasse Kun-

denakte zusammen mit den abstrakten Klassen Papier und FachlicherWert auszuliefern, da diese immer zusammen verwendet werden. Übertragen wir die Unterscheidung in Konzeptteil und Realisierungsteil auf unser Beispiel, dann ergibt sich die folgende Aufteilung in Klassen und Bibliotheken (s. Abbildung 3-73):

3


3.3


759

Konzeptbibliothek 1

Papier

Kundenakte enthält

Rahmenwerk Person/Kunde

Fachlicher Wert

enthält

Realisierungsbibliothek 1 Bankinfo


Dokument

Erfassungsmedium

Betrag

Zinssatz

Rahmenwerk elektr. Formularwesen

Modellrechenblatt


Vollmacht

Vertra gsformular

...

Rahmenwerk fachliche Werte

Antragsformular

Abb. 3-73 Das GEBOS-Beispiel aufgeteilt in Konzept- und

Die Konzeptklasse Kundenakte des Rahmenwerks Person/Kunde, die Konzeptklassen Papier und Erfassungsmedium des Rahmenwerks elektronisches Formularwesen sowie die Konzeptklasse FachlicherWert des Rahmenwerks fachliche Werte werden in einer Konzept-

3

Realisierungsbibliotheken


3.3


760

bibliothek zusammengefaßt. Die restlichen Klassen des Rahmenwerks elektronisches Formularwesen und fachliche Werte bilden je eine Realisierungsbibliothek. Wir können jetzt unser Beispiel so auf Verzeichnisstrukturen übertragen, daß einerseits die Schichtenarchitektur sichtbar wird, andererseits die Bibliotheksstruktur als zweite Sicht repräsentiert ist. Abbildung 3-74 stellt eine auf dem vorangegangenen Beispiel basierende Verzeichnisstruktur dar. Die Verbindung zwischen Klassen in den Bibliotheken und den Klassen in den Rahmenwerken wurde mittels symbolischer Verweise realisiert. Diese sind in der Abbildung kursiv und durch einen Pfeil auf die Klasse im Rahmenwerk dargestellt.

3


3.3


Schichten- und Rahmenwerksstruktur

Bibliotheksstruktur

761 Abb. 3-74 Verzeichnisse für

Einsatzkontexte

Schichten-, Rahmenwerks-

...

und Bibliotheksstruktur

Produktbereiche ...

Gegenstandsbereich Person/Kunde Kundenakte

Konzeptbibliothek N

Kundenakte

...

Papier

elektronisches Formularwesen

Erfassungsmedium

Papier

FachlicherWert

Erfassungsmedium Bankinfo

...

Dokument

Realisierungsbibliothek M

Bankinfo

Modellrechenblatt

Dokument

Unterschrifsformular

Modellrechenblatt

...


fachliche Werte FachlicherWert

... ...

Betrag Zinssatz

Konzeptteil eines Rahmenwerks

... ...

Realisierungsteil eines Rahmenwerks

Technologiebereich ...

Systembasis

Papier

Papier

symbolischer Verweis

...

3


3.3


762

3.3.4 Entwurfsmuster für die WAM-Modellarchitektur In den vorausgegangenen Abschnitten sind wir immer wieder auf das Thema der losen Kopplung zwischen den Komponenten einer rahmenwerkbasierten Architektur eingegangen. Zwei Probleme sind in der Diskussion noch offengeblieben: ❑ Das Rollenkonzept läßt sich nicht unmittelbar durch Generali-

sierung oder Spezialisierung und durch das Mittel der Vererbung realisieren. ❑ Vielfach kann zwischen Komponenten eine lose Kopplung in

der Benutzung dadurch erreicht werden, daß eine abstrakte (Ober-) Klasse verwendet wird. Die einzige Stelle, an der die konkrete Klasse bekannt sein muß, ist die Objekterzeugung. Dazu kommt ein drittes Problem, das in der Diskussion implizit auftauchte: ❑ Wir können nicht von einer völlig homogenen objektorientier-

ten »Welt« bei der Entwicklung von interaktiven Anwendungssystemen ausgehen. Unterschiedliche Persistenzmedien und externe Schnittstellen müssen bedient oder integriert werden. Dazu ist eine Transformation der Objekte von dem internen in verschiedene externe Formate notwendig.

3

Federführung: Dirk Bäumer Ko-Autor: Dirk Riehle, Wolf Siberski, Martina Wulf


3.3


763

Wir stellen im folgenden drei Entwurfsmuster vor, die eine Lösung dieser Probleme aufzeigen: ❑ Das Rollenmuster bietet die Möglichkeit, unter Wahrung der

fachlichen Identität ein fachliches Objekt in verschiedenen Rollen zu betrachten (und zu bearbeiten). ❑ Das Händlermuster ist ein Erzeugungsmuster, das die Kenntnis

der konkret zu erzeugenden Klassen aus der eigentlichen Anwendung in eine gesonderte Komponente verlagert. ❑ Das Serialisierermuster ermöglicht, Objektgeflechte in struk-

turbasierte externe Medien zu schreiben und von dort wieder einzulesen. Das Rollenmuster

Das Rollenmuster kann verwendet werden, um ein Objekt dynamisch an spezielle Bedürfnisse von Klienten anzupassen. Im Kontext der WAM-Modellarchitektur bedeutet dies, daß Attribute und Schnittstellen je nach Sichtweise eines Klienten (Produktbereichs) dynamisch zu Objekten, die von Klassen des Gegenstandsbereichs instanziiert werden, hinzugefügt und von diesen auch wieder entfernt werden können (s. [Bäumer 98]).

3


3.3


764

Zwei Objekte mit unterschiedlicher technischer Identität können fachlich betrachtet für eine Identität stehen. Dies gilt besonders für solche Gegenstände des Anwendungsbereichs, die als Konzepte im Gegenstandsbereich beschrieben sind, aber in verschiedenen Produktbereichen jeweils mit anderen Umgangsformen und fachlichen Zuständen betrachtet werden. Hier muß gewährleistet werden, daß ein Gegenstand, der aus einem Produktbereich in einen anderen wechselt, zwar diese unterschiedlichen Umgangsformen und Zustände zeigt, aber dieselbe fachliche Identität besitzt.

Problem

Die Modellierung eines Anwendungssystems wird immer unter einem ganz bestimmten Blickwinkel durchgeführt. Daher sind Klassen, die die Gegenstände des Anwendungsbereichs als Konzepte repräsentieren, geprägt durch die Sichtweise, unter der ein Softwareentwickler den Anwendungsbereich betrachtet. Dies gilt insbesondere für die unterschiedlichen Produktbereiche (s. Kapitel 3.3.1). Diese differenzierte Sichtweise ist unproblematisch, solange aus Sicht der verschiedenen Produktbereiche unterschiedliche Gegenstände des Anwendungsbereichs modelliert werden. Weist allerdings ein Konzept des Gegenstandsbereichs aus dem Blickwinkel der Produktbereiche verschiedene Attribute und Umgangsformen auf, so sind Lösungen erforderlich, um nicht alle Sichtweisen an diesem einen Konzept

Kontext

3


3.3


765

modellieren zu müssen. Sonst würde das Konzept als Bestandteil des Gegenstandsbereichs Abhängigkeiten zu den Produktbereichen besitzen. Derartige Abhängigkeiten führen in der Konsequenz zu einem gemeinsamen Bereich, der alle Produktbereiche und den Gegenstandsbereich umfaßt. Wir stellen daher als Lösung dieser Problematik das Modellierungsmittel der Rolle vor. Rollen ermöglichen es, die aus der Sicht eines Produktbereichs fachlich zusammengehörigen Zustände und Umgangsformen eines Konzepts aus dem Gegenstandsbereich in einer eigenen Klasse zu modellieren. Ein Beispiel aus dem Bankenbereich zeigt, daß derselbe fachliche Gegenstand aus der Sicht verschiedener Produktbereiche unterschiedlich modelliert wird: Die beiden Konzepte Kreditnehmer (Produktbereich Kredit) und Anleger (Produktbereich Anlage) realisieren das Konzept des Kunden aus unterschiedlichen Blickwinkeln. Ein Kreditnehmer verwaltet etwa die Sicherheiten, die im Rahmen der Kreditvergabe an die Bank übereignet werden. Derartige Informationen sind für das Konzept Anleger ohne Bedeutung und werden daher dort auch nicht modelliert. Zudem stellen die aus Sicht eines Produktbereichs modellierten Eigenschaften oft dynamische Aspekte eines fachlichen Gegenstands dar. Ein Kunde wird beispielsweise nur dann zum Kreditnehmer in einer Bank, wenn er einen Kredit in Anspruch nimmt.

3


3.3


Ansonsten weist er die mit einem Kreditnehmer verbundenen Eigenschaften nicht auf. Eine naive, auf den Mitteln der Objektorientierung basierende Lösung ist die Modellierung der drei Begriffe Kunde, Kreditnehmer und Anleger als Klassen. Das Konzept Kunde wäre Bestandteil des Gegenstandsbereichs, das des Kreditnehmers Teil des Produktbereichs Kredit und das des Anlegers Element des Produktbereichs Anlage. Da die Konzepte Anleger und Kreditnehmer das Konzept des Kunden erweitern und Anleger- bzw. Kreditnehmerobjekte anstelle eines Kundenobjekts verwendbar sind (ein Kreditnehmer »ist-ein« Kunde), wird softwaretechnisch die Klasse Kunde als Generalisierung der Klassen Kreditnehmer und Anleger realisiert. Die Klasse Kunde modelliert dabei Eigenschaften wie die Kundennummer oder eine Operation GibGesamtEngagement (vgl. Abbildung 3-75).

3

766 Ein wenig tragfähiger Lösungsansatz


3.3


767 Abb. 3-75

Kunde

Konto


GibSaldo() Einzahlen() Auszahlen() BerechneZinsen()

List Konten; String Name;

Produktbereichsspezifische Spezialisierung eines Kunden mittels Vererbung

Für alle Konten k do b := b + k->GibSaldo() return b;

Kreditnehmer

Anleger

GibSummeSicherheiten()

GibSummeAnlagen()

List<Sicherheit *> Sicherheiten;

List Anlageprodukte;

Wird nun der Kunde Hans Müller zur Laufzeit eines Systems als Anleger und als Kreditnehmer verwaltet (d.h., es wird von beiden Klassen ein Objekt erzeugt), so führt die vorgestellte Realisierung zur Verdopplung der in der Klasse Kunde modellierten Attribute. Denn sowohl ein Objekt der Klasse Anleger als auch ein Objekt der Klasse

3


3.3


768

Kreditnehmer besitzen die Attribute Konten und Name. Es sind daher aufwendige Synchronisierungsmechanismen notwendig, um die fachliche Identität der Objekte zu wahren. Änderungen an einem Objekt müssen jeweils in dem anderen Objekt nachgezogen werden, um mittels Wertegleicheit ihre fachliche Identität zu simulieren. Die technische Umsetzung in Form von Mehrfachvererbung, bei der eine Klasse KreditnehmerUndAnleger als Unterklasse der beiden Klassen Anleger und Kreditnehmer gebildet wird, verhindert zwar die Verdopplung der Attribute der Klasse Kunde, führt aber bei einer steigenden Anzahl von Klassen zu einem kombinatorischen Anwachsen der möglichen Unterklassen. Diese Flut von Unterklassen wird schnell sehr unübersichtlich. Die kombinierten Klassen werden zudem von allen Produktbereichen verwendet, die an der Kombination beteiligt sind (bei der Klasse KreditnehmerUndAnleger sind das die Produktbereiche Kredit und Anlage). Diese Lösung enthält zudem das Problem der Objektmigration. Ein Kunde ist beispielsweise nicht notwendigerweise gleichzeitig Kreditnehmer und Anleger. Er wird vielleicht zunächst nur als Anleger betrachtet. Erst wenn er einen Kredit in der Bank aufnimmt, wird er zusätzlich zum Kreditnehmer. Nun muß ein neues Objekt der Klasse KreditnehmerUndAnleger erzeugt werden, in das die Attribute des Anlegerobjekts übertragen werden. Weiterhin müssen alle Referenzen, die auf das »alte« Anlegerobjekt verweisen,

3


3.3


769

auf das neue Objekt gesetzt werden. Dieser Prozeß der Referenzänderung ist ohne geeignete Unterstützung (beispielsweise become: in Smalltalk) nicht durchführbar. Modelliere die verschiedenen Blickwinkel eines fachlichen Gegenstands in eigenen Objekten, den sogenannten Rollenobjekten. Diese Rollenobjekte können dynamisch zu Kernobjekten hinzugefügt und von diesen entfernt werden. Das Kernobjekt zeigt die Merkmale, die ein fachlicher Gegenstand in jedem Kontext oder Bereich ausweist. Stelle die gemeinsame fachliche Identität von Kern- und Rollenobjekten sicher. In der Literatur wird die Problematik, fachliche Gegenstände abhängig vom jeweiligen Blickwinkel (Produktbereich) und vom Zeitpunkt der Betrachtung unterschiedlich zu modellieren, unter dem Begriff der Rolle diskutiert (vgl. [Gottlob et al. 96, Kristensen & Østerbye 96, Reenskaug et al. 96]). Kristensen und Østerbye definieren den Begriff der Rolle als eine Menge von Eigenschaften, die ein Objekt in seinem Verhalten einer Menge anderer Objekte gegenüber zeigt. Ein Werkzeug, das der Bearbeitung von Kundensicherheiten dient, arbeitet mit Kundenobjekten unter dem speziellen Blickwinkel (Rolle) des Kreditnehmers.

3

Lösung


3.3


770

Ein Kernobjekt repräsentiert diejenigen Merkmale eines Gegenstandes des Anwendungsbereichs, die wir im Gegenstandsbereich modellieren, die also unabhängig von den verschiedenen Produktbereichen sind.

Rollenobjekt, Kernobjekt: Ein Rollenobjekt repräsentiert die Menge der Attribute und Operationen, die ein Gegenstand unter einem anwendungsbezogenen Blickwinkel aufweist. Ein Kernobjekt ist ein Objekt, das in einem System verschiedene Rollen spielen kann. Es umfaßt solche Zustände und Operationen, die unabhängig von einem spezifischen Blickwinkel von all seinen Rollenobjekten nach außen repräsentiert werden. Ein Kernobjekt kann unabhängig von seinen Rollenobjekten existieren.

Bei einem Kunden umfaßt das Kernobjekt beispielsweise seine Adresse und Kundennummer sowie sein Girokonto. Sowohl das Kernobjekt als auch die Rollenobjekte sind dabei nach dem Geheimnisprinzip entworfen. Sämtliche Attribute werden ausschließlich über Operationsaufrufe manipuliert. Ein Rollenobjekt hat somit keinen direkten Zugriff auf die Attribute seines Kernobjekts. Da ein Kernobjekt unabhängig von seinen Rollenobjekten lebensfähig sein muß, darf es nicht durch Operationsaufrufe auf sie zugreifen. Andernfalls würden über

3


3.3


771

das Kernobjekt Abhängigkeiten zwischen den Rollenobjekten entstehen, die wiederum zu Abhängigkeiten zwischen den Produktbereichen führen. Rollenobjekte und Kernobjekte werden im softwaretechnischen Modell durch Klassen realisiert. Um die Klassen den jeweiligen Objektarten zuordnen zu können, wird im weiteren die Klasse, die ein Kernobjekt modelliert, als Kernkonzept, die Klasse, die ein Rollenobjekt modelliert, als Rollenkonzept bezeichnet. Abb. 3-76

Subjekt: Kunde

Ein Kernobjekt Kunde mit den Rollenobjekten Kreditnehmer und Anleger

einKunde Rolle: Name: Hans Müller Tel.: 040-8587638 Kndnr: 858848

Kernobjekt: Kunde

einKreditnehmer Kredit: 250.000,-Sicherheiten: ...:

Rollenobjekt: Kreditnehmer

einAnleger Anlageprodukte: ...

Rollenobjekt: Anleger

3


3.3


772

Die technische Unterscheidung zwischen Kern- und Rollenobjekt führt zur Ausdifferenzierung des Identitätsbegriffs. Das Kernobjekt verfügt über eine eigene technische Identität, die sich von den technischen Identitäten der Rollenobjekte unterscheidet. Gleichzeitig bildet das Kernobjekt zusammen mit seinen Rollenobjekten eine logische Einheit, die als ganzes eine fachliche Identität besitzt. Existiert beispielsweise ein Kernobjekt Kunde mit zwei Rollenobjekten Kreditnehmer und Anleger, so besitzen die drei Objekte sowohl ihre eigene technische Identität als auch eine gemeinsame fachliche Identität, die der logischen Einheit, bestehend aus dem Kernobjekt Kunde und seinen Rollenobjekten, anhaftet (vgl. Abbildung 3-76). In Anlehnung an [Kristensen & Østerbye 96] bezeichnen wir diese logische Einheit als 11 Subjekt . Subjekt: Ein Subjekt ist die logische Einheit aus Kernobjekt und allen dem Kernobjekt momentan anhaftenden Rollen. Es verkörpert eine fachliche Identität, auch Subjektidentität genannt.

Das Rollenmuster sollte verwendet werden wenn:

Anwendbarkeit

3


3.3


773

❑ Kernkonzepte in unterschiedlichen Kontexten mit spezifischen

Schnittstellen und Attributen versehen werden sollen, ❑ es notwendig ist, die kontextspezifischen Blickwinkel dyna-

misch zu einem Kernobjekt hinzuzufügen und auch wieder von diesem entfernen zu können, ❑ das aus Kern- und Rollenobjekt bestehende Objektgefüge über

eine eigene Subjektidentität verfügen sollte, ❑ die verschiedenen Blickwinkel (Rollen), unter denen ein Kern-

konzept betrachtet werden kann, unabhängig voneinander weiterentwickelbar sein müssen.

11. Kristensen und Østerbye unterscheiden in [Kristensen & Østerbye 96] zusätzlich zwischen einem subject und einem closured subject. Ein subject umfaßt das Kernobjekt plus eine beliebige Anzahl von Rollenobjekten, die es gerade spielt. Der Begriff closured subject dagegen repräsentiert das Kernobjekt plus alle seine Rollenobjekte. Der von uns gewählte Begriff Subjekt stimmt demnach mit dem Begriff closured subject von Kristensen und Østerbye überein. Eine weitere Ausdifferenzierung ist in unseren Anwendungsbereichen bisher nicht notwendig gewesen.

3


3.3


774

Das Muster sollte nicht verwendet werden, wenn zwischen den Rollen starke Abhängigkeiten bestehen. Abbildung 3-77 zeigt die Struktur des Rollenmusters. Die in der Abbildung verwendete Spezifikation (Spec) ist mit der beim Produkthändler (s. S. 389ff.) beschriebenen Spezifikation vergleichbar.

3

Struktur


3.3


775 KlientB

Subjekt FachlicheOperation()

KlientA

hatRolle(Spec) fuegeRolleHinzu(Spec) entferneRolle(Spec) gibRolle(Spec)

Kernkonzept

Rollenkonzept

rollen

FachlicheOperation()

FachlicheOperation() Zustand

kern

kern->FachlicheOperation()

KonkreteRolleB NeueOperationB() NeuerZustandB KonkreteRolleA NeueOperationA() NeuerZustandA

Abb. 3-77 Die Struktur des Rollenmusters

3


3.3


776

Subjekt (das Subjekt Kunde) ❑ modelliert das Subjekt in Form von fachlichen Operationen,

im Beispiel des Kunden etwa aendereAdresse oder gibTelefonnummer. Die Operationen sind als aufgeschobene Operationen definiert und müssen im Kernkonzept implementiert werden. Da Rollenobjekte polymorph anstelle des Kernobjekts verwendbar sein müssen, implementieren die Rollenkonzepte ebenfalls die Schnittstelle des Subjekts. ❑ bietet Operationen für die Rollenverwaltung an (Rollen erfra-

gen, hinzufügen, entfernen und ihr Vorhandsein prüfen). Als Spezifikation wird im einfachsten Fall der Name der Rolle als Zeichenkette oder der Typ des Rollenkonzepts verwendet. ❑ definiert keine eigenen Attribute, da es die logische Einheit aus

Kernobjekt und Rollenobjekten repräsentiert. Kernkonzept (das Kernkonzept des Kunden) ❑ verwaltet die zu einem Kernobjekt hinzugefügten Rollenob-

jekte, ❑ implementiert die aufgeschobenen fachlichen Operationen des

Subjekts.

3


3.3


777

Rollenkonzept ❑ verwaltet eine Referenz auf das Kernobjekt. ❑ bietet eine Standardimplementierung der aufgeschobenen

fachlichen Operationen des Subjekts an. Diese delegiert den Operationsaufruf an das Kernobjekt. KonkreteRolle (Kreditnehmer, Anleger) ❑ modelliert und implementiert eine Erweiterung des Kernkon-

zepts unter einem anwendungsspezifischen Blickwinkel. In der Regel ist das die Sicht, die ein Produktbereich auf ein Kernkonzept des Gegenstandsbereichs einnimmt. Die Interaktion zwischen Kern- und Rollenobjekt läßt sich folgendermaßen beschreiben:

Interaktionen

❑ Ein Rollenobjekt leitet die an ihm aufgerufenen Subjektopera-

tionen an das Kernobjekt weiter. ❑ Alle Rollenobjekte eines Subjekts verwenden dasselbe Kernob-

jekt. Ein Klient interagiert folgendermaßen mit einem Kernobjekt und dessen Rollenobjekten:

3


3.3


778

❑ Ein Klient kann ein Rollenobjekt zu einem Kernobjekt hinzu-

fügen. Dies geschieht, indem der Klient die Rollen in Form eines Spezifikationsobjekts beschreibt. ❑ Ein Klient erfragt an einem Kern- oder Rollenobjekt eine

gewünschte Rolle. Existiert ein entsprechendes Rollenobjekt, so wird dieses zur weiteren Bearbeitung verwendet. ❑ Verfügt das Kernobjekt nicht über das gewünschte Rollen-

objekt, so signalisiert es dies dem Klienten in Form einer Fehlermeldung. Kernobjekte erzeugen nie selbständig Rollenobjekte. Diese müssen immer von einem Klienten zu einem Kernobjekt hinzugefügt werden. Mit dem Rollenmuster sind die folgenden Vorteile verbunden:

Konsequenzen

❑ Das Kernkonzept verfügt über eine hohe Kohäsion, da es keine

Schnittstellen und Attribute enthält, die nur aus einem bestimmten Blickwinkel (z.B. Produktbereich) motiviert sind. ❑ Rollenkonzepte können unabhängig voneinander entwickelt

werden, da hierfür keine Änderungen am Kernkonzept notwendig sind.

3


3.3


779

❑ Rollenobjekte können dynamisch zu Kernobjekten hinzuge-

fügt und von diesen entfernt werden. Zur Laufzeit eines Anwendungssystems befinden sich nur die Objekte im Hauptspeicher, die auch tatsächlich verwendet werden. ❑ Im Rahmen unserer Modellarchitektur können Produktberei-

che in ihrer Entwicklung besser voneinander getrennt werden, da Veränderungen, die aus Sicht eines Produktbereichs an einer Rolle vorgenommen werden, keine Auswirkungen auf Rollenkonzepte anderer Produktbereiche haben. Das Muster ist aber auch mit den folgenden Nachteilen verbunden: ❑ Regeln, die sich auf das Zusammenspiel von Rollenobjekten

mit ihrem Kernobjekt beziehen, können nicht durch das Typsystem überprüft werden. Ist beispielsweise das Hinzufügen einer Rolle von der Existenz einer anderen Rolle abhängig, so kann dies nur zur Laufzeit des Systems abgesichert werden. ❑ Das Rollenmusters erfordert zusätzlichen Kodierungsaufwand

beim Klienten. Klienten müssen in der Regel zunächst von einem Kernobjekt das passende Rollenobjekt anfordern. Ist dies noch nicht vorhanden, so muß es vom Klienten erzeugt werden. Dabei muß der Klient fachlich sicherstellen, daß das

3


3.3


780

Kernobjekt diese Rolle tatsächlich spielen kann. Erst dann läßt sich das Subjekt vom Klienten in der gewünschten Rolle ansprechen. ❑ Zusätzlicher Kodierungsaufwand ist auch notwendig, um die

Subjektidentität zu realisieren. Das Subjekt, das Kern- und das Rollenkonzept müssen daher über entsprechende Methoden verfügen, um die Subjektidentität auf die technische Objektidentität von Kern- und Rollenobjekt abzubilden. ❑ Rollen- und Kernobjekte müssen über dieselben Schnittstellen

Implementierung

verfügen. Ansonsten kann ein Rollenobjekt nicht anstelle eines Kernobjektes verwendet werden. Diese Forderung läßt sich in einer typisierten objektorientierten Programmiersprache nur unter Einsatz von Vererbung realisieren. Rollenkonzepte müssen daher von Kernkonzepten erben. Die Vererbungsbeziehung ermöglicht zudem, Eigenschaften des Kernkonzeptes in einem Rollenkonzept unter einem produktbereichsspezifischen Blickwinkel zu erweitern. Da aber alle Rollenobjekte die Attribute ihres Kernobjektes »gemeinsam« verwenden, müssen diese ihr Kernobjekt dekorieren. Implementierungstechnisch führt dies zu der abstrakten Klasse Subjekt, die als aufgeschobene

3


3.3


781

Operationen die Schnittstelle des Kerns definiert, einer Klasse Kernkonzept, die den Kern implementiert, und einer Klasse Rollenkonzept, die die Schnittstelle für konkrete Rollen sowie das Zusammenspiel mit einem Kernobjekt definiert. Die Verwendung eines Kernobjektes erfolgt aber stets unter der abstrakten Schnittstelle des Subjekts. ❑ Die Instanziierung von konkreten Rollen sollte vor dem Klien-

ten verborgen werden. Denn dann benötigt der Klient kein Wissen darüber, welche Rollen durch welche Klassen implementiert werden. Technisch läßt sich dieser Anspruch einfach mit einem Händler lösen (s. S. 389ff.). Die abstrakte Klasse Rollenkonzept fungiert dabei als Händler, der einem Kernkonzept die gewünschte Rolle vermittelt. Der Klient wendet sich dann stets unter der Schnittstelle des Subjekts an das Kernobjekt, um sich von ihm die gewünschte Rolle erzeugen zu lassen. ❑ Verwaltung der Rollenobjekte.

Damit ein Kernobjekt seine Rollenobjekte verwalten kann, muß die Klasse Subjekt eine geeignete, abstrakte Schnittstelle zur Verfügung stellen, die von dem konkreten Kernkonzept implementiert wird. Das Kernobjekt führt seine Rollen-

3


3.3


782

objekte in einer Hashtabelle. Kann eine Rolle nur einmal zu einem Kernobjekt hinzugefügt werden und ist sichergestellt, daß mehrere Rollen nicht unter einer gemeinsamen, abstrakten Rolle betrachtet werden, so kann als Schlüssel die Rollenspezifikation verwendet werden, die bereits zur Erzeugung eingesetzt wurde. Ansonsten müssen für die Rollenerzeugung und verwaltung unterschiedliche Spezifikationen benutzt werden. ❑ Kernobjekte müssen sich während ihrer Lebenszeit dynamisch

um Rollenobjekte erweitern lassen. Die Forderung nach Dynamik kann in einem objektorientierten Anwendungssystem nur durch eine Benutzt-Beziehung zwischen Kern- und Rollenobjekten realisiert werden. Denn die gängigen objektorientierten Programmiersprachen unterstützen keine dynamische Reklassifikation, beispielsweise durch eine Veränderung der Vererbungsbeziehung zur Laufzeit des Systems. ❑ Die Benutzt-Beziehung zwischen Kern- und Rollenobjekten

kann dazu verwendet werden, die geforderte Subjektidentität zu realisieren. Wenn alle Rollenobjekte, die ein Kernobjekt erweitern, dieses über eine Benutzt-Beziehung kennen, so läßt sich die techni-

3


3.3


783

sche Identität des Kernobjekts als Subjektidentität verwenden. Rollenobjekte besitzen dann dieselbe Subjektidentität, wenn sie dasselbe Kernobjekt referenzieren. ❑ Die Zustandsintegrität der konzeptionellen Subjektidentität

muß gewahrt werden. Die Eigenschaften eines Gegenstands im Anwendungsbereich lassen sich durch das Rollenkonzept in verschiedenen technischen Klassen modellieren. Dadurch wird die mit dem Gegenstand verbundene Identität auf mehrere technische Identitäten verteilt. Abgesehen davon, daß zusätzlich eine fachliche Subjektidentität konstruiert werden muß, kann diese Form der technischen Realisierung zu Problemen bei der Zustandsintegrität des Subjekts führen. Denn der Zustandsraum eines Gegenstands des Anwendungsbereichs wird auf verschiedene Zustandsräume im softwaretechnischen Modell verteilt. Existieren Abhängigkeiten zwischen den einzelnen Zustandsräumen, so werden geeignete Mechanismen für ihre Synchronisation (z.B. Beobachtermuster) benötigt. ❑ Die Möglichkeit, Eigenschaften eines Kernkonzeptes in einem

Rollenkonzept zu erweitern, führt potentiell zu Problemen. Dies läßt sich am Beispiel der Kundenadreßänderung illustrie-

3


3.3


784

ren. Angenommen, die Operation aendereAdresse wird nicht nur in der Rolle Kreditnehmer, sondern auch im Anleger erweitert (technisch kann dies durch die Redefinition der Operation aendereAdresse sowohl für den Kreditnehmer als auch für den Anleger realisiert werden). Dann führt ein Aufruf der Operation zu drei unterschiedlichen Ergebnissen, je nachdem ob aendereAdresse von dem Rollenobjekt Anleger, dem Rollenobjekt Kreditnehmer oder dem Kundenkernobjekt abgearbeitet wird. Dabei gilt: – Erfolgt der Aufruf am Kernobjekt, so wird keine der Erweiterungen ausgeführt. – Erfolgt sie an einem der Rollenobjekte, so wird zwar die dort angegebene Erweiterung (Redefinition) verarbeitet, die des anderen Rollenobjekts bleibt aber unberücksichtigt. Das Problem besteht darin, daß ein Subjekt technisch in mehreren Klassen realisiert wird und daher nur jeweils eine der drei Operationen zur Ausführung kommt. Aus anwendungsfachlicher Sicht sollten sich die verschiedenen Objekte jedoch wie ein Subjekt verhalten. Demnach müßten bei einer Adreßänderung alle drei Operationen ausgeführt werden. Technische Realisierungen des Kern- und Rollenkonzepts, die dieses Problem lösen, könnten sich auf das

3


3.3


785

Beobachtermuster oder auf Schablonenoperationen abstützen. ❑ Rollen von Rollen.

Durch die rekursive Anwendung des Rollenmusters auf Rollenkonzepte, lassen sich Rollen von Rollen realisieren. So ist in der Abbildung 3-78 die Rolle Kunde des Kernkonzeptes Person wieder durch Anwendung des Rollenmusters in ein Kernkonzept KundenKern und die Rollenkonzepte Anleger und Kreditnehmer zerlegt worden.

Abb. 3-78 Rekursive Anwendung des Rollenmusters –>

3


3.3


786

Person GibName() HatRolle(Spec) FuegeRolleHinzu(Spec) EntferneRolle(Spec) GibRolle(Spec)

rollen

PersonenKern

PersonenRolle

GibName()

GibName()

Name

Natuerliche Person

kern

Juristische Person

KundenKern

G i b Te l e f o n n u m m e r ( )

KundenRolle

rollen

GibKundennummer() Kundenummer

Gesellschafter

Kunde GibKundenummer()

GbRGesellschafter

GibKundenummer()

GmbHGesellschafter

kern

Anleger

Kreditnehmer

3


3.3


787

Durch die rekursive Anwendung des Musters sind zwei Kernkonzeptklassen entstanden. In einer Implementierung muß daher technisch zwischen einem Wurzelkonzept und einem Kernkonzept unterschieden werden. Um die Verdopplung der Exemplarvariablen kern in einem rekursiven Rollenkonzept zu vermeiden, sollte der Zugriff auf einen Kern nur über eine virtuelle Operation erfolgen. Der eigentliche Verweis auf das Kernobjekt ist dann in den jeweiligen konkreten Rollenkonzepten zu definieren. ❑ Verwalten einer Subjektidentität.

Neben der technischen Identität von Kern- und Rollenobjekten existiert eine fachliche Identität, die die Rollenobjekte und ihr Kernobjekt als ein Subjekt identifiziert. Da alle Rollenobjekte ihr Kernobjekt kennen, kann diese Subjektidentität einfach über die technische Identität des Kernobjekts hergestellt werden. Zwei Rollenobjekte sind Teil desselben Subjekts, wenn sie dasselbe Kernobjekt erweitern. Bei einer rekursiven Anwendung des Rollenmusters bezieht sich die Subjektidentität auf das Wurzelobjekt. Zwei Rollenobjekte Anleger und GbRGesellschafter sind subjektidentisch, wenn sie auf dasselbe Wurzelobjekt NatuerlichePerson verweisen.

3


3.3


788

❑ Kombination von Vererbungs- und Rollenhierarchien.

Rollenhierarchien können, da sie mittels normaler Vererbung realisiert sind, einfach mit Vererbungshierarchien kombiniert werden. Sowohl Kern- als auch Rollenkonzepte lassen sich mittels Vererbung spezialisieren. So spezialisieren die Klassen NatuerlichePerson und JuristischePerson das Kernkonzept Kunde und die Klassen GbR-Gesellschafter und GmbH-Gesellschafter das Rollenkonzept Gesellschafter. Das Objektdiagramm in Abbildung 3-79 stellt ein Subjekt Person dar, das aus dem Kernkonzept NatuerlichePerson und den beiden Rollenkonzepten GmbH-Gesellschafter und Kunde besteht. Die Rolle Kunde nimmt zusätzlich die Rolle Kreditnehmer wahr. Abb. 3-79

eineNatürliche Person

Ein Objektdiagramm mit

Rollen: Name: Hans Müller Telefon: 040-8587638 ...

ein GmbHGesellschafter Gesellschaft: Muster-GmbH Telefon: 089-84834723 kern

Rollen von Rollen

einKundenKern Rollen: Kundennr: 858848 ...

einKreditnehmer

kern

Kredit: 250.000,-Sicherheiten: ... kern

3


3.3


Der unten augeführte Programmcode zeigt die Realisierung des folgenden Beispiels: Ein Kernkonzept Person soll mit einer Rolle Kunde versehen werden. Um das Beispiel einfacher zu gestalten, berücksichtigt es nicht, daß eine Rolle mehrfach zu einem Kernobjekt hinzugefügt werden kann. Wir unterscheiden daher nicht zwischen einer Spezifikation für die Rollenerzeugung und der Rollenverwaltung. Zunächst stellen wir die Implementation der Klasse Person vor:

3

789 Beispielcode


3.3


790

class PersonenKern; // Deklaration des Typs PersonenKern; class PersonenRolle; // Deklaration des Typs PersonenRolle; class Person { public: // fachliche Operationen virtual Telefonnummer GibTelfonnummer() = 0; virtual void SetzeName(const String & einName) = 0; ... // Rollenmanagement bool IstDasselbeSubjektWie(Person * einePerson) { return (gibWurzelKern() == einePerson->GibWurzelKern()); } PersonenRolle * GibRolle(const Spez & Spez) { return ((* GibRollen())[eineSpez]); } virtual void FuegeRolleHinzu(const Spez & eineSpez) = 0; ... protected: virtual PersonenKern * GibWurzelKern() = 0; virtual map<Spez, PersonenRolle *> * GibRollen() = 0; };

3


3.3


791

Diese Implementation bildet die Oberklasse für die Klassen PersonenKern und PersonenRolle. Die Klasse PersonenKern ist dabei wie folgt realisiert: class PersonenKern : public Person { public: Telefonnummer GibTelefonnummer() {return meineNummer; }; void SetzeName(const String & einName) { meinName = einName; // ermoegliche die Erweiterbarkeit der Operation // Fuer alle Rollen, die _setzeName erweitert haben eineRolle->_setzeName(einName); }; ... void FuegeRolleHinzu(const Spez & eineSpez) { *Rollen[eineSpez] = PersonenRolle :: VermittleFuer(eineSpez, this); }

3


3.3


792

protected: PersonenKern * GibWurzelKern() { return this; }; map<Spez, PersonenRolle *> * GibRollen() { return Rollen; }; private: Telefonnummer meineNummer; String meinName; map<Spez, PersonenRolle *> * Rollen; };

Als nächstes wird die Klasse PersonenRolle als Oberklasse aller Rollenkonzepte realisiert. Sie leitet alle aufgeschobenen Operationen an das von einem Rollenobjekt umwickelte Kernobjekt weiter. Die Klasse definiert zudem für die fachlichen Operationen, die ein Rollenkonzept erweitern, eine leere Einschuboperation.

3


3.3


793

class PersonenRolle : public Person { public: friend class PersonenKern; Telefonnummer GibTelefonnummer() { return GibPersonenKern()->GibTelefonnummer(); }; void SetzeName(const String & einName) { GibPersonenKern()->SetzeName(einName); }; void FuegeRolleHinzu(const Spez & eineSpez) { GibPersonenKern()->FuegeRolleHinzu(eineSpez); } ... protected: virtual void _setzeName(const String & einName) {}; // HŠndler Operationen static PersonenRolle * VermittleFuer(const Spez &, PersonenKern *); virtual PersonenKern * GibPersonenKern() = 0; PersonenKern * GibWurzelKern() { return GibPersonenKern(); }; map<Spez, PersonenRolle *> * GibRollen() { return GibPersonenKern()->GibRollen(); }; };

3


3.3


794

Die Unterklassen der Klasse PersonenRolle definieren konkrete Rollenkonzepte. Die nachfolgende Implementation zeigt die Rolle Kunde: class Kunde : public PersonenRolle { public: virtual void _setzeName(const String & einName) { // erweiterte Implementierung ... }; Kundennummer GibKundennummer( return meineKundennummer; ); protected: Kunde(PersonenKern * einKern) { kern = einKern; }; PersonenKern * GibPersonenKern() { return kern; }; private: PersonenKern * kern; Kundennummer meineKundennummer; };

3


3.3


795

Ein Klient würde wie folgt mit einer Person und einer Rolle Kunde umgehen: Person * einePerson = Datenbank :: LadePerson("Hans MŸller"); Kunde * einKunde = dynamic_cast einePerson->GibRolle(typeid(Kunde)); if (einKunde) { einKunde->SetzeName("Hans MŸller-Ganzenbein"); // hat geheiratet out GibName() GibFelder(); iterator i(eineWerteListe); FachlicherWert * einWert; FachlicherIAT * einIAT; while( einWert = i.getNext() ) { // erzeuge den entsprechenden Interaktionstyp einIAT = FachlicherIAT :: erzeugeFuer(einWert); // Positioniere den IAT ... einIAT->show(); } } ... };

3


3.3


807

Intern müßte die Klasse FachlicherIAT lediglich eine Zuordnung 13 (beispielsweise als Hashtabelle) führen, die den dynamischen Typ eines fachlichen Wertes einem konkreten Interaktionstyp zuordnet. Dieser Prozeß ist effizient und läßt sich in konstanter Zeit durchführen. Der Produkthändler sollte in den folgenden Situationen verwendet werden:

Anwendbarkeit

❑ Wenn ein Klient kein Wissen darüber besitzen soll, welche

Dienstleistung von welchem konkreten Hersteller erbracht wird. Der Klient ist somit vollständig von der Existenz konkreter Hersteller entkoppelt. ❑ Wenn die Spezifikation der zu erbringenden Dienstleistung erst

zur Laufzeit festgelegt werden kann. ❑ Wenn die Zuordnung zwischen der Spezifikation und dem

Hersteller, der die Dienstleistung erbringt, statisch oder zur Laufzeit des Systems angepaßt werden soll, ohne dabei das Offen-Geschlossen-Prinzip zu verletzen. 13. Der dynamische Typ eines Objektes kann in C++ über die RuntimeType-Information (RTTI)-Schnittstelle ermittelt werden.

3


3.3


808

Der Produkthändler sollte nicht als genereller Ersatz für die direkte Objekterzeugung oder für die Entwurfsmuster Fabrikmethode oder abstrakte Fabrik eingesetzt werden. Denn mit dem Einsatz von Produkthändlern sind auch Nachteile verbunden, wie etwa eine höhere Komplexität und damit auch eine höhere Fehleranfälligkeit des Anwendungssystems. Die in Abbildung 3-81 aufgezeigte Struktur geht von der Annahme aus, daß Produkte, die durch einen Händler vermittelt werden, jeweils neu zu erzeugen sind. Diese Einschränkung haben wir getroffen, da dadurch die Präsentation der Struktur vereinfacht wird. Es stellt allerdings keine Schwierigkeit dar, anstatt der Erzeugung eines neuen Objektes aus Ressourcengründen ein bereits im System existierendes Objekt zu vermitteln.

3

Struktur


3.3


809 Klient

Erzeuger

ProduktHaendler Produkt erzeugeFuer(Spez) Erzeuger ermitteln(Spez)

Produkt

// erzeugt ein neues // Objekt Produkt erzeuge()

static Produkt erzeugeFuer(Spez) static ObjektHaendler GibHaendler()

hinzufuegen(Spez, Erzeuger) ersetzen(Spez, Erzeuger) entfernen(Spez)

Spezifikation (Spez) boolean istGleich (Spez) int Hashwert()

KonkretesProduktA

KonkreterErzeugerA Produkt erzeuge()

KonkreterErzeugerB

KonkretesProduktB

Produkt erzeuge()

TypSpezifikation

ID Spezifikation

return new KonkretesProduktB;

Abb. 3-81 Die Struktur des Händlers

3


3.3


810

Der gepunktete Pfeil von der abstrakten Klasse Erzeuger zur abstrakten Klasse Produkt soll verdeutlichen, daß die Klasse Erzeuger lediglich den Typ der Klasse Produkt kennen muß, um den Rückgabewert (einen Zeiger vom Typ Produkt) der Operation erzeuge() zu deklarieren. Der Compiler benötigt zur Übersetzung der Klasse Erzeuger kein Wissen über den Aufbau der Klasse Produkt. In C++ reicht daher die Deklaration des Typs Produkt in der Klasse Erzeuger aus. Es entsteht somit keine zyklische Abhängigkeit zwischen den Klassen ProduktHaendler, Erzeuger und Produkt. Der Produkthändler wird in der Regel nie direkt von einem Klienten benutzt. Die Objekterzeugung erfolgt stets über die Produktklasse. Dies soll durch den gestrichelten Pfeil vom Klienten zum Händler symbolisiert werden. Klient (Editor)

Teilnehmer

❑ erzeugt eine Spezifikation, die das gewünschte Produkt

(Objekt) beschreibt, ❑ initiiert den Erzeugungsprozeß, indem er entweder an der

Klasse Produkt oder direkt an einem Produkthändler die Erzeugung anstößt. Das gewünschte Produkt wird dabei mittels einer Spezifikation beschrieben.

3


3.3


811

Produkt (FachlicherIAT) ❑ definiert die Schnittstelle der Klassenhierarchie, von der Pro-

dukte erzeugt (vermittelt) werden sollen, kann unter Verwendung eines Produkthändlers Produkte erzeugen. KonkretesProdukt (IATBetrag, IATDatum, IATKreditbetrag) ❑ repräsentiert ein konkretes Produkt.

ProduktHaendler ❑ verwaltet und pflegt die Zuordnung von Spezifikationen zu

einem konkreten Produkt bzw. einem Erzeugerobjekt, das ein konkretes Produkt instanziieren kann, ❑ läßt anhand einer Spezifikation ein konkretes Produkt erzeu-

gen. Erzeuger ❑ definiert die Schnittstelle, um ein Exemplar eines konkreten

Produkts erzeugen zu können. KonkreterErzeuger ❑ erzeugt genau ein konkretes Produkt.

3


3.3


812

Spezifikation (ein fachlicher Wert) ❑ beschreibt eine Dienstleistung, so daß der Produkthändler

einen entsprechenden Erbringer der Dienstleistung (ein Produkt) erzeugen kann, ❑ muß eine eindeutige Identifikation des gewünschten Dienst-

leistungsprodukts sein. Die in Abbildung 3-82 dargestellte Interaktion wird zur Laufzeit des Systems zwischen den Objekten realisiert:

Interaktionen

❑ Der Klient übergibt dem ProduktHaendler eine Spezifikation

mit der Aufforderung, ein entsprechendes Objekt zu erzeugen. ❑ Der ProduktHaendler verwaltet eine Hashtabelle, aus der er

mit Hilfe der Spezifikation den entsprechenden Erzeuger ermittelt. ❑ Der ProduktHaendler ruft an einem konkreten Erzeuger (z.B.

einem Objekt vom Typ KonkreterErzeugerA) die Operation erzeuge auf. ❑ Ein KonkreterErzeuger instanziiert durch Aufruf des new-

Operators ein konkretes Produkt und gibt dieses an den Produkthändler zurück.

3


3.3

einKlient

eine Spezifikation


ein Produkthändler

eine konkrete Produktklasse

ein Erzeuger

813 Abb. 3-82 Die Zusammenarbeit der Objekte im Entwurfsmuster

new erzeugeFuer Hashwert ermitteln erzeuge new

Das Entwurfsmuster Produkthändler ist mit den folgenden Konsequenzen und Vorteilen verbunden:

3

Konsequenzen


3.3


814

❑ Klienten können vollständig von konkreten Produkten ent-

koppelt werden, da sie die Objekterzeugung nicht direkt unter Verwendung der new-Operation, sondern indirekt über einen Produkthändler durchführen. Der Klient beschreibt das angeforderte Produkt über eine Spezifikation. ❑ Klienten können in tieferliegenden Schichten Produkte aus

höherliegenden Schichten instanziieren, ohne daß dadurch eine Abhängigkeit entsteht. Greift der Klient auf ein konkretes Produkt lediglich unter der Schnittstelle der aufgeschobenen Produktklasse zu, dann kann er mittels eines Händlers ein konkretes Produkt referenzieren, ohne die konkrete Produktklasse zu kennen. ❑ Die konkrete Produktklasse, von der ein Objekt erzeugt wer-

den soll, kann zur Laufzeit ermittelt werden. Die gewünschte Dienstleistung wird dann in Form einer Spezifikation beschrieben und an den Produkthändler zur Erzeugung übergeben. ❑ Die Zuordnung einer Spezifikation zu einem konkreten Pro-

dukt ist konfigurierbar.

3


3.3


815

Unter Verwendung der am Produkthändler implementierten Operationen hinzufuegen, entfernen und ersetzen kann die Zuordnung statisch bei Start des Systems oder zur Laufzeit verändert werden. Dadurch lassen sich Anwendungssysteme auf der Basis von Rahmenwerken und Klassenbibliotheken konfektionieren. ❑ Kontextspezifisch lassen sich für eine Klassenhierarchie unter-

schiedliche Produkthändler verwenden. Eine abstrakte Produktklasse könnte mehrere Produkthändler verwalten (in Abbildung 3-82 der Einfachheit halber nicht dargestellt). Dadurch kann ein Anwendungssystem zwischen verschiedenen Produkthändlern wählen und sich kontextabhängig unterschiedliche Produkte erzeugen lassen. Im Beispiel des Formulareditors könnte die Klasse FachlicherIAT zwei unterschiedliche Produkthändler verwalten. Abhängig von dem zu editierenden Formular würde dann entweder der allgemeine Produkthändler ausgewählt, bei dem der fachliche Wert Betrag mit einem IATBetrag editiert wird, oder ein spezieller Produkthändler, der einem Betrag den IATKreditbetrag zuordnet. Um Zuordnungen nicht mehrfach führen zu müssen, sollten die verschiedenen Produkthändler über eine Zuständigkeitskette (Chain of Responsibility) untereinander verbunden sein (vgl. [Gamma et al. 96]).

3


3.3


816

❑ Die Klassenhierarchie der Produkte kann einfach weiterent-

wickelt werden. Da der Klient lediglich von der abstrakten Produktklasse abhängig ist, können Änderungen an konkreten Produktklassen einfach vorgenommen werden. Zudem lassen sich neue Produktklassen leicht zu einem bestehenden Rahmenwerk oder Anwendungssystem hinzufügen. Es müssen lediglich die Konfigurationsbeschreibungen, die die Zuordnung von Spezifikationen zu konkreten Produktklassen enthalten, angepaßt werden. Wenn zusätzlich die auf S. 368ff. vorgestellte Trennung von Konzept- und Realisierungsteil eingehalten wird, ist nur eine Neuübersetzung der Realisierungsbibliothek notwendig.

3


3.3


Formulareditor

Gegenstandsbereich

Fachlicher IAT

Erzeuger

Erz_IAT Datum

817

Erz_IAT Zinssatz

Produktbereich Kredit

IAT Datum Erz_IAT Betrag

Fachlicher Wert

Datum IAT Zinssatz

Zinssatz IAT Betrag

Erz_IAT KreditBetrag

Betrag

IATKreditBetrag

Abb. 3-83

Wir können somit durch das Entwurfsmuster Händler Rahmenwerke einer Schicht auch im Punkt Objekterzeugung schließen und trotzdem für Veränderungen offen halten. Dies ist mit anderen propagierten

3

Aufteilung der Erzeuger auf Gegenstands- und Produktbereich


3.3


818

Konstruktionen bisher nur bedingt möglich. Das Entwurfsmuster erleichtert daher die Weiterentwicklung von Klassenbibliotheken und Rahmenwerken und ermöglicht zudem eine einfache Konfektionierung von Anwendungssystemen (vgl. Abbildung 3-83). Die Verwendung des Musters ist allerdings auch mit Nachteilen verbunden: ❑ Erhöhte Komplexität der Strukturen und Abhängigkeiten in

Programmen: Der Erzeugungsprozeß von Objekten wird zugunsten einer Flexibilisierung nicht mehr statisch im Programmcode beschrieben. Dadurch kann die Objekterzeugung nicht mehr vom Übersetzer geprüft werden. Zudem ist der Programmcode für einen Softwareentwickler schwerer verständlich, da die Klasse, von der ein Objekt erzeugt werden soll, nicht mehr direkt angegeben ist. ❑ Erhöhte Fehleranfälligkeit:

Falsche Konfigurationen, d.h. Zuordnungen von Spezifikationen zu konkreten Produktklassen, können zu Fehlern führen, die wegen der fehlenden new-Operation im Programmcode nur schwer zu lokalisieren sind.

3


3.3


819

❑ Erweiterte Konfigurationsbeschreibung:

Mittels eines Produkthändlers kann die Konfiguration eines Systems sowohl statisch als auch zur Laufzeit einfach an geänderte Bedingungen angepaßt werden. Um eine Konfiguration überhaupt beschreiben zu können und dafür zu sorgen, daß bei einer C++-Implementierung der Linker konkrete Produktklassen beim Binden einer Bibliothek oder eines Anwendungssystems nicht unberücksichtigt läßt, sind spezielle Konfigurationsbeschreibungen notwendig. In der Konfigurationsbeschreibung wird die konkrete Produktklasse explizit referenziert. Diese Referenzierung ist notwendig, da der Aufruf der new-Operation im Code des Klienten fehlt (das Produkt wird über den Händler vermittelt) und konkrete Produktobjekte nur über die Schnittstelle der aufgeschobenen Produktklasse angesprochen werden, also nirgends eine Operation der konkreten Produktklasse aufgerufen wird. Im Implementierungsteil diskutieren wir verschiedene Alternativen für eine Konfigurationsbeschreibung. ❑ Mehrdeutige Spezifikation:

Je nach Typ einer Spezifikation kann es vorkommen, daß zu einer Spezifikation mehrere konkrete Produkte existieren. Soll

3


3.3


820

ein Produkthändler beispielsweise zu einem Material ein passendes Werkzeug ermitteln, so kann es in einem Anwendungssystem, das sich aus mehreren Produktbereichen zusammensetzt, mehrere passende Werkzeuge geben. Entweder muß dann durch zusätzliches Kontextwissen die Spezifikation eindeutig gemacht werden, oder es sind Regeln anzugeben, wie dieser Konflikt zu lösen ist. Zusätzliches Kontextwissen wäre etwa der Produktbereich, in dem das Werkzeug implementiert sein soll. Regeln könnten sich auch auf den Spezialisierungsgrad der konkreten Produktklasse beziehen. Dieser könnte durch den Abstand beschrieben werden, den die konkrete Produktklasse in der Klassenhierarchie von der aufgeschobenen Produktklasse aufweist. Im Beispiel der Interaktionstypen für die fachlichen Werte hätte die Klasse IATKreditbetrag einen höheren Spezialisierungsgrad als die Klasse IATBetrag. ❑ Argumente für die Objekterzeugung:

Benötigen konkrete Produktklassen bei der Objekterzeugung zusätzliche Argumente, so müssen diese mit übergeben werden. So braucht beispielsweise ein Interaktionstyp üblicherweise einen Verweis auf sein Vaterfenster. Wird zur Übergabe der Argumente der gängige Mechanismus einer Parameterliste

3


3.3


821

verwendet, so lassen sich nur solche Argumente übergeben, die für alle Produktklassen gleich sind. Denn der Produkthändler kennt vom Typ her nur die abstrakte Produktklasse. Unterschiedliche Argumente lassen sich in generischen Parameterlisten übergeben (vgl. [Mätzel & Bischofberger 96]). Dabei muß unbedingt sichergestellt sein, daß der Klient keine impliziten Annahmen über das zu erzeugende Produkt trifft. Ansonsten können Änderungen an der Konfiguration zu Fehlern führen, wenn ein anderes als das implizit angenommene Objekt instanziiert wird. Die Implementierung des Entwurfsmusters muß sich mit den folgenden vier Aspekten beschäftigen: den Spezifikationen, den Erzeugern, dem Produkthändler und den Konfigurationsbeschreibungen. Die Zuordnung von Spezifikation zu konkretem Produkt (mittels eines Erzeugungsobjekts) kann sehr einfach in Form einer Hashtabelle realisiert werden.

Implementierung

❑ Spezifikationen können sowohl als einfache Datentypen (z.B.

Zahlen oder Zeichenketten) als auch in einer eigenständigen Klassenhierarchie realisiert werden. Die Modellierung einer Klassenhierarchie hat den Vorteil, daß sich eine einheitliche Schnittstelle für Spezifikationsobjekte in Form einer abstrakten

3


3.3


822

Spezifikationsklasse definieren läßt (vgl. Abbildung 3-81, S. 396). Produkthändler können dann auf der Basis dieser Schnittstelle implementiert werden und sind daher einfach um neue Spezifikationstypen erweiterbar. ❑ Erzeuger lassen sich in Form von Prototypen oder speziellen

Erzeugerobjekten realisieren. Unabhängig von der Methode, die gewählt wird, sollte die Realisierung nicht mit der manuellen Implementierung einer Erzeugerklasse je konkreter Produktklasse verbunden sein. Die beiden unterschiedlichen Realisierungsformen stellen sich wie folgt dar: – Prototypen: Bei dieser Form der Implementierung verwaltet der Produkthändler jeweils ein prototypisches Objekt pro konkretem Produkt. Soll ein neues Exemplar dieses Produkts erzeugt werden, so wird der Prototyp kopiert (vgl. [Gamma 92]). – Verwendung einer jeweils eigenständigen Erzeugerklasse: Um die entsprechenden Klassen in C++ nicht einzeln kodieren zu müssen, können Templates zur Generierung eingesetzt werden. Dabei ist sowohl ein Template für die Klasse Erzeuger als auch eines für die Klasse KonkreterErzeuger notwendig. Das Template für die Klasse Erzeuger

3


3.3


823

läßt sich mit der Klasse des aufgeschobenen Produktes konfigurieren, dasjenige für KonkreterErzeuger wird mit einer konkreten Produktklasse instanziiert. Sie implementieren die im Erzeuger aufgeschobene Operation erzeuge. Die nachfolgend beschriebenen Templates können somit für jede Produkthierarchie verwendet werden, bei denen die Konstruktoren der konkreten Produktklassen keine Parameter erwarten. Werden Parameter benötigt, so müssen die beiden Templates repliziert und mit zusätzlichen Templateparametern für den Argumenttyp versehen werden. template class Erzeuger { public: virtual ProduktTyp * erzeuge() = 0; }; template class KonkreterErzeuger : public Erzeuger { public: ProduktTyp * erzeuge() {return new KonkreterProduktTyp}; };

3


3.3


824

❑ Der Produkthändler verwaltet die Zuordnung von Spezifika-

tionen zu konkreten Produkten in Form einer Hashtabelle. Da er die eigentliche Objekterzeugung anstößt, ist er produktspezifisch. Für jede Klassenhierarchie, deren Klassen über einen Produkthändler instanziierbar sein sollen, muß daher ein separater Produkthändler implementiert werden. Durch den Einsatz von Templates läßt sich aber ein allgemeiner Händler beschreiben. Ein entsprechendes Template läßt sich folgendermaßen formulieren:

template class ProduktHaendler { public: ProduktTyp * erzeugeFuer(const Spez &); void hinzufuegen(Spez *, Erzeuger *); void ersetzen(const Spez &, Erzeuger *); void entfernen(const Spez &); private: Erzeuger * ermittle(const Spez &); ... };

3


3.3


825

❑ Der Klient beschreibt gewünschte Dienstleistungen in Form

einer Spezifikation. Die Konfiguration des Produkthändlers, d.h. die Zuordnung von einer Spezifikation zu einem konkreten Produkt, muß demnach für jedes Anwendungssystem definiert werden. Folgende Möglichkeiten bieten sich an: – Registrierungsobjekte: Für Produkte, bei denen die Zuordnung von Spezifikation zu konkreter Produktklasse statisch definiert werden kann, lassen sich sogenannte Registrierungsobjekte einsetzen (vgl. [Bäumer & Riehle 97]). Diese sind als Klassenvariablen der konkreten Produktklasse implementiert und werden daher beim Start eines Anwendungssystems automatisch erzeugt und initialisiert. Bei ihrer Initialisierung melden sie dann ein für ihre Produktklasse passendes Erzeugungsobjekt unter einer statisch festgelegten Spezifikation beim Produkthändler der aufgeschobenen Produktklasse an. In dem vorgestellten Beispiel der fachlichen Werte und Interaktionstypen würde das Registrierungsobjekt der Klasse IATDatum ein Erzeugungsobjekt vom Typ KonkreterErzeuger instanziieren und beim Produkthändler der Klasse FachlicherIAT anmelden. Als Spezifikation wird dabei der Typ der Klasse Datum verwendet. Dieser läßt sich in C++ durch die Operation typeid ermitteln.

3


3.3


826

Registrierungsobjekte sind allerdings mit den folgenden beiden Nachteilen behaftet: Erstens sind Änderungen der Konfiguration mit Anpassungen der konkreten Produktklasse verbunden. Dies führt somit jeweils zu einer Öffnung des korrespondierenden Rahmenwerks respektive der Schicht. Unter diesem Gesichtspunkt sollte man Registrierungsobjekte nur einsetzen, wenn die Konfiguration eine hohe Stabilität aufweist oder Standardfälle beschreibt. Zweitens führt die Verwendung von Registrierungsobjekten nicht zur externen Referenzierung der konkreten Produktklasse (die Referenzierung der Produktklasse erfolgt in der Produktklasse selbst). Der Binder kann somit nicht sicherstellen, daß alle zur Ausführungszeit des Systems benötigten Klassen zum System hinzugebunden werden. – Konfigurationsskripte: Die Konfiguration der einzelnen Produkthändler wird in einem speziellen Konfigurationsskript festgelegt, das mittels eines Präprozessors in C++Code übersetzt wird. Der Code instanziiert ein Erzeugungsobjekt und registriert es unter der konfigurierten Spezifikation bei einem Produkthändler. Die Konfiguration des Produkthändlers läßt sich somit aus den konkreten Produktklassen herausziehen.

3


3.3


827

Der generierte Code für die Standardkonfiguration fachlicher Interaktionstypen sieht wie folgt aus: void StandardIATKonfiguration(void) { ... ProduktHaendler * einHaendler = FachlicherIAT :: GibHaendler(); // ordne Betrag einen IATBetrag zu, // indem unter dem Typ der Klasse // Betrag (new TypSpezifikation(typeid(Betrag))) // ein Erzeuger fŸr den IATBetrag //(new KonkreterErzeuger) // eingetragen wird. einHaendler->fuegeHinzu( new TypSpezifikation(typeid(Betrag)), new KonkreterErzeuger); // ordne einem Datum ein IATDatum zu // (analog zu oben) einHaendler->fuegeHinzu( new TypSpezifikation(typeid(Datum)), new KonkreterErzeuger); ... }

3


3.3


828

Soll diese Standardkonfiguration an besondere Bedürfnisse angepaßt werden, weil beispielsweise für einen Betrag der spezielle IATKreditbetrag zu verwenden ist, dann läßt sich diese Anpassung einfach in einem gesonderten Konfigurationsskript beschreiben: KreditKonfiguration() { ... ProduktHaendler * einHaendler = FachlicherIAT :: GibHaendler(); // ordne einem Betrag einen IATKreditBetrag zu einHaendler->ersetze( new TypSpezifikation(typeid(Betrag)), new KonkreterErzeuger); ... }

Das Hauptprogramm des Anwendungssystems muß nun die beiden Operationen StandardIATKonfiguration und KreditKonfiguration aufrufen. Dadurch wird die notwendige Konfiguration des Produkthändlers vollzogen. Zudem wird sichergestellt, daß alle zur

3


3.3


829

Ausführungszeit des Systems benötigten Klassen referenziert werden, so daß der Binder diese zum Anwendungssystem hinzufügt. Eine Kombination aus Konfigurationsskripten und Registrierungsobjekten ermöglicht es, Standardfälle im Programmcode der jeweiligen Klassen bereitzustellen und Änderungen in den Skripten zu beschreiben. Die Interaktionstypen könnten sich beispielsweise mittels Registrierungsobjekten für bestimmte fachliche Werte beim Händler FachlicherIAT anmelden. Dann muß ein Softwareentwickler im Konfigurationsskript lediglich die Änderungen beschreiben. Allerdings muß sichergestellt sein, daß die Abarbeitung von Registrierungsobjekten und Konfigurationsskripten zweistufig erfolgt. Zuerst muß ein System alle Registrierungsobjekte verarbeiten. Erst danach dürfen die Konfigurationsskripten abgearbeitet werden. Liegt keine Kombination aus Standardfall und Änderungen vor, sind Konfigurationsskripte den Registrierungsobjekten vorzuziehen, da sie einfacher zu verstehen sind. Außerdem beschreiben sie die Konfiguration eines Systems an einem Ort und, da sie zum Anwendungssystem gehören, können sie einfach angepaßt werden, ohne daß man dazu ein Rahmenwerk öffnen muß.

3


3.3


In den Abschnitten Motivation und Implementierung dieses Musters ist bereits ein vollständiges Beispiel eingeführt worden. Wir skizzieren daher die beiden folgenden Beispiele nur kurz (für eine ausführliche Diskussion siehe [Bäumer & Riehle 97]). Das erste Beispiel betrifft die Erzeugung von Objekten, die aus einer Datei oder einer relationalen Datenbank geladen werden (vgl. [Riehle et al. 97]). Das zweite Beispiel legt dar, wie zu Materialien passende Werkzeuge erzeugt werden können (vgl. [Riehle 95b]). In fast jedem größeren Anwendungssystem besteht die Notwendigkeit, Objekte persistent in einem Dateisystem oder einer relationalen Datenbank zu speichern und anschließend wieder zu laden (s. Kapitel 4.2). Beim Speichern wird dabei der dynamische Typ jedes Objekts in Form einer Klassenidentifikation oder des Klassennamens mit abgespeichert. Beim Laden wird nun anhand der Identifikation ein »leeres« Objekt erzeugt, das anschließend mit den gespeicherten Werten gefüllt wird. Ein Händler kann dabei die Zuordnung der Identifikation zu einem Erzeugerobjekt verwalten. Um ein Objekt zu erzeugen, muß ein Klient dann lediglich die Identifikation an den Händler übergeben. Existiert beispielsweise ein Aspekt Serialisierbar zum Speichern und Laden von Objekten, so könnte diese Klasse einen entsprechenden Händler verwalten. Dies stellt sich wie folgt dar:

3

830 Beispielcode


3.3


831

class Serialisierbar { public: // aufgeschobene Operationen zum Speichern und Laden ... static Serialisierbar * erzeugeFuer( const long Klassennummer) { return einHaendler.erzeugeFuer( IDSpezifikation(Klassennummer)); }; private: static ProduktHaendler<Serialisierbar> einHaendler; };

Das zweite Beispiel skizziert, wie ein Werkzeug mit Hilfe des Musters erzeugt wird. In einem Anwendungssystem bearbeiten wir Materialien mit Werkzeugen. Grundsätzlich müssen die Werkzeuge für die Arbeit mit Materialien geeignet sein. Umgekehrt gilt, daß je nach Konfiguration oder abhängig vom Arbeitskontext oder anderen Laufzeitfaktoren ein Material mit verschiedenen Werkzeugen bearbeitet werden kann. Die dynamische Zuordnung eines Materials zu einem Werkzeug sollte daher über einen Händler realisiert werden.

3


3.3


832

Serialisierer

Der Serialisierer ermöglicht es, beliebig komplexe Objektgeflechte in strukturierte externe Medien (wie z.B. Dateien, relationale Datenbanken, RPC-Buffer) zu schreiben und von dort wieder einzulesen (s. [Riehle et al. 97]). Er hilft, unterschiedliche Persistenzmechanismen (s. Kapitel 4.2) in Rahmenwerken und für die Interprozeßkommunikation (s. Kapitel 4.3) zu kapseln. Um fachliche Objekte persistent zu machen oder zu transportieren, wollen wir sie auf externen Medien abspeichern oder von dort lesen. Dazu ist Wissen über die externen Formate und Schnittstellen erforderlich. Anwendungsfachliche Klassen sollen jedoch kein Wissen über ihren technischen Verwendungszusammenhang haben. Dazu gehören vor allem externe Formate, in denen ihre Exemplare repräsentiert werden sollen, um sie zu speichern und zu übertragen.

Federführung: Wolf Siberski Ko-Autor: Dirk Bäumer, Daniel Megert, Dirk Riehle, Heinz Züllighoven

Problem

Aus diesem Grund ist es sinnvoll, dieses Wissen an technische Klassen zu delegieren. Diese sollen allerdings kein anwendungsfachliches Wissen enthalten, da sie sonst bei jeder Änderung des fachlichen Modells aktualisiert werden müssen.

3


3.3


833

Wir müssen daher anwendungsfachliche Klassen und diejenigen Klassen, die für den Umgang mit externen Medien verantwortlich sind, so stark wie möglich entkoppeln. Für größere Systeme ist es typisch, daß die fachlichen Objekte in verschiedenen externen Medien gespeichert werden müssen.

Kontext

Wir erläutern dies am Beispiel eines Kundenobjekts mit seiner Kontenliste. Ein solches Kundenobjekt nützt nur wenig, wenn wir es nicht persistent machen können. Dazu verwenden wir in der Praxis typischerweise eine relationale Datenbank. Zudem werden die Zweigstellen einer Bank untereinander Kundendaten austauschen wollen. Dazu muß der Zustand eines Kundenobjekts z.B. durch einen RPC übertragbar sein. Falls ein Kundenberater den Kunden vor Ort besucht, müssen die dort erfaßten Kundendaten ebenfalls gesichert werden. Es bietet sich an, das Kundenobjekt zunächst in einer einfachen Datei abzuspeichern und erst in der Bank in die relationale Datenbank zu schreiben. Die Klassen Kundenobjekt oder Kontoliste sollen jedoch kein Wissen über die unterschiedlichen externen Formate und die Schnittstellen der Speicher- und Transportsysteme haben, sonst hätte jede Änderung oder Erweiterung in diesem Bereich die Änderung dieser Anwendungsklassen zur Folge.

3


3.3


Delegiere das Schreiben und Lesen externer Formate an eigens dafür vorgesehene Klassen. Teile die Verantwortlichkeiten in einen Leser und einen Schreiber auf. Entwickle ein Leser/Schreiber-Klassenpaar für jedes externe Medium. Diese Klassen entkoppeln die Anwendungsklassen von den externen Medien. Jeder konkrete Schreiber implementiert die Schreiber-Schnittstelle, jeder konkrete Leser die Leser-Schnittstelle. Leser und Schreiber bilden jeweils eine eigene Spezialisierungshierarchie (s. Abbildung 3-84).

Leser

DateiLeser DateiSchreiber

Beispiel einer Leser-/

Schreiberschnittstelle

RPCBufferLeser RPCBufferSchreiber

Lösung

Abb. 3-84

Schreiber

Leserschnittstelle

834

Schreiber-Hierarchie

RDBLeser RDBSchreiber

3


3.3


835

Ebenso wie Anwendungsklassen keine externen Medien kennen sollten, so wenig sollten auch die Leser und Schreiber die konkreten Anwendungsklassen kennen. Um dies zu erreichen, bieten alle Anwendungsklassen die Schnittstelle Serialisierbar an. Diese Schnittstelle hat zwei Operationen: ❑ leseVon nimmt einen Leser als Parameter und verwendet ihn

zum Lesen. ❑ schreibeAuf nimmt einen Schreiber als Parameter und ver-

wendet ihn zum Schreiben. Leser und Schreiber arbeiten ausschließlich auf der Schnittstelle Serialisierbar und haben daher kein Wissen über die konkreten Anwendungsklassen (s. Abbildung 3-85).

3


3.3


Serialisierbar

Leser

Schreiber

836 Abb. 3-85

leseVon(Leser)

Die Schnittstelle

schreibeAuf(Schreiber)

Serialisierbar in ihrem Kontext

Kunde

Konto

Die Anwendungsklassen implementieren diese Schnittstelle, indem sie für jedes ihrer Attribute die passende Lese- und Schreiboperation des übergebenen Lesers oder Schreibers aufrufen. Leser und Schreiber bieten für jeden primitiven Datentyp (wie int, double) und für Objekte und Objektreferenzen vom Typ Serialisierbar eine Leseund Schreiboperation an. Ein serialisierbares Objekt interagiert mit seinem Leser oder Schreiber, indem das Objektgeflecht auf Attributebene traversiert wird. Während des Traversierens wird das Objektgeflecht in das externe Format umgewandelt oder von dort zurück konvertiert. So können sowohl die Anwendungsklassen als auch die Leser- und Schreiberklassen unabhängig von einander entwickelt werden.

3


3.3


837

Das Serialisierermuster ist geeignet, wenn die Anwendungsobjekte in unterschiedliche externe Datenformate umgewandelt werden müssen und die Anwendungsklassen selbst kein Wissen über diese Formate haben sollen. Als externe Medien kommen nicht nur »Datenströme« (Streams) wie Dateien oder RPC-Buffer in Frage, sondern auch relationale Datenbanken (vorausgesetzt, der Tabellenaufbau ist an den Objektstrukturen ausgerichtet). Das Muster sollte nicht angewendet werden, wenn das Format je nach Anwendungsklasse unterschiedlich ist und daher jede konkrete Klasse Formatinformationen liefern muß. Dies ist typischerweise der Fall, wenn Objekte in Altsystemen abgelegt oder aus Daten dieser Altsysteme erzeugt werden müssen. Der Serialisierer eignet sich außer zur Konvertierung auch zur Implementierung eines generischen Objektkopierers. Man kann mit ihm auch einen Objektinspektor im Stil von Smalltalk realisieren.

Anwendbarkeit

Abbildung 3-86 gibt einen Überblick über die Struktur und die Teilnehmer des Serialisierermusters.

Struktur

3


3.3


838

Klient

Serialisierbar leseVon(Leser) schreibeAuf(Schreiber)

KonkretesElementA

Leser

Schreiber

int leseInt() string leseString() ... WerteTypN leseWerteTypN() Serialisierbar leseObjekt() Serialisierbar leseStartObjekt()

schreibeInt(int) schreibeString(string) ... schreibeWerteTypN(WerteTypN) schreibeObject(Serialisierbar) schreibeStartObjekt(Serialisierbar)

KonkretesElementB

KonkreterLeserA

KonkreterLeserB

KonkreterSchreiberA

ExternesMediumA

KonkreterSchreiberB

ExternesMediumB

Abb. 3-86 Die Struktur des Serialisierers

3


3.3


Leser/Schreiber: ❑ Deklarieren eine Leser-Schnittstelle zum generischen Lesen von Objekten und eine Schreiber-Schnittstelle zum generischen Schreiben. Diese Schnittstellen bestehen aus Lese- und Schreib-Operationen für jeden primitiven Datentyp und für serialisierbare Objekte und Referenzen darauf. ❑ Kapseln das externe Medium gegenüber den serialisierbaren Objekten.

839 Teilnehmer

Konkreter Leser / Konkreter Schreiber: ❑ Implementieren die Leser- und Schreiber-Schnittstelle für ein bestimmtes externes Medium und sein Format. ❑ Kapseln ein konkretes externes Medium gegenüber den Anwendungsklassen. Serialisierbar: ❑ Ist eine Schnittstellenklasse, die Operationen zum Akzeptieren eines Lesers und eines Schreibers deklariert. Diese Operationen müssen dem Leser/Schreiber die Attribute des serialisierbaren Objektes zur Verfügung stellen. ❑ Stellt eine Erzeuge-Operation zur Verfügung, die anhand einer

Klassen-Identifikation ein Objekt der entsprechenden Klasse erzeugt.

3


3.3


840

Konkretes Element (z.B. Kunde, Konto): ❑ implementiert die Operationen der Schnittstelle Serialisierbar. Externes Medium (z.B. Datei, RPC-Buffer): ❑ stellt die Schnittstelle zu einem externen Medium zur Verfügung. ❑ wird vom zugehörigen Leser und Schreiber benutzt. ❑ muß keine objektorientierte Schnittstelle besitzen; eine proze-

durale Schnittstelle ist ebenfalls möglich. Ein Leser oder Schreiber arbeitet auf der Serialisierbar-Schnittstelle, um serialisierbare Objekte zu lesen oder zu schreiben. Der Leser oder Schreiber übergibt sich selbst als Parameter an das serialisierbare Objekt. Das Objekt wiederum benutzt die übergebene Komponente, um mit ihm seine Attribute zu lesen oder zu schreiben. Dies führt zu einem rekursiven Abstieg in der zu bearbeitenden Objektstruktur, bei dem sich Leser/Schreiber und die zu serialisierenden Objekte gegenseitig aufrufen. Während des Schreibens ruft das Objekt für jedes seiner Attribute die passende Schreiboperation des Schreibers auf. Attribute mit primitivem Typ werden direkt zum Schreiben an das externe Medium

3

Interaktionen


3.3


841

weitergegeben. Referenzen auf andere Objekte werden je nach Schreibstrategie (s. Abschnitt Implementierung in diesem Muster) behandelt. Falls das referenzierte Objekt geschrieben werden soll, fordert der Schreiber es dazu auf, ihm seine Attribute zum Schreiben zu übergeben. Beim Lesen liest der Leser zunächst die Klassen-Identifikation des zu lesenden Objekts. Dann erzeugt er ein Objekt der entsprechenden Klasse und übergibt sich als Parameter dem neu erzeugten Objekt. Das neue serialisierbare Objekt liest durch Aufruf der passenden Operationen des Lesers jedes seiner Attribute. Falls eines der Attribute eine Objektreferenz ist, führt dies je nach Lesestrategie dazu, daß der Leser das referenzierte Objekt erzeugt und einliest. Ein konkreter Leser oder konkreter Schreiber benutzt die Schnittstelle seines externen Mediums, um Daten zu lesen bzw. zu schreiben.

3


3.3

einKlient

einExternesMedium


einKonkreterSchreiber

einKunde

842 eineKontenListe

schreibeStartObjekt(einKunde)

schreibe Objekt- und Typ-Id schreibeAuf(this)

schreibeString(Name)

schreibe String schreibeObject(Kontenliste)

schreibe Objekt-Rreferenz

schreibe Objekt- und Typ-Id schreibeAuf(this)

Abb. 3-87

Abbildung 3-87 zeigt ein Interaktionsdiagramm für ein Schreib-Beispiel. Der Klient ruft schreibeStartObjekt mit einem Kunden als Parameter; der Kunde hat als Attribute einen Namen und eine Kontenliste. Die gestrichelte Linie deutet an, daß der KonkreteSchreiber aktiv bleibt, während er am Kunden schreibeAuf aufruft.

Interaktionsdiagramm

Die Anwendung des Serialisierermusters hat folgende Konsequenzen:

Konsequenzen

3

eines Schreib-Beispiels


3.3


843

❑ Das Hinzufügen eines neuen Repräsentationsformats für die

Objekte ist leicht. Um Objektgeflechte auf ein neues und unvorhergesehenes externes Medium zu speichern, müssen wir nur ein neues Leser/Schreiber-Paar implementieren. Dazu genügt es oft, eine bereits vorhandene Standardimplementierung mit der neuen externen Schnittstelle zu parametrisieren. ❑ Das Wissen über externe Repräsentationsformate wird von

den Anwendungsobjekten ferngehalten. Die Anwendungsobjekte benutzen ausschließlich die Schnittstellen des abstrakten Lesers und Schreibers zum Lesen und Schreiben. Daher ist jedes externe Format effektiv vor ihnen gekapselt. ❑ Jede neue Anwendungsklasse muß die Serialisierbar-

Schnittstelle implementieren. Das erfordert, jedes Attribut durch Operationsaufruf zu lesen und zu schreiben. ❑ Die Zustandskapselung der Anwendungsobjekte wird aufge-

brochen. Für das Serialisierermuster ist es grundlegend, daß Leser und Schreiber den Zugriff auf den Zustand der Anwendungsobjekte erhalten. Dies stellt eine Verletzung der Zustandskapselung dar. Allerdings ist es für andere Klienten als Leser und Schreiber sehr schwierig, die Serialisierbar-

3


3.3


844

Schnittstelle zu mißbrauchen, um Informationen über den internen Zustand zu erhalten. ❑ Die von Leser und Schreiber unterstützten primitiven Daten-

typen müssen sorgfältig ausgewählt werden. Auf den ersten Blick erscheint es ausreichend, wenn nur Objektreferenzen und alle in der verwendeten Programmiersprache »eingebauten« Datentypen unterstützt werden. Es kann jedoch sinnvoll sein, auch weitere Fachwertetypen als primitive Datentypen zu unterstützen, wie z.B. Zeichenketten oder Datum. Dazu müssen für einen solchen Typ entsprechende Operationen zur Leser- und Schreiber-Schnittstelle hinzugefügt werden. Folgende Punkte sollten bei der Implementierung des Serialisierers berücksichtigt werden:

Implementierung

❑ Zwischen vollständiger und unvollständiger Serialisierung ent-

scheiden. Ein Objektgeflecht vollständig zu serialisieren bedeutet, jedes referenzierte Objekt zu bearbeiten. Das ist dann sinnvoll, wenn ein Objektgeflecht in eine Datei geschrieben oder aus ihr gelesen wird. In anderen Fällen, z.B. Datenbanken, ist es besser, eine andere Strategie zu verwenden, etwa nur diejenigen Objekte zu schreiben, die sich seit dem letzten Schreiben

3


3.3


845

verändert haben. Unvollständige Serialisierung ist erheblich komplexer als vollständige Serialisierung. Aber die vollständige Serialisierung kann sehr zeit- und speicheraufwendig werden, wenn aufgrund komplexer Objektgeflechte große Datenmengen zum oder vom externen Medium transportiert werden müssen. Strategien zur unvollständigen Serialisierung finden sich am Ende dieses Abschnitts. ❑ Objektidentität sicherstellen. Die meisten Objekte referenzie-

ren andere Objekte. In einem externen Format müssen diese Referenzen durch eine eindeutige Objektidentifikation (Objekt-ID) repräsentiert werden. Eine solche Identifikation muß nicht unbedingt global eindeutig sein. Es genügt, wenn sie innerhalb der Exemplarmenge einer Klasse eindeutig ist, weil die Klassen-Identifikation stets mitgeschrieben werden muß, um das Objekt später wieder lesen zu können. Es gibt verschiedene Möglichkeiten, eine Identifikation zu generieren: – Globaler Zähler: Viele Implementierungen verwenden einen globalen Zähler, um Objekt-IDs zu generieren. Für jedes neue Objekt wird der Zähler inkrementiert. Um sicherzustellen, daß der »Namensraum« für Objekt-IDs nicht ausgeht, sollte ein solcher Zähler 8 Byte groß sein.

3


3.3


846

– Externe ID: Oft stellen die externen Medien bereits IDs zur Verfügung, z.B. Datenbanksysteme. Solche Möglichkeiten sollten genutzt werden. ❑ Schreiben zusätzlicher Informationen. Oft ist es sinnvoll,

zusätzlich zum Typ und Wert eines Attributes weitere Informationen zu schreiben, z.B – Name des Attributes: Wurde der Attributname geschrieben, ist die Leseoperation unabhängig von der Reihenfolge, in der die Attribute geschrieben worden sind. Manche externen Medien benötigen den Attributnamen, um das Attribut korrekt schreiben oder lesen zu können. So kann in einer relationalen Datenbank der Attributname zur Identifizierung der Spalte für das Attribut dienen. – Flags zur Kennzeichnung von Attributen: Durch entsprechende Kennzeichen können z.B. persistente Attribute von transienten unterschieden werden. Das ist sinnvoll, wenn man den Serialisierer nicht nur für das Abspeichern nutzt, sondern auch für andere Funktionen wie z.B. das tiefe Kopieren von Objekten. Die konkreten Leser und Schreiber können die Flags auswerten, um zu entscheiden, ob sie das übergebene Attribut lesen oder schreiben müssen, oder ob sie es ignorieren können.

3


3.3


847

– Versionsnummer: Jedes Objekt kann eine Versionsnummer schreiben, die seine Implementierungsversion kennzeichnet. Dadurch ist eine (wenn auch minimale) Unterstützung für die Evolution des Anwendungssystems möglich. Konvertierungsoperationen der Anwendungsobjekte können für die Abwärtskompatibilität sorgen. ❑ Objektmanager zur Verfügung stellen. Sowohl beim Lesen als

auch beim Schreiben müssen wir Informationen darüber sammeln, welche Objekte bereits bearbeitet wurden, um mehrfaches Lesen/Schreiben oder schlimmstenfalls sogar eine Endlosschleife (bei zirkulären Referenzen) zu vermeiden. Eine mögliche Lösung bildet ein Objektmanager, der Objekttabellen mit den benötigten Informationen führt. Der Objektmanager kann gefragt werden, ob ein Objekt mit einer bestimmten ID bereits gelesen oder geschrieben wurde. Außerdem kann er eine Zuordnungstabelle von Objekt-IDs zu Objektreferenzen verwalten und damit für bereits gelesene Objekte eine Referenz zu einer ID liefern. ❑ Metaobjekt-Protokoll für die Implementierung der Seriali-

sierbar-Schnittstelle ausnutzen. Falls das Laufzeitsystem der verwendeten Sprache ein Metaobjekt-Protokoll zur Verfügung

3


3.3


848

stellt, das den Zugriff auf Objektattribute gestattet, können wir die Lese- und Schreiboperationen bereits in der Klasse Serialisierbar implementieren. Nachteilig ist, daß wir dann die Attribute nicht einfach als persistent oder transient markieren können. Eine interessante Ausnahme bietet Java, das nicht nur die Attributnamen, sondern auch ein Persistenz-Flag zur Verfügung stellt, so daß leseVon und schreibeAuf komplett auf der Basis des Metaobjekt-Protokolls implementiert werden können. ❑ Datenpuffer als externes Medium verwenden. Für datenstrom-

orientierte Medien (z.B. Dateien) können wir eine weitere Entkopplung erreichen, indem der Schreiber nicht direkt auf das Medium, sondern statt dessen in einen Puffer schreibt. Erst der gefüllte Puffer wird an das externe Medium übergeben. Analog läßt sich der Leser einen Puffer vom externen Medium füllen und beginnt erst dann das eigentliche Lesen der Objekte. Dadurch kann ein generisches Leser-/Schreiber-Paar mit vielen verschiedenen externen Medien zusammenarbeiten. ❑ Initialisierungsoperation für erzeugte Objekte einführen. Oft

müssen neu erzeugte Objekte initialisiert werden (z.B. Setzen der Anfangswerte für nicht-persistente Objekte). In diesem Fall

3


3.3


849

ist es sinnvoll, die Serialisierbar-Schnittstelle um eine Initialisierungsoperation zu ergänzen, die standardmäßig leer implementiert sein kann. Diese Operation sollte erst nach dem Lesen aller Attribute aufgerufen werden. Ansonsten kann das Objekt noch in einem inkonsistenten Zustand sein und die Initialisierung fehlschlagen. ❑ Mechanismus zur Objekterzeugung wählen. Während des

Lesens müssen die zu lesenden Objekte anhand ihrer KlassenID erzeugt werden. Dazu eignen sich verschiedene Erzeugungsmuster, z.B. die Fabrikmethode (s. [Gamma et al. 96]). In Smalltalk wird eine solche Operation bereits vom Laufzeitsystem zur Verfügung gestellt. In C++ ist die einfachste Lösung eine statische Operation (static function), die eine Zuordnung von Klassen-IDs zu (selbstdefinierten) Klassenobjekten mit Erzeuge-Operation oder zu Objektprototypen mit Kopieroperation enthält. Eine flexiblere Lösung bietet der Produkthändler (s. S. 389ff.). ❑ Verwendung von diamantförmigen Vererbungsstrukturen ver-

meiden. Wir müssen darauf achten, daß Attribute von Klassen, die über zwei Pfade geerbt werden, nicht doppelt geschrieben und gelesen werden. Dazu müssen die bereits bearbeiteten

3


3.3


850

Oberklassen notiert werden. Dies erhöht die Komplexität des Serialisierers deutlich. Daher ist es empfehlenswert, auf diamantförmige Vererbungsstrukturen zu verzichten, bei denen die mehrfach geerbten Oberklassen Attribute enthalten. ❑ Fehlerbehandlung vorsehen. Falls ein nicht behebbarer Fehler

auftritt, soll das System den Schreibprozeß abbrechen und alle bereits geschriebenen Attribute zurücksetzen (Rollback). Um dies zu gewährleisten, müssen wir das Schreiben eines Objektgeflechts als eine Transaktion konzipieren, d.h. einen eigenen Ausführungskontext zur Verfügung stellen und Änderungen erst nach einem Commit allgemein sichtbar machen. Da ein generischer Transaktionsmanager kompliziert zu entwickeln ist, bringt ein vorhandener Transaktionsmanager des externen Mediums hier deutliche Vorteile. ❑ Klassenvariablen gesondert behandeln. Klassenvariablen soll-

ten nur bei Programmstart gelesen und bei Programmende geschrieben werden. Statt sie innerhalb der leseVon- und schreibeAuf-Operationen zu behandeln, sollte für sie ein eigenes Initialisierungs- und Finalisierungskonzept eingeführt werden.

3


3.3


851

Folgende Punkte müssen nur beachtet werden, wenn die Objektgeflechte nicht vollständig serialisiert werden: ❑ Serialisierungsstrategie wählen. Objekte können beliebig tief

miteinander verflochten sein. Eine Serialisierungsstrategie legt fest, bis zu welchem Grad Objektreferenzen beim Lesen oder Schreiben des referenzierten Objekts aufgelöst werden. Dabei können für das Lesen und Schreiben unterschiedliche Strategien gewählt werden. Es gibt z.B. folgende Strategien (vgl. [Bischofberger et al. 96]): – Flache Serialisierung: Nur das gerade bearbeitete Objekt wird serialisiert. Objektreferenzen werden nicht aufgelöst, d.h., es werden nur die Referenzen selbst gelesen oder geschrieben, nicht jedoch die referenzierten Objekte. Diese Lösung eignet sich für Fälle, in denen der Datentransfer sehr aufwendig ist, und daher möglichst wenige Objekte serialisiert werden sollen. – Serialisierung bis zu einer bestimmten Tiefe. Vom bearbeiteten Objekt ausgehend, werden alle Objekte bis zu einer vorher festgelegten Tiefe der Referenzen serialisiert. Das ist eine allgemeine Lösung, die sich anbietet, wenn vollständige Serialisierung zu aufwendig ist, aber keine Information über die Objektstruktur vorliegt, die eine auf die Struktur zugeschnittene Strategie ermöglichen würde.

3


3.3


852

– Spezifizierte Serialisierung: In diesem Fall wird anhand einer vorher festgelegten Spezifikation entschieden, welche Objektreferenzen aufgelöst werden und welche nicht. Die Unterscheidung kann z.B. anhand des Objekttyps erfolgen, so daß Referenzen innerhalb von Proxy-Typen nicht aufgelöst werden. Spezifizierte Serialisierung ist die beste Lösung, da der Entwickler das Serialisierungsverhalten auf anwendungsspezifische Anforderungen abstimmen kann. In [Lopes 96] ist ein solches Vorgehen ausführlich beschrieben. – Adaptive Serialisierung: Adaptive Serialisierung ist ein Spezialfall der spezifizierten Serialisierung für das Lesen. Statt die Spezifikation statisch aus den anwendungsspezifischen Anforderungen abzuleiten, wird sie dynamisch anhand der tatsächlichen Anforderungen der Anwendung zur Laufzeit bestimmt. Zunächst wird nur flach serialisiert. Je nachdem wie serialisiert wird und wie Referenzen aufgelöst werden, sammelt ein Serialisierungsdienst Daten darüber, welche Objekte immer zusammen benötigt werden und erzeugt daraus eine dynamische Serialisierungsspezifikation.

3


3.3


853

❑ Hängende Referenzen behandeln. Beim partiellen Lesen eines

Objektgeflechtes werden nicht alle Referenzen aufgelöst. Vor dem ersten Zugriff müssen diese Referenzen durch Lesen weiterer Objekte aufgelöst werden. Dazu gibt es im wesentlichen zwei Mechanismen: – Proxies verwenden: Eine hängende Referenz kann mit Hilfe des Proxy-Musters (s. [Gamma et al. 96]) realisiert werden. Als eine Variante wird das referenzierte Objekt erzeugt, aber in einen speziellen (uninitialisierten) Proxy-Zustand versetzt. Dann benötigen wir keine eigene Proxy-Klasse. Wir können auch einen speziellen Referenztyp einführen. In beiden Fällen muß das Proxy-Objekt in der Lage sein, Operationsaufrufe abzufangen und erst auszuführen, sobald das gerufene Objekt vollständig verfügbar ist. – Laufzeit-Mechanismus zur Auflösung von Referenzen modifizieren: Falls es die Programmiersprache gestattet, können wir das Laufzeitsystem so ändern, daß es Referenzen auf eine besondere Art behandelt. Wir können z.B. jede Referenz mit einem Flag versehen, das angibt, ob der Referenzwert auf ein gültiges Objekt im Hauptspeicher verweist oder nicht. Falls nicht, wird der Wert als Objekt-ID interpretiert, mit dessen Hilfe das Objekt gelesen wird. Eine

3


3.3


854

solche Modifikation des Laufzeitsystems ist grundsätzlich systemabhängig. Daher sollte sie nur dann durchgeführt werden, wenn sich Proxies aufgrund besonderer Performanz-Anforderungen als ungeeignet herausstellen. Wir greifen hier das Kunden-Konten-Beispiel aus dem Abschnitt Kontext dieses Musters wieder auf. Die Klasse Serialisierbar bietet je eine Operation zum Lesen und zum Schreiben an. Außerdem stellt sie eine Erzeuge-Operation zur Verfügung. Die Klassendeklaration sieht folgendermaßen aus:

Beispielcode

class Serialisierbar { public: virtual void leseVon( Leser* ) = 0; virtual void schreibeAuf( Schreiber* ) = 0; static Serialisierbar* erzeugeAusTypId( const string& ); };

Alle Klassen, die serialisiert werden sollen, müssen von Serialisierbar erben. Dies gilt auch für unsere Beispielklassen Kunde, Konto und Liste:

3


3.3


855

class Kunde : public Serialisierbar { public: virtual void leseVon( Leser* ); virtual void schreibeAuf( Schreiber* ); private: string Name; Liste* Konten; }; class Konto : public Serialisierbar { ... // analog zum Kunden }; template < class T > class Liste : public Serialisierbar { public: virtual void leseVon( Leser* ); virtual void schreibeAuf( Schreiber* ); private: // ZustandsreprŠsentation long AnzahlElemente; T* Elemente //C++-Array };

Objekte dieser Klassen besitzen eine Zustandsrepräsentation, die gelesen und geschrieben werden muß. Dazu muß jede Klasse die beiden Operationen leseVon und schreibeAuf implementieren. Zur Imple-

3


3.3


856

mentierung werden die Operationen des Lesers und Schreibers verwendet. Die Schnittstelle des Schreibers sieht folgendermaßen aus: class Schreiber { public: // Operationen zum Schreiben // der "eingebauten" Datentypen virtual void schreibeChar ( const string& AttributName, char Wert ) = 0; virtual void schreibeInt ( const string& AttributName, int Wert ) = 0; ... // Operationen zum Schreiben weiterer Wertetypen virtual void schreibeString ( const string& AttributName, const string& Wert ) = 0; ... // Operationen zum Schreiben von // Objekten/Objektreferenzen virtual void schreibeObjekt ( const string& AttributName, const Serialisierbar* ) = 0; virtual void schreibeStartObjekt ( const Serialisierbar* ) = 0; ... };

3


3.3


857

Diese Schnittstelle enthält Operationen zum Schreiben aller wichtigen Wertetypen, insbesondere der bereits von der Programmiersprache definierten Typen, und zum Schreiben von Objektreferenzen. Auf dieser Basis lassen sich nun die schreibeAuf-Operationen des Kunden und der Liste implementieren: void Kunde::schreibeAuf( Schreiber* AktuellerSchreiber ) { AktuellerSchreiber->schreibeString( "Name", Name ); AktuellerSchreiber->schreibeObjekt( "Konten", Konten ); } template < class T > void Liste::schreibeAuf ( Schreiber* AktuellerSchreiber ) { AktuellerSchreiber->schreibeLong ("AnzahlElemente", AnzahlElemente ); for ( long i=0; i < AnzahlElemente; i++ ) { AktuellerSchreiber->SchreibeObjekt ( "Elemente[" + string(i) + "]", Elemente[i] ); } }

3


3.3


858

Das Schreiben der Wertetypen bereitet üblicherweise keine besonderen Probleme. Der Schreiber muß dazu nur die Daten in das Format umwandeln, das vom externen Medium erwartet wird. Interessant ist dagegen die Behandlung von Referenzen. Das Schreiben der Referenz selbst ist einfach – es muß nur der Objekttyp und die Objekt-ID geschrieben werden. Aber da die Referenz auf ein Objekt verweist, muß der Schreiber entscheiden, ob er das referenzierte Objekt ebenfalls schreibt, und außerdem muß er darauf achten, welche Objekte er bereits geschrieben hat. Das läßt sich am besten an einem konkreten Beispiel zeigen: Ein ASCIIStreamSchreiber benutzt einen C++-Stream als externes Medium. Er konvertiert die Objekte in ein ASCII-Format, das sowohl vom System als auch vom Entwickler gelesen werden kann, z.B. beim Debugging. Die Schnittstelle des ASCIIStreamSchreiber sieht fast wie die allgemeine Schreiber-Schnittstelle aus. Es kommen nur noch Operationen für das Setzen des C++-Streams hinzu. Der Einfachheit halber wählen wir die vollständige Serialisierung als Schreibstrategie.

3


3.3


859

ASCIIStreamSchreiber verwendet ein Attribut Buffer als Referenz auf den ostream, auf den die Daten geschrieben werden. Das Schreiben eines einfachen Wertetyps wie long ist nicht schwierig: void ASCIIStreamSchreiber::schreibeLong ( const string& AttributName, long Wert ) { Buffer leseObjekt ( "Liste[" + string(i) + "]" ) ); } }

3


3.3


863

Die Leser-Schnittstelle ist analog zur Schreiber-Schnittstelle aufgebaut: class Leser { public: // Operationen zum Lesen // der "eingebauten" Datentypen virtual char leseChar ( const string& AttributName ) = 0; virtual int leseInt ( const string& AttributName ) = 0; ... // Operationen zum Lesen weiterer Wertetypen virtual string leseString ( const string& AttributName ) = 0; ... // Operationen zum Lesen von // Objekten/Objektreferenzen virtual Serialisierbar* leseObjekt ( const string& AttributName ) = 0; virtual Serialisierbar* leseStartObjekt() = 0; };

Während der ASCIIStreamSchreiber die Attribute in der Reihenfolge schreiben kann, in der er sie geliefert bekommt, sollte der ASCIIStreamLeser es auch verkraften, wenn das Objekt seine Attribute in einer anderen Reihenfolge anfordert als in der, in der sie geschrieben wurden.

3


3.3


864

Daher werden alle Attribute eines Objekts auf einmal gelesen und mit dem Attributnamen als Schlüssel in der Zuordnungstabelle Attribute abgelegt. Dazu besitzt der ASCIIStreamLeser die Hilfsoperation leseAttribute.

void ASCIIStreamLeser::leseAttribute() { Attribute->leeren(); while( Buffer->peek() != '}' ) { string Typ, AttributName, Wert; string Dummy; //Dummy fŸr " = " Buffer >> Typ >> AttributName >> Equal >> Wert; Attribute->einfuegen ( AttributName, TypWertPaar( Typ, Wert ) ); } }

Mit Hilfe dieser Zuordnungstabelle lassen sich die Operationen zum Lesen einfacher Wertetypen leicht implementieren. leseChar z.B. sieht folgendermaßen aus:

3


3.3


865

char ASCIIStreamLeser::leseChar ( const string& AtributName ) { return Attribute[AttributName]-> GibWert()->AlsChar(); }

leseObjekt prüft zunächst, ob das Objekt mit der gelesenen ID bereits existiert; dazu verwaltet es die Zuordnungstabelle ErzeugteObjekte, die eine Zuordnung der IDs aller bereits erzeugten Objekte zu den Objekten selbst führt. Falls das Objekt noch nicht existiert, wird es erzeugt, damit es mit einer gültige Objektreferenz in die Zuordnungstabelle eingetragen und zurückgegeben werden kann.

3


3.3


866

Serialisierbar* ASCIIStreamLeser::leseObjekt ( const string& AtributName ) { Serialisierbar* Objekt = nil; long Id = Attribute[AttributName]-> GibWert()->AlsLong(); if ( ErzeugteObjekte->enthaelt( Id ) ) { Objekt = ErzeugteObjekte[Id]; } else { string Typ = Attribute[Name]->GibTyp(); Objekt = Serialisierbar::ErzeugeAusTypId( Typ ); ErzeugteObjekte->einfŸgen( Id, Objekt ); } return Objekt; }

Der Leseprozeß wird vom Klienten durch Aufruf von leseStartObjekt gestartet und liefert eine Referenz auf das Startobjekt zurück. Analog zu schreibeStartObjekt hat auch leseStartObjekt eine Schleife, die so lange durchlaufen wird, bis der gesamte Stream gelesen ist.

3


3.3


867

Serialisierbar* ASCIIStreamLeser::leseStartObjekt() { Serialisierbar* StartObjekt = nil; ErzeugteObjekte->leeren; while ( ! Buffer.eof() ) { Serialisierbar* Objekt = nil; string Typ, Dummy; //Dummy fŸr " = " usw. long Id; // lies Typ und Objekt-ID Buffer >> Typ >> Id >> Dummy >> Dummy; if ( ErzeugteObjekte->enthaelt( Id ) ) { Objekt = ErzeugteObjekte[Id]; } else { Objekt = Serialisierbar::ErzeugeAusTypId ( Typ ); ErzeugteObjekte->einfŸgen( Id, Objekt ); if ( StartObjekt == nil ) StartObjekt = Objekt; } leseAttribute(); Objekt->leseVon( this ); Buffer >> Dummy; // "}" und } return StartObjekt;

}

3


3.3


868

Nun sind alle Bestandteile des Leseprozesses zusammen: Eine Schleife wird so lange durchlaufen, bis der Stream gelesen ist. Dann ist das vollständige Objektgeflecht erzeugt (vorausgesetzt, der Stream wurde mit dem ASCIIStreamSchreiber geschrieben). In jedem Durchlauf wird genau ein Objekt gelesen; falls es noch nicht existiert, wird es zuvor erzeugt. Zunächst liest der Leser alle Attribute ein und übergibt dann die Kontrolle an das zu lesende Objekt. Das Objekt fordert seine Attribute vom Leser an, der die entsprechenden Werte aus der Zuordnungstabelle Attribute zurückgibt. Falls es sich um eine Objektreferenz handelt, gibt der Leser die Hauptspeicherreferenz auf das passende Objekt zurück. Dazu wird es ggf. vorher erzeugt. Mit seinem Zustand gefüllt wird es erst, wenn es im Stream auftaucht.

3


4

Konstruktionsprobleme und -lösungen

4


4.1

Unterstützung kooperativer Arbeit

In diesem Buch und in den meisten unserer Kooperationsprojekte haben wir zunächst Anwendungssysteme für den einzelnen Arbeitsplatz betrachtet. Allerdings haben wir mehrfach bemerkt, daß praktisch jede Form qualifizierter Arbeit kooperative Anteile enthält. Immer wieder müssen sich Anwendungsexperten nach abgestimmten Regeln miteinander verständigen und Arbeitsmaterialien austauschen. Kooperation ist vielfach eine schlichte Notwendigkeit, um eine Arbeit zu erledigen, die individuell nicht durchzuführen ist. Die Art und Weise, wie kooperiert wird, kann, je nach Anliegen, unterschiedlich ausfallen. Wir sprechen davon, daß es jeweils unterschiedliche Kooperationsmodelle geben kann.

4

869

Federführung: Guido Gryczan Ko-Autoren: Anita Krabbel, Stefan Roock, Ingrid Wetzel, Henning Wolf, Heinz Züllighoven


4.1


870

Kooperationsmodell: Ein Kooperationsmodell ist ein Modell, das entweder explizit oder implizit die Zusammenarbeit (Kooperation) beschreibt und regelt. Wir betrachten hier Kooperationsmodelle, die Bestandteil eines Arbeitsplatzsystems sind.

Bevor wir die einzelnen Kooperationsmodelle untersuchen, soll festgehalten werden, daß individuelle und kooperative Arbeit Formen der Arbeit sind, die von uns nicht in den Kategorien »besser« und »schlechter« oder »angestrebt« und »nicht angestrebt« eingeteilt werden. Beide Formen der Arbeit sind notwendig und sinnvoll. Hier geht es nur um die Frage, in welchem Umfang kooperative Arbeit von einem Anwendungssystem unterstützt werden kann und soll. Während wir ohne Computerunterstützung sehr informell und selbstverständlich miteinander arbeiten und uns dabei koordinieren können, muß dies in der Anwendungssoftware explizit vorgesehen werden. Wir zeigen, daß dies nicht nur ein technisches Problem, sondern vorrangig ein anwendungsfachliches Problem ist. Ziel der folgenden Abschnitte ist es deshalb, das Modellrepertoire von WAM so zu erweitern, daß auch die Unterstützung kooperativer Arbeit möglich wird.

4

Individuelle und kooperative Arbeit


4.1


871

Wir fassen den Begriff der kooperativen Arbeit bewußt sehr weit und schränken ihn weder auf die durch Anwendungssoftware unterstützten Anteile ein noch haben wir bestimmte Organisationsformen im Auge. Kooperative Arbeit: Bei kooperativer Arbeit arbeiten verschiedene Personen geplant und koordiniert zusammen, um ein gemeinsames Ergebnis zu erreichen.

Wichtig ist für uns an dieser Stelle:

Merkmale von Kooperation

❑ Die Beteiligten wollen ein gemeinsames Produkt herstellen

oder eine gemeinsame Dienstleistung erbringen. ❑ Sie müssen sich begrenzte Ressourcen teilen. Im einfachsten

Fall müssen sie den Arbeitsgegenstand austauschen. ❑ Sie müssen ihre Arbeitshandlungen soweit notwendig aufein-

ander abstimmen, damit zeitliche oder sachlogische Reihenfolgen eingehalten werden. ❑ Sie müssen sich in irgendeiner Weise darüber verständigen, was

von wem wie getan wird.

4


4.1


872

Damit ist kooperative Arbeit immer mit Abstimmung und Koordination verbunden. In vielen Fällen gibt es neben festen Regeln für die Kooperation eine unter den Beteiligten geteilte Konvention darüber, wie die Kooperation abläuft und koordiniert wird. Koordination: Koordination ist der Prozeß oder der Mechanismus zur Abstimmung von Arbeitsteilung bei kooperativer Arbeit. Koordination kann auf wechselseitigen Konventionen oder ausdrücklichen Regeln beruhen.

Wenn wir zur Unterstützung kooperativer Arbeit Anwendungssoftware einsetzen wollen, dann sollten wir nicht vergessen, daß neben der eigentlichen Kooperation auch noch die dazu notwendige Koordination berücksichtigt werden muß. Im einfachsten Fall, und der war bisher meist die Regel, wird Kooperation und Koordination gar nicht oder nur extrem reduziert in der Anwendungssoftware modelliert. Die kooperierenden Personen arbeiten dabei ohne Unterstützung durch das System zusammen. Diesen Fall betrachten wir weiter unten in einem Beispiel.

4

Kooperation und Koordination


4.1


Wir diskutieren im folgenden verschiedene fachlich motivierte Kooperationsmodelle:

873 Implizite und explizite Kooperation

❑ Implizite Kooperation: Der konkurrierende Zugriff auf Mate-

rialien von verschiedenen Arbeitsplätzen aus wird deutlich. ❑ Explizite Kooperation: Gemeinsam benutzbare Posträume

oder Archive werden genutzt, Vorgänge werden unterstützt, Formen komplexer Kooperation (s. Kapitel 4.1.4) sind relevant. Jede Kooperation wird erst durch gegenständliche Kooperationsmittel oder -medien möglich. Kooperationsmittel: Ein Kooperationsmittel ist ein fachlich motivierter Gegenstand, der die Kooperation unterstützt. Er vergegenständlicht die Kooperation oder die dabei notwendige Koordination. Beispiele für Kooperationsmittel sind Vorgangsmappen und Laufzettel. Eine Vorgangsmappe ermöglicht, Unterlagen in einem arbeitsteiligen Prozeß weiterzugeben. Laufzettel vergegenständlichen die Reihenfolge von kooperativen Arbeitsschritten und die jeweils Verantwortlichen.

4


4.1


874

Begriff Kooperationsmedium: Ein Kooperationsmedium ist ein fachlich motivierter Gegenstand, der zur Realisierung von Kooperation in Anwendungssystemen dient. Gemeinsam ist allen Kooperationsmedien, daß mit ihrer Hilfe Materialien oder Information ausgetauscht werden können und daß sie selbst vergegenständlicht sind. Beispiele für Kooperationsmedien sind ein elektronisches Postversandsystem, Gruppenpostfächer oder ein elektronisches Notizbrett.

Das Pausenplansystem ist als reines Einzelarbeitsplatzsystem ausgelegt. Pausenplanersteller und Schulsekretariat kooperieren, indem sie ausgedruckte und mit der Hand korrigierte Pausenpläne weitergeben. Damit gibt es keine Möglichkeit zur computergestützten Kooperation. In einer nächsten Stufe läuft das gleiche Pausenplansystem auf zwei Arbeitsplatzrechnern; jeweils für den Pausenplanersteller und das Schulsekretariat. Über ein lokales Netz können beide Arbeitsplatzrechner auf ein gemeinsames Dateisystem zugreifen. Damit können Pausenplanersteller und Schulsekretariat Pausenpläne in Dateien ablegen, die vom anderen Arbeitsplatz aus zugreifbar sind. Hier ist die Kooperation über einen gemeinsamen Dateizugriff möglich (s. Abbil-

4


4.1


875

dung 4-1). Weiter wird Kooperation im System nicht unterstützt. Insbesondere müssen die Beteiligten darauf achten, daß sie sich koordinieren und nicht etwa gleichzeitig und »unkoordiniert« an einem neuen Pausenplan arbeiten. Abb. 4-1 Kooperation zwischen zwei Arbeitsplätzen über gemeinsamen Dateizugriff

4


4.1


876

4.1.1 Implizite Kooperation Von impliziter Kooperation sprechen wir immer dann, wenn ein Benutzer in einer kooperativen Arbeitssituation mit anderen eine Arbeitsumgebung teilt, ohne daß die Kooperation zunächst deutlich wird. Dabei gehen wir meist von gemeinsamen Arbeitsmateralien aus. Implizite Kooperation: Bei der impliziten Kooperation wird der konkurrierende Zugriff mehrerer Benutzer auf gemeinsame Ressourcen im Benutzungsmodell ermöglicht und verdeutlicht. Kooperation oder Koordination selbst sind aber nicht vergegenständlicht.

Auffällig wird diese Form der Kooperation dann, wenn auf Materialien konkurrierend von verschiedenen Arbeitsplätzen aus zugegriffen wird. Für diese Kooperationsform gelten folgende Merkmale:

Merkmale impliziter Kooperation

❑ Um eine kooperative Aufgabe zu erledigen, muß arbeitsteilig

auf ein gemeinsames Arbeitsmaterial zugegriffen werden. ❑ Es gibt mehrere Arbeitsplätze innerhalb einer gemeinsamen

Arbeitsumgebung.

4


4.1


877

❑ Am einzelnen Arbeitsplatz sind die anderen Arbeitsplätze nicht

sichtbar. ❑ Die Beteiligten koordinieren sich durch Konventionen außer-

halb des Anwendungssystems. Das zentrale Problem bei der impliziten Kooperation ist demnach die Transparenz bei der Verwendung gemeinsamer Materialien. Transparenz bedeutet hier, daß der Benutzer die Konkurrenzsituation mit Hilfe des Anwendungssystems erkennen kann:

Tranzparenz bei impliziter Kooperation

❑ Das System muß verdeutlichen, daß mehr als ein Benutzer am

gleichen Material arbeitet. ❑ Die Einheit von Ort und Zeit bei der Materialbearbeitung

bleibt gewahrt. ❑ Die Koordination erfolgt im wesentlichen durch Konventionen

außerhalb des Systems. Zur Lösung dieses Problems müssen geeignete Kooperationsmittel und -medien bereitgestellt werden. Anwendungsfachlich bietet sich hier das Konzept des Archivs (s. S. 434ff.) an.

4


4.1


878

Einheit von Ort und Zeit bei der Materialbearbeitung: Ein Material kann zu einem Zeitpunkt nur an genau einem Ort sein und dort bearbeitet werden. Hat ein Benutzer ein Material auf seinem persönlichen Arbeitsplatz, so kann es nicht von anderen bearbeitet werden. In der Regel ist es dann für andere auch nicht sichtbar.

In der Praxis gibt es verschiedene Arten des konkurrierenden Zugriffs auf Materialien und des dazu passenden Verwaltungsmechanismus:

Arten des konkurrierenden Zugriffs auf Material

❑ Exklusiver Zugriff auf das Material; es gibt keine Kopien. Das

entnommene Material ist für andere Benutzer gesperrt. Grund für die Modellierung: Ein Material soll nur einmal vorhanden sein, d.h., es ist fachlich nicht sinnvoll, vom Material eine Kopie anzufertigen. Konsequenz: Die Benutzer müssen darüber informiert werden, wo sich das Material momentan befindet, da es sonst zu Unterbrechungen und Störungen im Arbeitsprozeß kommen kann. ❑ Exklusiver Zugriff auf ein Original; Kopien sind möglich.

Nur ein Benutzer kann das Original des Materials auf seinen

4


4.1


879

Arbeitsplatz nehmen. Weitere Benutzer erkennen, daß das Original ausgeliehen ist, können sich aber Arbeitskopien ziehen. Grund für die Modellierung: Auch wenn das Original eines Materials nicht mehr verfügbar ist, sollen Kopien vorhanden sein, die als Arbeitskopien für weitere Benutzer bereitstehen. Konsequenz: Die Koordination von Änderungen, die am Original und den Arbeitskopien vorgenommen wurden, liegt bei den Benutzern. Änderungen am Original ziehen keine automatischen Änderungen an den Kopien nach sich. Es kann sinnvoll sein, Benutzer von Kopien über die Rückgabe des Originals zu informieren. ❑ Zugriff immer nur auf Kopien möglich. Jeder Benutzer erhält

nur eine Arbeitskopie, die mit einem internen Zeitstempel versehen wird. Das Original kann aufgrund einer expliziten Änderungsoperation durch eine Arbeitskopie ersetzt werden. Dabei erhält es einen aktuellen Zeitstempel. Wenn das Original durch eine Arbeitskopie mit einem älteren Zeitstempel ersetzt werden soll, wird der Benutzer über den Konflikt und seine Ursache informiert. Grund für die Modellierung: Wenn häufig lesend auf ein Material zugegriffen wird und Änderungen eher die Ausnahme sind,

4


4.1


880

dann werden zunächst beliebige Arbeitskopien ausgegeben. Dabei ist es für den lesenden Zugriff uninteressant, daß viele Benutzer konkurrierend zugreifen. Oft kommt hinzu, daß das Original aus fachlichen Gründen nicht dauerhaft für einen Benutzer exklusiv verfügbar gemacht werden kann (z.B. ein Konto). Konsequenz: Erst wenn durch nebenläufige unkoordinierte Bearbeitung eines Materials ein Konflikt entsteht, wird der Benutzer über diesen Konflikt informiert und kann sich anhand der mitgelieferten Informationen mit anderen Benutzern über die Regelung des Konflikts verständigen. Damit wird auch klar, daß das Konzept von Original und Kopie primär anwendungsfachlich motiviert ist und von der technischen Realisierung getrennt werden muß. Die Art und Weise, wie Originale und Kopien bei konkurrierendem Zugriff verwaltet werden und wie im Konfliktfall die Koordination erfolgen muß, kann nur anwendungsfachlich und nicht durch ein allgemeines technisches Verfahren geregelt werden.

4


4.1


881

Original und Kopie: Materialien, besonders Schriftstücke oder Dokumente, werden häufig in Arbeitsumgebungen als Originale und Kopien zur Verfügung gestellt. Dabei soll die alltagssprachliche Bedeutung der Begriffe aufrecht erhalten werden. In diesem Sinne sind Kopien, zur besseren Unterscheidung auch Arbeitskopien genannt, Materialien aus eigenem Recht, die wie Fotokopien weiter bearbeitet werden können. Zwischen Kopie und Original besteht keine technische Verbindung, so daß Änderungen an dem einen keine Auswirkungen auf das andere haben. Von Arbeitskopien sind technische Kopien zu unterscheiden. Diese können bei der Realisierung des Systems aus softwaretechnischen Gründen auch von fachlichen Originalen erzeugt werden, etwa um Zugriffszeiten zu minimieren.

Technische und fachliche Transparenz bei der Kooperation

Interessanterweise wird unter dem Begriff Transparenz Gegensätzliches verstanden, je nachdem ob dieser Begriff im technischen oder im anwendungsfachlichen Kontext verwendet wird. Technisch wird bei verteilten Systemen von Transparenz in dem Sinne gesprochen, daß die Verteilung von Komponenten aus Sicht der Anwendung und auch der

4


4.1


882

Anwendungsentwicklung möglichst unsichtbar sein soll. Verteilung soll wie eine völlig transparente Scheibe gar nicht festzustellen sein. Dahinter steht das Ideal unendlich schneller, unendlich großer und vollständig ortsunabhängiger Systeme. Im Rahmen des WAM-Ansatzes sprechen wir von Transparenz im anwendungsfachlichen Sinne. Dies bedeutet, daß Verteilung bei der Kooperation sichtbar also durchschaubar sein soll. Wir wollen dem Anwender (und auch dem Anwendungsentwickler) ein nachvollziehbares Bild von begrenzten Ressourcen und ihrer räumlichen Verteilung geben, um den Aufwand und die Folgen eines Zugriffs auf nicht-lokale Komponenten zu verdeutlichen. Die folgende Übersicht zeigt unsere Interpretation des fachlichen Transparenzbegriffs:

4


4.1


Art der Transparenz

Umsetzung mit der Entwurfsmetapher Arbeitsplatz

Lokalität

Benutzer sind über den Ort eines Materials informiert. Ein Material befindet sich immer an einem bestimmten Ort. Dieser Ort ist der Arbeitsplatz oder einer der Orte einer gemeinsamen Arbeitsumgebung, von denen ein Material beschafft werden kann.

Zugriff

Die Orte, an denen auf Materialien direkt oder durch explizite Anforderung zugegriffen werden kann, sind am Arbeitsplatz bekannt.

Migration

Die Bewegung eines Materials an einen anderen Ort innerhalb einer Arbeitsumgebung erfolgt nur durch eine (initiale) Aktivität eines Benutzers.

Simultaner Zugriff

Simultaner schreibender Zugriff von verschiedenen Arbeitsplätzen auf ein Material ist nicht möglich. Er wird durch das Konzept von Kopie und Original ersetzt.

Kopienverwaltung

Der Umgang mit geänderten Arbeitskopien und dem Original liegt in der Verantwortung der Benutzer.

Ausfall

Der systembedingte Ausfall von Orten, an denen Material in einer Umgebung bereitgestellt ist, wird anwendungsfachlich nicht verborgen.

4

883


4.1


884

Bei der impliziten Kooperation beschränkt sich das anwendungsfachliche Kooperationsmodell im wesentlichen auf die Bereitstellung eines Kooperationsmittels. Die dabei notwendigen Koordinationsprozesse werden außerhalb der technischen Umgebung realisiert. Das gemeinsame Archiv: ein Kooperationsmittel zur Verwaltung von Materialien

Der Zweck eines Archivs ist, Materialien bereitzustellen und konsistent zu verwalten. Ein Archiv führt eine Bestandsliste, aus der die verwalteten Materialien ersichtlich sind. Jeder Zugriff auf das Archiv wird in der Bestandsliste durch Vermerke über die entnommenen Materialien dokumentiert. Wir betrachten im folgenden sogenannte gemeinsame Archive, d.h. Archive, die von mehr als einem Arbeitsplatz aus zugänglich sind (s. Abbildung 4-2). Die gerade aufgeführten grundlegenden Eigenschaften bleiben erhalten. Hinzu kommt, daß über die Vermerke in der Bestandsliste ein Rückschluß auf den Entleiher möglich ist, da dies die Voraussetzung für eine einfache Koordination (außerhalb des Systems) ist. In diesem Sinne charakterisieren wir ein gemeinsames Archiv als Kooperationsmittel. Offensichtlich ermöglicht ein solches Archiv auch den Materialaustausch zwischen Arbeitsplätzen und hat

4

Gemeinsame Archive


4.1


damit auch den Charakter eines Kooperationsmediums. Da die Kooperation aber nicht explizit vergegenständlicht wird, diskutieren wir diesen Aspekt nicht weiter. Die Bestandsliste enthält die Namen aller Materialien, die im Archiv verwaltet werden. Über den Namen wird ein Material identifiziert und aus dem Archiv angefordert. Aus der Liste ist weiterhin ersichtlich, ob sich das Material gerade im Archiv befindet oder ob es ausgeliehen ist. Meist ist der Name oder die Rollenbezeichnung des Benutzers vermerkt, der ein Material ausgeliehen hat. Ziel dieser Modellierung ist, für die Benutzer ein fachlich nachvollziehbares Modell der Arbeit mit einem gemeinsamen Archiv herzustellen. Obwohl technisch durchaus die Möglichkeit besteht, gleichzeitig mehrere Benutzer auf einem Material arbeiten zu lassen, halten wir an der täglichen Arbeitserfahrung der Einheit von Zeit und Ort fest. Dies schließt die gleichzeitige Bearbeitung eines Materials durch mehrere Benutzer des Archivs aus.

4

885

Bestandslisten

Benutzungsmodell


4.1


886 Abb. 4-2 Kooperation zwischen zwei Arbeitsplätzen über ein gemeinsames Archiv

Um dennoch Flexibilität zu erreichen und den Fortgang der Arbeit nicht unnötig zu behindern, verwenden wir das Konzept von Original und Kopie. Wird Material angefordert, muß das Archiv entscheiden, ob die Entnahme des Originals oder einer Arbeitskopie möglich ist.

4

Original und Kopie


4.1


Soll die Koordination zwischen den Benutzern von Original und Kopien noch weiter vom System unterstützt werden, kann ein Archiv einen Signalmechanismus als zusätzliche Dienstleistung anbieten. Dabei wird der Benutzer einer Kopie vom Archiv benachrichtigt, wenn sich das zu der Kopie gehörende Original verändert hat. Dies kann über eine Nachricht im Posteingang oder durch ein entsprechendes grafisches Symbol am Arbeitsplatz geschehen. Dadurch hat der Benutzer die Möglichkeit, sich aus dem Archiv eine aktuelle Arbeitskopie oder eventuell das Original zu beschaffen. Mit der Einführung von Archiven stellt sich auch die Frage der Persistenz von Materialien. Jeder Benutzer wird erwarten, daß alle Materialien in einem Archiv ohne weitere explizite Handlungen dauerhaft gespeichert sind. Daher ist ein Archiv auch eine gute Vergegenständlichung des Persistenzkonzepts. Dahinter lassen sich etwa über Automaten die verschiedenen Persistenzräume, z.B. eine Datenbank, anschließen (vgl. auch Kapitel 4.2.2). Daraus ergeben sich weitere anwendungsfachliche Möglichkeiten. So kann der Benutzer etwa beim Archiv nach Materialien suchen oder sich über ältere Versionen eines Dokuments informieren. Die Schulsekretärin will mit Hilfe des Lehrerkarten-Editors auf einer Lehrerkarte vermerken, daß eine Lehrperson an einem bestimmten Tag nicht mehr aufsichtsbereit ist. Dazu entnimmt sie zunächst den

4

887 Signalmechanismus

Persistenz

Beispiel Aufsichtsbereitschaft aktualisieren


4.1


888

Ordner mit allen Lehrerkarten aus dem Archiv. Sie ändert dann die aus dem Ordner entnommene Lehrerkarte. Während der Ordner aus dem Archiv entnommen ist, enthält die Bestandsliste des Archivs einen Entnahmevermerk, aus dem deutlich wird, daß das Schulsekretariat den Ordner zu einem bestimmten Zeitpunkt entnommen hat. Der Pausenplanersteller kann während dieser Zeit nicht auf den Ordner zugreifen. Er sieht aber, daß er vom Schulsekretariat entliehen ist. Diese Konkurrenzsituation ist charakteristisch für implizite Kooperation. Implizit ist die Kooperation deshalb, weil hier »der andere«, also die Schulsekretärin, aus Sicht des Pausenplanerstellers nicht explizit sichtbar ist, sondern nur als Konkurrentin bei der Verwendung eines Materials ihre »Spuren hinterläßt«. Damit kann Kooperation aber koordiniert werden. Der Pausenplanersteller wird gegebenenfalls die Schulsekretärin anrufen und sie fragen, wie lange sie noch am Ordner mit den Lehrerkarten arbeitet.

4.1.2 Explizite Kooperation durch Materialaustausch Eine einfache Form der expliziten Kooperation stellt der Austausch von Materialien dar. Aus dem Bürobereich ist uns diese Form von

4


4.1


889

Kooperation geläufig. Akten, Mappen oder Schriftstücke werden zwischen wenigen Beteiligten ausgetauscht, wobei jeder weiß, was seine Rolle bei der Erledigung dieses »Vorgangs« ist. Explizite Kooperation: Bei der expliziten Kooperation wird im Benutzungsmodell deutlich, daß mehrere Benutzer kooperativ in einer gemeinsamen Arbeitsumgebung arbeiten. Geeignete Kooperationsmittel und -medien stehen für die Weitergabe von Materialien und für die Koordination bereit.

Der grundsätzliche Unterschied zur impliziten Kooperation beim Austausch von Materialien besteht darin, daß hier neben den Kooperationsmitteln explizite Kooperationsmedien in den Arbeitsplatz integriert sind. Für die explizite Kooperation durch Austausch von Materialien gelten damit folgende Merkmale: ❑ Zur Erledigung einer kooperativen Aufgabe werden arbeitstei-

Merkmale für explizite Kooperation durch Materialaustausch

lig gemeinsame Arbeitsmaterialien explizit ausgetauscht und weitergegeben.

4


4.1


890

❑ Die verschiedenen Arbeitsplätze innerhalb einer gemeinsamen

Arbeitsumgebung sind durch Kooperationsmedien miteinander verbunden. ❑ Am einzelnen Arbeitsplatz ist sichtbar, welche anderen Arbeits-

plätze prinzipiell oder aktuell vorhanden sind. ❑ Die Beteiligten kennen aufgrund von Konventionen die Art

und Weise ihrer Zusammenarbeit und benötigen keine besonderen Mechanismen innerhalb des Anwendungssystems, um ihre Arbeit zu koordinieren. Hier wird das Repertoire der WAM-Metaphern entscheidend erweitert. Zu den Kooperationsmitteln kommen unterschiedliche Kooperationsmedien hinzu. Je nach Art der Kooperation und ihrer gewünschten Unterstützung wählen wir z.B.: ❑ gemeinsame Postfächer, ❑ Punkt zu Punkt Verbindungen wie bei einer Rohrpost oder ❑ ein Postversandsystem.

Diese lassen sich mit Kooperationsmitteln kombinieren, die die Koordination explizit unterstützen. In den folgenden Abschnitten werden wir dies ausführlicher diskutieren.

4


4.1


891

Kooperationsmedium: Postfächer

Eine einfache Form der expliziten Kooperation durch Austausch von Materialien wird im Bürobereich auch konventionell unterstützt: die Verwendung von Postfächern in einem Postraum. Die Übertragung des Konzepts von Postfächern auf Anwendungssysteme nach dem WAM-Ansatz ist auf den ersten Blick eine Erweiterung der Archiv-Idee. Bei genauerer Betrachtung zeigen sich aber einige Eigenschaften, die Postfächer zu einem guten Kooperationsmedium machen. Sehen wir uns das Konzept unter anwendungsfachlichen Gesichtspunkten an: Von jedem Arbeitsplatz aus ist der gemeinsame Postraum mit seinen Fächern sichtbar. Jeder Benutzer kann in der offenen Version dieses Konzeptes Material in jedes beliebige Postfach hineinlegen oder aus einem Fach herausnehmen. Für alle Benutzer ist sichtbar, ob etwas und was in den Fächern liegt (s. Abbildung 4-3). Herausnehmen bedeutet, ein Material aus einem Postfach heraus auf den eigenen Schreibtisch zu holen. Damit ist dieses Material dann für die anderen nicht mehr sichtbar und zugreifbar. In der Gruppe, die diese Postfächer benutzt, gibt es Konventionen, wer was in welche Postfächer legen oder aus ihnen herausholen darf.

4

Die anwendungsfachliche Sicht auf Postfächer


4.1


892 Abb. 4-3 Kooperation zwischen zwei Arbeitsplätzen über gemeinsame Postfächer

cf

gg

cl

ak

dm

ws

ts

hz

aw

tz

uk

iw

lb

hw

db

dr

Postfächer in einem gemeinsamen Postraum sind eine wesentliche Erweiterung des Raumkonzepts. Neben dem individuellen Arbeitsplatz gibt es einen Raum, der für die Gruppe »gleichzeitig« zugänglich ist (vgl. [Pankoke-Babatz & Syri 96]). Dieses offene Konzept von Postfächern hat folgende Vorteile:

4

Vorteile von Postfächern


4.1


893

❑ Der Austausch von Materialien geschieht nach einem ganz ein-

fachen Modell, das jedem sofort einsichtig ist. ❑ Für die Koordination der Zusammenarbeit bedarf es keiner

eigenen Mechanismen, da für jeden Benutzer ersichtlich ist, wann ein Material im eigenen Fach oder auf dem Arbeitsplatz liegt. ❑ Da jeder Benutzer die Übersicht über alle Postfächer und den

(technisch) freien Zugriff darauf hat, können Arbeitsüberlastung, mögliche freie Kapazitäten und Stellvertreterregelungen durch Konventionen außerhalb des Systems geregelt, aber innerhalb des Systems realisiert werden. Das Konzept von Postfächern läßt sich bereits mit einem einfachen gemeinsamen Dateisystem für die unterschiedlichen Arbeitsplätze realisieren. Dort können die gemeinsamen Materialien abgespeichert werden. Innerhalb eines Arbeitsplatzes muß dann nur ein Automat regelmäßig den »Eingang« oder »Ausgang« von Materialien überprüfen und an die Komponenten melden, die die Postfächer repräsentieren. Natürlich lassen sich auch technisch anspruchsvollere Konzepte für die Realisierung verwenden. Ein eigener Serviceprozeß, in dem die

4

Die technische Sicht auf Postfächer


4.1


894

gemeinsamen Materialien bereitgehalten und verwaltet werden, ist eine weitere Lösung. Die Materialien in diesem Serviceprozeß lassen sich mit Proxies in den einzelnen Arbeitsplatzprozessen verbinden, die dort in den Postfächern dargestellt werden. Erst wenn ein Benutzer ein Material aus einem Fach auf seinen Arbeitsplatz herübernimmt, wird der Proxy durch das »vollständige« Materialobjekt ersetzt. Der Serviceprozeß kann dann selbst wieder mit einem Persistenzmechanismus versehen werden. Das Pausenplanbeispiel läßt sich einfach erweitern: Jede Lehrperson und alle Verwaltungsangestellten haben ein eigenes Postfach. Lehrpersonen legen einen Notizzettel ins Fach des Schulsekretariats, wenn sich an ihrer Zeiteinteilung etwas geändert hat. Der Pausenplanersteller erhält vom Schulsekretariat eine Nachricht ins Fach, wenn sich diese Änderung auf den aktuellen Pausenplan auswirkt. Ist ein neuer Pausenplan erstellt, wird er jeder Lehrperson ins Postfach gelegt. Der Pausenplanersteller sieht am nächsten Tag nach, ob alle betroffenen Lehrpersonen ihren Pausenplan aus dem Fach geholt haben.

4


4.1


895

Kooperationsmedium: Rohrpost und Postkörbe

Bei Verwendung eines üblichen Rohrpostsystems werden zu versendende Dokumente in einen dafür geeigneten Behälter gesteckt und abgeschickt. Wir gehen hier von dem einfachen Modell einer Eins-zueins-Verbindung aus. Offensichtlich benutzt der Anwender ein explizites Kooperationsmedium, um den Austausch der Materialien zu bewerkstelligen. Die Einfachheit dieses Kooperationsmodells ist gleichzeitig seine Begrenzung. Dadurch, daß Versender und Empfänger fest miteinander verbunden sind, ist es auch nicht notwendig, eine Empfängeradresse zu vergeben. Dieses Kooperationsmedium dient auch zur Koordination der Zusammenarbeit. Das Modell ist sehr einfach: Jeder der Beteiligten weiß, was zu tun ist. Wer das Arbeitsmaterial erhält, weiß, wer es geschickt hat. Die Verantwortung und die Initiative für die weitere Bearbeitung ist damit an den aktuellen Empfänger übergegangen. Wollen wir dieses anwendungsfachlich einfache (aber bewährte) Modell der Kooperation auf Anwendungssoftware übertragen, können wir dies fachlich und technisch recht einfach tun. Sehen wir uns zunächst die anwendungsfachliche Sicht an. Den Versandvorgang reduzieren wir auf den simplen Kern. Statt spezieller Versandbehälter und Rohrsysteme führen wir benannte

4

Die anwendungsfachliche Sicht auf Postkörbe


4.1


896

Postkörbe ein. Ein Postkorb mit Eingangs- und Ausgangsfach sowie einer entsprechenden Beschriftung wird dem Arbeitsplatz zugeordnet. In den Postkorb können beliebige Dokumente, Schriftstücke oder andere Arbeitsmaterialien gelegt werden. Eine Adressierung des Empfängers ist nicht notwendig, da der Postkorb eine eindeutige Verbindung zwischen zwei Arbeitsplätzen darstellt (s. Abbildung 4-4). Ebensowenig sind eigene Versandbehälter notwendig, obwohl es aus fachlichen Gründen oft sinnvoll sein wird, zusammengehörige Materialien in eine Mappe oder einen anderen Behälter zu legen, ehe sie weitergegeben werden. Abb. 4-4 Kooperation zwischen zwei Arbeitsplätzen mit direkt wb out

gg in

wb in

gg out

verbundenen Postkörben

4


4.1


Ein für den Versand bestimmtes Material wird entweder automatisch oder »auf Knopfdruck« verschickt. Es ist dann aus dem Ausgangsfach verschwunden. Andererseits sieht der Anwender, daß neues Material im Eingangsfach des Postkorbs angekommen ist. Postkörbe bilden die explizite Verbindung von Arbeitsplätzen untereinander. Sie haben damit gegenüber den bisher besprochenen Materialien am Arbeitsplatz eine andere Bedeutung. Für diese Materialien wurde festgelegt, daß sie nicht außerhalb eines Arbeitsplatzes sichtbar sind, und daß sie demzufolge nur durch lokale Werkzeuge und Automaten bearbeitet werden können. Demgegenüber ist es fachlich gewollt, daß auf Postkörbe in einer festgelegten Weise von außerhalb eines Arbeitsplatzes zugegriffen wird. Denn nur so kann ja der Austausch von Materialien stattfinden. Postkörbe sind damit wie Postfächer eine Erweiterung des Arbeitsplatzes hin zur Arbeitsumgebung, um eine explizite Form der Kooperation – den direkten Materialaustausch – zu ermöglichen. Gegenüber den Postfächern haben wir hier kein ausgeprägtes gemeinsames Raumkonzept. Jeder Postkorb ist Bestandteil des individuellen Arbeitsplatzes, obwohl er strenggenommen »an der Grenze« zur gemeinsamen Arbeitsumgebung liegt, die aber nicht eigenständig repräsentiert ist. Doch auch für Postkörbe gilt, daß die Weitergabe von Arbeitsgegenständen unter Kontrolle der Benutzer einer Arbeitsumge-

4

897

Vom Arbeitsplatz zur Arbeitsumgebung


4.1


bung möglich ist. Wir haben gesagt, daß Postfächer ein gutes Mittel für Arbeitsverteilung und Stellvertretung sind. Dies ist mit Postkörben nicht so einfach zu realisieren. Dafür zeichnen sie sich durch einen besseren Schutz des Materialaustauschs aus, der in vielen Anwendungsbereichen erwünscht oder sogar unabdingbar ist. Technisch sind Postkörbe zunächst Behälter, die bei der Erzeugung einem Arbeitsplatz zugeordnet werden und eine feste Versandadresse haben. Beides kann abgefragt werden. Diese Umgangsformen sind für die Verwaltung der Postkörbe durch ein Postsystem notwendig. Das Postsystem realisiert den Materialtransport. Dazu dient ein Versandautomat als Teil eines softwaretechnischen Postsystems. Bisher haben wir den Materialtransport zwischen einzelnen Arbeitsplätzen immer durch die Weitergabe von Objekten und nicht nur durch Referenzen oder als Proxies konstruiert. Zwei Versandmechanismen bieten sich an: Das serialisierte Objekt wird über ein Netzprotokoll zwischen zwei Arbeitsplatzprozessen ausgetauscht (s. Kapitel 3.3.4). Eine schlichte Variante ist der Umweg über ein gemeinsames Dateisystem. Hierbei schreibt der Versandautomat der Senderumgebung das serialisierte Objekt in eine entsprechende Datei. Dann informiert er den korrespondierenden Versandautomaten des anderen Arbeitsplatzes über ein Ereignis oder Signal, der dann das Objekt aus der Datei ausliest.

4

898

Die technische Sicht auf Postkörbe


4.1


Ein Versandautomat implementiert die folgende Funktionalität:

899 Der Versandautomat

❑ Er sondiert die Postausgangskörbe seiner Arbeitsumgebung in

einzustellenden Intervallen oder auf Anforderung. Nach Empfang eines Materials fügt er es in den Posteingangskorb ein und signalisiert den Eingang an die Umgebung. ❑ Er bereitet das Material für den Transport vor oder rekonstru-

iert es nach dem Empfang. ❑ Er stößt den eigentlichen Transport an oder nimmt das Mate-

rial entgegen. ❑ Soweit der Versand über ein Netz realisiert wird, sondiert der

Versandautomat das Netz, um seine Verfügbarkeit anzeigen zu können. Der Pausenplanersteller und das Schulsekretariat sind über Postkörbe miteinander verbunden. Immer wenn eine Lehrperson eine Änderung ihrer Zeiteinteilung an das Sekretariat meldet, die den Pausenplan berührt, schickt das Schulsekretariat eine Notiz und den entsprechend markierten Pausenplan an den Pausenplanersteller. Ist ein neuer Pausenplan fertig, wird er an das Sekretariat geschickt. Dort werden Kopien ausgedruckt und an die Lehrpersonen verteilt.

4


4.1


900

Kooperationsmedium: Postversandsystem

Die nächste Stufe der expliziten Kooperation wird durch die Einführung eines Postversandsystems ermöglicht. Betrachten wir ein Postversandsystem als Kooperationsmedium, dann zeichnet es sich gegenüber der Rohrpostverbindung durch einen flexiblen Transport von Materialien zu Versandadressen aus. Hinzu kommen, konzeptionell und technisch begründet, Vorgangsmappen und Adressen. Fachlich ergibt sich dann folgendes Bild: Der Anwender legt die zu versendenden Materialien in eine Vorgangsmappe. Eine Vorgangsmappe ist ein fachlicher Behälter, in den generell beliebige Arbeitsmaterialien eingefügt und aus dem diese entnommen werden können. Der Anwender beschriftet die Vorgangsmappe mit einer Versandadresse. Diese Adresse kann sich auf eine andere Person (»Frau Angelika Muster«) oder eine Rolle (»Rechnungsprüfung«) beziehen. Damit ist klar, wer Empfänger der Vorgangsmappe ist. Die Vorgangsmappe kommt in das Ausgangsfach des Postkorbs. Der Transport erfolgt ähnlich wie beim Rohrpostsystem (s. Abbildung 4-5). Neu ist die Möglichkeit, eine Rolle zu adressieren. Daraus lassen sich unterschiedliche Entwurfsalternativen ableiten:

Die anwendungsfachliche Sicht auf den Postversand

Entwurfsalternativen für den Postversand

❑ Die Vorgangsmappe wird vom Postversand nach einem fest-

gelegten Algorithmus an einen konkreten Arbeitsplatz transportiert, dessen Anwender die Rolle ausfüllen kann.

4


4.1


901

❑ Es gibt einen Gruppenpostkorb oder ein Postfach für diese

Rolle. Darauf kann von allen potentiellen »Rollenträgern« zugegriffen werden, so daß die Zuteilung der Vorgangsmappe zu einem konkreten Arbeitsplatz in der Gruppe durch Konvention geregelt wird. Abb. 4-5 Kooperation zwischen mehreren Arbeitsplätzen durch ein Postversandsystem

in out

in out

in out

in out

4


4.1


Die Integration des Postversands in die Arbeitsumgebung stellt bereits ein recht ausgefeiltes Konzept zur expliziten Kooperation zur Verfügung, soweit sich Kooperation auf den Austausch von Materialien bezieht. Die Koordination der Arbeit basiert immer noch im wesentlichen auf Konventionen und wird über die Weitergabe der Materialien realisiert. Jeder der Beteiligten muß aber ein »intuitives Verständnis« davon haben, was die Aufgabe ist und wie sie mit den vorliegenden Materialien erledigt werden soll. Im System selbst gibt es davon kein Modell. Der Versandautomat verwendet die generischen Vorgangsmappen zum Transport von Materialien zwischen den Arbeitsplätzen. Die Vorgangsmappe macht keine Annahmen über ihren Inhalt. Selbst wenn eine Beschriftung der Mappe möglich ist, sollte keine Prüfung über konsistente Inhalte vom System durchgeführt werden, da dies die Verwendung zu sehr einschränkt oder die Konstruktion unnötig kompliziert macht. Als weitere Eigenschaft trägt die Vorgangsmappe die Absender- und die Empfängeradresse, damit der oder die Versandautomaten auch im Fehlerfall reagieren können. Bei der Realisierung wird es oft sinnvoll sein, bestehende Transportmechanismen (etwa ftp oder TCP/IP) als Systembasis zu verwenden. Zusätzlich muß noch der Mechanismus zur Rollenauflösung konstruiert werden. Dies kann über Tabellen erfolgen. Natürlich sind

4

902

Die technische Sicht auf den Postversand


4.1


903

auch komplexere Strategien mit Stellvertreterregelungen und Auslastungsalgorithmen denkbar. Ohne zwingende Notwendigkeit für solche komplexen Konstruktionen würden wir dabei aber zu einer schlichten Lösung raten (»keep it simple«). An dieser Stelle sehen wir auch bewußt von einer anwendungsfachlich sichtbaren Protokollierung des Transports ab, aus der sich der Verbleib und die Wege von Vorgangsmappen einfach nachvollziehen lassen, da dies im weiteren als eigenes Konzept behandelt wird. Das Pausenplanbeispiel könnte mit einem Postversandsystem so aussehen: Immer wenn eine Lehrperson eine Änderung ihrer Zeiteinteilung an das Sekretariat meldet, die den Pausenplan berührt, schickt ein Mitarbeiter des Schulsekretariats eine Versandmappe mit einer Notiz und dem entsprechend markierten Pausenplan an den Pausenplanersteller. Ist ein neuer Pausenplan fertig, schickt der Pausenplanersteller diesen adressiert an das Schulsekretariat zurück. Der erste Mitarbeiter des Schulsekretariats, der sich an diesem Tag im Schulinformationssystem anmeldet, erhält die Mappe in seinen Eingangskorb.

4


4.1


904

4.1.3 Explizites Kooperationsmodell: Die Unterstützung von routinisierter Zusammenarbeit Zur Unterstützung der Kooperation haben wir uns bisher einen bestimmten Kooperationstyp herausgesucht, den wir in der Büroarbeit besonders häufig finden. Diesen haben wir auch im Auge, wenn es um die Unterstützung sogenannter Vorgänge geht. Wir betrachten im folgenden solche arbeitsteiligen Prozesse, die nicht nur durch den Austausch von Material realisiert werden, sondern die durch ein explizites Kooperations- und Koordinationsmodell im System unterstützt werden. Für uns sind hier vor allem solche Kooperationsformen bei der Vorgangsbearbeitung von Interesse, die in zeitlich und räumlich getrennten Arbeitsschritten ablaufen. Charakteristisch für diese Form der Arbeitsteilung ist, daß verschiedene Personen – häufig mit unterschiedlichen Qualifikationen – zu verschiedenen Zeitpunkten an der Lösung einer Aufgabe zusammenarbeiten.

4


4.1


905

Anmerkung zu Workflow-Management-Systemen: Die Unterstützung von Vorgängen, oft auch Geschäftsprozesse genannt, ist offenkundig Gegenstand sogenanner Workflow-Management- oder Vorgangssteuerungssysteme. In diesem Buch machen wir nur eine Anmerkung zu den konzeptionellen Unterschieden zwischen den meisten Workflow-Management-Systemen und unserem Ansatz. Gründlicher beschäftigt sich [Gryczan 96] mit diesem Thema. Die vorherrschende Sichtweise von Workflow-Management-Systemen ist die ablaufsteuernde (s. S. 78). Im Anwendungssystem ist ein Algorithmus integriert, der die Reihenfolge und teilweise sogar die Art und Weise der Aufgabenerledigung vorschreibt. Dieser Mechanismus ist den Anwendern unzugänglich. Solche Systeme verhalten sich daher wie große Automaten (s. S. 198). Die Grundidee unseres Ansatzes ist, die Mechanismen der Vorgangssteuerung zu vergegenständlichen und den Anwendern als eine Form von Material für die Bearbeitung zugänglich zu machen, um auch den Prozeß der Vorgangsbearbeitung in ihre Verantwortung zu geben.

4


4.1


906

Ein Beispiel für Vorgangsbearbeitung im Bankenbereich: Kreditvergabe

Kredite werden in einer Bank durch Kundenberater vergeben. Dabei wird zwischen Neu- und Altkunden unterschieden. Neukunden stehen noch nicht in einer geschäftlichen Verbindung mit der Bank; Altkunden sind dagegen Kunden, die der Bank bekannt sind. Über Altkunden können bereits vor einem Beratungsgespräch Informationen eingeholt werden. Daraus kann sich z.B. ergeben, daß Finanzierungsalternativen für die Kreditvergabe vorbereitet werden. Welcher Berater das Beratungsgespräch mit dem Kunden führt, ist bankintern durch eine Kundenzuordnung geregelt. Die Zuordnung kann beispielsweise nach dem Kundennamen oder der Kontonummer erfolgen. Befürwortet der Berater den Kreditwunsch des Kunden, füllt er teils während, teils nach dem Beratungsgespräch mit dem Kunden das Kreditantragsformular aus. Außerdem erstellt er ein Gesprächsprotokoll. Die Vergabe des Kredits muß nun noch genehmigt werden. Für die Genehmigung des Kredits wird in der Regel ein weiterer Kundenberater hinzugezogen (Vier-Augen-Prinzip). Grundlage für die Genehmigung sind der ausgefüllte Kreditantrag und ein Gesprächsprotokoll über das Kundengespräch. Wenn der Kreditantrag vom zweiten Kundenberater gegengezeichnet wurde, geht der Vorgang zurück zum zuständigen Kundenberater. Der überprüft erneut den Kreditvertrag und verschickt die einzelnen Kopien an die zuständigen

4


4.1


907

Stellen der Kreditbearbeitung und des Controlling. Die Kreditauszahlung, die der zuständige Berater in der Regel bereits vor der Genehmigung veranlaßt, erfolgt über ein speziell eingerichtetes Verrechnungskonto, das für den Kunden bis zur endgültigen Kreditgenehmigung gesperrt ist. Die Auszahlung kann vom Kundenberater, vom Schalterangestellten oder von einem Sekretariat durchgeführt werden. Die folgende Abbildung 4-6 zeigt in einer modifizierten WozuTabelle (s. Kapitel 5.2.6) die wichtigsten Tätigkeiten, die bei der Kreditvergabe anfallen. In diesem Zusammenhang wird jeweils auch die Art der Zusammenarbeit und ihr Zweck angegeben. Abb. 4-6

Wer

erledigt was

mit wem/ was

wozu

1

Kundenberater

leitet weiter

Kunde, zustän- Kundenzuordnung erfolgt diger Kunden- nach den banküblichen berater Konventionen

2

Kundenberater

bereitet das Gespräch mit dem Kunden vor

Kundeninforma- um Grundvoraustionen und Un- setzungen für die Vergabe terlagen des Kredits zu prüfen

3

Kundenberater

berät

Kunden

um über die Kreditbewilligung entscheiden zu können

4

Kundenberater

füllt

Kreditantrag aus

der Kreditantrag ist zentrales Dokument der Kreditvergabe

4

Wozu-Tabelle einer Kreditvergabe


4.1


5

Kundenberater

verfaßt

6

Kundenberater

übergibt Kredit- zweiten Kununterlagen an denberater

7

zweiter Kunden- unterzeichnet berater

8

zweiter Kunden- gibt die Kredit- Kundenberater berater unterlagen zurück

der Kundenberater nimmt Kenntnis von der Genehmigung

9

Kundenberater

richtet ein

Verrechnungskonto

spezielles Konto für die Auszahlung

10

Berater/Sekretariat

zahlt den Kredit aus

Verrechnungskonto

Kredit dem Kunden verfügbar machen

11

Kundenberater

prüft und verteilt

Kreditantrag

die weitere Bearbeitung und Kontrolle wird veranlaßt

12

Back-Office-An- prüft gestellter

Kreditantrag, Dokumente, Konto

Back-Office-Kontrolle des Kredits

908

Gesprächspro- aus gesetzlichen und vertokoll waltungstechnischen Gründen zur Gegenprüfung (4-Augen-Prinzip)

Kreditantrag zur endgültigen Genehmiund andere Do- gung des Kredits kumente

4


4.1


909

Die folgende Abbildung 4-7 zeigt die Abhängigkeiten zwischen einzelnen Tätigkeiten bei der Kreditvergabe. In den Spalten »frühestens« und »spätestens« werden Aussagen über den Zeitpunkt getroffen, wann diese Tätigkeiten zu erfolgen haben. In der letzten Spalte wird ausgedrückt, ob eine Tätigkeit durchgeführt werden »muß« oder »kann«. Tätigkeit

frühestens spätestens muß/kann

1

Kundenzuordnung

–

vor 2

M

2

Gesprächsvorbereitung

nach 1

vor 3

K

3

Beratungsgespräch

nach 1

vor 6

M

4

Ausfüllen des Kreditantrags

während 3

vor 6

M

5

Protokollerstellung

nach 3

vor 10

K

6

Weiterreichen der Kreditunterlagen

nach 4

vor 7

M

7

Kreditgenehmigung

nach 6

vor 8

M

8

Zurückreichen der Kreditunterlagen

nach 7

vor 10

M

9

Verrechnungskonto einrichten

nach 1

vor 10

M

10

Kreditauszahlung

nach 9

vor 11

M

11

Kreditbearbeitung

nach 8

-

M

12

Kreditkontrolle

nach 4, 9

-

K

Abb. 4-7 Abhängigkeiten

4

bei der Kreditvergabe


4.1


Die Entscheidung über das Verfahren bei der Kreditvergabe wird bankeinheitlich getroffen. Die Darstellungen in den Tabellen wurden auf der Basis von Szenarios und Interviews mit Kundenberatern erarbeitet (vgl. [Bürkle et al. 95]). In ihnen spiegelt sich der (wenig erfolgreiche) Versuch wider, komplexe Arbeitsprozesse »in den Griff« zu bekommen, die sich in der täglichen Praxis zwar immer wieder ähnlich, aber eben doch in unterschiedlichen Varianten abspielen. Diese Art der Vorgangsbearbeitung, die wir jetzt näher betrachten, nennen wir routinisierte Zusammenarbeit. Sie hat einige charakteristische Merkmale (siehe dazu [Gryczan 96], die wir wie folgt zusammenfassen:

910

Merkmale routinisierter Zusammenarbeit

❑ In der Regel kennen sich die kooperierenden Personen persön-

lich und haben ein bestimmtes »Muster« der Zusammenarbeit entwickelt. ❑ Für die Zusammenarbeit werden Materialien als Teil des ange-

strebten Arbeitsergebnisses oder zu Informationszwecken zwischen den Beteiligten ausgetauscht, etwa in Vorgangsmappen oder Ordnern. Erst dadurch kann eine Gesamtaufgabe räumlich und zeitlich getrennt erledigt werden.

4


4.1


911

❑ Die Anzahl der an der Kooperation beteiligten Personen ist

begrenzt. Voraussetzung für die Kooperation ist ein gemeinsamer Erfahrungshintergrund, der auch festlegt, wer mit welchen Tätigkeiten zur Erledigung der kooperativen Aufgabe betraut werden kann. ❑ Die Menge der zu erledigenden Tätigkeiten liegt ebenfalls in

einer überschaubaren Größenordnung. Inhalt und Zweck der anfallenden Tätigkeiten sind allen Beteiligten bekannt. ❑ Die Kontrolle über den weiteren Verlauf der Zusammenarbeit

liegt jeweils bei der Person, die den gemeinsamen Vorgang gerade bearbeitet. Sie weiß nicht nur, was als nächstes zu tun ist, sondern kennt auch den Sinn und Zweck sowie die Dringlichkeit der weiteren Arbeitsschritte, die verantwortlich durch andere Personen wahrgenommen werden. ❑ Obwohl sich bestimmte Formen der Kooperation zwischen

den Beteiligten etabliert haben, läßt sich kein allgemeingültiger Arbeitsablauf für die Vorgangsbearbeitung definieren. Dafür kann es verschiedene Gründe geben: (1) Viele Tätigkeiten können an einem Arbeitsplatz parallel durch eine Person in einem Arbeitszusammenhang ausgeführt werden. (2) Nur für einen

4


4.1


912

Teil der Tätigkeiten sind Ergebnisse aus vorangehenden Tätigkeiten zwingend erforderlich. (3) Je nach Situation können einzelne Tätigkeiten auch entfallen oder spezielle andere hinzukommen. Routinisierte Zusammenarbeit ist zwar prinzipiell beschreibbar, ein konkreter Vorgang wird aber nur in seltenen Fällen ein genaues Abbild des Routinefalls sein. Hier liegt genau das Spannungsfeld für die Unterstützung kooperativer Arbeit, für die sich zwei grundlegend verschiedene Entwurfsalternativen abzeichnen. Einerseits können wir nach einer Prozeßbeschreibung suchen, die die gesamte »Logik« des Vorgangs implementiert (s. Anmerkungen zu Workflow-Management-Systemen auf S. 445). Diese Beschreibung muß alle möglichen Sonderfälle, die in der konkreten Situation entstehen können, voraussehen und behandeln. Die Erfahrung zeigt, daß diese vollständige Prozeßbeschreibung in vielen Fällen nicht möglich oder sinnvoll ist. Alternativ können wir versuchen, das Kooperationsmodell explizit und bearbeitbar zu machen, um die Zusammenarbeit der verschiedenen Personen zu koordinieren. Damit lassen sich auch Situationen abdecken, die aus einem vorformulierten Schema herausfallen.

4


4.1


Auch für den Fall, daß technisch beide Varianten möglich sind, haben wir uns im Rahmen des WAM-Ansatzes für den zweiten Ansatz entschieden. Zur Unterstützung routinisierter Zusammenarbeit wurde innerhalb des WAM-Ansatzes das Konzept der Prozeßmuster ausgearbeitet (vgl. [Gryczan 96, Wulf 95]). Prozeßmuster vergegenständlichen das zur routinisierten Zusammenarbeit passende Kooperationsmodell. Mit ihnen können Verantwortlichkeiten innerhalb einer Kooperation beschrieben und verändert werden und sie machen die Koordination deutlich. Prozeßmuster sind keine umfassende Steuerung eines kooperativen Arbeitsprozesses. Sie repräsentieren den »Normalfall«, der sich aufgrund von Erfahrungen herausgebildet hat. Ein Prozeßmuster ist zunächst ein abstraktes Konzept. Dieses Konzept haben wir im folgenden beschrieben. Praktische Erfahrungen liegen mit der einfachen Umsetzung als Laufzettel vor, die wir danach beschreiben.

913 Prozeßmuster

Das Konzept Prozeßmuster

Ein Prozeßmuster ist ein Material, das den normalen Umgang mit einer kooperativen Anwendungssituation vergegenständlicht. Dieses Material hilft bei der wechselseitigen Koordination von Reihenfolgen und Zuständigkeiten, wenn eine Aufgabe in einzelnen Arbeitsschritten

4


4.1


914

erledigt wird. Grundlage sind Konventionen und ein gemeinsamer Erfahrungshintergrund aller Beteiligten. Das Prozeßmuster kann je nach Situation verändert werden, um den aktuellen Gegebenheiten zu entsprechen. Mit Prozeßmustern tragen wir dem Umstand Rechnung, daß die Vielfältigkeit von Anwendungssituationen nicht in einem Softwaresystem durch einen vordefinierten Ablauf modelliert und gesteuert werden kann und soll. Ein Prozeßmuster wird so modelliert, daß es den Normalfall des kooperativen Arbeitsprozesses darstellt. Während der Vorgang bearbeitet wird, repräsentiert das Prozeßmuster auch den Bearbeitungszustand des aktuellen Arbeitsprozesses. Die folgende Abbildung 4-8 zeigt im Ausschnitt das Prozeßmuster Kreditvergabe. Für einen Teil der zu erledigenden Tätigkeiten werden fachliche Zusammenhänge definiert. Diese Abhängigkeiten werden durch gerichtete Pfeile dargestellt und sind im Sinne von »soll vor einer anderen Tätigkeit erledigt sein« zu interpretieren.

4


4.1

Kundenzuordnung Kundenberater


915 Abb. 4-8

✔

Ein Prozeßmuster für die Kreditvergabe

Gesprächsvorbereitung Kundenberater

Gespräch führen Kundenberater

Kreditkontrolle Schalterangestellter

Kontenanlage Kundenberater

Realisierung von Prozeßmustern durch Laufzettel

In der Praxis haben wir Prozeßmuster bisher als Laufzettel verwendet. Dies ist keine neue Idee (vgl. [Prinz & Kolvenbach 96]), aber sie ist einfach und funktionstüchtig. Betrachten wir wieder die anwendungsfachliche Seite.

4


4.1


Laufzettel lassen sich an Vorgangsmappen heften. Empfänger der Vorgangsmappen können dann schnell erkennen, wer mit den darin enthaltenen Unterlagen bereits was erledigt hat bzw. noch erledigen muß. Laufzettel sind Kooperationsmittel, die im Sinne des WAM-Ansatzes als Materialien interpretiert werden. Im Umgang mit ihnen unterscheiden wir verschiedene Aspekte:

916 Die fachliche Sicht auf den Laufzettel

❑ Ein Laufzettel ist ein Arbeitsgegenstand, der von einem

Anwender für einen speziellen Vorgang erstellt wird. Dazu gehört die Festlegung, wer für welche Tätigkeiten zuständig ist, welche Reihenfolge zwischen den Arbeitsschritten besteht und welche Dokumente benötigt werden. ❑ Ein Laufzettel kann für Routinevorgänge aus einer Sammlung

vorformulierter Laufzettel entnommen werden. Zeichnet sich ein neuer Routinevorgang ab, kann der Anwender diese Sammlung durch einen prototypischen Laufzettel (im Sinne einer Vorlage) erweitern. ❑ Laufzettel lassen sich entsprechend den Anforderungen der

konkreten Situation von Benutzern verändern oder anpassen. Dies gilt natürlich nicht für bereits abgeschlossene Arbeits-

4


4.1


917

schritte, die unveränderbar dokumentiert werden. Geändert werden können nur Zuständigkeiten (etwa wenn der vorgesehene Kollege erkrankt ist) und zu erledigende Tätigkeiten (etwa wenn ein Arbeitsschritt nur unzureichend erledigt wurde und wiederholt werden muß). ❑ Ein Laufzettel ist eine Anweisung für den Transport der damit

verbundenen Vorgangsmappe. Auf Basis der im Laufzettel vereinbarten Zuständigkeiten versendet das Postversandsystem die Mappe zum jeweils zuständigen Arbeitsplatz. ❑ Anwender koordinieren ihre Zusammenarbeit anhand von

Laufzetteln. Sie informieren sich über den Stand der Vorgangsbearbeitung. Sie sehen, wer bisher welche Tätigkeit erledigt hat und was noch zu erledigen ist, und haken selbst einzelne Tätigkeiten als erledigt ab. ❑ Vorgangsmappen können nachverfolgt werden. Ein Anwender

kann beim Postversandsystem anfragen, an welchem Arbeitsplatz eine Vorgangsmappe derzeit in Arbeit ist und wo sie bisher war. Diese Nachfrage sagt aber nichts darüber aus, ob und

4


4.1


918

wie der Inhalt der Vorgangsmappe derzeit auf dem Arbeitsplatz bearbeitet wird. Abb. 4-9 Koordination der Kooperation zwischen mehreren Arbeitsplätzen über Laufzettel in out

in out

➼ ➼ in out

in out

Die Realisierung von Laufzetteln erfordert wenig technischen Aufwand über ein Postversandsystem mit Vorgangsmappen hinaus. Wir hatten

4

Die technische Sicht auf den Laufzettel


4.1


919

schon darauf hingewiesen, daß ein Postversandsystem einfach um einen Protokollmechanismus erweitert werden kann, der den Transport der Vorgangsmappen dokumentiert. Soweit Vorgangsmappen eine eindeutige Bezeichnung haben, kann darauf der Nachverfolgungsmechanismus aufgesetzt werden. In welchem Umfang er wem zur Verfügung steht, ist kein technisches, sondern ein fachliches Problem. Der Wunsch, einen Vorgang nachzuvollziehen, muß abgewogen werden gegenüber der unerwünschten Kontrolle der Arbeit durch Dritte. Ähnliches gilt für die Änderbarkeit von Laufzetteln. Vielfach besteht im Anwendungsmanagement der Wunsch, Vorgänge im Sinne einheitlicher Geschäftsprozesse zu standardisieren. Dies muß abgewogen werden gegenüber der notwendigen Flexibilität der Vorgangsbearbeitung. Die Gestaltung der Laufzettel ist relativ frei möglich. Randbedingungen bestehen nur darin, daß die Empfänger vom Postversandsystem eindeutig als Personen oder Rollen identifiziert werden können. Es sollten auch ausreichend Informationen für die Kooperation und Koordination ersichtlich sein, ohne die Mappe erst öffnen zu müssen. Wieder gilt das bereits genannte Prinzip, daß die Angaben zu Inhalt und ausstehenden Arbeitsschritten vom Anwender frei gemacht werden können. Eine maschinelle Konsistenzprüfung zwischen Mappeninhalt, Laufzetteltexten oder gar einzusetzenden Werkzeugen

4


4.1


920

erfolgt nicht. Wir haben diese Einschränkung bewußt vorgenommen. Die maschinelle inhaltliche Prüfung des Mappeninhalts oder der an einem Arbeitsplatz vorhandenen Werkzeuge ist sehr komplex und bringt im Rahmen der hier betrachteten routinisierten Zusammenarbeit wenig, da die Beteiligten diese Aspekte selbst sehr gut abschätzen können.

4.1.4 Komplexe Kooperationsformen Mit der routinisierten Zusammenarbeit haben wir eine Kooperationsform beschrieben, die besonders im Bürobereich sehr verbreitet, aber noch relativ einfach ist. »Einfach« bezieht sich hier sowohl auf die Analyse als auch auf die mögliche Unterstützung. In Kapitel 5.2 haben wir eine Sammlung von Dokumenttypen mit den passenden und dabei bewährten Vorgehensweisen beschrieben, die wir in den verschiedenen Anwendungsbereichen bei der Analyse und Modellierung routinisierter Zusammenarbeit einsetzen. In anderen Anwendungsbereichen, z.B. im Krankenhaus, stellt sich die Situation viel komplexer dar. Auch dort haben wir erste Erfahrungen gesammelt (vgl. [Krabbel et al. 96a]), aber ein abgerundetes Bild über Analyse, Modellierung und Unterstützung ist noch nicht ent-

4


4.1


921

standen. Da dieser Bereich aber zunehmend (fachlich und softwaretechnisch) an Bedeutung gewinnt, skizzieren wir erste Ergebnisse und Erfahrungen. Offenbar haben wir es in Bereichen wie einem Krankenhaus oder anderen Dienstleistungsunternehmen (Ferienclub, Hotel, »Schönheitsfarm«) mit teils sehr komplexen Kooperationsformen zu tun. Das Besondere an diesen Kooperationsformen bezeichnen wir mit dem Begriff übergreifende Aufgaben [Krabbel et al. 96b]. Die Aufnahme eines Patienten als Beispiel für kooperatives Arbeiten im Krankenhaus

Als Beispiel für eine übergreifende Aufgabe in einem Krankenhaus beschreiben wir die Aufnahme eines Patienten. Die stark vereinfachte textuelle Beschreibung des Beispiels im folgenden soll die enge und zeitgebundene Zusammenarbeit zwischen den Bereichen Aufnahme, Station, Funktionsarbeitsplätze, Labor, Archiv, Küche, Pforte, Chefarztsekretariat, Verwaltung sowie der Rolle des diensthabenden Oberarztes zeigen.

4


4.1


Ausgelöst wird die Aufnahme eines Patienten normalerweise von außen, durch einen Anruf eines niedergelassenen Arztes (Hausarzt) oder durch den Bettennachweis. Die Anrufe richten sich an das Aufnahmebüro oder den diensthabenden Oberarzt. Die Aufnahme erstellt jeden Morgen eine aktuelle Übersicht über freiwerdende Betten. Diese wird vom diensthabenden Oberarzt morgens eingesehen. Die Vergabe von Betten erfolgt von Oberarzt und der Aufnahme in enger Absprache.

922 Beispiel Aufnahme eines Patienten

Trifft ein Patient bei der Aufnahme ein, so bringt er normalerweise einen Einweisungsschein vom Hausarzt mit, unterschreibt einen Aufnahmevertrag und wird hinsichtlich verschiedener Daten zur Person befragt. Er erhält seinen Aufnahmevertrag und die mit seinen Daten bedruckten (Etiketten-)Aufkleber und geht damit auf die Station. Die Aufnahme von Patienten erfolgt in der Regel am Vormittag. Auf der Station wird er von einer Krankenschwester weiter befragt. Sie füllt ein sogenanntes Stammblatt mit allgemeinen Pflegedaten aus und legt für den Patienten eine Krankenakte an. Weiterhin trägt sie den Patienten in eine Reihe von stationseigenen Plänen für die Zimmer- und Telefonübersicht und die Diagnose bzw. Pflegebehandlung ein. Sie leitet eine Essenskarte für den Patienten an die Küche weiter. Der behandelnde Stationsarzt untersucht den aufgenommenen Patienten und füllt unter anderem ein Anordnungsblatt aus. Alle darin angeordneten Maßnahmen überträgt eine Schwester in die Kurve. Für die im Rahmen der Aufnahme angeordneten (Routine-) Untersuchungen füllt die Krankenschwester zusätzlich

4


4.1


923

die entsprechenden Anordnungsformulare aus, legt sie dem Arzt zur Unterschrift hin und liefert die unterschriebenen Anordnungen bei den Funktionsarbeitsplätzen ab. Sie beschriftet Röhrchen für Laboruntersuchungen und füllt auch hierzu Anordnungsformulare aus. Falls der Patient bereits früher in dem Krankenhaus stationär behandelt wurde, fordert die Krankenschwester seine alte Akte aus dem Archiv an. Nachdem eine terminliche Abstimmung mit den Funktionsarbeitsplätzen erfolgt ist, wird der Patient zu den Untersuchungen geschickt oder gebracht. Von der Röntgenabteilung wird hierbei, sofern der Patient bereits stationär behandelt wurde, aus dem Archiv die alte Röntgentüte für den Befund angefordert. Der Untersuchungsbefund, der erst vom Röntgenarzt diktiert und dann von der Chefarztsekretärin auf das Anordnungsformular getippt wird, wird im Laufe des Nachmittags von den Schwestern abgeholt, dem behandelnden Arzt vorgelegt und in die Krankenakte eingeheftet. Am Nachmittag stellt die Aufnahme eine Arztmappe und eine Patientenmappe zusammen. Die Arztmappe enthält den späteren Entlassungsschein und Etiketten, die auf der Station in die Krankenakte eingeheftet werden. Die Patientenmappe verbleibt im Aufnahmebüro und umfaßt Unterlagen für die Abrechnung des Patienten bei der Krankenkasse. Weiterhin werden per Rechner Daten an die Krankenhausverwaltung weitergeleitet. Wir haben diesen Vorgang in Form eines Kooperationsbildes (s. Abbildung 4-10 und Kapitel 5.2.5) dargestellt.

4


4.1


924 Abb. 4-10 Kooperationsbild

Archiv Angehörige

Aufnahme eines Patienten Oberarzt

Hausarzt Stationsarzt Zu Hause

Funktionsarbeitsplatz

Station

Aufnahme

Bettennachweis Labor

Krankenkasse

Küche Verwaltung Chefarztsekretariat

Pforte

Schreibdienst

4


4.1


925

In diesem Bild werden die vielfältigen Verbindungen zwischen den einzelnen Bereichen sichtbar und es wird klar, daß ein Großteil der Arbeit aus koordinierenden Tätigkeiten wie Telefongesprächen und der Übergabe von Materialien besteht. Hinter jedem Pfeil zwischen zwei »Orten« verbirgt sich eine komplexe Zusammenarbeit, die oftmals sehr unterschiedlich gestaltet ist. Auch innerhalb der Räume, beispielsweise der Station oder des Funktionsarbeitsplatzes, wird zusammengearbeitet. Dies ist in dieser Übersicht nicht mehr dargestellt. Für das Beispiel gilt verallgemeinernd, daß die Tätigkeiten aller Mitarbeiter im Krankenhaus oft durch die Patienten ausgelöst werden und deswegen an deren Zustand und Bedürfnissen orientiert sind. Viele Personen müssen unterschiedliche Handlungen an einem Patienten durchführen und dabei eine Vielzahl zusätzlicher Randbedingungen (z.B. die Bedürfnisse anderer Patienten, die Stimmigkeit der Behandlung, festgelegte Termine für Mahlzeiten) beachten. Daher können diese Aufgaben nur in enger Zusammenarbeit und Koordination mit allen Beteiligten erfolgreich erledigt werden.

Wie das vorstehende Beispiel zeigt, arbeiten in einem Krankenhaus an der bereichsübergreifenden Aufgabe Aufnahme eines Patienten mindestens fünfzehn Organisationsbereiche an einem Vormittag zusammen – und das in dem von uns analysierten Krankenhaus für bis zu fünfundzwanzig Patienten. Offenkundig gibt es dort viele solcher übergreifenden Aufgaben. Um die Anforderungen an die Zusammen-

4


4.1


arbeit erfüllen zu können, hat sich in solchen Bereichen eine Arbeitskultur mit bewährten Organisationsformen der Zusammenarbeit herausgebildet. Die Kooperation beruht dabei in so hohem Maß auf Konventionen und einem Vorverständnis zwischen den Beteiligten, daß eine Analyse für Außenstehende extrem schwierig ist. Hilfestellung dabei bieten Dokumenttypen wie Kooperationsbilder und WozuTabellen (s. Kapitel 5.2.5 und 5.2.6). Die Merkmale von übergreifenden Aufgaben sind: ❑ Eine Vielzahl von Einzelpersonen unterschiedlicher Berufs-

926

Merkmale von übergreifenden Aufgaben

gruppen mit z.T. sehr unterschiedlichen Tätigkeitsfeldern und Verantwortlichkeiten arbeiten zusammen. Dabei gehören die einzelnen Personen oft unterschiedlichen organisatorischen Einheiten an und arbeiten in der Regel räumlich voneinander getrennt. ❑ Die Kooperation zwischen den Beteiligten beruht auf etablier-

ten Konventionen. Dies wird z.B. an einer großen Anzahl von Formulararten zur Anmeldung und Bearbeitung von Vorgängen deutlich. Gleichzeitig erfordert die Zusammenarbeit jedoch ein hohes Maß an Flexibilität, da ihre Erledigung von äußeren Faktoren abhängig ist (»der Kunde ist König«, »der Patient steht im Mittelpunkt«). Daher müssen standardisierte Vorgänge an die Situation anpaßbar sein.

4


4.1


927

❑ Die Zusammenarbeit erfordert von den einzelnen Beteiligten

oftmals nur einfache und kurz zu erledigende Teiltätigkeiten, die jedoch wiederholt und in engen Zeitvorgaben erledigt werden müssen. ❑ Die Kooperation erfordert eine Vielzahl von Einzeltätigkeiten

zur Koordination. Auch hierfür haben sich bestimmte Formen etabliert. Dazu gehören beispielsweise Absprachen in täglichen Besprechungen und per Telefon, die Weiterleitung von Materialien, die Darstellung von Informationen in verschiedenen Plänen, die zeitliche Koordinierung oder Ressourcenvergabe und das Signalisieren wichtiger Änderungen. ❑ Die Zusammenarbeit setzt an vielen Stellen ein sicheres Ver-

ständnis der Beteiligten über die jeweils flexibel von ihnen geforderten Teiltätigkeiten voraus. Erforderliche Tätigkeiten sind z.B. durch Ort und Zustand eines Gegenstandes erkenntlich (z.B. vorausgefülltes Formular im Postfach zur Unterschrift, Laborröhrchen auf dem Tisch im Stationszimmer) oder über vereinbarte Signale (z.B. ein gezogener Reiter in einer Aktenablage, Putzwagen vor einer Zimmertür).

4


4.1


Übergreifende Aufgaben zeigen noch weitere Merkmale komplexer Kooperation, die diese Aufgaben von der bisher betrachteten Büroarbeit unterscheidet: Nicht jeder Mitarbeiter hat einen festen Arbeitsplatz, an dem er im wesentlichen seine Arbeiten durchführt, sondern die Aufgaben müssen in verschiedenen Räumen erledigt werden. Dies hat zur Folge, daß auch Schreib- und Verwaltungsarbeiten, also die primären Kandidaten für eine Softwareunterstützung, an unterschiedlichen Orten ausgeführt werden müssen. Neben der Zusammenarbeit von unterschiedlichen Berufsgruppen finden wir bei komplexer Kooperation auch eine starke Arbeitsteilung zwischen Personen innerhalb eines Berufsfeldes, z.B. des Pflegepersonals im Krankenhaus. Die Aufgaben werden dabei an Gruppenarbeitsplätzen erledigt, die sich von den Einzelarbeitsplätzen unterscheiden:

928

Gruppenarbeitsplätze

❑ Wird eine Aufgabe an einem Gruppenarbeitsplatz bearbeitet,

dann kann dies zur Folge haben, daß Arbeitsschritte von einer Person begonnen und situationsbedingt von einer anderen Person fortgeführt werden. Daher ist innerhalb der Gruppe Informationsaufbereitung und enge Abstimmung bei gleichzeitigem freien Zugriff auf alle Arbeitsmaterialien erforderlich.

4


4.1


929

❑ Die Zusammenarbeit am Gruppenarbeitsplatz bedeutet nicht,

daß alle Aufgaben in einem festgelegten Raum erledigt werden. Dazu müssen Arbeitsmaterialien, Informationen und Pläne an den jeweiligen Ort transportiert werden können. Für den Systementwurf zeichnet sich ab, daß neben den genannten und bewährten Kooperationsmedien und -mitteln neue hinzukommen müssen, die die speziellen Anforderungen komplexer Kooperation mit den Möglichkeiten der Informationstechnologie vereinen.

4.1.5 Unterstützung von Kooperation durch eine ausgeweitete Raummetapher In diesem Abschnitt fassen wir die aktuelle Diskussion um eine Erweiterung der Raummetapher im WAM-Ansatz zusammen. Während Archive und gemeinsame Postfächer mit gutem Erfolg in Projekten eingesetzt werden, haben wir Erfahrungen mit den weitergehenden Konzepten bisher nur anhand verschiedener Prototypen gesammelt. Erste industrielle Projekte haben gerade begonnen. In diesem Sinne ist dieser Abschnitt als eine »Vision« darüber zu verstehen, wie sich der Ortsbegriff im WAM-Ansatz in Richtung einer Raummetapher bewegen wird. Wir sprechen von einer »erweiterten« Raummetapher, weil mit dem Umgebungsbegriff bereits eine Raummetapher vorgestellt wurde.

4


4.1


Was ist der Kern der erweiterten Raummetapher? Orte werden durch Räume repräsentiert. So wollen wir den intuitiven Umgang mit dem Konzept durch Benutzer sicherstellen. Schließlich kennt jeder das Konzept des Raumes (im Sinne von Zimmer) aus eigener Erfahrung. Abbildung 4-11 zeigt als Beispiel die Skizze eines Raumplans. In den Räumen befinden sich Personen und Gegenstände.

930 Raummetapher zur Kooperationsunterstützung

Abb. 4-11 Skizze eines Raumplans

4


4.1


Für die erweiterte Raummetapher, die über die bisher vorgestellten Konzepte hinausgeht, sind folgende Kriterien zu beachten:

931 Kriterien für die erweiterte Raummetapher

❑ Gegenseitige Wahrnehmung (Awareness): Die Benutzer des

Systems sollen einander wahrnehmen (z.B. sehen) können, um sich so in ihrer Arbeit zu koordinieren. ❑ Kommunikation: Benutzer sollen über die gegenseitige Wahr-

nehmung hinaus auch explizit miteinander kommunizieren können. Auch wenn die Raummetapher primär zur Unterstützung von Kooperation und Koordination eingesetzt werden soll, ist offensichtlich, daß weitere Merkmale vorhanden sein müssen: Materialien und Werkzeuge müssen in Räumen adäquat präsentiert werden. Wenn Personen nicht mehr wissen, wo sie sich im System befinden, können sie nicht mehr sinnvoll arbeiten oder kooperieren. Daher muß die Raummetapher auch der Orientierung dienen. Wir stellen im folgenden die zentralen Elemente und Eigenschaften der ausgeweiteten Raummetapher vor. Diese Punkte entsprechen alle unserem Alltagsverständnis. Wir haben die Punkte, bei denen wir Veränderungen des Konzepts gegenüber der Alltagserfahrung vorgenommen haben, mit gekennzeichnet.

4


4.1


Allgemeine Eigenschaften der Raummetapher:

932 Eigenschaften

Abgeschlossenheit: Es gibt keine Orte außerhalb von Räumen.

der Raummetapher

❑ Einheit von Ort und Zeit: Jede Person und jedes Ding befindet

sich zu einem Zeitpunkt an genau einem Ort, also in genau einem Raum. ❑ Mobilität: Personen können sich von einem Raum in einen

anderen Raum bewegen. Dinge können dabei von Personen mitgenommen werden und auf diese Weise ebenfalls den Raum wechseln. Topographie: Räume sind topografisch angeordnet. Sie haben als Quader Länge, Breite und Höhe. Es können nur physikalisch mögliche Gebäude gebaut werden. Navigation: ❑ Verbindungen: Jeder Raum hat eine oder mehrere Türen,

durch die angrenzende Räume betreten werden können. Raumplan: Alternativ zu dem Weg durch Türen können Räume direkt über einen Raumplan betreten werden. Auf diesem Wege können jedoch nur die Räume betreten werden, die

4


4.1


933

auch durch Türen zugänglich sind. So ist das Betreten eines Raumes über den Raumplan als Abkürzung für den Weg durch mehrere Räume und Türen vorstellbar. Lokalisierung: Personen und Dinge können lokalisiert werden. Der entsprechende Ort wird im Raumplan angezeigt. Gegenseitige Wahrnehmung und Kommunikation: Flexible Sichtbarkeit: Während Personen sich zu einem Zeitpunkt in genau einem Raum befinden, können sie in beliebig viele weitere Räume hineinsehen. Dazu müssen diese Räume nicht direkt an den Raum der Person angrenzen. Personen können nur in solche Räume sehen, zu denen sie Zugang haben. ❑ Gegenseitige Wahrnehmung: Personen in einem Raum nehmen

die anderen und deren Handlungen wahr und können sich so koordinieren. ❑ Kommunikation: Personen, die sich in einem Raum befinden,

können explizit miteinander kommunizieren. Denkbar sind einfache zeilenorientierte Chat-Tools bis hin zu Videokonferenzsystemen.

4


4.1


934

❑ Koordinationsmedien: Zur Koordination können zusätzliche

Koordinationsmedien verwendet werden. Dies sind z.B. »Schwarze Bretter«, Archive oder Besprechungstische. Zugriffsschutz: ❑ Schlüsselkonzept: Jede Tür und jeder Arbeitsgegenstand kann

durch ein Schloß gesichert sein. Eine Person kann einen Raum nur betreten und den Arbeitsgegenstand benutzen, wenn sie den dafür notwendigen Schlüssel besitzt. ❑ Privatheit und Öffentlichkeit: Räume und Arbeitsgegenstände

können über das Schlüsselkonzept privat und öffentlich gemacht werden. Hat nur eine Person einen Schlüssel zu einem Raum oder Arbeitsgegenstand, so sind sie privat. Ist ein Raum durch kein Schloß gesichert, so ist dieser Raum öffentlich. Ist ein Arbeitsgegenstand nicht gesichert, so ist dieser Gegenstand für alle Personen benutzbar, die den entsprechenden Raum betreten können. Durch das Verteilen von mehreren Schlüsseln sind flexible Zwischenstufen möglich. Handgepäck: Jede Person hat ihr privates Handgepäck mit Unterlagen und Arbeitsmitteln ständig bei sich, unabhängig vom Raum, in dem sie sich gerade befindet. Dieses Gepäck kann nicht ohne ausdrückliche Genehmigung von anderen Personen eingesehen oder benutzt werden.

4


4.1


Diese Skizze einer erweiterten Raummetapher ist sicher noch nicht vollständig und wird sich in den laufenden Projekten noch verändern und konkretisieren. Interessant sind aber bereits die Gründe, weshalb wir in einigen Punkten von der Alltagserfahrung mit Räumen und Orten abgewichen sind.

935 Weitergehende Kriterien der Raummetapher

❑ Abgeschlossenheit: Offenkundig gibt es in unserer Umgebung

sehr wohl Orte außerhalb von Räumen. Wir beschränken uns bei der erweiterten Raummetapher auf die Orte in Gebäuden. Wir halten dies für eine zulässige Einschränkung, da die meisten Menschen ihre Arbeiten ausschließlich innerhalb eines Gebäudes verrichten. Orte »unter freiem Himmel« können bei Bedarf ohne Probleme als zusätzliche Räume nachgebildet werden. ❑ Topographie: Wir haben die Einschränkung vorgenommen,

daß die Räume in der erweiterten Raummetapher immer einen Quader darstellen, was alltäglich keineswegs immer der Fall ist. Durch diese Einschränkung verlieren wir jedoch keine wichtigen Eigenschaften physikalischer Räume und gewinnen dafür die einfachere Handhabbarkeit für Benutzer und Entwickler. Wenn Räume immer Quaderform haben, fällt die Orientierung und Navigation leichter.

4


4.1


936

❑ Raumplan: Es ist keineswegs ungewöhnlich, einen Raumplan

für ein Gebäude zu haben. Im Alltag ist es aber unmöglich, sich einfach über den Raumplan in den gewünschten Raum zu versetzen. Wir müssen immer den vollständigen Weg von der aktuellen Position zum gewünschten Raum gehen. Der direkte Weg über den Raumplan scheint uns sinnvoll, um die Benutzung des Systems nicht unnötig umständlich zu machen. Möglicherweise können durch die häufige Benutzung dieses Mechanismus, Orientierungsprobleme beim Benutzer auftreten. Ob dies ein ernstzunehmendes Problem darstellt, wird die Erfahrung zeigen. ❑ Lokalisierung: Eine Lokalisierung von Personen oder Gegen-

ständen in einem physikalischen Gebäude ist in der Regel mit großem Aufwand verbunden. Hier nutzen wir die Möglichkeiten von Software. ❑ Flexible Sichtbarkeit: Im Alltag kann eine Person nur in sehr

wenige Räume gleichzeitig hineinsehen. Dies ist in der Regel sogar auf direkt angrenzende Räume beschränkt. Wir haben an dieser Stelle die Raummetapher so erweitert, daß in beliebig viele andere Räume hineingesehen werden kann, sofern diese für die Person betretbar sind. Dies ist sicherlich eine wün-

4


4.1


937

schenswerte Eigenschaft des Systems, die aber zu Orientierungsproblemen führen kann. Wichtig ist jedenfalls, daß wir die Einheit von Ort und Zeit nicht aufgeben. ❑ Handgepäck: Der hier angesprochene Privatbereich existiert

alltäglich. Üblich sind Aktentaschen und -koffer, aber auch Jacken- oder Hosentaschen, die Handtasche oder einfach die eigenen Hände. Dinge, die wir unterwegs bei uns tragen, befinden sich in unserem Handgepäck. Die Erweiterung, die wir in der Raummetapher vorgenommen haben, ist ebenso einfach wie effektiv: Es können beliebig viele Dinge beliebiger Größe im Handgepäck transportiert werden. Zusätzlich kann jedes Werkzeug und Material direkt im Gepäck benutzt werden. Dies ist alltäglich kaum möglich, weil Werkzeuge zu groß sind oder es in der Handtasche zu dunkel ist. Dazu legen wir üblicherweise den Inhalt des Handgepäcks auf einen Tisch, um dort zu arbeiten. Dieser zusätzliche Schritt ist in der erweiterten Raummetapher nicht notwendig. Beispiel einer System-Vision »Planung für den Tag erstellen«: Die Krankengymnastin meldet sich am Rechner an und bekommt ihren privaten Arbeitsplatz auf dem Bildschirm angezeigt (s. Abbildung 4-12).

4


4.1


938 Abb. 4-12 Arbeitsplatz einer

Flur

Krankengymnastin

Terminplan

Arbeitsplatz

Sie öffnet mit einem Klick auf das Koffersymbol in der Navigationsleiste des Arbeitsplatzes ihr Handgepäck und verschiebt ihren Terminkalender vom privaten Arbeitsplatz dorthin (s. Abbildung 4-13).

4


4.1


939 Abb. 4-13 Terminplan im Handgepäck

Flur

Arbeitsplatz Handgepäck Terminplan

Jetzt öffnet die Krankengymnastin durch Klick auf das Raumplansymbol in der Navigationsleiste den Raumplan (s. Abbildung 4-14).

4


4.1


940 Abb. 4-14 Geöffneter Raumplan

Raumplan Anmeldung

Müller

Behandlung 1

Schmidt

Flur

Behandlung 2 Station 1

Station 2

BGAmbulanz

Arbeitsplatz Handgepäck Terminplan

Darin wählt sie die erste ihr zugeteilte Station aus und öffnet durch einen Doppelklick das Schwesternzimmer. Im Schwesternzimmer sind diverse öffentlich zugängliche Materialien zu sehen, darunter das Mitteilungsbrett (s. Abbildung 4-15).

4


4.1


941 Abb. 4-15 Blick in das

Flur Mülleimer

Schwesternzimmer

Mitteilungsbrett Patientenakten

Station 1 Handgepäck Terminplan

Die Krankengymnastin klickt das Symbol Mitteilungsbrett an. Auf dem angezeigten Mitteilungsbrett befinden sich Verordnungen über Behandlungen sowie weitere Mitteilungen z.B. über bestimmte Patienten. Die Krankengymnastin sucht die für sie bestimmten Mitteilungen und liest sie. Nach dem Lesen schiebt sie die Mitteilungen in den Mülleimer.

4


4.1


942

Sind Verordnungen auf dem Mitteilungsbrett, öffnet die Krankengymnastin ihren Terminplan im Handgepäck. Der Terminplan zeigt auf der linken Seite die variablen und rechts die festen Aufgaben. Da sich die festen Aufgaben selten ändern, kopiert sie durch Klick auf den Knopf vom Vortag kopieren die festen Aufgaben des Vortags (s. Abbildung 4-16). Die Verordnungen über Behandlungsaufträge zieht sie vom Mitteilungsbrett auf ihren Terminplaner. Dadurch werden die Verordungen vom Mitteilungsbrett entfernt. Gleichzeitig signalisiert dies den Stationsschwestern, daß die Verordnungen von der Krankengymnastin gelesen wurden. Ist der Patient bereits auf der rechten Seite des Terminplans vorgemerkt, wird die Verordnung automatisch links in der richtigen Zeile einsortiert. Bei neuen Patienten wird automatisch ein neuer Eintrag auf der rechten Seite erzeugt. Dieser Eintrag wird farblich markiert, damit die Krankengymnastin einen besseren Überblick über ihre neuen Patienten hat. Die Krankengymnastin trägt weitere Notizen manuell in ihren Terminplan ein. Dann schließt sie das Mitteilungswerkzeug.

4


4.1


943 Abb. 4-16

Mitteilungsbrett Hr. Mai: Zust. n. Herzinfarkt Fr. Will: Pneumonie Mülleimer

Verordnun g Fr. Ulla Will 07.02.1965 Atemtherapie

Mitteilungen und Flur

Terminplan

Mitteilungen

Patientenakten

Station 1

Handgepäck

Terminplan, 02.03.98

vom Vorta g kopieren

OP am 04.03.98 zum Essen raussetzen

Hr. Holst, St. 1, Zi. 113 Fr. Ber ger, St. 2, Zi. 201 Fr. Klettke, St. 2, Zi. 207

Termin BG-Ambulanz: 09.03.98, 10 Uhr Termin Dr.Frank: 11.03.98, 15 Uhr Terminplan

Anschließend öffnet sie den Waschplan und sieht nach, ob und wann ihre Patienten an diesem Tag gewaschen oder gebadet werden. Die entsprechenden Zeiten vermerkt sich die Krankengymnastin in ihrem Terminplan.

4


4.1


Die Krankengymnastin wählt jetzt aus dem noch offenen Raumplan die nächste ihr zugeteilte Station an und betritt dort das Schwesternzimmer. Sie verfährt in diesem Schwesternzimmer und allen folgenden nach dem gleichen Schema. Allerdings muß sie jetzt nicht mehr ihr Handgepäck oder ihren Terminplan öffnen, da beide bereits geöffnet sind. Wenn wir die Systemvision unseres Beispiels mit der aktuellen Arbeitssituation in dem betreffenden Krankenhaus vergleichen, so stellen wir schnell fest, daß die Systemvision sehr eng an die bestehenden Arbeitsabläufe angelehnt werden konnte. Dies scheint uns ein allgemeines Phänomen bei der Verwendung der Raummetapher zu sein. Durch die Möglichkeit, das Ortskonzept als Räume in Anwendungssystemen nachzubilden, ist es oftmals nicht mehr notwendig, einen bewährten Handlungsablauf umzustrukturieren. In den aktuellen Projekten werden wir diese These überprüfen.

4

944

Diskussion des Beispiels


4.2

4.2

Interaktive Anwendungssysteme und Persistenz

945


Wenn wir Arbeitsplätze mit Werkzeugen und Materialien gestalten wollen, müssen wir auch den Aspekt der Langlebigkeit von Materialien berücksichtigen. Genau an diesem Punkt endet aber in vielen derzeitigen Projekten die objektorientierte Welt. Uns ist klar, daß im heutigen industriellen Umfeld der Einsatz objektorientierter Datenbanken für »operative Daten« noch eher die Ausnahme ist. Zudem erfordert die Einbettung von Arbeitsplatzsystemen in ein konventionelles Umfeld Konzepte, wie die dort vorhandenen Datenbanken und »Datenquellen« (Data Feed, s. S. 472) mit der Architektur eines Anwendungssystems nach dem WAM-Ansatz vereinbart werden können. In diesem Abschnitt beschreiben wir daher, wie der Bruch zwischen konventionellen und objektorientierten Systemen zu überwinden ist, und welche geeigneten Architekturen sich technisch dabei anbieten. Wir verdeutlichen die verschiedenen Probleme und exemplarischen Lösungsansätze wieder vor dem Hintergrund konkreter Projekte.

4

Federführung: Ingrid Wetzel Ko-Autor: Ingrid Dörre, Michael Franz, Daniel Megert, Peter Rieth, Falk Wiegand, Heinz Züllighoven


4.2


946

4.2.1 Zwei Welten: objektorientierte Softwareentwicklung und Datenbanken Objektorientierte Anwendungsentwicklung und Datenbanken stehen sich bei genauerer Betrachtung in vielen Punkten konzeptionell entgegen. Wir zeigen dies für die unterschiedlichen Sichtweisen, Konzepte und Dienstleistungen. Diese Unterschiede müssen klar werden, da sonst Probleme im Zusammenspiel von Anwendungssystemen und den verschiedenen Mitteln der Persistenz entstehen. Auf der Grundlage der Unterschiede können wir dann konstruktive Lösungen entwickeln. Entwickler von Anwendungssystemen nach dem WAM-Ansatz sehen in ihren Anwendern Experten der Anwendungsdomäne, die die entscheidende Kompetenz besitzen, um ihre Aufgaben zu erledigen, und mit den dafür geeigneten Arbeitsgegenständen umgehen können. Anwendungsentwickler müssen herauskristallisieren, welche Softwarewerkzeuge und welche Materialien zukünftig bei der Erledigung dieser fachlichen Aufgaben eine sinnvolle Unterstützung bieten können. Für arbeitsteilige Aufgaben müssen sie entscheiden, welche bewährten Formen der Kooperation im System nachzubilden und wo neue Möglichkeiten zu realisieren sind. In Kapitel 4.1.2 haben wir gezeigt, daß dabei die gemeinsam genutzten Materialien eine wichtige Rolle spielen.

4

Unterschiedliche Leitbilder bei Analyse und Entwurf


4.2


947

Entwickler von Datenbankanwendungen stellen die Daten und ihren Schutz in den Vordergrund. Sie versuchen, korrekte Datenbeschreibungen und Konsistenzbedingungen zu erfassen, um die Gültigkeit der Daten in jedem Fall zu gewährleisten. Fehlerhafte Daten würden eine Datenbank nutzlos machen. Die häufig über lange Zeit angesammelten Daten sind eine auswertbare Investition. Da in der Regel unterschiedliche Anwendungen auf derselben Datenbank arbeiten, müssen die Daten nicht nur vor fehlerhaften Benutzereingaben (durch doch nicht so kompetente Anwender) geschützt werden, sondern auch vor fehlerhaften Anwendungsprogrammen. Ebenso müssen Anomalien im Mehrbenutzerbetrieb oder Hardwarefehler berücksichtigt werden. Datenbankmanagementsysteme unterstützen diesen Schutz. Je nach Standpunkt lassen sich folgende Aspekte für die Entwicklung gegenüberstellen:

Unterschiedliche Aspekte bei der Entwicklung

❑ Arbeitsplatz versus Gesamtorganisation, ❑ Identifikation von Aufgaben mit ihren Arbeitsabläufen versus

benötigte Daten, ❑ Ablage von und Zugriff auf einzelne Materialien versus Schutz

und Datenauswertung.

4


4.2


948

Die verschiedenen Aufgaben bei der Datenbankanbindung werden in der Regel von unterschiedlichen Teams geleistet. In den von uns betrachteten Projekten sind das meist objektorientierte Entwicklerteams und Datenbankteams; wobei im Datenbankbereich relationale, aber auch Netzwerk- oder hierarchische Konzepte vorherrschen. Der unterschiedliche Hintergrund und die Ausrichtung dieser Teams muß im Projekt berücksichtigt werden. Verständigungsschwierigkeiten, unterschiedliche Herangehensweisen und Schwerpunktsetzungen müssen durch gezieltes Vorgehen verdeutlicht und ausgehandelt werden, damit eine Gesamtarchitektur entsteht, die den unterschiedlichen Standpunkten der Beteiligten gerecht wird.

Konsequenzen für die

Auf der Konzeptebene pflanzen sich die verschiedenen Standpunkte fort. Die wesentlichen Unterschiede liegen in der Modellierung von Materialien, ihren Identifikationsmöglichkeiten und in der Unterscheidung von Objekten und Werten. Als Anwendungsentwickler modellieren wir beim objektorientierten Entwurf Objekte durch ihr Verhalten. Die Implementierung und damit die Repräsentation des zu speichernden Objektzustands sind gekapselt und von außen nicht direkt zugänglich. Objekte werden über einen internen, eindeutigen Objektidentifikator unterschieden. Wir greifen auf ein Objekt von außen per Navigation zu, ausgehend

Unterschiedliche Konzepte

4

Projektdurchführung

für die Modellierung


4.2


949

von einem bekannten Wurzelobjekt. Werden bei Analyse und Entwurf Objekte und Werte unterschieden, so ist diese Unterscheidung in objektorientierten Programmiersprachen nur bei der Benutzung von Basistypen direkt umsetzbar. Für benutzerdefinierte Werttypen haben wir ein eigenes Konzept vorgestellt (s. Kapitel 3.2.8). Bei der Modellierung im Datenbankbereich ist traditionell die Struktur von Objekten und ihre Beziehung untereinander vorrangig. Die Modellierung legt die Struktur der Objekte nach außen offen. Dadurch können Datenmengen hinsichtlich ihrer Attributwerte und Beziehung ausgewertet werden. Unterschiedliche Objektbeziehungen (1:1, 1:n und n:m) werden explizit modelliert. Die Exemplare einer Klasse werden als ihre Extension betrachtet, die über die Klasse zugänglich ist. Objekte werden von außen, d.h. durch benutzerdefinierte Werte, identifiziert. Im relationalen Modell sind dies ausgezeichnete Attribute. Der Umgang mit Objekten wird meist auf einen Satz generischer Operationen (»anlegen, ändern, löschen«; s. S. 31ff.) im Datenmodell reduziert. Diese bilden die Basis für Anwendungsprogramme. Die Auswertung von Datenmengen wird durch deklarative Anfragesprachen unterstützt.

4


4.2


950

Unterschiede bei den Konzepten sind also: ❑ Modellierung von Verhalten versus Struktur, ❑ intensionale versus extensionale (Mengen-) Aspekte, ❑ Objektidentität versus Identifikation über ausgewählte Werte, ❑ anwendungsspezifische

Umgangsformen versus generische

Operationen. Wir müssen die Unterschiede bei der Modellierung berücksichtigen, wenn wir Datenbanken an objektorientierte Anwendungsysteme anbinden wollen. Verschiedene Abbildungen sind zu leisten. Leitfragen dazu lauten:

Konsequenzen für die Konstruktion

❑ Welche Attribute einer Klasse sind für die Speicherung rele-

vant? ❑ Was sind die anwendungsbezogenen Identifikatoren der

Objekte einer Klasse? ❑ Wie können die unterschiedlichen Strukturierungs- und Navi-

gationsanforderungen effizient auf Datenbankschemata abgebildet werden?

4


4.2


951

❑ Was bedeutet Polymorphie, Rollen und Objektmigration für

die Datenhaltung (s. Kapitel 2.1)? ❑ Wie können komplexe Objekte gespeichert und teilweise gela-

den werden? Sind verschiedene Datenbanken mit unterschiedlichen Datenmodellen anzuschließen, müssen wir diese Aufgaben mehrfach erledigen. Bei der Festlegung von Datenbankschemata (samt Indices) müssen wir das Profil der Anwendung berücksichtigen (s.u.). Auswertungsdatenbanken erfordern andere Schemata als solche, die »nur« zum Abspeichern und Wiederauffinden von Objekten benötigt werden. Auch im Bereich der angebotenen Dienstleistungen (Services) unterscheiden sich objektorientierte Anwendungsentwicklung und der Datenbankbereich. Bei der objektorientierten Konstruktion ist für uns die jeweilige Architektur wesentlich. Dabei nutzen wir Vererbung, Identifikation und Wiederverwendung von Mustern und entwickeln Rahmenwerke. Sehr wichtig ist auch die Realisierung des Benutzungsmodells mit Fenstersystemen und Ereignismechanismen. Im Datenbankbereich liegt traditionell der Schwerpunkt bei der Gewährleistung redundanzfreier, integrierter Datenbestände für ver-

4

Unterschiedliche Dienstleistungen


4.2


952

schiedene Anwendungen mit physischer und logischer Datenunabhängigkeit auf der Basis einer Schichtenarchitektur. Wir berücksichtigen von Anfang an, daß große Datenmengen effizient behandelt werden können. Die Datenkonsistenz erfordert Konzepte zur Integritätsüberwachung. Mehrbenutzerfähigkeit und Datenrückgewinnung führt zu entsprechenden Transaktionskonzepten. Die relative Geschlossenheit traditioneller Datenbankmanagementsysteme mit Diensten wie Transaktionskonzept und Sperrverfahren, auf denen Datenbankanwendungen realisiert wurden, ist heute vielfach nicht mehr gegeben. Objektorientierte Datenbanken, ODBCSchnittstellen auf relationale Datenbanken oder CORBA-basierte Kommunikation mit verteilten Objekten stellen ein vielfältiges Angebot dar. In jedem dieser Bereiche werden unterschiedliche Transaktionskonzepte oder Sperrmechanismen angeboten. Die Diversifizierung der unterschiedlichen Dienstleistungen, gepaart mit Anforderungen, käufliche Standardsysteme zu integrieren oder bestehende Altumgebungen einzubeziehen, stellt hohe Anforderungen an den Aufbau geeigneter Architekturen für Anwendungssysteme. Daneben besteht oft eine große Unsicherheit, für welche Produkte sich ein Unternehmen grundsätzlich entscheiden sollte. Es gilt daher zu klären, welche Aufgaben in wessen Domäne fallen, z.B. auf welcher

4

Konsequenzen hinsichtlich der Architektur von Anwendungssystemen


4.2


953

Ebene Kooperationsmodelle für die gemeinsame Nutzung von Materialien zu realisieren sind. Wir sehen derzeit keine klaren Vorgaben, geschweige denn Standardarchitekturen für Anwendungssysteme. Projekte müssen im Rahmen ihrer vorhandenen Systemlandschaft neue Wege gehen. Dazu müssen Zeit und Ressourcen eingeplant weren. Probleme mit Effizienz sind vorprogrammiert. Die Anwendungen selbst stellen unterschiedliche Anforderungen an die Persistenzunterstützung. Daraus lassen sich verschiedene Anwendungsprofile entlang der folgenden Kriterien ableiten:

Verschiedenheit im Anwendungsprofil

❑ Langlebigkeit der Objekte: Objekte einer Arbeitsumgebung,

d.h. vor allem Materialien, müssen über einen langen Zeitraum abgelegt und wiedergeholt werden können. ❑ Gemeinsame (operationale) Nutzung von Objekten: Objekt-

mengen, meist in Form fachlicher Behälter, stellen langfristig gemeinsam zu nutzende Materialien zur Verfügung und bilden damit eine wichtige Grundlage, um Kooperation im Dienstleistungs- und Produktionsprozeß zu unterstützen. ❑ Analytische Auswertung von Objektmengen: Die Analyse der

gesammelten Objektmengen im Sinne des aktuellen Data-

4


4.2


954

Warehouse-Gedankens bedeutet, daß der operationale Bestand mit Blick auf die Steuerung des Unternehmens ausgewertet werden kann. Hier wird normalerweise der Zugriff auf Daten aus verschiedenen Anwendungsbereichen eines Unternehmens benötigt. Jedes Entwicklungsprojekt sollte sorgfältig hinsichtlich seines Anwendungsprofils untersucht werden. Was steht im Vordergrund und was muß auch noch abgedeckt werden? Muß vorrangig der Materialbestand für die einzelne Arbeitsumgebung abgesichert werden, dann können einfache Persistenzmechanismen mit Hilfe von Dateisystemen völlig ausreichen. Liegt der Schwerpunkt bei der gemeinsamen Nutzung von Materialien, dann bieten objektorientierte Datenbanken heute vielfach eine ausreichende Leistung und Sicherheit bei hohem Entwicklungskomfort. Steht das analytische Geschäft im Mittelpunkt und müssen konventionelle Datenbestände integriert werden, dann stellt meist die Anbindung einer relationalen Datenbank eine geeignete Lösung dar. Für komplexere Anwendungen wird sich allerdings selten ein eindeutiges Profil erstellen lassen. Dort sind dann »hybride« Lösungen gefragt: etwa objektorientierte Datenbanken für das operationale und relationale Datenbanken für das analytische Geschäft. In solchen Fäl-

4

Konsequenzen hinsichtlich der Gesamtstrategie


4.2


955

len sind Replikatdatenbanken für die analytische Auswertung eine gute Lösung, obwohl der Gedanke an redundante Datenbestände bei konservativen Datenbankentwicklern immer noch auf heftigen Widerstand stößt.

4.2.2 Gemeinsame Nutzung von Materialien Zur Illustration haben wir ein Beispiel aus dem Bankenbereich gewählt, bei dem die gemeinsame Nutzung von Materialien wichtig ist. Wir beschreiben die fachlichen Anforderungen und die Umsetzung in einen fachlichen Entwurf. Anschließend diskutieren wir allgemeine Entwurfsfragen und gehen auf die technische Realisierung ein. Beispiel für gemeinsame Nutzung langlebiger Materialien

Als Beispiel dient ein Kooperationsprojekt zur Vergabe von Krediten an Kommunen in der Kommunalkreditabteilung einer Landesbank. Kennzeichnend für diese Art der Kreditvergabe ist, daß der wesentliche Teil des Geschäfts, nämlich die Verhandlungen über Konditionen und der Vertragsabschluß, in sehr kurzen Zeiträumen und ausschließlich telefonisch erfolgen. Später werden die notwendigen Anträge ausgefüllt, Überweisungsaufträge erstellt und ausgezahlt, die physischen

4


4.2


956

Dokumente bearbeitet und an die Kreditnehmer versandt. Bei der Bearbeitung ist Einsicht in laufende Kreditunterlagen erforderlich, die als Vorlagen für Konditionsverhandlungen verwendet oder abgeändert werden. Konventionell werden solche Vorgänge sequentiell arbeitsteilig erledigt. Dabei koordinieren sich die Beteiligten durch die explizite Übergabe der Dokumente in Mappen. Abbildung 4-17 zeigt ein Kooperationsbild über diesen arbeitsteiligen Prozeß. Die bearbeiteten Vorgänge werden in einer abteilungsweiten Sammelablage von Mappen archiviert. Anhand ihrer Funktion können Mappen unterschieden werden, ❑ die während der eigentlichen Kreditvergabe verwendet wer-

den, ❑ die nach Vertragsabschluß Dokumente zu laufenden Krediten

enthalten, ❑ in denen die Dokumente abgelaufener Kredite aufbewahrt

werden.

4


4.2


957 Abb. 4-17

Abt.leiter

Kooperationsbild über die

2

Vergabe eines

Kreditvertrag

Kommunalkredits 1 Postmappe Kommune

Akquisiteur

Kontrolleur

5

3 Abschlußzettel

7

Postmappe

Postmappe

6

4 Back Office

8

Buchhaltung

Überweisung

Wir orientieren uns im Sinne des WAM-Ansatzes zunächst an den im Anwendungsbereich vorgefundenen Werkzeugen und Materialien, wobei wir die Möglichkeiten beachten müssen, die sich für die Unterstützung kooperativer Tätigkeiten bieten (s. Kapitel 4.1). In unserem Beispiel aus dem Kommunalkreditbereich wollen wir die langlebigen Materialien im System in ähnlicher Weise ablegen wie dies derzeit im

4

Anwendungsfachli cher Entwurf


4.2


958

Anwendungsbereich üblich ist. Entsprechend modellieren wir Archive zur gemeinsamen Aufbewahrung und Regale zur persönlichen Ablage. Zum Austausch von Materialien zwischen Mitarbeitern dienen Postkörbe mit einem Versandsystem. Am einzelnen Arbeitsplatz stellen wir neben dem Schreibtisch ein Regal bereit. Jeder Arbeitsplatz erhält einen Postkorb. Alle Mitarbeiter können direkt auf das Archiv zugreifen, um Dokumente zu entnehmen oder zurückzustellen. Abbildung 4-18 skizziert schematisch die Ausstattung der Arbeitsplätze mit der Möglichkeit, Dokumente abzulegen, zu beschaffen und weiterzuleiten. Abb. 4-18 Schematische Darstellung des Entwurfs

4


4.2


959

Bereits beim fachlichen Entwurf muß der Zusammenhang geklärt werden, wie Dokumente aus dem Archiv ausgeliehen und wie sie per Postkorb weitergeleitet werden. Soll beim Entleihvorgang in der Bestandsliste des Archivs ein entsprechender Vermerk gemacht werden, der das Dokument als entliehen kennzeichnet und auf den Entleiher verweist? Soll der Vermerk aktualisiert werden, wenn der Entleiher das Dokument per Post weiterleitet? Wie ist das Archiv sortiert, und wie erkennt der Anwender die Unterteilung zur Aufbewahrung der unterschiedlichen Mappenarten? Bisher haben wir den fachlichen Entwurf speziell für das Kommunalkreditbeispiel diskutiert. Sieht man das Projekt in seinem Anwendungskontext, stellen sich eine Reihe von Entwurfsfragen, die auch bei vielen derartigen Projekten beantwortet werden müssen.

Allgemeine Entwurfsfragen

Persistenzraum: Als Persistenzraum bezeichnen wir fachliche Sammlungen von Materialien oder anderen fachlichen Gegenständen, die langfristig aufbewahrt werden und auf die einfach und schnell zugegriffen werden kann.

4


4.2


960

Die in einem Projekt benötigten und vorhandenen Materialien stehen häufig im Zusammenhang mit anderen Einsatzkontexten des Anwendungsbereichs (s. Kapitel 2.5.2). Im Rahmen von Vorgängen im Bankenbereich stoßen wir z.B. auf eine Reihe von bestehenden Archiven oder gemeinsam genutzten Informationsquellen. Diese können abteilungs-, filialen- und unternehmensweit sein. Sie sind physisch oder computergestützt mittels Datenbanken realisiert. Entprechend müssen wir die folgenden Entwurfsfragen klären: ❑ Welche dieser sogenannten Persistenzräume müssen für die zu

unterstützenden Arbeitsvorgänge benutzt werden und welche müssen im Anwendungssystem zugänglich gemacht werden? ❑ Welche neuen Persistenzräume sind zur Verfügung zu stellen?

Bei der Analyse des Anwendungsbereichs müssen wir auch die benötigten Dokument- und Informationsmengen in Beziehung zu den vorhandenen unternehmensweiten Persistenzräumen setzen. Einzelne Abteilungen benötigen häufig nur bestimmte Ausschnitte. Oft ist es sinnvoll, Informationen aus unterschiedlichen Informationsquellen für Abteilungen neu zu bündeln und in eigenen Persistenzräumen zusammenzufassen.

4

Vorgehen bei der Anforderungsermittlung


4.2


961

Schon in Systemvisionen müssen wir festlegen, welche physischen Dokumente im späteren System elektronisch vorliegen und zu bearbeiten sind und welche nicht. Häufig werden wir die Umstellung schrittweise in Ausbaustufen und Zwischenorganisationsformen planen (s. S. 571ff.). Mit dem Übergang von physischen Dokumenten zu elektronischen können Informationen durch neue Persistenzräume gebündelt werden. Hierzu können Archivarten sinnvoll nach folgenden Merkmalen unterschieden werden:

Fragen beim Entwurf

❑ Dauer, für welche die Dokumente im Archiv abgelegt werden

sollen, ❑ Relevanz der abgelegten Dokumente für die Firma (private

Notizen versus juristische Daten), ❑ Kooperationsart, mit der das Archiv genutzt wird (persönliche

versus gemeinsame Archive, unterschiedliche Benutzungsarten gemeinsamer Archive), ❑ Art der Informationsnutzung (direkter Zugriff auf Doku-

mente, Navigation, Suche, Auswertung).

4


4.2


Im Kapitel 4.1 haben wir bereits unterschiedliche Kooperationsformen diskutiert. Wir fassen an dieser Stelle kurz zusammen:

962 Kooperationsformen

❑ Ein Material ist im Persistenzraum bearbeitbar. Hier müssen

geeignete Konfliktstrategien bei gleichzeitigem Bearbeitungswunsch bereitgestellt werden. ❑ Ein Material ist am privaten Arbeitsplatz bearbeitbar, an den

es verschoben werden muß. Für andere Anwender ist ein entferntes Material nicht nutzbar. Material sollte aber lokalisierbar sein, z.B. durch einen Vermerk im Archiv. Eine Folge dieses Entwurfs ist, daß beim Versenden des Materials per Postkorb diese Notiz im Archiv verändert werden muß. Beim Zurückstellen des Dokumentes ist zu entscheiden, ob das alte Dokument durch das neue ersetzt oder eine neue Version angelegt wird. ❑ Materialien können aus einem Archiv als Original und Kopie

entliehen werden.

4


4.2


963

4.2.3 Technische Umsetzung des Archivkonzepts Im folgenden skizzieren wir, wie die fachlichen Anforderungen an den Umgang mit langlebigen Materialien und an ihre Ablage in Archiven auf der Basis unterschiedlicher Kooperationsformen umgesetzt werden können. Da wir in diesem Bereich nur erste Projekterfahrungen gesammelt haben, können wir keine abschließenden Lösungen vorstellen. Wir zeigen eher Entwurfs- und Realisierungsmöglichkeiten auf. 14 Die Client/Server-Technologie dient uns als Grundlage für die Realisierung. Sie führt zu einer technischen Konkretisierung der fachlichen WAM-Architektur. Die Entwurfsfragen dabei sind:

Entwurfsfragen bei der Client/Server-Technologie

❑ Wieviele und welche Server sind für welche Aufgaben vorzuse-

hen; auf welchen Rechnern sollen sie angesiedelt sein; wie ist der »Schnitt« zwischen Client- und Serverprozeß? ❑ Wie teilen sich Clients und Server die Aufgaben der Persistenz

und der Kooperationsunterstützung; wer kennt welche Datenquellen und Speichermedien; wer informiert wen über Materialveränderungen, und wo steckt das Wissen über die Transformation von Materialien in externe Formate?

14. Um eine Verwechslung mit dem in Kapitel 2.1.4 eingeführten KlientenAnbieter Modell auf Objektebene zu vermeiden, sprechen wir im weiteren von Client und Server, wenn wir uns auf die entsprechenden Konzepte des technischen Client/Server-Modells beziehen. 4


4.2


964

❑ Wie kommunizieren Clients und Server; welche Middleware

wird benutzt; wie werden Materialien transportiert? ❑ Wie werden Datenbanken angeschlossen; welche Datenfor-

mate werden realisiert; wie werden Navigation und Anfragen umgesetzt? Zunächst ist zu klären, wo die Prozeßgrenze zwischen Client und Server anzusiedeln ist. Diese Aufteilung kann sich je nach Einsatzkontext anders ergeben. So haben wir in einem Projekt die Grenze zwischen Werkzeugen und Materialien gelegt (s. Kapitel 4.3.4). Wir skizzieren hier eine bewährte andere Lösungsidee, bei der der Prozeßschnitt grundsätzlich zwischen Arbeitsplatz und Archiv liegt. Damit haben wir uns für »fette« Anwendungsserver mit Archiven entschieden. Die Clients werden als Arbeitsplatzrechner realisiert, mit einer geeigneten Arbeitsplatzumgebung, bestehend aus Schreibtisch, lokalem Archiv, Postkorb und Werkzeugen. Sie greifen auf ein gemeinsames Archiv zu. Server koordinieren die Clients und realisieren die Archive. Innerhalb dieser prinzipiellen Aufteilung schlagen wir drei Architekturen mit unterschiedlichen Schwerpunkten vor. Diese Schwerpunkte »sacken« kontinuierlich nach »unten«, d.h., wir betrachten die Realisierung der anwendungsfachlichen Anforderungen bis zu den technischen Problemen der Datenbankanbindung und Transformation von Formaten:

4

Architekturen für die Persistenz


4.2


965

❑ Es wird eine Architektur für fachliche Archive und Postkörbe

mit Schwerpunkt auf der Client-Konfiguration vorgestellt. Wir unterteilen in Konzepte für die Kooperation und die Persistenz. ❑ Unterschiedliche Persistenzräume (d.h. Datenbanken und

Datenquellen) werden einbezogen, und der Wechsel zwischen Test- und Produktionsumgebungen für langlebige Materialien wird betrachtet. In diesem Kontext verweisen wir auf das Serialisierermuster (s. Kapitel 3.3.4). ❑ Wir beschreiben die konkrete Speicherung von Objekten in

nicht-objektorientierten Datenbanken unter Angabe von Transformationsregeln. Eine anwendungsfachliche Realisierung von Archiven und Postkörben

Die nachfolgend beschriebene Architektur ist im Rahmen des Projekts KOALA zur Kommunalkreditberatung bei der SüdwestLB Stuttgart entstanden (s. [Wetzel et al. 97]). Abbildung 4-19 zeigt die Komponenten von Client und Server. Die Kommunikation zwischen Client und Server läuft über eine Middleware, die Proxies (s. S. 303ff.) bereitstellt und entfernte Operations-

4


4.2


966

aufrufe ermöglicht. Die Middleware ist über ein Brückenmuster (s. [Gamma et al. 96]) angeschlossen. Wir beschreiben im folgenden die wesentlichen Komponenten für die Realisierung einer kooperativen Materialbenutzung und unterteilen dabei in Persistenz- und Kooperationsebene.

Postkorb

Wkz

Archiv

Server Rechte anmelden

Client anmelden

Persistenz

Materialmanager ServerStub

Object-ManagerClient

ClientObject

?

Rechtemanager

Materialkoordinator

Clientmanager

PostArchivTerminmanager manager manager ClientStub

Object-ManagerServer

ServerObject

Koordination

Wkz

Materialbenutzung

Persistenz

IAK FK IAK FK

Middleware

Koordination

Client IAK FK IAK FK

Komponenten der

Abb. 4-19 Beispiel für eine Client/Server-Architektur

4


4.2


967

Werkzeug (Wkz) ❑ Persistenz: Das Werkzeug-Objekt (s. S. 289ff.) kapselt die Auf-

rufe von globalen Objekten, wie dem Materialmanager, der als Singleton (s. [Gamma et al. 96]) realisiert ist. Weitere globale Objekte sind z.B. ein Werkzeugmanager und ein Iconmanager. Das Werkzeug reicht Operationsaufrufe zum Speichern von Materialien an den Materialmanager weiter und stellt diese Funktionalität für die FK (s. Kapitel 3.2.2) zur Verfügung. ❑ Kooperation: Ähnlich wie die Persistenzdienstleistungen stellt

das Werkzeug Operationen des Materialmanagers für die Kooperation bereit. ❑ Weitere Dienste: Das Werkzeug verwaltet den aktuellen Kon-

text, in dem FK und IAK eingesetzt werden, und bietet ein konfigurierbares Muster für die Erzeugung von FK und IAK an. Funktionskomponente (FK) ❑ Persistenz: Die FK ruft über das Werkzeug die entsprechenden

von der Materialverwendung bereitgestellten Operationen auf. ❑ Kooperation: wie oben.

4


4.2


968

Materialmanager ❑ Persistenz: Der Materialmanager kapselt die durch den Object-

Manager-Client bereitgestellten Persistenzdienstleistungen für die angemeldeten Materialklassen. Hierzu hält er ein Register dieser Klassen mit jeweils drei Operationen. Diese Operationen sind einheitlich benannt (materialAnlegen, materialAendern, materialLoeschen) und erhalten als Parameter das Materialobjekt. Diese Operationen sind beim Materialmanager und nicht an den bankfachlichen Objekten implementiert. ❑ Kooperation:

– Kooperation mit der Außenwelt: Durch den Aufruf des Object-Manager-Clients, der wiederum Operationen des Object-Manager-Servers aufruft, wird der Materialkoordinator über die Veränderung von Objekten in einem Client benachrichtigt. Umgekehrt benachrichtigt der Materialkoordinator die Clients über Veränderungen an Objekten, die in Form von Arbeitskopien innerhalb eines Client vorhanden sind. Diese Nachrichten leitet der Materialmanager an die entsprechenden Stellen im Client weiter, z.B. an Werkzeuge, die Arbeitskopien benutzen. Dazu verwendet der Materialmanager eine Liste der gerade im Client be-

4


4.2


969

nutzten Materialien. Je nach Kooperationsart und Benutzungsmodell können die einzelnen Werkzeuge bei der Anzeige oder beim Zugriff auf diese Kopien unterschiedlich reagieren. – Kooperation innerhalb eines Client: Der Materialmanager koordiniert die Materialien, die in unterschiedlichen Werkzeugen in einem Client gleichzeitig benutzt werden (s. S. 302ff.). Wie oben können Werkzeuge auf Nachrichten zur Materialsynchronisierung je nach Konzept unterschiedlich reagieren. Object-Manager-Client ❑ Persistenz: Der Objekt-Manager-Client stellt nach außen Ope-

rationen zum Speichern und Lesen von Materialien zur Verfügung. Intern werden diese durch Operationsaufrufe des Object-Manager-Server-Stub implementiert, der Transaktionsund Rollbackkonzepte zur Verfügung stellt. Objekte werden hier serialisiert. ❑ Kooperation: –

4


4.2


970

Object-Manager-Server ❑ Persistenz: Im Projekt wurde bisher nur ein Materialableger

realisiert, dessen Operationen mit dem serialisierten Objekt als Parameter aufgerufen werden. Der Materialableger transformiert das Material und legt es in einem Persistenzmedium ab. Sollen unterschiedliche Persistenzmedien (z.B. verschiedene Datenbanken) verwendet werden, dann muß der ObjectManager-Server eine Liste der verschiedenen Materialableger besitzen. Entweder entscheidet er in diesem Fall selbst, welche Materialien in welchen Materialablegern gespeichert werden, oder die Materialableger können hierüber Auskunft geben. Nach dem Geheimnisprinzip soll das Wissen über die Materialverteilung nur auf dem Server bekannt sein und im ObjectManager-Server entsprechend gekapselt werden. ❑ Kooperation: Der Object-Manager-Server liefert nach außen

Operationen zum Abspeichern, die von verschiedenen Clients aufgerufen werden. Er realisiert ein elementares Kooperationskonzept – wer zuerst kommt, mahlt zuerst (first come, first serve). Alle höheren, fachlichen Kooperationsmodelle werden durch das Zusammenspiel mit dem Materialkoordinator realisiert.

4


4.2


971

Materialkoordinator ❑ Persistenz: – ❑ Kooperation: Der Materialkoordinator stellt Operationen für

die fachliche Kooperation bereit, die z.T. auf Anwendungswissen beruhen. Dies ist die Basis für den Zugriff der Clients auf gemeinsame Archive oder auf Postkörbe. Der Materialkoordinator regelt die Benutzung von Materialien auf verschiedenen Clients und unterscheidet dabei Originale und Arbeitskopien. Er wird durch den ObjectManager-Server über Änderungen informiert und benachrichtigt je nach Kooperationskonzept die aktiven Clients. Benutzung unterschiedlicher Persistenzräume

Das folgende Beispiel beschreibt die Realisierung von Persistenzräumen im Projekt KMU-Desktop bei der UBS Zürich. Die fachliche Modellierung mit Postkörben und Archiven ist vergleichbar mit dem vorangegangenen Abschnitt »Eine anwendungsfachliche Realisierung von Archiven und Postkörben« (s. S. 475ff.). Hier betrachten wir aber auch unterschiedliche Persistenzkontexte und Datenquellen oder Persistenzmedien (s.u.). Dadurch muß die

4


4.2


972

Architektur erweitert werden. Da sich die Kooperationsaspekte, die jeweils das fachliche Benutzungsmodell bestimmen, mit dem vorigen Beispiel vergleichen lassen, werden sie hier vernachlässigt. Wir erläutern die unterschiedlichen Konzepte, die wir in diesem Zusammenhang gebrauchen: ❑ Persistenzraum ist der Oberbegriff für eine fachliche (dauer-

hafte) Ablagemöglichkeit von Materialien (vgl. S. 472). Ein Persistenzraum kann ein Archiv, ein Regal als lokale Ablage oder ein Postkorb sein. Die Materialien in Persistenzräumen können homogen oder heterogen sein. Es gibt Persistenzräume für spezifische Materialien. Persistenzräume können bei der kooperativen Arbeit unterschiedliche Benutzungsmodelle besitzen. Technisch gesehen ist ein Persistenzraum eine Abstraktion über eine oder mehrere Datenquellen oder Persistenzmedien, sofern er Daten aus diesen Datenquellen zu fachlich motivierten Materialien zusammensetzt und innerhalb des Persistenzraums gemeinsam anbietet.

Unterschiedliche Persistenzräume: Konzepte und Begriffe

❑ Behälter betrachten wir hier als fachliche Abstraktion über

eine Teilmenge von Persistenzräumen wie Ablagen und Archive. Generell haben wir das Behälterkonzept unabhängig von Persistenz eingeführt (s. Kapitel 3.1.5 und 3.2.7).

4


4.2


973

❑ Persistenzmedium ist ein Oberbegriff für Systeme, in denen

Materialien persistent abgelegt werden können. Dies sind meist Datenbankmanagementsysteme, die sich in angebotenen Datenmodellen und Dienstleistungen unterscheiden können, und Dateisysteme. ❑ Datenquelle ist ein Oberbegriff für konkrete Quellen anwen-

dungsfachlicher Daten, die in einer Anwendung als Materialien in Persistenzräumen zur Verfügung gestellt werden sollen. Unterschiedliche Datenquellen können durch gleiche oder verschiedene Persistenzmedien realisert sein. ❑ Persistenzkontext ist ein Oberbegriff für die unterschiedlichen

Möglichkeiten, die Persistenzräume einer Anwendung zu realisieren. Im Projekt mußte der Test- und Demonstrationsbetrieb von Prototypen anders umgesetzt werden als der operative Betrieb. ❑ Persistenzanbieter ist ein Oberbegriff für Komponenten, die in

einer Arbeitsplatzumgebung im Anwendungssystem Persistenzdienstleistungen anbieten. Eine abstrakte Persistenzanbieterklasse bietet alle notwendigen Persistenzoperationen an. Je nach Persistenzkontext müssen unterschiedliche konkrete Persistenzanbieter in einer Umgebung von dieser abstrakten Klasse abgeleitet werden.

4


4.2


974

❑ Materialablage bezeichnet alle Komponenten, die direkt oder

indirekt an Datenquellen oder Persistenzmedien angeschlossen sind. Die in der Materialablage gekapselte »Außenwelt« kann auf dem Client das Dateisystem oder die Middleware zur Übertragung an den Anwendungsserver sein und auf dem Server die benutzten Datenquellen oder Persistenzmedien. Überlegungen zur Realsierung von Persistenzräumen Es gibt unterschiedliche Konzepte zur Implementierung von Persistenzräumen. Mögliche Lösungen unterscheiden sich je nach Art der Persistenzmedien (relationale DB, OODB, Dateisystem) und der ver* ® fügbaren Zugriffsmöglichkeiten (z.B. SQL Net , Service-Architektur, ORB usw.). Einige typische Arten der Anbindung von Persistenzmedien sind: ❑ Integration einer objektorientierten Datenbank: einfachste

Mögiche Anbindung von Persistenzmedien

Integration, da kein Paradigmenwechsel stattfindet. ❑ Anbindung einer relationalen Datenbank über direkten Daten-

bank-Zugriff vom Client aus mittels SQL*Net® und ODBC. Hierbei müssen die Objekte (Materialien) auf Tabellenrelationen im Client abgebildet werden.

4


4.2


975

❑ Arbeit mit beliebigen Persistenzmedien über einen ORB: Der

Client kommuniziert über einen ORB (CORBA) mit den Persistenzmedien. Objekte sind im Prinzip verteilt. Die Materialien müssen zwar auf externe Formate abgebildet werden; dies ist aber nicht Aufgabe der Client-Anwendung. ❑ Arbeit mit beliebigen Persistenzmedien über eine Client/Server-

Architektur: ähnlich wie die ORB-Lösung, jedoch sind hier die Objekte nicht in jedem Fall verteilt. Die Aufteilung in Client und Server entspricht häufig dem vorausgegangenen Beispiel. Die Architektur wird im wesentlichen zu Transportzwecken verwendet. Projekte müssen sich häufig auf die gegebenen Randbedingungen einstellen. Dies sind meist:

Randbedingungen im Projekt

❑ bestehende einzubindende Datenquellen, ❑ generelle Entscheidungen über die zu verwendenden Persi-

stenzmedien, ❑ eine firmeninterne Strategie bezüglich der Middleware (und

der Entwicklungsumgebungen).

4


4.2


Im Projekt KMU-Desktop waren folgende Vorgaben zu berücksichtigen:

976 Projektvorgaben

❑ Objektorientierte Datenbanken waren nicht erlaubt. ❑ Die intern vorhandene Middleware (eine eigene CORBA-

Implementierung) ist für die Kommunikation zu verwenden. ❑ Alle operativen Daten sind in das vorhandene Host-Daten-

banksystem einzuspielen. ❑ Möglichst schlanke Clients sind anzustreben. Kein Client sollte

wissen, welche Datenbanken bzw. Persistenzmedien für welche Materialien zuständig sind. ❑ Zur Realisierung verschiedener Persistenzkontexte mußte ein

Persistenzsimulator konstruiert werden, der für Test- und Demonstrationszwecke eingeschaltet werden kann. Daraus ergab sich im Projekt KMU-Desktop die im folgenden beschriebene Architektur. Persistenzräume In der KMU-Desktop Anwendung arbeiten die Benutzer mit vier Persistenzräumen: den Kundenakten, der persönlichen Arbeitsablage, dem persönlichen und dem gemeinsamen Postkorb. Ferner können sie noch Daten aus dem Hostsystem (ABACUS) beziehen.

4


4.2


Innerhalb einer Arbeitsumgebung verwenden wir Werkzeuge, die den Umgang mit Persistenzräume ermöglichen, indem sie z.B. den Inhalt des Persistenzraums visualisieren und auf Materialien des Persistenzraums arbeiten. Generell sind Persistenzräume aus der Sicht der Anwendung als Behälter realisiert, die sich nach dem saveless-Modell verhalten, d.h. Änderungen am Behälter sind nicht flüchtig, sondern ohne zusätzliche Aktivitäten immer langlebig. In KMU-Desktop werden Behälter ähnlich dem Explorer unter Windows 95 angezeigt. Zur Realisierung der Persistenzräume werden verschiedene Datenquellen und Persistenzmedien benutzt:

977

Verwendete Datenquellen und Persistenzräume

❑ Eine neu eingerichtete ORACLE-Datenbank dient zur Mate-

rialablage der KMU-Desktop-Anwendung. Ziel der Realisierung war, die notwendige Abbildung zwischen dem objektorientierten und dem relationalen Konzept mit Hilfe von eindeutigen Objektbezeichnern (OID) zu optimieren und das Navigieren entlang von Objekten zu unterstützen. Dafür wird in Kauf genommen, daß Auswertungen etwas teurer werden. ❑ Eine weitere ORACLE-Datenbank, EBO (Erweiterte Bonitäts-

analyse) genannt, steht als Auswertungsdatenbank mit replizierten Daten aus der Materialablage zur Verfügung. Die Daten sind hier in relationaler Form (3. Normalform) abgelegt

4


4.2


978

und für Auswertungen optimiert. Die Erfahrungen haben gezeigt, daß das Datenmodell eines RDBMS sehr stark davon abhängt, ob die Daten eher für die Ablage oder für komplexe Auswertungen benötigt werden. Um beides innerhalb der Anwendung zu optimieren, wurde für Auswertungen sowie den lesenden Zugriff anderer Geschäftsbereiche die zusätzliche Auswertungsdatenbank EBO eingerichtet, auf die nur mit (CORBA-) Services zugegriffen werden kann. ❑ Die Anwendung muß darüber hinaus operationale Daten im

UBS-Hostsystem ABACUS speichern und von dort beziehen. Diese Daten enthalten oft Codes oder Abkürzungen, welche beim lesenden Zugriff über eine Referenzdatenbank aufgelöst werden. Server-Konzept Im Prinzip erlaubt die skizzierte Architektur, mehrere Anwendungsserver zu benutzen. In KMU-Desktop wurde beschlossen, nur einen Anwendungsserver einzusetzen, der aus praktischen Gründen auf dem vorhandenen unternehmensweiten Server läuft. Folgende Entwurfsentscheidungen wurden getroffen:

4


4.2


❑ Der Anwendungsserver nimmt außer den serialisierten Mate-

rialien auch einen Speicherwunsch des Clients entgegen und wählt die entsprechenden Materialablagen aus. Dabei kann ein Material auf verschiedene Persistenzmedien verteilt sein. Ein Beispiel ist das sogenannte Abwickeln, bei dem eine Geschäftsfallmappe nach Erledigung eines Vorgangs aufgelöst und verteilt wird. Umgekehrt stellt der Server auf Anforderung der Clients Materialien aus der Materialablage bereit. Im Anwendungsserver ist festgelegt, bei welchem Speichervorgang Materialien zu replizieren und zusätzlich in das Subsystem EBO einzufügen sind, oder in welcher Form das Hostsystem ABACUS aktualisiert werden muß. Der Anwendungsserver stellt also eine Art Materialverteiler dar. Damit enthält er ein beträchtliches Maß an anwendungsfachlichem Wissen.

979 Entwurfsentscheidungen für den Anwendungsserver

❑ Der Anwendungsserver verteilt die Materialien auf verschie-

dene Materialablagen. Diese kapseln in KMU-Desktop z.B. die ORACLE-Datenbanken, das Hostsystem ABACUS und einen Referenzdaten-Provider. In den Materialablagen werden die Materialien beim Einfügen und Herauslesen entsprechend transformiert.

4


4.2


980

Der Persistenzsimulator Bei Projekten, die ihre langfristigen Materialien nicht nur einfach lokal in Dateien ablegen, sondern in Datenbanken oder Hostsystemen speichern, sollte bereits bei Projektbeginn ein Subprojekt für Persistenzsimulatoren eingeplant werden. Ziel ist, die unterschiedlichen Persistenzkontexte neben ihrer tatsächlichen Realisierung auch simulieren zu können. Ein Persistenzsimulator muß dasselbe Verhalten wie der »echte« Persistenzraum zeigen. Wir müssen Materialablagen z.B. mit denselben Schnittstellen ausstatten, wie die »echten« Ablagesubsysteme der unterschiedlichen Persistenzmedien. Wir konstruieren einen Simulator mit Hilfe eines speziellen Persistenzanbieters. Dieser wird meist das vorhandene Dateisystem als Persistenzmedium benutzen. Daher ist das Speichern und Laden einfach und relativ rasch implementiert. Die Persistenzanbieter können auch sehr komplex werden, wenn wir nach Materialien suchen, Referenzdaten auflösen, oder gar komplexe HostTransaktionen simulieren möchten. Hier ist im Einzelfall zu entscheiden, was für die Simulationszwecke wirklich benötigt wird. Simulatoren haben einige Vorteile:

Vorteile von Simulatoren

❑ Test und Weiterentwicklung: Da der Simulator unabhängig ist,

können wir effizient testen und rasch weiterentwickeln. Neue

4


4.2


981

Anforderungen oder Änderungen können im Simulator viel schneller eingebaut werden als bei vorhandenen Persistenzmedien, deren Zugriff meist sehr beschränkt ist. ❑ Systemdemonstrationen: Ein nicht zu unterschätzender Vorteil

von Simulatoren besteht darin, daß die Anwendung »stand alone«, also losgelöst vom Netzwerk, vorgeführt werden kann. So lassen sich Prototypen bei Anwendern vor Ort ohne zusätzlichen Installationsaufwand demonstrieren. ❑ Ausbau zum Persistenzraum »Handgepäck«: Wenn die Simu-

latoren mit genügend Sorgfalt entwickelt werden, können sie sogar zur Produktionsreife gelangen. Sie sind die Grundlage eines eigenen Persistenzraums, nämlich des »Handgepäcks« (s. Kapitel 4.1.5) oder eines »Aktenkoffers« für die LaptopVariante der Anwendung. Zwischen den unterschiedlichen Persistenzkontexten des Echtbetriebs und der Test- und Demonstrationsumgebung wollen wir einfach wechseln können. Hierzu wurde in KMU-Desktop ein Schalter installiert, der von der Benutzungsoberfläche bedient werden kann. Die Stellung des Schalters wird bei der Umgebung registriert. Verlangt eine Komponente von der Umgebung einen Persistenzanbieter, so gibt die Umgebung entweder den eigentlichen Anbieter der Persistenz zurück oder den des Simulators. 4

Schalter für Persistenzkontexte


4.2


982

Um beide Persistenzkontexte einheitlich verwenden zu können, ist eine allgemeine Persistenzanbieterklasse definiert, von der konkrete Anbieter erben. Diese abstrakte Klasse definiert die allgemeinen Operationen. Die KMU-Desktop-Architektur ist als NT-Clients mit einem Anwendungsserver (Application Server in Abbildung 4-20) ausgelegt.

4

Kommunikation zwischen Client und Server


4.2

Client


Client

Wz-Frameworks

Frameworks

OLE-Framework

983 WinWord WinWord

Frameworks Excel Excel

PersistenzMaterial-Framework Framework Werte-Framework

Clients: NT 4.0 mit VisualAge for Smalltalk, ISI/ST und Dritt-Produkten

42,‘ Abc’, £

Lokale Persistenz

WOP-Protokoll

Transaktionssystem

Services ATI

Application Server

WOP-AS

SqlNet

Referenzdaten Referenzdaten ISI

WOP-Protokoll

bankfachl. Services Services

Materialablage

ISI

EBO

Autorisierungssystem Autorisierungssystem

WOP-Ablage

Abb. 4-20 Architektur des KMU-Desktop-Systems

4


4.2


984

Der Client kommuniziert über ein eigenes dynamisches Protokoll (WAM-Object-Provider-Protokoll, in Abbildung 4-20 WOP-Protokoll genannt) mit dem Server. Es gibt genau einen Service-Aufruf, bei dem jeweils die Beschreibung des Materials als Metainformation mitgegeben wird. Dies erlaubt, die Materialien weiterzuentwickeln oder neu zu definieren, ohne die Service-Schnittstelle ändern zu müssen. Alle Materialien werden serialisiert (s. Kapitel 3.3.4) und mit einer hauseigenen CORBA-Implementierung zwischen Clients und dem dedizierten Anwendungsserver transportiert. Der Speichervorgang Wir beschreiben jetzt am Beispiel eines Materials, das in einen Persistenzraum eingefügt wird, wie Client und Server kommunizieren. Wir beginnen auf der Client-Seite und gehen dann zum Server über (s. Abbildung 4-21)

4


4.2


Persistenzraum B

Materialablage

Anwendungsserver

?

Wkz Persistenzanbieter 1

Technisch

Server Persistenzraum C

Persistenzanbieter 2

Materialablage

Middleware

Fachlich

Client Persistenzraum A

985

Verwaltungsobjekte

Materialablage

Materialablage

Materialablage

Abb. 4-21 Komponenten zur

Ein Material wird mehrstufig gemäß der Hierarchie der verwendeten Komponenten gespeichert. Ist der Persistenzraum in der Anwendung gewählt, wird zur Laufzeit auf der Basis der entsprechenden Laufzeitinformation über den aktuellen Persistenzkontext der Anwendungsserver gerufen. Der bestimmt anhand des gewünschten Persistenzraums die entsprechende Materialablage und damit die richtige Datenquelle und initiiert die Speicherung. Im einzelnen sieht dies so aus:

4

Realisierung mehrerer Persistenzräume

Client-Seite


4.2


986

❑ Soll ein Material gespeichert werden, so wählt der Benutzer

einen Persistenzraum aus (Anzeige ähnlich dem Speichern-Dialog unter Windows 95). Alle Persistenzräume sind in jedem Persistenzkontext vorhanden, denn Persistenzräume sind fachlich begründet und sollten somit unabhängig vom Persistenzkontext sein. In KMU-Desktop sind diese Persistenzräume derzeit im Persistenzsimulator nur mit einem Ausschnitt der Daten realisiert. Die Persistenzkontexte verwenden natürlich unterschiedliche Persistenzmedien zur Realisierung der Persistenzräume. ❑ Die Funktionskomponente des Werkzeugs, das den Speichern-

Dialog anbietet, fragt zur Laufzeit bei der Umgebung nach dem Persistenzkontext und der zugehörigen Persistenzanbieterklasse. In Abbildung 4-20 ist dies durch Schalter im Client dargestellt, der zwischen dem lokalen Persistenzraum und dem Anwendungsserver wechselt. Die FK erzeugt danach ein Exemplar des Persistenzanbieters und ruft an diesem Objekt die Speichern-Operation auf. Dieses Persistenzanbieterexemplar (z.B. CalWopAblageDevice oder CalWopAblageDeviceSimulator genannt) können wir als »normales« High-Level-Device (z.B. als Klasse ASCIIFileIO) betrachten. Da das Speichern

4


4.2


987

fachlich gesehen parallel aufgerufen werden kann, sind die Persistenzanbieter nicht als Singleton implementiert. Beim Aufruf werden Material und Persistenzraum als Parameter mitgegeben. Das konkrete Persistenzanbieterobjekt serialisiert das Material mit einem zur Zeit statisch zugeordneten Serialisierer. Dabei wird das Material in das Format des zeichenkettenbasierten WOP-Protokolls konvertiert. Mit dem serialisierten Material ruft der Persistenzanbieter die zugehörige Materialablage auf. ❑ Ist der Persistenzkontext Simulation gewählt, dann schreibt die

Materialablage als eine Smalltalk-Klasse das Material in eine Datei. In diesem Fall enthält der Persistenzanbieter fachliches Wissen, das sonst in dem Anwendungsserver enthalten ist. ❑ Ist der »echte« Persistenzkontext gewählt, ruft die Materialab-

lage die Middleware zur Datenübertragung zum Anwendungsserver. Im Projekt KMU-Desktop kommt das eigene dynamische WOP-Protokoll über der bestehenden CORBA-Implementierung fast ohne IDLÄnderungen aus. Darin ist ein einziges CORBA-Objekt (DTKMU) mit einem Operationsaufruf (DTKMU_WOP_impl_do()) definiert. Diese

4

Server-Seite


4.2


988

Operation erhält als Parameter die eigentliche Kommandoinformation (Klassenname, Operationsname...), eine In-Parameter-Liste, eine Out-Parameter-Liste und die Kontextinformation. Alle (logischen) Persistenz-Dienstleistungen werden erst auf dem Client aufgrund dieses einen (physischen) Aufrufs initiiert. ❑ Nach dem Aufruf des Servers wird dem globalen ORB-Objekt

die Kontextinformation des Aufrufs (z.B. Sprache des Clients) übergeben. Aus der Kommandoinformation wird ein Kommandoobjekt erzeugt, das Informationen über die Art des Aufrufs enthält. Die In-Parameter-Liste wird in eine Liste von Objekten umgewandelt. ❑ Über eine abstrakte Fabrik (s. [Gamma et al. 96]) wird nun je

Kommandoobjekt ein Verwaltungsobjekt erzeugt und dynamisch im Server registriert. Diese Verwaltungsobjekte repräsentieren und verwalten in einer Eins-zu-eins-Beziehung die Materialobjekte der Clients. Verwaltungsobjekte werden statt der eigentlichen Materialien verwendet, da selten die volle Funktionalität eines Materialobjektes auf der Server-Seite verwendet wird. Statt dessen müssen aber Informationen über die verschiedenen Materialablagen verwaltet werden, in die ein komplexes Material potentiell aufgeteilt wird. Dazu kommen die dann notwendigen Replikationsoperationen.

4


4.2


989

❑ Je nach Kommandoobjekt, wird am Verwaltungsobjekt eine

entsprechende Operation mit der zuvor erzeugten Liste und einer leeren Out-Parameter-Liste aufgerufen. Diese Operation kann auch dynamisch registriert werden. Die Operation implementiert die Art und Weise, wie das Material gespeichert werden muß. In den meisten Fällen wird ein dynamisches SQL-Kommando erzeugt und an die jeweilige Datenbank geschickt. In der Operation ist auch definiert, ob neben dem Abspeichern weitere konsistenzerhaltende Maßnahmen getroffen werden müssen, z.B. ob die Auswertungsdatenbank EBO oder der operative Bestand im ABACUS-System nachgeführt werden muß. In diesen zusätzlichen Operationen ist teils komplexes bankfachliches Wissen enthalten. ❑ Zum Schluß wird die Out-Parameter-Liste wieder (gemäß

IDL-Definition) serialisiert und an den zuständigen Client geschickt. Anbindung relationaler Datenbanken

In diesem Abschnitt stellen wir die konkrete Speicherung von Objekten in relationale Datenbanken mit Hilfe der notwendigen Abbil-

4


4.2


dungsvorschriften vor. Die hier beschriebenen Ausprägungen wurden im Rahmen des GEBOS-Projekts in der RWG erarbeitet und umgesetzt. Wir klammern bewußt Konzepte für den Mehrbenutzerbetrieb aus. Die Abbildung von Objekten auf Tupel in einem Relationenschema erfordert folgende Festlegungen:

990

Festlegungen für die Abbildung

❑ Transformationsregeln für die Einrichtung der Datenbank:

Welches Datenbankschema wird aus den Klassen der Anwendungsprogramme unter Berücksichtigung von Objektreferenzen, Klassenhierarchien und Polymorphie definiert oder generiert? ❑ Lade- und Speichervorgang zur Laufzeit: Welche Algorithmen

werden für Speicher- und Ladevorgänge in Abhängigkeit der Objektkomplexität mit welchen Hilfsstrukturen benutzt? Hierbei müssen Objekte den Tupeln der Datenbank zugeordnet und dann wieder identifiziert werden. Ferner fassen wir die resultierenden Aufgaben des Materialablegers zusammen und beschreiben, wie er mit dem Object-Manager-Server zusammenspielt.

4


4.2


Grundprinzip der GEBOS-Transformationsregeln ist, daß für jede Klasse mit persistenten Objekten eine Datenbankrelation im Datenbankschema eingerichtet wird. Die Daten eines persistenten Objekts werden als Tupel der entsprechenden Relation abgelegt und aus ihr geladen. Bei der Darstellung der Abbildung beginnen wir mit einfachen Klassen, d.h. Klassen, deren Attribute nur elementare, von der Programmiersprache bereitgestellte Standardtypen besitzen. Wir gehen dann über zu Klassen komplexer Objekte, deren Attribute Referenzen auf andere Objekte besitzen. Als weiteres Thema wird die Abbildung von Klassen in Vererbungshierarchien behandelt. Dann machen wir Vorschläge für optimierte Lade- und Speichervorgänge, diese betreffen insbesondere die Abbildung von Klassen, deren Attribute mengenwertige Strukturen (z.B. Behälter) aufweisen. Jede Abbildung ist durch die Klassenstruktur und die zugehörige Relation beschrieben. Grundsätzlich ist für die Identifikation von Objekten der Aufbau von Hilfsstrukturen im Materialableger notwendig. Wir beschreiben dies beim Laden und Speichern von Objekten.

991 Abbildungsregeln

1. Einfache Klassen Einfache Klassen bestehen – neben ihren Operationen – nur aus Attributen elementarer Typen.

4


4.2


992

Für jede Klasse wird eine Relation im Datenbankschema definiert. Sie enthält für jedes zu speichernde Exemplarattribut (hier kann eine Auswahl getroffen werden) ein Datenbankattribut. Der elementare Datentyp des Exemplarattributs wird auf einen entsprechenden Datentyp des relationalen Datenbanksystems abgebildet. Zusätzlich wird in jeder Relation ein Attribut zur Identifizierung des gespeicherten Objektes, d.h. des Tupels, angelegt. Im GEBOS-Projekt wird das Relationenschema generiert. Konventionen für die Namensgebung sind wie folgt: Die Attributnamen einer Relation setzen sich aus einem Kürzel für den Typ des Datenbankattributs und der laufenden Nummer (Position) des Exemplarattributs der Klasse zusammen. Der Relationsname wird dabei nicht automatisch vergeben.

Transformationsregel

Im Materialableger wird in zwei Hilfstabellen statisches und dynamisches Transformationswissen verwaltet. Auf diese Hilfstabellen wird während der Speicher- und Ladevorgänge zugegriffen und deren Inhalt gegebenenfalls verändert. Eine Relationszuordnungstabelle verwaltet statisches Transformationswissen über die Zuordnung von Klassen- und zugehörigen Relationsnamen. Sie wird bei Programmstart in den Hauptspeicher gelesen.

Speicher- und Ladevorgang

4

Allgemeine Hilfsstrukturen


4.2


993

Das dynamische Transformationswissen steht in einer weiteren Tabelle, der Identifikatorzuordnungstabelle. Sie ordnet Objektidentifikatoren (das sind Objektreferenzen oder Hauptspeicheradressen) und Datenbankidentifikatoren (Werte des in jeder Tabelle vorhandenen Identifikatorattributs) zu. Diese Tabelle wird pro Programmausführung gefüllt und ist somit nur lokal innerhalb einer Sitzung verwendbar. Denn die Objektidentifikatoren werden je Programmstart völlig neu vergeben. Dies führt zu dem grundsätzlichen Problem, wie sich Objekte aus dem Programm heraus in der Datenbank beim Laden identifizieren lassen. Denn dem Programm sind die Datenbankidentifikatoren der Datenbanktupel nicht bekannt. Wir beschreiben die Lösung schrittweise. In diesem Abschnitt über einfache Klassen behandeln wir nur das Laden oder Verändern eines innerhalb einer Sitzung erzeugten Objektes. Der Materialableger erhält beim Speicheraufruf einen Zeiger auf das zu speichernde Objekt und damit die Werte der Attribute, die persistent zu machen sind, sowie den zugehörigen Klassennamen. Über die Relationszuordnungstabelle wird der Name der entsprechenden Relation ermittelt. Dann sind folgende zwei Fälle möglich:

4

Speichervorgang


4.2


994

❑ Soll ein zur Laufzeit erzeugtes Objekt zum erstenmal gespei-

chert werden, so wird in der zugehörigen Tabelle ein neues Tupel mit den transformierten Werten der Attribute und einem neu erzeugten Datenbankidentifikator abgelegt. In der Identifikatorzuordnungstabelle wird die Hauptspeicheradresse des Objektes und der erzeugte Datenbankidentifikator eingetragen. ❑ Soll ein Objekt mit geänderten Werten erneut gespeichert wer-

den, so ist dies an einem entsprechenden Eintrag in der Identifikatorzuordnungstabelle zu erkennen. Dann werden nur die Attribute gespeichert. Kein neuer Identifikator wird erzeugt und es muß nichts in die Identifikatorzuordungstabelle eingetragen werden. Um das Erzeugen oder Verändern beim Speichern eines Objektes zu erkennen, ist bei jedem Speichervorgang als erstes die Identifikatorzuordnungstabelle zu befragen. In der GEBOS-Implementierung wird als eindeutiger Datenbankidentifikator eine 8 Byte lange RWG-eindeutige Nummer vergeben. Wie beim Speichervorgang wird der Ladevorgang eines zur Laufzeit erzeugten Objektes behandelt. Laden heißt hier, daß das bereits existierende Objekt mit Werten aus der Datenbank überschrieben wird.

4

Ladevorgang


4.2


995

Ähnlich wie beim Speichern wird ein Zeiger auf das zu ladende Objekt (Hauptspeicheradresse) an den Materialableger übergeben. Der Name der entsprechenden Relation wird über die Relationszuordnungstabelle ermittelt; der Identifikator des Objekts steht in der Identifikatorzuordnungstabelle der Relation. Anhand dieser Informationen wird das Tupel, das die Daten für das zu ladende Objekt enthält, in der Datenbank in einfacher Weise gefunden. Die gespeicherten Daten werden an das Objekt im Hauptspeicher übergeben. Das Objekt nimmt die Daten entgegen und setzt seine Attribute entsprechend. 2. Klassen mit eingebetteten Objekten als Exemplarvariablen Im Gegensatz zu Attributen mit referenzierten Objekten werden Attribute mit (statisch alloziierten) eingebetteten Objekten innerhalb des Speicherbereichs des benutzenden Objektes angelegt. Eingebettete Objekte werden also bereits beim Erzeugen des benutzenden Objektes alloziiert. Da die Objekte der eingebetteten Exemplarattribute statisch alloziiert sind, also keine »eigentlichen« Objekte mit Objektidentität darstellen (s. auch Kapitel 2.1.4 und 3.2.8), werden diese in der Datenbank nicht in einer eigenen Relation abgelegt. Statt dessen werden ihre Exemplarvariablen wie die Exemplarvariablen der benutzenden Klasse behandelt, die Struktur wird ebenfalls serialisiert.

4



4.2


Speicher- und Ladevorgänge unterscheiden sich nicht von denen der einfachen Klassen oder, falls eingebettete Objekte wiederum Objektreferenzen besitzen, entsprechend erweiterter Algorithmen (s.u.).

996 Speicher- und Ladevorgang

3. Klassen mit Objektreferenzen Unter Klassen mit Objektreferenzen verstehen wir Klassen, in denen mindestens ein Attribut eine Referenz zu einem Objekt einer anderen Klasse enthält15. Mindestens ein Attribut besitzt in C++ also den Zeigertyp. Wir nehmen hier an, daß die referenzierte Klasse eine einfache Klasse ist. Exemplare solcher Klassen nennen wir komplexe Objekte. Sie werden in GEBOS als Einheit gesehen und in der Regel als Ganzes gespeichert und geladen (Optimierungen siehe unten). Dabei kann ein Objekt von mehreren anderen Objekten referenziert werden. Wie bei den einfachen Klassen wird für jede Klasse mit Objektreferenzen eine Relation im Datenbankschema definiert. Sie enthält für jedes zu speichernde Exemplarattribut eines Elementartyps ein entsprechendes Datenbankattribut. Für jedes Exemplarattribut eines Zeigertyps


15. Referenzen auf Objekte der eigenen Klasse und zyklische Referenzen müssen als Sonderfälle behandelt werden.

4


4.2


997

werden zwei Attribute in der Relation definiert. Das erste Attribut enthält die Klasse, als Namen codiert, das zweite den Datenbankidentifikator des referenzierten Objekts. Die Struktur- (oder Meta-) Information wird also in die Relation mit aufgenommen. Die Namen der Datenbankattribute lassen sich auch in diesem Fall aus der Position der Attribute in der Klasse und vereinbarten Namen für Klassen- und Datenbank-Identifikatorattribute ableiten. Wir beschreiben nur die Unterschiede des Speicher- und Ladevorgangs von komplexen Objekten gegenüber einfachen Objekten.


Der Speichervorgang entspricht zunächst dem von einfachen Objekten. Stößt der Materialableger auf ein Attribut, das eine Objektreferenz enthält, so sind zwei Fälle möglich.

Speichervorgang

❑ Wenn das referenzierte Objekt bereits zur Laufzeit in der

Datenbank gespeichert wurde, so wird dessen Objektidentifikator aus der Identifikatorzuordnungstabelle geladen und als Wert zusammen mit dem Klassennamen in die beiden hierfür vorgesehenen Attribute des anzulegenden Tupels gespeichert. Standardmäßig wird auch das referenzierte Objekt erneut gespeichert. Dieses entfällt allerdings bei optimiertem Speichern (s.u.).

4


4.2


998

❑ Ist das referenzierte Objekt noch nicht abgespeichert, so wird

zunächst dieses und dann das referenzierende Objekt gespeichert. Denn das referenzierende Objekt muß den Datenbankidentifikator des referenzierten Objekts als Wert abspeichern, der nur beim Speichern des referenzierten Objekts erzeugt wird. Stößt der Materialableger beim Ladevorgang des Objektes auf ein Attribut vom Typ Zeiger, so ist der Datenbankidentifikator des referenzierten Objekts ein Tupelattribut. Über die Identifikatorzuordnungstabelle ist ersichtlich, ob sich das zugehörige Objekt im Hauptspeicher befindet. Wenn ja, so wird dessen Objektidentifikator dem Attribut zugewiesen. Wenn nein, so wird das referenzierte Objekt dynamisch erzeugt. Der erzeugte Objektidentifikator wird danach dem Attribut des referenzierenden Objektes zugewiesen.

Ladevorgang

4. Erbende Klassen In GEBOS wird die Speicherung von erbenden Klassen durch eine horizontale Auffächerung vorgenommen, d.h., die einer erbenden Klasse zugeordnete Relation enthält für alle geerbten Exemplarattribute und für die zusätzlich definierten Exemplarattribute entsprechende Datenbankattribute. In der Relation werden die geerbten Attribute vor den »eigenen« definiert. Bei der Namensgebung von

4



4.2


999

Datenbankattributen werden geerbte und eigene Exemplarattribute gleich behandelt. Bei Mehrfachvererbung muß ein Namenskonflikt von Attributen ausgeschlossen werden. Das Speichern und Laden verläuft analog zu den oben beschriebenen Algorithmen. Da der Typ der Objekte (s. Kapitel 2.1.4 und 3.3.4 ) bei der Abspeicherung berücksichtigt wird, gibt es keine Probleme beim Speichern, wenn Polymorphismus nur in einer Subtypbeziehung genutzt wird (s. Kapitel 2.1.11). Das navigierende Laden ist ebenfalls problemlos, da die Objekte jeweils über ihren dynamischen Typ Auskunft geben können. Beim deklarativen polymorphen Laden hingegen kann die Notwendigkeit auftreten, über Objekte aus der Oberklasse mit all ihren Unterklassen zu iterieren. Dies ist durch die gewählte Abbildung nicht einfach umsetzbar und wird in GEBOS auf der Ebene von Behältern mit Hilfe spezifischer Inhaltsverzeichnisse simuliert.


5. Klassen mit Klassenattributen Klassenattribute gelten im Gegensatz zu Exemplarattributen nicht für jedes einzelne Objekt, sondern sind ein Merkmal der ganzen Klasse. Sie sind daher pro Klasse (d.h. für alle Exemplare einer Klasse) nur einmal vorhanden und von der Existenz der Objekte der Klasse unabhängig. In C++ sind Klassenvariablen im Code durch static gekennzeichnet und werden so von Exemplarvariablen unterschieden.

4


4.2


1000

Für Klassenattribute ist eine eigene Speicherungsstruktur erforderlich. In GEBOS sind Klassenattribute auf den Typ Zeiger eingeschränkt, somit kann eine Klassenattributrelation zur Speicherung der Klassenattribute aller Klassen verwendet werden. Ein Tupel dieser Klassenattributrelation enthält Angaben zur Identifikation der Klassenattribute. Dies sind der zugehörige Klassennamen, die Position des Attributs in der Klasse, sowie der »Wert« des Klassenattributs mit dem Objektidentifikator des referenzierten Objekts sowie dessen zugehörigen Klassennamen. Klassennamen werden dabei durch Nummern kodiert.


Ähnlich wie Objekte werden auch (alle) Klassenattribute einer Klasse immer als Ganzes gespeichert oder geladen.


Beim Speichern wird die Klassennummer der Klasse an den Materialableger übergeben. Dann werden die Klassenattribute der Reihe nach abgearbeitet. Für jedes Klassenattribut wird ein Tupel in der Klassenattibutrelation angelegt und die Klassennummer, die laufende Nummer des Klassenattributs sowie der Verweis auf das referenzierte Objekt in das Tupel eingetragen. Ehe das Tupel eingefügt werden kann, muß – wie immer beim Speichern von Zeigern – das referenzierte Objekt ebenfalls gespeichert werden, um seinen Datenbankidentifikator zu erzeugen.

Speichervorgang

4


4.2


Beim Laden wird die Klassennummer der zu ladenden Klasse an den Materialableger übergeben. Dann werden die Klassenattribute der Klasse nacheinander abgearbeitet. Das Laden läuft analog wie bei Klassen mit Objektreferenzen.

1001 Ladevorgang

Lösung des Identifikationsproblems von Objekten Grundsätzlich ist die Identifikation von gespeicherten Objekten deshalb problematisch, weil dieselben Objekte in zwei getrennten Welten existieren. Im Anwendungsprogramm erhalten Objekte vom Laufzeitsystem einen Identifikator. Dieser ist völlig unabhängig von dem in der Datenbank vergebenen Identifikator. Nur während der Laufzeit eines Progamms können die Identifikatoren der getrennten Welten explizit mit Hilfsstrukturen aufeinander bezogen werden. Da persistente Objekte gerade durch die Abspeicherung in der Datenbank (»Datenbankwelt«) die Laufzeit eines Programms (»Programmierwelt«) überdauern, ist die Identifikation von Objekten in der Datenbank, die in früheren Programmausführungen erzeugt wurden, problematisch (dies ist in Abbildung 4-22 angedeutet). Denn Programme können Datenbankidentifikatoren nicht im Code enthalten, da diese ja erst zur Laufzeit erzeugt werden.

4


4.2


Programmierwelt

1002 Abb. 4-22 Identifikationsproblem über Programm-

Programmausführung 1

Identifikatorzuordnungstabelle

ausführungen hinweg

Programmausführung 2

? Datenbankwelt

Programmausführungen überdauernde Datenbankrepräsentation Objektidentifikator Datenbankidentifikator

In GEBOS wird das Problem ähnlich wie in einigen objektorientierten Datenbanken über die im vorigen Abschnitt vorgestellten Klassenattribute gelöst. Klassen sind statisch. Ihre Identifikatoren (Klassennummern) können in beiden Welten gleich vergeben werden. Sie sind

4


4.2


1003

daher Bindeglied zwischen beiden Welten. Über sie kann mittels Klassenattributen auf Objekte in der Datenbank zugegriffen werden. In GEBOS werden daher die Datenbankidentifikatoren komplexer Objekte als Wurzelobjekte in Klassenattributen gespeichert. Weitere Objekte können durch Navigation erreicht werden. Mit Hilfe von Klassenattributen werden somit Wurzelobjekte über Laufzeitgrenzen hinaus geladen. Häufig benötigen wir eine variable Anzahl von Wurzelobjekten. Dem steht entgegen, daß die Anzahl von Klassenattributen konstant ist. Für die Lösung wählen wir Behälter als Klassenattributobjekte (z.B. ein Produktordner). Das Inhaltsverzeichnis eines solchen Behälters ermöglicht den deklarativen Zugriff auf die Wurzelobjekte. Häufig reicht eine rein navigierende Identifikation von Wurzelobjekten für Ladevorgänge nicht aus. Daher existiert in GEBOS in der »Programmierwelt« eine eingeschränkte Form SQL-artiger, deklarativer Anfragen zur Identifikation. Diese Anfragen können nicht direkt auf Datenbankstrukturen zugreifen, da das Anwendungsprogramm diese nicht kennen soll. Anfragen richten sich vielmehr an die Inhaltsverzeichnisse von Behältern (s. Kapitel 3.2.7). Sie werden gebildet anhand von ausgewählten, im Inhaltsverzeichnis aufgenommenen Werten oder Objekten und den verfügbaren Vergleichsoperatoren. Als Ergebnis werden in der Regel Objektmengen geliefert (»Alle Ange-

4


4.2


1004

stellten mit Gehalt > 6000«), es sei denn, die fachlichen Objektbeschreibung enthalten eindeutige Identifikatoren (z.B. Kontonummer). Optimierungen Die beschriebenen Abbildungsregeln sind somit anwendbar, von Erweiterungen zur Behandlung zyklischer Objektstrukturen und virtueller Mehrfachvererbung einmal abgesehen. Aus Effizienzgesichtspunkten werden sie in GEBOS jedoch nicht in »Reinform« umgesetzt. Komplexe Objekte werden nicht ausreichend behandelt:

Gründe

❑ Bei der strikten Eins-zu-eins-Zuordnung von Klassen zu Rela-

tionen wird beim Speichern und Laden komplexer Objekte sehr häufig auf die Datenbank zugegriffen. ❑ Komplexe Objekte werden immer als Ganzes gespeichert oder

geladen. Dabei werden direkt oder indirekt referenzierte Objekte eines Wurzelobjektes jeweils mitgeladen oder gespeichert, ohne daß dies häufig notwendig wäre. Neben der oben erwähnten großen Anzahl von Datenbankzugriffen wird dadurch der Hauptspeicher unnötig ausgelastet. Aufgrund dieser Schwächen wurde in GEBOS die allgemeine Strategie um spezielle Strategien für bestimmte Klassen und Objekte erweitert:

4


4.2


1005

❑ Komplexe Objekte werden so abgespeichert, daß für das Spei-

chern und Laden minimale Datenbankzugriffe (im Idealfall nur noch einer) für das ganze Objekt erforderlich sind. ❑ Komplexe Objekte werden teilweise geladen. Nur die Teile

eines komplexen Objektes werden geladen, die die Anwendung auch wirklich benötigt. Dazu sind Mechanismen erforderlich, mit denen Teile von komplexen Objekten gezielt angesprochen werden können. Wir erläutern die Optimierungsstrategien an zwei Beispielen: Unter bestimmten Bedingungen kann darauf verzichtet werden, die Objekte der Exemplarattribute vom Typ Zeiger in einer eigenen Relation zu speichern. Statt dessen werden sie wie Klassen mit statischen Objekten als Exemplarvariablen in die Tabelle des referenzierenden Objektes abgelegt. Dies erfordert, daß die Objekte nicht von zwei verschiedenen Objekten referenziert werden und nicht als eigenständige Objekte, sondern nur im Kontext des sie referenzierenden Objektes auftreten. Die Referenz besitzt im Grunde Wertsemantik. Durch eine »serialisierte« Abspeicherung werden also zusätzliche Datenbankzugriffe beim Speichern oder Laden eines solchen komplexen Objektes eingespart. Objektreferenzen mit Wertsemantik werden in GEBOS speziell gekennzeichnet, so daß sie optimiert gespeichert werden können.

4

Beispiel: Klassen mit Objektreferenzen mit Wertesemantik


4.2


Spezielle Varianten optimierter Speicherstrategien sind in GEBOS für Behälter realisiert. Dabei wird die Liste der Elemente einer Sammlung in einen String abgelegt. Je nach Typ der Elemente enthält dieser String den Wert direkt (wenn es sich dabei selbst um eine Zeichenkette handelt) oder den Identifikator mit dem zugehörigen Klassennamen eines Objekts. Hierzu muß der String bei heterogenen Behältern Metainformation über den Elementtyp enthalten. Wieder werden die Datenbankzugriffe optimiert. Im Idealfall (bei Zeichenkettenobjekten) ist nur ein Datenbankzugriff für die gesamte Sammlung notwendig. Enthält ein Behälter Objektreferenzen, so werden gemeinsam mit dem String alle Objekte gleichzeitig geladen. Ein teilweises Laden von Objekten ist bei dieser Strategie nicht möglich. Die Reihenfolge der Behälterelemente bleibt erhalten. Eine andere Variante, Behälter abzulegen, verwendet explizite Inhaltsverzeichnisse. Ein Inhaltsverzeichnis enthält pro Behälterelement eindeutig ein Auflistungsobjekt. Dieses enthält bestimmte Attribute des Behälterelementes, über die eine deklarative Anfrage auf dem Inhaltsverzeichnis möglich ist. Das Auflistungsobjekt wird vom Behälter (aus Angaben des Elementes ) erzeugt, wenn das Element eingefügt wird. Die Attribute des Behälterelements, die in das Auflistungsobjekt übernommen werden, besitzen Referenzsemantik, um die Attribute im Inhaltsverzeichnis konsistent halten zu können.

4

1006 Beispiel: Behälterklassen


4.2


1007

Das Auflistungsobjekt enthält ferner einen Identifikator des Behälterelements – den Datenbankidentifikator. Ist das Auflistungsobjekt im Inhaltsverzeichnis geladen, so kann bei Auswahl durch den Anwender das zugehörige Elementobjekt teilweise oder ganz nachgeladen werden. Der zugehörige Objektidentifikator wird dann zusammen mit dem Datenbankidentifikator in der Identifikatorzuordnungstabelle (s. S. 489) eingetragen. Als Speicherungsstruktur ist eine Behälter- und Inhaltsverzeichnisrelation vorgesehen. In die Behälterrelation wird pro Behälter ein Tupel eingetragen. Die Inhaltsverzeichnisrelation enthält die Auflistungsobjekte mit den Identifikatoren der Behälterelementattribute und dem Datenbankidentifikator für das Behälterelement selbst. Außerdem wird dort pro Auflistungsobjekt als Rückverweis der Datenbankidentifikator des Behälters abgelegt. Die Elemente selbst werden wie oben beschrieben in eigenen Relationen abgelegt. Dieses verfeinerte Behälterkonzept ermöglicht das partielle Laden der Behälterobjekte. Dem Benutzer werden dazu fachlich aussagekräftige Inhaltsverzeichnisse zur Auswahl angeboten. Diese Inhaltsverzeichnisse unterstützen zudem deklarative Anfragen (s.o. Beispiel: Behälterklassen). Ein Beispiel für die Anwendung von Inhaltsverzeichnissen ist ein Bankproduktverzeichnis. Die Elemente dieses Behälters sind Bankpro-

4


4.2


1008

dukte, also Sparbriefe, Kredite usw. Die Produktobjekte sind in verschiedenen Relationen abgelegt, da mehrere Produktklassen existieren. Ein Produkt soll nun anhand seines eindeutigen Produktnamens aus der Datenbank geladen werden. Der Produktnamen wird deshalb als Attribut im Auflistungsobjekt vorgesehen. Durch das Laden der Auflistungsobjekte aus der Inhaltsverzeichnisrelation, ist es möglich eine Auflistung der Produktnamen aller im Behälter eingetragenen Produkte zu bekommen, ohne daß hierzu alle zugehörigen Produkte geladen werden müssen. Nach der Auswahl eines bestimmten Produktnamens durch den Anwender, kann dann das zum Auflistungsobjekt gehörende Produkt mit Hilfe des im Auflistungsobjekt enthaltenen Datenbankidentifikator geladen werden. Komponenten und ihr Zusammenspiel bei Speicherund Ladevorgängen Die Kommunikation mit der Datenbank wird von den Komponentenobjekten Materialableger, Datenbankautomat und Datenbankschnittstelle übernommen (s. Abbildung 4-23). Die GEBOS-Objekte kommunizieren nur mit dem Materialableger und dem Datenbankautomaten.

4

Komponenten


4.2


1009

Hinter dem Datenbankautomat verbirgt sich der Serialisierer (s. Kapitel 3.3.4). Das für den Datenbankaufruf durch einen Schreiber oder Leser notwendige Strukturwissen wird zunächst über eine Zwischenrepräsentation (Liste der Attributwerte) bereitgestellt. Diese berücksichtigt die Namenskonventionen von Attributen nach ihrer Position und die Zuordnung zwischen Klassen- und Relationennamen. Den eigentlichen Zugriff auf das Datenbanksystem übernimmt die C-Schnittstelle. Sie kapselt das Datenbanksystem, so daß bei einer Umstellung auf eine neue Datenbank nur die C-Funktionen angepaßt werden müssen. Allgemeiner Ablauf beim Speichern Im folgenden wird das Speichern in seinem Ablauf beschrieben; das Laden erfolgt analog (s. Abbildung 4-23). Das zu speichernde Objekt oder das benutzende Objekt wendet sich an den Materialableger und übergibt das zu speichernde Objekt. Meist wird der Materialableger aber durch einen dritten – z.B. ein Werkzeug – aufgerufen, wobei das zu speichernde Objekt mitgegeben wird.

4

1. Initiieren


4.2


1010

Der Materialableger prüft über die Datenbankschnittstelle, ob die Verbindung zur Datenbank noch besteht. Ist dies nicht der Fall, so versucht er die Verbindung wiederherzustellen. Danach erzeugt er einen Datenbankautomaten und übergibt diesem das zu speichernde Objekt. Der Datenbankautomat wendet sich an das zu speichernde Objekt, das daraufhin seine Daten übergibt. Der Datenbankautomat nimmt die Daten entgegen und gibt sie an die Datenbankschnittstelle zum Speichern weiter. Sind in diesen Daten weitere Objekte enthalten, so wendet sich der Datenbankautomat an diese Objekte, um auch deren Daten zu bekommen. Hat der Datenbankautomat das Speichern beendet, prüft der Materialableger die Schnittstelle auf eventuell aufgetretene Fehler und gibt den Fehlerstatus an den Aufrufer zurück.

4

2. Speichern

3. Beenden


4.2

Iniitiieren des Speicherns und Ladens

Objekt: Speicherbar

Übergabe der Daten


Materialableger

Prüfungen

Weiterreichen des Speicherns und Ladens

Datenbankautomat

1011

Datenbankschnittstelle

Übergabe der Daten

Übergabe der Daten

datenbankspezifische C-Schnittstelle

Übergabe der Daten

Datenbank

Abb. 4-23

In diesem Kapitel haben wir erste Ansätze beschrieben, wie sich Persistenz im Rahmen des WAM-Ansatzes realisieren läßt. Diese Ansätze basieren auf den Entwürfen und Konstruktionen aus drei Kooperationsprojekten. Alle drei Projekte sind im Bankenbereich angesiedelt.

Ablauf beim Speichern und

Wir haben darauf hingewiesen, daß noch keine endgültigen Ergebnisse zu diesem Thema vorliegen. Allerdings sind die Anwendungs-

Relevanz der Ansätze

4

Laden von Objekten


4.3

Automaten in technisch eingebetteten Anwendungssystemen

1012

systeme in allen Projekten bereits einsatzfähig. Dies reicht von einer fast flächendeckenden Ausbreitung des GEBOS-Systems im Kundenkreis der RWG bis zu kleineren Pilotsystemen bei der SüdwestLB und der UBS. Damit können wir zumindest sagen, daß die vorgeschlagenen Lösungen praktisch anwendbar sind. Dies gilt insbesondere für die Optimierungen zu den relationalen Transformationen. Konzeptionell geht die Diskussion weiter, aber aus unserer Sicht ist eine beachtliche Etappe erreicht worden.

4.3


Wir haben in Kapitel 3.1.6 verschiedene Einsatzmöglichkeiten von Automaten innerhalb des WAM-Ansatzes aufgezeigt. Sie können zur Automatisierung lästiger menschlicher Routinehandlungen, zur Kapselung von Schnittstellen der Systembasis (z.B. Datenbank, Betriebssystem) oder zur Steuerung von Arbeitsprozessen an Funktionsarbeitsplätzen dienen. In diesem Abschnitt betrachten wir eine weitere Möglichkeit, Automaten einzusetzen, indem wir diese zur Abbildung oder Kapselung technischer Prozesse verwenden, die als eingebettete Systeme in relativer Unabhängigkeit vom Anwendungssystem laufen.

4

Federführung: Wolf-Gideon Bleek Ko-Autor: Dirk Weske


4.3


1013

Technisch eingebettetes Anwendungssystem: Als technisch eingebettetes Anwendungssystem bezeichnen wir ein Softwaresystem, das technische Komponenten unter harten oder weichen Echtzeitbedingungen steuert, kontrolliert oder repräsentiert. Diese einbettenden technischen Komponenten nennen wir den (technischen) Kontext.

Wir zeigen dazu die wichtigsten Eigenschaften technisch eingebetteter Anwendungssysteme auf und grenzen diese gegenüber den Eigenschaften interaktiver Anwendungssoftware ab. Auch wenn unsere Erfahrungen mit Entwurf und Konstruktion technisch eingebetteter Anwendungssysteme noch nicht hinreichend konsolidiert sind, um daraus allgemeinverbindliche Entwurfsmuster abzuleiten, so konnten wir doch in einigen Kooperationsprojekten feststellen, daß der Entwurf technisch eingebetteter Anwendungssysteme zusätzliche Modellbildungsschritte erforderlich macht. Wir werden in diesem Zusammenhang insbesondere das Problem der Synchronisation von Anwendungssystemen und dem Zustand des einbettenden technischen Kontextes diskutieren.

4


4.3


1014

Auf der Ebene von Konzeptionsmustern zeigen wir abschließend, wie Automaten in technisch eingebetteten Anwendungssystemen durch das Konzept der Sonde realisiert und zur Laufzeit mit Hilfe sogenannter Einstellwerkzeuge abgefragt und eingestellt werden können. Die relative Unabhängigkeit technischer Prozesse von dem sie steuernden und überwachenden Anwendungssystem macht es notwendig, dabei auch über Probleme der Verteilung und Nebenläufigkeit sowie über asynchrone Kommunikationsmechanismen nachzudenken.

4.3.1 Von interaktiver und kooperativer Anwendungssoftware zu technisch eingebetteten Anwendungssystemen Wir haben die Entwurfsmetaphern des WAM-Ansatzes bislang vor allem bei der Entwicklung interaktiver Anwendungssoftware erfolgreich eingesetzt. Ein wesentliches Kennzeichen solcher Anwendungssoftware ist, daß alle Aktivitäten des Systems stets Reaktionen auf Handlungen des Benutzers sind, niemals jedoch die Anwendungssoftware selbst seinem Benutzer den »Arbeitstakt« vorgibt. Diese Eigenschaft konnte auch beim Übergang von Anwendungen für den einzelnen Arbeitsplatz zu kooperativen Arbeitsumgebungen und dem damit verbundenen Wechsel vom Einprozeßraum zum Mehrprozeßraum beibehalten werden.

4

Interaktive Anwendungssoftware


4.3


Die Firma MedIS entwickelt Software zum Betrieb klinischer Großlaboratorien, sogenannte Laborinformations- und Steuerungssysteme (LIS), auf Basis des WAM-Ansatzes. Wichtige Aufgaben des von MedIS entwickelten LIS sind:

1015 Beispiel LIS

❑ der automatisierte Transport von mit Blut oder Urin gefüllten Probenröhrchen von der Probenannahme (Wareneingang) zu passenden Analyseautomaten, ❑ die Steuerung und Überwachung der dort weitgehend automatisiert durchgeführten Analytik. Die Proben werden automatisch mit Hilfe eines ringförmigen Transportbandes transportiert. Dabei steckt jede Probe in einem Kunststoffblock, genannt Probenträger. Die Probenträger können an verschiedenen Stellen des Transportbandes durch spezielle Hardware, sogenannte Leser, identifiziert und voneinander unterschieden werden. Die Probenröhrchen werden über Barcode-Etiketten und handelsübliche Barcode-Scanner identifiziert. Ein besonderer Punkt des Transportbandes ist der Zuordnungspunkt. Er besteht aus einem Leser und einem am Band angebrachten Barcode-Scanner. Fährt ein Probenträger mit seinem Probenröhrchen am Zuordnungspunkt vorbei, so können mit Hilfe von Leser und Barcode-Scanner gleichzeitig Probenträger und Probenröhrchen identifiziert werden. Dieser Vorgang wird Zuordnung genannt. Das LIS kann anhand dieser Zuordnung den zum Probenröhrchen gehörenden Auftrag heraussuchen, geeignete Analyseautomaten ermitteln und den günstigsten Weg des Probenträgers zum ausgewählten Analyseautomaten berechnen.

4


4.3


1016

Der Probenträger wird über weitere spezielle Komponenten des Transportbandes, die Weichen, zum Analyseautomaten gesteuert. Weichen besitzen nicht nur die notwendige Mechanik, um einen Probenträger in die eine oder andere Richtung auszusteuern, sondern auch einen Leser, um herannahende Probenträger zu identifizieren. Weichen, die auf dem Weg zu ausgewählten Analyseautomaten liegen, werden vom LIS vorab über die zu erwartenden Probenträger und deren Ziele unterrichtet. Durch diese Form der »Scharfstellung« können Weichen die Probenträger unter Echtzeitbedingungen aussteuern, d.h. unmittelbar nach deren Identifikation und ohne (potentiell zeitbehaftete) Rückfrage beim LIS.

Fachlich betrachtet dienen technisch eingebettete Anwendungssysteme allerdings nicht vorrangig der Unterstützung (kooperativen) menschlichen Arbeitshandelns, sondern vielmehr der Überwachung und Steuerung technischer Anlagen, in denen technische Prozesse ablaufen. Technische Prozesse, zum Beispiel der automatisierte Transport von Proben über ein Transportband (siehe Beispiel LIS), zeichnen sich vor allem dadurch aus, daß sie ununterbrochen selbst aktiv sind. Sie laufen in relativer Unabhängigkeit von der sie steuernden und überwachenden Software und deren Benutzer ab. Trotzdem müssen diese Prozesse in einem technisch eingebetteten Anwendungssystem geeignet repräsentiert und konstruktiv umgesetzt werden.

4

Technisch eingebettete Anwendungssysteme


4.3


1017

Auf technischer Ebene zeigt sich der Unterschied zu interaktiver Anwendungssoftware vor allem darin, daß nicht ausschließlich der Benutzer aktiv ist. Statt dessen sind es vor allem die unabhängig vom Benutzer im technischen Kontext ablaufenden Prozesse, die über Ereignisse, wie etwa die automatische Zuordnung eines Probenträgers zu einem Probenröhrchen, Reaktionen innerhalb des Anwendungssystems auslösen. Unsere Erfahrungen zeigen, daß sich die Komponenten eines technisch eingebetteten Anwendungssystems, die sich wie zusätzliche Ereignisquellen verhalten, nicht »konventionell« über den Umgang mit Arbeitsgegenständen und -mitteln entwerfen lassen. Statt dessen müssen wir den Zustand des technischen Kontextes und die Beziehungen zwischen Kontext und Anwendungssystem explizit modellieren.

4.3.2 Zustandsmodelle technisch eingebetteter Anwendungssysteme Wenn wir beim Entwurf technisch eingebetteter Anwendungssysteme ein weiteres Zustandsmodell erarbeiten müssen, dann stellt sich natürlich die Frage, welches Zustandsmodell denn dem Entwurf interaktiver Anwendungssysteme zugrundeliegt. In Kapitel 2.5 haben wir das

4


4.3


1018

Modell des Anwendungssystems identifiziert. Dieses Modell, das in Software implementiert ist, repräsentiert neben der Dynamik auch den Zustand des Anwendungssystems. Dieser Zustand ist für die Diskussion in diesem Abschnitt immer wieder von Interesse. Er läßt sich mit Hilfe der Entwurfsmuster des WAM-Repertoires interpretieren. Der Zustand des Anwendungssystems entspricht dem Zustand der in einer Arbeitsumgebung aktiven Elemente, d.h. Werkzeuge, Automaten, Materialien und Behälter. Der »Zustand« des Benutzers dieser Umgebung muß dagegen nicht modelliert werden. Diesen Umstand haben wir ja gerade als Vorteil der unterstützenden Sichtweise identifiziert. Betrachten wir nun nur denjenigen Aspekt des Modells des Anwendungssystems, der den Zustand der Anwendungssoftware repräsentiert, so sprechen wir der Einfachheit halber auch nur vom Anwendungszustand. Anwendungszustand: Der Anwendungszustand eines nach WAM entworfenen, interaktiven Anwendungssystems umfaßt den in Software repräsentierten Zustand der Werkzeuge, Materialien, Automaten und Behälter zur Laufzeit. Der Anwendungszustand legt die möglichen Umgangsformen des Benutzers mit dem Anwendungssystem fest. Der Zustand des (sozialen) Kontextes des Anwendungssystems, also der »Zustand« des Benutzers, wird dagegen weder modelliert noch implementiert.

4


4.3


Wie bereits angedeutet, ist bei technisch eingebetteten Anwendungssystemen der Zustand des technischen Kontextes von so elementarer Bedeutung, daß er explizit modelliert werden muß. Wichtig für das folgende ist, daß dieses Zustandsmodell rein konzeptioneller Natur ist. Es spiegelt die fachlich abstrahierende Sicht des Softwareentwicklers auf die technische Konfiguration der einbettenden Hardwarekomponenten wider. Das Zustandsmodell umfaßt diejenigen Aspekte des technischen Kontextes, die dem Softwareentwickler für Entwurf und Konstruktion des Anwendungssystems relevant erscheinen. Damit läßt sich dieses Zustandsmodell mit dem Modell des Anwendungsbereichs bei der Entwicklung interaktiver Anwendungssysteme vergleichen (s. Kapitel 2.5.1). Technisch enthält das Zustandsmodell des Kontextes vor allem die verfügbaren Schnittstellen zwischen Hard- und Software (z.B. Leser und Barcode-Scanner) und die über diese Schnittstellen feststellbaren Ereignisse und Zustandsveränderungen des technischen Kontextes. In unserem Beispiel zählt dazu etwa die Zuordnung von Probenträger zu Probenröhrchen. Abstrahiert wird dagegen meist von den technischen Einzelheiten der Hardwarekomponenten, im Beispiel etwa von der elektromechanischen Realisierung der Weichen. Wir haben festgestellt, daß technisch eingebettete Anwendungssysteme dem Betrieb und der Überwachung technischer Anlagen die-

4

1019 Zustand des technischen Kontextes


4.3


1020

nen. Das gerade skizzierte Zustandsmodell des technischen Kontextes bildet genau den Zustand einer solchen Anlage ab. Daher nennen wir es das Anlagenmodell. Als rein konzeptionelles Modell wird es nicht unmittelbar in Software abgebildet. Anlagenmodell: Unter dem Anlagenmodell technisch eingebetteter Anwendungssysteme verstehen wir die abstrahierende Sicht des Softwareentwicklers auf die Konfiguration der einbettenden Hardware. Zur Laufzeit bildet das Anlagenmodell den Zustand des technischen Kontextes des Anwendungssystems, also den Zustand der zu betreibenden Anlage, ab. Technisch umfaßt es die verfügbaren Schnittstellen zwischen Hard- und Software sowie die über diese Schnittstellen feststellbaren Ereignisse und Zustandsveränderungen der Anlage. Das Anlagenmodell ist ein konzeptionelles Modell und wird nicht in Software implementiert.

Offensichtlich können Anlagenmodell und Modell des Anwendungssystems nicht unabhängig voneinander betrachtet oder gar erstellt werden, da zur Laufzeit wechselseitige Abhängigkeiten zu beachten sind.

4

Wechselseitige Abhängigkeiten


4.3


So sind bestimmte Ereignisse des Kontextes, die im Anlagenmodell abgebildet sind, für das Anwendungssystem relevant, da entsprechende Reaktionen der Software ausgelöst werden müssen. Umgekehrt können Veränderungen innerhalb (des Modells) des Anwendungssystems Rückwirkungen auf den technischen Kontext und damit auf das Anlagenmodell haben. In unserem Beispiel reagiert das steuernde LIS auf das (Anlagen-) Ereignis »Zuordnung« mit einer Aktualisierung seines Anwendungszustands, was nach einigen Berechnungen dazu führt, daß die auf dem Weg zum Analyseautomaten befindlichen Weichen »scharfgestellt« werden. Kommt der entsprechende Probenträger näher, wirkt sich diese Reaktion unmittelbar auf den Zustand der Anlage aus, da die Weiche den Probenträger in die eine oder andere Richtung aussteuert und damit wiederum den Zustand des Transportbandes beeinflußt. Damit wird das Grundproblem der Entwicklung technisch eingebetteter Anwendungssysteme deutlich. Zwischen dem Modell des Anwendungssystems und dem Anlagenmodell bestehen logische und zeitliche Abhängigkeiten. Wir müssen daher zusätzliche Mechanismen vorsehen, um das Anlagenmodell und den Anwendungszustand zu synchronisieren. In unserem Beispiel müssen also etwa der Zustand des Transportbandes und der Zustand des LIS genügend gut übereinstimmen.

4

1021

Beispiel LIS

Notwendigkeit zur Synchronisation


4.3


1022

Im weiteren erläutern wir, wie das Zusammenspiel der beiden Modelle zur Laufzeit konkret synchronisiert werden kann und welchen Einfluß die Eigenschaften der zu betreibenden Anlage auf die Gestaltung dieses Zusammenspiels haben. Sensoren und Aktuatoren

Aus der Definition des Begriffs Anlagenmodell wurde deutlich, daß vor allem die verfügbaren Schnittstellen zwischen Hard- und Software und die über diese Schnittstellen feststellbaren Ereignisse und Zustandsveränderungen des technischen Kontextes für den Softwareentwickler relevant sind. Sensor und Aktuator: Als Sensoren und Aktuatoren bezeichnen wir die Schnittstellen zwischen den Hardwarekomponenten einer technischen Anlage und der Software.

Sensoren registrieren relevante Ereignisse der zu betreibenden Anlage und geben sie an das Anwendungssystem weiter. Aktuatoren ermöglichen es dem Anwendungssystem, seinerseits steuernd auf die Hardware einzuwirken und damit den Anlagenzustand zu verändern.

4


4.3


1023

Sensoren und Aktuatoren können auf konzeptioneller Ebene durch jeweils zwei Komponenten modelliert werden (vgl. Abbildung 4-24). Abb. 4-24 Modellierung von Sensoren und Aktuatoren Hardwarekomponente

Sensor A/D-Wandlung Softwarekomponente

Hardwarekomponente D/A-Wandlung

Aktuator

Softwarekomponente

Die Hardwarekomponente eines Sensors registriert Ereignisse, die innerhalb der vom Anwendungssystem zu betreibenden Anlage stattfinden. Dies sind meist analoge Eingangsgrößen wie Temperatur, elektromagnetische Veränderungen oder elektrische Spannung. Diese Eingangsgrößen werden in digitale Ausgangssignale umgewandelt (A/D-

4

Modellierung von Sensoren


4.3


Wandlung) und der Softwarekomponente des Sensors als Programmereignis zur Verfügung gestellt. Auf technischer Ebene wird dieser Mechanismus meist über sogenannte Betriebssystem-Interrupts realisiert, die über entsprechende Interrupt-Handler in der Anwendungssoftware ausgewertet werden können. Ruft umgekehrt das Anwendungssystem die Softwarekomponente eines Aktuators, dann wird ein digitales Eingangssignal an die zugehörige Hardwarekomponente übermittelt. Je nach Aktuatortyp wird dieses Signal in entsprechende analoge Ausgangsgrößen umgewandelt (D/A-Wandlung) und kann auf diese Weise den Zustand der einbettenden Anlage verändern. Beispiele für Sensoren und Aktuatoren lassen sich innerhalb des LIS leicht finden. So wandelt der Barcode-Scanner des Zuordnungspunktes die beim Scannen eines Barcodes gewonnenen, analogen Eingangsgrößen in die digitale Repräsentation eines Barcodes um und stellt sie der Software zur Verfügung. Auch die Barcode-Leser sind Sensoren. Sie messen über ein Induktionsverfahren die elektromagnetischen Veränderungen, die ein vorbeifahrender Probenträger verursacht, und wandeln diese in eine digitale, für das LIS auswertbare Repräsentation des Probenträgers um.

4

1024

Modellierung von Aktuatoren

Beispiel LIS


4.3


Weichen sind dagegen Beispiele für Aktuatoren. Das LIS berechnet für jeden Probenträger die auf seinem Weg zum Analyseautomaten liegenden Weichen und unterrichtet deren Softwarekomponenten über den zu erwartenden Probenträger und sein Ziel. Die Hardwarekomponente der Weiche ist nun für die Umwandlung dieser digitalen Eingangsgröße in ihre analoge Ausgangsgröße, nämlich die mechanische Aussteuerung des Probenträgers, zuständig. Durch die konzeptionelle Aufteilung von Sensoren und Aktuatoren in jeweils eine Hard- und eine Softwarekomponente können wir sie nahtlos den beiden gerade vorgestellten Modellen eines technisch eingebetteten Anwendungssystems zuordnen (vgl. Abbildung 4-25).

1025

Zuordnung zu den Zustandsmodellen

Abb. 4-25

Anlagenmodell Sensor

Das Zusammenspiel von

HW

Anlagenmodell und Modell des Anwendungssystems über Sensoren und

SW


Aktuatoren SW

HW

4

Aktuator


4.3


1026

Die jeweilige Hardwarekomponente eines Sensors oder Aktuators ist immer Teil des Anlagenmodells. Bei Betrachtung des Anlagenmodells wird deutlich, daß die Modellierung der Hardwarekomponente von Sensoren oder Aktuatoren eine Abstraktion aus Sicht des Softwareentwicklers ist: So abstrahiert das Modell des Barcode-Scanners am Zuordnungspunkt vollständig davon, daß eine ganze Anzahl von Eingangsgrößen zur vollständigen Erkennung eines Barcodes ausgewertet und interpretiert werden müssen. Für den Softwareentwickler ist lediglich das Gesamtergebnis des Lesevorgangs, also der Wert des gelesenen Barcodes, von Interesse. Die Softwarekomponente eines Sensors oder Aktuators ist immer Teil des Anwendungssystemmodells. Der Umgang mit der Softwarekomponente eines Aktuators unterscheidet sich nicht wesentlich vom Umgang mit anderen Komponenten des Anwendungssystems, da er meist auf einfache Operationsaufrufe beschränkt werden kann. Komplizierter dagegen ist der Umgang mit der Softwarekomponente eines Sensors, da Anlagen-Ereignisse in den Kontrollfluß des Systemmodells integriert werden müssen. Hier muß auf Ebene des Modells entschieden werden, ob ein solches Ereignis den »normalen« Kontrollfluß der Anwendung priorisiert unterbrechen darf (Interrupt-Ansatz) oder ob ein solches Ereignis in den allgemeinen Ereignismechanismus eines

4


4.3


1027

reaktiven Anwendungssystems integriert werden soll (Event-LoopAnsatz). Steuerungsmodell und das Problem der Synchronisation

Wir haben festgehalten, daß das Anlagenmodell und das Modell des Anwendungssystems in ihren Zuständen durch geeignete Mechanismen synchronisiert werden müssen. Sind diese Mechanismen nicht ausreichend, so können sich die Zustände beider Modelle zur Laufzeit »auseinander entwickeln«. Dann besteht die Gefahr, daß sich ein scheinbar korrektes Verhalten des Modells des Anwendungssystems, bezogen auf den tatsächlichen Zustand des Anlagenmodells, als fehlerhaft erweist. Eine solche Inkonsistenz zwischen Anlagenmodell und Anwendungszustand kann beispielsweise entstehen, wenn das Modell des Anwendungssystems relevante Zustandsveränderungen des Anlagenmodells nicht nachvollziehen kann. Umgekehrt entsteht auch ein Problem, wenn das Modell des Anwendungssystems eigene Zustandsveränderungen nicht rechtzeitig an das Anlagenmodell weitergibt. Betrachten wir beispielsweise den Fall, daß ein Probenröhrchen, nachdem es den Zuordnungspunkt passiert hat und damit seinem Probenträger zugeordnet wurde, aber bevor es sein Ziel, den ausgewählten Analyseautomaten, erreicht hat, aus dem Probenträger entfernt und

4

Gefahr von Inkonsistenzen

Beispiel LIS


4.3


durch ein anderes Probenröhrchen ersetzt wird. Zweifelsohne ist dieses Ereignis innerhalb des Anlagenmodells für das Anwendungssystem relevant, da der zugehörige Auftrag und damit auch der berechnete Weg des Probenträgers fortan ungültig sind. In der beschriebenen Konfiguration kann das steuernde LIS diesen Austausch nicht rechtzeitig registrieren, da mit dem bereits passierten Zuordnungspunkt nur ein einziger für dieses Ereignis geeigneter Sensor zur Verfügung steht. Das LIS würde also, trotz eines für sich betrachtet korrekt implementierten Anwendungsmodells, das »falsche« Probenröhrchen zum »richtigen« Analyseautomaten steuern. Entscheidend für das Fehlverhalten des LIS ist nicht nur der Umstand, daß überhaupt eine Inkonsistenz zwischen den beiden Modellen auftreten kann. Ebenso wichtig ist, daß das Modell des Anwendungssystems über keinerlei Mittel verfügt, den Grad an Synchronizität zwischen dem angenommenen und dem tatsächlichen Zustand des Anlagenmodells festzustellen und adäquat zu behandeln. Es ist nicht in der Lage abzubilden, daß die ihm zur Verfügung stehende Information über den Zustand der zu betreibenden Anlage unter Umständen bereits »veraltet« ist. Statt dessen setzt das Modell des Anwendungssystems voraus, daß alle relevanten Veränderungen des Anlagenmodells unmittelbar und ohne weitere Verzögerungen weitergegeben werden. Anders ausgedrückt geht das Modell des LIS

4

1028

Synchrones Anlagenmodell


4.3


1029

mangels anderer Möglichkeiten davon aus, daß die Sensoren ein synchrones Modell des Transportbandes und der aktuellen Zuordnungen von Probenträgern zu Probenröhrchen zur Verfügung stellen. Ein synchrones Anlagenmodell ist aber für technisch eingebettete Anwendungssysteme aus mehreren Gründen nicht zu realisieren. So kommen extrem feingranulare Programmiermodelle für die Entwicklung »großer« Softwaresysteme nicht in Frage – z.B. das sogenannte Perfect-Synchrony-Model, bei dem die Modellierung eines synchronen Anlagenmodells über garantierte Taktfrequenzen der Sensoren und das Auszählen von Maschinenzyklen sichergestellt wird. Konzeptionell sind vor allem Fragen der Berechenbarkeit und Nebenläufigkeit ungeklärt. Auf technischer Ebene kommen Aspekte wie das Multitasking oder Multithreading moderner Betriebssysteme und das Caching der heutigen Prozessoren erschwerend hinzu. Neben diesen eher grundsätzlichen Einwänden sprechen auch pragmatische Überlegungen gegen die Modellierung eines synchronen Anlagenmodells. So müßte beispielsweise für das LIS zu jedem Zeitpunkt die Position jedes Probenröhrchens auf dem Transportband durch entsprechende Sensoren synchron an das Modell des Anwendungssystems übermittelt werden. Dies ist schon deshalb kaum möglich, da zusätzliche Sensoren aus Perspektive des Hardwareentwick-

4

Probleme eines synchronen Anlagenmodells


4.3


lers auch zusätzlichen Bedarf an Platz und Gewicht sowie einen nicht zu unterschätzenden Aufwand an Verkabelung bedeuten. Ferner sind sie für einen nicht unerheblichen Anteil der Kosten einer Hardwarekomponente verantwortlich. Aus Sicht des Softwareentwicklers implizieren zusätzliche Sensoren eine höhere »Taktrate« von Ereignissen und Daten, die entsprechend zu verarbeiten sind und daher mehr Aufwand für die Softwareentwicklung bedeuten. Wir müssen also bei der Modellierung technisch eingebetteter Anwendungssysteme mit einer begrenzten Anzahl an Sensoren und Aktuatoren auskommen. Folglich kann das Modell des Anwendungssystems bei technisch eingebetteter Anwendungssoftware nur über ein asynchrones Modell der zu betreibenden Anlage verfügen. Für die Modellierung stellt sich nun die Frage, an welcher Stelle wir die offenbar zu streng gefaßten Voraussetzungen des Anwendungsmodells aufweichen können. Eine im Sinne des WAM-Ansatzes gangbare Lösung stellt das sogenannte Steuerungsmodell dar: Dazu entkoppeln wir die Feststellung der in der Anlage stattfindenden Ereignisse und den Zeitpunkt ihrer Weitergabe von der eigentlichen Anwendungskomponente, die eine fachliche Reaktion auf diese Ereignisse implementiert. Umgekehrt entkoppeln wir die Weitergabe und den Zeitpunkt der Umsetzung von Veränderungen der Anlage von der Anwendungskomponente, die

4

1030

Asynchrones Anlagenmodell

Lösung des Synchronisationsproblems


4.3


1031

diese Veränderungen veranlaßt. Wir implementieren also alle Aspekte des Anwendungssystems, die die konkrete Steuerung der zu betreibenden Anlage betreffen, in einem eigenen Modell, dem Steuerungsmodell. Anlagenmodell

Abb. 4-26 Die Modelle eines technisch eingebetteten

Aktuatoren

Steuerungsmodell

Sensoren

Anwendungssystems


Dieses Steuerungsmodell wird logisch »zwischen« Anlagenmodell und dem Modell des Anwendungssystems angeordnet (s. Abbildung 4-26) und hat die Aufgabe, dem Anwendungssystem ein synchronisiertes Bild des Anlagenmodells zu präsentieren. Das bedeutet, daß sich das Anlagenmodell aus der Perspektive des Betrachters scheinbar synchron verhält, es aber in Wirklichkeit nicht ist. Gelingt es dem Steue-

4


4.3


1032

rungsmodell dem Anwendungssystem ein synchronisiertes Bild des Anlagenmodells zu präsentieren, dann verhält dieses sich so, als ob ein synchrones Anlagenmodell vorhanden wäre. Während das Anlagenmodell rein konzeptionell ist, wird das Steuerungsmodell, genau wie das Modell des Anwendungssystems, in Software implementiert. Das Steuerungsmodell umfaßt zunächst die softwaretechnischen Repräsentanten der verfügbaren Schnittstellen zwischen Hard- und Software, also die Softwarekomponenten von Sensoren und Aktuatoren. Ferner muß das Steuerungsmodell ein aufgrund der beschränkten Anzahl von Sensoren und Aktuatoren notwendigerweise asynchrones Modell der zu betreibenden Anlage implementieren und gleichzeitig dem Modell des Anwendungssystems ein synchronisiertes Bild der Anlage präsentieren. Dazu muß das Steuerungsmodell zu jedem Zeitpunkt eine Aussage über den Grad an Synchronizität mit dem Anlagenmodell treffen können. Das Steuerungsmodell muß also jederzeit wissen, ob es »aktuelle«, d.h. synchrone Informationen über den Zustand der Anlage hat, oder ob diese Informationen bereits »veraltet«, also asynchron mit dem tatsächlichen Zustand der Anlage sind. Nur wenn es über synchrone Informationen über den Zustand der zu betreibenden Anlage verfügt, darf es diese an das Modell des Anwendungssystems weitergeben.

4


4.3


1033

Steuerungsmodell: Das Steuerungsmodell kapselt alle Aspekte einer zu steuernden technischen Anlage. Aus Sicht des Modells des Anwendungssystems präsentiert das Steuerungsmodell ein synchronisiertes Bild des Anlagenmodells. Dadurch kann das eigentliche Anwendungssystem so konstruiert werden, als ob es über einen synchronen Anlagenzustand verfügen würde.

Im Rahmen des WAM-Ansatzes realisieren wir das Steuerungsmodell als einen technischen Automaten. Dieser Automat kapselt das Modell der zu betreibenden Anlage und ermöglicht so, das eigentliche fachliche Anwendungsmodell unabhängig von Synchronisationsgesichtspunkten der konkret zu betreibenden Anlage zu entwerfen. Gelingt es nicht, einen solchen Automaten zu konstruieren, dann ist das nach unserer Erfahrung ein deutlicher Hinweis dafür, daß nicht ausreichend Schnittstellen zwischen Hard- und Software vorhanden sind. In diesem Falle muß das Gesamtkonzept von Hardware- und Softwarekomponenten überprüft werden. Oft wird nämlich ein vermeintlicher Hardware-Kostenvorteil durch überproportional hohen Aufwand bei der Entwicklung von Steuerungssoftware erkauft, die das Defizit an synchronisierter Information über den Zustand der Anlage durch erhöhte Komplexität kompensieren muß.

4


4.3


1034

4.3.3 Konzeptionsmuster für technisch eingebettete Anwendungssysteme Während wir bisher die grundsätzlichen Probleme der Entwicklung technisch eingebetteter Anwendungssoftware diskutiert haben, gehen wir jetzt näher auf die Entwurfskomponenten dieser Anwendungssoftware ein. In konkreten Projekten haben wir festgestellt, daß die in den Kapiteln 3.1 und 3.2 vorgestellten Konzepte von Automaten und Werkzeugen nicht ausreichen, um alle Formen des Umgangs im technischen Bereich zu beschreiben. Beide Konzepte, Automat und Werkzeug, werden nun für dieses Anwendungsfeld präziser gefaßt. Der technische Automat

Wir wählen zunächst ein bewußt simplifiziertes Beispiel für einen fachlichen Automaten. Ein Kopierer ist ein alltägliches Gerät, mit dem wir Dokumente vervielfältigt können. Als Kopierautomat eines Anwendungssystems kann er die gleiche Aufgabe wahrnehmen. Wir stellen an diesem Kopierautomaten z.B. die Anzahl der anzufertigenden Kopien ein. Dann wird dem Automaten das zu kopierende Dokument übergeben. Danach verrichtet der Kopierer seine Arbeit selbsttätig.

4


4.3


1035

Bisher haben wir das Konzept des Automaten auf reaktive Geräte beschränkt, die, wie unser Kopierer, nur aufgrund einer Benutzeraktion aktiv werden. Mit dem Steuerungsautomaten einer technischen Anlage haben wir erstmals Komponenten in das Modell des Anwendungssystems einbezogen, die ohne Zutun des Anwenders aktiv werden. Diese spezielle Eigenschaft muß im Entwurf und in der Konstruktion berücksichtigt werden. Wir suchen nach einem Benutzungsmodell für diese zusätzlichen Ereignisquellen, die neben den Aktivitäten des Benutzers existieren. In den bisher untersuchten Anwendungssystemen ging die Steuerung der Anwendung ausschließlich vom Benutzer aus. Dieser wählt z.B. einen Menüpunkt aus, klickt einen Knopf auf der Oberfläche mit der Maus an oder gibt Daten mit der Tastatur ein. Daraufhin reagiert das Anwendungssystem. Jetzt müssen wir technisches Gerät modellieren, das durch eigene, vom Benutzer unabhängige Aktivitäten charakterisiert ist. Im Benutzungsmodell muß daher deutlich werden, daß Aktionen des Anwendungssystems auch ohne Zutun des Benutzers ausgelöst werden können.

Automaten als zusätzliche

Diese neuen Merkmale technischer Systeme werden im Konzeptionsmuster des technischen Automaten berücksichtigt. Der technische Automat stellt also eine zusätzliche Ereignisquelle in technisch einge-

Lösung

4

Ereignisquelle

Diskussion


4.3


1036

betteten Anwendungssystemen dar, die gleichberechtigt neben dem Benutzer Aktionen auslösen kann. Damit das Anwendungssystem adäquat auf diese Aktionen reagieren kann, muß es darüber benachrichtigt werden. Technischer Automat:

Technische Automaten bilden anwendungsfachlich relevante Zustände von (»realen«) technischen Geräten ab, um sie in das Modell des Anwendungssystems zu integrieren. Sie benachrichtigen andere Komponenten des Anwendungssystems über Zustandsänderungen und stellen eine zusätzliche Ereignisquelle dar.

Technische Automaten stellen eine Entwurfsmetapher für »reale« technische Geräte dar, wie z.B. das Laborsystem, Telefonanlagen oder andere Maschinen. Natürlich sind auch technische Automaten real, aber sie sind ein softwaretechnisches Modell für andere, meist elektromechanische Geräte oder Anlagen. Technische Automaten präzisieren den allgemeinen Begriff Automat des WAM-Ansatzes (s. Kapitel 2.2.3 und 3.1.6). An einem technischen Automaten können verändernde Operationen aufgerufen werden, um das technische Gerät einzustellen. Diese

4


4.3


1037

Einstellungen verändern den Zustand des Automaten. Externe Ereignisse führen ebenfalls zur Veränderung des Automatenzustands. Damit muß neben dem Ereigniskanal des Fenstersystems bei interaktiven Anwendungen eine zusätzliche Ereignisquelle berücksichtigt werden. Als Beispiel für einen äußerst komplexen technischen Automaten wählen wir die Kapselung einer Telefonanlage. Das Anlagenmodell dieser Telefonanlage wechselt offensichtlich seinen Zustand, wenn ein Teilnehmer anruft. Dies läßt sich dadurch beschreiben, daß eine Nebenstelle in den Zustand »Klingeln« übergeht. Entsprechend muß auch in der softwaretechnischen Realisierung des Steuerungsmodells, also dem Automaten »Telefonanlage«, der Zustand wechseln. Stellen wir uns zur Veranschaulichung in der Anwendung eine interaktive Repräsentation der Telefonanlage vor. Dann muß der neue Zustand »Klingeln« einer Interaktionskomponente signalisiert werden, damit diese durch die Präsentation eines entsprechenden Symbols reagieren kann. Neben dem Benutzer als Quelle für Ereignisse tritt nun also der technische Automat Telefonanlage mit seinen Ereignissen gleichberechtigt im Benutzungs- und im Implementationsmodell auf.

4

Beispiel Telefonanlage


4.3


1038

Die Sonde

Klienten eines technischen Automaten sind nicht immer am gesamten Automatenzustand interessiert. In vielen Anwendungsfällen reicht es aus, einen partiellen Zustand des technischen Automaten zu kennen. Dafür spricht unser Entwurfsprinzip, daß im Modell des Anwendungssystems nur die Zustände auftreten sollen, die auch fachlich motivierbar sind. Dazu kommt die softwaretechnische Überlegung, daß jede unnötige Kommunikation zwischen dem technischen Automaten und seinen Klienten nur zu einer schlechteren Laufzeit führt. Wir suchen nach einer Konstruktion, bei der der Klient eines Automaten bestimmen kann, für welchen Ausschnitt des vom Automaten abgebildeten Zustandsraums er sich interessiert. Außerdem sollen die genannten Eigenschaften eines Automaten in diese Konstruktion integriert werden. Die fachlichen Zustände des Automaten lassen sich in zwei Kategorien aufteilen. In die erste Kategorie fallen Eigenschaften eines Automaten, die charakteristisch sind und sich nicht ändern. Sie können direkt am Automaten sondiert werden. In die zweite Kategorie fallen diejenigen fachlichen Zustände eines Automaten, die sich regelmäßig oder unregelmäßig ändern. Diese betrachten wir als veränderliche Meßwerte.

4

Problem


4.3


Zur Bestimmung dieser Meßwerte führen wir die Entwurfsmetapher Sonde (vgl. [Perry 96]) neu ein. Eine Sonde ist laut Lexikon ein kleines Meßgerät oder Meßfühler (im einfachsten Fall eine Metallspitze), das physikalische Verhältnisse (z.B. Geschwindigkeitsverteilungen einer Strömung, elektrischer Potentiale in einer Gasentladung) mißt, ohne sie zu stören (vgl. [Fischer 81]). Damit ist eine Sonde einem Sensor (s. Kapitel 4.3.2) sehr ähnlich. Wir wählen bei der Übertragung der Metapher in den WAM-Ansatz deshalb einen anderen Begriff, um klarzumachen, daß Sonden ausschließlich auf der Ebene des Anwendungssystems existieren, und nicht wie Sensoren Teil der Anlage sind. Wir bringen eine Sonde an einem Automaten an, um dort typisierte Meßwerte, d.h. Fachwerte (s. Kapitel 3.2.8), abzunehmen und sie verfügbar zu machen. Beim Entwurf eines Automaten legen wir deshalb fest, welche Sonden überhaupt angebracht werden können. Der Automat kann nach den verfügbaren Sonden gefragt werden. Im WAM-Ansatz ist eine Sonde also ein Objekt, das einen vordefinierten Meßwerttyp am Automaten abliest und diese Werte in fachlich motivierten und technisch realisierbaren Zeitabständen liefert.

4

1039 Entwurfsmetapher Sonde


4.3


1040

Sonde: Eine Sonde ist eine Komponente, die genau einen meßbaren Wertes eines Automaten ermittelt. An der Sonde kann eingestellt werden, in welchen Zeitabständen dieser Wert aktualisiert wird. Eine Sonde ist mit einem technischen Automaten verbunden und wird von ihm mit Meßwerten versorgt. Klienten der Sonde können sich für Ereignisse registrieren. Sie werden dann in den gewählten Abständen über die Meßwerte informiert.

Die Entwurfsmetapher Sonde läßt sich bruchlos in ein Konzeptionsmuster übertragen. Eine Sonde ermöglicht uns, einzelne fachlich relevante Meßwerte eines Automaten zu repräsentieren. Eine Sonde kann die Zustände des realen technischen Geräts aggregieren oder daraus fachlich motivierte Werte berechnen. Der Automat kennt die prinzipiellen Anforderungen der Sonde. Er liefert entsprechend seinen Zustandsveränderungen ein Ergebnis an die dafür vorgesehene Sonde. Die Sonde ist lose an ihre Klienten gekoppelt und benachrichtigt diese über neue Werte.

4

Konzeptionsmuster Sonde


4.3


1041 Abb. 4-27


Das Sondenmuster

Automat Sonden

Die Funktionskomponente eines Werkzeugs oder die Interaktionskomponente eines Automaten können sich bei einer Sonde registrieren, um darüber den Automaten nach einem Fachwert zu sondieren. Bei der Registrierung kann dann angegeben werden, auf welche Weise die Komponente über Änderungen informiert werden will (z.B. Sampling-Rate, oder ereignisgetrieben bei jeder Änderung). Abbildung 4-27 zeigt eine Interaktionskomponente, die einen Automaten und eine von zwei Sonden benutzt. Stellen wir uns zwei technische Automaten vor, die mit elektromechanischen Aggregaten eines Fahrzeugs verbunden sind. Der erste Automat repräsentiert den Motor und stellt je eine Sonde für die Umdrehungszahl und die Öltemperatur zur Verfügung. Außerdem kön-

4

Beispiel Armaturenbrett


4.3


1042

nen wir am Automaten den Hubraum des Motors abfragen. Während sich Umdrehungszahl und Öltemperatur natürlich in der Zeit verändern, ist die Größe des Hubraums über die Lebensdauer des Motors konstant. Ein zweiter Automat, der die Benzinpumpe des Fahrzeugs repräsentiert, bietet eine Sonde an, die den Durchfluß des Kraftstoffs meldet. Bei allen Sonden kann die Ereignisfrequenz eingestellt werden. Für den Entwurf eines einfachen Werkzeugs, das neben den genannten Werten auch noch den Verbrauch des Motors anzeigen soll, benutzen wir in der Funktionskomponente die Sonden UPM und Durchflu§, um aus den gelieferten Werten den Kraftstoffverbrauch zu berechnen.

4


4.3


1043 Abb. 4-28

WerkzeugFK Armaturenbrett

Sonden für ein Armaturenbrett-Werkzeug

BerechneVerbrauch() ...

Automat Motor GibSonde() GibHubraum()

Sonde UPM

Sonde Öltemperatur

GibWert() SetzeFrequenz()

GibWert() SetzeFrequenz()

Automat Benzinpumpe GibSonde()

Sonde Durchfluß GibWert() SetzeFrequenz()

Abbildung 4-28 verdeutlicht die Zusammenhänge: Ein Werkzeug soll die Fachwerte eines Fahrzeugs am Armaturenbrett anzeigen. Einige der Werte werden durch Berechnung ermittelt (hier der Verbrauch).

4


4.3


1044

Dazu verwendet das Werkzeug zwei technische Automaten, die Aggregate im Fahrzeug repräsentieren. Unveränderliche Werte eines Automaten lassen sich direkt sondieren. Für Größen, die sich in der Zeit verändern, kann die Funktionskomponente am Automaten eine Sonde anfordern. Diese Sonde liefert einen spezifischen Ausschnitt des fachlichen Zustandsraums. Um die Veränderung dieses Zustandsraums zu erfassen, kann die Sonde eingestellt werden. Die Funktionskomponente kann nun aus den von den Sonden gelieferten Werten neue Fachwerte berechnen, die über die Interaktionskomponente angezeigt werden. Technische Automaten und Sonden sind nützliche Konzeptionsmuster für den Entwurf technisch eingebetteter Anwendungssysteme. Technische Automaten und Sonden bilden eine konzeptionelle Einheit. Diese Einheit repräsentiert eine Ereignisquelle im Anwendungssystem. Das Einstellwerkzeug

Bisher haben wir Werkzeuge und Automaten dafür vorgesehen, Materialien darzustellen und zu bearbeiten. Materialien haben zwar eine oft umfangreiche fachliche Schnittstelle, sind aber nicht (inter-) aktiv. Werkzeuge und Automaten sind die einzigen Bestandteile der WAMModellwelt, die als Reaktion auf Benutzeraktionen oder Voreinstellungen Änderungen an Materialien durchführen können.

4


4.3


1045

Obwohl Automaten eine Interaktionskomponente besitzen können, ist dies nicht immer möglich. Das technische Gerät oder die Anlage, die durch einen Automaten repräsentiert wird, kann an einem anderen Ort stehen als die Arbeitsumgebung, der dieser Automat zugeordnet ist. Trotzdem müssen diese technischen Komponenten immer wieder eingestellt werden. Dazu kommen andere Aufgaben, die wir allgemein als Kontroll- und Wartungsarbeiten an technischen Komponenten bezeichnen wollen. Um diese Kontroll- und Wartungsarbeiten innerhalb eines technisch eingebetteten Anwendungssystems ausführen zu können, entwickeln wir spezielle Werkzeuge, die wir Einstellwerkzeuge nennen.

Problem

In Kooperationsprojekten (z.B. die Projekte »Agentenmonitor« und »MCC Online Configuration« bei Micrologica, s. S. 519f.) haben wir festgestellt, daß alle dort konstruierten Automaten mehr oder minder häufig eingestellt werden mußten. Es gibt z.B. Arbeitsplätze, die kontinuierlich durch einen technischen Automaten mit ihren Arbeitsgegenständen, z.B. Telefonaten, versorgt werden. An diesen Automaten mußten Anwender einstellen können, wie welche Arbeitsgegenstände verteilt werden.

Kontext

Auf der Suche nach einem geeigneten Konzept haben wir uns wieder an der täglichen Arbeit mit »realen« Anlagen und technischem Gerät

Lösung

4


4.3


1046

orientiert. Dort führen qualifizierte Techniker regelmäßig oder bei Bedarf Wartungs- und Einstellungsarbeiten durch. Dabei verwenden sie spezielle Werkzeuge, um die verschiedenen Parameter der technischen Geräte einzustellen. Daraus haben wir den Begriff des Einstellwerkzeugs abgeleitet. Übertragen auf den WAM-Ansatz ist ein Einstellwerkzeug ein spezielles Softwarewerkzeug, mit dem der Benutzer die Parameter eines technischen Automaten visualisieren und verändern kann. Einstellwerkzeug: Ein Einstellwerkzeug ist ein spezielles Werkzeug, um technische Automaten zu warten und zu kontrollieren. Es zeigt einen fachlich motivierten Ausschnitt des Zustands eines oder mehrerer technischer Automaten an und ermöglicht, Parameter an diesen Automaten einzustellen.

Um den Automatenzustand darstellen zu können, wird das Einstellwerkzeug z.B. über eine Sonde mit dem Automaten verbunden und so mit Zustandsinformationen versorgt. Sowohl die Auswahl der Informationen als auch die Frequenz, mit der Zustandsbeschreibungen

4


4.3


1047

geliefert werden, lassen sich mit dem Einstellwerkzeug festlegen. Es hängt vom jeweiligen Anwendungsbereich ab, ob nur einige Teilzustände eines Automaten oder der gesamte fachliche Zustand visualisiert werden müssen. Auch die Art der Aktualisierung der Zustandsinformationen im Einstellwerkzeug kann nicht allgemein festgelegt werden. Typische Anforderungen sind: »bei jeder Änderung des Automatenzustands« und »in festen zeitlichen Abständen«. Wir haben bisher selten erlebt, daß der Benutzer explizit mit dem Einstellwerkzeug eine Zustandsabfrage angestoßen hat. Die Veränderung von Parametern eines technischen Automaten erfordert ein etwas anderes Konzept, als wir es beim Entwurf von Werkzeug und Material bisher beschrieben haben. Bei interaktiven Anwendungssystemen hat der Benutzer die volle Kontrolle über das, was er mit Werkzeugen und Materialien macht. Technische Automaten haben dagegen ein gewisses »Eigenleben«, da sie ja weitgehend selbständig laufende technische Geräte abbilden. Einstellwerkzeuge haben deshalb keinen unmittelbaren Zugriff auf das technische Gerät, sondern sie übermitteln Wünsche (Requests) an den technischen Automaten. Inwieweit der Automat die daraus resultierenden neuen Zustände einnehmen kann oder ob er die Zustandsänderungen ablehnt ist sowohl fachlich als auch technisch begründet.

4


4.3


Einstellwerkzeuge werden aus den fachlichen Entwurfskomponenten Interaktionskomponte, Funktionskomponente, Sonde und Automat aufgebaut. Im folgenden werden wir die entsprechenden Zusammenhänge erläutern. Einstellwerkzeuge sind wie andere Werkzeuge in eine Umgebung eingebettet. Sie verwaltet das Wissen, welche Werkzeuge erzeugt werden können und welche bereits arbeiten; sie kann neue erzeugen und bestehende wieder beenden. Das Einstellwerkzeug selbst besteht aus Interaktions- und Funktionskomponente(n) und benutzt einen Automaten. Die Interaktionskomponente (IAK) stellt den Automatenzustand dar und erlaubt, Änderungswünsche abzusetzen. Die IAK hat kein eigenes Gedächtnis und ist deshalb auf eine Funktionskomponente angewiesen, von der sie jederzeit den fachlichen Zustand abfragen kann. Die Funktionskomponente (FK) liefert der IAK den fachlichen Zustand und koordiniert die Verbindung zum Automaten. Obwohl jeder Automat seinen eigenen Zustand hat, wird eine FK benötigt. Diese liefert für die Werte eines Automaten die jeweils benötigte fachliche Interpretation. Werden mehrere Automaten mit Hilfe eines Werkzeugs gesteuert, dann findet in der FK die fachliche Koordination der technischen Ereignisquellen statt.

4

1048 Architektur


4.3



1049 Abb. 4-29 Die Architektur eines Einstellwerkzeugs

Werkzeug-FK

Sonde

Automat

Automat

Eine Funktionskomponente speichert die Ergebnisse einer Automatensondierung zwischen; sie kann zudem die verschiedenen Werte interpretieren und neue für die Interaktionskomponente berechnen. Die FK kann die fachlichen Zustände und die Einstellungen unterschiedlicher Automaten in einem Werkzeug kombinieren. Greifen wir hier das Beispiel des Armaturenbretts wieder auf. Wir entwerfen eine Softwarekomponente, die einerseits die aktuellen Werte der Aggregate darstellt und zusätzlich z.B. für eine konstante Fahrgeschwindigkeit sorgen kann. Diese Kombination aus den konventionel-

4

Beispiel Armaturenbrett


4.3


1050

len Anzeigen eines Armaturenbretts und einem sogenannten Tempomaten wäre ein Einstellwerkzeug, das mit verschiedenen technischen Automaten arbeitet (zur Repräsentation von Motor, Benzinpumpe, Pedalen etc.).

4.3.4 Vom Einzelprozeßsystem zum Mehrprozeßraum Wir haben schon in Kapitel 3.3 die Frage nach der Aufteilung oder »Granularität« eines Anwendungssystems aufgeworfen. Zwischen dem Objekt als kleinster Einheit des Laufzeitsystems und dem gesamten Anwendungssystem gibt es keine »natürliche« Aufteilung in Komponenten. Für den Entwurf und die Konstruktion interaktiver Anwendungssysteme haben wir eine Reihe von Entwurfsmustern und eine rahmenwerkbasierte Modellarchitektur vorgeschlagen, die eine Aufteilung des Gesamtsystems in fachlich und technisch motivierte Einheiten darstellen. In diesem Kapitel diskutieren wir alternative Gliederungsmöglichkeiten für Werkzeuge und Automaten, die durch die Entwicklung technisch eingebetteter Anwendungssysteme motiviert sind. Wir stellen eine Architektur vor, die asynchrone Kommunikation an den bereits bekannten synchronen Kontrollfluß anknüpft. So können wir separate Prozesse miteinander koppeln. Als Folge können wir Werkzeuge in unterschiedlichen Prozessen eines Rechners realisieren

4


4.3


1051

und Werkzeuge mit Automaten in lokalen oder weit entfernten Netzen interagieren lassen. Wie die vorausgegangenen Überlegungen sind auch diese Konstruktionen Ergebnisse von Kooperationsprojekten. Die meisten Anwendungssysteme nach dem WAM-Ansatz sind für den Einzelprozeßraum entwickelt worden. An einem Arbeitsplatz koordiniert ein Umgebungsobjekt den Ereignisfluß zwischen den Werkzeugen, die dem Benutzer des Anwendungssystems zur Verfügung stehen. Jedes Werkzeug kann als Kontext-Werkzeug den Rahmen für SubWerkzeuge bilden. Diese Konstruktion unterstützt noch keine autonomen Komponenten, wie wir sie bei der Diskussion um Einstellwerkzeuge und technische Automaten gefordert haben. Insbesondere setzt die bisher vorgestellte Architektur eine synchrone Kopplung von Objekten voraus. Dies zeigt sich z.B. am Beobachtermuster, das etwa zur losen Kopplung von Funktions- und Interaktionskomponente und zur Anbindung des Umgebungsobjekts verwendet wird. Wenn wir mehr als einen Prozeß haben wollen und diese Prozesse über ein Kommunikationsmedium (lokale Interprozeßkommunikation mittels Signals oder LAN/WAN-Kommunikation mit Hilfe von Datenpaketen) miteinander verbinden, müssen wir asynchrone Kopplung berücksichtigen.

4

Kontext


4.3


Wir möchten Einstellwerkzeuge und Automaten so realisieren, daß die Automaten als eigenständige Komponenten auf separaten Maschinen laufen. Dazu müssen wir Prozesse miteinander koppeln. Dies ist wünschenswert, da wir voneinander abgrenzbare Komponenten entwikkeln wollen oder müssen. Neben den Merkmalen von Einstellwerkzeugen und Automaten, die wir bisher diskutiert haben, lassen sich auch für »konventionelle« Anwendungssysteme Nachteile eines Einprozeßsystems identifizieren:

1052 Problem

❑ Große Programmdateien (Executables): Da alle Komponenten

eines Systems innerhalb eines Prozesses laufen, ergeben sich daraus zwangsläufig große Programme. Insbesondere müssen in einer Sitzung unbenötigte Teile geladen und initialisiert werden. ❑ Lange Turnaround-Zeiten: Da bei Veränderungen am System

immer das gesamte System neu gebunden werden muß, ergeben sich lange Bindezeiten. Durch schwer zu vermeidende Abhängigkeiten kann außerdem das vollständige Übersetzen aller Komponenten notwendig werden. ❑ Schlechte Konfektionierbarkeit: Unterschiedliche Kunden-

ansprüche können eine unterschiedliche Zusammenstellung

4


4.3


1053

von Komponenten zu Arbeitsumgebungen für die kundenspezifischen Anforderungen ergeben. Bei einer Fehlerkorrektur bedeutet dies, daß für jeden Kunden ein separat zu konfektionierendes Anwendungssystem erstellt werden muß. ❑ Kein Verteilungsmodell: Wir können zwar externe Komponen-

ten mit Hilfe des Musters »Automat« in ein Anwendungssystem integrieren. Daraus ergibt sich aber noch kein generelles Muster für die Verteilung der verschiedenen Komponenten eines Anwendungssystems, z.B. für Werkzeuge. Jeder Server (s. Kapitel 4.2) wird »von Hand« angebunden. Im weiteren zeigen wir, welche Überlegungen zur Aufteilung und Verknüpfung von Prozessen geführt haben und welche Vorteile aus dieser Art der Anbindung resultieren. Aufteilung von Komponenten Die Firma Micrologica entwickelt Hard- und Software zur automatischen Verteilung und Durchführung von Telefongesprächen, sogenannte Telefoniesysteme. Diese Technologie wird zum Betrieb von Call Centern benötigt, in denen Sachbearbeiter große Anrufvolumina bearbeiten. Mit Hilfe eines Call Centers können sowohl große Anrufmengen auf Mitarbeiter verteilt werden, wie auch automatische Anruflisten abgearbeitet werden. Zu den wesentlichen Aufgaben eines Telefoniesystems in einem Call Center gehören:

4

Beispiel Telefoniesystem


4.3


1054

❑ eingehende Gespräche entsprechend der gewählten Nummer an einen Arbeitsplatz zu schalten, an dem ein qualifizierter Mitarbeiter zu Verfügung steht, ❑ Gesprächsinformationen am Arbeitsplatz zur Verfügung zu stellen, ❑

statistische Informationen zu den Telefongesprächen zu sammeln,

❑

Änderungen an der Verteilungsstrategie zur Laufzeit zu ermöglichen.

Eingehende Gespräche kommen über ausgewählte Rufnummern in das Telefoniesystem. Anhand der gewählten Nummer entscheidet das System, welche Gruppe von Mitarbeitern für den Anruf zuständig ist. An diese (logische) Gruppe wird das Gespräch geleitet. In deren Verantwortung liegt nun die Verteilung des Gesprächs auf einzelne Mitarbeiter. Jeder Mitarbeiter ist aufgrund seiner Qualifikation in verschiedenen Gruppen, die z.B. für die Bestellannahme, Kundenberatung oder technische Unterstützung zuständig sind. Mit dem Gespräch werden auch die gesprächsrelevanten Daten zu dem Arbeitsplatzrechner des Mitarbeiters übertragen. Die gesamte Gesprächsverteilung übernimmt ein dafür entwikkelter Softwareautomat. Zur Administration eines Telefoniesystems benötigt man Werkzeuge, um während des Betriebs neue Anwender eintragen zu können. Die Zugehörigkeit zu bestimmten Gruppen muß im Betrieb vom Administrator einstellbar sein. Ebenso wird gefordert, überlastete Gruppen während des Betriebs dadurch zu entlasten, daß Überläufe in andere Gruppen zeitweise zugelassen werden. Mit speziellen Werkzeugen kann die Telefoniesoftware aufgrund der verschiedenen Anforderungen während des Betriebs eingestellt werden. Die verteilte Struktur des gesamten Anwendungssystems erfordert es, in dezentralen Umgebungen an mehreren Standorten zu konfigurieren. Dadurch wird es möglich, bei hoher Auslastung die Gespräche und die Gesprächsdaten von einem Standort an einen anderen umzuleiten.

4


4.3


1055

Wir gehen davon aus, daß wir aufgrund der beschriebenen Analyseund Entwurfskonzepte des WAM-Ansatzes eine anwendungsfachliche Gliederung eines Anwendungssystems in Werkzeuge, Automaten und Materialien gefunden haben. Als ein Beispiel kann das Anwendungssystem »Online Konfiguration eines Call Centers« dienen. Hier haben wir eine Reihe von Werkzeugen und Automaten identifiziert, die sich aus den Anforderungen eines Call Centers ergeben (z.B. Automaten zur Gesprächsverteilung). Die Werkzeuge wurden in getrennten Prozessen implementiert. Beispiele für Werkzeuge sind das Anmeldewerkzeug, Werkzeuge zum Anlegen und Verwalten der Benutzer, Werkzeuge zur Konfiguration des Servers und zur Anzeige des Server-Zustands. Das Anmeldewerkzeug unterstützt ausschließlich den Anmeldevorgang. Es soll ebenso wie die Werkzeuge zur Benutzerverwaltung auch in anderen Anwendungssystemen wiederverwendet werden.

Beispiel

Wenn wir eine mögliche Aufteilung der Anwendung in unterschiedliche Prozesse erwägen, dann kommen unterschiedliche Trennstellen in Betracht. Wir können an der Verbindung zwischen Werkzeug und Automat trennen. Betrachten wir beispielsweise die softwaretechnische Abbildung eines Telefongesprächs als Material, dann können das Werkzeug zum Editieren der Parameter dieses Telefongesprächs und

Prozeßtrennung

4

Telefoniesystem


4.3


der Automat, der die Telefongespräche verteilt, voneinander getrennt werden. Das Material wird vom Automaten an das Werkzeug gegeben und später zurückgesendet. Es gibt einige Argumente, Automaten getrennt von Werkzeugen in eigenen Prozessen anzusiedeln. Automaten bilden eigenständige Einheiten eines Anwendungssystems. Besonders technische Automaten modellieren Geräte, die von sich aus weitgehend eigenständig sind. Automaten müssen zudem teilweise technisch bedingt auf speziellen Maschinen laufen, die für Anwender an ungeeigneten Standorten stehen. Bestimmte Typen von Automaten kann es nur einmal in einem Unternehmen geben, wenn diese z.B. Datenbanken oder andere eindeutige Datenquellen verwalten. Schließlich verkörpern Automaten oft ein komplexes fachliches oder technisches Dienstleistungsangebot, das vielfach in unterschiedlichen Anwendungen wiederverwendet werden kann. Auch für die Trennung von Werkzeugen in eigenen Prozessen gibt es eine Reihe von Gründen. Werkzeuge können dadurch in anderen Kontexten wiederverwendet werden. Sie bilden ähnlich wie Automaten oft eine abgeschlossene Einheit und verkörpern eine komplexe Dienstleistung. Bestimmte Werkzeuge, wie z.B. das Anmeldewerkzeug, können unabhängig vom konkreten Einsatzkontext des Anwendungssystems

4

1056

Automaten in eigenen Prozessen

Werkzeuge in eigenen Prozessen


4.3


1057

verwendet werden. Werkzeuge agieren selten direkt mit anderen Werkzeugen. Das macht sie unabhängig. Schließlich können neue Werkzeuge innerhalb einer Arbeitsumgebung zu bestehenden Materialien hinzukommen. Wenn wir die verschiedenen Entwurfskomponenten auf ihre Eignung für eine Prozeßtrennung untersuchen, stellt sich natürlich auch die Frage nach den Materialien. Das wichtigste Argument gegen eine Separierung von Materialien ist, daß sie keine interaktiven Bestandteile haben. Ein Material wird immer von Werkzeugen und Automaten bearbeitet. Das erfordert eine enge Kopplung zum jeweiligen Werkzeug oder Automaten. Auch der Materialverwalter, der Material zur Verfügung stellt, ist in diesem Sinne ein Automat und damit ein potentiell eigenständiger Prozeß. Im Gegensatz zur Beziehung Automat-Werkzeug oder Werkzeug-Werkzeug sind Material und Werkzeug oder Material und Automat so eng gekoppelt, daß es enorm aufwendig wäre, Materialien von diesen in eigene Prozesse zu entkoppeln.

4

Warum nicht Materialien trennen?


4.3


1058

Kopplung im Mehrprozeßraum

Für die Aufteilung von Werkzeugen und Automaten in separate Prozesse benötigen wir eine Form der Kommunikation, die den bisher vorgetragenen Überlegungen entgegen kommt. Auf der technischen Ebene unterscheiden wir verschiedene Kommunikationsformen nach der Art ihrer Synchronisierung (vgl. [Kerner 89]): synchron und asynchron. Um die Unterschiede zwischen synchroner und asynchroner Kommunikation zu verdeutlichen, untersuchen wir eine Situation, bei der zwei Objekte in verschiedenen Prozessen so miteinander »kommunizieren«, daß ein Objekt eine Operation des anderen aufrufen will.

Problem

Bei synchroner Kommunikation wird die Kontrolle, die den Programmablauf im aufrufenden Objekt steuert, virtuell an den Zielprozeß abgegeben. Das heißt, daß der Kontrollfluß im aufrufenden Prozeß stehenbleibt und erst dann fortfährt, wenn das Ergebnis des Zielprozesses (ungeachtet eines eventuell auftretenden Fehlers) zurückgesandt wird.

Synchrone Kommunikation

4


4.3


1059

Synchrone Kommunikation: Eine (Interprozeß-) Kommunikation wird als synchron bezeichnet, wenn der Absender einer Nachricht so lange blockiert ist, bis der Empfänger die Verarbeitung bestätigt hat. Direkte Operationsaufrufe innerhalb eines Programms sind beispielsweise synchron.

Ein Beispiel für die Umsetzung des synchronen Kontrollflusses bei der Interprozeßkommunikation sind Remote Procedure Calls (RPCs, s. [Silberschatz & Galvin 94]). Hierbei werden durch Stellvertreterfunktionen oder Stellvertreterobjekte Operationen angeboten, die nicht im selben Prozeßraum verfügbar sind. Eine solche Operation wandelt nach ihrem Aufruf zunächst die Parameter in ein internes Format um und überträgt diese Daten über ein geeignetes Kommunikationsmedium zum Zielprozeß. Der Kontrollfluß des Prozesses, in dem die Operation aufgerufen wird, ist so lange angehalten, bis eine Antwort gesendet wird. Dabei kann die gerufene Operation dann auch ein Rückgabeergebnis liefern. Auch der CORBA-Ansatz (s. [OMG 95]) verwendet RPCs zur Realisierung der Verteilung. Bedingt dadurch ist die Anbindung der beteiligten Prozesse primär synchron.

4

Beispiel RPCs


4.3


1060

Ein Vorteil synchroner Kommunikation ist sicherlich, daß sich damit Konsistenzbedingungen leichter aufrecht erhalten lassen. Wird z.B. der Benachrichtigungsmechanismus zwischen zwei lose gekoppelten Objekten in unterschiedlichen Prozessen mittels RPCs durchgeführt, kann während der Sondierung davon ausgegangen werden, daß alle sondierten Werte in einem konsistenten Zustand sind, denn der Kontrollfluß im benachrichtigenden Prozeß setzt sich erst fort – und hat somit die Gelegenheit zur Veränderung –, wenn die Kontrolle aus dem benachrichtigten Prozeß zurückkehrt. Dies gilt nur unter der Voraussetzung, daß die Sondierung lokal erfolgt. Andernfalls entsteht über getrennte Prozesse eine Deadlock-Situation.

Vorteil synchroner

Gerade die Einfachheit der synchronen Anbindung ist auch für die Schwächen dieser Kommunikationsart verantwortlich:

Nachteile synchroner

Kommunikation

Kommunikation

❑ Verteilung ist implizit: Dem Entwickler wird nicht klar, welche

Objekte im selben Prozeß laufen und welche in entfernten Prozessen existieren. Dies erschwert das Verständnis des Programmverhaltens und die Behandlung von Fehlern (s.u.). ❑ Ausführungszeiten sind schlecht einzuschätzen: Die Benutzer-

interaktionen (vgl. [Oberquelle et al. 94]) können vom Entwickler nicht angemessen geplant werden, da zum Entwicklungszeitpunkt unklar ist, wie lange die Ausführung von Operationen dauert. Dafür ist die bereits genannte implizite Verteilung verantwortlich. 4


4.3


1061

❑ Fehlersituationen lassen sich schlecht behandeln: Da die Ver-

teilung durch RPC oder CORBA ohne Kenntnis der konkreten Anwendungssituation realisiert ist, sind auch nur allgemeine Ausfallmechanismen vorgesehen. Die synchrone Prozeßkopplung verbirgt die Verteilung, indem z.B. normale Operationsaufrufe durch automatisch erzeugte Kapseln ersetzt sind, in denen die Kommunikation abläuft. Jedoch sind aufwendige Mechanismen notwendig, wenn Kommunikation aus technischen Gründen versagt, weil sich innerhalb des vom Programmierer entwickelten Codes keine dafür vorgesehenen Behandlungen befinden. Das bedeutet insbesondere, daß der Anwendungsentwickler keine einfache Möglichkeit hat, Fehlersituationen in einem angemessenen Benutzungsmodell abzufangen. Einen weiteren Nachteil haben sowohl synchrone als auch asynchrone Kommunikationsmechanismen: Die Verwaltung der Verteilung auf der Metaebene kostet Aufwand. Obwohl der synchrone Aufruf entfernt realisierter Operationen z.B. durch das CORBA-Rahmenwerk fast vollständig gekapselt werden kann, müssen trotzdem zusätzliche Programmteile entwickelt werden. Jeder Kommunikationsprozeß muß um zusätzliche Fallunterscheidungen für die Verwaltung der

4


4.3


1062

kommunikationsbedingten Ausnahmesituationen ergänzt werden. Der Kommunikationspartner muß eventuell ausgewählt und gefunden werden. Die Kommunikation kann unterbrochen sein und muß dann wieder aufgenommen werden. Das synchrone Kommunikationsmodell hat trotz seiner Einfachheit offenbar Nachteile, die aus der impliziten Realisierung von Verteilung entstehen. Wir haben schon in Kapitel 4.1 Wert darauf gelegt, daß Verteilung und Kooperation im Benutzungsmodell explizit gemacht werden. Ähnliches gilt auch für unser Implementationsmodell. Wir wollen sichtbar machen, welche Objekte für lokale Exemplare stehen und welche aufgrund von Verteilung über Interprozeßkommunikation entfernte Exemplare vertreten. Offenbar beeinflußt die Wahl des Verteilungsmodells nicht nur das Implementationsmodell, sondern wirkt sich bis hin zum Benutzungsmodell aus. Als Alternative zum synchronen Kommunikationsmodell betrachten wir deshalb die asynchrone Kommunikation.

Diskussion

Das asynchrone Kommunikatonsmodell umfaßt alle Formen des Kontrollflusses, bei denen mehrere Prozesse quasi oder real nebeneinander ausgeführt werden. Beim asynchronen Kontrollfluß wird die Kontrolle bei der Kommunikation zwischen zwei Prozessen nicht an den jeweils anderen Prozeß abgegeben. Vielmehr läuft der Kontrollfluß im aufru-

Asynchrone

4

Kommunikation


4.3


1063

fenden Prozeß ohne zeitliche Verzögerung weiter. Sowohl Sender als auch Empfänger besitzen zusätzliche Ereignismechanismen, durch die sie über eintreffende Nachrichten oder Ereignisse informiert werden. Asynchrone Kommunikation: Eine (Interprozeß-) Kommunikation wird als asynchron bezeichnet, wenn der Absender einer Nachricht seinen Kontrollfluß sofort nach dem Aufruf der entsprechenden Operation fortsetzen kann, ohne daß die Verarbeitung auf der Empfängerseite abgewartet werden muß. Bei einem Telefongespräch können beispielsweise beide Partner jederzeit reden.

Asynchrone Kommunikationsmechanismen werden von jedem modernen Betriebssystem angeboten und genutzt. So finden sich asynchrone Kontrollflüsse zum Beispiel bei multithreaded Programmen, in denen Teile des Algorithmus parallel implementiert sind. Man spricht von einem Thread (oder »light weight process«) im Gegensatz zu einem Prozeß, wenn zwei Threads denselben Adreßraum benutzen, während Prozesse jeweils einen getrennten Adreßraum verwenden (vgl. [Silberschatz & Galvin 94]). Threads können auf gemeinsame Variablen zugreifen; was bei Prozessen nicht möglich ist. Der Einfachheit halber sprechen wir im weiteren nur von »Prozeß«, wenn Threads und Prozesse unterschiedslos gemeint sind. 4


4.3


1064

Beim preemptive Multitasking auf einem Prozessor wird der notwendige Wechsel des Kontrollflusses zwischen den Prozessen direkt vom Betriebssystem nach Ablauf einer gewissen Zeitspanne durchgeführt oder explizit vom Programm vorgegeben. Die Kommunikation zwischen Prozessen kann über Semaphoren erfolgen, wenn eine Synchronisation erforderlich ist. Prozesse können aber auch, wie in Fenstersystemen üblich, eine Ereignisschlange verwenden, die von einem Dispatcher verwaltet wird. Jeder Prozeß stellt seine Ereignisse mit Ereignistyp, Absender, Empfänger und gegebenenfalls Ereignisdaten in die Ereignisschlange ein. Der Dispatcher gibt die Kontrolle z.B. immer an denjenigen Prozeß, für den das aktuelle (Fenstersystem-) Ereignis bestimmt ist. Verliert dieser Prozeß die Kontrolle, wird der Prozeß aktiviert, für den das nächste Ereignis der Schlange bestimmt ist. Der aktive Prozeß kann selbst neue Ereignisse in die Schlange einstellen. Diese werden allerdings erst bearbeitet, wenn alle anderen Ereignisse, die vorher in der Schlange standen, abgearbeitet worden sind. Alternativ gibt es prioritätsorientierte Verfahren, bei denen bestimmte Prozesse oder Ereignisse bevorzugt werden. Der Mechanismus eines asynchronen Kommunikationssystems ist durchaus dem synchronen vergleichbar. Die Kommunikation wird zwischen zwei Partnern dadurch aufgebaut, daß der Sender die Para-

4


4.3


meter eines Operationsaufrufs in geeigneter Weise umwandelt und an das Kommunikationssystem übergibt und von diesem eine Quittung über die Annahme erhält. Der Kontrollfluß fährt im Sender fort. Zeitlich versetzt erhält der Empfänger die Parameter und kann sie (nun synchron) verarbeiten. Zu einem frei gewählten Zeitpunkt (z.B. zu Beginn oder am Ende der Verarbeitung) kann der Empfänger eine Antwort an den Sender schicken, die ebenso über das Kommunikationssystem vermittelt wird. Die asynchrone Kommunikation zwischen verschiedenen Prozessen erfordert zusätzliche Synchronisationsmechanismen. Operationsaufrufe, die synchron auf einfache Weise Rückgabeergebnisse liefern, müssen asynchron aufgeteilt werden: Der Aufruf der Operation und die Rückgabe eines Ergebnisses sind zeitlich getrennt. Zwar wird durch das Kommunikationssystem die Beziehung zwischen den Partnern hergestellt, für das Implementationsmodell bedeutet dies aber eine Entwicklung von der prozedural-ablauforientierten zur ereignisorientierten Programmierung. Für die interaktiven Komponenten innerhalb des WAM-Ansatzes haben wir dies bereits gezeigt: Werkzeuge werden durch die Aktionen des Benutzers über System- und Programmereignisse gesteuert. Wir erweitern nun dieses Prinzip für die Anbindung anderer Prozesse.

4

1065

Ereignisgesteuerte Programmierung


4.3


Die zunächst negativen Konsequenzen der asynchronen Kopplung von Prozessen lassen sich folgendermaßen zusammenfassen:

1066 Nachteile asynchroner Kommunikation

❑ »Weiche« zeitliche Annahmen über die Ausführung eines Ope-

rationsaufrufs sind möglich, d.h., der Entwickler kann keine festen Annahmen über die Antwort auf einen Operationsaufruf machen: Verändernde Prozeduren haben nicht sofort ihre verändernde Wirkung; sondierende Funktionen liefern nicht immer das aktuellste Ergebnis. ❑ Explizite Handhabung der Verbindung zwischen Prozessen ist

notwendig, d.h., der Entwickler muß selbst für Aufbau, Abbau und Fehlerbehandlung im Kommunikationsprozeß sorgen. Jede Operation kann potentiell zu einem Fehler führen, der nicht im fachlichen oder programmlogischen Bereich angesiedelt ist, sondern durch die Kommunikation verursacht wird. ❑ Antworten können ausbleiben, d.h., für diesen Fall muß der

Entwickler Vorkehrungen treffen. Wenngleich die hier aufgeführten Konsequenzen im allgemeinen als Nachteile aufgefaßt werden, können wir sie auch als Vorteil betrachten, da der Anwendungsentwickler explizit Situationen vorhersehen muß, die in verteilten Systemen prinzipiell unvermeidbar sind. Die explizite Reaktion auf solche Situationen ermöglicht softwaretechnisch und anwendungsorientiert bessere Programme.

4


4.3


Vorteile der asynchronen Kommunikation sind:

1067 Vorteile asynchroner

❑ Im Implementationsmodell wird die Verteilung deutlich.

Kommunikation

❑ Der asynchrone Mechanismus ermöglicht nach einem Aufruf

eines entfernten Prozesses das Weiterarbeiten des Benutzers, auch wenn dies oft nur fachlich beschränkt möglich ist. ❑ Die asynchrone Prozeßkopplung ermöglicht, Prozesse ohne

zwingendes Blockieren parallel auszuführen. ❑ Die Fehlerbehandlung kann als Bestandteil der fachlichen und

technischen Umsetzung im Entwurfsmodell eingebettet werden. Entscheidend für die Verwendung der asynchronen Kommunikation ist, daß der Entwickler das grundlegende Prinzip verstanden hat und im gesamten Modell des Anwendungssystems berücksichtigt. Sowohl im Benutzungs- als auch im Implementationsmodell muß klar werden, daß Aktionen und zugehörige Reaktionen oder Ereignisse zeitlich viel stärker entkoppelt sind als im synchronen Modell. Unsere Erfahrungen aus Kooperationsprojekten zeigen aber, daß gerade bei technisch eingebetteten Anwendungssystemen die asynchrone Kommunikation erfolgreich und mit deutlichen Vorteilen gegenüber der synchronen eingesetzt werden kann.

4


4.3


1068

Ein Architekturmodell für Mehrprozeßräume

Wir haben zu Beginn von Kapitel 4.3.3 eine fachliche Aufteilung von Einstellwerkzeug und Automat vorgestellt. Im folgenden untersuchen wir diese Aufteilung in einem Mehrprozeßraum. Dabei werden zuerst Werkzeug und Automat in getrennten Prozessen angesiedelt und dann werden die Werkzeuge selbst verteilt.

Einordnung

Mehrprozeßraum: Unter einem Mehrprozeßraum verstehen wir den fachlichen und technischen Raum, den ein Anwendungssystem aufspannt, wenn dessen Werkzeuge und Automaten in unterschiedlichen Prozessen laufen, die durch ein Kommunikationsmedium miteinander verbunden sind. Wir gehen davon aus, daß die Verteilung der Komponenten in diesem Raum dabei sowohl im Entwurfsmodell als auch im Implementationsmodell explizit ist.

Die Trennung der Komponenten in einem Mehrprozeßraum erfordert andererseits ein Kopplungskonzept, das über die bisher in Kapitel 3.2 beschriebenen Ansätze hinausgeht. Wir sprechen in diesem Zusammenhang von asynchroner Kopplung.

4


4.3


1069

Asynchrone Kopplung: Unter asynchroner Kopplung verstehen wir die Verbindung zweier Objekte über ein asynchrones Kommunikationsmedium in einem Mehrprozeßraum. Wir unterscheiden drei Varianten: ❑ Aufruf ohne Erwartung eines direkten Ergebnisses, ❑ Aufruf unter Erwartung eines (direkten) Ergebnisses, ❑ abstrakte Kommunikation nur über Ereignisse. Bei einem asynchronen Kommunikationsmedium muß stets die Möglichkeit von Verbindungsfehlern berücksichtigt werden. Deshalb benötigen wir Kopplungsinformationen auf der Metaebene.

Die drei Varianten der asynchronen Kopplung benutzen wir bei der Verteilung von Werkzeugen und Automaten. Nach der bisher vorgestellten Musterarchitektur wurden Werkzeuge mit den Sonden von Automaten über das Beobachtermuster (s. Kapitel 3.2.3) verbunden. Das Werkzeug kennt die Schnittstelle der Sonde (und die des Automaten) vollständig; die Sonde verwendet hingegen eine abstrakte Schnittstelle, um Ereignisse auslösen oder versenden zu können.

4

Genese der Prozeßtrennung


4.3


1070

Wir wollen nun den Automaten und die Sonden in einem vom Werkzeug separaten Prozeß betreiben. Dies realisieren wir schrittweise mit Hilfe des Proxy-Musters, das hier in der Form des Remote Proxy (vgl. [Gamma et al. 96]) verwendet wird. 1. Schritt

2. Schritt

WerkzeugIAK

WerkzeugIAK

WerkzeugFK

Automat (fachlich)

3. Schritt

Abb. 4-30 Schrittweise Trennung von Werkzeug und Automat in separate Prozesse 4. Schritt

Wz-Fk

Wz-Fk

AutomatenProxy

AutomatenProxy

Broker

Broker

Wz-Fk Beobachter

Automat (fachlich)

Beobachter-Proxy

Entry Beobachter-Proxy

Automat (technisch) Legende

Automat

Automat

(fachlich)

(fachlich)

Benutzt-Beziehung Eingeschr. Benutzt-Beziehung Prozeßgrenze

4


4.3


1071

Abbildung 4-30 zeigt von links nach rechts die schrittweise Entwicklung vom Einzelprozeß zu einem Mehrprozeßraum. Dabei kennzeichnen die Pfeile mit den gestrichelten Linien die lose Kopplung nach dem Beobachtermuster: ❑ Schritt 1 zeigt nochmals die grundlegende fachliche Architek-

tur von Werkzeug, Automat und Sonde. ❑ In Schritt 2 haben wir die Werkzeug-FK (Wz-FK) in die zwei

relevanten Objektteile aufgetrennt: die Implementation des Beobachter-Protokolls und die restliche Werkzeug-FK. Nun können wir die Verwendung des Automaten als zwei separate Benutzt-Beziehungen interpretieren. ❑ In Schritt 3 modellieren wir die Prozeßtrennung über zwei Pro-

xies. Das jeweils im anderen Prozeß untergebrachte Objekt wird durch ein Proxy ersetzt. Ein Automaten-Proxy mit einer Reihe von Sonden-Proxies befindet sich im Werkzeugprozeß, da die Werkzeug-FK die volle Schnittstelle des Automaten und der Sonden benutzt. Im Automatenprozeß ist ein BeobachterProxy, das von den Sonden benutzt wird. ❑ In Schritt 4 betrachten wir genauer, wie die Werkzeug-FK mit

dem Automat und den Sonden verknüpft wird. Wir unterscheiden zwischen Erzeugung und Registrierung. Die Erzeugung des Automatenprozesses setzen wir hier einmal voraus. Durch die

4


4.3


1072

Registrierung meldet sich das Werkzeug bei den Sonden für Ereignisse an, die über Zustandsveränderungen informieren. Das Objekt, bei dem sich ein Klient an einem Automaten für 16 Ereignisse registriert, nennen wir Entry . Dieser Teil der Schnittstelle muß immer existieren, damit die Kommunikation aufgebaut werden kann. Das Entry-Objekt stellt einen solchen Mechanismus zur Verfügung. Alle einstellenden Operationen, die das Werkzeug am Automat ausführen will, werden mittels des Automaten-Proxy an den Entry des Automatenprozesses gesendet. Der Entry ruft die entsprechende Operation am Automaten auf. Ein aufgetretener Fehler kann direkt an den Absender gemeldet werden. Alle Beobachter werden bei einer Zustandsänderung des Automaten benachrichtigt. In diesem Modell steht das Automaten-Proxy für die Verbindung zwischen den beiden Prozessen auf der Seite des Werkzeugs. Zur Reduzierung von Verbindungen und deren Überwachung werden keine separaten Verbindungen zwischen allen Sonden und den korrespondierenden Proxies erzeugt. Das Automaten-Proxy bündelt diese Kommunikation. 16. engl. für Eingang, Eingangstür

4


4.3


Fassen wir die vier Schritte zusammen:

1073 Zusammenfassung

❑ Auftrennung der Objektbeziehung auf die benutzten Schnitt-

stellen. ❑ Ersetzung der Objekte durch ein Proxy auf jeder Seite. ❑ Bereitstellung eines Entry zur initialen Verknüpfung. ❑ Realisierung der Einstellungen im Entry und der Benachrichti-

gungen im Beobachter-Proxy. Offensichtlich kommt in diesem Architekturmodell dem ProxyMuster eine zentrale Stellung zu. Wir haben dadurch die an der Kopplung beteiligten Objekte in verschiedene Prozesse aufteilen können und deren relevante Anteile jeweils durch lokale Objekte ersetzt. Im weiteren zeigen wir, daß diese Anwendung des Proxy-Musters nicht vollständig ausreicht, um alle Anforderungen an reale Anwendungen zu erfüllen. Um die Kommunikation überhaupt aufbauen zu können, muß der initiierende Prozeß wissen, mit welchem anderen Prozeß er kommunizieren möchte, um einen gewissen Dienst nutzen zu können.

4

Problem: Prozesse finden


4.3


Prozesse sind im lokalen Prozeßraum nur über ihre Prozeß-ID bekannt. Diese wird vom Kommunikationssystem bei jedem Start neu vergeben. Deshalb spezifizieren wir Dienstnamen. Es gibt einen ausgezeichneten Prozeß, den sogenannten Nameserver, bei dem sich Prozesse registrieren können, wenn sie den von ihnen angebotenen Dienst namentlich veröffentlichen wollen. Die Prozeßnummer des Nameserver steht fest. Der initiierende Prozeß fragt den Nameserver nach einem Dienst, indem er dessen Namen angibt. Er erhält die Prozeß-ID, wenn ein Prozeß unter diesem Namen registriert ist.

1074 Lösungsansatz

Nameserver: Mit Hilfe eines (lokalen) Nameserver werden die vom System vergebenen Prozeß-IDs durch Namen ersetzt. Prozesse können den Nameserver unter Angabe eines Namens nach einer Prozeß-ID fragen. Jeder Prozeß kann sich unter beliebig vielen verschiedenen Namen mit seiner Prozeß-ID beim Nameserver registrieren.

Durch die Abstraktion von den konkreten technischen Prozeß-IDs mit Hilfe des Nameserver können wir frei zugewiesene Prozeß-IDs verwenden. Alle Nachteile, die durch fest gewählte Prozeß-IDs entstehen (z.B. versehentliche Doppelbelegung, Notwendigkeit eines Neustarts des gesamten Rechners wegen eines fehlerhaften Prozesses) sind damit im lokalen Bereich beseitigt. 4


4.3


1075

Außerdem ist die Kommunikation nun auf der Ebene von Diensten und nicht von Prozessen möglich. So können wir die Entscheidung, in welchem Prozeß ein Dienst implementiert ist, bis zur Laufzeit hinauszögern. Werkzeug – Automat Wie sieht das Zusammenspiel von Werkzeug und Automat nach Einführung des Nameserver aus? Wir gehen davon aus, daß der Automatenprozeß bereits gestartet ist und sich beim Nameserver unter seinem Dienstnamen registriert hat. Das Werkzeug ermittelt nun wie beschrieben seinen Kommunikationspartner. Zur Kommunikation mit dem Automaten und dem Nameserver verwendet das Werkzeug ein entsprechendes Automaten-Proxy, in dem diese Kommunikation gekapselt ist. Daher muß das Werkzeug die technische Kommunikationsschnittstelle des Automaten nicht kennen. Lediglich die Schnittstelle des Proxy ist relevant. Diese ist aber, entsprechend der Idee eines Proxy, zunächst identisch mit der fachlichen Automatenschnittstelle, wenn dieser Automat im selben Prozeß wie das Werkzeug laufen würde.

4


4.3


1076

Bei genauer Betrachtung zeigt sich aber, daß dieses Prinzip der fachlichen Übereinstimmung von Proxy- und Automatenschnittstelle nicht mehr aufrecht erhalten werden kann. Dies wird an den Funktionen einer Schnittstelle besonders deutlich. Eine Funktion des Automaten und somit des Automaten-Proxy bedeutet, daß nach dem Aufruf ein Rückgabewert erwartet wird. Dies ist aus den vorangegangenen Überlegungen in Mehrprozeßräumen aber nicht sinnvoll. Um zu verdeutlichen, daß wir prinzipiell innerhalb eines Mehrprozeßraumes entwerfen, ändern wir funktionsorientierte Schnittstellen in ereignisorientierte ab. Daher unterteilen wir die Schnittstelle des Automaten-Proxy in drei Teile: ❑ einstellende Operationen, ❑ sondierende Operationen, ❑ Benachrichtigungen über den Zustand des Proxy nach dem

Beobachtermuster. Dazu stehen Ereignisse bereit, die Auskunft über unterschiedliche Teile des Zustandsraums eines Automaten geben.

4


4.3


1077

Wir entwickeln ein Proxy in folgenden konzeptionellen Schritten: ❑ Entwurf des Proxy als Substitut für ein Objekt in einem ande-

ren Adreßraum. ❑ Reduktion der Schnittstelle des Proxy gegenüber dem vollen

Funktionsumfang des Automaten auf die in diesem abgegrenzten Fall notwendige Funktionalität. ❑ Kopplung der Funktionskomponente und des Automaten-

Proxy über das Beobachtermuster mit lokaler Sondierung des Automatenzustands. ❑ Einführung von zusätzlichen Meta-Ereignissen zur Signalisie-

rung des Verbindungszustands. Besonders wichtig sind die beiden letzten Punkte. Das AutomatenProxy und die zugehörigen Sonden bilden den Zustand des Automaten lokal ab. So kann eine konsistente Sondierung sichergestellt werden. Da nur die beim Automaten registrierten Sonden abgebildet werden, erhöht diese Konstruktion den Speicherverbrauch nur minimal. Das Protokoll zwischen Automaten-Proxy und Funktionskomponente wird deshalb um Meta-Ereignisse ergänzt, da bei der Kommunikation Verbindungsabbrüche auftreten können (siehe S. 536ff.).

4


4.3


1078

Das Interaktionsdiagramm in Abbildung 4-31 zeigt, wie Werkzeug und Automaten mit den beschriebenen Komponenten in unterschiedlichen Prozessen zusammenspielen. Wir haben das Diagramm um zwei Elemente erweitert: Die Objekte eines Prozesses sind am oberen Rand durch Klammern zusammengefaßt. So können mehrere kommunizierende Prozesse in einem Diagramm dargestellt werden.

Interaktionsdiagramme für

4

Interprozeßkommunikation


4.3


1079

Prozeß WerkzeugFK

Lokaler Broker

AutomatenProxy

Entry Beobachter- Automat Proxy

register() SendEvent()

1. Anmeldung

Event

constructor()

Event

Ändere Einstellungen()

Quittung

2. Einstellen

Ändere Einstellung() SendEvent()

Sonde

Quittung

AutomatenProxy

tell() Event

Sonde

Sondierung

ReceiveEvent()

3. Mitteilung

produzierte Werte

tell()

Sondierung

Abb. 4-31 Asynchrone Kommunikation zwischen Werkzeug und Automat

4


4.3


1080

Zusätzlich haben wir ein Broker-Objekt eingeführt, das die Interprozeßkommunikation deutlich macht. Broker: Unter einem Broker verstehen wir eine Instanz, der von einem Prozeß Botschaften übergeben werden können, damit diese an einen anderen Prozeß weitergeleitet werden.

Die Abbildung 4-31 zeigt folgende Zusammenhänge: ❑ Anmeldung: Die Funktionskomponente registriert sich über

das Proxy beim entfernten Automaten. Dieser asynchrone Vorgang erfolgt mit zeitlicher Verzögerung. Der Automat empfängt eine Aufforderung zur Registrierung. Daraufhin erzeugt dieser dafür ein Beobachter-Proxy. Ist die Registrierung technisch nicht möglich, weil z.B. die Netzwerkkommunikation zusammenbricht, wird der Klientenprozeß über den Fehler benachrichtigt. Das geschieht nach Ablauf einer systembedingten Zeitspanne (Timeout) durch eine Fehlermeldung des Kommunikationssystems an das Proxy-Objekt. Das Proxy setzt den Fehler in ein Ereignis zum Kommunikationsstatus um. Hat sich die Funktionskomponente für das entsprechende Ereignis registrieren lassen (s. S. 258ff.), kann sie nun geeignet darauf reagieren. 4


4.3


1081

❑ Einstellen: Die Funktionskomponente stellt den Automaten

ein. Dazu ruft sie die entsprechende Operation am Proxy auf. Das Proxy erstellt daraus ein Datenpaket und versendet dies über das Kommunikationssystem. Der Kontrollfluß kehrt in die Funktionskomponente zurück. Zeitlich versetzt wird das Datenpaket dem Entry des Automaten zugestellt. Dort wird es in einen Operationsaufruf am Automaten umgewandelt. Dieser nimmt gegebenenfalls die geforderten Einstellungen vor. Der Kontrollfluß kehrt über das Entry-Objekt in das Kommunikationssystem zurück. Wenn mehrere Klienten auf diese Weise mit dem Automaten kommunizieren, werden die Aufforderungen zur Einstellungsänderung durch das Kommunikationssystem serialisiert. Jede erfolgreiche Änderung führt zu einer Benachrichtigung über eine Zustandsveränderung. Die Ausführung aller Änderungen hintereinander bestimmt den letzten Zustand, der jedem Klienten mitgeteilt wird. Damit wird das grundlegende Konstruktionsprinzip gewahrt, daß alle interessierten Werkzeuge von einer Veränderung des Materials (hier: des Automaten) informiert werden.

4


4.3


1082

❑ Mitteilung: Der Automat hat seinen Zustand verändert. Da er

ein selbständiges technisches Gerät repräsentiert, kommt diese Situation häufig vor. In diesem Fall wird eine entsprechende Sonde über die Zustandsveränderung informiert. Die Sonde benachrichtigt das Beobachter-Proxy über die Zustandsänderung. Nachdem das Beobachter-Proxy sich mit den aktuellen Zustandsinformationen versorgt hat, setzt es diese zu Parametern um und übergibt sie an das Kommunikationssystem. Dann kehrt die Kontrolle zur Sonde zurück. Zeitlich versetzt signalisiert das Kommunikationssystem dem Automaten-Proxy den Empfang von Daten. Das AutomatenProxy kapselt die Umwandlung der »Datenpakete« des Kommunikationssystems, interpretiert den Inhalt und ändert seinen internen Zustand. Diese Zustandsveränderung gibt das Automaten-Proxy auch an die »zuständigen« Sonden weiter. Diese benachrichtigen alle beobachtenden lokalen Objekte, z.B. die Werkzeug-FK. Diese kann sowohl die Sonde als auch den Automaten sondieren, denn das aktuelle Abbild des Automatenzustandes ist in beiden Objekten entsprechend vorhanden. Dieser gesamte Vorgang der Benachrichtigung und Sondierung kann auf der Seite des Werkzeugprozesses als synchrone Kommunikation verstanden werden, die alle geforder-

4


4.3


1083

ten Konsistenzkriterien gewährleistet. Danach kehrt die Kontrolle über Sonde und Automaten-Proxy in das Kommunikationssystem zurück. Jetzt kann die Kontrolle über das Fenstersystem wieder an den Benutzer des Werkzeugs zurückgegeben werden. Die hier vorgestellte Mehrprozeßraum-Architektur bietet die Möglichkeit, in einem Prozeß sowohl reaktiv Benutzereingaben abzuarbeiten als auch gleichzeitig neue Automatenzustände weiterzuleiten. In den Micrologica-Projekten wurde dies durch eine spezielle Integration der Ereignisse in die Event Queue des Fenstersystems realisiert.

4


4.3


1084

Automatenprozeß

Werkzeugprozeß Werkzeug-FK

Automat

4

ChangeValue()

7

0

8

ChangeValue()

Automaten-Proxy SendPackage()

Entry

3 6 ReceivePackage()

1

Broker-Proxy

9

Broker-Proxy 10

5 SendEvent()

ReceiveEvent()

Broker-Prozeß 2

Event Queue

Event

Event

Call Return from Call

Abb. 4-32 Asynchrone Prozeßkommunikation an einem Ablaufbeispiel

4


4.3


Abbildung 4-32 zeigt nochmals exemplarisch, wie der Kontrollfluß innerhalb der drei an der Kommunikation beteiligten Prozesse verläuft. Die mit runden Linien abgegrenzten Bereiche stellen jeweils separate Prozesse dar.

1085 Beispiel

Werkzeug – Werkzeug Nach der Diskussion der Trennung von Werkzeug- und Automatenprozeß skizzieren wir eine mögliche Prozeßtrennung zwischen Werkzeugen innerhalb eines Anwendungssystems. In Kapitel 3.2.5 haben wir die Konstruktion von Sub- und Kontext-Werkzeugen und die lose Kopplung der Werkzeuge über die Umgebung beschrieben. In beiden Fällen können wir überlegen, ob die Möglichkeiten der asynchronen Prozeßkopplung genutzt werden sollen. Nach unserer Erfahrung ist die Prozeßtrennung von Kontext- und Sub-Werkzeugen nicht sinnvoll. Dagegen sprechen die geforderte Effizienz und die enge fachliche Bindung. Im allgemeinen sind z.B. Kontext-FK und Sub-FKs so eng miteinander verknüpft, daß die KontextFK nicht ohne die Existenz der Sub-FKs arbeiten kann. Dies läßt sich im Mehrprozeßraum nicht garantieren. Wir haben daher in unseren Projekten bisher darauf verzichtet, eine Prozeßtrennung von Kontextund Sub-Werkzeugen zu realisieren.

4


4.3


1086

Werkzeuge können indirekt über den Materialverwalter und den Materialversorger gekoppelt werden. Wenn unterschiedliche Werkzeuge dasselbe Material verwenden, werden sie gegenseitig über diesen Mechanismus von Materialveränderungen informiert (s. Kapitel 3.2.6). Diese Art der Kommunikation wird von dem hier vorgestellten Modell unterstützt, da Materialverwalter und -versorger beides Automaten sind. Da die Verknüpfung von Werkzeug- und Automatenprozessen gelöst ist, kann auch die indirekte Kommunikation von einem Werkzeug über einen Automat zu einem anderen Werkzeug realisiert werden. Bleibt die Frage, ob Werkzeuge und Ereignisverwalter einer Umgebung in unterschiedlichen Prozeßräumen laufen können. Obwohl wir diese Variante bisher nur prototypisch realisiert haben, bietet sich eine analoge Lösung zu der hier vorgestellten Konstruktion an. Ein zentraler Ereignisverwalter kann seine prozeßlokalen Entsprechungen haben, über die sich die verteilten Werkzeuge verständigen. Fehlerbehandlung Bei der synchronen Kopplung von Komponenten ist die Fehlerbehandlung in klar getrennte Bereiche unterteilbar. Ein schwerwiegender und systembedingter Fehler ist z.B. der mißlungene Versuch, ein neues Objekt zu erzeugen. Programmbedingte Fehler sind die Verletzungen

4

Kontext


4.3


1087

des Vertragsmodells (s. Kapitel 2.1.10) bei der Ausführung einer Operation. Diese Fehler können mit geeigneten Strategien behandelt werden (vgl. [Meyer 97]). Durch Mehrprozeßräume kommt eine weitere Fehlerdimension hinzu, die sich nicht auf dieselbe Weise angehen läßt. Es gibt grundsätzlich keine Garantie dafür, daß eine bisher als gesichert geltende Verbindung zwischen zwei Prozessen beim nächsten Kommunikationsversuch noch funktionsfähig ist. Unterschiedliche Ursachen kommen für diese potentielle Instabilität in Frage: Zum einen ist ein System aus Treibern, Prozessen und Dynamic-Link-Libraries für die Verbindung verantwortlich, welches insgesamt fehleranfällig ist. Andererseits basiert jedes Kommunikationsmedium auf Hardwarekomponenten, deren Stabilität und Qualität nur bedingt kontrollierbar sind. Diese Unberechenbarkeit eines Mehrprozeßraumes erfordert eine andere Strategie für die Behandlung von Kommunikationsfehlern als für synchrone Einprozeßsysteme. In einem Mehrprozeßraum kann es also passieren, daß die durch ein Proxy gekapselte entfernte Komponente nicht mehr erreichbar ist, weil sie nicht mehr existiert oder weil das Netzwerk, über das der Prozeß mit ihr verbunden war, defekt ist. In diesem Fall wird der Broker

4

Problem


4.3


1088

einige Versuche unternehmen, die Kommunikation wiederherzustellen, bevor er den Botschaftenversand als »nicht erfolgreich verschickt« an den Absender mit einem Fehlerstatus zurückmeldet. Charakteristisch für diese Fehlerart ist die zeitliche Verzögerung, mit der Fehler gemeldet werden. Während z.B. bei Speichermangel das fehlgeschlagene Erzeugen eines neuen Objektes sofort als Fehler gemeldet wird, muß in asynchronen Prozessen der aufrufende Kontext so lange aufbewahrt werden, bis eine positive Bestätigung, eine Fehlermeldung des Kommunikationsmediums oder eine Zeitüberschreitung gemeldet wird. Ein Timer (Zeitgeber) ist also im dritten Falle notwendig, damit kein unzumutbares Warten oder eine Verklemmung bei der Kommunikation zweier Prozesse auftritt. Für jede Kommunikation muß deshalb ein zeitlicher Schwellenwert definiert werden. Wird dieser Schwellenwert überschritten, gilt die Interprozeßkommunikation als gescheitert, auch wenn sie potentiell noch zustande kommen könnte. Diese Absicherung der Kommunikation ist im vorstehenden Beispiel besonders bei einstellenden Methoden am Automaten notwendig. An dieser Stelle muß auch im Benutzungsmodell deutlich werden, daß es sich um verteilte Komponenten handelt. Damit der Benutzer geeignet auf die abgebrochene oder unterbrochene Kommunikation

4

Lösung Schwellenwerte


4.3


1089

reagieren kann, ist natürlich ein passendes Implementationsmodell notwendig, das schon beim Entwurf der Klassen berücksichtigt werden muß. Die technische Fehlerbehandlung bei Mehrprozeßräumen geschieht auf zwei Stufen. Die erste Stufe umfaßt die synchronen Teile, in denen z.B. die Anfrage an eine entfernte Komponente formuliert wird. Die zweite Stufe ist danach angesiedelt; hierzu wird jede Fehlersituation gezählt, die erst asynchron, d.h. verzögert, erkannt werden kann. In Stufe 1 kann eine Rückmeldung sofort erfolgen. Bereits bei der Übergabe der Anfrage an den Broker steht fest, ob der Auftrag überhaupt entgegen genommen wird. In Abbildung 4-32 wird also bereits bei Aufruf (2) festgestellt, daß der Partner nicht verfügbar ist. Deshalb liefert das Broker-Proxy in (3) ein Fehlerereignis zurück, das vom Automaten-Proxy in (4) sofort an den Aufrufer signalisiert wird. In allen anderen Fällen, wenn also die Anfrage vom Broker entgegengenommen ist, verwenden wir einen Timer. Dieser definiert den Schwellenwert, wann eine Kommunikation als nicht erfolgreich gilt. Das führt zu einem Abbruchauftrag an das Kommunikationssystem. Darüber hinaus wird im Broker-Proxy die Verbindung zum Partner als getrennt markiert, der dies allen Beobachtern meldet.

4

Technische Lösungsansätze


4.3


1090

Daher ist es notwendig, daß sich alle Komponenten, die Partner einer Interprozeßkommunikation sind, auch für Ereignisse, die diese Kommunikation betreffen, registrieren lassen und darauf angemessen reagieren. In unseren Projekten hat sich übrigens gezeigt, daß die Art und die Realisierung der Verteilung (z.B. durch Hochgeschwindigkeitsnetze oder in einem Mehrprozeßrechner) keinen Unterschied für die Fehlerbehandlung macht. Auch lokale Netze können inakzeptable Antwortzeiten bieten, wenn die Netzlast über ein bestimmtes Maß wächst. Deshalb sollte der Schwellenwert des Timers ausschließlich von der akzeptablen Antwortzeit und nicht von der technischen Netzrealisierung abhängig gemacht werden. Der Schwellenwert der eingesetzen Timer kann entsprechend dem Einsatzkontext vom Entwickler eingestellt werden. Dazu lassen sich selbst wieder Einstellwerkzeuge konstruieren, die sich zur Präsentation der Werte und für die Fehlerbehandlung eignen. Das Timer-Konzept kann in einfacher Form direkt im BrokerProxy realisiert werden. Dazu führt das Broker-Proxy zu jeder weitergereichten Anfrage oder Botschaft einen Eintrag in einer Tabelle. Dort ist auch vermerkt, bis zu welchem Zeitpunkt eine Antwort erwartet wird. In zyklischen Abständen wird diese Tabelle nach Einträgen durchsucht, die bereits abgelaufen sind. In diesen Fällen wird das

4


4.3


1091

Kommunikationspaket vom Kommunikationssystem zurückgefordert. Dann teilt das Proxy dem Absender der Botschaft oder Anfrage mit, daß der Schwellenwert überschritten ist. Das Benutzungsmodell für die reibungslose und rasche asynchrone Kommunikation in Mehrprozeßräumen muß sich nicht wesentlich von der synchronen in einem Einprozeßsystem unterscheiden. Die Behandlung von Kommunikationsfehlern folgt bekannten Prinzipien. Der Benutzer wird meist über ein modales Dialogfenster informiert, daß eine Anfrage nicht beantwortet werden konnte, weil eine entfernte Komponente nicht mehr erreichbar ist. Es hat sich als sinnvoll erwiesen, den »Netzstatus« bei häufig verwendeten entfernten Komponenten zu symbolisieren. Dazu eignen sich Einträge in einer Statuszeile oder kleine Piktogramme, die ihr Aussehen je nach Zustand wechseln. Ähnliche Möglichkeiten bestehen, um die Zeitverzögerung eines Kommunikationsvorgangs zu vergegenständlichen. Auch hier hilft ein Statuszeileneintrag, der anzeigt, daß von einem entfernten System Dienstleistungen angefordert werden. Ebenso kann das Piktogramm, das den Kommunikationsstatus symbolisiert, die laufenden Kommunikationsvorgänge anzeigen. Dagegen hat sich die Verwendung eines »schlafenden Mauszeigers« (z.B. repräsentiert durch eine Sanduhr)

4

Benutzungsmodell bei verteilter Kommunikation


4.3


1092

aus unserer Sicht nicht bewährt. Anwender kennen dieses Symbol aus der synchronen Interprozeßkommunikation und erwarten daher, daß sie in dieser Phase nicht weiterarbeiten können.

4


5

Vorgehensweise und Dokumentation

5


5.1


Anwendungssoftware, als ein professionell und arbeitsteilig erstelltes Produkt, kann nicht unabhängig gesehen werden von dem Vorgang, der zu diesem Produkt führt. Wir haben uns dabei für eine grundlegende Vorgehensweise enschieden – für evolutionäre Systementwicklung mit Prototyping (vgl. Kapitel 2.4 und 5.2.4). In diesem Kapitel zeigen wir auf, wie Projektplanung und -management im Rahmen dieser allgemeinen Vorgehensweise praktisch durchgeführt werden können. Wir betrachten zunächst den Entwicklungsprozeß, um dazu ein Vorgehensmodell zu skizzieren. Die Einleitung (s. Kapitel 1.2) zu diesem Buch hat ja schon den Charakter unserer Methode verdeutlicht:

5

1093

Federführung: Heinz Züllighoven Ko-Autor: Dirk Bäumer, Guido Gryczan, Jürgen Hess, Anita Krabbel, Ute Bürkle, Ingrid Wetzel


5.1


1094

Es geht nicht um ein Kochrezept zur schrittweisen Durchführung eines Softwareprojektes, sondern um eine Anleitung zur »Selbsthilfe«. Das heißt, daß wir auch ein Vorgehensmodell nicht als »ausführbare Vorschrift« betrachten, nach der die detailliert beschriebenen Aktivitäten zu wohldefinierten Ergebnissen führen. Wir wollen vielmehr eine Anleitung geben, nach der sich ein konkretes Entwicklungsteam seine passende Vorgehensweise erarbeiten kann. Damit ist das im folgenden beschriebene Vorgehensmodell eher ein Metamodell für die Softwareentwicklung als eine konkrete Handlungsvorschrift. Der evolutionäre Entwicklungsprozeß kann und darf sich nicht von traditionellen Ansätzen durch eine Beliebigkeit der Vogehensweise und durch die Unplanbarkeit seiner Aktivitäten unterscheiden, sonst wird sich kein Unternehmen auf diese Risiken einlassen. Wir haben in der Vergangenheit einige Projekte mit sehr engen Zeitvorgaben, knappen Ressourcen und komplexen Entwicklungsaufgaben begleitet. Die dabei gewonnenen Erfahrungen über die Planung und das Management evolutionärer Projekte bilden einen eigenen wesentlichen Abschnitt dieses Kapitels. Damit unsere konkrete Vorgehensweise gegenüber traditionellen Ansätzen verständlich wird, haben wir eine Reihe von Themen aus dem Bereich Projektplanung und -management als kurze Diskussionsabschnitte zusammengestellt. Hier informieren wir über unterschiedliche Ansätze, berichten über unsere Erfahrungen und geben Anleitungen für die praktische Arbeit.

5


5.1


1095

5.1.1 Vorgehen in Softwareprojekten Softwareprojekte

Professionelle Softwareentwicklung findet in Form von Projekten statt, die sehr unterschiedlich ausgerichtet sein können. Diese Projekte haben sehr verschiedene Merkmale, die konkret bestimmen, wie die Vorgehensweise aussehen muß und welche methodische oder technische Unterstützung gefordert ist.

Thema

Nach [Floyd & Züllighoven 97] sind folgende Merkmale von Softwareprojekten relevant:

Diskussion

❑ Projektziel: Software als marktfähiges Fertigprodukt (z.B.

Textverarbeitungssysteme), wiederverwendbarer Baustein (sogenannte Componentware) und Bausteinsammlung (z.B. Fensterbibliotheken) oder als dedizierte Einzellösung; ❑ Projektgegenstand: Neuentwicklung, Weiterentwicklung, Re-

vision (Re-engineering) von Software; ❑ Anwendungsorientierung: Anzahl, Art und Umfang der

Anwendungsbereiche; erwartete Lebensdauer und Einsatzhäufigkeit der Software; Anzahl, Art, Tätigkeitsprofil und Qualifikation der Anwender und Benutzer;

5


5.1


1096

❑ organisatorischer Rahmen: Art der projekttragenden Organi-

sation, Verhältnis von Auftragnehmer zu Auftraggeber, beteiligte Personengruppen, ihre Größe, ihre Interessenvertretung und Qualifikation, Art der Entscheidungsfindung, Möglichkeiten von Partizipation und Mitentscheidung; ❑ technischer Kontext: kontextfrei definierte, technisch oder

sozial eingebettete Software; Software als einzelnes System, Teil einer Kombination aus Hardware und Software oder als Komponente in einer heterogenen Produktlandschaft. Softwareprojekte werden klassischerweise entlang von produktbezogenen Aktivitäten aufgeteilt. In der Literatur (z.B. [Pagel & Six 94, Pomberger & Blaschek 93, Sommerville 92]) und in der Praxis finden sich viele unterschiedliche Namen und Einteilungen (z.B. Bedarfsanalyse, Sytemanforderungen, Anforderungsanalyse), aber im Grunde genommen ein dahinterstehendes gemeinsames Grundverständnis: Analysierende, modellierende oder konstruierende und bewertende Aktivitäten sind notwendig, um ein Softwaresystem zu entwickeln. Die zahlreichen Vorgehensmodelle unterscheiden sich nun darin, wie sie diese Aktivitäten und deren Ergebnisse benennen, einteilen und in eine zeitliche oder logische Ordnung bringen. Wir betrachten im weiteren nur Vorgehensmodelle, die als Vorschriften oder zumindest preskriptive Anleitungen für die Projektdurchführung gedacht sind.

5


5.1


1097

Dimensionen eines Softwareprojektes

In Anlehnung an [Andersen et al. 90] zeigen wir verschiedene Dimensionen eines Softwareprojektes auf (s. Abbildung 5-1). Wir stellen eine große Ähnlichkeit zwischen dem Entwicklungs- und dem Managementprozeß fest. Als Folge wollen wir die Anwendungsorientierung zur Grundlage beider Prozesse machen und entsprechend bei der Wahl einer konkreten Vorgehensweise berücksichtigen.

Thema

Wir haben die Komplementarität zwischen produkt- und prozeßorientierten Aktivitäten herausgestellt. Unter dem Stichwort »AutorKritiker-Zyklus« fordern wir für die Entwicklungsaktivitäten den Wechsel zwischen Analyse, Modellierung und Bewertung. Das Verständnis der aktuellen Situation spielt für die Entwicklung des zukünftigen Systems eine zentrale Rolle. Auf den Zusammenhang von Istund Soll-Modellierung gehen wir in Kapitel 5.2 noch genauer ein.

Diskussion

5


5.1

Vision

Realität


Vision

Realität

Softwareprojekt Entwicklung Reflexion

Aktion

Analyse

Bewertung

Modellierung

produktorientiert

1098

Abb. 5-1 Dimensionen eines Softwareprojektes

Management Planen

Konttrolle

Steuerung

prozeßorientiert

5


5.1


1099

Entwicklungs- und Managementprozeß: ❑ Der Entwicklungsprozeß hat das Softwareprodukt zum Gegenstand. Entwicklung muß im ständigen Wechsel von analysierenden, modellierenden und bewertenden Aktivitäten stattfinden. Das Softwareprodukt soll durch eine hohe Gebrauchsqualität seine Anwendungsorientierung zeigen. ❑ Der Managementprozeß hat die Projektdurchführung zum Gegenstand. Management muß den evolutionären und situativen Entwicklungsprozeß durch den ständigen Wechsel von Planung, Steuerung und Kontrolle überschaubar und planbar gestalten. Dabei wird die Anwendungsorientierung durch die systematische Einbeziehung der verschiedenen Gruppen des Anwendungsbereichs realisiert.

Bei der Beschreibung der verschiedenen Merkmale eines interaktiven Anwendungssystems haben wir herausgearbeitet, daß die Übereinstimmung zwischen den Konzepten und Strukturen des Anwendungsbereichs und des Softwaresystems die wesentliche Grundlage für ein hohes Maß an Gebrauchs- und softwaretechnischer Qualität ist. Bezogen auf den Managementprozeß fordern wir ebenfalls Anwendungsorientierung. Hier bedeutet Anwendungsorientierung, daß die verschiedenen Gruppen des Anwendungsbereichs systematisch einbezogen werden. Damit diese Gruppen ihr Fachwissen und ihre Erfah-

5


5.1


1100

rung in den Entwicklungsprozeß einbringen können, sind neben einer geeigneten Vorgehensweise vor allem anwendungsorientierte Darstellungsmittel und Dokumenttypen gefordert. Das klassische Wasserfallmodell

Das Wasserfallmodell war historisch das erste Vorgehensmodell für die Softwareentwicklung, und es prägt heute noch das Denken vieler Softwareentwickler und -manager. Die Probleme und Schwachstellen dieses Modells sollten erkannt werden.

Thema

Das klassische Wasserfallmodell (populär gemacht durch [Boehm 76]) war das erste lineare Phasenmodell. Es betrachtet die Herstellung von Software als zeitliche Folge von in sich geschlossenen Aktivitäten (Phasen). Die zahlreichen Variationen (als Beispiel siehe Abbildung 5-2 in Anlehnung an [Pagel & Six 94]) fordern alle benannte und standardisierte Entwicklungsschritte, die nacheinander durchlaufen werden sollen. Diese führen zu einer Anzahl Dokumenten (sogenannte Meilensteindokumente), die in der Form möglichst festgelegt sind. Rückgriffe auf vorangegangene Phasen sind zwar meist erlaubt und in der Praxis die Regel. Aber diese Rückgriffe haben den Charakter von Fehlern und Unzulänglichkeiten, die bei optimalem Projektverlauf nicht nötig wären und damit minimiert werden sollen.

Diskussion

5


5.1


1101 Abb. 5-2 Ein Wasserfallmodell

Analyse und Definition

Pflichtenheft

Entwurf

Systemspezifikation Implementation

Programmcode Test

Programm

Einsatz und Wartung

5


5.1


1102

An Wasserfallmodellen ist viel Kritik geübt worden (vgl. [Parnas & Clements 85, Budde et al. 92c]). Neben den allgemein erkannten Problemen stehen für uns die mangelnde Anwendungsorientierung im Vordergrund. Die Anwender und ihre Integration in den Entwicklungsprozeß lassen sich nicht darstellen. Im einzelnen sehen wir folgende Schwachstellen: ❑ Die Aktivitäten des Vorgehensmodells sind an der Software-

technik und nicht am Anwendungsbereich orientiert. ❑ Die lineare Vorgehensweise läßt sich nicht einhalten. ❑ Anforderungen können nur teilweise vorab ermittelt werden

und ändern sich ständig. ❑ Dokumente sind keine zuverlässigen Zwischenergebnisse, weil

ihre Konsequenzen schwer abzusehen sind. ❑ Der Lernprozeß der Beteiligten bei der Entwicklung wird igno-

riert. ❑ Systematische Zyklen über Analyse, Entwurf und Bewertung

finden nicht statt.

5


5.1


1103

Das Spiralmodell

Das Spiralmodell wird als wesentliche Verbesserung des Wasserfallmodells angesehen. Aus unserer Sicht bringt sein Einsatz aber ähnliche Probleme. Deshalb sollten die Schwachstellen des Spiralmodells erkannt werden.

Thema

Auch die Weiterentwickung des Wasserfallmodells durch das flexiblere Spiralmodell [Boehm 88] bietet benannte und standardisierte Entwicklungsschritte. Diese werden jedoch in einem zyklisch angeordneten Prozeß mehrfach durchlaufen, bis das Produkt fertig gestellt ist (s. Abbildung 5-3). Obwohl das Spiralmodell den zyklischen Wechsel zwischen den verschiedenen Aktivitäten vorsieht und über die Integration von Prototyping die Schwierigkeiten der Anforderungsermittlung berücksichtigt, geht es aus unserer Sicht konzeptionell nicht weit genug:

Diskussion

❑ Das Ziel des Entwicklungsprozesses ist nach wie vor ein neu-

entwickeltes in sich geschlossenes Produkt. ❑ Die Trennung von Herstellung und Einsatz bzw. Wartung

bleibt erhalten. ❑ Die Aktivitäten sind softwaretechnisch ausgerichtet; eine

Anwendungsorientierung ist kaum erkennbar. ❑ Versionen und Ausbaustufen werden nicht berücksichtigt.

5


5.1

Festlegung von Zielen, Lösungsvarianten, Nebenbedingungen und Einschränkungen

Kumulative Kosten


Erarbeitung und Beurteilung von Lösungsvarianten, Erkennen und Beseitigen von Risiken

Projektfortschritt

1104 Abb. 5-3 Das Spiralmodell

Risikoanalyse

Risikoanalyse

Risikoanalyse Prototyp 1

Prototyp 2

operationaler Prototyp

Prototyp 3

Life-Cycle- VorgehensPlan modell

Systemspezifikation Entwicklungsplan Validierung der Spezifikation Integration und Test

Feinentwurf Codierung

Validierung und Verifikation des Entwurfs

Installation

Planung der nächsten Phase

Architekturentwurf

Abnahmetest

Komponententest Integration und Integrationstest

Entwicklung und Validierung des Produkts der nächsten Stufe

5


5.1


1105

Ein idealisiertes evolutionäres Vorgehensmodell

Wir formulieren das Ideal eines evolutionären Vorgehensmodells, das als Alternative zu einem Wasserfall- oder Spiralmodell als eine grundlegende Neuorientierung für das Vorgehen bei der Softwareentwicklung gesehen werden kann. Es ist die Aufgabe jedes Projektes, diese Idealvorstellung unter den gegebenen Randbedingungen zu konkretisieren.

Thema

In Abbildung 5-4 haben wir unser idealisiertes evolutionäres Vorgehensmodell dargestellt. Es sollte nicht überraschen, daß das Grundprinzip des Autor-Kritiker-Zyklus mit den anwendungsorientierten Dokumenttypen zusammengebracht wurde. Zwei Prinzipien bestimmen dieses Vorgehensmodell:

Diskussion

❑ Jedes Softwareprojekt sollte eine zyklische Abfolge der generel-

len Aktivitäten Analysieren, Modellieren und Bewerten sein. Dies gilt für die Entwicklung und das Management. Auf die Auswahl geeigneter Autoren und Kritiker ist zu achten. ❑ Alle für ein Projekt ausgewählten Dokumenttypen sollten prin-

zipiell im gesamten Projektverlauf bearbeitbar sein. Eine vordefinierte Bearbeitungsreihenfolge existiert nicht. Jeder Dokumenttyp sollte mit Blick auf seinen Zweck und seine Verständlichkeit für Autoren und Kritiker ausgewählt werden.

5


5.1


1106 Abb. 5-4 Ein idealisiertes

Bewerten

evolutionäres Vorgehensmodell

Analysieren Szenario Glossar Vision Entwurf Klasse Bibliothek Prototyp

Modellieren

5


5.1


1107

Aufgrund der prinzipiellen Ähnlichkeit von Entwicklungs- und Managementprozeß und unserer Vorstellung von durchgängiger Anwendungsorientierung ergeben sich einige Forderungen: ❑ Dokumentbasierte Modellierung: Der Entwicklungsprozeß

findet mit und an Dokumenten statt. Dies scheint auf den ersten Blick nicht neu. Genauer betrachtet heißt dies aber, daß die Beteiligten nur solche Dokumente erstellen und bewerten, die insgesamt das Anwendungssystem ausmachen. Jede Aktivität sollte also in diesem Sinne zielgerichtet sein und jedes Dokument sollte einen Beitrag zum Anwendungssystem liefern. Damit aber alle Beteiligten tatsächlich auf dieser Grundlage zusammenarbeiten können, müssen die Dokumente bestimmte Voraussetzungen erfüllen, auf die wir in Kapitel 5.2 detailliert eingehen. Für den Managementprozeß heißt das, weitgehend auf zusätzliche Dokumente zu verzichten. Je weniger eigenständige Managementdokumente von den Entwicklern für das Projektmanagement erstellt werden müssen, desto intensiver können sie sich dem Entwicklungsprozeß widmen. Entwicklungsdokumente sollten daher systematisch im Managementprozeß berücksichtigt werden. Dies bedeutet nicht, daß eine evolutionäre Vorgehensweise ganz auf Planungsdokumente verzichten kann. Darauf gehen wir in Kapitel 5.1.3 genauer ein.

5


5.1


1108

❑ Ist- und Sollabgleich: Die Rahmenbedingungen für die Ent-

wicklung von Anwendungssoftware haben sich verändert. Softwareentwicklung ist kein Selbstzweck, sondern wird als eine Dienstleistung gesehen, die ihren Beitrag zum Unternehmensziel aufzeigen muß. Die Einsatzkontexte und die fachlichen Anforderungen an Arbeitsplatzsysteme ändern sich ständig, oft bereits beträchtlich im Laufe eines Projektes. Deshalb müssen Standort- und Zielbestimmung für das zukünftige System immer wieder aufeinander abgeglichen werden. Damit die Ist- und Soll-bezogenen Aktivitäten aber nicht hypothetisch bleiben, sondern überprüfbar werden, müssen sie zu konkreten Ergebnissen führen. Dies sind zunächst anwendungsorientierte Dokumente, die für alle Beteiligten verständlich die jeweilige Situation beschreiben. Besondere Bedeutung kommt der gezielten Auswahl von Prototypen zu, mit denen die verändernden »Visionen« des zukünftigen Systems anschaulich und erfahrbar gemacht werden können. Auch dazu mehr in Kapitel 5.2.4. Diese anwendungsorientierten Dokumenttypen und das Prototyping sind gleichzeitig die Grundlage des entsprechenden Managementprozesses. Je aussagekräftiger sie die aktuelle Situation oder die Vision des zukünftigen Systems beschreiben, desto eher ist das Management in der Lage, die Zielvorgaben und die Ressourceneinteilungen für ein Projekt zu überprüfen und zu revidieren.

5


5.1


1109

❑ Permanente Rückkopplung: Die jeweiligen Autoren von

Dokumenten müssen eine Bewertung darüber erhalten, wie verständlich ihre Arbeit ist und welche fachliche Qualität sie hat. Dies ist ein wesentlicher Beitrag zur konstruktiven Qualitätssicherung (vgl. [Floyd & Züllighoven 97]): Schon im Erstellungsprozeß wird die Qualität des Ergebnisses abgesichert, sozusagen »hineinkonstruiert«. Traditionell ist Qualitätssicherung eher ein Kontrollprozeß, bei dem ein Softwareprodukt am Ende seiner Entwicklung in einem gesonderten Prüfverfahren entweder bestätigt oder verworfen wird. Neben der konstruktiven Qualitätssicherung fördert die ständige Rückkopplung auch den Kommunikations- und Lernprozeß zwischen den Beteiligten. Entwickler müssen sich in hohem Maß auf die anwendungsfachlichen Konzepte und Anforderungen einstellen können. In Kapitel 5.2 beschreiben wir, wie solche Rückkopplungsprozesse aussehen können. Unter Managementgesichtspunkten bedeutet permanente Rückkopplung, auch die Projektplanung einem solchen Rückkopplungsprozeß zu unterwerfen. Damit dies sinnvoll geschehen kann, müssen ähnliche Mechanismen wie beim Entwicklungsprozeß zum Tragen kommen: Der Managementprozeß muß dokumentiert sein. Projektziele, die Verteilung von Auf-

5


5.1


1110

gaben, Zuständigkeiten und Fristen müssen in allgemein zugänglichen Dokumenten festgehalten werden. Die Umsetzung der entsprechenden Aktivitäten muß regelmäßig von den verschiedenen Beteiligten überprüft werden. Als Ergebnis der Überprüfung werden neue Ziele und Umsetzungsschritte formuliert. Damit unterliegt der Managementprozeß den gleichen Autor-Kritiker-Zyklen wie der Entwicklungsprozeß. Diese Vorgehensweise verzahnt der Entwicklungs- und Managementprozeß eng miteinander. Die Rückkopplungszyklen sichern schon während der Entwicklung die Qualität des »Produkts«, während gleichzeitig aussagekräftige Indikatoren für die Projektsteuerung und -planung vorliegen (vgl. [Frei et al. 96]). Reihenfolge von Entwicklungsaktivitäten

Eine oft vorgetragene Kritik an evolutionären Vorgehensmodellen ist, daß eine vorgegebene Reihenfolge von Entwicklungsaktivitäten einer inneren Sachlogik folge. Wir halten dagegen, daß in konkreten Projekten natürlich eine Abfolge von Entwicklungsschritten vorgegeben werden kann und soll, daß dieses aber nicht zu einem allgemeinen Prozeßmodell hochstilisiert werden sollte.

5

Thema


5.1


Es klingt logisch, daß vor der Konstruktion eines Produkts die Analyse der Anforderungen und der Entwurf erfolgen sollen. Ohne Zweifel gibt es auch in einem Softwareprojekt sehr viel softwaretechnisches Handwerk (z.B. Editieren, Compilieren, Versionieren, Dokumentieren), das einer Abfolge unterliegt. Aber was wann und von wem in einem Projekt getan werden muß, das folgt nicht einem festen (technisch motivierten) Phasenschema, sondern muß sich an den Randbedingungen des Anwendungsbereichs orientieren. Wir hören oft den Einwand, daß es aber eine gewisse softwaretechnische »Sachlogik« gebe, die eine wasserfallartige Vorgehensweise in den bekannten Teilschritten »naturgemäß« erzwinge. Dem können wir auf der Mikroebene (im Sinne von [Booch 95]) zustimmen, wo es durchaus sinnvoll ist, erst zu überlegen, was ein Stück Programm tun soll, dann, wie es architektonisch zu strukturieren ist, um es schließlich zu implementieren und zu testen. Auf der größeren Ebene eines Projektes treffen diese Sachzwänge schon weniger häufig zu.

5

1111 Diskussion


5.1


1112

Dagegen lassen sich einige Kriterien angeben, die bei der Bestimmung von Aktivitäten und ihren Reihenfolgen herangezogen werden sollten: ❑ Die verschiedenen Aktivitäten sind grundsätzlich nicht ge-

trennten Arbeitsphasen oder Projektabschnitten zugeordnet. ❑ Jede Aktivität ist ziel-, d.h. anwendungsorientiert und berück-

sichtigt die verwendete Technik (s. Kapitel 2.5). ❑ Veränderte fachliche Anforderungen werden möglichst konti-

nuierlich berücksichtigt und bestimmen damit die Aktivitäten. ❑ Dokumente sind nicht einzelnen Aktivitäten zugeordnet und

werden daher nicht grundsätzlich fixiert (eingefroren), sondern je nach Anforderung fortgeschrieben. ❑ Die Lernprozesse der Beteiligten werden durch integrierte Pro-

jektteams aber vor allem durch geeignete Aktivitäten unterstützt.

5


5.1


1113

Im folgenden Beispiel werden wir die Frage auf, wie sachlich zwingend die Phasen eines Vorgehensmodells sind:

Beispiel

In einem von uns begleiteten Projekt beschlossen die Entwickler, nicht wie konventionell üblich, mit der Analyse des Anwendungsbereichs zu beginnen. Statt dessen bauten sie einen technischen Prototyp auf einer fachlich völlig vagen fachlichen Basis, der nach außen nur prinzipielle Handhabungsmöglichkeiten zeigte. Erst danach begannen sie, sich intensiv in Interviews und durch Hospitieren mit der Situation und den Anforderungen ihres Fachbereichs zu beschäftigen.

von Entwicklungs-

zur Reihenfolge aktivitäten

Die Ursachen für diese Vorgehensweise: Zum einen sollte in diesem Projekt erstmals ein Smalltalk-System als Entwicklungsplattform eingesetzt werden, das allen Entwicklern neu war. Zudem herrschte die Ansicht, daß die potentiellen Benutzer in der Fachabteilung durch zurückliegende unbefriedigend verlaufene Softwareprojekte keine besonders hohe Meinung von der Leistungsfähigkeit ihrer Entwicklungsabteilung hätten. Die Entwickler wollten daher sichergehen, daß sie zumindest ihr technisches Handwerkszeug beherrschen, ehe sie mit neuen Aktivitäten an den Fachbereich herantraten. Im weiteren Projektverlauf zeigte sich, daß diese Entscheidung in Anbetracht der Situation wohl völlig richtig war.

5


5.1


1114

Personenunabhängigkeit des Entwicklungsprozesses

Wir haben Softwareentwicklung als einen dokumentbasierten Modellierungsprozeß bezeichnet. Damit stellt sich unmittelbar die Frage, ob diese Dokumente nicht die beste Voraussetzung für einen personenunabhängigen Entwicklungsprozeß sind. Wir argumentieren dagegen, daß für einen Großteil der Softwarekomponenten eine personenunabhängige Entwicklung nicht möglich ist.

Thema

Ein immer wieder propagiertes Ideal des Software Engineering ist die Personenunabhängigkeit des Entwicklungsprozesses. Dahinter steht die Vorstellung, Software in hohem Maß arbeitsteilig erstellen zu wollen, d.h., es sollen unterschiedlich ausgebildete (und bezahlte) Spezialisten für die verschiedenen Aktivitäten eines Phasenmodells eingesetzt werden. So soll z.B. das Anwendungsmodell von Analytikern, der Softwareentwurf von Designern, die Benutzungsoberfläche von Softwareergonomen und das eigentliche Programm von Programmierern erstellt werden. Für die anschließende Weiterentwicklung stehen dann die Wartungsprogrammierer oder der Kundenservice bereit. Auch innerhalb der einzelnen Gruppen wird Personenunabhängigkeit angestrebt: Ausscheidene Personen sollen verlustfrei ersetzt und terminliche Engpässe durch die Erhöhung der Personalkapazität überbrückt werden.

Diskussion

5


5.1


1115

Damit diese Arbeitsteilung und die Personenunabhängigkeit aber funktionieren können, wird gefordert, daß die jeweiligen Dokumente (d.h. Meilensteindokumente) alle notwendigen Informationen über die bearbeitete Phase und für die nächste Phase enthalten sollen. Dazu sollen die Dokumente unzweideutig, widerspruchsfrei, objektiv und möglichst formalisiert sein. Hier begegnet uns wieder die grundlegende Illusion des traditionellen Software Engineering, daß Softwareentwicklung im Idealfall ein objektiver Transformationsprozeß von formalen Beschreibungen sein soll. Dem stellen wir die bereits genannte Sichtweise gegenüber, daß Softwareentwicklung zunächst und grundlegend ein Lern- und Diskussionsprozeß zwischen den Beteiligten ist, bei dem die einzelnen Gruppen sowohl die anstehende Aufgabe als auch die für alle möglichst befriedigende »Lösung« aushandeln. Nur einzelne Aspekte dieses Prozesses lassen sich in Dokumenten ausreichend detailliert beschreiben, so daß diese Dokumente für andere zur Arbeitsgrundlage werden können. Wesentliche Erfahrungen, Einsichten und Wertvorstellungen, die unabdingbar mit jedem Entwicklungsprojekt verbunden sind, können nicht in Dokumenten »objektiviert« werden. Das daraus resultierende Dilemma fassen wir so zusammen: Ein Softwaresystem sollte (formal) widerspruchsfrei, korrekt und vollständig dokumentiert sein. Dem steht gegenüber, daß sich der Sinn

5


5.1


1116

und Zweck eines solchen Systems nicht umfassend und vollständig personenunabhängig beschreiben läßt. Welche Bedeutung hat nun das Dilemma in bezug auf arbeitsteilige Softwareentwicklung? Es wäre naiv zu fordern, daß in einem Softwareprojekt keine Arbeitsteilung stattfinden darf und daß von Anfang bis Ende eines solchen Projektes immer die gleichen Personen tätig sind. Diese naive Forderung würde unserem eigenen Anspruch widersprechen. Wir wollen ja den Werkzeug & Material-Ansatz als geeignete Grundlage für die arbeitsteilige Softwareentwicklung vorstellen. Dies schließt ein, daß unterschiedliche Personen und Gruppen mit dem Entwurf und der Konstruktion der einzelnen Komponenten betraut werden können. Für die Beantwortung der Frage, in welchem Umfang Software anhand von (schriftlichen) Spezifikationen entwickelt werden kann, empfiehlt sich die Einteilung, die M. Lehman vorgestellt hat ([Lehman 80]). Lehman unterscheidet zwischen Spezifikationsprogrammen (S-Programme), problemlösenden Programmen (P-Programme) und eingebetteten Programmen (E-Programme).

Die Klassifikation von Software nach Lehman

S-Programme sind dadurch gekennzeichnet, daß zu ihnen eine vollständige und formale Spezifikation existiert, die die Aufgabenstellung und ihre prinzipielle Lösung beschreibt. Beispiele für solche Aufgabenstellungen sind Sinusberechnungen oder die Lösung des Acht-Damen-Problems. Kennzeichnend ist also,

5


5.1


1117

daß wir situations- und verwendungsunabhängig festlegen können, was ein SProgramm leisten muß. Die Voraussetzung für solche Aufgabenstellungen und Lösungen ist, daß sie im hohen Maß verallgemeinert oder abstrahiert sind, damit sie überhaupt formal, d.h. in einer personenunabhängigen mathematischen Form, darstellbar sind. Dann ist es möglich, unter Verwendung einer mathematischen Methode zu überprüfen, ob die Implementation eines S-Programms vollständig aus seiner formalen Spezifikation abgeleitet werden kann. Für kleine, gut bekannte Aufgabenstellungen ist eine solche Darstellung erreichbar. Anwendungsnahe Beispiele für S-Probleme aus unserer Projektpraxis sind Datumsprüfroutinen oder Modellrechner für Renditeberechnungen.

P-Programme besitzen eine klar beschreibbare Aufgabenstellung – sie lösen ein bekanntes Problem. Im Einzelfall ist es möglich, die Aufgabenstellung formal zu beschreiben. Damit sind P-Programme den S-Programmen verwandt. Allgemeine Beispiele für P-Programme sind Schach- oder Spielprogramme. Der Unterschied zu S-Programmen besteht in der Problemlösung. Sie muß zunächst mindestens den formalen Randbedingungen der Aufgabenstellung genügen. So darf ein Schachprogramm keine regelwidrigen Züge machen. Darüber hinaus muß aber festgelegt werden, wie gut , d.h. mit welcher Geschwindigkeit oder Präzision oder mit wieviel Kapazität, ein P-Programm seine Aufgabe löst. Dies ist eine Entscheidung der Entwickler, die meist durch Anwender bewertet und damit akzeptiert wird. So wird ein Anfänger andere Anforderungen an die Leistungsfähigkeit und Antwortzeit eines Schachprogramms stellen als ein Großmeister. Auf den Kontext unserer Projekte übertragen, finden wir P-Programme z.B. zur Überprüfung der Vollständigkeit und Konsistenz von ausgefüllten Formularen. Dabei ist z.B. klar, was ein konsistentes Formular ist und auch, daß kein inkonsistentes Formular zum Vertrag werden darf. Aber wann was mit welchem Aufwand geprüft wird, ist eine jeweils zu entscheidende Ermessensfrage, die oft erst in der Anwendung überprüft werden kann.

5


5.1


1118

E-Programme werden entwickelt, um Unterstützung in einem Anwendungsbereich, d.h. in konkreten Arbeitssituationen, zu bieten. Damit ist bereits in der Begriffsbestimmung von E-Programmen eine subjektive Komponente eingeflossen. Ob und in welchem Umfang ein Zustand als »Problem« angesehen wird und was als Unterstützung benötigt wird, ist abhängig von der Sichtweise des Betrachters. Daher ist es kaum möglich, so etwas wie eine in sich geschlossene und personenunabhängige Darstellung der Aufgabenstellung oder des Problems zu finden. Dazu paßt, daß eine Lösung oder Verfahrensvorschrift für ein EProgramm nicht abstrakt definiert ist, sondern immer nur von den beteiligten Personen bewertet und akzeptiert werden kann. Als Beispiel kann ein Bürokommunikationssystem dienen. In welcher als Problem eingeschätzten Situation ein solches System eine Lösung ist, kann nicht abstrakt gesagt werden. Ebenso hängt es von den beteiligten Personen und ihren Arbeitsaufgaben ab, ob das ausgewählte Bürokommunikationssystem den Anforderungen und Vorstellungen entspricht. Korrektheit im mathematischen Sinne kann für diese Art von Programmen nicht nachgewiesen werden. Viel bedeutsamer für E-Programme ist, ob sie anwendungsangemessen und menschengerecht sind. Die meisten der in diesem Buch vorgestellten Beispiele sind als E-Programme zu klassifizieren.

Hier ist die von Lehman entwickelte Klassifikation in S-, P- und E-Programme hilfreich (s. [Lehman 80]). Was bedeutet dieses Konzept bezogen auf die personenunabhängige Entwicklung? Primär, daß sich die

5


5.1


1119

jeweiligen Programmtypen unterschiedlich beschreiben und realisieren lassen. Während S- und P-Programme im traditionellen Sinne recht gut personenunabhängig spezifiziert und implementiert werden können, ist dies bei E-Programmen nicht der Fall. Für die Entwicklung von E-Programmen ist es notwendig, daß die Entwickler den nichtformalisierbaren Kontext und die Arbeitszusammenhänge eines Anwendungssystems verstanden haben. An S- und P-Programme werden auch andere Anforderungen für die Bewertung gestellt. Während S-Programme bereits von den Entwicklern auf Korrektheit geprüft werden können, ist dies bei P-Programmen nur noch eingeschränkt möglich. Hier muß der »Praxistest« hinzukommen. Die Bewertung von E-Programmen hingegen ist ein permanenter Prozeß zwischen allen Beteiligten, da sich durch Bewertung und Einsatz gleichzeitig die Voraussetzungen für die weitere Entwicklung verändern. Dies zeigt sich deutlich in vielen Projekten. Die Vorstellungen über das Anwendungssystem verändern sich im Team und noch stärker bei den Anwendern mit jeder neuen realisierten Komponente oder Ausbaustufe. Daher ist eine personelle Kontinuität auf Seiten der Entwickler wichtig für die evolutionäre Anpassung eines Systems an sich verändernde Randbedingungen.

5


5.1


1120

Der arbeitsteilige Entwicklungsprozeß

Anwendungssoftware wird im Rahmen des WAM-Ansatzes für die verschiedenen Einsatzkontexte entwickelt. Einerseits werden verschiedene Arbeitsplatzsysteme konstruiert, andererseits sollen möglichst viele bereits vorhandene Komponenten zur Ausstattung der verschiedenen Arbeitsplätze wiederverwendet werden. Damit stellt sich die Frage nach der arbeitsteiligen Entwicklung.

Thema

Ein Blick auf die Einteilung in S-, P- und E-Programme hilft auch, um die Frage zu beantworten, welche Komponten einer Anwendung sich innerhalb einer Entwicklungsorganisation arbeitsteilig erstellen lassen. Dazu eignen sich diejenigen Komponenten, die sich als eigenständige Dienstleistung im Rahmen eines Arbeitsplatzkonzepts beschreiben lassen. Soll eine neue Dienstleistung entwickelt werden, muß im Projektteam Klarheit über den Anwendungskontext und den Umfang der Dienstleistung hergestellt werden. Erst dann kann die Realisierung der Dienstleistung unabhängig erfolgen. Als Beispiele aus unseren Projekten sind die arbeitsteilige Realisierung des Anschlusses eines Arbeitsplatzsystems an einen Großrechner oder eine Datenbank zu nennen. Es muß aber bedacht werden, daß eine – von einzelnen oder unabhängigen Arbeitsgruppen vorgenommene – Implementation von Kom-

Diskussion

5


5.1


1121

ponenten jeweils der Ausgangspunkt für die nächsten, gemeinsam zu treffenden Entwurfsentscheidungen darstellt. Denn jede neue Komponente verändert ja den Kontext, in den weitere Komponenten eingepaßt werden müssen. Aus dem Konzept der E-Programme wird deutlich, daß mit der Identifikation einer Dienstleistung und ihrer Implementation der Entwicklungsvorgang nicht abgeschlossen ist. Erst die Bewertung und Akzeptanz im Anwendungsbereich schließt den Zyklus, da letztlich dort entschieden wird, ob die entwickelten Komponenten auch als Dienstleistungsangebote angenommen werden. Hieran wird deutlich, daß sich das Verständnis von E-Programmen aus dem Zusammenspiel von Konstruktion und Bewertung entwickelt und daß als Konsequenz ständig Autor-Kritiker-Zyklen zur Formulierung, Abgrenzung und Bewertung von Teilaufgaben notwendig sind. Die Einteilung in S-, P- und E-Programme klärt auch die Frage, ob und in welchem Umfang Komponenten von externen Kooperationspartnern oder Unterauftragnehmern übernommen werden können. Die Einteilung macht deutlich, daß sich S-Programme durchgängig als eigenständige Arbeitspakete formulieren lassen. So läßt sich eine Anwendungskomponente zur Berechnung von unterschiedlichen Kreditkennzahlen mit vertretbarem Aufwand spezifizieren und als Unterauftrag entwickeln.

5


5.1


1122

Programme vom P-Typ eignen sich für die lose Kooperation, soweit der Kooperationspartner über ausreichenden Sachverstand verfügt und die Komponenten in regelmäßigen Abständen integriert und bewertet werden können. Als Beispiel aus dem Bankenbereich lassen sich Komponenten eines Wertpapier-Systems für die Chartanalyse nennen. Denn hier sind die finanzmathematischen Vorgaben mit den Anforderungen an Benutzbarkeit und Übersichtlichkeit zusammenzubringen. Dagegen erfordern komplexe Anwendungssysteme vom E-Typ eine so hohe permanente Abstimmung und Rückkopplung im Projektteam und mit den Anwendern, daß sie nur mit großem Aufwand räumlich und zeitlich unabhängig entwickelt werden können. Damit können Komponenten vom E-Typ zwar durchaus als eigenständige Dienstleistungen arbeitsteilig »im Hause« entwickelt werden, aber sie können kaum mit vertretbarem Aufwand als externer Auftrag zur selbständigen Erledigung an Dritte vergeben werden. Eine wesentliche Managementaufgabe innerhalb jeder Entwicklerorganisation besteht entsprechend darin, aus dem Gesamtzusammenhang des zu entwickelnden Anwendungssystems einzelne S- und P-Komponenten herauszupräparieren, die dann arbeitsteilig auch von Kooperationspartnern und externen Auftragnehmern realisiert werden können. Allerdings ist hier Augenmaß erforderlich. Denn die

5


5.1


1123

Erfahrungen im Bereich der formalen Spezifikation haben gezeigt, daß der Aufwand, eine solche Spezifikation zu erstellen, meist den Aufwand für die Implementation übersteigt. Das Management muß also darauf achten, daß die Vor- und Nachbereitung externer Aufträge im eigenen Haus nicht mehr Ressourcen verbraucht, als die hauseigene Entwicklung gekostet hätte. Wenn die Möglichkeiten einer externen Entwicklung von Komponenten ausgeschöpft sind, aber trotzdem zeitliche und personelle Engpässe bestehen, dann bleibt noch das sogenannte »Insourcing«, das wir im nächsten Abschnitt besprechen. Organisatorische und fachliche Integration

Projektteams müssen so zusammengesetzt werden, daß sie eine hohe personelle Kontinuität besitzen und die verschiedenen Bereiche des fachlichen Wissens abdecken können. Die personelle Kontinuität im Entwicklungsprozeß schafft die Voraussetzung für die notwendigen Lernprozesse und ist die Grundlage für die systematische Arbeit mit Dokumenten. Die fachliche Integration stellt die Anwendungsorientierung sicher und muß die Wandlungen des Anwendungsbereichs reflektieren. Vor diesem Hintergrund sind auch die Möglichkeiten zur Nutzung externer Entwicklerkapazität zu sehen.

5

Thema


5.1


Das Ideal der Personenunabhängigkeit von Entwicklungsdokumenten als Leitlinie für die Projektdurchführung ist nach unserer Sicht nicht haltbar, d.h., die Personenunabhängigkeit sollte nicht zum vorrangig angestrebten Prinzip eines Projektes werden. Die Organisation eines Projektes in einzelne in sich abgeschlossene Phasen, die jeweils von unabhängigen Personengruppen realisiert werden, führt in der Praxis nicht zu dem gewünschten Gesamtergebnis. Deshalb fordern wir integrierte Entwicklerteams von anwendungsnah und softwaretechnisch orientierten Mitgliedern und die personelle Kontinuität innerhalb eines Projektes. Diese Integration und Kontinuität muß über das einzelne Projekt hinausgehen. Unsere Projekterfahrung zeigt, daß eine Entwicklungskultur entstehen muß, die die Anwendungsentwicklung insgesamt beeinflußt und die nicht mit dem offiziellen Ende eines Projektes wieder verschwinden darf. Eine Architekturgruppe (s. S. 560ff.) beispielsweise bedeutet für uns in diesem Zusammenhang ein Katalysator, um diese gemeinsame Entwicklungskultur herauszubilden. Sie kann viel an Erfahrung und Zusammenhangswissen über das einzelne Projekt hinaus transportieren. Uns ist klar, daß nicht alle Teammitglieder jede anfallende Aufgabe im Projekt gleich gut erledigen können, so wenig wie sie über einen beliebig langen Zeitraum kontinuierlich zur Verfügung stehen.

5

1124 Diskussion


5.1


1125

Trotzdem muß das Problem gelöst werden, daß ein rein softwaretechnisches Expertenwissen nicht ausreicht, um Anwendungssoftware aufgrund von schriftlichen Anforderungen zu entwickeln. Ein Mittel zur Lösung des Kontinuitätsproblems ist die organisatorische Integration: Innerhalb von Projekten und »Projektfamilien« wird nach dem »Staffel-Prinzip« gearbeitet. Wie beim Staffellauf die Übergabe des Stabes zwischen den einzelnen Läufern durch eine Phase des »gemeinsamen Laufens« gesichert wird, gibt es in jedem Projekt bei personellem Wechsel einen ausreichenden Zeitraum der personellen »Überdekkung«. Dabei kann in der direkten Zusammenarbeit und Diskussion das Erfahrungswissen und der Hintergrund der ausscheidenden Projektmitarbeiter an die neuen weitergegeben werden. Dies ist eine primäre Voraussetzung zum Verständnis der Projekt- und Entwicklungsdokumente. Für die Zusammenarbeit mit externen Partnern sehen wir zwei Wege der organisatorischen Integration: »Insourcing«, d.h. lokale Anwesenheit, oder ausreichende Abstimmungsphasen.

Organisatorische

Insourcing bedeutet zunächst trivialerweise, daß die externen Partner im Entwicklungsteam mitarbeiten. Hier muß sichergestellt werden, daß der Entwicklungsstil der externen Partner mit der gewählten

Insourcing

5

Integration


5.1


1126

Methode verträglich ist. Die entsprechenden Personen sollten auch nicht beliebig ausgetauscht oder mit anderen Aufgaben betraut werden. Wir haben in verschiedenen Projekten sehr gute Erfahrung damit gesammelt, externe Berater, die wenig mit dem Anwendungsbereich und mit dem WAM-Ansatz vertraut waren, für die Programmierunterstützung einzusetzen. Dabei arbeitet ein externer Mitarbeiter eng mit zwei bis drei Teammitgliedern zusammen und hilft ihnen, anstehende Konstruktionsfragen zu lösen. In einem Bankenprojekt sollte eine Smalltalk-Entwicklungsumgebung eingesetzt werden. Das Team war damit nicht vertraut. Trotz Schulung stellte sich bald heraus, daß besonders bei der Verwendung der GUI-Werkzeuge und der Komponenten zur grafischen Programmierung Probleme auftraten. Über einen Zeitraum von einem halben Jahr wurde ein Beratervertrag mit einer Beraterfirma abgeschlossen, die bereits verschiedene Smalltalk-Projekte mit dieser Umgebung durchgeführt hatte. Ein Berater stand dem Projekt an drei Tagen pro Woche zur Verfügung. Pro Tag arbeitete er mit einem Teammitglied am selben Arbeitsplatz. Das Teammitglied erläuterte jeweils sein aktuelles Konstruktionsproblem, das der Berater dann mit ihm gemeinsam löste. Auf diese Weise konnte die Entwicklungszeit für die Anwendungskomponenten drastisch verkürzt und das Konstruktionswissen im Team beachtlich erhöht werden, ohne daß aufwendige Spezifikations- und Anforderungspapiere geschrieben und extern erstellte Komponenten »abgenommen« werden mußten.

5

Beispiel für die Integration externer Mitarbeiter


5.1


Ist die lokale Anwesenheit nach dem Insourcing-Prinzip nicht möglich, dann sind vorausgeplante und kontinuierliche Abstimmungen zwischen den Beiteiligten unumgänglich. Dabei sollte bedacht werden, daß informationstechnische Medien wie elektronische Post, Telefonoder Videokonferenzen meist nur einen unzureichenden Ersatz für die direkte Zusammenarbeit zwischen Personen darstellen. Eine Abhilfe kann durch eine modifizierte Form des Insourcing geschaffen werden. Ein erfahrenes Teammitglied arbeitet über einen substantiellen Zeitraum im Team des externen Partners. Allerdings sind unsere Erfahrungen dabei nicht so gut wie mit dem eigentlichen Insourcing. Hier zeigt sich verstärkt das Problem unterschiedlicher Vorgehensweisen. Verschiedene Ansichten über die Notwendigkeit von Rückkopplungszyklen und den Stellenwert von Dokumenten wirken sich dabei besonders nachteilig aus. Einen durchgängig negativen Effekt haben in diesem Zusammenhang sogenannte Festpreisprojekte, da dort erfahrungsgemäß immer ein Mißverhältnis zwischen den Wünschen und Vorstellungen des Auftraggebers und der Bereitschaft des Vertragsnehmers besteht, diesen Anforderungen nachzukommen. Als Folge werden beide Seiten mit dem Projektergebnis unzufrieden sein, und bereits im Projektverlauf wird eine Atmosphäre gegenseitigen Mißtrauens an die Stelle einer kooperativen Zusammenarbeit treten.

5

1127 Abstimmungsphasen


5.1


Zur personellen Integration muß die fachliche Integration kommen. Dies betrifft zwei Aspekte: Das Verhältnis zwischen Entwicklerorganisation und den Projekten sowie der Zusammenhang zwischen den Projekten und den Strukturen und Arbeitsformen im Anwendungsbereich. In vielen Entwicklerorganisationen hat sich herausgestellt, daß die organisatorische Trennung in Sparten und Bereiche wie Vertrieb, dezentrale und zentrale Entwicklung teilweise zu erheblichen Reibungsverlusten in Projekten führt, die nach den WAM-Prinzipien organisiert sind. Dies gilt aus unserer Sicht für alle anwendungsorientierten und evolutionären Projektstrategien. Es sollte daher darüber nachgedacht werden, diese Trennung auf der Projektebene und innerhalb einer Projektfamilie aufzuheben. Die zweifelsohne notwendige Spezialisierung der einzelnen Mitarbeiter und ihre unterschiedlichen Kenntnisse müssen in fachlich integrierten Teams fruchtbar genutzt werden. Als Gegensatz finden wir noch immer die bereichsorientierte Projektorganisation, in der bestimmte Tätigkeiten oder bestimmte Projekttypen nur von den Mitarbeitern einer bestimmten Abteilung übernommen werden. Letztlich gilt dies nicht nur für die Entwicklung. Erfahrungen zeigen, daß dies auch für die Fehlerbehebung und die Weiterentwicklung von großer Bedeutung ist.

5

1128 Fachliche Integration


5.1


1129

Aber gerade für Projekte, in denen interaktive Arbeitsplatzsysteme entwickelt werden sollen, ist es unumgänglich, daß unterschiedliches softwaretechnisches Wissen im Projektteam vertreten ist. Dies wird im Regelfall aus den Bereichen Entwicklung interaktiver Software, verteilte Systeme, Netze, Datenbanken und Großrechneranwendungen kommen. Der softwaretechnischen Integration innerhalb der Entwicklerorganisation muß die anwendungsfachliche Integration entsprechen. Hier zeigen sich, zumindest für das Dienstleistungs- und Finanzgeschäft, ähnliche Tendenzen wie für die Entwicklerorganisationen. Der gemeinsame Faktor ist die Anwendungsorientierung, die im Anwendungsbereich heute als Kundenorientierung bezeichnet wird. Damit gemeint ist die Tendenz im Kundengeschäft, weg von der traditionellen Spartentrennung und hin zu Kundennähe und umfassender Sachbearbeitung zu gelangen. Anders formuliert: Die Prozesse und die Organisation eines Unternehmens sollen auf den Kunden ausgerichtet werden, um eine maximale Kundenzufriedenheit zu garantieren (vgl. [Herzwurm et al. 96]). Neben der dazu notwendigen Generalisierung zeichnet sich ab, daß für sehr anspruchsvolle Dienstleistungen und Produkte immer eine Spezialisierung in Beratung und Verkauf existieren wird.

5


5.1


1130

Hier muß also die »natürliche« Aufteilung von Projekten und Entwicklungsaufgaben entlang der traditionellen Produktlinien und Sparten einer Anwenderorganisation überdacht werden. Wie sich dies auf die Gestaltung von Anwendungssoftware auswirkt, haben wir in den Kapiteln 2.5 und 3.3.3 beschrieben. Für die anwendungsfachliche Integration folgt daraus: Um die inhaltliche Stimmigkeit der einzelnen Dokumente und damit die Gebrauchsqualität des Anwendungssystems zu sichern, müssen mit Blick auf die Strukturen und erkennbaren Veränderungen im Anwendungsbereich integrierte Teams gebildet werden, die aus anwendungsnahen und softwaretechnisch orientierten Mitgliedern bestehen. Als Beispiele für die Kundenorientierung einer Bank sehen wir die Zusammenführung von Aktiv- und Passiv-Kundenberatung, Schalter sowie Wertpapiergeschäft in Service-Zentren und die anstehende Integration weiterer Verkaufsangebote (z.B. Versicherungen, Immobilien, Bausparen). Es zeichnet sich ab, daß sich neue Arbeitsplatztypen im Kundenbereich herausbilden werden – etwa qualifizierte Kundenberatung, Standardberatung, Schaltergeschäft und Selbstbedienung. Dagegen wird im Marktfolgebereich absehbar die traditionelle spartenorientierte Aufteilung erhalten bleiben, die sich aus der fachlich notwendigen Spezialisierung ergibt. Im Mittelbereich bewegt sich schließlich das Controlling und die Banksteuerung – hier sind wahrscheinlich sowohl kundenzentrierte als auch produkt- oder spartenorientierte Zugänge zu schaffen. Diese unterschiedlichen Tendenzen führen zu verschiedenen Einsatzkontexten, in denen zuge-

5

Beispiel für Kundenorientierung


5.1


1131

schnittene Arbeitsplatzsysteme entwickelt werden, die aber auf einer gemeinsamen fachlichen und technischen Basis stehen müssen. Es empfiehlt sich, zunächst mit den kundennahen Bereichen zu beginnen, da dort die neue Orientierung am deutlichsten sichtbar ist und von dort aus Rückwirkungen auf die anderen Bereiche am ehesten abgeschätzt werden können.

Organisationsentwicklung

Evolutionäre Systementwicklung nach dem WAM-Ansatz erfordert eine hohe fachliche und organisatorische Integration des Projektteams (s. Kapitel 5.1.1). Dies hat meist organisatorische Konsequenzen für die Entwicklerorganisation. Sollen mehrere objektorientierte Projekte oder ganze Projektfamilien in einem Unternehmen angesiedelt werden, dann liegt der Einsatz von Rahmenwerken nahe. Dies bedingt weitere Umstellungen in der Organisationsstruktur – die Einrichtung einer Architekturgruppe und eines Teams für die Produktplanung sollten dann überlegt werden.

Thema

Schon die Einrichtung anwendungsorientierter Projekte zur Entwicklung von interaktiven Arbeitsplatzsystemen erfordert eine Veränderung der Entwicklerorganisation. Unsere Forderung nach fachlicher und organisatorischer Integration kann selten in den bestehenden Organisationsstrukturen reibungsfrei umgesetzt werden. Allein die

Diskussion

5


5.1


1132

Frage, aus welcher Abteilung die Projektleitung kommt und wie ihr die Mitarbeiter aus verschiedenen anderen Abteilungen unterstellt werden, bereitet in der Praxis Schwierigkeiten, die den Ablauf eines Projektes hemmen. Unser Konzept eines Kernsystems mit Ausbaustufen geht aber in seinen Konsequenzen über diese Organisationsfragen hinaus. Denn ein solches System mit seinen unterschiedlichen Arbeitsplätzen und Komponenten läßt sich heute eigentlich nur sinnvoll unter Verwendung von (Anwendungs-) Rahmenwerken konstruieren. In Kapitel 3.3 haben wir die dazu passenden fachlichen und softwaretechnischen Konzepte beschrieben. Wir stellen hier die Frage nach den Konsequenzen für die Organisation und das Management des Gesamtprozesses. Dabei müssen wir klar sagen, daß nur wenige Entwicklerorganisationen heute die Umwandlung von der konventionellen zu einer anwendungsorientierten und evolutionären Softwareentwicklung vollzogen haben. Die nachfolgenden Überlegungen basieren auf ersten Erfahrungen, die aber bereits die beschriebenen Tendenzen deutlich werden lassen. Abbildung 5-5 (s. S. 561) soll das Zusammenspiel von Entwurfsmustern, Rahmenwerken und Anwendungskomponenten bei der Entwicklung eines Anwendungssystems mit verschiedenen Ausbaustufen zeigen. Dabei kommt der Rahmenwerkarchitektur die zentrale Bedeu-

5


5.1


1133

tung für die technische und fachliche Integration des Anwendungssystems zu. Um dies in der Praxis umzusetzen, sind unterschiedliche Instanzen notwendig, die wir im einzelnen vorstellen: ❑ Die Rolle des Anwendungsbereichs als der zentralen anwen-

dungsfachlichen Instanz für die Anwendungsentwicklung wird in diesem Handbuch ausführlich in den verschiedenen Aspekten geschildert. Wir stellen hier in den Vordergrund, daß der Anwendungsbereich wesentlich die Anforderungen an ein System bestimmt und seinen Gebrauchswert feststellt. ❑ Die Entwicklung der Anwendungskomponenten, aus denen

die Ausbaustufen eines Systems zusammengesetzt werden, findet in einzelnen Projektteams statt. Neben dem fachlichen Verständnis der Aufgaben des Anwendungsbereichs und seiner Anforderungen sind technisch konstruktive Grundlagen für diese Arbeit erforderlich. Dazu gehört der Einsatz vorhandener Rahmenwerke und die Verwendung der verschiedenen Muster, besonders von Entwurfsmustern. Aus der Projektarbeit kommen aber auch die Impulse zur Weiterentwicklung von Rahmenwerken und für die Formulierung neuer Muster. Die Qualifikation der Teammitglieder ist weiter oben bereits diskutiert worden. Neben dem unabdingbaren Anwendungswissen ist

5


5.1


1134

eine solide softwaretechnische Basis unabdingbar. Differenzierte Kenntnisse sind erforderlich in dem Umfang, wie Teammitglieder vorrangig für die Werkzeug-, Material- oder Automatenentwicklung eingesetzt werden. In der Entwicklung werden Entwurfs- und Programmiermuster verwendet. Sie bilden einen wesentlichen Teil der gemeinsamen Projektsprache unter Entwicklern. ❑ Die Gestaltung des Anwendungssystems mit seinen Kompo-

nenten und Ausbaustufen ist aber nicht nur abhängig von den konkreten Anforderungen aus dem Anwendungsbereich. Wesentlich für die Entwicklerorganisation sind die strategischen Entscheidungen bei der »Entwicklung einer Produktlinie«. Dafür zuständig ist die Instanz, die wir in Abbildung 5-5 Produktentwicklung nennen. Diese Instanz hat die Aufgabe, sowohl die Neuentwicklung von Anwendungskomponenten als auch den Einsatz der verschiedenen Ausbaustufen anwendungsfachlich und unternehmenspolitisch zu koordinieren. Dabei bewegt sich diese Gruppe im Spannungsfeld zwischen den Anforderungen der Anwender einerseits und der technischen Machbarkeit und den strategischen Erwägungen der Entwicklerorganisation andererseits. Entsprechend breit muß

5


5.1


1135

die Qualifikation der Mitarbeiter in diesem Bereich sein. Hier ist anwendungsfachliches Wissen ausschlaggebend. Zusätzlich muß aber ein solides Verständnis der technischen Konzepte der objektorientierten Anwendungsentwicklung hinzukommen. Entsprechend stellen Konzeptionsmuster einen wichtigen Teil der Sprache der Produktplaner dar. Sie ermöglichen eine gute Zusammenarbeit mit den Entwicklern und Architekten. Schließlich gehört ein Gespür für die unternehmenspolitische Strategie und Managementfähigkeiten zum Handwerkszeug dieser Gruppe. ❑ Das Rückgrat der hier beschriebenen Anwendungsentwick-

lung stellt die rahmenwerkbasierte Architektur dar. Ihre Konzeption und Weiterentwicklung liegt in den Händen der Architekturgruppe. Wie in Kapitel 3.3.3 beschrieben, sind darin grundlegende technologische Konzepte, die prinzipielle Konstruktion von Werkzeugen und vor allem die zentralen fachlichen Konzepte vorgegeben. Die Architekturgruppe muß aus ihrer Sicht des Gesamtsystems die fachlichen Abstimmungen zwischen den Projekten über die zentralen Begriffe des Gegenstandsbereichs initiieren. Sie muß darauf achten, daß diese Begriffe das konsistente Fundament des Gesamtsystems bilden.

5


5.1


Abb. 5-5

Anwendungsbereich Anforderung Anforderung Anforderung

Produktentwicklung

Instanzen bei der Ausbaustufe Ausbaustufe Ausbaustufe Ausbaustufe

AnwendungsAnwendungskomponente Anwendungskomponente Anwendungskomponente komponente

1136 anwendungsorientieren Softwareentwicklung

Architekturgruppe

RahmenRahmenwerk Rahmenwerk werk

EntwurfsEntwurfsmuster Entwurfsmuster muster

Projektteam Projektteam Projektteam Projektteam

Die Architekturgruppe muß also sicherstellen, daß die Architektur mit ihren Rahmenwerken tatsächlich in den einzelnen Projekten eingesetzt wird. Organisatorisch hat sich dabei bewährt, daß jeweils ein Mitglied der Archtitekturgruppe in je-

5


5.1


1137

dem Projekt als »Berater« aktiv mitarbeitet. Das sichert den Wissenstransfer in beide Richtungen: vorhandene Rahmenwerke werden eingesetzt, Anforderungen für die Weiterentwicklung von Rahmenwerken können in der Architekturgruppe aufgegriffen werden. Zur softwaretechnischen Realisierung werden dabei Entwurfsmuster verwendet oder neue erarbeitet. Sie bilden und beschreiben die »interne« Struktur des Rahmenwerks. Neben diesen wesentlichen Arbeiten mit und an einer rahmenwerkbasierten Architektur müssen aber unter dem Gesichtspunkt eines fachlichen Anwendungsrahmens viele »Querschnittsaufgaben« erledigt werden, die projektübergreifend anzugehen sind. Dazu gehört z.B. die Entwicklung eines generellen Dokumentwesens in der Anwenderorganisation genauso, wie allgemeine Gestaltungsprinzipien für interaktive Werkzeuge. Es bietet sich an, solche Querschnittsaufgaben in den Zuständigkeitsbereich der Architekturgruppe zu geben. Eine weitere wesentliche Aufgabe der Architekturgruppe ist die enge Zusammenarbeit mit der Produktplanung. Bei dieser Bestimmung von Zielen und Prioritäten muß die Architekturgruppe verdeutlichen, welche Entwicklungsoptionen beim jeweiligen Stand der Technologie und Architektur sowie der aktuellen Projektaktivitäten möglich sind.

5


5.1


1138

Aus diesen Überlegungen sollte klar sein, daß hohe Anforderungen an die Mitglieder der Architekturgruppe gestellt werden. Nur die erfahrensten Entwickler sollten dort mitarbeiten. Neben ausgezeichneten softwaretechnischen Kenntnissen mit soliden theoretischen oder konzeptionellen Grundlagen ist auch ausreichendes Anwendungswissen gefordert. Sehr hoch in der Prioritätenliste stehen zudem kommunikative Fähigkeiten. Wir wissen, daß wir damit ein Mitarbeiterprofil zeichnen, das nur von wenigen Personen ausgefüllt werden kann. Damit wollen wir aber verdeutlichen, daß die Anforderungen an anwendungsorientierte Softwareentwicklung sehr hoch gesteckt sind. Jede Entwicklerorganisation sollte daher überprüfen, ob die vorhandenen personellen Ressourcen ausreichen, eine solche Herausforderung anzugehen.

5.1.2 Management Die Aktivitäten des Managementprozesses

Die grundlegenden Aktivitäten des Managementprozesses sind durch den Autor-Kritiker-Zyklus vorgegeben. Analyse, Modellierung und

5

Thema


5.1


1139

Bewertung werden zu Planung, Steuerung und Kontrolle. Jedes Projekt muß inhaltlich und zeitlich geplant, organisiert und kontrolliert werden. Die verschiedenen Aktivitäten des Managementprozesses sind im evolutionären Modell eng an den Aktivitäten des Entwicklungsprozesses ausgerichtet:

Diskussion

❑ Projektplanung: Die Zielvorstellung für das Projekt und seine

Etappen (s. Kapitel 5.1.3) muß erarbeitet und nachvollziehbar dokumentiert werden. Die anwendungsfachliche Vision des zukünftigen Systems ist das treibende Moment eines Softwareprojektes. Das Management muß sicherstellen, daß diese fachliche Vision mit den strategischen Zielen des Unternehmens und den verfügbaren Ressourcen und der verwendeten Technik verträglich ist. ❑ Projektsteuerung: Die Steuerung der verschiedenen Projektak-

tivitäten kann auf verschiedene Art und Weise erfolgen. Dabei lassen sich die verschiedenen Managementstile vereinfachend in ablaufsteuernd und unterstützend einteilen (s. S. 78 und 81). Der ablaufsteuernde Managementstil ist durch Anordnungen von oben und detaillierten Arbeitsvorgaben gekennzeichnet.

5


5.1


1140

Er entspricht dem traditionellen hierarchisch militärischen Führungsstil. Der unterstützende Managementstil paßt eher zu unserer evolutionären Vorgehensweise. Dabei sieht sich der Projektmanager als Trainer, Sprachrohr und Dienstleister für sein Team (vgl. [DeMarco & Lister 91]), der die Möglichkeiten und Randbedingungen schafft, unter denen das Team optimal arbeiten kann. Projektkontrolle: Eine sorgfältige Situationsbestimmung ist die we-sentliche Ausgangslage jedes Zyklus im Managementprozeß. Dabei kommt der aktuellen Situation im Anwendungsbereich ebenso viel Bedeutung zu wie der Situation im Projekt selbst. Entsprechend werden für die Kontrolle auch vorrangig die anwendungsfachlichen Dokumente bewertet und zur aktuellen Situation in Beziehung gesetzt. Die Planungsdokumente werden auf die Einhaltung von Beschlüssen und auf die Umsetzung von Aktivitäten überprüft. Hierbei spielt die Rollentrennung von Autoren und Kritikern eine wichtige Rolle. Es hatsich in Projekten bewährt, Projektsitzungen zu diesen Themen von Teammitgliedern vorbereiten und leiten zu lassen.

5


5.1

Planung •ist nur unter Kenntnis der Situation möglich, •erfordert Wissen um Realisierungsmöglichkeiten.


Kontrolle •ist nur mit Blick auf die Zielvorstellung möglich, •ist selbst ein Steuerungsinstrument, das die Situation verändert.

1141 Abb. 5-6 Zusammenhang der Managementaktivitäten

Steuerung •ist nur im Abgleich von Situation und Zielvorstellung möglich, •verändert Situation und Zielvorstellung.

In Abbildung 5-6 haben wir die Zusammenhänge zwischen den grundlegenden Aktivitäten des Managementprozesses aufgezeigt. Wichtig ist uns dabei, daß keine der Aktivitäten isoliert und ohne Einfluß auf die anderen gesehen werden kann. Damit dieser Zusammenhang gewahrt und in seinen Konsequenzen überblickt werden kann,

5


5.1


1142

schlagen wir in unserem evolutionären Vorgehensmodell den raschen Wechsel zwischen Planung, Steuerung und Kontrolle vor. Umgekehrt erweist es sich als schädlich, diese Aktivitäten zeitlich so weit voneinander zu trennen, wie dies durch die klassischen Phasenmodelle nahegelegt wird. Dort werden die »frühen« Phasen auf die Planung ausgerichtet, dann steuert das Management über lange Zeit nur innerhalb des Plans, um am Projektende die wesentlichen Kontrollen durchzuführen. Daran ändern auch die vielen Meilensteine und Meilensteindokumente nichts, die ja nur eine formale, aber keine inhaltliche Kontroll- und Steuerungsfunktion haben. Die Kontexte des Managementprozesses

Der Managementprozeß bezieht sich auf unterschiedliche Kontexte: Anwendungsbereich, Entwicklungsbereich und Technologiebereich. Alle drei Kontexte beeinflussen den Entwicklungsprozeß und müssen daher vom Managementprozeß berücksichtigt werden.

Thema

Softwareentwicklung als Modellbildung findet in bestimmten Kontexten statt. Wir haben diese als Anwendungsbereich, verwendete Technik sowie Handhabung und Präsentation identifiziert. In ähnlicher Weise beeinflussen Kontexte den Managementprozeß. Zwei Kontexte lassen sich aus dem Bereich des Entwicklungsprozesses übertragen – Anwendungsbereich und Technologiebereich. Der dritte Bereich ist augenfällig, es ist der Entwicklungsbereich, da er der Gegenstand des Managementprozesses ist.

Diskussion

5


5.1

Anwendungsbereich


1143

Technologiebereich

Selfservice

Telefonbanking

Schalter

Z

Z

Kreditgeschäft

Servicecenter

Devisenhandel

Entwicklungsbereich

Kurs Sicherheit

Währung

Abb. 5-7 Die Kontexte des Managementprozesses

5


5.1


1144

❑ Anwendungsbereich: Der Bereich, in dem das zukünftige Soft-

waresystem zum Einsatz kommen soll. Der konkrete Anwendungsbereich kann eine Organisation, eine Organisationseinheit oder ein Arbeitsplatztyp sein. Ein verallgemeinerter Anwendungsbereich wird in der Literatur oft als Domäne bezeichnet. Der Anwendungsbereich bestimmt vorrangig, wie ein Projekt ausgerichtet und durchgeführt wird. Er legt auch die beteiligten Anwendergruppen nahe. Wenn Anwendungsorientierung die grundlegende Vorgehensweise ist, stellt sich in diesem Zusammenhang die Frage, wer alles als Anwender zu betrachten ist. Neben den »unmittelbaren« Benutzern des Anwendungssystems sind sicherlich diejenigen zu betrachten und geeignet in den Prozeß zu integrieren, die mittelbar von den Ergebnissen eines Anwendungssystems und den veränderten Arbeitsprozessen betroffen sind. Oft stellt sich auch die Frage nach den »Kunden der Kunden«, d.h. beispielsweise im Bankenbereich, daß nicht nur die Bankangestellten, sondern vor allem die Bankkunden als (meist) mittelbare Nutznießer eines Anwendungssystems zu betrachten sind. ❑ Technologiebereich: Das technologische Umfeld, in dem das

Softwareprojekt stattfindet. Dieses technologische Umfeld

5


5.1


1145

bestimmt, welche architektonischen Konzepte, Gestaltungsrichtlinien und Technikmodelle sowie welche konkreten technischen Komponenten der Systembasis für den Entwicklungsprozeß ausgewählt und eingesetzt werden können. Die Einschätzung des Technologiebereichs ist eine eigenständige und permanente Aufgabe, die oft vom Management unterschätzt wird. ❑ Entwicklungsbereich: Der Bereich, in dem das Softwaresystem

stattfindet. Dies kann die hauseigene IT-Abteilung, ein im Auftrag handelndes Softwarehaus oder ein Hersteller von vorgefertigten Softwarekomponenten sein. Wir betrachten hier keine Entwickler von Standardprodukten, die für einen »anonymen Markt« arbeiten, da wir in diesem Bereich zu wenig Erfahrung besitzen. Die Aktivitäten des Managementprozesses orientieren sich an den Kontexten. In diesem Handbuch steht dabei der Anwendungsbereich im Vordergrund. Aber auch die anderen Kontexte verdienen Beachtung. So bedeutet Planung nicht nur festzulegen, welche gegenwärtigen und zukünftigen Aufgaben des Anwendungsbereichs auf welche Weise vom zukünftigen System unterstützt werden sollen. Bezogen auf die Technologie stellt sich die Frage, welche neuen Techniken und Mit-

5


5.1


1146

tel für die Realiserung des Systems notwendig sind und ob neue Technologien aus strategischen oder softwaretechnischen Gründen eingesetzt werden sollen. Oft wird in der Planung der Entwicklungsbereich zu wenig beachtet. Dabei ist die Ausrichtung der Entwicklungsabteilung von großer Bedeutung. Produktlinien müssen erarbeitet werden, und zukünftige Entwicklungen müssen mit der strategischen Personalplanung zur Deckung gebracht werden. Wenn der Einsatz neuer Technologien vorgesehen ist, dann muß die Weiterbildung und Einarbeitung der Teams geplant werden. Entsprechend stellen sich auch für die Kontrolle in einem Projekt Fragen aus den verschiedenen Kontexten. Die Situationsbestimmung im Anwendungsbereich gibt die Aspekte vor, die im Technologiebereich zu betrachten sind. Welche Systembasis ist vorhanden und in welchem Umfang ist sie für die anstehende Entwicklung geeignet? Hierher gehört die Diskussion um die sogenannten Altlasten. Was ist an vorhandenen Systemkomponenten fachlich und technisch wiederverwendbar, und welcher Aufwand soll in die Modernisierung oder Sanierung gesteckt werden? Diese Fragen sind wesentlich und werden heute in Literatur und Praxis immer wieder angesprochen. Weniger Beachtung findet die Situationsbestimmung im Entwicklungsbereich. Denn oft werden Projektteams mit den gerade verfügbaren Mitarbeitern bestückt, ohne zu klären, welche fachlichen und

5


5.1


1147

technologischen Anforderungen im Rahmen des Projektes zu erwarten sind, und wer diesen Erwartungen gerecht werden kann. Auf den besonderen Wert der anwendungsfachlichen Qualifikation gehen wir in Kapitel 5.2 noch genauer ein.

5.1.3 Projektplanung Die Projektplanung orientiert sich an einer expliziten Zielsetzung und identifiziert Teilziele. Mit Blick auf die Teilziele wird das Kernsystem und seine Ausbaustufen bestimmt. Ein Teilziel wird durch die Entwicklung des Kernsystems oder einer Ausbaustufe markiert. Jede dieser Systemversionen wird in Projektetappen entwickelt, die der Grobplanung dienen. Innerhalb einer Projektetappe wird ein Projekt detailliert nach qualitativen Gesichtspunkten geplant.

Thema

Die Projektplanung nach dem WAM-Ansatz muß als Teil einer einheitlichen Vorgehensweise betrachtet werden. Die in diesem Handbuch vermittelte Sichtweise von Softwareentwicklung und -konstruktion ist die Voraussetzung, die hier nicht weiter diskutiert wird. Insbesondere muß für jedes Softwareprojekt geklärt sein, daß prinzipiell ein evolutionäres Prozeßmodell verwendet werden soll. Ebenso sollte ein Leitbild für die Entwicklung festgelegt sein.

Diskussion

5


5.1


1148

Der zentrale Bestandteil jeder Projektplanung ist die Festlegung der Zielsetzung. Dabei müssen wir uns mit dem Dilemma auseinandersetzen, daß oft keine klaren Vorstellungen über die fachlichen (und technischen) Ziele bei Projektbeginn vorliegen oder, wie wir auf den Seiten 550ff. diskutieren, vorliegen können. Die Aufteilung in Teilziele führt zu einer Unterteilung des zukünftigen Anwendungssystem in ein Kernsystem und seine Ausbaustufen. Je nach Priorität und Verfügbarkeit können Kernsystem und Ausbaustufen um Spezialsysteme ergänzt werden. Diese fachlich motivierte Strukturierung des Anwendungssystems ist Grundlage der konkreten Projektplanung. Jede zu entwickelnde Systemversion wird in Zyklen auf zwei Ebenen geplant: ❑ Grobplanung: Ausgehend von wichtigen Zielen und Teilzielen

legen wir die großen Etappen eines Projektes fest. ❑ Feinplanung: Innerhalb einer Projektetappe werden die Aktivi-

täten und Zuständigkeiten mit Hilfe von Referenzlinien geplant.

5


5.1


1149

Zielsetzung

Jedes Entwicklungsprojekt sollte eine eindeutige anwendungsfachliche Zielsetzung haben. Anwendungssoftware kann bei der Umsetzung dieser Ziele nur Mittel zum Zweck sein. Für die Projektplanung ist es wichtig, die Zielsetzung zu erkennen und eigenständige Teilziele zu identifizieren.

Thema

Die Zielsetzung eines Projektes kann unter verschiedenen Gesichtspunkten betrachtet werden:

Diskussion

❑ Was ist Sinn und Zweck des Softwareprojektes? Anders

gefragt: Zu welchem Unternehmensziel soll das Entwicklungsprojekt einen Beitrag leisten? ❑ Welche Vorgaben im Anwendungsbereich sollen erreicht wer-

den? Müssen sie mit einem Mal erreicht werden, oder lassen sich Schritte auf dem Weg dahin identifizieren? ❑ Welche Mittel aus dem Bereich der Informationstechnologie

(IT, z.B. welche Art von Anwendungssystem) erfüllen in welchem Umfang das Ziel? Welche Alternativen (z.B. welche organisatorischen Maßnahmen oder welches verfügbare Standardsystem) sind denkbar?

5


5.1


1150

❑ Wer stellt die Zielerreichung fest? Sind es ein oder mehrere Per-

sonen- oder Interessensgruppen? ❑ Welche Zeitvorstellungen gibt es für die Zielerreichung? Wie

flexibel sind diese Zeitvorstellungen? Offenbar sind diese Fragen zur Zielsetzung nicht immer eindeutig zu beantworten. Aber es ist wichtig, im Rahmen der Projektplanung immer wieder diese Fragen zu stellen und vorläufig zu beantworten. In der Diskussion mit den Personen oder Gruppen, die die allgemeinen Projektziele vorgeben, sollten aus der allgemeinen Zielsetzung möglichst eigenständige Teilziele herausgearbeitet werden. In einem Bankenprojekt konnten wir beispielsweise zu Beginn folgende Aspekte der allgemeinen Zielsetzung identifizieren:

Beispiel für Zielsetzung

❑ Das Firmenkundengeschäft einer Bank sollte so reorganisiert werden, daß pro Jahr ein Gewinn von 1 Mio. DM in dieser Sparte erwirtschaftet wird. ❑ Im Rahmen der Reorganisation des Firmenkundengeschäfts sollten die Kernprozesse durch ein interaktives Arbeitsplatzsystem unterstützt werden. Dieses Arbeitsplatzsystem sollte zunächst in der hauseigenen ITAbteilung geplant und entworfen werden. Als Realisierungsalternative sollte ggf. eine geeignete Software auf dem Markt eingekauft werden.

5


5.1


1151

❑ Der Vorstand und die Abteilungsleitung wollten in Reviews feststellen, ob das Ziel erreicht ist und welchen Beitrag das Softwaresystem dazu leistet. Zusätzlich sollte die Leitung der zentralen Entwicklungsabteilung die softwaretechnische Qualität des Softwaresystems prüfen. ❑ Als Zeitvorstellung war geplant, innerhalb von zwei bis drei Jahren das gesamte Geschäft in diesem Bereich in allen Filialen zu reorganisieren und durch neue IT zu unterstützen. Nach der Diskussion mit dem Anwendermanagement ließen sich folgende Teilziele herausarbeiten: ❑ Fachlich wurde die Reorganisation des Kreditgeschäfts als prioritär eingeschätzt. ❑ Innerhalb des Kreditgeschäfts wurde die Bilanzanalyse als der Bereich gesehen, der am meisten von einer IT-Unterstützung profitieren könnte. ❑ Das Entwicklerteam erhielt den Auftrag, einen Arbeitsplatz für Firmenkundenberater zu entwerfen, der zunächst den Bereich der Bilanzanalyse abdecken sollte. ❑ Als Zeitraum für ein erstes Pilotsystem wurde ein Jahr vorgegeben.

5


5.1


1152

Kernsystem und Spezialsysteme

Die evolutionäre Entwicklung eines Anwendungssystems bedeutet nicht nur, daß Software in engen Autor-Kritiker-Zyklen realisiert wird. Ebenso wichtig ist, ein komplexes Anwendungssystem in überschaubaren Einheiten zu entwickeln. Das Konzept von Kernsystem und Spezialsystemen gibt eine erste Anleitung zur anwendungsfachlichen Segmentierung von Anwendungssoftware.

Thema

Sind die allgemeine Zielsetzung und Teilziele skizziert, dann kann ein (offenes) Kernsystem definiert werden. Das Kernsystem ist mit den Vertretern der verschiedenen Bereiche abzustimmen. Diese Einigung auf ein Kernsystem stellt einen wesentlichen Erfolgsfaktor für ein komplexes Entwicklungsprojekt dar.

Diskussion

Ein Kernsystem sollte: ❑ einen wichtigen Beitrag zur Erreichung des ersten Teilziels lei-

sten, ❑ dazu die wesentlichen Aufgaben in einer Abteilung (einem Pro-

duktbereich, s. Kapitel 3.3.1) oder in eng kooperierenden Bereichen unterstützen,

5


5.1


1153

❑ einen Satz an elementaren Dienstleistungen als Komponenten

(Werkzeuge, Materialien und Automaten) zur Verfügung stellen, die Grundlage der weiteren Entwicklung sein können, ❑ akute Anforderungen (z.B. gemäß gesetzlicher und betriebs-

wirtschaftlicher Bestimmungen) bedienen und ❑ die Einbindung von Spezialsystemen unterstützen.

Vom Kernsystem sollten Spezialsysteme unterschieden werden. Diese unterstützen mit ihren Komponenten weitgehend eigenständige Aufgaben. Sie können relativ lose mit dem Kernsystem verbunden werden. Damit eröffnet sich die Möglichkeit, Spezialsysteme von anderen Herstellern entwickeln zu lassen oder als fertige Komponenten zu kaufen. Die zeitliche Reihenfolge bei der Einführung der einzelnen Spezialsysteme ist von den Anwendern zu bestimmen. Daraus folgt, daß Anwendungsorientierung an dieser Stelle ein wichtiger Punkt der Projektplanung ist. Grundlage für die Festlegung des Kernsystems und möglicher Spezialsysteme ist ein Verständnis wesentlicher Aufgaben und Arbeitsteilungen im Anwendungsbereich, die sich auf eigenständige Komponenten abbilden lassen. Die Festlegung des Kernsystems und der Spezialsysteme kann daher keine Aufgabe sein, die im Projekt zu

5


5.1


1154

Anfang vollständig zu erledigen ist. Wenn dazu komplexe Kooperationszusammenhänge analysiert werden müssen, sollten Szenarios und Kooperationsbilder erstellt werden (s. Kapitel 5.2.1 und 5.2.5). Damit vergeht einige Zeit, bis eine erste Grobplanung soweit konkretisiert werden kann, daß sich Teilprojekte mit ihren Etappen abzeichnen. In einem Krankenhausprojekt bestand das definierte Kernsystem im wesentlichen aus der Patientenverwaltung und -abrechnung, der entsprechenden Gestaltung von Arbeitsplätzen auf den Stationen im ärztlichen und pflegerischen Bereich sowie aus Basisdienstleistungen für die Stationskommunikation mit verschiedenen Leistungsanbietern wie Radiologie-, Labor- und Küchensysteme (s. Abbildung 5-8).

Beispiel Kernsystem und Spezialsysteme

Durch die Bereitstellung dieser Basisdienstleistungen in eigenen Komponenten für die Kooperation zwischen den Stationen und den Funktionsbereichen konnte sichergestellt werden, daß die Kooperation für die Stationsarbeitsplätze einheitlich gestaltet sind. Da die neuen gesetzlichen Regelungen eine starke Verbindung zwischen administrativen und medizinischen Daten erfordern, sahen wir es als notwendig an, die Patientenverwaltung und -abrechnung mit den klinischen Bereichen im Kernsystem zu integrieren. Insgesamt hat sich aus der großen Anzahl von Anforderungen aus den verschiedenen Abteilungen und Bereichen ein Kernsystem herauskristallisiert, das um verschiedene Spezialsysteme zur Abdeckung der weiteren Anforderungen ergänzt wurde. Die Vorstellung des Kernsystems trug maßgeblich zur Einigung

5


5.1


1155

aller am Prozeß Beteiligten auf ein gemeinsames Projektziel und die verschiedenen Entwicklungsstufen bei. Dadurch wurde das Krankenhausprojekt erst planund durchführbar. Abb. 5-8 Kernsystem mit VerwaltungsSystem

OPSystem

Spezialsystemen RadiologieSystem

LaborSystem

Ke

Patientenverwaltung und -abrechnung

rn

sy

Aufnahme/Verlegung/ Entlassung auf Stationen

st

Diagnoseschlüsselvergabe

em

Kommunikation ...

...

KüchenSystem

DienstplanSystem

5


5.1


1156

Ausbaustufen

Bei einer engen Verzahnung der verschiedenen Abteilungen und Aufgaben wird ein Kernsystem meist noch sehr komplex sein. Entsprechend stellt sich die Frage nach weiteren Aufteilungen und damit verbunden nach fachlich motivierten Reihenfolgen für den Entwicklungsund Planungsprozeß. Daher unterteilen wir komplexe Anwendungssysteme in Kernsystem und Ausbaufstufen.

Thema

Wenn ein Kernsystem aufgrund seiner fachlichen oder technischen Komplexität nicht »am Stück« realisiert werden kann, dann müssen wir es in Ausbaustufen aufteilen. Dazu definieren wir zunächst ein minimales Kernsystem. Ein minimales Kernsystem umfaßt die fachlichen Dienstleistungen, die insgesamt ein minimal anwendungsfachlich und softwaretechnisch funktionstüchtiges Anwendungssystem ausmachen. Dabei helfen folgende Fragen:

Diskussion

❑ Welche Aufgabe im Anwendungsbereich hat die größte fach-

liche Bedeutung? ❑ Welche Aufgabe läßt sich durch wenige Werkzeuge, Materia-

lien und Automaten mit minimalen technischen Aufwendungen gut unterstützen? ❑ Welche Softwareunterstützung bringt für Anwender den mei-

sten erkennbaren Vorteil?

5


5.1


1157

Das minimale Kernsystem hat oft auch eine strategische Bedeutung, da es gewöhnlich das erste größere objektorientierte Anwendungssystem zumindest im Rahmen dieser Vorgehensweise ist. Deshalb sollten die Vorteile des »quick win« genutzt werden, d.h., mit möglichst kleinem Aufwand sollte ein nach außen demonstrierbarer großer Vorteil durch die Einführung des minimalen Systems im Anwendungsbereich realisierbar sein. Gleichzeitig sollte der besondere Charakter des WAMAnsatzes durch einige gut entworfene Werkzeuge mit passenden Materialien deutlich werden. Ist das minimale Kernsystem skizziert, müssen wir klären, wie die für das gesamte Kernsystem konzipierten Dienstleistungen logisch aufeinander aufbauen. Diese sind dementsprechend zu gruppieren und in aufeinanderfolgenden Ausbaustufen des Kernsystems zu plazieren. Eine Ausbaustufe unterstützt durch seine Komponenten zusammengehörige Aufgaben und Tätigkeiten. Diese Komponenten sollten höchstens von den bereits vorliegenden Ausbaustufen abhängig sein. Dazu ist für fachliche Dienstleistungen festzulegen, ab welcher Ausbaustufe ihre Unterstützung frühestens möglich ist. Wenn sich die Planung für eine Ausbaustufe konkretisiert, kann beschrieben werden, welche Anwender bei welchen Aufgaben durch welche Komponenten unterstützt werden und welche technischen und organisatorischen Voraussetzungen dabei zu erfüllen sind.

5


5.1


1158

Durch die sorgfältige Bestimmung des minimalen Kernsystems mit seinen Ausbaustufen lassen sich die Konsequenzen der schrittweisen Systementwicklung und -einführung mit den dadurch entstehenden Zwischenorganisationsformen für Entwickler und Anwender klarer erkennen und planen. Gleichzeitig unterstützen die Ausbaustufen eine genauere zeitliche Planung des Projektes und eine Aufwandsabschätzung. In Abbildung 5-9 greifen wir das Beispiel von Abbildung 5-8 wieder auf und stellen das von uns geplante Kernsystem eines Krankenhausinformationssystems mit Ausbaustufen vereinfacht dar. Das minimale Kernsystem (im Bild mit 0 gekennzeichnet) besteht aus der Patientendatenverwaltung und der -abrechnung. Dadurch konnte ein bestehendes System abgelöst und gleichzeitig die Abrechnung der Leistungen des Krankenhauses sichergestellt werden.

Beispiel Kernsystem mit Ausbaustufe

Ausbaustufe 1 stellt die aktuellen Patientendaten als Material auf den einzelnen Stationen zur Verfügung. Dies erlaubt, Etiketten der Patientendaten zu drucken, wodurch zeitaufwendiges handschriftliches Übertragen auf verschiedene Formulare entfällt. Darüber hinaus kann das Pflegepersonal im Rahmen der Routineaufgaben Aufnahme, Verlegung, Entlassung (A/V/E in der Abbildung) mit entsprechenden Werkzeugen Patientenbetten verwalten sowie Notfallpatienten administrativ aufnehmen. Dadurch hat die Aufnahme immer einen aktuellen Überblick über die Bettenbelegung der einzelnen Stationen und aller erfolgten Verlegungen.

5


5.1


1159

In Ausbaustufe 2 wird die Diagnose- und Prozedurschlüsselvergabe durch das Anwendungssystem eingeführt. Parallel hierzu können andere Dokumentationstätigkeiten, wie die Einstufung der Patienten nach Pflegeintensitäten (PPR), in derselben Ausbaustufe unterstützt werden. Ebenso kann ab dieser Stufe die Bettenplanung insgesamt im Anwendungssystem erledigt werden. Diese Dienstleistungen können aber auch erst in späteren Ausbaustufen eingeführt werden. In Abbildung 5-9 sind diese bereits skizziert. Zwangsläufig ergeben sich aus dieser Systemaufteilung Zwischenorganisationsformen, die in den Planungsprozeß einbezogen werden müssen. So muß bis zur Stufe 5 noch eine konventionelle (physische) Krankenakte vorliegen, obwohl z.B. Untersuchungsanforderungen und Befunde mit Werkzeugen erfaßt und bearbeitet werden. Zeitweise ist zudem in einigen Bereichen ein Parallelbetrieb von elektronischer und konventioneller Aufgabenerledigung notwendig, da z.B. nicht alle Stationen gleichzeitig mit Arbeitsplatzsystemen ausgerüstet werden können und sollen.

5


5.1


1160 Abb. 5-9

Patientenverwaltung

0

Ausbaustufen eines

Patientenabrechnung

1 2

Kernsystems

A/V/E (auf Stationen)

Bettenplanung

Schlüsselvergabe PPR

3 4 5

Leistungsanforderung

Arztbriefschreibung Befundschreibung

Terminkoordination

Pflegedokumentation

Befundübermittlung Kurve

Ärztliche Dokumentation

5


5.1


1161

Zeitabschätzung

Auf der Basis der Zielsetzung und der Aufteilung des Systems in Kernsystem und Ausbaustufen kann eine Zeitabschätzung für die jeweils zu entwickelnde(n) Systemkomponente(n) oder -ausbaustufe(n) erfolgen. Diese Zeitabschätzung sollte sehr grob sein und lediglich eine Aussage zur zeitlichen Machbarkeit liefern.

Thema

In einer ersten Zeitabschätzung geht es darum zu skizzieren, in welchem Zeitraum die angestrebten Komponenten des Anwendungssystems überhaupt realisiert werden können. Als »Faustregeln« können eine Reihe von Erfahrungswerten berücksichtigt werden:

Diskussion

❑ Jeder Entwicklungszyklus eines Prototyps dauert zwischen 3

und 6 Monaten. Die Frage ist also, wieviel Prototyp-Versionen überhaupt entwickelt werden sollen und können. ❑ Interviews und Szenarios bilden eine wesentliche Grundlage

für jedes Entwicklungsprojekt. Je Interview sollte mit Nachbereitung rund ein Tag für das Interviewteam eingeplant werden. Szenarios müssen geschrieben, von den Interviewpartnern gelesen und dann gemeinsam durchgesprochen werden. Entsprechend braucht ein Szenario bei eingespieltem Team rund eine Arbeitswoche. Es muß also kalkuliert werden, wie viele Teams Szenarios erstellen können, wie viele Interviews und Interviewpartner notwendig sind und wie weit sich Arbeit parallelisieren läßt. 5


5.1


1162

❑ Die organisatorische Installation und der Test eines Pilot-

systems im Einsatz erfordert auch einen gewissen Zeitraum, der sich nicht einfach reduzieren läßt. Hier sollte mit 1 bis 3 Monaten gerechnet werden. Aufgrund dieser einfachen Faustregeln (modifiziert durch die eigenen Projekterfahrungen) kann abgeschätzt werden, ob die Zeitvorstellungen des Managements oder der Anwenderorganisation in irgendeiner Weise realistisch sind. Offenkundig wird die Abschätzung um so ungenauer, ❑ je unbekannter der jeweilige Anwendungsbereich ist, ❑ je unbekannter der zu entwicklende Typ von Anwendungssy-

stem und die dabei verwendete Methodik und Technologie ist und ❑ je mehr Systemkomponenten und Ausbaustufen in die Ab-

schätzung eingebezogen werden. Diese Form der Zeitabschätzung sollte nicht mit der üblichen Zeitplanung eines Projektes verwechselt werden. Sie dient als eine Art Machbarkeitstest zur Beantwortung der Frage, ob ein Projekt überhaupt in der gewünschten Form durchgeführt werden kann.

5


5.1


1163

Planung von Projektetappen

Die eigentliche Projektplanung findet auf der Basis von Projektetappen statt. Diese definieren nicht nur überschaubare und jeweils einzeln planbare Projektabschnitte, sie verbinden auch die konstruktive Qualitätssicherung mit einer anwendungsorientierten Vorgehensweise.

Thema

In den Abschnitten über das Kernsystem und seine Ausbaustufen haben wir darauf hingewiesen, wie wichtig die Aufteilung eines komplexen Anwendungssystems in überschaubare Entwurfs- und Konstruktionseinheiten ist. Falls eine solche Einheit etwa als minimales Kernsystem festgelegt ist, dann muß der Entwicklungsprozeß detaillierter geplant werden. Wir führen Projekte zielorientiert durch. Wenn das Ziel für ein Projekt festliegt, können wir überlegen, welche Mittel, d.h. welche Anwendungssystemkomponenten, dazu beitragen, das Ziel zu erreichen. Die Diskussionen über die grobe Zeitabschätzung und die Vorstellungen des Managements führen meist zu einem Fertigstellungstermin für das zu entwickelnde System. Die Grundidee der Planung nach Projektetappen besteht darin, ausgehend von einem solchen Fertigstellungstermin ein Projekt in Etappen zeitlich von hinten nach vorne zu planen. Dies hat einen einfachen Grund: Wir haben oft festgestellt, daß konventionell geplante Softwareprojekte ihr Zeitbudget

Diskussion

5


5.1


1164

teils erheblich überzogen haben. Dagegen ist doch auffällig, daß alle zumindest uns bekannten Konferenzen zu dem Zeitpunkt stattfinden, zu dem sie oft schon lange vorher angekündigt wurden. Offensichtlich ist es also möglich, eine Konferenz termingenau zu planen. Was ist der große Unterschied zwischen konventioneller Projektplanung und Konferenzorganisation? Aus unserer Sicht liegt der Grund weniger darin, daß Konferenzen ein anderer Gegenstand sind als Softwaresysteme. Konferenzen werden schlicht anders geplant, nämlich von hinten nach vorne. Hat sich das Programmkomitee einmal auf einen Ort und Termin für eine Konferenz geeinigt, dann lassen sich bestimmte Zwischenergebnisse an bestimmte Zeiten binden. Sollen z.B. die Tagungsbände an die Teilnehmer verteilt werden, müssen sie zwei bis drei Tage vorher gedruckt beim Veranstalter vorliegen. Dazu müssen aber einen Monat vorher die Druckvorlagen beim Verlag sein. Dieser Termin bestimmt wiederum, wann die inhaltliche Redaktion der Tagungsbände begonnen werden muß. Derartige Überlegungen über zeitliche und logische Randbedingungen lassen sich fortsetzen. So werden Programmkomiteesitzungen, Abgabetermine für fertige Papiere, der Versand von Konferenzankündigungen und anderes geplant und zeitlich festgelegt. Gegen diese Überlegungen läßt sich vorbringen, daß wir bei der Organisation von Konferenzen viel genauer wissen, welche Schritte

5


5.1


1165

und Teilergebnisse notwendig sind und wie sie voneinander abhängen. Allerdings spricht aus unserer Erfahrung nichts dagegen, die grundlegenden Planungsprinzipien auch auf Softwareprojekte anzuwenden. Dazu legen wir ausgehend vom angestrebten Ziel rückwärts die Projektetappen fest. Projektetappen: Projektetappen stellen wesentliche »nach außen sichtbare« Ereignisse im Projektablauf dar. Sie werden mit Blick auf das Gesamtziel und die daraus abgeleiteten Teilziele festgelegt oder vereinbart Dabei legen sie den Umfang der zu realisierenden Systemversion fest Eine Projektetappe ist immer an eine demonstrierbare Version (meist ein Prototyp) des zu entwickelnden Systems gebunden und definiert einen Zeitpunkt, zu dem ein Projektteilziel erreicht sein soll. Jede Projektetappe wird detailliert durch Referenzlinien geplant. Dies ermöglicht eine Feinkontrolle des Projekts. Die Auswertung einer Projektetappe führt oft zur Revision der weiteren Projektplanung.

Die Idee der Projektetappen ist also, jede einsetzbare Version oder Ausbaustufe eines Anwendungssystems selbst wieder in Teilschritten

5


5.1


1166

zu realisieren und diese Teilschritte für alle Beteiligten offenzulegen. Damit macht eine Projektetappe einen Teilerfolg für alle Beteiligten sichtbar und dient gleichzeitig als Steuerungsinstrument für die weitere Planung (vgl. [Frei et al. 96]) Jede Projektetappe wird mit einer Veranstaltung abgeschlossen, bei der ein entsprechender Prototyp oder die Systemversion vorgeführt und bewertet wird. So wird festgestellt, ob das Etappenziel erreicht ist. Eine solche Veranstaltung kann ein formales Review mit Anwendern sein; es kann auch eine einfache Präsentation vor einem Projektausschuß sein. Wichtig ist nur, daß für die wesentlichen Gruppen und »Entscheidungsträger« der Projektfortschritt und mögliche Probleme erkennbar werden. Am Ende jeder Projektetappe wird die Projektplanung inhaltlich und zeitlich revidiert. Dabei werden verschiedene Gesichtspunkte beachtet: ❑ Ist das angestrebte Etappenziel erreicht worden? Wenn nein,

läßt es sich prinzipiell noch erreichen? ❑ Was bedeutet das Etappenergebnis für die kommende Etappe?

Wenn das Etappenergebnis schlechter als geplant war, wie wirkt sich dies auf die kommende Etappe aus? Müssen Änderungen in der Arbeitsverteilung vorgenommen werden oder ist das kommende Etappenziel ebenfalls gefährdet?

5


5.1


1167

❑ Welche Möglichkeiten bestehen bei einem unbefriedigenden

Etappenergebnis, mit reduzierten Mitteln die Teilziele oder das Gesamtziel doch noch zu erreichen? Muß die Planung aufgrund der Auswertung einer Etappe revidiert werden, dann orientieren wir uns wieder am Gesamtziel. Soweit überhaupt nur möglich sollte ein Projekt an diesem Ziel festhalten und sich bei Problemen und zeitlichen Engpässen fragen, ob das Ziel nicht mit weniger oder anderen Mittel erreicht werden kann. Wir haben in Projekten immer wieder festgestellt, daß ein gegenüber der ersten Planung »schlankeres« Anwendungssystem oder eine reduzierte Ausbaustufe aus Sicht der Anwender eine völlig akzeptierte und fast gleichwertige Lösung ihrer akutellen Probleme darstellte. Projektetappen sollten jeweils einen Zeitraum von 6 Wochen bis 3 Monaten einnehmen. Viele kurze Etappen sind nicht gut überschaubar und führen zur Hektik. Zu große Zeitabstände sind schwer planbar und gefährden den Autor-Kritiker-Zyklus mit den Anwendern und dem Management. In der Praxis hat es sich bewährt, die Planung von Projektetappen im Team zu diskutieren. Für Projekte mit kleinen Teams kann ein solcher Plan auch gemeinsam erarbeitet werden. Für größere Projektteams kann die Planung vorbereitet und dann in einer Projektsitzung

5


5.1


1168

diskutiert, gegebenenfalls revidiert und verabschiedet werden. Im Sinne der Anwendungsorientierung sollten die Anwender ebenfalls Einfluß auf die Planung haben. Zumindest alle Termine, die für die Anwender wesentlich sind, sollten mit ihnen abgestimmt werden.

In Abbildung 5-10 haben wir das Beispiel für Zielsetzung (s. S. 568) wieder aufgegriffen und zeigen, wie die dort geschilderte Zielsetzung umgesetzt werden kann. Dazu ist ein minimales Kernsystem definiert worden, das jetzt mit Hilfe von Projektetappen geplant wird. Wichtig ist hier wieder unsere Vorgehensweise, diese Planung von hinten nach vorne anzulegen. In diesem Fall nehmen wir den 15.02.97 als Fertigstellungstermin für dieses Kernsystem an. Alle weiteren Termine sind von diesem Termin an zurückgerechnet.

5

Beispiel für die Planung von Projektetappen


5.1


Entwicklung eines Arbeitsplatzsystems für die Bilanzanalyse Gesamtziel

Etappe

Der Arbeitsplatz für Firmenkundenberater soll so ausgestattet werden, daß die wesentlichen Aufgaben bei der regelmäßigen Bilanzanalyse unterstützt werden. Umsetzung Termin

Vorstand akzeptiert Demonstrationsprototyp auf der grundlegendes Konzept Basis von ersten Szenarios, Glossareinträgen und Systemvisionen Laborprototyp mit Verbindung zu Zentrale Entwicklung akzeptiert technisches Host und relationaler DB; erste Testdaten können ausgetauscht werden Konzept Anwendermanagement Prototyp mit Werkzeugen zur Bilanzerfassung und Risikoanalyse und Vorstand akzeptieren Fachkonzept Anwender akzeptieren Pilotsystem auf der Basis des letzten Prototyps bei 2 Banken im Funktionalität und Testeinsatz Handhabung Revision nimmt Pilotsystem im Test abgenommen; System ab alle Systemdokumente laut Projekthandbuch erstellt Workshop; Pilotsystem in 2 Banken Vorstand und Anwenim Echtbetrieb dermanagement von Machbarkeit überzeugt

5

1169 Abb. 5-10 Beispiel für Projektetappen

31.03.96

16.05.96

30.09.96

01.12.96

15.01.97

15.02.97


5.1


1170

Feinplanung anhand von Referenzlinien

Die Planung nach Projektetappen ist noch so grob, daß daraus keine Arbeitspakete und Zuständigkeiten erkennbar sind. Innerhalb einer Etappe wird daher eine Feinplanung anhand von Referenzlinien erstellt.

Thema

Auf der Ebene der Verteilung von Aufgaben und Zuständigkeiten macht die Planung nach Projektetappen keine Aussagen. Diese feingranulare Planung ist nach unserer Erfahrung erst auf der Ebene der jeweils aktuellen Etappe notwendig und sinnvoll. Dazu verwenden wir die sogenannten Referenzlinien.

Diskussion

Referenzlinien: Referenzlinien dienen der Feinplanung der Projektarbeit innerhalb einer Etappe und der konstruktiven Qualitätssicherung. Sie werden im Entwicklungsteam festgelegt und beschreiben Arbeitspakete, die sich auf qualitative oder quantitative Dokumentzustände oder auf überprüfbare Ereignisse beziehen. Eine Referenzlinie hat immer einen Verantwortlichen und wird regelmäßig überprüft. Die beteiligten Entwickler schätzen den jeweiligen Aufwand und Zeitbedarf ab.

5


5.1


1171

In einer Referenzlinie wird vorrangig beschrieben, welche Qualität ein Dokument oder eine Menge von Dokumenten als nächstes aufweisen soll. Idealerweise sollen die Dokumente dann so lange bearbeitet werden, bis der gewünschte (und überprüfbare) Zustand erreicht ist. Gleiches gilt auch, wenn in Referenzlinien Ereignisse festgelegt werden. Wichtig ist, daß für eine Referenzlinie bestimmt wird, wer dafür verantwortlich ist, daß sie erreicht wird. Dies muß nicht bedeuten, daß die verantwortliche Person die Arbeit alleine erledigt. Es muß nur klar sein, wer in dieser Frage »aktiv« ist. Im Sinne unserer allgemeinen Vorgehensweise werden zu einer Referenzlinie fachlich und an Teilzielen orientierte Tätigkeiten an zusammengehörigen Dokumenten zusammengefaßt. Die jeweiligen Aufgabenpakete sollten so klein sein, daß sie von wenigen Personen in einem überschaubaren Zeitraum erledigt werden können. Dadurch löst sich auch ein scheinbarer Widerspruch: Wir haben gesagt, daß Referenzlinien nur an Qualitätsmerkmalen orientiert sein sollten und nicht an der Zeit. Gleichzeitig fordern wir, daß mit Referenzlinien Zeit- und Aufwandsschätzungen verbunden werden sollten. Die Erfahrung zeigt, daß wenn Referenzlinien im Team verteilt werden, diejenigen, die sich für eine Referenzlinie verantwortlich erklären, meist ein sehr gutes Gefühl dafür haben, wie lange sie für die Bearbeitung benötigen.

5


5.1


1172

Referenzlinien sollten also gemeinsam im Team diskutiert werden. Ob sie auch dort erarbeitet werden, hängt von der Teamgröße und der Komplexität des Projektes ab. Unabhängig davon bieten sich bestimmte Darstellungsmittel an. Wir haben gute Erfahrungen mit Wandbildern gemacht, auf denen in Tabellenform Referenzlinien und personelle Ressourcen dargestellt werden. Je nach Anordnung lassen sich sowohl die logischen Zusammenhänge von Referenzlinien darstellen als auch zeitliche Vorgaben planen und diskutieren. Wir können aus der Erfahrung berichten, daß sich die hier beschriebenen Planungsverfahren auch für Projekte in sehr kritischen Anwendungs- und Technologiebereichen bewährt haben. Die grundsätzlich zyklische Vorgehensweise und die Orientierung an lauffähigen Prototypen und Systemversionen für die Projektetappen sind offenbar die entscheidenden Erfolgsfaktoren. Die zyklische Vorgehensweise hilft, in einem Projekt auch mit Unwägbarkeiten zurechtzukommen. Die konkreten und vorzeigbaren Zwischenergebnisse motivieren das Team und demonstrieren einen erkennbaren Projektfortschritt gegenüber den »Außenstehenden«.

5


5.1


Wir greifen wieder das Beispiel des Arbeitsplatzsystems für Firmenkundenberater auf. In Abbildung 5-11 sind die Referenzlinien in Anlehnung an eine WozuTabelle (s. Kapitel 5.2.6) aufgelistet. Genannt sind jeweils die Verantwortlichen (mit Namenskürzeln), die Referenzlinie, der Zweck, der geschätzte Aufwand in Personentagen und schließlich die Art der Überprüfung der Referenzlinie. Wichtig ist hier nicht die Form der Präsentation; sie soll nur andeuten, welche Überlegungen bei der Ausarbeitung von Referenzlinien eine Rolle spielen. Das Beispiel zeigt, daß Referenzlinien sehr fein geplant werden können, hier im Bereich eines bis weniger Personentage. Eine derartig feingranulare Planung empfiehlt sich natürlich nur in Projekten, die durch enge Termine und hohe Unsicherheitsfaktoren bestimmt sind. Allerdings zeigen Erfahrungen, daß andererseits keine zu großen Arbeitspakete geschnürt werden sollten, da diese schlecht abschätzbar sind und die Rückkopplung zur Kontrolle der Planung zu schwach wird.

1173 Beispiel für die Planung von Referenzlinien

In Abbildung 5-12 sind die Referenzlinien Grundlage für eine detaillierte Zeitplanung. In der Kalenderübersicht, die hier als Beispiel in Wochen unterteilt ist, sind zunächst die Namenskürzel aller Teammitglieder eingetragen. Die Kästen sollen »Fehlzeiten« aus Sicht des Projektes symbolisieren, d.h. Tage wie Urlaub oder Gremiensitzungen, an denen das Teammitglied nicht für die eigentliche Projektarbeit zur Verfügung steht. Dieser Teil der Übersicht wird meist zu Beginn einer Planungssitzung erstellt und verdeutlicht oft für alle Beteiligten in überraschender Weise, welches Zeitbudget überhaupt verfügbar ist.

5


5.1


Wer

macht Was

Wozu

Wie lange

P.B.

Terminabsprache mit Leitern Firmenkundengeschäft Interviewleitfaden ausarbeiten Interviews mit FirmenkundenBeratern Szenarios zu Bilanzanalyse schreiben

Vorbereitung der Interviews

1 PT E-Mail an Team (Personentag) 1 PT Teamdiskussion

R.S. P.B.

A.S.

D.M.

M.W.

Rahmenwerk für Werkzeuge implementieren Prototyp Bilanzeingabe-Werkzeug implementieren

Vorbereitung Interviews Grundlage für Szenarios

Wie geprüft

1174 Abb. 5-11 Beispiel für Referenzlinien

15 PT

Eintrag im Projekttagebuch

Grundlage für Rückkopplung und Werkzeugvision Grundlage für Werkzeugbau

5 PT

Verteilung an Team

12 PT

erster Teil eines Prototyps

8 PT

Laborprototyp mit Rahmenwerk lauffähig Prototyp lauffähig

5


5.1


1175

Im unteren Teil des Kalenders sind dann die einzelnen Referenzlinien eingetragen. Es ist dargestellt, wann diese Referenzlinien bearbeitet werden. Um die Abbildung im Buch nicht unübersichtlich zu machen, haben wir die Querbezüge zwischen dem unteren und oberen Teil weggelassen. Es liegt natürlich nahe, in den Spalten der jeweiligen Teammitglieder nicht nur zu notieren, wann sie nicht für das Projekt arbeiten, sondern auch wann sie mit welcher Referenzlinie beschäftigt sind. Wer

Wann

Was

KW35

A.S.

■■■■

Abb. 5-12 KW36

KW37

KW38

■■■

■■ ■■■■■

D.M.

Beispiel für Terminplanung mit Referenzlinien

■■■■■

M.W. ■

P.B.

■

■ ■■■

Interviews

Prototyp

■■ ■■

Szenarios Rahmenwerk

■

■

Terminabsprache Interviewleitfaden

■

■■■■■

R.S.

■■■

■■■■■

■■

■

■■■■ ■■■■

■■■■

5


5.1


1176

5.1.4 Einführung eines Anwendungssystems nach WAM: ein Beispiel aus dem Bankbereich Obwohl eine Reihe von Anwendungssystemen nach dem WAMAnsatz entwickelt und eingesetzt worden sind, gibt es nur wenig Erfahrung mit der systematischen Einführung umfassender Arbeitsplatzanwendungen in unterschiedlichen Unternehmen. Eine Ausnahme bildet das GEBOS-System, das in der RWG, Stuttgart entwickelt wurde. In unserem Zusammenhang ist dieses Kooperationsprojekt von besonderer Bedeutung, da die RWG neben der Entwicklung auch eine Beratung für die systematische Einführung des Systems im Unternehmen und seinen effizienten Einsatz als Dienstleistung anbietet. Wir erläutern zunächst die allgemeinen Prinzipien, die das Unternehmen mit der Einführung des GEBOS-Systems verfolgt und geben dann Beispiele, wie die Einführungsstrategie umgesetzt wurde. Die RWG ist eine Servicezentrale für genossenschaftliche Organisationen, vorrangig Volksbanken und Raiffeisenkassen. Sie ist verantwortlich für die rechnergestützte Abwicklung der finanziellen Transaktionen von ca. 370 selbständigen Banken. Zunehmend entwickelt die RWG auch Anwendungssysteme auf PC-Basis für den Einsatz im Bankenbereich, seit 1989 nach dem WAM-Ansatz (vgl. [Bürkle et al.

5

Die Entwicklungsorganisation


5.1


95]). Zur Zeit sind 522 Mitarbeiter überwiegend in der Produktion, im Marketing und in der Entwicklung beschäftigt. Ca. 130 Personen entwickeln Software, davon etwa : auf Mainframes unter Verwendung von Cobol, PL/I und Assembler und 3 auf PC unter Einsatz objektorientierter Techniken. Die objektorientierte Projektfamilie der RWG unter dem Namen GEBOS (Genossenschaftliches Bürokommunikations- und Organisationssystem) wird derzeit von 255 Banken auf 8.849 PCs eingesetzt (alle Angaben Stand 12/97). GEBOS umfaßt aktuell die Komponenten:

1177

Das GEBOS-System

❑ Personen/Kunden-Informationssystem für den Berater, den

Sachbearbeiter und den Vorstand, ❑ Produktberatung für den Standardproduktverkauf im Anlage-

und Konsumkreditgeschäft, ❑ Qualifizierte Anlageberatung für das Wertpapiergeschäft sowie ❑ Kreditsachbearbeitung für das qualifizierte Privat- und Fir-

menkundengeschäft.

5


5.1


1178

Unternehmensstrategie

Ein vorrangiges unternehmerisches Ziel beim Einsatz von Anwendungssoftware ist die Optimierung der Geschäftsprozesse, um so die Kosten zu senken und die Qualität der Produkte und Dienstleistungen zu steigern. Im vorliegenden Fall standen folgende konkreten Ziele im Vordergrund: ❑ Für die aktuellen und potentiellen Kunden sollte die Dienstlei-

stungsqualität erhöht und damit die Kundenzufriedenheit gesteigert werden. ❑ Innerhalb des Unternehmens sollte das Mitarbeiterpotential

besser genutzt werden, um die Produktivität zu erhöhen und gleichzeitig die Qualität der Dienstleistung zu steigern. Die Dienstleistungsqualität zu verbessern bedeutet, gegenüber den Kunden durch hohe Beratungsqualität Kompetenz zu zeigen. Beratungsqualität ist Bestandteil eines umfassenden Konzepts, das aktuell unter dem Begriff Kundenorientierung diskutiert wird. Kundenorientierung heißt, flexibel auf alle Kundenbedürfnisse sofort und umfassend reagieren zu können, um diese zu befriedigen (vgl. [Fittkau 98]). Dadurch soll das Interesse neuer Kunden geweckt und vor allem eine langfristige Kundenbindung erreicht werden.

5

Kundenorientierung


5.1


1179

Kundenorientierung in einer Bank erfordert vielfach eine Umstellung der bestehenden Vorgangsbearbeitung und Geschäftsprozesse. Die folgende Vision kann als Beispiel für Kundenorientierung in einer Bank dienen:

Beispiel

Ein Berater soll seinen Kunden umfassend betreuen. Er kann auf alle Kundeninformationen der Bank zugreifen. Auf der Basis dieser Informationen kann der Berater dem Kunden zielgerichtet ein zugeschnittenes Produktangebot machen. Er kann die Bankprodukte, d.h. Finanzdienstleistungen, ohne störende Unterbrechung des Vorgangs verkaufen. Dabei gilt das Prinzip »Einmal Kommen – Einmal Bearbeiten« von der Beratung bis zum Verkausfabschluß. Standardprodukte können dabei auch kundenindividuell angepaßt werden.

orientierung

für Kunden-

In dieses umfassende Beratungskonzept wird das Selbstbedienungsangebot integriert. Der Kunde kann jederzeit die Selbstbedienungszone seiner Bank aufsuchen, sich sein aktuelles Portfolio anschauen, einfache Bankgeschäfte tätigen und die notwendigen Unterlagen ausdrucken.

Die Vorstellung von einer umfassenden Kundenorientierung hat unmittelbare Konsequenzen auf die Unternehmensorganisation. Umfassende Dienstleistung bedeutet eine verringerte Arbeitsteilung: Die Mitarbeiter im Marktbereich, auch Front-Office-Bereich genannt, können alle Tätigkeiten von der Beratung bis zum Vertragsabschluß erledigen.

5


5.1


Sie können auch die eigentliche Umsetzung des Vorgangs auf das dahinterliegende Rechnungswesen initiieren, beispielsweise die notwendigen Änderungen des Kontos und des Depots. Dies ist aber nur möglich, wenn durch ein spezielles Anwendungssystem ein breites Spektrum fachlicher Funktionalität und entsprechender Standardprodukte am Arbeitsplatz bereitgestellt wird. Wir sprechen dabei von einem Beraterarbeitsplatz (vgl. Kapitel 2.2.3). Für das Unternehmen hat ein Beraterarbeitsplatz den Vorteil, daß aktuelle und umfassende Informationen vorhanden sind. Zudem können die bankfachlichen Gegenstände wesentlich schneller und mit weniger Fehlern bearbeitet werden. Umfassende Dienstleistung aus »einer Hand« und die damit verbundene geringere Arbeitsteilung sind eine Folge der Kundenorientierung. Daneben hat die Spartenorientierung an einzelnen Produktbereichen (s. Kapitel 3.3.1) nach wie vor ihre Berechtigung. Die verschiedenen Sparten sind bei Bankprodukten mit speziellen Anforderungen wichtig. So muß beispielswise eine Baufinanzierung im Marktfolgebereich, auch Back-Office-Bereich genannt, weiterbearbeitet werden. Denn bei einer Baufinanzierung sind eine Vielzahl von Bearbeitungsschritten notwendig, etwa die Vereinbarungen der notwendigen Sicherheiten. Auch im Beratungsbereich ist gelegentlich Spezialwissen erforderlich, z.B. bei einer Wertpapierberatung. Hier sind

5

1180

Arbeitsplatztypen


5.1


1181

Spezialisten gefragt. Entsprechend formulieren wir wieder Anforderungen an das Anwendungssystem für diese Arbeitsplätze. Im Back-Office-Bereich muß das Anwendungssystem für häufig wiederkehrende Teilaufgaben optimiert sein. Neben generellen Komponenten zur Textverarbeitung und Bürokommunikation sind zugeschnittene Werkzeuge für optimierte Vorgänge gefragt. Im Rahmen unserer Einteilung sind also vorrangig Funktionsarbeitsplätze (vgl. Kapitel 2.2.5) notwendig. Für die Wertpapierberatung sind ebenfalls Spezialwerkzeuge erforderlich. Allerdings steht hier nicht die rasche Bearbeitung häufiger Teilaufgaben im Vordergrund, sondern der differenzierte Umgang mit einer Fülle komplexer Materialien. Damit sind Arbeitsplatzsysteme notwendig, die in ihrer Spezialisierung mit Funktionsarbeitsplätzen vergleichbar sind, aber die Flexibilität von Beraterarbeitsplätzen besitzen müssen. Insgesamt erfordert Kundenorientierung aufgrund der umfassenden und aktiven Betreuung der Kunden, daß auch arbeitsteilige Geschäftsprozesse reibungslos ablaufen. Materialien und Informationen müssen ohne Verluste weitergeleitet werden; unnötige Doppelarbeit oder »Schleifen« innerhalb eines Vorgangs sind zu vermeiden. Darauf muß das Anwendungssystem ausgerichtet sein.

5


5.1


Die Kundenorientierung als Verbesserung der Dienstleistungsqualität läßt sich im Rahmen von Kosten/Nutzen-Betrachtungen schlecht diskutieren, da sie kaum unmittelbar nachgewiesen, d.h. gemessen, werden kann. Obwohl eine erhöhte Dienstleistungsqualität ein entscheidender Faktor für die Marktposition eines Unternehmens ist, spielen innerhalb einer Unternehmensstrategie meßbare Faktoren nach wie vor eine wichtige Rolle. Im vorliegenden Beispiel wurden folgende Faktoren diskutiert:

1182 Optimierung der Geschäftsprozesse

❑ Kostensenkung, ❑ Produktivitätsteigerung, ❑ erhöhte Prozeßgeschwindigkeit.

Die RWG stellt strategisch gegenüber ihren Banken als den Anwenderorganisationen die Optimierung der Geschäftsprozesse in den Vordergrund. Das bedeutet vor allem die Reduzierung der Arbeitsteilung und damit die Ausrichtung der Arbeitsschritte auf die fachlichen Tätigkeiten.

5


5.1


In Einklang mit dem WAM-Ansatz wurden folgende Kriterien für die Einführung des GEBOS-Systems erarbeitet:

1183 Kriterien für die Systemeinführung

❑ Die bestehenden Geschäftsprozesse werden zunächst als sinn-

voll betrachtet. Sie müssen auf ihre Übereinstimmung mit den Prinzipien der Kundenorientierung geprüft werden. ❑ Die vorhandenen Geschäftsprozesse sollen so weiterentwickelt

werden, daß ein Minimum an organisatorischen Anweisungen und an verwaltungstechnischem Aufwand entsteht. Informationstechnik soll weitgehend dazu eingesetzt werden. ❑ Bei der Entwicklung der Geschäftsprozesse sollen die fachli-

chen Gegenstände eines Prozesses, also die bearbeitenden Materialien, erhalten bleiben. So wird es auch im neugestalteten Geschäftsprozeß weiterhin einen Vertrag geben. Entscheidend ist die Konzentration auf die anwendungsfachlich notwendigen Tätigkeiten, die durch geeignete Mittel unterstützt werden. ❑ Das GEBOS-System besteht daher im wesentlichen aus unter-

schiedlichen Arbeitsplatztypen für die einzelnen Einsatzkontexte (s. Kapitel 3.3.1). Jeder Arbeitsplatz wird durch eine spezifische Ansammlung von Werkzeugen, Materialien und

5


5.1


1184

kleinen Automaten charakterisiert. Im System sind keine Arbeitsprozesse ablauforientiert implementiert (s. S. 78). ❑ Im Anwendungssystem sind also insgesamt die fachlichen

Arbeitsgegenstände und Arbeitsmittel rekonstruiert. Damit soll sich das Anwendungssystem in Form der verschiedenen Arbeitsplatzsysteme in die neugestalteten Geschäftsprozesse einfügen und diese unterstützen. Im Rahmen einer konkreten Einführungsstrategie für eine Bank ist festzulegen, an welchen Stellen eines Geschäftsprozesses welche Komponenten des Anwendungssystems sinnvoll und nützlich sind. Eine Einführungsstrategie

Wir haben bisher Kundenorientierung und ihren Bezug zu meßbaren Faktoren bei der Reorgansisation von Unternehmen am Beispiel des RWG-Konzepts diskutiert. Dabei hat sich ein enger Zusammenhang zwischen der angestrebten Anpassung der Geschäftsprozesse, dem Anwendungssystem und der vorhandenen Unternehmensstruktur ergeben. Ein neues Anwendungssystem soll die Kundenorientierung unterstützen. Dabei müssen Geschäftsprozesse verändert werden. Dies führt zu Anpassungen in der Unternehmensstruktur (s. Abbildung 5-13).

5


5.1


1185 Abb. 5-13

Anwendungssystem

Zusammenhänge bei der kundenorientierten Reorganisation Kundenorientierung

Unternehmensstruktur

Geschäftsprozesse

Es hat sich in der Praxis herausgestellt, daß nur diese Kombination einen maximalen Effekt beim Einsatz eines Anwendungssystems ergibt. Im Sinne des WAM-Ansatzes darf es aber keine überproportionale Betonung einer der drei Komponenten geben. Erzwingt z.B. ein Anwendungssystem die Veränderung der Geschäftsprozesse derart, daß sie der Unternehmensstruktur entgegenlaufen, ist das fatal. Andererseits hat sich gezeigt, daß der Einsatz eines Anwendungssystems in unveränderte Geschäftsprozesse und Unternehmensstrukturen keinen meßbaren positiven Effekt bringt. Hier ist der Zusammenhang zwischen der Kompetenzentwicklung der Mitarbeiter und der kundenorientierten Reorganisation wichtig (vgl. [Frei et al. 96]). Wir gehen auf diesen Punkt im weiteren noch ein.

5


5.1


1186

Eine wesentliche Einsicht im Rahmen der GEBOS-Entwicklung war, daß sich komplexe Arbeitsplatzsysteme nicht wie Standardsoftware »über die Theke verkaufen« lassen. Um ein auf die drei genannten Komponenten abgestimmtes Reorganisationskonzept zu erarbeiten, bietet die RWG ihren Kunden eine Beratung bei der GEBOSEinführung an. Diese Beratungsleistung ist freiwillig. Die Erfahrungen zeigen, daß bei der Systemeinführung diejenigen Banken den größten Nutzeffekt erzielten, die die Beratungsleistung in Anspruch genommen haben. Von großem Vorteil ist offenbar, die Beratung aus dem gleichen Haus zu beziehen, welches auch das System entwickelt hat. Dabei müssen die Berater allerdings über die Entwicklung und die dahinterliegenden Konzepte informiert sein und qualifiziert beraten können. Die Einführung des Anwendungssystems GEBOS nach der RWG-Strategie basiert auf einer Analyse der vorhandenen Geschäftsprozesse. Dies geschieht auf zwei unterschiedlichen Detaillierungsebenen. In einem ersten Durchgang wird jeder einzelne Arbeitsschritt aller relevanten Geschäftsprozesse festgehalten und auf eine mögliche Unterstützung durch das Anwendungssystem untersucht. Ziel dabei ist es, festzustellen, ob alle fachlichen Tätigkeiten und Teilaufgaben identifiziert sind und mit dem neuen System auch weiter erledigt werden können.

5

Analyse der vorhandenen Geschäftsprozesse


5.1


1187

In einem zweiten Schritt werden die einzelnen Erkenntnisse abstrahiert und in eine komprimierte, übersichtliche Form gebracht. Jetzt steht die Entwicklung einer konkreten Einführungsstrategie im Vordergrund. Ziel ist, Maßnahmen in folgenden Bereichen festzulegen: ❑ Reorganisation der Geschäftsprozesse, ❑ Qualifikation und Schulung des Personals, ❑ Veränderung der technischen Infrastruktur, ❑ Konzeption der konkreten Systemeinführung.

Als Minimum werden für jede neue Systemeinführung Maßnahmen in den Bereichen Geschäftsprozesse, Personalqualifizierung und technische Infrastruktur festgelegt. Bei der Betrachtung der Einführungsstrategie, die die RWG gewählt hat, stellt sich für den Leser vielleicht die Frage, weshalb eine erneute Analyse notwendig ist, da doch bereits bei der Entwicklung der Anwendungskomponenten im Rahmen von Interviews und Szenarien ausführliche Bestandsaufnahmen der aktuellen Anwendungssituation gemacht werden. Der wesentliche Unterschied ist, daß in der Entwicklung keine Modellierung von Arbeitsprozessen im System angestrebt wird. Im Mittelpunkt steht hier, die im Anwendungsbereich anfallen-

5

Anmerkung zur Analyse der vorhandenen Geschäftsprozesse


5.1


1188

den Aufgaben zu erkennen und zu verstehen. In Szenarien werden daher die Aufgabeninhalte beschrieben und welche Arbeitsgegenstände mit welchen Arbeitsmitteln von wem, mit wem und warum bearbeitet werden. Diese Erhebung ist daher keine Analyse der Geschäftsprozesse, sondern lenkt den Blick der beteiligten Entwickler auf die im Anwendungsbereich relevanten Arbeitsgegenstände und Arbeitsmittel. Der Ablauf der einzelnen Arbeitsschritte innerhalb eines Geschäftsprozesses wird nicht durchgängig modelliert, da dies zu einer ablaufsteuernden Sichtweise verleitet und von den Gegenständen und ihren Umgangsformen ablenkt. Das Verständnis der fachlichen Gegenstände und ihrer Bearbeitung ist schließlich der Ausgangspunkt für die Softwareentwicklung.

Für unseren Diskussionszusammenhang sind besonders die Geschäftsprozesse interessant. Alle durch das Anwendungssystem unterstützten Geschäftsprozesse werden identifiziert und mit den betroffenen Mitarbeitern diskutiert. Die daraus resultierenden Veränderungen werden mit den Bankvorständen abgestimmt, um Maßnahmen für die Einführung festzulegen. Die Einführungsstrategie legt in diesem Bereich Wert darauf, daß Geschäftsprozesse verändert werden können. Dies wird jedoch nicht erzwungen. Die Berater der RWG verdeutlichen den Beteiligten jedoch, daß gewünschte Kosten/Nutzen-Effekte nur durch die Veränderung der Geschäftsprozesse und der angepaßten Unternehmensstruktur in vollem Umfang eintreten.

5


5.1


Wir diskutieren im einzelnen die RWG-Einführungsstrategie in folgenden Bereichen:

1189 Die Einführungsstrategie im einzelnen

❑ Veränderte Geschäftsprozesse ❑ Personalqualifizierung ❑ Schulungskonzepte ❑ Technische und räumliche Veränderungen ❑ Systemeinführung

Veränderte Geschäftsprozesse: Für die zu verändernden Geschäftsprozesse werden erarbeitet: ❑ Die Arbeitsschritte mit GEBOS, ❑ die Arbeitsschritte im Marktbereich, ❑ die Arbeitsschritte im Marktfolgebereich, ❑ die für die Bank gültigen Produkte mit den Definitionen des für

die Bank gültigen Produktnamens und der Produktkonditionen,

5


5.1


1190

❑ die für die Bank gültigen Formulare mit der Entscheidung, ob

bankindividuelle Formulare oder mit einer rechtlichen Sicherheit versehene Standardformulare verwendet werden sollen sowie ❑ Neuorientierung der Datenkontrolle anhand von Orginal-

unterlagen. Die reibungslose Integration des Anwendungssystems in die veränderten Geschäftsprozesse verlangt vom Anwendungssystem Flexibilität, d.h. Unterstützung der Geschäftsprozesse ohne fixe Zwangsabläufe, die einen bestimmten Ablauf erzwingen. Leitlinie ist hier, daß sich ein Anwendungssystem der Unternehmensphilosophie anpassen muß. Es kann veränderte Abläufe und neue Umgangsformen bei der Erledigung von Aufgaben motivieren, darf jedoch niemals Veränderungen erzwingen, die für das Unternehmen nicht passen. Die Geschäftsprozesse sind von der Sache her, aber vor allem durch die Menschen, die den Prozeß bearbeiten, geprägt. Fachlich gleiche Aufgaben können in einem Unternehmen in unterschiedlichen Prozessen erledigt werden. Dies kann z.B. von der unterschiedlich starken Spezilisierung der Mitarbeiter in einer Bank abhängen. In einer Bank können sich Spezialisten einen Vorgang teilen; in einer anderen Bank kann der gleiche Vorgang von einer Personen erledigt

5


5.1


1191

werden, die die notwendigen Fachkenntnisse in den verschiedenen Bereichen besitzt. Für das Anwendungssystem und die Einführungsstrategie folgt daraus, daß im ersten Fall beispielsweise die Weitergabe von Materialien zwischen Arbeitsplätzen (s. Kapitel 4.1.2) viel stärker in Anspruch genommen werden muß als im anderen Fall. Der Zusammenhang von Anwendungssystem, Geschäftsprozeß und Unternehmensstruktur ist innerhalb eines Unternehmens in verschiedener Weise in Einklang zu bringen. Für die RWG-Klientel gilt dies aber auch über die Grenze einer Bank hinweg, wenn das Anwendungssystem für den Einsatz bei mehreren Banken verwendet werden soll. Aus dem RWG-Kontext bringen wir ein Beispiel, das die Vorgehensweise erläutert. Hier geht es um die Veränderung konventioneller Geschäftsprozesse zwischen Markt- und Marktfolgebereich. Dazu stellt der Organisationsberater der RWG den Ist-Zustand einem möglichen Soll-Konzept gegenüber. In Bildern und Tabellen wird also aufgezeigt wie ein Vorgang ohne und mit Unterstützung durch das GEBOS-System in der jeweiligen Bank abläuft. Abbildung 5-14 zeigt am Beispiel der Produktberatung und dem Verkauf für ein Sparprodukt, wie der Geschäftsprozeß konventionell abläuft.

5

Beispiel für einen veränderten Geschäftsprozeß


5.1


GEDIS-Arbeitsablauf IST: Produktberatung

1192 Abb. 5-14 Produktberatung und -verkauf für ein

GEDIS

Sparprodukt (Ist-Situation)

1

Beratung GEDIS-Terminal

2

Abfrage: Adress-/Kontendaten

3 auf Notizzettel vermerken

Vertragserstellung

4

5

Verkaufshilfe

maschinell

"handschriftlich"

6

Marktfolge Passiv

7

1. Prüfung der Vertragsunterlagen 2. Ablage von Spar-Sonderformen

GEDIS

8 Buchhaltung

GEDIS-Terminal Bestandspflege: – Kontodaten – notwendige AEB

1. Prüfung der Schlüsselblätter

5


5.1


1193

Die numerierten Pfeile in Abbildung 5-14 können in der Art eines Kooperationsbildes erläutert werden: 1. Der Berater informiert sich mit Hilfe des bisher eingesetzten GEDISSystems (einem relationalen Abfragesystem) über den Kunden. Er fragt folgende Daten ab: – Kundenname und Adresse – Kontenübersicht – und druckt sich die Information aus. 2. Der Berater überträgt die Daten manuell in eine Verkaufshilfe. Mit einem Taschenrechner, Stift und Papier sowie Produktinformationen aus dem Produktordner berät er den Kunden. 3. Der Berater schreibt als Notiz die Produktwahl des Kunden mit den vereinbarten Konditionen für den Marktfolgebereich auf einen Zettel. 4. Im Marktfolgebereich für das Passivgeschäft wird der Vertrag erstellt. Der Sachbearbeiter erfragt Kundenname und Adresse über das System und schreibt sie ab. Die Produktinformationen mit den Konditionsvereinbarungen werden vom Notizzettel des Beraters auf den Vertrag übernommen. Dies geschieht mit einem Textverarbeitungssystem, einer Schreibmaschine oder handschriftlich. Der Kunde unterschreibt den Vertrag bei seinem nächsten Besuch in der Bank oder nachdem er ihm per Post zugestellt wurde.

5


5.1


1194

5. Weitere Daten werden auf Erfassungsbelege übernommen. Diese Daten werden über eine Änderungsbezugszahl (AEB) den Prüffunktionen zugeordnet. 6. Die Daten auf den Erfassungsbelegen werden im Anwendungssystem über Erfassungsmasken eingegeben. 7. Die Vertragsunterlagen werden geprüft. Muß ein Vertrag geändert werden, so muß er auch wieder im Anwendungssystem erfaßt werden. Geprüfte Verträge werden abgelegt. 8. Am nächsten Arbeitstag werden die Kontrollisten des Systems mit den Erfassungsbelegen geprüft. Gegebenenfalls werden die Daten im Anwendungssystem berichtigt. Im nächsten Schritt werden die Arbeitsabläufe als Soll-Konzept so dargestellt, wie sie mit dem GEBOS-System möglich wären (siehe Abbildung 5-15).

5


5.1


Abb. 5-15

GEBOS-Arbeitsablauf SOLL: Produktberatung

1195

Produktberatung und -verkauf für GEBOS-PC

1. Abfrage: Kunden-/Kontendaten 2. Modellrechnung von Alternativprodukten 3. Elektronische Datenübernahme ermittelter Daten 4. Erstellung eines Beratungsblattes 5. Vertragserstellung

ein Sparprodukt (Soll-Vorschlag)

6. Bestandspflege Kunden-/Kontendaten 7. Gegebenenfalls Umsatzbuchung

Berater

op

tio

1

na

l

Arbeitsplatz-Drucker 1. Ausdruck: Beratungsblatt (Angebot) 2. ggf. Ausdruck Erfassungsbeleg 3. ggf. Ausdruck Buchungsbeleg ! kein Formulardruck !

Duplex-Drucker 1. Ausdruck Beratungsblatt (Angebot) 2. Ausdruck Vertrag 3. ggf. Ausdruck Erfassungsbeleg 4. ggf. Ausdruck Buchungsbeleg

2

3

Kontenverwaltung/Datenkontrolle 1. Prüfung der Vertragsunterlagen

Ablage

5


5.1


1196

1. Der Berater berät den Kunden unterstützt vom GEBOS-System bis zum eventuellen Vertragsabschluß. Die sogenannte Bestandspflege kann sofort erledigt werden. Die meisten Informationen stehen im System bereit. Die Produktdaten mit ihren Konditionen sind im Ordner Produkte enthalten. Sonderkonditionen oder vereinbarte Einzahlungsbeträge werden aus der Modellrechnung übernommen. Der Berater druckt den Vertrag aus, und der Kunde kann gleich unterschreiben. Will der Kunde sich das Angebot noch überlegen, erhält er ein Kundenberatungsblatt. Alle Informationen bleiben im System erhalten, so daß bei einem weiteren Kundengespräch darauf zurückgegriffen werden kann. Je nach Wunsch der Bank kann ein Erfassungsbeleg ausgedruckt werden. Ein Buchungsbeleg wird erstellt, wenn der Kunde gleich einen Betrag auf das neu vereinbarte Konto einzahlt. 2.

Der Vertrag und der Erfassungsbeleg gehen in den Marktfolgebereich. Am folgenden Arbeitstag wird die Kontrolliste des Systems gegen den Vertrag geprüft; optional kann die Prüfung auch mit dem Erfassungsbeleg erfolgen.

3.

Vertrag wird abgelegt.

Aufgrund dieser Gegenüberstellung kann der Organisationsberater mit den beteiligten Mitarbeitern der Bank die Veränderungen des Geschäftsprozesses diskutieren.

5


5.1


1197

Personalqualifizierung: Die Geschäftsprozesse werden so verändert, daß Routinetätigkeiten reduziert werden. Da das Unternehmen auf Kundenorientierung ausgerichtet werden soll, wird eine geringere Arbeitsteilung angestrebt. Dies erfordert meist Personalqualifizierung. Im Kontext der RWG hat sich herausgestellt, daß ein großer Teil der Mitarbeiter weiterhin in bereits bestehenden kundenorientierten Prozessen eingesetzt wird. Aber es fallen auch Arbeitsplätze im Routinebereich weg. Gleichzeitig entstehen mit dem Einsatz des Anwendungssystems neue Aufgaben, die es bisher so im Unternehmen nicht gab. Entsprechend müssen Mitarbeiter, deren Bereiche tendenziell wegfallen, für neue Aufgaben qualifiziert werden. Dieser Trend zur qualifizierten Arbeit als Folge der Entwicklung von Geschäftsprozessen und der Einführung eines passenden Anwendungssystems stellt erhöhte Anforderungen an die Mitarbeiter. Die Unternehmen müssen sich in ihrer Organisationsentwicklung darauf einstellen, daß es Kraft und Anstrengung kostet, die Mitarbeiter entsprechend den neuen Anforderungen zu qualifizieren. Dabei reicht es nicht aus, einfach »Köpfe« zu zählen (»die Anzahl stimmt«). Dies gilt offensichtlich über den Bankenbereich hinaus. Die Veränderung der Geschäftsprozesse führt auch dazu, daß Mitarbeiter, die bisher sehr wenig mit Anwendungssystemen zu tun

5


5.1


1198

haben, nun täglich mit dem Computer arbeiten müssen. Dies erfordert oft einiges an Überzeugungsarbeit. Manche Mitarbeiter sehen die Arbeit mit Computern als Abqualifizierung ihrer bisherigen Tätigkeit an. Hier muß im Rahmen einer Einführungsschulung motiviert werden, welchen Nutzen der Mitarbeiter aus der Arbeit mit dem Anwendungssystem ziehen kann und wie gut das Anwendungssystem zu den gewohnten Arbeitsformen paßt. Das GEBOS-System, das ja nach dem WAM-Ansatz entwickelt worden ist, zeigt in dieser Hinsicht die gewünschten Eigenschaften.

Das Beispiel in Abbildung 5-14 und Abbildung 5-15 macht deutlich, welche bisherigen Arbeitsschritte vom System unterstützt werden und welche durch den Einsatz des Anwendungssystems überflüssig werden. Offensichtlich kommt der Marktfolgebereich mit weniger Mitarbeitern aus. Diese Mitarbeiter können für andere Aufgaben qualifiziert werden. Im konkreten Fall ergibt sich folgendes Bild:

Beispiel für Personalqualifizierung

Die bisherigen Aufgaben eines Servicemitarbeiters im Markt- und Marktfolgebereich wird es in der Form zukünftig nicht mehr geben. Die wenig qualifizierten Aufgaben nehmen ab, da sie vom System übernommen werden. Für die Mitarbeiter gibt es verschiedene Alternativen, sich für neue Aufgaben zu qualifizieren. Folgende Aufgabenbereiche stehen zur Auswahl:

5


5.1


1199

❑ Kundenberater Er ist zuständig für – die Informationen über den Kunden, eine auf den Kunden ausgerichtete Beratung bis zum Vertragsabschluß und die anschließende Pflege der juristischen Daten. – Beratung im Anlagebereich und Kreditbereich. – Fachliche Qualifikation für Produktberatung, Modellrechnungen, Analyse von Kundendepots, das Geschehen im Markt und an der Börse. – Dazu kommt ein umfassendes, kundenorientiertes Dienstleistungsangebot. ❑ Technischer Kundenberater und Service-Berater Die Bank bietet Software für den Homebanking-Bereich und zur besseren Bearbeitung des Zahlungsverkehrs an. – Der technische Kundenberater ist Beratungs- und Ansprechstelle für die Bankkunden im Bereich Zahlungsverkehrsprodukte und im gewerblichen Bereich. – Der Service-Berater bietet Beratung und Unterstützung für das Homebanking. ❑ Organisator und DV-Administrator Die neue Client/Server-Infrastruktur erfordert Mitarbeiter, die für diesen Bereich verantwortlich sind. Zu den Aufgaben eines Organisators gehören: – Hardwareverwaltung, – Einführung der Benutzer, – laufende Unterstützung der Benutzer, – EDV-Support.

5


5.1


1200

Der DV-Administrator ist verantwortlich für die Pflege der Bankdaten (z.B. Produktdaten) und der Benutzerdaten. ❑ Neue Aufgaben bei der Datenkontrolle und der Kontenverwaltung Die neue Datenkontrolle erfolgt nicht mehr nur formal, sondern qualifiziert anhand der Orginalunterlagen. Die qualitative Datenkontrolle umfaßt alle Bereiche des Bankgeschäfts wie Kreditbereich, Anlagebereich und Wertpapierbereich. Zur Kontoverwaltung gehört z.B.: Abhandlung von Sonderfällen, z.B. Stundungen im Kreditbereich, Bestandsverwaltung Geschäftsguthaben, Zinsabschlagsteuer, Erbfälle, Kunden-/Kontenverschlüsselungen.

– – – – –

Schulungskonzepte: Die RWG plant gemeinsam mit der jeweiligen Bank bedarfsorientiert die notwendigen Schulungsmaßnahmen. Wichtig ist, daß die Schulungen und der produktive Einsatz des Anwendungssystems für die betroffenen Personen zeitlich nah beieinanderliegen. Wird ein Mitarbeiter heute geschult, kann aber mit dem Anwendungssystem erst

5


5.1


1201

nach einigen Wochen arbeiten, dann ist das vermittelte Wissen nicht mehr präsent. Der Inhalt der Schulung wird abhängig von den Vorkenntnissen der Mitarbeiter bestimmt. Wird bereits eine Version des GEBOS-Systems eingesetzt, kann die Schulung der neuen Version auch mit einem Lernpogramm erfolgen. Wird das System neu eingeführt, ist eine Schulung wichtig, bei der sich die klassischen vortragsorientierten Referentenveranstaltungen mit Tutoriumskonzepten (Coaching) ergänzen. So wird die Vermittlung von Konzepten mit konkreten bankfachlichen Übungsbeispielen kombiniert, die die Schulungsteilnehmer selbständig durchführen. Sehr bewährt haben sich Workshops, die nach einiger Zeit des Praxiseinsatzes durchgeführt werden. Dort können die Benutzer des neuen Systems ihre Alltagsprobleme zur Sprache bringen. Die RWG diskutiert mit jeder betroffenen Bank, ob sie eine sogenannte Schulungsbank (als Kopie des operativen Datenbestands) bei sich einrichtet und so die Möglichkeit hat, terminlich flexibel zu schulen. Zu überlegen ist auch, ob Mitarbeiter der Bank als Trainer ausgebildet werden, die dann die Schulungen im eigenen Haus durchführen. Dies ist nur sinnvoll, wenn diese Trainer neben dem Wissen über den Umgang mit dem Anwendungssystem auch über das erforderliche fachliche Wissen verfügen und damit die notwendigen Praxiskennt-

5


5.1


1202

nisse mitbringen. Diese Trainer können dann in der Bank auch als Ansprechpartner bei Fragen und Problemen agieren. Die Komponenten des GEBOS-Systems sind auf die verschiedenen Arbeitsplatztypen in unterschiedlichen Einsatzkontexten ausgelegt. Das Schulungsangebot sieht daher vor, den Mitarbeitern dem Einsatzkontext entsprechende Schulungen anzubieten. Abbildung 5-16 zeigt ein Beispiel eines solchen Schulungsangebots.

5

Beispiel für ein Schulungskonzept


5.1


1203 Abb. 5-16

GEBOS-Einsatzbereiche für Neueinsteiger

Beispiel für ein Musterbank eG

Schulungskonzept nach

Benutzer: Mustermann 1 1 2 4 5 6 7

Einsatzkontexten Berater

Sachbearbeiter Service Bank

Aktiv

Passiv

Aktiv

Passiv

Marktfolge interner Bereich

Administrator

GEBOS-Schalter

GEBOS-Basis

GEBOS-Anlageberatung

GEBOS-Produktberatung

GEBOS-Kreditberatung

GEBOS-Administration

5


5.1


1204

Ein Schulungsangebot für »GEBOS-Neueinsteiger« umfaßt folgende Schulungseinheiten: GEBOS-Schalter: 1 Tag Umgang mit der grafischen Oberfläche Abfragen Bestandspflege 1 Tag

Umsatzverarbeitung Kassenzählerabstimmung Sorten, Devisen, Edelmetalle Nachtragsbearbeitung

GEBOS-Basis: 1 Tag Person / Kunde Formular Produkt Kopien Vorgang Wiedervorlage GEBOS-Qualifizierte Anlageberatung (Wertpapier): 1 Tag Orderbearbeitung Depotbearbeitung inklusive Depotanalysen Wertpapier-Gattungsanzeige Hautpversammlung Chart-Darstellungen Informationssystem für Nachrichten, Kurse usw.

5


5.1


1205

GEBOS-Produktberatung mit Verkauf: 1 Tag Produktberatung inklusive der Unterbrechung und Wiederaufnahme Produktneuanlangen und Wandlungen GEBOS-Kreditsachbearbeitung: 2 Tage Kreditsachbearbeitung: Vorgang, Wiedervorlage, Formulare, Finanzierungsrechnungen Kundeninformationen: Engagementbearbeitung (Konto, Depot, usw.), Sicherheitenbearbeitung, Handelslinien und Derivate Kreditprotokollerstellung Protokollbuch GEBOS-Administration: 1 Tag Bearbeitung der für die Bank gültigen Informationen: Bank, Benutzer Arbeitsplatz, Produkt Erklärung der Konfigurationspläne, Installation und Inbetriebnahme, weitere GEBOS-Arbeitsplätze Tägliche Systemarbeiten 1 Tag

Sicherungskonzept Sicherung der Server Behandlung von Problemsituationen im GEBOS-Kontext Vorgehensweise bei Konfigurationsänderungen

5


5.1


1206

Ein Kundenberater würde entsprechend folgende Kurse besuchen: 1. GEBOS-Schalter 2. GEBOS-Basis 3. GEBOS-Qualifizierte Anlageberatung 4. GEBOS-Produktberatung Ein Mitarbeiter, der den Standardproduktbereich betreut, besucht die Seminare: 1. GEBOS-Schalter 2. GEBOS-Basis 3. GEBOS-Produktberatung Die Mitarbeiter können als passend für ihren Einsatzkontext geschult und nach Bedarf weiterqualifiziert werden. Das auf die GEBOS-Komponenten und die Einsatzkontexte ausgerichtete Schulungskonzept ermöglicht den Banken, ihre Unternehmensstruktur und Organisation auch auf den Schulungsbereich abzubilden.

Technische und räumliche Veränderungen: Die technische Infrastruktur wird von den Organisationsberatern mit Blick auf die jeweilige Einführungsstrategie geprüft und bei Bedarf ergänzt. Sie richtet sich nach der jeweils vorhandenen Infrastruktur. Im Fall der von der RWG betreuten Banken hängt dies stark davon ab, ob bereits Versionen des GEBOS-Systems eingesetzt werden oder ob ein erstmaliger Einsatz geplant ist. Zur Festlegung der notwendigen Ressourcen werden die Ergebnisse der Analyse der Geschäftsprozesse herangezogen.

5


5.1


1207

Beispiele sind: ❑ Wieviel Arbeitsplätze sollen mit dem Anwendungssystem

arbeiten? ❑ Welche Informationsmengen sind zu berücksichtigen? ❑ Welche Ausfallsicherheit ist zu gewährleisten? ❑ Welche Supportleistung ist gewünscht? ❑ Welche Antwortzeiten werden erwartet?

Hierbei spielen natürlich technologische Gesichtspunkte (s. S. 155ff.) eine Rolle. Die Ausstattung mit Hardware hängt von der Definition der Ressourcen ab. Für anstehende Beschaffungen ist die Entscheidung über den Hardwarelieferanten zu fällen. Wichtig ist die Frage, wie die vorhandene Hardware weiter genutzt werden kann. Dabei wird Hardware meist bedarfsorientiert anders eingesetzt. Das Zusammenspiel von Merkmalen des Anwendungssystems mit der organisatorischen Umstrukturierung läßt sich bei der Druckerausstattung aufzeigen. Im Marktbereich muß beispielsweise jeder GEBOS-Arbeitsplatz einen Drucker haben. Jeder Berater benötigt gedruckte Dokumente, ohne dazu aufzustehen und den Kunden

5


5.1


1208

alleine zu lassen. Anders sieht es im Marktfolgebereich aus. Hier können sich mehrere Mitarbeiter einen Drucker teilen. Die Veränderung der Geschäftsprozesse bringt in den von der RWG betreuten Banken neben den organisatorischen Änderungen auch räumliche Veränderungen mit sich. Soll ein Arbeitsplatzsystem nach dem WAM-Ansatz konsequent in der Kundenberatung eingesetzt werden, dann muß der Arbeitsplatz eines Beraters zu einem Beratungsplatz umgestaltet werden. Wesentlich dabei ist, daß der Kunde in die Beratung und die Arbeit mit dem Anwendungssystem einbezogen wird. Die notwendige technische Infrastruktur dazu muß oft erst geschaffen werden. Eine Bank hat den WAM-Ansatz konsequent umgesetzt und ein eigenes Kundenberatungszentrum gestaltet, in dem Beratungsplätze zur Verfügung stehen. Der Berater geht auf den Kunden zu, sucht sich gemeinsam mit dem Kunden einen freien Beratungsplatz aus und führt die Beratung mit dem Kunden bis zum eventuellen Vertragsabschluß oder Produktverkauf durch. Alle trennenden Elemente wie Tresen und ungeeignete Tische sind entfernt worden - Berater und Kunde schauen gleichzeitig auf den Bildschirm und bestimmen gemeinsam die Beratung.

5

Beispiel für räumliche Veränderungen


5.1


1209

Systemeinführung: Das Systemeinführungskonzept koordiniert die Maßnahmen, die sich in den gerade genannten Bereichen ergeben. Die Veränderung der Geschäftsprozesse müssen mit der Personalqualifizierung, dem Schulungskonzept und der Entwicklung der technischen und räumlichen Infrastruktur Hand in Hand gehen. Aus Sicht der RWG ist es wichtig mit der Bank gemeinsam zu definieren, in welchen Einsatzkontexten mit der Einführung des Anwendungssystems begonnen wird. Soll das Anwendungssystem zunächst nur in der Hauptstelle eingeführt werden oder auch in den Zweigstellen? Die Entscheidung, ob Zweigstellen umgestellt werden oder nicht, hängt sehr stark von den dafür notwendigen Investitionen in die Technik ab. Eine häufige Verfahrensweise ist, erst die Hauptstelle umzustellen, dann die Zweigstellen mit dem größten Kundenvolumen und danach erst die restlichen Zweigstellen. Die gestufte Einführungsweise bringt die Parallelität von »alten« und neuen Geschäftsprozessen mit sich. Generell ist zu prüfen, ob veränderte und alte Geschäftsprozesse eine Zeitlang parallel laufen sollen, weil es günstiger erscheint, die Veränderungen sukzessive einzuführen, oder weil die technische Infrastruktur nicht so schnell verändert werden kann.

5


5.1


1210

Andere Fragen sind: ❑ In welcher Zeit werden bestehende Informationen z.B. auf

konventionellen Dokumenten in das Anwendungssystem übernommen? ❑ Welche Musteranweisungen sind zu erstellen? ❑ Sind bestehende Arbeitsanweisungen zu ändern? ❑ Welche bankindividuellen Anpassungen des Anwendungssy-

stems, etwa bei bestimmten Produkten und Formularen, sind vorzunehmen? Die Antworten auf diese Fragen müssen mit den Planungen in den anderen Bereichen in Einklang gebracht werden. Hier sind z.B. Gespräche mit Architekten zu den räumlichen Veränderungen ebenso einzuplanen wie Absprachen über Handwerkertermine für die Verkabelung, das Bestellen von PCs bis hin zu Mitarbeitergesprächen. In der Arbeit der RWG hat sich das Konzept der Nachschau bewährt. Nach einigen Wochen des Praxiseinsatzes kommen die RWG-Berater, Anwender und Bankorganisatoren zusammen, um über die offenen Punkte des Alltags zu diskutieren und Nachbesserungen zu initiieren. Dies hat zu einer beträchtlichen Erhöhung der Akzeptanz des Systems geführt.

5


5.1


1211

Rückkopplung des Einführungsprozesses in die Entwicklung

Die RWG beschränkt den evolutionären Prozeß nicht auf die Neuentwicklung von Anwendungskomponenten. Auch auf der Ebene von Einführung und Einsatz eines Anwendungssystems sowie seiner Weiterentwicklung sind Rückkopplungsprozesse realisiert. Entsprechend fließen Erkenntnisse, die die Berater bei der Einführung eines Anwendungssystems »vor Ort« gesammelt haben, direkt in den (Weiter-) Entwicklungsprozeß zurück: Die detaillierte Gegenüberstellung bestehender und neuer Geschäftsprozesse zeigt deutlich die Lücken auf, in denen das Anwendungssystem den entsprechenden Geschäftsprozeß gar nicht oder schlecht unterstützt. Neben Anforderungen an veränderte fachliche Funktionalität sind es vor allem Schwächen im Umgang, d.h. im Benutzungsmodell, die auffallen. Dies waren bisher meist: ❑ ungenügende Werkzeugunterstützung für Teilaufgaben, ❑ fehlende Durchgängigkeit bei der Abarbeitung von häufigen

Teilschritten, ❑ unterschiedliche Reaktionen verschiedener Anwendungskom-

ponenten auf gleichartige Umgangsformen, die für Benutzer unerwartet sind.

5


5.1


1212

In Workshops zwischen den Beratern, den Bankmitarbeitern und den Entwicklern werden die identifizierten Schwächen des Anwendungssystems diskutiert. Die daraus resultierenden Anforderungen fließen in den nächsten Entwicklungszyklus ein und durchlaufen dort die aufgezeigten Autor-Kritiker-Zyklen. In diesen Zyklen sind dann diese Bankmitarbeiter wieder integriert. Auch die Berater der RWG werden in den Prozeß einbezogen und können ihr Praxiswissen einbringen. Gleichzeitig erhalten sie so frühzeitig Wissen über die Komponenten der nächsten Ausbaustufen, was ihre Beratungsqualität erhöht. Die RWG hat eine unabhängige Beratungsfirma beauftragt, den Einsatz des GEBOS-Systems bei einer Bank zu bewerten. Wir fassen die Ergebnisse dieser Studie in Abbildung 5-17 zusammen, da sie in zweierlei Hinsicht interessant ist. Zum einen wird deutlich, daß jenseits einer reinen Kosten/Nutzen-Bewertung zunehmend »weichere« Faktoren in eine Systembewertung eingehen. Zum anderen kann das GEBOS-System als ein gutes Beispiel für Anwendungssoftware nach dem WAM-Ansatz genommen werden. Da Banken auch einen relevanten Anwendungsbereich darstellen, lassen sich einige der Aussagen sicherlich verallgemeinern.

5

Beispiel für die Bewertung einer Systemeinführung


5.1

Beratungsqualität


Bessere und übersichtlichere Berechnungen / Angebote für den Kunden. Kompetenz gegenüber dem Kunden. Erleichtert und vereinheitlicht das Beratungsgespräch.

Informationsbeschaffung

Komplette Informationen stehen schneller zur Verfügung.

Schnelle, abschließende Bearbeitung

Schnellere Bearbeitung. Kunde kann sofort abschließend beraten werden. Einheitliche Bearbeitung. Einfache Bearbeitung von Kundenwünschen.

Kontrolle

Neuer Ansatzpunkt für Kontrollen.

Abbau von Schnittstellen

Weniger Schnittstellen — weniger Arbeitsplätze. D.h. auch: Verbesserung der Arbeitsqualität.

Einheitliche Formulare

Vereinheitlichung der Formulare in der Gesamtbank – besseres Erscheinungsbild. Einsatz aktueller Vordrucke ist gewährleistet.

1213 Abb. 5-17 Ergebnisse einer Studie zum Einsatz des GEBOSSystems

Aus unserer Sicht ist interessant, daß das verwendete Leitbild auch in der Bewertung deutlich wird. Das GEBOS-System wird als ein Arbeitsplatzsystem für eigenverantwortliche und qualifizierte Tätigkeit genutzt. Dadurch sind die Bankmitarbeiter meist in der Lage, die Kundenwünschen beim ersten Kunden-

5


5.2

Die WAM-Dokumenttypen

1214

kontakt unmittelbar am Arbeitsplatz zu erfüllen. Die einheitliche Ausstattung gleichartiger Arbeitsplätze mit geeigneten Werkzeugen und aktuellen Materialien schlägt sich auch erkennbar in der Bewertung nieder. Schließlich ein Wort zur Reduktion von Arbeitsplätzen. Im vorliegenden Beispiel war die Einsparung von Arbeitskräften kein Ziel bei der Systemeinfühung. Die Bank wollte primär die vorhandenen ohnehin recht knappen Personalressourcen optimiert einsetzen. In diesem Sinne wurde Personal aus dem Marktfolgebereich weiterqualifiziert und in anderen Bereichen eingesetzt.

5.2


In diesem Kapitel beschreiben wir die Dokumenttypen des WAMAnsatzes. Die hier vorgestellten Dokumenttypen haben sich vor dem Hintergrund unserer Erfahrungen aus laufenden Projekten als relevant zur Beantwortung zentraler Fragestellungen im Entwicklungsprozeß herausgebildet. Die grundlegenden Ideen zur Dokumentation sind in Kapitel 2.4 beschrieben. Wir betrachten jetzt die Entwicklungsdokumente. Jeder Dokumenttyp wird in ein Koordinatensystem eingebettet, aus dem erkennbar ist, für welche wesentlichen Fragestellungen er verwendet werden kann. Die drei Dimensionen des Koordinatensystems orientieren sich an den Fragestellungen:

5

Federführung: Guido Gryczan, Anita Krabbel Ko-Autor: Dirk Bäumer, Ingrid Wetzel, Heinz Züllighoven


5.2


1215 Abb. 5-18 Dimensionen der Dokumentation

Detail

Dynamik

Überblick

Statik Fachlich

Technisch

❑ Überblick/Detail: Wird ein Sachverhalt detailliert oder im

Überblick dargestellt? ❑ Fachlich/technisch: Wird ein Sachverhalt anwendungsorien-

tiert und aus Benutzungssicht betrachtet oder von der softwaretechnischen Seite? ❑ Statik/Dynamik: Wird ein Sachverhalt in seinen dynamischen

oder in seinen statischen Elementen und Bezügen beschrieben? Abbildung 5-18 zeigt das Koordinatensystem mit den relevanten Fragestellungen. Mit diesem Bezugssystem können wir die konkreten Fragen und Probleme im Entwicklungsprozeß kategorisieren. Außerdem können wir damit den Fragestellungen jeweils geeignete Dokumenttypen zuordnen. 5


5.2


1216

5.2.1 Szenarios Szenario: Ein Szenario ist ein Prosatext in der Sprache der Anwendung, der eine Ist-Situation beschreibt. Gegenstand der Beschreibung ist, wie Aufgaben im Anwendungsbereich erledigt werden.

Entwickler müssen die Aufgaben und Probleme der Anwender an den verschiedenen Arbeitsplätzen verstehen, um ein adäquates Anwendungssystem zu erstellen. Dazu ist es vor allem notwendig, daß Entwickler ein (für Anwender nachvollziehbares) Modell des Anwendungssystems aufbauen. Grundlage dazu ist aber ein Modell des Anwendungsbereichs mit einer Beschreibung der alltäglichen Arbeitssituationen am jeweiligen Arbeitsplatz eines Anwenders. Um diese Arbeitssituationen zu beschreiben, verwenden wir einen Dokumenttyp: das Szenario (Plural: Szenarios, nicht Szenarien). Szenarios sind ein Mittel, um ausgesprochene und unausgesprochene Annahmen über den fachlichen Kontext eines zu entwerfenden Werkzeugs oder eines Materials in der Sprache der Anwender zu beschreiben. Szenarios sind damit geeignet, einen Modellierungspro-

5

Zweck von Szenarios


5.2


1217 Abb. 5-19

Handlungsstudie

Szenarios in den Dokumentationsdimension Detail

Aufgabenszenario

Dynamik

Überblicksszenario Überblick

Statik Fachlich

Technisch

zeß zu begleiten, in dem das statische, geschlossene Softwaresystem sich den dynamischen Veränderungen der offenen Anwendungswelt anpassen muß. Szenarios beschreiben die Ist-Situation entlang der in Abbildung 5-19 dargestellten Dimensionen. Wir differenzieren Szenarios dabei je nach Grad der fachlichen Detaillierung in Überblicksszenarios, Aufgabenszenarios und Handlungsstudien (s. Abbildung 5-20, S. 611).

5


5.2


1218

Verständlicherweise sind für den Prozeß der Aufgabenanalyse die Dokumente sämtlich auf der fachlichen Ebene angesiedelt und vernachlässigen die technische Realisierung. Szenarios werden als Prosatexte in der Fachsprache der Anwendung geschrieben. Soweit dies mit den verfügbaren technischen Mitteln einfach möglich ist, werden dabei Begriffe, die in einem Glossar erläutert sind, hervorgehoben. Dazu hat jedes Szenario einen fachlich sprechenden Titel. Es ist sinnvoll, innerhalb des Szenariotextes und in eigenen Rubriken auf verwandte Entwicklungsdokumente, z.B. andere Szenarios, zu verweisen.

Aufbau eines Szenarios

Szenarios beschreiben die verschiedenen Aspekte der Dynamik des Anwendungsbereichs, d.h. die alltäglichen Arbeitssituationen, in denen Menschen mit Arbeitsmitteln und Arbeitsgegenständen selbstverständlich umgehen. Diese Akzentsetzung trifft nicht nur auf die einzelnen Aktionen (im Sinne von »Geschäftsvorfällen«), sondern auch auf die Gegenstände zu, die dabei verwendet werden. Ein Szenario beschreibt dabei als kurzer Prosatext in der Sprache der Anwendung:

Inhalte von Szenarios

❑ alltägliche Arbeitssituationen, ❑ den Ablauf und Zweck von Handlungen und ❑ welche Mittel verwendet werden.

5


5.2


1219

Die Beschreibung orientiert sich dabei vorrangig an den Aufgaben, die eine Person wahrnimmt. Für technisch eingebettete Systeme und Komponenten kommen Beschreibungen der Abläufe einer Maschine hinzu. Aufgabe: Eine Aufgabe wird von einer sachkundigen Person in einem Anwendungsbereich verantwortlich übernommen. Eine Aufgabe bildet eine sinnvolle und zielgerichtete Einheit. Sie ist meist benennbar. Personen können angeben, welche Tätigkeiten in der jeweiligen Situation ausgeführt werden müssen, um eine Aufgabe zu erledigen, und welches Ergebnis mit der Erledigung der Aufgabe erreicht wird.

Aufgaben werden von Fall zu Fall auf unterschiedliche Art und Weise erledigt. Für ihre Beschreibung ist deshalb vorrangig, Ziel und Inhalt der bei der Aufgabenerledigung durchgeführten Tätigkeiten anzugeben. Ein Szenario hilft den Entwicklern, sich in einen anwendungsfachlichen Arbeitskontext einzuarbeiten. Entwickler können so Arbeitssituationen besser verstehen, Fragen zu Arbeitssituationen stellen und Begriffe klären.

5

Eignung von Szenarios für Entwickler und Anwender


5.2


1220

Szenarios werden von Mitgliedern des Entwicklungsteams geschrieben und von den Interviewpartnern, den Anwendern, ausgewertet (s. S. 605). Damit werden zwei Effekte erzielt. Entwickler werden so gezwungen, in der Sprache der Anwender eine sinnvolle und für Anwender nachvollziehbare »Geschichte« zu erzählen. Das setzt voraus, daß die Entwickler die zu beschreibende Anwendungssituation verstanden haben. Zudem erhalten die Anwender durch Szenarios Hinweise darauf, welche ihrer Tätigkeiten so selbstverständlich sind, daß sie in Interviews gar nicht zur Sprache kamen und in welchem Umfang die Aufgaben der Anwender von Entwicklern verstanden wurden. Das Erstellen von Szenarios sollte nicht an einzelne Entwickler delegiert werden, da dies den angestrebten Kommunikations- und Lernprozeß für das Entwicklerteam weitgehend reduziert. Anwender können durch Szenarios ihre eigene Arbeitssituation verständlich machen. Weiterhin können sie »blinde Flecken« in ihrem eigenen Verständnis der Arbeit als auch im Verständnis der Entwickler entdecken.

5


5.2


Der Pausenplanersteller hat für jeden Lehrer einen Stapel von identischen Lehrerkarten, auf welchen der Name des jeweiligen Lehrers angegeben ist. Auf ihnen ist außerdem vermerkt, welche Pausen nicht von dem Lehrer beaufsichtigt werden können.

1221 Szenario Pausenaufsichtsplan erstellen

Diese Karten werden auf den anfangs noch leeren Pausenaufsichtsplan gelegt. Dies geschieht so lange, bis jede Pause mit genau einem Lehrer besetzt ist. Wenn es dem Pausenplanersteller angemessen erscheint, werden Karten auf dem Pausenplan verschoben oder entfernt. Jedesmal, wenn ein Lehrer einer Pause zugeteilt wird, wird die Pausenstatistik aktualisiert. Aus der Pausenstatistik ist ersichtlich, wie viele Pausen welcher Lehrer zu beaufsichtigen hat sowie sein prozentualer Anteil an den Gesamtpausen. Auf diese Weise kann der Pausenplanersteller z.B. halbe und dreiviertel Stellen berücksichtigen. Das Szenario benennt die handelnde Person und wie sie eine bestimmte Aufgabe durchführt. Insbesondere werden dazu die Gegenstände benannt, die zur Durchführung der Aufgabe wann und wie gehandhabt werden. Nicht zuletzt wird deutlich, warum die einzelnen Tätigkeiten dieser Aufgabe durchgeführt werden.

Kommentar

Als Grundlage für Szenarios und anwendungsbezogene Glossareinträge (s. Kapitel 5.2.2) führen Mitglieder des Entwicklungsteams Interviews mit zukünftigen Anwendern. Bei der Vorbereitung der Interviews erstellen sie Interviewleitfäden, in denen solche Themengebiete und Fragenkomplexe gesammelt werden, die im Laufe eines Interviews zur Sprache kommen sollen.

Szenarioerstellung

5


5.2


Das Interview dient dem Lernprozeß bei der Anwendungsanalyse. Es wird von einem Interviewteam mit relevanten Anwendervertretern durchgeführt. Optional besteht es aus den folgenden Teilen:

1222 Das Interview zentrales Mittel der Anforderungsanalyse

❑ Vorstellung des Interviewteams und der Zielsetzung (evtl. in einer eigenen Veranstaltung), ❑ Rollenspiel einer typischen Arbeitssituation, ❑ offenes Gespräch mit dem Interviewten, ❑ gezielte Nachfragen durch das Interviewteam. Für das eigentliche Interview ist es entscheidend, daß der Interviewpartner über Sinn, Zweck und Gegenstand des Interviews informiert wird. Nur so kann eine offene Gesprächsatmosphäre entstehen. Weiterhin gelten die Prinzipien des qualitativen Interviews (vgl. [Lamnek 88]): ❑ Vertraulichkeit und Anonymität sind dem Interviewpartner zuzusichern. ❑ Der Interviewer geht auf die Sprache des Befragten ein, d.h., das Interview ist in der Sprache der Anwendung und des Anwenders zu führen.

❑ Das Interview soll am Arbeitsplatz stattfinden, um für den Interviewpartner eine vertraute Atmosphäre zu gewährleisten.

5


5.2


1223

Das Interview selbst ist: ❑ mündlich-persönlich und nicht standardisiert. Insbesondere gilt es, vorformulierte Fragen und festgelegte Abfolgen zu vermeiden, ❑ in der Fragestellung offen, d.h., es wird inhaltlich (bzgl. Gegenstand und Ablauf) vom Interviewpartner strukturiert und bestimmt. ❑ vom Stil her neutral bis weich und nicht im Sinne eines Verhörs zu führen. Der Interviewer zeigt dabei Sympathie für den Interviewpartner (nicht für die Antworten), ❑ findet als Einzelinterview statt, um Beeinflussungen durch andere auszuschließen. Zur Vorbereitung des Interviews soll ein Interviewleitfaden erstellt werden. Er deckt alle Themenbereiche ab, die den Interviewern wichtig erscheinen und hilft, offene Punkte nachzufragen. Der Leitfadens dient eher der Entwicklung als der Prüfung von Theorien und Einsichten. Das offene Gespräch ist Kernstück des Interviews: Der Interviewpartner soll erzählen. In seiner Erzählung werden Wertungen und Interpretationen deutlich. Wesentlich für das offene Gespräch ist, daß der Interviewpartner einem realitätsnahen Erzählzwang unterliegt. Der Interviewer kann dabei nachfragen, um das eigene Verständnis abzusichern. Bei der Vorbereitung des Interviewleitfadens werden nur Themen und Stichpunkte notiert und nicht detaillierte Fragen

5


5.2


1224

im Sinne eines Fragebogens vorformuliert. Denn schließlich sollen bei den Interviews vor allem die angesprochenen Anwender und Benutzer ihre Sicht der Dinge erläutern. Eine zu starke Regieführung und Vorformulierung von Fragen und Sachverhalten verhindert, daß bei diesen Gesprächen die Anwender in ihrer Sprache und Sichtweise über die fachlichen Aufgaben und ihre Einschätzungen reden. Im Sinne der neutralen Gesprächsführung sollten ausschließlich offene Fragen, d.h. Fragen, die nicht mit ‘ja’ oder ‘nein’ beantwortet werden, gestellt werden. Das Entwicklerteam richtet das Gespräch prinzipiell auf die Ist-Situation aus. Dabei werden die Gesprächspartner von sich aus ihre Wertung und Einschätzungen über Schwachstellen ihrer Arbeit und über wünschenswerte Veränderungen äußern. Dies soll sorgfältig protokolliert und als Teil der ermittelten Anforderungen dokumentiert werden. Moderator und Gesprächsführer sollen allerdings von sich aus vermeiden, zu einem frühen Projektzeitpunkt (d.h. wenn noch keine Prototypen ausgewertet worden sind) Diskussionen über die Gestaltung des zukünftigen Systems im Detail zu führen. Denn die Erfahrungen zeigen, daß Anwender zu Beginn eines Projektes zwar oft Vorstellungen darüber haben, was an ihrer bisherigen Arbeit störend oder veränderungswürdig ist, jedoch selten so viel DV-technische Erfahrung und Wissen besitzen, um in ihren Vorschlägen für ein neues System die Möglichkeiten der Softwaretechnik richtig einschätzen zu können. Zur Vorbereitung des Interviews gehört weiterhin, daß die Interviewer untereinander ihre Rollen klären:

5


5.2


1225

❑ Gesprächsführer: führt das Gespräch und geht intensiv auf den Interviewpartner ein. ❑ Moderator: stellt das Interviewteam vor, behält den Interviewleitfaden im Auge und führt vorsichtig Regie. ❑ Protokollant: schreibt mit und stellt höchstens Verständnisfragen; kann zur Unterstützung eine Tonbandaufzeichnung oder einen Videomitschnitt verwenden. ❑ Beobachter: in der Ausbildungsphase günstig, um neue Mitglieder in das Entwicklungsteam zu integrieren. Typischerweise sind weitere Fragen und Inhalte bei der Vorbereitung eines Interviews zu klären: ❑ Werden die Rollen im Interview gewechselt? ❑ Was ist am Arbeitsplatz zu erwarten? ❑ Wer muß gefragt und informiert werden? ❑ Welches Vorwissen ist vorhanden; ist es ausreichend oder muß zusätzliches Wissen erworben werden? ❑ Welche Vorgespräche sind notwendig? ❑ Muß für den Interviewleitfaden ein Testinterview geführt werden? ❑ Welches Material muß vorbereitet werden: Unterlagen über das eigene Vorhaben, Visitenkarten, Tonbandgerät?

5


5.2


1226

Auf der Grundlage der Protokolle und der Erinnerung der Interviewer werden Szenarios und zugehörige Glossareinträge geschrieben. Fachliche Unterlagen wie Formulare, Leitfäden o.ä. ergänzen das Bild. Interviewvor- und -nachbereitung decken den »Autorenteil« eines Autor-Kritiker-Zyklus ab. Jetzt ist es notwendig, die erstellten Dokumente »kritisch« zu bewerten. Dazu werden sie im Regelfall den interviewten Anwendern vorgelegt und mit ihnen durchgesprochen. Das Konzept der Interviews legt nahe, daß bei dieser »Kritikerrunde« das Interviewerteam vollständig anwesend ist. Als Ergebnis des Auswertungsgesprächs werden die Dokumente überarbeitet. Erst jetzt ist ein Autor-Kritiker-Zyklus durchlaufen. Interviews und Dokumenterstellung sollten zwei zentrale Aspekte des Analyseprozesses zum Ziel haben: ❑ Vielfalt erzeugen und ❑ eine Synthese einleiten.

Vielfalt wird dadurch erzeugt, daß die Interviews mit unterschiedlichen Anwendern geführt und die entsprechenden Dokumente jeweils mit diesen Interviewpartnern ausgewertet werden. Durch die Auswahl unterschiedlicher Gesprächspartner sollen die Entwickler das Spektrum und die Bandbreite der Arbeitsformen und -prozesse erkennen. Um diese Vielfalt zu erzielen, müssen die Entwickler darauf achten,

5


5.2


1227

daß diese Vielfalt schon bei den Interviews »angeregt« und nicht durch vorschnelle Querbezüge zu anderen Interviews unterdrückt wird. Anders stellt sich die Situation dar, wenn auf der Basis einer bereits erkannten Vielfalt der Syntheseprozeß eingeleitet wird. Dann werden die erstellten Dokumente nicht individuell mit den Interviewpartnern besprochen, sondern die Auswertung findet z.B. während einer gemeinsamen Arbeitssitzung statt. Dort werden die versammelten Gesprächspartner dann gezielt mit den unterschiedlichen Positionen konfrontiert. Explizites Diskussionsziel ist, Vereinheitlichungen und wesentliche Unterschiede zu identifizieren, um aus der erkannten Vielfalt ein integriertes Anwendungssystem erstellen zu können. Wir haben in solchen Plenumsdiskussionen durchgängig erlebt, daß viele der zunächst unterschiedlichen Positionen zu einem gemeinsamen Kompromiß zusammengefaßt werden konnten, und daß nur wenige echte Differenzen zwischen den Anwendern in alternativen Systemlösungen aufgegriffen werden mußten. Beide Ergebnisse sind erwünscht: Der Kompromiß zwischen unterschiedlichen Ansätzen erleichtert die Entwicklung eines »schlanken« Systems und die frühzeitige Identifikation von relevanten Unterschieden in den Anforderungen macht klar, wo ein System flexibel für Varianten gestaltet werden muß.

5


5.2


1228

Das Szenario ist der vorrangige Dokumenttyp in der Kommunikation zwischen Entwicklern und Anwendern zu Projektbeginn. Es unterstützt die Analyse und Modellierung eines bestehenden Aufgabenbereichs. Szenarios sind darüber hinaus von unmittelbarer Bedeutung im gesamten Entwicklungsprozeß, da sie helfen, die technischen Entwurfsentscheidungen auf fachliche Gegebenheiten zu beziehen. Diese Aufgabe erfüllen sie natürlich auch bei späteren Weiterentwicklungen von Teilen des Anwendungssystems. Es hat sich als sehr sinnvoll erwiesen, Szenarios auch bei scheinbar rein technischen Verbesserungen zu Rate zu ziehen, weil viele technische Entwurfsentscheidungen nur im Lichte von fachlichen Zusammenhängen klar werden. M. M. Lehman stellt in [Lehman 90] fest, daß in jeweils 5 bis 8 Zeilen Programmcode eine dort nicht dokumentierte Annahme über den fachlichen Kontext eines Programmes enthalten ist. Da ein (mit den Anwendern abgestimmtes) Szenario einen wesentlichen Zustand des Anwendungsbereichs beschreibt, wird es aufbewahrt und nicht kontinuierlich fortgeschrieben. Verändert sich die Situation, die ein Szenario beschreibt, dann muß eine neue Version des Szenarios geschrieben werden.

Einsatz eines Szenarios im

5

Entwicklungsprozeß


5.2


1229

Ein neues, mit den Anwendern abzustimmendes Szenario soll auch dann geschrieben werden, wenn sich der Kenntnisstand über den Anwendungsbereich verändert hat. Ob eine Anwendungssituation hinreichend gut beschrieben ist, läßt sich nicht aus der Anzahl und dem Umfang der Szenarios ableiten. Demzufolge können wir auch keine Faustregeln angeben, wie viele Aufgabenszenarios oder wie detailliert Handlungsstudien geschrieben werden sollen. Wir warnen aber vor dem Mißverständnis, daß erst alle Szenarios geschrieben werden müssen und dann alle weiteren Dokumente. Dahinter steht die Illusion, daß etwas vollständig beschrieben werden kann. Wichtig ist die Einsicht, daß wir durch Lernprozesse zu einem späteren Zeitpunkt erst merken, was wir über den Anwendungsbereich noch wissen müssen. Aufgaben im Anwendungsbereich zu identifizieren und zu beschreiben ist ein kreativer Prozeß, der nur grob durch Leitlinien unterstützt werden kann. Wir können hier nur noch einmal betonen, daß Szenarios (und auch andere Dokumenttypen) ein aktuelles Projektverständnis repräsentieren, das sich dynamisch entwickelt. Wir unterbreiten mit den unterschiedlichen Subtypen von Szenarios ein Angebot, verschiedene, von uns als relevant betrachtete Situationen in einem Dokumenttyp festzuhalten. Insofern verstehen wir alle Dokument-

5

Anzahl Szenarios und zeitlicher Umfang


5.2


1230

typen als ein »materialisiertes« Verständnis von Situationen im Entwicklungsprozeß. In den Interviews werden häufig Wunschvorstellungen für die künftige Arbeit und Schwachstellen der gegenwärtigen Situation genannt. Diese müssen identifiziert und sorgfältig daraufhin untersucht werden, in welchem Dokumenttyp sie Eingang finden. Wünsche und Vorstellungen zu zukünftigen Arbeitsweisen gehören in den Dokumenttyp ermittelte Anforderungen. Erkannte Schwachstellen im Arbeitsablauf oder bei den dabei verwendeten Gegenständen sind Wertungen, die in die Szenarios gehören. In Szenarios verwendete Begriffe werden im Glossar notiert. Dadurch wird gewährleistet, daß einheitliche Begriffe in den verschiedenen Szenarios benutzt werden. Andererseits macht ein Glossar auch deutlich, daß in verschiedenen Szenarios Begriffe unterschiedlich verwendet werden. Szenarios bilden die Grundlage für die Erstellung von Systemvisionen. Da Szenarios an den Aufgaben der Anwender orientiert sind, können sie für das »Durchspielen« zukünftiger Aufgaben unter Verwendung der neu entworfenen Werkzeuge und Materialien eingesetzt werden.

5

Zusammenhang mit anderen Dokumenttypen


5.2


1231

Beim Prototyping helfen Szenarios, Drehbücher zu erstellen und die Bewertung von Prototypen vorzubereiten. Zusätzliche Impulse, um das Modell des Anwendungsbereichs zu verfeinern, entstehen bei der Arbeit am fachlichen Begriffsmodell, dem Klassenentwurf oder bei der Präsentation von Prototypen in Arbeitskreisen. Oft stellt sich dabei heraus, daß die bisherige Sicht der Anwendung noch nicht konsistent ist. Bei der Arbeit mit Visionen und technischen Entwürfen zeigen sich auch »Interpretationen« über die Anwendungssituation, die so nicht zu halten sind. Wichtig ist, daß überarbeitete Szenarios wieder mit den Anwendern abgestimmt und daß alte Versionen aufbewahrt werden. Nicht zuletzt können Szenarios im Anwendungsbereich als Aufgabenbeschreibungen für neue Mitarbeiter verwendet werden. Die hier vielfältig skizzierten Querbezüge zu anderen Dokumenttypen machen den zentralen Stellenwert von Szenarios im Entwicklungsprozeß deutlich. Für die Beschreibung komplexer Arbeitszusammenhänge und größerer Aufgabenbereiche ist es häufig sinnvoll (aber nicht zwingend), Szenarios nach der Detailgenauigkeit der beschriebenen Zusammenhänge zu unterteilen. Wir stellen eine Ausdifferenzierung vor, die sich aus den Anforderungen von Kooperationsprojekten ergeben hat. Dabei haben

5

Subtypen von Szenarios


5.2


1232 Abb. 5-20

Szenario

Dokumenttyp Szenario mit Subtypen

Handlungsstudie

detailliert

Aufgabenszenario

detailliert

Überblicksszenario

wir versucht, spezifische Anforderungen soweit zu verallgemeinern, daß sie auch auf neue Projekte übertragbar sind. Die Subtypen zeigen also mögliche Differenzierungen, die dann sinnvoll sind, wenn sich bestimmte Fragen nicht bereits auf einer allgemeinen Ebene klären lassen: ❑ Das Gesamtbild eines Arbeitsplatzes oder eines Anwendungs-

bereichs beschreibt das Überblicksszenario. ❑ Auf der Ebene einzelner Aufgaben und zusammengehöriger

Tätigkeiten sind die Aufgabenszenarios angesiedelt. ❑ Handlungsstudien betrachten einzelne Aktionen, Tätigkeiten,

Handlungsabläufe. Abbildung 5-20 verdeutlicht den Zusammenhang zwischen den Subtypen von Szenarios.

5


5.2


Überblicksszenarios geben einen Überblick über die zur Diskussion stehende Arbeitssituation als Ganzes. Hier soll ein Bild darüber entstehen, welche Personen an welchen Arbeitsplätzen mit welchem Aufwand (und welcher Häufigkeit) welche Aufgaben zu erledigen haben. Die Betonung liegt dabei auf den zu benennenden Aufgaben. Diese klar herauszuarbeiten, ist das Ziel eines Überblicksszenarios. Details in diesen Szenarios betreffen allenfalls das gegenwärtige Mengengerüst. Hier liegt die Konzentration darauf, was an Aufgaben in einem Anwendungsbereich von den (verschiedenen) Personen zu erledigen ist. Überblicksszenarios sollen sich dadurch auszeichnen, daß beim Leser ein Eindruck über die Aufgabenstellungen der beteiligten Personen entsteht. In Überblicksszenarios wird es günstig sein, die benannten Aufgaben auch sogenannten funktionellen Rollen zuzuweisen. Ebenso sind Verweise auf detaillierte Szenarios sinnvoll.

1233 Überblicksszenario

Funktionelle Rolle: Eine funktionelle Rolle ist im Sinne von [Floyd 97] eine Sammlung von Aufgaben und Verantwortlichkeiten, die einem prototypischen Arbeitsplatz und einer Rolle zugeordnet sind. Diese Rolle kann dann von einer oder mehreren Personen »besetzt« werden. Die Zuordnung kann zeitlich wechselnd, dauerhaft, informell oder in der Unternehmenshierarchie festgeschrieben sein. Wichtig ist, daß eine Rolle sprechend benannt ist.

5


5.2


Die kontinuierliche Pflege des Pausenplans gehört zu den Aufgaben des Pausenplaners in der Schule. Dazu muß pro Schulhalbjahr ein Pausenplan erstellt werden, aus dem die Aufsichtspflichten der einzelnen Lehrer erkennbar sind (siehe Aufgabenszenario Pausenaufsichtsplan erstellen, S. 605). Änderungen in der Aufsichtsbereitschaft werden vom Pausenplaner ständig im Pausenplan aktualisiert (siehe Aufgabenszenario Aufsichtsbereitschaft aktualisieren, S. 436). Weiterhin muß der Pausenplaner berücksichtigen, daß durch Krankheit oder Tod ein Lehrer zeitweise oder ganz für die Pausenbetreuung ausfallen kann (siehe Handlungsstudie Pausenstatistik aktualisieren, S. 613).

1234 Überblicksszenario

Pausenplanbearbeitung

Das Überblicksszenario benennt die Aufgaben des Pausenplaners ohne deren konkrete Erledigung vorwegzunehmen. Dazu verweist es lediglich auf die zugehörigen Aufgabenszenarios. Insgesamt soll durch das Überblicksszenario umrissen werden, welche Aufgaben die Entwickler für den Pausenplaner sehen.

Kommentar

Der Szenario-Subtyp Aufgabenszenario beschreibt, was eine einzelne Aufgabe ausmacht und wie eine einzelne Aufgabe insgesamt erledigt wird. Diese Beschreibung hat den Charakter eines »Drehbuchs« oder einer kleinen szenischen Schilderung. Alternativen an einzelnen Entscheidungspunkten der Handlung werden zwar erfaßt, aber möglichst sparsam. Hier gilt es abzuwägen, ob im Rahmen eines Szenarios mehrere Alternativen von sehr ähnlichen Aktionen zur Erledigung einer Aufgabe beschrieben werden (»der Kunde nennt entweder seinen Namen und seine Anschrift oder seinen Namen und seine Kontonum-

Aufgabenszenario

5


5.2


1235

mer«) oder ob zwei im Grundsatz verschiedene Herangehensweisen an eine Aufgabe nicht besser in zwei getrennte Szenarios gehören (»Ein Neukunde richtet ein Konto und einen Dauerauftrag ein« sowie »Ein Stammkunde richtet einen weiteren Dauerauftrag ein«). Als Leitlinie kann hierbei gelten, daß einfache Fallunterscheidungen beim Lesen noch nachvollziehbar sind, geschachtelte mehrfache Fallunterscheidungen oder Fallunterscheidungen, die sich selbst wieder auf vorhergehende Unterscheidungen beziehen, aber unverständlich werden. Die Detaillierung eines Aufgabenszenario geht nur soweit, daß einzelne Handlungen, die bei unterschiedlichen Aufgaben immer wieder vorkommen, zwar benannt sind, in ihrer genauen Beschreibung aber ausgeklammert und in eigenen Handlungsstudien untergebracht werden. Nur im Einzelfall sollen spezifische Handlungen, die zum Verständnis der Erledigung einer Aufgabe wesentlich sind, beschrieben werden. Dabei ist jedoch darauf zu achten, daß dies nicht in einer Vorschrift endet, wie eine Aufgabe in genau einer Art und Weise zu erledigen ist. Handlungsstudien beschreiben einzelne Schritte zur Erledigung einer Aufgabe im Detail. Oft sind dies Handlungen, wie etwa das Ausfüllen eines bestimmten Formulars oder ein Prüfvorgang, die selbst wieder im Kontext unterschiedlicher Aufgaben auftreten. Typisch für eine

5

Handlungsstudie


5.2


1236

Handlungsstudie ist z.B., wenn beim Ausfüllen eines Formulars bestimmte Details zu beachten sind, oder wenn eine bestimmte Prüfung oder Berechnung mehrfach an verschiedenen Stellen durchgeführt wird. Handlungen sind in diesem Zusammenhang konkrete körperliche Bewegungen, geistige Aktivitäten oder maschinelle Aktionen, die sich an den Arbeitsgegenständen und -mitteln orientieren. Sie sind die detaillierteste Form der Unterteilung von Arbeit im Anwendungsbereich. Aus der Beschreibung von Handlungen ist ablesbar, wie etwas genau und unter Verwendung welcher Hilfsmittel geschieht. Die Pausenstatistik muß aktualisiert werden, wenn Lehrer krank werden, wenn neue Lehrer an die Schule kommen bzw. Lehrer die Schule verlassen, z.B. weil sie gestorben sind. Der Pausenplaner nimmt die Berechnung, wie viele Pausen ein Lehrer beaufsichtigen muß, nach folgender Formel vor:

P (l x ) =

Handlungsstudie Pausenstatistik aktualisieren

A( l x ) * GP GA

dabei bedeutet:

lx – Lehrer x GP GA P(lx) A(lx)

– Gesamtzahl der Pausenaufsichten pro Woche – Summe der Arbeitsstunden aller Lehrer – Pausenaufsichten für Lehrer X pro Woche – Arbeitsstunden von Lehrer X pro Woche

5


5.2


1237

Bei der Rundung der Pausenaufsichten auf eine Kardinalzahl achtet der Pausenplaner darauf, daß die Summe der einzelnen Pausenaufsichten nach dem Runden die tatsächliche Anzahl der zu beaufsichtigenden Pausen ergibt. Der Zweck dieser Handlungsstudie ist, die Aktualisierung der Pausenstatistik möglichst genau zu beschreiben, so daß für den Außenstehenden das mathematische Verfahren deutlich wird. Für den Kontext der Handlungsstudie, also ein oder mehrere Aufgabenszenarios, sind diese einmal beschriebenen Details uninteressant.

Kommentar

5.2.2 Glossar Glossar: Ein Glossar ist ein Verzeichnis der relevanten Begriffe eines Anwendungsbereichs. Die Begriffe beziehen sich sowohl auf die dort verwendeten Gegenstände als auch auf die damit verbundenen Umgangsformen. Ein im Glossar aufgeführter Begriff ist ein Glossareintrag. In diesem Sinne ist ein Glossar das Wörterbuch der jeweiligen Fachsprache, die einem Anwendungssystem zugrunde liegt.

Ein Glossar ist der zentrale Ort für die fachliche und die technische Begriffsbildung soweit sie anwendungsfachlich relevant ist. Es dient damit dem Aufbau einer gemeinsamen Projektsprache und unterstützt die Einarbeitung der Entwickler in den Anwendungsbereich.

5

Zweck eines Glossars


5.2


1238 Abb. 5-21 Das Glossar in den Dimensionen der

Glossar

Detail

Dokumentation

Dynamik

Überblick

Statik Fachlich

Technisch

Abbildung 5-21 zeigt die Positionierung des Glossars im vorgestellten Bezugssystem. Das Glossar betont also den statischen Aspekt der IstSituation, nicht jedoch die dynamischen Aspekte, die in Szenarios beschrieben werden. Weiterhin wird deutlich, daß sowohl fachliche als auch technische Begriffe im Glossar definiert werden. Glossare sind durch ihre alphabetische Auflistung von Begriffen der Fachsprache eine Grundlage für den Entwurf eines Anwendungssystems. Sie sind auch eine gute Hilfe bei Einarbeitung neuer Teammit-

5


5.2


1239

glieder in einen Anwendungsbereich. Zudem dokumentieren sie den Diskussionsstand beim Entwurf an den Stellen, wo sich das Entwicklerteam auf ein gemeinsames Verständnis eines Begriffs geeinigt hat. Die Frage bei der Erstellung von Glossareinträgen ist: Wozu ist der Begriff oder Gegenstand gut und welchen Sinn hat er? Damit ist nicht die Struktur oder der innere Aufbau gemeint, sondern vielmehr, wozu der Gegenstand gebraucht wird. Als Beispiel kann der Formularordner dienen. Eine knappe Charakterisierung wäre: »Ein Formularordner stellt die in einer Beratungs- und Verkaufssituation notwendigen Formulare nach unterschiedlichen bankfachlichen Kategorien als Kopien bereit.« Nicht ausreichend wäre eine Inhaltsangabe nach dem Schema: »Ein Formularordner enthält die Formulare ›Vertragsformular Sparen mit Zuschlag‹ …«. Zur (konzeptionellen) Strukturierung eines Glossareintrags gibt es in der Literatur zwar viele Anregungen, aber wir sehen die Gefahr, daß sich eine zu starre Strukturvorgabe hinderlich bei der Arbeit mit dem Glossar auswirkt. Wesentlich ist, daß ein Glossareintrag mit einer inhaltlichen Erklärung über Sinn und Zweck des beschriebenen Gegenstandes beginnt. Das folgende Beispiel für die Struktur eines Glossareintrags soll nur als Anregung dienen:

5

Aufbau von Glossareinträgen


5.2


1240

❑ Name, ❑ Bedeutung, d.h. inhaltliche Kurzbeschreibung (was ist es, wie

funktioniert es, wozu ist es gut), ❑ Struktur (wie ist es aufgebaut, aus welchen Teilen besteht es), ❑ Beispiel, ❑ Kontext (in welchem Zusammenhang mit anderen Begriffen

und Konzepten steht der Begriff), ❑ Sichtweise (wer hat die Beschreibung aus welcher »funktionel-

len Rolle« in welchem Projekt erstellt), ❑ Referenzen auf andere Entwicklungsdokumente.

Die Benennung und Strukturierung eines Glossareintrags ist vom jeweiligen Kontext abhängig. Wie das unten aufgeführte PausenplanBeispiel zeigt, kann ein aussagekräftiger Eintrag zwar Strukturmerkmale enthalten, muß jedoch nicht alle Bestandteile umfassen. Der Inhalt und die Art der Beschreibung eines Glossars orientieren sich primär an der Sprache der Anwendung. Dabei sollen alle fraglichen Begriffe dokumentiert werden, die im Anwendungsbereich verwendet werden. Formal kann nicht festgelegt werden, welche Begriffe

5

Inhalte eines Glossars


5.2


1241

so trivial oder selbstverständlich sind, daß sie nicht in ein Glossar gehören. Wenn unterschiedliche Fachabteilungen die gleichen Begriffe verwenden, aber ihnen unterschiedliche Bedeutung zuordnen, oder wenn mehrere Projekte ein gemeinsames Glossar aufbauen, ist es notwendig, die unterschiedlichen »Quellen« oder Sichtweisen eines Glossareintrags deutlich zu machen. Nur so kann es im Laufe der Zeit gelingen, Glossareinträge und eine sich verändernde Fachsprache in annähernder Übereinstimmung zu halten, und im Rückblick Entwurfsentscheidungen fachlich verständlich zu dokumentieren. Glossare bieten Mitarbeitern der Fachabteilungen die Möglichkeit, zusammen mit den Entwicklern die Bedeutung von Begriffen ihrer Umgangs- und Fachsprache zu reflektieren. Glossareinträge machen oft Unklarheiten im Verständnis der Entwickler deutlich, was dann Anlaß zur Überarbeitung bereits bestehender, anderer Dokumente ist.

5

Eignung von Glossaren für Entwickler und Anwender


5.2


1242 Glossareinträge

Begriff

Erläuterung

Ausschlußzeitraum

Ein Ausschlußzeitraum ist eine Zeitspanne, in welcher ein Lehrer nicht zur Pausenaufsicht eingeteilt werden sollte.

Lehrer

Der Lehrer an einer Schule. Er ist im Kontext des Pausenplansystems eine Person, die Pausenaufsichten führen muß, also ein Pausenbeaufsichtiger.

Lehrerkarte

Eine Karte, auf der die für die Pausenplanung relevanten Informationen notiert sind. Diese Informationen sind im einzelnen der Name des Lehrers, die Stelle, die Anzahl der Aufsichtspflichten und die Ausschlußzeiträume des Lehrers. Die Anzahl der Lehrerkarten zu einem Lehrer entspricht der Anzahl der Aufsichtspflichten, denen er im Rahmen seiner Stelle nachzukommen hat (siehe dazu Szenario Pausenaufsichtsplan erstellen, S. 605).

Lehrkörper

Der Lehrkörper ist anwendungsfachlich die Menge der Lehrer, die an einer Schule beschäftigt sind. Systemtechnisch bezeichnet der Lehrkörper einen Behälter, der die Lehrer der Schule enthält und verwaltet.

für das

5

Pausenplanbeispiel


5.2


1243

Glossareinträge werden im engen Zusammenhang mit Szenarios erstellt. Wir betonen die enge Verknüpfung des Glossars mit den Interviews »vor Ort«. Auf der Grundlage der Protokolle und der Erinnerung der Interviewer werden Szenarios und zugehörige Glossareinträge geschrieben. Nur dadurch kann sichergestellt werden, daß die Fachsprache der Anwendung im Glossar dokumentiert wird und nicht die Vorstellung, die das Entwicklungsteam sich davon macht. Wir warnen ausdrücklich davor, Fachbegriffe aus Nachschlagewerken ohne weitere Abstimmung mit den Anwendern zu entnehmen, um so vordergründig Zeit zu sparen. Es hat sich gezeigt, daß selbst scheinbar allgemeingültige Begriffsdefinitionen ihre »lokale« Interpretation und Verwendung haben. Einmal im Glossar eingetragen, gewinnen diese »unscharfen« Begriffe eine Eigendynamik, die nur schwer aufzuhalten ist und teils zu schweren Entwurfsfehlern führt.

Erstellung eines Glossars

Glossare beziehen sich direkt auf die in Szenarios und Systemvisionen verwendeten Begriffe. Ein Glossar soll den aktuellen Stand, aber auch die Entwicklung der »Projektsprache« widerspiegeln. Idealerweise lassen sich aus einem gesamten Glossar Auszüge der jeweiligen Projektglossare und der Projektgeschichten erstellen. Es ist deshalb sinnvoll, Entwurfsdokumente mit den Einträgen im Glossar zu verbinden.

Einsatz eines Glossars im

5

Entwicklungsprozeß


5.2


1244

Im Einzelfall muß geklärt werden, ob es ein einheitliches oder viele projektspezifische Glossare geben sollte. Dazu gilt auf der technischen Seite, daß sich ein großes Glossar sehr viel schwerer pflegen läßt als mehrere kleine. Fachlich ermöglicht ein großes Glossar allerdings, daß jedes Projekt für die eigene Arbeit bereits auf die konsolidierten Ergebnisse der Vorprojekte zurückgreifen kann. Die Motivation, ein großes Glossar ohne technische Unterstützung insgesamt konsistent zu halten, wird wiederum aus der Sicht eines einzelnen Projektes relativ gering sein. Die optimale Lösung für den Einsatz im Entwicklungsprozeß hängt von einer entsprechenden technischen Unterstützung ab, und ist mit einer guten Projektbibliothek vergleichbar: Jedes Projekt kann sich »seinen Auszug« eines Glossars erstellen (»check out«) und auf diesem Ausschnitt über einen längeren Zeitraum unabhängig weiterarbeiten. An festgelegten Punkten wird das Projektglossar in das Gesamtglossar reintegriert (»check in«). Diese Integration bedeutet nicht, daß damit die projektspezifische Sicht verlorengeht. Es muß nur geprüft werden, an welchen Stellen Vereinheitlichungen sinnvoll und notwendig sind, und wo projektspezifische Differenzierungen eines Begriffs erhalten bleiben. Beispielsweise kann der Begriff »Kundeninformation« für die Passivberatung durchaus etwas anderes bedeuten als für die Wertpapier-

5


5.2


1245

beratung. Allerdings wäre es ungünstig, wenn beide Projekte eine unvereinbare Vorstellung vom Begriff »Kontonummer« hätten. Zwar ist mittlerweile durch die Verwendung von entsprechenden Data Dictionaries ein großer Fortschritt gegenüber der manuellen Glossarverwaltung erreicht, aber das Sortieren und Suchen sowie die Verwaltung von Querverweisen in umfangreicheren Glossaren sind Arbeitsformen, die noch besser technisch unterstützt werden müssen. Ohne einen hohen Benutzungskomfort wird ein umfangreiches Glossar selten aktiv genutzt. In der Folge tritt dann der zweite negative Effekt auf, daß ein nur partiell gepflegtes Glossar die Frage aufwirft, welche Begriffsbeschreibungen überhaupt noch aktuell und welche bereits in der Projektpraxis überholt sind. Recht gute Erfahrungen haben wir in Projekten gesammelt, die die Hypertext-Fähigkeiten von Web-Browsern für die Dokumentverwaltung nutzen. Dazu sind bereits erste Arbeiten entstanden [Dittrich et al. 96, Heybrock et al. 97]. Generell gilt hier wieder, was wir schon zu den Szenarios gesagt haben: Die Begriffe einer Fachsprache lassen sich niemals vollständig definieren. Es macht auch keinen Sinn, ein Glossar »am Anfang« erstellen zu wollen. Denn zu den Begriffen der »ursprünglichen« Fachsprache kommen mit der Zeit weitere, die sich durch das neu entwickelte

5

Anzahl der Glossareinträge und zeitlicher Umfang


5.2


1246

Anwendungssystem ergeben. Schließlich wird ja auch dieses System Teil des Anwendungsbereichs. Diese neuen, auf das Anwendungssystem bezogenen Begriffe, helfen festzustellen, wo und in welchem Umfang sich Veränderungen und Einschnitte in der Fachsprache ergeben haben, d.h., wo die Fachsprache »rekonstruiert« wurde. Daraus wird deutlich, daß das Glossar kontinuierlich im Entwicklungsprozeß weiterentwickelt werden muß. Insgesamt dient das Glossar nicht nur zur Entwicklung und Weiterentwicklung des Anwendungssystems, es sollte auch eine Grundlage der Benutzungsdokumentation sein. Abstimmungsprobleme können zwischen Glossar und Entwürfen auftreten, wenn beispielsweise eine vorliegende Formularbeschreibung oder eine Berechnungsvorschrift so detailliert sind, daß sie nicht mehr sinnvoll im Glossar untergebracht werden können. Dann gehören diese Beschreibungen unmittelbar in ein Entwurfsdokument. Glossare bilden zusammen mit Szenarios die Grundlage für die Erstellung der Systemvisionen (siehe unten) und damit auch für die Anfertigung von Prototypen.

5



5.2


1247

5.2.3 Systemvisionen Systemvision: Eine Systemvision beschreibt als kurzer Prosatext, wie fachliche Aufgaben mit Hilfe des zukünftigen Anwendungssystems unter Verwendung von Werkzeugen, Automaten und Materialien erledigt werden können. Dabei werden sowohl fachliche als auch technische Gesichtspunkte betrachtet. Eine Systemvision ist Grundlage für Entwickler, sich ein gemeinsames Verständnis über die Gestaltung des zukünftigen Anwendungssystems zu erarbeiten. Systemvisionen dokumentieren damit das aktuelle Verständnis der Projektmitarbeiter über das zu entwickelnde Anwendungssystem.

Im WAM-Ansatz haben Systemvisionen eine hohe Bedeutung bei der Verknüpfung von Analyse und Entwurf. Denn während Systemvisionen erarbeitet werden, wird oft intensiv über das Leitbild und die Entwurfsmetaphern diskutiert. Hier stellen sich Fragen nach den zu entwerfenden Gegenständen und ihrer Repräsentation ebenso wie nach den Aufgaben, deren Durchführung vom zukünftigen System unterstützt werden sollen. Im folgenden haben wir diese Fragestellungen aufgegliedert. Dabei unterscheiden wir die in Abbildung 5-22 dargestellten drei

5

Zweck einer Systemvision


5.2


1248

Dimensionen bei der Gestaltung des zukünftigen Systems. Sie führen zu Systemvisionen, ❑ die einen Überblick über das gesamte zu entwickelnde System

geben (Dimension: Überblick – Detail), ❑ die den dynamischen Ablauf aus fachlicher oder softwaretech-

nischer Sicht darstellen (Dimension: Statik – Dynamik), ❑ die entsprechend den Entwurfsmetaphern die einzelnen Kom-

ponenten des Systems modellieren (Dimension: Fachlich – Technisch).

Handhabungsvision Fachliche Ablaufvision

Abb. 5-22 Technische Ablaufvision

Systemvisionen in den Dimensionen der Dokumentation

Detail

Werkzeug- , Automatenund Materialvision

Dynamik

Überblicksvision Überblick

Statik

Einbettungsvision

Fachlich

Technisch

5


5.2


1249

Das Muster zur Erstellung von Systemvisionen ist dabei immer dasselbe: Eine Fragestellung oder eine Gruppe zusammengehöriger Fragen ist die Grundlage für eine bestimmte Art von Systemvision. Zentraler Gedanke ist die möglichst nahtlose Verbindung von Konzepten des Anwendungsbereichs mit Konzepten der softwaretechnischen Konstruktion. Eine Systemvision

Aufbau von Systemvisionen

❑ hat einen fachlich motivierten Titel, ❑ gehört zu einer fachlich motivierten Gruppe von Systemvisio-

nen, ❑ orientiert sich an den vorgegebenen Fragestellungen.

Konkretisiert wird dieser sehr allgemein gehaltene formale Aufbau jeweils durch die zu bearbeitende Fragestellung. Im Zentrum des Interesses steht bei Systemvisionen, wie der Zusammenhang der anwendungsfachlichen zur softwaretechnischen Welt modelliert wird. Dazu haben wir die oben genannten Arten von Fragestellungen jeweils der Welt der Anwendung und der Welt der Softwaretechnik zugeordnet. Aus der Positionierung der Dokumenttypen entlang der oben dargestellten Dimensionen ergeben sich die zielführenden fachlichen und technischen Fragestellungen für die jeweilige Ausarbeitung.

5

Inhalte von Systemvisionen


5.2


1250

Auf der fachlichen Seite sollen die Fragen nach ❑ alten und neuen Aufgaben, ❑ vom System unterstützten / nicht unterstützten und ❑ der Verantwortung für fachliche Aufgaben

im Vordergrund stehen. Diese mit Blick auf Szenarios zu beantwortenden Fragen erlauben es, einen Überblick über das zu entwerfende System zu entwickeln. Antworten auf diese fachlichen Fragen werden in einer Überblicksvision (s. Abbildung 5-23, S. 625) gegeben. Der fachlich motivierte Überblick wird konkretisiert durch Fragen nach der Handhabung des Systems mit Bezug auf die zu erledigenden Aufgaben: ❑ Wie läuft die Erledigung einer Aufgabe mit Hilfe des Systems? ❑ Welche fachlichen Komponenten werden zusammen benötigt? ❑ Wie sieht deren Handhabung aus? ❑ Wie sieht ein entsprechender Arbeitsplatz aus?

Diese mit Blick auf Aufgabenerledigung zu beantwortenden Fragen stellen einen konkreten Bezug zur Anwendungswelt und zu den zu ent-

5


5.2


1251

werfenden Komponenten her. Antworten auf diese fachlichen Fragen werden in Handhabungs- und Ablaufvisionen (s. Abbildung 5-23) gegeben. Den fachlich motivierten Fragen stehen auf der technischen Seite zunächst die Fragen nach der Einbettung des zu entwickelnden Systems in die bestehende technische Umgebung gegenüber. Zentrale Fragen sind hier: ❑ Welche externen Services werden durch das neue System benö-

tigt? ❑ Welche Protokolle und Formate müssen eingehalten werden? ❑ Welche Anteile der bestehenden Systemumgebung sind durch

das neue System änderungsbedürftig? ❑ Wie werden Komponenten in den informationstechnischen

Kontext eingebettet? Antworten auf diese technisch motivierten Fragen werden in einer Einbettungsvision (s. Abbildung 5-23) gegeben. Die technisch motivierte Einbettungsvision wird durch entsprechende Komponentenvisionen (s. Abbildung 5-23) ergänzt. Zentrale Fragen betreffen hier die Gestaltung einer Komponente:

5


5.2


1252

❑ Welche Funktionalität hat ein Werkzeug? Wie sieht es aus? ❑ Welche Funktionalität hat ein Material? ❑ Wie läuft ein Automat ab? ❑ Wie hängen die technischen Komponenten zusammen?

Komponentenvisionen sind dabei jeweils an einem Exemplar eines Werkzeugs, Materials oder Automaten orientiert. Welche Fragestellungen in einem Projekt relevant sind und in welcher Reihenfolge die Fragestellungen bearbeitet werden, kann nur projektspezifisch beantwortet werden. Nicht in jedem Projekt wird es notwendig sein, alle Dimensionen mit den damit verbundenen Fragestellungen abzudecken. Auch die Reihenfolge der Erstellung kann je nach Vorwissen der Beteiligten oder Ausgangslage des Projektes variieren. Wichtig scheint uns deshalb festzuhalten, daß die Visionssubtypen jeweils eine bestimmte Fragestellung besonders hervorheben sollen. Erst wenn alle Fragestellungen beachtet werden, ergibt sich ein ausgewogenes Konzept der technischen Unterstützung. Folglich ist es nach unserer Meinung gefährlich, die einzelnen Fragestellungen sequentiell hintereinander entwickeln zu wollen oder für deren Beantwortung unterschiedliche Personengruppen zu beauftragen – etwa in der Art, daß generelle Fragen vorrangig vom Projektmanagemenent

5


5.2


1253

erstellt werden oder daß zunächst eine Abgrenzung zu bestehenden Systemen erstellt werden soll. Eine derartige Orientierung führt mit Sicherheit zu einem schiefen Konzept. Systemvisionen sind zunächst für Entwickler ein Mittel, um ihre Ideen zu vergegenständlichen und sie der Diskussion zugänglich zu machen. Während in den entwicklungsorientierten Zyklen alle Arten von Systemvisionen einbezogen werden, sind bei den Gesprächen mit Anwendern nur bestimmte Visionsarten als Grundlage sinnvoll:

Eignung von Systemvisionen für Entwickler und Anwender

❑ Überblicksvisionen sind für das Management der Entwick-

lungs- und der Anwendungsorganisation eine wichtige Entscheidungsgrundlage, da hier die angestrebte Aufgabenverteilung deutlich wird. ❑ Fachliche Ablaufvisionen eignen sich im Gespräch mit späteren

Anwendern, da hier die Dynamik aus fachlicher Sicht beschrieben wird. ❑ Materialvisionen haben sich als Grundlage für den fachlichen

Klassenentwurf bewährt, nachdem sie als statisches, fachliches Modell mit den Anwendern abgestimmt wurden.

5


5.2


1254

Für die Diskussion zwischen Entwicklern und Anwendern sind Werkzeugvisionen und Automatenvisionen in der Regel nicht geeignet, da Anwendern die softwaretechnischen Voraussetzungen fehlen, um sich ein stimmiges Bild über das Verhalten eines Werkzeugs oder über den Ablauf eines Automaten machen zu können. Damit besteht die Gefahr, daß anhand von Oberflächenentwürfen oder Ablaufskizzen eine vordergründige Übereinkunft über diese Systemkomponenten erzielt wird, die sich aber in der weiteren Entwicklung als unhaltbar erweist. Systemvisionen haben am Anfang den Charakter von Skizzen und Protokollnotizen, die vom Projektteam benutzt werden. In einer Systemvision hält der Protokollant das Diskussionsergebnis aus seiner Sicht fest und ist damit der Autor. Die übrigen Mitglieder des Entwicklungsteams sind in der nächsten Projektsitzung die Kritiker, deren Aufgabe darin besteht, die Darstellung des Autors mit den eigenen Sichtweisen in Einklang zu bringen. Daraus entwickelt sich dann die nächste Version des Dokuments. Deshalb ist es bei der Arbeit mit Systemvisionen besonders negativ, wenn die Autoren der Dokumente und die eigentlichen Entwickler unterschiedliche Personen sind. Systemvisionen sollen von denjenigen Personen geschrieben werden, die auch die technische Konstruktion übernehmen. Sie sollen nicht als personenunabhängige Spezifikation

5

Erstellung einer Systemvision


5.2


1255

z.B. für eine externe Auftragsvergabe verwendet werden (vgl. dazu unsere Anmerkungen zu Personenunabhängigkeit, S. 549ff.). Für Systemvisionen gilt vielleicht am stärksten das, was wir über die Erstellung von Dokumenten gesagt haben (s. Kapitel 2.4.3): Nicht das fertige Dokument ist das zentrale Ergebnis, sondern sein Erstellungsprozeß, d.h. die Diskussionen, die anhand der Dokumente geführt werden. Denn in der Arbeit mit Visionen soll die kreative Umsetzung von der analysierten Ist-Situation zum angestrebten Anwendungssystem stattfinden. Mit anderen Worten: Die gemeinsame »Vision«, die in den Köpfen des Entwicklerteams entsteht, ist das eigentliche Resultat der Arbeit mit Systemvisionen. Die jeweiligen Dokumente sind vor allem Gedächtnisstützen oder Protokolle des Diskussionsprozesses. Damit ist ihre Bewertung und Fortentwicklung das wesentliche. Bei der Arbeit mit Systemvisionen geben ein Leitbild und seine illustrierenden Metaphern eine Orientierung; sie sind aber keine vollständigen Konstruktionsanweisungen für den Einzelfall. Also sind neben Leitbild und Metaphern Kreativität und eigene »Auslegung« gefordert. Systemvisionen haben als »historische« und eigenständige Dokumente, die wie traditionelle Spezifikationsdokumente als formale Pro-

5

Einsatz einer Systemvision im Entwicklungsprozeß


5.2


1256

grammiervorlage für andere dienen könnten, wenig Bedeutung. Sie sollten daher nicht mit dem Anspruch der Vollständigkeit und der Personenunabhängigkeit geschrieben werden. Da sie vor allem zu Anfang eher Skizzen für das sich herausbildende Verständnis des zukünftigen Systems sind, werden sie meist unter den Gesichtspunkten »schnell erstellbar« und »für die Beteiligten verständlich« erstellt. Dies heißt aber nicht, daß die darin dargestellten Inhalte beliebig sind. Wenn das Team der Meinung ist, daß der Stand der Systemvisionen eine ausreichende Grundlage für den fachlichen Entwurf und die Softwarekonstruktion der modellierten Komponenten liefert, werden Visionen oft zu Entwurfsdokumenten (siehe den folgenden Abschnitt sowie die detaillierte Besprechung der Subtypen von Systemvisionen, S. 635ff.). Grundsätzlich birgt die Arbeit mit nicht-ausführbaren Dokumenten eine Gefahr für Entwickler. Gerade beim Autor-Kritiker-Zyklus müssen die beteiligten Personen die Fähigkeit besitzen, »etwas bei sich bewenden« zu lassen – in schlichten Worten: »Es muß auch einmal genug sein.« Damit soll ausgedrückt werden, daß die Arbeit mit solchen Dokumenten nie zum Selbstzweck und mit einem Anspruch auf Perfektion und Vollständigkeit angegangen werden darf. Dies gilt auch für Systemvisionen.

5

Anzahl der Systemvisionen und zeitlicher Umfang


5.2


1257

Der Arbeitsaufwand um eine Vision zu erstellen, muß immer in Relation zum Erkenntnisgewinn bei der Erstellung und Diskussion gesehen werden. Das Projektteam muß immer wieder die Entscheidung treffen, ob ❑ eine (weitere) Revision der Systemvisionen sinnvoll ist oder ob

z.B. eher zunächst Begriffs- und Klassenhierarchien mit CRCKarten und dann Prototypen gebaut werden sollen, ❑ noch zusätzliche Systemvisionen »in der Breite« geschrieben

werden sollen, die eine sonst noch nicht beschriebene Funktionalität des Zielsystems abdecken. Statt dessen kann es sinnvoller sein, bereits durch Systemvisionen abgedeckte Anteile »in der Tiefe« weiterzuentwickeln, d.h. hin zu einem technischen Entwurf. Diese Entscheidung wird in hohem Maße davon abhängen, wie das jeweilige Projekt einzuschätzen ist. Wobei es meist sinnvoll ist, die verschiedenen Dokumenttypen im Wechsel zu bearbeiten. Systemvisionen dienen primär dem Entwicklungsprozeß und den daran beteiligten Personen, d.h., sie werden kontinuierlich fortgeschrieben, revidiert oder verworfen. Zur Unterstützung dieses Diskussionsprozesses hat es sich meist als sinnvoll erwiesen, einfache Demonstrationsprototypen zu erstellen.

5


5.2


Die Visionen müssen untereinander und mit den anderen Dokumenten konsistent sein. In einem Reviewprozeß muß geprüft werden, ob die in den Szenarios beschriebenen Aufgaben, die durch das künftige System unterstützt werden sollen, auch vollständig in Visionen modelliert worden sind. Zusätzlich muß die fachliche Terminologie zwischen Visionen und Glossar stimmig sein, und schließlich müssen die zu unterstützenden Aufgaben sowohl in ihren Abläufen als auch auf der Ebene der einzelnen Komponenten modelliert sein. Erst dann kann davon ausgegangen werden, daß sich Systemvisionen ausreichend stabilisiert haben. Damit legen wir bereits in den Systemvisionen tendenziell, aber doch konkret fest, wie das System durch Werkzeuge, Materialien und Automaten zu gestalten ist. Hier werden schon die fachlichen Begriffe verwendet, die dann im Begriffsmodell in Hierarchien angeordnet durch ein Klassenmodell realisiert werden. Diesen Zusammenhang haben wir ja mit unserer Forderung nach Strukturähnlichkeit festgelegt (s. S. 126). Eine wichtige Entscheidung ist, welches Visionsdokument so ausgereift ist, daß es als Entwurfsdokument übernommen werden kann. Dazu müssen zwei Voraussetzungen gegeben sein: Die Visionen müssen projektintern konsoldiert und evaluiert sein und sie müssen kompatibel zum Leitbild des Gesamtsystems sein. Der Konsolidierung

5

1258 Zusammenhang mit anderen Dokumenttypen


5.2


1259

innerhalb des Projektes wird durch entsprechende Autor-KritikerZyklen sichergestellt. Die Stimmigkeit des Gesamtsystems muß in einem projektübergreifenden Reviewprozeß sichergestellt werden. An dieser Abstimmung sollten sowohl Vertreter der Architekturgruppe als auch Zuständige für den Styleguide beteiligt sein. Denn hier werden sowohl Fragen der Architektur als auch der Handhabung und Präsentation angesprochen (vgl. Kapitel 2.5.2). Die unterschiedlichen Arten von Systemvisionen können in andere Dokumente überführt werden. Damit bilden sie die Grundlage für den weiteren Entwicklungs- und Dokumentationsprozeß: ❑ Besonders die Werkzeug- und Automatenvisionen sind im

Rahmen der Qualitätssicherung (Revision) Ausgangspunkt für die Abnahme eines eingesetzten Systems. ❑ Visionen lassen sich sinnvoll für die Vorbereitung und Bewer-

tung von fachlichen Tests einsetzen, da sie den intendierten Gebrauch und die erwünschten Ergebnisse beschreiben. ❑ Abgestimmte Visionen sind eine sinnvolle Form der System-

beschreibung. Denn das zukünftige System sollte ja in Funktionalität und Gestaltung den fachlichen Visionen entsprechen.

5


5.2


1260

❑ Neben den Szenarios und Glossareinträgen liefern Systemvi-

sionen die fachliche Substanz, aus der die Begriffs- und Klassenmodelle des technischen Entwurfs gewonnen werden. ❑ Wir können Szenarios und Visionen zusammen mit Teilen des

Glossars verwenden, wenn wir ein anwendungsfachliches Entwurfsdokument im »klassischen Sinne« vorlegen wollen. Im Laufe der verschiedenen Rückkopplungszyklen entwickeln sich die Visionen also von Skizzen und Protokollen zu Entwicklungsdokumenten, die abgestimmt und verbindlich sind und auf die sich die technischen Entwurfsdokumente konsistent beziehen. Die jeweiligen Subtypen von Systemvisionen werden nach Bedarf angefertigt, um in Autor-Kritiker-Zyklen den Diskussionsprozeß über fachliche und technische Gestaltungsprozesse zu dokumentieren und voranzutreiben. Systemvisionen werden immer mit dem Blick auf die möglichen Entwurfsmetaphern innerhalb des Leitbildes entwickelt. Wir diskutieren also dabei, welche zukünftigen Komponenten als Werkzeuge, Materialien oder Automaten gestaltet werden sollen. Abbildung 5-23 zeigt eine Hierarchie von Systemvisionstypen die sich aus unseren Projekterfahrungen gebildet hat. Die Blätter der Hierarchie bilden die Obermenge der tatsächlich im einzelnen Projekt eingesetzten Systemvisionen.

5

Subtypen von Systemvisionen


5.2


1261 Abb. 5-23

Vision

Hierarchie von Systemvisionen

Gesamtvision

Überblicksvision Einbettungsvision

Ablaufvision

Fachliche Ablaufvision

Komponentenvision

Werkzeugvision

Technische Ablaufvision

Automatenvision Materialvision

Handhabungsvision

In den folgenden Abschnitten diskutieren wir die einzelnen Visionsarten jeweils mit Bezug auf die leitenden Fragestellungen. Wie der Name schon sagt, geben Gesamtvisionen einen Gesamteindruck des zukünftigen Systems. Sie tun dies auf der fachlichen Ebene in Überblicksvisionen und auf technischer Ebene in Einbettungsvisionen. Während in Überblicksvisionen die zukünftigen Aufgaben und

5

Gesamtvisionen


5.2


1262

ihre Unterstützung durch das neue System beschrieben werden, betrachten Einbettungsvisionen das neue System als Teil eines bereits bestehenden informationstechnischen Kontexts. Überblicksvisionen sind sinnvoll, um explizit festzuhalten, in welchem Verhältnis die bisherigen Aufgaben zu den neuen Aufgaben stehen. So ist es möglich, die meist impliziten und teils uneinheitlichen Vorstellungen darüber, wie sich ein neues System in die vorhandenen Arbeitszusammenhänge einbetten soll, explizit und damit diskutierbar zu machen. Folgende Aspekte werden behandelt:

Überblicksvisionen

❑ Welche bisherigen Aufgaben werden vom zukünftigen System

unterstützt? ❑ Welche bisherigen Aufgaben werden nicht unterstützt? ❑ Welche neuen Aufgaben kommen dazu? ❑ Welche bisherigen Aufgaben fallen weg?

Aus Überblicksvisionen lassen sich nicht nur wertvolle Hinweise für die Gestaltung des einzelnen Arbeitsplatzes, sondern auch für die Kooperation verschiedener Arbeitsplätze gewinnen. Das Projektteam sollte sicherstellen, daß Überblicksvisionen sowohl vom Entwickler- als auch vom Anwendermanagement disku-

5


5.2


1263

tiert werden. Nur so lassen sich unliebsame Überraschungen bei der Einführung von Pilotsystemen oder dem fertigen Anwendungssystem in Grenzen halten. Überblicksvisionen sind weder eine Aufgabe, die an die Projektleitung oder das Management delegiert werden sollte, noch sind sie ein Ersatz für den Projektvertrag, in dem die Aufgaben des Projektes beschrieben werden. Einen Anhaltspunkt bei der Erstellung von Überblicksvisionen erhalten wir durch die Überblicksszenarios, die die relevanten Aufgaben des betrachteten Anwendungsbereichs beschreiben. Der Zusammenhang zwischen Überblicksszenarios und -visionen ist jedoch logisch und nicht zeitlich zu verstehen. Innerhalb einer evolutionären Vorgehensweise steht erst mit der Einführung und Benutzung des neuen Systems fest, welche Aufgaben durch softwaretechnisch modellierte Werkzeuge, Automaten und Materialien tatsächlich unterstützt werden. Deshalb liefert der Vergleich zwischen Überblicksszenarios und -visionen immer nur einen Eindruck über die Zusammenhänge aber nicht das tatsächliche Bild.

5


5.2


Ziel des Pausenplansystems ist, den Pausenplaner bei der effizienten und gerechten Zuteilung von Pausenaufsichtspflichten zu unterstützen. Darüber hinaus soll ein Lehrer die Möglichkeit haben, sich selbst einen Überblick über zu betreuende Pausen zu verschaffen sowie die potentiellen Pausenaufsichtszeiten zu verwalten. Im einzelnen kann der Pausenplaner mit dem Pausenplansystem Wochenpläne für Pausenaufsichten und Pausenstatistiken erstellen. Da die Lehrer sich über ihre Pausenaufsichten selbst unterrichten können, besteht keine unmittelbare Notwendigkeit mehr, den aktuellen Pausenplan ausgedruckt vorzuhalten.

In Einbettungsvisionen wird die technische Umgebung einer neuen Systemkomponente beschrieben – etwa das Netz oder der Hostanschluß. Im Mittelpunkt steht die Frage, wie sich die neue Komponente aus der Außensicht darstellt, d.h., was an der Schnittstelle dieser Komponente für andere Systemkomponenten und aus der Sicht anderer Gruppen, etwa für die Datenbankadministration, zu sehen ist. Dazu kommen Anforderungen an diejenigen externen Komponenten, die Dienstleistungen (Services) anbieten. Auf diese Weise können wir prüfen, welche Dienstleistungen von den Anbietern bereitgestellt werden müssen, damit die neue Komponente in ihrer Umgebung funktionstüchtig ist.

5

1264 Überblicksvision für das Pausenplanbeispiel

Einbettungsvisionen


5.2


1265

Neben den Protokollen und Formaten soll in diesen Beschreibungen deutlich werden, wie sich die Schnittstellen in Funktionen, Prozeduren und Prädikaten darstellen lassen (s. Kapitel 2.1.4, S. 27f.). Hierhin gehört auch die Behandlung von Ausnahmesituationen. Wir dokumentieren dazu, welche Protokolle und welche Vor- und Nachbedingungen im Zusammenspiel der einzelnen Komponenten eingehalten werden müssen (s. Kapitel 2.1.10). Wenn die anderen technischen Visionen bereits detailliert sind, ist eine Einbettungsvision eher eine Zusammenstellung von vorhandenen Komponentenvisionen. Sie ist auch dann wichtig, wenn mit anderen Entwicklergruppen über die Einbettung der neuen Komponente diskutiert wird. Erfahrungen zeigen, daß ein Entwicklungsteam erst bei der Formulierung von Einbettungsvisionen darüber diskutiert, welche Dienstleistungen in welcher Form vorhanden sind, und welche zusätzlichen Forderungen an »externe« Komponenten aus dem Projekt heraus resultieren.

5


5.2


1266

Das Pausenplansystem soll mit Hilfe des Rahmenwerks Microsoft Foundation Classes (MFC) realisiert werden. Es wird zusätzlich auf dem Betriebssystem Windows NT oder Windows 95 aufsetzen. Das Pausenplansystem wird zunächst als Einbenutzersystem für den Pausenplaner konzipiert, um darauf aufbauend ein Mehrbenutzersystem zu bauen das sowohl vom Pausenplaner als auch von Lehrern verwendet werden kann. Mehrere Benutzer können dann gleichzeitig mit dem System arbeiten. Die Verteilung soll dabei zunächst durch das DCOMObjektmodell technisch realisiert werden.

Einbettungsvision

Die Einbettungsvision greift vor allem die Entwurfsentscheidungen für technische Rahmenwerke auf hohem Abstraktionsniveau auf. Vor allem wird deutlich, daß für den geplanten Ausbau vom Ein- zum Mehrbenutzerbetrieb schon Überlegungen über die technische Realisierung angestellt werden müssen.

Kommentar

Ablaufvisionen dokumentieren das Ablaufverhalten des zukünftigen Systems, also seine Dynamik. Dies kann sich jeweils auf die fachliche und die technische Ebene konzentrieren – wie bei den fachlichen und den softwaretechnischen Ablaufvisionen. Wenn beide Aspekte zusammenkommen und der Umgang mit dem System im Vordergrund steht, sprechen wir von Handhabungsvisionen.

Ablaufvisionen

Fachliche Ablaufvisionen werden meist zu einem sehr frühen Zeitpunkt der Visionsentwicklung geschrieben oder, besser gesagt, durchgespielt. Sie sollen den Entwicklern helfen, sich anhand der erkannten fachlichen Aufgaben eine Vorstellung darüber zu verschaffen, wie die

Fachliche Ablaufvisionen

5

für das Pausenplanbeispiel


5.2


1267

Abläufe zur Erledigung einer Aufgabe in Zukunft aussehen. Da die Entwickler zunächst selten konkrete Vorstellungen über die Zuordnung der fachlichen Gegenstände zu den Modellelementen wie Werkzeuge, Automaten und Materialien haben, werden die fachlichen Abläufe vorrangig mit Fachbegriffen beschrieben. Auf diese Weise soll die Dynamik deutlich werden, ohne daß gleich die konkreten Entwurfskomponenten festgelegt werden. Zentral bei diesem Visionstyp ist demnach die Vorstellung der Entwickler, wie fachliche Gegenstände zur Erledigung einer Aufgabenstellung eingesetzt werden und welche Ergebnisse entstehen. Auch hier liefern Überblicksszenarien Anhaltspunkte über die möglichen fachlichen Ablaufvisionen. Fachliche Ablaufvisionen sind vielfältig einzusetzen: ❑ Zusammen mit einer Überblicksvision ergibt sich ein Bild der

Dynamik des Gesamtsystems, das eine gute Grundlage für den Entwurf von Komponenten ist, die die verschiedenen Aufgaben technisch unterstützen sollen. ❑ Sie sind auch eine gute Vorlage für die Benutzungsdokumenta-

tion unter dem Gesichtspunkt: Wie gehe ich mit dem System bei der Erledigung typischer Aufgaben um.

5


5.2


1268

❑ Sie ergänzen technische Ablaufvisionen und bilden zusammen

mit diesen die Grundlage für die Entwurfsdokumente, z.B. für das Begriffsmodell und für den fachlichen Klassenentwurf, da hier Komponenten aufgrund ihrer nach außen erkennbaren Funktionalität beschrieben werden. ❑ Sie helfen Handhabungsvisionen zu erstellen. Eine Veränderung des Lehrkörpers durch das Sekretariat hat zur Folge, daß der (vom Zustand des Lehrkörpers abhängige) Pausenplan auf seine Konsistenz geprüft werden muß. Diese Prüfung wird vom Pausenplanersteller vorgenommen. Er erkennt an der veränderten Farbe des Pausenplansymbols, daß der aktuelle Pausenplan geprüft werden muß.

Fachliche Ablaufvision Bearbeiten des Lehrkörpers durch das Sekretariat

Anhand des Materialstempels kann er sehen, welcher Benutzer den Lehrkörper bearbeitet hat und zu welchem Zeitpunkt die Bearbeitung erfolgte. Sobald er die Überprüfung des Pausenplans abgeschlossen hat (siehe Handhabungsvision Neuen Pausenplan bearbeiten, S. 632) wird das Symbol des Pausenplanes wieder in seiner normalen Farbe angezeigt. Die neue Darstellung signalisiert dem Sekretariatsmitarbeiter, daß der Pausenplanersteller auf die Veränderung des Lehrkörpers reagiert hat. Er kann auch anhand des Materialstempels erkennen, wer den Lehrkörper zuletzt sondiert hat und zu welchem Zeitpunkt die Betrachtung erfolgte.

5


5.2


Technische Ablaufvisionen beschreiben wie Zustands-Aktionsfolgen von Werkzeugen, Automaten und Materialien zusammenspielen. Sie behandeln damit den Übergang von den fachlichen Gegenständen zu den Komponenten des Entwurfs. Dabei sollte aber nicht voreilig auf einen bereits festliegenden Algorithmus oder ein fertiges Programm zurückgegriffen werden. Wichtig ist hier, wie eine fachliche Aufgabe im Zusammenspiel von Automaten und Werkzeugen mit Materialien und Behältern erledigt wird. Diese Frage ist deshalb so wichtig, damit über Materialien im objektorientierten Sinne und nicht zu früh über Hostabfragen oder Datenbankformate nachgedacht wird. Technische Ablaufvisionen haben folgende charakteristische Merkmale:

1269 Technische Ablaufvisionen

❑ Die Beschreibung ist an einer fachlichen Aufgabe orientiert. ❑ Die betroffenen Komponenten werden in ihrem Zusammen-

spiel benannt. Der Materialfluß zwischen den bearbeitenden Komponenten wird innerhalb einer fachlichen Aufgabe deutlich. ❑ Es werden logische, nicht zeitliche Abhängigkeiten gezeigt. ❑ Der Detaillierungsgrad entspricht dem Anliegen, eine fachliche

Komponente in ihrem Zusammenspiel zu verstehen.

5


5.2


1270

❑ Die Beschreibung umfaßt keine komponenteninternen Algo-

rithmen. Das »Innenverhalten« von Komponenten ist auf der Ebene der technischen Abläufe nicht von Interesse. Das Innenverhalten von Automaten wird z.B. als Teil einer Automatenvision beschrieben. Als Darstellungsmittel für technische Ablaufvisionen können z.B. Interaktionsdiagramme gut verwendet werden. Handhabungsvisionen beschreiben das Aussehen und die Verwendung des künftigen Anwendungssystems. Sie haben also einen statischen und einen dynamischen Aspekt. Die Kernfrage ist: Wie werden die bisherigen und die neuen Aufgaben vom System unterstützt? Die Antwort auf diese Frage sollte immer eine Beschreibung sein, in der eine Aufgabe mit ihren einzelnen Tätigkeiten erledigt wird, wozu dann Werkzeuge, Automaten und Materialien benutzt werden. Ausgangspunkt der Beschreibung ist das Benutzungsmodell, d.h. die Aktionen des Benutzers, die verwendeten sichtbaren Komponenten und die darauf folgende Reaktion des Systems. Handhabungsvisionen sind dann sinnvoll, wenn die betrachteten Aufgaben zukünftig im wesentlichen mit Hilfe (oder zumindest ausgehend) von Werkzeugen erledigt werden sollen. Obwohl es im Einzelfall Abgrenzungsschwierigkeiten geben kann, wird meist klar sein, ob

5

Handhabungsvisionen


5.2


1271

eine Aufgabe zukünftig als Routinetätigkeit an einen Automaten übertragen werden soll oder ob sie vom Benutzer mit Hilfe von Werkzeugen erledigt wird. Startet der Benutzer im wesentlichen einen Automaten, dann ist eine fachliche oder technische Ablaufvision besser zur Modellierung der relevanten Zusammenhänge geeignet. In einer Handhabungsvision stehen zunächst diejenigen Aufgaben im Mittelpunkt, die in Szenarios beschrieben worden sind und die auch zukünftig durch das System unterstützt werden sollen. Denn diese Aufgaben sind zum einen gut beschrieben, zum anderen sind die Anwender mit ihnen vertraut und werden in diesem Bereich das neue System besonders kritisch unter die Lupe nehmen. Als Ergänzung zu fachlichen und technischen Ablaufvisionen betonen Handhabungsvisionen die Außenansicht eines Werkzeugs. Besonderer Augenmerk ist hier auf solche Aktivitäten und Handlungen zu richten, die bisher bereits durch Informationstechnologie unterstützt werden. Eine Gefahr ist die unreflektierte Übernahme von Handlungssequenzen, die nicht aus einer fachlichen Notwendigkeit resultieren, sondern auf die konventionelle Programmentwicklung mit ihrem (Hierarchical-) Input-Process-Output-Modell zurückzuführen sind. Problematisch sind auch »pseudofachliche« Konzepte und Begriffe, die sich erst aus der Verwendung vorhandener Anwendungssysteme gebildet haben. Dazu zählen z.B. die sogenannten Experten-

5


5.2


1272

codes oder Short-Cuts zum schnellen Wechsel von Bildschirmmasken. Auch deren Wurzeln liegen bei der konventionellen Konstruktionsmethodik, sind aber bisweilen nicht so leicht zu entdecken wie die Sequenzen von Masken- und Menüfolgen. Wir haben in Projekten erlebt, daß fachliche Begriffe soweit »verstümmelt« waren, wie dies durch das alte Anwendungssystem erzwungen wurde. Mit Vorsicht sind völlig neue Aufgaben zu beschreiben. Die Beteiligten sollten sich hier besonders klar darüber sein, daß dies immer nur eine hypothetische Annahme über die Zukunft ist, die sich dann in der Realität mehr oder minder gut umsetzen und wiederfinden läßt. Deshalb dürfen Visionen über neue Arbeitsabläufe oder Aufgaben niemals normativen (d.h. vorschreibenden) Charakter annehmen. Hier wird besonders deutlich, was wir mit Visionen als Entwurfsskizzen gemeint haben. Denn die Unterstützung neuer Aufgaben ist ja zunächst fiktiv und erhält erst auf dem Weg über Prototypen und Pilotsysteme eine reale Basis. Die Entwickler drücken in diesen Handhabungsvisionen ihr aktuelles Verständnis der Entwicklungs- und Anwendungssituation aus. Dieses Verständnis wird im Prototyping-Prozeß erweitert und vertieft. Der Zusammenhang zwischen Systemvision und einem ersten Prototyp muß deshalb gewährleistet sein, um Systemvisionen bruchlos weiterentwickeln zu können.

5


5.2


1273

Um einen neuen Pausenplan zu erstellen, zieht der Pausenplanersteller mit der Maus einen neuen Pausenplan vom Pausenplanstapel des schwarzen Brettes und läßt ihn auf eine freie Stelle des Schreibtischs fallen. Es erscheint ein Symbol mit der Bezeichnung »neuer Pausenplan«. Die Bezeichnung des Pausenplans kann nun geändert werden, indem der Pausenplanersteller die Schrift unterhalb des Symbols mit der Maus anklickt und eine andere Bezeichnung einträgt. Um die Pausen der Schule in den Pausenplan einzutragen, startet der Pausenplanersteller die Bearbeitung des neuen Pausenplans mit dem Pausenlisten-Bearbeiter-Werkzeug, indem er das Symbol des Pausenplans auf das Werkzeugsymbol zieht. Die Bearbeitung kann auch gestartet werden, indem er das Werkzeug auf das Material zieht (s. Werkzeugvision Pausenlisten-Bearbeiter, S. 633).

Handhabungsvision

Bevor der Pausenplanersteller mit der Bearbeitung des neuen Pausenplanes beginnen kann, muß er den Pausenplan zunächst mit einem Lehrkörper am schwarzen Brett verknüpfen. Dazu zieht er das Lehrkörpersymbol mittels der Maus auf des Pausenplansymbol. Es erscheint eine Linie zwischen dem Symbol des Pausenplanes und dem Symbol des Lehrkörpers.

Handhabungsvision

Erstellen eines neuen Pausenplans

Neuen Pausenplan bearbeiten

Der Pausenplanersteller startet nun die Bearbeitung des Materials Pausenplan mit dem Pausenplaner-Werkzeug. Dazu zieht er das Symbol des Pausenplanes auf das Symbol des Pausenplaners. Der Lehrkörper und der noch leere Pausenplan werden daraufhin im Werkzeug dargestellt.

5


5.2


1274

Sowohl Werkzeuge als auch Materialien und Automaten sind Entwurfskomponenten, die sich durch eine bestimmte Funktionalität und durch Umgangsformen auszeichnen. Dies wird in den entsprechenden Komponentenvisionen losgelöst von spezifischen Aufgaben »als solches« beschrieben.

Komponentenvisionen

Bei Werkzeugvisionen steht die Frage im Vordergrund, welche Funktionalität das zu entwerfende Werkzeug haben soll. Diese Frage kann deutlich von der Frage unterschieden werden, wie sich eine Funktionalität an der Oberfläche präsentiert. Aus der Funktionalität eines Werkzeugs lassen sich Anforderungen an die Materialien formulieren, die das Werkzeug bearbeiten soll. Ergänzend zur Beschreibung der Funktionalität werden Oberflächen skizziert. Da Werkzeugvisionen häufig in einem Stadium geschrieben werden, wo das zukünftige System noch nicht prototypisch durchkonstruiert ist, wird dieser Dokumenttyp oftmals geändert. Dies hat Konsequenzen für die Detaillierung der Ausarbeitung und die erforderliche Werkzeugunterstützung. Bisher sind Bildschirmabzüge (Screen Shots) von GUI-Buildern nur mit einigem Aufwand in Dokumente einzubauen. In einigen Projekten hat sich bewährt, häufig vorkommende Oberflächenelemente in einem Grafikeditor bereitzustellen, um so die Werkzeugvisionen mit einem Minimum an Aufwand erstellen und

Werkzeugvisionen

5


5.2


1275

revidieren zu können. Werkzeugvisionen stellen das betrachtete Arbeitsmittel »an sich« dar, d.h., hier wird von der Einbettung in fachliche Zusammenhänge weitgehend abstrahiert. Konzeptionell gesehen, werden hier alle Umgangsformen zusammengestellt, die in den verschiedenen fachlichen Ablaufvisionen für ein Werkzeug beschrieben sind. Wenn wir die Umgangsformen »um ein Werkzeug gruppieren«, nehmen wir die Sequenzen aus den Arbeitsabläufen heraus. Hier schaffen wir also ein Gegengewicht zu den an Handlungssequenzen orientierten Ablaufvisionen. Am deutlichsten scheint uns der Gewinn von Werkzeugvisionen als Gegenstück zu Handhabungsvisionen zu sein. Durch die einseitige Konzentration auf Handhabungsvisionen entstehen häufig maskenorientierte, in Sequenzen entworfene Systeme. Um dieser Kraft entgegenzuwirken, ergänzen wir Ablaufvisionen durch zugehörige Werkzeugvisionen. Werkzeugvisionen können in einem fortgeschrittenen Stadium zu dem Teil der Benutzungsdokumentation werden, in denen die einzelnen Merkmale eines Systems »Punkt für Punkt« beschrieben werden (also im sogenannten Handbuch).

5


5.2


Mit dem Pausenlisten-Bearbeiter-Werkzeug pflegt der Pausenplanersteller die Pausenliste bestehender Pausenpläne. Pausen können zur Pausenliste hinzugefügt oder entfernt werden. Der Zeitraum, die Aufsichtsorte und die Anzahl der Pausenbeaufsichtiger einer Pause können verändert werden. Die Pausenliste wird als Teil des Materials Pausenplan verwendet.

1276 Werkzeugvision PausenlistenBearbeiter

Eine Liste aller Pausen wird auf der linken Seite des Fensters gezeigt. Die Zeiträume der Pausen werden temporär geordnet aufgelistet. Der Pausenplanersteller kann in der Liste eine Pause selektieren. Dadurch werden Wochentag, Zeitraum und eine Liste der Pausenaufsichtsorte der selektierten Pause auf der rechten Seite des Fensters gezeigt. Die Liste der Pausenaufsichtsorte enthält neben den Namen derselben ebenso die Anzahl der Pausenbeaufsichtiger. Selektiert der Pausenplanersteller einen Ort aus dieser Liste, so wird die Anzahl der Pausenbeaufsichtiger in einem Textfeld angezeigt und kann dort verändert werden.

5


5.2


1277 Abb. 5-24 Oberflächenprototyp für das PausenlistenBearbeiter-Werkzeug

5


5.2


1278

Aktionen des Pausenplanerstellers: ❑ Pause zur Pausenliste hinzufügen: Der Pausenplanersteller klickt auf den »Hinzufügen«-Knopf oder wählt den Menüpunkt »Pause/Hinzufügen«. In der Pausenliste erscheint daraufhin eine neue Pause mit der Darstellung »neue Pause«. Diese ist sofort selektiert und der Pausenplanersteller kann jetzt, im rechten Teil des Fensters, Wochentag und Anfangs- bzw. Endzeitpunkt mit Stunde und Minute eingeben. Daraufhin ändert sich die Darstellung der Pause in der Pausenliste. Als Voreinstellung sind alle Pausenaufsichtsorte der Schule in der Ortsliste vermerkt. Zu jedem Aufsichtsort gilt die voreingestellte Anzahl der Pausenbeaufsichtiger. Der Pausenplanersteller kann nun die Pausenaufsichtsorte, die in dieser Pause nicht beaufsichtigt werden müssen, aus der Liste entfernen (siehe unten »Pausenaufsichtsort einer Pause entfernen«). Er kann auch die Anzahl der Pausenbeaufsichtiger pro Pausenort ändern (siehe unten »Anzahl der Pausenbeaufsichtiger an einem Pausenaufsichtsort ändern«). ❑ Pause aus der Pausenliste entfernen: Um eine Pause aus der Pausenliste zu entfernen, muß der Pausenplanersteller in der Pausenliste eine Pause selektieren und dann auf den »Entfernen«-Knopf klicken oder den Menüpunkt »Pause/Entfernen« wählen. ❑ Zeitraum einer Pause verändern: Um den Zeitraum einer Pause zu verändern, muß der Pausenplanersteller in der Pausenliste die gewünschte Pause selektieren. Daraufhin wird der Zeitraum der ausgewählten Pause

5


5.2


1279

angezeigt. Der Pausenplanersteller kann nun den Wochentag in der Auswahlbox verändern. Anfangs- und Endzeitpunkt der Pause können in den Textfeldern verändert werden. Die Änderungen erscheinen sofort in der Pausenliste. ❑ Pausenaufsichtsorte eines Pausenplans werden mit dem AufsichtsorteBearbeiter-Werkzeug bearbeitet. ❑ Um das Werkzeug zu starten, muß der Pausenplanersteller auf den »Bearbeiten«-Knopf der Pausenaufsichtsorte klicken oder im Menü »Pause/Aufsichtsorte bearbeiten« wählen. ❑ Pausenaufsichtsort einer Pause hinzufügen: Um einen Pausenaufsichtsort zu einer Pause hinzuzufügen, muß der Pausenplanersteller in der Pausenliste die gewünschte Pause selektieren. Danach wählt er im Menü »Pause/Aufsichtsort hinzufügen«. Es erscheint ein Untermenü, welches neben den einzelnen Pausenorten auch einen Menüpunkt »alle Orte« enthält. Durch die Auswahl eines Menüpunktes kann er der Pause einen oder alle Aufsichtsorte hinzufügen. Das Hinzufügen von schon zugeordneten Pausenaufsichtsorten bleibt wirkungslos. ❑ Pausenaufsichtsort einer Pause entfernen: Der Pausenplanersteller selektiert in der Pausenliste die gewünschte Pause. Daraufhin werden alle Pausenaufsichtsorte angezeigt. Der Pausenplanersteller selektiert in der Liste den zu entfernenden Ort und klickt auf den »Entfernen«-Knopf der Pausenaufsichtsorte oder wählt im Menü »Pause/Aufsichtsort entfernen«. Der Pausenaufsichtsort wird gelöscht.

5


5.2


1280

❑ Anzahl der Pausenbeaufsichtiger an einem Pausenaufsichtsort ändern: Der Pausenplanersteller selektiert in der Pausenliste die gewünschte Pause. Daraufhin werden alle Pausenaufsichtsorte angezeigt. Der Pausenplanersteller selektiert in der Liste den gewünschten Ort und kann nun die Anzahl der Pausenbeaufsichtiger im Textfeld ändern. ❑ Bearbeitung beenden: Der Pausenplanersteller klickt auf den Systemknopf für das Beenden oder wählt den Menüpunkt »Pause/Bearbeitung beenden«.

Bei Materialvisionen steht die Frage im Vordergrund, wie die fachliche Funktionalität von Arbeitsgegenständen in Klassen beschrieben werden kann. Den Zwischenschritt modellieren wir angelehnt an das Konzept der abstrakten Datentypen Dazu betrachten wir ein einzelnes Material oder eine Materialgruppe. Dabei ist klar, daß jedes Material nur mit Hilfe von Werkzeugen oder Automaten bearbeitet oder dargestellt werden kann. Die Materialvisionen arbeiten vor allem die fachlichen Aspekte eines Materials heraus. Hier werden beispielsweise folgende Fragen beantwortet:

5

Materialvisionen


5.2


1281

❑ Welche fachlichen Aspekte deckt ein Material ab? ❑ Gibt es Festlegungen für Form und Inhalt des Materials? ❑ Welchen Konsistenzbedingungen muß das Material genügen? ❑ Steht das Material in inhaltlicher Verbindung zu anderen

Materialien? Eine besondere Rolle unter den Materialvisionen nehmen Visionen über Behälter ein. Fachliche Behälter sind oft mehr als eine Sammlung von gleichartigen Materialien und müssen daher gesondert beschrieben werden. Fachliche Behälter zeichnen sich durch komplexe Umgangsformen aus. Hier müssen wir z.B. die Entwurfsentscheidung treffen, ob eine Sammlung von Materialien durch einen Behälter mit komplexer Funktionalität bearbeitet wird oder ob hier ein Werkzeug oder Automat eingesetzt wird. Der Lehrkörper ist ein Behälter für alle Lehrerkarten. Zur Standardfunktionalität von Behältern gehört, daß man über ihre Elemente iterieren kann. Dazu muß ein Behälter keine Informationen über die in ihm enthaltenen Elemente haben. Der Lehrkörper kann so realisiert werden, jedoch muß dann z.B. eine spezielle Funktionalität, etwa das Sortieren von Lehrern nach der Menge bereits beaufsichtigter Pausen, in einer benutzenden Komponente (Werkzeug, Automat) implemen-

5


5.2


1282

tiert werden. Alternativ kann der Lehrkörper als fachlicher Behälter implementiert werden, der selbst z.B. verschiedene Sortierungen und Inhaltsverzeichnisse vorhält. Die Entscheidung darüber, welche Entwurfskomponente dafür zuständig gemacht wird, läßt sich aber nicht ohne Berücksichtigung des weiteren Kontextes vornehmen. Eine Pause bezieht sich auf einen wöchentlich wiederkehrenden Zeitraum. Sie ist dadurch gekennzeichnet, daß dieser Zeitraum beaufsichtigt werden muß. An einer Schule kann es mehrere Pausenaufsichtsorte geben. Es existieren beispielsweise verschiedene Pausenhöfe, beziehungsweise es muß sowohl innerhalb als auch außerhalb des Schulgebäudes Aufsicht geführt werden. Die Beaufsichtigung eines Pausenaufsichtsortes erfordert einen oder mehrere Lehrer. Im Krankheitsfall einer Aufsichtsperson muß eine Vertretung eingeteilt sein. Diese übernimmt dann die Beaufsichtigung der Pause. Die Mindestanzahl von Aufsichtspersonen kann durch eine untere Grenze festgelegt werden. Diese ist mit der Anzahl der eingeteilten Vertretungen identisch.

Materialvision Pause

Eine Pausenaufsicht wird eingeteilt, indem ein Aufsichtsort einer Pause mit Lehrern belegt wird. ❑ Belegung einer Pause mit einem Lehrer (Pausenaufsicht oder Vertretung der Pausenaufsicht): Im Falle der Belegung einer Pause mit einem Lehrer, wird der Lehrer bei der Pause mit dem gewünschten Aufsichtsort eingetragen.

5


5.2


1283

❑ Da jede Schule eine eigene Pauseneinteilung vornimmt, muß der Zeitraum, der Aufsichtsort und die Mindestanzahl von Aufsichtspersonen einer Pause bearbeitet werden können. Diese Werte sollen auch nachträglich verändert werden können. ❑ Feststellen eines Konfliktes: Durch die Belegung einer Pause kann ein Belegungskonflikt entstehen, wenn sich die Pausenzeit mit einem Ausschlußzeitraum des Lehrers überschneidet. An der Pause wird dieser Konflikt festgehalten.

Automatenvisionen haben vom Aufbau her viel Ähnlichkeit mit Werkzeugvisionen. Auch hier werden fachliche Funktionalität und Anforderungen an Materialien beschrieben. Während der äußeren Präsentation naturgemäß nur wenig Bedeutung zukommt, liegt der Schwerpunkt auf den fachlichen internen Abläufen und dem Zusammenspiel mit weiteren Systemkomponenten. Bei der Beschreibung der durch einen Automaten realisierten Routinen sollte nicht auf programmiersprachliche Konzepte und Begriffe, sondern vorrangig auf die fachlichen Schritte abgehoben werden. Dabei ist es wichtig, den Automaten nicht als »Einknopfautomat« zu konzipieren, der nur eine einzige Dienstleistung anbietet. Prüfende und einstellende Operationen sollten ebenso bedacht werden wie die Zerlegung eines fachlichen Gesamtablaufs in einzelne Teilabläufe, die als eigenständige wiederholbare Dienstleistungen angeboten werden.

5

Automatenvisionen


5.2


Grundsätzlich halten wir fest, daß sich die Zweiteilung in fachliche und softwaretechnisch orientierte Visionen bewährt hat. Diese Aufteilung ermöglicht eine Konzentration im Diskussions- und Entwicklungsprozeß, wobei der jeweils andere Gesichtspunkt aber nicht völlig ausgeblendet wird. Die weitere Differenzierung in Überblicks- und Handhabungsvision einerseits und Einbettungs- und Komponentenvision andererseits hilft, die unterschiedlichen Betrachtungsweisen zu berücksichtigen. So wird ein System sowohl im Überblick als auch detailliert in seinen einzelnen Werkzeugen, Automaten und Materialien beschrieben. Ebenso werden vorrangig fachliche Aspekte und die daraus resultierenden softwaretechnischen Konsequenzen betrachtet. Weiterhin wird untersucht, wie sich ein System in seine Umgebung einpassen soll. Schließlich werden die Beschreibungen der Statik eines Systems in Komponentenvisionen komplettiert durch Beschreibungen der Dynamik in Ablaufvisionen.

5

1284 Fazit


5.2


1285

5.2.4 Prototypen Prototyp: Ein Prototyp ist ein ablauffähiges Modell ausgewählter Aspekte des zukünftigen Anwendungssystems. Prototypen sind eine Diskussions- und Entscheidungsbasis für Entwickler und Anwender. Sie dienen ihnen zum Experimentieren und zum Sammeln von Erfahrungen. Prototypen helfen so, relevante Spezifikations- oder Entwicklungsprobleme zu klären.

Im Softwareentwicklungsprozeß können unterschiedliche Aktivitäten durch die Konstruktion von Prototypen unterstützt werden:

Zweck eines Prototyps

❑ die Projektinitiierung, ❑ die Analyse des Anwendungsbereichs sowie ❑ der Entwurf und die Konstruktion des Anwendungssystems.

Je nach der Beziehung zwischen Prototyp und diesen Aktivitäten unterscheiden wir nach [Floyd 84] die verschiedenen Arten von Prototyping.

5


5.2


1286

Arten des Prototyping:

Exploratives Prototyping wird eingesetzt, wenn die Problemstellung unklar ist. Anforderungen der Benutzenden und des Managements an das Anwendungssystem werden geklärt. Die Entwickler lernen den Anwendungsbereich und die Aufgaben der Benutzer kennen. Experimentelles Prototyping wird angewandt, wenn die technische Umsetzung eines Entwicklungsziels geklärt werden soll. Die Benutzer konkretisieren experimentell ihre Vorstellungen über das Anwendungssystem. Die Entwickler erhalten eine Grundlage für die Einschätzung der Machbarkeit und der Zweckmäßigkeit. Evolutionäres Prototyping ist ein kontinuierliches Verfahren, um ein Anwendungssystem an sich rasch verändernde Randbedingungen anzupassen. Software wird nicht mehr in abgeschlossenen Projekten, sondern in einem kontinuierlichen, evolutionären Prozeß entwickelt.

Komplementär unterscheiden wir verschiedene Arten von Prototypen und damit verbundene Fragestellungen sowie Ziele, Zwecke und deren Beurteilung bei der Entwicklung (s. [Kieback et al. 92]).

5


5.2


1287

Arten von Prototypen: Ein Demonstrationsprototyp unterstützt die Projektinitiierung: Er soll dem Auftraggeber zeigen, wie ein Anwendungssystem prinzipiell aussehen kann. Er soll Entwicklern und Anwendern eine erste Vorstellung von der Handhabung und dem Einsatzkontext geben. Demonstrationsprototypen werden meist vom Management bewertet. Ein funktioneller Prototyp hilft, die Problemstellung zu klären und Entwurfsfragen zu beantworten. Er zeigt Teile der Benutzungsschnittstelle und einen Ausschnitt der Funktionalität. Er besitzt meist bereits die Architektur des Anwendungssystems. Funktionelle Prototypen werden von allen Gruppen bewertet.

Labormuster dienen der Klärung softwaretechnischer Fragen, die sich bei der Entwicklung des Anwendungssystems ergeben. Es realisiert dazu einen Ausschnitt des Implementationsmodells. Diese Art von Prototyp findet sich auch in traditionellen Entwicklungsprojekten. Labormuster werden von den Entwicklern bewertet. Ein Pilotsystem wird im Anwendungsbereich eingesetzt und bewertet. Es ist ein technisch »gereifter« Prototyp. Ein erstes Pilotsystem entspricht oft dem Kernsystem der zukünftigen Anwendung. Es wird evolutionär durch Ausbaustufen ergänzt (s. S. 571ff.). Ein Pilotsystem bietet eine komfortable und sichere Bedienbarkeit und ein Mindestmaß an Benutzungsdokumentation. Bei der Bewertung von Pilotsystemen haben die Benutzer großen Einfluß.

5


5.2


Die Konstruktion eines Prototyps ist jeweils mit einer spezifischen Fragestellung verbunden, die mit Hilfe des Prototyps beantwortet werden soll. Dabei ist es von zentraler Bedeutung, daß diese Fragestellung jeweils vor der Konstruktion des Prototyps klar herausgearbeitet wird. Dadurch wird verhindert, daß nach der Konstruktion der Prototyp nach Gesichtspunkten bewertet wird, für die er nicht entwickelt wurde. Ohne eine festgelegte Fragestellung besteht die Gefahr des »Durchwurstelns«, d.h. beliebige ausführbare Softwarekomponenten werden konstruiert, bei Gefallen werden sie als Erfolg verkauft, bei Nichtgefallen nach dem Muster »es war ja nur ein Prototyp« verworfen. Fragestellungen, die mit der Konstruktion eines Prototyps beantwortet werden sollen, gliedern wir im folgenden nach der Art des zu konstruierenden Prototyps auf:

1288 Inhalte eines Prototyps

Demonstrationsprototypen ❑ Welche Leitbilder und welche Metaphern sollen mit dem Pro-

totyp verdeutlicht werden? ❑ Welche Ausschnitte des noch relativ unbekannten Anwen-

dungsbereichs können ins Anwendungsmodell aufgenommen werden? ❑ Welche grundsätzlichen Umgangsformen soll das zu entwik-

kelnde System bieten?

5


5.2


1289

Funktionelle Prototypen ❑ Welche Problemstellung oder Entwurfsfrage soll mit den

Benutzern geklärt werden? ❑ Welche Aufgaben sollen wie unterstützt werden? ❑ Welche typischen Arbeitsabläufe sollen unterstützt und welche

automatisiert werden? Labormuster ❑ Welche Alternativen gibt es bei der Umsetzung eines techni-

schen Problems? ❑ Wie passen die verschiedenen Implementierungsmöglichkeiten

zur Architektur des Anwendungssystems? ❑ Wie verhält sich das Anwendungssystem gegenüber der einbet-

tenden Systembasis? Pilotsysteme ❑ Wie bewährt sich das Pilotsystem im täglichen Arbeitshan-

deln? ❑ Können die weiteren geplanten Ausbaustufen auf der geschaf-

fenen Grundlage in Angriff genommen werden? ❑ Wie verhält sich das Anwendungssystem im Echtbetrieb?

5


5.2


1290

Abbildung 5-25 bettet die Prototypen in die allgemeinen Dimensionen für Dokumenttypen ein.

Labormuster

Pilotsystem

Abb. 5-25 Prototypen in den

Funktioneller Prototyp

Dimensionen der Dokumentation

Detail

Demonstrationsprototyp Dynamik

Überblick

Statik Fachlich

Technisch

Funktioneller Prototyp und Pilotsystem sind in Abbildung 5-25 eine modifizierte Darstellung, da beide nicht an einem Punkt unseres Schema lokalisiert werden können. Funktionelle Prototypen sind nicht nur fachlich sondern auch technisch relevant. Pilotsysteme sind neben ihrer fachlichen Funktionalität unterschiedlich weit technisch realisiert.

5


5.2


1291

Oberfläche Demonstrationsprototyp

Abb. 5-26

Labormuster

Konzept des T-Prototyps

Systembasis

Neben den hier dargestellten »reinen« Arten von Prototypen werden in der Praxis häufig Mischformen von Prototypen angefertigt. Abbildung 5-26 zeigt dies: Demonstrationsprototypen werden »breit« angelegt, um an der Oberfläche die prinzipielle Handhabung und Präsentation des Anwendungssystems zu verdeutlichen. Labormuster werden »tief« entwickelt, um für die Entwicklerorganisation den Nachweis der technischen Realisierbarkeit zu liefern. Demonstrationsprototypen und Labormuster können in der durch die Graphik angedeuteten »T«-Form verbunden werden, so daß ein Gesamteindruck des Anwendungssystem entsteht, der durch einzelne funktionstüchtige Komponenten ergänzt wird.

5


5.2


1292

In Demonstrationsprototypen wird dabei die Unterstützung der Aufgaben skizziert, die anhand der beschriebenen Dokumenttypen als wesentlich erkannt wurden. Einzelne Aufgaben werden technisch durch ein Labormuster bis zur Systembasis implementiert. Diesen Zusammenhang deutet Abbildung 5-26 an. Der Bau von T-Prototypen erweist sich dann als besonders günstig, wenn der Prototyp von verschiedenen Ziel- und Interessengruppen bewertet wird. Oft stehen dabei jeweils fachliche oder technische Kriterien im Vordergrund, etwa wenn Anwender und das Entwicklungsmanagement den Erfolg eines Prototyps beurteilen (s. Kapitel 5.1.3). Prototypen sind die entscheidende Basis, damit Entwickler und Anwender substantiell über das zukünftige System reden können. Anhand der verschiedenen Prototypen wird die Bewertung von fachlichen und technischen Entwurfsentscheidungen möglich. Von zentraler Bedeutung sind dabei solche Prototypen, die neben einer ausgearbeiteten Benutzungsschnittstelle sowohl das fachliche Modell des Anwendungssystems als auch ein diskussionswürdiges Implementationsmodell umfassen. Hier zeigt sich wieder, wie wichtig unsere Forderung nach Strukturähnlichkeit ist (s. S. 126).

5

Eignung von Prototypen für Entwickler und Anwender


5.2


1293

❑ Für die Anwender wird durch den Einsatz von Prototypen

deutlich, daß der aufwendige Analyseprozeß unter Verwendung der analytischen Dokumenttypen Szenario, Glossar, Kooperationsbilder und Wozu-Tabellen zu sinnvollen und operationalisierbaren Ergebnissen führt, die ihre Arbeit unterstützen. ❑ Für das Entwicklerteam ist entscheidend, daß die angefertigten

Systemvisionen nicht den Charakter von Illusionen haben, d.h., die prinzipielle Konstruierbarkeit der angestrebten Lösung muß gezeigt werden. ❑ Für das Entwicklungsmanagement wird deutlich, daß der

innovative Entwicklungsprozeß in absehbarer Zeit mit nachvollziehbarem Aufwand zu tragfähigen Ergebnissen (Pilotsystemen) führt, die stufenweise in die bestehende fachliche Arbeitsumgebung der Anwender und die technische Arbeitsumgebung der Entwickler integriert werden können. ❑ Für das Anwendermanagement wird schließlich deutlich, daß

der Entwicklungsprozeß zu einer organisatorisch und fachlich zu vertretenden Lösung führt, die mit Blick auf die zu erledigenden Aufgaben effizienter als die bisherige Lösung ist.

5


5.2


1294

Prototypen dokumentieren vorrangig für die Entwickler, wie sich das allgemeine Leitbild in die Gestaltung von Oberflächen und Handhabungsformen umsetzen läßt. In diesem Zusammenhang sind dann auch Managemententscheidungen über den grundsätzlichen Zuschnitt des späteren Systems gefordert. Neben den Prototypen im engeren Sinne werden auch immer wieder Labormuster, d.h. Prototypen, die innerhalb des Entwicklerteams zur Bewertung von Designalternativen dienen, mit großem Gewinn im Entwicklungsprozeß erstellt. Sie sind nicht nur nützlich, weil sie den Entwicklern bei der Klärung eines Konstruktionsproblems helfen, sie sind oft auch Katalysatoren für neue und weitreichende Ideen für die Systemgestaltung. Im Entwicklungsprozeß ist der Einsatz und die Bewertung von Prototypen entscheidend für den Erfolg des Prototyping-Verfahrens. Prototyping, so wie wir es hier definiert haben, orientiert sich stark an anwendungsfachlichen Fragestellungen und an der Gebrauchsqualität des Softwaresystems. Darüber dürfen die softwaretechnischen Gesichtspunkte und die Anforderungen an die Architektur nicht vergessen werden. Daher muß im Rahmen einer methodischen Vorgehensweise verankert werden, daß in größeren Abschnitten technische Revisionen im Prototyping-Prozeß durchgeführt werden können. Dies

5

Erstellung eines Prototyps


5.2


1295

bedeutet, daß die jeweils aktuellen funktionellen Prototypen unter softwaretechnischen Gesichtspunkten überarbeitet werden, um eine saubere konstruktive Grundlage für die evolutionäre Entwicklung der Prototypen hin zum Zielsystem zu gewährleisten. Demgegenüber sind Demonstrationsprototypen als »Wegwerfprototypen« gedacht. Dabei ist darauf zu achten, daß sie diesen Charakter behalten. Oft erleben wir in Projekten, daß eine attraktive Benutzungsschnittstelle das Management dazu bringt, solche Demonstrationsprototypen zur Plattform der weiteren Entwicklung zu machen. Entwickler sollten immer deutlich machen, daß Demonstrationprototypen nur Entwurfsskizzen im Sinne eines Layout sind. Sie demonstieren, was die fachliche Analyse und der fachliche Entwurf ergeben haben, aber sie sind ohne Rücksicht auf eine Zielarchitektur und auf softwaretechnische Qualitätsmerkmale entwickelt. Demonstrationsprototypen fördern damit die wesentlichen Lern- und Kooperationsprozesse bei der Systementwicklung und die Ausarbeitung von fachlichen Systemvisionen. Neben den klassischen Formen der Bewertung von Prototypen in Rahmen von Projektreviews oder Benutzerarbeitskreisen haben wir mit großem Erfolg in verschiedenen Projekten Werkstattbesuche als methodisches Element eingesetzt.

5

Einsatz eines Prototyps im Entwicklungsprozeß


5.2


1296

Werkstattbesuche: Werkstattbesuche sind »informelle Treffen« am Arbeitsplatz der Entwickler. Entwickler stellen in ihrer Arbeitsumgebung den Anwendern die »in Arbeit befindlichen« Prototypen vor.

Diese Art der Demonstration von Prototypen hat mehrere strategische Vorzüge gegenüber den normalen Arbeitstreffen, Workshops oder gar Reviews. Zunächst ist die Atmosphäre informell. Da immer nur einzelne Anwender einen solchen Werkstattbesuch machen, hat die Kommunikation einen eher persönlichen Charakter. Viele Problempunkte lassen sich so vorab, d.h. vor offiziellen Projektterminen oder Reviews, klären. Ein weiterer Vorteil ist der Beitrag zur kontinuierlichen Zusammenarbeit zwischen Entwicklern und Anwendern. Auch ehe Prototypen vollständig fertiggestellt sind, lassen sich bei einem Werkstattbesuch Teilergebnisse präsentieren. Niemand wird die Erwartung an ein fertiges Produkt haben. Trotzdem wird deutlich, daß etwas passiert, in welche Richtung die Entwicklung geht und daß die Anwender tatsächlich einbezogen werden. Insgesamt sollten Rückkopplungszyklen mit Anwendern über Prototypen zeitlich eng gewählt werden, denn Diskussionen über Prototypen bilden die Grundlage einer gemeinsamen Projektkultur, in der die gegenseitige fachliche Kompetenz akzeptiert wird.

5


5.2


1297

Bei Werkstattbesuchen und anderen Formen der Bewertung von Prototypen haben wir erfolgreich Drehbücher eingesetzt. Drehbücher: Ein Drehbuch schildert auf der Grundlage einer knappen fachlichen Situationsbeschreibung in einfach formulierten Handlungsfolgen alltägliche Arbeitssituationen. Dabei werden nahe an der Alltagswirklichkeit bestimmte Aufgaben erledigt, ohne daß das neue Anwendungssystem direkt in die Schilderung mit einbezogen wird. Die Szenen des Drehbuchs werden dann unter Verwendung des Prototyps als einer Art Requisite »durchgespielt«.

Der Wert von Drehbüchern liegt vor allem darin, daß Prototypen damit gezielt und praxisnah bewertet werden, wobei die Erledigung relevanter Aufgaben unabhängig vom konkreten Benutzungsmodell gefordert wird. Mit Drehbüchern läßt sich bei der Vorführung und Bewertung von Prototypen die Gefahr vermeiden, daß Anwender oder Entwickler durch interaktives »Herumspielen« Unwesentliches und Unverständliches zum Gegenstand der Bewertung machen. Statt fruchtlose Diskussionen über Details des Bildschirmlayouts zu führen, können sich die Beteiligten sehr rasch auf den fachlichen Kern eines Prototypen

5


5.2


1298

und die Verwendbarkeit der modellierten Werkzeuge und Materialien konzentrieren. Als Randbemerkung sei erwähnt, daß sich solche fachlich motivierten Drehbücher auch für die Bewertung von Standardsoftware sehr gut eignen. Der Pausenplanersteller will für das neue Schuljahr einen neuen Pausenplan erstellen. Da die wichtigsten Daten zu Pausen und Lehrplänen gegenüber dem Pausenplan von vor einem Jahr unverändert sind, benutzt er diesen alten Pausenplan als Vorlage. Allerdings muß er die aktuelle Situation des Lehrkörpers berücksichtigen. Zwei Referendarinnen sind mittlerweile ausgeschieden und durch neue Personen ersetzt worden. Der Pausenplanersteller paßt den alten Pausenplan auf die neuen Bedingungen an.

Die verschiedenen Arten von Prototypen werden über den gesamten Entwicklungszeitraum erstellt. Dies bedeutet, daß wir in größeren Projekten das gesamte Spektrum der Prototyp-Arten je nach Fragestellung einsetzen. Das bedeutet aber auch, daß Prototyping nicht zu einer Phase im Entwicklungsprozeß, etwa zur Unterstützung der Anforderungsermittlung, reduziert wird. Denn Prototypen schließen, wie wir bereits in [Kilberth et al. 94] festgehalten haben, den »Kreis von objektorientiertem Entwurf und Prototyping. Szenarios, Glossar, Systemvisionen sind die für alle betei-

5

Drehbuch Pausenplaner erstellt Pausenplan

Anzahl der Prototypen und zeitlicher Umfang


5.2


1299

ligten Gruppen diskutierbaren Entwicklungsdokumente. Diese werden um softwaretechnische Dokumente wie Klassenbeschreibungen und Klassenbibliotheken ergänzt, und daraus werden Prototypen entwickelt, die dann die weitere Diskussion unterstützen.« Prototypen sind das wirkungsvollste Mittel, um die Dynamik eines Entwurfs darzustellen und für alle beteiligten Gruppen diskutierbar zu machen. Deshalb ist eine Festlegung auf eine bestimmte Anzahl von Prototypen nicht sinnvoll. Darüber hinaus sind sie entscheidend, wenn in Etappen der Projektfortschritt (s. S. 574ff.) festgestellt werden soll. Sie bilden als Pilotsysteme den gleitenden Übergang zwischen einem Kernsystem und seinen Ausbaustufen. Neben den bereits erwähnten, vielfältigen Zusammenhängen zu anderen Dokumenttypen ist der Zusammenhang zwischen Prototypen und Systemvisionen besonders eng. Denn einerseits stehen Systemvisionen an der entscheidenden Schnittstelle zwischen der Analyse der gegenwärtigen Situation und dem Entwurf des zukünftigen Systems. Andererseits haben wir darauf hingewiesen, daß Systemvisionen nur begrenzt für die Diskussion zwischen allen beteiligten Gruppen geeignet sind. Deshalb müssen wir die verschiedenen Arten von Systemvisionen und die fachlich und technisch evaluierbaren Prototypen gut aufeinander abstimmen:

5



5.2


1300

❑ Fachliche Ablaufvisionen und Handhabungsvisionen bilden

die Grundlage, um Drehbücher anzufertigen, mit denen dann Prototypen »durchgespielt« werden. ❑ Werkzeugvisionen werden um Demonstrationsprototypen mit

geringer fachlicher »Tiefe« ergänzt. ❑ Einbettungsvisionen motivieren verschiedene Labormuster,

mit denen die technische Einbettung neuer Systemteile erprobt werden. Typischerweise intensivieren Prototyp-Evaluationen die Autor-Kritiker-Zyklen. Oft werden nach einer Prototyping-Sitzung Szenarien und Glossar erneut hinterfragt. Auf der technischen Seite beeinflussen funktionelle Prototypen und Labormuster z.B. die Visionen über die Einbettung neuer Systemteile.

5


5.2


1301

5.2.5 Kooperationsbilder Kooperationsbild: Ein Kooperationsbild (s. [Krabbel et al. 96b]) ist eine visuelle Darstellung einer kooperativen Arbeitssituation, besonders bei übergreifenden Aufgaben (vgl. Kapitel 4.1.4). Dabei werden allgemeinverständliche Piktogramme verwendet. Kooperationsbilder stellen dar, wie Personen arbeitsteilig zusammenarbeiten.

Mit Szenarios, Glossaren und Systemvisionen lassen sich die verschiedenen Aufgaben und Aktivitäten sehr gut aus der Sicht einzelner Arbeitsplätze beschreiben. Was fehlt ist die Gesamtsicht einer kooperativen Situation, besonders bei komplexen übergreifenden Aufgaben. Diese Gesamtsicht kann nicht einfach erstellt werden, da kaum einer der Anwendungsexperten sich mit diesem Aspekt der täglichen Arbeit vor einem Softwareprojekt befaßt hat. Dieses Problem stellt sich dann, wenn komplexe Kooperationsformen unterstützt werden sollen. Auf der allgemeinen Ebene ist ein zweites Problem angesiedelt: Die Menge der Szenarios für eine kooperative Aufgabe, etwa zur Vermittlung eines Kredits oder zur Aufnahme eines Patienten in ein Krankenhaus, stellt eine solche Textfülle dar, daß sie für einen Überblick nur

5

Zweck von Kooperationsbildern


5.2


1302

begrenzt geeignet ist. Damit sind solche Dokumentmengen auch keine ausreichende Grundlage für die gemeinsame Diskussion der Beteiligten über Kooperationszusammenhänge. Schließlich eignet sich die reine Textform nur sehr bedingt für eine Rückkopplung mit Gruppen von Anwendern im Rahmen einer Arbeitssitzung. Kooperationsbilder sollen deshalb in anschaulicher Form klar machen, wie und auf welche Art und Weise die Beteiligten bei der Erledigung einer übergreifenden Aufgabe kooperieren. Neben der reinen Rückkopplung von Analyseergebnissen können Kooperationsbilder verwendet werden, um kooperative Aufgaben und Arbeitsschritte gemeinsam zu analysieren und den Beteiligten deutlich zu machen. Schließlich eignen sie sich, um die Auswirkungen von Veränderungen der Organisation einzuschätzen. Abbildung 5-27 zeigt die Kooperationsbilder in den Dimensionen relevanter Fragestellungen für Dokumenttypen.

5


5.2


1303 Abb. 5-27 Kooperationsbilder in den Dimensionen der Dokumentation

Detail

Dynamik

Überblick

Kooperationsbilder

Statik Fachlich

Technisch

Kooperationsbilder geben einen Überblick der Dynamik und der Zusammenhänge von Kooperationsbeziehungen. Dabei greifen sie überwiegend fachliche Fragestellungen auf, ohne dabei die Verwendung technischer Hilfsmittel zu vernachlässigen, soweit diese im fachlichen Modell relevant sind. Strukturelle Bestandteile von Kooperationsbildern sind beschriftete Symbole für Räume und funktionelle Rollen, die durch Pfeile miteinander verbunden sind. Die Pfeile werden mit Piktogrammen »beschriftet«. Die Symbole bezeichnen einen Raum, wenn dieser als eine

5

Aufbau von Kooperationsbildern


5.2


1304

»Instanz« für die Erledigung kooperativer Aufgaben steht (z.B. das Stationszimmer einer Krankenhausstation mit den verschiedenen Personen, die in diesem Zimmer zusammenarbeiten), oder eine funktionelle Rolle, die nicht einfach einem Raum zugeordnet werden kann (z.B. der Stationsarzt, der selten an einem Ort ist). Die Pfeile zeigen an, daß Materialien oder Informationen weitergereicht oder ausgetauscht werden. Die Piktogramme an den Pfeilen konkretisieren, was weitergegeben oder wie ausgetauscht wird. Sie symbolisieren Gegenstände, die zwischen den Räumen ausgetauscht werden, Medien, mit denen Information übermittelt werden, sowie Mitarbeiter und Kunden, die Wege zurücklegen. Weiterhin können Pfeile numeriert werden, um eine typische oder beispielhafte Reihenfolge bei der Aufgabenerledigung darzustellen. Im Zentrum des Interesses steht bei Kooperationsbildern, wie eine kooperative Aufgabe im jeweiligen Arbeitszusammenhang zwischen den beteiligten Personen erledigt wird oder werden soll. Kooperationsbilder veranschaulichen also sowohl die gegenwärtige als auch eine geplante Situation und geben Aufschluß darüber,

Inhalte von Kooperationsbildern

❑ welche Bereiche oder funktionelle Rollen an einer übergreifen-

den Aufgabe beteiligt sind, ❑ welche Gegenstände zwischen ihnen ausgetauscht werden und

welches Medium zur Koordination verwendet wird,

5


5.2


1305

❑ welche Laufwege durch Mitarbeiter oder Kunden einer Orga-

nisation zurückgelegt werden, ❑ welche typischen oder besonderen Reihenfolgen vorkommen.

Kooperationsbilder liefern Anwendern und Entwicklern in Besprechungen und Workshops die Basis, um ein gemeinsames Verständnis über Charakter und Ablauf kooperativer Tätigkeiten zu erarbeiten (s. [Krabbel et al. 96c]). Kooperationsbilder eignen sich für Anwender in der folgenden Weise:

Eignung von Kooperationsbildern für Entwickler und Anwender

❑ Sie fördern das Verständnis der eigenen Arbeitszusammen-

hänge. Denn Kooperationsbilder haben im Unterschied zu anderen softwaretechnischen Darstellungsmitteln keine formale oder weitgehend abstrakte Syntax, sondern können mit einem normalen fachlichen Hintergrund verstanden werden. Anwender finden sich und ihre Arbeit in diesen Bildern wieder. ❑ Anwender können nach einer Einarbeitungs- oder Erklärungs-

zeit von wenigen Minuten von Anfang an aktiv bei der Analyse oder bei der Planung von kooperativen Aufgaben mitarbeiten und mitdiskutieren. So wird in relativ kurzer Zeit auf einem Wandbild vergegenständlicht, wie eine übergreifende Aufgabe kooperativ erledigt wird, wer dabei was macht und weshalb etwas auf eine bestimmte Art und Weise gemacht wird.

5


5.2


1306

❑ Kooperationsbilder veranschaulichen für Anwender die Kom-

plexität ihrer Arbeit. Sie schaffen einen Diskussionsgegenstand, der die Anwender sehr einfach in die Lage versetzt, über ihre eigene Organisation nachzudenken und diese zu hinterfragen. ❑ Kooperationsbilder fördern das gegenseitige Verständnis. In

der mit ihrer Erstellung verbundenen Diskussion wird vielen Anwendern (häufig zum ersten Mal) deutlich, welche (Teil-) Aufgaben die anderen Organisationsbereiche zu erledigen haben und wie sie diese durchführen. Damit kann ein größeres und übergreifendes Verständnis der verschiedenen Bereiche und Abteilungen füreinander geschaffen werden. ❑ Für das Anwendungsmanagement sind Kooperationsbilder

eine gute Grundlage, um organisatorische Schwachstellen bei der Zusammenarbeit zu erkennen. Kooperationsbilder sind damit die Basis für mögliche Änderungen sowohl in der Ablauf- als auch in der Aufbauorganisation.

5


5.2


Als wir in einem von uns durchgeführten Krankenhausprojekt [Krabbel et al. 96a] zum erstenmal in einer Arbeitssitzung ein Kooperationsbild erarbeitet haben, erlebten alle Teilnehmer (Pflegepersonal, Ärzte, Verwaltungspersonal, Projektbegleiter) Überraschungen. Es wurde deutlich, daß bei der regulären Aufnahme eines Patienten an einem Vormittag bis zu 17 mal telefoniert wird und zahlreiche Laufwege durch die Pflegekräfte erledigt werden müssen. Dies führte sofort zu der Diskussion, was davon notwendig und sinnvoll ist, aber auch, was davon durch eine Rechnerunterstützung einzusparen wäre. Viele Teilnehmer haben durch das als Wandbild erstellte Kooperationsbild zum ersten Mal gesehen, daß ihre Arbeit nicht nur aus der Pflege der Patienten, sondern zu einem erheblichen Teil aus Kooperations- und Dokumentationsarbeit besteht.

1307 Beispiel für den Einsatz von Kooperationsbilder

Kooperationsbilder sind auch für die Entwickler ein geeignetes Mittel, um sich in komplexe und stark kooperative Anwendungsbereiche einzuarbeiten: ❑ Die gemeinsam erarbeiteten Kooperationsbilder stellen eine

Technik zur Rückkopplung mit Anwendergruppen dar. Dabei können Entwickler überprüfen, ob die von ihnen anhand der einzelnen Szenarios erarbeitete Sicht auf die Zusammenhänge auch die Sicht der Anwender ist und verbliebene Unklarheiten können schnell ausgeräumt werden.

5


5.2


1308

❑ Im Rahmen der Diskussion können noch »unbekannte«

Zusammenhänge erarbeitet werden. Damit können die Entwickler »weiße Flecken« in ihrer Analyse erkennen, und sie erhalten Hinweise darauf, welche weiteren funktionellen Rollen zu interviewen sind. ❑ Kooperationsbilder vergegenständlichen die Zusammenhänge

von Arbeitstätigkeiten. Sie zeigen den Informations- und Kommunikationsfluß und die Weitergabe von Gegenständen. Sie liefern damit die Grundlage, um Kooperationsformen zu identifizieren und Gegenstände, insbesondere Dokumente, in ihrer Bedeutung für Kooperation und Koordination einzuordnen. ❑ Die Vergegenständlichung der Kooperationszusammenhänge

zeigt zugleich die »Dichte« des Informationsflusses. Diese bietet Anlaß zu einer Gewichtung, welche Kooperationsformen durch ein zukünftiges System zu unterstützen sind.

5


5.2


1309 Beispiel für ein Kooperationsbild

Pausenplanersteller Lehrkörper

4 2

5

3

Abb. 5-28 1

Kooperationsbild »Änderung eines

Schulsekretariat

Lehrer

Pausenplans«

Das Kooperationsbild von Abbildung 5-28 zeigt, wie Schulsekretariat, Pausenplanersteller und die beteiligten Lehrer zusammenarbeiten. Es vermittelt weiterhin, von welcher Art die Kooperation ist; ob Informationen ausgetauscht werden, wie z.B. persönlich, über das Telefon, oder ob Gegenstände zwischen verschie-

5


5.2


1310

denen Arbeitsplätzen transportiert werden. Die Numerierung an den Pfeilen gibt eine typische Abfolge bei der Erledigung der übergreifenden Aufgabe wieder. So soll die Numerierung hier verdeutlichen, daß eine Änderung des aktuellen Pausenplans oft von einem Lehrer ausgeht, der eine Änderung im Unterrichtsplan an das Sekretariat meldet. Dieses informiert den Pausenplanersteller durch eine Notiz, der evtl. wegen Details nochmals zurückruft. Der neue Pausenplan geht dann an das Schulsekretariat, das ihn an den Lehrkörper verteilt.

Die verschiedenen Arten, ein Kooperationsbild zu erstellen, sind vom jeweiligen Verwendungszweck abhängig. Sollen Kooperationsbilder vorrangig zur Analyse und Rückkopplung mit heterogenen Anwendergruppen eingesetzt werden, so fertigen wir Wandbilder an. Dazu werden beschriftete und unbeschriftete Symbole und eine große Anzahl unterschiedlicher Piktogramme vorbereitet. Die Arbeit an einem Wandbild während eines Workshops beginnt, indem wir lediglich »Startsymbole« vorgeben. Das Kooperationsbild wird aus der Diskussion in der Arbeitsgruppe entwickelt. Ein Entwickler als Moderator oder seine Helfer malen die Pfeile per Hand mit Filzstift direkt auf das Papier und befestigen die entsprechenden Piktogramme und Symbole auf einer Pinwand. Die anderen Entwickler bleiben passiv und machen sich Notizen. Notwendig ist jedoch, daß die Entwickler vorbereitend selbst ein Kooperationsbild erstellt haben.

5

Erstellung eines Kooperationsbilds


5.2


1311

Alternativ können Kooperationsbilder von Entwicklern selbständig auf der Basis einer durch Szenarios vorbereiteten Detailanalyse erarbeitet werden. Hier dienen Kooperationsbilder ähnlich wie Visionen dazu, den Entwicklern die Folgen von Entwurfsentscheidungen frühzeitig zu verdeutlichen. Dabei wird aufgezeigt, wie sich in Zukunft Arbeitsabläufe, Zuständigkeiten und Arbeitsgegenstände verändern. Das Ergebnis kann den Anwendern schrittweise wie eine »Diaschau« präsentiert werden, um darüber Rückkopplung zu erhalten. Kooperationsbilder werden analytisch als Teil der Modellierung des Anwendungsbereichs nach einer ersten Serie von Interviews auf der Grundlage der erstellten Szenarios eingesetzt. Als Ziel soll ein (Vor-) Verständnis der übergreifenden Aufgaben erarbeitet und mit den Anwendern rückgekoppelt werden. Den Rahmen bietet ein Workshop, in dem Kleingruppen je übergreifender Aufgabe etwa zwei bis vier Stunden arbeiten. Teilnehmer sind:

Einsatz eines Kooperationsbilds im Entwicklungsprozeß

❑ die Interviewpartner, ❑ Mitarbeiter, die die entsprechenden Aufgaben aus der täglichen

Arbeit kennen, ❑ weitere Mitglieder der Anwenderorganisation, die ein Interesse

oder einen Bezug zu diesen Aufgaben haben, ❑ Entwickler.

5


5.2


1312

Zur Vorbereitung sollten die Entwickler »probeweise« ein Kooperationsbild für die übergreifende Aufgabe erstellt haben, um den Diskussionsprozeß anzuregen und die Verwendung der Kooperationsbilder als Technik zu motivieren. Wir fassen die verschiedenen Ziele und Zwecke bei der Verwendung von Kooperationsbildern zusammen: ❑ Kooperationsbilder stellen die Ist-Situation dar. ❑ Sie können ebenso gut für die Darstellung der möglichen Ver-

änderungen der Kooperation beim Einsatz des zukünftigen Systems verwendet werden. Hier steht die Synthese verschiedener Sichtweisen im Vordergrund, mit dem Ziel, die Art der Softwareunterstützung für die Kooperation zu gestalten. ❑ Anhaltspunkte für eine gewünschte Systemunterstützung erge-

ben sich aus der Diskussion über die Schwachstellen, wie sie von den Anwendern bei der Erledigung der übergreifenden Aufgabe gesehen und anhand des Kooperationsbildes diskutiert werden. ❑ Oft werden dabei Veränderungen bei organisatorischen Abläu-

fen und in der Verteilung von kooperativen Aufgaben zwischen den Anwendern diskutiert.

5


5.2


1313

❑ Sie bilden eine Grundlage für die Anfertigung von Drehbü-

chern zu Prototyping-Sitzungen (s. Kapitel 5.2.4), in denen anhand typischer Aufgaben aus Szenarios die zukünftige Aufgabenerledigung »durchgespielt« wird. Kooperationsbilder begleiten den gesamten Entwicklungsprozeß. Vor allem zu Beginn eines Projektes wird es häufige Revisionen über Kooperationsbilder geben, da sich das Verständnis der Entwickler und Anwender von übergreifenden Aufgaben erst schrittweise entwickelt. Im weiteren Projektverlauf zeigen Kooperationsbilder dann die Abläufe mit dem sich entwickelnden System.

Anzahl der

Da ein Kooperationsbild meist im direkten Dialog zwischen Entwicklern und Anwendern entsteht und eingesetzt wird, ist es oft für Dritte unverständlich. Zudem ist es auch für die Beteiligten nicht detailliert genug, um als eigenständiges Modell zu existieren. Entwickler benötigen Szenarios zur Vorbereitung, um überhaupt ein Kooperationsbild erstellen und die Diskussion der Anwender mitverfolgen zu können. Denn Szenarios verdeutlichen die Aufgaben am einzelnen Arbeitsplatz. Die notwendigen Begriffserläuterungen liefert ein Glossar. Für die weitere Arbeit sollte ein Kooperationsbild um WozuTabellen ergänzt werden (s. Kapitel 5.2.6), die bestimmte Ausschnitte eines Bildes detaillieren und motivieren.

Zusammenhang mit

5

Kooperationsbilder und zeitlicher Umfang

anderen Dokumenttypen


5.2


1314

Da Kooperationsbilder verdeutlichen, welche Aufgaben ein Mitarbeiter alleine erledigen kann, welche Aufgaben von anderen und welche nur gemeinsam erledigt werden, hat dies Auswirkungen auf den »Zuschnitt« von Arbeitsplätzen und Arbeitsumgebungen (s. Kapitel 4.1.4). Dies beeinflußt alle anderen Entwurfsdokumente, die Prototypen und schließlich das Anwendungssystem. In unserer bisherigen Praxis zeichnen sich drei Arten von Kooperationsbildern ab, die je nach zugrundeliegender Fragestellung angefertigt werden. Das Kooperationsbild als:

Subtypen von Kooperationsbildern

❑ Überblick: Hier steht die Darstellung einer komplexen über-

greifenden Aufgabe oder eines ganzen Aufgabenbündels im Vordergrund. Reihenfolge sind ebensowenig von Interesse wie einzelne Arbeitsschritte (Beispiel: Patientenaufnahme in einem Krankenhaus). ❑ Aufgabenbild: Wie wird eine übergreifende Aufgabe mit den

verschiedenen Gegenständen arbeitsteilig durchgeführt. Hier werden die einzelnen Schritte, die sich zwischen den Beteiligten abspielen, dargestellt und eventuell mit Reihenfolgen versehen (z.B. Vergabe eines Kommunalkredits).

5


5.2


1315

❑ Planungsbild: Darstellung einer kooperativen Aufgabe mit den

verschiedenen Möglichkeiten, sie durch ein Anwendungssystem zu unterstützen. Hier werden die möglichen Systemalternativen in verschiedenen Fassungen eines Kooperationsbildes dargestellt. Ausgangspunkt ist immer ein Überblick oder ein Aufgabenbild der aktuellen Situation (z.B. die verschiedenen Ausbaustufen eines Krankenhausinformationssystems in ihren Auswirkungen auf die Patientenaufnahme). Dazu eignen sich markierte oder übereinandergelegte Folien sowie entsprechende Präsentationsprogramme.

5


5.2


1316

5.2.6 Wozu-Tabellen Wozu-Tabelle: Eine Wozu-Tabelle [Krabbel et al. 96b] ist eine Tabelle, in der für eine ausgewählte Kooperationsform festgehalten wird, wer was mit wem oder womit macht und – namensgebend für diese Art von Tabellen – wozu das gut ist. Die Frage »wozu« zielt explizit auf den Zweck einer Tätigkeit oder den kooperativen Verwendungszweck eines Gegenstandes. Konzeptionelle Grundlage der Wozu-Tabellen ist eine entsprechende Technik aus der Object Behavior Analysis (OBA) nach [Rubin & Goldberg 92] und [Heeg 95]. Dort werden Aufgaben nach dem Muster »wer – macht was – womit – welchen Dienst muß ein Gegenstand bereitstellen« beschrieben (vgl. auch [Ratuski 97]).

Wozu-Tabellen beschreiben Kooperationsaufgaben, an denen mehrere Personen beteiligt sind. Sie halten im wesentlichen fest, warum oder wozu mit und an Gegenständen gearbeitet wird und warum sie weitergeleitet werden. Damit ergänzen Wozu-Tabellen die Kooperationsbilder für ausgewählte kooperative Aufgaben. Sie dienen sowohl zur Erarbeitung als auch zur Rückkopplung dieser Aufgaben und Tätigkeiten. Gleichzeitig helfen Wozu-Tabellen bei der Diskussion, ob diese

5

Zweck von Wozu-Tabellen


5.2


1317

Kooperationsaufgaben in Zukunft so beibehalten werden sollen oder ob und wie sie fachlich verändert werden sollen. Abbildung 5-29 zeigt die Wozu-Tabellen in den Dimensionen relevanter Fragestellungen für Dokumenttypen. Abb. 5-29 Wozu-Tabellen in den Dokumentationsdimension

Wozu-Tabellen Detail

Dynamik

Überblick

Statik Fachlich

Technisch

Wozu-Tabellen zeigen Details der Dynamik einzelner Kooperationsbeziehungen. Dabei greifen sie überwiegend fachliche Fragestellungen auf, ohne die Frage der technischen Umsetzung zu behandeln.

5


5.2


1318

Wozu-Tabellen werden nach der Aufgabe benannt, deren Tätigkeiten in ihr beschrieben werden. Im einfachsten Fall bestehen Wozu-Tabellen aus zwei Spalten. In der ersten Spalte werden die Tätigkeiten (der beschriebenen Aufgabe) benannt, und korrespondierend wird dazu in der zweiten Spalte festgehalten, wozu die einzelne Tätigkeit durchgeführt wird und was die Konsequenz dieser Tätigkeit ist (s. Abbildung 5-30). Alternativ können Wozu-Tabellen in die vier Spalten »Wer« »Macht was« »Mit wem/womit« »Wozu« aufgeteilt werden (s. Abbildung 5-31). Die Zeilen dieser Tabelle werden meist numeriert. Diese Aufteilung ist insbesondere dann aussagekräftiger, wenn die WozuTabelle im Zusammenhang mit der Beschreibung übergreifender Aufgaben und mit Kooperationsbildern verwendet wird. Die Numerierung bezieht sich dabei auf die Nummern an den Pfeilen des zugehörigen Kooperationsbildes.

Aufbau von Wozu-Tabellen

Wir stellen in Wozu-Tabellen ausgewählte kooperative Aufgaben dar und verdeutlichen damit, welche Bedeutung den dabei verwendeten Gegenständen im Kooperationszusammenhang zukommt. Im WAMAnsatz bilden ja die Gegenstände eines Anwendungsbereichs den Ausgangspunkt für die fachliche Modellierung. Wir haben betont, daß es

Inhalte einer Wozu-Tabelle

5


5.2


1319

dabei keine Eins-zu-eins-Übertragung der vorgefundenen Gegenstände in das Modell des Anwendungssystems gibt. Besonders wenn wir übergreifende Aufgaben modellieren, besteht die Gefahr, den Zweck und die verschiedenen Implikationen zu übersehen, die die Gegenstände und die Arbeit an und mit ihnen für die Kooperation haben. Damit verkennen wir aber wesentliche Aspekte der Bedeutung dieser Gegenstände für die Modellierung von Kooperationszusammenhängen. So ist es im Beispiel von Abbildung 5-30 wichtig, daß der Anordnungsbogen je nach Bearbeitung an einer bestimmten Stelle liegt. Dadurch koordinieren Ärzte und Schwestern ihre Arbeit. Entscheiden wir uns, einen Gegenstand im System nicht oder nur mit einigen ausgewählten Eigenschaften zu modellieren, so können wir anhand der Wozu-Tabellen die damit verbundenen Auswirkungen auf die Organisation der kooperativen Bearbeitung durchspielen und mit Anwendungsexperten diskutieren. Wozu-Tabellen haben für Anwender und Entwickler große Bedeutung im Analyseprozeß. Wir haben darauf hingewiesen, daß es bei komplexen übergreifenden Aufgaben nicht »den Anwender« gibt, den die Entwickler fragen können, da Anwender selbst nur bedingt die detaillierten Zusammenhänge ihrer individuellen Tätigkeiten überblicken

5

Eignung von WozuTabellen für Entwickler und Anwender


5.2


1320

(s. Kapitel 4.1.4). Dies hat zur Folge, daß wir neue Abläufe und Kooperationsformen, die durch ein Anwendungssystem möglich oder bedingt sind, nur schwer daraufhin überprüfen können, ob sie in der täglichen Praxis sinnvoll und für die Arbeit der Anwender unterstützend sind. Hier bilden die in der Ist-Analyse erstellten und rückgekoppelten Wozu-Tabellen eine gute Diskussionsgrundlage. Beispiele

Einzeltätigkeiten

Zweck/Implikationen

Arzt schreibt Anordnung auf den Anordnungsbogen.

Es wird dokumentiert, wann die Untersuchung von wem angeordnet wurde (Forensik, Fehlersuche).Die Untersuchung wird angestoßen.

Arzt legt den Anordnungsbogen in den Postkorb der Schwester.

Schwester sieht, daß sie etwas tun muß. Sie ist über die Behandlung des Patienten informiert.

Schwester füllt den Kopf des Anmeldeformulars mit den Patientendaten (Etiketten) aus und trägt die Art der Untersuchung ein.

Schwester bereitet das Formular vor, um den Arzt zu entlasten.

für Wozu-Tabellen

Abb. 5-30 Wozu-Tabelle einer Anmeldung zur Röntgenuntersuchung

5


5.2


Schwester trägt die Untersuchung mit Bleistift in die Patientenakte ein.

Es ist für das Pflegeteam und alle behandelnden Ärzte einsehbar dokumentiert, wann die Untersuchung angemeldet wurde und zu welchen Untersuchungen der Patient angemeldet ist.

Schwester legt das Anmeldeformular in den Postkorb des zuständigen Arztes.

Dadurch weiß der Arzt, daß er die Unter-suchung freigeben muß.

Arzt sieht das Formular im Postkorb, trägt die Untersuchungsfragestellung ein, unterschreibt es und legt es in den Postkorb der Schwester.

Die Röntgenärztin wird näher darüber informiert, worauf sie achten muß und daß der Arzt die Unter-suchung verantwortet.

1321

Schwester bringt das Formular Die Röntgenabteilung kann die Unterin die Röntgenabteilung. suchung einplanen und die Röntgenärtzin kann die Angemessenheit der Untersuchung prüfen. Röntgenassistentin vergibt anhand ihres Kalenders einen Termin für die Untersuchung und gibt ihn telefonisch an die Station weiter.

Dies geschieht zur Koordinierung der Untersuchungen. Die Station weiß dadurch, wann der Patient in die Röntgenabteilung gebracht werden muß.

Schwester trägt den Termin im Stationskalender ein.

Damit wird der Termin dem ganzen Pflegeteam bekannt.

5


5.2


1322

Die Wozu-Tabelle zeigt, daß bei der Anmeldung zur Röntgenuntersuchung viele Gesichtspunkte zu berücksichtigen sind. Verschiedene Personen müssen sich in ihrer Tätigkeit koordinieren. Dabei spielt neben der persönlichen oder schriftlichen Abstimmung die Koordination über Gegenstände eine wesentliche Rolle. Wer

erledigt was

mit wem/was

wozu

1

Kundenberater

erstellt Angebot, bestätigt Auftrag

Kunde, Bevollmächtigter (Abteilungsleiter)

um Angebot und Abschluß zu tätigen und zu bewilligen

2

Kundenberater

erstellt Abschlußzettel

Kundeninformationen und Unterlagen

um die Grundvoraussetzungen für die Bearbeitung des Kredits zu schaffen

3

Sachbear- erstellt Kreditbeiter unterlagen und Überweisungsträger

Abschlußzettel, Formulare

aus gesetzlichen und verwaltungstechnischen Gründen

Kundenberater

Abschlußzettel, Kreditunterlagen

4

prüft Korrektheit der Unterlagen

um die sachliche Korrektheit der Kreditunterlagen zu gewährleisten

5

Abb. 5-31 Wozu-Tabelle zur übergreifenden Aufgabe »Vermittlung eines Kommunalkredits«


5.2


5

Kreditkontrolle

prüft die Korrektheit der Kreditunterlagen

Kreditunterlagen


6

Sachbear- versendet Kredibeiter tunterlagen an Kunden

Kreditunterlagen


7

Sachbear- erstellt und veran- Kreditunterbeiter laßt Überweisung lagen, Formulare

1323

um Kredit und Maklerprovision auszuzahlen

In diesem Beispiel scheinen die einzelnen Schritte klar und durch Sachlogik vorgegeben. Die Diskussion mit Bankmitarbeitern erbrachte, daß eine fixe Reihenfolge der Schritte kaum festgelegt werden kann (s. S. 445ff.).

Wozu-Tabellen werden von Entwicklern auf der Grundlage der Szenarios und in Ergänzung zu den Kooperationsbildern erstellt. Meist werden sie schon vor der eigentlichen Auswertung mit Anwendern angefertigt.

5

Erstellung einer Wozu-Tabelle


5.2


1324

Bei der Analyse komplexer übergreifender Aufgaben werden Wozu-Tabellen aber auch direkt in Workshops mit Anwendern parallel zu Kooperationsbildern erarbeitet. Wozu-Tabellen haben zunächst eine analytische Funktion, da sie den Entwicklern helfen, die Details einer kooperativen Aufgabe zu verstehen und zu modellieren. Sie sind ein gutes Mittel, um Kommunikations- und Lernprozesse zu unterstützen, da sie das intensive fachliche Gespräch mit den Experten der Anwendung fördern. Dabei machen sie den Anwendern Details und implizite Zusammenhänge bewußt und ermöglichen es, überhaupt über diese Dinge zu reden. Wozu-Tabellen decken immer nur einen Ausschnitt eines Anwendungsmodells ab. Wir wählen solche Ausschnitte, die für die Modellierung des zukünftigen Systems von kritischer Bedeutung erscheinen. Damit sind Entscheidungen für eine Wozu-Tabelle auch schon immer Entwurfsentscheidungen. Schließlich beeinflussen Wozu-Tabellen die Organisationsentwicklung. Sie helfen den Rahmen abzustecken, in dem »leicht« organisatorische Änderungen vorgenommen werden können. Sie stellen dar, wozu etwas getan wird. Soll also im Rahmen einer Organisationsentwicklung eine Aufgabe wegfallen, von einer anderen Person erledigt oder durch Softwareunterstützung anders durchgeführt werden, so müssen wir sicherstellen, daß der damit verbundene Zweck nach wie vor erreicht wird.

5

Einsatz einer Wozu-Tabelle im Entwicklungsprozeß


5.2


1325

Wozu-Tabellen werden immer bei der Analyse und Modellierung kooperativer Aufgaben erstellt. Sie ergänzen Kooperationsbilder und bereiten Systemvisionen vor. Wozu-Tabellen werden nicht mit dem Anspruch auf Vollständigkeit entwickelt – weder im Umfang noch in ihrer Anzahl.

Anzahl der Wozu-Tabellen

Neben ihrer offensichtlichen Beziehung zu Kooperationsbildern und Systemvisionen hängen Wozu-Tabellen mit Entwurfsdokumenten zusammen. Gegenstände der Anwendung haben vor allem bei übergreifenden Aufgaben eine Bedeutung für die Kooperation. Damit charakterisieren Wozu-Tabellen einen wesentlichen Aspekt fachlicher Gegenstände, den wir bis in das Klassenmodell berücksichtigen müssen. Da Wozu-Tabellen die Grundlage sind, um die Auswirkungen der Modellierung von Gegenständen der Anwendung im zukünftigen System durchzuspielen, beeinflussen sie auch die Entwicklung von Prototypen. Wozu-Tabellen sind kein Ersatz für Szenarios. Sie »verdichten« das Wissen über den Verwendungszweck von Gegenständen und den Zusammenhang von Aufgaben.

Zusammenhang mit

5

und zeitlicher Umfang

anderen Dokumenttypen


5.2


1326

5.2.7 Technische Dokumenttypen Bei der Auswahl technischer Dokumenttypen gehen wir sehr pragmatisch vor. Denn hier gelten wesentliche Kriterien der anwendungsorientierten Dokumentation nicht (s. Kapitel 2.4.3). Technische Dokumente richten sich an Softwareentwickler. Für diese Zielgruppe sollten sie verständlich und leicht zu handhaben sein. Zudem sollten technische Dokumenttypen ihren Zweck erfüllen, große objektorientierte Anwendungssysteme in den relevanten Aspekten beschreiben zu können. In den letzten Jahren hat sich eine Auswahl von Dokumenttypen herauskristallisiert, die diese Kriterien mehr oder minder gut erfüllen und die zum »Handwerkszeug« objektorientierter Softwareentwicklung geworden sind. Diese Dokumenttypen sind in den wichtigen Veröffentlichungen der letzten Jahre beschrieben und verwendet worden (vgl. [Jacobson 92, Gamma et al. 96, Booch 91, Rumbaugh et al. 91]). In den Veröffentlichungen zur UML (vgl. [Burkhardt 97]) sind die meisten Dokumenttypen und Notationen für den technischen Entwurf zusammengetragen. Aus diesem Repertoire haben wir in unseren Projekten bisher sehr pragmatisch Klassen- und Objektdiagramme, Statecharts zur Modellierung von Zuständen und Zustandsübergängen sowie Interaktionsdiagramme eingesetzt.

5


5.2


1327

Um die Statik objektorientierter Programme darzustellen, verwenden wir auch in diesem Handbuch Klassendiagramme. Dabei schließen wir uns mit leichten Modifikationen der von [Gamma et al. 96] eingeführten Notation an. Abbildung 5-32 zeigt ein Klassendiagramm mit den wesentlichen Beziehungen. Klassen werden als Rechtecke dargestellt. Der Klassenname wird bei abstrakten Klassen kursiv geschrieben, sonst in normaler Schrift. Bei der Benutzt-Beziehung zwischen Klassen unterscheiden wir grafisch Objektreferenzen, Aggregationen und Erzeugung. Die Vererbung wird grafisch durch ein gleichschenkliges Dreieck dargestellt, wobei die Spitze zur Oberklasse, die flache Seite zur Unterklasse/den Unterklassen zeigt. Schnittstellenoperationen werden analog zu Klassennamen in einer Rubrik unter dem Klassennamen notiert. Exemplarvariablen werden in einer eigenen Rubrik unter den Schnittstellenoperationen vermerkt. Pseudocode einer Operation wird durch einen gerichteten Pfeil ausgehend vom Operationsnamen in einer eigenen Box dargestellt.

5


5.2

AbstrakteKlasse AbstrakteOperation()

KonkreteUnterklasse1


1328 Abb. 5-32

Objektreferenz KonkreteKlasse

Aggregation

Klassendiagramme

•

Erzeugung

Notation für

KonkreteUnterklasse2

Operation();

Exemplarvariable

Pseudocode

Mit Objektdiagrammen nach [Gamma et al. 96] stellen wir Objektgeflechte zur Laufzeit eines objektorientierten Programms dar. Abbildung 5-33 zeigt ein einfaches Objektdiagramm. Abb. 5-33

einObjekt objektReferenz

•

einAnderesObjekt

Objektdiagramm

exemplarVariable

5


5.2


1329

Um die Dynamik objektorientierter Systeme darzustellen, haben wir auch in diesem Handbuch die von Jacobson eingeführten ObjektInteraktionsdiagramme (kurz: Interaktionsdiagramme) erweitert: Grundsätzlich verläuft die Zeitachse bei Interaktionsdiagrammen von oben nach unten, so daß in einem Interaktionsdiagramm Folgen von »Ereignissen« abgebildet werden können:

Objekt

Ein Objekt einer Klasse wird mit seinem Namen über einer Linie gekennzeichnet. Auf und entlang der Linie werden alle Zeitabschnitte durch einen Balken dargestellt, in denen das Objekt aktiv eine Operation abarbeitet.

5


5.2

Objekt 1


1330

Objekt 2

Operation_1()

Rückgabewert

5


5.2

Objekt 1


1331

Objekt 2

Operation_1() Operation_2()

Rückgabewert

Interaktion zwischen zwei Objekten wird durch Pfeile ausgedrückt. Ein schwarzer Pfeil steht für einen Operationsaufruf, wobei am Pfeil der Operationsname vermerkt wird. Kehrt der Kontrollfluß am Ende einer Operation zur aufrufenden Operation zurück, so wird dies durch einen gestrichelten Pfeil dargestellt. Wird ein Wert oder ein Objekt zurückgegeben, so wird dies am entsprechenden Pfeil notiert.

5


5.2


1332

Objekt 2

Objekt 1

Operation_1() Operation_2() Oberklasse::Methode_3() Rückgabewert

Rufen zwei Objekte wechselseitig Operationen (Operation_2), auf so wird der erneute Aufruf durch einen weiteren Balken neben dem ersten Balken dargestellt. Werden bei der Ausführung einer Operation andere Operationen des Objekts oder Operationen der Oberklassen gerufen, so können diese zur Verdeutlichung des Ablaufs in einem Kasten an dem entsprechenden Balken vermerkt werden. Statt der Operationsnamen können auch Beschreibungen von umfassenderen Abläufen im Kasten aufgeführt werden.

5


5.2


1333

Diese Erweiterungen helfen uns, in den Diagrammen größere Zusammenhänge übersichtlich wiederzugeben. Als Beispiel für ein erweitertes Interaktionsdiagramm haben wir in Abbildung 5-34 die Dynamik der Änderungsmeldung zwischen einer Funktions- und einer Interaktionskomponente eines Werkzeugs dargestellt.

Interaktionskomponente Aufgabenauflister

Funktionskomponente Aufgabenauflister Manipulierende Operation

Abb. 5-34 Interaktionsdiagramm einer Änderungsmeldung

Beobachtbar:MeldeÄnderung() From beobachter.Start Until beobachter.End BeachteÄnderung() Nachricht auswerten WelcheÄnderung() Änderung

Änderungen anzeigen Benachrichtigung anderer Beobachter

5


5.2


5

1334


6

6

Rückblick und Ausblick

1335


Nun ist es zu Ende – hinter dem Leser liegen annähernd 700 Seiten; hinter uns als Autoren mehr als anderhalb Jahre Schreiben, Diskutieren, Korrigieren. Da stellt sich natürlich die Frage, ob sich der ganze Aufwand gelohnt hat. Was sollte der Leser an Gewinn aus diesem Buch herausziehen? Ich denke, das wird von den Interessen und Voraussetzungen abhängen. Vorstellen kann ich mir immerhin:

Federführung: Heinz Züllighoven

❑ In der Einleitung wird der Werkzeug & Material-Ansatz auf

einen aktuellen und knappen Nenner gebracht. Hier sind die wesentlichen Begriffe und Konzepte zusammengetragen. So etwas braucht man oft, um eine Idee nochmals zu überdenken oder sie komprimiert an das Management zu »verkaufen«.

6


6


1336

❑ Die konzeptionellen Abschnitte von Kapitel 2 enthalten, auf

den Kern reduziert, die »Theorie« und die notwendigen Begriffsdefinitionen des WAM-Ansatzes. Als wir diese Teile geschrieben haben, ist uns rasch aufgefallen, daß wir einige Konzepte und Begriffe, die bereits veröffentlicht waren, noch einmal gründlich überarbeiten mußten. Damit haben wir ein hoffentlich konsistentes Begriffsgebäude und die zu unseren Vorstellungen passenden Konzepte für eine objektorientierte Softwareentwicklung vorgelegt. Die Themen reichen von einem Objektmetamodell für den technischen und fachlichen Entwurf über Leitbilder, Metaphern und Muster bis zu Prinzipien der Modellierung und Dokumentation sowie einer passenden anwendungsorientierten Vorgehensweise. Wir hoffen, daß der Leser sich davon anregen läßt, die eigenen konzeptionellen Grundlagen zu überprüfen und gegebenfalls weiter zu vertiefen. Mit diesem Ziel haben wir auch die Literaturreferenzen in diesem Kapitel ausgewählt. ❑ Kapitel 3 bringt dann den konsolidierten konstruktiven Kern

des WAM-Ansatzes. Hier beschreiben wir, wie interaktive Anwendungssoftware einheitlich vom Entwurf bis hin zur Konstruktion gestaltet werden kann. Dieser Teil ist insofern konsolidiert, als wir auf vielfältige Erfahrungen in unterschiedlichen Ausbildungs- und Projektzusammenhängen zurückgreifen konnten. 6


6


1337

Natürlich hat dieses Kapitel auch einen didaktischen Charakter. Ich habe schon einleitend darauf hingewiesen, daß wir unseren Anspruch, ein »ernsthaftes« vollständiges Beispiel in diesem Buch zu verarbeiten, rasch aufgegeben haben. Die Entwicklung interaktiver Software ist nach wie vor ein aufwendiges und komplexes Geschäft. Daher wird dieses Kapitel für den Leser dann besonders aussagekräftig sein, wenn er sich bereits mit interaktiver Softwareentwicklung beschäftigt und mit den angesprochenen Problemen »herumgeschlagen« hat. Wir hoffen, auch dem erfahrenen Entwickler noch ein paar »Weisheiten« ins Stammbuch geschrieben zu haben. Andererseits sind wir uns schon im klaren darüber, daß diese Abschnitte für den Novizen nicht die Unterweisung für die ersten Schritte am Terminal sein können. ❑ Mit den Abschnitten des Kapitels 4 haben wir unser eigentli-

ches Territorium, die Entwicklung interaktiver Anwendungssoftware im engeren Sinne, verlassen. Kooperation und Kommunikation, Persistenz sowie technisch eingebettete Systeme sind hier in die Diskussion des WAM-Ansatzes einbezogen. Das ist für einige von uns in den letzten Jahren Neuland gewesen. Darin zeigt sich eine Tendenz, die nicht gerade beruhigend ist: Wenn wir uns heute ernsthaft mit interaktiver Anwen-

6


6


1338

dungsentwicklung beschäftigen wollen, dann müssen wir uns mit diesen Themen befassen. Denn niemand wird heute von uns noch Einzelplatzsysteme auf der Basis von lokalen Dateien und ohne Anschluß an ein technisches Umfeld haben wollen. Erschreckend ist daran, daß die genannten Themen bisher immer als eigenständige Disziplinen der Informatik gesehen wurden und von uns mit distanziertem Interesse betrachtet werden konnten. Nun werden sie allmählich zum Handwerkszeug, das jeder Auftraggeber von uns erwartet. Da diese Themen aber von Hause aus schon recht komplex und umfangreich sind, standen wir vor einem Dilemma: Wie grundlegend sollten wir diese Themen hier behandeln. Wir haben schnell gemerkt, daß eine ausführliche Behandlung von den elementaren Prinzipien bis zur konkreten Konstruktionsanleitung dieses Handbuch mehrbändig gemacht hätte. Daher haben wir uns entschlossen, das »Einstiegsniveau« in diesen Kapiteln deutlich anzuheben. Hier erwarten wir vom Leser, daß er sich mit den wesentlichen Grundkonzepten, Hilfsmitteln und Techniken bereits auskennt. Im Mittelpunkt des Interesses stand für uns die Frage, wie diese Themen in das WAM-Konzept integriert werden können. Dazu ist in diesem Buch noch nicht das letzte Wort gesprochen. Doch wir hoffen, daß die zahlreichen Anregungen aufgegriffen werden können.

6


6


1339

❑ Kapitel 5 wird für den »harten« Softwaretechniker eher etwas

befremdlich wirken. Projektmanagement, Vorgehensweisen, Interviewtechniken, Dokumenttypen – dies wird doch traditionell eher in den sogenannten »weichen« Bereich der Betriebswirte und Systemanalytiker abgeschoben. Aber die Zeiten haben sich geändert. Selbst an Informatiklehrstühlen kann man heute mehr oder minder laut sagen, daß Softwareentwicklung nicht nur aus Spezifikation und Implementation besteht – wobei das eine sich in interessante Theorien fassen läßt und das andere ein notwendiges Übel ist –, sondern daß sie von Menschen in konkreten Projekten und real existierenden Organisationen gemacht wird. Und dazu gehören dann all die Dinge, mit denen sich ein Softwareentwickler oder ein Projektmanager in der täglichen Arbeit herumschlagen muß. Dieses Kapitel ist vielleicht das »praktischste« in diesem Handbuch. Denn hier haben wir die Techniken und Vorgehensweisen zusammengetragen, die sonst eher verstreut und in anderen Zusammenhängen herumstehen, aber die man bei der Hand haben muß, wenn man ein vernünftiges Entwicklungsprojekt durchführen will.

6


6


1340

❑ Schießlich ein Wort zur Literaturliste. Hier haben wir nicht zei-

gen wollen, was wir im Laufe der letzten Jahre so alles gelesen haben. Mehr oder minder explizit haben wir folgende Kriterien angelegt: Wer hat die Ideen geliefert, die zu einem Konzept oder einer Konstruktion des WAM-Ansatzes geführt haben? Wo lohnt es sich, mehr zu einem Thema zu lesen? Was ist in den letzten Jahren zum WAM-Ansatz veröffentlich worden? Bleibt noch die Frage, in welche Richtung sich die Aktivitäten um den WAM-Ansatz weiterentwickeln werden. Schon im Vorwort sind eine Reihe von Projekten aufgelistet, mit den wir in den letzten Jahren erfolgreich zusammengearbeitet haben. Je mehr Studenten und Entwickler mit dem Ansatz vertraut werden, desto weiter wird das Einsatzfeld. Neue Projekte sind in der Diskussion oder in der Anlaufphase. Wir werden uns mit diesen Projekten weiter in die neuen Richtungen bewegen, die in diesem Handbuch bereits skizziert sind: Unterstützung kooperativer Arbeit, Integration von WAM-Arbeitsplatzsystemen in große konventionelle Informationssysteme sowie interaktive Anwendungen in einem technischen Umfeld. Aktuell laufen Bestrebungen, dem WAM-Ansatz in unserem Umfeld einen professionellen organisatorischen Rahmen zu geben. Dies ist doppeldeutig gemeint. Einerseits wird das eine Professionalisierung der Beratung

6


6


1341

und Projektbegleitung bedeuten. Zum anderen arbeiten wir an Rahmenwerken, die die generischen Teile einer WAM-Anwendung realisieren. Diese Rahmenwerke möchten wir absehbar für Projekte im WAM-Kontext zugänglich machen. Kurz gesagt, wir haben uns einiges vorgenommen und hoffen, daß wir den Werkzeug & Material-Ansatz in der kommenden Zeit erfolgreich weiterentwickeln können.

6


6


6

1342


Autorenverzeichnis

1343

Autorenverzeichnis Das WAM-Team in Hamburg Dipl.-Inform. Wolf-Gideon Bleek Dr. Guido Gryczan Dipl.-Inform. Anita Krabbel Dipl.-Inform. Carola Lilienthal Dipl.-Inform. Stefan Roock Dipl.-Inform. Wolfgang Strunk Dr. Ingrid Wetzel Dipl.-Inform. Henning Wolf Prof. Dr.-Ing. Heinz Züllighoven Arbeitsbereich Softwaretechnik Fachbereich Informatik Universität Hamburg Vogt-Kölln-Str. 30 22527 Hamburg E-mail: @informatik.uni-hamburg.de

Autorenverzeichnis

Das WAM-Team in Hamburg

1344

Dipl.-Wirtschaftsinform. Thomas Slotos FH Nordostniedersachsen Fachbereich Wirtschaft Volgershall 1 21339 Lüneburg E-mail: [email protected] Dipl.-Inform. Dirk Weske MedIS - Medizinische Steuerungs- und Informationssysteme GmbH Grossmoorbogen 25 21079 Hamburg E-mail: [email protected] Dipl.-Ing. Falk Wiegand Intershop Communications AG Abt. Research & Development Leutragraben 2–4 07743 Jena E-mail: [email protected]

Autorenverzeichnis

Das WAM-Team in Stuttgart

1345

Das WAM-Team in Stuttgart Ute Bürkle Dipl.-Inform. Ingrid Dörre Dipl.-Math. Michael Franz Jürgen Hess Dipl.-Inform. Rolf Knoll Dipl.-Inform. Peter Rieth Dipl.-Inform. Wolf Siberski RWG GmbH Datenverarbeitungsgesellschaft Räpplenstr. 17 70191 Stuttgart E-mail: @RWG.de

Autorenverzeichnis

Das WAM-Team in Zürich

1346

Das WAM-Team in Zürich Dipl.-Inform. Dirk Bäumer TakeFive Software AG Eidmattstr. 51 CH-8032 Zürich E-mail: [email protected]

Dipl.-Inform. Daniel Megert E-mail: [email protected] Dipl.-Inform. Dirk Riehle E-mail: [email protected] Dipl.-Inform. Martina Wulf E-mail: [email protected] Schweizerische Bankgesellschaft (UBS) Bahnhofstr. 45 CH-8021 Zürich

Autorenverzeichnis

Literaturverzeichnis

1347


A [Alexander 79] C. Alexander: The Timeless Way of Building. New York: Oxford University Press, 1979. [Alexander et al. 77] C. Alexander, S. Ishikawa, M. Silverstein: A Pattern Language. New York: Oxford University Press, 1977. [Andersen et al. 90] N. E. Andersen, F. Kensing, J. Lundin, L. Mathiassen, A. Munk-Madsen, M. Rasbech, P. Sørgaard: Professional Systems Development. New York, London: Prentice-Hall, 1990.

B [Bäumer 98] D. Bäumer: Softwarearchitekturen für die rahmenwerkbasierte Konstruktion großer Anwendungssysteme. Disserationsschrift zur Vorlage am Fachbereich Informatik der Universität Hamburg, Januar 1998.



1348

[Bäumer et al. 95a] D. Bäumer, G. Gryczan, H. Züllighoven: Objektorientierte Software-Entwicklung für Banken – Methodik und Erfahrungen aus einer mehrjährigen Projektpraxis. OBJEKTspektrum Nr. 3 Mai/Juni 1995, München: SIGS Conferences GmbH, S. 45–61. [Bäumer et al. 95b] D. Bäumer, R. Budde, K.-H. Sylla, G. Gryczan, H. Züllighoven: Objektorientierte Konstruktion von Software-Werkzeugen und -Materialien. Informatik-Spektrum, Band 18, Heft 4, August 1995, Berlin, Heidelberg: Springer-Verlag, S. 203–210. [Bäumer et al. 95c] D. Bäumer, R. Knoll, G. Gryczan, W. Strunk, H. Züllighoven: Objektorientierte Entwicklung anwendungsspezifischer Rahmenwerke. OBJEKTspektrum Nr. 6 November/Dezember 1995, München: SIGS Conferences GmbH, S. 48–59. [Bäumer et al. 96a] D. Bäumer, W. R. Bischofberger, H. Lichter und H. Züllighoven: User Interface Prototyping – Concepts, Tools, and Experience. ICSE’96, IEEE Computer Society Press, March 1996, pp. 532–541. [Bäumer et al. 96b] D. Bäumer. R. Knoll, G. Gryczan, H. Züllighoven: Large Scale Object-Oriented Software-Development in a Banking Environment – An Experience Report. In: Pierre Cointe (Ed.): ECOOP’96 – ObjectOriented Programming, 10th European Conference, Linz, Austria, July 1996, Proceedings, Berlin, Heidelberg: Springer-Verlag, pp. 73–90. [Bäumer et al. 97] D. Bäumer, G. Gryczan, R. Knoll, C. Lilienthal, D. Riehle, H. Züllighoven: Framework Development for Large Systems. Communications of the ACM, October 1997, Vol. 40, No. 10, pp. 52–59. [Bäumer & Riehle 98] D. Bäumer, D. Riehle: Product Trader. In: [Martin et al. 98], pp. 29–46.



1349

[Beck & Cunningham 89] K. Beck, W. Cunnibgham: A Laboratory for teaching object-oriented thinking. Proceedings of OOPSLA ’89, pp. 1–6, 1989. [Beck & Johnson 94] K. Beck, R. Johnson: Patterns Generate Architectures. ECOOP’94, LNCS 821, Conference Proceedings, Berlin, Heidelberg: Springer-Verlag, 1994, pp. 139–149. [Berczuk 94] S. Berczuk: Finding Solutions Through Pattern Languages. IEEE Computer 27, 12, December 1994. [Bird & Wadler 92] R. Bird, P. Wadler: Einführung in die funktionale Programmierung. München: Carl Hanser und Prentice Hall, 1992. [Birrer et al. 95] A. Birrer, W. R. Bischofberger, T. Eggenschwiler: Wiederverwendung durch Framework-Technik – vom Mythos zur Realität. OBJEKTSpektrum Nr. 5, 1995, München: SIGS Conferences GmbH, S. 18–26. [Bischofberger et al. 96] W. Bischofberger, M. Guttman, D. Riehle: Global Business Objects: Requirements and Solutions. In: Proceedings of the 1996 Ubilab Conference, Zürich. K.-U. Mätzel, H.-P. Frei (eds). Konstanz: Universitätsverlag Konstanz, 1996, pp. 79–98. [Bleek 97] W.-G. Bleek: Techniken zur Konstruktion verteilter und technisch eingebetteter Anwendungssysteme. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, August 1997.



1350

[Bleicher 91] K. Bleicher: Organisation: Strategien – Strukturen – Kulturen. Wiesbaden: Gabler, 1991. [Boehm 76] B. Boehm: Software Engineering. IEEE Transactions on Computers, Vol. 25, 1976, pp. 1226–1241. [Boehm 88] B. Boehm: The Spiral Model of Software Development and Enhancement. Computer, Vol. 21, No. 5, May 1988, pp. 61–72. [Booch 91] G. Booch: Object-Oriented Design. Redwood City, Calif.: Benjamin/Cummings, 1991. [Booch 95] G. Booch: Object Solutions: Managing the Object-Oriented Project. Reading, Massachusetts: Addison-Wesley, 1995. [Boyd 98] L. Boyd: »Business Patterns of Association Objects.« In: [Martin et al. 98], Chapter 22. [Brooks 96] F. P. Brooks: The Computer Scientist as Toolsmith II. Communications of the ACM 39, 3 (March 1996), pp. 61–68. [Budde et al. 84] R. Budde, K. Kuhlenkamp, L. Mathiassen, H. Züllighoven (eds.): Approaches to Prototyping. Berlin, Heidelberg: Springer-Verlag, 1984. [Budde et al. 85] R. Budde, K.-H. Sylla, K. Kuhlenkamp, H. Züllighoven: Software-Entwicklungsmethodik für eine Programmierumgebung in Prolog. In: Molzberger, P., Zemanek, G.V. (Hrsg.): Software-Entwicklung: Kreativer Prozeß oder formales Problem. German Chapter of the ACM, Berichte 22, S. 103–116, 1985.



1351

[Budde et al. 87]R. Budde, K.-H. Sylla, K. Kuhlenkamp, H. Züllighoven: Bib – ein Bibliographie-System. Und: Programmentwicklung mit Smalltalk. Und: Ein Erfahrungsbericht über die Arbeit mit Smalltalk. In: H.-J. Hoffmann (Hrsg.), SMALLTALK verstehen und anwenden, München, Wien: Carl Hanser Verlag, 1987. [Budde et al. 89] R. Budde, K.-H. Sylla, K. Kuhlenkamp, H. Züllighoven: Der Entwurf objektorientierter Systeme. Handbuch der modernen Datenverarbeitung, Wiesbaden: Forkel-Verlag, Heft 145, S. 13–24, 1989. [Budde et al. 90] R. Budde, K.-H. Sylla, H. Züllighoven: Objektorientierter Systementwurf. In: LOG IN, Heft 4/5/6 90, München, Wien: Oldenbourg, 1990. [Budde et al. 91] R. Budde, M.-L. Christ-Neumann, K.-H. Sylla, H. Züllighoven: Objektorientierter Entwurf benutzerorientierter Systeme. GI FG 2.1.1, Softwaretechnik-Trends, Bd. 11, H. 3, S. 184–202, August 1991. [Budde et al. 92a] R. Budde, M.-L. Christ-Neumann, K.-H. Sylla: Tools and Materials, an Analysis and Design Metaphor. In: Proceedings of the TOOLS 7, New York, London: Prentice-Hall, 1992. [Budde et al. 92b] R. Budde, M.-L. Christ-Neumann, K.-H. Sylla, H. Züllighoven: Erfahrungen beim objektorientierten Entwerfen und Analysieren. Arbeitspapiere der GMD 653, St. Augustin, Mai 1992. [Budde et al. 92c] R. Budde, K. Kautz, K. Kuhlenkamp, H. Züllighoven: Prototyping. Berlin, Heidelberg: Springer-Verlag, 1992.



1352

[Budde et al. 93] R. Budde, M.-L. Christ-Neumann, K.-H. Sylla, H. Züllighoven: Das Leitbild qualifizierter Arbeit und die Metaphern »Werkzeug« und »Material« für Herstellung und Einsatz von Computeranwendungen. In W. Müller, E. Senghaas-Knobloch (Hrsg.) Arbeitsgerechte Softwaregestaltung, Münster/Hamburg: LIT Verlag, 1993, S. 125–138. [Budde & Züllighoven 90] R. Budde, H. Züllighoven: Software-Werkzeuge in einer Programmierwerkstatt. Berichte der GMD, Nr. 182, München, Wien: Oldenbourg, 1990. [Budde & Züllighoven 92] R. Budde, H. Züllighoven: Software Tools in a Programming Workshop. In: Ch. Floyd, H. Züllighoven, R. Budde, R. Keil-Slawik (eds.): Software Development and Reality Construction. Berlin, Heidelberg: Springer-Verlag, 1992. [Bürkle et al. 92] U. Bürkle, G. Gryczan, H. Züllighoven: Erfahrungen mit der objektorientierten Vorgehensweise in einem Bankenprojekt. InformatikSpektrum, Band 15, Heft 5, Berlin, Heidelberg: Springer-Verlag, 1992, S. 273–281. [Bürkle et al. 93] U. Bürkle, V. Weimer, H. Züllighoven: Prototyping in einem objektorientierten Bankenprojekt. In: H. Züllighoven, W. Altmann, E.-E. Doberkat (Hrsg.): Requirements Engineering ’93: Prototyping. Berichte des German Chapter of the ACM 41, Stuttgart: Teubner, 1993. S. 11–32.



1353

[Bürkle et al. 95] U. Bürkle, G. Gryczan, H. Züllighoven: Object-Oriented System Development in a Banking Project: Methodology, Experience, and Conclusions. In: Human-Computer Interaction, Special Issue: Expirical Studies of Object-Oriented Design, Vol. 10, No. 2 & 3, Hillsdale, New Jersey, England: Lawrence Erlbaum Associates Publishers, 1995, pp. 293–336. [Burkhardt 97] R. Burkhardt: UML – Unified Modelling Language. Bonn: Addison-Wesley, 1997. [Buschmann et al. 96] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal: Pattern-Oriented Software Architecture – A System of Patterns. Chichester, New York: Wiley & Sons Ltd, 1996.

C [CACM 94] Special Issue on Agents. Communications of the ACM 37, 7, July 1994. [Cardelli & Wegner 85] L. Cardelli, P. Wegner: On Understanding Types, Data Abstraction, and Polymorphism. Computing Surveys, Vol.17, No.4, Dec. 1985. [Cook & Daniels 94] S. Cook und J. Daniels: Designing Object Systems. Object-oriented modelling with Syntropy. New York, London: PrenticeHall, 1994.



1354

[Coplien 92] J. Coplien: Advanced C++: Programming Styles and Idioms. Reading, Massachusetts: Addison-Wesley, 1992. [Coplien & Schmidt 95] J. Coplien, D.C. Schmidt (eds): Pattern Languages of Program Design. Reading, Massachusetts: Addison-Wesley, 1995. [Coulouris et al. 94] G. Coulouris, J. Dollimore, T. Kindberg: Distributed Systems – Concepts and Design. Reading, Massachusetts: Addison-Wesley, 2nd Edition, 1994. [Cotter & Potel 95] S. Cotter, M. Potel: Inside Taligent Technology. Reading, Massachusetts: Addison-Wesley, 1995. [Cunningham 95] W. Cunningham: The CHECKS Pattern Language of Information Integrity. In: J. O. Coplien and D. C. Schmidt (Hrsg.): Pattern Languages of Program Design. Reading, Massachusetts: Addison-Wesley, 1995. Chapter 3, pp. 145–156.

D [DeMarco & Lister 91] T. DeMarco, T. Lister: Wien wartet auf Dich! Der Faktor Mensch im DV-Management. München, Wien: Carl Hanser Verlag, 1991. [Dijkstra 68] E.W. Dijkstra: The Structure of the T.H.E. Multiprogramming System. Communications of the ACM, August 1968, Vol. 18, No. 8, pp. 453–457.



1355

[Dittrich et al. 96] Y. Dittrich, J. Heybrock, S. Knickel, A. Löffler, P. von Savigny: Einsatz des World Wide Web zur Unterstützung asynchroner Zusammenarbeit in Softwareentwicklungsprojekten. In: H. Krcmar, H. Lewe, G. Schwabe (Hrsg.) Herausforderung Telekooperation, DCSCW’96, Berlin, Heidelberg: Springer-Verlag 1996. S. 189–203.

E [Engelmann 95] T. Engelmann: Business Process Reegineering. Grundlagen Gestaltungsempfehlungen – Vorgehensmodell. Wiesbaden: Deutscher Universitätsverlag, 1995.

F [Fischer 81] Das neue Fischer Lexikon in Farbe. Frankfurt: Fischer Taschenbuch Verlag, 1981. [Fittkau 98] B. Fittkau: Die Bedeutung von Kundenorientierung in der Softwareentwicklung. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, 1998. [Floyd 84] C. Floyd, R. Budde, K. Kuhlenkamp, L. Mathiassen, H. Züllighoven (Hrsg.): A Systematic Look at Prototyping. In: Approaches to Prototyping. Berlin, Heidelberg: Springer-Verlag, 1984. pp. 1–18.



1356

[Floyd 94] C. Floyd: Software-Engineering – und dann? Informatik Spektrum, Band 17, Heft 1, Berlin, Heidelberg: Springer-Verlag, 1994, S. 29–37. [Floyd 97] C. Floyd: Einführung in die Softwaretechnik. Scriptum zur gleichnamigen Vorlesung, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, Hamburg, 1997. [Floyd et al. 89] C. Floyd, W.-M. Mehl, F. M. Reisin, G. Schmidt, G. Wolf: Out of Scandinavia: Alternative Approaches to Software Design and System Development. Human-Computer Interaction, 4 (1989) 4, Hillsdale, New Jersey, England: Lawrence Erlbaum Associates Publishers, pp. 253–350. [Floyd et al. 89] C. Floyd, A. Krabbel, S. Ratuski, I. Wetzel: Zur Evolution der evolutionären Systementwicklung: Erfahrungen aus einem Krankenhausprojekt. Informatik Spektrum, Band 20, Heft 1, Februar 1997, S. 13–20. [Floyd & Züllighoven 97] C. Floyd, H. Züllighoven: Softwaretechnik. In: P. Rechenberg, G. Pomberger (Hrsg.): Informatik Handbuch. München, Wien: Carl Hanser Verlag, 1997, S. 641–667. [Fowler 97] M. Fowler: Analysis Patterns : Reusable Object Models. Reading, Massachusetts: Addison Wesley, 1997. [Frese 92] E. Frese (Hrsg.): Handwörterbuch der Organisation. Stuttgart: C. E. Poeschel Verlag, 1992.



1357

[Frei et al. 96] F. Frei, M. Hugentobler, A. Alioth, W. Duell, L. Ruch: Die kompetente Organisation. 2. Auflage, Zürich: vdf Hochschulverlag der ETH Zürich, 1996.

G [Gamma 92] E. Gamma: Objektorientierte Software-Entwicklung am Beispiel von ET++. Berlin, Heidelberg: Springer-Verlag, 1992. [Gamma et al. 96] E. Gamma, R. Helm, R. Johnson, J. Vlissides: Entwurfsmuster – Elemente wiederverwendbarer objektorientierter Software. Übersetzung von D. Riehle, Bonn: Addison Wesley, 1996. [Garlan & Perry 95] D. Garlan, D.E. Perry (eds.): Special Issue on Software Architecture. IEEE Transactions on Software Engineering 21, 4 (April 1995). [Gatzhammer & Kyriakides 96] M. Gatzhammer, V. Kyriakides: Konstruktion interaktiver Software nach der Methode WAM in Smalltalk am Beispiel von VisualAge und VisualWorks. Studienarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, 1996. [Görtz 98] Th. Görtz: Abstraktion der GUI-Komponente in einem Framework. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, Januar 1998.



1358

[Goldberg 90] A. Goldberg: Information Models, Views, and Controllers. Dr. Dobb’s Journal, July 1990, pp. 54–61. [Goldberg & Rubin 95] A. Goldberg, K.S. Rubin: Succeeding with Objects: Descision Frameworks for Project Management. Reading, Massachusetts: Addison-Wesley, 1995. [Goldberg & Robson 89] A. Goldberg, D. Robson: Smalltalk-80 – the Language. Reading, Massachusetts: Addison-Wesley, 1989. [Gottlob et al. 96] G. Gottlob, M. Schrefl, B. Röck: Extending Object-Oriented Systems with Roles. ACM Transactions on Information Systems, 14(3), July 1996, pp. 268–296. [Gryczan 96] G. Gryczan: Prozeßmuster zur Unterstützung kooperativer Tätigkeit. Wiesbaden: Deutscher Universitätsverlag, 1996 (DUV: Informatik). [Gryczan et al. 93] G. Gryczan, U. Piepenburg, H. Züllighoven: Erfahrungen mit Industriekooperationen unter Ausbildungsaspekten. In: J. Raasch, Th. Bassler (Hrsg.): Software Engineering im Unterricht der Hochschulen SEUH ’93. Berichte des German Chapter of the ACM 38, Stuttgart: Teubner, 1993. S. 140–150. [Gryczan et al. 96] G. Gryczan, M. Wulf, H. Züllighoven: Prozeßmuster für die situierte Koordination kooperativer Arbeit. In: H. Krcmar, H. Lewe, G. Schwabe (Hrsg.): Herausforderung Telekooperation, DCSCW’96, Berlin, Heidelberg: Springer-Verlag, 1996. S. 89–103.



1359

[Gryczan et al. 97] Gryczan, G., Wiegand, F., Züllighoven, H.: Objektorientierte Dokumenttypen & Prototypen zur Unterstützung kooperativer Tätigkeiten. In: G. Szwillus (Hrsg.): PB97 Prototypen von Benutzungsschnittstellen. Notizen zu Interaktiven Systemen. Heft 19, November 1997, S. 19–26. [Gryczan & Züllighoven 92] G. Gryczan, H. Züllighoven: Objektorientierter Systementwurf: Leitbild und Entwicklungsdokumente. Informatik-Spektrum, Band 15, Heft 5, Oktober 1992, Berlin, Heidelberg: Springer-Verlag, S. 264–272. [Gryczan & Züllighoven 96] G. Gryczan, H. Züllighoven: Objektorientierte Anwendungsentwicklung – Von der maschinen-zentrierten zur menschenorientierten Sichtweise. In: H. Rose (Hg.) Objektorientierte Produktionsarbeit, ISF München, Frankfurt: Campus Verlag, 1996. S. 23–54.

H [Harel 87] D. Harel: Statecharts: A visual formalism for computer systems. Science of Computer Programming, 8/3, 1987, pp. 231–274. [Hartmann 98] A. Hartmann: Softwarekonstruktion nach WAM zur Unterstützung von Kooperation an einem Ort am Beispiel eines Pausenplanersystems. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, 1998. [Hay 96] D. Hay: Data Model Patterns. New York: Dorset House, 1996.



1360

[Heeg 95] G. Heeg: Objektorientierte Systeme. In: Fachseminar Objektorientierung, Systems-Kongreß München: Systems, 1995, S. 81–90. [Heller & Ferguson 94] D. Heller, P. Ferguson: Motif programming manual for OSF/Motif release 1.2. Sebastopol Ca.: O’Reilly, 1994. [Herzwurm et al. 96] G. Herzwurm, A. Hierholzer, W. Mellis (Hrsg.): Kundenorientierte Softwareherstellung. Universität Köln, FB Wirtschaftinformatik, Reihe: Studien zur Systementwicklung, Bd.9, Köln, 1996. [Heybrock et al. 97] J. Heybrock, S. Knickel, A. Löffler, I. Wetzel: Extended World Wide Web Support for Software-Development Projects. In: K. Braa, E. Monteiro (eds.): Proceedings of IRIS 20 »Social Informatics«, Oslo, June 1997. [Hoare 72] C.A.R. Hoare: Notes on Data Structuring. In: O.-J. Dahl, E.W. Dijkstra, C.A.R. Hoare. Structured Programming, London: Academic Press, 1972.

J [Jacobson 92] I. Jacobson: Object-Oriented Software Engineering – A Use Case Driven Approach. Reading, Massachusetts: Addison-Wesley, 1992. [Johnson & Foote 88] R.E. Johnson und B. Foote: Designing Reusable Classes. The Journal of Object-Oriented Programming, 1(2), June/July 1988, pp. 22–35.



1361

[Johnson & Russo 91] R. E. Johnson und V. F. Russo: Reusing ObjectOriented Designs, Department of Computer Science, University of Illinois at Urbana-Champaign, 1991.

K [Kerner 89] H. Kerner (Hrsg.): Rechnernetze nach ISO-OSI. CCITT, Selbstverlag 1989. [Kiczales et al. 92] G. Kiczales, J. des Riverieres, D. G. Bobrow: The Art of the Metaobject Protocol. Cambridge, MA: The MIT Press, 1992. [Kieback et al. 92] A. Kieback, H. Lichter, M. Schneider-Hufschmidt, H. Züllighoven: Prototypen in industriellen Software-Projekten – Erfahrungen und Analysen. In: Informatik-Spektrum, Bd. 15, Nr. 2, 1992. [Kilberth et al. 94] K. Kilberth, G. Gryczan, H. Züllighoven: Objektorientierte Anwendungsentwicklung – Konzepte, Strategien, Erfahrungen. Braunschweig, Wiesbaden: Vieweg Verlag, 2. überarbeitete Auflage, 1994. [Koenig & Moo 97] A. Koenig, B. Moo: Ruminations on C++. Reading, Massachusetts: Addison-Wesley, 1997. [Kofler et al. 93] T. Kofler: Robust Iterators in ET++. Structured Programming, Vol. 14, No. 2, 1993, Berlin, Heidelberg: Springer International, pp. 62–85.



1362

[Kofler et al. 94] T. Kofler, W. Bischofberger, B. Schäfer, A. Weinand: A Poor Man’s Approach to Dynamic Invocation of C++ Member Functions. Technical Report of the UBILAB, 1994. [Krabbel et al. 96a] A. Krabbel, S. Ratuski, I. Wetzel: Requirements Analysis of Joint Tasks in Hospitals. In: Proceedings of IRIS 19 2, 10.–13. August 1996, Lökeberg, Schweden, pp. 733–749. [Krabbel et al. 96b] A. Krabbel, I. Wetzel, S. Ratuski: Objektorientierte Analysetechniken für übergreifende Aufgaben. In: Beiträge der GI-Fachtagung Softwaretechnik ’96 12.–13. September 1996, Koblenz. S. 65–72. [Krabbel et al. 96c] A. Krabbel, I. Wetzel, S. Ratuski: Participation of Heterogeneous User Groups: Providing an Integrated Hospital Information System. In: Proceedings PDC-Conference, Boston, November 13–15, 1996. pp. 241–249. [Krabbel et al. 97a] A. Krabbel, I. Wetzel, S. Ratuski: Anforderungsermittlung für Krankenhausinformationssysteme: Definition von Kernsystem und Ausbaustufen. In: W. Hasselbring (Hrsg.): Erfolgsfaktor Softwaretechnik für die Entwicklung von Krankenhausinformationssystemen. GI/GMDSWorkshop, Universität Dortmund, 20. Februar 1997, Münster: Krehl Verlag, 1997, S. 1–8.



1363

[Krabbel et al. 97b] Krabbel, A., Wetzel, I., Züllighoven, H.: On the Inevitable Intertwining of Analysis and Design: Developing Systems for Complex Cooperations. In: G. van der Veer, A. Henderson, S. Coles (eds.): DIS’97 Designing Interactive Systems: Processes, Practices, Methods, and Techniques. Conference Proceedings, Amsterdam, The Netherlands, August 1997, pp. 205–213. [Krasner & Pope 88] G. Krasner, S. Pope: A CookBook for using the ModelView Controller User Interface in SMALLTALK-80. ParcPlace Systems 2400 GengRoad Palo Alto, CA 94303, 1988. [Krauß 98] T. Krauß: Softwarekonstruktion nach WAM unter Nutzung des MFC Rahmenwerks. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, 1998. [Kristensen & Østerbye 96] B. B. Kristensen und K. Østerbye: Roles: Conceptual Abstraction Theory and Practical Language Issues. In: Theory and Practice of Object Systems, 2(3), 1996, pp. 143–160

L [Lakos 96] J. Lakos: Large Scale C++ Software Design. Reading, Massachusetts: Addison Wesley, 1996. [Lamnek 88] S. Lamnek: Qualitative Sozialforschung. Band 2: Methoden und Techniken. München: Psychologie Verlags Union, 1988.



1364

[Lehman 80] M.M. Lehman: Programs, Life Cycles, and Laws of Software Evolution. Proc. of IEEE, Vol 68, No. 9, Sept. 1980, pp. 1060–1076. [Lehman 90] M.M. Lehman: Uncertainty in Computer Applications is Certain. In: Proceedings of the 1990 IEEE International Conference on Computer Systems and Software Engineering, IEEE, Tel Aviv, May 1990. [Lewis 95] T. Lewis: Object-Oriented Application Frameworks. Greenwich: Manning Publications Co., 1995. [Lichter et al. 94] H. Lichter, M. Schneider-Hufschmidt, H. Züllighoven: Prototyping in Industrial Software Projects – Bridging the Gap Between Theory and Practice. In: IEEE Transactions on Software Engineering, Vol. 20, No. 11, 1994. pp. 825–832. [Lilienthal & Züllighoven 96] C. Lilienthal, H. Züllighoven: Techniques and Tools for Continuous User Participation. In: Proceedings PDC-Conference, Boston, November 13–15, 1996. p. 153–159. [Lilienthal & Züllighoven 97] C. Lilienthal, H. Züllighoven: ApplicationOriented Use Quality, The Tools and Materials Approach. Interactions Magazine, ACM, November+December 1997, Volume IV.6. [Liskov 88] B. Liskov: Data Abstraction and Hierarchy. OOPSLA ’87 Addendum to the Proceedings, ACM SIGPLAN Notices, 23(5), May 1988, pp. 17–34. [Liskov & Wing 93] B. Liskov, J. W. Wing: Family Values: A Behavioral Notion of Subtyping. Technical Report, Carnegie Mellon University, CMUCS-93-187, 1993.



1365

[Lopes 96] C.V. Lopes: Adaptive Parameter Passing. In: K. Futatsugi, S. Matsuoka (eds.): Proceedings of the ISOTAS ’96 Conference, LNCS 1049, Berlin, Heidelberg: Springer Verlag, 1996, p. 118-136. [Luckham et al.95] D. C. Luckham, J. Vera, S. Meldal: Three Concepts of System Architecture. Technical Report CSL-TR-95-674. Stanford, CA: Stanford University, 1995.

M [Maaß 94] S. Maaß: Maschine, Partner, Medium, Welt ... Eine Leitbildgeschichte der Software-Ergonomie. In: H. D. Hellige (Hrsg.). Leitbilder der Informatik- und Computer-Entwicklung. Bremen: artec paper 33. 1994 [Maaß & Oberquelle 92] S. Maaß, H. Oberquelle: Perspectives and Metaphors for Human-Computer-Interaction. In C. Floyd, H. Züllighoven, R. Budde, R. Keil-Slawik (eds.): Software development and reality construction. Berlin, Heidelberg: Springer-Verlag 1992, pp. 233–251. [MacLennan 82] B.J. MacLennan: Values and Objects in Programming Languages. ACM SIGPLAN Notices, Vol. 17, No. 12, Dec. 1982. [Maes & Nardi 88] P. Maes, B. Nardi (eds.): Meta-Level Architectures and Reflection. The Netherlands: North-Holland Publishers, 1988.



1366

[Mätzel & Bischofberger 96] K.-U. Mätzel, W. Bischofberger: Evolution of Object Systems or How to Tackle the Slippage Problem in Object Systems. Computer Science Research at UBILAB, Hrsg.: K.-U. Mätzel, H.-P. Frei, Universitätsverlag Konstanz 1996, pp. 99-117. [Martin et al. 98] R. C. Martin, D. Riehle, F. Buschmann (eds.): Pattern Languages of Program Design 3. Reading, Massachusetts: Addison-Wesley, 1998. [McClain 91] G. R. McClain (ed.): Open Systems Interconnection Handbook. New York: Intertext Publications McGraw-Hill, 1991. [Meyer 91] B. Meyer: Design by Contract. In: D. Mandrioli, B. Meyer (eds.): Advances in Object-Oriented Software Engineering. New York, London: Prentice-Hall, 1991, pp. 1-50. [Meyer 97] B. Meyer: Object-Oriented Software Construction. New York, London: Prentice-Hall, Second Edition, 1997. [Monroe et al. 97] R .T. Monroe, A. Kompanek, R. Melton, D. Garlan: Architectural Styles, Design Patterns, and Objects. IEEE Software, 14(1), January/February 1997, pp. 43-52. [Mühlhäuser 97] M. Mühlhäuser: Verteilte Systeme. In: P. Rechenberg, G. Pomberger (Hrsg.): Informatik Handbuch. München, Wien: Carl Hanser Verlag, 1997, S. 557-588. [Mumford 77] L. Mumford: Mythos der Maschine. Frankfurt/M.: Fischer, 1977.



1367

N [Notkin et al. 93] D. Notkin, D. Garlan, W.G. Griswood, K. Sullivan: Adding Implicit Invocation to Languages: Three Approaches. In: S. Nishio, A. Yonezawa (eds.): Proceedings of JSSST-93, LNCS 742, Berlin, Heidelberg: Springer Verlag,1993, pp. 489-510.

O [Oberquelle et al. 94] H. Oberquelle, E. Eberleh, R. Oppermann: Einführung in die Software-Ergonomie. Berlin, New York: de Gruyter, 1994. [Odell 92] J. J. Odell: Managing object complexity, Part I: abstraction and generalization. Part II: composition. The Journal of Object-Oriented Programming, Vol. 5, No. 5 & 6, September, October 1992. [OMG 93] Object Management Group: Object Management Architecture Guide. Chichester, New York: Wiley & Sons, 1993. [OMG 94] Object Management Group: Common Object Services Specification. Volume 1. Revision 1.0, OMG technical document, 94-01-01, 1994. [OMG 95] Object Management Group: Common Object Request Broker: Architecture and Specification. Revision 2.0, OMG technical dcoument 96-03-04, 1995.



1368

[Ousterhout 94] J. Ousterhout: TCL and the TK toolkit. Reading, Massachusetts: Addison Wesley, 1994.

P [Pagel & Six 94] B.-U. Pagel, H.-W. Six: Software Engineering. Bonn: Addison Wesley, 1994. [Pankoke-Babatz & Syri 96] U. Pankoke-Babatz, A. Syri: Gemeinsame Arbeitsbereiche: Eine neue Form der Telekooperation? In: H. Krcmar, H. Lewe, G. Schwabe. (Hrsg.): Herausforderung Telekooperation: Fachtagung Deutsche Computer Supported Cooperative Work (DCSCW ’96), Stuttgart-Hohenheim, 30.9.-2.10.96. Berlin, Heidelberg: Springer Verlag, 1996, S. 51-67. [Parnas 72] D. L. Parnas: On the Criteria to be Used in Decomposing Systems into Modules. Communication of the ACM, 5(12), December 1972, pp. 1053-1058. [Parnas & Clements 85] D.L. Parnas, P.A. Clements: A Rational Design-Process. How and Why to Fake It. In: M. Nivat, H. Ehrig, C. Floyd, J., Thatcher (eds.): Formal Methods and Software Development, Proceedings of TAPSOFT’85, Berlin, Heidelberg: Springer, März 1985. [Perry 96] R. Perry: The Displayer/Data Pattern-Language: A Software Engineering Technique for GUI/Application Decoupling. Tel Aviv University, Computer Science Dept., November 1996.



1369

[Peters & Waterman 82] T. Peters, R. H. Waterman: In Search of Excellence – Lessons from America’s Best-Run Companies. New York: Harper & Row, 1982. [Piepenburg & Züllighoven 95] U. Piepenburg, H. Züllighoven: Objektorientierte Systementwicklung. In: W. Dzida, U. Konradt (Hrgs.): Psychologie des Software-Entwurfs. Arbeit und Technik 5. Göttingen, Stuttgart: Verlag für Angewandte Psychologie, 1995, S. 45–59. [Pomberger & Blaschek 93] G. Pomberger, G. Blaschek: Software Engineering. München, Wien: Carl Hanser Verlag, 1993 [Pree 95] W. Pree: Design Patterns for Object-Oriented Software Development. Reading, Massachusetts: Addison-Wesley, 1995. [Prinz & Kolvenbach 96] W. Prinz, S. Kolvenbach: Support for Workflows in a Ministerial Environment. In: M. S. Ackermann (ed.): Proceedings of the ACM 1996 Conference on Computer Supported Cooperative Work, Nov. 16-20, 1996, Boston, Massachusetts, USA. New York: ACM Press, 1996, pp. 199–208.

R [Ratuski 97] S. Ratuski: Vorgehensweise zur Auswahl von Standardsoftware am Beispiel von Krankenhausinformationssystemen. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, August 1997.



1370

[Reenskaug et al. 96] T. Reenskaug, P. Wold, O. A. Lehne: Working with Objects. Greenwich: Manning, 1996. [Riehle 95a] D. Riehle: Muster am Beispiel der Werkzeug und Material Metapher. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, April 1995. [Riehle 95b] D. Riehle: How and Why to Encapsulate Class Trees, OOPSLA ’95, Conference Proceedings, pp. 251–264. [Riehle et al. 98] D. Riehle, W. Siberski, D. Bäumer, D. Megert, H. Züllighoven: Serializer. In: [Martin et al. 98], pp. 293–312. [Riehle & Schnyder 94] D. Riehle, M. Schnyder. Design and Implementation of a Smalltlak Framework for thr Tools and Materials Metaphor. Technical Report 95.7.1, UBILAB Zürich, Switzerland: Union Bank of Switzerland, 1995. [Riehle & Züllighoven 94a] D. Riehle, H. Züllighoven: Späte Erzeugung. In: Eberhart Köhler (Hrsg.) 39. Internationales Wissenschaftliches Kolloquium 27.–30.9.1994, Band 1, Technische Universität Ilmenau. S. 39. [Riehle & Züllighoven 94b] D. Riehle, H. Züllighoven: A Pattern Language for Tool Construction and Integration Based on the Tools&Materials Metaphor. In: Proceedings of the First Conference on Pattern Languages of Programs (PLOP ’94), Monticello, Illinois, August 4–6, 1994, Paper B.



1371

[Riehle & Züllighoven 95] D. Riehle, H. Züllighoven: A Pattern Language for Tool Construction and Integration Based on the Tools and Materials Metaphor. In: J.O. Coplien, D.C. Schmidt (eds.): Pattern Languages of Program Design. Reading, Massachusetts: Addison-Wesley, 1995. Chapter 2, pp. 9–42. [Riehle & Züllighoven 96] D. Riehle, H. Züllighoven: Understanding and Using Patterns in Software Development. In: K. Lieberherr, R. Zicari (eds.): Theory and Practice of Object Systems, Special Issue Patterns. Guest Editor: S. Berczuk,Vol. 2, No.1, 1996, pp. 3–13. [Roock & Wolf 96] S. Roock, H. Wolf: Konzeption und Implementierung eines »Reaktionsmusters« für objektorientierteSoftwaresysteme. Studienarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, Mai 1996. [Roock & Wolf 98] S. Roock, H. Wolf: Die Raummetapher zur Entwicklung kooperationsunterstützender Softwaresystem für Organsiationen. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, Januar 1998. [Roock et al. 97] S. Roock, I. Wetzel, H. Wolf, H. Züllighoven: Location as an Analysis and Design Metaphor in Work Settings with Complex Cooperations. In: K. Braa, E. Monteiro (eds.): Proceedings of IRIS 20 »Social Informatics«, Oslo, June 1997. pp. 431–448. [Rubin & Goldberg 92] K.S. Rubin, A. Goldberg: Object Behaviour Analysis. In: CACM, Vol. 35, No.9, September 1992, pp. 48–62



1372

[Rumbaugh et al. 91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: Object-Oriented Modeling and Design. New York, London: Prentice-Hall, 1991.

S [Sebesta 96] R.W. Sebesta: Concepts of Programming Languages. Reading, Massachusetts: Addison-Wesley, 1996. [Shaw & Garlan 96] G. Shaw, D. Garlan: Software Architecture. Perspectives on an emerging discipline. New York, London: Prentice-Hall, 1996. [Shneiderman 83] B. Shneiderman, Direct manipulation: A step beyond programming languages. IEEE Computer, Vol. 16, No. 8, pp.57–69, 1983. [Siberski 95] W. Siberski: Meta-Konzepte in objektorientierten Sprachen – unter besonderer Berücksichtigung von C++. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, September 1995. [Silberschatz & Galvin 94] A. Silberschatz, P.B. Galvin: Operating System Concepts. Reading, Massachusetts: Addison-Wesley, 1994. [Sommerville 92] I. Sommerville: Software Engineering. 4. Auflage, Reading, MA: Addison Wesley 1992. [Star Division 92] Star Division: StarView C++ class library, 1992.



1373

[Streich et al. 83] H. Streich, K.-H. Sylla, H. Züllighoven: Anmerkungen zum Prototyping. In: I. Kupka (Hrsg.): Proceedings der 13. GI-Jahrestagung. Informatik-Fachberichte Nr. 73, Berlin, Heidelberg: Springer Verlag, 1983. [Strunk & Fröse 96] W. Strunk, F. Fröse: Using Design Patterns to Restructure the User Interface Part of an Application Framework. In: K. Lieberherr, R. Zicari (eds.): Theory and Practice of Object Systems, Special Issue Patterns. Guest Editor: S. Berczuk,Vol. 2, No.1, pp. 53–60.

T [Tracz 95] W. Tracz: DSSA (Domain-Specific Software Architecture) Pedagogical Example. Software Engineering Notes, Vol. 20, No. 3, July 1995, pp. 49–62. [Traub 95] H.-P. Traub: Objektorientierte Behälterklassen-Bibliotheken. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, Juni 1995.

W [Wegner 90] P. Wegner: Concepts and Paradigms Of Object-Oriented Programming. OOPS Messenger, Vol.1, No.1, August 1990, pp. 8–87.



1374

[Weinand 91] A. Weinand: Objektorientierter Entwurf und Implementation portabler Fensterumgebungen am Beispiel des Application-Frameworks ET++.Universität Zürich, Dissertation, 1991. [Weinand & Gamma 95] A. Weinand, E. Gamma: ET++ A Portable Homogeneous Class Library and Framework. In: [Lewis95], pp. 154–194. [Weiß 97] U. Weiß: Konzeptionelle und technische Weiterentwicklung eines objektorientierten Frameworks nach der Werkzeug-Material-Metapher. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, 1997. [Weske 96] D. Weske: Objektorientierte Modellierung verteilter, technisch eingebetteter Anwendungssysteme am Beispiel eines Laborinformationsund Steuerungssystems. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, Oktober 1996. [Weske & Wulf 94] D. Weske, M. Wulf: Konzepte zur Materialversorgung verteilter Werkzeugumgebungen am Beispiel der Anbindung einer objektorientierten Datenbank. Studienarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, Juli 1994. [Wetzel et al. 97] I. Wetzel, G. Gryczan, F. Wiegand, H. Züllighoven: Verteilte, objektorientierte Anwendungen für kooperative Arbeit: ein Projektbericht aus dem Bankenbereich. OBJEKTspektrum Nr. 2 März/ April 1998, München: SIGS Conferences GmbH, S. 54–61. [Wirfs-Brock et al. 90] R.J. Wirfs-Brock, B. Wilkerson, L. Wiener: Designing Object-Oriented Software. New York, London: Prentice-Hall, 1990.



1375

[Wulf 95] M. Wulf: Konzeption und Realisierung einer Umgebung zur Koordination rechnergestützter Tätigkeiten in kooperativen Arbeitsprozessen. Diplomarbeit, Universität Hamburg, Fachbereich Informatik, Arbeitsbereich Softwaretechnik, September 1995. [Wulf et al. 96] M. Wulf, G. Gryczan, H. Züllighoven: Process Patterns – Supporting Cooperative Work in the Tools & Materials Approach. In: Proceedings of IRIS 19 1, 10.-13. August 1996, Lökeberg, Schweden. pp. 445–459.

Y [Yonezawa & Smith 92] A. Yonezawa and B. C. Smith (eds.): Proceedings of the International Workshop on New Models for Software Architecture ’92: Reflection and Metalevel Architecture. (IMSA ’92). Japan: November 4–7, 1992.

Z [Zimmermann 96] C. Zimmermann (ed.): Advances in Object-Oriented Metalevel Architectures and Reflection. Boca Raton, FL: CRC Press, 1996. [Züllighoven 92] H. Züllighoven: Umgang mit Software. In: W. Coy et al. (Hrsg.): Sichtweisen der Informatik. Braunschweig: Vieweg, 1992.


Index

1376

Index

A ablaufsteuernde Sichtweise 161, 162, 168 ablaufsteuernder Managementstil 1139 Ablaufvision 1253, 1266, 1275 – fachliche 1266 – technische 1269, 1270 abstrakte Fabrik 988 abstrakte Klasse 110, 112, 114 abstrakte Operation 114 abstrakter Datentyp 93, 98, 101 Adaptermuster 440 Adapterobjekt 448

Index

Index

1377

Administrationsumgebung 621 Adressierbarkeit 59 Agenten 155 Aktuator 1022, 1024, 1026, 1030, 1032 Analyse der Geschäftsprozesse 1186 Analyse und Entwurf 1247 Anbieter 94, 95, 117 Anforderung – ermittelte 294 Anfrage 55, 524 Anlagenmodell 1020, 1022, 1025, 1027, 1028, 1031, 1032 – asynchrones 1030 – synchrones 1029 Anweisung 55, 524 Anwender 1144 Anwendergruppen 287 Anwendungsbereich 309, 310, 329, 674, 678, 697, 740, 741, 742, 1142, 1144 – Analyse 309, 311 – Modell 224, 297, 666, 689, 698 – Modellierung 1311

Index

Index

1378

Anwendungsentwicklung 1135 – objektorientierte 951 anwendungsfachliches Dokument 1140 Anwendungskomponente 1132, 1134 Anwendungsoftware – interaktive 1014 anwendungsorientierte Dokumenttypen 290, 291 anwendungsorientierte Entwicklungsdokumente 276, 277 anwendungsorientierte Software 8 anwendungsorientierte Softwareentwicklung 258, 1138 anwendungsorientierter Dokumente 274 anwendungsorientierter Dokumenttyp 14, 268 anwendungsorientierter Entwicklungsprozeß 265, 271 Anwendungsorientierung 3, 13, 150, 260, 261, 264, 276, 277, 287, 304, 1099, 1107, 1123, 1129, 1144, 1153 Anwendungsrahmenwerk 250 Anwendungsserver 978 Anwendungssoftware 4, 148, 152, 196, 258, 259, 264, 267, 1108 – interaktive 5, 9, 1017 – Modell 733

Index

Index

1379

Anwendungssystem 322, 678, 679, 681, 684, 698, 1148 – Einsatzkontext 679 – interaktives 604, 1047 – Modell 300, 673, 697, 1025, 1027, 1032, 1035, 1036, 1038 – technisch eingebettes 1016 – technisch eingebettetes 1012, 1013, 1016, 1019, 1020, 1030, 1050 Anwendungssystemmodell 1026 Anwendungssystems – Modell 695 Anwendungswissen der Entwickler 286 Anwendungszustand 1018, 1021 Arbeit – kooperative 12, 13, 15, 182, 869 – kooperative 871 Arbeiten – kooperatives 921 Arbeitsgegenstände 170, 180, 685 Arbeitskontext 376 Arbeitskopie 879, 971 Arbeitsmittel 170, 187 Arbeitsplatz 181, 182, 198, 368, 621, 698, 890, 897, 962, 964

Index

Index

1380

Arbeitsplatzsystem – interaktives 1131 Arbeitsplatztyp 698, 1180, 1183 arbeitsteilige Softwareentwicklung 1116 arbeitsteiliger Entwicklungsprozeß 1120 Arbeitsteilung 195, 1115 Arbeitsumgebung 170, 181, 182, 368, 370, 372, 377, 378, 380, 383, 384, 604, 605, 606, 614, 619, 897, 902 – Anforderungen 372 – Ordnungsprinzipien 379 Arbeitszusammenhänge 345 Architektur – rahmenwerkbasierte 1135, 1137 – reflexive 719 Architekturgruppe 1124, 1135, 1136, 1138 Architekturstil 664 Archiv 396, 884, 887, 958, 959, 964, 965, 971 – gemeinsames 884 Archivart 961 Arten des Prototyping siehe Prototyping 1286 Arten von Prototypen siehe Prototypen 1286

Index

Index

1381

Aspekt 420, 423, 426, 427 – Dekorierer 449 – Objektadaptermuster 439 – Schnittstelle 458 – Schnittstellendefinition 457 – Verhaltensspezifikation 427 – Werkzeugunterstützung 466, 476 Aspekt und Einfachvererbung 428 Aspekte 452, 453, 455, 460, 471 Aspektklasse 428, 430, 431, 433, 435, 442, 445, 446, 448, 454, 461, 469 – Namenskonvention 437 Aspektklasse und Subsystem 437 Aspektschnittstelle 426 Aspektvererbung 430, 449, 471 asynchrone Kommunikation 1050, 1062, 1064, 1079, 1091 – Nachteile 1066 – Vorteile 1067 asynchrone Kopplung 1069 asynchrone Prozeßkommunikation 1084 asynchrone Prozeßkopplung 1085 asynchroner Prozeß 1088 asynchrones Anlagenmodell 1030 Auf gabenszenario 1217 Aufbauorganisation 667 Aufgabe 1219, 1318 Index

Index

1382

Aufgaben – kooperative 1316 – übergreifende 921, 925, 1301, 1318 Aufgabenbeschreibungen 1231 Aufgabenszenario 1234 Aufruf einer Operation 55 Ausbaustufe 961, 1132, 1134, 1147, 1148, 1156, 1158 Auswertungsdatenbank 977 Automat 12, 180, 185, 187, 399, 402, 405, 408, 1012, 1033, 1036, 1041, 1044, 1046, 1048, 1050, 1052, 1056, 1068, 1069, 1081, 1082, 1271 – fachliche Funktionalität 185 – groß 185 – großer 407 – klein 185 – kleiner 399, 405 – Kriterien 403 – technischer 409, 1034, 1036, 1038, 1040, 1044, 1046 Automat und Werkzeug 400, 401 Automaten in eigenen Prozessen 1056 Automatenvision 1254, 1283 Automatismen 402

Index

Index

1383

Autor-Kritiker-Zyklen 277, 279 Autor-Kritiker-Zyklus 17, 221, 269, 272, 1097, 1105, 1121, 1138, 1152, 1226, 1256, 1260, 1300 B Basisoperation 114 Bearbeitungszustand 491 Befehlsmuster 556, 557 Begriffsgebäude 107 Begriffshierarchie 61, 73, 77, 79, 298 – fachliche 733 Begriffsmodell 45, 313, 314 Begriffsmodellierung 81 Behälter 189, 380, 387, 388, 389, 390, 394, 395, 616, 972, 977, 1003, 1006, 1281 – Dienstleistungen 391 – fachlicher 189, 390, 391, 394, 625, 629, 645 – Ordnungsprinzipien 394 – polymorphe 393 – technischer 390, 625, 628, 637, 645 Behälter und Datenstrukturen 389 Behälter und Materialien 388

Index

Index

1384

Behälterbibliothek 639, 640, 645 Benachrichtigung 521, 524, 526, 529, 537 Benutzer als Fachleute 192 Benutzerführung 206 Benutzt-Beziehung 82, 85, 87, 93, 95, 300 Benutzungsdokumentation 1246 Benutzungsmodell 69, 147, 150, 317, 330, 374, 380, 382, 384, 682, 1062, 1091, 1270 Benutzungsschnittstelle – grafische 541, 543 Beobachter 517, 518, 521, 537, 538 Beobachtermechanismus 521, 524, 581, 582, 635 – Generalisierung 527 Beobachtermuster 1069 Beobachtermuster für Funktionskomponente und Interaktionskomponente 515 Beobachtung 529 Beobachtungsmechanismus 561, 563, 566, 584 Bestandsliste 884, 885 Bibliothek – dynamische 753 Bibliotheken 756

Index

Index

1385

Binden – dynamisches 55, 86 – spätes 55 bjektorientierte Datenbank 974 Black-box-Rahmenwerk 251, 254 Botschaft 49, 54, 107 Brückenmuster 722, 723 Business Objects 156 Business Patterns 222 Business Process Reegineering 675 Business Process Reengineering 671 C Chain of Responsibility siehe Zuständigkeitskette 815 Client/Server-Anwendungen 725 Client/Server-Architektur 975 Client/Server-Technologie 963 CORBA 975 Cursor 641, 642, 643

Index

Index

1386

D Datenbank 1001, 1008 – objektorientierte 974 – Optimierungsstrategien 1005 – relationale 833, 974 – Transformationsregeln 991 Datenbankanwendung 947 Datenbanken 946, 951, 960, 964 – Anwendungsprofil 953 Datenbankidentifikator 994 Datenbankmanagementsystem 952, 973 Datenbankschema 991 Datenbankteam 948 Datenmenge 949 Datenmodellierung – unternehmensweite 688 Datenquelle 972, 973, 977, 985 Datenschicht 725 Datenstruktur 389, 637 Datentyp 648, 660 – abstrakter 93, 98, 101 Dekorierermuster 450, 453, 455, 473

Index

Index

1387

Demonstrationsprototyp 1288, 1291, 1292, 1295 Design Patterns 225 Dienstleistung 94, 97 Dienstleistungsanbieter 506, 528, 796 Dienstleistungsbündel 427 DIN 66234 262 direkte Manipulation 393 Diskussionsprozeß 1115 DLL siehe Dynamic Link Library 752 Dokument – anwendungsfachliches 1140 – anwendungsorientiertes 274 Dokumentation 274, 275, 295 Dokumentationsrichtlinien 295 Dokumente der Projektsteuerung 295 Dokumenttyp 280, 281, 283, 286, 1108, 1214, 1216 – anwendungsorientierter 14, 268 – Szenario 1216 – technischer 1326 Dokumenttyp Szenario 1232 Dokumenttypen – anwendungsorientierte 290, 291

Index

Index

1388

Dokumenttypen zur Dokumentation 295 Domäne 1144 Downcast 137 Drehbuch 1297, 1313 Drei-Schichten-Architektur 724, 726, 728 Durchsichtigkeit 720 Dynamic Link Library 752 dynamische Bibliothek 752, 753 E Einbettungsvision 1251, 1264, 1266 einfaches Werkzeug 572, 574 Einfachvererbung 75 Einführungsstrategie 1176, 1184, 1189 Einheit von Ort und Zeit 184 Einheit von Raum und Zeit 878, 932 Einheit von Zeit und Raum 885 Einsatzkontext 148, 259, 265, 377, 678, 679, 682, 697, 698, 733,

Index

Index

1389

755, 1183 Einsatzkontextschicht 743 Einschub-Operation 114 Einstellwerkzeug 409, 1044, 1046, 1048, 1052 elektronische Schreibtisch 371 elektronischer Schreibtisch 375 elementarer Fachwert 649 Entwicklerorganisation 1131, 1132, 1134 Entwicklerteam – integriertes 1124 Entwicklungs- und Dokumentationsprozeß 1259 Entwicklungs- und Managementprozeß 1099, 1107 Entwicklungsaktivitäten – Reihenfolge 1110 Entwicklungsbereich 1142, 1145, 1146 Entwicklungsdokument 1107, 1214 – anwendungsorientiertes 276, 277 Entwicklungsdokumente 289 Entwicklungsprozeß 16, 194, 264, 1093, 1099, 1107, 1123, 1214,

Index

Index

1390

1228, 1243, 1244, 1246, 1255, 1295, 1311, 1313, 1324 – anwendungsorientierter 265, 271 – arbeitsteiliger 1120 – evolutionärer 16 – Lern- und Kommunikationsprozeß 16 – Personenunabhängigkeit 267, 1114 Entwicklungsteam 1125, 1170 Entwurf – technischer 234 Entwurfmuster – Body/Handle 658 Entwurfs- und Konstruktionseinheiten 88, 91 Entwurfs- und Kontruktionseinheit 718 Entwurfsdokument 1256 Entwurfskomponenten 228 Entwurfsmetapher 10, 163, 165, 166, 174, 224, 233, 286, 738, 739, 1036 Entwurfsmetapher Arbeitsumgebung 181 Entwurfsmetapher Automat 184 Entwurfsmetapher Behälter 188 Entwurfsmetapher Material 179 Entwurfsmetapher Sonde 1039

Index

Index

1391

Entwurfsmetapher Werkzeug 175 Entwurfsmetaphern 328 Entwurfsmodell 223, 318 Entwurfsmuster 175, 207, 208, 211, 213, 219, 223, 225, 229, 234, 235, 255, 413, 654, 703, 1132, 1137 – allgemeiner Teil 229 – Body/Handle 657 – Fabrik 654 – Fliegengewicht 654 – Rückkopplung zwischen Funktion und Interaktion 504 – Serialisierer 750 – Stellenwert 413 – Trennung von Funktion und Interaktion 479 – Trennung von Handhabung und Präsentation 540 – Trennung von Werkzeug und Material 750 – Werkzeug- und Materialkopplung 418, 749 – Werkzeugkomposition 565 Entwurfsmusterumgebung 603 Ereignis 530, 535, 608, 609 Ereignismuster 536, 538, 581, 582 Ereignismuster für Funktionskomponente und Interaktionskomponente 530 Ereignis-Objekt 536

Index

Index

1392

Ereignisquelle 1035, 1037, 1044, 1048 Ereignisverwalter 605, 607, 608 ermittelte Anforderung 294 Evolutionäre Systementwicklung 273 evolutionäre Systementwicklung 13, 273, 1093, 1131 evolutionäre Vorgehensweise 281, 1107 evolutionärer Entwicklungsprozeß 16 evolutionäres Vorgehensmodell 1105 Exemplar 50, 51, 63, 99, 102, 105, 107, 111, 121, 391 Expertentätigkeit 168 explizite Kooperation 873, 888, 889, 900 explizites Kooperationsmodell 904 F Fabrik – abstrakte 988 Fabrikmethode 801 fachliche Ablaufvision 1266, 1268 fachliche Begriffshierarchie 733 Fachliche Behälter 627 fachliche Behälter 189, 625

Index

Index

1393

fachliche Identität 764, 772, 787 fachliche Integration 1128, 1130 fachliche Modellierung 76, 233, 666 fachliche Transparenz 881, 882 fachlicher Behälter 390, 391, 629 fachliches Modell 147, 152 Fachsprache 76, 194, 265, 309, 312, 688, 1218, 1241, 1243, 1245, 1246 Fachwert 547, 548, 550, 556, 647, 648, 650, 651, 653, 656, 660, 798, 800, 1039, 1041, 1043 – elementarer 649 – zusammengesetzter 649 Fachwerte 129, 132, 133, 352 Fehlerbehandlung 1086, 1090 Festpreisprojekt 1127 Finanz- und Dienstleistungsunternehmen 671 friend-Konstrukt 80 Funktion 54, 56 funktionale Schicht 725 Funktionalität 261 Funktionalität eines Werkzeugs 356 funktionelle Prototypen 1289, 1290, 1295

Index

Index

1394

funktionelle Rolle 1233 Funktionsarbeitsplatz 199, 201, 406, 407, 1181 Funktionskomponente 483, 491, 578, 608, 610, 661 – Handhabung und Präsentation 494 – Zuständigkeit 491 Funktionskomponente und Interaktionskomponente – Beobachtermuster 515 – Ereignismuster 530 G Gebrauchsqualität 8, 193, 260, 262, 267 Gegenstandsbereich 684, 687, 689, 691, 694, 696, 697, 700, 712, 714, 716, 720, 722, 734, 741, 745 Gegenstandsbereichsschicht 739, 748 Geheimnisprinzip 59, 91 Generalisierung 44, 62, 73, 81, 107, 298, 527 Generalisierung und Spezialisierung 711, 720 generische Operation 64, 66, 68, 949 Gesamtvision 1261 Geschäftsprozeß 1182, 1184, 1185 Geschäftsprozesse 1188, 1189, 1197

Index

Index

1395

Gestaltung 147 Gestaltungsrichtlinien 149, 296 Glossar 14, 290, 313, 1237, 1239, 1243, 1244, 1246 Glossareintrag 1237, 1239, 1243, 1245 – Struktur 1239 grafische Benutzungsschnittstelle 541, 543 große Softwaresysteme 696 großes Softwaresystem 666 Gruppenarbeitsplatz 202, 928 H Handgepäck 934, 937, 981 Handhabung 147, 151, 261, 481 Handhabung und Präsentation 327, 328, 330, 351, 480, 590, 733, 745 Handhabungs- und Ablaufvision 1251 Handhabungs- und Präsentationsschicht 738, 739, 748 Handhabungsvision 1266, 1270, 1272, 1275 Handlungsstudie 1217 Handwerkszeug 421 horizontale Auffächerung 998

Index

Index

1396

I Identität 60, 122 – fachliche 60, 72, 82, 447, 764, 772, 787 – technische 60, 72, 447, 764, 772, 783, 787 Implementierungsmodell 318 implizite Kooperation 873, 876, 884 – Merkmale 876 Infrastruktur – technische 1206 Inhaltsverzeichnis 188, 628, 630, 633, 635, 1006 Insourcing 1125, 1127 Integration – fachliche 1128, 1130 – organisatorische 1125 integriertes Entwicklerteam 1124 integriertes Team 1130 Interaktion 147 Interaktion und Funktion 480 Interaktions- und Funktionskomponente 531 Interaktionsdiagramm 1078, 1329, 1333 Interaktionskomponente 484, 486, 488, 541, 544, 547, 548, 553, 555, 557, 560, 563, 579, 584, 660

Index

Index

1397

Interaktionskomponente und Funktionskomponente – Aufgabenteilung 489 – Entwicklung 493 – Trennung 493 Interaktionstyp 484, 487, 541, 547, 548, 550, 552, 553, 555, 557, 560, 563, 661, 799, 800, 802 interaktive Anwendungsoftware 1014 interaktive Anwendungssoftware 5, 9, 1017 interaktives Anwendungssystem 604, 1047 interaktives Arbeitsplatzsystem 1131 Interprozeßkommunikation 1078, 1080, 1088 Interview 1161, 1221, 1223, 1224, 1226, 1230 Interviewleitfaden 1223 Invarianten 93, 97 Ist- und Sollabgleich 1108 Iterator 641 K Kapselung 48, 59 Käufermarkt 676 Kernkonzept 776, 778, 780, 783, 785, 787, 789

Index

Index

1398

Kernobjekt 769, 770, 772, 777, 779, 782, 787, 792 Kernobjekte 769 Kernsystem 1132, 1147, 1148, 1152, 1154, 1156, 1158 – minimales 1156, 1158 Klasse 61 – abstrakte 110, 112, 114 – interne Schnittstelle 66, 68 – Oberklasse 62, 73, 78, 85, 111 – Unterklasse 62, 73, 85, 112 Klasse und Typ 104, 106, 107 Klassenbibliothek 703, 718, 722, 736, 818 Klassenbibliotheken 245, 704 Klassenbiliothek 710 Klassendiagramm 1327 Klassenhierarchie 104, 105, 107, 109, 248 Klasseninvarianten 95 Klassenmodell 300 Klient 94, 95, 117, 506, 528, 796 Klient-Anbieter-Modell 804

Index

Index

1399

Kohäsion 89 – maximale 87 – maximierte 89 – minimale 87 Kombi-Werkzeug 571, 576, 584, 588, 590, 591, 593 Kommunikation – asynchrone 1050, 1062, 1064, 1079, 1091 – synchrone 1058, 1062 Kommunikation und Kooperation 123 Kommunikations- und Lernprozeß 1109, 1220 komplexe Kooperation 928 komplexe Kooperationsformen 920 komplexe Materialien 636 komplexes Werkzeug 567 Komponenten 701, 705, 718, 736, 743, 744, 1153, 1157 – Kombinationsregeln 703 Komponentenvision 1251, 1274 Komposition 44, 299 Konfigurationsbeschreibung 819 Konsistenzprüfung 379, 394 Konsistenzprüfungen 382 Konstruktionsansatz 219, 229, 231, 236

Index

Index

1400

Konstruktionskomponenten 318 konstruktive Qualitätssicherung 279, 1109 Kontext – technischer 1019, 1020 Kontexte der Softwareentwicklung 302, 329 Kontext-Funktionskomponente 576 Kontext-Werkzeug 572, 573 Konzept- und Realisierungsteil 816 Konzept von Material und Kopie 621 Konzeptionsmuster 211, 212, 214, 219, 220, 222, 229, 234, 235, 338, 339 – Zusammenhang von Werkzeug und Material 481 Konzeptteil 754, 758 Kooperation 869 – explizite 873, 888, 889, 900 – implizite 873, 876, 884 – komplexe 928 – Merkmale 871 Kooperation und Koordination 189, 190, 384, 391, 872, 931 Kooperationsbeziehung 1303 Kooperationsbild 923, 957, 1301, 1310, 1312, 1313 Kooperationsbilder 15, 926, 1302, 1304, 1306, 1308, 1318, 1323 Kooperationsform 962

Index

Index

1401

Kooperationsformen – komplexe 920 Kooperationsmedium 874, 885, 890, 891, 895, 900 Kooperationsmittel 873, 884 Kooperationsmodell 870 – explizites 904 Kooperationsmodelle 873 kooperative Arbeit 12, 13, 15, 182, 869, 871 kooperative Aufgaben 1316 kooperative Materialbenutzung 966 kooperatives Arbeiten 921 Koordination 872, 895 Koordination und Kooperation 919 Kopplung 89 – asynchrone 1069 – lose 117, 515, 516, 527, 545, 556, 577, 703, 762, 796 – minimierte 89 Kopplung von Rahmenwerken 256 Korrektheit von Software 92 kovariante Redefinition 104 Kriterien – für Automatisierung 404 Kundenorientierung 1, 3, 677, 678, 1129, 1130, 1178, 1179, 1181

Index

Index

1402

L Laborinformations- und Steuerungssysteme 1015 Labormuster 1289, 1291, 1292 Laufzettel 915, 917, 919 Leistungsanbieter 93 Leitbild 10, 151, 153, 233, 286, 328, 738, 739 Leitbild Arbeitsplatz für eigenverantwortliche Expertentätigkeit 167, 170, 171 Leitbild direkte Manipulation von Arbeitsgegenständen 156 Leitbild Fabrik 158, 161 Leitbild Funktionsarbeitsplatz für eigenverantwortliche Expertentätigkeit 198 Leitbild Gruppenarbeitsplatz für eigenverantwortliche, kooperative Aufgabenerledigung 202 Leitbild in der Softwareentwicklung 152 Leitbild Objektwelten 154 Leitbild Selbstbedienungsautomat 204 Lern- und Kommunikationsprozeß 1324 LIS siehe Laborinformations- und Steuerungssysteme 1015 löschen von Objekten 601 lose Kopplung 117, 515, 527, 545, 556, 577, 703, 762, 796 losen Kopplung 516 M Makrostruktur 663, 668, 673, 675, 676, 684, 697

Index

Index

1403

Makrostrukturen 304 Management 1138 Managementprozeß 1099, 1109, 1138, 1140, 1142, 1145 Managementstil – ablaufsteuernder 1139 – unterstützend 1139 – unterstützender 1140 Material 11, 171, 177, 179, 180, 342, 344, 345, 347, 349, 351, 388, 420, 422, 423, 437, 606, 614, 619, 620, 627, 629, 887, 910, 1044, 1057, 1280 – Arbeitsgegenstand 344 – fachliche Funktionalität 349 – generische Operationen 352 – Interaktion 351 – komplexes 636 – konkurrierenden Zugriff 878 – Nachladen 632 – Original und Kopie 621 – Präsentation und Handhabung 349 – Schnittstelle 423 – Umgang 351 – Werkzeug 344 Materialablage 974, 979, 985, 987, 988

Index

Index

1404

Materialableger 990, 991, 993, 1000, 1001, 1010 Materialaustausch 888, 897 Materialbenutzung – kooperative 966 Materialdarstellung 363 Materialentwurf 348, 494 Materialien 635, 884, 885 Materialklasse 431, 433, 438 Materialkoordinator 619, 621, 968, 971 Materialmagazin 616 Materialmanager 968 Materialsammlung 616 Materialschnittstelle 422, 426, 446 Materialtransport 396 Materialveränderung 624 Materialversorger 616, 617 Materialversorgung 621, 624 Materialverwalter 615, 617, 622, 623 Materialverwaltung 604, 613, 615 Materialvision 1253, 1280, 1282 Materialzustand 350, 351, 433 Mehrfachvererbung 75, 77, 109, 437 Mehrprozeßraum 1058, 1068, 1071, 1076, 1083, 1087, 1089, 1091 Meilensteindokument 282, 1100, 1115, 1142 Meilensteindokumente 275 Index

Index

1405

Meßwert 1039, 1040 Metaklasse 135 Metaobjekt 135 Meta-Objektprotokoll 460 Metaobjekt-Protokoll 134, 135, 847 Metapher – allgemein 163, 164 Methode 19 Methodenarbeit 229 Methodenbegriff 18 Methodenrahmen 20 Mikroarchitektur 225 Mikroelemente 304 Modell – Anlagenmodell 1028 – fachliches 46, 147, 152 – technisches 46 Modell der Anwendungssoftware 733 Modell der Softwareentwicklung 233, 307, 332 Modell der Unternehmensorganisation 667 Modell des Anwendungsbereichs 224, 297, 309, 313, 318, 666, 689, 698 Modell des Anwendungssystems 300, 317, 319, 322, 326, 673, 695, 697, 1025, 1027, 1028, 1032, 1035, 1036, 1038 Modellarchitektur 662, 664, 668, 673, 675, 702, 705, 709, 718, 734 Index

Index

1406

Modellierung – fachliche 76, 233, 666 Modellierung des Anwendungsbereichs 1311 Modellierungseinheit 305, 664, 676, 679, 682, 687, 697, 701 Modellierungseinheiten 306 Modularisierung 83, 88 Modularisierungsprinzip 673 MOP siehe Metaobjekt-Protokoll 135, 138, 142 Multitasking – preemptives 1064 Muster 210 – allgemein 209 – Anwendungsorientierung 217 – Einteilung 219 – Form 211 – Kontext 213, 238, 240, 241 – Umfang 215 – Verständlichkeit 216 – Zusammenhang von Werkzeug und Material 342 – Zweck 211 Musterbeschreibungen 242, 244 Musterform 242 Mustersammlungen 238

Index

Index

1407

N Nachbedingungen 93, 95, 97 Nachladen von Materialien 632 Nachricht 54 Nameserver 1074 O Oberklasse 78, 111

Index

Index

1408

Objekt 46, 49, 120, 122 – als Anbieter 53 – als Klient 53 – Benutzt-Beziehung 53 – Dienstleistung 52 – Erzeugen 69 – Identität 48 – Löschen 70 – löschen 601 – Schnittstelle 52, 54 – Transfomieren 71 – Typ 48, 50, 105 – Verhalten 47, 59 – Zustand 48, 51, 55 Objektadapter 441, 442, 444, 446 Objektadaptermuster 472 Objektdiagramm 1328 Objekterzeugung 796, 801, 808, 817, 820, 849 Objektidentifikator 993 Objektidentität 59 – Adressierbarkeit 59 Objekt-Metamodell 38, 39, 41, 674, 732 objektorientierte Anwendungsentwicklung 951

Index

Index

1409

objektorientierte Schicht 733 objektorientierte Schichtenarchitektur 711, 713, 719, 720 objektorientierte Softwareentwicklung 258, 946 objektorientierter Programmierstil 127 Objektorientierung – Begriffsgerüst 38 Objektprinzip 669, 673, 675, 676 Objektzustand 140 Offen-Geschlossen-Prinzip 91, 245, 695, 713, 714, 719, 742, 797 Operation 49, 54 – abstrakte 114 – Aufruf 55 – Basisoperation 114 – Einschub-Operation 114 – generische 64, 66, 68, 949 – Schablonenoperation 114 Operation abstrakter Klassen 114 Ordnungsprinzipien 394 Organisa tionsprinzipien für Unternehmen 672 Organisationsentwicklung 1131, 1324 Organisationsform 676 Organisationsmodell 668

Index

Index

1410

Organisationsstruktur 671, 678 organisatorische Integration 1125 Organsiationsstruktur 666 Original und Kopie 881, 886, 962 Ortsbegriff 368, 372 OSI-Referenzmodell 705, 708 P Pausenplan-Beispiel 29 Perfect-Synchrony-Model 1029 Persistenz 887, 945, 1011 Persistenzanbieter 973, 980, 981, 987 Persistenzkontext 973, 981, 985, 987 Persistenzmechanismus 832 Persistenzmedien 614 Persistenzmedium 970, 972, 973, 975, 977, 979, 980, 981, 986 Persistenzraum 959, 962, 972, 973, 974, 976, 984, 985, 987 Persistenzsimulator 980, 986 Personalqualifizierung 1197 Personenunabhängigkeit 1114, 1115, 1124

Index

Index

1411

Personenunabhängigkeit des Entwicklungsprozesses 267 Phasenmodell 1100, 1114, 1142 Pilotorganisationen 288 Pilotsystem 288, 1162, 1289, 1290 Pläne 169 Planungsdokument 1140 Polling 511 Polymorphie 83, 85, 137 – eingeschränkte 85 – uneingeschränkte 85 Postfach 891, 893 Postkorb 895, 897, 899, 958, 959, 965, 971 Postversand 900 Postversandsystem 900, 917 Prädikat 57, 95 Präsentation 147, 481 preemptives Multitasking 1064 Primäraufgabe 672 Primäraufgaben 671 Produktbereich 674, 676, 678, 683, 684, 687, 689, 691, 694, 696, 698, 711, 714, 716, 734, 755, 764 Produktbereichsschicht 742, 743, 748

Index

Index

1412

Produktdistanz 199 Produktentwicklung 1134 Produkthändler 795, 807, 808, 813, 820, 824 – Konfiguration 828 Produktplanung 1137 Programmbibliothek 752 Programmereignis 487, 547 Programmiermuster 219, 231, 234 Programmierrichtlinien 296 Programmiersprache – klassenbasierte 42 – objektbasierte 42 – objektorientierte 42 Programmierstil – objektorientierter 127 – wertorientierter 126 Projektauftrag 293 Projektdokumente 293 Projektetappe 1163, 1165, 1169, 1170 Projektkontrolle 1140 Projektkultur 276, 277 Projektmanagement 1107

Index

Index

1413

Projektplanung 1109, 1139, 1147, 1148, 1150, 1153, 1163, 1164, 1166 Projektplanung und- management 1093 Projektsprache 1237 Projektsteuerung 1139 Projektteam 1123, 1133, 1146 Projektziel 1150 Protokoll 57, 98, 435, 708, 710 protokollbasierte Schicht 733 protokollbasierte Schichtenarchitektur 707, 709, 710, 720, 728 Prototyp 15, 288, 1108, 1161, 1172, 1285, 1288, 1294 Prototypen 1291, 1295, 1297, 1298, 1299 – Demonstrationsprototyp 1287 – funktionelle 1289, 1290, 1295 – funktioneller Prototyp 1287 – Labormuster 1287 – Pilotsystem 1287 Prototyping 494, 1093, 1108, 1272, 1294, 1313 – evolutionäres 1286 – experimentelles 1286 – exploratives 1286 Proxy-Muster 1070, 1073

Index

Index

1414

Prozedur 54, 56 Prozeß – asynchroner 1088 – technischer 1016 Prozeßgrenze 964 Prozeßkommunikation – asynchrone 1084 Prozeßkopplung – asynchrone 1085 Prozeßmuster 913, 915 Prozeßorientierung 672 Prozeßprinzip 671 Prozeßtrennung 1055, 1071 Prozeßverkettung 199 Q Qualitätssicherung 1109 – konstruktive 279, 1109, 1163, 1170

Index

Index

1415

R Rahmenwerk 5, 207, 226, 245, 248, 249, 256, 437, 701, 703, 710, 718, 722, 736, 742, 745, 752, 754, 756, 759, 818, 1133, 1136 – Black-box 251, 254 – Kopplung 256 – White-box 253, 254 Rahmenwerk und Muster 248 Rahmenwerkarchitektur 1132 rahmenwerkbasierte Architektur 1135, 1137 Raumbegriff 183 Raummetapher 929, 931 – erweiterte 931, 935, 936, 944 Raumplan 932, 936 Reaktionsmechanismus 528, 531, 597, 599, 607, 624 reaktives System 484 Realisierungsteil 754, 758 Redefinition – kovariante 104 referentielle Transparenz 126, 127, 133 Referenzdatenbank 978 Referenzlinie 1170, 1172, 1174

Index

Index

1416

Referenzsemantik 84, 118, 133, 648 reflexive Architektur 719 relationale Datenbank 833, 974 – Anbindung 989 Remote Procedure Call 1059 Replikatdatenbank 955 Request 1047 Rolle 81, 769, 900 – Benutzer 191 – Entwickler 194 – funktionelle 1233 – Organisatoren 195 – Planer 195 – Produktentwickler 195 Rollen objekt 782 Rollen von Rollen 785 Rollenhierarchie 788 Rollenkonzept 719, 776, 777, 778, 780, 783, 785, 792 Rollenmuster 749, 763, 772, 778 Rollenobjekt 769, 770, 772, 777, 779, 784, 787, 792 Rollenverteilung 153, 157, 191 Routine 54 routinisierte Zusammenarbeit 910 – Unterstützung 904

Index

Index

1417

RPC siehe Remote Procedure Call 1059 Rückkopplung 606 Rückkopplung zwischen Interaktionstypen und Interaktionskomponente 553 Rückkopplung zwischen Sub-Funktionskomponente und KontextFunktionskomponente 575 Rückkopplung zwischen Sub-Interaktionskomponente und KontextInteraktionskomponente 583 Rückkopplungsproblem 495, 515, 577, 578 Rückkopplungszyklus 1110, 1127 Runtime Type Information 137 S Sammlung 630 – anwendungsfachlich 388 – von Materialien 392 saveless-Modell 977 Schablonenmethode 67 Schablonen-Operation 435 Schablonenoperation 114

Index

Index

1418

Schicht 718, 720 – funktionale 725 – objektorientierte 733 – protokollbasierte 733 –Durchsichtigkeit 720 Schichtenarchitektur 705, 709, 730, 760 – objektorientierte 711, 713, 719, 720 – protokollbasierte 707, 709, 710, 720, 728 – Regeln 744 – Vererbung 713 Schnittstelle 49, 54, 90, 98, 99, 102, 106, 111, 112, 114, 116 – bekannte 458 – benannte 106, 107, 109 Schnittstellen – bekannte 460 Schnittstellendefinition – benannte 475 Schulungskonzepte 1200 Selbstbedienungsautomat 204 Sensor 1022, 1024, 1026, 1030, 1032 Serialisierer 832, 1009 Serialisierermuster 837, 842

Index

Index

1419

Serialisierung – unvollständige 845 – vollständige 845 Serialisierungsstrategie 851 Sichtbarkeit 48 Sichtweise 20 – ablaufsteuernde 161, 162, 168 – unterstützende 167, 168 Signalmechanismus 887 Signatur 49, 51 Software – anwendungsorientierte 8 – Korrektheit von 92 – Umgang 327 Software Engineering 1115 Softwarearchitektur 208, 225, 263, 663, 664, 666, 673, 676, 700, 702, 704 Softwareentwicklung 148, 151, 161, 162, 233, 264, 269, 297, 1095, 1116, 1142, 1147 – anwendungsorientierte 258, 1138 – arbeitsteilige 1116 – Kontexte 302 – Modell 233, 307 – objektorientierte 258, 946

Index

Index

1420

Softwareentwicklung als Lern- und Kommunikationsprozeß 267 Softwareentwicklungsprozeß 1285 Software-Fabrik 161 Softwarematerial 180 Softwareprojekt 1097, 1163 Softwareprojekte 1095 – Merkmale 1095 Softwaresystem – Funktionalität 261 – großes 666, 696 – Handhabung 261 Softwarewerkzeug 177, 178, 421 Sonde 409, 1038, 1040, 1043, 1044, 1069 Sondierung 176 Speicherautomat 410 Speicherung von Exemplarvariablen 143 Spezialisierung 44, 73, 82, 107, 298 Spezialsystem 1152, 1154 Spezifikation und Implementation 110, 111 Spezifikationsobjekt 804 Spiralmodell 1103 statische Bibliothek 752

Index

Index

1421

Steuerungsautomat 1035 Steuerungsmodell 1030, 1032 Strukturähnlichkeit 9, 45, 263, 300, 304, 673, 674, 1292 Sub-Funktionskomponente 576 Subjekt 772, 776, 784 Subjektidentität 782, 787 Subsystem 456 Subtyp 102, 103 Sub-Werkzeug 572, 573, 588, 590 – Erzeugung 587 synchrone Kommunikation 1058, 1062 – Nachteile 1060 synchrones Anlagenmodell 1029 Synchronizität 1028, 1032 System – technisch eingebettetes 1219 – technisches 197 Systembasis 259, 322, 325, 326, 722, 732 Systembasisschicht 735, 737, 740 Systemeinführung 1209 Systementwicklung – evolutionäre 13, 273, 1093, 1131 Systemereignis 487, 547

Index

Index

1422

Systemvision 14, 318, 1247, 1249, 1253, 1254, 1255, 1257, 1260, 1299 Systemvisionen 290 Szenario 14, 1161, 1216, 1217, 1220, 1221, 1228, 1229, 1313, 1323 Szenarios 290, 313 S-, P- und E-Programme 1118, 1121 T Team – integriertes 1130 Technik – verwendete 323, 324, 329 technisch eingebettetes Anwendungssystem 1012, 1013, 1016, 1019, 1020, 1030, 1050 technisch eingebettetes System 1219 technische Ablaufvision 1269, 1270 technische Behälter 625, 637, 645 – Klassifikation 639 technische Dokumenttypen 1326 technische Identität 447, 764, 772, 782, 787 technische Infrastruktur 1206

Index

Index

1423

technische Prozesse 1016 technische Transparenz 881 technischer Automat 1034, 1036, 1038, 1040, 1044, 1046 technischer Behälter 390, 628 technischer Entwurf 234 technischer Kontext 1019, 1020 technisches System 197 Technologie 732 Technologiebereich 722, 745, 1142, 1144 Technologiegestaltung 198, 200, 204, 206 Technologieschicht 737, 740, 748, 750 Telefoniesystem 1053, 1054 Terminplanung 1175 Test 56, 524 Thread 1063 Three Tier Architecture 725 Toolkit 543, 544, 547, 550, 551 T-Prototyp 1291 Transaktionskonzept 952

Index

Index

1424

Transparenz 877, 881 – fachliche 881 – referentielle 126, 127, 133 – technische 881 Trennung von Interaktion und Funktion 479 Typ 48, 98, 99, 101, 105 – dynamischer 50 – statischer 50 – Subtyp 102 – Suptyp 103 – Verhalten 99 Typ eines Objekts 105 Typbegriff 132 Typdeklaration 108 Typhierarchie 102, 103, 105, 107, 109, 714, 716 Typkonzept 99 Typ-Subtypbeziehung 431 U Überblicksszenario 1217, 1233, 1234, 1263 Überblicksvision 1250, 1253, 1262

Index

Index

1425

übergreifende Aufgaben 921, 925, 1318 – Merkmale 926, 928 Umgang mit Software 327 Umgangsform 312 Umgebung 610, 981, 986, 1048, 1086 Umgebungsbegriff 929 Unterklasse 112 Unternehmen – Organisationsprinzipien 672 Unternehmensorganisation 675 – Modell 667 unternehmensweite Datenmodellierung 688 unterstützende Sichtweise 167, 168 unterstützender Managementstil 1140 Unterstützung von routinisierter Zusammenarbeit 904 V Veränderung 176 Verbindungsstück 701, 703, 718 Verbindungsstücke 744

Index

Index

1426

Vererbung 73, 77, 78, 111, 436, 713, 718 – Einfachvererbung 75 – Einschränkung der Schnittstelle 79 – Mehrfachvererbung 75 Vererbungsbeziehung 85 Vererbungshierarchie 109 Verhaltensähnlichkeit 102, 103, 105, 109 Verhaltensgleichheit 102, 103 Verkopplung von Mensch und Maschine 198 Verrichtungsprinzip 668, 672 Versandautomat 898, 899, 902 Versandsystem 958 Vertrag 293 Vertragsmodell 92, 93, 95, 97, 107, 350, 358, 428, 1087 Vertragsverletzungen 97 verwendete Technik 323, 324, 329 Vorbedingungen 93, 95, 97 Vorgang 381 Vorgänge 189 Vorgangsbearbeitung 906, 910, 917, 919 Vorgangsmappe 902, 916 Vorgangssteuerungssysteme 905

Index

Index

1427

Vorgehensmodell 1094, 1096, 1100, 1102, 1105 – evolutionäres 1105 Vorgehensweise – evolutionäre 281, 1107 W WAM-Ansatz 19, 21, 41, 129, 190, 233, 263, 280, 283, 297, 349, 390, 664, 738, 1012, 1039, 1046, 1336, 1337 WAM-Architektur 963 WAM-Entwurfsmuster 416 WAM-Konzeptionsmuster 338, 341 – Hierarchie 341 WAM-Leitbilder 197 WAM-Modellarchitektur 700, 702, 729, 744, 746, 751, 800 Wasserfallmodell 1100, 1101 Werkstattbesuche 1296 Werkzeug 11, 171, 175, 176, 180, 342, 344, 345, 347, 355, 357, 401, 420, 422, 423, 566, 594, 605, 607, 1044, 1050, 1056, 1068,

Index

Index

1428

1069, 1083, 1270, 1274 – einfaches 572, 574 – Einstellungen 362 – fachliche Funktionalität 176 – Funktion 482 – Funktionalität 356 – Gestaltungsmerkmale 361 – Größe 358 – Handhabung 176, 178, 361 – Interaktion 482 – Kombi 571, 576, 584, 588, 590, 591, 593 – komplexes 568 – Kontext 572, 573 – Sub 572, 573, 588, 590 – Umgang 176 Werkzeug und Automat 1075 Werkzeug und Material 505 Werkzeug & Material-Ansatz 9 Werkzeugabschluß 592 Werkzeuge in eigenen Prozessen 1056 Werkzeuge und Szenarios 359 Werkzeugentwurf 355, 359, 367 Werkzeuggedächtnis 483, 598

Index

Index

1429

Werkzeuggestaltung 362 Werkzeugklasse 431, 438, 595 Werkzeugkomponente 571 Werkzeug-Objekt 566, 593, 596, 967 Werkzeugobjekt 967 Werkzeugvision 1254, 1274, 1275, 1283 Werkzeugzustand 358 Wert 120, 121, 123, 124, 128, 133 Wert und Objekt 119 wertorientierter Programmierstil 126 Wertsemantik 118, 130, 648, 653, 657, 659, 661 Werttypen 128, 129 White-box-Rahmenwerk 253, 254 Workflow-Management-System 163 Workflow-Management-Systeme 905 Wozu-Tabelle 1316, 1318, 1320, 1322, 1325 Wozu-Tabellen 926 Wurzelkonzept 787

Index

Index

1430

Z Zeitabschätzung 1161, 1162 Zielsetzung 1148, 1149, 1150 zusammengesetzter Fachwert 649, 650 Zusicherung 92, 94, 100, 105 Zuständigkeitskette 566, 598, 600, 815 Zustandsänderung 537, 538 Zustandsautomat 539 Zustandsmodell 1017, 1019 Zustandsraum 1044 Zustandsrepräsentation 139

Index

Das objektorientierte Konstruktionshandbuch

Objektorientierte Softwareentwicklung mit Smalltalk (Objekttechnologie)

Objektorientierte Modellierung zur geodätischen Deformationsanalyse German

Objektorientierte Programmierung in Java : professionell einsteigen

Objektorientierte Programmierung spielend gelernt: mit dem Java-Hamster-Modell

Unternehmensmodellierung: Objektorientierte Theorie und Praxis mit UML 2.0 (German Edition)

Objektorientierte Systementwicklung. Vom Geschäftsprozess zum Java-Programm GERMAN

Objektorientierte Datenbanken: Die C++-Anbindung des ODMG-Standards (Objekttechnologie)

Unternehmensmodellierung Objektorientierte Theorie und Praxis mit UML 2.0

Das Feuer, das Schwert und das Paradies

Das Auge und das Schwert

Das Eichhorn und das Nashörnchen

Das Leben und das Schreiben

Das Seiende und das Wesen

Das Leben und das Kino

Das Seiende und das Wesen

Das Auge und das Schwert

Das Auge und das Schwert

Das Geschehen und das Schweigen

Das Auge und das Schwert

Das Geschlecht, das nicht einkauft

Das Eichhorn und das Nashörnchen

Das Leben Und Das Schreiben

Geschaftsprozessanalyse: Ereignisgesteuerte Prozessketten und objektorientierte Geschaftsprozessmodellierung fur Betriebswirtschaftliche Standardsoftware (German Edition)

Das Schlangengrab

Das Kristallkommando

Das Zeitauge

Das Heideprinzesschen

Das Relikt

Das Zeitkommando

Das Kristallkommando

Das objektorientierte Konstruktionshandbuch

Objektorientierte Softwareentwicklung mit Smalltalk (Objekttechnologie)

Objektorientierte Modellierung zur geodätischen Deformationsanalyse German

Objektorientierte Programmierung in Java : professionell einsteigen

Objektorientierte Programmierung spielend gelernt: mit dem Java-Hamster-Modell

Unternehmensmodellierung: Objektorientierte Theorie und Praxis mit UML 2.0 (German Edition)

Objektorientierte Systementwicklung. Vom Geschäftsprozess zum Java-Programm GERMAN

Objektorientierte Datenbanken: Die C++-Anbindung des ODMG-Standards (Objekttechnologie)

Unternehmensmodellierung Objektorientierte Theorie und Praxis mit UML 2.0

Das Feuer, das Schwert und das Paradies

Das Auge und das Schwert

Das Eichhorn und das Nashörnchen

Das Leben und das Schreiben

Das Seiende und das Wesen

Das Leben und das Kino

Das Seiende und das Wesen

Das Auge und das Schwert

Das Auge und das Schwert

Das Geschehen und das Schweigen

Das Auge und das Schwert

Das Geschlecht, das nicht einkauft

Das Eichhorn und das Nashörnchen

Das Leben Und Das Schreiben

Geschaftsprozessanalyse: Ereignisgesteuerte Prozessketten und objektorientierte Geschaftsprozessmodellierung fur Betriebswirtschaftliche Standardsoftware (German Edition)

Das Schlangengrab

Das Kristallkommando

Das Zeitauge

Das Heideprinzesschen

Das Relikt

Das Zeitkommando

Das Kristallkommando

Recommend Documents