Contract-first Design Beispielcode und Tool-Hinweise zu User Group Vorträgen

Am 20.3. und 22.3. habe ich Vorträge zum Thema Contract-first Design vor den .NET User Groups in Ulm und München (Download des Beispielcodes) gehalten. Insgesamt lauschten knapp 80 Entwickler meinen Vorschlägen, wie Software ganz grundsätzlich mit Komponenten als binären Codebausteinen diesseits von SOA-Services und jenseits von Objekten strukturiert werden sollte.

Mit Komponenten habe ich da natürlich das gemeint, was ich in meiner Serie "Software als System" als hybrides Swolon im Schnittpunkt zwischen logischer und physischer Swolon-Hierarchie bezeichne. Auf den Weg von den Anforderungen zu den Komponenten oder das Big Picture von "Software als System" konnte ich allerdings nicht eingehen. Dafür war die Zeit zu knapp. Schon die theoretische Begründung und praktische Demonstration echter Komponentenorientierung hat ja 2-3 Stunden gebraucht - und alle UG Mitglieder haben tapfer ausgehalten.

Und hinterher gab es auch noch interessierte Diskussionen, auch wenn die Implikationen meiner Vorschläge einige recht still gemacht hatten. Echte Komponentenorientierung bedeutet nicht nur, Klassen mal wieder mit Interfaces zu versehen, sondern funktioniert nur auf der Basis eines veränderten Entwicklungsprozesses und einer klareren Codeorganisation, als in den meisten heutigen Projekten. Ich hoffe aber, ich konnte auch den Nutzen eines Umdenkens in Richtung echter Komponentenorientierung vermitteln. Wer mehr Produktivität, bessere Testbarkeit, mehr nutzbringende Dokumentation oder schlicht mehr Qualität und Seelenfrieden haben möchte... der kommt um einige Kurskorrekturen in der Softwareentwicklung leider nicht herum.

Zum Glück machen ein paar Tools den Einstieg aber leichter. Konsequente Komponententests brauchen zwar vor allem guten Willen, wenn der dann aber da ist, sind sie technisch recht einfach. VSTS enthält z.B. einen Unit Test Framework, der auch mit TFS integriert ist. Wer das Geld für VSTS allerdings nicht hat, muss nicht zurückstehen. NUnit ist die Mutter aller automatischen Tests und kostenlos. Allerdings ist NUnit nicht wirklich gut in VS2005 integriert. Macht aber nichts, denn NUnit-kompatible Werkzeuge wie Testrunner (s. folgende Abbildung) oder TestDriven lösen das Problem fast oder ganz kostenlos.

Klicken für Originalbild

Ich bin mit Testrunner schon länger sehr zufrieden. Der macht Unit Tests während der Entwicklung wirklich schmerzfrei und bietet darüber hinaus auch noch eine Codecoverage-Analyse und Profilinginformationen.

Aber Tests während der Entwicklung sind natürlich nicht alles. Echte Komponentenorientierung zerlegt eine Lösung in viele Assemblies, die in separaten VS2005 Projektmappen entwickelt werden. Die muss man den Überblick behalten und immer wieder integrieren. Ein erster natürlicher Integrationspunkt ist ein zentraler Build-Prozess, der die Komponenten periodisch unabhängig vom einzelnen Entwickler auf einem dedizierten Rechner nochmal übersetzt und testet und erst bei Fehlerfreiheit für andere zur Nutzung freigibt.

Dafür setze ich FinalBuilder ein (s. folgende Abbildung; bezieht sich allerdings nicht auf das Beispiel aus dem UG Vortrag). Ein wirklich cooles Tool, mit dem sich die Übersetzung von VS2005 Solutions, deren Test, das Deployment auf einen FTP-Server, der Umgang mit einer Versionsverwaltung uvm. automatisieren lässt. Seit ich FinalBuilder habe, schreibe ich keine Batch-Dateien mehr.

Klicken für Originalbild

Das Bild zeigt ein komponentenorientiertes Projekt aus einer Artikelserie in der dotnetpro. Rechts ist das Script zu sehen, mit dem ich alle zugehörigen VS2005 Projektmappen übersetze und teste, rechts liegt die lange Liste mit vorgefertigten Aktivitäten, aus denen ich solche Scripte zusammensetzen kann. Da bleibt kaum ein Wunsch unerfüllt. Interaktion mit virtuellen Maschinen, parallele Abarbeitung, Workflow, VSS-, SVN-, CVS-, TFS-Nutzung... alles drin.

