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.

23.01.1998 - 

Componentware / Jeder soll Software komponieren können

Visuelle Sprachen verhelfen den Komponenten zum Durchbruch

Ein langgehegter Wunsch von Anwendern könnte jetzt in Erfüllung gehen. Das objektorientierte Programmieren hat dafür gesorgt, daß Software inzwischen strukturiert in Form von Komponenten wiederverwendbar ist. Windows schuf mit seinen grafischen Fähigkeiten die Voraussetzungen für den Einsatz visueller Sprachen, um Softwarebausteine auch als solche handhaben zu können. Beide zusammen - OO-Technologien und visuelle Sprachen - haben Componentware zum Durchbruch verholfen.

Wer bei "visuellen Sprachen" an all jene Programmiersprachen denkt, die sich mit dem Namenszusatz "Visual" schmücken, ist allerdings auf dem falschen Dampfer. Gemeint sind eben nicht die textuellen Programmiersprachen, die nur Eingeweihte zu interpretieren wissen, sondern wirklich visuelle, mit Bildern funktionierende Sprachen, die wegen ihres rein grafischen Ansatzes auch der normale PC-Anwender verstehen und einsetzen kann.

Visuelle Sprachen werden dazu verwendet, Software aus Bausteinen zu komponieren. Am Bildschirm stellt ein Symbol (Icon) einen Baustein dar, an dem Pfeile die Ein- und Ausgänge repräsentieren, über die der Benutzer Nachrichten empfangen oder verschicken kann. Aus einem Programmbaukasten holt sich der Anwender mit der Maus all die Bausteine, aus denen seine Anwendung bestehen soll, auf sein Arbeitsblatt.

Danach muß er nur noch festlegen, wie diese miteinander kommunizieren. Dazu hat er lediglich zwischen den Ein- und Ausgängen Verbindungen in Form von Linien herzustellen. Das Gebilde nennt sich dann Visuagramm, eine Kurzform von visualisiertes Nachrichtenflußdiagramm. Fertig ist die Anwendung.

Wie kann das zugehen? Tatsächlich verbirgt sich hinter jedem elementaren Baustein ein Objekt mit seinen Methoden. Trifft am Eingang eines Bausteins eine Nachricht ein, wird genau eine bestimmte Methode des Objekts aufgerufen, die sie verarbeiten kann.

Auch die Ausgänge repräsentieren Methoden des Objekts, allerdings können diese nur objektintern aufgerufen werden. Sie veranlassen die Weitergabe einer Nachricht an das Component Call Center (CCC, englisch ausgesprochen: Triple-C). Das sorgt dann dafür, daß die Nachricht entsprechend der vom Anwender hergestellten Verbindungen an alle nachfolgenden Bausteine weitergeleitet wird.

Hier kommt deutlich der Unterschied von Komponenten und Objekten zum Ausdruck. Auf unterstem Niveau sind beides Bezeichnungen für ein und dasselbe, denn jede elementare Komponente wird üblicherweise als Objekt realisiert. Wer vom Objekt spricht, setzt sich mit dem Inneren einer elementaren Komponente auseinander.

Hier kommt auch das Schlagwort Vererbung zum Tragen. Objekte beziehungsweise Objektklassen werden voneinander abgeleitet und erben die Methoden ihrer Basisklasse. Änderungen in einer Basisklasse schlagen auf alle davon abgeleiteten Klassen durch. Bei fertigen Komponenten macht dieser Mechanismus keinen Sinn, denn sie besitzen ein "Gedächtnis" mit festem Datenbestand, der in sich konsistent sein muß. Das Gedächtnis bleibt auch erhalten, wenn die Applikation beendet wird.

Wer in Komponenten denkt, hält ein Objekt für die kleinste Einheit, für ein Atom sozusagen. Wer in Objekten denkt, für den beginnt es ab dem Atom erst interessant zu werden. Die einen denken wie Chemiker, die aus Atomen Stoffe zusammensetzen, die anderen wie Physiker, die sich mit den Atomen selbst beschäftigen. Jedoch ist in der Informatik eine derart saubere Trennung zweier unterschiedlicher und sich doch ideal ergänzender Ansätze nur selten zu finden.

Visuelle Sprachen sind das Werkzeug, um mit Komponenten adäquat umgehen zu können. Die wesentlichen Elemente dabei sind Bausteine: Komponenten mit ihrer vollständigen Dokumentation, genormter Interface-Beschreibung und eigenem Datenbestand. In der Regel läßt sich der Gebrauch visueller Sprachen in wenigen Stunden erlernen. Auf ihrer Basis wird keine Zeile Code mehr programmiert. Und wo nicht programmiert wird, gibt es auch keine Programmierfehler.

Trotzdem stellen visuelle Sprachen ein Werkzeug dar, mit dessen Hilfe beliebig komplexe Software entstehen kann, denn jedes Visuagramm beschreibt seinerseits das Innere eines zusammengesetzten Bausteins. Dazu kann es auch äußere Ein- und Ausgänge besitzen, über die dieser wieder Nachrichten aufnehmen oder abgeben kann. Also läßt sich, ausgehend von elementaren Bausteinen, im Bottom-up-Verfahren beliebige und zudem hierarchisch strukturierte Software komponieren.

