Einführung
In einigen Aufgaben von RUP wird erörtert, dass die neu entstehenden Designmodelle untersucht und Urteile zu verschiedenen
Qualitätsaspekten gefällt werden müssen, und dass im Anschluss daran ein Refactoring für das Modell erstellt werden
muss. Es ist außerdem wichtig, die architektonische Integrität des Systems zu pflegen, sobald sie implementiert wurde,
um sicherzustellen, dass die Integritätsbedingungen zu Architektur und Design nicht verletzt werden und dass sich das
implementierte System weiterhin an der Architekturvision ausrichtet. In RUP werden diese entscheidenden Prüfpunkte in
den Aufgaben Architektur prüfen, Design prüfen und Code prüfen
behandelt.
Ein anderes, wenngleich verwandtes, Problem tritt bei der Architektur- und Designsynthese auf: Dem Softwarearchitekten
wird in den Aufgaben Architekturanalyse (siehe Architekturübersicht entwickeln und Verfügbare Assets begutachten) und Vorhandene Designelemente integrieren empfohlen, nach Möglichkeiten
der Wiederverwendung vorhandener Design- und Code-Assets zu suchen und diese ggf. nach einem Reverse-Engineering in das
Designmodell zu integrieren. Wenn die wiederverwendeten Assets nicht mit einem Qualitätssiegel versehen wurden, sollte
sie der Softwarearchitekt mit derselben Genauigkeit untersuchen, wie er neu erstelltes Design und Code begutachtet.
In beiden Fällen sind die Anforderungen an den Softwarearchitekten bei dieser statischen Analyse dieselben:
-
Er muss eine codierte Anwendung (oder ein Fragment davon) untersuchen, die symbolischen Strukturen erkennen und
diese idealerweise in einem Designmodell in UML-Form wiederherstellen. Ein besonderer Vorteil in der
Wiederherstellung durchsuchbarer Dokumentationsartefakte liegt für den Softwarearchitekten darin, zu sehen, wie der
Code tatsächlich aufgebaut ist, wenn es keine oder nur eine veraltete Dokumentation gibt.
-
Um Designmodelle analysieren zu können, muss der Softwarearchitekt die Qualitätsmetriken (siehe Beispiel Kopplung) zusammenstellen, die im Projektkontrollplan enthalten sind, und die Einhaltung anhand des
Softwarearchitekturdokuments und der Designrichtlinien prüfen.
-
Er muss über wichtige Änderungen an der Architektur oder am Design informiert werden, so dass er gegebenenfalls
entsprechende Korrekturmaßnahmen ergreifen kann. Der Softwarearchitekt legt die Kriterien fest, nach denen
entschieden wird, welche Änderungen wichtig sind.
Theoretisch können diese Anforderungen mit Hilfe von Untersuchungen erfüllt werden. Doch wenn es sich um größere,
komplexe Systeme handelt, ist eine automatische Unterstützungsfunktion von entscheidender Bedeutung. In den
nachfolgenden Abschnitten finden Sie Informationen zu diesen Themen und Beispiele zur Toolunterstützung.
Architekturerkennung und -wiederherstellung
Hintergrund
In der Green-Field-Entwicklung entwickelt sich die Softwarearchitektur aus den Anforderungen, dem Domänenzusammenhang
und den Konventionen (einschließlich Muster und Mechanismen). Das Artefakt Ergänzende Spezifikationen spielt bei der Bestimmung der Architektur
eine wichtige Rolle. Dieser Prozess der Entwicklung der Softwarearchitektur wird manchmal Architekturerkennung genannt,
da es in der Regel keine eindeutige, mechanische Zuordnung von den Anforderungen bis zur Architektur gibt. Hier wird
der Begriff Erkennung jedoch anders verwendet. Er beschreibt den Vorgang, der den Softwarearchitekten dabei
unterstützt, eine vorhandene Anwendung oder ein codiertes Anwendungsfragment zu verstehen. Die
Architekturwiederherstellung ist hingegen umfassender: Bei der Wiederherstellung geht es dem
Softwarearchitekten einerseits darum, eine Anwendung zu verstehen, andererseits aber auch darum, wie er ein Modell
dieser Anwendung bestenfalls auf der Abstraktionsebene eines Designmodells extrahieren kann. Es besteht anschließend
die Möglichkeit, diese Modelle über eine Umsetzung zusammenzuführen und eine neue Anwendung ggf. für eine andere Plattform zu generieren.
Erkennung
In den Aufgaben Architekturanalyse (siehe Architekturübersicht entwickeln und Verfügbare Assets begutachten) und Vorhandene Designelement integrieren sucht der Softwarearchitekt nach
Möglichkeiten, vorhandene Design- und Code-Assets wiederverwenden zu können. Eine Organisation hat beispielsweise
mehrere Referenzarchitekturen in ihrer Assetbasis und diese sind idealerweise
im Hinblick auf die Dokumentation und die Modelle auf dem neuesten Stand. Allerdings findet sich üblicherweise nicht
mehr als Quellcode und falls die Architektur dokumentiert wurde, ist sie nicht auf dem neuesten Stand.
In vielen Fällen kann der Softwarearchitekt diesen Code nicht als Blackbox behandeln (selbst wenn die Schnittstellen
eindeutig definiert sind), er muss jedoch die Struktur verstehen können. Unterstützt wird dieser Prozess durch die
Möglichkeit, durchsuchbare Darstellungen des Code automatisch zu generieren. Der Softwarearchitekt kann anschließend
Muster und Antimuster im Code "aufspüren". Ein Beispiel für diese Art der Unterstützung findet sich im RSA-Tool. Die
Funktion für die Architekturerkennung füllt automatisch Themendiagramme für Java-Anwendungen (z. B. Paketstrukturen,
Klasseninterna, Vererbungsbäume und Kollaborationen). Nähere Informationen finden Sie in der Dokumentation zu Rational Software
Architect.
Wiederherstellung und Umsetzung
Wenn wiederverwendbare Assets vollständige Modelle enthalten, ist es möglich, diese Modelle mit projektspezifischen
Modellen zu verbinden und anschließend mit der plattformspezifischen Implementierung mit Hilfe von Umsetzungstechniken
fortzufahren. Wenn nur Code vorhanden ist, besteht dennoch die Möglichkeit, ihn auch bei einem umsetzungsorientierten
Ansatz wiederverwenden zu können, indem der aus der Umsetzung erstellte Code in den Code aus früheren Versionen
integriert wird.
Die Stärke und größtmögliche Flexibilität des Softwarearchitekten liegt in der Verwendung der
Architekturwiederherstellung. Über die Wiederherstellungsfunktion wird ein semantisch aufwendiges Anwendungsmodell
generiert, das für die Codegenerierung und für Suchvorgänge verwendet werden kann. In der Praxis lässt sich das
Reverse-Engineering von Code so lenken, dass eine überschaubare grafische Darstellung dabei herauskommt. Es ist jedoch
generell schwierig, den Vorgang, ein solches Modell auf die Ebene eines plattformunabhängigen Modells (Designmodells) zu transportieren, vollständig zu
automatisieren.
Es handelt sich im Wesentlichen um die Umsetzung eines plattformspezifischen Modells (PSM) in ein plattformunabhängiges Modell (PIM) (siehe MDD (Model
Driven Development) und MDA (Model Driven Architecture)). Das wiederhergestellte PIM (Fragment) wird dann mit dem
Designmodell (auch wiederum ein PIM) mit einem Umsetzungstyp zu einer Modellzusammenführung kombiniert (siehe
[OMG03]).
Architekturanalyse
Der Softwarearchitekt kann mit Hilfe der durchsuchbaren Modelle die Qualität der Architektur prüfen. Dieser Vorgang ist
jedoch sehr mühsam und zeitaufwendig, und das Prüfen der Einhaltung von Standards und Regeln sowie die Zusammenstellung
von Metriken ist mit dieser Methode auch fehleranfällig. Daher sollte der Softwarearchitekt versuchen, so viele
Vorgänge dieses Prozesses wie möglich zu automatisieren, um auf diese Weise mehr Zeit für die Lösungsfindung und
-anwendung zu haben. Eine Automatisierung ermöglicht es dem Softwarearchitekten außerdem, zu experimentieren, da er
Szenarios (Was wäre, wenn?) ausprobieren und das Ergebnis schnell prüfen kann.
Welche Automatisierungsmöglichkeiten gibt es?
Eine automatisierte Architekturanalyse ermöglicht Folgendes:
-
Muster und Antimuster (pathologische Strukturen) in der Architektur suchen
-
Bewertungen an verschiedenen Strukturen durchführen und Metriken
erfassen
-
Einhaltung der Integritätsbedingungen des Softwarearchitekten (siehe Architektursteuerung)
Muster werden durch Projekt- und Organisationsstandards vorgegeben und die Gründe
für ihre Verwendung wird im Softwarearchitekturdokument (wenn sie im Hinblick auf die Architektur von Bedeutung sind)
oder in den Designrichtlinien festgehalten. Mit der automatisierten Analyse kann der Softwarearchitekt schnell die
Musterverwendung prüfen, um festzustellen, ob die im Softwarearchitekturdokument festgehaltenen Absichten und die
Designrichtlinien erfüllt wurden. Antimuster sind unauffällige Architektur- und Designstrukturen, die in gewisser Weise
die Architektur schwächen, sie instabiler oder komplexer werden lassen, oder sie dadurch einfach schwieriger zu
verwalten ist.
Die durchzuführenden Kontrollen werden im Projektkontrollplan beschrieben (einige empfohlene Metriken finden Sie in der
Richtlinie Metriken). Der Projektkontrollplan beschreibt außerdem wie Metriken verwendet werden
sollen, z. B., ob höhere oder niedrigere Werte besser sind, oder ob der Trend wichtig ist, so dass mit der Analyse der
Metriken auch Hotspots identifiziert werden können, d. h. Stellen in der Architektur, an denen Änderungen die erfassten
Metriken entscheidend verbessern. Oftmals finden sich diese Stellen in der Struktur. Der Softwarearchitekt hat
anschließend eine objektive Grundlage für Verbesserungen, kann Änderungen vornehmen oder Folgeaktionen beauftragen, die
getestet werden können, sobald sie abgeschlossen sind.
Was ist das Ziel einer Analyse?
Das Ziel einer Analyse variiert je nach Lebenszyklus und in Abhängigkeit des ausgewählten Entwicklungsansatzes. Wenn
ein Projekt einen umsetzungsorientierten (generierungsorientierten) Ansatz verwendet, ist das Ziel normalerweise das
Designmodell, vorausgesetzt, die generierte Anwendung wird immer am Design synchronisiert. Wenn ein Implementierungsmodell erstellt und separat verwaltet wird, oder wenn
Code wiederverwendet wird, verschiebt sich das Augenmerk auf den Code, um sicherzustellen, dass die Integrität der
Architektur gewährleistet ist, wenn sie am Softwarearchitekturdokument und den Designrichtlinien gemessen wird.
Diese Art der Analyse (an einem Implementierungsmodell) stellt nicht notwendigerweise ein ausführliches Designmodell
aus dem Code wieder her. Es geht jedoch um Architektur- und Designprobleme (wie sie im Code manifestiert sind), die
analysiert werden sollen, und nicht um Codierungsstandards.
Beispiel für diese Konzepte und Funktionen
Das RSA-Tool eignet sich nicht nur für die Wiederherstellung von Dokumentationen für Java-Anwendungen über die
Architekturerkennung, sondern kann auch zur Identifizierung potenzieller Problembereiche in der Architektur mit einer
Reihe vordefinierter Muster und zur entsprechenden Berichterstellung verwendet werden. Zu diesen Mustern gehören unter
anderem Folgende:
-
Butterfly
-
Breakable
-
Hub
-
Tangle
Butterfly
Ein Butterfly ist ein Element, wie z. B. eine Klasse, mit vielen Beziehungen zu anderen abhängigen Elementen,
die von jeder Änderung des Butterfly betroffen sind. Wenn es sich um direkte Beziehungen handelt, werden diese Elemente
als localButterfly bezeichnet. Mit Rational Software Architect können Sie auch Beziehungen, die sich durch
eine Anwendung durchziehen, über die ganze Anwendung hinweg zurückverfolgen und bestimmen, ob Änderungen an einem
Element nicht nur die direkten Abhängigkeiten, sondern auch deren Abhängigkeiten etc. betreffen. Ein solches Element,
das viele indirekte Abhängigkeiten besitzt, wird als globalButterfly bezeichnet. Nachfolgend sehen Sie eine
Abbildung zum Element "localButterfly". Das Diagramm zeigt, dass es neben UML-Abhängigkeiten auch noch andere
Abhängigkeiten geben kann. Ein Element ist beispielsweise von einem anderen Element abhängig, wenn diese Abhängigkeit
realisiert wurde. Änderungen im angegebenen Element wirken sich auf das Element aus, das es realisiert.
Typ "LocalButterfly"
Breakable
Ein Breakable ist ein Element mit vielen Abhängigkeiten, d. h. es hat viele Beziehungen, mit denen es von
anderen Elementen abhängt. Jede Änderungen an einem dieser anderen Elemente wirken sich auf das Breakable aus. Analog
zu den "Butterflys" werden diese Elemente bei direkten Beziehungen als localBreakables bzw.
globalBreakables bezeichnet, wenn es viele indirekte Beziehungen gibt, die das Element betreffen.
"GlobalBreakables" reagieren in vielen Teilen einer Anwendung empfindlich auf Änderungen und deuten auf mangelnde
Modularität hin. Nachfolgend sehen Sie eine Abbildung zu einem "localBreakable".
Typ "localBreakable"
Hub
Ein Hub ist ein Element, das die Merkmale eines Butterfly und eines Breakable vereint. Es weist auch die
Formen local und global auf. Das Vorhandensein von "global hubs" weist auf eine ungünstige
Partitionierung hin, die dazu führt, dass die Software sehr empfindlich auf Änderungen reagiert. Änderungen ziehen sich
in der Regel durch die gesamte Anwendungen.
Tangle
Ein "Tangle" ist eine große Gruppe von Elementen, deren Beziehungen so umfangreich sind, dass eine Änderung in einem
dieser Elemente alle anderen betreffen kann. Solche Strukturen sorgen für große Instabilität.
Der Softwarearchitekt kann durch den Einsatz des RSA-Tools diese Hotspots schnell erkennen und mit dem Designer
zusammenarbeiten, um sie zu beheben. Nähere Informationen finden Sie in der Dokumentation zu Rational Software Architect.
Zeitlicher Verlauf
Die Ergebnisse dieser Analysen sind für die Überprüfung an jedem Meilenstein wichtig. Sie dienen als objektive und
messbare Nachweise für die Qualität der Architektur und des Designs oder bei wichtigen Änderungen an der Architektur,
wenn beispielsweise die Organisation des Designmodells aktualisiert wird (siehe Aufgabe:
Vorhandene Designelemente integrieren).
Architektursteuerung
Die Vision des Softwarearchitekten wird im Softwarearchitekturdokument und die Anleitungen für den Designer in den
Designrichtlinien festgehalten. Selbst wenn diese Vision von alle Mitarbeitern getragen wird, ist es möglich, dass sie
von den täglichen Anforderungen der Projektarbeit in den Hintergrund gedrängt wird. Wenn Termine eingehalten werden
müssen, müssen möglicherweise schnelle Entscheidungen getroffen werden, und der Softwarearchitekt kann nicht an allen
Entscheidungsprozessen teilnehmen. Damit stellt sich nun also die Frage nach der Kontrolle: Ebenso wie der
Projektleiter Einschränkungen und Grenzen bestimmen und deren Einhaltung überwachen muss (siehe Projektstatus überwachen), hat der Softwarearchitekt eine analoge
Aufgabe für das neu entstehende Softwaredesign und die Implementierung.
Mit der Architektursteuerung kann der Softwarearchitekt Regeln erstellen, architekturbezogene Integritätsbedingungen
umzusetzen. Der Softwarearchitekt kann beispielsweise eine Regel definieren, die eine Warnung bei jeder Realisierung
einer bestimmten Schnittstelle ausgibt. Diese Regel ohne Toolunterstützung in einem einfachen Ausdruck umzusetzen,
würde eine regelmäßige Prüfung erfordern, um Verstöße festzustellen. Durch die Automatisierung können die Regeln so
codiert werden, dass Regelsatzverletzungen während der Architekturanalyse erfasst werden. Dies trifft auch hinterher
noch zu, und in einer erweiterten kontrollierten Umgebung werden diese Regeln in den Design- und Codeproduktionsprozess
direkt eingebunden. Auf diese Weise werden Verstöße von vorneherein verhindert. Der manuelle Prüfprozess ist jedoch
dennoch wertvoll.
Das RSA-Tool enthält eine Funktion für Java-Anwendungen, bei der der Softwarearchitekt Regeln aufstellen und
anschließend Analysen durchführen kann, um die Einhaltung zu überprüfen. Nähere Informationen finden Sie in der
Dokumentation zu
Rational Software Architect.
|