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.

16.01.1987

Selektion der richtigen Werkzeuge macht den guten Entwickler aus:Wissensbasierter Ansatz eröffnet neue Wege

Es gibt nicht nur ein einziges Modell für das Software-Engineering. Der gute Entwickler verfügt viel mehr über mehrere Vorgehensweisen, die verschiedenen Programmiermethoden zuzuordnen sind. An Bedeutung gewinnt dabei zunehmend der wissensbasierte Ansatz. Meister ihres Fachs erkennt man an der Auswahl der richtigen Werkzeuge und ihrer sachgemäßen Handhabung bei der Lösung eines Problems.

Die Erstellung von Programmen zählt ohne Zweifel zu den zentralen Aufgaben derjenigen Leute, die mit Computern umzugehen haben. Software-Engineering umfaßt alle Tätigkeiten, die notwendig sind, um ein Problem unter Zuhilfenahme eines Computers zu lösen. Die Entwicklung und Implementierung eines korrekten Programms ist in den allermeisten Fällen alles andere als eine einfache Angelegenheit. Die dabei auftretenden Schwierigkeiten lassen sich noch am besten dadurch meistern, daß man einer sauberen Systematik folgt. Als eine solche hat sich, zumindest im Prinzip, die Aufteilung der für die Erstellung eines Programms benötigten Tätigkeiten in verschiedenen Phasen herausgestellt. Diese sind üblicherweise

- die Problemanalyse,

- die Festlegung ("Spezifikation") der vom Programm geforderten Funktions- und Leistungsmerkmale,

- der Entwurf eines diesen Anforderungen genügenden Systems,

- die Implementierung und der Test einzelner Bausteine dieses Systems sowie ihr Zusammenbau zu einem funktionierenden Ganzen,

- die Integration dieses Produkts in die Anwendungsumgebung,

- die Inbetriebnahme und Wartung.

Es gibt unzählige Verfeinerungen, Vergröberungen und Varianten der genannten Vorgehensweise. In ihrem Kern entsprechen sie sich jedoch fast alle. So naheliegend und vernünftig dieses Modell auch erscheint, erleiden Software-Entwicklung doch noch häufig nicht, daß die oben aufgelisteten Tätigkeiten nicht richtig ausgeführt würden, sondern schlichtweg der, daß ein solches Modell gar nicht erst hätte zur Anwendung gebracht werden dürfen.

Der traditionelle Ansatz des Software-Engineering ist zugeschnitten auf die prozedurale Programmierung. Diese ist gekennzeichnet durch ihre enge Anlehnung an die derzeit dominierende Architektur eines Computers, die nach einem der Pioniere der Datenverarbeitung, John von Neumann, benannt ist. In Abbildung 1 ist die Gedankenwelt eines Entwicklers modelliert, der sich des Paradigmas der prozeduralen Programmierung bedient.

In Anlehnung an die beiden Komponenten Prozessor und Speicher eines Von-Neumann-Computers sieht er sich mit den folgenden vier Aufgaben konfrontiert:

- Er plant die Belegung des ihm zur Verfügung stehenden Speichers in Form von Datenvereinbarungen.

- Durch Deklaration von Prozeduren, Funktionen und Routinen beschafft er sich die Operationen, aus denen er seinen Problemlösungsprozeß zusammenzusetzen beabsichtigt. - Er legt die Reihenfolge der Anwendung von Operationen mittels Kontrollstrukturen fest.

- Er plant die Steuerung des Datenflusses, das heißt, er gibt an, welche Daten welchen Operationen zuzuführen sind.

Grundvoraussetzung für das Gelingen des geschilderten Vorhabens ist die Existenz eines Algorithmus, der zur Lösung des gestellten Problems geeignet ist. Die Entwurfsphase des traditionell verwendeten Software-Engineering-Modells ist gerade auf die Entwicklung eines solchen Algorithmus ausgerichtet. In diesem Sinne spielt diese Phase eine ganz entscheidende Rolle bei der Entwicklung eines Softwaresystems. Konsequenterweise müßte in manchen Fällen das Ergebnis der Entwicklungsphase in der Feststellung bestehen, daß die Entwicklung eines Lösungsalgorithmus entweder nicht gelingt, oder aber so widernatürlich ist, daß besser davon Abstand genommen werden sollte.

Ein derzeit bereits vielfach relevanter, und in Zukunft noch in weitaus stärkerem Maße als bisher an Bedeutung erlangender Problembereich ist die Wissensverarbeitung. Die hier anstehenden Aufgaben sind zumeist gar nicht oder jedenfalls nur sehr schwer algorithmisierbar. Aus dem einfachen Grunde, weil die von Menschen bei der Verarbeitung von Wissen angewandte Vorgehensweise nicht der prozeduralen Abwicklung von Algorithmen entspricht. Zumeist ist die menschliche Wissensverarbeitung noch nicht in dem Maße erforscht, daß die ihr eventuell doch zugrunde liegende algorithmische Methodik offengelegt wurde.