Aber nicht nur ein umfassender Build-Prozess muss aufgesetzt werden, wenn echte Komponentenorientierung die beliebte allumfassende VS2005 Projektmappe in viele kleine zerschlägt. Es sind dann auch Integrationstestläufe womöglich außerhalb VS2005 nötig. Und der Debugger ist dann vielleicht auch nicht auf einem Staging-System zur Hand. Wer dann wissen will, was so läuft in seinem Programm, der braucht Einblick. Den kann Instrumentierung bieten (z.B. TraceSource einsetzen oder Performance Counter einrichten oder in ein Windows Log schreiben), aber ich finde es auch sehr nützlich, ohne vorgedachte Instrumentierung den Verlauf einer Software beobachten zu können. Derzeit gefällt mir dafür sehr gut SpeedTrace Pro (s. folgende Abbildung).

Klicken für Originalbild

Damit kann ich mich an ein Programm anhängen und mir den Verlauf der Arbeit protokollieren lassen. Das Ergebnis lässt sich filtern, zum Quellcode in Bezug setzen, ich kann sogar das Tracing erst bei einem bestimmten "Event" (Methodenaufruf) starten lassen.

Zuguterletzt gehört zur echten Komponentenorientierung dann noch ein Service Locator oder Microkernel. Mein eigener kleiner Microkernel steht zur freien Benutzung mit kurzen Erläuterungen online. Alternativen sind z.B. Spring.Net oder Windsor des Castle Projects. Die bieten mehr Leistung - für meinen persönlichen Geschmack allerdings oft zuviel. Ich persönlich kann mich auch nicht so recht mit dem Konzept der Inversion of Control (IoC) anfreunden, wenn es um das "Zusammennähen" von größeren Komponentengeflechten geht. Wenn es um Komponenten geht, die ich verkaufen will, oder die in Zusammenhängen eingesetzt werden sollen, in denen nicht sicher ein Microkernel vorhanden ist, dann ist IoC eine gute Sache, um Entkopplung aufrecht zu erhalten. Aber ansonsten ziehe ich innerhalb geschlossener Projekte einen Microkernel als generische Factory vor.

Ich würde mich freuen, wenn ich mit dem Beispielcode des Vortrags vor der UG München und der kleinen Werkzeugliste hier den Einstieg in die echt komponentenorientierte Softwareentwicklung ein etwas erleichtern könnte. Wer das Szenario der Beispielanwendung noch nicht kennt, der sei hier kurz eingeführt (s. folgende Abbildung):

Zwei kooperierende Komponenten sollen entwickelt werden. Die Calculator-Komponente kann Zahlenreihen zwischen zwei Grenzwerten berechnen und solche Zahlenreihen laden/speichern. Sie ist die zentrale Logik-Komponente des Szenarios und verkörpert nach außen die gesamte Funktionalität. Für die konkrete Speicherung ist dann allerdings die DataAccess-Komponente zuständig.

Beide Komponenten sind durch einen Kontrakt definiert. Die Spezifikation der Calculator-Komponente besteht aus dem Calculator- und dem DataAccess-Kontrakt, ersteren exportiert sie, letzteren importiert sie. Die Spezifikation der DataAccess-Komponente besteht aus dem DataAccess-Kontrakt, den sie exportiert, und der Beschreibung des Persistenzformats.

Klicken für Originalbild

Das ist natürlich ein supersimples Beispielszenario. Aber es ging bei der Demonstration nicht darum, komplizierte Funktionen zu implementieren, sondern den Prozess der Entwicklung echter Komponenten erlebbar zu machen. Theoretische Erklärungen am Flipchart sind eine Sache. Dann aber zu sehen, wie die Theorie in die Praxis umgesetzt wird, den Schritten wirklich zu folgen, das ist noch eine ganz andere Sache - und ein Vortrag das beste Medium, um das zu vermitteln. Ich hoffe, das hat geklappt. Freue mich über Feedback an: info (at) ralfw.de.

Maffay neben Westphal - Kaffeehauskonsultation in Ulm

So kann es kommen: Ahnungslos fahre ich nach Ulm zur Kaffeehauskonsultation - und finde neben mir Peter Maffay. Aber nur in der Zeitung :-) Oder anders: Allerdings in der Zeitung, denn bisher hatte ich nicht geahnt, dass kostenloses .NET Technologiecoaching für die Lokalpresse von Interesse wäre. So stand es jedoch am 20.3. in der Neuulmer Zeitung:

Verständlich wurde diese Nähe zu Peter Maffay dann jedoch, als Thomas Schissler erklärte, er habe anlässlich meines abendlichen Vortrags vor der UG Ulm eine Presseerklärung an die Zeitung geschickt. Und ich dachte schon, die Lokalpresse verfolgt mein Blog... ;-)

Ob der Artikel allerdings viel gebracht hat, weiß ich nicht. Die Kaffeehauskonsultation war auch ohne ihn 2 Wochen vor dem Termin schon "ausverkauft". Von 10h bis 17h gaben sich Entwickler die Klinke in die Hand und ich hatte Mühe, zwischendurch einen Happen zu essen. Aber passt schon. Hat wieder viel Spaß gemacht.

