Objektorientierte Softwareentwicklung Klaus Becker 2003.
Post on 05-Apr-2015
104 Views
Preview:
Transcript
Objektorientierte Objektorientierte SoftwareentwicklungSoftwareentwicklung
Klaus Becker2003
2
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Softwareentwicklung als ProzessSoftwareentwicklung als Prozess
Analyse Entwurf
Implementierung
Wartung
3
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Teil 1Teil 1
Auftrag und Pflichtenheft
4
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Das ProblemDas Problem
Schon wieder keine 6! 10mal gewürfelt und es ist keine einzige 6 gefallen. Stimmt hier etwas nicht?
Problem:
Wie wahrscheinlich ist es, dass man bei 10maligem Würfeln - keine 6 - genau einmal eine 6 - genau zweimal eine 6 - ... - mindestens zweimal und höchstens viermal eine 6 erhält?
Problem:
Wie wahrscheinlich ist es, dass man bei 10maligem Würfeln - keine 6 - genau einmal eine 6 - genau zweimal eine 6 - ... - mindestens zweimal und höchstens viermal eine 6 erhält?
5
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Eine LösungsmethodeEine Lösungsmethode
0
3
...
0 1 2 3 4 5 6 7 8 9 10
195 310 287 143 50 13 2 0 0 0 0
Empirische Abschätzung:
Wir führen das Zufallsexperiment „10mal Würfeln“ sehr oft durch (z. B. 1000 mal) und ermitteln, wie oft dabei das Ereignis „keine 6“ eintritt.
Empirische Abschätzung:
Wir führen das Zufallsexperiment „10mal Würfeln“ sehr oft durch (z. B. 1000 mal) und ermitteln, wie oft dabei das Ereignis „keine 6“ eintritt.
6
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
BegriffeBegriffe
Zufallsexperiment: Experiment, bei dem mehrere Ergebnisse möglich sind, der Ausgang aber nicht genau vorhergesagt werden kann
Ereignis: Teilmenge der Ergebnismenge eines Zufallsexperiments
Bernoulli-Experiment: Zufallsexperiment mit genau zwei Ergebnissen (1: Treffer; 0: Niete)
Bernoulli-Kette der Länge n: n-malige Durchführung eines Bernoulli-Experiments
7
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Verallgemeinertes ProblemVerallgemeinertes Problem
Problem:
Wie groß ist die Wahrscheinlichkeit, dass man bei einer Bernoulli-Kette der Länge n und der Trefferwahrscheinlichkeit p eine bestimmte Anzahl von Treffern erhält?
Problem:
Wie groß ist die Wahrscheinlichkeit, dass man bei einer Bernoulli-Kette der Länge n und der Trefferwahrscheinlichkeit p eine bestimmte Anzahl von Treffern erhält?
Empirische Abschätzung:
Wir führen die Bernoulli-Kette sehr oft aus und ermitteln, wie oft dabei eine bestimmte Anzahl von Treffern eingetreten ist.
Empirische Abschätzung:
Wir führen die Bernoulli-Kette sehr oft aus und ermitteln, wie oft dabei eine bestimmte Anzahl von Treffern eingetreten ist.
8
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Der AuftragDer Auftrag
Es soll ein Softwaresystem entwickelt werden, mit dem der Benutzer die wiederholte Ausführung von Bernoulli-Ketten simulieren und die Simulationsergebnisse auswerten kann.
9
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Ein Prototyp zum Softwaresystem Ein Prototyp zum Softwaresystem
Ein Prototyp dient dazu, bestimmte Aspekte eines zu entwickelnden Software-Systems vor der Realisierung zu überprüfen. Häufig wird ein Prototyp der Benutzungsoberfläche erstellt. Anhand dieses Prototyps können die Entwickler mit dem Auftraggeber diskutieren, inwieweit dessen Wünsche beachtet und umgesetzt wurden.
10
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Aufgabe Aufgabe
Auftraggeber und Entwickler sollen gemeinsam einen Prototyp erstellen und dokumentieren. Auftraggeber und Entwickler sollen gemeinsam einen Prototyp erstellen und dokumentieren.
11
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Prototyp zum SimulationssystemPrototyp zum Simulationssystem
p = 0,1666
n = 10
a = 1000
0: 1951: 3102: 287...
neue Simulation und Auswertung
neue Auswertung
Eingabefelder f. d.
Simulationsparam.
Darstellung der Häufigkeitsverteilu
ng
0: 0.195
1: 0.310
2: 0.287
...
absolute
Häufigkeit
relative
Häufigkeit
Auswertung
min = 0
max = 0
h = 0.195
Button ButtonGrafische Darst. d.
Häufigkeitsverteilung
12
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
PflichtenheftPflichtenheft
Ein Pflichtenheft ist eine textuelle Beschreibung dessen, was das zu realisierende System leisten soll. Es soll dabei zwei Zielsetzungen erfüllen: Zum einen ist es das „Einstiegsdokument“ in das Projekt für alle, die das System später pflegen und warten sollen, zum anderen soll es den Systemanalytiker in die Lage versetzen, eine objektorientierte Analyse vorzunehmen.
Zielformulierungen (Muss-Kriterien, Kann-Kriterien, Abgrenzungskriterien)
Einsatzbereiche (Anwendungsbereich, Zielgruppe, ...)
Umgebung (Hardware, Software, ...)
Funktionalitäten
Datenhaltung
Benutzungsoberfläche
...
13
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
AufgabeAufgabe
Ergänzen Sie das folgende, bereits angefangene Pflichtenheft. Ergänzen Sie das folgende, bereits angefangene Pflichtenheft.
14
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Pflichtenheft zum SimulationssystemPflichtenheft zum Simulationssystem
/0/ Der Benutzer kann folgende Simulationsparameter vorgeben: Trefferwahrscheinlichkeit p; Länge der Bernoulli-Kette n; Anzahl der Wiederholungen: a.
/1/ Der Benutzer kann folgende Auswertungsparameter vorgeben: Minimum und Maximum des Ereignisbereichs. Diese Parameter müssen aber nicht gesetzt sein.
/2/ Das System bestimmt (auf Buttondruck) zu den vorgegebenen Simulationsparametern eine absolute und relative Häufigkeitsverteilung und zeigt diese in Tabellenform an.
/3/ (evtl.) Die relativen Häufigkeiten werden auch grafisch in Form eines Histogramms angezeigt.
/4/ Das Simulationssystem soll im Stochstikunterricht eingesetzt werden können.
...
15
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Pflichtenheft zum SimulationssystemPflichtenheft zum Simulationssystem
16
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Pflichtenheft zum SimulationssystemPflichtenheft zum Simulationssystem
17
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Teil 2Teil 2
Objektorientierte Analyse
18
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Zielsetzung der OOAZielsetzung der OOA
- Unabhängig von der späteren Implementierung wird die Miniwelt mit Hilfe von Objekten, Klassen sowie deren Beziehungen beschrieben.
- Die Miniwelt wird dabei soweit abstrahiert, dass alle für den Auftraggeber relevanten Bestandteile des Problembereichs abgebildet sind.
- Das Ergebnis einer OOA ist also eine präzise, abstrahierende Beschreibung der Miniwelt.
Aufgabe der objektorientierten Analyse (kurz: OOA):
Modellierung des Problembereichs („Miniwelt“), der vom zu entwickelnden Informatiksystem erfasst werden soll.
Aufgabe der objektorientierten Analyse (kurz: OOA):
Modellierung des Problembereichs („Miniwelt“), der vom zu entwickelnden Informatiksystem erfasst werden soll.
19
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Identifikation der ObjekteIdentifikation der Objekte
Vorgehensweise:
- Zunächst wird die Miniwelt beschrieben (verbal und/oder mit Bildern etc.).
- Anschließend wird analysiert, welche (konkreten oder abstrakten) „Gegenstände“ in der Miniwelt vorkommen.
- Abschließend wird entschieden, welche „Gegenstände“ der Miniwelt im Modell repräsentiert werden sollen und was ihre jeweilige Zuständigkeit ist.
Beschreiben
Analysieren
Auswählen
Aufgabe: Führen Sie die oben beschriebenen Schritte zur Identifikation der Objekte durch.
20
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Beschreibung der MiniweltBeschreibung der Miniwelt
21
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
0
0,02
Beschreibung der MiniweltBeschreibung der Miniwelt
Simulation: 100 mal (a mal) das Zufallsexperiment ausführen
0 1 2 3 4 5
2 14 27 30 20 7
Verteilung:
1
0,14
2
0,27
3
0,30
4
0,20
5
0,07
2..4
0,77
Zufallsgerät: Münze, Würfel, ... (0-1-Gerät)
Zufallsexperiment: Bernoulli-Kette (n mal 0-1-Gerät aktivieren)
relative Häufigkeit
Ereignis
absolute Häufigkeit
Anzahl der Treffer
Treffer
Niete
rel. Häufigk.
22
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Beschreibung der MiniweltBeschreibung der Miniwelt
Das Zufallsexperiment benutzt ein 0/1-Zufallsgerät (d. h. ein Gerät, mit dem man zufallsbasiert zwei Ergebnisse erzielen kann: 1 bzw. „Treffer“ und 0 bzw. „Niete“).
Ein (Bernoulli-) Zufallsexperiment besteht darin, das Zufallsgerät n mal zu aktivieren und eine bestimmte Beobachtungsgröße (hier Anzahl der Treffer) zu ermitteln.
Bei einer Simulation wird das Zufallsexperiment a mal durchgeführt. Das Ergebnis einer Simulation ist eine Tabelle mit den jeweiligen absoluten Häufigkeiten.
Zur Auswertung der Simulationsergebnisse wird die Verteilung der Beobachtungsgröße (relative Häufigkeiten der Ergebnisse) bestimmt und evtl. eine relative Häufigkeit für eine konkrete Fragestellung (das interessierende Ereignis) bestimmt.
23
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Objekte und ihre ZuständigkeitenObjekte und ihre Zuständigkeiten
zufallsgeraet: erzeugt Treffer (1) bzw. Nieten (0) mit einer Wahrscheinlichkeit pzufallsexperiment: führt das eigentliche Experiment (wiederholte Aktivierung des Zufallsgeräts) durch und ermittelt die Beobachtungsgröße (Anzahl der Treffer)
simulation: führt das Zufallsexperiment eine bestimmte Anzahl mal durch und ermittelt die absolute Häufigkeit der möglichen Ergebnisse der Beobachtungsgröße
verteilung:verwaltet die relative Häufigkeit aller möglichen Ergebnisse der Beobachtungsgröße und ggf. die relative Häufigkeit eines interessierenden Ereignisses
24
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Modellierung der ObjekteModellierung der Objekte
Ziel: Festlegung der Objektattribute
Aufgabe: Erstellen Sie (mit Hilfe von Violet) ein Objektdiagramm zur Miniwelt „Simulation von Bernoulli-Ketten“. Legen Sie insbesondere die Attribute der Objekte fest und weisen Sie diesen Attributen typische Attributwerte zu.
25
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Ein erstes ObjektdiagrammEin erstes Objektdiagramm
26
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Modellierung der KlassenModellierung der Klassen
Ziel: Informelle Festlegung der Attribute und Methoden der Klassen
Aufgabe: Erstellen Sie (mit Hilfe von Violet) ein erstes vorläufiges Klassendiagramm zur Miniwelt „Simulation von Bernoulli-Ketten“. Legen Sie hierzu die Attribute und Methoden der Klassen fest.
27
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Ein erstes KlassendiagrammEin erstes Klassendiagramm
28
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Aufgabe:
Überlegen Sie sich, welches Objekt welches andere Objekt kennen (besitzen) muss, um seine Aufgaben zu erfüllen.
Identifikation von BeziehungenIdentifikation von Beziehungen
29
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Wer kennt wen?Wer kennt wen?
zufallsexperiment:
benutzt das Zufallsgerät kennt zufallsgeraet
simulation:
führt das Zufallsexperiment wiederholt durch kennt zufallsexperiment
erstellt aus dem Simulationsergebnis eine Verteilung kennt verteilung
zufallsexperiment:
benutzt das Zufallsgerät kennt zufallsgeraet
simulation:
führt das Zufallsexperiment wiederholt durch kennt zufallsexperimentverteilung:
wertet die Ergebnisse der Simulation aus kennt simulation
Version 1 Version 2
30
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Aufgabe:
Führen Sie zunächst in Ihrem Objektdiagramm geeignete Referenzparameter ein und stellen Sie die Beziehungen zwischen den Objekten mit Referenzen dar.
Ergänzen Sie anschließend in Ihrem Klassendiagramm die Beziehungen.
Verfeinerung der DiagrammeVerfeinerung der Diagramme
31
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Verfeinertes ObjektdiagrammVerfeinertes Objektdiagramm
32
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Klassendiagramm mit BeziehungenKlassendiagramm mit Beziehungen
33
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Teil 3Teil 3
Objektorientierter Design
34
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Zielsetzung des OODZielsetzung des OOD
- Genaue Spezifikation der Attribute (Datentypen) und Methoden (Parameter und ihre Datentypen)
- Modellierung der Benutzungsoberfläche
Aufgabe des objektorientierten Designs (kurz: OOD):
Anpassung des OOA-Modells an die Rahmenbedingungen des zu erstellenden Systems
Aufgabe des objektorientierten Designs (kurz: OOD):
Anpassung des OOA-Modells an die Rahmenbedingungen des zu erstellenden Systems
35
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Spezifikation der Attribute und Spezifikation der Attribute und MethodenMethoden
Aufgabe:
Erstellen Sie (mit Hilfe von UMLed) ein dokumentiertes Klassendiagramm. Legen Sie insbesondere folgende Punkte fest:
- die Zugriffsrechte und Datentypen der Attribute- die Konstruktoren- die get/set-Operationen- die Parameter der Operationen
36
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Verfeinertes Klassendiagramm (Violet)Verfeinertes Klassendiagramm (Violet)
Dynamischer Array
Dynamischer Array
37
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Verfeinertes Klassendiagramm (UMLed)Verfeinertes Klassendiagramm (UMLed)
Dynamischer Array
Dynamischer Array
38
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Exkurs: Dynamische ArraysExkurs: Dynamische Arrays
Statischer Array:
var s: array [1..10] of integer
Bem.: Ein (statischer) Array hat eine feste Größe (Indexbereich 1..10), die in der Deklaration festgelegt wird.Dynamischer Array:
var d: array of integer
Bem.: Ein dynamischer Array hat zunächst keine feste Größe. Der genaue Indexbereich wird erst zur Laufzeit dynamisch mit Hilfe der Methode „SetLength“ festgelegt.
setLength(d, 3) // Indexbereich 0..2
39
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Klassen-DokumentationKlassen-Dokumentation
Zielsetzung:
Damit die entwickelten Klassen gut benutzt werden können (z. B. von anderen Personen / zu einem späteren Zeitpunkt), sollten die Klassenbeschreibungen hinreichend kommentiert werden.
Integrierte Dokumentation:
Die Dokumentation erfolgt während der Entwicklung. Viele CASE-Tools (wie UMLed) unterstützen die Dokumentationstätigkeit.
Aufgabe:
Erstellen Sie Klassen-Dokumentationen zu den entwickelten Klassen.
40
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Klassen-Dokumentation (mit UMLed)Klassen-Dokumentation (mit UMLed)
Dokumentation der Klasse "TZufallsgeraet"
Beschreibung der Klasse:modelliert ein Zufallsgerät, mit dem Bernoulli-Experimente (d.h.: 0/1-Experimente) ausgeführt werden können.
Attribute
e : integer // Ergebnis (1: Treffer; 0: Niete)
p : real // Trefferwahrscheinlichkeit
Protokoll der Dienste / Methoden
Konstruktor create
Auftrag aktivieren// veranlasst das Zufallsgerät, zufallsbasiert eine 0/1-Entscheidung zu treffen
Auftrag setP ( p: integer )
Anfrage getE : integer
41
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Aufgabe:
Entwerfen Sie eine Benutzungsoberfläche. Der Entwurf soll die GUI-Objekte und die Ereignisbehandlung festlegen.
BenutzungsoberflächeBenutzungsoberfläche
42
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Entwurf einer BenutzungsoberflächeEntwurf einer Benutzungsoberfläche
Simulations-parameter
Auswertungs-parameter
Simulations-ergebnis
Auswertungs-ergebnis:Verteilung
Auswertungs-ergebnis
43
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
EreignisbehandlungEreignisbehandlung
Benutzeraktion Programmreaktionen
Mausklick auf den „neue Simulation und Auswertung“-Button
Zuerst werden die Simulationsparameter (p, n, a) und Auswertungsparameter (min, max) übernommen und gesetzt.
Anschließend wird die Simulation ausgeführt sowie die Verteilung erstellt und ausgewertet.
Abschließend werden die Simulations- und Auswertungsergebnisse angezeigt.
Mausklick auf den „neue Auswertung“-Button
Zuerst werden die Auswertungsparameter (min, max) übernommen und gesetzt.
Anschließend wird die Verteilung ausgewertet.
Abschließend werden die Auswertungsergebnisse angezeigt.
44
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Modellierung der GUI-KlasseModellierung der GUI-Klasse
45
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
SequenzdiagrammSequenzdiagramm
46
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
SequenzdiagrammSequenzdiagramm
47
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Teil 4Teil 4
Implementierung und Testen
48
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
ImplementierungImplementierung
Aufgabe:
Implementieren Sie die entwickelten Klassen.
Arbeitsaufteilung:- Fachkonzeptklassen (TZufallsgeraet, ..., TVerteilung)- GUI-Klasse (Benutzungsoberfläche, Ereignisverarbeitung, ...)
Zielsetzung:
Erstellung eines lauffähigen Programms zum entwickelten Modell
Zielsetzung:
Erstellung eines lauffähigen Programms zum entwickelten Modell
49
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Naive Vorgehensweise:
Wir überlegen uns (möglichst alle) Testfälle und schauen, wie das entwickelte System die Testfälle bearbeitet. Die Ergebnisse werden kurz dokumentiert.
Zielsetzung:
Auffinden von Fehlern / Nachweis der Fehlerfreiheit
Zielsetzung:
Auffinden von Fehlern / Nachweis der Fehlerfreiheit
TestenTesten
Aufgabe:
Untersuchen Sie möglichst viele Testfälle und dokumentieren Sie die Ergebnisse. Achtung: Vor dem Testen alle Programmteile abspeichern! Absturzgefahr!
50
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Dokumentation der TestfälleDokumentation der Testfälle
/1/ alle Simulationsparameter sind sinnvoll eingegeben; min, max ist nicht eingegeben; Button „neue Simulation und Auswertung“ gedrückt ok
/2/ Simulationsparameter nicht eingegeben; Button „neue Simulation und Auswertung“ gedrückt Fehlermeldung
51
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Teil 5Teil 5
Wartung und Pflege
52
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Wartung und PflegeWartung und Pflege
Beispiel:
/1/ Alle nicht erwünschten Eingaben sollen vom System abgefangen werden. Der Benutzer soll jeweils geeignet informiert werden.
Hinweise: try-exept-Anweisung(beachte Delphi-Einstellung: Tools-Debugger-Optionen-SprachExceptions-BeiDelphiExceptionsStoppen)
Zielsetzung:
Änderungen / Erweiterungen / Verbesserung des Systems
Zielsetzung:
Änderungen / Erweiterungen / Verbesserung des Systems
53
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Wartung und PflegeWartung und Pflege
Beispiel:
/2/ Die tabellenartige Ausgabe der Verteilung soll um eine grafische Ausgabe ergänzt werden.
Zielsetzung:
Änderungen / Erweiterungen / Verbesserung des Systems
Zielsetzung:
Änderungen / Erweiterungen / Verbesserung des Systems
54
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Grafische Ansicht der VerteilungGrafische Ansicht der Verteilung
55
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Modellierung von AnsichtenModellierung von Ansichten
56
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Modellierung von AnsichtenModellierung von Ansichten
57
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Teil 6Teil 6
Zusammenfassung / Bemerkungen
58
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
EntwicklungszyklusEntwicklungszyklus
OOA:Analyse und Modellierung der Miniwelt
OOD:Entwurf des Software-Systems
OOP:Implementierung des Systems; Testen des Systems
Wartung und Pflege:Fehlerbeseitigung, Erweiterung, ...
59
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Prinzipien für die Entwicklung von Prinzipien für die Entwicklung von SoftwareSoftware
Folgende allgemeinen Prinzipien sollten bei der Entwicklung von Softwaresystemen beachtet werden:(http://www.oszhdl.be.schule.de/index.htm)
Abstraktion
Hervorhebung des Wesentlichen, absehen von speziellen, untergeordneten Details, erkennen gleicher Merkmal
Hierarchisierung
Anordnung der Elemente in einer Rangordnung. Elemente gleicher Rangordnung stehen auf derselben Stufe und bilden eine Schicht oder Ebene.Grundsatz: Innerhalb der Hierarchie dürfen keine zirkulären Beziehungen auftreten
60
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Prinzipien für die Entwicklung von Prinzipien für die Entwicklung von SoftwareSoftware
Modularisierung
"Modularisierung" ist ein allgemeines Prinzip aus den Ingenieurwissenschaften und dient insbesondere der Erzeugung überschaubarer Systeme, deren Komponenten unter Umständen auch in anderen Systemen wiederverwendet werden können.
Auf die Softwareentwicklung angewandt fordert dieses Prinzip die Aufteilung des Systems in überschaubare Teile, mit klar definierten Schnittstellen.
Dabei sollen einzelne Module ausgetauscht oder geändert werden können, ohne dass Veränderungen im übrigen System erforderlich sind.
61
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Prinzipien für die Entwicklung von Prinzipien für die Entwicklung von SoftwareSoftware
Lokalität
Alle wichtigen Informationen, die zu derselben Situation gehören, sind an einem Platz vorhanden. Optimale Lokalität liegt vor, wenn die jeweils benötigten Informationen auf einer Seite stehen. Lokalität ist damit auch ein Strukturierungsprinzip.
Integrierte Dokmentation
Ein Software-System besteht aus "Programmcode und Dokumentation" und ist letztlich nur so gut wie diese. Die Dokumentation muss integraler Bestandteil der Softwareentwicklung sein.
62
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Warum Objektorientierung?Warum Objektorientierung?
These (Oestereich)
Objektorientierung ist die derzeitige Antwort auf die gestiegene Komplexität der Softwareentwicklung.
63
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Das Probleme der ZuverlässigkeitDas Probleme der Zuverlässigkeit
„Eines der Hauptprobleme der Software-Entwicklung ist die Entwicklung zuverlässiger Software. Man bezeichnet ein Programm als zuverlässig, wenn es sich im Betrieb so verhält, wie man es aufgrund der Anforderungen an das Programm erwartet. Je umfangreicher ein Software-Projekt ist, desto unwahrscheinlicher ist es, dass sein Ergebnis jemals fehlerfrei wird. Man muss sogar davon ausgehen, dass es unmöglich ist, umfangreiche Software-Produkte vollständig fehlerfrei zu entwickeln.“
(Gumm, Einführung in die Informatik, S. 661 ff)
64
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Berühmte ProgrammierfehlerBerühmte Programmierfehler
• Der Taschenrechner von Windows 3.1 rechnete bei einigen Eingaben total falsch. Z. B.: 2,01 – 2 = 0,00
• Eine Schweizer Bank überwies einigen Kunden den Betrag, den die Kunden selbst an die Bank hätten überweisen müssen. Der Fehler wurde erst nach 9 Monaten bemerkt, der Bank entstand inzwischen ein Schaden von ca. 200000 DM.
• Beim Bau der Rakete Ariane-5 wurde das bewährte Navigationssystem der Ariane-4 komplett übernommen. Daher konnten die für die Softwaretests vorgesehenen Ausgaben von mehr als 100 Millionen DM drastisch reduziert werden. Eine praxisgerechte Simulation der bei einem Ariane-5-Start anfallenden Datenmengen fand nicht statt. Da die Ariane-5 durch zusätzliche Triebwerke schneller startete als ihr Vorgängermodell, konnten die Computer die Daten nicht schnell genug verarbeiten. Die Ariane-5 musste eine Minute nach dem Start gesprengt werden (Schaden: mehrere Milliarden DM).
• Der als schwarzer Montag in die Börsengeschichte eingegangene 19.10.1987 war zum Großteil durch falsch programmierte Börsenprogramme großer Banken hervorgegangen. Als der Kurs einiger Aktien an diesem Tag besonders stark fiel, verkauften einige Programme automatisch die entsprechenden Aktien. Durch einen Lawineneffekt kam es zu einem weltweit drastischen Absinken der Kurse.
(vgl. Bähnisch: Praktische Informatik 1, S. 193 ff)
65
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Das Probleme der ModifizierbarkeitDas Probleme der Modifizierbarkeit
„Das andere Hauptproblem der Software-Entwicklung besteht darin, die Software so zu entwickeln, dass sie später problemlos geändert werden kann. Für die Entwickler ist es vorteilhaft, wenn die Entwicklung eines Software-Systems nach seiner Fertigstellung beendet ist. Eine weitergehende Betrachtung zeigt jedoch, dass die Entwicklung eines Software-Systems ein evolutionärer Prozess ist, der oft sehr lange währt, und dessen Ende womöglich nicht abzusehen ist.“
(Gumm, Einführung in die Informatik, S. 662 ff)
66
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Der Millennium-BugDer Millennium-Bug
Weil in der Anfangszeit der Computerentwicklung Programmspeicher noch sehr teuer war und mit jedem Byte gegeizt wurde, hatte es sich eingebürgert, die Jahreszahlen in Datumsangaben nur zweistellig statt vierstellig zu speichern.
Beim Jahrtausendwechsel kam es daher zum Umspringen der Jahreszahl von (19)99 auf (19)00.
Einige Pannen:
• Die Münchner Stadtverwaltung verschickte über 400 Mahnungen mit einem Wert von bis zu 60000 DM. Ursache war ein Programmierfehler, der die Verzugszinsen nicht vom Januar 2000 aus, sondern seit Januar 1900 berechnete.
• Mehrere amerikanische Spionagesatelliten sendeten nur nach fehlerhafte Daten.
• In weltweit 16 Kernkraftwerken kam es zu kleineren Unregelmäßigkeiten, die zum Glück sofort geklärt werden konnten.
(vgl. Bähnisch: Praktische Informatik 1, S. 195 ff)
67
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Warum Objektorientierung?Warum Objektorientierung?
These 1 (Oestereich)
Die ganzheitliche Sichtweise in der Modellierung wird den Strukturen, Zusammenhängen und Abhängigkeiten der realen Welt besser gerecht. Anspruchsvollere und komplexere Anwendungsgebiete können infolgedessen einfacher erschlossen werden.
Sichtweise:
- Die Welt ist aus Objekten aufgebaut.
- Der Mensch sieht die Welt objektorientiert.
68
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Warum Objektorientierung?Warum Objektorientierung?
These 2 (Oestereich)
Objektorientierung erlaubt eine durchgängige und konsistent aufeinander aufbauende Entwicklung von Software-Systemen. Dies begünstigt die Qualität der Arbeitsergebnisse.
Phasen:
- objektorientierte Analyse
- objektorientierter Entwurf
- objektorientiertes Programm
Durchgängige Modellrepräsentation
69
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Warum Objektorientierung?Warum Objektorientierung?
These 3 (Oestereich)
Objektorientierung begünstigt einen evolutionären Software-Entwicklungsprozess. Neue Anforderungen können auch während des Entwicklungsprozesses nachgereicht und integriert werden.
- entwicklungsfähige Modelle
- änderungsfreundliche Modelle
70
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
Warum Objektorientierung?Warum Objektorientierung?
These 4 (Oestereich)
Die Kommunikation zwischen Softwareentwickler und den Experten des Anwendungsbereichs wird durch die am Menschen orientierte objektorientierte Sichtweise verbessert.
- am Menschen orientierte Denkweise
- anschauliche Fachsprache
- grafische Modellierungssprache
71
KB
Ob
jekto
rien
tiert
e S
oft
ware
en
twic
klu
ng
LiteraturhinweiseLiteraturhinweise
Helmut Balzert: Lehrbuch Grundlagen der Software-Technik. Spektrum Ak. Verlag 1996.
Eberhard Lehmann: Projekte im Informatik-Unterricht – Software-Engineering. Dümmler-Verlag 1995.
Unterrichtsmaterialien von Klaus Merkert.http://hsg.region-kaiserslautern.de/Informatik/se/index.html
Unterrichtsmaterialien der OSZ-Handel Ihttp://www.oszhdl.be.schule.de/gymnasium/faecher/informatik/material/index.htm
top related