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.

Software als System VII - Logische Strukturierung

Swolons mit ihrer Funktionalität und ihren Zuständen lassen sich in zwei Arten einteilen: logische und physische Swolons.

Logische Swolons haben keine bzw. nicht notwendig eine Entsprechung "in der Codewelt". Sie sind lediglich Hilfskonstrukte zur Gliederung einer Software. Ich nenne sie mal Module, weil der Begriff nur relativ wenig besetzt ist. Jede Software kann dann als Hierarchie von Modulen beschrieben werden. Jedes Modul kann aus beliebig vielen Submodulen bestehen. Dasselbe Submodul kann in mehreren Modulen enthalten sein.

Jedes Modul hat eine möglichst klare Aufgabe und entsteht im Prozess einer schrittweisen Dekomposition oder Verfeinerung. Das Wurzelmodul ist die zu entwickelnde Lösung; sie wird in Funktions- oder Verantwortlichkeitsbereiche zerlegt. Diese Module werden dann wiederum in kleinere Funktions- oder Verantwortlichkeitsbereiche zerlegt und so weiter...

Diese Art der Zerlegung eines Systems in immer kleinere Bestandteile ist im Laufe der letzten Jahre leider in Verruf geraten, nicht agil genug zu sein. Dieser grundsätzlichen Kritik kann ich jedoch nicht folgen. Agilität ergibt sich nicht einfach aus dem Verzicht auf eine hierarchische Strukturierung/Planung von Software. Sie ist vielmehr eine Frage des Umgangs mit ihr. Und das ist eine Frage des Entwicklungsprozesses - den ich an dieser Stelle jedoch zunächst ausklammern möchte.

Unabhängig vom Prozess halte ich es für unabdingbar, auch ein Softwaresystem (wie jedes andere komplexe System) sauber in logische Bestandteile zu zerlegen. Die Zerlegungstiefe soll dabei problemangemessen sein. Ziel ist es, schrittweise zu Funktionseinheiten zu kommen, deren Aufgabe klar und überschaubar ist, die einen abschätzbaren Implementationsaufwand haben.

Dabei ist ganz wichtig zu beachten, dass Module eben keine Klassen sind. Module sind logische Swolons, Klassen physische. Die logische Dekomposition findet also losgelöst von einer konkreten Implementierung und Entwicklungsplattform statt. Leitmotiv sollte dabei lediglich sein, Kompliziertes in Einfacheres zu zerlegen. Da Software immer eine Funktion hat, sind Module für mich daher immer zuerst Funktionsträger. Sie stehen für eine möglichst klar umrissene Dienstleistung. Sie sind verantwortlich für ihre Erbringung. Diese Dienstleistung kann natürlich mal mehr funktionsorientiert und mal mehr zustandsorientiert sein.

Jede Ebene im Modulbaum kann auch als Abstraktionsebene angesehen werden. Die Dienstleistung der Module in einer Ebene sollten dann in Bezug auf diese Ebene möglichst klar umrissen sein. Konjunktionen wie "und" und "oder" sollten in Funktionsbeschreibungen nicht vorkommen. Die Summe der Funktionen aller Submodule entspricht dann wieder der Gesamtfunktionalität ihres Moduls.

In Bezug auf seine Submodule ist die Dienstleistung eines Moduls jedoch eher grob und unscharf. Die Submodule präzisieren sie. Ein Beispiel:

Auf der obersten Abstraktionsebene geht es nur um einen online Shop. Die Ebene darunter präzisiert: zu einem online Shop gehören Produkte, Bestellungen dieser Produkte und die Wahrung der Sicherheit des Bestellvorgangs. Und was genau bedeutet "Wahrung der Sicherheit"? Das präzisiert die darunterliegende Abstraktionsebene. Laut ihr gehören eine Benutzerverwaltung und die Authentifizierung bzw. Autorisierung von Benutzern dazu.

Die Modularisierung einer Software ist sozusagen eine sich schrittweise in das Problem hineingrabende Bestandsaufnahme der Verantwortungsbereiche oder "Abteilungen", die nötig sind, um am Ende einen Nutzen für den Anwender herzustellen. Software kann in diesem Sinn auch als Unternehmen oder Fabrik - software as a factory - angesehen werden: Ihre Produkte sind Dienstleistungen für den Anwender. Der wünscht sich z.B. die Aufnahme eines Artikels in den Warenkorb und die Software erfüllt ihm diesen Wunsch. Oder der Anwender "bestellt" die Umsetzung einer Verkaufszahlenliste in eine Grafik und die Software produziert diese Grafik.

Geleistet werden solches Services von, hergestellt werden solche Produkte durch das Zusammenspiel vieler Swolons mit sehr unterschiedlichen Verantwortlichkeiten und auf unterschiedlichen Abstraktionsebenen. Blätter des vorstehenden Modulbaumes können daher auch als Aufgabenbereiche zu einem "Unternehmen" zusammengesetzt werden:

Eine Modulhierarchie kann insofern auch als Orga-Diagramm angesehen werden. Und die Knoten darin sind Rollen. Damit bewegt sich die logische Strukturierung in der Nähe von OORAM - Object Oriented Role Analysis Method -, verzichtet aber auf die Bindung an ein Implementationsdetail wie Objekte. Während Modularisierung geht also eher und allgemeiner um eine Swolon Rollenanalyse.

Module sind auf allen Ebenen der Modulhierarchie gleich. Es sind Swolons mit den grundsätzlich gleichen allgemeinen Eigenschaften. Auf höheren Ebene sind die Module nur sozusagen größer, weil sie noch Submodule enthalten.

Wann sollten Sie mit der logischen Dekomposition aufhören? Wenn es Ihnen in den Fingern kribbelt und Sie mit der Implementation eines Moduls beginnen wollen. D.h. wenn Sie meinen, Sie würden die Dienstleistung eines Moduls hinlänglich gut überblicken und keine weitere Zerlegung in Submodule benötigen. Implementiert, d.h. in Code gegossen, werden also die Blätter des Modulbaumes. Die Tiefe, in der diese Blätter unter der Wurzel hängen, kann von Ast zu Ast natürlich verschieden sein.

My Blogs

Ich glaube, ein Überblick über meine Blogs ist inzwischen mal angezeigt ;-) Sie sollen sich ja darin zurecht finden. Also...

 

One Man Think Tank Gedanken <- Sie sind hier

Dies ist mein "professionelles" Blog. Hier berichte ich über meine Arbeit als Softwarearchitekt/-entwickler in der .NET-Welt. Es ist sozusagen der dynamische Teil meiner Homepage www.ralfw.de, deren eigene dynamische Inhalte wie die Seite mit meinen Publikationen leider, leider nur eigentlich, aber nicht wirklich dynamisch sind.

In meinem "Hauptblog" finden Sie daher alle meinen Gedanken zu Aktuellem und Zukünftigem, zu Realem und Visioniertem. Es ist mein öffentliches Tagebuch meiner Gedanken zur Softwareentwicklung und gleichzeitig auch Eventkalender. Ein Abo lohnt sich :-) Sie bleiben dann auf dem neuesten Stand, was mein Leben und Weben im Denktank angeht.

Ralf´s Sudelbücher

Die Sudelbücher waren mein erstes Blog vor Jahren. Da habe ich mich der internationalen Entwicklergemeinde mit andienen wollen und schreibe auf Englisch. Ab und an lasse ich dort auch nochmal einen Gedankensplitter einschlagen, aber letztlich ist der internationale Markt nicht wirklich mein Zielgebiet. Deshalb auch meine deutschen Blogs. Aber immerhin: mehrere Tausend Entwickler weltweit lesen die Einträge in den Sudelbüchern. Das ist schon cool :-)

Sie sind allerdings der Ort, an dem ich das Softwareuniversum bzw. die Softwarezellen erstmals öffentlich beschrieben habe. Oder den relationistischen Ansatz zum Umgang mit Daten, genannt Pile. Da ist also einiges Originalmaterial zu lesen. Inzwischen habe ich die Themen aber in mein Hauptblog unter den Rubriken "Software als System" und "Intuitives Datenmodell" überführt und stelle sie dort aktualisiert nochmal ganz neu dar. Das ist für mich sowas wie ein Gedanken-Refactoring.

O/R Mapping Adventures

Auch wenn ich lieber auf Deutsch blogge, weil ich mich da noch freier im Umgang mit der Sprache fühle, so verdient es manches Thema, doch auf Englisch angegangen zu werden. O/R Mapping ist für mich so ein Thema. Zunächst wollte ich ein Buch darüber schreiben, doch dann habe ich gemerkt, dass mir noch entscheidende Bausteine zum Gesamtbild von O/R Mapping fehlen. Das Einfache ist einfach - aber das Fortgeschrittene braucht noch etwas mehr "Inkubationszeit". Also habe ich das Buch erstmal auf Eis gelegt. Stattdessen mache ich meine Stoffsammlung nun öffentlich. Ein spezielles Blog schien mir dafür angebracht, um für jeden Interessierten den Zugang möglichst einfach zu machen. Statt die Beiträge in meinen Sudelbüchern zu verteilen, sind sie nun alle unter einem Dach zu finden. Sozusagen Komponentenorientierung für Themen :-) Hohe Kohäsion der Beiträge in dem Blog, lose Kopplung mit anderen Blogs. Englisch ist die Sprache der Wahl, weil ich möglichst viel Feedback bekommen möchte - oder umgekehrt: Ich möchte für meine Gedanken eine möglichst große Reichweite. Bei O/R Mapping ist das lohnend.

Vom Harten und vom Weichen der .NET Softwareentwicklung

Im Jahr 2006 habe ich mit zwei Partnern das Professional Developer College als Trainingsunternehmen gegründet. Wir bieten, hm, außergewöhnliche Trainings für den .NET Markt an. Sie sollen Theorie und Technologien besser integrieren als "die üblichen Trainings", sie sollen ganzheitlich Fach- und Prozesskompetenzen vermitteln und sie sollen das Gelernte sehr praxisnah vermitteln. Darüber hinaus sind helfen wir auch bei der Personalauswahl mit einem Assessment Center und Unterstützung im Stellenausschreibungsprozess. Und selbstverständlich muss auch das College als modernes Unternehmen ein Blog haben :-)

PQ - Gedanken zu einer Philosophischen Haltung

Das PQ-Blog ist mein "Spaß-Blog". Zu meinen Hobbies gehört die Beschäftigung mit Philosophie und da fallen mir eben auch immer wieder Sachen ein, die ich einfach mal aufschreiben muss. In das PQ-Blog gehen allerdings nur Gedanken zu einer Idee ein, die ich zusammen mit einer befreundeten Philosophin entwickelt habe, eben PQ für "Philosophischer Intelligenzquotient". In dem Blog sammeln wir jetzt Material, das vielleicht irgendwann mal zu einem Buch oder etwas anderem verarbeitet wird. Mal schauen... In jedem Fall ist es spannend, mal nicht über Software nachzudenken :-)

 

Zunächst einmal sind all diese Blogs nur öffentliche Tagebücher. Sie dienen als Sammelstellen für Ideen/Gedanken, die ich auch in eine Papierkladde schreiben könnte. So eine Klasse habe ich auch immer bei mir, aber ein Blog addiert zu ihr noch etwas hinzu: die Chance auf Feedback, auf ein Gespräch. Mit einem Blog schließe ich meine Gedanken nicht weg, bis ich sie vielleicht irgendwann einmal in einem Artikel/Buch verarbeite, sondern biete sie jedem Interessierten als Ausgangspunkt für weitere Gedanken an. Ob ich davon höre oder nicht... das ist unterschiedlich. Je mehr Feedback ich allerdings bekomme, desto besser. Denn dann können sich diese Gedanken schneller weiterentwickeln. In diesem Sinne: Hinterlassen Sie gern Ihre Meinung als Kommentar!

Neue Sprecher bekommt das Land - Öffentliche Abschlussvorträge des Rhetoriktrainings

Mit dem Professional Developer College veranstalte ich am 2./3. April ein öffentliches Rhetoriktraining für Softwareprofis. Angesichts einer steigenden Themenvielfalt meinen wir, dass auch mehr Entwickler nötig sind, die diese Themen auf den Bühnen der Community - sei es auf großen Entwicklerevents oder kleinen User Group Meetings - auch ansprechend und verständlich vermitteln. Neues Sprecher, neue Referenten braucht das Land, damit nicht immer dieselben "üblichen Verdächtigen" - mich eingeschlossen ;-) - vorne stehen müssen. Denn die können schon lange nicht mehr die ganze Palette der spannenden Themen abdecken.

Das Besondere an unserem Rhetoriktraining neben dem Fokus auf Softwareprofis ist nun, dass die Teilnehmer nicht nur während der zwei Tage unter sich viele Übungen durchführen, sondern... dass sie am Ende ihren Abschlussvortrag öffentlich halten. Ihr "Meisterstück" sollen sie vor einem richtigen, großen, unbarmherzigen, nein, wohlwollenden, aber kritischen Publikum abliefern. Denn auch wenn wir ihnen eine ganze Reihe von Tipps und Werkzeugen und Best Practices mit auf den Weg geben können - am Ende ist deren Anwendung in einem echten Vortrag immer noch etwas anderes. Damit aber auch das unter "kontrollierten Bedingungen" passiert, bieten wir den Teilnehmern für ihre Abschlussvorträge ein großen Forum, zu dem auch Sie herzlich eingeladen sind.

Wir würden uns freuen, wenn Sie am 3. April um 18h den Weg zu uns in den Technologiepark Karlsruhe finden würden. Zusammen mit unserem lokalen Kooperationspartner andrena objects bieten wir Ihnen einen thematisch vielfältigen Abend mit 7 technischen Vorträgen rund um die Softwareentwicklung. Von Multithreading über Eclipse bis zu SOA ist alles dabei.

Wir würden uns freuen, wenn Sie dabei wären, um die Teilnehmer des Rhetoriktrainings anzufeuern und sich von ihren frisch entwickelten Sprecherkompetenzen beeindrucken zu lassen.

Melden Sie sich am besten direkt auf der Seite des ObjektForums von andrena objects an:

http://www.andrena.de/ObjektForum/Veranstaltungen/72.html

Dort finden Sie auch die Vortragsthemen und eine Wegbeschreibung. Die Veranstaltung ist kostenlos - aber bringt den Absolventen des Rhetoriktrainings und ihnen hoffentlich gleichermaßen viel.

Renate Klein, meine Ko-Trainerin, und ich freuen uns auf Sie!

Vorträge auf User Group Meetings

Nun ist es mal wieder soweit: Ich spreche in der nächsten Zeit auf zwei .NET User Group Meetings. Darauf freue ich mich sehr, denn das ist nochmal eine ganz andere, persönlichere Art des Kontakts mit der Community als auf Entwicklerkonferenzen. Das Thema in beiden Fällen:

Echte Komponentenorientierung als Grundlage für bessere Testbarkeit

• Der erste Termin ist am Dienstag 20.3. um 18h in Ulm, http://www.dotnet-ulm.de/Treffen.aspx.
• Der zweite Termin ist am Donnerstag 22.3. um 18h in München, http://www.munichdot.net/Events/464.aspx

Ich denke, auch (noch) nicht Mitglieder der UGs dürfen vorbeikommen. Anmeldung am besten über die jeweiligen UG Leads.

Es wäre schön, wenn wir uns dort alle zahlreich (wieder)sehen würden :-)

Software als System VI - Komplexität revisited

In meinem letzten Posting habe ich das Thema Komplexität nochmal aufgegriffen. Sie ergibt sich aus der Anzahl der Verbindungen in einem System, der Anzahl der verbundenen Strukturbestandteile - hier: Swolons - und der Stärke der Kopplung entlang der Verbindungen.

Ein Softwaresystem mit vielen Swolons, die nur wenig verbunden sind (z.B. in Form einer Kette) und deren Kopplung gering ist, ist nicht komplex. Ein Softwaresystem, mit weniger Swolons, die aber eng vernetzt sind und deren Kopplung hoch ist, ist viel komplexer.

Komplexität ist insofern ein anderes Wort für Vorhersehbarkeit. Es geht um die Vorhersehbarkeit der Veränderung des Gesamtzustands eines Systems, der sich zunächst aus der Summe der Einzelzustände der Systembestandteile ergibt. (Ob ein System mehr als die Summe seiner Teile ist, d.h. neue Qualitäten entwickelt, die sich nicht direkt aus den Teilen ableiten lassen, soll an dieser Stelle außer acht gelassen werden.)

Ein Softwaresystem, dessen Zustand sich in recht einfach zu verfolgender Weise verändert, wenn man an seiner Oberfläche eine Operation anstößt, ist also nicht komplex - kann aber sehr kompliziert sein. (Wo Kompliziertheit in Komplexität umschlägt, ist sicherlich auch eine Diskussion wert, soll an dieser Stelle jedoch auch außer acht gelassen werden.)

Nachdem ich über Zustände und Kopplung und Komplexität geschrieben hatte, ist mir allerdings erst später aufgefallen, dass zwei Zeitpunkte zu unterscheiden sind. Der sofort naheliegende Zeitpunkt ist die Laufzeit einer Software. Wenn ich Zustand schreibe, dann meine ich doch eigentlich den Zustand eines Objektes oder anderen Laufzeitartefaktes, oder? In dem Zusammenhang ist Zustand einfach zu verstehen.

Vor der Laufzeit liegt allerdings die Entwicklungszeit. Wenn man im Allgemeinen von Komplexität spricht, meint man gewöhnlich sie, würde ich sagen. Worauf bezieht sich in der Entwicklungszeit dann aber der Begriff Zustand? Dann existieren ja noch keine Objekte, sondern nur ihre Klassen.

Komplexität und Zustand gehören aber sowohl zur Entwicklungs- wie zur Laufzeit zusammen. Meine bisherige Erklärung war nicht falsch, sondern nur missverständlich, weil sie beides nicht explizit getrennt hat.

Der Zustand der Entwicklungszeit-Swolons - welche das auch sein mögen; darüber muss ich noch schreiben; Klassen gehören aber sicherlich dazu - bezieht sich auf ihren Code. Daten bilden den Laufzeitzustand, Code den Entwicklungszeitzustand. Verbindungen zwischen Entwicklungszeit-Swolons bestehen immer da, wo sie voneinander abhängig sind. Meist sind das auch die späteren Pfade, entlang derer Operationen laufen, z.B. Klasse A ist von Klasse B zur Entwicklungszeit abhängig, weil zur Laufzeit Objekte von A Operationen auf Objekten von B aufrufen.

Die Operationen entlang der Verbindungen eines Softwaresystems zur Entwicklungszeit sind dann nicht Datenzustandsänderungen, d.h. Methodenaufrufe. Zur Entwicklungszeit sind die Operationen Codeänderungen. Die Komplexität ist zur Entwicklungszeit davon abhängig, ob Codeänderungen auf einem Swolon Auswirkungen auf den Code in anderen haben.

Komplexität zur Entwicklungszeit beherrschen heißt also, den Effekt von Änderungen an Code in einem Teil der Swolarchie möglichst lokal zu halten. Contract-first Design (CFD) ist dafür ein Mittel: Mit CFD werden während der Entwicklungszeit "Mauern" um Codebereiche gezogen, so dass sich Änderungen am Code innerhalb der "Mauern" möglichst nicht über sie hinaus auswirken.

Ein sicheres Zeichen für (zu) hohe Komplexität in Ihren Softwaresystemen ist die Frage "Wenn ich hier etwas ändere, was hat das für Auswirkungen auf andere Teile des Programms? Kann ich sicher sein, den Gesamteffekt zu überblicken?"

Also: Ich bleibe bei meiner Definition von Komplexität, die sie in Korrelation zu Verbindungszahl, Swolonzahl und Kopplungsstärke setzt. Und ich differenziere: Zur Entwicklungszeit bestehen die verbundenen Zustände der Swolons aus ihrem Code, zur Laufzeit bestehen sie aus den in ihren Instanzen gehaltenen Daten.

Daraus ergibt sich übrigens, dass die Laufzeitkomplexität nicht der Entwicklungszeitkomplexität entsprechen muss. Oder? Hm... Ich glaube, ich kann mir zumindest ein zur Entwicklungszeit sehr komplexes Softwaresystem vorstellen - d.h. Codeänderungen haben schwer fassbare Auswirkungen -, das zur Laufzeit eine sehr geringe Komplexität hat. Mir schweben da alte sehr objektorientierte Stammdatenverwaltungsprogramme vor. Was sie tun, ist im grunde total simpel - aber der Code ist so verquarzt, ist so ein Spaghettihaufen, dass er sehr schwer wartbar ist. Der Code ist also (unnötig) komplex im Vergleich zu dem, was zur Laufzeit passiert.

Und umgekehrt ist es wohl auch möglich, würde ich sagen. Ich kann mir eine wenig komplexe Codebasis vorstellen (Entwicklungszeit), die aber zu einer hohen Laufzeitkomplexität führt. Simulationsszenarien gehören in diesen Bereich.

Strukturkomplexität und Verhaltenskomplexität sind also zu unterscheiden und können auch für ein Softwaresystem verschieden sein.

Von statischer und dynamischer Komplexität würde ich übrigens nicht reden. Systeme sind von Natur aus immer dynamisch, denn sie existieren ja nur durch Operationen. Alles andere ist nur ein "Haufen Zeugs" ;-)

Interessanterweise verläuft die Kopplung im System zur Entwicklungszeit im Vergleich zur Laufzeit wohl in umgekehrter Richtung: Wenn Swolon A von Swolon B abhängig ist - das betrifft die Entwicklungszeit -, es gilt also "A braucht B", dann haben Änderungen am Code von B eher Auswirkungen auf den Code von A. Der Code von A richtet sich als "Kunde" von B eben eher nach dem, wie B sich nach außen präsentiert. Grundsätzlich sind Verbindungen zwischen Swolons zur Entwicklungszeit zwar bidirektional, aber tendenziell würde ich sagen, es "operieren" eher unabhängige Swolons (B) durch Codeänderungen auf abhängigen (A).

Zur Laufzeit ist es dann eher umgekehrt und klarer. Verbindungen zur Laufzeit sind durch den Code klar in ihrer Richtung definiert. Wenn A von B abhängt, dann laufen die Operationen gewöhnlich von A zu B, d.h. A verändert den Zustand von B. Zur Laufzeit sind die Zustände von B-Instanzen also zunächst abhängig von Zuständen von A. Aufgeweicht wird diese Umkehrung allerdings, wenn wir Rückgabewerte von Operationen einbeziehen. Hm...

Naja, auf jeden Fall fühle ich mich wohler, da ich das mit den "Zustandszeitpunkten" nun (zumindest für mich) klar bekommen habe.

PS: Haben Sie übrigens bemerkt, wie einfach das Nachdenken über Software durch den Begriff Swolon wird? Ich kann über Verbindungen, Zustandsänderungen usw. Aussagen machen, ohne immer gleich konkret werden zu müssen. Ich muss mich nicht (so schnell) für Klasse oder Komponente oder Prozess oder sonsteine Artefaktart entscheiden. Ich kann einfach über Einheiten von Funktionalität und Zuständen, den Swolons, reden. Und am Ende solcher Überlegungen kann ich dann schauen, was sich auf konkrete Artefaktarten übertragen lässt oder was zwischen ihnen eben unterschiedlich ist.

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...

Neues Blog zum Thema O/R Mapping

Das Thema O/R Mapping bewegt mich ja schon länger. Ich bin überzeugt von dem Konzept. Aber ich habe es bisher noch nicht tief genug selbst genutzt. Deshalb mache ich mich jetzt auf zu einer Expedition in das Land des O/R Mappings und berichte darüber in einem eigenen Blog.

Mit den O/R Mapping Adventures will ich meine Fortschritte beim Eindringen in das Thema protokollieren. Mich interessieren besonders die Aspekte von O/R Mapping, die Relevanz für die Softwarearchitektur haben. Wie sieht eine Datenzugriffsschicht mit O/R Mapping aus? Taugt O/R Mapping für den Einsatz in verteilten Applikationen? Wie ist der Umgang mit O/R Mapping in ASP.NET-Anwendungen? Das sind Fragen, die mich bewegen.

Um sie zu beantworten, muss ich aber natürlich am Anfang starten. Ich beginne also mit einfachen Beispielen und drehe mich dann tiefer ins Thema. Ein Blog scheint mir angesichts meiner eigenen Unsicherheit bei einigen Aspekten das geeignete Medium, um darüber zu schreiben. Nicht gesetztes Wissen, sondern lebendige Erfahrung möchte ich mitteilen. Und ich möchte zur Diskussion ermuntern. Denn alles, was ich tue, tue ich mit beschränktem Blick. Wer es also besser weiß, soll mir gern einen Tipp geben. Der kommt über das Blog dann ja auch gleich allen anderen Lesern zugute.

Aus rein praktischen Gründen musste ich mich allerdings auf einen O/R Mapper in der Betrachtung beschränken. Ich habe Vanatec OpenAccess (VOA) gewählt, weil ich mit dem Tool einfach schon länger zu tun hatte. Ich empfinde VOA als recht weit entwickelt und hoffe, es lässt mich auf meiner Expedition nicht so schnell im Stich.

Trotz eines konkreten Werkzeugs glaube ich jedoch, dass meine Expeditionsergebnisse auch allgemeineren Wert haben. Ich denke, einiges lässt sich auch auf andere O/R Mapper übertragen, von denen es ja inzwischen eine große Zahl gibt. Insofern ist meine Wahl keine ausdrückliche Produktempfehlung. Wer über o/R Mapping nachdenkt, sollte ohnehin min. 2-3 Produkte nach seinen Kriterien evaluieren. Ich kann und will mit dem Blog höchstens Fingerzeige geben, worauf man dabei achten sollte.

So, jetzt muss ich los. Der Expeditionsjeep - oder fährt man da heute auch schon einen Hummer? - wartet...

Wi(e)der ein dickes Fachbuch - Gedanken zu "Programmieren mit dem .NET CF"

Torsten Weber, der sich für .NET in und um Leipzig und darüber hinaus engagiert und den ich schon länger kenne und für seinen Enthusiasmus schätze, hatte mich anlässlich meines kritischen Postings über dicke Fachbücher gefragt, ob ich mir denn mal sein dickes Fachbuch zum Thema .NET CF anschauen und rezensieren könne. Das waren seine Worte:

"Nur um eines würde ich dich bitten: Sei ehrlich. Zerreiß es ruhig, wenn es nichts ist, in der Luft. Das ist mir für ein nächstes Buch zu wichtig, als „Honig ums Maul geschmiert zu bekommen“. Außerdem wäre eine positive / negative Rezension je nachdem eine Bestätigung deiner Vermutung über die Seitenanzahl oder das Zeugnis, dass einfach ein neuer Schreibstil her muss."

Solch Wunsch nach unverbrämtem Urteil hat mich dann doch motiviert, selbst ein dickes Fachbuch auch ohne Not und eigenes Sachinteresse mal näher anzuschauen. So habe ich mich denn rituell gereinigt, die Behaarung am ganzen Körper entfernt, mich mit feinsten Ölen eingerieben, in weiße Linnen gehüllt, Räucherstäbchen angezündet und drei Tage unter Absingen heiliger Journalistenlieder gefastet, um mich in den für Rezensenten angemessenen selbstlosen Zustand zu versetzen, der Voraussetzung für die vorurteilsfreie Betrachtung eines Buches ist. Kein Zorn, kein Eifer soll mich leiten, sondern nur der Wunsch, Torstens Titel gerecht zu werden. Ergebnisoffen möchte ich prüfen, ob er die Ausnahme zu meiner "Regel" ist, dass dicke Fachbücher inzwischen unzeitgemäß und kontraproduktiv seien.

So nehme ich denn die Betrachtung seines Buches auf...

Zur Form

Äußerlich kommt es (ge)wichtig daher mit 678 Seiten - die sich allerdings durch einen vergleichsweise kleinen Preis andienen. Für 39,90 EUR verspricht "Programmieren mit dem .NET Compact Framework - Anwendungsentwicklung für mobile Geräte" von Ruprecht Dröge, Peter Nowak und Torsten Weber "umfassendes Wissen zur Entwicklung von mobilen Anwendungen" und "viele[] praxisnahe[] Beispiele[]". Es zeigt "die nötigen Grundlagen, Techniken und besten Vorgehensweisen" für alle, die "mobile Anwendungen auf Basis der .NET-Plattform entwickeln möchten". Obendrein ist es auch noch empfohlen von mit einem Grußwort versehen von der OpenNETCF Consulting - werimmer das sein mag.

Das Buch verspricht also viel: Viel Wissen auf vielen Seiten, deren Gliederung allein 9 Seiten Inhaltsverzeichnis ausmachen. 10 Seiten Index sind dann schon nicht mehr so üppig, wenn man mal Arno Schmidts Forderung von 1 Seite Index pro 20 Seiten in Anschlag bringt, aber ich weiß selbst, wie nervig die Indizierung eines Buches ist. Wenn man alles endlich fertig geschrieben hat, dann fällt es schwer, nochmal alles ganz genau zu lesen und die wirklich wichtigen Worte herauszuziehen - allemal, da die Indizierung im Grunde nicht werkzeuggestützt ist. Alles mühselige Handarbeit. Allerdings: Bei .NET kompakt 3.0 sind Christian Weyer und ich immerhin auf 6 Seiten Index für knapp 200 Seiten gekommen. Aber ich schweife ab... Meine innere Reinigung war vielleicht doch nicht so synapsentief, wie angestrebt?

Äußerlich ist am Buch also erstmal nichts auszusetzen. Solide Buchdruckerkunst. Am Ende stellen sich die Autoren kurz vor und es wird doch auch angezeigt, wer welchen Teil des Buches zu verantworten hat. Diese Information hatte ich nämlich beim Blick auf die Kapitel vermisst. Ich finde eine klare Zurechenbarkeit zum Autor sehr wichtig.

15 Seiten Anhang geben dann noch über den Inhalt der CD-ROM Auskunft, 4 Seiten über sonstige nützliche Ressourcen. Die sind wie auch andere Hinweise mit einem ominösen LINKnnnn-Kürzel versehen, über dessen Funktion ich dann doch einen Moment rätseln muss. Ist LINK2202 nur als Platzhalter im Text gedacht, eben als Referenz in diesen Anhang? Nein, denn im Anhang stehen die Ressourcen nicht sortiert nach diesen Platzhaltern. Auch finden sich nicht alle Platzhalter im Anhang, wie z.B. LINK0002, der auf Seite 20 mit einer Aufforderung zu einer Rezension bei Amazon erwähnt ist. Erst auf Seite 35 und nach vielen solchen Platzhaltern wird die Auflösung verraten: Sie sollen als Label an die Domain www.nahtlos-mobil.de gehängt werden, z.B. www.nahtlos-mobil.de/gehezu/?link0002. Achso. Das ist natürlich eine nette Idee - aber warum kann man die nicht auf der ersten Seite vor Erwähnung des ersten LINKs erklären oder zumindest dort, wo im Anhang ein ganzer Haufen solcher Verweise gelistet ist?

Und überhaupt: Wenn denn das Internet so mit in das Buch eingewoben ist - worauf mich Torsten schon vorbereitet hatte und was ich eigentlich sehr löblich finde -, warum ist dann noch eine Buch-CD nötig? Warum sind dann seitenlange Listen mit Referenzen nach irgendwohin im Buch? Immerhin knapp 20 Seiten oder 3% des Buches werden damit gefüllt, ohne rechten Nutzen zu bringen. Heute noch eine CD mit auszuliefern, ist anachronistisch. Ihr Inhalt veraltet quasi sofort nach der Pressung. Genauso die Liste der Ressourcen in Anhang B. Eine Bibliographie, die viele Verweise auf ohnehin nur offline verfügbare Texte enthält und genaue Quellenangaben an einem Ort im Buch bündelt, die sonst als Fußnoten darin verstreut wären, ja, so eine Bibliographie ist auch heute noch sinnvoll. Aber elektronische Ressourcen sind viel aktueller und leichter über ein ebensolches elektronisches Verzeichnis im Internet zu finden und zu nutzen. Insbesondere wenn Thorsten mir erklärt, dass das Buch sozusagen "work in progress" sei und Ressourcen ständig verändert/ergänzt würden... was soll dann eine Buch-CD und diese Platzverschwendung im Buch?

Es gibt eigentlich nur eine Antwort: Man hat einfach nach alter Väter Sitte gehandelt. ´s war schon immer so, dass man eine schöne Buch-CD beilegt. Wertet das Buch doch auf, oder? Das erwarten die Leser! Nun, ich zumindest erwarte keine CD. Eine CD veraltet unmittelbar, macht das Buch teurer, Bücher mit Softcover kann man dann nicht mehr bequem knicken und Einlegen macht mehr Umstände als eben mal zu einer URL surfen.

Aber genug davon. Ich glaub, ansonsten hab ich an den Äußerlichkeiten des Buches nichts auszusetzen. Ist halt ein solider MSPress Titel. Manche Abbildungen sehen zwar unnötig vergrößert aus, als ob die Seite sonst nicht voll geworden wäre, und andere vermitteln den Eindruck von etwas Bequemlichkeit, weil sie wie 1:1 von Microsoft übernommene Powerpoint-Folien aussehen, die im s/w-Druck aber ihren Charme verloren haben... doch sei´s drum. Das ist ok für ein Buch zu dem Preis.

Zum Inhalt

Jetzt endlich zum Inhalt. Meine Erwartungen sind hoch, denn die Ankündigung auf dem Einband verspricht viel und das Inhaltsverzeichnis scheint ihm Recht zu geben. Es scheint, als wäre zu jedem Stichwort, das mir im Zusammenhang mit .NET oder Mobile Computing einfallen könnte, auch etwas im Buch gesagt: Garbage Collection, Thread-Synchronisation, Unit Tests, Lokalisierung, ActiveSync, Business Intelligence, ImageList... you name it. Wow!

Aber was soll dieses Grußwort? Von einem Chris Tacke geschrieben, der dick bei OpenNETCF mit drin sitzt. Er kann sicherlich kein Deutsch und hat sicherlich das Manuskript des Buches nicht gelesen und nimmt darauf auch gar keinen Bezug. Er wünscht nicht mal viel Spaß beim Lesen. Was soll das also?

Dann nochmal 4 Seiten Vorwort der Autoren, Danksagung und Vorstellung der Autoren, die ich ja schon vom Ende des Buches kenne. Warum das? Wann geht es endlich los?

Es folgen 4 Seiten, die sich damit beschäftigen, was ich auf den folgenden noch knapp 650 lesen könnte, wenn ich alles lesen wollte. Warum das? Wann geht es endlich los?

Solche Art Meta-Aussagen finde ich schlicht überflüssig. Sie kommen dann auch noch am Anfang jedes Kapitels unter der Überschrift "Was sie in diesem Kapitel erfahren" vor. Das ist gut gemeint, langweilt den Leser aber. Irgendwann hat irgendwer mal (bei Microsoft?) die Idee gehabt, Vorträge und Bücher müssten mit solcherlei Vorspann ausgestattet sein. Das sei gut, um die Erwartungen der Zuhörer/Leser "einzuschwingen". Das halte ich jedoch für eine didaktisch/methodische Verirrung aus einem paternalistischen Geist heraus. Motto: "Jungchen, ich will dich mal nicht gleich unter dem Gewicht meines Wissens begraben, sondern führe dich ganz langsam ran. Erstmal ein Überblick, damit du dich nicht verschluckst. Ich weiß ja, du verträgst nicht soviel Neues. Die Dusche wäre zu kalt, wenn ich gleich anfangen würde." Der Überblick ist also so ehrlich wie das Lächeln einer amerikanischen Kellnerin. Und er ist kontraproduktiv, weil er langweilt, denn der Zuhörer/Leser merkt, dass er gegängelt wird. Nicht er muss sich aufwärmen, sondern eher der Referent/Autor. Aussagen über Aussagen, die man gleich machen wird, kann man quasi immer ersatzlos streichen. Der mündige Leser informiert sich anhand des Inhaltsverzeichnisses, wie der Gedankengang des Autors ist. Wenn ein Überblick nötig ist, dann aus der Sache heraus und nicht, weil es dir Form vorschreibt.

Ebenfalls kontraproduktiv finde ich 2 Seiten voll mit dem, was man in dem Buch nicht (!) findet. Zur Profilierung und um allzuübliche Missverständnisse zu vermeiden, mag es gelegentlich angezeigt sein, auch zu sagen, worum es nicht geht. Aber gleich zwei Seiten? Und das bei einem Buch, das laut Einband "umfassendes Wissen" verspricht? Wie kann denn da soviel nicht behandelt sein?