Links Thomas Schissler, rechts Andreas Gümbel, der sich mit mir darüber unterhalten wollte, wie er ein single-sign-on für mehrere Web-Applikation realisieren kann.

Auch der Vortrag am Abend in den Räumen von artiso fand vor einem vollen Haus statt.

Knapp 40 Entwickler waren gekommen, um sich einen Eindruck davon zu verschaffen, wie der Weg zur mehr Produktivität, besserer Testbarkeit, einfacherer Wartbarkeit und größerer Verständlichkeit ihrer Applikationen durch echte Komponentenorientierung aussehen könnte. Nach etwas mehr als 2,5 Stunden wussten sie es dann - hoffentlich :-) Denn solange habe ich doch für meinen Vortrag am Flipchart mit anschließender Demo in VS2005 gebraucht.

Die Kombination Kaffeehauskonsultation + UG-Vortrag - danke an INETA für´s Sponsoring - hat mir gut gefallen. Mache ich gern wieder.

Danke an Thomas Schissler für seine Initiatve! Das ist Nutzung der Angebote von Microsoft at its best.

Vom Guten im Schlechten - TurboDb besser dank "Passionsspiele"

In der dotnetpro 4/07 hatte ich unter dem Titel "Passionsspiele" - passend zum Ostermonat ;-) - von meinem Leidensweg bei der Portierung einer .NET 2.0 Anwendung nach Mono berichtet. dnpMelodie, ein (noch und zugegebenermaßen rudimentärer) Windows Media Player/iTunes Clone, wollte ich mal eben so auf Linux umstellen, weil das aufgrund der komponentenorientierten Architektur einfach schien. Leider ging das aber daneben, weil Mono derzeit noch zu wenig kompatibel zu .NET 2.0 ist und... ja, und auch die Datenbank, von der ich dachte, das sie hüben wie drüben laufen würde, eben das nicht tat.

Ich hatte mich für die Neuentwicklung der Datenzugriffskomponente, die zunächst auf die Jet Engine ausgelegt war, für TurboDb von DataWeb entschieden. TurboDb Managed ist eine rein in Managed Code geschriebene Datenbank und sah für mich daher so aus, als sei sie der ideale Kandidat. Wie sich dann allerdings herausstellte, war TurboDb Managed nicht 100% kompatibel zu Mono. Leider hatte ich das aber erst gemerkt, als ich die Datenzugriffskomponente schon neu entwickelt hatte. War dann schade, aber machte auch nicht soviel. Ich hab es dann mit db4o nochmal probiert und die DB-Engine lief dann auch unter Mono - nur meine Anwendung trotzdem noch nicht.

Aber egal. Denn um die Inkompatibilität von TurboDb mit Mono geht es mir hier nicht. Nerviger waren vorher nämlich einige Stolpersteine während des Umbaus auf TurboDb unter .NET. Da funktionierte die SQL ORDER-BY-Klausel nicht wie mit der Jet Engine und ein Feldname war plötzlich ein reserviertes Wort und die Escape-Zeichen für solche Fällen waren schlecht dokumentiert. Davon habe ich dem Artikel im Sinne eines Entwicklungsprotokolls dann auch berichtet.

Und nun hat mich der Hersteller von TurboDb kontaktiert, nochmal genauer erfragt, was mein Problem war... und hat die Probleme behoben. Hier ein Auszug aus der Email von DataWeb:

Hallo Herr Westphal,

vielen Dank für Ihre Hinweise.

Bei der Sortierung haben Sie einen Bug entdeckt. Er betrifft Strings der Länge 1 in ANSI-String-Feldern (also nicht Unicode) der Länge 256 und darüber. Die Ursache liegt im Kompatibilitätscode zu alten Versionen, wo diese Felder nur bis 255 Zeichen lang sein durften. Der Fehler wird noch diese Woche behoben.

TurboDB Managed unterstützt Bezeichner in doppelten Anführungszeichen, wie es der SQL-Standard vorsieht. Das ist auch dokumentiert (im Kapitel über Spaltennamen) wenn auch zugegebenermaßen etwas unscheinbar. Wir haben aber auf Ihre Bemerkungen hin auch die eckigen Klammern ergänzt, wie sie in der MS-Welt üblich sind. Außerdem gibt es jetzt ein AddWithValue für die Parameterkollektion.

...

Das nenne ich prompte Reaktion! Toll! Danke, Herr Holzinger!

Und was lernen wir daraus? Ein bisschen maulen in der Öffentlichkeit hilft. Die Hauptaufgabe von technischen Artikeln ist natürlich zu zeigen, was geht. Aber wenn etwas nicht geht, sollte das nicht einfach stillschweigend mit einem Workaround verborgen werden, sondern durchaus auch in einem Artikel zu Kenntnis der Leser wie auch des Herstellers gebracht werden. Und Hersteller - insbesondere kleinere wie DataWeb - können Pluspunkte sammeln, wenn sie solche Hinweise ernst nehmen und Reaktion zeigen. Sie können damit einen Vorteil gegenüber den Platzhirschen ausspielen: ihre Agilität. Es heißt ja schon lange nicht mehr "Der Große schlägt den Kleinen", sondern auch "Der Schnelle/Flexible den Langsamen/Starren".

