Arbeitsergebnis: 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. |
|
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
Rollen | Verantwortlich:
| Geändert von:
|
Eingabe für | Verbindlich:
| Optional:
| Extern:
|
Beschreibung
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
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.
-
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.
-
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.
-
(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.
-
(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.
|
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 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.
-
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.
-
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.
-
(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.
-
(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.
|
Eigenschaften
Optional |  |
Geplant |  |
Anpassung
Darstellungsoptionen | UML-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.
|
© Copyright IBM Corp. 1987, 2006. Alle Rechte vorbehalten.
|
|