Softwarearchitektur kompakt - prio.conference 2008

Als wie relevant das Thema Softwarearchitektur inzwischen in der Community wahrgenommen wird, hat die prio.conference der dotnetpro am 10./11. November gezeigt: mehr als 260 Teilnehmer hatten den Weg nach Baden-Baden ins Kurhaus gefunden. Das ist eine Zahl, die mich als Content Manager der prio sehr gefreut hat - und ich hoffe, dass nicht nur das Oberthema im Großen, sondern auch meine Auswahl von Vortragsthemen und -referenten im Kleinen dazu einen Beitrag geleistet hat.

Erstes Feedback stimmt mich da aber positiv. So ist zum Beispiel die Keynote des (wahrscheinlich) einzigen wirklichen Architekten vor Ort sehr gut angekommen. Prof. Dr. Christian Kühn aus Wien hat einen interessanten Bogen von seinem Metier der Bauarchitektur zur Softwareentwicklung geschlagen. Denn wenn sich schon die Pattern-Bewegung der Softwareentwicklung auf bauarchitektonische Patterns bezieht, ist es angezeigt einmal zu beleuchten, welche Relevanz die denn eigentlich haben. Und so haben die Anwesenden nicht nur erfahren, wie die Patterns schon vor Erich Gamma et al. ihren Weg in die Softwarebranche gefunden hatten, sondern auch, wie Prinz Charles mit Patterns verbunden ist.

Nach solchem Blick über den Tellerrand ging es dann aber mit "echten" Softwareinhalten los. In 30 Sessions haben die Referenten den Bogen vom Konzeptionellen wie der Definition von Architekturrollen und Dokumentation über eher unbekannte Technologien wie Microsofts CCR oder PostSharp bis zu handfesten Tipps zum Transport von veränderlichen Objekten per WCF gespannt.

Besonders haben mich die Kommentare zum Thema Jabber gefreut. Die Teilnehmer waren hocherfreut zu erfahren, dass es solch coole Kommunikationstechnologie gibt - und gleichzeitig erstaunt, dass sie bisher davon noch nichts gehört hatten. Denn Jabber kann vieles schon lange, was Microsoft erst heute mit seinem Communication Server anfängt zu realisieren. Und dabei ist Jabber bzw. seine Server und Clients vielfach kostenlos und reifer.

Ebenfalls über den Horizont der vielfach Microsoft-lastigen Welt der .NET-Community hinaus hat Referent Markus Völter mit seinen Vorträgen zum Thema Domänenspezifische Sprachen (DSL) geblickt. Er hat vorgeführt, wie auf der Basis der oAW Plattform mit Eclipse (!) schon heute eigene textuelle Sprachen inkl. Codegeneratoren realisiert werden können. Wer also nicht auf Microsofts Oslo warten will, der kann jetzt loslegen.

Die prio hat somit nicht nur viele Facetten des Themas Softwarearchitektur beleuchtet, sondern bewusst weiter geblickt als die üblichen Microsoft-lastigen Events. Softwarearchitektur hat zwar immer mit Entwicklungsplattform zu tun, sollte sich von ihr aber nicht unnötig beschränken lassen. Relevante und interessante Entwicklungen gibt es jenseits von Linq, Entity Framework, WPF, Silverlight oder dem sich schon zur Welle hebenden OsloAzureWindows7.

Aber nicht nur das Fachliche hat Spaß gemacht. Der Abend stand wieder ganz im Zeichen der Heimat der dotnetpro: alle Teilnehmer trafen sich im Löwenbräu zu einem nah ans Oktoberfest-Original heranreichenden bayrischen Abend. Der war ausnehmend gemütlich - auch wenn er Sprecher und Veranstalter sich nicht nur entspannen konnten. Wie schon im Vorjahr galt das Motto der englischen Offiziersakademie Sandhurst: serve to lead - dienen, um zu führen. Und so bedienten Sprecher und Chefredakteur die Teilnehmer vor und hinter dem Thresen.

Das hat Laune gemacht und wieder ganz neue Einblicke in die Community gegeben :-)

Im nächsten Jahr wird die prio solche Gemütlichkeit jedoch nicht mehr "exportieren" müssen. 2009 findet die prio.conference in der dotnetpro Heimatstadt München statt. Das Thema steht auch schon fest. Es wird um "User Interfaces" gehen. Und es wird natürlich wieder technisch und praktisch und konzeptionell werden. Von Usability bis DataBinding Best Practices gibt es viel zum Thema zu sagen. Immerhin sind User Interfaces das Aushängeschild unserer Anwendungen.