Also: Wer eine embedded Datenbank geschrieben in Managed Code sucht, der sollte einen Blick auf TurboDb Managed werfen. Man ist dort kundenorientiert. Das finde ich geiler als Geiz :-)

Das Intuitive Datenmodell IV - Werte als Schnittpunkte

Das Intuitive Datenmodell (IDM) kennt nur ineinander geschachtelte Werte. Eine Intuitive Datenbank (IDB) ist damit ein großer Raum, in dem solche Werte gespeichert werden. Eine beschränkende Vorstrukturierung in Tabellen und Tabellenzeilen ist ihr fremd. Sie kennt nur ein Konzept: den schachtelbaren Wert.

Die Kommunikation mit einer IDB geschieht jedoch in "Happen", die ich einmal Dokument nenne. Jedes Dokument ist eine Ansammlung von Werten, die allerdings im Speichervorgang in das schon vorhandene Wertegeflecht eingewoben werden. Eine IDB nimmt ein Dokument also nicht wie eine RDB einfach in Form einer Kopie auf! In einer IDB existieren keine Daten mehr in Kopie. Eine IDB enthält Werte der "äußeren Welt" und insofern auch Kopien. Aber jeden Wert aus der äußeren Welt, der in einem oder vielen Dokumenten steckte, die einer IDB "dargeboten" wurden, enthält die IDB nur einmal.

Das Relationale Datenmodell (RDM) kennt natürlich im Grunde auch Datengeflechte. Sie werden durch die Beziehungen zwischen Datensätzen hergestellt. Dennoch hat für mich das Daten- bzw. Wertegeflecht des IDM noch eine andere Qualität. Im IDM können nämlich Daten nicht anders, als sich zu verflechten. Es passiert ganz automatisch. Im RDM müssen Sie das Geflecht sehr bewusst weben, indem Sie Beziehungen über Fremdschlüssel aufbauen. Im IDM hingegen "passieren" Beziehungen ganz von allein immer und notwendig überall dort, wo Dokumente dieselben Werte enthalten.

Da das IDM alle Werte nur einmal enthält - und das auf allen Strukturebenen von Dokumenten -, teilen sich Dokumente gleiche Werte automatisch. Gleiche Werte sind quasi die Schnittpunkte von Dokumenten. Hier zwei Dokumente, in denen derselbe Wert in unterschiedlicher Schachtelungstiefe vorkommt:

Aus Sicht des IDM schneiden sich diese Dokumente in dem Wert, der in beiden vorkommt. Sie überlappen in ihm, er gehört zu beiden Dokumenten gleichzeitig.

Einfacher ist dieses Schneiden von Dokumenten allerdings mit einem Baum darstellbar. Er führt zwar wieder Verbindungen zwischen Werten ein, aber die sollen nur Zugehörigkeit beschreiben. Sie definieren eine Enthalten-Beziehung wie die Zusammenfassung von Werten in den vorstehenden Bildern. Verwechseln Sie sie bitte nicht mit Referenzen im Objektorientierten Datenmodell  (ODM) oder Fremdschlüsseln des RDM.

Dokumente können eine beliebige Anzahl solcher Schnittpunkte haben. Enthält ein Dokument mehrfach denselben Wert, so schneidet es sich sogar mit sich selbst.

Für das Verständnis des IDM ist es zentral, den Effekt dieser Dokumentenschnitte zu verstehen. Sie führen dazu, dass sich in einer IDB nicht einfach eine Anzahl nebeneinanderliegender Dokumente anhäuft, sondern alle Dokumente zusammen ein großes Ganzes ergeben. Alle Dokumente sind miteinander verwoben, ohne dass dafür etwas Spezielles getan werden müsste.

Auch sehr Verschiedenes berührt sich dort, wo es Gleiches enthält. Das ist wie im richtigen Leben: Die vorstehende Grafik enthält einen Baum und lässt damit diesen Text mit einem Wald in Verbindung treten. So unterschiedliche Zusammenhänge wie Software und Natur berühren sich im Begriff Baum. Diese Berührung haben Sie und ich nicht geplant, sie entsteht einfach in Ihrem und meinem Kopf durch Verwendung desselben Begriffs hier wie dort.

