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

Kein Log-In? Dann jetzt kostenlos registrieren.

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

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

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

30.07.1993

Scheinbarer Gegensatz zwischen objekt- und funktionsorientierten Oberflaechen OO oder nicht OO? - Darueber entscheidet das Interaktionsmodell

Was unterscheidet eine objektorientierte von einer funktionsorientierten Benutzeroberflaeche? Diese Frage ist, so Hartmut Fillhardt* falsch gestellt. Der eigentliche Gegensatz besteht seiner Ansicht nach naemlich zwischen Oberflaechen nach dem Objekt-Aktions-Modell und solchen, die gemaess dem Aktions-Objekt- Modell entworfen sind.

Die Inflation der Begriffe in der Softwarelandschaft hat dazu gefuehrt, dass wir heute zu fast jedem Begriff eine Abhandlung mitliefern muessen, wenn wir richtig verstanden werden wollen. Ansaetze zur Begriffsnormierung sind zwar vorhanden, werden jedoch zuwenig beruecksichtigt. Vermutlich ist der Umfang solcher Normenwerke daran schuld beziehungsweise die Zeit, die man deshalb zum Lesen benoetigt, aber nicht zu haben glaubt - oder die Tatsache, dass fast jeder Hersteller seine eigenen Normen definiert.

Als "objektorientiert" kann ein System nicht aufgrund der fuer seine Erstellung verwendeten Werkzeuge oder der Gestaltungsdetails seiner Benutzeroberflaeche bezeichnet werden, sondern allein wegen seiner Systemstruktur und des verwendeten Interaktionsmodells.

Die Evolutionstheorie

scheitert am Marketing

In jeder soliden Software-Anwendung gibt es Datenstrukturen und Algorithmen, um diese Daten zu veraendern und darzustellen, erklaerte Niklaus Wirth in den 60er Jahren. Lange war ein steter Trend zu beobachten, Datenstrukturen und Algorithmen voneinander abzugrenzen. Daten waren und sind eine Sache des Modellierens, Algorithmen eine Sache des Programmierens. Programmiert wird, indem komplexe Probleme in einfachere zerlegt werden und schlussendlich die Loesung in Form von Algorithmen in einer Programmiersprache niedergeschrieben und vom Computer abgearbeitet wird.

Seit den 70er Jahren bemuehen sich Universitaeten und einzelne innovative Unternehmen unter dem Stichwort Objektorientierung, diese beiden Aspekte von Softwaresystemen einander wieder nahezubringen. Seit etwa 1988 ist auch die oeffentliche Diskussion im Softwaremarkt von diesem Thema gepraegt. Trotz etlicher Versuche, die Objektorientierung als evolutionaere Veraenderung in die Software-Entwicklung hineinzudefinieren, praesentiert sie das Marketing als Neuheit. Was verkauft werden soll, muss auffallen, heisst es.

Es ist also ein - zumindest begrifflicher - Dualismus gefordert. Aber wogegen soll man sich abgrenzen? Wo oder was ist das Alte? Niemand moechte seine Software zum alten Eisen geworfen sehen, und sei es auch nur in begrifflicher Hinsicht.

Die Objektorientierung stellt Daten und Algorithmen in einer zusammengehoerigen Struktur vor: Der Klassenbegriff als Abstraktion des einzelnen Objekts vereint Datenstruktur und damit operierende Methoden.

Die Geburt der Objektorientierung als Disziplin des Software- Engineerings ist eng mit der Programmierumgebung Smalltalk verbunden. Smalltalk gilt vielen Softwerkern jedoch als zu exotisch, um die allgemeine Begriffspraegung konsequent beeinflussen zu koennen: Cii als Nachfolger des durch Unix und DOS weitverbreiteten C bildet einen nach vier Jahren mehr oder weniger akzeptierten Kompromi Die Begriffe "Objekt" und "Klasse" schafften den Sprung in die Hybridsprache Cii, "Methode" und "Botschaft" blieben einstweilen auf der Strecke.

