Konzept: Softwarearchitektur
Die Softwarearchitektur stellt die Struktur bzw. Strukturen des Systems dar, die sich aus Softwarekomponenten, den extern sichtbaren Eigenschaften dieser Komponenten und den Beziehungen zwischen ihnen zusammensetzt.
Beziehungen
Hauptbeschreibung

Einführung

Softwarearchitektur ist ein Konzept, das zwar leicht zu verstehen ist und dass die meisten Entwickler, insbesondere mit ein wenig Erfahrung intuitiv erfassen, das sich aber schwierig präzise definieren lässt. Es ist besonders schwierig, eine klare Linie zwischen Design und Architektur zu ziehen. Architektur ist ein Aspekt des Designs, der sich auf einige bestimmte Merkmale konzentriert.

In ihrem Buch An Introduction to Software Architecture behaupten David Garlan und Mary Shaw, dass Softwarearchitektur eine Designstufe ist, die sich mit Aspekten befasst, die über die Algorithmen und Datenstrukturen der Berechnung hinausgehen. Zitat: "Beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives." [GAR93]

Architektur ist jedoch mehr als nur Struktur. Die IEEE Working Group on Architecture definiert Architektur wie folgt: "the highest-level concept of a system in its environment" [IEP1471]. Architektur umfasst auch die "Tauglichkeit" für die Systemintegrität, die wirtschaftlichen Einschränkungen, ästhetische Aspekte und Stil. Sie richtet sich nicht nur nach inneren Schwerpunkten, sondern betrachtet das System als Ganzes in seiner Benutzerumgebung und seiner Entwicklungsumgebung.

In Rational Unified Process (RUP) besteht die Architektur des Softwaresystems (zu einem gegebenen Zeitpunkt) aus der Organisation oder Struktur der wichtigen Komponenten; diese Komponenten wiederum setzen sich aus kleineren Komponenten und Schnittstellen zusammen.

Architekturbeschreibung

Bevor Sie über die Softwarearchitektur sprechen können, muss die Darstellung definiert werden, in der wichtige Aspekte der Architektur beschrieben werden können. In RUP wird diese Beschreibung im Softwarearchitekturdokument erfasst.

Architektursichten

Wir haben uns für die Darstellung der Softwarearchitektur in mehreren Architektursichten entschieden. Jede Architektursicht bezieht sich auf eine bestimmte Gruppe aus Überlegungen von Stakeholdern im Entwicklungsprozess: Benutzer, Entwickler, Manager, Systemberater, Wartungspersonal etc.

Die Sichten erfassen die wichtigsten strukturellen Designentscheidungen und zeigen, wie die Softwarearchitektur in Komponenten zerlegt wird und wie die Komponenten durch Konnektoren verbunden werden, um nützliche Formen zu bilden [PW92]. Diese Designentscheidungen müssen an die Anforderungen - funktionale und ergänzende - und andere Einschränkungen gebunden werden. Diese Entscheidungen wiederum bedeuten weitere Einschränkungen für die Anforderungen und für künftige Designentscheidungen auf niedrigerer Ebene.

Typische Architektursichten