Im richtigen Leben begrüßen wir solche spontanen Überschneidungen von ansonsten ganz Verschiedenem. Wir versuchen sogar, sie mit Kreativitätstechniken zu befördern. Wem solche Assoziationen leicht fallen, wird gewöhnlich beneidet. Sie sind ein Merkmal von Intuition, wenn sie denn irgendwann bewusst werden. Wannimmer wir ausrufen, "Ach, das erinnert mich an..." oder "Das ist genauso wie bei...", dann sprechen wir über einen solchen Schnittpunkt von Kontexten. Natürlich kann das umso häufiger passieren, je mehr "Weltwissen" wir haben, je aufmerksamer wir beobachten. Jeder Schnittpunkt ist dann ein Brückschlag und lässt uns etwas Neues erkennen.

Analogien sind in diesem Sinne bewusste Brückenschläge, um Zusammenhänge zwischen ansonsten Unverbundenem herzustellen, um Eigenschaften eines Kontexts mit denen eines anderen in Beziehung zu setzen.

Genauso ist es im IDM: Indem Dokumente sich automatisch in jedem übereinstimmenden Wert schneiden, werden immer wieder Verbindungen zwischen ansonsten Unverbundenem hergestellt. Es können und sollen sich Assoziationen ergeben, die quasi unplanbar sind. Dieser Effekt ist natürlich umso größer, je mehr Dokumente in eine IDB aufgenommen werden und je vielfältiger sie sind.

Anders als beim ODM/RDM ist für die Verbindung der Dokumente jedoch viel weniger Planungsaufwand zu treiben. Niemand muss sich hinsetzen und Verbindungen im Sinne von Container-Referenzen planen. Sie ergeben sich vielmehr einfach so im Verlauf der Aufnahme von immer mehr Dokumenten in einen IDM-Werteraum. (Die Diskussion, wie man die Assoziation von Dokumenten durch etwas Planung befördern kann, möchte ich auf einen zukünftigen Artikel vertagen.)

 
Bild anklicken zur Vergrößerung

Das Endresultat der Aufnahme von immer mehr Dokumenten in eine IDB ist ein großes Dokument, dem man nicht mehr ansehen kann, in welcher Reihenfolge seine Teile hinzugefügt wurden. Auch die ursprüngliche Granularität der darin eingegangenen Dokumente ist nicht mehr erkennbar. Aufgenommene Dokumente verlieren sozusagen ihre Identität. Sie werden einfach Teil eines größeren Ganzen; sie werden assimiliert wie Menschen von den Borg bei Star Trek.

Diese Assimilation ist kommutativ und idempotent:

• Sie kann in beliebiger Reihenfolge stattfinden und führt immer zum selben Ergebnis. Dokument A + Dokument B führt genauso zu "Gesamtdokument" C wie B + A.
• Dasselbe Dokument kann beliebig oft assimiliert werden: A + B = C, aber auch A + B+ B = C oder A + A + B = C.

Software als System X - Von der Struktur zur Kooperation

Die logische und die physische  Swolarchie beschreiben Software noch nicht als System. Sie definieren lediglich die Bestandteile aus zwei unterschiedlichen Blickwinkeln. Sie beschreiben, welche Bestandteile aus welchen anderen bestehen. Durch Aufspannen einer Modulhierarchie können Sie sich schrittweise der Problemlösung nähern. Sie verfeinern sie durch neue Hierarchieebenen, wo sie sie für noch zu kompliziert/undurchsichtig halten. Dabei geht es aber nur um grundsätzliche Verantwortlichkeiten im Sinne der Produktion von Anwendernutzen und noch nicht darum, wie der am Ende konkret entsteht. Für ein gegebenes Modul ist die Leitfrage: "Aus welchen Rollen/Submodulen könnte dieses Modul bestehen, die zusammen seine Leistung erbringen?"

Die Modularisierung einer Software dient nur der Ermittlung derjenigen Rollen, die zur Lösung des Gesamtproblems "irgendwie" nötig sind. Ziel ist eine Menge von Modulen, die als Komponenten implementiert werden können.

 
Click image to enlarge

Am Ende der Modularisierung wissen Sie also, was grundsätzlich zu tun ist. Es ist dann klar, welche Bauteile herzustellen sind, aus denen die Software dann zusammengesetzt werden kann. Wie das dann geschieht, beschreibt die physische Swolarchie. Die Modulhierarchie ist sozusagen der Herstellungsplan, die physische Swolarchie der Bauplan für Software.

Modellierung ist kein Selbstzweck. Sie dient vielmehr der Beantwortung von Fragen:

1. Wer tut am Ende was?
2. Wo tut wer etwas?
3. Wie tut wer etwas?

Warum und Wofür sind der Ausgangspunkt und durch die Anforderungen an die zu entwickelnde Softwarelösung gegeben.

Die Modulhierarchie ist die Antwort auf die erste Frage. Ihr Ergebnis ist eine Liste von Rollen oder Verantwortlichen, den Hybriden, die am Ende die "Fabrik Software" konstituieren. Die Modularisierung ermittelt diese Verantwortlichen aber nur, setzt sie quasi nur ungeordnet in einen Raum. Das kann auf jeder Ebene des Herstellungsplans geschehen (s. die Schnitte im obigen Bild).

