Aspektorientierte Softwareentwicklung - Aspect-oriented software development

Beim Computing ist die aspektorientierte Softwareentwicklung (AOSD) eine Softwareentwicklungstechnologie , die nach neuen Modularisierungen von Softwaresystemen sucht , um sekundäre oder unterstützende Funktionen von der Geschäftslogik des Hauptprogramms zu isolieren . Mit AOSD können mehrere Anliegen separat zum Ausdruck gebracht und automatisch in funktionierenden Systemen zusammengefasst werden.

Die traditionelle Softwareentwicklung konzentriert sich auf die Zerlegung von Systemen in Einheiten der Primärfunktionalität, wobei erkannt wird, dass es andere Probleme gibt, die nicht gut in die Primärzerlegung passen. Der traditionelle Entwicklungsprozess überlässt es den Programmierern, Module zu codieren, die der primären Funktionalität entsprechen, und sicherzustellen, dass alle anderen Probleme, die von Belang sind, im Code behandelt werden, wo immer dies angebracht ist. Programmierer müssen alle Dinge im Auge behalten, die getan werden müssen, wie mit jedem Problem umgegangen werden soll, welche Probleme mit den möglichen Interaktionen verbunden sind und wie das richtige Verhalten zur richtigen Zeit ausgeführt wird. Diese Bedenken erstrecken sich über mehrere primäre Funktionseinheiten innerhalb der Anwendung und führen häufig zu schwerwiegenden Problemen bei der Anwendungsentwicklung und -wartung. Die Verteilung des Codes zur Realisierung eines Problems wird besonders kritisch, wenn sich die Anforderungen für dieses Problem ändern. Ein Systembetreuer muss eine Vielzahl von Situationen finden und korrekt aktualisieren.

Die aspektorientierte Softwareentwicklung konzentriert sich auf die Identifizierung, Spezifikation und Darstellung von Querschnittsthemen und deren Modularisierung in separate Funktionseinheiten sowie deren automatisierte Zusammensetzung zu einem funktionierenden System.

Geschichte

Aspect-Oriented Software Development beschreibt eine Reihe von Ansätzen zur Software Modularisierung und Zusammensetzung , einschließlich, in der Reihenfolge der Veröffentlichung, Reflexion und Metaobjekt Protokolle , Zusammensetzung Filter , an der entwickelten Universität Twente in den Niederlanden, subjektorientierten Programmierung (später erweitert als mehrdimensionale Trennung of Concerns ) bei IBM, Feature Oriented Programming an der University of Texas in Austin, Adaptive Programming an der Northeastern University , USA, und Aspect-Oriented Programming (AOP) am Palo Alto Research Center . Der Begriff "aspektorientiert" wurde von Gregor Kiczales und seinem Team am Palo Alto Research Center eingeführt, die auch zuerst das explizite Konzept von AOP und die AOP-Sprache namens AspectJ entwickelten, die in der Java-Entwicklergemeinde beträchtliche Akzeptanz und Popularität erlangt hat.

Derzeit sind mehrere aspektorientierte Programmiersprachen für eine Vielzahl von Sprachen und Plattformen verfügbar.

So wie die objektorientierte Programmierung zur Entwicklung einer großen Klasse objektorientierter Entwicklungsmethoden führte , hat AOP eine Reihe neuer Software-Engineering-Technologien gefördert, einschließlich Methoden für den Umgang mit Aspekten und Modellierungstechniken (häufig basierend auf den Ideen von Unified) Modellierungssprache (UML) und Testtechnologie zur Bewertung der Wirksamkeit von Aspektansätzen. AOSD bezieht sich nun auf eine breite Palette von Softwareentwicklungstechniken, die die Modularisierung von Querschnittsthemen in einem Softwaresystem unterstützen, von Anforderungs-Engineering über Geschäftsprozessmanagement , Analyse und Design , Architektur , Programmier- und Implementierungstechniken bis hin zu Test- und Softwarewartungstechniken .

Die aspektorientierte Softwareentwicklung erfreut sich immer größerer Beliebtheit und ist Gegenstand einer jährlichen Konferenz, der Internationalen Konferenz zur aspektorientierten Softwareentwicklung, die 2002 erstmals in Enschede, Niederlande, stattfand. AOSD ist ein sich schnell entwickelndes Gebiet. Es ist ein beliebtes Thema der Software Engineering- Forschung, insbesondere in Europa, wo die Forschungsaktivitäten zu AOSD vom Europäischen Exzellenznetzwerk für aspektorientierte Softwareentwicklung (AOSD-Europe) koordiniert werden, das von der Europäischen Kommission finanziert wird.

Motivation

Querschnittsthemen

Abbildung 3 - Ein UML-Architekturdiagramm für eine Telekommunikationskomponente