An ihre Stelle traten die Programmiersprachen-Begriffe der "function" und - als der Klasse untergeordnet - der "Member function". Somit ist auf der Codierungsebene, beim "Programming in the small", der Gegensatz gefunden: hier Objektorientierung mit "class" und untergeordneter "Member function", dort die alleinregierende, C-gemaesse "function", die beliebig auf tumbe Datenstrukturen zugreifen darf.

Etwas ganz Wesentliches wird jedoch ueber diesem gesuchten Gegensatz leicht uebersehen: Objektorientierung ist keine Konkurrenz zum strukturierten Programmieren, sondern eine Modularisierungstechnik, eine Methode des "Programming in the large". Es geht darum, Komponenten innerhalb eines Softwaresystems so zu gestalten, dass sie moeglichst autonom sind. Im Idealfall haengen sie nicht vom konkreten Softwaresystem ab, fuer das sie entwickelt wurden; damit sind sie auch in anderen Systemen unveraendert einsetzbar. Die Wiederverwendbarkeit ist eines der grundlegenden wirtschaftlichen Ziele dieser Modularisierungstechnik.

Programmierung wird mit

Modellierung verwechselt

Schuld an der Begriffsverwirrung traegt auch die Tatsache, dass der Wechsel zwischen der Programmierung und der abstrakteren Begriffsebene der Systemmodellierung oft uebersehen wird. Im Systemkontext den deutschen Begriff "Funktion" mit dem englischen "function" gleichzusetzen, ist zwar naheliegend, aber falsch.

Im Deutschen bezeichnet die "Funktion" eine "Aufgabe" (englisch "task") beziehungsweise einen "Verantwortungsbereich" (englisch "responsibility"). So hat zum Beispiel ein Text-Editor die Aufgabe, Texte zu bearbeiten und zu verwalten. Verwendet er dazu Softwarewerkzeuge, so heissen diese der Einfachheit halber ebenfalls Text-Editoren.

Solch ein Werkzeug kann objektorientiert realisiert werden. Es besteht dann zumeist aus mehreren Klassen, die einfache oder komplexere Methoden bereitstellen, mit denen Textobjekte dargestellt und veraendert werden koennen. Eine derartige Methode anzuwenden heisst, etwas zu tun, zu agieren. Es wird deshalb auch "Aktion" genannt. Das englische Pendant heisst "action" und passt diesmal sogar.

Somit geht es strenggenommen nicht um den Unterschied zwischen objekt- und funktionsorientiert, sondern die zentrale Frage muss lauten: Was unterscheidet Oberflaechen nach dem Objekt-Aktions- Modell von solchen, die gemaess dem Aktions-Objekt-Modell entworfen sind?

Bei einer Oberflaeche gemaess dem Aktions-Objekt-Modell ist zuerst wichtig, was ich tun will, danach erst, mit welchen Objekten ich es tun will. Zuerst wird eine Taetigkeit ausgewaehlt aus einem Katalog aller moeglichen Taetigkeiten des Gesamtsystems (Speichern, Loeschen, Umziehen, Anschauen etc.), wobei zumeist aus fachlichen oder Platzgruenden eine - mehr oder weniger gelungene - Gruppierung der moeglichen Taetigkeiten vorliegt. Diese Gruppierung ist deshalb so schwierig, weil jeder Benutzer seine eigenen Prioritaeten setzt.

Danach wird beliebig oft ein zu bearbeitendes Objekt ausgewaehlt. Diese Art der Softwaregestaltung ist geeignet fuer gleichfoermige Massenarbeiten. Ihre gedankliche Grundlage bildet die Stapelverarbeitung (Batch). Eine solche Arbeitsweise ist vor allem dann effizient, wenn die zu bearbeitenden Dinge oder Ereignisse vorsortiert sind, so dass sie schematisch abgearbeitet werden koennen. Beispiele dafuer sind Bestellungen und Wareneingaenge.

