Patterns & Softwarearchitektur

Transkript

1 Patterns & Softwarearchitektur Ausarbeitung zum Vortrag im Softwareengineering Projekt WS07/08 Michael Saecker Matrikelnummer: Software Engineering Projekt WS07/08 Institut für Softwaretechnik und Theoretische Informatik Technische Universität Berlin

2 Kurzfassung In der Softwareentwicklung ist man stets bemüht qualitativ hochwertige Systeme zu entwickeln. Um diesem Ziel näher zu kommen wurden pragmatische Lösungen für Problemklassen unter dem Namen Pattern (Muster) eingeführt. Hierbei unterscheidet man zwischen Design Patterns (Entwurfsmustern), die sich der Programmierung einzelner Komponenten widmen und Architectural Patterns (Architekturmustern), die den generellen Aufbau eines Softwaresystems darstellen. Entwurfs- und Architekturmuster geben somit Lösungsstrategien für häufige Probleme bei der Programmierung und dem Aufbau von Software. Diese Ausarbeitung erklärt die Begriffe der Muster um dann exemplarisch einige Repräsentanten vorzustellen. Als Beispiel für klassische Entwurfsmuster werden die Design Patterns Strategy und Observer vorgestellt. Als Vertreter der Architekturmuster werden das Layers und das Model-View-Controller Muster vorgestellt. Zu guter Letzt werden die J2EE spezifischen Muster Business Delegate, Transfer Object und Session Facade vorgestellt, da diese im auf Enterprise JavaBeans basierenden Serversystem des Software Engineering Projekts zur Anwendung kommen. Hierbei wird auf die Konsequenzen, sowie die Anwendbarkeit der verschiedenen Muster eingegangen und ein Einblick in die Anwendung der Muster gegeben. 2

3 Inhaltsverzeichnis Kurzfassung Einleitung Definitionen Design Pattern Softwarearchitektur Architectural Pattern Entwurfsmuster Observer Strategy Architekturmuster Layers Model-View-Controller (MVC) J2EE spezifische Entwurfsmuster Verwendung innerhalb des Projekts Business Delegate Session Facade Transfer Object Literaturverzeichnis

4 1. Einleitung Design Patterns (Entwurfsmuster), erlauben Softwareentwicklern Lösungen für bekannte Probleme in der objektorientierten Programmierung wiederzuverwenden, ohne dabei das grundlegende Konzept der Lösung jedes Mal neu entwickeln zu müssen. Dabei profitiert der Entwickler von dem bewährten Lösungskonzept, das durch zahlreiche Erfahrungen stetig weiterentwickelt wurde. In den vorgestellten Mustern wird jeweils nur auf die wichtigsten Aspekte näher eingegangen um einen Überblick zu Mustern bieten zu können. Zunächst werden im Kapitel 2 einige grundlegende Begriffsdefinitionen erläutert. Auf Grundlage dessen werden im dritten Kapitel zwei klassische Entwurfsmuster Observer und Strategy vorgestellt. Das Kapitel 4 behandelt zwei Beispiele für Architectural Patterns (Architekturmuster), nämlich das Layers Muster aus dem Bereich Mud-to-structure und das Model-View-Controller Muster aus dem Bereich interaktiver Systeme. Das fünfte Kapitel stellt die J2EE spezifischen Muster Business Delegate, Transfer Object und Session Facade vor. Diese Muster wurden ausgewählt, da das Software Engineering Projekt die Entwicklung einer Lehrveranstaltungsverwaltung auf Basis von Enterprise JavaBeans umfasst und diese J2EE spezifischen Muster in dieser Lehrveranstaltungsverwaltung zur Anwendung kommen. 2. Definitionen 2.1. Design Pattern Ein Design Pattern (Entwurfsmuster) beschreibt die konzeptionelle Lösung eines wiederkehrenden Problems in der objektorientierten Programmierung. Ein Entwurfsmuster besteht aus vier essentiellen Elementen: Dem Namen des Entwurfsmusters, der zur Identifizierung und Beschreibung eines Design Problems dient. Durch die Namen der Entwurfsmuster wird dem Entwickler ein geeignetes Vokabular zum Diskutieren über Design Probleme an die Hand gegeben. Es erlaubt effizient Entwicklern das Problem oder die Lösung zu schildern, ohne weitreichende Erklärungen liefern zu müssen. Der Beschreibung des Problems, für das ein Entwurfsmuster eine Lösungsstrategie liefert. Es beschreibt spezifische Strukturen oder Design Probleme, die für die Anwendung des Entwurfsmusters sprechen. Der Lösung, die eine abstrakte Beschreibung darstellt, wie das Problem gelöst werden kann. Da Entwurfsmuster keine speziellen Lösungen bieten, können sie nur die Rollen der einzelnen Elemente darstellen und wie diese miteinander interagieren. Den Folgen, die durch die Anwendung des Entwurfsmusters eintreten, da der Einsatz meistens einen Kompromiss darstellt. Entwurfsmuster haben immer Konsequenzen, die bei der Entscheidung, ob und welches Muster eingesetzt werden soll, beachtet werden müssen. Sie wirken sich auf bestimmte Aspekte wie Erweiterbarkeit oder Flexibilität aus. Hinzu 4