Doch es ist nicht unbedingt das Ziel, mit visuellen Sprachen beliebige Anwendungen zu erstellen. Vielmehr werden visuelle Sprachen branchenorientiert konzipiert und eingesetzt. Normalerweise genügt ein Set von 20 bis 30 Grundbausteinen, um damit das Tagesgeschäft in einer Branche erledigen zu können.

Die Triple-S GmbH hat mehr als 50 Systeme untersucht, wovon sich mehr als die Hälfte den Bereichen Meßtechnik und Prozeßvisualisierung zuordnen lassen. Daneben sind visuelle Sprachen stark in den Bereichen Automation, Ablaufsteuerung, Simulation, Autorensoftware, Bildverarbeitung, Workflow und Geschäftsprozeßanalyse vertreten. Es muß hier allerdings einschränkend erwähnt werden, daß es sich mit einer Ausnahme bei allen Systemen um Insellösungen handelt, die außerdem sehr jung sind.

In den Bereichen Meß- und Prozeßtechnik besteht naturgemäß ein starker Zwang zum Erstellen von Individuallösungen. Diese lassen sich nur deshalb kostengünstig realisieren, weil der Gebrauch einer visuellen Sprache so einfach ist und der Endanwender die benötigten Anwendungen ohne Programmierer selbst erstellen kann. Wenn dabei Standardsoftware zum Einsatz kommt, dann nur in Form von vorgefertigten Komponenten, die allerdings DV-Spezialisten entwickelt haben.

Der in einigen Branchen schon heute nicht mehr wegzudenkende Einsatz visueller Sprachen zeigt deutlich, wohin der Zug Componentware fahren wird. Der Traum von der kostengünstigen Individuallösung wird damit Wirklichkeit. "Make and buy" heißt dabei die Devise.

Das wird keineswegs die Informatiker arbeitslos machen. Ähnlich wie die Hochsprachen der dritten Generation (Fortran, Pascal, C, C++ etc.) nicht zu einem Heer von unbeschäftigten Assembler-Programmierern führten, sondern den Zugang zum Computer für einen riesigen Anwenderkreis erschlossen haben, wird sich dies im Fall von visuellen Sprachen beziehungsweise Componentware verhalten. Die Meta Group prognostiziert für Componentware ein jährliches Wachstum von 30 Prozent.

Unabhängig vom schnellen und wirtschaftlichen Erstellen von Individuallösungen verfolgt Componentware das Ziel, Software so aufzubauen, daß die an einer Anwendung beteiligten Komponenten auch über Rechnergrenzen hinweg und auf verschiedene Hardwareplattformen verteilt laufen können.

Besonders ins Gewicht fällt allerdings, daß man all die in den vergangenen Jahrzehnten für Mittel- und Großrechner geschriebene Software mit der kostengünstigen Bedienoberfläche des PCs verbinden möchte. Beim Vorschlag, doch zu portieren, winkt hier jeder ab: "Never change a running system!"

Bei der Festschreibung eines einheitlichen Standards für verteilte Komponenten hält der Streit allerdings an. Insbesondere stehen sich hier DCOM von Microsoft für die Windows-Welt und Corba für die Unix-Welt gegenüber. Es sprechen jedoch einige Argumente dafür, daß sich DCOM durchsetzen wird: Vor allem ist DCOM (beziehungsweise COM+) die konsequente Fortführung des Komponentenstandards COM, auf dem wiederum alle OCX- und Active-X-Controls aufbauen, und das sind nicht wenige. Weltweit schätzt man die Zahl der existierenden OCX-Controls auf rund 50000.

Wer mit "Visual Basic" von Microsoft, "Delphi" von Borland oder "Visua" von Triple-S arbeitet, dem dürfte die visuelle Programmiermethode vertraut sein. Schließlich hat die Software AG mit ihrem Produkt "Entire-X" die dem DCOM-Standard zugrundeliegende Technologie zumindest in den wichtigsten Aspekten auch in die Unix- und IBM-Großrechnerwelt portiert.

Angeklickt

Programme aus Codebausteinen zusammenstellen zu können ist ein erstrebenswertes Ziel. Noch besser wäre es, wenn dies den Anwendern auch ohne spezielle DV-Kenntnisse möglich wäre. Tatsächlich gibt es dazu mehr als bescheidene Ansätze. Die visuelle Programmierung, in der nicht viel mehr als die Zusammenstellung von Komponenten per Maus geschieht, hat in den letzten Jahren bedeutende Fortschritte gemacht. Sie könnte analog zur Componentware einen enormen Aufschwung nehmen.

Zum Beispiel

Wer wissen will, was visuelle Programmierung heute bedeuten kann, könnte sich das Programm "Visua-Softwarestudio" von Triple-S per Internet http://www.sss.de auf den Rechner holen. Vergleichende Darstellungen bringt das gerade erschienene und gut lesbare Buch "Visuelle Programmierung" von Stefan Schiffer http://www.swe.uni-linz.ac.at/schiffer/vp/html .

*Josef Hübl ist Geschäftsführer der Triple-S GmbH in Regensburg.