Architekturen betrieblicher Anwendungssysteme Klassische Architekturmuster Lehrstuhl für Wirtschaftsinformatik und Electronic Government Universität Potsdam Chair of Business Information Systems and Electronic Government University of Potsdam Univ.-Prof. Dr.–Ing. habil. Norbert Gronau Lehrstuhlinhaber | Chairholder August-Bebel-Str. 89 | 14482 Potsdam | Germany Tel Fax +49 331 977 3322 +49 331 977 3406 E-Mail [email protected] Web lswi.de Architekturmuster Mustersysteme Schichtenmuster Model-View-Controller-Muster Service orientierte Architektur Architekturmuster Mustersysteme Schichtenmuster Model-View-Controller-Muster Service orientierte Architektur Definition Softwaremuster Robustheit Memory Muster Problem Änderbarkeit Kontext Performance Lösung Lösung Kosten Time-to-Market Muster Dreiteiliges Regelwerk zur Verdeutlichung von Beziehungen zwischen Kontext, Problem und Lösung Quelle: Vogel 2005, S. 173 Einfachheit Wiederverwendbarkeit Wartbarkeit Softwaremuster Dreiteiliges Regelwerk zur Verdeutlichung von Beziehungen zwischen Kontext, System an Kräften und Software-Konfiguration Architekturstil - Architekturmuster - Entwurfsmuster Abstraktion grobe Architekturspezifikation Makro-Architekturen Referenzarchitektur detaillierte Architektur-spezifikation Mikro-Architekturen Architekturmuster Entwurfsmuster Mustersprachen Programmcode Idiome System einer Anwendungsdomäne System aus allen Anwendungsdomänen Scope Ein Architekturstil stellt das Alphabet für die Mustersprachen zur Verfügung. Quelle: Reusser 2006, S. 330 Dokumentation eines Musters Wiederverwendung einer bewährten Lösung für ein Architekturproblem Dokumentation erfasst folgende Punkte: Name Name des Musters Kontext/Beschreibung Der Kontext in dem das Problem und die Lösung anwendbar sind Problem Das Problem, für welches das Pattern eine Lösung anbietet Kräfte/Forces Bedingungen, die in der Lösung berücksichtigt werden sollen und oft nur Kompromisse zulassen Lösung Die Lösung des Problems, oft ein Kompromiss bezüglich der Kräfte Konsequenzen Welche neue Situation durch die Anwendung der Beschriebenen Lösung entsteht und welche Kräfte wie berücksichtig wurden Quelle: Vogel 2005, S. 173 Weitere Unterpunkte zu Lösung Struktur Class-Responsibility-Collaborator-Karten Komponentendiagramme Andere Strukturdiagramme Verhalten Szenariobasierte Verhaltensbeschreibung Implementierung Vorgehensmodell zur Implementierung eines Systems basierend auf dem Muster, inkl. Code-Beispielen Beispiele Konkrete Beispiele, bei denen das Muster angewandt wurde Varianten Beschreibung der variablen Systembestandteile Quelle: Buschmann 1996, S. 19ff Architekturmuster Mustersysteme Schichtenmuster Model-View-Controller-Muster Service orientierte Architektur Musterkategorien Architekturmuster Templates für konkrete Softwarearchitekturen Analyse Systemweite Spezifikation von Eigenschaften einer Anwendung Beeinflussung der Architektur der Subsysteme Entwurfsmuster Schema zur Entwicklung von Subsystemen bzw. Komponenten von Systemen Geringere Reichweite und Auswirkungen als Architekturmuster Entwurf Design Unabhängig von Programmiersprachen oder Programmierparadigmen Implemen tierung Idiome „Implemtierungsmuster“ Abhängig von Programmiersprachen Lösen konkrete Probleme in einer konkreten Programmiersprache Test Musterkategorien orientieren sich am Entwicklungszyklus von Software Quelle: Buschmann 1996, S. 12-14 Klassifikation von Mustern Zweck und Abdeckung Adressierte Probleme bilden das Klassifikationsschema Erstellung (Creation Patterns) Distributed Systems Kompositions von Objekten und Klassen (Structural Patterns) Interaktive Systeme Interaktion von Klassen und Objekten (Behavioral Patterns) ... Systemdekomposition Anpassungsfähige Systeme Das Klassifikationsschema nach Problemen ermöglicht das gezielte Suchen von Softwaremustern Quelle: Reussner 2006, S. 344; Buschmann 1996, S. 364 Zuordnung von Anwendungsproblemen zu Mustern Architekturmuster Vom Untergeordneten zur Struktur Schichten Pipes & Filters Blackboard Verteilte Systeme Broker Pipes & Filters Microkernel Interaktive Systeme Anpassungsfähige Systeme Strukturelle Dekomposition Arbeitsorganisation Zugriffskontrolle Management Kommunikation Entwurfsmuster Idiome MVC PAC Microkernel Reflection Whole-Part Master-Slave Proxy Command Processor View Handler Publisher-Subscriber Forwarder-Receiver Client-Dispatcher-Server Ressource Handling Counted Pointer Quelle: Buschmann 1996, S. 366 Pattern-Mining Wie kommt es zu diesen Mustern? Muster werden gefunden, nicht erfunden! Architekturmuster beschreiben einen Lösungsansatz für ein häufig auftretendes Problem Reflektion über Lösungsansätze und gezieltes Suchen nach Mustern Nicht trivial Komplexität besteht in dem Herausfinden der Schlüsselidee, den Rahmenbedingungen und den Konsequenzen für die Anwendbarkeit Muster sind Gegenstand kontinuierlicher Evolution Quelle: Reussner 2006, S. 349f Architekturmuster Mustersysteme Schichtenmuster Model-View-Controller-Muster Service orientierte Architektur Schichtensysteme Ablaufsteuerung Nützliche Systeme BasisFunktionen Kernschicht Stilbeschreibung Hierarchische Organisation Zur Verfügungstellung von Services für die übergeordnete Schicht Benutzung der Services der darunterliegenden Schicht Stilkomponenten = Schicht Stilkonnektoren = Interaktionsbestimmende Protokolle zwischen den Schichten Komposition von verschiedenen Elementen Benutzer Die Drei-Schichten-Architektur ist insbesondere für betriebliche Anwendungssysteme etabliert Quelle: Shaw 1996, S. 25 Schichtenmodelle I Ziele Benutzer Separation von logischen und physischen Bestandteilen UI Components Business Entities Data Access Logic Components Service Agents Data Sources Services Operational Management Business Components Communication Business Workflows Security Server Interfaces Cross-Cutting UI Process Components Getrennte Modellierung, Implementierung, Verteilung und Betrieb Stichwort: Separation of Concers Das Schichten-Muster eignet sich zur Dekomposition der Aufgaben. Quelle: Fowler 2003, S. 32 Schichtenmodelle II Zweck und Aufbau Vorteile Mittel der Strukturierung Leicht verständlich Darstellung verschiedener, aufeinander aufbauender Abstraktionslevel Technologietrennung und -integration Schichten können selbst wieder strukturiert sein Übliche Modelle Wohl definierte Zugriffskonzepte durch Beschreibung der Protokolle Nachteile 2-Schichten-Modell, z.B. Rich-Client Szenarien Notwendigkeit von definierten stabilen Schnittstellen 3-Schichten-Modell, z.B. Daten-, Geschäftslogik- und Präsentationsschicht Krititsche Performance Hohe Kosten bei Gesamtsystemveränderung N-Schichten-Modell, z.B. ISO OSI Referenzmodell für die Kommunikation offener Systeme Schichten-Muster werden häufig in betrieblichen Anwendungssystemen eingesetzt. Quelle: Buschmann 1996, S. 31-51 Dokumentation des Schichten-Architekturmusters Name Layers Vom Untergeordneten zur Struktur Große Systeme, die eine Dekomposition erfordern Problem Wie strukturiert man eine Anwendung, so dass stabile Schnittstellen entstehen und nachträgliche Änderungen lokal bleiben? Nachträgliche Code-Änderungen dürfen sich nicht auf das ganze System auswirken Schnittstellen müssen stabil sein Teile des Systems müssen austauschbar sein, ohne einen Effekt auf den Rest des Systems zu haben Möglichkeit der Wiederverwendung in einem zukünftigen System Gruppierungen von ähnlichen Verhaltensweisen Keine Standard-Granularität Komplexe Komponenten müssen weiter zerlegt werden Teamarbeit muss ermöglicht werden Kräfte/Forces Kontext und Problembeschreibung ermöglicht das Finden von Software-Mustern. Quelle: Buschmann 1996, S. 31-51 Dokumentation des Schichten-Architekturmusters Name Lösung Layers Schichtung der Aufgaben bzw. Module Anordnen der Schichten nach Abstraktionslevel (niedrigster Abstraktionslevel ist Layer 1) Restriktion der Aufrufbeziehungen Struktur: Class Collaborator Layer Schicht J-1 Responsibility Anbieten von Services, die von der Schicht J+1 genutzt werden Delegieren von Teilaufgaben an die Schicht J-1 Konsequenzen Wiederverwendung von Schichten; Voraussetzung ist eine wohldefinierte Abstraktion der Schicht und wohldefinierte sowie dokumentierte Schnittstellen Ermöglichung von Standardisierung Abhängigkeiten bleiben lokal auf einer Schicht Austauschbarkeit Geringere Effizienz Unnötige Arbeitsschritte Schwierige Granularitätsbestimmung Lösung enthält ein Vorgehensmodell zur Anwendung des Software-Musters. Quelle: Buschmann 1996, S. 31-51 Anwendung des Schichten-Musters in betrieblichen Anwendungssystemen Client-Server-Architekturen Eigenschaften Layer 2: Dienstnutzer Client Enthält die Anwendungslogik, häufig umgesetzt als FAT-Client Layer 1: Dienstanbieter Server Trennung von Datenhaltung und Datenverarbeitung Keine Verantwortung für die Datenspeicherung und sämtlicher damit verbundener Konzeptionen der Clienten-Komponente Clienten-Komponente nutzt die zugesicherten Dienste der Server-Komponente Stellt die für die Bearbeitung der Funktionen dem Clienten die notwendigen Daten zur Verfügung Die grundlegendeste Anwendung des Schichten-Musters ist die Client/Server-Architektur. Quelle: Hasselbring 2006 Anwendung des Schichten-Musters in betrieblichen Anwendungssystemen Drei-Schichten-Architektur Eigenschaften Präsentation Layer 3 Weitere Dekomposition der Client-Komponente Dienstnutzer Client Dienstanbieter Geschäftslogik Dienstnutzer Datenhaltung Layer 1 Server Die Client-Server-Architektur lässt sich weiter unterteilen. Quelle: Hasselbring 2006 Variante 1: Geschäftslogik ist Teil des Servers (Thin-Client) Variante 2: Geschäftslogik ist Teil des Clienten (FAT-Client) Layer 2 Dienstanbieter Businesslogik wird getrennt von der Präsentation Anwendung des Schichten-Musters in betrieblichen Anwendungssystemen Web-Informationssystem-Architektur Eigenschaften Web-Client Layer 4 Web-Server Layer 3 Anwendungslogik Geschäftslogik Layer 2 Datenhaltung Layer 1 Quelle: Hasselbring 2006 Entwicklung eines Schichtenmodells für Portale Portal Webbasierte Anwendung Integration von verschiedenen Informationsquellen und Anwendungen in einer homogenen Benutzeroberfläche Vorgehen zur Erstellung einer Software-Architektur für Portale Definition von Abstraktionskriterien Welche funktionalen Abhängigkeiten bestehen? Welche Abstraktionsniveaus existieren im Umfeld? Einteilung des Systems in funktionale Ebenen mit strikter Ordnung Quelle: Gurzki 2006, S. 58f Präsentationslayer weiter unterteilt in Web-Server und Web-Client Webserver übernimmt Aufbereitung der Daten Webclient ist ein Webbrowser Aufbereitung der Daten für die Präsentation im Webserver = Serverseitige Präsentation Schichtenmodell im Kontext von Portalsoftware Verwendung eigenstäniger Systeme für Portalsystemkomponenten Portalanwendungskomponente Portalsystemkomponente Betriebliche Informationskomponente Verwendung von Portalsystemkomponenten im Application-Server des Portals Mischform der Szenarien A und B Systemgrenze Application-Server Systemgrenze Portalsoftware Verschiedene PaKs Verschiedene PAKs Verschiedene PAKs Verschiedene PSKs Verschiedene PSKs Verschiedene PSKs Für den Betrieb des Protals notwendige Funktionen für die Nutzung durch PAKs Verschiedene BIKs Verschiedene BIKs Verschiedene BIKs Betriebsrelevante Kernprozesse des Unternehmens Für den Benutzer sichtbare Anwendungen Je nach Anwendungsszenario der Protalsoftware entstehen unterschiedliche Architekturmodelle. Quelle: Gurzki 2006, S. 61 Architekturmuster Mustersysteme Schichtenmuster Model-View-Controller-Muster Service orientierte Architektur Model-View-Controller (MVC) Beispiel Black 43 Red 39 Blue 6 Anwendbar für interaktive Systeme Aufteilung des Systems in drei Bereiche: Green 10 Model: Kernfunktionalität und Daten Black: Red: Blue: Green: 43% 39% 6% 10% View: Anzeige der Informationen } Benutzerschnittstelle Controller: Verarbeitung der Nutzereingaben Quelle: Buschmann 1996, S. 125 Dokumentation des MVC-Architekturmuster Name Model-View-Controller (MVC) Kontext/ Beschreibung Interaktive Anwendungen mit einer flexiblen Mensch-Computer-Schnittstelle Problem Benutzerschnittstellen unterliegen häufigen Änderungsbedarfen. Funktionserweiterungen erfordern Anpassungen der Menüs etc.. Nutzer verlangen nach verschiedenen Darstellungsmöglichkeiten des selben Inhaltes und möchten das "look and feel" auf ihre Bedürfnisse anpassen. Kräfte/Forces Verschiedene Anzeigeformate für die selben Informationen in verschiedenen Fenstern (z.B. Kreisdiagramm oder Balkendiagramm) Umgehende Verarbeitung von Datenänderungen Einfaches und Schnelles Ändern der Benutzerschnittstelle zur Laufzeit Anbieten verschiedener "look and feel"-Standards Lösung Aufteilung in processing, output und input Erstmalig umgesetzt in der Smalltalk-80 Entwicklungsumgebung Model kapselt die Kerndaten und -funktionalität, ist unabhängig vom Output, dem Input und der Repräsentation View stellt dem Nutzer die Informationen zur Verfügung; holt sich die Daten vom Model; ein Model kann mehrere Views haben Controller empfängt Input, i.d.R. eventgetrieben Verändert der Benutzer das Model über einen Controller, zeigen alle Views die Änderungen unmittelbar an Vorteile Konsequenzen Verschiedene Views auf das selbe Model Synchroisierte Views Nachträgliches Hinzufügen von weiteren Views Wechselbare Oberflächeneinstellungen Quelle: Buschmann 1996, S. 125 Class Model Responsibility Anbieten der Kernfunktionalität Kennt alle Views unf Controller Meldet Änderungen an alle notwendigen Komponenten Nachteile Komplexität Hohe Updateneigung Abhängigkeit zwischen Controller und View Collaborator View Controller Architekturmuster Mustersysteme Schichtenmuster Model-View-Controller-Muster Service orientierte Architektur Grundprinzipien einer Service orientierten Architektur Dienstverzeichnis 1. Veröffentlichen 2. Suchen 3. Verweis auf Dienst 4. Abfrage der Beschreibung Dienstanbieter Dienstnutzer 5. Nutzung des Dienstes Quelle: Dostalu.a.,2005,S.12 Grundlegende Merkmale einer SOA Lose Kopplung Dynamisches Finden und Einbinden von Diensten Bindung zur Laufzeit Schnittstellen zur Kommunikation Verwendung von (möglichst) offenen Standards fördert die Akzeptanz Stichpunkt 2 Maschinenlesbar Dienstsuchverzeichnis Wiederverwendung Ermöglicht das Finden relevanter Dienste Gekapselte Dienste Zugriff auf Instanzen des Diensteverzeichnisses Mehrfach verwendbar in verschiedenen Umgebungen ohne Aufwand Wissen über die Kategorie in welcher der Dienst eingebunden ist Anmeldung des Dienstes im Verzeichnis Komponentenorientierung ist durch die Trennung von Schnittstelle und Implementierung gegeben Quelle: Dostal2005,S.9 Beispiel Servicenutzung im Geschäftsprozess Web Service basierte SOA und Standards Simple Object Access Protocol (SOAP) Beschreibt das XML-basierte Nachrichtenformat der Kommunikation und dessen Einbettung in ein Transportprotokoll Universal Description, Discovery and Integration protocol (UDDI) Web Services Description Language (WSDL) XML-basierte Beschreibungssprache, um Web Services (Dienste) zu beschreiben Beschreibt einen Verzeichnisdienst für Web Services, Spezifiziert eine standardisierte Verzeichnisstruktur für die Verwaltung von Web Services Metadaten (allg. Anforderungen, Web Services Eigenschaften, benötigte Informationen zum Auffinden von Web Services) Quelle: Dostal u.a.,2005 Anwendungsszenario: UDDI als branchenspezifischer Marktplatz Administration Richtlinien Richtlinien Autorisieren Bindung Bindung Veröffentlichen UDDI-Markplatz Dienstanbieter Dienstnutzer Geschäftsbeziehung Quelle: Dostal u.a., 2005, S. 104ff. Suchen Zusammenfassung Zusammenfassung Definition von Mustern Muster allgemein nach Alexander 1977 Ein Muster ist eine dreiteilige Regel, die die Beziehung zwischen einem bestimmten Kotext, einem Problem und einer Lösung ausdrückt. Quelle: Vogel 2005, S. 173 Software-Muster nach Coplien 2004 Jedes Muster ist eine dreiteilige Regel, die die Beziehung zwischen einem bestimmten Kontext, einem bestimmten System an Kräften, die in diesem Kontex wiederkehrend auftreten, und einer bestimmten Software-Konfiguration, die diesen Kräften erlaubt, sich gegenseitig aufzulösen, ausdrückt. Zusammenfassung Musterkategorien Architekturmuster Templates für konkrete Softwarearchitekturen Analyse Systemweite Spezifikation von Eigenschaften einer Anwendung Beeinflussung der Architektur der Subsysteme Entwurfsmuster Schema zur Entwicklung von Subsystemen bzw. Komponenten von Systemen Geringere Reichweite und Auswirkungen als Architekturmuster Entwurf Design Unabhängig von Programmiersprachen oder Programmierparadigmen Implemen tierung Idiome „Implemtierungsmuster“ Abhängig von Programmiersprachen Lösen konkrete Probleme in einer konkreten Programmiersprache Musterkategorien orientieren sich am Entwicklungszyklus von Software Quelle: Buschmann 1996, S. 12-14 Zusammenfassung Musterdokumentation Muster Kontext Beschreibung des Anwendungsgebietes Problem Problembeschreibung Sammlung von Kräften, die im Kontext von Bedeutung sind Lösung Konfiguration zum Ausbalancieren der Kräfte Struktur mit Komponenten und Beziehungen Laufzeit-Verhalten Eine Musterdokumentation folgt einem strukturierten und einheitlichen Aufbau. Test Zusammenfassung Schichtenmuster und MVC Schichtenmuster Model-View-Controler Dient der Strukturierung durch Dekomposition Anwendungsbereich sind interaktive Systeme Bereitstellung eines Services für die obere Schicht Aufteilung in Nutzung von Services der unteren Schicht Model für Daten und Funktionalität Schichtenmuster ist etablierter Standard für betriebliche Anwendungssysteme View zur Darstellung der Informationen Controller zum Abfangen und weiterleiten der Benutzereingaben Wichtig für Web-Architekturen, deren Funktion in der Interaktion mit dem Benutzer liegt. Lernfragen Was ist eine Softwaremuster und woher kommen diese? Welche Ziele werden mit dem Softwaremuster verfolgt? Wie werden Softwaremuster dokumentiert? Warum sind Schichtenarchitekturen so erfolgreich? Welche Bestandteile hat eine Service orientierte Architektur? Literatur zur Vorlesung Andres, T. (2005): Vom Geschäftsprozess zum Anwendungssystem, in: Model-driven develpoment, MDA 2/2005, online unter www.objektspektrum.de Andresen, A. (2004): Komponentenorientierte Softwareentwicklung, Hansa-Verlag 2004. Buschmann, F. et al. (1996): Pattern-oriented Software Architecture, West Sussex 1996. Dostal, W. u.a.: Serviceorientierte Architekturen mit Web Services - Konzepte, Standards, Praxis. München 2005. Fowler, M. (2003): Patterns für Enterprise Application-Architekturen, Berlin 2003. Gurzki, T. (2006): Ein Architekturmodell für Portale im technischen Vertrieb, Dissertation, Hildesheim 2006. Hasselbring, W. (2006): Aktuelles Schlagwort - Software-Architektur, in: Informatik Spektrum (29) 1/2006. Springer Verlag, Heidelberg 2006. Reussner, R. (2006); Hasselbring, Wilhelm (Hrsg.): Handbuch der Software-Architektur, Heidelberg 2006. Shaw, M., Garlan, D. (1996): Software architecture : perspectives on an emerging discipline, NJ . Prentice-Hall,1996. Siedersleben, J. (2004): Moderne Softwarearchitektur, Heidelberg, 2004. Starke, G. (2005): Effektive Software-Architekturen, München 2005. Vogel, O. et al. (2005): Software-Architektur, Grundlagen - Konzepte - Praxis, München 2005.
© Copyright 2024 ExpyDoc