Zuerst das Was

und dann das Wie

Bei einer Benutzeroberflaeche gemaess dem Objekt-Aktions-Modell wird zuerst ausgewaehlt, womit ich etwas tun will, danach waehle ich aus den jetzt noch moeglichen Aktionen die fuer dieses Objekt geeignete. Zumeist helfen sogenannte Container bei einer fach- oder mengenorientierten Gruppierung. Das wohl verbreitetste Beispiel sind Dateisysteme mit hierarchisch gegliederten Verzeichnissen (directories), in denen Dateien und Verzeichnisse enthalten sein koennen.

Das Softwaresystem bietet nach dieser Objektauswahl kontextsensitiv nur noch solche Aktionen an, die fuer das gewaehlte Objekt in seinem derzeitigen Zustand zulaessig sind. So kann beispielsweise ein Vertrag im allgemeinen nicht installiert werden, und zu kuendigen ist er erst, nachdem er zunaechst einmal abgeschlossen wurde. Vorbild dieser Arbeitsweise ist die Arbeitsflaeche des Schreibtischs (Desktop), auf dem die Bearbeitung von parallelen Vorgaengen dominiert, zwischen denen haeufig gewechselt wird und bei denen Arbeitsunterbrechungen die Regel sind.

Objektorientierte Benutzeroberflaechen gibt es heute in einem breiten Spektrum zwischen textbasiert und vollgrafisch, was haeufig zu Verwirrung fuehrt. So ist das Markieren eines Objekts in einer Liste und das anschliessende Auswaehlen der Methode "Loeschen" in einem Pulldown-Menue ebenso objektorientiert wie das Schieben eines Objekt-Icons mittels Maus in das Objekt "Papierkorb". Eine enge Bindung der beiden Benutzertaetigkeiten "Objekt auswaehlen" und "Objekt bearbeiten", wie zum Beispiel beim Schieben mit der Maus, wird auch "direkte Manipulation" genannt.

Eine Frage des

jeweiligen Geschmacks

Es geht hierbei lediglich um die Feinheiten des Wie, um die Wahl des Werkzeugs, um mehr oder weniger Komfort. Das grundlegende Interaktionsmodell ist jedoch in beiden Faellen dasselbe: Objekt - Aktion. Bei der direkten Manipulation liegen Objektauswahl und - bearbeitung naeher beisammen, doch der Effekt ist identisch. Die Entscheidung ist eine Frage des Geschmacks und Komforts.

Was als komfortabel gilt, haengt jedoch vom derzeitigen Standpunkt beziehungsweise den bisherigen Erfahrungen und Gewohnheiten des Benutzers ab. In diesem Zusammenhang zitiere ich gern den Modeschoepfer Christian Dior: "Mode ist Ewigkeit fuer eine Saison."