5 kommt, dass einige Muster aufgrund der gewählten Programmiersprache eventuell nicht oder nur in abgewandelter Form einsetzbar sind Softwarearchitektur Die Softwarearchitektur ist eine Beschreibung der Subsysteme und der Komponenten eines Softwaresystems. Weiterhin beschreibt sie das Zusammenspiel der Komponenten, sowie die Beziehungen zwischen ihnen. Die Softwarearchitektur ist eine globale Eigenschaft des Systems und wird meist durch nicht-funktionale Eigenschaften bestimmt wie Wartbarkeit, Modifizierbarkeit, Flexibilität oder Erweiterbarkeit. Eine einmal aufgebaute Softwarearchitektur ist im Nachhinein schwer zu ändern, da sie das ganze System betrifft. Deshalb ist es wichtig im Vorfeld einen Plan der Softwarearchitektur aufzustellen und zu prüfen. Das Definieren einer geeigneten Softwarearchitektur ist somit einer der wichtigsten Punkte beim Entwurf von Software Architectural Pattern Ein Architectural Pattern (Architekturmuster) ist auf einer höheren Abstraktionsebene als Entwurfsmuster und befasst sich nicht mit lokalen Entwürfen von Komponenten, sondern liefert ein globales Konzept für das Gesamtsystem. Dieser Entwurf hilft dabei eine globale Systemeigenschaft herzustellen, die von der Softwarearchitektur gewünscht ist, wie Erweiterbarkeit, Wartbarkeit oder Performance. Die verschiedenen Architekturmuster lassen sich in vier verschiedene Bereiche einordnen: Mud-to-structure: Unter diese Rubrik fallen alle Architekturmuster, die dabei helfen ein System aus zahlreichen Komponenten zu organisieren. Verteilte Systeme: Dieser Bereich enthält Architekturmuster, die für die Verwendung von Diensten und Ressourcen in Netzwerken gedacht sind. Interaktive Systeme: In diesen Bereich fallen alle Architekturmuster, die sich auf die Interaktion eines Softwaresystems mit Menschen spezialisieren. Adaptive Systeme: Architekturmuster dieses Bereichs widmen sich vorrangig der Erweiterbarkeit und der Anpassungsfähigkeit von Softwaresystemen. 5

6 3. Entwurfsmuster 3.1. Observer In objektorientierten Systemen hat man häufig Komponenten, die sehr eng zusammenarbeiten oder bei Veränderungen aufeinander reagieren. Es ist möglich diese Komponenten in den Klassen statisch zu verankern und so den Zugriff für die Benachrichtigung zu ermöglichen. Das ist jedoch sehr unflexibel und eng gekoppelt. Sobald ein neues Element benachrichtigt werden soll, muss die Klasse angepasst werden. Somit ist auch das System schlecht erweiterbar. Der Einsatz des Observer Musters kann dieses Problem lösen. Der Lösungsansatz sieht eine lose Kopplung der kommunizierenden Komponenten vor, um so mehr Flexibilität zu erreichen. Dieses Entwurfsmuster sollte angewendet werden, wenn die Änderung eines bestimmten Objekts Änderungen an anderen Objekten nach sich zieht, wenn Objekte andere Objekte benachrichtigen können sollen ohne genau zu wissen welches Objekt oder wenn eine Abstraktion zwei Aspekte besitzt, die voneinander abhängig sind. Letzteres ermöglicht eine individuelle Wiederverwendung der einzelnen Aspekte. Abbildung Beim Observer Muster unterscheidet man vier schiedene Teilnehmer (Abbildung 3.1.1): Das Subject (Beobachtungsgegenstand) stellt ein Interface zur Verfügung um Beobachter hinzuzufügen oder wieder zu entfernen, sowie eine Methode zur Benachrichtung aller Beobachter. Der Observer (Beobachter) stellt ein Interface zur Verfügung für die Aktualisierung der konkreten Beobachter im Falle einer Benachrichtigung. Das ConcreteSubject (konkreter Beobachtungsgegenstand) implementiert das Interface des Beobachtungsgegenstands und besitzt einen Zustand, der für die Beobachter von Bedeutung sein kann. Bei einer Änderung dieses Zustands benachrichtigt der konkrete Beobachtungsgegenstand seine Beobachter. Der ConcreteObserver (konkreter Beobachter) hält eine Referenz auf den zu beobachtenden, konkreten Beobachtungsgegenstand. Weiterhin speichert er dessen Zustand, der konsistent gehalten werden soll. Der konkrete Beobachter implementiert das 6

