Diplomarbeit

Entwicklung eines webbasiertenZeiterfassungssystems mit vergleichenderUntersuchung von Datenbanktechniken

Eingereicht von Clemens Schweter

am Lehrstuhl Softwaretechnik

an der Technischen Universitat Berlin

WS 2003/2004

1. Gutachter: Prof. Dr.-Ing. Stefan Jahnichen

2. Gutachter: Dr. Stephan Herrmann

Berlin, Mai 2004

i

Eidesstattliche Erklarung

Die selbststandige und eigenhandige Anfertigung versichere ich an Eides statt.Berlin, den 27.05.2004

- Clemens Schweter -Unterschrift

ii

Inhaltsverzeichnis

1 Motivation und Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Die zu losende Aufgabe . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Requirements Engineering 52.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Was sind Requirements? . . . . . . . . . . . . . . . . . . . . . 62.2.2 Definition: Requirement . . . . . . . . . . . . . . . . . . . . . 62.2.3 Bedingungen an ein Requirement . . . . . . . . . . . . . . . . 72.2.4 Was ist Requirements Engineering? . . . . . . . . . . . . . . . 7

2.3 Das Requirements Document . . . . . . . . . . . . . . . . . . . . . . 82.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 Requirements beschreiben . . . . . . . . . . . . . . . . . . . . 82.3.3 Systemmodellierung . . . . . . . . . . . . . . . . . . . . . . . 92.3.4 Struktur des Requirements Documents . . . . . . . . . . . . . 10

2.4 Anforderungen erheben (Elicitation) . . . . . . . . . . . . . . . . . . 102.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.2 Erste Schritte . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.3 System Stakeholder identifizieren und befragen . . . . . . . . . 102.4.4 Unterstutzende Analysetechniken . . . . . . . . . . . . . . . . 12

2.5 Anforderungen analysieren und neu verhandeln . . . . . . . . . . . . 142.5.1 Anforderungen sprachlich uberarbeiten . . . . . . . . . . . . . 142.5.2 Checklisten zur Uberprufung . . . . . . . . . . . . . . . . . . . 15

3 Analyse mit Requirements Engineering 173.1 Anforderungen erheben . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Erste Schritte . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2 Analyse des Ist-Zustandes . . . . . . . . . . . . . . . . . . . . 193.1.3 Befragung der Stakeholder mit verschiedenen Techniken . . . . 203.1.4 Beschreibung der Stakeholder . . . . . . . . . . . . . . . . . . 223.1.5 Unterstutzende Analysetechniken . . . . . . . . . . . . . . . . 23

3.2 Analyse der Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 243.2.1 Anforderungen sprachlich uberarbeiten . . . . . . . . . . . . . 253.2.2 Checklisten zur Uberprufung . . . . . . . . . . . . . . . . . . . 26

3.3 Requirements Document . . . . . . . . . . . . . . . . . . . . . . . . . 273.3.1 Systemmodelle . . . . . . . . . . . . . . . . . . . . . . . . . . 273.3.2 Struktur eines Requirements . . . . . . . . . . . . . . . . . . . 303.3.3 Struktur des Requirements Documents nach [IEEE830-1998] . 30

3.4 Abschließende Worte zum Requirements Engineering . . . . . . . . . 31

iii

4 Konzepte von ASP.NET 344.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.1 3-Tier-Architektur . . . . . . . . . . . . . . . . . . . . . . . . 344.1.2 .NET - Framework . . . . . . . . . . . . . . . . . . . . . . . . 344.1.3 Businessobjekte . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1.4 Die Programmiersprache C# . . . . . . . . . . . . . . . . . . . 354.1.5 ASP.NET Page-Framework . . . . . . . . . . . . . . . . . . . 37

4.2 Codebehind-Technologie . . . . . . . . . . . . . . . . . . . . . . . . . 374.3 Webforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.3.2 HTML Server Controls . . . . . . . . . . . . . . . . . . . . . . 384.3.3 Web Server Controls . . . . . . . . . . . . . . . . . . . . . . . 39

4.4 Zustandsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5 Lebenszyklus eines Page-Objekts . . . . . . . . . . . . . . . . . . . . 41

5 Architektur und Entwurf der Webapplikation 435.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3 Persistenz-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3.2 Persistenz Manager . . . . . . . . . . . . . . . . . . . . . . . . 465.3.3 Persistente Objekte . . . . . . . . . . . . . . . . . . . . . . . . 475.3.4 Die Klasse Controller . . . . . . . . . . . . . . . . . . . . . . . 495.3.5 Zusammenfassung und Ubersicht uber alle persistenten Objekte 50

5.4 Entwurf des Web-Interfaces . . . . . . . . . . . . . . . . . . . . . . . 515.4.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515.4.2 Struktur der GUI . . . . . . . . . . . . . . . . . . . . . . . . . 515.4.3 Problem bei Web-Applikationen . . . . . . . . . . . . . . . . . 535.4.4 Verwendung eines Datagrids . . . . . . . . . . . . . . . . . . . 545.4.5 Entwurf eines User Controls . . . . . . . . . . . . . . . . . . . 55

5.5 Zustandsmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.5.1 PageNavigator . . . . . . . . . . . . . . . . . . . . . . . . . . 575.5.2 Start einer Session . . . . . . . . . . . . . . . . . . . . . . . . 60

5.6 Benutzerrechte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.7.1 Gesamtstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . 615.7.2 Beispielhafter Ablauf . . . . . . . . . . . . . . . . . . . . . . . 635.7.3 Schwierigkeiten beim Entwurf . . . . . . . . . . . . . . . . . . 645.7.4 Nebenlaufigkeit . . . . . . . . . . . . . . . . . . . . . . . . . . 655.7.5 Ubergang zur Implementierung . . . . . . . . . . . . . . . . . 65

iv

6 Implementierung mit relationaler Datenbank 676.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.2 Datendefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.2.1 Datentypen und Domanen . . . . . . . . . . . . . . . . . . . . 686.2.2 Primarschlussel . . . . . . . . . . . . . . . . . . . . . . . . . . 686.2.3 Fremdschlusselverbindungen und referentielle Integritat . . . . 696.2.4 Integritatsbedingungen . . . . . . . . . . . . . . . . . . . . . . 696.2.5 Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.2.6 Benutzerdefinierte Routinen . . . . . . . . . . . . . . . . . . . 706.2.7 Sichten (Views) . . . . . . . . . . . . . . . . . . . . . . . . . . 716.2.8 Schwachen der relationalen Datendefinition . . . . . . . . . . . 71

6.3 Datenmanipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.3.1 Datenmanipulationsoperationen . . . . . . . . . . . . . . . . . 716.3.2 (SQL-)Transaktionen . . . . . . . . . . . . . . . . . . . . . . . 726.3.3 Nebenlaufigkeitsanomalien . . . . . . . . . . . . . . . . . . . . 726.3.4 Nebenlaufigkeitskontrolle . . . . . . . . . . . . . . . . . . . . . 73

6.4 Datenabfragen (Select) . . . . . . . . . . . . . . . . . . . . . . . . . . 746.4.1 Select-Statement . . . . . . . . . . . . . . . . . . . . . . . . . 746.4.2 Subqueries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.4.3 OUTER JOIN . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.5 Redundanzvermeidung durch Normalisierung . . . . . . . . . . . . . . 786.5.1 Begrifflichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 786.5.2 1. Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.5.3 2. Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.5.4 3. Normalform . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.5.5 Boyce-Codd-Normalform (BCNF) . . . . . . . . . . . . . . . . 82

6.6 ODBC-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.7 Konkrete Implementierung . . . . . . . . . . . . . . . . . . . . . . . . 83

6.7.1 Verwendete Modellierungstechnik . . . . . . . . . . . . . . . . 836.7.2 Entwurf des Datenmodells . . . . . . . . . . . . . . . . . . . . 846.7.3 (SQL-)Transaktionen . . . . . . . . . . . . . . . . . . . . . . . 876.7.4 Sichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 896.7.5 Primarschlussel und Identitat . . . . . . . . . . . . . . . . . . 906.7.6 Referenzielle Integritat . . . . . . . . . . . . . . . . . . . . . . 91

6.8 Motivation zur Objektorientierung in Datenbanken . . . . . . . . . . 926.8.1 Vorteile einer relationalen Datenbank . . . . . . . . . . . . . . 926.8.2 Nachteile einer relationalen Datenbank . . . . . . . . . . . . . 936.8.3 Object-Oriented Database System Manifesto . . . . . . . . . . 95

7 Implementierung mit objektrelationaler Datenbank 987.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.2 Erweiterte Datendefinition . . . . . . . . . . . . . . . . . . . . . . . . 99

7.2.1 Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

v

7.2.2 Distinct-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . 997.2.3 Unbenannte Typkonstruktoren . . . . . . . . . . . . . . . . . . 1007.2.4 Strukturierte Typen . . . . . . . . . . . . . . . . . . . . . . . 1037.2.5 Typisierte Tabellen . . . . . . . . . . . . . . . . . . . . . . . . 1057.2.6 Typisierte Sichten . . . . . . . . . . . . . . . . . . . . . . . . . 106

7.3 Erweiterte Datenabfragen und -manipulation . . . . . . . . . . . . . . 1077.4 Bewertung nach Datenbankmanifesto . . . . . . . . . . . . . . . . . . 108

7.4.1 Komplexe Datentypen . . . . . . . . . . . . . . . . . . . . . . 1087.4.2 Objektidentitat . . . . . . . . . . . . . . . . . . . . . . . . . . 1097.4.3 Kapselung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097.4.4 Typen- und Klassenhierarchien . . . . . . . . . . . . . . . . . 1097.4.5 Vererbung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1097.4.6 Override, Overload und spates Binden . . . . . . . . . . . . . 1097.4.7 Sprach- und Berechnungsvollstandigkeit . . . . . . . . . . . . 1107.4.8 Erweiterbarkeit von Typen . . . . . . . . . . . . . . . . . . . . 110

7.5 Klassenmodell in objektrelationales Datenmodell transformieren . . . 1107.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

8 Vergleich: relationale und objektrelationale Datenbank 1128.1 Relationale Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . 112

8.1.1 Modellierungsmoglichkeiten und Normalisierung . . . . . . . . 1128.1.2 Definition von Primarschlusseln . . . . . . . . . . . . . . . . . 1138.1.3 Integritatsbedingungen . . . . . . . . . . . . . . . . . . . . . . 1148.1.4 Abfragemoglichkeiten und Datenmanipulation . . . . . . . . . 1148.1.5 Nebenlaufigkeit und Performanz . . . . . . . . . . . . . . . . . 115

8.2 Verbesserungen durch eine objektrelationale Datenbank? . . . . . . . 1158.3 Vergleich objektrelational zu relational zusammengefasst . . . . . . . 116

9 Zusammenfassung und Ausblick 1169.1 Objektorientierte Datenbank . . . . . . . . . . . . . . . . . . . . . . . 1169.2 Persistenz Framework und Datenbankvergleich . . . . . . . . . . . . . 1189.3 Entwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . 1189.4 Zusammenfassung der wichtigsten Erkenntnisse . . . . . . . . . . . . 1199.5 Offene Frage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Literaturverzeichnis 122

A Requirements Document 126

vi

Abbildungsverzeichnis

1 Beispiel fur eine Vergleichbarkeit von Fachgruppen . . . . . . . . . . . 32 Gliederung und Vorgehensweise . . . . . . . . . . . . . . . . . . . . . 33 Requirements Engineering Prozess [Som Saw 97, S. 113] . . . . . . . . 54 Erste Befragung des Auftraggebers . . . . . . . . . . . . . . . . . . . 115 Kommunikation zwischen den Stakeholdern . . . . . . . . . . . . . . . 186 Activity Diagram des Ist-Zustandes fur die Berichtserstellung . . . . . 197 Zustande eines Projekts . . . . . . . . . . . . . . . . . . . . . . . . . 208 Systemmodell: Klassendiagramm . . . . . . . . . . . . . . . . . . . . 289 Statechart Diagramm fur die Menufuhrung . . . . . . . . . . . . . . . 2910 Use Case Modell zur Beschreibung der drei Hauptfunktionalitaten . . 2911 Aufbau eines Requirements . . . . . . . . . . . . . . . . . . . . . . . 3212 Requirement Dokument nach [IEEE830-1998] . . . . . . . . . . . . . 3313 3-Tier-Architektur fur Web-Applikationen . . . . . . . . . . . . . . . 3414 Das .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3515 Beispiel fur die Verwendung von Properties . . . . . . . . . . . . . . . 3616 Beispielcode fur die Verwendung eines Indexer . . . . . . . . . . . . . 3617 Beschreibung der Codebehind-Technologie . . . . . . . . . . . . . . . 3818 Zusammenhang von HTML und Server Controls . . . . . . . . . . . . 3919 Lebenszykus eines Page-Objekts . . . . . . . . . . . . . . . . . . . . . 4220 Struktur der Komponenten . . . . . . . . . . . . . . . . . . . . . . . . 4421 Ubersicht der spefizischen Komponenten . . . . . . . . . . . . . . . . 4522 Struktur des Persistenz Frameworks am Beispiel Projekt . . . . . . . 4623 Rollen des Factory Patterns im Persistenz-Framework . . . . . . . . . 4724 Einfugen eines persistenten Objektes . . . . . . . . . . . . . . . . . . 4825 Die Klasse Controller mit zwei Beispielmanagern . . . . . . . . . . . . 4926 Klassendiagramm der persistenten Objekte . . . . . . . . . . . . . . . 5127 Seitenaufbau der Default-Webform . . . . . . . . . . . . . . . . . . . 5228 Die Webform Default und die Codebehind-Klasse PageFrontdoor . . . 5329 Eigenschaften einer Web-Applikation . . . . . . . . . . . . . . . . . . 5430 Beispielanwendung fur ein Datagrid . . . . . . . . . . . . . . . . . . . 5431 Beispiel fur ein User Control . . . . . . . . . . . . . . . . . . . . . . . 5532 Klasse DateControl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5633 Sequenz Diagramm zum DateControl am Beispiel Mitarbeitereinga-

bemaske . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5634 Beispielklasse des PageNavigators zur Steuerung der Benutzeroberflache 5835 Abhangig vom PageNavigator werden die jeweiligen Templates geladen 5836 Beispiel fur Zustandsanderung mit PageNavigator . . . . . . . . . . . 5937 Sequenz Diagramm fur das Starten einer Session . . . . . . . . . . . . 6038 Zusammenfassende Darstellung am Beispiel Mitarbeiterverwaltung . . 6239 Sequenz Diagramm bei einer Serveranfrage ohne Event . . . . . . . . 6340 Sequenz Diagramm bei einer Serveranfrage durch ein Event . . . . . . 63

vii

41 Referenzielle Aktionen nach [Tur 03, S. 21] . . . . . . . . . . . . . . . 7042 Die ACID-Eigenschaften, die eine Transaktion erfullen sollte . . . . . 7243 Anomalien bei nebenlaufigen Transaktionen nach [FO 04b] . . . . . . 7344 Einfache Darstellung des SQL-Select-Statements . . . . . . . . . . . . 7545 Verbund von zwei SQL-Tabellen . . . . . . . . . . . . . . . . . . . . . 7546 SQL-Select-Statement zu dem Beispielverbund von Abbildung 45 . . 7547 Ad-hoc-Abfrage uber alle Mitarbeiter in einem Projekt in einer aus-

gewahlten Woche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7648 Definition einer Sicht auf Mitarbeiteraccounts . . . . . . . . . . . . . 7649 Beispiel aus der Zeiterfassung fur einen Subquery . . . . . . . . . . . 7750 Beispiel fur outer join . . . . . . . . . . . . . . . . . . . . . . . . . . . 7751 Verkurztes Ergebnis der Anfrage aus Abbildung 50 . . . . . . . . . . 7852 Grafische Darstellung der 2NF . . . . . . . . . . . . . . . . . . . . . . 8153 Grafische Darstellung der 3NF . . . . . . . . . . . . . . . . . . . . . . 8154 Grafische Darstellung der BCNF . . . . . . . . . . . . . . . . . . . . . 8255 Datenmodell nach der IDEF1X-Notation (siehe Kapitel 6.7.1) . . . . 8556 Klasse Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8857 Beispielanwendung fur die Klasse Database ohne Ausnahmebehandlung 8958 Sichten aus der Zeiterfassung . . . . . . . . . . . . . . . . . . . . . . 8959 Screenshot: Eingabemaske der Vertragsmitarbeiter . . . . . . . . . . . 9060 zusammengesetzter Primarschlussel . . . . . . . . . . . . . . . . . . . 9161 Beispiel fur referenzielle Intritat zwischen Projekt und Projekttyp . . 9262 Vorteile einer relationalen Datenbank . . . . . . . . . . . . . . . . . . 9363 Nachteile eines relationalen Datenmodels anhand eines Beispiels . . . 9464 Beispiel fur Tupeltypkonstruktor . . . . . . . . . . . . . . . . . . . . . 10065 Beispiel fur Arraytypkonstruktor . . . . . . . . . . . . . . . . . . . . 10166 Beispiel fur eine SQL-Anfrage auf einem Array . . . . . . . . . . . . . 10167 Beispiel fur einen Referenztypkonstruktor . . . . . . . . . . . . . . . . 10268 Beispiel fur die Vorteile von Zugriffen uber Referenzen . . . . . . . . 10269 Beispiel fur 1:n-Relation . . . . . . . . . . . . . . . . . . . . . . . . . 10370 Merkmale eines strukturierten Typs (basiert auf [Eis+ 99]) . . . . . . 10371 Aufbau eines strukturierten Typs . . . . . . . . . . . . . . . . . . . . 10472 Vereinfachter Definitionsaufbau einer typisierten Tabelle . . . . . . . 10673 Beispiel fur eine typisierte Sicht . . . . . . . . . . . . . . . . . . . . . 10774 Zwei Moglichkeiten fur Vererbung im ER-Modell . . . . . . . . . . . . 11375 Uberblick relationale zu objektrelationaler Datenbank . . . . . . . . . 11676 Beispiel fur eine Implementierung mit objektorientierter Datenbank . 11777 Auswirkung einer Anforderungsanderung (vgl. mit Kapitel 9.3) . . . . 121

viii

1 Motivation und Einleitung

1.1 Motivation

Obwohl die relationale Datenbank die mit Abstand am weitesten verbreitete Daten-banktechnik ist, hat diese doch viele Nachteile. In der Softwareentwicklung werdenobjektorientierte Konzepte eingesetzt um Wiederverwendbarkeit durch Vererbung,komplexe Datentypen, usw. zu verwenden und beim Modellieren der Datenbank wirdauf flache und einfache Tabellenstrukturen zuruckgegriffen.

In dieser Arbeit werden die Moglichkeiten einer objektrelationale gegenuber einerrelationalen Datenbank verglichen. Grundlage fur die objektrelationale Datenbankist der Standard SQL:19991. Eine objektrelationale Datenbank ist eine Erweiterungeiner relationalen Datenbank und bietet Konzepte an, mit denen Objektorientierungin einer Datenbank moglich ist.

Zuvor aber musste ein sehr konkretes Problem gelost werden. Von der FirmaFrancotyp Postalia wurde ich beauftragt im Rahmen einer Diplomarbeit ein web-basiertes Zeiterfassungssystem zu entwickeln. Das erste Problem, was sich dabeistellte, war: Was soll das Zeiterfassungssystem konnen, also die Analyse? In vielenVortragen zum Thema UML und anderen Modellierungstechniken wird sofort damitbegonnen, das Problem zu modellieren, aber woher kommen die Beschreibungen furdie zu losenden Probleme? Vor allem, wenn es sich um ein Projekt in einer ”echten”Firma handelt, sind die Anforderungen oft nicht von vornherein so klar. Durch Re-quirements Engineering soll genau diese Frage beantwortet werden: ”Was genau sollentwickelt werden?”

Fur die Entwicklung der Applikation wurde das .NET Framework verwendet. Ei-ne der Komponenten dieses Frameworks ist ASP.NET. ASP.NET ist eine Technik,mit der Web-Applikationen entworfen werden konnen, die ein etwas anderes Vorge-hen besitzt, als es bei der Entwicklung von herkommlichen Web-Applikationen derFall ist.

Ein weiterer Ansatz, um die Unterschiede zwischen objektorientierter Program-mierung und relationaler Datenbank zu verringern, ist die Verwendung eines Mapping-Tools, wie in [Scr+ 97] unter dem Begriff ”gateway-based object persistence” be-schrieben ist. Bei einem Mapping-Tool wird eine automatische Umwandlung vonKlassenstrukturen zu relationalen Datenstrukturen vorgenommen. Basierend aufdiesem Konzept und der Struktur eines bereits existierenden Persistenz-Framework,wurde eine Framework entworfen, was einen direkten Vergleich der Datenbanktech-niken ermoglichen soll.

1SQL:1999 ist der offizielle Namen und ist gleichbedeutend mit SQL-99 oder SQL-3.

1

Diese Struktur ermoglicht daruber hinaus nicht nur eine logischen, sondern aucheine physikalische Trennung zwischen Entwurf und Implementierung. Das entwickel-te Framework bildet dabei den Entwurf und die Komponente, die diese Frameworkverwendet, und enthalt (fast) nur noch Implementierungsaspekte.

Den Abschluss dieser Arbeit bildet ein Vergleich der relationalen und der objekt-relationalen Datenbanktechnik, Schlussfolgerungen aus dem Entwicklungsprozessund ein Ausblick, in dem die Verwendung einer objektorientierten Datenbank be-trachtet wird.

1.2 Die zu losende Aufgabe

Von der Firma Francotyp Postalia wurde eine Aufgabe gestellt, die, wie bereitserwahnt wurde, im Rahmen einer Diplomarbeit gelost werden sollte. Francotyp Pos-talia stellt Frankier- und Kuvertiermaschinen her. Fur die Entwicklung einer neuenFrankiermaschine2 sind u. a. folgende Schritte notig, die von verschiedenen Teams(im Folgenden Fachgruppe genannt) bearbeitet werden:

• Entwicklung und Weiterentwicklung der Hardware

• Entwicklung der eingebetteten Software

• Entwicklung der Mechanik

• Entwicklung und Weiterentwicklung von Tools zum Konfigurieren der Maschi-ne

• Serverentwicklung zur Verwaltung der Kundendaten

Die Fachgruppen erledigen dabei unterschiedliche Tatigkeiten, die in einer abs-trakten Form fur alle Arten von Fachgruppen gleich sind. Bei einer Hardwareent-wicklung muss, genauso wie bei einer Softwareentwicklung, analysiert, entworfen,implementiert und getestet werden.

In langer und muhevoller Arbeit hat die Abteilung Hardware- und Software-entwicklung, von der ich beauftragt wurde, einen solchen Katalog mit abstraktenAufgabenbeschreibungen (im Folgenden Aufgabenkatalog) erstellt. Diese Aufgaben-kataloge sollen eine Vergleichbarkeit der unterschiedlichen Fachgruppen moglich ma-chen. Abbildung 1 zeigt dies anhand eines Beispiels. Obwohl das Zusammenlotenvon Schaltungen scheinbar nichts mit der Programmierung einer Applikation zu tunhat, kann es doch im Aufgabenkatalog Implementierung eine Vergleichbarkeit vonHardware- und Softwareentwicklung ermoglichen.

2Frankiermaschinen sind Maschinen, die einen der Briefmarke entsprechenden Aufdruck aufeinen Briefumschlag oder ein abziehbares Label drucken.

2

Aufgabenkatalog Fachgruppe Hardware Fachgruppe SoftwareAnalyse 20 % 30 %Entwurf 30 % 60 %

Implementierung 50 % 10 %

Abbildung 1: Beispiel fur eine Vergleichbarkeit von Fachgruppen

1.3 Vorgehensweise

Bei der Entwicklung der Applikation Zeiterfassung wurde, wie in Abbildung 2 dar-gestellt ist, vorgegangen.

Abbildung 2: Gliederung und Vorgehensweise

Der erste Schritt in einem Softwareentwicklungsprozess ist die Analyse. Require-ments Engineering stellte Techniken, Methoden und Vorgehensweisen zur Verfugung,zum Erheben, Analysieren und Beschreiben von Anforderungen. Durch eine syste-matische Vorgehensweise sollen Fehler in der Analyse vermieden werden. Im Kapitel2 werden diese Konzepte vorgestellt. Das Kapitel 2 dient als Grundlage fur die ei-gentliche Analyse bzw. Anforderungsermittlung, die in Kapitel 3 beschrieben wird.

Nach der Analyse folgt der Entwurf. Die zu erstellende Applikation sollte mitdem ASP .NET Page-Framework entwickelt werden. Im Kapitel 4 wird diese Frame-work vorgestellt und auf einige Konzepte, die im Weiteren benotigt werden, genauereingehen. Prinzipiell sollte der Entwurf unabhangig von der Implementierung sein.Es hat sich aber herausgestellt, dass dies fur die Entwicklung in einem Frameworknicht so ohne weiteres moglich ist. Im Kapitel 5 wird, basierend auf den Konzepten

3

von Kapitel 4, der Entwurf fur die Zeiterfassung mit ASP.NET beschrieben.

Um eine Vergleichbarkeit von verschiedenen Datenbanktechniken zu ermoglichen,wurde ein Framework entwickelt. Die datenbankspezifischen Aspekte werden in eineseparate Komponente auslagert, die das entwickelte Framework verwendet. Damitkann, abhangig von der verwendeten Datenbanktechnik, eine der spezifischen Kom-ponenten verwendet und verglichen werden. Die konkrete Implementierung wurdemit einer relationalen Datenbank durchgefuhrt.

Basierend auf dem entwickelten Framework von Kapitel 4, wird die eine ver-wendete Komponente mit einer Implementierung mit einer relationalen Datenbankvorgestellt (siehe Kapitel 6). Ausgehend von den Problemen, die sich dabei erge-ben haben, wird diese Implementierung mit der einer objektrelationalen Datenbankverglichen (siehe Kapitel 7).

4

2 Requirements Engineering

2.1 Einleitung

Oft sind Fehler in der Softwareentwicklung auf eine schlechte Analyse zuruckzufuh-ren (vgl. u. a. [Rup 01]). Unklare, nicht oder nur oberflachlich formulierte Anforde-rungen konnen in einem Projektverlauf zu vielen Missverstandnissen und spaterenAnderungen fuhren. Diese Anderungen sind unter Umstanden sehr zeitaufwendigoder gar nicht mehr moglich. Wie in [Rup 02, S. 1] beschrieben ist, stellen die An-forderungen das Fundament der Softwareentwicklung dar. Umso wichtiger ist es, dassdiese Phase der Softwareentwicklung mit besonderer Sorgfalt durchgefuhrt wird.

In diesem Kapitel werden die Grundlagen (Kapitel 2.2) und einige Techniken be-schrieben, mit denen ein Requirements Document erstellt wird. Das RequirementsDocument ist das Ziel der Entwicklungsphase Requirements Engineering und be-schreibt die Anforderungen an ein zu erstellendes Softwaresystem.

Der Requirements Engineering Prozess besteht, wie in Abbildung 3 dargestellt,aus drei Phasen.

Abbildung 3: Requirements Engineering Prozess [Som Saw 97, S. 113]

Zunachst werden die Anforderungen ermittelt (Requirements Elicitation). In Ka-pitel 2.4 wird gezeigt, wie durch Befragung der System Stakeholder, Analyse des Ist-Zustands und Untersuchung der vorhandenen Unterlagen dabei vorgegangen wird.

System Stakeholder sind Personen, die das System direkt oder indirekt benut-zen. Beispiele fur System Stakeholder sind Kunden, Administratoren, Manager undMitarbeiter.

Nachdem die Anforderungen erhoben wurden, werden diese auf ”Schwachen” hinuntersucht. In Kapitel 2.5 wird beschrieben, wie inkonsistente, unvollstandige, fehler-hafte und unvollstandige Anforderungen erkannt werden. Die Fragen und Probleme,

5

die sich bei den ”fehlerhaften” Anforderungen ergeben, mussen weiter hinterfragtwerden (Requirements Negotiation), was zu neuen oder geanderten Anforderungenfuhren kann. Wie in Abbildung 3 dargestellt, ist der Requirements Engineering Pro-zess ein zyklischer, d. h., die geanderten oder neu hinzugekommenen Anforderungenmussen wiederum analysiert werden. Im Idealfall ist der Requirements EngineeringProzess beendet, wenn alle Unstimmigkeiten beseitigt sind.

Parallel zu diesen drei Phasen mussen die Anforderungen aufgeschrieben werden.Bei der Beschreibung der Anforderungen ergeben sich u. a. folgende Fragen, die imKapitel 2.3 beantwortet werden:

• Wie werden die Anforderungen in dem Requirements Document strukturiert?

• Wie werden die einzelnen Anforderungen beschrieben?

• Wie konnen Systemmodelle unterstutzend eingesetzt werden?

2.2 Definitionen

Bevor auf die einzelnen Phasen des Requirements Engineering Prozesses eingegangenwird, werden in diesem Abschnitt einige Begrifflichkeiten und Grundlagen beschrie-ben.

2.2.1 Was sind Requirements?

In [Som Saw 97, S. 5, eigene Ubersetzung] wird die Frage folgendermaßen beantwor-tet:

”Requirements (=Anforderungen) sind die Spezifikation von dem, was implemen-tiert werden soll. Sie beschreiben die Benutzermoglichkeiten, die generellen System-rechte (Beispiel: Personalinformationen sind nur einsehbar, wenn sich der Benutzerauthentifiziert hat), die generellen Bedingungen an das System (Beispiel: alle 10Sekunden soll ein Sensorwert ausgelesen werden) und die Bedingungen an den Ent-wickler (Beispiel: Das System soll in C++ entwickelt werden)”.

2.2.2 Definition: Requirement

Nach [IEEE610.12-1990] wird eine Requirement folgendermaßen definiert:

1. Eine Bedingung oder Fahigkeit von einem Benutzer, die benotigt wird, um einProblem zu losen oder eine Zielsetzung auszufuhren.

2. Eine Bedingung oder Fahigkeit, die beschlossen wird oder die ein System odereine Komponente besitzen muss, um einen Vertrag, Standard, Spezifikationoder andere formell aufgelegte Dokumente zu erfullen.

3. Eine dokumentierte Reprasentation der Bedingungen von (1) und (2).

6

2.2.3 Bedingungen an ein Requirement

Nach [IEEE830-1998] sollten Anforderungen mindestens folgende Bedingungen er-fullen:

korrekt: Anforderungen mussen die (wahren) Kundenanforderungen widerspiegeln.

unmissverstandlich bzw. eindeutig : Anforderungen durfen keinen Interpreta-tionsspielraum zulassen.

vollstandig: Vor allem die Bedingungen sind zu uberprufen, Ausnahme- und Son-derfalle sind zu prufen.

konsistent: Jede Anforderung muss fur sich allein konsistent sein.

sortiert nach Bedeutung und Stabilitat: Durch die Vergabe von Prioritatenkonnen Anforderungen nach ihrer Wichtigkeit sortiert werden.

testbar: Anhand einer Anforderung sollte sich muhlos ein Testfall ableiten konnen.

anderbar: Anderungen an einer Anforderung durfen keine Inkonsistenz zu anderenAnforderungen entstehen lassen. Ggf. mussen Abhangigkeiten der Anforderun-gen untereinander definiert werden, um diese anderbar zu machen.

nachvollziehbar: Es sollte nachvollziehbar sein, warum die Anforderung so gestelltwurde, z. B. durch Referenzen auf zusatzliche Unterlagen oder anderen Doku-menten.

2.2.4 Was ist Requirements Engineering?

Requirements Engineering beschreibt die Aktivitaten, die notig sind um Anforde-rungen zu ermitteln, zu beschreiben und auf Korrektheit, Vollstandigkeit, Konsis-tenz und Relevanz zu uberprufen. Der Begriff Engineering impliziert, dass es sichum eine systematische und wiederholbare Technik handelt (vgl. [Som Saw 97, S. 5]).

Bei den Anforderungen unterscheidet man außerdem zwischen funktionalen undnicht-funktionalen Anforderungen. Nicht-funktionale Anforderungen sind z. B. Qua-litatsanforderungen oder Randbedingungen und lassen sich oft nur sehr schwer odergar nicht messen. Funktionale Requirements beschreiben die (messbaren bzw. test-baren) Eigenschaften des Systems. Dabei ist die Trennung nicht ganz eindeutig undviele nicht-funktionale Anforderungen lassen sich durch detailliertere Beschreibungin funktionale und damit auch messbare Anforderungen umwandeln (vgl. [Gli 04,Kap. 5.4]). Wie in Kapitel 3.2.1 noch zu sehen sein wird, konnen nicht-funktionaleAnforderungen in funktionale umgewandelt werden.

7

2.3 Das Requirements Document

2.3.1 Einleitung