Der Bauplan beantwortet die zweite Frage. Er legt fest, wo die Hybriden im späteren Softwaresystem zum Einsatz kommen, zu welchen Superkomponenten oder Prozessen sie zusammengesetzt werden müssen, um ein im Sinne der Anforderungen funktionsfähiges Ganzes zu ergeben.

Und wer beantwortet die dritte Frage? Es ist ein weiterer Plan nötig, der Kooperationsplan. Ein Kooperationplan beschreibt für einen Schnitt durch eine Ebene von logischer oder physischer Swolarchie die Verbindungen zwischen den Swolons. Er definiert, wie die Swolons miteinander kooperieren/kommunizieren, um zusammen Anwendernutzen hertzstellen.

Click image to enlarge

Die Beziehungen zwischen Swolons in einem Schnitt müssen dabei natürlich grundsätzlich denen in anderen entsprechen, die denselben Systemausschnitt beschreiben. Bei den Kooperationsplänen für Schnitt 1 und Schnitt 2 im vorstehenden Bild ist das der Fall. Die gestrichelten Pfeile zeigen das Mapping von logischen Swolons auf physische inkl. ihrer Verbindungen. Die Modellierung muss hier also ein Auge auf die Konsistenz der unterschiedlichen Pläne haben.

In UML werden Kooperationspläne als Kollaborationsdiagramme dargestellt. Ich möchte mich in dieser Serie jedoch nicht zu sehr an UML binden, um den allgemeinen Begriff der Swolons nicht mit Bedeutungen aufzuladen, die ihm angesichts seiner Jugend schaden könnten. UML wurde vor allem aus C++ und Java geboren und hat seine Wurzeln bei allem Willen zur Allgemeingültigkeit also in der Objektorientierung. Mein Ziel ist jedoch, über die Objektorientierung hinaus zu gehen, sozusagen auf sie zu steigen, um auf ein höheres Level bei der Softwareentwicklung zu kommen. Komplexe Software zu beschreiben darf nicht (zu früh) von Konzepten der Objektorientierung behindert werden.

Paket-, Komponenten-, Klassen- und Kollaborationsdiagramme haben alle ihren Wert. Wenn Sie sie zur Darstellungen von Swolarchien benutzen wollen, dann tun Sie das gern. "Software als System" steht dem nicht im Wege. Ob die Diagramme dann allerdings so hübsch aussehen, wie die Grafiken in dieser Postingreihe... das weiß ich nicht ;-)

Software als System IX - Komponenten als Nahtstelle zwischen logischer und physischer Struktur

Bei der Modellierung von Software finde ich es ganz wichtig, immer die Verbindung von Modell zur Realität im Blick zu behalten. Denn dass reine Modelle nach Beginn der Implementierung kaum das Papier wert sind, auf dem sie ausgedruckt worden, ist ja schon lange bekannt.

Wie kann nun aber ohne MDA-"Gedöns" ;-) eine Nähe von Modell zu Code hergestellt und auch erhalten werden? Ich meine, die Voraussetzung dafür ist eine Verzahnung von logischer und physicher Swolarchie. Das geschieht am besten auf der Blattebene der Modulhierarchie. Module, die Blätter sind, sollten einem physischen Swolon gleichgesetzt werden.

Darüber hinaus sollte dieses physische Swolon jedoch relativ stabil sein, so dass Typen eigentlich ausgeschlossen sind. Für mich findet daher der Übergang von logischer zu phyischer Swolarchie auf Komponentenebene statt. Aus welchen Komponenten eine Software besteht, unterliegt viel seltener Änderungen als die Menge ihrer Klassen. Eine logische Planung gerät deshalb weniger schnell aus dem Tritt mit der Coderealität, wenn sie nicht versucht, zu detailliert zu sein.

Das Blatt-Modul der Modulhierarchie ist also hybrid. Es ist sowohl ein Modul wie auch eine Komponente. Unter ihm setzt sich die Hierarchie jedoch nur mit physischen Swolons fort. Über ihm kann die Modulhierarchie beliebig viele Ebenen haben; aber auf der physischen Seite reicht sie natürlich nur bis zum Prozess hoch.

Hybride können selbstverständlich auf der logischen Seite wie jedes andere Modul Teil mehrere Module sein. Und sie können auf der physischen Seite Teil mehrerer Superkomponenten, AppDomains oder Prozesse sein. Die Modellierung mit Swolons unterstützt also den Wiederverwendungsgedanken.

Aus welchen/wievielen Assemblies, Typen und Methoden ein Hybride besteht, ist für die Modellierung transparent. Sie sollte, so meine ich, bei den Hybriden enden. Auch diese Entscheidung ist ein Mittel, um den Trend zur Entfernung von Modell und Coderealität zu unterdrücken. Hybriden sind Black Boxes für die logische Modellierung und auch für die physische Implementierung. Damit sind sie die entscheidenden Swolons, mit denen Wiederverwendung erreicht werden kann.