Aber zur Softwarearchitektur wird die dotnetpro bis dahin sicher auch nicht stumm bleiben. Stay tuned!

Interrupt? Nein, danke! [OOP 2009]

Es ist schon erstaunlich, wie unterschiedlich Menschen sein können:

Situation 1: Auf der Straße unterhalte ich mich mit einer Nachbarin. Die hat ihren 5-jährigen Sohn dabei. Nach 2-3 Minuten Plauderei ruft der plötzlich "Mama, Mama, ich würde gern...". Die Mutter daraufhin sofort: "Nicht jetzt! Ich unterhalte mich gerade. Gleich bin ich aber für dich wieder da."

Situation 2: Im Café sitzen neben mir zwei Frauen ins Gespräch vertieft. Da klingelt plötzlich das Handy der einen. Sie zögert nicht, nimmt ab und plaudert mit dem Anrufer mehrere Minuten. Die andere blättert derweil klaglos zur Überbrückung in einer Zeitschrift.

Situation 3: Während eines Beratungsauftrags sitze ich mit einem Entwickler über einem Architekturproblem in seinem Büro. Plötzlich geht die Tür auf und der Projektleiter fordert ihn auf, sofort einem Kollegen bei der Lösung einer Aufgabe zu helfen.

Hm... was haben diese Situationen gemeinsam? Da sind Menschen in etwas vertieft und es tritt eine plötzliche Störung durch einen Dritten ein.

Und was unterscheidet diese Situationen voneinander? Nur in einem Fall entscheiden sich die ins Gespräch vertieften zu einer Abwehr der Störung. Nur das Kind wird als Störenfried in seine Schranken verwiesen. Die Mutter macht ihm klar, dass es nicht jederzeit Zugriff auf sie hat, sondern darauf achten muss, ob Mutter gerade offen für eine Ansprache ist. Sieht es hingegen, dass Mutter anderweitig beschäftigt ist, soll es sich gedulden.

Daran ist grundsätzlich nichts auszusehen, würde ich sagen. Es ist höflich, nicht zu unterbrechen. Das sollte ein Kind lernen.

Wie ist solche Lehre aber zu vereinbaren mit dem Verhalten der beiden Frauen im Café? Sie lassen sich ganz einfach durch einen Anruf unterbrechen. Sie nehmen das nicht nur in Kauf, sondern provozieren es geradezu, indem sie ihre Handys angeschaltet lassen. Dass sie Ärztinnen oder Bestatterinnen sind, die jederzeit auf Abruf zu erreichen sein müssen, war allerdings nicht zu erkennen.

Warum lassen sich erwachsene Frauen die Unterbrechung von einem Kind nicht gefallen, aber von jedem anderen, der noch nicht einmal anwesend ist? Hm... darüber kann man einen Moment nachdenken. Doch über die wahren Beweggründe für diese Unterbrechungstoleranz will ich hier gar nicht reden. Mir fiel angelegentlich dieser Situation nur die Diskrepanz zwischen Anspruch und Wirklichkeit auf.

Denn der allgemeine Anspruch ist ja, dass man nicht gestört werde, wenn man in etwas vertieft ist. So lautet die pädagogische Reaktion der Mutter. Auf der anderen Seite tolerieren oder provozieren wir jedoch die Unterbrechung. Im privaten Umfeld mag das auch unproblematisch sein. Im geschäftlichen jedoch wird das schnell teuer.

Wissensarbeit wie in Situation braucht nämlich eines: Konzentration. Um gute Wissensarbeit - und nichts anderes ist Softwareentwicklung - leisten zu können, müssen sie sich fokussieren können. Sie brauchen Störungsfreiheit. Entwickler durch "Chefanfragen" immer wieder in ihrer Arbeit zu unterbrechen, ist daher kontraproduktiv. Sie müssen ihren Fokus verlassen und später wieder aufbauen. 15min "Umschaltzeit" sind dabei durchaus keine Seltenheit.

Im Grunde wissen das auch alle vom Wissensarbeiter bis zum Top-Manager. Multitasking funktioniert nur sehr begrenzt. Dennoch verhalten sie sich aber alle anders.

Obige Situation 2 hat mir nun klar gemacht, woran das liegt. Das Unterbrechungsproblem in der Arbeitswelt kann nicht besser werden, solange wir es nicht konsequent umfassend angehen. Wer sich im privaten Bereich gern unterbrechen lässt, das Handy immer auf Empfang hat und verständnisvoll-verzeihend nickt, wenn andere angerufen werden, der darf sich nicht wundern, wenn am Arbeitsplatz auch immer wieder unterbrochen wird.

