Richtlinie: Softwarearchitekturdokument
Diese Richtlinie enthält einen Überblick über das Softwarearchitekturdokument.
Beziehungen
Hauptbeschreibung

Referenzen

Der Abschnitt für die Referenzliteratur stellt externe Dokumente vor, die wichtige Hintergrundinformationen für das Verständnis der Systemarchitektur liefern. Sind viele Referenzen angegeben, sollte der Abschnitt in Unterabschnitte unterteilt werden:

  1. externe Dokumente
  2. interne Dokumente
  3. Dokumente von Regierungsstellen
  4. Dokumente von Nichtregierungsstellen
  5. etc.

Ziele und Einschränkungen der Architektur

Die Architektur wird unter Berücksichtigung der folgenden Punkte aufgebaut:

  • Funktionale Anforderungen, die im Anwendungsfallmodell erfasst sind
  • Nicht funktionale Anforderungen, die in den ergänzenden Spezifikationen erfasst sind.

Dies sind jedoch nicht die einzigen Faktoren, die die Architektur beeinflussen. Es gibt Einschränkungen, die vorgegeben werden: durch die Umgebung, in der die Software ausgeführt werden muss, die Notwendigkeit, Assets wieder zu verwenden, die Verwendung verschiedener Standards, die Notwendigkeit der Kompatibilität mit vorhandenen Systemen usw. Möglicherweise gibt es auch vorab definierte Architekturprinzipien und -Policys als Leitfaden für die Entwicklung, die für das Projekt ausgearbeitet und verifiziert werden sollen. In diesem Abschnitt des Softwarearchitekturdokuments werden diese Ziele und Einschränkungen sowie alle Entscheidungen die Architektur betreffend, die sich aus ihnen ergeben und nicht an anderer Stelle als Anforderungen formuliert sind, beschrieben. 

Wenn dieses Dokument erstellt ist, ist die Spezifikation der Implementierungsumgebung eine wichtige Eingabe. Beispiele für die anzugebenden Größen: Zielplattform (Hardware, Betriebssystem), Fenstertechnik, Entwicklungstools (Sprache, GUI-Erstellungsprogramm), Datenbankmanagementsystem und Komponentenbibliotheken. Es ist auch nützlich, anzugeben, welche Technologien für Benutzerschnittstellen zulässig sind und welche nicht. Viele Systeme verzichten darauf, bestimmte Darstellungstechnologien zu verwenden (JavaScript, Applets, Frames, XML etc.), damit mehr Clientsysteme die Anwendung nutzen können oder die Entwicklung der Anwendung vereinfacht wird. Die Entscheidungen werden hier im Softwarearchitekturdokument erfasst, während die Details für die Verwendung und die Anwendung der ausgewählten Technologien in den  projektspezifischen Richtlinien dokumentiert werden.

Die Umsetzung dieser Entscheidungen wird erzielt durch die Formulierung von Kriterien zur Bewertung der Architektur, die als Teil der Iterationsauswertung verwendet werden.

Die Bewertungskriterien werden von Änderungsfällen abgeleitet, die angeben, in welchen Bereichen zukünftige Änderungen wahrscheinlich sind:

  • Funktionen und Merkmale des Systems
  • Art und Weise, in der das System verwendet wird
  • Betriebs- und Unterstützungsumgebungen des Systems.

Änderungsfälle erläutern die Systemmerkmale, die in den nachfolgenden Sätzen subjektiv wie folgt beschrieben werden: einfach zu erweitern, einfach zu portieren, einfach zu verwalten, solide bei Änderungen und einfach zu entwickeln. Die Änderungsfälle konzentrieren sich darauf, was wichtig und wahrscheinlich ist anstatt auf das, was möglich ist.

Mit Änderungsfällen wird versucht, Änderungen vorauszusagen. Diese Voraussagen sind selten zu 100 Prozent exakt.

