J and I and Me
2006-08-05
  Nochmal: AOP
Ein Kommentar zum letzten AOP-Posting (Danke für das Feedback!) kritisiert, dass es noch keine Best Practices zu Thema AOP gibt. Dem muss ich natürlich widersprechen...

Dabei könnte ich erstmal auf unser AOP-Training hinweisen, das diese Themen behandelt, aber solche billige Werbung erspare ich mir lieber...

Mein Kollege Adrian Colyer, der sich mittlerweile schon eine Ewigkeit mit AOP beschäftigt und zuvor z.B. an der Einführung von AOP bei IBM u.a. in den Middleware Bereich gearbeitetet hat, schägt ein Verfahren vor, wie man AOP einführen kann. Durch das Verfahren wird auch das Design-Thema klar: Er schlägt vor, als ersten Schritt Aspekte zu definieren, die bei z.B. aus Layering Gesichtspunkten heraus verbotene Operationen (siehe hier) als Compiler-Error klassifizieren. Als nächsten Schritt sieht er dann die klassischen technischen Aspekte wie Tracing, Profiling usw, die bei AspectJ auch in Development und Production Aspekte eingeteilt werden. Erst dann kommt Aspekt-orientierte Analyse und fachliche Aspekte. Zu diesem Thema hat Ivar Jacobson auch schon ein Buch geschrieben (immerhin der Erfinder der Use Cases...) und es gibt auch noch ein zweites Buch in diesem Bereich (siehe unten). Also gibt es sogar im Bereich AOP Analyse bereits publizierte Best Practices.

Diese Diskussion bezieht aber noch nicht Spring ein und durch Spring ändert sich hier nochmal einiges. Ohne AOP kann man nämlich keine nicht-triviale Spring-Applikation bauen. Security, Transactions usw. bauen alle darauf auf und es gibt auch eine breite Vielfalt an vorbereiteteten technischen Aspekten (Tracing, Performance Monitoring), die man nutzen kann. Daher ist durch Spring der erste Schritt zur Adaption von AOP die Benutzung von Spring, bei der man ohne AOP eh nicht auskommt. Das Schreiben eines eigenen Aspekts ist ebenfalls recht einfach und auch in der Online-Doku nachzulesen. Daher gibt es hier eigentlich auch keine Barriere: Spring ohne AOP macht keinen Sinn und selber Aspekte schreiben ist recht einfach. Man muss es nur tun...

Das interessante ist nun, dass man bereits mit diesen technischen Aspekten zum Teile ganze Layer einsparen kann, weil man eben Security, Transactions und auch Exception-Handling nicht mehr in jeder Klasse ausprogrammieren muss, sondern es zentral irgendwo als Aspekt macht. So gibt es Beispiele, in denen es ganze Layer gibt, die nur für die Remote Aufrufe die Themen Security, Transactions und Konvertierung der Exceptions behandeln und dabei einen signifikanten Anteil des Gesamtcodes darstellt, weil man eben für jede Remote zugreifbare Funktion nochmal dasselbe hinschreibt. Nur mit AOP oder ähnlichen Hilfsmitteln kann man das zentralisiert implementieren und das ist wirklich kein Hexenwerk. Deswegen glaube ich, dass man nur mit AOP den Don't-Repeat-Yourself-Imperativ in statisch typisierten Programmiersprachen umsetzten kann und halte AOP für eine wesentliche Basis-Technologie.

Zweifel habe ich im Bereich aspekt-orientierter Analyse. Meine Erfahrung ist, dass auch objekt-orientierte Analyse noch nicht flächendeckend eingeführt ist, so dass es fraglich ist, ob man hier schon in den Bereich Aspekt-Orientierung vorstoßen will, wenn man Objekt-Orientierung noch nicht vollständig umgesetzt hat.

Meiner Meinung nach hat man schon bei der Beschränkung von AOP auf technische Aspekte ein großes Produktivitätspotential. Diesen Bereich hat die Software-Entwicklungs-Community auch gut verstanden und setzt es spätestens seit EJB 1.0 auch so um - schließlich sind Transaktionen und Security dort als eine Art Aspekt implementiert, auch wenn niemand es damals so genannt hat und vollwertige AOP-Lösungen auch mitttlerweile wesentlich mächtiger sind.

