Aufgabe: Implementierungsmodell strukturieren
Diese Aufgabe beschreibt, wie Sie die Struktur der Implementierungselemente auf der Basis zugeordneter Zuständigkeiten für Implementierungssubsysteme und ihren Inhalt aufbauen.
Beziehungen
RollenHauptrollen: Zusätzliche Rollen: Unterstützende Rollen:
EingabenVerbindlich: Optional: Extern:
  • Ohne
Ausgaben
Schritte
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.

Abbildung zum Extrahieren von Typendeklaration in ein Subsystem

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.

Beispiel für Übertragung von Artefaktgruppierungen

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

Informationen hierzu finden Sie in Prüfliste: Implementierungsmodell.

 

Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen