Richtlinie: Architekturerkennung, Analyse und Steuerung
Diese Richtlinie beschreibt, wie Sie mit der Modellierungsumgebung von RSA Architekturerkennung, Analyse und Steuerung für ein Projekt verwenden.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

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 Symbol für Onlinehilfe 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.

Eine Klasse mit vier abhängigen Elementen, zwei bei Abhängigkeitsbeziehungen in der Verwendung, eine durch eine Generalisierungsbeziehung und eine durch eine Realisierungsbeziehung

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".

Eine Klasse mit vier abhängigen Elementen, zwei bei Abhängigkeitsbeziehungen in der Verwendung, eine durch eine Generalisierungsbeziehung und eine durch eine Realisierungsbeziehung.

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 Symbol für Onlinehilfe 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 Symbol für Onlinehilfe Rational Software Architect.