docSoftwarearchitektur verteilter Systeme
download 
Report Transcription
Softwarearchitektur verteilter Systeme
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 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 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.3 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. s Wiederverwendung von Spezifikationen, Design und Entwurfswissen? Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.4 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 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 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 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 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 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 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.11 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 Beschreibungsschema § Bezeichnung und Überblick § Name § Kurzbeschreibung, Zweck § alternative Bezeichnungen Name § Motivation und Zielsetzung § Anwendbarkeit Kontext § graphische Beschreibung der Struktur § beteiligte Klassen § Interaktion Problem § Zweck § Lösung § Konsequenzen § § § § Vor- und Nachteile Implementierung und Beispiel-Code Anwendungsbeispiele Bezug zu anderen Mustern Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung Lösung 6b.13 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 Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung Klassendiagramm 6b.14 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 Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung Klassendiagramm 6b.15 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 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 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 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 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 Visitor Muster (3) § Struktur: Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.21 Visitor Muster (4) § Interaktion: Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.22 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.23 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 Beschreibungsschema § Bezeichnung, Überblick, Motivation § Name § Kurzbeschreibung Name § Kontext § motivierendes Beispiel § Beschreibung des Kontexts § Problem Kontext § Beschreibung des Problems § Lösung § § § § § § Beschreibung der Lösung Struktur Dynamik Vorgehen bei der Implementierung Varianten bekannte Anwendungsfälle Problem Lösung § Konsequenzen § Vor- und Nachteile § Beziehungen zu anderen Mustern Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.25 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 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 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 Responsibility Client uses Layer N Layer N-1 • stellt Dienste für Schicht J+1 zur Verfügung • ruft Dienste von Schicht J-1 auf Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung Layer 1 6b.28 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 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 Layers Muster (6) § Varianten: § Abgeschwächte Schichtenarchitektur: Kommunikation nicht nur zwischen benachbarten Schichten Tradeoff: Performance vs. Wartbarkeit § ... § Layer 3 Layer 2 Layer 1 bekannte Anwendungsfälle: § APIs § Virtual Machines § Informationssysteme mit Zwei- oder Dreischichtenarchitektur § Betriebssysteme Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.31 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 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 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 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 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 Broker Muster (4) § Struktur: Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.37 Broker Muster (4) § Dynamik: § Server meldet sich an Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.38 Broker Muster (5) § Client schickt Anfrage Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.39 Broker Muster (6) § Broker kommuniziert über Brücken Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.40 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 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 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 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 Beispiel: Bus-Architekturen und Smartcards (1) CardLet 1 Component 1 Smartcard Betriebssystem CORBA Event Service Component m CardLet n Smartcard Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.45 Beispiel: Bus-Architekturen und Smartcards (2) CardLet 1 Component 1 CORBA Event Service Component m CardLet n Smartcard Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.46 Beispiel: Bus-Architekturen und Smartcards (3) PortProxy Port CardLet 1 Component 1 Smartcard Event Broker PortProxy Proxy Event Broker CORBA Event Service Component m PortProxy Port Port CardLet n PortProxy Port Smartcard Proxy Smartcard Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.47 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.48 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 Muster: Beobachtungen und Messungen (1) § Naive Modellierung einer Person mit Göße, Gewicht und Blutzuckerspiegel Person - Göße : int - Gewicht : int - Blutzuckersp iegel : 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 Quantität Person + Göße : Quantität + Gewicht : Quantität + Blutzuckerspiegel : 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 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 Quantität Person + Göße : Quantität + Gewicht : Quantität + Blutzuckerspiegel : Quantität + A nza l : int + Einheit : Einhe it + kleiner(Vergleichswert : Quantit ät ) + größer(Vergleichswert : Quantit ät ) + gleich(Vergleichswert : Quantitä t) Einheit + Name : String von nach * Konvertierungsverhältnis * + Umrechnungs sat z : float + Umrechnen(Von : Quantität, NachEinheit : Einheit) : Quantität Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.51 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 Muster: Organisation und Verantwortlichkeit (2) § Naive Modellierungen von Organisationshierarchie und -struktur Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.53 Muster: Organisation und Verantwortlichkeit (3) § Problem: Struktur ist inflexibel und nicht wieder verwendbar Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.54 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 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 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 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 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.59 Nutzen von Mustern § Entwickler § Hilfe bei Entwurfsentscheidungen § Nutzung von erprobtem Wissen erfahrener Entwickler § Code-Beispiele können den Einstieg erleichtern und als Ausgangsbasis für eigene Lösungen dienen § Vertrautheit und leichter Einstieg durch standardisierte Beschreibung § Hilfe beim Weitergeben und Festhalten von eigenem Wissen § Team § Bildung einer einheitlichen Sprache § Dokumentationsstandard § Wissenstransfer an neue Mitarbeiter § Unternehmen § Standardisierte Dokumentation des Firmenwissens § Wiederverwendung erprobter Lösungen § Einheitliche Architektur der Firmensysteme Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.60 Problemfelder § Aufwand für Einarbeitung und Auswahl von Mustern kann hoch sein § Komplexe Mustersprachen mit starken Querbezügen zwischen vielen Mustern § Organisation, Kategorisierung und Einordnung von Mustern § Derzeit kein einheitliches Schema für die Beschreibung von Mustern § Anwendung von Mustern erfordert Erfahrung beim Entwurf von Softwaresystemen § Ausbalancieren der Kräfte eines Musters § Auswahl und Kombination von Mustern § Einsatz von Mustern aus unterschiedlichen Katalogen § § § Erkennen von Mustern im Code eines Systems ohne Dokumentation mühsam Kaum Ansätze zur Werkzeugunterstützung Erarbeitung von hilfreichen Mustern schwierig und aufwendig § „Übermusterisierung“ (Was ist eigentlich kein Muster?) § „Einzelmuster“ (Muster, die nur einmal auftreten) § Engagement von erfahrenen „Schäfern“ beim „Ausbrüten“ von Mustern nötig Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.61 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.62 Warum Referenzarchitekturen? § Muster § Beschreiben Lösungsansätze für spezielle Entwurfsprobleme § Unterstützen damit die - Wiederverwendung - Standardisierung - Kommunikation von Entwurfswissen § Keine Lösung für den gesamten Entwurf eines Softwaresystems § Für Unternehmen wie zum Beispiel § Anwender mit Individualsoftware (Deutsche Bank, Allianz, BMW, etc.) § Technologieanbieter (IBM, SUN, Microsoft, etc.) § Lösungsanbieter und Softwarehäuser (Accenture, sd&m, etc.) bieten einheitliche Architekturen für Softwaresysteme eine Reihe von Vorteilen… Referenzarchitekturen bzw. Blueprints Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.63 Was sind Referenzarchitekturen? § Referenzarchitekturen beschreiben eine Vorlage (Blueprint) für die Software- oder / und Systemarchitektur von Softwaresystemen. § Referenzarchitekturen legen insbesondere fest: § Funktionale Aufteilung des Systems unter technischen Gesichtspunkten § Technische Trägersysteme, die Rahmen für Applikationsentwicklung darstellen (Middleware, Datenbanken, Standardschnittstellen, etc.) § Prozesskommunikationsgrenzen und Ausführungsort von Systemteilen § Verwendete Systemsoftware, Netzwerke und Hardware § Für die Entwicklung von Softwaresystemen wird dann diese Architektur „kopiert“ und gegebenenfalls modifiziert Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.64 Vorteile und Nachteile von Referenzarchitekturen J Reduzierung der Entwicklungs- und Produktionskosten J Wiederverwendung von Entwurfswissen J Geringere Lizenzkosten durch beispielsweise einheitliches Datenbanksystem J Geringere Wartungs- und Einarbeitungskosten da einheitliche Umgebung J Erhöhung der anwendungsübergreifenden Interoperabilität J Anwendungsübergreifende Wiederverwendung von Komponenten K Abhängigkeit von Technologie- oder Lösungsanbieter § Technologie- und Lösungsanbieter J § Anwender L L Referenzarchitekturen beschränken sich meist auf technische Aspekte Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.65 Beispiel: Microsoft .NET Referenzarchitektur für eCommerce Systeme (1) Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.66 Beispiel: Microsoft .NET Referenzarchitektur für eCommerce Systeme (2) Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.67 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.68 Produktlinienarchitekturen – Wieso, weshalb, warum? § Referenzarchitekturen beschränken sich hauptsächlich darauf die technische Aspekte der Software- und Systemarchitektur von Anwendungen festzulegen. § Bei der Produktentwicklung steht aber die Funktionalität im Vordergrund nicht die Technik! § Produktzyklen sind relativ kurz (1-3 Jahre) § Technikzyklen im Produkt sind relativ lang (5-15 Jahre) § Strategische Erfolgsfaktoren im „heißen“ Produktmarkt § § § § Kosten Qualität Time-to-market Diversifizierung § Der Produktlinienansatz versucht den klassischen Entwicklungszyklus zu ändern und Produkte aus vorgefertigten, konfigurierbaren Komponenten zusammen zu stellen. Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.69 Produktlinienansatz (1) § Produktlinienarchitekturen (Product Line Architecture) beschreiben von einer Gruppe von ähnlichen Systemen § Architektureigenschaften § Typische Komponenten § Beziehungen zwischen den Komponenten § Produktlinien (Product Lines) sind eine Gruppe von Produkten, die eine gemeinsame, organisierte Menge von Fähigkeiten besitzen, um die Anforderungen des Marktes, des Benutzers oder der Anwendung zu erfüllen. § Eine Domäne (Domain) ist ein Bereich mit einem spezifischen Anwendungswissen; eine spezielle Anwendungsexpertise. Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.70 Produktlinienansatz (2) gehören zu einer Marktstrategie Anwendungsdomäne is satisfied by eine gemeinsame Produkte Architektur used to implement bestehen aus Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung Komponenten 6b.71 Produktlinienansatz (3) Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.72 Produktlinienansatz (4) § Der Produktlinienansatz ist § Domänenspezifisch § Prozessgetrieben § Architekturzentriert § Somit ermöglicht der Produktlinienansatz die Wiederverwendung verschiedener Softwareentwicklungsartefakte für die Erstellung neuer, ähnlicher Systeme, wie zum Beispiel § Anforderungen § Entwürfe und Design § Programmcode § Testfälle § Vorsicht: Sehr schwer beherrschbar; nur wenn die Anwendungsdomäne vollständig verstanden wurde! Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.73 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.74 Zusammenfassung § Die pragmatische Wiederverwendung von Softwarearchitekturen in Form von Design, Implementierung und Erfahrung ist essentielle Voraussetzung für die effektive Softwareentwicklung § (Wieder-)Verwendung von existierenden Implementierungen wird bereits gelebt, zum Beispiel Datenbanken, Middleware, Bibliotheken, Frameworks § (Wieder-)Verwendung von Entwurfswissen durch Muster gehört zu dem Handwerkszeug eines guten Architekten § Referenzarchitekturen geben den technischen Rahmen für Anwendungssysteme vor § Der Produktlinienansatz bietet einen ganzheitlichen Wiederverwendungs- bzw. Entwicklungsansatz für ähnliche Softwaresysteme Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.75 Literaturhinweise § § § § § § § [Ale77] Christopher Alexander. A Pattern Language. Oxford University Press. 1977. [Ale79] Christopher Alexander. The Timeless Way of Building. Oxford University Press. 1979. [GHJ+95] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns – Elements of Reusable Object-Oriented Software. 1995. [BMR+96] Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad und Michael Stal. Pattern-Oriented Software Architecture , Volume 1: A System of Patterns. John Wiley & Sons 1996. [SSR+00] Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann. Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Net-worked Objects. John Wiley & Sons. 2000. [Fow97] Martin Fowler. Analysis Patterns, Reusable Object Models. Addision-Wesley. 1997. [CN01] Paul Clements, Linda Northrop. Software Product Lines: Practices and Patterns. Addison Wesley Publishing Company. 2001 Softwarearchitektur verteilter Systeme – 6b. Ausprägungen und Wiederverwendung 6b.76
