Beschreibung von Softwarearchitekturen...Möglichkeiten einer Strukturierung eines Softwaresystems, (4)Klassifikation von Szenarien in direkte und indirekte Szenarien, (5)Evaluierung

© 2005, W. Pree 45

Beschreibung vonSoftwarearchitekturen

© 2005, W. Pree 46

Definition Softwarearchitektur

Die Menge aller Komponenten (Module) einesSoftwaresystems zusammen mit ihrenWechselwirkungen.

© 2005, W. Pree 47

Architekturmuster

Das Software Engineering Institute (SEI) an derCarnegie-Mellon-University in Pittsburgh,Pennsylvania, hat in den 1990er-Jahren maßgeblichzur Etablierung von Architekturmustern für dieBeschreibung von Softwarearchitekturen beigetragen.

ursprünglich wurde vom SEI eine eigene Notationdafür vorgeschlagen; seit 2003 wird vom SEI auch dieUML dafür verwendet

© 2005, W. Pree 48

Beispiele für exzellent beschriebeneSoftwarearchitekturen

Project Oberon—The Design of an Operating Systemand Compiler von Wirth und Reiser (Addison-Wesley1992)Darin wird die informelle Beschreibung durchschematische Darstellungen, Screen-Shots, undQuelltext ergänzt.

die Entwurfsmuster von Gamma et al. (Addison-Wesley 1995)

© 2005, W. Pree 49

SEI-Architekturmuster im Überblick

Architekturmuster Ausprägungen

Datenzentrierung Repository-Architektur Blackboard-Architektur

Datenflussorientierung Batch/Sequential-Architektur Pipes&Filters-Architektur

Call & Return Top-Down-Architektur Netzwerk-Architektur (Objektorientierung) Schichten-Architektur (layered)

Virtuelle Maschine Interpreter-Architektur Regelbasierte Architektur

Unabhängige Komponenten Ereignisgesteuerte Architektur

© 2005, W. Pree 50

Datenzentrierung (I)

In einer Repository-Architektur sind die Daten passiv. Eine Blackboard-Architektur hat quasi aktive Daten,

die die an Änderungen interessierten Klientenentsprechend informieren. Das Blackboard-Architekturmuster ist ähnlich dem Observer-Entwurfsmuster (Gamma et al., 1995).

© 2005, W. Pree 51

Datenzentrierung (II)

Vorteil: Klienten sind voneinander unabhängig.

Dadurch können Klienten geändert werden, ohnedass andere davon betroffen sind. Es könnenselbstverständlich auch weitere Klienten hinzugefügtwerden.

Der Vorteil der Unabhängigkeit schwindet, wenn dieArchitektur so geändert wird, dass Klienten enggekoppelt werden (also vom empfohlenenArchitekturmuster abgewichen wird), um zum Beispieldie Performanz des Systems zu verbessern.

© 2005, W. Pree 52

Datenflussorientierung – Batch/Sequential

Das Muster beschreibt eine Abfolge von Transformationen vonEingabedaten.

Datenflussorientierte Architekturteile zeichnen sich besondersdurch Wiederverwendbarkeit und Modifizierbarkeit aus.

Bei der Batch/Sequential-Ausprägung des Architekturmustersmuss jeder Transformationsvorgang beendet sein, bevor dernächste beginnt.

© 2005, W. Pree 53

Datenflussorientierung – Pipes&Filters

Bei der Architekturmusterausprägung Pipes&Filters werden dieDaten nicht sequenziell en bloc sondern inkrementelltransformiert. Das heißt, dass die Daten in kleinere Einheitenzerlegt werden und diese Einheiten von den Prozessenverarbeitet werden.

Pipes sind zustandslos und transportieren die Daten von Filterzu Filter und zwar so, dass jeder Filter (autonom) bestimmt,wann er vom vorgelagerten Filter das nächste Element des(Eingabe-) Datenstroms benötigt.

In der UML-Darstellung ist der Unterschied zwischenPipes&Filters und Batch/Sequential nicht ersichtlich.

© 2005, W. Pree 54

Datenflussorientierung: Vor- und Nachteile

Der Vorteil der Datenflussorientierung liegt darin, dass es keinekomplexen Interaktionen zwischen Komponenten gibt. DieVerarbeitungsprozesse sind Black-Boxes.

Das datenflussorientierte Architekturmuster ist ungeeignet fürdie Modellierung interaktiver Anwendungen.

Ein weiterer Nachteil ist die häufig ungenügende Performanzund Effizienz. Wenn Filter als Kontext den gesamtenEingabestrom benötigen, müssen entsprechende Pufferverwendet werden. Das wirkt sich negativ auf dieSpeichereffizienz aus.

Das Datenfluss-Muster eignet sich gut als Grundlage für visuell-interaktive Komposition: Es wird beispielsweise bei derModellierung von Regelungssystemen im Werkzeug Simulink(www.MathWorks.com) eingesetzt.

© 2005, W. Pree 55

Call & Return (I)

Damit wird der für imperative Programmierungtypische Kontrollfluss beschrieben: Prozeduren,Funktionen und Methoden eines Moduls werden ausanderen Modulen aufgerufen und nach ihrerAusführung wird hinter die Aufrufstellezurückgesprungen.

Top-Down Ausprägung des Call&Return-Architekturmusters: Bei konventionellen, nichtobjektorientierten Implementierungen, führt das zueiner top-down-orientierten Architektur, das heißt eine(Haupt- oder Wurzel-)Prozedur/Funktion/Methode ruftweitere Prozeduren/Funktionen/Methoden auf, etc.

© 2005, W. Pree 56

Call & Return (II)

Netzwerk beziehungsweise objektorientierteAusprägung des Call&Return-Architekturmusters:Die Konstrukte, die objektorientierte Sprachenbereitstellen, erlauben neben der hierarchischenStrukturierung von top-down-orientiertenArchitekturen auch die Bildung vonnetzwerkorientierten Architekturen. DieMethodenaufrufe erfolgen in einem Netzwerk vonObjekten.

© 2005, W. Pree 57

Call & Return (III)

Eine weitere Ausprägung des Call&Return-Architekturmusters,die sogenannte Schichtenarchitektur (Layers), wirdverwendet, um Abstraktionen einzuführen.

Eine Schicht entspricht einem Modul, der eine Menge weitererModule enthalten kann und der eine bestimmte Funktionalitätanbietet. Mit Ausnahme der untersten Schicht, beruht jedeSchicht jeweils auf der Schnittstelle der darunter liegendenSchicht. Das heißt, es soll vermieden werden, dass von einerSchicht aus Aufrufe erfolgen, die Module betreffen, die sich nichtin der unmittelbar darunter liegenden Schicht befinden.Ansonsten ist die Austauschbarkeit der Schichten nicht mehrgegeben.

© 2005, W. Pree 58

Beispiel: Schichtenarchitektur von AUTOSAR(Automotive Open Systems Architecture)

weitere Informationen auf www.autosar.org

© 2005, W. Pree 59

Virtuelle Maschine (I)

Eine virtuelle Maschine dient dazu, Funktionalität, die zurAusführung einer Applikation benötigt wird, aber die durch diebenutzte Hardware und/oder Systemsoftware einer bestimmtenPlattform, auf der die Applikation ausgeführt werden soll, nichtzur Verfügung gestellt wird, bereitzustellen.

Mit diesem Architekturmuster wird die Portierbarkeit verbessert.

© 2005, W. Pree 60

Virtuelle Maschine (II)

Interpreter-Architektur: Das Konzept der virtuellen Maschinewird seit der Einführung von Java verstärkt unddementsprechend verbreitet eingesetzt. Dass mit einer virtuellenMaschine die Portierbarkeit von Software deutlich verbessertwerden kann, wurde bereits anfangs der 1970er Jahre durch dieDefinition des P-Codes (Pascal-Code) gezeigt. Dadurch wurdenPascal-Compiler, die P-Code statt Maschinencode erzeugten,portierbar. Für eine bestimmte Hardwareplattform musste jeweilseine virtuelle Maschine, die den P-Code interpretiert,bereitgestellt werden