Die Motivation für aspektorientierte Programmieransätze ergibt sich aus den Problemen, die durch Codestreuung und -verwicklung verursacht werden. Der Zweck der aspektorientierten Softwareentwicklung besteht darin, systematische Mittel zur Modularisierung von Querschnittsthemen bereitzustellen.

Die Implementierung eines Problems ist verstreut, wenn sein Code auf mehrere Module verteilt ist. Das Problem betrifft die Implementierung mehrerer Module. Die Implementierung ist nicht modular.

Die Implementierung eines Problems ist verwirrt, wenn sein Code mit Code gemischt wird, der andere Probleme implementiert. Das Modul, in dem Verwicklungen auftreten, ist nicht zusammenhängend.

Streuung und Verwicklung gehören oft zusammen, obwohl es sich um unterschiedliche Konzepte handelt.

Die aspektorientierte Softwareentwicklung ist der Ansicht, dass Streuung und Verwicklung von Code die Symptome von Querschnittsproblemen sind. Querschnittsthemen können nicht mithilfe der Zerlegungsmechanismen der Sprache (Objekt oder Prozeduren) modularisiert werden, da sie von Natur aus unterschiedlichen Zerlegungsregeln folgen. Die Implementierung und Integration dieser Bedenken in die primäre funktionale Zerlegung des Systems führt zu Codeverwirrung und -streuung.

Beispiel 1: Anmelden bei Apache Tomcat

Das Laden von Klassen in Tomcat ist ein modulares Problem in Bezug auf die Systemzerlegung. Seine Implementierung ist in einer kleinen Anzahl von Klassen enthalten und nicht mit der Implementierung anderer Anliegen verflochten.

Die Anmeldung bei Tomcat ist ein Querschnittsthema. Die Implementierung erstreckt sich über viele Klassen und Pakete und ist mit der Implementierung vieler anderer Probleme vermischt.

Beispiel 2: Koordination von Komponenten

Abbildung 3 zeigt das UML-Architekturdiagramm einer Telekommunikationskomponente. Jede Box entspricht einem Prozess, der über Konnektoren mit anderen Prozessen kommuniziert.

Beispiele für Querschnittsthemen

Siehe Querschnittsthema # Beispiele .

Probleme durch Streuung und Verwicklungen

Streuung und Verwicklung des Verhaltens sind die Symptome dafür, dass die Umsetzung eines Problems nicht gut modularisiert ist. Ein Unternehmen, das nicht modularisiert ist, weist keine genau definierte Schnittstelle auf. Die Wechselwirkungen zwischen der Implementierung des Konzerns und den Modulen des Systems werden nicht explizit deklariert. Sie werden implizit durch die Abhängigkeiten und Interaktionen zwischen Codefragmenten codiert, die das Problem und die Implementierung anderer Module implementieren.

Das Fehlen von Schnittstellen zwischen der Implementierung von Querschnittsthemen und der Implementierung der Module des Systems behindert die Entwicklung, die Entwicklung und die Wartung des Systems.

Systementwicklung

Ein Modul ist in erster Linie eine Einheit der unabhängigen Entwicklung. Es kann weitgehend unabhängig von anderen Modulen implementiert werden. Modularität wird durch die Definition klar definierter Schnittstellen zwischen Segmenten des Systems erreicht.

Das Fehlen expliziter Schnittstellen zwischen Querschnittsthemen und den Modulen, die durch die funktionale Zerlegung des Systems erhalten wurden, impliziert, dass die Implementierung dieser Bedenken sowie die Verantwortung für die korrekte Implementierung dieser Bedenken nicht unabhängigen Entwicklungsteams zugewiesen werden können. Diese Verantwortung muss auf verschiedene Entwickler aufgeteilt werden, die an der Implementierung verschiedener Module des Systems arbeiten und das Querschnittsthema in das Modulverhalten integrieren müssen.

Darüber hinaus sind Module, deren Implementierung mit Querschnittsthemen verbunden ist, in verschiedenen Kontexten schwer wiederzuverwenden. Das Querschneiden behindert die Wiederverwendung von Bauteilen. Das Fehlen von Schnittstellen zwischen Querschnittsthemen und anderen Modulen macht es schwierig, die Gesamtarchitektur eines Systems darzustellen und zu begründen. Da das Anliegen nicht modularisiert ist, sind die Interaktionen zwischen dem Anliegen und den Komponenten der obersten Ebene des Systems schwer explizit darzustellen. Daher sind diese Bedenken schwer zu begründen, da die Abhängigkeiten zwischen Querschnittsthemen und Komponenten nicht spezifiziert sind.