Architektur wird in einer Reihe unterschiedlicher Architektursichten dargestellt, bei den es sich im Prinzip um Extrakte handelt, die die "architektonisch relevanten" Elemente der Modelle veranschaulichen. In RUP können Sie mit einer typischen Gruppe von Sichten, dem so genannten "4+1-Sichtmodell" [KRU95] beginnen. Diese Gruppe setzt sich wie folgt zusammen:

  • Die Anwendungsfallsicht enthält Anwendungsfälle und Szenarios, die sich auf architektonisch relevante Verhalten, Klassen oder technische Risiken beziehen. Sie ist eine Teilgruppe des Anwendungsfallmodells.
  • Die logische Sicht enthält die wichtigsten Designklassen und ihre Strukturierung in Pakete und Subsysteme sowie die Strukturierung dieser Pakete und Subsysteme in Schichten. Sie enthält außerdem einige Anwendungsfallrealisierungen. Sie ist eine Teilgruppe des Designmodells.
  • Die Implementierungssicht enthält eine Übersicht über das Implementierungsmodell und die Strukturierung der Modellmodule in Pakete und Schichten. Die Zuordnung der Pakete und Klassen (aus der logischen Sicht) zu den Paketen und Modulen der Implementierungssicht wird ebenfalls beschrieben. Die Implementierungssicht ist eine Teilgruppe des Implementierungsmodells.
  • Die Prozesssicht enthält die Beschreibung der beteiligten Aufgaben (Prozess und Threads), ihrer Interaktionen und Konfigurationen sowie der Zuordnung von Designobjekten und Klassen zu Aufgaben. Diese Sicht muss nur verwendet werden, wenn das System einen hohen Grad von Parallelität aufweist. In RUP ist diese Sicht eine Teilgruppe des Designmodells.
  • Die Deployment-Sicht enthält die Beschreibung der verschiedenen physischen Knoten für die typischsten Plattformkonfigurationen und der Zuordnung von Aufgaben (aus der Prozesssicht) zu den physischen Knoten. Diese Sicht muss nur verwendet werden, wenn das System ein verteiltes System ist. Sie ist eine Teilgruppe des Deployment-Modells.

Die Architektursichten werden in einem Softwarearchitekturdokument dokumentiert. Sie können sich weitere Sichten ausdenken, um verschiedene besondere Problemstellungen zu beschreiben: Benutzerschnittstellensicht, Sicherheitssicht, Datensicht usw. Für einfache Systeme können Sie einige der Sichten aus dem 4+1-Sichtenmodell weglassen.

Fokus auf die Architektur

Obwohl die zuvor beschriebenen Sichten das gesamte Design eines Systems darstellen könnten, beschäftigt sich die Architektur nur mit einigen speziellen Aspekten:

  • der Struktur des Modells - den Organisationsmustern, z. B. Schichtung,
  • den wesentlichen Elementen - kritischen Anwendungsfällen, Hauptklassen, allgemeinen Mechanismen usw. (in Gegensatz zu der Gesamtheit der im Modell enthaltenen Elemente),
  • ein paar Schlüsselszenarios, die die Hauptsteuerungsflüsse im System zeigen,
  • den Services zum Erfassen der Modularität, optionaler Features und produktspezifischer Aspekte.

Im Wesentlichen sind Architektursichten Abstraktionen oder Vereinfachungen des Gesamtdesigns, in denen wichtige Merkmale sichtbarer gemacht werden, indem Details weggelassen werden. Diese Merkmale sind wichtig, wenn Sie sich über Folgendes Gedanken machen:

  • Systemweiterentwicklung - Übergang in den nächsten Entwicklungszyklus.
  • Wiederverwendung der Architektur oder Teilen davon im Kontext der Produktlinie.
  • Bewertung ergänzender Qualitäten, z. B. Leistung, Verfügbarkeit, Portierbarkeit und Sicherheit.
  • Verteilung der Entwicklungsarbeiten auf Teams oder Unterauftragnehmer.
  • Entscheidungen über die Verwendung von gebrauchsfertigen Komponenten.
  • Einbindung in ein größeres System.

Architekturmuster

Architekturmuster sind gebrauchsfertige Formen, die wiederholt auftretende Architekturprobleme lösen. Ein Architekturframework oder eine Architekturinfrastruktur (Middleware) sind Komponenten, auf deren Basis Sie eine bestimmte Art von Architektur erstellen können. Viele der vorrangigen architektonischen Schwierigkeiten können innerhalb des Frameworks oder der Infrastruktur behoben werden, das bzw. die gewöhnlich für eine bestimmte Domäne bestimmt ist: Befehl und Steuerung, MIS, Steuerungssystem usw.

Beispiele für Architekturmuster

