Komplexität beherrschen

Software ist komplex und wird immer komplexer. Worin die Komplexität liegt? Nun, sie entspringt der "Systemhaftigkeit" von Software. Dazu mehr in meiner Serie "Software als System".

Wie können wir nun aber mit Komplexität umgehen? Wir müssen sie beherrschen, wenn wir immer leistungsfähigere Software entwickeln wollen.

Ein altbewährtes Mittel zur Bewältigung von Komplexität ist sicherlich die Bildung von Hierarchien. Etwas komplexes wird zerlegt in Teile, die weniger komplex sind. Falls die immer noch zu komplex sind, um sie handhaben zu können, werden sie wiederum zerlegt in kleinere, weniger komplexe Teile usw. Stepwise refinement und rekursive Dekomposition führen zu Softwaresubsystemen, von denen man das Gefühl hat, sie zu beherrschen - so dass man in Summe auch das zu komplexe Ganze beherrscht.

Ein weiteres Mittel gegen Komplexität ist Ordnung. In einem komplexen Gebilde systematisiert sie die Teile und ihre Verbindungen. Sie ist Voraussetzung für die Möglichkeit zur Information über ein System. Dem liegt der Gedanke zugrunde, dass der Informationsgehalt einer Aussage umso höher ist, je mehr sie dazu beiträgt, vom Kleinen/Einzelnen auf das Große/Ganze zu schließen. Beispiel: In einer unaufgeräumten Küche, d.h. einer Küche mit weniger Ordnung, hat die Aussage "In jener Schublade liegt die Gabel" wenig Informationsgehalt. Im Extremfall erfährt man durch sie nur etwas über eine einzige Gabel. Ist die Küche jedoch gut strukturiert, d.h. sie ist "in Ordnung"/ordentlich, dann kann man von der Aussage nicht nur auf den Ort weiterer Gabeln schließen, sondern weiß wahrscheinlich auch wo die Löffel liegen.

Wissen/Bildung ist wiederum ein Mittel, um Ordnung herzustellen bzw. zu erkennen. Wer weiß, wie ein Flugzeug funktioniert, sieht die Ordnung in den Bedienelementen im Cockpit; wer es nicht weiß, der fühlt sich überwältigt von der Komplexität. (Weiter)Bildung ist somit ein indirektes und allgemeines Mittel zur Beherrschung von Komplexität.

Soweit zwei sehr bekannte und mehr oder weniger bewusst in Gebrauch befindliche Mittel zur Reduktion von Komplexität. Zwei andere sind mit allerdings erst in der letzten Zeit aufgefallen, die ich für bisher unterbewertet halte: Wissenschaftlichkeit und Vertrauen.

Wissenschaft strebt nach einer objektiven, vom Individuum unabhängigen Sicht auf die Welt. Ihre methodischen Standards wollen Erkenntnisse nur dann gelten lassen, d.h. zum kollektiven Modell über die Welt hinzufügen, wenn sie intersubjektiv übertragbar sind. Die Gesamtkomplexität der "Weltwahrnehmungen" aller Individuen sowie ihre jeweils eigene Komplexität und die ihrer sozialen System wird dabei reduziert auf das, was nachvollziehbar und reproduzierbar ist. Nicht, was der eine oder andere in der Welt zu sehen vermeint, gilt, sondern nur der reproduzierbare Konsens. Auf die Softwareentwicklung übertragen bedeutet das: Nicht das, was Projektteammitglieder im Kopf haben ist "wahr", sondern das, was für alle nachvollziehbar ist. Nur "Experimente" (z.B. Tests), die von unterschiedlichen Individuen an womöglich unterschiedlichen Orten reproduziert werden können, sagen etwas über die Coderealität aus. Das wiederum bedeutet, dass "Experimente" möglichst automatisch und kontextfrei ablaufen sollten.

Und schließlich hilft Vertrauen, mit Komplexität umzugehen. Denn Menschen und Code-Subsystemen, denen man vertrauen kann, muss man nicht im Detail kennen. Man muss sich mit ihrer inneren Komplexität nicht auseinandersetzen; das tun andere. Wie kann Vertrauen als Mittel zur Reduktion von Komplexität Eingang in die Softwareentwicklung finden? Indem zunächst einmal Subsysteme und Organisationseinheiten geschaffen werden, zu denen man überhaupt Vertrauen aufbauen kann. Ohne klar erkennbaren Einheiten hätte Vertrauen kein Ziel. Subsysteme sind dabei als Black Boxes (Komponente) zu sehen, die eine klare Aufgabe (Kontrakt) haben, auf deren Erfüllung man vertrauen kann. Und Organisationseinheiten (Komponentenentwickler) müssen klare Verantwortlichkeiten haben, auf deren Erfüllung man vertrauen kann. Wo Komponentenorientierung und klare Verantwortlichkeiten fehlen, vergibt man sich die Chance auf Reduktion von Komplexität durch Vertrauen.