Schließlich sind Bedenken, die nicht modularisiert sind, nur schwer isoliert zu testen. Die Abhängigkeiten des Problems in Bezug auf das Verhalten anderer Module werden nicht explizit deklariert. Daher erfordert die Implementierung eines Komponententests für solche Probleme Kenntnisse über die Implementierung vieler Module im System.

Systemwartung und -entwicklung

Der Mangel an Unterstützung für die modulare Umsetzung von Querschnittsthemen ist besonders problematisch, wenn die Implementierung dieses Konzerns geändert werden muss. Das Verständnis der Implementierung eines Querschnittsthemas erfordert die Überprüfung der Implementierung aller Module, mit denen es interagiert. Daher erfordern Änderungen des Systems, die sich auf die Implementierung von Querschnittsproblemen auswirken, eine manuelle Überprüfung aller Stellen im Code, die für das Querschnittsproblem relevant sind. Der Systembetreuer muss eine Vielzahl von schlecht identifizierten Situationen finden und korrekt aktualisieren.

Überblick

Art der Aspektorientierung

Der Schwerpunkt der aspektorientierten Softwareentwicklung liegt auf der Untersuchung und Implementierung neuer Strukturen für die Softwaremodularität, die explizite Abstraktionen zur Modularisierung von Bedenken unterstützen. Aspektorientierte Programmieransätze bieten explizite Abstraktionen für die modulare Implementierung von Bedenken in Bezug auf Design, Code, Dokumentation oder andere Artefakte, die während des Software-Lebenszyklus entwickelt wurden. Diese modularisierten Anliegen werden als Aspekte bezeichnet , und aspektorientierte Ansätze bieten Methoden, um sie zusammenzustellen. Einige Ansätze bezeichnen ein Grundproblem als Basis. Verschiedene Ansätze bieten unterschiedliche Flexibilität hinsichtlich der Zusammensetzung von Aspekten.

Quantifizierung und Unwissenheit

Die bekannteste Definition der Natur von AOSD geht auf Filman und Friedman zurück, die AOSD unter Verwendung der Gleichung Aspektorientierung = Quantifizierung + Vergessenheit charakterisierten .

AOP kann als der Wunsch verstanden werden, quantifizierte Aussagen über das Verhalten von Programmen zu machen und diese Quantifizierungen über Programme zu halten, die von ahnungslosen Programmierern geschrieben wurden.

AOP ist der Wunsch, Aussagen der Form zu machen: Führen Sie in Programm P, wann immer Bedingung C auftritt, Aktion A über ein herkömmlich codiertes Programm P aus.

Unwissenheit bedeutet, dass ein Programm nicht weiß, welche Aspekte es wo oder wann modifizieren, während sich die Quantifizierung auf die Fähigkeit von Aspekten bezieht, mehrere Punkte im Programm zu beeinflussen.

Der Begriff der Nichtinvasivität wird häufig dem Begriff der Unwissenheit vorgezogen. Nicht-Invasivität drückt aus, dass Aspekte einem Programm Verhalten hinzufügen können, ohne dass Änderungen an diesem Programm vorgenommen werden müssen. Es wird jedoch nicht davon ausgegangen, dass Programme die Aspekte nicht kennen.

Filmans Definition der Aspektorientierung wird oft als zu restriktiv angesehen. Viele aspektorientierte Ansätze verwenden Anmerkungen , um die Stellen im System explizit zu deklarieren, an denen Aspekte Verhalten einführen. Diese Ansätze erfordern die manuelle Inspektion und Modifikation anderer Module im System und sind daher invasiv. Darüber hinaus erfordert die Aspektorientierung nicht unbedingt eine Quantifizierung. Aspekte können verwendet werden, um Features zu isolieren, deren Implementierung sich sonst mit anderen Features verwickeln würde. Solche Aspekte verwenden nicht notwendigerweise eine Quantifizierung über mehrere Stellen im System.

Die wesentlichen Merkmale von Aspect-Oriented Software Development werden deshalb besser in Bezug auf die Modularität der Umsetzung der Ablängen betrifft gekennzeichnet, die Abstraktionen von aspektorientierten Sprachen bereitgestellt Modularisierung und die Ausdruckskraft der aspektorientierten Zusammensetzung ermöglichen Betreibern .

Konzepte und Terminologie

Aspektorientierte Ansätze bieten explizite Unterstützung für die Lokalisierung von Bedenken in getrennten Modulen, die als Aspekte bezeichnet werden. Ein Aspekt ist ein Modul, das ein Anliegen zusammenfasst. Die meisten aspektorientierten Sprachen unterstützen die nicht-invasive Einführung von Verhalten in eine Codebasis und die Quantifizierung über Punkte im Programm, an denen dieses Verhalten eingeführt werden sollte. Diese Punkte werden genannt beitreten Punkte .