7 Interface des Beobachters und stellt die Methode zur Verfügung, die für die Konsistenz der Zustände zwischen konkreten Beobachtern und konkreten Beobachtungsgegenständen sorgt. Die konkreten Beobachter registrieren sich zunächst bei den gewünschten, konkreten Beobachtungsgegenständen. Danach benachrichtigen die konkreten Beobachtungsgegenstände jeden Beobachter über die Benachrichtigungsfunktion des Interfaces des Beobachtungsgegenstands über Änderungen an ihrem Zustand. An den einzelnen, konkreten Beobachtern wird die vom Beobachter Interface zur Verfügung gestellte Aktualisierungsfunktion aufgerufen. Die benachrichtigten, konkreten Beobachter fordern nun über die gehaltene Referenz den Zustand des zu beobachtenden Objekts an und gleichen ihn mit ihrem internen Zustand ab. Die Verwendung des Observer Musters ermöglicht uns die lose Kopplung zwischen konkreten Beobachtungsgegenständen und konkreten Beobachtern, da die konkreten Beobachtungsgegenstände nur eine Liste von Beobachtern besitzen, also lediglich gegen ein Interface arbeiten. Weiterhin erlaubt uns dieses Design eine Broadcast-Kommunikation. Ein konkreter Beobachtungsgegenstand adressiert seine Benachrichtigung nicht, sondern sendet sie an alle Beobachter. Die einzige Aufgabe des konkreten Beobachtungsgegenstandes ist die Benachrichtigung ihrer Beobachter. Wie die Benachrichtigungen behandelt werden liegt in der Verantwortlichkeit der konkreten Beobachter, die das Interface der Beobachter implementieren. Leider hat die Verwendung des Observer Musters auch Nachteile: Es wird normalerweise bei einer Benachrichtigung nicht mitgeteilt, was sich am Zustand des Beobachtungsgegenstands verändert hat, so dass große Anfragemengen zustande kommen können, die eventuell keine Auswirkungen oder weitere Aktualisierungen an abhängigen Objekten zur Folge haben, so dass eine Flut von Aktualisierungen die Performance verringert. Ausserdem können auch scheinbar harmlose Operationen zu unerwarteteten Benachrichtigungen führen, wie das Auslesen einer Eigenschaft. Beispielsweise könnte die Anzahl der Anfragen an diese Eigenschaft mitgezählt werden. Dem Problem, dass bei der Benachrichtigung nicht mitgeteilt wird, was sich verändert hat, kann durch entsprechend angepasste Benachrichtigungsmethoden entgegengewirkt werden. Dies koppelt die Komponenten jedoch wieder enger aneinander und diese Zusatzinformationen sind eventuell nicht für alle Beobachter interessant, so dass unnötige Daten versendet werden. Je nach Anwendungsfall muss also abgewägt werden, welche Konsequenzen man in Kauf nehmen möchte Strategy In Algorithmen, die viele Varianten der Ausführung haben trifft man häufig auf große Verzweigungsblöcke um den gewünschten Ablauf auszuwählen. Dieser Code ist schwer leserlich aufgrund der vielen Bedingungen und lässt sich in der objektorientierten Programmierung besser lösen: Die gleiche Aufgabe eines großen Verzweigungsblocks können verschiedene Objekte übernehmen, wenn die verschiedenen Algorithmen in verschiedenen Klassen untergebracht werden. Diese Eigenschaft macht sich das Strategy Muster zu Nutze und bietet somit eine Lösung für dieses Problem. Das Strategy Muster ermöglicht es Familien von Algorithmen zusammenzufassen, indem die verschiedenen Aspekte in Strategien verpackt werden und diese benutzen um den Algorithmus zu 7

8 variieren. Es empfiehlt sich das Entwurfsmuster Strategy anzuwenden, wenn viele zusammenhängende Klassen sich nur in ihrem Verhalten unterscheiden oder verschiedene Varianten eines Algorithmus benötigt werden. Weiterhin kann es benutzt werden, wenn das oben genannte Problem mit großen Verzweigungsblöcken vorliegt. Abbildung 3.2. Beim Strategy Muster unterscheidet man zwischen drei verschiedenen Teilnehmern (Abbildung 3.2.1): Dem Kontext, innerhalb dessen verschiedene Algorithmen ähnlichen Typs situationsabhängig ausgeführt werden sollen. Der Kontext kann ein Interface zur Verfügung stellen, um den Strategien Zugriff auf seine Daten zu gewähren. Der Nutzen hiervon wird in der späteren Anwendungserklärung deutlich. Der allgemeinen Strategie, die ein Interface darstellt für konkrete Strategien und somit als Schnittstelle für den Kontext und die konkreten Strategien dient. Der konkreten Strategie, die die Implementierung einer Variante des Algorithmus darstellt. Um dieses Entwurfsmuster zu verwenden definiert man sich zunächst ein Interface für die Strategie, mit Hilfe dessen man die konkreten Strategien benutzen kann. Nun werden verschiedene Strategien implementiert, die alle das Interface der allgemeinen Strategie implementieren. Beim Aufruf des Kontextes wird ihm vom Client nun eine konkrete Strategie übermittelt, mit Hilfe derer er das Problem bearbeiten soll. Ähnlich dem dynamischen Binden operiert der Kontext nun statisch auf einem Interface, doch zur Laufzeit werden die Aufrufe an ein konkretes Strategieobjekt delegiert. Anstatt die verschiedenen Funktionalitäten in Strategien auszulagern, könnte man auch Subtyping einsetzen, indem man für jede Funktionalität einen Subtyp vom Kontext erstellt und je nach Situation die entsprechende Subklasse des Kontexts verwendet. Dies hat jedoch den entscheidenden Nachteil, dass die Strategie im Nachhinein nicht mehr verändert werden kann ohne den Kontext erneut zu erstellen. Außerdem erhöht es die Komplexität des Kontextes und erschwert somit das Verständnis der Komponente. Dies wirkt sich auch negativ auf die Erweiterbarkeit aus. Weiterhin koppelt es den Algorithmus stark an den Kontext, so dass auch die Wiederverwendung darunter leidet. Aus diesem Grund sollte man stattdessen Interfaces verwenden. Für die korrekte Arbeit einer Strategie werden in den meisten Fällen Daten benötigt. Auch hier gibt es wieder zwei Alternativen, wie die Übertragung von Daten realisiert werden kann. Einerseits 8