-Ralf

Das Intuitive Datenmodell III - Container als Dokumente

Im Intuitiven Datenmodell (IDM) sind alle Werte einzigartig. Es gibt nur einen Vornamen "Peter" und nur einen Preis 12,34, egal in wievielen Containern diese Daten vorkommen. Aber das gilt nicht nur für solche atomischen Daten, sondern auch für Zusammensetzungen!

Um das zu verdeutlichen, nehmen Sie eine relationale Datenbank mit einer Tabelle für Personen an:

Personen(Vorname, Nachname)

In der Tabelle stehen einige Datensätze:

Personen("Peter", "Mustermann")
Personen("Frank", "Müller")
Personen("Gabi", "Mustermann")
Personen("Gabi", "Müller")
Personen("Susanne", "Frank")

"Gabi" und "Frank" und "Mustermann" sind in der relationalen Datenbank selbstverständlich mehrfach enthalten, weil sie ja in mehreren Datensätzen vorkommen. Nicht so aber in einer intuitiven Datenbank (IDB)! Dort gibt es alle Zeichenketten nur einmal - unabhängig davon, wie sie in Containern gebraucht werden, d.h. ob sie einen Vornamen oder einen Nachnamen darstellen.

"Gabi" usw. sind im IDM atomische Werte (Atomic Value, AV). Für eine IDB sind sie quasi unteilbar, sozusagen kleine Blobs ohne weitere Struktur. Sie entsprechen den Spalten im Relationalen Datenmodell oder Feldern in Klassen des Objektorientierten Datenmodells.

Die Zusammensetzungen solcher AVs sind, wie könnte es anders sein, zusammengesetzte Werte (Composite Values, CV). Anders als im Relationalen Datenmodell sind CVs allerdings beliebig tief schachtelbar. Die Schachtelungstiefe in einer relationalen Datenbank ist flach: Tabelle/Satz/Spalte. Das war´s. Bei Klassen ist es etwas anders, da können Felder Strukturen (struct) enthalten, die wiederum Strukturen enthalten können usw. Objekte sind in anderen allerdings nicht physisch enthalten wie Datensätze in Tabellen. Wenn man davon spricht, dass ein Objekt ein anderes enthält, dann ist das nur eine logische Enthalten-Beziehung, die durch Referenzen hergestellt werden muss.

Das IDM steht mit seiner beliebig tiefen Schachtelung, die keiner Ebene irgendeinen Vorrang gibt, daher dem XML Datenmodell am nächsten. Deshalb möchte ich die "Dateneinheiten", die man einer IDB zur Speicherung übergibt oder aus ihr ausliest, auch Dokumente nennen. Damit soll natürlich keine Nähe zu Word- oder Excel-Dokumenten suggeriert werden. Dokumente sind einfach nur Zusammenfassungen von Werten in einer für einen bestimmten Zweck geeigneten Struktur. Ob diese Werte dann Kalkulationen oder eine Bibliographie oder Kontaktdaten darstellen, ist unerheblich. Alles kann zu einem Dokument zusammengefasst werden. Und alles kann auch in immer wieder neuen Dokumenten zu einander in Bezug gesetzt werden.

Die obigen Daten könnten einer IDB also z.B. in Form mehrerer Dokumente zur Speicherung übergeben werden. Das IDM basiert nicht auf XML, aber ich kann XML zur Beschreibung von IDB Dokumenten benutzen. Dann sähen die Dokumente für die obigen Daten z.B. so aus:

<Person>
<Vorname>Peter</Vorname>
<Nachname>Mustermann</Nachname>
</Person>

oder

<Person vorname="Peter" nachname="Mustermann"/>

Atomische Werte könnten als Subelemente oder als Attribute notiert werden.

Aber auch eine knappere Notation ist möglich, die eher der obigen für die Tabellen entspricht:

Person(Vorname("Peter"), Nachname("Mustermann"))

Sie steht XML ins nichts nach. Auch mit ihr kann ich Schachtelungen ausdrücken:

Personen(
Person(Vorname("Peter"), Nachname("Mustermann"))
Person(Vorname("Klaus"), Nachname("Müller"))
)

Welche Notation ich im Folgenden benutze, hängt wahrscheinlich von meiner Tagesform ab ;-) Beide sind einfach zu lesen, denke ich.

Eine Abbildung nach XML ist mir vor allem wichtig, um zu zeigen, dass das IDM nicht nur "outspacet" ist. Wer XML kann, der hat im Grunde von viel vom IDM verstanden.

Und eine Abbildung auf zwei Notationen ist mir wichtig, um klar zu machen, dass das IDM eben letztlich notationsunabhängig ist. Beim IDM geht es nicht wie bei XML ursprünglich nur um Text. Es geht um ein Werteuniversum - dessen Inhalt sich auch in eine textuelle Dokumentenwelt abbilden lässt. Denn wie die Dokumente bzw. Daten intern abgelegt sind, ist unerheblich für das Intuitive Datenmodell. Es muss nur verwirklicht sein. Insofern ist auch eine objektorientierte Schnittstelle denkbar, z.B.

IIntuitiveDatabase db;
...
ICompositeValue person = db.CreateCV("Person");
person.Subvalues.Add(db.CreateAV("Vorname", "Peter"));
person.Subvalues.Add(db.CreateAV("Nachname", "Mustermann"));
...
db.Store(person);

Aber das sind im Augenblick Details. Wichtig ist, dass IDBs Dokumente speichern und liefern. Allerdings werden diese Dokumente nicht 1:1 in einer IDB abgelegt. Eine IDB speichert ja keine Kopien von Daten. Vielmehr werden die Dokumente "geshreddert" und so mit den schon vorhandenen Dokumenten "verwoben", dass den Bedingungen des IDM Genüge getan ist. Statt speichern würde ich eher sagen, dass IDBs Dokumente assimilieren. Sie nehmen sie auf, machen sie sich zu eigen - aber die Dokumente selbst verschwinden in dem Vorgang. Sie sind in der IDB nicht mehr ohne Weiteres erkennbar. Selbstverständlich kann man sie aber dennoch wieder herausbekommen ;-) Das Speichern von Daten in einer IDB ist insofern verlustfrei.

Wenn ich sage, dass die Dokumente bei der Assimilierung verschwinden, dann möchte ich damit vor allem ausdrücken, dass eben keine einfachen Kopien von Daten in einer IDB abgelegt werden. Wenn ich Daten einer relationalen Datenbank hinzufüge (z.B. Personen mit jeweils mehreren Adressen), dann führt das quasi immer dazu, dass neue Datensätze erzeugt werden. Füge ich ein Dokument mit demselben Inhalt einer IDB hinzu, dann kann es aber sein, dass nichts passiert oder nur sehr wenig. Denn wenn ein neues Dokument Werte enthält, die schon assimiliert wurden, dann werden die eben nicht nochmals in der IDB angelegt.

Insofern würde ich auch nicht sagen, dass in einer IDB diese oder jene Dokumente stecken. Die Dokumente A, B und C mögen assimiliert worden sein. Sie sind also schon in der IDB irgendwie drin und können auch wieder herausgeholt werden. Viel wichtiger ist aber das große Ganze, das durch die Assimilation entstanden ist. Aus dem können nämlich nicht nur A, B und C wieder generiert werden, sondern auch noch viele andere, neue, unvorhergesehene Dokumente, die sich quasi "einfach so" ergeben, weil A, B und C Gemeinsamkeiten aufweisen.

Diese Gemeinsamkeiten müssen dabei nicht nur bei AVs liegen, sondern können auf jeder Ebene eines Dokuments, d.h. bei den CVs liegen. Das (!) ist der entscheidende Unterschied zu einer relationalen Datenbank oder einer XML-Datenbank.

Kaffeehauskonsultation in Ulm

Am 20. März, 10h-17h, lade ich wieder zur Kaffehauskonsultation ein. Diesmal in Ulm, denn die dortige .NET User Group hat mich gebeten, einen Vortrag zu halten. Und vorher können Sie mich im Café BellaVista über den Dächern von Ulm mit Fragen löchern.

