Analyse und Entwurf objektorientierter Systeme

Transkript

1 Analyse und Entwurf objektorientierter Systeme Fachbereich der FHW Berlin Teil 4 Modellbildung in der Entwurfsphase 4.2 Entwurfsmuster Modul WI111: Objektorientierte Programmierung Fachrichtung Wirtschaftsinformatik Prof. Dr. Gert Faustmann Fachbereich Berufsakademie der FHW Berlin

2 Teil 1 Architekturmuster

3 Architekturmuster Definition SW-Architektur Eine SW-Architektur ist eine Beschreibung der Subsysteme und Komponenten eines SW-Systems und der Beziehungen zwischen ihnen. Eine Komponente ist ein in sich gekapselter Teil eines SW-Systems mit einer Schnittstelle. Mit der Größe und Komplexität von SW-Systemen wächst die Wichtigkeit nichtfunktionaler Eigenschaften wie Änderbarkeit, Interoperabilität, Effizienz, Zuverlässigkeit, Testbarkeit und Wiederverwendbarkeit. Architekturmuster bzw. allgemein Software-Muster haben zum Ziel oder fördern nichtfunktionale Eigenschaften von SW-Systemen.

4 Architekturmuster: Schichtenmodelle Ein Schichtenmodell gliedert ein SW-System in mehrere Abstraktionsebenen. Beispiel: Benutzeroberfläche (B), Verabeitung (V), Datenhaltung (D) Regeln: - Oberflächengestaltung und -verhalten nur in der Schicht B - Alle in der Analysephase definierten essenziellen Leistungen des Systems als API (Application Programming Interface) in der Schicht V - Datenbankzugriffe nur in der Schicht D, exportiert als API - Allgemein Zugriffe nur innerhalb der eigenen oder auf nächsttiefere Schicht Vorteile: - Gliederung - leichte Testbarkeit der APIs - Austauschbarkeit der Schichten B und D - Schicht F stellt Ergebnis der Analysephase dar

5 Architekturmuster: Broker-Systeme (I) Problem: Interagierende Komponenten in verteilter Umgebung Lösung: - Abhängigkeiten durch eigenständige Interprozeßkommunikation (abh. von Mechanismus, Programmiersprache, Serverstandort) - Wechsel von Systemkomponenten schwierig - systemabhängige Entwicklung Server 1 Proxy Server 2 Proxy Server 3 Proxy Broker Proxy Client 1 Proxy Client 1 direkte Kommunikation: Broker stellt Verbindung zwischen Client und Server her indirekte Kommunikation: Nachrichten gehen immer über Broker

6 Architekturmuster: Broker-Systeme (II) Beispiel: Stadtinformationssystem im WWW Server: Client: Informationen zum öffentlichen Nahverkehr, zu freien Hotelzimmern öffentliche Terminals, WWW-Browser, PDAs, Mobiltelefonen Vorteile: - Standortunabhängigkeit - Änderung der Server durch IDL-Stubs (Proxies) - Portierbarkeit (nur Broker + Neuübersetzung der Proxies) - Wiederverwendbarkeit von Diensten Nachteile: - Eingeschränkte Effizienz (Anzahl der Komponenten!) - Niedrige Fehlertoleranz (z.b. Versagen des Vermittlers) - Schwieriges Testen (Verteilte Komponenten)

7 Weitere Architekturmuster Pipes and Filters Verarbeitung von Datenströmen Jederzeit neue Anordnung der Filter Blackboard Anwendungen ohne deterministische Lösungsstrategie z.b.: Mustererkennung (Sprache, Signale, Molekülstrukturen) Presentation-Abstraction- Control Microkernel Hierarchie von Agenten, die über Kontrollmodule (Control) miteinander kommunizieren; Presentation = Nutzerschnittstelle, Abstraction = Funktionen Architektur für sich ändernde Systemanforderungen Minimaler funktionaler Kern, erweitert um zusätzliche Funktionen und kundenspezifische Teile Reflection Dynamische Änderungen der Struktur und des Verhaltens Basisebene enthält Anwendungslogik und Metaebene Informationen über ausgewählte Systemeigenschaften

8 Übung Entwerfen Sie ein Schichtenmodell für die Verwaltung eines Bankkontos. Überlegen Sie speziell, welche Informationen und welche Funktionen auf welchen Ebenen anzusiedeln sind! Sind weitere Architekturmuster für eine solche Anwendung denkbar? Geben Sie Aspekte an, die im Rahmen dieser Anwendung für bzw. gegen entsprechende Architekturen sprechen.