Die Merkmale eines Systems werden von Benutzern, Sponsoren, Lieferanten, Entwicklern und anderen Stakeholdern bestimmt. Änderungen können sich aus vielen Quellen ergeben. Beispiele:

  • Geschäftliche Faktoren: neue Geschäftsprozesse und -ziele
  • Technologische Faktoren: Anpassung des Systems an neue Plattformen, Integration in neue Komponenten
  • Änderungen in den Profilen des Durchschnittsbenutzers
  • Änderungen in den Integrationsanforderungen andere Systeme betreffend
  • Änderungen des Umfangs, die sich aus der Migration der Funktionalität aus externen Systemen ergeben

Anwendungsfallsicht

Die Anwendungsfallsicht stellt eine Untergruppe zum Arbeitsergebnis: Anwendungsfallmodell dar und beinhaltet die Anwendungsfälle des Systems, die für die Architektur wichtig sind. Sie beschreibt die Gruppe der Szenarios und/oder Anwendungsfälle, die einige zentrale Funktionen umfassen. Ferner beschreibt die Anwendungsfallsicht die Gruppe der Szenarios und/oder Anwendungsfälle, die einen großen Bereich der Architektur abdecken (d. h., viele Elemente der Architektur ausführen) oder einen spezifischen, sensiblen Punkt der Architektur hervorheben bzw. veranschaulichen.

Ist das Modell größer, ist es normalerweise in Pakete gegliedert. Zum besseren Verständnis sollte auch die Anwendungsfallsicht, falls möglich, in Pakete gegliedert sein. Geben Sie für jeden bedeutenden Anwendungsfall einen Unterabschnitt mit den folgenden Informationen an:

  1. Den Namen des Anwendungsfalls.
  2. Eine Kurzbeschreibung des Anwendungsfalls.
  3. Wichtige Beschreibungen der Ereignisabfolge des Anwendungsfalls. Das kann die gesamte Beschreibung der Ereignisabfolge sein, es können aber auch Unterabschnitte der Beschreibung sein, die sich auf wichtige Abfolgen oder Szenarios des Anwendungsfalls konzentrieren.
  4. Wichtige Beschreibungen von Beziehungen einschließlich des Anwendungsfalls, z. B. Einschluss- und Erweiterungsbeziehungen oder Kommunikationsassoziationen mit Richtungsangabe.
  5. Eine Aufzählung der wichtigen Anwendungsfalldiagramme, die sich auf den Anwendungsfall beziehen.
  6. Wichtige Beschreibungen der besonderen Anforderungen des Anwendungsfalls. Das kann die gesamte Beschreibung der besonderen Anforderungen sein, es können aber auch Unterabschnitte der Beschreibung sein, die sich auf wichtige Anforderungen konzentrieren.
  7. Wichtige Bilder der Benutzerschnittstelle, die den Anwendungsfall transparenter gestalten.
  8. Die Realisierungen dieser Anwendungsfälle sollten in der logischen Sicht zu finden sein.

Logische Sicht

Die logische Sicht ist eine Untergruppe zum Arbeitsergebnis: Designmodell, das Designelemente zeigt, die für die Architektur wichtig sind. Sie beschreibt die wichtigsten Klassen, ihre Gliederung in Pakete und Subsysteme sowie die Gliederung dieser Pakete und Subsysteme in Schichten. Sie beschreibt auch die wichtigsten Realisierungen der Anwendungsfälle, z. B. die dynamischen Aspekte der Architektur.

