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