Regelbasierte Architektur: Expertensysteme, bei denenRegeln interpretiert werden.

© 2005, W. Pree 61

Unabhängige Komponenten (I)

Dieses Architekturmuster postuliert lose miteinander gekoppelte,voneinander unabhängige Komponenten. Komponentenbezeichnen wir als voneinander unabhängig, wenn dieKomponenten die Funktionen/Prozeduren/Methoden von anderenKomponenten nicht direkt aufrufen.

Eine übliche Form, unabhängige Komponenten lose zu verbinden,sind sogenannte ereignisorientierte Verknüpfungen: EineKomponente registriert sich bei einer anderen Komponente, vonder sie über Änderungen informiert werden will. Bei Änderungen,also wenn ein Ereignis eingetreten ist, informiert die Komponentealle Komponenten, die sich bei ihr registriert haben. Die Kopplungist lose, weil die Komponente lediglich eine Änderung bekannt gibt,nicht aber festlegt, was die anderen Komponenten zu tun haben.Diese können darauf reagieren, oder nicht.

© 2005, W. Pree 62

Unabhängige Komponenten (II)

Die Video-Clip-Komponente muss sich bei der Schaltflächeregistriert haben, dass sie über das Eintreten von Ereignisseninformiert wird. Beim Aktivieren der Schaltfläche wird die Video-Clip-Komponente durch die Nachricht, dass das Ereignises„gedrückt“ eingetreten ist, von der Schaltflächenkomponenteinformiert. Die Video-Clip-Komponente kann nun darauf reagieren,indem der mit der Komponente assoziierte Video-Clip abgespieltwird.

© 2005, W. Pree 63

Die Software-Architektur-Analyse-Methode (SAAM)

© 2005, W. Pree 64

Wozu Architekturanalyse?

Wenn ein Softwaresystem neu entwickelt wird, soll die Analyseverschiedener Architekturoptionen (auch Architekturkandidatengenannt) erlauben, die Erfüllung beziehungsweise Nichterfüllungvon Qualitätsattributen einzuschätzen. VerschiedeneArchitekturkandidaten sollten in der Entwurfsphase evaluiert undauf Basis von verlässlichen Urteilen akzeptiert oderzurückgewiesen werden.

Eine Architekturanalyse ist außerdem sinnvoll, wenn einSoftwaresystem gekauft oder übernommen werden soll. Nurdurch eine ausreichende Architekturanalyse ist es möglich, dieProduktqualität, insbesondere im Hinblick auf die Wartbarkeit,Änderbarkeit und Erweiterbarkeit unter den gegebenenRahmenbedingungen, einzuschätzen.

© 2005, W. Pree 65

Auswahl relevanter Kriterien in SAAM (I)

Betrachten wir als Beispiel das QualitätsmerkmalÄnderbarkeit. Ein Softwaresystem ist bezogen aufbestimmte Aspekte (zum Beispiel beim Aussehen undbei der Konfiguration der Benutzungsschnittstelle)leicht änderbar, hingegen in anderen Bereichen (zumBeispiel bei den unterstützten Datenformaten beiKonversionen) schwer änderbar.

Die Qualitätsanforderungen bezogen auf einbestimmtes Qualitätsmerkmal müssen daherkontextbezogen definiert werden.

© 2005, W. Pree 66

Auswahl relevanter Kriterien in SAAM (II)

SAAM führt dazu Szenarien ein. Ein Szenario würdebeispielsweise beschreiben, dass ein Benutzer derSoftware die Menus konfigurieren können soll. Der imSzenario erwähnte Benutzer ist ein Beispiel für einenBeteiligten (Stakeholder in der SAAM-Terminologie),also einer Person, die einen Bezug zumSoftwaresystem hat. Ein Szenario beschreibtstichwortartig die Interaktion eines Beteiligten mit demSoftwaresystem.

Für die Bewertung einer Softwarearchitektur müssenzuerst die Voraussetzungen durch die Beschreibungvon Szenarien geschaffen werden, dass einezielgerichtete Analyse vorgenommen werden kann.

© 2005, W. Pree 67

SAAM im Überblick(1) Identifikation und Zusammenstellung der Beteiligten

(Stakeholders)(2) Beschreibung und Reihung von Szenarien (Benutzungs-Szenarien,

Änderungs- und Erweiterungs-Szenarien, etc.) nach Wichtigkeit,(3) Beschreibung von Architekturkandidaten, also von verschiedenen

Möglichkeiten einer Strukturierung eines Softwaresystems,(4) Klassifikation von Szenarien in direkte und indirekte Szenarien,(5) Evaluierung der indirekten Szenarien durch Analyse der Architektur,

um eine Beurteilung der Kopplung der Komponenten derSoftwarearchitektur vornehmen zu können,

(6) Evaluierung der Interaktionen zwischen den indirekten Szenariendurch Analyse der Architektur, um eine Beurteilung der Kohäsionder Komponenten der Softwarearchitektur vornehmen zu können,und

(7) zusammenfassende Beurteilung

© 2005, W. Pree 68

SAAM – mögliche Stakeholders (I)

Modularisierung (Kopplung, Kohäsion)DokumentationSystemtransparenz/Lesbarkeit(z.B. Aufwand für das Auffinden der Stellen, andenen Systemänderungen/-verbesserungenvorgenommen werden müssen)

Entwickler (developer,maintainer, integrator,application builder)

FunktionalitätBenutzbarkeitRobustheit

Benutzer

Zeitplan und BudgetNutzen des SystemsGrad der Erwartungserfüllung

Kunde

InteressensschwerpunkteStakeholder

© 2005, W. Pree 69

SAAM – mögliche Stakeholders (II)

Interoperabilität zu anderen SystemenRepräsentant desAnwendungsgebietes

Modularisierung (Kopplung, Kohäsion)(konsistente) FehlerbehandlungDokumentationSystemtrasparenz/Lesbarkeit

Tester

NetzwerkdurchsatzVorhersagbarkeit des Durchsatzes

Netzwerkadministrator

Problemursachenidentifikation(z.B. das schnelle Auffinden vonUrsachen für Probleme beim Betriebder Software)

Systemadministrator

© 2005, W. Pree 70

Beschreibung und Reihung von Szenariennach Wichtigkeit

Die Szenarien werden von den Beteiligtenvorgeschlagen und müssen repräsentativ für künftigeAnforderungen, Änderungen und Erweiterungen sein.

Die Szenarien zusammengenommen sollen allerelevanten Benutzungsaspekte des Systemsbeschreiben und sich insbesondere aufFunktionalitätsaspekte, sowie Entwicklungs- undÄnderungsaktivitäten beziehen.

ca. 10 – 20 Szenarien am Ende: Reihung nach Wichtigkeit

© 2005, W. Pree 71

Beschreibung der Architekturkandidaten

In der Praxis hat sich gezeigt, dass eine einfache Beschreibungder Datenverbindungen (welche Komponenten tauschen welcheInformationen mit wem aus) und der Steuerungsverbindungen(welche Komponenten veranlassen welche Komponenten – ihrerSpezifikation gemäß – aktiv zu werden) für eine statischeDarstellung der Architektur meist ausreicht.

Als Ergänzung zur statischen Beschreibung wird zum Beispieldurch UML-Interaktionsdiagramme oder durch natürlicheSprache skizziert, wie sich das System zur Laufzeit verhaltensoll.

Für Szenarien, die Änderungen betreffen, ist eventuell dieBetrachtung von Quelltext-Fragmenten nötig.

© 2005, W. Pree 72

Klassifikation der Szenarien in direkte undindirekte Szenarien

Direkte Szenarien können aufgrund des aktuellenEntwicklungsstandes unmittelbar umgesetzt werden.

