JavaSpektrum Dezember/Januar 2006 [antikvár]

Editorial I Aspekte ohne Grenzen ^ Der Schwerpunkt der vorliegenden ^Ausgabe thematisiert aspektorientierte Softwareentwicklung oder zu gut Neudeutsch AOSD (Aspect-Oriented Software Development). Wenn nun AOSD die Antwort auf die Fragen aller Fragen nach dem Leben, dem Universum und dem ganzen Rest darstellt, fragt sich der geneigte Leser zu Recht, wie denn die eigentliche Frage lautet. Wer sich jetzt, von Wissensdurst getrieben, anschickt, virtuell in Wikipedia zu blättern, dem fliegt unweigerlich die Phrase „Separation of Concerns" um die Ohren. Trennung der Belange subsumiert neben einer auch in der Patterns-Community beliebten Waffe, eine Problemstellung geradezu biblischen Ausmaßes - zumindest in Bezug auf die von Softwareentwicklern anerkannten Bibeln (siehe „Hitchhiker's Guide to the Galaxy"). Unter „Separation of Concerns" ist konkret zu verstehen, dass sich eine Problemdomäne bei der Lösungserstellung jederzeit so in voneinander unabhängige Belange partitionieren lässt, dass die daraus resultierenden Lösungsmodule schnitt-mengenfrei sind. (Anm.: an dieser Stelle dürfen Sie sich ruhig beeindruckt ob dieser eleganten Definition die Augen reiben und darüber nachdenken, ob ich Sie nicht doch hinters Licht geführt habe.) Die gute alte Objektorientierung alleine kann diese Trennung der Belange nicht leisten. Der Grund dafür liegt auf der Hand. Softwareentwickler und -architekten haben einen derart eingeschränkten Blickwinkel - behauptet zumindest meine Lebensgefährtin -, dass sie sich nur gleichzeitig auf einen Aspekt konzentrieren können. Bei Analyse- und Entwurfsaktivitäten liegt der Fokus daher auf der Anwendungsdomäne, während alle anderen Belange dabei allenfalls als lästige Seiteneffekte erscheinen. Welcher Anwendungsent- wickler ohne masochistische Grundveranlagung möchte schon gerne freiwillig in die Untiefen von Multithreading, Logging oder Persistenzaspekten eintauchen? Leider hat diese domänenorientierte Vorgehensweise einen entscheidenden Haken. Sie funktioniert schlechthin nicht für die Umsetzung ineinander verwobener funktionaler und erst recht nicht für die Integration vieler nicht-funktionaler, speziell invasiver Anforderungen. Sollten wir uns also jetzt langsam von objektorientierten Plattformen wie Java verabschieden? Vom Chefredakteur einer Java-Zeitschrift können Sie hier selbstverständlich keine „positive" Antwort erwarten. Zum Glück eilt das aspektorientierte Paradigma seinem betagten Urahn zur Hilfe und erlaubt, die Problemdomäne aus mehreren unterschiedlichen Perspektiven in einer Art Matrix-Sicht Zu beleuchten und die daraus resultierenden Belange anschließend systematisch zu kombinieren. Das klingt zwar abstrakt, erweist sich bei genauerem Nachdenken aber als naheliegend. Die Problematik stellt im Übrigen kein Alleinstellungsmerkmal für Softwareentwicklung dar, sondern tritt durchaus auch in anderen Lebensbereichen zu Tage. Etwa bei der Arbeit in größeren Organisationen. Die meisten Unternehmen besitzen eine hierarchische Linien-Orga-nisation, die bei abteilungsübergreifen-den Projekten oft durch Matrix-Organi-sationen Ergänzung findet. Aktivitäten wie projektunabhängige Meetings, Reiseorganisation, Kaffeepausen oder Einkauf bilden dort die typischen nicht-funktio-nalen Belange (Cross-Cutting Concerns) und werden, wie auch bei der Softwareentwicklung, eher als störend und kon-tra-produktiv empfunden. Ein weiteres Beispiel ist das Schreiben dieses Editori-als, das meine beiden Stubentiger als willkommenen Anlass betrachten, von Zeit zu Zeit Aufmerksamkeit zu erheischen. Zu den Cross-Cutting Concerns gesellen sich hier somit „Streicheln", „Füttern" und „Stresstest der Wohnungseinrichtung". Ihnen schwant so langsam, dass Aspektorientierung nicht nur für Softwareentwickler interessant sein könnte? Als ich unlängst ein Seminar über verteilte Architekturen durchführte und dabei das Thema aspektorientierte Programmierimg zur Sprache kam, waren einige Teilnehmer noch überhaupt nicht mit diesem Ansatz vertraut. Gleichwohl fanden sie die Thematik spannend und sahen Potenzial für dessen praktische Nutzung. Bei einem der „Unwissenden" handelte es sich um einen reinen Microsoft-.NET-Entwickler ohne Java-Vor-strafenregister. Und in der Tat scheinen einzig für die Java-Plattform ausgereifte Werkzeuge wie AspectJ sowie Frameworks mit integrierter AOP-Unterstüt-zung wie JBossAOP zu existieren. Doch auch zu allen Java-Entwicklern ist die Mächtigkeit aspektorientierter Ansätze noch längst nicht durchgedrungen. Das verwundert nicht, wenn bei der Frage der Einsatzgebiete immer wieder dieselben „Killerapplikationen" zur Sprache kommen. Zu den üblichen Verdächtigen gehören Logging und Tracing. Zudem unterliegen viele Architekten wegen der starken Verbreitung von AspectJ dem Irrglauben, Aspektorientierung sei gleichbedeutend mit code-basiertem Aspect-Weaving und daher im Grunde eine rein implementierungs-spezifische Angelegenheit. Das ist ein großer Irrtum, stellt das aspektorientierte Paradigma doch in Wirklichkeit einen holistischen Ansatz dar, der sich über alle Entwicklungsphasen erstreckt, von der Anforderungsanalyse bis hin zur Wartung. Eigenschaften wie Skalierbarkeit, Hexibilität oder Per-formanz lassen sich nun einmal durch rein funktionale Use-Case-Szenarien nicht abdecken. Einer der Gründe übrigens dafür, dass - zumindest aus meiner eigenen Erfahrung - viele Softwareprojekte partiell oder gänzlich scheitern. Zum Glück sind sich immer mehr Softwareexperten dieser Problemstellung bewusst und beschäftigen sich mit der Exploration aspektorientierter Konzepte. Langsam aber sicher finden diese Ansätze auch Eingang in die kommerzielle Softwareentwicklung. Nur an der Erstellung und Verbreitung aspektorientierter Methoden und Werkzeuge hapert es noch immer. Die große Koalition aus Objektorientierung und Aspektorientierung macht jedenfalls einen vielversprechenden Eindruck, sollte sich aber bei der Geschwindigkeit der Umsetzimg nicht an den politischen „Vorbildern" orientieren. In diesem Sinne viel Spaß mit der vorliegenden Ausgabe von JavaSPEKTRUM Ihr Michael Stal