Aufgabe: Vorhandene Designelemente integrieren
Diese Aufgabe beschreibt, wie das Designmodell weiterentwickelt und präzisiert wird.
Disziplinen: Analyse und Design
Zweck
  • Interaktionen der Analyseklassen analysieren, um Schnittstellen, Designklassen und Designsubsysteme zu finden.
  • Architektur präzisieren und, sofern möglich, mit Wiederverwendung arbeiten.
  • Allgemeine Lösungen für allgemeine Designprobleme identifizieren.
  • Architektonisch relevante Designmodellelemente in den Abschnitt für die logische Sicht des Softwarearchitekturdokuments aufnehmen.
Beziehungen
Schritte
Möglichkeiten zur Wiederverwendung identifizieren
Zweck Anhand der Schnittstellen feststellen, wo vorhandene Subsysteme und/oder Komponenten wiederverwendet werden können.  

Suchen Sie nach vorhandenen Subsystemen oder Komponenten, die ähnliche Schnittstellen haben. Vergleichen Sie jede identifizierte Schnittstelle mit den Schnittstellen, die von vorhandenen Subsystemen oder Komponenten bereitgestellt werden. In der Regel werden Sie keine exakten Übereinstimmungen finden, aber ungefähre Übereinstimmungen. Suchen Sie zuerst nach ähnlichem Verhalten und zurückgegebenen Werten und schauen Sie sich dann die Parameter an.

Passen Sie die neu identifizierten Schnittstellen an.. Unter Umständen können geringfügige Änderungen an einer Kandidatenschnittstelle vorgenommen werden, die die Konformität mit der vorhandenen Schnittstelle verbessern. Zu einfachen Änderungen gehören die Änderung der Reihenfolge oder das Hinzufügen von Parametern in der Kandidatenschnittstelle und die anschließende Aufteilung der Schnittstelle in mehrere Schnittstellen, von denen eine oder mehrere der vorhandenen Komponente entsprechen. Die "neuen" Verhalten werden in eine separate Schnittstelle ausgelagert.

Ersetzen Sie Kandidatenschnittstellen durch vorhandene Schnittstellen, wenn Sie exakte Übereinstimmungen finden. Wenn nach der Vereinfachung und Aufteilung eine exakte Übereinstimmung mit einer vorhandenen Schnittstelle vorliegt, verwerfen Sie die Kandidatenschnittstelle und verwenden Sie einfach die vorhandene.

Orden Sie das Kandidatensubsystem vorhandenen Komponenten zu. Schauen Sie sich vorhandene Komponenten und die Gruppe der Kandidatensubsysteme an. Teilen Sie die Subsysteme so auf, dass vorhandene Komponenten, sofern möglich, verwendet werden, um das erforderliche Verhalten des Systems zu erbringen. Wenn ein Kandidatensubsystem durch eine vorhandene Komponente realisiert werden kann, sorgen Sie für die Rückverfolgbarkeit zwischen dem Designsubsystem und der Komponente im Implementierungsmodell.

Wenn Sie Subsysteme wiederverwendbaren Komponenten zuordnen, müssen Sie sich die Designmechanismen anschauen, die dem Subsystem zugeordnet sind. Leistungs- und Sicherheitsanforderungen können eine Komponente trotz ansonsten perfekter Übereinstimmung bei den Operationssignaturen für die Wiederverwendung disqualifizieren.

Komponenten und Datenbanken rückentwickeln
Zweck Potenziell wiederverwendbare Modellelemente aus anderen Projekten, externen Quellen oder vorherigen Iterationen integrieren.  

Vorhandener Code und vorhandene Datenbankdefinition können verwendet werden, um Arbeiten aus vorherigen Projekten oder Iterationen im aktuellen Projekt bzw. in der aktuellen Iteration verfügbar zu machen. Durch die Nutzung potenzieller Wiederverwendungsmöglichkeiten als Filter kann sich beim Rückentwickeln (Reverse-Engineering) von Arbeiten auf die Komponenten konzentriert werden, die für die aktuelle Iteration wiederverwendbar sind.

Komponenten rückentwickeln

In Organisationen, die ähnliche Systeme erstellen, gibt es häufig eine Gruppe gemeinsamer Komponenten, die viele Architekturmechanismen bereitstellen, die für ein neues System benötigt werden. Außerdem können Komponenten auf dem Markt verfügbar sein, die diese Architekturmechanismen ebenfalls enthalten. Vorhandene Komponenten sollten untersucht werden, um ihre Eignung für und Kompatibilität mit der Softwarearchitektur zu bestimmen.

Vorhandene Komponenten, die in früheren Iterationen entwickelt, aber noch nicht in das Designmodell integriert wurden, oder gekaufte Komponenten müssen rückentwickelt und in das Designmodell integriert werden. Im Designmodell werden solche Komponenten häufig als Subsystem mit einer oder mehreren Schnittstellen dargestellt.

Datenbanken rückentwickeln

Datenbanken und die in Datenbanken enthaltenen Daten stellen eine der wichtigsten Quellen für wiederverwendbare Assets dar. Zur Wiederverwendung der impliziten Klassendefinitionen, die in vorhandenen Datenbanken enthalten sind, müssen Sie feststellen, welche von der Anwendung verwendeten Informationen bereits in vorhandenen Datenbanken enthalten sind. Anschließend müssen Sie die Klassen rückentwickeln, um die Datenbankstrukturen darzustellen, die diese Informationen enthalten. Gleichzeitig müssen Sie eine Zuordnung zwischen der Klassendarstellung der Anwendung und den in der Datenbank verwendeten Strukturen herstellen. Weitere Informationen zum Rückentwickeln von Datenbanken finden Sie in Richtlinie für Arbeitsergebnis: Relationale Datenbanken rückentwickeln. Weitere Informationen zur Zuordnung von Klassen und Tabellen in einer relationalen Datenbank finden Sie in Richtlinie für Arbeitsergebnis: Datenmodell.