Also schauen wir mal - immerhin bietet Spring 2.0 einen einfacher Einstieg in AspectJ, so dass Spring 2.0 die Einstiegsbarriere für AspectJ eliminiert. Bei der Popularität von Spring kann es sehr gut sein, dass dadurch auch AspectJ sich einer deutlich breiteren Benutzer-Basis erschließt.



  11:51
Bookmark and Share
Comments:
Guten Tag,

ich denke, dass aspektorientierte Analyse etwas ziemlich spannendes ist - mit guten Codegeneratoren möglicherweise sogar spannender als aspektorientierte Programmiersprachen, die ja fast alle Java-basiert sind.

Sichten sind ein klassisches Problem in der Anforderungsanalyse - eine vernünftige Anforderungsspezifikation kann eigentlich nur von unterschiedlichen Stakeholder-Perspektiven aus beschreiben. Die Integration dieser Sichten ist harte Arbeit, für die es bisher wenig methodischen Support gibt. Theme/Doc (in dem Clarke/Baniassad-Buch in Ihrem Blog beschrieben) hat da einen spannenden Ansatz, der sich von einer relativ informale Ebene hin zu einer UML-basierten Analyse (Theme/UML) arbeitet. In dem Buch werden eine Menge kluge Sachen über das Zusammenführen von Modellen gesagt; ähnlich übrigens in dem Jacobson-Buch, wobei der einen stärker über Use Case getriebenen Ansatz verfolgt. Sowohl in Theme als auch bei Jaobson ist das Kompositionsmodell hochspannend und interessanterweise auch anderes als das Kompositionsmodell von AspectJ.

Gruß

Erich Pawlik
 
Hallo Herr Wolf,

Die in ihrem Blog gemachten Aussagen treffen genau meine Sicht der Dinge: POJO-zentierter Ansatz zur Modellierung der Fachdomäne und Auslagerung der technischen Infrastruktur-Themen in Aspekten (vgl. Richardson - POJOs in Action).
(Eine interessante Fragestellung in diesem Rahmen ist die Frage, ob man Persistenz auch als Aspekt betrachten sollte - hier lohnt sich meiner Meinung nach eine weitere Betrachtung, würde aber dem Rahmen dieses Threads nicht gerecht werden und wäre insofern ein Thema für eine separate Diskussion).

Wie schon geschrieben (und in Ihrem Blog nochmals verdeutlicht) habe auch ich meine Zweifel, was Aspekt-orientierte Analyse und Design der Fachlichkeit angeht. Der Umstand, dass dieses Gebiet noch relativ neu ist mag eine Sache sein (natürlich heisst dies nicht, dass eine Methode nur deswegen schlecht sein muss, weil sie noch neu und von einem Grossteil der Fachwelt noch nicht durchdrungen ist).
Wesentlich ist aber die Frage, ob uns diese Methode darin unterstützt fachliche Komplexität so zu modellieren, dass diese Verständlich, Erweiterbar und Wartbar bleibt. Hier werden dann auch kognitive Fragestellungen zur Art und Weise wie wir generell mit komplexen Sachverhalten umgehen und in welcher Weise/Paradigma dies am besten abgebildet werden kann interessant.

Die (freiwillige) Beschränkung von AOP (zunächst) auf technische Aspekte bringt einen grossen Mehrwert mit sich, frei nach dem Motto 'nicht alles was möglich ist ist auch sinnvoll'. Die Einschränkung auf techniche Belange bringt uns dem alten Wunsch 'Konzentration auf die Business-Logik' einen Schritt näher, bei gleichzeitiger Reduktion der Komplexität im Umgang mit Infrastruktur-Themen. Hier gilt meiner Meinung nach der alte Spruch: Weniger kann durchaus mehr sein ... :o)

Viele Grüsse

Mario Gleichmann
 
Kommentar veröffentlichen

<< Home
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff