Software als System IV – Die Hierarchie der Strukturelemente

Software ist also nicht einfach nur ein „Ding“, sondern hat eine Struktur, d.h. sie ist aus mehreren „Dinger“, ihren Strukturelementen zusammengesetzt.

Diese Strukturelemente liegen auch nicht einfach nebeneinander herum, sondern operieren aufeinander und bilden so ein System untereinander. Darüber hinaus operieren immer zumindest einige von ihnen auch mit Strukturelementen der Umwelt der Software, so dass Umwelt und Software ebenfalls ein System bilden.

So ist Software ein System, ihre Umwelt ist natürlich ebenfalls ein System oder sogar eine Anzahl von Systemen - und Software plus Umwelt bilden zusammen ein umfassendes System.

Wenn wir über Software reden, reden wir also über geschachtelte Systeme. Jedes System können wir dabei als Ganzes betrachten, als Black Box, oder eben als Zusammensetzung aufeinander operierender Systemstrukturelemente. Wir schauen also entweder auf ein System (Gesamtsicht) oder in ein System (Struktursicht). Wir können also quasi in ein System hineinzoomen.


Jedes Strukturelemente, auf das wir dann beim Hineinzoomen stoßen, kann selbst wieder ein System von Strukturelementen sein – und so weiter und so weiter...


Software ist also eine Hierarchie von ineinandergeschachtelten Systemen von Strukturelementen. Jedes dieser Elemente kann also ein Teil eines größeren Systems sein und gleichzeitig aber auch ein Ganzes, d.h. selbst wieder ein System von kleineren, es konstituierenden Elementen.

Solche „Dinge“, die gleichzeitig Teile und Ganzes sind, hat Arthur Koestler Holon genannt [1]. In dem Begriff fasste er gr. holos für Ganzes und -on für Teil (wie in Proton, Elektron etc.) zusammen, um eine Teil-Ganzes-Dualität einfach handhabbarer zu machen, die überall in der Welt zu finden ist. Eine Hierarchie von Holons bezeichnete er als Holarchie.

Da Softwarestrukturelemente nun ebenfalls gleichzeitig Ganzes und Teile sind, scheint es mir konsequent, sie als Holons anzusehen und Software als Holarchie zu beschreiben. Software-Holons sind aber natürlich etwas ganz anders als Moleküle, Familien oder Gebäude, die ebenfalls Holons in ihren je sehr eigenen Holarchien sind. Deshalb möchte ich sie nicht einfach Holons nennen, sondern Swolons als Zusammenziehung von Software und Holon, die eine Swolarchie konstituieren.

Jetzt mögen Sie fragen, ob es denn wirklich nötig sei, einen neuen Begriff für Software zu prägen? Meine Antwort darauf ist ein entschiedenes Ja. Ja, es ist ein so allgemeiner Begriff wie Swolon für Softwarestrukturelemente nötig, weil die Zahl der konkreten Begriffe inzwischen so groß geworden ist, dass sich eine Verallgemeinerung oder Zusammenfassung lohnt.

Früher gab es nur Programm und Unterprogramm als wesentliche Strukturelemente. In einer Diskussion, die sich um ein Programm drehte, konnte man dann sicher sein, dass über Unterprogramme gesprochen wurde. Aber heute... heute gibt es Klasse, Objekt, Methode, Komponente, Paket, Modul, Prozess, Host, Applikation, Service uvm., um Software zu beschreiben, um Software zusammenzusetzen.

Angesichts dieser Vielfalt, sind allgemeine Aussagen über Software sehr schwer. Sie schreit förmlich danach, durch einen umfassenderen Begriff gezähmt zu werden. Mit dem Begriff Swolon wird deshalb der konkreten Vielheit der „Dinge“ eine allgemeine, vereinheitlichende „Idee“ zugrundegelegt. Das halte ich für konsequent im Sinne einer Bewusstseinsentwicklung der Softwareentwicklungsbranche.

Am Anfang jeder Bewusstseinsentwicklung steht für einen Beobachter immer nur Konkretes, die beobachteten Dinge. Zunächst ist für ihn dabei jedes Ding neu. Ein „Bewusstseinssprung“ tritt dann ein, wenn er zwischen Dingen Ähnlichkeiten wahrnimmt und sie zu einer „Klasse“ zusammenfasst, sie als Manifestationen einer allgemeinen „Idee“ ansieht. Der Beobachter gewinnt dann die Möglichkeit, mit Mengen von Dingen zu operieren wie mit den Dingen selbst. Ideelles wie Mengen werden damit (fast) so greifbar wie die realen Dinge.

Außerdem erlaubt ein allgemeiner Begriff wie Swolon, der zunächst unabhängig von softwaretechnischen Details ist, eine bessere Vergleichbarkeit von Swolarchien mit anderen Holarchien. Lässt sich vielleicht etwas aus biologischen oder sozialen Holarchien für softwaretechnische Holarchien lernen? Solange über Software nur als Ansammlung von Objekten oder Prozessen gesprochen werden kann, fällt es schwer, Parallelen zu ziehen. Ein hierarchiches System von Swolons kann viel leichter mit einem hierarchischen System ganz anderer Arten von Holons verglichen werden.

Schließlich finde ich eine einfache Antwort auf die Frage „Was ist Software?“ wichtig. In der Literatur wie [2] oder [3] finden sich nur recht elaborierte Beschreibungen dessen, was Software ist. Mit dem Begriff Swolon ist hingegen eine simple Definition wie „Software ist eine Holarchie bestehend aus Systemen von kommunizierenden Swolons“ möglich. Holarchie, System, Kommunikation und Swolon sind dann zwar zu erklären, aber die „Wurzeldefinition“ für Software ist simpel. Insbesondere weisen Holarchie und Swolon schon darauf hin, dass Software auf verschiedenen Abstraktionsebenen betrachtet werden kann.

Software ist meist ein komplexes System und ein sehr probates Mittel, um Komplexität zu bewältigen, sind Hierarchien. Interessanterweise gehen Softwareentwickler zwar oft mit Datenbäumen um, aber die konsequente Beschreibung von Software selbst als Hierarchie (oder Holarchie) ist ihnen kaum geläufig. Es fehlt ihnen einfach das Bewusstsein von Software als System. Sie sehen vor allem Bäume, aber kaum den Wald oder die Landschaft, die Region oder gar das Land, in dem sie sich bei der Entwicklung einer Software bewegen.

Mit dem konsequenten „Denken in Swolons“ wird das aber hoffentlich leichter. Swolons legen die Beschreibung von Software auf verschiedenen Abstraktionsebenen einfach nahe, weil sie frei machen von all dem, was bei Objekten, Komponenten, Prozessen immer sofort mitschwingt.

Swolons machen ein nötiges systemisches Denken über Software (endlich) möglich. Sie leisten einer Softwarearchitektur-Disziplin Vorschub, die (zunächst) unabhängig von den Niederungen der Implementation Strukturen planen kann.

Ressourcen
[1] Arthur Koestler, The Ghost in the Machine, Arkana 1989, 7. Auflage, ISBN 0140191925
[2] O. Vogel et al., Software-Architektur, Spektrum Akademischer Verlag 2005, ISBN 3827415349
[3] Jochen Ludewig, Horst Lichter, Software Engineering, dpunkt.verlag 2007, ISBN 3898642682

[Vorhergehender Artikel] [Nächster Artikel] [Artikelserie]