9 können alle benötigten Daten der Strategie beim Aufruf übergeben werden. Dies hat den Vorteil, dass die Strategien wiederverwendbar bleiben und nur lose an den Kontext gekoppelt sind. Jedoch kann es auch simple Strategien dieses Algorithmus geben, für die das volle Spektrum der mitgegebenen Parameter unnötig ist. Eine zweite, mögliche Variante ist den Kontext selbst als Argument zu übergeben und über die oben bereits erwähnte Schnittstelle einen Zugriff auf die Daten des Kontextes zu ermöglichen. Dies lässt den Strategien die Möglichkeit, nur die für sie relevanten Daten vom Kontext abzufragen. Leider koppelt dies die Strategien auch stärker an den Kontext, wodurch diese schlechter wiederzuverwenden sind. Der Client hat durch die verschiedenen Strategien die Möglichkeit situationsbedingt zu arbeiten. Beispielsweise können Strategien mit der gleichen Kernfunktionalität existieren, die sich aber in Speicherbedarf und Rechenleistung unterscheiden. Um jedoch die Möglichkeiten dieses Entwurfsmusters voll auszunutzen ist es für den Client nötig alle Strategien für einen Kontext zu kennen, denn nur dann kann er sie auch einsetzen. Weiterhin hat die Benutzung dieses Entwurfsmusters eine erhöhte Anzahl an Klassen zur Folge, da für jede konkrete Strategie eine neue Klasse eingeführt werden muss. 4. Architekturmuster 4.1. Layers Anwendungen bestehen aus einer Vielzahl von Komponenten. Ungeordnet wird diese Vielzahl zu einem unüberschaubaren und schlecht nachvollziehbaren System. Die Folge sind schlechte Erweiterbarkeit und Schwierigkeiten bei der Wartung. Um ein wenig Ordnung in die Architektur zu bringen kann man das Layers Muster benutzen. Vor allem wenn die Software so gestaltet ist, dass es Funktionen auf unterschiedlichen Ebenen gibt, also dass Funktionen der höheren Ebene sich durch Funktionsaufrufe aus den unteren Ebenen erfüllen lassen, empfiehlt es sich das System nach dem Layers Muster zu organisieren. Es gruppiert die verschiedenen Komponenten in einzelne Schichten. Jede Schicht zeichnet sich dadurch aus, dass ihre Komponenten auf der gleichen Ebene der Abstraktion liegen. Jede Schicht definiert eine Schnittstelle zu der Funktionalität, die sie zur Verfügung stellt. Weiterhin wird die Kommunikation zwischen den Schichten festgelegt. Eine Schicht darf nur mit der unter ihr liegenden Schicht kommunizieren und dies auch nur über die Schnittstelle. Dies ist die strenge Formulierung des Layers Musters, jedoch gibt es auch den Ansatz des Relaxed Layered Systems, das den Zugriff auf alle Schichten unterhalb erlaubt. Dies hat zwar einen Gewinn für die Performance und die Flexibilität zur Folge, wirkt sich jedoch negativ auf die Wartbarkeit des Systems aus, da bei Änderungen der Schnittstelle einer Schicht alle mit ihr arbeitenden Schichten angepasst werden müssen. Daher sollte diese Variante nur mit Bedacht eingesetzt werden. Im Folgenden wird nur das klassische Layers Muster betrachtet, in dem die Kommunikation ausschließlich auf die darunter liegende Schicht beschränkt ist. Diese Beschränkung hat zur Folge, dass die Kopplung zwischen den Schichten gelöst wird und die Schichten austauschbar werden, da sich Änderungen an der Schnittstelle einer Schicht nur auf die darüber liegende Schicht auswirken 9

10 und alle anderen Schichten davon unberührt bleiben. Somit kann auch eine Schicht aus einem System extrahiert und in ein anderes System eingebaut werden. Liegt eine Schichtenarchitektur vor, läuft der Aufruf einer Methode durch einen Client folgendermaßen ab: Der Aufruf geschieht an der höchsten Schicht. Diese wiederum greift nun auf die Funktionalitäten der darunter liegenden Schicht zu. Dies setzt sich solange fort, bis die Anfrage ausgeführt werden konnte. Die Rückgabewerte werden entsprechend verarbeitet und an die oberste Schicht zurückgereicht, die nach eventuellen Transformationen ein Ergebnis liefert. Dies ist nur eines der möglichen Szenarien und ist eine reine top-down Kommunikation. Es kann durchaus auch eine bottom-up Architektur aufgebaut werden, in der die unteren Schichten Benachrichtigungen (Notifications) an die darüber liegenden Schichten senden. Natürlich ist es möglich, diese beiden Arten der Kommunikation zu verbinden. Dies hat jedoch eine stärkere Kopplung der einzelnen Schichten zur Folge, da eine Schicht Abhängigkeiten zu der über ihr und der unter ihr liegenden Schicht besitzen würde. Ein Beispiel für das Layers Muster ist der Aufbau des Netzwerkprotokolls. Anwendungen arbeiten auf der höchsten Schicht. Diese gibt ihre Anfragen an die darunterliegende Schicht. Dies setzt sich bis zur physischen Ebene fort, in der die Daten dann über das Netzwerk transportiert werden. Diese Architektur ist eine solche Kombination von bottom-up und top-down Kommunikation, da Anfragen auf der untersten Schicht, der physikalischen Schicht, entgegen genommen und nach oben weitergereicht werden. Leider besitzt diese Architekturform auch ein paar Schwierigkeiten. Durch die Restriktion der Kommunikation zwischen den Schichten müssen Anfragen zum Teil durchgereicht werden. Dies führt zu Performanceeinbußen. Weiterhin besteht eine große Schwierigkeit in der Anwendung dieses Musters die korrekte Anzahl an Schichten zu bestimmen. Eine zu große Anzahl erhöht den Kommunikationsaufwand und den Performanceverlust durch die Transformation von Eingabe- zu Ausgabeparametern. Außerdem wird die Komplexität des Systems unnötig erhöht. Nimmt man hingegen eine zu geringe Anzahl an Schichten sind die Grenzen zwischen ihnen eventuell unklar und das Problem, weshalb diese Architektur gewählt wurde, nämlich eine klare Ordnung in die Komponenten zu bringen, wird nur zum Teil gelöst. Ebenfalls schöpft man die Möglichkeiten der Wiederverwendung und der Austauschbarkeit dieser Architektur dann nicht voll aus. Somit ist es bei dieser Architektur wichtig im Vorfeld genau zu planen und fundierte Entscheidungen über die verwendete Anzahl an Schichten zu treffen. Abbildung

11 Im Software Engineering Projekt wird dieses Architekturmuster verwendet und unterteilt das Serversystem in vier Schichten (Abbildung 4.1.1): Die Session Facade, die die Schnittstelle für den Client darstellt und eine logische Gruppierung der Funktionen bietet, sowie die darunter liegende Geschäftslogik nach außen hin versteckt. Den Application Service, der von der Session Facade angesprochen wird und die Geschäftslogik des Systems zur Verfügung stellt. Hier spalten sich die Aufrufe in mehrere Unteraufrufe an Methoden aus der gleichen oder der darunter liegenden Schicht auf. Der DAO (Data Access Object) Schicht, die für jegliche Operationen auf den Entity Beans dient. In dieser Schicht werden Daten ermittelt und bearbeitet, sowie Transfer-Objekte konstruiert. Die Datenbankschicht, die aus Entity Beans besteht und die Datenhaltung des Systems übernimmt. Diese Schicht umfasst lediglich die Definitionen der Entity Beans, sowie Methoden um Transfer-Objekte einzulesen oder zu generieren Model-View-Controller (MVC) Ein weiteres, sehr häufiges Problem in Softwaresystemen ist, dass man auf ein Modell viele verschiedene Sichten hat und diese durch Benutzereingaben ständig verändert werden können. Solch eine Änderung soll natürlich in allen Sichten sofort dargestellt werden, so dass jede Sicht stets mit aktuellen Daten arbeitet. Abbildung

12 Um dieses Problem zu lösen entwickelte Trygve Reenskaug das Architekturmuster Model-View- Controller und implementierte es in Smalltalk. Zur Verwirklichung dieses Architekturmusters ist die Benutzung des Observer Musters ausschlaggebend. Das System wird zunächst in drei Arten von Komponenten zerlegt (Abbildung 4.2.1): Das Modell, das für die gesamte Datenhaltung verantwortlich ist und die beiden anderen Arten von Komponenten benachrichtigt, sobald Änderungen vollzogen worden sind. Es ist komplett unabhängig von verschiedenen Datenrepräsentationen und enthält allein die Kernanwendung des Systems. Der Controller, der für die Behandlung von Benutzereingaben verantwortlich ist und diese in Manipulationen der Ansicht oder der Daten umsetzt. Den View (Sicht), der die Darstellung der Daten für den Benutzer übernimmt. Die Modellkomponenten agieren in dem System als Beobachtungsgegenstände und führen eine Liste von Beobachtern. Ebenso implementieren sie die Schnittstelle, einen Beobachter hinzuzufügen, zu entfernen oder alle registrierten Beobachter zu benachrichtigen. Hinzu kommt die Funktionalität des Modells, Daten und Dienste zur Verfügung zu stellen und Daten zu verarbeiten. Die Controller und die Sichten übernehmen die Rolle des Beobachters und bilden zusammen die Benutzerschnittstelle des Systems. Sie registrieren sich zu Beginn bei beliebig vielen Modellkomponenten als Beobachter und fordern dabei alle für sie relevanten Daten an. Mit diesen Daten arbeiten sie dann solange, bis sie vom Modell benachrichtigt werden, dass es eine Änderung gab, woraufhin sie sich erneut mit dem Modell synchronisieren. Somit wird gewährleistet, dass immer aktuelle Daten zur Verwendung kommen. Weiterhin referenzieren sich Controller und Sicht gegenseitig, wodurch dem Controller die Möglichkeit gegeben wird Anfragen des Benutzers, wie beispielsweise das Verschieben des Bildausschnitts direkt an den View weiterzugeben. Die Sicht erhält dadurch die Möglichkeit seinen Controller auszutauschen um dem Benutzer eine andere Schnittstelle zur Manipulation zur Verfügung zu stellen. Als Beispiel für das Architekturmuster Model-View-Controller wird in der Literatur häufig ein Informationssystem für Wahlen angeführt. Die Daten der Abstimmung bilden das Modell. Auf dieses Modell gibt es verschiedene Sichten, wie eine Verteilung der Sitze oder die Darstellung der Wahlergebnisse als Balken- oder Tortendiagramm. Bei dieser Darstellung ist es natürlich von äußerster Wichtigkeit, dass alle Sichten bei jeder Änderung aktualisiert werden. Weiterhin gibt es einen Controller, der das Wählen für Parteien implementiert. Die Benutzerinteraktion mit diesem System geschieht über die Stimmabgabe, die der Controller entgegen nimmt und an das Modell weiterleitet. Dieses vermerkt die neue Stimmenanzahl und leitet die Aktualisierung aller Controller und Sichten ein. Diese benachrichtigten Komponenten fordern nun neue Daten vom Modell an und präsentieren dem Benutzer die neue Verteilung der Stimmen. Der Einsatz einer solchen Architektur ist natürlich auch mit einigen Konsequenzen verbunden. Es ist möglich mehrere Sichten auf das gleiche Modell zu haben und diese auch während der Laufzeit zu verändern oder gar auszutauschen. Auch das Hinzufügen beziehungsweise Entfernen einer Sicht ist möglich. Dies ermöglicht es verschiedene Sichten für die gleiche Ansicht zu erstellen, um verschiedene Look & Feels zur Verfügung zu stellen. Weiterhin zeigen durch den Einsatz des Observer Musters alle Sichten stets aktuelle Daten an. Als Nachteil kann man anführen, dass diese Architektur durch die Aufteilung in drei Arten von Komponenten und die Verwendung des Observer 12

