8. Design-Phase Querschnittsthemen und Muster Softwaretechnik (CNAM)

Transkript

1 8. Design-Phase Querschnittsthemen und Muster Softwaretechnik (CNAM) Wintersemester 2009 / 2010 Prof. Dr. Bernhard Humm Hochschule Darmstadt, FB Informatik 1 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

2 Einordnung in den gesamten Kurs 1. Einführung 2. Vorgehensmodelle 3. Analyse: Anwendungsfälle 4. Analyse: Datenmodell 5. Analyse: Dialoge 6. Design: Architektur-Grundlagen 7. Design: Referenzarchitektur betriebliche Informationssysteme 8. Design: Querschnittsthemen und Muster 9. Programmierung, Konfigurationsmanagement 10.Test, Einführung, Qualitätsmanagement 11. Projektmanagement 2 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

3 Agenda Fehlerbehandlung Entwurfsmuster Performance Kontrollfragen

4 Kein Computersystem ohne Fehler Fehler stellen unerwünschtes Verhalten während der Ausführung eines Computersystems dar aufgrund von Programmierfehlern, z.b. Division durch Null aufgrund von technischen Problemen, z.b. Netzwerkfehlern aufgrund fehlerhafter Bedienung, z.b. Anwender gibt größeres von -Datum als bis -Datum ein aufgrund von Ausnahmen im Geschäftsprozess, z.b. Überweisung nicht möglich aufgrund einer Kontensperre Fehler kommen vor: Programmierfehler können durch gutes Design und Tests reduziert werden, aber in komplexen Systemen nie komplett vermieden werden Technische Probleme können reduziert werden, z.b. durch redundante Hardware, können aber auch nicht komplett vermieden werden Fehlerhafte Bedienung kann durch eine ergonomische Benutzeroberfläche reduziert werden, aber nie komplett vermieden werden Ausnahmen im Geschäftsprozess können immer vorkommen und sind unabhängig vom Computersystem Fehler können nicht vermieden werden. Daher müssen wir sie behandeln! 4 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

5 Ist das Problem mit Exceptions gelöst? Exceptions sind Sprachmittel aktueller Programmiersprachen wie Java, C++, C# etc. Aber: Exceptions führen nicht automatisch zu einem guten Design für Fehlerbehandlung. Sie sind sogar manchmal gar nicht angemessen zur Behandlung von Fehlern! Manchmal führen Exceptions zu neuem Spaghetti-Code: Exceptions sind das moderne GoTo GoTo considered harmful! Es gibt in der Java Community bislang keine allgemein akzeptierten Muster für Fehlerbehandlung, z.b. Wann Checked Exceptions verwenden, wann Unchecked Exceptions? Wo werden Exceptions gefangen? Wie werden Exceptions behandelt? Lehrbücher zu Architektur schweigen sich meist zu Fehlerbehandlung aus (positive Ausnahme: J. Siedersleben Moderne Softwarearchitektur) 5 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

6 Wiederholung: Exceptions in Java geschützter Block... Statement; Statement; Statement;... Fehlerbehandlungscode... Statement; Statement; Statement;... Ausnahmebehandler (exception handler) Wenn im geschützten Block ein Fehler (eine Ausnahme) auftritt: Ausführung des geschützten Blocks wird abgebrochen Fehlerbehandlungscode wird ausgeführt Programm setzt nach dem geschützten Block fort 6 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

7 Try-Anweisung in Java try { p(...); q(...); r(...); } catch (Exception1 e) { error(...); geschützter Block void q(...) {... throw new Exception2();... } Auslösen einer Ausnahme } catch (Exception2 e) { error(...); } catch (Exception3 e) { Ausnahmebehandler error(...); } Vorteile Fehlerfreier Fall und Fehlerfälle sind sauberer getrennt Man kann nicht vergessen, einen Fehler zu behandeln (Compiler prüft, ob es zu jeder möglichen Ausnahme einen Behandler gibt) 7 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

8 Throw-Anweisung Löst eine Ausnahme aus throw new MyException("invalid operation", 17); "Wirft" ein Ausnahmeobjekt mit entsprechenden Fehlerinformationen bricht normale Programmausführung ab sucht passenden Ausnahmebehandler (catch-block) führt Ausnahmebehandler aus und übergibt ihm Ausnahmeobjekt als Parameter setzt nach try-anweisung fort, zu der der catch-block gehört 8 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

9 catch-blöcke und finally-block try {... } catch (MyException e) { Out.println(e.getMessage() + ", error code = ", + e.geterrorcode()); } catch (NullPointerException e) {... } catch (Exception e) {... } finally {... } Passender catch-block wird an Hand des Ausnahme-Typs ausgewählt catch-blöcke werden sequentiell abgesucht Achtung: speziellere Ausnahme-Typen müssen vor allgemeineren stehen Am Ende wird (optionaler) finally-block ausgeführt egal, ob im geschützten Block ein Fehler auftrat oder nicht 9 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

10 Arten von Exceptions in Java Ungeprüfte (Unchecked Exceptions) werden beispielsweise von der Java-VM ausgelöst Division durch 0 ArithmeticException Zugriff über null-zeiger NullPointerException Indexüberschreitung ArrayIndexOutOfBoundsException wenn sie nicht behandelt werden, stürzt das Programm mit einer Fehlermeldung ab Geprüfte Ausnahmen (Checked Exceptions) Müssen vom Client-Code gefangen (catch) oder weitergeworfen werden (throws-anweisung) vordefinierte Ausnahmen z.b. FileNotFoundException selbst definierte Ausnahmenz.B. MyException Compiler prüft, ob sie abgefangen werden 10 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

11 Beispiel: die Fehlerbehandlung kann das Geheimnisprinzip verletzen try { result = Kontokorrent.ueberweise(100, konto1, konto2); } catch (DatabaseNotAvailableException e) { // was tun, sprach Zeuss? } Der Aufrufer einer Operation (Client) kennt nur die Schnittstelle, nicht dessen Implementierung Der aufgetretene Fehler gibt aber Auskunft über die Implementierung. Der Server zwingt den Client, den Fehler zu behandeln. class Dependency Client Serv er Client Die Fehlerbehandlung verletzt das Geheimnisprinzip. Der Client weiß nicht so recht, was er tun soll ( ich wusste gar nicht, dass da eine Datenbank im Spiel ist. Ich kenne mich nur mit Überweisungen aus ) 11 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 / Serv er Aufrufer Schnittstelle Implementierung

12 Lösung: Klassifikation von Fehlern in fachliche Fehler (A-Fehler) und technische Fehler (T-Fehler) Fachliche Fehler (A-Fehler): Im Sinne der Fachlichkeit der Schnittstelle (Außensicht) zu erwartender Fehler Beispiele: Operation Geld abheben einer Bankanwendung: Kreditlimit überschritten Operation Datei öffnen eines Betriebssystems: Datei nicht vorhanden Technische Fehler (T-Fehler): Fehler, die sich aus der Implementierung und deren Technik (Innensicht) ergeben. Beispiele: Operation Geld abheben einer Bankanwendung : Datenbank nicht verfügbar Operation Datei öffnen eines Betriebssystems: Fileserver abgestürzt Verletzte Vor-/Nachbedingungen (sind keine fachlichen Fehler, sondern Programmierfehler!) Der Anbieter einer Operation führt die Klassifikation der Fehler durch 12 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

13 Fachliche Fehler (A-Fehler) Können und müssen vollständig aufgezählt werden! Sind Bestandteil der Schnittstelle Design-Alternativen: Rückgabewert Geprüfte Ausnahme (checked Exception) Beispiele: int ueberweise (int betrag, Konto von, Konto nach) post: result = 0, falls Überweisung erfolgreich post: result = -1, falls Kreditlimit überschritten void ueberweise (int betrag, Konto von, Konto nach) throws KreditlimitException error: KreditlimitException, falls Kreditlimit überschritten Der Aufrufer muss den fachlichen Fehler fachlich behandeln und beispielsweise den Anwender informieren! 13 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

14 Technische Fehler (T-Fehler) Sind abhängig von der Implementierung und deren Technologie Können im Allgemeinen nicht vollständig aufgezählt werden (Murphy s Law: if anything can go wrong it will ) Design-Empfehlungen: Kein Bestandteil der Schnittstelle! Verwende stets unchecked Exceptions (RuntimeException oder Error) für T-Fehler Werden Fremdkomponenten gerufen, die sich nicht an diese Konvention halten: packe die gefangenen checked exceptions in neue Runtime Exceptions (Exception Chaining) Beispiel: try { result = Kontokorrent.ueberweise(100, konto1, konto2); } catch (DatabaseNotAvailableException e) { throw new RuntimeException(e); } Der Aufrufer kann den Fehler nicht behandeln und tut es auch nicht! 14 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

15 Wer behandelt technische Fehler? Der ExceptionHandler Design-Empfehlung: An einer zentralen Stelle im System werden alle technischen Fehler gefangen und dem ExceptionHandler übergeben Der ExceptionHandler bündelt die Logik für die Fehlerbehandlung try { f();... } catch (Throwable e) { exceptionhandler.handleexception(e) }... class ExceptionHandler { Throwable handleexception(throwable e){ // classify situation // perform corresponding action }... } 15 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

16 Der ExceptionHandler klassifiziert technische Fehler nach ihrer Schwere und stößt erforderliche Aktionen an Katastrophe (globales schweres Problem): Das Gesamtsystem muss heruntergefahren werden Lokales schweres Problem: Die Benutzersession muss beendet werden. In beiden Fällen ist u. U. der Anwender zu informieren Behebbares Problem: Durch Retry oder Compensating Actions kann das Problem behoben werden Leichtes Problem: Das Problem wird protokolliert zur Unterstützung von Wartungsarbeiten (das muss auch für alle obigen Fälle erfolgen) und das System kann fortgesetzt werden 16 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

17 Erinnerung: Der ExceptionHandler ist ein Dienst der Application Kernel Facade cmp Application Kernel Facade «A Component» Dialog NameService A_UseCase_1' A_UseCase_n' Administration «Abstract T Component» Application Kernel Facade TechnicalConfiguration SystemsManagement ExceptionHandler TransactionManager A_UseCase_1 A_UseCase_n «Abstract T Compo... Transaction «A Component» Application Component 17 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

18 Der Ablauf am Beispiel sd handle exception and repair Client Application Kernel Facade Transaction Application Client «interface» A_UseCase_1' «interface» ExceptionHandler «interface» :TransactionManager «interface» SystemsManagement «interface» A_UseCase_1 somemethod(arguments) begintransaction() :Transaction somemethod(arguments) or via catch exception handle(exception) :Exception rollbacktransaction(transaction) shutdown 18 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

19 Agenda Fehlerbehandlung Entwurfsmuster Performance Kontrollfragen

20 Muster in der Architektur von Gebäuden Ziele: Angreifer aufwärts kämpfen lassen parallel zu dem Burgmauern führen immer von 3 Seiten beschießen Lösungen Versetzte Tore Mauern mit auskragenden Türmen Mehrere konzentrische Bastionen Innere Bastionen überblicken äußere 20 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS Quelle: /

21 Einführung in Design Patterns Folien von Bob Tarr, Computer Science and Electrical Engineering Department, University of Maryland Baltimore County < Introduction To Design Patterns : 21 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

22 Ausgewählte Design Patterns (Entwurfsmuster) Design Pattern Sammlung unter : Observer : Factory : Composite : Adapter : Pipes and Filters : 22 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

23 Agenda Fehlerbehandlung Entwurfsmuster Performance Kontrollfragen

24 Performance: Durchsatz, Anwortzeit Stellschrauben für die Performance-Optimierung A-Architektur (fachliche Anwendungsarchitektur) Effiziente fachliche Algorithmen Reduktion der Kommunikation zwischen Komponenten Optimierung Datenbankmodell, z.b. Indexing, Denormalisierung des Datenbankmodells bei Performance Hotspots T-Architektur (Technikarchitektur) Performante Verwendung der technischen Infrastruktur, z.b. Reduktion von Netzwerkkommunikation, Optimierung von DB- Abfragen, Caching, Lazy / Eager Loading etc. Verwendung von besonders performanten Programmiersprachen / Systemsoftware bei Performance Hotspots TI-Architektur (Architektur der technischen Infrastruktur) Schnellere / mehr Hardware Performantere Systemsoftware, z.b. DBMS Optimierung der Systemparameter, z.b. Cachegrößen Änderung der Architektur, z.b. Clustering 24 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /

25 Agenda Fehlerbehandlung Entwurfsmuster Performance Kontrollfragen

26 Kontrollfragen Wie sind Fehler zu klassifizieren? Wie soll mit fachlichen Fehlern umgegangen werden? Wie soll mit technischen Fehlern umgegangen werden? Wie funktioniert der ExceptionHandler? Was sind Design Patterns? Wozu sind diese gut? Wann setzen Sie diese ein? Wann setzen Sie das Beobachter-Muster ein? Welche Charakteristika hat Performance? An welchen Stellschrauben kann die Performance einer Anwendung optimiert werden? 26 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2009 /