Die Entscheidung über die Details eines Hybriden, über seine internet physische Struktur, sollte nicht bei der Modellierung liegen, um sich zum einen nicht in Details zu verzetteln, zum anderen aber auch, um Verantwortung und Flexibilität dorthin zu delegieren, wo die Entscheidungen aufgrund des Tagesgeschäfts gemacht werden: zu den Entwicklern. Komponentenentwickler werden so zu autonomen organisatorischen Einheiten aufgewertet. Aufgabe der Modellierung ist es, ihnen einen Rahmen zu stecken, innerhalb dessen sie ziemlich freie Entscheidungen treffen können, ohne Gefahr zu laufen, andere Teile des Systems in Mitleidenschaft zu ziehen.

Software als System verleugnet die Objektorientierung also nicht, sondern verschiebt nur den Fokus auf Komponenten, wenn es um die Planung der Implementierung geht. Objekte/Typen spielen innerhalb von Komponenten weiterhin eine große Rolle. Und der Funktionalität-Daten-Dualismus ist eine zentrale Eigenschaft aller Swolons. Zur Modellierung von Software eignen sich Objekte/Typen jedoch nicht. Sie sind einerseits als physische Swolons zu klein, die Modellierung wäre zu feingranular. Andererseits sind sie auch zu konkret, um nützlich für eine logische Modellierung zu sein, denn Typen lassen sich nicht flexibel genug schachteln.

Sind logisches und physisches Modell nur über Blatt-Module bzw. Komponenten verzahnt? Zunächst einmal ja. Aber es steht natürlich einer Korrespondenz von darüber liegenden Modulen mit physischen Swolons nichts im Wege. Ein Modul einem Prozess entsprechen zu lassen, ist natürlich erlaubt. Als mehr als eine lose Korrespondenz würde ich solch eine Beziehung allerdings nicht bezeichnen. Ein direktes Mapping von logischem auf physisches Swolon sehe ich nur bei Blatt-Modulen auf Komponenten.

Software als System VIII - Physische Strukturierung

Physische Swolons kann man "sehen und anfassen". Es sind die Artefakte, mit denen Sie täglich umgehen: Klassen, Assemblies usw. Physische Swolon sind das Ergebnis der Implementation von logischen Swolons. Im Gegensatz zu den Modulen ist die Hierarchie der physischen Swolons jedoch vorgegeben. Entwicklungs- und Betriebssystemplattform definieren sie:

Die Hierarchie der physischen Swolons ist wie die der Module durch eine Enthalten-Beziehung definiert: physische Swolons auf einer höheren Ebene enthalten ein oder mehrere physische Swolons der nächst niederen Ebene. In einem Prozess existieren eine oder mehrere AppDomains; in eine AppDomain sind eine oder mehrere Komponenten geladen. Eine Komponente besteht aus einer oder mehreren Assemblies. In einer Assembly sind einer oder mehrere Typen definiert. Ein Typ enthält eine oder mehrere Methoden.

Eine Modulhierarchie kann beliebig tief sein. Eine physische Hierarchie muss jedoch eine wirklich kleinste, unteilbare Einheit als Blatt haben. Das sind für mich Methoden. Sie sind die elementaren physischen Swolons. Alles beginnt bei ihnen als ersten Trägern von Funktionalität.

Einzelne Anweisungen sind für mich keine Swolons, weil sie nicht zu Systemen verbunden werden können. Eine Anweisung kann immer nur zwischen zwei anderen stehen. Methoden können jedoch von beliebig vielen anderen genutzt werden. Sie sind echte Einheiten der Wiederbenutzung.

Das größe physische Swolon ist für mich derzeit ein Prozess. Er ist eine auf Betriebssystemebene klar identifizierbare Codeeinheit.

Zwischen Prozess und Methode ist die physische Swolarchie aufgespannt. Jede Ebene sieht dabei jedoch anders aus. Waren Module auf allen Ebenen der logischen Hierarchie grundsätzlich gleich, so sind physische Swolons auf allen Ebenen grundsätzlich unterschiedlich:

Methoden sind zur Laufzeit nach außen hin reine Funktionalitätsträger und enthalten selbst keinen Zustand, der einen Aufruf überdauert. (Von den früheren statischen Variablen in Methoden bei VB sehe ich an dieser Stelle einmal ab. Es gibt sie aus gutem Grund nicht mehr.)

Typen (oder weniger allgemein: Klassen) sind heute die wesentlichen Träger von Funktionalität und Zustand. Ihre Felder enthalten den Zustand, ihre Methoden definieren ihre Funktionalität. Wenn von physischen Swolons die Rede ist, dann allermeistens von ihnen.

