EIS - Implementierung eines Energie

EIS
Implementierung eines
Energie-Informationssystems (Endbericht)
Projektgruppe Energie-Informationssyteme
Daniel Aarden, Ole Behrens, Malte Diehl, Hannes Dillwitz,
Simon Droste, Tammo Filusch, Florian Frische, Winfried Klinker,
Jens Plüster, Dirk Räder, Thorben Witt
30. September 2006
Projektgruppe Energie-Informationssysteme
Carl von Ossietzky Universität Oldenburg
Department für Informatik
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Inhaltsverzeichnis
1 Einleitung
1.1
12
Einführung in den Energiemarkt . . . . . . . . . . . . . . . . . .
13
1.1.1
Begriffe aus der Energiewirtschaft . . . . . . . . . . . . .
13
1.1.2
Weitere EIS-spezifische Begriffe . . . . . . . . . . . . . . .
14
2 Übersicht über das Energieinformationssystem (EIS)
16
2.1
Modellierter Weltausschnitt . . . . . . . . . . . . . . . . . . . . .
16
2.2
Implementierte Funktionen . . . . . . . . . . . . . . . . . . . . .
17
3 Anforderungen an das Produkt
20
3.1
Aus dem Weltmodell abgeleitete Systemabgrenzung
. . . . . . .
20
3.2
Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . .
21
3.2.1
Datenhaltung und -zugriff . . . . . . . . . . . . . . . . . .
21
3.2.2
Dateneingabe und -austausch . . . . . . . . . . . . . . . .
22
3.2.3
Datenbasis . . . . . . . . . . . . . . . . . . . . . . . . . .
22
3.2.4
Energiehandel . . . . . . . . . . . . . . . . . . . . . . . . .
24
3.2.5
Entscheidungsunterstützung . . . . . . . . . . . . . . . . .
24
3.2.6
Fahrplanmanagement . . . . . . . . . . . . . . . . . . . .
26
Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . .
27
3.3.1
Benutzbarkeit . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3.2
Zuverlässigkeit . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3.3
Effizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
3.3.4
Leistungsverhalten . . . . . . . . . . . . . . . . . . . . . .
27
3.3.5
Wartbarkeit/Erweiterbarkeit . . . . . . . . . . . . . . . .
28
3.3.6
Skalierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3.7
Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
3.3.8
Dokumentation . . . . . . . . . . . . . . . . . . . . . . . .
28
Hinzugefügte und entfallene Anforderungen . . . . . . . . . . . .
29
3.3
3.4
4 Umsetzung der Anforderungen
4.1
30
Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.1.1
Programmiersprache . . . . . . . . . . . . . . . . . . . . .
30
4.1.2
Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.1.3
Grafische Oberfläche . . . . . . . . . . . . . . . . . . . . .
31
4.1.4
Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . .
34
2
EIS - Energie-Informationssystem
4.2
4.3
4.4
Projektgruppe Energie-Informationssyteme
Konzepte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2.1
Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.2.2
Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . .
41
4.2.3
Transaktionskontrolle . . . . . . . . . . . . . . . . . . . .
43
4.2.4
Rollenbasierte Sicherheit . . . . . . . . . . . . . . . . . . .
45
4.2.5
Benutzbarkeit/Usability . . . . . . . . . . . . . . . . . . .
47
Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . .
49
4.3.1
Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.3.2
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
4.3.3
Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
Ablauf der Implementierung . . . . . . . . . . . . . . . . . . . . .
54
5 Implementierung der einzelnen Funktionen
5.0.1
5.1
5.2
5.3
5.4
56
ReturnCode-Rückgabewerte . . . . . . . . . . . . . . . . .
56
Stammdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.1.1
Systemnutzer . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.1.2
Kunden und -verträge, Tarife und Lastprofile . . . . . . .
62
5.1.3
Stromlieferanten, Lieferangebote und -verträge . . . . . .
75
5.1.4
Bilanzkreise und Regelzonen . . . . . . . . . . . . . . . .
81
EEX-Handel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
5.2.1
Zugangsdaten zur Energiebörse . . . . . . . . . . . . . . .
89
5.2.2
Abgabe und Bearbeitung von Angeboten . . . . . . . . .
91
5.2.3
Bestätigte Lieferungen . . . . . . . . . . . . . . . . . . . . 100
5.2.4
Aktuelle Marktdaten der Energiebörse . . . . . . . . . . . 105
5.2.5
EEX-Parser . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.2.6
Die Funktionsweise von EEX.exe . . . . . . . . . . . . . . 108
Entscheidungsunterstützung . . . . . . . . . . . . . . . . . . . . . 109
5.3.1
Lastprognosen . . . . . . . . . . . . . . . . . . . . . . . . 109
5.3.2
Störungsverwaltung . . . . . . . . . . . . . . . . . . . . . 115
5.3.3
Kaufempfehlungen . . . . . . . . . . . . . . . . . . . . . . 120
Fahrpläne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6 Tests
139
6.1
Datenbankzugriff . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.2
Webservicetests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.3
Systemtests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.4
Installationstest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
6.5
Lasttests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
7 Vorgehensmodell
7.1
7.2
148
Scrum - Entwicklungsmodell für das EIS . . . . . . . . . . . . . . 148
7.1.1
Agile Softwareentwicklung . . . . . . . . . . . . . . . . . . 148
7.1.2
Eigenschaften agiler Softwareentwicklung mit Scrum . . . 150
7.1.3
Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
7.1.4
Product Backlog . . . . . . . . . . . . . . . . . . . . . . . 152
7.1.5
Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . 152
7.1.6
Daily Scrum
7.1.7
Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . 152
7.1.8
Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . 152
. . . . . . . . . . . . . . . . . . . . . . . . . 152
Erfahrungen mit Scrum . . . . . . . . . . . . . . . . . . . . . . . 152
7.2.1
Eigene Umsetzung . . . . . . . . . . . . . . . . . . . . . . 153
7.2.2
Planen der Sprints und Sprint Review Meetings . . . . . . 153
7.3
Warm Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.4
Erster Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
7.5
7.6
7.7
7.8
7.9
7.4.1
Verlauf des ersten Sprints . . . . . . . . . . . . . . . . . . 155
7.4.2
Probleme und Ereignisse im ersten Sprint . . . . . . . . . 156
7.4.3
Review Meeting des ersten Sprints . . . . . . . . . . . . . 157
Zweiter Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.5.1
Verlauf des zweiten Sprints . . . . . . . . . . . . . . . . . 157
7.5.2
Probleme und Ereignisse im zweiten Sprint . . . . . . . . 158
7.5.3
Review Meeting zum zweiten Sprint . . . . . . . . . . . . 159
Dritter Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.6.1
Verlauf des dritten Sprints . . . . . . . . . . . . . . . . . . 159
7.6.2
Probleme und Ereignisse im dritten Sprint . . . . . . . . . 159
7.6.3
Review Meeting zum dritten Sprint . . . . . . . . . . . . . 160
Vierter Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
7.7.1
Verlauf des vierten Sprints . . . . . . . . . . . . . . . . . . 160
7.7.2
Probleme und Ereignisse im vierten Sprint . . . . . . . . . 161
7.7.3
Review Meeting zum vierten Sprint . . . . . . . . . . . . 162
Fünfter Sprint
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
7.8.1
Verlauf des 5. Sprints . . . . . . . . . . . . . . . . . . . . 162
7.8.2
Probleme und Ereignisse im fünften Sprint . . . . . . . . 162
7.8.3
Review Meeting zum fünften Sprint . . . . . . . . . . . . 162
Abschlussarbeiten und Organisation . . . . . . . . . . . . . . . . 162
4
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
8 Fazit
164
8.1
Allgemeines Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
8.2
Thematik Energieinformationssysteme . . . . . . . . . . . . . . . 164
8.3
Umsetzung des Entwurfs . . . . . . . . . . . . . . . . . . . . . . . 165
8.4
Implementierung des Programms . . . . . . . . . . . . . . . . . . 165
8.5
Arbeit als Projektgruppe
8.6
Die Arbeit mit Scrum . . . . . . . . . . . . . . . . . . . . . . . . 167
8.7
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
. . . . . . . . . . . . . . . . . . . . . . 166
9 Benutzerhandbuch
169
9.1
Willkommen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
9.2
Systemvorausetzungen . . . . . . . . . . . . . . . . . . . . . . . . 169
9.3
9.4
9.2.1
Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
9.2.2
Betriebsystem . . . . . . . . . . . . . . . . . . . . . . . . . 169
9.2.3
Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
9.3.1
Installation der Serverkomponenten . . . . . . . . . . . . 170
9.3.2
Datenbank aufsetzen . . . . . . . . . . . . . . . . . . . . . 170
9.3.3
Konfiguration der Datenbankverbindung . . . . . . . . . . 172
9.3.4
EEX-Marktdaten aktualisieren . . . . . . . . . . . . . . . 172
9.3.5
Installation der Clientanwendung . . . . . . . . . . . . . . 173
Erste Schritte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
9.4.1
Programm starten . . . . . . . . . . . . . . . . . . . . . . 174
9.4.2
Serveradresse angeben . . . . . . . . . . . . . . . . . . . . 174
9.4.3
Einloggen . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
9.4.4
Administratorpasswort ändern . . . . . . . . . . . . . . . 174
9.4.5
Benutzer anlegen . . . . . . . . . . . . . . . . . . . . . . . 175
9.5
Der Startbildschirm . . . . . . . . . . . . . . . . . . . . . . . . . 176
9.6
Das ToDo-Panel . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
9.7
Fehlermeldungen . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
9.8
Auswahlfenster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
9.9
9.8.1
Auswahl für Tarife . . . . . . . . . . . . . . . . . . . . . . 179
9.8.2
Auswahl für Regelzonen . . . . . . . . . . . . . . . . . . . 179
9.8.3
Auswahl für Lastprofile . . . . . . . . . . . . . . . . . . . 180
9.8.4
Auswahl für Bilanzkreise
. . . . . . . . . . . . . . . . . . 180
Kunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
5
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
9.9.1
Kunden anlegen . . . . . . . . . . . . . . . . . . . . . . . 181
9.9.2
Kunden bearbeiten . . . . . . . . . . . . . . . . . . . . . . 182
9.9.3
Kunden löschen . . . . . . . . . . . . . . . . . . . . . . . . 183
9.9.4
Kundenvertrag anlegen . . . . . . . . . . . . . . . . . . . 183
9.9.5
Kundenvertrag bearbeiten . . . . . . . . . . . . . . . . . . 185
9.9.6
Kundenvertrag löschen . . . . . . . . . . . . . . . . . . . . 185
9.10 Lastprofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
9.10.1 Lastprofile anlegen . . . . . . . . . . . . . . . . . . . . . . 187
9.10.2 Lastprofile bearbeiten . . . . . . . . . . . . . . . . . . . . 188
9.10.3 Lastprofile löschen . . . . . . . . . . . . . . . . . . . . . . 188
9.11 Tarife . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
9.11.1 Tarife anlegen . . . . . . . . . . . . . . . . . . . . . . . . . 189
9.11.2 Tarife bearbeiten . . . . . . . . . . . . . . . . . . . . . . . 190
9.11.3 Tarife löschen . . . . . . . . . . . . . . . . . . . . . . . . . 190
9.12 Fahrpläne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
9.12.1 Fahrplan erstellen . . . . . . . . . . . . . . . . . . . . . . 191
9.12.2 Fahrplan löschen . . . . . . . . . . . . . . . . . . . . . . . 192
9.13 Kaufempfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . 193
9.13.1 Schritt 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
9.13.2 Schritt 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
9.13.3 Schritt 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
9.13.4 Schritt 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
9.13.5 Schritt 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
9.13.6 Schritt 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
9.14 Lieferanten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
9.14.1 Lieferanten anlegen . . . . . . . . . . . . . . . . . . . . . . 199
9.14.2 Lieferanten bearbeiten . . . . . . . . . . . . . . . . . . . . 200
9.14.3 Lieferanten löschen . . . . . . . . . . . . . . . . . . . . . . 200
9.14.4 Lieferangebot/–vertrag anlegen . . . . . . . . . . . . . . . 200
9.14.5 Lieferangebot/-vertrag bearbeiten . . . . . . . . . . . . . 201
9.14.6 Lieferangebot/-vertrag löschen . . . . . . . . . . . . . . . 201
9.15 Lastprognosen
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
9.16 Bilanzkreise und Regelzonen . . . . . . . . . . . . . . . . . . . . . 205
9.16.1 Massenupdate . . . . . . . . . . . . . . . . . . . . . . . . . 205
9.17 EEX - Angebote . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
9.17.1 Blockgebote . . . . . . . . . . . . . . . . . . . . . . . . . . 208
6
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
9.17.2 Stundengebote . . . . . . . . . . . . . . . . . . . . . . . . 209
9.17.3 EEX-Lieferungen eintragen . . . . . . . . . . . . . . . . . 209
9.18 EEX - Lieferungen . . . . . . . . . . . . . . . . . . . . . . . . . . 211
9.18.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
9.18.2 Lieferung bearbeiten . . . . . . . . . . . . . . . . . . . . . 211
9.18.3 Lieferung löschen . . . . . . . . . . . . . . . . . . . . . . . 212
9.19 Störungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
9.19.1 Störung melden . . . . . . . . . . . . . . . . . . . . . . . . 213
9.19.2 Störung bearbeiten . . . . . . . . . . . . . . . . . . . . . . 213
9.19.3 Störung löschen . . . . . . . . . . . . . . . . . . . . . . . . 214
9.20 Systemnutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
9.20.1 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
9.20.2 Benutzer anlegen/bearbeiten . . . . . . . . . . . . . . . . 217
9.20.3 Benutzer löschen . . . . . . . . . . . . . . . . . . . . . . . 217
9.21 Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
9.21.1 Szenario 1: Herausgabe einer aktualisierten Bilanzkreisliste 218
9.21.2 Szenario 2: Abschluss eines neuen Vertrages . . . . . . . . 221
9.22 Hilfefunktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
10 Glossar
225
Literatur
227
7
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildungsverzeichnis
1
Der Implementierung zugrunde liegender Weltausschnitt . . . . .
16
2
Aufbau der Entscheidungsunterstützung . . . . . . . . . . . . . .
26
3
Ausführliche Fehlermeldung mit Eingabemöglichkeit . . . . . . .
42
4
Usability Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5
Architekt des implementierten Energieinformationssystems
. . .
50
6
Struktur der Solution in Microsoft Visual Studio . . . . . . . . .
50
7
Datenbankschema des Energieinformationssystems . . . . . . . .
52
8
Klassen EisUser, Person und EisUserRole . . . . . . . . . . . . .
57
9
Klasse EisUserDAL . . . . . . . . . . . . . . . . . . . . . . . . . .
58
10
Klasse UserManager . . . . . . . . . . . . . . . . . . . . . . . . .
59
11
Übersicht über alle Systemnutzer . . . . . . . . . . . . . . . . . .
61
12
Anlegen oder Bearbeiten eines Nutzers . . . . . . . . . . . . . . .
61
13
Klassen zur Kundenverwaltung . . . . . . . . . . . . . . . . . . .
64
14
Klasse CustomerDAL . . . . . . . . . . . . . . . . . . . . . . . .
64
15
Klasse CustomerManager . . . . . . . . . . . . . . . . . . . . . .
65
16
Klasse CustomerCustomerContractDAL . . . . . . . . . . . . . .
66
17
Klasse CustomerCustomerContractManager . . . . . . . . . . . .
68
18
Anlegen oder Bearbeiten eines Kunden . . . . . . . . . . . . . . .
69
19
Anlegen oder Bearbeiten eines Kundenvertrages . . . . . . . . . .
69
20
Übersicht über Kunden und ihre Verträge . . . . . . . . . . . . .
70
21
Klasse EnergyProfileDAL . . . . . . . . . . . . . . . . . . . . . .
73
22
Klasse EnergyProfileManager . . . . . . . . . . . . . . . . . . . .
74
23
Hauptfenster der Lastprofilverwaltung . . . . . . . . . . . . . . .
75
24
Eingabefenster für Lastprofile . . . . . . . . . . . . . . . . . . . .
76
25
Lieferant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
26
Lieferangebot und -vertrag . . . . . . . . . . . . . . . . . . . . . .
78
27
Lieferanten im Datenzugriff . . . . . . . . . . . . . . . . . . . . .
79
28
Lieferanten in der Geschäftslogik . . . . . . . . . . . . . . . . . .
80
29
Bilanzkreis- und Regelzonenobjekt . . . . . . . . . . . . . . . . .
82
30
Datenzugriff auf Bilanzkreise und Regelzonen . . . . . . . . . . .
83
31
Bilanzkreise und Regelzonen in der Geschäftslogik . . . . . . . .
85
32
Übersicht der vorhandenen Bilanzkreise . . . . . . . . . . . . . .
87
33
Bearbeiten-Fenster für einen Bilanzkreis . . . . . . . . . . . . . .
87
34
Panel für EEX-Handel . . . . . . . . . . . . . . . . . . . . . . . .
89
8
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
35
Klasse EexAccount . . . . . . . . . . . . . . . . . . . . . . . . . .
90
36
Klasse EexAccountDAL . . . . . . . . . . . . . . . . . . . . . . .
90
37
Eingabefenster für EEX-Zugangsdaten . . . . . . . . . . . . . . .
91
38
Klassen EexHourBid und EexHourBidDetails . . . . . . . . . . .
92
39
Klassen EexBlockBid und EexBlockBidDetails . . . . . . . . . .
93
40
Erstellung des Reports für Stundenangebote in Visual Studio 2005 94
41
Vorschau auf den PDF-Export eines Stundenangebots . . . . . .
95
42
Klassen für den Datenbankzugriff auf EEX-Angebote . . . . . . .
95
43
Eingabefenster für Stundenangebote . . . . . . . . . . . . . . . .
98
44
Eingabefenster zur Preissetzung für Stundenangebote
99
45
Eingabefenster für Blockangebote . . . . . . . . . . . . . . . . . . 100
46
Klasse EexManager . . . . . . . . . . . . . . . . . . . . . . . . . . 101
47
Klasse EexDelivery . . . . . . . . . . . . . . . . . . . . . . . . . . 102
48
Klasse EexDeliveryDAL . . . . . . . . . . . . . . . . . . . . . . . 102
49
EEX-Lieferungsübersicht mit Bearbeitungsmöglichkeiten . . . . . 104
50
Eingabefenster für EEX-Lieferungen . . . . . . . . . . . . . . . . 105
51
Klasse EexMarketData . . . . . . . . . . . . . . . . . . . . . . . . 105
52
Klasse EexMarketDataDAL . . . . . . . . . . . . . . . . . . . . . 106
53
Fenster für aktuelle Marktdaten . . . . . . . . . . . . . . . . . . . 108
54
Die GUI für den EEX-Scraper . . . . . . . . . . . . . . . . . . . . 109
55
Die Program-Klasse von EEX.exe . . . . . . . . . . . . . . . . . . 110
56
Klassen EnergyPrediction und EnergyPredictionTimeSeries . . . 111
57
Klasse EnergyPredictionDAL . . . . . . . . . . . . . . . . . . . . 111
58
Klasse EnergyPredictionManager . . . . . . . . . . . . . . . . . . 112
59
GUI zur Erstellung von Lastprognosen . . . . . . . . . . . . . . . 113
60
GUI zur Konfiguration des AdvancedPredictionPlugin
61
Klasse Disturbance . . . . . . . . . . . . . . . . . . . . . . . . . . 115
62
Klasse DisturbanceDAL . . . . . . . . . . . . . . . . . . . . . . . 116
63
Klasse DisturbanceManager . . . . . . . . . . . . . . . . . . . . . 117
64
Störungsverwaltung
65
Neue Störung eingeben . . . . . . . . . . . . . . . . . . . . . . . . 119
66
Liefervertrag auswählen . . . . . . . . . . . . . . . . . . . . . . . 119
67
Klasse Recommendation . . . . . . . . . . . . . . . . . . . . . . . 120
68
Klasse RecommendationDAL . . . . . . . . . . . . . . . . . . . . 121
69
Klasse RecommendationManager . . . . . . . . . . . . . . . . . . 122
70
Auswahl der zu verwendenden Lastprognose . . . . . . . . . . . . 124
. . . . . .
. . . . . . 114
. . . . . . . . . . . . . . . . . . . . . . . . . 118
9
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
71
Zu berücksichtigenden Lieferverträge und -angebote . . . . . . . 124
72
Auswahl des Kaufempfehlungs-Algorithmus . . . . . . . . . . . . 125
73
Konfiguration des Kaufempfehlungs-Algorithmus . . . . . . . . . 125
74
Ergebnis der Berechnung . . . . . . . . . . . . . . . . . . . . . . . 126
75
Nachbearbeitung der Kaufempfehlung . . . . . . . . . . . . . . . 127
76
Schematischer Ablauf der Evolutionsstrategie . . . . . . . . . . . 127
77
Klassen Schedule und ScheduleTimeSeries . . . . . . . . . . . . . 131
78
Klasse ScheduleDAL . . . . . . . . . . . . . . . . . . . . . . . . . 133
79
Klasse ScheduleManager . . . . . . . . . . . . . . . . . . . . . . . 135
80
Grafische Oberfläche für Fahrpläne . . . . . . . . . . . . . . . . . 137
81
Testprotokoll nach Lasttest in Visual Studio . . . . . . . . . . . . 146
82
Agiler Prozess im Scrum-Modell . . . . . . . . . . . . . . . . . . 149
83
Wirtschaftlichkeit von agilen und konventionellen Methoden . . . 150
84
Terminplanung der einzelnen Scrums . . . . . . . . . . . . . . . . 154
85
SQL Server Management Studio . . . . . . . . . . . . . . . . . . 171
86
SQL Server Management Studio - Datenbankdatei auswählen . . 172
87
Vergabe der Benutzerrechte . . . . . . . . . . . . . . . . . . . . . 173
88
Auswahlfenster zum Aktualisieren der EEX Marktdaten . . . . . 174
89
Die Startoberfläche des Programms . . . . . . . . . . . . . . . . . 176
90
Hier geben Sie die Daten in die ToDo-Liste ein . . . . . . . . . . 177
91
Fehlermeldung bei inkorrekten Daten . . . . . . . . . . . . . . . . 178
92
Eine Fehlermeldung, die Sie auf unzureichende Rechte hinweist. . 178
93
Das Auswahlfenster für Tarife . . . . . . . . . . . . . . . . . . . . 179
94
Das Auswahlfenster für Regelzonen . . . . . . . . . . . . . . . . . 179
95
Das Auswahlfenster für Lastprofile . . . . . . . . . . . . . . . . . 180
96
Das Auswahlfenster für Bilanzkreise . . . . . . . . . . . . . . . . 180
97
Die Oberfläche zur Verwaltung von Kunden und deren Verträge . 181
98
Einen neuen Kunden anlegen . . . . . . . . . . . . . . . . . . . . 182
99
Einen bestehenden Kunden bearbeiten . . . . . . . . . . . . . . . 182
100 Einen bestehenden Kunden löschen . . . . . . . . . . . . . . . . . 183
101 Einen neuen Kundenvertrag anlegen . . . . . . . . . . . . . . . . 183
102 Einem Kunden ein Lastprofil zuweisen . . . . . . . . . . . . . . . 184
103 Einem Kunden einen Tarif zuweisen . . . . . . . . . . . . . . . . 184
104 Einem Kunden eine Regelzone zuweisen . . . . . . . . . . . . . . 185
105 Einem Kunden einen Bilanzkreis zuweisen . . . . . . . . . . . . . 185
106 Einen bestehenden Kundenvertrag bearbeiten . . . . . . . . . . . 186
10
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
107 Die Oberfläche zur Verwaltung von Lastprofilen . . . . . . . . . . 187
108 Ein neues Lastprofil anlegen . . . . . . . . . . . . . . . . . . . . . 188
109 Ein Lastprofil bearbeiten
. . . . . . . . . . . . . . . . . . . . . . 188
110 Die Oberfläche zur Verwaltung von Tarifen . . . . . . . . . . . . 189
111 Einen neuen Tarif anlegen . . . . . . . . . . . . . . . . . . . . . . 190
112 Einen Tarif bearbeiten . . . . . . . . . . . . . . . . . . . . . . . . 190
113 Die Oberfläche zur Erstellung von Fahrplänen . . . . . . . . . . . 191
114 Einen Fahrplan im Browserfenster anzeigen . . . . . . . . . . . . 192
115 Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 1 . 193
116 Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 2 . 194
117 Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 3 . 195
118 Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 4 . 196
119 Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 5 . 197
120 Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 6 . 198
121 Die Oberfläche zur Verwaltung von Lieferanten . . . . . . . . . . 199
122 Ein bestehenden Lieferanten bearbeiten . . . . . . . . . . . . . . 200
123 Ein Lieferangebot/-vertrag anlegen . . . . . . . . . . . . . . . . . 201
124 Eine Regelzone auswählen . . . . . . . . . . . . . . . . . . . . . . 201
125 Die Oberfläche zur Verwaltung und Erstellung von Lastprognosen 203
126 Oberfläche zur Verwaltung von Bilanzkreisen und Regelzonen . . 205
127 Die Oberfläche zur Verwaltung von EEX-Angeboten . . . . . . . 207
128 EEX-Daten ändern . . . . . . . . . . . . . . . . . . . . . . . . . . 208
129 Ein Blockangebot erstellen . . . . . . . . . . . . . . . . . . . . . . 209
130 Ein Stundenangebot erstellen . . . . . . . . . . . . . . . . . . . . 210
131 Die Oberfläche zur Verwaltung von EEX-Lieferungen . . . . . . . 211
132 Die Oberfläche zur Verwaltung und Erstellung von Störungen . . 213
133 Die Oberfläche zur Verwaltung von Systemnutzern . . . . . . . . 215
134 Einen Systemnutzer hinzufügen . . . . . . . . . . . . . . . . . . . 216
135 Die ToDo-Liste zeigt, dass heute eine Aufgabe anliegt . . . . . . 218
136 Auswahl der CSV-Datei zur Listenaktualisierung . . . . . . . . . 219
137 Bearbeitung des Ereignisses in der ToDo-Liste . . . . . . . . . . . 220
138 In der Lieferantenansicht prüft der Nutzer die Angebote . . . . . 221
139 In der Störungsansicht vergleicht der Nutzer die Störrate . . . . . 222
140 Verwaltung von Angeboten und Verträgen in Lieferantenansicht . 223
11
EIS - Energie-Informationssystem
1
Projektgruppe Energie-Informationssyteme
Einleitung
Dies ist der Endbericht der Projektgruppe Energieinformationssysteme, die in
der Abteilung Informationssysteme des Departments für Informatik der Universität Oldenburg vom 1. Oktober 2005 bis zum 30. September 2006 veranstaltet
wurde. Neben dem offiziellen Namen wurden den Teilnehmern kaum Vorgaben
hinsichtlich ihrer Arbeit gemacht, außer dass sie sich mit dem Geschehen und
den Abläufen in der Energiebranche beschäftigen sollte.
Nachdem in der Seminarphase zunächst zahlreiche Vorträge rund um die
Themen Energieversorgung, liberalisierte Energiemärkte und Produktionsplanungssysteme gehalten worden waren, begann folglich eine Diskussion über die
weitere Vorgehensweise. Nur kurze Zeit später war vor dem Hintergrund der voranschreitenden Liberalisierung der Strommärkte die Entscheidung gefallen, ein
Informationssystem zu implementieren, das Energiehändlern bei ihrer täglichen
Arbeit rund um Stromein- und -verkauf hilft und auch umfangreiche Entscheidungsunterstützung in wichtigen Fragen bietet.
Der vorliegende Bericht ist nun das Ergebnis der zwölf Monate Planung und
Entwicklung der Projektgruppe Energieinformationssysteme. In den folgenden
Kapiteln stellt er die wesentlichen Resultate der Gruppenarbeit heraus und bietet dem Leser darüber hinaus eine verständliche Darstellung der Entscheidungsprozesse und Vorgehensweisen innerhalb der Gruppe. Viele Entscheidungen und
Ergebnisse im Vorfeld der Implementierung wurden schon im ersten Semester
dieses Projektes erarbeitet. Diese sind im Zwischenbericht enthalten. Auf ihn
wird im Verlauf dieses Endberichtes des öfteren verwiesen. Im Zwischenbericht,
der Anfang April 2006 abgegeben wurde, sind
• die Ausarbeitung der einzelnen Projektgruppenmitglieder für die anfängliche Seminarphase,
• die ursprüngliche Anforderungsdefinition und
• der detaillierte Entwurf der Implementierung enthalten.
Kapitel zwei dieses Berichts bietet einen kurzen Überblick über den betrachteten Weltausschnitt und das daraus entstandene Programm. In Kapitel drei
werden die Anforderungen, die als Grundlage der Implementierung an das Programm gestellt wurden, zusammengefasst. Das darauffolgende Kapitel erläutert
den Ablauf der Implementierung und, welche Technologien, Konzepte und Softwarearchitektur zur Erfüllung der zuvor gestellten Anforderungen eingesetzt
wurden. Die einzelnen Funktionen des Programms werden dann in Kapitel fünf
ausführlich vorgestellt, wobei der Schwerpunkt auf der Art und Weise der Implementierung in den verschiedenne Schichten der Archtektur liegt. Kapitel sechs
beschäftigt sich anschließend mit den verschiedenen Testarten, die eingesetzt
wurden, um einen reibungslosen Programmablauf sicherzustellen. Im siebten
Kapitel wird das Vorgehensmodell, das während der Implementierung verfolgt
wurde, dargestellt, bevor im achten ein detailliertes Fazit der Arbeit samt Ausblick auf zukünftige Entwicklungsmöglichkeiten des Programms geboten wird.
Das neunte und letzte Kapitel ist ein Benutzerhandbuch. Während das fünfte Kapitel beschreibt, wie das System implementiert wurde und was es kann,
12
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
wird hier gezeigt, wie man die einzelnen Funktionen korrekt bedient, was man
beachten muss, welche Systemanforderungen das Programm stellt und wie man
es installiert. Zudem werden auch einige Benutzungsszenarien durchgespielt, die
typische Handlungsabfolgen einfach erklären.
1.1
Einführung in den Energiemarkt
In den letzten Jahren wurde der europäische Energiemarkt zunehmend liberalisiert. Das Stromnetz ist nicht mehr in staatlicher Hand, sondern wird von
einigen so genannten Übertragungsnetzbetreibern (ÜNB) verwaltet, denen zugleich die meisten Kraftwerke gehören. Die Energiehändler, die eine Vielzahl
von Endkunden zu beliefern haben1 , kaufen zu diesem Zweck Strom bei anderen
Energiehändlern und melden die daraus resultierenden Stromflüsse regelmäßig
den Netzbetreibern. Diese haben die Pflicht, dafür zu sorgen, dass jederzeit auf
Grundlage der Angaben der Energiehändler die passende Energiemenge an jeden Ort des Netzes gelangt. Der Datenaustausch zwischen den ÜNB und den
Händlern sowie die Bilanzierung der Energiemengen erfolgt in länderübergreifend einheitlichen Standards.
Im Folgenden werden nun in alphabetischer Reihenfolge einige Begriffe erklärt, die für das Verständnis der Vorgänge auf dem Energiemarkt unabdingbar
sind. Des weiteren werden die für das Verständnis der Arbeit der Projektgruppe
und der Funktionsweise des erstellten Energieinformationssystems (EIS) wichtigsten und immer wieder vorkommenden Termini definiert.
1.1.1
Begriffe aus der Energiewirtschaft
Bilanzkreis: Ein Bilanzkreis ist eine Sammlung aus Stromeinspeise- und entnahmepunkten, der zwischen ÜNB ↓ und Energiehändler oder ausländischem Netzbetreiber definiert wird. Die Salden von Einspeisung und
Entnahme müssen stets ausgeglichen sein. Strom kann zwischen zwei Regelzonen nur innerhalb eines Bilanzkreises ausgetauscht werden.
Energiehändler: Energiehändler kaufen Strom bei Kraftwerksbetreibern oder
anderen Energiehändlern ein und verkaufen diesen an Endverbraucher
oder weitere Energiehändler. Sie verfügen über kein eigenes Netz und werden durch einen bei den ÜNBs registrierten Bilanzkreis repräsentiert.
European Transmission System Operators (ETSO): Hierbei handelt es
sich um den Zusammenschluss der europäischen Übertragungsnetzbetreiber mit dem Ziel, die Arbeit besser miteinander zu koordinieren und einheitliche Standards für den Energieaustausch zwischen den verschiedenen
Netzen zu schaffen.
ETSO Scheduling System (ESS): Das ETSO Scheduling System ist ein von
der ETSO herausgegebenes, auf XML basierendes Fahrplanformat, in dem
seit Mitte 2004 alle Akteure am Energiemarkt ihre Fahrpläne an die ÜNBs
weiterleiten müssen. Weitergehende Informationen befinden sich in [For03].
1 Es gibt auch zahlreiche Akteure wie etwa die Deutsche Bank, die nur zum Zwecke der
Spekulation an den entsprechenden Börsen Strom kaufen und verkaufen und keinerlei Kundenverträge zu bedienen haben.
13
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Fahrplan: Die ÜNBs erhalten von den anderen ÜNBs, Energiehändlern und
ausländischen Netzbetreibern täglich Fahrpläne, in denen in Viertelstundenblöcken der Stromtransfer von einem Bilanzkreis (einer Regelzone) in
einen anderen Bilanzkreis (eine andere Regelzone) in Megawatt aufgeführt wird. Fahrpläne können kurzfristig angepasst und sogar noch nach
Inkrafttreten verändert werden. Ihre Erstellung erfolgt auf Grundlage der
Lastprofile für Objekte eines bestimmten Bilanzkreises (einer bestimmten
Regelzone).
Lastprofil: Zu jedem Objekt, das mit Strom beliefert wird, gehört ein Lastprofil, das seinen Bedarf in Abhängigkeit von Parametern wie Uhr- und
Jahreszeit beschreibt, um die Stromerzeugung verlässlich planen zu können.
Regelzone: Jedem ÜNB ist ein bestimmter Bereich zugeordnet, in dem er
Stromeinspeisung und -entnahme regelt und die Salden ausgleicht. Diese Bereiche werden Regelzonen genannt. Innerhalb einer Regelzone kann
Strom zwischen beliebigen Bilanzkreisen ausgetauscht werden.
Übertragungsnetzbetreiber (ÜNB): Übertragungsnetzbetreiber sind diejenigen Unternehmen, denen das Netz an Freiluft- und Erdkabeln zum
Stromtransport gehört. In Deutschland sind dies EnBW, Vattenfall, RWE
und E.ON.
1.1.2
Weitere EIS-spezifische Begriffe
Kaufempfehlung: Eine Kaufempfehlung wird anhand der Lastprognose erstellt und listet die Angebote auf, deren gleichzeitiger Abschluss möglichst
kostengünstig und möglichst vollständig den für den Zeitraum der Lastprognose gültigen Strombedarf decken kann.
Kunde: Kunden sind Einzelpersonen, Unternehmen und Haushalte, die ihren
Strombedarf über den Energiehändler teilweise oder ganz decken.
Kundenvertrag: Kundenverträge sind Verträge, die der Energiehändler mit
seinen Kunden geschlossen hat und in denen er ihnen Stromlieferungen zu
bestimmten Konditionen zusichert.
Lastprognose: Lastprognosen werden auf Basis der Lastprofile der Kunden
erstellt und geben für bestimmte Zeiträume an, wie viel Strom voraussichtlich eingekauft werden muss, um den Kundenbedarf zu decken. Sie
werden für verschieden lange Zeiträume erstellt.
Lieferant: Unter der Bezeichnung Lieferant werden die Kraftwerksbetreiber
und Energieanbieter zusammengefasst, die dem Energiehändler Stromlieferungen anbieten.
Lieferangebot: Lieferangebote werden von Lieferanten gemacht und umfassen
eine Strommenge, die zu einem bestimmten Preis über einen bestimmten
Zeitraum lang zur Verfügung gestellt werden kann.
Liefervertrag: Lieferverträge sind angenommene Lieferangebote, die dadurch
für den Lieferanten verbindlich geworden sind.
14
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Marktdaten: Unter Marktdaten sind die wichtigsten Kurse der European Energy Exchange (EEX) in Leipzig zusammengefasst, die dem Energiehändler
und den Nutzern einen Überblick über die aktuelle Marktlage und damit
die Eignung der vorliegenden Angebote gewähren.
Nutzer: Als Nutzer werden im Folgenden die Personen bezeichnet, die das EIS
bedienen; also im wesentlichen Angestellte des jeweiligen Energiehändlers,
der das System einsetzt.
Tarif: Als Tarif werden die Konditionen, zu denen Strom an ein bestimmtes
Objekt geliefert wird, genannt. Tarife richten sich im Allgemeinen vor
allem nach Abnahmemenge, Lieferzeitraum und Energiemix.
Störung: Störungen sind unvorhergesehene Ereignisse, die die Bereitstellung
des Stroms durch Lieferanten oder die Abnahme des Stroms durch Kunden
beeinträchtigen.
15
EIS - Energie-Informationssystem
2
2.1
Projektgruppe Energie-Informationssyteme
Übersicht über das Energieinformationssystem
(EIS)
Modellierter Weltausschnitt
Abbildung 1: Der Implementierung zugrunde liegender Weltausschnitt
Abbildung 1 stellt den als Basis des Energieinformationssystems modellierten Weltausschnitt dar. In ihm steht der Energiehändler im Zentrum des modellierten Weltausschnitts, weil er der zentrale Akteur ist, der Energieein- und
-verkauf koordiniert und das Geschäft überwacht. Die Abläufe innerhalb des
Weltausschnitts werden durch die schwarzen Pfeile symbolisiert. Kleine Kreise
sind Knoten, an denen wichtige Elemente des Weltausschnitts aufeinander treffen. Die Rechtecke symbolisieren Entitäten, also zum Beispiel handelnde Subjekte. Eine typische Handlungskette, die sich durch den ganzen Weltausschnitt
zieht, ist die folgende:
Zunächst melden sich Kunden beim Energiehändler an und schließen mit ihm
für beliebige Objekte (Häuser, Fabriken etc.) Verträge ab, um diese mit Strom
zu versorgen. Verträge basieren auf einem Tarif, in dem der Strompreis und
16
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
der Anteil erneuerbarer Energien festgehalten werden. Darüber hinaus verfügen
sie jeweils über ein Lastprofil, das zeitlich detailliert aufgeschlüsselte Angaben
über die benötigten Energiemengen enthält. Auf Grundlage der Kundenverträge
werden nun für jeden Tag Lastprognosen erstellt, die den Gesamtstrombedarf
des Energiehändlers zur Versorgung seiner Kunden berechnen.
Gleichzeitig geben Energieanbieter, also z. B. andere Energiehändler oder
Kraftwerksbetreiber, Lieferangebote beim Energiehändler ab. Diese Angebote
und die Lastprognosen dienen als Basis für die vom System erzeugten Kaufempfehlungen, die nach bestimmten Kriterien wie optimale Bedarfsdeckung oder
minimale Kosten Lieferangeboten heraussucht und zum Abschluss vorschlägt.
Durch aktuelle Marktdaten von der Europäischen Energiebörse werden die Entscheidungen des Nutzers zusätzlich beeinflusst.
Aus dem Abschluss von Lieferverträgen ergibt sich dennoch oftmals eine
gewisse Fehldeckung, auch können sie durch Störungen wie etwa Kraftwerksnotabschaltungen unerwartet beeinträchtigt werden, weswegen durch kurzfristige Angebote an der EEX versucht werden muss, zusätzlichen Strom zu kaufen
oder überschüssigen zu verkaufen. Kommt es an der EEX dazu, dass ein anderer Energiehändler ein solches Angebot teilweise oder ganz akzeptiert, resultiert
daraus eine neue Lieferung, hier zur Abgrenzung von herkömmlichen Lieferverträgen als EEX-Lieferung bezeichnet. Sind alle Lieferungen für einen bestimmten
Tag vereinbart und die Kundenbedürfnisse gedeckt, kann der Nutzer einen Fahrplan im von der ETSO vorgegebenen ESS-Format erstellen, der die einzelnen
Lieferungen an den Händler für jeden betroffenen Übertragungsnetzbetreiber
aufsaldiert.
Mit der auf der Grundlage dieses Modells erstellten Software kann unter
anderem dieses Szenario nachempfunden werden. Eingesetzt wird sie vom Energiehändler, benutzt von seinen Angestellten, die in ihren verschiedenen Rollen
die Datenbasis pflegen und sie zur Entscheidungsunterstützung nutzen. Wenn
in dem Modell ein Lieferant ein Lieferangebot abgibt, so bedeutet dies für die
Benutzung des Programms, dass ein Nutzer, dem als Aufgabe die Lieferantenbetreuung zugewiesen wurde, die Daten dieses Angebots ins System eingibt.
2.2
Implementierte Funktionen
Das EIS, das in den vergangenen sechs Monaten implementiert wurde, dient
als unterstützendes System für einen Energiehändler, der sich bei Stromerzeugern, anderen Lieferanten und der Europäischen Energiebörse (EEX) mit Strom
eindeckt, um seine Kunden, also die Endabnehmer des Stroms, gemäß den laufenden Verträgen zu bedienen. Dazu wurden vier große Funktionsblöcke implementiert:
• Stammdatenverwaltung: In diesen Block fallen alle Funktionen, die zur
Administration des Systems dienen (Nutzer- und Rechteverwaltung), sowie die Verwaltung von Kunden- und Lieferantendaten. Hierzu gehören
bei der Kundenverwaltung die personen- oder firmenbezogenen Daten der
Kunden selbst, ihre Verträge mit dem Händler, die ihnen Stromlieferungen zum Endverbrauch zu sichern, die Lastprofile, nach denen die Kunden
17
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
beliefert werden, sowie die verschiedenen Tarife, zu denen der Händler seinen Strom anbietet. Zur Lieferantenverwaltung gehört die Verwaltung der
personen- und firmenbezogenen Daten der Lieferanten sowie deren Lieferangebote und die abgeschlossenen Lieferverträge. Außerdem kommen die
Datenbestände zu Regelzonen und Bilanzkreise hinzu, die dazu dienen,
Verträge und Stromflüsse nach Verantwortungsbereichen zu ordnen, und
für EEX-Handel sowie Fahrpläne benötigt werden. Zu jedem dieser Punkte
bietet die Stammdatenverwaltung Möglichkeiten zum Anlegen, Auslesen,
Ändern und Löschen von Objekten.
• EEX-Handel: Während normale Lieferverträge eher der langfristigen Versorgung dienen, ist der EEX-Handel eher zur Beseitigung kurzzeitiger Fehldeckungen gedacht. Es können Angebote für die EEX erstellt und in die
von der EEX bereitgestellten Faxvorlage exportiert werden. Zu abgegebenen Angeboten können darüber hinaus Lieferungen eingetragen werden,
falls sich an der EEX ein Handelspartner gefunden hat. Auf diesem Wege ist es sowohl möglich, zusätzlich benötigten Strom zu kaufen, als auch
überschüssigen Strom zu verkaufen, während herkömmliche Lieferverträge
nur Lieferungen zum Händler vorsehen.
• Entscheidungsunterstützung: Die Entscheidungsunterstützung versorgt den
Händler mit Informationen zum erwarteten Stromverbrauch für beliebige
Zeiträume, zu aktuellen Versorgungsstörungen, die Lieferverträge betreffen, sowie zu aktuellen Fehldeckungen. Auf dieser Basis werden Empfehlungen zum Abschluss von Lieferangeboten erstellt, die dem Händler erlauben, möglichst optimal seinen Strombedarf zu decken.
• Fahrplanerstellung: Die Fahrpläne werden benötigt, um den Kraftwerksbetreibern zu signalisieren, wann sie dem Händler welche Mengen an Strom
liefern müssen. Dazu wurde ein von der ETSO vorgegebenes XML-Format
(ESS) implementiert, das zum Datenaustausch benutzt wird. So können
Fahrpläne direkt aus dem System heraus generiert werden, so dass sie nur
noch an die entsprechenden Stellen versandt werden müssen.
Die vom EIS angebotenen Funktionen sind also die folgenden (für eine detaillierte Beschreibung siehe auch Kapitel 5):
• Nutzerverwaltung (Anlegen, anzeigen, bearbeiten, löschen)
• Rollenverwaltung (Benutzern Rollen zuweisen und entziehen)
• Kundenverwaltung (Anlegen, anzeigen, bearbeiten, löschen)
• Kundenverträge (Anlegen, anzeigen, bearbeiten, löschen, zuordnen)
• Lastprofile (Anlegen, anzeigen, bearbeiten, löschen, zuordnen)
• Tarife (Anlegen, anzeigen, bearbeiten, löschen, zuordnen, (de)aktivieren)
• Lieferantenverwaltung (Anlegen, anzeigen, bearbeiten, löschen)
• Lieferangebote/-verträge (Anlegen, anzeigen, bearbeiten, löschen, zuordnen, abschließen)
18
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• Bilanzkreise (Anlegen, anzeigen, bearbeiten, löschen, (de)aktivieren)
• Regelzonen (Anlegen, anzeigen, bearbeiten, löschen, (de)aktivieren)
• Störungen (Anlegen, anzeigen, löschen)
• Lastprognosen (Berechnen, speichern, löschen, anzeigen, Plugins einbinden)
• Kaufempfehlungen (Berechnen, umsetzen, speichern, löschen, anzeigen,
Plugins einbinden)
• EEX-Angebote (Anlegen, bearbeiten, löschen, anzeigen, exportieren)
• EEX-Lieferungen (Anlegen, bearbeiten, zuordnen, löschen, anzeigen)
• Fahrpläne (Anlegen, exportieren, anzeigen, löschen)
Wie schon im Zwischenbericht geschrieben, kann das System nicht dazu eingesetzt werden,
• buchhalterische Aufgaben zu erledigen oder automatisieren,
• Stromflüsse innerhalb von Bilanzkreisen zu modellieren,
• mehrere Energiehändler gleichzeitig zu verwalten (nur über mehrere Installationen),
• Lastprofile automatisch zu optimieren (nur manuell) und
• Stromhandel zu automatisieren (wohl aber dazu, ihn durchzuführen).
19
EIS - Energie-Informationssystem
3
Projektgruppe Energie-Informationssyteme
Anforderungen an das Produkt
In diesem Kapitel wird ein Überblick über die Anforderungen gegeben, die während der Implementierung an das Programm gestellt wurden. Sie unterscheiden
sich in geringem Maße von den in der ursprünglichen Anforderungsdefinition
(siehe Kapitel 3 des Zwischenberichts) festgehaltenen Anforderungen, da sich
während des weiteren Entwurfs- und Entwicklungsprozesses in manchen Fällen Änderungen als sinnvoll oder unvermeidbar herausstellten. Ein Vergleich
zwischen den initialen und den während der Implementierung gültigen Anforderungen steht am Ende dieses Kapitels. Wie die Anforderungen letztendlich
umgesetzt wurden, findet sich in Kapitel 4.
3.1
Aus dem Weltmodell abgeleitete Systemabgrenzung
Das zu implementierende Energieinformationssystem soll in der Lage sein, die
Abläufe im Weltmodell nachzuvollziehen und den Energiehändler, der es einsetzt, in die Lage versetzen, seine Energiekäufe und -verkäufe möglichst effizient
zu tätigen im Hinblick auf Kosten und anfallenden Bedarf seiner Kunden. Darüber hinaus muss das System in der Lage sein, mit wichtigen Instanzen außerhalb des modellierten Weltausschnitts (Energiebörse, Netzbetreiber etc.) zwecks
Datenaustausch zu kommunizieren.
Dazu bedarf es einer Reihe weit verbreiteter Standardfunktionen wie etwa
einer Kundenverwaltung, aber auch neuartiger Leistungsmerkmale wie etwa Mechanismen zum Finden möglichst optimaler Kaufempfehlungen und zur Nutzung
der Beschaffungsmöglichkeiten am liberalisierten Energiemarkt, so dass sich ein
innovatives Gesamtsystem mit echtem Mehrwert gegenüber bisherigen Lösungen ergibt. Ebenfalls sollen Fahrpläne generiert werden können, damit der Energiehändler den betroffenen Übertragungsnetzbetreibern mitteilen kann, wieviel
Energie ihm und damit seinen Kunden zugeleitet werden muss.
Mit dem System soll es möglich sein, Energie direkt bei entsprechenden Anbietern einzukaufen oder An- und Verkäufe über die Energiebörse EEX zu tätigen. Kernstück des Systems ist hierbei die Funktion der Entscheidungsunterstützung für die Berechnung des voraussichtlichen Strombedarfs der Kunden
zu beliebigen Zeitpunkten und für die Empfehlung von Lieferangeboten zum
Kauf. Auf einer Lastprognose aufbauend soll unter Berücksichtigung verschiedener Planungsintervalle sowie weiterer Parameter ein Kaufvorschlag unterbreitet
werden, der dann vom Benutzer entsprechend getätigt oder auch verworfen sowie geändert werden kann. Durch einen steten Abgleich zwischen bestehenden
Verträgen und dem ermittelten Bedarf soll so ein effizienter Handel mit Energie ermöglicht werden. Weiterhin soll das System Störungen, also kurzfristige
Nichterfüllungen von Lieferverträgen, die etwa durch Kraftwerksausfälle entstehen, wahrnehmen und behandeln, indem Kaufvorschläge entsprechend angepasst
werden.
Das System soll darüber hinaus Kunden, Lieferanten, deren Verträge und alle
anderen insbesondere zur Entscheidungsunterstützung nötigen Daten verwalten,
sowie Daten für die Lastprognosen und die Ermittlung des Kaufvorschlags (aktuelle Energiepreise usw.) beschaffen und langfristig ablegen, um eine Basis für
spätere Analysen auf diesen Daten zu bieten.
20
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Insgesamt soll sich das System insbesondere durch Entscheidungsunterstützung, Nutzung neuer Handelsmöglichkeiten am Energiemarkt, integriertes Fahrplanmanagement und Einhaltung aktueller Standards zum Datenaustausch von
anderen Lösungen abheben.
3.2
Funktionale Anforderungen
In Abschnitt 3.1 wurde das Einsatzgebiet des Systems dargestellt. Daraus ergeben sich die im folgenden erläuterten detaillierten Anforderungen an die Funktionalität des Systems. Anhand der vorangegangenen Systemabgrenzung, in der
auch die Funktionen umrissen wurden, lassen sich vier größere Blöcke innerhalb
der zu erstellenden Software identifizieren: Datenbasis, Entscheidungsunterstützung, Energiehandel und Fahrplanmanagement.
3.2.1
Datenhaltung und -zugriff
An die Datenhaltung ergeben sich folgende Anforderungen:
• In der Datenhaltung muss der gesamte modellierte Weltausschnitt repräsentiert werden.
• Sie muss persistent sein. Einmal gespeicherte Daten dürfen nicht verloren
gehen, solange sie nicht explizit gelöscht werden.
• Sie muss übersichtlich und in ihrer Struktur an den Zusammenhängen des
modellierten Weltausschnitts orientiert sein.
• Sie muss sicher sein, das heißt, sie darf nur berechtigte Zugriffe zulassen.
• Sie muss auch bei komplexen Anfragen schnellen Zugriff auf die einzelnen
Datensätze gewährleisten, da mit großen Datenmengen zu rechnen ist.
• Sie muss in der Lage sein, Beziehungen zwischen Objekten aufzustellen
und die Einhaltung der sich so ergebenden Referenzbedingungen zu überwachen.
• Des weiteren muss die Datenhaltung die zu speichernden Daten korrekt,
vollständig, möglichst minimal, lesbar und redundanzfrei darstellen.
Der Zugriff auf die einzelnen Datensätze muss im Normalfall Funktionen zum
Auslesen, Anlegen, Ändern und Löschen umfassen. Beim lesenden Zugriff auf
Daten müssen diese nicht nur aus den persistenten Datenbeständen ausgelesen,
sondern auch derart transformiert werden, dass daraus die von der Software
erwarteten Datentypen resultieren. Umgekehrt müssen die an die Datenhaltung
übergebenen Datentypen vor der Speicherung in eine Form überführt werden,
die von der Datenhaltung aufgenommen werden kann. Vor dem Einfügen oder
Ändern von Datensätzen müssen durch das Programm das korrekte Format
der Daten sowie deren referenzielle Integrität bei Beziehungen untereinander
sichergestellt werden.
21
EIS - Energie-Informationssystem
3.2.2
Projektgruppe Energie-Informationssyteme
Dateneingabe und -austausch
Die Dateneingabe erfolgt in der Regel manuell durch die Benutzer des Systems,
sofern es sich um einzelne Datensätze oder allgemein kleinere Datenmengen handelt. Dazu müssen dem Nutzer geeignete Eingabemöglichkeiten zur Verfügung
gestellt werden. Dies hat durch eine grafische Oberfläche zu geschehen, über die
alle Funktionen, mittels derer ein Nutzer direkt auf den Datenbestand zugreifen
darf, angeboten werden.
Für größere Datenmengen soll das Programm spezielle Schnittstellen bereithalten, die einen direkten Import oder Export von Daten erlaubt. Sofern die
exportierten Dateien mit anderen Akteuren auf dem Energiemarkt ausgetauscht
werden sollen, sind die derzeit aktuellen Insdustriestandards zu beachten und zu
implementieren. Der Import kann vollautomatisch oder durch manuell angeordneten Import aus vorliegenden Quellen geschehen, der Export soll ausschließlich
auf Veranlassung eines Benutzers erfolgen.
Derartige Schnittstellen bieten sich zum Import an für Marktdaten der EEX,
für den Export bei Fahrplänen und EEX-Geschäften. Funktionen zum Datenimport, die automatisch aufgerufen werden, müssen nicht in der grafischen Oberfläche bedienbar sein.
3.2.3
Datenbasis
Die Daten, die als Grundlage für weitere Berechnungen wie Lastprognosen dienen, werden als Stammdaten in der Datenbasis zusammengefasst. Hierzu zählen
Daten zu
• Kunden und -verträgen,
• Lieferanten, Lieferangeboten und -verträgen,
• Regelzonen und Bilanzkreisen
• Tarifen und
• Lastprofilen.
Kunden und ihre Verträge müssen erfasst werden, damit der Energiehändler
weiß, wen er wann mit Strom beliefern muss. Zu den erforderlichen Daten gehören personen- oder firmenbezogene Informationen zum Kunden wie Name,
Anschrift und Bankverbindung, Daten zur Laufzeit des Vertrages, den Stromkosten, dem gewünschten Energiemix und den jeweils zu liefernden Strommengen.
Lieferanten mit ihren Angeboten und abgeschlossenen Verträgen müssen
ebenfalls erfasst werden, da sie die Grundlage der Versorgung des Energiehändlers mit Strom bilden. Zu jedem Lieferanten müssen firmenbezogene Informationen wie Anschrift, Ansprechpartner und Bankverbindung vorliegen. Die Lieferangebote müssen Angaben zu Zeitraum, Strommenge, und -preis enthalten.
Um Kunden- und Lieferverträge zwecks Bilanzierung und Durchführung der
Stromflüsse richtig einordnen zu können, müssen Bilanzkreise und Regelzonen
22
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
zu jedem Angebot und jedem Vertrag erfasst werden. Die von der ETSO erarbeiteten Industriestandards bezüglich dieser beiden Entitäten sind einzuhalten.
Das heißt, dass jeder Bilanzkreis und jede Regelzone über ein Objekt repräsentiert wird, das mindestens einen eindeutigen EIC, einen Eignernamen und eine
Abkürzung des Eigners enthält.
Zwecks Vertragsvereinbarung mit den Kunden benötigt das Energieinformationssystem Möglichkeiten zur Tarifgestaltung. Dazu gehört eine Tarifverwaltung, die es dem Energiehändler erlaubt, Tarife zu erstellen, zu ändern, nach
Kundenwünschen anzupassen und sie einem Kundenvertrag zuzuordnen. Energiemixe sollen dabei berücksichtigt werden, da sie in der Zukunft an Bedeutung
gewinnen dürften.
Um den zeitlich schwankenden Energieverbrauch von Stromkunden wiederzugeben, werden Lastprofile benötigt. Ihre Repräsentation innerhalb der Software muss sich ebenfalls an den gängigen Industriestandards ausrichten, wonach
Verbrauchswerte in 15-minütigen Intervallen angegeben werden.
Für alle hier genannten Entitäten sind Funktionen zum Eingeben, Auslesen,
Bearbeiten und Löschen nötig. Die Zusammenhänge zwischen ihnen müssen sich
in der Datenhaltung wiederfinden.
Zusätzlich hierzu sollen zur besseren Information des jeweiligen Nutzers die
aktuellen Preisdaten von der EEX bezogen werden können. Dazu müssen datumsabhängige Informationen über die verschiedenen Strompreisindizes, die an
der EEX notiert werden, in der Software repräsentiert werden. Diese Daten müssen täglich aktualisiert werden. Folgende Indizes der EEX sind relevant, da sie
das Tagesgeschehen wiedergeben:
• Phelix Day Peak: Preis für Strom zur Deckung von Spitzenlast
• Phelix Day Base: Preis für Strom zur Deckung von Normallast
• Off Peak I: Blockpreis für Lieferung zwischen
• Off Peak II: Blockpreis für Lieferung zwischen
• Night: Blockpreis für Lieferung zwischen 0 und 6 Uhr
• Morning: Blockpreis für Lieferung zwischen 6 und 10 Uhr
• High Noon: Blockpreis für Lieferung zwischen 11 und 14 Uhr
• Afternoon: Blockpreis für Lieferung zwischen 15 und 18 Uhr
• Rush Hour: Blockpreis für Lieferung zwischen 16 und 20 Uhr
• Evening: Blockpreis für Lieferung zwischen 18 und 24 Uhr
• Business: Blockpreis für Lieferung zwischen 8 und 16 Uhr
• Stundenpreise: Individuelle Preisangaben für jede Stunde des Tages
23
EIS - Energie-Informationssystem
3.2.4
Projektgruppe Energie-Informationssyteme
Energiehandel
Unter dem Punkt Energiehandel werden sämtliche Funktionen zum Beschaffen
und – bei Überschuss – Veräußern von Energie zusammengefasst. Hier muss
folgende Funktionalität geboten werden:
• Abschluss von Lieferverträgen mit beliebigen Lieferanten
• Angebote zum Strom(ver)kauf an der EEX erstellen
• Auf Basis von EEX-Angeboten vereinbarte Lieferungen registrieren
Zum Abschluss von Lieferverträgen müssen bereits eingegangene Lieferangebote vom Energiehändler als akzeptiert markiert werden können, wobei sich die
übrigen Daten in der Regel nicht ändern. Es muss aber dennoch möglich sein,
bei Annahme eines Angebots dessen Angaben zu modifizieren, da sich durch
Verhandlungen des Lieferanten mit dem Händler Änderungen ergeben haben
können. Lieferangbote und -verträge sollen eher zur langfristigen Deckung des
Bedarfs des Händlers dienen und dementsprechend längere Laufzeiten (Wochen,
Monate etc.) aufweisen. Es ist nicht nötig, Lastprofile auch für Lieferverträge
zu verwenden, da Lieferungen vom Anfang bis zum Ende eine konstante Menge
festlegen.
Zur Deckung des kurzfristigen Strombedarfs (maximal eine Woche) sollen
die durch die Liberalisierung des Energiemarktes neu geschaffenen Handelsmöglichkeiten an der Europäischen Energiebörse in Leipzig genutzt werden können.
Das Programm muss daher in der Lage sein, EEX-Angebote vorzulegen, die
dem Standardformat der EEX entsprechen. Es gibt hier im wesentlichen zwei
Angebotsarten, die zur kurzfristigen Bedarfsdeckung infrage kommen. Dies sind
Stunden- und Blockangebote. Zumindest diese Angebotstypen müssen vom Nutzer im Programm erstellt, bearbeitet und gelöscht werden können.
Die auf Basis dieser EEX-Angebote entstandenen Lieferungen müssen ebenfalls ins System eingepflegt und verwaltet werden können. Dazu gehören für jede
EEX-Lieferungen mindestens der Lieferzeitraum, die konstante Liefermenge, der
Preis, das zugrunde liegende EEX-Angebot und zwecks Bilanzierung Regelzone
und Bilanzkreis des Lieferanten.
3.2.5
Entscheidungsunterstützung
Die Entscheidungsunterstützung enthält im wesentlichen die Funktionen zur
Lastprognose und zur Kaufempfehlung. Hinzu kommen Daten zu Störungen in
der Belieferung des Händlers mit Energie, wenn beispielsweise ein Kraftwerk
heruntergefahren werden musste. Derartige Störungen müssen einzelnen Lieferverträgen zugeordnet werden können. Dies dient dem Zweck, dass perspektivisch Fehlleistungen der anderen Vertragspartei protokolliert werden sollen, um
Konventionalstrafen einzufordern. Außerdem müssen Störungen aus Gründen
der Planbarkeit des Energiebedarfs mindestens Angaben darüber enthalten, wie
groß der Leistungsausfall ist und ob sie derzeit aktuell sind. Ebenso sollte die
Möglichkeit bestehen, eine Nachricht und einen händlerinternen Code hinzuzufügen, um die Störungen besser einordnen zu können.
24
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Lastprognosen Die Lastprognosen stellen die Basis für die Kaufentscheidung,
mit denen der Strom für bestimmte Zeiträume eingekauft werden kann. Für die
Bestimmung der Lastdaten werden als Grundlage Lastprofile für die Kunden
verwendet, mit denen eine Prognose für spätere Kaufentscheidungen getroffen
werden. Die Zeiträume, in denen Prognosen erstellt werden, erstrecken sich mindestens über
• ein langfristiges (Jahr),
• ein mittelfristiges (Quartal) und
• ein kurzfristiges Intervall (Tag).
Diese Prognosen sollen auch für Monats- und Wochenfrist erstellt werden können, jedoch sind diese Möglichkeiten optional. Um eine weitaus bessere Prognose
zu erstellen, werden weitere Parameter wie z. B. Wetterdaten oder Lastspitzen
bei Großereignissen berücksichtigt. Eine wichtige Anforderung ist die Anpassbarkeit der Parameter und Algorithmen zur Prognoseerstellung an die Bedürfnisse des jeweiligen Energiehändlers.
Aus Gründen der Kompatibilität zu den Lastprofilen der Kundenverträge
sollen die auf den darin gespeicherten Daten aufbauenden Lastprognosen ebenfalls Zeitschemata enthalten, die in 15-minütige Zeitintervalle aufgegliedert sind
und den jeweils erwarteten Verbrauch wiedergeben. Des Weiteren muss zu jeder
Lastprognose ihr Gültigkeitszeitraum erfasst werden. Die Erstellung von Lastprognosen muss wegen der zu erwarteten sehr großen Zahl an Kundenverträgen
nach Eingabe aller benötigten Parameter vollautomatisch erfolgen.
Kaufempfehlungen Das Entscheidungsunterstützungssystem soll mit Hilfe
von Verbrauchsprognosen, bestehenden Verträgen, EEX-Lieferungen und Lieferangeboten Kaufvorschläge generieren. Dazu muss zunächst ein Abgleich zwischen zugesicherten Lieferungen und dem pronostizierten Verbrauch stattfinden, um den Fehlbedarf zu ermitteln. Störungen müssen bei der Fehldeckungsermittlung ebenfalls einbezogen werden. Dann müssen aus den vorhandenen
Lieferangeboten die passendsten für einen Kaufvorschlag herausgesucht werden.
Hierbei sollen sowohl langfristige als auch kurzfristige Angebote betrachtet und
vorgeschlagen werden, um dem Benutzer einen effizienten Handel mit Energie
zu ermöglichen. Langfristige Verträge sind dabei zu bevorteilen, da sie größere
Verlässlichkeit und meistens Kostenvorteile bieten. Vorgesehen ist wie bei der
Lastprognose die Erstellung von Kaufempfehlung mindestens für die lange, die
mittlere und die kurze Frist. Als standardmäßige Gütekriterien sind mindestens
die Genauigkeit der Deckung des Fehlbedarfs durch den Kaufvorschlag und die
Höhe der Kosten zu berücksichtigen.
Als optionale Erweiterung ist eine weitere Optimierung der Kaufvorschläge angedacht. Hierbei können zusätzliche Parameter, wie zum Beispiel Kundenfluktuation, frühzeitig mit in die Betrachtung einbezogen werden, um eine
bessere Nutzung von Langzeitverträgen zu erreichen. Weiterhin kann mit Hilfe von Schwellenwerten für Über- bzw. Unterdeckungen die Kaufentscheidung
verfeinert werden.
25
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 2: Aufbau der Entscheidungsunterstützung
Wie bei Lastprognosen sollen Kaufempfehlungen in hohem Maße flexibel, d.
h. an die Bedürfnisse des Energiehändlers und seine bevorzugten Gütekriterien
anpassbar sein. Die Erstellung von Kaufempfehlungen muss nach Eingabe der
benötigten Parameter vollautomatisch ablaufen. Es soll darüber hinaus möglich
sein, die vorgeschlagenen Angebote auf einen Schlag abzuschließen, wenn die
erstellte Kaufempfehlung den Wünschen des Energiehändlers entspricht. Eine
Übersicht über das gesamte Entscheidungsunterstützungssystem liefert Abbildung 2.
3.2.6
Fahrplanmanagement
Fahrpläne werden von den Übertragungsnetzbetreibern benötigt, damit sie wissen, wieviel Strom sie zu welcher Zeit produzieren und wohin sie ihn leiten
müssen. Seit einigen Jahren ist der Standard für Fahrpläne das XML-basierte
ESS-Format. Fahrpläne werden für jeweils einen Tag erzeugt und enthalten die
nach Bilanzkreisen und Regelzonen aggregierten Lieferungen. Das System muss
also in der Lage sein, alle ÜNBs, über die es Strom zur Versorgung seiner Kunden bezieht, mit EES-konformen Fahrplänen zu versorgen. Die Erstellung dieser
Fahrpläne muss auf Befehl des Nutzers vollautomatisch geschehen, nachdem die
benötigten Parameter eingegeben sind, da eine manuelle Erstellung wegen der
großen zugrunde liegenden Datenmenge jeden vertretbaren Zeitrahmen sprengen würde und überdies sehr fehleranfällig wäre. Eine Nachbereitungsfunktion
ist gemäß den ETSO-Vorgaben insofern einzurichten, als Fahrpläne neu erstellt
und mit höheren Versionsnummern versehen werden können.
26
EIS - Energie-Informationssystem
3.3
Projektgruppe Energie-Informationssyteme
Nicht-funktionale Anforderungen
Neben den gerade geschilderten Anforderungen an die Funktionen ergeben sich
zahlreiche nicht-funktionale Anforderungen.
3.3.1
Benutzbarkeit
Das Softwaresystem muss von einem Nutzer, der mit den Vorgängen der Energiewirtschaft vertraut ist, ohne große Einarbeitungszeit bedient werden können.
Die Hilfestellung, die vom Programm angeboten wird, kann also von entsprechenden fachlichen Kenntnissen der Benutzer ausgehen. Eine Anpassung des
Systems an fachlich unversierte Privatnutzer ist nicht erforderlich.
Da das System für den Einsatz im deutschsprachigen Raum gedacht ist,
soll die Sprache des Programms standardmäßig Deutsch sein, wenngleich die
Möglichkeit zur späteren Übersetzung in andere Sprachen bestehen soll.
Die Oberfläche muss übersichtlich gestaltet und nach den einzelnen Funktionsblöcken gegliedert sein, damit sich Nutzer schnell darin zurecht finden können. Das Design soll daher weitgehend dem üblichen Look & Feel von WindowsProgrammen folgen, jedoch auch eigene Akzente setzen, die es davon leicht abheben, um es unverwechselbar zu machen. Gleichzeitig soll das System insgesamt
optisch ansprechend sein, so dass die Nutzer gerne damit arbeiten.
3.3.2
Zuverlässigkeit
Komplettabstürze des Programms sind zu durch geeignetes Abfangen von Fehlern zu vermeiden; sie sollen zu keinem Zeitpunkt auftreten. Falls Fehler innerhalb des Programms auftreten, sollen diese dem Benutzer kenntlich gemacht
werden, damit er darüber informiert ist, dass das System nicht so gearbeitet hat
wie erwartet. Falsche Benutzereingaben sollen so früh wie möglich abgefangen
werden, so dass gar kein Prozess mit diesen falschen Eingaben gestartet wird
und Fehler gleich im Vorfeld vermieden werden. Sollte es dennoch zu einem Systemabsturz kommen, so dürfen keinesfalls bereits gespeicherte Daten verloren
gehen.
3.3.3
Effizienz
Das Programm muss sofort auf Nutzereingaben reagieren. Einfache Anfragen
wie das Einfügen eines neuen Datensatzes oder das Abfragen einer Liste dürfen
auch bei großen Datenmengen nicht mehr als wenige Sekunden benötigen. Dies
gilt auch für den Fall, dass mehrere Nutzer gleichzeitig mit dem Programm
arbeiten. Sämtliche vom Betriebssystem zur Verfügung gestellten Ressourcen
dürfen voll ausgeschöpft werden.
3.3.4
Leistungsverhalten
Das Programm muss mit kleinen, mittleren und großen Datenbeständen problemlos umgehen können. Ein großer Datenbestand ist in diesem Kontext ein
27
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
solcher, der sämtliche Daten eines durchschnittlichen Energiehändlers oder versorgers, etwa eines Stadtwerks mit einigen zehn- bis hunderttausend Kunden,
enthält.
Die Ergebnisse der Algorithmen zur Entscheidungsunterstützung müssen im
Hinblick auf die vorgegebenen Parameter optimal sein, falls es sich nicht um heuristische Algorithmen handelt. Heuristische Ergebnisse müssen möglichst nah
an den vom Benutzer vorzugebenden Zielwerten liegen. Exakte Ergebnisse sind
auch für die Fahrplanerstellung vonnöten. Hier darf keine Heuristik eingesetzt
werden.
3.3.5
Wartbarkeit/Erweiterbarkeit
Das Energieinformationssystem muss auch nach seiner Fertigstellung leicht zu
modifizieren und zu erweitern sein. Darüber hinaus müssen Wartungsarbeiten,
etwa zum Beheben von Programmfehlern, auch von Menschen, die an der Erstellung des Projekts nicht beteiligt waren, ohne große Einarbeitungszeit vorgenommen werden können. Das Programm muss daher klar strukturiert sein.
Die Abbildung des Weltausschnitts auf die Programmbestandteile muss daher
nachvollziehbar gestaltet sein. Darüber hinaus sollen die einzelnen funktionalen
Blöcke wie Datenzugriff oder grafische Oberfläche klar voneinander getrennt und
über wohldefinierte Schnittstellen miteinander verbunden werden, so dass man
sie durch andere Implementierungen ersetzen kann.
3.3.6
Skalierbarkeit
Die erstellte Software ist als Mehrbenutzersystem auszulegen und muss dementsprechend eine beliebige Anzahl an Nutzern verwalten können. Je nach Hardwareumgebung müssen auch mehrere oder viele Nutzer gleichzeitig mit dem
System arbeiten können, ohne dass sich daraus nennenswerte Geschwindigkeitsbeeinträchtigungen ergeben.
3.3.7
Sicherheit
Die Funktionen des Programms und der Datenbestand müssen vor unerlaubten
Zugriffen geschützt sein. Dies gilt sowohl für Zugriffe von außerhalb über die
Schnittstellen des Programms als auch für Zugriffe von angemeldeten Benutzern,
die Funktionen aufrufen, für die sie keine entsprechenden Rechte haben.
3.3.8
Dokumentation
Die Dokumentation soll durch ein ausführliches Benutzerhandbuch erfolgen, das
sowohl in gedruckter Form vorliegt als auch innerhalb des Programms kontextabhängig aufgerufen werden kann. Zusätzlich soll der Quellcode angemessen
kommentiert und nach Möglichkeit eine HTML- oder ähnliche Dokumentation
davon, wie dies etwa in Java mittels JavaDoc möglich ist, generiert werden.
28
EIS - Energie-Informationssystem
3.4
Projektgruppe Energie-Informationssyteme
Hinzugefügte und entfallene Anforderungen
Als Vergleichsgrundlage dienen an dieser Stelle das dritte und vierte Kapitel
des Zwischenberichts. Komplett weggelassen wurden gegenüber den darin enthaltenen Anforderungen lediglich die Wetterdaten. Dies hat drei Gründe: Der
Aufwand zur Implementierung des ohnehin nur als optional vorgesehenen Leistungsmerkmals wäre durch den enormen Aufwand zur regelmäßigen Beschaffung der benötigten Informationen (Parsen zahlreicher HTML-Seiten; verborgene, fehlende, teils unzuverlässige Quellen) unverhältnismäßig im Vergleich zum
Nutzen gewesen. Ebenso hätte ein kompliziertes Modell zur adäquaten Berücksichtung der Wetterdaten in den Kundenverträgen entwickelt werden müssen,
da Wetterdaten in den vorliegenden Lastprofilen anderer Energieversorger nicht
benutzt werden und somit keine Grundlage existiert, auf der man leicht ein
eigenes System hätte aufbauen können.
Die Bedeutung erneuerbarer Energien wurde stark reduziert. Ihr Anteil an
der insgesamt gelieferten Energie kann zwar noch für jeden Tarif festgelegt
werden, findet aber ansonsten, etwa bei Lieferangeboten, keine Berücksichtigung mehr. Die Berücksichtigung erneuerbarer Energien bei Lieferverträgen und
Kaufempfehlungen könnte ein Ansatzpunkt zur Weiterentwicklung des Systems
sein.
Störungen wurden insoweit reduziert, als sie nicht mehr direkt in einen Liefervertrag integriert werden, sondern nur noch bei der Berechnung von Lastprognosen zum Einsatz kommen.
In vielen weiteren Fällen wurde während der Entwicklung in Details von den
ursprünglichen Anforderungen abgewichen, wie bei einem Vergleich zwischen
den in diesem Kapitel aufgeführten Anforderungen und der Anforderungsdefinition aus dem Zwischenbericht zu sehen ist, weil zwischenzeitlich gefundene
Anforderungen und Lösungen sich als besser oder realistischer herausstellten.
29
EIS - Energie-Informationssystem
4
Projektgruppe Energie-Informationssyteme
Umsetzung der Anforderungen
Dieses Kapitel beschreibt, welche Technologien, welche Konzepte und welche Architektur zur Umsetzung der Anforderungen eingesetzt wurden. Außerdem wird
ein Überblick über den zeitlichen Ablauf der Implementierungsarbeiten gegeben.
Im anschließenden Kapitel werden die Details der implementierten Funktionen
erläutert.
4.1
Technologien
Dieses Kapitel bietet einen Überblick über die Technologien, die im Vorfeld des
Projekts zur Verfügung standen. Außerdem wird erläutert, für welche dieser
Technologien wir uns entschieden haben und warum. Zum besseren Verständnis
der folgenden Diskussion sei erwähnt, dass die Projektgruppe eine Client-ServerArchitektur für ihre Software wählte, was in Abschnitt 4.3 näher ausgeführt
wird.
4.1.1
Programmiersprache
Aufgrund der Größe des Projekts und weil das Programm möglichst in vielen Betrieben eingesetzt werden können sollte, wollte die Projektgruppe eine
erprobte, leicht zu nutzende und kompatible Programmiersprache nutzen. Zunächst wurde dazu Java ins Spiel gebracht, da alle Projektgruppenmitglieder
diese Sprache kannten und bereits eingesetzt hatten. Auch ist Java weitestgehend plattformunabhängig und bietet eine ausgereifte Unterstützung für viele
andere Aspekte, die sich sehr früh als relevant erwiesen, wie Datenbankzugriff
oder XML-Verarbeitung. Spätestens aber, nachdem beschlossen war, eine ClientServer-Architektur mit Kommunikation über Webservices zu implementieren,
wurde Java als Programiersprache nicht weiter verfolgt, da einige Projektgruppenteilnehmer mit Webservices in Verbindung mit Java-Programmen schlechte
Erfahrungen gemacht hatten. Diese bezogen sich im wesentlichen auf Probleme
mit persistenter Speicherung von Objekten und Beziehungen zwischen diesen in
einer MySQL-Datenbank unter J2EE und dem Java Enterprise Application Server. Für den Einsatz einer Client-Server-Architektur unter Java wird aber ein
solcher Applicationserver benötigt, daher hätten hier zunächst noch einige Recherchen angestellt werden müssen und es wäre mit weitergehenden Problemen
zu rechnen gewesen. Darüber hinaus wurde die geringe Ausführungsgeschwindigkeit von Java-Programmen bemängelt. Da außerdem eine eigenständige grafische
Oberfläche implementiert werden sollte, kam verschärfend hinzu, dass selbst bei
komplexen Entwicklungsumgebungen wie Eclipse oder netbeans aus Sicht der
Teilnehmer bislang nur unzureichende Unterstützung bei der Erstellung grafischer Oberflächen (GUI) geboten wird.
Nachdem sich die Meinung gegen Java wandte, wurde C# in Verbindung
mit dem .NET-Framework von Microsoft vorgeschlagen. Die meisten Teilnehmer hatten hiermit zwar keinerlei Erfahrungen, jedoch ähnelt diese Sprache
Java sehr stark und ist daher leicht zu erlernen, wenn man Java einigermaßen
beherrscht. Die Laufzeitprobleme von Java, die durch das Interpretieren des
Bytecodes zur Laufzeit entstehen, fallen in C# nicht an, da .NET-Programme
30
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
bei Programmstart in nativen Maschinencode übersetzt und ausgeführt werden
kann. Darüber hinaus gibt es mit Visual Studio 2005 eine Entwicklungsumgebung, die einfaches GUI-Design erlaubt und auch die Erstellung von Webservices
sowie das Projektmanagement weitgehend automatisiert. Die Gruppe entschied
sich also für C# als Programmiersprache.
4.1.2
Datenhaltung
Von Anfang an war im Hinblick auf die in Abschnitt 3.2.1 gestellten Anforderungen deutlich geworden, dass nur ein Datenbanksystem für die Datenhaltung
infrage kommen würde, weil die zu erwartenden Datenmengen – es handelt sich
bei dem Programm schließlich um eine Lösung für größere Unternehmen und
viele Benutzer – mit anderen Datenhaltungsmethoden, etwa einer Dateistruktur, die überdies noch aufwändig hätte konzipiert werden müssen, nur äußerst
ineffizient zu handhaben sind.
Die Entscheidung fiel auf den Microsoft SQL Server 2005. Dies geschah
vor dem Hintergrund, dass zuvor bereits beschlossen worden war, das .NETFramework von Microsoft zu benutzen. Daher bot es sich an, auch bei der Datenhaltung auf ein Microsoft-Produkt zurückzugreifen, weil die Kompatibilität
zu den anderen .NET-Technologien am größten ist. Zudem existiert über die Microsoft Enterprise Library eine mächtige Bibliothek, die viele Aufgaben in der
Kommunikation mit der Datenbank, etwa das Auslesen großer Datenmengen
effizient handhabt und/oder vereinfacht.
MySQL wäre noch am ehesten eine Alternative zu SQL Server 2005 gewesen,
zumal es frei verfügbar ist. Auch können viele Projektgruppenmitglieder Erfahrungen im Umgang mit MySQL vorweisen. Allerdings wäre die Unterstützung
dieser Datenbank durch die .NET-Technologien nicht sehr groß gewesen, und gerade bei großen Datenmengen werden MySQL starke Geschwindigkeitsnachteile
zugeschrieben.
4.1.3
Grafische Oberfläche
Innerhalb des Energieinformationssystems treten zwei Arten grafischer Oberflächen auf: Eine eigenständige, statische GUI, in der das von der Projektgruppe
ausgelieferte Programm abläuft sowie eine HTML-basierte Oberfläche für die
Plugins (siehe Abschnitt 4.2.1), die von den Programmierern der Plugins zu
verfassen ist. Die im weiteren erläuterten Designentscheidungen wurden insbesondere vor dem Hintergrund getroffen, dass leichte Bedienbarkeit, Überschaubarkeit und ansprechende Optik wesentliche Anforderungen an die GUI darstellen.
Eigenständige GUI Die grafische Oberfläche, über die das Programm gesteuert wird, greift wiederum auf drei verschiedene Bibliotheken von drei verschiedenen Anbietern zurück, die im folgenden vorgestellt werden.
31
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Windows.Forms Die Bibliothek Windows.Forms von Microsoft ist Teil
des .NET-Frameworks und beinhaltet zahlreiche Standardelemente zur Erstellung einer GUI, etwa Eingabefelder für Text, Schaltflächen oder Menüleisten.
Es lag am nächsten, sich für den Einsatz dieser Bibliothek zu entscheiden, da sie
durch ihre Integration in das Framework und die Unterstützung durch den Oberflächeneditor von Visual Studio 2005 einfach zu benutzen und darüber hinaus
durch den Einsatz in zahlreichen Applikationen bereits vielfach erprobt ist, was
eine hohe Ausgereiftheit versprach. Überdies versprach sich die Projektgruppe
durch die Benutzung von Windows-Standardkomponenten eine hohe intuitive
Benutzbarkeit, weil jeder, der weitverbreitete Programme wie Microsoft Word
bedient, mit ihnen vertraut ist. Windows Forms bieten außerdem vielfältige Validierungsmöglichkeiten für Benutzereingaben, indem reguläre Ausdrücke benutzt
oder bestimmte Datentypen zum Abgleich mit den Eingaben herangezogen werden, und erleichtern damit die Arbeit nicht unerheblich.
ZedGraph Allerdings konnten mit Windows.Forms nicht alle Anforderungen der Projektgruppe im Hinblick auf ihre grafische Oberfläche abgedeckt werden. So fehlte es beispielsweise an Komponenten zum Erstellen von Diagrammen. Hier wurde nach intensiver Recherche die als Open Source frei verfügbare
Bibliothek ZedGraph [Zed] gefunden, die eingesetzt wird, um die aktuelle Fehldeckung sowie die Anteile der verschiedenen Tarife an allen Kundenverträgen
zu illustrieren.
Die eingesetzten Diagramme waren nötig, um teilweise komplexe Sachverhalte auf einen Blick zu verdeutlichen. An geeigneten Stellen (Fehldeckungsübersicht, Tarifnutzung) wurden Diagramme bewusst eingesetzt, um die Aufmerksamkeit des Nutzers nicht unnötig zu strapazieren und um ihm die Arbeit bei
der Erfassung und Einschätzung von Sachverhalten zu erleichtern.
Fireball Darüber hinaus war mit den Standardkomponenten von Windows.Forms keine den Vorstellungen der Projektgruppe gerecht werdende Navigationsleiste machbar. Zusätzlich zu der Menüleiste am oberen Bildschirmrand
sollte eine Navigation am linken Bildschirmrand eingeblendet werden, die zu jedem Menüpunkt umfangreiche Zusatzinformationen einblenden konnte. Hierzu
benutzte die Projektgruppe die ebenfalls frei verfügbare Bibliothek FireFX in
der Version Beta 2 [Fir].
Diese Bibliothek ermöglichte eine eingängige Navigation im Stile von Microsoft Outlook abzubilden. Der Projektgruppe war es in diesem Zusammenhang
besonders wichtig, auf bestehende, bewährte Konzepte zu setzen. Das aufgabenorientierte Layout von Outlook machte es dabei besonders leicht, Informationen
kategorisiert zu präsentieren.
HTML-Oberfläche Um die spätere Erweiterung und die Anbindung von externen Anbietern zu erleichtern, wurde in die Software eine Plugin-Schnittstelle
implementiert (siehe Abschnitt 4.2.1). Die Schnittstelle ermöglicht das einfache
Hinzufügen von Algorithmen für die Lastprognose sowie für die Kaufempfehlung. Durch das Pluginsystem wird große Flexibilität erreicht.
32
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Für die Umsetzung dieses Systems wurde hauptsächlich auf die umfangreichen Möglichkeiten des .NET-Frameworks im Bezug auf Metadaten zurückgegriffen. Mittels der in .NET integrierten Reflection-API ist es möglich, Informationen über Objekte zur Laufzeit auszulesen und Objekte und Methoden
dynamisch zu laden und auszuführen. Diese Technologie ermöglichte es, mit
vergleichsweise geringem Aufwand ein solches Pluginsystem in unsere Software
zu integrieren. Die Einzelheiten der Umsetzung sowie Informationen für die Entwicklung eigener Plugins für das EIS-System sind in Kapitel 4.2.1 beschrieben.
Aus der Tatsache, dass über das Pluginsystem beliebige Algorithmen ins
Programm eingebunden werden können, und weil eine Client-Server-Architektur
eingesetzt wurde, ergaben sich zwei neue Anforderungen, die zu Beginn der
Implementierung nicht feststanden:
Das Pluginsystem muss überaus flexibel im Hinblick auf Art und Anzahl der
Parameter der Algorithmen sein muss. Ein Beispiel: Algorithmus A benötigt drei
Parameter vom Typ double, während Algorithmus B nur einen Parameter vom
Typ bool für die Ausführung benötigt. Weil diese Parameter vom Benutzer vor
der Ausführung festgelegt werden müssen, ist die Entwicklung einer geeigneten
Schnittstelle sowie einer geeigneten Oberfläche für die Eingabe durch den Nutzer
erforderlich.
Außerdem müssen die oft aufwändigen Algorithmen serverseitig ausgeführt
werden, um die Ressourcen des Servers zu nutzen und eine vereinfachtes Deployment zu erreichen. Diese beiden Anforderungen stellten ein Problem da, weil es
somit notwendig wurde, eine Oberfläche zur Eingabe der Parameter vom Server
an den Client zu senden.
Ein erster Ansatz, das Serialisieren von Windows-Forms mit den Mitteln
des .NET-Frameworks, schlug leider fehl, da es grundsätzlich nicht vorgesehen
ist, Formulare oder Steuerelemente zu serialisieren. Für diese Problemstellung
gibt es folgende Lösungsmöglichkeiten, die im Folgenden kurz auf ihre Vor- und
Nachteile untersucht werden sollen:
• Generische Oberfläche: Eine einfache Möglichkeit zur Lösung des Problems hätte darin bestanden, eine generische Oberfläche zu entwerfen, die
eine beliebige Anzahl an Parameter z. B. in einer Tabellenstruktur anzeigt und die Eingabe durch den Nutzer ermöglicht. Diese ließe sich etwa
in einem eigenen Formular unterbringen. Obwohl und auch auch gerade
weil diese Möglichkeit sehr einfach umzusetzen war, wurde diese Methode
nicht benutzt, da sie von der Gruppe als zu unflexibel eingestuft wurde.
Weil es sich bei den Algorithmen um komplexe Berechnungen handelt,
sind oftmals Hilfetexte oder auch grafische Illustrationen vonnöten, um
dem Nutzer bei seinen Eingaben zu unterstützen. Dies wäre mit dieser
Methode nicht realisierbar gewesen.
• Framework für die Serialisierung von Windows-Forms: Da das .NETFramework keine Serialisierung von Steuerelementen und Formularen unterstützt, wurde intensiv nach Frameworks und Open-Source-Werkzeugen
gesucht die diese Funktionalität bieten. Jedoch blieb die Suche erfolglos, so
dass nur die Möglichkeit blieb, selbst ein Framework zu entwickeln, welches
die Eigenschaften von Steuerelementen sowie den Aufbau von Formularen
in einem Format wie XML serialisiert, so dass eine Deserialisierung auf
33
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
der Clientseite wieder möglich ist. Diese Alternative wurde ebenfalls abgelehnt, da der Aufwand als zu hoch eingeschätzt wurde und sich die Gruppe
außerdem zu weit von der ursprünglichen Problemstellung entfernt hätten.
• Windows Presentation Foundation: Microsoft entwickelt im Moment ein
neues Framework für die Oberflächengestaltung, genannt Windows Presentation Foundation. Dieses nutzt eine XML-basierte Sprache zur Beschreibung von 2D- sowie 3D-Oberflächen. Obwohl das Framework sehr
mächtig ist und sich damit optisch sehr ansprechende Oberflächen entwickeln lassen, gab es mehrere Punkte die gegen den Einsatz in unserem
Projekt sprachen. Zum einen handelt es sich dabei um Beta-Software,
die nicht für den Produktivbetrieb gedacht ist, und zum anderen würden
durch den Einsatz die Systemanforderungen erhöht, da die Windows Presentation Foundation das .NET-Framework in Version 3 voraussetzt, die
ebenfalls noch nicht erschienen ist.
• Webbasierte Oberfläche: Diese Lösung bietet ein Höchstmaß an Flexibilität und der Entwicklungsaufwand wurde als vertretbar eingestuft. Daher
haben wir diese Methode ausgewählt. Der Ansatz soll im folgenden kurz
erläutert werden, wobei die genaue technische Umsetzung in Kapitel 4.2.1
beschrieben ist.
ASP.NET-basierte Pluginkonfiguration Bei der auf ASP.NET basierten Pluginkonfiguration erstellt der Plugin-Entwickler eine frei definierbare Oberfläche für das von Ihm entwickelte Plugin. Dabei kann er auf alle Funktionen
von ASP.NET wie die Validierungsfunktionen zugreifen und kann Technologien
wie Stylesheets nutzen, um die Pluginoberfläche individuell und ansprechend zu
gestalten. Jede so erstellte Seite muss lediglich einen Knopf mit einem vorgegebenen Namen aufweisen, welcher die Konfiguration abschließt. Diese Webseite
wird bei der Konfiguration automatisch in einen in die Clientanwendung des EIS
integrierten Browser geladen. Mittels DHTML bzw. JavaScript kommunizieren
die Host-Anwendung, also die Windows-Forms-Anwendung, sowie die Webseite
miteinander und tauschen Daten aus. Die genaue technische Umsetzung ist in
Kapitel 4.2.1 nachzulesen.
4.1.4
Datenaustausch
Einer der wichtigsten Anforderungen (vgl. Kapitel 3) bei einer Client-ServerAnwendung ist der effiziente Datenaustausch zwischen beiden Seiten. Hier wurden drei Alternativen begutachtet:
• SOAP-Webservices: Webservices bieten ihre Schnittstellen über XMLDateien an und sind über einen eindeutigen Unified Resource Identifier
zugreifbar. Der Client richtet also eine Anfrage an den Webservice, der
diese an den Server weiterleitet und das Ergebnis des Servers an den
Client zurückgibt. Hierzu dienen spezielle Protokolle wie das vom World
Wide Web Consortium veröffentlichte und frei nutzbare SOAP. Webservices wurden von der Projektgruppe zum Datenaustausch gewählt, weil
sie plattformunabhängig sind und Microsoft Visual Studio sie unterstützt,
34
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
so dass Clients auch für andere Plattformen entwickelt werden können und
der Entwicklungsaufwand reduziert wird. Desweiteren ermöglichen sie die
Interaktion von Programmen, die auf unterschiedlichen Betriebssystemen
laufen und in verschiedenen Programmiersprachen geschrieben sind. Dadurch sind alternative Clients, die ebenfalls auf den EIS-Server zugreifen
wollen, nicht auf C# festgelegt.
• .NET-Remoting: Bei .NET-Remoting handelt es sich um einen RPC2 Mechanismus, der durch das .NET-Framework bereitgestellt wird. Die
Kommunikation erfolgt dabei über so genannte Channels, wobei die verbreitetste Variante die Nutzung eines Binärformats, das über TCP übertragen wird, ist. Das Protokoll ist proprietär und kann nur von anderen
.NET-Anwendungen genutzt werden. Außerdem ist schon ein Nachfolger
dieser Technologie in der Entwicklung, und es kann davon ausgegangen
werden, dass .NET-Remoting in Zukunft in seiner bisherigen Form nicht
weiterentwickelt wird. Daher wurde diese Variante trotz des zu erwartenden Performancevorsprungs gegenüber Webservices nicht eingesetzt.
• .NET Enterprise Services (Com+): Bei den .NET Enterprise Services handelt es sich um Klassen und Funktionen, die den Zugriff auf die COM+Dienste bieten. Die COM-Komponententechnologie ist weit verbreitet und
bietet eine höhere Geschwindigkeit und zusätzliche Funktionen gegenüber
Webservices. Die Nachteile dieser Technologie liegen in der Beschränkung
auf die proprietären Protokolle, die dabei genutzt werden. Es ist daher
nicht plattformübergreifend verfügbar. Zudem ist die Einarbeitungszeit in
die Technologie höher und das Deployment aufwändiger als bei der Nutzung von SOAP-Webservices.
Eine derartige Client-Server-Archtektur mit SOAP-Webservices wurde unter anderem beispielhaft von Microsoft in Adventure Works [Adv], einem Programm
zum Management von Kinos, implementiert und wird auf den Seiten des Microsoft Developer Networks detailliert beschrieben. Diverse Ansätze und Ideen aus
diesem Programm dienten als Anregungen für die Programmierung des Energieinformationssystems.
2 Remote
Procedure Call, Aufruf einer entfernten Methode
35
EIS - Energie-Informationssystem
4.2
Projektgruppe Energie-Informationssyteme
Konzepte
Dieser Abschnitt beschreibt Konzepte, die von der Projektgruppe eingesetzt
wurden, um insbesondere nicht-funktionale Anforderungen zu erfüllen.
4.2.1
Plugins
Eine zentrale Anforderung an das Entscheidungsunterstützungssystem (vgl. Abschnitt 3.2.5) war die möglichst flexible und den Benutzerwünschen entsprechende Gestaltung von Lastprognosen und Kaufempfehlungen. Um dem Endnutzer
des Energieinformationssystems dies zu bieten, entschied sich die Projektgruppe, die zugehörigen Funktionen als Plugin-Systeme zu realisieren. Das bedeutet,
dass das Programm nicht über fest in den übrigen Code eingebettete, vorgegebene Algorithmen verfügt, die dann bei Benutzung einer dieser Funktionen aufgerufen werden, sondern dass Drittanbieter in C# oder anderen Sprachen, die
das .NET-2.0-Framework unterstützen, eigene Berechnungsmethoden erstellen
und über eine vordefinierte Schnittstelle in das System einfügen können. Für
einige Teile der Entwicklung des Pluginsystems erwies sich der Artikel Plugin
Architecture using C# aus dem Internetportal The Code Project, einem Forum
für Entwickler, die Microsoft Visual Studio .NET einsetzen (siehe [Plu03]), als
hilfreich.
Aufbau des Plugin-Systems Im wesentlichen besteht das Plugin-System
aus nur fünf Klassen und Interfaces:
• IPredictionPlugin: In diesem Interface wird die Schnittstelle für Plugins
zum Erstellen von Lastprognosen definiert.
• IRecommendationPlugin: In diesem Interface wird die Schnittstelle für
Plugins zum Erstellen von Kaufempfehlungen definiert.
• PluginHost: Diese Klasse stellt Funktionen bereit, die beiderlei Plugins
erkennen und registrieren können. Sie wird nur intern von der Klasse PluginManager verwendet.
• PluginManager : Diese Klasse stellt Funktionen bereit, die aus dem Webservice aufgerufen werden können und einen Zugriff auf die Plugins erlauben.
• AdditionalParameter : Hierbei handelt es sich um eine Hilfsklasse zum Umgang mit den benutzerdefinierten Parametern eines Plugins.
Die Schnittstellen sind im Projekt DataObjects enthalten, welches bei der Eigenentwicklung eines Plugins referenziert werden muss. Die weiteren Klassen für
die Pluginverwaltung sind im Projekt BusinessLogic zusammengefasst.
Arbeitsweise des Plugin-Systems Wenn das Programm startet, sind zunächst keine Plugins geladen. Verfügbare Plugins werden zur Laufzeit eingebunden, sobald die grafischen Oberflächen zur Erstellung von Lastprognosen oder
Kaufempfehlungen aufgerufen werden. Plugins müssen dabei als vorkompilierte
36
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
DLL-Dateien vorliegen, damit sie erkannt werden können. Diese DLLs müssen
sich im Unterverzeichnis Plugins“ im Verzeichnis des Webservices auf dem Ser”
ver befinden. Sofern ein Plugin eine spezielle Oberfläche zur Konfiguration bereitstellt, muss diese als ASPX-Datei im virtuellen Verzeichnis des Webservices
liegen.
Wenn in der Clientanwendung das Lastprognosemodul aufgerufen wird, wird
eine Anfrage über alle verfügbaren Plugins per Webservice-Aufruf an den Server
geleitet. Dieser ruft intern die Klasse PluginManager auf, welche die verfügbaren Plugins ermittelt. Dabei greift die Klasse PluginManager auf die Hilfsklasse
PluginHost zu und ruft deren statische Methode RegisterPredictionPlugins()
auf. Das Unterverzeichnis Plugins“ der Webanwendung wird dann nach DLLs
”
durchsucht, die unter Rückgriff auf das Paket System.Reflection geladen werden. Dabei wird versucht, die in den unterschiedlichen DLL definierten Typen
zu finden und sie unter Benutzung der Vererbungseigenschaft als IPredictionPlugin-Objekte zu instantiieren. Nicht passende Typen werden dabei ignoriert.
Ein Fehlschlag mit einem Abbruch des Ladevorgangs entsteht dann, wenn zwar
vom Interface abgeleitete Typen gefunden werden, diese aber offenbar nicht die
aktuelle Version der Schnittstelle implementieren (weil beispielsweise Methoden mehr Parameter haben als vorgegeben). War der Ladevorgang erfolgreich,
stehen alle gefundenen Plugins im Array PredictionPlugins zur Verfügung und
können von außen abgerufen werden. Die Plugins stehen so lange zur Verfügung,
bis durch erneuten Aufruf von RegisterPredictionPlugins() eine neue Suche gestartet wird. Die Einbindung von Plugins zur Lastprognose verläuft analog über
die Methode RegisterRecommendationPlugins().
Im Folgenden werden die Abläufe beim Einbinden von Plugins zur Kaufempfehlung zur Laufzeit anhand der betreffenden Codeabschnitte der Methode
RegisterRecommendationPlugins nachgezeichnet.
Zunächst werden mit der folgenden Anweisung die Pfade aller DLL-Dateien
ermittelt, die im Verzeichnis mit dem absoluten Pfad path liegen und im Array
pluginFiles gehalten.
string[] pluginFiles = Directory.GetFiles(path, "*.DLL");
Falls keine DLLs vorhanden sind, wird abgebrochen:
if(pluginFiles.Length == 0) {
recommendationPlugins = null;
return;
Sofern DLLs vorhanden sind, wird innerhalb einer for -Schleife versucht, sie
als Assembly-Objekte zu laden. Dazu wird das Paket System.Reflection benötigt, das das Einbinden von kompiliertem Quellcode zur Laufzeit ermöglicht.
Assembly assembly = null;
try {
assembly = Assembly.LoadFrom(pluginFiles[i]);
} catch(Exception exc) {
throw new FileLoadException("Konnte Datei nicht laden: " +
pluginFiles[i]);
37
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
if(assembly == null)
throw new FileNotFoundException("DLL nicht gefunden");
Zuvor wird außerhalb der Schleife noch eine Liste initialisiert, in die alle
gültigen Plugins aufgenommen werden.
List<IRecommendationPlugin> tmp = new List<IRecommendationPlugin>();
Anschließend wird für jede DLL versucht, alle darin vorhandenen Klassen
als Implementierung des IRecommendationPlugin-Interfaces zu instantiieren.
Ist dies nicht möglich, tritt eine Ausnahme auf, die aber ignoriert wird, weil
in einer DLL beliebige Klassen definiert werden können, die nichts mit den
Plugins zu tun haben müssen. Dasselbe Verhalten tritt ein, wenn eine andere
als die aktuelle Version des Interfaces von der zu ladenden Klasse implementiert
wurde. War die Instantiierung erfolgreich, wird die gefundene Klasse in die Liste
der Plugins zur Kaufempfehlung aufgenommen.
int numTypes = assembly.GetTypes().Length;
for(int j = 0; j < numTypes; ++j) {
Type t = assembly.GetTypes()[j];
try {
IRecommendationPlugin irp =
(IRecommendationPlugin)Activator.CreateInstance(t);
tmp.Add(irp);
} catch(Exception exc) {
}
}
Zum Abschluss wird noch das Attribut RecommendationPlugins aktualisiert,
über das aus anderen Klassen auf die Plugins zugegriffen werden kann.
recommendationPlugins = new IRecommendationPlugin[tmp.Count];
for(int i = 0; i < tmp.Count; ++i) {
recommendationPlugins[i] = tmp[i];
}
Wenn ein Plugin über eine eigene Konfigurationsoberfläche verfügt, wird diese
geladen wenn der Nutzer aus der Windowsoberläche heraus das Plugin startet.
Dabei wird zunächst ein integrierter Webbrowser innerhalb der Windowsanwendung gestartet und die im Plugin angegebene URL aufgerufen. Das Plugin selber
spezifiziert nur den Dateinamen der ASPX-Datei und der restliche Teil der URL
wird dann automatisch ermittelt. Der integrierte Webbrowser basiert auf dem
Internet Explorer 6. Er ist so konfiguriert, dass nur auf die Seiten des Plugins
zugegriffen werden kann und verbietet z.B. Drag und Drop Aktionen aus Sicherheitsgründen. Jede Konfigurationsoberfläche ist verpflichtet, eine Schaltfläche
mit dem Namen cmdStart“ zu implementieren, welcher die Konfiguration ab”
schließt. Nach dem Laden der ASPX-Seite im Browser wird nach diesem Knopf
gesucht und es wird ein Eventhandler registriert, der bei einem Klick durch den
Benutzer eine Funktion innerhalb der PG-EIS-Client-Anwendung auslöst. Diese
Funktion liest dann die Daten nach den im Plugin spezifizierten Parametern
aus. Anschließend ruft die Clientanwendung eine Methode des Webservices auf
und übergibt dabei die eindeutige ID des Plugins, die Werte für die Parameter
und weitere Werte wie z. B. Start- und Enddatum.
38
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Implementierung eines Plugins Das Plugin-System stellt zwei unterschiedliche Schnittstellen für Lastprognosen und Kaufempfehlungen bereit, die ausprogrammiert werden müssen, damit das Plugin-System darauf zugreifen und
das Programm damit sinnvoll arbeiten kann. Beide Schnittstellen verfügen über
einige Attribute zur Beschreibung des jeweiligen Plugins:
• Id : Eine eindeutige ID, die über die Methode Guid.NewGuid() erzeugt
werden kann.
• Name: Der offizielle Name des Plugins.
• Author : Der Verfasser des Algorithmus oder die Firma, die das Plugin
vertreibt.
• Description: Eine Beschreibung der Funktionsweise des Algorithmus.
• Version: Informationen zur Version des Plugins.
• License: Die Lizenzangaben des Plugins.
• ConfigPanel : Wenn das Plugin über eine eigene Konfigurationsoberfläche
verfügen soll, muss diese Eigenschaft den Namen der ASPX-Datei wiedergeben, welche die Konfigurationsoberfläche enthält. Eine ASPX-Datei
ist ein ASP.NET-Dokument, das neben HTML-Code auch .NET-Code und
spezielle Steuerelemente enthalten darf. Durch die Definition einer eigenen
ASPX-Seite kann jedem Plugin eine umfangreiche und attraktive Oberfläche zur Konfiguration hinzugefügt werden.
• ParameterWerte: Diese Eigenschaft wird von außen gesetzt nachdem das
Plugin konfiguriert wurde.
Jedes Plugin verfügt außerdem noch über eine Eigenschaft Parameter, welche
die zusätzlichen Parameter beschreibt die über die Konfigurationsoberfläche vom
Benutzer definiert werden. Hier sieht man ein Beispiel:
public AdditionalParameter[] Parameter {
get {
AdditionalParameter[] parameter = new AdditionalParameter[3];
AdditionalParameter paraPopSize = new AdditionalParameter();
paraPopSize.Attribut = "Value";
paraPopSize.ElementID = "PopulationsTextBox";
AdditionalParameter paraGenSize = new AdditionalParameter();
paraGenSize.Attribut = "Value";
paraGenSize.ElementID = "GenerationsTextBox";
AdditionalParameter paraAbbruch = new AdditionalParameter();
paraAbbruch.Attribut = "Value";
paraAbbruch.ElementID = "AbortTextBox";
parameter[0] = paraPopSize;
parameter[1] = paraGenSize;
parameter[2] = paraAbbruch;
return parameter;
}
}
39
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Jeder Parameter enthält Informationen wie der Wert aus der Konfigurationsoberfläche übernommen werden muss. Die Eigenschaft ElementID liefert einen
Verweis auf das Element, z. B. eine Textbox, und die Eigenschaft Attribut bezeichnet das Attribut, das den Wert, den der Benutzer eingetragen hat, beschreibt.
Für die Überprüfung der Korrektheit der vom Benutzer eingegebenen Werte
ist der Verfasser des Plugins weitgehend selbst verantwortlich. In den mitgelieferten Plugins wurde die Überprüfung mittels der von ASP zur Verfügung
gestellten Validatoren realisiert. Das System macht allerdings zwei Vorgaben,
die vom Verfasser erfüllt werden müssen. Zum einen muss der Button zum Absenden der Eingaben cmdStart heißen. Die zweite Auflage ist ein boolescher
Wert vali, in den das Ergebnis der Validierung eingetragen werden muss. Dieser Wert wird später vom System als Korrektheitsbestätigung der übergebenen
Eingaben abgefragt.
Ist die Implementierung abgeschlossen, müssen die Plugins zu DLL-Dateien
kompiliert und in das Unterverzeichnis Plugins“ kopiert werden, wobei die Kon”
figurationsoberfläche (APSX-Datei) in das Hauptverzeichnis des Webservice kopiert werden muss.
Plugins zur Lastprognose Die wichtigste zu implementierende Methode bei
einem Plugin zur Lastprognose ist predictEnergyConsumption(). In ihr muss der
Programmierer den Algorithmus unterbringen, der zum Erstellen der Lastprognose benötigt wird. Sie wird nach der Konfiguration des Plugins vom Hauptprogramm aufgerufen und bekommt als Parameter ein Start- und ein Enddatum für die Lastprognose übergeben sowie eine Liste mit Kundenverträgen, die
ganz in diesen Zeitraum fallen oder sich mit ihm überschneiden. Als Rückgabe
wird ein Objekt vom Typ EnergyPrediction erwartet, das alle Informationen zur
Lastprognose beinhaltet.
Plugins zur Kaufempfehlung Für ein Plugin zur Kaufempfehlung muss die
Methode recommendSupplierContracts() implementiert werden. Die Methode
übernimmt die Erstellung der Kaufempfehlung und wird vom Hauptprogramm
aufgerufen. Übergeben werden eine Lastprognose (Typ EnergyPrediction), auf
der die Kaufempfehlung aufbaut, indem sie deren Start- und Enddatum sowie die Verbrauchswerte übernimmt, sowie drei Listen mit Lieferangeboten und
-verträgen (Typ SupplierContract). In der ersten befinden sich bereits abgeschlossene Lieferverträge, die sich mit dem Zeitraum der Kaufempfehlung überschneiden, in der zweiten Lieferangebote, die im Resultat der Kaufempfehlung
unbedingt auftauchen müssen, und in der dritten Lieferangebote, bei denen der
Algorithmus der Kaufempfehlung selbständig entscheiden kann, ob er sie zum
Abschluss vorschlägt oder nicht. Die Rückgabe der Methode ist eine Objekt
vom Typ RecommendationReturn welches ein Statuscode enthält der besagt ob
die Methode erfolgreich war. So ist es möglich, Meldungen an den Benutzer zurückzugeben, falls die von ihm angegebenen Daten nicht für die Erstellung einer
sinnvollen Empfehlung ausreichen. Das Objekt RecommendationReturn enthält
eine Kaufempfehlung vom Typ Recommendation falls kein Fehler aufgetreten
ist.
40
EIS - Energie-Informationssystem
4.2.2
Projektgruppe Energie-Informationssyteme
Fehlerbehandlung
Da sich auch bei sorgfältigen Tests nicht sicherstellen lässt, dass alle Systemfunktionen fehlerfrei arbeiten und es immer wieder zu Ausnahmesituationen
kommen kann, ist eine verlässliche und für den Nutzer transparente Fehlerbehandlung äußerst wichtig (vgl. hierzu Abschnitt 3.3.2 bei den nicht-funktionalen
Anforderungen). Auftretende Ausnahmen werden dabei vom Webservice an die
GUI weitergereicht und dort in aussagekräftige Fehlermeldungen an den Benutzer umgesetzt. Desweiteren werden die Fehler vom Webservice und vom
Service Access Layer abhängig von den jeweiligen Konfigurationseinstellungen
protokolliert. Als Voreinstellung wurden die Dateien C:\eis-log-server.txt
und C:\eis-log-client.txt sowie die ausführlichste Protokollierung gewählt.
Die Ursachen für solche Ausnahmen lassen sich im Wesentlichen in die Punkte
Programmfehler und fehlerhafte Benutzereingaben unterteilen; beide werden im
Folgenden vorgestellt.
Programmfehler Zunächst werden Programmfehler betrachtet, also solche,
die im regulären Programmablauf entstehen. Dazu werden drei Phasen des Ablaufs untersucht: Programmstart, laufender Betrieb und Beenden.
Beim Start des Webservice können Ausnahmen bezüglich fehlerhafter Konfigurationsdateien auftreten; diese werden lediglich in den Protokollen vermerkt.
Während des laufenden Betriebs können im Webservice Ausnahmen von der Datenbank bei Verletzung von Integritätsbedingungen und der Geschäftslogik bei
der Zugriffs- und Rechtekontrolle ausgelöst werden. Sofern der Rückgabewert
der jeweiligen Funktion es zulässt, wird die Ausnahme direkt in eine entsprechende Rückgabe umgesetzt. Ansonsten wird die Ausnahme vom Webservice automatisch als SOAP-Fault gekapselt und an den Client weitergereicht. Mögliche
Ausnahmen kennzeichnen einen fehlgeschlagenen Datenbankzugriff, verschiedene Fehler in der Zugriffskontrolle sowie den Hinweis, dass ein gewünschtes Objekt
nicht in der Datenbank gefunden wurde. Beim Herunterfahren des Webservice
können keine Ausnahmen auftreten, da hierbei nicht auf die Datenbank, Bibliotheken oder Konfigurationseinstellungen zugegriffen wird.
Die Kapselung als SOAP-Fault wird vom Service Access Layer durch Analyse der Nachricht (siehe Quellcode auf Seite 42) aufgehoben, die entsprechende
Ausnahme erzeugt und an die grafische Oberfläche geleitet. Da der serverseitig
verwendete Internet Information Server die Fehlermeldung und weitere Daten
zur Fehleranalyse in einem einzigen String zusammenfasst, wird diese Nachricht anhand von Trennzeichen in mehrere Strings aufgeteilt und diese mit
den Namensschemata von Exceptions verglichen. Dabei wird der letzte gefundene Treffer zur weiteren Auswertung mit den für diese Anwendung definierten
Exception-Namen verglichen. Entspricht der Exception-Name einem aus dem
Schema, wird eine entsprechende Exception erzeugt, ansonsten die allgemeine
System.Exception.
Die GUI gibt, abhängig von der aufgerufenen Funktion und der Art der Ausnahme, eine einfache Fehlermeldung aus oder informiert den Nutzer ausführlich
(siehe Abbildung 3) über die aufgetretene Ausnahme und ermöglicht ihm auch,
einen Kommentar einzugeben. Dort kann er beispielsweise beschreiben, welche
Funktion er ausführen möchte oder welche eingegebenen Daten zum Ausnahme
41
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
geführt haben. Der Kommentar wird zusammen mit den Daten der eigentlichen
Ausnahme in den konfigurierten Client-Protokollen gespeichert.
private void extractFromSoapException(SoapException exc) {
Trace.WriteLine(exc.Message);
char[] separator = { ’:’, ’>’ };
string[] splitMessage = exc.Message.Split(separator);
string excType = "";
foreach (string split in splitMessage) {
if (Regex.IsMatch(split,
"^[ ]*PG.EIS.Exceptions.[ A-Za-z]*Exception$") ||
Regex.IsMatch(split,
"^[ ]*System.Data.SqlClient.SqlException$")) {
excType = split;
excType = excType.Trim();
}
}
switch (excType) {
case "PG.EIS.Exceptions.LogOnFailedException":
Trace.WriteLineIf(TraceLevelSwitch.TraceError,
"LogOnFailedException detected by SAL.");
throw new LogOnFailedException();
[...]
}
}
Abbildung 3: Ausführliche Fehlermeldung mit Eingabemöglichkeit
Fehlerhafte Benutzereingaben Die andere Gruppe von Fehlern entsteht
durch Falscheingaben von Benutzern, beispielsweise Daten wie 31.02.2006 oder
42
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
24:45 Uhr. Gerade in Eingabefeldern für Freitext können aber auch gezielt
falsche Daten eingegeben werden, die Schadcode in Form von Datenbankbefehlen enthalten.
Zur Überprüfung der Eingaben wurden verschiedene Methoden eingesetzt.
Sofern es sich um Eingaben handelt, die direkt in vorgegebene Objekte wie
DateTime umgewandelt werden sollen, wird die von Windows.Forms bereitgestellte Funktionaliät Validator eingesetzt. Diesem gibt man über Eigenschaften
vor, welche Formate und Wertebereiche für das jeweilige Feld vor. Verletzt die
Eingabe diese Eigenschaften, wird ein Icon mit Fehlermeldung eingeblendet.
Handelt es sich um Eingaben, für die keine vorgegebenen Prüfungen existieren (z.B. Namen, Telefonnummern oder Email-Adressen), wird auf die selbst
implementierte Klasse CheckUserInput zugegriffen. Wie im Beispiel-Code auf
Seite 43 zu sehen ist, wird zunächst geprüft, ob die Eingabe notwendig ist und,
falls keine Eingabe erfolgte, ein Hinweis auf das leere Feld ausgegeben. Anschließend wird geprüft, ob die Eingabe gegen einen regulären Ausdruck gültig
ist. Dieser Ausdruck beschreibt alle möglichen Zeichenkombinationen, die eine
gültige Emailadresse darstellen. Schlägt die Prüfung fehl, wird ein Hinweis auf
fehlerhafte Zeichen ausgegeben.
public static string CheckEMail(string eMail, bool isMandatory) {
string errorMessage = null;
if (eMail == null || eMail == "") {
if(isMandatory)
errorMessage = DE.ErrorEmptyField;
}
else if (!Regex.IsMatch(eMail, "^[A-Za-z0-9._%-]+
[@][A-Za-z0-9._%-]+.[A-Za-z]{2,4}$")) {
errorMessage = DE.ErrorWrongChar;
}
return errorMessage;
}
Gibt ein Benutzer dagegen gezielt Datenbankbefehle ein, die die Datenbank
manipulieren oder gar löschen sollen, bezeichnet man den Angriff als SQLInjection. Sofern diese Eingaben die Prüfungen passieren, werden sie an den
Server weitergeleitet. Dort werden die Werte aber nicht direkt an die Datenbank übergeben, sondern zunächst in SqlParameter-Objekten gekapselt. Diese
sorgen dafür, dass sämtliche SQL-Befehle, die eventuell in den Werten enthalten
sind, maskiert werden. Durch die Maskierung erkennt der Datenbankserver sie
nicht als Befehl, sondern als Wert und speichert sie statt dessen in der Datenbank.
4.2.3
Transaktionskontrolle
Um Dateninkonsistenzen zu vermeiden, müssen insbesondere schreibende Zugriffe auf den Datenbestand ständig überwacht und bereits erfolgte Änderungen
im Rahmen einer Transaktion bei deren Scheitern wieder rückgängig gemacht
werden können. Diese Transaktionskontrolle dient maßgeblich zur Erfüllung der
43
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Als Hilfsmittel zur Implementierung dieser Transaktionskontrolle wurden
die in der Assembly System.Transactions bereitgestellten Funktionen genutzt.
Insbesondere existiert hier die Klasse TransactionScope, mit der sich Codeblöcke als eine Transaktion zusammenfassen lassen und die darin untergebrachten
Datenänderungen somit als atomare Operation entweder ganz oder gar nicht
ausgeführt werden.
Die Systemebene, auf der die Transaktionskontrolle implementiert wurde, ist
der Service Access Layer, in dem die eigentliche Geschäftslogik auf Serverseite sich befindet. Eine niedrigere Ebene wäre nicht möglich gewesen, da in den
Datenobjekten selbst keine Operationen stattfinden und die Datenzugriffsebene
austauschbar ist. Das heißt, das in der vorgenommenen Implementierung zwar
eine Datenbank eingesetzt wird, aber ein anderes Programmierer-Team genauso
gut zum Beispiel eine dateibasierte Datenhaltung einführen könnte. Wäre die
Transaktionskontrolle in der Datenzugriffsebene realisiert worden, müsste bei
jeder neu geschriebenen Datenhaltung auch die Transaktionskontrolle neu verfasst werden. Damit man sich darum nicht eigens kümmern muss, bleibt nichts
übrig als die Implementierung in der Geschäftslogikebene. Jede höhere Abstraktionsebene befände sich im Webservice oder auf Clientseite und ist nicht für die
Ausführung solcher Algorithmen gedacht.
Die Anwendung des Transaktionsmanagers sei hier anhand eines Beispiels
demonstriert. Die Klasse EnergyProfileManager beinhaltet die Geschäftslogik
für den Umgang mit Lastprofilen, die in Kundenverträgen zum Einsatz kommen.
Die Methode AddNewEnergyProfile speichert ein vom Webservice übergebenes
Lastprofil im System. Der zugehörige Code sieht wie folgt aus:
public static ReturnCode AddNewEnergyProfile(EnergyProfile ep) {
if (ep == null) {
return ReturnCode.NullParameterGiven;
}
using(TransactionScope scope = new TransactionScope()) {
if(EnergyProfileDAL.InsertEnergyProfile(ep)) {
scope.Complete();
return ReturnCode.OK;
} else {
return ReturnCode.Error;
}
}
}
Über die using-Direktive wird der gesamte kritische Code des Schreibzugriffs
einer neuen Transaktion unterworfen. Hinter der Methode InsertEnergyProfile
verbirgt sich sämtlicher Code, der auf die Datenbank zugreift. Falls das Einfügen des Objektes gelingt, wird über den Befehl scope.Complete() die Änderung
im Datenbestand irreversibel gespeichert. Andernfalls wird der Bereich über die
else-Option verlassen, ohne die Transaktion abzuschließen. Das bedeutet, dass
die bis zum Verlassen der using-Direktive durchgeführten Änderungen am Datenbestand verworfen werden.
Bei Lesezugriffen dagegen wird auf eine derartige Transaktionskontrolle verzichtet, weil es dadurch nicht durch inkonsistente Datenbestände kommen kann.
44
EIS - Energie-Informationssystem
4.2.4
Projektgruppe Energie-Informationssyteme
Rollenbasierte Sicherheit
Das Programm stellt verschiedene Rollen für Nutzer des Systems bereit, anhand derer die Zugriffsrechte auf die einzelnen Funktionen kontrolliert werden,
um unbefugte Aktionen zu verhindern, wobei ein Nutzer mehrere Rollen auf sich
vereinen kann. Die Realisierung dieses Sicherheitskonzeptes erfolgte mit Hilfe der
Microsoft Enterprise Library. Sie bietet die Möglichkeit, innerhalb des Webservices, der die Funktionen des Servers nach außen für Clients zugänglich macht,
Zugriffsregeln zu definieren. Das heißt, man weist einer Regel einen Namen zu
und gibt an, welche Rolle oder welche Kombination von Rollen ein Nutzer besitzen muss, um Funktionen des Programms, die nach dieser Regel behandelt
werden, aufrufen zu dürfen.
In Anlehnung an den Entwurf wurden folgende Rollen für Systemnutzer
eingeführt:
• Administrator: Ein Administrator hat als einziger das Recht, Nutzer anzulegen, zu bearbeiten und zu löschen. Darüber hinaus kann er ihnen Rollen
zubilligen oder aberkennen. Allerdings ergibt sich eine bedeutende Abweichung der Administratorenrolle vom Entwurf, da er keine besonderen
Zugriffsrechte auf andere Daten wie etwa Kundenverträge hat, kann sie
also nicht bearbeiten oder löschen. Dies ist der Tatsache geschuldet, dass
ein Administrator nicht notwendigerweise Ahnung von den firmeninternen
Abläufen hat und seine Pflicht oft darauf reduziert ist, das System am
Laufen zu halten, nicht aber, in die Arbeit anderer Nutzer einzugreifen.
• Kundenbetreuer: Kundenbetreuer haben Zugriff auf alle Funktionen, die
Kunden in irgendeiner Weise betreffen. Dazu gehört neben der Verwaltung
des Kundenstammes auch der volle Zugriff auf die Kundenverträge sowie
die Tarife und die Lastprofile, die diesen Verträgen zugeordnet werden.
Außerdem können Kundenbetreuer Bilanzkreise und Regelzonen verwalten. Der Kundenbetreuer übernimmt also im Vergleich zum Entwurf auch
die Rollen des Tarif- und des Lastprofilspezialisten.
• Lieferantenbetreuer: Analog zu den Kundenbetreuern können Lieferantenbetreuer auf alle Funktionen zugreifen, die zur Verwaltung des Lieferantenstammes und seiner Verträge benötigt werden. Ebenso können sie Bilanzkreise und Regelzonen anlegen, bearbeiten und löschen, da diese auch
für Lieferverträge unabdingbar sind. Nur von ihnen können Lastprognosen
und Kaufempfehlungen erstellt werden, da diese für die Entscheidungsunterstützung beim Abschluss neuer Lieferverträge benötigt werden. Es ließe
sich einwenden, dass auch Kundenbetreuer Lastprognosen erstellen können
sollten, weil Kundenverträge deren Grundlage darstellen, jedoch arbeiten
sie mit diesen Prognosen im Gegensatz zu Lieferantenbetreuern nicht weiter. Lieferantenbetreuer besorgen auch die Fahrplanerstellung, damit die
Regelzonenbetreiber der Lieferanten über bevorstehende Transaktionen informiert sind. Auch legen sie Störungsmeldungen an, wenn ein Liefervertrag nicht voll erfüllt wird. Sie vereinen damit neben ihrer ursprünglichen
Rolle auch die des Stromhändlers und des Fahrplanspezialisten auf sich.
Dies ist möglich, da die Erstellung von Fahrplänen vollständig, und die von
Lastprofilen bzw. Kaufempfehlungen fast vollständig automatisiert ist und
praktisch keine Spezialkenntnisse mehr nötig sind.
45
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• EEX-Händler: EEX-Händler haben die Möglichkeit, Block- und Stundenangebote an der EEX abzugeben und zu korrigieren. Dazu steht ihnen
neben den Formularen für die Angebote auch eine Druck- und PDF Exportfunktion zur Verfügung, da die EEX in Leipzig die Angebote per
Fax erwartet. Bestätigte Lieferungen können von ihnen mit allen nötigen
Daten ins System eingespeichert werden.
• Extern: Diese Rolle wird derzeit nicht benutzt, steht aber bereit für zukünftige Erweiterungen des Systems. Es ist angedacht, dass auch externe
Nutzer, etwa Lieferanten, über das Internet Zugriff auf bestimmte Funktionen des Systems erhalten und dazu diese Rolle zugewiesen bekommen.
Jeder Rolle ist auch eine entsprechende Regel zugeordnet, die ihren Inhabern den
Zugriff auf die entsprechenden Funktionen gewährt. Desweiteren existiert eine
Regel, die allgemeinen Zugriff ermöglicht. Diese findet beispielsweise Einsatz auf
dem Startpanel.
Die Regeln mit den zugehörigen Rollen werden in der Konfigurationsdatei des
Webservices hinterlegt (Web.Config). Beim Aufruf einer Methode des Webservices wird dann zunächst überprüft, ob die Anmeldung des Nutzers am System
überhaupt gültig ist. Unangemeldet können keine Systemfunktionen aufgerufen
werden. Ist der Nutzer korrekt angemeldet, wozu u. a. seine IP mit der im System gespeicherten Session-IP übereinstimmen muss, wird überprüft, ob seine
Rollen und die daraus resultiernden Befugnisse für die aufgerufene WebserviceFunktion ausreichen. Dazu wird vor dem eigentlichen Funktionsaufruf eine Hilfsfunktion aufgerufen, die einen String, der den Namen der Regel für die folgende
Methode beinhaltet, anhand der Einträge in der Konfigurationsdatei mit den
Rollen des Nutzers abgleicht. Nur wenn der Nutzer über alle Rollen verfügt, die
die Regel verlangt, wird der Methodenzugriff gestattet. Ansonsten kommt es zu
einer Fehlermeldung, die an die grafische Oberfläche weitergereicht wird und den
Nutzer über den verweigerten Zugriff informiert. Der folgende Codeausschnitt
zeigt als Beispiel den Aufruf einer typischen WebService-Methode.
[WebMethod]
[SoapHeader("SessionHeader", Direction = SoapHeaderDirection.In)]
public ReturnCode DeleteAllSchedules() {
EnsureSessionIsValid();
IstErlaubt("Supplier");
return ScheduleManager.DeleteAllSchedules();
}
In der ersten Zeile wird die Methode als nach außen bereitzustellende Webservice-Methode deklariert. Der folgende Befehl gibt an, dass die Sitzungsdaten
des aktuellen Nutzers übermittelt werden sollen. SoapHeaderDirection.In bestimmt, dass diese Methode vom Client aus aufzurufen ist. Nach dem Eintritt
in die Methode, die ein Objekt vom Typ ReturnCode zurückgibt, wird mit
EnsureSessionIsValid() die Gültigkeit der zuvor übergebenen Sitzungsdaten
überprüft. Hier kommt es bei Ungültigkeit zu einer Exception.
Danach testet die Methode IstErlaubt(), ob die Rechte des Benutzers für
den Zugriff auf DeleteAllSchedules() ausreichen. Hier entsteht ebenfalls eine
46
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Exception, falls dies nicht der Fall ist. Über den übergebenen String Supplier
wird festgelegt, dass diese Methode nur dann aufgerufen werden darf, wenn dem
Nutzer die gleichnamige Rolle aus der Datei Web.Config zugewiesen ist.
4.2.5
Benutzbarkeit/Usability
Schon in einem frühen Stadium der Implementierung hat die Projektgruppe
mittels so genanntem Usability Engineering [SB06] das Layout und Design des
Programms validiert und versucht, es kontinuierlich zu verbessern. Aufgrund
von Zeitmangel musste leider auf eine vollständige und wissenschaftliche Herleitung der Zielgruppen verzichtet werden. Die Projektgruppe hat sich deshalb
eines intuitiven Ansatzes bedient, zumal bei diesem Programm die Zielgruppe
generell relativ leicht zu identifizieren ist. Leider bestand zu keiner Zeit Zugriff
auf die in diesem Zusammenhang identifizierten Personen und so mussten die
Tests mit branchenfremden Personen durchgeführt werden. Jedoch wählte die
Projektgruppe bei diesen Tests bewusst Personen mit unterschiedlichen Fähigkeiten und Kenntnissen am Rechner, um eine möglichst große Abdeckung an
Nutzertypen zu erreichen.
Nachdem im Laufe des zweiten Sprints deutlich wurde, dass eine Standardisierung der Nutzungsoberfläche und eine Überprüfung der Benutzbarkeit nötig
sei, wurde zuerst der so genannte Hände-hoch-Test nach Art des FraunhoferInstitutes [FI] eingeführt. Nach dem Abschluss der Arbeiten an einem Dialog
mußte jeder Entwickler sich folgende Fragen stellen:
1. Kann ich bei Eingabefeldern erkennen, was ich in welchem Format eingeben kann?
2. Ist erkennbar, was thematisch zusammengehört?
3. Ist erkennbar, was Pflichteingaben sind?
4. Welche Aktionen werden mir angeboten?
5. Welche Aktion wird eine Folge- oder Untermaske aufrufen?
6. Wie kann ich die Maske schließen?
7. Wie kann ich in der Maske navigieren?
8. Welche Tab-Folge ist zu erwarten?
Zudem fand ab dem zweiten Sprint jeweils eine Iteration des so genannten Usability Lifecyle (siehe Abb. X) statt, d. h., mit Beendigung jedes Sprints
wurden drei Personen, die außerhalb der Projektgruppe standen, zum Test der
Usability heran gezogen. Auf Basis dieser Testergebnisse wurden dann weitere Entwurfsentscheidungen getroffen (beispielhafte Testergebnisse siehe Fragebögen im Anhang). Ziel dabei war es, sowohl Schwächen als auch Stärken zu
identifizieren und die Schwächen auszubessern, ohne dabei die Stärken zu beeinflussen.
Die Projektgruppe konzentrierte sich dabei darauf, die folgenden Eigenschaften des Programms zu überprüfen. Diese basieren zum Teil auf den DIN-ENISO-Normen 9241, 13407 und 14915 (vgl. hierzu [Usa97], [Usa99] und [Usa03]).
47
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 4: Usability Lifecycle
1. Aufgabenangemessenheit: Alle benötigten Funktionen sind im Programm
enthalten und so gestaltet das sie bei der Erledigung einer Aufgabe unterstützen.
2. Selbstbeschreibungsfähigkeit: Die enthaltenen Funktionen sind selbst deskriptiv und klar ersichtlich.
3. Steuerbarkeit: Das System ist einfach handhabbar und gibt dem Nutzer
die Kontrolle über die Dialoge.
4. Fehlertoleranz: Fehlermeldungen sind deutlich und erklärend.
5. Lernförderlichkeit: Lernstrategien werden durch schrittweisen Anleitungen
oder Anwendungsfälle unterstützt.
6. Joy of use: Arbeitsabläufe sollen durch ansprechende Gestaltung und trotz
notwendiger Konsistenz spannend“ gehalten werden und die Nutzung des
”
Programms interessanter machen.
48
EIS - Energie-Informationssystem
4.3
Projektgruppe Energie-Informationssyteme
Softwarearchitektur
Bei der Softwarearchitektur standen im wesentlichen zwei Möglichkeiten zur
Debatte: Eine monolithische Anwendung, die auf jedem für ihren Gebrauch
vorgesehenen Rechner installiert werden muss, und eine verteilte Client-ServerAnwendung, bei der ein Server zentral installiert wird und die einzelnen Rechner nur die Client-Programe benötigen. Diese Eigenschaft eines Client-ServerSystems eignet sich insbesondere, um den unter dem Punkt Skalierbarkeit subsummierten Anforderungen gerecht zu werden.
Der monolithische Programmblock hätte als Vorteil eine vergleichsweise hohe Effizienz für die einzelnen Nutzeranfragen mit sich gebracht, weil die einzelnen Komponenten eine hohe Verzahnung miteinander aufgewiesen hätten.
Allerdings wäre dieser Ansatz auch sehr problembehaftet gewesen. Die Wartung durch den Anwender wäre erschwert worden, es hätten sich, wenn auch die
Datenbank auf jedem Rechner hätte aufgesetzt werden müssen, Probleme mit
Dateninkonsistenzen ergeben, und ein Austausch von Teilen des Programms wäre kaum möglich gewesen. Gerade der letzte Punkt, die Austauschbarkeit von
Teilen des Programms, war aber auch eine wesentliche nicht-funktionale Anforderung der Projektgruppe (siehe Abschnitt 3.3.5). Dazu gehört etwa, dass
verschiedene Clients angeboten werden können oder dass man den Datenzugriff
über eine andere Datenbank laufen lassen kann. Client-Server-Anwendungen
erzwingen im allgemeinen auch eine klare Strukturierung des Programms und
begünstigen damit einfache Wartung durch die Entwickler. Die Geschwindigkeit
ist zwar durch den Zwang, ständig Daten zwischen Client und Server hin- und
herschicken zu müssen, geringer, jedoch wiegt das nicht die bislang beschriebenen Vorteile auf. Die Projektgruppe entschied sich also für eine mehrschichtige
Client-Server-Architektur.
Die Architektur unseres Systems orientiert sich dabei bis auf wenige Punkte
komplett am Zwischenberichts (vgl. dort Abbildung 4.23). Entfallen sind aus
Zeitgründen beispielhafte Implementierungen von Diensten, die externen Beteiligten zum direkten Zugriff über das Internet bereitgestellt werden sollten.
Hauptwerkzeug zur Erstellung des Projekts war Microsoft Visual Studio 2005,
so dass auch auf die Fähigkeiten von .NET 2.0 zurückgegriffen werden konnte.
Das gesamte Programm wurde als so genannte Lösung (Solution) mit mehreren
Teilprojekten (Projects), die einzelne Ebenen der Architektur umfassen, erstellt.
Diese Ebenen werden im folgenden vorgestellt.
Der in Abbildung 4.23 des Entwurfs zu sehende Simulator wird durch zwei
Programme zum serverseitigen Befüllen der Datenbank mit großen Mengen an
Kunden- und Lieferantendaten sowie einen ausführlichen Webservice-Test (siehe
Abschnitt 6.2) ersetzt.
Abbildung 5 gewährt einen Gesamtüberblick über das implementierte System. Auf Serverseite befinden sich Datenhaltung und Datenzugriff sowie der
Webservice, dessen Funktionen auch dem Client zugänglich sind. Auf Clientseite befinden sich die GUI sowie der Service Access Layer als Vermittler zwischen
GUI und Webservice. Über alle Ebenen erstrecken sich die Datenhaltungsklassen
und die rollenbasierte Sicherheit.
Abbildung 6 zeigt die Projektstruktur des Systems in Visual Studio. Jedes
Rechteck innerhalb der Solution steht für ein Teilprojekt. Eine hellgelbe Ein49
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 5: Architekt des implementierten Energieinformationssystems
Abbildung 6: Struktur der Solution in Microsoft Visual Studio
50
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
färbung bedeutet, dass das jeweilige Projekt serverseitig liegt, hellgrüne Farbe
steht für Projekte auf Clientseite. Die Teilprojekte Webservice und DataObjects
sind anders eingefärbt, weil sie beiden Seiten zur Verfügung stehen.
4.3.1
Datenhaltung
Die Datenhaltungsklassen stellen als unterste Schicht die abstrakten Datentypen bereit, die das Rückgrat des Systems für den Datenaustausch zwischen
den verschiedenen Ebenen bilden. Es wurden zur angemessenen Abbildung des
Weltausschnitts Klassen für Stammdaten (Nutzer, Kunden, Lieferanten sowie
Verträge und Rechte), Entscheidungsunterstützung (Lastprognosen und Kaufempfehlungen), EEX-Handel und Fahrpläne angelegt. Sie stehen dem Server
vollständig zur Verfügung. Der Client hingegen sieht nur diejenigen Klassen, die
als Rückgabewerte von Webservice-Methoden dienen. Zusätzlich zu den Klassen,
die vollständige Entitäten repräsentieren, gibt es auf das für jeweilige Aufgabe
reduzierte Maß Hilfsklassen, die nur die wichtigsten Informationen einer Entität
enthalten. Dies dient dazu, die Datenmengen, die über den Webservice zu übertragen sind, zu reduzieren, da insbesondere bei Anfragen wie Zeige eine Über”
sicht aller Kundenverträge!“ tausende Objekte erzeugt und gesendet werden
müssen. Indem nur die tatsächlich zur Anzeige derartiger Übersichten erforderlichen Daten ausgelesen und übertragen werden – vor allem werden komplexe
Objekthierarchien mit zusätzlichen Zugriffen auf die Datenhaltung vermieden
–, sinkt die zu übertragende Datenmenge und damit die Zugriffszeit, was die
Anforderung bezüglich hoher Geschwindigkeit von Datenhaltung und -zugriff
erfüllen hilft.
4.3.2
Server
Datenzugriff Zur Speicherung der Daten wurde wie geplant der Microsoft
SQL Server 2005 eingesetzt, in dem für jede Entität, d. h. jeden abstrakten
Datentypen, eine eigene, gleichnamige Tabelle erzeugt wurde. Darüber hinaus
waren an mehreren Stellen Verknüpfungstabellen nötig, um m-n-Beziehungen
zu realisieren. Für das Befüllen der Hilfsklassen mit Daten wurden Views eingerichtet, die die benötigten Attribute ohne zusätzliche Datenbankabfragen bereitstellen. Vergleiche hierzu Abbildung 7, die von Microsoft SQL Server 2005
aus den vorhandenen Tabellen und Beziehungen zwischen diesen erzeugt wurde
und das Datenbankschema wiedergibt. Dabei sind die einzelnen Tabellen jeweils
mit ihrem Namen und den als Primär- oder Fremdschlüssel genutzen Attributen
zu sehen. Die Linien zwischen den Tabellen geben Fremdschlüsselbeziehungen
an.
Der Zugriff auf die Daten erfolgt über eine austauschbare Architekturschicht,
im Projekt Data Layer oder Data Access Layer genannt (vgl. Abbildung 4.23
des Zwischenberichts). Sämtlicher Code, der auf die Daten zugreift, ist in dieser
Schicht gekapselt. In der Regel wurden für alle Entitäten die Standardroutinen
zum Einfügen, Bearbeiten, Löschen und Anzeigen bereitgestellt, wie es im Entwurf vorgesehen wurde. Gelegentlich gibt es Ausnahmen, etwa bei Kaufempfehlungen und Lastprognose, wo eine (manuelle) Nachbearbeitung nicht vorgesehen
ist. Zusätzlich wurden bei einigen Objekten weitere Methoden bereitgestellt, die
etwa nur zur Zeit freigegebene Tarife für Kundenverträge ausgeben.
51
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 7: Datenbankschema des Energieinformationssystems
52
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Durch die Kapselung des Datenbankcodes in einer Schicht ist es möglich,
diese Schicht komplett durch eine andere auszutauschen, die beispielsweise mit
einem Dateisystem im Hintergrund arbeitet, ohne die anderen Schichten anpassen zu müssen.
Als weiteres Hilfsmittel kam die Microsoft Enterprise Library zum Einsatz.
Geschäftslogik In der Geschäftslogik werden alle komplizierten Algorithmen
gebündelt und ausgeführt. Dies umfasst:
• Berechnung von Lastprognosen über Plugins
• Berechnung von Kaufempfehlungen über Plugins
• Berechnung von aktuellen Über- und Unterdeckungen
• Erstellung von Fahrplänen
• Überwachung von Transaktionen
Generell ist die Geschäftslogikschicht (in Abbildung 4.23 des Zwischenberichts
als Business Layer bezeichnet) die Schicht, an die der Webservice sämtliche
Anfragen der Clients delegiert, sobald er festgestellt hat, dass der Nutzer diese
Anfrage überhaupt tätigen darf. Anders als noch im Entwurf dargelegt, gibt es
innerhalb der Geschäftslogik keine streng voneinander abgegrenzten Module für
genau je eine Komponente des Systems, sondern vielmehr Manager-Klassen für
alle dem Client zugänglichen Funktionen. Dabei wurde je eine solche ManagerKlasse für eine einzelne oder wenige logisch direkt zusammenhängende Klassen
erstellt.
Reine Datenbankabfragen werden von der Geschäftslogik in der Regel ungefiltert an die darunterliegende Datenzugriffsebene weitergeleitet und ihre Ergebnisse nach erfolgreicher Transaktionsausführung zurückgegeben. Mehr über die
einzelnen Funktionen findet sich in den Abschnitten zu Transaktionskontrolle
(4.2.3), Lastprognosen (5.3.1), Kaufempfehlungen (5.3.3), Fahrplänen (5.4) und
EEX-Handel (5.2).
Webservice Der Webservice dient als Vermittler zwischen Client und Server und übernimmt die Funktion der Fassaden aus dem Zwischenbericht. Benutzt wird das plattformunabhängige SOAP -Protokoll[SOA03] in Verbindung
mit dem Internet Information Server von Microsoft. Zu jeder Methode der Geschäftslogik, auf die der Client zugreifen können soll, existiert eine gleichnamige
Methode im Webservice, die nach außen zur Verfügung gestellt wird.
Berechnungen finden beim Aufruf einer Webservice-Methode nicht statt, da
sämtliche Aufrufe an die Geschäftslogik weitergeleitet und ihre Ergebnisse an
den Client zurückgeschickt werden. Es wird allerdings im Rahmen der rollenbasierten Sicherheit überprüft, ob der aktuelle Nutzer eine gültige Anmeldung am
System sowie die nötigen Rechte zum Aufruf dieser Methode vorweisen kann.
Ist dem nicht so, wird der Aufruf durch Werfen der entsprechenden Exception
abgebrochen.
53
EIS - Energie-Informationssystem
4.3.3
Projektgruppe Energie-Informationssyteme
Client
Service Access Layer Der Service Access Layer ist das Bindeglied zwischen
grafischer Oberfläche und Webservice. Er greift über eine Schnittstelle auf die
vom Webservice bereitgestellten Methoden zu und stellt sie der grafischen Oberfläche bereit. Berechnungen finden in dieser Schicht nicht statt.
Grafische Oberfläche (Client) Die grafische Benutzeroberfläche, auch GUI
abgekürzt, sorgt für die Interaktion des Nutzers mit dem Programm. Die fertige GUI ist dabei ein Zwischenprodukt zwischen Thin und Rich Client, weil
sämtliche komplexen Algorithmen wie etwa zur Berechnung eines Lastprofils
serverseitig durchgeführt werden, einfache Aufgaben wie etwa Datenvalidierung
aber wie im Entwurf angekündigt Aufgabe der GUI-Schicht bleiben. Der Grund
dafür ist, dass bei serverseitiger Validierung ständig Verbindungen über den
Webservice auf- und abgebaut werden müssten und dies mit dem zugehörigen
Datenaustausch eine erhebliche Systembelastung darstellen würde, nur um vergleichsweise simple Berechnungen wie etwa die Überprüfung eines Zahlwertes
auszulagern.
Zur Realisierung wurde im Wesentlichen die Grafikbibliothek Windows.Forms
benutzt. Die Oberfläche ist dabei zweigeteilt in eine Navigationsleiste auf der
linken Seite und wechselnde Datenpanels auf der rechten Seite. Ebenso wurden
Kontextmenüs, die mit der rechten Maustaste geöffnet werden, eingefügt sowie
eine Menüleiste am oberen Rand des Programms, um den Zugriff auf die einzelnen Funktionen möglichst benutzerfreundlich und effizient zu gestalten. Die
Darstellung der Daten erfolgt als Übersicht in der Regel über Tabellen bzw.
bei ihrer Eingabe über sich öffnende Eingabefenster, in denen auch die oben
beschriebenen Validierungsfunktionen aufgerufen werden.
Außerdem wurden an manchen Stellen, z. B. bei der Anzeige der aktuellen
Über- oder Unterdeckung zur Veranschaulichung dynamisch generierte Diagramme eingesetzt, die mit ZedGraph [Zed] erzeugt wurden. Für die Navigationsleiste
wurde die Bibliothek Fireball.Windows.Forms von DotNetFireball [Fir] verwendet. Näheres zu den in der grafischen Oberflächen verwendeten Technologien
findet sich in Abschnitt 4.1.3.
4.4
Ablauf der Implementierung
Die Implementierung begann wenige Tage nach Anfang des Sommersemesters
2006 und dauerte bis Ende September desselben Jahres. Zunächst stand im
Vordergrund, den modellierten Weltausschnitt mit seinen Entitäten und Beziehungen zwischen ihnen (siehe Abbildung 1) in Klassen zu übersetzen, diese
Klassen mit allen benötigten Attributen zu versehen und das so entstandene
Datengerüst in der Datenbank adäquat abzubilden. Zeitgleich wurden die verschiedenen Schichten der Architektur wie in Abschnitt 4.3 beschrieben festgelegt. Um die Kommunikation des Programms mit der Datenbank sicherzustellen,
wurden jetzt die Datenbankzugriffsklassen erstellt und mit Standardfunktionen
zum Auslesen, Anlegen, Bearbeiten und Löschen der jeweiligen Objekte ausgestattet. Obwohl im weiteren Verlauf des Projekts hin und wieder kleinere
54
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Änderungen am Klassengerüst, der Datenbank und dem -zugriff nötig wurden,
erwiesen sich diese Projektteile als gut durchdacht und dementsprechend stabil.
Die weitere Implementierung orientierte sich im wesentlichen an den in Abschnitt 3 identifizierten Funktionsblöcken. Dabei wurden jeweils vertikale Prototypen erstellt, das heißt, eine oder mehrere Funktionen wurden immer komplett
durch alle Ebenen hindurch programmiert. Dieses Vorgehen erwies sich als vorteilhaft, da die jeweiligen Funktionen über die grafische Oberfläche und damit
unter realistischer Benutzerinteraktion getestet werden konnten.
Zunächst wurden die Stammdaten (Kundenverträge, Lieferangebote etc.)
server- und clientseitig ausprogrammiert und mit einer grafischen Oberfläche
versehen. Es folgten darauf aufbauend die Funktionen zur Entscheidungsunterstützung, zum EEX-Handel und zur Fahrplanverwaltung. Bei der Entscheidungsunterstützung traten allerdings insofern Probleme auf, als das zugehörige
Pluginsystem für Lastprognosen und Kaufempfehlungen in der ersten Version seine aufwändigen Berechnungen clientseitig ausführte, was nicht dem Sinn
einer Client-Server-Architektur entspricht. Zeitgleich zur Implementierung der
Handelsfunktionen musste daher das Pluginssystem umgeschrieben werden. Die
Algorithmen mussten dazu allerdings nicht angepasst werden.
Während der Implementierung der einzelnen Funktionsblöcke wurden ständig Fehlerbehandlung und Transaktionskontrolle in die neu erstellten Klassen
eingefügt. Ebenso wurde ständig auf ein einheitliches Aussehen der verschiedenen GUI-Bestandteile geachtet und bei Abweichungen Anpassungen vorgenommen. Die rollenbasierte Sicherheit wurde dagegen erst nach weitgehendem Abschluss der Implementierungsarbeiten hinzugefügt, da dies nur sehr geringfügige
Änderungen des Programmcodes und ausschließlich in der Webservice-Schicht
nach sich zog und somit auf einen Schlag erledigt werden konnte.
Bei der Programmierung der Schnittstellen wurde sehr darauf geachtet, dass
die Anforderungen hinsichtlich der Beachtung von Industriestandards eingehalten wurden. Die Fahrplanschnittstelle wurde so gestaltet, dass die Fahrplandaten in der Datenbank gespeichert und automatisch in eine XML-Datei im ESSFormat exportiert werden. Die EEX-Daten werden über ein separates Programm
erfasst, das in den Taskplaner unter Windows eingebunden werden kann und jeden Tag automatisch neue oder fehlende Daten von den EEX-Webseiten ausliest
und in die Datenbank einfügt. EEX-Angebote werden ins Programm eingegeben und können automatisch in eine Faxvorlage exportiert werden, die von der
EEX zur Abgabe von Angeboten eingesetzt wird. In allen drei Fällen wurden
also die selbst gestellten Anforderungen erfüllt. Über die im Anforderungskapitel genannten Schnittstellen hinaus erwies es sich als nützlich, Importfunktionen
für Regelzonen- und Bilanzkreisdaten anzubieten, da hier ebenfalls recht große
Datenmengen anfallen, die oft aktualisiert werden müssen.
Den letzten Monat verbrachte die Projektgruppe im wesentlichen mit ausführlichen Tests aller Funktionen und Fehlerkorrekturen, da sich bei derartigen
Projekten Fehler auch bei sorgfältiger Programmierung nicht vermeiden lassen.
55
EIS - Energie-Informationssystem
5
Projektgruppe Energie-Informationssyteme
Implementierung der einzelnen Funktionen
Dieses Kapitel gewährt einen überaus detaillierten Überblick über die Implementierung der einzelnen Programmfunktionen. Im Vordergrund steht dabei zu
erklären, wie die Implementierung in den einzelnen Schichten erfolgte und was
die Funktionen genau leisten. Genaue Hinweise zur Bedienung der einzelnen
Funktionen sind im Handbuch (Kapitel 9) zu finden.
5.0.1
ReturnCode-Rückgabewerte
In den folgenden Abschnitten wird bei vielen Funktionen auf Rückgabewerte des
Typs ReturnCode verwiesen, die das Ergebnis oder den Erfolg einer Operation
anzeigen. Es handelt sich dabei um eine Enumeration, die eine überschaubare
Anzahl an Codes enthält, die bestimmte Sachverhalte anzeigen. Dieser Typ wird
insbesondere dann eingesetzt, wenn boolesche Werte zu ungenau sein können.
So reicht es zum Beispiel aus Sicht der Fehlerbehandlung nicht aus, wenn nur
bekannt ist, dass eine Datenbankabfrage fehlgeschlagen ist; vielmehr ist hier eine
möglichst genaue Angabe des Grundes wichtig.
An dieser Stelle wird eine Übersicht über die in der Enumeration vorhandenen Werte und ihre Bedeutung geboten.
• None: Wird zum Initialisieren genutzt und solange noch kein genauerer
Wert ermittelt wurde.
• OK: Bestätigt den Erfolg einer Operation.
• DBFailure: Gibt an, dass eine Operation aufgrund einer falschen oder
unzulässigen Datenbankanfrage nicht vollführt werden konnte.
• Error: Gibt an, dass während einer Operation ein Fehler aufgetreten ist,
der ein erfolgreiches Beenden verhindert.
• NotFound: Zeigt an, dass ein gesuchtes Objekt nicht gefunden wurde.
• NullParameterGiven: Weist auf mindestens einen zum Durchführen einer
Operation fehlenden Parameterwert hin.
• IsUsed: Zeigt an, dass ein gespeichertes Objekt noch durch andere gespeicherte Objekte referenziert wird, so dass eine Löschung damit ausgeschlossen ist.
• IsCurrentlyServed: Gibt an, dass ein Vertrag momentan läuft und deswegen nicht gelöscht werden darf.
• Yes: Wird teilweise wie OK eingesetzt, teilweise als Antwort auf Anfragen,
ob ein Objekt eine bestimmte Eigenschaft besitzt.
• No: Verneint, dass ein Objekt eine bestimmte Eigentschaft besitzt.
• HasDisturbances: Wird eingesetzt, wenn ein Liefervertrag wegen noch bestehender Störungen nicht gelöscht werden darf.
56
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• NoSupplierContract: Wird benutzt, wenn eine Kaufempfehlung keine Lieferangebote enthält.
• CalculationFailed: Zeigt an, dass eine numerische Berechnung fehlgeschlagen ist.
• IsLastAdmin: Gibt an, dass ein Nutzer nicht gelöscht werden darf, weil er
der letzte Administrator ist.
5.1
5.1.1
Stammdaten
Systemnutzer
Allgemeines Die Systemnutzer sind die Benutzer des Programms die die
Funktionen des Energieinformationssystems nutzen. Dabei ist es nötig, die verschiedenen Funktionen auch nur denen zur Verfügung zu stellen, die zur Benutzung dieser authorisiert sind. Die Benutzerverwaltung stellt dies sicher und
macht es möglich, einem Benutzer eine oder mehrere dynamisch konfigurierbare
Rollen zuzuordnen. Rollen ermöglichen es, die Rechte zur Benutzung des Programms einzuschränken. Genaueres über das Rollenkonzept kann in Abschnitt
4.2.4 nachgelesen werden.
Die Verwaltung der Systemnutzer deckt die im Entwurf beschriebenen Anwendungsfälle 1 bis 6 ab. Zusätzlich werden An- und Abmeldung realisiert.
Abbildung 8: Klassen EisUser, Person und EisUserRole
Nutzer mit ihren Daten werden von der Klasse EisUser repräsentiert, die
von der allgemeineren Klasse Person abgeleitet ist. Die zugehörigen Benutzerrollen werden in der Klasse EisUserRole gespeichert, die als Array in jedem
Nutzerobjekt gehalten werden (siehe Abbildung 8).
Systemnutzer im Datenzugriff Nutzer werden in der Datenbanktabelle
EisUser gespeichert, die die Attribute der gleichnamigen Klasse abbildet. Die
verschiedenen vom System angebotenen Benutzerrollen liegen in der Tabelle
Role und werden über die Tabelle EisUserRole mit den einzelnen Nutzern verknüpft.
In der Klasse EisUserDAL (siehe 9) wird der Datenzugriff auf Benutzer und
ihre Rechte folgendermaßen gewährleistet:
57
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 9: Klasse EisUserDAL
• DeleteEisUser : Identifiziert einen Systembenutzer über ein GUID-Objekt,
löscht diesen aus der Datenbank und zeigt über einen ReturnCode den
Erfolg der Aktion an.
• GetAllEisUsers: Liefert alle in der Datenbank gespeicherten Systemnutzer
zurück.
• GetEisUser : Identifiziert einen Systembenutzer über ein Guid-Objekt in
der Datenbank und liefert das entsprechende EisUser-Objekt zurück
• GetEisUser : Identifiziert einen Systembenutzer über ein string-Objekt,
das das eindeutigen Login enthält, in der Datenbank und liefert das entsprechende EisUser-Objekt zurück.
• GetUsersByFirstname: Identifiziert einen Systembenutzer über ein stringObjekt in der Datenbank anhand seines Vornamens und liefert die entsprechenden EisUser-Objekte zurück.
• GetUsersByLastname: Identifiziert einen Systembenutzer über ein stringObjekt in der Datenbank anhand des Nachnamens und liefert die entsprechenden EisUser-Objekte zurück.
• GetUsersByLogin: Funktioniert wie GetEisUser(string s).
• GetUsersByRole: Identifiziert einen Systembenutzer über ein string-Objekt,
das einen Rollennamen angibt, in der Datenbank und liefert eine Liste mit
allen Nutzern zurück, die diese Rolle innehaben.
• GetUsersOnline: Liefert alle in der Datenbank als eingeloggt gekennzeichneten Systemnutzer in Form einer Liste zurück.
58
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• InsertEisUser : Speichert das übergebene EisUser-Objekt in der Datenbank und gibt den Erfolg der Operation über ein ReturnCode-Objekt zurück.
• UpdateEisUser : Speichert das übergebene, geänderte EisUser-Objekt in
der Datenbank und liefert das Ergebnis der Operation über ein ReturnCodeObjekt zurück.
• IsUserUsed : Überprüft ob der durch das übergebene eindeutige ID in Form
einer GUID) repräsentierte Systemnutzer durch Referenzen auf andere Datensätze von einer Löschung ausgeschlossen ist, weil sonst die referenzielle
Integrität verloren ginge.
Abbildung 10: Klasse UserManager
Systemnutzer im der Geschäftslogik In der Geschäftslogik ist der Systemnutzer durch die Klasse UserManager (siehe Abbildung 10) repräsentiert,
hier werden keine Algortihmen ausgeführt sondern nur Zugriff auf die Datenhaltungsschicht bereitgestellt. Folgende Methoden stehen zur Verfügung:
• AddNewEisUser : Ruft mit dem übergebenen EisUser-Objekt die statische Methode InsertEisUser der Klasse EisUserDAL auf und gibt deren
Ergebnis zurück.
• DeleteEisUser : Ruft mit dem übergebenen Guid-Objekt die statische Methode DeleteEisUser der Klasse EisUserDAL auf und gibt deren Ergebnis
zurück.
• GetAllEisUsers: Ruft statische Methode GetAllEisUsers der Klasse
EisUserDAL auf und gibt deren Ergebnis zurück.
59
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• GetEisUser : Ruft mit dem übergebenen Guid-Objekt die statische Methode GetEisUser der Klasse EisUserDAL auf und gibt deren Ergebnis
zurück.
• GetEisUserRoles: Ruft mit dem übergebenen Guid-Objekt die statische
Methode GetEisUserRoles der Klasse EisUserDAL auf und gibt deren Ergebnis zurück.
• GetUsersByFirstname: Ruft mit dem übergebenen string die statische
Methode GetUsersByFirstname der Klasse EisUserDAL auf und gibt deren
Ergebnis zurück.
• GetUsersByLastname: Ruft mit dem übergebenen string die statische
Methode GetUsersByLastname der Klasse EisUserDAL auf und gibt deren
Ergebnis zurück.
• GetUsersByLogin: Ruft mit dem übergebenen string die statische Methode GetUsersByLogin der Klasse EisUserDAL auf und gibt deren Ergebnis
zurück.
• GetUsersByRole: Ruft mit dem übergebenen string die statische Methode GetUsersByRole der Klasse EisUserDAL auf und gibt deren Ergebnis
zurück.
• IsUserUsed : Ruft mit dem übergebenen EisUser-Objekt die statische Methode IsUserUsed der Klasse EisUserDAL auf und gibt deren Ergebnis
zurück.
• LogOff : Ruft mit dem übergebenen Guid-Objekt die statische Methode
DeleteSession der Klasse SessionManager auf und meldet den Nutzer mit
der übergebenen GUID dadurch vom System ab.
• LogOn: Meldet einen Nutzer mittels eines übergebenen Logins und eines
Passworts am System an und initialisiert eine neue Session für diesen Nutzer oder verweigert die Anmeldung im Falle fehlerhafter Anmeldedaten.
• UpdateEisUser : Ruft mit dem übergebenen string die statische Methode
GetUsersByRole der Klasse EisUserDAL auf und deren Ergebnis zurück.
Systemnutzer in der grafischen Oberfläche Die Nutzerverwaltung wird
im Programmmenü durch den Button Systemnutzer repräsentiert, wobei nur
Administratoren auf diese Funktion zugreifen dürfen. Im zugehörigen Panel (siehe Abbildung 11) werden alle Systembenutzer mit ihren Stammdaten angezeigt.
Weitere Möglichkeiten in der Nutzerverwaltung sind die Suche bestimmter Benutzer anhand verschiedener durch ein Drop-Down-Fenster auswählbarer
Parameter. Am unteren Rand befinden sich die Funktionen zum Anlegen, Bearbeiten und Löschen. Zum Anlegen öffnet sich ein Panel (siehe Abbildung 12
mit Eingabefeldern und einer Liste zur Rechtevergabe als Popup, analog öffnet
sich das gleiche Panel beim Bearbeiten eines Benutzers, allerdings muss der zu
bearbeitende Nutzer in der Liste ausgewählt worden sein. Zum Löschen eines
Benutzers ist eine Bestätigung nötig. Das Programm verbietet die Löschung des
letzten Administratoren bzw. die Aberkennung des Administratorenstatus für
60
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 11: Übersicht über alle Systemnutzer
Abbildung 12: Anlegen oder Bearbeiten eines Nutzers
61
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
den letzten verbleibenden, da sonst mangels Zugriffsrechten kein Nutzer mehr
Zugriff auf die Nutzerverwaltung hätte.
5.1.2
Kunden und -verträge, Tarife und Lastprofile
Allgemeines Unter Stromkunden sind im Zusammenhang dieses Projektes
die Endabnehmer, also Endkunden eines Händlers zu verstehen, die Verträge
mit ihm abschließen und auf dieser Basis mit Strom beliefert werden. Zu jedem
Kunden werden die wesentlichen personenbezogenen Daten inklusive Bankverbindung gespeichert. Kunden können wegen der referenziellen Integrität der
Daten nur gelöscht werden, wenn sie nicht über Verträge mit dem Händler verfügen. Stromkunden werden über die von der Klasse Person abgeleitete Klasse
Customer dargestellt. In der Datenbank speichert die Tabelle Customer alle zu
Kunden anfallenden Daten.
Kundenverträge sind Lieferverträge, die mit einem Endkunden des Unternehmens abgschlossen werden. Diese können angelegt, bearbeitet und für den
Fall, dass kein Kunde mit ihnen Verknüpft ist, gelöscht werden. Jeder Kundenvertrag ist einer Regelzone und einem Regelkreis zugeordnet, weshalb es in der
Klasse CustomerContract, die Kundenverträge darstellt, entsprechende Referenzen gibt. Darüber hinaus gibt es zur Reduzierung des Datenverkehrs eine
vereinfachte Version der Kundenverträge, die in einem Datenbankview gespeichert und in der Klasse CustomerContractInfo gehalten wird.
Ein Tarif, dargestellt durch die Klasse Tariff beschreibt einen Energietarif,
der sich aus Strom aus herkömmlichen Quellen, sowie erneuerbaren Energien
zusammensetzt. Tarife können aktiv oder inaktiv sein. Sind sie aktiv, können
sie für neu abgeschlossene Kundenverträge benutzt werden, sonst sind sie auf die
Nutzung in vorhandenen Verträgen beschränkt. Jeder Vertrag hat genau einen
Tarif.
Lastprofile, die über die Klasse EnergyProfile dargestellt werden, sind die
Grundlage für Prognosen über den Energiebedarf, den der Energiehändler, der
das System benutzt, decken muss. Sie ordnen gemäß den Vorgaben der European
Transmission System Operators (ETSO) jeder Viertelstunde eines Tages einen
Energiebedarf in MWh zu. Ein Lastprofil enthält also insgesamt 96 Werte. Jedem
Kundenvertrag wird genau ein Lastprofil zugewiesen, damit ersichtlich ist, wann
das zu beliefernde Objekt mit wieviel Energie versorgt werden muss.
Im Entwurf war noch vorgesehen, insgesamt sechs derartige Zeitreihen in
einem Lastprofil mit je 96 Werten unterzubringen, um eine Differenzierung der
Verbrauchswerte zu erreichen, da diese je nach Jahreszeit und Wochentag stark
voneinander abweichen. Geplant waren Zeitreihen, die zwischen Sommer, Winter und einer Übergangsjahreszeit unterscheiden sowie zwischen Werktagen und
Wochenenden.
Dies Modell wurde während der Implementierung zugunsten einer einzigen
Zeitreihe – wie oben beschrieben – verworfen. Dafür gibt es im wesentlichen zwei
Gründe:
• Zum einen ist es nicht angenehm, als Nutzer knapp 600 Werte eingeben zu
müssen, um ein Lastprofil zu erstellen. Hierfür eine geeignete, d. h. nutzbare grafische Oberfläche zu erstellen, wäre praktisch unmöglich gewesen.
62
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• Andererseits ist das Modell mit sechs Zeitreihen schon recht speziell und
übernimmt durch die Abänderung der Verbrauchswerte in Abhängigkeit
von bestimmten Faktoren bereits Aufgaben, die eigentlich der Lastprognose und ihren Algorithmen zufallen. Daher erscheint es sinnvoller, dies
auch auf diese Komponente zu verlagern und die Lastprognose auf eine
Zeitreihe zu beschränken.
Das Zusammenspiel zwischen den verschiedenen Objekten wird in Abbildung 13
repräsentiert. Durch die Kundenverwaltung werden die im Entwurf beschriebenen Anwendungsfälle 7 bis 27 abgedeckt.
Um den Betrieb des Systems realitätsnah zu simulieren, wurden mehrere
zehntausend automatisch generierte Kunden mit einem oder mehreren Verträgen
in die Datenbank eingespeist. Als Grundlage für die Verträge dienten fünf real
existierende Lastprofile, die im Internet heruntergeladen werden können [Las06]
und unter anderem vom VDEW (Verband der Elektrizitätswirtschaft) benutzt
werden. Es handelt sich dabei um Profile für Telefonzellen, Straßenbeleuchtungen, Privathaushalte, kleine Gewerbebetriebe und landwirtschaftliche Betriebe.
Es werden jeweils mehrere Zeitreihen für Werte an verschiedenen Tagen und zu
verschiedenen Jahreszeiten angeboten. Die Entscheidung fiel dabei stets auf die
Werte für Werktage während der Übergangszeit zwischen Sommer und Winter
bzw. umgekehrt, weil dies relativ gut den Verbrauch bei durchschnittlichen Temperaturen repräsentiert. Die jahreszeitliche Anpassung der Werte erfolgt dann
in den Lastprognosen (siehe Abschnitt 5.3.1).
Kunden im Datenzugriff Kundenobjekte werden durch die Datenbanktabelle Customer abgebildet. In der Klasse CustomerDAL (siehe Abbildung 14)
wird der Datenzugriff folgendermaßen gewährleistet:
• AddNewCustomer : Fügt den übergebenen Kunden in die Datenbank ein
und gibt den Erfolg der Operation als ReturnCode zurück.
• CountCustomers: Zählt alle in der Datenbank vorhandenen Kundendatensätze und liefert deren Anzahl als Rückgabewert zurück.
• CreateCustomerFromDataRow : Erzeugt aus einem übergebenen Datensatz
aus der Datenbank ein neues Customer-Objekt und liefert es zurück.
• DeleteCustomer : Identifiziert einen Kunden über ein Guid-Objekt, löscht
diesen aus der Datenbank und zeigt über einen ReturnCode den Erfolg
der Aktion an.
• GetAllCustomers: Liefert alle in der Datenbank gespeicherten Kunden als
Liste von Customer-Objekten zurück.
• GetCustomer : Identifiziert einen Kunden über ein Guid-Objekt in der Datenbank, liest ihn aus und gibt ihn zurück.
• UpdateCustomer : Bekommt ein Kundenobjekt übergeben und aktualisiert
die Daten des bereits gespeicherten Datensatzes mit derselben GUID und
gibt den Erfolg der Aktion als ReturnCode zurück.
63
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 13: Klassen zur Kundenverwaltung
Abbildung 14: Klasse CustomerDAL
64
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• GetCustomerByNumber : Identifiziert einen Kunden anhand seiner von der
Datenbank vergebenen eindeutigen Kundennummer, liest ihn aus und gibt
ihn zurück.
• GetCustomerByName: Liefert eine Liste mit allen Kunden zurück, deren
Nachname einer übergebenen Zeichenkette hinreichend ähnelt.
• GetCustomerByCity: Liefert eine Liste mit allen Kunden zurück, deren
Wohnort einer übergebenen Zeichenkette hinreichend ähnelt.
• GetCustomerByContract: Liefert einen Kunden zurück, dem ein Kundenvertrag mit einer bestimmten übergebenen GUID zugeordnet ist oder
null, falls kein Kunde gefunden wurde.
Abbildung 15: Klasse CustomerManager
Kunden in der Geschäftslogik In der Geschäftslogik steht die Klasse
CustomerManager bereit (siehe Abbildung 15). Hier werden keine Algorithmen
ausgeführt sondern nur Zugriff auf die Datenhaltungsschicht bereitgestellt. Folgende Methoden stehen zur Verfügung:
• AddNewCustomer : Ruft mit dem übergebenen Customer-Objekt die statische Methode InsertCustomer der Klasse CustomerDAL auf und gibt deren
Ergebnis zurück.
• CountCustomer : Ruft die gleichnamige Methode aus der Klasse CustomerDAL
auf und gibt deren Ergebnis zurück.
• DeleteCustomer : Ruft mit dem übergebenen GUID-Objekt die statische
Methode DeleteCustomer der Klasse CustomerDAL auf und gibt deren Ergebnis zurück.
• GetCustomer : Ruft mit dem übergebenen Customer-Objekt die statische
Methode GetCustomer der Klasse CustomerDAL auf und gibt deren Ergebnis zurück.
65
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• GetAllCustomers: Ruft die statische Methode GetAllCustomers der Klasse
CustomerDAL auf und gibt deren Ergebnis zurück.
• UpdateCustomer : Ruft mit dem übergebenen Customer-Objekt die statische Methode UpdateCustomer der Klasse CustomerDAL auf und gibt
deren Ergebnis zurück.
• GetCustomerByNumber : Ruft mit dem übergebenen ID aus dem die statische Methode GetCustomerByNumber der Klasse CustomerDAL auf und
gibt deren Ergebnis zurück.
• GetCustomerByName: Ruft mit der übergebenen Zeichenkette die statische Methode GetCustomerByName der Klasse CustomerDAL auf und gibt
deren Ergebnis zurück.
• GetCustomerByCity: Ruft mit der übergebenen Zeichenkette die statische
Methode GetCustomerByCity der Klasse CustomerDAL auf und gibt deren
Ergebnis zurück.
• GetCustomerByContract: Ruft mit dem übergebenen GUID-Objekt die
statische Methode GetCustomerByContract der Klasse CustomerDAL auf
und gibt deren Ergebnis zurück
Abbildung 16: Klasse CustomerCustomerContractDAL
Kundenverträge im Datenzugriff Für Kundenverträge steht die Tabelle
CustomerContract zur Verfügung, die 1-1 -Fremdschlüsselbeziehungen zu den
Tabellen Customer, EnergyProfile, Tariff, AccountingArea und ControlArea
enthält. In der Klasse CustomerContractDAL (siehe Abbildung 16) wird der Datenzugriff folgendermaßen gewährleistet:
• CountCustomerContracts: Zählt alle vorhandenen Kundenverträge in der
Datenbank und gibt ihre Anzahl zurück.
66
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• CountCustomerContractsPerTariff : Zählt zu einem Tarif mit einer bestimmten GUID alle vorhandenen Verträge in der Datenbank und gibt
ihre Anzahl zurück.
• CreateCustomerContractFromDataRow : Erzeugt aus einer ausgelesenen
Tabellenzeile ein neues CustomerContract-Objekt.
• CreateCustomerContractInfoFromDataRow : Erzeugt aus einer ausgelesenen Viewzeile ein neues CustomerContractInfo-Objekt.
• DeleteCustomerContract: Identifiziert einen Kundenvertrag über eine GUID,
löscht diesen aus der Datenbank und zeigt über einen ReturnCode den Erfolg der Aktion an.
• GetAllCustomerContracts: Liefert alle in der Datenbank gespeicherten
Kundenverträge zurück.
• GetCustomerContract: Identifiziert einen Kundenvertrag über eine GUID
in der Datenbank, liest ihn aus und liefert ihn zurück.
• GetCustomerContractInfosForEnergyPrediction: Liefert alle in der Datenbank gespeicherten Kundenverträge, die teilweise oder ganz in den Zeitraum einer Lastprognose fallen, als vereinfachte CustomerContractInfoObjekte in einer Liste zurück.
• GetCustomerContractsForEnergyPrediction: Liefert alle in der Datenbank
gespeicherten Kundenverträge als Liste zurück, die teilweise oder ganz in
den Zeitraum einer Lastprognose fallen.
• GetCustomerContractsForCustomer : Liefert alle für einen Kunden mit einer bestimmten GUID gespeicherten Kundenverträge zurück.
• GetExpiringCustomerContracts: Liefert eine Liste aller Kundenverträge
zurück, die bis zu einem übergebenen Datum auslaufen.
• InsertCustomerContract: Fügt ein neues CustomerContract-Objekt in die
Datenbank ein und gibt den Erfolg der Operation als ReturnCode zurück.
• HasCustomerContracts: überprüft in der Datenbank, ob zu einem Kunden
Kunderverträge bestehen, und liefert True zurück, falls dem so ist, oder
False.
• UpdateCustomerContract: Ändert mittels des übergebenen Kundenvertrages die Werte des bereits in der Datenbank gespeicherten Datensatzes mit
derselben GUID in der Datenbank und liefert den Erfolg der Operation
über einen ReturnCode zurück.
Kundenverträge in der Geschäftslogik In der Geschäftslogik ist der Kundenvertrag durch die Klasse CustomerContractManager repräsentiert (siehe Abbildung 17). Folgende Methoden stehen zur Verfügung:
• AddNewCustomerContract: Ruft mit dem übergebenen CustomerContractObjekt die statische Methode InsertCustomerContract der Klasse
CustomerContractDAL auf und gibt deren Ergebnis zurück.
67
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 17: Klasse CustomerCustomerContractManager
• CountCustomerContracts: Ruft die gleichnamige Methode der Klasse
CustomerContractDAL auf und gibt deren Ergebnis zurück.
• CountCustomerContractsPerTariff : Ruft die gleichnamige Methode der
Klasse
CustomerContractDAL auf und gibt deren Ergebnis zurück.
• DeleteCustomerContract: Ruft mit der übergebenen GUID die gleichnamige Methode der Klasse CustomerContractDAL auf und gibt deren Ergebnis
zurück.
• GetAllCustomerContracts: Ruft die gleichnamige Methode der Klasse
CustomerContractDAL auf und gibt deren Ergebnis zurück.
• GetCustomerContract: Ruft mit der übergebenen GUID die g leichnamige
Methode der Klasse CustomerContractDAL auf und gibt deren Ergebnis
zurück.
• GetCustomerContractsForCustomer : Ruft die gleichnamige Methode der
Klasse CustomerContractDAL auf und gibt deren Ergebnis zurück.
• GetCustomerContractsForEnergyPrediction: Ruft die gleichnamige Methode der Klasse CustomerContractDAL auf und gibt deren Ergebnis zurück.
• GetCustomerContractInfosForEnergyPrediction: Ruft die gleichnamige Methode der Klasse CustomerContractDAL auf und gibt deren Ergebnis zurück.
• GetExpiringCustomerContracts: Ruft mit dem übergebenen Datum die
gleichnamige Methode der Klasse CustomerContractsDAL auf und gibt
deren Ergebnis zurück.
68
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• UpdateCustomerContract: Ruft mit dem übergebenen CustomerContractObjekt die gleichnamige Methode der Klasse CustomerContractDAL auf
und gibt deren Ergebnis zurück.
• HasCustomerContracts: Ruft die gleichnamige Methode der Klasse
CustomerContractDAL auf und gibt deren Ergebnis zurück.
Abbildung 18: Anlegen oder Bearbeiten eines Kunden
Abbildung 19: Anlegen oder Bearbeiten eines Kundenvertrages
Kunden und Kundenverträge in der grafischen Oberfläche In der grafischen Oberfläche wurde für die gesamte Kundenverwaltung ein zweiteiliges
Panel entworfen (siehe Abbildung 20), auf das Zugriff nur möglich ist, wenn
der Nutzer die Rolle Kundenbetreuer besitzt. Bei der Auswahl des Menüpunkts
Kunden in der linken Navigationsleiste wird es aufgerufen und zeigt im oberen
69
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Teil eine Kundenliste an, die bestimmten Suchkriterien entspricht. Es kann nach
Nachnamen, Kundennummern, Nutzern mit bestimmten Tarifen und Wohnorten gesucht werden. Dass anfangs nicht alle Nutzer angezeigt werden dient dazu, die über den Webservice zu übertragende Datenmenge gering zu halten. Bei
einigen Zehntausend registrierten Kunden könnten hierdurch bei vielen Nutzern nicht mehr vernachlässigbare Verzögerungen entstehen. Zu den gefundenen
Kunden werden alle wichtigen Daten angezeigt, die nach Auswahl eines Eintrags
über Doppelklick, das Kontextmenü oder einen Klick auf den Button Bearbeiten editiert werden können. Dazu öffnet sich, ebenso wie nach dem Klick auf
Anlegen, ein neues Panel, in das die Benutzerdaten eingetippt werden können
(siehe Abbildung 18).
Abbildung 20: Übersicht über Kunden und ihre Verträge
Im unteren Teil des Hauptpanels werden zu jedem ausgewählten Kunden
seine Verträge – sowohl gültige wie auch abgelaufene oder zukünftige – angezeigt.
Auch für die Kundenverträge stehen die Funktionen Anlegen, Bearbeiten und
Löschen zur Verfügung, wobei nur solche Verträge gelöscht werden können, die
noch nicht in Kraft getreten oder bereits abgelaufen sind. Neue Verträge können
nur nach Auswahl eines Kunden, dem sie zugeordnet werden sollen, angelegt
werden. Bei einem Klick auf den zugehörigen Button Anlegen wird ein Fenster
zur Dateneingabe geöffnet (siehe Abbildung 19), ebenso wenn ein Vertrag zum
Bearbeiten ausgewählt wird.
70
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Außerdem werden im Fenster links über der Navigationsleiste die aktuell
aktiven Tarife nach angezeigt, die nach der Häufigkeit ihrer Nutzung geordnet
sind. Nicht aktive Tarife werden nicht angezeigt, da sie dem Systemnutzer nicht
für den Abschluss neuer Verträge zur Verfügung stehen.
Tarife im Datenzugriff Tarife sind in der Datenbank durch die Tabelle
Tariff dargestellt. Der Datenzugriff wird über die statische Klasse TariffDAL
realisiert, die die folgende statische Methoden bereitstellt
• CreateTariffFromDataRow : Erzeugt aus einer ausgelesenen Tabellenzeile
ein neues Tariff-Objekt und gibt es zurück.
• InsertTariff : Fügt ein übergebenes Tariff-Objekt als neuen Tarif in die
Datenbank ein und zeigt über einen ReturnCode den Erfolg der Aktion
an.
• UpdateTariff : Aktualisiert anhand eines übergebenen Tariff-Objekts einen
in der Datenbank gespeicherten Tarif und zeigt über einen ReturnCode den
Erfolg der Aktion an.
• DeleteTariff : Löscht einen in der Datenbank gespeicherten Tarif und zeigt
über einen ReturnCode den Erfolg der Aktion an.
• IsTariffUsed : Überprüft, ob ein Tarif noch von Kundenverträgen benutzt
wird, und gibt das Ergebnis als booleschen Wert zurück.
• GetTariff : Liest einen Tarif mit einer übergebenen GUID aus der Datenbank aus und gibt ihn zurück.
• GetActiveTariffs: Liest alle Tarife mit aktiven Status aus der Datenbank
aus und liefert sie als Liste zurück.
• GetRankedTariffs: Liest alle Tarife aus der Datenbank aus und gibt sie
nach Benutzungshäufigkeit geordnet als Liste zurück.
• GetRankedActiveTariffs: Liest alle aktiven Tarife aus der Datenbank aus
und gibt sie nach Benutzungshäufigkeit geordnet als Liste zurück.
• GetAllTariffs: Liest alle Tarife aus der Datenbank aus und liefert sie als
Liste von Tariff-Objekten zurück.
Tarife in der Geschäftslogik In der Geschäftslogikschicht existiert die statische Klasse TarifManager zum Umgang mit Tarifen. Bereitgestellte Methoden:
• AddNewTariff : Ruft mit dem übergebenen Tariff-Objekt die statische
Methode InsertTariff der Klasse TariffDAL auf und deren Ergebnis zurück.
• DeleteTarif : Ruft mit der übergebenen GUID die statische Methode DeleteTariff der Klasse TarifDAL auf und git deren Ergebnis zurück.
• GetActiveTariffs: Ruft die statische Methode GetActiveTariffs aus der
Klasse TarifDAL auf und liefert deren Ergebnis als Array zurück.
71
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• GetAllTariffs: Ruft die statische Methode GetAllTariffs aus der Klasse
TariffDAL auf und liefert deren Ergebnis als Array zurück.
• GetRankedTariffs: Ruft die statische Methode GetRankedTariffs aus der
Klasse TariffDAL auf und liefert deren Ergebnis als Array zurück.
• GetRankedActiveTariffs: Ruft die statische Methode GetRankedActiveTariffs aus der Klasse TariffDAL auf und liefert deren Ergebnis als Array
zurück.
• GetTariff : Ruft mit einer übergebenen GUID für ein Tariff-Objekt die
statische Methode GetTariff der Klasse TariffDAL auf und gibt das Ergebnis zurück.
• IsTariffUsed : Ruft die statische Methode IsTariffUsed der Klasse TariffDAL
auf und übergibt ein Tariff-Objekt. Das Ergebnis wird zurückgegeben.
• UpdateTariff : Ruft mit dem übergebenen Tariff-Objekt die statische Methode UpdateTariff der Klasse TariffDAL auf und gibt deren Ergebnis
zurück.
Tarife in der grafischen Oberfläche In der GUI ist die Tarifverwaltung
über den Button Tarife im Hauptmenü zu erreichen. Das Tarif-Panel listet alle vorhandenen Tarife in einer Übersicht, geordnet nach Benutzungshäufigkeit,
auf. Darunter befinden sich Buttons für die entsprechenden Funktionen auf Tarifdaten (anlegen, ändern, löschen, (de)aktivieren). Ein ausgewählter Tarif kann
über den Button Tarif (de)aktivieren aktiviert bzw. deaktiviert werden. Ein
Haken in der Spalte Aktiv markiert aktive Tarife. In das Bearbeitungspanel,
ein sich zusätzlich öffnendes Fenster, gelangt man über den Tarif anlegen- oder
Tarif bearbeiten-Button. Hier gibt man die neuen bzw. ändert die vorhandenen
Werte eines Tarifs. Nach Eingabe und Validierung der Werte wird von der GUI
im Service Access Layer die Methode AddNewTariff zum Anlegen eines neuen
Tarifs bzw. UpdateTariff zum Bearbeiten eines vorhandenen Tarifs aufgerufen
und dieser Aufruf über den Webservice an den Server weitergeleitet.
Lastprofile im Datenzugriff Lastprofile werden in der Tabelle EnergyProfile
gespeichert. Die Verbrauchswerte eines Lastprofils sind dabei als CSVs in einer
Zelle gespeichert, was zwar kein optimales Datenbanklayout darstellt, weil so
keine Normalform eingehalten wird, jedoch erheblichen Aufwand bei der Programmierung erspart. Außerdem ist es unproblematisch, da CSVs einfach zu
parsen sind und nirgendwo Nullwerte oder Redundanzen auftreten. Der Datenzugriff wird über die statische Klasse EnergyProfileDAL realisiert, die die bereits
im vorigen Abschnitt vorgestellten statischen Methoden bereitstellt:
• CreateEnergyProfileFromDataRow : Erstellt aus einer ausgelesenen Tabellenzeile ein neues EnergyProfile-Objekt und gibt dieses zurück.
• InsertEnergyProfile: Fügt ein übergebenes Lastprofil in die Datenbank ein
und zeigt über einen ReturnCode den Erfolg der Aktion an.
72
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 21: Klasse EnergyProfileDAL
• UpdateEnergyProfile: Aktualisiert ein in der Datenbank gespeichertes Lastprofil anhand des übergebenen EnergyProfile-Objekts und zeigt über
einen ReturnCode den Erfolg der Aktion an.
• DeleteEnergyProfile: Löscht ein in der Datenbank gespeichertes Lastprofil
mit einer bestimmten GUID und zeigt über einen ReturnCode den Erfolg
der Aktion an.
• IsEnergyProfileUsed : Überprüft, ob ein Lastprofil noch von Kundenverträgen benutzt wird, und gibt das Ergebnis als booleschen Wert zurück.
• GetEnergyProfile: Liest ein Lastprofil mit einer übergebenen GUID aus der
Datenbank aus und gibt es zurück.
• GetEnergyProfileByName: Liest Lastprofile, deren Namen einen übergebenen String enthalten, aus der Datenbank aus und liefert sie als Liste
zurück.
• GetRankedEnergyProfile: Liest alle Lastprofile geordnet nach Einsatzhäufigkeit aus der Datenbank aus und liefert sie als Liste zurück.
• GetAllEnergyProfiles: Liest alle Lastprofile aus der Datenbank aus und
liefert sie als Liste zurück.
Lastprofile in der Geschäftslogik In der Geschäftslogikschicht existiert die
statische Klasse EnergyProfileManager zum Umgang mit Lastprofilen. Da aber
keinerlei Algorithmen auf den Lastprofilen ausgeführt werden müssen, erfolgt
lediglich ein Zugriff auf die passenden Methoden der darunterliegenden Datenhaltungsschicht, deren Ergebnisse weitergeleitet und vom Webservice, der die
Methoden dieser Klasse aufruft, als Rückgabewerte verwendet werden.
• AddNewEnergyProfile: Ruft mit dem übergebenen EnergyProfile-Objekt
die statische Methode InsertEnergyProfile der Klasse EnergyProfileDAL
auf und gibt deren Ergebnis zurück.
73
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 22: Klasse EnergyProfileManager
• UpdateEnergyProfile: Ruft mit dem übergebenen EnergyProfile-Objekt
die statische Methode UpdateEnergyProfile der Klasse EnergyProfileDAL
auf und gibt deren Ergebnis zurück.
• DeleteEnergyProfile: Ruft mit der übergebenen ID die statische Methode DeleteEnergyProfile der Klasse EnergyProfileDAL auf und gibt deren
Ergebnis zurück.
• IsEnergyProfileUsed : Ruft mit dem übergebenen EnergyProfile-Objekt
die statische Methode IsEnergyProfileUsed der Klasse EnergyProfileDAL
auf und gibt deren Ergebnis zurück.
• GetEnergyProfile: Ruft mit dem übergebenen EnergyProfile-Objekt die
statische Methode InsertEnergyProfile der Klasse EnergyProfileDAL auf
und gibt deren Ergebnis zurück.
• GetEnergyProfileByName: Ruft mit dem übergebenen String die statische
Methode GetEnergyProfileByName der Klasse EnergyProfileDAL auf und
gibt deren Ergebnis zurück.
• GetAllEnergyProfiles: Ruft die statische Methode GetAllEnergyProfiles
der Klasse EnergyProfileDAL auf, wandelt deren Ergebnis (eine Liste mit
EnergyProfile-Objekten) in ein Array um und gibt dies zurück.
Lastprofile in der grafischen Oberfläche Die grafische Oberfläche der
Lastprofile ist relativ einfach aufgebaut und besteht nur aus zwei Elementen:
• dem Übersichtsfenster, das die vorhandenen Lastprofile auflistet und den
Zugriff auf die verschiedenen Operationen für Lastprofile (anlegen, bearbeiten, löschen) bereitstellt und auch eine Suchfunktion bietet, die nach
bestimmten Lastprofilnamen sucht, und
• dem Eingabefenster, das erscheint, wenn ein neues Lastprofil erstellt oder
ein im Übersichtsfenster ausgewähltes geändert werden soll. Nach der Eingabe und Validierung von Werten wird durch Klick auf den Button Speichern die Funktion AddNewEnergyProfile aus dem Service Access Layer
74
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 23: Hauptfenster der Lastprofilverwaltung
aufgerufen, die das erzeugte Lastprofil über den Webservice zum Einfügen
in die Datenbank an den Server weiterreicht (analog beim Bearbeiten die
Methode UpdateEnergyProfile).
Beide Oberflächen sind als Windows Forms angelegt, wobei das Übersichtsfenster in das Hauptfenster und das Eingabefenster als abhängiges Pop-Up geladen
wird.
5.1.3
Stromlieferanten, Lieferangebote und -verträge
Allgemeines Ein Stromlieferant ist ein elementarer Bestandteil der Logik des
Programms. Er beliefert einen Stromhändler mit der benötigten Energie, welche
er mit seinen verschiedenen Kraftwerken (z.B. Atom-, Kohle-, Wind-, Wasserkraftwerke) produziert. Ein Lieferant kann einem Händler ein Lieferangebot für
Strom unterbreiten. Der Händler kann, wenn ihm die Bedingungen des Angebotes zusagen, dieses Angebot annehmen, sodass zwischen den beteiligten Parteien
ein Vertrag geschlossen wird. Der Vertragsschluss wird durch Änderung des Feldes Signed auf true gespeichert.
Die Klasse SupplierContract speichert sämtliche Details zu den einzelnen
Angeboten und Verträgen. Da gerade bei Übertragung von vielen Verträgen hier
große Datenmengen zusammen kommen, können auch SupplierContractInfoObjekte übertragen werden, die nur die für Übersichten notwendigen Daten
enthalten. Somit wird die Datenmenge und die Übertragungsdauer reduziert.
Die im Folgenden beschriebenen Funktionen decken die Anwendungsfälle 34 bis
46 des Entwurfs ab. Anwendungsfall 37 wurde dahingehend modifiziert, dass
Bilanzkreise und Regelzonen nun nicht mehr je Lieferant erfasst werden, sondern
je Liefervertrag.
Als Datenbasis wurden für den Testbetrieb etliche Lieferanten und mehrere
hundert, meist längerfristige Lieferverträge im Megawattbereich in die Datenbank eingefügt, die zusammen mit den Kundenverträgen eine für einen kleineren Stromhändler oder Energieversorger – etwa ein Stadtwerk, das ohne eigene
75
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 24: Eingabefenster für Lastprofile
Kraftwerke eine kleine Großstadt wie Oldenburg versorgen muss – eine realistische Situation ergibt.
Lieferanten, Lieferangebote und -verträge in der Datenbank In der
Datenbank existieren die Tabellen Supplier für die Lieferantendaten und SupplierContracts für die Lieferangebote und -verträge. Sie bilden die jeweiligen
Objekte ab.
Lieferanten, Lieferangebote und -verträge im Datenzugriff Der Datenzugriff wird über die statischen Klassen SupplierDAL und SupplierContractDAL
realisiert. Die nachfolgend vorgestellten Methoden werden von Funktionen der
Klassen SupplierManager.cs und SupplierContractManager.cs aufgerufen:
• CountSuppliers: Gibt die Zahl der in der Datenbank gespeicherten Lieferanten zurück.
• CreateSupplierFromDataRow: Erzeugt aus dem übergebenen DataRow-Objekt ein Supplier-Objekt und gibt dieses zurück.
• DeleteSupplier: Löscht den durch die übergebene GUID eindeutig identifizierten Lieferanten aus der Datenbank und zeigt über einen booleschen
Wert den Erfolg der Aktion an.
76
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 25: Lieferant
• GetAllSuppliers: Liest alle Lieferanten aus der Datenbank aus und liefert
diese als generische Liste zurück.
• GetSupplier: Liest den durch die übergebene GUID identifizierten Lieferanten aus und gibt ihn zurück.
• GetSuppliersByCity: Liest alle Lieferanten, deren Firmensitz den übergebenen Wert enthält, aus und gibt diese als generische Liste zurück.
• GetSuppliersByCompany: Liest alle Lieferanten, deren Firmenname den
übergebenen Wert enthält, aus und gibt diese als generische Liste zurück.
• GetSuppliersByEmail: Liest alle Lieferanten, deren Emailadresse den übergebenen Wert enthält, aus und gibt diese als generische Liste zurück.
• GetSuppliersByFax: Liest alle Lieferanten, deren Faxnummer den übergebenen Wert enthält, aus und gibt diese als generische Liste zurück.
• GetSuppliersByLastName: Liest alle Lieferanten, deren Ansprechpartner
im Nachnamen den übergebenen Wert enthalten, aus und gibt diese als
generische Liste zurück.
• GetSuppliersByFon: Liest alle Lieferanten, deren Telefonnummer den übergebenen Wert enthält, aus und gibt diese als generische Liste zurück.
• GetSuppliersBySupplierId: Liest alle Lieferanten, deren ID den übergebenen Wert enthält, aus und gibt diese als generische Liste zurück.
• HasSupplierContracts: Gibt an, ob ein Lieferant noch über Lieferverträge
verfügt. Der Lieferant kann als Supplier-Objekt übergeben oder durch
eine GUID identifiziert werden.
77
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 26: Lieferangebot und -vertrag
• InsertSupplier: Fügt einen neuen Lieranten in die Datenbank ein und zeigt
über einen booleschen Wert den Erfolg der Aktion an.
• UpdateSupplier: Aktualisiert einen Datenbankeintrag auf die Werte des
übergebenen Supplier-Objektes und zeigt über einen booleschen Wert
den Erfolg der Aktion an.
• CountSupplierContracs: Liefert die Anzahl an vorhandenen Lieferangeboten und -verträgen zurück.
• CreateSupplierContractFromDataRow: Erstellt ein neues Lieferangebot bzw.
einen neuen Liefervertrag aus dem übergebenenDataRow-Objekt.
• CreateSupplierContractInfoFromDataRow: Erstellt ein neues
SupplierContractInfo-Objekt aus dem übergebenen DataRow-Objekt.
• DeleteSupplierContract: Löscht ein Angebot oder einen Vertrag aus der
Datenbank, dessen ID dieser Funktion übergeben wird. Der Erfolg der
Aktion wird über den zurück gegebenen booleschen Wert angezeigt.
• GetAllSupplierContracts: Liefert alle in der DB gespeicherten Lieferangebote und -verträge als generische Liste zurück.
• GetDemandCoverageInPercent: Liefert die Abdeckung des Energiebedarfs
in Prozent zum aktuellen Zeitpunkt zurück. Dabei werden die Kundenverträge als Grundlage genommen, falls für den aktuellen Zeitpunkt keine
Lastprognose vorhanden ist. Andernfalls wird die zuletzt erzeugte Lastprognose, die zum aktuellen Zeitpunkt gilt, genommen.
78
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 27: Lieferanten im Datenzugriff
• GetExpiringSupplierContracts: Liefert eine generische Liste aller Verträge
zurück, die bis zum übergebenen Zeitpunkt ablaufen und vom übergebenen
Nutzer betreut werden.
• GetSupplierContract: Liefert einen bestimmten Liefervertrag oder -angebot
für eine übergebene ID zurück.
• GetSupplierContractInfoByDate: Liefert alle im übergebenen Zeitraum gültigen Lieferverträge und -angebote als Liste von Info-Objekten zurück.
• GetSupplierContractInfoForRecommendation: Liefert alle im Zeitraum der
übergebenen Kaufempfehlung gültigen Lieferangebote als Info-Objekte zurück.
• GetSupplierContractsByCompany: Liefert alle Lieferangebote und -verträge,
deren Lieferantennamen den übergebenen Wert enthält, zurück.
• GetSupplierContractsForRecommendation: Liefert alle im Zeitraum der
übergebenen Kaufempfehlung gültigen Lieferangebot zurück.
• GetSupplierContractsForSchedule: Liefert alle am übergebenen Tag gültigen Lieferverträge zurück.
• GetSupplierContractsForSupplier: Liefert alle Angebote und Verträge für
ein übergebenes Supplier -Objekt zurück.
• GetSupply: Hilfsmethode für GetSupplyCoverageInPercent. Berechnet die
für den übergebenen Tag vereinbarte zu liefernde Energiemenge und gibt
diese zurück.
• HasDisturbances: Überprüft für einen übergebenen Vertrag bzw. für ein
übergebenes Angebot, ob Störungen vorliegen. Falls aktuell Störungen aufgetreten sind, wird true zurück gegeben, false sonst.
79
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• InsertSupplierContract: Fügt einen neuen Liefervertrag oder ein neues Lieferangebot in die Datenbank ein. Ein entsprechendes SupplierContractObjekt wird dieser Funktion übergeben.
• UpdateSupplierContract: Aktualisiert einen übergebenen Vertrag oder ein
übergebenes Angebot in der Datenbank und liefert true zurück, falls die
Aktualisierung erfolgreich war, false sonst.
Lieferanten, Lieferangebote und -verträge in der Geschäftslogik Die
Geschäftslogik stellt die Klassen SupplierManager.cs und
SupplierContractManager.cs zur Verfügung. In diesen Klassen sind alle gültigen Funktionen definiert, die auf Lieferanten, Lieferangeboten und -verträgen,
ausgeführt werden können. Jeder in dieser Klasse definierten Funktion ist eine entsprechende ausführende Funktion in der Datenzugriffsschicht zugeordnet,
welche von hier aus aufgerufen wird. Das Ergebnis des Datenzugriffs wird zurückgegeben. Sofern die Funktionsnamen im Datenzugriff von denen der Geschäftslogik abweichen oder weitere Prüfungen oder Berechnungen durchgeführt
werden, sind die Zuordnungen aufgeführt.
Abbildung 28: Lieferanten in der Geschäftslogik
• AddNewSupplier: Ruft InsertSupplier auf.
• DeleteSupplier: Prüft zunächst, ob ein Lieferant noch laufende Verträge
hat. Ist dies der Fall, darf er nicht gelöscht werden und es wird IsUsed
zurück gegeben. Ansonsten wird die Funktion DeleteSupplier aufgerufen
und deren Ergebnis als OK für true bzw. Error für false zurück gegeben.
• UpdateSupplier: Prüft zunächst, ob der zu aktualisierende Eintrag noch
in der Datenbank vorhanden ist und ruft bei Erfolg UpdateSupplier auf.
Mögliche Rückgabewerte sind NotFound, OK, Error und DBFailure.
• DeleteSupplierContract: Prüft vor dem eigentlichen Löschen, ob der Vertrag noch in der Datenbank existiert, ob er gerade bedient wird und
80
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
ob Störungen existieren. Anschließend wird DeleteSupplierContract aufgerufen. Mögliche Rückgabewerte sind NotFound, IsCurrentlyServed,
HasDisturbances, OK, Error und DBFailure.
Lieferanten in der grafischen Oberfläche Die Übersicht über die Lieferanten eines Händlers wird in der GUI durch Anklicken des Buttons Lieferanten
oder den entsprechenden Menüpunkt erreicht. Der Systemnutzer sieht nun eine nach Lieferantennummern geordnete Liste. Standardmäßig werden in diesem
Menüpunkt alle Lieferanten des Händlers angezeigt, da die Liste der Lieferanten
im Gegensatz zu der Liste der Kunden überschaubar ist. Weitere Felder neben
den Lieferantennummern sind deren Firmenname, Straße, Hausnummer, Postleitzahl, Ort, Kontonummer, Bankleitzahl, Telefon- und Faxnummer, Anrede,
Vorname, Nachname und E-Mail-Adresse.
Um nun nach bestimmten Lieferanten suchen zu können, bietet das System dem Nutzer eine Suchfunktion an, mittels welcher er nach Lieferantennummer, Firmenname, Ort, Nachname, Telefonnummer, Telefaxnummer oder
E-Mail-Adresse suchen kann. Zusätzlich hat der Nutzer auch die Möglichkeit,
nach der speziellen Suche die Liste aller Lieferanten zurück zu erhalten, indem
er auf den Button Alle Anzeigen drückt.
Unter dem Datenfeld, welches die Lieferanten anzeigt, sind drei weitere Buttons angeordnet. Diese sind zum Hinzufügen neuer Lieferanten, Bearbeiten oder
Löschen bestehender Lieferanten vorgesehen und tragen die Aufschriften Lieferant anlegen, Lieferant bearbeiten, Lieferant löschen.
In einem weiteren Datenfeld, welches sich unter der Lieferantenanzeige befindet, werden die zu einem Lieferanten gehörenden Lieferangebote und Lieferverträge angezeigt. Dieses Datenfeld ist gefüllt mit Werten für die Attribute Bearbeiter, Bilanzkreis, Regelzone, Startdatum, Enddatum, Menge (MWh/h), Preis
(Euro/MWh) und Abgeschlossen. Abgeschlossen bezeichnet hiebei den Status
eines Angebotes. Ist das jeweilige Feld mit einem Häkchen gekennzeichnet, so
ist das Angebot bereits ein Vertrag.
Auch zu diesem Datenfeld gibt es Buttons, mit denen bestimmte Aktionen durchgeführt werden können. Diese sind das Hinzufügen eines neuen Angebotes oder Vertrages, das Bearbeiten eines Angebotes oder Vertrages und
das Löschen eines Angebotes oder Vertrages. Die Namen dieser Buttons lauten
Lieferantangebot/-vertrag eingeben, Lieferantangebot/-vertrag bearbeiten
und Lieferantangebot/-vertrag löschen.
5.1.4
Bilanzkreise und Regelzonen
Allgemeines Ein Bilanzkreis stellt den Verantwortungsbereich eines Stromhändlers dar, in dem dieser für ausgeglichene Ein- und Verkauf von Energie
verantwortlich ist. Ein Bilanzkreis kann sich über mehrere Regelzonen erstrecken. Bei der Erfüllung von Lieferverträgen wird Strom aus einem Bilanzkreis
in einen anderen geführt. Für jeden Bilanzkreis wird der Name des Unternehmens, eine Abkürzung und der ETSO Identification Code (EIC) gespeichert.
Ein Bilanzkreis wird im EIC durch ein X an der dritten Stelle des EIC gekennzeichnet.
81
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Regelzonen stellen den Verantwortungsbereich der einzelnen Übertragungsnetzbetreiber (ÜNB) dar, innerhalb dessen sie für ausgeglichene Einspeisung
und Entnahme von Energie verantwortlich sind. Die Regelzone ist dabei identisch mit dem physikalischen Stromnetz, dass der ÜNB betreibt. Wie auch für
Bilanzkreise werden Name des Unternehmens, Abkürzung und EIC gespeichert.
Regelzonen werden durch ein Y an der dritten Stelle des EIC gekennzeichnet. Zu
Abbildung 29: Bilanzkreis- und Regelzonenobjekt
jedem Lieferangebot, -vertrag und Kundenvertrag werden Bilanzkreis und Regelzone gespeichert, um die für den ordnungsgemäßen Netzbetrieb notwendigen
Energiefahrpläne erstellen zu können.
Die Verwaltung von Bilanzkreisen und Regelzonen deckt die Anwendungsfälle 28 bis 33 des Entwurfs ab.
Bilanzkreise und Regelzonen in der Datenbank Für Bilanzkreise und
Regelzonen existiert je eine Tabelle (AccountingArea und ControlArea) in der
Datenbank. Sie bilden die gleichnamigen Objekte eins zu eins ab.
Bilanzkreise und Regelzonen im Datenzugriff
• AccountingAreaReferenced: Prüft, ob in einer der Tabellen, die auf die
AccountingArea-Tabelle verweisen, ein Verweis auf die übergebene ID existiert und gibt true zurück, falls ein Verweis existiert, false sonst.
• CreateAccountingAreaFromDataRow: Erstellt ein AccountingArea-Objekt
aus dem übergebenen DataRow-Objekt.
• DeleteAccountingArea: Löscht das mittels der übergebenen ID eindeutig
identifizierte AccountingArea-Objekt aus der Datenbank.
• GetAccountingArea: Liefert den Bilanzkreis zurück, der zur übergegebenen
ID gehört.
• GetAccountingAreaByAbbreviation: Liefert alle Bilanzkreise zurück, deren
Abkürzung die übergebene Zeichenfolge enthält.
82
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 30: Datenzugriff auf Bilanzkreise und Regelzonen
• GetAccountingAreaByEIC: Liefert alle Bilanzkreise zurück, deren EIC die
übergebene Zeichenfolge enthält.
• GetAccountingAreaByOwner: Liefert alle Bilanzkreise zurück, deren Eigentümer die übergebene Zeichenfolge enthält.
• GetAllAccountingAreas: Liefert alle Bilanzkreise aus der Datenbank zurück.
• GetDatabase: Gibt die verwendete Datenbankverbindung zurück. Diese
Funktion wird für das Massen-Update benötigt, da hier durch die Transaktionsmechanismen dieselbe Verbindung für alle Anfragen benutzt werden
muss.
• GetMarkedAccountingAreas: Liefert alle Bilanzkreise zurück, deren DeletedFeld auf true gesetzt ist.
• InsertAccountingArea: Fügt das übergebene AccountingArea-Objekt in die
Datenbank ein.
• IsEICAvailable: Prüft, ob in der Datenbank bereits ein Eintrag mit dem
übergebenen EIC existiert. Gibt true zurück, falls kein Eintrag existiert,
false sonst.
• MarkAccountingAreaAsDeleted: Setzt für das durch die übergebene ID eindeutig identifizierte AccountingArea-Objekt das Feld Deleted auf true.
• UpdateAccountingArea: Aktualisiert den Datenbankeintrag für das übergebene AccountingArea-Objekt mit dessen Daten.
83
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• ControlAreaReferenced: Prüft, ob in einer der Tabellen, die auf die ControlArea-Tabelle verweisen, ein Verweis auf die übergebene ID existiert und
gibt true zurück, falls ein Verweis existiert, false sonst.
• CreateControlAreaFromDataRow: Erstellt ein ControlArea-Objekt aus dem
übergebenen DataRow-Objekt.
• DeleteControlArea: Löscht das mittels der übergebenen ID eindeutig identifizierte ControlArea-Objekt aus der Datenbank.
• GetAllControlAreas: Liefert alle Regelzonen aus der Datenbank zurück.
• GetControlArea: Liefert die Regelzone zurück, die zur übergegebenen ID
gehört.
• GetControlAreaByAbbreviation: Liefert alle Regelzonen zurück, deren Abkürzung die übergebene Zeichenfolge enthält.
• GetControlAreaByEIC: Liefert alle Regelzonen zurück, deren EIC die übergebene Zeichenfolge enthält.
• GetControlAreaByOwner: Liefert alle Regelzonen zurück, deren Eigentümer die übergebene Zeichenfolge enthält.
• GetMarkedControlAreas: Liefert alle Regelzonen zurück, deren DeletedFeld auf true gesetzt ist.
• InsertControlArea: Fügt das übergebene ControlArea-Objekt in die Datenbank ein.
• IsEICAvailable: Prüft, ob in der Datenbank bereits ein Eintrag mit dem
übergebenen EIC existiert. Gibt true zurück, falls kein Eintrag existiert,
false sonst.
• MarkControlAreaAsDeleted: Setzt für das durch die übergebene ID eindeutig identifizierte ControlArea-Objekt das Feld Deleted auf true.
• UpdateControlArea: Aktualisiert den Datenbankeintrag für das übergebene ControlArea-Objekt mit dessen Daten.
Bilanzkreise und Regelzonen in der Geschäftslogik Die Geschäftslogik
stellt durch die Klassen AccountingAreaManager.cs und
ControlAreaManager.cs alle für den Client verfügbaren Methoden bereit, über
die auf Bilanzkreise und Regelzonen zugegriffen werden kann. Die meisten dieser Funktionen rufen die gleichnamigen Funktionen der jeweiligen Datenzugriffsklassen auf; alle Methoden, die weitere Berechnungen durchführen, werden im
Folgenden erläutert.
• AreaBulkUpdate: Der übergebene Array enthält in jeder Zeile eine Regelzone oder einen Bilanzkreis. Zusammen sind das alle aktuell gültigen Einträge, die laut VDN Berlin vorhanden sind. Innerhalb einer Transaktion
wird nun jeder String abgearbeitet. Zunächst werden Listen aller bislang
84
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 31: Bilanzkreise und Regelzonen in der Geschäftslogik
bekannten Bilanzkreise und Regelzonen aus der Datenbank durch Aufruf von GetAllAccountingAreas und GetAllControlAreas des Datenzugriffs
geladen und mit dem übergebenen Array verglichen. Weicht ein Listeneintrag von der entsprechenden Zeile (identifiziert über den EIC) ab, wird der
Listeneintrag aktualisiert und die Änderung durch Aufruf von UpdateAccountingArea bzw. UpdateControlArea an die Datenbank gemeldet. Jedes
verglichene Element wird aus seiner Liste – nicht der Datenbank – entfernt.
Existiert zu einer Zeile des Arrays kein Eintrag in den Listen, wird ein
entsprechender neuer Eintrag durch Aufruf der statischen Methode InsertAccountingArea bzw. InsertControlArea erzeugt. Sobald nun der gesamte
Array abgearbeitet wurde, stehen in den beiden Listen nur noch die Regelzonen und Bilanzkreise, die zwar in der Datenbank, aber nicht im Array
enthalten sind. Sie werden somit gelöscht oder, falls noch Referenzen auf
sie existieren, als gelöscht markiert.
Sind alle Datenbankoperationen ohne Fehler abgeschlossen, wird die Transaktion ebenfalls geschlossen und die Änderungen somit in die Produktivdaten übernommen. Es wird OK zurückgegeben. Hat eine DB-Operation
einen Fehler produziert, wird die Transaktion abgebrochen, sämtliche Änderungen verworfen und Error zurückgegeben. Wurde eine Exception geworfen, wird sie gefangen, die Transaktion abgebrochen und DBFailure
zurückgegeben.
• bulkDeleteAccountingArea: Hilfsmethode für AreaBulkUpdate. Löscht alle
übergebenen Bilanzkreise aus der Datenbank.
85
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• bulkDeleteControlArea: Hilfsmethode für AreaBulkUpdate. Löscht alle übergebenen Regelzonen aus der Datenbank.
• DeleteAccountingArea: Prüft zunächst, ob der zu löschende Bilanzkreis
noch in der Datenbank existiert und ob keinerlei Referenzen auf diesen
existieren. Sind diese Prüfungen erfolgreich, wird der Bilanzkreis aus der
Datenbank gelöscht. Mögliche Rückgabewerte sind NotFound, IsUsed, OK,
Error und DBFailure.
• MarkAccountingAreaAsDeleted: Prüft zunächst, ob der zu ändernde Bilanzkreis noch in der Datenbank existiert und markiert diesen im Erfolgsfall als gelöscht. Mögliche Rückgabewerte sind NotFound, OK, Error und
DBFailure.
• processAccountingArea: Hilfsfunktion für AreaBulkUpdate. Bearbeitet einen
als Bilanzkreis identifizierten String und führt die nötigen Updates aus
oder erzeugt einen neuen Datenbankeintrag.
• processControlArea: Hilfsfunktion für AreaBulkUpdate. Bearbeitet einen
als Regelzone identifizierten String und führt die nötigen Updates aus oder
erzeugt einen neuen Datenbankeintrag.
• UpdateAccountingArea: Prüft zunächst, ob der zu ändernde Bilanzkreis
noch in der Datenbank existiert und führt im Erfolgsfall die Änderung
aus. Mögliche Rückgabewerte sind NotFound, OK, Error und DBFailure.
• DeleteControlArea: Prüft zunächst, ob die zu löschende Regelzone noch in
der Datenbank existiert und ob keinerlei Referenzen auf diese existieren.
Sind diese Prüfungen erfolgreich, wird die Regelzone aus der Datenbank
gelöscht. Mögliche Rückgabewerte sind NotFound, IsUsed, OK, Error und
DBFailure.
• MarkControlAreaAsDeleted: Prüft zunächst, ob die zu ändernde Regelzone
noch in der Datenbank existiert und markiert sie im Erfolgsfall als gelöscht.
Mögliche Rückgabewerte sind NotFound, OK, Error und DBFailure.
• UpdateControlArea: Prüft zunächst, ob die zu ändernde Regelzone noch
in der Datenbank existiert und führt im Erfolgsfall die Änderung aus.
Mögliche Rückgabewerte sind NotFound, OK, Error und DBFailure.
Bilanzkreise und Regelzonen in der grafischen Oberfläche Da Bilanzkreise und Regelzonen von der Datenhaltung her nahezu identisch sind, wurden
ihre Verwaltungsfunktionen in einem gemeinsamen Panel zusammen gefasst.
Es ist in der GUI über den Menüpunkt ”Bilanzierung” im Hauptmenü oder
den entsprechenden Button links zu erreichen. Das Verwaltungspanel (Klasse
PanelSearchArea.cs) ist in das Hauptfenster integriert und listet zunächst alle
Bilanzkreise in einer Übersicht auf. Der Anzeigemodus kann beliebig von Bilanzkreisen zu Regelzonen und zurück gewechselt werden; eine Suchfunktion dient
zur Eingrenzung der Anzeige. Unterhalb der Übersicht finden sich Buttons für
die Funktionen Anlegen, Ändern und Löschen.
86
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 32: Übersicht der vorhandenen Bilanzkreise
In das Bearbeitungspanel (Klasse PanelAddArea.cs) gelangt man über einen
Klick auf die Buttons Bilanzkreis (Regelzone) anlegen bzw. Bilanzkreis (Regelzone) ändern. Im sich öffnenden Popup-Fenster gibt man die neuen Daten ein
bzw. ändert die vorhandenen Daten.
Abbildung 33: Bearbeiten-Fenster für einen Bilanzkreis
Soll ein Bilanzkreis oder eine Regelzone gelöscht werden, wird zunächst geprüft, ob noch irgendwo Referenzen darauf existieren. Falls ja, wird nur eine
Gelöscht-Attribut gesetzt; dadurch können keine weiteren Referenzen auf das
Objekt angelegt werden. Falls nein, werden die Informationen aus der Datenbank gelöscht. In der Übersicht werden als gelöscht markierte Bilanzkreise und
Regelzone grau dargestellt.
87
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Über den Button Massen-Update können berechtigte Nutzer eine CSV-Datei
im Format Unternehmen;Abkürzung;EIC auswählen. Diese Datei wird an den
Server übertragen und bringt die Datenbestände für Bilanzkreise und Regelzone
auf den Stand der Datei. Eine aktuelle Liste mit gültigen EICs ist beispielsweise
unter [EIC06] als Excel-Datei verfügbar. Nach dem Export in das vorgegebene
Format kann diese Datei vom EIS verarbeitet.
5.2
EEX-Handel
Die (langfristigen) Lieferverträge reichen nicht immer für eine (nahezu) exakte
Deckung des Strombedarfs der zu versorgenden Kunden aus. Laut Vorgaben
dürfen die in Fahrplänen angegebenen Mengen maximal fünf Prozent nach oben
oder unten von der tatsächlich verbrauchten Menge abweichen. Zudem kann es
durch Störungen seitens der Stromanbieter zu kurzfristigen Versorgungsengpässen kommen. Um solche Probleme in den Griff zu bekommen und weil Strom
im Zuge der Liberalisierung des Energiemarktes zunehmend an Energiebörsen
gehandelt wird, bietet das Energieinformationssystem auch die Möglichkeit, Angebote zum Kauf oder Verkauf von Strom zu erstellen, die direkt an der Europäischen Energiebörse EEX in Leipzig abgegeben werden können.
EEX-Handel in der grafischen Oberfläche Der gesamte Handel mit der
EEX wurde zwecks besserer Übersicht in einem Panel zusammengefasst. Links
über der Navigationsleiste wird bei Aufruf des Panels eine Tabelle mit den aktuellen Marktdaten eingeblendet (siehe 5.2.4). Das eigentliche Panel ist dreigeteilt
(siehe Abbildung 34). Oben wird eine Liste mit Lastprognosen angezeigt, die
am aktuellen Tag gelten. Bei Auswahl einer dieser Lastprognosen wird rechts
daneben ein Graph mit Hilfe der ZedGraph-Bibliothek berechnet, der die Überbzw. Unterdeckung für den folgenden Tag, das heißt, um wieviel mit den aktuellen Lieferverträgen und EEX-Lieferungen sowie Störungen der durch die
Kundenverträge anfallende Energiebedarf über- oder unterschritten wird.
Die Berechnung der Überdeckung wird wie auch alle anderen komplizierten
Algorithmen in der serverseitigen Geschäftslogik statt (Klasse EexManager). Dazu existiert in der Datenzugriffsschicht die Methode subtractContractFromEnergyPrediction, die als Argument unter anderem die ausgewählte Lastprognose
übergeben bekommt. Zunächst werden alle Lieferverträge und EEX-Lieferungen
ermittelt, die am fraglichen Tag gelten. Danach werden die darin genannten
Mengen für die einzelnen Zeitintervalle von den in der Lastprognose genannten
Verbrauchswerten subtrahiert, wobei die in Lieferverträgen genannten Mengen
nur abzüglich eventueller Störungen betrachtet werden. Allerdings geschieht diese Berechnung nur für jedes vierte Viertelstundenintervall, so dass in der Methode computeGraphPoints, die die im Graphen anzuzeigenden Werte zurückliefert,
nur ein Wert pro Stunde berechnet wird. Dies geschieht, damit der Graph, der
nur sehr begrenzten Platz zur Verfügung hat, übersichtlich bleibt, und um die
Rechenzeit, die sich als zu lang erwies, zu reduzieren.
Unter dem Graphen finden sich zwei Übersichten, in denen zum einen alle
bestehenden EEX-Stundenganbote und zum anderen alle bestehenden EEXBlockangebote mit den wichtigsten Parametern angezeigt werden. Bei Klick auf
den Anlegen-Button wird jeweils ein Fenster geöffnet, in das ein neues Angebot
88
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 34: Panel für EEX-Handel
eingegeben werden kann. Der Bearbeiten-Button öffnet das gleiche Fenster, jedoch mit den Daten des ausgewählten Angebots befüllt. Ein Klick auf Lieferung
öffnet einen Dialog zur Eingabe einer EEX-Lieferung auf Basis des ausgewählten
Angebots.
Ganz unten schließlich befinden sich Anzeigen für die EEX-Zugangsdaten
des angemeldeten Nutzers, die er über einen Klick auf Daten ändern bearbeiten
kann. Sollte noch kein EEX-Konto im System gespeichert sein, wird er beim Aufruf dieses Panels gebeten, eines anzulegen, weil ohne EEX-Zugangsdaten keine
Angebote verfasst werden können. Überprüft werden die eingegebenen Daten
allerdings nicht, da es keine Schnittstelle zum Datenbestand der Energiebörse
gibt.
Die EEX-Funktionalitäten decken die Anwendungsfälle 72 bis 84 sowie 63
des Entwurfs ab.
5.2.1
Zugangsdaten zur Energiebörse
Damit an der EEX gehandelt werden kann, müssen die Nutzer, die dies tun
wollen, sich durch spezielle Zugangsdaten, nämlich einen eindeutigen Händlernamen und eine zugehörige ID, ausweisen. Dieser Zusammenhang wird in der
Klasse EexAccount verwirklicht, wobei jedem Systemnutzer maximal ein solcher
Zugang gewährt wird (siehe Abbildung 35
89
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 35: Klasse EexAccount
EEX-Zugangsdaten im Datenzugriff Es existiert eine Datenbanktabelle
namens EexAccount, in der die in der gleichnamigen Klasse vorhandenen Attribute gespeichert werden und eine Fremdschlüsselbeziehung zum Systemnutzer,
dem diese Zugangsdaten gehören, besteht.
Abbildung 36: Klasse EexAccountDAL
In der Klasse EexAccountDAL (siehe Abbildung 36 werden folgende Methoden zum Zugriff auf die Datenbank bereit:
• GetEexAccount: Liefert zu einer gegebenen ID ein bestimmtes aus der
Datenbank ausgelesenes EexAccount-Objekt zurück.
• InsertEexAccount: Fügt neue EEX-Zugangsdaten für einen Benutzer in die
Datenbank ein.
• UpdateEexAccount: Aktualisiert die vorhandenen EEX-Zugangsdaten eines Nutzers in der Datenbank.
• DeleteEexHourBid: Löscht die EEX-Zugangsdaten eines Nutzers mit einer
bestimmten ID aus der Datenbank.
• CreateEexAccountFromDataRow: Erzeugt aus einer aus der Tabelle
EexAccount ausgelesenen Zeile einen Satz an Zugangsdaten für einen Benutzer.
90
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
EEX-Zugangsdaten in der Geschäftslogik Die Geschäftslogik für EEXZugangsdaten beschränkt sich auf das Delegieren der Anfragen des Webservices
an die Datenhaltungsschicht, da keinerlei Berechnungen auszuführen sind. Folgende Methoden in der Klasse EexManager (siehe Abbildung 46) kümmern sich
darum und werden bei Clientanfragen vom Webservice aufgerufen:
• GetEexAccount: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• AddNewEexAccount: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• UpdateEexAccount: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• DeleteEexHourBid: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
EEX-Zugangsdaten in der grafischen Oberfläche In der GUI nehmen
EEX-Zugangsdaten nur wenig Raum ein. Im unteren Teil des EEX-Panels werden die aktuellen Zugangsdaten des angemeldeten Nutzers angezeigt, und bei
Anklicken der Schaltfläche Daten ändern öffnet sich ein neues Fenster zur Eingabe eines neuen Kontonamens und einer neuen Konto-ID (siehe Abbildung 37).
Dieses Fenster erscheint auch, wenn noch keine EEX-Zugangsdaten angelegt
wurden, da ansonsten keine Angebote abgegeben werden können. Bei Nichteingabe wird kein Zugriff auf die weiteren Funktionen gewährt.
Abbildung 37: Eingabefenster für EEX-Zugangsdaten
5.2.2
Abgabe und Bearbeitung von Angeboten
Es wurden wie im Entwurf vorgesehen zwei der vielen verschiedenen Angebotstypen, die an der EEX gehandelt werden, implementiert:
• Stundenangebote
• Blockangebote
Beide Angebotstypen dienen in der Regel zur kurzfristigen Beschaffung kleinerer Energiemengen bis 250 MWh und können somit die oben genannten Probleme, die Nutzern unseres Systems durch Störungen längerfristiger Verträge oder
91
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
andere Gründe entstehen können, lösen helfen. Andere, vorwiegend zu spekulativen Zwecken eingesetzte Möglichkeiten wie etwa Terminhandel wurden aus
zeitlichen Aspekten, aber auch weil sie im Kontext eines Händlers, der Kunden
mit realem Strom versorgt und nicht spekuliert, nicht aufgegriffen. Beide Angebotstypen werden im folgenden näher erläutert. Ihnen gemein sind wesentliche
Parameter wie die Laufzeit von genau einer Woche und die Möglichkeit, in dieser Woche das Angebot nur an bestimmten Tagen gelten zu lassen. Außerdem
kann jedes Angebot nachträglich korrigiert werden und wird mit den Zugangsdaten des Nutzers, der es verfasst, versehen. Anders als normale Lieferangebote
können EEX-Angebote nicht zur Berechnung von Kaufempfehlungen herangezogen werden, weil der Energiehändler, der sie abgegeben hat, nicht über ihre
Annahme entscheidet.
Stundenangebote In einem Stundenangebot werden nun für die einzelnen
Stunden eines Tages Energiemengen zwischen −250 und 250 MWh angegeben,
wobei die Nummerierung der Stunden bei 1 (entspricht 0:00 bis 0:59 Uhr) beginnt und bei 24 (entspricht 23:00 bis 23:59 Uhr) endet. Für jede Stunde können
bis zu 16 verschiedene Mengen zu selbst definierten Höchstkauf- oder Mindestverkaufpreisen angegeben werden. Ein Kaufangebot besitzt dabei kein oder ein
positives Vorzeichen bei der Mengenangabe, ein Verkaufsangebot ein negatives.
Zu jedem Stundenangebot muss darüber hinaus angegeben werden, für welche
Regelzone es gedacht ist.
Abbildung 38: Klassen EexHourBid und EexHourBidDetails
Als abstrakter Datentyp wurden Stundenangebote wie in Abbildung 38 dargestellt implementiert. Es gibt dazu zwei Klassen, wobei die Klasse EexHourBid
die Rahmendaten beinhaltet sowie eine Liste von EexHourBidDetails-Objekten,
in denen jeweils die für eine Stunde zu den verschiedenen Preisen angegebenen
Mengen enthalten sind. Entsprechend wurden auch zwei gleichnamige Tabellen
92
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
in der Datenbank angelegt, wobei die Tabelle EexHourBidDetails einen Fremdschlüssel in die Tabelle EexHourBid besitzt.
Blockangebote Blockangebote dagegen beziehen sich auf von der EEX vordefinierte Zeitblöcke, in denen dann die ge- oder verkauften Mengen aus dem
jeweiligen Zielnetz geliefert oder dahin transferiert werden müssen, wozu für
jedes der maximal 15 auf einem Formular anzugebenden Angebote eine eigene Regelzone genannt werden muss. Mit den Vorzeichen für Kauf und Verkauf
verhält es sich hier genauso wie bei den Stundenangeboten.
Abbildung 39: Klassen EexBlockBid und EexBlockBidDetails
Wie bereits die Stundenangebote werden die Blockangebote auch durch zwei
Klassen – EexBlockBid und EexBlockBidDetails – dargestellt (siehe Abbildung 39). Die erste Klasse enthält wieder die Rahmeninformationen wie AngebotsID, Zugangsdaten des Benutzers und die Woche, in der das Angebot gilt. Die
zweite enthält diesmal je eines der maximal 15 Teilgebote pro Instanz. Pro Teilangebot muss eine Regelzone, eine Energiemenge, ein Höchstkauf- oder Mindestverkaufspreis sowie ein Block angegeben werden. In der Datenbank ergaben sich
aus diesem Modell ebenfalls zwei Tabellen namens EexBlockBid und EexBlockBidDetails, wobei aus letzterer eine Fremdschlüsselbeziehung zur erstgenannten
besteht.
PDF-Export Angebote sollen bei der EEX per Fax eingereicht werden. Hierfür werden von der Energiebörse spezielle Angebotsformulare bereitgestellt. Die
vom EIS erstellten Angebote können – sofern alle erforderlichen Daten vorhanden sind – in eine PDF -Datei exportiert werden, so dass man sie bei der Energiebörse einreichen kann. Dazu wurden die Formulare der EEX als Grafikdateien
ins System eingefügt und dienen als Hintergrund für einen von Windows.Forms
angebotenen ReportViewer, in den aus den relevanten Klassen die benötigten
Daten, also die mit Werten besetzten Attribute der Instanzen, im What-yousee-is-what-you-get-Verfahren eingebunden und positioniert werden können.
93
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Die Anzeige dieser Daten erwies sich jedoch als komplizierter als erwartet,
da sich nur einfache Datentypen direkt in die Vorlage einbinden ließen. Für alle
komplexeren Datenstrukturen, etwa Arrays, oder zum Zugriff auf Attribute von
Instanzen anderer Klassen, die innerhalb der ursprünglichen Klasse referenziert
werden, mussten Hilfsklassen erstellt werden. Diese werden vor Erzeugung des
Reports mit den nicht direkt einzubindenden Attributen der anderen Klassen
gefüllt. Die Attribute werden dann in eine Form gebracht, die direkt in den
Report übernommen werden kann, und eingebunden.
Die in den Report eingefügten Daten wurden so platziert, dass das von der
EEX bereitgestellte Formular korrekt ausgefüllt ist. Beim Aufruf des Kommandos PDF-Export öffnet sich ein neues Fenster, in dem dieser Report als Vorschau
angezeigt wird, und die Optionen zum Speichern als PDF werden angezeigt. Die
folgenden beiden Abbildungen (40 und 41) zeigen die Vorlage des Reports für
Stundenangebote und die PDF-Export-Vorschau.
Abbildung 40: Erstellung des Reports für Stundenangebote in Visual Studio
2005
EEX-Angebote im Datenzugriff Für den Datenzugriff auf EEX-Angebote
stehen die Klassen EexBlockBidDAL und EexHourBidDal zur Verfügung, deren
Methoden hier erläutert werden. Außerdem gibt es für die Angebotsdetails zwei
weitere Klassen, deren Methoden innerhalb der hier aufgeführten aufgerufen
werden und hier nicht weiter diskutiert werden.
• GetAllEexHourBids: Liefert alle EEX-Stundenangebote aus der Datenbank als Liste von EexHourBid-Objekten zurück.
• GetEexHourBid: Liefert das EEX-Stundenangebot zurück, das zur übergebenen GUID gehört.
94
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 41: Vorschau auf den PDF-Export eines Stundenangebots
Abbildung 42: Klassen für den Datenbankzugriff auf EEX-Angebote
95
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• GetEexHourBidDataSet: Liefert ein DataSet-Objekt zurück, das vereinfachte Darstellungen aller EEX-Stundenangebote zur Anzeige von Übersichten enthält.
• GetAllEexBlockBidInfos: Liefert vereinfachte Darstellungen aller EEX-Blockangebote als Liste von EexBlockBidInfo-Objekten zurück.
• InsertEexHourBid: Fügt ein neues EEX-Stundenangebot in die Datenbank
ein.
• UpdateEexHourBid: Aktualisiert mittels des übergebenen Stundenangebot
ein vorhandenes EEX-Stundenangebot in der Datenbank und gibt den
Erfolg dieser Operation als ReturnCode-Objekt zurück.
• DeleteEexHourBid: Löscht ein über seine GUID identifiziertes EEX-Stundenangebot aus der Datenbank und gibt den Erfolg der Operation als
ReturnCode-Objekt zurück. Stundenangebote können auch gelöscht werden, wenn sich noch EEX-Lieferungen auf sie beziehen.
• GetAllEexBlockBids: Liefert alle EEX-Blockangebote als Liste
von EexBlockBid-Objekten aus der Datenbank zurück.
• GetEexBlockBid: Liefert das EEX-Blockangebot zurück, das zur übergebenen GUID gehört.
• GetEexBlockBidDataSet: Liefert ein DataSet zurück, das vereinfachte Darstellungen aller EEX-Blockangebote zur Anzeige von Übersichten enthält.
• GetAllEexBlockBidInfos: Liefert vereinfachte Darstellungen aller
EEX-Blockangebote als Liste von EexBlockBidInfo-Objekten zurück.
• InsertEexBlockBid: Fügt ein neues EEX-Blockangebot in die Datenbank
ein.
• UpdateEexBlockBid: Aktualisiert mittels des übergebenen Blockangebots
ein vorhandenes EEX-Blockangebot in der Datenbank und gibt den Erfolg
dieser Operation als ReturnCode-Objekt zurück.
• DeleteEexBlockBid: Löscht ein über seine GUID identifiziertes EEX-Blockangebot aus der Datenbank und gibt den Erfolg der Operation als Objekt
des Typs ReturnCode zurück. Blockangebote können auch gelöscht werden, wenn sich noch EEX-Lieferungen auf sie beziehen.
EEX-Angebote in der Geschäftslogik Die Geschäftslogik befindet sich in
der Klasse EexManager. Die zentralen Methoden zum Zugriff auf EEX-Angebote
werden hier kurz vorgestellt.
• GetAllEexHourBids: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• GetEexHourBid: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
96
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• GetEexHourBidDataSet: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• AddNewEexHourBid: Ruft mit dem übergebenen Stundenangebot als Argument die Methode InsertEexHourBid aus der Datenzugriffsschicht auf
und liefert deren Ergebnis zurück.
• UpdateEexHourBid: Ruft mit dem übergebenen Stundenangebot als Argument die gleichnamige Methode aus der Datenzugriffsschicht auf und
liefert deren Ergebnis zurück.
• DeleteEexHourBid: Ruft mit der übergebenen GUID als Argument die
gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren
Ergebnis zurück.
• GetAllEexBlockBids: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• GetEexBlockBid: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• GetEexBlockBidDataSet: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• AddNewEexBlockBid: Ruft mit dem übergebenen Blockangebot als Argument die Methode InsertEexBlockBid aus der Datenzugriffsschicht auf
und liefert deren Ergebnis zurück.
• UpdateEexBlockBid: Ruft mit dem übergebenen Blockangebot als Argument die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• DeleteEexBlockBid: Ruft mit der übergebenen GUID als Argument die
gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren
Ergebnis zurück.
Stundenangebote in der GUI Für Stundenangebote wurde ein eigenes
GUI-Fenster erstellt (siehe Abbildung 43, das sich öffnet wenn der Benutzer
im EEX-Panel unter der Übersicht der Stundenangebote auf Erstellen oder –
sofern ein Angebot ausgewählt ist – Bearbeiten klickt. Zum Bearbeiten eines
Angebots wird das in der Übersicht ausgewählte dem neuen Panel übergeben
und dessen Daten dort angezeigt. In diesem Panel, das überdies ähnlich aufgebaut ist wie das zugrunde liegende EEX-Formular, lassen sich alle für das
Stundenangebot benötigten Parameter setzen. Diese sind:
• Gültigkeitszeitraum (Jahr und Woche)
• Wochentage
• Korrekturangebot, sind also frühere Versionen vorhanden
• Betroffene Regelzone
97
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 43: Eingabefenster für Stundenangebote
Für die Hauptdaten des Angebots, also wann wieviel Energie geliefert werden
soll, steht eine Tabelle mit insgesamt 18 Spalten und 24 Zeilen zur Verfügung,
die den EEX-Vorgaben entspricht. In den beiden linken Spalten werden die
Stundenintervalle eingetragen, für die die rechts daneben angegebenen Energiemengen ge- oder verkauft werden sollen. Steht links beispielsweise Von 1 bis 1
bedeutet dies, dass die Mengen in derselben Zeile für die erste Stunde des Tages,
also die Zeit von 0:00 Uhr bis 0:59 Uhr gelten. Eine Zeitangabe Von 4 bis 6 steht
für Lieferungen von 4:00 Uhr bis 6:59 Uhr.
Die Mengen, die daneben stehen, sind jeweils bis zu 16 Mengen, die bei verschiedenen Preisen angeboten oder nachgefragt werden. Diese 16 Preise können
über den Button Preise wählen in einem weiteren Fenster gesetzt werden, wobei als Mindestgrenze 0 und als Höchstgrenze 3000 Euro gesetzt wurden. Die
Preisangabe von 0 Euro für die erste Mengenspalte und von 3000 Euro für die
letzte Spalte ist darüber hinaus durch die EEX fest vorgegeben.
Es müssen nicht für jeden Preis Mengen gesetzt werden, aber mindestens eine
Menge für jedes Zeitintervall wird gefordert. Negative Mengen gelten wie bereits
erwähnt als Verkaufs-, nicht-negative Mengen als Kaufwunsch. Die Preise dienen
dabei als Höchstkauf- oder Mindestverkaufspreise für die eingetragen Menge.
Die von der EEX vorgegebene Höchstmenge von 250 MWh wird überwacht,
und erst wenn das Angebot korrekt ausgefüllt ist, wird der Button PDF-Export
freigeschaltet, über den man sich den in Absatz 5.2.2 beschriebenen Report
generieren lassen kann.
Durch einen Klick auf den Speichern-Button wird mit den vorhandenen Daten ein neues EexHourBid-Objekt erzeugt und die Methode AddNewEexHourBid
aus dem Service Access Layer aufgerufen, um das Objekt über den Webservice
in die Datenbank einzufügen. Die übrigen, nicht vom Nutzer einzugebenden
98
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 44: Eingabefenster zur Preissetzung für Stundenangebote
Parameter wie EEX-Zugangsdaten oder Datum des Angebots werden dabei automatisch ermittelt.
Blockangebote in der GUI Die Eingabe von Blockangeboten erfolgt analog
zu Stundenangeboten über einen Klick auf die Buttons Erstellen oder Bearbeiten, woraufhin sich ein neues Fenster öffnet (siehe Abbildung 45), das ggf. mit
den Daten des bereits vorhandenen Blockangebots gefüllt wird. Auch das Design
dieses Panels entspricht der EEX-Vorlage. Die Rahmendaten des Angebots, die
vom Nutzer bereitzustellen sind, sind die folgenden:
• Gültigkeitszeitraum (Jahr und Woche)
• Wochentage
• Korrekturangebot, sind also frühere Versionen vorhanden
Unter dem Bereich für diese Daten folgt ein zweigeteilter Abschnitt, in dem sich
links eine Matrix mit vier Spalten und 15 Zeilen befindet. In jede Zeile kann
dabei ein Kauf- oder Verkaufswunsch eingetragen werden. Dazu muss ein Block
ausgewählt werden, für den dieser gilt, wobei ein Block einen von der EEX vordefinierten Zeitraum beschreibt, von denen insgesamt 12 zur Verfügung stehen.
Ebenso muss in Abweichung von Stundenangeboten für jeden der maximal 15
Wünsche eine Regelzone angegeben werden, aus der die Energie bezogen bzw.
in die sie geliefert werden muss. Pro Kauf- bzw. Verkaufswunsch muss wieder
ein Höchst- bzw. Mindestpreis eingegeben werden. Die Mengenrestriktion von
maximal 250 MWh pro Block wird ebenfalls beachtet. Wenn das Angebot korrekt ausgefüllt ist, wird der Button PDF-Export freigeschaltet, über den man
sich den in Absatz 5.2.2 beschriebenen Report generieren lassen kann.
99
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 45: Eingabefenster für Blockangebote
Indem auf den Button Speichern geklickt wird, erzeugt das Programm ein
neues EexBlockBid-Objekt und füllt es mit den eingegebenen Daten. Die fehlenden Daten wie Datum oder EEX-Zugang werden automatisch ergänzt. Danach
wird die Methode AddNewEexBlockBid mit dem erzeugten Objekt aufgerufen
und dieses dem Server zum Einfügen in die Datenbank übergeben.
5.2.3
Bestätigte Lieferungen
Wenn Teile eines EEX-Angebots von einem anderen Energiehändler akzeptiert
wurden, entstehen daraus neue Lieferverpflichtungen. Diese werden in Objekten
des Typs EexDelivery gespeichert, wobei es unerheblich ist, ob das zugrunde
liegende Angebot, auf das eine Referenz gespeichert wird, ein Block- oder Stundenangebot war. Zu jeder EEX-Lieferung werden neben dem Zeitraum, in dem
sie stattfindet, die konstant zu liefernde Menge in MW, der Preis pro MWh in
Euro sowie die Regelzone und der Bilanzkreis, die Ursprung oder bei Verkäufen
Ziel der Lieferungen sind, vermerkt. Daraus ergibt sich der Datentyp, der in
Abbildung 47 dargestellt ist.
Spezielle EEX-Lieferungen waren im Entwurf ursprünglich nicht vorgesehen,
erwiesen sich aber als sinnvoll, da sie einige Abweichungen von normalen Lieferverträgen aufweisen. Zum einen sind sie mit einem vorher abgegebenen EEXAngebot verbunden und sind stets abgeschlossene Verträge, die Unterscheidung
zwischen von Lieferanten abgegebenen Angeboten und abgeschlossenen Verträgen entfällt also. Außerdem können EEX-Lieferungen von oder zu beliebigen
Händlern erfolgen, auch solchen, die nicht als Lieferanten eingetragen sind. Darüber hinaus besitzen EEX-Lieferungen die eine Mengenbegrenzung. Ansonsten
sind die Formate aber zueinander kompatibel, was die Berechnung von Kaufemp100
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 46: Klasse EexManager
101
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 47: Klasse EexDelivery
fehlungen und aktueller Fehldeckung erleichtert. Zu EEX-Lieferungen, die über
mehrere Tage gehen und dort jeweils nur einzelne Stunden abdecken, müssen
mehrere EexDelivery-Objekte erzeugt werden, die jeweils einen der verschiedenen Lieferzeiträume an den verschiedenen Tagen abdecken, da zwecks Kompatibilität zu normalen Lieferverträgen nur ein konstanter Energiefluss während
der Laufzeit vorgesehen ist.
Abbildung 48: Klasse EexDeliveryDAL
EEX-Lieferungen im Datenzugriff Zum Zugriff auf die Daten der Lieferungen existiert die Klasse EexDeliveryDAL (Abbildung 48), die auf die Datenbanktabelle EexDelivery zugreift, die die EEX-Lieferungen relational abbildet.
Zur Verbindung zwischen EEX-Angebot und zugehöriger Lieferung existiert eine Referenz über die Angebots-GUID. Die Methoden zum Datenzugriff sind die
folgenden:
102
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• CountEexDeliveriesForDay: Bekommt ein DateTime-Objekt übergeben,
zählt auf dieser Grundlage alle EEX-Lieferungen in der Datenbank, die
an diesem Tag für einen beliebigen Zeitraum gelten und gibt das Ergebnis
zurück.
• DeleteEexDelivery: Löscht die EEX-Lieferung mit der übergebenen GUID
aus der Datenbank und gibt mit einem ReturnCode-Objekt den Erfolg der
Operation zurück.
• GetAllEexDeliveries: Liest alle gespeicherten EEX-Lieferungen aus der Datenbank aus und gibt sie als Liste von EexDelivery-Objekten zurück.
• GetEexDelivery: Liefert die zur übergebenen GUID gehörende EEX-Lieferung zurück.
• GetEexDeliveryForSchedule: Bekommt ein DateTime-Objekt übergeben und
extrahiert auf dieser Grundlage alle EEX-Lieferungen aus der Datenbank,
die am besagten Tag für einen beliebigen Zeitraum gelten. Diese Lieferungen werden in einer Liste von EexDelivery-Objekten zurückgegeben.
• InsertEexDelivery: Bekommt eine neue EEX-Lieferung zum Einfügen in
die Datenbank übergeben und gibt über einen ReturnCode das Ergebnis
der Operation zurück.
• UpdateEexDelivery: Bekommt eine bearbeite EEX-Lieferung, mit der ein
vorhandener Datenbankeintrag aktualisiert werden soll, übergeben und
gibt über einen ReturnCode das Ergebnis der Operation zurück.
EEX-Lieferungen in der Geschäftslogik In der Geschäftslogik werden im
wesentlichen durch die Klasse EexManager (siehe Abbildung 46) auf Anfrage
des Webservices die Methoden aus der Datenbanklogik angesprochen und deren
Ergebnis zurückgegeben. Zusätzlich existieren Methoden zur Berechnung geund verkaufter Mengen.
• CountEexDeliveriesForDay: Ruft die gleichnamige Methode aus der Klasse
EexDeliveryDAL auf und liefert deren Ergebnis zurück.
• DeleteEexDelivery: Ruft die gleichnamige Methode aus der Klasse
EexDeliveryDAL auf und liefert deren Ergebnis zurück.
• GetAllEexDeliveries: Ruft die gleichnamige Methode aus der Klasse
EexDeliveryDAL auf und liefert deren Ergebnis zurück.
• GetBoughtEnergyAmount: Berechnet für einen übergebenen Tag (als
DateTime) die Gesamtmenge der über die EEX verkauften Energie in
MWh und liefert das Ergebnis zurück.
• GetEexDelivery: Ruft die gleichnamige Methode aus der Klasse
EexDeliveryDAL auf und liefert deren Ergebnis zurück.
• GetSoldEnergyAmount: Berechnet für einen übergebenen Tag (als
DateTime) die Gesamtmenge der über die EEX verkauften Energie in
MWh und liefert das Ergebnis.
103
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• InsertEexDelivery: Ruft die gleichnamige Methode aus der Klasse
EexDeliveryDAL auf und liefert deren Ergebnis zurück.
• UpdateEexDelivery: Ruft die gleichnamige Methode aus der Klasse
EexDeliveryDAL auf und liefert deren Ergebnis zurück.
Abbildung 49: EEX-Lieferungsübersicht mit Bearbeitungsmöglichkeiten
EEX-Lieferungen in der GUI In der Benutzeroberfläche existiert ein eigenes Panel (Abbildung 49 zur Übersicht über die vorhandenen Lieferungen. In
einer Tabelle werden die wichtigsten Daten aller Lieferungen dargestellt. Jede
Lieferung lässt sich, nachdem sie ausgewählt wurde, über ein Kontextmenü oder
einen Klick auf den Button Markierte bearbeiten editieren. Dann wird das Panel
zum Bearbeiten einer EEX-Lieferung aufgerufen und mit den vorhandenen Daten gefüllt. Nach dem Klick auf Speichern erfolgt die Zuweisung der neuen Daten
an das EexDelivery-Objekt und ein Aufruf der Methode UpdateEexDelivery
mit dem geänderten Objekt. Gelöscht werden EEX-Lieferungen über das Kontextmenü oder einen Klick auf den Button Markierte löschen. Nach einer Sicherheitsabfrage wird die Methode DeleteEexDelivery aufgerufen.
Anlegen lassen sich EEX-Lieferungen nur über das Panel für EEX-Angebote.
Und zwar muss aus den dort vorhandenen Übersichten ein Stunden- bzw. ein
Blockangebot ausgewählt werden, bevor über einen Klick auf Lieferung eingeben das Eingabefenster (siehe Abbildung 50) geöffnet wird. Dies liegt daran,
dass jeder Lieferung ein Angebot zugeordnet werden muss. Nach Eingabe aller
benötigten Daten und deren Validierung wird bei Drücken des Buttons Speichern ein neues EexDelivery-Objekt erzeugt, gefüllt und über die Methode
AddNewEexDelivery an den Webservice zwecks Speicherung übergeben.
104
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 50: Eingabefenster für EEX-Lieferungen
5.2.4
Aktuelle Marktdaten der Energiebörse
Damit der Nutzer bei Erstellung von Angeboten immer einen Überblick hat,
welche Preise für welche Stunden oder Blöcke derzeit zu zahlen sind, werden im
Info-Bereich des Programms stets die aktuellen Strompreise der Energiebörse
für alle Blöcke und sämtliche 24 Stunden eines Tages eingeblendet. Diese Daten
werden von der EEX-Homepage bezogen. Hierzu wurde ein separates Programm
entwickelt, welches taskgesteuert einmal täglich die neu bereitgestellten Daten
der EEX parst und sie in die Datenbank schreibt. Zur Speicherung steht die
Tabelle EexMarketData bereit. Eine gleichnamige Klasse übernimmt die Datenhaltung im Programm (siehe Abbildung 51).
Abbildung 51: Klasse EexMarketData
Die Attribute dieser Klasse, die zur Darstellung der an der EEX gehandelten
Tarife dienen, sind die folgenden:
105
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• Afternoon: Strompreis für den EEX-Block zwischen 14 und 18 Uhr
• Business: Strompreis für den EEX-Block zwischen 8 und 16 Uhr
• Evening: Strompreis für den EEX-Block zwischen 18 und 24 Uhr
• Hours: Array mit Einzelpreisen für die 24 Stunden eines Tages
• Morning: Strompreis für den EEX-Block zwischen 6 und 11 Uhr
• Night: Strompreis für den EEX-Block zwischen 0 und 6 Uhr
• OffPeak1: Strompreis für den EEX-Block zwischen 0 und 8 Uhr
• OffPeak2: Strompreis für den EEX-Block zwischen 20 und 24 Uhr
• PhelixDayBase: Basispreis für normale Stromlieferungen über den ganzen
Tag.
• PhelixDayPeak: Basispreis für Stromlieferungen zur Hochlastzeit zwischen
8 bis 16 Uhr.
• RushHour: Strompreis für den EEX-Block zwischen 16 und 20 Uhr.
Abbildung 52: Klasse EexMarketDataDAL
Marktdaten im Datenzugriff Zur Kommunikation mit der Datenbank steht
die Klasse EexMarketDataDAL zur Verfügung. Sie stellt die folgenden Methoden
bereit:
• CreateEexMarketDataFromDataRow : Erzeugt aus einer ausgelesenen Tabellenzeile ein neues EexMarketData-Objekt und gibt es zurück.
• DeleteEexMarketData: Löscht ein EexMarketData-Objekt aus der Datenbank und liefert über einen ReturnCode den Erfolg dieser Operation zurück.
• GetAllEexMarketData: Liefert alle vorhandenen Datensätze aus der Datenbank als Liste von EexMarketData-Objekten zurück.
106
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• GetEexMarketData: Liefert einen Datensatz als EexMarketData-Objekt
zurück, der entweder eine bestimmte GUID oder ein bestimmtes Gültigkeitsdatum aufweist.
• InsertEexMarketData: Fügt ein übergebenes EexMarketData-Objekt in
die Datenbank ein und gibt den Erfolg der Operation über einen ReturnCode
zurück.
• UpdateEexMarketData: Aktualisiert anhand eines übergebenen
EexMarketData-Objektes den zugehörigen Datensatz in der Datenbank
und gibt den Erfolg der Operation über einen ReturnCode zurück.
Marktdaten in der Geschäftslogik Die Geschäftslogik für EEX-Marktdaten
findet sich in der Klasse EexManager (siehe Abbildung 46). Komplexere Berechnungen finden nicht statt; es werden nur Anfragen an die Datenzugriffslogik
weitergeleitet. Dies geschieht durch die Funktion
• GetEexMarketData: Ruft mit einem übergebenen Datum die gleichnamige
Methode der Klasse EexMarketDataDAL auf und liefert deren Ergebnis
zurück.
Marktdaten in der grafischen Oberfläche Beim Aufruf des Panels für
EEX-Handel durch Klick auf den entsprechenden Menüpunkt in der linken Navigationsleiste wird oberhalb der Navigation ein Fenster eingeblendet, in dem
die aktuellsten von der EEX bezogenen Preise mit den zugehörigen Tarifen eingeblendet werden, sofern Preisdaten in der Datenbank verfügbar sind (siehe
Abbildung 53).
5.2.5
EEX-Parser
Das Programm EEX.exe wird mit einem übergebenen Parameter aufgerufen,
welcher die jeweilige Ausführung des Programms bestimmt. Diese Parameter
sind -f, -a und -n.
Mit eex -f werden die fehlenden Tagesdaten in die Datenbank geschrieben.
Damit sind die Tagesdaten gemeint, die auf der EEX-Seite aktualisiert wurden,
aber sich noch nicht in der Datenbank befinden. Dazu wird die Tagedifferenz
zwischen dem neuesten Eintrag in der Datenbank und dem neuesten Eintrag
auf der EEX-Seite ermittelt. Beträgt diese Differenz zum Beispiel drei Tage,
so werden die letzten drei Einträge von der EEX-Seite in die Datenbank geschrieben. Es können jedoch keine Lücken“ einzelner Tage in der Datenbank
”
gefüllt werden, die jedoch auch niemals auftreten sollten. Dieser Parameter ist
der Standardaufruf des Parsers.
Der Parameter -a schreibt alle acht auf der EEX-Seite angebotenen Tagesmarktdaten in die Datenbank. Er bietet sich für den erstmaligen Eintrag in
eine noch leere Datenbank an. Ansonsten besteht die Gefahr von Redundanzen,
da keine explizite Prüfung erfolgt, ob die Marktdaten eines bestimmten Tages
bereits vorhanden sind.
107
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 53: Fenster für aktuelle Marktdaten
Der letzte Parameter -n schreibt nur den neuesten Tagesdatensatz der EEXSeite in die Datenbank. Er dient in erster Linie rein administrativen Zwecken,
zum Beispiel für Datenbanktests.
Es wurde eine eigenständige GUI entwickelt, die die manuelle Ausführung
des Parsers erleichtert. Sie ist in Abbildung 54 zu sehen. Das Parsen von Webseiten wird auch als scrapen bezeichnet, weshalb auch vom EEX-Scraper die
Rede ist. Die EEX-GUI erlaubt die Auswahl des gewünschten Parameters durch
den Benutzer. Zuvor muss noch der Pfad zu EEX.exe gesetzt werden. Dies geschieht durch den Setzen-Button neben der Pfadangabe. Nach einmaliger Auswahl wird dieser Pfad in der Datei Verzeichnis.txt gespeichert und bei jedem
Programmstart wieder ausgelesen.
Die Aktualisierung der Marktdaten in der Datenbank wird dadurch automatisiert, dass eex.exe -f täglich durch den Taskmanager des Windows-Servers
ausgeführt wird. Da die EEX die Marktdaten täglich zwischen 12:00 und 13:00
Uhr aktualisiert, bietet sich hier 13:05 Uhr als Zeitpunkt für den Aufruf an.
5.2.6
Die Funktionsweise von EEX.exe
Das Programm EEX.exe wird durch die Klasse Program repräsentiert (siehe
Abbildung 55). Die zentralen Methoden zum Programmablauf werden hier kurz
vorgestellt.
• ScrapIt: Liest die angegebene URL (der EEX-Seite) aus und schreibt den
Inhalt in einen String.
108
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 54: Die GUI für den EEX-Scraper
• BeschneideInhalt: schneidet die drei relevanten Info-Bereiche zurecht, bzw.
entfernt die Teile der HTML-Seite, die nicht benötigt werden.
• EntferneHtml: entfernt die HTML-Tags aus dem String, der den Webseiteninhalt speichert.
• Schreibe: schreibt die Marktdaten in eine Textdatei.
• erzeugeMarktdaten: erzeugt aus dem Inhaltstring die Marktdatenobjekte.
• ausfuehren: führt die Methoden BeschneideInhalt, EntferneHtml, Schreibe
und erzeugeMarktdaten in dieser Reihenfolge aus.
• dbEintrag: schreibt die gewünschten Marktdaten in die Datenbank.
• fehlendeTage: Hilfsfunktion, die die Anzahl der fehlenden Tage berechnet.
• verbose: zeigt die Marktdaten im Windows-Eingabefenster an.
• Main: das eigentliche Hauptprogramm, das auch die Parameter entgegennimmt und sie entsprechend auswertet.
5.3
5.3.1
Entscheidungsunterstützung
Lastprognosen
Allgemeines Eine Lastprognose gibt für einen bestimmten Zeitraum in der
Zukunft den erwarteten Energieverbrauch der Kunden des Energiehändlers an.
Jede Lastprognose enthält eine beliebige Anzahl an Lastprofilen, wobei jedes
Lastprofil einen Tag abdeckt. Das Lastprofil ist in Viertelstundenabschnitte unterteilt, denen jeweils die erwartete Energi emenge in MWh zugeordnet ist.
Grundlage jeder Lastprognose sind die Kundenverträge, die mit dem Energiehändler abgeschlossen wurden und sich mit dem Zeitraum der Lastprognose
überschneiden oder komplett in diesen fallen, und deren Lastprofile. Lastprognosen dienen als Grundlage für Kaufempfehlungen.
109
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 55: Die Program-Klasse von EEX.exe
Lastprognosen werden mit Hilfe benutzerdefinierter Algorithmen berechnet,
wozu das Programm ein Plugin-System bereitstellt, das erlaubt, zur Laufzeit
neue Plugins zu laden und zu benutzen. Dieses System wird in Abschnitt 4.2.1
ausführlich erläutert. Die Verwaltung der Lastprognose implementiert die Anwendungsfälle 47 bis 51 des Entwurfs.
Lastprognose als abstrakter Datentyp Die Umsetzung der Lastprognosen
als Datentyp erstreckt sich über zwei Klassen (s. Abb. 56). Alles, was mit den
Zeitreihen der Lastprognose zu tun hat, ist in die Klasse EnergyPredictionTimeSeries ausgelagert. In der Klasse EnergyPrediction werden nur Daten gehalten,
die einmal pro Instanz vorkommen. Dies sind das Erstelldatum der Lastprognose
(Created ), der Geltungszeitraum (begrenzt durch StartDate und EndDate), die
eindeutige ID, eine laufende Nummer sowie ein Infofeld. Außerdem wird ein Konstruktor angeboten und eine Liste von EnergyPredictionTimeSeries-Objekten,
in denen die prognostizierten Verbrauchswerte gespeichert sind.
Dabei steht jedes Objekt in der Liste für die Vorhersage für einen bestimmten
Tag, wobei die Objekte durchgehend vom ersten bis zum letzten Tag der Geltungsdauer geordnet sind. Jedes Objekt vom Typ EnergyPredictionTimeSeries
speichert neben einer eindeutigen ID auch, für welchen Tag es den Energieverbrauch prognostiziert (Feld Day), eine GUID-Referenz zum zugehörigen EnergyPrediction-Objekt und eine Liste mit 96 Energieverbrauchswerten, je einem
für jede Viertelstunde des Tages (zugreifbar über Index this oder Amounts).
Lastprognosen in der Datenbank Beide Klassen, die zur Repräsentation einer Lastprognose dienen, werden in der Datenbank über je eine gleichnamige Tabelle dargestellt. Jedes Attribut der Klassen wird auf eine Spalte der
jeweiligen Tabelle abgebildet, wobei das Array aus der Klasse EnergyPredictionTimeSeries über CSV-Werte ebenfalls in einer Spalte abgelegt wird und
beim Einfügen und Auslesen entsprechend formatiert werden muss. Als Primärschlüssel dienen in beiden Klassen die ID-Felder. Zudem gibt es in der Tabelle
110
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 56: Klassen EnergyPrediction und EnergyPredictionTimeSeries
EnergyPredictionTimeSeries eine Fremdschlüsselbeziehung der Spalte energyPrediction zur Spalte id der Tabelle EnergyPrediction, um so die Zeitreihen mit
der zugehörigen Lastprognose in Verbindung zu bringen.
Abbildung 57: Klasse EnergyPredictionDAL
Lastprognosen im Datenzugriff Der Datenzugriff wird über die statische
Klasse EnergyPredictionDAL realisiert, die die bereits im vorigen Abschnitt angesprochenen statischen Methoden bereitstellt:
• InsertEnergyPrediction: Fügt eine neue Lastprognose in die Datenbank
ein und zeigt über einen booleschen Wert den Erfolg der Aktion an.
• DeleteEnergyPrediction: Löscht eine in der Datenbank gespeicherte Lastprognose und zeigt über einen booleschen Wert den Erfolg der Aktion an.
111
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• IsEnergyPredictionUsed : Überprüft, ob eine Lastprognose noch von Kaufempfehlungen benutzt wird, und gibt das Ergebnis als booleschen Wert
zurück.
• GetEnergyPrediction: Liest eine Lastprognose mit einer übergebenen ID
aus der Datenbank aus und gibt sie zurück.
• GetAllEnergyPredictions: Liest alle Lastprognosen aus der Datenbank aus
und liefert sie als Liste zurück.
Abbildung 58: Klasse EnergyPredictionManager
Lastprognosen in der Geschäftslogik Die Klasse EnergyPredictionManager übernimmt den Umgang mit Lastprognosen in der Geschäftslogik. Weil
keinerlei Algorithmen auf den Lastprofilen ausgeführt werden müssen, erfolgt
lediglich ein Zugriff auf die passenden Methoden der darunterliegenden Datenhaltungsschicht, deren Ergebnisse weitergeleitet und vom Webservice, der die
Methoden dieser Klasse aufruft, als Rückgabewerte verwendet werden. Zu jeder
Methode aus dem Service Access Layer existiert eine bereitgestellte Methode:
• AddNewEnergyPrediction: Ruft mit dem übergebenen EnergyPredictionObjekt die statische Methode InsertEnergyPrediction der Klasse EnergyPredictionDAL auf und gibt deren Ergebnis zurück.
• DeleteEnergyPrediction: Ruft mit der übergebenen ID die statische Methode DeleteEnergyPrediction der Klasse EnergyPredictionDAL auf und
gibt deren Ergebnis zurück.
• IsEnergyPredictionUsed : Ruft mit dem übergebenen EnergyPredictionObjekt die statische Methode IsEnergyPredictionUsed der Klasse EnergyPredictionDAL auf und gibt deren Ergebnis zurück.
• GetEnergyPrediction: Ruft mit dem übergebenen EnergyPrediction-Objekt
die statische Methode InsertEnergyPrediction der Klasse EnergyPredictionDAL auf und gibt deren Ergebnis zurück.
• GetAllEnergyPredictions: Ruft die statische Methode GetAllEnergyPredictions der Klasse EnergyPredictionDAL auf, wandelt deren Ergebnis (eine
Liste mit EnergyPrediction-Objekten) in ein Array um und gibt es zurück.
112
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Lastprognosen in der grafischen Oberfläche Zum Erstellen von Lastprognosen gibt es eine zweigeteilte grafische Oberfläche. Links gibt es die Möglichkeit, Plugins mit Algorithmen auszuwählen. Nachdem ein Algorithmus ausge-
Abbildung 59: GUI zur Erstellung von Lastprognosen
wählt sowie Anfangs- und Enddatum der Lastprognose eingegeben wurden, kann
der Nutzer über den Button Lastprognose konfigurieren die individuellen Parameter des Plugins einstellen und es starten. Anfangs- und Enddatum können
beliebige Zeitspannen abdecken, so dass damit die Anforderungen (vgl. Kapitel 3) an die Laufzeit der Lastprognose (und auch der Kaufempfehlungen, da
Kaufempfehlungen auf Lastprognosen und deren Laufzeit aufbauen) übertroffen
werden.
Die Algorithmen zur Lastprognose Das Energieinformationssystem verfügt bereits über zwei Algorithmen zum Erstellen von Lastprognosen.
• SimplePredictionPlugin: Dies eine ist ein sehr einfacher Algorithmus, der
lediglich die in den Lastprofilen der Kundenverträge angegebenen Werte aufaddiert und danach in der Lastprognose speichert. Für jedes Zeitintervall jedes Tages werden also die Werte aus allen Kundenverträgen,
die während dieses Zeitintervalls gelten, summiert und dann in das entsprechende Zeitintervall der Lastprognose geschrieben. Weitere Parameter
existieren nicht.
• AdvancedPredictionPlugin: Dieser Algorithmus verfährt nach demselben
Prinzip wie der vorige, summiert also auch die Werte auf, allerdings werden
113
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
drei weitere, vom Benutzer vorzugebende Parameter berücksichtigt. Dies
sind:
– Ein fester prozentualer Wert für die Abweichung des Stromverbrauchs
an Wochenenden vom normalen Verbrauch an Werktagen.
– Ein fester prozentualer Wert für die maximale jahreszeitlich bedingte Abweichung des tatsächlichen Stromverbrauchs von den in den
Lastprofilen angegebenen Werten. Diese Abweichung wird über eine
Kosinuskurve repräsentiert, die standardmäßig bei Neujahr ihr Maximum und zur Jahresmitte ihr Minimum erreicht. Dort wird der
Prozentwert voll aufgeschlagen bzw. voll abgezogen.
– Ein weiterer Wert gibt an, um wieviele Tage die Sinuskurve gegenüber
der Standardposition mit den Extrema bei Neujahr und Jahresmitte
verschoben ist. Dieser Parameter ist notwendig, weil normalerweise
die kälteste Zeit des Jahres einige Wochen nach Neujahr und die
heißeste einige Wochen nach der Jahresmitte liegt.
Abbildung 60: GUI zur Konfiguration des AdvancedPredictionPlugin
Beide Algorithmen sind im Projekt PredictionPlugins zusammengefasst und
werden gegen das übrige Projekt zu einer DLL kompiliert. Die zusätzlichen
Parameter des zweiten Algorithmus werden über ein einfaches GUI eingegeben,
das von der Lastprognosenoberfläche aufgerufen wird.
114
EIS - Energie-Informationssystem
5.3.2
Projektgruppe Energie-Informationssyteme
Störungsverwaltung
Allgemeines Störungen werden von den Energielieferanten an die Benutzer
des Energieinformationssystens gemeldet und von diesen in das System eingetragen. Diese Störungen wirken sich dabei auf die laufenden Verträge mit den
Lieferanten aus und werden bei der Erstellung von Lastprognosen und Kaufempfehlungen berücksichtigt. Eine Störung vermindert die Menge der aktuellen
Energielieferung zu einem bestimmten Zeitraum, was zu neuen Berechnungen
des Strombedarfs folgen kann. Die Störungsverwaltung realisiert die Anwendungsfälle 58 bis 62.
Störungen als Datentyp Die Umsetzung der Störungen in einen Datentyp
erfolgt durch die Klasse Disturbances. Sie speichert zur eindeutigen Identifikation eine Guid, den Liefervertrag, auf dem die Störung angewendet wird, den
Repräsentationscode, die voraussichtliche Fehlmenge, die zugehörige, erklärende
Nachricht für die Störung, das Kennzeichen, ob die Störung noch aktuell ist und
den Zeitpunkt, für wann die Störung gültig ist.
Abbildung 61: Klasse Disturbance
Störungen in der Datenbank Die Klasse Disturbance, siehe Abbildung 61,
für die Repräsentation einer Störung wird in der Datenbank über eine gleichnamige Tabelle dargestellt. Jedes Attribut der Klasse wird auf eine Spalte der
jeweiligen Tabelle abgebildet. Als Primärschlüssel dient das ID-Feld. Zudem gibt
es in der Tabelle eine Fremdschlüsselbeziehung der Spalte supplierContract zur
Spalte id der Tabelle SupplierContract, um so die Störungen mit dem zugehörigen Liefervertrag in Verbindung zu bringen.
Störungen im Datenzugriff Der Datenzugriff wird über die statische Klasse DisturbanceDAL, siehe Abbildung 62, realisiert, die die bereits im vorigen
Abschnitt angesprochenen statischen Methoden bereitstellt:
• InsertDisturbance: Fügt eine neue Störung in die Datenbank ein und zeigt
über einen booleschen Wert den Erfolg der Aktion an.
115
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 62: Klasse DisturbanceDAL
• UpdateDisturbance: Aktualisiert eine vorhandene Störung in der Datenbank und zeigt über einen booleschen Wert den Erfolg der Aktion an.
• DeleteDisturbance: Löscht eine in der Datenbank gespeicherte Störung und
zeigt über einen booleschen Wert den Erfolg der Aktion an.
• GetDisturbance: Liest eine Störung mit einer übergebenen ID aus der Datenbank aus und gibt sie zurück.
• GetAllDisturbances: Liest alle Störungen aus der Datenbank aus und liefert sie als Liste zurück.
• GetDisturbancesForContract: Bekommt ein Guid-Objekt übergeben und
liest alle Störungen aus der Datenbank für einen bestimmten Liefervertrag
aus und gibt sie als Liste zurück.
• GetDisturbancesNotCurrent: Liest alle historischen Störungen aus der Datenbank aus und gibt sie als Liste zurück.
• GetDisturbancesByDate: Bekommt ein DateTime-Objekt übergeben und
liest alle Störungen aus der Datenbank zu dem Datum aus und gibt sie
als Liste zurück.
• GetDisturbancesByCode: Bekommt einen Störungscode übergeben, liest
alle Störungen mit diesem Code aus der Datenbank aus und gibt sie als
Liste zurück.
• GetDisturbancesByCompany: Bekommt einen Firmennamen übergeben,
liest alle Störungen für Unternehmen mit diesem Namen aus der Datenbank aus und gibt sie als Liste zurück.
116
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• GetDisturbancesForWorstSuppliers: Liefert eine Liste von Objekten des
Typs FlopDisturbances zurück, in der zu den einzelnen Lieferanten die
jeweilige Anzahl der Störungen aufgelistet sind.
Abbildung 63: Klasse DisturbanceManager
Störungen in der Geschäftslogik Die Klasse DisturbanceManager, Abbildung 63, übernimmt den Umgang mit Störungen in der Geschäftslogik. Weil
keinerlei Algorithmen auf den Störungen ausgeführt werden müssen, erfolgt lediglich ein Zugriff auf die passenden Methoden der darunterliegenden Datenhaltungsschicht, deren Ergebnisse weitergeleitet und vom Webservice, der die
Methoden dieser Klasse aufruft, als Rückgabewerte verwendet werden. Zu jeder
Methode aus dem Service Access Layer existiert eine bereitgestellte Methode:
• AddNewDisturbance: Ruft mit dem übergebenen Disturbance-Objekt die
statische Methode InsertDisturbance der Klasse DisturbanceDAL auf und
gibt deren Ergebnis zurück.
• UpdateDisturbance: Ruft mit dem übergebenen Disturbance-Objekt die
statische Methode UpdateDisturbance der Klasse DisturbanceDAL auf und
gibt deren Ergebnis zurück.
• DeleteDisturbance: Ruft mit der übergebenen ID die statische Methode
DeleteDisturbance der Klasse DisturbanceDAL auf und gibt deren Ergebnis
zurück.
• GetDisturbance: Ruft mit der übergebenen ID die statische Methode GetDisturbance der Klasse DisturbanceDAL auf und gibt deren Ergebnis zurück.
• GetAllDisturbances: Ruft die statische Methode GetAllDisturbance der
Klasse DisturbanceDAL auf, wandelt deren Ergebnis (eine Liste mit Disturbance-Objekten) in ein Array um und gibt es zurück.
117
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• GetDisturbancesForContract: Ruft die statische Methode GetDisturbancesForContract der Klasse DisturbanceDAL auf, wandelt deren Ergebnis
(eine Liste mit Disturbance-Objekten) in ein Array um und gibt es zurück.
• GetDisturbancesNotCurrent: Ruft die statische Methode GetDisturbancesNotCurrent der Klasse DisturbanceDAL auf, wandelt deren Ergebnis (eine
Liste mit Disturbance-Objekten) in ein Array um und gibt es zurück.
• GetDisturbancesByDate: Ruft die statische Methode GetDisturbancesByDate der Klasse DisturbanceDAL auf, wandelt deren Ergebnis (eine Liste
mit Disturbance-Objekten) in ein Array um und gibt es zurück.
• GetDisturbancesByCode: Ruft die statische Methode GetDisturbancesByCode der Klasse DisturbanceDAL auf, wandelt deren Ergebnis (eine Liste
mit Disturbance-Objekten) in ein Array um und gibt es zurück.
• GetDisturbancesByCompany: Ruft die statische Methode GetDisturbancesByCompany der Klasse DisturbanceDAL auf, wandelt deren Ergebnis
(eine Liste mit Disturbance-Objekten) in ein Array um und gibt es zurück.
• GetDisturbancesForWorstSuppliers: Ruft die statische Methode GetDisturbancesForWorstSuppliers der Klasse DisturbanceDAL auf, wandelt deren Ergebnis (eine Liste mit FlopDisturbances-Objekten) in ein Array um
und gibt es zurück.
Abbildung 64: Störungsverwaltung
118
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Störungen in der GUI In der GUI ist die Störungsverwaltung über den
Button Störung im Hauptmenü zu erreichen. Im oberen Hauptmenü werden die
Lieferanten mit den meisten Störungen angezeigt. Das Störungs-Panel (Klasse PanelDisturbance) enthält die Möglichkeit, nach eingetragenen Störungen zu
suchen und diese im Panel anzuzeigen, siehe Abbildung 64. Die Suche kann
nach verschiedenen Kriterien (Historische Störungen, bestimmtes Datum, Meldungscode oder Lieferantenname) durchgeführt werden, wobei eine Anzeige aller
Störungen über den Button Alle anzeigen“ möglich ist. Darunter befinden sich
”
die entsprechenden Schalter für die Funktionen auf Störungsdaten (anlegen, ändern und löschen.
In das Bearbeitungspanel Klasse PanelAddDisturbance, Abbildung 65, gelangt
Abbildung 65: Neue Störung eingeben
man über den Anlegen- oder Bearbeiten-Button. Hier gibt man die neuen, bzw.
ändert die vorhandenen Werte einer Störung. Beide Klassen sind als Windows
Forms angelegt, wobei PanelDisturbance in den Client eingebettet ist, das Panel
zum ändern und anlegen von Störungen wurde als Pop-Up-Fenster implementiert.
Abbildung 66: Liefervertrag auswählen
Im Bearbeitungspanel für Störungen kann ebenfalls ein weiteres Pop-Up
Fenster Klasse PanelSearchSupplierContracts, siehe 66 aufgerufen werden.
119
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Dieses dient zur Auswahl eines Lieferantenvertrags, der zu der aktuellen Störung gehört. In dem Fenster kann über ein Suchfeld nach Lieferantenverträgen
gesucht werden. Der ausgewählte Vertrag wird an das vorige Fenster übergeben.
5.3.3
Kaufempfehlungen
Allgemeines Kaufempfehlungen sind eine Zusammenstellung von Lieferangeboten, die den erwarteten Energiebedarf möglichst präzise deckt. Der erwartete
Energiebedarf wird durch eine oben beschriebene Lastprognose repräsentiert.
Die Berechnung erfolgt serverseitig über das Plugin-System. Ein genetischer
Algorithmus wird mitgeliefert. Hier werden die Anwendungsfälle 52 bis 57 umgesetzt.
Abbildung 67: Klasse Recommendation
Kaufempfehlungen als Datentyp Die Umsetzung der Kaufempfehlungen
in einen Datentyp erfolgt durch die Klasse Recommendation (siehe Abbildung
67). Sie speichert zur eindeutigen Identifikation eine Guid, die Lastprognose,
auf der die Empfehlung basiert, das Erstellungsdatum, den durch Start- und
Enddatum bestimmten Gültigkeitszeitraum, die benötigte und die durch die
vorgeschlagenen Angebote gedeckte Energiemenge, eine laufende Nummer, den
Namen des verwendeten Algorithmus und eine Liste mit den empfohlenden Lieferverträgen.
Darüber hinaus gibt es noch die Klasse RecommendationInfo, die nur die
wichtigsten Informationen einer Kaufempfehlung enthält und bei Übersichten
zwecks Reduzierung der zu übertragenden Datenmenge eingesetzt wird.
Kaufempfehlungen im Datenzugriff Kaufempfehlungen werden in der Tabelle Recommendation gespeichert, von der aus eine Fremdschlüsselbeziehung
120
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 68: Klasse RecommendationDAL
zur Tabelle EnergyPrediction besteht, da jede Kaufempfehlung auf einer Lastprognose beruht. Zum Zugriff auf diese Datensätze steht die Klasse
RecommendationDAL bereit (siehe Abbildung 68). Diese beinhaltet folgende Methoden:
• CreateRecommendationFromDataRow : Erzeugt aus einem aus der Datenbank ausgelesenen Datensatz ein neues Recommendation-Objekt und gibt
es zurück.
• CreateRecommendationInfoFromDataRow : Erzeugt aus einem aus der Datenbank ausgelesenen Datensatz ein neues RecommendationInfo-Objekt
und gibt es zurück.
• DeleteAllRecommendations: Löscht alle gespeicherten Kaufempfehlungen
aus der Datenbank und gibt das Ergebnis der Operation als ReturnCodeObjekt zurück.
• DeleteRecommendation: Löscht die Kaufempfehlung mit einer bestimmten GUID aus der Datenbank und gibt den Erfolg der Operation als
ReturnCode-Objekt zurück.
• GetAllRecommendationInfos: Liefert alle gespeicherten Kaufempfehlungen in Form vereinfachter RecommendationInfo-Objekte zurück.
• GetAllRecommendations: Liefert alle gespeicherten Kaufempfehlungen in
Form von Recommendation-Objekten zurück.
• GetRecommendation: Liefert eine Kaufempfehlung mit einer bestimmten
GUID zurück.
• GetSupplierContractsForRecommendation: Liefert anhand des Zeitraums,
für den eine Kaufempfehlung erstellt werden soll, alle Lieferverträge als
Liste von SupplierContract-Objekten zurück, die in diesem Zeitraum gelten.
121
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• InsertRecommendation: Fügt ein übergebenes Recommendation-Objekt in
die Datenbank ein und gibt das Ergebnis der Operation über ein ReturnCodeObjekt zurück. UpdateRecommendation: Aktualisiert eine bereits gespeicherte Kaufempfehlung mit den Daten des übergebenen RecommendationObjekts und liefert das Ergebnis der Operaiton als ReturnCode zurück.
Abbildung 69: Klasse RecommendationManager
Kaufempfehlungen in der Geschäftslogik Die Klasse
RecommendationManager enthält die Methoden zum Umgang mit Kaufempfehlungen. Die Logik zur Berechnung der Kaufempfehlungen befindet sich in den
Plugins, die von anderen Programmierern bereitgestellt werden müssen. Wie
diese zu implementieren sind, ist in Abschnitt über das Pluginsystem nachzulesen (4.2.1). Ein genetischer Algorithmus wurde als Beispiel implementiert und
wird in Abschnitt 5.3.3 beschrieben. In der Geschäftslogik verbleiben daher nur
die folgenden Methoden:
• AddNewRecommendationRuft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• CalculateAvailableEnergy: Berechnet zu einer bereits erstellten Kaufempfehlung, wieviel Energie für den gesamten Zeitraum benötigt wird, um den
Bedarf aller Kunden hundertprozentig zu decken und gibt diesen Wert zurück.
• CalculateNeededEnergy: Berechnet zu einer bereits erstellten Kaufempfehlung, wieviel Energie für den gesamten Zeitraum aufgrund der abgeschlossenen Verträge zur Verfügung steht und gibt diesen Wert zurück.
• DeleteAllRecommendations: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert den Erfolg der Operation als ReturnCode
zurück.
122
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• DeleteRecommendation: Ruft mit der übergebenen GUID die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert den Erfolg der
Operation als ReturnCode zurück.
• GetAllRecommendationInfos: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• GetAllRecommendations: Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• GetRecommendation: Ruft mit der übergebenen GUID die gleichnamige
Methode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zurück.
• RealizeRecommendation: Ruft in der Datenbankzugriffsschicht die Methoden zum Speichern der übergebenen fertigen Kaufempfehlung auf und
sorgt dafür, dass sämtliche ausgewählten Lieferangebote als Verträge abgeschlossen werden. Ein zurückgegebener ReturnCode gibt Auskunft über
den Erfolg der Operation.
• UpdateRecommendation Ruft die gleichnamige Methode aus der Datenzugriffsschicht auf und liefert den Erfolg der Operation als ReturnCode
zurück.
Erstellung von Kaufempfehlungen Die folgenden zwei Abschnitte beschreiben, wie ein Nutzer die Funktionen zum Erstellen von Kaufempfehlungen benutzen kann und wie der mitgelieferte Algorithmus arbeitet.
Kaufempfehlungen in der grafischen Oberfläche Die grafische Oberfläche für Kaufempfehlungen wurde als sechsteiliger Wizard realisiert. Im ersten
Schritt muss aus den vorhadenen Lastprognosen (angezeigt werden der Übersicht halber nur die aktuellen) eine als Grundlage der Kaufempfehlung ausgewählt werden.
Dann wird eine Liste aller noch nicht abgeschlossenen Angebote, die teilweise
oder ganz in den Zeitraum der gewählten Lastprognose fallen, gezeigt. (Zeitraum
der Lastprognose und der zu erstellenden Kaufempfehlung sind identisch.) Zu
jedem Angebot kann der Nutzer auswählen, ob es auf jeden Fall, gar nicht oder
nur, wenn der Algorithmus zur Berechnung der Kaufempfehlung es für sinnvoll
erachtet, in die Kaufempfehlung aufgenommen werden soll.
Der dritte Schritt zeigt eine Liste aller verfügbaren Algorithmen – auch hier
kam das Plugin-System zum Einsatz – für die Kaufempfehlungserstellung an
und liefert zu jedem eine kurze Erläuterung, sofern die Programmierer diese
angegeben haben.
Schritt vier dient zur Konfiguration des Algorithmus. In der Regel werden zusätzliche, vom Benutzer einzugebende Parameter benötigt, die über eine HTMLOberfläche innerhalb eines Browser-Fensters abgefragt werden, bevor ein Klick
auf Start die Berechnung anstößt.
Nach der Berechnung, die einige Sekunden dauern kann, werden in zwei
Übersichten die vom Algorithmus zum Abschluss empfohlenen Angebote sowie
123
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 70: Auswahl der zu verwendenden Lastprognose
Abbildung 71: Zu berücksichtigenden Lieferverträge und -angebote
124
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 72: Auswahl des Kaufempfehlungs-Algorithmus
Abbildung 73: Konfiguration des Kaufempfehlungs-Algorithmus
125
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
die ohnehin für den Kaufempfehlungszeitraum bereits abgeschlossenen Verträge
angezeigt.
Abbildung 74: Ergebnis der Berechnung
Im letzten Schritt kann die Kaufempfehlung noch manuell nachbearbeitet
werden. Der Nutzer kann empfohlene Angebote aussortieren und andere, vom
Algorithmus nicht berücksichtigte Angebote, hinzufügen. Schließlich wird die
Kaufempfehlung durch einen Klick auf den entsprechenden Button umgesetzt
und gespeichert und damit alle berücksichtigten Angebote angenommen, also in
Verträge umgewandelt.
Genetischer Algorithmus für Kaufempfehlungen Zur Generierung
von Kaufempfehlungen stellt das EIS einen als Plugin (näheres zum Pluginsystem siehe Abschnitt 4.2.1) genetischen Algorithmus zur Verfügung, der gemäß
der Evolutionsstrategie [Rec94] versucht, ein möglichst nah am Optimum liegendes, heuristisches Ergebnis zu erzielen. Gegenstand der Berechnungen sind
dabei Lieferangebote, die in den Zeitraum einer Kaufempfehlung fallen. Aus allen verfügbaren Angeboten erzeugt der Algorithmus eine Menge von Angeboten,
die sowohl möglichst gut den Energiebedarf für den Zeitraum der Kaufempfehlung, der in der zugrundeliegenden Lastprognose ermittelt wurde, decken und
gleichzeitig möglichst kostengünstig abgeschlossen werden können.
Vom Benutzer sind zur Konfiguration des Algorithmus vier Parameter zu
setzen:
126
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 75: Nachbearbeitung der Kaufempfehlung
Abbildung 76: Schematischer Ablauf der Evolutionsstrategie
127
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• Die Größe der initialen Population, also wie groß die Teilmenge aller möglichen Lösungen sein soll, die zu Beginn der Berechnung erstellt wird.
• Die Anzahl der aus der Population zu erzeugenden Generationen. Sie gibt
an, wie viele verschiedene Lösungsvorschläge aus der initialen Population
generiert werden sollen. Das Erreichen der maximalen Generationenanzahl
ist zugleich die Abbruchbedingung für den Algorithmus.
• Ein gewünschter Preis, der als vorzeitige Abbruchbedingung für den Algorithmus benutzt wird. Unterschreitet ein Kandidat den an dieser Stelle
eingetragenen Wert, so bricht der Algorithmus ab und stellt das Ergebnis
dar.
• Die Option einen Mehreinkauf zuzulassen. Ist diese Checkbox gesetzt so
wird der Zeitraum eines Liefervertrags, der über den Zeitraum der Lastprognose, und damit den eigentlichen Planungszeitraum hinausgeht, nicht
negativ bewertet. Dadurch wird die Möglichkeit des Kaufes eines langfristigen Vertrages zu wahrscheinlich günstigeren Konditionen ermöglicht.
Der Algorithmus läuft nach Eingabe dieser Parameter wie folgt ab:
1. Initialisierung Lieferangebote, die der Benutzer unbedingt haben möchte,
werden als gesetzt behandelt und die von ihnen kompensierte Energiemenge vom gesamten Bedarf subtrahiert. Als initiale Population der Größe n
werden n Lösungskandidaten, also Listen zum Abschluss vorgeschlagener
Lieferangebote, zufällig aus den optional vorzuschlagenden Angeboten erstellt. Kandidaten, die den Energiebedarf nicht decken, werden nicht berücksichtigt. Nun werden nacheinander die m Generationen erstellt. Für
die erste Generation wird die initiale Population verwendet.
2. Evaluierung Für die einzelnen Lösungskandidaten der Population wird
nun die Fitness berechnet, also ein Double-Wert, der angibt, wie gut ein
Kandidat den beiden Optimierungskriterien (Deckung des Strombedarfs
und möglichst geringe Kosten) entspricht. Je kleiner der Fitnesswert dabei ist, desto besser werden die Kriterien erfüllt. Dazu werden die Gesamtpreise der Lieferverträge errechnet und aufaddiert. Die Berechnung
des durch die Stromlieferung beigesteuerten Teils des Fitnesswertes verläuft etwas anders. Hier wird zunächst die durch die Lieferverträge während des Kaufempfehlungszeitraums verursachte Überdeckung erfasst. Anschließend wird die vor und nach besagtem Zeitraum anfallende Energiemenge bestimmt. Beides fließt negativ in die Bewertung ein. Einzige
Ausnahme bildet hierbei der Zeitraum der über den eigentlichen PLanungszeitraum hinausgeht. Für diesen kann mittels der Option Mehrkauf
zulassen eine negative Berwertung ein- oder ausgestellt werden.
3. Selektion Nach der Fitnessberechung werden die Lösungskandidaten sortiert und der fitteste Kandidat einer Liste zugewiesen, die eine engere
Auswahl an Vorschlägen enthält. Zuvor wird versucht, diesen Kandidaten
weiter zu optimieren, indem Lieferangebote entfernt werden und überprüft
wird, ob nach wie vor der Energiebedarf gedeckt wird.
128
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
4. Rekombination Nun ist die Berechnung einer Generation abgeschlossen.
Für die nächste Generation wird eine neue Population benötigt, die aus
Veränderung der bestehenden hervorgeht. Dies geschieht durch Kreuzen
und Mutieren der besten Kandidaten der vorhergehenden Population.
• Beim Kreuzen werden zwei Lösungskandidaten einer Funktion übergeben, die aus diesen Kandidaten zwei neue erstellt und zurückliefert,
indem die erste Hälften der in diesen Kandidaten gespeicherten Vertragslisten in den ersten neuen Kandidaten übertragen werden und
die zweiten Hälften in den zweiten neuen.
• Beim Mutieren hingegen wird eine zufällige Anzahl an Lieferverträgen aus der Vertragsliste durch andere ebenfalls zufälligbestimmte
Lieferverträge ausgetauscht.
5. Ergebnis Dieser Kreislauf aus Evaluierung, Selektion und Rekombination setzt sich fort, bis die maximale Anzahl an Generationen erreicht ist
oder der vom Benutzer eingegebene gewünschte Preis unterschritten wurde. Aus der danach m Kandidaten umfassenden engeren Auswahl wird
derjenige mit dem besten, also geringsten Fitnesswert ausgewählt und zurückgegeben.
5.4
Fahrpläne
Fahrpläne sind das wichtigste Endprodukt, das aus dem Einsatz des Energieinformationssystems resultiert, da ohne sie die gesamte Stromversorgung auf
dem liberalisierten, nicht mehr staatsmonopolistisch organisierten Energiemarkt
nicht funktionieren würde.
Allgemeines zum Fahrplankonzept Damit die Kraftwerksbetreiber, die
über ein Regelzonen identifiziert werden, wissen, wann sie welche Energiemengen
bereitstellen müssen, brauchen sie detaillierte Informationen über den Bedarf
der verschiedenen Stromanbieter, die sich den Kraftwerksbetreibern gegenüber
durch Angabe eines ihnen zugeordneten Bilanzkreises ausweisen. Dies gilt auch
für solche Stromhändler, die nur aus spekulativen Gründen kaufen und verkaufen
und selbst gar keine Kunden haben, die mit Energie versorgt werden müssen.
Jeden Tag bis 14 Uhr müssen die einzelnen Stromhändler jedem von ihren
Transaktionen betroffenen Kraftwerksbetreiber sogenannte Fahrpläne vorlegen,
die in Viertelstundenintervallen den Stromverbrauch angeben. Dabei wird zusätzlich bei jedem Fahrplan für einen Kraftwerksbetreiber nach Bilanzkreisen
unterschieden. Fahrpläne können dabei gegebenenfalls auch nachträglich korrigiert werden.
Die Fahrpläne werden seit einigen Jahren im sogenannten ESS -Format zwischen den Betroffenen ausgetauscht. Das ESS, englisch für ETSO Scheduling
System wurde von der ETSO standardisiert und ist XML-basiert. Insgesamt
besteht das Fahrplanmanagement aus vier Teilen:
• der eigentlichen Fahrplannachricht (Schedule Planning Message),
• der Empfangsbestätigung (Acknowledgement Message),
129
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• der Fehlernachricht (Anomaly Report) und
• der endgültigen Fahrplanbestätigung (Confirmation Report).
Implementierte Komponenten im EIS Von den oben genannten vier Bestandteilen des Fahrplanmanagements wurde im EIS nur die wichtigste verwirklicht, nämlich die Fahrplannachricht. Die anderen drei XML-Nachrichten wurden aus Zeitgründen nicht berücksichtigt. Die hier beschriebenen Funktionen
entsprechen den Anwendungsfällen 64 bis 71 aus dem Zwischenbericht.
Fahrpläne können von ausreichend mit Rechten ausgestatteten Nutzern erstellt und gelöscht, jedoch nicht bearbeitet werden werden. Falls ein Fahrplan
sich im Nachhinein als unvollständig herausstellen sollte – etwa weil kurzfristig
neue Lieferverträge hinzugekommen sind –, muss ein komplett neuer Fahrplan
für den betreffenden Tag erstellt werden, der automatisch eine neue Versionsnummer erhält. Eine manuelle Bearbeitung von Fahrplänen wurde nicht erlaubt,
da das Format sonst zu leicht mit Fehlern durchsetzt würde. Alle benötigten Informationen, also Lieferanten und Lieferverträge, sind zur Zeit der Erstellung
eines Fahrplans bereits im System gespeichert und werden dementsprechend
automatisch extrahiert und zur Berechnung der Strommengen herangezogen.
Die im EIS implementierte Version der Fahrplannachricht entspricht Version
2, Release 3, die zu Beginn der Programmierarbeiten (Februar 2006) aktuell war.
Inzwischen (Juli 2006) wurde Version 3, Release 0 veröffentlicht, die im Rahmen
der Projektgruppe aber keine Berücksichtigung mehr finden konnte.
Fahrpläne als Datentyp Ein Fahrplan besteht aus zahlreichen administrativen Angaben, die etwa die Version des Fahrplans oder seinen Empfänger beinhalten. Diese Informationen sind in der Klasse Schedule gespeichert. Außerdem
existiert pro Fahrplan eine beliebige Anzahl an Zeitschemata. Jedes Schema enthält neben weiteren administrativen Daten 96 Viertelstundenintervalle mit Verbrauchswerten, die einen kompletten Tag abdecken. Diese Datenstruktur wird
über die Klasse ScheduleTimeSeries repräsentiert, die zur Realisierung der 1n-Beziehung von der Klasse Schedule referenziert wird. Abbildung 77 zeigt eine
Übersicht über beide Klassen.
Im folgenden werden die für Fahrpläne benötigten administrativen Daten
näher erläutert und beschrieben, wie sie vom System behandelt werden. Eine ausführliche Beschreibung findet sich in den Dokumenten der ETSO (siehe
[Ope03]).
• Attribute eines Fahrplans:
– ClassificationType: Wird gesetzt, um die Art des Fahrplans gegenüber
den anderen ETSO-Teilnehmern zu markieren. Wird stets auf den
Code für Energieaustausch gesetzt.
– Day: Der Tag, für den der Fahrplan gilt.
– Filename: Der von der ETSO vorgegebene Dateiname, der ebenfalls
in der XML-Datei gespeichert wird.
– Id: Eine eindeutige Identifikationsnummer des Fahrplans. Das System
erzeugt hierzu eine GUID.
130
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 77: Klassen Schedule und ScheduleTimeSeries
– MessageDateAndTime: Das Datum, an dem der Fahrplan erstellt
wurde.
– MessageId: Eine eindeutige Identifikationsnummer des Fahrplans, die
in allen Versionen dieses Fahrplans gleich bleibt. Das System erzeugt
hierzu eine GUID.
– MessageType: Der Typ des Fahrplans. Wird vom System auf den
vordefinierten Wert für bilanzwirksame Fahrpläne gesetzt.
– MessageVersion: Die Version des Fahrplans. Wird vom System als
aufsteigende Reihe, beginnend mit 1, behandelt.
– ProcessType: Der Vorgang, der durch den Fahrplan beschrieben wird.
Das System benutzt hier stets den Wert für zukünftige, so genannte
Day-ahead -Fahrpläne.
– ReceiverCodingScheme: Gibt an, wie die ID des Empfängers codiert
ist. Das System zeigt hier eine Codierung als EIC an.
– ReceiverId: Die eindeutige Identifikation des Empfängers.
– ReceiverRole: Zeigt über einen ETSO-Code an, welche Funktion der
Empfänger des Fahrplans einnimmt.
– SenderCodingScheme: Gibt an, wie die ID des Senders codiert ist.
Das System zeigt hier eine Codierung als EIC an.
131
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
– SenderId: Die eindeutige Identifikation des Senders.
– SenderRole: Zeigt über einen ETSO-Code an, welche Funktion der
Sender des Fahrplans einnimmt.
– Timespan: Die genaue Zeitspanne, in der der Fahrplan gilt.
• Attribute eines Fahrplanzeitschemas:
– AccountingAreaIn: Enthält den EIC des Bilanzkreises, in den der
Strom geliefert wird.
– AccountingAreaInCodingScheme: Enthält das Schema, mit dem der
Bilanzkreis des Stromempfängers in der XML-Datei codiert ist. Wird
vom System auf die Konstante für EICs gesetzt.
– AccountingAreaOut: Enthält den EIC des Bilanzkreises, aus dem der
Strom transferiert wird.
– AccountingAreaOutCodingScheme: Enthält das Schema, mit dem der
Bilanzkreis des Stromsenders in der XML-Datei codiert ist. Wird vom
System auf die Konstante für EICs gesetzt.
– Aggregation: Zeigt an, für welchen Bereich die Energietransfers aggregiert sind. Wird vom Programm stets auf den ESTO-Code für
Regelzonen gesetzt.
– Agreement: Wird in der vorhandenen Implementierung nicht benötigt
und daher nicht gesetzt.
– Amounts: Die eigentliche Zeitreihe als Array von 96 Werten, einer
für jede Viertelstunde des Tages. Hier werden die vom Fahrplanerstellungsalgorithmus ermittelten Werte gespeichert.
– BusinessType: Gibt die Art des Geschäfts an. Wird vom Programm
auf den Wert für Energieverbrauch gesetzt, da mit der gelieferten
Energie Kunden bedient werden.
– ContractType: Gibt die Art der Lieferung an. Die vom System generierten Fahrpläne werden dabei stets als Transaktionen für einen Tag
klassifiziert.
– ControlAreaIn: Enthält den EIC des Bilanzkreises, in den der Strom
geliefert wird.
– ControlAreaInCodingScheme: Enthält das Schema, mit dem der Bilanzkreis des Stromempfängers in der XML-Datei codiert ist. Wird
vom System auf die Konstante für EICs gesetzt.
– ControlAreaOut: Enthält den EIC des Bilanzkreises, aus dem der
Strom transferiert wird.
– ControlAreaOutCodingScheme: Enthält das Schema, mit dem der Bilanzkreis des Stromsenders in der XML-Datei codiert ist. Wird vom
System auf die Konstante für EICs gesetzt.
– Id: Eine eindeutige GUID, mit der dieses Zeitschema identifiziert werden.
– MeasurementUnit: Gibt die Maßeinheit für die Energie in den Zeitintervallen an. Wird auf den ETSO-Standardwert für Megawattstunden
gesetzt.
132
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
– MeteringPoint: Wird in der vorhandenen Implementierung nicht benötigt und daher nicht gesetzt.
– MeteringPointCodingScheme: Wird in der vorhandenen Implementierung nicht benötigt und daher nicht gesetzt.
– Product: Die Art der gelieferten Energie. Wird auf den ETSO-Code
für aktive Energie gesetzt.
– Resolution: Zeigt die Dauer der Zeitintervalle. Dieser Wert wird auf
die ETSO-Konstante für 15-minütige Intervalle gesetzt.
– Schedule: Enthält eine Referenz auf das zugrunde liegende ScheduleObjekt.
– TimeInterval: Gibt an, wie lange die einzelnen Zeitintervalle des Schemas dauern. Wird vom Programm auf den ETSO-Standardwert von
15 Minuten gesetzt.
– TimeSeriesIdentification: Die eindeutige Identifikationsnummer des
Zeitschemas. Bleibt bei verschiedenen Versionen des Zeitschemas gleich.
– Version: Die Version des Zeitschemas. Wird vom System als laufende
Nummer, beginnend mit 1, behandelt.
Abbildung 78: Klasse ScheduleDAL
Fahrpläne im Datenzugriff Der Datenzugriff erfolgt über die Klasse
ScheduleDAL. Sie schreibt und liest Fahrpläne in die bzw. aus den zugehörigen
Datenbanktabellen Schedule und ScheduleTimeSeries, die jeweils die gleichnamige Datenhaltungsklasse abdecken. Die einzelnen Methoden sind:
• CalculateMessageVersion: Berechnet anhand der Anzahl der in der Datenbank vorhandenen Einträge ein und derselben Fahrplannachricht die
Version der zu erzeugenden nächsten Fahrplanversion und liefert sie zurück.
133
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• CalculateTimeSeriesVersion: Berechnet anhand der Anzahl der in der Datenbank vorhandenen Einträge ein und desselben Fahrplanzeitschemas die
Version der zu erzeugenden nächsten Zeitschemaversion und liefert sie zurück.
• CountSchedulesForDay: Zählt die für einen bestimmten Tag erzeugten
Fahrpläne (Anzahl Dateien) und liefert das Ergebnis zurück.
• CreateScheduleFromDataRow : Erzeugt aus einem aus der Datenbank ausgelesenen Datensatz ein neues Schedule-Objekt mit zugehörigen
ScheduleTimeSeries-Instanzen und liefert es zurück.
• DeleteAllSchedules: Löscht alle bislang erzeugten Fahrpläne aus der Datenbank und gibt als Ergebnis ein ReturnCode-Objekt zurück, das den
Ausgang der Operation beschreibt. Die zugehörigen XML-Dateien werden
nicht gelöscht, da der Nutzer diese speichern kann, wo er möchte, und diese
Orte dem System nicht bekannt sind.
• DeleteSchedule: Löscht anhand einer übergebenen GUID einen bestimmten Fahrplan aus der Datenbank und gibt als Ergebnis ein ReturnCodeObjekt zurück, das den Ausgang der Operation beschreibt. Die zugehörigen XML-Dateien werden nicht gelöscht, da der Nutzer diese speichern
kann, wo er möchte, und diese Orte dem System nicht bekannt sind.
• DeleteSchedulesForDay: Löscht alle für einen bestimmten Tag erzeugten
Fahrpläne aus der Datenbank und gibt als Ergebnis ein ReturnCodeObjekt zurück, das den Ausgang der Operation beschreibt. Die zugehörigen XML-Dateien werden nicht gelöscht, da der Nutzer diese speichern
kann, wo er möchte, und diese Orte dem System nicht bekannt sind.
• GetAllSchedules: Liest alle vorhandenen Fahrplandatensätze aus der Datenbank aus und liefert sie als Liste von Schedule-Objekten zurück.
• GetMessageId : Bekommt ein DateTime-Objekt sowie einen EIC als Empfängerkennung übergeben und liefert anhand dieser Daten die ID der Fahrplannachricht (nicht die des Fahrplandatensatzes) zurück, die an diesem
Tag für den übergebenen Empfänger gilt.
• GetSchedule: Liefert aus der Datenbank ein Schedule-Objekt mit einer
bestimmten ID zurück.
• GetScheduleTimeSeriesForSchedule: Liest die Datensätze von Fahrplanzeitschemata, die zu einem bestimmten Fahrplan gehören, aus der Datenbank aus und gibt sie als Liste von ScheduleTimeSeries-Objekten
zurück.
• InsertSchedule: Bekommt ein Schedule-Objekt übergeben, fügt es in die
Datenbank ein und gibt den Erfolg der Operation als ReturnCode-Objekt
codiert zurück.
• UpdateSchedule: Bekommt ein Schedule-Objekt übergeben, aktualisiert
mit seinen Daten den Datensatz mit derselben ID und gibt den Erfolg der
Operation als ReturnCode-Objekt codiert zurück.
134
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 79: Klasse ScheduleManager
Fahrpläne in der Geschäftslogik Die Geschäftslogik für Fahrpläne und
damit auch die Erstellung von Fahrplänen, eine der Hauptfunktionen des Programms, befindet sich in der Klasse ScheduleManager. Ein Überblick über ihre Methoden ist in Abbildung 79 zu sehen. Die Methoden, deren Name mit
Write beginnt, dienen allesamt dazu, die erstellten Schedule-Objekte in XMLFahrplandateien gemäß ESS-Format zu transformieren. Die Fahrplanerstellung
läuft dabei wie folgt ab:
• Der Benutzer muss vor der Erstellung zunächst eingeben, welchen Bilanzkreis er durch seine Firma vertritt und für welchen Netzbetreiber, also
für welche Regelzone der Fahrplan ist. Ein Datum, für das der Fahrplan
gelten soll, ist ebenfalls notwendig.
• Anschließend beginnt der Erstellungsprozess. Es wird dabei eine XMLDatei gemäß ESS erstellt, die alle Transaktionen enthält, die zwecks Versorgung der Stromkunden des Händlers anfallen. In der Regel handelt es
sich um Lieferungen in die Regelzone des Händlers, die von anderen Bilanzkreisen, also Stromanbietern, kommen. Es ist aber auch möglich, dass
die Lieferungen aus der Regelzone des Händlers kommen, wenn Überschußenergie veräußert wird. Für jede durch Lieferverträge oder EEXLieferungen auftretende Kombinationen von Regelzonen und Bilanzkreisen, die an Transaktionen beteiligt sind, wird ein eigenes Zeitschema im
Fahrplan angelegt. Sind noch andere Regelzonen als die des Händlers an
135
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
den Transaktionen beteiligt, wird für jede dieser Regelzonen eine weitere
Fahrplandatei in XML erzeugt, die dann jeweils die Transaktionen zwischen dem Händler und der betroffenen Regelzone auflistet.
• Um diese Dateien erstellen zu können, werden zunächst über die Methoden
GetSupplierContractsForSchedule und GetEexDeliveriesForSchedule
sämtliche abgeschlossenen Lieferverträge und EEX-Lieferungen ausgelesen, die an dem Tag, für den der Fahrplan gemacht wird, gelten.
• Anschließend werden Lieferungen und Verträge zuerst nach Regelzonen
und dann innerhalb dieser Aufteilung nach Bilanzkreisen geordnet, sodass die jeweiligen Listen bereits in der richtigen Sortierung für die verschiedenen zu erstellenden Fahrplanobjekte und zugehörigen Zeitreihen
vorliegen. Das Sortieren nach Regelzonen geschieht über die Methoden
GetContractsForControlArea und GetDeliveriesForControlArea. Die
Sortierung nach Bilanzkreisen erfolgt durch Aufruf von SortContractsBy
AccountingAreas und SortDeliveriesByAccountingAreas. Zuvor werden Listen aller beteiligten Regelzonen und Bilanzkreise über die Methoden GetAccountingAreasInvolved und GetControlAreasInvolved erstellt.
• Nun wird für jede Regelzone über die Methode ein neues Schedule-Objekt
erzeugt und mit den von der ETSO vorgegebenen administrativen Daten
gefüllt.
• Dann wird für jeden Bilanzkreis, der in der sortieren Liste für diese Regelzone aufgeführt ist, ein Zeitschema als ScheduleTimeSeries-Objekt
erstellt und gefüllt.
• Um die Verbrauchsmengen je Zeitreihe zu berechnen, wird die Methode
AggregateAmounts aufgerufen. Hier wird zunächst zu jedem Liefervertrag
überprüft, ob noch aktuelle Störungen dazu existieren, deren Menge dann
ggf. von der zu liefernden Menge abgezogen wird. Dann werden für alle
EEX-Lieferungen und Lieferverträge, die zu ein und derselben Kombination von Bilanzkreisen und Regelzonen gehören, die Liefermengen für alle
Viertelstundenintervalle aufaddiert.
• Falls dabei durch Verkäufe an die EEX negative Mengen zustande kommt,
was über die Methode HasNegativeAmounts abgefragt wird, müssen die
negativen Werte in eine eigene Zeitreihe mit vertauschten Regelzonen und
Bilanzkreisen und umgekehrten Vorzeichen ausgelagert werden. Das liegt
daran, dass die ETSO im ESS-Format nur nicht-negative Energiewerte vorsieht. Das Aufteilen des Zeitschemas geschieht über die Methode
SplitTimeSeries.
• Damit ist die inhaltliche Erstellung der Fahrpläne abgeschlossen, und die
erzeugten Objekte werden über Aufrufe der verschiedenen Write-Methoden
in ESS-konforme XML-Dateien transformiert. Die Daten der Fahrpläne
werden in der Datenbank gespeichert.
Die übrigen Methoden der Klasse ScheduleManager funktionieren wie folgt:
136
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• DeleteAllSchedules: Ruft die gleichnamige Methode der Klasse
ScheduleDAL auf gibt als Ergebnis ein ReturnCode-Objekt zurück, das
den Ausgang der Operation beschreibt.
• DeleteSchedulesForDay: Ruft die gleichnamige Methode der Klasse
ScheduleDAL auf gibt als Ergebnis ein ReturnCode-Objekt zurück, das
den Ausgang der Operation beschreibt.
Abbildung 80: Grafische Oberfläche für Fahrpläne
Fahrpläne in der Benutzeroberfläche Zur Fahrplanverwaltung existiert
ein dreigeteiltes Panel (siehe Abbildung 80). Oben werden Fahrpläne erstellt, indem der Tag, für den der Fahrplan berechnet werden soll, sowie Bilanzkreis und
Regelzone des Händlers, der das System einsetzt, ausgewählt werden. Schließlich wird über einen Dialog noch der Ort bestimmt, an dem die fertigen XMLDateien zu speichern sind.
Im mittleren Teil kann der Nutzer sich links für beliebige Verzeichnisse auf
dem Rechner eine Liste von Fahrplandateien anzeigen lassen. Wählt man einen
der aufgeführten Dateinamen an, wird in einem Fenster recht daneben die zugehörige XML-Datei angezeigt. Dazu wurde das von Windows.Forms bereitgestellte WebBrowser-Control benutzt, das als Parameter übergebene XML-Dateien
automatisch formatiert darstellt.
137
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Unten besteht die Möglichkeit, nach Eingabe eines Datums die Fahrpläne
eines Tages oder gleich alle vorhandenen Fahrpläne zu löschen. Dazu werden
bei Bestätigung der Sicherheitsabfrage die entsprechenden Methoden aus dem
Service Access Layer aufgerufen.
138
EIS - Energie-Informationssystem
6
Projektgruppe Energie-Informationssyteme
Tests
Um die volle Funktionsfähigkeit sowie vor allem die Korrektheit des Programms
sicherzustellen, wurden umfangreiche Testmaßnahmen unternommen. Zum einen
wurden Unittests zum Testen einzelner Klassen mit ihren Funktionen verwendet, um während der Entwicklung Fehler zu finden und eine Basis für Tests nach
Codeänderungen zu haben. Des Weiteren wurde am Ende ein umfangreicher
Systemtest durchgeführt, bei dem die Oberfläche von mehreren Testern untersucht wurde. Die dabei gefundenen Bugs wurden protokolliert und anschließend
behoben. Im Anschluss wurden die Installationsroutinen getestet, indem das
Programm auf verschiedene Rechnerkonfigurationen installiert wurde. Um Aussagen über die Skalierbarkeit sowie die Performanz der Anwendung zu treffen,
wurden Lasttests durchgeführt.
6.1
Datenbankzugriff
Die korrekte und zuverlässige Kommunikation mit der Datenbank sicherzustellen war einer der wichtigsten Aspekte bei der Programmierung des Systems. Im
Gegensatz zu normalem Programmcode werden Syntaxfehler oder falsche Referenzen nicht automatisch während der Eingabe oder beim Kompilieren angezeigt, sondern treten erst beim Ausführen der entsprechenden Datenbankabfragen auf. Um zu gewährleisten, dass die einzelnen Funktionen auch das tun, was
von ihnen erwartet wird, wurde das Testprojekt DALTests erstellt, in dem für
jede Klasse der Datenbankzugriffsschicht eine Testklasse als Unittest implementiert wurde, die mit Beispieldaten die Funktionen der zugrundeliegenden Klasse
aufruft und deren Ergebnis überprüft. In der Regel werden Anlegen, Auslesen,
Bearbeiten und Löschen von Objekten eines Typs getestet. Das Testprojekt wird
dazu mit allen Klassen in Visual Studio ausgeführt und liefert Protokolle über
Erfolg oder Fehlschlag des Testlaufs zurück. Im folgenden wird als Beispiel für
die allgemeine Vorgehensweise der Testcode der Klasse CustomerDALTest, die
die Datenbankfunktionen zum Umgang mit Kunden-Objekten testet, erläutert.
Zunächst wird die Testklasse als solche deklariert und der zugehörige Testcontext der aufrufenden Testumgebung zur Verfügung gestellt.
[TestClass()]
public class CustomerDALTest {
private TestContext testContextInstance;
public TestContext TestContext {
get { return testContextInstance; }
set { testContextInstance = value; }
}
Innerhalb der Methode MyTestInitialize wird Code angegeben, der zur Vorbereitung des eigentlichen Tests nötig ist, in diesem Fall das Anlegen und Speichern einiger Hilfsobjekte, die später benötigt werden. In der Methode MyTestCleanup steht Code, der nach dem Ausführen des Tests zum Aufräumen“ be”
nötigt wird – in diesem Fall müssen die Hilfsobjekte wieder aus der Datenbank
gelöscht werden. Das Aufräumen sieht hier wie folgt aus:
139
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
[TestCleanup()]
public void MyTestCleanup() {
Assert.IsFalse(CustomerContractDAL.DeleteCustomerContract(
contract.Id));
Assert.IsTrue(TariffDAL.DeleteTariff(t.Id) &&
EnergyProfileDAL.DeleteEnergyProfile(ep.Id) &&
ControlAreaDAL.DeleteControlArea(ca.Id) &&
AccountingAreaDAL.DeleteAccountingArea(aa.Id) &&
EisUserDAL.DeleteEisUser(eu.Id));
aa = null;
ca = null;
ep = null;
eu = null;
t = null;
}
Anschließend wird die Testmethode CustomerTest deklariert – alle Funktionstests einer Datenzugriffsklasse werden jeweils in einer Testmethode zusammengefasst.
[TestMethod()]
public void CustomerTest() {
Nun wird zunächst ein fiktiver Testkunde erzeugt, mit beliebigen Daten gefüllt und in der Datenbank abgelegt. Der Assert-Befehl am Ende überprüft, wie
dies auch in anderen Testframeworks der Fall ist, ob die aufgerufende Methode zum Einfügen des Datensatzes einen bestimmten Wert, in diesem Fall true
für erfolgreiches Speichern, zurückliefert. Andernfalls schlägt der Test fehl und
terminiert.
Customer c = new Customer();
c.Address = "Frau";
c.City = "Bramsche";
c.Company = "Ruhrgas AG";
c.Email = "[email protected]";
c.Fax = "0514/4241";
c.FirstName = "Anja";
c.SortCode = "22143224";
c.BankAccountNumber = "21487423878";
c.Id = Guid.NewGuid();
c.LastName = "Meier";
c.Number = "15c";
c.Phone = "05123/3421";
c.Street = "Energiestraße";
c.Zipcode = "46234";
c.DateOfBirth = new DateTime(1976,08,20);
Assert.IsTrue(CustomerDAL.InsertCustomer(c));
Nach dem Einfügen folgt der Test der Bearbeitungsfunktion. Dazu werden
einige Werte des Kunden verändert und anschließend die geeignete Funktion
140
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
zur Änderung eines Datensatzes aufgerufen und ihr Ergebnis wieder mit Assert
überwacht.
c.Zipcode = "45324";
c.Number = "22 - 24";
c.LastName = "Bierhoff";
c.Street = "Waldweg";
Assert.IsTrue(CustomerDAL.UpdateCustomer(c));
Anschließend werden die Funktionen zum Auslesen bestimmter Kundendatensätze überprüft. Zunächst das Auslesen über die dem soeben eingefügten
Objekte zugewiesene GUID. Direkt danach wird über Vergleiche der zahlreichen Attribute des ausgelesenen mit dem ursprünglichen Objekt sichergestellt,
dass die richtigen Werte aus der Datenbank extrahiert wurden. Weicht ein Wert
von den Erwartungen ab, schlägt der Test fehl.
Customer test = CustomerDAL.GetCustomer(c.Id);
Assert.Equals(test.Address,c.Address);
Assert.Equals(test.City,c.City);
Assert.Equals(test.Company,c.Company);
Assert.Equals(test.Email,c.Email);
Assert.Equals(test.Fax,c.Fax);
Assert.Equals(test.FirstName,c.FirstName);
Assert.Equals(test.BankAccountNumber,c.BankAccountNumber);
Assert.Equals(test.Id,c.Id);
Assert.Equals(test.LastName,c.LastName);
Assert.Equals(test.Number,c.Number);
Assert.Equals(test.Phone,c.Phone);
Assert.Equals(test.Street,c.Street);
Assert.Equals(test.DateOfBirth,c.DateOfBirth);
Assert.Equals(test.SortCode,c.SortCode);
Assert.Equals(test.Zipcode,c.Zipcode);
Dieses Vorgehen wird für die anderen Auslesemethoden, die Listen mit zahlreichen Objekten zurückliefern, wiederholt, wobei vor dem Abgleich zunächst
aus allen Elementen der Liste über die GUID das richtige herausgesucht wird.
Überprüft wird außerdem, ob das erwartete Objekt überhaupt in der Liste vorhanden ist. Falls nicht, kommt es wieder zu einem Fehlschlag.
found = false;
List<CustomerContract> cc =
CustomerDAL.GetCustomerByName("Bierhoff");
for(int i = 0; i < cc.Count; ++i) {
test = cc[i];
if(test.Id == c.Id) {
found = true;
Assert.Equals(test.Address, c.Address);
Assert.Equals(test.City, c.City);
...
141
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
}
}
Assert.IsTrue(found);
Nachdem alle Auslesemethoden getestet sind, erfolgt schließlich noch die
Löschung des Kundenobjektes, deren Erfolg ebenfalls überwacht wird, womit
der Test beendet ist.
Assert.IsTrue(CustomerDAL.DeleteCustomer(c.Id));
Durch diese Vorgehensweise ist eine hohe Codeabdeckung in den getesteten
Klassen gewährleistet, da alle vorhandenen Methoden zum Anlegen, Auslesen,
Bearbeiten und Löschen mindestens einmal aufgerufen werden. An dieser Stelle könnte man einwenden, dass nur mit korrekten Werten gearbeitet wird und
nicht mit ungültigen Eingaben, die von der Datenzugriffsklasse abgefangen werden müssten. Dies Problem stellt sich hier allerdings nicht, weil sämtliche Daten clientseitig auf ihre Gültigkeit überprüft werden, so dass fehlerhafte Daten
gar nicht in diese Architekturschicht gelangen, sondern schon früher zurückgewiesen werden. Damit entfällt auch die Notwendigkeit der Überwachung in
dieser Schicht. Allerdings müsste, sobald Plugins zum Zugriff von außen auf
den Webservice bereitgestellt werden, was in dieser Version nicht der Fall ist,
zusätzlicher Code zur Validierung von außen gelieferter Daten in die Geschäftslogik eingebaut werden, weil dann die GUI-seitige Validierung nicht griffe und
korrekte Werte nicht sichergestellt werden könnten.
6.2
Webservicetests
Zusätzlich zu den Tests der Datenzugriffslogik wurden Testfälle für die Methoden des Webservice entwickelt, die auch als Grundlage für die Lasttests dienen
(vgl. Abschnitt 6.5). Sie wurden ebenfalls als Unittests implementiert, die jeweils
Methoden, die funktional zusammengehören — also etwa solche zur Tarifverwaltung —, überprüfen. Dabei werden nahezu alle Funktionen des Webservices einmal oder mehrfach aufgerufen, um eine hohe Codeabdeckung zu gewährleisten.
Ihre Ergebnisse werden überprüft, sofern es sich nicht um reine Datenbankanfragen handelt, die bereits in den Tests der Datenzugriffslogik überprüft wurden.
In den Testfällen werden typische Handlungsabläufe durchgespielt wie beispielsweise das Anlegen eines Kunden mit anschließender Zuweisung von Verträgen
und Lastprofilen. Der Code für diesen Test der Webservicemethoden zum Anlegen von Kundenverträgen wird hier als Beispiel und zum Vergleich mit dem
Code der Datenzugriffstests vorgestellt.
Anfangs der Methode wird ein Kundenvertrag über den Aufruf von Helper CreateCustomerContract generiert und alle zugehörigen Objekte wie Regelzone oder Bilanzkreis angelegt.
[TestMethod]
public void CustomerContractTest() {
ReturnCode rc;
142
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
CustomerContract cc = Helper_CreateCustomerContract();
cc.StartDate = DateTime.Now.AddDays(3);
cc.Id = Guid.NewGuid();
cc.EndDate = DateTime.Now.AddDays(52);
Anschließend werden die zugehörigen Objekte, die über Refenzen mit dem im
Mittelpunkt stehenden Kundenvertrag verbunden sind, eingefügt, damit es nicht
zu Konflikten in der Datenbank kommt. Dies sind ein Bilanzkreis, eine Regelzone, ein Kunde, ein Systemnutzer, ein Lastprofil und ein Tarif. Über das
Überprüfen des rc genannten ReturnCode-Objekts wird sichergestellt, dass die
Methoden erfolgreich ausgeführt wurden.
rc = target.AddNewAccountingArea(cc.AccountingArea);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.AddNewControlArea(cc.ControlArea);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.AddNewCustomer(cc.Customer);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.AddNewEisUser(cc.EisUser);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.AddNewEnergyProfile(cc.EnergyProfile);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.AddNewTariff(cc.Tariff);
Assert.IsTrue(rc == ReturnCode.OK);
Dann wird der Kundenvertrag eingefügt.
rc = target.AddNewCustomerContract(cc);
Assert.IsTrue(rc == ReturnCode.OK);
Nun werden Abfragen zum Auslesen von Kunden und -verträgen durchgeführt, indem die verschiedenen dazu bereitgestellten Methoden (Auslesen aller
Kundenverträge, aller Verträge eines Kunden, eines bestimmten Vertrages und
des Kunden, der einen bestimmten Vertrag hat) aufgerufen werden, und sichergestellt, dass Daten übermittelt wurden. Eine genaue Überprüfung der Ergebnisse wie bei den Datenzugriffstests erfolgt nicht, da in jenen bereits sichergestellt
wurde, dass die Daten richtig ausgelesen werden. Es geht hier nur noch darum
zu kontrollieren, ob die Daten auch über den Webservice zurückkommen.
CustomerContract[] ccs = target.GetAllCustomerContracts();
Assert.IsTrue(ccs.Length > 0);
ccs = target.GetCustomerContractsForCustomer(cc.Customer);
Assert.IsTrue(ccs.Length > 0);
143
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
CustomerContract c = target.GetCustomerContract(cc.Id);
Assert.IsTrue(c.Id == cc.Id);
Customer[] cs = target.GetCustomerByContract(cc.Id);
Assert.IsTrue(cs.Length > 0);
Sind diese Überprüfungen erfolgreich, wird der Kundenvertrag wieder gelöscht und abschließend gewissermaßen aufgeräumt, das heißt, alle eigens für
diesen Vertrag angelegten Objekte werden ebenfalls aus den Datenbeständen
entfernt. Die Ergebnisse dieser Funktionsaufrufe werden wieder überprüft. Bezeugen die Ergebniscodes den Erfolg dieser Operationen, ist der Test erfolgreich
beendet.
rc = target.DeleteCustomerContract(cc.Id);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.DeleteCustomer(c.Customer.Id);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.DeleteControlArea(c.ControlArea.Id);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.DeleteAccountingArea(c.AccountingArea.Id);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.DeleteEisUser(c.EisUser);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.DeleteEnergyProfile(c.EnergyProfile.Id);
Assert.IsTrue(rc == ReturnCode.OK);
rc = target.DeleteTariff(c.Tariff.Id);
Assert.IsTrue(rc == ReturnCode.OK);
6.3
Systemtests
Abschließend und vor allem auch, um die geforderte Bedienbarkeit sicherzustellen (vgl. 3.3.1), wurde das gesamte System einem manuellen Test unterzogen.
Dabei wurden alle Masken des Programms untersucht und alle Funktionen auf
Korrektheit überprüft. Diese Tests waren sehr umfangreich und wurden von
mehreren Testern durchgeführt. Alle Tests wurden dabei protokolliert, so dass
gefundene Fehler gleich in Beziehung zu Korrekturmaßnahmen gesetzt werden
konnten. Im folgenden soll kurz der Aufbau der Protokolldokumentation vorgestellt werden.
Jedes Testdokument spezifziert zunächst das Datum der Tests sowie den
Namen des Testers. Unter dem Punkt Leistungsmerkmal ist beschrieben, welche
Maske bzw. welche Funktionen untersucht wurden. Außerdem wird noch die
Systemumgebung erfasst.
Ein einzelner Testfall hat dabei folgende Attribute:
144
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• Testfall-Nr.: Die Nummer des Testfalls.
• Beschreibung: Beschreibung der getesteten Funktion.
• Erwartetes Ergebnis Beschreibung des Ergebnisses, das der Nutzer erwartet.
• Ergebnis: Die Spalte enhält das Ergebnis. Es sind folgende Werte verwendet:
– + bedeutet, dass der Test erfolgreich war.
– 0 bedeutet, dass der Test war Einschränkungen erfolgreich war. Diese
Einschränkungen sind dann in den Anmerkungen beschrieben.
– - bedeutet, dass der Test nicht erfolgreich war. Die aufgetretenen
Fehler sind dann in den Anmerkungen beschrieben.
• Fehler/Anmerkungen: Freitext für Bemerkungen
Alle Protokolle zu Tests und Fehlerkorrekturen sind als Anhang angefügt.
6.4
Installationstest
Neben dem Systemtest wurde auch ein Installationstest durchgeführt. Dabei
wurden die von der Projektgruppe erstellten Setup-Programme auf verschiedenen Rechnern ausgeführt. Im Anschluss wurde bei einer kurzen manuellen
Überprüfung getestet, ob alle erorderlichen Komponenten einwandfrei auf dem
Zielsystem installiert wurden und ob alle Funktionen ausführbar waren. Die folgende Tabelle listet die Rechner auf, auf denen wir die Software getestet haben.
Auf allen Systemen lief die Installation ohne Probleme.
Rechner
Intel P4; 2,6 GHz; 1 GB RAM
Intel P4; 3,2 GHz; 1,5 GB RAM
Intel P4; 3,2 GHz; 1,5 GB RAM
AMD Athlon 64; 3,2 GHz; 1 GB RAM
Intel Centrio; 1,5 GHz; 1 GB RAM
Dual Xeon; 3,4 GHz; 4 GB RAM
6.5
Betriebssystem
Windows XP SP2
Windows 2003 Server
Windows 2003 Server
Windows XP SP2
Windows XP SP2
Windows 2003
Typ
Client
Client
Server
Client
Client
Server
Lasttests
Die Lasttests dienen unter anderem dazu, die Skalierbarkeit des Systems im
Mehrbenutzerbetrieb (vgl. nicht-funktionale Anforderungen, Abschnitt 3.3.6)
zu überprüfen, und benutzen die Testsuite für die Webservicetests. Microsoft
Visual Studio bietet standardisierte Vorlagen für Lasttests an, mit deren Hilfe
sich Testszenarien durchspielen lassen. So ist es möglich, einen Lasttest über verschiedene Zeiträume durchzuführen, konstante oder variable Benutzerzahlen zu
simulieren oder das Benutzerverhalten etwa durch Denkpausen zu beeinflussen.
Auch können die einzelnen Testmethoden zu einem Testmix zusammengefasst
werden, in dem ein benutzerdefinierter Prozentsatz von Aufrufen auf jeweils eine
Methode entfällt.
145
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Diese Lasttests wurden in verschiedenen Konfigurationen durchgeführt und
bescheinigten dem System eine überaus akzeptable Performanz. Protokolliert
wurden seitens der Entwicklungsumgebung jeweils zahlreiche Werte für das Testaggregat wie auch für die einzelnen Methodenaufrufe. Die Testresultate sind sowohl in tabellarischer als auch in grafischer Form verfügbar. Im folgenden wird
die Arbeitsweise des Lasttests an einem Beispiel vorgeführt.
Abbildung 81: Testprotokoll nach Lasttest in Visual Studio
Abbildung 81 zeigt ein Testprotokoll, nachdem zuvor ein sechsminütiger
Lasttest durchgeführt worden war, in dem die Nutzerhandlungen zur Kundenund zur Lieferantenverwaltung simuliert wurden. Die gerade (rote) Linie im
Graphen weist die Anzahl der Nutzer aus, die gleichzeitig am System arbeiten. In diesem Fall lag sie bei konstant 30 Nutzern. Zwischen den verschiedenen
Aktionen der Nutzer war eine Nachdenkzeit von zehn Sekunden vorgegeben
worden (hier nicht zu sehen). Die in stark ausschlagende (grüne) Linie symbolisiert die jeweils pro Sekunde durchgeführten Testmethodenaufrufe. Die unterste
(blaue) Linie steht für die durchschnittliche Dauer eines Testaufrufs in Sekunden. Zahlreiche andere Werte sind noch protokolliert, so zum Beispiel die drei
eben genannten Werte nochmals deaggregiert für jede einzelne Testmethode.
Festgehalten wird zu jedem dieser Werte der minimale, maximale, durchschnittliche und letzte aufgetretene Wert. So ist zum Beispiel für die Anzahl der Tests
pro Sekunde zu erkennen, dass die maximale Anzahl bei sechs Aufrufen lag und
die durchschnittliche Anzahl knapp unter dreien. In dem rechten oberen Fenster
sind für die jeweils ausgewählte Größe die Anzahlen der Tests für die einzelnen,
hier fünfsekündigen Zeitintervalle abgebildet.
Diese sehr detaillierte Art der Protokollierung durch Visual Studio erlaubt
deutliche Rückschlüsse auf die Leistungsfähigkeit des Systems. So lässt sich anhand der 2, 73 durchschnittlich pro Sekunde durchgeführten Testläufe ablesen,
dass der Webservice die anfallenden Daten überaus schnell überträgt und die
Datenbearbeitung durch das System insgesamt sehr effizient geschieht. Die zu146
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
grunde liegenden Testmethoden zu Kunden- und Lieferantenverwaltung enthielten nämlich nicht nur einzelne Methodenaufrufe aus dem Webservice, sondern
ein komplettes Benutzungsszenario mit verschiedenen Aufrufen zum Anlegen,
Bearbeiten, Löschen und vor allem Auslesen. Zum Zeitpunkt des hier vorgestellten Testlaufs etwa befanden sich gut tausend Kunden in der Datenbank, die für
einen Aufruf der Kundenverwaltungstestmethode einmal komplett und mehrfach nach bestimmten Kriterien ausgelesen und übertragen werden mussten.
Hinzu kommt ein neu erzeugter sowie ein zu löschender Kunde und 29 andere
angemeldete Nutzer. Man kann also sagen, dass die Kommunikation innerhalb
der Client-Server-Anwendung effizient abläuft und auch größere Benutzermengen kein Problem für das System darstellen. Andere Testläufe bestätigten den
hier gewonnenen Eindruck.
147
EIS - Energie-Informationssystem
7
Projektgruppe Energie-Informationssyteme
Vorgehensmodell
Die Erstellung einer komplexen Software durch eine relativ große Gruppe mit
immerhin elf Teilnehmern erfordert ein strukturiertes Vorgehensmodell. Die wesentlichen Gründe sind, dass dadurch ein koordinierter Entwicklungsprozess in
der Gruppe möglich wird und niemand den Überblick über den Projektstand verliert. Allerdings stießen etablierte Vorgehensmodelle wie das Wasserfallmodell
oder das V-Modell auf wenig Gegenliebe in der Projektgruppe, da die anderweitig mit diesen Methodiken gemachten Erfahrungen – etwa im Softwareprojekt
im Grundstudium – nicht sehr positiv ausgefallen waren. Insbesondere wurde
ein System gewünscht, das flexibler war und alle Ebenen der Entwicklung bis
hin zur Aufgabenzuteilung an die einzelnen Mitglieder umfasste. Hier fand sich
das noch recht junge Scrum-Modell als Lösung. Erfahrungen mit diesem Modell
hatte noch niemand in der Gruppe gemacht, so dass es sich zugleich anbot, es
einmal unter realen Bedingungen zu testen, weil Projektgruppen nicht nur dazu
dienen, möglichst schnell möglichst viel zu programmieren, sondern auch dazu, neue Erfahrungen zu sammeln. In den folgenden Abschnitten wird zunächst
beschrieben, was Scrum ist und wie es in der Projektgruppe eingesetzt wurde.
7.1
7.1.1
Scrum - Entwicklungsmodell für das EIS
Agile Softwareentwicklung
Auf Flexibilität ausgerichtete Softwareentwicklung ist eine Form des Softwareentwicklungsprozesses und zeichnet sich durch vergleichsweise geringen bürokratischen Aufwand aus. Damit bildet die so genannte agile Softwareentwicklung ein Gegengewicht zu den herkömmlichen Entwicklungsprozessen wie dem
V-Modell und dem Wasserfallmodell, bei welchen der hohe bürokratische Aufwand für die Mitarbeiter eines Softwareentwicklungsteams häufig als hinderlich
angesehen wird.
Je nach Betrachtungsquerschnitt lässt sich agile Softwareentwicklung auf verschiedene Ebenen zergliedern, die im folgenden Beschrieben und in Abbildung
82 dargestellt werden. Näheres zu den Grundsätzen der agilen Softwareentwicklung, die im folgenden umrissen werden, findet sich unter anderem im Manifesto
for Agile Software Development [BBa01], im Artikel Agile Processes [Mar02] von
Robert C. Martin oder im Artikel The New Methodology [BBa01] von Martin
Fowler.
Agile Werte sind die unterste Ebene und bilden das Fundament agiler Softwareentwicklung und zielen auf soziale Kompetenzen der Mitarbeiter. Dazu
zählen:
• Ehrlichkeit
• Kommunikation
• Kritikfähigkeit
• Engagement
148
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 82: Agiler Prozess im Scrum-Modell
Agile Prinzipien sind ein Leitsatz für die Arbeitsweise mit dieser Art der
Softwareentwicklung. Sie beschreiben die Dos and Don´t Dos des agilen
Prozesses und sind in dem Manifesto for Agile Software Development“
”
[BBa01] nachzulesen. Das Verfahren kann dabei nur funktionieren, solange sich jeder Beteiligte eines Projektes an die bestehenden Prinzipien hält.
Daraus wird ersichtlich, wieso Werte wie Ehrlichkeit im agilen Entwicklungsprozess so wichtig sind. Beispiele für agile Prinzipien sind etwa
• selbstständiges Arbeiten,
• genaues Arbeiten und
• Terminverpflichtung.
Agile Methoden sind die zur Bearbeitung eines Projektes eingesetzten Teilverfahren, auch Arbeitstechniken genannt. Meist bauen die eingesetzten
Methoden aufeinander auf, so dass das Weglassen bestimmter Methoden
für den Entwicklungsprozess eher hinderlich ist. Die eingesetzten Methoden dienen dazu, die Aufwandskurve und damit die Kostenkurve möglichst
gering zu halten. Dies wird in den nächsten Abschnitten noch ausführlicher begründet werden. Agile Methoden werden von Martin Fowler in
[Fow05] ausführlich beschrieben, so dass an dieser Stelle nicht weiter auf
die umfangreichen Vorteile dieser Arbeitsweisen eingegangen werden soll.
Zur Veranschaulichung wurde Abbildung 83 aus [kos] übernommen.
Agile Prozesse sind die im Rahmen des Projektes eingesetzten Softwareentwicklungsprozesse. Diese bedienen sich agiler Methoden. Werden diese
Prozesse erfolgreich zur Entwicklung von Software eingesetzt, spricht man
von agiler Softwareentwicklung. Den eingesetzten Prozessen liegt in der
Theorie zugrunde, die für den Entwurf eingeplante Zeit zu minimieren
und schnell zu ausführbarem Code zu gelangen.
149
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 83: Wirtschaftlichkeit von agilen und konventionellen Methoden
The most immediate difference is that they are less document-oriented,
”
usually emphasizing a smaller amount of documentation for a given task.
In many ways they are rather code-oriented: following a route that says
that the key part of documentation is source code.“ [Fow05]
7.1.2
Eigenschaften agiler Softwareentwicklung mit Scrum
Die Projektgruppe einigte sich nach kurzer Diskussion darauf, agile Softwareentwicklung einzusetzen. Dabei entschied sie sich dafür, deren Verfahren im
Rahmen des so genannten Scrum-Modells anzuwenden. Da dieses Modell relativ
neu und noch nicht sehr verbreitet ist, soll in diesem Abschnitt kurz auf seine
Vorteile eingegangen werden. Scrum wurde maßgeblich von Ken Schwaber und
Jeff Sutherland entworfen [Sch05]. Dabei soll das Modell die beteiligten Menschen in den Mittelpunkt stellen und dem sozialen Aspekt der Gruppenarbeit
große Bedeutung einräumen. Kommunikation zwischen den Teammitgliedern
bildet ein zentrales Element bei der Bearbeitung der zu erfüllenden Aufgaben.
In regelmäßig stattfindenden Treffen (zwei- bis dreimal pro Woche), genannt
Scrums, werden daher auftretende Probleme und Fortschritte besprochen. Große
Softwareprojekte sind für den einzelnen Entwickler oft schwer zu überblicken.
Scrums helfen, Probleme zu erkennen, bevor sie akut werden. Dies spart Zeit
und damit das Geld des Auftraggebers.
Das Projekt wird zudem in kleinen, einwöchigen Etappen bearbeitet. Jede
Etappe enthält alle Entwicklungsschritte des Gesamtprojekts (Anforderungsanalyse, Design, Implementierung, Test). Diese Etappen werden Sprints genannt
und werden schriftlich festgehalten. So können sich alle Mitglieder über Fortschritte anderer Mitarbeiter informieren. Dies wiederum hilft bei der Prävention
von Fehlern.
150
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Es wird auf einen strikten Anforderungskatalog des Kunden verzichtet, dafür
werden auch Kundenwünsche berücksichtigt, die sich noch während der Softwareentwicklung ergeben. Dies ist möglich, da, anders als in klassischen Verfahren,
der Entwicklungsprozess in Sprints organisiert ist. Nur die im aktuellen Iterationsschritt benötigten Merkmale werden implementiert. Scrum ist bietet durch
diese Flexibilität wie auch andere vergleichbare Vorgehensmodelle, etwa Extreme
Programming, Kostenvorteile für den Auftraggeber (vgl. Abbildung 83). Auch
für die Entwickler kann Scrum eine geeignete Arbeitsweise sein, denn aus der
Erfahrung heraus betrachten viele Entwickler von Software die Dokumentation eher als ein Hindernis und weniger als eine Hilfe. Scrum ist jedoch nicht
vollkommen planlos, wie man nun vermuten könnte. Dies wäre fatal, da kleine
Programmierfehler große Korrekturphasen erfordern würden. Um diesem Irrtum vorzubeugen, soll im nächsten beschrieben werden, wie Scrum es schafft,
mit verringertem Planungsaufwand dennoch planvoll zu einer funktionierenden
Software zu gelangen.
Scrum basiert auf dem iterativen Umsetzen vordringlicher Anforderungen
[Sch05]. Während Extreme Programming allerdings noch Konzepte zur Ermittlung von Anforderungen umfasst, liegt der Schwerpunkt in Scrum auf deren
Abarbeitung. Scrum ist somit in erster Linie ein Managementprozess, der sich
mit anderen Vorgehensmodellen — sinnvollerweise aber agilen — kombinieren
läßt. Schwaber sieht Scrum als empirischen Prozess, einem Prozess ständiger
Adaption im Gegensatz zu den herkömmlichen definierten Modellen.
Scrum besteht im wesentlichen aus den folgenden Kernpraktiken, welche
nachstehend näher beschrieben werden und auch auf den Internetseiten der
Agile Alliance“ [All] nachzulesen sind:
”
• Sprint
• Product Backlog
• Sprint Backlog
• Daily Scrum
• Sprint Review
• Sprint Retrospective
7.1.3
Sprint
Sprints stehen bei der Softwareentwicklung mit Scrum im Mittelpunkt. In einem Sprint werden die in einem Product Backlog (s. u.) gesammelten Anforderungen den Kunden Schritt für Schritt abgearbeitet. Die im Product Backlog
aufgestellten Anforderungen werden in Sprint Backlogs eingetragen. In einem
Sprint Backlog ist festgehalten, welche Anforderungen in einem bestimmten
Sprintzeitraum erfüllt werden sollen. Die Iterationslänge beträgt in der Regel
30 Tage, innerhalb dieser Projektgruppe jedoch nur sieben Tage, da in kleineren
Schritten gearbeitet wird. Die Entscheidung, welche Anforderungen umgesetzt
werden, wird vom Kunden nach von ihm festgelegten Prioritäten getroffen. Die
Anforderungen aus dem Sprint Backlog werden vom Team aufgeteilt und jeder
Entwickler schätzt und bewertet die ihm zugewiesenen Aufgaben.
151
EIS - Energie-Informationssystem
7.1.4
Projektgruppe Energie-Informationssyteme
Product Backlog
Ein Product Backlog ist eine Liste priorisierter Anforderungen, die in zukünftigen Sprints abgearbeitet werden sollen. Das Product Backlog gibt damit eine
grobe Entwicklungsrichtung für das Softwareprodukt an.
7.1.5
Sprint Backlog
Ein Sprint Backlog ist eine Liste der Anforderungen, die in einem Sprint abgearbeitet werden sollen. Welche Anforderungen aus dem Product Backlog in das
Sprint Backlog wandern, bestimmt allein der Kunde auf Basis der Schätzungen
der Entwickler.
7.1.6
Daily Scrum
Bei jedem Meeting findet ein kurzes (15-minütiges) Scrum-Meeting statt. Bei
einem Scrum-Meeting skizziert eine Gruppe, die einen bestimmten Scrum abarbeitet kurz Ergebnisse und Probleme. Da jede Gruppe selbständig arbeitet, erfordert dieses Verfahren Disziplinierung der Mitglieder. Der Begriff Daily-Scrum
ist im Rahmen der Projektgruppe irreführend, da nicht täglich Treffen stattfinden.
7.1.7
Sprint Review
Ist der Iterationszeitraum eines Sprints vorbei, findet ein Sprint Review statt.
Hier können dem Kunden die abgearbeiteten Anforderungen eines Sprints vorgestellt werden und Zusagen zur Abarbeitung von Aufgaben des nächsten Sprints
gemacht werden.
7.1.8
Sprint Retrospective
Nach dem öffentlichen Sprint Review mit dem Kunden findet ein Meeting der
Entwickler statt. Folgende Fragen sollen geklärt werden:
• Welche Ereignisse sind eingetreten?
• Was lief gut?
• Was ist verbesserungswürdig?
7.2
Erfahrungen mit Scrum
Wie schon vor der Implementierung im ersten Semester der Projektgruppe geplant, sollte die eigentliche Umsetzung des Energieinformationssystem mit Hilfe
von Scrum geschehen. Wie bereits im vorigen Abschnitt beschrieben, ist Scrum
eine agile Methode der Softwarentwicklung. Da die Projektgruppe von der Idee
angetan war, eine solche im Studium noch unbekannte und ungenutzte Softwarentwicklungsmethode zu nutzen, und auch die eigentliche Arbeitsweise im
152
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Scrum interessant fanden, entschied man sich, mit diesen Konzept bzw. mit
einer modifizierten Variante zu arbeiten.
Die hier beschriebenen Features unseres Projektes sind im Backlog in weitere
Aufgaben unterteilt. Um Scrum und die Features genauer und übersichtlicher
beschreiben zu können, werden diese unterteilten Aufgaben gruppiert. So werden
Items aus dem Backlog in dieser Beschreibung zusammengefasst. Zum Beispiel
werden die Aufgaben Kunden anlegen, Kunden löschen usw. zum Leistungsmerkmal Kunden zusammengefasst und beschrieben.
7.2.1
Eigene Umsetzung
Da für die Gruppenmitglieder feststand, dass man in einer Projektgruppe nicht
identisch zu einer wirklichen Softwareentwicklerfirma arbeiten kann — als Gründe sind hier zum Beispiel projektexterne Verpflichtungen, sei es zum Beispiel
durch die Universität und außeruniversitäre Arbeiten oder personelle und technische Kapazitäten, zu nennen — aber trotzdem versuchen sollte, sich so nah
wie möglich an eine solche Umgebung und Arbeitsweise zu orientieren, wurde
das Scrum Konzept so modifiziert, dass man unter den gegebenen Bedingungen sinnvoll mit den Ideen arbeiten konnte. Des Weiteren wurde stets versucht,
einen Softwareprozess in wirtschaftlicher Umgebung zu simulieren.
Im folgenden soll aufgeführt werden, wie die Projektgruppe sich die Arbeit
mit Scrum vorstellte und in der hier beschriebenen Dokumentation der Sprints
auch, wie sie im Prozess der Entwicklung stellenweise den Scrumprozess anpasste. Es bestand dabei nicht die Absicht, aus einem bestehenden Konzept ein
eigenes Softwareentwicklungsmodell zu erstellen, sondern eher nicht starr und
undynamisch an einer Idee zu hängen, die man so nicht in der Gruppe umsetzen
konnte. Gerade weil es sich bei Scrum um eine sehr agile Methode der Softwareentwicklung handelt, hielt die Projektgruppe diese Anpassung für sinnvoll.
7.2.2
Planen der Sprints und Sprint Review Meetings
Zuvorderst stand das Erstellen eines Planes, an dem man sich orientieren konnte, wieviel Zeit man zur Verfügung hat und welche Ziele in einer solchen Zeit
erreicht werden können. Ein Sprint im ursprünglichen Scrum ist für eine Woche
angesetzt, in der es tägliche Treffen gibt und an dessen Ende die aufgestellten
Features implementiert sein sollen bzw. eine Zusammenfassung über Geschafftes
und Offenes geliefert wird. Die Gruppe einigte sich darauf, diese Sprints an ihre
Situation anzupassen und den Zeitraum auf einen Monat zu verlängern. Das
hieß, dass im zweiten Semester des Projektes, dem Sommersemester 2006, vier
bis fünf Sprints aufgestellt und mit Features gefüllt werden konnten. Dementsprechend wurde ein Plan für diese Situation aufgestellt.
• Warm Up: 07.04.2006-14.04.2006 | Bevor mit dem eigentlichen Sprint angefangen wurde, sollten im sogenannten Warm Up erst noch offenstehende
organisatorische Dinge geklärt werden.
• Erster Sprint inklusive der Sprint Organisation: 14.04.2006-31.05.2006 |
Grobe Organisation der Sprints und der Aufstellung des ersten Sprints.
153
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 84: Terminplanung der einzelnen Scrums
• Zweiter Sprint: 31.05.2006-05.07.2006 | Sprint Review Meeting des ersten
Sprints und Aufstellung des zweiten Sprints.
• Dritter Sprint: 05.07.2006-02.08.2006 | Sprint Review Meeting des zweiten
Sprints und Aufstellung des dritten Sprints.
• Vierter Sprint: 02.08.2006-30.08.2006 | Sprint Review Meeting des dritten
Sprints und Aufstellung des vierten Sprints.
• Fünfter Sprint: 30.08.2006-13.09.2006 | Sprint Review Meeting des vierten
Sprints. Diskussion über die Nutzung und Aufstellung des fünften Sprints.
• Projektabschluss: 13.09.2006-20.09.2006 | Sprint Review Meeting des fünften Sprints. Abschließende Arbeiten an Dokumentation, Tests, Handbuch
und eventuellen noch offenen zu erledigenden Aufgaben
• Abschlussbericht: 20.09.2006-30.09.2006 | Finale Zusammenstellung des
Berichtes, Korrektur und lezte Formatierungen des Berichtes. Bestimmung
einer Person aus der Gruppe zur Präsentation des Projektes
7.3
Warm Up
Das Warm Up war dafür angedacht, einen möglichst reibungslosen Start in die
Arbeit mit den Sprints zu gewährleisten. Es sollte verhindert werden, dass viele Fragen zur Implementierung erst bei der eigentlichen Arbeit auftauchen. So
wurde als erstes noch einmal zusammengefasst, was bereits erledigt wurde, insbesondere im Zusammenhang mit dem Zwischenbericht und dem angetesten
Prototypen innerhalb der gewählten Entwicklungsumgebung. Zusätzlich wurden Tipps sowie Hilfen zur Installation, Benutzung der Entwicklungsumgebung
und Zusatzprogrammen gegeben. Hintergedanke war auch, alle Mitglieder der
Projektgruppe nach den Semesterferien wieder auf einen Stand zu bringen, um
die Motivation für alle zu erhalten und niemanden aus der Arbeit bzw. bestimmten Bereichen des Projektes auszuschließen. So sollte jeder wissen, mit welchen
Mitteln die eigentliche Programmierarbeit zu leisten ist und welche Schritte zu
tun sind, um gestellte Aufgaben bewältigen zu können. Aus eigener Erfahrung
ist zu sagen, dass es sehr frustrierend ist, wenn man bereits am Start scheinbar
unendlich viele Probleme bewältigen muss, um überhaupt den ersten Schritt in
Richtung der eigentlichen Implementierung gehen zu können. So wurde zum Beispiel von einigen Mitgliedern der Gruppe erläutert, wie man richtig mit der gewählten Entwicklungsumgebung arbeitet und beispielhaft einige Arbeitsschritte
vorgeführt.
154
EIS - Energie-Informationssystem
7.4
7.4.1
Projektgruppe Energie-Informationssyteme
Erster Sprint
Verlauf des ersten Sprints
Um sich mit dem ersten Sprint vertraut zu machen und da kein vorrausgegangenes Sprint Review Meeting von einem früheren Sprint bzw. ein Sprint selbst
vorlag, um in diesem bereits Aufgaben und sonstige Dinge zu verteilen, entschied sich die Projektgruppe dafür, den ersten Sprint zusammen mit der noch
dazugehörigen einmalig zu bestimmenden Organisation der Sprints von vier auf
sechs Wochen zu erweitern. Da auch noch das komplette Backlog, also den Pool
für alle gewünschten Features, mit den dazugehörigen Aufgaben erstellt werden
musste, wurde der Vorschlag der Sprintverlängerung übernommen.
Zu Beginn des ersten Sprints wurde ein Scrum-Master bestimmt, der die
Organisation der einzelnen Sprints übernehmen sollte. Der Scrum-Master musste unter anderem die von der Gruppe aufgestellten Features des Backlogs in
das dafür eingerichte Plugin von Visual Studio übertragen. So hatte die ganze
Gruppe eine Übersicht über alle Aufgaben, die zu bewältigen waren. Die Aufgaben wurden mit einer Priorität und einer teilweise mit einer eingeschätzten
Bearbeitungszeit versehen. Aus dem Backlog wurden nun für den ersten Sprint
die gewünschten Features ausgewählt.
Damit die Arbeit mit den Features gut funktionierte, wurden in den ersten
zwei Wochen des Sprints von den Teilnehmern einige Konzepte ausgearbeitet
und der Gruppe vorgestellt:
• Transaktionskonzepte definieren
• Logging definieren
• Tests definieren
• Benachrichtung bei Ergeignissen
• Sessionhandling definieren
• Form der Exceptions
• Datenbankanbindung
Sinn war es, allen Teilnehmern einen einheitlichen Zugang zu verschaffen, um
die gelösten Aufgaben nicht nur zu bewältigen, sondern die Ergebnisse konsistent und für die ganze Gruppe lesbar bzw. verständlich und nachvollziehbar zu
halten. Diese Konzepte wurden in einer Sitzung von den jeweiligen Verantwortlichen vorgetragen und anhand von Beispielen oder Definitionen erklärt, so dass
jeder auf dem Wissensstand war, diese Anleitungen auch umzusetzen.
Die Gruppe entschied sich danach, erst einmal die Stammdaten des Systems zu implementieren, zumal diese Daten relativ unabhängig von den jeweiligen anderen Features sind. Somit sollte das Grundgerüst geschaffen werden,
um dann später mit diesem weiter arbeiten und die folgenden, komplexeren
Features leichter umsetzen zu können. Es sollten also Benutzer, Lieferanten,
Kunden, Bilanzkreise und Regelzonen, Tarife und Lastprofile als zugängliche
Leistungsmerkmale nach diesem Sprint existieren. Für eine sinnvolle Nutzung
155
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
wurde dementsprechend die erste grobe Form der Nutzungsoberfläche gestaltet
(weitere Informationen dazu im Kapitel 4). So konnten die Stammdaten gleich
in eine zusammenhängende Umgebung gebracht werden, was einerseits eine gute
Übersicht bot, was das System bereits leistet, aber auch schon eine Vorschau
darauf ergab und erste Ideen weckte, wie die restlichen Features in das bereits
vorhandene Programm integriert werden konnten.
Die hier erwähnten Stammdatenfeatures lassen sich im Detail im Kapitel
Funktionen – Stammdaten nachlesen.
7.4.2
Probleme und Ereignisse im ersten Sprint
Während der Arbeit am ersten Sprint wurde die Struktur der Backlog Items
noch einmal überarbeitet, um sinnvoller mit diesen arbeiten und diese besser
verteilen zu können. Falls sinnvoll, wurde ein Feature auf die drei Entwicklungsebenen verteilt: Datenbank, Oberfläche und Logik. Zum einen hatte der
Scrum-Master dadurch eine bessere Übersicht, wie weit eine zusammenhängende Aufgabe bereits bearbeitet ist, und zum anderen konnten die Teilnehmer sich
in ihren Untergruppen effizienter aufteilen. Wie auch schon zuvor tauchten immer wieder Probleme mit der genutzten Entwicklungsumgebung auf. Einerseits
erfüllte das Plugin zur Organisation des Scrums nicht ganz die Ansprüche, die
die Gruppe daran gestellt hatte:
Backlog und Sprint Die Arbeit mit dem Backlog und den eigentlichen Sprints
wurde dadurch erschwert, dass zwischen diesen beiden Bereichen im Plugin keine direkte Verbindung besteht. Dass heißt, jedes Objekt aus dem
Backlog musste manuell im Sprint neu erstellt und größtenteils auch neu
beschrieben werden. Zum einen musste die Gruppe jetzt darauf achten,
die erhaltenen Aufgaben im Sprint zu bearbeiten und zusätzlich noch einige Einstellungen im Stammobjekt im Backlog zu tätigen. So musste zum
Beispiel der aktuelle Bearbeitungsstatus sowohl im Backlog als auch im
Sprint manuell umgestellt werden. Ein größeres Durcheinander wurde aber
dennoch vermieden, lediglich die Übersicht im Backlog ging mit der Zeit
immer wieder etwas verloren.
Integrierte Reports Die anfänglich als praktisch empfundenen Reports zur
Ausgabe von beispielsweise Sprintarbeitsstatistiken stellten sich im weiteren Verlauf als für die Gruppe unnütz heraus. Da kein Report manuell konfigurierbar ist und eine hohe Einarbeitungszeit für die Erstellung
von eigenen Reports kein vernünftiges Verhältnis zwischen Aufwand und
Ertrag versprach, wurden diese Reports nicht weiter genutzt. So wurde
beschlossen, im Endbericht eine Zusammenfassung in ähnlicher Form zu
gestalten.
Sprint- und Backlogitems Da die Projektgruppe die Reports nicht nutzen
wollte, hatten die tiefgreifenderen Beschreibungen der Items aus den Sprints
oder auch den Backlogs für uns ebenfalls keinen direkten Sinn, so dass man
sich darauf einigte, nur die nötigsten Informationen zu beschreiben. Da das
das Backlog gemeinsam erstellt worden war somit jeder auch Ahnung von
den einzelnen Features hatte, ergaben sich aus dieser Entscheidung auch
156
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
keine weiteren Probleme, zumal sich die Aufgabenmenge noch in überschaubaren Dimensionen befand.
Andererseits wurde die Gruppe von unerklärlichen Fehlermeldungen seitens Visual Studio befallen, die zwar keinen Einfluss auf unser Programm hatte, doch
einige Male an den Nerven der Gruppenmitglieder zerrte.
7.4.3
Review Meeting des ersten Sprints
Das Sprint Review Meeting gab uns die Möglichkeit, den Betreuern der Projektgruppe, wie in einer realen wirtschaftlichen Umgebung, unsere Ergebnisse
zu präsentieren und zusätzlich Verbesserungen und Anregungen einzuholen. Im
ersten Meeting kristallisierte sich schnell heraus, dass die doch umfangreiche
Aufgabenstellung zwar bewältigt worden war, aber trotzdem noch einige Fehler
im System vorhanden waren. Es wurde empfohlen, diese erst zu beheben, bevor man mit neuen Features weitermachen würde, da sich ein nicht beseitigter
Fehler in den anderen Aufgaben wahrscheinlich noch weiter ausbreiten würde.
Da die Gruppe eine Woche bereits als Puffer für unerwartete Ereignisse eingeplant hat, wurde der zweite Sprint entsprechend um eine Woche erweitert. In
der ersten Woche sollten also möglichst alle Fehler behoben werden, damit man
in der darauffolgenden Sprintwoche direkt am ursprünglich geplanten, zweiten
Sprint ansetzen konnte. In diesem Zusammenhang wurde auch festgelegt, die
Oberfläche während der Entwicklung genauer zu bearbeiten und einheitlich zu
gestalten, damit Fehler schon frühzeitig verringert werden können.
7.5
7.5.1
Zweiter Sprint
Verlauf des zweiten Sprints
In der anfänglichen groben Planung des Scrums war der zweite Sprint für die
Erstellung der Entscheidungsunterstützung und dazugehöriger Aufgaben angedacht. Der Sprint wurde jetzt um die Fehlersuche und Behebung erweitert. Wie
schon erwähnt, wurde der zweite Sprint um eine Woche verlängert, um das
Gerüst der Implementierung möglichst fehlerfrei zu halten.
Zu Beginn wurde aus dem ersten Sprint heraus eine Fehlerliste zusammengestellt, damit in der ersten Woche die Behebung schnell durchgeführt werden
konnte. In der ersten Sitzung wurden diese Fehler auf die Gruppe verteilt. Es
wurde also versucht, diese Liste abzuarbeiten. Am Ende dieser Woche hatte man
zwar einen Großteil der Fehler behoben, entschied sich aber dafür, zwei Personen
aus der Gruppe für eine weitere Fehlersuche abzustellen. So sollte die Gruppe
wie geplant an den noch aufzustellenden neuen Aufgaben arbeiten können, aber
auch die restlichen Fehler noch beseitigen und neue möglichst schnell beheben
können.
Als Hauptaufgaben wurden das Pluginsystem zum einen für die Lastprognosen und zum anderen für die Entscheidungsunterstützung (weitere Informationen siehe Abschnitt 4.2.1, Seite 36) und die rollenbasierte Sicherheit innerhalb
des Programmes bestimmt (weitere Informationen siehe Abschnitt 4.2.4, Seite
157
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
45). Zusätzlich sollten für die jeweiligen Pluginsysteme Algorithmen entwickelt
werden, die mit verschiedenen Zielsetzungen die Entscheidungsunterstützung
bzw. das Lastprognoseplugin lauffähig machen sollten. So wurde zum Beispiel
zuerst ein simpler Algorithmus entwickelt, der das Problem kurzsichtig und auf
einfachstem Wege löst, um das Gesamtsystem erst einmal testen zu können. Alle
folgenden Algorithmen sollten nach den Kriterien Geschwindigkeit und Optimalität verbessert werden.
Neben diesen Features wurden zusätzlich kleinere Aufgaben verteilt:
Systembeschreibung Jeder Verantwortliche einer Aufgabe im dafür eingerichteten Scrum- Verwaltungs-Plugin sollte, soweit dies möglich ist, das
entsprechende Feature schon für den Endbericht in grober Form beschreiben.
Oberfläche Alle Fenster sollten einer einheitlichen Vorlage entsprechen, so dass
neue Inhalte nach dieser Form erstellt und bereits bestehende an diese
Vorgaben angepasst werden konnten.
Script für Testzwecke Um das System sinnvoll testen zu können, wurden der
Datenbank Testdaten zugefügt. Gerade im Hinblick auf die Probleme im
ersten Scrum sollten solche oder ähnliche Fehler auch durch diese Daten
vermieden werden.
Exceptions definieren Da in der Gruppe die Behandlung von Exceptions
noch nicht eindeutig war, wurde hierzu abermals ein Konzept zur Umsetzung ausgearbeitet.
Diese wurden parallel zu den Hauptaufgaben bearbeitet, so dass es in der Gruppe eigentlich selten einen Leerlauf für eine Person gab, da immer eine kleine
Aufgabe zu erledigen war, wenn man an einem Hauptfeature zum Beispiel auf
Ergebnisse von Gruppenmitgliedern warten musste.
7.5.2
Probleme und Ereignisse im zweiten Sprint
Das Hauptproblem war sicherlich, dass man die Probleme aus dem ersten Sprint,
seien es nun Probleme mit der Entwicklungsumgebung oder mit Fehlern im eigenen Programm selbst, nicht wirklich für den zweiten Sprint eingeplant hatte,
soweit man das überhaupt tun kann. Auf jeden Fall war man nicht auf einen
holprigen Sprintverlauf vorbereitet. Und so musste man sich erst daran gewöhnen, offene Aufgaben nachträglich zu bewältigen, gleichzeitig aber auch die neuen Aufgaben nicht aus den Augen zu verlieren. So hatte die Gruppe auch die
Fehler an sich unterschätzt und dies in der ersten Woche abermals gemerkt, als
es hieß, diese erst einmal aus dem Wege zu schaffen. So fiel auf, dass Fehler
wieder neue Fehler nach sich ziehen und so eine Aufgabe leicht sehr zeitaufwendig werden lassen können. In der zweiten Woche hatte die Projektgruppe diese
Tatsache aber dennoch erkannt und die Aufgaben entsprechend angepasst, so
dass der zweite Sprint die gewünschten Ergebnisse lieferte.
158
EIS - Energie-Informationssystem
7.5.3
Projektgruppe Energie-Informationssyteme
Review Meeting zum zweiten Sprint
Im Meeting wurden einerseits die neuen Features vorgestellt und andererseits
die Arbeit an den Fehlern vorgeführt. Ergebnis war, dass der Großteil der Fehler ausgemerzt wurde und lediglich einige Unstimmigkeiten in der Validierung
herrschten. An den neuen Hauptfeatures fehlten noch einige Detailarbeiten, die
im dritten Sprint aufgearbeitet werden sollten. Dazu gehörten zum Beispiel die
Anpassung der Oberfläche oder der Erweiterung um einige aus dem Entwurf
vorgesehenen Optionen.
7.6
7.6.1
Dritter Sprint
Verlauf des dritten Sprints
Im Verlauf des dritten Sprints traten zum ersten Mal ernsthafte Probleme auf,
die man neben den neuen gestellten Aufgaben zu bewältigen hatte.
Zuerst einmal wurde nach dem Meeting festgelegt, dass in diesem Sprint die
vorgesehenen Features der EEX implementiert werden sollten (weitere Informationen siehe Abschnitt 5.2, Seite 88). Zusätzlich sollten die erstellten Features
aus dem zweiten Sprint abgeschlossen werden. Zum einen hieß dies, dass die
Kaufentscheidung um die eigentliche Umsetzung erweitert werden sollte. Außerdem sollte die Oberfläche nicht mehr nur einheitlich sein, sondern auch ein
an Windows ausgerichtetes Design erhalten.
Wie schon erwähnt, bemühte man sich intensiver um die Fehlersuche, dennoch nutzte die Gruppe die Validierung für die Nutzungsoberfläche noch zu
uneinheitlich und lückenhaft. So wurde ebenfalls die Aufgabe verteilt, eine einheitliche Validierungsfunktion zu erstellen bzw. die alte den Ansprüchen entsprechend anzupassen. So war ebenfalls gewährleistet, dass alle Oberflächeninhalte
einheitlich auf zum Beispiel falsche Eingaben reagieren.
Als erstes ernsthaftes Problem stellte sich die Testbarkeit der Multithreading-fähigkeit des Webservices unseres Programmes heraus. Da es nicht möglich
war, dies über Visual Studio nachzuweisen, wurden wir von den Betreuern gebeten, dies explizit vorzuweisen. Zum einen hieß dies, dass einige Teilnehmer der
Gruppe nicht für die eigentlich vorgesehenen Aufgaben zur Verfügung standen
und dass diese Analyse ein Mangel im Programm aufzeigen könnte. Es wurde
davon ausgegangen, dass unser Programm Multithreading unterstützt, ohne dies
wirklich überprüft zu haben. So wurde dieser vorzubringende Beweis ebenfalls
eine Aufgabe im dritten Sprint.
Das zweite Problem war, dass die strikte Trennung von Client und Server nicht eingehalten wurde. Dieser Missstand sollte ebenfalls in diesem Sprint
zusätzlich behoben werden, so dass nicht die volle Gruppenkapazität für die
eigentlichen Aufgaben bereit stand.
7.6.2
Probleme und Ereignisse im dritten Sprint
Da die Gruppe sich in diesem Sprint im Verhältnis zu den vorangegangenen
Sprints eine übersichtliche Anzahl an Aufgaben gestellt hatte, wurde das Problem der Arbeitsaufteilung hinsichtlich der Gruppenkapazität gut umgangen.
159
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
So hatte man nach der Verteilung der Hauptaufgaben immer noch genügend
Teilnehmer für die Behebung der eben genannten Mängel zur Verfügung. Die
Arbeitsteilung von Client und Server, bei der der Client die grafische Oberfläche
enthält und der Server die Berechnungen übernimmt, konnte bis auf eine Ausnahme gut umgesetzt werden, da das Problem und das Prinzip von der Gruppe
verstanden worden war. Die Ausnahme bildete das Pluginsystem. Hier war es in
einem ersten Anlauf nicht gelungen, die überaus komplexen Berechnungen auf
der Serverseite ablaufen zu lassen, da die vom Pluginsystem benötigten Interfaces sich nicht über den Webservice übertragen ließen. Dies widersprach aber
deutlich den Anforderungen an die oben geschilderte Arbeitsteilung. Da dieses
Problem aber nicht ohne großen Zeitaufwand zu beheben war, wurden erst einmal Lösungsvorschläge erarbeitet, die dann im vierten Sprint umgesetzt werden
sollten.
Das Problem der Multithreading-Fähigkeit wurde anfangs von der Gruppe
unterschätzt, da man sich sicher war, dass der Webservice dazu fähig wäre. Einen
soliden Beweis konnte man dennoch nicht liefern, so dass auch diese Aufgabe
im vierten Sprint erneut aufgenommen werden musste.
7.6.3
Review Meeting zum dritten Sprint
Im Meeting wurden kurz die wenigen neuen Features vorgestellt, das Hauptaugenmerk lag aber auf der Bewältigung und Diskussion der noch offenstehenden
Probleme. Zum einen wurde ein Konzept vorgestellt, mit dem sich das Problem
der Arbeitsteilung zwischen Client und Server beheben lassen sollte. Betreuer
und Gruppe einigten sich auf eine Bearbeitung innerhalb des vierten Sprints.
Bei dem noch ausstehenden Beweis hingegen wurde von den Betreuern auf eine
schnelle Bearbeitung gedrängt, da bei einem negativen Ergebnis — sprich einer
nicht vorhandenen Multithreading-Fähigkeit des Webservices — zu schließen
ist, dass die Arbeitsweise des Webservices ungenügend ist und eine Umstellung
viel Zeit kosten würde. Das hätte auch geheißen, dass der gesamte Zeitplan in
Gefahrg geraten wäre.
7.7
7.7.1
Vierter Sprint
Verlauf des vierten Sprints
Wie schon im zweiten Sprint kam in diesem Sprint eine unerwartet aufwändige
und eher schwierige Aufgabe hinzu. Diese war, den Beweis zu erbringen, dass
unser Webservice multithreading-fähig ist. Schwierig deshalb, weil in der Gruppe
noch keine Erfahrungen zu diesem Thema und insbesondere nicht im Zusammenhang mit Visual Studio existierten. Diese Aufgabe sollte also so schnell wie
möglich gelöst werden, d. h. nicht erst am Ende des vierten Sprints abgeschlossen
sein.
Trotz dieses Problems mussten die weiteren noch offenstehenden Aufgaben
erledigt werden. Da der vierte Sprint eigentlich der letzte Sprint sein sollte, in
dem neue Features eingebaut werden sollten, wurde eine intensive Sprintplanung durchgeführt. So wurden alle noch im Backlog existierenden Aufgaben
160
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
gesammelt und versucht, für die jeweiligen Aufgaben Zeiteinschätzungen anzugeben. Entsprechend der Priorität wurde dann entschieden, welche Features
noch bearbeitet werden sollten. Folgende Aufgaben wurden dem vierten Sprint
hinzugefügt:
Störungen: Weitere Informationen siehe Abschnitt 5.3.2, Seite 115
Druckoptionen
Fahrpläne: Weitere Informationen siehe Abschnitt 5.4, Seite 129
Informationen innerhalb der Oberfläche
Finale Oberflächenanpassung:
Umstellung des Pluginsystems: Weitere Informationen siehe Abschnitt 4.2.1,
Seite 36
Abschluss der Validierungsfunktionen: Weitere Informationen siehe Abschnitt
4.2.2, Seite 42
Erstaunlicherweise sind nur einige als optional gekennzeichnete Aufgaben aus
dem Backlog nicht in die Sprints mit eingeflosssen, was bedeutete, dass bei
einem erfolgreichen Abschluss des vierten Sprints die gestellten Aufgaben der
Gruppe bewältigt wären.
7.7.2
Probleme und Ereignisse im vierten Sprint
Das große Problem zu Beginn des Sprints, nämlich der noch zu liefernde Beweis,
konnte innerhalb der ersten Tage endgültig gelöst werden. Der Webservice ist
multithreading-fähig, jedoch kann man dies nicht direkt in der Entwicklungsumgebung nachweisen geschweige denn testen. Ein solcher Test ist anscheinend nur
über Lasttests möglich. Erst nach einigen Recherchen über Foren und Hilfestellungen zur Thematik sowie einer Anfrage an Microsoft konnte man zu diesem
Ergebnis gelangen, was selbst den Betreuer etwas verwunderte. In ihren Augen
eignet sich Microsoft Visual Studio wegen der fehlenden Testbarkeit nur bedingt für die Entwicklung von Client-Server-Anwendungen. Zur Erleichterung
der Gruppe wurde das Problem von den Betreuern als gelöst betrachtet und die
noch ausstehenden Aufgaben konnten angegangen werden.
Ebenfalls gelöst wurde das Problem der Pluginumstellung. Diese arbeitet
jetzt serverseitig und nicht wie zunächst implementiert clientseitig (weitere Informationen im Abschnitt 4.3, Seite 49).
Ein kleines weiteres Problem war die Urlaubsthematik in der Gruppe. Da
ein nicht unerheblicher Teil im vierten Sprint Urlaub eingereicht hatte, musste
die Planung der Aufgaben entsprechend präzise erfolgen. Dies wurde dann auch
dementsprechend gemacht, so dass die gestellten Aufgaben dieses Sprints zum
Großteil gelöst werden konnten. Wie immer am Ende eines Sprints fehlten zu den
einzelnen Aufgaben noch Details bzw. traten Fehler auf, die dann im folgenden
Sprint behoben bzw. bearbeitet werden sollten. Da der letzte Sprint als reiner
Dokumentations-, Test- und Sprint zur Fehlerbehebung angedacht war, konnte
man die letzten offenstehenden Verbesserungen ohne Probleme in den Verlauf
des Scrumprozesses mit einbeziehen.
161
EIS - Energie-Informationssystem
7.7.3
Projektgruppe Energie-Informationssyteme
Review Meeting zum vierten Sprint
Im Meeting wurden wie gewohnt alle erstellten Features vorgestellt und im Anschluss der neue Sprint geplant. Hauptaugenmerk lag also auf der Vervollständigung der Dokumentation, dem Testen des Programmes und dazugehörigen Komponenten, entsprechende Fehlerbehebung und dem Schreiben des Abschlussberichtes.
Zum einen sollten Datenbankzugriffe getestet, Systemtests, Installationstests, Lasttests und Webservice-Tests durchgeführt werden (weitere Informationen in Kapitel 6, Seite 139). So sollten alle Bereiche abgedeckt werden.
7.8
7.8.1
Fünfter Sprint
Verlauf des 5. Sprints
Da in diesem Sprint nur noch stellenweise am Programm selbst gearbeitet wurde
(z. B. abschließende Arbeiten an der GUI und letzte Optimierungen an den Plugins), konnten die Tests konsequent im vorhandenen Zeitraum entwickelt werden.
Bei der Dokumentation traten wie erwartet keine weiteren Schwierigkeiten auf,
ebenso beim Schreiben der ersten Kapitel des Endberichtes. Die schwierigen und
komplexeren Arbeiten am Endbericht sollten nach dem fünften Sprint starten.
7.8.2
Probleme und Ereignisse im fünften Sprint
Das Pluginsystem war zwar bereits entsprechend den Vorgaben der Betreuer
überarbeitet worden und arbeitete nun serverseitig, allerdings haperte es noch
an der Einbindung der generischen Benutzeroberflächen ins übrige Programm.
Die Arbeiten an diesem — im Vergleich zur Umstellung der Arbeitsweise kleinen — Problem wurden als Spezialfall im Scrum vermerkt, da sie auch noch
nach dem vierten und fünften Sprint fortgesetzt wurden. An dieser Stelle wurde
vom eigentlich Plan abgewichen, keine weiteren Features bzw. Aufgaben im Programm nach dem fünften Sprint zu tätigen. Für die Endfassung des Programms
musste dieses Leistungsmerkmal aber auf jeden Fall enthalten sein und wurde
auch als noch schaffbar und sinnvoll eingestuft. So sollte die Einbindung des
Pluginsystems auf jeden Fall so lange weiterentwickelt werden, wie es die Zeit
zuließ.
7.8.3
Review Meeting zum fünften Sprint
Das letzte Meeting war sehr kurz und es wurde nur einmal kurz besprochen,
was geschafft wurde und was noch an Aufgaben offenstand. Dazu gehörten noch
einige kleine Fehler bei der Installation, die noch behoben werden mussten und
weitere Restarbeiten, die im folgenden Kapitel beschrieben werden.
7.9
Abschlussarbeiten und Organisation
Zu diesem Zeitpunkt wollte man eigentlich nur noch am Endbericht schreiben
und keine weiteren Arbeiten am Programm oder den dazugehörigen Komponenten tätigen. Da aber noch einige Tests, Oberflächenarbeiten, Behebung kleinerer
162
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Programmfehler und der Abschluss der Einbindung des Plugins anstanden, wurde selbstverständlich an diesen Punkten weitergearbeitet. Die Gruppe war davon
überzeugt, beides gleichzeitig fortführen zu können, um ein solides Endprodukt
abzuliefern. Der Zeitaufwand in jenen Tagen wurde dementsprechend hoch, wie
schon in den Wochen davor, um ein Projekt mit dem gewünschtem Ergebnis
abliefern zu können.
Ein persönliches Gruppenfazit zu Scrum an sich und der Arbeit damit findet
sich in Kapitel sec:fazit.
163
EIS - Energie-Informationssystem
8
Projektgruppe Energie-Informationssyteme
Fazit
Die Arbeit in der Projektgruppe hat sich in mehreren Ebenen abgespielt, weshalb sich das Fazit auch in verschiedene Kapitel teilt.
8.1
Allgemeines Fazit
Nach der Fertigstellung des Projekts kann der Schluss gezogen werden, dass
die entwickelte Software bereits eine solide Grundlage für eine kommerzielle
Weiterentwicklung darstellt. Insbesondere die zum Datenaustausch eingesetzten Formate (Fahrpläne, EEX-Handel), aber auch die intern eingesetzten Datenstrukturen (Lastprofile, Regelzonen etc.) entsprechen den aktuellen industriellen Standards und enthalten somit alle Informationen, die Akteure auf dem
realen Energiemarkt benötigen, um mit Energie zu handeln und ihre Kunden
zu versorgen. Hier hat sich die anfängliche Einarbeitung in die Thematik Ener”
giewirtschaft“ bezahlt gemacht. Auch die übrigen Leistungsmerkmale wie die
Client-Server-Architektur, die Mehrbenutzerfähigkeit, die Austauschbarkeit verschiedener Programmteile und ganz besonders das überaus flexible System zur
Entscheidungsunterstützung bei Lastprognosen und Kaufempfehlungen erfüllen
wesentliche Anforderungen, die ein Energiehändler an ein Programm zur Hilfe
bei seinen Aktivitäten auf dem Strommarkt stellen kann.
8.2
Thematik Energieinformationssysteme
Die Arbeit an dem eigentlichen Thema Energieinformationssysteme war für die
Teilnehmer im ersten Semester mit Sicherheit informativ und interessant, zumal
man sich in dieser Projektgruppe sehr detailliert in diesen Bereich einarbeiten
musste, um sinnvoll ein eigenes Thema zu konstruieren. Gerade aus diesem
Grund ist es eigentlich schade, dass im zweiten Semester die Auseinandersetzung mit dem Thema im Prinzip immer weiter in den Hintergrund gerückt ist
und Dinge wie Implementierungsschwierigkeiten, Softwarearchitektur, Algorithmenwahl usw. in den Vordergrund gerückt sind. Dieser Umschwung ist wahrscheinlich nicht zu vermeiden, da natürlich ein großer Teil an Programmierarbeit
geleistet werden muss und man nicht die ganze Zeit über die Energiethematik
referieren und konzipieren kann, so dass am Ende kein wirkliches Produkt ensteht. Vielleicht wäre aber ein erneuter Bezug zum Thema zur Mitte des zweiten
Semesters interessant gewesen. Zum Beispiel hätte man als Projektgruppe einem
Außenstehenden ein paar Ergebnisse präsentieren können. Wahrscheinlich wäre
es dann zu spät gewesen, Anregungen oder Verbesserungen noch umzusetzen,
aber eventuell hätte eine externe Meinung die Energiethematik in der Gruppe
noch einmal neu aufleben lassen, da man am Ende des Scrums doch des öfteren
nur noch Sprintitems und das Backlog im Kopf hatte.
In diesem Zusammenhang stellte sich besonders die Findung eines eigenen
Projektes für die Gruppe im nachhinein als eine erfahrungsreiche Aufgabe heraus. Da noch niemand wirkliche Erfahrung mit einer solchen Aufgabe hatte, waren die ständigen Zweifel und Nachfragen bei den Betreuern, ob wir überhaupt
ein angemessenes Konzept erstellt haben, sicherlich verständlich. Abschließend
164
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
kann man aber sagen, dass gerade das Finden eines eigenen Themas eine Projektgruppe in dem Sinne weiterbringt, dass man nicht nur einen Teil einer Thematik betrachtet, sondern viele Seiten in Augenschein nimmt. So wächst ganz
automatisch das Verständnis für ein Thema, weil man nicht nur den Blick auf
ein vorgegebenes Projekt gerichtet hat, sondern viele Faktoren beachtet werden
müssen. Dieser Rundumblick wurde bei uns zusätzlich noch durch die weit gefächerten Themen unserer Seminarphase erweitert, so dass die ganze Gruppe
voll im Thema integriert war. Diese Vorarbeit war mit Sicherheit eine hilfreiche
Erfahrung, wie man bestimmte Probleme oder Aufgaben in Zukunft angehen
kann.
8.3
Umsetzung des Entwurfs
Die Umsetzung des Entwurfs lässt sich insgesamt als sehr erfreulich und gradlinig beurteilen. In Kapitel 2.1 werden die Unterschiede zwischen Entwurf und
Umsetzung dargestellt. Hierbei werden nur sehr geringe Abweichungen aufgelistet, was für eine sehr gute konzeptionelle Vorarbeit und Disziplin innerhalb
der Projektgruppe spricht. Es konnten alle als essentiell hervorgehobenen Leistungsmerkmale implementiert werden sowie einige weitere, nützliche Features.
Insbesondere hervorzuheben ist, dass die bei der Umsetzung dieser Features
keine Vereinfachungen gegenüber der realen Welt vorgenommen wurden, um
Probleme zu umgehen oder Arbeit zu sparen. Daher lässt sich abschließend zur
Umsetzung sagen, dass die Projektgruppe EIS“ die selbstgesteckten Ziele er”
reicht hat.
8.4
Implementierung des Programms
In Kapitel 4 wurden bereits die eingesetzten Technologien, Konzepte und Arbeitsweisen vorgestellt. Die Entscheidung, auf Microsoft basierende Lösungen
einzusetzen, erwies sich im Verlauf der Implementierung als vorteilhaft. Es konnte auf eine Vielzahl produktiver Werkzeuge zurückgegriffen werden, die die Umsetzung des Programms deutlich erleichterten. Als Beispiel sei hier der GUIDesigner in der Visual-Studio-Entwicklungsumgebung genannt. Auch die einfache Anbindung des Microsoft SQL Server 2005 an das Programm bestätigte die
Auswahl, eine Lösung aus einem Guss“ zu verwenden.
”
Es soll natürlich nicht verschwiegen werden, dass während der Implementierung auch viele Schwierigkeiten und Probleme auftraten. Eine anscheinend
nicht ganz auf den Gesetzen der Logik basierende Versionsverwaltung der Team
”
Edition“ ließ so manchen Zweifel aufkommen. Die Tatsache, dass jedes dieser
Probleme letztlich gehandhabt werden konnte, spricht jedoch wieder für unsere
Entscheidung.
Dem Umstand, dass für die meisten Mitglieder der Projektgruppe die Entwicklungswelt von Microsoft sowie die Programmiersprache C# völliges Neuland
waren, läßt sich positiv entnehmen, hier neue Erfahrungen und Fähigkeiten gewonnen zu haben. Aus dieser Sicht war es besonders vorteilhaft, die jeweils
aktuellsten Versionen einzusetzen, etwa .NET 2.0, SQL Server 2005 oder Visual
Studio 2005. So merkte man auch, dass .NET ausgereifter zu sein scheint als das
165
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
über die Jahre gewachsenes Java. Aber auch mit .NET und C# zu programmieren hat — wie eigentlich jede Entscheidung — seine Vor- und Nachteile. So
stellte man beim Programmieren fest, dass die Dokumentation bei Java wiederum intuitiver und leichter bedienbar war. Helfen konnte man sich aber durch die
doch sehr große Gemeinschaft um .NET, Microsoft und Co., die einen an den
meisten Stellen durch zahlreiche Foren und Anleitungen weitergebracht hat.
Auch wenn die Implementierung nicht immer glatt lief und zwischenzeitlich
manchen Nerv etwas überstrapaziert hat, so zeigt jedoch die Tatsache, dass alle geforderten Features erfolgreich integriert werden konnten, dass die einzelnen
Mitglieder in der Lage sind, eigenständig Probleme zu lösen und sich nicht durch
gelegentliche Rückschläge von einem einmal eingeschlagenen Weg abbringen lassen.
Würde man vor die Wahl gestellt werden, ob man sich bei einem erneuten Projekt noch einmal für die selben Mittel und Wege entscheiden würde,
so sprechen am Ende dieses Projektes selbstverständlich immer Dinge für und
gegen eine erneute Benutzung. So war einerseits der Einstieg in .NET und C#
sehr komfortabel, einige Arbeitsschritte aber widerum sehr ungewöhnlich und
manchmal auch umständlich. Vor allem das aufgetretene Problem im Bereich
des Multithreading und insebesondere die Tests, um es zu beseitigen, lassen daran zweifeln, dass man eine große Serveranwendung ohne weiteres und in einem
solchen Projektgruppenrahmen im Visual Studio entwickeln kann. So müsste
man vorher sicherstellen, dass man zum Beispiel durch einen Drittanbieter alle
Bereiche des Multithreadings ausgiebig testen kann, wenn dies nicht in Visual
Studio so möglich ist, wie man es individuell erwartet. Dennoch möchte man
die gewonnenen Erfahrung mit der gewählten Umgebung nicht missen und ist
einer erneuten Nutzung nicht abgeneigt, besonders da man jetzt mehrere Seiten
kennt und aus dieser Erfahrung heraus vor und Nachteile entsprechend abwiegen
kann.
8.5
Arbeit als Projektgruppe
Die Gruppe hatte das Glück, aus wirklich sehr umgänglichen Charakteren zusammengesetzt worden zu sein. Die Stimmung in der Gruppe war eigentlich nie
wirklich negativ, was sich natürlich auch auf die Arbeit an sich auswirkt, da selten Spannungen herschten, die das Arbeitsklima geschädigt hätten. Sicherlich
wäre es für eine Projektgruppe interessant gewesen, wenn sie intern persönliche
Konflikte hätte bewältigen müssen und nicht nur Probleme programmiertechnischer Natur, zumal im wahren Leben vermutlich ebenfalls nicht immer ein
reibungloses Klima herschen wird. Dieses Fehlen hat aber niemanden wirklich
gestört, so dass die Arbeit in der Gruppe dennoch viel Erfahrung und auch dem
einen oder anderen Spaß einbrachte.
Einige dieser Erfahrungen konnte man schon im Softwarprojekt sammeln,
doch ist sicherlich allen aufgefallen, dass die Arbeit in der Projektgruppe sich
in wesentlichen Bereichen davon unterscheidet. Wie schön erwähnt, wäre da die
Themenfindung zu nennen, die völlig selbstverantwortliche Zeiteinteilung oder
auch die selbständige Wahl von Vorgehensweisen, Definitionen, Entwicklungsumgebungen usw. Aber gerade diese eigene Verantwortung im Projekt hat einen
Großteil der gewonnenen Erfahrung ausgemacht.
166
EIS - Energie-Informationssystem
8.6
Projektgruppe Energie-Informationssyteme
Die Arbeit mit Scrum
Die Entscheidung, mit einem alternativen Entwicklungsmodell zu arbeiten, war
vielleicht riskant, da man im Studium dem Konzept Scrum noch nicht begegnet war, aber am Ende dieser Projektgruppe darf man wohl sagen, dass dieses
Modell sehr gut mit unserer Gruppe harmonierte.
Zum einen ist das Backlog eine gute Methode gewesen, um die Aufgaben
im Überblick zu behalten, zum anderen gab es aber auch eine Möglichkeit das
Projekt um neue, unerkannte Aufgaben zu erweitern und auf neue Ereignisse
entsprechend zu reagieren.
Die Aufteilung des Semesters in die jeweiligen Sprints gab ebenfalls immer
eine gute Orientierung und man konnte in etwa einschätzen, welche neuen Aufgaben noch hinzugefügt werden können und welche optionalen Aufgaben nicht
mehr mit aufgenommen werden sollten.
Durch die Sprint-Review-Meetings war man des Weiteren motiviert, den Betreuern jeden Monat etwas Neues zu zeigen und das Projekt voranzutreiben.
Die Gruppe hatte so auch die Möglichkeit, sich jederzeit Verbesserungsvorschläge und Wünsche der Betreuer einzuholen und diese direkt im nächsten Sprint
umzusetzen.
Nach dem ersten Sprint hatte die Gruppe im Prinzip immer eine lauffähige
Version des Projektes zur Verfügung, so dass einerseits die Gruppe immer eine Orientierung innerhalb der Sprints hatte und andererseits die Betreuer sich
Informationen über den aktuellen Entwicklungsstand einholen und der Gruppe
weitere Hinweise und Anmerkungen geben konnten.
8.7
Ausblick
Auf Basis der Projektergebnisse wäre es nur logisch, das bestehende Programm
zu einem kommerziellen Energieinformationssystem weiterzuentwickeln. Die Erfassung der Basisdaten ist aus Sicht der Projektgruppe bereits gegeben. Die
fehlenden Leistungsmerkmale, die man von einem kommerziellen System erwarten würde, betreffen in erster Linie abwicklungstechnische Aspekte. Hierzu zählt
beispielsweise ein Rechnungswesen, das automatisch Kundenrechnungen erstellt,
Abbuchungen vornimmt oder Finanzbilanzen erstellt. Darüber hinaus wäre eine
direkte Anbindung an die EEX über eine digitale Schnittstelle anstatt der bisherigen Faxverschickung wünschenswert, um einen reibungsloseren Handel an der
Strombörse zu ermöglichen. Dies ermöglichte auch eine bessere Erstellung von
Kaufempfehlungen, so dass Vorschläge und Entscheidungen anhand einer größeren Datenbasis getroffen werden könnten. Denkbar wäre auch eine verbesserte
Integration von Stromlieferanten, denen man eine direktere Anbindung an das
eigene System über den Webservice bereitstellt, um etwa Angebote unmittelbar in den Datenbestand einzuspeisen. Zusammenfassend lässt sich sagen, dass
mit dem Energieinformationssystem der Projektgruppe eine solide Grundlage
für Energieunternehmen geschaffen wurde, auf der sowohl individuelle als auch
allgemeinere Lösungen entwickelt werden können.
Anbei eine Liste mit möglichen neuen Leistungsmerkmalen, entstanden aus
den vorangegangenen Überlegungen, die man zum Beispiel auf weitere Sprints
innerhalb eines Scrum-Prozesses aufteilen könnte:
167
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Externe Anbindung: Öffentliche Schnittstelle für Stromlieferanten zur Angabe
von Angeboten: So wäre es im Programm möglich, nicht mehr nur durch
manuelle Eingabe, sondern automatisiert und damit arbeitssprarend und
in Echtzeit Angebote anderer Stromhändler zu erfassen.
Verwaltung der Stammdaten: Erweiterte Stammdatenverwaltung z. B. für Erinnerungen an den Benutzer bei wichtigen Ereignissen wie Neuerichtung
von Bilanzkreisen, Tarifumstellung usw.: Dadurch würde verhindert, dass
der Systemnutzer wichtige Geschehnisse in seinem Verantwortungsbereich
nicht bemerkt, wodurch dem Energiehändler Schaden entstehen könnte.
Weboberfläche: Erstellung einer webbasierten GUI: Durch dieses Feature wäre
es nicht mehr nur möglich, das Programm über die vorgegebene Oberfläche, sondern über einen normalen Webbrowser zu nutzen.
Algorithmen zur Kaufempfehlung und Lastprognose: Zusätzliche, mitgelieferte Algorithmen, die nach anderen Maßgaben arbeiten: Man würde dem
Benutzer weitere Algorithem liefern oder alte austauschen, um etwa die
Kaufempfehlung noch zu optimieren und diesen Prozess in der Laufzeit
schneller zu gestalten. So könnte man auch überlegen, ein Update zu liefern, welches einem nach einem bestimmten Zeitraum immer die neuesten
Algorithmen für das Programm zur Verfügung stellt.
Erweiterung der Benutzertypen: Neue Rollen bzw. neue Möglichkeiten zur Rollenverwaltung integrieren: Kunden des Programms könnten hier die individuellen Berechtigungen für die Nutzer selbst konfigurieren.
Energiebörse EEX: Erweiterte Anbindung an den kostenpflichtigen Service der
EEX: Durch dieses Feature fiele die bisher umständliche, aber derzeit nicht
anders mögilche Nutzung der EEX weg, und zusätzlich würde die Interaktion mit ihr beschleunigt.
Lokalisierung: Übersetzung des Programms in andere weitverbreitete Sprachen
wie Englisch oder Französisch: Somit wäre das Programm nicht mehr nur
in der deutschen Sprache verfasst, und man könnte einen internationalen
Kundenstamm aufbauen.
Erweiterte Benutzbarkeit: Anpassung der Oberfläche und Bedienung an Standards der Usability und des barrierefreien Zugangs: Indem möglichst wenige die Benutzung des Program als schwierig empfinden und niemand
gänzlich aufgrund von Behinderungen von der Nutzung ausgeschlossen
wird, erhöht sich die Akzeptanz des Programms ebenfalls.
168
EIS - Energie-Informationssystem
9
Projektgruppe Energie-Informationssyteme
Benutzerhandbuch
9.1
Willkommen
Vielen Dank, dass sie sich für unser Produkt EIS entschieden haben. Dieses
Handbuch soll Ihnen den Einstieg in das Programm erleichtern und Hilfestellungen geben, falls Sie einmal nicht weiter kommen.
Ihr EIS-Team
9.2
9.2.1
Systemvorausetzungen
Hardware
Für den Betrieb des Energieinformationssystems EIS sind folgende Systemvorraussetzungen empfohlen:
• Prozessor mit mind. 2 GHz Taktung
• 1 GB Hauptspeicher (für die Serverkomponente möglichst 2 GB)
• 500 MB Festplattenplatz (für den Server mit Datenbank entsprechend
mehr)
9.2.2
Betriebsystem
Als Betriebssystem werden folgende Plattformen untersützt:
Clientanwendung:
• Windows XP oder höher.
• installiertes .NET-2.0-Framework
Server:
• Windows 2003 Server oder höher.
• installiertes .NET-2.0-Framework
• installierter Internet Information Server
9.2.3
Datenbank
• Microsoft SQL Server 2005 oder
• Microsoft SQL Server 2005 Express
169
EIS - Energie-Informationssystem
9.3
Projektgruppe Energie-Informationssyteme
Installation
In diesem Kapitel werden die Schritte erklärt, die nötig sind um eine neue Installation von EIS in Betrieb zu nehmen. Diese Schritte müssen vom Systemadministrator vorgenommen werden.
9.3.1
Installation der Serverkomponenten
Legen Sie die DVD–ROM in das DVD–ROM–Laufwerk ein. Wenn der Autostart
nicht deaktiviert wurde, wird automatisch ein Fenster geladen, in dem Sie auf
“Server-Komponenten“ klicken müssen. Daraufhin startet das Installationsprogramm für die Severkomponenten. Hier werden Sie aufgefordert, einen Namen
für das virtuelle Verzeichnis im Internet Information Server anzugeben. Diesen
Namen müssen Sie sich merken, da er für die Konfiguration der Clientanwendung benötigt wird.
9.3.2
Datenbank aufsetzen
Im Anschluss an die Serverinstallation muss die Datenbank eingerichtet werden.
Dazu benötigen Sie einen Server mit installiertem SQL Server 2005. Dies kann
auch derselbe Server sein, auf dem auch der IIS läuft. Um Hilfe für die Installation des MS SQL Server zu erhalten, konsultieren Sie die Dokumentation des
SQL-Servers. Dabei ist es wichtig, dass Sie für die Anmeldung am SQL-Server
den so genannten Mixed Mode erlauben. Näheres dazu finden sie ebenfalls in
der SQL-Server-Dokumentation. Nachdem Sie den Datenbankserver erfolgreich
installiert haben, müssen Sie die mitgelieferte Datenbankdatei zum Server hinzufügen. Dazu benötigen Sie das SQL Server Management Studio, welches frei
verfügbar ist und auf den Internetseiten von Microsoft heruntergeladen werden
kann. Im Folgenden wird beschrieben, wie Sie die mitgelieferte Grunddatenbank
mithilfe des SQL Management Studios installieren können.
Starten Sie zunächst das SQL Server Management Studio. Nachdem Sie sich
erfolgreich an Ihrem Server angemeldet haben, klicken Sie im Objektexplorer
mit der rechten Maustaste auf den Eintrag Databases (siehe Abbildung 85).
170
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 85: SQL Server Management Studio
Durch den Klick auf Attach ... öffnet sich ein weiteres Fenster (siehe Abbildung 86),
in dem Sie zunächst auf Add ... klicken müssen. Daraufhin erscheint ein Dateibrowser, mit dessen Hilfe Sie die Datei ”EISDB.mdf” auswählen. Diese Datei
befindet sich in dem Ordner, in welchem Sie die Serverkomponenten der EISSoftware installiert haben (Üblicherweise c:/inetpub/wwwroot/SetupServer).
Die Datei wird jetzt in der Liste “Databases to attach“ angezeigt. Klicken Sie
nun auf OK, um den Vorgang abzuschliessen. Die Datenbank ist nun installiert!
Versichern Sie sich, dass der Nutzer angelegt wurde!
Wenn der Datenbankserver und der Webserver auf verschiedenen Rechnern
installiert sind, muss der Datenbankserver so konfiguriert werden, dass das TCPProtokoll genutzt wird. Um das TCP-Protokoll zu aktivieren, starten Sie den
SQL Server Configuration Manager. Im Unterpunkt SQL Native Client Configuration / Client Protocols müssen Sie das TCP/IP-Protokoll aktivieren. Bitte
beachten Sie, dass für die Nutzung des Protokolls der dazu jeweilige Port (Standard ist 1433) in Ihrer Firewallsoftware freigeschaltet werden muss. Konsultieren
Sie dazu die Hilfe oder Dokumentation Ihrer Firewallsoftware oder wenden Sie
sich an Ihren Systemadministrator.
171
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 86: SQL Server Management Studio - Datenbankdatei auswählen
9.3.3
Konfiguration der Datenbankverbindung
Um die Verbindung des EIS-Servers zur Datenbank zu erstellen, starten Sie unter Systemsteuerung / Verwaltung den Internet-Informationsdienste-Manager.
Wählen Sie das virtuelle Verzeichnis aus, das Sie bei der Serverinstalltion angegeben haben und klicken Sie mit der rechten Maustaste auf den Eintrag “Eigenschaften“. Auf der Karteikarte “ASP.NET“ wählen Sie bitte unter ASP.NETVersion den Eintrag mit der Versionsnummer 2 aus. Klicken Sie dann auf die
Schaltfläche Konfiguration bearbeiten .... Daraufhin wird ein neues Fenster geöffnet. Hier müssen Sie nun die Verbindungszeichenfolge “EISSQLSERVER“ bearbeiten. Tragen Sie hier eine gültige Zeichenfolge für die Verbindung zu Ihrem
Datenbankserver ein. Beachten Sie bitte, dass Sie einem neu angelegten Datenbanknutzer auch die entsprechenden Rechte an der EISDB erteilen, siehe dazu
Abbildung 87.
9.3.4
EEX-Marktdaten aktualisieren
Nachdem Sie die Datenbankkonfiguration abgeschlossen haben, führen Sie die
Verknüpfung ”EEX-Marktdaten aktualisieren” auf dem Desktop des Servers aus.
Dies ist nur einmal nach der Installation nötig. Wählen Sie die Option ”Alle
172
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 87: Vergabe der Benutzerrechte
Marktdaten aktualisieren” und klicken Sie auf ”Ausführen” (siehe Abbildung 88.
Ohne diesen Schritt sind die EEX Funktionen des EIS nicht verfügbar.
9.3.5
Installation der Clientanwendung
Legen Sie die DVD–ROM in das DVD–ROM–Laufwerk ein. Wenn der Autostart
nicht deaktiviert wurde, wird automatisch ein Fenster geladen, in dem Sie auf
“Client-Komponenten“ klicken müssen. Daraufhin startet das Installationsprogramm für die Clientanwendung. Folgen Sie den Anweisungen auf dem Bildschirm, um den Client zu installieren. Beim ersten Start der Clientanwendung
wird der Nuzer aufgefordert, die URL zum EIS-Server anzugeben. Diese muss
mit dem Präfix “http://“, gefolgt vom Servernamen und nach einem Doppelpunkt der Portnummer des Webservers (Standard ist 80), angegeben werden.
Nach einem weiteren Schrägstrich geben Sie den unter der Serverinstallation
festgelegten Namen gefolgt von “/Service.asmx“ an.
173
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 88: Auswahlfenster zum Aktualisieren der EEX Marktdaten
9.4
9.4.1
Erste Schritte
Programm starten
Öffnen Sie das EIS–Symbol auf dem Desktop oder starten Sie die Verknüpfung
im Windows–Startmenü.
9.4.2
Serveradresse angeben
Beim ersten Start des Programms werden Sie nach der URL des Webservice auf
der Serverseite gefragt. Geben Sie die entsprechende URL an und klicken Sie
auf ”Speichern”. Diese Abfrage ist einmalig.
9.4.3
Einloggen
Allgemeine Hinweise zum Loginfenster: Um sich am Programm anzumelden,
müssen Sie einen Benutzernamen und ein Passwort im Loginfenster eingeben.
Diese Daten erhalten Sie bei Ihrem Systemadministrator. Um sich einzuloggen,
geben Sie ihren Benutzernamen und ihr entsprechendes Passwort ein und klicken
Sie auf ”Anmelden”. Um den Vorgang abzubrechen, klicken Sie auf ”Abbrechen”.
9.4.4
Administratorpasswort ändern
Loggen Sie sich mit dem Benutzernamen ”admin” ein. Das Passwort lautet ebenfalls ”admin” (ohne Anführungszeichen). Wählen Sie aus dem Menü den Punkt
”Systemnutzer”. Wählen Sie dann das Admin-Konto aus, und klicken Sie die
174
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Schaltfläche ”Bearbeiten”. Ändern Sie die Daten wie gewünscht. Besonderes
Augenmerk gilt hier dem Passwort des Administratorkontos. Geben Sie unter
”Passwort” Ihr neues Kontopasswort ein, bestätigen Sie es noch einmal in dem
Feld darunter. Nach erfolgter Eingabe klicken Sie ”Speichern”, um die Änderungen zu übernehmen.
Nun wird es Zeit, einige Nutzer anzulegen, die für die einzelnen Funktionen
des Programms Zugriffsrechte haben.
9.4.5
Benutzer anlegen
Legen Sie Benutzer mit den jeweiligen Rollen an. Genauere Informationen zu
der Erstellung von Systemnutzern und verschiedenen Rollen (Rechten), die ein
Systemnutzer haben kann, finden Sie im Abschnitt Systemnutzer“.
”
175
EIS - Energie-Informationssystem
9.5
Projektgruppe Energie-Informationssyteme
Der Startbildschirm
Abbildung 89: Die Startoberfläche des Programms
Nach dem Einloggen sehen Sie als erstes den Starbildschirm, Abbildung 89,
des EIS. Hier finden Sie eine Übersicht über die wichtigsten Daten, Termine und
Vorfälle, die das EIS betreffen. Im Bereich ”Überblick” finden Sie oben eine Liste
der aktuellen Störungen. Darunter eine Liste mit in weniger als einem Monat
auslaufenden Kundenverträgen und widerrum darunter eine Liste mit bald auslaufenden Lieferverträgen. Auf der rechten Seite finden Sie ein Tortendiagramm,
welches die prozentuale Verteilung der Tarife verdeutlicht.
Direkt unter dem überlick finden Sie das sog. ToDo Panel.
176
EIS - Energie-Informationssystem
9.6
Projektgruppe Energie-Informationssyteme
Das ToDo-Panel
Im ToDo-Panel, siehe Abbildung 90, können Sie ihre persönlichen Aufgaben und
Notizen verwalten. Klicken Sie ”Anlegen” um eine neue Aufgabe anzulegen.
Abbildung 90: Hier geben Sie die Daten in die ToDo-Liste ein
Füllen Sie die Felder aus. Als Code können Sie eine bliebige Zeichengfolge
(bis zu 10 Stellen) wählen, die Ihnen später das wiederfinden erleichtert. Unter
Status wählen Sie den aktuellen Status der Aufgabe aus. Unter ”Aufgabe” geben
Sie dann eine Beschreibung der Aufgabe ein.
Mit einem Klick auf ”Bearbeiten” können Sie eine bestehende Aufgabe öffnen
und den Status und/oder die Aufgabenbeschreibung ändern.
Mit einem Klick auf ”Löschen” können Sie eine abgeschlossene Aufgabe aus
der Liste löschen.
177
EIS - Energie-Informationssystem
9.7
Projektgruppe Energie-Informationssyteme
Fehlermeldungen
Während der Benutzung des EIS werden Sie das ein oder andere Mal auf eine
Fehlermeldung stoßen. Es gibt zwei Arten von Fehlern, die auftreten können.
Zunächst einmal so genannte Exceptions. Dieses sind Fehler, die durch Falscheingaben und/oder Datenbankfehler erzeugt werden. Sollte solche eine Exception
auftreten, weist Sie das EIS mit einem Fenster darauf hin. Dieses sieht wie in
Abbildung 91 aus.
Abbildung 91: Fehlermeldung bei inkorrekten Daten
Hier finden Sie eine Beschreibung des Fehlers und ein Eingabefeld, in dem Sie
einen Kommentar für den Systemadministrator hinterlassen können. Beispielsweise können Sie hier Ihre letzten Schritte bevor der Fehler auftrat eintragen
und an den Administrator Ihres EIS senden.
Ein zweiter Fehlertyp der auftreten kann, ist der in Abbildung 92 gezeigte.
Diese Meldung weist Sie darauf hin, dass Sie eine Funktion aufgerufen haben,
für die Ihr Benutzerkonto keine Berechtigung hat.
Abbildung 92: Eine Fehlermeldung, die Sie auf unzureichende Rechte hinweist.
178
EIS - Energie-Informationssystem
9.8
Projektgruppe Energie-Informationssyteme
Auswahlfenster
Im Laufe der Benutzung von EIS werden Sie auf einige Auswahlfenster stoßen,
die sich nach dem Klick auf ein Lupensymbol öffnen. Hier eine kleine Übersicht:
9.8.1
Auswahl für Tarife
Abbildung 93: Das Auswahlfenster für Tarife
Wählen Sie einen Tarif aus und klicken Sie auf ”Auswählen”, um den Tarif
auszuwählen. Ein Klick auf ”Abbrechen” bricht die Auswahl ab (siehe Abbildung
93).
9.8.2
Auswahl für Regelzonen
Abbildung 94: Das Auswahlfenster für Regelzonen
Wählen Sie eine Regelzone aus und klicken Sie auf ”Auswählen”, um die entsprechende Regelzone zu übernehmen. Mit einem Klick auf ”Abbrechen” brechen
Sie die Auswahl ab. Um die Regelzonen einzugrenzen, können Sie einen Suchbegriff und einen Suchbereich eingeben und mit ”Suchen” eine Suche starten (siehe
Abbildung 94).
179
EIS - Energie-Informationssystem
9.8.3
Projektgruppe Energie-Informationssyteme
Auswahl für Lastprofile
Abbildung 95: Das Auswahlfenster für Lastprofile
Wählen Sie ein Lastprofil aus und klicken Sie auf ”Auswählen”, um es zu
übernehmen. Klicken Sie auf ”Abbrechen”, um die Auswahl abzubrechen, ohne
ein Lastprofil zu übernehmen (siehe Abbildung 95).
9.8.4
Auswahl für Bilanzkreise
Abbildung 96: Das Auswahlfenster für Bilanzkreise
Wählen Sie einen Bilanzkreis aus und klicken Sie auf ”Auswählen”, um den
Bilanzkreis zu übernehmen. Mit einem Klick auf ”Abbrechen” brechen Sie die
Auswahl ab. Um die Bilanzkreise einzugrenzen, können Sie einen Suchbegriff
und einen Suchbreich eingeben und mit ”Suchen” entsprechende Bilanzkreise
auflisten (siehe Abbildung 96).
180
EIS - Energie-Informationssystem
9.9
Projektgruppe Energie-Informationssyteme
Kunden
In der Kundenverwaltung können Kundendaten angelegt, verändert und gelöscht werden. Außerdem werden hier Kundenverträge den Kunden zugeordnet. Es können Kundenverträge neu hinzugefügt, bearbeitet und auch gelöscht
werden. In den folgenden Abschnitten erfahren Sie, wie Kundendaten und deren Verträge angelegt, bearbeitet und gelöscht werden. Abbildung 97 zeigt die
Oberfläche der Kundenverwaltung.
Abbildung 97: Die Oberfläche zur Verwaltung von Kunden und deren Verträge
9.9.1
Kunden anlegen
Zum Anlegen eines Kunden müssen Sie als Kundenbetreuer eingeloggt sein.
Wählen Sie im Auswahlmenü oder dem Programmmenü den Punkt ”Kunden”
aus. Klicken Sie die Schaltfläche ”Anlegen...” und füllen Sie die entsprechenden
Felder aus (siehe Abbildung 98). Wenn Sie alle benötigten Felder korrekt ausgefüllt haben (die Überprüfung der Eingaben erfolgt im übrigen transparent, d.h.,
während der Eingabe werden ihre Angaben auf Stimmigkeit geprüft), klicken
Sie auf die Schaltfläche Speichern“. Ihr Kundendatensatz wird vom Programm
”
181
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
abgespeichert und steht Ihnen in der Kundenverwaltung zur Verfügung. Wollen
Sie den eigegebenen Datensatz nicht speichern, so klicken Sie auf Abbrechen“
”
oder schließen Sie das Fenster mit einem Klick auf das Kreuz in der rechten
oberen Ecke des Eingabefensters.
Abbildung 98: Einen neuen Kunden anlegen
9.9.2
Kunden bearbeiten
Zum Bearbeiten eines Kundendatensatzes geben Sie einen Suchbegriff (z.B.
Kundennummer, (Nach–)Namen und oder andere bekannte Merkmale des Kunden in die am oberen Rand der Kundenverwaltung befindliche Suchmaske ein.
Wählen Sie die Art der Suche im Klappmenü links neben der Suchmaske aus, geben Sie den Suchbegriff ein und klicken sie auf die Schaltfläche ”Suchen”. Wählen
Sie das Ergebnis bzw. eines der Ergebnisse der Suche aus, und klicken Sie die
Schaltfläche ”Bearbeiten ...”. Die Maske für Kundendaten öffnet sich mit den
Daten des ausgewählten Kundendatensatzes (siehe Abbildung 99). Fügen Sie
die gewünschten Änderungen ein und klicken Sie die Schaltfläche ”Speichern”.
Um den Vorgang abzubrechen, klicken Sie auf Abbrechen“ oder auf das Kreuz
”
in der Ecke oben rechts der Maske.
Abbildung 99: Einen bestehenden Kunden bearbeiten
182
EIS - Energie-Informationssystem
9.9.3
Projektgruppe Energie-Informationssyteme
Kunden löschen
Abbildung 100: Einen bestehenden Kunden löschen
Um einen Kundendatensatz zu löschen, vollziehen Sie eine Suche wie unter
”Kundendaten bearbeiten” beschrieben, oder wählen Sie den gewünschten Kundendatensatz direkt in der Kundendatenliste aus. Klicken Sie jetzt die Schaltfläche ”Löschen”. bestäigen Sie die Sicherheitsabfrage mit einem Klick auf die
Schaltfläche ”Ja” (siehe Abbildung 100). Der Kunde ist nun aus der Datenbank
gelöscht. Zu beachten: Es können nur Kundendaten gelöscht werden, die nicht
in einem laufenden Kundenvertrag verankert sind.
9.9.4
Kundenvertrag anlegen
Abbildung 101: Einen neuen Kundenvertrag anlegen
Um einen Kundenvertrag anzulegen, wählen Sie zunächst einen Kunden aus,
für den Sie einen Vertrag anlegen möchten. Wenn Sie einen Kunden ausgewählt
haben, erscheinen auf der Vertragsanzeige alle Verträge, die diesem Kunden bereits zugeordnet sind. Klicken Sie nun die Schaltfläche Anlegen ...“, um einem
”
183
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Kunden einen neuen Vertrag zuzuordnen. Füllen Sie alle Felder aus (siehe Abbildung 101). Die Einträge für Lastprofil, Tarif, Regelzone, Bilanzkreis wählen
Sie aus dem Menü aus, welches sich durch klicken des Lupensymbols öffnet, das
rechts neben dem jeweiligen Textfeld positioniert ist. Wenn Sie alle Felder auf
der linken Seite ausgefüllt haben, werden die Einträge der rechten Seite automatisch berechnet. Wenn Sie mit den Eingaben einverstanden sind, klicken Sie
auf die Schaltfläche Speichern“ oder auf die Schaltfläche Abbrechen“, wenn Sie
”
”
die Daten nicht speichern wollen.
Auf den folgenden vier Abbildungen sehen Sie die Fenster, in denen Sie für
einen Vertrag ein Lastprofil (siehe Abbildung 102), einen Tarif (siehe Abbildung 103), eine Regelzone (siehe Abbildung 104) und einen Bilanzkreis (siehe
Abbildung 105) auswählen.
Abbildung 102: Einem Kunden ein Lastprofil zuweisen
Abbildung 103: Einem Kunden einen Tarif zuweisen
184
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 104: Einem Kunden eine Regelzone zuweisen
Abbildung 105: Einem Kunden einen Bilanzkreis zuweisen
9.9.5
Kundenvertrag bearbeiten
Wenn Sie einen bestehenden Kundenvertrag bearbeiten wollen, wählen Sie zunächst den betreffenden Kunden aus der Liste aus. Es erscheinen nun alle Verträge, die diesem Kunden zugeordnet sind. Wählen Sie den Vertrag aus, den Sie
bearbeiten wollen, indem Sie auf die Schaltfläche Bearbeiten...“ klicken oder
”
doppelklicken Sie auf den zu bearbeitenden Vertrag. Es erscheint eine weitere
Maske auf dem Bildschirm, die mit den Vertragsdaten gefüllt ist (siehe Abbildung 106). Nehmen Sie die notwendigen Änderungen des Vertrags vor und
drücken Sie anschließend auf die Schaltfläche Speichern“ wenn Sie die Daten
”
speichern wollen oder klicken Sie auf Abbrechen“ wenn Sie die Daten nicht
”
ändern wollen.
9.9.6
Kundenvertrag löschen
Wenn Sie einen bestehenden Kundenvertrag bearbeiten wollen, wählen Sie zunächst den betreffenden Kunden aus der Liste aus. Es erscheinen nun alle Verträ185
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 106: Einen bestehenden Kundenvertrag bearbeiten
ge, die diesem Kunden zugeordnet sind. Wählen Sie den zu löschenden Vertrag
an, so dass dieser blau markiert ist und klicken Sie die Schaltfläche Löschen“.
”
186
EIS - Energie-Informationssystem
9.10
Projektgruppe Energie-Informationssyteme
Lastprofile
In der Lastprofilverwaltung (siehe Abbildung 107) können Sie neue Lastprofile anlegen, bearbeiten oder löschen. Sie können bestehende Lastprofile mit der
gegebenen Suchfunktion suchen. Durch klicken der Schaltfläche Zurücksetzen“
”
wird Ihre Eingabe aus der Suchmaske entfernt.
Abbildung 107: Die Oberfläche zur Verwaltung von Lastprofilen
9.10.1
Lastprofile anlegen
Sie können ein neues Lastprofil anlegen, indem Sie die Schaltfläche Anlegen...“
”
klicken. Es öffnet sich eine Eingabemaske (siehe Abbildung 108), in der Sie die
geforderten Daten eingeben müssen. Die Eingabe eines Lastprofils ist zeitaufwendig, da ein vollständiges Lastprofil aus 96 Eingaben besteht. Wenn Sie das
neue Lastprofil speichern möchten, klicken Sie auf die Schaltfläche Speichern“.
”
Um den Vorgang abzubrechen, klicken Sie auf Abbrechen“.
”
187
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 108: Ein neues Lastprofil anlegen
9.10.2
Lastprofile bearbeiten
Sie können bestehende Lastprofile einfach bearbeiten. Wählen Sie das zu bearbeitende Lastprofil aus der Liste aus, klicken Sie anschließend die Schaltfläche
Bearbeiten...“. Es öffnet sich eine Eingabemaske (siehe Abbildung 109), die mit
”
den Daten des zu bearbeitenden Lastprofils gefüllt ist. Ändern Sie die Felder,
die Sie ändern möchten und drücken Sie zum Bestätigen auf die Schaltfläche
Speichern“. Um den Vorgang abzubrechen, klicken Sie auf Abbrechen“.
”
”
Abbildung 109: Ein Lastprofil bearbeiten
9.10.3
Lastprofile löschen
Wenn Sie ein Lastprofil löschen wollen, markieren Sie das zu löschende Lastprofil
und drücken Sie auf Löschen“. Bestätigen Sie die folgende Sicherheitsabfrage
”
mit Ja“, wenn Sie das ausgewählte Lastprofil löschen möchten oder drücken Sie
”
Nein“, wenn Sie das Lastprofil nicht löschen wollen.
”
188
EIS - Energie-Informationssystem
9.11
Projektgruppe Energie-Informationssyteme
Tarife
In der Tarifverwaltung (siehe Abbildung 111) können Tarife hinzugefügt,
bearbeitet oder gelöscht werden. Bestehende Tarife können auf aktiv“ oder auf
”
inaktiv“ gestellt sein. Ist ein Tarif aktiv, so kann in der Kundenverwaltung
”
ein Kundenvertrag mit diesem Tarif eingegeben werden. Ist er nicht aktiv, so
erscheint er nicht in der Kundenverwaltung.
Abbildung 110: Die Oberfläche zur Verwaltung von Tarifen
9.11.1
Tarife anlegen
Wenn Sie einen Tarif anlegen möchten, klicken Sie auf die Schaltfläche Anle”
gen...“. Es erscheint ein neues Fenster (siehe Abbildung 111). Hier tragen Sie
die dort verlangten Attribute ein. Ein Tarif kann nur dann übernommen werden, wenn alle Felder korrekt ausgefüllt sind. Haben Sie einen Tarif angelegt,
erscheint er in der Liste der Tarife als inaktiv. Um diesen Tarif verwenden zu
können, müssen Sie ihn durch Klicken auf die Schaltfläche (De)aktivieren“ ak”
tivieren.
189
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 111: Einen neuen Tarif anlegen
9.11.2
Tarife bearbeiten
Wenn Sie einen Tarif bearbeiten möchten, wählen Sie diesen aus der Liste aus
und klicken Sie auf die Schaltfläche Bearbeiten...“ oder doppelklicken Sie auf
”
den zu bearbeitenden Tarif. Es erscheint ein neues Fenster (siehe Abbildung
112). Sie können nun die Attribute bearbeiten. Durch Betätigen der Schaltfläche Speichern“ werden die neuen Werte in das Programm übernommen. Durch
”
Betätigen der Schaltfläche Abbrechen“ werden keine Änderungen am Tarif ge”
speichert und der Vorgang abgebrochen.
Abbildung 112: Einen Tarif bearbeiten
9.11.3
Tarife löschen
Sie können nur dann einen Tarif löschen, wenn er inaktiv ist. Möchten Sie einen
inaktiven Tarif löschen, so klicken Sie auf die Schaltfläche Löschen“. Der Tarif
”
wird nun aus der Liste entfernt.
190
EIS - Energie-Informationssystem
9.12
Projektgruppe Energie-Informationssyteme
Fahrpläne
In der Fahrplanverwaltung (siehe Abbildung 113) können Sie Ihre Fahrpläne
automatisch erstellen. Das Ergebnis ist eine XML-Datei im ESS-Format. Sie
können hier natürlich auch problemlos bereits erstellte Fahrpläne löschen. Wie
Sie dies machen, erfahren Sie in den nächsten Abschnitten.
Abbildung 113: Die Oberfläche zur Erstellung von Fahrplänen
9.12.1
Fahrplan erstellen
Wenn Sie einen Fahrplan erstellen möchten, brauchen Sie lediglich ein Datum
auszuwählen, für das ein Fahrplan erstellt werden soll. Außerdem müssen Sie
noch den entsprechenden Bilanzkreis und die Regelzone bestimmen. Diese wählen Sie aus den neben der Datumseingabe positionierten Ausklappmenüs. Sollten
Sie hier keine Bilanzkreise oder Regelzonen auswählbar sein, überprüfen Sie unter dem Menüpunkt Bilanzkreise und Regelzonen“ ob Sie eine CSV–Datei mit
”
Bilanzkreis– und Regelzonendaten in die Datenbank übertragen haben. Wenn
Ihre Eingaben vom System akzeptiert wurden, müssen Sie noch einen Zielordner
für die erstellte XML–Datei bestimmen. Der Name der erzeugten XML–Datei
191
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
wird automatisch nach den Regeln der ETSO bestimmt. Erstellte Fahrpläne finden Sie in der Liste Vorhandene Fahrpläne“. Durch Markieren eines erstellten
”
Fahrplanes in dieser Liste wird der Inhalt der XML–Datei auf der rechten Seite
angezeigt (siehe Abbildung 114).
9.12.2
Fahrplan löschen
Sie können Fahrpläne entweder für einen Tag löschen oder gleich alle vorhandenen. Hierzu geben Sie entweder ein Datum ein, für das alle vorhandenen Fahrpläne entfernt werden sollen, oder klicken Sie auf die Schaltfläche Löschen“ neben
”
dem Text Alle Fahrpläne löschen“. Achtung: Durch diese Maßnahme werden
”
alle Fahrpläne unwiderruflich aus der Datenbank gelöscht! Eine Löschung der
zugehörigen XML-Dateien findet allerdings nicht statt. Diese Dateien müssen
Sie gegebenenfalls manuell aus dem Dateisystem Ihres Computers löschen.
Abbildung 114: Einen Fahrplan im Browserfenster anzeigen
192
EIS - Energie-Informationssystem
9.13
Projektgruppe Energie-Informationssyteme
Kaufempfehlungen
Um eine Kaufempfehlung zu erhalten, sind nur wenige Schritte notwendig.
Beachten Sie, dass zur Austellung einer Kaufempfehlung zuvor eine Lastprognose generiert worden sein muss, da sich der Kaufempfehlungsalgorithmus auf
Daten und Vorgaben aus einer Lastprognose angewiesen ist (siehe ”Lastprognosen”).
9.13.1
Schritt 1
Wählen Sie den Menüpunkt ”Kaufempfehlungen” aus dem (Programm–)Menü.
Es öffnet sich die Programmseite für Kaufempfehlungen. Wenn Sie eine Lastprognose als Basis gewählt haben (siehe Abbildung 115), klicken Sie auf die
Schaltfläche ”Weiter...”, um zu Schritt 2 zu gelangen.
Abbildung 115: Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 1
193
EIS - Energie-Informationssystem
9.13.2
Projektgruppe Energie-Informationssyteme
Schritt 2
Im 2. Schritt wählen Sie nun aus den bestehenden Lieferverträgen mit Lieferanten diejenigen Verträge aus, die entweder auf jeden Fall oder auf keinen Fall in
die Kaufempfehlung mit einbezogen werden sollen (siehe Abbildung 116). Dazu
finden Sie in der äußerst rechten Spalte für jeden Vertrag eine sog. ”Checkbox”,
also ein Kästchen in dem Sie mit einem Mausclick einen Haken setzen (Vertrag
miteinbeziehen) oder entfernen können (Vertrag nicht miteinbeziehen). Sofern
Sie die initiale graue Markierung belassen, bleibt es dem Algorithmus freigestellt, das betreffende Angebot zu berücksichtigen oder nicht. Haben Sie ihre
Auswahl getroffen klicken Sie ”Weiter...”, um zu Schritt 3 der Kaufempfehlung
zu gelangen.
Abbildung 116: Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 2
194
EIS - Energie-Informationssystem
9.13.3
Projektgruppe Energie-Informationssyteme
Schritt 3
In diesem Schritt wählen Sie das Plugin (externes Programmpaket) mit dem
von Ihnen gewünschten Algorithmus zur Erstellung einer Kaufempfehlung (siehe Abbildung 117). Im oberen Auswahlfenster wird Ihnen eine Auswahl von
verfügbaren Plugins angezeigt. Wählen Sie das gewünschte Plugin mit einem
Klick aus. In der unteren Hälfte des Programmfensters wird die Versionsinformation sowie eine kurze Beschreibung des gewählten Plugins angezeigt. Haben
Sie sich für ein Plugin entscheiden, klicken Sie ”Weiter...”, um zu Schritt 4 zu
gelangen.
Abbildung 117: Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 3
195
EIS - Energie-Informationssystem
9.13.4
Projektgruppe Energie-Informationssyteme
Schritt 4
In diesem Abschnitt konfigurieren Sie die Einstellungen des in Schritt 3 gewählten Plugins. Je nach Plugin werden Ihnen hier Möglichkeiten zur Anpassung
des entsprechenden Algorithmus gezeigt. Für Informationen zu den jeweiligen
verfügbaren Einstellungsmöglichkeiten konsultieren Sie die Dokumentation des
Plugins in Schritt 3 oder der entsprechenden Dokumentation die jedem Plugin
beiliegen sollte. Sobald Sie alle Einstellungen ihren Wünschen angepasst haben,
klicken Sie ”Prüfen” (siehe Abbildung 118). Daraufhin werden die eingegebenen
Parameter auf Gültigkeit überprüft. Sind sie nicht gültig, erhalten Sie eine Benachrichtigung und können die Werte korrigieren. Sind sie gültig, ändert sich
die Beschriftung des Buttons zu ”Erstellen”. Klicken Sie ihn erneut, um die
Kaufempfehlung generieren zu lassen und zum nächsten Schritt der Kaufempfehlungserstellung zu gelangen.
Abbildung 118: Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 4
196
EIS - Energie-Informationssystem
9.13.5
Projektgruppe Energie-Informationssyteme
Schritt 5
Im 5. Schritt sehen Sie das Ergebnis der Berechnung der Kaufempfehlung. Im
Bereich ”Basisinformationen” finden Sie übersichtsdaten für die abgeschlossene
Berechnung (siehe Abbildung 119). ”Nr.” bezeichnet die laufende Nummer der
Kaufempfehlung. ”Erstellt” stellt das Datum der Erstellung der Kaufempfehlung
dar. Das Zeitfenster für die Gültigkeit der Kaufempfehlung ergibt sich aus den
Punkten ”Gültig ab” und ”Gültig bis”. ”Gesamtbedarf” gibt den Bedarf an Energie in MWh wieder der für den entsprechenden Zeitraum der zugrundeliegenden
Lastprognose gilt. ”Gesamteinkauf” gibt die Energiemenge in MWh an, die der
Kaufempfehlungsalgorithmus zur Deckung des Gesamtbedarfs an Energie vorgeschlagen hat.
Im unteren Bereich werden in einer übersicht auf der linken Seite die zum Abschluss vorgeschlagenen Lieferangebote dargestellt. Auf der rechten Seite werden
bereits abgeschlossene Lieferverträge angezeigt.
Klicken sie auf ”Weiter”, um zum letzten Schritt zu gelangen.
Abbildung 119: Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 5
197
EIS - Energie-Informationssystem
9.13.6
Projektgruppe Energie-Informationssyteme
Schritt 6
Im letzten Schritt der Kaufempfehlung können Sie Änderungen an der erstellten
Kaufempfehlung vornehmen, dazu können Sie auf der rechten Seite der Ansicht
andere infrage kommende Angebot zu der Kaufempfehlung hinzufügen (siehe
Abbildung 120). Wählen Sie dazu ein infragekommendes Angebot auf der rechten Seite und klicken sie ”Hinzufügen” um das Angebot zur Kaufempfehlung
hinzuzufügen. Bereits hinzugefügte Lieferangebote können Sie auf der linken
Seite einsehen. Um eines dieser Angebote wieder aus der Liste zu entfernen,
wählen Sie das entsprechende Angebot aus, und klicken Sie auf ”Löschen”.
Um die Kaufempfehlung und damit die empfohlenen Angebote abzuschließen, klicken Sie auf die Schaltfläche ”Fertigstellen...”.
Abbildung 120: Die Oberfläche zur Erstellung von Kaufempfehlungen: Schritt 6
198
EIS - Energie-Informationssystem
9.14
Projektgruppe Energie-Informationssyteme
Lieferanten
In der Lieferantenverwaltung (siehe Abbildung 121) haben Sie Zugriff auf die
Daten der im System gespeicherten Lieferantendaten und deren Verträge. In den
folgenden Abschnitten erfahren Sie, wie Sie neue Lieferanten in die Datenbank
speichern, bearbeiten oder auch löschen können. Außerdem wird erklärt, wie Sie
zu einem Lieferanten gehörende Lieferverträge bearbeiten oder löschen können.
Sie erfahren außerdem, wie Sie neue Verträge für bestimmte Lieferanten erstellen
können.
Abbildung 121: Die Oberfläche zur Verwaltung von Lieferanten
9.14.1
Lieferanten anlegen
Um einen neuen Lieferanten anzulegen, klicken Sie in der Lieferantenverwaltung
auf die Schaltfläche Anlegen...“. Das Programm öffnet eine Eingabemaske, in
”
welche Sie die für einen Lieferanten wichtigen Daten eingeben müssen. Wenn
Sie Felder auslassen, kann der neue Lieferant nicht angelegt werden. Haben Sie
alle Felder korrekt ausgefüllt, so klicken Sie die Schaltfläche Speichern“, um
”
den neuen Lieferanten im System zu speichern, oder klicken Sie die Schaltfläche
199
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbrechen“, um den Vorgang abzubrechen, ohne einen neuen Lieferanten zu
”
speichern.
9.14.2
Lieferanten bearbeiten
Um einen bestehenden Lieferanten zu bearbeiten, suchen Sie diesen über die
Suchfunktion des Programms aus. Markieren Sie den zu bearbeitenden Lieferanten, so dass dieser blau hinterlegt wird, und klicken Sie auf die Schaltfläche
Bearbeiten...“. Ändern Sie die Daten ab, die Sie ändern möchten, und betätigen
”
Sie anschließend die Schaltfläche Speichern“ (siehe Abbildung 122). Wenn die
”
von Ihnen geänderten Daten zulässig sind, werden diese übernommen. Wollen
Sie die Daten nicht speichern, so klicken Sie auf die Schaltfläche Abbrechen“
”
oder auf das Kreuz in der rechten oberen Ecke der Eingabemaske.
Abbildung 122: Ein bestehenden Lieferanten bearbeiten
9.14.3
Lieferanten löschen
Wenn Sie einen Lieferanten löschen möchten, markieren Sie den zu löschenden
Lieferanten, so dass dieser blau hinterlegt ist und klicken Sie auf die Schaltfläche
Löschen“. Der Löschvorgang ist nur dann zulässig, wenn für diesen Lieferanten
”
keine aktuellen Lieferangebote oder Lieferverträge vorhanden sind. Möchten Sie
den Löschvorgang abbrechen, klicken Sie die Schaltfläche Abbrechen“.
”
9.14.4
Lieferangebot/–vertrag anlegen
Sie können für einen bestehenden Lieferanten ein neues Lieferangebot oder einen
Liefervertrag anlegen. Wählen Sie hierzu zunächst den Lieferanten aus der Liste
aus, dem Sie ein Angebot oder einen Vertrag zuordnen möchten. Klicken Sie
anschließend auf die Schaltfläche Anlegen...“ in der Angebots- und Vertrags”
verwaltung. Es öffnet sich eine Eingabemaske (siehe Abbildung 123), in der Sie
alle Felder korrekt ausfüllen müssen. Der Status gibt an, ob es sich bei Ihrer
Eingabe um ein Angebot eines Lieferanten handelt oder um einen bereits abgeschlossenen Vertrag. Sie können den Status eines Angebots jederzeit ändern.
Wählen Sie die Regelzone und den entsprechenden Bilanzkreis aus, indem Sie auf
200
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
das jeweilige Lupensymbol klicken (siehe Abbildung 124). Wenn Ihre Eingaben
korrekt sind, können Sie den Datensatz abspeichern. Wollen Sie den Datensatz
nicht speichern, klicken Sie die Schaltfläche Abbrechen“ oder das Kreuz in der
”
rechten oberen Ecke der Eingabemaske.
Abbildung 123: Ein Lieferangebot/-vertrag anlegen
Abbildung 124: Eine Regelzone auswählen
9.14.5
Lieferangebot/-vertrag bearbeiten
Sie können bestehende Lieferangebote oder Lieferverträge bearbeiten. Hierzu
wählen Sie zunächst den Lieferanten aus, dessen Angebot oder Vertrag Sie bearbeiten möchten. Klicken Sie anschließend auf die Schaltfläche Bearbeiten...“
”
der Angebots- und Vertragsverwaltung. Ändern Sie die Daten, die Sie ändern
wollen, und betätigen Sie anschließend die Schaltfläche Speichern“, wenn Sie
”
diese Daten abspeichern möchten, oder klicken Sie auf Abbrechen“, wenn Sie
”
den alten Datensatz unverändert lassen möchten.
9.14.6
Lieferangebot/-vertrag löschen
Wenn Sie ein Angebot löschen wollen, das zu einem bestimmten Lieferanten
gehört, können Sie dies ohne Einschränkung tun, indem Sie den zu löschenden
201
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Datensatz auswählen und die Schaltfläche Löschen“ aus der Angebots- und
”
Vertragsverwaltung klicken. Der Datensatz wird aus der Liste entfernt. Wollen
Sie einen Vertrag löschen, ist dies nicht ohne weiteres möglich. Sie können einen
Vertrag nur dann löschen, wenn er ausgelaufen und ist und sich keine Kaufempfehlung mehr auf ihn bezieht. Alternativ können Sie den Vertrag auf den
Angebotsstatus zurücksetzen und ihn anschließend löschen.
202
EIS - Energie-Informationssystem
9.15
Projektgruppe Energie-Informationssyteme
Lastprognosen
Abbildung 125: Die Oberfläche zur Verwaltung und Erstellung von Lastprognosen
Sie können mit diesem Programm sehr einfach Lastprognosen erstellen. Wählen Sie zunächst einen Prognosealgorithmus aus der Liste aus, die mit Verfügba”
re Lastprognosealgorithmen“ betitelt ist (siehe Abbildung 125). Informationen
zum gewählten Algorithmus werden Ihnen unten angezeigt. Haben Sie sich für
einen Algorithmus entschieden, tragen Sie noch das Start- und das Enddatum
des Zeitraumes ein, der in die Lastprognose mit einfließen soll. Klicken Sie zum
Erstellen der Lastprognose auf die Schaltfläche Lastprognose erstellen“. Für
”
manche Algorithmen werden weitere Eingaben erforderlich sein. In diesen Fällen
öffnet sich nach klicken der Schaltfläche Prognose erstellen“ eine Eingabemaske.
”
Haben Sie diese Ausgefüllt und bestätigt, wird eine Lastprognose erstellt und
in der rechten Liste mit dem Titel Bereits erstellte Lastprognosen“ angezeigt.
”
Um die Details einer bestimmten Lastprognose einzusehen, klicken Sie auf die
Schaltfläche Details“. Es öffnet sich daraufhin ein weiteres Fenster, welches die
”
Details zu der von Ihnen gewählten Lastprognose enthält, aufgeschlüsselt nach
96 Tages-Viertelstunden und den Tagen, für die eine Lastprognose erstellt wurde. Wenn Sie eine Lastprognose löschen möchten, klicken Sie auf die Schaltfläche
203
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Löschen“ und bestätigen Sie die Sicherheitsabfrage. Sie können eine Lastpro”
gnose nur löschen, wenn keine Kaufempfehlung mehr auf ihr basiert.
204
EIS - Energie-Informationssystem
9.16
Projektgruppe Energie-Informationssyteme
Bilanzkreise und Regelzonen
Abbildung 126: Oberfläche zur Verwaltung von Bilanzkreisen und Regelzonen
9.16.1
Massenupdate
Um eine aktuelle Liste mit Bilanzkreisen und Regelzonen per Massenupdate
in die Datenbank zu übertragen, wählen Sie den Menüpunkt ”Bilanzkreise und
Regelzonen” und klicken dann die Schaltfläche ”Massenupdate”, wählen Sie jetzt
eine CSV–Datei mit Bilanzkreisen und Regelzonen und klicken Sie dann ”OK”.
Die Liste wird dann in die Datenbank übertragen.
Eine Liste der aktuell gültigen Bilanzkreise und Regelzone erhalten Sie beispielsweise auf [EIC06] als Datei für Microsoft Excel. Laden Sie diese herunter
und öffnen Sie sie. Löschen Sie alle Zeilen, die keine Bilanzkreise oder Regelzonen enthalten. Löschen Sie ebenfalls leere Spalten und die Spalte ”Änderungsdatum”. Sortieren Sie anschließend die Spalten in der Reihenfolge Eigentümer,
Abkürzung, EIC. Klicken Sie dann auf Datei, Speichern unter. Wählen Sie als
Dateityp ”CSV (Trennzeichen-getrennt) (*.csv)” und einen beliebigen Dateinamen. Bestätigen Sie die folgende Abfrage mit ja.
205
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Wie alle anderen Daten können auch die Angaben zu Bilanzkreisen und Regelzonen manuell geändert werden, indem sie Schaltflächen ”Anlegen ...”, ”Bearbeiten ...” und ”Löschen ...” am unteren Rand des Übersichtspanels (siehe
Abbildung 126) betätigen. Für die letzten beiden Funktionen muss ein Bilanzkreis oder eine Regelzone ausgewählt sein. Über das Auswahlfeld oben links
wechseln Sie zwischen der Übersicht für Bilanzkreisen und der für Regelzonen
hin und her.
206
EIS - Energie-Informationssystem
9.17
Projektgruppe Energie-Informationssyteme
EEX - Angebote
Um die EIS–Funktionen für die EEX nutzen zu können, müssen Sie als
EEX-Händler eingeloggt sein, bzw. es muss mindestens einen ”EEX–Händler”Systemnutzer geben, dessen Daten für den Handel an der EEX genutzt werden.
Sofern dies nicht der Fall ist, werden Sie aufgefordert, Ihre EEX-Zugangsdaten
einzugeben.
Um in die EEX–Übersicht zu gelangen, wählen Sie den Menüpunkt ”EEXAngebote” im Programmmenü. Sie können in der Übersicht eine aktuelle Lastprognose auswählen. Die Daten der Lastprognose werden nun intern mit den
bereits vereinbarten Lieferungen an Sie abzüglich der Störungen abgeglichen.
In dem Deckungsgraphen der übersicht können Sie erkennen, ob und wann Sie
für die errechnete Last zu einem bestimmten Zeitpunkt genug Energie durch
Verträge und Lieferungen zur Verfügung stehen haben (siehe Abbildung 127).
Abbildung 127: Die Oberfläche zur Verwaltung von EEX-Angeboten
Unter dem Punkt ”Ihre Blockangebote” sehen Sie eine Übersicht über alle zur
Zeit aktuellen Blockangebote, die Sie an der EEX platziert haben. Entsprechend
darunter die Stundenangebote im Bereich ”Ihre Stundenangebote”.
207
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Im untersten Abschnitt können Sie ablesen welche EEX–Händlerdaten (TraderID und TraderLogin) zur Zeit für den EEX–Handel genutzt werden. Das
aktive EEX–Händler–Konto können Sie mit einem Klick auf ”Daten ändern...”
wechseln.
Abbildung 128: EEX-Daten ändern
Geben Sie dazu die entsprechenden EEX-Daten ein, und bestätigen Sie (siehe
Abbildung 128).
In der Info–Spalte links sehen Sie die aktuellen Marktdaten der EEX, also
die Preise für bestimmte Blöcke.
9.17.1
Blockgebote
Blockgebot anlegen Im Bereich ”Ihre Blockgebote” finden Sie eine Übersicht über die aktuellen Blockgebote die Sie an der EEX platziert haben. Um ein
neues Blockgebot für die EEX anzulegen, klicken Sie auf die Schaltfläche ”Anlegen...”. Geben Sie in dem neuen Fenster (siehe Abbildung 129) die gewünschten
Daten für Ihr neues Blockgebot ein. Speichern Sie das neue Blockgebot mit einem Klicke auf ”Speichern”. Sie können das Blockgebot nun mit einem Klick
auf ”PDF erzeugen” als druckbares Faxformular erzeugen lassen bzw. drucken
bzw. direkt an den Faxdrucker übergeben. Für Informationen zu den Druckeinstellungen wenden Sie sich an den jeweiligen Systemadministrator, der für
Sie zuständig ist. Analog dazu können Sie bereits abgegebene Blockangebote
bearbeiten.
208
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 129: Ein Blockangebot erstellen
Blockgebot löschen Um ein Blockgebot zu löschen, wählen Sie das entsprechende Gebot aus der Liste aus und klicken Sie auf ”Löschen”. Bestätigen Sie
die Sicherheitsfrage mit ”OK” um das Gebot endgültig zu löschen. Es können
nur bisher unbestätigte Gebote gelöscht werden.
9.17.2
Stundengebote
Stundengebot anlegen Im Bereich ”Ihre Stundengebote” finden Sie eine
Übersicht über die aktuellen Stundengebote, die Sie an der EEX platziert haben.
Um ein neues Stundengebot für die EEX anzulegen, klicken Sie auf die Schaltfläche ”Anlegen...”. Geben Sie in dem neuen Fenster (siehe Abbildung 130) die
gewünschten Daten für Ihr neues Stundengebot ein. Speichern Sie das neue Stundengebot mit einem Klick auf ”Speichern”. Sie können das Stundengebot nun
mit einem Klick auf ”PDF erzeugen” als druckbares Faxformular erzeugen lassen bzw. drucken bzw. direkt an den Faxdrucker übergeben. Für Informationen
zu den Druckeinstellungen wenden Sie sich an den jeweiligen Systemadministrator, der für Sie zuständig ist. Analog dazu können Sie bereits abgegebene
Stundenangebote bearbeiten.
Stundengebot löschen Um ein Stundengebot zu löschen, wählen Sie das
entsprechende Gebot aus der Liste aus und klicken Sie auf ”Löschen”. Bestätigen
Sie die Sicherheitsfrage mit ”OK” um das Gebot endgültig zu löschen. Es können
nur bisher unbestätigte Gebote gelöscht werden.
9.17.3
EEX-Lieferungen eintragen
Wenn Sie ein Stunden- oder Blockangebot eingegeben haben, können Sie dazu eine an der EEX ausgehandelte Lieferung eintragen. Wählen Sie dazu das
209
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Abbildung 130: Ein Stundenangebot erstellen
jeweilige Angebot aus und klicken Sie auf den zugehörigen Button mit der Aufschrift ”Lieferung ...”. Sie werden dann in einem neuen Fenster nach den Daten
der Lieferung gefragt und können diese mit einem Klick auf die Schaltfläche
”Speichern” sichern.
210
EIS - Energie-Informationssystem
9.18
9.18.1
Projektgruppe Energie-Informationssyteme
EEX - Lieferungen
Übersicht
Um eine Übersicht über aus EEX-Angeboten resultierende Lieferungen zu erhalten, wählen Sie im Menü den Punkt ”EEX–Lieferungen”. Sie erhalten eine Liste
mit allen Lieferungen, die Sie abgeschlossen haben (siehe Abbildung 131). In
der Infospalte links sehen Sie eine Übersicht der gelieferten bzw. gekauften und
verkauften Energiemengen in MWh sowie die Anzahl der aktuellen Lieferungen.
Abbildung 131: Die Oberfläche zur Verwaltung von EEX-Lieferungen
9.18.2
Lieferung bearbeiten
Zur Korrektur einer EEX–Lieferung wählen Sie eine Lieferung aus der Liste
mit einem Mausklick aus (blau hinterlegt) und klicken Sie dann die Schaltfläche
”Bearbeiten...”. ändern Sie die gewünschten Parameter und speichern Sie die
Änderungen mit einem Klick auf ”Speichern”. Zum Abbrechen klicken Sie die
Schaltfläche ”Abbrechen”.
211
EIS - Energie-Informationssystem
9.18.3
Projektgruppe Energie-Informationssyteme
Lieferung löschen
Um eine Lieferung zu löschen, wählen Sie mit einem Mausklick die entsprechende Lieferung in der Übersicht aus und klicken Sie dann die Schaltfläche
”Löschen”. Sie müssen zum endgültigen Löschen der Lieferung die Sicherheitsabfrage mit ”Ja” bestätigen. Andernfalls brechen Sie die Löschung mit einem
Klick auf ”´Nein” ab.
212
EIS - Energie-Informationssystem
9.19
Projektgruppe Energie-Informationssyteme
Störungen
Unter dem Punkt ”Störung” können Sie aktuelle und vergangene Störungen
im Stromübertragungsnetz einsehen, die an Sie übermittelt wurden (siehe Abbildung 132). Geben Sie in der Suchmaske einene Suchbegriff ein und klicken Sie
”Suchen”, um eine bestimmte Störung zu suchen. Um alle vorliegenden Störungen anzuzeigen, klicken Sie auf ”Alle anzeigen”. Es werden nun alle Störungen
mit den entsprechenden Daten in der Liste angezeigt.
Abbildung 132: Die Oberfläche zur Verwaltung und Erstellung von Störungen
9.19.1
Störung melden
Sie können eine neue Störung melden, indem Sie die Schalfläche ”Anlegen” klicken. Geben Sie in der neuen Maske (siehe Abbildung 9.19.1) die entsprechenden
Daten für die Störung ein. Bestätigen Sie die Störung mit einem Klick auf ”OK”.
9.19.2
Störung bearbeiten
Eine bereits bestehende Störung können Sie nachdem Sie sie ausgewählt haben,
mit einem Klick auf ”Bearbeiten...” ändern.
213
EIS - Energie-Informationssystem
9.19.3
Projektgruppe Energie-Informationssyteme
Störung löschen
Mit einem Klick auf ”Löschen” können Sie eine ausgwählte Störung löschen.
Bestätigen Sie die Sicherheitsabfrage mit ”Ja”, um die Störung endgültig zu
löschen.
214
EIS - Energie-Informationssystem
9.20
Projektgruppe Energie-Informationssyteme
Systemnutzer
Abbildung 133: Die Oberfläche zur Verwaltung von Systemnutzern
9.20.1
Rollen
Jeder Systemnutzer kann keine, eine oder mehrere Rollen haben. Diese lauten
wie folgt:
Administrator Der Administrator hat uneingeschränkte Rechte zum Zugriff
auf die Nutzerverwaltung des EIS. Es kann mehrere Administratoren geben.
Mindestens ein Adminstrator muss im System vorhanden sein.
EEX–Händler Die Daten die einem EEX–Händler Account zugeordnet sind,
können zum Handel an der EEX eingesetzt werden (siehe EEX–Angebote).
EEX–Händler hat Zugriff auf die Funktionen:
• EEX–Angebote
215
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
• EEX–Lieferungen
Um auf die Funktionen EEX–Angebote und EEX–Lieferungen zugreifen zu können, müssen Sie als EEX–Händler eingeloggt sein bzw. als Admin wenn ein
EEX–Händler Konto angelegt wurde.
Kundenbetreuer Ein Kundenbetreuer verwaltet Stammdaten für eigene Kunden. Kundenbetreuer haben Zugriff auf die Funktionen:
• Kundenverwaltung inkl. Kundenverträge
• Tarife
• Lastprofile
• Bilanzkreise und Regelzonen
Lieferentenbetreuer Ein Lieferantenbetreuer verwaltet Stammdaten für Energielieferanten. Lieferantenbetreuer haben Zugriff auf die Funktionen:
• Lieferantenverwaltung inkl. Lieferverträge.
• Lastprognosen
• Kaufempfehlungen
• Bilanzkreise und Regelzonen
• Störungen
Abbildung 134: Einen Systemnutzer hinzufügen
216
EIS - Energie-Informationssystem
9.20.2
Projektgruppe Energie-Informationssyteme
Benutzer anlegen/bearbeiten
Wählen Sie aus dem Menü den Punkt ”Systemnutzer” (siehe Abbildung 133).
Zum Anlegen neuer Systemnutzer klicken Sie auf die Schaltfläche ”Anlegen”
(siehe Abbildung 134). Geben Sie die entsprechenden Daten an, wählen Sie
keine, eine oder mehrere Rollen für den neuen Systemnutzer aus und klicken
Sie dann auf die Schaltfläche ”Speichern”, um die Änderungen zu speichern. Der
neue Systemnutzer erscheint jetzt in der Liste der Systemnutzer. Analog können
Sie einen bestehenden Systemnutzer auch bearbeiten und ihm beispielsweise
Rollen aberkennen. Dazu klicken
9.20.3
Benutzer löschen
Über einen Klick auf die Schaltfläche ”Löschen” können Sie beliebige Systemnutzer – auch sich selbst – löschen. Voraussetzung dafür ist, dass der zu löschende
Nutzer keine Verträge und keinen EEX-Handel mehr betreut. Eine Löschung
ist ebenfalls nicht möglich, wenn es sich um den letzten im System verbliebenen Adminstrator handelt, da sonst ein Zugriff auf die Benutzerverwaltung
unmöglich würde. Bevor ein Nutzer tatsächlich gelöscht wird, müssen Sie eine
Sicherheitsabfrage bestätigen.
217
EIS - Energie-Informationssystem
9.21
9.21.1
Projektgruppe Energie-Informationssyteme
Szenarien
Szenario 1: Herausgabe einer aktualisierten Bilanzkreisliste
Der EIS-Nutzer Klaus Mustermann startet zu Beginn seines Arbeitstages das
System und gelangt nach erfolgreicher Anmeldung auf die Übersichtsseite. Er
kontrolliert die eingegangenen Störungen und die heute auslaufenden Verträge
mit Kunden und Lieferanten. Schließlich schaut er auf seine ToDo-Liste und
stellt fest, dass an diesem Tag eine aktualisierte Liste mit Bilanzkreisen herausgegeben wurde (siehe Abbildung 9.21.1).
Abbildung 135: Die ToDo-Liste zeigt, dass heute eine Aufgabe anliegt
218
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Er öffnet seinen Internetbrowser und lädt sich die aktuelle Liste herunter.
Anschließend kann er diese Datei verwenden, um die Liste des Systems zu aktualisieren. Hierzu wechselt er in die Verwaltung der Bilanzkreise und Regelzonen,
indem er im Menü Bilanzkreise und Regelzonen“ anklickt. Er klickt nun auf
”
Durchsuchen“ und gibt den Dateipfad zu der soeben heruntergeladenen CSV”
Datei an (siehe Abbildung 9.21.1). Abschließend klickt er auf die Schaltfläche
Datei verarbeiten“. Die Liste ist nun aktualisiert und der EIS-Nutzer kehrt
”
wieder in die Übersicht zurück, zu der er durch ein Klick auf Willkommen“ im
”
Menü gelangt.
Abbildung 136: Auswahl der CSV-Datei zur Listenaktualisierung
219
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Hier muss er nun die abgeschlossene Aufgabe als bearbeitet markieren. Er
wählt aus der ToDo-Liste den entsprechenden Eintrag aus und klickt auf Be”
arbeiten...“. Er setzt den Status von Nicht angefangen“ auf Bearbeitet“ und
”
”
klickt dann auf Speichern“ (siehe Abbildung 137). Der Vorgang ist hiermit
”
abgeschlossen. Alternativ könnte der Nutzer den Eintrag natürlich auch sofort
löschen.
Abbildung 137: Bearbeitung des Ereignisses in der ToDo-Liste
220
EIS - Energie-Informationssystem
9.21.2
Projektgruppe Energie-Informationssyteme
Szenario 2: Abschluss eines neuen Vertrages
Ein EIS-Nutzer möchte einen Vertrag mit einem Lieferanten schließen, um den
Strombedarf seiner Kunden decken zu können. Er hat mehrere Angebote von
Lieferanten im System gespeichert. Er überprüft einige gleichwertige Angebote
(siehe Abbildung 138) und fragt sich nun, mit welchem dieser Lieferanten er
einen Vertrag abschließen soll. Er entscheidet sich dazu, dem Lieferanten den
Vorzug zu geben, der das geringste Störungsaufkommen hat. Dazu wechselt der
Nutzer in die Störungsansicht des EIS-Systems.
Abbildung 138: In der Lieferantenansicht prüft der Nutzer die Angebote
221
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Hier gibt der Nutzer nacheinander die Namen der Lieferanten ein, die er im
Auge hat. Er erhält eine Übersicht über die Störungen, die im Zusammenhang
mit dem jeweiligen Lieferanten aufgetreten sind (siehe Abbildung 139). Nachdem der Nutzer sich auf Basis der Störungsinformationen für einen Lieferanten
entschieden hat, kann es zum Vertragsschluss mit diesem Lieferanten kommen.
Er kehrt zurück in die Lieferantenansicht.
Abbildung 139: In der Störungsansicht vergleicht der Nutzer die Störrate
222
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
In der Lieferantenansicht wählt der Nutzer das Angebot des Lieferanten,
dass der Nutzer zu einem Vertrag im System ändern möchte. Er klickt auf Be”
arbeiten...“ und ändert den Status von Angebot“ auf Vertrag“ (siehe Abbildung
”
”
140). Der Vorgang ist nun abgeschlossen.
Abbildung 140: Verwaltung von Angeboten und Verträgen in Lieferantenansicht
223
EIS - Energie-Informationssystem
9.22
Projektgruppe Energie-Informationssyteme
Hilfefunktion
Zum Aufrufen der Online–Hilfe können Sie jederzeit die Taste F1 drücken. Die
Online–Hilfe wird dann an der für die derzeitig Ausgewählte Funktion relevanten
Seite geöffnet. Um die Windows-Hilfedatei auf der Startseite zu öffnen, wählen
Sie im Programm-Menu den Punkt ”Hilfe”.
224
EIS - Energie-Informationssystem
10
Projektgruppe Energie-Informationssyteme
Glossar
Agile Modeling Agile Modellierung, Sammlung von Werten, Prinzipien und
Methoden zur Softwaremodellierung, die auf einfache Weise in einem Entwicklungsprojekt angewandt werden können.
CRM Customer Relationship Management, Kundenverwaltung, die sich um
Anlegen, Ändern und Löschen kundenbezogener Daten kümmert.
CRUD-Methoden Create, Read, Update, Delete, Standardmethoden zum Zugriff auf Objekte in einer Datenbank zum Einfügen, Auslesen, Bearbeiten
und Löschen.
CSV Comma Seperated Values, Textdatei zur Speicherung oder Austasuch von
einfach strukturierten Daten, einzelne Werte sind durch ein Trennzeichen
(z.B. Komma) voneinander getrennt
CVS Concurrent Versions System, Programm zur Versionsverwaltung von Dateien, hauptsächlich Software-Quelltext
DLL Dynamic Link Library, unter Microsoft Windows eingesetzte Programmbibliothek, die Programmcode und/oder Daten beinhalten kann.
DSS Decision Support System, Entscheidungsunterstützungssystem, das dem
Nutzer eines Systems sinnvolle, möglichst optimale Vorschläge zur Lösung
einer bestimmten, meist betriebswirtschaftlichen Fragestellung anbietet.
EEX European Energy Exchange, elektronischer Marktplatz für den Energiehandel mit Sitz in Leipzig.
ETSO European Transmission System Operators, Verband der europäischen
Übertragungsnetzbetreiber.
ESS ETSO Scheduling System, standardisiertes, XML-basiertes Dateiformat
zum Austausch von Fahrplanmeldungen zwischen Eneriehändlern und
ÜNBs im europäischen Energieverbund.
Extreme Programming Flexible Vorgehensweise zur Softwaremodellierung,
die in kurzen Zyklen alle Entwicklungsschritte durchläuft und dabei den
Programmcode sowie die sich im Zeitablauf ändernden Kundenwünsche
bei ständiger Reflexion in den Mittelpunkt stellt.
GUI Graphical User Interface, grafische Benutzeroberfläche, über die Menschen mit einem Programm interagieren können.
NUnit Framework zu Entwurf und Durchführung von Unit-Tests für alle .NETProgrammiersprachen.
Review Kontrolle des Ergebnis eines bearbeiteten Sprints durch eines oder
mehrere Mitglieder der Projektgruppe auf Erfüllung der im Springt gestellten Anforderungen
RPC Remote Procedure Call ist ein Netzwerkprotokoll, mit dem über das Netzwerk Funktionsaufrufe auf entfernten Rechnern durchgeführt werden.
225
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Scrum ist eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Methoden für das Projektmanagement im Rahmen agiler Software-Entwicklung.
SOAP Simple Object Access Protocol ist ein Protokoll, mit dem Daten zwischen
Systemen ausgetauscht werden und mit dem RPC durchgeführt wird.
SVN Subversion, Programm zur Versionsverwaltung von Dateien, hauptsächlich Software-Quelltext.
UML Unified Modeling Language, standardisierte Sprache zur Modellierung
von Software und anderen Systemen.
ÜNB Übertragungsnetzbetreiber, Unternehmen, das für Organisation und Wartung des Stromleitungsnetzes in einer bestimmten Region zuständig ist.
V-Modell Das V-Modell ist ein spezielles Vorgehensmodell zur Softwareentwicklung. Das V-Modell ist einer von vielen Versuchen, in Deutschland
eine Richtlinie für die Entwicklung von IT-Systemen der öffentlichen Hand
einzuführen. In der Regel wird ein neues V-Modell nach einer Katastrophe
mit dem jeweils vorhergehenden V-Modell entwickelt. Das Bestreben ist,
ein auf die öffentliche Hand zugeschnittenes Prozessmodell als Richtlinie
einzuführen.
Wasserfallmodell Das Wasserfallmodell bezeichnet ein Vorgehensmodell in
der Softwareentwicklung, bei dem der Softwareentwicklungsprozesses in
Phasen organisiert wird. Dabei gehen die Phasenergebnisse wie bei einem
Wasserfall immer als bindende Vorgaben für die nächst tiefere Phase ein.
Wrapper-Klasse Klasse, die den Datenbankzugriff für einen bestimmten Objekttyp kapselt und dazu Methoden zum Einfügen, Bearbeiten, Löschen
und Auslesen von Objekten bereitstellt.
226
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
Literatur
[Adv]
Adventureworks cinema 1.0.
Online und herunterladbar unter
http://www.microsoft.com/germany/msdn/library/vs2005/samples/default.mspx?mfr=true.
[All]
Agile alliance. Online unter http://www.agilealliance.com/.
[BBa01] Kent Beck, Mike Beedle, and und andere. Manifesto for agile software
development. Online unter http://agilemanifesto.org/principles.html,
letzter Zugriff am 04.04.2006, 2001.
[Bun05] Bundesgesetzblatt.
Verordnung
über
den
zugang
zu
elektrizitätsversorgungsnetzen.
Online
unter
http://217.160.60.235/BGBL/bgbl1f/bgbl105s2243.pdf, letzter Zugriff
am 15.9.2005, 2005.
[dE01] Verband der Elektrizitätswirtschaft.
Begriffe im liberalisierten strommarkt.
Online unter http://www.vdnberlin.de/global/downloads/Service/BegriffeStrommarkt.PDF, letzter
Zugriff am 14.9.2005, 2001.
[EIC06] Eic-codes für vnb-bilanzkreise gemäß nvz. Online und herunterladbar
unter http://www.vdn-berlin.de/vnb eic.asp, 2006.
[FI]
Fraunhofer-Institut.
Projekt
fit
für
usability.
Online
unter
http://www.fit-fuerusability.de/tipps/software/information/uebersicht.html,
zuletzt
besucht am 19. September 2006.
[Fir]
Firefx
beta
2.
Online
http://www.dotnetfireball.net.
und
herunterladbar
unter
[For03] European Transmission System Operators Task Force. ETSO Scheduling System - Implementation Guide, 2 edition, April 2003.
[Fow05] Martin Fowler.
The new methodology.
Online unter
http://www.martinfowler.com/articles/newMethodology.html, letzter
Zugriff am 04.04.2006, 2005.
[Gro04] Agile Cologne Group.
Scrum.
Online unter http://agilecologne.de:8080/snipsnap-0.5.2a/space/Scrum, letzter Zugriff am
15.12.2005, 2004.
[kos]
Kostenkurve. Online unter http://de.wikipedia.org/wiki/Agile Softwareentwicklung,
letzter Zugriff am 04.04.2006.
[Las06] Energiedienst
ag,
lastprofile.
Online
und
herunterladbar
unter
http://www.energiedienstnetze.de/site/DE/netze/01-netznutzung/01 03lastprofile/Lastprofile Energiedienst AG/container lastprofile energiedienst AG.php,
2006.
[Mar02] Robert C. Martin. Agile processes. 2002.
227
EIS - Energie-Informationssystem
Projektgruppe Energie-Informationssyteme
[Nat05] National Oceanic and Atmospheric Administration. Wetterdaten der
noaa. Online unter http://www.nws.noaa.gov, letzter Zugriff am
15.10.2005, 2005.
[Nie]
Jakob Nielsen. 6 ways to fix a confused information architecture.
[Ope03] European Transmission System Operators. Etso scheduling system (ess) implementation guide. Online unter http://www.edi.etsonet.org/schedulev2r3/ess-guide-v2r3.zip, letzter Zugriff am 15.03.2006,
2003.
[Plu03] Plugin architecture using c sharp. 2003.
[Rec94] Ingo Rechenberg. Evolutionsstrategie ’94. Frommann Holzboog, 1994.
[SB06] Florian Sarodnick and Henning Brau. Methoden der Usability Evaluation. Huber, 2006.
[Sch05] Ken Schwaber. Scrum - it´s about common sense. Online unter
http://www.controlchaos.com, letzter Zugriff am 13.12.2005, 2005.
[SOA03] Soap version 1.2, part 1: Messaging framework. Online und herunterladbar unter http://www.w3.org/TR/2003/REC-soap12-part120030624/, 2003.
[Sut05] Jeff
Sutherland.
Scrumlog.
http://jeffsutherland.com/scrum, letzter
2005.
Zugriff
Online
unter
am 13.12.2005,
[Usa97] DIN EN ISO 9421. Ergonomische Anforderungen für Bürotätigkeiten
mit Bildschirmgeräten. Deutsche Fassung EN ISO 9421. Beuth Verlag
Berlin, 1997.
[Usa99] DIN EN ISO 13407. Benutzer-orientierte Gestaltung interaktiver System. Deutsche Fassung EN ISO 13407. Beuth Verlag Berlin, 1999.
[Usa03] DIN EN ISO 14915. Software Ergonomie für MultimediaBenutzungsschnittstellen. Deutsche Fassung EN ISO 14915. Beuth
Verlag Berlin, 2003.
[Zed]
Zed
graph
5.x.
Online
http://zedgraph.org/wiki/index.php.
228
und
herunterladbar
unter