Nicht zuletzt spielt natuerlich auch der Geldbeutel eine Rolle: Grafische Systeme sind (nochteurer als textbasierte.

Wer also glaubt, je grafischer, desto besser, sollte einmal versuchen, laenger als fuenf Minuten mit einem solchen Werkzeug zu arbeiten. Nicht ueberall, wo Objektorientierung draufsteht, ist auch Objektorientierung drin, und auch ein gutes Modell ist noch keine Garantie fuer gute Details.

Intuitiv bedeutet

ohne Erklaerung verstehbar

Meine Erfahrungen im Dialogdesign haben mich dazu gefuehrt, mir von Fall zu Fall zunaechst ueber die Eignung des einzusetzenden Interaktionsmodells Gedanken zu machen. Das richtige Modell entscheidet langfristig ueber den Nutzen des eingesetzten Werkzeugs.

Die Akzeptanz beim Benutzer haengt hingegen von der intuitiven Verstehbarkeit der Details, von der Uebersichtlichkeit und von den Erfolgserlebnissen ab. Eine gute objektorientierte Oberflaeche ist immer das Ergebnis genauen Hinsehens beim Arbeiten. Unverzeihlich sind grafische Abstraktionen um jeden Preis. Manche Methode ist eindeutiger und intuitiver durch einen allgemein bekannten und akzeptierten Begriff im Pulldown-Menue darstellbar als durch ein Smart-Icon, das lediglich die Kreativitaet des Softwerkers zur Schau stellt.

"Intuitive Techniken" wie zum Beispiel "Drag und drop" sind daher genau da sinnvoll, wo sie eine enge Bindung zwischen Taetigkeit und Effekt darstellen, also beispielsweise bei "Wegwerfen" und "Umziehen". Bereits der Unterschied zwischen "Verschieben" und "Kopieren" ist ohne auswendig zu lernende Zusatztasten nicht mehr intuitiv erfassbar. Gefordert sind also Designer, die begriffen haben, was intuitiv eigentlich bedeutet: ohne Erklaerung verstehbar.

Ob funktions- oder objektorientiert gearbeitet wird, ist eine Frage des Zugangs. Der Benutzer nimmt die Aktion oder das Objekt als Ausgangspunkt seiner Arbeit, aber fuer eine abgeschlossene Taetigkeit benoetigt er beides. Der eine bereitet seine Arbeit lieber vor und arbeitet danach gleichartige Taetigkeiten ab, der andere arbeitet lieber, wie es kommt. Aus diesem Grund gibt es auf die Frage, was besser sei, keine unternehmensweit richtige Antwort. Die Frage kann aus der Sicht des einzelnen Benutzers nur lauten: "Was ist fuer mich besser?"

Beim konkreten Werkzeug wird die Akzeptanz wesentlich davon bestimmt, wie sehr die Anforderungen des jeweiligen Ansatzes von der Software auch in den Details konsequent umgesetzt werden. Als Beispiel soll hier die Dokumentenbearbeitung dienen: Arbeitet der Anwender in solchen Systemen objektorientiert, so wird beim Oeffnen eines Dokuments automatisch das zugehoerige Werkzeug gestartet: fuer den Text der Text-Editor, fuer die Grafik das Designwerkzeug, fuer eine Tabelle das Tabellenkalkulations-Programm etc. Bei einer funktionsorientierten Arbeitsweise starte ich zunaechst ein bestimmtes Werkzeug und bearbeite danach ein oder mehrere Dokumente, die zu diesem Werkzeug passen.

Firmenstandards muessen beide Arbeitsweisen zulassen

Bei der zuletzt beschriebenen Arbeitsweise spielt die Zeit, die ein Werkzeug fuer den Start benoetigt, keine grosse Rolle. Der von den Dokumenten aus arbeitende Anwender hingegen wird durch eine lange Startzeit extrem behindert. Insofern kann dieser Faktor die bevorzugte Arbeitsweise eines Benutzers wesentlich mitbestimmen.

Die Forderung an eine unternehmensweit einheitliche Benutzeroberflaeche lautet deshalb heute, beide Arbeitsformen gleichwertig zu unterstuetzen. Ein Uebergang kann nicht verordnet werden, ohne ernsthafte Effizienzeinbrueche zu riskieren. Ein harmonischer Wandel bedeutet fuer den einzelnen, im Nebeneinander beide Ansaetze auszuprobieren und selbst entscheiden zu koennen, welches Vorgehen den eigenen Arbeitsstil am besten unterstuetzt. Gute Werkzeuge sind solche, die beide Arbeitsweisen zulassen und so aus sich heraus technologischen Wandel durch Auseinandersetzung und Akzeptanz ermoeglichen.

*Hartmut Fillhardt ist Projektleiter und Dialogdesigner im Bereich Standardsoftware der Integrata AG, Tuebingen.