Es ergibt sich für Bereiche wie

- Erkennung, Übersetzung und Erzeugung natürlichsprachiger Äußerungen,

- Diagnose fehlerhaften Verhaltens von Maschinen,

- Büroautomatisierung,

- Entwicklung von Strategien,

- Interpretation von Meßdaten,

- maschinelles Lernen

die Notwendigkeit zur Entwicklung von neuen nichtprozeduralen Software-Engineering-Techniken. Zwei solcher Ansätze sollen nachfolgend etwas ausführlicher erläutert werden.

Das Grundprinzip des Ansatzes für den objektorientierten Systementwurf besteht darin, ein Problem unter Verwendung eines Computers dadurch zu lösen, daß die Vorgänge innerhalb der Problemumgebung auf möglichst natürliche und unmittelbare Weise simuliert werden. In Abbildung 2 ist dieses Modell der Software-Entwicklung skizziert.

Die Simulation von irgendwelchen Vorgängen in der realen Welt erfordert die Nachbildung der relevanten Problembestandteile sowie des wechselseitigen Zusammenwirkens dieser Komponenten. Bestandteile der realen Welt lassen sich charakterisieren durch die Zustände, welche sie annehmen können, und durch die Aktivitäten, in die sie einbezogen werden können. Objektorientierte Entwicklungsumgebungen stellen dafür Werkzeuge in Form von Objekten und Klassen zur Verfügung. Klassen sind Schablonen für Kapseln, bestehend aus einer Daten- und einer Operationskammer. Objekte sind Ausprägungen ("Exemplare") von Klassen. Alle Exemplare einer Klasse besitzen die gleiche Operationskammer; ihre Datenkammern sind strukturell gleich, können sich aber in Größe und Inhalt unterscheiden. Mittels Klassen lassen sich Familien der für das zu lösende Problem logisch zusammengehörigen Bestandteile gut nachbilden. Durch Erzeugung von Exemplarobjekten der Klassen können individuelle Problembestandteile in den Simulationsvorgang eingebracht werden.

"Vererbungsprinzip" dient zur Klassenbeschreibung

Viele Bestandteile der realen Welt sind sich gegenseitig bedingende Spezialfälle, wie etwa Pkws in die Kategorie der Autos gehören, diese wiederum Fortbewegungsmittel sind, und letztere zu den Transportgeräten gehören. Bei der Beschreibung von Klassen kann deshalb auf bereits vorhandene Klassen zurückgegriffen werden ("Vererbung"). Objektorientierte Systeme unterscheiden sich darin, ob neue Klassen durch Spezialisierung einer einzigen oder mehrerer anderer Klassen entstehen können.

Objekte treten miteinander durch den Austausch von Nachrichten in Beziehung. Der Sender einer Nachricht übermittelt dabei dem Empfänger einen Wunsch, welche Operation des letztgenannten Objekts mit welchen Argumenten ausgeführt werden soll. Einzig und allein das Empfängerobjekt entscheidet aufgrund der Zugehörigkeit zu seiner Klasse und der dort verankerten Operationen über die Erfüllung dieses Wunsches.

Objektorientierter Entwurf schafft Vorteile

An dieser Stelle soll nicht auf weitere Einzelheiten der objektorientierten Programmierung eingegangen werden. Ziel ist vielmehr, einige positive Aspekte des objektorientierten Entwurfs von Softwaresystemen hervorzuheben:

- Das von David Parnas propagierte und zwischenzeitlich von allen gewissenhaften Software-Entwicklern als richtig und wichtig anerkannte Prinzip der Informationsabkapselung (Information hiding) läßt sich mit den Ausdrucksmitteln objektorientierter Sprachen bestens implementieren.

- Die objektorientierte Methodik leitet zur Erstellung hochgradig modularer Systeme an.

- Klassen beschreiben alle Aspekte ihrer Exemplarobjekte. Jede Änderung einer Klassenvereinbarung wird an alle davon betroffenen Objekte weitergereicht. Dies erleichtert die Anpassung eines objektorientierten Systems an sich ändernde Anforderungen.

- Durch die Möglichkeit, Attribute einer Klasse an andere Klassen weiterzureichen (Vererbung), wird die Vereinbarung neuer Klassen beträchtlich vereinfacht.

- Es gibt sehr gut ausgestattete Entwicklungsumgebungen für objektorientierte Programmiersprachen. Typisch für sie ist, daß alle ihre Werkzeuge als gleichrangige Objekte betrachtet werden, deren Dienste mittels Nachrichten in Anspruch genommen werden können. Dieser uniforme Mechanismus erleichtert das Erlernen und die Handhabung solcher Programmierumgebungen.

Es soll hier nicht der Eindruck erweckt werden, als ob die objektorientierte Programmierung aller Probleme des Software-Engineering mit einem Schlage lösen könnte. Alle anfallenden Problemstellungen in ein Gerüst von Objekten, Nachrichten und Klassen einzwängen zu wollen, wäre unsinnig. Es gibt jedoch viele Bereiche, in denen das objektorientierte Programmiermodell dem prozeduralen Ansatz überlegen ist. An dieser Stelle seien lediglich

- Simulationen technischer Vorgänge,

- grafische Datenverarbeitung,

- Systemprogrammierung,

- Wissensverarbeitung,

- Gestaltung von Benutzerschnittstellen sowie

- SW-Entwicklungsumgebungen

stellvertretend für noch zahlreiche andere Aufgabenbereiche genannt.

Wissensbasis steht im Mittelpunkt

Für die Entwicklung von Programmen ist es gewissermaßen eine Traumvorstellung, nur noch die funktionellen Merkmale der gewünschten Softwarepakete festlegen zu müssen. Ihre Umsetzung in eine ablauffähige Form sollte dann automatisch vorgenommen werden. Das in Abbildung 3 skizzierte Modell der wissensorientierten Programmierung kommt dieser Traumvorstellung sehr nahe.

Der Entwickler ist in erster Linie mit dem Aufbau einer Wissensbasis befaßt. Diese ist zugeschnitten auf den jeweiligen Aufgabenbereich. Zur Lösung seiner Probleme formuliert der Entwickler diese als Anfragen an die Wissensbasis. Ihre Beantwortung übernimmt ein Interpreter, der fester Bestandteil der Entwicklungsumgebung ist. Er arbeitet unabhängig von allen Anwendungsbereichen und bearbeitet Anfragen stets nach desselben Prinzip.

Dieses Modell kann auf sehr unterschiedliche Arten ausgeprägt werden. Es gibt heutzutage im wesentlichen vier verschiedene Formen der Darstellung von Wissen, nämlich semantische Netze, Rahmen (frames), Regeln, sowie logische Aussagen mit eigens darauf zugeschnittenen Mechanismen zur Beantwortung von Anfragen. Die beiden erstgenannten Darstellungsformen hängen sehr eng miteinander zusammen; außerdem besteht bei ihnen eine enge Beziehung zu Objekten und Klassen aus dem Bereich der objektorientierten Programmierung.

Wissensorientierter Systementwurf weicht noch sehr viel stärker als die objektorientierte Programmierung von dem prozeduralen Modell des herkömmlichen Software-Engineering ab. Der Entwickler eines Systems konzentriert sich auf die Formulierung dessen, was er zu einem bestimmten Problembereich weiß, beziehungsweise was der Auftraggeber an Eigenschaften des von ihm gewünschten Systems fordert. Er vernachlässigt mehr oder weniger die Überlegung, wie die Erfüllung dieser Aufgaben prozedural abgewickelt wird.

Um Mißverständnissen entgegenzuwirken, sei hier deutlich erwähnt, daß wissensbasierter Systementwurf nicht mit dem Bau von Expertensystemen gleichzusetzen ist. Offensichtlich bietet sich bei der Entwicklung von Expertensystemen die Verwendung des wissensorientierten Paradigmas an. Umgekehrt ist es aber nicht so, daß die Programmierung in einer wissensorientierten Sprache, wie etwa Prolog oder OPS-5, zwangsläufig zur Erstellung von Expertensystemen führt.

Spezifikationskonsequenzen werden beobachtbar

Eine typische Verwendung wissensbasierter Sprachen könnte so aussehen, daß der Software-Entwickler in ihnen Spezifikationen erstellt. Diese sollen ja gerade zum Ausdruck bringen, was das gewünschte System funktionell zu leisten hat, ohne dabei operationale Aspekte vorzuschreiben. Mit Hilfe des vorhandenen Wissensinterpreters können diese Spezifikationen bequem zum Leben erweckt werden; mit anderen Worten: Ihre Konsequenzen werden beobachtbar. Dies erleichtert die Überprüfung der Vollständigkeit, sowie die Aufdeckung von eventuellen Inkonsistenzen von Spezifikationen. Dem Auftraggeber können Verhaltensmerkmale des Systems, die sich aus seinen Anforderungen ergeben, veranschaulicht werden.

Dr. Gerhard Barth ist Professor am Institut für Informatik der Universität Stuttgart.

Literaturhinweise: B.J. Cox: Object Oriented Programming Addison-Wesley Publ. Co., 1986

D. Waterman: A Guide to Expert Systems. Addison-Wesley Publ. Co., 1986