Artefakt: Referenzarchitektur
Dieses Arbeitsergebnis ist im Wesentlichen ein vordefiniertes Architekturmuster bzw. eine Gruppe von Mustern, eventuell teilweise oder vollständig instanziert, das bzw. die für den Gebrauch in bestimmten geschäftlichen und technischen Kontexten instanziert und entworfen wurde und sich in der Praxis bewährt hat. Um die Verwendung zu ermöglichen, werden unterstützende Artefakte eingesetzt.
Domänen: Analyse und Design
Arten von Arbeitsergebnissen: Konzept
Zweck

Die Arbeitsergebnisse der Referenzarchitektur gehören zur wiederverwendbaren Assetbasis einer Organisation. Ihr Zweck besteht darin, einen Ausgangspunkt für die Architekturentwicklung zu schaffen. Die Arbeitsergebnisse reichen von gebrauchsfertigen Architekturmustern, Architekturmechanismen und Gerüsten bis hin zu vollständigen Systemen mit bekannten, bewährten Merkmalen. Sie können allgemein oder für eine breite Klasse von Systemen anwendbar sein, domänenübergreifende oder domänenspezifische Bedeutung haben.

Die Verwendung getesteter Referenzarchitekturen ist eine effektive Methode zur Handhabung vieler nicht funktionaler Anforderungen, insbesondere Qualitätsanforderungen. Es werden vorhandene, bewährte Referenzarchitekturen ausgewählt, um diese Anforderungen zu erfüllen. Referenzarchitekturen können auf verschiedenen Abstraktionsstufen vorhanden sein und unter verschiedenen Gesichtspunkten verwendet werden. Diese entsprechen den 4+1-Sichten (siehe "Typische Architektursichten"). Auf diese Weise kann der Softwarearchitekt das auswählen, was am besten passt - nur Architekturdesign oder Design und Implementierung, jeweils mit unterschiedlichem Fertigstellung.  

Eine Referenzarchitektur wird oft so definiert, dass sie keine Instanzen der Komponenten enthält, die für die Konstruktion des Systems verwendet werden - wenn sie es tut, wird sie zur Produktlinienarchitektur. Das ist jedoch keine verbindliche Unterscheidung. In Rational Unified Process (RUP) kann der Begriff der Referenzarchitektur Referenzen auf vorhandene, wiederverwendbare Komponenten (d. h. Implementierungen) einbeziehen.

Beziehungen
Beschreibung
Hauptbeschreibung

Organisation von Assets

Die Organisation, die Eignerin der Assets für die Referenzarchitektur ist, muss bestimmen, wie die Assets klassifiziert und organisiert werden sollen, damit der Softwarearchitekt sie einfach abrufen kann, indem er Auswahlkriterien für das neue System abgleicht. Obwohl die Erstellung und Speicherung der Referenzarchitektur gegenwärtig außerhalb von RUP erfolgt, besteht die Möglichkeit, Architekturen nach dem Konzept der Domäne aufzubauen, wobei unter Domäne ein Themenbereich zu verstehen ist, der Wissen und Konzepte für einen Systemaspekt oder eine Systemfamilie definiert. Hier wird der Begriff "Domäne" auf Ebenen zugelassen, die der Anwendungsebene untergeordnet sind. Diese Verwendung weicht leicht von einigen Definitionen ab, z. B. der in Veröffentlichung HOF99 dargestellten, passt jedoch zu der Darstellung in Veröffentlichung LMFS96:

"Produktliniendomäne: Eine gebundene Gruppe gegenwärtig verwendeter und/oder in Zukunft zu verwendender Funktionen, die definiert werden, um die Kommunikation, Analyse und Entwicklung zu vereinfachen und so die Gemeinsamkeiten in einer Produktlinie zu identifizieren, zu entwickeln und zu steuern. Solche Domänen können eng zusammengehörende Gruppen von Endbenutzersystemen, allgemein verwendete Funktionen in mehreren Systemen oder Gruppierungen zugrunde liegender Services, die in vielen Bereichen angewendet werden können, beinhalten."

Diese Definition beinhaltet die Vorstellung, dass Elemente, die zum Erstellen von Systemen verwendet werden, zu einer Domäne gehören, die eine separate Untersuchung lohnt. Die folgende Abbildung aus der Veröffentlichung [LMFS96] veranschaulicht dieses Prinzip.

Horizontale und vertikale Domänen für die U.S. Army

Horizontale und vertikale Domänen bei der US Army

Diese Abbildung zeigt die Hauptsystemfamilien, die Informationssysteme, den Bereich Befehl und Steuerung sowie die Waffensysteme, alle mit vollständig enthaltenen vertikalen und horizontalen Domänen, von denen sie durchzogen sind. Daher sind die meisten Konzepte für Echtzeitplanung auf die Domäne Taktik des Bereichs Befehl und Steuerung sowie alle vertikalen Domänen des Bereichs Waffensysteme anwendbar. Aus diesem Grund macht es wahrscheinlich Sinn, Probleme für die Echtzeitplanung einmal für alle diese Domänen zu lösen und das Wissen und die Assets, die so gewonnen werden, als eigenständige Domäne zu entwickeln, die dann eine Zuordnung zum Bereich Elektronische Kriegsführung, nicht aber zum Bereich Informationssysteme (Personal und Logistik) hat.