[BUS96] gruppiert Architekturmuster nach den Merkmalen der Systeme, in denen sie sich am besten eignen, wobei sich eine Kategorie mit eher generellen Strukturierungsproblemen beschäftigt. Die folgende Tabelle zeigt die Kategorien, die in [BUS96] beschrieben werden, und die Muster, die darin enthalten sind.

Kategorie Muster
Struktur Schichten
Pipes und Filter
Blackboard
Verteilte Systeme Broker
Interaktive Systeme Model View Controller (MVC)
Presentation Abstraction Control (PAC)
Anpassbare Systeme Reflexion
Mikro-Kernel

Zwei dieser Architekturmuster werden hier ausführlicher vorgestellt, um die Ideen zu verdeutlichen. Eine vollständige Erläuterung finden Sie in [BUS96]. Muster werden gewöhnlich wie folgt dargestellt:

  • Mustername
  • Kontext
  • Problem
    • Kräfte, die verschiedene Problemaspekte beschreiben, die zu berücksichtigen sind.
  • Lösung
    • Begründung
    • Resultierender Kontext
    • Beispiele
Mustername

Schichten

Kontext

Ein großes System, das zerlegt werden muss.

Problem

Ein System, das Probleme auf unterschiedlichen Abstraktionsebenen behandeln muss, z. B. Hardwaresteuerung, allgemeine Services und domänenspezifische Probleme. Es wäre in höchstem Maße unerwünscht, vertikale Komponenten zu erstellen, die Probleme auf allen Ebenen behandeln. Dasselbe Probleme würde mehrfach (und möglicherweise inkonsistent) in verschiedenen Komponenten behandelt.

Kräfte

  • Teile des Systems sollen ersetzbar sein.
  • Änderungen in Komponenten sollen sich nicht verbreiten.
  • Ähnliche Zuständigkeiten sollen gruppiert werden.
  • Größe der Komponenten. Komplexe Komponenten müssen möglicherweise zerlegt werden..
Lösung

Strukturieren Sie die Systeme in Gruppen von Komponenten, die aufeinander aufbauende Schichten bilden. Die oberen Schichten dürfen nur Services der unteren Schichten (niemals der oberen Schichten) verwenden. Versuchen Sie, keine anderen Services zu verwenden als die in der direkt untergeordneten Schicht (überspringen Sie Schichten nur, wenn die zwischengelagerten Schichten lediglich Passthrough-Komponenten bereitstellen).

Beispiele:

1. Generische Schichten

Im Begleittext beschriebene Abbildung

Eine streng geschichtete Architektur dokumentiert, dass Designelemente (Klassen, Pakete, Subsysteme) nur die Services der direkt untergeordneten Schicht verwenden. Services können sich auf ereignisgesteuerte Verarbeitung, Fehlerbehandlung, Datenbankzugriff usw. beziehen. Sie enthält konkretere Mechanismen im Gegensatz zu reinen Aufrufen auf Betriebssystemebene, die in der untersten Schicht dokumentiert sind.

2. Geschäftssystemschichten

Im Begleittext beschriebene Abbildung

Die vorherige Abbildung zeigt ein weiteres Beispiel für Schichtung, in dem vertikale anwendungsspezifische Schichten und horizontale Infrastrukturschichten verwendet werden. Das Ziel ist, sehr kurze "Dienstwege" zu haben und Gemeinsamkeiten von Anwendungen zu nutzen.  Andernfalls haben Sie mehrere Personen, die dasselbe Problem auf möglicherweise unterschiedliche Weise lösen.

Ausführliche Informationen zu diesem Muster finden Sie auf der Seite Richtlinie: Schichtung.

Mustername

Blackboard

Kontext

Eine Domäne, in der kein geschlossener (algorithmischer) Ansatz für die Lösung eines Problems bekannt oder durchführbar ist. Beispiele hierfür sind AI-Systeme, Spracherkennung und Überwachungssysteme.

Problem