Bein einem komplexen System sind möglicherweise mehrere Abschnitte zur Beschreibung der logischen Sicht erforderlich:

  1. Überblick

    Dieser Unterabschnitt beschreibt die Gliederung des gesamten Designmodells hinsichtlich der Pakethierarchie und der Schichten. Wenn das System mehrere Paketebenen verwendet, sollten Sie zunächst die wichtigsten Pakete auf der höchsten Ebene beschreiben. Nehmen Sie alle Diagramme in die Beschreibung auf, die Pakete auf der höchsten Ebene, deren gegenseitige Abhängigkeiten und die Anordnung der Schichten zeigen. Nennen Sie dann alle wichtigen Pakete, die in diesen Paketen enthalten sind usw., bis sie alle wichtigen Pakete bis hin zur untersten Ebene der Hierarchie genannt haben.

  2. Designpakete, die für die Architektur wichtig sind

    Geben Sie für jedes wichtige Paket einen Unterabschnitt mit den folgenden Informationen an:

    1. Den Namen.
    2. Eine Kurzbeschreibung.
    3. Ein Diagramm, in dem alle im Paket enthaltenen wichtigen Klassen und Pakete dargestellt sind. Zum besseren Verständnis zeigt dieses Diagramm, falls erforderlich, vielleicht einige Klassen aus anderen Paketen.
    4. Geben Sie für jede wichtige Klasse im Paket den Namen, eine kurze Beschreibung und, optional, eine Beschreibung einiger ihrer wichtigsten Zuständigkeiten, Operationen und Attribute an. Beschreiben Sie, falls nötig, auch ihre wichtigen Beziehungen, um die enthaltenen Diagramme zu verstehen.
  3. Anwendungsfallrealisierungen

    In diesem Abschnitt wird mit wenigen ausgewählten Realisierungen von Anwendungsfällen (oder Szenarien) veranschaulicht, wie die Software tatsächlich funktioniert und wie verschiedene Elemente des Designmodells zu ihrer Funktionalität beitragen. In diesem Abschnitt sind die Anwendungsfälle oder Szenarios aus dem Anwendungsfallmodell aufgelistet, sofern sie wichtige, zentrale Funktionen des Endsystems darstellen oder sich auf einen großen Teil der Architektur auswirken, d. h., wenn sie viele Elemente der Architektur ausführen bzw. einen bestimmten Punkt der Architektur hervorheben oder veranschaulichen. Die entsprechenden Anwendungsfälle und Szenarios zu diesen Realisierungen können in der Anwendungsfallsicht ermittelt werden.

    Geben Sie für jede wichtige Anwendungsfallrealisierung einen Unterabschnitt mit den folgenden Informationen an:

    1. Den Namen des realisierten Anwendungsfalls.
    2. Eine Kurzbeschreibung des realisierten Anwendungsfalls.
    3. Wichtige Beschreibungen der Ereignisabfolge (Design) der Anwendungsfallrealisierung. Das kann die gesamte Beschreibung der Ereignisabfolge (Design) sein, es können aber auch Unterabschnitte der Beschreibung sein, die sich auf die Realisierung wichtiger Abfolgen oder Szenarios des Anwendungsfalls konzentrieren.
    4. Eine Aufzählung der wichtigen Interaktionen oder Klassendiagramme, die sich auf die Anwendungsfallrealisierung beziehen.
    5. Wichtige Beschreibungen der abgeleiteten Anforderungen der Anwendungsfallrealisierung. Das kann die gesamte Beschreibung der abgeleiteten Anforderungen sein, es können aber auch Unterabschnitte der Beschreibung sein, die sich auf wichtige Anforderungen konzentrieren.

Designelemente, die für die Architektur wichtig sind

Nachfolgend ein paar Beispiele für qualifizierende Elemente und deren Merkmale, die helfen, zu bestimmen, was für die Architektur wichtig ist:

  • Ein Modellelement, das eine wichtige Abstraktion der Aufgabendomäne kapselt. Beispiele:
    • Einen Flugplan in einem Flugsicherungssystem
    • Einen Mitarbeiter in einem Lohnbuchhaltungssystem
    • Einen Abonnenten in einem Telefonsystem.

Untertypen müssen nicht notwendigerweise aufgenommen werden. Beispiel: ICAO-Standardflugplan von Plan der US-Inlandsflüge zu unterscheiden, ist nicht wichtig, beide Einträge bezeichnen Flugpläne und nutzen eine wesentliche Menge von Attributen und Operationen gemeinsam.

Einen Abonnenten mit einer Datenleitung von einem Abonnenten mit einer Sprachübertragungsverbindung zu unterscheiden, ist nicht nötig, wenn die Rufsteuerung auf etwa dieselbe Art und Weise erfolgt.

  • Ein Modellelement, das von vielen anderen Modellelementen verwendet wird.
  • Ein Modellelement, das einen wichtigen Mechanismus (Service) des Systems kapselt.
  • Designmechanismen
    • Persistenzmechanismus (Repository, Datenbank, Speicherverwaltung).
    • Kommunikationsmechanismus (RPC, Broadcasting, Broker-Service).
    • Fehlerbehandlungs- oder Wiederherstellungsmechanismus.
    • Anzeigemechanismus und andere allgemeine Schnittstellen (Fenstertechnik, Datenerfassung, Anzeigemechanismen, Setzen von Signalbedingungen usw.).
    • Mechanismen für die Parameterangabe.

