Struktur des Implementierungsmodells aufbauen
Zweck
|
Gehen Sie wie folgt vor, um die Struktur des Implementierungsmodells aufzubauen.
|
Wenn Sie vom Design zur Implementierung schreiten, beginnen Sie mit Spiegelung der Struktur des Designmodells im
Implementierungsmodell.
Designpakete haben entsprechende Implementierungssubsysteme, die Verzeichnisse und Dateien enthalten (Artefakt
Implementierungselement), mit denen die entsprechenden Designelemente implementiert werden müssen. Die Abbildung des
Designmodells auf das Implementierungsmodell kann sich ändern, da jedes Implementierungssubsystem einer speziellen
Schicht der Architektur zugeordnet ist.
Erstellen Sie ein Diagramm, um die Struktur des Implementierungsmodells darzustellen (siehe Richtlinien:
Implementierungsdiagramm).
|
Implementierungssubsysteme ändern
Zweck
|
Die Struktur des Modells anpassen, um die Teamorganisation oder Einschränkungen für die
Implementierungssprache umzusetzen.
|
Stellen Sie fest, ob die Organisation der Subsysteme geändert werden muss, indem Sie kleine taktische Aspekte in Bezug
auf die Implementierungsumgebung in Augenschein nehmen. Im Folgenden sind einige Beispiele für solche taktischen
Aspekte beschrieben. Wenn Sie sich für die Änderung der Organisation der Implementierungssubsysteme entscheiden, müssen
Sie auch entscheiden, ob Sie zurückgehen und das Designmodell aktualisieren oder das Abweichen des Designmodells vom
Implementierungsmodell zulassen wollen.
-
Organisation des Entwicklerteam. Die Subsystemstruktur muss zulassen, dass mehrere Implementierer oder
Implementiererteams parallel weiterarbeiten können, ohne dass zu viele Überschneidungen entstehen und Unruhe
aufkommt. Es wird empfohlen, jedes Implementierungssubsystem in die Zuständigkeit genau eines Teams zu stellen. Das
bedeutet, dass Sie ein (großes) Subsystem in zwei aufteilen können und die beiden zu implementierenden Teile zwei
Implementierern oder Implementiererteams zuordnen können, insbesondere, wenn die beiden Implementierer (oder Teams)
unterschiedliche Build-/Release-Zyklen haben.
-
Deklaration von Typen. Während der Implementierung können Sie feststellen, dass ein Subsystem
Arbeitsergebnisse eines anderen Subsystems importieren muss, weil ein Typ in diesem Subsystem deklariert ist. Ein
solcher Fall tritt in der Regel ein, wenn Sie typisierte Programmiersprachen wie C++, Java und Ada verwenden. In
solchen Situationen und im Allgemeinen kann es sich empfehlen, Typendeklarationen in ein separates Subsystem zu
extrahieren.
Beispiel
Sie extrahieren einige Typendeklarationen aus dem Subsystem D in ein neues Subsystem "Typen", um Subsystem
A von den Änderungen an den öffentlichen (sichtbaren) Arbeitsergebnissen in Subsystem D unabhängig zu
machen.
Typendeklarationen werden aus Subsystem D extrahiert
.
-
Vorhandener, aus früheren Versionen übernommener und Komponentensysteme. Möglicherweise müssen Sie aus
früheren Versionen übernommenen Code, eine Bibliothek wieder verwendbarer Komponenten oder gebrauchsfertige
Produkte integrieren. Wenn diese im Modell nicht modelliert wurden, müssen Implementierungssubsysteme hinzugefügt
werden.
-
Abhängigkeiten anpassen. Angenommen, ein Subsystem A und ein Subsystem B haben gegenseitige
Importabhängigkeiten. Sie möchten B jedoch weniger abhängig von den Änderungen in Subsystem A machen. Extrahieren
Sie die Arbeitsergebnisse von A, die B importiert, und stellen Sie sie in ein neues Implementierungssubsystem A1 in
einer niedrigeren Schicht.
Arbeitsergebnisse werden aus Subsystem A extrahiert und in ein neues Subsystem A1 gestellt.
Da die Implementierungssubsysteme jetzt nicht mehr eins zu eins mit den Paketen/Subsystemen im Designmodell
übereinstimmen, können Sie entweder eine entsprechende Änderung am Designmodell vornehmen (wenn Sie sich für einen
engen Schulterschluss von Designmodell und Implementierungsmodell entschieden haben) oder die Zuordnung von
Implementierungs- und Designmodell (z. B. durch Rückverfolgbarkeits- oder Realisierungsabhängigkeiten) verfolgen. Ob
und wie eine solche Zuordnung durchgeführt wird, ist eine Prozessentscheidung, die in den projektspezifischen Richtlinien erfasst werden muss.
|
Importe für jedes Implementierungssubsystem definieren
Zweck
|
Abhängigkeiten zwischen Subsystemen definieren.
|
Definieren Sie für jedes Subsystem, welche anderen Subsysteme importiert werden. Sie können dies für vollständige
Gruppen von Subsystemen tun, indem Sie allen Subsystemen auf einer Schicht erlauben, alle Subsysteme einer niedrigeren
Schicht zu importieren. Im Allgemeinen spiegeln die Abhängigkeiten im Implementierungsmodell die des Designmodells
wieder, sofern die Struktur des Implementierungsmodells nicht angepasst wurde (siehe Implementierungssubsysteme anpassen).
Stellen Sie die geschichtete Struktur der Subsysteme in Komponentendiagrammen dar.
|
Behandlung ausführbarer Programme (und anderer abgeleiteter Objekte) festlegen
Ausführbare Programme (und andere abgeleitete Objekte) entstehen, wenn ein Build-Prozess auf ein
Implementierungssubsystem (oder -subsysteme) oder einen Teil eines solchen angewendet wird, und gehören somit logisch
zum Implementierungssubsystem. Der Softwarearchitekt muss jedoch zusammen mit dem Konfigurationsmanager die Struktur
der Konfigurationselemente festlegen, die auf das Implementierungsmodell angewendet wird.
Zur Vereinfachung von Auswahl, Referenz und insbesondere Deployment wird empfohlen, separate Konfigurationselemente zu
definieren, die die Gruppen ausführbarer Programme enthalten, die eingesetzt werden können (welche ausführbaren
Programme auf welchen Knoten eingesetzt werden, wird im Deployment-Modell erfasst). Im einfachsten Fall gibt es somit für
jedes Implementierungssubsystem ein Konfigurationselement für die einsetzbaren ausführbaren Programme und ein
Konfigurationselement für die Quelle, die für die Generierung verwendet wird. Das Implementierungssubsystem kann auch
durch ein zusammengesetztes Konfigurationselement dargestellt werden, das diese Konfigurationselemente (und andere, z.
B. Test-Assets) enthält.
Aus der Modellierungsperspektive kann eine Sammlung ausführbarer Programme, die von einem Build-Prozess erzeugt werden,
als Build (ein Paket) dargestellt werden, das im zugeordneten
Implementierungssubsystem (auch ein Paket) enthalten ist.
|
Behandlung von Test-Assets festlegen
Zweck
|
Testarbeitsergebnisse zum Implementierungsmodell hinzufügen.
|
Im Allgemeinen werden Testarbeitsergebnisse und Testsubsysteme in Rational Unified Process nicht wesentlich anders
behandelt als andere entwickelte Software. Testarbeitsergebnisse und -subsysteme gehören jedoch in der Regel nicht zum
eingesetzten System und sind häufig nicht an den Kunden auslieferbar. Deshalb empfiehlt es sich, die Test-Assets an dem
Testziel (z. B. Implementierungselement für Einheitentest, Implementierungssubsystem für Integrationstest, System für
Systemtest) auszurichten, aber die Test-Assets beispielsweise in separaten Testverzeichnissen zu verwalten, falls das
Projekt-Repository als Gruppe oder Hierarchie von Verzeichnissen aufgebaut ist. Gesonderte Testsubsysteme (die für
Tests oberhalb der Einheitentestebene bestimmt sind) müssen auf dieselbe Weise behandelt werden wie andere
Implementierungssubsysteme, nämlich als gesonderte Konfigurationselemente.
Für die Modellierung kann eine Sammlung von Testarbeitsergebnissen als Implementierungssubsystem (ein Paket) dargestellt werden. Für
Einheitentests ist ein solches Testsystem normalerweise im zugeordneten (getesteten) Implementierungssubsystem
enthalten. Der Softwarearchitekt muss in Absprache mit dem Konfigurationsmanager entscheiden, ob Testarbeitsergebnisse
auf dieser Ebene zusammen mit den Implementierungselementen, die sie testen, oder als separate Konfigurationselemente
konfiguriert werden sollen. Für Integrations- und Systemtests können die Testsubsysteme Partner der zu testenden
Implementierungssubsysteme sein.
|
Implementierungssicht aktualisieren
Zweck
|
Implementierungssicht des Softwarearchitekturdokuments aktualisieren.
|
Die Implementierungssicht wird im Softwarearchitekturdokument beschrieben. Dieser Abschnitt enthält
Komponentendiagramme, die die Schichten und die Zuordnung der Implementierungssubsysteme zu Schichten sowie die
Importabhängigkeiten zwischen Subsystemen aufzeigen.
|
Implementierungsmodell bewerten
|