Melden Sie sich einfach per Email bei mir, wenn Sie einen der max. 90-minütigen, kostenlosen Beratungstermine ergattern wollen. Ich bin gespannt auf Ihre Problemfelder und freue mich auf Sie!

Wider dicke Fachbücher - Die Wahrheit liegt in der Vielfalt

Schon lange hege ich ja eine gewisse Aversion gegen dicke Fachbücher. 500, 800, 1000 Seiten versprechen lückenloses Wissen und mehr Programmier-Rezepte, als jeder Leser ausprobieren kann. Heute nun bin ich darauf gekommen, was diese Aversion in mir auslöst: ihr Anspruch auf Wahrheit.

Dicke Fach- oder auch Sachbücher suggerieren, sie würden die "ganze Wahrheit" zu einem Thema enthalten. Sie flüstern vom Buchhandlungsregal herab, "Kauf mich und du musst kein zweites Buch zum Thema lesen." Sie versprechen, "So, wie ich es darstelle, ist es! Lückenlos."

Und wer würde das nicht gern glauben? Dicke Bücher zu lesen ist zwar nicht bequem - man kann sie nur schwer mit ins Bett nehmen -, aber für "letzte Wahrheiten" ist man dann doch bereit, etwas Unbequemlichkeit auf sich zu nehmen. Immerhin winkt Seelenfrieden als Lohn der Mühe. Denn wo soviel Wahrheit drin steht, muss man ja nicht mehr zweifeln, ob man nicht etwas anderes hätte wählen sollen. Man hat dem Thema seine Schuldigkeit getan. Außerdem sind dicke Bücher im Verhältnis preisgünstiger als dünne.

Das ultimative dicke Buch war sicherlich die Encyclopaedia Britannica: ein Buch bzw. eine Veröffentlichung, die versprach, das Wissen der Welt zwischen Buchdeckeln für jedermann zugänglich zu machen. Auch ich war dieser Einflüsterung in den 1980ern erlegen und hatte für viel Geld die damals aktuelle Britannica erworben. Sie war lange die Zier meiner Buchregale.

Aber schon damals war ihr Versprechen hohl. Sie konnte nicht annähernd "die" Wahrheit über die Welt enthalten. Und genausowenig kann ein Buch die Wahrheit über ASP.NET- oder ADO.NET-Programmierung enthalten. Das geht nicht, weil die Themen zu umfangreich sind. Es gibt zuviele Aspekte, die es zu beachten gilt.

Den 800+ Seiten haftet einfach die latente Arroganz eines "So ist es! Ich weiß es." an. Das aber ist unzeitgemäß. Nicht nur in Beziehungen beginnt die Wahrheit zu zweit. Auch in der (scheinbar) so rationalen Softwarebranche ist Wahrheit kein zu entdeckendes Faktum, sondern ein Prozess. Wahrheit entsteht nur im Diskurs.

Wahrheit ist deshalb von Natur aus flüchtig und hat eine Lebensdauer. Bücher und allemal dicke Fachbücher haben dagegen den Anspruch zu überdauern. Das ist allemal ein Widerspruch in der Softwarebranche, in der die Wahrheit notwendig noch flüchtiger als in anderen Branchen ist, weil ihre Grundlagen, die Konzepte und Technologien, eine so extrem kurze Halbwertszeit haben.

Je größer und häufiger die "Bewegungen" in einem Wissensbereich, desto unpassender sind also die auf Dauer und umfassende Wahrheitsvermittlung ausgelegten dicken Bücher. Oder andersherum und konkreter: Weil sich in der Softwarebranche ständig soviel tut, die Wahrheiten also konstanter Änderung unterliegen, sollten ihre Fachbücher dünn bleiben.

Dünne Bücher lassen sich schneller schreiben, schneller lesen, schneller ersetzen. Und ich meine, dass sie unterm Strich auch nicht teurer als dicke Bücher sind oder sein müssen. Im Gegenteil! Dünne Bücher sind ehrlicher, weil sie keine umfassende, allein seligmachende Wahrheit verkünden. Leser laufen also weniger Gefahr, sich später (schmerzhaft) desillusionieren zu müssen. Das spart Zeit und damit Geld.

Was ist nun aber der richtige Umfang für ein Fachbuch? Das hängt sicherlich vom Thema ab. 150, 250, vielleicht auch noch 400 Seiten mögen angemessen sein. Jenseits dessen beginnt für mich aber der Zweifel, ob ein Fachbuch seinem Anspruch gerecht werden kann. Aufwand und Flüchtigkeit der Wahrheit in der Softwarebranche stehen dann in keinem Verhältnis mehr.

