POSA 1 - Part 1
Pattern Oriented Software Architecture
Pattern Oriented Software Architecture
Kartei Details
Karten | 11 |
---|---|
Sprache | Deutsch |
Kategorie | Informatik |
Stufe | Universität |
Erstellt / Aktualisiert | 29.12.2015 / 04.02.2025 |
Weblink |
https://card2brain.ch/box/layerspattern
|
Einbinden |
<iframe src="https://card2brain.ch/box/layerspattern/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
Layers-Pattern
Kontext
Ein grosses Anwendungssystem, welches strukturiert werden soll. Bekanntes Beispiel: OSI-Layer.
Problem
Ein System soll aus unterschiedlichen High- und Low-Level Funktionen erstellt werden.
Lösung
Die Anwendung soll in Layers aufgeteilt werden, wobei Layering eine horizontale Aufteilung der Anwendung darstellt. Layer einer höheren Schicht dürfen nur auf die Layers von den unteren Schichten zugreifen. In der Regel dürfen diese nur auf den direkt darunterliegenden Layer zugreifen. Dieser leitet die Anfragen anschliessend ggf. an den erneut darunterliegenden Layer weiter.
Layering Trough Inheritance
Tiefere Layer implementieren deren Funktionalität als Basisklassen. Höhere Layer leiten von diesen Klassen ab und können dadurch das Verhalten anpassen. Dadurch entsteht jedoch eine sehr starke Kopplung, daher ist davon abzuraten.
Pipe and Filters
Das Pipes and Filters Patterns (oder Data Flow Architektur) wird bei Anwendungen die Datenströme verarbeiten angewendet. Die einzelnen Verarbeitungsschritten entsprechen den Filtern. Die Pipes, welche jeweils zwei Filter verbinden, stellen den Datenstrom zwischen den Filtern dar. Die einzelnen Filter sollten unabhängig realisiert werden und haben keine Abhängigkeit untereinander. Dadurch wird eine hohe Flexibilität erreicht.
Lösung:
Die Aufgaben eines Systems werden in einzelne sequentielle Prozessschritte unterteilt. Jeder einzelne Prozessschritt wird als Filter implementiert, welcher einen Datenstrom entgegen nimmt, verarbeitet und zu einem ausgehenden Datenstrom führt. Die Quelle (Pump) der Daten, die Filterkomponente sowie die Senke (Verbraucher) sind jeweils
durch eine Pipe verbunden.
Für die Kommunikation zwischen den Filtern sollte ein uniformes Datenformat etabliert werden. Dadurch können die Filter unabhängig zum vorherigen Filter kombiniert werden. Die Transformation in das Datenformat kann jedoch zu grossem Overhead führen.
Complex
Bei dieser Varianten sind sämtliche Filter aktiv. Die Pipes unterstützen ein Buffern der Daten. Die einzelnen Filter laufen in einem eigenen Thread und arbeiten die Daten immer so lange ab, solange Daten in der Pipe verfügbar sind. Jeder
Filter verarbeitet solange Daten, bis die Pipe leer ist, in diesem Fall wartet dieser auf eingehende Daten.
Tee and join pipeline sytems
Tee (dt. Verzweigung/Abzweigung)
Normale Pipeline-Systeme unterstützen pro Filter nur einen Input sowie Output. Das Tee and Join Pipeline System kann mehrere Outputs sowie Inputs für einen Filter erlauben. Dadurch ist es möglich, dass ein einziger Filter mehrere Outputs hat. Ein anderer Filter ist jedoch auf den Input aus ggf. mehreren Filtern angewiesen.
Blackboard
Das Blackboard Architectural Pattern ist sehr nützlich, wenn man Probleme lösen will, für die keine deterministische Lösungsstrategie bekannt ist. Mehrere spezialisierte Subsysteme tragen ihr Wissen zusammen, um eine mögliche Lösung oder annähernde Teillösung zu erarbeiten. Beispiel: Ein System welches Sprachbefehle erkennen kann, besteht aus diversen Teilaufgaben.
Kontext
Softwaresysteme, die grosse und vielfältig spezialisierte Module integrieren, um komplexe, nichtdeterministische Probleme zu erarbeiten.
Problem
Der Prozess der Spracherkennung (als Beispiel) ist abhängig von vielen Zwischenresultaten, die man nur mit gewissen Kompetenzen weiterverarbeiten kann. Es muss ein Weg gefunden werden, wie diese «Partial Problem Solvers» ihr wissen kombinieren können.
Forces
• Verschiedene spezialisierte Algorithmen lösen unterschiedliche Teilprobleme. Sie sind unabhängig voneinander
• Da das Gebiet nicht ausgereift ist, muss man eventuell mit verschiedenen Algorithmen für das gleiche Teilproblem experimentieren
• Der Input, zwischenliegende- und Endresultate haben unterschiedliche Darstellungen und die Algorithmen sind auf gewisse Muster implementiert
• Ein Algorithmus arbeitet mit dem Resultat eines anderen Algorithmus
• Es muss mit unzuverlässigen und annähernden Inputs gerechnet werden. (Beispiel Spracherkennung: Unterscheidung zwischen «two» und «too» ist schwer zu bestimmen. Auch Störgeräusche erschweren den Prozess. Konkurrierende Alternativen der Eingabe können an allen Stellen auftauchen.)
Lösung
Die Idee des Blackboard ist es, dass mehrere unabhängige Programme kooperativ an einer gemeinsamen Lösung arbeiten. Die spezialisierten Programme sind unabhängig und rufen sich nicht gegenseitig auf. Auch kann man die Aktivierungsreihenfolge der Programme nicht im Voraus bestimmen. Der Name kommt von der Wandtafel, an welcher
verschiedene Experten eine Lösung erarbeiten. Jeder Experte analysiert für sich die Situation und könnte zu jeder Zeit an die Wandtafel gehen, um Daten hinzuzufügen, zu löschen oder abzuändern. Im Gegensatz zu Menschen, welche selber entscheiden würden, wenn es Zeit für sie ist, an die Tafel zu gehen, wird dies beim Blackboard Pattern durch eine Moderator Komponente entschieden.
Blackboard Struktur
Struktur
Für das Blackboard Pattern werden drei verschiedene Komponenten benötigt, das Blackboard selbst, eine Sammlung von "Knowledge Sources" und eine Control"Komponente. Im folgenden werden diese kurz beschrieben.
Blacboard
Das Blackboard dient als zentraler gemeinsamer Datenspeicher. Der Begriff "Vocabulary" wird für die Sammlung von Datenelementen verwendet die auf dem Blackboard erscheinen können. Vom Blackboard wird ein Interface angeboten das allen "Knowledge Sourcen" ermöglicht darauf zu schreiben und zu lesen. Lösungen die während dem Problemlösungsprozess entstehen werden auf das Blackboard gelegt, sie nennt sie "Hypothesis". Eine solche Hypothese hat ein Abstraktionslevel welcher die konzeptionelle Distanz vom Input darstellt. Ein tiefer Abstraktionslevel bedeutet man hat eine Repräsentation die näher beim Input ist, ein hoher dass man näher beim Output ist.
Knowledge Sources
Knowledge Sources sind Subsysteme die spezifische Aspekte des Gesamtproblems lösen. Keine Knowledge Source kann das Gesamtproblem selbst lösen, dies ist nur durch zusammenführen aller Teillösungen möglich. Sie kommunizieren nicht direkt untereinander, sondern schreiben und lesen nur auf dem Blackboard. Jede Knowledge Source muss die Bedingungen kennen unter welchen sie zur Lösung beitragen kann, deshalb werden sie unterteilt in einen Condition und einen Action Teil. Der Condition Teil evaluiert anhand dem das auf dem Blackboard steht, ob zur Lösung beigetragen werden kann. Der Action Teil produziert dann eine neue Teillösung.
Control
Die Control Komponente läuft in einer Schlaufe die den Inhalt des Blackboards überwacht und entscheidet was als nächstes ausgeführt werden soll. Die Entscheidungen basieren eventuell auf Berechnungen die von speziellen Knowledge Sources ausgeführt werden. Die folgende Grafik zeigt das Zusammenspiel der einzelnen Komponenten: