Follow my new blog

Montag, 5. März 2007

Software als System V - Was ist ein Swolon?

Software besteht aus Swolons, habe ich in meinem letzten Posting zum Thema "Software als System" einfach mal so definiert. Spannend dabei ist, dass Swolons nicht nur eine Software als Ganzes ausmachen, sondern selbst wiederum aus Swolons bestehen. Von einer ganz allgemeinen Warte aus betrachtet, ist Software also eine Hierarchie von verschalteten Bausteinen, die wiederum aus verschalteten Bausteinen bestehen, die wiederum aus verbundenen Bausteinen bestehen usw. Software ist damit rekursiv definiert. Hier eine vereinfachende textuelle Definition in EBNF:

Software ::= Swolonsystem .
Swolonsystem ::= Swolon { Swolon } .
Swolon ::= Swolonsystem .

Die Produktionsregel Swolonsystem definiert sich indirekt rekursiv selbst.

Einheiten von Funktionalität und Zustand

Was ist denn nun aber ein Swolon außer, dass es wieder aus anderen Swolons aufgebaut ist? Ein Swolon hat zwei Gesichter: es vereinigt Funktionalität und Daten.

Wenn Sie nun denken, dass ein Swolon dann doch irgendwie ein Objekt ist... dann liegen sie nicht ganz falsch. Ein Swolon hat selbstverständlich ganz bewusst diese Eigenschaften heutiger Objekte, die auch Funktionalität und Daten zusammenfassen, wo früher Prozeduren und Datenstrukturen nebeneinander standen.

Aber ein Swolon ist viel allgemeiner als ein Objekt. Nicht ein Swolon ist ein Objekt, sondern ein Objekt ist ein Swolon.

Für mich ist Software einfach aus einer Hierarchie von Systemen von "Dingen" aufgebaut, die Funktionalität implementieren, d.h. eine Dienstleistung verkörpern, und gleichzeitig natürlich auch Informationen halten können, die zu ihrer Funktionalität gehören. Ganz allgemein können diese Informationen als der Zustand eines Swolon bezeichnet werden.

Daraus ergibt sich natürlich, dass Swolons mehr oder weniger Funktionalität bieten und mehr oder weniger Zustand halten können. Es gibt also ganz allgemein gesprochen Swolons, die zustandslos sind und nur reine Dienstleistung anbieten, die sozusagen keine eigene Erinnerung hat. Und es gibt ganz allgemein gesprochen Swolons, deren Aufgabe es ist, nur Zustand zu halten und keine Funktionalität über den Zugriff auf diese Daten hinaus anzubieten.

Zustandslose Geschäftslogik wie sie oft für den Einsatz in Applikationsservern entworfen wird und Data Transfer Objects (DTO) wie sie für den Transport von Daten zwischen den Tiers in verteilten Anwendungen benutzt werden, können also ganz wunderbar auch mit meiner Swolon-Terminologie beschrieben werden.

Wenn man das Swolon als ganzes betrachtet, dann ist es eine Black Box. Dann interessiert es nicht, wie es seinen Zustand hält und seine Leistung erbringt. Wenn man jedoch in ein Swolon hineinschaut, dann sieht man das System von Swolons (oder Sub-Swolons), die für die Zustandshaltung und/oder Funktionalität zuständig sind.

System durch Operationen

Zu einem System wird eine Ansammlung von Swolons erst, wenn sie aufeinander operieren. Swolons, die einander nur kennen, d.h. eine irgendwie geartete Referenz halten, sind zwar auch verbunden, aber diese Verbindungen sind recht uninteressant. Solange diese Verbindungen zuu nichts weiter dienen, tragen sie nicht zur Komplexität eines Swolonsystems bei.

Verbindungen müssen leben, d.h. sie müssen die Bahnen sein, entlang derer Swolons aufeinander zugreifen und Leistungen voneinander nutzen. Dann entsteht ein lebendiges System. Nehmen Sie als Analogie Nervenzellen. Solange Nervenzellen nur miteinander verbunden sind, nützen sie nichts; der Organismus ist tot. Sobald entlang der Verbindungen aber Impulse laufen, lebt ein Organismus. Genauso ist es mit einer Swolarchie.

Verbindungen zwischen Holons können unidirektional oder bidirektional sein. D.h. Operationen laufen immer nur von einem Swolon zum anderen oder in beide Richtungen. Die Operationen auf Holons sind dann entweder zustandsneutral oder zustandsverändernd. Je weniger die Operationen auf einer Verbindung zwischen Swolons zustandsverändernd sind, desto entkoppelter sind die Swolons. Kopplung ist also ein Maß dafür, wieviel Einfluss ein Swolon auf den Zustand eines anderen hat.

Kopplung sorgt für Komplexität

Kopplung ist daher für mich ein wesentlicher Faktor bei der Beurteilung der Komplexität eines Systems. Roger Sessions hat in einem Artikel versucht, Komplexität mit Würfeln zu erklären. Seine These: Eine Münze ist weniger komplex als ein Würfel, weil eine Münze nur zwei Zustände einnehmen kann, ein Würfel aber sechs. Und drei Würfel zusammen sind komplexer als ein Würfel, weil sie 6*6*6=216 Zustände einnehmen können. Daraus leitet er dann ab: Wenn man ein komplexes System besser handhabbar machen will, dann muss man es in Partitionen teilen. Aus den 216 Zuständen des komplexen gesamten Würfelsystems könnten so 6+6+6=18 Zustände eines viel weniger komplexen partitionierten Würfelsystems werden:


Quelle: Microsoft

Auch wenn ich mit Roger Sessions Schlussfolgerung übereinstimme, so bin ich mit seiner Erklärung nicht einverstanden. Ich halte sein Ausgangsbeispiel der drei Würfel für zu simpel. Platt gesagt: Eine Münze und ein Würfel und drei Würfel, wie er sie darstellt, sind für mich gleich un-komplex. Sie sind nicht unterschiedlich komplex, sondern allerhöchstens unterschiedlich kompliziert. Ein 216-seitiger Würfel wäre für mich auch nicht komplexer als die drei 6-seitigen Würfel.

Zur Komplexität fehlt den Würfeln nämlich etwas: eine Verbindung. Die Würfel bilden kein System, weil sie nicht verbunden sind. Und selbst wenn sie verbunden wären, dann käme es darauf an, wie stark gekoppelt sie dann wären.

Komplexität ist also nicht einfach eine Frage der Anzahl von Zuständen, wie Roger Sessions darstellt, sondern eine Frage der Anzahl der Verbindungen und der Stärke der Kopplung entlang dieser Verbindungen.

Seine Systeme A..D sind also keine Systeme. Erst Systeme E und F sind Systeme, weil ihre Strukturbestandteile verbunden sind.

Ob sie allerdings komplex sind, hängt davon ab, ob die Änderung am Zustand eines Strukturelements eine Änderung des Zustands in anderen nach sich zieht. Kann ich einen Würfel werfen, ohne dass sich dadurch die Augenzahl der anderen ändert? Dann ist seine Verbindung zu den anderen losen und das System nicht komplex. Wenn der Wurf eines Würfels aber die Änderung der Zustände eines oder mehrerer anderer Würfel nach sich zieht... dann wird das System interessant - und komplex. Jenachdem wie die Kopplungen ausgelegt sind, wird der Zustand des Gesamtsystems mehr oder weniger schwer vorhersagbar. Und das (!) ist es, was Komplexität ausmacht.

Roger Sessions System C mit seinen 216 Zuständen ist viel weniger komplex, als ein echtes System von z.B. drei Münzen wäre, die miteinander nicht nur verbunden, sondern gekoppelt wären, und das nur 2*2*2=6 Zustände hätte.

Die Komplexität einer Swoloarchie hängt daher nicht nur von der Zahl der Verbindungen zwischen den Swolons ab, sondern von deren Zustandsreichtum und der Stärke der Kopplung.

Was Roger Sessions daher vorschlägt mit dem Begriff der Partionierung, ist die Reduktion der Kopplung von Systembestandteilen. Er plädiert für eine Komplexitätsreduktion durch bewusste Planung und Kontrolle von Verbindungen zwischen zustandsreichen Systembereichen.

Zu den von mir an anderer Stelle genannten Mitteln zur Beherrschung von Komplexität müssen also noch das "Beziehungsmanagement" und die "Zustandsplanung" treten.

Zum "Beziehunsgmanagement" gehört z.B. das Schichten-Entwurfsmuster. Es ordnet die Verbindungen zwischen Swolons. Swolons einer Schicht sind mit denen darunterliegender nur unidirektional verknüpft.

Das N-Tier Architekturmuster für verteilte Anwendungen geht dann noch einen Schritt weiter. Es bezieht die Zustandsplanung mit ein und plädiert für eine Entkopplung von Swolons in unterschiedlichen Tiers, d.h. physischen Schichten. Swolons in der Geschäftslogik sollen vorzugsweise zustandslos sein. Sie sollen also zur Komplexität des Systems bestehend aus den Tiers Frontend-Geschäftslogik-Datenzugriff möglichst wenig beitragen.

Zusammenfassung

Swolons sind Kombinationen aus Funktionalität und Zustand. Ihre Verbindungen können uni- oder bidirektional sein. Operationen entlang dieser Verbindungen spannen ein System von Swolons auf und sind entweder zustandsneutral oder zustandsverändernd.

Aber das ist natürlich noch nicht alles, was sich zu Swolons und ihren Verbindungen sagen lässt...

Kommentare:

Dennis hat gesagt…

Hrm... den Würfel gibt es doch gar nicht :-)

Wozu auch?
Wir denken ja in Swolons jetzt ;-)

Und nach etwas überlegung behaupte ich mal, dass Münze = Würfel = Würfelautomat ist.
Alle bestehn aus den Swolon "Seiten".
Welcher aus den Atom True oder False besteht daher nicht mehr als ein Container ist.

Das schöne ist jede Seite interessiert nicht ob es noch andere gibt :-)

Was ist jetzt noch nicht verstanden habe Ralf ist:

Ein Swolon kann sowohl Container sein wie auch Funktion.
Also müsste ein Swolon auch Portal sein können.
Was wiederrum bedeuten würde, das die Münzen nicht miteinander Kommunizieren müssen sonder nur mit den jeweiligen Portal-Swolon.
Sind die Striche schon jene Portal-Swolons oder muss man die extra Zeichnen?

Was ist wenn wie in dem Fall eine Dynamische Anzahl von Münz-Swolons angenommen werden kann?
Legt man in der Zeichnung eine Fixe fest (mind. zwei wohl) oder wie zeichnet man sowas?

Ist eine solide Basis-Klasse, welche im Grunde nur Modifizierte Portale brauch besser als zich verschiedene Klassen die aufeinander aufbauen und erben?

Ralf Westphal - One Man Think Tank hat gesagt…

@Dennis: Genau, ein Swolon kann Container oder Dienstleister sein. Bei einem Container-Swolon liegt die Betonung auf seinem Zustand, beim Dienstleister auf seiner Funktionalität.

Ein Swolon kann natürlich auch Portal im Sinne des Softwarezellenmodells sein. Aber Portal oder Adapter oder Logik usw. sind orthogonal zu Container bzw. Dienstleister.

Bei Container/Dienstleister geht es um den "Funktionalitätsgehalt", bei Portal/Adapter geht es um die Art (!) der Funktionalität, den Zweck eines Swolons im Rahmen einer Architektur in Bezug auf den Kontakt mit der Umwelt einer Software.

Striche sind keine Swolons, sondern Verbindungen zwischen Swolons.

Auch Portal-Swolons müssen natürlich mit anderen Verbunden sein. Ein Portal allein ist sinnlos. Da fehlt ja die Anwendungslogik (egal wie minimal die ist).

Beim Zeichnen ist zwischen Entwicklungszeit und Laufzeit zu unterscheiden. In einer Grafik kann daher ein Swolon mit einem anderen Verbunden sein - und das bezieht sich auf die Entwicklungszeit. Eine Klasse "kennt" eine andere.

Zur Laufzeit ist dann aber eine Instanz des so dargestellten Swolons mit vielen anderen verbunden. Ein Objekt hat Referenzen auf viele andere. Ob die Zahl der referenzierten vorher festgelegt wurde oder nicht, ist erstmal unerheblich.

Deine letzte Frage zu der Basisklasse kann ich leider nicht beantworten. Ich verstehe nicht genau, was du meinst, aber ich zweifle auch, dass sich eine allgemeine Antwort geben lässt.

Dennis hat gesagt…

Ok, dann hab ich es ganz falsch verstanden.