Das macht meine zunehmende Aversion gegen dicke Fachbücher aus. Ich bin für mehr dünne Fachbücher, für mehr Vielfalt, für mehr Diskurs.

PS: Bin grad wieder über ein hübsches Posting gestolpert. Da wird auch das Übel der dicken Fachbücher beklagt.

.NET meets Apple - oder: Was man mit dotnet TV so alles werden kann

Erinnern Sie sich noch an dotnet TV? Die erste deutsche Videoserie für die .NET-Entwicklergemeinde? Seufz... Schön war die Zeit, Spaß hat´s gemacht. Schnief...

Wir waren aber auch ein gutes Team, der Sebi (Sebastian Baumgartner) und ich. Wir kannten uns schon seit einem Jahrzehnt, hatten uns einige Jahre aus den Augen verloren, dann aber in München wieder getroffen. Sebi war inzwischen eine Größe in der Inline Skating Community geworden und hatte Lust, seine Erfahrung mit der Digitalkamera aus dem Sportbereich auch einmal anders zum Einsatz zu bringen. Also haben wir zusammen dotnet TV gemacht. Und Sebi hat sich echt ins Zeug gelegt, wie man sieht...

Früher... ja, früher, da gab es auch noch den alten Apple Computer... Schön war die Zeit. Schnief. Darauf habe ich meine ersten Programmierschritte gemacht. Und meine Helden waren - wie könnte es anders sein - Steve & Steve. (Von Bill & Steve hatte ich damals, 1981?, noch nichts gehört.)

Quelle: www.cedmagic.com

Ja, so war das damals. Da wurden Computer noch in einer Holzkiste geliefert. Handwerk met Hightech. Seufz... Da war Programmieren noch etwas für den haptischen Typen. Heute dagegen... Heute verkauft der eine Steve keine Holzkisten mehr, sondern Kleinststereoanlagen und Kleinstfernseher.

Quelle: www.clubic.com

Und was macht der andere Steve? Tja, der andere Steve reist durch die Welt und trifft sich z.B. mit... Sebi. Wem sonst? ;-)

Nachdem dotnet TV leider aus Budgetgründen eingestellt werden musste, hat Sebi seine dort (naja, und auch anderswo) gewonnene Medienerfahrung gewinnbringend eingesetzt und ist nun Organisator des alljährlichen Volvo Sports Design Forums der ISPO München. Und in dieser Position hat er neulich den anderen Steve, Held meiner Jugend, getroffen.

Nun ist Sebi nicht mehr so recht in der .NET-Welt unterwegs. Und Steve Wozniak ist nicht mehr so recht in der Apple-Welt unterwegs. Dennoch würde ich sagen: Irgendwie hat jetzt .NET Apple getroffen :-) Irgendwie haben sich jetzt zwei Kreise von früher geschlossen. Schön!

Cool gemacht, Sebi! Weiter so! :-)

Das Intuitive Datenmodell II - Es kann nur einen geben

Wie im ersten Artikel beschrieben, halte ich die grundsätzliche Container-Referenz-Dichotomie aller existierenden Datenmodelle für ein ebenso grundsätzliches Problem. Sie ist wie eine gläserne Decke: Wir können durch sie Problemlösungen in weiter ferne sehen - aber sie lässt sie uns nur schwer oder gar nicht erreichen.

Prinzipiell, ganz prinzipiell mag sich womöglich jedes Datenmodellierungsproblem mit jedem existierenden Datenmodell irgendwie realisieren lassen. Genauso ist es aber prinzipiell auch möglich, jede Software in Maschinencode zu schreiben.

Ob die heutigen Datenmodelle ausreichend für die Zukunft sind, lässt sich daher nicht anhand dessen entscheiden, ob sich prinzipiell alle Modellierungsprobleme mit ihnen bewältigen lassen. Ihre Eignung ist vielmehr immer wieder (auch) an der Leichtigkeit zu prüfen, mit der sich Lösungen auf ihrer Grundlage finden lassen. Und genau da sehe ich Grenzen.

Etwas greifbarer werden diese Grenzen vielleicht mit folgendem Bild:

Container können gewöhnlich ineinander geschachtelt werden, aber eine Beziehung lässt sich zwischen ihnen nur auf einer Ebene aufbauen. Objekte können nur andere Objekte referenzieren und nicht Teile von Objekten. Dasselbe gilt für Datensätze in relationalen Datenbanken. Nur bei XML ist es etwas anders: Dort kann jedes Element in beliebiger Schachtelungstiefe mit einer ID versehen werden, auf die woanders Bezug genommen werden kann.

Die außer bei XML stark beschränkte Schachtelungstiefe im Verein mit nur einer adressierbaren Ebene von Containern macht es schwierig, Daten zu modellieren. Welche Daten sollten echt ineinandergeschachtelt werden? Welche Daten sollten besser über Referenzen verbunden werden?

Diese Fragen stellen sich, solange überhaupt noch eine Entscheidung zwischen Container und Referenz getroffen werden muss. Was aber, wenn diese Entscheidung überflüssig würde? Was, wenn es nur noch ein Konzept gäbe? Das ist die Idee hinter dem Intuitiven Datenmodell (IDM) bzw. einer es implementierenden Intuitiven Datenbank (IDB, Intuivite Database).

Eine Datenwelt nur noch bestehend aus Containern
Im Intuitiven Datenmodell gibt nur noch Container. Das IDM kennt keine Referenzen mehr. Alle Daten bestehen aus einer beliebig tief geschachtelten Menge von Containern - oder besser: Daten werden als eine Hierarchie von Werten angesehen. Im IDM gibt es nur noch Werte.

Allerdings haben diese Werte eine ganz besondere Eigenschaft: sie sind immer einzigartig. In einer IDB existiert jeder Wert nur einmal! Das IDM beschreibt daher ein "universe of unique values". Sie können es von daher auch als mathematische Menge auffassen. Z.B. gibt es in der Menge der natürlichen Zahlen jede Zahl nur einmal.

Allerdings unterscheidet sich das IDM auch gravierend von einer mathematischen Menge. Denn in einer IDB ist nicht nur jedes "Element", jeder Wert einzigartig, sondern kann selbst wieder Werte enthalten, die dann ebenfalls zur IDB gehören. Ein Wert selbst ist allerdings keine Menge, d.h. er kann den selben Wert mehrfach enthalten. Dennoch ist dieser eingeschachtelte Wert in einer IDB nur einmal vorhanden.

Das IDM kennt zunächst zwei Arten von Werten: atomische Werte (Atomic Values, AV) und zusammengesetzte Werte (Composite Values, CV).

Einn AV ist unteilbar und enthält keine weiteren Werte.

Ein CV hingegen besteht aus anderen Werte, die zusammen seinen Wert ausmachen. Der Wert eines CV ist quasi die "Summe" der in ihm enthaltenen Werte (Subwerte).

Da eine IDB jeden Wert nur einmal enthalten kann, lassen sich Werte auch als Identitäten auffassen. Die Identität eines CV ist dann zusammengesetzt, so wie die Identität einer Gruppe von Menschen auch zusammengesetzt ist aus den Identitäten der einzelnen Personen.

Während der Wert eine AV jedoch noch quasi gleichgesetzt werden knn mit den rohen Daten, die er enthält (z.B. ein Name oder eine Telefonnummer oder ein Preis), so ist der Wert eines CV schnell nur noch abstrakt zu fassen; es wäre unhandlich, ihn als Verknüpfung seiner Subwerte zu notieren.

CVs sind genauso einzigartig wie das, für was sie in der realen Welt stehen. Und das ist ein erstes Indiz dafür, warum ich das Datenmodell als intuitiv bezeichne.

In der realen Welt gibt es nur Einzigartiges. Jeder Mensch, jedes Blatt am Baum ist einzigartig, jedes Auto, jeder Bleistift ebenso. Und wenn zwei Dinge noch so gleich aussehen, so sind sie doch nicht dieselben. Selbst eine exakte Kopie, selbst ein geklontes Lebewesen hat eine eigene Identität. Alles Materielle gibt es also nur einmal.

Und genau diesen Umstand, mit dem wir alle täglich souverän umgehen, übertragt das IDM in die Welt der Datenmodellierung. Eine IDB enthält keine Kopien so wie relationale Datenbanken oder Objektmodelle. In einer IDB ist alles einzigartig.

Und das hat Folgen... die ich aber erst im nächsten Artikel beschreiben will.

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]