13 Musters die Komplexität des Systems erhöht. Weiterhin sind Sicht und Controller sehr eng miteinander gekoppelt. Dies verhindert in den meisten Fällen eine Wiederverwendung einzelner Controller oder Sichten. Aufgrund dieser engen Kopplung ist es auch schwer die Grenze zwischen Controller und Sicht zu ziehen. Aus diesem Grund fallen in einigen Systemen diese beiden Konstrukte zusammen. Doch sind nicht nur Sicht und Controller eng aneinander gebunden, sondern auch eng an das Modell, da sie direkt auf die Methoden des Modells zurückgreifen um ihre Daten zu synchronisieren. Änderungen an den Interfaces des Modells ziehen auch Änderungen an sämtlichen Controllern und Sichten nach sich, die mit dem Modell arbeiten. Ebenso kann eine Benutzeraktion viele Aktualisierungen zur Folge haben. In einem solchen Fall sind nicht unbedingt alle Sichten an den Aktualisierungen interessiert. Minimierte Sichten beispielsweise, sollten erst aktualisiert werden, wenn sie wieder angezeigt werden. Ebenso können je nach der Schnittstelle der Modelle mehrere Aufrufe an das Modell von einer Sicht nötig sein um alle Daten zu sammeln, die für die Anzeige notwendig sind. Viele der Daten werden sich bei Aktualisierungen nicht verändern, so dass diese Anfragen nur unnötig die Performance des Systems verschlechtern, wenn sie häufig auftreten. Das Zwischenspeichern von Daten in der Sicht kann die Reaktionszeit in solchen Systemen verbessern. Hier ergibt sich jedoch wieder das Problem, dass die zwischengespeicherten Daten aktuell gehalten werden müssen, also muss bei einer Aktualisierungsbenachrichtigung die Information darüber enthalten sein, welche Daten sich verändert haben. Die Konsequenzen daraus wurden bereits im Observer Muster dargestellt. 5. J2EE spezifische Entwurfsmuster 5.1. Verwendung innerhalb des Projekts Die drei folgenden Muster sind im Software Engineering Projekt benutzt worden, aufgrund der auf Enterprise JavaBeans aufbauenden Projektstruktur. Auf Serverseite bieten Session Facades die Schnittstelle für das Business Delegate des Clients und stellen somit die Dienste des Servers zur Verfügung. Der Client besitzt Business Delegates, die für den Verbindungsaufbau des Clients zum Server verantwortlich sind und den Transport der Daten steuern. Die Datenübertragung zwischen Client und Abbildung Server findet hauptsächlich über Transfer-Objekte statt, um komplexe Daten zu übertragen und die Anzahl der Remoteaufrufe zu mindern. 13

14 5.2. Business Delegate Beim Aufbau von verteilten Anwendungen gibt es immer das Problem der Kopplung der verschiedenen Dienste des Systems. Ein Client muss den Ort der Dienste des Servers kennen, sowie eine Verbindung zu ihnen aufbauen. Dies ist meistens im Code der Geschäftslogik eingewebt schlecht aufgehoben. Es wäre schöner diese Funktionalität an einer Stelle zentral zu halten und für die Anwendung eine schmale Schnittstelle zu bieten, die sich um den Kommunikationsaufwand nicht mehr kümmern muss. Bei der Lösung dieses Problems hilft das Entwurfsmuster Business Delegate. Abbildung Beim Muster Business Delegate unterscheidet man zwischen vier verschiedenen Komponenten (Abbildung 5.2.1): Dem Client, der das Business Delegate über eine definierte Schnittstelle nutzt. Der Client kümmert sich um die Präsentation der Funktionalitäten und Daten. Dem Business Service, der auf dem Server die Dienste für den Client bereitstellt. Dem Lookup Service, der für die Auffindung des Servers und seiner Dienste zuständig ist. Dem Business Delegate, das die Schnittstelle für den Client implementiert. Weiterhin benutzt es den Lookup Service um eine Verbindung zum Server und seinen Diensten aufzubauen. Es sendet Anfragen an den Server und liefert dem Client die Ergebnisse der Anfragen. Business Delegates bieten dem Client Zugriff auf die Serverdienste stellvertretend für die eigentlichen Dienste. Sie bilden somit die unterste Schicht der Client Anwendung. Business Delegates bedienen sich des Lookup Services um die Anforderungen des Clients an die Dienste des Servers weiterzureichen. Sie kapseln also die komplette Funktionalität für den Netzwerkverkehr. Sie verstecken die Remoteaufrufe vor der Client Anwendung. In verteilten Anwendungen sind wiederholte Anfragen derselben Daten ein Problem, da sie viel Netzwerklast verursachen können. Diese zentrale Stelle ist daher ideal um Caching zu implementieren. Anstatt bei jedem Aufruf die Daten erneut vom Server anzufordern, können in dieser Schicht die Daten zwischengespeichert oder konkretere Anfragen gesendet werden, die nur die veränderten Daten mit dem Business Delegate synchronisieren. So ist die Client Anwendung unbelastet und nutzt weiterhin nur die schmale Schnittstelle zum Business Delegate. Weiterhin ist dies der Ort an dem Netzwerk Fehler abgefangen und behandelt werden sollten. Ist dies nicht möglich oder wurde von dem Serverdienst ein Fehler geworfen, so kann man im Business Delegate diese in Fehler für den Benutzer umwandeln. Dies verhindert, dass ungewollt 14

