Aufgabe: Architekturanalyse
Diese Aufgabe befasst sich schwerpunktmäßig mit der Definition einer geeigneten Architektur und der Einschränkung der im System verwendeten Architekturtechniken.
Zweck
  • Eine geeignete Architektur für das System basierend auf den Erfahrungen definieren, die in ähnlichen Systemen oder ähnlichen Problemdomänen gewonnen wurden.
  • Architekturmuster, Schlüsselmechanismen und Modellierungskonventionen für das System definieren.
Beziehungen
Hauptbeschreibung

Die Architekturanalyse befasst sich schwerpunktmäßig mit der Definition einer geeigneten Architektur und der Einschränkung der im System verwendeten Architekturtechniken. Sie stützt sich auf die Erfahrungen, die in ähnlichen Systemen oder Problemdomänen gefunden wurden, um die Architektur so einzuschränken und zu kanalisieren, dass nicht vergeblich Arbeit in "Neuerfindungen" investiert wird. In Systemen, in denen es bereits eine klar definierte Architektur gibt, kann die Architekturanalyse weggelassen werden. Die Architekturanalyse ist in erster Linie hilfreich, wenn neue oder noch nie dagewesene Systeme entwickelt werden.

Schritte
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.



Eigenschaften
Mehrere Vorkommen
Ereignisgesteuert
Fortlaufend
Optional
Geplant
Wiederholt anwendbar
Weitere Informationen