Dieser Gedanke bringt mich nun unweigerlich zur zentralen Frage: Wer ist denn überhaupt die Zielgruppe? Was beabsichtigt das Buch genau? "Umfassendes Wissen" klingt zwar toll, aber macht mich auch hellhörig und skeptisch, wie - trotz aller Reinigung - nicht anders zu erwarten nach meinem Blogposting zur Unsitte dicker Fachbücher. Auf Seite 40 geht es endlich mit dem wirklichen Thema los.  Abgesehen vom Inhaltsverzeichnis kann ich also 30 Seiten überschlagen, um den Einstieg in das "umfassende Wissen" zu bekommen. Aber an wen richtet sich das dann? Seite 24 gibt eine genauso knappe wie simple Antwort: "Diese Buch besitzt keine scharf abgegrenzte Zielgruppe". So einfach ist das. Meine 6jährige Tochter zähle ich zwar nicht zu dieser großen Gruppe, aber alle, die sich wohl irgendwie mit der Softwareentwicklung für mobile Geräte im weitesten Sinne beschäftigen, gehören zu ihr. Egal, ob der Leser also Vorkenntnisse im Bereich .NET hat oder nicht, egal, ob er Vorkenntnisse im Bereich .NET CF hat oder nicht, egal, ob er Datenbankvorkenntnisse hat oder nicht, sich mit ASP.NET auskennt oder nicht, Multithreading beherrscht oder nicht... er gehört immer zur Zielgruppe.

Das (!) halte ich für den wesentlichen Fehler dieses wie vieler anderer dicker Bücher. Wer in die Zielgruppe so groß fasst, das er Schwierigkeiten hat, sie einzugrenzen, der hat keine und der weiß daher auch nicht, was ins Buch gehört und was nicht. Eine Zielgruppendefinition ist ein Maßstab, an dem man misst, ob Themenaspekte beschrieben werden sollten oder nicht. Er ist die Latte, auf der abgelesen werden kann, in wecher Art und welcher Tiefe Wissen vermittelt werden sollte. Ohne einen solchen Maßstab aber gilt: anything goes. Und das drückt sich im Inhalt aus und kann im Grunde schon aus dem Inhaltsverzeichnis. Es fehlt die thematische Kontur. Die aber ist nötig, denn der Buchtitel ist zu breit, als dass er angesichts dessen, was so ganz allgemein darunter fallen könnte, genügend Kontour böte.

Warum haben weder Autoren noch Verlag den Mut gehabt, eine Zielgruppe zu definieren? Sie hätten sich an erfahrene .NET-Programmierer wenden können, denen sie die Besonderheiten des .NET CF aufzeigen. Das Buch hätte sich dann auf die Beschreibung einer Differenz zwischen zwei sehr ähnlichen Plattformen konzentrieren können. Die Darstellungen hätten dann alle sehr tief gehen können, weil viel grundsätzliches Vorwissen in der Leserschaft einfach vorhanden gewesen wäre. Oder man hätte den Plattformeinsteiger adressieren können, den C/C++-Entwickler, der bisher schon im embedded/mobile Bereich gearbeitet hat und jetzt auf den .NET CF umsatteln will. Dann wäre klar gewesen, dass keine Differenz, sondern Grundlegendes vermittelt werden müsste. Tiefe wäre dann nicht nötig, sondern Überblick. Oder Autoren und Verlag hätten Entwickler angesprechen können, die schon Erfahrung mit dem .NET CF haben, um ihnen Best Practices aufzuzeigen. Grundlegendes und Differenzen wären dann unwichtig gewesen; stattdessen wäre es um Tiefe und Erfahrungswerte gegangen.

In der gegenwärtigen Form holt das Buch aber nicht wirklich die Leser ab. Aus Verlagssicht mag das noch einen gewissen Charme haben, denn für ein Buch, das sich an alle wendet, ist jeder vor dem Regal ein potenzieller Käufer. Wer beim Lesen jedoch hinter das Themensperrfeuer blickt, der kommt nicht umhin festzustellen: Wer alles für alle sein will, ist am Ende nichts für niemanden. Dafür ein paar Beispiele:

Wem nützt das Kapitel über "Die Geschichte von Mobile Computing"? Die Idee dahinter ist verständlich und es hätte ein interessanter Rückblick auf die embedded/mobile Softwareentwicklung dabei herauskommen können. Die Geschichte, also das Vergangene beschränkt sich jedoch auf knapp 4 Seite von 20 des Kapitels. Die Darstellung muss also notwendig oberflächlich sein. So ist denn auch nichts über seinerzeit hochgepriesene Technologien wie Auto-PC, den PC in der Uhr (SPOT Produkte) oder die ersten Tablet-PC Versuche Anfang der 1990er zu lesen. Auch vermisse ich in diesem Zusammenhang eine visualisierte Entwicklungsgeschichte der Microsoft Entwicklungsplattform für embedded/mobile Geräte zusammen mit ihren Betriebssystemgeschmacksrichtungen. Das alles hätte sinnvoll Platz gehabt in einem geschichtlichen Abriss. Stattdessen bietet die Geschichte auf 15 Seiten den Versuch einer Darstellung der Gegenwart einiger Windows Mobile Komponenten wie Internet Explorer oder ActiveSync. Und abschließend wird das Für und Wider mobiler Anwendungen vs. Web-Anwendungen diskutiert. Was hat das mit Geschichte zu tun? Das gehört in ein Architekturkapitel.

Wem nützt das Kapitel "Die .NET-Plattform als Basis für Mobile Computing"? Hier könnte man eine Diskussion darüber erwarten, warum eine standardisierte Managed Code Plattform einen Vorteil für die Entwicklung mobiler Anwendungen hat. Warum nicht C++, warum aber auch nicht Java? Angesichts einer nicht definierten Zielgruppe ist es aber den Autoren natürlich schwer gefallen, ein klares Niveau der Darstellung zu finden. So schwankt man zwischen kurzer Abhandlung von grundlegend Konzeptionellem wie der Überwindung der DLL-Hölle durch .NET und mehrseitiger Erklärung für ein Implementatiosndetail wie Namensräume. Daran schließen sich dann 7 Seiten Schnelldurchlauf von allgemeinen Anwendungsarchitekturschlagworten wie "Präsentationsschicht" und "Verteilte Anwendungen" an, um von 7 Seiten Ausführungen zu "XML-Webdienste[n]" gefolgt zu werden. Da gibt es dann auch hübsche PDA-Emulatorscreenshots zu sehen und auch Code, sogar SQL-Skripte zur Einrichtung eines SOAP-Endpunktes im SQL Server 2005.  Ganz am Ende widmet sich das Kapitel dann noch auf 3 Seiten dem .NET Compact Framework mit einem Schaubild und einer Liste der Unterschiede zum .NET Framework. Aber was hat das nun alles in Bezug auf das Kapitelthema gebracht? Hat ein in Sachen .NET unbedarfter Leser etwas über den .NET Framework erfahren können? Nein. Dafür hätte die Darstellung der .NET-Grundlagen breiter sein müssen. Ein Unbedarfter hätte nach einer so kurzen Einführung dann aber auch mit den folgenden Ausführungen nichts mehr anfangen können; sie wären zu speziell gewesen. Hat sich das Kapitel also an den erfahrenen .NET-Entwickler gewandt? Warum dann ein Ausflug in die Grundlagen? Und warum das Thema Architektur? Hat es speziell etwas mit Mobile Computing zu tun? Kann man die Grundbegriffe nicht ohnehin voraussetzen, unabhängig davon, ob der Leser schon Erfahrung mit dem .NET Framework hat oder nicht? Selbst ein VB6- oder Java-Entwickler wird nicht umhin gekommen sein, vom Schichtenmodell gehört zu haben. Und mehr als eine ganz flüchtige Einführung hat das Kapitel hierzu auch nicht gegeben. Sie ist daher überflüssig. Die originären Vorteile von .NET für das mobile Computing hingegen sind nicht wirklich herausgearbeitet worden. Von knapp 30 Seiten des Kapitels beschäftigen sich nur 3 wirklich mit ihm.