15 Informationen der Implementierung nach außen dringen und erlaubt es den Entwicklern dem Benutzer die genauen Spezifikationen der Implementierung zu ersparen. Durch das Einsetzen eines Business Delegates wird die Kopplung des Systems reduziert, da der Client nicht mehr eng an die Serverdienste gekoppelt ist, sondern ausschließlich an das Business Delegate. Der Client ist also unabhängig von der Implementierung der Geschäftslogik und könnte mit jedem Business Delegate arbeiten, dass dieselbe Schnittstelle zur Verfügung stellt. Weiterhin ist es möglich, dass das Business Delegate eine angepasste Schnittstelle für die Client Anwendung zur Verfügung stellt, die es dann in entsprechende Aufrufe an die Serverdienste übersetzt. Durch das saubere Trennen von Clientlogik und Netzwerkverwaltung wird das System auch wartbarer, da nur Änderungen der Schnittstelle des Business Delegates auch Änderungen in der Logik des Clients nach sich ziehen. Das Verstecken der Remoteaufrufe hat jedoch auch einen Haken: Da Aufrufe an das Business Delegate wie lokale Aufrufe von der Clientlogik behandelt werden, kann es zu zahlreichen Aufrufen kommen um eine einzelne Aufgabe zu erfüllen, die das Netzwerk stark belasten. Um dies zu verhindern müssen die Entwickler verstehen, dass das Business Delegate eine Schicht zur Kommunikation mit den Serverdiensten darstellt Session Facade In verteilten Systemen ist es notwendig Dienste nach außen hin verfügbar zu machen. Dies hat jedoch den entscheidenden Nachteil, dass zu große Schnittstellen entblößt werden, die schwer zu bedienen sind und Geschäftslogik enthüllen, die nicht nach außen verfügbar gemacht werden soll. Außerdem ist bei der Offenlegung der gesamten Geschäftslogik eine Vielzahl von fein granularen Schnittstellen vorhanden. Somit sind für die Erfüllung einer Anfrage unter Umständen mehrere Remoteaufrufe notwendig. Dies wiederum führt zu erhöhter Netzwerkbelastung. Abbildung

16 Der Einsatz von Session Facades wirkt diesem Problem entgegen. Bei der Session Facade unterscheidet man zwischen drei grundlegenden Komponenten (Abbildung 5.3.1): Dem Client, der auf die Funktionalität der Geschäftslogik zugreift indem er die Methoden der Session Facade aufruft. Der Session Facade, die Aufrufe an ihre Methoden durch Aufrufe von Methoden der Geschäftslogik erfüllt. Der Geschäftslogik, die der Session Facade die nötige Funktionalität zur Verfügung stellt. Diese kann sowohl aus Enterprise Beans als auch aus Datenzugriffsobjekten bestehen. Zur Implementierung von Session Facades werden Session Beans verwendet. Hier unterscheidet man zwischen zwei Arten, den zustandslosen (stateless) Session Beans und den zustandsspeichernden (stateful) Session Beans. Beide sind geeignet eine Session Facade darzustellen, jedoch gibt es entscheidende Unterschiede in der Funktionsweise. Je nach Art des Geschäftsprozesses, der mit der Session Facade dargestellt wird, reicht ein einzelner Aufruf an der Session Facade um die Aufgabe zu erfüllen. In solchen Fällen spricht man von nicht dialogorientierten Prozessen, die am besten mit zustandslosen Session Beans implementiert werden. Ist der Geschäftsprozess hingegen dialogorientiert, so dass er mehrere Aufrufe benötigt um den Dienst bereitzustellen, ist der Einsatz von zustandsspeichernden Session Beans anzuraten, da der Zustand zwischen den Aufrufen gespeichert werden muss. In den Session Facades kann man angepasste Schnittstellen definieren und vor allem nur die Teile der Geschäftslogik, die für entfernte Dienste interessant und verfügbar sein sollen. Diese Schnittstellen können nach logischen Funktionen gruppiert oder für verschiedene Clients angepasst sein. Die Benutzung von Session Facades mit angepassten Schnittstellen entkoppelt den Client von der konkreten Implementierung der Geschäftslogik und versteckt alle Abhängigkeiten und Interaktionen zwischen ihren Komponenten. Dies verschafft der Anwendung eine höhere Flexibilität, da sie nicht auf eine bestimmte Implementierung angewiesen ist. Außerdem fördert der Einsatz von Session Facades die Wartbarkeit, da Änderungen an der Geschäftslogik nicht auch im Client durchgeführt werden müssen. Dies macht die Geschäftslogik austauschbar gegenüber dem Client, da lediglich die Session Facade als konstanter Faktor berücksichtigt werden muss. Weiterhin erhöht der Einsatz von Session Facades die Performance des Gesamtsystems dahingehend, dass weniger Aufrufe über das Netzwerk transportiert werden müssen, da die in den Session Facades definierten Funktionen grobgranularer sind als es in den Business Objekten normalerweise der Fall ist. Die Kommunikation zwischen den einzelnen Business Objekten und der Transport von Daten zwischen ihnen sind von der Session Facade besser zu verwalten, denn sie sind in der Regel besser angebunden als die Clients, sei es durch ein internes Netzwerk oder die Ausführung innerhalb des gleichen Containers. Session Facades bilden also eine neue Schicht in der Serveranwendung, die für die Kommunikation mit Clients gedacht ist und ihnen die Serverdienste zur Verfügung stellen. Sie bilden die oberste Schicht seitens des Servers und kommunizieren mit den Business Objekten, um die an sie gestellten Anfragen zu bearbeiten. Diese Schicht ist ideal um ein zentrales Sicherheitsmanagement einzubinden mit dem Ziel Aufrufe von unbefugter Stelle zu blockieren. Auch bietet sie einen zentralen Punkt um die Transaktionskontrolle zu implementieren. Session Facades können zwar als Ballast angesehen werden, da sie in bestimmten Fällen nur die Anfragen der Clients an ein Business Objekt weiterleiten, doch sobald das System komplexer wird kann sich die Session Facade auch in dieser Hinsicht als 16

