Aspektorientierte Softwareentwicklung

Transkript

1 Ausarbeitung zum Thema Aspektorientierte Softwareentwicklung Erstellt von: Thomas Steinhart HS Furtwangen CN 8 Für: Leiter: Hr. F. Kaspar

2 Inhaltsverzeichnis Inhaltsverzeichnis... 2 Einleitung... 3 Aspekt-Orientierte Software Entwicklung (AOSD)... 4 Was ist ein Aspekt?... 4 Crosscutting Concerns... 4 Separation of Concerns... 5 Ein Beispiel... 6 Der objektorientierte Lösungsansatz... 6 Der aspektorientierte Lösungsansatz... 7 Aspektorientierte Tools... 9 AspectJ... 9 CaesarJ... 9 Funktionsweise von CaesarJ...10 Noch ein Beispiel...10 AspectJ vs. CaesarJ...14 Fazit...15 Literaturverzeichnis /15 Thomas Steinhart

3 Einleitung Die Aspektorientierung ist ein relativ junges Forschungsgebiet mit dem Ziel, Methoden, Sprachen und Werkzeuge für die bessere Modularisierung von funktionalen und nicht funktionalen Belangen zu entwickeln (Bonomo-Kappeler, 2004). In herkömmlichen, objekt-orientierten Systemen können die Kernfunktionen für sich allein sauber in verschiedenen Klassen modularisiert werden. Allerdings gibt es in jedem System auch nicht funktionale Belange, so genannte Crosscutting Concerns (Stal, 2005). Diese Crosscutting Concerns schneiden sich sozusagen quer durch die Kernfunktionen eines Systems (engl. crosscut). Dazu gehören Funktionen wie z.b. Autorisierung, Logging, Tracing, etc. Diese Funktionen lassen sich nicht eindeutig zu einer der Kernfunktionen zuordnen sondern sind durch das gesamte System verstreut. Dadurch verhindern sie eine wirklich saubere Modularisierung und verschlechtern somit die Wartbarkeit, Lesbarkeit, Wiederverwendbarkeit und (Rück-) Verfolgbarkeit (Bonomo-Kappeler, 2004). Diese allerdings sind heutzutage wichtige Kriterien vor allem in Bezug auf die Kosten eines Systems. Die Aspektorientierung beschäftigt sich nun genau mit diesem Problem und versucht Lösungswege aufzuzeigen und Werkzeuge bereitzustellen /15 Thomas Steinhart

4 Aspekt-Orientierte Software Entwicklung (AOSD) Aspektorientierte Software-Entwicklung ist, wie eingangs schon erwähnt, ein sehr junges Forschungsgebiet des Software Engineerings. Sie wird definiert als die Berücksichtigung von Entwurfsentscheidungen, welche quer durch das ganze System getroffen werden müssen (crosscutting concerns) (Bonomo-Kappeler, 2004). Die Aspektorientierung steckt noch in den Kinderschuhen ihrer Entwicklungsphase, zeigt aber schon einige Methoden zur Vorgehensweise auf, die z.t. auf bewährten Methoden des Software Engineerings aufsetzten wie z.b. auf UML. Wie der Name schon andeutet bezieht sich die Aspektorientierung auf einzelne Aspekte, die aus verschiedenen Funktionalitäten heraus definiert und als separate Konstrukte implementiert werden um somit Kernfunktionalitäten zu bereinigen und auf ihre eigentlichen Funktionen zu beschränken. Was ist ein Aspekt? In der Literatur lassen sich verschiedene Definitionen zu Aspekt finden. Allerdings widersprechen sich die einzelnen Definitionen nicht sondern gehen mehr oder weniger tief in die Thematik ein. 1. Definition: Aspekt. Modulare Implementierung eines Crosscutting Concerns. (Definition von Lieberherr, Orleans, Ovlinger, 2001 aus (Bonomo-Kappeler, 2004)) 2. Definition: Aspekt. Modulare Einheit einer crosscutting Implementierung. (Ivar Jacobson, 2004) 3. Definition: Aspekt. Funktionale Einheit, die durch das ganze übrige Systemverhalten gewoben ist. (Siobhán Clarke, 2005) Wie Bonomo-Kappeler zeigt, sind noch einige weitere Definitionen zu finden, allerdings ist die hier als 1.Definition genannte die bevorzugte Definition. Ein Aspekt ist also ein modular implementierter Crosscutting Concern. Was aber ist ein Crosscutting Concern? Crosscutting Concerns Das Wort Concern geht nach Duden (1997) auf lateinisch concernere beachten, berücksichtigen, betreffen, sich beziehen auf, eigentlich Unterschiedliches /15 Thomas Steinhart

