Design: Querschnittsthemen und Muster

Transcription

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
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
Agenda
Fehlerbehandlung
 Fehlerbehandlung
Entwurfsmuster
Performance
Kontrollfragen
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
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
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
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
Aufrufer
7
Serv er
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“)
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
(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
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)
void ueberweise (int betrag, Konto von,
Konto nach) throws KreditlimitException
result = 0, falls Überweisung erfolgreich
-1, falls Kreditlimit überschritten
error: KreditlimitException, falls
Kreditlimit überschritten
 Der Aufrufer muss den fachlichen Fehler fachlich behandeln und beispielsweise den
Anwender informieren!
10
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
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)
}
...
12
class ExceptionHandler {
…
Object handleException(Throwable e){
// classify situation
// perform corresponding action
}
...
}
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
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»
TechnicalConfiguration
SystemsManagement
ExceptionHandler
A_UseCase_1
A_UseCase_n
TransactionManager
«Abstract T Compo...
Transaction
14
«A Component»
Application Component
Der Ablauf am Beispiel
sd handle exception and repair
Client
Transaction
Application
«interface»
«interface»
«interface»
«interface»
«interface»
A_UseCase_1'
ExceptionHandler
:TransactionManager
SystemsManagement
A_UseCase_1
Client
someMethod(arguments)
beginTransaction() :Transaction
someMethod(arguments)
or via catch exception
handle(exception) :Exception
rollbackTransaction(transaction)
shutDown
15
Agenda
Fehlerbehandlung
Entwurfsmuster
 Entwurfsmuster
Performance
Kontrollfragen
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
Einführung in Design Patterns
Folien von Bob Tarr, Computer Science and Electrical Engineering Department, University of
Maryland Baltimore County <http://userpages.umbc.edu/~tarr/dp/spr06/cs446.html>
 Introduction To Design Patterns :
http://userpages.umbc.edu/%7Etarr/dp/lectures/IntroToDP.pdf
18
Ausgewählte Design Patterns (Entwurfsmuster)
Design Pattern Sammlung unter http://www.vico.org/pages/PatronsDisseny.html :
 Observer : http://www.vico.org/pages/PatronsDisseny/Pattern%20Observer/index.html
 Factory :
http://www.vico.org/pages/PatronsDisseny/Pattern%20Factory%20Method/index.html
 Composite : http://www.vico.org/pages/PatronsDisseny/Pattern%20Composite/index.html
 Adapter :
http://www.vico.org/pages/PatronsDisseny/Pattern%20Adapter%20Object/index.html
 Pipes and Filters :
http://www.vico.org/pages/PatronsDisseny/Pattern%20Pipes%20and%20Filters/index.html
19
Ü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
Agenda
Fehlerbehandlung
Entwurfsmuster
Performance
 Performance
Kontrollfragen
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
22
T-Architektur
(Technikarchitektur)
 Performante
Verwendung der
technischen Infrastruktur,
z.B. Reduktion von
Netzwerkkommunikation,
Optimierung von DBAbfragen, 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
Agenda
Fehlerbehandlung
Entwurfsmuster
Performance
Kontrollfragen
 Kontrollfragen
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

Design: Querschnittsthemen und Muster

Transcription

Similar documents

Angebotsliste externe Betreuung Maturarbeit

RAZER COPPERHEAD™ HANDBUCH