Die Gründe für solche Ambivalenz mögen verständlich sein. An den weitreichenden Auswirkungen der Ambivalenz ändert das jedoch nichts. Wer sich einem Kind gegenüber die Unterbrechung verbittet, sie aber im Freundeskreis toleriert oder gar erwartet, darf sich nicht wundern, wenn er dann am Arbeitsplatz keine "produktive Unterbrechungskultur" etablieren kann.

Ich möchte nicht ohne Handy, SMS, Email, IM usw. leben. Aber wichtiger als diese Medien ist mir immer noch mein Fokus. Und so habe ich kein Verständnis mehr für Unterbrechungswilligkeit. Ich schalte (spätestens ab heute) meine "Unterbrechungsmedien" ab, wenn ich im Gespräch bin. Und ich werde sonstige Unterbrecher höflich, aber bestimmt auf die Kontraproduktivität ihrer Unterbrechung hinweisen. Kinder und Manager machen da für mich keinen Unterschied. Das halte ich vielmehr für eine Grundlage höflichen und respektvollen Umgangs miteinander.

NETZ it! - Komponentenorientierte Software ausliefern leicht gemacht

"Soooviele Assemblies???" ist der ungläubige Ausruf, den ich oft höre, wenn ich ich über Komponentenorientierung spreche. Denn damit komponentenorientierte Entwicklung wirklich ihre Vorteile ausspielen kann, ist es nötig, Software nicht nur logisch in Komponenten zu zerlegen, sondern die auch noch physisch getrennt zu implementieren. Das bedeutet, jeder Komponentenkontrakt und jede Komponentenimplementation wird zu einer eigenen Assembly. Die Zahl der Assemblies einer Anwendung ist also immer mindestens doppelt so groß wie die ihrer Komponenten.

Das hört sich viel an. Oder zumindest ungewohnt. Schon bei 3 Komponenten kommen 5 oder 6 Assemblies zusammen, wie die nebenstehenden Beispielanwendung zeigt. Und größere Anwendungen bestehen schonmal aus 50 oder 100 Komponenten und damit 100 oder 200 Assemblies.

Einen "materiellen" Nachteil hat das jedoch nicht. Der .NET Framework kommt damit ganz gut zurecht. Nur Visual Studio nicht. Es macht keine Freude, in einer Visual Studio Projektmappe mehr als vielleicht 10 Projekte zu verwalten. Aber das soll man ja auch nicht.  (Insofern entspricht die Abbildung links nicht dem Ideal; ich habe die Projekte nur für eine einfachere Darstellung so zusammengefasst.)

Echte Komponentenorientierung bedeutet vielmehr, dass alle Komponenten in je eigenen Projektmappen entwickelt werden. Wenn Sie an einer Komponente arbeiten sollen Sie nicht abgelenkt werden durch Implementationsdetails anderer Komponenten, die in derselben Projektmappe liegen.

Doch auch wenn es keinen "materiellen" Nachteil hunderter Assemblies für eine Anwendung gibt, verstehe ich, dass sie dazu angetan ist, den Überblick zu verlieren. Vor allem wollen Sie womöglich dem Kunden gegenüber solche Detailfülle nicht offenlegen. Die Abbildung rechts zeigt, wie ich die Beispielanwendung eigentlich ausliefern müsste: als "Sack von Assemblies". Das ist zwar einfach, aber mag sich eben zumindest merkwürdig anfühlen.

Krücke ILmerge

Nun habe ich aber noch nie behauptet, dass die Zahl der Assemblies zur Entwicklungszeit der zur Zeit der Auslieferung gleich sein müsse. Immer schon habe ich auf die Möglichkeit hingewiesen, sie mit Microsofts ILmerge zusammenzufassen. Aus den 7 zur Anwendung gehörenden Assemblies (inkl. DI Framework Infrastruktur) rechts im Bild könnte mit ILmerge ganz leicht eine werden.

Sie anders zusammenfassen, wäre allerdings nicht unproblematisch. Zum Beispiel könnten Sie nicht nur alle Kontrakt-Assemblies vereinigen, weil Sie damit die Referenzen darauf in den Komponentenimplementationen invalieren würden. Die beziehen sich ja auch konkrete Assemblynamen, die es dann nicht mehr gäbe.

ILmerge funktioniert zwar grundsätzlich. Ist aber letztlich nur eine Krücke, weil es nicht genügend Freiheitsgrade bietet. Außerdem mag es nicht jedem schmecken, dass ILmerge den IL-Code "anfasst". Zugegebenermaßen ein Vorgang, bei dem mehr falsch laufen könnte, als wenn man Assemblies, so wie sie sind, irgendwohin kopiert.

NETZ to the rescue

Aber diese Zeit der Krückenlösung ist nun vorbei! Durch einen News-Schnippsel in einer Entwicklerzeitschrift bin ich auf das Open Source Tool NETZ gestoßen. Das ist echt cool für die komponentenorientierte Entwicklung! Und es ist auch noch eines aus deutschen Landen - ein seltener Umstand bei Softwareentwicklungstools.

Was bietet NETZ? Zusammenfassung und Kompression von Assemblies. Mit NETZ können Sie Assemblies wie mit ILmerge zusammenfassen, allerdings ohne Eingriff in den IL-Code. NETZ verpackt die Assemblies einfach nur als Ressourcen in eine von ihm generierte.

Für die Komponentenorientierung unwichtig, aber für Sie dennoch vielleicht interessant, komprimiert NETZ die Assemblies während der Zusammenfassung auch noch. So kann der in den Ressourcen steckende IL-Code nicht mehr so einfach decompiliert werden. Ohne Obfuscation erhalten Sie also einen ersten Schutz gegen beiläufige Ausspähung von Implementationsdetails.

Die obige Beispielanwendung in eine Assembly zusammenzufassen, ist mit NETZ ganz einfach. Eine Kommandozeile wie diese reicht (sie ist nur der Lesbarkeit wegen hier in mehrere Zeilen geteilt):

netz -z -s
  frontend.exe
  -d logic.dll dataaccess.dll
       contracts.logic.dll contracts.dataaccess.dll
       Microsoft.Practices.Unity.dll Microsoft.Practices.ObjectBuilder2.dll

Mit ihr verpackt NETZ alle Assemblies in eine neue Assembly (-s), die auch eine DLL zur Dekompression enthält (-z). Alle Assemblies können auch dynamisch geladen werden (-d) - das ist für die Nutzung eines DI Frameworks nützlich sein mag. Das Resultat: eine Assembly mit Namen frontend.exe und einer Struktur wie in der nachstehenden Abbildung. Der Start-Code wurde komplett durch NETZ generiert (Methoden auf der linken Seite), die Anwendungsassemblies sind zu Ressourcen geworden (rechts). Der NETZ-Code sorft dafür, dass beim Laden einer Assembly, die die CLR nicht selbst findet, die Ressourcen herangezogen werden.

Schon bis hierhin bietet NETZ also mehr als ILmerge. Nicht nur Zusammenfassung von Assemblies, sondern gleichzeitig Kompression - und das ohne Eingriff in den Assembly-IL-Code.

NETZ kann aber noch mehr! NETZ kann die Assemblies auch in externe Ressourcen verpacken. So können Sie sie beliebig gruppieren. Auf die Referenzen hat das keinen Einfluss. Bilden Sie also beliebige Gruppen von Assemblies. Die Beispielanwendung habe ich z.B. einmal so zusammengefasst wie rechts zu sehen. In frontend.exe steckt die ursprüngliche EXE mit den Microsoft Unity DI Infrastruktur-Assemblies. Die contracts-Ressourcen enthalten die Kontrakt-Assemblies, die components-Ressource die Implementationen. Ganz einfach ist damit einem Batch wie diesem:

netz -z -s frontend.exe Microsoft.Practices.Unity.dll Microsoft.Practices.ObjectBuilder2.dll
netz -xr contracts contracts.logic.dll contracts.dataaccess.dll
netz -xr components dataaccess.dll logic.dll

move *-netz.resources frontend.exe.netz

Der -xr Switch weist NETZ an, die Assemblies nicht zu einer EXE, sondern zu einer externen Ressource zusammenzufassen. Der NETZ-Start-Code sucht in solchen Ressourcendateien im selben Verzeichnis sogar zuerst nach Assemblies.

Lassen Sie sich durch 50 oder 100 Assemblies nicht in Bockshorn jagen. Fassen Sie sie für´s Deployment mit NETZ einfach so zusammen, wie Sie es möchten: alle zu einer großen Assembly oder Kontrakte und Implementationen getrennt oder Kontrakte zusammen mit ihren Implementationen oder alle Assemblies einer Kategorie (z.B. alle Domänenlogik-Assemblies getrennt von allen Aspekt-Assemblies). Mit NETZ ist das alles sehr einfach möglich. Und kostenlos dazu! Mein herzlicher Dank gilt Vasian Cepa, dem Entwickler! (Der ist übrigens sehr bemüht; innerhalb eines Tages hatte er eine Verbesserung eingebaut, auf die ich ihn angesprochen hatte.)

Ich arbeite jetzt nicht mehr ohne NETZ in meinen komponentenorientierten Projekten.