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