Verbindungspunktmodell

Verknüpfungspunkte sind Punkte in der Ausführung des Systems, z. B. Methodenaufrufe, bei denen das von Aspekten bereitgestellte Verhalten kombiniert wird. Ein Verknüpfungspunkt ist ein Punkt in der Ausführung des Programms, mit dem die dynamische Struktur eines Querschnittsthemas definiert wird.

Das Verbindungspunktmodell einer aspektorientierten Sprache definiert die Arten von Verbindungspunkten, die von der aspektorientierten Sprache unterstützt werden, und die möglichen Interaktionspunkte zwischen Aspekten und Basismodulen.

Die dynamische Interpretation von Verknüpfungspunkten ermöglicht es, Laufzeitinformationen wie den Aufrufer oder den Angerufenen einer Methode von einem Verknüpfungspunkt zu einem übereinstimmenden Punktschnitt verfügbar zu machen . Heutzutage gibt es verschiedene Join-Point-Modelle, die sich noch in der Entwicklung befinden. Sie hängen stark von der zugrunde liegenden Programmiersprache und der AO-Sprache ab.

Beispiele für Verbindungspunkte sind:

• Methodenausführung
• Methodenaufruf
• Feld Lese- und Schreibzugriff
• Ausnahmebehandlungsausführung
• statische und dynamische Initialisierung

Ein Verbindungspunkt für Methodenaufrufe deckt die Aktionen eines Objekts ab, das einen Methodenaufruf empfängt. Es enthält alle Aktionen, aus denen ein Methodenaufruf besteht, beginnend nachdem alle Argumente ausgewertet wurden, bis sie zurückgegeben werden.

Viele AOP-Ansätze implementieren das Aspektverhalten, indem sie Hooks in Verbindungspunktschatten verweben. Dies ist die statische Projektion eines Verbindungspunkts auf den Programmcode.

Abbildung 6 zeigt mögliche Verbindungspunkte bei der Ausführung eines kleinen objektorientierten Programms. Die markierten verbinden Punkte umfassen die Ausführung der Methode moveBy (int, int) auf einer Linie Objekt, die Anrufe an Methoden moveBy (int, int) auf den Punktobjekte im Rahmen des Linienobjekts, die Ausführung dieser Methoden im Kontext der Point- Objekte und der Aufrufe und Ausführung der Methoden setX (int) und setY (int) .

Pointcut-Bezeichner

Die Quantifizierung über Verbindungspunkte wird auf Sprachebene ausgedrückt. Diese Quantifizierung kann in der Sprachstruktur implizit sein oder unter Verwendung eines abfrageähnlichen Konstrukts ausgedrückt werden, das als Pointcut bezeichnet wird. Pointcuts werden als Prädikat über dem Syntaxbaum des Programms definiert und definieren eine Schnittstelle, die einschränkt, welche Elemente des Basisprogramms durch den Pointcut verfügbar gemacht werden. Ein Pointcut wählt bestimmte Verknüpfungspunkte und Werte an diesen Punkten aus. Die syntaktische Formulierung eines Punktschnitts variiert von Ansatz zu Ansatz, aber ein Punktschnitt kann häufig aus anderen Punktschnitten unter Verwendung der booleschen Operatoren AND, OR und NOT zusammengesetzt werden. Pointcut-Ausdrücke können mithilfe von Platzhaltern eine Vielzahl von Ereignissen von Interesse präzise erfassen. Beispiel: In der AspectJ- Syntax der Verschiebungspunktschnitt

pointcut move: call(public * Figure.* (..))

wählt jeden Aufruf der öffentlichen Methoden von Figure aus.

cflow-Poincuts identifizieren Verknüpfungspunkte basierend darauf, ob sie im dynamischen Kontext anderer Verknüpfungspunkte auftreten. In der AspectJ-Syntax cflow(move()) wird beispielsweise jeder Verknüpfungspunkt ausgewählt, der im dynamischen Kontext der vom Verschiebungspunktschnitt ausgewählten Verknüpfungspunkte auftritt.

Pointcuts können in zwei Kategorien eingeteilt werden:

• Sortierte Punktschnitte, wie z. B. der Aufrufpunktschnitt, stimmen mit einer Art von Verbindungspunkt mithilfe einer Signatur überein.
• Nicht sortierte Pointcuts, wie z. B. der Cflow-Pointcut, stimmen mit allen Arten von Verknüpfungspunkten mithilfe verschiedener Eigenschaften überein.

Beratungsgremien

Ein Beratungsgremium ist Code, der ausgeführt wird, wenn ein Verknüpfungspunkt erreicht wird. Beratung modularisiert die funktionalen Details eines Unternehmens. Die Reihenfolge, in der die Beratungsgremien nach Aspekten (und nach der Basis) beigetragen haben, kann auf verschiedene Weise gesteuert werden, einschließlich:

• Wenn ein Verbindungspunkt erreicht ist, wird die Ausführung mit der Basis fortgesetzt
• nach der Basissemantik für den Join-Punkt. Wenn der Verknüpfungspunkt der Ausführung einer Methode entspricht, kann nach der Rückgabe der Methode oder nach dem Auslösen einer Ausnahme ein After-Hinweis ausgeführt werden
• Wenn der Verknüpfungspunkt erreicht ist, können Sie explizit steuern, ob die Basissemantik ausgeführt wird. Rund um Ratschläge kann der Kontrollfluss des Programms geändert werden.

Es wurden auch allgemeinere Möglichkeiten zur Beschreibung der Reihenfolge von Beratungsgremien in Form von Teilordnungsgraphen bereitgestellt.

Wenn die Ausführung eines Verknüpfungspunkts einen Punktschnittausdruck erfüllt, werden der dem Verknüpfungspunkt zugeordnete Basis- und Hinweiscode ausgeführt. Der Hinweis kann mit dem Restsystem über eine Join-Point-Instanz interagieren, die reflektierende Informationen zum Kontext des Ereignisses enthält, das den Hinweis ausgelöst hat, z. B. die Argumente eines Methodenaufrufs oder die Zielinstanz eines Aufrufs.

Typübergreifende Deklarationen

Mithilfe von Typdeklarationen kann der Programmierer die statische Struktur eines Programms ändern, z. B. Klassenmitglieder und Klassenhierarchie. Neue Mitglieder können eingefügt und Klassen in der Klassenhierarchie nach unten verschoben werden.

Aspekte

Ein Aspekt ist ein Modul, das ein Anliegen zusammenfasst. Ein Aspekt besteht aus Pointcuts, Beratungsgremien und typübergreifenden Erklärungen. In einigen Ansätzen kann ein Aspekt auch Klassen und Methoden enthalten.

Aspektweben

Das Aspektweben ist ein Kompositionsmechanismus, der Aspekte mit den anderen Modulen des Systems koordiniert. Es wird von einem spezialisierten Compiler ausgeführt, der als Aspektweber bezeichnet wird .

Beispiel

Abbildung 6 - Abbildung Editor in UML

Abbildung 7 - Aspektorientierter Figureneditor in UML

Abbildung 6 zeigt ein klassisches Beispiel für ein Querschnittsthema in einem Beispiel für einen Bildeditor aus der AOSD-Literatur. Das Beispiel beschreibt eine abstrakte Formklasse, die im Editor verschoben werden kann. Immer wenn eine Form verschoben wird, muss die Anzeige aktualisiert werden. Abbildung 6 zeigt auch zwei Shape-Unterklassen, Line und Point, die die Shape-Funktionalität implementieren. Das Problem der Anzeigeaktualisierung ist auf die Implementierung beider Unterklassen verteilt. Fig. 7 zeigt eine aspektorientierte Implementierung desselben Systems, wobei ein Aspekt die Aktualisierungsfunktionalität der Anzeige kapselt.

Der Verschiebungspunktschnitt-Deskriptor von 7 erfasst alle Ausführungen der moveBy-Methoden einer Unterklasse von Shape und ruft die Anzeigeaktualisierungsfunktion auf, nachdem die Ausführung fortgesetzt wurde. Das Unternehmen ist modularisiert, was die Entwicklung und Wartung erleichtert.

Aspektorientiertes Requirement Engineering

Das aspektorientierte Anforderungs-Engineering (auch als "frühe Aspekte" bezeichnet) konzentriert sich auf die Identifizierung, Spezifikation und Darstellung von Querschnittseigenschaften auf Anforderungsebene . Beispiele für solche Eigenschaften sind Sicherheit , Mobilität, Verfügbarkeit und Echtzeitbeschränkungen . Querschnittseigenschaften sind Anforderungen, Anwendungsfälle oder Funktionen, die einen weitreichenden Einfluss auf andere Anforderungen oder Architekturkomponenten haben .

Aspektorientierte Anforderungs-Engineering-Ansätze sind Techniken, die ausdrücklich erkennen, wie wichtig es ist, sowohl funktionale als auch nicht funktionale Querschnittsthemen zusätzlich zu nicht-Querschnittsthemen klar anzugehen. Daher konzentrieren sich diese Ansätze auf die systematische und modulare Behandlung, Überlegung, Zusammenstellung und anschließende Verfolgung von übergreifenden funktionalen und nicht funktionalen Belangen über geeignete Abstraktions- , Darstellungs- und Zusammensetzungsmechanismen, die auf den Bereich des Requirements Engineering zugeschnitten sind.

