A web application for human resources administration
Werbung
Diplomarbeit aus Telematik, TU Graz Institut fuer Informationsverarbeitung und Computergestuetzte neue Medien A web application for human resources administration Daniel Gschliesser i Gutachter: O.Univ.-Prof. Dr.phil. Dr.h.c Hermann Maurer Betreuer: Dipl.-Ing. Thomas Dietinger Graz, im Februar 2001 Ich versicherem, diese Arbeit selbständig verfaßt, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt und mich auch sonst keiner unerlaubten Hilfsmittel bedient zu haben. ii Danksagung Ich möchte mich an dieser Stelle bei allen Mitarbeitern des IICM, sowie der Firma SILVA System Services GmbH, die mich bei der Durchführung dieser Arbeit unterstützt haben und stets bemüht haben, meine Fragen zu beantworten, herzlich bedanken. Besonderer Dank gebührt auch meiner Freundin für ihr Vertändnis und ihre aufopfernde Hilfe. Abstract The starting point of this thesis was the need of an online tool for human resources administration of the company SILVA Services GmbH. The subject of this thesis is to describe the implementation and usage of this web based application for human resources administration. The Application gives customers the possibility to book trainers for courses online. There exists an online calender where trainers are able to enter the times they have time to train. The system tries to compute the best trainer for each customer query with that user inputs. It searches for possible dates for the course and takes care about the abilities of every trainer. Furthermore the customer is able to give some feedback to system how he liked the trainer and the course itself. These feedbacks are used for finding the proper trainer. The software design uses a three tier system model which makes the system scalable. Furthermore the implemented objects and the underlying objects can be used in other software projects later on. Zusammenfassung Ausgehend von der Problematik der Trainerverwaltung der SILVA Personaldienstleistung Ges.m.b.H wurde eine Datenbank erstellt, die alle relevanten Daten für eine human resources Verwaltung enthält. Als Front End dient ein beliebiger Web Browser. Das GUI wurde für den Microsoft IIS 4.0 und Microsoft Windows NT 4.0 entwickelt. Die Web Applikation stellt eine Verbindung zwischen Kunden und Trainern dar. Kunden können über das Internet direkt von SILVA Kurse buchen und bekommen automatisch den passenden Trainer zugewiesen. Weiters soll dieses Dokument zeigen, inwieweit das erarbeitete Konzept auf andere Anwendungsgebiete übertragbar ist. Beim Design der Software wurde insbesondere auf die Erweiterbarkeit geachtet, sodass es leicht möglich ist, eine spezielle Lösung einfach zu entwickeln. Ein weiterer Punkt ist die Verwendung von Mobiltelephonen als Eingabemedium. Die Trainer sollen die Möglichkeit haben, ihre Verfügbarbarkeit direkt über ein Handy an die Datenbank zu übermitteln. Auch der umgekehrte Weg ist möglich. Das System informiert die Trainer via SMS über neue Termine und gibt ihnen Bescheid, ob ein Kunde sie gebucht hat. Inhaltsverzeichnis 1 Einleitung 2 1.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Klassische Bewertung eines freien Mitarbeiters nach den verursachten Kosten am Beispiel der Fa. NaviConsult . . . . . . . . . . . . . . . . . . . . . . 2 Definition 2 3 4 2.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Klassische Methoden (Telefon) . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Forderungen an ein “human resources administration tool” . . . . . . . . . . 6 2.3.1 Verfügbarkeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2 Fähigkeiten “Abilities” . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 Kundenfeedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5 Datenflussdiagramme und Use Cases . . . . . . . . . . . . . . . . . . . . . . 10 2.6 Fixe Kurszeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.6.1 2.7 Diagramme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Entgültige Trainerauswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3 Algorithmus zur Trainerauswahl 15 3.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Fähigkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.1 Erste Auswahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2.2 Bewertungen des Trainers miteinbeziehen . . . . . . . . . . . . . . . 16 3.2.3 Gewichtung des Alters von Beurteilungen . . . . . . . . . . . . . . . 16 3.2.4 Definition der Einbindung der Referenzbewertung . . . . . . . . . . 19 3.2.5 Setzen von Prioritäten bei Auswahl der Kombinationen . . . . . . . 20 3.2.6 Unterschiedliche Fähigkeiten . . . . . . . . . . . . . . . . . . . . . . 20 3.2.7 Gleichmäßiges Aufteilen der Aufträge unter dem Personal . . . . . . 20 i INHALTSVERZEICHNIS ii 4 Verwendete Technologien und Produkte 4.1 4.2 4.3 4.4 22 Web Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.1 CGI (Common Gateway Interface) . . . . . . . . . . . . . . . . . . . 22 4.1.2 ISAPI (Internet Server Application Programming Interface) . . . . . 24 4.1.3 ASP (Active Server Pages) . . . . . . . . . . . . . . . . . . . . . . . 26 Business Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.2 Microsoft Transaktion Server . . . . . . . . . . . . . . . . . . . . . . 27 4.2.3 COM+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.1 ADO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.2 Microsoft SQL Server 7.0 . . . . . . . . . . . . . . . . . . . . . . . . 32 Perfomance Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.4.1 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.2 Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.3 Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.4.4 Test 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.5 Schlußfolgerungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 4.6 Entwicklungstools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5 Software Design 36 5.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2 Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.1 Objekt Relationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.2.2 OFFER.DLL - Details . . . . . . . . . . . . . . . . . . . . . . . . . . 37 6 Die Datenbank von rent@trainer 6.1 42 Erläuterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.1.1 Tabelle PLZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.1.2 Tabelle COURSEBEGINTIME . . . . . . . . . . . . . . . . . . . . . 44 7 System Requirements 46 7.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 7.2 Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8 Installation von rent@trainer 47 INHALTSVERZEICHNIS 9 Bedienung der Web Site iii 48 9.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.2 Public Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 9.3 Trainer Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 9.4 9.3.1 Ändern der persönlichen Daten . . . . . . . . . . . . . . . . . . . . . 50 9.3.2 Eintragen von Kurswünschen . . . . . . . . . . . . . . . . . . . . . . 50 9.3.3 Online Kalender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Customer Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 9.4.1 Feedback Formular . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 9.4.2 Kursinfos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 9.4.3 Die Buchung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 10 Ausblick 60 10.1 Katastrophendienste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 10.1.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 10.1.2 Bergrettung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 10.2 Interne Personalbeurteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 10.2.1 Notwendige Änderungen . . . . . . . . . . . . . . . . . . . . . . . . . 62 A Tabellen 63 B Views in der Datenbank 71 C Der Algorithmus zur Trainerauswahl 75 D Die Business Logik 78 D.1 Allgemein . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 D.2 CAL.DLL (Interface: Calendar) . . . . . . . . . . . . . . . . . . . . . . . . . 78 D.3 CUST.DLL (Interface: Customer) . . . . . . . . . . . . . . . . . . . . . . . . 81 D.4 MISC.DLL (Interface : Misc) . . . . . . . . . . . . . . . . . . . . . . . . . . 81 D.5 SEC.DLL (Interface Security) . . . . . . . . . . . . . . . . . . . . . . . . . . 83 D.6 TRAIN.DLL (Interface: Trainer) . . . . . . . . . . . . . . . . . . . . . . . . 84 D.7 BOOKINGS.DLL (Interface: Booking) . . . . . . . . . . . . . . . . . . . . . 85 D.8 OFFERS.DLL (Interface Offer) . . . . . . . . . . . . . . . . . . . . . . . . . 88 D.8.1 Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 D.9 ORDERS.DLL (Interface: ORDER) . . . . . . . . . . . . . . . . . . . . . . 89 D.10 MSG.DLL (Interface: Messager) . . . . . . . . . . . . . . . . . . . . . . . . . 89 Abbildungsverzeichnis 91 INHALTSVERZEICHNIS Tabellenverzeichnis 1 93 Kapitel 1 Einleitung 1.1 Allgemein Das Ein Lösungsansatz für das Problem von Betrieben und Institutionen geeignetes Personal effektiv zu verwalten ist der Inhalt dieses Dokuments. Der klassische Ansatz, wie es noch vielerorts gehandhabt wird, besteht in der Verwendung von Telefonisten, die die Aufgabe haben, Kundenanfragen entgegenzunehmen. Diese Person soll dann ad hoc die Trainer koordinieren und geeignetes Personal dem Kunden zur Verfügung zu stellen. Das ließ die Firma SILVA Personaldienstleistung GmbH ein Projekt initieren, dass sich mit dieser Problematik befassen sollte. Es sollte die Möglichkeit geschaffen werden, Kunden die Möglichkeit zu geben, Trainer direkt und unkompliziert buchen zu lassen. Der gewaltige Verwaltungsaufwand geeignete Trainer zu finden, soll vollautomatisiert ablaufen. Trainer können über das Internet einen Online Terminkalender zur Bekanntgabe Ihrer Verfügbarkeit benützen. Das System wertet diese Angaben aus und liefert innerhalb von Sekunden für jeden Kunden den richtigen Trainer. Dieser kann dann die so erhaltenen Angebote direkt online buchen. Umgekehrt garantiert das System durch seine Auswahlalgorithmen keinen Trainer, der gewisse Mindestanforderungen erfüllt, zu benachteiligen. Die Algorithmen wurden so entwickelt, dass im Mittel alle Trainer, deren Fähigkeiten vergleichbar sind, auch gleich oft gebucht werden. Resultat der Arbeit soll ein System sein, das eine konkrete Implementierung einer Personalverwaltung über das Internet erlaubt. Die entwickelten Komponenten sollen aber auch in anderen, vergleichbaren Szenarien einsetzbar sein. 2 KAPITEL 1. EINLEITUNG 1.2 3 Klassische Bewertung eines freien Mitarbeiters nach den verursachten Kosten am Beispiel der Fa. NaviConsult (Info: Heike Pratter, Personalwesen, 1999) Um zu zeigen, dass das Problem der Personalbeurteilung nicht nur auf die Firma SILVA beschränkt ist, wird die Vorgehensweise in der Firma NaviConsult beschrieben. Es ist zu sehen, dass die automatisierte Beurteilung noch in den Kindeschuhen steckt, bzw. nicht vorhanden ist. Die Motivation für die Entwicklung einer automatisierten “human resource” Verwaltung ist nicht nur für den konkreten Anwendungsfall “SILVA” gegeben, sondern spiegelt sich auch in anderen Firmen wieder. Die Fa. NaviConsult entwickelt EDV Systemlösungen. Im konkreten wird eine große Buchhaltungssoftware, die auch das Personalwesen abdeckt, kundenspezifisch weiterentwickelt und vermarktet. Die Fa. NaviConsult rundet Ihr Angebot durch Hardwareinstallationen für die Software, sowie Schulungen und Workshops ab. NaviConsult beschäftigt ca. 100 Mitarbeiter österreichweit. Es wird intern keine qualitative Bewertung von den freien Mitarbeitern vorgenommen, im Sinne von rent@trainer. Es werden lediglich alle Kosten, die ein Mitarbeiter verursacht auf ein eigenes projektbezogenes Konto gebucht. Diese Kosten, die auch Spesen und sonstige Aufwendungen abdecken, werden den, dem Kunden verrechneten Kosten, entgegen gestellt. Weiters wird noch festgehalten, wie viele nicht verrechenbare Stunden der Mitarbeiter bei einem Kunden gearbeitet hat. Aus den Verhältnissen “verrechenbare Stunden / Kosten” und “verrechenbare Stunden / nicht verrechenbare Stunden” wird dann eine Beurteilung des Mitarbeiters gewonnen. Zufriedenheit des Kunden und Qualität der geleisteten Arbeit gehen in diese Beurteilung nicht ein. Ein Kunde gilt als zufrieden, wenn die gestellte Rechnung akzeptiert wird. Erst bei einer Beschwerde eines Kunden wird die Qualität des Mitarbeiters näher, auch in persönlichen Gesprächen, beleuchtet. Kapitel 2 Definition 2.1 Allgemein Um über Human resources administration sprechen zu können, muss man das Problem zunächst klassifizieren. Prinzipiell geht es darum, Personal für eine bestimmte Aufgabe zu finden. Um diese Aufgabe erfüllen zu können, werden bestimmte Fähigkeiten gefordert. Neben der Kenntnis bestimmter Fähigkeiten wird noch die Verfügbarkeit der human resource gefordert. Ein dritter Punkt, der in dieser Arbeit diskutiert wird, ist das Feedback vom Kunden. Dieses Feedback muss in die Auswahl der human resource einfließen. Diese Beurteilung fällt aber nicht direkt unter den Aspekt Fähigkeiten. Aus diesem Grund wird es hier als eigener Punkt diskutiert. Diese Arbeit nimmt als Beispiel eine Schulungsfirma. Überlegungen, die direkt Bezug auf ein Schulungsunternehmen nehmen, können analog auch auf andere Bereiche übetragen werden. 2.2 Klassische Methoden (Telefon) In unserem Szenario werden Trainer, die als freie Mitarbeiter für das Schulungsunternehmen tätig sind, den Kunden vermittelt. Die Trainer stellen dann für geleistete Schulungen ein Honorar. Diese Form der Zusammenarbeit impliziert, dass die Trainer vor Ort nicht verfügbar sind. Die Trainer haben in der Regel einen weiteren Job und halten bei Bedarf Schulungen ab. D.h. die Trainer der Schulungsfirma sind auf ganz Österreich bzw. in Europa verteilt. Ein weiteres Problem neben dem Lokalitätsproblem ist die eigentliche Verfügbarkeit der Trainer. Da diese freie Mitarbeiter sind und in der Regel anderen Geschäften nachgehen, ist es 4 KAPITEL 2. DEFINITION 5 der Schulungsfirma oft nicht möglich, einen Kundenwunsch sofort positiv zu beantworten, weil sie einfach nicht weiß, ob der Trainer zu dem gegebenen Zeitpunkt auch wirklich verfügbar ist. Trainer müssen daher eine Art Verfügbarkeitsplan erstellen, an dem Sie bereit sind, Schulungen abzuhalten. Kann der Trainer an einem Tag nicht unterrichten, obwohl er sich dafür in dem Verfügbarkeitsplan eingetragen hat, so muss er dies umgehend der Zentrale melden. Dies geschieht im Allgemeinen per Telefon zwischen Tür und Angel. Damit ist für den Trainer der Fall erledigt. Er hat ja seine Verfügbarkeit oder seine “Nichtverfügbarkeit” gemeldet. Nun liegt der Ball bei dem Mitarbeiter der Schulungsfirma, der den Anruf erhalten hat. Er muss nun die Verfügbarkeit des Trainers auf dessen Plan abändern. Für diesen Plan gibt es kein EDV System, sodass hier auf dem Plan aus klassischem Papier mehr oder weniger oft herumgestrichen wird. Je länger im Voraus der Plan jetzt existiert, desto wahrscheinlicher werden auch auf diesem Termine geändert. Neben dem Problem der Verfügbarkeit muss natürlich noch die Befähigung des Trainers für die Schulung festgestellt werden. Hiezu gibt es wieder einen Plan, auf dem, vom Personalchef verifiziert, alle möglichen Schulungen für einen Trainer festgelegt sind. Eine weitere Unterteilung stellt die Sprache dar. Da die Anforderung von meist größeren Firmen besteht, die Schulungen in Englisch oder in einer anderen Sprache zu halten, ist es notwendig, festzuhalten, welcher Trainer welche Schulung in welcher Sprache halten kann. Der Mitarbeiter der Schulungsfirma muss nun anhand zweier unabhängiger Aufstellungen überprüfen, welcher Trainer für die Schulung in Frage kommt. Manuell fast unlösbar wird dieses Problem bei einer genügend hohen Anzahl an Trainern durch die Randbedingung des Terminwunsches: Schulungen gehen im Allgemeinen über mehrere Tage. Das bedeutet, dass Sonn- und Feiertage berücksichtigt werden müssen. Größte Probleme wird der Mitarbeiter der Schulungsfirma haben, wenn ein Kunde mehrere Trainer für einen Kurs buchen möchte, der über mehrere Tage dauert. In diesem Fall müssen die Trainer untereinander koordiniert werden. Die Komplexität dieser Aufgabe wird im folgenden Kapitel genauer erläutert. Ein wichtiger Aspekt in der Auswahl der Trainer ist aber noch nicht angesprochen worden. Neben der Ausbildung und rethorischen Fähigkeiten zählen auch Erfahrung und Kundenpreferenzen. War ein Kunde mit einem Trainer zufrieden, wird er den gleichen Trainer für kommende Schulungen wieder zugewiesen bekommen. Umgekehrt kann ein Kunde verlangen, dass bestimmte Trainer für ihn aufgrund schlechter Erfahrungen nicht mehr in Frage kommen. Zusammengenommen kann man festhalten, dass die oben beschriebenen Probleme ohne den Einsatz geeigneter Software nicht oder nur sehr schwer bzw. umständlich handzuhaben sind. Es wird nun versucht, obige Probleme formaler zu beschreiben und Algorithmen für KAPITEL 2. DEFINITION 6 deren Lösung anzugeben. 2.3 Forderungen an ein “human resources administration tool” 2.3.1 Verfügbarkeit Der klar scheinende Begriff “Verfügbarkeit” muss zunächst genau definiert werden. Ja nach Standpunkt, bekommt er eine unterschiedliche Bedeutung. Aus der Sichtweise des Trainers bedeutet er, die Zeit die der Trainer insgesamt zur Verfügung steht. In diesem Fall sind eventuelle Fahrzeiten mitberücksichtigt. Hat ein Trainer zum Beispiel an einem Tag von 08:00 Uhr bis 12:00 Uhr Zeit, so bedeutet das, dass die effektive Kursdauer 4h minus der Anfahrtszeit beträgt. Vom Standpunkt des Kunden aus bedeutet der Begriff Verfügbarkeit, die Zeit in der der Trainer bei ihm vor Ort ist. Wir definieren: Verfügbarkeit := reale Zeit, die die human resource zur Verfügung steht. Kundenzeit := die effektive Zeitdauer, in der die human resource dem Kunden zur Verfügung steht. Ein EDV System, dass Schulungen und Trainer verwalten soll, muss dieser Unterscheidung Rechnung tragen. In dieser Arbeit wurden die Wohnorte bzw. die momentanen Trainerschulungen gespeichert und die Entfernung daraus berechnet. Mittels einer empirisch gewählten Geschwindigkeit wurde dann die notwendige Dauer für die Anreise berechnet. Neuerdings ist es ist möglich, diese Zeitdauer auch von Routenplanern errechnen zu lassen. Hiezu benötigt man Routenplaner, die über ein geeignetes API automatisierte Abfragen zulassen. Als Geschwindigkeit wurde für diese Implementierung v := 70Km/h gewählt. Für die folgenden Betrachtungen gilt folgendes: n := Anzahl an Kalendereinträgen für alle Trainer, die in der Datenbank gespeichert sind. Ein Kalendereintrag entspricht in dieser Implementierung einer Zeitdauer, die beliebig lang sein kann. t := Anzahl der Trainer, die bei der Firma beschäftigt sind. m := Kursdauer in Tagen, diese müssen nicht aufeinanderfolgend sein. KAPITEL 2. DEFINITION 7 k := Anzahl an Trainern, die für den Kurswunsch benötigt werden. p := Zeitperiode in Tagen, in der der Kurs stattfinden soll (z.B. innerhalb eines Monats ). Die Verfügbarkeit eines Trainers wird als Liste von Kalendereinträgen gespeichert. Diese Einträge enthalten eine Start- und Endzeit. Um einen Terminwunsch zu überprüfen, muss das System diese Liste durchsuchen. Die Liste wird in einer Datenbank gespeichert, wobei diese nach der Zeit indiziert ist. Das bedeutet, die Abfrage, ob ein Trainer zu einer bestimmten Zeit zur Verfügbar ist, ist von der Ordnung [Alg98, Seite 236]: Tn = O (log (n)) (2.1) Dauert ein Kurs m Tage, so benötigt man O(m+log n) Zeit. m ist dabei gegen n sehr klein und kann in der Praxis als Konstante angesehen werden. Tm,n = O (m + log (n)) (2.2) Hat man insgesamt t Trainer zur Verfügung und benötigt man für einen Kurs k Trainer, so ergibt sich für die Komplexität: Tm,n,k,t = O t ∗ (m + log (n)) k (2.3) Fordert man vom System nun die Funktion selbständig nach freien Terminen zu suchen, wobei man als Randbedingung die Periode p vorgibt, innerhalb derer die Schulung stattfinden muss, ergibt sich für die Komplexität [Bar99, Seiten 78,79]: Tm,n,k,p,t = O p ∗ m t ∗ (m + log (n)) k (2.4) Beispiel: Die Schulungsfirma habe 100 Trainer. Für jeden Trainer existieren 100 Kalendereinträge über seine Verfügbarkeit. Ein Kunde benötige für eine Schulung, die fünf Tage dauern soll, drei Trainer. Das System soll einen Termin innerhalb von drei Wochen finden. Sei: m = 5, n = 100, p = 21, t = 100, k = 3 Dann ergebe sich nach obiger Formel T = 23.033.033.100 KAPITEL 2. DEFINITION 8 Geht man davon aus, dass eine elementare Operation (Kalenderzugriff, Vergleich, etc) 10− 6 s benötigt, dann käme man auf T = 23.033.033.100 − > 23.033, 0331s − > 6, 3h Dieser Rechnungsaufwand ist nicht vertretbar. Das Ziel eines “human administration tool” ist es, sofort reagieren zu können. Eine Wartezeit von über sechs Stunden, wie in diesem Fall, ist nicht geeignet. Ein Ziel dieser Arbeit ist es, Methoden aufzuzeigen, wie man durch Ausnützen spezieller Eigenschaften den Rechnenaufwand reduzieren kann. 2.3.2 Fähigkeiten “Abilities” Wie eingangs erwähnt, benötigt man für die positive Erledigung einer Aufgabe bestimmte Fähigkeiten. Es gilt nun, diese benötigten Fähigkeiten zu klassifizieren, sodass diese als Eigenschaften der human resource herangezogen werden können, um entscheiden zu können, ob jemand die Aufgabe erledigen kann oder nicht. Die Fähigkeit eine bestimmte Aufgabe erfüllen zu können, ist im Allgemeinen hinreichend komplex und sehr spezifisch. Dieser Umstand macht diese Fähigkeit (fast) nicht auf andere Aufgaben übertragbar. Es wird vielmehr eine Liste von Basisfähigkeiten gespeichert. Um eine Aufgabe positiv abschließen zu können, benötigt man daher auch eine Anzahl von verschiedenen Basisfähigkeiten. Besitzt eine Person alle geforderten Fähigkeiten in ausreichendem Maße, dann kann sie zur Lösung der Aufgabe herangezogen werden. Spezifische Fähigkeiten setzen sich also aus einer oder mehreren dieser Basisfähigkeiten zusammen. Diese Basisfähigkeiten sind auch leicht verwaltbar, da sie zwischen den Aufgaben austauschbar sind. Das Anforderungsprofil aller möglichen Aufgaben (z.B.: aller angebotenen Dienstleistungen) stellt sich dann als Anforderungsmatrix A dar. Die Spalten der Matrix spezifizieren die Basisfähigkeiten, die Zeilen der Matrix stellen die einzelnen Aufgaben dar. Durch Setzen der einzelnen Felder in der Matrix wird festgelegt, welche Fähigkeiten für welche Aufgabe notwendig sind. A= a11 .. . a12 .. . ··· .. . an1 an2 · · · anm a1m .. . Beispiel: Die Schulungsfirma bietet drei verschiedene Kurse in deutsch und englisch an (Zeilen): • HTML Grundkurs (Deutsch) • HTML Grundkurs (Englisch) KAPITEL 2. DEFINITION 9 • Homepage Design (Gestalten ansprechender Sites) (Deutsch) • Homepage Design (Gestalten ansprechender Sites) (Englisch) • Einführung in Macromedia Dreamweaver (Deutsch) • Einführung in Macromedia Dreamweaver (Englisch) Es werden folgende Basisfähigkeiten definiert (Spalten): • Unterrichten • HTML • Homepage Design • Macromedia Dreamweaver • Englisch • Deutsch Die Anforderungsmatrix A sieht wird dann 1 1 0 1 1 0 1 1 1 A= 1 1 1 1 0 0 1 0 0 wie folgt aus: 1 0 1 1 1 0 1 0 1 1 1 0 1 0 1 1 1 0 Bemerkenswert ist die erste Spalte. Unterrichten wird als zusätzliche Basiseigenschaft festgelegt. Das bedeutet, dass es der Firma nicht genügt, wenn sich jemand gut in HTML auskennt. Um unterrichten zu dürfen, muss er zum Beispiel pädagogische Kurse oder bereits Erfahrungen im Unterrichten gesammelt haben. Um jetzt festzustellen, ob ein Trainer für einen Kurs geeignet ist, werden einfach die Werte der entsprechenden Zeile der Anforderungsmatrix mit den Eigenschaften des Trainers verglichen. Der Trainer muss alle Fähigkeiten besitzen, die in der Zeile gesetzt sind. Die Felder der Matrix werden nun nicht mehr nur als bool’sche Werte betrachtet, sondern als Zahlenwerte. Diese Zahlenwerte geben einen Schwellwert an. Dieser Schwellwert definiert die Mindestanforderungen, die an das Personal für diese Fähigkeit für diese Aufgabe gestellt werden. Es werden die analogen Werte der Fähigkeiten immer auf 1 normiert. Die Werte der Matrix liegen also zwischen 0 (keine Kenntnis) und 1 (Top). KAPITEL 2. DEFINITION 10 Im obigen Beispiel bedeutet das, dass ein Trainer für den HTML Grundkurs grundlegende Kenntnisse in Macromedias Dreamweaver haben muss. Für den Dreamweaverkurs wird aber gefordert, dass der Trainer perfekt mit der Software umgehen kann. Für die Kurse HTML Grundkurs und Macromedia Dreamweaver (beide in Deutsch) ergibt sich folgendes: A= 0, 8 0, 9 0, 8 0, 2 0, 9 0, 2 0, 6 0 0, 8 0, 91 0 0, 8 Anmerkung: Die Werte in der Matrix stellen lediglich ein Beispiel dar und werden in der Praxis natürlich unterschiedlich sein. 2.4 Kundenfeedback Neben der eigentlichen Qualifikation spielen die individuelle Preferenzen von Kunden eine große Rolle. Kommt ein Trainer bei einem Kunden sehr gut an, dann kann es sein, dass sein Kontakt mit dem Kunden mehr wiegt als seine fachliche Qualifikation. Gerade im Trainingsbereich spielen derartige Sonderwünsche von Kunden eine große Rolle. Es wird nun versucht, diese Kundenpreferenzen mit einem Feedback-Formular zu erfassen. Der Kunde muss bestimmte Fragen zum Trainer und zum Kurs beantworten. Diese Benotung fließt nun direkt in die zukünftige Auswahl von Trainern ein. Diese Kundenfeedbacks stellen eine Art Akt über den Trainer dar. Da Einträge “ein Leben lang” gespeichert werden, muss eine Möglichkeit geschaffen werden, dass ein Trainer alte, negative Beurteilungen ausbessern kann. 2.5 Datenflussdiagramme und Use Cases Im Folgenden sollen nun die eben gemachten Überlegungen in Datenflussdiagrammen visualisiert werden. Diese Diagramme sind ein wichtiger Bestandteil beim Erstellen des Softwaredesigns. Im einfachsten Fall wird ein Trainer für einen Kurs benötigt. Für größere Projekte benötigt man jedoch meist mehr Personal. Hier genügt es nicht, obiges Schema wiederholt auszuführen, da eine erfolgreiche Antwort des Systems nur erfolgen darf, wenn die geforderte Anzahl an Personen auch zur Verfügung gestellt werden kann. Werden für einen Auftrag sieben Programmierer benötigt, es stehen aber für den angegebenen Zeitraum nur 3 zur Verfügung, so muss das System eine negative Antwort ausgeben. Außerdem müssen alle Personen zu den selben Zeitperioden Zeit haben. Diese müssen also intern koordiniert werden. Obiges Schema muss also um einen Input Parameter erweitert werden. “Count” legt fest, wie viel Personal das System für diese Anfrage suchen muss. KAPITEL 2. DEFINITION 11 [ht] Abbildung 2.1: Datenfluss für einen benötigten Trainer 2.6 Fixe Kurszeiten Im Gegensatz zum bisher beschriebenen Szenario, wo nach Verfügbarkeit der Trainer gesucht wird, und der Termin entsprechend der Verfügbarkeit des Personen angepasst wird, werden Kurse auch mit fixen Zeiten angeboten. Kunden können sich in diesem Fall in einen Kurs einschreiben. Hier wird also nicht explizit eine Anzahl von Personal für eine bestimmte Aufgabe gesucht. Die Anzahl der geforderten Trainer ergibt sich implizit aus der Anzahl der Anmeldungen für einen Kurs. Die Aufgabe des Systems liegt nun darin, eine Anmeldung zu verbuchen, oder, falls kein Trainer zur Verfügung steht, die Anmeldung zurückzuweisen. Das System muss dafür sorgen, dass das Verhältnis Trainer/Kunde in einem einstellbaren Verhältnis bleibt. Ist der Kurs mit der gegebenen Anzahl an Trainern ausgebucht, so kann das System entweder einen weiteren Trainer anfordern oder falls die maximale Kursteilnehmerzahl erreicht ist, die Anmeldung zurückweisen. Die Lösung dieser Aufgabe ist im Allgemeinen weniger komplex als das Suchen von freien Terminen für mehrere Trainer, da die Termine ja bereits vom Benutzer vorgegeben werden. Diese Termine richten sich eher nach Kundenwünschen als nach Trainerwünschen. Für die Komplexität zum Suchen eines Trainers ergibt sich aus [2.2] multipliziert mit der Anzahl der Trainer t, da die Berechnung für jeden Trainer extra gemacht werden muss. KAPITEL 2. DEFINITION 12 [ht] Abbildung 2.2: Datenfluss für mehr benötigte Trainer k := Anzahl an Trainern, die für den Kurswunsch benötigt werden. m := Kursdauer in Tagen, diese müssen nicht aufeinanderfolgend sein. n := Anzahl an Kalendereinträgen für alle Trainer, die in der Datenbank gespeichert sind. Ein Kalendereintrag entspricht in dieser Implementierung einer Zeitdauer, die beliebig lang sein kann. t := Anzahl der Trainer, die bei der Firma beschäftigt sind. Tm,n,t = O (t ∗ (m + log (n))) (2.5) Für den gesamten Kurs (bei k benötigten Trainern) ergibt sich für die Komplexität: Tm,n,k,t = O (k ∗ t ∗ (m + log (n))) (2.6) Erklärung: Bei diesem Szenario wird [2.5] für jeden Trainer hintereinander angewandt, da ja im Bedarfsfall jeweils immer nur ein Trainer benötigt wird und sich der Berechnungsaufwand für die einelnen Trainer nur addiert. KAPITEL 2. DEFINITION 2.6.1 13 Diagramme Die Randbedingungen werden vom Verantwortlichen eingangs gesetzt, bevor ein Kursangebot publik wird. [ht] Abbildung 2.3: Datenfluss für fixe Kurszeiten Der Verantwortliche legt den Kurstermin fest. Ein Kurs setzt sich dabei aus mehreren Tagen zusammen. Für jeden Tag wird die Startzeit und die Dauer festgelegt. Es ist dabei möglich, dass Tage nicht aufeinanderfolgend sein müssen. 2.7 Entgültige Trainerauswahl Die Trainerauswahl muss, wie oben beschrieben, alle drei Punkte, Verfügbarkeit, Qualifikation und Kundenfeedback in genügendem Maße berücksichtigen. Idealerweise werden beiden Parameter, Qualifikation und Kundenfeedback, derartig miteinander verknüpft, sodass ein Ranking der Trainer für diese Aufgabe entsteht. Der Algorithmus muss die beiden Parameter derartig ineinander abbilden, dass es möglich ist, eine Funktion ranking = f (f eedback, qualif iacation) (2.7) zu erhalten. Die Auswahl eines Trainers kann nun anhand dieses Rankings erfolgen. Dies bedeutet, dass jeder Kunde den für ihn optimalen Trainer erhält. KAPITEL 2. DEFINITION 14 Bei dieser scheinbar optimalen Lösung muss nun aber bedacht werden, dass ein guter Trainer immer vor einem schlechteren Trainer (ein Trainer mit einem schlechteren Ranking) ausgewählt wird. Dies hat zur Folge, dass diese schlechter beurteilten oder schlechter qualifiziertern Trainer selten zu einer Schulung kommen und daher auch keine Möglichkeit erhalten, sich zu verbessern. Umgekehrt wird ein guter Trainer aufgrund guten Feedbacks immer hoher im Ranking sein. Es kann nun aber seitens der Schulungsfirma gefordert sein, dass alle verfügbaren Trainer in gewisser Regelmäßigkeit ausgewählt werden müssen, um diese “bei Laune” zu halten. Diese Forderung steht nun zunächst im Widerspruch mit der Forderung, Kundenanfragen optimal zu lösen. Später in diesem Dokument wird eine Methode vorgestellt, die dieses Problem zu umgehen versucht. Kapitel 3 Algorithmus zur Trainerauswahl 3.1 Allgemein In diesem Kapitel soll nun die Implementierung für die gestellten Anforderungen detailiert erörtert werden. Dieser Abschnitt soll als Grundlage für alternative Implementierungen dienen. Es wird gezeigt, wie man der hohen Komplexität (Gleichung 2.4), mit geschickter Implementierung Herr werden kann. Ausserdem wird versucht, die Algorithmen derart allgemein zu halten, dass alle besprochenen Aspekte abgedeckt werden können. 3.2 3.2.1 Fähigkeiten Erste Auswahl Zunächst werden alle Trainer selektiert, die den angegebenen Kurs in der angegebenen Sprache mit einem minimalen Wissensstand MinKnowledgefaktor halten können. Diese Information wird aus der Tabelle “ABILITY” (Feld Knowledgefaktor ) geholt. Über Knowledgefaktor kann der Administrator die Qualitäten eines Trainers festlegen. Dieser Wert soll als erste Information dienen, wie der Trainer intern eingestuft wird. Durch Setzen von Knowledgefaktor hat der Administrator zum Beispiel die Möglichkeit Trainer für einen Kurs zu sperren, indem er Knowledgefaktor auf einen Wert, der unter Minknowledgefaktor liegt, setzt. Zusätzlich werden alle Trainer herausgefiltert, die die Länge der Anfahrt nicht in Kauf nehmen wollen, und dies als eine Eigenschaft in der Web Site eingetragen haben. Für alle so ermittelten Trainer wird anhand der Kalendereinträge überprüft, welcher 15 KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 16 Trainer Zeit hat. Übrig bleibt ein Anzahl von Trainern, die grundsätzlich in der Lage wären, die gestellten Anforderungen zu erfüllen. Das Ziel eines solchen automatischen Systems ist,alle Beteiligten zufrieden zu stellen. Das bedeutet, dass Kunden nur Trainer erhalten, mit denen sie bereits positive Erfahrungen gemacht haben. Weiters soll dafür gesorgt werden, dass alle Trainer möglichst gleichmäßig ausgelastet werden. 3.2.2 Bewertungen des Trainers miteinbeziehen Um die gestellten Anforderungen zu erfüllen, wurde der Ansatz eines Protokolls gewählt. In dieses Protokoll werden alle Anmerkungen den Trainer und seine Arbeit betreffend, festgehalten. Im konkreten Fall von rent@trainer ist dies ein Feedbackformular, welches die Kunden nach abgeschlossenen Kurs ausfüllen sollen. Dieses Feedbackformular wird online zur Verfügung gestellt und speichert die Angaben des Kunden unmittelbar in die Datenbank (Tabellen FEEDBACK und TRAINERFEEDBACK ). Die Beurteilung von Trainern in einem Protokoll zu speichern, bietet gegenüber einem starren Wert den Vorteil, dass die Leistungen eines Trainers über einen Zeitraum hinweg genau verfolgt werden können. Es wurde ein Algorithmus entwickelt, der ältere Beurteilungen mitberücksichtigt. Erhält ein Trainer von einem Kunden zum Beispiel ein vernichtendes Urteil, so hat er zukünftig die Möglichkeit, diese “Scharte” aus seiner Geschichte auszumerzen. Es muss noch die Notenskala der Beurteilung definiert werden. Auf der Web Site wird mit dem Schulnotensystem wegen der intuitiven Bedienung gearbeitet. Die Beurteilung muss aber laut Definition immer zwischen 0 und 1 liegen, wobei 1 die höchste Bewertung ist. Das bedeutet, dass unabhängig von der Anzeige im UI (z.B.: Schulsystem 1 bis 5) Beurteilungen intern immer zwischen 0 und 1 angenommen wird. Es muss also vom UI eine Umsetzung auf das interne Bewertungssystem vorgenommen werden (Normierung). Aus allen Beurteilungen, die ein Trainer im Verlauf seiner Laufbahn bei rent@trainer erhalten hat, wird nun ein Mittelwert gebildet. Dabei können Beurteilungen von anderen Kursen und anderen Kunden unterschiedlich gewichtet werden. Außerdem bietet sich die Möglichkeit, ältere Beurteilungen weniger ins Gewicht fallen zu lassen. Dieser gewichtete Mittelwert wird im folgenden mit “Ranking” bezeichnet. 3.2.3 Gewichtung des Alters von Beurteilungen Durch den Parameter feedbackageweight kann man die Gewichtungskurve beeinflussen. Ein Wert von 0 würde alle Beurteilungen vom Alter her gleich gewichten. Die Trainer werden in der Reihenfolge ihres Rankings für die Auswahl herangezogen. Da auch Beurteilungen anderer Kunden berücksichtigt werden, tritt das Problem auf, dass ein Trainer, der einmal von irgendeinem Kunden eine positive Beurteilung erhalten hat, immer vor einem Trainer KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 17 gereiht wird, der noch keine Beurteilung hat. Um dieses Problem zu lösen, wird einem neuen Trainer zunächst ein Standard Ranking zugeordnet. Dies soll so bemessen sein, dass ein neuer Trainer vor einem Trainer mit schlechter Bewertung, aber hinter einem Trainer mit guter Bewertung liegen wird. Dieser Standardwert wird mit der Eigenschaft “booking.EmptyRanking” festgelegt. Erhält nun ein Trainer von einem anderen Kunden eine positive Beurteilung und liegt diese auch weit zurück, falls sie die einzige ist bildet sie allein die Bewertung, da der Mittelwert eines Wertes immer der Wert selber ist, egal wie man die Gewichtung der Werte setzt. Das würde bedeuten, dass eine positive Beurteilung genügt, um vor einem Neuling gereiht zu werden. Dies wird zum Problem, da neue Trainer nur dann zum Zuge kommen würden, wenn alle anderen Trainer entweder keine Zeit oder schlechte Beurteilungen bekommen hätten. Da dieser Fall bei einem eingeschwungenen System bei ausreichender Traineranzahl im Allgemeinen nicht vorkommen wird, hieße dies effektiv, dass ein neuer Trainer überhaupt nie unterrichten könnte. Abhilfe schafft ein sogenannte Referenzbewertung, die zu den anderen Bewertungen addiert wird. Diese Referenzbewertung wird durch ihre Gewichtung, ihren Wert, sowie ihrem Datum festgelegt (Die Properties: booking.ReferenceWeight, booking.ReferenceValue und booking.ReferenceTime). Dieser Referenzwert wird nun unter dem Standard Ranking festgesetzt und wird nur wirksam, wenn ein Trainer bereits reale Beurteilungen erhalten hat. Das bedeutet, dass der Trainer zunächst einmal diese negative Referenzbeurteilung ausbessern muss, um vor einem Neuling zu gelangen. Durch geschicktes Setzen der einzelnen Parameter, kann man das System so einstellen, dass zwar eine positive Bewertung des aktuellen Kunden genügt, um vor einem Neuling zu stehen, aber mehrere Beurteilungen von anderen Kunden. er := EmptyRanking okw := OtherCustomerFeedbackWeight ocw := FeedbackOtherCoursesWeight w := FeetBackAgeWeight rw := ReferenceWeight ra := ReferenceAge rv :=ReferenceValue rd := Today d_n := Fedbackdate_n fan := FeedbackRanking für gleichen Kurs, gleichen Kunden fbn := FeedbackRanking für anderen Kurs, gleichen Kunden fcn := FeedbackRanking für gleichen Kurs, anderen Kunden fdn := FeedbackRanking für anderen Kurs, anderen Kunden KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 18 N := Anzahl der Bewertungen. raw = aw = N X n=1 [ 1 (rd − ra)w ∗ rv 1 (f an + f bn ocw + f cn okw + f dn ocw okw)] + raw rv rw (rd − dn )w ranking = PN aw 1 n=1 (rd−dn )w + raw (3.1) Erklärung: Obige Formel den im Text beschriebenen gewichteten Mittelwert dar. Die Gewichtung wird je nach Alter, Kurs und Kunde getroffen. rd − ra stellt dabei das Alter des Feedbacks in Tagen dar. Mit 1 (rd−ra)w wird nun das Alter gewichtet, wobei der Parameter w die Alterung bestimmt. Ist w = 0, so werden alle Beurteilungen unabhängig vom Alter bewertet. Im Gegensatz zu einem “normalen” Mittelwert wird hier nicht durch die Anzahl N der Gewichtungen dividiert, sondern durch die Summe der Altersgewichte selber. Der Effekt läßt sich am besten durch ein Beispiel erklären. rv=0 (Keine Referenz-Bewertung) w := 1 rd-ra := 5 (Alter der Bewertung in Tagen) N := 1 fa1 := 1 Bei einer Division durch die Anzahl N wäre Ranking = 0, 2. D.h. nur durch des Alters des Gewichtes würde der Trainer schlechter werden. Er würde mit jedem neuen Tag weiter abgewertet. Dividiert man aber durch die Summe der Altersgewichte, bleibt das Ranking konstant auf 1. Es wird also nicht allein durch das Altern verändert. Erst durch einen neues Feedback, mit einem neuen Datum, verändert die Bewertung des Trainers. Beispiel für eine solche Parameterschar: EmptyRanking := 0,7 OtherCustomerFeedbackWeight := 0,1 FeedbackOtherCoursesWeight FeetBackAgeWeight := 0,5 ReferenceWeight := 0,25 ReferenceAge := 200 Tage ReferenceValue := 0,5 := 0,5 KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 19 In diesem Fall genügt eine einzelne Bewertung des aktuellen Kunden für den aktuell geforderten Kurs von 0,75, um mit einem Neuling gleichzuziehen, falls die Bewertung ebenfalls 200 Tage zurückliegt. Sollte die Bewertung jünger sein, dann ist der Trainer schon vor einem neuen Trainer gereiht. Aber einer Bewertung von 1 eines anderen Kunden für einen anderen Kurs, die lediglich einen Monat zurückliegt, reicht nicht aus, um vor einen Neuling zu gelangen. Um die idealen Werte für rent@trainer zu finden, existiert ein Microsoft Excel Macro, mit dem man die verschiedenen Auswirkungen der Parameter leicht ausprobieren und überprüfen kann. 3.2.4 Definition der Einbindung der Referenzbewertung Der eingesetzte Referenzwert löst das Problem, dass neue Trainer nicht zum Zuge kommen würden. Betrachtet man ein eingeschwungenes System, wo alle Trainer bereits Kurse gehalten haben und bereits eine Reihe von Bewertungen protokolliert wurden, verschwindet die Wirkung des Referenzwertes, da sein Wert bei steigender Anzahl von Beurteilungen naturgemäß immer weniger ins Gewicht fällt. Mit dem Knowledgefaktor und dem Ranking bestehen also zwei Möglichkeiten einen Trainer qualitativ zu beurteilen. In der aktuellen Implementierung wird Knowledgefaktor nur als Schwellwert verwendet, unter welchem ein Trainer auf keinen Fall mehr unterrichten darf. Es ist aber auch denkbar, diesen Wert mit in das Ranking einzubeziehen. Beispielsweise könnte man den Knowledgefaktor analog der Referenzbeurteilung in die Berechnung einbeziehen. Ein anderer Ansatz wäre, Knowledgefaktor direkt als Referenzbeurteilung zu verwenden. Diese Erweiterungen ändern aber nicht das Prinzip der Beurteilungen, da man sowohl die Referenzbeurteilung als auch den Knowledgefaktor als eigene Beurteilungen speichern könnte. Man würde sich dadurch die explizite Ausführung dieser Parameter zwar ersparen, aber die Übersichtlichkeit des Algorithmus würde darunter leiden. Für die Komplexität der Berechnung des Rankings gilt: Tb,B,n = O ((b + log (B)) ∗ n) (3.2) b = Anzahl an Bewertungen des Trainers B = Anzahl aller Bewertungen aller Trainer n = Anzahl benötigter Trainer Anmerkung: log(B) ergibt sich aus dem Datenbankzugriff, welcher indiziert in O(log B) erfolgen kann. [Alg98, Seite 236] KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 3.2.5 20 Setzen von Prioritäten bei Auswahl der Kombinationen Hat man mehrere Personen zur Auswahl bleibt noch das Problem, der Möglichkeiten, Personen zu kombinieren. Es bestehen zwei Möglichkeiten durch Setzen von Prioritäten die Auswahl der Trainer zu beeinflussen. Entweder es versucht, die möglichst besten Trainer für die Auswahl zu erreichen, oder die Aufgabenstellung verlangt den ehest möglichen Termin. Je nach Aufgabenstellung muss man also zuert die Termine oder die Trainer permutieren. 3.2.6 Unterschiedliche Fähigkeiten Es sind aber auch Aufgabenstellungen denkbar, die Personal mit verschiedenen Fähigkeiten benötigen. In diesem Fall ist obiger Algorithmus für alle gewünschten Fähigkeiten wiederholt anzuwenden. Das System muss die gesammelten Ergebnisse auswerten und eine negative Antwort retournieren, falls nicht Personal mit allen geforderten Fähigkeiten gefunden werden kann. 3.2.7 Gleichmäßiges Aufteilen der Aufträge unter dem Personal Mit dem Errechnen des Rankings und der Einbeziehung eines Wissensfaktors hat man probate Werkzeuge immer den besten Trainer für einen Kurs zu finden. Die Konsequenz der Auswahl von besten Trainern ist aber der Umstand, dass Trainer mit geringeren Rankings nicht mehr für einen Kurs ausgewählt werden. Wird ein Trainer mit schlechtem Ranking nicht mehr für einen Kurs ausgewählt, so hat er aber auch nicht mehr die Möglichkeit, sein Ranking zu verbessern. Das bedeutet, dass eine einzige negative Beurteilung einen Trainer für immer aus dem Verkehr ziehen kann. Betrachtet man wieder ein eingeschwungenes System, so ergibt sich folgender Zustand: Einige wenige Trainer teilen sich alle einkommenden Aufträge unter sich auf, während andere Trainer nie gebucht werden. Trainer, die von rent@trainer nie gebucht werden, werden aber über kurz oder lang die Firma verlassen und die Konkurrenz aufsuchen, was natürlich nicht im Sinne eines Personaldienstleistungsbetriebes sein kann. Eine einfache Lösung gleichmäßiger Aufteilung wäre, alle Trainer, deren Ranking über dem Minranking liegt, nicht nach dem Ranking, sondern nach dem Datum des letzten gehaltenen Kurses zu reihen. Mit dieser Methode wäre gewährleistet, dass alle qualifizierten Trainer im Mittel gleich oft gebucht wird. Schulungsunternehmen sind in der Regel darauf bedacht, dass Kunden immer denselben Trainer zugewiesen bekommen, da sich dieser bereits mit den Gepflogenheiten des Kunden auskennt und im Allgemeinen seine Arbeit zielgerechter und dadurch effektiver durchführen kann. In der Diskussion mit Verantwortlichen von Silva stellte sich heraus, KAPITEL 3. ALGORITHMUS ZUR TRAINERAUSWAHL 21 dass diese Forderung sehr wichtig, ja erfolgskritisch für ein Schulungsunternehmen sein kann. Diese Forderung würde durch den oben beschriebenen “Ranking” Algorithmus erfüllt, jedoch steht sie im Widerspruch zu der Forderung alle Trainer gleichmäßig auszulasten. Die Lösung besteht in einer Kombination beider Algorithmen. In einem ersten Durchlauf wird nach Stammtrainern gesucht. Ein Stammtrainer ist per Definition ein Trainer, der bei einem Kunden bereits unterrichtet hat und dabei sehr hohe Bewertungen erhalten hat. Zu Qualifizierung eines Stammtrainers wird ein Stammtrainerranking herangezogen. Dieses Stammtrainerranking errechnet sich gleich dem oben beschriebenen Ranking Algorithmus mit dem Unterschied, dass othercustomerfeedbackweight auf 0 und othercoursefeedbackweight auf 1 gesetzt wird. Es werden also alle Bewertungen anderer Kunden ignoriert. Weiters wird ein neuer Schwellwert eingeführt (MinDefaultTrainerRanking). Dieser Schwellwert gibt das minimale Stammtrainerranking an, ab wann ein Trainer als Stammtrainer gewertet wird. Zu beachten ist auch, dass bei der Berechnung des Stammtrainerranking die Referenzbeurteilung nicht benötigt wird. Sollte ein Trainer einmal bei einem Kunden gewesen sein und dort gute Kritiken erhalten haben, so genügt das, um ihn wieder diesem Kunden zuzuweisen. Hier wäre es sogar ein Nachteil, das Ranking gegen einen tieferen Wert hinzugewichten, da dann unter Umständen (je nach Parametervorgabe) mehrere gute Beurteilungen notwendig sind, um einen Trainer zu einem Stammtrainer zu machen. Da die Trainerauswahl bei nicht Vorhandensein eines Trainers nicht mehr ausschließlich vom Ranking abhängt, sondern von den Buchungszeiten, würden dann mehrere Trainer abwechselnd diesem Kunden zugewiesen werden, solange bis eben einer den Status eines Stammtrainers erreicht. Erhält ein Kunde bei seinen ersten drei Buchungen aber drei verschiedene Trainer, so wird dies für seine Einstellung gegenüber dem Schulungsunternehmen nicht unbedingt positiv sein. Wird ein Trainer gefunden, dessen Stammtrainerranking höher als MinDefaultTrainerRanking ist, so wird dieser Trainer gebucht. Dieser Trainer wird unabhängig vom Datum seines letzten Einsatzes gebucht. Wird kein derartiger Trainer gefunden, so werden aus allen verbleibenden Trainern, die ja laut Ranking ebenfalls für diese Aufgabe geeignet sind, derjenige gewählt, dessen letzte Buchung am weitesten zurück liegt. Aus Performancegründen wird die Berechnung von Stammtrainer im selben Durchlauf wie das “normale” Ranking durchgeführt. (Die Daten brauchen in diesem Fall nur einmal aus der Datenbank gelesen werden) Für den Algorithmus siehe Anhang C. Kapitel 4 Verwendete Technologien und Produkte 4.1 Web Interface Aus der Vorgabe der Firma Silva eine Internet Applikation für den MS IIS zu schreiben, stellte sich zunächst die Frage nach den zu verwendeten Technologien. Grundsätzlich gibt es für den MS IIS 4.0 drei grundsätzliche Möglichkeiten, dynamische Webseiten zu generieren. 4.1.1 CGI (Common Gateway Interface) Das Common Gateway Interface (Allgemeine Vermittlungsrechner-Schnittstelle) ist eine Möglichkeit, Programme im WWW bereitzustellen, die von HTML-Dateien aus aufgerufen werden können und die selbst HTML-Code erzeugen und an einen WWW-Browser senden können. Wenn Sie im WWW eine Suchdatenbank benutzen, Pizza oder Büstenhalter bestellen, sich in ein Gästebuch eintragen, oder einen Zähler mit Zugriffszahlen sehen, dann steckt CGI oder eine CGI vergleichbare Schnittstelle dahinter. CGI - das sind Programme, die auf einem Server-Rechner im Internet liegen und bei Aufruf bestimmte Daten verarbeiten. Die Datenverarbeitung geschieht auf dem ServerRechner. CGI-Programme können auf dem Server-Rechner Daten speichern, zum Beispiel, wie oft auf eine WWW-Seite zugegriffen wurde, oder, was ein Anwender in ein Gästebuch geschrieben hat. Bei entsprechendem Aufruf kann ein CGI-Programm gespeicherte Daten auslesen und daraus HTML-Code generieren. Dieser “dynamisch” erzeugte HTML-Code wird an den aufrufenden WWW-Browser eines Anwenders übertragen und kann dort in- 22 KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 23 dividuelle Daten in HTML-Form anzeigen, zum Beispiel den aktuellen Zugriffszählerstand einer WWW-Seite oder die bisherigen Einträge in einem Gästebuch. Die sogenannte CGI-Schnittstelle muss von der WWW-Server-Software unterstützt werden. Aus Sicht des Mieters von Speicherplatz auf einem WWW-Server steht die CGISchnittstelle in Form eines bestimmten Verzeichnisses zur Verfügung. Meistens hat dieses Verzeichnis den Namen cgi-bin. In diesem Verzeichnis können Programme abgelegt werden, die CGI-Aufgaben übernehmen. Falls Sie unsicher sind, fragen Sie Ihren Provider, ob er Ihnen eine CGI-Schnittstelle zur Verfügung stellt. Bei preiswerten oder gar kostenlosen Homepage-Vermittlern wie CompuServe, AOL usw. steht Ihnen normalerweise keine CGISchnittstelle zur Verfügung. Es gibt keine Vorschriften dafür, in welcher Programmiersprache ein CGI-Programm geschrieben ist. Damit das Programm auf dem Server-Rechner ausführbar ist, muss es entweder für die Betriebssystem-Umgebung des Servers als ausführbares Programm kompiliert worden sein, oder es muss auf dem Server ein Laufzeit-Interpreter vorhanden sein, der das Programm ausführt. Wenn der Server zum Beispiel ein Unix-Rechner ist, führt er C-Programme aus, die mit einem Unix-C-Compiler zu einer ausführbaren Datei kompiliert wurden. Wenn der Server ein Windows-NT-Rechner ist, können CGI-Scripts auch EXE-Dateien sein, die mit 32-Bit-Compilern für C, Pascal, Visual Basic usw. erzeugt wurden. Die meisten heutigen CGI-Programme sind in der Unix-Shell-Sprache oder in Perl geschrieben. Die Unix-Shell-Sprache wird von allen Unix-Rechnern interpretiert. Für Perl muss ein entsprechender Interpreter installiert sein. Fragen Sie hierzu Ihren Provider. Das folgende Beispiel zeigt eine typische CGI-Situation, wie sie zum Beispiel für Suchdienste im WWW erforderlich ist. Abbildung 4.1: CGI Struktur In dem Beispiel kann der Anwender in einer angezeigten HTML-Datei in einem Formular Daten eingeben, zum Beispiel eine Suche in einer Datenbank formulieren. Nach dem Abschicken des Formulars an den Server-Rechner wird ein CGI-Programm aufge- KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 24 rufen. Das CGI-Programm setzt die vom Anwender eingegebenen Daten in eine Datenbankabfrage um. Wie das genau funktioniert, hängt von der Datenbank ab. Es gibt eine international standardisierte Datenbankabfragesprache, SQL, die hierbei sehr häufig zum Einsatz kommt. Die Datenbankanwendung liefert die Suchergebnisse an das aufrufende CGI-Programm zurück (oder schreibt sie in eine Datei, die das CGI-Programm dann auslesen kann). Das CGI-Programm erzeugt nun HTML-Code, wobei es die Suchergebnisse als Daten in den HTML-Code einbaut. Den HTML-Code sendet das CGI-Programm an den WWW-Browser, der die Suchabfrage gestartet hat. Am Bildschirm des Anwenders verschwindet die WWW-Seite mit dem Suchformular. Stattdessen erscheint eine neue Seite mit den Suchergebnissen, dynamisch generiert von dem CGI-Programm. Dies stellt die klassische Methode dar, einem Web Server Funktionalität hinzuzufügen. Vorteil dieser Methode ist die weite Verbreitung. Ein CGI ist generell auf allen Web Servern einer Plattform, die den Standard erfüllen, lauffähig. Da unter Windows NT aber fast ausschließlich der MS IIS zum Einsatz kommt, ist eine derartige Flexibilität nicht notwendig. Nachteil von CGI’s ist, dass für jeden HTTP Request ein eigener Server Prozess gestartet werden muss. Das Erzeugen eines Prozesses ist für einen Web Server eine zeitaufwendige Prozedur. Aus diesem Grund schneiden CGI’s in Performancevergleichen im Allgemeinen schlechter ab als ISAPI oder ASP Anwendungen [CT991]. Der größte Nachteil ergibt sich aber in mangelnden Möglichkeiten zum Debuggen der Anwendung während der Entwicklung. Man ist hier auf das Ausgeben von Text in Files angewiesen. Was die Entwicklungszeit drastisch erhöhen kann. 4.1.2 ISAPI (Internet Server Application Programming Interface) ISAPI ist eine Entwicklung von Microsoft, die den Nachteil von CGI’s, immer neue Prozesse starten zu müssen, kompensieren will. ISAPI Anwendungen sind DLL’s, mit standardisierten Interfaces zur Kommunikation mit dem MS IIS. Mit ISAPI startet der IIS jeweils nur einen neuen Thread für jeden Request. Das Erzeugen und Zerstören von Threads geht wesentlich schneller als das Starten von eigenen Prozessen. In der Praxis ergab sich ein Performancegewinn bei rechenintensiven Routinen bei mittlerer Serverlast von 600 %. Ein weiterer Vorteil von ISAPI ist die Möglichkeit des Debuggens. Man hat die Möglichkeit, gängige Compiler (Microsoft Visual C++ 6.0 bzw. Borland Delphi 4.03) als Host Applikationen für die ISAPI Extentions zu definieren. Durch diese Einstellung wird bei einem http Request automatisch der Debugger der verwendeten Entwicklungsumgebung gestartet und man hat die Möglichkeit , den Source Code zu debuggen. KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 25 Kommunikation zwischen ISAPI Extentions und dem IIS Der Server erzeugt eine ECB Datenstruktur. In dieser Datenstruktur werden alle relevanten Daten, die zum Handling eines Requests notwendig sind, gespeichert. Das Erzeugen dieser Datenstruktur ist natürlich viel schneller als das Erzeugen eines eigenen Prozesses, dem man die Servervariablen, etc. über den Standardinput mitgibt. Für jeden HTTP Request wird nun, wie gesagt, kein eigener Prozess gestartet, sondern nur ein neuer Thread erzeugt, was viel schneller geht. Das Konzept birgt jedoch auch Gefahren. So kann eine abstürzende DLL den ganzen Server mit in die Tiefe reißen, da ja beide im selben Prozessraum laufen. Aus diesem Grund bietet der IIS die Möglichkeit, sogenannte ”Applications” zu definieren. Applications sind in diesem Zusammenhang Gruppen von ISAPI DLL’s oder SKRIPTS (werden weiter unten behandelt). Eine Gruppe von Dateien ist ein Verzeichnis. Also kann man jedes virtuelle Verzeichnis des IIS als ”Application” definieren. Alle ISAPI DLL’S, die unter diesem Verzeichnis liegen, gehören dann zu dieser Applikation. Die wichtigste Eigenschaft so eines Applikationsverzeichnisses ist ”Run in seperate memory Space”. Dabei ist garantiert, dass eine “unhandled Exception” in einer ISAPI DLL nicht den gesamten Server zum Absturz bringt. So kann man durch Definieren mehrerer ”Application Directories” die richtige Mischung aus Performance und Sicherheit (Serverstabilität) finden. Je mehr eigene Prozessräume man definiert, desto weniger beeinflussen sich die ISAPI DLL’S. Umgekehrt müssen dann aber wiederum Prozesse erzeugt und terminiert werden, was Zeit kostet. Man hat nur dann die Möglichkeit über die Management Console alle Dll’s einer Application zu terminieren, indem der Server die ISAPI DLL’S unloaded (ISAPI Exit Function ”TerminateExtention”), wenn diese in einem eigenen Prozessraum laufen. Auch dieses wichtige Feature ist nicht über das Web Interface erreichbar, sondern nur über die Management Console. Das Problem beim Entwickeln einer ISAPI Extension ist nun aber das Debuggen. Während man beim Debuggen von simplen CGI Programmen noch über die Kommandozeile Tests durchführen kann, ist dies bei DLL’s natürlich nicht möglich. Ein weiterer Vorteil beim Debuggen von CGI Programmen ist, dass wenn ein CGI Programm abstürzt, es zwar im Speicher hängen bleibt, der Server aber trotzdem ”ungehindert” weiterläuft. Ungehindert ist deshalb nicht 100% richtig, da das hängengebliebene CGI Programm Speicher, und schlimmer noch, Rechenleistung in Anspruch nimmt. Man hat da aber immer noch die Möglichkeit, einige weitere Testläufe zu fahren, bis der Server komplett zu ist, um dann erst den Server neu zu starten bzw. mit dem MS Ressource Kit den Prozess zu killen. Bei einer ISAPI Extension muss man nach jedem fehlgeschlagenen Testlauf (die DLL hängt noch im Server Prozessraum) versuchen, den Server zu überreden, die DLL zu entladen. Nur wenn dies gelingt, kann man einen neuen KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 26 Compilerlauf starten und die alte DLL überschreiben, da sie sonst vom System als geöffnet erkannt wird und keine Schreibzugriffe auf diese Datei gestattet werden. Das Unloaden einer abgestürzten DLL funktioniert aber nicht immer, was bedeutet, dass man früher oder später um einen Reboot nicht umhinkommt. Das Laufzeitverhalten von ISAPI Anwendungen ist momentan das beste aller möglichen Techniken der Internetprogrammierung [Pro98]. Der Nachteil von ISAPI ist aber, analog zu CGI, dass keine klare Trennlinie zwischen User Interface (HTML Code) und der Funktionalität der Anwendungen möglich ist. Sollen größere Projekte zum Beispiel mehrsprachig entwickelt werden, so leidet die Wartbarkeit des entstandenen Codes erheblich. 4.1.3 ASP (Active Server Pages) ASP [MSO] schließlich ist eine Scriptsprache des IIS, die intern als ISAPI realisiert ist. Die direkte Programmierung einer ISAPI Extentions wird daher in der Regel immer schneller sein. Das UI wurde mit ASP programmiert. Die Programmierung mit Scripts bringt den Vorteil, dass das Layout der Anwendung später leichter geändert werden kann. Jedoch ist es mit ASP ab einer gewissen Komplexität nicht möglich, lesbaren Code zu schreiben. Versucht man z.B. zusätzlich zur Eingabeüberprüfung von HTML Formularen noch ein wenig Logik in die Scripts zu programmieren, so endet dieser Ansatz unweigerlich in Spaghetti Code [DevJ1]. Aus diesem Grund wurde jegliche Business Logik in COM+ Objekten realisiert. ASP bietet die Möglichkeit, sehr einfach und unkompliziert auf jegliche im System registrierten Objekte zuzugreifen. Aber auch der umgekehrte Ansatz etwas vom UI in die COM+ Objekte zu packen, birgt die Gefahr, dass Layoutänderungen später nur schwer und aufwendig zu realisieren sind [MSO2] [Bün00] [Buc00]. Aus diesem Grund war unbedingt darauf zu achten, hier eine exakte Trennlinie einzuhalten [Qui99] [Gam95]. 4.2 4.2.1 Business Layer Allgemein Scriptsprachen, wie JScript, sind aber nur bedingt dafür geeignet, komplexere Software zu erstellen. Hier hakt Microsoft ein und bietet weitere Software an, die den Entwickler hier unterstützen. Ein Ansatz, diesen Nachteil von Scriptsprachen zu umgehen, sind “ThreeTier Applications”. Gemeint ist, dass man ausgehend vom Zweischicht Modell (klassisches Client / Server), eine dritte Schicht zwischen Client und Server einzieht, die die sogenannte Business Logik beinhaltet. KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 4.2.2 27 Microsoft Transaktion Server Microsoft bietet für die Business Logic mit DCOM (Distributed Components Object Modell) auch gleich eine passende Technologie an. Man kann sogenannte DCOM Server entwickeln, die auf verschiedenen Rechnern liegen können. Diese DCOM Server übernehmen dann die Business Logik. DCOM Server sind quasi nicht sichtbare ActiveX Controls, die Methoden und Properties besitzen [Cha96]. Mit dem Option Pack wird auch der MS Transaktion Server (MTS) mit ausgeliefert. Dieser bildet eine Art Schutzhülle über DCOM Komponenten, die man entwickelt hat. Diese Schutzhülle beinhaltet eine Transaktionskontrolle auf Datenbankzugriffe, eine kompfortable Schnittstelle zur Userverwaltung von MS Windows NT, sowie eine Multi threading Umgebung. Der MTS sorgt dafür, dass man eine Komponente single threaded entwickeln kann, diese erscheint aber nach außen hin wie eine Multi Threaded Anwendung. Dies erlaubt kleine überschaubare Komponenten zu entwickeln, und diese dann z.B. mit JScript zu einer größeren Applikation zu verbinden. Der Einsatz von solchen kleinen überschaubaren Komponenten kann einem das Entwicklerleben sehr erleichtern. 4.2.3 COM+ Mit Windows 2000 wurde die MTS Technologie von COM Objekten neuerlich überarbeitet. COM+ wurde dafür ausgelegt, bestehende Investitionen in COM, MTS und andere COM-basierte Applikationen zu nutzen und möglichst leicht erweitern zu können. Es wird erstmalig in Windows 2000 enthalten sein. Auch in COM+ werden Dienste in Form von Komponenten verwaltet. Der Zugriff und die Kontrolle dieser werden hier komplett vom Server übernommen. Dazu wurde ein “Interception” -Mechanismus eingeführt. Im Unterschied zum “einfachen” COM, wo Server und Client auf demselben Rechner angesiedelt waren (Abbildung 4.2), ist es mit COM+ ohne weiteres möglich, Dienste auf anderen Rechnern zu nutzen. Früher wurde dies mittels “Remote Procedure Call” (RPC) gelöst. (Abbildung 4.3) Der MTS erweiterte dieses RPCPrinzip um eigene Kontext-Wrapper auf der Serverseite, welche Sicherheitsüberprüfung übernahmen. (Abbildung 4.4) [DNJ100, Seite 55-56]. COM+ führt zur Sicherheitsüberprüfung sogenannte “Policy-Objekte” ein, wodurch die Kontext-Wrapper des MTS entfallen. Diese Policy-Objekte werden sowohl auf Client- als auch auf Serverseite plaziert, wo sie die bereits oben erwähnten Interceptions durchführen können. Wie das ganze dann schematisch aussieht, zeigt die Abbildung 4.5. Alle angebotenen Dienste müssen in COM+ als Applikation angemeldet werden. Es werden dabei 2 Arten von Applikationen unterschieden. Zum ersten wäre da die Serverapplikation, was bedeutet, dass die Komponente zur Laufzeit in einen vom Client getrenn- KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 28 Abbildung 4.2: Eine direkte Verbindung zu einem Objekt auf dem gleichen Computer, im gleichen Adressraum und Apartment wie der Client Abbildung 4.3: Eine indirekte Proxy/Stub-Verbindung zu einem Objekt, das an einem anderen Ort existiert ten Adressraum auf dem Server oder einem anderen beliebigen Rechner ausgeführt wird. (Abbildung 4.6) Die zweite Form ist die Bibliotheksapplikation, bei der die Komponente im Adressraum des Client ausgeführt wird.(Abbildung 4.7) Wird von COM+ nun ein bestimmter Dienst angefordert, muss zunächst das entsprechende Objekt erstellt werden. Dazu wird zuerst geprüft, ob der geforderte Dienst überhaupt registriert ist. Hierzu wird der interne COM+ Katalog nach der gewünschten Komponente durchsucht. Wurde die Komponente gefunden, wird sie gemäß ihren Eigenschaften (Bibliotheks- oder Serverapplikation) gestartet. Danach kann der Interceptor eingerichtet werden. Anschließend wird auf der Clientseite ein Proxy inklusive eines RPCKanals eingerichtet. Zuletzt wird dem Client ein Zeiger auf den Proxy zurückgegeben. Für das Beenden einer Applikation ist der Server verantwortlich; das Verhalten kann vom Administrator eingestellt werden (z.B.: App. niemals beenden, App. nach xx Minuten beenden, usw.). Hier noch ein paar Bemerkungen zum oben erwähnten COM+ Katalog. Der Katalog stellt eine Systemdatenbank dar, in welcher alle registrierten Applikationen mit ihren Komponenten gespeichert werden können. Arbeiten kann man mit diesem Katalog über sogenannte Dienstobjekte, welche unter anderem auch Skriptverarbeitung anbieten. Zugriff auf die oberste Ebene des Kataloges bekommt man durch die Verwendung der Komponente COMAdmin (ist in COM+ enthalten). KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 29 Abbildung 4.4: Ein Kontext-Wrapper als eine separate Schicht im Microsoft Transaction Server Abbildung 4.5: Interception durch Policy-Objekte Zuletzt noch ein paar Worte zur Sicherheit in COM+. Früher war die Erstellung von guten Sicherheitscode schwierig und teuer. Heute kann man diese Aufgabe voll und ganz COM+ überlassen, es kann die Sicherheitsinfrastruktur ererbt werden. Zu den angebotenen Diensten zählen die Authentifizierung und die Autorisierung. Die Authentifizierung wird vom “Security Support Provider” (SSP) im Betriebssystem bereitgestellt. Er stellt dazu verschiedene Authentifizierungsebenen bereit, die angeben, wie umfangreich das Sicherheitssystem arbeiten soll. Auf die einzelnen Ebenen soll an dieser Stelle nicht weiter eingegangen werden. Die Autorisierung ist natürlich abhängig von der Authentifizierungsebene. Ist sie beispielsweise auf NONE eingestellt, entfällt die Autorisierung komplett. Die Autorisierung selbst wird über sogenannte “Rollen” abgewickelt, wobei Rollen anwendungsbezogene Benutzergruppen sind. Die neue Bezeichnung derartiger Objekte lautet nun COM+. Die herausragende Neuerung von COM+ ist, die Tatsache COM Objekte kontektbezogen zu entwickeln. Das bedeutet, dass sich ein COM Objekt bei entsprechender Implementierung je nach aufrufender Applikation anders verhalten. Das Objekt verändert also sein Verhalten, wenn es z.B. über KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 30 Abbildung 4.6: Eine Serverapplikation, die in einem separaten Adressraum ausgeführt wird Abbildung 4.7: Eine Bibliotheksapplikation, die im Adressraum der Clientanwendung ausgeführt wird den IIS aus dem Internet aufgerufen wird. Wird es von VBA aus Microsoft Excel aufgerufen, dann können andere Eigenschaften des Objektes zum Vorschein kommen. 4.3 4.3.1 Datenbank ADO Ob Veranstaltungskalender, Produktkatalog, Mitgliederdatenbank, Gästebuch, personalisierte Dienste oder allgemein veränderliche Daten - all dies läßt sich mit Hilfe der Kombination ASP Skripts auf der Webserver Seite und einer Datenbank auf der anderen Seite verwirklichen. Betrachten wir einmal das Bindeglied zwischen diesen beiden Technologien näher. Von ASP aus greift man am einfachsten über ADO (ActiveX Data Objects) und das zugehörige ADODB Objekt auf Datenquellen zu. Die Verbindung zwischen ADO (und der darunterliegenden OLE DB, Object Linking and Embedding Database) und der Datenbank wird meist über ODBC (Open DataBase Connectivity) hergestellt, das Applikationen einen weitgehend einheitlichen Zugriff auf verschiedenste Datenquellen erlaubt [Kol00] [MSO2]. ADO stellt die Objekte zur Verfügung, mit deren Hilfe ein ASP Skript eine Verbindung zur Datenbank aufbauen und Daten auf vielfältigste Weise manipulieren kann. KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 31 Die wichtigsten ADO Objekte sind: • Connection (Datenbankverbindung) - Repräsentiert die Verbindung zur Datenquelle . • Recordset (Sammlung von Datensätzen) - Besteht aus den Datensätzen die aus einer Datenbankabfrage stammen und dem zugehörigen Cursor, der auf den aktuellen Datensatz zeigt. • Field (Datenfeld) - Enthält Daten einer Datenbankspalte und Informationen über diese Daten wie Datentyp, Datenlänge und Ähnliches. Das Recordset Objekt stellt dabei die Fields Collection zur Verfügung, die alle Field Objekte eines Datensatzes beinhaltet. • Property (Eigenschaft) - Erlaubt den Zugriff auf dynamische Informationen eines ADO Objektes, die von der Datenquelle oder der Datenanbindung (wie ODBC) zur Verfügung gestellt werden. • Error (Fehler) - Enthält ausführliche Fehlerinformationen bei Datenbankzugriffen. Auf alle Fehler eines Datenbankzugriffes kann durch die Errors Collection zugegriffen werden. • Command (Befehl) - Erlaubt es, einzelne Datenbankabfragen zu definieren, sodass ein mehrmaliger Einsatz mit verschiedenen Parametern rascher durchgeführt werden kann . • Parameter (Parameter) - Stellt einen einzelnen Parameter (Argument) eines Command Objektes für eine parametrisierte Abfrage oder einen Zugriff auf eine “Gespeicherte Datenbankprozedur” dar. Wie sieht nun eine einfache Datenbankabfrage aus? Das folgende ASP Skript öffnet eine Verbindung zur Nordwind Datenbank, die mit Microsoft Access 97/2000 und SQL Server 7.0 (deutsche Versionen) ausgeliefert wird. Weiters liest es die Datensätze der Tabelle Artikel aus, die in die Kategorie Meeresfrüchte fallen, um die Werte der Spalten ArtikelNr und Artikelname schließlich im Browser anzuzeigen. <% Response.Expires=0 Response.AddHeader ’’Pragma’’,’’no-cache’’ Response.AddHeader ’’cache-control’’, ’’no-store’’ Response.Write ’’Abfrageergebnis:<br>’’ & vbcrlf Set conn = Server.CreateObject(’’ADODB.Connection’’) KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 32 conn.Open ’’DSN=NW;USR=sa;PWD=’’ strSQL = ’’SELECT Artikel.[Artikel-Nr], Artikel.Artikelname ’’ strSQL = strSQL & ’’FROM Artikel INNER JOIN Kategorien ’’ strSQL = strSQL & ’’ON Artikel.[Kategorie-Nr]=Kategorien.[Kategorie-Nr] ’’ strSQL = strSQL & ’ ’WHERE Kategorien.Kategoriename = ’Meeresfrüchte’ ’’ Set rs = conn.Execute(strSQL) Do While Not(rs.EOF) Response.Write ’’’’ & rs(’’Artikel-Nr’’) & ’’ : ’’ Response.Write ’’’’ & rs(’’Artikelname’’) & ’’<BR>’’ & vbcrlf rs.MoveNext Loop rs.Close conn.Close %> 4.3.2 Microsoft SQL Server 7.0 Für die Entwicklung des Datenbank Back end’s wurde MSDE gewählt. MSDE ist im MS Office 2000 Paket enthalten und bietet SQL Kompatibilität zum MS SQL Server 7.0. Außerdem benötigt die MSDE weniger Hardwaressourcen, was ebenfalls ein Kostenfaktor ist. Aufgrund der 100% Kompatibilität zum MS SQL Server 7.0 lässt sich das System leicht durch einen einfachen Upgrade der Datenbankengine skalieren. Bei der Entwicklung wurde darauf geachtet, möglichst wenig herstellerspezifische SQL Statements zu verwenden. Dies sollte es leicht möglich machen, gegebenenfalls gegen einen anderen SQL Server zu fahren. Durch die Verwendung von ADO 2.1 ist es aber auch leicht möglich, die Software dahingehend zu ändern, dass gegen jede relationale Datenbank (SQL) gefahren werden kann. Bei der Verwendung von Windows 2000 als Betriebssystem kommt ADO 2.5 zur Anwendung. 4.4 Perfomance Vergleich ISAPI wurde eingeführt, um CGI Programme zu beschleunigen. Die Frage ist nun, wie es mit der Performance im Vergleich mit ASP steht. Als erstes, weil dies ein Kernbereich der Untersuchungen darstellt, wurde der Zugriff auf eine Tabelle einer Relationalen Datenbank getestet. KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE Task ASP ISAPI Default Einstellungen 9sec 20sec Isolated Process* 22sec 21sec Buffer ASP Pages** 6sec - 33 Tabelle 4.1: Ergebnisse Test 1 4.4.1 Testumgebung • AMD K6 166 • 32MB Ram • NT Server+Optionpack installiert (IIS 4.0) • MS SQL Server Server installiert • MS Office 97 installiert • 10BaseT Netzwerk (PCI Netzwerkkarten) 4.4.2 Test 1 Zugriff auf eine Tabelle in einer Accessdatenbank. Access wurde gewählt, da die JET Engine Ressourcen schonender als der MS SQL Server ist. Die Testkandidaten sollten einfach die Felder aus der Access Tabelle in eine HTML Tabelle schreiben. Folgendes Script musste gegen eine entsprechende ISAPI Extension antreten. Die ISAPI Extention wurde mit Borland Delphi 4.0 entwickelt. Ergebnisse von Test 1 Tabelle enthält ca. 2000 Datensätze. Es wurde mit einer Stoppuhr die Zeit, in der sich die Fortschrittsanzeige (Balken in der Statusleiste) der Browser bewegt, gemessen. Außerdem wurde die Abfrage zuvor einmal ohne Messung gestartet, um dem Server internes Caching (welcher Art auch immer) zu ermöglichen. * Option ”Run in Seperated Space” wurde aktiviert. ** Option ”Buffering ASP Pages” wurde aktiviert. Bedeutet, dass das Senden einer ASP solange vom Server verzögert wird, bis sie fertig aufgebaut ist. Andernfalls würde sie Zeile für Zeile abgearbeitet und Zeile für Zeile verschickt werden. KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE Task ASP ISAPI Buffer ASP Pages 10sec Absturz 34 Tabelle 4.2: Ergebnisse Test 2 4.4.3 Test 2 Identisch mit Test1, nur dass zusätzlich noch eine kleine Berechnung aus den Daten der selben Tabelle gefordert war. Berechnung : ((oRs(2)/3.3) ∗ (oRs(2)/3.7))/(12/2.3) Anmerkung: Bei einem Testlauf dieser ISAPI Extention war der Server abgestürzt. Laut Taskmanager: “Prozessorauslastung 0 Dabei konnte der IIS nur durch ein Reboot der gesamten NT Maschine wieder zum Leben erweckt werden. Der Server lieferte bei allen folgenden Requests nichts mehr zurück (TimeOut). 4.4.4 Test 3 Neben dem Datenbankzugriff sollte nun auch die reine Ausführungsgeschwindigkeit gemessen werden. Zu diesem Zweck wurde folgendes Script getestet: Hierzu benötigte der IIS 5 Sekunden. Als ”Gegner” musste wieder eine ISAPI DLL ins Rennen. Diese brachte das Ergebnis ohne merkliche Verzögerung in den Browser. Da die Ergebnisse handgestoppt wurden, kann bei einer derartigen kurzen Messdauer keine präzise Zeit genannt werden, da der Seitenaufbau immer weniger als eine Sekunde benötigte. 4.5 Schlußfolgerungen rent@trainer verwendet nun die Kombination ASP, COM+ und Microsofts SQL Server. Die Entwicklung von Web Anwendungen mittels CGI oder ISAPI hat den großen Nachteil, das die Trennung von Präsentation und Funktionalität nicht gegeben ist. Es bestünde zwar die Möglichkeit, mittels Dokumentvorlagen eine Trennlinie einzufügen, diese kann in der Praxis, wie die Erfahrung zeigt, aber nicht eingehalten werden. Beispielsweise muss man in der Anwendung eine HTML-Auswahlbox mit Elementen aus der Datenbank füllen. Der Code für die Auswahlbox kann dabei nur in im CGI bzw. ISAPI Code liegen, womit man die Seperation von Präsentation und Funktionalität schon aufgegeben hat. Die Verwendung von Scriptsprachen löst obiges Problem. Jedoch bekommt man bei der Verwendung von ASP bei größeren Projekten das Problem, dass der Code schnell unüber- KAPITEL 4. VERWENDETE TECHNOLOGIEN UND PRODUKTE 35 sichtlich wird. Dies liegt darin begündet, dass ASP Objektorientiertheit nur ansatzweise bietet. Sehr schnell entwickelt sich das Script zu “Spagetti Code”. Aus diesem Grund wurde folgende Vorgangsweise gewählt: Für die Präsentation der Daten wird ASP verwendet. ASP greift nun nicht direkt auf die Datenbank zu, sondern auf COM+ Objekte. Diese enthalten die gesamte Business Logic der Anwendung und stellen auch die Verbindung zur Datenbank her. Die COM+ Objekte sind in Borlands Delphi implementiert. 4.6 Entwicklungstools Die MTS Objekte wurden mit Borland Delphi 4.03 entwickelt [Kos991] [Kos992]. Bereits im späten Entwicklungsprozess, wo versucht wurde die Anwendung nach Windows 2000 zu portieren, musste festgestellt werden, dass mit Borland Delphi 4.03 unter Windows NT 4.0 entwickelte Objekt unter Windows 2000 nicht mehr funktionieren. Die kompilierten Object Interfaces wurden von den verschiedenen Betriebssystemen nicht mehr verstanden. Aus diesem Grund war eine Neukompilation des gesamten Source Codes auf der neuen Plattform notwendig. Da dieses Verhalten von Microsoft nicht dokumentiert ist, wird angenommen, dass sich Borland Delphi 4.03 hier nicht 100% korrekten Compilate liefert [...]. Die ASP und HTML Seiten wurden mit Macromedia Dreamweaver 2.0 erstellt. Die erstellten Images kamen von einer Drittfirma. Die ASP Tags selber wurden mit einem gewöhnlichem Texteditor, der HTML Syntaxhighlithing beherrscht, erstellt. Die Wahl fiel hier auf das Shareware Programm UltraEdit32 v6.20b. Kapitel 5 Software Design 5.1 Allgemein Da die Software eine Web-Applikation ist, geht das Design von einer Client / Server Architektur aus. Den Client stellt ein HTML Browser. Die bekanntesten und am weitesten verbreiteten Vertreter sind Microsoft’s Internet Explorer und Netscape’s Communicator. Bei der Entwicklung von einer Web-Applikation ist, wie bei der Entwicklung aller Anwendungen, darauf zu achten, die “Presentation Layer” streng von der “Data Source Layer” zu trennen. Diese Forderung wird im Allgemeinen von Scriptsprachen, wie ASP eine ist, nicht erfüllt. Eine zukünftige Alternative, die bereits Einzug in die neuesten Implementationen gehalten hat ist XML. XML verspricht die Möglichkeit, Daten und Präsentation derselben trennen zu können. Ein anderer Ansatz, der auch in dieser Arbeit angewandt wurde, ist das Einziehen einer dritten Schicht auf dem Server. Diese Schicht wird “Application Layer” oder “Business Layer” genannt. Die Aufgabe dieser Schicht ist das Bereitstellen von Funktionen, die nicht direkt von der Datenbank geliefert werden, aber von der Präsentationsschicht benötigt werden. In diese Schicht werden alle Algorithmen, die von der Applikation verwendet werden, gepackt. Ein Beispiel dafür ist der Algorithmus zum Auswahl eines Trainers. Die klassische Client/Server Architektur wird zur Multi Tier-, oder Three Tier Architektur. Um die Entwicklung der Application Layer möglichst effektiv zu gestallten, bieten verschiedene Hersteller Produkte her, die Transaktionen, Sicherheitsaspekte und Performanceaspekte, wie Load Balancing unterstützen. Eines dieser Produkte ist der in Windows NT und Windows 2000 integrierte Transaction Server. Soll die Applikation nicht auf einem Windows basierendem Server, sondern auf einem 36 KAPITEL 5. SOFTWARE DESIGN 37 Unix Derivat laufen, so sind die Produkte von Borland (Borland Application Server) oder Sun (Sun Java Application Server) in Betracht zu ziehen. Einen weiteren interessanten, vielversprechenden Ansatz bietet Hyperwave. Hyperwave bietet mit seiner objektorientierten Datenbank und der damit verbundenen objektorientierten Scriptsprache, die an JavaScript angelehnt ist, die Möglichkeit auch große Projekte durchgehend in Scriptsprachen zu entwickeln, ohne die Probleme der Unübersichtlichkeit von ASP Code zu haben. 5.2 5.2.1 Business Logic Objekt Relationen Es folgen Diagramme über die Beziehungen der ASP Scripts mit den COM+ Objekten (Abb 5.1 und Abb 5.2). Man sieht, dass versucht wurde, eine strenge Trennung der einzelnen Layers zu erhalten. Die COM+ Objekte stellen konsequent die mittlere Schicht zwischen User Interface und Datenbank dar. Eine genaue Beschreibung der Methoden der einzelnen Objekte findet sich im Anhang D. 5.2.2 OFFER.DLL - Details Motivation Das zentrale Objekt dieser Arbeit stellt TOffer im File OFFER.DLL dar. Sie enthält die Implementierung für die Auswahl der Trainer. Unter Kapitel 3 war die Komplexität untersucht worden. Es wird nun gezeigt, wie man durch Ausnutzen maschinenspezifischer Eigenschaften, die Performance erhöhen kann. Schnelle Berechnung der Verfügbarkeit Es wird ein Matrix erstellt, wobei die Spalten die Tage und die Zeilen die Personen darstellen. Es wird von dem angegebenen Startdatum stadat ausgegangen. Der Spaltenindex i gibt den Tag relativ zum Startdatum an. Alle Einträge werden zu diesem Startdatum genormt. Das bedeutet, dass eine Spalte bei allen Personen dem selben Tag entspricht. Für die Abstraktion eines Tages wählt man einen Ganzzahlwert, dessen Bits Teile eines Tages darstellen. Mit einer 24 Bitzahl kann man einen Tag Stundengenau auflösen. Die Implementierung von rent@trainer verwendet einen 64 Bit Integer Typ. Das erlaubt eine Auflösung von 30 Minuten, da von den 64 Bit momentan nur 48 genutzt werden. Eine Auf- KAPITEL 5. SOFTWARE DESIGN 38 lösung von 30 Minuten erscheint noch recht grob, da aber bei rent@trainer Kurse nur ganze Vielfache von Stunden dauern und nur zur jeweils halben oder vollen Stunde anfangen, genügt eine Auflösung von 30 Minuten. Das Verwenden von 64 Bit Ganzzahlen hat zudem den Vorteil gegenüber komplexen Datenstrukturen, dass Operationen auf diesen Zahlen direkt von einem modernen Prozessor ausgeführt werden können. Damit beschränken sich Vergleiche zwischen zwei Personen auf binäre UND Operationen, welche vom Prozessor sehr schnell ausgeführt werden können. Von allen potentiellen Personen werden alle Kalendereinträge, die die Verfügbarkeit repräsentieren, aus der Datenbank gelesen. Jeder Tag wird in einem 64Bit Ganzzahlwert gespeichert. Jedes Bit entspricht einer halben Stunde. Somit werden von den 64Bit 48Bit effektiv genutzt. Für jede Person ergibt sich dadurch ein Array von 64 Bit Ganzzahlen. Die Länge des Arrays m ergibt sich aus der Anzahl der Tage, für die Verfügbarkeit gesucht wird. In der konkreten Implementation von rent@trainer wäre m=60. Man erhält also eine Matrix M der Größe p*m. Wo die Zeilen den Tagen und Spalten den Personen entsprechen . Es wird eine Schablone für einen Tag erstellt. Diese Schablone ist eine 64 Bit Zahl wo für jede benötigte halbe Stunde eine binäre 1 steht. Würde man Trainer von 8:00 Uhr bis 12:00 Uhr benötigen, ergäbe sich eine Zahl von Binär 111111110000000000000000 = FF0000 = 16711680. Ob zwei Trainer j1, j2 am Tag i von 8:00 Uhr bis 12:00 Uhr Zeit haben, ergibt sich wie folgt: if (M[i,j1] AND M[i,j2] AND FF0000 = FF0000) then begin j1 and j2 have time end; Resultat Als Resultat dieser Berechnungen erhält man eine Liste aller potentiellen Trainer, die alle geforderten Ansprüche erfüllen. Trainer, die diese Mindestanforderungen nicht erfüllen, sind ausgeschieden. Zusätzlich sind die ausgewählten Trainer nach ihrem Ranking sortiert. Der “beste” Trainer steht am Beginn der Liste. Nachdem die Fähigkeiten aller Trainer untersucht wurde, muss nun ein möglicher Termin für einen Kurs gefunden werden. Die Komplexität für die Berechnung der Fähigkeiten (Gl. 3.2) liegt unter der, die für die Berechnung der Verfügbarkeit (Gl. 2.4). Aus diesem Grund werden zuerst die Fähigkeiten errechnet, um so die Komplexität für die Berechnung der Termine zu minimieren. KAPITEL 5. SOFTWARE DESIGN 39 Würde durch obiges Verfahren 2/3 der Trainer eliminiert werden, so ergibt sich für die Gesamtkomplexität folgender Wert. m = 5 (Kursdauer), n = 100 (Anzahl der Kalendereinträge), p = 21 (Periode innerhalb der Kurs stattfinden muss, t = 100 (Anzahl der Trainer), k = 3 (Benötigte Trainer), b = 25 (Anzahl Bewertungen für einen Trainer), B = 2500 (Anzahl aller Bewertungen im System) Geht man davon aus, dass eine elementare Operation (Kalenderzugriff, Vergleich, etc) − 10 6 s benötigt, dann käme man nach Gl. 2.4 und Gl. 3.2 auf T = 13M inuten Dies entspricht einer Zeitersparnis von 2700 %. Wählt man die Parameter so, dass nur mehr 10 Trainer übrigbleiben, dann kommt man auf nach der genannen Formel auf: T = 12sec Die Berechnungsvorschrift findet sich in Anhang C. KAPITEL 5. SOFTWARE DESIGN 40 [h][ht] courselist.asp editanswer.asp TMisc Datenbank registration.asp courseinfo.asp TMisc TCustomer bookingform.asp Datenbank default.asp TCustomer Datenbank editcustomer.asp TTrainer TCustomer feedbackanswer.asp Datenbank TOrder feedback.asp Datenbank TOrder Datenbank order.asp TMessenger Mail / SMS TCustomer TSecurity Datenbank registrationanswer.asp TMessenger Mail / SMS Abbildung 5.1: Objekt Relationen Teil 1 KAPITEL 5. SOFTWARE DESIGN 41 [h][ht] TCustomer Datenbank editanswer.asp TMessanger Mail / SMS TOffer TBooking offer.asp Datenbank TOffer Datenbank orderverification.asp TCalendar newterminasnwer.asp calendar.asp Datenbank newavailable.aspnewtermin.asp edittrainer.asp editanswer.asp TTrainer Datenbank education.asp wantercourseanswer.asp Abbildung 5.2: Objekt Relationen Teil 2 Kapitel 6 Die Datenbank von rent@trainer 6.1 Erläuterungen Die Datenbank basiert im Prinzip auf drei Säulen: Den Trainern (Tabelle HUMANRESOURCE), den angebotenen Kursen (Tabelle COURSE) und den Kunden (Tabelle CUSTOMER). Diese Tabellen sind mit verschiedenen Untertabellen verknüpft. Die Untertabellen ergaben sich durch die Erstellung der 3. Normalform der Datenstruktur [Dat98] Besonderheiten: Normalerweise werden als Identity Felder “Autoincrement Integer Felder” verwendet. Bei einigen Fällen wird jedoch darauf verzichtet und stattdessen das Primärschlüsselfeld mit speziellen Funktionen versehen. 6.1.1 Tabelle PLZ Hier ist das Primärschlüsselfeld die Postleitzahl. Die Verknüpfungen mit PLZ sind in der derzeitigen Version nicht mit referentieller Integrität realisiert. Es kann nämlich sein, dass ein User eine Postleitzahl und einen Ort eingibt, der noch nicht in der Datenbank gespeichert ist. Sollte dies der Fall sein, so darf dieser User nicht abgewiesen werden, sondern die angegebenen Daten müssen in die Datenbank übernommen werden. In der Tabelle PLZ werden noch Längengrad und Breitengrad der Orte gespeichert. Mit diesen Informationen wird mittels Pythagoras die Entfernung zwischen zwei Orten ermittelt, aus der dann die Fahrtkosten errechnet werden. Da diese Entfernung nur die Luftlinie darstellt, kann sie natürlich nicht ganz übereinstimmen. Aus diesem Grund wird die ermittelte Luftlinie mit dem Faktor 1.2 multipliziert, um auf eine reale Straßenentfernung zu kommen. 42 KAPITEL 6. DIE DATENBANK VON RENT@TRAINER Abbildung 6.1: Datenbankstruktur 43 KAPITEL 6. DIE DATENBANK VON RENT@TRAINER 44 Leider war es zur Entwicklungszeit nicht möglich, einen Routenplaner zu organisieren, der über ein API, die wirkliche Entfernung zwischen zwei Orten einer anderen Applikation zur Verfügung stellt. Alle erhältlichen Routenplaner verlangen eine händische Eingabe der Orte. 6.1.2 Tabelle COURSEBEGINTIME Das Primärschlüsselfeld gibt hier die Zeit in Minuten an. Dieses Format wurde deshalb verwendet, um im Integer Bereich bleiben zu können. Ein Datumsfeld wird ja intern von der Datenbank als FLOAT Typ gespeichert. Diese Tabelle wird benötigt um die Kursbeginnzeiten für den Kunden einzuschränken. Würde man hier dem Kunden freie Hand lassen, so wäre im Allgemeinen nicht möglich, für einen Trainer zwei Halbtageskurse an einem Tag zu halten. Bucht der Kunde zum Beispiel um 11:00 Uhr einen 4-Stunden Kurs, so geht sich weder davor noch danach ein Kurs für denTrainer aus. Aus diesem Grund bietet man dem Kunden nur bestimmte Beginnzeiten an. Aus ähnlichem Grund wie bei den Beginnzeiten von Kursen möchte man nur definierte Dauern von Kursen anbieten (4h , 1 Tag oder 2 Tage, etc.). Alle möglichen Dauern von Kursen werden in der Tabelle COURSEDURATION gespeichert. Auch die Tabelle COURSEDURATION besitzt ein spezielles Primärschlüsselfeld. Dieses ist wie folgt definiert. Coursedurationid := Anzahl Tage * 100 + Anzahl Stunden/Tag. Anzahl Tage := coursedurationid div 100 Anzahl Stunden := coursedurationid mod 100 Es liegt in der Verantwortung des Administrators hier sinnvolle Werte einzutragen. Es wird hier seitens der Datenbank keine Plausibiltätskontrolle durchgeführt. Dies ist insofern zu beachten, als dass ein fehlerhaftes Schlüsselfeld nicht visualisiert wird. Das bedeutet, dass das Programm hier einfach falsch rechnet. Als eigenständigen Teil muss man auch die Login Tabellen betrachten. Diese haben mit der eigentlichen Verwaltung der Trainer und Kunden nichts zu tun. Sie dienen lediglich dem Web Interface als Informationen über die Zugriffsberechtigungen der User. Die Login Tabellen lauten wie folg: • LOGIN • LOGINGROUP • LOGINHRMAPPING • LOGINCUSTOMERMAPPING • LOG KAPITEL 6. DIE DATENBANK VON RENT@TRAINER 45 Die Tabelle LOGIN enthält die eigentlichen Zugangsdaten. Die Tabelle LOGINGROUP speichert lediglich die verschiedenen Benutzergruppen, die auf das System Zugriff haben. In der derzeitigen Implementierung sind dies nur “Trainer” und “Kunde”. Zu beachten ist, dass die ID Werte der Zeilen “Trainer” und “Kunde” in der Tabelle LOGINGROUP vom System reserviert sind. “Trainer” wird eine 1 zugeordnet; “Kunde” eine 2. Diese ID Werte werden vom Web Server dazu verwendet, um schnell unterscheiden zu können, ob ein gerade eingeloggter User ein Kunde oder ein Trainer ist. Die Tabelle LOG zeichnet alle Logins auf. Mit dieser Tabelle ist es später möglich, eine statistische Auswertung des Userverhaltens vorzunehmen. Kapitel 7 System Requirements 7.1 Hardware • Intel Pentium PC oder kompatibel. • 64 MB Ram (Generell gilt je mehr Speicher, desto besser. Empfohlen werden min. 128 MB) • 1 GB Festplatte Die Datenbank, die COM Objekte, und die HTML Templates nehmen zusammen ca. 10 MB Festplattenspeicher in Anspruch. Sollte die Datenbank schnell wachsen, so ist hier generell mehr Speicherplatz gefordert. 7.2 Software Requirements • Microsoft Windows NT 4.0 + Service Pack3 mit Microsoft Option Pack 4.0 (IIS 4.0) Alternativ dazu kann auch Microsoft Windows 2000 verwendet werden. • Microsoft SQL Server 7.0 oder die dazu kompatible MSDE. 46 Kapitel 8 Installation von rent@trainer Bevor mit der eigentlichen Installation begonnen werden kann, muss gewährleistet sein, dass obige Systemvoraussetzungen erfüllt sind. 1. Das selbstentpackende Archiv hrsetup.exe ausführen. Als Zielordner wird der Ordner angegeben, der später auch als Web Verzeichnis fungieren soll. 2. Die entpackte Datei “humanresource.adp” mit MS Access 2000 starten. Dann die MSDE Datenbank wiederherstellen [MSACC1]. Die Datei der Sicherungskopie heißt “humanresource.dat”. 3. In der Microsoft Management Console (MMC) ist ein neues Packages zu erstellen. Die MMC ermöglicht dabei den Import bereits bestehender Packages. Beim Importieren muss das Exportfile hr.PAK angegeben werden, welches ebenfalls entpackt wurde. 4. Schließlich sind noch alle entsprechenden Zugriffsrechte für die Verzeichnisse zu setzen, damit die Anwendung ihren Dienst aufnehmen kann. 5. Der Web folder, in den man alle ASP Files kopiert hat, muss als Applikation definiert werden. Dies geschieht ebenfalls in der MMC. 6. Zum Schluss müssen noch alle Parameter für die Anwendung gesetzt werden. Dazu wird auf die Kapitel Datenbankstruktur und Businesslogik verwiesen. 47 Kapitel 9 Bedienung der Web Site 9.1 Allgemein Die Web Site gliedert sich in drei Abschnitte “Public Area” (Abbildung 9.1), “Trainer Area” (Abbildung 9.2) und “Customer Area” (Abbildung 9.3). Die Public Area verschafft einen groben Überblick über die Möglichkeiten und Angebote von rentatrainer. Die Trainer Area bietet spezifische Funktionen für die Trainer an. Die Customer Area bietet dem Kunden die Möglichkeit, die Angebote von rentatrainer auch interaktiv zu nutzen. Die Navigation innerhalb der Site findet durchgehend am linken Bildschirmrand statt. Diese Bedienung wird konsistent in allen Areas eingehalten. Die verschiedenen Areas unterscheiden sich erkennbar in der Farbe der Navigationsleiste. Die Public Area ist durchgehend in Blautönen gehalten, die Trainer Area in Rot- und die Customer Area in Gelbtönen. Dies soll dem User eine intuitive Navigation ermöglichen. 9.2 Public Area Die Public Area dient als zentrale Informationsstelle für rentatrainer. Hier findet man allgemeine Informationen zu rentatrainer. Außerdem wird man über Bedingungen und etwaige Einschränkungen dieses Dienstes informiert. Außerdem war von der Firma SILVA geplant ständig akutelle News auf der Startseite zu präsentieren. Um das Angebot von rentatrainer nutzen zu können, ist eine einmalige Registrierung in die Datenbank notwendig. Dies gilt sowohl für Trainer als auch für Kunden. Die Registrierung soll in beiden Fällen kostenlos sein. Für Trainer ist eine Registrierung sowieso selbstverständlich. Von Kunden wird eine Registrierung gefordert, damit eine Überprüfung der Identität vorgenommen werden kann. Da ein Kunde direkt Trainer buchen kann und diese Trainer damit für den gewählten Termin für andere Kunden nicht verfügbar sind, 48 KAPITEL 9. BEDIENUNG DER WEB SITE Abbildung 9.1: Public Area 49 KAPITEL 9. BEDIENUNG DER WEB SITE Abbildung 9.2: Trainer Area 50 KAPITEL 9. BEDIENUNG DER WEB SITE Abbildung 9.3: Trainer Area 51 KAPITEL 9. BEDIENUNG DER WEB SITE 52 Abbildung 9.4: Startseite muss ein Missbrauch des Dienstes weitgehend verhindert werden. Da der Einsatzzweck von rentatrainer kurzfristig gebuchte Schulungen sind, soll davon abgesehen werden, im Buchungsvorgang selbst eine Identitätsüberprüfung einzubauen. Eine derartige Überprüfung würde den Buchungsvorgang ausbremsen, was der prompten Erledigung von Buchungen widersprechen würde. Zur Registrierung stehen zwei Buttons zur Verfügung. Einer für Trainer, sowie einer für Kunden. Das Registrieren erschöpft sich im Ausfüllen eines Formulars. Bei erfolgter Registrierung erhält der User seine Zugangsdaten direkt per e-mail zugesandt. Die Korrektheit der e-mail Adresse genügt also in der derzeitigen Implementierung für die Überprüfung der Identität. Sollen weitere Überprüfungen stattfinden, so sind diese manuell von rentatrainer durchzuführen. Registriert sich ein Trainer, so erhält dieser zwar Zugang zu der Trainer Area, kann jedoch a priori noch nicht gebucht werden. Seine Kurswünsche müssen erst vom Personalchef verifiziert werden. Dieser erhält bei jeder Änderung von Kurswünschen eine e-mail, sodass er die Änderungen verfolgen kann. Trägt ein Trainer einen Kurswunsch ein, so wird das Feld Knowledgefaktor in der Tabelle ABILITY standardmäßig auf 0 gesetzt. Der Personalchef muss, damit der Trainer auch gebucht werden kann, diesen Wert auf einen Wert größer als MinKnowledgefactor einstellen (Minknowledgefactor wird im Script Offer.asp eingestellt). KAPITEL 9. BEDIENUNG DER WEB SITE Abbildung 9.5: Kunden Registrierung Abbildung 9.6: Trainer Registrierung 53 KAPITEL 9. BEDIENUNG DER WEB SITE 54 Nach erfolgter Registrierung kann sich der User nach Erhalt der Zugangsdaten per email einloggen. Zu diesem Zweck stehen zwei Buttons zur Verfügung: Ein Login - Button für die Trainer Area, der zweiter für die Customer Area. Diese Aufteilung hat lediglich optischen Charakter. Man kommt von jedem Login- Dialog mit den entsprechenden Zugangsdaten zu beiden Areas. Abbildung 9.7: Buchungsformular Um zu verhindern, dass sich ein User zweimal registriert, kann sich ein User pro Sitzung nur einmal registrieren. Eine erneute Registrierung ist nur dann möglich, wenn der Internet Browser beendet und wieder gestartet wird. Durch diese Maßnahme wird auch verhindert, dass durch ein Reload einer Seite eine erneute Registrierung vorgenommen wird. Es wurde vereinbart, dass aus Sicherheitsgründen bereits existente Namen nicht abgewiesen werden. Dies würde Dritten die Möglichkeit bieten, zu erfahren, wer bei rentatrainer bereits registriert ist. 9.3 Trainer Area Gibt man gültige Login Daten eines Trainers ein, so gelangt man zur Startseite für Trainer. Auf dieser Seite sieht der Trainer alle Buchungen, für die er eingeteilt ist. Von dieser Seite aus kommt der Trainer auf verschiedene weitere Seiten, auf denen er verschiedene KAPITEL 9. BEDIENUNG DER WEB SITE 55 Einstellungen treffen kann. 9.3.1 Ändern der persönlichen Daten Ändert sich zum Beispiel die Anschrift des Trainers, so kann er über diese Seite seine Daten ändern. Die Daten werden nach erfolgter Bestätigung sofort in die Datenbank übernommen. D.h. der Trainer trägt die volle Verantwortung über seine Eingaben. Diese sollten daher stehts überprüft werden. 9.3.2 Eintragen von Kurswünschen Auf dieser Seite kann der Trainer alle Kurse und Sprachen eintragen, die er unterrichten will. Wie eingangs erwähnt, sollen sich komplexere Fähigkeiten aus mehreren Fähigkeiten zusammensetzen. Bei Rent@trainer sind dies Fachkenntnisse über den zu unterrichtenden Stoff und die Kenntnis der Sprachen. Aber genau rent@trainer stellt eine Ausnahme dar. Da alle Trainer aus dem deutschsprachigen Raum kommen, werden vollkommen perfekte Sprachkenntnisse nicht angenommen. Vielmehr verlangen Kurse im IT Bereich spezielles Fachvokabular, dass für jeden Kurs variieren kann. Aus diesem Grund genügt es nicht, einfach “Englisch” anzukreuzen, damit man alle Kurse in Englisch halten kann. Es muss differentiert für alle Kurse angegeben werden, in welcher Sprache man diesen halten kann. Diese Vorgehensweise erhöht zwar den Tippaufwand für den Trainer, aber die Auswahl des Trainers kann viel spezifischer erfolgen. 9.3.3 Online Kalender Um die Verfügbarkeit verwalten zu können, müssen die Trainer ihre Verfügbarkeit erst eintragen. Dies geschieht mit einem Online Kalender. • Die Verfügbarkeit stellt sich durch einen dunkelblauen Bereich in der Wochenansicht dar. • Gebuchte Bereiche werden hellblau dargestellt. • Andere Termine werden grün dargestellt. Der Kalender ist jedoch nur prototypenhaft implementiert. Bis zum Zeitpunkt der Fertigstellung konnte er leider noch nicht von der Firma SILVA evaluiert werden. Es wurde daraufhin verzichtet, die Entwicklung in diesem Bereich fortzusetzen. KAPITEL 9. BEDIENUNG DER WEB SITE 56 Abbildung 9.8: Trainer Kalender Das Software Design des Kalenders ist aber so allgemein gehalten, dass eine Erweiterung des Kalenders leicht vorgenommen werden kann. Eine Monatsansicht wäre zum Beispiel sehr wünschenswert. Modifikationen, die das Layout des Kalenders betreffen, können durch Änderung der ASP Scripts vorgenommen werden. 9.4 Customer Area Der Kunde kann seine persönlichen Daten ändern, Kursinformationen abfragen und natürlich Kurse buchen. Nachdem ein Kunde gültige Zugangsdaten eingegeben hat, gelangt er zu seiner Startseite. Hier sieht er alle abgeschlossenen gebuchten Kurse. Der Kunde kann dann diese Kurse mittels einem Online Feedback Formular evaluieren. Dieses Feedback fliesst dann direkt in zukünftige Auswahlen von Trainern ein. 9.4.1 Feedback Formular Das Feedback, das der Kunde einzugeben hat, beinhaltet folgende Felder: KAPITEL 9. BEDIENUNG DER WEB SITE 57 • Erwartungen • Nutzen • Inhalt • Dauer • Tempo • Vorkenntnisse • Unterlagen • Gesamtnote Diese Felder wurden von der Fa. SILVA G.m.b.H vorgegeben. Die Eintragungen sind im Schulnotensystem einzugeben (“Sehr Gut” bis “Nicht Genügend”). Intern werden die Noten umgerechnet in Werte zwischen 0 (Nicht Genügend) und 1 (Sehr Gut). 9.4.2 Kursinfos Der Kunde kann in einer eigenen Seite die Details aller angebotenen Kurse abfragen. Die Details sind in dieser Implementierung als Hyperlink ausgeführt. D.h. Es obligt dem Systadministrator vor Ort die Links auf eine externe Site zu setzen, um hier die Informationen anzeigen zu lassen. Momentan wurde das Kursportfolio der Fa. SILVA G.m.b.h, welches in Microsoft Powerpoint vorlag, in JPEG Bilder convertiert und die Links auf die Bilder gesetzt. Diese Vorgangsweise ist sicher nicht optimal, sie soll hier aber nur die Möglichkeiten aufzeigen und als Prototyp dienen. 9.4.3 Die Buchung Die Buchung erfolgt in mehreren Schritten. Zuerst muss das Buchungsformular (Abbildung 9.10) ausgefüllt werden. Es ist möglich, hier einen eigenen Ansprechpartner anzugeben, der auf Kundenseite für die Abwicklung dieses Kurses verantwortlich ist. Standardmäßig wird der eingeloggte User als Kontaktperson angenommen. Falls die Kontaktperson geändert wird, ist auf eine korrekte e-mail Adresse zu achten, damit der geänderte User auch die notwendigen Nachrichten vom System erhält. Nach der Eingabe der Daten versucht der Server mit den zuvor beschriebenen Algorithmen, Vorschläge für Kurstermine zu finden. Diese Vorschläge werden dem User als Antwort auf die Eingabe des Buchungsformulars präsentiert. Aus diesen Vorschlägen kann KAPITEL 9. BEDIENUNG DER WEB SITE Abbildung 9.9: Kursportfolio: Beispiel MS Visual Basic Abbildung 9.10: Buchungsformular 58 KAPITEL 9. BEDIENUNG DER WEB SITE 59 der User nun einen auswählen. Bevor die Buchung nun wirksam wird, muss der User noch auf einer Bestätigungsseite seine Eingaben kontrollieren. Erst wenn der Kunde diese Seite bestätigt hat, wird die Anfrage im System als Buchung gespeichert. Die entsprechenden Trainer werden daraufhin sofort mittels e-mail und SMS verständigt. Die SMS an die Trainer enthält nur die Nachricht, dass dieser gebucht ist. Genauere Daten stehen in der übermittelten e-mail. Außerdem sieht der Trainer die Buchung in seinem Online Termin Kalender. Sollte der Kunde die Buchung abbrechen so bleibt trotzdem die Anfrage gespeichert. Die Ausertung der Anfragen über einen gewissen Zeitraum hinweg, soll dann Rückschlüsse auf das Kundenverhalten liefern. Kapitel 10 Ausblick 10.1 Katastrophendienste 10.1.1 Allgemein Hilfsorganisationen wie das rote Kreuz oder die österreichische Bergrettung haben ebenso wie eine Schulungsfirma freie Mitarbeiter. Die Verwaltung dieses Personals wird momentan noch manuell über das Telefon durchgeführt. Im folgenden Abschnitt soll nun diskutiert werden, inwieweit ein Automatisierung in diesen Bereichen Sinn macht. Welche Vorteile bietet eine automatische Personalverwaltung und kann diese über das Internet durchgeführt werden. Welche Vorteile bieten die klassischen, momentan eingesetzten, Verfahren gegenüber neuen Modellen? Gibt es Möglichkeiten durch Hybridsysteme die Vorteile beider Lager zu verbinden? 10.1.2 Bergrettung Der Einsatzplan für die Verständigung der Retter ist bei der Bergrettung Österreichs eine sogenannte Alarmierungskette. Wählt man die Nummer 144 gelangt man zur Zentrale des österreichischen Bergrettungsdienstes (OEBRD). Ein Mitarbeiter in der Telefonzentrale nimmt die Daten des Anrufers auf und alarmiert die zuständige Ortsgruppe. Der OEBRD ist in Ortsgruppen eingeteilt, welche jeweils ein bestimmtes Gebiet abdecken. Das Alarmieren der Ortsgruppe funktioniert durch Alarmierung des dortigen Einsatzleiters bzw. einen seiner Stellvertreter. Sobald einer der Einsatzleiter erreicht ist, liegt die weitere Planung des Einsatzes in seiner Verantwortung. Für die Organisation des weiteren Einsatzes gibt es zwei mögliche Szenarien. Der Einsatzleiter weiß, dass eine oder mehrere Personen in einem mehr oder weniger großem Gebiet vermisst sind. Bei der Suche von Vermissten gilt die Regel, je mehr Einsatzkräfte zur Verfügung stehen, desto besser. Der weitere Alarmierungs- 60 KAPITEL 10. AUSBLICK 61 plan sieht dann vor, dass der Einsatzleiter den nächsten in der Alarmierungsliste anruft. Sollte dieser nicht erreichbar sein, so muss er versuchen, den nächsten zu erreichen. Diese Prozedur ist solange durchzuführen, bis er wirklich eine Kraft erreicht hat. Dieser wird nun Ort und Zeitpunkt des Treffpunktes bekanntgegeben. Nun liegt es an dieser Einsatzkraft den nächsten Retter zu alarmieren. Nach Beendigung der Alarmierung sind nun alle möglichen, momentan verfügbaren Einsatzkräfte alarmiert. Als Erweiterung dieser Kette, deren Durchführung sehr zeitaufwendig wäre, hat sich eingebürgert, auf Ortsgruppenebene drei parallel laufende Ketten zu haben. Der Einsatzleiter ruft in diesem Fall nicht nur einen, sondern drei weitere Bergretter an. Diese rufen dann den nächsten in ihrer Kette an. Die Alarmierungszeit wird dadurch auf ein Drittel reduziert. Wird die Bergrettung über einen Unfall informiert, wo der Aufenthaltsort der Verunglückten bekannt ist, wo es darum geht den oder die Vermissten zu bergen, so werden anderer Prioritäten gesetzt. Es ist nicht mehr die Quantität der Retter entscheiden, sondern es werden für die Einsäte spezifische Fähigkeiten gefordert. Muss ein Kletterer aus einer Wand geborgen werden, so sind andere Kenntnisse erforderlich, als bei einem alpinen Rettungseinsatz im Winter. Bei einem eingehenden Notruf verständigt die Zentrale nun den Einsatzleiter. Dieser hat nun die Aufgabe den Einsatz derart zu koordinieren, dass er auswählt, welche Rettungskraft und welches Gerät benötigt wird. In diesem Fall ist es nicht mehr möglich, drei parallele Alarmierungsketten aufzubauen, da ansonsten die gesamten Einsatzinformationen an den jeweils nächsten weitergegeben werden müssten, damit dieser weiß, wen er in der Folge weiter informieren muss. Hier erfolgt die Alarmierung sequentiell. Das bedeutet, dass die Dauer der Alarmierung länger dauern kann. Gerade bei einer Bergung kann verlorene oder gewonnene Zeit Leben entscheiden. In jüngster Zeit werden in der Bergrettung Österreich Pager eingesetzt. Bei einer Vermisstensuche kontaktiert die Zentrale direkt alle Retter. Diese bestätigen den Empfang der eingehenden Message auf dem Pager mit einem Rückruf bei dem Einsatzleiter. Sollte die Anzahl der Rückrufe jedoch nicht genügend hoch sein, so wird auf die konventionelle Telefonkette zurückgegriffen. Beim Bergungsszenario bekommt wieder der Einsatzleiter die Meldung von der Zentrale. Dieser wählt nun anhand der geforderten Fähigkeiten, die entsprechenden Pagernummern seiner Leute an. Bei den Recherchen unterstützt wurde ich vom Obmann der Bergrettung “Sektion Gesäuse” Hans Peter scheb. 10.2 Interne Personalbeurteilung Es ist aber nicht nur vorstellbar, dass Feedback von außen über die Qualität von Personal bestimmt. Der Algorithmus für das Bilden des Trainerrankings kann auch dazu verwendet werden, interne Beurteilungen zu verwalten. In einer Firma wird typischerweise vermerkt, KAPITEL 10. AUSBLICK 62 welcher Arbeiter welchen Arbeitsschritt wann gemacht hat bzw. wie lange er dafür gebracht hat. Wenn man also sowieso die Arbeit protokolliert, dann ist es nur mehr ein kleiner Schritt, diese Arbeit zu beurteilen. Bei rent@trainer wird das Feedback vom Kunden eingegeben und mit der entsprechenden Bestellung verknüpft. Verknüpft man nun das Feedback mit einer internen Auftragsnummer oder besser direkt mit einem Arbeitsschritt, so hat ein Verantwortlicher (z.B. Personalchef) die Möglichkeit, Arbeitsvorgänge genau zu protokollieren und zu beurteilen. In der Folge kann man dann, bei ähnlich gelagerten Aufträgen die ideale Arbeitskraft aus der Belegschaft extrahieren und so die Effektivität erhöhen, was die Produktionskosten senken hilft. Wichtig für eine interne Personalbeurteilung ist aber, genauso wie für das Trainerbeurteilungssystem, dass die Bewertungen auch der Realität entsprechen. Das heißt, dass 10.2.1 Notwendige Änderungen Um so ein internes Beurteilungssystem mit bei ev. fixer Belegschaft einzusetzen, sind aber noch einige Designänderungen vorzunehmen. Rent@trainer fordert in Anforderungsprofil der Software, dass immer der bestmögliche Trainer ausgewählt wird. Sollte dieser bestmögliche Trainer erst Wochen nach einem anderen Trainer Zeit haben, so wird trotzdem ein Angebot mit diesem Trainer erstellt, so lange der Termin innerhalb der eingestellten Zeit ist (Property Booking.MaxSearchIntervall) ist. Erst wenn innerhalb dieses Zeitraumes kein Angebot mehr möglich ist, wird zum nächstbesten Trainer gegriffen. Bei dem eben beschriebenen internen Betriebsszenario sind die Prioritäten anders gesetzt. Hier wird gefordert, dass ein Arbeitsschritt umgehend erledigt wird. Es ist lediglich wichtig, dass der Arbeiter die notwendigen Kenntnisse erfüllt (Property booking.minranking). Aus allen Arbeitern, die diese Anforderung erfüllen, wird nun der ausgewählt, der ehest möglich Zeit hat. “Zeit haben” bedeutet in diesem Fall, mit keiner anderen Arbeit beschäftigt sein. Standardmäßig hat ein Arbeiter innerhalb seiner Schicht immer Zeit, bis er eine Arbeit angefangen hat. Bei Beendigung derselben wird er wieder verfügbar. Um eine nahtlose Aneinanderreihung von Arbeiten für einen Arbeiter zu gewährleisten, muss man wissen, wie lange die angefangene Arbeit voraussichtlich dauern wird. Erst dann ist es möglich, die Verfügbarkeit der Arbeitskraft im vornhinein abzuschätzen. Die Information über die Dauer des Arbeitsschrittes kann hier aus bereits erledigten, protokollierten Arbeiten gewonnen werden oder durch einfaches Abschätzen der Arbeitsdauer seitens des Verantwortlichen der Fertigung. Anhang A Tabellen LOGIN • LOGINID ID Wert. Vom System automatisch generiert • PASSWORD Das Passwort: Zusammen mit Loginid die Zugangsdaten. • CREATION Datum der Erzeugung dieses Datensatzes • LOGINGROUPID Fremdschlüssel LOGINGROUP.LOGINGROUPID • VALIDBY Datumsfeld, bis wann der Account gilt. Wird das Datum überschritten, so wird der Zugang für den User gesperrt. Um einen User explizit zu sperren, so erreicht man dies durch setzen von VALIDBY auf ein vergangenes Datum. Dadurch wird der User umgehend gesperrt LOGINGROUP • LOGINGROUPID ID Wert. Vom User zu vergeben. Da dies der Primärschlüssel der Tabelle ist, muss der Administrator auf Eindeutigkeit achten. Da die Anzahl der Datensätze aber sehr begrenzt ist (in der aktuellen Implementierung lediglich zwei), dürfte dies aber kein Problem darstellen. • Caption Die Bezeichnung der Benutzergruppe LOGINCUSTOMERMAPPING • loginid Fremdschlüssel LOGIN.LOGINID • Customerid Fremdschlüssel CUSTOMER.CUSTOMERID 63 ANHANG A. TABELLEN 64 LOGINHRMAPPING • Loginid Fremdschlüssel LOGIN.LOGINID • humanresourceid Fremdschlüssel HUMANRESOURCE.humanresourceid HUMANRESOURCE • humanresourceid Primärschlüssel (Autowert) • Firstname Vorname • Lastname Nachname • Title Titel • Male Gibt an, ob Kunde (Kontaktperson) männlich ist oder nicht. Dies wirkt sich auf die Anrede aus; “Herr” oder “Frau” sind hier möglich. • Address Das Straßenfeld • Plzid Die Postleitzahl des Wohnortes. Fremdschlüssel PLZ.PLZID. Hier wird aber keine referentielle Integrität gefordert. Falls ein Postleitzahl eingetragen wurde, die noch nicht existiert, muss das System darauf reagieren und darf den Trainer nicht einfach abweisen. Genauere Beschreibung Siehe Tabelle PLZ • Stateid Fremdschlüssel STATE.stateid • Place Der Wohnort des Trainers • Maxteachdistance Die maximale Distanz des Trainers, die er unterrichten will. Sollte der Unterrichtsort weiter entfernt sein, so wird dieser Trainer ausgefiltert. • Telephone1 • Telephone2 • Mobiletelephone • Email • Birth Geburtsdatum • fax • Skills Besondere Fähigkeiten, Ausbildung • Jobs Erfahrungen, die der Trainer mitbringt ANHANG A. TABELLEN 65 • interests Interessen des Trainers • Firm Die Firma des Trainers, falls er bei einer anderen Firma beschäftigt ist, und hier als Selbständiger auftritt. • kmcost Die Fahrtkosten. Dies sind die Kosten, die der Firma SILVA pro gefahrenen Kilometer des Trainers entstehen. CALENDAR • Calendarid Primärschlüssel (Autowert) • Humanresourceid Fremdschlüssel HUMANRESOURCE.humanresourceid • Starttime DatumsZeitfeld mit der Startzeit dieses Eintrags • Endtime DatumsZeitfeld mit der Endzeit dieses Eintrags • Calendarcategorieid Fremdschlüssel CALENDARCATEGORIE.CALENDARCATEGORIEID • Note Zusätzliche Bemerkung • Title Titel des Eintrages CALENDARCATEGORIE • Calendarcategorieid Primärschlüssel (Autowert) • caption Bezeichnung der Kategorie ABILITY • Humanresourceid Fremdschlüssel HUMANRESOURCE.humanresourceid • Courseid Fremdschlüssel COURSE.courseid • Languageid Fremdschlüssel LANGUAGE.languageid • Knowledgefaktor Bewertung der Fähigkeit des Trainers (0.0 - 1.0) LANGUAGE • Languageid Primärschlüssel (Autowert) • caption Bezeichnung der Sprache ANHANG A. TABELLEN 66 COURSE • Courseid Primärschlüssel (Autowert) • Caption Bezeichnung des Kurses Informationlink Link zu einer HTML Seite, die genauere Angaben über diesen Kurs enthält. • Coursedurationid Fremdschlüssel COURSEDURATION.coursedurationid • Priceperhour Preis dieses Kurses für eine Stunde • Literaturprice Preis für eine Unterlage zu diesem Kurs • available Wird dieses Flag gelöscht, so wird dieser Kurs nicht mehr im UI angezeigt. COURSECATEGORIE • Coursecategorieid Primärschlüssel (Autowert) • caption Bezeichnung der Kategorie COURSEDURATION • Coursedurationid Primärschlüssel. Muss vom Administrator manuell eingetragen werden. Dabei wird dieser Integerwert von der Software wie folg interpretiert: Tage := coursedurationid div 100 \\ Stunden := coursedurationid mod 100\\ Ein Wert von 108 bedeutet also, daß der Kurs an einem Tag zu acht Stunden gehalten wird • Caption Bezeichnung der Kategorie QUERY • Queryid Primärschlüssel (Autowert) • Customerid Fremdschlüssel CUSTOMER.customerid • Contact Vorname und Nachname der Kontaktperson für diesen Kurs • Email e-mail Adresse der Kontaktperson • Telephone Telephonnummer der Kontaktperson ANHANG A. TABELLEN 67 • courseid Fremdschlüssel COURSE.courseid • Languageid Fremdschlüssel LANGUAGE.languageid • Duration Fremdschlüssel COURSEDURATION.Coursedurationid (jedoch ohne referentielle Integrität) • Wantedstart Datum, welches der Kunde im Online Formular eingetragen hat. • Plzid Fremdschlüssel PLZ.plzid • Address • Place • Stateid Fremdschlüssel STATE.stateid • Literaturecount Anzahl der geforderten Unterlagen • traineecount Anzahl der geforderten Trainer • querytime Datum der Anfrage STATE • Stateid Primärschlüssel (Autowert) • Caption Bezeichng des Staates OFFER • Offerid Primärschlüssel (Autowert) • Queryid Fremdschlüssel QUERY.queryid • Price Kurspreis • Literatureprice Unterlagenpreis • Offertime Datum der Anbotslegung • Valid Gibt an, ob das Angebot noch gültig ist. • Drivingprice Kosten für die Anreise des/der Trainer ANHANG A. TABELLEN HROFFER • Hrofferid Primärschlüssel (Autowert) • Offerid Fremdschlüssel offer.offerid • Humanresourceid Fremdschlüssel HUMANRESOURCE.humanresourceid • Payment Ausgaben für den Trainer • drivingpayment Ausgaben für die Anreise des Trainers OFFERTIMES • Offertimesid Primärschlüssel (Autowert) • Offerid Fremdschlüssel offer.offerid • Offerstart Datums/Zeitfeld mit dem Start des Trainingstages • offerend Datums/Zeitfeld mit dem Ende des Trainingstages ORDERING • Orderid Primärschlüssel (Autowert) • Offerid Fremdschlüssel offer.offerid • Ordertime Datum der Bestellung FEEDBACK • Feedbackid Primärschlüssel (Autowert) • Offerid Fremdschlüssel offer.offerid • Erwartungen • Nutzen • Inhalt • Dauer • Tempo • Vorkenntnisse • Unterlagen • Gesamtnote • Feedbacktime 68 ANHANG A. TABELLEN 69 TRAINERFEEDBACK • trainerfeedbackid Primärschlüssel (Autowert) • feedbackid Fremdschlüssel FEEDBACK.feDie Datenbankstruktur: PLZ • Plzid Primärschlüssel (Die Postleitzahl selber) • Caption Bezeichnung des Ortes • Latitude Breitengrad • longitude Längengrad COURSEBEGINTIME • Coursebegintimeid Primärschlüssel. Dieser Wert muss vom Administrator manuell eingegeben werden. Er gibt die Zeit in Minuten an. Ein Wert von 450 bedeutet 7:30, 300 eben 5:00 Uhr • caption Die Zeit im Klartext FIRMBRANCH • Firmbranchid Primäschlüssel (Autowert) • Caption Der Name der Branche NOTICE • Noticeid Primäschlüssel (Autowert) • caption Bezeichnung CUSTOMER • customerid Primärschlüssel (Autowert) • Firstname Vorname • Lastname Nachname • Title Titel • Male Gibt an, ob Kunde (Kontaktperson) männlich ist oder nicht. Dies wirkt sich auf die Anrede aus; “Herr” oder “Frau” sind hier möglich. ANHANG A. TABELLEN 70 • Firmname • Firmbranchid Fremdschlüssel FIRMBRANCH.firmbranchid • Address • Place • Plzid Fremdschlüssel PLZ.plzid • Homepage • Stateid Fremdschlüssel STATE.stateid • Telephone1 • Mobiletelephone • Fax • Email • Noticeid Fremdschlüssel NOTICE.noticeid wantinformation Flag, das angibt, ob der Kunde weitere Informationen erhalten will. Anhang B Views in der Datenbank bookedtrainer S ELECT OFFER.offerid, HROFFER.humanresourceid, OFFERTIMES.offerstart, OFFERTIMES.offerend, HUMANRESOURCE.firstname, HUMANRESOURCE.lastname, ORDERING.orderid, CUSTOMER.firmname, LANGUAGE.caption, COURSE.caption AS ccaption, HUMANRESOURCE.email, HUMANRESOURCE.mobiletelephone FROM OFFERTIMES INNER JOIN OFFER ON OFFERTIMES.offerid = OFFER.offerid INNER JOIN HROFFER ON OFFER.offerid = HROFFER.offerid INNER JOIN HUMANRESOURCE ON HROFFER.humanresourceid = HUMANRESOURCE.humanresourceid INNER JOIN ORDERING ON OFFER.offerid = ORDERING.offerid INNER JOIN QUERY ON OFFER.queryid = QUERY.queryid INNER JOIN COURSE ON QUERY.courseid = COURSE.courseid INNER JOIN LANGUAGE ON QUERY.languageid = LANGUAGE.languageid INNER JOIN CUSTOMER ON QUERY.customerid = CUSTOMER.customerid customerlogin S ELECT LOGIN.loginid AS Expr1, LOGIN.password AS Expr2, 71 ANHANG B. VIEWS IN DER DATENBANK CUSTOMER.* FROM LOGIN INNER JOIN LOGINCUSTOMERMAPPING ON LOGIN.loginid = LOGINCUSTOMERMAPPING.loginid INNER JOIN CUSTOMER ON LOGINCUSTOMERMAPPING.customerid = CUSTOMER.custome humanresourcelogin S ELECT LOGIN.loginid AS Expr1, LOGIN.password AS Expr2, HUMANRESOURCE.* FROM LOGIN INNER JOIN LOGINHRMAPPING ON LOGIN.loginid = LOGINHRMAPPING.loginid INNER JOIN HUMANRESOURCE ON LOGINHRMAPPING.humanresourceid = HUMANRESOURCE.humanresourceid humanresourcelogin S ELECT OFFER.drivingprice, OFFER.offertime, OFFER.literatureprice, OFFER.price, OFFER.offerid, QUERY.contact, QUERY.email, QUERY.telephone, LANGUAGE.caption, COURSE.caption AS ccaption, STATE.caption AS scaption, QUERY.place, QUERY.address, QUERY.literaturecount, QUERY.traineecount, QUERY.plzid FROM QUERY INNER JOIN OFFER ON QUERY.queryid = OFFER.queryid INNER JOIN LANGUAGE ON QUERY.languageid = LANGUAGE.languageid INNER JOIN COURSE ON QUERY.courseid = COURSE.courseid INNER JOIN STATE ON QUERY.stateid = STATE.stateid 72 ANHANG B. VIEWS IN DER DATENBANK pastcourses S ELECT ORDERING.orderid, COURSE.caption, LANGUAGE.caption AS lcaption, QUERY.place, QUERY.customerid FROM ORDERING INNER JOIN OFFER ON ORDERING.offerid = OFFER.offerid INNER JOIN OFFERTIMES ON OFFER.offerid = OFFERTIMES.offerid INNER JOIN QUERY ON OFFER.queryid = QUERY.queryid INNER JOIN COURSE ON QUERY.courseid = COURSE.courseid INNER JOIN LANGUAGE ON QUERY.languageid = LANGUAGE.languageid WHERE (ORDERING.orderid NOT IN (SELECT orderid FROM feedback)) possibletrainer S ELECT query1.courseid, query1.languageid, query1.qlong, query1.qlat, (humanrersouce1.hlong - query1.qlong) * (humanrersouce1.hlong - query1.qlong) * 12100 + (humanrersouce1.hlat - query1.qlat) * (humanrersouce1.hlat - query1.qlat) * 5776 AS distance, humanrersouce1.kmcost * humanrersouce1.kmcost * ((humanrersouce1.hlong - query1.qlong) * (humanrersouce1.hlong - query1.qlong) * 12100 + (humanrersouce1.hlat - query1.qlat) * (humanrersouce1.hlat - query1.qlat) * 5776) * 5.76 AS drivingcosts, query1.queryid, query1.plzid, humanrersouce1.humanresourceid, humanrersouce1.mobiletelephone, humanrersouce1.email, humanrersouce1.firstname, humanrersouce1.lastname, humanrersouce1.title, humanrersouce1.male, query1.knowledgefactor, humanrersouce1.kmcost FROM humanrersouce1 INNER JOIN query1 ON 73 ANHANG B. VIEWS IN DER DATENBANK humanrersouce1.humanresourceid = query1.humanresourceid rankingcalc S ELECT TRAINERFEEDBACK.*, QUERY.customerid AS Expr1, QUERY.courseid AS Expr2, QUERY.languageid AS Expr3 FROM QUERY INNER JOIN OFFER ON QUERY.queryid = OFFER.queryid INNER JOIN ORDERING ON OFFER.offerid = ORDERING.offerid INNER JOIN TRAINERFEEDBACK ON ORDERING.orderid = TRAINERFEEDBACK.orderingid 74 Anhang C Der Algorithmus zur Trainerauswahl Zum besseren Verständnis ist hier die Implementierung der Funktion abgedruckt, die die Berechnung des Rankings aus den vergangenen Feedbacks vornimmt. function Tbooking.calculateRanking(humanresourceid: integer; var defaulttrainerranking:double): double; var cmd:string; weight:double; totalweight:double; sum:double; reference : double; ageweight : double; defsum:double; deftotweight : double; begin cmd := ’SELECT * FROM rankingcalc WHERE humanresourceid=’+ inttostr(humanresourceid); defsum := 0; deftotweight := 0; sum:=0; totalweight:=0; with coRecordSet.Create do begin Open(cmd,getConnection,adOpenDynamic, 75 ANHANG C. DER ALGORITHMUS ZUR TRAINERAUSWAHL adlockoptimistic,adCmdText); while not eof do begin weight:=1; ageweight:=exp(-\_feedbackageweight* ln((now - fields[’feedbackdatum’].value))); if fields[’customerid’].value <> \_customerid then begin weight := weight * \_OtherFeedbackWeight; end else begin // calculate DefaultTrainer; defsum:=defsum+ageweight*fields[’gesamtnote’].value; deftotweight := deftotweight+ ageweight; end; if (fields[’courseid’].value <> courseid) or (fields[’languageid’].value <> \_languageid) then begin weight := weight * \_feedbackothercoursesweight; end; weight := weight* ageweight; sum := sum+weight*fields[’gesamtnote’].value; totalweight:=totalweight+weight; movenext; end; close; end; if deftotweight > 0 then begin defaulttrainerranking := defsum / deftotweight; end else begin defaulttrainerranking := 0; end; if totalweight > 0 then begin reference:=\_referenceweight * (1/exp(\_feedbackageweight * ln(now - \_referenceage))); totalweight:=totalweight+reference; sum := sum + reference*\_referencevalue; result := (sum / totalweight); end else result := \_emptyranking; 76 ANHANG C. DER ALGORITHMUS ZUR TRAINERAUSWAHL end; 77 Anhang D Die Business Logik D.1 Allgemein Wie in den vorigen Kapiteln erwähnt, wird für die Implementierung von Rent@trainer ein “Three Tier” Software Design genommen. Im folgenden werden die Interfaces der Business Logik beschrieben. Diese stellen den Kern der Arbeit dar. Auch wenn man dem Kunden kein Webinterface zur Verfügung stellen will, können diese Objekte dennoch für ein internes System genutzt werden. Durch die Verwendung von COM+ können diese Objekte ja nicht nur von ASP sondern auch z.B. von einer VBA Applikation, wie Microsoft Excel, angesprochen werden. D.2 CAL.DLL (Interface: Calendar) Das Calendar Objekt kapselt alle Tabellen des Online Calendars. Es stehen folgende Methoden zur Verfügung. procedure addEntry(trainerid: Integer; betreff: WideString; categorieid: Integer; starttime, endtime: TDateTime; note: WideString) Erstellt einen neuen Termin für den angegebenen Trainer. Der Parameter trainerid ergibt sich aus dem eingeloggtem user. Dieser wird vom IIS in seinem Session Objekt gespeichert. Mit Trainerid := Session(userid)} erhält man den aktuellen user aus dem ASP Script. Categorieid entspricht dem Schlüssel der Tabelle COURSECATEGORIE. Dabei zu beachten ist, dass zwei Werte reserviert 78 ANHANG D. DIE BUSINESS LOGIK 79 sind. 1: verfügbar 2: gebucht Die Methode getCBCalendarCategorieOptions() liefert für eine HTML Combobox alle Options Felder direkt aus der Datenbank. Starttime und endtime sind absolute Datumswerte. In Note kann man einen Kommentar dem Termin hinzufügen. Rückgabewert: Der Primärschlüssel des neuen Kalendereintrages (CALENDAR.calendarid) Beispiel: set calobj = Server.CreateObject(‘‘hr.calendar’’) calendarid = calobj.addEntry(Session(‘‘userid’’), request.Form(‘‘betreff’’), request.form(‘‘categorie’’), starttime, endtime, request.form(‘‘note’’)) Erzeugt einen neuen Kalendereintrag in der Datenbank. procedure changeEntry(calendarid: Integer; betreff: WideString; categorieid: Integer; starttime, endtime: TDateTime; note: WideString) Ändert einen Termineintrag in der Datenbank Categorieid entspricht dem Schlüssel der Tabelle COURSECATEGORIE. Dabei zu beachten ist, dass zwei Werte reserviert sind. 1: verfügbar 2: gebucht Die Methode getCBCalendarCategorieOptions() liefert für eine HTML Combobox alle Options felder direkt aus der Datenbank. Starttime und endtime sind absolute Datumswerte. In Note kann man einen Kommentar dem Termin hinzufügen. Beispiel: Set calobj = Server.CreateObject (‘‘hr.calendar’’) calobj.changeEntry (calendarid, request.Form (‘‘betreff’’), request.form (‘‘categorie’’), starttime, endtime, request.form(‘‘note’’) ) Ändert den mit calendarid angegebenen Eintrag mit den übergebenen Parametern. procedure removeEntry(calendarid: Integer) ANHANG D. DIE BUSINESS LOGIK 80 Entfernt einen Kalendereintrag procedure loadcurrentMonth(currentdate: TDateTime; trainerid: Integer) loadCurrentMonth lädt alle Termineinträge des angegebenen Trainers für den angegebenen Monat in den Speicher des Objektes. Im Detail wird ein 43*24 Array angelegt, das für 43 Tage für jede Stunde die passende Farbe für die Wochenansicht speichert. Die Farbe wird aus CALENDARCATEGORIE.color geholt. Mit der Methode getColor() kann dann die entsprechende Zelle schnell ausgelesen werden. Die Arraygrenzen sind [-6..36, 0..23]. Das bedeutet es werden 6 Tage des Vormonats und 6 Tage des Folgemonats mitgespeichert. Dies ist notwendig, falls in der Wochenansicht des Onlineterminkalenders gerade ein Monatssprung stattfindet. function getUpcomingEntriesList(trainerid: Integer): recordset Liefert ein ADO Recordset mit allen zukünftigen Termineinträgen des angegebenen Trainers zurück. Dieses Recordset kann dann innerhalb des ASP Scriptes weiterverwendet werden. Der Grund, warum hier ein Recordset zurückgeliefert wurde, wodurch ja die Middle Tier umgangen wird, ist einfach: Einerseits soll dem ASP Script volle Kontrolle über das Layout überlassen werden, anderseits ist es in diesem einfachen Fall nicht notwendig, eine künstliche Zwischenschicht zwischen dem ADO Recordset und dem ASP Script einzuziehen. function getCellColor(day, hour: Integer): Integer Liefert die Farbe für die angegebenene, zuvor von loadCurrentMonth() geladende, Zelle zurück. Diese Funktion liefert nur dann korrekte Werte, falls vor dem ersten Aufruf von getCellColor() loadCurrenMonth() aufgerufen wurde. function getCBCalendarCategorieOptions( selected: Integer): WideString Liefert alle möglichen Kalenderkategorien in einem String zurück. Dieser String ist bereits vorformatiert, um in einem HTML Option field zum Einsatz zu kommen. Selected gibt den Primärschlüssel des defaultmäßig ausgewählten Eintrages an. Ist selected = 0, dann wird kein Eintrag ausgewählt. Beispiel : (Rückgabewert für selected=12): <option value= ‘‘12’’ SELECTED>Gebucht<//option> <option value= ‘‘13’’>Verfügbar<//option> ANHANG D. DIE BUSINESS LOGIK 81 Es wird in diesem Beispiel ersichtlich, dass alle getCBxxx Methoden direkten HTML code zurückliefern. Diese ist eine Ausnahme. Alle anderen Methoden liefern nur Rohdaten zurück, die von einer upper Layer (ASP Scripts in dieser Implementierung) erst präsentiert werden müssen. function load(calendarid: Integer): Recordset Liefert einen ADO Recordset, der nur den mit calendarid angegebenen Eintrag enthält, zurück. Diese Funktion wird zum Editieren bereits vorhandener Einträge benötigt. Im entsprechenden ASP Script werden die Form Elemente mit den hier zurückgegebenen Werten aufgefüllt. D.3 CUST.DLL (Interface: Customer) Kapselt einen Kunden. Da der Umgang mit einem Kunden sich im Grunde auf Datenbankabfragen beschränkt, wurde das Objekt auch entsprechend einfach gehalten. Die notwendige Funktionalität bietet in diesem Fall ADO. Zusätzlich benötigte Hilfsfunktionen, wie das Anzeigen eines Option Formobjektes mit Firmenbranchen, sind im Objekt Misc hinterlegt. function load(customerid: Integer): Recordset Liefert einen ADO Recordset zurück, der den Kunden mit der angegebenen Customerid enthält. Die Customerid erhält man innerhalb des ASP Scriptes durch das Session Objectes (Session(“userid”)). Mit dem zurückgelieferten Recordset kann man Kundendaten verändern, sowie einen neuen Kunden anlegen. procedure addMapping(loginid, customerid: Integer) Registriert sich ein neuer Kunde, so erzeugt das security object die Zugangsdaten. Unter Zuhilfenahme der Methode load() wird dann ein neuer Kunden angelegt. Die Methode addMapping erzeugt nun eine Relation, die die Verbindung zwischen Kundendaten und Login herstellt. Wichtig ist, dass vor dem Aufruf von AddMapping die Parameter loginid und customerid gültige Primärschlüssel der Tabellen LOGIN und CUSTOMER sind. D.4 MISC.DLL (Interface : Misc) function getCBStateOptions(stateid: Integer): WideString Liefert alle möglichen Staaten für eine HTML Combobox zurück. Stateid gibt an, welcher Eintrag ausgewählt sein soll. 0 bedeutet, dass kein Eintrag ausgewählt wird. ANHANG D. DIE BUSINESS LOGIK 82 function getCourseList(optional categorieid: Integer): Recordset Liefert einen ADO Recordset zurück, der alle Kurse der angegebenen Kategorie zurückliefert. Zum genaueren Verständnis welche Daten genau in diesem Recordset sind, ist hier der SQL Querystring cmd abgebildet. cmd := ’Select course.*, courseduration.caption as cc ’+ ’from course, courseduration ’+ ’WHERE course.coursedurationid=courseduration.’+ ’coursedurationid and course.available=1’; if categorieid >0 then cmd := cmd+’ and coursecategorieid=’+inttostr(categorieid); cmd := cmd +’ ORDER BY course.caption’; function getLanguageList: Recordset Liefert einen ADO Recordset mit allen gespeicherten Sprachen zurück. function getCBBranchOptions(selected: Integer): WideString Liefert alle gespeicherten Branchen als Option Felder für eine HTML Combobox zurück. Selected gibt an, welcher Eintrag ausgewählt sein soll. 0 bedeutet, dass kein Eintrag ausgewählt wird. function getCBNoticeOptions(selected: Integer): WideString Liefert alle gespeicherten Orte zurück, die angeben, woher ein Kunde diese Site kennt, als Option Felder für eine HTML Combobox zurück. Selected gibt an, welcher Eintrag ausgewählt sein soll. 0 bedeutet, dass kein Eintrag ausgewählt wird. function getCourseCategorieList: Recordset Liefert einen ADO Recordset mit allen gespeicherten Kurskategorien zurück. function getCBCourseOptions(selected: Integer): WideString Liefert alle gespeicherte Kurse als Option Felder für eine HTML Combobox zurück. Selected gibt an, welcher Eintrag ausgewählt sein soll. 0 bedeutet, dass kein Eintrag ausgewählt wird. function getCBLanguageOptions(selected: Integer): WideString Liefert alle gespeicherten Sprachen als Option Felder für eine HTML Combobox zurück. Selected gibt an, welcher Eintrag ausgewählt sein soll. 0 bedeutet, dass kein Eintrag ausgewählt wird. ANHANG D. DIE BUSINESS LOGIK 83 function getCBStartTimeOptions(selected: Integer): WideString Liefert alle möglichen gespeicherten Startzeiten als Option Felder für eine HTML Combobox zurück. Selected gibt an, welcher Eintrag ausgewählt sein soll. 0 bedeutet, dass kein Eintrag ausgewählt wird. function getCBDurationOptions(selected: Integer): WideString Liefert alle gespeicherten Möglichkeiten für eine Kursdauer als Option Felder für eine HTML Combobox zurück. Selected gibt an, welcher Eintrag ausgewählt sein soll. 0 bedeutet, dass kein Eintrag ausgewählt wird. D.5 SEC.DLL (Interface Security) Das Security Objekt stellt Methoden zur Verfügung, die es erlauben, den eingeloggten Benutzer zu identifizieren, sowie neue Benutzer anzulegen. Das Security Objekt wurde so entwickelt, dass es auch für andere Anwendungen einsetzbar ist. Bei der Eingabe seiner Zugangsdaten, function addLogin(usergroupid: Integer): Integer erstellt einen neuen Datensatz in der Tabelle LOGIN. Es wird dabei ein zufälliges Passwort erzeugt. Rückgabewert dieser Funktion ist die loginid. function loadlogin(loginid, password: WideString): Integer Sucht in der Datenbank, ob ein User mit obigen Zugangsdaten existiert. Rückgabewert: userid > 0 falls Eingabe korrekt oder <0 falls eine falsche loginid oder ein falsches Passwort eingetragen wurde. function usergroup: Integer Liefert die Usergroup des aktuell eingeloggten users zurück. Vor dem ersten Aufruf von usergroup() muss loadLogin() aufgrufen worden sein. function userid: Integer Liefert die userid des aktuell eingeloggten Users zurück. Vor dem ersten Aufruf von userid() muss loadLogin() aufgerufen worden sein. Die Userid ist dabei entweder HUMANRESOURCE.humanresourceid oder CUSTOMER.customerid je nach erfolgtem Login. Es wird also das Mapping bereits mitberechnet. ANHANG D. DIE BUSINESS LOGIK D.6 84 TRAIN.DLL (Interface: Trainer) function load(trainerid: Integer): recordset Liefert von der Tabelle HUMANRESOURCE den ADO Recordset zurück wobei der Cursor auf den Datensatz des übergebenen trainerid zeigt. procedure addMapping(loginid, trainerid: Integer); Registriert sich ein neuer Trainer, so erzeugt das security object die Zugangsdaten. Unter Zuhilfenahme der Methode load() wird dann ein neuer Trainer angelegt. Die Methode addMapping erzeugt nun eine Relation, die die Verbindung zwischen Trainerdaten und Login herstellt. procedure setAbility(trainerid, courseid, languageid: Integer; knowledgefaktor: Double Setzt die Fähigkeiten, des mit trainerid angegeben Trainers. Eine Fähigkeit im Zusammenhang mit rent@trainer, ist immer die Fähigkeit einen Kurs in einer bestimmten Sprache zu halten. Um die Fähigkeiten eines Trainers genauer zu differentieren, hat der Administrator noch die Möglichkeit mittels Knowledgefaktor die Qualität dieses Trainers für diesen Kurs in dieser Sprache anzugeben. Knowledgefaktor muss zwischen 0 und 1 liegen. Bei der Auswahl eines Trainers kann man nun einen unteren Schwellwert als Parameter angeben, wie hoch der Knowledgefaktor mindestens sein muss, damit ein Trainer überhaupt für einen Kurs berücksichtigt wird. Sollte bereits ein Eintrag mit den angegebenen Daten existieren, so wird der alte Datensatz mit dem neuen Knowledgefaktor überschrieben. procedure deleteAbility( trainerid, courseid, languageid: Integer) Löscht den angegbenen Eintrag aus der Datenbank procedure loadAbilityList(trainerid: Integer) Lädt alle Fähigkeiten des mit trainerid angegebenen Trainers aus der Datenbank in den Speicher, um mit getAbility dann schnell abgerufen werden zu können. function getAbility( courseid, languageid: Integer): Double ANHANG D. DIE BUSINESS LOGIK 85 Liefert den Knowledgefaktor des Trainers der angegebenen courseid und languageid zurück. Vor dem ersten Aufruf von getAbility() muss loadAbilityList() aufgerufen worden sein. procedure clearAbilities(trainerid: Integer) Löscht alle Fähigkeiten des mit trainerid angegebenen Trainers. D.7 BOOKINGS.DLL (Interface: Booking) function calculateOffers: Integer Berechnet Angebote mit den angegebenen Parametern. Die Parameter müssen vor dem Aufruf von calculateOffers() definiert werden. Diese Methode speichert alle errechneten Angebote in der Datenbank ab. Rückgabewert: Anzahl der erfolgreich errechneten Angebote. Im folgenden werden alle Parameter beschrieben. Diese sind als Properties definiert und können, wenn nicht anders angegeben, geschrieben und gelesen werden. CourseId : Integer Gibt den gewünschten Kurs an. (COURSE.courseid) languageid: Integer Gibt die gewünschte Sprache an. customerid: Integer Gibt den Kunden an, der die Anfrage gemacht hat. starttimeid: Integer Gibt die gewünschte Startzeit an. Die Definition der Startzeit wurde bereits weiter oben diskutiert. durationid: Integer Gibt die gewünschte Dauer des Kurses an. Die Definition der Dauer wurde bereits weiter oben diskutiert. Trainercount: Integer Gibt die gewünschte Anzahl an Trainern an. ANHANG D. DIE BUSINESS LOGIK 86 documentcount: Integer Gibt die gewünschte Anzahl von Dokumenten an. plz: Integer Gibt die gewünschte Postleitzahl des Kursortes an. place: WideString Gibt den gewünschten Kursort an. address: WideString Gibt die Strasse des gewünschten Kursortes an. contactperson: WideString Gibt die Kontaktperson des Kunden an. Standardmäßig ist dies der eingeloggte User. Dies kann aber vom User bei einer Anfrage noch geändert werden. email: WideString Gibt die e-mail der Kontaktperson an. telephone: WideString Gibt die Telephonnummer der Kontaktperson an. stateid: Integer Gibt den Staat des Kursortes an. maxOffers: Integer Gibt an, wieviel Angebote calculateOffer maximal errechnen soll. minKnowledgefactor: Double Gibt den minimalen Knowledgefaktor für einen Trainer an. Hat ein Trainer einen geringeren Wert als hier angegeben, wird er von vornherein nicht berücksichtigt. maxSearchIntervall: Integer Gibt die Zeit in Tagen an, wieweit in die Zukunft die Funktion calculateOffers() nach freien Terminen suchen soll. ANHANG D. DIE BUSINESS LOGIK 87 OtherCustomerFeedbackWeight: Double Gibt die Gewichtung von Feedbacks anderer Kunden im Verhältnis des aktuellen Kunden an. Der Wert “0.5” für OtherCustomerFeedbackWeight bedeutet, dass andere Feedbacks nur halb so stark bewertet werden. FeedbackAgeWeight: Double Gibt die Gewichtung für ältere Feedbacks an. ReferenceValue:double Gibt den Wert für das Referenzranking an. ReferenceWeight: Double Gibt den Wert für die Gewichtung des Referenzrankings an. ReferenceAge:TdateTime Gibt den Zeitpunkt an, der für das Referenzranking angenommen wird. MinDefaultTrainerRanking : double Gibt das minimale Ranking eines Trainers aus den Feedbacks an, sodass dieser als Stammtrainer für den aktuellen Kunden gilt. minranking: Double Gibt das minimale Ranking eines Trainers aus den Feedbacks an, sodass dieser für das aktuelle Angebot berücksichtigt wird. FeedbackOtherCoursesWeight: Double Gibt die Gewichtung von Feedbacks anderer Kurse im Verhältnis zu diesem Kurs an. Der Feedbacks des aktuellen Kurs hat die Gewichtung “1”. startdate: TdateTime Gibt das Datum an, ab wann calculateOffers nach freien Terminen suchen soll. notescount: Integer Gibt die Anzahl von Unterlagen an, die für diesen Kurs benötigt werden. EmptyRanking:Double Gibt das Ranking eines Trainers an, der noch keine Beurteilung erhalten hat. Dies wird für die gleichmäßige Aufteilung von Trainern benötigt. ANHANG D. DIE BUSINESS LOGIK 88 function getOfferCount: Integer Nach dem Aufruf von calculateOffers() kann man mit getOfferCount die Anzahl der errechneten Angebote erhalten. Function getOffer(index: Integer): offer Liefert ein Angebot Objekt zurück. Index muss zwischen 0 und getOfferCount-1 liegen. D.8 OFFERS.DLL (Interface Offer) Das Object Offer sollte nicht explizit erzeugt werden. Das Object Booking erzeugt alle möglichen Offer Objekte. Diese erhält man mit Booking.getOFfer() D.8.1 Methoden procedure addDay(day: Integer) Fügt einen Kurstag zum Angebot hinzu. Eine explizite Speicherung aller Kurstage ist notwendig, da ein Kurs über mehrere Tage gehen kann, und die Kurse auch an nicht aufeinanderfolgenden Tagen stattfinden können. Diese Funktion wird vom User im Allgemeinen nicht direkt aufgerufen. Sie wird ausschließlich vom Booking Objekt aufgerufen. function daycount: Integer Liefert die Anzahl der Kurstage für dieses Angebot zurück. procedure store(courseid, queryid, trainercount, notescount: Integer; startdate: TDateTime; durationid, starttimeid: Integer; drivingprice: Double) Speichert dieses Angebot in die Datenbank. Diese Funktion wird nur intern vom Bookingobjekt aufgerufen. procedure addTrainer(humanresourceid: Integer) Fügt einen Trainer zum Angebot hinzu. Diese Funktion wird nur intern vom Bookingobjekt aufgerufen. function offerid: Integer Liefert die Angebotsnummer dieses Angebots zurück. function getDay(index: Integer): TdateTime Liefert den, mit index angegebenen Kurstag zurück. function getDrivingPrice: Double ANHANG D. DIE BUSINESS LOGIK 89 Gibt die verrechneten Fahrtkosten dieses Angebots an. function getTeachingPrice: double Gibt die verrechneten Kurskosten dieses Angebots an. function getNotesPrice: Double Gibt die verrechneten Unterlagenkosten dieses Angebots an. D.9 ORDERS.DLL (Interface: ORDER) function makeorder(offerid: Integer): Integer Generiert aus dem angegebenen Angebot eine verbindliche Buchung. Aus einer Anfrage entstehen also mehrere Angebote. Aus diesen Angeboten wird nun genau eine Buchung. Beim Erstellen der Buchung werden alle Angebote als abgelaufen markiert. Dies ist notwendig, falls ein Kunde auf den Back Button des Browsers klickt, um alle erhaltenen Angebote aus dem Browser Cache wieder anzuzeigen. Es muss nun verhindert werden, dass der Kunde durch erneutes Drücken des “Buchen Links” erneut bucht. Durch das Markieren der Angebote kann nun überprüft werden, ob ein Kunde eine Buchung doppelt klickt. D.10 MSG.DLL (Interface: Messager) Messager übernimmt die e-mail Kommunikation. Nach rein objekt-orientierten Gesichtspunkten müssten die Objekte Trainer, Customer und Order die Methoden von Messager aufrufen, da diese für die Registrierung von Usern bzw. für das Abwickeln von Buchungen zuständig sind. Anwendung wurde aber so designed, dass alle Methodenaufrufe nur von ASP Scripts durchgeführt werden. Dadurch ist gewährleistet, dass man die Parameter SMTPHost , from und fromaddress später leicht ändern kann. procedure sendMail(const SMTPHost, fromaddress, from, toAddress, tobcc, subject, body: WideString); safecall; Sendet eine e-mail über SMTPHost an toAddress und tobcc. From gibt den Namen des Absenders, fromaddress die e-mail Adresse desselben an. procedure sendSMS(prenumber, mainnumber: Integer; const subject:WideString); safecall; ANHANG D. DIE BUSINESS LOGIK 90 Sendet eine sms an die angegebene Nummer. prenumber gibt die Vorwahl des Handys an (0664, 0669, 0676). Mainnumber steht für die eigentliche Nummer. Subject ist schließlich der Text, der via SMS versandt werden soll. Abbildungsverzeichnis 2.1 Datenfluss für einen benötigten Trainer . . . . . . . . . . . . . . . . . . . . 11 2.2 Datenfluss für mehr benötigte Trainer . . . . . . . . . . . . . . . . . . . . . 12 2.3 Datenfluss für fixe Kurszeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1 CGI Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 Eine direkte Verbindung zu einem Objekt auf dem gleichen Computer, im gleichen Adressraum und Apartment wie der Client 4.3 . . . . . . . . . . . . . 28 Eine indirekte Proxy/Stub-Verbindung zu einem Objekt, das an einem anderen Ort existiert . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.4 Ein Kontext-Wrapper als eine separate Schicht im Microsoft Transaction Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.5 Interception durch Policy-Objekte . . . . . . . . . . . . . . . . . . . . . . . 29 4.6 Eine Serverapplikation, die in einem separaten Adressraum ausgeführt wird 4.7 Eine Bibliotheksapplikation, die im Adressraum der Clientanwendung aus- 30 geführt wird . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.1 Objekt Relationen Teil 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.2 Objekt Relationen Teil 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.1 Datenbankstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.1 Public Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 9.2 Trainer Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 9.3 Trainer Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 9.4 Startseite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 9.5 Kunden Registrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 9.6 Trainer Registrierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 9.7 Buchungsformular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 9.8 Trainer Kalender . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 9.9 Kursportfolio: Beispiel MS Visual Basic . . . . . . . . . . . . . . . . . . . . 58 91 ABBILDUNGSVERZEICHNIS 92 9.10 Buchungsformular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Tabellenverzeichnis 4.1 Ergebnisse Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2 Ergebnisse Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 93 Literaturverzeichnis [MSO] http://www.mircosoft.com [Bün00] Uwe Bünning: PC Intern. Dynamische Webseiten mit ASP, Data Becker 2000 [Buc00] Greg Buczek: ASP Developers Guide - Active Server Pages für Entwickler, Franzis 2000 [Dat98] Chris J. Date: SQL-Der Standard, Addison-Wesley 1998 [Cha96] David Cappel: ActiveX and OLE, Microsoft Press 1996 [Hof96] Manfred Hofbauer: ACCESS 7 für Windows 95, SYBEX 1996 [DNJ100] Jon Honeyball: Developer Network Journal, MSDN July/August 2000 [CT991] c’t Magazin 8/99. CGI aber schnell, Heise Verlag 1999 [Bar99] Hans-Jochen Bartsch: Taschenbuch Mathematischer Formeln, Fachbuchverlag Leibnitz 18. Auflage 1999 [Kol00] ADO und ASP - Datenbanken einmal näher betrachtet: http://www.aspheute.com/artikel/19990825.htm 2000 [MSO2] ADO Programming Model: http://www.microsoft.com/data/ado/prodinfo/progmod.htm, 1997 [Dob00] Walter Doberenz, Thomas Kowalski: Borland Delphi 5 Grundlagen und Profiwissen, Verlag Carl Hanser 2000 [Kos991] Andreas Kosch: Client/Server Datenbankentwicklung mit Delphi, Software und Support Verlag 1999 [Kos992] Andreas Kosch: COM/DCOM mit Delphi, Software und Support Verlag 1999 [Qui99] Klaus Quibeldey-Cirkel: Entwurfsmuster. Design Patterns in der objektorientierten Softwaretechnik, Springer-Verlag Berlin Heidelberg 1999 94 LITERATURVERZEICHNIS 95 [Gam95] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns, Addison-Wesley 1995 [Alg98] Robert Sedgewick: Algorithmen, Addison-Wesley, 1992