5 zusammenmischen (lateinisch con zusammen, mit und lateinisch cernere unterscheiden ) zurück. Es lässt sich auf Deutsch mit Angelegenheit, Interesse, Beziehung übersetzen (Langenscheidt 1991). In der Literatur zu AOSD finden sich zu Concern u.a. folgende Definitionen: 1. Definition: Concern. Spezifische Anforderung oder Gesichtspunkt, welche(r) in einem Software-System behandelt werden muss, um die übergreifenden Systemziele zu erreichen (Laddad, 2003). 2. Definition: Concern. Irgendeine Sache, die an einem System interessiert, d.h. ein Ziel oder eine Menge von Eigenschaften, die das System erfüllen muss (Definition von Brito, Moreira, 2004 aus (Bonomo-Kappeler, 2004)). Auch hier ist die erste Definition wiederum die zu bevorzugende, da sie präziser ist. Ein Concern stellt also eine spezifische Anforderung dar, die behandelt werden muss um übergreifende Systemziele umzusetzen. Dazu gehören natürlich die Kernfunktionalitäten (Core Concerns), ohne die es kein System gäbe. Aber auch durch diese Core Concerns quer schneidende (engl. crosscut), nicht zu diesen Core Concerns gehörende Funktionalitäten gehören hier dazu. Diese werden Crosscutting Concerns genannt. 3. Definition: Crosscutting Concerns. Realisieren diejenigen Funktionen eines Systems, welche die Core Concerns oder andere Crosscutting Concerns quer schneiden, beispielsweise Authentisierung oder Logging (Laddad, 2003). Ein Aspekt stellt somit eine modular implementierte, spezifische Anforderung dar, die mehrere Core Concerns betrifft und diese quer schneidet. Wie aber erkennt man nun einen solchen Aspekt bzw. den Crosscutting Concern? Separation of Concerns Generell versucht man, die Anforderungen während der Planungsphase eines Software Systems zu separieren, d.h. zu identifizieren und so zu trennen, dass die einzelnen Concerns voneinander unabhängig bzw. Schnittmengenfrei sind (Stal, 2005). Dadurch lassen sich die einzelnen Anforderungen separat planen, implementieren und erst später, wenn das Projekt schon weiter fortgeschritten ist, sauber zusammenfügen. Bei diesem Schritt fallen nun die nicht funktionalen Belange bzw. die Anforderungen, die mehrere Core Concerns betreffen, aber nicht dazugehören, auf. Sie werden als /15 Thomas Steinhart

6 Crosscutting Concerns spezifiziert und somit in die Planung mit aufgenommen und später dann als Aspekte implementiert. Ein Beispiel Anhand eines Beispiels kann die Thematik und Problematik der Aspektorientierung etwas verdeutlicht werden. Im Folgenden soll die Methode booking() einer Klasse RoomBooking am Beginn und Ende der Methode mitgeloggt werden. Dies geschieht durch eine Klasse Trace und deren Methoden traceentry(string) und traceexit(string). Der objektorientierte Lösungsansatz UML-Klassendiagramm UML-Sequenzdiagramm Trace RoomBooking :RoomBooking :Trace +traceentry() +traceexit() +booking() booking() traceentry() Code von booking() traceexit() Hier erkennt man sehr deutlich die Probleme der objektorientierten Implementation dieses Aspekts: 1. Die booking()-methode enthält neben ihren eigentlichen Kernfunktionalitäten auch noch die Aufrufe für traceentry() und traceexit(). Dadurch sind die Wiederverwendbarkeit und die Lesbarkeit des Codes eingeschränkt. Dieses Problem wird Tangling genannt (Siobhán Clarke, 2005) /15 Thomas Steinhart

7 2. Das Tracing-Verhalten ist über beide Klassen (RoomBooking, Trace) verteilt. Dies hat zur Folge, dass auch jede andere Methode, die das Tracing implementieren soll, die Methodenaufrufe implementieren muss. Änderungen des Aufrufs müssen also in allen aufrufenden Methoden durchgeführt werden. Dieses Problem wird Scattering genannt (Siobhán Clarke, 2005). Diese Probleme sind mit den Methoden der Objektorientierung nicht oder nur sehr schwer zu umgehen. Der aspektorientierte Lösungsansatz Der aspektorientierte Lösungsversuch moduliert nun die Tracing-Funktionalität als Aspekt. Somit enthält die Klasse RoomBooking keinen Aufruf von traceentry() oder traceexit() mehr. Das übernimmt alles der Aspekt Tracing. Der dafür erforderliche Code des Tracing-Aspekts sieht in AspectJ in etwa folgendermaßen aus: public aspect Tracing { before () : withincode (void Main.startTest()) && call (void RoomBooking.booking()){ Trace.traceEntry(); after () : /15 Thomas Steinhart

8 withincode (void Main.startTest()) && call (void RoomBooking.booking()){ Trace.traceExit(); Der Code kann natürlich nicht mit dem normalen Java-Compiler kompiliert werden. Dazu ist (in diesem Fall) der AspectJ-Compiler verantwortlich /15 Thomas Steinhart

9 Aspektorientierte Tools AspectJ AspectJ ist eine Mehrzweck-, aspektorientierte Erweiterung zur Java- Programmiersprache. Aus diesem Grund ist jedes gültige Java Programm auch ein gültiges AspectJ Programm. Ein AspectJ-Compiler erzeugt.class-dateien die konform mit der Java Byte-Code Spezifikation sind und die von jeder Java Virtual Machine ausgeführt werden können. Dadurch, dass AspectJ Java als Grundsprache verwendet, nutzt es alle Vorteile von Java und macht es Java Programmierern einfach, die AspectJ Sprache zu verstehen (Laddad, 2003). Aspektorientiertes Programmieren funktioniert kurz gesagt folgendermaßen: Man entwickelt die Java Klassen mit den Kernfunktionen seines Systems, dann entwickelt man die Aspekte, die die Crosscutting Concerns bilden. Ob man die Objekte und Aspekte zusammen, separat, nacheinander oder parallel entwickelt hängt nur davon ab, welche Entwicklungsstrategie man verwendet. Wichtig ist, dass, nach dem man alles fertig entwickelt hat, man das Ganze mit dem AspectJ-Compiler kompiliert. Er macht die komplette horizontale Bündelung in Java und erzeugt dann den ausführbaren Byte-Code (Kiselev, 2003). Der AspectJ-Compiler ist als Eclipse Plug-In erhältlich unter CaesarJ Bisher wurde nur die Möglichkeit in Betracht gezogen, Crosscutting Concerns in AspectJ zu implementieren. CaesarJ bietet dagegen die Möglichkeit, Aspekte nicht nur zu lokalisieren sondern sie auch wieder verwendbar zu machen. CaesarJ bietet sich somit sehr gut an für Produktlinienarchitekturen die z.b. viel mit Plug-Ins arbeiten. CaesarJ ist wie AspectJ eine auf Java basierende, aspektorientierte Sprache die Mechanismen zur Verfeinerung und Komposition in größerem Umfang integriert. Kompositionsmechanismen wie Vererbung und Polymorphie werden auf Gruppen von Klassen und nicht nur auf einzelne Klassen angewendet. Ausserdem bietet CaesarJ die Möglichkeit, neue Komponenten ohne Änderung des bestehenden Quelltextes in ein existierendes System zu integrieren. Wie für AspectJ gibt es auch für CaesarJ ein Eclipse Plug-In unter /15 Thomas Steinhart

10 Funktionsweise von CaesarJ CaesarJ arbeitet mit in sich geschlossenen Funktionseinheiten, die mehrere Klassen und alle relevanten Abstraktionen, die für eine Komponente bzw. ein Feature notwendig sind, beinhalten. Das bedeutet, dass alle für eine Komponente bzw. ein Feature notwendigen Klassen in abstrakten Klassen geschachtelt sind, ähnlich wie inner classes in Java. Allerdings können hier die inneren Klassen, genau wie die Methoden in diesen Klassen, in Ableitungen der äußeren Klasse überschrieben bzw. erweitert werden. Diese inneren Klassen sind darum virtuelle Klassen. Um sowohl innere als auch äußere CaesarJ Klassen von normalen Java Klassen zu unterscheiden, werden sie nicht mit dem normalen class-schlüsselwort eingeleitet sondern mit cclass. Die Funktionseinheiten entsprechen in etwa den Aspekten, die oben definiert wurden. Allerdings sind diese Funktionseinheiten wieder unterteilt in Core Concerns und Elementen, die direkt mit der originalen Anwendung zu tun haben. Dies garantiert eine modulare Bauweise der Komponenten. Als Schnittstelle von einer Komponente bzw. einem Feature zu einer Anwendung werden in CaesarJ so genannte collaboration Interfaces (CI) implementiert. Diese definieren die Klassenordnung sowie provided - und expected - Methoden für die virtuellen Klassen. Provided Methoden definieren die Funktionalität und damit die Core Concerns der Komponente bzw. des Features. Expected Methoden dienen zur Abfrage kontextspezifischer Informationen, die notwendig sind wenn bestimmte Teile der Komponente anwendungsspezifisch sind. Noch ein Beispiel An einem Beispiel (entnommen aus (Iris Groher, 2005)) soll gezeigt werden, wie die Implementierung aussehen kann. Dabei soll eine Pricing-Komponente zu einer StockInformationBrocker-Anwendung hinzugefügt werden, um Aktienkursabfragen preislich zu belangen. Die Anwendung sieht wie folgt aus: /15 Thomas Steinhart

11 Folgender Code zeigt die Implementierung eines collaboration Interfaces für die Pricing-Komponente: abstract cclass PricingCI { abstract public cclass Customer { /* provided */ abstract public double getbalance(); abstract public void charge(item it); abstract public Bill createbill(); /* expected */ abstract public String getcustinfo(); abstract public cclass Item { /* provided */ public double getprice(); public double gettax(); public BillLine createbillline(); /* expected */ public double getbaseprice(); public String getitemdescr(); Die einfache Implementierung der Pricing-Komponente sieht folgendermaßen aus, wobei hier nur die provided Methoden implementiert werden, da sie nur die Core Concerns der Komponente darstellt: abstract cclass SimplePricing extends PricingCI { abstract public cclass Customer { private double balance; private List billlines; public double getbalance() { return balance; public void charge(item item) { balance -= item.getprice(); /15 Thomas Steinhart

12 billllines.add(item.createbillline()); public Bill createbill() { String header = "Bill for " + getcustinfo();... abstract public cclass Item { public double getprice() { return getbaseprice() + gettax(); public BillLine createbillline() { return new BillLine(getItemDescr(), getprice(), gettax()); public double gettax() {... Nun muss diese Implementierung aber auch an die originale StockInformationBroker- Anwendung gebunden werden, d.h. sie muss in die Anwendung integriert werden. Dies geschieht bei CaesarJ mit Hilfe eines Bindings. Dabei werden die restlichen expected Methoden implementiert: abstract public cclass PerStockRequestBinding extends PricingCI { public cclass ClientCustomer extends Customer wraps Client { public String getcustinfo() { return wrappee.getclientname() + " " + wrappee.getclientid(); public cclass StockItem extends Item wraps StockInfoRequest { public double getbaseprice() { return 5 + wrappee.getstocks().length * 0.2; public String getitemdescr() { return "Stock req. "+ wrappee.getstocks().length; after(client client, StockInfoRequest request) : (call(stockinfo StockInfoBroker.collectInfo(..)) && this(c) && args(request)) { ClientCustomer(client).charge(StockItem(request)); /15 Thomas Steinhart

13 Das Binding beschreibt also die Verbindung zwischen Features und Anwendung. Bisher waren alle Klassen abstrakt. Um die ganzen Einzelteile nun funktionsfähig miteinander zu kombinieren muss ein Binding mit einer Komponentenimplementierung (den Core Concerns) kombiniert werden. In diesem Beispiel kann mit der folgenden Deklaration SimplePricing mit PerStockRequestBinding kombiniert werden: cclass SimplePricingPerStockRequest extends SimplePricing & PerStockRequestBinding { Dieses Konstrukt zeigt nun eine Klasse die von zwei anderen Klassen erbt. Das ist möglich, da CaesarJ eine einfache Form der Mehrfachvererbung unterstützt wobei die Vererbungshierarchie linearisiert wird, um die typischen Probleme von Mehrfachvererbung zu vermeiden. Die Klassenkomposition setzt sich durch den &-Operator rekursiv in allen geschachtelten Klassen fort, d.h. durch die Komposition der umschließenden Klassen werden auch alle anderen, unterschiedlichen Erweiterungen derselben virtuellen Klassen ebenfalls miteinander kombiniert. Somit werden alle Implementierungen der expected und der provided Methoden der virtuellen Klassen miteinander kombiniert: Um nun die SimplePricingPerStockRequest Klasse tatsächlich einzubinden, muss ein Objekt dieser Klasse explizit mit Hilfe eines Deployment-Mechanismus aktiviert werden. Hierzu wird das Pricing-Feature für den Block innerhalb der Klammern nach dem Schlüsselwort deploy aktiviert, danach ist es wieder deaktiviert: final SimplePricingPerStockRequest pricing = /15 Thomas Steinhart

14 new SimplePricingPerStockRequest(); deploy (pricing) { StockInfoRequest request = new StockInfoRequest(stockList); StockInfo si = StockInformationBroker.getInstance().collectInfo( request); /* Advice ist während der Ausführung dieses Blocks aktiviert*/ CaesarJ bietet mehrere unterschiedliche Deployment-Mechanismen, von denen hier aber nur dieser eine verwendet wird. Dieser ganze Aufwand bringt nun einige Vorteile zur üblichen Implementierung mit AspectJ oder gar mit objektorientierten Mitteln: Die einzelnen Implementierungen, wie PerStockRequestBinding (Binding), SimplePricing (Core Concerns) und PricingCI (Collaboration Interface) können wieder verwendet werden. Verschiedene Implementierungen können miteinander kombiniert werden. Und die Einbindung erfolgt komplett nicht invasiv, was bedeutet, dass die Klassen der ursprünglichen Anwendung nicht geändert werden müssen. AspectJ vs. CaesarJ AspectJ und CaesarJ unterscheiden sich in einigen wesentlichen Punkten: - Behandlung von Aspekten: Bei AspectJ ist ein Aspekt keine Java Klasse und kann deshalb auch nicht instanziiert werden. Bei CaesarJ werden Aspekte als Objekte implementiert und könne je nach bedarf aktiviert oder deaktiviert werden. - Ansatz in der Sichtweise: AspectJ wird meist nur in Verbindung mit der Lösung von Crosscutting Concerns gesehen. CaesarJ wurde mit der Aufgabenstellung entwickelt, ein effektives Werkzeug für die Entwicklung von Software-Systemfamilien zu haben /15 Thomas Steinhart

15 Fazit Meiner Meinung nach ist die Entwicklung und Anwendung von CaesarJ ein logischer Schritt nach der Entwicklung und Einführung der AOSD und AspectJ. Der generelle Ansatz der AOSD ist wichtig und gut um Software besser zu Modularisieren und vermehrt Wiederverwendbar zu machen. Ob der Quellcode dadurch allerdings Lesbarer wird (Bonomo-Kappeler, 2004) wage ich angesichts der komplexen Strukturen von CaesarJ zu bezweifeln. Literaturverzeichnis - Bonomo-Kappeler, I. (2004). Aspektorientierte Software-Entwicklung Unter Besonderer Berücksichtigung Der Begrifflichen Zusammenhänge Und Der Einbettung in Den Entwicklungsprozess. Unpublished Diplomarbeit, Universität Zürich, CH-5430 Wettingen. - Iris Groher, V. G., Christa Schwanninger, Klaus Ostermann. (2005). Aspektorientierte Softwareentwicklung Mit Caesarj. Java Spektrum, 6/2005, Ivar Jacobson, P.-W. N. (2004). Aspect-Oriented Software Development with Use Cases: Addison-Wesley. - Kiselev, I. (2003). Aspect-Oriented Programming with Aspectj: Sams Publishing. - Laddad, R. (2003). Aspectj in Action. Greenwich: Manning Publications Co. - Siobhán Clarke, E. B. (2005). Aspect-Oriented Analysis and Design - the Theme Approach: Addison-Wesley. - Stal, M. (2005). Aspekte Ohne Grenzen. Java Spektrum, 6/2005, /15 Thomas Steinhart