Inhalt

Die Referenzarchitektur hat dieselbe Form wie das Softwarearchitekturdokument und die zugeordneten Modelle, ohne projektspezifische Referenzen bzw. mit generischen Referenzen und Merkmalen, so dass die Referenzarchitektur in der Assetbasis entsprechend klassifiziert werden kann. Typische, dem Softwarearchitekturdokument (SAD) zugeordnete Modelle sind das Anwendungsfallmodell, das Designmodell, das Implementierungsmodell und das Deployment-Modell.

Der Zugriff auf das SAD und die zugeordneten Modelle bieten verschiedene Zugangspunkte für den Softwarearchitekten, der sich entscheiden könnte, nur die konzeptionellen oder logischen Teile der Architektur zu verwenden (wenn die Wiederverwendungs-Policy der Organisation dies zulässt). Das andere Extrem läge vor, wenn der Softwarearchitekt der Assetbasis vollständige funktionsfähige Subsysteme und ein Deployment-Modell auf der physischen Ebene (d. h. einen vollständigen Hardware- und Netzentwurf) entnähme.

Andere unterstützende Artefakte sind erforderlich, um die Architektur-Assets verwendbar zu machen.  

  1. Das Anwendungsfallmodell beschreibt das Verhalten der Architektur, der Softwarearchitekt muss jedoch auch ihre nicht funktionalen Merkmale kennen. Diese zwei Aspekte, das Anwendungsfallmodell und die nicht funktionalen Anforderungen, wurden möglicherweise zuvor in einer Spezifikation der Softwareanforderungen erfasst. Anhand der Spezifikation kann der Softwarearchitekt bestimmen, in welchem Maße die Referenzarchitektur mit aktuellen Anforderungen übereinstimmt.

  2. Bei der Verwendung und insbesondere der Änderung der Architektur ist ebenso wie bei der ursprünglichen Entwicklung eine Anleitung erforderlich. Beispielsweise muss der Softwarearchitekt wissen, welche Regeln bei der Bildung der Referenzarchitektur angewendet wurden, und wie schwierig es sein wird, die Schnittstellen zu ändern. Die der Referenzarchitektur zugeordneten Designrichtlinien können helfen, diese Fragen zu beantworten.

  3. (Optional) Die Überprüfung aller relevanten vorhandenen Testpläne kann sich ebenfalls als nützlich erweisen. Diese Testpläne informieren den Architekten über die Test- und Bewertungsstrategien, die zuvor zum Testen ähnlicher Architekturen verwendet wurden und wahrscheinlich Einblicke in potenzielle Schwächen der Architektur geben können.

  4. (Optional) Die Überprüfung aller relevanten vorhandenen Architekturen für Testautomatisierung und Spezifikationen von Testschnittstellen kann nützlich sein. Diese Artefakte informieren den Architekten über Anforderungen, die wahrscheinlich an die Architektur gestellt werden, und erleichtern so das Testen.

Kurze Gliederung

Organisation von Assets

Die Organisation, die Eignerin der Assets für die Referenzarchitektur ist, muss bestimmen, wie die Assets klassifiziert und organisiert werden sollen, damit der Softwarearchitekt sie einfach abrufen kann, indem er Auswahlkriterien für das neue System abgleicht. Obwohl die Erstellung und Speicherung der Referenzarchitektur gegenwärtig außerhalb von RUP erfolgt, besteht die Möglichkeit, Architekturen nach dem Konzept der Domäne aufzubauen, wobei unter Domäne ein Themenbereich zu verstehen ist, der Wissen und Konzepte für einen Systemaspekt oder eine Systemfamilie definiert. Hier wird der Begriff "Domäne" auf Ebenen zugelassen, die der Anwendungsebene untergeordnet sind. Diese Verwendung weicht leicht von einigen Definitionen ab, z. B. der in Veröffentlichung HOF99 dargestellten, passt jedoch zu der Darstellung in Veröffentlichung LMFS96:

"Produktliniendomäne: Eine gebundene Gruppe gegenwärtig verwendeter und/oder in Zukunft zu verwendender Funktionen, die definiert werden, um die Kommunikation, Analyse und Entwicklung zu vereinfachen und so die Gemeinsamkeiten in einer Produktlinie zu identifizieren, zu entwickeln und zu steuern. Solche Domänen können eng zusammengehörende Gruppen von Endbenutzersystemen, allgemein verwendete Funktionen in mehreren Systemen oder Gruppierungen zugrunde liegender Services, die in vielen Bereichen angewendet werden können, beinhalten."

Diese Definition beinhaltet die Vorstellung, dass Elemente, die zum Erstellen von Systemen verwendet werden, zu einer Domäne gehören, die eine separate Untersuchung lohnt. Die folgende Abbildung aus der Veröffentlichung [LMFS96] veranschaulicht dieses Prinzip.

Horizontale und vertikale Domänen bei der US Army

Horizontale und vertikale Domänen bei der US Army

