EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines...

228
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¨ uster, Dirk R¨ ader, Thorben Witt 30. September 2006 Projektgruppe Energie-Informationssysteme Carl von Ossietzky Universit¨ at Oldenburg Department f¨ ur Informatik

Transcript of EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines...

Page 1: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS

-

Implementierung eines

Energie-Informationssystems (Endbericht)

Projektgruppe Energie-InformationssytemeDaniel Aarden, Ole Behrens, Malte Diehl, Hannes Dillwitz,

Simon Droste, Tammo Filusch, Florian Frische, Winfried Klinker,

Jens Pluster, Dirk Rader, Thorben Witt

30. September 2006

Projektgruppe Energie-InformationssystemeCarl von Ossietzky Universitat Oldenburg

Department fur Informatik

Page 2: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Inhaltsverzeichnis

1 Einleitung 12

1.1 Einfuhrung in den Energiemarkt . . . . . . . . . . . . . . . . . . 13

1.1.1 Begriffe aus der Energiewirtschaft . . . . . . . . . . . . . 13

1.1.2 Weitere EIS-spezifische Begriffe . . . . . . . . . . . . . . . 14

2 Ubersicht uber 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 Entscheidungsunterstutzung . . . . . . . . . . . . . . . . . 24

3.2.6 Fahrplanmanagement . . . . . . . . . . . . . . . . . . . . 26

3.3 Nicht-funktionale Anforderungen . . . . . . . . . . . . . . . . . . 27

3.3.1 Benutzbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.3.2 Zuverlassigkeit . . . . . . . . . . . . . . . . . . . . . . . . 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

3.4 Hinzugefugte und entfallene Anforderungen . . . . . . . . . . . . 29

4 Umsetzung der Anforderungen 30

4.1 Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1.1 Programmiersprache . . . . . . . . . . . . . . . . . . . . . 30

4.1.2 Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.3 Grafische Oberflache . . . . . . . . . . . . . . . . . . . . . 31

4.1.4 Datenaustausch . . . . . . . . . . . . . . . . . . . . . . . . 34

2

Page 3: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

4.2 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

4.3 Softwarearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.1 Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.4 Ablauf der Implementierung . . . . . . . . . . . . . . . . . . . . . 54

5 Implementierung der einzelnen Funktionen 56

5.0.1 ReturnCode-Ruckgabewerte . . . . . . . . . . . . . . . . . 56

5.1 Stammdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1.1 Systemnutzer . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.1.2 Kunden und -vertrage, Tarife und Lastprofile . . . . . . . 62

5.1.3 Stromlieferanten, Lieferangebote und -vertrage . . . . . . 75

5.1.4 Bilanzkreise und Regelzonen . . . . . . . . . . . . . . . . 81

5.2 EEX-Handel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5.2.1 Zugangsdaten zur Energieborse . . . . . . . . . . . . . . . 89

5.2.2 Abgabe und Bearbeitung von Angeboten . . . . . . . . . 91

5.2.3 Bestatigte Lieferungen . . . . . . . . . . . . . . . . . . . . 100

5.2.4 Aktuelle Marktdaten der Energieborse . . . . . . . . . . . 105

5.2.5 EEX-Parser . . . . . . . . . . . . . . . . . . . . . . . . . . 107

5.2.6 Die Funktionsweise von EEX.exe . . . . . . . . . . . . . . 108

5.3 Entscheidungsunterstutzung . . . . . . . . . . . . . . . . . . . . . 109

5.3.1 Lastprognosen . . . . . . . . . . . . . . . . . . . . . . . . 109

5.3.2 Storungsverwaltung . . . . . . . . . . . . . . . . . . . . . 115

5.3.3 Kaufempfehlungen . . . . . . . . . . . . . . . . . . . . . . 120

5.4 Fahrplane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

Page 4: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

7 Vorgehensmodell 148

7.1 Scrum - Entwicklungsmodell fur 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 . . . . . . . . . . . . . . . . . . . . . . . . . 152

7.1.7 Sprint Review . . . . . . . . . . . . . . . . . . . . . . . . . 152

7.1.8 Sprint Retrospective . . . . . . . . . . . . . . . . . . . . . 152

7.2 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.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

7.5 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

7.6 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

7.7 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

7.8 Funfter Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

7.8.1 Verlauf des 5. Sprints . . . . . . . . . . . . . . . . . . . . 162

7.8.2 Probleme und Ereignisse im funften Sprint . . . . . . . . 162

7.8.3 Review Meeting zum funften Sprint . . . . . . . . . . . . 162

7.9 Abschlussarbeiten und Organisation . . . . . . . . . . . . . . . . 162

4

Page 5: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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 . . . . . . . . . . . . . . . . . . . . . . 166

8.6 Die Arbeit mit Scrum . . . . . . . . . . . . . . . . . . . . . . . . 167

8.7 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

9 Benutzerhandbuch 169

9.1 Willkommen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

9.2 Systemvorausetzungen . . . . . . . . . . . . . . . . . . . . . . . . 169

9.2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

9.2.2 Betriebsystem . . . . . . . . . . . . . . . . . . . . . . . . . 169

9.2.3 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . 169

9.3 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

9.4 Erste Schritte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

9.4.1 Programm starten . . . . . . . . . . . . . . . . . . . . . . 174

9.4.2 Serveradresse angeben . . . . . . . . . . . . . . . . . . . . 174

9.4.3 Einloggen . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

9.4.4 Administratorpasswort andern . . . . . . . . . . . . . . . 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.8.1 Auswahl fur Tarife . . . . . . . . . . . . . . . . . . . . . . 179

9.8.2 Auswahl fur Regelzonen . . . . . . . . . . . . . . . . . . . 179

9.8.3 Auswahl fur Lastprofile . . . . . . . . . . . . . . . . . . . 180

9.8.4 Auswahl fur Bilanzkreise . . . . . . . . . . . . . . . . . . 180

9.9 Kunden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

5

Page 6: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.9.1 Kunden anlegen . . . . . . . . . . . . . . . . . . . . . . . 181

9.9.2 Kunden bearbeiten . . . . . . . . . . . . . . . . . . . . . . 182

9.9.3 Kunden loschen . . . . . . . . . . . . . . . . . . . . . . . . 183

9.9.4 Kundenvertrag anlegen . . . . . . . . . . . . . . . . . . . 183

9.9.5 Kundenvertrag bearbeiten . . . . . . . . . . . . . . . . . . 185

9.9.6 Kundenvertrag loschen . . . . . . . . . . . . . . . . . . . . 185

9.10 Lastprofile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

9.10.1 Lastprofile anlegen . . . . . . . . . . . . . . . . . . . . . . 187

9.10.2 Lastprofile bearbeiten . . . . . . . . . . . . . . . . . . . . 188

9.10.3 Lastprofile loschen . . . . . . . . . . . . . . . . . . . . . . 188

9.11 Tarife . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

9.11.1 Tarife anlegen . . . . . . . . . . . . . . . . . . . . . . . . . 189

9.11.2 Tarife bearbeiten . . . . . . . . . . . . . . . . . . . . . . . 190

9.11.3 Tarife loschen . . . . . . . . . . . . . . . . . . . . . . . . . 190

9.12 Fahrplane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

9.12.1 Fahrplan erstellen . . . . . . . . . . . . . . . . . . . . . . 191

9.12.2 Fahrplan loschen . . . . . . . . . . . . . . . . . . . . . . . 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 loschen . . . . . . . . . . . . . . . . . . . . . . 200

9.14.4 Lieferangebot/–vertrag anlegen . . . . . . . . . . . . . . . 200

9.14.5 Lieferangebot/-vertrag bearbeiten . . . . . . . . . . . . . 201

9.14.6 Lieferangebot/-vertrag loschen . . . . . . . . . . . . . . . 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

Page 7: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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 Ubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

9.18.2 Lieferung bearbeiten . . . . . . . . . . . . . . . . . . . . . 211

9.18.3 Lieferung loschen . . . . . . . . . . . . . . . . . . . . . . . 212

9.19 Storungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

9.19.1 Storung melden . . . . . . . . . . . . . . . . . . . . . . . . 213

9.19.2 Storung bearbeiten . . . . . . . . . . . . . . . . . . . . . . 213

9.19.3 Storung loschen . . . . . . . . . . . . . . . . . . . . . . . . 214

9.20 Systemnutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

9.20.1 Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

9.20.2 Benutzer anlegen/bearbeiten . . . . . . . . . . . . . . . . 217

9.20.3 Benutzer loschen . . . . . . . . . . . . . . . . . . . . . . . 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

Page 8: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildungsverzeichnis

1 Der Implementierung zugrunde liegender Weltausschnitt . . . . . 16

2 Aufbau der Entscheidungsunterstutzung . . . . . . . . . . . . . . 26

3 Ausfuhrliche Fehlermeldung mit Eingabemoglichkeit . . . . . . . 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 Ubersicht uber 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 Ubersicht uber Kunden und ihre Vertrage . . . . . . . . . . . . . 70

21 Klasse EnergyProfileDAL . . . . . . . . . . . . . . . . . . . . . . 73

22 Klasse EnergyProfileManager . . . . . . . . . . . . . . . . . . . . 74

23 Hauptfenster der Lastprofilverwaltung . . . . . . . . . . . . . . . 75

24 Eingabefenster fur Lastprofile . . . . . . . . . . . . . . . . . . . . 76

25 Lieferant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

26 Lieferangebot und -vertrag . . . . . . . . . . . . . . . . . . . . . . 78

27 Lieferanten im Datenzugriff . . . . . . . . . . . . . . . . . . . . . 79

28 Lieferanten in der Geschaftslogik . . . . . . . . . . . . . . . . . . 80

29 Bilanzkreis- und Regelzonenobjekt . . . . . . . . . . . . . . . . . 82

30 Datenzugriff auf Bilanzkreise und Regelzonen . . . . . . . . . . . 83

31 Bilanzkreise und Regelzonen in der Geschaftslogik . . . . . . . . 85

32 Ubersicht der vorhandenen Bilanzkreise . . . . . . . . . . . . . . 87

33 Bearbeiten-Fenster fur einen Bilanzkreis . . . . . . . . . . . . . . 87

34 Panel fur EEX-Handel . . . . . . . . . . . . . . . . . . . . . . . . 89

8

Page 9: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

35 Klasse EexAccount . . . . . . . . . . . . . . . . . . . . . . . . . . 90

36 Klasse EexAccountDAL . . . . . . . . . . . . . . . . . . . . . . . 90

37 Eingabefenster fur EEX-Zugangsdaten . . . . . . . . . . . . . . . 91

38 Klassen EexHourBid und EexHourBidDetails . . . . . . . . . . . 92

39 Klassen EexBlockBid und EexBlockBidDetails . . . . . . . . . . 93

40 Erstellung des Reports fur Stundenangebote in Visual Studio 2005 94

41 Vorschau auf den PDF-Export eines Stundenangebots . . . . . . 95

42 Klassen fur den Datenbankzugriff auf EEX-Angebote . . . . . . . 95

43 Eingabefenster fur Stundenangebote . . . . . . . . . . . . . . . . 98

44 Eingabefenster zur Preissetzung fur Stundenangebote . . . . . . 99

45 Eingabefenster fur Blockangebote . . . . . . . . . . . . . . . . . . 100

46 Klasse EexManager . . . . . . . . . . . . . . . . . . . . . . . . . . 101

47 Klasse EexDelivery . . . . . . . . . . . . . . . . . . . . . . . . . . 102

48 Klasse EexDeliveryDAL . . . . . . . . . . . . . . . . . . . . . . . 102

49 EEX-Lieferungsubersicht mit Bearbeitungsmoglichkeiten . . . . . 104

50 Eingabefenster fur EEX-Lieferungen . . . . . . . . . . . . . . . . 105

51 Klasse EexMarketData . . . . . . . . . . . . . . . . . . . . . . . . 105

52 Klasse EexMarketDataDAL . . . . . . . . . . . . . . . . . . . . . 106

53 Fenster fur aktuelle Marktdaten . . . . . . . . . . . . . . . . . . . 108

54 Die GUI fur 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 . . . . . . 114

61 Klasse Disturbance . . . . . . . . . . . . . . . . . . . . . . . . . . 115

62 Klasse DisturbanceDAL . . . . . . . . . . . . . . . . . . . . . . . 116

63 Klasse DisturbanceManager . . . . . . . . . . . . . . . . . . . . . 117

64 Storungsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . 118

65 Neue Storung eingeben . . . . . . . . . . . . . . . . . . . . . . . . 119

66 Liefervertrag auswahlen . . . . . . . . . . . . . . . . . . . . . . . 119

67 Klasse Recommendation . . . . . . . . . . . . . . . . . . . . . . . 120

68 Klasse RecommendationDAL . . . . . . . . . . . . . . . . . . . . 121

69 Klasse RecommendationManager . . . . . . . . . . . . . . . . . . 122

70 Auswahl der zu verwendenden Lastprognose . . . . . . . . . . . . 124

9

Page 10: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

71 Zu berucksichtigenden Liefervertrage 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 Oberflache fur Fahrplane . . . . . . . . . . . . . . . . . 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 auswahlen . . 172

87 Vergabe der Benutzerrechte . . . . . . . . . . . . . . . . . . . . . 173

88 Auswahlfenster zum Aktualisieren der EEX Marktdaten . . . . . 174

89 Die Startoberflache 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 fur Tarife . . . . . . . . . . . . . . . . . . . . 179

94 Das Auswahlfenster fur Regelzonen . . . . . . . . . . . . . . . . . 179

95 Das Auswahlfenster fur Lastprofile . . . . . . . . . . . . . . . . . 180

96 Das Auswahlfenster fur Bilanzkreise . . . . . . . . . . . . . . . . 180

97 Die Oberflache zur Verwaltung von Kunden und deren Vertrage . 181

98 Einen neuen Kunden anlegen . . . . . . . . . . . . . . . . . . . . 182

99 Einen bestehenden Kunden bearbeiten . . . . . . . . . . . . . . . 182

100 Einen bestehenden Kunden loschen . . . . . . . . . . . . . . . . . 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

Page 11: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

107 Die Oberflache zur Verwaltung von Lastprofilen . . . . . . . . . . 187

108 Ein neues Lastprofil anlegen . . . . . . . . . . . . . . . . . . . . . 188

109 Ein Lastprofil bearbeiten . . . . . . . . . . . . . . . . . . . . . . 188

110 Die Oberflache zur Verwaltung von Tarifen . . . . . . . . . . . . 189

111 Einen neuen Tarif anlegen . . . . . . . . . . . . . . . . . . . . . . 190

112 Einen Tarif bearbeiten . . . . . . . . . . . . . . . . . . . . . . . . 190

113 Die Oberflache zur Erstellung von Fahrplanen . . . . . . . . . . . 191

114 Einen Fahrplan im Browserfenster anzeigen . . . . . . . . . . . . 192

115 Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 1 . 193

116 Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 2 . 194

117 Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 3 . 195

118 Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 4 . 196

119 Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 5 . 197

120 Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 6 . 198

121 Die Oberflache zur Verwaltung von Lieferanten . . . . . . . . . . 199

122 Ein bestehenden Lieferanten bearbeiten . . . . . . . . . . . . . . 200

123 Ein Lieferangebot/-vertrag anlegen . . . . . . . . . . . . . . . . . 201

124 Eine Regelzone auswahlen . . . . . . . . . . . . . . . . . . . . . . 201

125 Die Oberflache zur Verwaltung und Erstellung von Lastprognosen 203

126 Oberflache zur Verwaltung von Bilanzkreisen und Regelzonen . . 205

127 Die Oberflache zur Verwaltung von EEX-Angeboten . . . . . . . 207

128 EEX-Daten andern . . . . . . . . . . . . . . . . . . . . . . . . . . 208

129 Ein Blockangebot erstellen . . . . . . . . . . . . . . . . . . . . . . 209

130 Ein Stundenangebot erstellen . . . . . . . . . . . . . . . . . . . . 210

131 Die Oberflache zur Verwaltung von EEX-Lieferungen . . . . . . . 211

132 Die Oberflache zur Verwaltung und Erstellung von Storungen . . 213

133 Die Oberflache zur Verwaltung von Systemnutzern . . . . . . . . 215

134 Einen Systemnutzer hinzufugen . . . . . . . . . . . . . . . . . . . 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 pruft der Nutzer die Angebote . . . . . 221

139 In der Storungsansicht vergleicht der Nutzer die Storrate . . . . . 222

140 Verwaltung von Angeboten und Vertragen in Lieferantenansicht . 223

11

Page 12: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

1 Einleitung

Dies ist der Endbericht der Projektgruppe Energieinformationssysteme, die inder Abteilung Informationssysteme des Departments fur Informatik der Univer-sitat Oldenburg vom 1. Oktober 2005 bis zum 30. September 2006 veranstaltetwurde. Neben dem offiziellen Namen wurden den Teilnehmern kaum Vorgabenhinsichtlich ihrer Arbeit gemacht, außer dass sie sich mit dem Geschehen undden Ablaufen in der Energiebranche beschaftigen sollte.

Nachdem in der Seminarphase zunachst zahlreiche Vortrage rund um dieThemen Energieversorgung, liberalisierte Energiemarkte und Produktionspla-nungssysteme gehalten worden waren, begann folglich eine Diskussion uber dieweitere Vorgehensweise. Nur kurze Zeit spater war vor dem Hintergrund der vor-anschreitenden Liberalisierung der Strommarkte die Entscheidung gefallen, einInformationssystem zu implementieren, das Energiehandlern bei ihrer taglichenArbeit rund um Stromein- und -verkauf hilft und auch umfangreiche Entschei-dungsunterstutzung in wichtigen Fragen bietet.

Der vorliegende Bericht ist nun das Ergebnis der zwolf Monate Planung undEntwicklung der Projektgruppe Energieinformationssysteme. In den folgendenKapiteln stellt er die wesentlichen Resultate der Gruppenarbeit heraus und bie-tet dem Leser daruber hinaus eine verstandliche Darstellung der Entscheidungs-prozesse und Vorgehensweisen innerhalb der Gruppe. Viele Entscheidungen undErgebnisse im Vorfeld der Implementierung wurden schon im ersten Semesterdieses Projektes erarbeitet. Diese sind im Zwischenbericht enthalten. Auf ihnwird im Verlauf dieses Endberichtes des ofteren verwiesen. Im Zwischenbericht,der Anfang April 2006 abgegeben wurde, sind

• die Ausarbeitung der einzelnen Projektgruppenmitglieder fur die anfang-liche Seminarphase,

• die ursprungliche Anforderungsdefinition und

• der detaillierte Entwurf der Implementierung enthalten.

Kapitel zwei dieses Berichts bietet einen kurzen Uberblick uber den betrach-teten Weltausschnitt und das daraus entstandene Programm. In Kapitel dreiwerden die Anforderungen, die als Grundlage der Implementierung an das Pro-gramm gestellt wurden, zusammengefasst. Das darauffolgende Kapitel erlautertden Ablauf der Implementierung und, welche Technologien, Konzepte und Soft-warearchitektur zur Erfullung der zuvor gestellten Anforderungen eingesetztwurden. Die einzelnen Funktionen des Programms werden dann in Kapitel funfausfuhrlich vorgestellt, wobei der Schwerpunkt auf der Art und Weise der Imple-mentierung in den verschiedenne Schichten der Archtektur liegt. Kapitel sechsbeschaftigt sich anschließend mit den verschiedenen Testarten, die eingesetztwurden, um einen reibungslosen Programmablauf sicherzustellen. Im siebtenKapitel wird das Vorgehensmodell, das wahrend der Implementierung verfolgtwurde, dargestellt, bevor im achten ein detailliertes Fazit der Arbeit samt Aus-blick auf zukunftige Entwicklungsmoglichkeiten des Programms geboten wird.

Das neunte und letzte Kapitel ist ein Benutzerhandbuch. Wahrend das funf-te Kapitel beschreibt, wie das System implementiert wurde und was es kann,

12

Page 13: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

wird hier gezeigt, wie man die einzelnen Funktionen korrekt bedient, was manbeachten muss, welche Systemanforderungen das Programm stellt und wie manes installiert. Zudem werden auch einige Benutzungsszenarien durchgespielt, dietypische Handlungsabfolgen einfach erklaren.

1.1 Einfuhrung in den Energiemarkt

In den letzten Jahren wurde der europaische Energiemarkt zunehmend libe-ralisiert. Das Stromnetz ist nicht mehr in staatlicher Hand, sondern wird voneinigen so genannten Ubertragungsnetzbetreibern (UNB) verwaltet, denen zu-gleich die meisten Kraftwerke gehoren. Die Energiehandler, die eine Vielzahlvon Endkunden zu beliefern haben1, kaufen zu diesem Zweck Strom bei anderenEnergiehandlern und melden die daraus resultierenden Stromflusse regelmaßigden Netzbetreibern. Diese haben die Pflicht, dafur zu sorgen, dass jederzeit aufGrundlage der Angaben der Energiehandler die passende Energiemenge an je-den Ort des Netzes gelangt. Der Datenaustausch zwischen den UNB und denHandlern sowie die Bilanzierung der Energiemengen erfolgt in landerubergrei-fend einheitlichen Standards.

Im Folgenden werden nun in alphabetischer Reihenfolge einige Begriffe er-klart, die fur das Verstandnis der Vorgange auf dem Energiemarkt unabdingbarsind. Des weiteren werden die fur das Verstandnis der Arbeit der Projektgruppeund der Funktionsweise des erstellten Energieinformationssystems (EIS) wich-tigsten 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 UNB ↓ und Energiehandler oder auslan-dischem Netzbetreiber definiert wird. Die Salden von Einspeisung undEntnahme mussen stets ausgeglichen sein. Strom kann zwischen zwei Re-gelzonen nur innerhalb eines Bilanzkreises ausgetauscht werden.

Energiehandler: Energiehandler kaufen Strom bei Kraftwerksbetreibern oderanderen Energiehandlern ein und verkaufen diesen an Endverbraucheroder weitere Energiehandler. Sie verfugen uber kein eigenes Netz und wer-den durch einen bei den UNBs registrierten Bilanzkreis reprasentiert.

European Transmission System Operators (ETSO): Hierbei handelt essich um den Zusammenschluss der europaischen Ubertragungsnetzbetrei-ber mit dem Ziel, die Arbeit besser miteinander zu koordinieren und ein-heitliche Standards fur den Energieaustausch zwischen den verschiedenenNetzen zu schaffen.

ETSO Scheduling System (ESS): Das ETSO Scheduling System ist ein vonder ETSO herausgegebenes, auf XML basierendes Fahrplanformat, in demseit Mitte 2004 alle Akteure am Energiemarkt ihre Fahrplane an die UNBsweiterleiten mussen. Weitergehende Informationen befinden sich in [For03].

1Es gibt auch zahlreiche Akteure wie etwa die Deutsche Bank, die nur zum Zwecke derSpekulation an den entsprechenden Borsen Strom kaufen und verkaufen und keinerlei Kun-denvertrage zu bedienen haben.

13

Page 14: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Fahrplan: Die UNBs erhalten von den anderen UNBs, Energiehandlern undauslandischen Netzbetreibern taglich Fahrplane, in denen in Viertelstun-denblocken der Stromtransfer von einem Bilanzkreis (einer Regelzone) ineinen anderen Bilanzkreis (eine andere Regelzone) in Megawatt aufge-fuhrt wird. Fahrplane konnen kurzfristig angepasst und sogar noch nachInkrafttreten verandert werden. Ihre Erstellung erfolgt auf Grundlage derLastprofile fur Objekte eines bestimmten Bilanzkreises (einer bestimmtenRegelzone).

Lastprofil: Zu jedem Objekt, das mit Strom beliefert wird, gehort ein Last-profil, das seinen Bedarf in Abhangigkeit von Parametern wie Uhr- undJahreszeit beschreibt, um die Stromerzeugung verlasslich planen zu kon-nen.

Regelzone: Jedem UNB ist ein bestimmter Bereich zugeordnet, in dem erStromeinspeisung und -entnahme regelt und die Salden ausgleicht. Die-se Bereiche werden Regelzonen genannt. Innerhalb einer Regelzone kannStrom zwischen beliebigen Bilanzkreisen ausgetauscht werden.

Ubertragungsnetzbetreiber (UNB): Ubertragungsnetzbetreiber sind die-jenigen Unternehmen, denen das Netz an Freiluft- und Erdkabeln zumStromtransport gehort. In Deutschland sind dies EnBW, Vattenfall, RWEund E.ON.

1.1.2 Weitere EIS-spezifische Begriffe

Kaufempfehlung: Eine Kaufempfehlung wird anhand der Lastprognose er-stellt und listet die Angebote auf, deren gleichzeitiger Abschluss moglichstkostengunstig und moglichst vollstandig den fur den Zeitraum der Last-prognose gultigen Strombedarf decken kann.

Kunde: Kunden sind Einzelpersonen, Unternehmen und Haushalte, die ihrenStrombedarf uber den Energiehandler teilweise oder ganz decken.

Kundenvertrag: Kundenvertrage sind Vertrage, die der Energiehandler mitseinen Kunden geschlossen hat und in denen er ihnen Stromlieferungen zubestimmten Konditionen zusichert.

Lastprognose: Lastprognosen werden auf Basis der Lastprofile der Kundenerstellt und geben fur bestimmte Zeitraume an, wie viel Strom voraus-sichtlich eingekauft werden muss, um den Kundenbedarf zu decken. Siewerden fur verschieden lange Zeitraume erstellt.

Lieferant: Unter der Bezeichnung Lieferant werden die Kraftwerksbetreiberund Energieanbieter zusammengefasst, die dem Energiehandler Stromlie-ferungen anbieten.

Lieferangebot: Lieferangebote werden von Lieferanten gemacht und umfasseneine Strommenge, die zu einem bestimmten Preis uber einen bestimmtenZeitraum lang zur Verfugung gestellt werden kann.

Liefervertrag: Liefervertrage sind angenommene Lieferangebote, die dadurchfur den Lieferanten verbindlich geworden sind.

14

Page 15: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Marktdaten: Unter Marktdaten sind die wichtigsten Kurse der European Ener-gy Exchange (EEX) in Leipzig zusammengefasst, die dem Energiehandlerund den Nutzern einen Uberblick uber die aktuelle Marktlage und damitdie Eignung der vorliegenden Angebote gewahren.

Nutzer: Als Nutzer werden im Folgenden die Personen bezeichnet, die das EISbedienen; also im wesentlichen Angestellte des jeweiligen Energiehandlers,der das System einsetzt.

Tarif: Als Tarif werden die Konditionen, zu denen Strom an ein bestimmtesObjekt geliefert wird, genannt. Tarife richten sich im Allgemeinen vorallem nach Abnahmemenge, Lieferzeitraum und Energiemix.

Storung: Storungen sind unvorhergesehene Ereignisse, die die Bereitstellungdes Stroms durch Lieferanten oder die Abnahme des Stroms durch Kundenbeeintrachtigen.

15

Page 16: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

2 Ubersicht uber das Energieinformationssystem(EIS)

2.1 Modellierter Weltausschnitt

Abbildung 1: Der Implementierung zugrunde liegender Weltausschnitt

Abbildung 1 stellt den als Basis des Energieinformationssystems modellier-ten Weltausschnitt dar. In ihm steht der Energiehandler im Zentrum des mo-dellierten Weltausschnitts, weil er der zentrale Akteur ist, der Energieein- und-verkauf koordiniert und das Geschaft uberwacht. Die Ablaufe innerhalb desWeltausschnitts werden durch die schwarzen Pfeile symbolisiert. Kleine Kreisesind Knoten, an denen wichtige Elemente des Weltausschnitts aufeinander tref-fen. Die Rechtecke symbolisieren Entitaten, also zum Beispiel handelnde Sub-jekte. Eine typische Handlungskette, die sich durch den ganzen Weltausschnittzieht, ist die folgende:

Zunachst melden sich Kunden beim Energiehandler an und schließen mit ihmfur beliebige Objekte (Hauser, Fabriken etc.) Vertrage ab, um diese mit Stromzu versorgen. Vertrage basieren auf einem Tarif, in dem der Strompreis und

16

Page 17: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

der Anteil erneuerbarer Energien festgehalten werden. Daruber hinaus verfugensie jeweils uber ein Lastprofil, das zeitlich detailliert aufgeschlusselte Angabenuber die benotigten Energiemengen enthalt. Auf Grundlage der Kundenvertragewerden nun fur jeden Tag Lastprognosen erstellt, die den Gesamtstrombedarfdes Energiehandlers zur Versorgung seiner Kunden berechnen.

Gleichzeitig geben Energieanbieter, also z. B. andere Energiehandler oderKraftwerksbetreiber, Lieferangebote beim Energiehandler ab. Diese Angeboteund die Lastprognosen dienen als Basis fur die vom System erzeugten Kauf-empfehlungen, die nach bestimmten Kriterien wie optimale Bedarfsdeckung oderminimale Kosten Lieferangeboten heraussucht und zum Abschluss vorschlagt.Durch aktuelle Marktdaten von der Europaischen Energieborse werden die Ent-scheidungen des Nutzers zusatzlich beeinflusst.

Aus dem Abschluss von Liefervertragen ergibt sich dennoch oftmals einegewisse Fehldeckung, auch konnen sie durch Storungen wie etwa Kraftwerks-notabschaltungen unerwartet beeintrachtigt werden, weswegen durch kurzfristi-ge Angebote an der EEX versucht werden muss, zusatzlichen Strom zu kaufenoder uberschussigen zu verkaufen. Kommt es an der EEX dazu, dass ein ande-rer Energiehandler ein solches Angebot teilweise oder ganz akzeptiert, resultiertdaraus eine neue Lieferung, hier zur Abgrenzung von herkommlichen Lieferver-tragen als EEX-Lieferung bezeichnet. Sind alle Lieferungen fur einen bestimmtenTag vereinbart und die Kundenbedurfnisse gedeckt, kann der Nutzer einen Fahr-plan im von der ETSO vorgegebenen ESS-Format erstellen, der die einzelnenLieferungen an den Handler fur jeden betroffenen Ubertragungsnetzbetreiberaufsaldiert.

Mit der auf der Grundlage dieses Modells erstellten Software kann unteranderem dieses Szenario nachempfunden werden. Eingesetzt wird sie vom Ener-giehandler, benutzt von seinen Angestellten, die in ihren verschiedenen Rollendie Datenbasis pflegen und sie zur Entscheidungsunterstutzung nutzen. Wennin dem Modell ein Lieferant ein Lieferangebot abgibt, so bedeutet dies fur dieBenutzung des Programms, dass ein Nutzer, dem als Aufgabe die Lieferanten-betreuung zugewiesen wurde, die Daten dieses Angebots ins System eingibt.

2.2 Implementierte Funktionen

Das EIS, das in den vergangenen sechs Monaten implementiert wurde, dientals unterstutzendes System fur einen Energiehandler, der sich bei Stromerzeu-gern, anderen Lieferanten und der Europaischen Energieborse (EEX) mit Stromeindeckt, um seine Kunden, also die Endabnehmer des Stroms, gemaß den lau-fenden Vertragen zu bedienen. Dazu wurden vier große Funktionsblocke imple-mentiert:

• Stammdatenverwaltung: In diesen Block fallen alle Funktionen, die zurAdministration des Systems dienen (Nutzer- und Rechteverwaltung), so-wie die Verwaltung von Kunden- und Lieferantendaten. Hierzu gehorenbei der Kundenverwaltung die personen- oder firmenbezogenen Daten derKunden selbst, ihre Vertrage mit dem Handler, die ihnen Stromlieferun-gen zum Endverbrauch zu sichern, die Lastprofile, nach denen die Kunden

17

Page 18: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

beliefert werden, sowie die verschiedenen Tarife, zu denen der Handler sei-nen Strom anbietet. Zur Lieferantenverwaltung gehort die Verwaltung derpersonen- und firmenbezogenen Daten der Lieferanten sowie deren Liefer-angebote und die abgeschlossenen Liefervertrage. Außerdem kommen dieDatenbestande zu Regelzonen und Bilanzkreise hinzu, die dazu dienen,Vertrage und Stromflusse nach Verantwortungsbereichen zu ordnen, undfur EEX-Handel sowie Fahrplane benotigt werden. Zu jedem dieser Punktebietet die Stammdatenverwaltung Moglichkeiten zum Anlegen, Auslesen,Andern und Loschen von Objekten.

• EEX-Handel: Wahrend normale Liefervertrage eher der langfristigen Ver-sorgung dienen, ist der EEX-Handel eher zur Beseitigung kurzzeitiger Fehl-deckungen gedacht. Es konnen Angebote fur die EEX erstellt und in dievon der EEX bereitgestellten Faxvorlage exportiert werden. Zu abgegebe-nen Angeboten konnen daruber hinaus Lieferungen eingetragen werden,falls sich an der EEX ein Handelspartner gefunden hat. Auf diesem We-ge ist es sowohl moglich, zusatzlich benotigten Strom zu kaufen, als auchuberschussigen Strom zu verkaufen, wahrend herkommliche Liefervertragenur Lieferungen zum Handler vorsehen.

• Entscheidungsunterstutzung: Die Entscheidungsunterstutzung versorgt denHandler mit Informationen zum erwarteten Stromverbrauch fur beliebigeZeitraume, zu aktuellen Versorgungsstorungen, die Liefervertrage betref-fen, sowie zu aktuellen Fehldeckungen. Auf dieser Basis werden Empfeh-lungen zum Abschluss von Lieferangeboten erstellt, die dem Handler er-lauben, moglichst optimal seinen Strombedarf zu decken.

• Fahrplanerstellung: Die Fahrplane werden benotigt, um den Kraftwerksbe-treibern zu signalisieren, wann sie dem Handler welche Mengen an Stromliefern mussen. Dazu wurde ein von der ETSO vorgegebenes XML-Format(ESS) implementiert, das zum Datenaustausch benutzt wird. So konnenFahrplane direkt aus dem System heraus generiert werden, so dass sie nurnoch an die entsprechenden Stellen versandt werden mussen.

Die vom EIS angebotenen Funktionen sind also die folgenden (fur eine de-taillierte Beschreibung siehe auch Kapitel 5):

• Nutzerverwaltung (Anlegen, anzeigen, bearbeiten, loschen)

• Rollenverwaltung (Benutzern Rollen zuweisen und entziehen)

• Kundenverwaltung (Anlegen, anzeigen, bearbeiten, loschen)

• Kundenvertrage (Anlegen, anzeigen, bearbeiten, loschen, zuordnen)

• Lastprofile (Anlegen, anzeigen, bearbeiten, loschen, zuordnen)

• Tarife (Anlegen, anzeigen, bearbeiten, loschen, zuordnen, (de)aktivieren)

• Lieferantenverwaltung (Anlegen, anzeigen, bearbeiten, loschen)

• Lieferangebote/-vertrage (Anlegen, anzeigen, bearbeiten, loschen, zuord-nen, abschließen)

18

Page 19: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• Bilanzkreise (Anlegen, anzeigen, bearbeiten, loschen, (de)aktivieren)

• Regelzonen (Anlegen, anzeigen, bearbeiten, loschen, (de)aktivieren)

• Storungen (Anlegen, anzeigen, loschen)

• Lastprognosen (Berechnen, speichern, loschen, anzeigen, Plugins einbin-den)

• Kaufempfehlungen (Berechnen, umsetzen, speichern, loschen, anzeigen,Plugins einbinden)

• EEX-Angebote (Anlegen, bearbeiten, loschen, anzeigen, exportieren)

• EEX-Lieferungen (Anlegen, bearbeiten, zuordnen, loschen, anzeigen)

• Fahrplane (Anlegen, exportieren, anzeigen, loschen)

Wie schon im Zwischenbericht geschrieben, kann das System nicht dazu ein-gesetzt werden,

• buchhalterische Aufgaben zu erledigen oder automatisieren,

• Stromflusse innerhalb von Bilanzkreisen zu modellieren,

• mehrere Energiehandler gleichzeitig zu verwalten (nur uber mehrere In-stallationen),

• Lastprofile automatisch zu optimieren (nur manuell) und

• Stromhandel zu automatisieren (wohl aber dazu, ihn durchzufuhren).

19

Page 20: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

3 Anforderungen an das Produkt

In diesem Kapitel wird ein Uberblick uber die Anforderungen gegeben, die wah-rend der Implementierung an das Programm gestellt wurden. Sie unterscheidensich in geringem Maße von den in der ursprunglichen Anforderungsdefinition(siehe Kapitel 3 des Zwischenberichts) festgehaltenen Anforderungen, da sichwahrend des weiteren Entwurfs- und Entwicklungsprozesses in manchen Fal-len Anderungen als sinnvoll oder unvermeidbar herausstellten. Ein Vergleichzwischen den initialen und den wahrend der Implementierung gultigen Anfor-derungen steht am Ende dieses Kapitels. Wie die Anforderungen letztendlichumgesetzt wurden, findet sich in Kapitel 4.

3.1 Aus dem Weltmodell abgeleitete Systemabgrenzung

Das zu implementierende Energieinformationssystem soll in der Lage sein, dieAblaufe im Weltmodell nachzuvollziehen und den Energiehandler, der es ein-setzt, in die Lage versetzen, seine Energiekaufe und -verkaufe moglichst effizientzu tatigen im Hinblick auf Kosten und anfallenden Bedarf seiner Kunden. Dar-uber hinaus muss das System in der Lage sein, mit wichtigen Instanzen außer-halb des modellierten Weltausschnitts (Energieborse, Netzbetreiber etc.) zwecksDatenaustausch zu kommunizieren.

Dazu bedarf es einer Reihe weit verbreiteter Standardfunktionen wie etwaeiner Kundenverwaltung, aber auch neuartiger Leistungsmerkmale wie etwa Me-chanismen zum Finden moglichst optimaler Kaufempfehlungen und zur Nutzungder Beschaffungsmoglichkeiten am liberalisierten Energiemarkt, so dass sich eininnovatives Gesamtsystem mit echtem Mehrwert gegenuber bisherigen Losun-gen ergibt. Ebenfalls sollen Fahrplane generiert werden konnen, damit der Ener-giehandler den betroffenen Ubertragungsnetzbetreibern mitteilen kann, wievielEnergie ihm und damit seinen Kunden zugeleitet werden muss.

Mit dem System soll es moglich sein, Energie direkt bei entsprechenden An-bietern einzukaufen oder An- und Verkaufe uber die Energieborse EEX zu ta-tigen. Kernstuck des Systems ist hierbei die Funktion der Entscheidungsunter-stutzung fur die Berechnung des voraussichtlichen Strombedarfs der Kundenzu beliebigen Zeitpunkten und fur die Empfehlung von Lieferangeboten zumKauf. Auf einer Lastprognose aufbauend soll unter Berucksichtigung verschiede-ner Planungsintervalle sowie weiterer Parameter ein Kaufvorschlag unterbreitetwerden, der dann vom Benutzer entsprechend getatigt oder auch verworfen so-wie geandert werden kann. Durch einen steten Abgleich zwischen bestehendenVertragen und dem ermittelten Bedarf soll so ein effizienter Handel mit Ener-gie ermoglicht werden. Weiterhin soll das System Storungen, also kurzfristigeNichterfullungen von Liefervertragen, die etwa durch Kraftwerksausfalle entste-hen, wahrnehmen und behandeln, indem Kaufvorschlage entsprechend angepasstwerden.

Das System soll daruber hinaus Kunden, Lieferanten, deren Vertrage und alleanderen insbesondere zur Entscheidungsunterstutzung notigen Daten verwalten,sowie Daten fur die Lastprognosen und die Ermittlung des Kaufvorschlags (ak-tuelle Energiepreise usw.) beschaffen und langfristig ablegen, um eine Basis furspatere Analysen auf diesen Daten zu bieten.

20

Page 21: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Insgesamt soll sich das System insbesondere durch Entscheidungsunterstut-zung, Nutzung neuer Handelsmoglichkeiten am Energiemarkt, integriertes Fahr-planmanagement und Einhaltung aktueller Standards zum Datenaustausch vonanderen Losungen abheben.

3.2 Funktionale Anforderungen

In Abschnitt 3.1 wurde das Einsatzgebiet des Systems dargestellt. Daraus erge-ben sich die im folgenden erlauterten detaillierten Anforderungen an die Funk-tionalitat des Systems. Anhand der vorangegangenen Systemabgrenzung, in derauch die Funktionen umrissen wurden, lassen sich vier großere Blocke innerhalbder zu erstellenden Software identifizieren: Datenbasis, Entscheidungsunterstut-zung, Energiehandel und Fahrplanmanagement.

3.2.1 Datenhaltung und -zugriff

An die Datenhaltung ergeben sich folgende Anforderungen:

• In der Datenhaltung muss der gesamte modellierte Weltausschnitt repra-sentiert werden.

• Sie muss persistent sein. Einmal gespeicherte Daten durfen nicht verlorengehen, solange sie nicht explizit geloscht werden.

• Sie muss ubersichtlich und in ihrer Struktur an den Zusammenhangen desmodellierten 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 einzelnenDatensatze gewahrleisten, da mit großen Datenmengen zu rechnen ist.

• Sie muss in der Lage sein, Beziehungen zwischen Objekten aufzustellenund die Einhaltung der sich so ergebenden Referenzbedingungen zu uber-wachen.

• Des weiteren muss die Datenhaltung die zu speichernden Daten korrekt,vollstandig, moglichst minimal, lesbar und redundanzfrei darstellen.

Der Zugriff auf die einzelnen Datensatze muss im Normalfall Funktionen zumAuslesen, Anlegen, Andern und Loschen umfassen. Beim lesenden Zugriff aufDaten mussen diese nicht nur aus den persistenten Datenbestanden ausgelesen,sondern auch derart transformiert werden, dass daraus die von der Softwareerwarteten Datentypen resultieren. Umgekehrt mussen die an die Datenhaltungubergebenen Datentypen vor der Speicherung in eine Form uberfuhrt werden,die von der Datenhaltung aufgenommen werden kann. Vor dem Einfugen oderAndern von Datensatzen mussen durch das Programm das korrekte Formatder Daten sowie deren referenzielle Integritat bei Beziehungen untereinandersichergestellt werden.

21

Page 22: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

3.2.2 Dateneingabe und -austausch

Die Dateneingabe erfolgt in der Regel manuell durch die Benutzer des Systems,sofern es sich um einzelne Datensatze oder allgemein kleinere Datenmengen han-delt. Dazu mussen dem Nutzer geeignete Eingabemoglichkeiten zur Verfugunggestellt werden. Dies hat durch eine grafische Oberflache zu geschehen, uber diealle Funktionen, mittels derer ein Nutzer direkt auf den Datenbestand zugreifendarf, angeboten werden.

Fur großere Datenmengen soll das Programm spezielle Schnittstellen be-reithalten, die einen direkten Import oder Export von Daten erlaubt. Sofern dieexportierten Dateien mit anderen Akteuren auf dem Energiemarkt ausgetauschtwerden sollen, sind die derzeit aktuellen Insdustriestandards zu beachten und zuimplementieren. Der Import kann vollautomatisch oder durch manuell angeord-neten Import aus vorliegenden Quellen geschehen, der Export soll ausschließlichauf Veranlassung eines Benutzers erfolgen.

Derartige Schnittstellen bieten sich zum Import an fur Marktdaten der EEX,fur den Export bei Fahrplanen und EEX-Geschaften. Funktionen zum Datenim-port, die automatisch aufgerufen werden, mussen nicht in der grafischen Ober-flache bedienbar sein.

3.2.3 Datenbasis

Die Daten, die als Grundlage fur weitere Berechnungen wie Lastprognosen die-nen, werden als Stammdaten in der Datenbasis zusammengefasst. Hierzu zahlenDaten zu

• Kunden und -vertragen,

• Lieferanten, Lieferangeboten und -vertragen,

• Regelzonen und Bilanzkreisen

• Tarifen und

• Lastprofilen.

Kunden und ihre Vertrage mussen erfasst werden, damit der Energiehandlerweiß, wen er wann mit Strom beliefern muss. Zu den erforderlichen Daten ge-horen personen- oder firmenbezogene Informationen zum Kunden wie Name,Anschrift und Bankverbindung, Daten zur Laufzeit des Vertrages, den Strom-kosten, dem gewunschten Energiemix und den jeweils zu liefernden Strommen-gen.

Lieferanten mit ihren Angeboten und abgeschlossenen Vertragen mussenebenfalls erfasst werden, da sie die Grundlage der Versorgung des Energiehand-lers mit Strom bilden. Zu jedem Lieferanten mussen firmenbezogene Informa-tionen wie Anschrift, Ansprechpartner und Bankverbindung vorliegen. Die Lie-ferangebote mussen Angaben zu Zeitraum, Strommenge, und -preis enthalten.

Um Kunden- und Liefervertrage zwecks Bilanzierung und Durchfuhrung derStromflusse richtig einordnen zu konnen, mussen Bilanzkreise und Regelzonen

22

Page 23: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

zu jedem Angebot und jedem Vertrag erfasst werden. Die von der ETSO erar-beiteten Industriestandards bezuglich dieser beiden Entitaten sind einzuhalten.Das heißt, dass jeder Bilanzkreis und jede Regelzone uber ein Objekt reprasen-tiert wird, das mindestens einen eindeutigen EIC, einen Eignernamen und eineAbkurzung des Eigners enthalt.

Zwecks Vertragsvereinbarung mit den Kunden benotigt das Energieinforma-tionssystem Moglichkeiten zur Tarifgestaltung. Dazu gehort eine Tarifverwal-tung, die es dem Energiehandler erlaubt, Tarife zu erstellen, zu andern, nachKundenwunschen anzupassen und sie einem Kundenvertrag zuzuordnen. Ener-giemixe sollen dabei berucksichtigt werden, da sie in der Zukunft an Bedeutunggewinnen durften.

Um den zeitlich schwankenden Energieverbrauch von Stromkunden wieder-zugeben, werden Lastprofile benotigt. Ihre Reprasentation innerhalb der Soft-ware muss sich ebenfalls an den gangigen Industriestandards ausrichten, wonachVerbrauchswerte in 15-minutigen Intervallen angegeben werden.

Fur alle hier genannten Entitaten sind Funktionen zum Eingeben, Auslesen,Bearbeiten und Loschen notig. Die Zusammenhange zwischen ihnen mussen sichin der Datenhaltung wiederfinden.

Zusatzlich hierzu sollen zur besseren Information des jeweiligen Nutzers dieaktuellen Preisdaten von der EEX bezogen werden konnen. Dazu mussen da-tumsabhangige Informationen uber die verschiedenen Strompreisindizes, die ander EEX notiert werden, in der Software reprasentiert werden. Diese Daten mus-sen taglich aktualisiert werden. Folgende Indizes der EEX sind relevant, da siedas Tagesgeschehen wiedergeben:

• Phelix Day Peak: Preis fur Strom zur Deckung von Spitzenlast

• Phelix Day Base: Preis fur Strom zur Deckung von Normallast

• Off Peak I: Blockpreis fur Lieferung zwischen

• Off Peak II: Blockpreis fur Lieferung zwischen

• Night: Blockpreis fur Lieferung zwischen 0 und 6 Uhr

• Morning: Blockpreis fur Lieferung zwischen 6 und 10 Uhr

• High Noon: Blockpreis fur Lieferung zwischen 11 und 14 Uhr

• Afternoon: Blockpreis fur Lieferung zwischen 15 und 18 Uhr

• Rush Hour: Blockpreis fur Lieferung zwischen 16 und 20 Uhr

• Evening: Blockpreis fur Lieferung zwischen 18 und 24 Uhr

• Business: Blockpreis fur Lieferung zwischen 8 und 16 Uhr

• Stundenpreise: Individuelle Preisangaben fur jede Stunde des Tages

23

Page 24: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

3.2.4 Energiehandel

Unter dem Punkt Energiehandel werden samtliche Funktionen zum Beschaffenund – bei Uberschuss – Veraußern von Energie zusammengefasst. Hier mussfolgende Funktionalitat geboten werden:

• Abschluss von Liefervertragen mit beliebigen Lieferanten

• Angebote zum Strom(ver)kauf an der EEX erstellen

• Auf Basis von EEX-Angeboten vereinbarte Lieferungen registrieren

Zum Abschluss von Liefervertragen mussen bereits eingegangene Lieferangebo-te vom Energiehandler als akzeptiert markiert werden konnen, wobei sich dieubrigen Daten in der Regel nicht andern. Es muss aber dennoch moglich sein,bei Annahme eines Angebots dessen Angaben zu modifizieren, da sich durchVerhandlungen des Lieferanten mit dem Handler Anderungen ergeben habenkonnen. Lieferangbote und -vertrage sollen eher zur langfristigen Deckung desBedarfs des Handlers dienen und dementsprechend langere Laufzeiten (Wochen,Monate etc.) aufweisen. Es ist nicht notig, Lastprofile auch fur Liefervertragezu verwenden, da Lieferungen vom Anfang bis zum Ende eine konstante Mengefestlegen.

Zur Deckung des kurzfristigen Strombedarfs (maximal eine Woche) sollendie durch die Liberalisierung des Energiemarktes neu geschaffenen Handelsmog-lichkeiten an der Europaischen Energieborse in Leipzig genutzt werden konnen.Das Programm muss daher in der Lage sein, EEX-Angebote vorzulegen, diedem Standardformat der EEX entsprechen. Es gibt hier im wesentlichen zweiAngebotsarten, die zur kurzfristigen Bedarfsdeckung infrage kommen. Dies sindStunden- und Blockangebote. Zumindest diese Angebotstypen mussen vom Nut-zer im Programm erstellt, bearbeitet und geloscht werden konnen.

Die auf Basis dieser EEX-Angebote entstandenen Lieferungen mussen eben-falls ins System eingepflegt und verwaltet werden konnen. Dazu gehoren fur jedeEEX-Lieferungen mindestens der Lieferzeitraum, die konstante Liefermenge, derPreis, das zugrunde liegende EEX-Angebot und zwecks Bilanzierung Regelzoneund Bilanzkreis des Lieferanten.

3.2.5 Entscheidungsunterstutzung

Die Entscheidungsunterstutzung enthalt im wesentlichen die Funktionen zurLastprognose und zur Kaufempfehlung. Hinzu kommen Daten zu Storungen inder Belieferung des Handlers mit Energie, wenn beispielsweise ein Kraftwerkheruntergefahren werden musste. Derartige Storungen mussen einzelnen Liefer-vertragen zugeordnet werden konnen. Dies dient dem Zweck, dass perspekti-visch Fehlleistungen der anderen Vertragspartei protokolliert werden sollen, umKonventionalstrafen einzufordern. Außerdem mussen Storungen aus Grundender Planbarkeit des Energiebedarfs mindestens Angaben daruber enthalten, wiegroß der Leistungsausfall ist und ob sie derzeit aktuell sind. Ebenso sollte dieMoglichkeit bestehen, eine Nachricht und einen handlerinternen Code hinzuzu-fugen, um die Storungen besser einordnen zu konnen.

24

Page 25: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Lastprognosen Die Lastprognosen stellen die Basis fur die Kaufentscheidung,mit denen der Strom fur bestimmte Zeitraume eingekauft werden kann. Fur dieBestimmung der Lastdaten werden als Grundlage Lastprofile fur die Kundenverwendet, mit denen eine Prognose fur spatere Kaufentscheidungen getroffenwerden. Die Zeitraume, in denen Prognosen erstellt werden, erstrecken sich min-destens uber

• ein langfristiges (Jahr),

• ein mittelfristiges (Quartal) und

• ein kurzfristiges Intervall (Tag).

Diese Prognosen sollen auch fur Monats- und Wochenfrist erstellt werden kon-nen, jedoch sind diese Moglichkeiten optional. Um eine weitaus bessere Prognosezu erstellen, werden weitere Parameter wie z. B. Wetterdaten oder Lastspitzenbei Großereignissen berucksichtigt. Eine wichtige Anforderung ist die Anpass-barkeit der Parameter und Algorithmen zur Prognoseerstellung an die Bedurf-nisse des jeweiligen Energiehandlers.

Aus Grunden der Kompatibilitat zu den Lastprofilen der Kundenvertragesollen die auf den darin gespeicherten Daten aufbauenden Lastprognosen eben-falls Zeitschemata enthalten, die in 15-minutige Zeitintervalle aufgegliedert sindund den jeweils erwarteten Verbrauch wiedergeben. Des Weiteren muss zu jederLastprognose ihr Gultigkeitszeitraum erfasst werden. Die Erstellung von Last-prognosen muss wegen der zu erwarteten sehr großen Zahl an Kundenvertragennach Eingabe aller benotigten Parameter vollautomatisch erfolgen.

Kaufempfehlungen Das Entscheidungsunterstutzungssystem soll mit Hilfevon Verbrauchsprognosen, bestehenden Vertragen, EEX-Lieferungen und Lie-ferangeboten Kaufvorschlage generieren. Dazu muss zunachst ein Abgleich zwi-schen zugesicherten Lieferungen und dem pronostizierten Verbrauch stattfin-den, um den Fehlbedarf zu ermitteln. Storungen mussen bei der Fehldeckungs-ermittlung ebenfalls einbezogen werden. Dann mussen aus den vorhandenenLieferangeboten die passendsten fur einen Kaufvorschlag herausgesucht werden.Hierbei sollen sowohl langfristige als auch kurzfristige Angebote betrachtet undvorgeschlagen werden, um dem Benutzer einen effizienten Handel mit Energiezu ermoglichen. Langfristige Vertrage sind dabei zu bevorteilen, da sie großereVerlasslichkeit und meistens Kostenvorteile bieten. Vorgesehen ist wie bei derLastprognose die Erstellung von Kaufempfehlung mindestens fur die lange, diemittlere und die kurze Frist. Als standardmaßige Gutekriterien sind mindestensdie Genauigkeit der Deckung des Fehlbedarfs durch den Kaufvorschlag und dieHohe der Kosten zu berucksichtigen.

Als optionale Erweiterung ist eine weitere Optimierung der Kaufvorschla-ge angedacht. Hierbei konnen zusatzliche Parameter, wie zum Beispiel Kun-denfluktuation, fruhzeitig mit in die Betrachtung einbezogen werden, um einebessere Nutzung von Langzeitvertragen zu erreichen. Weiterhin kann mit Hil-fe von Schwellenwerten fur Uber- bzw. Unterdeckungen die Kaufentscheidungverfeinert werden.

25

Page 26: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 2: Aufbau der Entscheidungsunterstutzung

Wie bei Lastprognosen sollen Kaufempfehlungen in hohem Maße flexibel, d.h. an die Bedurfnisse des Energiehandlers und seine bevorzugten Gutekriterienanpassbar sein. Die Erstellung von Kaufempfehlungen muss nach Eingabe derbenotigten Parameter vollautomatisch ablaufen. Es soll daruber hinaus moglichsein, die vorgeschlagenen Angebote auf einen Schlag abzuschließen, wenn dieerstellte Kaufempfehlung den Wunschen des Energiehandlers entspricht. EineUbersicht uber das gesamte Entscheidungsunterstutzungssystem liefert Abbil-dung 2.

3.2.6 Fahrplanmanagement

Fahrplane werden von den Ubertragungsnetzbetreibern benotigt, damit sie wis-sen, wieviel Strom sie zu welcher Zeit produzieren und wohin sie ihn leitenmussen. Seit einigen Jahren ist der Standard fur Fahrplane das XML-basierteESS-Format. Fahrplane werden fur jeweils einen Tag erzeugt und enthalten dienach Bilanzkreisen und Regelzonen aggregierten Lieferungen. Das System mussalso in der Lage sein, alle UNBs, uber die es Strom zur Versorgung seiner Kun-den bezieht, mit EES-konformen Fahrplanen zu versorgen. Die Erstellung dieserFahrplane muss auf Befehl des Nutzers vollautomatisch geschehen, nachdem diebenotigten Parameter eingegeben sind, da eine manuelle Erstellung wegen dergroßen zugrunde liegenden Datenmenge jeden vertretbaren Zeitrahmen spren-gen wurde und uberdies sehr fehleranfallig ware. Eine Nachbereitungsfunktionist gemaß den ETSO-Vorgaben insofern einzurichten, als Fahrplane neu erstelltund mit hoheren Versionsnummern versehen werden konnen.

26

Page 27: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

3.3 Nicht-funktionale Anforderungen

Neben den gerade geschilderten Anforderungen an die Funktionen ergeben sichzahlreiche nicht-funktionale Anforderungen.

3.3.1 Benutzbarkeit

Das Softwaresystem muss von einem Nutzer, der mit den Vorgangen der Ener-giewirtschaft vertraut ist, ohne große Einarbeitungszeit bedient werden konnen.Die Hilfestellung, die vom Programm angeboten wird, kann also von entspre-chenden fachlichen Kenntnissen der Benutzer ausgehen. Eine Anpassung desSystems an fachlich unversierte Privatnutzer ist nicht erforderlich.

Da das System fur den Einsatz im deutschsprachigen Raum gedacht ist,soll die Sprache des Programms standardmaßig Deutsch sein, wenngleich dieMoglichkeit zur spateren Ubersetzung in andere Sprachen bestehen soll.

Die Oberflache muss ubersichtlich gestaltet und nach den einzelnen Funkti-onsblocken gegliedert sein, damit sich Nutzer schnell darin zurecht finden kon-nen. Das Design soll daher weitgehend dem ublichen Look & Feel von Windows-Programmen folgen, jedoch auch eigene Akzente setzen, die es davon leicht abhe-ben, um es unverwechselbar zu machen. Gleichzeitig soll das System insgesamtoptisch ansprechend sein, so dass die Nutzer gerne damit arbeiten.

3.3.2 Zuverlassigkeit

Komplettabsturze des Programms sind zu durch geeignetes Abfangen von Feh-lern zu vermeiden; sie sollen zu keinem Zeitpunkt auftreten. Falls Fehler inner-halb des Programms auftreten, sollen diese dem Benutzer kenntlich gemachtwerden, damit er daruber informiert ist, dass das System nicht so gearbeitet hatwie erwartet. Falsche Benutzereingaben sollen so fruh wie moglich abgefangenwerden, so dass gar kein Prozess mit diesen falschen Eingaben gestartet wirdund Fehler gleich im Vorfeld vermieden werden. Sollte es dennoch zu einem Sys-temabsturz kommen, so durfen keinesfalls bereits gespeicherte Daten verlorengehen.

3.3.3 Effizienz

Das Programm muss sofort auf Nutzereingaben reagieren. Einfache Anfragenwie das Einfugen eines neuen Datensatzes oder das Abfragen einer Liste durfenauch bei großen Datenmengen nicht mehr als wenige Sekunden benotigen. Diesgilt auch fur den Fall, dass mehrere Nutzer gleichzeitig mit dem Programmarbeiten. Samtliche vom Betriebssystem zur Verfugung gestellten Ressourcendurfen voll ausgeschopft werden.

3.3.4 Leistungsverhalten

Das Programm muss mit kleinen, mittleren und großen Datenbestanden pro-blemlos umgehen konnen. Ein großer Datenbestand ist in diesem Kontext ein

27

Page 28: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

solcher, der samtliche Daten eines durchschnittlichen Energiehandlers oder -versorgers, etwa eines Stadtwerks mit einigen zehn- bis hunderttausend Kunden,enthalt.

Die Ergebnisse der Algorithmen zur Entscheidungsunterstutzung mussen imHinblick auf die vorgegebenen Parameter optimal sein, falls es sich nicht um heu-ristische Algorithmen handelt. Heuristische Ergebnisse mussen moglichst nahan den vom Benutzer vorzugebenden Zielwerten liegen. Exakte Ergebnisse sindauch fur die Fahrplanerstellung vonnoten. Hier darf keine Heuristik eingesetztwerden.

3.3.5 Wartbarkeit/Erweiterbarkeit

Das Energieinformationssystem muss auch nach seiner Fertigstellung leicht zumodifizieren und zu erweitern sein. Daruber hinaus mussen Wartungsarbeiten,etwa zum Beheben von Programmfehlern, auch von Menschen, die an der Er-stellung des Projekts nicht beteiligt waren, ohne große Einarbeitungszeit vor-genommen werden konnen. Das Programm muss daher klar strukturiert sein.Die Abbildung des Weltausschnitts auf die Programmbestandteile muss dahernachvollziehbar gestaltet sein. Daruber hinaus sollen die einzelnen funktionalenBlocke wie Datenzugriff oder grafische Oberflache klar voneinander getrennt unduber wohldefinierte Schnittstellen miteinander verbunden werden, so dass mansie durch andere Implementierungen ersetzen kann.

3.3.6 Skalierbarkeit

Die erstellte Software ist als Mehrbenutzersystem auszulegen und muss dement-sprechend eine beliebige Anzahl an Nutzern verwalten konnen. Je nach Hard-wareumgebung mussen auch mehrere oder viele Nutzer gleichzeitig mit demSystem arbeiten konnen, ohne dass sich daraus nennenswerte Geschwindigkeits-beeintrachtigungen ergeben.

3.3.7 Sicherheit

Die Funktionen des Programms und der Datenbestand mussen vor unerlaubtenZugriffen geschutzt sein. Dies gilt sowohl fur Zugriffe von außerhalb uber dieSchnittstellen des Programms als auch fur Zugriffe von angemeldeten Benutzern,die Funktionen aufrufen, fur die sie keine entsprechenden Rechte haben.

3.3.8 Dokumentation

Die Dokumentation soll durch ein ausfuhrliches Benutzerhandbuch erfolgen, dassowohl in gedruckter Form vorliegt als auch innerhalb des Programms kontext-abhangig aufgerufen werden kann. Zusatzlich soll der Quellcode angemessenkommentiert und nach Moglichkeit eine HTML- oder ahnliche Dokumentationdavon, wie dies etwa in Java mittels JavaDoc moglich ist, generiert werden.

28

Page 29: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

3.4 Hinzugefugte und entfallene Anforderungen

Als Vergleichsgrundlage dienen an dieser Stelle das dritte und vierte Kapiteldes Zwischenberichts. Komplett weggelassen wurden gegenuber den darin ent-haltenen Anforderungen lediglich die Wetterdaten. Dies hat drei Grunde: DerAufwand zur Implementierung des ohnehin nur als optional vorgesehenen Leis-tungsmerkmals ware durch den enormen Aufwand zur regelmaßigen Beschaf-fung der benotigten Informationen (Parsen zahlreicher HTML-Seiten; verborge-ne, fehlende, teils unzuverlassige Quellen) unverhaltnismaßig im Vergleich zumNutzen gewesen. Ebenso hatte ein kompliziertes Modell zur adaquaten Beruck-sichtung der Wetterdaten in den Kundenvertragen entwickelt werden mussen,da Wetterdaten in den vorliegenden Lastprofilen anderer Energieversorger nichtbenutzt werden und somit keine Grundlage existiert, auf der man leicht eineigenes System hatte aufbauen konnen.

Die Bedeutung erneuerbarer Energien wurde stark reduziert. Ihr Anteil ander insgesamt gelieferten Energie kann zwar noch fur jeden Tarif festgelegtwerden, findet aber ansonsten, etwa bei Lieferangeboten, keine Berucksichti-gung mehr. Die Berucksichtigung erneuerbarer Energien bei Liefervertragen undKaufempfehlungen konnte ein Ansatzpunkt zur Weiterentwicklung des Systemssein.

Storungen wurden insoweit reduziert, als sie nicht mehr direkt in einen Lie-fervertrag integriert werden, sondern nur noch bei der Berechnung von Lastpro-gnosen zum Einsatz kommen.

In vielen weiteren Fallen wurde wahrend der Entwicklung in Details von denursprunglichen Anforderungen abgewichen, wie bei einem Vergleich zwischenden in diesem Kapitel aufgefuhrten Anforderungen und der Anforderungsdefi-nition aus dem Zwischenbericht zu sehen ist, weil zwischenzeitlich gefundeneAnforderungen und Losungen sich als besser oder realistischer herausstellten.

29

Page 30: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

4 Umsetzung der Anforderungen

Dieses Kapitel beschreibt, welche Technologien, welche Konzepte und welche Ar-chitektur zur Umsetzung der Anforderungen eingesetzt wurden. Außerdem wirdein Uberblick uber den zeitlichen Ablauf der Implementierungsarbeiten gegeben.Im anschließenden Kapitel werden die Details der implementierten Funktionenerlautert.

4.1 Technologien

Dieses Kapitel bietet einen Uberblick uber die Technologien, die im Vorfeld desProjekts zur Verfugung standen. Außerdem wird erlautert, fur welche dieserTechnologien wir uns entschieden haben und warum. Zum besseren Verstandnisder folgenden Diskussion sei erwahnt, dass die Projektgruppe eine Client-Server-Architektur fur ihre Software wahlte, was in Abschnitt 4.3 naher ausgefuhrtwird.

4.1.1 Programmiersprache

Aufgrund der Große des Projekts und weil das Programm moglichst in vie-len Betrieben eingesetzt werden konnen sollte, wollte die Projektgruppe eineerprobte, leicht zu nutzende und kompatible Programmiersprache nutzen. Zu-nachst wurde dazu Java ins Spiel gebracht, da alle Projektgruppenmitgliederdiese Sprache kannten und bereits eingesetzt hatten. Auch ist Java weitestge-hend plattformunabhangig und bietet eine ausgereifte Unterstutzung fur vieleandere Aspekte, die sich sehr fruh als relevant erwiesen, wie Datenbankzugriffoder XML-Verarbeitung. Spatestens aber, nachdem beschlossen war, eine Client-Server-Architektur mit Kommunikation uber Webservices zu implementieren,wurde Java als Programiersprache nicht weiter verfolgt, da einige Projektgrup-penteilnehmer mit Webservices in Verbindung mit Java-Programmen schlechteErfahrungen gemacht hatten. Diese bezogen sich im wesentlichen auf Problememit persistenter Speicherung von Objekten und Beziehungen zwischen diesen ineiner MySQL-Datenbank unter J2EE und dem Java Enterprise Application Ser-ver. Fur den Einsatz einer Client-Server-Architektur unter Java wird aber einsolcher Applicationserver benotigt, daher hatten hier zunachst noch einige Re-cherchen angestellt werden mussen und es ware mit weitergehenden Problemenzu rechnen gewesen. Daruber hinaus wurde die geringe Ausfuhrungsgeschwindig-keit von Java-Programmen bemangelt. Da außerdem eine eigenstandige grafischeOberflache implementiert werden sollte, kam verscharfend hinzu, dass selbst beikomplexen Entwicklungsumgebungen wie Eclipse oder netbeans aus Sicht derTeilnehmer bislang nur unzureichende Unterstutzung bei der Erstellung grafi-scher Oberflachen (GUI) geboten wird.

Nachdem sich die Meinung gegen Java wandte, wurde C# in Verbindungmit dem .NET-Framework von Microsoft vorgeschlagen. Die meisten Teilneh-mer hatten hiermit zwar keinerlei Erfahrungen, jedoch ahnelt diese SpracheJava sehr stark und ist daher leicht zu erlernen, wenn man Java einigermaßenbeherrscht. Die Laufzeitprobleme von Java, die durch das Interpretieren desBytecodes zur Laufzeit entstehen, fallen in C# nicht an, da .NET-Programme

30

Page 31: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

bei Programmstart in nativen Maschinencode ubersetzt und ausgefuhrt werdenkann. Daruber hinaus gibt es mit Visual Studio 2005 eine Entwicklungsumge-bung, die einfaches GUI-Design erlaubt und auch die Erstellung von Webservicessowie das Projektmanagement weitgehend automatisiert. Die Gruppe entschiedsich also fur C# als Programmiersprache.

4.1.2 Datenhaltung

Von Anfang an war im Hinblick auf die in Abschnitt 3.2.1 gestellten Anforde-rungen deutlich geworden, dass nur ein Datenbanksystem fur die Datenhaltunginfrage kommen wurde, weil die zu erwartenden Datenmengen – es handelt sichbei dem Programm schließlich um eine Losung fur großere Unternehmen undviele Benutzer – mit anderen Datenhaltungsmethoden, etwa einer Dateistruk-tur, die uberdies noch aufwandig hatte konzipiert werden mussen, nur außerstineffizient zu handhaben sind.

Die Entscheidung fiel auf den Microsoft SQL Server 2005. Dies geschahvor dem Hintergrund, dass zuvor bereits beschlossen worden war, das .NET-Framework von Microsoft zu benutzen. Daher bot es sich an, auch bei der Da-tenhaltung auf ein Microsoft-Produkt zuruckzugreifen, weil die Kompatibilitatzu den anderen .NET-Technologien am großten ist. Zudem existiert uber die Mi-crosoft Enterprise Library eine machtige Bibliothek, die viele Aufgaben in derKommunikation mit der Datenbank, etwa das Auslesen großer Datenmengeneffizient handhabt und/oder vereinfacht.

MySQL ware noch am ehesten eine Alternative zu SQL Server 2005 gewesen,zumal es frei verfugbar ist. Auch konnen viele Projektgruppenmitglieder Erfah-rungen im Umgang mit MySQL vorweisen. Allerdings ware die Unterstutzungdieser Datenbank durch die .NET-Technologien nicht sehr groß gewesen, und ge-rade bei großen Datenmengen werden MySQL starke Geschwindigkeitsnachteilezugeschrieben.

4.1.3 Grafische Oberflache

Innerhalb des Energieinformationssystems treten zwei Arten grafischer Oberfla-chen auf: Eine eigenstandige, statische GUI, in der das von der Projektgruppeausgelieferte Programm ablauft sowie eine HTML-basierte Oberflache fur diePlugins (siehe Abschnitt 4.2.1), die von den Programmierern der Plugins zuverfassen ist. Die im weiteren erlauterten Designentscheidungen wurden insbe-sondere vor dem Hintergrund getroffen, dass leichte Bedienbarkeit, Uberschau-barkeit und ansprechende Optik wesentliche Anforderungen an die GUI darstel-len.

Eigenstandige GUI Die grafische Oberflache, uber die das Programm ge-steuert wird, greift wiederum auf drei verschiedene Bibliotheken von drei ver-schiedenen Anbietern zuruck, die im folgenden vorgestellt werden.

31

Page 32: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Windows.Forms Die Bibliothek Windows.Forms von Microsoft ist Teildes .NET-Frameworks und beinhaltet zahlreiche Standardelemente zur Erstel-lung einer GUI, etwa Eingabefelder fur Text, Schaltflachen oder Menuleisten.Es lag am nachsten, sich fur den Einsatz dieser Bibliothek zu entscheiden, da siedurch ihre Integration in das Framework und die Unterstutzung durch den Ober-flacheneditor von Visual Studio 2005 einfach zu benutzen und daruber hinausdurch den Einsatz in zahlreichen Applikationen bereits vielfach erprobt ist, waseine hohe Ausgereiftheit versprach. Uberdies versprach sich die Projektgruppedurch die Benutzung von Windows-Standardkomponenten eine hohe intuitiveBenutzbarkeit, weil jeder, der weitverbreitete Programme wie Microsoft Wordbedient, mit ihnen vertraut ist. Windows Forms bieten außerdem vielfaltige Vali-dierungsmoglichkeiten fur Benutzereingaben, indem regulare Ausdrucke benutztoder bestimmte Datentypen zum Abgleich mit den Eingaben herangezogen wer-den, und erleichtern damit die Arbeit nicht unerheblich.

ZedGraph Allerdings konnten mit Windows.Forms nicht alle Anforderun-gen der Projektgruppe im Hinblick auf ihre grafische Oberflache abgedeckt wer-den. So fehlte es beispielsweise an Komponenten zum Erstellen von Diagram-men. Hier wurde nach intensiver Recherche die als Open Source frei verfugbareBibliothek ZedGraph [Zed] gefunden, die eingesetzt wird, um die aktuelle Fehl-deckung sowie die Anteile der verschiedenen Tarife an allen Kundenvertragenzu illustrieren.

Die eingesetzten Diagramme waren notig, um teilweise komplexe Sachverhal-te auf einen Blick zu verdeutlichen. An geeigneten Stellen (Fehldeckungsuber-sicht, Tarifnutzung) wurden Diagramme bewusst eingesetzt, um die Aufmerk-samkeit des Nutzers nicht unnotig zu strapazieren und um ihm die Arbeit beider Erfassung und Einschatzung von Sachverhalten zu erleichtern.

Fireball Daruber hinaus war mit den Standardkomponenten von Win-dows.Forms keine den Vorstellungen der Projektgruppe gerecht werdende Navi-gationsleiste machbar. Zusatzlich zu der Menuleiste am oberen Bildschirmrandsollte eine Navigation am linken Bildschirmrand eingeblendet werden, die zu je-dem Menupunkt umfangreiche Zusatzinformationen einblenden konnte. Hierzubenutzte die Projektgruppe die ebenfalls frei verfugbare Bibliothek FireFX inder Version Beta 2 [Fir].

Diese Bibliothek ermoglichte eine eingangige Navigation im Stile von Micro-soft Outlook abzubilden. Der Projektgruppe war es in diesem Zusammenhangbesonders wichtig, auf bestehende, bewahrte Konzepte zu setzen. Das aufgaben-orientierte Layout von Outlook machte es dabei besonders leicht, Informationenkategorisiert zu prasentieren.

HTML-Oberflache Um die spatere Erweiterung und die Anbindung von ex-ternen Anbietern zu erleichtern, wurde in die Software eine Plugin-Schnittstelleimplementiert (siehe Abschnitt 4.2.1). Die Schnittstelle ermoglicht das einfacheHinzufugen von Algorithmen fur die Lastprognose sowie fur die Kaufempfeh-lung. Durch das Pluginsystem wird große Flexibilitat erreicht.

32

Page 33: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Fur die Umsetzung dieses Systems wurde hauptsachlich auf die umfangrei-chen Moglichkeiten des .NET-Frameworks im Bezug auf Metadaten zuruckge-griffen. Mittels der in .NET integrierten Reflection-API ist es moglich, Infor-mationen uber Objekte zur Laufzeit auszulesen und Objekte und Methodendynamisch zu laden und auszufuhren. Diese Technologie ermoglichte es, mitvergleichsweise geringem Aufwand ein solches Pluginsystem in unsere Softwarezu integrieren. Die Einzelheiten der Umsetzung sowie Informationen fur die Ent-wicklung eigener Plugins fur das EIS-System sind in Kapitel 4.2.1 beschrieben.

Aus der Tatsache, dass uber das Pluginsystem beliebige Algorithmen insProgramm eingebunden werden konnen, und weil eine Client-Server-Architektureingesetzt wurde, ergaben sich zwei neue Anforderungen, die zu Beginn derImplementierung nicht feststanden:

Das Pluginsystem muss uberaus flexibel im Hinblick auf Art und Anzahl derParameter der Algorithmen sein muss. Ein Beispiel: Algorithmus A benotigt dreiParameter vom Typ double, wahrend Algorithmus B nur einen Parameter vomTyp bool fur die Ausfuhrung benotigt. Weil diese Parameter vom Benutzer vorder Ausfuhrung festgelegt werden mussen, ist die Entwicklung einer geeignetenSchnittstelle sowie einer geeigneten Oberflache fur die Eingabe durch den Nutzererforderlich.

Außerdem mussen die oft aufwandigen Algorithmen serverseitig ausgefuhrtwerden, um die Ressourcen des Servers zu nutzen und eine vereinfachtes Deploy-ment zu erreichen. Diese beiden Anforderungen stellten ein Problem da, weil essomit notwendig wurde, eine Oberflache zur Eingabe der Parameter vom Serveran den Client zu senden.

Ein erster Ansatz, das Serialisieren von Windows-Forms mit den Mittelndes .NET-Frameworks, schlug leider fehl, da es grundsatzlich nicht vorgesehenist, Formulare oder Steuerelemente zu serialisieren. Fur diese Problemstellunggibt es folgende Losungsmoglichkeiten, die im Folgenden kurz auf ihre Vor- undNachteile untersucht werden sollen:

• Generische Oberflache: Eine einfache Moglichkeit zur Losung des Pro-blems hatte darin bestanden, eine generische Oberflache zu entwerfen, dieeine beliebige Anzahl an Parameter z. B. in einer Tabellenstruktur an-zeigt und die Eingabe durch den Nutzer ermoglicht. Diese ließe sich etwain einem eigenen Formular unterbringen. Obwohl und auch auch geradeweil diese Moglichkeit sehr einfach umzusetzen war, wurde diese Methodenicht 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 vonnoten, umdem Nutzer bei seinen Eingaben zu unterstutzen. Dies ware mit dieserMethode nicht realisierbar gewesen.

• Framework fur die Serialisierung von Windows-Forms: Da das .NET-Framework keine Serialisierung von Steuerelementen und Formularen un-terstutzt, wurde intensiv nach Frameworks und Open-Source-Werkzeugengesucht die diese Funktionalitat bieten. Jedoch blieb die Suche erfolglos, sodass nur die Moglichkeit blieb, selbst ein Framework zu entwickeln, welchesdie Eigenschaften von Steuerelementen sowie den Aufbau von Formularenin einem Format wie XML serialisiert, so dass eine Deserialisierung auf

33

Page 34: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

der Clientseite wieder moglich ist. Diese Alternative wurde ebenfalls abge-lehnt, da der Aufwand als zu hoch eingeschatzt wurde und sich die Gruppeaußerdem zu weit von der ursprunglichen Problemstellung entfernt hatten.

• Windows Presentation Foundation: Microsoft entwickelt im Moment einneues Framework fur die Oberflachengestaltung, genannt Windows Pre-sentation Foundation. Dieses nutzt eine XML-basierte Sprache zur Be-schreibung von 2D- sowie 3D-Oberflachen. Obwohl das Framework sehrmachtig ist und sich damit optisch sehr ansprechende Oberflachen ent-wickeln lassen, gab es mehrere Punkte die gegen den Einsatz in unseremProjekt sprachen. Zum einen handelt es sich dabei um Beta-Software,die nicht fur den Produktivbetrieb gedacht ist, und zum anderen wurdendurch den Einsatz die Systemanforderungen erhoht, da die Windows Pre-sentation Foundation das .NET-Framework in Version 3 voraussetzt, dieebenfalls noch nicht erschienen ist.

• Webbasierte Oberflache: Diese Losung bietet ein Hochstmaß an Flexibili-tat und der Entwicklungsaufwand wurde als vertretbar eingestuft. Daherhaben wir diese Methode ausgewahlt. Der Ansatz soll im folgenden kurzerlautert werden, wobei die genaue technische Umsetzung in Kapitel 4.2.1beschrieben ist.

ASP.NET-basierte Pluginkonfiguration Bei der auf ASP.NET basier-ten Pluginkonfiguration erstellt der Plugin-Entwickler eine frei definierbare Ober-flache fur das von Ihm entwickelte Plugin. Dabei kann er auf alle Funktionenvon ASP.NET wie die Validierungsfunktionen zugreifen und kann Technologienwie Stylesheets nutzen, um die Pluginoberflache individuell und ansprechend zugestalten. Jede so erstellte Seite muss lediglich einen Knopf mit einem vorgege-benen Namen aufweisen, welcher die Konfiguration abschließt. Diese Webseitewird bei der Konfiguration automatisch in einen in die Clientanwendung des EISintegrierten Browser geladen. Mittels DHTML bzw. JavaScript kommunizierendie Host-Anwendung, also die Windows-Forms-Anwendung, sowie die Webseitemiteinander und tauschen Daten aus. Die genaue technische Umsetzung ist inKapitel 4.2.1 nachzulesen.

4.1.4 Datenaustausch

Einer der wichtigsten Anforderungen (vgl. Kapitel 3) bei einer Client-Server-Anwendung ist der effiziente Datenaustausch zwischen beiden Seiten. Hier wur-den drei Alternativen begutachtet:

• SOAP-Webservices: Webservices bieten ihre Schnittstellen uber XML-Dateien an und sind uber einen eindeutigen Unified Resource Identifierzugreifbar. Der Client richtet also eine Anfrage an den Webservice, derdiese an den Server weiterleitet und das Ergebnis des Servers an denClient zuruckgibt. Hierzu dienen spezielle Protokolle wie das vom WorldWide Web Consortium veroffentlichte und frei nutzbare SOAP. Webser-vices wurden von der Projektgruppe zum Datenaustausch gewahlt, weilsie plattformunabhangig sind und Microsoft Visual Studio sie unterstutzt,

34

Page 35: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

so dass Clients auch fur andere Plattformen entwickelt werden konnen undder Entwicklungsaufwand reduziert wird. Desweiteren ermoglichen sie dieInteraktion von Programmen, die auf unterschiedlichen Betriebssystemenlaufen und in verschiedenen Programmiersprachen geschrieben sind. Da-durch sind alternative Clients, die ebenfalls auf den EIS-Server zugreifenwollen, nicht auf C# festgelegt.

• .NET-Remoting: Bei .NET-Remoting handelt es sich um einen RPC2-Mechanismus, der durch das .NET-Framework bereitgestellt wird. DieKommunikation erfolgt dabei uber so genannte Channels, wobei die ver-breitetste Variante die Nutzung eines Binarformats, das uber TCP uber-tragen wird, ist. Das Protokoll ist proprietar und kann nur von anderen.NET-Anwendungen genutzt werden. Außerdem ist schon ein Nachfolgerdieser Technologie in der Entwicklung, und es kann davon ausgegangenwerden, dass .NET-Remoting in Zukunft in seiner bisherigen Form nichtweiterentwickelt wird. Daher wurde diese Variante trotz des zu erwarten-den Performancevorsprungs gegenuber Webservices nicht eingesetzt.

• .NET Enterprise Services (Com+): Bei den .NET Enterprise Services han-delt es sich um Klassen und Funktionen, die den Zugriff auf die COM+-Dienste bieten. Die COM-Komponententechnologie ist weit verbreitet undbietet eine hohere Geschwindigkeit und zusatzliche Funktionen gegenuberWebservices. Die Nachteile dieser Technologie liegen in der Beschrankungauf die proprietaren Protokolle, die dabei genutzt werden. Es ist dahernicht plattformubergreifend verfugbar. Zudem ist die Einarbeitungszeit indie Technologie hoher und das Deployment aufwandiger als bei der Nut-zung von SOAP-Webservices.

Eine derartige Client-Server-Archtektur mit SOAP-Webservices wurde unter an-derem beispielhaft von Microsoft in Adventure Works [Adv], einem Programmzum Management von Kinos, implementiert und wird auf den Seiten des Micro-soft Developer Networks detailliert beschrieben. Diverse Ansatze und Ideen ausdiesem Programm dienten als Anregungen fur die Programmierung des Energi-einformationssystems.

2Remote Procedure Call, Aufruf einer entfernten Methode

35

Page 36: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

4.2 Konzepte

Dieser Abschnitt beschreibt Konzepte, die von der Projektgruppe eingesetztwurden, um insbesondere nicht-funktionale Anforderungen zu erfullen.

4.2.1 Plugins

Eine zentrale Anforderung an das Entscheidungsunterstutzungssystem (vgl. Ab-schnitt 3.2.5) war die moglichst flexible und den Benutzerwunschen entsprechen-de Gestaltung von Lastprognosen und Kaufempfehlungen. Um dem Endnutzerdes Energieinformationssystems dies zu bieten, entschied sich die Projektgrup-pe, die zugehorigen Funktionen als Plugin-Systeme zu realisieren. Das bedeutet,dass das Programm nicht uber fest in den ubrigen Code eingebettete, vorgege-bene Algorithmen verfugt, die dann bei Benutzung einer dieser Funktionen auf-gerufen werden, sondern dass Drittanbieter in C# oder anderen Sprachen, diedas .NET-2.0-Framework unterstutzen, eigene Berechnungsmethoden erstellenund uber eine vordefinierte Schnittstelle in das System einfugen konnen. Fureinige Teile der Entwicklung des Pluginsystems erwies sich der Artikel PluginArchitecture using C# aus dem Internetportal The Code Project, einem Forumfur Entwickler, die Microsoft Visual Studio .NET einsetzen (siehe [Plu03]), alshilfreich.

Aufbau des Plugin-Systems Im wesentlichen besteht das Plugin-Systemaus nur funf Klassen und Interfaces:

• IPredictionPlugin: In diesem Interface wird die Schnittstelle fur Pluginszum Erstellen von Lastprognosen definiert.

• IRecommendationPlugin: In diesem Interface wird die Schnittstelle furPlugins zum Erstellen von Kaufempfehlungen definiert.

• PluginHost : Diese Klasse stellt Funktionen bereit, die beiderlei Pluginserkennen und registrieren konnen. Sie wird nur intern von der Klasse Plu-ginManager verwendet.

• PluginManager : Diese Klasse stellt Funktionen bereit, die aus dem Webser-vice aufgerufen werden konnen und einen Zugriff auf die Plugins erlauben.

• AdditionalParameter : Hierbei handelt es sich um eine Hilfsklasse zum Um-gang mit den benutzerdefinierten Parametern eines Plugins.

Die Schnittstellen sind im Projekt DataObjects enthalten, welches bei der Ei-genentwicklung eines Plugins referenziert werden muss. Die weiteren Klassen furdie Pluginverwaltung sind im Projekt BusinessLogic zusammengefasst.

Arbeitsweise des Plugin-Systems Wenn das Programm startet, sind zu-nachst keine Plugins geladen. Verfugbare Plugins werden zur Laufzeit eingebun-den, sobald die grafischen Oberflachen zur Erstellung von Lastprognosen oderKaufempfehlungen aufgerufen werden. Plugins mussen dabei als vorkompilierte

36

Page 37: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

DLL-Dateien vorliegen, damit sie erkannt werden konnen. Diese DLLs mussensich im Unterverzeichnis ”Plugins“ im Verzeichnis des Webservices auf dem Ser-ver befinden. Sofern ein Plugin eine spezielle Oberflache zur Konfiguration be-reitstellt, muss diese als ASPX-Datei im virtuellen Verzeichnis des Webservicesliegen.

Wenn in der Clientanwendung das Lastprognosemodul aufgerufen wird, wirdeine Anfrage uber alle verfugbaren Plugins per Webservice-Aufruf an den Servergeleitet. Dieser ruft intern die Klasse PluginManager auf, welche die verfugba-ren Plugins ermittelt. Dabei greift die Klasse PluginManager auf die HilfsklassePluginHost zu und ruft deren statische Methode RegisterPredictionPlugins()auf. Das Unterverzeichnis ”Plugins“ der Webanwendung wird dann nach DLLsdurchsucht, die unter Ruckgriff auf das Paket System.Reflection geladen wer-den. Dabei wird versucht, die in den unterschiedlichen DLL definierten Typenzu finden und sie unter Benutzung der Vererbungseigenschaft als IPrediction-Plugin-Objekte zu instantiieren. Nicht passende Typen werden dabei ignoriert.Ein Fehlschlag mit einem Abbruch des Ladevorgangs entsteht dann, wenn zwarvom Interface abgeleitete Typen gefunden werden, diese aber offenbar nicht dieaktuelle Version der Schnittstelle implementieren (weil beispielsweise Metho-den mehr Parameter haben als vorgegeben). War der Ladevorgang erfolgreich,stehen alle gefundenen Plugins im Array PredictionPlugins zur Verfugung undkonnen von außen abgerufen werden. Die Plugins stehen so lange zur Verfugung,bis durch erneuten Aufruf von RegisterPredictionPlugins() eine neue Suche ge-startet wird. Die Einbindung von Plugins zur Lastprognose verlauft analog uberdie Methode RegisterRecommendationPlugins().

Im Folgenden werden die Ablaufe beim Einbinden von Plugins zur Kauf-empfehlung zur Laufzeit anhand der betreffenden Codeabschnitte der MethodeRegisterRecommendationPlugins nachgezeichnet.

Zunachst werden mit der folgenden Anweisung die Pfade aller DLL-Dateienermittelt, die im Verzeichnis mit dem absoluten Pfad path liegen und im ArraypluginFiles 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, sieals Assembly-Objekte zu laden. Dazu wird das Paket System.Reflection be-notigt, das das Einbinden von kompiliertem Quellcode zur Laufzeit ermoglicht.

Assembly assembly = null;try {assembly = Assembly.LoadFrom(pluginFiles[i]);

} catch(Exception exc) {throw new FileLoadException("Konnte Datei nicht laden: " +pluginFiles[i]);

37

Page 38: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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 allegultigen Plugins aufgenommen werden.List<IRecommendationPlugin> tmp = new List<IRecommendationPlugin>();

Anschließend wird fur jede DLL versucht, alle darin vorhandenen Klassenals Implementierung des IRecommendationPlugin-Interfaces zu instantiieren.Ist dies nicht moglich, tritt eine Ausnahme auf, die aber ignoriert wird, weilin einer DLL beliebige Klassen definiert werden konnen, die nichts mit denPlugins zu tun haben mussen. Dasselbe Verhalten tritt ein, wenn eine andereals die aktuelle Version des Interfaces von der zu ladenden Klasse implementiertwurde. War die Instantiierung erfolgreich, wird die gefundene Klasse in die Listeder 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,uber 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 uber eine eigene Konfigurationsoberflache verfugt, wird diesegeladen wenn der Nutzer aus der Windowsoberlache heraus das Plugin startet.Dabei wird zunachst ein integrierter Webbrowser innerhalb der Windowsanwen-dung gestartet und die im Plugin angegebene URL aufgerufen. Das Plugin selberspezifiziert nur den Dateinamen der ASPX-Datei und der restliche Teil der URLwird dann automatisch ermittelt. Der integrierte Webbrowser basiert auf demInternet Explorer 6. Er ist so konfiguriert, dass nur auf die Seiten des Pluginszugegriffen werden kann und verbietet z.B. Drag und Drop Aktionen aus Sicher-heitsgrunden. Jede Konfigurationsoberflache ist verpflichtet, eine Schaltflachemit dem Namen ”cmdStart“ zu implementieren, welcher die Konfiguration ab-schließt. Nach dem Laden der ASPX-Seite im Browser wird nach diesem Knopfgesucht und es wird ein Eventhandler registriert, der bei einem Klick durch denBenutzer eine Funktion innerhalb der PG-EIS-Client-Anwendung auslost. DieseFunktion liest dann die Daten nach den im Plugin spezifizierten Parameternaus. Anschließend ruft die Clientanwendung eine Methode des Webservices aufund ubergibt dabei die eindeutige ID des Plugins, die Werte fur die Parameterund weitere Werte wie z. B. Start- und Enddatum.

38

Page 39: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Implementierung eines Plugins Das Plugin-System stellt zwei unterschied-liche Schnittstellen fur Lastprognosen und Kaufempfehlungen bereit, die aus-programmiert werden mussen, damit das Plugin-System darauf zugreifen unddas Programm damit sinnvoll arbeiten kann. Beide Schnittstellen verfugen ubereinige Attribute zur Beschreibung des jeweiligen Plugins:

• Id : Eine eindeutige ID, die uber die Methode Guid.NewGuid() erzeugtwerden kann.

• Name: Der offizielle Name des Plugins.

• Author : Der Verfasser des Algorithmus oder die Firma, die das Pluginvertreibt.

• Description: Eine Beschreibung der Funktionsweise des Algorithmus.

• Version: Informationen zur Version des Plugins.

• License: Die Lizenzangaben des Plugins.

• ConfigPanel : Wenn das Plugin uber eine eigene Konfigurationsoberflacheverfugen soll, muss diese Eigenschaft den Namen der ASPX-Datei wie-dergeben, welche die Konfigurationsoberflache enthalt. Eine ASPX-Dateiist ein ASP.NET-Dokument, das neben HTML-Code auch .NET-Code undspezielle Steuerelemente enthalten darf. Durch die Definition einer eigenenASPX-Seite kann jedem Plugin eine umfangreiche und attraktive Oberfla-che zur Konfiguration hinzugefugt werden.

• ParameterWerte: Diese Eigenschaft wird von außen gesetzt nachdem dasPlugin konfiguriert wurde.

Jedes Plugin verfugt außerdem noch uber eine Eigenschaft Parameter, welchedie zusatzlichen Parameter beschreibt die uber die Konfigurationsoberflache vomBenutzer 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

Page 40: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Jeder Parameter enthalt Informationen wie der Wert aus der Konfigurationso-berflache ubernommen werden muss. Die Eigenschaft ElementID liefert einenVerweis auf das Element, z. B. eine Textbox, und die Eigenschaft Attribut be-zeichnet das Attribut, das den Wert, den der Benutzer eingetragen hat, be-schreibt.

Fur die Uberprufung der Korrektheit der vom Benutzer eingegebenen Werteist der Verfasser des Plugins weitgehend selbst verantwortlich. In den mitge-lieferten Plugins wurde die Uberprufung mittels der von ASP zur Verfugunggestellten Validatoren realisiert. Das System macht allerdings zwei Vorgaben,die vom Verfasser erfullt werden mussen. Zum einen muss der Button zum Ab-senden der Eingaben cmdStart heißen. Die zweite Auflage ist ein boolescherWert vali, in den das Ergebnis der Validierung eingetragen werden muss. Die-ser Wert wird spater vom System als Korrektheitsbestatigung der ubergebenenEingaben abgefragt.

Ist die Implementierung abgeschlossen, mussen die Plugins zu DLL-Dateienkompiliert und in das Unterverzeichnis ”Plugins“ kopiert werden, wobei die Kon-figurationsoberflache (APSX-Datei) in das Hauptverzeichnis des Webservice ko-piert werden muss.

Plugins zur Lastprognose Die wichtigste zu implementierende Methode beieinem Plugin zur Lastprognose ist predictEnergyConsumption(). In ihr muss derProgrammierer den Algorithmus unterbringen, der zum Erstellen der Lastpro-gnose benotigt wird. Sie wird nach der Konfiguration des Plugins vom Haupt-programm aufgerufen und bekommt als Parameter ein Start- und ein Endda-tum fur die Lastprognose ubergeben sowie eine Liste mit Kundenvertragen, dieganz in diesen Zeitraum fallen oder sich mit ihm uberschneiden. Als Ruckgabewird ein Objekt vom Typ EnergyPrediction erwartet, das alle Informationen zurLastprognose beinhaltet.

Plugins zur Kaufempfehlung Fur ein Plugin zur Kaufempfehlung muss dieMethode recommendSupplierContracts() implementiert werden. Die Methodeubernimmt die Erstellung der Kaufempfehlung und wird vom Hauptprogrammaufgerufen. Ubergeben werden eine Lastprognose (Typ EnergyPrediction), aufder die Kaufempfehlung aufbaut, indem sie deren Start- und Enddatum so-wie die Verbrauchswerte ubernimmt, sowie drei Listen mit Lieferangeboten und-vertragen (Typ SupplierContract). In der ersten befinden sich bereits abge-schlossene Liefervertrage, die sich mit dem Zeitraum der Kaufempfehlung uber-schneiden, in der zweiten Lieferangebote, die im Resultat der Kaufempfehlungunbedingt auftauchen mussen, und in der dritten Lieferangebote, bei denen derAlgorithmus der Kaufempfehlung selbstandig entscheiden kann, ob er sie zumAbschluss vorschlagt oder nicht. Die Ruckgabe der Methode ist eine Objektvom Typ RecommendationReturn welches ein Statuscode enthalt der besagt obdie Methode erfolgreich war. So ist es moglich, Meldungen an den Benutzer zu-ruckzugeben, falls die von ihm angegebenen Daten nicht fur die Erstellung einersinnvollen Empfehlung ausreichen. Das Objekt RecommendationReturn enthalteine Kaufempfehlung vom Typ Recommendation falls kein Fehler aufgetretenist.

40

Page 41: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

4.2.2 Fehlerbehandlung

Da sich auch bei sorgfaltigen Tests nicht sicherstellen lasst, dass alle System-funktionen fehlerfrei arbeiten und es immer wieder zu Ausnahmesituationenkommen kann, ist eine verlassliche und fur den Nutzer transparente Fehlerbe-handlung außerst wichtig (vgl. hierzu Abschnitt 3.3.2 bei den nicht-funktionalenAnforderungen). Auftretende Ausnahmen werden dabei vom Webservice an dieGUI weitergereicht und dort in aussagekraftige Fehlermeldungen an den Be-nutzer umgesetzt. Desweiteren werden die Fehler vom Webservice und vomService Access Layer abhangig von den jeweiligen Konfigurationseinstellungenprotokolliert. Als Voreinstellung wurden die Dateien C:\eis-log-server.txtund C:\eis-log-client.txt sowie die ausfuhrlichste Protokollierung gewahlt.Die Ursachen fur solche Ausnahmen lassen sich im Wesentlichen in die PunkteProgrammfehler und fehlerhafte Benutzereingaben unterteilen; beide werden imFolgenden vorgestellt.

Programmfehler Zunachst werden Programmfehler betrachtet, also solche,die im regularen Programmablauf entstehen. Dazu werden drei Phasen des Ab-laufs untersucht: Programmstart, laufender Betrieb und Beenden.

Beim Start des Webservice konnen Ausnahmen bezuglich fehlerhafter Konfi-gurationsdateien auftreten; diese werden lediglich in den Protokollen vermerkt.Wahrend des laufenden Betriebs konnen im Webservice Ausnahmen von der Da-tenbank bei Verletzung von Integritatsbedingungen und der Geschaftslogik beider Zugriffs- und Rechtekontrolle ausgelost werden. Sofern der Ruckgabewertder jeweiligen Funktion es zulasst, wird die Ausnahme direkt in eine entspre-chende Ruckgabe umgesetzt. Ansonsten wird die Ausnahme vom Webservice au-tomatisch als SOAP-Fault gekapselt und an den Client weitergereicht. MoglicheAusnahmen kennzeichnen einen fehlgeschlagenen Datenbankzugriff, verschiede-ne Fehler in der Zugriffskontrolle sowie den Hinweis, dass ein gewunschtes Objektnicht in der Datenbank gefunden wurde. Beim Herunterfahren des Webservicekonnen keine Ausnahmen auftreten, da hierbei nicht auf die Datenbank, Biblio-theken oder Konfigurationseinstellungen zugegriffen wird.

Die Kapselung als SOAP-Fault wird vom Service Access Layer durch Ana-lyse der Nachricht (siehe Quellcode auf Seite 42) aufgehoben, die entsprechendeAusnahme erzeugt und an die grafische Oberflache geleitet. Da der serverseitigverwendete Internet Information Server die Fehlermeldung und weitere Datenzur Fehleranalyse in einem einzigen String zusammenfasst, wird diese Nach-richt anhand von Trennzeichen in mehrere Strings aufgeteilt und diese mitden Namensschemata von Exceptions verglichen. Dabei wird der letzte gefun-dene Treffer zur weiteren Auswertung mit den fur diese Anwendung definiertenException-Namen verglichen. Entspricht der Exception-Name einem aus demSchema, wird eine entsprechende Exception erzeugt, ansonsten die allgemeineSystem.Exception.

Die GUI gibt, abhangig von der aufgerufenen Funktion und der Art der Aus-nahme, eine einfache Fehlermeldung aus oder informiert den Nutzer ausfuhrlich(siehe Abbildung 3) uber die aufgetretene Ausnahme und ermoglicht ihm auch,einen Kommentar einzugeben. Dort kann er beispielsweise beschreiben, welcheFunktion er ausfuhren mochte oder welche eingegebenen Daten zum Ausnahme

41

Page 42: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

gefuhrt haben. Der Kommentar wird zusammen mit den Daten der eigentlichenAusnahme 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: Ausfuhrliche Fehlermeldung mit Eingabemoglichkeit

Fehlerhafte Benutzereingaben Die andere Gruppe von Fehlern entstehtdurch Falscheingaben von Benutzern, beispielsweise Daten wie 31.02.2006 oder

42

Page 43: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

24:45 Uhr. Gerade in Eingabefeldern fur Freitext konnen aber auch gezieltfalsche Daten eingegeben werden, die Schadcode in Form von Datenbankbe-fehlen enthalten.

Zur Uberprufung der Eingaben wurden verschiedene Methoden eingesetzt.Sofern es sich um Eingaben handelt, die direkt in vorgegebene Objekte wieDateTime umgewandelt werden sollen, wird die von Windows.Forms bereitge-stellte Funktionaliat Validator eingesetzt. Diesem gibt man uber Eigenschaftenvor, welche Formate und Wertebereiche fur das jeweilige Feld vor. Verletzt dieEingabe diese Eigenschaften, wird ein Icon mit Fehlermeldung eingeblendet.

Handelt es sich um Eingaben, fur die keine vorgegebenen Prufungen exis-tieren (z.B. Namen, Telefonnummern oder Email-Adressen), wird auf die selbstimplementierte Klasse CheckUserInput zugegriffen. Wie im Beispiel-Code aufSeite 43 zu sehen ist, wird zunachst gepruft, ob die Eingabe notwendig ist und,falls keine Eingabe erfolgte, ein Hinweis auf das leere Feld ausgegeben. An-schließend wird gepruft, ob die Eingabe gegen einen regularen Ausdruck gultigist. Dieser Ausdruck beschreibt alle moglichen Zeichenkombinationen, die einegultige Emailadresse darstellen. Schlagt die Prufung fehl, wird ein Hinweis auffehlerhafte 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 Datenbankmanipulieren oder gar loschen sollen, bezeichnet man den Angriff als SQL-Injection. Sofern diese Eingaben die Prufungen passieren, werden sie an denServer weitergeleitet. Dort werden die Werte aber nicht direkt an die Daten-bank ubergeben, sondern zunachst in SqlParameter-Objekten gekapselt. Diesesorgen dafur, dass samtliche SQL-Befehle, die eventuell in den Werten enthaltensind, maskiert werden. Durch die Maskierung erkennt der Datenbankserver sienicht als Befehl, sondern als Wert und speichert sie statt dessen in der Daten-bank.

4.2.3 Transaktionskontrolle

Um Dateninkonsistenzen zu vermeiden, mussen insbesondere schreibende Zu-griffe auf den Datenbestand standig uberwacht und bereits erfolgte Anderungenim Rahmen einer Transaktion bei deren Scheitern wieder ruckgangig gemachtwerden konnen. Diese Transaktionskontrolle dient maßgeblich zur Erfullung der

43

Page 44: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Als Hilfsmittel zur Implementierung dieser Transaktionskontrolle wurdendie in der Assembly System.Transactions bereitgestellten Funktionen genutzt.Insbesondere existiert hier die Klasse TransactionScope, mit der sich Codeblo-cke als eine Transaktion zusammenfassen lassen und die darin untergebrachtenDatenanderungen somit als atomare Operation entweder ganz oder gar nichtausgefuhrt werden.

Die Systemebene, auf der die Transaktionskontrolle implementiert wurde, istder Service Access Layer, in dem die eigentliche Geschaftslogik auf Serversei-te sich befindet. Eine niedrigere Ebene ware nicht moglich gewesen, da in denDatenobjekten selbst keine Operationen stattfinden und die Datenzugriffsebeneaustauschbar ist. Das heißt, das in der vorgenommenen Implementierung zwareine Datenbank eingesetzt wird, aber ein anderes Programmierer-Team genausogut zum Beispiel eine dateibasierte Datenhaltung einfuhren konnte. Ware dieTransaktionskontrolle in der Datenzugriffsebene realisiert worden, musste beijeder neu geschriebenen Datenhaltung auch die Transaktionskontrolle neu ver-fasst werden. Damit man sich darum nicht eigens kummern muss, bleibt nichtsubrig als die Implementierung in der Geschaftslogikebene. Jede hohere Abstrak-tionsebene befande sich im Webservice oder auf Clientseite und ist nicht fur dieAusfuhrung solcher Algorithmen gedacht.

Die Anwendung des Transaktionsmanagers sei hier anhand eines Beispielsdemonstriert. Die Klasse EnergyProfileManager beinhaltet die Geschaftslogikfur den Umgang mit Lastprofilen, die in Kundenvertragen zum Einsatz kommen.Die Methode AddNewEnergyProfile speichert ein vom Webservice ubergebenesLastprofil im System. Der zugehorige 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;

}}

}

Uber die using-Direktive wird der gesamte kritische Code des Schreibzugriffseiner neuen Transaktion unterworfen. Hinter der Methode InsertEnergyProfileverbirgt sich samtlicher Code, der auf die Datenbank zugreift. Falls das Einfu-gen des Objektes gelingt, wird uber den Befehl scope.Complete() die Anderungim Datenbestand irreversibel gespeichert. Andernfalls wird der Bereich uber dieelse-Option verlassen, ohne die Transaktion abzuschließen. Das bedeutet, dassdie bis zum Verlassen der using-Direktive durchgefuhrten Anderungen am Da-tenbestand verworfen werden.

Bei Lesezugriffen dagegen wird auf eine derartige Transaktionskontrolle ver-zichtet, weil es dadurch nicht durch inkonsistente Datenbestande kommen kann.

44

Page 45: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

4.2.4 Rollenbasierte Sicherheit

Das Programm stellt verschiedene Rollen fur Nutzer des Systems bereit, an-hand derer die Zugriffsrechte auf die einzelnen Funktionen kontrolliert werden,um unbefugte Aktionen zu verhindern, wobei ein Nutzer mehrere Rollen auf sichvereinen kann. Die Realisierung dieses Sicherheitskonzeptes erfolgte mit Hilfe derMicrosoft Enterprise Library. Sie bietet die Moglichkeit, innerhalb des Webser-vices, der die Funktionen des Servers nach außen fur Clients zuganglich macht,Zugriffsregeln zu definieren. Das heißt, man weist einer Regel einen Namen zuund gibt an, welche Rolle oder welche Kombination von Rollen ein Nutzer be-sitzen muss, um Funktionen des Programms, die nach dieser Regel behandeltwerden, aufrufen zu durfen.

In Anlehnung an den Entwurf wurden folgende Rollen fur Systemnutzereingefuhrt:

• Administrator: Ein Administrator hat als einziger das Recht, Nutzer anzu-legen, zu bearbeiten und zu loschen. Daruber hinaus kann er ihnen Rollenzubilligen oder aberkennen. Allerdings ergibt sich eine bedeutende Ab-weichung der Administratorenrolle vom Entwurf, da er keine besonderenZugriffsrechte auf andere Daten wie etwa Kundenvertrage hat, kann siealso nicht bearbeiten oder loschen. Dies ist der Tatsache geschuldet, dassein Administrator nicht notwendigerweise Ahnung von den firmeninternenAblaufen hat und seine Pflicht oft darauf reduziert ist, das System amLaufen zu halten, nicht aber, in die Arbeit anderer Nutzer einzugreifen.

• Kundenbetreuer: Kundenbetreuer haben Zugriff auf alle Funktionen, dieKunden in irgendeiner Weise betreffen. Dazu gehort neben der Verwaltungdes Kundenstammes auch der volle Zugriff auf die Kundenvertrage sowiedie Tarife und die Lastprofile, die diesen Vertragen zugeordnet werden.Außerdem konnen Kundenbetreuer Bilanzkreise und Regelzonen verwal-ten. Der Kundenbetreuer ubernimmt also im Vergleich zum Entwurf auchdie Rollen des Tarif- und des Lastprofilspezialisten.

• Lieferantenbetreuer: Analog zu den Kundenbetreuern konnen Lieferanten-betreuer auf alle Funktionen zugreifen, die zur Verwaltung des Lieferan-tenstammes und seiner Vertrage benotigt werden. Ebenso konnen sie Bi-lanzkreise und Regelzonen anlegen, bearbeiten und loschen, da diese auchfur Liefervertrage unabdingbar sind. Nur von ihnen konnen Lastprognosenund Kaufempfehlungen erstellt werden, da diese fur die Entscheidungsun-terstutzung beim Abschluss neuer Liefervertrage benotigt werden. Es ließesich einwenden, dass auch Kundenbetreuer Lastprognosen erstellen konnensollten, weil Kundenvertrage deren Grundlage darstellen, jedoch arbeitensie mit diesen Prognosen im Gegensatz zu Lieferantenbetreuern nicht wei-ter. Lieferantenbetreuer besorgen auch die Fahrplanerstellung, damit dieRegelzonenbetreiber der Lieferanten uber bevorstehende Transaktionen in-formiert sind. Auch legen sie Storungsmeldungen an, wenn ein Lieferver-trag nicht voll erfullt wird. Sie vereinen damit neben ihrer ursprunglichenRolle auch die des Stromhandlers und des Fahrplanspezialisten auf sich.Dies ist moglich, da die Erstellung von Fahrplanen vollstandig, und die vonLastprofilen bzw. Kaufempfehlungen fast vollstandig automatisiert ist undpraktisch keine Spezialkenntnisse mehr notig sind.

45

Page 46: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• EEX-Handler: EEX-Handler haben die Moglichkeit, Block- und Stunden-angebote an der EEX abzugeben und zu korrigieren. Dazu steht ihnenneben den Formularen fur die Angebote auch eine Druck- und PDF -Exportfunktion zur Verfugung, da die EEX in Leipzig die Angebote perFax erwartet. Bestatigte Lieferungen konnen von ihnen mit allen notigenDaten ins System eingespeichert werden.

• Extern: Diese Rolle wird derzeit nicht benutzt, steht aber bereit fur zu-kunftige Erweiterungen des Systems. Es ist angedacht, dass auch externeNutzer, etwa Lieferanten, uber das Internet Zugriff auf bestimmte Funk-tionen des Systems erhalten und dazu diese Rolle zugewiesen bekommen.

Jeder Rolle ist auch eine entsprechende Regel zugeordnet, die ihren Inhabern denZugriff auf die entsprechenden Funktionen gewahrt. Desweiteren existiert eineRegel, die allgemeinen Zugriff ermoglicht. Diese findet beispielsweise Einsatz aufdem Startpanel.

Die Regeln mit den zugehorigen Rollen werden in der Konfigurationsdatei desWebservices hinterlegt (Web.Config). Beim Aufruf einer Methode des Webser-vices wird dann zunachst uberpruft, ob die Anmeldung des Nutzers am Systemuberhaupt gultig ist. Unangemeldet konnen keine Systemfunktionen aufgerufenwerden. Ist der Nutzer korrekt angemeldet, wozu u. a. seine IP mit der im Sys-tem gespeicherten Session-IP ubereinstimmen muss, wird uberpruft, ob seineRollen und die daraus resultiernden Befugnisse fur die aufgerufene Webservice-Funktion ausreichen. Dazu wird vor dem eigentlichen Funktionsaufruf eine Hilfs-funktion aufgerufen, die einen String, der den Namen der Regel fur die folgendeMethode beinhaltet, anhand der Eintrage in der Konfigurationsdatei mit denRollen des Nutzers abgleicht. Nur wenn der Nutzer uber alle Rollen verfugt, diedie Regel verlangt, wird der Methodenzugriff gestattet. Ansonsten kommt es zueiner Fehlermeldung, die an die grafische Oberflache weitergereicht wird und denNutzer uber den verweigerten Zugriff informiert. Der folgende Codeausschnittzeigt 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 Web-service-Methode deklariert. Der folgende Befehl gibt an, dass die Sitzungsdatendes aktuellen Nutzers ubermittelt werden sollen. SoapHeaderDirection.In be-stimmt, dass diese Methode vom Client aus aufzurufen ist. Nach dem Eintrittin die Methode, die ein Objekt vom Typ ReturnCode zuruckgibt, wird mitEnsureSessionIsValid() die Gultigkeit der zuvor ubergebenen Sitzungsdatenuberpruft. Hier kommt es bei Ungultigkeit zu einer Exception.

Danach testet die Methode IstErlaubt(), ob die Rechte des Benutzers furden Zugriff auf DeleteAllSchedules() ausreichen. Hier entsteht ebenfalls eine

46

Page 47: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Exception, falls dies nicht der Fall ist. Uber den ubergebenen String Supplierwird festgelegt, dass diese Methode nur dann aufgerufen werden darf, wenn demNutzer die gleichnamige Rolle aus der Datei Web.Config zugewiesen ist.

4.2.5 Benutzbarkeit/Usability

Schon in einem fruhen Stadium der Implementierung hat die Projektgruppemittels so genanntem Usability Engineering [SB06] das Layout und Design desProgramms validiert und versucht, es kontinuierlich zu verbessern. Aufgrundvon Zeitmangel musste leider auf eine vollstandige und wissenschaftliche Her-leitung der Zielgruppen verzichtet werden. Die Projektgruppe hat sich deshalbeines intuitiven Ansatzes bedient, zumal bei diesem Programm die Zielgruppegenerell relativ leicht zu identifizieren ist. Leider bestand zu keiner Zeit Zugriffauf die in diesem Zusammenhang identifizierten Personen und so mussten dieTests mit branchenfremden Personen durchgefuhrt werden. Jedoch wahlte dieProjektgruppe bei diesen Tests bewusst Personen mit unterschiedlichen Fahig-keiten und Kenntnissen am Rechner, um eine moglichst große Abdeckung anNutzertypen zu erreichen.

Nachdem im Laufe des zweiten Sprints deutlich wurde, dass eine Standardi-sierung der Nutzungsoberflache und eine Uberprufung der Benutzbarkeit notigsei, wurde zuerst der so genannte Hande-hoch-Test nach Art des Fraunhofer-Institutes [FI] eingefuhrt. Nach dem Abschluss der Arbeiten an einem Dialogmußte jeder Entwickler sich folgende Fragen stellen:

1. Kann ich bei Eingabefeldern erkennen, was ich in welchem Format einge-ben kann?

2. Ist erkennbar, was thematisch zusammengehort?

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 genann-ten Usability Lifecyle (siehe Abb. X) statt, d. h., mit Beendigung jedes Sprintswurden drei Personen, die außerhalb der Projektgruppe standen, zum Test derUsability heran gezogen. Auf Basis dieser Testergebnisse wurden dann weite-re Entwurfsentscheidungen getroffen (beispielhafte Testergebnisse siehe Frage-bogen im Anhang). Ziel dabei war es, sowohl Schwachen als auch Starken zuidentifizieren und die Schwachen auszubessern, ohne dabei die Starken zu be-einflussen.

Die Projektgruppe konzentrierte sich dabei darauf, die folgenden Eigenschaf-ten des Programms zu uberprufen. Diese basieren zum Teil auf den DIN-EN-ISO-Normen 9241, 13407 und 14915 (vgl. hierzu [Usa97], [Usa99] und [Usa03]).

47

Page 48: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 4: Usability Lifecycle

1. Aufgabenangemessenheit: Alle benotigten Funktionen sind im Programmenthalten und so gestaltet das sie bei der Erledigung einer Aufgabe unter-stutzen.

2. Selbstbeschreibungsfahigkeit: Die enthaltenen Funktionen sind selbst de-skriptiv und klar ersichtlich.

3. Steuerbarkeit: Das System ist einfach handhabbar und gibt dem Nutzerdie Kontrolle uber die Dialoge.

4. Fehlertoleranz: Fehlermeldungen sind deutlich und erklarend.

5. Lernforderlichkeit: Lernstrategien werden durch schrittweisen Anleitungenoder Anwendungsfalle unterstutzt.

6. Joy of use: Arbeitsablaufe sollen durch ansprechende Gestaltung und trotznotwendiger Konsistenz ”spannend“ gehalten werden und die Nutzung desProgramms interessanter machen.

48

Page 49: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

4.3 Softwarearchitektur

Bei der Softwarearchitektur standen im wesentlichen zwei Moglichkeiten zurDebatte: Eine monolithische Anwendung, die auf jedem fur ihren Gebrauchvorgesehenen Rechner installiert werden muss, und eine verteilte Client-Server-Anwendung, bei der ein Server zentral installiert wird und die einzelnen Rech-ner nur die Client-Programe benotigen. Diese Eigenschaft eines Client-Server-Systems eignet sich insbesondere, um den unter dem Punkt Skalierbarkeit sub-summierten Anforderungen gerecht zu werden.

Der monolithische Programmblock hatte als Vorteil eine vergleichsweise ho-he Effizienz fur die einzelnen Nutzeranfragen mit sich gebracht, weil die ein-zelnen Komponenten eine hohe Verzahnung miteinander aufgewiesen hatten.Allerdings ware dieser Ansatz auch sehr problembehaftet gewesen. Die War-tung durch den Anwender ware erschwert worden, es hatten sich, wenn auch dieDatenbank auf jedem Rechner hatte aufgesetzt werden mussen, Probleme mitDateninkonsistenzen ergeben, und ein Austausch von Teilen des Programms wa-re kaum moglich gewesen. Gerade der letzte Punkt, die Austauschbarkeit vonTeilen des Programms, war aber auch eine wesentliche nicht-funktionale An-forderung der Projektgruppe (siehe Abschnitt 3.3.5). Dazu gehort etwa, dassverschiedene Clients angeboten werden konnen oder dass man den Datenzugriffuber eine andere Datenbank laufen lassen kann. Client-Server-Anwendungenerzwingen im allgemeinen auch eine klare Strukturierung des Programms undbegunstigen damit einfache Wartung durch die Entwickler. Die Geschwindigkeitist zwar durch den Zwang, standig Daten zwischen Client und Server hin- undherschicken zu mussen, geringer, jedoch wiegt das nicht die bislang beschriebe-nen Vorteile auf. Die Projektgruppe entschied sich also fur eine mehrschichtigeClient-Server-Architektur.

Die Architektur unseres Systems orientiert sich dabei bis auf wenige Punktekomplett am Zwischenberichts (vgl. dort Abbildung 4.23). Entfallen sind ausZeitgrunden beispielhafte Implementierungen von Diensten, die externen Be-teiligten zum direkten Zugriff uber das Internet bereitgestellt werden sollten.Hauptwerkzeug zur Erstellung des Projekts war Microsoft Visual Studio 2005,so dass auch auf die Fahigkeiten von .NET 2.0 zuruckgegriffen werden konnte.Das gesamte Programm wurde als so genannte Losung (Solution) mit mehrerenTeilprojekten (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 zweiProgramme zum serverseitigen Befullen der Datenbank mit großen Mengen anKunden- und Lieferantendaten sowie einen ausfuhrlichen Webservice-Test (sieheAbschnitt 6.2) ersetzt.

Abbildung 5 gewahrt einen Gesamtuberblick uber das implementierte Sys-tem. Auf Serverseite befinden sich Datenhaltung und Datenzugriff sowie derWebservice, dessen Funktionen auch dem Client zuganglich sind. Auf Clientsei-te befinden sich die GUI sowie der Service Access Layer als Vermittler zwischenGUI und Webservice. Uber alle Ebenen erstrecken sich die Datenhaltungsklassenund die rollenbasierte Sicherheit.

Abbildung 6 zeigt die Projektstruktur des Systems in Visual Studio. JedesRechteck innerhalb der Solution steht fur ein Teilprojekt. Eine hellgelbe Ein-

49

Page 50: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 5: Architekt des implementierten Energieinformationssystems

Abbildung 6: Struktur der Solution in Microsoft Visual Studio

50

Page 51: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

farbung bedeutet, dass das jeweilige Projekt serverseitig liegt, hellgrune Farbesteht fur Projekte auf Clientseite. Die Teilprojekte Webservice und DataObjectssind anders eingefarbt, weil sie beiden Seiten zur Verfugung stehen.

4.3.1 Datenhaltung

Die Datenhaltungsklassen stellen als unterste Schicht die abstrakten Datenty-pen bereit, die das Ruckgrat des Systems fur den Datenaustausch zwischenden verschiedenen Ebenen bilden. Es wurden zur angemessenen Abbildung desWeltausschnitts Klassen fur Stammdaten (Nutzer, Kunden, Lieferanten sowieVertrage und Rechte), Entscheidungsunterstutzung (Lastprognosen und Kauf-empfehlungen), EEX-Handel und Fahrplane angelegt. Sie stehen dem Servervollstandig zur Verfugung. Der Client hingegen sieht nur diejenigen Klassen, dieals Ruckgabewerte von Webservice-Methoden dienen. Zusatzlich zu den Klassen,die vollstandige Entitaten reprasentieren, gibt es auf das fur jeweilige Aufgabereduzierte Maß Hilfsklassen, die nur die wichtigsten Informationen einer Entitatenthalten. Dies dient dazu, die Datenmengen, die uber den Webservice zu uber-tragen sind, zu reduzieren, da insbesondere bei Anfragen wie ”Zeige eine Uber-sicht aller Kundenvertrage!“ tausende Objekte erzeugt und gesendet werdenmussen. Indem nur die tatsachlich zur Anzeige derartiger Ubersichten erforder-lichen Daten ausgelesen und ubertragen werden – vor allem werden komplexeObjekthierarchien mit zusatzlichen Zugriffen auf die Datenhaltung vermieden–, sinkt die zu ubertragende Datenmenge und damit die Zugriffszeit, was dieAnforderung bezuglich hoher Geschwindigkeit von Datenhaltung und -zugrifferfullen hilft.

4.3.2 Server

Datenzugriff Zur Speicherung der Daten wurde wie geplant der MicrosoftSQL Server 2005 eingesetzt, in dem fur jede Entitat, d. h. jeden abstraktenDatentypen, eine eigene, gleichnamige Tabelle erzeugt wurde. Daruber hinauswaren an mehreren Stellen Verknupfungstabellen notig, um m-n-Beziehungenzu realisieren. Fur das Befullen der Hilfsklassen mit Daten wurden Views ein-gerichtet, die die benotigten Attribute ohne zusatzliche Datenbankabfragen be-reitstellen. Vergleiche hierzu Abbildung 7, die von Microsoft SQL Server 2005aus den vorhandenen Tabellen und Beziehungen zwischen diesen erzeugt wurdeund das Datenbankschema wiedergibt. Dabei sind die einzelnen Tabellen jeweilsmit ihrem Namen und den als Primar- oder Fremdschlussel genutzen Attributenzu sehen. Die Linien zwischen den Tabellen geben Fremdschlusselbeziehungenan.

Der Zugriff auf die Daten erfolgt uber eine austauschbare Architekturschicht,im Projekt Data Layer oder Data Access Layer genannt (vgl. Abbildung 4.23des Zwischenberichts). Samtlicher Code, der auf die Daten zugreift, ist in dieserSchicht gekapselt. In der Regel wurden fur alle Entitaten die Standardroutinenzum Einfugen, Bearbeiten, Loschen und Anzeigen bereitgestellt, wie es im Ent-wurf vorgesehen wurde. Gelegentlich gibt es Ausnahmen, etwa bei Kaufempfeh-lungen und Lastprognose, wo eine (manuelle) Nachbearbeitung nicht vorgesehenist. Zusatzlich wurden bei einigen Objekten weitere Methoden bereitgestellt, dieetwa nur zur Zeit freigegebene Tarife fur Kundenvertrage ausgeben.

51

Page 52: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 7: Datenbankschema des Energieinformationssystems

52

Page 53: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Durch die Kapselung des Datenbankcodes in einer Schicht ist es moglich,diese Schicht komplett durch eine andere auszutauschen, die beispielsweise miteinem Dateisystem im Hintergrund arbeitet, ohne die anderen Schichten anpas-sen zu mussen.

Als weiteres Hilfsmittel kam die Microsoft Enterprise Library zum Einsatz.

Geschaftslogik In der Geschaftslogik werden alle komplizierten Algorithmengebundelt und ausgefuhrt. Dies umfasst:

• Berechnung von Lastprognosen uber Plugins

• Berechnung von Kaufempfehlungen uber Plugins

• Berechnung von aktuellen Uber- und Unterdeckungen

• Erstellung von Fahrplanen

• Uberwachung von Transaktionen

Generell ist die Geschaftslogikschicht (in Abbildung 4.23 des Zwischenberichtsals Business Layer bezeichnet) die Schicht, an die der Webservice samtlicheAnfragen der Clients delegiert, sobald er festgestellt hat, dass der Nutzer dieseAnfrage uberhaupt tatigen darf. Anders als noch im Entwurf dargelegt, gibt esinnerhalb der Geschaftslogik keine streng voneinander abgegrenzten Module furgenau je eine Komponente des Systems, sondern vielmehr Manager-Klassen furalle dem Client zuganglichen Funktionen. Dabei wurde je eine solche Manager-Klasse fur eine einzelne oder wenige logisch direkt zusammenhangende Klassenerstellt.

Reine Datenbankabfragen werden von der Geschaftslogik in der Regel unge-filtert an die darunterliegende Datenzugriffsebene weitergeleitet und ihre Ergeb-nisse nach erfolgreicher Transaktionsausfuhrung zuruckgegeben. Mehr uber dieeinzelnen Funktionen findet sich in den Abschnitten zu Transaktionskontrolle(4.2.3), Lastprognosen (5.3.1), Kaufempfehlungen (5.3.3), Fahrplanen (5.4) undEEX-Handel (5.2).

Webservice Der Webservice dient als Vermittler zwischen Client und Ser-ver und ubernimmt die Funktion der Fassaden aus dem Zwischenbericht. Be-nutzt wird das plattformunabhangige SOAP -Protokoll[SOA03] in Verbindungmit dem Internet Information Server von Microsoft. Zu jeder Methode der Ge-schaftslogik, auf die der Client zugreifen konnen soll, existiert eine gleichnamigeMethode im Webservice, die nach außen zur Verfugung gestellt wird.

Berechnungen finden beim Aufruf einer Webservice-Methode nicht statt, dasamtliche Aufrufe an die Geschaftslogik weitergeleitet und ihre Ergebnisse anden Client zuruckgeschickt werden. Es wird allerdings im Rahmen der rollenba-sierten Sicherheit uberpruft, ob der aktuelle Nutzer eine gultige Anmeldung amSystem sowie die notigen Rechte zum Aufruf dieser Methode vorweisen kann.Ist dem nicht so, wird der Aufruf durch Werfen der entsprechenden Exceptionabgebrochen.

53

Page 54: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

4.3.3 Client

Service Access Layer Der Service Access Layer ist das Bindeglied zwischengrafischer Oberflache und Webservice. Er greift uber eine Schnittstelle auf dievom Webservice bereitgestellten Methoden zu und stellt sie der grafischen Ober-flache bereit. Berechnungen finden in dieser Schicht nicht statt.

Grafische Oberflache (Client) Die grafische Benutzeroberflache, auch GUIabgekurzt, sorgt fur die Interaktion des Nutzers mit dem Programm. Die fer-tige GUI ist dabei ein Zwischenprodukt zwischen Thin und Rich Client, weilsamtliche komplexen Algorithmen wie etwa zur Berechnung eines Lastprofilsserverseitig durchgefuhrt werden, einfache Aufgaben wie etwa Datenvalidierungaber wie im Entwurf angekundigt Aufgabe der GUI-Schicht bleiben. Der Grunddafur ist, dass bei serverseitiger Validierung standig Verbindungen uber denWebservice auf- und abgebaut werden mussten und dies mit dem zugehorigenDatenaustausch eine erhebliche Systembelastung darstellen wurde, nur um ver-gleichsweise simple Berechnungen wie etwa die Uberprufung eines Zahlwertesauszulagern.

Zur Realisierung wurde im Wesentlichen die Grafikbibliothek Windows.Formsbenutzt. Die Oberflache ist dabei zweigeteilt in eine Navigationsleiste auf derlinken Seite und wechselnde Datenpanels auf der rechten Seite. Ebenso wurdenKontextmenus, die mit der rechten Maustaste geoffnet werden, eingefugt sowieeine Menuleiste am oberen Rand des Programms, um den Zugriff auf die ein-zelnen Funktionen moglichst benutzerfreundlich und effizient zu gestalten. DieDarstellung der Daten erfolgt als Ubersicht in der Regel uber Tabellen bzw.bei ihrer Eingabe uber sich offnende Eingabefenster, in denen auch die obenbeschriebenen Validierungsfunktionen aufgerufen werden.

Außerdem wurden an manchen Stellen, z. B. bei der Anzeige der aktuellenUber- oder Unterdeckung zur Veranschaulichung dynamisch generierte Diagram-me eingesetzt, die mit ZedGraph [Zed] erzeugt wurden. Fur die Navigationsleistewurde die Bibliothek Fireball.Windows.Forms von DotNetFireball [Fir] verwen-det. Naheres zu den in der grafischen Oberflachen verwendeten Technologienfindet sich in Abschnitt 4.1.3.

4.4 Ablauf der Implementierung

Die Implementierung begann wenige Tage nach Anfang des Sommersemesters2006 und dauerte bis Ende September desselben Jahres. Zunachst stand imVordergrund, den modellierten Weltausschnitt mit seinen Entitaten und Be-ziehungen zwischen ihnen (siehe Abbildung 1) in Klassen zu ubersetzen, dieseKlassen mit allen benotigten Attributen zu versehen und das so entstandeneDatengerust in der Datenbank adaquat abzubilden. Zeitgleich wurden die ver-schiedenen Schichten der Architektur wie in Abschnitt 4.3 beschrieben festge-legt. Um die Kommunikation des Programms mit der Datenbank sicherzustellen,wurden jetzt die Datenbankzugriffsklassen erstellt und mit Standardfunktionenzum Auslesen, Anlegen, Bearbeiten und Loschen der jeweiligen Objekte aus-gestattet. Obwohl im weiteren Verlauf des Projekts hin und wieder kleinere

54

Page 55: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Anderungen am Klassengerust, der Datenbank und dem -zugriff notig wurden,erwiesen sich diese Projektteile als gut durchdacht und dementsprechend stabil.

Die weitere Implementierung orientierte sich im wesentlichen an den in Ab-schnitt 3 identifizierten Funktionsblocken. Dabei wurden jeweils vertikale Proto-typen erstellt, das heißt, eine oder mehrere Funktionen wurden immer komplettdurch alle Ebenen hindurch programmiert. Dieses Vorgehen erwies sich als vor-teilhaft, da die jeweiligen Funktionen uber die grafische Oberflache und damitunter realistischer Benutzerinteraktion getestet werden konnten.

Zunachst wurden die Stammdaten (Kundenvertrage, Lieferangebote etc.)server- und clientseitig ausprogrammiert und mit einer grafischen Oberflacheversehen. Es folgten darauf aufbauend die Funktionen zur Entscheidungsun-terstutzung, zum EEX-Handel und zur Fahrplanverwaltung. Bei der Entschei-dungsunterstutzung traten allerdings insofern Probleme auf, als das zugehorigePluginsystem fur Lastprognosen und Kaufempfehlungen in der ersten Versi-on seine aufwandigen Berechnungen clientseitig ausfuhrte, was nicht dem Sinneiner Client-Server-Architektur entspricht. Zeitgleich zur Implementierung derHandelsfunktionen musste daher das Pluginssystem umgeschrieben werden. DieAlgorithmen mussten dazu allerdings nicht angepasst werden.

Wahrend der Implementierung der einzelnen Funktionsblocke wurden stan-dig Fehlerbehandlung und Transaktionskontrolle in die neu erstellten Klasseneingefugt. Ebenso wurde standig auf ein einheitliches Aussehen der verschiede-nen GUI-Bestandteile geachtet und bei Abweichungen Anpassungen vorgenom-men. Die rollenbasierte Sicherheit wurde dagegen erst nach weitgehendem Ab-schluss der Implementierungsarbeiten hinzugefugt, da dies nur sehr geringfugigeAnderungen des Programmcodes und ausschließlich in der Webservice-Schichtnach sich zog und somit auf einen Schlag erledigt werden konnte.

Bei der Programmierung der Schnittstellen wurde sehr darauf geachtet, dassdie Anforderungen hinsichtlich der Beachtung von Industriestandards eingehal-ten wurden. Die Fahrplanschnittstelle wurde so gestaltet, dass die Fahrplanda-ten in der Datenbank gespeichert und automatisch in eine XML-Datei im ESS-Format exportiert werden. Die EEX-Daten werden uber ein separates Programmerfasst, das in den Taskplaner unter Windows eingebunden werden kann und je-den Tag automatisch neue oder fehlende Daten von den EEX-Webseiten ausliestund in die Datenbank einfugt. EEX-Angebote werden ins Programm eingege-ben und konnen automatisch in eine Faxvorlage exportiert werden, die von derEEX zur Abgabe von Angeboten eingesetzt wird. In allen drei Fallen wurdenalso die selbst gestellten Anforderungen erfullt. Uber die im Anforderungskapi-tel genannten Schnittstellen hinaus erwies es sich als nutzlich, Importfunktionenfur Regelzonen- und Bilanzkreisdaten anzubieten, da hier ebenfalls recht großeDatenmengen anfallen, die oft aktualisiert werden mussen.

Den letzten Monat verbrachte die Projektgruppe im wesentlichen mit aus-fuhrlichen Tests aller Funktionen und Fehlerkorrekturen, da sich bei derartigenProjekten Fehler auch bei sorgfaltiger Programmierung nicht vermeiden lassen.

55

Page 56: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

5 Implementierung der einzelnen Funktionen

Dieses Kapitel gewahrt einen uberaus detaillierten Uberblick uber die Imple-mentierung der einzelnen Programmfunktionen. Im Vordergrund steht dabei zuerklaren, wie die Implementierung in den einzelnen Schichten erfolgte und wasdie Funktionen genau leisten. Genaue Hinweise zur Bedienung der einzelnenFunktionen sind im Handbuch (Kapitel 9) zu finden.

5.0.1 ReturnCode-Ruckgabewerte

In den folgenden Abschnitten wird bei vielen Funktionen auf Ruckgabewerte desTyps ReturnCode verwiesen, die das Ergebnis oder den Erfolg einer Operationanzeigen. Es handelt sich dabei um eine Enumeration, die eine uberschaubareAnzahl an Codes enthalt, die bestimmte Sachverhalte anzeigen. Dieser Typ wirdinsbesondere dann eingesetzt, wenn boolesche Werte zu ungenau sein konnen.So reicht es zum Beispiel aus Sicht der Fehlerbehandlung nicht aus, wenn nurbekannt ist, dass eine Datenbankabfrage fehlgeschlagen ist; vielmehr ist hier einemoglichst genaue Angabe des Grundes wichtig.

An dieser Stelle wird eine Ubersicht uber die in der Enumeration vorhande-nen Werte und ihre Bedeutung geboten.

• None: Wird zum Initialisieren genutzt und solange noch kein genauererWert ermittelt wurde.

• OK: Bestatigt den Erfolg einer Operation.

• DBFailure: Gibt an, dass eine Operation aufgrund einer falschen oderunzulassigen Datenbankanfrage nicht vollfuhrt werden konnte.

• Error: Gibt an, dass wahrend 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 Durchfuhren einerOperation fehlenden Parameterwert hin.

• IsUsed: Zeigt an, dass ein gespeichertes Objekt noch durch andere gespei-cherte Objekte referenziert wird, so dass eine Loschung damit ausgeschlos-sen ist.

• IsCurrentlyServed: Gibt an, dass ein Vertrag momentan lauft und deswe-gen nicht geloscht 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 be-stehender Storungen nicht geloscht werden darf.

56

Page 57: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• NoSupplierContract: Wird benutzt, wenn eine Kaufempfehlung keine Lie-ferangebote enthalt.

• CalculationFailed: Zeigt an, dass eine numerische Berechnung fehlgeschla-gen ist.

• IsLastAdmin: Gibt an, dass ein Nutzer nicht geloscht werden darf, weil erder letzte Administrator ist.

5.1 Stammdaten

5.1.1 Systemnutzer

Allgemeines Die Systemnutzer sind die Benutzer des Programms die dieFunktionen des Energieinformationssystems nutzen. Dabei ist es notig, die ver-schiedenen Funktionen auch nur denen zur Verfugung zu stellen, die zur Be-nutzung dieser authorisiert sind. Die Benutzerverwaltung stellt dies sicher undmacht es moglich, einem Benutzer eine oder mehrere dynamisch konfigurierbareRollen zuzuordnen. Rollen ermoglichen es, die Rechte zur Benutzung des Pro-gramms einzuschranken. Genaueres uber das Rollenkonzept kann in Abschnitt4.2.4 nachgelesen werden.

Die Verwaltung der Systemnutzer deckt die im Entwurf beschriebenen An-wendungsfalle 1 bis 6 ab. Zusatzlich werden An- und Abmeldung realisiert.

Abbildung 8: Klassen EisUser, Person und EisUserRole

Nutzer mit ihren Daten werden von der Klasse EisUser reprasentiert, dievon der allgemeineren Klasse Person abgeleitet ist. Die zugehorigen Benutzer-rollen werden in der Klasse EisUserRole gespeichert, die als Array in jedemNutzerobjekt gehalten werden (siehe Abbildung 8).

Systemnutzer im Datenzugriff Nutzer werden in der DatenbanktabelleEisUser gespeichert, die die Attribute der gleichnamigen Klasse abbildet. Dieverschiedenen vom System angebotenen Benutzerrollen liegen in der TabelleRole und werden uber die Tabelle EisUserRole mit den einzelnen Nutzern ver-knupft.

In der Klasse EisUserDAL (siehe 9) wird der Datenzugriff auf Benutzer undihre Rechte folgendermaßen gewahrleistet:

57

Page 58: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 9: Klasse EisUserDAL

• DeleteEisUser : Identifiziert einen Systembenutzer uber ein GUID-Objekt,loscht diesen aus der Datenbank und zeigt uber einen ReturnCode denErfolg der Aktion an.

• GetAllEisUsers: Liefert alle in der Datenbank gespeicherten Systemnutzerzuruck.

• GetEisUser : Identifiziert einen Systembenutzer uber ein Guid-Objekt inder Datenbank und liefert das entsprechende EisUser-Objekt zuruck

• GetEisUser : Identifiziert einen Systembenutzer uber ein string-Objekt,das das eindeutigen Login enthalt, in der Datenbank und liefert das ent-sprechende EisUser-Objekt zuruck.

• GetUsersByFirstname: Identifiziert einen Systembenutzer uber ein string-Objekt in der Datenbank anhand seines Vornamens und liefert die entspre-chenden EisUser-Objekte zuruck.

• GetUsersByLastname: Identifiziert einen Systembenutzer uber ein string-Objekt in der Datenbank anhand des Nachnamens und liefert die entspre-chenden EisUser-Objekte zuruck.

• GetUsersByLogin: Funktioniert wie GetEisUser(string s).

• GetUsersByRole: Identifiziert einen Systembenutzer uber ein string-Objekt,das einen Rollennamen angibt, in der Datenbank und liefert eine Liste mitallen Nutzern zuruck, die diese Rolle innehaben.

• GetUsersOnline: Liefert alle in der Datenbank als eingeloggt gekennzeich-neten Systemnutzer in Form einer Liste zuruck.

58

Page 59: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• InsertEisUser : Speichert das ubergebene EisUser-Objekt in der Daten-bank und gibt den Erfolg der Operation uber ein ReturnCode-Objekt zu-ruck.

• UpdateEisUser : Speichert das ubergebene, geanderte EisUser-Objekt inder Datenbank und liefert das Ergebnis der Operation uber ein ReturnCode-Objekt zuruck.

• IsUserUsed : Uberpruft ob der durch das ubergebene eindeutige ID in Formeiner GUID) reprasentierte Systemnutzer durch Referenzen auf andere Da-tensatze von einer Loschung ausgeschlossen ist, weil sonst die referenzielleIntegritat verloren ginge.

Abbildung 10: Klasse UserManager

Systemnutzer im der Geschaftslogik In der Geschaftslogik ist der Sys-temnutzer durch die Klasse UserManager (siehe Abbildung 10) reprasentiert,hier werden keine Algortihmen ausgefuhrt sondern nur Zugriff auf die Daten-haltungsschicht bereitgestellt. Folgende Methoden stehen zur Verfugung:

• AddNewEisUser : Ruft mit dem ubergebenen EisUser-Objekt die stati-sche Methode InsertEisUser der Klasse EisUserDAL auf und gibt derenErgebnis zuruck.

• DeleteEisUser : Ruft mit dem ubergebenen Guid-Objekt die statische Me-thode DeleteEisUser der Klasse EisUserDAL auf und gibt deren Ergebniszuruck.

• GetAllEisUsers: Ruft statische Methode GetAllEisUsers der KlasseEisUserDAL auf und gibt deren Ergebnis zuruck.

59

Page 60: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• GetEisUser : Ruft mit dem ubergebenen Guid-Objekt die statische Me-thode GetEisUser der Klasse EisUserDAL auf und gibt deren Ergebniszuruck.

• GetEisUserRoles: Ruft mit dem ubergebenen Guid-Objekt die statischeMethode GetEisUserRoles der Klasse EisUserDAL auf und gibt deren Er-gebnis zuruck.

• GetUsersByFirstname: Ruft mit dem ubergebenen string die statischeMethode GetUsersByFirstname der Klasse EisUserDAL auf und gibt derenErgebnis zuruck.

• GetUsersByLastname: Ruft mit dem ubergebenen string die statischeMethode GetUsersByLastname der Klasse EisUserDAL auf und gibt derenErgebnis zuruck.

• GetUsersByLogin: Ruft mit dem ubergebenen string die statische Metho-de GetUsersByLogin der Klasse EisUserDAL auf und gibt deren Ergebniszuruck.

• GetUsersByRole: Ruft mit dem ubergebenen string die statische Metho-de GetUsersByRole der Klasse EisUserDAL auf und gibt deren Ergebniszuruck.

• IsUserUsed : Ruft mit dem ubergebenen EisUser-Objekt die statische Me-thode IsUserUsed der Klasse EisUserDAL auf und gibt deren Ergebniszuruck.

• LogOff : Ruft mit dem ubergebenen Guid-Objekt die statische MethodeDeleteSession der Klasse SessionManager auf und meldet den Nutzer mitder ubergebenen GUID dadurch vom System ab.

• LogOn: Meldet einen Nutzer mittels eines ubergebenen Logins und einesPassworts am System an und initialisiert eine neue Session fur diesen Nut-zer oder verweigert die Anmeldung im Falle fehlerhafter Anmeldedaten.

• UpdateEisUser : Ruft mit dem ubergebenen string die statische MethodeGetUsersByRole der Klasse EisUserDAL auf und deren Ergebnis zuruck.

Systemnutzer in der grafischen Oberflache Die Nutzerverwaltung wirdim Programmmenu durch den Button Systemnutzer reprasentiert, wobei nurAdministratoren auf diese Funktion zugreifen durfen. Im zugehorigen Panel (sie-he Abbildung 11) werden alle Systembenutzer mit ihren Stammdaten angezeigt.

Weitere Moglichkeiten in der Nutzerverwaltung sind die Suche bestimm-ter Benutzer anhand verschiedener durch ein Drop-Down-Fenster auswahlbarerParameter. Am unteren Rand befinden sich die Funktionen zum Anlegen, Be-arbeiten und Loschen. Zum Anlegen offnet sich ein Panel (siehe Abbildung 12mit Eingabefeldern und einer Liste zur Rechtevergabe als Popup, analog offnetsich das gleiche Panel beim Bearbeiten eines Benutzers, allerdings muss der zubearbeitende Nutzer in der Liste ausgewahlt worden sein. Zum Loschen einesBenutzers ist eine Bestatigung notig. Das Programm verbietet die Loschung desletzten Administratoren bzw. die Aberkennung des Administratorenstatus fur

60

Page 61: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 11: Ubersicht uber alle Systemnutzer

Abbildung 12: Anlegen oder Bearbeiten eines Nutzers

61

Page 62: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

den letzten verbleibenden, da sonst mangels Zugriffsrechten kein Nutzer mehrZugriff auf die Nutzerverwaltung hatte.

5.1.2 Kunden und -vertrage, Tarife und Lastprofile

Allgemeines Unter Stromkunden sind im Zusammenhang dieses Projektesdie Endabnehmer, also Endkunden eines Handlers zu verstehen, die Vertragemit ihm abschließen und auf dieser Basis mit Strom beliefert werden. Zu jedemKunden werden die wesentlichen personenbezogenen Daten inklusive Bankver-bindung gespeichert. Kunden konnen wegen der referenziellen Integritat derDaten nur geloscht werden, wenn sie nicht uber Vertrage mit dem Handler ver-fugen. Stromkunden werden uber die von der Klasse Person abgeleitete KlasseCustomer dargestellt. In der Datenbank speichert die Tabelle Customer alle zuKunden anfallenden Daten.

Kundenvertrage sind Liefervertrage, die mit einem Endkunden des Unter-nehmens abgschlossen werden. Diese konnen angelegt, bearbeitet und fur denFall, dass kein Kunde mit ihnen Verknupft ist, geloscht werden. Jeder Kunden-vertrag ist einer Regelzone und einem Regelkreis zugeordnet, weshalb es in derKlasse CustomerContract, die Kundenvertrage darstellt, entsprechende Refe-renzen gibt. Daruber hinaus gibt es zur Reduzierung des Datenverkehrs einevereinfachte Version der Kundenvertrage, die in einem Datenbankview gespei-chert und in der Klasse CustomerContractInfo gehalten wird.

Ein Tarif, dargestellt durch die Klasse Tariff beschreibt einen Energietarif,der sich aus Strom aus herkommlichen Quellen, sowie erneuerbaren Energienzusammensetzt. Tarife konnen aktiv oder inaktiv sein. Sind sie aktiv, konnensie fur neu abgeschlossene Kundenvertrage benutzt werden, sonst sind sie auf dieNutzung in vorhandenen Vertragen beschrankt. Jeder Vertrag hat genau einenTarif.

Lastprofile, die uber die Klasse EnergyProfile dargestellt werden, sind dieGrundlage fur Prognosen uber den Energiebedarf, den der Energiehandler, derdas System benutzt, decken muss. Sie ordnen gemaß den Vorgaben der EuropeanTransmission System Operators (ETSO) jeder Viertelstunde eines Tages einenEnergiebedarf in MWh zu. Ein Lastprofil enthalt also insgesamt 96 Werte. JedemKundenvertrag wird genau ein Lastprofil zugewiesen, damit ersichtlich ist, wanndas zu beliefernde Objekt mit wieviel Energie versorgt werden muss.

Im Entwurf war noch vorgesehen, insgesamt sechs derartige Zeitreihen ineinem Lastprofil mit je 96 Werten unterzubringen, um eine Differenzierung derVerbrauchswerte zu erreichen, da diese je nach Jahreszeit und Wochentag starkvoneinander abweichen. Geplant waren Zeitreihen, die zwischen Sommer, Win-ter und einer Ubergangsjahreszeit unterscheiden sowie zwischen Werktagen undWochenenden.

Dies Modell wurde wahrend der Implementierung zugunsten einer einzigenZeitreihe – wie oben beschrieben – verworfen. Dafur gibt es im wesentlichen zweiGrunde:

• Zum einen ist es nicht angenehm, als Nutzer knapp 600 Werte eingeben zumussen, um ein Lastprofil zu erstellen. Hierfur eine geeignete, d. h. nutz-bare grafische Oberflache zu erstellen, ware praktisch unmoglich gewesen.

62

Page 63: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• Andererseits ist das Modell mit sechs Zeitreihen schon recht speziell undubernimmt durch die Abanderung der Verbrauchswerte in Abhangigkeitvon bestimmten Faktoren bereits Aufgaben, die eigentlich der Lastpro-gnose und ihren Algorithmen zufallen. Daher erscheint es sinnvoller, diesauch auf diese Komponente zu verlagern und die Lastprognose auf eineZeitreihe zu beschranken.

Das Zusammenspiel zwischen den verschiedenen Objekten wird in Abbildung 13reprasentiert. Durch die Kundenverwaltung werden die im Entwurf beschriebe-nen Anwendungsfalle 7 bis 27 abgedeckt.

Um den Betrieb des Systems realitatsnah zu simulieren, wurden mehrerezehntausend automatisch generierte Kunden mit einem oder mehreren Vertragenin die Datenbank eingespeist. Als Grundlage fur die Vertrage dienten funf realexistierende Lastprofile, die im Internet heruntergeladen werden konnen [Las06]und unter anderem vom VDEW (Verband der Elektrizitatswirtschaft) benutztwerden. Es handelt sich dabei um Profile fur Telefonzellen, Straßenbeleuchtun-gen, Privathaushalte, kleine Gewerbebetriebe und landwirtschaftliche Betriebe.Es werden jeweils mehrere Zeitreihen fur Werte an verschiedenen Tagen und zuverschiedenen Jahreszeiten angeboten. Die Entscheidung fiel dabei stets auf dieWerte fur Werktage wahrend der Ubergangszeit zwischen Sommer und Winterbzw. umgekehrt, weil dies relativ gut den Verbrauch bei durchschnittlichen Tem-peraturen reprasentiert. Die jahreszeitliche Anpassung der Werte erfolgt dannin den Lastprognosen (siehe Abschnitt 5.3.1).

Kunden im Datenzugriff Kundenobjekte werden durch die Datenbankta-belle Customer abgebildet. In der Klasse CustomerDAL (siehe Abbildung 14)wird der Datenzugriff folgendermaßen gewahrleistet:

• AddNewCustomer : Fugt den ubergebenen Kunden in die Datenbank einund gibt den Erfolg der Operation als ReturnCode zuruck.

• CountCustomers: Zahlt alle in der Datenbank vorhandenen Kundendaten-satze und liefert deren Anzahl als Ruckgabewert zuruck.

• CreateCustomerFromDataRow : Erzeugt aus einem ubergebenen Datensatzaus der Datenbank ein neues Customer-Objekt und liefert es zuruck.

• DeleteCustomer : Identifiziert einen Kunden uber ein Guid-Objekt, loschtdiesen aus der Datenbank und zeigt uber einen ReturnCode den Erfolgder Aktion an.

• GetAllCustomers: Liefert alle in der Datenbank gespeicherten Kunden alsListe von Customer-Objekten zuruck.

• GetCustomer : Identifiziert einen Kunden uber ein Guid-Objekt in der Da-tenbank, liest ihn aus und gibt ihn zuruck.

• UpdateCustomer : Bekommt ein Kundenobjekt ubergeben und aktualisiertdie Daten des bereits gespeicherten Datensatzes mit derselben GUID undgibt den Erfolg der Aktion als ReturnCode zuruck.

63

Page 64: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 13: Klassen zur Kundenverwaltung

Abbildung 14: Klasse CustomerDAL

64

Page 65: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• GetCustomerByNumber : Identifiziert einen Kunden anhand seiner von derDatenbank vergebenen eindeutigen Kundennummer, liest ihn aus und gibtihn zuruck.

• GetCustomerByName: Liefert eine Liste mit allen Kunden zuruck, derenNachname einer ubergebenen Zeichenkette hinreichend ahnelt.

• GetCustomerByCity : Liefert eine Liste mit allen Kunden zuruck, derenWohnort einer ubergebenen Zeichenkette hinreichend ahnelt.

• GetCustomerByContract : Liefert einen Kunden zuruck, dem ein Kunden-vertrag mit einer bestimmten ubergebenen GUID zugeordnet ist odernull, falls kein Kunde gefunden wurde.

Abbildung 15: Klasse CustomerManager

Kunden in der Geschaftslogik In der Geschaftslogik steht die KlasseCustomerManager bereit (siehe Abbildung 15). Hier werden keine Algorithmenausgefuhrt sondern nur Zugriff auf die Datenhaltungsschicht bereitgestellt. Fol-gende Methoden stehen zur Verfugung:

• AddNewCustomer : Ruft mit dem ubergebenen Customer-Objekt die stati-sche Methode InsertCustomer der Klasse CustomerDAL auf und gibt derenErgebnis zuruck.

• CountCustomer : Ruft die gleichnamige Methode aus der Klasse CustomerDALauf und gibt deren Ergebnis zuruck.

• DeleteCustomer : Ruft mit dem ubergebenen GUID-Objekt die statischeMethode DeleteCustomer der Klasse CustomerDAL auf und gibt deren Er-gebnis zuruck.

• GetCustomer : Ruft mit dem ubergebenen Customer-Objekt die statischeMethode GetCustomer der Klasse CustomerDAL auf und gibt deren Er-gebnis zuruck.

65

Page 66: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• GetAllCustomers: Ruft die statische Methode GetAllCustomers der KlasseCustomerDAL auf und gibt deren Ergebnis zuruck.

• UpdateCustomer : Ruft mit dem ubergebenen Customer-Objekt die sta-tische Methode UpdateCustomer der Klasse CustomerDAL auf und gibtderen Ergebnis zuruck.

• GetCustomerByNumber : Ruft mit dem ubergebenen ID aus dem die sta-tische Methode GetCustomerByNumber der Klasse CustomerDAL auf undgibt deren Ergebnis zuruck.

• GetCustomerByName: Ruft mit der ubergebenen Zeichenkette die stati-sche Methode GetCustomerByName der Klasse CustomerDAL auf und gibtderen Ergebnis zuruck.

• GetCustomerByCity : Ruft mit der ubergebenen Zeichenkette die statischeMethode GetCustomerByCity der Klasse CustomerDAL auf und gibt derenErgebnis zuruck.

• GetCustomerByContract : Ruft mit dem ubergebenen GUID-Objekt diestatische Methode GetCustomerByContract der Klasse CustomerDAL aufund gibt deren Ergebnis zuruck

Abbildung 16: Klasse CustomerCustomerContractDAL

Kundenvertrage im Datenzugriff Fur Kundenvertrage steht die TabelleCustomerContract zur Verfugung, die 1-1 -Fremdschlusselbeziehungen zu denTabellen Customer, EnergyProfile, Tariff, AccountingArea und ControlAreaenthalt. In der Klasse CustomerContractDAL (siehe Abbildung 16) wird der Da-tenzugriff folgendermaßen gewahrleistet:

• CountCustomerContracts: Zahlt alle vorhandenen Kundenvertrage in derDatenbank und gibt ihre Anzahl zuruck.

66

Page 67: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• CountCustomerContractsPerTariff : Zahlt zu einem Tarif mit einer be-stimmten GUID alle vorhandenen Vertrage in der Datenbank und gibtihre Anzahl zuruck.

• CreateCustomerContractFromDataRow : Erzeugt aus einer ausgelesenenTabellenzeile ein neues CustomerContract-Objekt.

• CreateCustomerContractInfoFromDataRow : Erzeugt aus einer ausgelese-nen Viewzeile ein neues CustomerContractInfo-Objekt.

• DeleteCustomerContract : Identifiziert einen Kundenvertrag uber eine GUID,loscht diesen aus der Datenbank und zeigt uber einen ReturnCode den Er-folg der Aktion an.

• GetAllCustomerContracts: Liefert alle in der Datenbank gespeichertenKundenvertrage zuruck.

• GetCustomerContract : Identifiziert einen Kundenvertrag uber eine GUIDin der Datenbank, liest ihn aus und liefert ihn zuruck.

• GetCustomerContractInfosForEnergyPrediction: Liefert alle in der Daten-bank gespeicherten Kundenvertrage, die teilweise oder ganz in den Zeit-raum einer Lastprognose fallen, als vereinfachte CustomerContractInfo-Objekte in einer Liste zuruck.

• GetCustomerContractsForEnergyPrediction: Liefert alle in der Datenbankgespeicherten Kundenvertrage als Liste zuruck, die teilweise oder ganz inden Zeitraum einer Lastprognose fallen.

• GetCustomerContractsForCustomer : Liefert alle fur einen Kunden mit ei-ner bestimmten GUID gespeicherten Kundenvertrage zuruck.

• GetExpiringCustomerContracts: Liefert eine Liste aller Kundenvertragezuruck, die bis zu einem ubergebenen Datum auslaufen.

• InsertCustomerContract : Fugt ein neues CustomerContract-Objekt in dieDatenbank ein und gibt den Erfolg der Operation als ReturnCode zuruck.

• HasCustomerContracts: uberpruft in der Datenbank, ob zu einem KundenKundervertrage bestehen, und liefert True zuruck, falls dem so ist, oderFalse.

• UpdateCustomerContract : Andert mittels des ubergebenen Kundenvertra-ges die Werte des bereits in der Datenbank gespeicherten Datensatzes mitderselben GUID in der Datenbank und liefert den Erfolg der Operationuber einen ReturnCode zuruck.

Kundenvertrage in der Geschaftslogik In der Geschaftslogik ist der Kun-denvertrag durch die Klasse CustomerContractManager reprasentiert (siehe Ab-bildung 17). Folgende Methoden stehen zur Verfugung:

• AddNewCustomerContract : Ruft mit dem ubergebenen CustomerContract-Objekt die statische Methode InsertCustomerContract der KlasseCustomerContractDAL auf und gibt deren Ergebnis zuruck.

67

Page 68: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 17: Klasse CustomerCustomerContractManager

• CountCustomerContracts: Ruft die gleichnamige Methode der KlasseCustomerContractDAL auf und gibt deren Ergebnis zuruck.

• CountCustomerContractsPerTariff : Ruft die gleichnamige Methode derKlasseCustomerContractDAL auf und gibt deren Ergebnis zuruck.

• DeleteCustomerContract : Ruft mit der ubergebenen GUID die gleichnami-ge Methode der Klasse CustomerContractDAL auf und gibt deren Ergebniszuruck.

• GetAllCustomerContracts: Ruft die gleichnamige Methode der KlasseCustomerContractDAL auf und gibt deren Ergebnis zuruck.

• GetCustomerContract : Ruft mit der ubergebenen GUID die g leichnamigeMethode der Klasse CustomerContractDAL auf und gibt deren Ergebniszuruck.

• GetCustomerContractsForCustomer : Ruft die gleichnamige Methode derKlasse CustomerContractDAL auf und gibt deren Ergebnis zuruck.

• GetCustomerContractsForEnergyPrediction: Ruft die gleichnamige Metho-de der Klasse CustomerContractDAL auf und gibt deren Ergebnis zuruck.

• GetCustomerContractInfosForEnergyPrediction: Ruft die gleichnamige Me-thode der Klasse CustomerContractDAL auf und gibt deren Ergebnis zu-ruck.

• GetExpiringCustomerContracts: Ruft mit dem ubergebenen Datum diegleichnamige Methode der Klasse CustomerContractsDAL auf und gibtderen Ergebnis zuruck.

68

Page 69: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• UpdateCustomerContract : Ruft mit dem ubergebenen CustomerContract-Objekt die gleichnamige Methode der Klasse CustomerContractDAL aufund gibt deren Ergebnis zuruck.

• HasCustomerContracts: Ruft die gleichnamige Methode der KlasseCustomerContractDAL auf und gibt deren Ergebnis zuruck.

Abbildung 18: Anlegen oder Bearbeiten eines Kunden

Abbildung 19: Anlegen oder Bearbeiten eines Kundenvertrages

Kunden und Kundenvertrage in der grafischen Oberflache In der gra-fischen Oberflache wurde fur die gesamte Kundenverwaltung ein zweiteiligesPanel entworfen (siehe Abbildung 20), auf das Zugriff nur moglich ist, wennder Nutzer die Rolle Kundenbetreuer besitzt. Bei der Auswahl des MenupunktsKunden in der linken Navigationsleiste wird es aufgerufen und zeigt im oberen

69

Page 70: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Teil eine Kundenliste an, die bestimmten Suchkriterien entspricht. Es kann nachNachnamen, Kundennummern, Nutzern mit bestimmten Tarifen und Wohnor-ten gesucht werden. Dass anfangs nicht alle Nutzer angezeigt werden dient da-zu, die uber den Webservice zu ubertragende Datenmenge gering zu halten. Beieinigen Zehntausend registrierten Kunden konnten hierdurch bei vielen Nut-zern nicht mehr vernachlassigbare Verzogerungen entstehen. Zu den gefundenenKunden werden alle wichtigen Daten angezeigt, die nach Auswahl eines Eintragsuber Doppelklick, das Kontextmenu oder einen Klick auf den Button Bearbei-ten editiert werden konnen. Dazu offnet sich, ebenso wie nach dem Klick aufAnlegen, ein neues Panel, in das die Benutzerdaten eingetippt werden konnen(siehe Abbildung 18).

Abbildung 20: Ubersicht uber Kunden und ihre Vertrage

Im unteren Teil des Hauptpanels werden zu jedem ausgewahlten Kundenseine Vertrage – sowohl gultige wie auch abgelaufene oder zukunftige – angezeigt.Auch fur die Kundenvertrage stehen die Funktionen Anlegen, Bearbeiten undLoschen zur Verfugung, wobei nur solche Vertrage geloscht werden konnen, dienoch nicht in Kraft getreten oder bereits abgelaufen sind. Neue Vertrage konnennur nach Auswahl eines Kunden, dem sie zugeordnet werden sollen, angelegtwerden. Bei einem Klick auf den zugehorigen Button Anlegen wird ein Fensterzur Dateneingabe geoffnet (siehe Abbildung 19), ebenso wenn ein Vertrag zumBearbeiten ausgewahlt wird.

70

Page 71: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Außerdem werden im Fenster links uber der Navigationsleiste die aktuellaktiven Tarife nach angezeigt, die nach der Haufigkeit ihrer Nutzung geordnetsind. Nicht aktive Tarife werden nicht angezeigt, da sie dem Systemnutzer nichtfur den Abschluss neuer Vertrage zur Verfugung stehen.

Tarife im Datenzugriff Tarife sind in der Datenbank durch die TabelleTariff dargestellt. Der Datenzugriff wird uber die statische Klasse TariffDALrealisiert, die die folgende statische Methoden bereitstellt

• CreateTariffFromDataRow : Erzeugt aus einer ausgelesenen Tabellenzeileein neues Tariff-Objekt und gibt es zuruck.

• InsertTariff : Fugt ein ubergebenes Tariff-Objekt als neuen Tarif in dieDatenbank ein und zeigt uber einen ReturnCode den Erfolg der Aktionan.

• UpdateTariff : Aktualisiert anhand eines ubergebenen Tariff-Objekts einenin der Datenbank gespeicherten Tarif und zeigt uber einen ReturnCode denErfolg der Aktion an.

• DeleteTariff : Loscht einen in der Datenbank gespeicherten Tarif und zeigtuber einen ReturnCode den Erfolg der Aktion an.

• IsTariffUsed : Uberpruft, ob ein Tarif noch von Kundenvertragen benutztwird, und gibt das Ergebnis als booleschen Wert zuruck.

• GetTariff : Liest einen Tarif mit einer ubergebenen GUID aus der Daten-bank aus und gibt ihn zuruck.

• GetActiveTariffs: Liest alle Tarife mit aktiven Status aus der Datenbankaus und liefert sie als Liste zuruck.

• GetRankedTariffs: Liest alle Tarife aus der Datenbank aus und gibt sienach Benutzungshaufigkeit geordnet als Liste zuruck.

• GetRankedActiveTariffs: Liest alle aktiven Tarife aus der Datenbank ausund gibt sie nach Benutzungshaufigkeit geordnet als Liste zuruck.

• GetAllTariffs: Liest alle Tarife aus der Datenbank aus und liefert sie alsListe von Tariff-Objekten zuruck.

Tarife in der Geschaftslogik In der Geschaftslogikschicht existiert die stati-sche Klasse TarifManager zum Umgang mit Tarifen. Bereitgestellte Methoden:

• AddNewTariff : Ruft mit dem ubergebenen Tariff-Objekt die statischeMethode InsertTariff der Klasse TariffDAL auf und deren Ergebnis zu-ruck.

• DeleteTarif : Ruft mit der ubergebenen GUID die statische Methode De-leteTariff der Klasse TarifDAL auf und git deren Ergebnis zuruck.

• GetActiveTariffs: Ruft die statische Methode GetActiveTariffs aus derKlasse TarifDAL auf und liefert deren Ergebnis als Array zuruck.

71

Page 72: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• GetAllTariffs: Ruft die statische Methode GetAllTariffs aus der KlasseTariffDAL auf und liefert deren Ergebnis als Array zuruck.

• GetRankedTariffs: Ruft die statische Methode GetRankedTariffs aus derKlasse TariffDAL auf und liefert deren Ergebnis als Array zuruck.

• GetRankedActiveTariffs: Ruft die statische Methode GetRankedActiveTa-riffs aus der Klasse TariffDAL auf und liefert deren Ergebnis als Arrayzuruck.

• GetTariff : Ruft mit einer ubergebenen GUID fur ein Tariff-Objekt diestatische Methode GetTariff der Klasse TariffDAL auf und gibt das Er-gebnis zuruck.

• IsTariffUsed : Ruft die statische Methode IsTariffUsed der Klasse TariffDALauf und ubergibt ein Tariff-Objekt. Das Ergebnis wird zuruckgegeben.

• UpdateTariff : Ruft mit dem ubergebenen Tariff-Objekt die statische Me-thode UpdateTariff der Klasse TariffDAL auf und gibt deren Ergebniszuruck.

Tarife in der grafischen Oberflache In der GUI ist die Tarifverwaltunguber den Button Tarife im Hauptmenu zu erreichen. Das Tarif-Panel listet al-le vorhandenen Tarife in einer Ubersicht, geordnet nach Benutzungshaufigkeit,auf. Darunter befinden sich Buttons fur die entsprechenden Funktionen auf Ta-rifdaten (anlegen, andern, loschen, (de)aktivieren). Ein ausgewahlter Tarif kannuber den Button Tarif (de)aktivieren aktiviert bzw. deaktiviert werden. EinHaken in der Spalte Aktiv markiert aktive Tarife. In das Bearbeitungspanel,ein sich zusatzlich offnendes Fenster, gelangt man uber den Tarif anlegen- oderTarif bearbeiten-Button. Hier gibt man die neuen bzw. andert die vorhandenenWerte eines Tarifs. Nach Eingabe und Validierung der Werte wird von der GUIim Service Access Layer die Methode AddNewTariff zum Anlegen eines neuenTarifs bzw. UpdateTariff zum Bearbeiten eines vorhandenen Tarifs aufgerufenund dieser Aufruf uber den Webservice an den Server weitergeleitet.

Lastprofile im Datenzugriff Lastprofile werden in der Tabelle EnergyProfilegespeichert. Die Verbrauchswerte eines Lastprofils sind dabei als CSVs in einerZelle gespeichert, was zwar kein optimales Datenbanklayout darstellt, weil sokeine Normalform eingehalten wird, jedoch erheblichen Aufwand bei der Pro-grammierung erspart. Außerdem ist es unproblematisch, da CSVs einfach zuparsen sind und nirgendwo Nullwerte oder Redundanzen auftreten. Der Daten-zugriff wird uber die statische Klasse EnergyProfileDAL realisiert, die die bereitsim vorigen Abschnitt vorgestellten statischen Methoden bereitstellt:

• CreateEnergyProfileFromDataRow : Erstellt aus einer ausgelesenen Tabel-lenzeile ein neues EnergyProfile-Objekt und gibt dieses zuruck.

• InsertEnergyProfile: Fugt ein ubergebenes Lastprofil in die Datenbank einund zeigt uber einen ReturnCode den Erfolg der Aktion an.

72

Page 73: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 21: Klasse EnergyProfileDAL

• UpdateEnergyProfile: Aktualisiert ein in der Datenbank gespeichertes Last-profil anhand des ubergebenen EnergyProfile-Objekts und zeigt ubereinen ReturnCode den Erfolg der Aktion an.

• DeleteEnergyProfile: Loscht ein in der Datenbank gespeichertes Lastprofilmit einer bestimmten GUID und zeigt uber einen ReturnCode den Erfolgder Aktion an.

• IsEnergyProfileUsed : Uberpruft, ob ein Lastprofil noch von Kundenver-tragen benutzt wird, und gibt das Ergebnis als booleschen Wert zuruck.

• GetEnergyProfile: Liest ein Lastprofil mit einer ubergebenen GUID aus derDatenbank aus und gibt es zuruck.

• GetEnergyProfileByName: Liest Lastprofile, deren Namen einen uberge-benen String enthalten, aus der Datenbank aus und liefert sie als Listezuruck.

• GetRankedEnergyProfile: Liest alle Lastprofile geordnet nach Einsatzhau-figkeit aus der Datenbank aus und liefert sie als Liste zuruck.

• GetAllEnergyProfiles: Liest alle Lastprofile aus der Datenbank aus undliefert sie als Liste zuruck.

Lastprofile in der Geschaftslogik In der Geschaftslogikschicht existiert diestatische Klasse EnergyProfileManager zum Umgang mit Lastprofilen. Da aberkeinerlei Algorithmen auf den Lastprofilen ausgefuhrt werden mussen, erfolgtlediglich ein Zugriff auf die passenden Methoden der darunterliegenden Daten-haltungsschicht, deren Ergebnisse weitergeleitet und vom Webservice, der dieMethoden dieser Klasse aufruft, als Ruckgabewerte verwendet werden.

• AddNewEnergyProfile: Ruft mit dem ubergebenen EnergyProfile-Objektdie statische Methode InsertEnergyProfile der Klasse EnergyProfileDALauf und gibt deren Ergebnis zuruck.

73

Page 74: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 22: Klasse EnergyProfileManager

• UpdateEnergyProfile: Ruft mit dem ubergebenen EnergyProfile-Objektdie statische Methode UpdateEnergyProfile der Klasse EnergyProfileDALauf und gibt deren Ergebnis zuruck.

• DeleteEnergyProfile: Ruft mit der ubergebenen ID die statische Metho-de DeleteEnergyProfile der Klasse EnergyProfileDAL auf und gibt derenErgebnis zuruck.

• IsEnergyProfileUsed : Ruft mit dem ubergebenen EnergyProfile-Objektdie statische Methode IsEnergyProfileUsed der Klasse EnergyProfileDALauf und gibt deren Ergebnis zuruck.

• GetEnergyProfile: Ruft mit dem ubergebenen EnergyProfile-Objekt diestatische Methode InsertEnergyProfile der Klasse EnergyProfileDAL aufund gibt deren Ergebnis zuruck.

• GetEnergyProfileByName: Ruft mit dem ubergebenen String die statischeMethode GetEnergyProfileByName der Klasse EnergyProfileDAL auf undgibt deren Ergebnis zuruck.

• GetAllEnergyProfiles: Ruft die statische Methode GetAllEnergyProfilesder Klasse EnergyProfileDAL auf, wandelt deren Ergebnis (eine Liste mitEnergyProfile-Objekten) in ein Array um und gibt dies zuruck.

Lastprofile in der grafischen Oberflache Die grafische Oberflache derLastprofile ist relativ einfach aufgebaut und besteht nur aus zwei Elementen:

• dem Ubersichtsfenster, das die vorhandenen Lastprofile auflistet und denZugriff auf die verschiedenen Operationen fur Lastprofile (anlegen, bear-beiten, loschen) bereitstellt und auch eine Suchfunktion bietet, die nachbestimmten Lastprofilnamen sucht, und

• dem Eingabefenster, das erscheint, wenn ein neues Lastprofil erstellt oderein im Ubersichtsfenster ausgewahltes geandert werden soll. Nach der Ein-gabe und Validierung von Werten wird durch Klick auf den Button Spei-chern die Funktion AddNewEnergyProfile aus dem Service Access Layer

74

Page 75: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 23: Hauptfenster der Lastprofilverwaltung

aufgerufen, die das erzeugte Lastprofil uber den Webservice zum Einfugenin die Datenbank an den Server weiterreicht (analog beim Bearbeiten dieMethode UpdateEnergyProfile).

Beide Oberflachen sind als Windows Forms angelegt, wobei das Ubersichtsfens-ter in das Hauptfenster und das Eingabefenster als abhangiges Pop-Up geladenwird.

5.1.3 Stromlieferanten, Lieferangebote und -vertrage

Allgemeines Ein Stromlieferant ist ein elementarer Bestandteil der Logik desProgramms. Er beliefert einen Stromhandler mit der benotigten Energie, welcheer mit seinen verschiedenen Kraftwerken (z.B. Atom-, Kohle-, Wind-, Wasser-kraftwerke) produziert. Ein Lieferant kann einem Handler ein Lieferangebot furStrom unterbreiten. Der Handler kann, wenn ihm die Bedingungen des Angebo-tes zusagen, dieses Angebot annehmen, sodass zwischen den beteiligten Parteienein Vertrag geschlossen wird. Der Vertragsschluss wird durch Anderung des Fel-des Signed auf true gespeichert.

Die Klasse SupplierContract speichert samtliche Details zu den einzelnenAngeboten und Vertragen. Da gerade bei Ubertragung von vielen Vertragen hiergroße Datenmengen zusammen kommen, konnen auch SupplierContractInfo-Objekte ubertragen werden, die nur die fur Ubersichten notwendigen Datenenthalten. Somit wird die Datenmenge und die Ubertragungsdauer reduziert.Die im Folgenden beschriebenen Funktionen decken die Anwendungsfalle 34 bis46 des Entwurfs ab. Anwendungsfall 37 wurde dahingehend modifiziert, dassBilanzkreise und Regelzonen nun nicht mehr je Lieferant erfasst werden, sondernje Liefervertrag.

Als Datenbasis wurden fur den Testbetrieb etliche Lieferanten und mehrerehundert, meist langerfristige Liefervertrage im Megawattbereich in die Daten-bank eingefugt, die zusammen mit den Kundenvertragen eine fur einen kleine-ren Stromhandler oder Energieversorger – etwa ein Stadtwerk, das ohne eigene

75

Page 76: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 24: Eingabefenster fur Lastprofile

Kraftwerke eine kleine Großstadt wie Oldenburg versorgen muss – eine realisti-sche Situation ergibt.

Lieferanten, Lieferangebote und -vertrage in der Datenbank In derDatenbank existieren die Tabellen Supplier fur die Lieferantendaten und Sup-plierContracts fur die Lieferangebote und -vertrage. Sie bilden die jeweiligenObjekte ab.

Lieferanten, Lieferangebote und -vertrage im Datenzugriff Der Daten-zugriff wird uber die statischen Klassen SupplierDAL und SupplierContractDALrealisiert. Die nachfolgend vorgestellten Methoden werden von Funktionen derKlassen SupplierManager.cs und SupplierContractManager.cs aufgerufen:

• CountSuppliers: Gibt die Zahl der in der Datenbank gespeicherten Liefe-ranten zuruck.

• CreateSupplierFromDataRow: Erzeugt aus dem ubergebenen DataRow-Ob-jekt ein Supplier-Objekt und gibt dieses zuruck.

• DeleteSupplier: Loscht den durch die ubergebene GUID eindeutig identi-fizierten Lieferanten aus der Datenbank und zeigt uber einen booleschenWert den Erfolg der Aktion an.

76

Page 77: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 25: Lieferant

• GetAllSuppliers: Liest alle Lieferanten aus der Datenbank aus und liefertdiese als generische Liste zuruck.

• GetSupplier: Liest den durch die ubergebene GUID identifizierten Lieferan-ten aus und gibt ihn zuruck.

• GetSuppliersByCity: Liest alle Lieferanten, deren Firmensitz den uberge-benen Wert enthalt, aus und gibt diese als generische Liste zuruck.

• GetSuppliersByCompany: Liest alle Lieferanten, deren Firmenname denubergebenen Wert enthalt, aus und gibt diese als generische Liste zuruck.

• GetSuppliersByEmail: Liest alle Lieferanten, deren Emailadresse den uber-gebenen Wert enthalt, aus und gibt diese als generische Liste zuruck.

• GetSuppliersByFax: Liest alle Lieferanten, deren Faxnummer den uberge-benen Wert enthalt, aus und gibt diese als generische Liste zuruck.

• GetSuppliersByLastName: Liest alle Lieferanten, deren Ansprechpartnerim Nachnamen den ubergebenen Wert enthalten, aus und gibt diese alsgenerische Liste zuruck.

• GetSuppliersByFon: Liest alle Lieferanten, deren Telefonnummer den uber-gebenen Wert enthalt, aus und gibt diese als generische Liste zuruck.

• GetSuppliersBySupplierId: Liest alle Lieferanten, deren ID den ubergebe-nen Wert enthalt, aus und gibt diese als generische Liste zuruck.

• HasSupplierContracts: Gibt an, ob ein Lieferant noch uber Liefervertrageverfugt. Der Lieferant kann als Supplier-Objekt ubergeben oder durcheine GUID identifiziert werden.

77

Page 78: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 26: Lieferangebot und -vertrag

• InsertSupplier: Fugt einen neuen Lieranten in die Datenbank ein und zeigtuber einen booleschen Wert den Erfolg der Aktion an.

• UpdateSupplier: Aktualisiert einen Datenbankeintrag auf die Werte desubergebenen Supplier-Objektes und zeigt uber einen booleschen Wertden Erfolg der Aktion an.

• CountSupplierContracs: Liefert die Anzahl an vorhandenen Lieferangebo-ten und -vertragen zuruck.

• CreateSupplierContractFromDataRow: Erstellt ein neues Lieferangebot bzw.einen neuen Liefervertrag aus dem ubergebenenDataRow-Objekt.

• CreateSupplierContractInfoFromDataRow: Erstellt ein neuesSupplierContractInfo-Objekt aus dem ubergebenen DataRow-Objekt.

• DeleteSupplierContract: Loscht ein Angebot oder einen Vertrag aus derDatenbank, dessen ID dieser Funktion ubergeben wird. Der Erfolg derAktion wird uber den zuruck gegebenen booleschen Wert angezeigt.

• GetAllSupplierContracts: Liefert alle in der DB gespeicherten Lieferange-bote und -vertrage als generische Liste zuruck.

• GetDemandCoverageInPercent: Liefert die Abdeckung des Energiebedarfsin Prozent zum aktuellen Zeitpunkt zuruck. Dabei werden die Kunden-vertrage als Grundlage genommen, falls fur den aktuellen Zeitpunkt keineLastprognose vorhanden ist. Andernfalls wird die zuletzt erzeugte Last-prognose, die zum aktuellen Zeitpunkt gilt, genommen.

78

Page 79: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 27: Lieferanten im Datenzugriff

• GetExpiringSupplierContracts: Liefert eine generische Liste aller Vertragezuruck, die bis zum ubergebenen Zeitpunkt ablaufen und vom ubergebenenNutzer betreut werden.

• GetSupplierContract: Liefert einen bestimmten Liefervertrag oder -angebotfur eine ubergebene ID zuruck.

• GetSupplierContractInfoByDate: Liefert alle im ubergebenen Zeitraum gul-tigen Liefervertrage und -angebote als Liste von Info-Objekten zuruck.

• GetSupplierContractInfoForRecommendation: Liefert alle im Zeitraum derubergebenen Kaufempfehlung gultigen Lieferangebote als Info-Objekte zu-ruck.

• GetSupplierContractsByCompany: Liefert alle Lieferangebote und -vertrage,deren Lieferantennamen den ubergebenen Wert enthalt, zuruck.

• GetSupplierContractsForRecommendation: Liefert alle im Zeitraum derubergebenen Kaufempfehlung gultigen Lieferangebot zuruck.

• GetSupplierContractsForSchedule: Liefert alle am ubergebenen Tag gulti-gen Liefervertrage zuruck.

• GetSupplierContractsForSupplier: Liefert alle Angebote und Vertrage furein ubergebenes Supplier -Objekt zuruck.

• GetSupply: Hilfsmethode fur GetSupplyCoverageInPercent. Berechnet diefur den ubergebenen Tag vereinbarte zu liefernde Energiemenge und gibtdiese zuruck.

• HasDisturbances: Uberpruft fur einen ubergebenen Vertrag bzw. fur einubergebenes Angebot, ob Storungen vorliegen. Falls aktuell Storungen auf-getreten sind, wird true zuruck gegeben, false sonst.

79

Page 80: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• InsertSupplierContract: Fugt einen neuen Liefervertrag oder ein neues Lie-ferangebot in die Datenbank ein. Ein entsprechendes SupplierContract-Objekt wird dieser Funktion ubergeben.

• UpdateSupplierContract: Aktualisiert einen ubergebenen Vertrag oder einubergebenes Angebot in der Datenbank und liefert true zuruck, falls dieAktualisierung erfolgreich war, false sonst.

Lieferanten, Lieferangebote und -vertrage in der Geschaftslogik DieGeschaftslogik stellt die Klassen SupplierManager.cs undSupplierContractManager.cs zur Verfugung. In diesen Klassen sind alle gul-tigen Funktionen definiert, die auf Lieferanten, Lieferangeboten und -vertragen,ausgefuhrt werden konnen. Jeder in dieser Klasse definierten Funktion ist ei-ne entsprechende ausfuhrende Funktion in der Datenzugriffsschicht zugeordnet,welche von hier aus aufgerufen wird. Das Ergebnis des Datenzugriffs wird zu-ruckgegeben. Sofern die Funktionsnamen im Datenzugriff von denen der Ge-schaftslogik abweichen oder weitere Prufungen oder Berechnungen durchgefuhrtwerden, sind die Zuordnungen aufgefuhrt.

Abbildung 28: Lieferanten in der Geschaftslogik

• AddNewSupplier: Ruft InsertSupplier auf.

• DeleteSupplier: Pruft zunachst, ob ein Lieferant noch laufende Vertragehat. Ist dies der Fall, darf er nicht geloscht werden und es wird IsUsedzuruck gegeben. Ansonsten wird die Funktion DeleteSupplier aufgerufenund deren Ergebnis als OK fur true bzw. Error fur false zuruck gegeben.

• UpdateSupplier: Pruft zunachst, ob der zu aktualisierende Eintrag nochin der Datenbank vorhanden ist und ruft bei Erfolg UpdateSupplier auf.Mogliche Ruckgabewerte sind NotFound, OK, Error und DBFailure.

• DeleteSupplierContract: Pruft vor dem eigentlichen Loschen, ob der Ver-trag noch in der Datenbank existiert, ob er gerade bedient wird und

80

Page 81: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

ob Storungen existieren. Anschließend wird DeleteSupplierContract auf-gerufen. Mogliche Ruckgabewerte sind NotFound, IsCurrentlyServed,HasDisturbances, OK, Error und DBFailure.

Lieferanten in der grafischen Oberflache Die Ubersicht uber die Liefe-ranten eines Handlers wird in der GUI durch Anklicken des Buttons Lieferantenoder den entsprechenden Menupunkt erreicht. Der Systemnutzer sieht nun ei-ne nach Lieferantennummern geordnete Liste. Standardmaßig werden in diesemMenupunkt alle Lieferanten des Handlers angezeigt, da die Liste der Lieferantenim Gegensatz zu der Liste der Kunden uberschaubar ist. Weitere Felder nebenden Lieferantennummern sind deren Firmenname, Straße, Hausnummer, Post-leitzahl, Ort, Kontonummer, Bankleitzahl, Telefon- und Faxnummer, Anrede,Vorname, Nachname und E-Mail-Adresse.

Um nun nach bestimmten Lieferanten suchen zu konnen, bietet das Sys-tem dem Nutzer eine Suchfunktion an, mittels welcher er nach Lieferanten-nummer, Firmenname, Ort, Nachname, Telefonnummer, Telefaxnummer oderE-Mail-Adresse suchen kann. Zusatzlich hat der Nutzer auch die Moglichkeit,nach der speziellen Suche die Liste aller Lieferanten zuruck zu erhalten, indemer auf den Button Alle Anzeigen druckt.

Unter dem Datenfeld, welches die Lieferanten anzeigt, sind drei weitere But-tons angeordnet. Diese sind zum Hinzufugen neuer Lieferanten, Bearbeiten oderLoschen bestehender Lieferanten vorgesehen und tragen die Aufschriften Liefe-rant anlegen, Lieferant bearbeiten, Lieferant loschen.

In einem weiteren Datenfeld, welches sich unter der Lieferantenanzeige befin-det, werden die zu einem Lieferanten gehorenden Lieferangebote und Lieferver-trage angezeigt. Dieses Datenfeld ist gefullt mit Werten fur die Attribute Bear-beiter, Bilanzkreis, Regelzone, Startdatum, Enddatum, Menge (MWh/h), Preis(Euro/MWh) und Abgeschlossen. Abgeschlossen bezeichnet hiebei den Statuseines Angebotes. Ist das jeweilige Feld mit einem Hakchen gekennzeichnet, soist das Angebot bereits ein Vertrag.

Auch zu diesem Datenfeld gibt es Buttons, mit denen bestimmte Aktio-nen durchgefuhrt werden konnen. Diese sind das Hinzufugen eines neuen An-gebotes oder Vertrages, das Bearbeiten eines Angebotes oder Vertrages unddas Loschen eines Angebotes oder Vertrages. Die Namen dieser Buttons lautenLieferantangebot/-vertrag eingeben, Lieferantangebot/-vertrag bearbeitenund Lieferantangebot/-vertrag loschen.

5.1.4 Bilanzkreise und Regelzonen

Allgemeines Ein Bilanzkreis stellt den Verantwortungsbereich eines Strom-handlers dar, in dem dieser fur ausgeglichene Ein- und Verkauf von Energieverantwortlich ist. Ein Bilanzkreis kann sich uber mehrere Regelzonen erstre-cken. Bei der Erfullung von Liefervertragen wird Strom aus einem Bilanzkreisin einen anderen gefuhrt. Fur jeden Bilanzkreis wird der Name des Unterneh-mens, eine Abkurzung und der ETSO Identification Code (EIC) gespeichert.Ein Bilanzkreis wird im EIC durch ein X an der dritten Stelle des EIC gekenn-zeichnet.

81

Page 82: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Regelzonen stellen den Verantwortungsbereich der einzelnen Ubertragungs-netzbetreiber (UNB) dar, innerhalb dessen sie fur ausgeglichene Einspeisungund Entnahme von Energie verantwortlich sind. Die Regelzone ist dabei iden-tisch mit dem physikalischen Stromnetz, dass der UNB betreibt. Wie auch furBilanzkreise werden Name des Unternehmens, Abkurzung 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 Re-gelzone gespeichert, um die fur den ordnungsgemaßen Netzbetrieb notwendigenEnergiefahrplane erstellen zu konnen.

Die Verwaltung von Bilanzkreisen und Regelzonen deckt die Anwendungs-falle 28 bis 33 des Entwurfs ab.

Bilanzkreise und Regelzonen in der Datenbank Fur Bilanzkreise undRegelzonen existiert je eine Tabelle (AccountingArea und ControlArea) in derDatenbank. Sie bilden die gleichnamigen Objekte eins zu eins ab.

Bilanzkreise und Regelzonen im Datenzugriff

• AccountingAreaReferenced: Pruft, ob in einer der Tabellen, die auf dieAccountingArea-Tabelle verweisen, ein Verweis auf die ubergebene ID exis-tiert und gibt true zuruck, falls ein Verweis existiert, false sonst.

• CreateAccountingAreaFromDataRow: Erstellt ein AccountingArea-Objektaus dem ubergebenen DataRow-Objekt.

• DeleteAccountingArea: Loscht das mittels der ubergebenen ID eindeutigidentifizierte AccountingArea-Objekt aus der Datenbank.

• GetAccountingArea: Liefert den Bilanzkreis zuruck, der zur ubergegebenenID gehort.

• GetAccountingAreaByAbbreviation: Liefert alle Bilanzkreise zuruck, derenAbkurzung die ubergebene Zeichenfolge enthalt.

82

Page 83: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 30: Datenzugriff auf Bilanzkreise und Regelzonen

• GetAccountingAreaByEIC: Liefert alle Bilanzkreise zuruck, deren EIC dieubergebene Zeichenfolge enthalt.

• GetAccountingAreaByOwner: Liefert alle Bilanzkreise zuruck, deren Ei-gentumer die ubergebene Zeichenfolge enthalt.

• GetAllAccountingAreas: Liefert alle Bilanzkreise aus der Datenbank zu-ruck.

• GetDatabase: Gibt die verwendete Datenbankverbindung zuruck. DieseFunktion wird fur das Massen-Update benotigt, da hier durch die Transak-tionsmechanismen dieselbe Verbindung fur alle Anfragen benutzt werdenmuss.

• GetMarkedAccountingAreas: Liefert alle Bilanzkreise zuruck, deren Deleted-Feld auf true gesetzt ist.

• InsertAccountingArea: Fugt das ubergebene AccountingArea-Objekt in dieDatenbank ein.

• IsEICAvailable: Pruft, ob in der Datenbank bereits ein Eintrag mit demubergebenen EIC existiert. Gibt true zuruck, falls kein Eintrag existiert,false sonst.

• MarkAccountingAreaAsDeleted: Setzt fur das durch die ubergebene ID ein-deutig identifizierte AccountingArea-Objekt das Feld Deleted auf true.

• UpdateAccountingArea: Aktualisiert den Datenbankeintrag fur das uber-gebene AccountingArea-Objekt mit dessen Daten.

83

Page 84: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• ControlAreaReferenced: Pruft, ob in einer der Tabellen, die auf die Cont-rolArea-Tabelle verweisen, ein Verweis auf die ubergebene ID existiert undgibt true zuruck, falls ein Verweis existiert, false sonst.

• CreateControlAreaFromDataRow: Erstellt ein ControlArea-Objekt aus demubergebenen DataRow-Objekt.

• DeleteControlArea: Loscht das mittels der ubergebenen ID eindeutig iden-tifizierte ControlArea-Objekt aus der Datenbank.

• GetAllControlAreas: Liefert alle Regelzonen aus der Datenbank zuruck.

• GetControlArea: Liefert die Regelzone zuruck, die zur ubergegebenen IDgehort.

• GetControlAreaByAbbreviation: Liefert alle Regelzonen zuruck, deren Ab-kurzung die ubergebene Zeichenfolge enthalt.

• GetControlAreaByEIC: Liefert alle Regelzonen zuruck, deren EIC die uber-gebene Zeichenfolge enthalt.

• GetControlAreaByOwner: Liefert alle Regelzonen zuruck, deren Eigentu-mer die ubergebene Zeichenfolge enthalt.

• GetMarkedControlAreas: Liefert alle Regelzonen zuruck, deren Deleted-Feld auf true gesetzt ist.

• InsertControlArea: Fugt das ubergebene ControlArea-Objekt in die Da-tenbank ein.

• IsEICAvailable: Pruft, ob in der Datenbank bereits ein Eintrag mit demubergebenen EIC existiert. Gibt true zuruck, falls kein Eintrag existiert,false sonst.

• MarkControlAreaAsDeleted: Setzt fur das durch die ubergebene ID ein-deutig identifizierte ControlArea-Objekt das Feld Deleted auf true.

• UpdateControlArea: Aktualisiert den Datenbankeintrag fur das ubergebe-ne ControlArea-Objekt mit dessen Daten.

Bilanzkreise und Regelzonen in der Geschaftslogik Die Geschaftslogikstellt durch die Klassen AccountingAreaManager.cs undControlAreaManager.cs alle fur den Client verfugbaren Methoden bereit, uberdie auf Bilanzkreise und Regelzonen zugegriffen werden kann. Die meisten die-ser Funktionen rufen die gleichnamigen Funktionen der jeweiligen Datenzugriffs-klassen auf; alle Methoden, die weitere Berechnungen durchfuhren, werden imFolgenden erlautert.

• AreaBulkUpdate: Der ubergebene Array enthalt in jeder Zeile eine Regel-zone oder einen Bilanzkreis. Zusammen sind das alle aktuell gultigen Ein-trage, die laut VDN Berlin vorhanden sind. Innerhalb einer Transaktionwird nun jeder String abgearbeitet. Zunachst werden Listen aller bislang

84

Page 85: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 31: Bilanzkreise und Regelzonen in der Geschaftslogik

bekannten Bilanzkreise und Regelzonen aus der Datenbank durch Auf-ruf von GetAllAccountingAreas und GetAllControlAreas des Datenzugriffsgeladen und mit dem ubergebenen Array verglichen. Weicht ein Listenein-trag von der entsprechenden Zeile (identifiziert uber den EIC) ab, wird derListeneintrag aktualisiert und die Anderung durch Aufruf von UpdateAc-countingArea bzw. UpdateControlArea an die Datenbank gemeldet. Jedesverglichene Element wird aus seiner Liste – nicht der Datenbank – ent-fernt.Existiert zu einer Zeile des Arrays kein Eintrag in den Listen, wird einentsprechender neuer Eintrag durch Aufruf der statischen Methode Inser-tAccountingArea bzw. InsertControlArea erzeugt. Sobald nun der gesamteArray abgearbeitet wurde, stehen in den beiden Listen nur noch die Regel-zonen und Bilanzkreise, die zwar in der Datenbank, aber nicht im Arrayenthalten sind. Sie werden somit geloscht oder, falls noch Referenzen aufsie existieren, als geloscht markiert.Sind alle Datenbankoperationen ohne Fehler abgeschlossen, wird die Trans-aktion ebenfalls geschlossen und die Anderungen somit in die Produktiv-daten ubernommen. Es wird OK zuruckgegeben. Hat eine DB-Operationeinen Fehler produziert, wird die Transaktion abgebrochen, samtliche An-derungen verworfen und Error zuruckgegeben. Wurde eine Exception ge-worfen, wird sie gefangen, die Transaktion abgebrochen und DBFailurezuruckgegeben.

• bulkDeleteAccountingArea: Hilfsmethode fur AreaBulkUpdate. Loscht alleubergebenen Bilanzkreise aus der Datenbank.

85

Page 86: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• bulkDeleteControlArea: Hilfsmethode fur AreaBulkUpdate. Loscht alle uber-gebenen Regelzonen aus der Datenbank.

• DeleteAccountingArea: Pruft zunachst, ob der zu loschende Bilanzkreisnoch in der Datenbank existiert und ob keinerlei Referenzen auf diesenexistieren. Sind diese Prufungen erfolgreich, wird der Bilanzkreis aus derDatenbank geloscht. Mogliche Ruckgabewerte sind NotFound, IsUsed, OK,Error und DBFailure.

• MarkAccountingAreaAsDeleted: Pruft zunachst, ob der zu andernde Bi-lanzkreis noch in der Datenbank existiert und markiert diesen im Erfolgs-fall als geloscht. Mogliche Ruckgabewerte sind NotFound, OK, Error undDBFailure.

• processAccountingArea: Hilfsfunktion fur AreaBulkUpdate. Bearbeitet einenals Bilanzkreis identifizierten String und fuhrt die notigen Updates ausoder erzeugt einen neuen Datenbankeintrag.

• processControlArea: Hilfsfunktion fur AreaBulkUpdate. Bearbeitet einenals Regelzone identifizierten String und fuhrt die notigen Updates aus odererzeugt einen neuen Datenbankeintrag.

• UpdateAccountingArea: Pruft zunachst, ob der zu andernde Bilanzkreisnoch in der Datenbank existiert und fuhrt im Erfolgsfall die Anderungaus. Mogliche Ruckgabewerte sind NotFound, OK, Error und DBFailure.

• DeleteControlArea: Pruft zunachst, ob die zu loschende Regelzone noch inder Datenbank existiert und ob keinerlei Referenzen auf diese existieren.Sind diese Prufungen erfolgreich, wird die Regelzone aus der Datenbankgeloscht. Mogliche Ruckgabewerte sind NotFound, IsUsed, OK, Error undDBFailure.

• MarkControlAreaAsDeleted: Pruft zunachst, ob die zu andernde Regelzonenoch in der Datenbank existiert und markiert sie im Erfolgsfall als geloscht.Mogliche Ruckgabewerte sind NotFound, OK, Error und DBFailure.

• UpdateControlArea: Pruft zunachst, ob die zu andernde Regelzone nochin der Datenbank existiert und fuhrt im Erfolgsfall die Anderung aus.Mogliche Ruckgabewerte sind NotFound, OK, Error und DBFailure.

Bilanzkreise und Regelzonen in der grafischen Oberflache Da Bilanz-kreise und Regelzonen von der Datenhaltung her nahezu identisch sind, wurdenihre Verwaltungsfunktionen in einem gemeinsamen Panel zusammen gefasst.Es ist in der GUI uber den Menupunkt ”Bilanzierung” im Hauptmenu oderden entsprechenden Button links zu erreichen. Das Verwaltungspanel (KlassePanelSearchArea.cs) ist in das Hauptfenster integriert und listet zunachst alleBilanzkreise in einer Ubersicht auf. Der Anzeigemodus kann beliebig von Bilanz-kreisen zu Regelzonen und zuruck gewechselt werden; eine Suchfunktion dientzur Eingrenzung der Anzeige. Unterhalb der Ubersicht finden sich Buttons furdie Funktionen Anlegen, Andern und Loschen.

86

Page 87: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 32: Ubersicht der vorhandenen Bilanzkreise

In das Bearbeitungspanel (Klasse PanelAddArea.cs) gelangt man uber einenKlick auf die Buttons Bilanzkreis (Regelzone) anlegen bzw. Bilanzkreis (Regel-zone) andern. Im sich offnenden Popup-Fenster gibt man die neuen Daten einbzw. andert die vorhandenen Daten.

Abbildung 33: Bearbeiten-Fenster fur einen Bilanzkreis

Soll ein Bilanzkreis oder eine Regelzone geloscht werden, wird zunachst ge-pruft, ob noch irgendwo Referenzen darauf existieren. Falls ja, wird nur eineGeloscht-Attribut gesetzt; dadurch konnen keine weiteren Referenzen auf dasObjekt angelegt werden. Falls nein, werden die Informationen aus der Daten-bank geloscht. In der Ubersicht werden als geloscht markierte Bilanzkreise undRegelzone grau dargestellt.

87

Page 88: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Uber den Button Massen-Update konnen berechtigte Nutzer eine CSV-Dateiim Format Unternehmen;Abkurzung;EIC auswahlen. Diese Datei wird an denServer ubertragen und bringt die Datenbestande fur Bilanzkreise und Regelzoneauf den Stand der Datei. Eine aktuelle Liste mit gultigen EICs ist beispielsweiseunter [EIC06] als Excel-Datei verfugbar. Nach dem Export in das vorgegebeneFormat kann diese Datei vom EIS verarbeitet.

5.2 EEX-Handel

Die (langfristigen) Liefervertrage reichen nicht immer fur eine (nahezu) exakteDeckung des Strombedarfs der zu versorgenden Kunden aus. Laut Vorgabendurfen die in Fahrplanen angegebenen Mengen maximal funf Prozent nach obenoder unten von der tatsachlich verbrauchten Menge abweichen. Zudem kann esdurch Storungen seitens der Stromanbieter zu kurzfristigen Versorgungsengpas-sen kommen. Um solche Probleme in den Griff zu bekommen und weil Stromim Zuge der Liberalisierung des Energiemarktes zunehmend an Energieborsengehandelt wird, bietet das Energieinformationssystem auch die Moglichkeit, An-gebote zum Kauf oder Verkauf von Strom zu erstellen, die direkt an der Euro-paischen Energieborse EEX in Leipzig abgegeben werden konnen.

EEX-Handel in der grafischen Oberflache Der gesamte Handel mit derEEX wurde zwecks besserer Ubersicht in einem Panel zusammengefasst. Linksuber der Navigationsleiste wird bei Aufruf des Panels eine Tabelle mit den aktu-ellen Marktdaten eingeblendet (siehe 5.2.4). Das eigentliche Panel ist dreigeteilt(siehe Abbildung 34). Oben wird eine Liste mit Lastprognosen angezeigt, dieam aktuellen Tag gelten. Bei Auswahl einer dieser Lastprognosen wird rechtsdaneben ein Graph mit Hilfe der ZedGraph-Bibliothek berechnet, der die Uber-bzw. Unterdeckung fur den folgenden Tag, das heißt, um wieviel mit den ak-tuellen Liefervertragen und EEX-Lieferungen sowie Storungen der durch dieKundenvertrage anfallende Energiebedarf uber- oder unterschritten wird.

Die Berechnung der Uberdeckung wird wie auch alle anderen kompliziertenAlgorithmen in der serverseitigen Geschaftslogik statt (Klasse EexManager). Da-zu existiert in der Datenzugriffsschicht die Methode subtractContractFromEner-gyPrediction, die als Argument unter anderem die ausgewahlte Lastprognoseubergeben bekommt. Zunachst werden alle Liefervertrage und EEX-Lieferungenermittelt, die am fraglichen Tag gelten. Danach werden die darin genanntenMengen fur die einzelnen Zeitintervalle von den in der Lastprognose genanntenVerbrauchswerten subtrahiert, wobei die in Liefervertragen genannten Mengennur abzuglich eventueller Storungen betrachtet werden. Allerdings geschieht die-se Berechnung nur fur jedes vierte Viertelstundenintervall, so dass in der Metho-de computeGraphPoints, die die im Graphen anzuzeigenden Werte zuruckliefert,nur ein Wert pro Stunde berechnet wird. Dies geschieht, damit der Graph, dernur sehr begrenzten Platz zur Verfugung hat, ubersichtlich bleibt, und um dieRechenzeit, die sich als zu lang erwies, zu reduzieren.

Unter dem Graphen finden sich zwei Ubersichten, in denen zum einen allebestehenden EEX-Stundenganbote und zum anderen alle bestehenden EEX-Blockangebote mit den wichtigsten Parametern angezeigt werden. Bei Klick aufden Anlegen-Button wird jeweils ein Fenster geoffnet, in das ein neues Angebot

88

Page 89: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 34: Panel fur EEX-Handel

eingegeben werden kann. Der Bearbeiten-Button offnet das gleiche Fenster, je-doch mit den Daten des ausgewahlten Angebots befullt. Ein Klick auf Lieferungoffnet einen Dialog zur Eingabe einer EEX-Lieferung auf Basis des ausgewahltenAngebots.

Ganz unten schließlich befinden sich Anzeigen fur die EEX-Zugangsdatendes angemeldeten Nutzers, die er uber einen Klick auf Daten andern bearbeitenkann. Sollte noch kein EEX-Konto im System gespeichert sein, wird er beim Auf-ruf dieses Panels gebeten, eines anzulegen, weil ohne EEX-Zugangsdaten keineAngebote verfasst werden konnen. Uberpruft werden die eingegebenen Datenallerdings nicht, da es keine Schnittstelle zum Datenbestand der Energieborsegibt.

Die EEX-Funktionalitaten decken die Anwendungsfalle 72 bis 84 sowie 63des Entwurfs ab.

5.2.1 Zugangsdaten zur Energieborse

Damit an der EEX gehandelt werden kann, mussen die Nutzer, die dies tunwollen, sich durch spezielle Zugangsdaten, namlich einen eindeutigen Handler-namen und eine zugehorige ID, ausweisen. Dieser Zusammenhang wird in derKlasse EexAccount verwirklicht, wobei jedem Systemnutzer maximal ein solcherZugang gewahrt wird (siehe Abbildung 35

89

Page 90: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 35: Klasse EexAccount

EEX-Zugangsdaten im Datenzugriff Es existiert eine Datenbanktabellenamens EexAccount, in der die in der gleichnamigen Klasse vorhandenen Attri-bute gespeichert werden und eine Fremdschlusselbeziehung zum Systemnutzer,dem diese Zugangsdaten gehoren, besteht.

Abbildung 36: Klasse EexAccountDAL

In der Klasse EexAccountDAL (siehe Abbildung 36 werden folgende Metho-den zum Zugriff auf die Datenbank bereit:

• GetEexAccount: Liefert zu einer gegebenen ID ein bestimmtes aus derDatenbank ausgelesenes EexAccount-Objekt zuruck.

• InsertEexAccount: Fugt neue EEX-Zugangsdaten fur einen Benutzer in dieDatenbank ein.

• UpdateEexAccount: Aktualisiert die vorhandenen EEX-Zugangsdaten ei-nes Nutzers in der Datenbank.

• DeleteEexHourBid: Loscht die EEX-Zugangsdaten eines Nutzers mit einerbestimmten ID aus der Datenbank.

• CreateEexAccountFromDataRow: Erzeugt aus einer aus der TabelleEexAccount ausgelesenen Zeile einen Satz an Zugangsdaten fur einen Be-nutzer.

90

Page 91: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

EEX-Zugangsdaten in der Geschaftslogik Die Geschaftslogik fur EEX-Zugangsdaten beschrankt sich auf das Delegieren der Anfragen des Webservicesan die Datenhaltungsschicht, da keinerlei Berechnungen auszufuhren sind. Fol-gende Methoden in der Klasse EexManager (siehe Abbildung 46) kummern sichdarum und werden bei Clientanfragen vom Webservice aufgerufen:

• GetEexAccount: Ruft die gleichnamige Methode aus der Datenzugriffs-schicht auf und liefert deren Ergebnis zuruck.

• AddNewEexAccount: Ruft die gleichnamige Methode aus der Datenzu-griffsschicht auf und liefert deren Ergebnis zuruck.

• UpdateEexAccount: Ruft die gleichnamige Methode aus der Datenzugriffs-schicht auf und liefert deren Ergebnis zuruck.

• DeleteEexHourBid: Ruft die gleichnamige Methode aus der Datenzugriffs-schicht auf und liefert deren Ergebnis zuruck.

EEX-Zugangsdaten in der grafischen Oberflache In der GUI nehmenEEX-Zugangsdaten nur wenig Raum ein. Im unteren Teil des EEX-Panels wer-den die aktuellen Zugangsdaten des angemeldeten Nutzers angezeigt, und beiAnklicken der Schaltflache Daten andern offnet sich ein neues Fenster zur Einga-be eines neuen Kontonamens und einer neuen Konto-ID (siehe Abbildung 37).Dieses Fenster erscheint auch, wenn noch keine EEX-Zugangsdaten angelegtwurden, da ansonsten keine Angebote abgegeben werden konnen. Bei Nichtein-gabe wird kein Zugriff auf die weiteren Funktionen gewahrt.

Abbildung 37: Eingabefenster fur EEX-Zugangsdaten

5.2.2 Abgabe und Bearbeitung von Angeboten

Es wurden wie im Entwurf vorgesehen zwei der vielen verschiedenen Angebots-typen, die an der EEX gehandelt werden, implementiert:

• Stundenangebote

• Blockangebote

Beide Angebotstypen dienen in der Regel zur kurzfristigen Beschaffung kleine-rer Energiemengen bis 250 MWh und konnen somit die oben genannten Proble-me, die Nutzern unseres Systems durch Storungen langerfristiger Vertrage oder

91

Page 92: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

andere Grunde entstehen konnen, losen helfen. Andere, vorwiegend zu speku-lativen Zwecken eingesetzte Moglichkeiten wie etwa Terminhandel wurden auszeitlichen Aspekten, aber auch weil sie im Kontext eines Handlers, der Kundenmit realem Strom versorgt und nicht spekuliert, nicht aufgegriffen. Beide Ange-botstypen werden im folgenden naher erlautert. Ihnen gemein sind wesentlicheParameter wie die Laufzeit von genau einer Woche und die Moglichkeit, in die-ser Woche das Angebot nur an bestimmten Tagen gelten zu lassen. Außerdemkann jedes Angebot nachtraglich korrigiert werden und wird mit den Zugangs-daten des Nutzers, der es verfasst, versehen. Anders als normale Lieferangebotekonnen EEX-Angebote nicht zur Berechnung von Kaufempfehlungen herange-zogen werden, weil der Energiehandler, der sie abgegeben hat, nicht uber ihreAnnahme entscheidet.

Stundenangebote In einem Stundenangebot werden nun fur die einzelnenStunden eines Tages Energiemengen zwischen −250 und 250 MWh angegeben,wobei die Nummerierung der Stunden bei 1 (entspricht 0:00 bis 0:59 Uhr) be-ginnt und bei 24 (entspricht 23:00 bis 23:59 Uhr) endet. Fur jede Stunde konnenbis zu 16 verschiedene Mengen zu selbst definierten Hochstkauf- oder Mindest-verkaufpreisen angegeben werden. Ein Kaufangebot besitzt dabei kein oder einpositives Vorzeichen bei der Mengenangabe, ein Verkaufsangebot ein negatives.Zu jedem Stundenangebot muss daruber hinaus angegeben werden, fur welcheRegelzone es gedacht ist.

Abbildung 38: Klassen EexHourBid und EexHourBidDetails

Als abstrakter Datentyp wurden Stundenangebote wie in Abbildung 38 dar-gestellt implementiert. Es gibt dazu zwei Klassen, wobei die Klasse EexHourBiddie Rahmendaten beinhaltet sowie eine Liste von EexHourBidDetails-Objekten,in denen jeweils die fur eine Stunde zu den verschiedenen Preisen angegebenenMengen enthalten sind. Entsprechend wurden auch zwei gleichnamige Tabellen

92

Page 93: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

in der Datenbank angelegt, wobei die Tabelle EexHourBidDetails einen Fremd-schlussel in die Tabelle EexHourBid besitzt.

Blockangebote Blockangebote dagegen beziehen sich auf von der EEX vor-definierte Zeitblocke, in denen dann die ge- oder verkauften Mengen aus demjeweiligen Zielnetz geliefert oder dahin transferiert werden mussen, wozu furjedes der maximal 15 auf einem Formular anzugebenden Angebote eine eige-ne Regelzone genannt werden muss. Mit den Vorzeichen fur Kauf und Verkaufverhalt es sich hier genauso wie bei den Stundenangeboten.

Abbildung 39: Klassen EexBlockBid und EexBlockBidDetails

Wie bereits die Stundenangebote werden die Blockangebote auch durch zweiKlassen – EexBlockBid und EexBlockBidDetails – dargestellt (siehe Abbil-dung 39). Die erste Klasse enthalt wieder die Rahmeninformationen wie Angebots-ID, Zugangsdaten des Benutzers und die Woche, in der das Angebot gilt. Diezweite enthalt diesmal je eines der maximal 15 Teilgebote pro Instanz. Pro Teil-angebot muss eine Regelzone, eine Energiemenge, ein Hochstkauf- oder Mindest-verkaufspreis sowie ein Block angegeben werden. In der Datenbank ergaben sichaus diesem Modell ebenfalls zwei Tabellen namens EexBlockBid und EexBlock-BidDetails, wobei aus letzterer eine Fremdschlusselbeziehung zur erstgenanntenbesteht.

PDF-Export Angebote sollen bei der EEX per Fax eingereicht werden. Hier-fur werden von der Energieborse spezielle Angebotsformulare bereitgestellt. Dievom EIS erstellten Angebote konnen – sofern alle erforderlichen Daten vorhan-den sind – in eine PDF -Datei exportiert werden, so dass man sie bei der Ener-gieborse einreichen kann. Dazu wurden die Formulare der EEX als Grafikdateienins System eingefugt und dienen als Hintergrund fur einen von Windows.Formsangebotenen ReportViewer, in den aus den relevanten Klassen die benotigtenDaten, also die mit Werten besetzten Attribute der Instanzen, im What-you-see-is-what-you-get-Verfahren eingebunden und positioniert werden konnen.

93

Page 94: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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. Fur allekomplexeren Datenstrukturen, etwa Arrays, oder zum Zugriff auf Attribute vonInstanzen anderer Klassen, die innerhalb der ursprunglichen Klasse referenziertwerden, mussten Hilfsklassen erstellt werden. Diese werden vor Erzeugung desReports mit den nicht direkt einzubindenden Attributen der anderen Klassengefullt. Die Attribute werden dann in eine Form gebracht, die direkt in denReport ubernommen werden kann, und eingebunden.

Die in den Report eingefugten Daten wurden so platziert, dass das von derEEX bereitgestellte Formular korrekt ausgefullt ist. Beim Aufruf des Komman-dos PDF-Export offnet sich ein neues Fenster, in dem dieser Report als Vorschauangezeigt wird, und die Optionen zum Speichern als PDF werden angezeigt. Diefolgenden beiden Abbildungen (40 und 41) zeigen die Vorlage des Reports furStundenangebote und die PDF-Export-Vorschau.

Abbildung 40: Erstellung des Reports fur Stundenangebote in Visual Studio2005

EEX-Angebote im Datenzugriff Fur den Datenzugriff auf EEX-Angebotestehen die Klassen EexBlockBidDAL und EexHourBidDal zur Verfugung, derenMethoden hier erlautert werden. Außerdem gibt es fur die Angebotsdetails zweiweitere Klassen, deren Methoden innerhalb der hier aufgefuhrten aufgerufenwerden und hier nicht weiter diskutiert werden.

• GetAllEexHourBids: Liefert alle EEX-Stundenangebote aus der Daten-bank als Liste von EexHourBid-Objekten zuruck.

• GetEexHourBid: Liefert das EEX-Stundenangebot zuruck, das zur uber-gebenen GUID gehort.

94

Page 95: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 41: Vorschau auf den PDF-Export eines Stundenangebots

Abbildung 42: Klassen fur den Datenbankzugriff auf EEX-Angebote

95

Page 96: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• GetEexHourBidDataSet: Liefert ein DataSet-Objekt zuruck, das verein-fachte Darstellungen aller EEX-Stundenangebote zur Anzeige von Uber-sichten enthalt.

• GetAllEexBlockBidInfos: Liefert vereinfachte Darstellungen aller EEX-Block-angebote als Liste von EexBlockBidInfo-Objekten zuruck.

• InsertEexHourBid: Fugt ein neues EEX-Stundenangebot in die Datenbankein.

• UpdateEexHourBid: Aktualisiert mittels des ubergebenen Stundenangebotein vorhandenes EEX-Stundenangebot in der Datenbank und gibt denErfolg dieser Operation als ReturnCode-Objekt zuruck.

• DeleteEexHourBid: Loscht ein uber seine GUID identifiziertes EEX-Stun-denangebot aus der Datenbank und gibt den Erfolg der Operation alsReturnCode-Objekt zuruck. Stundenangebote konnen auch geloscht wer-den, wenn sich noch EEX-Lieferungen auf sie beziehen.

• GetAllEexBlockBids: Liefert alle EEX-Blockangebote als Listevon EexBlockBid-Objekten aus der Datenbank zuruck.

• GetEexBlockBid: Liefert das EEX-Blockangebot zuruck, das zur uberge-benen GUID gehort.

• GetEexBlockBidDataSet: Liefert ein DataSet zuruck, das vereinfachte Dar-stellungen aller EEX-Blockangebote zur Anzeige von Ubersichten enthalt.

• GetAllEexBlockBidInfos: Liefert vereinfachte Darstellungen allerEEX-Blockangebote als Liste von EexBlockBidInfo-Objekten zuruck.

• InsertEexBlockBid: Fugt ein neues EEX-Blockangebot in die Datenbankein.

• UpdateEexBlockBid: Aktualisiert mittels des ubergebenen Blockangebotsein vorhandenes EEX-Blockangebot in der Datenbank und gibt den Erfolgdieser Operation als ReturnCode-Objekt zuruck.

• DeleteEexBlockBid: Loscht ein uber seine GUID identifiziertes EEX-Block-angebot aus der Datenbank und gibt den Erfolg der Operation als Objektdes Typs ReturnCode zuruck. Blockangebote konnen auch geloscht wer-den, wenn sich noch EEX-Lieferungen auf sie beziehen.

EEX-Angebote in der Geschaftslogik Die Geschaftslogik befindet sich inder Klasse EexManager. Die zentralen Methoden zum Zugriff auf EEX-Angebotewerden hier kurz vorgestellt.

• GetAllEexHourBids: Ruft die gleichnamige Methode aus der Datenzu-griffsschicht auf und liefert deren Ergebnis zuruck.

• GetEexHourBid: Ruft die gleichnamige Methode aus der Datenzugriffs-schicht auf und liefert deren Ergebnis zuruck.

96

Page 97: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• GetEexHourBidDataSet: Ruft die gleichnamige Methode aus der Daten-zugriffsschicht auf und liefert deren Ergebnis zuruck.

• AddNewEexHourBid: Ruft mit dem ubergebenen Stundenangebot als Ar-gument die Methode InsertEexHourBid aus der Datenzugriffsschicht aufund liefert deren Ergebnis zuruck.

• UpdateEexHourBid: Ruft mit dem ubergebenen Stundenangebot als Ar-gument die gleichnamige Methode aus der Datenzugriffsschicht auf undliefert deren Ergebnis zuruck.

• DeleteEexHourBid: Ruft mit der ubergebenen GUID als Argument diegleichnamige Methode aus der Datenzugriffsschicht auf und liefert derenErgebnis zuruck.

• GetAllEexBlockBids: Ruft die gleichnamige Methode aus der Datenzu-griffsschicht auf und liefert deren Ergebnis zuruck.

• GetEexBlockBid: Ruft die gleichnamige Methode aus der Datenzugriffs-schicht auf und liefert deren Ergebnis zuruck.

• GetEexBlockBidDataSet: Ruft die gleichnamige Methode aus der Daten-zugriffsschicht auf und liefert deren Ergebnis zuruck.

• AddNewEexBlockBid: Ruft mit dem ubergebenen Blockangebot als Argu-ment die Methode InsertEexBlockBid aus der Datenzugriffsschicht aufund liefert deren Ergebnis zuruck.

• UpdateEexBlockBid: Ruft mit dem ubergebenen Blockangebot als Argu-ment die gleichnamige Methode aus der Datenzugriffsschicht auf und lie-fert deren Ergebnis zuruck.

• DeleteEexBlockBid: Ruft mit der ubergebenen GUID als Argument diegleichnamige Methode aus der Datenzugriffsschicht auf und liefert derenErgebnis zuruck.

Stundenangebote in der GUI Fur Stundenangebote wurde ein eigenesGUI-Fenster erstellt (siehe Abbildung 43, das sich offnet wenn der Benutzerim EEX-Panel unter der Ubersicht der Stundenangebote auf Erstellen oder –sofern ein Angebot ausgewahlt ist – Bearbeiten klickt. Zum Bearbeiten einesAngebots wird das in der Ubersicht ausgewahlte dem neuen Panel ubergebenund dessen Daten dort angezeigt. In diesem Panel, das uberdies ahnlich auf-gebaut ist wie das zugrunde liegende EEX-Formular, lassen sich alle fur dasStundenangebot benotigten Parameter setzen. Diese sind:

• Gultigkeitszeitraum (Jahr und Woche)

• Wochentage

• Korrekturangebot, sind also fruhere Versionen vorhanden

• Betroffene Regelzone

97

Page 98: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 43: Eingabefenster fur Stundenangebote

Fur die Hauptdaten des Angebots, also wann wieviel Energie geliefert werdensoll, steht eine Tabelle mit insgesamt 18 Spalten und 24 Zeilen zur Verfugung,die den EEX-Vorgaben entspricht. In den beiden linken Spalten werden dieStundenintervalle eingetragen, fur die die rechts daneben angegebenen Energie-mengen ge- oder verkauft werden sollen. Steht links beispielsweise Von 1 bis 1bedeutet dies, dass die Mengen in derselben Zeile fur die erste Stunde des Tages,also die Zeit von 0:00 Uhr bis 0:59 Uhr gelten. Eine Zeitangabe Von 4 bis 6 stehtfur Lieferungen von 4:00 Uhr bis 6:59 Uhr.

Die Mengen, die daneben stehen, sind jeweils bis zu 16 Mengen, die bei ver-schiedenen Preisen angeboten oder nachgefragt werden. Diese 16 Preise konnenuber den Button Preise wahlen in einem weiteren Fenster gesetzt werden, wo-bei als Mindestgrenze 0 und als Hochstgrenze 3000 Euro gesetzt wurden. DiePreisangabe von 0 Euro fur die erste Mengenspalte und von 3000 Euro fur dieletzte Spalte ist daruber hinaus durch die EEX fest vorgegeben.

Es mussen nicht fur jeden Preis Mengen gesetzt werden, aber mindestens eineMenge fur jedes Zeitintervall wird gefordert. Negative Mengen gelten wie bereitserwahnt als Verkaufs-, nicht-negative Mengen als Kaufwunsch. Die Preise dienendabei als Hochstkauf- oder Mindestverkaufspreise fur die eingetragen Menge.Die von der EEX vorgegebene Hochstmenge von 250 MWh wird uberwacht,und erst wenn das Angebot korrekt ausgefullt ist, wird der Button PDF-Exportfreigeschaltet, uber den man sich den in Absatz 5.2.2 beschriebenen Reportgenerieren lassen kann.

Durch einen Klick auf den Speichern-Button wird mit den vorhandenen Da-ten ein neues EexHourBid-Objekt erzeugt und die Methode AddNewEexHourBidaus dem Service Access Layer aufgerufen, um das Objekt uber den Webservicein die Datenbank einzufugen. Die ubrigen, nicht vom Nutzer einzugebenden

98

Page 99: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 44: Eingabefenster zur Preissetzung fur Stundenangebote

Parameter wie EEX-Zugangsdaten oder Datum des Angebots werden dabei au-tomatisch ermittelt.

Blockangebote in der GUI Die Eingabe von Blockangeboten erfolgt analogzu Stundenangeboten uber einen Klick auf die Buttons Erstellen oder Bearbei-ten, woraufhin sich ein neues Fenster offnet (siehe Abbildung 45), das ggf. mitden Daten des bereits vorhandenen Blockangebots gefullt wird. Auch das Designdieses Panels entspricht der EEX-Vorlage. Die Rahmendaten des Angebots, dievom Nutzer bereitzustellen sind, sind die folgenden:

• Gultigkeitszeitraum (Jahr und Woche)

• Wochentage

• Korrekturangebot, sind also fruhere Versionen vorhanden

Unter dem Bereich fur diese Daten folgt ein zweigeteilter Abschnitt, in dem sichlinks eine Matrix mit vier Spalten und 15 Zeilen befindet. In jede Zeile kanndabei ein Kauf- oder Verkaufswunsch eingetragen werden. Dazu muss ein Blockausgewahlt werden, fur den dieser gilt, wobei ein Block einen von der EEX vor-definierten Zeitraum beschreibt, von denen insgesamt 12 zur Verfugung stehen.Ebenso muss in Abweichung von Stundenangeboten fur jeden der maximal 15Wunsche eine Regelzone angegeben werden, aus der die Energie bezogen bzw.in die sie geliefert werden muss. Pro Kauf- bzw. Verkaufswunsch muss wiederein Hochst- bzw. Mindestpreis eingegeben werden. Die Mengenrestriktion vonmaximal 250 MWh pro Block wird ebenfalls beachtet. Wenn das Angebot kor-rekt ausgefullt ist, wird der Button PDF-Export freigeschaltet, uber den mansich den in Absatz 5.2.2 beschriebenen Report generieren lassen kann.

99

Page 100: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 45: Eingabefenster fur Blockangebote

Indem auf den Button Speichern geklickt wird, erzeugt das Programm einneues EexBlockBid-Objekt und fullt es mit den eingegebenen Daten. Die fehlen-den Daten wie Datum oder EEX-Zugang werden automatisch erganzt. Danachwird die Methode AddNewEexBlockBid mit dem erzeugten Objekt aufgerufenund dieses dem Server zum Einfugen in die Datenbank ubergeben.

5.2.3 Bestatigte Lieferungen

Wenn Teile eines EEX-Angebots von einem anderen Energiehandler akzeptiertwurden, entstehen daraus neue Lieferverpflichtungen. Diese werden in Objektendes Typs EexDelivery gespeichert, wobei es unerheblich ist, ob das zugrundeliegende Angebot, auf das eine Referenz gespeichert wird, ein Block- oder Stun-denangebot war. Zu jeder EEX-Lieferung werden neben dem Zeitraum, in demsie stattfindet, die konstant zu liefernde Menge in MW, der Preis pro MWh inEuro sowie die Regelzone und der Bilanzkreis, die Ursprung oder bei VerkaufenZiel der Lieferungen sind, vermerkt. Daraus ergibt sich der Datentyp, der inAbbildung 47 dargestellt ist.

Spezielle EEX-Lieferungen waren im Entwurf ursprunglich nicht vorgesehen,erwiesen sich aber als sinnvoll, da sie einige Abweichungen von normalen Liefer-vertragen aufweisen. Zum einen sind sie mit einem vorher abgegebenen EEX-Angebot verbunden und sind stets abgeschlossene Vertrage, die Unterscheidungzwischen von Lieferanten abgegebenen Angeboten und abgeschlossenen Vertra-gen entfallt also. Außerdem konnen EEX-Lieferungen von oder zu beliebigenHandlern erfolgen, auch solchen, die nicht als Lieferanten eingetragen sind. Dar-uber hinaus besitzen EEX-Lieferungen die eine Mengenbegrenzung. Ansonstensind die Formate aber zueinander kompatibel, was die Berechnung von Kaufemp-

100

Page 101: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 46: Klasse EexManager

101

Page 102: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 47: Klasse EexDelivery

fehlungen und aktueller Fehldeckung erleichtert. Zu EEX-Lieferungen, die ubermehrere Tage gehen und dort jeweils nur einzelne Stunden abdecken, mussenmehrere EexDelivery-Objekte erzeugt werden, die jeweils einen der verschiede-nen Lieferzeitraume an den verschiedenen Tagen abdecken, da zwecks Kompa-tibilitat zu normalen Liefervertragen nur ein konstanter Energiefluss wahrendder Laufzeit vorgesehen ist.

Abbildung 48: Klasse EexDeliveryDAL

EEX-Lieferungen im Datenzugriff Zum Zugriff auf die Daten der Liefe-rungen existiert die Klasse EexDeliveryDAL (Abbildung 48), die auf die Daten-banktabelle EexDelivery zugreift, die die EEX-Lieferungen relational abbildet.Zur Verbindung zwischen EEX-Angebot und zugehoriger Lieferung existiert ei-ne Referenz uber die Angebots-GUID. Die Methoden zum Datenzugriff sind diefolgenden:

102

Page 103: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• CountEexDeliveriesForDay: Bekommt ein DateTime-Objekt ubergeben,zahlt auf dieser Grundlage alle EEX-Lieferungen in der Datenbank, diean diesem Tag fur einen beliebigen Zeitraum gelten und gibt das Ergebniszuruck.

• DeleteEexDelivery: Loscht die EEX-Lieferung mit der ubergebenen GUIDaus der Datenbank und gibt mit einem ReturnCode-Objekt den Erfolg derOperation zuruck.

• GetAllEexDeliveries: Liest alle gespeicherten EEX-Lieferungen aus der Da-tenbank aus und gibt sie als Liste von EexDelivery-Objekten zuruck.

• GetEexDelivery: Liefert die zur ubergebenen GUID gehorende EEX-Liefe-rung zuruck.

• GetEexDeliveryForSchedule: Bekommt ein DateTime-Objekt ubergeben undextrahiert auf dieser Grundlage alle EEX-Lieferungen aus der Datenbank,die am besagten Tag fur einen beliebigen Zeitraum gelten. Diese Lieferun-gen werden in einer Liste von EexDelivery-Objekten zuruckgegeben.

• InsertEexDelivery: Bekommt eine neue EEX-Lieferung zum Einfugen indie Datenbank ubergeben und gibt uber einen ReturnCode das Ergebnisder Operation zuruck.

• UpdateEexDelivery: Bekommt eine bearbeite EEX-Lieferung, mit der einvorhandener Datenbankeintrag aktualisiert werden soll, ubergeben undgibt uber einen ReturnCode das Ergebnis der Operation zuruck.

EEX-Lieferungen in der Geschaftslogik In der Geschaftslogik werden imwesentlichen durch die Klasse EexManager (siehe Abbildung 46) auf Anfragedes Webservices die Methoden aus der Datenbanklogik angesprochen und derenErgebnis zuruckgegeben. Zusatzlich existieren Methoden zur Berechnung ge-und verkaufter Mengen.

• CountEexDeliveriesForDay: Ruft die gleichnamige Methode aus der KlasseEexDeliveryDAL auf und liefert deren Ergebnis zuruck.

• DeleteEexDelivery: Ruft die gleichnamige Methode aus der KlasseEexDeliveryDAL auf und liefert deren Ergebnis zuruck.

• GetAllEexDeliveries: Ruft die gleichnamige Methode aus der KlasseEexDeliveryDAL auf und liefert deren Ergebnis zuruck.

• GetBoughtEnergyAmount: Berechnet fur einen ubergebenen Tag (alsDateTime) die Gesamtmenge der uber die EEX verkauften Energie inMWh und liefert das Ergebnis zuruck.

• GetEexDelivery: Ruft die gleichnamige Methode aus der KlasseEexDeliveryDAL auf und liefert deren Ergebnis zuruck.

• GetSoldEnergyAmount: Berechnet fur einen ubergebenen Tag (alsDateTime) die Gesamtmenge der uber die EEX verkauften Energie inMWh und liefert das Ergebnis.

103

Page 104: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• InsertEexDelivery: Ruft die gleichnamige Methode aus der KlasseEexDeliveryDAL auf und liefert deren Ergebnis zuruck.

• UpdateEexDelivery: Ruft die gleichnamige Methode aus der KlasseEexDeliveryDAL auf und liefert deren Ergebnis zuruck.

Abbildung 49: EEX-Lieferungsubersicht mit Bearbeitungsmoglichkeiten

EEX-Lieferungen in der GUI In der Benutzeroberflache existiert ein eige-nes Panel (Abbildung 49 zur Ubersicht uber die vorhandenen Lieferungen. Ineiner Tabelle werden die wichtigsten Daten aller Lieferungen dargestellt. JedeLieferung lasst sich, nachdem sie ausgewahlt wurde, uber ein Kontextmenu odereinen Klick auf den Button Markierte bearbeiten editieren. Dann wird das Panelzum Bearbeiten einer EEX-Lieferung aufgerufen und mit den vorhandenen Da-ten gefullt. Nach dem Klick auf Speichern erfolgt die Zuweisung der neuen Datenan das EexDelivery-Objekt und ein Aufruf der Methode UpdateEexDeliverymit dem geanderten Objekt. Geloscht werden EEX-Lieferungen uber das Kon-textmenu oder einen Klick auf den Button Markierte loschen. Nach einer Si-cherheitsabfrage wird die Methode DeleteEexDelivery aufgerufen.

Anlegen lassen sich EEX-Lieferungen nur uber das Panel fur EEX-Angebote.Und zwar muss aus den dort vorhandenen Ubersichten ein Stunden- bzw. einBlockangebot ausgewahlt werden, bevor uber einen Klick auf Lieferung einge-ben das Eingabefenster (siehe Abbildung 50) geoffnet wird. Dies liegt daran,dass jeder Lieferung ein Angebot zugeordnet werden muss. Nach Eingabe allerbenotigten Daten und deren Validierung wird bei Drucken des Buttons Spei-chern ein neues EexDelivery-Objekt erzeugt, gefullt und uber die MethodeAddNewEexDelivery an den Webservice zwecks Speicherung ubergeben.

104

Page 105: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 50: Eingabefenster fur EEX-Lieferungen

5.2.4 Aktuelle Marktdaten der Energieborse

Damit der Nutzer bei Erstellung von Angeboten immer einen Uberblick hat,welche Preise fur welche Stunden oder Blocke derzeit zu zahlen sind, werden imInfo-Bereich des Programms stets die aktuellen Strompreise der Energieborsefur alle Blocke und samtliche 24 Stunden eines Tages eingeblendet. Diese Datenwerden von der EEX-Homepage bezogen. Hierzu wurde ein separates Programmentwickelt, welches taskgesteuert einmal taglich die neu bereitgestellten Datender EEX parst und sie in die Datenbank schreibt. Zur Speicherung steht dieTabelle EexMarketData bereit. Eine gleichnamige Klasse ubernimmt die Daten-haltung im Programm (siehe Abbildung 51).

Abbildung 51: Klasse EexMarketData

Die Attribute dieser Klasse, die zur Darstellung der an der EEX gehandeltenTarife dienen, sind die folgenden:

105

Page 106: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• Afternoon: Strompreis fur den EEX-Block zwischen 14 und 18 Uhr

• Business: Strompreis fur den EEX-Block zwischen 8 und 16 Uhr

• Evening: Strompreis fur den EEX-Block zwischen 18 und 24 Uhr

• Hours: Array mit Einzelpreisen fur die 24 Stunden eines Tages

• Morning: Strompreis fur den EEX-Block zwischen 6 und 11 Uhr

• Night: Strompreis fur den EEX-Block zwischen 0 und 6 Uhr

• OffPeak1: Strompreis fur den EEX-Block zwischen 0 und 8 Uhr

• OffPeak2: Strompreis fur den EEX-Block zwischen 20 und 24 Uhr

• PhelixDayBase: Basispreis fur normale Stromlieferungen uber den ganzenTag.

• PhelixDayPeak: Basispreis fur Stromlieferungen zur Hochlastzeit zwischen8 bis 16 Uhr.

• RushHour: Strompreis fur den EEX-Block zwischen 16 und 20 Uhr.

Abbildung 52: Klasse EexMarketDataDAL

Marktdaten im Datenzugriff Zur Kommunikation mit der Datenbank stehtdie Klasse EexMarketDataDAL zur Verfugung. Sie stellt die folgenden Methodenbereit:

• CreateEexMarketDataFromDataRow : Erzeugt aus einer ausgelesenen Ta-bellenzeile ein neues EexMarketData-Objekt und gibt es zuruck.

• DeleteEexMarketData: Loscht ein EexMarketData-Objekt aus der Daten-bank und liefert uber einen ReturnCode den Erfolg dieser Operation zu-ruck.

• GetAllEexMarketData: Liefert alle vorhandenen Datensatze aus der Da-tenbank als Liste von EexMarketData-Objekten zuruck.

106

Page 107: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• GetEexMarketData: Liefert einen Datensatz als EexMarketData-Objektzuruck, der entweder eine bestimmte GUID oder ein bestimmtes Gultig-keitsdatum aufweist.

• InsertEexMarketData: Fugt ein ubergebenes EexMarketData-Objekt indie Datenbank ein und gibt den Erfolg der Operation uber einen ReturnCodezuruck.

• UpdateEexMarketData: Aktualisiert anhand eines ubergebenenEexMarketData-Objektes den zugehorigen Datensatz in der Datenbankund gibt den Erfolg der Operation uber einen ReturnCode zuruck.

Marktdaten in der Geschaftslogik Die Geschaftslogik fur EEX-Marktdatenfindet sich in der Klasse EexManager (siehe Abbildung 46). Komplexere Berech-nungen finden nicht statt; es werden nur Anfragen an die Datenzugriffslogikweitergeleitet. Dies geschieht durch die Funktion

• GetEexMarketData: Ruft mit einem ubergebenen Datum die gleichnamigeMethode der Klasse EexMarketDataDAL auf und liefert deren Ergebniszuruck.

Marktdaten in der grafischen Oberflache Beim Aufruf des Panels furEEX-Handel durch Klick auf den entsprechenden Menupunkt in der linken Na-vigationsleiste wird oberhalb der Navigation ein Fenster eingeblendet, in demdie aktuellsten von der EEX bezogenen Preise mit den zugehorigen Tarifen ein-geblendet werden, sofern Preisdaten in der Datenbank verfugbar sind (sieheAbbildung 53).

5.2.5 EEX-Parser

Das Programm EEX.exe wird mit einem ubergebenen Parameter aufgerufen,welcher die jeweilige Ausfuhrung des Programms bestimmt. Diese Parametersind -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 Tagedifferenzzwischen dem neuesten Eintrag in der Datenbank und dem neuesten Eintragauf der EEX-Seite ermittelt. Betragt diese Differenz zum Beispiel drei Tage,so werden die letzten drei Eintrage von der EEX-Seite in die Datenbank ge-schrieben. Es konnen jedoch keine ”Lucken“ einzelner Tage in der Datenbankgefullt werden, die jedoch auch niemals auftreten sollten. Dieser Parameter istder Standardaufruf des Parsers.

Der Parameter -a schreibt alle acht auf der EEX-Seite angebotenen Tages-marktdaten in die Datenbank. Er bietet sich fur den erstmaligen Eintrag ineine noch leere Datenbank an. Ansonsten besteht die Gefahr von Redundanzen,da keine explizite Prufung erfolgt, ob die Marktdaten eines bestimmten Tagesbereits vorhanden sind.

107

Page 108: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 53: Fenster fur aktuelle Marktdaten

Der letzte Parameter -n schreibt nur den neuesten Tagesdatensatz der EEX-Seite in die Datenbank. Er dient in erster Linie rein administrativen Zwecken,zum Beispiel fur Datenbanktests.

Es wurde eine eigenstandige GUI entwickelt, die die manuelle Ausfuhrungdes Parsers erleichtert. Sie ist in Abbildung 54 zu sehen. Das Parsen von Web-seiten wird auch als scrapen bezeichnet, weshalb auch vom EEX-Scraper dieRede ist. Die EEX-GUI erlaubt die Auswahl des gewunschten Parameters durchden Benutzer. Zuvor muss noch der Pfad zu EEX.exe gesetzt werden. Dies ge-schieht durch den Setzen-Button neben der Pfadangabe. Nach einmaliger Aus-wahl wird dieser Pfad in der Datei Verzeichnis.txt gespeichert und bei jedemProgrammstart wieder ausgelesen.

Die Aktualisierung der Marktdaten in der Datenbank wird dadurch automa-tisiert, dass eex.exe -f taglich durch den Taskmanager des Windows-Serversausgefuhrt wird. Da die EEX die Marktdaten taglich zwischen 12:00 und 13:00Uhr aktualisiert, bietet sich hier 13:05 Uhr als Zeitpunkt fur den Aufruf an.

5.2.6 Die Funktionsweise von EEX.exe

Das Programm EEX.exe wird durch die Klasse Program reprasentiert (sieheAbbildung 55). Die zentralen Methoden zum Programmablauf werden hier kurzvorgestellt.

• ScrapIt: Liest die angegebene URL (der EEX-Seite) aus und schreibt denInhalt in einen String.

108

Page 109: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 54: Die GUI fur den EEX-Scraper

• BeschneideInhalt: schneidet die drei relevanten Info-Bereiche zurecht, bzw.entfernt die Teile der HTML-Seite, die nicht benotigt werden.

• EntferneHtml: entfernt die HTML-Tags aus dem String, der den Websei-teninhalt speichert.

• Schreibe: schreibt die Marktdaten in eine Textdatei.

• erzeugeMarktdaten: erzeugt aus dem Inhaltstring die Marktdatenobjekte.

• ausfuehren: fuhrt die Methoden BeschneideInhalt, EntferneHtml, Schreibeund erzeugeMarktdaten in dieser Reihenfolge aus.

• dbEintrag: schreibt die gewunschten 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 entgegen-nimmt und sie entsprechend auswertet.

5.3 Entscheidungsunterstutzung

5.3.1 Lastprognosen

Allgemeines Eine Lastprognose gibt fur einen bestimmten Zeitraum in derZukunft den erwarteten Energieverbrauch der Kunden des Energiehandlers an.Jede Lastprognose enthalt eine beliebige Anzahl an Lastprofilen, wobei jedesLastprofil einen Tag abdeckt. Das Lastprofil ist in Viertelstundenabschnitte un-terteilt, denen jeweils die erwartete Energi emenge in MWh zugeordnet ist.Grundlage jeder Lastprognose sind die Kundenvertrage, die mit dem Energie-handler abgeschlossen wurden und sich mit dem Zeitraum der Lastprognoseuberschneiden oder komplett in diesen fallen, und deren Lastprofile. Lastpro-gnosen dienen als Grundlage fur Kaufempfehlungen.

109

Page 110: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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 Laufzeitneue Plugins zu laden und zu benutzen. Dieses System wird in Abschnitt 4.2.1ausfuhrlich erlautert. Die Verwaltung der Lastprognose implementiert die An-wendungsfalle 47 bis 51 des Entwurfs.

Lastprognose als abstrakter Datentyp Die Umsetzung der Lastprognosenals Datentyp erstreckt sich uber zwei Klassen (s. Abb. 56). Alles, was mit denZeitreihen der Lastprognose zu tun hat, ist in die Klasse EnergyPredictionTime-Series 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), dieeindeutige ID, eine laufende Nummer sowie ein Infofeld. Außerdem wird ein Kon-struktor angeboten und eine Liste von EnergyPredictionTimeSeries-Objekten,in denen die prognostizierten Verbrauchswerte gespeichert sind.

Dabei steht jedes Objekt in der Liste fur die Vorhersage fur einen bestimmtenTag, wobei die Objekte durchgehend vom ersten bis zum letzten Tag der Gel-tungsdauer geordnet sind. Jedes Objekt vom Typ EnergyPredictionTimeSeriesspeichert neben einer eindeutigen ID auch, fur welchen Tag es den Energiever-brauch prognostiziert (Feld Day), eine GUID-Referenz zum zugehorigen Ener-gyPrediction-Objekt und eine Liste mit 96 Energieverbrauchswerten, je einemfur jede Viertelstunde des Tages (zugreifbar uber Index this oder Amounts).

Lastprognosen in der Datenbank Beide Klassen, die zur Reprasentati-on einer Lastprognose dienen, werden in der Datenbank uber je eine gleichna-mige Tabelle dargestellt. Jedes Attribut der Klassen wird auf eine Spalte derjeweiligen Tabelle abgebildet, wobei das Array aus der Klasse EnergyPredic-tionTimeSeries uber CSV-Werte ebenfalls in einer Spalte abgelegt wird undbeim Einfugen und Auslesen entsprechend formatiert werden muss. Als Primar-schlussel dienen in beiden Klassen die ID-Felder. Zudem gibt es in der Tabelle

110

Page 111: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 56: Klassen EnergyPrediction und EnergyPredictionTimeSeries

EnergyPredictionTimeSeries eine Fremdschlusselbeziehung der Spalte energy-Prediction zur Spalte id der Tabelle EnergyPrediction, um so die Zeitreihen mitder zugehorigen Lastprognose in Verbindung zu bringen.

Abbildung 57: Klasse EnergyPredictionDAL

Lastprognosen im Datenzugriff Der Datenzugriff wird uber die statischeKlasse EnergyPredictionDAL realisiert, die die bereits im vorigen Abschnitt an-gesprochenen statischen Methoden bereitstellt:

• InsertEnergyPrediction: Fugt eine neue Lastprognose in die Datenbankein und zeigt uber einen booleschen Wert den Erfolg der Aktion an.

• DeleteEnergyPrediction: Loscht eine in der Datenbank gespeicherte Last-prognose und zeigt uber einen booleschen Wert den Erfolg der Aktion an.

111

Page 112: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• IsEnergyPredictionUsed : Uberpruft, ob eine Lastprognose noch von Kauf-empfehlungen benutzt wird, und gibt das Ergebnis als booleschen Wertzuruck.

• GetEnergyPrediction: Liest eine Lastprognose mit einer ubergebenen IDaus der Datenbank aus und gibt sie zuruck.

• GetAllEnergyPredictions: Liest alle Lastprognosen aus der Datenbank ausund liefert sie als Liste zuruck.

Abbildung 58: Klasse EnergyPredictionManager

Lastprognosen in der Geschaftslogik Die Klasse EnergyPredictionMana-ger ubernimmt den Umgang mit Lastprognosen in der Geschaftslogik. Weilkeinerlei Algorithmen auf den Lastprofilen ausgefuhrt werden mussen, erfolgtlediglich ein Zugriff auf die passenden Methoden der darunterliegenden Daten-haltungsschicht, deren Ergebnisse weitergeleitet und vom Webservice, der dieMethoden dieser Klasse aufruft, als Ruckgabewerte verwendet werden. Zu jederMethode aus dem Service Access Layer existiert eine bereitgestellte Methode:

• AddNewEnergyPrediction: Ruft mit dem ubergebenen EnergyPrediction-Objekt die statische Methode InsertEnergyPrediction der Klasse Energy-PredictionDAL auf und gibt deren Ergebnis zuruck.

• DeleteEnergyPrediction: Ruft mit der ubergebenen ID die statische Me-thode DeleteEnergyPrediction der Klasse EnergyPredictionDAL auf undgibt deren Ergebnis zuruck.

• IsEnergyPredictionUsed : Ruft mit dem ubergebenen EnergyPrediction-Objekt die statische Methode IsEnergyPredictionUsed der Klasse Ener-gyPredictionDAL auf und gibt deren Ergebnis zuruck.

• GetEnergyPrediction: Ruft mit dem ubergebenen EnergyPrediction-Objektdie statische Methode InsertEnergyPrediction der Klasse EnergyPredic-tionDAL auf und gibt deren Ergebnis zuruck.

• GetAllEnergyPredictions: Ruft die statische Methode GetAllEnergyPredic-tions der Klasse EnergyPredictionDAL auf, wandelt deren Ergebnis (eineListe mit EnergyPrediction-Objekten) in ein Array um und gibt es zuruck.

112

Page 113: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Lastprognosen in der grafischen Oberflache Zum Erstellen von Lastpro-gnosen gibt es eine zweigeteilte grafische Oberflache. Links gibt es die Moglich-keit, Plugins mit Algorithmen auszuwahlen. Nachdem ein Algorithmus ausge-

Abbildung 59: GUI zur Erstellung von Lastprognosen

wahlt sowie Anfangs- und Enddatum der Lastprognose eingegeben wurden, kannder Nutzer uber den Button Lastprognose konfigurieren die individuellen Para-meter des Plugins einstellen und es starten. Anfangs- und Enddatum konnenbeliebige Zeitspannen abdecken, so dass damit die Anforderungen (vgl. Kapi-tel 3) an die Laufzeit der Lastprognose (und auch der Kaufempfehlungen, daKaufempfehlungen auf Lastprognosen und deren Laufzeit aufbauen) ubertroffenwerden.

Die Algorithmen zur Lastprognose Das Energieinformationssystem ver-fugt bereits uber zwei Algorithmen zum Erstellen von Lastprognosen.

• SimplePredictionPlugin: Dies eine ist ein sehr einfacher Algorithmus, derlediglich die in den Lastprofilen der Kundenvertrage angegebenen Wer-te aufaddiert und danach in der Lastprognose speichert. Fur jedes Zeit-intervall jedes Tages werden also die Werte aus allen Kundenvertragen,die wahrend dieses Zeitintervalls gelten, summiert und dann in das ent-sprechende Zeitintervall der Lastprognose geschrieben. Weitere Parameterexistieren nicht.

• AdvancedPredictionPlugin: Dieser Algorithmus verfahrt nach demselbenPrinzip wie der vorige, summiert also auch die Werte auf, allerdings werden

113

Page 114: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

drei weitere, vom Benutzer vorzugebende Parameter berucksichtigt. Diessind:

– Ein fester prozentualer Wert fur die Abweichung des Stromverbrauchsan Wochenenden vom normalen Verbrauch an Werktagen.

– Ein fester prozentualer Wert fur die maximale jahreszeitlich beding-te Abweichung des tatsachlichen Stromverbrauchs von den in denLastprofilen angegebenen Werten. Diese Abweichung wird uber eineKosinuskurve reprasentiert, die standardmaßig bei Neujahr ihr Ma-ximum und zur Jahresmitte ihr Minimum erreicht. Dort wird derProzentwert voll aufgeschlagen bzw. voll abgezogen.

– Ein weiterer Wert gibt an, um wieviele Tage die Sinuskurve gegenuberder Standardposition mit den Extrema bei Neujahr und Jahresmitteverschoben ist. Dieser Parameter ist notwendig, weil normalerweisedie kalteste Zeit des Jahres einige Wochen nach Neujahr und dieheißeste einige Wochen nach der Jahresmitte liegt.

Abbildung 60: GUI zur Konfiguration des AdvancedPredictionPlugin

Beide Algorithmen sind im Projekt PredictionPlugins zusammengefasst undwerden gegen das ubrige Projekt zu einer DLL kompiliert. Die zusatzlichenParameter des zweiten Algorithmus werden uber ein einfaches GUI eingegeben,das von der Lastprognosenoberflache aufgerufen wird.

114

Page 115: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

5.3.2 Storungsverwaltung

Allgemeines Storungen werden von den Energielieferanten an die Benutzerdes Energieinformationssystens gemeldet und von diesen in das System einge-tragen. Diese Storungen wirken sich dabei auf die laufenden Vertrage mit denLieferanten aus und werden bei der Erstellung von Lastprognosen und Kauf-empfehlungen berucksichtigt. Eine Storung vermindert die Menge der aktuellenEnergielieferung zu einem bestimmten Zeitraum, was zu neuen Berechnungendes Strombedarfs folgen kann. Die Storungsverwaltung realisiert die Anwen-dungsfalle 58 bis 62.

Storungen als Datentyp Die Umsetzung der Storungen in einen Datentyperfolgt durch die Klasse Disturbances. Sie speichert zur eindeutigen Identifi-kation eine Guid, den Liefervertrag, auf dem die Storung angewendet wird, denReprasentationscode, die voraussichtliche Fehlmenge, die zugehorige, erklarendeNachricht fur die Storung, das Kennzeichen, ob die Storung noch aktuell ist undden Zeitpunkt, fur wann die Storung gultig ist.

Abbildung 61: Klasse Disturbance

Storungen in der Datenbank Die Klasse Disturbance, siehe Abbildung 61,fur die Reprasentation einer Storung wird in der Datenbank uber eine gleich-namige Tabelle dargestellt. Jedes Attribut der Klasse wird auf eine Spalte derjeweiligen Tabelle abgebildet. Als Primarschlussel dient das ID-Feld. Zudem gibtes in der Tabelle eine Fremdschlusselbeziehung der Spalte supplierContract zurSpalte id der Tabelle SupplierContract, um so die Storungen mit dem zugeho-rigen Liefervertrag in Verbindung zu bringen.

Storungen im Datenzugriff Der Datenzugriff wird uber die statische Klas-se DisturbanceDAL, siehe Abbildung 62, realisiert, die die bereits im vorigenAbschnitt angesprochenen statischen Methoden bereitstellt:

• InsertDisturbance: Fugt eine neue Storung in die Datenbank ein und zeigtuber einen booleschen Wert den Erfolg der Aktion an.

115

Page 116: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 62: Klasse DisturbanceDAL

• UpdateDisturbance: Aktualisiert eine vorhandene Storung in der Daten-bank und zeigt uber einen booleschen Wert den Erfolg der Aktion an.

• DeleteDisturbance: Loscht eine in der Datenbank gespeicherte Storung undzeigt uber einen booleschen Wert den Erfolg der Aktion an.

• GetDisturbance: Liest eine Storung mit einer ubergebenen ID aus der Da-tenbank aus und gibt sie zuruck.

• GetAllDisturbances: Liest alle Storungen aus der Datenbank aus und lie-fert sie als Liste zuruck.

• GetDisturbancesForContract : Bekommt ein Guid-Objekt ubergeben undliest alle Storungen aus der Datenbank fur einen bestimmten Liefervertragaus und gibt sie als Liste zuruck.

• GetDisturbancesNotCurrent : Liest alle historischen Storungen aus der Da-tenbank aus und gibt sie als Liste zuruck.

• GetDisturbancesByDate: Bekommt ein DateTime-Objekt ubergeben undliest alle Storungen aus der Datenbank zu dem Datum aus und gibt sieals Liste zuruck.

• GetDisturbancesByCode: Bekommt einen Storungscode ubergeben, liestalle Storungen mit diesem Code aus der Datenbank aus und gibt sie alsListe zuruck.

• GetDisturbancesByCompany : Bekommt einen Firmennamen ubergeben,liest alle Storungen fur Unternehmen mit diesem Namen aus der Daten-bank aus und gibt sie als Liste zuruck.

116

Page 117: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• GetDisturbancesForWorstSuppliers: Liefert eine Liste von Objekten desTyps FlopDisturbances zuruck, in der zu den einzelnen Lieferanten diejeweilige Anzahl der Storungen aufgelistet sind.

Abbildung 63: Klasse DisturbanceManager

Storungen in der Geschaftslogik Die Klasse DisturbanceManager, Abbil-dung 63, ubernimmt den Umgang mit Storungen in der Geschaftslogik. Weilkeinerlei Algorithmen auf den Storungen ausgefuhrt werden mussen, erfolgt le-diglich ein Zugriff auf die passenden Methoden der darunterliegenden Daten-haltungsschicht, deren Ergebnisse weitergeleitet und vom Webservice, der dieMethoden dieser Klasse aufruft, als Ruckgabewerte verwendet werden. Zu jederMethode aus dem Service Access Layer existiert eine bereitgestellte Methode:

• AddNewDisturbance: Ruft mit dem ubergebenen Disturbance-Objekt diestatische Methode InsertDisturbance der Klasse DisturbanceDAL auf undgibt deren Ergebnis zuruck.

• UpdateDisturbance: Ruft mit dem ubergebenen Disturbance-Objekt diestatische Methode UpdateDisturbance der Klasse DisturbanceDAL auf undgibt deren Ergebnis zuruck.

• DeleteDisturbance: Ruft mit der ubergebenen ID die statische MethodeDeleteDisturbance der Klasse DisturbanceDAL auf und gibt deren Ergebniszuruck.

• GetDisturbance: Ruft mit der ubergebenen ID die statische Methode Get-Disturbance der Klasse DisturbanceDAL auf und gibt deren Ergebnis zu-ruck.

• GetAllDisturbances: Ruft die statische Methode GetAllDisturbance derKlasse DisturbanceDAL auf, wandelt deren Ergebnis (eine Liste mit Di-sturbance-Objekten) in ein Array um und gibt es zuruck.

117

Page 118: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• GetDisturbancesForContract : Ruft die statische Methode GetDisturban-cesForContract der Klasse DisturbanceDAL auf, wandelt deren Ergebnis(eine Liste mit Disturbance-Objekten) in ein Array um und gibt es zuruck.

• GetDisturbancesNotCurrent : Ruft die statische Methode GetDisturbances-NotCurrent der Klasse DisturbanceDAL auf, wandelt deren Ergebnis (eineListe mit Disturbance-Objekten) in ein Array um und gibt es zuruck.

• GetDisturbancesByDate: Ruft die statische Methode GetDisturbancesBy-Date der Klasse DisturbanceDAL auf, wandelt deren Ergebnis (eine Listemit Disturbance-Objekten) in ein Array um und gibt es zuruck.

• GetDisturbancesByCode: Ruft die statische Methode GetDisturbancesBy-Code der Klasse DisturbanceDAL auf, wandelt deren Ergebnis (eine Listemit Disturbance-Objekten) in ein Array um und gibt es zuruck.

• GetDisturbancesByCompany : Ruft die statische Methode GetDisturban-cesByCompany der Klasse DisturbanceDAL auf, wandelt deren Ergebnis(eine Liste mit Disturbance-Objekten) in ein Array um und gibt es zuruck.

• GetDisturbancesForWorstSuppliers: Ruft die statische Methode GetDi-sturbancesForWorstSuppliers der Klasse DisturbanceDAL auf, wandelt de-ren Ergebnis (eine Liste mit FlopDisturbances-Objekten) in ein Array umund gibt es zuruck.

Abbildung 64: Storungsverwaltung

118

Page 119: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Storungen in der GUI In der GUI ist die Storungsverwaltung uber denButton Storung im Hauptmenu zu erreichen. Im oberen Hauptmenu werden dieLieferanten mit den meisten Storungen angezeigt. Das Storungs-Panel (Klas-se PanelDisturbance) enthalt die Moglichkeit, nach eingetragenen Storungen zusuchen und diese im Panel anzuzeigen, siehe Abbildung 64. Die Suche kannnach verschiedenen Kriterien (Historische Storungen, bestimmtes Datum, Mel-dungscode oder Lieferantenname) durchgefuhrt werden, wobei eine Anzeige allerStorungen uber den Button ”Alle anzeigen“ moglich ist. Darunter befinden sichdie entsprechenden Schalter fur die Funktionen auf Storungsdaten (anlegen, an-dern und loschen.In das Bearbeitungspanel Klasse PanelAddDisturbance, Abbildung 65, gelangt

Abbildung 65: Neue Storung eingeben

man uber den Anlegen- oder Bearbeiten-Button. Hier gibt man die neuen, bzw.andert die vorhandenen Werte einer Storung. Beide Klassen sind als WindowsForms angelegt, wobei PanelDisturbance in den Client eingebettet ist, das Panelzum andern und anlegen von Storungen wurde als Pop-Up-Fenster implemen-tiert.

Abbildung 66: Liefervertrag auswahlen

Im Bearbeitungspanel fur Storungen kann ebenfalls ein weiteres Pop-UpFenster Klasse PanelSearchSupplierContracts, siehe 66 aufgerufen werden.

119

Page 120: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Dieses dient zur Auswahl eines Lieferantenvertrags, der zu der aktuellen Sto-rung gehort. In dem Fenster kann uber ein Suchfeld nach Lieferantenvertragengesucht werden. Der ausgewahlte Vertrag wird an das vorige Fenster ubergeben.

5.3.3 Kaufempfehlungen

Allgemeines Kaufempfehlungen sind eine Zusammenstellung von Lieferange-boten, die den erwarteten Energiebedarf moglichst prazise deckt. Der erwarteteEnergiebedarf wird durch eine oben beschriebene Lastprognose reprasentiert.Die Berechnung erfolgt serverseitig uber das Plugin-System. Ein genetischerAlgorithmus wird mitgeliefert. Hier werden die Anwendungsfalle 52 bis 57 um-gesetzt.

Abbildung 67: Klasse Recommendation

Kaufempfehlungen als Datentyp Die Umsetzung der Kaufempfehlungenin einen Datentyp erfolgt durch die Klasse Recommendation (siehe Abbildung67). Sie speichert zur eindeutigen Identifikation eine Guid, die Lastprognose,auf der die Empfehlung basiert, das Erstellungsdatum, den durch Start- undEnddatum bestimmten Gultigkeitszeitraum, die benotigte und die durch dievorgeschlagenen Angebote gedeckte Energiemenge, eine laufende Nummer, denNamen des verwendeten Algorithmus und eine Liste mit den empfohlenden Lie-fervertragen.

Daruber hinaus gibt es noch die Klasse RecommendationInfo, die nur diewichtigsten Informationen einer Kaufempfehlung enthalt und bei Ubersichtenzwecks Reduzierung der zu ubertragenden Datenmenge eingesetzt wird.

Kaufempfehlungen im Datenzugriff Kaufempfehlungen werden in der Ta-belle Recommendation gespeichert, von der aus eine Fremdschlusselbeziehung

120

Page 121: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 68: Klasse RecommendationDAL

zur Tabelle EnergyPrediction besteht, da jede Kaufempfehlung auf einer Last-prognose beruht. Zum Zugriff auf diese Datensatze steht die KlasseRecommendationDAL bereit (siehe Abbildung 68). Diese beinhaltet folgende Me-thoden:

• CreateRecommendationFromDataRow : Erzeugt aus einem aus der Daten-bank ausgelesenen Datensatz ein neues Recommendation-Objekt und gibtes zuruck.

• CreateRecommendationInfoFromDataRow : Erzeugt aus einem aus der Da-tenbank ausgelesenen Datensatz ein neues RecommendationInfo-Objektund gibt es zuruck.

• DeleteAllRecommendations: Loscht alle gespeicherten Kaufempfehlungenaus der Datenbank und gibt das Ergebnis der Operation als ReturnCode-Objekt zuruck.

• DeleteRecommendation: Loscht die Kaufempfehlung mit einer bestimm-ten GUID aus der Datenbank und gibt den Erfolg der Operation alsReturnCode-Objekt zuruck.

• GetAllRecommendationInfos: Liefert alle gespeicherten Kaufempfehlun-gen in Form vereinfachter RecommendationInfo-Objekte zuruck.

• GetAllRecommendations: Liefert alle gespeicherten Kaufempfehlungen inForm von Recommendation-Objekten zuruck.

• GetRecommendation: Liefert eine Kaufempfehlung mit einer bestimmtenGUID zuruck.

• GetSupplierContractsForRecommendation: Liefert anhand des Zeitraums,fur den eine Kaufempfehlung erstellt werden soll, alle Liefervertrage alsListe von SupplierContract-Objekten zuruck, die in diesem Zeitraum gel-ten.

121

Page 122: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• InsertRecommendation: Fugt ein ubergebenes Recommendation-Objekt indie Datenbank ein und gibt das Ergebnis der Operation uber ein ReturnCode-Objekt zuruck. UpdateRecommendation: Aktualisiert eine bereits gespei-cherte Kaufempfehlung mit den Daten des ubergebenen Recommendation-Objekts und liefert das Ergebnis der Operaiton als ReturnCode zuruck.

Abbildung 69: Klasse RecommendationManager

Kaufempfehlungen in der Geschaftslogik Die KlasseRecommendationManager enthalt die Methoden zum Umgang mit Kaufempfeh-lungen. Die Logik zur Berechnung der Kaufempfehlungen befindet sich in denPlugins, die von anderen Programmierern bereitgestellt werden mussen. Wiediese zu implementieren sind, ist in Abschnitt uber das Pluginsystem nachzule-sen (4.2.1). Ein genetischer Algorithmus wurde als Beispiel implementiert undwird in Abschnitt 5.3.3 beschrieben. In der Geschaftslogik verbleiben daher nurdie folgenden Methoden:

• AddNewRecommendationRuft die gleichnamige Methode aus der Daten-zugriffsschicht auf und liefert deren Ergebnis zuruck.

• CalculateAvailableEnergy : Berechnet zu einer bereits erstellten Kaufemp-fehlung, wieviel Energie fur den gesamten Zeitraum benotigt wird, um denBedarf aller Kunden hundertprozentig zu decken und gibt diesen Wert zu-ruck.

• CalculateNeededEnergy : Berechnet zu einer bereits erstellten Kaufempfeh-lung, wieviel Energie fur den gesamten Zeitraum aufgrund der abgeschlos-senen Vertrage zur Verfugung steht und gibt diesen Wert zuruck.

• DeleteAllRecommendations: Ruft die gleichnamige Methode aus der Da-tenzugriffsschicht auf und liefert den Erfolg der Operation als ReturnCodezuruck.

122

Page 123: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• DeleteRecommendation: Ruft mit der ubergebenen GUID die gleichnami-ge Methode aus der Datenzugriffsschicht auf und liefert den Erfolg derOperation als ReturnCode zuruck.

• GetAllRecommendationInfos: Ruft die gleichnamige Methode aus der Da-tenzugriffsschicht auf und liefert deren Ergebnis zuruck.

• GetAllRecommendations: Ruft die gleichnamige Methode aus der Daten-zugriffsschicht auf und liefert deren Ergebnis zuruck.

• GetRecommendation: Ruft mit der ubergebenen GUID die gleichnamigeMethode aus der Datenzugriffsschicht auf und liefert deren Ergebnis zu-ruck.

• RealizeRecommendation: Ruft in der Datenbankzugriffsschicht die Metho-den zum Speichern der ubergebenen fertigen Kaufempfehlung auf undsorgt dafur, dass samtliche ausgewahlten Lieferangebote als Vertrage ab-geschlossen werden. Ein zuruckgegebener ReturnCode gibt Auskunft uberden Erfolg der Operation.

• UpdateRecommendation Ruft die gleichnamige Methode aus der Daten-zugriffsschicht auf und liefert den Erfolg der Operation als ReturnCodezuruck.

Erstellung von Kaufempfehlungen Die folgenden zwei Abschnitte beschrei-ben, wie ein Nutzer die Funktionen zum Erstellen von Kaufempfehlungen be-nutzen kann und wie der mitgelieferte Algorithmus arbeitet.

Kaufempfehlungen in der grafischen Oberflache Die grafische Ober-flache fur Kaufempfehlungen wurde als sechsteiliger Wizard realisiert. Im erstenSchritt muss aus den vorhadenen Lastprognosen (angezeigt werden der Uber-sicht halber nur die aktuellen) eine als Grundlage der Kaufempfehlung ausge-wahlt werden.

Dann wird eine Liste aller noch nicht abgeschlossenen Angebote, die teilweiseoder ganz in den Zeitraum der gewahlten Lastprognose fallen, gezeigt. (Zeitraumder Lastprognose und der zu erstellenden Kaufempfehlung sind identisch.) Zujedem Angebot kann der Nutzer auswahlen, ob es auf jeden Fall, gar nicht odernur, wenn der Algorithmus zur Berechnung der Kaufempfehlung es fur sinnvollerachtet, in die Kaufempfehlung aufgenommen werden soll.

Der dritte Schritt zeigt eine Liste aller verfugbaren Algorithmen – auch hierkam das Plugin-System zum Einsatz – fur die Kaufempfehlungserstellung anund liefert zu jedem eine kurze Erlauterung, sofern die Programmierer dieseangegeben haben.

Schritt vier dient zur Konfiguration des Algorithmus. In der Regel werden zu-satzliche, vom Benutzer einzugebende Parameter benotigt, die uber eine HTML-Oberflache innerhalb eines Browser-Fensters abgefragt werden, bevor ein Klickauf Start die Berechnung anstoßt.

Nach der Berechnung, die einige Sekunden dauern kann, werden in zweiUbersichten die vom Algorithmus zum Abschluss empfohlenen Angebote sowie

123

Page 124: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 70: Auswahl der zu verwendenden Lastprognose

Abbildung 71: Zu berucksichtigenden Liefervertrage und -angebote

124

Page 125: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 72: Auswahl des Kaufempfehlungs-Algorithmus

Abbildung 73: Konfiguration des Kaufempfehlungs-Algorithmus

125

Page 126: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

die ohnehin fur den Kaufempfehlungszeitraum bereits abgeschlossenen Vertrageangezeigt.

Abbildung 74: Ergebnis der Berechnung

Im letzten Schritt kann die Kaufempfehlung noch manuell nachbearbeitetwerden. Der Nutzer kann empfohlene Angebote aussortieren und andere, vomAlgorithmus nicht berucksichtigte Angebote, hinzufugen. Schließlich wird dieKaufempfehlung durch einen Klick auf den entsprechenden Button umgesetztund gespeichert und damit alle berucksichtigten Angebote angenommen, also inVertrage umgewandelt.

Genetischer Algorithmus fur Kaufempfehlungen Zur Generierungvon Kaufempfehlungen stellt das EIS einen als Plugin (naheres zum Pluginsys-tem siehe Abschnitt 4.2.1) genetischen Algorithmus zur Verfugung, der gemaßder Evolutionsstrategie [Rec94] versucht, ein moglichst nah am Optimum lie-gendes, heuristisches Ergebnis zu erzielen. Gegenstand der Berechnungen sinddabei Lieferangebote, die in den Zeitraum einer Kaufempfehlung fallen. Aus al-len verfugbaren Angeboten erzeugt der Algorithmus eine Menge von Angeboten,die sowohl moglichst gut den Energiebedarf fur den Zeitraum der Kaufempfeh-lung, der in der zugrundeliegenden Lastprognose ermittelt wurde, decken undgleichzeitig moglichst kostengunstig abgeschlossen werden konnen.

Vom Benutzer sind zur Konfiguration des Algorithmus vier Parameter zusetzen:

126

Page 127: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 75: Nachbearbeitung der Kaufempfehlung

Abbildung 76: Schematischer Ablauf der Evolutionsstrategie

127

Page 128: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• Die Große der initialen Population, also wie groß die Teilmenge aller mog-lichen Losungen sein soll, die zu Beginn der Berechnung erstellt wird.

• Die Anzahl der aus der Population zu erzeugenden Generationen. Sie gibtan, wie viele verschiedene Losungsvorschlage aus der initialen Populationgeneriert werden sollen. Das Erreichen der maximalen Generationenanzahlist zugleich die Abbruchbedingung fur den Algorithmus.

• Ein gewunschter Preis, der als vorzeitige Abbruchbedingung fur den Al-gorithmus benutzt wird. Unterschreitet ein Kandidat den an dieser Stelleeingetragenen Wert, so bricht der Algorithmus ab und stellt das Ergebnisdar.

• Die Option einen Mehreinkauf zuzulassen. Ist diese Checkbox gesetzt sowird der Zeitraum eines Liefervertrags, der uber den Zeitraum der Last-prognose, und damit den eigentlichen Planungszeitraum hinausgeht, nichtnegativ bewertet. Dadurch wird die Moglichkeit des Kaufes eines langfris-tigen Vertrages zu wahrscheinlich gunstigeren Konditionen ermoglicht.

Der Algorithmus lauft nach Eingabe dieser Parameter wie folgt ab:

1. Initialisierung Lieferangebote, die der Benutzer unbedingt haben mochte,werden als gesetzt behandelt und die von ihnen kompensierte Energiemen-ge vom gesamten Bedarf subtrahiert. Als initiale Population der Große nwerden n Losungskandidaten, also Listen zum Abschluss vorgeschlagenerLieferangebote, zufallig aus den optional vorzuschlagenden Angeboten er-stellt. Kandidaten, die den Energiebedarf nicht decken, werden nicht be-rucksichtigt. Nun werden nacheinander die m Generationen erstellt. Furdie erste Generation wird die initiale Population verwendet.

2. Evaluierung Fur die einzelnen Losungskandidaten der Population wirdnun die Fitness berechnet, also ein Double-Wert, der angibt, wie gut einKandidat den beiden Optimierungskriterien (Deckung des Strombedarfsund moglichst geringe Kosten) entspricht. Je kleiner der Fitnesswert da-bei ist, desto besser werden die Kriterien erfullt. Dazu werden die Ge-samtpreise der Liefervertrage errechnet und aufaddiert. Die Berechnungdes durch die Stromlieferung beigesteuerten Teils des Fitnesswertes ver-lauft etwas anders. Hier wird zunachst die durch die Liefervertrage wah-rend des Kaufempfehlungszeitraums verursachte Uberdeckung erfasst. An-schließend wird die vor und nach besagtem Zeitraum anfallende Ener-giemenge bestimmt. Beides fließt negativ in die Bewertung ein. EinzigeAusnahme bildet hierbei der Zeitraum der uber den eigentlichen PLa-nungszeitraum hinausgeht. Fur diesen kann mittels der Option Mehrkaufzulassen eine negative Berwertung ein- oder ausgestellt werden.

3. Selektion Nach der Fitnessberechung werden die Losungskandidaten sor-tiert und der fitteste Kandidat einer Liste zugewiesen, die eine engereAuswahl an Vorschlagen enthalt. Zuvor wird versucht, diesen Kandidatenweiter zu optimieren, indem Lieferangebote entfernt werden und uberpruftwird, ob nach wie vor der Energiebedarf gedeckt wird.

128

Page 129: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

4. Rekombination Nun ist die Berechnung einer Generation abgeschlossen.Fur die nachste Generation wird eine neue Population benotigt, die ausVeranderung der bestehenden hervorgeht. Dies geschieht durch Kreuzenund Mutieren der besten Kandidaten der vorhergehenden Population.

• Beim Kreuzen werden zwei Losungskandidaten einer Funktion uber-geben, die aus diesen Kandidaten zwei neue erstellt und zuruckliefert,indem die erste Halften der in diesen Kandidaten gespeicherten Ver-tragslisten in den ersten neuen Kandidaten ubertragen werden unddie zweiten Halften in den zweiten neuen.

• Beim Mutieren hingegen wird eine zufallige Anzahl an Liefervertra-gen aus der Vertragsliste durch andere ebenfalls zufalligbestimmteLiefervertrage ausgetauscht.

5. Ergebnis Dieser Kreislauf aus Evaluierung, Selektion und Rekombinati-on setzt sich fort, bis die maximale Anzahl an Generationen erreicht istoder der vom Benutzer eingegebene gewunschte Preis unterschritten wur-de. Aus der danach m Kandidaten umfassenden engeren Auswahl wirdderjenige mit dem besten, also geringsten Fitnesswert ausgewahlt und zu-ruckgegeben.

5.4 Fahrplane

Fahrplane sind das wichtigste Endprodukt, das aus dem Einsatz des Energi-einformationssystems resultiert, da ohne sie die gesamte Stromversorgung aufdem liberalisierten, nicht mehr staatsmonopolistisch organisierten Energiemarktnicht funktionieren wurde.

Allgemeines zum Fahrplankonzept Damit die Kraftwerksbetreiber, dieuber ein Regelzonen identifiziert werden, wissen, wann sie welche Energiemengenbereitstellen mussen, brauchen sie detaillierte Informationen uber den Bedarfder verschiedenen Stromanbieter, die sich den Kraftwerksbetreibern gegenuberdurch Angabe eines ihnen zugeordneten Bilanzkreises ausweisen. Dies gilt auchfur solche Stromhandler, die nur aus spekulativen Grunden kaufen und verkaufenund selbst gar keine Kunden haben, die mit Energie versorgt werden mussen.

Jeden Tag bis 14 Uhr mussen die einzelnen Stromhandler jedem von ihrenTransaktionen betroffenen Kraftwerksbetreiber sogenannte Fahrplane vorlegen,die in Viertelstundenintervallen den Stromverbrauch angeben. Dabei wird zu-satzlich bei jedem Fahrplan fur einen Kraftwerksbetreiber nach Bilanzkreisenunterschieden. Fahrplane konnen dabei gegebenenfalls auch nachtraglich korri-giert werden.

Die Fahrplane werden seit einigen Jahren im sogenannten ESS -Format zwi-schen den Betroffenen ausgetauscht. Das ESS, englisch fur ETSO SchedulingSystem wurde von der ETSO standardisiert und ist XML-basiert. Insgesamtbesteht das Fahrplanmanagement aus vier Teilen:

• der eigentlichen Fahrplannachricht (Schedule Planning Message),

• der Empfangsbestatigung (Acknowledgement Message),

129

Page 130: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• der Fehlernachricht (Anomaly Report) und

• der endgultigen Fahrplanbestatigung (Confirmation Report).

Implementierte Komponenten im EIS Von den oben genannten vier Be-standteilen des Fahrplanmanagements wurde im EIS nur die wichtigste verwirk-licht, namlich die Fahrplannachricht. Die anderen drei XML-Nachrichten wur-den aus Zeitgrunden nicht berucksichtigt. Die hier beschriebenen Funktionenentsprechen den Anwendungsfallen 64 bis 71 aus dem Zwischenbericht.

Fahrplane konnen von ausreichend mit Rechten ausgestatteten Nutzern er-stellt und geloscht, jedoch nicht bearbeitet werden werden. Falls ein Fahrplansich im Nachhinein als unvollstandig herausstellen sollte – etwa weil kurzfristigneue Liefervertrage hinzugekommen sind –, muss ein komplett neuer Fahrplanfur den betreffenden Tag erstellt werden, der automatisch eine neue Versions-nummer erhalt. Eine manuelle Bearbeitung von Fahrplanen wurde nicht erlaubt,da das Format sonst zu leicht mit Fehlern durchsetzt wurde. Alle benotigten In-formationen, also Lieferanten und Liefervertrage, sind zur Zeit der Erstellungeines Fahrplans bereits im System gespeichert und werden dementsprechendautomatisch extrahiert und zur Berechnung der Strommengen herangezogen.

Die im EIS implementierte Version der Fahrplannachricht entspricht Version2, Release 3, die zu Beginn der Programmierarbeiten (Februar 2006) aktuell war.Inzwischen (Juli 2006) wurde Version 3, Release 0 veroffentlicht, die im Rahmender Projektgruppe aber keine Berucksichtigung mehr finden konnte.

Fahrplane als Datentyp Ein Fahrplan besteht aus zahlreichen administra-tiven Angaben, die etwa die Version des Fahrplans oder seinen Empfanger bein-halten. Diese Informationen sind in der Klasse Schedule gespeichert. Außerdemexistiert pro Fahrplan eine beliebige Anzahl an Zeitschemata. Jedes Schema ent-halt neben weiteren administrativen Daten 96 Viertelstundenintervalle mit Ver-brauchswerten, die einen kompletten Tag abdecken. Diese Datenstruktur wirduber die Klasse ScheduleTimeSeries reprasentiert, die zur Realisierung der 1-n-Beziehung von der Klasse Schedule referenziert wird. Abbildung 77 zeigt eineUbersicht uber beide Klassen.

Im folgenden werden die fur Fahrplane benotigten administrativen Datennaher erlautert und beschrieben, wie sie vom System behandelt werden. Ei-ne ausfuhrliche Beschreibung findet sich in den Dokumenten der ETSO (siehe[Ope03]).

• Attribute eines Fahrplans:

– ClassificationType: Wird gesetzt, um die Art des Fahrplans gegenuberden anderen ETSO-Teilnehmern zu markieren. Wird stets auf denCode fur Energieaustausch gesetzt.

– Day: Der Tag, fur den der Fahrplan gilt.

– Filename: Der von der ETSO vorgegebene Dateiname, der ebenfallsin der XML-Datei gespeichert wird.

– Id: Eine eindeutige Identifikationsnummer des Fahrplans. Das Systemerzeugt hierzu eine GUID.

130

Page 131: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 77: Klassen Schedule und ScheduleTimeSeries

– MessageDateAndTime: Das Datum, an dem der Fahrplan erstelltwurde.

– MessageId: Eine eindeutige Identifikationsnummer des Fahrplans, diein allen Versionen dieses Fahrplans gleich bleibt. Das System erzeugthierzu eine GUID.

– MessageType: Der Typ des Fahrplans. Wird vom System auf denvordefinierten Wert fur bilanzwirksame Fahrplane gesetzt.

– MessageVersion: Die Version des Fahrplans. Wird vom System alsaufsteigende Reihe, beginnend mit 1, behandelt.

– ProcessType: Der Vorgang, der durch den Fahrplan beschrieben wird.Das System benutzt hier stets den Wert fur zukunftige, so genannteDay-ahead -Fahrplane.

– ReceiverCodingScheme: Gibt an, wie die ID des Empfangers codiertist. Das System zeigt hier eine Codierung als EIC an.

– ReceiverId: Die eindeutige Identifikation des Empfangers.

– ReceiverRole: Zeigt uber einen ETSO-Code an, welche Funktion derEmpfanger des Fahrplans einnimmt.

– SenderCodingScheme: Gibt an, wie die ID des Senders codiert ist.Das System zeigt hier eine Codierung als EIC an.

131

Page 132: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

– SenderId: Die eindeutige Identifikation des Senders.

– SenderRole: Zeigt uber einen ETSO-Code an, welche Funktion derSender des Fahrplans einnimmt.

– Timespan: Die genaue Zeitspanne, in der der Fahrplan gilt.

• Attribute eines Fahrplanzeitschemas:

– AccountingAreaIn: Enthalt den EIC des Bilanzkreises, in den derStrom geliefert wird.

– AccountingAreaInCodingScheme: Enthalt das Schema, mit dem derBilanzkreis des Stromempfangers in der XML-Datei codiert ist. Wirdvom System auf die Konstante fur EICs gesetzt.

– AccountingAreaOut: Enthalt den EIC des Bilanzkreises, aus dem derStrom transferiert wird.

– AccountingAreaOutCodingScheme: Enthalt das Schema, mit dem derBilanzkreis des Stromsenders in der XML-Datei codiert ist. Wird vomSystem auf die Konstante fur EICs gesetzt.

– Aggregation: Zeigt an, fur welchen Bereich die Energietransfers ag-gregiert sind. Wird vom Programm stets auf den ESTO-Code furRegelzonen gesetzt.

– Agreement: Wird in der vorhandenen Implementierung nicht benotigtund daher nicht gesetzt.

– Amounts: Die eigentliche Zeitreihe als Array von 96 Werten, einerfur jede Viertelstunde des Tages. Hier werden die vom Fahrplaner-stellungsalgorithmus ermittelten Werte gespeichert.

– BusinessType: Gibt die Art des Geschafts an. Wird vom Programmauf den Wert fur Energieverbrauch gesetzt, da mit der geliefertenEnergie Kunden bedient werden.

– ContractType: Gibt die Art der Lieferung an. Die vom System gene-rierten Fahrplane werden dabei stets als Transaktionen fur einen Tagklassifiziert.

– ControlAreaIn: Enthalt den EIC des Bilanzkreises, in den der Stromgeliefert wird.

– ControlAreaInCodingScheme: Enthalt das Schema, mit dem der Bi-lanzkreis des Stromempfangers in der XML-Datei codiert ist. Wirdvom System auf die Konstante fur EICs gesetzt.

– ControlAreaOut: Enthalt den EIC des Bilanzkreises, aus dem derStrom transferiert wird.

– ControlAreaOutCodingScheme: Enthalt das Schema, mit dem der Bi-lanzkreis des Stromsenders in der XML-Datei codiert ist. Wird vomSystem auf die Konstante fur EICs gesetzt.

– Id: Eine eindeutige GUID, mit der dieses Zeitschema identifiziert wer-den.

– MeasurementUnit: Gibt die Maßeinheit fur die Energie in den Zeitin-tervallen an. Wird auf den ETSO-Standardwert fur Megawattstundengesetzt.

132

Page 133: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

– MeteringPoint: Wird in der vorhandenen Implementierung nicht be-notigt und daher nicht gesetzt.

– MeteringPointCodingScheme: Wird in der vorhandenen Implemen-tierung nicht benotigt und daher nicht gesetzt.

– Product: Die Art der gelieferten Energie. Wird auf den ETSO-Codefur aktive Energie gesetzt.

– Resolution: Zeigt die Dauer der Zeitintervalle. Dieser Wert wird aufdie ETSO-Konstante fur 15-minutige Intervalle gesetzt.

– Schedule: Enthalt eine Referenz auf das zugrunde liegende Schedule-Objekt.

– TimeInterval: Gibt an, wie lange die einzelnen Zeitintervalle des Sche-mas dauern. Wird vom Programm auf den ETSO-Standardwert von15 Minuten gesetzt.

– TimeSeriesIdentification: Die eindeutige Identifikationsnummer desZeitschemas. Bleibt bei verschiedenen Versionen des Zeitschemas gleich.

– Version: Die Version des Zeitschemas. Wird vom System als laufendeNummer, beginnend mit 1, behandelt.

Abbildung 78: Klasse ScheduleDAL

Fahrplane im Datenzugriff Der Datenzugriff erfolgt uber die KlasseScheduleDAL. Sie schreibt und liest Fahrplane in die bzw. aus den zugehorigenDatenbanktabellen Schedule und ScheduleTimeSeries, die jeweils die gleich-namige Datenhaltungsklasse abdecken. Die einzelnen Methoden sind:

• CalculateMessageVersion: Berechnet anhand der Anzahl der in der Da-tenbank vorhandenen Eintrage ein und derselben Fahrplannachricht dieVersion der zu erzeugenden nachsten Fahrplanversion und liefert sie zu-ruck.

133

Page 134: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• CalculateTimeSeriesVersion: Berechnet anhand der Anzahl der in der Da-tenbank vorhandenen Eintrage ein und desselben Fahrplanzeitschemas dieVersion der zu erzeugenden nachsten Zeitschemaversion und liefert sie zu-ruck.

• CountSchedulesForDay : Zahlt die fur einen bestimmten Tag erzeugtenFahrplane (Anzahl Dateien) und liefert das Ergebnis zuruck.

• CreateScheduleFromDataRow : Erzeugt aus einem aus der Datenbank aus-gelesenen Datensatz ein neues Schedule-Objekt mit zugehorigenScheduleTimeSeries-Instanzen und liefert es zuruck.

• DeleteAllSchedules: Loscht alle bislang erzeugten Fahrplane aus der Da-tenbank und gibt als Ergebnis ein ReturnCode-Objekt zuruck, das denAusgang der Operation beschreibt. Die zugehorigen XML-Dateien werdennicht geloscht, da der Nutzer diese speichern kann, wo er mochte, und dieseOrte dem System nicht bekannt sind.

• DeleteSchedule: Loscht anhand einer ubergebenen GUID einen bestimm-ten Fahrplan aus der Datenbank und gibt als Ergebnis ein ReturnCode-Objekt zuruck, das den Ausgang der Operation beschreibt. Die zugeho-rigen XML-Dateien werden nicht geloscht, da der Nutzer diese speichernkann, wo er mochte, und diese Orte dem System nicht bekannt sind.

• DeleteSchedulesForDay : Loscht alle fur einen bestimmten Tag erzeugtenFahrplane aus der Datenbank und gibt als Ergebnis ein ReturnCode-Objekt zuruck, das den Ausgang der Operation beschreibt. Die zugeho-rigen XML-Dateien werden nicht geloscht, da der Nutzer diese speichernkann, wo er mochte, und diese Orte dem System nicht bekannt sind.

• GetAllSchedules: Liest alle vorhandenen Fahrplandatensatze aus der Da-tenbank aus und liefert sie als Liste von Schedule-Objekten zuruck.

• GetMessageId : Bekommt ein DateTime-Objekt sowie einen EIC als Emp-fangerkennung ubergeben und liefert anhand dieser Daten die ID der Fahr-plannachricht (nicht die des Fahrplandatensatzes) zuruck, die an diesemTag fur den ubergebenen Empfanger gilt.

• GetSchedule: Liefert aus der Datenbank ein Schedule-Objekt mit einerbestimmten ID zuruck.

• GetScheduleTimeSeriesForSchedule: Liest die Datensatze von Fahrplan-zeitschemata, die zu einem bestimmten Fahrplan gehoren, aus der Da-tenbank aus und gibt sie als Liste von ScheduleTimeSeries-Objektenzuruck.

• InsertSchedule: Bekommt ein Schedule-Objekt ubergeben, fugt es in dieDatenbank ein und gibt den Erfolg der Operation als ReturnCode-Objektcodiert zuruck.

• UpdateSchedule: Bekommt ein Schedule-Objekt ubergeben, aktualisiertmit seinen Daten den Datensatz mit derselben ID und gibt den Erfolg derOperation als ReturnCode-Objekt codiert zuruck.

134

Page 135: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 79: Klasse ScheduleManager

Fahrplane in der Geschaftslogik Die Geschaftslogik fur Fahrplane unddamit auch die Erstellung von Fahrplanen, eine der Hauptfunktionen des Pro-gramms, befindet sich in der Klasse ScheduleManager. Ein Uberblick uber ih-re Methoden ist in Abbildung 79 zu sehen. Die Methoden, deren Name mitWrite beginnt, dienen allesamt dazu, die erstellten Schedule-Objekte in XML-Fahrplandateien gemaß ESS-Format zu transformieren. Die Fahrplanerstellunglauft dabei wie folgt ab:

• Der Benutzer muss vor der Erstellung zunachst eingeben, welchen Bilanz-kreis er durch seine Firma vertritt und fur welchen Netzbetreiber, alsofur welche Regelzone der Fahrplan ist. Ein Datum, fur das der Fahrplangelten soll, ist ebenfalls notwendig.

• Anschließend beginnt der Erstellungsprozess. Es wird dabei eine XML-Datei gemaß ESS erstellt, die alle Transaktionen enthalt, die zwecks Ver-sorgung der Stromkunden des Handlers anfallen. In der Regel handelt essich um Lieferungen in die Regelzone des Handlers, die von anderen Bi-lanzkreisen, also Stromanbietern, kommen. Es ist aber auch moglich, dassdie Lieferungen aus der Regelzone des Handlers kommen, wenn Uber-schußenergie veraußert wird. Fur jede durch Liefervertrage oder EEX-Lieferungen auftretende Kombinationen von Regelzonen und Bilanzkrei-sen, die an Transaktionen beteiligt sind, wird ein eigenes Zeitschema imFahrplan angelegt. Sind noch andere Regelzonen als die des Handlers an

135

Page 136: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

den Transaktionen beteiligt, wird fur jede dieser Regelzonen eine weitereFahrplandatei in XML erzeugt, die dann jeweils die Transaktionen zwi-schen dem Handler und der betroffenen Regelzone auflistet.

• Um diese Dateien erstellen zu konnen, werden zunachst uber die MethodenGetSupplierContractsForSchedule und GetEexDeliveriesForSchedulesamtliche abgeschlossenen Liefervertrage und EEX-Lieferungen ausgele-sen, die an dem Tag, fur den der Fahrplan gemacht wird, gelten.

• Anschließend werden Lieferungen und Vertrage zuerst nach Regelzonenund dann innerhalb dieser Aufteilung nach Bilanzkreisen geordnet, so-dass die jeweiligen Listen bereits in der richtigen Sortierung fur die ver-schiedenen zu erstellenden Fahrplanobjekte und zugehorigen Zeitreihenvorliegen. Das Sortieren nach Regelzonen geschieht uber die MethodenGetContractsForControlArea und GetDeliveriesForControlArea. DieSortierung nach Bilanzkreisen erfolgt durch Aufruf von SortContractsByAccountingAreas und SortDeliveriesByAccountingAreas. Zuvor wer-den Listen aller beteiligten Regelzonen und Bilanzkreise uber die Metho-den GetAccountingAreasInvolved und GetControlAreasInvolved er-stellt.

• Nun wird fur jede Regelzone uber die Methode ein neues Schedule-Objekterzeugt und mit den von der ETSO vorgegebenen administrativen Datengefullt.

• Dann wird fur jeden Bilanzkreis, der in der sortieren Liste fur diese Re-gelzone aufgefuhrt ist, ein Zeitschema als ScheduleTimeSeries-Objekterstellt und gefullt.

• Um die Verbrauchsmengen je Zeitreihe zu berechnen, wird die MethodeAggregateAmounts aufgerufen. Hier wird zunachst zu jedem Liefervertraguberpruft, ob noch aktuelle Storungen dazu existieren, deren Menge dannggf. von der zu liefernden Menge abgezogen wird. Dann werden fur alleEEX-Lieferungen und Liefervertrage, die zu ein und derselben Kombina-tion von Bilanzkreisen und Regelzonen gehoren, die Liefermengen fur alleViertelstundenintervalle aufaddiert.

• Falls dabei durch Verkaufe an die EEX negative Mengen zustande kommt,was uber die Methode HasNegativeAmounts abgefragt wird, mussen dienegativen Werte in eine eigene Zeitreihe mit vertauschten Regelzonen undBilanzkreisen und umgekehrten Vorzeichen ausgelagert werden. Das liegtdaran, dass die ETSO im ESS-Format nur nicht-negative Energiewer-te vorsieht. Das Aufteilen des Zeitschemas geschieht uber die MethodeSplitTimeSeries.

• Damit ist die inhaltliche Erstellung der Fahrplane abgeschlossen, und dieerzeugten Objekte werden uber Aufrufe der verschiedenen Write-Methodenin ESS-konforme XML-Dateien transformiert. Die Daten der Fahrplanewerden in der Datenbank gespeichert.

Die ubrigen Methoden der Klasse ScheduleManager funktionieren wie folgt:

136

Page 137: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• DeleteAllSchedules: Ruft die gleichnamige Methode der KlasseScheduleDAL auf gibt als Ergebnis ein ReturnCode-Objekt zuruck, dasden Ausgang der Operation beschreibt.

• DeleteSchedulesForDay : Ruft die gleichnamige Methode der KlasseScheduleDAL auf gibt als Ergebnis ein ReturnCode-Objekt zuruck, dasden Ausgang der Operation beschreibt.

Abbildung 80: Grafische Oberflache fur Fahrplane

Fahrplane in der Benutzeroberflache Zur Fahrplanverwaltung existiertein dreigeteiltes Panel (siehe Abbildung 80). Oben werden Fahrplane erstellt, in-dem der Tag, fur den der Fahrplan berechnet werden soll, sowie Bilanzkreis undRegelzone des Handlers, der das System einsetzt, ausgewahlt werden. Schließ-lich wird uber einen Dialog noch der Ort bestimmt, an dem die fertigen XML-Dateien zu speichern sind.

Im mittleren Teil kann der Nutzer sich links fur beliebige Verzeichnisse aufdem Rechner eine Liste von Fahrplandateien anzeigen lassen. Wahlt man einender aufgefuhrten Dateinamen an, wird in einem Fenster recht daneben die zuge-horige XML-Datei angezeigt. Dazu wurde das von Windows.Forms bereitgestell-te WebBrowser-Control benutzt, das als Parameter ubergebene XML-Dateienautomatisch formatiert darstellt.

137

Page 138: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Unten besteht die Moglichkeit, nach Eingabe eines Datums die Fahrplaneeines Tages oder gleich alle vorhandenen Fahrplane zu loschen. Dazu werdenbei Bestatigung der Sicherheitsabfrage die entsprechenden Methoden aus demService Access Layer aufgerufen.

138

Page 139: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

6 Tests

Um die volle Funktionsfahigkeit sowie vor allem die Korrektheit des Programmssicherzustellen, wurden umfangreiche Testmaßnahmen unternommen. Zum einenwurden Unittests zum Testen einzelner Klassen mit ihren Funktionen verwen-det, um wahrend der Entwicklung Fehler zu finden und eine Basis fur Tests nachCodeanderungen zu haben. Des Weiteren wurde am Ende ein umfangreicherSystemtest durchgefuhrt, bei dem die Oberflache von mehreren Testern unter-sucht wurde. Die dabei gefundenen Bugs wurden protokolliert und anschließendbehoben. Im Anschluss wurden die Installationsroutinen getestet, indem dasProgramm auf verschiedene Rechnerkonfigurationen installiert wurde. Um Aus-sagen uber die Skalierbarkeit sowie die Performanz der Anwendung zu treffen,wurden Lasttests durchgefuhrt.

6.1 Datenbankzugriff

Die korrekte und zuverlassige Kommunikation mit der Datenbank sicherzustel-len war einer der wichtigsten Aspekte bei der Programmierung des Systems. ImGegensatz zu normalem Programmcode werden Syntaxfehler oder falsche Re-ferenzen nicht automatisch wahrend der Eingabe oder beim Kompilieren ange-zeigt, sondern treten erst beim Ausfuhren der entsprechenden Datenbankabfra-gen auf. Um zu gewahrleisten, dass die einzelnen Funktionen auch das tun, wasvon ihnen erwartet wird, wurde das Testprojekt DALTests erstellt, in dem furjede Klasse der Datenbankzugriffsschicht eine Testklasse als Unittest implemen-tiert wurde, die mit Beispieldaten die Funktionen der zugrundeliegenden Klasseaufruft und deren Ergebnis uberpruft. In der Regel werden Anlegen, Auslesen,Bearbeiten und Loschen von Objekten eines Typs getestet. Das Testprojekt wirddazu mit allen Klassen in Visual Studio ausgefuhrt und liefert Protokolle uberErfolg oder Fehlschlag des Testlaufs zuruck. Im folgenden wird als Beispiel furdie allgemeine Vorgehensweise der Testcode der Klasse CustomerDALTest, diedie Datenbankfunktionen zum Umgang mit Kunden-Objekten testet, erlautert.

Zunachst wird die Testklasse als solche deklariert und der zugehorige Test-context der aufrufenden Testumgebung zur Verfugung 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 Vor-bereitung des eigentlichen Tests notig ist, in diesem Fall das Anlegen und Spei-chern einiger Hilfsobjekte, die spater benotigt werden. In der Methode MyTest-Cleanup steht Code, der nach dem Ausfuhren des Tests zum ”Aufraumen“ be-notigt wird – in diesem Fall mussen die Hilfsobjekte wieder aus der Datenbankgeloscht werden. Das Aufraumen sieht hier wie folgt aus:

139

Page 140: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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 Funkti-onstests einer Datenzugriffsklasse werden jeweils in einer Testmethode zusam-mengefasst.

[TestMethod()]public void CustomerTest() {

Nun wird zunachst ein fiktiver Testkunde erzeugt, mit beliebigen Daten ge-fullt und in der Datenbank abgelegt. Der Assert-Befehl am Ende uberpruft, wiedies auch in anderen Testframeworks der Fall ist, ob die aufgerufende Metho-de zum Einfugen des Datensatzes einen bestimmten Wert, in diesem Fall truefur erfolgreiches Speichern, zuruckliefert. Andernfalls schlagt der Test fehl undterminiert.

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 Einfugen folgt der Test der Bearbeitungsfunktion. Dazu werdeneinige Werte des Kunden verandert und anschließend die geeignete Funktion

140

Page 141: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

zur Anderung eines Datensatzes aufgerufen und ihr Ergebnis wieder mit Assertuberwacht.

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 Kundenda-tensatze uberpruft. Zunachst das Auslesen uber die dem soeben eingefugtenObjekte zugewiesene GUID. Direkt danach wird uber Vergleiche der zahlrei-chen Attribute des ausgelesenen mit dem ursprunglichen Objekt sichergestellt,dass die richtigen Werte aus der Datenbank extrahiert wurden. Weicht ein Wertvon den Erwartungen ab, schlagt 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 fur die anderen Auslesemethoden, die Listen mit zahl-reichen Objekten zuruckliefern, wiederholt, wobei vor dem Abgleich zunachstaus allen Elementen der Liste uber die GUID das richtige herausgesucht wird.Uberpruft wird außerdem, ob das erwartete Objekt uberhaupt in der Liste vor-handen 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

Page 142: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

}}Assert.IsTrue(found);

Nachdem alle Auslesemethoden getestet sind, erfolgt schließlich noch dieLoschung des Kundenobjektes, deren Erfolg ebenfalls uberwacht wird, womitder Test beendet ist.

Assert.IsTrue(CustomerDAL.DeleteCustomer(c.Id));

Durch diese Vorgehensweise ist eine hohe Codeabdeckung in den getestetenKlassen gewahrleistet, da alle vorhandenen Methoden zum Anlegen, Auslesen,Bearbeiten und Loschen mindestens einmal aufgerufen werden. An dieser Stel-le konnte man einwenden, dass nur mit korrekten Werten gearbeitet wird undnicht mit ungultigen Eingaben, die von der Datenzugriffsklasse abgefangen wer-den mussten. Dies Problem stellt sich hier allerdings nicht, weil samtliche Da-ten clientseitig auf ihre Gultigkeit uberpruft werden, so dass fehlerhafte Datengar nicht in diese Architekturschicht gelangen, sondern schon fruher zuruck-gewiesen werden. Damit entfallt auch die Notwendigkeit der Uberwachung indieser Schicht. Allerdings musste, sobald Plugins zum Zugriff von außen aufden Webservice bereitgestellt werden, was in dieser Version nicht der Fall ist,zusatzlicher Code zur Validierung von außen gelieferter Daten in die Geschafts-logik eingebaut werden, weil dann die GUI-seitige Validierung nicht griffe undkorrekte Werte nicht sichergestellt werden konnten.

6.2 Webservicetests

Zusatzlich zu den Tests der Datenzugriffslogik wurden Testfalle fur die Metho-den des Webservice entwickelt, die auch als Grundlage fur die Lasttests dienen(vgl. Abschnitt 6.5). Sie wurden ebenfalls als Unittests implementiert, die jeweilsMethoden, die funktional zusammengehoren — also etwa solche zur Tarifverwal-tung —, uberprufen. Dabei werden nahezu alle Funktionen des Webservices ein-mal oder mehrfach aufgerufen, um eine hohe Codeabdeckung zu gewahrleisten.Ihre Ergebnisse werden uberpruft, sofern es sich nicht um reine Datenbankanfra-gen handelt, die bereits in den Tests der Datenzugriffslogik uberpruft wurden.In den Testfallen werden typische Handlungsablaufe durchgespielt wie beispiels-weise das Anlegen eines Kunden mit anschließender Zuweisung von Vertragenund Lastprofilen. Der Code fur diesen Test der Webservicemethoden zum An-legen von Kundenvertragen wird hier als Beispiel und zum Vergleich mit demCode der Datenzugriffstests vorgestellt.

Anfangs der Methode wird ein Kundenvertrag uber den Aufruf von Hel-per CreateCustomerContract generiert und alle zugehorigen Objekte wie Regel-zone oder Bilanzkreis angelegt.

[TestMethod]public void CustomerContractTest() {

ReturnCode rc;

142

Page 143: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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 zugehorigen Objekte, die uber Refenzen mit dem imMittelpunkt stehenden Kundenvertrag verbunden sind, eingefugt, damit es nichtzu Konflikten in der Datenbank kommt. Dies sind ein Bilanzkreis, eine Re-gelzone, ein Kunde, ein Systemnutzer, ein Lastprofil und ein Tarif. Uber dasUberprufen des rc genannten ReturnCode-Objekts wird sichergestellt, dass dieMethoden erfolgreich ausgefuhrt 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 eingefugt.

rc = target.AddNewCustomerContract(cc);Assert.IsTrue(rc == ReturnCode.OK);

Nun werden Abfragen zum Auslesen von Kunden und -vertragen durchge-fuhrt, indem die verschiedenen dazu bereitgestellten Methoden (Auslesen allerKundenvertrage, aller Vertrage eines Kunden, eines bestimmten Vertrages unddes Kunden, der einen bestimmten Vertrag hat) aufgerufen werden, und sicher-gestellt, dass Daten ubermittelt wurden. Eine genaue Uberprufung der Ergebnis-se wie bei den Datenzugriffstests erfolgt nicht, da in jenen bereits sichergestelltwurde, dass die Daten richtig ausgelesen werden. Es geht hier nur noch darumzu kontrollieren, ob die Daten auch uber den Webservice zuruckkommen.

CustomerContract[] ccs = target.GetAllCustomerContracts();Assert.IsTrue(ccs.Length > 0);

ccs = target.GetCustomerContractsForCustomer(cc.Customer);Assert.IsTrue(ccs.Length > 0);

143

Page 144: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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 Uberprufungen erfolgreich, wird der Kundenvertrag wieder ge-loscht und abschließend gewissermaßen aufgeraumt, das heißt, alle eigens furdiesen Vertrag angelegten Objekte werden ebenfalls aus den Datenbestandenentfernt. Die Ergebnisse dieser Funktionsaufrufe werden wieder uberpruft. Be-zeugen die Ergebniscodes den Erfolg dieser Operationen, ist der Test erfolgreichbeendet.

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 sicherzustel-len (vgl. 3.3.1), wurde das gesamte System einem manuellen Test unterzogen.Dabei wurden alle Masken des Programms untersucht und alle Funktionen aufKorrektheit uberpruft. Diese Tests waren sehr umfangreich und wurden vonmehreren Testern durchgefuhrt. Alle Tests wurden dabei protokolliert, so dassgefundene Fehler gleich in Beziehung zu Korrekturmaßnahmen gesetzt werdenkonnten. Im folgenden soll kurz der Aufbau der Protokolldokumentation vorge-stellt werden.

Jedes Testdokument spezifziert zunachst das Datum der Tests sowie denNamen des Testers. Unter dem Punkt Leistungsmerkmal ist beschrieben, welcheMaske bzw. welche Funktionen untersucht wurden. Außerdem wird noch dieSystemumgebung erfasst.

Ein einzelner Testfall hat dabei folgende Attribute:

144

Page 145: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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 erwar-tet.

• Ergebnis: Die Spalte enhalt das Ergebnis. Es sind folgende Werte verwen-det:

– + bedeutet, dass der Test erfolgreich war.

– 0 bedeutet, dass der Test war Einschrankungen erfolgreich war. DieseEinschrankungen sind dann in den Anmerkungen beschrieben.

– - bedeutet, dass der Test nicht erfolgreich war. Die aufgetretenenFehler sind dann in den Anmerkungen beschrieben.

• Fehler/Anmerkungen: Freitext fur Bemerkungen

Alle Protokolle zu Tests und Fehlerkorrekturen sind als Anhang angefugt.

6.4 Installationstest

Neben dem Systemtest wurde auch ein Installationstest durchgefuhrt. Dabeiwurden die von der Projektgruppe erstellten Setup-Programme auf verschie-denen Rechnern ausgefuhrt. Im Anschluss wurde bei einer kurzen manuellenUberprufung getestet, ob alle erorderlichen Komponenten einwandfrei auf demZielsystem installiert wurden und ob alle Funktionen ausfuhrbar waren. Die fol-gende Tabelle listet die Rechner auf, auf denen wir die Software getestet haben.Auf allen Systemen lief die Installation ohne Probleme.

Rechner Betriebssystem Typ

Intel P4; 2,6 GHz; 1 GB RAM Windows XP SP2 ClientIntel P4; 3,2 GHz; 1,5 GB RAM Windows 2003 Server ClientIntel P4; 3,2 GHz; 1,5 GB RAM Windows 2003 Server ServerAMD Athlon 64; 3,2 GHz; 1 GB RAM Windows XP SP2 ClientIntel Centrio; 1,5 GHz; 1 GB RAM Windows XP SP2 ClientDual Xeon; 3,4 GHz; 4 GB RAM Windows 2003 Server

6.5 Lasttests

Die Lasttests dienen unter anderem dazu, die Skalierbarkeit des Systems imMehrbenutzerbetrieb (vgl. nicht-funktionale Anforderungen, Abschnitt 3.3.6)zu uberprufen, und benutzen die Testsuite fur die Webservicetests. MicrosoftVisual Studio bietet standardisierte Vorlagen fur Lasttests an, mit deren Hilfesich Testszenarien durchspielen lassen. So ist es moglich, einen Lasttest uber ver-schiedene Zeitraume durchzufuhren, konstante oder variable Benutzerzahlen zusimulieren oder das Benutzerverhalten etwa durch Denkpausen zu beeinflussen.Auch konnen die einzelnen Testmethoden zu einem Testmix zusammengefasstwerden, in dem ein benutzerdefinierter Prozentsatz von Aufrufen auf jeweils eineMethode entfallt.

145

Page 146: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Diese Lasttests wurden in verschiedenen Konfigurationen durchgefuhrt undbescheinigten dem System eine uberaus akzeptable Performanz. Protokolliertwurden seitens der Entwicklungsumgebung jeweils zahlreiche Werte fur das Tes-taggregat wie auch fur die einzelnen Methodenaufrufe. Die Testresultate sind so-wohl in tabellarischer als auch in grafischer Form verfugbar. Im folgenden wirddie Arbeitsweise des Lasttests an einem Beispiel vorgefuhrt.

Abbildung 81: Testprotokoll nach Lasttest in Visual Studio

Abbildung 81 zeigt ein Testprotokoll, nachdem zuvor ein sechsminutigerLasttest durchgefuhrt worden war, in dem die Nutzerhandlungen zur Kunden-und zur Lieferantenverwaltung simuliert wurden. Die gerade (rote) Linie imGraphen weist die Anzahl der Nutzer aus, die gleichzeitig am System arbei-ten. In diesem Fall lag sie bei konstant 30 Nutzern. Zwischen den verschiedenenAktionen der Nutzer war eine Nachdenkzeit von zehn Sekunden vorgegebenworden (hier nicht zu sehen). Die in stark ausschlagende (grune) Linie symboli-siert die jeweils pro Sekunde durchgefuhrten Testmethodenaufrufe. Die unterste(blaue) Linie steht fur die durchschnittliche Dauer eines Testaufrufs in Sekun-den. Zahlreiche andere Werte sind noch protokolliert, so zum Beispiel die dreieben genannten Werte nochmals deaggregiert fur jede einzelne Testmethode.Festgehalten wird zu jedem dieser Werte der minimale, maximale, durchschnitt-liche und letzte aufgetretene Wert. So ist zum Beispiel fur die Anzahl der Testspro Sekunde zu erkennen, dass die maximale Anzahl bei sechs Aufrufen lag unddie durchschnittliche Anzahl knapp unter dreien. In dem rechten oberen Fenstersind fur die jeweils ausgewahlte Große die Anzahlen der Tests fur die einzelnen,hier funfsekundigen Zeitintervalle abgebildet.

Diese sehr detaillierte Art der Protokollierung durch Visual Studio erlaubtdeutliche Ruckschlusse auf die Leistungsfahigkeit des Systems. So lasst sich an-hand der 2, 73 durchschnittlich pro Sekunde durchgefuhrten Testlaufe ablesen,dass der Webservice die anfallenden Daten uberaus schnell ubertragt und dieDatenbearbeitung durch das System insgesamt sehr effizient geschieht. Die zu-

146

Page 147: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

grunde liegenden Testmethoden zu Kunden- und Lieferantenverwaltung enthiel-ten namlich nicht nur einzelne Methodenaufrufe aus dem Webservice, sondernein komplettes Benutzungsszenario mit verschiedenen Aufrufen zum Anlegen,Bearbeiten, Loschen und vor allem Auslesen. Zum Zeitpunkt des hier vorgestell-ten Testlaufs etwa befanden sich gut tausend Kunden in der Datenbank, die fureinen Aufruf der Kundenverwaltungstestmethode einmal komplett und mehr-fach nach bestimmten Kriterien ausgelesen und ubertragen werden mussten.Hinzu kommt ein neu erzeugter sowie ein zu loschender Kunde und 29 andereangemeldete Nutzer. Man kann also sagen, dass die Kommunikation innerhalbder Client-Server-Anwendung effizient ablauft und auch großere Benutzermen-gen kein Problem fur das System darstellen. Andere Testlaufe bestatigten denhier gewonnenen Eindruck.

147

Page 148: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

7 Vorgehensmodell

Die Erstellung einer komplexen Software durch eine relativ große Gruppe mitimmerhin elf Teilnehmern erfordert ein strukturiertes Vorgehensmodell. Die we-sentlichen Grunde sind, dass dadurch ein koordinierter Entwicklungsprozess inder Gruppe moglich wird und niemand den Uberblick uber den Projektstand ver-liert. Allerdings stießen etablierte Vorgehensmodelle wie das Wasserfallmodelloder das V-Modell auf wenig Gegenliebe in der Projektgruppe, da die anderwei-tig mit diesen Methodiken gemachten Erfahrungen – etwa im Softwareprojektim Grundstudium – nicht sehr positiv ausgefallen waren. Insbesondere wurdeein System gewunscht, das flexibler war und alle Ebenen der Entwicklung bishin zur Aufgabenzuteilung an die einzelnen Mitglieder umfasste. Hier fand sichdas noch recht junge Scrum-Modell als Losung. Erfahrungen mit diesem Modellhatte noch niemand in der Gruppe gemacht, so dass es sich zugleich anbot, eseinmal unter realen Bedingungen zu testen, weil Projektgruppen nicht nur dazudienen, moglichst schnell moglichst viel zu programmieren, sondern auch da-zu, neue Erfahrungen zu sammeln. In den folgenden Abschnitten wird zunachstbeschrieben, was Scrum ist und wie es in der Projektgruppe eingesetzt wurde.

7.1 Scrum - Entwicklungsmodell fur das EIS

7.1.1 Agile Softwareentwicklung

Auf Flexibilitat ausgerichtete Softwareentwicklung ist eine Form des Software-entwicklungsprozesses und zeichnet sich durch vergleichsweise geringen buro-kratischen Aufwand aus. Damit bildet die so genannte agile Softwareentwick-lung ein Gegengewicht zu den herkommlichen Entwicklungsprozessen wie demV-Modell und dem Wasserfallmodell, bei welchen der hohe burokratische Auf-wand fur die Mitarbeiter eines Softwareentwicklungsteams haufig als hinderlichangesehen wird.

Je nach Betrachtungsquerschnitt lasst sich agile Softwareentwicklung auf ver-schiedene Ebenen zergliedern, die im folgenden Beschrieben und in Abbildung82 dargestellt werden. Naheres zu den Grundsatzen der agilen Softwareentwick-lung, die im folgenden umrissen werden, findet sich unter anderem im Manifestofor Agile Software Development [BBa01], im Artikel Agile Processes [Mar02] vonRobert C. Martin oder im Artikel The New Methodology [BBa01] von MartinFowler.

Agile Werte sind die unterste Ebene und bilden das Fundament agiler Softwa-reentwicklung und zielen auf soziale Kompetenzen der Mitarbeiter. Dazuzahlen:

• Ehrlichkeit

• Kommunikation

• Kritikfahigkeit

• Engagement

148

Page 149: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 82: Agiler Prozess im Scrum-Modell

Agile Prinzipien sind ein Leitsatz fur die Arbeitsweise mit dieser Art derSoftwareentwicklung. Sie beschreiben die Dos and Don´t Dos des agilenProzesses und sind in dem ”Manifesto for Agile Software Development“[BBa01] nachzulesen. Das Verfahren kann dabei nur funktionieren, solan-ge sich jeder Beteiligte eines Projektes an die bestehenden Prinzipien halt.Daraus wird ersichtlich, wieso Werte wie Ehrlichkeit im agilen Entwick-lungsprozess so wichtig sind. Beispiele fur agile Prinzipien sind etwa

• selbststandiges Arbeiten,• genaues Arbeiten und• Terminverpflichtung.

Agile Methoden sind die zur Bearbeitung eines Projektes eingesetzten Teil-verfahren, auch Arbeitstechniken genannt. Meist bauen die eingesetztenMethoden aufeinander auf, so dass das Weglassen bestimmter Methodenfur den Entwicklungsprozess eher hinderlich ist. Die eingesetzten Metho-den dienen dazu, die Aufwandskurve und damit die Kostenkurve moglichstgering zu halten. Dies wird in den nachsten Abschnitten noch ausfuhrli-cher begrundet werden. Agile Methoden werden von Martin Fowler in[Fow05] ausfuhrlich beschrieben, so dass an dieser Stelle nicht weiter aufdie umfangreichen Vorteile dieser Arbeitsweisen eingegangen werden soll.Zur Veranschaulichung wurde Abbildung 83 aus [kos] ubernommen.

Agile Prozesse sind die im Rahmen des Projektes eingesetzten Softwareent-wicklungsprozesse. Diese bedienen sich agiler Methoden. Werden dieseProzesse erfolgreich zur Entwicklung von Software eingesetzt, spricht manvon agiler Softwareentwicklung. Den eingesetzten Prozessen liegt in derTheorie zugrunde, die fur den Entwurf eingeplante Zeit zu minimierenund schnell zu ausfuhrbarem Code zu gelangen.

149

Page 150: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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 saysthat 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 Softwa-reentwicklung einzusetzen. Dabei entschied sie sich dafur, deren Verfahren imRahmen des so genannten Scrum-Modells anzuwenden. Da dieses Modell relativneu und noch nicht sehr verbreitet ist, soll in diesem Abschnitt kurz auf seineVorteile eingegangen werden. Scrum wurde maßgeblich von Ken Schwaber undJeff Sutherland entworfen [Sch05]. Dabei soll das Modell die beteiligten Men-schen in den Mittelpunkt stellen und dem sozialen Aspekt der Gruppenarbeitgroße Bedeutung einraumen. Kommunikation zwischen den Teammitgliedernbildet ein zentrales Element bei der Bearbeitung der zu erfullenden Aufgaben.

In regelmaßig stattfindenden Treffen (zwei- bis dreimal pro Woche), genanntScrums, werden daher auftretende Probleme und Fortschritte besprochen. GroßeSoftwareprojekte sind fur den einzelnen Entwickler oft schwer zu uberblicken.Scrums helfen, Probleme zu erkennen, bevor sie akut werden. Dies spart Zeitund damit das Geld des Auftraggebers.

Das Projekt wird zudem in kleinen, einwochigen Etappen bearbeitet. JedeEtappe enthalt alle Entwicklungsschritte des Gesamtprojekts (Anforderungs-analyse, Design, Implementierung, Test). Diese Etappen werden Sprints genanntund werden schriftlich festgehalten. So konnen sich alle Mitglieder uber Fort-schritte anderer Mitarbeiter informieren. Dies wiederum hilft bei der Praventionvon Fehlern.

150

Page 151: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Es wird auf einen strikten Anforderungskatalog des Kunden verzichtet, dafurwerden auch Kundenwunsche berucksichtigt, die sich noch wahrend der Softwa-reentwicklung ergeben. Dies ist moglich, da, anders als in klassischen Verfahren,der Entwicklungsprozess in Sprints organisiert ist. Nur die im aktuellen Iterati-onsschritt benotigten Merkmale werden implementiert. Scrum ist bietet durchdiese Flexibilitat wie auch andere vergleichbare Vorgehensmodelle, etwa ExtremeProgramming, Kostenvorteile fur den Auftraggeber (vgl. Abbildung 83). Auchfur die Entwickler kann Scrum eine geeignete Arbeitsweise sein, denn aus derErfahrung heraus betrachten viele Entwickler von Software die Dokumentati-on eher als ein Hindernis und weniger als eine Hilfe. Scrum ist jedoch nichtvollkommen planlos, wie man nun vermuten konnte. Dies ware fatal, da kleineProgrammierfehler große Korrekturphasen erfordern wurden. Um diesem Irr-tum vorzubeugen, soll im nachsten beschrieben werden, wie Scrum es schafft,mit verringertem Planungsaufwand dennoch planvoll zu einer funktionierendenSoftware zu gelangen.

Scrum basiert auf dem iterativen Umsetzen vordringlicher Anforderungen[Sch05]. Wahrend Extreme Programming allerdings noch Konzepte zur Ermitt-lung von Anforderungen umfasst, liegt der Schwerpunkt in Scrum auf derenAbarbeitung. Scrum ist somit in erster Linie ein Managementprozess, der sichmit anderen Vorgehensmodellen — sinnvollerweise aber agilen — kombinierenlaßt. Schwaber sieht Scrum als empirischen Prozess, einem Prozess standigerAdaption im Gegensatz zu den herkommlichen definierten Modellen.

Scrum besteht im wesentlichen aus den folgenden Kernpraktiken, welchenachstehend naher 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 ei-nem Sprint werden die in einem Product Backlog (s. u.) gesammelten Anforde-rungen den Kunden Schritt fur Schritt abgearbeitet. Die im Product Backlogaufgestellten Anforderungen werden in Sprint Backlogs eingetragen. In einemSprint Backlog ist festgehalten, welche Anforderungen in einem bestimmtenSprintzeitraum erfullt werden sollen. Die Iterationslange betragt in der Regel30 Tage, innerhalb dieser Projektgruppe jedoch nur sieben Tage, da in kleinerenSchritten gearbeitet wird. Die Entscheidung, welche Anforderungen umgesetztwerden, wird vom Kunden nach von ihm festgelegten Prioritaten getroffen. DieAnforderungen aus dem Sprint Backlog werden vom Team aufgeteilt und jederEntwickler schatzt und bewertet die ihm zugewiesenen Aufgaben.

151

Page 152: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

7.1.4 Product Backlog

Ein Product Backlog ist eine Liste priorisierter Anforderungen, die in zukunf-tigen Sprints abgearbeitet werden sollen. Das Product Backlog gibt damit einegrobe Entwicklungsrichtung fur das Softwareprodukt an.

7.1.5 Sprint Backlog

Ein Sprint Backlog ist eine Liste der Anforderungen, die in einem Sprint abge-arbeitet werden sollen. Welche Anforderungen aus dem Product Backlog in dasSprint Backlog wandern, bestimmt allein der Kunde auf Basis der Schatzungender Entwickler.

7.1.6 Daily Scrum

Bei jedem Meeting findet ein kurzes (15-minutiges) Scrum-Meeting statt. Beieinem Scrum-Meeting skizziert eine Gruppe, die einen bestimmten Scrum abar-beitet kurz Ergebnisse und Probleme. Da jede Gruppe selbstandig arbeitet, er-fordert dieses Verfahren Disziplinierung der Mitglieder. Der Begriff Daily-Scrumist im Rahmen der Projektgruppe irrefuhrend, da nicht taglich Treffen stattfin-den.

7.1.7 Sprint Review

Ist der Iterationszeitraum eines Sprints vorbei, findet ein Sprint Review statt.Hier konnen dem Kunden die abgearbeiteten Anforderungen eines Sprints vorge-stellt werden und Zusagen zur Abarbeitung von Aufgaben des nachsten Sprintsgemacht werden.

7.1.8 Sprint Retrospective

Nach dem offentlichen Sprint Review mit dem Kunden findet ein Meeting derEntwickler statt. Folgende Fragen sollen geklart werden:

• Welche Ereignisse sind eingetreten?

• Was lief gut?

• Was ist verbesserungswurdig?

7.2 Erfahrungen mit Scrum

Wie schon vor der Implementierung im ersten Semester der Projektgruppe ge-plant, sollte die eigentliche Umsetzung des Energieinformationssystem mit Hilfevon Scrum geschehen. Wie bereits im vorigen Abschnitt beschrieben, ist Scrumeine agile Methode der Softwarentwicklung. Da die Projektgruppe von der Ideeangetan war, eine solche im Studium noch unbekannte und ungenutzte Soft-warentwicklungsmethode zu nutzen, und auch die eigentliche Arbeitsweise im

152

Page 153: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Scrum interessant fanden, entschied man sich, mit diesen Konzept bzw. miteiner modifizierten Variante zu arbeiten.

Die hier beschriebenen Features unseres Projektes sind im Backlog in weitereAufgaben unterteilt. Um Scrum und die Features genauer und ubersichtlicherbeschreiben zu konnen, werden diese unterteilten Aufgaben gruppiert. So werdenItems aus dem Backlog in dieser Beschreibung zusammengefasst. Zum Beispielwerden die Aufgaben Kunden anlegen, Kunden loschen usw. zum Leistungs-merkmal Kunden zusammengefasst und beschrieben.

7.2.1 Eigene Umsetzung

Da fur die Gruppenmitglieder feststand, dass man in einer Projektgruppe nichtidentisch zu einer wirklichen Softwareentwicklerfirma arbeiten kann — als Grun-de sind hier zum Beispiel projektexterne Verpflichtungen, sei es zum Beispieldurch die Universitat und außeruniversitare Arbeiten oder personelle und tech-nische Kapazitaten, zu nennen — aber trotzdem versuchen sollte, sich so nahwie moglich an eine solche Umgebung und Arbeitsweise zu orientieren, wurdedas Scrum Konzept so modifiziert, dass man unter den gegebenen Bedingun-gen sinnvoll mit den Ideen arbeiten konnte. Des Weiteren wurde stets versucht,einen Softwareprozess in wirtschaftlicher Umgebung zu simulieren.

Im folgenden soll aufgefuhrt werden, wie die Projektgruppe sich die Arbeitmit Scrum vorstellte und in der hier beschriebenen Dokumentation der Sprintsauch, wie sie im Prozess der Entwicklung stellenweise den Scrumprozess an-passte. Es bestand dabei nicht die Absicht, aus einem bestehenden Konzept eineigenes Softwareentwicklungsmodell zu erstellen, sondern eher nicht starr undundynamisch an einer Idee zu hangen, die man so nicht in der Gruppe umsetzenkonnte. Gerade weil es sich bei Scrum um eine sehr agile Methode der Softwa-reentwicklung handelt, hielt die Projektgruppe diese Anpassung fur sinnvoll.

7.2.2 Planen der Sprints und Sprint Review Meetings

Zuvorderst stand das Erstellen eines Planes, an dem man sich orientieren konn-te, wieviel Zeit man zur Verfugung hat und welche Ziele in einer solchen Zeiterreicht werden konnen. Ein Sprint im ursprunglichen Scrum ist fur eine Wocheangesetzt, in der es tagliche Treffen gibt und an dessen Ende die aufgestelltenFeatures implementiert sein sollen bzw. eine Zusammenfassung uber Geschafftesund Offenes geliefert wird. Die Gruppe einigte sich darauf, diese Sprints an ihreSituation anzupassen und den Zeitraum auf einen Monat zu verlangern. Dashieß, dass im zweiten Semester des Projektes, dem Sommersemester 2006, vierbis funf Sprints aufgestellt und mit Features gefullt werden konnten. Dement-sprechend wurde ein Plan fur diese Situation aufgestellt.

• Warm Up: 07.04.2006-14.04.2006 | Bevor mit dem eigentlichen Sprint an-gefangen wurde, sollten im sogenannten Warm Up erst noch offenstehendeorganisatorische Dinge geklart werden.

• Erster Sprint inklusive der Sprint Organisation: 14.04.2006-31.05.2006 |Grobe Organisation der Sprints und der Aufstellung des ersten Sprints.

153

Page 154: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 84: Terminplanung der einzelnen Scrums

• Zweiter Sprint: 31.05.2006-05.07.2006 | Sprint Review Meeting des erstenSprints und Aufstellung des zweiten Sprints.

• Dritter Sprint: 05.07.2006-02.08.2006 | Sprint Review Meeting des zweitenSprints und Aufstellung des dritten Sprints.

• Vierter Sprint: 02.08.2006-30.08.2006 | Sprint Review Meeting des drittenSprints und Aufstellung des vierten Sprints.

• Funfter Sprint: 30.08.2006-13.09.2006 | Sprint Review Meeting des viertenSprints. Diskussion uber die Nutzung und Aufstellung des funften Sprints.

• Projektabschluss: 13.09.2006-20.09.2006 | Sprint Review Meeting des funf-ten Sprints. Abschließende Arbeiten an Dokumentation, Tests, Handbuchund eventuellen noch offenen zu erledigenden Aufgaben

• Abschlussbericht: 20.09.2006-30.09.2006 | Finale Zusammenstellung desBerichtes, Korrektur und lezte Formatierungen des Berichtes. Bestimmungeiner Person aus der Gruppe zur Prasentation des Projektes

7.3 Warm Up

Das Warm Up war dafur angedacht, einen moglichst reibungslosen Start in dieArbeit mit den Sprints zu gewahrleisten. Es sollte verhindert werden, dass vie-le Fragen zur Implementierung erst bei der eigentlichen Arbeit auftauchen. Sowurde als erstes noch einmal zusammengefasst, was bereits erledigt wurde, ins-besondere im Zusammenhang mit dem Zwischenbericht und dem angetestenPrototypen innerhalb der gewahlten Entwicklungsumgebung. Zusatzlich wur-den Tipps sowie Hilfen zur Installation, Benutzung der Entwicklungsumgebungund Zusatzprogrammen gegeben. Hintergedanke war auch, alle Mitglieder derProjektgruppe nach den Semesterferien wieder auf einen Stand zu bringen, umdie Motivation fur alle zu erhalten und niemanden aus der Arbeit bzw. bestimm-ten Bereichen des Projektes auszuschließen. So sollte jeder wissen, mit welchenMitteln die eigentliche Programmierarbeit zu leisten ist und welche Schritte zutun sind, um gestellte Aufgaben bewaltigen zu konnen. Aus eigener Erfahrungist zu sagen, dass es sehr frustrierend ist, wenn man bereits am Start scheinbarunendlich viele Probleme bewaltigen muss, um uberhaupt den ersten Schritt inRichtung der eigentlichen Implementierung gehen zu konnen. So wurde zum Bei-spiel von einigen Mitgliedern der Gruppe erlautert, wie man richtig mit der ge-wahlten Entwicklungsumgebung arbeitet und beispielhaft einige Arbeitsschrittevorgefuhrt.

154

Page 155: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

7.4 Erster Sprint

7.4.1 Verlauf des ersten Sprints

Um sich mit dem ersten Sprint vertraut zu machen und da kein vorrausgegan-genes Sprint Review Meeting von einem fruheren Sprint bzw. ein Sprint selbstvorlag, um in diesem bereits Aufgaben und sonstige Dinge zu verteilen, ent-schied sich die Projektgruppe dafur, den ersten Sprint zusammen mit der nochdazugehorigen einmalig zu bestimmenden Organisation der Sprints von vier aufsechs Wochen zu erweitern. Da auch noch das komplette Backlog, also den Poolfur alle gewunschten Features, mit den dazugehorigen Aufgaben erstellt werdenmusste, wurde der Vorschlag der Sprintverlangerung ubernommen.

Zu Beginn des ersten Sprints wurde ein Scrum-Master bestimmt, der dieOrganisation der einzelnen Sprints ubernehmen sollte. Der Scrum-Master muss-te unter anderem die von der Gruppe aufgestellten Features des Backlogs indas dafur eingerichte Plugin von Visual Studio ubertragen. So hatte die ganzeGruppe eine Ubersicht uber alle Aufgaben, die zu bewaltigen waren. Die Auf-gaben wurden mit einer Prioritat und einer teilweise mit einer eingeschatztenBearbeitungszeit versehen. Aus dem Backlog wurden nun fur den ersten Sprintdie gewunschten Features ausgewahlt.

Damit die Arbeit mit den Features gut funktionierte, wurden in den erstenzwei Wochen des Sprints von den Teilnehmern einige Konzepte ausgearbeitetund 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, umdie gelosten Aufgaben nicht nur zu bewaltigen, sondern die Ergebnisse konsis-tent und fur die ganze Gruppe lesbar bzw. verstandlich und nachvollziehbar zuhalten. Diese Konzepte wurden in einer Sitzung von den jeweiligen Verantwort-lichen vorgetragen und anhand von Beispielen oder Definitionen erklart, so dassjeder auf dem Wissensstand war, diese Anleitungen auch umzusetzen.

Die Gruppe entschied sich danach, erst einmal die Stammdaten des Sys-tems zu implementieren, zumal diese Daten relativ unabhangig von den jewei-ligen anderen Features sind. Somit sollte das Grundgerust geschaffen werden,um dann spater mit diesem weiter arbeiten und die folgenden, komplexerenFeatures leichter umsetzen zu konnen. Es sollten also Benutzer, Lieferanten,Kunden, Bilanzkreise und Regelzonen, Tarife und Lastprofile als zuganglicheLeistungsmerkmale nach diesem Sprint existieren. Fur eine sinnvolle Nutzung

155

Page 156: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

wurde dementsprechend die erste grobe Form der Nutzungsoberflache gestaltet(weitere Informationen dazu im Kapitel 4). So konnten die Stammdaten gleichin eine zusammenhangende Umgebung gebracht werden, was einerseits eine guteUbersicht bot, was das System bereits leistet, aber auch schon eine Vorschaudarauf ergab und erste Ideen weckte, wie die restlichen Features in das bereitsvorhandene Programm integriert werden konnten.

Die hier erwahnten Stammdatenfeatures lassen sich im Detail im KapitelFunktionen – Stammdaten nachlesen.

7.4.2 Probleme und Ereignisse im ersten Sprint

Wahrend der Arbeit am ersten Sprint wurde die Struktur der Backlog Itemsnoch einmal uberarbeitet, um sinnvoller mit diesen arbeiten und diese besserverteilen zu konnen. Falls sinnvoll, wurde ein Feature auf die drei Entwick-lungsebenen verteilt: Datenbank, Oberflache und Logik. Zum einen hatte derScrum-Master dadurch eine bessere Ubersicht, wie weit eine zusammenhangen-de Aufgabe bereits bearbeitet ist, und zum anderen konnten die Teilnehmer sichin ihren Untergruppen effizienter aufteilen. Wie auch schon zuvor tauchten im-mer wieder Probleme mit der genutzten Entwicklungsumgebung auf. Einerseitserfullte das Plugin zur Organisation des Scrums nicht ganz die Anspruche, diedie Gruppe daran gestellt hatte:

Backlog und Sprint Die Arbeit mit dem Backlog und den eigentlichen Sprintswurde dadurch erschwert, dass zwischen diesen beiden Bereichen im Plu-gin keine direkte Verbindung besteht. Dass heißt, jedes Objekt aus demBacklog musste manuell im Sprint neu erstellt und großtenteils auch neubeschrieben werden. Zum einen musste die Gruppe jetzt darauf achten,die erhaltenen Aufgaben im Sprint zu bearbeiten und zusatzlich noch ei-nige Einstellungen im Stammobjekt im Backlog zu tatigen. So musste zumBeispiel der aktuelle Bearbeitungsstatus sowohl im Backlog als auch imSprint manuell umgestellt werden. Ein großeres Durcheinander wurde aberdennoch vermieden, lediglich die Ubersicht im Backlog ging mit der Zeitimmer wieder etwas verloren.

Integrierte Reports Die anfanglich als praktisch empfundenen Reports zurAusgabe von beispielsweise Sprintarbeitsstatistiken stellten sich im wei-teren Verlauf als fur die Gruppe unnutz heraus. Da kein Report manu-ell konfigurierbar ist und eine hohe Einarbeitungszeit fur die Erstellungvon eigenen Reports kein vernunftiges Verhaltnis zwischen Aufwand undErtrag versprach, wurden diese Reports nicht weiter genutzt. So wurdebeschlossen, im Endbericht eine Zusammenfassung in ahnlicher Form zugestalten.

Sprint- und Backlogitems Da die Projektgruppe die Reports nicht nutzenwollte, hatten die tiefgreifenderen Beschreibungen der Items aus den Sprintsoder auch den Backlogs fur uns ebenfalls keinen direkten Sinn, so dass mansich darauf einigte, nur die notigsten Informationen zu beschreiben. Da dasdas Backlog gemeinsam erstellt worden war somit jeder auch Ahnung vonden einzelnen Features hatte, ergaben sich aus dieser Entscheidung auch

156

Page 157: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

keine weiteren Probleme, zumal sich die Aufgabenmenge noch in uber-schaubaren Dimensionen befand.

Andererseits wurde die Gruppe von unerklarlichen Fehlermeldungen seitens Vi-sual Studio befallen, die zwar keinen Einfluss auf unser Programm hatte, docheinige Male an den Nerven der Gruppenmitglieder zerrte.

7.4.3 Review Meeting des ersten Sprints

Das Sprint Review Meeting gab uns die Moglichkeit, den Betreuern der Pro-jektgruppe, wie in einer realen wirtschaftlichen Umgebung, unsere Ergebnissezu prasentieren und zusatzlich Verbesserungen und Anregungen einzuholen. Imersten Meeting kristallisierte sich schnell heraus, dass die doch umfangreicheAufgabenstellung zwar bewaltigt worden war, aber trotzdem noch einige Fehlerim System vorhanden waren. Es wurde empfohlen, diese erst zu beheben, be-vor man mit neuen Features weitermachen wurde, da sich ein nicht beseitigterFehler in den anderen Aufgaben wahrscheinlich noch weiter ausbreiten wurde.

Da die Gruppe eine Woche bereits als Puffer fur unerwartete Ereignisse ein-geplant hat, wurde der zweite Sprint entsprechend um eine Woche erweitert. Inder ersten Woche sollten also moglichst alle Fehler behoben werden, damit manin der darauffolgenden Sprintwoche direkt am ursprunglich geplanten, zweitenSprint ansetzen konnte. In diesem Zusammenhang wurde auch festgelegt, dieOberflache wahrend der Entwicklung genauer zu bearbeiten und einheitlich zugestalten, damit Fehler schon fruhzeitig verringert werden konnen.

7.5 Zweiter Sprint

7.5.1 Verlauf des zweiten Sprints

In der anfanglichen groben Planung des Scrums war der zweite Sprint fur dieErstellung der Entscheidungsunterstutzung und dazugehoriger Aufgaben ange-dacht. Der Sprint wurde jetzt um die Fehlersuche und Behebung erweitert. Wieschon erwahnt, wurde der zweite Sprint um eine Woche verlangert, um dasGerust der Implementierung moglichst fehlerfrei zu halten.

Zu Beginn wurde aus dem ersten Sprint heraus eine Fehlerliste zusammen-gestellt, damit in der ersten Woche die Behebung schnell durchgefuhrt werdenkonnte. In der ersten Sitzung wurden diese Fehler auf die Gruppe verteilt. Eswurde also versucht, diese Liste abzuarbeiten. Am Ende dieser Woche hatte manzwar einen Großteil der Fehler behoben, entschied sich aber dafur, zwei Personenaus der Gruppe fur eine weitere Fehlersuche abzustellen. So sollte die Gruppewie geplant an den noch aufzustellenden neuen Aufgaben arbeiten konnen, aberauch die restlichen Fehler noch beseitigen und neue moglichst schnell behebenkonnen.

Als Hauptaufgaben wurden das Pluginsystem zum einen fur die Lastprogno-sen und zum anderen fur die Entscheidungsunterstutzung (weitere Informatio-nen siehe Abschnitt 4.2.1, Seite 36) und die rollenbasierte Sicherheit innerhalbdes Programmes bestimmt (weitere Informationen siehe Abschnitt 4.2.4, Seite

157

Page 158: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

45). Zusatzlich sollten fur die jeweiligen Pluginsysteme Algorithmen entwickeltwerden, die mit verschiedenen Zielsetzungen die Entscheidungsunterstutzungbzw. das Lastprognoseplugin lauffahig machen sollten. So wurde zum Beispielzuerst ein simpler Algorithmus entwickelt, der das Problem kurzsichtig und aufeinfachstem Wege lost, um das Gesamtsystem erst einmal testen zu konnen. Allefolgenden Algorithmen sollten nach den Kriterien Geschwindigkeit und Optima-litat verbessert werden.

Neben diesen Features wurden zusatzlich kleinere Aufgaben verteilt:

Systembeschreibung Jeder Verantwortliche einer Aufgabe im dafur einge-richteten Scrum- Verwaltungs-Plugin sollte, soweit dies moglich ist, dasentsprechende Feature schon fur den Endbericht in grober Form beschrei-ben.

Oberflache Alle Fenster sollten einer einheitlichen Vorlage entsprechen, so dassneue Inhalte nach dieser Form erstellt und bereits bestehende an dieseVorgaben angepasst werden konnten.

Script fur Testzwecke Um das System sinnvoll testen zu konnen, wurden derDatenbank Testdaten zugefugt. Gerade im Hinblick auf die Probleme imersten Scrum sollten solche oder ahnliche Fehler auch durch diese Datenvermieden werden.

Exceptions definieren Da in der Gruppe die Behandlung von Exceptionsnoch nicht eindeutig war, wurde hierzu abermals ein Konzept zur Um-setzung ausgearbeitet.

Diese wurden parallel zu den Hauptaufgaben bearbeitet, so dass es in der Grup-pe eigentlich selten einen Leerlauf fur eine Person gab, da immer eine kleineAufgabe zu erledigen war, wenn man an einem Hauptfeature zum Beispiel aufErgebnisse 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 ei-genen Programm selbst, nicht wirklich fur den zweiten Sprint eingeplant hatte,soweit man das uberhaupt tun kann. Auf jeden Fall war man nicht auf einenholprigen Sprintverlauf vorbereitet. Und so musste man sich erst daran gewoh-nen, offene Aufgaben nachtraglich zu bewaltigen, gleichzeitig aber auch die neu-en Aufgaben nicht aus den Augen zu verlieren. So hatte die Gruppe auch dieFehler an sich unterschatzt und dies in der ersten Woche abermals gemerkt, alses hieß, diese erst einmal aus dem Wege zu schaffen. So fiel auf, dass Fehlerwieder neue Fehler nach sich ziehen und so eine Aufgabe leicht sehr zeitaufwen-dig werden lassen konnen. In der zweiten Woche hatte die Projektgruppe dieseTatsache aber dennoch erkannt und die Aufgaben entsprechend angepasst, sodass der zweite Sprint die gewunschten Ergebnisse lieferte.

158

Page 159: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

7.5.3 Review Meeting zum zweiten Sprint

Im Meeting wurden einerseits die neuen Features vorgestellt und andererseitsdie Arbeit an den Fehlern vorgefuhrt. Ergebnis war, dass der Großteil der Feh-ler ausgemerzt wurde und lediglich einige Unstimmigkeiten in der Validierungherrschten. An den neuen Hauptfeatures fehlten noch einige Detailarbeiten, dieim dritten Sprint aufgearbeitet werden sollten. Dazu gehorten zum Beispiel dieAnpassung der Oberflache oder der Erweiterung um einige aus dem Entwurfvorgesehenen Optionen.

7.6 Dritter Sprint

7.6.1 Verlauf des dritten Sprints

Im Verlauf des dritten Sprints traten zum ersten Mal ernsthafte Probleme auf,die man neben den neuen gestellten Aufgaben zu bewaltigen hatte.

Zuerst einmal wurde nach dem Meeting festgelegt, dass in diesem Sprint dievorgesehenen Features der EEX implementiert werden sollten (weitere Informa-tionen siehe Abschnitt 5.2, Seite 88). Zusatzlich sollten die erstellten Featuresaus dem zweiten Sprint abgeschlossen werden. Zum einen hieß dies, dass dieKaufentscheidung um die eigentliche Umsetzung erweitert werden sollte. Au-ßerdem sollte die Oberflache nicht mehr nur einheitlich sein, sondern auch einan Windows ausgerichtetes Design erhalten.

Wie schon erwahnt, bemuhte man sich intensiver um die Fehlersuche, den-noch nutzte die Gruppe die Validierung fur die Nutzungsoberflache noch zuuneinheitlich und luckenhaft. So wurde ebenfalls die Aufgabe verteilt, eine ein-heitliche Validierungsfunktion zu erstellen bzw. die alte den Anspruchen entspre-chend anzupassen. So war ebenfalls gewahrleistet, dass alle Oberflacheninhalteeinheitlich auf zum Beispiel falsche Eingaben reagieren.

Als erstes ernsthaftes Problem stellte sich die Testbarkeit der Multithrea-ding-fahigkeit des Webservices unseres Programmes heraus. Da es nicht moglichwar, dies uber Visual Studio nachzuweisen, wurden wir von den Betreuern gebe-ten, dies explizit vorzuweisen. Zum einen hieß dies, dass einige Teilnehmer derGruppe nicht fur die eigentlich vorgesehenen Aufgaben zur Verfugung standenund dass diese Analyse ein Mangel im Programm aufzeigen konnte. Es wurdedavon ausgegangen, dass unser Programm Multithreading unterstutzt, ohne dieswirklich uberpruft zu haben. So wurde dieser vorzubringende Beweis ebenfallseine Aufgabe im dritten Sprint.

Das zweite Problem war, dass die strikte Trennung von Client und Ser-ver nicht eingehalten wurde. Dieser Missstand sollte ebenfalls in diesem Sprintzusatzlich behoben werden, so dass nicht die volle Gruppenkapazitat fur dieeigentlichen Aufgaben bereit stand.

7.6.2 Probleme und Ereignisse im dritten Sprint

Da die Gruppe sich in diesem Sprint im Verhaltnis zu den vorangegangenenSprints eine ubersichtliche Anzahl an Aufgaben gestellt hatte, wurde das Pro-blem der Arbeitsaufteilung hinsichtlich der Gruppenkapazitat gut umgangen.

159

Page 160: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

So hatte man nach der Verteilung der Hauptaufgaben immer noch genugendTeilnehmer fur die Behebung der eben genannten Mangel zur Verfugung. DieArbeitsteilung von Client und Server, bei der der Client die grafische Oberflacheenthalt und der Server die Berechnungen ubernimmt, konnte bis auf eine Aus-nahme gut umgesetzt werden, da das Problem und das Prinzip von der Gruppeverstanden worden war. Die Ausnahme bildete das Pluginsystem. Hier war es ineinem ersten Anlauf nicht gelungen, die uberaus komplexen Berechnungen aufder Serverseite ablaufen zu lassen, da die vom Pluginsystem benotigten Inter-faces sich nicht uber den Webservice ubertragen ließen. Dies widersprach aberdeutlich den Anforderungen an die oben geschilderte Arbeitsteilung. Da diesesProblem aber nicht ohne großen Zeitaufwand zu beheben war, wurden erst ein-mal Losungsvorschlage erarbeitet, die dann im vierten Sprint umgesetzt werdensollten.

Das Problem der Multithreading-Fahigkeit wurde anfangs von der Gruppeunterschatzt, da man sich sicher war, dass der Webservice dazu fahig ware. Einensoliden Beweis konnte man dennoch nicht liefern, so dass auch diese Aufgabeim vierten Sprint erneut aufgenommen werden musste.

7.6.3 Review Meeting zum dritten Sprint

Im Meeting wurden kurz die wenigen neuen Features vorgestellt, das Hauptau-genmerk lag aber auf der Bewaltigung und Diskussion der noch offenstehendenProbleme. Zum einen wurde ein Konzept vorgestellt, mit dem sich das Problemder Arbeitsteilung zwischen Client und Server beheben lassen sollte. Betreuerund Gruppe einigten sich auf eine Bearbeitung innerhalb des vierten Sprints.Bei dem noch ausstehenden Beweis hingegen wurde von den Betreuern auf eineschnelle Bearbeitung gedrangt, da bei einem negativen Ergebnis — sprich einernicht vorhandenen Multithreading-Fahigkeit des Webservices — zu schließenist, dass die Arbeitsweise des Webservices ungenugend ist und eine Umstellungviel Zeit kosten wurde. Das hatte auch geheißen, dass der gesamte Zeitplan inGefahrg geraten ware.

7.7 Vierter Sprint

7.7.1 Verlauf des vierten Sprints

Wie schon im zweiten Sprint kam in diesem Sprint eine unerwartet aufwandigeund eher schwierige Aufgabe hinzu. Diese war, den Beweis zu erbringen, dassunser Webservice multithreading-fahig ist. Schwierig deshalb, weil in der Gruppenoch keine Erfahrungen zu diesem Thema und insbesondere nicht im Zusam-menhang mit Visual Studio existierten. Diese Aufgabe sollte also so schnell wiemoglich gelost werden, d. h. nicht erst am Ende des vierten Sprints abgeschlossensein.

Trotz dieses Problems mussten die weiteren noch offenstehenden Aufgabenerledigt werden. Da der vierte Sprint eigentlich der letzte Sprint sein sollte, indem neue Features eingebaut werden sollten, wurde eine intensive Sprintpla-nung durchgefuhrt. So wurden alle noch im Backlog existierenden Aufgaben

160

Page 161: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

gesammelt und versucht, fur die jeweiligen Aufgaben Zeiteinschatzungen an-zugeben. Entsprechend der Prioritat wurde dann entschieden, welche Featuresnoch bearbeitet werden sollten. Folgende Aufgaben wurden dem vierten Sprinthinzugefugt:

Storungen: Weitere Informationen siehe Abschnitt 5.3.2, Seite 115

Druckoptionen

Fahrplane: Weitere Informationen siehe Abschnitt 5.4, Seite 129

Informationen innerhalb der Oberflache

Finale Oberflachenanpassung:

Umstellung des Pluginsystems: Weitere Informationen siehe Abschnitt 4.2.1,Seite 36

Abschluss der Validierungsfunktionen: Weitere Informationen siehe Abschnitt4.2.2, Seite 42

Erstaunlicherweise sind nur einige als optional gekennzeichnete Aufgaben ausdem Backlog nicht in die Sprints mit eingeflosssen, was bedeutete, dass beieinem erfolgreichen Abschluss des vierten Sprints die gestellten Aufgaben derGruppe bewaltigt waren.

7.7.2 Probleme und Ereignisse im vierten Sprint

Das große Problem zu Beginn des Sprints, namlich der noch zu liefernde Beweis,konnte innerhalb der ersten Tage endgultig gelost werden. Der Webservice istmultithreading-fahig, jedoch kann man dies nicht direkt in der Entwicklungsum-gebung nachweisen geschweige denn testen. Ein solcher Test ist anscheinend nuruber Lasttests moglich. Erst nach einigen Recherchen uber Foren und Hilfestel-lungen zur Thematik sowie einer Anfrage an Microsoft konnte man zu diesemErgebnis gelangen, was selbst den Betreuer etwas verwunderte. In ihren Augeneignet sich Microsoft Visual Studio wegen der fehlenden Testbarkeit nur be-dingt fur die Entwicklung von Client-Server-Anwendungen. Zur Erleichterungder Gruppe wurde das Problem von den Betreuern als gelost betrachtet und dienoch ausstehenden Aufgaben konnten angegangen werden.

Ebenfalls gelost wurde das Problem der Pluginumstellung. Diese arbeitetjetzt serverseitig und nicht wie zunachst implementiert clientseitig (weitere In-formationen im Abschnitt 4.3, Seite 49).

Ein kleines weiteres Problem war die Urlaubsthematik in der Gruppe. Daein nicht unerheblicher Teil im vierten Sprint Urlaub eingereicht hatte, musstedie Planung der Aufgaben entsprechend prazise erfolgen. Dies wurde dann auchdementsprechend gemacht, so dass die gestellten Aufgaben dieses Sprints zumGroßteil gelost werden konnten. Wie immer am Ende eines Sprints fehlten zu deneinzelnen Aufgaben noch Details bzw. traten Fehler auf, die dann im folgendenSprint behoben bzw. bearbeitet werden sollten. Da der letzte Sprint als reinerDokumentations-, Test- und Sprint zur Fehlerbehebung angedacht war, konnteman die letzten offenstehenden Verbesserungen ohne Probleme in den Verlaufdes Scrumprozesses mit einbeziehen.

161

Page 162: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

7.7.3 Review Meeting zum vierten Sprint

Im Meeting wurden wie gewohnt alle erstellten Features vorgestellt und im An-schluss der neue Sprint geplant. Hauptaugenmerk lag also auf der Vervollstandi-gung der Dokumentation, dem Testen des Programmes und dazugehorigen Kom-ponenten, entsprechende Fehlerbehebung und dem Schreiben des Abschlussbe-richtes.

Zum einen sollten Datenbankzugriffe getestet, Systemtests, Installations-tests, Lasttests und Webservice-Tests durchgefuhrt werden (weitere Informa-tionen in Kapitel 6, Seite 139). So sollten alle Bereiche abgedeckt werden.

7.8 Funfter Sprint

7.8.1 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 Plug-ins), 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 undkomplexeren Arbeiten am Endbericht sollten nach dem funften Sprint starten.

7.8.2 Probleme und Ereignisse im funften Sprint

Das Pluginsystem war zwar bereits entsprechend den Vorgaben der Betreueruberarbeitet worden und arbeitete nun serverseitig, allerdings haperte es nochan der Einbindung der generischen Benutzeroberflachen ins ubrige Programm.Die Arbeiten an diesem — im Vergleich zur Umstellung der Arbeitsweise klei-nen — Problem wurden als Spezialfall im Scrum vermerkt, da sie auch nochnach dem vierten und funften Sprint fortgesetzt wurden. An dieser Stelle wurdevom eigentlich Plan abgewichen, keine weiteren Features bzw. Aufgaben im Pro-gramm nach dem funften Sprint zu tatigen. Fur die Endfassung des Programmsmusste dieses Leistungsmerkmal aber auf jeden Fall enthalten sein und wurdeauch als noch schaffbar und sinnvoll eingestuft. So sollte die Einbindung desPluginsystems auf jeden Fall so lange weiterentwickelt werden, wie es die Zeitzuließ.

7.8.3 Review Meeting zum funften Sprint

Das letzte Meeting war sehr kurz und es wurde nur einmal kurz besprochen,was geschafft wurde und was noch an Aufgaben offenstand. Dazu gehorten nocheinige kleine Fehler bei der Installation, die noch behoben werden mussten undweitere Restarbeiten, die im folgenden Kapitel beschrieben werden.

7.9 Abschlussarbeiten und Organisation

Zu diesem Zeitpunkt wollte man eigentlich nur noch am Endbericht schreibenund keine weiteren Arbeiten am Programm oder den dazugehorigen Komponen-ten tatigen. Da aber noch einige Tests, Oberflachenarbeiten, Behebung kleinerer

162

Page 163: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Programmfehler und der Abschluss der Einbindung des Plugins anstanden, wur-de selbstverstandlich an diesen Punkten weitergearbeitet. Die Gruppe war davonuberzeugt, beides gleichzeitig fortfuhren zu konnen, um ein solides Endproduktabzuliefern. Der Zeitaufwand in jenen Tagen wurde dementsprechend hoch, wieschon in den Wochen davor, um ein Projekt mit dem gewunschtem Ergebnisabliefern zu konnen.

Ein personliches Gruppenfazit zu Scrum an sich und der Arbeit damit findetsich in Kapitel sec:fazit.

163

Page 164: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

8 Fazit

Die Arbeit in der Projektgruppe hat sich in mehreren Ebenen abgespielt, wes-halb sich das Fazit auch in verschiedene Kapitel teilt.

8.1 Allgemeines Fazit

Nach der Fertigstellung des Projekts kann der Schluss gezogen werden, dassdie entwickelte Software bereits eine solide Grundlage fur eine kommerzielleWeiterentwicklung darstellt. Insbesondere die zum Datenaustausch eingesetz-ten Formate (Fahrplane, EEX-Handel), aber auch die intern eingesetzten Da-tenstrukturen (Lastprofile, Regelzonen etc.) entsprechen den aktuellen industri-ellen Standards und enthalten somit alle Informationen, die Akteure auf demrealen Energiemarkt benotigen, um mit Energie zu handeln und ihre Kundenzu versorgen. Hier hat sich die anfangliche Einarbeitung in die Thematik ”Ener-giewirtschaft“ bezahlt gemacht. Auch die ubrigen Leistungsmerkmale wie dieClient-Server-Architektur, die Mehrbenutzerfahigkeit, die Austauschbarkeit ver-schiedener Programmteile und ganz besonders das uberaus flexible System zurEntscheidungsunterstutzung bei Lastprognosen und Kaufempfehlungen erfullenwesentliche Anforderungen, die ein Energiehandler an ein Programm zur Hilfebei seinen Aktivitaten auf dem Strommarkt stellen kann.

8.2 Thematik Energieinformationssysteme

Die Arbeit an dem eigentlichen Thema Energieinformationssysteme war fur dieTeilnehmer im ersten Semester mit Sicherheit informativ und interessant, zumalman sich in dieser Projektgruppe sehr detailliert in diesen Bereich einarbeitenmusste, um sinnvoll ein eigenes Thema zu konstruieren. Gerade aus diesemGrund ist es eigentlich schade, dass im zweiten Semester die Auseinanderset-zung mit dem Thema im Prinzip immer weiter in den Hintergrund geruckt istund Dinge wie Implementierungsschwierigkeiten, Softwarearchitektur, Algorith-menwahl usw. in den Vordergrund geruckt sind. Dieser Umschwung ist wahr-scheinlich nicht zu vermeiden, da naturlich ein großer Teil an Programmierarbeitgeleistet werden muss und man nicht die ganze Zeit uber die Energiethematikreferieren und konzipieren kann, so dass am Ende kein wirkliches Produkt en-steht. Vielleicht ware aber ein erneuter Bezug zum Thema zur Mitte des zweitenSemesters interessant gewesen. Zum Beispiel hatte man als Projektgruppe einemAußenstehenden ein paar Ergebnisse prasentieren konnen. Wahrscheinlich warees dann zu spat gewesen, Anregungen oder Verbesserungen noch umzusetzen,aber eventuell hatte eine externe Meinung die Energiethematik in der Gruppenoch einmal neu aufleben lassen, da man am Ende des Scrums doch des ofterennur noch Sprintitems und das Backlog im Kopf hatte.

In diesem Zusammenhang stellte sich besonders die Findung eines eigenenProjektes fur die Gruppe im nachhinein als eine erfahrungsreiche Aufgabe her-aus. Da noch niemand wirkliche Erfahrung mit einer solchen Aufgabe hatte, wa-ren die standigen Zweifel und Nachfragen bei den Betreuern, ob wir uberhauptein angemessenes Konzept erstellt haben, sicherlich verstandlich. Abschließend

164

Page 165: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

kann man aber sagen, dass gerade das Finden eines eigenen Themas eine Pro-jektgruppe in dem Sinne weiterbringt, dass man nicht nur einen Teil einer The-matik betrachtet, sondern viele Seiten in Augenschein nimmt. So wachst ganzautomatisch das Verstandnis fur ein Thema, weil man nicht nur den Blick aufein vorgegebenes Projekt gerichtet hat, sondern viele Faktoren beachtet werdenmussen. Dieser Rundumblick wurde bei uns zusatzlich noch durch die weit ge-facherten Themen unserer Seminarphase erweitert, so dass die ganze Gruppevoll im Thema integriert war. Diese Vorarbeit war mit Sicherheit eine hilfreicheErfahrung, wie man bestimmte Probleme oder Aufgaben in Zukunft angehenkann.

8.3 Umsetzung des Entwurfs

Die Umsetzung des Entwurfs lasst sich insgesamt als sehr erfreulich und grad-linig beurteilen. In Kapitel 2.1 werden die Unterschiede zwischen Entwurf undUmsetzung dargestellt. Hierbei werden nur sehr geringe Abweichungen aufge-listet, was fur eine sehr gute konzeptionelle Vorarbeit und Disziplin innerhalbder Projektgruppe spricht. Es konnten alle als essentiell hervorgehobenen Leis-tungsmerkmale implementiert werden sowie einige weitere, nutzliche Features.Insbesondere hervorzuheben ist, dass die bei der Umsetzung dieser Featureskeine Vereinfachungen gegenuber der realen Welt vorgenommen wurden, umProbleme zu umgehen oder Arbeit zu sparen. Daher lasst sich abschließend zurUmsetzung 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 Ar-beitsweisen vorgestellt. Die Entscheidung, auf Microsoft basierende Losungeneinzusetzen, erwies sich im Verlauf der Implementierung als vorteilhaft. Es konn-te auf eine Vielzahl produktiver Werkzeuge zuruckgegriffen werden, die die Um-setzung des Programms deutlich erleichterten. Als Beispiel sei hier der GUI-Designer in der Visual-Studio-Entwicklungsumgebung genannt. Auch die einfa-che Anbindung des Microsoft SQL Server 2005 an das Programm bestatigte dieAuswahl, eine Losung ”aus einem Guss“ zu verwenden.

Es soll naturlich nicht verschwiegen werden, dass wahrend der Implemen-tierung auch viele Schwierigkeiten und Probleme auftraten. Eine anscheinendnicht ganz auf den Gesetzen der Logik basierende Versionsverwaltung der ”TeamEdition“ ließ so manchen Zweifel aufkommen. Die Tatsache, dass jedes dieserProbleme letztlich gehandhabt werden konnte, spricht jedoch wieder fur unsereEntscheidung.

Dem Umstand, dass fur die meisten Mitglieder der Projektgruppe die Ent-wicklungswelt von Microsoft sowie die Programmiersprache C# volliges Neulandwaren, laßt sich positiv entnehmen, hier neue Erfahrungen und Fahigkeiten ge-wonnen zu haben. Aus dieser Sicht war es besonders vorteilhaft, die jeweilsaktuellsten Versionen einzusetzen, etwa .NET 2.0, SQL Server 2005 oder VisualStudio 2005. So merkte man auch, dass .NET ausgereifter zu sein scheint als das

165

Page 166: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

uber die Jahre gewachsenes Java. Aber auch mit .NET und C# zu program-mieren hat — wie eigentlich jede Entscheidung — seine Vor- und Nachteile. Sostellte man beim Programmieren fest, dass die Dokumentation bei Java wieder-um intuitiver und leichter bedienbar war. Helfen konnte man sich aber durch diedoch sehr große Gemeinschaft um .NET, Microsoft und Co., die einen an denmeisten Stellen durch zahlreiche Foren und Anleitungen weitergebracht hat.

Auch wenn die Implementierung nicht immer glatt lief und zwischenzeitlichmanchen Nerv etwas uberstrapaziert hat, so zeigt jedoch die Tatsache, dass al-le geforderten Features erfolgreich integriert werden konnten, dass die einzelnenMitglieder in der Lage sind, eigenstandig Probleme zu losen und sich nicht durchgelegentliche Ruckschlage von einem einmal eingeschlagenen Weg abbringen las-sen.

Wurde man vor die Wahl gestellt werden, ob man sich bei einem erneu-ten Projekt noch einmal fur die selben Mittel und Wege entscheiden wurde,so sprechen am Ende dieses Projektes selbstverstandlich immer Dinge fur undgegen eine erneute Benutzung. So war einerseits der Einstieg in .NET und C#sehr komfortabel, einige Arbeitsschritte aber widerum sehr ungewohnlich undmanchmal auch umstandlich. Vor allem das aufgetretene Problem im Bereichdes Multithreading und insebesondere die Tests, um es zu beseitigen, lassen dar-an zweifeln, dass man eine große Serveranwendung ohne weiteres und in einemsolchen Projektgruppenrahmen im Visual Studio entwickeln kann. So mussteman vorher sicherstellen, dass man zum Beispiel durch einen Drittanbieter alleBereiche des Multithreadings ausgiebig testen kann, wenn dies nicht in VisualStudio so moglich ist, wie man es individuell erwartet. Dennoch mochte mandie gewonnenen Erfahrung mit der gewahlten Umgebung nicht missen und isteiner erneuten Nutzung nicht abgeneigt, besonders da man jetzt mehrere Seitenkennt und aus dieser Erfahrung heraus vor und Nachteile entsprechend abwiegenkann.

8.5 Arbeit als Projektgruppe

Die Gruppe hatte das Gluck, aus wirklich sehr umganglichen Charakteren zu-sammengesetzt worden zu sein. Die Stimmung in der Gruppe war eigentlich niewirklich negativ, was sich naturlich auch auf die Arbeit an sich auswirkt, da sel-ten Spannungen herschten, die das Arbeitsklima geschadigt hatten. Sicherlichware es fur eine Projektgruppe interessant gewesen, wenn sie intern personlicheKonflikte hatte bewaltigen mussen und nicht nur Probleme programmiertech-nischer Natur, zumal im wahren Leben vermutlich ebenfalls nicht immer einreibungloses Klima herschen wird. Dieses Fehlen hat aber niemanden wirklichgestort, so dass die Arbeit in der Gruppe dennoch viel Erfahrung und auch demeinen oder anderen Spaß einbrachte.

Einige dieser Erfahrungen konnte man schon im Softwarprojekt sammeln,doch ist sicherlich allen aufgefallen, dass die Arbeit in der Projektgruppe sichin wesentlichen Bereichen davon unterscheidet. Wie schon erwahnt, ware da dieThemenfindung zu nennen, die vollig selbstverantwortliche Zeiteinteilung oderauch die selbstandige Wahl von Vorgehensweisen, Definitionen, Entwicklungs-umgebungen usw. Aber gerade diese eigene Verantwortung im Projekt hat einenGroßteil der gewonnenen Erfahrung ausgemacht.

166

Page 167: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

8.6 Die Arbeit mit Scrum

Die Entscheidung, mit einem alternativen Entwicklungsmodell zu arbeiten, warvielleicht riskant, da man im Studium dem Konzept Scrum noch nicht begeg-net war, aber am Ende dieser Projektgruppe darf man wohl sagen, dass diesesModell sehr gut mit unserer Gruppe harmonierte.

Zum einen ist das Backlog eine gute Methode gewesen, um die Aufgabenim Uberblick zu behalten, zum anderen gab es aber auch eine Moglichkeit dasProjekt um neue, unerkannte Aufgaben zu erweitern und auf neue Ereignisseentsprechend zu reagieren.

Die Aufteilung des Semesters in die jeweiligen Sprints gab ebenfalls immereine gute Orientierung und man konnte in etwa einschatzen, welche neuen Auf-gaben noch hinzugefugt werden konnen und welche optionalen Aufgaben nichtmehr mit aufgenommen werden sollten.

Durch die Sprint-Review-Meetings war man des Weiteren motiviert, den Be-treuern jeden Monat etwas Neues zu zeigen und das Projekt voranzutreiben.Die Gruppe hatte so auch die Moglichkeit, sich jederzeit Verbesserungsvorschla-ge und Wunsche der Betreuer einzuholen und diese direkt im nachsten Sprintumzusetzen.

Nach dem ersten Sprint hatte die Gruppe im Prinzip immer eine lauffahigeVersion des Projektes zur Verfugung, so dass einerseits die Gruppe immer ei-ne Orientierung innerhalb der Sprints hatte und andererseits die Betreuer sichInformationen uber den aktuellen Entwicklungsstand einholen und der Gruppeweitere Hinweise und Anmerkungen geben konnten.

8.7 Ausblick

Auf Basis der Projektergebnisse ware es nur logisch, das bestehende Programmzu einem kommerziellen Energieinformationssystem weiterzuentwickeln. Die Er-fassung der Basisdaten ist aus Sicht der Projektgruppe bereits gegeben. Diefehlenden Leistungsmerkmale, die man von einem kommerziellen System erwar-ten wurde, betreffen in erster Linie abwicklungstechnische Aspekte. Hierzu zahltbeispielsweise ein Rechnungswesen, das automatisch Kundenrechnungen erstellt,Abbuchungen vornimmt oder Finanzbilanzen erstellt. Daruber hinaus ware einedirekte Anbindung an die EEX uber eine digitale Schnittstelle anstatt der bishe-rigen Faxverschickung wunschenswert, um einen reibungsloseren Handel an derStromborse zu ermoglichen. Dies ermoglichte auch eine bessere Erstellung vonKaufempfehlungen, so dass Vorschlage und Entscheidungen anhand einer große-ren Datenbasis getroffen werden konnten. Denkbar ware auch eine verbesserteIntegration von Stromlieferanten, denen man eine direktere Anbindung an daseigene System uber den Webservice bereitstellt, um etwa Angebote unmittel-bar in den Datenbestand einzuspeisen. Zusammenfassend lasst sich sagen, dassmit dem Energieinformationssystem der Projektgruppe eine solide Grundlagefur Energieunternehmen geschaffen wurde, auf der sowohl individuelle als auchallgemeinere Losungen entwickelt werden konnen.

Anbei eine Liste mit moglichen neuen Leistungsmerkmalen, entstanden ausden vorangegangenen Uberlegungen, die man zum Beispiel auf weitere Sprintsinnerhalb eines Scrum-Prozesses aufteilen konnte:

167

Page 168: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Externe Anbindung: Offentliche Schnittstelle fur Stromlieferanten zur Angabevon Angeboten: So ware es im Programm moglich, nicht mehr nur durchmanuelle Eingabe, sondern automatisiert und damit arbeitssprarend undin Echtzeit Angebote anderer Stromhandler zu erfassen.

Verwaltung der Stammdaten: Erweiterte Stammdatenverwaltung z. B. fur Er-innerungen an den Benutzer bei wichtigen Ereignissen wie Neuerichtungvon Bilanzkreisen, Tarifumstellung usw.: Dadurch wurde verhindert, dassder Systemnutzer wichtige Geschehnisse in seinem Verantwortungsbereichnicht bemerkt, wodurch dem Energiehandler Schaden entstehen konnte.

Weboberflache: Erstellung einer webbasierten GUI: Durch dieses Feature warees nicht mehr nur moglich, das Programm uber die vorgegebene Oberfla-che, sondern uber einen normalen Webbrowser zu nutzen.

Algorithmen zur Kaufempfehlung und Lastprognose: Zusatzliche, mitgeliefer-te Algorithmen, die nach anderen Maßgaben arbeiten: Man wurde demBenutzer weitere Algorithem liefern oder alte austauschen, um etwa dieKaufempfehlung noch zu optimieren und diesen Prozess in der Laufzeitschneller zu gestalten. So konnte man auch uberlegen, ein Update zu lie-fern, welches einem nach einem bestimmten Zeitraum immer die neuestenAlgorithmen fur das Programm zur Verfugung stellt.

Erweiterung der Benutzertypen: Neue Rollen bzw. neue Moglichkeiten zur Rol-lenverwaltung integrieren: Kunden des Programms konnten hier die indi-viduellen Berechtigungen fur die Nutzer selbst konfigurieren.

Energieborse EEX: Erweiterte Anbindung an den kostenpflichtigen Service derEEX: Durch dieses Feature fiele die bisher umstandliche, aber derzeit nichtanders mogilche Nutzung der EEX weg, und zusatzlich wurde die Inter-aktion mit ihr beschleunigt.

Lokalisierung: Ubersetzung des Programms in andere weitverbreitete Sprachenwie Englisch oder Franzosisch: Somit ware das Programm nicht mehr nurin der deutschen Sprache verfasst, und man konnte einen internationalenKundenstamm aufbauen.

Erweiterte Benutzbarkeit: Anpassung der Oberflache und Bedienung an Stan-dards der Usability und des barrierefreien Zugangs: Indem moglichst we-nige die Benutzung des Program als schwierig empfinden und niemandganzlich aufgrund von Behinderungen von der Nutzung ausgeschlossenwird, erhoht sich die Akzeptanz des Programms ebenfalls.

168

Page 169: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9 Benutzerhandbuch

9.1 Willkommen

Vielen Dank, dass sie sich fur unser Produkt EIS entschieden haben. DiesesHandbuch soll Ihnen den Einstieg in das Programm erleichtern und Hilfestel-lungen geben, falls Sie einmal nicht weiter kommen.

Ihr EIS-Team

9.2 Systemvorausetzungen

9.2.1 Hardware

Fur den Betrieb des Energieinformationssystems EIS sind folgende Systemvor-raussetzungen empfohlen:

• Prozessor mit mind. 2 GHz Taktung

• 1 GB Hauptspeicher (fur die Serverkomponente moglichst 2 GB)

• 500 MB Festplattenplatz (fur den Server mit Datenbank entsprechendmehr)

9.2.2 Betriebsystem

Als Betriebssystem werden folgende Plattformen untersutzt:

Clientanwendung:

• Windows XP oder hoher.

• installiertes .NET-2.0-Framework

Server:

• Windows 2003 Server oder hoher.

• installiertes .NET-2.0-Framework

• installierter Internet Information Server

9.2.3 Datenbank

• Microsoft SQL Server 2005 oder

• Microsoft SQL Server 2005 Express

169

Page 170: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.3 Installation

In diesem Kapitel werden die Schritte erklart, die notig sind um eine neue In-stallation von EIS in Betrieb zu nehmen. Diese Schritte mussen vom System-administrator vorgenommen werden.

9.3.1 Installation der Serverkomponenten

Legen Sie die DVD–ROM in das DVD–ROM–Laufwerk ein. Wenn der Autostartnicht deaktiviert wurde, wird automatisch ein Fenster geladen, in dem Sie auf“Server-Komponenten“ klicken mussen. Daraufhin startet das Installationspro-gramm fur die Severkomponenten. Hier werden Sie aufgefordert, einen Namenfur das virtuelle Verzeichnis im Internet Information Server anzugeben. DiesenNamen mussen Sie sich merken, da er fur die Konfiguration der Clientanwen-dung benotigt wird.

9.3.2 Datenbank aufsetzen

Im Anschluss an die Serverinstallation muss die Datenbank eingerichtet werden.Dazu benotigen Sie einen Server mit installiertem SQL Server 2005. Dies kannauch derselbe Server sein, auf dem auch der IIS lauft. Um Hilfe fur die Instal-lation des MS SQL Server zu erhalten, konsultieren Sie die Dokumentation desSQL-Servers. Dabei ist es wichtig, dass Sie fur die Anmeldung am SQL-Serverden so genannten Mixed Mode erlauben. Naheres dazu finden sie ebenfalls inder SQL-Server-Dokumentation. Nachdem Sie den Datenbankserver erfolgreichinstalliert haben, mussen Sie die mitgelieferte Datenbankdatei zum Server hin-zufugen. Dazu benotigen Sie das SQL Server Management Studio, welches freiverfugbar ist und auf den Internetseiten von Microsoft heruntergeladen werdenkann. Im Folgenden wird beschrieben, wie Sie die mitgelieferte Grunddatenbankmithilfe des SQL Management Studios installieren konnen.

Starten Sie zunachst das SQL Server Management Studio. Nachdem Sie sicherfolgreich an Ihrem Server angemeldet haben, klicken Sie im Objektexplorermit der rechten Maustaste auf den Eintrag Databases (siehe Abbildung 85).

170

Page 171: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 85: SQL Server Management Studio

Durch den Klick auf Attach ... offnet sich ein weiteres Fenster (siehe Abbil-dung 86),

in dem Sie zunachst auf Add ... klicken mussen. Daraufhin erscheint ein Da-teibrowser, mit dessen Hilfe Sie die Datei ”EISDB.mdf” auswahlen. Diese Dateibefindet sich in dem Ordner, in welchem Sie die Serverkomponenten der EIS-Software installiert haben (Ublicherweise c:/inetpub/wwwroot/SetupServer).Die Datei wird jetzt in der Liste “Databases to attach“ angezeigt. Klicken Sienun 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 Rechnerninstalliert sind, muss der Datenbankserver so konfiguriert werden, dass das TCP-Protokoll genutzt wird. Um das TCP-Protokoll zu aktivieren, starten Sie denSQL Server Configuration Manager. Im Unterpunkt SQL Native Client Confi-guration / Client Protocols mussen Sie das TCP/IP-Protokoll aktivieren. Bittebeachten Sie, dass fur die Nutzung des Protokolls der dazu jeweilige Port (Stan-dard ist 1433) in Ihrer Firewallsoftware freigeschaltet werden muss. KonsultierenSie dazu die Hilfe oder Dokumentation Ihrer Firewallsoftware oder wenden Siesich an Ihren Systemadministrator.

171

Page 172: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 86: SQL Server Management Studio - Datenbankdatei auswahlen

9.3.3 Konfiguration der Datenbankverbindung

Um die Verbindung des EIS-Servers zur Datenbank zu erstellen, starten Sie un-ter Systemsteuerung / Verwaltung den Internet-Informationsdienste-Manager.Wahlen Sie das virtuelle Verzeichnis aus, das Sie bei der Serverinstalltion ange-geben haben und klicken Sie mit der rechten Maustaste auf den Eintrag “Eigen-schaften“. Auf der Karteikarte “ASP.NET“ wahlen Sie bitte unter ASP.NET-Version den Eintrag mit der Versionsnummer 2 aus. Klicken Sie dann auf dieSchaltflache Konfiguration bearbeiten .... Daraufhin wird ein neues Fenster ge-offnet. Hier mussen Sie nun die Verbindungszeichenfolge “EISSQLSERVER“ be-arbeiten. Tragen Sie hier eine gultige Zeichenfolge fur die Verbindung zu IhremDatenbankserver ein. Beachten Sie bitte, dass Sie einem neu angelegten Daten-banknutzer auch die entsprechenden Rechte an der EISDB erteilen, siehe dazuAbbildung 87.

9.3.4 EEX-Marktdaten aktualisieren

Nachdem Sie die Datenbankkonfiguration abgeschlossen haben, fuhren Sie dieVerknupfung ”EEX-Marktdaten aktualisieren”auf dem Desktop des Servers aus.Dies ist nur einmal nach der Installation notig. Wahlen Sie die Option ”Alle

172

Page 173: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 87: Vergabe der Benutzerrechte

Marktdaten aktualisieren”und klicken Sie auf ”Ausfuhren” (siehe Abbildung 88.Ohne diesen Schritt sind die EEX Funktionen des EIS nicht verfugbar.

9.3.5 Installation der Clientanwendung

Legen Sie die DVD–ROM in das DVD–ROM–Laufwerk ein. Wenn der Autostartnicht deaktiviert wurde, wird automatisch ein Fenster geladen, in dem Sie auf“Client-Komponenten“ klicken mussen. Daraufhin startet das Installationspro-gramm fur die Clientanwendung. Folgen Sie den Anweisungen auf dem Bild-schirm, um den Client zu installieren. Beim ersten Start der Clientanwendungwird der Nuzer aufgefordert, die URL zum EIS-Server anzugeben. Diese mussmit dem Prafix “http://“, gefolgt vom Servernamen und nach einem Doppel-punkt der Portnummer des Webservers (Standard ist 80), angegeben werden.Nach einem weiteren Schragstrich geben Sie den unter der Serverinstallationfestgelegten Namen gefolgt von “/Service.asmx“ an.

173

Page 174: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 88: Auswahlfenster zum Aktualisieren der EEX Marktdaten

9.4 Erste Schritte

9.4.1 Programm starten

Offnen Sie das EIS–Symbol auf dem Desktop oder starten Sie die Verknupfungim Windows–Startmenu.

9.4.2 Serveradresse angeben

Beim ersten Start des Programms werden Sie nach der URL des Webservice aufder Serverseite gefragt. Geben Sie die entsprechende URL an und klicken Sieauf ”Speichern”. Diese Abfrage ist einmalig.

9.4.3 Einloggen

Allgemeine Hinweise zum Loginfenster: Um sich am Programm anzumelden,mussen 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 klickenSie auf ”Anmelden”. Um den Vorgang abzubrechen, klicken Sie auf ”Abbrechen”.

9.4.4 Administratorpasswort andern

Loggen Sie sich mit dem Benutzernamen ”admin”ein. Das Passwort lautet eben-falls ”admin” (ohne Anfuhrungszeichen). Wahlen Sie aus dem Menu den Punkt”Systemnutzer”. Wahlen Sie dann das Admin-Konto aus, und klicken Sie die

174

Page 175: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Schaltflache ”Bearbeiten”. Andern Sie die Daten wie gewunscht. BesonderesAugenmerk gilt hier dem Passwort des Administratorkontos. Geben Sie unter”Passwort” Ihr neues Kontopasswort ein, bestatigen Sie es noch einmal in demFeld darunter. Nach erfolgter Eingabe klicken Sie ”Speichern”, um die Anderun-gen zu ubernehmen.

Nun wird es Zeit, einige Nutzer anzulegen, die fur die einzelnen Funktionendes Programms Zugriffsrechte haben.

9.4.5 Benutzer anlegen

Legen Sie Benutzer mit den jeweiligen Rollen an. Genauere Informationen zuder Erstellung von Systemnutzern und verschiedenen Rollen (Rechten), die einSystemnutzer haben kann, finden Sie im Abschnitt ”Systemnutzer“.

175

Page 176: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.5 Der Startbildschirm

Abbildung 89: Die Startoberflache des Programms

Nach dem Einloggen sehen Sie als erstes den Starbildschirm, Abbildung 89,des EIS. Hier finden Sie eine Ubersicht uber die wichtigsten Daten, Termine undVorfalle, die das EIS betreffen. Im Bereich ”Uberblick”finden Sie oben eine Listeder aktuellen Storungen. Darunter eine Liste mit in weniger als einem Monatauslaufenden Kundenvertragen und widerrum darunter eine Liste mit bald aus-laufenden Liefervertragen. Auf der rechten Seite finden Sie ein Tortendiagramm,welches die prozentuale Verteilung der Tarife verdeutlicht.

Direkt unter dem uberlick finden Sie das sog. ToDo Panel.

176

Page 177: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.6 Das ToDo-Panel

Im ToDo-Panel, siehe Abbildung 90, konnen Sie ihre personlichen Aufgaben undNotizen verwalten. Klicken Sie ”Anlegen” um eine neue Aufgabe anzulegen.

Abbildung 90: Hier geben Sie die Daten in die ToDo-Liste ein

Fullen Sie die Felder aus. Als Code konnen Sie eine bliebige Zeichengfolge(bis zu 10 Stellen) wahlen, die Ihnen spater das wiederfinden erleichtert. UnterStatus wahlen Sie den aktuellen Status der Aufgabe aus. Unter ”Aufgabe”gebenSie dann eine Beschreibung der Aufgabe ein.

Mit einem Klick auf ”Bearbeiten”konnen Sie eine bestehende Aufgabe offnenund den Status und/oder die Aufgabenbeschreibung andern.

Mit einem Klick auf ”Loschen” konnen Sie eine abgeschlossene Aufgabe ausder Liste loschen.

177

Page 178: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.7 Fehlermeldungen

Wahrend der Benutzung des EIS werden Sie das ein oder andere Mal auf eineFehlermeldung stoßen. Es gibt zwei Arten von Fehlern, die auftreten konnen.Zunachst einmal so genannte Exceptions. Dieses sind Fehler, die durch Falschein-gaben und/oder Datenbankfehler erzeugt werden. Sollte solche eine Exceptionauftreten, weist Sie das EIS mit einem Fenster darauf hin. Dieses sieht wie inAbbildung 91 aus.

Abbildung 91: Fehlermeldung bei inkorrekten Daten

Hier finden Sie eine Beschreibung des Fehlers und ein Eingabefeld, in dem Sieeinen Kommentar fur den Systemadministrator hinterlassen konnen. Beispiels-weise konnen Sie hier Ihre letzten Schritte bevor der Fehler auftrat eintragenund 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,fur die Ihr Benutzerkonto keine Berechtigung hat.

Abbildung 92: Eine Fehlermeldung, die Sie auf unzureichende Rechte hinweist.

178

Page 179: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.8 Auswahlfenster

Im Laufe der Benutzung von EIS werden Sie auf einige Auswahlfenster stoßen,die sich nach dem Klick auf ein Lupensymbol offnen. Hier eine kleine Ubersicht:

9.8.1 Auswahl fur Tarife

Abbildung 93: Das Auswahlfenster fur Tarife

Wahlen Sie einen Tarif aus und klicken Sie auf ”Auswahlen”, um den Tarifauszuwahlen. Ein Klick auf ”Abbrechen”bricht die Auswahl ab (siehe Abbildung93).

9.8.2 Auswahl fur Regelzonen

Abbildung 94: Das Auswahlfenster fur Regelzonen

Wahlen Sie eine Regelzone aus und klicken Sie auf ”Auswahlen”, um die ent-sprechende Regelzone zu ubernehmen. Mit einem Klick auf ”Abbrechen”brechenSie die Auswahl ab. Um die Regelzonen einzugrenzen, konnen Sie einen Suchbe-griff und einen Suchbereich eingeben und mit ”Suchen” eine Suche starten (sieheAbbildung 94).

179

Page 180: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.8.3 Auswahl fur Lastprofile

Abbildung 95: Das Auswahlfenster fur Lastprofile

Wahlen Sie ein Lastprofil aus und klicken Sie auf ”Auswahlen”, um es zuubernehmen. Klicken Sie auf ”Abbrechen”, um die Auswahl abzubrechen, ohneein Lastprofil zu ubernehmen (siehe Abbildung 95).

9.8.4 Auswahl fur Bilanzkreise

Abbildung 96: Das Auswahlfenster fur Bilanzkreise

Wahlen Sie einen Bilanzkreis aus und klicken Sie auf ”Auswahlen”, um denBilanzkreis zu ubernehmen. Mit einem Klick auf ”Abbrechen” brechen Sie dieAuswahl ab. Um die Bilanzkreise einzugrenzen, konnen Sie einen Suchbegriffund einen Suchbreich eingeben und mit ”Suchen” entsprechende Bilanzkreiseauflisten (siehe Abbildung 96).

180

Page 181: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.9 Kunden

In der Kundenverwaltung konnen Kundendaten angelegt, verandert und ge-loscht werden. Außerdem werden hier Kundenvertrage den Kunden zugeord-net. Es konnen Kundenvertrage neu hinzugefugt, bearbeitet und auch geloschtwerden. In den folgenden Abschnitten erfahren Sie, wie Kundendaten und de-ren Vertrage angelegt, bearbeitet und geloscht werden. Abbildung 97 zeigt dieOberflache der Kundenverwaltung.

Abbildung 97: Die Oberflache zur Verwaltung von Kunden und deren Vertrage

9.9.1 Kunden anlegen

Zum Anlegen eines Kunden mussen Sie als Kundenbetreuer eingeloggt sein.Wahlen Sie im Auswahlmenu oder dem Programmmenu den Punkt ”Kunden”aus. Klicken Sie die Schaltflache ”Anlegen...” und fullen Sie die entsprechendenFelder aus (siehe Abbildung 98). Wenn Sie alle benotigten Felder korrekt ausge-fullt haben (die Uberprufung der Eingaben erfolgt im ubrigen transparent, d.h.,wahrend der Eingabe werden ihre Angaben auf Stimmigkeit gepruft), klickenSie auf die Schaltflache ”Speichern“. Ihr Kundendatensatz wird vom Programm

181

Page 182: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

abgespeichert und steht Ihnen in der Kundenverwaltung zur Verfugung. WollenSie den eigegebenen Datensatz nicht speichern, so klicken Sie auf ”Abbrechen“oder schließen Sie das Fenster mit einem Klick auf das Kreuz in der rechtenoberen 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 Kun-den in die am oberen Rand der Kundenverwaltung befindliche Suchmaske ein.Wahlen Sie die Art der Suche im Klappmenu links neben der Suchmaske aus, ge-ben Sie den Suchbegriff ein und klicken sie auf die Schaltflache ”Suchen”. WahlenSie das Ergebnis bzw. eines der Ergebnisse der Suche aus, und klicken Sie dieSchaltflache ”Bearbeiten ...”. Die Maske fur Kundendaten offnet sich mit denDaten des ausgewahlten Kundendatensatzes (siehe Abbildung 99). Fugen Siedie gewunschten Anderungen ein und klicken Sie die Schaltflache ”Speichern”.Um den Vorgang abzubrechen, klicken Sie auf ”Abbrechen“ oder auf das Kreuzin der Ecke oben rechts der Maske.

Abbildung 99: Einen bestehenden Kunden bearbeiten

182

Page 183: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.9.3 Kunden loschen

Abbildung 100: Einen bestehenden Kunden loschen

Um einen Kundendatensatz zu loschen, vollziehen Sie eine Suche wie unter”Kundendaten bearbeiten” beschrieben, oder wahlen Sie den gewunschten Kun-dendatensatz direkt in der Kundendatenliste aus. Klicken Sie jetzt die Schalt-flache ”Loschen”. bestaigen Sie die Sicherheitsabfrage mit einem Klick auf dieSchaltflache ”Ja” (siehe Abbildung 100). Der Kunde ist nun aus der Datenbankgeloscht. Zu beachten: Es konnen nur Kundendaten geloscht werden, die nichtin einem laufenden Kundenvertrag verankert sind.

9.9.4 Kundenvertrag anlegen

Abbildung 101: Einen neuen Kundenvertrag anlegen

Um einen Kundenvertrag anzulegen, wahlen Sie zunachst einen Kunden aus,fur den Sie einen Vertrag anlegen mochten. Wenn Sie einen Kunden ausgewahlthaben, erscheinen auf der Vertragsanzeige alle Vertrage, die diesem Kunden be-reits zugeordnet sind. Klicken Sie nun die Schaltflache ”Anlegen ...“, um einem

183

Page 184: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Kunden einen neuen Vertrag zuzuordnen. Fullen Sie alle Felder aus (siehe Ab-bildung 101). Die Eintrage fur Lastprofil, Tarif, Regelzone, Bilanzkreis wahlenSie aus dem Menu aus, welches sich durch klicken des Lupensymbols offnet, dasrechts neben dem jeweiligen Textfeld positioniert ist. Wenn Sie alle Felder aufder linken Seite ausgefullt haben, werden die Eintrage der rechten Seite auto-matisch berechnet. Wenn Sie mit den Eingaben einverstanden sind, klicken Sieauf die Schaltflache ”Speichern“ oder auf die Schaltflache ”Abbrechen“, wenn Siedie Daten nicht speichern wollen.

Auf den folgenden vier Abbildungen sehen Sie die Fenster, in denen Sie fureinen Vertrag ein Lastprofil (siehe Abbildung 102), einen Tarif (siehe Abbil-dung 103), eine Regelzone (siehe Abbildung 104) und einen Bilanzkreis (sieheAbbildung 105) auswahlen.

Abbildung 102: Einem Kunden ein Lastprofil zuweisen

Abbildung 103: Einem Kunden einen Tarif zuweisen

184

Page 185: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

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, wahlen Sie zu-nachst den betreffenden Kunden aus der Liste aus. Es erscheinen nun alle Ver-trage, die diesem Kunden zugeordnet sind. Wahlen Sie den Vertrag aus, den Siebearbeiten wollen, indem Sie auf die Schaltflache ”Bearbeiten...“ klicken oderdoppelklicken Sie auf den zu bearbeitenden Vertrag. Es erscheint eine weitereMaske auf dem Bildschirm, die mit den Vertragsdaten gefullt ist (siehe Ab-bildung 106). Nehmen Sie die notwendigen Anderungen des Vertrags vor unddrucken Sie anschließend auf die Schaltflache ”Speichern“ wenn Sie die Datenspeichern wollen oder klicken Sie auf ”Abbrechen“ wenn Sie die Daten nichtandern wollen.

9.9.6 Kundenvertrag loschen

Wenn Sie einen bestehenden Kundenvertrag bearbeiten wollen, wahlen Sie zu-nachst den betreffenden Kunden aus der Liste aus. Es erscheinen nun alle Vertra-

185

Page 186: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 106: Einen bestehenden Kundenvertrag bearbeiten

ge, die diesem Kunden zugeordnet sind. Wahlen Sie den zu loschenden Vertragan, so dass dieser blau markiert ist und klicken Sie die Schaltflache ”Loschen“.

186

Page 187: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.10 Lastprofile

In der Lastprofilverwaltung (siehe Abbildung 107) konnen Sie neue Lastpro-file anlegen, bearbeiten oder loschen. Sie konnen bestehende Lastprofile mit dergegebenen Suchfunktion suchen. Durch klicken der Schaltflache ”Zurucksetzen“wird Ihre Eingabe aus der Suchmaske entfernt.

Abbildung 107: Die Oberflache zur Verwaltung von Lastprofilen

9.10.1 Lastprofile anlegen

Sie konnen ein neues Lastprofil anlegen, indem Sie die Schaltflache ”Anlegen...“klicken. Es offnet sich eine Eingabemaske (siehe Abbildung 108), in der Sie diegeforderten Daten eingeben mussen. Die Eingabe eines Lastprofils ist zeitauf-wendig, da ein vollstandiges Lastprofil aus 96 Eingaben besteht. Wenn Sie dasneue Lastprofil speichern mochten, klicken Sie auf die Schaltflache ”Speichern“.Um den Vorgang abzubrechen, klicken Sie auf ”Abbrechen“.

187

Page 188: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 108: Ein neues Lastprofil anlegen

9.10.2 Lastprofile bearbeiten

Sie konnen bestehende Lastprofile einfach bearbeiten. Wahlen Sie das zu bear-beitende Lastprofil aus der Liste aus, klicken Sie anschließend die Schaltflache

”Bearbeiten...“. Es offnet sich eine Eingabemaske (siehe Abbildung 109), die mitden Daten des zu bearbeitenden Lastprofils gefullt ist. Andern Sie die Felder,die Sie andern mochten und drucken Sie zum Bestatigen auf die Schaltflache

”Speichern“. Um den Vorgang abzubrechen, klicken Sie auf ”Abbrechen“.

Abbildung 109: Ein Lastprofil bearbeiten

9.10.3 Lastprofile loschen

Wenn Sie ein Lastprofil loschen wollen, markieren Sie das zu loschende Lastprofilund drucken Sie auf ”Loschen“. Bestatigen Sie die folgende Sicherheitsabfragemit ”Ja“, wenn Sie das ausgewahlte Lastprofil loschen mochten oder drucken Sie

”Nein“, wenn Sie das Lastprofil nicht loschen wollen.

188

Page 189: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.11 Tarife

In der Tarifverwaltung (siehe Abbildung 111) konnen Tarife hinzugefugt,bearbeitet oder geloscht werden. Bestehende Tarife konnen auf ”aktiv“ oder auf

”inaktiv“ gestellt sein. Ist ein Tarif aktiv, so kann in der Kundenverwaltungein Kundenvertrag mit diesem Tarif eingegeben werden. Ist er nicht aktiv, soerscheint er nicht in der Kundenverwaltung.

Abbildung 110: Die Oberflache zur Verwaltung von Tarifen

9.11.1 Tarife anlegen

Wenn Sie einen Tarif anlegen mochten, klicken Sie auf die Schaltflache ”Anle-gen...“. Es erscheint ein neues Fenster (siehe Abbildung 111). Hier tragen Siedie dort verlangten Attribute ein. Ein Tarif kann nur dann ubernommen wer-den, wenn alle Felder korrekt ausgefullt sind. Haben Sie einen Tarif angelegt,erscheint er in der Liste der Tarife als inaktiv. Um diesen Tarif verwenden zukonnen, mussen Sie ihn durch Klicken auf die Schaltflache ”(De)aktivieren“ ak-tivieren.

189

Page 190: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 111: Einen neuen Tarif anlegen

9.11.2 Tarife bearbeiten

Wenn Sie einen Tarif bearbeiten mochten, wahlen Sie diesen aus der Liste ausund klicken Sie auf die Schaltflache ”Bearbeiten...“ oder doppelklicken Sie aufden zu bearbeitenden Tarif. Es erscheint ein neues Fenster (siehe Abbildung112). Sie konnen nun die Attribute bearbeiten. Durch Betatigen der Schaltfla-che ”Speichern“ werden die neuen Werte in das Programm ubernommen. DurchBetatigen der Schaltflache ”Abbrechen“ werden keine Anderungen am Tarif ge-speichert und der Vorgang abgebrochen.

Abbildung 112: Einen Tarif bearbeiten

9.11.3 Tarife loschen

Sie konnen nur dann einen Tarif loschen, wenn er inaktiv ist. Mochten Sie eineninaktiven Tarif loschen, so klicken Sie auf die Schaltflache ”Loschen“. Der Tarifwird nun aus der Liste entfernt.

190

Page 191: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.12 Fahrplane

In der Fahrplanverwaltung (siehe Abbildung 113) konnen Sie Ihre Fahrplaneautomatisch erstellen. Das Ergebnis ist eine XML-Datei im ESS-Format. Siekonnen hier naturlich auch problemlos bereits erstellte Fahrplane loschen. WieSie dies machen, erfahren Sie in den nachsten Abschnitten.

Abbildung 113: Die Oberflache zur Erstellung von Fahrplanen

9.12.1 Fahrplan erstellen

Wenn Sie einen Fahrplan erstellen mochten, brauchen Sie lediglich ein Datumauszuwahlen, fur das ein Fahrplan erstellt werden soll. Außerdem mussen Sienoch den entsprechenden Bilanzkreis und die Regelzone bestimmen. Diese wah-len Sie aus den neben der Datumseingabe positionierten Ausklappmenus. SolltenSie hier keine Bilanzkreise oder Regelzonen auswahlbar sein, uberprufen Sie un-ter dem Menupunkt ”Bilanzkreise und Regelzonen“ ob Sie eine CSV–Datei mitBilanzkreis– und Regelzonendaten in die Datenbank ubertragen haben. WennIhre Eingaben vom System akzeptiert wurden, mussen Sie noch einen Zielordnerfur die erstellte XML–Datei bestimmen. Der Name der erzeugten XML–Datei

191

Page 192: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

wird automatisch nach den Regeln der ETSO bestimmt. Erstellte Fahrplane fin-den Sie in der Liste ”Vorhandene Fahrplane“. Durch Markieren eines erstelltenFahrplanes in dieser Liste wird der Inhalt der XML–Datei auf der rechten Seiteangezeigt (siehe Abbildung 114).

9.12.2 Fahrplan loschen

Sie konnen Fahrplane entweder fur einen Tag loschen oder gleich alle vorhande-nen. Hierzu geben Sie entweder ein Datum ein, fur das alle vorhandenen Fahrpla-ne entfernt werden sollen, oder klicken Sie auf die Schaltflache ”Loschen“ nebendem Text ”Alle Fahrplane loschen“. Achtung: Durch diese Maßnahme werdenalle Fahrplane unwiderruflich aus der Datenbank geloscht! Eine Loschung derzugehorigen XML-Dateien findet allerdings nicht statt. Diese Dateien mussenSie gegebenenfalls manuell aus dem Dateisystem Ihres Computers loschen.

Abbildung 114: Einen Fahrplan im Browserfenster anzeigen

192

Page 193: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.13 Kaufempfehlungen

Um eine Kaufempfehlung zu erhalten, sind nur wenige Schritte notwendig.Beachten Sie, dass zur Austellung einer Kaufempfehlung zuvor eine Lastpro-gnose generiert worden sein muss, da sich der Kaufempfehlungsalgorithmus aufDaten und Vorgaben aus einer Lastprognose angewiesen ist (siehe ”Lastprogno-sen”).

9.13.1 Schritt 1

Wahlen Sie den Menupunkt ”Kaufempfehlungen” aus dem (Programm–)Menu.Es offnet sich die Programmseite fur Kaufempfehlungen. Wenn Sie eine Last-prognose als Basis gewahlt haben (siehe Abbildung 115), klicken Sie auf dieSchaltflache ”Weiter...”, um zu Schritt 2 zu gelangen.

Abbildung 115: Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 1

193

Page 194: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.13.2 Schritt 2

Im 2. Schritt wahlen Sie nun aus den bestehenden Liefervertragen mit Lieferan-ten diejenigen Vertrage aus, die entweder auf jeden Fall oder auf keinen Fall indie Kaufempfehlung mit einbezogen werden sollen (siehe Abbildung 116). Dazufinden Sie in der außerst rechten Spalte fur jeden Vertrag eine sog. ”Checkbox”,also ein Kastchen in dem Sie mit einem Mausclick einen Haken setzen (Vertragmiteinbeziehen) oder entfernen konnen (Vertrag nicht miteinbeziehen). SofernSie die initiale graue Markierung belassen, bleibt es dem Algorithmus freige-stellt, das betreffende Angebot zu berucksichtigen oder nicht. Haben Sie ihreAuswahl getroffen klicken Sie ”Weiter...”, um zu Schritt 3 der Kaufempfehlungzu gelangen.

Abbildung 116: Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 2

194

Page 195: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.13.3 Schritt 3

In diesem Schritt wahlen Sie das Plugin (externes Programmpaket) mit demvon Ihnen gewunschten Algorithmus zur Erstellung einer Kaufempfehlung (sie-he Abbildung 117). Im oberen Auswahlfenster wird Ihnen eine Auswahl vonverfugbaren Plugins angezeigt. Wahlen Sie das gewunschte Plugin mit einemKlick aus. In der unteren Halfte des Programmfensters wird die Versionsinfor-mation sowie eine kurze Beschreibung des gewahlten Plugins angezeigt. HabenSie sich fur ein Plugin entscheiden, klicken Sie ”Weiter...”, um zu Schritt 4 zugelangen.

Abbildung 117: Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 3

195

Page 196: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.13.4 Schritt 4

In diesem Abschnitt konfigurieren Sie die Einstellungen des in Schritt 3 gewahl-ten Plugins. Je nach Plugin werden Ihnen hier Moglichkeiten zur Anpassungdes entsprechenden Algorithmus gezeigt. Fur Informationen zu den jeweiligenverfugbaren Einstellungsmoglichkeiten konsultieren Sie die Dokumentation desPlugins in Schritt 3 oder der entsprechenden Dokumentation die jedem Pluginbeiliegen sollte. Sobald Sie alle Einstellungen ihren Wunschen angepasst haben,klicken Sie ”Prufen” (siehe Abbildung 118). Daraufhin werden die eingegebenenParameter auf Gultigkeit uberpruft. Sind sie nicht gultig, erhalten Sie eine Be-nachrichtigung und konnen die Werte korrigieren. Sind sie gultig, andert sichdie Beschriftung des Buttons zu ”Erstellen”. Klicken Sie ihn erneut, um dieKaufempfehlung generieren zu lassen und zum nachsten Schritt der Kaufemp-fehlungserstellung zu gelangen.

Abbildung 118: Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 4

196

Page 197: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.13.5 Schritt 5

Im 5. Schritt sehen Sie das Ergebnis der Berechnung der Kaufempfehlung. ImBereich ”Basisinformationen” finden Sie ubersichtsdaten fur die abgeschlosseneBerechnung (siehe Abbildung 119). ”Nr.” bezeichnet die laufende Nummer derKaufempfehlung. ”Erstellt” stellt das Datum der Erstellung der Kaufempfehlungdar. Das Zeitfenster fur die Gultigkeit der Kaufempfehlung ergibt sich aus denPunkten ”Gultig ab”und ”Gultig bis”. ”Gesamtbedarf” gibt den Bedarf an Ener-gie in MWh wieder der fur den entsprechenden Zeitraum der zugrundeliegendenLastprognose gilt. ”Gesamteinkauf” gibt die Energiemenge in MWh an, die derKaufempfehlungsalgorithmus zur Deckung des Gesamtbedarfs an Energie vor-geschlagen hat.Im unteren Bereich werden in einer ubersicht auf der linken Seite die zum Ab-schluss vorgeschlagenen Lieferangebote dargestellt. Auf der rechten Seite werdenbereits abgeschlossene Liefervertrage angezeigt.

Klicken sie auf ”Weiter”, um zum letzten Schritt zu gelangen.

Abbildung 119: Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 5

197

Page 198: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.13.6 Schritt 6

Im letzten Schritt der Kaufempfehlung konnen Sie Anderungen an der erstelltenKaufempfehlung vornehmen, dazu konnen Sie auf der rechten Seite der Ansichtandere infrage kommende Angebot zu der Kaufempfehlung hinzufugen (sieheAbbildung 120). Wahlen Sie dazu ein infragekommendes Angebot auf der rech-ten Seite und klicken sie ”Hinzufugen” um das Angebot zur Kaufempfehlunghinzuzufugen. Bereits hinzugefugte Lieferangebote konnen Sie auf der linkenSeite einsehen. Um eines dieser Angebote wieder aus der Liste zu entfernen,wahlen Sie das entsprechende Angebot aus, und klicken Sie auf ”Loschen”.

Um die Kaufempfehlung und damit die empfohlenen Angebote abzuschlie-ßen, klicken Sie auf die Schaltflache ”Fertigstellen...”.

Abbildung 120: Die Oberflache zur Erstellung von Kaufempfehlungen: Schritt 6

198

Page 199: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.14 Lieferanten

In der Lieferantenverwaltung (siehe Abbildung 121) haben Sie Zugriff auf dieDaten der im System gespeicherten Lieferantendaten und deren Vertrage. In denfolgenden Abschnitten erfahren Sie, wie Sie neue Lieferanten in die Datenbankspeichern, bearbeiten oder auch loschen konnen. Außerdem wird erklart, wie Siezu einem Lieferanten gehorende Liefervertrage bearbeiten oder loschen konnen.Sie erfahren außerdem, wie Sie neue Vertrage fur bestimmte Lieferanten erstellenkonnen.

Abbildung 121: Die Oberflache zur Verwaltung von Lieferanten

9.14.1 Lieferanten anlegen

Um einen neuen Lieferanten anzulegen, klicken Sie in der Lieferantenverwaltungauf die Schaltflache ”Anlegen...“. Das Programm offnet eine Eingabemaske, inwelche Sie die fur einen Lieferanten wichtigen Daten eingeben mussen. WennSie Felder auslassen, kann der neue Lieferant nicht angelegt werden. Haben Siealle Felder korrekt ausgefullt, so klicken Sie die Schaltflache ”Speichern“, umden neuen Lieferanten im System zu speichern, oder klicken Sie die Schaltflache

199

Page 200: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

”Abbrechen“, um den Vorgang abzubrechen, ohne einen neuen Lieferanten zuspeichern.

9.14.2 Lieferanten bearbeiten

Um einen bestehenden Lieferanten zu bearbeiten, suchen Sie diesen uber dieSuchfunktion des Programms aus. Markieren Sie den zu bearbeitenden Liefe-ranten, so dass dieser blau hinterlegt wird, und klicken Sie auf die Schaltflache

”Bearbeiten...“. Andern Sie die Daten ab, die Sie andern mochten, und betatigenSie anschließend die Schaltflache ”Speichern“ (siehe Abbildung 122). Wenn dievon Ihnen geanderten Daten zulassig sind, werden diese ubernommen. WollenSie die Daten nicht speichern, so klicken Sie auf die Schaltflache ”Abbrechen“oder auf das Kreuz in der rechten oberen Ecke der Eingabemaske.

Abbildung 122: Ein bestehenden Lieferanten bearbeiten

9.14.3 Lieferanten loschen

Wenn Sie einen Lieferanten loschen mochten, markieren Sie den zu loschendenLieferanten, so dass dieser blau hinterlegt ist und klicken Sie auf die Schaltflache

”Loschen“. Der Loschvorgang ist nur dann zulassig, wenn fur diesen Lieferantenkeine aktuellen Lieferangebote oder Liefervertrage vorhanden sind. Mochten Sieden Loschvorgang abbrechen, klicken Sie die Schaltflache ”Abbrechen“.

9.14.4 Lieferangebot/–vertrag anlegen

Sie konnen fur einen bestehenden Lieferanten ein neues Lieferangebot oder einenLiefervertrag anlegen. Wahlen Sie hierzu zunachst den Lieferanten aus der Listeaus, dem Sie ein Angebot oder einen Vertrag zuordnen mochten. Klicken Sieanschließend auf die Schaltflache ”Anlegen...“ in der Angebots- und Vertrags-verwaltung. Es offnet sich eine Eingabemaske (siehe Abbildung 123), in der Siealle Felder korrekt ausfullen mussen. Der Status gibt an, ob es sich bei IhrerEingabe um ein Angebot eines Lieferanten handelt oder um einen bereits ab-geschlossenen Vertrag. Sie konnen den Status eines Angebots jederzeit andern.Wahlen Sie die Regelzone und den entsprechenden Bilanzkreis aus, indem Sie auf

200

Page 201: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

das jeweilige Lupensymbol klicken (siehe Abbildung 124). Wenn Ihre Eingabenkorrekt sind, konnen Sie den Datensatz abspeichern. Wollen Sie den Datensatznicht speichern, klicken Sie die Schaltflache ”Abbrechen“ oder das Kreuz in derrechten oberen Ecke der Eingabemaske.

Abbildung 123: Ein Lieferangebot/-vertrag anlegen

Abbildung 124: Eine Regelzone auswahlen

9.14.5 Lieferangebot/-vertrag bearbeiten

Sie konnen bestehende Lieferangebote oder Liefervertrage bearbeiten. Hierzuwahlen Sie zunachst den Lieferanten aus, dessen Angebot oder Vertrag Sie be-arbeiten mochten. Klicken Sie anschließend auf die Schaltflache ”Bearbeiten...“der Angebots- und Vertragsverwaltung. Andern Sie die Daten, die Sie andernwollen, und betatigen Sie anschließend die Schaltflache ”Speichern“, wenn Siediese Daten abspeichern mochten, oder klicken Sie auf ”Abbrechen“, wenn Sieden alten Datensatz unverandert lassen mochten.

9.14.6 Lieferangebot/-vertrag loschen

Wenn Sie ein Angebot loschen wollen, das zu einem bestimmten Lieferantengehort, konnen Sie dies ohne Einschrankung tun, indem Sie den zu loschenden

201

Page 202: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Datensatz auswahlen und die Schaltflache ”Loschen“ aus der Angebots- undVertragsverwaltung klicken. Der Datensatz wird aus der Liste entfernt. WollenSie einen Vertrag loschen, ist dies nicht ohne weiteres moglich. Sie konnen einenVertrag nur dann loschen, wenn er ausgelaufen und ist und sich keine Kauf-empfehlung mehr auf ihn bezieht. Alternativ konnen Sie den Vertrag auf denAngebotsstatus zurucksetzen und ihn anschließend loschen.

202

Page 203: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.15 Lastprognosen

Abbildung 125: Die Oberflache zur Verwaltung und Erstellung von Lastprogno-sen

Sie konnen mit diesem Programm sehr einfach Lastprognosen erstellen. Wah-len Sie zunachst einen Prognosealgorithmus aus der Liste aus, die mit ”Verfugba-re Lastprognosealgorithmen“ betitelt ist (siehe Abbildung 125). Informationenzum gewahlten Algorithmus werden Ihnen unten angezeigt. Haben Sie sich fureinen Algorithmus entschieden, tragen Sie noch das Start- und das Enddatumdes Zeitraumes ein, der in die Lastprognose mit einfließen soll. Klicken Sie zumErstellen der Lastprognose auf die Schaltflache ”Lastprognose erstellen“. Furmanche Algorithmen werden weitere Eingaben erforderlich sein. In diesen Fallenoffnet sich nach klicken der Schaltflache ”Prognose erstellen“ eine Eingabemaske.Haben Sie diese Ausgefullt und bestatigt, wird eine Lastprognose erstellt undin der rechten Liste mit dem Titel ”Bereits erstellte Lastprognosen“ angezeigt.Um die Details einer bestimmten Lastprognose einzusehen, klicken Sie auf dieSchaltflache ”Details“. Es offnet sich daraufhin ein weiteres Fenster, welches dieDetails zu der von Ihnen gewahlten Lastprognose enthalt, aufgeschlusselt nach96 Tages-Viertelstunden und den Tagen, fur die eine Lastprognose erstellt wur-de. Wenn Sie eine Lastprognose loschen mochten, klicken Sie auf die Schaltflache

203

Page 204: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

”Loschen“ und bestatigen Sie die Sicherheitsabfrage. Sie konnen eine Lastpro-gnose nur loschen, wenn keine Kaufempfehlung mehr auf ihr basiert.

204

Page 205: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.16 Bilanzkreise und Regelzonen

Abbildung 126: Oberflache zur Verwaltung von Bilanzkreisen und Regelzonen

9.16.1 Massenupdate

Um eine aktuelle Liste mit Bilanzkreisen und Regelzonen per Massenupdatein die Datenbank zu ubertragen, wahlen Sie den Menupunkt ”Bilanzkreise undRegelzonen”und klicken dann die Schaltflache ”Massenupdate”, wahlen Sie jetzteine CSV–Datei mit Bilanzkreisen und Regelzonen und klicken Sie dann ”OK”.Die Liste wird dann in die Datenbank ubertragen.

Eine Liste der aktuell gultigen Bilanzkreise und Regelzone erhalten Sie bei-spielsweise auf [EIC06] als Datei fur Microsoft Excel. Laden Sie diese herunterund offnen Sie sie. Loschen Sie alle Zeilen, die keine Bilanzkreise oder Regelzo-nen enthalten. Loschen Sie ebenfalls leere Spalten und die Spalte ”Anderungs-datum”. Sortieren Sie anschließend die Spalten in der Reihenfolge Eigentumer,Abkurzung, EIC. Klicken Sie dann auf Datei, Speichern unter. Wahlen Sie alsDateityp ”CSV (Trennzeichen-getrennt) (*.csv)” und einen beliebigen Datein-amen. Bestatigen Sie die folgende Abfrage mit ja.

205

Page 206: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Wie alle anderen Daten konnen auch die Angaben zu Bilanzkreisen und Re-gelzonen manuell geandert werden, indem sie Schaltflachen ”Anlegen ...”, ”Be-arbeiten ...” und ”Loschen ...” am unteren Rand des Ubersichtspanels (sieheAbbildung 126) betatigen. Fur die letzten beiden Funktionen muss ein Bilanz-kreis oder eine Regelzone ausgewahlt sein. Uber das Auswahlfeld oben linkswechseln Sie zwischen der Ubersicht fur Bilanzkreisen und der fur Regelzonenhin und her.

206

Page 207: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.17 EEX - Angebote

Um die EIS–Funktionen fur die EEX nutzen zu konnen, mussen Sie alsEEX-Handler eingeloggt sein, bzw. es muss mindestens einen ”EEX–Handler”-Systemnutzer geben, dessen Daten fur den Handel an der EEX genutzt werden.Sofern dies nicht der Fall ist, werden Sie aufgefordert, Ihre EEX-Zugangsdateneinzugeben.

Um in die EEX–Ubersicht zu gelangen, wahlen Sie den Menupunkt ”EEX-Angebote” im Programmmenu. Sie konnen in der Ubersicht eine aktuelle Last-prognose auswahlen. Die Daten der Lastprognose werden nun intern mit denbereits vereinbarten Lieferungen an Sie abzuglich der Storungen abgeglichen.In dem Deckungsgraphen der ubersicht konnen Sie erkennen, ob und wann Siefur die errechnete Last zu einem bestimmten Zeitpunkt genug Energie durchVertrage und Lieferungen zur Verfugung stehen haben (siehe Abbildung 127).

Abbildung 127: Die Oberflache zur Verwaltung von EEX-Angeboten

Unter dem Punkt ”Ihre Blockangebote”sehen Sie eine Ubersicht uber alle zurZeit aktuellen Blockangebote, die Sie an der EEX platziert haben. Entsprechenddarunter die Stundenangebote im Bereich ”Ihre Stundenangebote”.

207

Page 208: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Im untersten Abschnitt konnen Sie ablesen welche EEX–Handlerdaten (Tra-derID und TraderLogin) zur Zeit fur den EEX–Handel genutzt werden. Dasaktive EEX–Handler–Konto konnen Sie mit einem Klick auf ”Daten andern...”wechseln.

Abbildung 128: EEX-Daten andern

Geben Sie dazu die entsprechenden EEX-Daten ein, und bestatigen Sie (sieheAbbildung 128).

In der Info–Spalte links sehen Sie die aktuellen Marktdaten der EEX, alsodie Preise fur bestimmte Blocke.

9.17.1 Blockgebote

Blockgebot anlegen Im Bereich ”Ihre Blockgebote”finden Sie eine Uber-sicht uber die aktuellen Blockgebote die Sie an der EEX platziert haben. Um einneues Blockgebot fur die EEX anzulegen, klicken Sie auf die Schaltflache ”Anle-gen...”. Geben Sie in dem neuen Fenster (siehe Abbildung 129) die gewunschtenDaten fur Ihr neues Blockgebot ein. Speichern Sie das neue Blockgebot mit ei-nem Klicke auf ”Speichern”. Sie konnen das Blockgebot nun mit einem Klickauf ”PDF erzeugen” als druckbares Faxformular erzeugen lassen bzw. druckenbzw. direkt an den Faxdrucker ubergeben. Fur Informationen zu den Druck-einstellungen wenden Sie sich an den jeweiligen Systemadministrator, der furSie zustandig ist. Analog dazu konnen Sie bereits abgegebene Blockangebotebearbeiten.

208

Page 209: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 129: Ein Blockangebot erstellen

Blockgebot loschen Um ein Blockgebot zu loschen, wahlen Sie das entspre-chende Gebot aus der Liste aus und klicken Sie auf ”Loschen”. Bestatigen Siedie Sicherheitsfrage mit ”OK” um das Gebot endgultig zu loschen. Es konnennur bisher unbestatigte Gebote geloscht werden.

9.17.2 Stundengebote

Stundengebot anlegen Im Bereich ”Ihre Stundengebote” finden Sie eineUbersicht uber die aktuellen Stundengebote, die Sie an der EEX platziert haben.Um ein neues Stundengebot fur die EEX anzulegen, klicken Sie auf die Schalt-flache ”Anlegen...”. Geben Sie in dem neuen Fenster (siehe Abbildung 130) diegewunschten Daten fur Ihr neues Stundengebot ein. Speichern Sie das neue Stun-dengebot mit einem Klick auf ”Speichern”. Sie konnen das Stundengebot nunmit einem Klick auf ”PDF erzeugen” als druckbares Faxformular erzeugen las-sen bzw. drucken bzw. direkt an den Faxdrucker ubergeben. Fur Informationenzu den Druckeinstellungen wenden Sie sich an den jeweiligen Systemadminis-trator, der fur Sie zustandig ist. Analog dazu konnen Sie bereits abgegebeneStundenangebote bearbeiten.

Stundengebot loschen Um ein Stundengebot zu loschen, wahlen Sie dasentsprechende Gebot aus der Liste aus und klicken Sie auf ”Loschen”. BestatigenSie die Sicherheitsfrage mit ”OK”um das Gebot endgultig zu loschen. Es konnennur bisher unbestatigte Gebote geloscht werden.

9.17.3 EEX-Lieferungen eintragen

Wenn Sie ein Stunden- oder Blockangebot eingegeben haben, konnen Sie da-zu eine an der EEX ausgehandelte Lieferung eintragen. Wahlen Sie dazu das

209

Page 210: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Abbildung 130: Ein Stundenangebot erstellen

jeweilige Angebot aus und klicken Sie auf den zugehorigen Button mit der Auf-schrift ”Lieferung ...”. Sie werden dann in einem neuen Fenster nach den Datender Lieferung gefragt und konnen diese mit einem Klick auf die Schaltflache”Speichern” sichern.

210

Page 211: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.18 EEX - Lieferungen

9.18.1 Ubersicht

Um eine Ubersicht uber aus EEX-Angeboten resultierende Lieferungen zu erhal-ten, wahlen Sie im Menu den Punkt ”EEX–Lieferungen”. Sie erhalten eine Listemit allen Lieferungen, die Sie abgeschlossen haben (siehe Abbildung 131). Inder Infospalte links sehen Sie eine Ubersicht der gelieferten bzw. gekauften undverkauften Energiemengen in MWh sowie die Anzahl der aktuellen Lieferungen.

Abbildung 131: Die Oberflache zur Verwaltung von EEX-Lieferungen

9.18.2 Lieferung bearbeiten

Zur Korrektur einer EEX–Lieferung wahlen Sie eine Lieferung aus der Listemit einem Mausklick aus (blau hinterlegt) und klicken Sie dann die Schaltflache”Bearbeiten...”. andern Sie die gewunschten Parameter und speichern Sie dieAnderungen mit einem Klick auf ”Speichern”. Zum Abbrechen klicken Sie dieSchaltflache ”Abbrechen”.

211

Page 212: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.18.3 Lieferung loschen

Um eine Lieferung zu loschen, wahlen Sie mit einem Mausklick die entspre-chende Lieferung in der Ubersicht aus und klicken Sie dann die Schaltflache”Loschen”. Sie mussen zum endgultigen Loschen der Lieferung die Sicherheits-abfrage mit ”Ja” bestatigen. Andernfalls brechen Sie die Loschung mit einemKlick auf ” Nein” ab.

212

Page 213: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.19 Storungen

Unter dem Punkt ”Storung” konnen Sie aktuelle und vergangene Storungenim Stromubertragungsnetz einsehen, die an Sie ubermittelt wurden (siehe Ab-bildung 132). Geben Sie in der Suchmaske einene Suchbegriff ein und klicken Sie”Suchen”, um eine bestimmte Storung zu suchen. Um alle vorliegenden Storun-gen anzuzeigen, klicken Sie auf ”Alle anzeigen”. Es werden nun alle Storungenmit den entsprechenden Daten in der Liste angezeigt.

Abbildung 132: Die Oberflache zur Verwaltung und Erstellung von Storungen

9.19.1 Storung melden

Sie konnen eine neue Storung melden, indem Sie die Schalflache ”Anlegen” kli-cken. Geben Sie in der neuen Maske (siehe Abbildung 9.19.1) die entsprechendenDaten fur die Storung ein. Bestatigen Sie die Storung mit einem Klick auf ”OK”.

9.19.2 Storung bearbeiten

Eine bereits bestehende Storung konnen Sie nachdem Sie sie ausgewahlt haben,mit einem Klick auf ”Bearbeiten...” andern.

213

Page 214: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.19.3 Storung loschen

Mit einem Klick auf ”Loschen” konnen Sie eine ausgwahlte Storung loschen.Bestatigen Sie die Sicherheitsabfrage mit ”Ja”, um die Storung endgultig zuloschen.

214

Page 215: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.20 Systemnutzer

Abbildung 133: Die Oberflache zur Verwaltung von Systemnutzern

9.20.1 Rollen

Jeder Systemnutzer kann keine, eine oder mehrere Rollen haben. Diese lautenwie folgt:

Administrator Der Administrator hat uneingeschrankte Rechte zum Zugriffauf die Nutzerverwaltung des EIS. Es kann mehrere Administratoren geben.Mindestens ein Adminstrator muss im System vorhanden sein.

EEX–Handler Die Daten die einem EEX–Handler Account zugeordnet sind,konnen zum Handel an der EEX eingesetzt werden (siehe EEX–Angebote).EEX–Handler hat Zugriff auf die Funktionen:

• EEX–Angebote

215

Page 216: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

• EEX–Lieferungen

Um auf die Funktionen EEX–Angebote und EEX–Lieferungen zugreifen zu kon-nen, mussen Sie als EEX–Handler eingeloggt sein bzw. als Admin wenn einEEX–Handler Konto angelegt wurde.

Kundenbetreuer Ein Kundenbetreuer verwaltet Stammdaten fur eigene Kun-den. Kundenbetreuer haben Zugriff auf die Funktionen:

• Kundenverwaltung inkl. Kundenvertrage

• Tarife

• Lastprofile

• Bilanzkreise und Regelzonen

Lieferentenbetreuer Ein Lieferantenbetreuer verwaltet Stammdaten fur Ener-gielieferanten. Lieferantenbetreuer haben Zugriff auf die Funktionen:

• Lieferantenverwaltung inkl. Liefervertrage.

• Lastprognosen

• Kaufempfehlungen

• Bilanzkreise und Regelzonen

• Storungen

Abbildung 134: Einen Systemnutzer hinzufugen

216

Page 217: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.20.2 Benutzer anlegen/bearbeiten

Wahlen Sie aus dem Menu den Punkt ”Systemnutzer” (siehe Abbildung 133).Zum Anlegen neuer Systemnutzer klicken Sie auf die Schaltflache ”Anlegen”(siehe Abbildung 134). Geben Sie die entsprechenden Daten an, wahlen Siekeine, eine oder mehrere Rollen fur den neuen Systemnutzer aus und klickenSie dann auf die Schaltflache ”Speichern”, um die Anderungen zu speichern. Derneue Systemnutzer erscheint jetzt in der Liste der Systemnutzer. Analog konnenSie einen bestehenden Systemnutzer auch bearbeiten und ihm beispielsweiseRollen aberkennen. Dazu klicken

9.20.3 Benutzer loschen

Uber einen Klick auf die Schaltflache ”Loschen”konnen Sie beliebige Systemnut-zer – auch sich selbst – loschen. Voraussetzung dafur ist, dass der zu loschendeNutzer keine Vertrage und keinen EEX-Handel mehr betreut. Eine Loschungist ebenfalls nicht moglich, wenn es sich um den letzten im System verblie-benen Adminstrator handelt, da sonst ein Zugriff auf die Benutzerverwaltungunmoglich wurde. Bevor ein Nutzer tatsachlich geloscht wird, mussen Sie eineSicherheitsabfrage bestatigen.

217

Page 218: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.21 Szenarien

9.21.1 Szenario 1: Herausgabe einer aktualisierten Bilanzkreisliste

Der EIS-Nutzer Klaus Mustermann startet zu Beginn seines Arbeitstages dasSystem und gelangt nach erfolgreicher Anmeldung auf die Ubersichtsseite. Erkontrolliert die eingegangenen Storungen und die heute auslaufenden Vertragemit Kunden und Lieferanten. Schließlich schaut er auf seine ToDo-Liste undstellt fest, dass an diesem Tag eine aktualisierte Liste mit Bilanzkreisen heraus-gegeben wurde (siehe Abbildung 9.21.1).

Abbildung 135: Die ToDo-Liste zeigt, dass heute eine Aufgabe anliegt

218

Page 219: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Er offnet seinen Internetbrowser und ladt sich die aktuelle Liste herunter.Anschließend kann er diese Datei verwenden, um die Liste des Systems zu aktua-lisieren. Hierzu wechselt er in die Verwaltung der Bilanzkreise und Regelzonen,indem er im Menu ”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 Schaltflache

”Datei verarbeiten“. Die Liste ist nun aktualisiert und der EIS-Nutzer kehrtwieder in die Ubersicht zuruck, zu der er durch ein Klick auf ”Willkommen“ imMenu gelangt.

Abbildung 136: Auswahl der CSV-Datei zur Listenaktualisierung

219

Page 220: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Hier muss er nun die abgeschlossene Aufgabe als bearbeitet markieren. Erwahlt aus der ToDo-Liste den entsprechenden Eintrag aus und klickt auf ”Be-arbeiten...“. Er setzt den Status von ”Nicht angefangen“ auf ”Bearbeitet“ undklickt dann auf ”Speichern“ (siehe Abbildung 137). Der Vorgang ist hiermitabgeschlossen. Alternativ konnte der Nutzer den Eintrag naturlich auch sofortloschen.

Abbildung 137: Bearbeitung des Ereignisses in der ToDo-Liste

220

Page 221: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.21.2 Szenario 2: Abschluss eines neuen Vertrages

Ein EIS-Nutzer mochte einen Vertrag mit einem Lieferanten schließen, um denStrombedarf seiner Kunden decken zu konnen. Er hat mehrere Angebote vonLieferanten im System gespeichert. Er uberpruft einige gleichwertige Angebote(siehe Abbildung 138) und fragt sich nun, mit welchem dieser Lieferanten ereinen Vertrag abschließen soll. Er entscheidet sich dazu, dem Lieferanten denVorzug zu geben, der das geringste Storungsaufkommen hat. Dazu wechselt derNutzer in die Storungsansicht des EIS-Systems.

Abbildung 138: In der Lieferantenansicht pruft der Nutzer die Angebote

221

Page 222: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Hier gibt der Nutzer nacheinander die Namen der Lieferanten ein, die er imAuge hat. Er erhalt eine Ubersicht uber die Storungen, die im Zusammenhangmit dem jeweiligen Lieferanten aufgetreten sind (siehe Abbildung 139). Nach-dem der Nutzer sich auf Basis der Storungsinformationen fur einen Lieferantenentschieden hat, kann es zum Vertragsschluss mit diesem Lieferanten kommen.Er kehrt zuruck in die Lieferantenansicht.

Abbildung 139: In der Storungsansicht vergleicht der Nutzer die Storrate

222

Page 223: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

In der Lieferantenansicht wahlt der Nutzer das Angebot des Lieferanten,dass der Nutzer zu einem Vertrag im System andern mochte. Er klickt auf ”Be-arbeiten...“ und andert den Status von ”Angebot“ auf ”Vertrag“ (siehe Abbildung140). Der Vorgang ist nun abgeschlossen.

Abbildung 140: Verwaltung von Angeboten und Vertragen in Lieferantenansicht

223

Page 224: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

9.22 Hilfefunktion

Zum Aufrufen der Online–Hilfe konnen Sie jederzeit die Taste F1 drucken. DieOnline–Hilfe wird dann an der fur die derzeitig Ausgewahlte Funktion relevantenSeite geoffnet. Um die Windows-Hilfedatei auf der Startseite zu offnen, wahlenSie im Programm-Menu den Punkt ”Hilfe”.

224

Page 225: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

10 Glossar

Agile Modeling Agile Modellierung, Sammlung von Werten, Prinzipien undMethoden zur Softwaremodellierung, die auf einfache Weise in einem Ent-wicklungsprojekt angewandt werden konnen.

CRM Customer Relationship Management, Kundenverwaltung, die sich umAnlegen, Andern und Loschen kundenbezogener Daten kummert.

CRUD-Methoden Create, Read, Update, Delete, Standardmethoden zum Zu-griff auf Objekte in einer Datenbank zum Einfugen, Auslesen, Bearbeitenund Loschen.

CSV Comma Seperated Values, Textdatei zur Speicherung oder Austasuch voneinfach strukturierten Daten, einzelne Werte sind durch ein Trennzeichen(z.B. Komma) voneinander getrennt

CVS Concurrent Versions System, Programm zur Versionsverwaltung von Da-teien, hauptsachlich Software-Quelltext

DLL Dynamic Link Library, unter Microsoft Windows eingesetzte Programm-bibliothek, die Programmcode und/oder Daten beinhalten kann.

DSS Decision Support System, Entscheidungsunterstutzungssystem, das demNutzer eines Systems sinnvolle, moglichst optimale Vorschlage zur Losungeiner bestimmten, meist betriebswirtschaftlichen Fragestellung anbietet.

EEX European Energy Exchange, elektronischer Marktplatz fur den Energie-handel mit Sitz in Leipzig.

ETSO European Transmission System Operators, Verband der europaischenUbertragungsnetzbetreiber.

ESS ETSO Scheduling System, standardisiertes, XML-basiertes Dateiformatzum Austausch von Fahrplanmeldungen zwischen Eneriehandlern undUNBs im europaischen Energieverbund.

Extreme Programming Flexible Vorgehensweise zur Softwaremodellierung,die in kurzen Zyklen alle Entwicklungsschritte durchlauft und dabei denProgrammcode sowie die sich im Zeitablauf andernden Kundenwunschebei standiger Reflexion in den Mittelpunkt stellt.

GUI Graphical User Interface, grafische Benutzeroberflache, uber die Men-schen mit einem Programm interagieren konnen.

NUnit Framework zu Entwurf und Durchfuhrung von Unit-Tests fur alle .NET-Programmiersprachen.

Review Kontrolle des Ergebnis eines bearbeiteten Sprints durch eines odermehrere Mitglieder der Projektgruppe auf Erfullung der im Springt ge-stellten Anforderungen

RPC Remote Procedure Call ist ein Netzwerkprotokoll, mit dem uber das Netz-werk Funktionsaufrufe auf entfernten Rechnern durchgefuhrt werden.

225

Page 226: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Scrum ist eine Sammlung von Arbeitstechniken, Strukturen, Rollen und Me-thoden fur das Projektmanagement im Rahmen agiler Software-Entwick-lung.

SOAP Simple Object Access Protocol ist ein Protokoll, mit dem Daten zwischenSystemen ausgetauscht werden und mit dem RPC durchgefuhrt wird.

SVN Subversion, Programm zur Versionsverwaltung von Dateien, hauptsach-lich Software-Quelltext.

UML Unified Modeling Language, standardisierte Sprache zur Modellierungvon Software und anderen Systemen.

UNB Ubertragungsnetzbetreiber, Unternehmen, das fur Organisation und War-tung des Stromleitungsnetzes in einer bestimmten Region zustandig ist.

V-Modell Das V-Modell ist ein spezielles Vorgehensmodell zur Softwareent-wicklung. Das V-Modell ist einer von vielen Versuchen, in Deutschlandeine Richtlinie fur die Entwicklung von IT-Systemen der offentlichen Handeinzufuhren. In der Regel wird ein neues V-Modell nach einer Katastrophemit dem jeweils vorhergehenden V-Modell entwickelt. Das Bestreben ist,ein auf die offentliche Hand zugeschnittenes Prozessmodell als Richtlinieeinzufuhren.

Wasserfallmodell Das Wasserfallmodell bezeichnet ein Vorgehensmodell inder Softwareentwicklung, bei dem der Softwareentwicklungsprozesses inPhasen organisiert wird. Dabei gehen die Phasenergebnisse wie bei einemWasserfall immer als bindende Vorgaben fur die nachst tiefere Phase ein.

Wrapper-Klasse Klasse, die den Datenbankzugriff fur einen bestimmten Ob-jekttyp kapselt und dazu Methoden zum Einfugen, Bearbeiten, Loschenund Auslesen von Objekten bereitstellt.

226

Page 227: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

Literatur

[Adv] Adventureworks cinema 1.0. Online und herunterladbar unterhttp://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 softwaredevelopment. Online unter http://agilemanifesto.org/principles.html,letzter Zugriff am 04.04.2006, 2001.

[Bun05] Bundesgesetzblatt. Verordnung uber den zu-gang zu elektrizitatsversorgungsnetzen. Online unterhttp://217.160.60.235/BGBL/bgbl1f/bgbl105s2243.pdf, letzter Zugriffam 15.9.2005, 2005.

[dE01] Verband der Elektrizitatswirtschaft. Begriffe im libe-ralisierten strommarkt. Online unter http://www.vdn-berlin.de/global/downloads/Service/BegriffeStrommarkt.PDF, letzterZugriff am 14.9.2005, 2001.

[EIC06] Eic-codes fur vnb-bilanzkreise gemaß nvz. Online und herunterladbarunter http://www.vdn-berlin.de/vnb eic.asp, 2006.

[FI] Fraunhofer-Institut. Projekt fit fur usa-bility. Online unter http://www.fit-fuer-usability.de/tipps/software/information/uebersicht.html, zuletztbesucht am 19. September 2006.

[Fir] Firefx beta 2. Online und herunterladbar unterhttp://www.dotnetfireball.net.

[For03] European Transmission System Operators Task Force. ETSO Schedu-ling System - Implementation Guide, 2 edition, April 2003.

[Fow05] Martin Fowler. The new methodology. Online unterhttp://www.martinfowler.com/articles/newMethodology.html, letzterZugriff am 04.04.2006, 2005.

[Gro04] Agile Cologne Group. Scrum. Online unter http://agile-cologne.de:8080/snipsnap-0.5.2a/space/Scrum, letzter Zugriff am15.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 her-unterladbar unter http://www.energiedienst-netze.de/site/DE/netze/01-netznutzung/01 03-lastprofile/Lastprofile Energiedienst AG/container lastprofile energiedienst AG.php,2006.

[Mar02] Robert C. Martin. Agile processes. 2002.

227

Page 228: EIS Implementierung eines Energie-Informationssystems ... · EIS-Implementierung eines Energie-Informationssystems (Endbericht) Projektgruppe Energie-Informationssyteme Daniel Aarden,

EIS - Energie-Informationssystem Projektgruppe Energie-Informationssyteme

[Nat05] National Oceanic and Atmospheric Administration. Wetterdaten dernoaa. Online unter http://www.nws.noaa.gov, letzter Zugriff am15.10.2005, 2005.

[Nie] Jakob Nielsen. 6 ways to fix a confused information architecture.

[Ope03] European Transmission System Operators. Etso scheduling sys-tem (ess) implementation guide. Online unter http://www.edi.etso-net.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 Evalua-tion. Huber, 2006.

[Sch05] Ken Schwaber. Scrum - it´s about common sense. Online unterhttp://www.controlchaos.com, letzter Zugriff am 13.12.2005, 2005.

[SOA03] Soap version 1.2, part 1: Messaging framework. Online und her-unterladbar unter http://www.w3.org/TR/2003/REC-soap12-part1-20030624/, 2003.

[Sut05] Jeff Sutherland. Scrumlog. Online unterhttp://jeffsutherland.com/scrum, letzter Zugriff am 13.12.2005,2005.

[Usa97] DIN EN ISO 9421. Ergonomische Anforderungen fur Burotatigkeitenmit Bildschirmgeraten. Deutsche Fassung EN ISO 9421. Beuth VerlagBerlin, 1997.

[Usa99] DIN EN ISO 13407. Benutzer-orientierte Gestaltung interaktiver Sys-tem. Deutsche Fassung EN ISO 13407. Beuth Verlag Berlin, 1999.

[Usa03] DIN EN ISO 14915. Software Ergonomie fur Multimedia-Benutzungsschnittstellen. Deutsche Fassung EN ISO 14915. BeuthVerlag Berlin, 2003.

[Zed] Zed graph 5.x. Online und herunterladbar unterhttp://zedgraph.org/wiki/index.php.

228