9 Teil 2 Entwurfsmuster

10 Klassen von Mustern A. Perspektive der Abstraktion Klassenbasierte Entwurfsmuster beschreiben Beziehungen zwischen Klassen, die während der Übersetzung festgelegt werden und durch Vererbung festgelegt werden. Objektbasierte Entwurfsmuster beschreiben Beziehungen zwischen Objekten, die zur Laufzeit geändert werden können. B. Perspektive der Aufgabe Erzeugungsmuster isolieren den Aspekt der Objekterzeugung und repräsentation. Beispiel: Singleton-Muster, Fabrikmethode-Muster Strukturmuster beschreiben, wie Klassen und Objekte zu größeren Strukturen zusammengesetzt werden. Beispiel: Proxy-Muster Verhaltensmuster beschreiben Interaktionen zwischen Objekten und Klassen. Beispiel: Publisher-Subscriber-Muster

11 Singleton-Muster Das Entwurfsmuster Singleton wird eingesetzt, wenn nur ein Objekt einer Klasse im System existieren darf. Dazu wird zunächst der Konstruktor vor einem externen Aufruf geschützt. Dann wird in der Klasse eine Klassenoperation instance() realisiert, die prüft, ob bereits ein Objekt dieser Klasse vorhanden ist. Ist noch kein Objekt vorhanden, wird ein neues Objekt erschaffen und eine Referenz zurückgeliefert. Singleton -uniqueinstance singletondata +instance() #Singleton() Im anderen Fall wird sofort die Referenz auf das bereits existierende Objekt geliefert. class Singleton{ private: static Singleton* uniqueinstance; protected: Singleton(); public: static Artikelliste* instance(); } Singleton* Singleton::instance(){ if (instance == 0){ instance = new Singleton(); } return instance; }

12 Beispiel Singleton-Muster Es soll eine Liste von Artikeln verwaltet werden. Dafür wird eine Klasse Artikelliste erschaffen, von der aber nur ein Objekt im System existieren darf. Dafür wird das Entwurfsmuster Singleton eingesetzt: Artikel Artikelliste static all: Artikelliste* Artikel[100]: Artikel* Artikelliste* instance(void) Das Objekt :Artikelliste verwaltet maximal 100 Artikelobjekte. Jedes Objekt im System, das Zugriff auf Artikel haben will, muss die statische Funktion instance der Klasse Artikelliste aufrufen, die eine Referenz auf das Objekt :Artikelliste liefert. Existiert dieses Objekt noch nicht, wird ein neues Objekt erschaffen. :Artikel :Artikel Objektdiagramm: :Artikel :Artikelliste :Artikel :Artikel

13 Fabrikmethode-Muster Zum Zeitpunkt der Erzeugung eines Objekts soll zwischen verschiedenen (Implementierungs-)Varianten gewählt werden können. Product definiert als abstrakte Klasse die Schnittstelle zu den konkreten Objekten <<abstract>> Product Creator create(...): Product Concrete Product1 Concrete Product2 <<create>> <<create>> In von Product abgeleiteten Klassen wird jeweils die Schnittstelle implementiert Creator speichert nur einen Verweis auf die abstrakte Basisklasse.

14 Beispiel Fabrikmethode-Muster Die Klasse Bestellung soll eine Liste von Positionen (Artikel und Menge) speichern. Diese Liste kann unterschiedlich realisiert werden. <<abstract>> List Falls die Bestellung häufig zu ändern ist, soll eine verkettete Liste benutzt werden. Im anderen Fall ist eine assoziative Liste für den schnelleren Zugriff auf Listenelemente zu nutzen. ArrayList LinkedList class Bestellung{... private List position; <<create>> <<create>> Bestellung Bestellung(...): Product public Bestellung(boolean oftzuaendern){ if (oftzuaendern){ position = new LinkedList(); } else { position = new ArrayList(); } } }

15 Proxy-Muster Das Muster kontrolliert den Zugriff auf ein Objekt mit Hilfe eines vorgelagerten Stellvertreterobjekts. Klient Subjekt Operation() Durch eine abstrakte Klasse wird eine gemeinsame Schnittstelle auf Proxy und Objekt definiert EchtesSubjekt Operation() echtessubjekt Proxy Operation() Der Proxy besitzt eine Referenz auf das echte Objekt. :Klient subjekt :Proxy echtessubjekt :EchtesSubjekt

16 Beispiel Proxy-Muster Das Muster kann z.b. für lokale Stellvertreter (Remote-Zugriff), virtuelle Objekte (bei hohen Kosten für Objekte), Zugriffsfilter und Smart-References (intelligenter Zeiger) eingesetzt werden. Das Beispiel zeigt, wie ein teures Objekt (z.b. Bild im Dokument) erst erzeugt wird, wenn es angezeigt werden soll. Editor Grafik Zeichne() Solange das Bild nicht angezeigt werden braucht, übernimmt ein Proxobjekt dessen Aufgaben (z.b. Liefern der Bildgröße). Bild Zeichne() echtessubjekt BildProxy Zeichne() if (bild == 0){ bild = ladebild(); } bild->zeichne();

17 Publisher-Subscriber-Muster Problem: Änderung von Daten, von denen viele Komponenten abhängen - Anzahl und Identität der Komponenten ist von vornherein nicht bekannt - Regelmäßiges Abfragen durch Komponenten nicht möglich (Aufwand) Lösung: Publisher register notify Subscriber Subscriber Subscriber push-modell: pull-modell: Senden aller geänderten Daten durch den Publisher Benachrichtigung über geänderte Daten

18 MVC-Muster (I) Problem: Flexible Darstellung und Verarbeitung von Informationen Lösung: - Änderungsanforderungen an der Benutzerschnittstelle - Unterschiedliche Anforderungen der Benutzer - Verwaltung von verschiedenen Varianten eines Systems ist teuer Nachricht Abfrage von Daten View View View Ansichten Publisher-Subscriber Model Ereignis + Daten Nachricht Abfrage von Daten Controller Controller Controller Ereignisse

19 MVC-Muster (II) Beispiel: Eingabe und Darstellung von Wahldaten Modell verwaltet aufaddierte Stimmen Abfrage von Stimmenzahlen für Ansichten Änderung der Daten für Steuerungskomponenten Ansichten: Balkendiagramm, Kuchendiagramm, Tabelle (verbunden mit Steuerung zur Eingabe von Einträgen) Vorteile: - Mehrere Ansichten mit integrierter Synchronisation - Austauschbare Ansichten und Steuerungen - Einfache Portierbarkeit (nur Views und Controller systemabhängig) Nachteile: - Erhöhte Komplexität - zu viele Aktualisierungen - getrennte Wiederverwendung von View und Controller unwahrscheinlich - schwierige Integration mit Oberflächenwerkzeugen (GUI-Builder)

20 Übung Entwerfen und realisieren Sie eine Anwendung, die das Publisher-Subscriber- Muster einsetzt: Der Publisher verwaltet eine zentrale Datenstruktur (z.b. ein int- Feld) und eine Zugriffsfunktion void change(void). Zwei Subscriber wollen informiert werden, wenn sich an diesen Daten etwas ändert (also die Zugriffsfunktion aufgerufen wurde). Die Zugriffsfunktion soll von einem vierten Modul (main) aufgerufen werden. Subscriber 1 Subscriber 2 register register notify Publisher notify Zentrale Daten Zugriff Main

21 Hilfen zur Übung Bei der Registrierung übergibt ein Subscriber dem Publisher einen Zeiger auf eine Funktion, die vom Publisher aufgerufen werden soll. Der Zeiger wird im Publisher gespeichert (Funktion register). Realisieren Sie im Publisher die Funktion void notify_all(void) die alle als Funktionszeiger gespeicherten Funktionen ausführt, sobald eine Änderung der Daten im Publisher stattgefunden hat. Der Aufruf erfolgt dann z.b. durch wenn notifylist.notify[i](); typedef void (*Tnotify) (void); // Typ Funktionszeiger struct{ Tnotify notify[100]; // 100 Subscriber möglich int anzahl; }notifylist; vereinbart wurde.

22 // // publisher.cpp // // Funktionszeiger als Typ typedef void (*Tnotify)(void); static struct{ Tnotify notify[100]; // 100 Subscriber int count; } notifylist; void register(void (*func)(void)){ notifylist.notify[notifylist.count++]=func; } void notify_all(){ for(int i=0; i<notifylist.count; i++){ notifylist.notify[i](); } } void change(){ // Daten ändern und // alle verständigen notify_all(); } void init(){ notifylist.count=0; } #include "publisher.h" #include "subscriber.h" void main(){ // Publisher initialisieren init(); // Subscriber anmelden lassen subscriber_reg(); // Aenderung der Daten change(); } // // subscriber.cpp // #include "publisher.h #include <iostream.h> // Weckfunktion void notify(){ cout << "Subscriber hat etwas bemerkt! ; } // Anmeldung beim Publisher void subscriber_reg(){ register(notify); }