Softwarearchitektur verteilter Systeme

Transkript

1 Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung Vorlesung Wintersemester 2002 / 03 Technische Universität München Institut für Informatik Lehrstuhl von Prof. Dr. Manfred Broy Dr. Klaus Bergner, Prof. Dr. Manfred Broy, Dr. Andreas Rausch, Dr. Marc Sihling

2 Inhalt Musterbasierte Architekturen (Pattern) Muster Wieso, weshalb, warum? Design-Muster Architekturmuster Analysemuster Bewertung Referenzarchitekturen Produktlinienarchitekturen Zusammenfassung Literaturhinweise Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.2

4 Muster Wieso, weshalb, warum? Klassen sind sehr kleine Einheiten, deren Wiederverwendung steigert die Produktivität kaum. Datenbanken, Middleware und COTS-Komponenten ermöglichen Wiederverwendung auf der Ebene von ausführbaren, binären Komponenten. Frameworks und Bibliotheken unterstützen lediglich die Wiederverwendung von Programmcode. Aspect-oriented programming und Codegeneratoren unterstützen die Wiederverwendung von spezifischen Lösungsansätzen auf der Implementierungsebene. Wiederverwendung von Spezifikationen, Design und Entwurfswissen? Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.4

5 Analogien Etablierten Ingenieur-Disziplinen verfügen über Handbücher, in denen Lösungen und Lösungsvarianten für so manche bekannten und immer wiederkehrenden Probleme stehen. So entwickeln Automobilbauer ihre Fahrzeuge nicht immer neu auf der Basis physikalischer Gesetze, sie modifizieren und adaptieren bewährte Lösungen. Der Zugewinn an Performance bei einer vollständigen neuen Entwicklung ist selten kostendeckend. Soll das Software-Engineering und die Disziplin Softwarearchitektur eine Ingenieursdisziplin sein, dann müssen erfolgreiche Methoden systematisch dokumentiert, aufgearbeitet und verbreitet werden. Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.5

6 Ursprung des Musteransatzes Der Begriff Pattern als Lösungsmuster, das Lösungsansätze für ähnliche bzw. sich wiederholende Designprobleme bietet, geht zurück auf den Architekten Christopher Alexander [Ale77]. Beispiel Window Place [Ale77]: Jeder liebt Aussichtsplätze in Hochhäusern, auf Bergen oder am Meer Wenn man in einen Raum kommt der Fenster und Sitzplätze hat, die Sitzplätze aber nicht bei den Fenster sind, dann steht man vor folgendem Problem: - Man möchte sich hinsetzten, um es bequem zu haben - Man möchte möglichst in der Nähe des Lichts sein Jeder Raum, in dem man sich länger aufhält sollte mindestens einen Window Place haben Sitzplätze vor dem Fenster Every pattern we define must be formulated in the form of a rule which establishes a relationship between a context, a system of forces which arises in that context and a configuration, which allows these forces to resolve themselves in that context. [Ale79] Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.6

7 Muster sind Lösungsbeschreibungen Ein Designproblem beruht darauf, dass in gewissen Situationen (Kontext), sich widerstrebende Kräfte (Problem) entgegenstehen. Die Lösung besteht darin, mit den in der jeweiligen Designdisziplin zur Verfügung stehenden Werkzeugen die Situation so zu gestalten, dass diese Kräfte optimal ausgeglichen werden. In der klassischen Architektur ist dies die räumliche Gestaltung von Gebäuden In der Softwarearchitektur ist dies die Struktur der Komponenten und deren Beziehungen Ein Muster beschreibt eine Lösung für ein Designproblem Muster sind konstruktiv, d.h. sie liefern Instruktionen zur Lösung einer Problemsituation Muster sind abstrakt, d.h. sie bieten ein breites Anwendungsspektrum mit vielen verschiedenen Anwendungsfällen Muster sind stabil, d.h. sie erfassen den stabilen Kern der Lösung Muster sind über die Zeit hinweg gültig und weitestgehend invariant gegenüber neuen Möglichkeiten Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.7

8 Struktur und Beschreibung von Mustern Ein Muster besteht aus einem Kontext bzw. Situation in dem ein wiederkehrendes Design-Problem auftritt, das durch eine generische, bewährte Lösung gemeistert werden kann. Muster werden beschrieben mit: Musterschablonen geben eine einheitliche Struktur vor, die sich in Kontext, Problem, Lösung und entsprechende Unterpunkte aufteilt Jeder Gliederungspunkte der Musterschablone wird dann mit Freitext und Diagrammen ausgestaltet Muster werden in vielen Disziplinen entwickelt und verwendet, zum Beispiel im Bauwesen, in der Medizin, beim Ölbohren oder in der Softwareentwicklung Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.8

9 Mustersammlungen Musterkataloge sind eine einfache meist kategorisierte Sammlungen ähnlicher oder komplementärer Muster. Eine Mustersprache bildet eine Einheit, in der die zusammenhängenden Muster miteinander kooperieren, um ein gemeinsames Problem zu lösen. Mustersysteme umfassen eine Menge von Mustern auf verschiedenen Abstraktionsstufen. Die Beziehungen zwischen den Mustern beschreiben, wie sich durch die Kombination der Muster Lösungen komplexerer Probleme konstruieren lassen. In der Regel entwickelt sich aus einem Musterkatalog eine Mustersprache und eventuell dann ein Mustersystem. Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.9

10 Architekturmuster Ein Architekturmuster stellt ein Lösungsschema für ein Problem im Architekturentwurf dar. Es umfasst Strukturen und Verhalten, die durch Teildefinitionen von Komponenten, Klassen, Methoden, Vererbungs- und Komponentenbeziehungen sowie erklärenden Text beschrieben werden. Wiederverwendung von bewährten Entwürfen Qualitativ bessere Entwürfe Dokumentation von Entwurfsentscheidungen Effizientere Kommunikation durch ein Standardvokabular Das Verstehen der Software wird verbessert Wissensaufbau und Erhaltung Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.10

12 Design-Muster Buch Design Patterns von Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides (Gang of Four, GoF) 1995 Einführung in das Gebiet der Entwurfsmuster: Definition, Beschreibung von Mustern, Verwendung von Mustern Fallstudie Dokumenteneditor für die Anwendung von Mustern Katalog von 23 Entwurfsmustern, jedes mit mindestens zwei Einsatzbeispielen Ziel: Hilfsmittel für den objektorientierten Entwurf im Kleinen Wie kann man effiziente und flexible Mechanismen entwerfen? Wie findet man Klassen und Operationen für technische Probleme? Wie können die Objekte sinnvoll miteinander interagieren? Wie implementiert man die vorgeschlagenen Mechanismen? Wie kann man den Code übersichtlich und wartbar strukturieren? Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.12

13 Beschreibungsschema Bezeichnung und Überblick Name Kurzbeschreibung, Zweck alternative Bezeichnungen Zweck Motivation und Zielsetzung Anwendbarkeit Lösung graphische Beschreibung der Struktur beteiligte Klassen Interaktion Konsequenzen Vor- und Nachteile Implementierung und Beispiel-Code Anwendungsbeispiele Bezug zu anderen Mustern Name Kontext Problem Lösung Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.13

14 Composite Muster (1) Name: Composite Zweck: Repräsentiere baumartige Hierarchien mit Hilfe von Objekten. Auf einfache und zusammengesetzte Objekte kann in der gleichen Weise zugegriffen werden. Motivation: Dudel! Graphik Instanzendiagramm Klassendiagramm Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.14

15 Composite Muster (2) Anwendbarkeit: Darstellung von Hierarchien (Whole-Part-Structures) Für Clients soll kein Unterschied in der Schnittstelle von zusammengesetzten und einfachen Objekten sein Struktur: Instanzendiagramm Klassendiagramm Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.15

16 Composite Muster (3) Teilnehmer: Component (Graphic): - Definiert gemeinsame Schnittstelle von einfachen und zusammengesetzten Objekten - Implementiert im Einzelfall nötiges Standardverhalten für alle Klassen - Optional: definiert Schnittstelle für Zugriff auf den Vaterknoten Leaf (Rectangle, Line, Text): - Repräsentiert einfache Objekte ohne Kinderknoten - Implementiert das Verhalten einfacher Objekte Composite (Picture): - Implementiert das Verhalten zusammengesetzer Objekte - Speichert (Verweise auf) Kind-Objekte - Implementiert Operationen für Management der Kinder (Hinzufügen, Löschen,...) Client: - Manipuliert hierarchische Strukturen über die Schnittstelle der Klasse Component Interaktion: Vaterknoten können Aufträge an ihre Kinder weiterleiten und davor/danach noch eigene Operationen durchführen Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.16

17 Composite Muster (4) Vor- und Nachteile: + Einheitliche Schnittstelle für Clients erlaubt es, Clients einfach zu halten + Neue Component-Klassen können leicht über Vererbung hinzugefügt werden, ohne dass die Clients geändert werden müssen Über die uniforme Schnittstelle zum Einfügen beliebiger Component-Objekte können beliebige Baumstrukturen erzeugt werden; Einschränkungen müssen über Runtime-Checks durchgeführt werden Implementierung: Referenzen von Kindern zu ihrem Vaterknoten Sharing von Component-Objekten Breite der Schnittstelle von Component addchild/deletechild-operationen Caching... Beispiel-Code:... Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.17

18 Composite Muster (5) Anwendungsbeispiele: ET++ Vobjects InterViews Glyphs RTL Smalltalk Compiler Expressions... Bezug zu anderen Mustern: Chain of Responsibility Decorator Flyweight Iterator Visitor Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.18

19 Visitor Muster (1) Name: Visitor Zweck: Führe auf jedem Objekt einer Struktur eine bestimmte Operation aus. Definiere neue Operationen, ohne die Klassen der Struktur zu ändern. Motivation: Operationen auf abstrakten Syntaxbäumen als Beispiel Ohne Visitor: Knoten implementieren alle Operationen beim Hinzufügen einer neuen Operation müssen alle Knoten geändert werden Code für gleichartige Operationen ist über viele Klassen verstreut Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.19

20 Visitor Muster (2) Mit Visitor: Eine neue Visitor-Klasse für jede Operation als Unterklasse von NodeVisitor, enthält den Code für alle Typen von Knoten Knoten haben einen Haken zum Andocken für den Visitor Neue Operationen können einfach durch Bilden einer neuen Klasse hinzugefügt werden Aber: Hinzufügen neuer Knotentypen ist schwierig! Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.20

21 Visitor Muster (3) Struktur: Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.21

22 Visitor Muster (4) Interaktion: Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.22

24 Architekturmuster Buch A System of Patterns von Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad und Michael Stal ( das Siemens-Buch ), 1995 Drei Kategorien von Mustern: - Idioms für die Verwendung einer Sprache (Hilfestellung beim Schreiben einzelner Codezeilen) - Entwurfsmuster (analog zu den GoF-Mustern) - Architekturmuster Ziel von Architekturmustern: Hilfsmittel für den Entwurf im Großen Wie kann man effiziente und flexible Architekturen unabhängig von einer bestimmten technischen Basis entwerfen? Wie findet man Komponenten und Subsysteme für große Systeme? Wie kann man die Verantwortlichkeiten und Schnittstellen der Komponenten bestimmen? Wie geht man bei der Umsetzung der Architektur vor? Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.24

25 Beschreibungsschema Bezeichnung, Überblick, Motivation Name Kurzbeschreibung Kontext motivierendes Beispiel Beschreibung des Kontexts Problem Beschreibung des Problems Lösung Beschreibung der Lösung Struktur Dynamik Vorgehen bei der Implementierung Varianten bekannte Anwendungsfälle Konsequenzen Vor- und Nachteile Beziehungen zu anderen Mustern Name Kontext Problem Lösung Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.25

26 Layers Muster (1) Name: Layers Zweck: Strukturiere Anwendungen, deren Funktionalität in Gruppen von Unterfunktionen zerfällt, wobei man die einzelnen Gruppen jeweils unterschiedlichen Abstraktionsniveaus zuordnen kann. Beispiel: Netzwerkprotokolle wie ISO/OSI, TCP/IP Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.26

27 Layers Muster (2) Kontext: Ein großes System, das strukturiert werden muss. Problem: Organisation von Funktionalität auf unterschiedlichen Abstraktionsebenen, von der Benutzungsoberfläche bis hin zu Gerätetreibern Pflichtenheft spezifiziert allgemeine Anforderungen und konkrete Zielhardware, wobei die Abbildung der Anforderungen auf die Hardware nicht unmittelbar einsichtig ist Kräfte, die ausbalanciert werden müssen: - Änderungen an Anforderungen und Quellcode sollen lokal bleiben - Schnittstellen sollen stabil bleiben (evtl. Verwendung von Standardschnittstellen) - Komponenten und Hardware/Software-Plattformen sollen austauschbar sein - Low-Level-Funktionalität soll in mehreren Systemen verwendet werden - Komponenten mit komplexer Funktionalität sollen weiter strukturiert werden - Möglichst wenige Komponenten sollen bei der Lösung einer Aufgabe involviert sein - Das System soll von einem Team von Programmierern mit klaren Verantwortlichkeiten erstellt werden -... Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.27

28 Layers Muster (3) Lösung: Strukturiere das System in Schichten aus Komponenten, die auf der gleichen Abstraktionsebene angesiedelt sind. Komponenten einer höheren Schicht können zur Erledigung ihrer Aufgabe auf Komponenten der gleichen und der unmittelbar darunter liegenden Schicht zurückgreifen. Struktur: Class Schicht J Collaboration Schicht J-1 Client uses Layer N Responsibility Layer N-1 stellt Dienste für Schicht J+1 zur Verfügung ruft Dienste von Schicht J-1 auf Layer 1 Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.28

29 Layers Muster (4) Dynamik: Szenario 1 (Top-Down): Requests von höheren Schichten werden durch alle Schichten bis zur untersten durchgereicht, eventuelle Replies kommen analog zurück Szenario 2 (Bottom-Up): Notifications niederer Schichten werden von höheren Schichten analysiert, interpretiert und gegebenenfalls weiter nach oben durchgereicht Szenario 3: wie 1, nur dass Requests nicht unbedingt bis ganz nach unten durchgereicht werden, sondern bereits von einer mittleren Schicht vollständig bearbeitet werden können Szenario 4: wie 3, nur für Notifications Szenario 5: Kombination von 1 bis 4 für zwei kommunizierende Protocol Stacks (ein Request eines Stacks wird zu einer Notification im anderen Stack und umgekehrt) Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.29

30 Layers Muster (5) Vorgehen bei der Implementierung: Bestimme das Abstraktionskriterium Bestimme die Anzahl der Abstraktionsebenen Benenne die Schichten und ordne ihnen Aufgaben zu Spezifiziere die Dienste der Schichten Verfeinere die Aufteilung in Schichten Spezifiziere die Schnittstelle der Schichten Strukturiere die einzelnen Schichten Spezifiziere die Kommunikation zwischen den einzelnen Schichten Schirme die einzelnen Schichten gegeneinander ab - Implementierungsvarianten: C++-Interfaces, Callbacks, Reactor-Entwurfsmuster Entwerfe eine Strategie für die Fehlerbehandlung - Behandle Fehler möglichst auf unteren Abstraktionsebenen vollständig! - Reiche keine Low-Level-Fehlermeldungen nach oben durch! Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.30

31 Layers Muster (6) Varianten: Abgeschwächte Schichtenarchitektur: Kommunikation nicht nur zwischen benachbarten Schichten Tradeoff: Performance vs. Wartbarkeit... Layer 2 Layer 3 Layer 1 bekannte Anwendungsfälle: APIs Virtual Machines Informationssysteme mit Zwei- oder Dreischichtenarchitektur Betriebssysteme Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.31

32 Layers Muster (7) Vor- und Nachteile: + Wiederverwendung von Schichten + Möglichkeit zur Standardisierung + Minimierung von Code-Abhängigkeiten + Austauschbarkeit der Implementierung von Schichten Änderungen müssen eventuell durch alle/viele Schichten durchgezogen werden Geringere Effizienz durch viele Schichtenübergänge Unnötige und doppelte Arbeit (Bsp: Fehlerkorrektur auf allen Schichten) Schwierigkeit, die korrekte Anzahl von Schichten zu finden Beziehungen zu anderen Mustern Composite Message (Variante von Composite Muster für den Entwurf von Datenpaketen zwischen Schichten)... Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.32

33 Beispiel: 3-Schichtenarchitektur von Informationssystemen intelligente fachliche Objekte Clients Middleware spezielle fachliche Dienste allgemeine technische Dienste Datenhaltung Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.33

34 Broker Muster (1) Name: Broker Zweck: Das Broker-Muster hilft bei Strukturierung verteilter Softwaresysteme mit entkoppelten Komponenten, die durch das Aufrufen entfernter (remote) Dienste interagieren. Ein Vermittler koordiniert die Kommunikation.. Beispiel: Touristeninformationssystem HTTP Browser Web Server Broker Database server Database server Database server Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.34

35 Broker Muster (2) Kontext: Ein verteiltes eventuell heterogenes System mit voneinander unabhängigen, miteinander arbeitenden Komponenten. Problem: Ein System, das aus einer Sammlung verteilter, entkoppelter aber interagierender Komponenten besteht, ist flexibel, änderbar und skalierbar. Die Kommunikation unter den kooperierenden Komponenten sollte jedoch nicht zu unnötigen Abhängigkeiten führen. Diese ergeben sich aber sofort, wenn die Komponenten selbst für den IPC-Mechanismus verantwortlich sind. - Klienten müssen wissen wo die Server sich befinden - Die Lösung ist meist auf eine Programmiersprache beschränkt Darüber hinaus sollten kein systemspezifischen Details mit Diensten wie - Hinzufügen, Entfernen, Auswechseln, Aktivieren und Suchen von Komponenten verbunden sein. Es sollte keinen Unterschied für die Entwicklung von Software für verteilte oder zentralisierte Systeme geben. Eine Anwendung, die ein Objekt benutzt, sollte nur dessen Schnittstelle sehen. Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.35

36 Broker Muster (3) Kräfte, die ausbalanciert werden - Komponenten sollten mit Hilfe von entfernten, ortsunabhängigen Dienstanforderungen auf Dienste anderer Komponenten zugreifen. - Zur Laufzeit müssen Komponenten ausgetauscht, hinzugefügt oder entfernt werden. - Die Architektur sollte system- und implementierungsspezifische Details vor den Benutzern von Komponenten und Diensten verbergen. Lösung: Zur Entkopplung von Client und Server wird ein Vermittler (Broker) eingeführt. Server melden sich selbständig beim Vermittler an und stellen den Clients ihre Dienste zur Verfügung. Clients greifen durch Senden von Dienstanforderungen über den Vermittler auf die Funktionalität des Servers zu. Der Broker - macht den geeigneten Server ausfindig - leitet die Dienstanforderungen weiter - übermittelt Ergebnisse und Fehlermeldungen Statt sich auf IPC zu konzentrieren, schickt die Anwendung lediglich Nachrichten an das betreffende Objekt. Im Broker-Muster werden Verteilungs- und Objekttechnologien kombiniert. Es entstehen verteilte objektorientierte Anwendungen. Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.36

37 Broker Muster (4) Struktur: Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.37

38 Broker Muster (4) Dynamik: Server meldet sich an Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.38

39 Broker Muster (5) Client schickt Anfrage Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.39

40 Broker Muster (6) Broker kommuniziert über Brücken Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.40

41 Broker Muster (7) Vorgehen bei der Implementierung: Objektmodell festlegen, Eigenschaften von Client und Server insbesondere deren Datenstrukturen und Operationen Interoperabilität festlegen, Austauschformate bestimmen, Schnittstellen zwischen Client und Server festlegen (z.b.: über IDL) APIs der Vermittler festlegen Proxies entwerfen - Client-side Proxies verwandeln Prozeduraufrufe in Nachrichten und leiten diese an den Broker - Server-side Proxies empfangen Nachrichten und wandeln sie in Operationsaufrufe, leiten Antworten und Fehlermeldungen weiter. Die Proxies sind immer Teil des jeweiligen Prozesses. Eventuell werden Proxies auch automatisch bereitgestellt (z.b.: durch den IDL-Übersetzer erzeugt) Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.41

42 Broker Muster (8) Broker entwerfen - Übertragungsprotokoll definieren - Anfragen, Antworten, Fehlermeldungen, Typinformation - Austauschformate, Brücken - Auffinden entfernter Komponenten (Routing) - Jedem Rechner im Netz (Komponente) muss ein Vermittler zugewiesen werden. Eventuell ist die Routinginformation Teil der Client und Serverbezeichnungen - Der Broker ist verantwortlich für die Weitergabe aller Informationen - Der Broker muss stets wissen welcher Klient welche Anfrage getätigt hat. - Bei asynchroner Kommunikation sind Puffer in den Broker erforderlich. - Eventuell ist eine Adressbuchfunktionalität bis hin zu Nameservices notwendig - Fehler berücksichtigen - Komponenten können in Fehlerzustände laufen - Kommunikation kann scheitern IDL-Übersetzer entwickeln Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.42

43 Broker Muster (9) Varianten: Direct-Communication: Der Vermittler ist nur noch für die Kanalwahl zuständig. Der Rest obliegt den Proxies (effizient) Message-Passing: Statt eines dedizierten Dienstes anzubieten, werden nur Nachrichten ausgetauscht. Die Aufgabe wird über den Nachrichtentyp festgelegt. (Schnittstelle wird einfacher, Austauschformat komplexer) Trader: Statt Server werden direkt Dienste angesprochen. Broker muss nun wissen, welcher Server welchen Dienst bereitstellt (kompliziertere API, Lastverteilung durch den Broker möglich) Callbacks: Der Vermittler ruft Callbacks auf, statt Nachrichten zu versenden. Keine Unterscheidung zwischen Client und Server. bekannte Anwendungsfälle: CORBA, DCOM, J2EE,.NET, SOAP, etc. ATM-P, MQ-Series Windows NT, verteilte Betriebssysteme Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.43

44 Broker Muster (10) Vor- und Nachteile: + Standortunabhängigkeit: Klienten müssen nicht wissen wo die Server sind. + Änderbarkeit und Erweiterbarkeit der Komponenten + Portierbarkeit: Insbesondere durch den Einsatz von Brücken steigt die Portierbarkeit + Interoperabilität: Verschiedene Brokersysteme können zusammen arbeiten, falls die Nachrichtenformate und -mechanismen gleich bleiben. (DCOM, SOAP, XML) + Wiederverwendbarkeit: Vorhandene Dienste können einfach eingebunden werden. Eingeschränkte Effizienz: Daten müssen in Nachrichten verwandelt werden und Kommunikationswege dynamisch bestimmt werden. Broker sind Flaschenhälse Niedrige Fehlertoleranz: Fällt der Broker aus, dann sind ganze Systemteile nicht mehr erreichbar. Beziehungen zu anderen Mustern Forwarder-Receiver, Proxy, Client-Dispatcher-Server Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.44

45 Beispiel: Bus-Architekturen und Smartcards (1) Component 1 Component m CORBA Event Service Smartcard Betriebssystem CardLet 1 CardLet n Smartcard Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.45

46 Beispiel: Bus-Architekturen und Smartcards (2) Component 1 CardLet 1 Component m CORBA Event Service CardLet n Smartcard Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.46

47 Beispiel: Bus-Architekturen und Smartcards (3) Component 1 Component m CORBA Event Service PortProxy PortProxy PortProxy PortProxy Proxy Event Broker Smartcard Event Broker Port Port Port Port CardLet 1 CardLet n Smartcard Proxy Smartcard Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.47

49 Fowler s Analysemuster Fowler:...pattern is an idea that has been useful in one practical context and will propably be useful in others. Kategorien von Mustern Analysemuster Muster für die fachliche Anwendungsarchitektur: Beobachtungen und Messungen, Organisation und Verantwortlichkeit, etc. Support-Muster Muster um die fachliche Anwendungsarchitektur technisch zu realisieren: Zwei-, Drei-Schichtenarchitekturen, Objekt Erzeugung, etc. Kein durchgängiges, einheitliches Beschreibungsschema Zu bestimmten Problembereichen der Anwendungsdomäne wird eine Lösung schrittweise eingeführt Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.49

50 Muster: Beobachtungen und Messungen (1) Naive Modellierung einer Person mit Göße, Gewicht und Blutzuckerspiegel Person - Göße : int - Gewicht : int - Blutzuckerspiegel : int Problem: Verschiedenen Systeme müssen mit Objekt Person umgehen; Attribute sind aber interpretierbar, da die Einheit (cm oder in) nicht mitmodelliert wird Lösung: Explizite Modellierung der Einheit Person + Göße : Quantität + Gewicht : Quantität + Blutzuckerspiegel : Quantität Quantität + Anzal : int + Einheit : Einheit + kleiner(vergleichswert : Quantität) + größer(vergleichswert : Quantität) + gleich(vergleichswert : Quantität) Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.50

51 Muster: Beobachtungen und Messungen (2) Fowler s Modellierungsprinzip: When multiple attributes interact with behavior that might be used in several types, combine the attributes into a new fundamental type. Erweiterung: Konvertierungsverhältnis Person + Göße : Quantität + Gewicht : Quantität + Blutzuckerspiegel : Quantität Quantität + Anzal : int + Einheit : Einheit + kleiner(vergleichswert : Quantität) + größer(vergleichswert : Quantität) + gleich(vergleichswert : Quantität) + Name : String Einheit + Umrechnen(Von : Quantität, NachEinheit : Einheit) : Quantität von nach * * Konvertierungsverhältnis + Umrechnungssatz : float Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.51

52 Muster: Organisation und Verantwortlichkeit (1) Naive Modellierung einer Adressverwaltung Problem: Finde geeignete Abstraktion für Organisation und Person Lösung: Party als gemeinsame Abstraktion von Organisation und Person Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.52

53 Muster: Organisation und Verantwortlichkeit (2) Naive Modellierungen von Organisationshierarchie und -struktur Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.53

54 Muster: Organisation und Verantwortlichkeit (3) Problem: Struktur ist inflexibel und nicht wieder verwendbar Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.54

55 Muster: Organisation und Verantwortlichkeit (4) Lösung: Verwendung einer einzigen, aber im Modell typisierbaren Assoziation Fowler s Modellierungsprinzip: Design a model so that the most frequent modification of the model causes changes to the least number of types. Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.55

56 Muster: Organisation und Verantwortlichkeit (5) Erweiterung: Typisierbare Assoziation über die gemeinsame Abstratkion von Person und Organisation Fowler s Modellierungsprinzip: Whenever defining features for a type, that has a supertype, consider whether placing the features on the supertype makes sense. Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.56

57 Muster: Organisation und Verantwortlichkeit (6) Erweiterung: Gültige Konfiguration der Assoziationen zw. Parties und Accountabilities im Knowledge Level ablegen. Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.57

58 Analysemuster: Zusammenfassung und Bewertung Analysemuster haben ein hohes Potential Dokumentation des wertvollen internem Wissen Kontinuierliche Weiterentwicklung des internen Wissens Hohe Wiederverwendung von Branchenwissen Über die Standardisierung erreicht man Interoperabilität und Flexibilität Fowler s Analysemuster sind keine vollständigen Analysemuster Kein einheitliches Dokumentationsschemata Keine klare Struktur; es fehlt an einer MusterkatalogNur Dokumentation von Nähkästchen-Wissen in Form von Beispielen Softwarearchitektur verteilter Systeme 6b. Ausprägungen und Wiederverwendung 6b.58