Organisation des Designmodells aktualisieren
Zweck Neue Modellelemente in der Organisation des Designmodells berücksichtigen.
Struktur des Designmodells bei Bedarf erneut ausgleichen. 

Wenn dem Designmodell neue Elemente hinzugefügt werden, müssen die Elemente des Designmodells häufig neu gepackt werden. Mit dem erneuten Packen werden verschiedene Zielsetzungen verfolgt: Kopplung zwischen Paketen verringern und Kohäsion innerhalb der Pakete im Designmodell verbessern. Damit soll erreicht werden, dass unterschiedlichen Pakete (und Subsysteme) unabhängig voneinander von unterschiedlichen Personen oder Teams entworfen und entwickelt werden können. Obwohl eine vollständige Unabhängigkeit wahrscheinlich unmöglich erreicht werden kann, vereinfacht eine lose Kopplung zwischen Paketen im Allgemeinen die Entwicklung großer oder komplexer Systeme.

Eine 'flache' Modellstruktur (in der sich alle Pakete und Subsysteme auf derselben konzeptionellen Ebene im System befinden) eignet sich für kleine Systeme. Größere Systeme benötigen ein zusätzliches Strukturierungswerkzeug, die so genannte 'Schichtung' (siehe Richtlinie für Arbeitsergebnis: Schichtung). Schichtungsregeln definieren Einschränkungen für zu zulässigen Beziehungen zwischen bestimmten Typen von Paketen. Diese Regeln erkennen, dass bestimmte Abhängigkeiten nicht existieren dürfen: Anwendungsfunktionalität darf nicht direkt von bestimmten Betriebssystem- oder fensterorientierten Systemservices abhängig sein. Es muss eine Zwischenschicht vorhanden sein, die logische Betriebssystem- und fensterorientierte Services enthält und die Anwendungsfunktionalität von Änderungen in den Implementierungsservices der unteren Ebene isoliert. Schichtung ist eine Methode, die Auswirkungen von Änderungen zu mindern. Durch das Einsetzen von Regeln, die die Abhängigkeiten zwischen Paketen und Subsystemen einschränken und den Kopplungsgrad zwischen Paketen und Subsystemen verringern, wird das System stabiler. Es wird änderungstolerant.

Wenn dem System neue Modellelemente hinzugefügt werden, können vorhandene Pakete zu groß werden, um von einem einzelnen Team verwaltet zu werden. In diesem Fall muss das Paket auf mehrere Pakete mit hoher Kohäsion intern, aber loser Kopplung untereinander aufgeteilt werden. Diese Aufteilung kann schwierig sein. Einige Elemente lassen sich möglicherweise nur mit Mühe in ein bestimmtes Paket packen, weil sie von Elementen in beiden Paketen verwendet werden. Es gibt zwei Lösungen: Sie können das Element in mehrere Objekte aufteilen, eines für jedes Paket (dies funktioniert, wenn das Element mehrere 'Persönlichkeiten' oder relativ disjunkte Zuständigkeiten hat), oder Sie können das Element in ein Paket in einer niedrigeren Schicht verschieben, so dass alle Elemente der höheren Ebene gleichermaßen von diesem Element abhängig sind.

Je mehr das System an Komplexität zunimmt, desto höher ist die Anzahl der Schichten, die erforderlich sind, um eine verwaltbare und verständliche Struktur zu erhalten. Mehr als 7-10 Schichten sind jedoch ungewöhnlich, selbst in den größten Systemen, da mit zunehmender Anzahl von Schichten die Komplexität steigt und die Verständlichkeit abnimmt.

Im Folgenden sehen Sie ein Beispiel für Schichtung, einschließlich Middleware- und Systemsoftwareschichten:

Layoutdiagramm für eine Java-/Webanwendung

Beispielpaketschichtung für eine Java-/webbasierte Anwendung. Beachten Sie, dass die Abhängigkeiten vom TCP/IP-Paket normalerweise nicht explizit modelliert werden, da die Verwendung von TCP/IP-Services in der Java-VM, java.rmi und im Web-Browser gekapselt sind. Sie sind hier nur zur Veranschaulichung dargestellt.

Ordnen Sie Einzelpersonen oder Teams Zuständigkeiten für die Subsysteme und Schichten zu. Jedes Paket und jedes Subsystem muss in der Zuständigkeit einer Person (bei geringem Umfang) oder eines Teams (bei großem Umfang) liegen.

Logische Sicht aktualisieren
Zweck Sicherstellen, dass das Softwarearchitekturdokument (logische Sicht) auf dem neuesten Stand ist.  

Wenn Designklassen, Pakete und Subsysteme (Modellelemente) aus Architekturperspektive wichtig sind, müssen sie in den Abschnitt zur logischen Sicht des Softwarearchitekturdokuments aufgenommen werden. Auf diese Weise wird gewährleistet, dass neue architektonisch relevante Modellelemente an die anderen Projektteammitglieder kommuniziert werden.

Außerdem stellt die Rolle Softwarearchitekt in Zusammenarbeit mit der Rolle Prozessentwickler detaillierte Anleitungen für Designer und Implementierer zur Verwendung der neu integrierten Designelemente bereit.



Weitere Informationen