Wem nützt das Kapitel "Vorbereitung auf die Entwicklung für mobile Geräte"? Das wird mit dem "Aufbau von .NET Compact Framework" begonnen - ein Thema, das ich im vorhergehenden Kapitel erwartet hätte -, um nach einem Dutzendschaubild im Vorbeigehen AppDomains auf 1 Seite einzuführen und dann 3 Seiten lang die Garbage Collection zu thematisieren. Anschließend eine halbe Seite zur Sicherheit - und das war´s.  Jetzt soll der Leser wissen, wie der .NET CF aufgebaut ist. Denn es folgen als "Neuerungen im .NET Framework 2.0" nur Generics - was ist mit all den anderen Neuerungen? - und dann in einer Tabelle "Neues im .NET Compact Framework 2.0". An wen hat sich dieser Abschnitt gewandt? Anfänger haben nichts über den .NET Framework oder CG gelernt. Fortgeschrittene .NET Entwickler ohne Erfahrung mit dem .NET CF auch nicht. Weiter gehts mit einer Vorstellung von VS2005: 1 Seite Informationen wie aus einer Marketingbroschüre, dann die Information "Das Visual Studio ist eine IDE [...]". Dann 5 Seiten mit Neuerungen in VS2005 - die zumindest z.B. für unbedarfte C++ embedded Software Entwickler mit Umstiegswille, die ja auch zur Zielgruppe gehören, nichts bringen. Warum sollte auch ein Buch zum Thema .NET CF auch nur ein Wort über das Refactoring oder CodeSnippets in VS2005 verlieren? Aber jetzt... es ist kaum zu glauben, auf 3 Seiten geht es wirklich um spezifische Aspekte des mobile Computing rund um mobile Device Emulatoren. Wie sich die Arbeit mit einem Emulator aber gestaltet... davon ist hier nicht die Rede. Aber vielleicht kommt das ja im nächsten Kapitel. Hier sollen ja auch nur Vorbereitungen behandelt werden. Zu denen gehört sicherlich auch ganz dringend Lutz Roeders Reflector und NUnit. Und das war´s. Fertig mit der Vorbereitung. Aber was habe ich gelernt? Nichts. Ich fühle mich nicht auf die "Entwicklung für mobile Geräte" vorbereitet. Weder kenne ich jetzt den .NET CF, wenn ich ihn vorher noch nicht kannte. Noch habe ich eine Ahnung, wie ich ein Programm für ein mobiles Gerät in VS2005 schreibe und im Emulator ausprobieren kann. Dier Prozess - so einfach er sein mag - ist nicht mit einem Beispiel demonstriert worden.

Wem nützt das Kapitel "Einführung in die Entwicklung für mobile Geräte"? Ah, da kommen jetzt mal die Projektvorlagen für Geräteanwendungen vor.  Aber nach noch nicht einmal 2 Seiten geht es um Details des WinForms-Designers wie den Gebrauch von partiellen Klassen gleich neben der Abbildung der Eigenschaften eines Buttons. Wen will man damit erreichen? Wer nichts über partielle Klassen weiß, lernt hier nichts. Eine Entschädigung könnten eventuell allerdings die 1,5 Seiten darstellen, die dem Deploymentprozess eines Hello-World-Programms in einen Emulator hinein gewidmet sind. Aber dann hat es sich auch mit dieser Besonderheit der .NET-CF-Programmierung. Es folgen knapp 20 Seiten mit der Vorstellung von Benutzersteuerelementen wie Label, TextBox, TreeView usw. Ein Nutzen ist dabei leider nicht zu erkennen. Weder findet hier eine Gegenüberstellung der Eigenschaften dieser Steuerelemte mit ihren Pendants beim .NET Framework statt, noch wird wirklich erklärt, wie die Steuerlemente zu nutzen sind. Den Abschluss des Kapitels bilden 6 Seiten eines vielversprechenden Themas: "Hybride Anwendungen". Es ist der Frage gewidmet, ob und wie Anwendungen möglich sind, die sowohl auf dem .NET Framework, d.h. Desktop Rechnern, wie auch auf dem .NET CF, d.h. mobilen Geräten, laufen. Das (!) ist nun wirklich mal ein Thema, das zum Titel des Buches passt und auch jeden Leser interessieren sollte. Leider empfinde ich die Behandlung als oberflächlich und unvollständig. Einziges Thema sind WinForms-Benutzeroberflächen. Was ist aber mit ASP.NET-Seiten, die sowohl hüben wie drüben angezeigt werden sollen? Oder welche Teile des .NET Framework sollte man nicht einsetzen, um portabel zu sein? Wie wäre es mit einem Hinweis zur Architektur von hybriden Anwendungen? Nicht nur, dass das Thema besser ans Ende des Buches gepasst hätte, weil es eigentlich die Kenntnis beider Plattformen voraussetzt, die Autoren schweigen auch zu diesen selbst für mich als .NET-CF-Laie auf der Hand liegenden Fragen. Fühle ich mich am Ende des Kapitels nun eingeführt in die Entwicklung für mobile Geräte? Nein. Die Spezifika von mobilen Geräten wurden nur im Vorbeigehen behandelt und die Darstellung hat sich auf Oberflächliches im doppelten Sinn beschränkt: Allereinfachstes wurde für WinForms-GUIs besprochen.

Wem nützt nun das Kapitel "Erweiterte Möglichkeiten bei der Entwicklung für mobile Geräte"? Schon der Titel lässt vermuten, dass es hier, hm, sehr allgemein zugehen wird. Von "Möglichkeiten" ist immer die Rede, wenn ein konkreterer Begriff grad fehlt. Und unter "erweiterte Möglichkeiten" passt dann wirklich alles, was irgendwie noch nicht gesagt wurde. Doch dann die Überraschung: Laut Inhaltsverzeichnis, das jeweils auch noch auf "Kapiteltitelblatt" aufgeführt ist, behandelt das Kapitel nur ADO.NET. Warum hat man es dann nicht "Datenbankprogrammierung mit dem .NET CF" genannt oder "ADO.NET für .NET CF"? Weil das nächste Kapitel schon so ähnlich heißt? Vielleicht. Vielleicht aber auch, weil man noch viel mehr für dieses Kapitel vorhatte, dann aber die Zeit nicht mehr reichte? Ich weiß es nicht. In jedem Fall beschränken sich die "Erweiterte[n] Möglichkeiten" auf ADO.NET. Auf 20 Seiten wird eine Einführung in den Datenbankzugriff mit ADO.NET versucht von der Connection bis zum Databinding. Eine Erklärung, was es früher mit COM auf sich hatte, gibt es als Bonus noch dazu - ohne das ich wüsste, was das nun hier soll. (Interessanterweise taucht diese "Definition" im Index auch gar nicht auf.) Darüber hinaus ist es immer schlecht, wenn eine Definition des Definierten (hier: COM) folgt. Das ist hier aber der Fall. Auf COM wurde schon mehrfach angespielt (z.B. im Zusammenhang mit der DLL-Hölle). Aber weiter mit ADO.NET. Was soll diese Darstellung? Wer ADO.NET noch nicht kannte, kann durch sie nicht wirklich lernen, was das Besondere an ADO.NET ist. Und wer es schon kannte... der konnte nichts dazu lernen. Ein schlicht überflüssiges Kapitel.

Wem nützt das Kapitel "Programmierung von Datenbanken für mobile Anwendungen"? Es mutet zunächst an wie eine Marketingbroschüre für den SQL Server 2005. Da ist von Enterprise Data Management und Business Intelligence die Rede. Da steht ein Dialog zum Aufbau einer Verbindung mit dem SQL Server nur 2 Seiten entfernt von einer SQL CLR Funktion. Dann 6 Seiten zum Thema OLAP, die nichts mit mobile Computing zu tun haben. Und jetzt... 35 (!) Seiten zum Thema "Eine mobile Datenbank-Anwendung". Wow! Da geht es richtig zur Sache mit Synchronisationsmechanismen. Das (!) ist relevant für mobile Computing. Die Anwendung, um die es laut Überschrift aber gehen soll, findet sich kaum beschrieben. Es geht im Grunde nur um Infrastruktur, der Rest ist auf der Buch-CD zu finden. Das finde ich schwach. Es überlässt dem Leser den Aufbau eines Kontextes, in dem die ganzen Infrastruktureinrichtungen erst Sinn ergeben. Didaktisch schlecht. Hier wäre ein Motivation am Anfang mit einem Überblick angezeigt gewesen nach dem Motto "Was wir machen wollen und was wir dafür benötigen und wie wir dann vorgehen werden".

Nach 233 Seiten bzw. knapp einem Drittel des Buches erlaube ich mir, seine Analyse nun abzuschließen. Für den Rest schaue ich nocheinmal ins Inhaltsverzeichnis:

Der Umgang mit dem Dateisystem wird auf knapp 20 Seiten beschrieben inkl. der Behandlung von kommaseparierten Dateien. Das grundlegende Stream-Konzept findet hier allerdings keine Erwähnung. Das finde ich verwunderlich. Welchen Eindruck soll ein Neuling von den Fundamenten des .NET Framework da bekommen?

Für die Entwicklung von "Multithreading-Anwendungen" stehen knapp 40 Seiten zur Verfügung. Ein sicherlich wichtiges Thema, das ich allerdings nicht so konkret im Zusammenhang mit mobilen Anwendungen sehe. Sicher können und sollen dort auch mehrere Threads zum Einsatz kommen. Aber muss dem Thema im Vergleich zu anderen, die eine größere Zahl von Entwicklern betreffen, soviel Raum gegeben werden?

"Zugriff auf Netzwerke" umfasst knapp 40 Seiten und behandelt von GPRS über MSMQ und AJAX bis zu Bluetooth scheinbar alles, was irgendwie mit Kommunikation zu tun hat. Außer Webservices, die ja schon viel früher einmal dran waren und auch bei XML nochmal einen Kurzauftritt hatten. Überprüfung des Headsets und XML-Dateninseln scheinen auch irgendwie mit Kommunikation zu tun zu haben, denn darum geht es auch in diesem Kapitel. Eine eigenwillige Mischung.

Emulatoren und Unit Tests sind auf 30 Seiten zusammengefasst. Einen groben Zusammenhang kann ich da erkennen, aber für wirklich geglückt halte ich die gemeinsame Abhandlung nicht. Ohne Emulatoren geht es nicht. Aber Unit Tests sind "lediglich" eine Best Practice.

Auf 40 Seiten kommt dann doch auch noch endlich das Thema Deployment zur Sprache. Warum es aber nicht am Ende des Buches steht, sondern danach noch Multimedia-Techniken folgen... das verstehe ich nicht.

Fazit

Ich habe das Buch nicht Seite für Seite gelesen. Ich möchte ihm, den Autoren und dem Verlag auch kein Unrecht tun. Dennoch glaube ich, dass die ausführlicheren Kapitelschilderungen - pars pro toto - die Qualität des Buches treffend beschreiben. Es ist gut gemeint, hat grundsätzlich bestimmt einen Markt - mobile Computing ist gefragt und wird immer gefragter -, aber es leidet unter Konzeptlosigkeit. Das Konzept, allen etwas zu bieten, ist kein tragfähiges Konzept. Allemal nicht, wenn dieser Anspruch dann so unsystematisch umgesetzt wird wie hier. Es fehlt das Gefühl, was wichtig und was unwichtig ist. Auf der einen Seite werden weitgehend irrelevante Schlagworte abgehandelt, auf der anderen Seite offensichtlich Relevantes nicht behandelt. Insbesondere die fehlende Definition von Voraussetzungen - was auf Seite 27 gelistet wird, ist wenig hilfreich - zeigt sich immer wieder. Sie führt zur Behandlung von Themen, die entweder nicht behandelt werden müssten oder die zu flach behandelt werden. So verpufft der Aufwand und bläht das Buch nur unnötig auf.

Mein Gefühl ist, dass hier drei Autoren mit sehr gutem Willen ein wichtiges Thema angegangen haben - aber in der Durchführung am Mangel einer klaren Vision wie auch an einer zu wenig koordinierten Verschiedenheit ihrer Interessen gescheitert sind. Das Buch sagt sicherlich auch Gutes und Richtiges, doch das ist versteckt im Rauschen des Überflüssigen. Schade.

Letztlich fühle ich mich aber dadurch in meiner These bestätigt. Das ist zwar nicht wirklich mein Ziel gewesen, aber trotz aller Reinigung komme ich nun doch nicht drumherum. Das Buch ist zu dick. Auf das wirklich Wichtige gekürzt und mit in einigen Bereichen verbesserter Darstellung könnte es mit vielleicht 350 Seiten gut sein - vorausgesetzt, eine Zielgruppe wird klar definiert.

Sorry, Torsten.

PS: Mein Urteil mach sich nun besonders schlimm anhören, weil ich hier ein Buch herausgegriffen habe. Zur "Milderung der Umstände" sei aber gesagt, dass viele Fachbücher in der Softwareentwicklung unter denselben Symptomen leiden: interessantes Thema, gute Idee - aber schlechtes Konzept und mangelnde Struktur/didaktische Schwäche. Es ist eben schwer, ein Buch zu schreiben. Und je dicker, desto schwerer. Aus das ein Grund, warum ich gegen dicke Fachbücher sind. Sie gehen soviel leichter daneben.

PPS: Ich habe übrigens grad neulich ein Buchprojekt wieder abgesagt, das ich angeleiert hatte. Der Grund: Ich war mir der Struktur und Didaktik nicht mehr so sicher wie zum Zeitpunkt der Idee. Das Thema ist weiterhin wichtig und ich schreibe auch darüber. Aber angesichts unerwarteter Hürden in der Technologie, konnte ich die Struktur noch nicht genügend gut festlegen, weil ich die Puzzleteile noch nicht alle im Blick habe. Also schreibe ich lieber (erstmal) kein Buch, als eines, bei dem ich mich so durchs Thema laviere.

 

Technorati tags: Rezension