Das Requirements Document beschreibt die Anforderungen fur die Kunden, die Be-nutzer und die Entwickler. Es sollte in einer einfachen, fur jedermann verstandlichenSprache geschrieben sein. Das Requirements Document soll die verschiedensten In-teressen und Sichtweisen der Benutzer- und Personengruppen widerspiegeln (siehe[Som Saw 97, S. 38 f.].

• Dem Kunden3 dient das Requirements Document zur Uberprufung, ob seineAnforderungen richtig verstanden wurden.

• Dem Projektmanagement dient das Requirements Document als Grundlagefur die Angebotserstellung und die Planung des Entwicklungsprozesses.

• Dem Systementwickler dient das Requirements Document als Grundlage furden Entwurf und die Implementierung des Systems.

• Die Tester sollen aus den Anforderungen Testfalle ableiten konnen, um zuuberprufen, dass die Anforderungen auch erfullt sind.

Sehr haufig werden in diesem Zusammenhang die Begriffe Pflichtenheft und Las-tenheft verwendet. In einem Lastenheft werden die Anforderungen aus Sicht desKunden aufgeschrieben. Die erweiterte Version des Lastenheftes ist das Pflichten-heft. Im Pflichtenheft werden die Anforderungen des Kunden verfeinert und konkreteRealisierungsansatze ermittelt. Kurz gesagt beschreibt das Lastenheft, was zu losenist und warum. Das Pflichtenheft erweitert das Lastenheft um das Wie und Wo-mit. Das Pflichtenheft wird dem Auftraggeber vorgelegt und dient als Grundlagefur einen Vertrag zwischen dem Systementwickler und Auftraggeber (vgl. [ViSEK]).

In der Realitat gibt es dabei oft Probleme, da das Pflichtenheft nicht immer kon-form zum Lastenheft ist. Beim Requirements Engineering gibt es ein RequirementsDocument, was das Pflichten- und das Lastenheft ersetzen soll.

2.3.2 Requirements beschreiben

Anforderungen mussen so beschrieben werden, dass sie kurz, verstandlich und ein-deutig sind. Sie durfen keinen Interpretationsspielraum zulassen und mussen die inKapitel 2.2.3 genannten Bedingungen erfullen.

3Der Kunde wird im weiteren Verlauf als Auftraggeber bezeichnet und ist der beschriebeneAbteilungsleiter.

8

Die Beschreibung solcher Anforderungen ist nicht ganz einfach, da kurze einfacheFormulierungen und vollstandig Beschreibungen mit allen Sonder- und Ausnahme-fallen oft einen Widerspruch darstellen. Ein weiteres Problem stellen die sehr un-terschiedlichen Lesergruppen (siehe Kapitel 2.3.1) dar. Die Anforderungen sollen sogestellt werden, dass ein Entwickler daraus eindeutig ableiten kann, was entwickeltwerden soll, und das Projektmanagement beispielsweise muss die gleichen Anforde-rungen ebenfalls verstehen konnen, um daraus ein Angebot erstellen zu konnen. Diesist vor allem bei einer rein naturlichsprachlichen Anforderungsbeschreibung oft sehrschwierig.

Ein weiteres Problem mit der naturlichsprachlichen Anforderungsbeschreibungsoll das folgende Beispiel verdeutlichen (vgl. auch [Som Saw 97, S. 141 ff.]): ”Wennder Benutzer eingeloggt ist und den Button Administration bestatigt hat, kann er,wenn er das Benutzerrecht ’Administrator’ besitzt und sofern kein anderer...”

Weitere Probleme, die sich nach Sawyer und Sommerville (vgl. [Som Saw 97, S.147]) bei einer naturlichsprachlichen Beschreibung ergeben, sind, dass diese Termi-nologien meist in einer inkonsequenten und unsauberen Form verwendet werden.

Die Verwendung einer Spezifikationssprache fur Requirements hat den Nachteil,dass sie wahrscheinlich nicht von jedem sofort verstanden wird und erst erlerntwerden muss (vgl. [IEEE830-1998, Kapitel 4.3.2.2]). Wie schon erwahnt wurde, sinddie Systementwickler nur eine der Lesergruppen.

2.3.3 Systemmodellierung

Systemmodelle beschreiben einen bestimmten Aspekt eines Systems. Sie erganzendas Requirements Dokument, um die Anforderung verstandlicher zu beschreiben,und sollten parallel zur Anforderungsermittlung erstellt werden (vgl. [Som Saw 97,S 299]).

Systemmodelle helfen zum einen die Anforderungen besser zu verstehen undkonnen es erleichtern, mit dem Auftraggeber zu kommunizieren. Zwei wichtige Ty-pen von Systemmodellen sind verhaltensorientierte und strukturelle Modelle (vgl.[Som Saw 97, S. 307]). Die strukturellen Modelle beschreiben die Entitaten und dieAbhangigkeiten dieser zueinander sowie die Struktur des Systems oder der Kompo-nenten. Ein Beispiel fur die verhaltensorientierten Modelle sind Statechart Diagram-me oder Timeline Diagramme.

Prinzipiell sollten die Systemmodelle die gleichen Anforderungen wie die eigent-lichen Anforderungen erfullen, da diese genauso von allen genannten Lesergruppenverstanden werden sollen.

9

2.3.4 Struktur des Requirements Documents

Im Requirements Document sollen die gesammelten und analysierten Informationen(Requirements, Systemmodelle, Beschreibung der Stakeholder) in einer strukturier-ten Form dargestellt werden.

Zu diesem Zweck wurde ein Standard entwickelt, der in [IEEE830-1998] beschrie-ben ist und als Grundlage fur das Requirements Document dienen kann. DieserStandard ist sehr allgemein gehalten, gibt aber trotz allem eine Reihe von Punktenvor, die grundsatzlich in jedem Requirements Documents enthalten sein sollten. DerStuktur des Hauptteils ist dabei offen gehalten. Es werden lediglich Templates furmogliche Strukturen vorgeschlagen. Die Verwendung eines Standards hat den Vor-teil, dass nicht jede Firma das ”Rad neu erfinden” muss und auf die Erfahrungenanderer zuruckgegriffen werden kann. Neue Mitarbeiter, die ein Requirements Do-cument lesen, was einem firmeneigenen Standard folgt, mussen sich erst einarbeiten,um mit diesem arbeiten zu konnen. Softwareunterstutzte Tools, die auf diesem Stan-dard basieren, sind in der Regel preiswerter als selbst entwickelte Tools, welche aufdem firmeneigenen Standard aufbauen.

2.4 Anforderungen erheben (Elicitation)

2.4.1 Einleitung

In diesem Abschnitt geht es darum, die Anforderungen zu ermitteln. Haupt- undMittelpunkt bei der Anforderungserhebung sind die Stakeholder (vgl. [Rup 02, S. 140f.]). Durch eine erste Befragung des Auftraggebers (siehe 2.4.2) werden die generellenZiele und die ersten Stakeholder ermittelt. In Abschnitt 2.4.3 werden Technikenvorgestellt, mit denen diese befragt werden konnen. Parallel zu den Befragungender Stakeholder konnen weitere Techniken verwendet werden, die in Abschnitt 2.4.4vorgestellt werden.

2.4.2 Erste Schritte

Als ersten Schritt in der Anforderungserhebung wird in [Som Saw 97, S. 66 ff.] eineMachbarkeitsstudie vorgeschlagen. Eine Machbarkeitsstudie im eigentlichen Sinnewar diesem Fall aus zeitlichen Grunden nicht moglich. Basierend auf dem Fragen-katalog von [Som Saw 97, S. 66 ff.] konnen die in Abbildung 4 dargestellten Fragenzum ersten Interview des Auftraggebers dienen. Durch die letzte Frage werden dieersten Stakeholder ermittelt.

2.4.3 System Stakeholder identifizieren und befragen

Ein sehr wichtiger Punkt in der Anforderungsermittlung ist die Ermittlung und Be-fragung der Stakeholder. Wenn nicht alle Stakeholder ermittelt werden, besteht dieGefahr, dass wichtige Anforderungen vergessen werden (vgl. [Som Saw 97, S. 72 ff.]),

10

1. Was ist das Ziel des Systems?

2. Was ware die Konsequenz, wenn wir das System nicht entwickeln?

3. In welchen direkten und indirekten Wegen beeinflusst das System die Ge-schaftsprozesse?

4. Welche kritischen Prozesse muss das System berucksichtigen?

5. Welche kritischen Prozesse werden von dem System nicht unterstutzt?

6. Wie beeinflusst das System die vorhandenen Systeme?

7. Was sind die Bedingungen an den Entwickler?

8. Welche Geschaftsbereiche sind in das System integriert und mussen betrachtetwerden?

Abbildung 4: Erste Befragung des Auftraggebers

oder wie in [Rup 02, S. 148] beschrieben ist: ”Vergessene Stakeholder sind vergesse-ne Anforderungen”. Ein nachtragliches Hinzufugen von Anforderungen ist dann nurnoch mit sehr viel Aufwand moglich.

Durch die Geschaftsbereiche, die in das System integriert werden sollen, lassensich die ersten Benutzergruppen ermitteln (vgl. letzte Frage aus Abbildung 4). ImFolgenden werden einige Befragungstechniken vorgestellt, mit denen die Anforde-rungen von der Stakeholder ermittelt werden konnen. Ein grundsatzlicher Vorteilbei der Befragung der Stakeholder ist, dass sich diese durch die Befragung starkeran der Entwicklung beteiligt fuhlen, was die Akzeptanz an das neue System erhoht.

FragebogenFragebogen sind vor allem dann eine geeignete Technik, wenn in kurzer Zeit vieleInformationen gesammelt werden sollen. Sie haben allerdings den Nachteil, dass diebefragten Personen keine Fragen stellen konnen, und setzen voraus, dass bekanntist, welche Informationen benotigt werden, was in dieser Arbeit oft nicht der Fallwar.

EinzelinterviewIn [Sah 00, S. 21] werden zwei Arten des Einzelinterviews beschrieben.

Bei einem geschlossenen Interview werden zuvor Fragen vorbereitet, die dementsprechenden Stakeholder gestellt werden. Ruck- und Verstandnisfragen sind zwar

11

moglich, aber diese Technik verlangt ein strenges Vorgehen nach den vorher definier-ten Fragen und erlaubt nicht, dass auf die Fragen weiter eingegangen werden kann.Wie in [Sah 00, S. 21] dargestellt ist, besteht bei dieser Technik das Problem, dasswichtige Aspekte nicht berucksichtigt werden, die durch ein ”freies Reden” aufkom-men konnten. Einer der Vorteile dieser Methode ist, dass kein aufwendiges Proto-kollieren notig ist und die gleiche Befragung bei einem anderen Reprasentanten derStakeholdergruppe durchgefuhrt werden kann.

Die zweite Moglichkeit ist das offene Interview. In diesem Fall wir eine zentra-le Frage bzw. ein zentrales Ziel der Befragung definiert und der Befragende kannabhangig von den gegebenen Antworten weitere Fragen stellen. Bei dieser Technikbesteht das Problem, dass auf unwichtige Themen abgeschweift werden kann undsowohl die Fragen als auch die Antworten mussen protokolliert werden. Außerdemist ein geschlossenes Interview in gleicher Form nicht reproduzierbar.

GruppeninterviewIn einem Gruppeninterview wird eine reprasentative Menge an Stakeholdern ermit-telt, mit denen gemeinsam die Anforderungen oder Probleme analysiert werden. DieVorgehensweise ist dabei ahnlich der des offenen Interviews. Das Gruppeninterviewhat zusatzlich den Vorteil, dass sich die Stakeholder gegenseitig Feedback gebenkonnen und durch die gemeinsame Analyse schneller eine Losung erreicht werdenkann. Eine Diskussion in einer Gruppe hat aber auch einige weitere Nachteile imVergleich zum offenen Einzelinterview, wie z. B. die Einschuchterung von Befragtendurch Anwesenheit eines Vorgesetzten oder Kollegen.

BrainstormingEine spezielle Form der Gruppenbefragung ist das Brainstorming. Brainstormingbesteht in zwei Phasen:In der ersten Phase werden alle Ideen gesammelt und aufgeschrieben, ohne dass siebewertet werden. Dabei konnen auch ungewohnliche Ideen aufkommen oder sich be-liebige Kombinationen ergeben. Erst in der zweiten Phase werden die Ideen bewertetund die unsinnigen Ideen verworfen oder korrigiert.

2.4.4 Unterstutzende Analysetechniken

Im Folgenden werden einige Techniken beschrieben, die sich nicht auf die Befragungder Stakeholder beziehen und unterstutzend eingesetzt werden konnen. Diese Techni-ken allein sind oft wenig hilfreich, aber eine wertvolle Erganzung zu den Befragungen.

Analyse von Dokumenten und VorgangersystemenVor allem existierende Dokumente aller Art zu diesem Thema konnen eine hilfreicheErganzung darstellen. Gescheiterte Entwicklungen oder existierende Vorgangersys-teme konnen bereits einige Probleme gelost haben und sind ebenfalls eine hilfreiche

12

Unterstutzung.

PrototypingEine weitere Technik ist das Prototyping. Beim Prototyping werden bereits einigeFunktionalitaten in einer sehr fruhen Phase implementiert, um das Benutzerverhal-ten zu demonstrieren. Bei dieser Technik gibt es zwei Vorgehensweisen: das explo-rative und das evolutionare Prototyping.

Beim explorativen Prototyping werden die Benutzermoglichkeiten des zu erstel-lenden Systems an einer einfachen Anwendung dargestellt, ohne dass konkrete Funk-tionalitaten existieren. Dieser Prototyp hat den Zweck, die Beschreibung der An-forderungen zu unterstutzen, und wird nach dem Requirements Engineering nichtweiter verwendet. Ein explorativer Prototyp sollte mit einfachsten Mitteln erstelltwerden konnen (z. B. Drag-and-Drop4). Obwohl ein explorativer Prototyp zusatzli-che Zeit kostet, kann sich diese investierte Zeit doch lohnen, da eine ”funktionsfahige”Benutzeroberflache oft mehr aussagt als eventuell umstandliche Beschreibungen.

Im Gegensatz dazu gibt es das evolutionare Prototyping. Dieser Prototyp wirdweiter verwendet und entwickelt, um dann schließlich daraus ein fertiges System zuerhalten. Durch die Verwendung eines evolutionaren Prototypen hat der Auftragge-ber die Moglichkeit, den Entwicklungsprozess mit zu verfolgen. Fehler und Problemekonnen so fruhzeitig erkannt werden und die Stakeholder fuhlen sich starker an derEntwicklung beteiligt. Allerdings konnen dadurch auch immer weitere Anforderun-gen entstehen, die erst beim Prototyp erkannt werden. Da der evolutionare Prototypgleichzeitig ein Teil des endgultigen Systems darstellt, kann es aber sehr schwierigwerden, diese Anderungen mit zu berucksichtigen.

Viewpoint-orientierter AnsatzEin weiterer Ansatz ist der Viewpoint-orientierte Ansatz. Die verschiedenen Sichtender Stakeholder und die verschiedenen Aspekte der Software konnen separat be-trachtet werden. Durch die Betrachtung der Anforderungen unter einem bestimmtenGesichtspunkt (View) kann die Komplexitat der Anforderungen vermindert werdenund ist somit leichter verstandlich. Viewpoints konnen neben der Anforderungserhe-bung auch zum Analysieren und in der Beschreibung der Anforderungen verwendetwerden. Wie schon in 2.3.2 erwahnt wurde, stellt es eine Schwierigkeit dar, Anforde-rungen so zu formulieren, dass sie von allen Lesergruppen verstanden werden. Zweimogliche Viewpoints, die betrachtet werden konnten, sind die Benutzeranforderun-gen, und zwar einmal mit und einmal ohne Systemanforderungen (vgl. [Som Saw 97,S. 7]). Weitere Moglichkeiten fur die Ermittlung von Viewpoints sind die referen-zierten Quellen oder die Benutzerrechte.

4”ziehen und loslassen”, d. h., die Benutzeroberflache wird zusammengeklickt

13

2.5 Anforderungen analysieren und neu verhandeln

Im Folgenden werden zwei Ansatze vorgestellt, mit denen Anforderungen auf Schwa-chen hin untersucht werden konnen. Schwachen in Anforderungen sind nichts Schlech-tes. In [Som Saw 97, S. 125] werden sie als naturlich und unvermeidbar dargestellt.

Der erste Ansatz ist die Analyse auf sprachlicher Ebene. Anhand der Formu-lierungen sollen Schwachen erkannt werden. Der zweite Ansatz basiert auf der in-haltlichen Analyse. Dabei wird uberpruft, ob die Anforderungen die in Kapitel 2.2.3genannten Bedingungen erfullen und konform zueinander sind.

Die gefundenen Schwachen in den Anforderungen mussen anschließend dem ent-sprechenden Stakeholder oder dem Auftraggeber vorgetragen werden. Durch Be-schreibung des entstandenen Problems oder Konflikts muss gemeinsam eine Losunggefunden werden (vgl. [Som Saw 97, S. 125 ff.]. Wie bereits erwahnt wurde, kon-nen an dieser Stelle neue Anforderungen entstehen, sich Anforderungen andern oderneue Stakeholdergruppen herauskristallisieren.

2.5.1 Anforderungen sprachlich uberarbeiten

Die sprachliche Analyse von Anforderungen basiert auf der Idee, die Formulierun-gen der Anforderungen zu untersuchen und anhand dieser Schwachen und Fehlerzu ermitteln. In [Rup 01] werden drei Arten der sprachlichen Analyse vorgestellt:Tilgung, Generalisierung und Verzerrrung.

Bei der sprachlichen Tilgung werden Informationen weggelassen. Oft ist es sinn-voll, zu viele Details in der ersten Phase der Anforderungsermittlung zu vermeiden,um das Problem als Ganzes zu verstehen. Wurden die Anforderungen aber bereitserhoben und sollen analysiert werden, mussen diese Tilgungen wieder hinterfragtwerden um die Anforderungen korrekt darzustellen. Eine Form der Informationstil-gung sind unvollstandig definierte Prozessworter5. Diese mussen ermittelt werdenund weiter hinterfragt werden. Eine weitere Form der Informationstilgung sind un-vollstandige Komparative oder Superlative. Diese benotigen immer einen Bezugs-punkt, der, wenn er spezifiziert ist, auch messbar sein sollte.

Durch Generalisierung bzw. Verallgemeinerungen werden Anforderungen oftzu ungenau beschrieben. Sonder- und Ausnahmefalle werden nicht berucksichtigt,wodurch die Anforderungen unvollstandig werden. Zur Uberprufung einer Gene-ralisierung konnen Universalquantoren gesucht werden (siehe [ViSEK]), wie zumBeispiel ”alle”, ”jeder”, ”nie”, ”immer”. Diese Begriffe sind ein Anzeichen fur eineGeneralisierung und es muss hinterfragt werden, ob diese Anforderung wirklich furalle bzw. fur keinen der moglichen Falle eintritt. Unvollstandig spezifizierte Bedin-

5Prozessworter sind Worter, die einen Prozess beschreiben.

14

gungen konnen ebenfalls Anzeichen fur Schwachen in den Anforderungen darstellen.Dabei ist zu hinterfragen, was passiert, wenn die gegebene Bedingung nicht eintritt.Substantive ohne Bezugspunkt mussen ebenfalls hinterfragt werden, ob diese nichteine bestimmte Person oder einen Gegenstand darstellen. Beispiele fur solche Sub-stantive sind: ”die Daten”, ”die Funktion” oder ”das System” (vgl. [ViSEK]).

Durch Verzerrung werden zeitlich zusammenhange Informationen zusammen-gefasst. Ein Beispiel fur eine Verzerrung ist Nominalisierung. Dabei wird ein Prozesszu einem Ereignis umformuliert. Beispiele sind ”das Drucken” oder ”das Melden”.Hinter diesen Anforderungen konnte sich ein Prozess verbergen. Ein weiteres An-zeichen fur Schwachen in den Anforderungen sind Worter wie ”machen”, ”konnen”oder ”haben”. Diese drucken Anforderungen oft nur unvollstandig aus (siehe auch[Rup 02, S. 208 ff.]).

2.5.2 Checklisten zur Uberprufung

Die Verwendung von Checklisten zur Uberprufung der Anforderungen hat den Vor-teil, dass die Anforderungen systematisch und wiederholbar untersucht werden kon-nen. Jede Anforderung wird so lang gegen jeden Checklisteneintrag getestet, bisalle ”Fehler” beseitigt sind. In [Som Saw 97, S. 117-120] wird eine initiale Checklistevorgegeben:

voreiliger Entwurf: Beschreibt die Anforderung bereits Entwurfs- oder Imple-mentierungsdetails?

Kombinierte Anforderung: Beschreibt diese Anforderung wirklich eine einzelneAnforderung, oder konnte sie in mehrere unterteilt werden?

Unwichtige Anforderung: Ist diese Anforderung wirklich notig, oder beschreibtsie nur eine kosmetische Verschonerung?

Konsistent zu den Unternehmenszielen: Ist diese Anforderung konform zu demUnternehmenszielen?

Anforderungsmehrdeutigkeit: Kann diese Anforderung von verschiedenen Per-sonen unterschiedlich interpretiert werden? Was sind die moglichen Deutungendieser Anforderung?

Anforderungsrealismus: Ist die Anforderung mit den gegebenen Mitteln undWerkzeugen realisierbar?

Testbarkeit: Ist die Erfullung dieser Anforderung testbar? Kann ein Tester anhanddieser Anforderung einen Testfall ableiten, der zeigt, dass das System dieseAnforderung erfullt?

15

Wenn die oben dargestellten Checklistenpunkte mit den Bedingungen an dieRequirements aus Kapitel 2.2.3 verglichen werden, sieht man, dass diese Checklisteprinzipiell uberpruft, ob die genannten Bedingungen an die Requirements erfulltsind. Die in Kapitel 2.5.1 dargestellte sprachliche Analyse kann ebenfalls in Formeiner Checkliste verwendet werden.

16

3 Analyse mit Requirements Engineering

3.1 Anforderungen erheben

3.1.1 Erste Schritte

Durch eine erste Befragung des Auftraggebers6, wie in Kapitel 2.4.2 beschrieben,wurden die ersten Anforderungen ermittelt. Dabei ergaben sich u. a. die folgendenInformationen. Die detailliertere und uberarbeitete Beschreibung befindet sich in[ReqDoc, Kapitel 1.1 und 2].

Ziele des Systems:

• Es soll ein webbasiertes Zeiterfassungssystem erstellt werden, wo die Mit-arbeiter ihre geleistete Arbeitszeit den Projekten zuschreiben konnen. Diegeleistete Arbeitszeit wird in prozentualer Form auf die vorhandenen Pro-jekte verteilt.

• Die Projekte wiederum bestehen aus einer Menge von Fachgruppen. DieMitarbeiter sollen ihre den Projekten zugewiesene Arbeitszeit auf dieseFachgruppen verteilen.

• Außerdem existieren Aufgabenkataloge, die unabhangig von Projektenund Fachgruppen sind. Jede zugewiesene Arbeitszeit in den Fachgruppenmuss von den Mitarbeitern auf die Aufgabenkataloge verteilt werden.

• Bei ”kleineren”Projekten existieren keine Fachgruppen. Die in diesen Pro-jekten zugewiesene Arbeitszeit wird dann direkt auf die Aufgabenkatalogeverteilt.

• Es sollen zahlreiche Berichte (Reports) erzeugt werden konnen, die ver-schiedenste Daten in aufbereiteter Form darstellen.

• Gleiche Berichte mit gleichen Parametern sollen jederzeit die gleichenDaten anzeigen, d. h., ein nachtragliches Andern von Daten darf keineAnderung in den Berichten verursachen. Folgendes Beispiel soll diese An-forderung erklaren:Wird eine Kostenstelle eines Mitarbeiters geandert, so wurde ein Berichtmit allen Stunden pro Kostenstelle nach der Anderung eine andere Aus-gabe erzeugen.

Konsequenz ohne das System:

• Ohne dieses System ware ein Aufbau von Kennzahlen fur die Personal-entwicklung nicht moglich (siehe auch [ReqDoc, S. 1]), d. h., die obengenannten Berichte mussten muhselig von Hand erstellt werden.

6dem Abteilungsleiter der Abteilung Hardware- und Softwareentwicklung

17

Kritische Prozesse:

• Das System darf personengebundene Leistungskontrolle nicht ermogli-chen, da der Betriebsrat dieses System sonst nicht zulassen wurde.

Grenzen des Systems:

• Eine Anbindung an das existierende SAP-System ist aus politischen unddatenschutztechnischen Grunden nicht moglich.

Bedingungen an den Entwickler:

• Die Zeiterfassung soll eine webbasierte Applikation sein, d. h., die Kom-munikation erfolgt uber einen Webbrowser.

• Fur die Zeiterfassung soll ASP.NET und die Programmiersprache C#verwendet werden.

Geschaftsprozesse oder andere Systeme beeinflusst die Zeiterfassung nicht (sieheFrage 3 und 6 aus Kapitel 2.4.2). Wie an diesen Antworten zu sehen ist, stellten sichdabei weitere Fragen, die nicht auf Anhieb beantwortet werden konnten:

• Woher kommen die Projekte, wenn es keinen Zugriff auf die Projektdaten desSAP-Systems gibt?

• Wenn die Mitarbeiter nur prozentual ihre Arbeitszeit den Projekten zuord-nen, woher kommen dann die absoluten Arbeitszeiten, um daraus Reports zuerstellen?

Aus dieser Befragung ergaben sich die in Abbildung 5 dargestellten Geschafts-bereiche bzw. Stakeholder (vgl. mit Frage 8 und 6 in Abbildung 4 auf Seite 11).

Abbildung 5: Kommunikation zwischen den Stakeholdern

18

3.1.2 Analyse des Ist-Zustandes

Basierend auf dem Ist-Zustand wurden die ersten Stakeholder ermittelt. Das Haupt-ziel der Anwendung ist es, Berichte mit Arbeitsstunden uber Projekte, Fachgruppenund Aufgabenkataloge zu erhalten. Im Vorgangersystem wurden die Berichte, wiein Abbildung 6 dargestellt, erstellt.

Abbildung 6: Activity Diagram des Ist-Zustandes fur die Berichtserstellung

Die Arbeitszeiten der Mitarbeiter werden uber ein externes System erfasst, wasnicht ersetzt werden kann. Diese Zeiten stehen dann in einem SAP-System dem Con-troller zur Verfugung. Uber ein Excell-basiertes System mussen die Mitarbeiter ihreArbeitszeiten nach Ablauf einer jeden Woche auf vorhandene aktive Projekte vertei-len. Der Controller wandelt diese relativen Arbeitszeiten in den Projekten zusammenmit den absoluten Arbeitszeiten aus dem SAP-System in absolute Arbeitszeiten inden Projekten um. Uber die Zuordnung der Mitarbeiter zu bestimmten Kostenstel-len kann er daraus einen Stundenreport fur Projekte nach Kostenstellen und nachMitarbeitern erstellen und diese dem Abteilungsleiter zur Verfugung stellen.

Die Projektverwaltung erfolgt wie in Abbildung 7 dargestellt. Die Projekte wer-den vom Projektmanager7 in einer Exceltabelle verwaltet. Wenn ein neues Projektbeschlossen8 wird, wird der Projektmanager benachrichtigt. Das neue Projekt wirddann in der Exceltabelle angelegt. Die Projektnummer wird dabei manuell ermittelt.Anschließend wird ein Schreiben aufgesetzt, indem u. a. der Controller benachrich-tigt wird, dieses Projekt im SAP-System anzulegen. Das Beenden eines Projekts

7Projektmanager ist in diesem Fall die Sekretarin des Bereichsleiters, der wiederum der Vorge-setzte des Abteilungsleiters ist.

8in einem Projektteammeeting, was fur diese Anwendung aber irrelevant ist

19

Abbildung 7: Zustande eines Projekts

erfolgt in einer ahnlichen Form.

Wie an dieser Beschreibung zu sehen ist, ergeben sich bei dieser Vorgehensweiseviele Probleme. Einige Beispiele hierfur sind die folgenden:

• Die Projekte existieren redundant in drei verschiedenen Systemen: in der Ex-celtabelle des Projektmanagers, im SAP-System, und der Auftraggeber besitztebenfalls ein eigenes System.

• In dem Excel-basierten System des Controllers kann ein Projekt nur hinzuge-fugt werden. Abgeschlossene Projekte zu loschen oder wenigstens aus der Listeder Projekte zu entfernen ist nicht moglich.

• Der Controller muss bis zu einem festgesetzten Datum jeden Monats einenBericht mit Arbeitsstunden uber Kostenstellen und Projekte erstellen. Wur-den Arbeitszeiten von Mitarbeitern nicht zugewiesen, weil sie beispielsweiseam Ende der Woche in den Urlaub gegangen sind, ohne ihre Zeitverteilungvorzunehmen, so muss der Controller die Zeitverteilung fur diese Mitarbeitervornehmen, da alle Arbeitsstunden auf Projekte verteilt werden mussen.

3.1.3 Befragung der Stakeholder mit verschiedenen Techniken

Fur die Befragung der Stakeholder wurden jeweils die in Kapitel 2.4.3 dargestelltenunterschiedlichen Techniken angewendet.

Gruppeninterview

Die Befragung der Mitarbeiter erfolgte in Form eines (geschlossenen) Gruppen-interviews (vgl. Kapitel 2.4.3). Vier reprasentative Mitarbeiter und der Auftragge-

20

ber sollten klaren, wie die Zeitverteilung vorgenommen wird. Dabei sollten folgendePunkte geklart werden:

• Da Unstimmigkeiten uber die Verwendung von prozentualer oder absoluterZuordnung existierten, sollten die Stakeholder diese Frage beantworten.

• Sollen Fachgruppen global verwaltet und den Projekten zugeordnet werdenoder werden sie fur jedes Projekt neu angelegt?

• Der Nutzen fur die Mitarbeiter sollte geklart werden, d. h. ob es fur sie sinnvollware, wenn sie Berichte uber ihre zugeordneten Zeiten erhalten wurden.

Der letzte Punkt wurde im Wesentlichen nur deswegen gewahlt, um die Akzep-tanz der Mitarbeiter zu steigern und ihnen einen Vorteil darzubieten, der das neueSystem fur sie besitzt. Ein interessantes Phanomen war, dass sich die Meinungenziemlich schnell zu einer gemeinsamen Gruppenmeinung entwickelten. Interessantwar außerdem, dass die Mitarbeiter Prozente eingeben wollten, obwohl sie ihre Ar-beitszeiten als Stunden sehen wollten, so wie zuvor vom Auftraggeber schon gefordertwurde. Nach den Angaben der Stakeholder besteht eine Fachgruppe im Wesentli-chen aus einem festen Kern von Mitarbeitern. Um aber den Administrationsaufwandfur die Verwaltung der Fachgruppe zu vermeiden, sollen diese fur jedes Projekt neuangelegt werden.

Brainstorming

Die moglichen Berichte, die durch die Zeiterfassung erstellt werden konnen, wur-den in einem Brainstorming-Interview durchgefuhrt. Der entscheidende Vorteil desBrainstormings liegt darin, dass ziemlich schnell viele Ideen entstehen. Allerdingshat diese Technik den Nachteil, dass das gegebene Vorgehen auch streng eingehal-ten werden muss, was in diesem Fall nur halbwegs funktioniert hat. Ein weiterernachteiliger Punkt ist, dass es schwierig ist, die Ideen zu bewerten. Grundsatzlichwaren viele gute Ideen dabei, die aber in der gegebenen Zeit nicht realisierbar waren.

Einzelinterview

Die Befragung der Stakeholder Projektmanagement und Controller wurde alsEinzelinterview vorgenommen. Ein strenges Vorgehen in Form eines geschlossenenInterviews (vgl. Kapitel 2.4.3) wurde nicht vorgenommen, um die Moglichkeitennicht von vornherein einzuschranken. Ein Problem stellte auch die Tatsache dar,dass die Fragen nicht genau genug gestellt werden konnten, da nicht genau klar war,was entwickelt werden sollte. Vor der Befragung wurde eine Liste mit Fragen vorbe-reitet, die als Richtlinie fur das Interview diente.

Diese Technik hat sich als sehr vorteilhaft herausgestellt, da durch die vorgegebe-nen Fragen die Ziele des Interviews definiert waren und die Moglichkeiten trotzdem

21

nicht eingeschrankt wurden. Ein weiterer Vorteil war der, dass keine ”geschickte”Moderatorfunktion des Befragenden notig war und keine ”storenden” gruppendyna-mischen Prozesse berucksichtigt werden mussten.

Weitere Befragungen

Fur die Befragungen nach entstandenen Widerspruchen und Schwachen der An-forderungen wurden direkte Befragungen der entsprechenden Stakeholder durchge-fuhrt.

3.1.4 Beschreibung der Stakeholder

Im Folgenden werden die einzelnen Stakeholder beschrieben, die in Kapitel 3.1.2ermittelt und in Kapitel 3.1.3 befragt wurden.

Mitarbeiter:

Bisher wurden nur Mitarbeiter erwahnt. Diese werden weiter unterteilt in interneund externe Mitarbeiter.

Die internen Mitarbeiter arbeiten an den Projekten. An Ende jeder Woche mus-sen sie ihre Arbeitszeiten in prozentueller Form den vorhandenen Projekten, Fach-gruppen und Aufgabenkatalogen zuordnen. Die absoluten Arbeitszeiten der internenMitarbeiter kommen von einem externen System, auf das aus datenschutztechni-schen Grunden nicht zugegriffen werden kann. Die einzige Moglichkeit, diese Datenzu erhalten, besteht darin, diese aus den Exceltabellen des Controllers zu extrahie-ren. Da diese Losung aber sehr instabil ist, muss auf jeden Fall auch eine manuelleStundeneingabe existieren.

Die externen Mitarbeiter arbeiten, genau wie der interne Mitarbeiter, in Fach-gruppen organisiert, an verschiedenen Projekten. Im Gegensatz zu den internen Mit-arbeitern erscheinen externe Mitarbeiter nicht in den Berichten des Vorgangersys-tems. Die externen Mitarbeiter schreiben in unregelmaßigen Zeitabstanden Rech-nungen mit ihren geleisteten Arbeitszeiten und reichen diese beim Abteilungsleiterein.

In Kapitel 6.7.2 werden die internen und externen Mitarbeiter auch als Vertrags-mitarbeiter bezeichnet, da es moglich sein soll, dass Mitarbeiter, die ihre Arbeits-zeiten nicht den Projekten, Fachgruppen und Aufgabenkatalogen zuordnen mussen,ebenfalls Fachsprecher oder Projektleiter sein konnen. Vertragsmitarbeiter sind sozu-sagen eine erweiterte Form der Mitarbeiter. Auf dieses Thema wird in den Kapiteln6.7.2 und 6.8.2 noch eingegangen.

22

Projektmanager:

Der Projektmanager verwaltet die Projekte. Er legt die Projekte mit den entspre-chenden Projektleitern an und kann diese beenden. Außerdem kann er den ProjektenFachgruppen hinzufugen oder entfernen.

Controller:

Der Controller uberwacht die Kosten der Projekte. Am Ende eines jeden Monatsbenotigt er eine Projekt-Kostenstelle-Tabelle mit den geleisteten Arbeitsstunden,die er so effizient wie moglich in das SAP-System eingeben mochte und dem Abtei-lungsleiter zur Verfugung stellt. Der Controller ist die einzige Schnittstelle, um dieabsoluten Arbeitszeiten der internen Mitarbeiter zu erhalten.

Abteilungsleiter:

Der Abteilungsleiter verwaltet die Projekte und die darin enthaltenden Fach-gruppen und Mitarbeiter seiner Abteilung. Sein Hauptinteresse an der Zeiterfassungist die Ausgabe der Berichte.

Administrator:

Diese Rolle existierte vorher nicht und ist notig um verschiedene Daten, wie bei-spielsweise Kostenstellen, zu verwalten. Wie bereits erwahnt wurde, existiert keineMoglichkeit, auf die Daten des SAP-Systems zuzugreifen. Die benotigten Informa-tionen mussen redundant zu dem SAP-System verwaltet werden.

3.1.5 Unterstutzende Analysetechniken

Zwei unterstutzende Techniken bei der Anforderungserhebung sind die Analyse vonvorhandenen Dokumenten und die Analyse eines Vorgangersystems. Der Viewpoint-orientierte Ansatz ist vor allem dann vorteilhaft, wenn das Requirements Engineeringdurch einen CASE-Tool9 unterstutzt wird. Da in diesem Fall aber kein CASE-Toolverwendet wurde, wurde auf diesen Ansatz verzichtet. Wie bereits beschrieben wur-de, kann der Viewpoint-orientierte Ansatz auch fur das Beschreiben von Anforde-rungen verwendet werden, was in diesem Fall getan wurde (siehe Kapitel 3.3.3).

Dokumente und Vorgangersystem:

Eine Access Datenbank, die fur diese Zwecke entworfen worden war und verwen-det wird, lieferte weitere Informationen, die durch die Befragungen nicht aufgekom-

9Ein CASE (Code Aided Software Engineering)-Tools ist eine Software, welche den Software-entwicklungsprozess unterstutzt (siehe auch [Som 00] Kapitel 3).

23

men sind. Ein Beispiel dafur ist die weitere Unterteilung der internen Mitarbeiterin Studenten, Aushilfen und ”normale” interne Mitarbeiter. Die vorhandene Excel-tabelle des Stakeholders Projektmanager zeigte außerdem, dass Projekte weiter inProjektgruppen organisiert sind.

Prototyping:

Zunachst wurde ein explorativer Prototyp (vgl. Kapitel 2.4.4) verwendet, der dieFunktionalitat darstellen sollte. Dies waren einfache PHP-Scripte, die mithilfe einer”Template-Klasse”10 HTML-Templates zu vollstandigen HTML-Seiten zusammen-setzen.

Der entscheidende Vorteil an dieser Technik ist die Trennung von Funktionalitatund Layout uber einen sehr einfachen Mechanismus. Anderungen in den HTML-Templates haben (fast) keine Auswirkungen auf Funktionalitat (in diesem Fall nurdie Benutzersteuerung) und umgekehrt, wodurch sich ziemlich schnell und einfachOberflachen gestalten lassen.

Die Anforderung, dass die Zeiterfassung in ASP.NET und C# entwickelt werdensoll, kam erst etwas spater dazu, wodurch sich ein Problem darstellte. ASP .NETbietet einige grundlegend neue Techniken, wie in Kapitel 4 noch beschrieben wird.Da mir diese Technik nicht vertraut war und nicht vorhergesehen werden konnte, wasmit ASP .NET moglich ist und was nicht, wurde die Art des Prototyping in einenevolutionaren geandert. Wie in Kapitel 2.4.4 beschrieben wurde, stellte sich dabeiein Problem ein. Der Auftraggeber hatte die Moglichkeit, den Entwicklungsprozesszu verfolgen und Anderungen an der definierten Benutzerfuhrung wurden verlangt.

3.2 Analyse der Anforderungen

Gemaß Kapitel 2.5 werden im Folgenden einige Beispiel fur ”Schwachen” in denAnforderungen darstellt und die Konsequenzen daraus beschrieben. Vor allem dernaturlichsprachliche Ansatz (siehe 2.5.1) stellte sich als sehr effizient heraus, dadurch eindeutige Regeln Schwachen in den Anforderungen gefunden werden konnen.Allerdings bot dieser Ansatz keine Moglichkeit, Inkonsistenzen der Anforderungenuntereinander zu analysieren. Der Checklisten-Ansatz aus Kapitel 2.5.2 war etwasschwieriger durchzufuhren, da diese Fragen ein großes Maß an Interpretationsfrei-raum zuließen, d. h., der gleiche Test von einer anderen Person hatte u. U. zu einemanderen Ergebnis gefuhrt. Im Folgenden werden einige Beispiele dargestellt, die zei-gen, welche Schwachen durch die Analyse der Anforderungen gefunden wurden.

10Mehr Informationen zu der Klasse Template befinden sich unter http://phplib.sourceforge.net/

24

3.2.1 Anforderungen sprachlich uberarbeiten

Tilgung:

Das folgende Beispiel zeigt eine Tilgung in Form eines unvollstandig spezifizier-ten Prozesswortes, welche weiter hinterfragt werden musste:

Wurde beim Anlegen eines Projekts keine Projektnummer angegeben, so wird au-tomatisch eine Projektnummer ermittelt, die dem Benutzer voreingestellt in derEingabemaske angezeigt wird.

Das Prozesswort ermittelt stellt dabei ein Schwache dar. Die Frage ist hierbei,wie wird diese Projektnummer ermittelt. Beim Hinterfragen des Stakeholders Pro-jektmanager ergab sich, dass die Projektnummer abhangig von dem Projekttyp ineinem Projektnummerraum liegt.

Eine Konsequenz daraus ist, dass der Projekttyp um mindestens ein weiteresAttribut erweitert wird. Außerdem musste geklart werden, ob sich Projektnummernimmer in dem Projektnummerraum befinden mussen oder diese nur eine Empfeh-lung darstellen, wenn keine Projektnummer eingegeben wurde.

Ein weiteres Beispiel fur eine Tilgung ist ein unvollstandiger Komparativ. Wiebereits in Kapitel 3.1.5 angesprochen wurde, existierten Unstimmigkeiten uber dasAussehen und den Ablauf der Benutzeroberflache, da folgende Anforderungen nichtgenau genug betrachtet wurden:

Die Zeiterfassung soll eine einfach bedienbare und ubersichtliche Benutzerober-flache besitzen.

Die Frage, die sich hierbei u. a. stellt, lautet, wozu die Benutzeroberflache einfachbedienbar sein soll.

Dies ist auch gleichzeitig ein Beispiel fur eine nicht-funktionale Anforderung (vgl.Kapitel 2.2.4), die durch genauere Beschreibung zu einen funktionalen umgeformtwerden musste.

Generalisierung:

Ein Beispiel fur eine Generalisierung, die zu einer Schwache fuhrt ist die Pro-jektzeiterfassung der Mitarbeiter. Dabei stellte sich die Frage, was passiert, wenndie Zuordnungen zu Projekten, Fachgruppen und Aufgabenkatalogen nicht vollstan-dig durchgefuhrt wird, weil beispielsweise der Browser geschlossen oder ein andererMenupunkt ausgewahlt wird.

25

Ohne Betrachtung dieses Problems waren die eingegebenen Daten einfach ver-worfen worden, was im Fall eines Ausfalls, weil beispielsweise der Browser absturzt,sehr argerlich geworden ware. Die Zeitverteilung kann u. U. etwas Zeit in Anspruchnehmen und ein frustrierter Mitarbeiter, der seine Zuordnungen ein zweites Mal vor-nehmen muss, weil alle Daten verworfen wurden, wird sicherlich keine allzu grund-lichen Angaben mehr vornehmen.

Nominalisierung:

Ein Beispiel fur Nominalisierung ist folgende Anforderung:

Durch die Eingabe einer Exceltabelle vom Controller werden die absoluten Ar-beitszeiten der Mitarbeiter in das System eingegeben.

Zur Uberprufung, ob es sich bei einem Substantiv um eine Nominalisierung han-delt, kann, wie [Rup 02, S. 208 ff.] beschrieben ist, folgendermaßen vorgegangenwerden:

• ”Passt das Substantiv sinnvoll in die Phrase ’ein(e) andauernde(r) ...’ (im Sinnevon kontinuierlich)”, oder

• ”Beschreibt ein Substantiv etwas, das man nicht anfassen kann?”

Trifft mindestens eine der beiden Fragen auf ein Substantiv zu, so handelt essich um eine Nominalisierung. In diesem Fall treffen fur das Wort ”Eingabe” sogarbeide Falle zu, d. h., dieser Prozess sollte weiter hinterfragt werden. Bei genauererUntersuchung dieses Punkts stellte sich heraus, dass dieses Problem im Rahmendieser Arbeit nicht zufrieden stellend gelost werden kann. Dies ist auch einer derGrunde dafur, dass in jedem Fall eine manuelle Arbeitszeiteingabe fur die internenMitarbeiter existiert.

3.2.2 Checklisten zur Uberprufung

Widerspruchliche Anforderungen:

1. Bei der Befragung des Stakeholders Projektmanagement ergab sich die In-formation, dass bei der Planung eines Projektes festgelegt wird, wann ein Projektgestartet wird. Anschließend wird es in eine Exceltabelle eingetragen, der Controllerwird informiert und redundant dazu wird dieses Projekt in das SAP-System einge-geben.

26

2. Eine Anforderung vom Stakeholder Abteilungsleiter war, dass Projekte auchruckwirkend eingegeben werden sollten, da das Eintragen der Projekte eventuell ver-gessen werden konnte, und die Projektinformationen korrekt sein sollten.

3. Des Weiteren sollen Berichte, die sich auf Daten der Vergangenheit beziehen,nicht verandert werden, wenn sich irgendwelche Daten geandert haben.

Die 1. Anforderung schließt aus, dass das Eintragen eines Projekts vergessenwerden kann, da die Zeiterfassung die vorhandene Exceltabelle des StakeholdersProjektmanager ersetzen soll. Des Weiteren stellt die 1. Anforderung einen Wider-spruch zur dritten dar, da die besagten Berichte beispielsweise auch eine Auflistungaller aktuellen Projekte eines Monats enthalten, die bei einem ruckwirkenden Ein-tragen verfalscht werden wurden.

Die Konsequenz daraus ist, dass Projekte nur mit einem Projektstart angelegtwerden durfen, der nicht in der Vergangenheit liegt.

Unnotige Anforderungen sind beispielsweise Anforderungen, die beschreiben, inwelchem Fall welcher Button wie gefarbt wird, wobei dieser Punkt ebenfalls abhangigvon den Moglichkeiten der verwendeten Implementierungstechnik ist. In ASP. NETist es beispielsweise kein Aufwand, Buttons in unterschiedlichen Farben darzustel-len oder Tabellenspalten fur bestimmte Benutzergruppen auszublenden. In anderenImplementierungstechniken fur Web-Applikationen ist dies nicht so ohne weiteresder Fall. Dabei zeigt sich auch, dass Anforderungen niemals vollig unabhangig vomEntwurf und von der Implementierung sind.

Folgende Aspekte konnen ebenfalls als Checkliste verwendet werden:

• Die Untersuchung der sprachlichen Schwachen aus Kapitel 3.2.1

• Die Struktur des Requirements Documents aus Kapitel 3.3

Da es den Umfang der Arbeit sprengen wurde, wurde dieses Thema nicht weitervertieft.

3.3 Requirements Document

3.3.1 Systemmodelle

Gemaß Kapitel 2.3.3 werden im Folgenden die verwendeten Systemmodeltechnikenbeschrieben.

Als statisches Modell wurde ein Klassendiagramm (siehe Abbilung 8) gewahltund das in Kapitel 6.7.2 noch vorgestellte, Datenbankmodell. Wie bereits in der Ein-leitung (Kapitel 1.3) erwahnt wurde, soll die entwickelte Struktur einen Vergleich

27

Abbildung 8: Systemmodell: Klassendiagramm

der Datenbanktechniken ermoglichen. Aus diesem Grund kann das Klassendiagrammnicht eins-zu-eins verwendet werden, dient aber zur Beschreibung der Entitaten undihrer Beziehungen.

Als dynamisches Modell wurden Statechart Diagramme verwendet. Diese be-schreiben das Benutzerverhalten und die Moglichkeiten der Benutzeroberflache. DieZustande bilden dabei jeweils einen Zustand der Benutzeroberflache ab und die Tran-sitionen beschreiben die Benutzeraktionen. Statechart Diagramme konnen zudemgeschachtelt werde, wodurch die jeweiligen Zustande Schritt fur Schritt verfeinertwerden konnen. Durch die Schachtelung lassen sich Funktionsblocke auf verschiede-nen Detailliertheitsgraden darstellen.

Der Zustand AuthentificatedUser, wie in Abbildung 9 dargestellt, kann nur er-reicht werden, wenn sich der Benutzer zuvor erfolgreich authentifiziert hat (sieheKapitel 5.6). Einschrankungen, welche die Benutzerrechte betreffen, werden nicht inden Statechart Diagrammen, sondern direkt in den Requirements beschrieben (sieheKapitel 3.3.2). Befindet sich der Benutzer in einem bestimmten Unterzustand wiebeispielsweise Project, so hat er immer die Moglichkeit, durch Auswahl eines anderenMenupunktes den Zustand Project zu verlassen (beispielsweise durch Betatigen desButtons Mitarbeiterverwaltung - ButtonEmployeeClick). Die Statechart Diagrammewurden dabei bewusst einfach gehalten, beispielsweise wurden keine parallelen Kom-positionen verwendet, um die Benutzermoglichkeit einfach erkennbar zu lassen und

28

Abbildung 9: Statechart Diagramm fur die Menufuhrung

die Testfallgenerierung nicht zu erschweren. Durch den dargestellten Junction Point(siehe schwarzen Punkt in Abbildung 9) konnen mehrere Transitionen zu einer zu-sammengefasst werden (siehe auch [Lin 01]).

Abbildung 10: Use Case Modell zur Beschreibung der drei Hauptfunktionalitaten

Das in Abbildung 10 dargestellte Use Case Diagramm soll aus einer sehr abstrak-ten Sicht zeigen, welches die generellen Funktionsblocke sind. Die Akteure spiegelndabei nicht die Stakeholder wider, sondern sollen die drei generellen Benutzerrollenbeschreiben. Die Administratorrolle mit den Use Case ”System verwalten”beschreibtdie Funktionalitaten, die notig sind, da keine Anbindung an das vorhandene SAP-System moglich ist. Dieser Use Case enhalt auch die Eingabe der absoluten Arbeits-zeiten und die Projektverwaltung. Die Mitarbeiter ordnen ihre Arbeitszeiten denProjekten, Fachgruppen und Aufgabenkatalogen zu. Die durch die Mitarbeiter undden Administrator gesammelten Informationen konnen dann von einer Controller-rolle in Form von Berichten (Reports) ausgegeben werden (siehe auch [ReqDoc, 2.2Produkt-Funktionen]).

29

3.3.2 Struktur eines Requirements

Wie in Kapitel 2.3.2 beschrieben ist, hat sowohl die rein naturlichsprachliche alsauch die rein formale Beschreibung ihre Nachteile. Um die Anforderungen leichtverstandlich, aber trotzdem vollstandig zu beschreiben, wurden bestimmte Informa-tionen der Anforderungen aus den Formulierungen extrahiert (siehe Abbildung 11auf Seite 32). Die Anforderungsbeschreibung ist in diesem Fall frei von umstandli-chen Formulierungen, welche beispielsweise die Moglichkeiten der Benutzerfuhrung(durch die Statechart Referenz) oder die Benutzerrechte betreffen. Die einzelnenPunkte werden unterschieden in zwingend erforderliche und optionale. Diese Punk-te konnen ebenfalls als Checkliste verwendet werden (siehe Kapitel 3.2.2), um zuuberprufen, ob die Anforderungen vollstandig sind.

3.3.3 Struktur des Requirements Documents nach [IEEE830-1998]

Gemaß Kapitel 2.3 wurde das Requirements Document nach dem [IEEE830-1998]Standard verwendet. Dieser besteht, wie in Abbildung 12 darstellt, aus drei Teilen:

Das erste Kapitel Einleitung gibt einen groben Uberblick uber das Produkt unddas Requirements Document. Im Abschnitt Zielsetzung wird beschrieben, warumdieses Produkt benotigt wird (siehe Kapitel 3.1.1) und fur welche Lesergruppen die-ses Dokument geeignet ist. Definitionen, Akronyme und Abkurzungen helfen dabei,eine gemeinsame ”Sprachbasis” zu definieren. Unterschiedliche Begriffe fur gleicheDinge sollen damit vermieden werden. Der weitere Aufbau des Requirements Docu-ments und die Struktur der einzelnen Anforderungen (siehe Kapitel 3.3.2) werdenim letzten Abschnitt beschrieben.

Das Kapitel Benutzercharakteristika beschreibt die Benutzergruppen, die im Ka-pitel Zielsetzung der Einleitung kurz vorgestellt wurden detaillierter. Eine genauereBeschreibung der Stakeholder soll erklaren, warum die Anforderungen genau so be-schrieben wurden. Generelle Einschrankungen, Annahmen und Abhangigkeiten zudefinieren ist vor allem dann interessant, wenn die Anforderungen des 3. Kapitelsauf diese verweisen. Soll das System geandert werden, weil sich z. B. eine Abhangig-keit geandert hat, so ware sofort erkennbar, welche Anforderungen davon betroffensind. Anforderungen, die vielleicht sinnvoll und nutzlich sind, aber aus irgendwel-chen Grunden nicht realisiert werden konnen, konnen im letzten Abschnitt des 2.Kapitels aufgeschrieben werden, um nicht vergessen zu werden.

Vor allem das dritte Kapitel ist sehr dynamisch gehalten (siehe Kapitel 2.3). Indiesem Fall wurde die in Abbildung 12 dargestellte Form gewahlt:

Der Punkt Schnittstellenbeschreibung ist noch offen und soll die Anbindung andas SAP-System oder die Exceltabelle des Controllers beschreiben. Das in Kapitel3.3.1 dargestellte Klassendiagramm und das Datenmodell befinden sich im Abschnitt

30

”Statische Systemmodelle”. Die eigentlichen Anforderungen werden durch zwei Sich-ten dargestellt (vgl. 2.4.4 und 3.1.5). Wie bereits in Kapitel 2.3.2 erwahnt wurde,ist es schwierig, Anforderungen so zu beschreiben, dass sowohl ein Entwickler alsauch beispielsweise ein Projektmanager diese versteht und eindeutig interpretierenkann. Aus diesem Grund wurden genau diese beiden Sichten dargestellt. Im Ab-schnitt ”Benutzeranforderungen” werden nur die Benutzerfunktionalitaten ohne alleSonder- und Ausnahmefalle beschrieben. Diese Sicht soll einen detaillierten Uber-blick uber alle vorhandenen Funktionalitaten geben, ohne dass zu sehr ins Detailgegangen wird. Fur den Entwickler, der aus diesen Anforderungen eindeutig ablei-ten soll, was entwickelt werden soll, wird diese Sicht nicht ausreichen. Aus diesemGrund werden im Abschnitt ”Benutzeranforderungen mit Systemanforderungen”dieeinzelnen Anforderungen im Detail beschrieben.

3.4 Abschließende Worte zum Requirements Engineering

Wie schon im Kapitel 2.1 beschrieben wurde, wird beim Requirements Engineeringein iteratives Vorgehen vorgeschlagen. Dabei ist es sehr wichtig, diese Reihenfolgeauch diszipliniert durchzufuhren. Anforderungen, die geandert, aber nicht im Requi-rements Document aufgenommen wurden, und anschließend implementiert wurden,verfehlen den Grundgedanken des Requirements Engineerings. Dabei kann es sehrschnell geschehen, dass Anforderungen, Entwurf und Implementierung nicht mehrkonform zueinander sind.

Da in diesem Fall kein CASE-Tools (siehe Kapitel 3.1.5) verfugbar war, war es indieser Arbeit sehr muhselig, die Anforderungen aktuell zu halten. Die Anforderungenwurden in einer Exceltabelle mit der in Kapitel 3.3.2 beschriebenen Struktur verwal-tet. Uber die Filterfunktion konnten nur sehr eingeschrankte Sichten (Viewpoints)auf die Anforderungen vorgenommen werden. Fur die Ausgabe in dem RequirementsDocument wurde eine Serienbrieffunktion verwendet, die diese Anforderungen nachLatex konvertiert hat, da diese Arbeit und das Requirements Document mit Latexerstellt wurden. Folgeanderungen durch Referenzen der Anforderungen untereinan-der, eine Versionsverwaltung und eine etwas bessere Moglichkeit, verschiedene Sich-ten auf die Anforderungen zu erhalten, hatten die Arbeit wahrscheinlich sehr vielweniger muhselig gemacht.

Wie an den Beispielen zu sehen ist, war das Problem bei der Analyse gar nicht sosehr die Abbildung des Problems auf geeignete Modelle, sondern vielmehr die Frage,was abgebildet werden soll.

Eine klare Beschreibung, die angibt, wie detailliert Requirements beschriebenwerden sollen, habe ich nicht gefunden. In [Som Saw 97, eigene Ubersetzung, S. 6]heißt es nur: ”Der Detailliertheitsgrad der Anforderungen hangt im wesentlichen vonder Praxis in ihrem Unternehmen ab.”

31

ID: Jede Anforderung besitzt eine eindeutige Identitat. Durch die verwendetePunkt-Notation werden diese hierarchisch geordnet, d. h., Project.Insert.Validbeschreibt den detaillierteren Fall, wenn das Anlegen eines Projekts (Pro-ject.Insert) aus beschriebenen Grunden nicht moglich ist.

Prioritat: Jede Anforderung besitzt eine der drei folgenden Prioritaten:

• A (zwingend erforderlich),

• B (ware gut, aber muss nicht sein) oder

• C (”nice to have”)

Benutzerrecht (optional): Bedingungen sind meist mit Transitionen verbundenund beschreiben all diejenigen Bedingungen, die sich nicht auf Moglichkeitender Benutzeroberflache oder die Benutzerrechte beziehen.

Anforderung: In diesem Punkt werden die eigentlichen Anforderungen (Requi-rement) beschrieben.

Statechart-Referenz: Jeder Funktionsblock besitzt genau ein Statechart Dia-gramm. Jede Anforderung muss sich auf einen Zustand oder eine Transitionbeziehen, die hier beschrieben wird.

Stakeholder: Jede Anforderung kommt von einem Stakeholder, der als Referenzfur die Anforderung gilt. Dieser kann sich von den Benutzerrechten unterschei-den, beispielsweise wenn Forderungen vom Auftraggeber fur Mitarbeiterfunk-tionalitaten beschrieben werden.

Referenz (optional): Alle zusatzlichen Referenzen (siehe Kapitel x) werden hierbeschrieben. Aus zeitlichen Grunden wurde diese Spalte nicht vollstandig aus-gefullt. Dieser Punkt stellt auch eine Erweiterung des Punktes Stakeholderdar.

Beispiel (optional): Vor allem bei Berechnungen oder beschriebenen Einschran-kungen konnen Beispiele unterstutzend verwendet werden.

Anmerkung (optional): In diesem Punkt werden detaillierte Beschreibungen fureine Anforderung, die keine neue Anforderung darstellt, oder Begrundungenfur bestimmte Anforderungen beschrieben.

Abbildung 11: Aufbau eines Requirements

32

1. Einleitung

(a) Zielsetzung

(b) Produkt- und Anwendungsbereich

(c) Definitionen, Akronyme und Abkurzungen

(d) Referenzen

(e) Uberblick zum restlichen Dokument

2. Generelle Beschreibung

(a) Produkt-Perspektiven

(b) Produktfunktionen

(c) Benutzercharakteristika

(d) Generelle Einschrankungen

(e) Annahmen und Abhangigkeiten

(f) Anforderungen fur Weiterentwicklungen

3. Spezifische Anforderungen

(a) Schnittstellen im Detail

(b) Statische Systemmodelle

(c) Benutzeranforderungen

(d) Benutzeranforderungen mit Systemanforderungen

4. Anhange

5. Index

Abbildung 12: Requirement Dokument nach [IEEE830-1998]

33

4 Konzepte von ASP.NET

4.1 Grundlagen

4.1.1 3-Tier-Architektur

Im Allgemeinen werden Web-Applikationen als 3-Tier-Architektur konzipiert, wie inAbbildung 13 dargestellt ist.

Abbildung 13: 3-Tier-Architektur fur Web-Applikationen

In einer 3-Tier-Architektur sind Client11, Applikation und Datenbank voneinan-der getrennte Einheiten. Der Client kommuniziert nur mit dem Applikationsserver(oft auch Businesslogik genannt), welcher wiederum mit einer Datenbank kommuni-ziert, d. h., der Client und die Datenbank kommunizieren niemals direkt miteinander.Durch Senden einer parametrisierten Webseiten-Anfrage an den Server fordert derClient vom Server eine Webseite an. Diese ist abhangig von der jeweiligen Anfra-ge. Fur jede Benutzeraktion (beispielsweise das Betatigen eines Buttons) wird einesolche Anfrage an den Server gesendet (siehe auch [Sch 02, S. 9 ff.]).

4.1.2 .NET - Framework

Eine verhaltnismaßig neue Entwicklungsform fur Web-Applikationen ist ASP.NET.ASP.NET ist ein Bestandteil des .NET Frameworks, wie in Abbildung 14 dargestellt.

In [MSDN .NET Framework FAQ 01, eigene Ubersetzung] wird das .NET Fra-mework definiert als, ”eine integrierte Windowskomponente, zum Ausfuhren undEntwickeln von Applikationen [..] der nachsten Generation. Das .NET Frameworkist sprachenunabhangig und stellt eine umfangreiche Klassenbibliothek zur Verfu-gung [(Base Class Library)].”

Auf dem (Windows-)Betriebssystem ist eine Common Language Runtime aufge-setzt, die, ahnlich der JAVA Virtual Maschine, ein Programm nicht direkt ausfuhrt,

11Der Client der Web-Applikation ist immer der Web-Browser.

34

Abbildung 14: Das .NET Framework

sondern es erst bei der ersten Verwendung in Maschinencode ubersetzt. Die Pro-grammiersprache, die in der Zeiterfassung verwendet wurde, ist C# (siehe Kapitel4.1.4), obwohl die Festlegung einer Programmiersprache im .NET Framework nichtunbedingt notig ist, da uber die Common Language Specification die verschiedenenKlassen in verschiedenen Programmiersprachen entwickelt und beliebig miteinanderkombiniert werden konnen. Fur die Web-Applikation ist vor allem ASP.NET wichtig.Die Konzepte von ASP.NET werden in Kapitel 4.1.5 genauer beschrieben.

4.1.3 Businessobjekte

In .NET gibt es zwei Moglichkeiten, Gruppen von Klassen zu Komponenten oderBusinessobjekten zusammenzufassen (vgl. dazu auch [Mos 03]).

Assemblies:

Assemblies sind wiederverwendbare Programmpakete, die in einer physikalischenDatei abgelegt sind und von anderen Applikationen verwendet werden konnen. Siesind in der Windowswelt sozusagen eine Weiterentwicklung der Dynamic Linked Li-brarys (DLL). Im Vergleich zu JAVA sind sie eng verwandt mit den JAR-Files.

Namespaces:

Namespaces sind ahnlich zu den Packages in JAVA. Im Gegensatz zu JAVA kanneine Datei aber mehrere Namespaces besitzen oder sich ein Namespace uber mehrereDateien erstrecken.

4.1.4 Die Programmiersprache C#

Parallel zum .NET-Framework wurde von Microsoft eine neue Programmierspra-che mit dem Namen C# (gesprochen: ”See Sharp”) entwickelt. C# besitzt sehr vielAhnlichkeit mit JAVA und C++, aber auch einige neue Konzepte, die im Folgenden

35

erklart und im Entwurf in Kapitel 5 verwendet werden.

PropertiesIm [NetLexikon] wird ein Property (Eigenschaft) als eine Sicht auf ein Attribut

bezeichnet. Properties ersetzen die ”Getter”- und ”Setter”-Methoden und werdenwie Attribute einer Klasse verwendet, wie in Abbildung 15 an einem Beispiel gezeigtwird. Die Konsistenzprufung in dem Property Proration gewahrleistet, dass dasAttribut immer kleiner als 100 ist.

(1) private string m Proration;(2) public string Proration {(3) get{ return this.m Proration; }(4) set {(5) if( value < 100 ) throw new Exception( ”Fehlermeldung” );(6) else this.m Proration = value;(7) }...Proration = 142; // wirf eine Exception

Abbildung 15: Beispiel fur die Verwendung von Properties

IndexerAhnlich zu dem Konzept der Properties sind die Indexer. Diese erlauben es, auf

ein Objekt wie auf ein Array zuzugreifen. Indexer werden durch das Schlusselwortthis definiert. Abbildung 16 zeigt eine Klasse Manager, die einen Indexer enthalt.

(1) public class Manager {(2) PersistentObject this [int id ] {(3) get { /* Gibt das PersistentObject id zuruck */ }(4) set { /* Setzt das PersistentObject id */ }(5) }(6) }...(7) Manager m = new Manager();(8) m[0] = new PersistentObject();(9) Persistentobject o = m[0];

Abbildung 16: Beispielcode fur die Verwendung eines Indexer

EventhandlerEin Event ist eine Nachricht, die von einem Objekt gesendet wird, um das Auf-

treten einer Aktion zu signalisieren. Sie wird von einem Sender ausgelost und voneinem Empfanger empfangen. Der Empfanger muss sich dafur beim Sender anmel-den, was uber ein Delegate passiert. In . NET wird dafur ein eigener Typ mit dem

36

Namen event zur Verfugung gestellt, bei dem ein Empfanger sich durch Ubergebeneiner Methode (Delegation) anmelden kann. Wenn das Event eintritt bzw. gefeu-ert wird, werden die an dem Event angemeldeten Methoden aufgerufen (siehe auch[Mos 03, Kap. 10]).

SichtbarkeitenIn C# gibt es neben public, protected und private noch eine weitere Sichtbarkeit,

die durch das Schlusselwort internal gekennzeichnet ist. Diese druckt aus, dass einMitglied einer Klasse nur in derselben Assembly sichtbar ist. Im Klassendiagrammwird diese Sichtbarkeit durch ein ∼ dargestellt.

4.1.5 ASP.NET Page-Framework

Microsoft definiert das ASP. NET Page Framework ”als ein Programmierframework,das auf einem Webserver lauft und dynamisch Webseiten erzeugt und verwaltet.Diese Webseiten werden Webforms genannt und konnen im Visual Studio entwi-ckelt und implementiert werden. ... Das ASP .NET Page Framework schafft eineAbstraktion der traditionellen Client-Server Kommunikation, die es ermoglicht, eineWeb-Applikation mit den traditionellen objektorientierten und eventbasierten Pro-grammiertechniken zu entwickeln” ([MSDN ASP.NET, eigene Ubersetzung]).

Eine Webform besteht aus zwei Teilen, die im Folgenden erklart werden: visuelleElemente, die das Aussehen der grafischen Benutzeroberflache (siehe Kapitel 4.3)beschreiben, und die dazugehorige Programmlogik (siehe Kapitel 4.2).

4.2 Codebehind-Technologie

Verbunden wird eine Webform mit ihrer Codebehind-Klasse durch eine so genanntePage-Direktive. Die Codebehind-Klasse, wie in Abbildung 17 dargestellt, ist eineKlasse, die von der Page abgeleitet werden muss. Die Klasse Page stellt Schnittstel-len zur Verfugung, um das gewunschte Verhalten der Webform zu implementieren.

Der Einstiegspunkt in eine Codebehind-Klasse ist die Methode OnInit. In C#mussen Methoden, die uberschrieben werden konnen, explizit mit dem Schlusselwortvirtual, und wenn sie uberschrieben werden, explizit mit dem Schlusselwort overridegekennzeichnet werden.

In dem Beispiel von Abbildung 17 werden den Events Load und PreRender je-weils Methoden zugeordnet, die beim Eintreten der entsprechenden Events ausge-fuhrt werden. In Kapitel 4.5 werden der Lebenszyklus und die moglichen Eventseines Page-Objekts noch genauer beschrieben.

37

Abbildung 17: Beschreibung der Codebehind-Technologie

4.3 Webforms

4.3.1 Einleitung

Eine Webform ist eine Webseite (HTML-Seite) mit einem HTML-Formular, die ne-ben HTML-Elementen und einem HTML-Formular so genannte Server Controls ent-halt. Server Controls sind grafische Objekte mit Methoden, Properties und Events.Der in dem HTML-Attribut id angegebene Name definiert den Namen des Pro-perties in der entsprechenden Codebehind-Klasse, d. h., auf der Clientseite werdenHTML-Elemente angezeigt und in der Codebehind-Klasse erscheinen diese als ”echteObjekte”. Durch diesen Mechanismus wird die in Kapitel 4.1.5 beschriebene Abs-traktion realisiert.

Die Server Controls werden unterschieden in HTML Server Controls und WebServer Controls.

4.3.2 HTML Server Controls

HTML Server Controls reprasentieren HTML-Elemente. Die Attribute der HTML-Elemente bilden die Attribute der HTML Server Controls in der Codebehind-Klasse.Wird beispielsweise in der Codebehind-Klasse ein Attribut eines HTML Server Con-trols geandert, so erscheint beim Client das HTML-Element mit dem geandertenAttribut.

38

Abbildung 18: Zusammenhang von HTML und Server Controls

Abbildung 18 soll diese Funktionsweise und den Zusammenhang von HTML-Elementen und Properties erklaren. Der Client schickt an den Server eine HTTP-Anfrage, in der er eine Webseite anfordert. Das ASP .NET Page Framework wandeltdie HTML-Elemente in HTML Server Controls Objekte um. Die Codebehind-Klassebesitzt dann fur jedes HTML Server Control ein Property, welches den gleichen Na-men besitzt wie das Attribut id des HTML-Elements.

Die Properties konnen dabei beliebig geandert werden. Nachdem die Anfrageabgearbeitet wurde, wandelt das ASP .NET Page Framework die Server Controls(mit den geanderten Attributen) in HTML um und schickt das erzeugte HTML-Dokument an den Client zuruck.

Des Weiteren kann ein Server Control Events besitzen. Ein Beispiel ist dasHTMLButton Server Control. Dieser besitzt ein Event ServerClick, was ausgefuhrtwird, wenn der entsprechende Button auf der Clientseite betatigt wurde.

Ein weiteres Konzept kann durch den Zustatz runat=”server” im HTML ServerControl realisiert werden. Dieser Zusatz bedeutet, dass auf dem Server eine Instanzdes entsprechenden Objekts gehalten wird, welche den Zustand des entsprechendenObjekts enthalt. In einem ViewState12 wird zu jedem Objekt, was als runat=”server”definiert wurde, eine Referenz abgelegt, die dieses Objekt auf dem Server identifi-ziert. Damit besteht die Moglichkeit, dass dem Server nur mitgeteilt wird, was aneinem Objekt geandert wurde, ohne das komplette Objekt bzw. alle Attribute zuubertragen.

4.3.3 Web Server Controls

Die zweite Form von Server Controls sind die Web Server Controls. Wahrend dieHTML Server Controls die HTML-Elemente reprasentieren, ist die Vorgehenswei-se bei den Web Server Controls genau entgegengesetzt. Die Web Server Controlsbeschreiben komplexe grafische Objekte und die Umwandlung in HTML kann sich

12Ein ViewState ist eine versteckte Variable, die in einer Webform enthalten ist und zusatzlicheInformationen fur den Server enthalt.

39

uber mehrere HTML-Elemente erstrecken.

Ein spezielles Web Server Control ist der PlaceHolder, der als Container inner-halb einer Webform verwendet wird. Dieser besitzt eine Methode, um ihn in weitereServer Controls zu laden. Dadurch konnen dynamisch Inhalte in einer Webformgesetzt werden. Web Server Controls, die mindestens einen PlaceHolder besitzen,werden im Folgenden auch als Templates bezeichnet.

Neben den vordefinierten Server Controls besteht auch die Moglichkeit, eigeneServer Controls zu entwickeln. Diese werden User Controls genannt. In Kapitel 5.4.5wird ein Beispiel fur die Entwicklung eines User Controls beschrieben.

4.4 Zustandsmanagement

In einer Web-Applikation kommuniziert der Client uber das zustandslose HTTP-Protokoll mit dem Server. Gleiche Serveranfragen von verschiedenen Clients werdennicht unterschieden. Nach der Verarbeitung der Anfrage werden alle Verbindungsda-ten verworfen. Bei einer Web-Applikation ist es aber notig, dass Zustandsinforma-tionen verwaltet werden. ASP.NET bietet dafur verschiedenste Moglichkeiten, dieim Folgenden beschrieben werden.

Versteckte Formularfelder:

Die einfachste Moglichkeit, Zustandsinformationen zu halten, ist es, diese mitjeder Anfrage an den Server in versteckten Formularfeldern mitzuschicken. Die Me-thode RegisterHiddenField in der Klasse Page bietet die Moglichkeit, versteckteFormularfelder zu definieren, die beim Erzeugen der HTML-Seite mit angelegt wer-den. Die mitgeschickten Zustandsinformationen sind allerdings im HTML-Code inKlartext sichtbar, was vor allem bei sensiblen Daten sehr nachteilig ist.

ViewState:

Jede Webform enthalt ein verstecktes HTML-Element mit dem Namen VIEW-STATE. In der Page-Klasse wird dieser Viewstate durch ein Property reprasentiert.Auf dieses Property kann in der Codebehind-Klasse zugegriffen werden. Der Vorteildieser Variante, im Vergleich zu den versteckten Formularfeldern, ist, dass die Da-ten nicht mehr als Klartext sichtbar sind. Allerdings mussen die Zustandsdaten beidieser Variante immer noch bei jeder Serveranfrage mitgesendet werden.

Session:

Eine Session ist der Zeitraum vom ersten Aufruf einer Webseite bis zum Schlie-ßen des Webbrowsers. Allerdings kann eine Session auch vorher vom Server beendet

40

werden (beispielsweise wenn ein Timeout abgelaufen ist) oder uber das Schließendes Webbrowser hinaus gultig sein, wenn die Sessiondaten im Cookie gespeichertwerden. Hierfur bittet die Klasse Page das Property Session an. In diesem Proper-ty konnen Daten, die abhangig von einer Session sind, verwaltet werden, d. h., dieZustandsinformationen werden nicht bei jeder Anfrage mit ubermittelt.

Application:

Informationen konnen auch uber die gesamte Lebenszeit einer Applikation ver-waltet werden. Eine Applikation startet, wenn die erste Anfrage an den Server gesen-det wird, und endet, wenn die Konfigurationsdaten geandert oder der Serverprozessbeendet, wird. Hierfur bietet die Page-Klasse ein Property mit dem Namen Appli-cation an.

4.5 Lebenszyklus eines Page-Objekts

Um zu verstehen, welche Schnittstellen das ASP.NET Page Framework anbietet,wird in diesem Kapitel der Lebenszyklus eines Page Objekts beschrieben, d. h. waspassiert zwischen einer Serveranfrage und dem anschließenden Senden der HTML-Seite (vgl. Kapitel 4.1.1).

Wie bereits erwahnt wurde, ist das zentrale Konzept von ASP.NET die KlassePage. Bei einer Serveranfrage bzw. Anfrage an einer Webform wird eine Instanz derdazugehorigen Codebehind-Klasse erzeugt. Den verschiedenen Events konnen durchUberschreiben der Methode Init (vgl. Kapitel 4.2) eigene Methoden ubergeben wer-den, die im Folgenden kurz beschrieben werden (vgl. [Esp 04]).

In Abbildung 19 ist der Lebenszyklus eines Page-Objekts dargestellt.

Nachdem die OnInit-Methode durch das Event Init aufgerufen wurde, werdendie ubergebenen Variablen ausgewertet. Dies sind zum einen der Viewstate und zumanderen die durch die http-Anfrage ubergebenen Variablen. Der Viewstate enthaltReferenzen auf die Server Controls, die durch runat=”server” gekennzeichnet wur-den. Die Server Controls dieser Referenzen werden geladen. Anschließend werdendie durch den Post-Mechanismus ubertragenen Formulardaten ausgewertet. NachAbschluss dieser Phase besitzen die Objekte auf dem Server den gleichen Zustandwie auf dem Client.

Anschließend wird das Event Load aufgerufen. Dieses Event ist dafur gedacht,benutzerdesfiniertes Initialisieren vorzunehmen. Das Laden der User Controls in dieTemplates ist ein Beispiel dafur. Des Weiteren konnen Attribute initialisiert werden.Diesem Event wird ublicherweise eine Methode Page Load ubergeben.

41

Abbildung 19: Lebenszykus eines Page-Objekts

Die Benutzeraktionen (Betatigen eines Buttons oder das Andern einer Auswahlin einer Dropdownliste, sofern dies definiert wurde) werden in der nachsten Phaseausgewertet. Den Events der Server Controls konnen zuvor Methoden ubergebenworden sein, die in dieser Phase ausgewertet werden. Wurde eine Seite angefragt,weil ein Benutzerevent ausgefuhrt wurde, so spricht man auch von Postback. In derPage-Klasse steht hierfur ein Property zur Verfugung, mit dem gepruft werden kann,ob eine Seite durch einen Postback aufgerufen wurde. In diesem Fall mussen danneventuelle Initialisierungen nicht mehr vorgenommen werden.

Bevor die HTML-Seite zusammengebaut wird, wird das Event PreRender gewor-fen. Dieses Event wird nach den Benutzeraktionen ausgefuhrt und kann beispiels-weise abhangig von diesen bestimmten Ausgaben erzeugen. Die ubliche Methode furdieses Event ist eine Methode mit dem Namen PreRender.

Im letzten Schritt wird der ViewState zusammengesetzt, d. h., die in dem Pro-perty ViewState enthaltenen Daten werden als String kodiert, die HTML-Seite wirdzusammengesetzt und die zuvor angeforderten Ressourcen werden freigegeben.

42

5 Architektur und Entwurf der Webapplikation

5.1 Einleitung

Im objektorientierten Entwurf wird fur das aus der Analyse spezifizierte System einabstraktes Implementierungskonzept erstellt. Der Entwurf sollte die Analyse erwei-tern und unabhangig von der Implementierung sein (siehe auch [Bit Koc 00, S. 47]).

In diesem Fall war dies allerdings in der Form nicht moglich. Die Struktur derZeiterfassung soll neben den Benutzermoglichkeiten einen Vergleich von den in derEinleitung vorgestellten Datenbanktechniken ermoglichen. Dieser Aspekt war beider Analyse nicht relevant, muss aber im Entwurf berucksichtigt werden. Aus die-sem Grund kann auch das in Kapitel 3.3.1 dargestellte Klassendiagramm im Entwurfnicht erweitert werden.

Zu diesem Zweck wurde eine Framework entwickelt, was diesen Vergleich ermog-lichen soll. Die Idee fur diese Struktur stammt von einem Persistenz Framework, dasin der Firma Francotyp Postalia entwickelt wurde. Die Architektur der Zeiterfassungwird in Kapitel 5.2 beschrieben. In Kapitel 5.3 wird detaillierter auf die Strukturdes entwickelten Frameworks eingegangen.

Ein weiterer Punkt fur das geanderte Vorgehen ist der, dass die Zeiterfassungdas ASP .NET Framework verwenden soll. Hierbei konnen nur die vordefiniertenSchnittstellen verwendet werden, was beim Entwurf ebenfalls berucksichtigt werdenmuss. Dieser Aspekt muss vor allem bei dem Entwurf des Web-Interfaces betrachtetwerden. Das Web-Interface bildet die Schnittstelle zwischen Benutzer und Business-logik (siehe Kapitel 5.4).

Das .NET Framework bietet zwar ein Konzept fur das Zustandsmanagement(vgl. Kapitel 4.4) an, aber stellt keine Technik zur Verfugung, um die Navigationdurch die Webseiten zu steuern. Der Entwurf fur die angewandte Technik des Zu-standsmanagements und die Navigation werden in Kapitel 5.5 beschrieben.

Ein weiteres Problem, was gelost werden muss, ist die Authentifizierung der Be-nutzer und die Definition der Zugriffsmoglichkeiten. In Kapitel 3.2 wurde beschrie-ben, welche Benutzerrollen existieren und welche Moglichkeiten diese haben. Hierfurwird der integrierte Windows Authentifizierungsmechanismus des .NET Frameworksverwendet. Dieser wird in Kapitel 5.6 dargestellt.

Abgeschlossen wird das Kapitel Entwurf mit einem Uberblick uber das gesamteSystem (siehe Kapitel 5.7). Dort werden die vorgestellten Entwurfe zusammenge-fuhrt. Außerdem werden in diesem Kapitel einige weitere Probleme, wie beispiels-weise die Nebenlaufigkeit, kurz angesprochen.

43

5.2 Architektur

Die Zeiterfassung besteht, wie in Abbildung 20 dargestellt, aus funf Komponenten.Jede Komponente ist gleichzeitig ein eigenes Assembly und besitzt einen eigenenNamespace (vgl. Kapitel 4.1.3).

Abbildung 20: Struktur der Komponenten

Die Komponente ProjectManagement bildet die Schnittstelle zwischen Benutzerund Businesslogik. Nach dem Model View Controller Design Pattern nimmt dieseKomponente die Rollen Controller und View ein und realisiert das Web-Interface.Im Kapitel 5.4 wird die Struktur detaillierter beschrieben. Die Businesslogik bestehtaus den folgenden zwei Komponenten:

1. Die Komponente ProjectManagement.Core ist ein Framework, welches persis-tente Objekttypen und ihre Managerklassen als abstrakte Klassen definiert(siehe Abbildung 20). Managerklassen sind Klassen, die persistente Objek-te eines bestimmten Typs verwalten. Fur jede Entitat existiert ein Typ ei-nes persistenten Objekts und ein dazugehoriger Manager. Diese beiden stehenmiteinander in Beziehung. Der detaillierte Aufbau dieses Frameworks wird inKapitel 5.3 beschrieben.

2. Die konkrete Implementierung mit der jeweiligen Datenbanktechnik wird in derspezifischen Komponente (siehe Abbildung 21) realisiert. Fur jede Manager-klasse und jedes persistente Objekt muss eine spezifische (abgeleitete) Klassedefiniert werden, welche die definierten abstrakten Methoden implementiert.

44

Komponente: ProjectManagement. Datenbanktechnik RealisierungCore.Relational relational s. Kapitel 6

Core.ObjectRelational objektrelational Theorie in Kapitel 7Core.ObjectOriented objektorientiert Idee

Abbildung 21: Ubersicht der spefizischen Komponenten

5.3 Persistenz-Framework

5.3.1 Einleitung

Das entwickelte Framework wird als Persistenz Framework bezeichnet, da es persis-tente Objekte verwaltet. In dem ”echten” Persistenz-Framework (siehe Kapitel 5.1),was die Motivation fur diese Struktur war, werden die entsprechenden Datenbank-operationen automatisiert, d. h., uber Reflexion werden die Attribute der Objekteausgelesen und uber Umwandlungsroutinen in Datenbankoperationen umgewandelt.Da das ”echte” Persistenz-Framework ziemlich komplex in seiner Struktur und An-wendung ist, wurde, wie bereits erwahnt, nur die Idee ubernommen.

Ziel der Zeiterfassung ist die Verwaltung von persistenten Objekten verschiedens-ter Typen, wie beispielsweise Projekte, Mitarbeiter oder Fachgruppen. Die benotig-ten Operationen lassen sich dabei in zwei Arten unterscheiden:

1. Operationen, die direkt an einem persistenten Objekte ausgefuhrt werden, umbeispielsweise den Zustand eines Objekts zu andern (siehe PersistentObject inAbbildung 22), und

2. Operationen, die eine bestimmte Menge von Objekten eines bestimmten Typszuruckliefern oder auf einer Menge von Objekten eines bestimmten Typs aus-fuhren werden. Ein Beispiel ist eine Anfrage nach allen Projekten, die keineFachgruppen besitzen. Diese Operationen werden in den bereits erwahntenManagerklassen realisiert (siehe PersistentManager in Abbildung 22).

Die Klassen ProjectManagerImpl, ControllerImpl und ProjectImpl in Abbildung22 zeigen ein Beispiel fur Klassen, die in einer der drei spezifischen Komponenten,wie beispielsweise ProjectManagement.Core.Relational, realisiert werden.

Anhand des Beispiels Project und ProjectManager wird im Folgenden die ab-strakte Managerklasse (PersistentManager, siehe Kapitel 5.3.3) mit ihren spezifi-schen Managerklassen beschrieben. Mit spezifischen Managerklassen sind in diesemFall Klassen gemeint, die in der Komponente ProjectManagement.Core enthaltenund von PersistentManager abgeleitet sind, wie in Abbildung 22 die Klasse Pro-jectManager. Diese Klassen sind abstrakt und mussen in den konkreten Managernimplementiert werden. Konkrete Manager sind Klassen, die von den spezifischenManagerklassen abgeleitet sind und in der konkreten Komponente (siehe Abbildung

45

Abbildung 22: Struktur des Persistenz Frameworks am Beispiel Projekt

21) die jeweiligen Funktionalitaten implementieren.

Die Formulierung spezifisch und konkret wird auch fur persistente Objekte (Per-sistentObject, siehe Kapitel 5.3.3) und die Schnittstelle (Controller, siehe Kapitel5.3.4) zur Komponente ProjectManagement verwendet.

Abgeschlossen wird das Kapitel in 5.3.5 mit einem Uberblick der vorhandenenpersistenten Objekte der Zeiterfassung.

5.3.2 Persistenz Manager

Erzeugt werden persistente Objekte durch ein Factory Pattern, welches in der inAbbildung 22 dargestellten Struktur enthalten ist. In Abbildung 23 sind die Rol-len des Factory Patterns und die zugehorigen Klassen des entwickelten Frameworksdargestellt.

Die Methode CreateObject im PersistentManager hat die Rolle der MethodeFactoryMethode im Factory Pattern. In der konkreten Implementierung der Ma-nagerklasse erzeugt diese Methode eine Instanz des konkreten PersistentObjects.Das Erzeugen eines solchen Objekts darf nur uber diese Methode erfolgen. Dadurch”kennt” jeder Manager den Typ seines persistenten Objekts (siehe Abhangigkeit per-sistentObject in Abbildung 22).

46

Klassen im Factory Pattern Klassen im Persistenz-FrameworkCreator PersistentManager

ConcreteCreator spezifische Implementierung der ManagerklasseProduct PersistentObject

ConcreteProduct spezifische Implementierung des PersistentObjects

Abbildung 23: Rollen des Factory Patterns im Persistenz-Framework

Der Indexer (vgl. Kapitel 4.1.4) im PersistentManager ermoglicht es, einen spe-zifischen PersistentManager wie ein Array zu verwenden. Jedes konkrete persistenteObjekt besitzt eine Identitat in Form einer Zahl. Im Indexer kann anhand dieserZahl ein konkretes Objekt ermittelt werden. Existiert kein Objekt zu der uberge-benen Zahl, so wird ein Null Pointer zuruckgeliefert. Der Indexer ist abstrakt undmuss in der konkreten Komponente bzw. im konkreten Manager realisiert werden.Der Indexer erlaubt nur lesende Zugriffe, da das Einfugen, Andern und Loschen vonpersistenten Objekten an den persistenten Objekten selber durchgefuhrt wird.

Wenn ein Objekt mit der Identitat 42 existiert, dann wurde der Aufruf Control-ler.ProjectManager[42] dieses Objekt zuruckliefern.

Die Methoden Insert, Update und Delete werden im PersistentManager definiertund mussen in der konkreten Implementierung der Managerklasse realisiert werden.Der Zugriff auf diese Methode erfolgt aber uber die persistenten Objekte. In Kapitel5.3.3 wird der Ablauf genauer beschrieben.

Durch die Methode LoadArrayList wird eine Array mit allen Objekten des jewei-ligen Typs zuruckgeliefert. In den spezifischen Managerklassen konnen weitere abs-trakte Methoden definiert werden, die beispielsweise die Ergebnismenge einschran-ken oder andere Funktionalitaten auf der Menge der persistenten Objekte definieren.

Die Methode GetNewProjectNumber (siehe Abbildung 22) ist ein Beispiel fureine weitere Methode. Abhangig vom Projekttyp wird durch diese eine neue vorge-schlagene Projektnummer ermittelt (vgl. Kapitel 3.2.1 das Beispiel Tilgung).

5.3.3 Persistente Objekte

Wie bereits in Kapitel 5.3.2 erwahnt wurde, ist das Einfugen, Andern und Loscheneine Eigenschaft des persistenten Objekts. Diese Methoden leiten die Anfragen anihren jeweiligen Manager (siehe Insert, Update und Delete in Abbildung 22 auf Seite46 in der Klasse PersistentObject).

In Abbildung 24 ist der Ablauf fur das Einfugen eines persistenten Objekts dar-

47

Abbildung 24: Einfugen eines persistenten Objektes

gestellt. Die Methode CreateObject erzeugt lediglich eine neue Instanz des jeweiligenObjekts mit einer Verbindung zu seinem Manager. Persistent im eigentlichen Sinne,d. h. dass diese Daten beispielsweise auch in der Datenbank abgelegt werden, ist die-ses Objekt in diesem Zustand noch nicht. Erst durch Aufrufen der Methode Insertwerden diese Objekte in der entsprechenden Datenbank hinzugefugt. Diese Methodeliefert ein Boolean zuruck. Im Falle eines Fehlers wird false zuruckgeliefert. Durchdas Property CurrentError wird in diesem Fall die Fehlermeldung ermittelt.

Wie bereits erwahnt wurde, besitzt jedes persistente Objekt eine Identitat inForm einer Zahl. In Kapitel 6.2.2 wird noch auf die Schwierigkeiten bei diesem Vor-gehen eingegangen. Daruber hinaus besitzt jedes persistente Objekt einen Namen(siehe Property Name in Abbildung 22). Die Realisierung dieses Namens kann inden jeweiligen konkreten persistenten Objekten unterschiedlich aussehen. Bei einemMitarbeiter ist dieser beispielsweise eine Kombination aus Vor- und Nachname, wah-rend dieser fur ein Projekt der Name des Projektes ist.

Die Informationen, die in einem spezifischen persistenten Objekt gespeichert wer-den, lassen sich in zwei Arten unterscheiden:

Zum einen sind dies einfach Daten, die in Form von Properties definiert werden.Beispiele hierfur im Projekt sind der Projektstart (statedDate) oder die Bemerkungzum Projektabschluss (finishComment).

Die zweite Art von Informationen sind Abhangigkeiten zu anderen persistentenObjekten, wie beispielsweise ein Projektleiter (projectLeader) in einem Projekt, derein Mitarbeiter (Employee) ist. Ein Uberblick aller persistenten Objekte und ihrerAbhangigkeiten zueinander wird in Kapitel 5.3.5 dargestellt.

In den spezifischen persistenten Objekten konnen weitere Methoden definiertwerden. Wie in Abbildung 22 auf Seite 46 zu sehen ist, besitzt die Klasse Project

48

eine Methode Close, welche ein Projekt mit einem Datum und einer Bemerkung zumAbschluss beendet. Ab dem definierten Datum ist das Projekt in der Projektlistenicht mehr sichtbar und kann nur noch uber die Berichte angezeigt werden.

Die Funktionalitaten fur die prozentuale Zeitverteilung der Mitarbeiter auf dieProjekte wurden als Methoden des Projektes definiert. Ahnlich zu dem Einfugen,Andern und Loschen eines Objekts werden diese Methoden auf dem jeweiligen Ob-jekt aufgerufen und in dem entsprechenden Manager implementiert.

5.3.4 Die Klasse Controller

Bisher wurden nur die Managerklassen und ihre persistenten Objekte beschrieben.In diesem Abschnitt geht es darum, diese zusammenzufuhren und eine Moglichkeitzur Initialisierung des Frameworks zu geben. Die dafur verantwortliche Klassen sinddie Klassen Controller und ControllerImpl (siehe Abbildung 22 auf Seite 46).

Abbildung 25: Die Klasse Controller mit zwei Beispielmanagern

Die Klasse Controller besitzt zu jeder abstrakten Managerklasse einen Property(siehe Abbildung 25). Die Komponente ProjectManagement (siehe Abbildung 22)kann uber den Controller auf diese Properties der jeweiligen Manager zugreifen.Der Konstruktor der Klasse Controller ruft eine abstrakte Methode Init auf. Umdas Framework zu initialisieren muss von der Klasse Controller eine abgeleiteteKlasse definiert werden (ControllerImpl), welche die Methode Init implementiert. Indieser Methode werden Instanzen der konkreten Managerklassen erzeugt und an die

49

Properties bzw. an die dahinter liegenden Attribute gebunden. Durch eine Instanzdieser abgeleiteten Klasse stehen dem Anwender - in diesem Fall der KomponenteProjectManagement - alle Manager zur Verfugung.

5.3.5 Zusammenfassung und Ubersicht uber alle persistenten Objekte

Abhangig von der jeweiligen Datenbanktechnik wird eine Komponente erstellt, diedas entwickelte Framework verwendet. Dieses Framework definiert fur jede Entitatein Paar aus (persistenten) Managern und persistenten Objekten. In diesen Klassenwerden abstrakte Methoden definiert, die jeweils in die konkreten Klassen implemen-tiert werden. Die Klasse Controller besitzt fur jeden Manager einen Property, aufden die Komponente ProjectManagement (also das Web-Interface) zugreifen kann.Initialisiert wird das Framework durch eine konkrete Controllerklasse, welche kon-krete Instanzen der Managerklassen an die Properties binden.

Einfugen, Andern und Loschen von persistenten Objekten geschieht uber Me-thoden an den Objekten selber, wahrend Operationen, die sich auf Mengen vonpersistenten Objekten beziehen, in den Managern aufgerufen werden.

Die beiden in Abbildung 25 dargestellten Managerklassen haben noch eine wei-tere Bedeutung. Die Arbeitszeiten der Mitarbeiter und die prozentualen Verteilun-gen dieser auf Projekte, Fachgruppen und Aufgabenkataloge sind abhangig von derKalenderwoche. Beim Starten einer Session (siehe Kapitel 4.4 auf Seite 40) mussendie Kalenderwocheneintrage in der jeweiligen Datenbank aktualisiert (UpdateWeeks)werden. Dieses Thema wird in Kapitel 5.5.2 noch beschrieben. Die Klasse Employeebesitzt außerdem eine Methode SelectEmployeeByAccount, die abhangig von einemubergebenen Account einen Mitarbeiter zuruckliefert. Die Problematik mit der Au-thentifizierung der Mitarbeiter wird in Kapitel 5.6 auf Seite 60 noch beschrieben.

In Abbildung 26 ist die Struktur der persistenten Objekte mit ihren Abhangig-keiten dargestellt.

Wie an dieser Abbildung zu sehen ist, konnen erst die konkreten persistenten Ob-jekte auf die jeweils abhangigen persistenten Objekte zugreifen, d. h., diese mussen injeder konkreten Komponente implementiert werden. Ein weiteres Problem stellt diefehlende Vererbung dar. Dadurch, dass jedes persistente Objekt direkt oder indirektvon PersistentObject abgeleitet werden muss, besteht keine Moglichkeit, Vererbungin den persistenten Objekten in der konkreten Komponente zu verwenden.

50

Abbildung 26: Klassendiagramm der persistenten Objekte

5.4 Entwurf des Web-Interfaces

5.4.1 Einleitung

Im Folgenden wird das Web-Interface beschrieben. In der Komponentenstruktur ausAbbildung 20 in Kapitel 5.2 ist dies die Komponente ProjectManagement. Die Zeit-erfassung besteht aus einer einzigen Webform und einer dazugehorigen CodeBehindKlasse, die in Kapitel 5.4.2 beschrieben wird. Eine Web-Applikation besitzt einigeBesonderheiten im Vergleich zu einer nicht Web-Applikation, die beim Design be-rucksichtigt werden mussen. Diese werden in Kapitel 5.4.3 aufgezeigt.

Wie bereits in Kapitel 5.2 beschrieben wurde, werden in der Zeiterfassung per-sistente Objekte verwaltet. Diese mussen erzeugt, geandert, geloscht und angezeigtwerden. Dafur wird meist ein Datagrid verwendet. In Kapitel 5.4.4 wird an einemBeispiel die Verwendung eines Datagrids beschrieben.

Ein Beispiel fur die Entwicklung eines User Controls, was in der Zeiterfassungbenotigt wird, wird in Kapitel 5.4.5 beschrieben.

5.4.2 Struktur der GUI

Die Benutzeroberflache besteht, wie in Abbildung 27 dargestellt ist, aus drei Place-Holdern:

51

Abbildung 27: Seitenaufbau der Default-Webform

PhHead In den PlaceHolder PhHead wird eine konstante UserControl eingefugt,die ein Firmenlogo und ein Logo der Applikation enthalt.

PhNavigation In den PlaceHolder PhNavigation wird das UserControl Naviga-tor/Main hineingeladen, das abhangig von den Benutzerrechten des aktuellenBenutzers alle ihm verfugbaren Menupunkte anzeigt. Auf die Benutzerrechtewird in Kapitel 5.6 genauer eingegangen.

PhContent Der interessante Teil ist der PlaceHolder PhContent, der abhangig vomBenutzerzustand eine entsprechende UserControl enthalt. Diese kann weiterePlaceHolder enthalten, die wiederum UserControls besitzen.

Eine sprachliche Beschreibung, in welchem Zustand sich der Benutzer in der Zeit-erfassung zum aktuellen Zeitpunkt befindet, wird in LHead dargestellt. Die Steue-rung der Benutzeroberflachen wird in Kapitel 5.5.1 beschrieben. Fehlermeldungenund Benutzerhinweise werden in dem Label LInfo dargestellt.

Abbildung 28 zeigt die entsprechende Klassenstruktur zu der grafischen Benut-zeroberflache aus Abbildung 27.

Die Webform Default wird dabei in zwei Klassen modelliert, welche die Stereo-typen (siehe auch [UML]) ClientPage und ServerPage besitzen. Diese beiden Klassenzeigen den serverseitigen (ServerPage) und den clientseitigen (ClientPage) Aspektdieser Webform (vgl. [Con 99]).

Der serverseitige Aspekt besitzt beispielsweise einen direkten Zugriff auf die Busi-nesslogik und damit auch die Datenbank, wahrend die clientseitige Webform diesenur uber die serverseitige Webform erreichen kann. Beim Ausfuhren von Funktiona-litaten muss außerdem unterschieden werden, ob diese auf dem Client (beispielsweisedurch Javascript) oder auf dem Server ausgefuhrt wird.

52

Abbildung 28: Die Webform Default und die Codebehind-Klasse PageFrontdoor

Das HTML-Formular in der Webform wird durch eine Aggregationsbeziehungmodelliert, d. h., die Webform aus clientseitiger Sicht enthalt ein Formular, waswiederum Attribute (die HTML- bzw. Webform-Elemente) besitzt. Die Verbindungzwischen der serverseitigen und der clientseitigen Webform wird durch eine Asso-ziation mit dem Stereotypen Build modelliert. Diese modelliert das Erzeugen einerclientseitigen Webform bzw. Webseite.

5.4.3 Problem bei Web-Applikationen

Eine Eigenschaft, die eine Web-Applikation im Vergleich zu anderen Applikationenbesitzt, ist die, dass der Client ein Web-Browser ist. Wahrend in einer Nicht-Web-Applikation die Moglichkeiten des Benutzers ziemlich genau eingegrenzt werden,mussen bei einer Web-Applikation die Moglichkeiten des Browsers mit berucksich-tigt werden. In Abbildung 29 sind einige Beispiele hierfur darstellt.

Aus diesem Grund wurde eine Losung mit nur einer Frame entwickelt und dieApplikation besitzt lediglich einen Einstiegspunkt. Den ”Zuruck”-Button vollstandigabzufangen ist nicht moglich. In vielen Fallen fuhrt dieser aber in ASP.NET zueinem Fehler, auf den entsprechend reagiert werden kann (siehe Kapitel 5.5.1). DieBenutzermoglichkeiten werden auf Buttons und Javascript-Events beschrankt, damitbesteht (fast) keine Moglichkeit, mehrere unkontrollierte Instanzen des Browsers zuerzeugen. Fur jede neue Instanz wird eine eigene Session erzeugt, damit sind zweiInstanzen auch zwei unabhangige Benutzer in der Web-Applikation.

53

• Die Webseiten konnen direkt aufgerufen werden, damit sind beliebige Ein-stiegspunkte in die Applikation moglich.

• Durch den ”Zuruck”-Button besteht immer die Moglichkeit, auf vorherige Sei-ten zuzugreifen. Bei einer Nicht-Web-Applikation ist dies nur moglich, wenndiese Funktionalitat explizit implementiert wurde. Wenn der Browser dieseSeite dann auch noch aus dem Cache holt, besteht ein weiteres Problem. EineSeite, die vielleicht durch einen Lock gesperrt und wieder freigegeben wurde,ist fur den Client sichtbar, ohne dass der Lock erneut gesetzt wurde.

• Durch Erzeugen einer neuen Browser-Instanz konnen mehrere Instanzen derApplikation parallel laufen. Der Server kann nicht unterscheiden, wann eineweitere Instanz gebildet und von welcher eine Anfrage gestellt wurde.

• Bei der Verwendung von Frames werden mehrere unabhangige Instanzen desBrowsers erzeugt, was zu weiteren Problemen fuhren kann. Die Zustande derFrames mussen u. U. zueinander bestimmte Bedingungen erfullen, die nurschwer einzuhalten sind. Ein weiteres Problem ist, dass nur ein einziges Frameabsturzen kann und somit die Applikation unvorhersehbare Zustande erreichenkann.

Abbildung 29: Eigenschaften einer Web-Applikation

5.4.4 Verwendung eines Datagrids

Ein Beispiel fur ein ServerControl ist das Datagrid. Mit dem Datagrid konnen, wiein Abbildung 30 dargestellt ist, Datenmengen in Tabellenform angezeigt werden.Aus der Sicht des Servers ist ein Datagrid ein Objekt. Dieses besitzt verschiedeneProperties, Methoden und Events. Die Spalten konnen dabei mithilfe von Flags ein-und ausgeblendet werden.

Abbildung 30: Beispielanwendung fur ein Datagrid

54

Die Spalten konnen in einem Datagrid mit verschiedenen Spaltentypen definiertwerden, die im Folgenden, an dem Beispiel von Abbildung 30, beschrieben werden.

Wie bereits in Kapitel 5.3.3 beschrieben wurde, besitzt jedes persistente Objekteine Identitat, die in der ersten Spalte des Datagrids gesetzt und fur die Ansichtausgeblendet wird. Uber diese Spalte konnen die Objekte bzw. Zeilen identifiziertwerden. Die einzelnen Zeilen des Datagrids besitzen zwar eine eigene Nummerierung,da diese aber automatisch vergeben wird und nicht geandert werden kann, mussteauf eine versteckte Spalte zuruckgegriffen werden. Diese Spalten (BoundColumn)werden auch fur die Darstellung der ubrigen Daten (in diesem Fall nur Status) ver-wendet.

Eine weitere Spaltenart ist die Buttonspalte (ButtonColumn). Das Datagrid bie-tet fur solche Spalten ein Event an. Uber Delegation kann diesem Event eine Methodeubergeben werden. Beim Werfen dieses Events (also beim Betatigen des Buttons)kann durch die mitgegebene Methode entsprechend reagiert werden. In diesem Fallwird eine neue Benutzeroberflache fur die Arbeitszeitverteilung auf Projekte desausgewahlten Mitarbeiters angezeigt.

Die Eingabefelder (Arbeitszeit) stellten im Datagrid eine Schwierigkeit dar. DasDatagrid stellt dafur keine eigene Spaltenart zur Verfugung. In diesem Fall wurdeeine Template-Spalte (TemplateColumns) definiert, in der das entsprechende Einga-befeld einfugt wurde. Damit ist es Bestandteil einer Zeile (Item) und kann uber dieMethode FindControl des Items ermittelt werden.

Aus der Sicht des Clients ist ein Datagrid eine HTML-Tabelle, welche Daten,Eingabefelder und Buttons enthalt. Die Zusammengehorigkeit dieser Daten existiertim HTML nicht. Wird beispielsweise ein Button betatigt, so wird eine Anfrage anden Server gesendet und die HTML-Elemente werden wieder zu einem Datagrid-Objekt ”zusammengesetzt”.

5.4.5 Entwurf eines User Controls

ASP.NET stellt zwar ein Kalender Server Control zur Verfugung, mit dem ein Datumausgewahlt bzw. angezeigt werden kann, bietet aber keine Moglichkeit, ein Datums-feld in einfacher und weniger Platz raubenden Form darzustellen, wie in Abbildung31 zu sehen ist.

Abbildung 31: Beispiel fur ein User Control

Abbildung 32 zeigt die dazugehorige Klasse, die von der Klasse UserControl ab-geleitet werden muss und die OnInit-Methode uberschreibt. In der OnInit-Methode

55

wird dem Load - bzw. PreRender -Event uber Delegation eine entsprechende Metho-de ubergeben.

Abbildung 32: Klasse DateControl

Das voreingestellte bzw. angezeigte Datum wird dabei in Attributen gespeichertund kann uber die entsprechenden Properties gelesen werden. Das Andern des vor-eingestellten Datums geschieht durch die uberladene Methode SetDefaultDate. EinProblem stellt hierbei der angezeigte Jahreszahlenraum dar. Ein Geburtsdatum be-sitzt beispielsweise einen anderen Jahreszahlenraum wie das Jahr eines Projekt-starts. Die Methode SetYearLimit setzt diesen Jahreszahlenraum.

Abbildung 33: Sequenz Diagramm zum DateControl am Beispiel Mitarbeitereinga-bemaske

In Abbildung 33 ist eine beispielhafte Anwendung fur ein UserControl darge-stellt. Fur jeden angelegten Mitarbeiter wird ein Datum der Aktivierung festgelegt.

56

Da ein Objekt vom Typ DateControl auch als Kopie auf dem Server gehalten wird,muss das voreingestellte Datum nicht bei jeder Ausgabe neu geladen werden, d. h.,eine wiederholte Anfrage (IsPostBack) desselben UserControls muss das Datum desMitarbeiters nicht erneut ermitteln.

Wird die Methode SetYearLimit nicht aufgerufen, so wird ein voreingestellterJahreszahlenbereich von [aktuelles Jahr -5; aktuelles Jahr +5] definiert, bzw. wennein voreingestelltes Datum mit einem Jahr gesetzt wird, wird der Jahreszahlenbe-reich entsprechend erweitert.

5.5 Zustandsmanagement

5.5.1 PageNavigator

Wie in Kapitel 4.4 beschrieben wurde, stellt das ASP.NET Page Framework ver-schiedenste Mechanismen zur Verfugung, um Zustandsinformationen zu verwalten.Jeder Benutzer, der die Web-Applikation startet, d. h. die Web-Applikation im Web-Browser aufruft, erhalt vom ASP.NET Page Framework eine eindeutige Session zu-gewiesen. Damit hat die Web-Applikation die Moglichkeit, die Anfragen der ver-schiedenen Benutzer zu unterscheiden. Wie in Abbildung 28 auf Seite 53 zu sehenwar, stellt die Klasse Page eine Property mit dem Namen Session zur Verfugung.Zu jeder Session wird ein Session Objekt erzeugt, an das uber einen Indexer ver-schiedene Werte gebunden werden konnen.

Die verschiedenen Zustande der Benutzer in der Web-Applikation mussen inirgendeiner Form unterschieden werden. Wie bereits erwahnt wurde, stellt ASP.NETdafur keine Technik zur Verfugung.

Die Klasse PageNavigator, wie in Abbildung 34 dargestellt ist, ist fur die Steue-rung der Benutzerzustande zustandig. Eine Instanz der Klasse PageNavigator, odereiner spezifischen Form davon, wird an das Session Objekt gebunden bzw. wirddiesem zugewiesen. Abhangig davon, in welchem Funktionsblock sich der Benutzeraktuell befindet, wird jeweilig eine der in Abbildung 34 dargestellten spezifischenPageNavigator Objekte erzeugt.

Jeder Funktionsblock verwaltet in irgendeiner Form persistente Objekte, die eineIdentitat besitzen. Das Property ID in der Klasse PageNavigator hat dabei folgendeBedeutung:

ID = -1 Es wurde kein persistentes Objekt ausgewahlt, d. h., die Liste oder Tabelleder persistenten Objekte wird angezeigt.

ID = 0 Der Benutzer befindet sich in einem Zustand, in dem er eine Eingabemaskesieht, um ein neues Objekt dieses Typs anzulegen.

57

Abbildung 34: Beispielklasse des PageNavigators zur Steuerung der Benutzerober-flache

ID > 0 Der Benutzer hat ein bestimmtes Objekt mit der Identitat ID ausgewahlt,um etwas damit zu tun. Im einfachsten Fall mochte er es bearbeiten und siehteine Eingabemaske mit den anderbaren Daten.

Abbildung 35: Abhangig vom PageNavigator werden die jeweiligen Templates gela-den

Wie in Abbildung 35 an dem Beispiel Administration zu sehen ist, wird abhangigvon dem Property ID eines der beiden Templates in das Haupt Template (PhAd-minContent) der Administration geladen. Der Zustand ID > 0 ist in diesem Fallnicht moglich, da diese Entitaten nicht geandert werden durfen.

Eine weitere Gemeinsamkeit aller Funktionsblocke ist die, dass jeder Funktions-block ein Haupt Template besitzt. Der Name dieses Templates wird durch das Pro-perty Content ausgelesen und im Konstruktor des jeweiligen PageNavigators gesetzt.

58

Abhangig von den jeweiligen Funktionsblocken und Zustanden darin werden wei-tere Properties definiert, welche den Aufbau der Oberflache beschreiben. Ein Beispieldafur ist das Property AdminKind in AdminNavigator. AdminNavigator beschreibtden Aufbau der Administrationsoberflache. Dort konnen Kostenstellen, Projektty-pen, Projektgruppen und Aufgabenkataloge verwaltet werden. Das Property Admin-Kind beschreibt, in welchem dieser vier Zustande sich der Benutzer aktuell befindet,oder ist NULL, wenn die Begrußungsseite der Administration angezeigt wird.

Abbildung 36: Beispiel fur Zustandsanderung mit PageNavigator

Das Beispiel aus Abbildung 36 soll diesen Mechanismus erklaren (vgl. dazu auchAbbildung 34):

Der Benutzer betatigt den Navigationsbutton ”Administration” (Event Butto-nAdminClick in Abbildung 36) und gelangt in den Zustand ShowAdminMenu. Indiesem Zustand steht dem Benutzer ein Untermenu mit den oben genannten Admi-nistrationspunkten zur Verfugung (vgl. in Abbildung 34 mit Enumeration Admin-Kind).

Betatigt der Benutzer den Untermenupunkt Kostenstelle (Event ButtonCost-CenterClick in Abbildung 36), so wird AdminKind auf COSTCENTER gesetzt. Indiesem Zustand sieht der Benutzer einen Button mit der Aufschrift ”Eine neue Kos-tenstelle anlegen”, welcher beim Betatigen das Event ButtonNewCostCenterClickwirft und ID auf 0 setzt.

Da mit jeder Serveranfrage auch die Session Informationen mitgeschickt wer-den, ”kennt” die Web-Applikation ebenfalls das PageNavigator -Objekt und kann,abhangig vom Zustand des PageNavigator -Objekts, die entsprechenden UserCon-trols ”zusammensetzen”.

59

5.5.2 Start einer Session

Eine weitere Besonderheit bei einer Web-Applikation ist die Tatsache, dass diese Ap-plikation nur lauft, wenn entsprechende Anfragen an den Server gesendet werden.Eine Web-Applikation ist demnach keine Applikation, die als dauerhafter Prozesslauft und somit z. B. nach definierten Zeitraumen bestimmte Aktualisierung vor-nehmen kann.

Abbildung 37: Sequenz Diagramm fur das Starten einer Session

Ein Problem stellen dabei die Kalenderwochen in der Datenbank dar. Die Ver-teilung der Arbeitszeit auf die Projekte wird wochenweise durchgefuhrt. Fur jedeabgelaufenen Woche muss in der Datenbank eine neue Woche angelegt werden. Esbesteht zwar die Moglichkeit, diese erst zu aktualisieren, wenn sie entsprechend beno-tigt wird, da dies aber an verschiedensten Stelle notig ist, wurde die Aktualisierung,wie in Abbildung 37 zu sehen ist, beim Starten einer Session durchgefuhrt (in derKlasse Global wird das Event Session Start geworfen).

Die Authentifizierung des Benutzers bzw. Mitarbeiters (SelectEmployeeByAc-count) wird im folgenden Kapitel beschrieben.

5.6 Benutzerrechte

In diesem Kapitel geht es darum, die Mitarbeiter bzw. die Benutzer in der Zeiterfas-sung zu authentifizieren. Authentifizierung ist die Uberprufung der Identitat einesBenutzers.

Die integrierte Windows-Authentifizierung (vgl. [GotDotNet]) von ASP.NET bie-tet die Moglichkeit, auf die Daten der NT-Konten der Benutzer zuzugreifen. Da sichjeder Mitarbeiter in der Firma FP an seinem Arbeitsplatzrechner authentifizierenmuss, bot sich diese Technik an. Der Browser kommuniziert dabei mit dem Server ineiner verschlusselten Form, wobei das Passwort selber nicht ubertragen wird (siehe[Loh 03, Kap. 13]).

60

Wird die Zeiterfassung gestartet, so werden die Authentifizierungsdaten an denServer gesendet und sofern dieser Benutzer berechtigt ist, bekommt er den Zugangzum System.

Zunachst wurde in der Analyse von einer eigenstandigen Authentifizierung ausge-gangen, d. h., zu jedem Mitarbeiter wird ein Passwort angelegt. Dafur muss eine ent-sprechende Authentifizierungsmaske entwickelt werden. Dabei mussten verschiedeneProbleme berucksichtigt werden: Wer darf das Passwort sehen? Wird das Passwortverschlusselt und wenn ja mit welchem Verfahren? Was passiert, wenn ein Benutzersein Passwort vergessen hat? usw.

Die bis dahin beschriebenen Anforderungen mussten geandert werden. Wie sichbei weiteren Befragungen herausgestellt hat, besitzt der Benutzer nicht nur ein NT-Konto, sondern beliebig viele, d. h., fur jeden Benutzer wird eine Menge von Kontenbzw. Accounts angelegt (vgl. mit Abbildung 8 auf Seite 28 und siehe auch Employ-eeAccount in 55 auf Seite 85).

Diese Losung funktioniert nur unter einigen Voraussetzungen. Da der Benutzeruber das NT-Konto authentifiziert wird, muss ein entsprechendes auch in der Doma-ne existieren. Ein Problem bei diesem Mechanismus ist die Abhangigkeit zu einemWindowsserver. Außerdem muss der Browser ein Internet Explorer sein. Da dieseBedingungen in der Zeiterfassung aber erfullt waren, stellt dieser Mechanismus einegute Losung dar.

Im Namespace System.Security.Principal stellt ASP.NET eine Klasse WindowsI-dentity zur Verfugung, die einen Windowsbenutzer reprasentiert. Uber diese Klassewird der Benutzername des NT-Kontos (Account) des Benutzers ermittelt.

Beim Event Session Start in der Klasse Global wird zu dem Account ein ent-sprechender Benutzer ermittelt (siehe SelectEmployeeByAccount in 5.3.5). Die Be-nutzerechte in der Zeiterfassung sind dabei verschieden von denen in der Domaneund werden an das Session Objekt gebunden.

Damit stehen die Benutzerrechte uberall in der Zeiterfassung zur Verfugung undkonnen entsprechend verwendet werden, um z. B. bestimmte Spalten im Datagridauszublenden oder in der Navigation nur bestimmte Buttons anzuzeigen.

5.7 Zusammenfassung

5.7.1 Gesamtstruktur

Die zuvor vorgestellten Konzepte werden im Folgenden anhand des Beispiels Mitar-beiterverwaltung von Abbildung 38 zusammengefasst.

61

Abbildung 38: Zusammenfassende Darstellung am Beispiel Mitarbeiterverwaltung

Der Einstiegspunkt in die Zeiterfassung ist die Webform Default mit ihrer dazu-gehorigen CodeBehind Klasse PageFrontdoor. Die Verbindung zwischen der KlassePageFrontdoor und dem Template Main stellt das Laden des Templates in den Pla-ceHolder PhContent dar (vgl. Kapitel 5.4.2).

Gemaß Kapitel 5.4 beschreibt der Namespace WebControl.Employee in Abbil-dung 38 in der Komponente ProjectManagement.Core einen beispielhaften Aufbaufur die zwei Templates Main und EmployeeList. Die Templates werden von einerspezifischen Klasse von UserControlBasic abgeleitet. In diesem Fall ist dies Employ-eeUserControl. In diesen Klassen werden weitere Methoden definiert, die in mehrerenTemplates des Funktionsblocks benotigt werden. Die Klasse UserControlBasic, wel-

62

che einen Funktionsblock reprasentiert, wird von UserControl abgeleitet und stellteinige Properties zur Verfugung. Das Setzen des Properties Info setzt beispielsweiseeinen Benutzerhinweis auf der Webform Default (siehe LInfo in Kapitel 5.4.2). DieKlasse UserControlBasic besitzt außerdem ein Property, welches den aktuellen Be-nutzer mit seinen Benutzerrechten reprasentiert (siehe Kapitel 5.6). Die Schnittstellezur Businesslogik bildet das Property Controller.

Das Property PageNavigator bzw. in diesem Fall das spezifische Property Em-ployeeNavigator reprasentiert das PageNavigator Objekt, was an die Session ge-bunden wird. Dieses beschreibt die Zusammensetzung der Oberflache, d. h. wie dieTemplates miteinander in Abhangigkeit stehen (siehe Kapitel 5.5).

Die Klasse EmployeeManager ist eine beispielhafte Managerklasse, wie in 5.2und 5.3 beschrieben wurde.

5.7.2 Beispielhafter Ablauf

Abbildung 39: Sequenz Diagramm bei einer Serveranfrage ohne Event

Abbildung 40: Sequenz Diagramm bei einer Serveranfrage durch ein Event

63

In Abbildung 39 und 40 sind zwei beispielhafte Ablaufe einmal mit und einmalohne Event dargestellt. Beim Aufrufen eines Oberflachenzustandes durch ein Event(beispielsweise durch Betatigen eines Buttson) wird, wie in Abbildung 40 dargestellt,fur jedes Template das Event Load geworfen bzw. die Methode Page Load aufge-rufen. An das Event ”Betatigen des Buttons neuen Mitarbeiter anlegen” wird eineMethode mit dem Namen BtShowInsertMask Click gebunden, die in diesem Fallaufgerufen wird. Diese andert den Zustand des PageNavigator Objekts (vgl. Abbil-dung 36 auf Seite 59) und ruft die Reload-Methode auf, die in UserControlBasicdefiniert wurde. Diese fuhrt zu einer neue Anfrage am Server (mit dem geandertenPageNavigator).

Die neue Anfrage an den Server (siehe Abbildung 40) wirft dann ebenfalls dasEvent Load, was in den jeweiligen Templates die Methoden Page Load aufruft. Dasanschließende Event PreRender (mit der Methode Page PreRender) setzt die Inhalteder einzelnen Templates. An dem Beispiel von Abbildung 38 ist dies die Darstellungaller Mitarbeiter, die durch LoadArrayList aus der Businesslogik geholt werden.

5.7.3 Schwierigkeiten beim Entwurf

Die fehlende Vererbung im Persistenz Framework erzwang bereits beim Entwurfflache Strukturen, d. h. Strukturen ohne Vererbung. Beispielsweise ist Wiederver-wendbarkeit in den konkreten Managerklassen nicht moglich, da diese von ihren spe-zifischen abstrakten Managerklassen abgeleitet werden mussen (siehe Kapitel 5.3.1).

Das nachste Problem stellen die verschiedenen Anfragemoglichkeiten dar. Furjede Anfrage, beispielsweise Projekte mit Fachgruppen, die bereits geschlossen sind,oder Projekte ohne Fachgruppen eines bestimmten Monats, muss eine abstrakte Me-thode in der Komponente ProjectManagement.Core definiert und in den konkretenManagern implementiert werden.

Problematisch an dieser Struktur waren auch die Anderungen. Eine Anderungfuhrt zu einer Anderung in den entsprechenden spezifischen und konkreten persis-tenten Objekten und entsprechend auch in den dazugehorigen Managern.

Der Vorteil an dieser Variante ist nicht nur die logische, sondern auch die phy-sikalische Trennung zwischen Implementierung und Entwurf. Wie bereits in Kapitel5.1 beschrieben wurde, soll der Entwurf die Analyse erweitern bzw. verfeinern, wasdurch Definition der abstrakten Methoden in den Klassen des Persistenz-Frameworksdurchgefuhrt wird. Vererbung kann dabei nur auf Spezifikationsebene durchgefuhrtwerden, wie in Abbildung 26 in Kapitel 5.3.5 an der Klasse SimpleObject zu sehen ist.Kostenstellen (CostCenter), Projekttypen (ProjectType), Projektgruppen (Project-Group) und Aufgabenkataloge (Activity) haben die gleichen Properties: ID, Nameund Beschreibung. Wie bereits erwahnt wurde, ist diese Struktur in den konkreten

64

Komponenten nicht mehr moglich.

Die Trennung nach dem Model-View-Controller Pattern ist ebenfalls gegeben.Das Persistenz-Framework besitzt dabei die Rolle des Modells, die Webform und dieTemplates bilden die View und die Codebehind Klassen mit ihrem PageNavigator(siehe Kapitel 5.5.1) nehmen die Rolle des Controllers ein.

Die Entwicklung in einem Framework ist nicht ganz einfach, da nur an den vor-definierten Schnittstellen angesetzt werden kann. Beispielsweise habe ich erst sehrspat herausbekommen, dass es ein PreRender Event gibt, wobei man sich vorstellenkann, wie eine Implementierung ohne dieses Event ausgesehen hat, da nach demWerfen der Benutzer Events keine Methode mehr zur Verfugung stand.

Ein weiteres Problem fur einen Web-Programmierer ist die Vorstellung, dassHTML-Elemente Objekte mit Events und Methoden sind. Die etwas andere Formder Webseitengestaltung hat aber auch einige Nachteile. Uber das Visual Studiolassen sich zwar die Oberflachen einfach zusammenklicken, aber wenn man besonde-re Wunsche hat (siehe Kapitel 5.4.4), wird man gezwungen Manipulationen in denautomatisch erzeugten Webforms bzw. Templates vorzunehmen, die nicht geradeeinfach zu lesen sind.

Die Entwicklung und Verwendung des PageNavigators (siehe Kapitel 5.5.1) warprinzipiell eine gute Idee, wobei sich die Controller-Funktion des Model-View- Con-troller Patterns fur jede Oberflache auf drei Klassen verteilt hat: die CodeBehindKlasse, die spezifische UserControlBasic Klasse und den spezifischen PageNavigator.

5.7.4 Nebenlaufigkeit

Ein Problem bei der Entwicklung einer Web-Applikation ist die Nebenlaufigkeit.Wie noch im Kapitel 6.3.3 gezeigt wird, stellten nebenlaufig arbeitende Aktionenein Problem dar. In Kapitel 6.3.3 wird die Nebenlaufigkeitsproblematik zwischenBusinesslogik und Datenbank beschrieben. Ein anderes Problem ist die Nebenlau-figkeit zwischen Client und Businesslogik. Eine Web-Applikation besitzt im Ver-gleich zu einer Nicht-Web-Applikation (siehe Kapitel 5.4.3) einige Besonderheiten.Beispielsweise kann der Zustand der grafischen Benutzeroberflache eines Benutzersnie wirklich eindeutig bestimmt werden. Aus diesem Grund muss jedem BenutzerEvent bzw. Serveranfrage sichergestellt werden, dass die Operationen, die ausgefuhrtwerden sollen, im aktuellen Zustand noch zulassig sind.

5.7.5 Ubergang zur Implementierung

Die in den spezifischen Managerklassen und den persistenten Objekten definiertenabstrakten Methoden mussen fur die spezifische Komponente mit Funktionalitat

65

gefullt werden, d. h., von jeder dieser Klassen muss eine abgeleitete Klasse ent-wickelt werden, welche die abstrakten Methoden implementiert. Instanzen dieserKlasse mussen an eine von Controller abgeleitete Klasse gebunden werden.

66

6 Implementierung mit relationaler Datenbank

6.1 Einleitung

Die relationale Datenbank basiert auf dem Relationenmodell, welches von E. F.Codd 1970 [Cod 70] vorgestellt wurde. Das grundlegende Konzept der relationalenDatenbank ist die Tabelle13. Eine Tabelle besitzt eine definierte Anzahl von Attri-buten (Spalten) und eine beliebige Menge von Tupeln. Die Tupel reprasentieren dieDatensatze. Uber so genannte Schlusselverbindungen, wie in Kapitel 6.2 noch ge-zeigt wird, werden Beziehungen zwischen den Tabellen realisiert.

Die Kommunikation zwischen der Anwendung14 und der Datenbank erfolgt uberdie standardisierte Stuctured Query Language (SQL). Eine relationale Datenbankist immer ein von der Anwendung unabhangiges System. Die Probleme, die durchdiese Trennung entstehen, werden im weiteren Verlauf noch beschrieben. In Formeines Strings (Query) werden Anweisungen oder Abfragen formuliert, die an dieDatenbank gesendet und dort entsprechend ausgefuhrt werden. SQL kann in dreiTeilsprachen unterteilt werden:

Die Datendefinitionssprache (DDL) enthalt Befehle zum Anlegen, Andern undLoschen von Strukturen bzw. Tabellen. Die einzelnen Moglichkeiten und Problemewerden in Kapitel 6.2 beschrieben.

In der Datenmanipulationssprache (DML) werden Befehle zum Erzeugen, An-dern und Loschen von Daten definiert. Die Funktionsweise der Datenmanipulationund die Problematik, insbesondere bei nebenlaufigen Manipulationen, werden in Ka-pitel 6.3 beschrieben.

Die dritte Teilsprache von SQL ist die Abfragesprache (QL), mit der die einzel-nen Daten abgefragt werden. Diese wird in Kapitel 6.4 vorgestellt.

Redundanzvermeidung durch Normalisierung ist einer der entscheidenden Vor-teile einer relationalen Datenbank. Durch mathematische Regeln, die auf der Arbeitvon [Cod 70] basieren, konnen Redundanzen vermieden bzw. gemindert werden. Die-ses Thema wird in Kapitel 6.5 behandelt.

In Kapitel 6.6 wird anhand des Beispiels der ODBC-Schnittstelle beschrieben,wie aus der Sicht der Anwendung mit der Datenbank kommuniziert wird.

Basierend auf den Grundlagen von Kapitel 6.2-6.6 wird in Kapitel 6.7 das kon-

13In der Relationstheorie spricht man von Relationen und in der Datenbank von Tabellen. Prin-zipiell sind Tabellen Relationen, die in einer (relationalen) Datenbank verwendet werden.

14Die Anwendung ist in diesem Fall die Applikation ”Zeiterfassung”.

67

krete Datenmodell der Applikation Zeiterfassung vorgestellt.

In Kapitel 5.3 wurde bereits das entwickelte Framework vorgestellt, was eineTrennung von Entwurf und Implementierung ermoglicht. Die Beispiele im Folgen-den beziehen sich auf dabei vorgestellten Managerklassen aus Kapitel 5.3.

Bei der Entwicklung einer relationalen Datenbank ergeben sich etliche Schwierig-keiten und Schwachen, wie in den folgenden Kapiteln noch gezeigt wird. In Kapitel6.8 werden diese zusammengefasst und mit einer Motivation zur Objektorientierungin Datenbanken abgeschlossen.

Die Beschreibungen basieren auf dem SQL-99 Standard, allerdings ohne die ob-jektrelationalen Erweiterungen. Da SQL-99 abwarts kompatibel zu SQL-92 ist, sinddarin auch alle Moglichkeiten von SQL-92 enthalten. Dabei werden nur die Punktebehandelt, die fur die Realisierung und den Vergleich relevant sind. Weitere Kon-zepte, wie beispielsweise Schemata, mit denen logisch zusammengehorige Tabellenweiter strukturiert werden konnen, werden nicht behandelt.

6.2 Datendefinition

6.2.1 Datentypen und Domanen

Fur jedes Attribut wird ein Wertebereich definiert. Dieser Wertebereich wird alsDomane bezeichnet. Neben vordefinierten Domanen besteht die Moglichkeit, eigeneDomanen zu definieren. Diese basieren auf vordefinierten Domanen und konnen die-se einschranken. Ein Beispiel fur eine Domane ist eine Prozentdefinition, die durchden Query ”CREATE DOMAIN Percent INTEGER CHECK(BETWEEN 0 AND100)” definiert werden kann.

Benutzerdefinierte Domanen sind nicht streng typisiert, da sie keine Typen imeigentlichen Sinne sind, d. h., ein Vergleich von Percent und einem Attribut vomTyp Integer mit dem Wert 101 ware zulassig (vgl. [Tur 03, S. 26]).

Domanen sind atomar, d. h., Strukturen in Attributen sind nicht moglich. DieKonsequenzen daraus, die sich fur die Datenmodellierung ergeben, werden im wei-teren Verlauf noch beschrieben.

6.2.2 Primarschlussel

Zur Identifizierung eines Tupels wird in einer Tabelle ein Primarschlussel definiert.Dieser kann entweder aus einem einzelnen oder aus einer Gruppe von Attributen(zusammengesetzter Schlussel) bestehen. Der Primarschlussel darf nicht NULL seinund muss fur jedes Tupel eindeutig vorliegen.

68

Die Betrachtung eines Primarschlussels als Identitat, wie es in vielen Fallen ge-tan wird, hat einen entscheidenden Nachteil. Wenn der Wert des Primarschlusselsgeandert wird, so bedeutet das, dass sich die Identitat eines Tupels andert, was aberfalsch ist.

Ein konkretes Beispiel ist das Projekt, wie in Kapitel 6.7 auf Seite 83 noch ge-zeigt wird. Ein Projekt wird durch eine Projektnummer (ProjectID) identifiziert,welche gleichzeitig der Primarschlussel ist. Eine Anderung der Projektnummer, bei-spielsweise weil eine Projektnummer falsch eingegeben wurde, bedeutet aber keineAnderung der Identitat des Projekts (vgl. auch [Saa 03, S. 47 f.]).

Aus diesem Grund wurden - bis auf das Projekt - fur alle Entitaten unveran-derliche Schlussel definiert. Der Datentyp ”serial” in der Abbildung 55 auf Seite 85erzeugt automatisch eine fortlaufende eindeutige Zahl. Die Anwendung, also die Zei-terfassung, braucht sich in diesem Fall nicht mehr um die Eindeutigkeit zu kummern.

6.2.3 Fremdschlusselverbindungen und referentielle Integritat

Um zwei Tabellen miteinander in Beziehung zu setzen werden Fremdschlussel de-finiert. Ein Fremdschlussel kann, genau wie ein Primarschlussel, fur ein einzelnesAttribut oder eine Gruppe von Attributen definiert werden. Zu jedem Fremdschlus-sel in einer Tabelle gibt es einen dazugehorenden Primarschlussel in einer anderenTabelle.

Dabei mussen Fremdschlusselverbindungen die referentielle Integritat gewahr-leisten. Referentielle Integritat bedeutet, dass zu jedem Fremdschlusselwert in einerTabelle ein entsprechender Primarschlussel existiert, der den gleichen Wert besitzt,oder der Fremdschlussel ist NULL, d. h., ein Fremdschlussel muss immer auf einenexistierenden Primarschlussel verweisen (vgl. [Vor 99], S. 89).

6.2.4 Integritatsbedingungen

Durch Anderungen an den Daten konnen Schlusselbedingungen verletzt werden unddie referentielle Integritat ist dann nicht mehr gegeben. Wie in [Tur 03, S. 20] be-schrieben, tritt dies ein, wenn einer der folgenden Punkte erfullt ist:

• Einfugen einer Zeile in die referenzierende Tabelle.

• Andern des Fremdschlusselwertes einer Zeile in der referenzierenden Tabelle.

• Loschen einer Zeile aus der referenzierten Tabelle (oder Loschen einer referen-zierten Tabelle).

• Andern des korrespondierenden Schlusselwertes einer Zeile in der referenziertenTabelle.

69

Zu Sicherung der referenziellen Integritat muss einer Fremdschlusselverbindungeine Eigenschaft (siehe Abbildung 41) mitgegeben werden, die beschreibt, wie eineVerletzung der referenziellen Integritat behandelt wird.

NO ACTION: Wenn eine Fremdschlusselbedingung beim Andern oder Loscheneiner Zeile verletzt wird, wird diese Anfrage mit einem Fehler zuruckgewiesen.Allerdings kann die Integritatsverletzung mit einem Trigger behoben werden,wodurch kein Fehler auftritt.

CASCADE (C): Die Anderung oder Loschung der Zeile wird kaskadiert. Wirdeine Zeile geloscht bzw. geandert, so werden alle Zeilen, die auf diese Zeilereferenziert haben, mit geloscht oder geandert.

SET NULL (SN) und SET DEFAULT (SD): Wird ein Primarschlussel einerZeile geandert oder eine Zeile geloscht, so werden die Fremdschlussel, die aufdiese Zeile referenzierten, auf NULL bzw. den eingestellten Defaultwert gesetzt.

RESTRIKT (R): Restrikt weist eine Anfrage, genau wie No Action, zuruck, wenneine Integritatsverletzung vorliegt. Ein Beheben der Integritatsverletzung miteinem Trigger ist allerdings nicht moglich.

Abbildung 41: Referenzielle Aktionen nach [Tur 03, S. 21]

6.2.5 Trigger

Fremdschlusselverbindungen konnen nur die Integritat zwischen zwei Tabellen, d.h. die referentielle Integritat gewahrleisten. Fur komplexere Integritatsprufungenwerden Trigger definiert. Ein Trigger fuhrt, ahnlich zu einem Event, beim Eintreteneines Ereignisses eine Folge von Anweisungen aus. Die moglichen Ereignisse nachdem SQL-99 Standard, wie in [Tur 03, S. 37] beschrieben, sind das Einfugen, Andernoder Loschen von Tupel.

6.2.6 Benutzerdefinierte Routinen

Durch die Definition von benutzerdefinierten Routinen (stored procedures) bestehtdie Moglichkeit, einfache Funktionalitaten in einer relationalen Datenbank auszufuh-ren. Diese konnen, durch die Verwendung von atomar definierten Funktionsblocken,Definition von Variablen, bedingten Schleifen oder bedingten Anweisungen, zusatzli-che Integrationsprufungen oder analog zu den Sichten komplexe Abfragen realisieren.Dabei ahnelt eine benutzerdefinierte Routine sehr einem Pascalprogramm, in wel-chem zusatzlich SQL-Statements enthalten sind.

70

So wie in [Tur 03, S. 32] beschrieben wird, sind nicht alle SQL-Statements zulas-sig. Beispiele fur nicht zulassige SQL-Statements sind Transaktionsanweisungen, An-weisungen zur Steuerung der Datenbankverbindung und Transaktionsanweisungen.Bei den benutzerdefinierten Routinen wird zwischen Prozeduren und Funktionenunterschieden. Funktionen haben im Gegensatz zu Prozeduren einen Ruckgabewertund konnen auch in Queries verwendet werden, um z. B. Bedingungen zu definie-ren. Funktionen konnen außerdem uberladen (overloading) werden (vgl. dazu auch[Tur 03, S. 28-37]).

Die Funktionen und Prozeduren in Klassen zu organisieren und damit Vererbungund dynamisches Binden zu ermoglichen, besteht nicht.

6.2.7 Sichten (Views)

Eine Sicht, auch als virtuelle Tabelle bezeichnet, reprasentiert eine SQL-Anfrage undkann wie eine Tabelle verwendet werden. Anderungen in den Tupeln einer Sicht sindzwar nach dem SQL-99 Standard unter sehr eingeschrankten Bedingungen moglich(vgl. [Tur 03, S. 253 ff.]), da aber die mir zur Verfugung stehende Informix Daten-bank Anderungen auf Sichten nicht unterstutzt und die verwendeten Sichten dieBedingungen uberwiegend nicht erfullt haben, wird im Folgenden davon ausgegan-gen, dass Anderungen an Sichten nicht moglich sind.

6.2.8 Schwachen der relationalen Datendefinition

Wahrend in der Anwendung komplexe (objektorientierte) Datentypen verwendetwerden konnen, mussen diese in der relationalen Datenbank durch die fehlende Ver-erbung auf flache Strukturen abgebildet werden. Die Domanen (vgl. 6.2.1) konnenzwar Wertebereiche definieren, sind aber keine echten Typen im eigentlichen Sinne.Dadurch, dass sie nicht typsicher sind, konnen beliebige Daten unterschiedlicher Do-manen miteinander verglichen und in Beziehung gesetzt werden.

In Kapitel 6.7.2 wird die Problematik bei der Modellierung des Modells vonAbbildung 8 auf Seite 28 in einer Struktur ohne Vererbung noch genauer beschrieben.

6.3 Datenmanipulation

6.3.1 Datenmanipulationsoperationen

Einfugen, Andern und Loschen von Tupeln werden uber die Insert-, Update- undDelete-Statements durchgefuhrt. Diese Operationen sind auf einzelne Tabellen be-schrankt, d. h., Operationen, die sich auf mehrere Tabellen verteilen, mussen ineinzelnen SQL-Statements angegeben werden. Die referentielle Integritat und even-tuell durch Trigger zusatzlich definierte Integritatsbedingungen durfen dabei nicht

71

verletzt werden. Damit ist gesichert, dass keine unzulassigen Zustande in der Da-tenbank vorkommen konnen.

6.3.2 (SQL-)Transaktionen

Eine Transaktion ist eine atomare Ausfuhrungseinheit, die eine Folge von logisch zu-sammengehorigen Operationen umfasst und dem ACID-Prinzip, wie in Abbildung42 dargestellt, entsprechen muss (vgl. [Saa 03, S. 275]).

Atomicity (Atomaritat): Eine Transaktion stellt eine atomare Einheit dar, d. h.,eine Transaktion wird entweder vollstandig oder gar nicht ausgefuhrt.

Consistency (Konsistenz): Nach Abschluss einer Transaktion muss sich die Da-tenbank in einem konsistenten Zustand befinden.

Isolation: Parallel ablaufende Transaktionen durfen sich gegenseitig nicht behin-dert, d. h., eine Transaktion muss immer so ablaufen, als ware sie die einzigeauf der Datenbank. Anderungen an Daten in einer Transaktion durfen in eineranderen Transaktion nicht auftreten.

Durability (Dauerhaftigkeit): Beim Beenden einer Transaktion mussen alle An-derungen, welche durch die Transaktion verursacht wurden, dauerhaft (persis-tent) erhalten bleiben.

Abbildung 42: Die ACID-Eigenschaften, die eine Transaktion erfullen sollte

In einer relationalen Datenbank werden dafur entsprechende Operationen zurVerfugung gestellt, die eine Transaktion starten und erfolgreich (Commit) oderdurch Ruckgangigmachen aller Operationen der Transaktion (Rollback) beenden.Erst wenn ein Commit durchgefuhrt wurde, sind alle Daten dauerhaft in der Da-tenbank gespeichert. Tritt wahrend einer Transaktion ein Fehler auf, beispielsweiseweil eine Integritatsbedingung nicht erfullt ist oder eine Query eine fehlerhafte Syn-tax besitzt, so verhalt sich die Datenbank wie bei einem Rollback und erzeugt denZustand, der vor der Transaktion existierte. Dies funktioniert wunderbar unter derVoraussetzung, dass keine weitere parallele Transaktion lauft. Durch das Bilden vonTransaktionen, in denen die Queries an die Datenbank gesendet werden, sind dieACID-Eigenschaften Atomicity und Durability erfullt.

6.3.3 Nebenlaufigkeitsanomalien

Problematisch wird die Erfullung der ACID-Eigenschaften Consistency und Isola-tion. Diese beziehen sich auf die Nebenlaufigkeitsproblematik. Nebenlaufige Lese-und Schreiboperationen konnen, wie in Abbildung 43 dargestellt, zu inkonsistenten

72

Zustanden fuhren (vgl. [Vor 99, S. 143 f.]).

Dirty Read: Diese Problem tritt auf, wenn eine Transaktion Daten liest, die zuvorvon einer zweiten geandert wurden, und diese zweite Transaktion ein Rollbackausfuhrt. Das Rollback der zweiten Transaktion verwirft die Anderungen in derDatenbank, aber die erste Transaktion verwendet noch die ”falschen” Daten.

Lost Update: Zwei Transaktionen lesen jeweils das gleiche Objekt und andern diesunabhangig. Die Anderungen der ersten Transaktionen werden dabei uber-schrieben.

Non-repeatable Read: Wenn eine Transaktion zweimal dasselbe Objekt liest undes wahrenddessen geandert wurde, wurde die zweite Leseoperation einen an-deren Wert zuruckliefern. Dies ist vor allem dann problematisch, wenn einewiederholte Anfrage abhangig von einem Ergebnis einer vorherigen Anfrageist.

Phantom Read: Das Problem Phantom Read tritt bei folgendem Ablauf ein: EineTransaktion holt sich Daten, die abhangig von einer Menge sind, die anschlie-ßend von einer zweiten Transaktion geandert wird. Die erste Transaktion ver-arbeitet diese Daten, welche die geforderten Bedingungen nicht mehr erfullt.

Abbildung 43: Anomalien bei nebenlaufigen Transaktionen nach [FO 04b]

In [FO 04b] wird noch eine weitere Anomalie mit dem Namen Reading of Incon-sistent States beschrieben, die sich auf Verletzung von Bedingungen zwischen Datenbezieht, da diese aber in der ubrigen Literatur nicht zu finden war, wird sie hiernicht weiter beschrieben.

Das folgende Beispiel soll das Problem Phantom Read verdeutlichen:

Transaktion 1 ermittelt alle Projekte, die keine Fachgruppen15 besitzen. Einezweite Transaktion fugt anschließend einem dieser Projekte eine erste Fachgruppehinzu. Die erste Transaktion enthalt dabei in ihrer Projektmenge ein Projekt, welchesFachgruppen besitzt, obwohl diese Transaktion davon ausgeht, dass sie die Liste allerProjekte ohne Fachgruppen enthalt.

6.3.4 Nebenlaufigkeitskontrolle

Um die Kapitel 6.3.3 dargestellten Probleme zu beseitigen gibt es grundsatzlich zweiAnsatze, die in diesem Kapitel beschrieben werden. Nebenlaufigkeitskontrolle kann

15In der realisierten Datenbank existiert zu jedem Projekt immer eine Default-Fachgruppe (vgl.6.7). Das Problem bleibt aber das gleiche.

73

auf verschiedenen Ebenen durchgefuhrt werden. Im Folgenden wird nur von Daten-einheiten gesprochen, wobei es abhangig von der verwendeten Granularitat ist, obeine Dateneinheit ein Wert, ein Tupel, eine Tabelle oder eine Datenbank ist.

Der erste Ansatz ist die pessimistische Nebenlaufigkeitskontrolle. Diese basiertauf einem Lock-Mechanismus. Eine bestimmte Dateneinheit kann von einer Trans-aktion entweder durch einen exklusive, write lock oder ein shared, read lock gesperrtwerden (vgl. [Vor 99, S. 150]. Dabei kann eine Dateneinheit entweder von beliebigvielen Transaktionen mit einem shared, read lock belegt oder einer einzigen Trans-aktion mit einem exklusive, write lock gesperrt werden. Zugriffe auf gelockte Da-teneinheiten werden von der Datenbank sofort zugewiesen, bzw. abhangig von derDatenbank konnen auch Wartezeiten eingestellt werden. Wird der Lock wahrenddieser Wartezeit freigegeben, so kann die Transaktion, welche die gelockte Daten-einheit benotigt, ausgefuhrt werden (vgl. dazu auch [FO 04b]).

Der zweite Ansatz ist die optimistische Nebenlaufigkeitskonrolle (vgl. [FO 04b]).Die Prufung, ob eine Lese- oder Schreiboperation unzulassig ist, wird beim Ausfuh-ren der jeweiligen Operation uberpruft. Realisiert werden kann dieser Algorithmusdurch das Einfuhren von Zeitstempeln oder Versionierung der Dateneinheiten (vgl.[FO 04b] und [Vor 99, S. 156 f.]).

Einen direkten Mechanismus gibt es beim relationalen Datenbankkonzept nicht.Es besteht zwar die Moglichkeit, in einem Attribut eine Version oder einen Zeitstem-pel zu speichern und diesen Wert bei jeder Anderung zu aktualisieren. Das Problem,was sich dabei stellt, ist, dass dieses spezielle Attribut ein Attribut wie jedes andereauch ist und beliebig geandert werden kann. Viel schlimmer ist die Abfrage, ob einWert noch aktuell ist. Die Versionsinformation muss beim Lesen eines Datensatzesmit ausgelesen und beim Andern entsprechend uberpruft werden, ob dieser Wertnoch aktuell ist. Zumindest das Testen auf Aktualitat und das Andern sollten dannin einer sperrenden Transaktion durchgefuhrt werden.

6.4 Datenabfragen (Select)

6.4.1 Select-Statement

Durch das Select-Statement werden, wie in Abbildung 44 dargestellt, Tupelmengenaus Tabellen abgefragt.

Die From-Klausel enthalt die Tabellen, aus denen die Daten abgefragt werdensollen. In der Select-Klausel werden die Attribute angegeben, die zuruckgeliefertwerden sollen. Die Where-Klausel gibt Bedingungen an, die auf die Ergebnismengezutreffen mussen. Abbildung 45 zeigt ein Beispiel mit zwei Tabellen. Um einen Ver-bund dieser beiden Tabellen zu erzeugen, werden die Schlusselbedingungen in der

74

SELECT <Attribute>FROM <Tabellen>[WHERE <Bedingungen>][ORDER BY <Sortierreihenfolge>]

Abbildung 44: Einfache Darstellung des SQL-Select-Statements

Where-Klausel definiert, wie in Abbildung 46 dargestellt.

Abbildung 45: Verbund von zwei SQL-Tabellen

SELECT Employee.ID AS ID, AccountID, Firstname, Lastname, AccountFROM Employee, EmployeeAccountWHERE Employee.ID=EmployeeAccount.ID

Abbildung 46: SQL-Select-Statement zu dem Beispielverbund von Abbildung 45

Des Weiteren konnen in der Select-Klausel berechnete Werte enthalten sein. EinBeispiel aus der Zeiterfassung ist die Select-Anfrage fur Projekte. Dort wird u. a. einAttribut erzeugt, was die Summe aller Fachgruppen des jeweiligen Projekts enthalt.

Abbildung 47 stellt eine ”einfache” Ad-hoc-Anfrage uber alle Mitarbeiter, die ineiner ausgewahlten Kalenderwoche an einem ausgewahlten Projekt gearbeitet haben,dar. Wie an diesem Beispiel zu sehen ist, konnen Anfragen nach einfachen Informa-tionen ziemlich kompliziert werden und die Bedeutung einer Anfrage ist nicht soforterkennbar. Die definierten Fremdschlusselverbindungen mussen dabei als Bedingun-gen mit angegeben werden. Solche Anfragen konnen bei sehr großen Datenmengendurch die Verbund-Operation sehr rechenintensiv werden.

75

SELECT ... FROM Employee e, EmployeeContract ec,EmployeeWeek ew, Week w, ProjectEmployee pe, Project pWHERE e.EmployeeID = ec.EmployeeIDAND ec.ContractID = ew.ContractIDAND ew.EmployeeWeekID = w.WeekIDAND w.CalendarWeek = <ausgegewahlte Kalenderwoche>AND w.Year = <ausgewahltes Jahr>AND ew.EmployeeWeekID = pe.EmployeeWeekIDAND pe.ProjectID = p.ProjectIDAND p.ProjectID = <ausgewahltes Projekt>

Abbildung 47: Ad-hoc-Abfrage uber alle Mitarbeiter in einem Projekt in einer aus-gewahlten Woche

Wie in Kapitel 6.2.7 schon beschrieben wurde, konnen Select-Anfragen als Sich-ten abgespeichert werden. Abbildung 48 zeigt eine Sicht, die wiederum eine Sicht(CurrentEmployeeView) mit der Tabelle EmployeeAccount verbindet. Die Mengealler Mitarbeiter mit ihren Accounts, die zum aktuellen Zeitpunkt aktiv sind, wirddann uber ein einfachesSELECT * FROM EmployeeAccountViewabgefragt.

CREATE VIEW EmployeeAccountView ASSELECT ...FROM CurrentEmployeeView, EmployeeAccountWHERE CurrentEmployeeView.ID=EmployeeAccount.ID

Abbildung 48: Definition einer Sicht auf Mitarbeiteraccounts

Da Sichten nur fur Anfragen verwendet werden konnten (siehe Kapitel 6.3.1),mussten das Andern, Loschen und Einfugen von Datensatzen in einer Sicht, auf denin der Sicht enthaltenden Tabellen durchgefuhrt werden. Ein Beispiel aus der Zeiter-fassung ist das in Abbildung 45 dargestellte Beispiel. Ein neu angelegter Mitarbeiterfuhrt zu einem neuen Eintrag in der Tabelle Employee und fur jeden Account zueinem Eintrag in der Tabelle EmployeeAccount. In Kapitel 6.7.4 wird auf die Proble-matiken, die bei der Verwendung von Sichten entstehen, noch genauer eingegangen.

6.4.2 Subqueries

Ein Subquery ist ein Query, der in einem anderen Query eingebettet ist (vgl. [Inf 99,S. 7-60 bis 7-68]). Subqueries konnen in Insert-, Delete-, Update- und Select-Statements

76

verwendet werden. Ein Beispiel fur eine Subquery ist die Anfrage alle Mitarbeiter,die keinen Vertrag besitzen, wie in Abbildung 49 dargestellt.

(1) SELECT * FROM Employee e(2) WHERE ((3) SELECT COUNT(*) FROM EmployeeContract c(4) WHERE c.EmployeeID=e.EmployeeID) = ’0’

Abbildung 49: Beispiel aus der Zeiterfassung fur einen Subquery

6.4.3 OUTER JOIN

Die bisherigen Verbunde waren so genannte inner join-Verbunde. Ein weiteres Kon-zept von SQL sind die outer join-Verbunde. Ein outer join-Verbund enthalt dieMenge aller inner join-Verbunde. Zusatzlich zu dieser Menge enthalt sie die Mengealler Tupel, die die Bedingungen der Where-Klausel zwar nicht erfullen, aber auseiner Tabelle stammen, die in der From-Klausel als outer join definiert wurde.

In Abbildung 50 ist eine Beispielanwendung aus der Zeiterfassung dargestellt,welche die Liste aller Aufgabenkataloge (Activity) zuruckliefert (vgl. dazu auch 55auf Seite 85).

Existiert zu dem ubergebenden Vertrag (contractID) in der ubergebenden Woche(weekID) der ubergebenden Fachgruppe (teamID) eine Arbeitszeitzuordnung bzw.ein Eintrag in der Tabelle ActivityEmployee (siehe Abbildung 55 auf Seite 85), sowird diese Arbeitszeitzuordnung (Proration) mit ausgegeben.

(1) SELECT *(2) FROM Activity(3) OUTER ( ActivityEmployee ActivityEmployee, EmployeeWeek )(4) WHERE Activity.ActivityID=ActivityEmployee.ActivityID(5) AND ActivityEmployee.EmployeeWeekID=EmployeeWeek.EmployeeWeekID(6) AND ( (TeamID is null) OR (TeamID=’“+ teamID + “) )(7) AND ( (ContractID is null) OR (ContractID=’“+ contractID + “) )(8) AND ( (WeekID is null) OR (WeekID=’“+ weekID + “) )(9) AND Activity.ActivityID>’0’

Abbildung 50: Beispiel fur outer join

Wie in Abbildung 51 zu sehen ist, existierte fur die drei oben angegebenen Pa-rameter fur die Fachgruppe ”Software” kein Eintrag. In einem inner join-Verbund

77

ware die Zeile ”Software” nicht in der Ergebnismenge enthalten gewesen.

Activity.Name ActivityEmployee.ProrationSoftware NULLHardware 77

Testen 23

Abbildung 51: Verkurztes Ergebnis der Anfrage aus Abbildung 50

6.5 Redundanzvermeidung durch Normalisierung

Ziel der Normalisierung ist es, ein redundanzfreies Datenmodell zu erhalten, indemkeine unerwunschten Seiteneffekte auftreten. Diese Seiteneffekte werden Anomaliengenannt. Dabei werden die folgenden drei Arten von Anomalien unterschieden:

Update-Anomalie: Anderungen an redundanten Daten mussen an allen vorhan-denen Stellen durchgefuhrt werden.

Insert-Anomalie: Ein Datensatz kann erst eingefugt werden, wenn alle darin ent-haltenen Informationen vorhanden sind.

Delete-Anomalie: Wird ein Datensatz geloscht, so gehen alle Information in die-sem verloren.

Durch die von Codd (vgl. Literatur [Cod 70]) vorgestellten Normalformen sollendiese Anomalien vermieden werden. Das Prinzip der Normalisierung ist es, redundan-te Daten dadurch zu vermeiden, dass Tabellen aufgeteilt und ggf. uber zusatzlicheSchlussel in Verbindung gesetzt werden. Um die ursprunglichen Relationen wiederzu erhalten werden diese aufgeteilten Tabellen uber ihre Schlussel verbunden. DieZerlegung der Tabellen muss dabei verlustfrei sein, d. h., es durfen keine Datenverloren gehen (vgl. auch [Geb 04, S. 167 f.]).

6.5.1 Begrifflichkeiten

Funktionale Abhangigkeit:Ein Wertebereich B ist funktional abhangig von einem Wertebereich A, geschriebenA -> B, wenn zu jedem Zeitpunkt gilt:

Zu jedem Wert von A ist genau ein Wert in B zugeordnet. Das bedeutet, dassder Wertebereich A den Wertebereich B eindeutig identifiziert.

Voll funktionale Abhangigkeit:Ein Wertebereich B mit B=(B1, B2, ..., Bm) ist voll funktional abhangig von A mit

78

A=(A1, A2, ..., An), wenn B funktional abhangig von A, aber nicht funktional ab-hangig von einer echten Teilmenge von A ist.

Transitive Abhangigkeiten:Der Wertebereich C ist funktional abhangig von B und B ist funktional abhangigvon A (A –> B –> C), dann ist C transitiv abhangig von A.

6.5.2 1. Normalform

Eine Relation liegt in der ersten Normalform vor, wenn jedes Attribut atomar ist,d. h. eine nicht weiter zerlegbare Dateneinheit darstellt und keine Wiederholungs-gruppe enthalt.

Um eine nicht-normalisierte Relation in eine Relation der ersten Normalformzu uberfuhren, mussen die nicht atomaren Attribute in atomare aufgeteilt werden.Die Attribute der Wiederholungsgruppen werden in einer neuen Tabelle angelegtund entsprechend aus der alten Tabelle entfernt. Anschließend mussen diese beidenTabellen uber eine Schlusselverbindung verbunden werden, um die ursprunglicheRelation wieder darstellen zu konnen.

Fur jeden Wechsel einer Kostenstelle muss ein neuer Datensatz in der TabelleEmployee erzeugt werden. Dieser enthalt ein Datum, ab wann der Mitarbeiter die-ser Kostenstelle zugeordnet ist. Die Kostenstelleninformationen durfen nicht einfachuberschrieben werden, da Reports, die sich auf einen Zeitraum vor dem Wechselbeziehen, diesen Mitarbeiter mit der vorherigen Kostenstelle darstellen mussen. EinBeispiel fur solch einen Report ware eine Stundenubersicht, nach Kostenstellen ge-ordnet, fur einen ausgewahlten Monat. Das folgende Beispiel soll die Redundanz andieser Tabelle zeigen:

Alte Tabelle Employee:

EmployeeID Name Vertragsstart Kostenstelle1 Claus Schmidt 01.01.2004 2871 Claus Schmidt 10.04.2004 1102 Max Muller 26.06.1998 287

Wie an dieser Tabelle zu sehen ist, ist Name nicht atomar und Kostenstelle stellteine Wiederholungsgruppe dar. Die Konsequenz ist, dass keine Mitarbeiter ohneVertrag eingefugt werden konnen, Anderungen beispielsweise am Namen musstenan mehreren Stellen durchgefuhrt werden, und sollten alle Datensatze bzw. Tupelgeloscht werden, die der Kostenstelle 287 gewesen sind, so ware die Kostenstelle 287anschließend nicht mehr existent.

Um diese Relation in die erste Normalform zu uberfuhren, muss der Name in seineBestandteile (Vor- und Nachname) zerlegt werden und die Attribute Vertragsstart

79

und Kostenstelle werden in eine neue Tabelle mit dem Namen EmployeeContractausgelagert. Zusatzlich ist der neue Schlussel ContractID notig, um die ursprungli-che Relation wieder darstellen zu konnen.

Neue Tabelle Employee:

EmployeeID Vorname Nachname1 Claus Schmidt2 Max Muller

Neue zusatzliche Tabelle EmployeeContract:

EmployeeID ContractID Vertragsstart Kostenstelle1 1 01.01.2004 2871 2 10.04.2004 1102 1 26.06.1998 287

Durch den dargestellten Normalisierungsprozess ergab sich, dass ein Mitarbeitereine beliebige Menge an Vertragen besitzt, wobei es in dem jetzigen System nichtmoglich ist, dass ein Mitarbeiter mehr als einen Vertrag gleichzeitig besitzt, was aberim Datenmodell ohne großere Probleme moglich ware.

Wie an diesem Beispiel zu sehen ist, hilft Normalisierung nicht nur Redundanzenzu vermeiden bzw. zu mindern, sondern hilft auch die Daten und ihre Abhangigkei-ten besser zu verstehen. Diese Information, dass Mitarbeiter Vertrage besitzen undeigentlich nur die Vertrage ”arbeiten”, d. h. Arbeitszeiten besitzen und diese Zeitenauf Projekte verteilen, wurde im Requirement Engineering ”ubersehen” und ist erstbeim Normalisieren entstanden.

6.5.3 2. Normalform

Eine Relation liegt in der zweiten Normalform vor, wenn sie in der ersten Nor-malform vorliegt und jedes Nichtschlusselattribut16 voll funktional abhangig vomPrimarschlussel ist (vgl. [CIS]).

Das bedeutet, dass es keine Nichtschlusselattribute geben darf, die nur von einemTeil des Primarschlussels abhangig sind (vgl. gestrichelte Linie in Abbildung 52).

Alte Tabelle Week:

16Attribute, die nicht zum Primarschlussel gehoren

80

Abbildung 52: Grafische Darstellung der 2NF

WeekID ContractID Year CalendarWeek WorkingHour1 1 2004 10 381 2 2004 13 45

Neue Tabelle Week:

WeekID Year CalendarWeek1 2004 101 2004 13

Neue zusatzliche Tabelle EmployeeWeek:

WeekID ContractID WorkingHour1 1 381 2 45

6.5.4 3. Normalform

Eine Relation liegt in der dritten Normalform vor, wenn sie sich in der 2. Normalformbefindet und jedes Nichtschlusselattribut nicht transitiv abhangig vom Primarschlus-sel ist (vgl. [CIS]).

Es wurfen keine Nichtschlusselattribute existieren, die von einem anderen Nicht-schlusselattribut abhangig sind (vgl. gestrichelte Linie in Abbildung 53).

Abbildung 53: Grafische Darstellung der 3NF

Alte Tabelle Project:

PjID PjName PjTypeName PjTypeFirstPjID10001 Joker Frankiermaschine 1000010002 Frankit Frankiermaschine 10000

81

Neue Tabelle Project:

PjID PjName PjTypeID10001 Joker 110002 Frankit 1

Neue zusatzliche Tabelle ProjectType:

PjTypeID PjTypeName PjTypeFirstPjID1 Frankiermaschine 10000

6.5.5 Boyce-Codd-Normalform (BCNF)

Eine Relation befindet sich in der BCNF genau dann, wenn sie in der 3NF vorliegtund alle voll funktionalen Abhangigkeiten vom Primarschlussel ausgehen (vgl. [CIS]).

Das bedeutet, dass kein Nichtschlusselattribut ein Primarschlusselattribut iden-tifizieren darf (vgl. gestrichelte Linie in Abbildung 54).

Abbildung 54: Grafische Darstellung der BCNF

6.6 ODBC-Schnittstelle

ODBC steht fur Open DataBase Connectivity und ist eine standardisierte Schnitt-stelle, die durch standardisierte Methoden den Zugriff einer beliebigen Applikationauf eine beliebige (relationale) Datenbank beschreibt (vgl. [MSDN]).

Im .NET-Framework werden hierfur Klassen zur Verfugung gestellt, die dieseMethoden anbieten und somit die Anwendung unabhangig von der spezifischen (re-lationalen) Datenbank machen. Die vier wichtigen Klasen im .NET-Framework sinddabei folgende:

OdbcConnection: Rerasentiert eine Datenbankverbindung.

OdbcCommand: Reprasentiert einen SQL-Query oder eine benutzerdefinierte Rou-tine (vgl. Kapitel 6.2.6).

OdbcDataReader: Reprasentiert eine Ergebnisrelation, die durch einen SQL-Queryzuruckgeliefert wurde.

82

OdbcTransaction: Reprasentiert eine Transaktion.

Durch die Verwendung von ODBC-Klassen im .NET Framework werden die Pro-bleme mit den heterogenen Datenbanken gemindert. Das Definieren von Transaktio-nen mit entsprechenden Einstellungen fur die Nebenlaufigkeitskontrolle (vgl. 6.3.4)und der Verbindungsaufbau zur Datenbank werden durch die ODBC-Klassen durch-gefuhrt. Die Nebenlaufigkeitsanomalie Phantom Read (vgl. 6.3.3) kann allerdings nurdurch Serialisieren der Transaktionen vermieden werden.

6.7 Konkrete Implementierung

6.7.1 Verwendete Modellierungstechnik

Zur Beschreibung des Datenmodells habe ich die IDEF1X-Notation gewahlt, dadas mir zur Verfugung stehende Tool ERwin17 diese Notation verwendet. Auf ei-ner grafischen Benutzeroberflache lassen sich damit Entitaten und ihre Beziehungendarstellen. Aus diesen Modellen konnen SQL-Scripte erzeugt werden, welche die Da-tenbankstruktur erzeugen.

IDEF1X (siehe [IDEF]) ist eine Datenmodellierungssprache, welche auf dem An-satz des Entity-Relationship-Modells (ER-Modell) basiert und außerdem Konzeptedes Relationenmodells von [Cod 70] enthalt. Ziel dieser Modellierungsform ist einebessere grafische Reprasentation (siehe [Ade 94, S. 9 f.]).

Genauso wie in einem ER-Modell werden Entitaten durch Rechtecke dargestellt.Die Attribute werden dabei direkt in die Rechtecke hineingeschrieben, wie in Ab-bildung 55 auf Seite 85 zu sehen ist. Die so genannten schwachen Entitaten (siehe[Vor 99, S. 22 f.]) im ER-Modell werden im IDEF1X-Modell als abhangige bezeich-net und durch ein Recheck mit abgerundeten Ecken dargestellt. Diese Entitatenergeben nur zusammen mit einer unabhangigen Entitat eine Information, so wie inAbbildung 55 auf Seite 85 die Entitaten Klassen ProjectEmployee, TeamEmployeeund ActivityEmployee.

Vererbung wird zwar im IDEF1X-Modell unterstutzt, kann aber weder im ER-win noch in der relationalen Datenbank realisiert werden (siehe [Ett 99, S. 41 bis 47]).

Die Primarschlussel werden am oberen Ende einer Entitat dargestellt und durcheine horizontale Linie von den ubrigen Attributen getrennt. Fremdschlusselattributewerden durch das Kurzel (FS) dargestellt.

Wahrend das ER-Diagramm nur die Abhangigkeiten beschreibt und Primar-schlussel definiert, werden diese in dem IDEF1X-Modell genauer spezifiziert. Bei den

17siehe Homepage von Computer Associates r©: http://www.ca.com

83

Beziehungen zwischen den Entitaten werden zwei Arten unterschieden: identifizie-rende und nicht-identifizierende. Bei einer identifizierenden Beziehung ist der Fremd-schlussel gleichzeitig ein Primarschlussel, wahrend bei einer nicht-identifizierendenBeziehung dies nicht der Fall ist.

Ein Beispiel fur eine identifizierende Verbindung ist die Verbindung zwischenEmployee und EmployeeAccount in Abbildung 55. Das Primarschlusselattribut Em-ployeeID in der Entitat EmployeeAccount ist gleichzeitig der Fremdschlussel zumPrimarschlusselattribut EmployeeID in Employee.

In den meisten Fallen wurden in der Zeiterfassung nicht-identifizierende Bezie-hungen gewahlt und ein entsprechend neuer Primarschlussel wurde angelegt. Damitbesitzt fast jede Entitat nur einen Primarschlussel und Abhangigkeiten zwischen denPrimarschlusseln konnen gar nicht erst auftreten. Weitere Grunde werden in Kapitel6.7.5 aufgefuhrt. Nicht-identifizierende Beziehungen werden durch eine gestrichelteLinie dargestellt. Der ausgefullte Punkt am Ende einer Beziehungslinie beschreibt,welche Entitat durch einen Fremdschlussel mit der dazugehorigen Entitat verbun-den ist. Der nicht ausgefullte Punkt, wie in Abbildung 55 an der Beziehung zwischenEmployee und ProjectTeam zu sehen ist, bedeutet, dass der Fremdschlussel auch denWert NULL besitzen darf, was sonst nicht der Fall ist.

Das Tool ERwin bietet außerdem die Moglichkeit, die referenziellen Aktionen furdas Einfugen (I-nsert), Andern (U-pdate) und Loschen (D-elete) darzustellen. Dabeisind die in Kapitel 6.2.4 beschriebenen funf Einstellungen moglich, wobei nur Schlus-selverbindungen, die auch Null sein durfen, auf Set Null gesetzt werden durfen. DerAusdruck D:C bedeutet beispielsweise, dass das Loschen eines Datensatzes kaska-diert wird (siehe Kapitel 6.2.4), d. h., das Loschen eines Mitarbeiters (Employee)fuhrt zu einem Loschen aller seiner Accounts (EmployeeAccount) (siehe Abbildung55).

6.7.2 Entwurf des Datenmodells

In diesem Abschnitt wird an einigen Beispielen gezeigt, welche konkreten Problemesich bei der Entwicklung des relationalen Datenmodells ergeben haben und wie diesegelost wurden. Wie bereits in Abbildung 55 zu sehen ist, ist die Struktur der En-titaten nicht ohne weiteres ersichtlich. Wahrend in einem Klassenmodell Konzeptezur Verfugung gestellt werden, mit denen Beschreibungen der Realitat im Modellabgebildet werden konnen (vgl. [Fra+ 96, 2.Kapitel]), konnen diese nicht direkt ab-gebildet werden. Beispielsweise ist ein externer Mitarbeiter eine spezielle Form einesMitarbeiters und kann durch Vererbung im Klassenmodell auch so modelliert wer-den. Diese Moglichkeit bietet das relationale Datenmodell nicht.

Ein weiteres Problem ist das Fehlen der Aggregationsbeziehung. Im Klassen-

84

modell von Abbildung 8 auf Seite 28 ist die Verbindung von Projekt (Project) zuFachgruppe (ProjectTeam) eine Aggregation, d. h., ein Projekt besitzt Fachgrup-pen (siehe auch [Bit Koc 00, S.18 f.]). Diese Modellierungsform ist in IDEF1X nichtmoglich (siehe [Ett 99, S. 48]).

Eine Kompositionsbeziehung abzubilden, so wie sie in Abbildung 8 auf Seite 28zwischen Mitarbeiter und Account besteht, ist in IDEF1X ebenfalls nicht moglich(siehe [Ett 99, S. 49]). Es besteht lediglich die Moglichkeit, diese uber die Fremd-schlusseleigenschaften nachzubilden (siehe Kapitel 6.2.4). Wie in Abbildung 55, ander Verbindung zwischen Employee und EmployeeAccount zu sehen ist, wurde dieseals Delete Cascade (D:C) gekennzeichnet.

Abbildung 55: Datenmodell nach der IDEF1X-Notation (siehe Kapitel 6.7.1)

85

Das Datenmodell wurde direkt im ERwin erstellt. Ein Entwurf mit einem Klas-senmodell hatte dazu verfuhrt, durch zu viele Klassen und Vererbung eine Strukturzu entwerfen, die im IDEF1X-Modell, was von ERwin unterstutzt wird, sehr un-ubersichtlich geworden ware. In Kapitel 6.8.2 wird dieses Problem an einem Beispielgezeigt.

Kalenderwochen und Mitarbeiter

Bei der Analyse mit Requirements Engineering (siehe Mitarbeiter in Kapitel 3.1.4und Kapitel 3.1.2) und im Entwurf (siehe Kapitel 5.3.5) wurden lediglich Wochenbzw. Kalenderwochen erwahnt. Im Datenmodell mussen diese mit abgespeichertwerden (siehe Week), da Mitarbeiterwochen (siehe EmployeeWeek) von diesen ab-hangig sind. Außerdem besitzen Wochen zwei zusatzliche Flags, die identifizieren, obeine Kalenderwoche fur interne bzw. externe Mitarbeiter bereits abgerechnet wur-de, wobei hier nur von Vertragsmitarbeitern die Rede ist, d. h. Mitarbeitern, die inProjekten arbeiten und ihre Zeiten den Projekten zuordnen mussen.

Bei den Vertragsmitarbeitern gibt es zwei Arten: interne und externe. InterneMitarbeiter unterteilen sich wiederum in ”normale” interne Mitarbeiter, Studentenund Aushilfen. Da das relationale Datenmodell keine Vererbung anbietet, die Tabel-len aber noch die Entitaten widerspiegeln sollen, wurde das Problem wie folgt gelost:

Externe Mitarbeiter besitzen in ihren Vertragen die EmployeeTypeID null. EineEmployeeTypeID großer Null definiert einen internen Mitarbeiter, wobei in der Ta-belle EmployeeType die verschiedenen Arten der internen Mitarbeiter (Stundenten,Aushilfen und ”normale interne Mitarbeiter”) abgespeichert werden. Damit ist dieListe der internen Mitarbeitertypen beliebig erweiterbar.

Mitarbeiter und ihre Vertrage

Jeder Vertragsmitarbeiter besitzt eine beliebige Menge an Vertragen. Diese Ver-trage besitzen fur jede Kalenderwoche Arbeitszeiten. Jede Vertragsmitarbeiterwo-che (EmployeeWeek) kann durch Setzen des Flags Finish geschlossen werden. Indiesem Fall durfen keine Zuordnungen der Arbeitszeiten zu Projekten, Fachgruppenoder Aufgabenkatalogen durchgefuhrt werden. Die Vertrage der Vertragsmitarbeiterdurfen sich nicht uberschneiden, da jeder Vertragsmitarbeiter zu jedem Zeitpunktnur einen Vertrag besitzen darf. Mitarbeiter, die aus Sicht der Zeiterfassung keineVertrage besitzen, durfen zwar Projektleiter oder Fachsprecher sein, besitzen aberentsprechend keine Eintrage in der Tabelle EmployeeContract, wie in Abbildung 55zu sehen ist.

Projekte und Fachgruppen

86

Jedes Projekt besitzt eine beliebige Menge an Fachgruppen. Auch in diesem Fallgibt es zwei Arten von Projekten: Projekte mit Fachgruppen und Projekte ohne.Bei Projekten ohne Fachgruppen mussen aber ebenfalls Zuordnungen nach Aufga-benkategorien vorgenommen werden. Ein Eintrag in der Tabelle ActivityEmployeemuss jedoch von einem ProjectTeam abhangig sein. Um keine weiteren Tabellen ein-zufugen, besitzt jedes Projekt eine Default-Fachgruppe, die dadurch gekennzeichnetist, dass sie keinen Fachsprecher besitzt. Zeitzuordnungen auf Aufgabenkataloge inProjekten, die keine Fachgruppe besitzen, werden auf diese Default-Fachgruppe ge-schrieben. In den Ausgaben wird diese Fachgruppe unter dem Namen ”SonstigeFachgruppen” dargestellt.

Arbeitszeitzuordnungen auf Projekte, Fachgruppen und Aufgabenka-talog

Die Zuordnungen der Arbeitszeiten zu den Projekten, Fachgruppen und Auf-gabenkatalogen werden in den Tabellen ProjectEmployee, TeamEmployee und Ac-tivityEmployee abgespeichert. Ein Uberblick uber beispielsweise einen Mitarbeiterin einer ausgewahlten Kalenderwoche ist nur uber mehrere Anfragen moglich. Imweiteren Verlauf wird noch gezeigt, wie dieses Problem in einer objektorientiertenDatenbank besser gelost werden kann.

Zunachst wird die Mitarbeiterwoche (EmployeeWeek) ermittelt. Fur eine ausge-wahlte Kalenderwoche und einen ausgewahlten Mitarbeiter wird diese durch einenVerbund von Employee, EmployeeContract, EmployeeWeek und Week ermittelt.

Anschließend mussen, abhangig von EmployeeWeek, die darin enthaltenen Pro-jekte (ProjectEmployee und Project) bestimmt werden. Fur jedes Projekt wird dieListe aller zugeordneten Fachgruppen (TeamEmployee und ProjectTeam) und diedarin enthaltenen Aufgabenkataloge (ActivityEmployee und Activity) ausgelesen.

6.7.3 (SQL-)Transaktionen

Der Zugriff auf die relationale Datenbank erfolgt in der Zeiterfassung uber eineInstanz der Klasse Database, wie in Abbildung 56 dargestellt, welche die ODBC-Schnittstelle bzw. die ODBC-Klassen von .NET verwendet.

Beim Erzeugen einer Instanz dieser Klasse wird eine serialisierte Transaktion ge-offnet, die beim Entfernen dieser Instanz wieder geschlossen wird. Wie in Kapitel6.3.4 schon beschrieben wurde, gibt es in einer relationalen Datenbank keine wirklichbrauchbare Losung, um eine optimistische Nebenlaufigkeitskontrolle durchzufuhren.In Kapitel 6.3.3 wurde gezeigt, dass das Phantom Read durchaus ein Problem dar-stellt.

87

Abbildung 56: Klasse Database

Durch Serialisieren der Transaktionen ist dieses Problem gelost. Da Performanzund eine hohe Last bei der Zeiterfassung keine allzu wichtigen Themen sind, kanndiese Losung auch hingenommen werden. Bei einem Fehler, weil beispielsweise einLock gesetzt ist, wird eine Exception geworfen, die entsprechend abgefangen werdenmuss.

In Abbildung 57 ist ein Beispiel fur eine Anwendung dieser Klasse dargestellt.Die getData-Methoden (siehe Abbildung 56) geben nach einem gesendeten Query(siehe db.Query) die gewunschten Attribute eines Tupels zuruck. In der ODCB-Klasse OdbcDataReader konnen die Attribute nur uber die Spaltennummer abge-fragt werden, da es aber sinnvoller ist, diese uber ihren Namen (in Abbildung 57,Zeile 5 ”name”) zu identifizieren, werden in den getData-Methoden entsprechendeUmwandlungen vorgenommen. Der Vorteil dieser Variante ist die Unabhangigkeitzu Odbc. Ein Austauschen der (relationalen) Datenbank, fur die beispielsweise keinOdbc-Treiber existiert, hatte nur eine Anderung an dieser Klasse zur Folge. DasProtokollieren von gesendeten Queries beispielsweise musste ebenfalls nur an dieserKlasse, genauer gesagt in der Methode Query, durchgefuhrt werden.

88

(1) Database db = new Database() );(2) db.Query( ”SELECT * FROM CostCenter ORDER BY CostCenterID” );(3) while( db.getNextRecord() ){(4) CostCenter data = (CostCenter)this.CreateObject();(5) data.Name = db.getData(”name”);...(6) }(7) db.Dispose(); // zum Beenden einer Transaktion

Abbildung 57: Beispielanwendung fur die Klasse Database ohne Ausnahmebehand-lung

6.7.4 Sichten

Unabhangige Entitaten besitzen allein betrachtet keine sinnvollen Informationen undmussen mit abhangigen verbunden werden. Die abhangigen Entitaten konnen aberebenfalls nicht sinnvoll allein betrachtet werden.

Fur die Anfragen nach einer Menge von Projekten werden beispielsweise auch dieNamen der zugehorigen Projektleiter, Projekttypen und Projektgruppen benotigt.Aus diesem Grund wurden, wie in Abbildung 58 zu sehen ist, Sichten fur verschie-dene Entitaten definiert. Die verwendete Namenskonvention ist dabei ”<Tabellen-name>View”.

Sicht Zusatzliche Tabellen bzw. SichtenEmployeeAccountView EmployeeView

EmployeeView EmployeeContract, EmployeeType u. CostCenterEmployeeWeekView Employee u. EmployeeContractProjectTeamView Project u. Employee

ProjectView ProjectType, ProjectGroup, Employee u. ProjectTeamProjectEmployeeView Project u. EmployeeWeekTeamEmployeeView ProjectTeam u. EmployeeWeek

ActivityEmployeeView Activity u. EmployeeWeekCurrentEmployee EmployeeView mit Einschrankung

Abbildung 58: Sichten aus der Zeiterfassung

Fur Anfragen sind Sichten ein vorteilhaftes Konzept, um die Anfragen zu ver-einfachen, wie in Abbildung 58 zu sehen ist.

Das Loschen von abhangigen Entitaten kann dabei kaskadiert werden, wie diesbeispielsweise bei Employee und EmployeeAccount der Fall ist. Wird ein Mitarbeiter

89

geloscht, so werden alle dazugehorigen Accounts mit geloscht.

Beim Einfugen und Andern von Entitaten ist dies etwas schwieriger. Wie be-reits in Kapitel 6.2.7 erwahnt wurde, bestand keine Moglichkeit, in den SichtenDatensatze einzufugen oder diese zu andern. In Abbildung 59 ist die Eingabemaskefur Vertragsmitarbeiter zu erkennen. Wie dort zu sehen ist, werden Mitarbeiter-,Vertrags- und Accountdaten erfasst. Das Einfugen eines Vertragsmitarbeiters er-streckt sich in diesem Fall uber die drei Tabellen Employee, EmployeeAccount undEmployeeContract.

Abbildung 59: Screenshot: Eingabemaske der Vertragsmitarbeiter

6.7.5 Primarschlussel und Identitat

Ein Problem bei der Datenmodellierung stellte die Definition der Primarschlusseldar. Eine Komposition beispielsweise kann als eine identifizierende Verbindung zwi-schen zwei Entitaten modelliert werden, wobei die Fremdschlussel gleich dem Pri-marschlussel sind (vgl. [Ade 94, S. 13]).

Ein Beispiel ist die Verbindung zwischen Fachgruppe und Projekt in Abbildung8 auf Seite 28. Ein Projekt kann nur existieren, wenn die dazugehorige Fachgruppeexistiert. Die Verbindung zwischen Fachgruppe und Projekt ist ebenfalls eine Kom-position, d. h., diese Verbindungen konnen als identifizierende modelliert werden.Das Resultat war, dass eine Fachgruppe von den drei Schlusseln, der Projektgruppe,dem Projekt und der Fachgruppe, abhangig war, d. h. einen zusammengesetzten

90

Primarschlussel aus diesen drei Attributen besaß, wie in Abbildung 60 zu sehen ist.

Abbildung 60: zusammengesetzter Primarschlussel

Dies stellt aber eine Verletzung der zweiten Normalform dar, da es keinen Un-terschied macht, ob fur die Identifizierung eines Datensatzes aus ProjectTeam dasAttribut ProjectGroupID verwendet wird oder nicht. Aus diesem Grund wurde dieVerbindung zwischen Projekt und Projektgruppe in eine nicht-identifizierende ge-andert. Ein weiteres Problem ist, dass sich bei identifizierenden Verbindungen dieSchlusseldefinition ”ausbreitet”, d. h. wenn ein Projekt beispielsweise nicht mehrdurch eine Projektgruppe identifiziert wird, so wurde das Loschen der Projektgrup-pe zu einer geanderten Definition in der Tabelle ProjectTeam fuhren. Das Primar-schlusselattribut ProjectGroupID wird dann in ProjectTeam ebenfalls geloscht, ob-wohl keine direkte Verbindung zwischen ProjectTeam und ProjectGroup besteht.

Ein weiteres Problem stellte die Tatsache dar, dass eine Entitat, die durch mehrals ein Attribut im Primarschlussel identifiziert wird, keine automatisch erzeugtenPrimarschlussel (vgl. mit serial in Kapitel 6.2.2) erzeugen kann, d. h., der Primar-schlussel hatte manuell erzeugt werden mussen. Da sich die Anforderungen einigeMale geandert haben (vgl. mit Prototyping in Kapitel 3.1.5), wurde dazu uberge-gangen, fur jede Entitat nur ein Attribut als Primarschlussel zu verwenden und dieVerbindungen zwischen Entitaten durch nicht-identifizierende zu ersetzen.

Das Problem mit den Projektnummern, die als Primarschlussel verwendet wer-den, wurde bereits in Kapitel 6.2.2 beschrieben.

Aus diesem Grund wurde fast uberall ein technischer Schlussel eingefuhrt, dersozusagen die Objektidentitat simulieren soll. Dieser ist in jeder Tabelle eindeutigund vom Anwender nicht anderbar bzw. sollte nicht geandert werden.

6.7.6 Referenzielle Integritat

Die referenzielle Integritat verhindert, dass eine Datenbank in einen inkonsistentenZustand kommen kann, wie in Abbildung 61 an einigen Beispielen fur Projekt und

91

Projekttyp dargestellt ist. Komplexe Integritatsprufungen konnen nur uber Triggerrealisiert werden, wobei die fehlende Kapslung hier ein Problem darstellt. Dadurch,dass an jeder beliebigen Stelle in der Datenbank Anderungen vorgenommen werdenkonnen, mussen verschiedenste Trigger an allen moglichen Stellen eingefuhrt werden.Anderungen an den Tabellen hatten Anderungen an den entsprechenden Triggernzur Folge, wobei die Abhangigkeiten und Integritatsprufungen ziemlich schnell sehrkomplex und unubersichtlich werden konnen. Das folgende Beispiel soll dies verdeut-lichen:

Eine Mitarbeiterwoche (EmployeeWeek) darf nur dann den Zustand Finish=Truebesitzen, wenn bestimmte Voraussetzungen der Tabellen ProjectEmployee, TeamEm-ployee und ActivityEmployee erfullt sind. Da diese drei Tabellen durch die fehlendeKapselung beliebig geandert und geloscht werden konnen, mussen in diesen Tabellenebenfalls entsprechende Uberprufungen vorgenommen werden. Dieses Datenmodellist noch relativ einfach. Bei großeren Modellen, an denen mehrere Entwickler betei-ligt sind, kann dies zu einem großen Problem werden, wenn sich die Abhangigkeitenuber mehrere Tabellen erstrecken.

• Ein Projekt kann keinem Projekttyp zugeordnet werden, welcher nicht exis-tiert.

• Ein Projekttyp kann nur geloscht werden, wenn kein Projekt auf dieses Projektverweist.

• Ein Projekt, das eingefugt wird, muss auf einen gultigen Projekttypen verwei-sen.

Abbildung 61: Beispiel fur referenzielle Intritat zwischen Projekt und Projekttyp

6.8 Motivation zur Objektorientierung in Datenbanken

6.8.1 Vorteile einer relationalen Datenbank

Die relationale Datenbank bietet trotz der vielen Schwachen eine Reihe von Vor-teilen, wie in Abbildung 62 zu sehen ist, wobei sich die letzten beiden Punkte aufdie Tatsache beziehen, dass Daten in Tabellen abgespeichert werden und auf dieseeinfach zugegriffen werden kann. Wie schon gezeigt wurde, ist der Zugriff auf dieInformationen, die durch die Beziehungen der Tabellen untereinander dargestelltwerden, teilweise nur mit sehr komplizierten Queries moglich.

92

• In der Regel sind relationale Datenbanken auch bei sehr großen Datenmengennoch sehr leistungsstark.

• Die relationalen Datenbanken werden in der Regel von großen Firmen entwi-ckelt, die viel Erfahrung auf diesem Gebiet besitzen.

• Relationale Datenbanken haben sich in der Vergangenheit schon mehrfach be-wahrt.

• Durch Normalisierung wird Redundanz vermieden oder wenigstens gemindert.

• Durch mathematische Regeln lassen sich die Abhangigkeiten, Einschrankun-gen und Bedingungen der Daten beschreiben und mussen nicht implementiertwerden.

• Durch den SQL-Standard besteht (zumindest theoretisch) eine Unabhangigkeitvon Anwendung und Datenbank [Saa 03, S. 35].

• Ein relationales Datenmodell hat eine einfache Struktur (Tabellen und Schlus-selverbindungen).

• Uber ein entsprechendes Tool und SQL kann in einer relativ einfachen Formauf die Daten zugegriffen werden.

Abbildung 62: Vorteile einer relationalen Datenbank

6.8.2 Nachteile einer relationalen Datenbank

Anhand eines konkreten Beispiels sollen die Probleme des relationalen Datenmodellserklart werden. Die Beschreibungen basieren auf dem Datenmodell von Abbildung55. Wie in Abbildung 63 zu sehen ist, gibt es zwei Arten von Mitarbeitern, die imFolgenden kurz erklart werden.

Mitarbeiter, die keinen Vertrag besitzen (Employee) (vgl. Kapitel 6.7.2), konnenProjektleiter (projectLeader) in einem Projekt und Fachsprecher (teamLeader) ineiner Fachgruppe sein. Außerdem besitzen sie Benutzerrechte (EmployeeRole) undeinen Namen (EmployeeName). Mitarbeiter, die bereits Fachsprecher oder Projekt-leiter gewesen sind, durfen nicht geloscht werden, da beispielsweise Statistiken ubervergangene Projekte oder Fachgruppen die richtigen Projektleiter und Fachsprecherenthalten mussen. Diese werden durch Loschen eines Flags ( active) als nicht aktivgekennzeichnet. In dem Beispiel von Abbildung 63 wird dieses Flag uber die Metho-den SetActive und GetActive gesetzt bzw. gelesen.

Vertragsmitarbeiter (EmployeeWithContract) besitzen zusatzlich Vertrage. Die

93

Abbildung 63: Nachteile eines relationalen Datenmodels anhand eines Beispiels

Unterscheidung zwischen diesen beiden Mitarbeitertypen wird in dem relationalenDatenmodell uber einen Subquery realisiert, der pruft, ob der entsprechende Mitar-beiter mindestens einen Vertrag besitzt. In der Variante von Abbildung 63 ist diesemuhselige Anfrage nicht notig. Außerdem werden Mitarbeiter, die mindestens einenVertrag besitzen, beim Loschen anders behandelt. Beim Loschen wird der aktuelleVertrag beendet. In der Variante von Abbildung 63 wird diese Funktionalitat durchUberschreiben der Methoden realisiert.

In Abbildung 55 besitzt die Tabelle Employee ein Flag active. Dieses hat furVertragsmitarbeiter keine direkte Bedeutung. Um die Struktur des Datenmodellsubersichtlich zu halten, wurde diese Schwache hingenommen.

Die Datentypen der Attribute mussen atomar sein, d. h., komplexe Datentypen,wie im Klassenmodell z. B. durch Vererbung moglich sind, mussen in anderer Formabgebildet werden. Wie in Abbildung 55 zu sehen ist, ist die Unterscheidung vonMitarbeitern mit und Mitarbeitern ohne Vertrag nicht sofort ersichtlich.

Um die Trennung der Klassen Employee, EmployeeName und EmployeeRole indem relationalen Datenmodell zu realisieren, waren zusatzliche Tabellen und Fremd-schlusselverbindungen notig, welche die Mitarbeiteranfragen weiter verkomplizierenwurden.

Die Entitaten eines relationalen Datenmodells enthalten keine Funktionalitaten.Es besteht zwar die Moglichkeit, Funktionalitat uber benutzerdefinierte Routinen zudefinieren, allerdings konnen diese nicht direkt an die Entitaten gebunden werdenund nur einfache Datentypen zuruckliefern. Eine benutzerdefinierte Routine, die alle

94

Mitarbeiter zuruckliefert, die eine bestimmte Bedingung erfullen, ist beispielsweisenicht moglich.

Das Problem mit den Primarschlusseln und den Identitaten wurde bereits in Ka-pitel 6.7.5 beschrieben.

Durch die fehlende Kapselung (vgl. Kapitel 6.7.6) besteht keine Trennung vonSchnittstelle und Realisierung, d. h., Daten konnen beliebig auf allen Tabellen gean-dert werden. Komplexe Integritatsprufungen durch z. B. Trigger mussen alle denkba-ren Falle abfangen. Eine Entwicklung eines sehr großen Datenmodells von mehrerenEntwicklern ist nur mit sehr viel Aufwand moglich. Ein Datenmodell in mehrereTeile zu zerlegen und nur uber fest definierte Schnittstellen miteinander zu kommu-nizieren kann zwar vereinbart werden, wird aber in der Datenbank nicht unterstutzt.

6.8.3 Object-Oriented Database System Manifesto

Im Object-Oriented Database System Manifesto von 1995 [Atk+ 95] wurden dieAnforderungen untersucht, die eine objektorientierte Datenbank erfullen muss. DieEigenschaften lassen sich in zwei Gruppen einteilen. Zum einen wurden die Anfor-derungen an eine objektorientierte Programmiersprache und zum anderen die An-forderungen an eine Datenbank untersucht. Eine ”gute”objektorientierte Datenbanksollte all diese Anforderungen erfullen.

Objektorientierte Eigenschaften:

Komplexe Datentypen: Komplexe Datentypen mussen sich mithilfe von Kons-truktoren aus einfachen (atomaren) Datentypen, wie zum Beispiel integer,boolean oder string, zusammensetzen lassen. Des Weiteren soll es verschie-dene Arten von komplexen Konstruktoren, wie zum Beispiele Tupel, Set, Bag,Listen oder Arrays, geben. Die Objektkonstruktoren mussen orthogonal sein,d. h., jeder Konstruktor muss an jedes Objekt anwendbar sein.

Objektidentitat: Jedes Objekt muss eine eindeutige und von den Attributenunabhangige Identitat besitzen, die systemweit (oder wenigstens datenbank-weit) gultig ist. Damit konnen zwei Arten von Objektgleichheit unterschiedenwerden: identisch (das gleiche Objekt) und gleich (gleiche Werte, aber unter-schiedliche Identitat).

Kapselung: Kapselung verhindert unzulassige Zustandsanderungen und verbirgtden Implementierungsteil. Damit entsteht eine saubere Trennung zwischenSchnittstelle und Implementierung und Anderungen in der internen Strukturwerden nach außen nicht sichtbar.

95

Typen oder Klassen: Ein Typ in einem objektorientierten System fasst Objektemit gleichen Eigenschaften zusammen. Dieser besteht auf einem Interface undder Implementierung. Nach außen sichtbar ist nur das Interface und die Imple-mentierung bleibt dem Anwender diese Typs verborgen. Die Implementierungbesteht aus Daten und Funktionalitaten.Eine Klasse wird zwar genauso wie ein Typ definiert, bietet aber noch zweiweitere Aspekte: Objekterzeugung und Objektcontainer. Durch einen new -Operator werden Instanzen eines Objekts erzeugt und uber den Objektcontai-ner konnen Operationen auf einer Menge aller Objekte dieser Klasse durchge-fuhrt werden.

Vererbung: Vererbung und Klassenhierarchien sollen moglich sein, um Attributeund Methoden wiederzuverwenden, zu erweitern, zu uberschreiben oder zuspezialisieren.

Overriding, Polymorphismus und dynamisches Binden: Overloading be-deutet, dass verschiedene Methoden mit gleichem Namen und unterschiedli-chen Parametern definiert werden. Beim Aufruf einer Methoden wird anhandder Parameter entschieden, welche Implementierung verwendet wird.Durch Overriding wird dynamisches Binden moglich. In einer vererbten Klassewird eine Methode uberschrieben, d. h., die Implementierung wird geandert.Damit wird zur Laufzeit entschieden (late binding), welche Implementierungverwendet wird.

Sprach- und Berechnungsvollstandigkeit: Man kann jede berechenbare Funk-tion ausdrucken, was in SQL nicht vollstandig moglich ist.

Erweiterbarkeit von Typen: Das Datenbanksystem hat eine vordefinierte Men-ge von Datentypen, die verwendet werden konnen. Des Weiteren soll es aberauch moglich sein, neue Typen zu definieren, die nicht von den vordefiniertenTypen unterschieden werden konnen.

Datenbankeigenschaften:

Persistenz: Die Lebensdauer eines Objektes soll langer sein als die Lebensdau-er einer Applikation und soll im gleichen Zustand in einem weiteren Prozessverwendet werden konnen.

(sekundares) Datenmanagement: Sekundares Datenmanagement ist eine An-sammlung von Mechanismen, die fur den Anwender der Datenbank nicht sicht-bar sind und z. B. die Performanz verbessern sollen. Diese sind z. B. Indizie-rung, Pufferung, Zugriffsmanagement, Daten-Cluster oder Queryoptimierung.Es wird gefordert, dass der Anwender keinen zusatzlichen Code schreiben muss,um z. B. einen Index aktuell zu halten o. A., d. h., es soll eine Trennung zwi-schen der logischen und physikalischen Ebene des Systems geben.

96

Nebenlaufigkeit: Mehrere Benutzer sollen parallel auf einer Datenbank arbeitenkonnen, ohne dass es zu inkonsistenten Zustanden kommt. Diese Eigenschaftbeschreibt im Wesentlichen die Problematik, die schon in Kapitel 6.3.3 be-schrieben wurde.

Recovery: Im Falle eines Ausfalls durch einen Hardware- oder Softwarefehler,muss eine Rekonstruktion des alten und konsistenten Zustandes moglich sein.

Ad hoc Abfragemoglichkeit: Durch eine einfach Anfragesprache soll es moglichsein, Inhalte aus der Datenbank auszulesen. Die Anfragesprache sollte dabeifolgende Bedingungen erfullen:

1. Sie sollte einfach sein, bzw. es sollte moglich sein, in kurzen AnfragenInformationenen erhalten.

2. Sie sollte effizient sein (z. B. durch Query-Optimierung).

3. Sie sollte unabhangig von der Applikation sein, d. h., die Anfragesprachesollte auf jeder moglichen Datenbank gleichermaßen funktionieren.

Diese Anforderungen werden im folgenden Kapitel anhand einer objektrelatio-nalen Datenbank untersucht. Bei der objektrelationalen Datenbank wird von einerSQL-99-komformen Datenbank ausgegangen, d. h., es wird gepruft, inwieweit eineDatenbank, die diesem Standard entspricht, die gestellten Anforderungen erfullt.Den Abschluss bildet ein kurzer Uberblick uber die Moglichkeiten mit einer objek-torientierten Datenbank. Dabei bildet die Datenbank FastObjects .NET von Poetdie Grundlage.

97

7 Implementierung mit objektrelationaler Daten-

bank

7.1 Einleitung

Wahrend in der relationalen Datenbank eine strikte Trennung zwischen Daten undSemantik besteht, soll diese Trennung durch Hinzufugen weiterer Anwendungslogikin die Datenbank verringert werden. Durch die Bildung von komplexen und ge-schachtelten Datentypen konnen beliebige Strukturen gebildet werden. Zusatzlichkann Verhalten an die Tupel gebunden werden, wodurch Tupel zu Objekten im ob-jektorientierten Sinne werden. Das Ziel des objektrelationalen Datenmodells ist es,ein Klassenmodell eins-zu-eins auf das Datenmodell abbilden zu konnen. Im Idealfallexistiert die komplette (objektorientierte) Anwendungslogik in der objektrelationa-len Datenbank und nur ein einfaches grafisches Benutzerinterface wird benotigt,um Funktionalitaten auszufuhren und Daten, die gekapselt sind, abzufragen und zumanipulieren. Dabei sollen die Vorteile einer relationalen Datenbank nicht verlorengehen.

Bei der Entwicklung einer objektrelationalen Datenbank gibt es prinzipiell zweiHerangehensweisen. Die erste Moglichkeit ist die Entwicklung eines objektrelationa-len Datenmodells auf der Basis eines Klassenmodells. Dieses Thema wird in Kapitel7.5 kurz angesprochen. Der andere Weg, der hier detaillierter vorgestellt wird, be-steht darin, das relationale Datenmodell schrittweise um objektrelationale Konzeptezu erweitern.

Als Vergleichsgrundlage dient das relationale Datenmodell in Abbildung 55 ausKapitel 6.7.2 mit den Vergleichskriterien aus Kapitel 6.8.3. Wie bereits erwahntwurde, ist der SQL-99 Standard, der die objektrelationalen Konzepte enthalt, eineErweiterung des SQL-92 Standards, wodurch sich schon erahnen lasst, dass dieserziemlich umgangreich ist. Durch die Erweiterung von SQL-92 besteht in der objek-trelationalen Datenbank die Moglichkeit relationale und objektrelationale Konzeptebeliebig miteinander zu kombinieren.

Die SQL-Dialekte der real existierenden Datenbanksysteme unterstutzen die SQL-99 Norm nur in hochst unvollstandiger Form und sind zudem sehr heterogen (vgl.[Luf 02]). Eine konkrete Implementierung mit einer objektrelationalen Datenbankkonnte nicht vorgenommen werden, da die zur Verfugung stehende Informix Daten-bank 3.31 einige grundlegende Konzepte nicht unterstutzt. Aus diesem Grund wirdim Folgenden von einer SQL-99 konformen Datenbank ausgegangen. Großtenteilsbasieren die folgenden Kapitel auf den Darstellungen von [Tur 03].

Ausgehend von Kapitel 6 werden in diesem Kapitel die Erweiterungen fur dieDatendefinition (siehe Kapitel 7.2) und die daraus resultierenden Erweiterungen fur

98

die Datenmanipulation und die Datenabfrage untersucht (siehe Kapitel 7.3).

7.2 Erweiterte Datendefinition

7.2.1 Einleitung

Durch Erweiterungen des relationalen Datenmodells um Konzepte wie komplexe Da-tentypen, Methoden, Objektidentitaten, Kapselung und Vererbung sollen die Vortei-le einer relationalen Datenbank mit denen der Objektorientierung kombiniert wer-den. Im Folgenden werden die objektrelationalen Konzepte von SQL-99 vorgestellt,die dies ermoglichen. Basierend auf dem Datenmodell in Abbildung 55 aus Kapitel6.7.2 werden jeweils Beispiele vorgestellt, die zeigen, wie das relationale Datenmodellerweitert werden kann.

Benutzerdefinierte Typen und strukturierte Typen bilden die Grundlage zur De-finition von komplexen und geschachtelten Typen. Dabei werden die benutzerdefi-nierte Typen in unbenannte und benannte unterteilt.

Unbenannte Typen sind Tupeltypen, Arrays und Refererenztypen. Im Gegensatzdazu gibt es die Distinct Datentypen (vgl [Tur 03, S. 50 f.]), die, ahnlich zu demKonzept der Domanen (vgl. Kapitel 6.2.1), neue Typen definieren. Im Gegensatz zuden Domanen sind diese streng typisiert. Benutzerdefinierte Datentypen konnen alsAttribute in Tabellen definiert werden und geben somit der Tabelle mehr Struktur.

Strukturierte Typen sind klassenahnliche Typen, die durch Definition einer Ob-jektidentitat zu Klassen werden. Von diesen konnen Instanzen gebildet werden, dieahnlich den Objekten im objektorientierten Sinne sind. Die Klassen bieten das Kon-zept der Vererbung an und ermoglichen dynamisches Binden, wie in Kapitel 7.2.4beschrieben wird.

Verwaltet werden strukturierte Typen in typisierten Tabellen. Typisierte Tabel-len bilden sozusagen einen Container (vgl. [Luf 99]) fur Objekte bzw. strukturierteTypen. Durch die Definition von Referenzen in den strukturierten Typen werden diein der relationalen Datenbank verwendeten Verbunde ersetzt, d. h., auf die abhan-gigen Tabellen wird durch eine aufgeloste Referenz zugegriffen (vgl. 6.4.1).

Eine Erweiterung der Sichten des relationalen Datenmodells (vgl. 6.2.7) sinddie typisierten Sichten. Durch diese konnen Sichten auf strukturierte Typen bzw.Objekte definiert werden.

7.2.2 Distinct-Typen

Ahnlich zu dem Prinzip der Domanen definieren Distinct-Typen neue Datentypen.Fur Distinct-Typen kann keine Einschrankung definiert werden. Sie sind lediglich

99

eine Kopie des angegebenen Basistyps. Der entscheidene Vorteil ist, dass diese strengtypisiert sind. Das Konzept der Vererbung bieten Distinct-Typen nicht.

7.2.3 Unbenannte Typkonstruktoren

Definiert wird ein unbenannter Typ durch einen Typkonstruktor. Im Folgenden wer-den die drei in 7.2.1 vorgestellten unbenannten Typkonstruktoren vorgestellt.

Tupeltypkonstruktor

Durch Tupeltypkonstruktoren lassen sich Tupel bilden, die als Attribute in Tabel-len verwendet werden konnen. Logisch zusammengehorige Attribute konnen somitzusammengefasst werden und geben dem relationalen Datenmodell mehr Struktur.

Wie in Abbildung 64 zu sehen ist, konnen der Name und die Benutzerrechteeines Mitarbeiters jeweils als Tupel definiert werden. Ein Mitarbeiter besitzt dannnur noch die zwei Attribute: Name und Role. Die Gruppierung von Attributen ist,vor allem wenn es sich um Tabellen mit sehr vielen Attributen handelt, ein gutesKonzept um verstandlichere Modelle zu erzeugen. Zugegriffen wird auf die Elementeeines Tupeltyps uber die Punktnotation, wie in Abbildung 64,(5) gezeigt.

(1) CREATE TABLE Employee ((2) Name ROW( Firstname VARCHAR(50), Lastname VARCHAR(50) ),(3) Role ROW( Admin BOOLEAN, DepartLeader BOOLEAN, ... )(4) )...(5) SELECT ... FROM Employee WHERE ... Employee.Name.Firstname...

Abbildung 64: Beispiel fur Tupeltypkonstruktor

Arraytypkonstruktor

Ein weiteres Konzept der unbenannten Typkonstruktoren ist der Arraytypkons-truktor. Fur die Typen, die in einem Array enthalten sind, sind alle Elementtypenzulassig. Komplexe Datentypen und geschachtelte Arrays (vgl. [Tur 03, S. 47]) sindnicht moglich, d. h., SQL-99 ist nicht vollstandig orthogonal, so wie es in [Atk+ 95](vgl. 6.8.3) gefordert wurde.

Fur den Datenbankentwurf bedeutet dies, dass in der Entwicklung immer Aus-nahmeregeln und Sonderfalle beachtet werden mussen und die Moglichkeiten desDatenbankentwurfs eingeschrankt sind. Problematisch ist dies vor allen dann, wennein Klassenmodell in einer objektrelationalen Datenbank abgebildet werden soll (sie-

100

he Kapitel 7.5).

CREATE TABLE Employee (...Accounts VARCHAR(15) ARRAY[20]...)

Abbildung 65: Beispiel fur Arraytypkonstruktor

Die Accounts der Mitarbeiter aus der Zeiterfassung sind ein gutes Beispiel fur dieVerwendung von Arrays (vgl. Abbildung 65). Um der ersten Normalform zu entspre-chen, wurden die Accounts in eine separate Tabelle EmployeeAccount ausgelagertund uber die Fremdschlusselverbindung EmployeeID mit der Tabelle Employee ver-bunden (vgl. Abbildung 55 aus Kapitel 6.7.2). Da diese Tabelle nur ein elementaresAttribut, namlich Windowsname enthalt, kann diese als ein Array in Employee ver-wendet werden. Wie in Abbildung 65 zu sehen ist, besteht daruber hinaus die Mog-lichkeit, die Menge der Elemente in dem Array zu beschranken. Diese Beschrankungware in der relationalen Datenbank nur durch zusatzliche Integritatsbedingungenmoglich (vgl. 6.2.5).

Die Meinungen, ob es sich bei den Array und Tupeltypen um eine Verletzungder ersten Normalform handelt, gehen dabei auseinander (vgl. [Eis+ 99, S. 2] undals Beispiel [Saa 03, S. 533]). Prinzipiell bilden diese Konstrukte nur eine andereForm der Darstellung. Uber einen Unnest-Operator lasst sich ein Array wieder ineine Tabelle transformieren, wie in Abbildung 66 dargestellt ist.

Abfrage auf der Tabelle von Abbildung 55:SELECT * FROM Employee e, EmployeeAccount aWHERE e.EmployeeID=a.EmployeeID

Abfrage auf der Tabelle von Abbildung 65:SELECT * FROM Employee UNNEST(Accounts)

Abbildung 66: Beispiel fur eine SQL-Anfrage auf einem Array

Referenztypkonstruktor

Wahrend in einer relationalen Datenbank die Abhangigkeiten der Tabellen unter-einander uber Schlusselverbindungen definiert werden, besteht bei einer objektrela-tionalen Datenbank die Moglichkeit, diese uber Referenzen zu verbinden. Referenzensind, anders als Fremdschlusselverbindungen, streng typisiert und konnen nur auf

101

typisierte Tabellen angewendet werden. Das Konzept der typisierten Tabellen wirdin Kapitel 7.2.4 noch detaillierter beschrieben.

Ein Beispiel fur eine Referenz ist die Verbindung von Employee und Project(vgl. Abbildung 55 aus Kapitel 6.7.2). Wahrend in dem relationalen Datenmodelldie Projektleiter (ProjectLeader) der Projekte uber einen Verbund aus Employee undProject ermittelt werden mussen, konnen diese uber Referenzen direkt angesprochenwerden. Eine Anfrage aller Projekte mit ihren Projektleitern, die Bedingung X erful-len, konnte dann uber eine Referenzauflosung realisiert werden, wie im Beispiel vonAbbildung 67 dargestellt. Referenzen haben zum einen den Vorteil, dass dadurchQueries verstandlicher formuliert werden konnen, zum anderen sind Zugriffe uberReferenzen sehr viel effizienter, als aufwendige Verbunde uber mehrere Tabellen.

Definition in Project :COLUMN ProjectLeaderID REF(Employee) ..

Alter Query:SELECT e.Lastname as ProjectLeaderLastnameFROM Project p, Employee eWHERE p.ProjectLeaderID = e.EmployeeID AND X

Neuer Query:SELECT ProjectLeaderID->EmployeeID FROM Project WHERE X

Abbildung 67: Beispiel fur einen Referenztypkonstruktor

Dieses Beispiel ist noch relativ einfach. Bei aufwendigeren Anfragen, die sich ubermehrere Tabellen erstrecken, sieht man den Nutzen. Eine Anfrage, die beschreibt,in wie vielen Projekten der Projektgruppe X ein Mitarbeiter Y bereits Projektleiterwar, wurde dann wie in Abbildung 68 aussehen.

SELECT COUNT(*) FROM Project pWHERE p->ProjectGroupID->Name=XAND p->ProjectLeaderID->Lastname=Y

Abbildung 68: Beispiel fur die Vorteile von Zugriffen uber Referenzen

Die Beispiele bildeten jedoch nur 1:1-Beziehungen ab. Zur Realisierung einer 1:n-Beziehung muss ein Array der Große n von Referenzen gebildet werden. Abbildung69 stellt die 1:n-Beziehung zwischen Mitarbeitern und ihren Vertragen dar.

Statt einer ungerichteten m:n-Beziehung muss der Umweg uber zwei gerichtete1:n-Beziehungen gegangen werden (vgl. [Lau 01]).

102

CREATE TYPE EmployeeTypeAS (... contract REF(ContractType) Array[n] ...);

Abbildung 69: Beispiel fur 1:n-Relation

7.2.4 Strukturierte Typen

Strukturierte Typen sind ebenfalls benutzerdefinierte Typen mit einigen Erweiterun-gen (vgl. Abbildung 70). Sie entsprechen in etwa dem Konzept der Klasse und ent-halten Attribute und Methoden. Durch Vererbung ermoglichen sie das Konzept derSubstituierbarkeit. Jedes Attribut wird vom System automatisch gekapselt. Im Fol-genden wird beschrieben, wie diese Konzepte realisiert wurden und welche Schwie-rigkeiten sich dabei ergeben.

komplexe Datentypen: Strukturierte Typen konnen mehr als ein Attribut defi-nieren und jedes Attribut kann wiederum ein beliebiger Datentyp sein.

Verhalten: Das Verhalten eines strukturierten Typs kann durch Methoden, Proze-duren und Funktionen realisiert werden.

Kapselung: Fur jedes Attribut wird vom System eine Observer- und eine Muta-tormethode generiert (get- und set-Methoden).

Vererbung: Jeder strukturierte Typ kann spezialisiert und generalisiert werden.

Abbildung 70: Merkmale eines strukturierten Typs (basiert auf [Eis+ 99])

Wie in Abbildung 71 dargestellt, besteht ein strukturierter Typ aus einem Typ-namen, Attributen und Methodendeklarationen. Damit ein strukturierter Typ zueinem Objekt im objektorientierten Sinne wird, muss eine Objektidentitat definiertwerden. Es besteht zwar die Moglichkeit, diese abhangig von den Attributen odernoch schlimmer benutzerdefiniert zu definieren, da diese Einstellungen aber demGrundgedanken (vgl. [Tur 03, S. 57 f.]) einer unabhangigen und systemverwalte-ten Objektidentitat widersprechen wurden, sollten diese durch den Ausdruck ”REFIS SYSTEM GENERATED” als vom System generiert gesetzt werden (vgl. auchKapitel 6.8.3).

Ein strukturierter Typ kann von einem anderen strukturierten Typen erben undzusatzliche Attribute und Methoden definieren und Methoden uberschreiben. Da-durch wird Substituierbarkeit von strukturierten Typen moglich, d. h., uberall, woein bestimmter Typ erwartet wird, kann auch ein abgeleiteter Typ eingesetzt werden.

Attribute

103

CREATE TYPE <Typname>[UNDER <Suptertypname>]AS( <Attribute>)[[NOT] INSTANTIABLE][[NOT] FINAL][<OID-Typspezifikation>][<Methodendeklaration>]

Abbildung 71: Aufbau eines strukturierten Typs

Die Definition der Attribute erfolgt in einer ahnlichen Form wie die Definitionder Attribute in einer Tabelle. Jedes Attribut besitzt einen Namen, einen Datentypund optional einen Defaultwert.

Fur jedes Attribut werden vom System zwei Methoden erzeugt, welche die At-tribute durch so genannte Observer - und Mutator -Methoden kapseln. Das Lesenbzw. Schreiben eines Attributs wird zwar wie ein direkter Attributszugriff durch-gefuhrt, fuhrt aber intern die entsprechende Methode aus. Die Methoden konnenuberschrieben werden, wobei fur jedes Attribut genau eine Observer - und eine Mu-tator -Methode vorhanden ist. Verschiedene Sichten auf ein Attribut sind damit nichtmoglich. Dadurch dass die Observer - und die Mutator -Methoden den gleichen Na-men wie ihre Attribute besitzen, kann eigentlich nicht wirklich von Kapslung ge-sprochen werden, da Anderungen an einem Attribut die Schnittstelle nach außenverandern wurden (vgl. mit dem Punkt Kapselung aus Kapitel 6.8.3). Die einzigeForm von Kapselung, die moglich ist, ist, die Bedingungen in einer uberschriebenenMutator- oder Observermethode zu definieren.

Methoden

Die Methodendeklaration erfolgt direkt in der Definition eines strukturiertenTyps. Die dazugehorige Methodenimplementierung muss separat erzeugt werden undan den entsprechenden strukturierten Typ gebunden werden. Es gibt drei Arten vonMethoden, die jeweils mit einem entsprechenden Schlusselwort gekennzeichnet wer-den mussen: Instanzmethoden, Konstruktormethoden und statische Methoden. DieInstanz- und die Konstruktormethoden besitzen einen impliziten Self-Parameter (dieObjektidentitat oid). Neben dem Uberladen (overloading) von Methoden bestehtdie Moglichkeit, Methoden zu uberschreiben. Methoden, die uberschrieben wurden,mussen, genauso wie in C#, durch das Schlusselwort OVERRIDING gekennzeich-net werden. Substituierbarkeit und das Uberschreiben von Methoden ermoglichendynamisches Binden. Neben den Aufrufen der Methoden in anderen Methoden kon-nen diese auch direkt in den SQL-Queries verwendet werden, um zum Beispiel ineiner Where-Klausel eine Prufung vorzunehmen. Im SQL-99 werden dabei einige

104

Einschrankungen definiert, wie in Kapitel 7.3 noch beschrieben wird. Diese verhin-dern unerwunschte Seiteneffekte.

Zu jedem instanziierbaren strukturierten Typ wird ein Defaultkonstruktor ange-legt, analog zu dem Defaultkonstruktor in der Objektorientierung. Der Konstruktorliefert eine Instanz des jeweiligen strukturierten Typs zuruck. Außerdem besteht dieMoglichkeit, weitere Konstruktoren mit Parametern zu definieren.

Abstrakte und nicht weiter vererbbare Typen

Durch den Zusatz Not Instantiable kann ein strukturierter Typ als abstrakt defi-niert werden, d. h., von diesem konnen keine Instanzen gebildet werden. Allerdingskonnen keine abstrakten Methoden definiert werden.

Der Zusatz FINAL gibt an, dass von diesem Typ nicht abgeleitet werden darf,und ist vergleichbar mit dem sealed in C#.

Typprufung

Uber das Konstrukt IS OF konnen Objekte auf ihre Typen hin uberpruft wer-den, wobei mit dem Zusatz ONLY angegeben werden kann, ob genau dieser Typ(ohne seine Subtypen) oder ein Typ inklusive seiner Subtypen uberpruft wird. DasCasten eines strukturierten Typs auf einen Subtypen ist durch TREAT (<Superty-pname>) AS (<Subtypname>) ebenfalls moglich.

Soweit ist (fast) alles so, wie man es von einer objektorientierten Sprache er-wartet. Einige Konzepte, wie beispielsweise Sichtbarkeiten18 oder Interfaces, werdennicht unterstutzt. Des Weiteren besteht keine Moglichkeit, Typen in Komponentenoder Packages und damit das Datenmodell in mehrere Teilmodelle zu unterteilen.

7.2.5 Typisierte Tabellen

Eine typisierte Tabelle basiert auf einem strukturierten Typ und enthalt eine Mengevon strukturierten Typen. Gemaß [Atk+ 95] wird in einer objektrelationalen Da-tenbank zwischen (strukturierten) Typen und Tabellen (Klassen) unterschieden. InAbbildung 72 ist der Definitionsaufbau einer typisierten Tabelle vereinfacht darge-stellt.

Typisierte Tabellen konnen, genau wie strukturierte Typen, vererbt werden. Eineabgeleitete typisierte Tabelle erbt alle Attribute und Methoden und kann Metho-den uberschreiben. Die Methoden und Attribute werden durch den entsprechendenstrukturierten Typen vorgegeben. Des Weiteren konnen Attribute und Methoden

18public, private, protected

105

CREATE TABLE <Tabellenname>OF <Typname>[UNDER <Suptabellenname>]

Abbildung 72: Vereinfachter Definitionsaufbau einer typisierten Tabelle

hinzugefugt werden, wobei sich dabei ein Problem ergibt (vgl. auch [Tur 03, S. 75-79]).

Bei der Anfrage auf einer typisierten Tabelle wird zwischen flacher und tiefer Ex-tension unterschieden. Eine tiefe Extension beinhaltet alle Tupel einer Tabelle undalle Tupel der typisierten Subtabelle dieser Tabelle, wahrend die flache Extensionnur die Tupel der Supertabelle enthalt. Bildet man nun eine tiefe Extension auf einertypisierten Tabelle, die mehrere Subtabellen enthalt, so besteht keine Moglichkeit(auch durch explizites Casten nicht), auf die hinzugefugten Attribute oder Methodender Subtabellen zuzugreifen. Das Ergebnis einer tiefen - genauso wie einer flachen -Extension ist wiederum nur eine Tabelle, die Spalten und Zeilen enthalt. Neu hin-zugefugte Spalten der Subtypen erscheinen in der tiefen Extension nicht (siehe auch[Tur 03, S. 76 bis 79]).

An dem Beispiel von Abbildung 63 auf Seite 94 kann man sehen, dass durch eineflache Extension auf Employee die Menge aller Mitarbeiter zuruckgegeben wird, diekeine Vertrage besitzen. Die tiefe Extension auf Employee liefert die Menge allerMitarbeiter zuruck.

Da keine abstrakten Methoden definiert werden konnen, ist Vererbung nur in sehreingeschranktem Maß moglich. Es besteht lediglich die Moglichkeit, anstelle einerabstrakten Methode eine Methode zu definieren, die eine Exception zuruckliefert.Das Problem dabei ist, dass typisierte Tabellen prinzipiell nur Tabellen mit einerspeziellen Spalte fur die Objektidentitat sind. Die Attribute des entsprechendenstrukturierten Typs werden in Attribute einer Tabelle umgewandelt. Dadurch sinddirekte Manipulationen an den Attributen moglich, ohne dass auf die Mutator- undObserver-Methoden zugegriffen wird.

7.2.6 Typisierte Sichten

Ein weiteres Konzept sind die typisierten Sichten. Eine typisierte Sicht ermoglichteine Sicht auf ein Objekt, d. h., sie basiert auf einem strukturierten Typen und de-finiert auf diesen eine SQL-Anfrage. Im Gegensatz zu den Tupelsichten haben dieObjekte einer typisierten Sicht eine Objektidentitat und auf ihnen konnen Methodenaufgerufen werden. Außerdem kann angegeben werden, ob es sich bei der entspre-chenden Anfrage um eine flache oder eine tiefe Extension handelt.

106

Typisierte Sichten konnen vererbt werden, wobei der strukturierte Typ der Sub-sicht direkt oder indirekt von dem strukturierten Typ der basierenden typisiertenSicht abgeleitet werden muss.

Abbildung 73: Beispiel fur eine typisierte Sicht

Wie in Abbildung 73 zu sehen ist, ist ein Mitarbeiter mit Vertrag (Employee-WithContract) eine Erweiterung eines Mitarbeiters (Employee) (vgl. auch Kapitel6.8.2). Die typisierten Sichten beschranken sich darauf, dass nur Mitarbeiter zuruck-gegeben werden, die im Moment aktiv sind. Wie schon in Kapitel 6.8.2 beschriebenwurde, besitzen Mitarbeiter mit und ohne Vertrag jeweils unterschiedliche Imple-mentierungen fur die Abfrage und das Setzen des aktiven Status, wobei in diesemBeispiel nur die Abfrage (Active()) berucksichtigt wird.

Eine tiefe Extension auf der typisierten Sicht AktiveMitarbeiter liefert alle Mit-arbeiter zuruck, die im Moment aktiv sind. Dies beinhaltet auch die Mitarbeiter mitVertrag. Intern wird die SQL-Anfrage fur die typisierte Sicht AktiveMitarbeiter undalle darin enthaltenden Subsichten, in diesem Fall nur AktiveMitarbeiterMitVertrag,ausgefuhrt (vgl. [Tur 03, S. 79-84]). Eine flache Extension auf der typisierten SichtAktiveMitarbeiter liefert nur die Mitarbeiter ohne Vertrag zuruck, die im Momentaktiv sind.

7.3 Erweiterte Datenabfragen und -manipulation

Entsprechend zu der erweiterten Datendefinition wurde in SQL-99 auch die Da-tenselektion angepasst. Die Verwendung von Referenzen fuhrt dazu, dass uber dieAbhangigkeiten der Tabellen navigiert werden kann, wie schon gezeigt wurde. DieAnfragen lassen sich somit ubersichtlicher formulieren und sind leistungsfahiger, dakeine Verbunde mehr gebildet werden mussen.

107

Die Referenztypen enthalten intern die Objektidentitat des referenzierten Ob-jekts. Uber einen Pfeiloperator (vgl. mit Abbildung 67 und 68 auf Seite 102) konnenReferenzen aufgelost werden und liefern somit das referenzierte Objekt zuruck. Me-thoden werden auf ihren Referenzwerten ausgefuhrt und konnen in den SQL-Querys(fast) beliebig verwendet werden. Beispielsweise konnte eine SQL-Anfrage in ihrerWhere-Klausel einen Methodenaufruf enthalten, wie schon in Kapitel 7.2.6 beschrie-ben wurde.

Dadurch dass objektrelationale und relationale Techniken beliebig kombiniertwerden konnen, sind somit beliebig komplizierte Anfragen moglich. Bisher wurdeimmer von einer SQL-99 konformen Datenbank ausgegangen. Da die Realitat aberganz anders aussieht, ist z. Z. ein Mischen dieser beiden Techniken notig. Beispiels-weise bietet die mir zur Verfugung stehende Informix Datenbank keine Referenzenan. Es hatten sich zwar beliebig komplexe Datentypen definieren lassen, aber ent-sprechend kompliziert waren auch die Anfragen geworden.

Zur Vermeidung von unerwunschten Seiteneffekten wurden in SQL-99 einige Ein-schrankungen definiert. Beispielsweise durfen in einer Where-Klausel keine Metho-den oder sonstigen benutzerdefinierten Routinen aufgerufen werden, die Anderun-gen an den Daten vornehmen (vgl. [Tur 03, S. 256 f.]). Die Anderungen durch einUpdate-Statement werden auf eine Tabelle beschrankt, d. h., die Daten einer aufge-losten Referenz durfen nicht verandert werden.

Die Nebenlaufigkeitsprobleme, wie in Kapitel 6.3 beschrieben wurde, sind in einerobjektrelationalen Datenbank die gleichen.

7.4 Bewertung nach Datenbankmanifesto

Konzeptionell bietet SQL-99 interessante Konzepte um Objektorientierung in derrelationalen Datenbank zu ermoglichen. Im Folgenden wird das Konzept der objek-trelationalen Datenbank anhand der in Kapitel 6.8.3 geforderten Bedingungen von[Atk+ 95] untersucht.

7.4.1 Komplexe Datentypen

Wie in Kapitel 7.2 beschrieben wurde, bietet SQL-99 verschiedene Moglichkeiten, umkomplexe Datentypen zu definieren. Distinct-, Tupel-, Arraytypen ermoglichen es,mehr Struktur in das Datenmodell zu bringen. Mit den strukturierten Typen lassensich Typen bilden, die, ahnlich zu einer Klasse, mehrere Typen zu einem Typenzusammenfassen. Allerdings sind die Konstruktoren nicht vollstandig orthogonal, sowie gefordert wurde.

108

7.4.2 Objektidentitat

Durch das Konzept der strukturierten Typen und die vom System generierten Ob-jektidentitaten ist eine Unterscheidung von gleichen und denselben Objekten mog-lich. Allerdings muss diese Eigenschaft explizit definiert werden. Es besteht auch dieMoglichkeit, zustandsabhangige oder selbst definierte Objektidentitaten zu definie-ren, was aber der Idee einer Objektidentitat widerspricht.

7.4.3 Kapselung

Die Anforderung nach einer sauberen Trennung zwischen Schnittstelle und Imple-mentierung ist nicht gegeben, da keine Sichtbarkeiten definiert werden konnen undalle strukturierten Typen und Methoden prinzipiell public sind. Die Kapselung derAttribute ist auch nur in einem sehr eingeschrankten Maß gegeben, da fur jedesAttribut genau eine Mutator - und eine Observer -Methode definiert wird. Verschie-dene Sichten eines Attributs sind damit nicht moglich. Dadurch dass die Mutator-und die Observermethode den gleichen Namen wie ihre Attribute haben, wurdenAnderungen nach außen sichtbar. Die Mutator - und Observer -Methoden sind aberein geeignetes Mittel um Konsistenzprufungen vorzunehmen, d. h. eine unzulassigeZustandsubergabe abzufangen.

7.4.4 Typen- und Klassenhierarchien

Die Unterteilung von Klasen (typisierte Tabellen) und Typen (strukturierte Typen)existiert so, wie es auch gefordert wurde. Auf einer strukturierten Tabelle lassensich, wie auch auf einer einfachen Tabelle, beliebige Operationen fur eine Menge vonObjekten ausfuhren. Die geforderte Trennung zwischen Schnittstelle und Implemen-tierung eines Typs ist nicht gegeben (vgl. mit Kapselung 7.4.3).

7.4.5 Vererbung

In einem eingeschrankten Maß ist auch Vererbung moglich. Die Definition von abs-trakten Methoden ist nicht moglich. Zusatzlich definierte Attribute oder Metho-den eines strukturierten abgeleiteten Typen konnen bei einer tiefen Extension aufden Basistypen auch durch explizites Casten nicht verwendet werden (siehe Kapitel7.2.5). Ein weiteres Problem ist, dass strukturierte Tabellen nur strukturierte Ty-pen des gleichen Typs beinhalten durfen. Abgeleitete Typen mussen in abgeleitetenTabellen abgelegt werden (s. Kapitel 7.5).

7.4.6 Override, Overload und spates Binden

Overloading existiert sowohl fur Methoden als auch fur Funktionen und Prozedu-ren. Dynamisches Binden, wie in Kapitel 7.2.6 an einem Beispiel gezeigt wurde,ermoglicht es, Methoden zur Laufzeit zu ermitteln.

109

7.4.7 Sprach- und Berechnungsvollstandigkeit

Die Forderung nach Sprach- und Berechnungsvollstandigkeit ist bereits durch diein Kapitel 6.2.6 beschriebenen benutzerdefinierten Routinen gegeben. In den Me-thoden konnen dieselben Funktionalitaten wie in den benutzerdefinierten Routinenverwendet werden, womit sich alle berechenbaren Operationen ausfuhren lassen.

7.4.8 Erweiterbarkeit von Typen

Wie schon in dem Punkt Kapselung beschrieben wurde, konnen (fast) beliebigeTypen gebildet und verwendet werden. Das Typsystem von SQL-99 macht dabeikeine Unterscheidung zwischen benutzerdefinierten und vorgegebenen Typen.

7.5 Klassenmodell in objektrelationales Datenmodell trans-formieren

Basierend auf der Vorgehensweise von [Fin 02, S. 63-68] wird in diesem Kapitel einAnsatz fur eine Transformation von Klassenmodell auf objektrelationales Modellvorgestellt. Eine entsprechende Anwendung mit einer identischen Klassenstrukturwird aber auch in einem objektrelationalen Datenmodell immer notig sein, da inder objektrelationalen Datenbank kein grafisches Benutzerinterface oder irgendeineandere Schnittstelle nach außen implementiert werden kann.

Datentypen nachbilden: Zunachst mussen die benotigten einfachen Datentypenim objektrelationalen Datenmodell angelegt werden, sofern sie in der Formnoch nicht existieren.

Klassen werden zu strukturierten Typen: Klassen mit ihren Attributen wer-den zu strukturierten Typen mit einer vom System generierten Objektidenti-tat. Diejenigen Attribute, die auf eine weitere Klasse verweisen, mussen als Re-ferenzen abgebildet werden. 1:n-Beziehungen werden als Array von Referenzenmodelliert und m:n-Beziehungen werden durch zwei Beziehungen dargestellt.

Vererbung nachbilden: Die Vererbungsbeziehungen werden in strukturiertenTypen nachgebildet. Dabei sollte zu jedem strukturierten Typ eine entspre-chende strukturierte Tabelle angelegt werden. Eine strukturierte Tabelle kannnur Typen des genau gleichen Typs enthalten. Subtypen in eine strukturierteTabelle einzufugen geht nicht (vgl. [Fin 02, S. 66]). Diese mussen dann in dieentsprechende abgeleitete Tabelle (also die Tabelle des Subtypen) eingefuhrtwerden.

7.6 Zusammenfassung

Wie an den Punkten von Abschnitt 7.4 gezeigt wurde, ließen sich viele Anwendun-gen komplett in eine objektrelationale Datenbank auslagern. Das große Problem

110

ist die benotigte Abwartskompatibilitat zu SQL-92 und die damit verbundene feh-lende Kapselung. Eine großere Entwicklung mit mehreren Entwicklern wurde eineerhohte Disziplin der Entwickler erfordern, da vereinbarte Schnittstellen nicht in derDatenbank realisiert werden konnten. Die Entwicklung eines Frameworks in einerobjektrelationalen Datenbank ware beispielsweise durch die fehlenden abstraktenMethoden und die fehlenden Sichtbarkeiten nicht in der Form moglich, wie in einerobjektorientierten Programmiersprache.

Das eigentliche Problem ist aber ganz anderer Art. In den real existierendenobjektrelationalen Datenbanken werden immer nur einige der Konzepte realisiertund es ist erforderlich, dass die relationalen mit den objektrelationalen Konzeptengemischt werden. Dadurch wird die Entwicklung sehr viel aufwendiger als bei einerTrennung von relationaler Datenbank und Anwendung.

111

8 Vergleich: relationale und objektrelationale Da-

tenbank

8.1 Relationale Datenbank

8.1.1 Modellierungsmoglichkeiten und Normalisierung

Ein großes Problem beim Entwurf war die Trennung zwischen Datenmodell undKlassenmodell. Erschwerend kam noch hinzu, dass es zwei Arten von Klassenmo-dellen gab: das informative Klassenmodell aus dem Requirements Engineering (vgl.Abbildung 8 auf Seite 28 und das Klassenmodell des Entwurfs der persistenten Ob-jekte (vgl. Abbildung 26 auf Seite 51).

Um die Probleme der eingeschrankten Modellierungsmoglichkeiten zu verringern,bildete das Datenmodell die Basis fur den Entwurf und das Klassenmodell der Ana-lyse diente nur als Informationsgrundlage.

Bei der Modellierung des Datenmodells wurden bewusst einige Normalisierungs-schritte nicht vorgenommen, da diese das Datenmodell unubersichtlich gemacht unddie Tabellen nicht mehr die Entitaten der Realitat dargestellt hatten. Ein Beispiel istdas Attribut active in der Tabelle Employee (vgl. Abbildung 55 auf Seite 85), welchesfur Vertragsmitarbeiter, d. h. Mitarbeiter, die eine Verbindung zu EmployeeContractbesitzen, keine Bedeutung hat. Da der Unterschied zwischen Vertragsmitarbeiternund Mitarbeitern ohne Vertrag nicht allzu groß war, stellte diese ”Schwache” keingroßes Problem dar.

In dem Beispiel von Abbildung 74 hingegen ist dies etwas komplizierter. Die linksdargestellten Klassen lassen sich auf zwei Arten abbilden.

Die erste Moglichkeit enthalt alle Attribute, die moglich sind, d. h., in jedemDatensatz sind Daten vorhanden, die keine Bedeutung haben, so wie beispielsweisedas Attribut active in der Tabelle Employee (vgl. Abbildung 55 auf Seite 85).

Die zweite Moglichkeit besteht darin, die Klassen direkt als Tabellen abzubildenund die Vererbung durch Schlusselverbindungen zu verbinden. Der Nachteil dieserVariante ist, dass fur jede Anfrage an B oder C jeweils ein Verbund mit der TabelleA durchgefuhrt werden muss und die ursprungliche Modellierungsform nicht mehrersichtlich ist.

Ein weiteres Problem, was sich aus der Trennung von Datenmodell und Applika-tion uber die SQL- Schnittstelle ergibt, ist, dass die SQL-Queries erst zur Laufzeituberpruft werden konnen, da dies nur ein einfacher String ist. Ein vorheriges Uber-prufen, ob beispielsweise Tabellen oder Attribute der Tabelle existieren, ist nicht

112

Abbildung 74: Zwei Moglichkeiten fur Vererbung im ER-Modell

moglich. Dies ist vor allem bei Anderungen sehr aufwendig, da der entsprechendeProgrammteil, der den geanderten Query enthalt, jeweils durchlaufen werden muss.

8.1.2 Definition von Primarschlusseln

In Kapitel 6.7.5 wurde bereits das Problem mit zusammengesetzten Primarschlus-seln beschrieben.

Die Definition von technischen Schlusseln, die vom System erzeugt werden, auseinem Attribut bestehen, welches unabhangig von den Werten des Datensatzes ist,und die Definition von nicht-identifizierenden Verbindungen stellte sich als sehr vor-teilhaft heraus.

Die zweite Normalform musste nicht mehr betrachtet werden, da sie in diesemFall nicht mehr auftreten kann. Die einzige Uberprufung zur Vermeidung von Red-undanzen war die Betrachtung der Abhangigkeiten der (Nichtschlussel-)Attributeuntereinander. Ausgenommen waren dabei die Tabellen, welche m:n-Beziehungendarstellten.

Die Entitaten konnen dann nur noch uber ihre definierten Abhangigkeiten ver-bunden werden. Wie in Abbildung 60 auf Seite 91 zu sehen war, war es bei den

113

zusammengesetzten Primarschlusseln auch moglich, Tabellen miteinander zu verbin-den, die nicht direkt in Beziehung stehen, wie beispielsweise in Abbildung 60 Fach-gruppen (ProjectTeam) und Projektgruppen (ProjectGroup). In diesem Fall kannaber wiederum das Problem Phantom Read (vgl. Kapitel 6.3.3) auftreten, da dasProjekt hier nicht betrachtet wird und damit auch nicht gelockt werden kann.

8.1.3 Integritatsbedingungen

Integritatsbedingungen zwischen Entitaten werden durch Fremdschlussel realisiert.Fur komplexere Bedingungen konnen Trigger verwendet werden. Trigger haben al-lerdings den Nachteil, dass sie nur auf Ereignisse in einer Tabelle reagieren konnen,d. h., fur eine komplexere Uberprufung mussten verschiedenste Trigger definiert wer-den, um eine Integritatsbedingung zu erfullen.

Ein Beispiel ist die Uberprufung, die sicherstellt, dass Daten in den Mitarbeiter-wochen nur geandert werden konnen, wenn diese noch nicht geschlossen sind (vgl.mit dem Attribut finish in der Tabelle EmployeeWeek ist (vgl. Abbildung 55 aufSeite 85). Fur diese Uberprufung waren vier Trigger fur die folgenden Tabellen no-tig: EmployeeWeek, ProjectEmployee, TeamEmployee und ActivityEmployee.

Da diese das Datenmodell recht kompliziert machen und bei jeder Anderungmanuell mit geandert werden mussten, wurde auf die Verwendung von Triggernverzichtet.

8.1.4 Abfragemoglichkeiten und Datenmanipulation

Bei der Formulierung der Abfragen mussen alle denkbaren Abhangigkeiten mit be-trachtet werden, d. h., wenn beispielsweise eine Liste mit Projekten ermittelt werdensoll und noch nicht genau feststeht, ob die abhangigen Projektleiter wirklich benotigtwerden, so mussen diese in der Anfrage mit angeben werden. Die andere Moglich-keit ist, die geforderten Daten explizit bei Bedarf anzufordern, wobei hier sperrendeTransaktionen verwendet werden sollten.

Durch die Verwendung von Sichten konnen die Anfragen zwar erleichtert werden,aber Sichten ”verstecken” die aufwendigen Anfragen nur. Beim Erzeugen, Andernoder Loschen von Datensatzen muss wieder auf die hinter den Sichten liegenden Ta-bellen zugegriffen werden.

Das Andern, Loschen und Einfugen von Datensatzen ist pro Query nur auf eineTabelle beschrank, d. h. Operationen dieser Art, die sich uber mehrere Tabellenerstrecken, mussen in mehreren Queries formuliert werden.

114

8.1.5 Nebenlaufigkeit und Performanz

Einer der großen Vorteile einer relationalen Datenbank ist die Performanz. Wie sichaber herausgestellt hat, ist es sinnvoll, fur jede Entitat ein Attribut als Primarschlus-sel zu definieren, der unabhangig vom Zustand der Datensatze ist und vom Systembzw. von der Datenbank erzeugt wird, d. h., die Tabellen konnen nur uber ihre defi-nierten Schlusselverbindungen miteinander verbunden werden. Dadurch mussen beiden Verbund-Operationen auch genau diese Verbindungen berucksichtigt werden,wodurch aufwendige Verbunde uber mehrere Tabellen notig sind. Die Nebenlaufig-keitsprobleme habe gezeigt, dass Phantom Read durchaus zu einem Problem fuhrenkann, was nur durch Serialisieren der Transaktionen gelost werden kann. Inwieweitdie relationalen Datenbanken dann immer noch so leistungsstark sind, ist fraglich.

8.2 Verbesserungen durch eine objektrelationale Datenbank?

Bei einer Realisierung mit einem objektrelationalen Datenmodell kann das erstellteKlassenmodell sowohl fur die Anwendung als auch fur die Datenbank verwendet wer-den, d. h., umstandliche Umwandlungen oder von vornherein eingeschrankte Model-lierungstechniken sind nicht mehr notig. Die in Abbildung 74 dargestellten Klassenließen sich eins-zu-eins in einer objektrelationalen Datenbank abbilden.

Eine Businesslogik wird aber auch in einer objektrelationalen Datenbank immernotig sein, da keine Moglichkeiten fur die Gestaltung einer grafischen Benutzerober-flache oder eines anderen Interfaces gegeben sind. Der Zugriff erfolgt ebenfalls uberSQL, wobei eine Uberprufung auf syntaktische Korrektheit auch erst zur Laufzeitausgefuhrt werden kann.

Die Problematik mit den Primarschlusseln ist in diesem Fall nicht gegeben, dafur jeden strukturierten Typen eine vom System generierte Objektidentitat ermitteltwerden kann.

Die Verwendung von aufgelosten Referenzen fuhrt dazu, dass Queries einfacherformuliert werden konnen und verstandlicher sind. Des Weiteren sind keine aufwen-digen Verbundoperationen mehr notig.

Durch die Definition von Methoden in den strukturierten Typen konnen Funktio-nalitaten, die sonst nur in der Businesslogik realisiert wurden, direkt in der Daten-bank ausgefuhrt werden. Allerdings sind die Moglichkeiten nach SQL-99 im Vergleichzu einer objektorientierten Programmiersprache eingeschrankter.

Die Transaktionsprobleme sind in einer objektrelationalen Datenbank aber im-mer noch die gleichen, wobei sich durch das komplexere Datenmodell mehr Anwen-dungssemantik in die Datenbank verlagern lasst und damit weniger Queries an die

115

Datenbank notig sind.

8.3 Vergleich objektrelational zu relational zusammengefasst

relational objektrelationalFlache Strukturen VererbungPrimarschlussel Objektidentitat

Verbundoperationen aufgeloste ReferenzenTrigger und benutzerdefinierte Routinen Methoden

Sichten Objektsichten (typisierte Sichten)- eingeschrankte Kapselung

Abbildung 75: Uberblick relationale zu objektrelationaler Datenbank

Wie in Abbildung 75 zu sehen ist, bietet eine objektrelationale Datenbank imVergleich zu einer relationalen viele Vorteile. Leider ist dieser Ansatz nur Theorie,wobei sich hierbei auch die Frage stellt, ob die Vorteile einer relationalen Datenbank(vgl. Kapitel 6.8.1) in einem objektrelationalen Datenmodell immer noch gegebensind. Die Idee der objektrelationalen Erweiterung war, die Vorteile der Objektorien-tierung mit denen der relationalen Datenbank zu verbinden.

9 Zusammenfassung und Ausblick

9.1 Objektorientierte Datenbank

Einen vollig anderen Ansatz verfolgt die objektorientierte Datenbank. Sie bringt, imGegensatz zu einer objektrelationalen Datenbank, nicht die Anwendungssemantik indie Datenbank, sondern die Persistenzeigenschaften in die Programmiersprache.

Das Datenmodell kann als Klassenmodell entworfen werden und uber einen ”Zu-satz”werden automatisch Persistenzeigenschaften realisiert. Eine Moglichkeit ist derAttributemechanismus von .NET (.NET-Attribute). Dieser erlaubt es u. a., uber Re-flexion Objektinformationen zur Laufzeit zu bestimmen.

Die FastObjects Datenbank von Poet ist ein Beispiel fur eine objektorientierteDatenbank, die diesen Mechanismus verwendet. Genauso wie in einem relationalenoder einem objektrelationalen Datenbankkonzept muss hierfur eine Transaktion ge-offnet werden. In dieser Transaktion konnen Daten erzeugt, gelesen, geandert undgeloscht werden. Beim Schließen der Transaktion werden die geanderten Daten au-tomatisch auch in der Datenbank aktualisiert.

116

In Abbildung 76 ist ein Beispiel dargestellt fur die Definition eines konkretenpersistenten Objekts aus der Zeiterfassung.

(1) [Persistent](2) public class CostCenterImpl : CostCenter {(3) public CostCenterImpl(){}(4) public override string Name{...}(5) private string m OOName;(6) }

(7) IObjectScope scope(8) = FastObjects.Database.Get(<Datenbank>).GetObjectScope();(9) scope.Transaction.Begin();(10) foreach( CostCenterImpl p in scope.GetExtent( typeof(CostCenterImpl) ) )(11) // Irgendetwas mit p machen(6) scope.Transaction.Commit();

Abbildung 76: Beispiel fur eine Implementierung mit objektorientierter Datenbank

Sobald die ersten Objekte ermittelt wurden, kann auf die abhangigen Objektedirekt zugegriffen werden (Persistence by Reachability). Diese Objekte mussen nichtexplizit aus der Datenbank ausgelesen werden. In der relationalen und der objektre-lationalen Datenbank hatten dafur alle benotigten abhangigen Objekte bzw. Tupelin dem Query mit ausgelesen werden mussen.

In dem Beispiel von Abbildung 76 kann beispielsweise das Attribute m OOName(Zeile 5) uber die Property Name geandert werden. Nach dem Commit ist diese An-derung dann persistenz, ohne dass explizite Queries an die Datenbank geschicktwerden, die diese Anderung vornehmen.

Um auf Objekte zugreifen zu konnen, wurde von der ODMG-Untergruppe OMGder Standard OQL entwickelt, der, ahnlich zu SQL, eine Abfragesprache fur eineobjektorientierte Datenbank definiert. Die Syntax ist dabei sehr ahnlich zu SQL-92.Der Unterschied zu SQL ist, dass, die Anfragen auf einer Extension statt auf einerRelation formuliert werden, d. h. auf einer Menge von Objekten. Im Gegensatz zuSQL-99 liefert eine OQL-Anfrage ”echte” Objekte zuruck. Abhangige Daten konnendabei genauso wie bei SQL-99 uber Navigation angesprochen werden.

Anstelle von Events bietet die FastObjects .NET Datenbank Events an, an denensich Methoden registrieren konnen. Die auftretenden Events sind dabei die gleichenwie bei einem Trigger: Andern, Loschen, Einfugen und Lesen von Objekten.

117

Neben der pessimistischen Nebenlaufigkeitskontrolle existiert in FastObjects dieMoglichkeit, eine (automatische) optimistische Nebenlaufigkeitskontrolle zu verwen-den, die in einer relationalen oder objektrelationalen Datenbank nur durch zusatzli-che Attribute und manuell realisiert werden kann. Unter Umstanden kann es sinnvollsein, die Daten nicht unbedingt gleich zu sperren oder die Transaktionen zu serialisie-ren. Trotzdem soll aber gesichert sein, dass keine inkonsistenten Zustande auftreten.

Eine Moglichkeit, die persistenten Klassen im Klassenmodell zu kennzeichnen,konnte ein Stereotyp sein (beispielsweise persistent). Das Klassenmodell konnte inder Analyse entwickelt und im Entwurf verfeinert werden. Fur die Implementierungmuss dieses dann nicht mehr geandert werden.

Des Weiteren bietet die FastObject .NET Datenbank noch Mechanismen zumsekundaren Datenmanagement an. Recovery wird nach eigenen Angaben ebenfallsunterstutzt, d. h., im Fall eines Ausfalls wird der alte (konsistente) Zustand wiederhergestellt.

9.2 Persistenz Framework und Datenbankvergleich

Das in Kapitel 5.3 entwickelte Framework sollte einen Vergleich von relationaler undobjektrelationaler Datenbank ermoglichen. Das Problem, was hierbei bestand, war,dass durch diese Struktur von vornherein ein objektiver Vergleich ausgeschlossenist. Eines der zentralen Konzepte der relationalen Datenbank ist die Vererbung.Dadurch, dass jedes konkrete persistente Objekt und jeder konkrete Manager voneiner entsprechenden Klasse abgeleitet werden musste, war in dieser Struktur vonvornherein kein objektiver Vergleich moglich.

9.3 Entwicklungsprozess

Die Vorgehensweise, zunachst eine relationale Datenbank zu verwenden und an-schließend die gleiche Anwendung mit einer besseren Variante, wie beispielsweiseeiner objektorientierten Datenbank, zu realisieren, stellte sich ebenfalls nicht alsvorteilhaft heraus.

Folgendes Szenario soll den Grund dafur verdeutlichen:

1. Eine Anderungen der Anforderungen wird verlangt (siehe Kapitel Prototypingin Kapitel 3.1.5).

2. Diese Anderung musste (manuell) uberpruft werden (siehe Kapitel 3.2).

3. Anschließend wurden diese Anderungen (halb)automatisch in das Require-ments Document ubernommen (siehe Kapitel 3.4).

118

4. Das ERwin-Datenmodell wurde angepasst (siehe Kapitel 6.7.2).

5. Das entsprechende informative Datenmodell wurden angepasst (siehe Kapitel3.3.1).

6. Die Struktur des Persistenz-Frameworks wurde geandert (siehe Kapitel 5.3.5).

7. Diese Anderung muss in der konkreten Komponente, welche die Implementie-rung mit der relationalen Datenbank vornimmt, geandert werden.

Ware die erste Wahl fur die verwendete Datenbanktechnik eine objektorientierteDatenbank gewesen, so waren nur die ersten drei Schritte und eine Anpassung anein Klassen-/Datenmodell notig gewesen.

9.4 Zusammenfassung der wichtigsten Erkenntnisse

Im Folgenden werden die wichtigsten Erkenntnisse stichpunktartig zusammenge-fasst:

• Fur die Verwaltung der Requirements ein unterstutzendes Tool verwenden.

• Die Systemgrenzen ganz genau abgrenzen und genau definieren, wo die An-wendung nicht mehr weitermacht.

• Ein nicht unwesentliches Maß an ”Fingerspitzengefuhl”, Intuition und Erfah-rung ist beim Requirements Engineering immer notig und kann auch nichtdurch Erlernen von bestimmten Techniken ersetzt werden.

• Die Entwicklung eines Frameworks ist kompliziert, da es schwierig ist, allemoglichen Aspekte vorherzusehen.

• Die Verwendung eine Frameworks ist einfach, wenn man die Schnittstelle genaukennt.

• Das Ziel genau spezifizieren und nicht aus den Augen verlieren.

• Eine Web-Applikation besitzt nicht nur Vorteile (siehe Abbildung 29 auf Seite54).

• Bei der Modellierung mit einer relationalen Datenbank sollte auf zusammen-gesetzte Schlussel verzichtet werden. Ausnahme ist die Abbildung einer m:n-Beziehung.

119

9.5 Offene Frage

Eines der Hauptprobleme war, die verschiedenen Modellierungstechniken, wie in Ka-pitel 9.3 beschrieben, konsistent zueinander zu halten. Sowohl die Trennung nachdem Model View Controller Pattern als auch die Trennung von Datenbank und An-wendung hat Vor- und Nachteile.

Vorteile:

• Die Komponenten lassen sich einfach austauschen bzw. ersetzen.

• Eine Komponente enthalt nur einen bestimmten Aspekt eines Problems, wiebeispielsweise die Steuerung der Benutzeroberflache oder die Datenstruktur.

Nachteil:

• Es existieren redundante Informationen in den verschiedenen Modellen, d.h.,eine Anderung wird eventuell an mehreren Stellen durchgefuhrt.

Der andere Weg ware, zunachst die Anforderungen zu erheben, diese zu uberpru-fen, und erst wenn alle die Requirement ”fehlerfrei” sind, zum Entwurf uberzugehen.Das Problem ist nur, wie realistisch ist die Anforderung, dass eine Requirement ”feh-lerfrei” ist?

Existiert fur das in Abbildung 77 dargestellte Fragezeichen eine brauchbare Lo-sung?

120

Abbildung 77: Auswirkung einer Anforderungsanderung (vgl. mit Kapitel 9.3)

121

Literatur

[Ade 94] IDEF-1X - Eine Methode zur DatenmodellierungH.H. Adelsberger, F. Korner, 1994, Universitat GH Essen

[Atk+ 95] The Object-Oriented Database System Manifesto, 1995M. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier, S. Zdonikwww-2.cs.cmu.edu/People/clamen/OODBMS/Manifesto/htManifesto/Manifesto.html

[Bit Koc 00] Objektorientierte Analyse und DesignDie Fusion-Methode unter Verwendung von UML,M. Bittner und W. Koch, 2000

[CIS] NormalisierungBegleitende Folien zur Vorlesung Datenbanksysteme (DBS)im Fachbereich Computergestutzte InformationsSysteme (CIS)an der Technischen Universitat Berlin (TUB)

[Cod 70] A Relational Model of Data for Large Shared Data BanksE. F. Codd, 1970http://www.acm.org/classics/nov95/

[Con 99] Modeling Web Application Architectures with UMLRational Software White PaperJ. Conallen, Rational Software, June 1999

[Eis+ 99] SQL:1999, formerly known as SQL3A. Eisenberg, J. Melton , 1999

[Esp 04] Das ASP.NET-SeitenobjektmodellMSDN, Entwickler BibliothekD. Esposito, 2004

[Ett 99] IDEF1X VS UMLA Comparative AnalysisB.Ettlinger, 1999, Artikel aus ”The Erwin Insider”(Tips, Tricks and Articles of Interest to ERwin and BPwin Users)

[FO 04a] FastObjects .NETScript zur Schulung ”Einfuhrungs-Workshop C#”08.01.2004

[FO 04b] FastObjects .NET Programmer’s GuidePoet Software, 2004

[Fra+ 96] Delegation:Eine sinnvolle Erganzung gangiger objektorientierter ModellierungskonzepteU. Frank, S. Halter, 1996

122

[Fin 02] Anbindung objektorientierter Software an objektrelationale DatenbankenDiplomararbeit an der Universitat Hamburg im Fachbereich SoftwaretechnikM. Finsterwalder, 2002

[Geb 04] DatenbankenProf. Dr. K.F. Gebhardt, 2004

[Gli 04] Spezifikation und Entwurf von SoftwareVorlesung im WS 2003/2004 von Prof. Dr. M. Glinz (Institut fur Informatikder Universitat Zurich)http://www.ifi.unizh.ch/groups/req/courses/ses/

[GotDotNet] http://de.gotdotnet.com/quickstart/aspplus/doc/authandauth.aspx

[IDEF] IDEF Family of MethodsKnowledge Based Systems, Inchttp://www.idef.com

[IEEE610.12-1990] IEEE Standard Glossary of Software Engineering Terminology,IEEE Std.610.12-1990

[IEEE830-1998] IEEE Recommended Practice for Software Requirements Specifica-tions,IEEE Std 830-1998

[Inf 99] SQL Reference Guide, Version 6.0, 1999

[Lau 01] Object-Oriented Features of SQL:1999 Workshop-Folien,F. Laux, 2001

[Lin 01] Dynamisches Verhalten in UML Dynamisches Verhalten in UMLProf. Dr. rer. nat N. Link, WS 2001/2002, LKIT an der FH Karlsruhe

[Loh 03] Einstieg in ASP.NET,Fur Einsteiger und Umsteiger,M. Lohrer, Galileo Computing, 2003

[Luf 99] Beitrag im Informatik-Lexikon der Gesellschaft fur Informatik e.V.,J. Lufter, 1999

[Luf 02] Abbildung normkonformer objektrelationaler Sprachmittel auf reale DBMS,J. Lufter, 2003

[MSDN] Microsoft Developer Networkhttp://msdn.microsoft.com/

123

[MSDN ASP.NET] ASP.NET Technology BackgrounderMicrosoft Corporation, 2001msdn.microsoft.com/library/en-us/vbcon/html/vbconasptechnologybackgrounder.asp

[MSDN .NET Framework FAQ 01] Microsoft .NET Framework FAQMicrosoft Corporation, 2001http://msdn.microsoft.com/library/en-us/dndotnet/html/faq111700.asp

[Mos 03] Vorlesung im Institut fur Systemsoftwarean der Johannes Kepler Universitat (JKU) Linz, Osterreich”Softwareentwicklung mit C#”Institut fur Systemsoftware, Fachbereich InformatikJohannes Kepler Universitat LinzH. Mossenbock, 2003http://www.ssw.uni-linz.ac.at/Teaching/Lectures/CSharp/

[NetLexikon] Net-Lexikonhttp://www.net-lexikon.de

[Pla 03] Implementierung von Datenbanktransaktionen mit Microsoft .NET,M. Platt, 2003, Artikel aus der MSDN Entwickler Bibliothek

[ReqDoc] Requirements Dokument zu dieser DiplomarbeitC. Schweter, 2004

[Rup 01] Requirement Engineering - der Einsatz naturlichsprachlicher Methoden beider Ermittlung und Qualitatsprufung von Anforderungen,C. Rupp, Paper 2001

[Rup 02] Requirements-Engineering und -Management C. Rupp, Hanser-Verlag,2002

[Saa 03] Objektdatenbanken, 2003Gunter Saake, Can Turker, Ingo Schmitt

[Sah 00] Anforderungsanalyse fur die Werkzeugunterstutzung der Methode FUSIONund Entwurf einer BenutzungsschnittstelleB. Sahin, Diplomarbeit im Fachgebiet Softwaretechnik,Technischen Universitat Berlin, 2000

[Sch 02] Einsatz von ApplikationsservernUntersuchung am Beispiel des Sybase ”Enterprise Application Server”Diplomarbeit an der FH Brandenburg, FB Informatik und Medien,A. Schwarzbauer, 2002http://ots.fh-brandenburg.de -> abgeschlossene Diplomarbeiten

124

[Scr+ 97] Object persistence in object-oriented applicationsArtikel aus dem IBM Systems Journal, Vol. 36,V.Srinivasan, D. T. Chang

[Som 00] Software Engineering 6th EditionPowerpoint Presentations von Ian Sommervielle zum gleichnamigen Buchhttp://www.comp.lancs.ac.uk/computing/resources/SE6/Slides/

[Som Saw 97] Requirements Engineering - A good practice guideIan Sommerville und Pete Sawyer, 1997

[Tur 03] SQL:1999 & SQL:2003Objektrelationales SQL, SQLJ & SQL/XML, 2003Can Turker, 2003

[UML] UML Notation GuideOMG-Unified Modeling Language, v1.5, 2003

[ViSEK] Virtuelles Software Engineering Kompetenzzentrumhttp://www.visek.de

[Vor 99] Unterlagen zur Vorlesung Datenbanksysteme22.Juli 1999, Oliver VornbergerUniversitat Osnabruck Fachbereich Mathematik und Informatik Praktische In-formatik

125

A Requirements Document

126