Mehrere Problemlösungsagenten (Wissenagenten) müssen zusammenarbeiten, um ein Problem zu beheben, das von keinem der Agenten allein behoben werden kann. Die Arbeitsergebnisse der einzelnen Agenten muss allen zur Verfügung stehen, damit sie beurteilen können, ob sie etwas zur Problemlösung beitragen können, und Ergebnisse ihrer Arbeit bereitstellen können.

Kräfte

  • Die Reihenfolge, in der Wissensagenten zur Problemlösung beitragen können, ist nicht deterministisch und kann von den Problemlösungsstrategien abhängig sein.

  • Eingaben unterschiedlicher Agenten (Ergebnisse oder Teillösungen) können unterschiedliche Darstellungen haben.

  • Agenten haben keine direkte Kenntnis voneinander, können aber die bereitgestellten Beiträge der anderen auswerten.

Lösung

Eine Reihe von Wissensagenten haben Zugriff auf einen gemeinsam genutzten Datenspeicher, das so genannte Blackboard. Das Blackboard besitzt eine Schnittstelle, über die der Inhalt des Blackboards untersucht und aktualisiert werden kann. Das Steuermodul bzw. Steuerobjekt aktiviert die Agenten nach einer bestimmten Strategie. Sobald ein Agent aktiviert wird, untersucht er das Blackboard, um festzustellen, ob er etwas zur Problemlösung beitragen kann. Wenn der Agent feststellt, dass er etwas beizutragen hat, kann das Steuerungsobjekt dem Agenten erlauben, seine Teil- bzw. Endlösung im Board zu veröffentlichen.

Beispiel:

Im Begleittext beschriebene Abbildung

Diese Abbildung zeigt die mit UML modellierte strukturelle oder statische Sicht. Diese ist Teil einer parametrisierten Kollaboration, die dann an tatsächliche Parameter gebunden wird, um das Muster zu instanzieren.

Architekturstil

Eine Softwarearchitektur oder eine Architektursicht kann ein Attribut Architekturstil haben, das die Gruppe auswählbarer Formen eingrenzt und der Architektur einen gewissen Grad von Einheitlichkeit auferlegt. Der Stil kann mit einer Gruppe von Mustern oder durch Auswahl spezieller Komponenten oder Konnektoren als Basisbausteine definiert werden. Für jedes System kann ein Teil des Stils im Rahmen der Architekturbeschreibung in einem Architektur-Styleguide erfasst werden, der im RUP-Arbeitsergebnis  Projektspezifische Richtlinien bereitgestellt wird. Der Stil spielt eine wichtige Rolle, was die Verständlichkeit und die Integrität der Architektur betrifft.

Architekturentwürfe

Die grafische Darstellung einer Architektursicht ist ein Architekturentwurf. Für die zuvor beschriebenen Sichten setzen sich die Entwürfe aus den folgenden UML-Diagrammen [UML01]:

  • Logische Sicht. Klassendiagramme, Zustandsmaschinen und Objektdiagramme.
  • Prozesssicht. Klassendiagramme und Objektdiagramme (einschließlich Aufgaben, Prozessen und Threads)
  • Implementierungssicht. Komponentendiagramme.
  • Deployment-Sicht. Deployment-Diagramme.
  • Anwendungsfallsicht. Anwendungsfalldiagramme, die Anwendungsfälle, Akteure und herkömmliche Designklassen zeigen. Ablaufdiagramme, die Designobjekte und ihre Kollaboration zeigen.

Der Architekturprozess

In RUP ist die Architektur primär ein Ergebnis des Analyse- & Designworkflows. Da das Projekt diesen Workflow in jeder Iteration wiederholt, wird die Architektur mit der Zeit präzisiert und verfeinert. Da jede Iteration Integration und Test umfasst, ist die Architektur bei Auslieferung des Produkts relativ stabil. Diese Architektur ist einer der Hauptschwerpunkte in den Iterationen der Ausarbeitungsphase, an deren Ende normalerweise eine Referenzversion der Architektur erstellt wird.