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

Transkript

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

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

3 Agenda Fehlerbehandlung Entwurfsmuster Performance Kontrollfragen Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

4 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 4 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

5 Kein Computersystem ohne Fehler 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! 5 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

6 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) 6 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

7 Die Fehlerbehandlung kann das Geheimnisprinzip verletzen try { result = Kontokorrent.ueberweise (100, konto1, konto2); } catch (DatabaseNotAvailableException e) { // was tun, sprach Zeuss? } class Dependency Client Serv er Client Serv er Aufrufer Schnittstelle Implementierung 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. 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 ) 7 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

8 Lösung: Klassifikation von Fehlern (1.) Fachliche Fehler (A-Fehler) Klassifikation von Fehlern in fachliche Fehler (A-Fehler) und technische Fehler (T-Fehler) Der Anbieter einer Operation führt die Klassifikation der Fehler durch Fachliche Fehler (A-Fehler): Im Sinne der Schnittstelle zu erwartender Fehler Beispiele: Operation Geld abheben einer Bankanwendung: Kreditlimit überschritten Operation Datei öffnen eines Betriebssystems: Datei nicht vorhanden 8 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

9 (2.) Technische Fehler (T-Fehler) Technische Fehler (T-Fehler): Fehler, die sich aus der Implementierung und deren Technik 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!) 9 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

10 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) result = 0, falls Überweisung erfolgreich -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! 10 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

11 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), z.b. try { result = Kontokorrent.ueberweise(100, konto1, konto2); } catch (DatabaseNotAvailableException e) { throw new RuntimeException(e); } 11 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

12 Wer behandelt technische Fehler? Der ExceptionHandler Design-Empfehlungen: An einer zentralen Stelle im System werden alle technischen Fehler gefangen und dem ExceptionHandler übergeben Beispiele für zentrale Stellen: Application Server, Client-Server-Schnitt, Event-Dispatch-Thread der GUI Der ExceptionHandler bündelt die Logik für die Fehlerbehandlung try { f();... } catch (Throwable e) { exceptionhandler.handleexception(e) }... class ExceptionHandler { Object handleexception(throwable e){ // classify situation // perform corresponding action }... } 12 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

13 ExceptionHandler: Klassifikation und Aktion 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 13 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

14 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 14 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

15 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 15 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

17 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 17 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

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

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

20 Übungen Observer: Entwerfen Sie ein Klassendiagramm für eine Anwendung, welche es erlaubt, Börsenkurse sowohl tabellarisch als auch graphisch stets aktuell anzuzeigen Composite: Entwerfen Sie ein Klassendiagramm für das Layout (GUI Statik) geschachtelter Dialoge Adapter: Entwerfen Sie einen Adapter für ein Buchhaltungssystem 20 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

21 Agenda Fehlerbehandlung Entwurfsmuster Performance Performance Kontrollfragen Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

22 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 22 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012

24 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? 24 Prof. Dr. Bernhard Humm, Hochschule Darmstadt, FB Informatik: Softwaretechnik (CNAM), WS 2011 / 2012