02.2 - Software Architekturen

Warum werden 'Konnektoren' in vielen Architekturmodellen als eigenständiges Grundelement neben der Komponente geführt?

Weil sie die explizite Verpflichtung übernehmen, die syntaktische und semantische Korrektheit der Verbindung zwischen Schnittstellen zu prüfen.

Welcher Zusammenhang besteht zwischen dem 'Gesamtimport' eines Systems und den Importen seiner Teilkomponenten?

Der Gesamtimport des Systems ergibt sich aus der Summe aller Importe der enthaltenen Komponenten, die nicht durch interne Verbindungen aufgelöst wurden.

Was ist die architekurelle Bedeutung der 'Common Parameters' einer Konfiguration?

Sie stellen die Schnittmenge der Eigenschaften dar, die von allen Komponenten innerhalb einer Konfiguration sowohl importiert als auch exportiert werden.

Wie unterscheidet sich ein 'Delegation Connector' von einem 'Assembly Connector' in einem UML-Komponentendiagramm?

Ein Delegation Connector verbindet einen äußeren Port einer Komponente mit einem internen Port, während ein Assembly Connector zwei interne Ports miteinander verknüpft.

Warum ist das 'Publish-Subscribe'-Muster ungeeignet, wenn Komponenten nicht eindeutig in Sender und Empfänger unterteilt werden können?

Da das Muster auf einer gerichteten Informationsverbreitung basiert, bei der Empfänger sich explizit bei bekannten Sendern anmelden müssen.

Inwiefern unterscheiden sich 'Batch-Sequential' und 'Pipes-and-Filters' hinsichtlich der Parallelität?

• Bei Batch-Sequential erfolgt die Verarbeitung streng nacheinander in abgeschlossenen Paketen

• Bei Pipes-and-Filters alle Komponenten gleichzeitig als Datenstrom arbeiten können.

Weitere UML-Diagramme mit Bezug zur Architektur

Kompositionsstrukturdiagramm • Quasi eine Verallgemeinerung von Komponentendiagrammen • Ports wie bisher • Konnektoren: Diesmal mit frei definierbarer Semantik • Parts: Können Instanzen von Klassen oder Komponenten sein • Kollaborationen: Menge von Parts oder Operationen, die ein Verhalten realisieren • Rollen: Zuordnung von Eigenschaften zu einer Menge von Instanzen • Ermöglichen vermischte Darstellung von Struktur und Verhalten

Paketdiagramm • Beschreibung der Softwarestruktur aus Entwicklersicht • Spezifiziert Verknüpfung („import", „access" und „merge") von Paketen

Kommunikationsdiagramm • Dynamische Sicht auf Verhalten • Fokussiert Richtung und zeitliche Reihenfolge von Nachrichten

Deployment-Diagramm • Zuordnung von Software-Komponenten zu Hardware-Ressourcen • Kann zwischen Geräten („device") und Ausführungsumgebungen („execution environment") unterscheiden • Kann Komponentenparameter als „deployment spec" abbilden

Architekturstile für implizite Aufrufe Pro/Contra

Vorteile: • Effiziente Verbreitung von Informationen in eine Richtung • Sehr lose Kopplung der beteiligten Komponenten • Informationen, für die es keinen Empfänger gibt, brauchen gar nicht erst bereitgestellt zu werden • Individuelle Verschlüsselung von Nachrichten möglich

Nachteile: • Hohe Anzahl an Empfängern für einen Sender erfordert spezielle Kommunikationsprotokolle

was sind Architekturstile

Architekturstile sind bewährte Sammlungen von Design-Entscheidungen, die in einem bestimmten Entwicklungskontext angewendet werden.

Sie dienen dazu, die Struktur und die Kommunikationsmuster eines Systems festzulegen, um die Wiederverwendbarkeit zu erhöhen und die Softwarequalität zu verbessern.

Architekturstile für implizite Aufrufe

Diese Stile werden oft verwendet, wenn Komponenten lose gekoppelt sein sollen und auf Ereignisse reagieren:

• Publish-Subscribe: Komponenten werden in Sender und Empfänger unterteilt. Empfänger melden sich bei Sendern an und erhalten Benachrichtigungen (Broadcast), wenn neue Informationen vorliegen.

• Event-based: Alle Komponenten kommunizieren über einen gemeinsamen Kanal (Event-Bus). Jeder schickt Nachrichten (Events) auf den Bus und liest nur die für ihn relevanten Informationen.

Architekturstile für den Datenfluss

Hier liegt der Fokus darauf, wie Daten durch das System geleitet und transformiert werden:

• Batch-Sequential: Jede Aufgabe wird von einer Komponente komplett abgeschlossen, bevor das Ergebnis als Datenpaket an die nächste Komponente weitergegeben wird. Es gibt keine Parallelität.

• Pipes-and-Filters: Komponenten (Filter) arbeiten parallel und sind durch Leitungen (Pipes) verbunden. Die Informationen fließen als kontinuierlicher Datenstrom von einer Komponente zur nächsten (bekannt z. B. von der Unix-Kommandozeile).