Spezifische Kompetenzbereiche unter dem Nenner der AO-Anforderungsanalyse sind:

• der aspektorientierte Anforderungsprozess selbst,
• die aspektorientierten Anforderungsnotationen,
• Unterstützung von aspektorientierten Anforderungswerkzeugen,
• Übernahme und Integration von aspektorientiertem Requirements Engineering und
• Bewertung / Bewertung von aspektorientierten Anforderungen.

Aspektorientiertes Geschäftsprozessmanagement (AOBPM)

Die Reduzierung der Komplexität ist ein wichtiges Thema im Bereich Business Process Management (BPM). Eine Quelle der Komplexität liegt in der Vielzahl von Bedenken, mit denen sich ein Geschäftsprozess befasst, wie z. B. Sicherheit und Datenschutz. Im Idealfall sollten diese Bedenken getrennt von den Geschäftsprozessen definiert werden, da sie sich normalerweise über mehrere Prozesse erstrecken und auf allgemeiner Organisationsebene anstelle einer bestimmten Prozessebene geändert werden können. Aktuelle Geschäftsprozessmanagementsysteme unterstützen diese Art der Modellierung jedoch nicht.

Das aspektorientierte Geschäftsprozessmanagement (AOBPM) versucht, die Trennung von Querschnittsthemen von den Kerngeschäftsthemen zu unterstützen. Es definiert eine Reihe von Anforderungen und ein formales Modell. Dieses Modell wurde mit farbigen Petri-Netzen (CPN) entwickelt.

Der Ansatz wird als Service in YAWL implementiert, der auf einer serviceorientierten Architektur basiert .

Das Bewertungsergebnis aktueller aspektorientierter Geschäftsprozessmanagement-Ansätze wird anhand von fünf Dimensionen definiert, z. B. Signatur-Exposure, Regelzusammensetzung, Beratungsbeziehungen, Transformationsmuster und Phasenunterstützung. Das Ergebnis ist in der folgenden Abbildung dargestellt.

Aspektorientierte Systemarchitektur

Die aspektorientierte Systemarchitektur konzentriert sich auf die Lokalisierung und Spezifikation von Querschnittsthemen in Architekturentwürfen. Querschnittsthemen, die auf architektonischer Ebene auftreten, können nicht modularisiert werden, indem die Softwarearchitektur mithilfe herkömmlicher Architekturabstraktionen neu definiert wird. Aspektorientierte Systemarchitektursprachen schlagen explizite Mechanismen vor, um Aspekte auf der Ebene des Architekturdesigns zu identifizieren, zu spezifizieren und zu bewerten.

Aspektorientierte Architektur geht von der Beobachtung aus, dass wir Aspekte explizit auf der Ebene des Architekturdesigns identifizieren, spezifizieren und bewerten müssen. Aspekte der Architektur beschreiben Ansätze zur Identifizierung architektonischer Aspekte. Diese Informationen werden verwendet, um eine bestimmte Architektur neu zu gestalten, in der die architektonischen Aspekte explizit dargestellt werden. In dieser Hinsicht sind spezifische Exzellenzbereiche:

• der aspektorientierte Architekturprozess selbst,
• die aspektorientierten Architekturnotationen,
• Unterstützung von aspektorientierten Architekturwerkzeugen,
• Übernahme und Integration von aspektorientierter Architektur und
• Bewertung / Bewertung der aspektorientierten Architektur.

Aspektorientierte Modellierung und Gestaltung

Aspektorientiertes Design verfolgt dieselben Ziele wie jede Software-Design-Aktivität, dh das Charakterisieren und Spezifizieren des Verhaltens und der Struktur des Softwaresystems. Sein einzigartiger Beitrag zum Software-Design liegt in der Tatsache, dass Bedenken, die in traditionelleren Ansätzen notwendigerweise verstreut und verwickelt sind, modularisiert werden können. Typischerweise umfasst ein solcher Ansatz sowohl einen Prozess als auch eine Sprache. Der Prozess nimmt als Eingabeanforderungen und erstellt ein Entwurfsmodell. Das produzierte Designmodell repräsentiert separate Anliegen und deren Beziehungen. Die Sprache bietet Konstrukte, die die im Entwurf darzustellenden Elemente und die Beziehungen beschreiben können, die zwischen diesen Elementen bestehen können. Insbesondere werden Konstrukte bereitgestellt, um die Modularisierung von Anliegen und die Spezifikation der Zusammensetzung von Anliegen unter Berücksichtigung von Konflikten zu unterstützen. Darüber hinaus ist das Design jedes einzelnen modularisierten Unternehmens mit dem Standard-Software-Design vergleichbar.

