Reinhold Plösch: Prototyping verteilter objektorientierter Prozeßsteuerungssysteme, Schriften der Johannes-Kepler-Universität Linz, Reihe C, Nr. 6, Universitätsverlag Rudolf Trauner, ISBN 3 85320 674 3, Linz 1994.
Der Traum, Abläufe zu automatisieren, ist so alt wie die Menschheit selbst. Frederick Winslow Taylor, Wegbereiter der industriellen Fertigung, der Rationalisierung und der Fließbandarbeit, ist es zu Beginn dieses Jahrhunderts gelungen, Automatisierung auf eine wissenschaftliche Basis zu stellen. Unter anderem schreibt er in seinem berühmt gewordenen Werk The Principles of Scientific Management [Taylor19]: “Was nun den dritten Grund “das langsame Arbeiten” anbelangt, so wird er im weiteren Verlauf dieser Abhandlung ganz ausführlich behandelt werden, um den großen Gewinn für beide Teile, Arbeitgeber und Arbeitnehmer, vor Augen zu führen, den die Ersetzung der Faustregeln durch wissenschaftliche Methoden, selbst im kleinsten Detail jeder gewerblichen Arbeit, herbeiführt. Die außergewöhnliche Zeitersparnis und die damit verbundene Steigerung der Produktion, die sich für jeden gewerblichen Arbeiter erzielen lassen, wenn alle unnötigen Bewegungen ausgeschaltet, langsame Bewegungen durch schnelle und unökonomische durch ökonomische Handgriffe ersetzt werden, kann nur von jemandem gewürdigt werden, der mit eigenen Augen die Resultate mit angesehen hat, die durch eingehendes Studium aller Handgriffe und der notwendigerweise aufzuwendenden Zeit durch einen dazu geeigneten Mann herbeigeführt werden. Zur kurzen, vorläufigen Erläuterung dieses Punktes möge folgendes dienen. Es ist eine Tatsache, daß die Arbeiter aller Gewerbszweige ihr Handwerk durch Beobachtung ihrer Mitarbeiter gelernt haben. Daher laufen eine Unmenge verschiedener Ausführungsmethoden für ein und dieselbe Arbeit nebeneinander her, manchmal 40, manchmal 50, manchmal 100 verschiedene Methoden zur Erzielung ein und desselben Zweckes. Aus demselben Grunde gibt es eine Unzahl verschiedenster Werkzeuge für dieselbe Arbeit. Unter diesen verschiedenen Methoden und Werkzeugen, die für eine einzelne, elementare Operation in irgend einem Gewerbe im Gebrauch sind, gibt es immer nur eine Methode und ein Werkzeug, schneller und besser als die übrigen, und diese eine beste Methode und das beste Werkzeug kann nur durch systematisches Studium und durch Prüfung aller Methoden und Werkzeuge, die im Gebrauch sind, gefunden werden, im Verein mit einem gründlichen, eingehenden Bewegungs- und Zeitenstudium. Das ist der Weg zur allmählichen Ersetzung der Faustregeln durch wissenschaftlich ermittelte Methoden und Zahlen auf allen technischen Gebieten.” Moderne computergesteuerte Fertigungszentren sind heutzutage die besten Beispiele für verwirklichten Taylorismus, wo – um Taylors Worte zu verwenden – Roboter die besten Werkzeuge darstellen und der Mensch häufig nur mehr überwachende Funktionen innehat. Zur Steuerung dieser Roboter und Maschinen werden in zunehmendem Maße Computer eingesetzt, eine Maßnahme, durch die große Rationalisierungspotentiale genutzt werden können (siehe dazu [Schiebe92]). Die Produktion von Gütern wird in zunehmendem Maße im Sinne des Taylor’schen Systems perfekt und optimiert, wenngleich sich die verwendeten Techniken wesentlich verändert haben – vom Fließband hin zu flexiblen Fertigungszellen. Taylors System ist aber nicht auf den Produktionsbereich beschränkt, sondern für fast alle Teilbereiche des Lebens anwendbar. Es stellt sich die Frage, ob die Ideen des Taylorismus auch in der Software-Erstellung ihre Berechtigung haben. Betrachten wir die Definition für Software Engineering von Pomberger [Pomberger93]: “Software Engineering ist die praktische Anwendung wissenschaftliche Erkenntnisse für die wirtschaftliche Herstellung und den wirtschaftlichen Einsatz qualitativ hochwertiger Software.” Von der Disziplin Software Engineering wird also erwartet, daß sie Methoden, Werkzeuge, Normen und Hilfsmittel bereitstellt, die es ermöglichen, die technischen und organisatorischen Probleme der Software-Entwicklung in den Griff zu bekommen (siehe [Pomberger93]). Der Grundstein für Software-Engineering wurde bei den beiden von der NATO veranstalteten Konferenzen in Garmisch [Naur69] und Rom [Buxton69] gelegt. Auf diesen Konferenzen wurde darauf hingewiesen, daß Programme Industrieprodukte sind, verbunden mit der Forderung, eine ingenieursmäßige Software-Entwicklung einzuführen. Die dabei zu lösenden Probleme sind vielschichtiger als jene, die Taylor durch einfache Zeit- und Bewegungsstudien lösen konnte. Bei der Entwicklung von Software-Systemen handelt es sich um keine manuelle Tätigkeit, die leicht meßbar und standardisierbar sind. In den letzten beiden Jahrzehnten hat es im Bereich des Software Engineering Fortschritte gegeben, die hoffen lassen, daß diese noch junge Disziplin mittelfristig zu einem ingenieursmäßigeren Software-Bau führt. Das von Taylor postulierte Ziel, nämlich für eine Aufgabe genau eine Methode und ein Werkzeug zuzulassen, erscheint aufgrund der Komplexität für die Software-Entwicklung nicht erreichbar. Prototyping und objektorientierte Programmierung sind unserer Meinung nach jene Forschungsrichtungen, die nach dem derzeitigen Wissensstand am besten dazu geeignet sind, die Probleme der Software-Entwicklung zu lösen und damit den Zielen des Software-Engineering näher zu kommen. Ohne an dieser Stelle auf diese beiden Begriffe einzugehen, können wir aus unserer Erfahrung feststellen, daß durch den Einsatz dieser beiden Techniken Kernprobleme des Software Engineering gemildert werden können: • Gesichertes Wissen über die gewünschte Funktionalität von Anwendungen (Prototyping) • Bessere Akzeptanz beim Anwender (Prototyping) • Bessere Software-Qualität (Prototyping und objektorientierte Programmierung) • Erhöhte Wiederverwendbarkeit (Objektorientierte Programmierung) • Kürzere Entwicklungszeit (Objektorientierte Programmierung) Der Anspruch dieser Arbeit ist es, Prototyping und objektorientierte Programmierung für den Bereich “Automatisierungstechnik” zu betrachten, wobei unter anderem folgende Fragestellungen beantwortet werden sollen: • Ist Prototyping eine adäquate Vorgehensweise in Automatisierungsprojekten? • Welchen Wert haben allgemeine prototyping-orientierte Vorgehensweisen (wie z.B. bei Bischofberger in [Bischofberger92] beschrieben) für den Bereich der Automatisierungstechnik? Sind spezielle Vorgehensweisen für Automatisierungsprojekte notwendig und sinnvoll? • Inwieweit kann mit Klassenbibliotheken Prototyping von Automatisierungssystemen betrieben werden? • Wie ist das Zusammenspiel zwischen einer Klassenbibliothek und einem darauf aufbauenden Prototyping-Werkzeug? • Welchen Einfluß haben Klassenbibliotheken auf den Bau von Prototyping- Werkzeugen? In Kapitel 2 geben wir einen Überblick über die Automatisierungstechnik und über den Stand der Technik im Bereich der objektorientierten Programmierung. Dabei werden Grundbegriffe der Automatisierungstechnik vorgestellt, und wir werden eine Eingrenzung des Themenbereiches Automatisierungstechnik für diese Arbeit vornehmen. Aus der Sicht der Automatisierungstechnik werden generelle Anforderungen an Software für Automatisierungssysteme formuliert. Zum anderen werden Grundbegriffe und Konzepte der objektorientierten Programmierung diskutiert. Dies ist vor allem darum notwendig, da sich im Bereich der objektorientierten Programmierung noch kein eindeutiger Sprachgebrauch herauskristallisiert hat. In Kapitel 3 wollen wir die wichtigsten Begriffe und Konzepte des Prototyping vorstellen. Dazu zählen unter anderem die von anderen Autoren entwickelten prototyping-orientierten Vorgehensmodelle. Darüberhinaus werden wir aufbauend auf diese Vorgehensmodelle ein eigenes Modell entwickeln, das für das Prototyping von verteilten Prozeßsteuerungssystemen eingesetzt werden kann. In Kapitel 4 stellen wir die Architektur und Komponenten von ProcessTalk vor, einem Application Framework für verteilte objektorientierte Prozeßleitsysteme. Wir werden dabei die prinzipielle Funktionalität des Application Framework vorstellen und untersuchen, inwieweit die generellen Anforderungen an Prozeßsteuerungssoftware erfüllt sind. Darüberhinaus werden wir anhand von Beispielen zeigen, inwieweit Prototyping mit dem Application Framework ProcessTalk möglich ist und die Prototyping-Möglichkeiten zusammenfassend beurteilen. In Kapitel 5 stellen wir das Werkzeug ProcessBuild vor, das auf dem Application Framework ProcessTalk aufsetzt und u.a. durch seine grafische Benutzeroberfläche gut für das Prototyping verteilter Prozeßleitsysteme geeignet ist. Wir werden in diesem Kapitel die Funktionalität des Werkzeuges vorstellen und – wie in Kapitel 4 – zeigen, inwieweit das Prototyping mit ProcessBuild unterstützt wird. Abgeschlossen wird das Kapitel durch eine zusammenfassende Beurteilung der Prototyping-Möglichkeiten. Kapitel 6 liefert die zusammenfassende Schlußbetrachtung der Arbeit. Abgeschlossen wird die Arbeit durch einige Anmerkungen zu möglichen weiterführenden Forschungsaktivitäten.