Diese Abbildung zeigt die Hauptsystemfamilien, die Informationssysteme, den Bereich Befehl und Steuerung sowie die Waffensysteme, alle mit vollständig enthaltenen vertikalen und horizontalen Domänen, von denen sie durchzogen sind. Daher sind die meisten Konzepte für Echtzeitplanung auf die Domäne Taktik des Bereichs Befehl und Steuerung sowie alle vertikalen Domänen des Bereichs Waffensysteme anwendbar. Aus diesem Grund macht es wahrscheinlich Sinn, Probleme für die Echtzeitplanung einmal für alle diese Domänen zu lösen und das Wissen und die Assets, die so gewonnen werden, als eigenständige Domäne zu entwickeln, die dann eine Zuordnung zum Bereich Elektronische Kriegsführung, nicht aber zum Bereich Informationssysteme (Personal und Logistik) hat.

Inhalt

Die Referenzarchitektur hat dieselbe Form wie das Softwarearchitekturdokument und die zugeordneten Modelle, ohne projektspezifische Referenzen bzw. mit generischen Referenzen und Merkmalen, so dass die Referenzarchitektur in der Assetbasis entsprechend klassifiziert werden kann. Typische, dem Softwarearchitekturdokument (SAD) zugeordnete Modelle sind das Anwendungsfallmodell, das Designmodell, das Implementierungsmodell und das Deployment-Modell.

Der Zugriff auf das SAD und die zugeordneten Modelle bieten verschiedene Zugangspunkte für den Softwarearchitekten, der sich entscheiden könnte, nur die konzeptionellen oder logischen Teile der Architektur zu verwenden (wenn die Wiederverwendungs-Policy der Organisation dies zulässt). Das andere Extrem läge vor, wenn der Softwarearchitekt der Assetbasis vollständige funktionsfähige Subsysteme und ein Deployment-Modell auf der physischen Ebene (d. h. einen vollständigen Hardware- und Netzentwurf) entnähme.

Andere unterstützende Artefakte sind erforderlich, um die Architektur-Assets verwendbar zu machen.  

  1. Das Anwendungsfallmodell beschreibt das Verhalten der Architektur, der Softwarearchitekt muss jedoch auch ihre nicht funktionalen Merkmale kennen. Diese zwei Aspekte, das Anwendungsfallmodell und die nicht funktionalen Anforderungen, wurden möglicherweise zuvor in einer Spezifikation der Softwareanforderungen erfasst. Anhand der Spezifikation kann der Softwarearchitekt bestimmen, in welchem Maße die Referenzarchitektur mit aktuellen Anforderungen übereinstimmt.

  2. Bei der Verwendung und insbesondere der Änderung der Architektur ist ebenso wie bei der ursprünglichen Entwicklung eine Anleitung erforderlich. Beispielsweise muss der Softwarearchitekt wissen, welche Regeln bei der Bildung der Referenzarchitektur angewendet wurden, und wie schwierig es sein wird, die Schnittstellen zu ändern. Die der Referenzarchitektur zugeordneten Designrichtlinien können helfen, diese Fragen zu beantworten.

  3. (Optional) Die Überprüfung aller relevanten vorhandenen Testpläne kann sich ebenfalls als nützlich erweisen. Diese Testpläne informieren den Architekten über die Test- und Bewertungsstrategien, die zuvor zum Testen ähnlicher Architekturen verwendet wurden und wahrscheinlich Einblicke in potenzielle Schwächen der Architektur geben können.

  4. (Optional) Die Überprüfung aller relevanten vorhandenen Architekturen für Testautomatisierung und Spezifikationen von Testschnittstellen kann nützlich sein. Diese Arbeitsergebnisse informieren den Architekten über Anforderungen, die wahrscheinlich an die Architektur gestellt werden, und erleichtern so das Testen.

Anpassung
DarstellungsoptionenUML-Darstellung - verschiedene relevante Architektursichten: Anwendungsfallsicht, logische Sicht, Prozesssicht, Deployment-Sicht, Implementierungssicht, Datensicht.

Vorhandene Referenzarchitekturen sollten, sofern sie nicht vollkommen neu sind, auf ihre Anwendbarkeit (für Domäne und Entwicklungstyp) überprüft werden, vorausgesetzt, sie sind für die Entwicklungsorganisation zugänglich. Die Erstellung von Referenzarchitekturen ist eine Frage, die auf der Ebene der Organisation behandelt werden muss. Es besteht sicherlich die Möglichkeit, die obige Inhaltsliste zu reduzieren und immer noch einige Vorteile aus der Wiederverwendung der Architektur zu erzielen. Beispielsweise ist es möglich, das Testmodell zu übergehen, obwohl Tests bei einer Änderung der Architektur neu geschrieben werden müssten. Das Minimum, das man erwarten kann, ist ein Designmodell mit zugehörigen Verhaltensbeschreibungen (eventuell ein Anwendungsfallmodell). Werden diese Mindestvoraussetzungen unterschritten, kann man das Asset nur noch schwerlich Referenzarchitektur nennen. Man könnte es dann noch als gültiges Muster bezeichnen.