Hier sind bestimmte Bereiche der Exzellenzbereiche:

• der aspektorientierte Designprozess selbst,
• die aspektorientierten Designnotationen,
• aspektorientierte Unterstützung von Designwerkzeugen,
• Übernahme und Integration von aspektorientiertem Design und
• Bewertung / Bewertung von aspektorientiertem Design.

Aspektorientierte Programmierung (AOP)

AOP umfasst Programmiertechniken und Tools, die die Modularisierung von Bedenken auf der Ebene des Quellcodes unterstützen.

Wie jede andere Programmiersprache besteht eine aspektorientierte Sprache normalerweise aus zwei Teilen: einer Sprachspezifikation und einer Implementierung. Daher gibt es zwei entsprechende Problembereiche: Unterstützung für Sprachentwickler und Unterstützung für Anwendungsentwickler.

Unterstützung für Anwendungsentwickler

Ein aspektorientierter Ansatz unterstützt die Umsetzung von Bedenken und die Zusammenstellung dieser unabhängig umgesetzten Bedenken. Während die Spezifikation einer solchen Sprache das primäre Handbuch für Anwendungsentwickler ist, bietet sie offensichtlich keine Garantie dafür, dass der Anwendungsentwickler qualitativ hochwertige aspektorientierte Programme erstellt. Spezifische Exzellenzbereiche:

• die entscheidenden Konzepte der aspektorientierten Programmierung,
• Programmierung in aspektorientierten Sprachen,
• Erstellen von Softwarekomponenten, die in einer beliebigen Sprache unter Verwendung von aspektorientierten Kompositionsmechanismen geschrieben wurden, oder
• aspektorientierte Programmierumgebungen.

Unterstützung für Sprachentwickler

Die Exzellenz beim Aufbau aspektorientierter Sprachen umfasst folgende Bereiche:

• Erstellen von Sprachen oder DSLs für bestimmte Domänen und / oder Plattformen und
• Übertragen von Implementierungsprinzipien aus anderen aspektorientierten Ausführungsumgebungen, einschließlich:
  • Dolmetscher,
  • Compiler und
  • virtuelle Maschinen.

Formale Methodenunterstützung zur Aspektorientierung

Formale Methoden können sowohl zur semantischen Definition von Aspekten als auch zur Analyse und Verifizierung von aspektorientierten Systemen verwendet werden. Die aspektorientierte Programmierung erweitert die Programmiernotationen um Aspektmodule, die die Erklärung isolieren, wann der Aspekt angewendet werden soll (Verbindungspunkte) und welche Maßnahmen ergriffen werden sollen, wenn er erreicht ist (Beratung). Das Fachwissen über formale semantische Definitionen von Aspektkonstrukten ist für Sprachdesigner hilfreich , um ein tiefes Verständnis der Unterschiede zwischen Konstrukten zu vermitteln. Aspekte können möglicherweise die Zuverlässigkeit eines Systems beeinträchtigen, mit dem sie verwoben sind, und wesentliche Eigenschaften ungültig machen, die für das System ohne diesen Aspekt bereits zutrafen. Es muss auch gezeigt werden, dass sie dem System tatsächlich beabsichtigte Querschnittseigenschaften hinzufügen. Daher werden zahlreiche Aspekte der Korrektheit und Überprüfung durch Aspektsprachen aufgeworfen. Zu den Arten von Fachwissen gehören:

• speziell entwickelte Testtechniken zur Abdeckung von Aspekten,
• Programm-Slicing- und Code-Analyse- Ansätze zur Identifizierung von Interaktionen zwischen Aspekten und zwischen Aspekten und zugrunde liegenden Systemen;
• auf Aspekte spezialisierte Modellprüfungstechniken und
• induktive Techniken zur Überprüfung aspektorientierter Systeme.

Jeder der oben genannten Ansätze kann verwendet werden, um:

• einzelne Aspekte in Bezug auf ein bestehendes System spezifizieren und analysieren,
• Bedingungen für die korrekte Zusammenstellung mehrerer Aspekte definieren und
• Erkennen und Beheben potenzieller Interferenzen zwischen Aspekten.

Obwohl einige Ansätze bereits in Aspektsprachen verwendet werden, sind andere noch Gegenstand der Forschung und nicht für die routinemäßige industrielle Anwendung bereit. Dennoch ist das Bewusstsein für diese Themen für Sprachdesigner und für die effektive Nutzung von Aspekten, insbesondere in sicherheitskritischen Kontexten , von wesentlicher Bedeutung .

Aspektorientierte Middleware

Middleware und AOSD ergänzen sich stark. Exzellenzbereiche bestehen im Allgemeinen aus:

• Unterstützung für den Anwendungsentwickler, einschließlich
  • die entscheidenden Konzepte des Aspekts, der Middleware unterstützt,
  • Aspektorientierte Softwareentwicklung unter Verwendung einer bestimmten Middleware, die das Aspektprogrammierungsmodell, das Aspektbereitstellungsmodell, die Plattforminfrastruktur und die Dienste der Middleware umfasst, und
• Product Family Engineering (Methoden, Architekturen, Techniken) im verteilten und Ambient Computing und
• Unterstützung für den Middleware-Entwickler in Bezug auf
  • Host-Infrastruktur-Middleware,
  • Distributions-Middleware,
  • gemeinsame Middleware-Dienste und
  • domänenspezifische Middleware-Dienste.

Annahme

• IBM WebSphere Application Server (WAS) ist ein Java-Anwendungsserver, der Java EE und Web Services unterstützt. Websphere wird nach Editionen verteilt, die verschiedene Funktionen unterstützen. Websphere verwendet AspectJ intern, um Funktionen der verschiedenen Editionen zu isolieren.
• JBoss Application Server (JBoss AS) ist ein kostenloser Open-Source-Java-Anwendungsserver, der Java EE unterstützt. Der Kern von JBoss AS ist in die aspektorientierte Programmiersprache JBoss AOP integriert. Der Anwendungsserver verwendet JBoss AOP, um Dienste wie Sicherheit und Transaktionsverwaltung bereitzustellen.
• Oracle TopLink ist ein Java-Framework für die Objekt-zu-Relational-Persistenz, das in den Spring Application Server integriert ist. TopLink erreicht mit Spring AOP ein hohes Maß an Persistenztransparenz.
• SAFT
• Sun Microsystems verwendet AspectJ , um die Entwicklung mobiler Anwendungen für die Java ME-Plattform zu optimieren. Aspekte werden verwendet, um die Entwicklung mobiler Anwendungen für die Bereitstellung auf verschiedenen Operator-Decks und verschiedenen Benutzeroberflächen für mobile Spiele zu vereinfachen.
• Siemens Soarian ist ein Gesundheitsinformationsmanagementsystem, das den nahtlosen Zugriff auf Patientenakten und die Definition von Workflows für Organisationen von Gesundheitsdienstleistern unterstützt. Soarian verwendet AspectJ, um Querschnittsfunktionen wie Nachverfolgung, Prüfung und Leistungsüberwachung im Kontext eines agilen Entwicklungsprozesses zu integrieren.
• Motorola wi4 ist ein zellulares Infrastruktursystem, das den drahtlosen WiMAX-Breitbandstandard unterstützt. Die wi4-Steuerungssoftware wurde unter Verwendung einer aspektorientierten Erweiterung des UML 2.0-Standards namens WEAVR entwickelt. WEAVR wird während der Entwicklung zu Debugging- und Testzwecken verwendet.
• ASML ist ein Anbieter von Lithografiesystemen für die Halbleiterindustrie. ASML verwendet eine aspektorientierte Erweiterung von C namens Mirjam, um die Probleme bei der Ablaufverfolgung und Profilerstellung zu modularisieren.
• Glassbox ist ein Fehlerbehebungsagent für Java-Anwendungen, der häufig auftretende Probleme automatisch diagnostiziert. Der Glassbox-Inspektor überwacht die Aktivität der virtuellen Java-Maschine mithilfe von AspectJ.
• .NET 3.5 unterstützt aspektorientierte Konzepte über den Unity-Container.

Fußnoten

Verweise

• Kiczales, G . ; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, JM; Irwin, J. (1997). Aspektorientierte Programmierung (PDF) . ECOOP '97. Vorträge der 11. Europäischen Konferenz über objektorientierte Programmierung . LNCS . 1241 . S. 220–242. CiteSeerX   10.1.1.115.8660 . doi : 10.1007 / BFb0053381 . ISBN   3-540-63089-9 .
• Murphy, GC, RJ Walker, ELA Baniassad, MP Robillard, A. Lai, MA Kersten (2001): Funktioniert aspektorientierte Programmierung? 44, Nr. 10, 75-77
• Tarr, P., H. Ossher, W. Harrison, SM Sutton Jr. (1999): N Trennungsgrade: Mehrdimensionale Trennung von Bedenken, in: Proceedings of the 21st International Conference on Software Engineering (ICSE 1999), Los Angeles, Kalifornien, USA, IEEE Computer Society Press, 107-119
• Wijesuriya, Viraj Brian (30.08.2016) Aspektorientierte Entwicklung, Vorlesungsunterlagen, School of Computing der Universität Colombo, Sri Lanka

Externe Links

• Aspektorientierte Softwareentwicklungsgemeinschaft und Konferenz