Allgemein kann man sagen, dass jeder Mechanismus wahrscheinlich in vielen verschiedenen Paketen verwendet wird (im Gegensatz zur internen Verwendung im Paket), daher empfiehlt es sich, eine einzige, für das gesamte System einheitliche Implementierung zu verwenden, oder zumindest eine einzige Schnittstelle, die verschiedene alternative Implementierungen verdeckt.

  • Ein Modellelement, das im System an einer wichtigen Schnittstelle zu folgenden Komponenten beteiligt ist:
    • Einem Betriebssystem
    • Einem gebrauchsfertigen Produkt (System mit Fenstertechnik, RDBMS, geographisches Informationssystem)
    • Einer Klasse, die ein Architekturmuster (z. B. Muster für das Entkoppeln von Modellelementen einschließlich des Musters für Modellsicht-Controller oder des Broker-Musters) implementiert oder unterstützt.
  • Ein Modellelement, das nur lokal sichtbar ist, jedoch möglicherweise eine große Wirkung auf die Gesamtleistung des Systems hat, z. B.:
    • Ein Abfragemechanismus zum Scannen von Sensoren mit einer sehr hohen Geschwindigkeit
    • Ein Tracing-Mechanismus für die Fehlerbehebung
    • Ein Prüfpunktmechanismus für ein System mit hoher Verfügbarkeit (Prüfpunkt und Neustart)
    • Eine Startsequenz
    • Eine Onlineaktualisierung des Codes
    • Eine Klasse, die einen neuartigen und technisch riskanten Algorithmus kapselt, oder ein Algorithmus, der kritisch für die Sicherheit ist, z. B. bei der Berechnung des Bestrahlungsniveaus, bei den Kriterien zur Vermeidung von Flugzeugkollisionen in überfüllten Lufträumen, bei der Kennwortverschlüsselung.

Die Kriterien für die Wichtigkeit bezüglich der Architektur werden in den ersten Iterationen des Projekts entwickelt, wenn Sie technische Schwierigkeiten feststellen und sich mit dem System vertraut machen. Als Faustregel gilt, dass sie höchstens 10 % der Modellelemente als wichtig für die Architektur kennzeichnen sollten. Andernfalls gehen Sie das Risiko ein, das Konzept der Architektur zu verwässern.

Wenn sie die Modellelemente, die für die Architektur wichtig sind, definieren und in die logische Sicht aufnehmen, sollten Sie auch die folgenden Aspekte berücksichtigen.

  • Identifizieren Sie das Potenzial für gemeinsame Verwendung und Wiederverwendung. Welche Klassen sollten Unterklassen einer allgemeine Klasse oder Instanzen derselben parametrisierten Klasse sein?
  • Identifizieren Sie das Potenzial für die Parameterangabe. Welcher Teil des Designs kann durch die Verwendung von statischen und Laufzeitparametern (z. B. tabellengesteuertes Verhalten, Laden der Ressourcendaten beim Start) flexibler oder für die Wiederverwendbarkeit geeigneter gestaltet werden?
  • Identifizieren Sie das Potenzial für die Verwendung gebrauchsfertiger Produkte.

Prozesssicht

Die Prozesssicht beschreibt die Prozessstruktur des Systems. Da die Prozessstruktur sich stark auf die Architektur auswirkt, sollten alle Prozesse dargestellt werden. In Prozessen müssen nur Lightweight-Threads, die für die Architektur wichtig sind, dargestellt werden. Die Prozesssicht beschreibt die Aufgaben (Prozesse und Threads), die an der Systemausführung beteiligt sind, deren Interaktionen und Konfigurationen, sowie die Zuordnung von Objekten und Klassen zu Aufgaben.