17 nützlich erweisen. Sie kann als Controller agieren und die Anfragen des Clients für die Business Objekte entsprechend anpassen Transfer Object In J2EE Anwendungen müssen in den meisten Fällen Daten über die Grenzen des Containers hinweg transportiert werden. Entity Beans oder Session Beans können jedoch nicht außerhalb ihres Containers existieren, da sie ohne den Container und seine Umgebung nur abstrakte Klassen sind. Um dieses Problem zu lösen kann man Transfer-Objekte benutzen. Abbildung Beim Einsatz von Transfer-Objekten sind drei verschiedene Komponenten beteiligt (Abbildung 5.4.1): Der Client, der ein Transfer-Objekt anfordert und verarbeitet oder seinerseits ein Transfer- Objekt erstellt und an einen der Serverdienste sendet. Das Geschäftsobjekt, das Transfer-Objekte generiert und als Antwort auf Anfragen an die Dienste des Servers durch den Client liefert oder Transfer-Objekte vom Client erhält und diese verarbeitet. Das Transfer-Objekt, das von Client oder Server erstellt und zwischen ihnen versendet wird. Transfer-Objekte sind reine Datenobjekte mit Hilfe derer man Daten auch außerhalb des Containers transportieren kann. Ein Transfer-Objekt sollte möglichst keine Funktionalität beinhalten. Es besteht aus Attributen, sowie deren Methoden zum lesenden und schreibenden Zugriff. Bei einem Remoteaufruf des Clients an den Server werden die benötigten Daten im Server ermittelt. Nun wird ein Transfer-Objekt erstellt und mit den Daten gefüllt. Die Methoden zum Erstellen eines Transfer-Objekts mit Daten aus einem Business Objekt oder zum Einspielen von Änderungen werden von dem jeweiligen Business Objekt zur Verfügung gestellt. Somit ist ein Aktualisieren der Daten und das Erstellen von Transfer-Objekten möglich ohne eine Vielzahl von Methoden zum Zugriff manuell aufrufen zu müssen. Dieses vom Server erstellte Objekt wandert nun als Antwort zum Client. Dieser wiederum hat die Möglichkeit dieses Objekt zu verändern und in einer weiteren Anfrage zu benutzen. Jedoch kann auch der Client ein Transfer-Objekt erstellen und an den Server senden. 17

18 Dieser liest die entsprechenden Daten aus und agiert dementsprechend. Das Transfer-Objekt muss also auch dem Client zur Verfügung gestellt werden, ist also eine gemeinsam genutzte Ressource. In der Entwicklung kann es schnell passieren, dass komplexe Daten übermittelt werden müssen, die auch aus mehreren Business Objekten zusammen gesetzt sind. Für solche Anwendungsfälle kann man komplexe Transfer-Objekte erstellen, deren Attribute wiederum Transfer-Objekte sind. Das Transfer-Objekt bietet die Möglichkeit mehr Daten mit einem Aufruf zu transferieren als es mit feingranularen Methoden möglich wäre. Dadurch entsteht weniger Netzwerklast, da die Anzahl der Remoteaufrufe reduziert wird. Der Einsatz von Transfer-Objekten führt jedoch auch zu neuen Problemen. Da sie sowohl für den Transport aus dem System als auch den Transport in das System dienen, muss es möglich sein zu erkennen, ob es sich um ein bereits bestehendes Objekt oder einen bestehenden Datensatz handelt und dieser synchronisiert werden muss, ob und welche Änderungen vorgenommen wurden und ob diese Änderungen überhaupt erlaubt sind. Sollten mehrere Clients gleichzeitig Änderungen an den gleichen Daten vornehmen wollen, muss dieser Konflikt gelöst werden. Dies ist zum Beispiel durch eine Versionsnummer oder einen Zeitstempel der letzten Änderung möglich. Durch die Überprüfung, ob ein aktuelles Transfer-Objekt gesendet wurde, können überschreibende Aktualisierungen der Daten verhindert werden. In einem solchen Fall wird eine entsprechende Meldung zurückgegeben und der Client muss eine aktuelle Version des Transfer-Objektes anfordern, auf dem er dann die Änderungen gegebenenfalls erneut durchführen kann. In extremen Situationen könnte dies zum Blockieren eines Clients führen, der seine Aktualisierungen aufgrund veralteter Transfer-Objekte nie durchführen kann, da stetig andere Clients ihre Aktualisierungen einspielen. Diese Überprüfungsaufgaben entstehen zusätzlich zur eigentlichen Geschäftslogik. Weiterhin können viele verschiedene Transfer-Objekte entstehen, die die Masse der Objekte in dem System weiter erhöhen. 18

19 6. Literaturverzeichnis [1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns Elements of Reusable Object-Oriented Software, Addison-Wesley, 1997 [2] F.Buschmann, R.Meunier, H.Rohnert, P.Sommerlad, M.Stal: Pattern-Oriented Software Architecture A System of Patterns, Wiley, 1996 [3] [4] [5] [6] [7] 19