Von den Ingenieuren lernen?
Wenn Sie einem anderen Programmierer Ihr Programmlisting zeigen, ist das dazu vergleichbar, daß ein Elektroingenieur dem anderen eine von ihm entworfene und fertig aufgebaute Platine zeigt. Es ist für den anderen Elektroniker nur sehr schwer möglich, die Zusammenhänge dieser Schaltung zu verstehen. Aber auch der Bastler selbst wird es nicht leicht haben, allein anhand der Platine die Struktur der Schaltung zu erläutern. Da er aber beim Entwurf der Schaltung bestimmt nicht sogleich konkrete Bauelemente aneinanderreihte, sondern sich über eine Hierarchie von immer konkreter werdenden Schaltplänen der endgültigen Lösung angenähert hat, kann er durch Vorzeigen dieser Schaltpläne den anderen schnell seine Gedankengänge nachvollziehen lassen.
Dokumentation?
Bei der Dokumentation von Software sind "Schaltpläne" Mangelware. Da hilft auch ein "gut dokumentierter Quelltext" (wie man oft stolz formuliert) nicht aus der Patsche. Analog dazu hätte eine "gut dokumentierte Platine" neben jedem Bauteil eine Bemerkung stehen, wozu dieses dient. Kein Elektrotechniker würde sich die Mühe machen, seine Platine so zu beschriften.
Aufbaubeschreibung versus Ablaufbeschreibung
Auch wenn ein Programm nunmal eigentlich keine Verschaltung, sondern nur eine Verhaltensbeschreibung ist, ist es sinnvoll, sich das Programm als Verschaltung einzelner Komponenten vorzustellen und es anhand von Schaltplänen zu entwerfen und zu beschreiben. Das Zusammenschalten von einzelnen Komponenten zu einem System beherrscht der Mensch seit dem frühen Kindesalter, wo er mit seinem Baukasten gespielt hat; und das Verhalten einer einzelnen Komponente zu beschreiben (also ein Programm dazu anzugeben) ist auch nicht sonderlich schwer für ihn. Es ist daher im Allgemeinen nicht sinnvoll, den Versuch zu starten, für ein komplettes System sofort ein großes Programm anzugeben. Stattdessen sollte man sich wie der Elektroingenieur durch immer konkreter werdende Schaltpläne der Lösung annähern.
Aber wie sehen nun solche Schaltpläne für Computerprogramme aus? Bei der Gestaltung der Pläne orientiert man sich an den Bedürfnissen des Menschen. Wenn etwas geschieht, müssen wir stets auf den Ort des Geschehens zeigen können. Daß etwas geschieht, dieses aber "nirgendwo" geschieht, können wir uns nämlich nicht vorstellen. Als zweites suchen wir immer nach dem Grund des Geschehens. Bei einer schwebenden Gabel wird man ein Seil oder einen Magneten suchen. Denn überhaupt erst dadurch, daß wir uns der vielen "wenn - dann"-Beziehungen bewußt sind, können wir mit unserer Welt umgehen.
Zwei Dinge interessieren daher vorrangig:
Beim Zeichnen der Schaltpläne hat es sich daran angelehnt als sinnvoll gezeigt, zwischen zwei konkreten Systemkomponententypen zu unterscheiden: Zum einen sind dies die Orte, an denen etwas geschieht. Das sind die passiven Komponenten des Systems. Sie werden in runder Form (Kreise oder Ovale) dargestellt. Dem gegenüber stehen die aktiven Komponenten, also die Komponenten, die für Änderungen an den Orten sorgen. Diese Komponenten zeichnet man wie eine Blackbox rechteckig.
Zur Verdeutlichung noch ein kleines Beispiel:
Dargestellt ist eine mögliche GFA-Basic Entwicklungumgebung, bestehend aus den aktiven (rechteckige) Komponenten Interpreter (mit Editor), Compiler und Shell. Als passive (runde) Komponenten sehen Sie den Speicher für die GFA-Datei, für das Compilat, sowie zwei Kanäle, über die die Shell den Interpreter und den Compiler aufrufen kann.
Das System läßt sich natürlich weiter verfeinern. Man könnte zum Beispiel in die Shell hineinblicken und würde dort wieder einige aktive und passive Komponenten in irgendeiner Weise miteinander verschaltet vorfinden. Als aktive Komponenten wird es vielleicht einen Programmnachstarter geben oder einen Menü- und Dialogverwalter, der sich um die Benutzerschnittstelle kümmert. Als passive Komponente taucht vielleicht ein Speicher auf, der die Shellkonfiguration enthält (die INF-Datei).
Beachten Sie, daß zwei Akteure immer nur über eine passive Komponente miteinander verbunden werden können.
Diese Einführung war natürlich nur sehr knapp. Die Einblicke sollten aber helfen, wenn später erklärt wird, welche Objekttypen in informationellen Systemen auftreten.