Architekturübersicht entwickeln
Zweck:
|
Die Systemvisionierung durch Untersuchen und Auswerten von Architekturoptionen auf hoher Ebene
vereinfachen.
Den Projektträgern, Entwicklungsteams und anderen Stakeholdern ein klares Verständnis der Struktur des
Zielsystems auf hoher Ebene vermitteln.
|
Die Architekturübersicht wird in einem frühen Stadium eines Projektlebenszyklus, unter Umständen bereits in der
Konzeptionsphase erstellt. Die Architekturübersicht vermittelt die frühen Entscheidungen und Arbeitsannahmen für die
Implementierung der Vision sowie Entscheidungen, die die physische und logische Architektur und nicht funktionale
Anforderungen an das System betreffen. Sie wird vom Softwarearchitekten, häufig in Zusammenarbeit mit dem
Projektträger, in Form eines formlosen, reich bebilderten Storyboards oder eines Diagramms mit vielen Symbolen
entwickelt. Konzeptionell veranschaulicht die Architekturübersicht die wesentliche Charakteristik der vorgeschlagenen
Lösung und vermittelt die Leitideen einschließlich der Hauptbausteine. Der Grad der Formalität der Architekturübersicht
ist projektabhängig. In einem großen, sehr formellen Projekt kann es beispielsweise erforderlich sein, die
Architekturübersicht in den entsprechenden Abschnitten des Softwarearchitekturdokuments zu erfassen, damit es formell
geprüft werden kann.
Zu diesem Zeitpunkt ist die Architekturübersicht ein erster provisorischer Ansatz. Machen Sie keine Zusagen auf der
Basis des Architekturübersichtsdiagramms, bis die Architektur, einschließlich Design, Implementierung und Deployment
durch einen ausführbaren Architekturprototyp validiert wurde.
Prüfen Sie, ob Sie die Architektur auf einer Referenzarchitektur, anderen Architekturmustern oder anderen Architektur-Assets aufbauen können.
Überlegen Sie, ob Sie das Übersichtsdiagramm zur Architektur präzisieren und pflegen möchten, um es als
Kommunikationsmittel einzusetzen.
Viele Systeme müssen in einer vorhandenen Umgebung von Hardware und Software entwickelt und eingesetzt werden. Für
solche Systeme muss der Softwarearchitekt Informationen zur aktuellen Umgebung zusammentragen.
Bei der Entwicklung eines e-business-Systems sind beispielsweise die folgenden Informationen relevant:
-
vorhandenes logisches und physisches Design des Netzes
-
vorhandene Datenbanken und Datenbankdesign
-
vorhandene Web-Umgebung (Servers, Firewalls usw.)
-
vorhandene Serverumgebung (Konfiguration, Softwareversionen, geplante Upgrades)
-
vorhandene Standards (Netz, Benennung, Protokolle usw.)
Solche Informationen können in Textform oder in einem Deployment-Modell erfasst werden.
|
Verfügbare Assets begutachten
Zweck:
|
Assets identifizieren, die für das Projekt relevant sein können.
Tauglichkeit der Assets und Lücke zwischen Assets und Projektanforderungen analysieren.
Entscheiden, ob bestimmte Bereiche des Systems auf den verfügbaren Assets aufbauen sollen.
Assets ermitteln und auflisten, die potenziell im Projekt wiederverwendet werden können.
Eine vorläufige Auswertung durchführen, um sicherzustellen, dass die erforderliche Unterstützung
potenziell verfügbar ist.
|
Sie müssen die Anforderungen der Umgebung, für die Assets in Erwägung gezogen werden, sowie den Systemumfang und die
generell erforderliche Funktionalität verstehen. Durchforschen Sie den Assetstamm der Organisation und die
Branchenliteratur, um Assets oder ähnliche Projekte zu finden. Es gibt verschiedene Arten von Assets, die
berücksichtigt werden müssen, z. B. Industriemodelle, Frameworks, Klassen und Erfahrungen. Sie müssen auswerten, ob
verfügbare Assets zur Lösung der Schlüsselanforderungen des aktuellen Projekts betragen können und ob sie mit den
Projektvorgaben kompatibel sind.
Sie müssen die Tauglichkeit der Assets in Bezug auf die Kundenanforderungen analysieren und überlegen, ob die
Anforderungen verhandelbar sind (um die Assets einsetzen zu können).
Stellen Sie fest, ob ein Asset geändert oder erweitert werden muss, um den Anforderungen zu genügen, und welche
Kompromisse in Bezug auf Kosten, Risiken und Funktionalität getroffen werden müssen, wenn das Asset eingesetzt wird.
Schließlich müssen Sie entscheiden, ob ein oder mehrere Assets verwendet werden, und die Begründung für Ihre
Entscheidung dokumentieren.
|
Organisation von Subsystemen auf hoher Ebene definieren
Zweck
|
Eine erste Struktur für das Designmodell erstellen.
|
Wenn der Fokus auf der Durchführung einer Architektursynthese in der Konzeptionsphase liegt, ist dieser Schritt von der
Aufgabe ausgeschlossen.
Normalerweise wird das Designmodell in Schichten aufgebaut - als allgemeines Architekturmuster für die mittlere bis große Systeme. Die Anzahl der Schichten ist
nicht fix, sondern variiert von Fall zu Fall.
Während der Architekturanalyse konzentrieren Sie sich gewöhnlich auf die beiden Ausgangsschichten, d. h. die
Anwendungs- und die geschäftsspezifische Schicht. Damit erklärt sich auch der Begriff Organisation von
Subsystemen auf hoher Ebene. Die anderen untergeordneten Schichten werden in der Aufgabe: Vorhandene Designelemente integrieren behandelt. Wenn Sie
spezielle Architekturmuster verwenden, werden die Subsysteme auf der Basis der Architekturvorlage für dieses Muster
definiert.
Weitere Informationen zur Schichtung finden Sie in Richtlinie für
Arbeitsprodukt: Schichtung.
|
Schlüsselabstraktionen identifizieren
Zweck
|
Analyse vorbereiten, indem die Schlüsselabstraktionen (Darstellung von Konzepten, die in den Aufgaben für
die Geschäftsmodellierung und Anforderungsaufgaben ermittelt wurden) identifiziert werden, die das System
behandeln muss.
|
Wenn der Fokus auf der Durchführung der Architektursynthese liegt, wird dieser Schritt so weit ausgeführt, dass der
Softwarearchitekt eine Anleitung für die Auswahl der Assets für die Erstellung der Architekturmachbarkeitsstudie hat und repräsentative
Verwendungsszenarios erstellt werden können.
Die Aufgaben in den Bereichen Anforderungen und Geschäftsmodellierung decken gewöhnlich die Schlüsselkonzepte auf, die
das System erfüllen muss. Diese Konzepte manifestieren sich als Schlüsseldesignabstraktionen. Da diese Arbeiten bereits
ausgeführt wurden, ist es nicht erforderlich, die Ermittlungsarbeiten während der Anwendungsfallanalyse zu wiederholen.
Sie können vorhandenes Wissen nutzen, indem Sie vorläufige Entitätsanalyseklassen, die diese Schlüsselabstraktionen
darstellen, auf der Basis allgemeiner Kenntnisse über das System, wie z. B. Anforderungen, das Glossar und
insbesondere das Domänenmodell oder das Geschäftsanalysemodell (sofern vorhanden), identifizieren.
Wenn Sie die Schlüsselabstraktionen definieren, müssen Sie auch alle vorhandenen Beziehungen zwischen den
Entitätsklassen definieren. Stellen Sie die Schlüsselabstraktionen in einem oder mehreren Klassendiagrammen dar und
erstellen Sie für jede eine Kurzbeschreibung. Je nach Domäne und Neuheit des Systems sind unter Umständen Analysemuster vorhanden, die viele der für die Modellierung des Systems
erforderlichen Schlüsselabstraktionen bereits beschreiben. Die Verwendung solcher Muster (die bereits erfolgreich in
der Domäne eingesetzt worden sein müssen) vereinfacht die Aufgabe, wichtige darzustellende Konzepte zu identifizieren,
erheblich. [FOW97a] stellt einige Analysemuster vor, die hilfreich für die Modellierung von
Geschäftssystemen sind, aber möglicherweise auch in anderen Kontexten eingesetzt werden können. Ein weiteres Beispiel
ist die Object Management Group (OMG), die durch die Arbeit ihres Domain Technology Committee und zugehöriger
Arbeitsgruppen ebenfalls versucht, Schnittstellen und Protokolle für viele Domänen zu definieren. Diese Arbeit führt
unweigerlich zur Identifizierung wichtiger Abstraktionen in der Domäne.
Die Analyseklassen, die zu diesem Zeitpunkt identifiziert sind, werden im Verlauf des Projekts wahrscheinlich geändert
und weiterentwickelt. Der Zweck dieses Schritts ist nicht, eine Gruppe von Klassen zu identifizieren, die das ganze
Design "überleben", sondern die Schlüsselkonzepte zu ermitteln, die das System erfüllen muss. Verbringen Sie nicht zu
viel Zeit damit, Entitätsklassen zu diesem Zeitpunkt im Detail zu beschreiben, weil das Risiko besteht, dass Sie
Klassen und Beziehungen finden, die von den Anwendungsfällen eigentlich nicht benötigt werden. Denken Sie daran, dass
Sie während der Untersuchung der Anwendungsfälle noch weitere Entitätsklassen und Beziehungen finden.
|
Stereotype Interaktionen identifizieren
Dieser Schritt muss nur während der Konzeptionsphase ausgeführt werden.
Mit diesem Schritt werden die Interaktionen zwischen Schlüsselabstraktionen im System ermittelt, die relevante Arten
von Aktivitäten im System charakterisieren bzw. darstellen. Diese Interaktionen werden als Anwendungsfallrealisierungen
erfasst.
|
Deployment-Übersicht entwickeln
Zweck
|
Grundlage für die Bewertung der Durchführbarkeit der Systemimplementierung bereitstellen.
Verständnis für die geografische Verteilung und Komplexität des Systems gewinnen.
Grundlage für frühe Aufwands- und Kostenschätzungen bereitstellen.
|
Entwickeln Sie eine Übersicht auf hoher Ebene, die zeigt, wie die Software eingesetzt wird (Deployment). Stellen Sie
beispielsweise fest, ob das System über Remote-Zugriff zugänglich sein muss oder Anforderungen vorliegen, die eine
Verteilung der Software auf mehrere Knoten nahe legen. Hierbei zu berücksichtigende Informationsquellen sind unter
anderem:
-
Benutzer (an Standorten), die in Benutzerprofilen (in der Vision) und Anwendungsfällen (im Anwendungsfallmodell)
definiert sind,
-
Organisation der Geschäftsdaten (im Geschäftsanalysemodell und im Designmodell, sofern vorhanden),
-
Service-Level-Anforderungen (in den ergänzenden Spezifikationen),
-
Vorgaben (in den ergänzenden Spezifikationen, z. B. Anforderungen bezüglich Schnittstellen zu traditionellen
Systemen).
Wenn ein nicht unbedeutendes verteiltes System erforderlich ist, können mit einem Deployment-Modell die Beziehungen
zwischen den Knoten erfasst werden. Hierbei müssen Sie Komponenten und Daten vorläufig zu Knoten zuordnen und angeben,
wie Benutzer auf die Komponenten zugreifen, die auf die Daten zugreifen. Die detaillierte Spezifikation der Knoten und
Verbindungen wird vertagt, es sei denn, sie ist für die Schätzung oder Bewertung der Durchführbarkeit erforderlich. Es
können vorhandene Assets verwendet werden, sofern entsprechende verfügbar sind. Obwohl dies das erste Deployment-Modell
ist, das im Projekt erzeugt wird, und obwohl es in relativ kurzer Zeit produziert wird, kann es vermitteln, welche
Hardware- und Softwareprodukte tatsächlich vorhanden sind (sofern diese bekannt sind) und ob diese
Auswahlentscheidungen zum jetzigen Zeitpunkt getroffen werden müssen.
Prüfen Sie, ob das Deployment-Modell Benutzer (insbesondere Benutzer an fernen Standorten, falls dies erforderlich ist)
unterstützt, die typische Anwendungsfälle ausführen, und gleichzeitig nicht funktionale Anforderungen und Vorgaben
erfüllt. Prüfen Sie, ob die Knoten und Verbindungen geeignet sind, die Interaktionen zwischen Komponenten auf
unterschiedlichen Knoten und zwischen Komponenten und ihren gespeicherten Daten zu unterstützen.
|
Analysemechanismen identifizieren
Zweck
|
Die Analysemechanismen und -services definieren, die Designer verwenden, um ihre Objekte zu erstellen.
|
Wenn der Fokus auf der Durchführung einer Architektursynthese in der Konzeptionsphase liegt, ist dieser Schritt von der
Aufgabe ausgeschlossen.
Analysemechanismen können durch Top-Down- (A-priori-Wissen) oder Bottom-up-Verfahren (während der Arbeit) identifiziert
werden. Im Top-down-Modus weiß der Softwarearchitekt aus Erfahrung, dass bestimmte Probleme in der Domäne vorliegen,
und muss bestimmte Arten von Lösungen finden. Beispiele für allgemeine Architekturprobleme, die in Form von Mechanismen
während der Analyse ausgedrückt werden können, sind Persistenz, Transaktionsmanagement, Fehlermanagement,
Nachrichtenübertragung und Inferenzeinheiten. Die Gemeinsamkeit dieser Mechanismen besteht darin, dass sie jeweils eine
allgemeine Fähigkeit vieler Systeme darstellen und jeweils Funktionalität bereitstellen, die mit der Funktionalität der
Basisanwendung interagiert bzw. diese unterstützt. Die Analysemechanismen unterstützen Fähigkeiten, die in
grundlegenden funktionalen Anforderungen des Systems erforderlich sind, unabhängig von der Deployment-Plattform oder
der Implementierungssprache. Analysemechanismen können auf verschiedene Arten entworfen und implementiert werden. Im
Allgemeinen gibt es für jeden Analysemechanismus mehrere Designmechanismen und möglicherweise mehrere Möglichkeiten,
jeden dieser Designmechanismen zu implementieren.
Beim Bottom-up-Ansatz werden die Analysemechanismen letztendlich "geboren". Sie werden erstellt, wenn der
Softwarearchitekt, vielleicht erst auch nur ansatzweise ein gemeinsames Thema in einer Gruppe von Lösungen für
verschiedene Probleme erkennt. Es muss eine Möglichkeit gefunden werden, dass Elemente in unterschiedlichen Threads
ihre Uhren aufeinander abstimmen können, und es muss eine gemeinsame Lösung für die Reservierung von Ressourcen
gefunden werden. Diesen Mustern entspringen Analysemechanismen, die die Sprache der Analyse vereinfachen.
Das Identifizieren eines Analysemechanismus bedeutet, dass Sie ein allgemeines, vielleicht implizites (insofern, als
die Anforderungen für das System es implizieren) Teilproblem erkennen und benennen. Zunächst kann der Name alles sein,
was vorhanden ist, z. B. wenn der Softwarearchitekt erkennt, dass das System einen Persistenzmechanismus benötigt.
Letztendlich wird dieser Mechanismus durch die Kollaboration einer Gesellschaft von Klassen (siehe [BOO98]) implementiert, von denen einige nicht direkt Anwendungsfunktionalität
liefern, sondern nur zur Unterstützung existieren. Sehr häufig befinden sich diese 'Unterstützungsklassen' in den
mittleren und unteren Schichten einer geschichteten Architektur und stellen damit einen allgemeinen
Unterstützungsservice für alle Klassen auf Anwendungsebene dar.
Wenn das identifizierte Teilproblem allgemein genug ist, können unter Umständen Muster vorhanden
sein, aus denen der Mechanismus instanziert werden kann, indem die vorhandenen Klassen gebunden und neue Klassen, die
das Muster erfordert, implementiert werden. Ein so erzeugter Analysemechanismus ist abstrakt und muss durch Design und
Implementierung optimiert werden.
Weitere Informationen finden Sie in Konzept:
Analysemechanismen.
|
Ergebnisse prüfen
Zweck
|
Sicherstellen, dass die Ergebnisse der Architekturanalyse vollständig und konsistent sind.
|
Zum Abschluss der Architekturanalyse müssen die identifizierten Architekturmechanismen, die Subsysteme, Pakete und
Klassen überprüft werden, um sicherzustellen, dass sie vollständig und konsistent sind. Da die Ergebnisse der
Architekturanalyse vorläufig und relativ formlos sind, sollten die Überprüfungen ebenfalls formlos sein. Für die
Validierung der Architekturauswahl auf den verschiedenen Ebenen - von der Geschäftsperspektive bis in zu den
spezifischen Interaktionen - können Szenarios oder Anwendungsfälle verwendet werden.
Weitere Informationen zur Auswertung der Ergebnisse dieser Aufgabe finden Sie in Softwarearchitekturdokument - Hinweise zur Architekturanalyse.
|
|