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