Indirekte Szenarien erfordern Änderungen desSystems, die sich auf die Architektur auswirken.Für indirekte Szenarien ist auch der geschätzteAufwand für die erforderliche Änderung anzugeben(in Personen-Tagen/-Monaten oder -Jahren).

Bei der SAAM werden in den folgenden Schritten nurdie indirekten Szenarien weiter betrachtet. Einindirektes Szenario kann durch die notwendigeArchitekturänderung eine oder mehrereKomponenten betreffen.

© 2005, W. Pree 73

Evaluierung der indirekten Szenarien

Das Ergebnis dieses Schrittes ist die Feststellung derAnzahl der von Änderungen betroffenenKomponenten für jedes indirekte Szenario.

Das ist das Maß für die Kopplung der Komponentender Softwarearchitektur.

© 2005, W. Pree 74

Evaluierung der Interaktionen zwischen denindirekten Szenarien

In SAAM-Terminologie interagieren zwei indirekteSzenarien, wenn sie eine Änderung derselbenKomponente erfordern.

Die Analyse der Interaktion von Szenarien zeigt auf,welche Komponenten mehrere Aspekte abdeckenund somit eine geringe Kohäsion aufweisen. EineInteraktion von einander ähnlichen Szenarien ist einIndikator für eine hohe Kohäsion.

© 2005, W. Pree 75

Zusammenfassende Bewertung

Der abschliessende Schritt dient insbesondere dazu,die verschiedenen Architekturkandidaten miteinanderzu vergleichen, um eine Reihung derArchitekturkandidaten vornehmen zu können. Dafürsollen jene Szenarien ausgewählt werden, die vonentscheidender Bedeutung für den Einsatz desSystems sind.

Das Verständnis der Architekturkandidaten aufgrundder vorhergehenden Evaluierungen bildet die Basisfür die zusammenfassende Bewertung, diequantitative und qualitative Aspekte berücksichtigensoll.

© 2005, W. Pree 76

Abfolge der SAAM-Schritte

© 2005, W. Pree 77

Beispielanwendung der SAAM

© 2005, W. Pree 78

Revision Control System WRCS (I)

Ein Projekt in WRCS ist eine Gruppe verwandterDateien, die zusammen ein Produkt ergeben, wennsie entsprechend verbunden werden:

Quelltext-Dateien sein, die zu einem lauffähigenProgramm übersetzt werden,

Text-Dokumente eines Buches oder digitalisierte Audio- und Video-Daten für einen

Werbespot, etc.

© 2005, W. Pree 79

Revision Control System WRCS (II)

Mit WRCS können die Änderungen von Dateien verfolgt werden Archive definiert werden, Dateien ein- und ausgecheckt werden, Releases erzeugt werden, und alte Versionen wiederhergestellt werden.

Das WRCS wurde mit verschiedenen Entwicklungs-umgebungen integriert. Die verfügbaren Funktionenkönnen von der jeweiligen Entwicklungsumgebungaus oder über die grafische Benutzungsschnittstellevon WRCS ausgeführt werden.

© 2005, W. Pree 80

WR

CS

-Kom

pone

nten

und

der

en In

tera

ktio

nen

© 2005, W. Pree 81

WRCS-Architekturmuster

Call & Return-Architektur keine Schichten

© 2005, W. Pree 82

Szenarien und deren Wichtigkeit

Stakeholder Szenario Wichtigkeit

Endbenutzer Vergleich von Binärdateien 1 Konfiguration des Toolbars 3 Entwickler (Maintainer)

Anpassungen der grafischen Benutzungsschnittstelle

6

Portierung auf ein anderes Betriebssystem

4

Administrator Änderung der Zugriffsrechte für ein Projekt

5

Integration in eine neue Entwicklungsumgebung

2

© 2005, W. Pree 83

Klassifikation in direkte undindirekte Szenarien

Stakeholder Szenario Klassifikation

Endbenutzer Vergleich von Binärdateien indirekt Konfiguration des Toolbars direkt Entwickler (Maintainer)


indirekt


indirekt

Administrator Änderung der Zugriffsrechte für ein Projekt

direkt


indirekt

© 2005, W. Pree 84

Anzahl der Komponenten, die durch einindirektes Szenario geändert werden müssen

indirektes Szenario Anzahl der zu ändernden

Komponenten

Vergleich von Binärdateien 2


3


3+


4

© 2005, W. Pree 85

Evaluierung der Interaktionen zwischen denindirekten Szenarien

Modul Anzahl der erforderlichen Änderungen

main 4

wrcs 7

diff 1

bindiff 1

pvcs2rcs 1

sccs2rcs 1

nwcalls 1

nwspxipx 1

nwnlm 1

hook 4

report 1

visdiff 3

ctrls 2

© 2005, W. Pree 86

Visualisierung der Szenario-Interaktionen

© 2005, W. Pree 87

Vorteile und Risken beiAnwendung der SAAM (I)

Die Brauchbarkeit der Ergebnisse hängt entscheidend von der richtigenWahl des Granularitätsgrades der Architekturbeschreibung ab.ZB wäre folgende Granularität bei WRCS problematisch:

© 2005, W. Pree 88

Vorteile und Risken beiAnwendung der SAAM (II)

Ermöglicht rasche und zielsichere Bewertung der Qualität einerSoftwarearchitektur, insbesondere was Änderungen undErweiterungen betrifft.

Keine aufwändigen und detaillierten Code-Inspektionen unddergleichen sind nötig.

Ein Aufwand von wenigen Personentagen (2 bis 5 Tage je nachSytemkomplexität) ist erforderlich.

Dennoch sind viel Erfahrung und fachliches Wissen von denBeteiligten die Voraussetzung für eine erfolgreiche SAAM-Anwendung.

Stakeholder-Beteiligung ist die sozioökonomische Komponenteder SAAM und sichert die Effizienz des Analyseprozesses.

Die SAAM bietet eine pragmatische Möglichkeit, Kopplung undKohäsion zu „messen“ und auf Grundlage der Messergebnisseeine Bewertung der Balance von Kopplung und Kohäsion einergewählten Modularisierung vorzunehmen.

© 2005, W. Pree 89

MehrdimensionaleModularisierung durch

AspektorientierteProgrammierung (AOP)

© 2005, W. Pree 90

AOP als Weiterentwicklung vonMetaprogrammierung

AOP geht auf Gregor Kiczales zurück und wurde Mitte der1990er Jahre bekannt

Die grundlegende Idee der AOP ist, dass für ein Softwaresystemnicht bloß eine (statisch festgelegte) Modularisierung existiert,sondern dass unterschiedliche Sichten auf die Modularisierungeines Softwaresystem gelegt werden können. Deswegenbezeichnen wir AOP auch als ein Mittel zur „mehrdimensionalenModularisierung“.

Die zusätzlichen, die statische Modularisierung überlagerndenModularisierungen sind an Bedingungen geknüpft, die zurLaufzeit evaluiert werden.

Die Metaprogrammierung, mit der die Semantik einerProgrammiersprache erweitert werden kann, wurde bei AOPangewendet, um die Modularisierung von Software zuverbessern.

© 2005, W. Pree 91

Ausgangspunkt von AOP: das Problem einereinzigen statischen Modularisierung (I)

Beispiel Apache Tomcat Web-Server (laut aspect.org):

gute Modularisierung des Aspekts“URL-Mustererkennung”

© 2005, W. Pree 92

Ausgangspunkt von AOP: das Problem einereinzigen statischen Modularisierung (II)


schlechte Modularisierung des Aspekts“Logging”

© 2005, W. Pree 93

AOP-Lösung: Cross-Cutting


“Cross-Cutting” des über viele Moduleverteilten Logging-Codes zu einem neuenAOP-Modul Logging

© 2005, W. Pree 94

AOP-Konzepte in AspectJ (I)Beispiel: Grafikeditor