Assemblies fassen Typen zu größeren Funktionseinheiten zusammen und sind die erste Ebene, auf physische Swolons als binäre Black Boxes betrachtet werden können. Innerhalb eines Prozesses ist eine Assembly ein Singleton; ihre Typen können jedoch grundsätzlich beliebig oft instanziert werden. Assemblies können - anders als Typen und Methoden - Teil mehrerer übergeordneter physischer Swolons sein.

Komponenten sind für mich die zentralen Bausteine für Software. Sind sind ebenfalls binäre Black Boxes und bestehen aus mindestens einer, gelegentlich aber auch aus mehreren Assemblies. Die Komponenten einer Software zu identifizieren ist für mich erstes Ziel der Modellierung. Zu ihnen wird noch einiges zu sagen sein. Wenn Komponenten aus mehreren Assemblies bestehen sollten, dann plädiere ich für ihre Zusammenfassung zu einer neuen Komponentenassembly.

Falls die Zahl der Komponenten einer Software unhandlich groß ist, können sie zu Superkomponenten zusammengefasst werden. Das sind für mich Vereinigungen von mehreren Komponentenassemblies zu einer wiederum größeren Superkomponenteassembly. Dieselbe Komponente kann in mehreren Superkomponenten vorkommen. Komponenten sind für mich unverzichtbare Bauteile von Software, Superkomponenten jedoch sind eine optionale Ebene in der physischen Swolarchie. Allerdings sind sie die einzigen physischen Swolons, die rekursiv definiert sind: Superkomponenten können nicht nur Komponenten, sondern auch andere Superkomponenten enthalten. (Es ließe sich argumentieren, dass Superkomponenten dann überflüssig sind, weil doch auch Komponenten rekursiv definiert werden könnten. Im Augenblick scheint mir die Trennung von Superkomponente und Komponente jedoch vorteilhaft, weil Komponenten für mich die zentralen physischen Bausteine von Software sind. Diese ihre Funktion würde ich ungern durch Rekursivität verwässern.)

Ob am Ende eine Komponente, zu der mehrere Assemblies gehören, oder eine Superkomponente bestehend aus mehreren Komponenten wirklich durch nur eine Assembly repräsentiert wird oder nicht, ist mir allerdings weniger wichtig als die Identifikation ihrer physischen Funktionseinheiten. Eine (Super)Komponente bestehend aus mehreren Assemblies kann von mir aus auch durch ein Verzeichnis oder eine ZIP-Datei physisch klar erkennbar von anderen separiert sein.

Dass Managed Code immer in einer AppDomain abläuft, ist für ihn meist unwichtig. Es gibt jedoch Fälle, in denen Komponenten bewusst auf mehrere AppDomains verteilt werden (z.B. Hauptprogramm und Plug-Ins). AppDomains sollten daher in der physischen Swolarchie sichtbar sein. Auch wenn ein Prozess nur die default AppDomain enthält, so ist sie es doch, in die die Komponentenassemblies geladen werden. Aber auch im Hinblick auf die Kommunikation auf dieser physischen Swolarchieebene ist eine Unterscheidung von den darunterliegenden Ebenen wichtig. Doch dazu später mehr.

Die oberste Ebene der Swolarchie bildet schließlich der Prozess, in dem eine oder mehrere AppDomains liegen. Er spannt den physikalischen Addressraum auf, die AppDomains teilen ihn in logische Unteradressräume auf, über die die CLR wacht. Ein Prozess wird durch eine ausführbare EXE gestartet, die ich den Host nennen. Ob der Host durch Sie geschrieben wird oder schon existiert, ist unerheblich. Wichtig ist, dass ein Prozess einen Ort definiert, an dem kleinere physische Swolons zusammengeführt und ausgeführt werden.

Prozess und AppDomain sind binäre physische Swolons, die eigentlich erst zur Laufzeit existieren. Dennoch sollten sie geplant werden, d.h. zur Entwicklungszeit modellierbar sein. Superkomponente, Komponente und Assembly sind binäre physische Swolons und für mich die wesentlichen Black-Box-Bausteine für Software. Typen und Methoden sind die White-Box-Bausteine und die, über die am meisten diskutiert wird. So wichtig sie natürlich sind, ich halte die Aufmerksamkeit, die sie während der Modellierung bekommen, für unangemessen groß. Oder umgekehrt: Ich denke, die über ihnen liegenden Ebenen der physischen Swolarchie erhalten bisher zuwenig Aufmerksamkeit. Das möchte ich durch diese Darstellung ändern. Denn zusätzliche Ebenen helfen, besser mit der Komplexität von Software umzugehen und machen es einfacher, die Verbindungen zwischen Swolons zu planen. Außerdem sind die über den Typen liegenden physischen Swolons wichtig für das Deployment und das Laufzeitverhalten einer Software.