Geben Sie für jedes Prozessnetz einen Unterabschnitt mit den folgenden Informationen an:

  1. Den Namen.
  2. Die beteiligten Prozesse.
  3. Die Interaktionen zwischen Prozessen in Form von Kommunikationsdiagrammen, in denen die Objekte tatsächliche Prozesse sind, die ihre eigenen Steuer-Threads umfassen. Beschreiben Sie für jeden Prozess das Verhalten, die Lebensdauer und die Kommunikationsmerkmale.

Deployment-Sicht

In diesem Abschnitt werden eine oder mehrere physische Netzkonfigurationen (Hardware) für das Deployment und die Ausführung der Software beschrieben. Außerdem wird die Zuordnung von Aufgaben (in der Prozesssicht) zu den physischen Knoten beschrieben. Geben Sie für jede Konfiguration eines physischen Netzes einen Unterabschnitt mit den folgenden Informationen an:

  1. Den Namen.
  2. Ein Deployment-Diagramm, das die Konfiguration veranschaulicht, gefolgt von einer Zuordnung von Prozessen zu den einzelnen Prozessoren.
  3. Sind viele physische Konfigurationen möglich, beschreiben Sie nur eine typische Konfiguration und erläutern Sie die allgemeinen Zuordnungsregeln für die Definition weiterer Konfigurationen. In den meisten Fällen sollten Sie auch Beschreibungen von Netzkonfigurationen für die Durchführung von Softwaretests und Simulationen aufnehmen.

Die Sicht wird aus dem Arbeitsergebnis: Deployment-Modell generiert.

Implementierungssicht

Dieser Abschnitt beschreibt die Unterteilung der Software in Schichten und Subsysteme im Implementierungsmodell. Er enthält auch einen Überblick über die Zuordnung von Designelementen (aus der logischen Sicht) zur Implementierung. Er enthält zwei Unterabschnitte:

  1. Überblick

    Dieser Unterabschnitt benennt und definiert die verschiedenen Schichten und deren Inhalt, die Regeln für die Aufnahme in eine bestimmte Schicht sowie die Grenzwerte zwischen den Schichten. Nehmen Sie ein Komponentendiagramm auf, das die Beziehungen zwischen den Schichten veranschaulicht.

  2. Schichten

    Geben Sie für jede Schicht einen Unterabschnitt mit den folgenden Informationen an:

    1. Den Namen.
    2. Ein Komponentendiagramm, das die Implementierungssubsysteme und deren Importabhängigkeiten darstellt.
    3. Eine Struktur der Beziehung der Schicht zu Elementen in der logischen oder der Prozesssicht.
    4. Eine Aufzählung der in der Schicht befindlichen Implementierungssubsysteme. Gehen Sie für jedes Implementierungssubsystem wie folgt vor:
      • Geben Sie den Namen, den Kurznamen und eine Kurzbeschreibung des Implementierungssubsystems an sowie eine Begründung für seine Existenz:
      • Geben Sie, falls passend, die Beziehung des Implementierungssubsystems zu den Elementen in der logischen oder Prozesssicht an. In vielen Fällen implementiert ein Implementierungssubsystem ein oder mehrere Designsubsysteme aus der logischen Sicht.
      • Wenn ein Implementierungssubsystem andere, für die Architektur wichtige Implementierungssubsysteme und/oder
        Verzeichnisse enthält, sollten Sie in Erwägung ziehen, dies in der Hierarchie der Unterabschnitte darzustellen.
      • Wenn das Implementierungssubsystem 1:1 mit einem Implementierungsverzeichnis übereinstimmt, müssen Sie erläutern, wie das Implementierungssubsystem im Kontext der Implementierungsverzeichnisse und/oder Dateien definiert ist.

Datensicht

Diese Sicht ist nur relevant für Systeme, die mit datenbankgestützter Persistenz arbeiten. Sie beschreibt die persistenten, für die Architektur wichtigen Elemente im Datenmodell. Außerdem bietet sie eine Übersicht über das Datenmodell und seine Gliederung in Tabellen, Sichten, Indizes, Auslöser und gespeicherte Prozeduren, mit denen Persistenz für das System bereitgestellt wird. Sie beschreibt die Zuordnung persistenter Klassen (aus der logischen Sicht) zur Datenstruktur der Datenbank.