AspectJ ist die AOP-Erweiterung von Java AspectJ erweitert mit den sogenannten Dynamic Join

Points die Semantik der Sprache Java. Die anderen vier Konstrukte von AspectJ Point Cuts,

Advices, Intra Class Declarations (auch OpenClasses genannt), und Aspects ergänzen lediglichJava, ohne direkt die Semantik der Sprache zuverändern.

© 2005, W. Pree 95

AOP-Konzepte in AspectJ (II)Beispiel: Grafikeditor

Ausgangspunkt (nicht AOP):

© 2005, W. Pree 96

AOP-Konzepte in AspectJ (III)Beispiel: Grafikeditor


class Line implements FigureElement { private Point p1, p2; Point getP1() { return p1; } Point getP2() { return p2; } void setP1(Point p1) { this.p1 = p1; Display.update(); } void setP2(Point p2) { this.p2 = p2; Display.update(); } void moveBy(int dx, int dy) { ... Display.update(); }}

© 2005, W. Pree 97

AOP-Konzepte in AspectJ (IV)Beispiel: Grafikeditor


class Point implements FigureElement { private int x = 0, y = 0; int getX() { return x; } int getY() { return y; } void setX(int x) { this.x = x; Display.update(); } void setY(int y) { this.y = y; Display.update(); } void moveBy(int dx, int dy) { ... Display.update(); }}

© 2005, W. Pree 98

AOP-Konzepte in AspectJ (V)Beispiel: Grafikeditor

AOP-Join-Point-Konzept:Der AOP-Entwickler bekommt dadurch die Möglichkeit, in Methoden aufden Aufruf einer Methode beziehungsweise auf die Ausführung einerMethode zu reagieren.In AspectJ werden folgende Arten von Join-Points unterschieden:Methoden- und Konstruktor-Aufrufe; Methoden- und Konstruktor-Ausführungen, Zugriff auf Instanzvariablen (Setter- und Getter-Methoden),Ausführung von Ausnahmebehandlungen, statische und dynamischeInitialisierung.

© 2005, W. Pree 99

AOP-Konzepte in AspectJ (VI)Beispiel: Grafikeditor

Ein Point Cut ist in AOP als logisches Prädikat aufeinem Join Point definiert. ZB trifft der Point Cut

call(void Line.setP1(Point))zu, wenn ein Methodenaufruf mit der angebenenSignatur void Line.setP1(Point) erfolgt.Das AspectJ-Schlüsselwort call wird als Designatorbezeichnet, der für den Join Point Methodenaufrufdefiniert worden ist. Point Cuts können mit logischenOperatoren (gemäß Java-Syntax) verknüpft werden, wiezum Beispiel:

call(void Line.setP1(Point)) ||call(void Line.setP2(Point))

© 2005, W. Pree 100

AOP-Konzepte in AspectJ (VII)Beispiel: Grafikeditor

Ein Point Cut kann auch benannt werden. In unseremBeispiel nennen wir den Point Cut move:

pointcut move():call(void Line.setP1(Point)) ||call(void Line.setP2(Point))

Ein Point Cut kann auch Parameter haben. In diesemeinfachen Beispiel ist das nicht erforderlich.

© 2005, W. Pree 101

AOP-Konzepte in AspectJ (VIII)Beispiel: Grafikeditor

Außer call bietet AspectJ weitere Designatoren, wie zumBeispiel execute, get, set, und handler, die den weiterenJoin Point-Arten

Methoden-Ausführung, Zugriff auf Instanzvariablen

(Setter- und Getter-Methoden), und Ausführung von Ausnahmebehandlungen

entsprechen.Darauf gehen wir in der überblicksartigen Darstellung vonAOP nicht ein.

© 2005, W. Pree 102

AOP-Konzepte in AspectJ (IX)Beispiel: Grafikeditor

Unter einem Aspect versteht man eine spezifischeKlasse, die quer durch andere Klassen „schneidet“(cross cutting), um den dort verstreuten,aspektbezogenen Code, der logisch zusammengehört, ineinem Modul zusammenzufassen.

© 2005, W. Pree 103

AOP-Konzepte in AspectJ (X)Beispiel: Grafikeditor

aspect DisplayUpdating { pointcut move(): call(void FigureElement.moveBy(int, int)) || call(void Line.setP1(Point)) || call(void Line.setP2(Point)) || call(void Point.setX(int)) || call(void Point.setY(int));

after() returning: move() { // after Advice Display.update(); }}

© 2005, W. Pree 104

AOP-Konzepte in AspectJ (XI)Beispiel: Grafikeditor

Unter einem Advice versteht man in AOP den Code,der ausgeführt wird, wenn ein Point Cut zutrifft. DerAOP after Advice beschreibt, was zu tun ist, wenn derPoint Cut move zutrifft, also mindestens eines der call-Prädikate zutrifft: Die statisch definierte Methodeupdate() der Klasse Display wird aufgerufen.

Damit werden die Display.update() Anweisungenüberflüssig, wie sie in der konventionellen,objektorientierten Implementierung in den Methodender Klassen Point und Line enthalten waren.

© 2005, W. Pree 105

Weitere AOP-Konzepte werden in dieserEinführung nicht erläutert

Die Erläuterung der zahlreichen weiteren Facetten vonAOP, wie zum Beispiel

Parameter, Vor- und Nachbedingungen, Wildcards, Reflection, abstrakte Aspekte, sowie die Einbettung von AOP in

Programmierumgebungen,würden den Rahmen dieses als Überblick konzipiertenAbschnittes sprengen.

© 2005, W. Pree 106

Kritische Betrachtung von AOP

Ein Nachteil von AOP ist, dass die Lokalität beiErweiterungen verloren geht: Wenn ein neuesFigureElement, zum Beispiel ein Circle, hinzugefügtwird, muss zusätzlich die „globale Klasse“, also aspectDisplayUpdating, geändert werden.

Je mehr Point Cuts vorgesehen werden, umsoschwieriger ist es nachvollziehbar, wann welchePrädikate zutreffen. Man verliert schnell den Überblick.

© 2005, W. Pree 107

Zusammenfassung wichtigerModularisierungsprinzipien

© 2005, W. Pree 108

Wichtige Modularisierungsprinzipien

Die wichtigste Eigenschaft eines Moduls ist, einMittel für Abstraktionen zur Verfügung zu stellen.Es sollen unwichtige (Implementierungs-)Detailshinter einer Schnittstelle verborgen werden.

Die Festlegung einer Softwarearchitektur durch dieModularisierung eines Softwaresystems erfordert einegute Kenntnis des Anwendungsbereichs. DieKomponenten sollen den Entitäten desAnwendungsbereichs entsprechen.

Die Module sollen eine Balance von Kopplung undKohäsion aufweisen.

© 2005, W. Pree 109

Der Bezug zu Architektur...

Die Modularisierung eines Softwaresystems ist eine schwierige,zum Teil künstlerische Aufgabe, wo es ähnlich wie bei derGebäudearchitektur keine Methoden gibt, die verlässlich zu einemguten Ergebnis führen.

Christopher Alexander, ein Architekturprofessor an der Universitätvon Kalifornien in Berkeley, der die Muster von seiner Meinungnach guten Gebäudearchitekturen beschrieben hat (Alexander,1977), prägte den Begriff „quality without a name“. Eine guteArchitektur hat eine „quality without a name“, die nichtexplizit beschrieben werden kann.

Was hilft, ein guter Architekt zu werden, ist, viele guteArchitekturen zu studieren, die diese „quality without a name“haben. Leider gibt es bisher nur wenigeSoftwarearchitekturen, die diese Qualität haben undeinzusehen sind.

Documents

Beschreibung von Softwarearchitekturen...Möglichkeiten einer Strukturierung eines Softwaresystems, (4)Klassifikation von Szenarien in direkte und indirekte Szenarien, (5)Evaluierung