Dazu gehört normalerweise Folgendes:

  • Die Zuordnung persistenter wichtiger Designklassen, insbesondere in den Fällen, in denen die Zuordnung anspruchsvoll ist.
  • Die Systemabschnitte, die für die Architektur wichtig sind, werden in der Datenbank in Form gespeicherter Prozeduren und Auslöser implementiert.
  • Wichtige Entscheidungen in anderen Sichten, die sich auf Daten auswirken, z. B. die Auswahl der Transaktionsstrategie, die Verteilung, die Parallelität, die Fehlertoleranz. Beispielsweise erfordert der Einsatz der datenbankbasierten Transaktionsverwaltung (zum Festschreiben oder Abbrechen von Transaktionen), dass den in der Architektur verwendeten Mechanismus zur Fehlerbehandlung eine Wiederherstellungsstrategie für den Fall einer fehlerhaften Transaktion beinhaltet. Die Wiederherstellung erfolgt über die Aktualisierung des im Speicher der Anwendung zwischengespeicherten Status der Persistenzobjekte.

Sie sollten Datenmodellelemente, die für die Architektur wichtig sind, nennen und deren Zuständigkeiten beschreiben. Ferner sollten Sie einige wenige, sehr wichtige Beziehungen und Verhaltensweisen (Auslöser, gespeicherte Prozeduren etc.) nennen und beschreiben.

Größe und Leistung

Dieser Abschnitt beschreibt die Merkmale zur Definition der Architektur, die sich auf den Umfang und die Reaktionsfähigkeit des Systems beziehen. Die dargestellten Informationen umfassen die folgenden Punkte:

  • Die Anzahl der Schlüsselelemente, die das System handhaben muss. Beispiele: Anzahl der parallel stattfindenden Flüge für ein Flugsicherungssystem, die Anzahl parallel stattfindender Anrufe für einen Telefonschalter, die Anzahl gleichzeitig aktiver Onlinebenutzer des Buchungssystems einer Fluggesellschaft usw.
  • Die wichtigsten Kenngrößen für die Systemleistung: durchschnittliche Antwortzeit für Schlüsselereignisse, durchschnittliche, maximale und minimale Durchsatzgeschwindigkeit usw.
  • Der Speicherbedarf (Platte und Hauptspeicher) der ausführbaren Programme. Das ist wesentlich, wenn es sich um ein eingebettetes System handelt, das extrem restriktive Vorgaben meistern muss.

Die meisten dieser Eigenschaften werden als Anforderungen erfasst. Sie werden hier genannt, weil sie die Architektur wesentlich formen und einen besonderen Fokus erlauben. Diskutieren Sie für jede Anforderung die Frage, wie die Architektur diese Anforderung unterstützt.

Qualität

Listen Sie in diesem Abschnitt die wichtigen Dimensionen für die Systemqualität auf, die die Architektur formen. Die dargestellten Informationen umfassen die folgenden Punkte:

  • Anforderungen für die Betriebsleistung, z. B. die mittlere Zeit zwischen auftretenden Fehlern (Mean-Time Between Failure, MTBF).
  • Qualitätsziele, z. B.: keine ungeplante Ausfallzeit
  • Ziele zur Erweiterbarkeit, z. B.: Upgrade für die Software kann während des laufenden Systembetriebs durchgeführt werden
  • Ziele für die Portierbarkeit, z. B. Hardwareplattformen, Betriebssysteme, Sprachen.

Diskutieren Sie für jede Kenngröße die Frage, wie die Architektur diese Anforderung unterstützt. Sie können den Abschnitt nach verschiedenen Sichten (logische Sicht, Implementierungssicht usw.) oder nach Qualität aufbauen. Wenn bestimmte Merkmale im System wichtig sind, z. B. Sicherheit oder Vertraulichkeit, sollte die Unterstützung dieser Merkmale durch die Architektur in diesem Abschnitt sorgfältig dargestellt werden.