Home

Dokument 1

1. Von langen Listen werden nur die momentan ausgew hlten Elemente in einer eigenen Liste pr sentiert ber einen Button kann ein eigenes Dialogfenster ge ffnet werden das die Ver nderung der Teilmenge durch Auswahl aus der Gesamtmenge erlaubt 3 1 2 3 Eingabedialoge Der typische Eingabedialog besteht aus einer Menge von Eingabefeldern Aus wahllisten und anderen berfl chenelementen zur Datenerfassung sowie den zwei Buttons OK zur Best tigung der Eingabe und bernahme der Werte und Abbruch zur Beendigung des Dialogs ohne die eingegebenen Werte zu ber nehmen Die Klasse TRO GUI OKCancelDialog bietet diese Grundfunktionali t t an S mtliche Eingabedialoge im Programm TROSS erben von dieser Klasse und besitzen dadurch ohne zus tzliche Programmierung diese zwei grundlegen den Buttons die auch ber die Tasten Enter bzw Escape ausgel st werden k nnen Die Aktivierung eines dieser Buttons ruft die passende Methode der Dialog klasse auf die sich gegebenenfalls um das Auslesen der Werte k mmert unter Benutzung des in 3 1 2 1 beschriebenen zweistufigen Mechanismus und dann den Dialog schlie t 3 1 2 4 Unterteilte Dialoge Register Da einige Datenobjekte eine Vielzahl an Eingaben erfordern wurde im Verlauf der Implementierung bald der Punkt erreicht an dem die entstehenden Einga bemasken nicht mehr vollst ndig auf den Bildschirm pa ten Auch aus Gr nden der bersichtlichkeit war hier eine Untertei
2. Dann wird das Programm mit folgendem Aufruf gestartet jre cp java lib classes zip tross tross jar TRO Tross 69 70 KAPITEL 7 BEDIENUNGSANLEITUNG 7 3 Grundlegende Konzepte 7 3 1 Erweiterbare Listen An vielen Stellen des Programms werden Listen angezeigt die vom Benutzer beliebig erweitert oder verkleinert werden k nnen Dazu dienen die Buttons Einf gen ndern und L schen rechts neben der Liste Diese haben folgende Bedeutung Einf gen ffnet einen Eingabedialog um ein neues Element einzugeben Schlie t der Benutzer seine Eingabe mit OK ab wird das neue Element an der passenden Stelle in der Liste eingef gt ndern Dieser Button hat nur dann eine Funktion wenn ein Element der Liste durch Anklicken ausgew hlt wurde Dann wird ein Dialogfenster ge ffnet um die Daten des gew hlten Elements zu ndern Nach Best tigung der Eingabe erscheint das Element im ge nderten Zustand in der Liste L schen Auch hierzu mu ein Element ausgew hlt sein Dieses wird aus der Liste gel scht falls keine Konsistenzbedingungen dies verbieten 7 3 2 Eingabedialoge Jeder Eingabedialog egal ob zur Erfassung eines neuen Datenobjekts oder zur nderung eines bestehenden hat am unteren Rand zwei Buttons OK und Abbruch Mit OK wird die Eingabe best tigt und alle nderungen ber nommen Bei Abbruch werden alle direkten nderungen verworfen und das Datenobjekt bleibt im urspr
3. 7 5 KUNDEN 75 Abbildung 7 1 Eingabedialog f r Ort und Zeit Schulfahrten Dialysefahrten und Fahrten zur Tagespflege Hier k n nen folgende Anforderungen erfa t werden e Die Art des ben tigten Platzes im Fahrzeug Sitzplatz Rollstuhlplatz oder Sitzplatz mit fest montiertem Hilfsmittel einer bestimmten Art e Die Forderung da ein zweiter Mitarbeiter bei der Auf hrung des Dienstes dabei sein mu e die erforderlichen Qualifikationen des oder der Mitarbeiter e Die Vorlieben und Abneigungen des Kunden sind hier zur Information nochmals angezeigt eine nderung wirkt sich aber stets auf die Kunden daten aus gilt also f r alle Dienstw nsche F r die Fahrt mu ein Startort angegeben werden an dem der Kunde abgeholt werden soll und ein Zielort zu dem der Kunde gebracht wird Die Angaben zur Zeit sind in Daten f r die Hin und R ckfahrt eingeteilt Die Zeiten f r die R ckfahrt kommen allerdings nur dann zur Geltung wenn die Checkbox R ckfahrt angekreuzt ist F r jede dieser Teilfahrten k nnen Abholzeit und Ankunftszeit vorgegeben werden sowie die ben tigten Zeitdauern zum Ein und Aussteigen in das bef rdernde Fahrzeug Die Zeiten sind jeweils als Zeitspanne definiert so da eine gew nschte Toleranz explizit angegeben 76 KAPITEL 7 BEDIENUNGSANLEITUNG werden kann Von den vier m glichen Uhrzeitangaben mu nur eine angegeben werden z B bedeutet der Eintrag 8 00 Uhr bei Ankunft bis d
4. class 61 implements TRO GUI ObjektListePanel ElementListener class TRO GUI Kunden KundenListePanel implements TRO GUI ObjektListePanel ElementListener class TRO GUI Ressourcen MitarbeiterListePanel implements TRO GUI ObjektListePanel ElementListener class TRO GUI Touren StationenListePanel implements java awt event ActionListener TRO GUI ObjektListePanel InformationListener class TRO GUI Dienste StationenPanel implements TRO GUI ObjektListePanel ElementListener TRO GUI ObjektListePanel InformationListener java awt event ActionListener class TRO GUI Dienste ZahlerPanel implements TRO GUI ObjektListePanel ElementListener TRO GUI ObjektListePanel InformationListener class TRO GUI Kunden PersonPanel class TRO GUI Dienste QualifikationsPanel class TRO GUI StationPanel implements java awt event ActionListener class TRO GUI Dienste TerminPanel implements TRO GUI ObjektListePanel ElementListener class TRO GUI Touren TourQualifikationsPanel class TRO GUI Touren TourVorliebenPanel class TRO GUI Kunden VorliebenPanel class TRO GUI ZeitraumPanel implements TRO GUI ObjektListePanel ElementListener TRO GUI Touren TourenListePanel TRO UVeberTrossPanel TRO GUI UhrzeitPanel TRO GUI ZeitdauerPanel TRO GUI ZeitspannePanel class java awt Window class java awt Dialog class TRO GUI AnbindungspunktWahlDialog implements java awt event ActionListener class TRO GUI De
5. 7 7 2 Fahrzeuge Zeigt eine nderbare Liste aller Fahrzeuge an 7 8 AUSGABE 83 7 7 2 1 Eingabedialog f r Fahrzeuge Ein Fahrzeug wird durch Angabe von Modell amtlichem Kennzeichen sowie einer internen Nummer identifiziert im Programm TROSS dient die interne Nummer als Unterscheidungsmerkmal z B in der Liste aller Fahrzeuge Drei wichtige Termine k nnen f r jedes Fahrzeug erfa t werden Die n chste Hauptuntersuchung beim T V die n chste ASU sowie der n chste Kunden dienst Beim Laden eines Szenarios werden diese Werte mit dem Tagesdatum verglichen und dem Benutzer gemeldet falls sie innerhalb der n chsten zwei Wochen f llig werden Die Austattung eines Fahrzeugs wird durch die Eingabefelder spezielle Da ten definiert F r jedes definierte Hilfsmittel kann die Anzahl der davon im Fahrzeug mitgef hrten Exemplare angegeben werden gemeint sind hier nur lose Hilfsmittel wie z B spezielle Sitzkissen die einfach auf einem Sitzplatz an gebracht und wieder von dort entfernt werden k nnen fest montiere Hilfsmittel werden in der Fahrzeugkonfiguration erfa t Durch Auswahl eines Fahrzeugtyps und einer diesem Typ zugeordneten Fahr zeugkonfiguration wird der m gliche sowie momentane Umbauzustand des Fahrzeugs beschrieben siehe hierzu auch 7 10 3 und 7 10 3 2 7 8 Ausgabe 7 8 1 Tourplan Zeigt eine Tour mit allen Untertouren schematisch an Hieraus k nnen sowohl der Benutzer als auch die ausf hrenden Mi
6. ArbeitszeitProfil VollzeitProfil TeilzeitTageProfil TeilzeitStundenProfil ArbeitszeitProfil abstrakt e Attribute bezeichnung String Bezeichner mit dem verschiedene Arbeitszeitpro file identifiziert und auseinandergehalten werden k nnen e Methoden abstrakt art int Die Unterklassen geben hier jeweils ihre Art zur ck VollzeitProfil ArbeitszeitProfil e Attribute zeitProWoche int w chentliche Arbeitszeit in Minuten maxZeitProTag int H chstgrenze f r die t gliche Arbeitszeit in Minu ten TeilzeitTageProfil ArbeitszeitProfil e Attribute zeitProTag Zeitspanne F r jeden Wochentag die Zeitspanne an der der Mitarbeiter arbeitet maxZeitProTag int H chstgrenze f r die t gliche Arbeitszeit in Minu ten Eine Zahl die f r alle Wochentage gleicherma en gilt TeilzeitStundenProfil ArbeitszeitProfil e Attribute zeitProMonat int monatliche Arbeitszeit in Minuten maxZeitProTag int H chstgrenze f r die t gliche Arbeitszeit in Minu ten S mtliche Werte sind Mu werte Diese drei Arbeitszeitprofile stellen einen Kompromi dar zwischen Erfas sung aller M glichkeiten von Teilzeitarbeit und sinnvollem Aufwand bei der programminternen Realisierung und auch der Dateneingabe Ein Mitarbeiter der nur Montags oder Dienstags eingesetzt werden kann aber eine monatliche Arbeitszeit von 50 Stunden hat kann mit den vorliegenden Arbeitszeitprofilen nic
7. Datenhaltung in TROSS 3 3 UMSETZUNG DES ENTWURFS IN DER IMPLEMENTIERUNG 35 Neben dem Dateimanagement bieten die Szenarien auch objekt bergreifende Methoden z B Verwaltung benannter Stationen an Im Gegensatz zum Feinentwurf werden nicht alle Objekte direkt von den Szenarien referenziert sondern nur solche die nicht von anderen Objekten refe renziert werden oder die in globalen Listen vorgehalten werden z B benannte Stationen Mitarbeiter Qualifikationen etc Im folgenden nun die Beschreibung zur Implementierung der Verwaltungs klassen 3 3 2 1 Szenario e Attribute name String Schl ssel Name des Szenarios geaendert Boolean Ist true wenn der Datenbestand ge ndert wurde mitarbeiter SortierterVektor Referenz auf alle Mitarbeiter des Sze narios kunden SortierterVector Referenz auf alle Kunden des Szenarios institutionen SortierterVektor Referenz auf alle Institutionen des Szenarios qualifikationen SortierterVektor Referenz auf alle Qualifikationen des Szenarios fahrzeuge SortierterVektor Referenz auf alle Fahrzeuge des Szena rios fahrzeugtypen Sortierter Vektor Referenz auf alle Fahrzeugtypen des Szenarios stationen SortierterVektor Referenz auf alle benannten Stationen des Szenarios essensarten SortierterVektor Referenz auf alle Essensarten des Sze narios hilfsmittel Sortierter Vektor Referenz auf alle Hilfsmittel des Szena rios arbeitszeitProfile SortierterVektor Refer
8. de der Algorithmus der bereiteVor Methode die alle Entfernungen zwischen den angegebenen Knoten ermittelt und in der Entfernungstabelle speichert ge ndert Dabei ist N die Menge der Knoten N also die Anzahl der Knoten und N O der erste Knoten Jeder Knoten wird als Menge von Kanten gedacht soda In die Anzahl der von Knoten n N ausgehenden Kanten angibt Diese werden in einer Record Schreibweise als n Kanten bezeichnet n Kanten 0 ist also die in irgendeiner Hinsicht erste der vom Knoten n ausgehenden Kanten proc bereiteVor N Menge von Knoten while n sucheStartKnoten fahreNach n while n naechsterKnoten n fahreNach n D teilAuftragStarten D proc sucheStartKnoten if 3 n E N mit n ungerade 20 KAPITEL 2 NACHTRAG ZUM ENTWURF return n else if NI 0 return null else return N 0 func Knoten naechsterKnoten Knoten n if a 0 return null return n Kanten 0 proc fahreNach Knoten n schreibt den Knoten in die Auftrags Datei wenn schon 20 Knoten geschrieben wurden teilAuftragStarten proc teilAuftragStarten uebergibt die Datei an Map amp Guide warte auf Map amp Guide werte das Ergebnis aus Da die momentane Implementierung dieses Algorithmus auf naheliegende Op timierungsans tze verzichtet ergibt sich bereits f r die Suche nach dem n chsten Startknoten eine Laufzeit von O gesuchte Kanten Ermittlung d
9. dieser Adressen gilt als Wohnort des Kunden der als Vorgabewert f r Dienstw nsche benutzt wird z B Abholadresse f r Fahrten Kommunikationsverbindungen Eine Kommunikationsverbindung besteht aus der Art z B Telephon und dem Eintrag z B 0815 4711 Bankverbindungen Bankverbindungen bestehen aus Bankname Bankleit zahl Kontonummer und der Angabe ob f r dieses Konto eine Einzugser m chtigung vorliegt Dienstbezogene Daten Vorlieben und Abneigungen Definiert Mitarbeiter die der Kunde gerne f r seine Dienstw nsche eingesetzt h tte dies ist eine Soll Vorgabe und sol che die auf keinen Fall bei dem Kunden eingesetzt werden d rfen dies ist eine Mu Vorgabe Der Button ndern unter der jeweiligen Liste ffnet ein Fenster worin diese Liste ver ndert werden kann indem Mitarbeiter entfernt oder weitere aus der Gesamtliste eingef gt werden Ben tigte Hilfsmittel Hier k nnen aus der Liste der definierten Hilfsmittel siehe 7 10 6 diejenigen ausgew hlt werden die der Kunde ben tigt Hier mit kann z B ein Abgleich zwischen geforderten Kindersitzen und tat s chlich im Fahrzeug vorhandenen stattfinden Das Programm macht dies jedoch nicht Zul ssige Fahrzeuge Darf ein Kunde nur mit bestimmten Fahrzeugen be f rdert werden k nnen diese hier ausgew hlt werden Ist die Liste leer kommt prinzipiell jedes Fahrzeug in Frage Bezugspersonen Hier k nnen beliebige Personen erfa t werden deren D
10. so wurden zugewiesene aber vom Kunden abgelehnte Mitarbeiter korrekt ent deckt Auf mehrfach verplante Mitarbeiter und Fahrzeuge wurde jedoch nicht hingewiesen 4 1 4 Test der Men punkte Ressourcen Ausgabe Analy se und Einstellungen 4 1 4 1 Vorgehensweise In diesem Testabschnitt sollten die Eingabemasken f r Mitarbeiter Fahrzeuge und die systemweit bekannten Daten Einstellungen sowie die Ausgabe und Analysefunktionen auf ihre Funktionalit t hin berpr ft werden Die Vorge hensweise f r den Test der Eingabemasken war folgende Eingabe neuer Daten auch falsche Formate ndern und L schen bestehender Daten F r den Test der Ausgabe und Analysefunktionen wurde auf schon bestehende Daten zuge griffen 4 1 4 2 Ressourcen Sowohl die Masken zur Neueingabe zum ndern und zum L schen von Mit arbeitern sowie die zur Manipulation der Fahrzeugdaten funktionieren im ge w nschten Umfang Bei der Neueingabe diverser Daten z B Adressen Kommu nikationsverbindungen eines f r das System neuen Mitarbeiters bzw Fahr zeugs erscheint im Titel des Fensters nicht der Name des Mitarbeiters bzw Fahrzeugs sondern null null Dies ist bedingt durch das Konzept des Zwei Phasen Commit welches s mtliche Eingaben nach Dr cken des OK Button erst pr ft und danach dem System bekannt macht 4 1 4 3 Ausgabe Die Men punkte zur Ausgabe waren zum Zeitpunkt an dem der Test durchge f hrt wurde teilweise noch nicht vollst ndig
11. und nur wenn in der Vorschlagsliste nur eine Alternative zur ckgegeben wird ist der Anbindungspunkt g ltig Die Alternativen werden dem Benutzer nur noch zur Hilfe angezeigt Als n chstes Problem trat in Map amp Guide eine falsch kodierte Stra e auf die Sommerrainstra e in Stuttgart Sommerrain ist in zwei Teile aufgeteilt deren Hausnummern Mengen nicht disjunkt sind Deshalb sind Hausnummern gr er 41 nie eindeutig In solchen F llen gibt es zwei M glichkeiten entweder einfach eine andere Hausnummer oder die geographischen Koordinaten als Anbindungs punkt eingeben n heres dazu steht im Handbuch von Map amp Guide CAS97 Um die Arbeitsweise von Map amp Guide zu beeinflussen gibt es zum einen die Parameterdatei param mgb zum anderen k nnen die Parameter aber auch an den Anfang der Auftragsdatei gestellt werden Nur funktionierte die zweite M glichkeit zun chst nicht Nach etlichen Stunden war die Ursache gefunden Wenn Map amp Guide die Parameterdatei nicht findet ignoriert es auch die Pa rameter in der Auftragsdatei Deshalb wird nun eine Parameterdatei angelegt wenn noch keine vorhanden ist Zu kl ren war auch die Frage wie viele Stationen Map amp Guide wohl in ei ner Anfrage schafft Im Handbuch steht nur da bei aktivierter Reihenfolge Optimierung der Stationen maximal 20 Zwischenstationen m glich sind Es stellte sich heraus da berhaupt nur 20 Stationen d h 19 Kanten m glich sind Dadurch wird die Anfrage
12. 2 2 7 8 4 Angezeigten Plan drucken 7 8 5 Untermenu Pl ne drucken CH Analyse u ss nenn 7 9 1 Auslastung Mitarbeiter 7 92 Ausfallzeiten 2 2222 222 200 7 9 3 Fahrzeugbesetzung 7 9 4 Auslastung Mitarbeiter drucken 7 9 5 Auslastung Fahrzeuge drucken 7 9 6 Ausfall Mitarbeiter drucken 7 9 7 Ausfall Fahrzeuge drucken 7 10 Einstellungen 2 222220 7 10 1 Qualifikationen 2 2 2 7 10 2 Arbeitszeitprofle 7 10 3 Fahrzeugtypen 2 2 2 2200 7 10 4 Institutionen 2 222 220 7 10 5 Stationen 7 10 6 Hilfsmittel 2 2 2222 22 7 10 7 Essensarten 7 10 8 Feiertage 2 22 wu Rh 7 10 9 Verkehrstool 2 2 22 22 7 10 10 Entfernungen korrigieren 7 10 11 Maximale Fahrzeit 8 Projektplanung 8 1 Planung f r das Projekt Transportoptimierung 8 1 1 Planung des Zeit und Kostenaufwandes 8 1 2 Meilensteine 2 2222 2222 8 1 3 Projektverlauf 22 2 202 8 1 4 Tats chlicher Zeit und Kostenaufwand 9 R ckblick 9 1 Zeitplanung 9 2 Umfang der Aufgabenstellung 9 3 Zust ndigkeiten und Kompetenzen in der Projektgruppe 9 4 Empfehlungen an zuk nftige Projektgruppen Literaturverzeichnis 83 83 83 83 83 83 84 84 84 85 85 85 85 85 85 85 85 86 86 86 87 87 87 87 88 88 89 89 89 90 91 93 95 95 96 96 96 98 Kapitel 1 Einf hrung 1 1 Der Bericht Di
13. 3 1 5 Kommunikationsverbindung Abgesehen von der Implementierung des Listenelements wurde gegen ber dem Feinentwurf keine Anderung vorgenommen e Attribute art String Mu wert Gibt die Art der Kommunikationsverbindung an Telefon Fax Email etc eintrag String Mu wert Zur Art passender Eintrag z B Telefon nummer Email Adresse etc Zus tzlich wurde das Interface Listenelement implementiert 3 3 1 6 Kunde Unterklasse von Person e Attribute kundenNr String Schl ssel Eindeutige Nummer welche den Kun den innerhalb des DRK identifiziert hausschluesselZahl int Anzahl der Haus bzw Wohnungsschl ssel die der Kunde dem DRK berlassen hat Dieses Attribut wurde we gen der einfacheren Handhabung als Integer statt als String imple mentiert hausSchluesselText String Beliebige Bemerkungen zu den Schl s seln beispielsweise vergebene Schl sselnummern f r welche T r etc maxFahrDauer int Gibt an wieviele Minuten ein Kunde maximal in einem Fahrzeug zubringen darf Die globalen Obergrenzen z B Schulfahrten max 2h bleiben davon unber hrt Im Feinentwurf wur de noch der Typ short vorgesehen bemerkung String wird jetzt aus der Oberklasse Person geerbt bezugsPersonen Vector Die zum Kunden geh renden Bezugsperso nen wie Hausarzt und Familienangeh rige Institutionen werden jetzt in einem eigenen Vektor ber cksichtigt Kundenbetreuer der Institu tionen k nnen nach wie vor als B
14. Auch der Gesamtdiensplan kann ebenso wie der Diensplan f r alle Objekte erzeugt werden die das DienstplanErstellbar Interface implementieren Dazu wird wie der die in 3 3 2 2 beschriebene Methode objektFahrten des Tourszenarios ver wendet die f r jedes Objekt einmal aufgerufen wird Der Aufwand liegt damit in O Anz d Objekte Anz d Fahrten Eine effizientere Methode w re das einmalige Durchlaufen aller Fahrten wobei f r jedes Objekt ein Z hler z B in einer Hashtable mitgef hrt wird Der Aufwand l ge dann wie bei objekt Fahrten in O Anz d Fahrten Wegen der Code Wiederverwendung und aus Zeitgr nden wurde diese Variante jedoch nicht implementiert 3 3 5 3 Tourplan Der Tourplan listet zu allen Touren die zugeh rigen Untertouren mit den ge planten Mitarbeitern dem geplanten Fahrzeug und den anzufahrenden Statio nen incl dortiger Ankunfts und Abfahrtszeit auf Zudem wird bei jeder Sta tion angegeben welche Personen ein oder aussteigen Ferner werden f r alle im Rahmen der Tour bef rderten Kunden die Bezugspersonen ausgegeben die beim zugeh rigen Dienstwunsch angegeben wurden 3 4 Probleme beim Umsetzen des Entwurfs 3 4 1 Unvollst ndige Details im Entwurf Einige Probleme bei der Umsetzung des Entwurfs r hrten daher da im Ent wurf nicht alles bis ins Detail zu Ende gedacht war Hier wurde insbesondere deutlich da sich manche sprachlich einfachen Konstrukte als t ckisch bei der Implementierung herau
15. Dienst wunsch einf gen kann dies wieder r ckg ngig gemacht werden Die Liste wird dann dementsprechend ver ndert so da nur diejenigen Stationen angezeigt werden die sich auf Dienstw nsche beziehen die der Fahrt noch zugeordnet sind Die Zeitangaben in der Liste sind die in der Untertour ermittelten Beim L schen von Dienstw nschen aus einer Fahrt werden sie nicht angepa t eine Erfassung dieser Zeiten w re sicher auch nicht sinnvoll da sonst alle Etappen zeiten von real durchgef hrten Fahrten notiert und im Programm gegebenen falls angepa t werden m ten 7 6 3 Fahrten erzeugen Erzeugt aus den Untertouren Fahrten f r einen vom Benutzer angegebenen Zeit raum Bereits bestehende Fahrten werden dadurch nicht beeinflu t Die neu erzeugten Fahrten werden zum Durchsehen und Bearbeiten aufgelistet 7 6 4 Fahrten archivieren Um erfolgte Fahrten archivieren zu k nnen bietet TROSS die M glichkeit diese in einem tabellarischen Format abzuspeichern siehe 2 2 2 4 Die entstehende Datei kann in eine Textverarbeitung Tabellenkalkulation oder Datenbank gela den und den Bed rfnissen des Anwenders gem aufbereitet werden Nach dem Speichern werden die archivierten Fahrten gel scht Achtung TROSS bietet kein Konzept zur Verwaltung der Historie von Tou ren Untertouren und Fahrten Fahrten im Tourszenario beziehen sich direkt auf den status quo der zugeordneten Untertour so da sich nderungen an ei ner Tour
16. Tourszenario machen Macht das aktive Tourszenario zum Master Tourszenario falls das momentan geladene Szenario das Master Szenario ist 7 4 6 Programm beenden Beendet das Programm Wurde das Szenario seit der letzten nderung nicht gespeichert erfolgt eine Sicherheitsabfrage 75 Kunden 7 5 1 Kundenliste Zeigt eine nderbare Liste mit allen Kunden des Szenarios an Diese sind alpha betisch nach Nachnamen sortiert 7 5 1 1 Eingabedialog f r Kunden Pers nliche Daten Hier werden folgende Daten erfa t Kundennummer Jeder Kunden braucht zur eindeutigen Identifikation eine Kundennummer da Namen mehrfach vorkommen k nnen Maximale Fahrdauer Zeitdauer die der Kunde bei einer Fahrt maximal im Fahrzeug verbringen darf Falls hier ein Wert angegeben wird hat dieser Vorrang vor dem global definierten Fehlt eine Angabe gilt die globale Obergrenze siehe 7 10 11 Anzahl Schl ssel Anzahl der Hausschl ssel des Kunden die dieser zur Durch f hrung von Diensten zur Verf gung gestellt hat Bemerkungen Schl ssel Beliebige Bemerkungen zu den Hausschl sseln Hier k nnte z B die Nummer stehen unter der dieser Hausschl ssel im Schl sselschrank zu finden ist 7 5 KUNDEN 73 Allgemeine Personendaten Name Der Nachname der Person Dieser Wert mu immer angegeben werden Vorname Der Vorname optional Geburtsdatum Das Geburtsdatum optional Adressen Jeder Person k nnen mehrere Adressen zugeordnet werden Die erste
17. Verzeichnis in dem Map amp Guide nach Auftrags Dateien sucht z B C MG41 Jobs timeOut int die Zeit in Sekunden die auf eine Antwort von Map amp Guide gewartet werden soll 2 2 ALLGEMEINE KONZEPTE 19 e Methoden speichern ObjectOutputStream speichert alle Daten des Verkehrs moduls laden ObjectInputStream l dt die Daten des Verkehrsmoduls aus dem angegebenen Stream starteVerkehrstool Moeglicher AnbindungsPunkt startet Map amp Guide und gibt ein Feld mit noch nicht korrekt angebun denen Stationen zur ck verwendeVerkehrstool Moeglicher AnbindungsPunkt wie starteVerkehrstool nur da Map amp Guide nicht neu gestartet wird anbindungInOrdnung Moeglicher AnbindungsPunkt boolean gibt true zur ck wenn die Anbindung in Ordnung sie he 3 6 ist oder das Verkehrstool nicht l uft Ersetzt sucheMoeglicheAnbindungsPunkte erstelleAnbindungsPunkt MoeglicherAnbindungsPunkt AnbindungsPunkt Erstellt einen AnbindungsPunkt Ist der m gliche Anbindungspunkt nicht gepr ft worden oder ist er nicht in Ordnung wird ein Dummy erstellt entferneAnbindungsPunkt AnbindungsPunkt macht den angege benen Anbindungspunkt ung ltig und entfernt ihn wenn er nicht nochmal verwendet wird aus den Tabellen Die Abfrage und Vorbereitungs Anfragen haben sich von der Schnittstelle her nicht ver ndert und wurden deshalb nicht wieder aufgef hrt Um die im Cache vorhandenen Entfernungen ber cksichtigen zu k nnen wur
18. an ob der TeilDienstwunsch zu einer Hin Fahrt geh rt Gibt es von einem Dienstwunsch keine R ckfahrten ist dieses Feld true e Methoden beginn Zeitspanne liefert die Zeitspanne innerhalb der der zugeh rige Dienstwunsch anfangen soll dauer Station int liefert die Aufenthaltsdauer an der angegebenen Station 2 2 2 2 UntertourHalt Ein weiteres Problem war die Zuordnung der Teildienstw nsche zu den Statio nen Wenn eine Station doppelt in einer Untertour vorkommt k nnen die Teil dienstw nsche nicht per Algorithmus auf die Stationen verteilt werden da der Benutzer eventuell eine andere Verteilung m chte Deshalb wurden die Eintr ge im Vector stationen um die dort behandelten Teildienstw nsche erweitert Zu dem wurde das Attribut umbenannt in halte und ist ein Vector mit Elementen vom Typ UntertourHalt 2 2 ALLGEMEINE KONZEPTE 17 e Erbt von StationMitZeiten e Attribute wuensche Vector enth lt die Dienstw nsche die an dem Halt behan delt werden Damit sind auch die Teildienstw nsche festgelegt da alle Teildienstw nsche eines Dienstwunsches in einer Untertour im mer gleich behandelt werden 2 2 2 3 StationMitZeiten Eine Record Klasse von der UntertourHalt erbt e Attribute station Station die Station zu der Zeiten gespeichert werden sollen ankunftsZeit Uhrzeit Die Ankunftszeit an der Station abfahrtsZeit Uhrzeit Die Abfahrtszeit an der Station 2 2 2 4 Fahrten W hrend der Impl
19. an das Verkehrsmodul zum Vorbereiten aller Entfernungen zwischen je zwei Stationen einer gr eren Menge eigentlich un brauchbar Ein geringe Verbesserung wird durch einen anderen Algorithmus erreicht siehe 2 2 3 Das Erkennen der Fehler von Map amp Guide ist nicht einfach da je nach Art des Fehlers manche Dateien erzeugt werden und andere nicht Eine Datei die sich bei einem Fehler immer ndert ist die Fehler Datei Error mgb Ihr Inhalt ist aber kaum f r eine Auswertung per Programm geeignet da die Anzahl der an geh ngten Zeilen schwankt Das Verkehrsmodul meldet nun einen Fehler wenn sich der Zeitstempel dieser Datei ge ndert hat kann aber keine genaueren An gaben zum Fehler machen Wenn nur Anbindungen gepr ft werden wird dieser Fehler ignoriert 3 7 ERFAHRUNGEN MIT JAVA 45 3 7 Erfahrungen mit Java 3 7 1 Javas Klassenbibliothek Javas Klassenbibliothek enth lt zwar alle grundlegenden Objekte und Funktio nen zur Verwaltung von Daten und Erstellung von graphischen Benutzungsober fl chen allerdings auch nicht mehr Semantisch h here Konstrukte sind bis auf Ausnahmen kaum zu finden vor allem das Abstract Window Toolkit AWT f r die Programmierung von Oberfl chen bietet nur die blichen Primitive die von den g ngigen Fenstersystemen direkt zur Verf gung gestellt werden Manche grundlegenden Konzepte die in anderen objektorientierten Program miersystemen zum Standard geh ren sind in Java noch unausgereift
20. aus der ent sprechenden Tour mu manuell erfolgen Auswirkungen auf die Untertouren und Fahrten konnten nicht getestet werden Szenario 8 Solche kurzfristigen nderungen werden vermutlich nicht ber das System laufen Falls doch m ssen die entsprechenden Fahrten ge ndert werden 2 Fahrten zu einer Untertour wobei jede einen Teil erledigt Dies konnte nicht getestet werden da es nicht m glich war Fahrten zu erzeugen 4 3 0 4 Individualfahrten Szenario 1 Dieses Szenario Kundin f hrt zum Arzt und wieder zur ck kann problemlos nachvollzogen werden Szenario 2 Bei der Eingabe dieses Szenarios einer Individualfahrt mit ei ner Zwischenstation blieb die Frage offen wann die Zwischenstation im System ber cksichtigt wird auf der Hinfahrt auf der R ckfahrt immer Au erdem kann nur angeben werden ob der Mitarbeiter zwischen der Hin und R ckfahrt 4 3 ABGLEICH MIT DEN ANFORDERUNGEN 55 anwesend sein mu f r Zwischenstationen ist keine Angabe m glich Eine an dere M glichkeit dieses Szenario so einzugeben da der Mitarbeiter dem DRK zwischen allen Stationen zur Verf gung steht w re die Aufspaltung des Dienst wunsches auf drei Individualfahrten Wohnung Friedhof Friedhof Gemein dehaus Gemeindehaus Wohnung Au erdem war es wegen Exceptions nicht m glich berhaupt Zwischensta tionen anzugeben Szenario 3 Entspricht abgesehen von der Anfangszeit dem Szenario 2 Szenario 4 Ist f r die Dateneingab
21. che integriert werden k nnen Das Auslesen und Setzen von Eingabewerten zusammengesetzter Dialoge soll atomar erfolgen Kann ein Feld wegen fehlerhafter Eingabe nicht ausgewertet werden d rfen auch die Werte der anderen Felder noch nicht propagiert wer den sondern es mu ein R cksprung zur Eingabe erfolgen Auch f r solche kombinierten Konsistenzpr fungen stellt Java keine Unterst tzung bereitstellt Deshalb wurde in die neuen Eingabefeld Klassen ein Mechanismus integriert der ohne gro en Aufwand f r den Aufrufer nicht nur die Atomarit t des Ausle sevorgangs sicherstellt sondern bei Fehlern im Eingabeformat auch eine pr zise R ckmeldung an den Benutzer erlaubt Hierbei wird in der Art des in der Transaktionsverarbeitung eingesetzten Zwei Phasen Commit Protokolls vorgegangen BN97 1 Ein komplexes Eingabeobjekt Dialog oder zusammengesetztes Eingabe feld stellt zun chst den Ready to Commit Status sicher indem es alle untergeordneten Eingabefelder zum Auslesen der Eingabewerte auffordert Jedem Teilfeld wird hierbei eine Bezeichnung mitgegeben mit der im Falle eines Auslese Fehlers dem Benutzer genau mitgeteilt werden kann welche seiner Eingaben unkorrekt war bzw ein falsches Format hatte 2 Konnten alle Eingaben in die passenden Datentypen umgesetzt werden werden in der zweiten Phase tats chlich die Werte in den Datenstrukturen gesetzt Dieses synchronisierte Setzen von Werten gilt allerdings nur f r direkt
22. der Bedienung insbesondere nimmt die Darstellung 3 5 IMPLEMENTIERUNG AUSGEHEND VON EINEM PROTOTYP 43 solcher Listen einen nicht unerheblichen Teil der doch begrenzten Bildschirm fl che in Anspruch 3 5 Implementierung ausgehend von einem Pro totyp Um dem DRK schon fr h eine anschaulichen berblick ber den Planungs stand geben zu k nnen wurde bereits parallel zur Anforderungsanalyse ein Prototyp der graphischen Benutzungsoberfl che erstellt im Akkord ber die Weihnachts ferien Die Existenz dieses Prototyps wurde dann naiverweise als ein bereits betr cht licher Fortschritt bei der Implementierung gewertet Da dem nicht so war sollte sich recht schnell nach Beginn der tats chlichen Implementierungsphase heraus stellen Die Eingabedialoge und Datenfelder waren auf Datenklassen bezogen die ebenso ad hoc im Kopf entworfen wurden wie der gesamte Prototyp Da in Spezifikation und Entwurf die Struktur und Zusammenh nge dieser Datenklas sen deutlich vom Prototyp abwich konnte lediglich ein minimaler Teil der alten Oberfl che wiederverwendet werden um z B gewisse Teile von Eingabefenstern aufzubauen Insbesondere die Anbindung an die Datenklassen Werte setzen und lesen siehe 3 1 2 1 war recht aufwendig F r eine Anwendung die so unmittelbar auf der Struktur des Datenmodells aufsetzt wie dies bei der Datenverwaltung des Programms TROSS der Fall ist ist es sicher sinnvoller den Prototyp zu einem sp teren Zeitp
23. die wie gefordert f r die automatische Optimierung gesperrt wurde Da die Sch lerin Karin Klein krank ist wurde in ihrem Dienstwunsch die voraussichtliche Dauer der Krankheit vom Zeitrahmen ausgenommen Probleme e Da f r Touren keine Bemerkung vorgesehen ist mu der Auftrag die Sch ler in die Klassen zu bringen bei jedem Dienstwunsch angegeben werden Der Zivi Karl Tremmle machte zu Beginn seiner Dienstzeit einen Lehrgang Dies sollte in TROSS durch eine Datumsspanne f r die Zeit des Lehrgangs dargestellt werden Dazu w re es w nschenswert gewesen bei den Ausnahemzeitr umen auch Bemerkungen eingeben zu k nnen damit man wei warum ein Mitarbeiter fehlt Bisher kann nur dargestellt werden da ein Mitarbeiter nicht verf gbar ist aber nicht warum er fehlt Da der Klassenlehrer von Karin Klein ber deren Krankheit unter richtet werden soll ist im System nicht sinnvoll darstellbar da der entsprechende Dienstwunsch nicht mehr in der Fahrt auftaucht Die Zeitangabe ohne Minuten 16 1 f hrte zu der verwirrenden Fehlermeldung ganze Zahl eingeben Fehler 4 3 ABGLEICH MIT DEN ANFORDERUNGEN 53 e Beim Erstellen von Untertouren trat eine Exception auf Daher konn te auch nicht festgestellt werden ob es m glich ist da die Sch lerin Susanne Schlecht auf der Hinfahrt garantiert als letzte abgeholt und bei der R ckfahrt als erste abgeliefert wird Szenario 2 Das Szenario konnte mit dem System kompl
24. diese auf die Dienstart st tzt und somit entweder ein Essen oder MSD Stunden in Rechnung stellen k nnte Szenario 3 Beim Szenario 3 ergeben sich durch die geforderte Verbindung von EAR und MSD Dienst die schon oben genannten Probleme Weitere Probleme traten in Verbindung mit der Erfassung von Institutionen auf e Obwohl die Klasse Kunde einen Vektor f r die Aufnahme von Institutionen besitzt ist es ist nicht m glich dem Kunden direkt d h ohne bekannten Sachbearbeiter eine Institution zuzuweisen Ist der Sachbearbeiter unbe kannt mu die Institution ber eine Dummy Bezugsperson referenziert werden e Es ist keine Angabe der Versicherten Nummer vorgesehen Diese kann zwar im Feld Bemerkung untergebracht werden verhindert aber z B f r automatische Rechnungsstellung eine Auswertung durch das Systems Szenario 4 Das Szenario konnte mit TROSS erfa t werden Ein Problem trat unter Windows95 jedoch nicht bei UNIX auf Der Zeitrahmen wird beim Ver lassen der Zeitrahmeneingabe um einen Tag nach vorne verschoben Szenario 5 Das Szenario 5 konnte problemlos nachvollzogen werden Szenario 6 Der entsprechende Ausnahmezeitraum wurde erfa t und nach Szenario 4 erwartungsgem verschoben Auswirkungen auf die Fahrten konn ten nicht getestet werden da es nicht m glich war Fahrten zu erzeugen Szenario 7 Der nicht mehr ben tigte Dienstwunsch wurde durch Angabe ei nes Enddatums in seiner Zeitspanne suspendiert Die Entfernung
25. erstellt wurden Betrachtet man die Kapazit t eines einzelnen Mitarbeiters kommt man auf fol genden Aufwand pro Projektgruppenmitglied 33 5 Wochen 2 Mitarbeitertage 67 Mitarbeitertage 502 5 Mitarbeiterstun den Wobei von einem w chentlichen Aufwand pro Mitarbeiter von ungef hr 15 Stunden gt 2Tage ausgegangen wurde Umgerechnet auf alle Mitarbeiter er gibt sich daraus folgender Gesamtaufwand f r das Projekt 33 5 Wochen 4 Mitarbeiter 134 Mitarbeiterwochen 268 Mitarbeitertage Werden pro Mitarbeiterstunde die fiktiven Kosten von 150 DM angesetzt die wahrscheinlich weit unter einem realistischen in der freien Wirtschaft ver anlagten Wert liegen ergeben sich folgende Kosten 268 Mitarbeitertage 7 5 Stunden 150 DM 301 500 DM 8 1 2 Meilensteine Bei einem Meilenstein handelt es sich um einen ausgezeichnten Zeitpunkt w h rend des Projektverlaufes an diesem ein vorher festgelegtes Ergebnis erwartet wird Folgende Meilensteine waren w hrend des Projekts zu erreichen Beendigung der Anforderungsanalyse Ergebnis angenommenes Dokument geplant 21 12 97 Abnahme durch Review Beendigung der Spezifikation Ergebnis angenommenes Dokument geplant 30 01 98 Abnahme durch Review Vorf hrung Prototyp Oberfl che Ergebnis Prototyp f r die Benutzungsschnittstelle geplant 06 02 98 Abnahme durch Kunden Beendigung des Entwurfs Ergebnis angenommenes Dokument geplant 13 03 98 Abnahme durc
26. fung auch von Hand aufgerufen werden Daraufhin bekommt der Benutzer alle Verst e gegen die Vorgaben gemeldet Ein gezieltes Fragen nach einzelnen Vorgaben wurde bis auf wenige Ausnahmen nicht implementiert 3 3 UMSETZUNG DES ENTWURFS IN DER IMPLEMENTIERUNG 37 3 3 3 1 Referenzintegrit t Die Referenzintegrit t wird im Programm TROSS gewahrt indem das L schen von Fremdschl sseln verhindert wird So darf z B eine Qualifikation nicht ge l scht werden wenn sie einem Mitarbeiter zugeordnet ist oder von einem Kun den gefordert wird Da keine Datenwerte als Fremdschl ssel dienen sondern direkte Referenzen auf die Java Objekte gespeichert werden findet eine Ver nderung von Fremd schl sseln durch die Eingabe nicht statt hier mu also nichts gepr ft werden 3 3 3 2 Vorgaben Weiche Konsistenzbedingungen die Bedingungen der realen Welt darstellen sind f r die Touren Untertouren und Fahrten definiert Diese werden automa tisch aufgerufen wenn der Benutzer eine Tour Untertour oder Fahrt im Dialog bearbeitet Da dieser explizit Verst e gegen Konsistenzbedingungen zulassen kann ist es au erdem m glich die Konsistenzpr fung der Touren manuell zu starten um einen berblick ber die bewu t akzeptierten Unregelm igkeiten zu bekommen F r die leicht nachzuvollziehenden Laufzeitabsch tzungen der Konsistenzpr fungen werden folgende Bezeichnungen benutzt DW Menge aller Dienstw nsche T Menge aller Touren
27. mit einem gut konzipierten GUI Builder ergeblich vereinfacht Lange Zeit gab es auch regelm ige Probleme mit dem Versionsverwaltungs system CVS dessen Funktionsweise und Bedienung nicht unmittelbar einleuch tete Erst nach wiederholten Datenverlusten beim Einchecken neuer Versionen wurde die korrekte Handhabung klar Kapitel 4 Test 4 1 Funktionstest des Gesamtprogramms Eigentlich h tte vor Beginn der Testphase ein Schnitt gemacht werden sollen so da nach einem Implementierungsstop eine definierte Version 0 des Pro gramms zur Verf gung gestanden h tte Da dies durch krampfhaftes Festhalten an der Fertigstellung gewisser Programmteile so nicht realisiert werden konn te gr ndete der Funktionstest nicht nur auf von Teil zu Teil unterschiedlichen Versionen sondern stellte teilweise auch Fehler fest die mittlerweile l ngst be hoben waren Da es sich hierbei teilweise um wichtige Programmteile handelt sollen hier kurz diejenigen Punkte wiedergegeben werden die der Funktionstest als fehlerhaft beschreibt die aber im Programm zum Zeitpunkt des Endberichts korrigiert waren 4 1 1 Szenario F r die folgenden Tests wurden verschiedene Szenarien u A mit DRK Testdaten mit generierten Testdaten und mit Daten aus 4 3 verwendet Die Men punkte neu ffnen und Szenario zum Masterszenario machen zeig ten bei mehrmaligen Aufrufen und auch bei zwischenzeitlichem Verlassen des Programms die gew nschte Wirkung Das Speiche
28. nglichen Zustand Dies gilt nicht f r nderungen an Listen wie in 7 3 1 beschrieben die unmittelbar nach Eingabe wirksam werden Beispielsweise ist die Erfassung einer Kundenadresse bereits dann ge speichert wenn die Eingabe der Adresse best tigt wurde und diese in der Liste erscheint Ein sp teres Abbrechen des Dialogs zur Kundeneingabe hat hierauf keinen Einflu Die Buttons OK und Abbruch k nnen auch direkt per Tastaturk rzel ak tiviert werden lt Enter gt auch als lt Return gt oder lt Eingabe gt bezeichnet be st tigt die Eingabe und beendet den Dialog mit lt Escape gt wird die Eingabe verworfen und der Dialog abgebrochen Dialoge f r umfangreichere Eingaben sind in mehrere Register unterteilt Dazu bietet ein solcher Dialog eine waagrechte Reihe von Buttons am oberen Rand mit denen zwischen den verschiedenen Teilen des Dialogs umgeschaltet werden kann Trotzdem geh ren alle Eingabefelder zusammen auch wenn sie verschiedenen Registern zugeordnet sind Der Button OK best tigt also auch hier alle Eingaben und schlie t den Dialog nicht nur die jeweilige Registerseite 7 4 Szenario Zur Unterst tzung manueller Planung und Optimierung bietet TROSS das Kon zept der Szenarien an Ein Szenario besteht aus den Stammdaten Kunden mit ihren Dienstw nschen Ressourcen und allen Einstellungen einerseits und einer Menge von Tourszenarien andererseits Ein Tourszenario wiederum enth lt alle 7 4 SZ
29. oder schlicht nicht vorhanden Als Beispiel sei hier die Eigenschaft der Vergleichbar keit genannt die Voraussetzung f r das Sortieren von Objekten ist Zwar haben manche Java Klassen bereits eine Methode namens compareTo implementiert die diesen Vergleich durchf hrt jedoch ist diese Methode nicht Teil eines Inter face mit dessen Hilfe man die Vergleichbarkeit von Objekten erzwingen k nnte um sie z B in eine sortierte Liste aufzunehmen Folgerichtig gibt es auch keine Listenklassen die ihren Inhalt automatisch sortieren Daim Projekt TROSS sol che sortierten Listen aber gebraucht wurden mu ten die meisten Datenklassen mit zwei selbsterstellten Interfaces implementiert werden siehe 3 1 1 1 Der Verzicht auf Mehrfachvererbung l st zwar gewisse semantische Eindeu tigkeitsprobleme bedeutet aber manchmal zus tzlichen Programmieraufwand durch Verlust an Modularit t Javas Interfaces k nnen zwar wie abstrakte Su perklassen gehandhabt werden bieten aber nicht die M glichkeit des code reu se durch Vererbung von Methoden Im Projekt w re es z B w nschenswert gewesen sowohl Personen als auch In stitutionen in einen Zusammenhang mit Kunden zu bringen Dies k nnte durch eine Superklasse Bezug realisiert werden von der sowohl BezugsPerson als auch Institution erben Da BezugsPerson aber auf jeden Fall von Person erbt mu te diese Realisierungsm glichkeit ausscheiden Wir haben uns f r die Ver kn pfung von Kunde und Instit
30. oder Untertour direkt auf die Fahrten auswirken z B Entfernen eines Dienstwunsches Vor nderungen an einer Tour oder Untertour des Master Tourszenarios ist es daher sinnvoll die bereits erfolgten Fahrten die also vor dem jeweiligen Tagesdatum liegen zu archivieren 7 6 5 Konsistenzpr fung berpr ft alle Touren Untertouren und Fahrten des aktiven Tourszenarios auf ihre Konsistenz mit den Vorgaben der Dienstw nsche Verst e gegen diese Re geln werden dem Benutzer in einer Liste angezeigt Folgende Kriterien werden abgepr ft Mitarbeiter e Sind erster und zweiter Mitarbeiter unterschiedlich e Ist ein zweiter Mitarbeiter eingeteilt falls die Dienstw nsche dies verlangen e Sind die Mitarbeiter am Tag einer Fahrt verf gbar e Sind die Mitarbeiter f r den Dienst an den Kunden der Tour zul ssig werden also von diesen Kunden nicht abgelehnt 82 KAPITEL 7 BEDIENUNGSANLEITUNG e Haben die Mitarbeiter alle geforderten Qualifikationen Fahrzeuge e Ist das Fahrzeug am Tag einer Fahrt verf gbar e Wir die maximale Sitzplatzzahl eingehalten bei Fahrdiensten e Ist das Fahrzeug f r alle Kunden als zul ssig eingetragen bei Fahr diensten oder MSD Kunde f hrt mit Zeiten e Entsprechen die Zeiten der Untertour den Zeitvorgaben der Dienst w nsche 7 7 Ressourcen Hier werden die wichtigsten Ressourcen verwaltet die zur Verf gung stehen um Dienstw nsche der Kunden zu erf llen Mitarbeiter und Fah
31. x Genetische Algorithmen und das System Genom Nicole Weickert und Alexander Leonardi x Java Fritz Hohl x Projektplanung und MS Project Anke Drappa x C und wxwin Stefan Lewandowski x Smalltalk und Visual Works Tobias Spribille Vortrag des Kunden Herr Schroff ber die Anforderungen an das System und die aktuelle Abwicklung der Fahrdienstplanung des DRK Stuttgart Analyse des Ist Zustandes beim Kunden Erfassung der notwendigen Eingabedaten Mitfahrt bei einzelnen Diensten zur Erfahrungssammlung Erstellung einzelner Szenarien Review 16 1 1998 21 12 1997 92 KAPITEL 8 PROJEKTPLANUNG Spezifikation Beginn 19 1 1998 22 12 1997 was wurde getan Architektur des Gesamtsystems Erstellung eines Datenmodells Aufbau und Funktionsweise des Verkehrsmoduls Zusammenstellung der Datenausgabe M glichkeiten der Optimierung Aussehen der Benutzungsoberfl che Erstellung eines Prototyps f r die Benutzungsoberfl che Review 27 3 1998 13 3 1998 Entwurf Beginn 2 3 1998 2 3 1998 was wurde getan Umsetzung der Spezifikation in passende Klassenstruktur Konzepte der Datenhaltung Erstellung der Men struktur Review 27 3 1998 13 3 1998 Zwischenbericht Beginn 30 3 1998 16 3 1998 was wurde getan Zusammenstellung bisher erstellter Dokumente korrekturlesen Dokument fertig 29 4 1998 27 3 1998 Implementierung Beginn 3 4 1998 30 3 1998 was
32. 0 00 0 00 9 50 0 00 Gesamt 542 50 573 00 536 50 534 00 Abbildung 8 1 Stundenzahl pro Projektgruppenmitglied Kapitel 9 R ckblick 9 1 Zeitplanung Der grobe Zeitrahmen f r die einzelnen Phasen der Projektgruppe war bereits zu Anfang von den Betreuern fest vorgegeben Da er seltsamerweise zwei Mona te ber das Ende der Projektgruppenzeit hinausging mu te er gek rzt werden um alle vorgesehenen Phasen bis zum Ende des Vorlesungszeitraums im Juli 1998 unterzubringen Die beiden letzten Phasen n mlich Implementierung und Test wurden radikal gek rzt Im Nachhinein tr gt diese Ma nahme entschei dend dazu bei da nicht alles im Programm umgesetzt werden konnte und selbst die wichtigsten Bestandteile nur durch enorme Mehrarbeit der Projektgruppe in der Implementierungsphase berhaupt bis zur vollen Funktionalit t gebracht werden konnten Ein weiteres zeitliches Problem war nat rlich die Aufgabenstellung die insge samt einfach zu komplex war um sie mit vier Personen in dieser Zeit komplett zu bew ltigen siehe 9 2 Sowohl dem Verlauf als auch dem Ergebnis der Pro jektgruppe w re es sicher zugute gekommen nach der Anforderungsanalyse als die berdimensionierung der Aufgabe durchaus schon zu sehen war einen sau beren Schnitt zu machen Sp testens aber nach dem Entwurf h tte man sich dazu durchringen m ssen im Interesse eines lauff higen Gesamtsystems von vornherein gewisse Teile nicht zu implementie
33. 0 2 Arbeitszeitprofile Alle Arbeitszeitprofile die Mitarbeitern zugewiesen werden sollen m ssen zuvor in dieser Liste definiert werden Ein Arbeitszeitprofil gibt an wann und wie lange ein Mitarbeiter im Dienst ist 7 10 2 1 Eingabedialog f r Arbeitszeitprofile Es gibt drei Arten von Arbeitszeitprofilen mit denen die meisten tats chlichen Arbeitszeitverh ltnis dargestellt werden k nnen Vollzeit Mitarbeiter mit einer bestimmten Arbeitszeit pro Woche 86 KAPITEL 7 BEDIENUNGSANLEITUNG Teilzeit tageweise Mitarbeiter die je nach Wochentag zu bestimmten Uhr zeiten arbeiten Teilzeit stundenweise Mitarbeiter mit einer bestimmten Arbeitszeit pro Monat Allen Arbeitszeitprofilen gemeinsam ist die Angabe einer maximalen Arbeitszeit pro Tag wie sie z B von Arbeitsschutzrichtlinien vorgeschrieben wird 7 10 3 Fahrzeugtypen Alle Typen der vorhandenen Fahrzeuge m ssen zuvor in dieser Liste definiert werden 7 10 3 1 Eingabedialog f r Fahrzeugtypen Ein Fahrzeugtyp hat neben einer kurzen Bezeichnung und einer ausf hrlichen Beschreibung eine maximal zul ssige Sitzplatzzahl sowie einen Kilometerpreis Die verschiedenen M glichkeiten ein Fahrzeug umzubauen z B zur Schaffung von Rollstuhlpl tzen durch Ausbau von Sitzb nken werden durch eine Menge von Fahrzeugkonfigurationen beschrieben F r jeden tats chlich vorhandenen Zustand eines Fahrzeuges mu in dessen Typ die passende Konfiguration defi niert werden 7 1
34. 0 3 2 Eingabedialog f r Fahrzeugkonfigurationen Die Konfiguration wird durch Angabe der Anzahl vorhandener Pl tze pro Platz art angegeben Anzahl Sitzpl tze Anzahl Rollstuhlpl tze sowie zu jedem de finierten Hilfsmittel die Anzahl Pl tze an denen ein solches Hilfsmittel fest montiert ist Falls die Fahrzeugkonfiguration ber eine K hlm glichkeit verf gt z B Schienen f r einen K hlcontainer und ausreichend Platz f r dessen Trans port kann dies angegeben werden 7 10 4 Institutionen Hier k nnen alle Institutionen erfa t werden die mit einem Kunden in Bezie hung stehen z B Krankenkassen als Rechnungsempf nger 7 10 4 1 Eingabedialog f r Institutionen Eine Insitution hat au er einem eindeutigen Namen eine Menge von Adressen Kommunikations und Bankverbindungen 7 10 5 Stationen Manche Stationen werden sehr oft verwendet da sie z B das gemeinsame Ziel vieler Fahrten darstellen Schulen oder Krankenh user Deshalb k nnen sie unter einem kennzeichnenden Namen hier erfa t werden und stehen dann bei jeder Eingabe einer Station ber den Button Nachschlagen zur Verf gung Wird bei der Eingabe einer Station z B in einem Dienstwunsch diese mit einem Namen versehen wird sie ebenfalls in die globale Liste eingetragen 7 10 EINSTELLUNGEN 87 7 10 5 1 Eingabedialog f r benannte Stationen Zus tzlich zur Adresse mu hier auch ein Name f r die Station eingegeben wer den unter dem sie sp ter gefund
35. 2 22 Corn n nn 56 5 4 Klassenhierarchie 60 6 Erweiterungsm glichkeiten 67 6 1 M gliche Verbesserungen am Programm 67 6 2 Hilfestellungen f r den Benutzer 2 2 222 nn nn 67 6 3 Erweiterungsm glichkeiten 2 2 2 2 2 nun nen 68 7 Bedienungsanleitung 69 7 1 Systemvoraussetzungen 69 CH Installation 282 ann Ren re FIRE e E 69 7 3 Grundlegende Konzepter 70 7 3 1 Erweiterbare Listen 22 22 2 room 70 7 3 2 Eingabedialoge 2 2 on 70 TA Eat 4 2 Ben a ee ee ee ee ee Ee 70 GT Neun ee ee A e e eene E 71 1 427 adet tee 8 ee ee TA A a A 71 1 4 3 Speichern a nn ak ees bh a a an 71 7 4 4 Szenario zum Masterszenario machen 71 7 4 5 Untermenu Tourszenario 2 222mm nn 71 7 4 6 Programm beenden 2 2 22m 72 1 9 gt Kunden Se ler Ate a e e a ee d 72 T 5 1 Kundenliste u 2 203 3a dh re a 72 7 5 2 Eingabedialoge f r Dienstw nsche 2 2 2 74 7 5 3 Dienstw nsche erf llt 2 22 22 2m nenn 76 1 6 Toure saw Erna an er ann 76 CL Tourenliste sutta onca i ans aa AE EI a a 77 1 6 2 Pahrtenlister coc 2 Ber or ALANS 80 7 6 3 Fahrten erzeugen EN 7 6 4 Fahrten archivieren 2 2 2 2 2m nn EN 7 6 5 Konsistenzpr fung EN 7 1 Ressourcen loa ae e ee E E a E 82 7 0 1 Mitarbeiter 22 2 ern 82 ZA Bahrzeuge A Sean AA E a id 82 1 8 Ausgaben ur sonne ee 78 1 Tourplan 2 2 2222 2 78 2 Dienstplan 2 2 2 2 78 3 Gesamtdienstplan 2
36. 7 BEDIENUNGSANLEITUNG bleiben bestehen k nnen sich aber m glicherweise auch ver ndern Daher sollten vor nderungen gegebenenfalls erst die alten Fahrten archiviert werden siehe 7 6 4 Abbildung 7 3 Eingabedialog f r Untertouren 7 6 2 Fahrtenliste Zeigt alle Fahrten des aktiven Tourszenarios an Diese werden zun chst nach Tour und Untertournummer dann nach Datum sortiert Ein vor der Fahrt zeigt an da diese gegen ber den Planungsdaten in Tour und Untertour ver ndert wurde indem Mitarbeiter bzw Fahrzeug ge ndert oder Dienstw nsche entfernt wurden Diese k nnen einzeln ge ndert werden um Abweichungen der tats chlich durchgef hrten Fahrten von den geplanten Untertouren zu doku mentieren 7 6 2 1 Dialog zur nderung von Fahrten Der Dialog f r Fahrten zeigt Tournummer Datum und Dienstart zur Informa tion mit an Mitarbeiter und Fahrzeuge sind bei neu erzeugten Fahrten zun chst auf die Werte der Tour gesetzt ist dort nichts angegeben wird automatisch der erste m gliche Eintrag in der Liste gew hlt k nnen aber ge ndert werden Ebenso k nnen die Anfangs und Endstation mit den zugeh rigen Zeiten abweichend von der Untertour eingetragen werden 7 6 TOUREN EN Die anzufahrenden Stationen werden in einer Liste angezeigt Werden bei einer Fahrt einzelne Dienstw nsche der Untertour nicht erf llt k nnen diese mit dem Button Dienstwunsch entfernen aus der Fahrt entfernt werden mit
37. ENARIO 71 Tourdaten Touren Untertouren und Fahrten zu den Stammdaten des Szena rios Jedes Szenario kann in eine Datei gespeichert und wieder geladen werden Dadurch k nnen Planungsans tze mit der Methode Was w re wenn leicht durchgef hrt werden Sollen unterschiedliche Touren ausprobiert werden um z B verschiedene Ver teilungen der Fahrdienstkunden auf die Fahrzeuge zu vergleichen werden in nerhalb eines Szenarios verschiedene Tourszenarien angelegt die verschiedene M glichkeiten darstellen denselben Kundenkreis mit denselben Ressourcen zu bedienen Von den Tourszenarien eines Szenarios ist immer eines aktiv d h alle nderungen an Touren Untertouren und Fahrten beziehen sich auf das momentan aktive Tourszenario Noch weitergehende Planspiele bieten verschiedene Szenarien Hier ist z B ein Kapazit tsvergleich m glich wenn nach dem Ausscheiden eines Zivildienst leistenden im einen Fall ein Nachfolger eingestellt wird im anderen Fall mit einem Mitarbeiter weniger gearbeitet werden mu Um den berblick bei vielen Szenarien und Tourszenarien zu behalten hat jedes einen eindeutigen Namen Die Titelzeile des Hauptfensters gibt Auskunft ber das momentan geladene Szenario und dessen aktives Tourszenario ber dies ist ein Szenario als sogenanntes Master Szenario sowie eines seiner Tour szenarien als Master Tourszenario ausgezeichnet Diese Kennzeichnung ist f r die real g ltigen Daten gedacht also di
38. Endbericht der Projektgruppe Transportoptimierung Bericht Nr 1998 10 Universit t Stuttgart Endbericht der Projektgruppe Transportoptimierung J rg Fleischmann Lars Hermes Tobias Spribille Frank Wagner Betreuung Prof Dr Volker Claus Dipl Inform Friedhelm Buchholz Dipl Inform Stefan Lewandowski Abteilung Formale Konzepte Fakult t Informatik Universit t Stuttgart 9 November 1998 Prof Dr Volker Claus Abteilung Formale Konzepte Institut f r Informatik Universit t Stuttgart Breitwiesenstr 20 22 D 70565 Stuttgart Telefon 0711 7816 300 Prof Dr V Claus 0711 7816 301 Sekretariat 0711 7816 330 FAX E Mail claus informatik uni stuttgart de Inhaltsverzeichnis 1 Einf hrung EH Der Bericht oa 23 2a AR Er RE ee he 1 2 Has Programm sa 2 2 8 Bass ans a a ae ee Nachtrag zum Entwurf 2 1 Neue Klassen und Interface 2 1 1 Arbeitszeitprofille 2 1 2 DienstplanErstellbar 22 22 2 nn nn 2 1 3 Zahlereinterf ce 2 2 2233 2 rer e MN 21 4 WDruckbarns 2 act ta Ak De A a eebe 2 2 Allgemeine Konzepte Coon 2 2 1 Stationen und Anbindungspunkte 2 2 2 2 aa 22 2 Untertours u ur 2 EEN AITE E A H N 2 2 3 Verkehrsmodul A a nina reese ner Implementierung 3 1 Entwurfsentscheidungen auf Programmiersprachenebene 3 1 1 Allgemeine Konzepte En een 3 1 2 GUI Erweiterungen 2 22 Connor n 3 2 Designentscheidungen e 3 2 1 Fensteraufbau s s e e ea n a no
39. Fahrt ist eine an einem konkreten Datum stattfindende Untertour Gegen ber Tour und Untertour kann sie gewisse Abweichungen aufwei sen die angeben wie die tats chliche Dienstausf hrung von der Planung abwich Da die Fahrten die tats chliche Durchf hrung von Diensten abbilden k nnen sie die Grundlage einer Buchf hrung ber diese Dienstleistungen bilden Dazu kann jede Fahrt falls n tig gegen ber der geplanten Untertour ver ndert werden um z B festzuhalten da ein anderer Mitarbeiter den Dienst erledigt hat oder einer der Kunden an diesem Tag nicht mitfuhr In den Eingabedialogen f r Touren und Untertouren sind noch verschiede ne Eingabefelder zum Sperren einzelner Dienstw nsche sowie ganzer Touren f r die Optimierung vorhanden Da diese automatische Optimierung von der Projektgruppe TRO Wintersemester 1997 98 und Sommersemester 1998 aus Zeitgr nden nicht mehr implementiert werden konnte haben diese Eingaben keinerlei Wirkung Sie wurden jedoch im Programm belassen um f r eine m g liche sp tere Erweiterung zur Verf gung zu stehen 7 6 1 Tourenliste Zeigt eine nderbare Liste mit allen Touren und Untertouren des aktiven Tour szenarios an Nach Auswahl einer Tour durch Mausklick in der linken Liste wer den in der rechten Liste alle Untertouren dieser Tour angezeigt Sowohl Touren als auch Untertouren k nnen beliebig neu angelegt ver ndert sowie gel scht werden Beim Ver ndern von Touren Untertouren mu aller
40. K Menge aller Kunden DW Menge der Dienstw nsche des Kunden ke K DW Menge der Dienstw nsche die auf Tour t T erf llt werden AZm Menge der Ausnahmezeiten f r die Verf gbarkeit des Mitarbeiter m AZ Menge der Ausnahmezeiten f r die Verf gbarkeit des Fahrzeugs f MA Menge aller Mitarbeiter FZ Menge aller Fahrzeuge F Menge aller Qualifikationen Folgende Kriterien werden gepr ft Mitarbeiter Sind erster und zweiter Mitarbeiter unterschiedlich O 1 Ist ein zweiter Mitarbeiter eingeteilt falls die Dienstw nsche dies verlangen OO DH Sind die Mitarbeiter am Tag einer Fahrt verf gbar OU A Sal Sind die Mitarbeiter f r alle Kunden einer Tour zul ssig also nicht bei den Abneigungen der Kunden erfa t OU DH MA Besitzen die Mitarbeiter alle geforderten Qualifikationen O DW QFP 38 KAPITEL 3 IMPLEMENTIERUNG Fahrzeuge e Ist das Fahrzeug am Tag einer Fahrt verf gbar O AZ e Wird die maximale Sitzplatzzahl eingehalten bei Fahrdiensten oa e Ist das Fahrzeug unter den f r den Kunden zul ssigen bei Fahrdien sten oder MSD wenn der Kunde mitf hrt O DW FZ Zeiten e Werden die Zeitvorgaben in den Rhythmen der Dienstw nsche ein gehalten O DW Vollst ndigkeit e Werden alle Dienstw nsche komplett erf llt also alle Teildienstw n sche ber cksichtigt O DW SC DW e OUT DW Nicht gepr ft wird die Arbeitszeit der Mitarbeiter im Vergleich zu den in den Arbei
41. Mit den Tourszenarien k nnen bei gleichbleibenden Stammdaten verschiedene Tourkonstellationen ausprobiert werden Da diese logisch zu den gleichen Stammdaten geh ren werden alle Tour szenarien samt den Stammdaten in einer Datei gespeichert 2 Allgemeine Szenarien Hierbei k nnen auch Stammdaten ge ndert wer den um beispielsweise zu testen wie sich eine Verringerung der Fahr zeugflotte auswirken w rde Diese allgemeinen Szenarien werden jeweils in einer eigenen Datei gespeichert und im folgenden kurz als Szenarien bezeichnet KAPITEL 3 IMPLEMENTIERUNG Szenario 1 Personen Dienstw nsche Fahrzeuge Fahrten Qualifikationen Dienstarten Fahrzeugtypen Touren Stationen Essensarten Fahrzeugkonfig Untertouren Komm Verb Hilfsmittel Bankverbindung Institutionen Tourszenario 1 Tourszenario i Tourszenario n Touren Touren Touren Untertouren Untertouren Untertouren Fahrten Fahrten Fahrten Szenario k Personen Dienstw nsche Fahrzeuge Fahrten Qualifikationen Dienstarten Fahrzeugtypen Touren Stationen Essensarten Fahrzeugkonfig Untertouren Komm Verb Hilfsmittel Bankverbindung Institutionen Tourszenario 1 Tourszenario i Tourszenario n Touren Touren Touren Untertouren Untertouren Untertouren Fahrten Fahrten Fahrten Abbildung 3 1
42. RO VollzeitProfil implements java io Serializable o class RU Bank implements java io Serializable o class TRO BankVerbindung implements java io Serializable TRO ListenElement o class TRO GUI ColumnConstraints implements java lang Cloneable java io Serializable o class TRO GUI ColumnLayout implements java awt LayoutManager2 java io Serializable o interface TRO Comparable o class java awt Component implements java awt image Image bserver java awt MenuContainer java io Serializable class java awt Choice implements java awt ItemSelectable class TRO GUI ObjektAuswahl class java awt Container class java awt Panel class TRO GUI Definitionen ArbeitszeitPanel class TRO GUI Definitionen TeilzeitStundenPanel class TRO GUI Definitionen TeilzeitTagePanel class TRO GUI Definitionen VollzeitPanel class TRO GUI DatumsspannePanel class TRO GUI GroupFramePanel class TRO GUI AuswahlListePanel class TRO GUI HashPanel class TRO GUI Dienste KonfigurationsPanel class TRO GUI ObjektListePanel class TRO GUI Dienste BezugspersonenPanel implements TRO GUI ObjektListePanel ElementListener class TRO GUI Dienste DienstwunschListePanel implements TRO GUI ObjektListePanel ElementListener class TRO GUI Touren FahrtenListePanel implements TRO GUI ObjektListePanel ElementListener class TRO GUI Ressourcen FahrzeugListePanel 5 4 KLASSENHIERARCHIE class class class class
43. TRO GUI Dienste TRO GUI Analyse KundeDialog KundenListePanel P S b e 8 UntertourDialog lt init gt lt init gt lt init gt okAktion elementEntfernen seg TRO GUI Definitionen TRO GUI Menu DEER D H KE TRO TRO Konsistenztests TRO Verkehrsmodul Abbildung 5 2 Architektur der graphischen Benutzungsoberfl che Konstruktor station I Verkehrsmodul anbindungInOrdnung Station gt MoeglicherAnbindungsPunkt I Ne MoeglicherAnbindungsPunkt korrekturListe Verkehrsmodul erstelleAnbindungsPunkt M von I t J AnbindungsPunkt EntfernungsTabellenEintrag R i nach j j D anbindungsPunkte entfernung e fahrzeit gt Verkehrsmodul EntfernungsTabelle bereiteVor TRO Verkehrsmodul Me ar ERE T ee E EE tross lst tross asc Auftrag Antwort tross cor tross bal error mgb Y Map amp Guide Abbildung 5 3 Prinzipskizze des Verkehrsmoduls INUONSUHHMYHA CO 6S 60 KAPITEL 5 ARCHITEKTUR DES PROGRAMMS TROSS 5 4 Klassenhierarchie class java lang Object o class TRO Verkehrsmodul AnbindungsPunkt implements java io Serializable o class TRO ArbeitszeitProfil implements java io Serializable TRO ListenElement class TRO TeilzeitStundenProfil implements java io Serializable class TRO TeilzeitTageProfil implements java io Serializable class T
44. Tabellen bestehen sondern nur eindimensionale Listen mu ten die Hashtabellen bzw Tabellen aller Art zur Eingabe in ihre einzelnen Dimensionen zerlegt werden siehe 3 1 2 6 3 4 2 2 Teilbare Einheiten Aufwendig in der Handhabung sind auch Werte mit teilbaren Einheiten Die Speicherung von Zeitdauern in Minuten ist zweifelsohne sinnvoll um ohne auf wendige und fehlertr chtige Gleitkommaarithmetik auszukommen Bei der Ein gabe ist es aber in den meisten F llen nicht zumutbar alles in Minuten umzu rechnen man denke z B an die Erfassung der w chentlichen Arbeitszeit Dem Benutzer sollte eine Ausgabe in Form hh mm je zwei Stellen f r Stunden und Minuten bzw getrennte Eingabefelder f r Stunden und Minuten angeboten werden Hier ist wieder zus tzlicher Aufwand n tig um einen gegegeben Wert f r die Ein und Ausgabe zu teilen die Teile einzeln zu editieren und hinterher wieder zusammenzusetzen 3 4 2 3 Aufwand durch Allgemeing ltigkeit Manche Teile des Entwurfs der Datenklassen wurden bewu t allgemeing ltig ge halten um nicht von vornherein gewisse Eingabem glichkeiten auszuschlie en Es fand z B keine Einschr nkung auf zwei Adressen oder Telephonnummern pro Person Kunde statt statt dessen kann eine theoretisch beliebig gro e Menge von Adressen Bank sowie Kommunikationsverbindungen eingegeben werden Dies l t sich zwar auch in der Benutzungsoberfl che recht einfach umsetzen ist aber etwas unhandlich in
45. Uhrzeit Die Zeit zu der die Untertour beginnt endZeit Uhrzeit Die Zeit zu der die Tour beendet wird halte Vector of UntertourHalt In diesem Vector steht in welcher Reihenfolge welche Halte anzufahren sind fahrten Vector of Fahrt Die erstellten Fahrten zu der Untertour sortiert nach Datum e Methoden anfangsUndEndZeitAnpassen Wenn die anfangsZeit nach der ankunftsZeit des ersten Haltes liegt wird sie auf diese ankunftsZeit gesetzt Entsprechend wird mit der endZeit und der abfahrtsZeit des letzten Haltes verfahren sucheErsteFahrt Datum Fahrt liefert die erste Fahrt die an oder nach dem angegebenen Datum stattfindet fahrtenInZeitraum Zeitraum Fahrt liefert ein Array aller Fahr ten im angegebenen Zeitraum Noch nicht erzeugte Fahrten werden vorher erstellt fahrt AnTag Datum Fahrt liefert die Fahrt an dem angegebenen Tag zur ck wenn es sie schon gibt Sonst wird null zur ckgegeben erstelleFahrten Zeitraum Fahrt erstellt noch fehlende Fahrten im angegebenen Zeitraum und gibt diese auch zur ck um sie z B dem Benutzer zur Kontrolle anzeigen zu k nnen fahrtenSchreibenUndLoeschen Datum PrintWriter Wenn es ei ne Fahrt an dem angegebenen Tag gibt wird eine Info Zeile in den PrintWriter geschrieben und die Fahrt anschlie end gel scht loescheFahrtenAb Datum l scht alle Fahrten ab dem angegebenen Datum ohne sie zu archivieren 2 2 ALLGEMEINE KONZEPTE 15 fahrdauer int von int nach
46. a der Kunde sp testens um 8 Uhr am Zielort ankommen mu Die Abholzeit kann abh ngig hiervon beliebig gew hlt werden Individualfahrten F r Individualfahrten k nnen dieselben Anforderungen erfa t werden wie f r Schulfahrten Zus tzlich kann gefordert werden da die Mitarbeiter zwischen Hin und R ckfahrt am Zielort bleiben um z B mit ei nem behinderten Kunden ein Konzert zu besuchen Au erdem k nnen beliebige Zwischenstationen mit Aufenthaltsdauern angegeben werden die auf der Fahrt zum Ziel angefahren werden sollen Essen auf R dern Hier werden unter Anforderungen die Anzahl der bestell ten Essen erfa t Zu jeder vorr tigen Essensart Eingabe siehe 7 10 7 kann eine Anzahl zu liefernder Essen angegeben werden Als Ort wird die Adresse erfa t an die die Essen gebracht werden sollen Die Uhrzeit besteht aus Zeitspanne innerhalb derer das Essen geliefert werden mu sowie einer Dauer f r das Abgeben des Essens MSD APD Die Anforderungen umfassen neben den Anspr chen an Mitar beiter Qualifikationen und Vorlieben Abneigungen die Angabe ob der Kunde bei der Verrichtung des Dienstes im Fahrzeug mitfahren soll z B zum Ein kaufen Ist dies angekreuzt kann die Art des erforderlichen Platzes angegeben werden Es mu ein Dienstort angegeben werden an dem der Dienst stattfindet sowie die Uhrzeit wieder als Zeitspanne des Beginns und die Dauer des Dienstes 7 5 3 Dienstw nsche erf llt Erm glicht das gezie
47. a jede Projektgruppe wieder wie wir von Null auf beginnt sondern durch Nutzung dieser Erkenntnisse die Pro jektzeit sinnvoller f r die eigentlich interessanten Problemstellungen verwendet Das schl gt sich bestimmt auch positiv im Ergebnis nieder also in einem guten lauff higen Programm Der Zeitplan sollte die verf gbare Zeit nicht bis auf den letzten Tag verpla nen Der Verlauf mehrerer Projektgruppen hat gezeigt da die Zeit immer bersch tzt bzw die Aufgabe untersch tzt wird Ein Pufferzeitraum am Ende w re sicherlich kein Fehler Reviews m ssen als feste Gr en im Zeitplan vorgesehen werden Dazu mu nach der eigentlichen Durchf hrung jeder Phase mindestens eine Wo che ausschlie lich f r Vorbereitung Durchf hrung und Nachbereitung des Reviews zur Verf gung stehen Die Aufgabenstellung erforderlichenfalls anpassen Lieber ein kleines lauf f higes Programm als eine gro e universelle Planungsruine Die Entscheidung ber die benutzte Programmiersprache sollte m glichst fr h fallen Dann kann man sich rechtzeitig nach Entwicklungsumgebun gen Bibliotheken mit Hilfsfunktionen etc umschauen und in die Syntax und Philosophie der Sprache einarbeiten Ein Prototyp sollte nicht zu fr h erstellt werden da man sonst nicht nur viel zus tzliche Arbeit hat sondern sich auch in selbsterdachten Daten strukturen verrennt die dem tats chlichen Datenmodell dann in die Quere kommen siehe 3 5 Litera
48. ahl von f nf Projektgruppenmitgliedern verringerte sich auf vier nachdem der f nfte Mann die Projektgruppe kurz nach dem Ende der Seminarphase verlassen hatte Da dieser f r die Projektgruppe prinzipiell keine verwendbaren Ergebnisse hinter lassen hatte taucht er in der weiteren Planung nicht mehr auf 8 1 1 Planung des Zeit und Kostenaufwandes Die Planung beruht auf den oben genannten Annahmen sowie einem fikitiven Plan der im Rahmen eines Vortrages ber Projektplanung von Anke Drappa einer Mitarbeiterin der Abteilung Software Engineering der Fakult t f r In formatik der Universit t Stuttgart vorgestellt wurde Der von den Betreuern vorgegebene Rahmen f r die einzelnen Phasen der Projektgruppe sah folgender ma en aus e 17 11 97 21 12 97 Anforderungsanalyse 5 Wochen e 22 12 97 31 01 98 Spezifikation 6 Wochen e 01 02 98 15 03 98 Entwurf 5 Wochen e 16 03 98 29 03 98 Zwischenbericht 2 Wochen e 30 03 98 24 05 98 Implementierung 8 Wochen e 25 05 98 28 06 98 Test 5 Wochen e 29 06 98 15 07 98 Enddokumentation 2 5 Wochen Dies entspricht einem Gesamtaufwand von 33 5 Wochen f r das gesamte Soft wareprojekt Abweichend vom Vorschlag von Anke Drappa wurden die beiden Berichtsphasen mit einbezogen da es sich bei diesen nicht um eine Erstellung 89 90 KAPITEL 8 PROJEKTPLANUNG von Berichten sondern vielmehr um eine Zusammenf gung bestehender Doku mente handelte die im Rahmen der Projektarbeit
49. aten f r die Ausf hrung von Diensten bei diesem Kunden relevant sind z B Eltern eines behinderten Kindes der Hausarzt etc Zus tzlich zu den allge meinen Personendaten siehe 7 5 1 1 sind diese durch die Art des Bezuges charakterisiert hier k nnte Hausarzt oder Mutter eingetragen wer den Ein gewisser Sonderfall sind Sachbearbeiter einer Institution z B der Krankenkasse des Kunden Diese haben als Bezug generell Sachbear beiter sind aber zur n heren Identifikation einer Institution zugeordnet zur Eingabe von Institutionen siehe 7 10 4 Dienstw nsche Hier werden die Dienstw nsche des Kunden erfa t Diese stehen nach Dienstart sortiert in der Liste 74 KAPITEL 7 BEDIENUNGSANLEITUNG 7 5 2 Eingabedialoge f r Dienstw nsche Zur Eingabe eines neuen Dienstwunsches mu zun chst die zugeh rige Dienstart gew hlt werden bevor der passende Dienstwunschdialog ge ffnet wird Die Dienstwunschdialoge sind zweigeteilt Anforderungen Hier k nnen verschiedene dienstwunschspezifische Anforde rungen des Kunden erfa t werden wie z B Art des ben tigten Sitzplatzes oder die Art des zu liefernden Essens Allen Dienstw nschen gemeinsam ist eine Liste von Rechnungsempf ngern f r den Dienst dies k nnen der Kunde selbst Bezugspersonen oder In stitutionen sein eine der angegebenen Bankverbindungen mu f r diesen Dienstwunsch ausgew hlt werden sowie eine Liste mit Bezugspersonen deren Daten mit auf dem Tou
50. ch die M glichkeit diese Pl ne auszudrucken 3 3 4 2 Vorgehensweise Auslastung der Mitarbeiter Die Analyse der Mitarbeiterauslastung erfolgt ber die geplanten Touren bzw Untertouren in einem vom Benutzer frei w hlba ren Zeitrahmen in dem die Sollarbeitszeit der Mitarbeiter im Arbeitszeitprofil festgehalten mit ihrer geplanten Einsatzzeit ins Verh ltnis gesetzt wird Daraus folgt da es dem Benutzer nur m glich ist seine Planung zu analysieren und gegebenenfalls zu verbessern Eine Feststellung der tats chlichen Auslastung ist nicht vorgesehen Um also ein realistisches Ergebnis zu erhalten wird eine Zuweisung der Sollmitarbeiter in den Touren erforderlich d h ein Offenlassen dieser Zuordnung die dem Benutzer in einer fr hen Planungsphase m glich ist f hrt zu Verf lschungen des Ergebnisses Ressourcenbindung Die Analyse der Fahrzeugauslastung erfolgt nur f r die jenigen Dienstw nsche bei denen Gruppen von Kunden transportiert werden Schulfahrt Tagespflege und Dialyse Dabei wird in einem vom Kunden frei zu w hlenden Zeitraum die f r Fahrg ste verf gbare Sitzplatzzahl eines Fahrzeu ges mit der f r den gew hlten Zeitraum durchschnittlichen Zahl mitfahrender Kunden ins Verh ltnis gesetzt Zeit und km Aufwand pro Dienstart Hierbei werden pro Dienstart und pro Untertour die gefahrenen km bzw der zeitliche Aufwand f r die Untertour aufsummiert Ausfallzeiten der Mitarbeiter Fahrzeuge Bildung einer Summe b
51. ckgegriffen werden kann Die im Szenario gespeicherten Stationen lassen sich dadurch in zwei Gruppen einteilen 1 Stationen ohne Namen stehen f r beliebige einmalige Adressen Dabei k nnen mehrere Stationsobjekte zu einer Adresse existieren falls z B zwei Kunden im selben Haus wohnen oder ein Kunde mehrere Dienstw nsche mit derselben Adresse hat 2 Benannte Stationen sind ber ihren Namen eindeutig unterscheidbar Ha ben z B mehrere Kunden dasselbe Ziel verweisen zwei Dienstw nsche auf dieselbe benannte Station Die Eingabe von Stationen geht folgenderma en vor sich e Der Benutzer gibt die Adresse einer Station ein e Hierzu kann er aus den bereits im System bekannten benannten Stationen ausw hlen Name und Adresse der gew hlten Station werden ggf in die Eingabemaske eingetragen e Beendet der Benutzer die Eingabe wird zun chst ein Anbindungspunkt zur Station ermittelt Ist die Station benannt und bereits im Szenario be kannt wird diese bekannte Station mitsamt ihrem bereits bekannten An bindungspunkt benutzt Ansonsten mu der Anbindungspunkt mit Hilfe des Verkehrsmoduls bestimmt werden Hierzu wird die eingegebene Adresse beim Verkehrstool angefragt welches einen keinen oder mehrere alternative Anbindungspunkte zur ckgibt Die letzten beiden F lle erfordern eine R ckfrage beim Benutzer Dieser hat die M glichkeit aus den angegebenen Alternativen eine zu w hlen oder er gibt eine weitere Adresse f r den Anb
52. dings R cksicht auf die zugeh rigen Fahrten genommen werden siehe 7 6 4 7 6 1 1 Eingabedialog f r Touren Jede Tour wird durch eine Nummer eindeutig gekennzeichnet Zus tzlich kann eine Bezeichnung angegeben werden um die Touren f r den Benutzer besser identifizierbar zu machen Jeder Tour k nnen ein oder zwei Mitarbeiter sowie ein Fahrzeug zugewiesen werden die diese Tour normalerweise fahren Es ist sinnvoll diese Eintr ge zu machen da sonst alle Fahrten von Hand bearbeitet werden m ssen da f r sie diese Angaben obligatorisch sind und au erdem die Analysefunktionen sonst keine sinnvollen Werte liefern In der Liste Dienstw nsche werden alle Dienstw nsche angezeigt die auf der Tour erf llt werden damit enth lt die Liste alle Kunden die diese Tour bedient Der Button Einf gen ffnet ein Dialogfenster zur Auswahl eines Dienstwun sches Zun chst mu in der linken Liste ein Kunde ausgew hlt werden draufhin erscheinen in der rechten Liste dessen Dienstw nsche von denen einer gew hlt werden kann 78 KAPITEL 7 BEDIENUNGSANLEITUNG Im unteren Teil des Tourdialoges werden die vereinigten Anforderungen aller Dienstw nsche der Tour angezeigt Diese Angaben dienen nur der Information und bersicht und sollten daher vom Benutzer nicht ver ndert werden sel Abbildung 7 2 Eingabedialog f r Touren 7 6 1 2 Eingabedialog f r Untertouren Da ein Dienstwunsch ein relativ komplexes Gebilde mit
53. e Kosten 2186 Mitarbeiterstunden 150 DM 327 900 DM Das geplante Budget wurde also um 26400 DM berschritten W re das System wie geplant aus programmiert worden w ren der Kosten und Zeit berhang noch deutlicher ausgefallen 94 KAPITEL 8 PROJEKTPLANUNG Arbeitszeitaufwand pro Mitarbeiter Woche Frank J rg Lars Tobias 47 7 50 7 50 5 00 6 50 48 7 50 7 50 6 00 5 50 49 7 50 7 50 6 00 8 50 50 7 50 7 50 7 00 11 50 51 7 50 7 50 6 00 13 00 52 7 50 7 50 20 50 18 50 1 7 50 7 50 16 00 31 00 2 7 50 7 50 11 00 8 50 3 7 50 17 25 8 50 12 50 4 19 75 22 00 14 50 17 00 5 14 00 17 00 18 50 22 00 6 4 25 23 25 17 50 22 00 7 22 00 24 25 18 00 19 00 8 10 00 21 75 14 00 15 50 9 22 25 9 00 13 50 10 00 10 8 75 9 50 12 00 13 50 11 13 50 20 00 18 50 4 50 12 6 00 18 00 9 00 6 50 13 0 00 16 25 13 00 9 50 14 12 00 12 00 13 00 0 00 15 9 50 10 00 18 00 0 00 16 16 00 15 75 0 00 7 50 17 17 00 14 00 17 00 11 00 18 9 00 17 00 16 50 14 50 19 15 00 10 75 21 00 28 50 20 26 00 15 50 23 00 35 00 21 17 25 21 50 19 50 19 00 22 26 25 20 75 23 00 26 00 23 25 75 19 75 21 00 22 50 24 40 75 17 00 28 00 19 00 25 7 50 14 75 16 50 23 50 26 37 50 11 00 7 00 15 50 27 15 25 10 50 5 00 21 00 28 35 50 19 25 5 00 25 00 29 17 75 22 00 18 00 11 00 30 26 50 31 00 17 00 0 00 31 0 00 11 00 12 00 0 00 32 0 00 21 25 12 00 0 00 33
54. e Typ Date wurde durch die ei gene Klasse Datum ersetzt verf gbarkeitsZeiten Zeitraum Daten an denen der Mitarbeiter eingesetzt werden kann bemerkung String Wird jetzt aus der Oberklasse Person geerbt erfuellteQualifikationen Vector Die vom Mitarbeiter erf llten Qua lifikationen arbeitszeit ArbeitszeitProfil Dieses Attribut ist zum Feinentwurf hinzugekommen und nimmt ein Arbeitszeitprofil Sollarbeitszeit f r den Mitarbeiter auf Zus tzlich wurde das Interface Listenelement implementiert 3 3 1 8 Ort e Attribute PLZ String Postleitzahl ohne Einschr nkung auf f nf Stellen Damit sind auch Postleitzahlen im Ausland z B f r private Versicherungen m glich 32 KAPITEL 3 IMPLEMENTIERUNG name String Name des Ortes der zu obiger Postleitzahl geh rt e Methoden boolean gleich Ort Gibt true zur ck wenn dieser Ort mit dem ber gebenen in Postleitzahl und Namen bereinstimmt 3 3 1 9 Person e Attribute name String Nachname der Person vorName String Vorname der Person geburtsDatum Datum Geburtsdatum der Person Jetzt als Datum statt als Date adressen Vector Die zur Person geh renden Stationen kommunikationsVerbindungen Vector Die Kommunikationsver bindungen der Person bankVerbindungen Vector Die Bankverbindungen der Person bemerkung String Hier kann ein beliebiger Text als Anmerkung ein gegeben werden der vom System nicht weiter verwendet wird Zus tzlich wu
55. e es vielleicht vorteilhaft dieses durch ein geeignetes Verkehrs tools bzw sogar durch nackte Verkehrsdaten zu ersetzen Einer Umsetzung der Datenverwaltung auf eine Datenbank kommt das Datenmodell durch eine gewisse Normierung siehe Klassen Ort und Bank entgegen Die in der Oberfl che benutzte Vorgehensweise zum berpr fen und Setzen von Werten eignet durch ihre Anlehnung an das Zwei Phasen Commit Konzept gut f r die Umsetzung auf ein Datenbanksystem Aufsetzen des System TROSS auf ein DBMS Dies k nnte zum einen evtl die schlechte Lade und Speicher Performance ausgleichen und zum an deren k nnte dem Benutzer die M glichkeit geboten werden die Analyse und Ausgabefunktionen dynamisch zu erweitern z B Heraussuchen wie viele Kunden im Plz Bereich 7xxxx best Stadteil z B Stuttgart West wohnen Da TROSS mit sehr gro er Wahrscheinlichkeit auf einem Windows95 System zum Einsatz kommt best nde die M glichkeit das System an statt in plattformunabh ngigen Bytecode in einen plattformabh ngigen Microcode zu bersetzen um so das Laufzeitverhalten zu verbessern Da es sich bei Java um eine sehr junge Programmiersprache handelt die sich aber trotzdem oder gerade deswegen sehr dynamisch entwickelt w re es w nschenswert das System TROSS an neue Entwicklungen der Sprache Java anzupassen Insbesondere bei den noch recht spartanischen M glich keiten der Benutzungsoberfl chenprogrammierung der Version 1 1 Eine wei
56. e tats chlich vorhandenen Ressourcen des Benutzers und die wirklich durchgef hrten Fahrten Erweist sich eine andere Planungsvariante als so gut da sie anstelle der bisherigen benutzt werden soll kann diese jederzeit zum Masterszenario gemacht werden Der Benutzer sollte also darauf achten da das Masterszenario und das Master Tourszenario stets mit der Realit t bereinstimmen also auch regelm ig mitgef hrt werden 7 4 1 Neu Erstellt ein neues leeres Szenario Dessen Name wird vom Benutzer definiert 7 4 2 Laden L dt ein gespeichertes Szenario 7 4 3 Speichern Speichert das aktuelle Szenario in einer Datei 7 4 4 Szenario zum Masterszenario machen Macht das aktuelle Szenario zum Masterszenario Zuk nftig sollten also alle nderungen am Datenbestand an diesem Szenario durchgef hrt werden 7 4 5 Untermenu Tourszenario 7 4 5 1 Neu Erstellt im aktuellen Szenario ein weiteres leeres Tourszenario 72 KAPITEL 7 BEDIENUNGSANLEITUNG 7 4 5 2 Wechseln Wechselt das aktive Tourszenario 7 4 5 3 Kopieren Erstellt eine Kopie des aktiven Tourszenarios unter anderem Namen Dadurch k nnen ausgehend vom momentanen Datenbestand beliebige Ver nderungen auf der Kopie ausprobiert werden ohne das urspr ngliche Tourszenario zu ver ndern 7 4 5 4 L schen L scht ein Tourszenario mit allen seinen Daten aus dem Szenario 7 4 5 5 Umbenennen Gibt einem Tourszenario einen anderen Namen 7 4 5 6 Zum Master
57. e v llig uninteressant da die Fahrt abge lehnt wird Diese Entscheidung kann auf Grundlage der Datenausgabe getroffen werden deren Testergebnisse in 4 1 4 3 zu finden sind Kapitel 5 Architektur des Programms TROSS 5 1 Architektur des System TROSS Abbildung 5 1 bietet einen berblick ber die gesamte Architektur des System TROSS 5 2 Graphische Benutzungsoberfl che Eine schematische bersicht bietet Abbildung 5 2 5 3 Verkehrsmodul Abbildung 5 3 zeigt den prinzipiellen Aufbau und die Verwendung des Verkehrs moduls 56 Ausgabe Plaene Analyse Szenario Verkehrsmodul Szenariol Tour Tour szenarioll Szenario INUONSUHHMYHA CO Konsistenz sicherung 19 persistenter Speicher Abbildung 5 1 Architektur des System TROSS KAPITEL 5 ARCHITEKTUR DES PROGRAMMS TROSS TRO GUI java lang Dialog java lang Panel 58 TastaturDialog GroupFramePanel ZeitspannePanel e a UhrzeitPanel IntegerFeld DatumsFeld o r r Ir i Von g stunden sado A J i Bis Ji minuten 1 D OKCancelDialog ObjektListePanel TRO GU Kunden i TRO GUI Ressourcen TRO GUI Ausgabe TRO GUI Touren i r 8 i J e J J e J e S i i
58. ePanel ElementListener class TRO GUI Definitionen FeiertageDialog implements TRO GUI ObjektListePanel ElementListener class TRO GUI Definitionen HilfsmittelListeDialog implements TRO GUI ObjektListePanel ElementListener TRO GUI ObjektListePanel InformationListener class TRO GUI Definitionen InstitutionenDialog implements TRO GUI ObjektListePanel ElementListener class TRO GUI MeldungDialog class TRO GUI VerkehrstoolLaeuftNichtDialog class TRO GUI Definitionen QualifikationenDialog implements TRO GUI ObjektListePanel ElementListener TRO GUI ObjektListePanel InformationListener Frame implements java awt MenuContainer class TRO Tross implements java awt event ActionListener class java awt List implements java awt ItemSelectable class TRO GUI ObjektListe class java awt TextComponent class java awt TextField class TRO GUI DatumsFeld class TRO GUI IntegerFeld o class TRO Datum implements java lang Cloneable java io Serializable o class TRO Datumsspanne implements java io Serializable TRO ListenElement o class TRO Dienstwunsch implements java io Serializable TRO ListenElement class TRO EARDienstwunsch implements java io Serializable 5 4 KLASSENHIERARCHIE 65 class TRO MSDDienstwunsch implements java io Serializable class TRO TransportDienstwunsch implements java io Serializable o interface TRO Druckbar o class TRO Essensart implements java io Se
59. ebung Die Entwicklungsumgebung f r das Projekt TROSS zeichnete sich vor allem da durch aus da keine Entwicklungsumgebung vorhanden war Programmierung Compilieren und Testen mu ten von Hand via Editor und Kommandozeilen aufrufe der Java Tools gemacht werden Zwei Punkte d rften dazu wesentlich beigetragen haben 1 Die Entscheidung welche Programmiersprache eingesetzt wird wurde erst sehr sp t gef hrt Das f hrte dazu da der gesamte Prototyp von Hand erstellt werden mu te Eine komplette Neuerstellung w re wohl auch mit Entwicklungsumgebung recht zeitaufwendig geworden Dar berhinaus h tte die Suche nach einer geeigneten Entwicklungsumgebung sowie die Einarbeitung darin einige Projektzeit verschlungen W re zu Beginn der Projektgruppe wenigstens dieses Grundhandwerks zeug dagewesen h tte sicher mancher sp tere Aufwand vermieden werden k nnen 2 Da zu Beginn der Projektgruppe die Maxime ausgegeben wurde alle ver wendeten Programme d rften m glichst nichts kosten war es kaum m g lich eine leistungsf hige Entwicklungsumgebung zu bekommen Wir mu ten also auch ohne GUI Builder auskommen der beim Erstellen der Benutzungsoberfl che eine betr chtliche Hilfe dargestellt h tte Viel Handar beit war angesagt um zus tzliche Oberfl chenelemente zu realisieren und die bestehenden mit ihrer rudiment ren Schnittstelle zu bedienen Insbesondere das Setzen und Auslesen von Eingabewerten siehe 3 1 2 1 h tte sich
60. ein gegebene Werte nderungen in Listen wie in 3 1 2 2 und 3 1 2 5 beschrieben werden direkt nach deren Best tigung in den Datenobjekten durchgef hrt da die obige Vorgehensweise hier noch deutlich komplizierter umzusetzen w re 3 1 2 2 Auswahl aus Listen Eine h ufige Aktion bei der Arbeit mit der graphischen Benutzungsoberfl che stellt die Auswahl eines oder mehrerer Elemente aus einer Menge dar e Zur Auswahl genau eines Elements dienen herunterklappende Auswahlli sten die jeweils nur das gew hlte Element zeigen Java nennt diese Choi ce unter MS Windows sind sie als Combobox bekannt Da nicht in jedem Fall eine Auswahl aus der angebotenen Liste obligato risch ist z B ist eine Tour auch ohne Angabe der Soll Mitarbeiter g ltig bietet die Auswahlliste gegebenenfalls ein Dummy Element Keine Aus wahl an erster Stelle an nach dessen Auswahl die zugeh rige Variable auf null gesetzt wird e Die Auswahl mehrerer Elemente also einer Teilmenge geschieht je nach Gr e auf zwei unterschiedliche Arten 26 KAPITEL 3 IMPLEMENTIERUNG Kleinere Listen z B m gliche Qualifikationen der Mitarbeiter bei denen auch der berblick ber die nicht gew hlten Elemente interes sant ist werden komplett dargestellt bzw ein mehrelementiger Aus schnitt mit Scrollbalken Die Auswahl und Abwahl von Elementen erfolgt durch Mausklick worauf das gew hlte Element durch inverse Darstellung gekennzeichnet wird
61. ementierung kam die Frage auf was mit Dienstw nschen ge schehen soll die nicht sofort wirksam werden oder an denen nur nderungen vorgenommen wurden Da die meisten nderungen vermutlich zu diesen Grup pen geh ren mu te ein einfach aufsetzbares Konzept gesucht werden Die beste M glichkeit w re gewesen den Untertouren und unter Umst nden auch den Touren eine Datumsspanne zu geben w hrend der sie g ltig sind Dies h tte jedoch umfangreiche Ver nderungen am gesamten System zur Folge gehabt weshalb eine andere L sung gesucht wurde Das System kennt von einer Untertour immer nur eine Version Der Benutzer mu sich geplante nderungen extra aufschreiben und zum gegebenen Zeit punkt einf gen Um feststellen zu k nnen welche W nsche eines Kunden er f llt wurden werden alle Fahrten bevor sie gel scht werden in eine Log Datei geschrieben die von TROSS nicht weiter verwendet wird aber z B in eine Ta bellenkalkulation geladen werden kann In dieser Datei werden f r jede statt gefundene Fahrt alle Halte mit den jeweils betroffenen Kunden gespeichert Je nach Dienstart werden auch noch zus tzliche Informationen gespeichert wie zum Beispiel bei einem Essens Dienstwunsch Art und Anzahl der Essen Durch dieses Auslagern wird auch der aktive Datenbestand von TROSS immer wieder reduziert Die Fahrt hat nun folgenden Aufbau e Attribute untertour Untertour die Untertour zu der die Fahrt geh rt datum Datum anfangsZei
62. en da diese immer gesetzt werden m ssen Soll ein ein mal erzeugter Dialog nochmals benutzt werden m ten diese Objekte mit eigenen Methoden gesetzt werden Das Dialogfenster m te bei jeder erneuten Benutzung Pr fungen durchf hren ob diese Werte alle gesetzt wurden und gegebenenfalls Exceptions ausl sen die im aufrufenden Ob jekt abgefangen werden m ten Letztlich m ten also auch alle Aufrufer ge ndert werden Die Projekt gruppe entschied sich daf r die bersichtliche Handhabung der Dialogfen ster im Programm nicht daf r zu opfern Probleme der Laufzeitumgebung zu kompensieren Au erdem kann das Zeitproblem durch den Einsatz eines Compilers der Javain reinen Maschinencode f r das Zielsystem umsetzt vermutlich stark relativiert werden 28 KAPITEL 3 IMPLEMENTIERUNG 3 2 2 Destruktoren In Java arbeitet die Speicherverwaltung automatisch und f r den Programmierer weitgehend unsichtbar Neue Objekte werden mit new angefordert um eine Frei gabe braucht sich das Programm nicht zu k mmern Diese wird vom Laufzeit system erledigt das in gewissen Abst nden seinen garbage collector aktiviert der alle Objekte die im Programm nicht mehr referenziert werden aufsammelt und den zugeh rigen Speicher freigibt Klassen k nnen die Methode finalize implementieren um externe Ressour cen vor dem L schen des Objekts durch den Garbage collector freizugeben Im Projekt TROSS ist es n tig beim L schen einer Station den
63. en vom Feinentwurf der Personenklassen beschrieben Alle Klassen besitzen zus tz lich die standardm igen setze und lese Methoden Ebenso wurde wenn nicht anders angegeben bei allen Klassen ein leerer Konstruktor der alle referenzier ten Objekte mit new initialisiert und ein vollst ndiger Konstruktor der alle Werte mit den bergebenen initialisiert implementiert Zu den Schl sselattributen ist anzumerken da deren Schl sseleigenschaft von der Benutzungsoberfl che unter Verwendung des Packages Konsistenztests 1 Parameter R ckgabewerte gleichen Typs wie die Attribute lese Methoden hei en genauso wie das Attribut die setze Methoden hei en setze Attribut Name 3 3 UMSETZUNG DES ENTWURFS IN DER IMPLEMENTIERUNG 29 und nicht von den Klassen selbst sichergestellt wird Das gleiche gilt f r die Mu werte Auch hier ist die Angabe beim jeweiligen Attribut nur eine Informa tion f r die entsprechende Umsetzung in der Benutzungsoberfl che 3 3 1 1 Bank Diese Klasse wurde gegen ber dem Feinentwurf nur marginal ver ndert e Attribute bankLeitZahl int Die Bankleitzahl wurde wegen der einfacheren Handhabung als Integer anstatt als String implementiert Au erdem wurde die Begrenzung auf acht Stellen aufgehoben bankName String Name der Bank mit obiger Bankleitzahl 3 3 1 2 Bankverbindung e Attribute bank Bank Dient zur Referenzierung des zugeh rigen Bankobjektes der Bank bei dem die Bankverbindung besteh
64. en werden kann Ist das Verkehrstool angeschaltet siehe 7 10 9 wird ermittelt ob die Adres se dort bekannt ist Konnte sie nicht eindeutig identifiziert werden erscheint ein Dialog mit Alternativvorschl gen des Verkehrstools In den Eingabefeldern kann jetzt entweder einer dieser Vorschl ge bernommen werden oder man gibt eine Adresse an die in der N he der urspr nglich gew nschten liegt z B die n chstgr ere Stra e Ist diese Adresse dem Verkehrstool bekannt wird sie als Grundlage f r Fahrzeitberechnungen benutzt 7 10 6 Hilfsmittel Hier k nnen alle Hilfsmittel erfa t werden die Kunden ben tigen und deshalb in ihren Dienstw nschen fordern 7 10 6 1 Eingabedialog f r Hilfsmittel Hilfsmittel werden durch eine kurze Bezeichnung sowie eine ausf hrlichere Be schreibung definiert 7 10 7 Essensarten Alle Essensarten die der Dienst Essen auf R dern anbietet m ssen hier erfa t werden damit sie in den Dienstw nschen gew hlt werden k nnen 7 10 7 1 Eingabedialog f r Essensarten Essensarten werden durch eine kurze Bezeichnung sowie eine ausf hrlichere Be schreibung definiert 7 10 8 Feiertage Damit das Programm wei welche Tage Feiertage sind was sich auf das Statt finden von Diensten auswirkt m ssen hier deren Daten eingegeben werden Es empfiehlt sich die Feiertage immer einige Monate im voraus zu erfassen da mit eventuelle Auswirkungen auf die Planung rechtzeitig ber cksichtigt w
65. enz auf alle Arbeitszeit profile des Szenarios tourSzenarien Sortierter Vektor Referenz auf alle Tourszenarien des Szenarios aktivesTourszenario TourSzenario Referenz auf das aktuell akti vierte Tourszenario e Methoden void wurdeGeaendert Setzt das Ge ndert Flag auf wahr und mu immer aufgerufen werden wenn sich irgendein Objekt ndert Diese Methode ersetzt die setzeGeaendert Methode da das Ge ndert Flag von au en nicht auf false gesetzt werden darf Szenario laden String pfad String name L dt das angegebene Szenario in den Speicher Die Methode soll nur aufgerufen werden wenn sich kein ver ndertes Szenario im Speicher befindet 36 KAPITEL 3 IMPLEMENTIERUNG void speichern String pfad String name Speichert das im Haupt speicher befindliche Szenario unter dem angegebenen Namen und setzt das Ver nderungsflag auf false Stimmt der bergebene Name nicht mit dem des Szenarios berein speichern als wird der ber gebene Name als neuer Szenarioname bernommen boolean istStationBekannt String name berpr ft ob der berge bene Name schon f r eine benannte Station verwendet wurde und gibt einen entsprechenden Wahrheitswert zur ck Station sucheStation String name Gibt die Station zum bergebe nen Namen zur ck Die Methoden zum L schen und Kopieren wurden aus Zeitgr nden nicht imple mentiert da diese durch entsprechende Dateioperationen auf Betriebssystem ebene erreicht werden k nnen A
66. er die vom Benutzer im System pro Mitarbeiter bzw pro Fahrzeug eingetragenen Ausfallzeiten Da im System keine genaue Aufteilung ber die Art des Ausfalls der einzelnen Ressourcen erfolgt kann diese folglich auch nicht in der Analyse dargestellt werden Dieser Analysepunkt soll dem Benutzer vielmehr mittels eines berblicks Auff lligkeiten aufzeigen die er dann verfolgen kann 3 4 PROBLEME BEIM UMSETZEN DES ENTWURFS 41 3 3 5 Datenausgabe 3 3 5 1 Einzeldienstplan Der Einzeldienstplan wurde als Balkendiagramm realisiert Er kann f r Objek te die das DienstplanErstellbar Interface implementieren ber eine beliebige Datumsspanne erzeugt werden Zur Auswertung wird die Methode objektFahr ten des Tourszenarios aufgerufen Damit liegt der Aufwand wie im Abschnitt 3 3 2 2 beschrieben in O Anz d Fahrten Das im Abschnitt 2 1 2 beschriebene DienstplanErstellbar Interface dient als Schnittstelle die f r beliebige sinnvolle Objekte implementiert werden kann Dadurch ist es m glich neben Dienstpl nen f r Mitarbeiter auch Fahrzeugein satzpl ne zu erzeugen und darzustellen wann ein Kunde vom DRK betreut wird 3 3 5 2 Gesamtdienstplan Der Gesamtdienstplan wurde als Exportfile implementiert Dieses Exportfile enth lt zu allen Mitarbeitern die Fahrten die sie im angegebenen Zeitraum zu erledigen haben Dieses Exportfile kann dann mit einem anderen Programm z B einer Tabellenkalkulation beliebig aufbereitet und gedruckt werden
67. er Kanten anzahl per Schleife erst danach Vergleich mit 0 Deswegen ist dieser Algorith mus mit einem Aufwand von O n auch langsamer als der alte im Kapitel Feinentwurf des Zwischenberichts vorgestellte mit einem Aufwand von O n Durch kleine Optimierungen k nnte dies auf O n m O n verbessert wer den n Anzahl Knoten m Anzahl Kanten In der Praxis werden aber die gesparten Kanten durch den nur im neuen Algorithmus ber cksichtigten Ca che den Ausschlag geben da die Kommunikation mit Map amp Guide lange dauert nach bisheriger Erfahrung midestens 5 Sekunden F r alle 11175 Entfernungen zwischen 150 Knoten m ssen etwa 559 Anfragen an Map amp Guide gestellt werden Die Zeit daf r wurde nicht gestoppt d rfte aber in der Gr enordnung von 2 Stunden liegen Allerdings wird diese Methode in der aktuellen Implementierung gar nicht ver wendet eine automatische Optimierung ist nicht Bestandteil des Programms Das System in seiner momentanen Gestalt ben tigt Entfernungen nur zwischen den aufeinanderfolgenden Stationen einer Untertour Diese Kantenmenge l t sich f r normale Touren mit nicht mehr als 20 Stationen in etwa 15 Sekunden bearbeiten 2 2 ALLGEMEINE KONZEPTE 21 2 2 3 1 Moeglicher AnbindungsPunkt Objekte dieser Klasse werden zum Erstellen von Anbindungspunkten f r Sta tionen ben tigt Attribute station Station ein Verweis auf die Station strasse String Der Name der Stra e hausNr Strin
68. erden k nnen 7 10 8 1 Eingabedialog f r Feiertage Ein Feiertag wird durch Namen und Datum charakterisiert 7 10 9 Verkehrstool Um Entfernungen und Fahrzeiten zwischen den diversen Stationen automatisch ermitteln zu k nnen ist das Programm TROSS in der Lage mit dem Routen planungsprogramm Map amp Guide zusammenzuarbeiten Dieses Programm wird hier als Verkehrstool bezeichnet 88 KAPITEL 7 BEDIENUNGSANLEITUNG 7 10 9 1 Einstellungsdialog f r das Verkehrstool Hier kann angegeben werden ob Map amp Guide als Verkehrstool verwendet werden soll F r den Einsatz von Map amp Guide mu der Pfad zu diesem Programm sowie ein Verzeichnis angegeben werden in das die Auftragsdateien f r dessen Batch Schnittstelle abgelegt werden n here Informationen hierzu sind dem Handbuch zu Map amp Guide zu entnehmen sein Je nach Wahl des Benutzers arbeitet TROSS also in einem von zwei Modi mit Verkehrstool Hier werden s mtliche Entfernungen und Fahrzeiten vom Verkehrstool erfragt Ebenso werden alle Stationen nach ihrer Eingabe dahingehend berpr ft ob sie dem Verkehrstool bekannt sind Da diese Anfragen ber die langsame Batch Schnittstelle von Map amp Guide laufen kann es jeweils zu gewissen Wartezeiten kommen Sollte der Modus mit Verkehrstool eingestellt sein dieses aber aus irgend welchen Gr nden nicht korrekt ansprechbar sein wird die momentane Operation mit einer entsprechenden Fehlermeldung abgebrochen ohne Verke
69. es Dienstwunsches in der Untertour so werden auch alle nicht mehr ben tigten UntertourHalte entfernt wunschEntfernen Dienstwunsch Entfernt alle Teildienstw nsche die zu dem angegebenen Dienstwunsch geh ren aus der Untertour Die Fahrten bleiben erhalten sollten aber gel scht werden die Be nutzungsoberfl che erledigt dies automatisch Nach nderungen an einer Tour oder Untertour werden alle noch nicht erfolgten Fahrten deren Datum in der Zukunft liegt gel scht laenge int Die L nge der Untertour in Metern Beinhaltet auch Anfangs und Endstation 2 2 2 1 TeilDienstwunsch Im Entwurf waren die Untertouren als einfache Datenklassen gedacht denen die Stationen mit den Ankunfts und Abfahrtszeiten einfach bergeben werden W hrend der Implementierung kam dann der Wunsch auf Dienstw nsche in die Untertour einzuf gen Da ein Dienstwunsch aber unterschiedliche Rhythmen haben kann und unter Umst nden auch R ckfahrten enth lt ist nicht klar wie ein neuer Dienstwunsch die bestehende Stationenfolge ver ndern soll Deshalb wurde die Klasse TeilDienstwunsch eingef hrt Ein TeilDienstwunsch ist ein Teil eines Dienstwunsches der genau einen Rhythmus hat an einem Wochentag stattfindet und entweder Hin oder R ckfahrt ist e Attribute wunsch Dienstwunsch der Dienstwunsch zu dem dieser TeilDienst wunsch geh rt wochentag int der Wochentag rhythmus Rhythmus ein Verweis auf den Rhythmus hinFahrt boolean gibt
70. eses Dokument ist nicht als alleinstehender Bericht aufzufassen sondern kn pft direkt an den Zwischenbericht der Projektgruppe Transportoptimierung Pr098 an Beide Berichte zusammen ergeben einen kontinuierlichen berblick ber die Arbeit der Projektgruppe von Oktober 1997 bis September 1998 Die Lekt re dieses Endberichts setzt also teilweise die Kenntnis des Zwischenbe richts voraus Begriffe die bereits im Zwischenbericht ausf hrlich eingef hrt und definiert wurden werden hier ohne erneute Definition benutzt Leser die daran interessiert sind woraus z B die praxisnahe Lehrveranstaltungsform der Projektgruppe im einzelnen besteht k nnen dies im Zwischenbericht nachlesen Der Endbericht setzt dort an wo der Zwischenbericht endet Beim Entwurf Teile des Entwurfs die erst nach dem Zwischenbericht fertiggestellt wurden oder deren Notwendigkeit sich gar erst w hrend der Implementierungsphase ergab sind hier festgehalten Danach folgt der Bericht ber die wichtigsten Aspekte der Projektphasen Implementierung und Test dem sicherlich nicht die geb hren de Aufmerksamkeit geschenkt wurde aber Zeitprobleme scheinen offensichtlich zum Wesen einer Projektgruppe zu geh ren Eine bersicht ber das entstan dene Programm aus Programmierersicht zeigt Kapitel 5 mit einer schematischen Darstellung der Architektur des Systems die Benutzerseite beschreibt die Be dienungsanleitung in Kapitel 7 Ein solch langes und aufwendiges Projekt soll
71. ett umgesetzt werden Ob die nderungen der Dienstw nsche in den Touren durch Umsetzen der Kun den in den Untertouren und Fahrten richtig nachvollzogen wird konnte nicht festgestellt werden da es nicht m glich war Untertouren zu bilden 4 3 0 2 MSD Pflegedienst Szenario 1 Das Szenario konnte mit TROSS nachvollzogen werden Die Vor gabe beide Dienstanforderungen als einen Dienstwunsch zu erfassen kann nach vollzogen werden hat im System jedoch folgendes Problem Auf der Tour mu immer ein teurer Pfleger mitgehen auch wenn nur Eink ufe zu erledigen sind Szenario 2 Bei der Umsetzung des zweiten MSD Szenarios traten zwei Fehler auf Zum einen war gefordert einen bevorzugten Mitarbeiter festzulegen Dies geschah bei der Eingabe des Dienstwunsches allerdings war die Eingabe beim n chsten Aufruf der Dienstwunschmaske wieder verschwunden Das zweite Problem machte die Ausnahmezeiterfassung beim Kunden Es sollten zwei Zeitr ume eingegeben werden in denen die Kundin nicht bedient werden soll Allerdings wurde die zweite Eingabe ignoriert und daf r der erste Zeitraum unter Windows um einen Tag nach vorne verschoben 4 3 0 3 Essen auf R dern Szenario 1 Das Szenario konnte erfolgreich nachvollzogen werden Szenario 2 Bei diesem Szenario traten folgende Probleme auf Zun chst sollte eine Email Adresse eingegeben werden da der Kunde per Email bestellte Dabei fiel auf da unter Windows95 die Eingabe des Zeichens nic
72. ezugspersonen hier hinterlegt wer den 3 3 UMSETZUNG DES ENTWURFS IN DER IMPLEMENTIERUNG 31 institutionen Vector Hier werden die Institutionen abgelegt die einen Bezug zum Kunden haben bevorzugt Vector Die vom Kunden bevorzugten Mitarbeiter diese sollen i d R dessen Dienstw nsche erf llen abgelehnt Vector Die vom Kunden abgelehnten Mitarbeiter diese d rfen keine Dienste beim Kunden verrichten hilfsmittel Vector Die vom Kunden ben tigten Hilfsmittel wie Sitz kissen u die ber die Attribute des Dienstwunsches hinausgehen Diese Werte sind nur informativ und werden bei der automatischen Planung nicht ber cksichtigt zulaessigeFahrzeuge Vector Fahrzeuge die f r den Kunden vom DRK freigegeben wurden Ist dieser Vektor leer d rfen alle Fahr zeuge bei dem Kunden eingesetzt werden dienstwuensche Vector Die Dienstw nsche des Kunden Zus tzlich wurde das Interface Listenelement implementiert 3 3 1 7 Mitarbeiter Unterklasse von Person e Attribute personalNr String Schl ssel Personalnummer des Mitarbeiters beim DRK die diesen eindeutig identifiziert dienstantrittsDatum Datum Datum zu dem der Mitarbeiter seinen Dienst beim DRK antritt Der im Feinentwurf vorgesehene Typ Date wurde durch die eigene Klasse Datum ersetzt entlassungsDatum Datum Datum zu dem der Mitarbeiter ausschei det Bei festangestellten Mitarbeitern ist dieser Eintrag in der Regel leer Der im Feinentwurf vorgesehen
73. finitionen ArbeitszeitArtDialog implements java awt event ActionListener class TRO GUI Dienste DienstartDialog implements java awt event ActionListener 62 KAPITEL 5 ARCHITEKTUR DES PROGRAMMS TROSS class TRO GUI TastaturDialog implements java awt event KeyListener java awt event ContainerListener class TRO GUI JaNeinDialog class TRO GUI 0KCancelDialog class TRO GUI AdresseDialog class TRO GUI Definitionen ArbeitszeitProfilDialog class TRO GUI Kunden BankverbindungsDialog class TRO GUI Definitionen BenannteStationDialog class TRO GUI Kunden BezugsPersonDialog class TR0 GUI DatumsspanneDialog class TRO GUI DienstwunschWahlDialog class TRO GUI ElementWahlDialog class TRO GUI Definitionen EntfernungDialog class TRO GUI Definitionen EssensartDialog class TRO GUI Touren FahrtDialog implements java awt event ActionListener class TRO GUI Definitionen FahrzeugkonfigurationsDialo implements TRO GUI HashPanel HashListener class TRO GUI Definitionen FahrzeugtypDialog implements TRO GUI ObjektListePanel ElementListener class TRO GUI Definitionen FeiertagDialog class TRO GUI Definitionen HilfsmittelDialog class TRO GUI Definitionen InstitutionDialog class TRO GUI Kunden KommunikationsverbindungsDialog class TRO GUI KonsistenzDialog class TRO GUI Definitionen QualifikationDialog class TRO GUI RegisterDialog class TRO GUI Dienste EssenDialog implements TRO GUI Ha
74. g Die Hausnummer postLeitZahl String Die Postleitzahl ortsname String Der Name des Ortes MGsStation String Der String der an Map amp Guide bergeben werden soll Kann null sein korrekturListe String Die von Map amp Guide gelieferten Alternati ven Methoden MGsStation String Gibt den String zur ck der an Map amp Guide bergeben werden soll Wurde MGStation nicht gesetzt wird das Er gebnis von standardMGStation zur ckgegeben istInOrdnung boolean Gibt true zur ck gdw in der korrekturListe genau ein Eintrag enthalten ist standardMGsStation String Liefert Orte postLeitZahl ortsName strasse hausNr 2 2 3 2 AnbindungsPunkt Zwischen Paaren von Anbindungspunkten speichert das Verkehrsmodul Entfer nungen und Fahrzeiten Attribute MGsStation String Der Ortsbezeichner f r Map amp Guide anzahlVerwendungen int gibt an wie oft dieser Anbindungspunkt verwendet wird Methoden istDummy boolean Gibt true zur ck wenn der Anbindungspunkt kein von Map amp Guide gepr fter Anbindungspunkt ist Verkehrstool wird nicht verwendet 2 2 3 3 EntfernungsTabelle In einer Instanz dieser Klasse werden die Entfernungen zwischen den Anbin dungspunkten gespeichert Attribute 22 KAPITEL 2 NACHTRAG ZUM ENTWURF tabelle Hashtable In dieser Tabelle werden Paaren von Anbindungs punkten EntfernungsTabellenEintr ge zugeordnet Die Tabelle ist symmetrisc
75. gte die besonders komplizierten oder auch nur komplexen Begriffe auf W h rend Spezifikation und Entwurf beim Umsetzen in Datenstrukturen und Algo rithmen Verfahren und Schnittstellen kam deutlich zutage da mit vier Perso nen in acht Wochen an eine komplette Umsetzung der bisher entwickelten Ideen in ein laufendes Programm nicht zu denken war 9 3 Zust ndigkeiten und Kompetenzen in der Projektgruppe Ein Grundproblem bei der praktischen Durchf hrung dieser Projektgruppe war die weder eindeutig noch sinnvoll festgelegte Verteilung von Entscheidungskom petenz einerseits und Verantwortung f r Entscheidungen andererseits So wurden sowohl Zeitplan als auch die Aufgabe von den Betreuern vorge geben Versuche von Seiten der Projektgruppe die Aufgabenstellung auf das zeitlich M gliche einzuschr nken wurden meist abgeblockt mit Auflistung von Funktionen die noch gemacht werden m ssen Der f r den Zeitplan zust n dige Student konnte diese Vorgaben lediglich mit dem Programm MS Project verwalten und hatte die undankbare Aufgabe die regelm igen Kassandra Rufe zum zeitlichen Stand des Projekts zu verk nden Die Beschaffung des Verkehrstools Map amp Guide erfolgte als verbl ffender Schnellschu Lange Zeit ruhte man sich auf der scheinbaren Gewi heit aus da passende Verkehrsdaten zur Verf gung stehen w rden Nachdem sich dies als falsch herausstellte da die an der Universit t vorhandenen Verkehrsdaten n
76. h e Methoden setzeEintrag AnbindungsPunkt von AnbindungsPunkt nach int fahrdauer int entfernung boolean vonBenutzer setzt den Eintrag in der Entfernungstabelle eintrag AnbindungsPunkt AnbindungsPunkt Entfernungs TabellenEintrag liefert den Eintrag zu den beiden Anbindungs punkten oder null entferneEintraegeMit AnbindungsPunkt AnbindungsPunkt Entfernt alle Eintr ge mit dem angegebenen AnbindungsPunkt aus der Tabelle 2 2 3 4 EntfernungsTabellenEintrag Ein Eintrag in der Hashtabelle tabelle einer EntfernungsTabelle e Attribute fahrdauer int die Fahrdauer in Minuten entfernung int die Entfernung in Kilometern vonBenutzer boolean true wenn der Eintrag vom Benutzer gesetzt wurde und nicht vom Verkehrstool stammt Kapitel 3 Implementierung 3 1 Entwurfsentscheidungen auf Programmier sprachenebene 3 1 1 Allgemeine Konzepte 3 1 1 1 Sortieren und Sortierbarkeit Da Java kein Konzept f r sortierbare Objekte bietet mu te ein solches von der Projektgruppe selbst entworfen und implementiert werden Um Klassen wie selbstsortierende Listen zu realisieren wurden zwei Interfaces definiert die von allen Klassen implementiert werden m ssen deren Instanzen in einer solchen Liste gespeichert bzw angezeigt werden sollen Comparable Vergleichbare Objekte implementieren die Methode compareTo nach dem Vorbild des JDK Leider k nnen die fertigen Java Klassen dieses Interface nicht mehr implementieren selbst
77. h Review Beendigung des Zwischenberichts Ergebnis angenommenes Dokument geplant 27 03 98 Abnahme durch Review Beendigung der Implementierung Ergebnis angenommenes Dokument geplant 22 05 98 Abnahme durch Review Kunden Beendigung des Tests Ergebnis angenommenes Dokument 8 1 PLANUNG F R DAS PROJEKT TRANSPORTOPTIMIERUNG 91 geplant 26 06 98 Abnahme durch Review e Beendigung des Endberichtes Ergebnis angenommenes Dokument geplant 15 07 98 Abnahme durch Review Hinzu kamen noch verschieden Besprechungstermine um die Anforderungen des Kunden herauszuarbeiten und um offene Fragen bez glich der Realisierung zu kl ren 8 1 3 Projektverlauf Die Zusammenfassung des Projektes ahnlich erfolgt wie bei der Vorstellung der Meilensteine 8 1 2 in tabellarischer Form Die einzelnen Daten werden doppelt dargestellt Auf der einen Seite das Datum an dem der Projektabschnitt tats chlich begonnen hat und auf der anderen Seite in Klammern der geplante Beginn Eine berschneidung der einzelnen Phasen kommt dadurch zustande da die einzelnen Phasen an ihren Schnittstellen teilweise parallel bearbeitet wurden d h der Abschlu der einen Phase Korrektur der Berichte kleinere nderungen fiel in den Beginn der neuen Phase e Anforderungsanalyse Beginn 17 11 1997 17 11 1997 was wurde getan einige Vortr ge ber Werkzeuge und Programmiersprachen die f r das Projekt n tzlich sein k nnten
78. h aus dem UntertourHalt an der alten Position zwei tes Argument zur neuen Position drittes Argument Gibt es an dieser Position schon einen Halt mit der Station des zu verschieben den Dienstwunsches wird der Dienstwunsch an diesem Halt erf llt ansonsten wird ein neuer UntertourHalt angelegt dienstwuensche Dienstwunschl Liefert ein Feld mit den Dienst w nschen die sich aus den Teildienstw nschen ergeben teilDienstwunschHinzufuegen TeilDienstwunsch Nimmt den Teil Dienstwunsch mit seinen Stationen zur Untertour hinzu Bei einer R ckfahrt wird die Stationenfolge umgedreht Um f r den Benutzer aufwendige Verschiebungen m glichst zu ver meiden wird eine gemeinsame Station von Teildienstwunsch und bis heriger Untertour gesucht Gibt es eine solche Station werden alle Stationen des Teildienstwunsches vor dieser Station am Anfang der Untertour angef gt und der Halt mit der gleiche Station wird ge meinsam verwendet Die restlichen Stationen alle wenn es keine gemeinsame Station gibt werden an das Ende angeh ngt Bei der anschlie enden Korrektur der Fahrzeiten kann es zu Fehler meldungen des Verkehrsmoduls kommen die weitergereicht werden Ob Rhythmen oder Wochentage passen wird hier nicht gepr ft da das Aufgabe der Konsistenzpr fung ist 16 KAPITEL 2 NACHTRAG ZUM ENTWURF teilDienstwunschEntfernen TeilDienstwunsch Entfernt den ange gebenen TeilDienstwunsch aus der Untertour War er der letzte Teil ein
79. heiden zu m ssen Durch diese einheitliche Gestaltung der Konsistenzpr fung besteht auch kein wesentlicher konzeptioneller Unterschied zwischen harten Integrit tsbedingun gen die auf jeden Fall erf llt sein m ssen da sonst die Daten in sich keinen Sinn geben und weichen semantischen Konsistenzbedingungen im Entwurf als Vorgaben bezeichnet die Beziehungen zwischen Objekten der realen Welt beschreiben und vom Benutzer im Einzelfall au er Kraft gesetzt werden k nnen Verst e gegen Integrit tsbedingungen werden durch Exceptions angezeigt die von der Klasse Integrit tsException abgeleitet sind Andere von KonsistenzException abgeleitete Exceptions stehen f r semantische Konsi stenzverletzungen Somit kann durch eine minimale Fallunterscheidung bei der Dateneingabe festgestellt werden ob die Daten im eingegebenen Zustand ak zeptiert werden d rfen S mtliche Konsistenzpr fungen liegen in einem eigenen Modul TRO Konsistenztests das zu jeder zu pr fenden Datenklasse eine zuge h rige Pr fklasse definiert Durch diese Trennung der Konsistenzpr fungen von sowohl Dateneingabe als auch den Daten selbst kann die interne Durchf h rung der Pr fungen ohne Auswirkungen auf das restliche System geplant und umgesetzt werden Eine Ver nderung der Pr falgorithmen oder auch die Ver nderung der Pr fkriterien und dadurch notwendige Hinzunahme neuer Tests oder Auslassung bestehender kann somit lokal im Modul TRO Konsis
80. hier die einfach und sicher zu implementierende Methode gew hlt 2 Beim ndern von Objekten dazu geh rt auch das Setzen von Daten in neu erzeugten Objekten wird kontrolliert da allen vorgeschriebe nen Datenfeldern auch wirklich ein Wert zugewiesen wurde Mu wert Pr fung au erdem werden die Werte bestimmter Felder auf Einmaligkeit 3 3 UMSETZUNG DES ENTWURFS IN DER IMPLEMENTIERUNG 39 Schl sselwert Pr fung und Einhaltung von Wertebereichen bzw andere Kriterien f r sinnvolle Werte gepr ft F r die Schl sselwert Pr fung ist jeweils eine Iteration ber alle Objek te derselben Art notwendig um das Schl sselattribut zu vergleichen Ist also K die Menge aller Kunden hat die berpr fung einer eingegebenen Kundennummer auf Einmaligkeit den Aufwand O K Eine eventuelle Konsistenzverletzung wird dem Programm durch Exceptions der Pr ffunktion mitgeteilt Zu diesem Zweck wurde eine Menge von hierarchisch voneinander abgeleiteten Exceptions definiert die f r die verschiedenen Arten von Verst en gegen die Konsistenzregeln stehen Dadurch kann dem Benutzer eine genaue R ckmeldung gegeben werden mit deren Hilfe er seine Eingabeda ten nochmals durchsehen und berichtigen kann Die Vererbungshierarchie der Exceptions mit einer gemeinsamen Wurzel in der Klasse KonsistenzException erm glicht die einfache Behandlung solcher Exceptions im Programm ohne nach jeder Eingabe zwischen diversen m glichen Konsistenzfehlern untersc
81. hrstool Ist die Verwendung des Verkehrstool nicht vorgesehen m ssen alle im Programm notwendigen Entfernungen und Fahrzeiten von Hand eingegeben werden Dazu wird dem Benutzer zur gegebenen Zeit ein Eingabedialog pr sentiert wo er die fehlenden Daten eintragen kann Achtung Da im Modus ohne Verkehrstool keine Stationen gepr ft werden k n nen werden diese zun chst als ungepr ft gekennzeichnet Bei einem Wechsel in den Modus mit Verkehrstool m ssen zun chst all diese Stationen vom Verkehrs tool berpr ft und gegebenenfalls vom Benutzer noch korrigiert werden Beim Umschalten in den Modus mit Verkehrstool mu daher mit einer l ngeren War tezeit gerechnet werden 7 10 10 Entfernungen korrigieren Erm glicht die manuelle Eingabe von Entfernungen und Fahrzeiten zwischen zwei Stationen Die hier eingegebenen Werte haben Vorrang vor denen des Ver kehrstools und k nnen somit benutzt werden um dessen Werte zu korrigieren 7 10 11 Maximale Fahrzeit Hier wird der Standardwert f r die Zeit erfa t die ein Kunde maximal im Fahr zeug verbringen darf Dieser Wert gilt f r alle Kunden f r die keine individuelle Grenze angegeben wurde Kapitel 8 Projektplanung 8 1 Planung f r das Projekt Transportoptimie rung Da die Seminare nur indirekt mit dem Projekt bzw dem Ziel der Erstellung eines lauff higen Softwaresystems in Verbindung zu bringen sind wurde diese Phase bei der Planung nicht ber cksichtigt Die urspr ngliche Z
82. ht dargestellt werden Eine Ann herung k nnte hier durch ein TeilzeitTa geProfil erreicht werden das f r Montag und Dienstag eine 5 5 Stunden lange Zeitspanne enth lt 12 KAPITEL 2 NACHTRAG ZUM ENTWURF 2 1 2 DienstplanErstellbar Das DienstplanErstellbar Interface dient als einheitliche Schnittstelle aller Ob jekte f r die ein Dienstplan erstellt werden kann Dies sind die Objekte Mitar beiter Fahrzeug und Kunde Mit dem Dienstplan f r Kunden kann der DRK Einsatzplaner schnell feststellen wann bei einem bestimmten Kunden Dienste verrichtet werden Um das DienstplanErstellbar Interface benutzen zu k nnen m ssen folgende Methoden implementiert werden Fahrt dienstplanFahrten Datumsspanne Liefert alle Fahrten f r das Objekt innerhalb der bergebenen Datumsspanne sortiert nach Datum zur ck String dienstplanName Liefert einen Namen bzw eine Bezeichnung f r das Objekt zur ck f r welches der Plan erstellt wird z B Mitarbeiterna me String dienstplanBezeichnung Gibt die berschrift zur ck die der Dienstplan haben soll 2 1 3 Zahler Interface Das Zahlerinterface legt eine einheitliche Schnittstelle f r alle Objekte fest die als Rechnungsempf nger in Frage kommen Dazu stehen folgende Methoden zur Verf gung String zahlerName Gibt den nicht notwendigerweise eindeutigen Namen des Zahlers zur ck BankVerbindung zahlerBankVerbindungen Gibt alle Bankverbindun gen des Zahlers zur c
83. ht m glich ist obwohl dies unter UNIX funktioniert Das n chste Problem war die nachtr gliche Adre erfassung in der Dienst wunschmaske Da zun chst keine Lieferadresse angegeben war erschien korrek terweise eine entsprechende Fehlermeldung Daraufhin wurde die Lieferadresse erg nzt Diese konnte vom Verkehrsmodul nicht angebunden werden weshalb ein entsprechender Hinweis kam der mit Abbrechen beendet werden sollte Lei der blieb daraufhin auch TROSS stehen und mu te von au en verlassen werden Nachdem der Dienstwunsch wegen obigem Fehler nochmals erfa t war soll te sichergestellt werden da er am Ende einer Essenstour erledigt wird Eine Reihenfolge kann jedoch erst bei Untertouren festgelegt werden die wie schon erw hnt nicht funktionierte Damit bleibt dieser Punkt ungepr ft Als Alterna tive wurde eine sp te Lieferzeit eingegeben die jedoch nichts garantiert Die Verquickung mit einem MSD Dienstwunsch ist aus konzeptionellen Gr n den nicht direkt m glich Dies mu bei der Tourplanung manuell ber cksichtigt werden wobei die beiden Dienstw nsche wegen der unterschiedlichen Dienstar ten nicht in einer Tour erledigt werden d rfen Eine andere M glichkeit w re 54 KAPITEL A TEST ein MSD Dienstwunsch mit der Bemerkung Essen mitnehmen oder ein EAR Dienstwunsch mit einer l ngeren Aufenthaltszeit Dies bringt aber Probleme f r die in dieser Version nicht realisierte automatische Abrechnung mit sich da sich
84. icht an einen Fremdkunden der Projektgruppe weitergegeben werden durften mu te auch das Verkehrstool selbst beschafft werden W hrend der zust ndi ge Projektgruppenteilnehmer noch Anbieter von Streckenplanungsprogrammen anschrieb um eine m glichst kostenlose berlassung der Daten zu Studien zwecken zu erbetteln war pl tzlich das Programm Map amp Guide schon gekauft zu einem Betrag den wir nie f r Hilfsmittel einzuplanen gewagt h tten Da das Programm eine externe Schnittstelle anbietet war die einzige Information die vor dessen Eintreffen an der Uni zur Verf gung stand Sp ter stellte sich dann heraus da die Batch Schnittstelle weder von der Geschwindigkeit noch vom m glichen Umfang der Anfragen f r die Anforderungen des Programms TROSS geeignet war 9 4 Empfehlungen an zuk nftige Projektgruppen Auch wenn es bisher in diesem Dokument wie auch schon im Zwischenbericht fast immer nur um die zu modellierende Aufgabenstellung und das daf r ge schriebene Programm ging sind das Hauptziel einer Projektgruppe die vielf l tigen Lerneffekte Um die diversen Erfahrungen dieser Projektgruppe die oft 9 4 EMPFEHLUNGEN AN ZUK NFTIGE PROJEKTGRUPPEN 97 genug durch m hsames Learning by doing erzielt wurden nicht nur f r uns zu behalten sollen hier einige Punkte genannt werden die k nftige Projektgrup pen unserer Meinung nach beachten sollten Dadurch kann hoffentlich bis zu einem gewissen Grad vermieden werden d
85. ile vorgegeben wird 7 9 2 Ausfallzeiten 7 9 2 1 Ausfallzeiten Mitarbeiter Zeigt die Anzahl der Tage die die Mitarbeiter f r einen gegebenen Zeitraum ausf llt 7 9 2 2 Ausfallzeiten Fahrzeuge Zeigt die Anzahl der Tage die die Fahrzeuge f r einen gegebenen Zeitraum ausf llt 7 10 EINSTELLUNGEN 85 7 9 3 Fahrzeugbesetzung Zeigt die Anzahl der Passagiere pro Fahrzeug im Verh ltnis zur maximalen Sitzplatzzahl im Fahrzeugtyp definiert 7 9 4 Auslastung Mitarbeiter drucken Druckt die Auslastungsgraphik f r alle Mitarbeiter mit automatischem Seite numbruch 7 9 5 Auslastung Fahrzeuge drucken Druckt die Auslastungsgraphik f r alle Fahrzeuge mit automatischem Seite numbruch 7 96 Ausfall Mitarbeiter drucken Druckt die Ausfallzeiten f r alle Mitarbeiter mit automatischem Seitenum bruch 7 9 7 Ausfall Fahrzeuge drucken Druckt die Ausfallzeiten f r alle Fahrzeuge mit automatischem Seitenumbruch 7 10 Einstellungen 7 10 1 Qualifikationen Alle Qualifikationen die Mitarbeitern zugewiesen werden sollen m ssen zuvor in dieser Liste definiert werden 7 10 1 1 Eingabedialog f r Qualifikationen Eine Qualifikation hat eine kurze Bezeichnung die im Programm als Identifi kation dient und z B in Listen angezeigt wird sowie eine ausf hrlichere Be schreibung Die Felder f r Verrechnungswerte beziehen sich auf eine nicht implementier te automatische Optimierung sind hier also bedeutungslos 7 1
86. implementiert und funktionierten dementsprechend noch nicht 4 1 4 4 Analyse Die Men punkte zur Anzeige der Mitarbeiterauslastung und zur Fahrzeugbeset zung zeigten die gew nschten Daten richtig an Die weiteren Analysefunktionen 4 1 FUNKTIONSTEST DES GESAMTPROGRAMMS 49 waren zum Testzeitpunkt noch nicht vollst ndig implementiert und konnten so mit nicht getestet werden Die Funktionen zum Drucken funktionieren mit der Solaris Version des JDK nicht X11MOTIF Exception 4 1 4 5 Einstellungen Die Masken zur Eingabe der einzelnen systemweit bekannten Daten funktio nierten zur vollen Zufriedenheit Auch falls die Daten in anderen Masken z B Fahrzeugeingabe ver ndert oder erg nzt werden Die Eingaben falscher Daten formate z B Eingabe von Buchstaben statt Zahlen werden von den Konsi stenztests sicher erkannt und erfolgreich abgewiesen 4 1 4 6 Allgemeine Systemprobleme Bei manchen Testl ufen kam es vor da das System ohne Fehlermeldung ab st rzte oder einfach h ngen blieb und dadurch von au en beendet werden mu te Da diese Fehler in unterschiedlichen Bediensituationen auftraten liegt die Ur sache wahrscheinlich in einer gewissen Instabilit t der Java Laufzeitumgebung 4 1 5 Probleme unter Windows und JDK1 1 5 e Die Eingabe des Zeichens ist nicht m glich e Der Warte Mauscursor wird erst nach einer Mausbewegung wieder in einen Aktiv Mauscursor ge ndert Spielt man nicht die ganze Zeit mit der Mau
87. indungspunkt ein die wiederum vom Verkehrstool gepr ft wird Konnte der Station auf diese Weise ein Anbindungspunkt zugeordnet wer den mu noch unterschieden werden ob es sich um eine benannte Station handelt Ist kein Name angegeben wird eine neue Station erzeugt und im Dienstwunsch gespeichert Wurde ein Name eingegeben wird diese Station dem Szenario gemel det Sollte ein Konflikt mit einer bereits bekannten Station auftreten wird der Benutzer dar ber informiert und kann seine Eingabe ndern Sonst wird eine neue benannte Station angelegt der Dienstwunsch speichert nur eine Referenz darauf 14 KAPITEL 2 NACHTRAG ZUM ENTWURF 2 2 2 Untertour Die Schnittstelle der Untertour hat sich nachtr glich ge ndert Einzelne nde rungen werden in den folgenden Abschnitten beschrieben e Attribute nummer String die Nummer der Untertour a zz bezeichnung String Eine frei vergebbare Bezeichnung f r die Unter tour Die Bezeichnungen der Untertouren einer Tour m ssen verschie den sein tour Tour ein Verweis auf die Tour teilWuensche Vector of TeilDienstwunsch Hier werden alle Teil dienstw nsche gespeichert die in dieser Untertour erf llt werden sol len anfangsStation Station Gibt eine Station an die immer als erste an gefahren werden mu z B die K che bei einer Essen Tour endStation Station Gibt eine Station an die unbedingt als letzte angefahren werden mu anfangsZeit
88. ionierte fand sich dann doch die L sung im Handbuch wenn das erste 44 KAPITEL 3 IMPLEMENTIERUNG Kommentarfeld der Auftragsdatei mit einem Doppelpunkt beginnt wird der Rest des Feldes als Stra e interpretiert Wer bitte kommt auf solche Ideen Als n chstes wurde die Vorschlagsliste cor untersucht die Map amp Guide im mer anlegt Anhand dieser kann eine neue eindeutige Auftragsdatei erstellt wer den Allerdings fehlten dabei stets die Hausnummern weshalb die gelieferten Stationen zum Teil nicht eindeutig sind Als erste L sung wurde die Hausnum mer aus der Anfrage einfach wieder an die Stra e angeh ngt Nach einer Dis kussion in einer Sitzung wurde diese Alternative verworfen da es kaum m glich ist den Stra ennamen algorithmisch von der Hausnummer zu trennen Deshalb wurde das Attribut Stra e in der Station aufgetrennt in zwei Attribute Stra e und Hausnummer Die n chste Eigenheit von Map amp Guide lie nicht lange auf sich warten die Postleitzahlen in der Vorschlagsliste waren zum Teil falsch 9xxxx f r Stationen in Stuttgart zum Teil aber auch gro e negative Zahlen Diese Vorschl ge in eine neue Auftragsdatei gepackt brachten wie erwartet keine sinnvollen Ergebnisse Aufgrund dieser Probleme mit der Vorschlagsliste werden die Vorschl ge nun nicht mehr zur Erzeugung neuer g ltiger Anbindungspunkte verwendet Statt dessen mu jeder m gliche Anbindungspunkt gepr ft werden Methode Verkehrsmodul anbindungInOrdnung
89. itarbeiter und Fahrzeug angepa t werden sowie Dienstw nsche entfernt und wieder eingef gt werden Das Erstellen von Dienstpl nen auf der Basis dieser Fahrten gelang ebenso wie das Archivieren von Fahrten in eine Log Datei Erf llung von Dienstw nschen pr fen Es wurden zwei Dienstw nsche berpr ft von denen einer teilweise in Touren und Untertouren enthal ten war Das Programm meldete korrekt alle Teildienstw nsche dieser Dienstw nsche die nicht in den bestehenden Untertouren erf llt wurden L schen von Dienstw nschen die in Touren enthalten sind Nach der Warnmeldung da der zu l schende Dienstwunsch noch in Touren steckt wurde die Option gew hlt diesen automatisch auch dort entfernen zu las sen Nach Eingabe einer Entfernung die in der Untertour durch Wegfall des Dienstwunsches ben tigt wurde war der Dienstwunsch sowohl aus der Wunschliste des Kunden als auch aus der Tour und Untertour gel scht in denen er zuvor noch referenziert worden war Drucken von Analysen und Pl nen Pl ne und Analysedaten k nnen jetzt auch ausgedruckt werden Analyselisten werden dabei in Seiten umbro chen von Dienstpl nen wird jeweils nur der Teil ausgedruckt der auf eine Seite pa t dies ist etwa eine Woche 4 2 Grenzen des Systems Test mit gro en Da tenmengen Um die Grenzen des Systems zu erkunden wurde ein Programm geschrieben das gro e Mengen zuf lliger Daten anlegt wobei verschiedene Parameter eingestellt werden
90. k 2 1 4 Druckbar F r den mehrseitigen Ausdruck ben tigt das druckbare Component einen Print job um den Seitenvorschub selbst vornehmen zu k nnen Wird das Interface Druckbar implementiert ist das implementierende Component f r den Aus druck v llig selbstverantwortlich d h es bekommt nur einen PrintJob und mu daraus nach Bedarf Graphics Objekte erzeugen und freigeben Insbesondere ist darauf zu achten da auch das letzte Graphics Objekt wieder mit dispose freigegeben wird Um das DienstplanErstellbar Interface benutzen zu k nnen mu folgende Methode implementiert werden void drucken PrintJob initiert den evtl mehrseitigen Ausdruck des imple mentierenden Components 2 2 Allgemeine Konzepte 2 2 1 Stationen und Anbindungspunkte Um Adressen f r Anfragen an das Verkehrstool benutzen zu k nnen hat jede Station eine Referenz auf einen Anbindungspunkt Dies ist eine Adresse im For 2 2 ALLGEMEINE KONZEPTE 13 mat des Verkehrstools die entweder mit der Adresse der Station bereinstimmt oder in deren N he liegt falls die Stationsadresse selbst im Verkehrstool nicht bekannt ist Da manche Adressen recht oft ben tigt werden z B Schulen zu denen eine gr ere Anzahl Kunden bef rdert werden soll wurde als Eingabehilfe das Kon zept der benannten Stationen entwickelt Jeder Station kann optional ein Name zugewiesen werden ber den dann sp ter ohne erneute Eingabe der gesamten Adresse auf diese Station zur
91. k nnen Die Daten werden in Szenarien gespeichert die dann von TROSS geladen werden k nnen Mit diesem Programm wurden zwei Szenarien erzeugt 1 Das erste Szenario enth lt je 50 Qualifikationen Essensarten Hilfsmittel und Fahrzeugtypen je 200 Fahrzeuge und Mitarbeiter 500 Kunden mit jeweils 0 bis 2 Dienstw nschen 10 Schulen 150 Schultouren mit 3 bis 6 Kindern und die Untertouren zu den Schultouren eine Hin und eine R ckfahrt 2 Im zweiten Szenario wurde die Zahl der Kunden auf 1000 erh ht die Zahl der Schulen auf 20 und die Zahl der Schultouren auf 300 Diese Szenarien wurden geladen und verschiedene Funktionen von TROSS auf gerufen um die Schwachstellen zu finden F r diese wurden dann Zeitmessungen durchgef hrt In Tabelle 4 1 werden die nacheinander aufgerufenen Funktionen und die ben tigten gestoppten Zeiten in Sekunden auf zwei Rechnern beide Windows 95 mit JDK 1 1 6 angegeben 4 2 GRENZEN DES SYSTEMS TEST MIT GROSSEN DATENMENGENS1 Cyrix 166 32MB P100 24MB Szenario 1 laden 319 Kunden anzeigen 12 speichern als Szenario 3 152 Szenario 3 laden 307 Kunden anzeigen 8 Szenario 2 laden 912 Kunden anzeigen 18 Touren anzeigen 5 Tabelle 4 1 Zeiten f r verschiedene Funktionen Das gro e Problem das Laden und Speichern der Daten In TROSS wird die Serialisation von Java verwendet wobei die Daten noch komprimiert wer den Auch das Abschalten der Komprimierung nderte kaum etwas Der Profiler ermi
92. liefert die Fahrzeit in Minuten zwischen den zwei durch ihre Position angegebenen Halten Dies ist die Diffe renz von Ankunftszeit bei nach und Abfahrtszeit bei von aufenthaltsDauer int Liefert die Aufenthaltszeit in Minuten an dem durch seine Position gegebenen Halt aendereAufenthaltsDauer int int ndert die Aufenthaltsdauer an dem angegebenen Halt um das als zweites Argument angegebene Del ta aendere AufenthaltsDauer Absolut int int Setzt die Aufenthalts dauer an dem angegebenen Halt auf die als zweites Argument an gegebene Dauer pruefeHalteReihenfolge Vector boolean Pr ft ob die Reihenfol ge der Stationen im Vector mit der von den Dienstw nschen der Untertour vorgesehenen Reihenfolge bereinstimmt korrigiereFahrzeiten Vector Setzt die Fahrzeiten zwischen den Hal ten im angegebenen Vector auf die vom Verkehrsmodul geliefer ten Werte An und Abfahrtszeiten werden entsprechend angepa t Klappt dies nicht weil z B Map amp Guide nicht l uft wird eineUn bekannteFahrzeitenException die die fehlenden Strecken enth lt ge worfen verschiebeHalt int int Verschiebt den Halt an der angegebenen Po sition erstes Argument an eine neue Position zweites Argument Alle Dienstw nsche an dem Halt werden mit verschoben Gibt es an der angegebenen Position schon einen Halt mit der gleichen Station werden die beiden Halte verschmolzen verschiebeDienstwunsch Dienstwunsch int int Verschiebt einen Dienstwunsc
93. lte berpr fen einer Menge von Dienstw nschen Der Be nutzer w hlt eine Menge von Dienstw nschen die mit den bestehenden Tou ren und Untertouren abgeglichen werden S mtliche Teildienstw nsche siehe 7 6 1 2 die nicht durch das aktive Tourszenario erf llt werden werden dem Benutzer gemeldet Daraus kann z B ganz gezielt erkannt werden da f r einen Dienstwunsch noch eine R ckfahrt am Freitag fehlt 76 Touren Zur Beschreibung der geplanten und tats chlich stattfindenden Fahrten auf denen die diversen Dienstw nsche der Kunden erf llt werden benutzt das Pro gramm TROSS folgende Bezeichnungen Tour Eine Tour besteht aus einer Menge von Dienstw nschen die nacheinan der von denselben Mitarbeitern mit demselben Fahrzeug erf llt werden Bei Fahrdiensten entspricht dies also einer Fahrgemeinschaft von Kun den Die Angabe von Mitarbeitern und Fahrzeug ist optional eine Tour beschreibt lediglich die Planung d h sie hat kein Datum sondern be schreibt ein regelm ig wiederkehrendes Ereignis 7 6 TOUREN 77 Untertour Jede Tour besteht aus einer Menge von Untertouren die diese wei ter konkretisieren Eine Untertour findet an gewissen Wochentagen mit einem gewissen Rhythmus statt und kann entweder eine Hinfahrt oder eine R ckfahrt der Kunden zu einem Ziel sein In der Untertour werden die verschiedenen anzufahrenden Stationen in eine Reihenfolge gebracht Auch die Untertouren beschreiben die Planung Fahrt Eine
94. lung notwendig die nach dem Prin zip der sogenannten Registerkarten erfolgte Eine Reihe von Buttons am oberen Rand des Fensters erm glicht das Um schalten zwischen verschiedenen Seiten mit thematisch zusammengeh rigen Eingabefeldern Die Gesamtheit all dieser Seiten ergibt den Eingabedialog die Eingabefelder aller Seiten erfassen das zugeh rige Datenobjekt in seiner Ge samtheit Diese Grundfunktionalit t wurde in der Klasse TRO GUI RegisterDialog verwirklicht so da alle komplexen Dialoge lediglich davon abgeleitet und in passende Seiten aufgeteilt werden mu ten 3 1 2 5 Erweiterbare Listen Bereits bei der Erstellung des Prototyps der graphischen Benutzungsoberfl che hatte sich gezeigt da das Programm TROSS eine Vielzahl von Listen verwaltet deren Elemente vom Benutzer beliebig ge ndert erweitert und ge l scht werden sollen Um dies sowohl m glichst einfach als auch universell zu unterst tzen wurde die Klasse TRO GUI ObjektListePanel geschaffen Diese 3 2 DESIGNENTSCHEIDUNGEN 27 pr sentiert sich auf dem Bildschirm als eine geordnete Liste von Objekten mit den drei Buttons Einf gen ndern und L schen Die jeweils individuelle Funktionalit t der Buttons wird vom aufrufenden Programmteil zur Verf gung gestellt indem sogenannte Listener Objekte definiert werden wie sie in Javas AWT an vielen Stellen zum Einsatz kommen um auf gewisse Ereignisse der Benutzungsoberfl che kontex
95. mplements java lang Cloneable java io Serializable o class TRO Station implements java io Serializable java lang Cloneable TRO ListenElement o class TRO StationMitZeiten implements java io Serializable java lang Cloneable TRO ListenElement class TRO UntertourHalt implements java io Serializable java lang Cloneable TRO ListenElement o class TRO Strecke o class TRO Verkehrsmodul Strecke implements java io Serializable 66 KAPITEL 5 ARCHITEKTUR DES PROGRAMMS TROSS class TRO Szenario implements java io Serializable class TRO TeilDienstwunsch implements java io Serializable TRO ListenElement class TRO Termin implements java io Serializable class java lang Throwable implements java io Serializable class java lang Exception class TRO GUI EingabeFormatException class TRO IstMasterSzenario class TRO UnbekannteFahrzeitenException class TRO Verkehrsmodul VerkehrstoolLaeuftNicht class TRO VerschiebungNichtErlaubtException class TRO Verkehrsmodul WertNichtBekanntException class TRO Tour implements java lang Cloneable java io Serializable TRO ListenElement class TRO TourSzenario implements java lang Cloneable java io Serializable TRO ListenElement class TRO Uhrzeit implements java io Serializable java lang Cloneable class TRO Untertour implements java lang Cloneable java io Serializable TRO ListenElement class TRO Verkehrsmodul Verkehrsmodul interface TRO Zahler extends TRO ListenElement cla
96. n 3 2 2 Destr kt ren vr sr 2 2 NEE NN RORO ER UA dadada d 3 3 Umsetzung des Entwurfs in der Implementierung 3 3 1 Personenklassen 3 32 D tenhalt ng t ern aa ea 233 Konsistenztests r rrr eames nn 3 3 4 Analysedaten 3 3 5 Datenausgabe aroi a irira TE nn 3 4 Probleme beim Umsetzen des Entwurfs 2 2 2 2 200 3 4 1 Unyollst ndige Details im Entwurf 2 2 2 3 4 2 Einfach aber aufwendig 3 5 Implementierung ausgehend von einem Prototyp 3 6 Verwendung externer Programme Das Verkehrsmodul 3 7 Erfahrungen mit Java 3 7 1 Javas Klassenbibliothek 222222 3 7 2 Entwicklungsumgebung 2 2 2 2 2 10 10 10 12 12 12 12 12 14 18 4 Test 47 4 1 Funktionstest des Gesamtprogramms 2 2 2 nn 47 41 1 Szenario 24 4 4 Bi ns BE Be ee E de Ei 47 4 1 2 Kunden und Dienstw nsche 2 2 2 2222 nn 48 4 1 3 Touren Untertouren und Fahrten 2 2 22 48 4 1 4 Test der Men punkte Ressourcen Ausgabe Analyse und Einstellungen ea ash a A e EN ae 48 4 1 5 Probleme unter Windows und JDK1 15 49 4 1 6 allgemeine Fehler 2 2 2 2 nn nn 49 4 1 7 Erg nzungen zum Test aooaa 49 4 2 Grenzen des Systems Test mit gro en Datenmengen 50 4 3 Abgleich mit den Anforderungen 52 5 Architektur des Programms TROSS 56 5 1 Architektur des System ROSS 56 5 2 Graphische Benutzungsoberfl che 2 22222 20 56 5 3 Verkehrsmodul 22
97. n k nnen ob der Mitarbeiter zur vorgesehenen Zeit berhaupt eingesetzt werden kann Dabei soll zum einen ber cksichtigt werden an welchen Tagen bzw zu welchen Zeiten ein Mitarbeiter prinzipiell im Dienst ist zum anderen gibt es nicht nur f r die w chentliche sondern auch f r die t gliche Arbeitszeit Grenzen so da nicht immer der bestpassende Mitarbeiter eingesetzt werden kann Im Gespr ch mit dem Benutzer am Ende der Entwurfsphase stellte sich daher die Notwendigkeit heraus die Mitarbeiter bez glich ihrer Arbeitszeit zu klassi fizieren Diesem Zweck dienen drei Arten von Arbeitszeitprofilen deren einzelne Parameter frei definierbar sind und somit unterschiedlichste Einsatzzeiten be schreiben k nnen Vollzeitkr fte Diese Mitarbeiter sind prinzipiell immer verf gbar eine w chentliche sowie eine maximale t gliche Arbeitszeit sind die Grenzen Dies sind Soll Vorgaben die im Einzelfall durch den Benutzer au er Kraft ge setzt werden k nnen Tageweise besch ftigte Teilzeitkr fte Solche Mitarbeiter arbeiten nur an manchen Wochentagen f r das DRK und oder nur zu gewissen Zeiten an diesen Tagen Teilzeitkr fte auf Stundenbasis Hierunter fallen Mitarbeiter die nach Stunden bezahlt werden und meist eine bestimmte Obergrenze nicht berschreiten d rfen sogenannte 620 Mark Jobs Auch hier mu auf eine Obergrenze f r die t gliche Arbeitszeit geachtet werden 10 2 1 NEUE KLASSEN UND INTERFACES 11
98. nat rlich nicht ohne ein ab schlie endes Fazit bleiben M glichkeiten zur Erweiterung des Programms wur den zusammengestellt m glicherweise als Anregung f r folgende Projektgrup pen dem theoretische Zeitplan wird der tats chliche Ablauf des Projekts gegen bergestellt und schlie lich fa t ein R ckblick einige gute und weniger gelungene Aspekte der Projektgruppe zusammen um daraus Empfehlungen f r kommende Projektgruppen oder ganz allgemein Programmierteams abzuleiten 1 2 Das Programm Eines der Ziele der Projektgruppe war die Erstellung eines Programms zur Ver waltung und Planung der sozialen Fahrdienste des DRK in Bad Cannstatt Wenn dieses Ziel auch etwas zu hoch gesteckt war was in diesem Bericht noch aus 1 2 DAS PROGRAMM 9 f hrlicher geschildert werden wird ist trotzdem ein Programm entstanden das die wichtigsten Funktionen zur Verwaltung und manuellen Organisation der Da ten des DRK zur Verf gung stellt ber eine graphische Benutzungsschnittstelle l t es sich komfortabel bedienen Das Programm tr gt den Namen TROSS was bereits eine gewisse Bedeu tung in sich tr gt vor allem jedoch als Abk rzung zu verstehen ist TRansport Organisation for Social Services oder auch Transport Organisation f r Soziale Serviceanbieter Kapitel 2 Nachtrag zum Entwurf 2 1 Neue Klassen und Interfaces 2 1 1 Arbeitszeitprofile Bei der Einteilung von Mitarbeitern f r Touren und Fahrten sollte berpr ft werde
99. ng mit Daten und Zeiten bemerkbar machten wurden eigene Klas sen f r Uhrzeit und Datum implementiert die im wesentlichen unabh ngig vom JDK arbeiten und nur f r einige komplexe Berechnungsfunktionen auf dessen M glichkeiten zur ckgreifen Ebenso lassen die von Java zur Verf gung gestell ten Datums und Zeitklassen eine Funktion zum berpr fen ob ein Datum bzw eine Uhrzeit sinnvoll eingegeben wurde vermissen Da die Implementierung ei ner solchen Pr ffunktion sich als sehr komplex herausgestellt hat und nur mit erheblichen Aufwand realisiert werden k nnte wurde im Hinblick auf die knap pe Zeit darauf verzichtet Auf falsche Eingaben eines Datums oder einer Uhrzeit wird nun mit der von Java vorgegebenen Methodik reagiert nach der die Ein gabe in eine sinnvolle berf hrt wird So wird z B auf die Eingabe 35 13 1998 nicht mit einer Fehlermeldung reagiert sondern diese stillschweigend von Java in das n chste sinnvolle in diesem Falle den 4 1 1999 berf hrt 3 1 2 GUI Erweiterungen Die graphische Benutzungsoberfl che wurde stark modular konzipiert um den Entwicklungsaufwand m glichst gering zu halten Alle mehrfach ben tigten berfl chenelemente wurden als eigene Klassen realisiert die dann zur allgemei nen Verwendung f r die restliche Benutzungsoberfl che zur Verf gung stehen Hier sind insbesondere zu nennen e einfache und zusammengesetzte Eingabefelder f r h ufig ben tigte Da tentypen Diese kon
100. nstelle der neuen Klasse SortierterVektor sie he 3 1 1 1 war im Feinentwurf noch die Klasse Vector vorgesehen Diese Klasse erlaubt die Objekte sortiert abzulegen und damit eine wesentlich effizientere Implementierung der h ufig ben tigten sortierten Ausgaben 3 3 2 2 Tourszenario e Attribute name String Schl ssel Name des Tourszenarios touren Vector Touren des Tourszenarios die wiederum auf die fahr tenreferenzierenden Untertouren verweisen e Methoden Fahrt objektFahrten Object Zeitraum Gibt alle Fahrten zur ck die das bergebene Objekt innerhalb des bergebenen Zeitraums zu erledigen hat Dazu werden alle Touren deren Untertouren und Fahr ten durchlaufen Damit liegt der Aufwand in O Anz d Fahrten Zus tzlich wurde das ListenElement Interface implementiert Welches Tourszenario aktiv Mastertourszenario ist wird abweichend vom Feinentwurf jetzt durch das zugeh rige Szenario verwaltet 3 3 3 Konsistenztests Die Konsistenztests wurden entsprechend dem Entwurf als automatische Pr fungen implementiert Nach der Eingabe von Daten wird die Einhaltung von Integrit tsbedingungen und Vorgaben durch das neu Eingegebene gepr ft Ver sto en die Daten gegen Integrit tsbedingungen mu die Eingabe wiederholt werden Vorgaben k nnen hingegen explizit au er Kraft gesetzt werden Um den berblick ber solche explizit akzeptierten Verst e gegen Vorgaben zu behal ten kann dieser Teil der Konsistenzpr
101. orieren Es w re sch n wenn auch Kunden Ausnahme Datumsspannen h tten um alle Dienstw nsche des Kunden auf einfache Weise zu suspendieren Bei der Untertourzusammenstellung w ren die Funktionen alle Hin bzw R ckfahrten w hlen l schen sehr hilfreich Die Unterst tzung des direkten Umsetzens Dienstwunsch in einer Tour w hlen und in eine andere Tour verschieben w re w nschenswert 67 68 KAPITEL 6 ERWEITERUNGSM GLICHKEITEN Bei Dienstw nschen k nnen nur Bezugspersonen angegeben werden die schon beim Kunden definiert wurden Es w re wesentlich einfacher auch hier die Neuanlage von Bezugspersonen zu erm glichen 6 3 Erweiterungsm glichkeiten Aufgrund der modularen Programmierweise k nnen einzelne Teile leicht erwei tert oder gar ganz ausgetauscht werden um leistungsf higeren Konzepten Platz zu machen Weitere Konsistenztests k nnen fast ohne nderungen am restlichen Pro gramm implementiert werden F r eine Zusammenarbeit mit einem anderen Verkehrstool als Map amp Guide vielleicht mit einem Programm das als Bibliothek vorliegt und direkt vom Programm aus ohne Umwege ber Batchdateien aufgerufen werden kann oder gar eine Online Abfrage ber ein geeignetes Netzwerk mu nur das Verkehrsmodul intern angepa t werden ber die definierten Schnittstellen kann die Datenverwaltung wie bisher damit kommunizieren Da Map amp Guide beim Einsatz im System TROSS doch einige Schw chen aufzeigt w r
102. rde das Zahlerinterface implementiert das es jeder Person erlaubt Rechnungsempf nger f r Dienstw nsche zu sein 3 3 1 10 Sachbearbeiter Unterklasse von Person die gegen ber dem Feinentwurf nicht ge ndert wurde e Attribute angestelltBei Institution Arbeitgeber des Sachbearbeiters beispiels weise Sozialamt oder Krankenkasse 3 3 1 11 Station e Attribute strasse String Stra en oder Platzname bzw Postfach hausNr String In diesem Attribut das im Feinentwurf noch nicht vor gesehen war wird die Hausnummer der Station gespeichert Die Tren nung vom Stra ennamen wurde wegen der einfacheren Anbindung an das Verkehrstool vorgenommen ort Ort Als Referenz zum Ort der Adresse Dies ersetzt die im Feinent wurf vorgesehene Postleitzahl anbindungspunkt AnbindungsPunkt Bezeichnung unter der die Station im Verkehrsmodul vermerkt ist i d R die Adresse oder ein Punkt der m glichst nahe an der Station liegt name String SCHL SSEL Name einer Station als Eingabehilfe f r den Anwender Konzept der benannten Station siehe 2 2 1 3 3 UMSETZUNG DES ENTWURFS IN DER IMPLEMENTIERUNG 33 e Methoden void entferneAnbindungsPunkt Veranla t die Entfernung des An bindungspunkts aus dem Verkehrsmodul boolean adressenGleich Station berpr ft ob diese Station mit der bergebenen in der Adresse bereinstimmt Dies ist der Fall wenn sowohl der Stra enname String equals als auch der Ort Ort gleich bereins
103. ren So wurden zun chst nahezu alle Module parallel begonnen und am Schlu fehlte die Zeit die Arbeit wirklich zu Ende zu f hren Ebenso wurde der Zeitaufwand f r die Reviews nach jeder Phase bei der Planung nicht extra eingeplant so da letztlich jede Phase um eine bis zwei Wochen in die n chste berhing w hrend derer das Review vorbereitet und durchgef hrt werden mu te Besonders realit tsfern war das Vorhaben die gesamten vorlesungsfreie Zeit zu verplanen Da in dieser Zeit mit Pr fungen zu rechnen war sollte jedem der selbst einmal studiert hat ebenso klar sein wie die Tatsache da intensive Pr fungsvorbereitung eine gewisse Zeit erfordert in der f r umfangreiche sonstige Aufgaben kein Platz ist weder zeitlich noch gedanklich Zeit f r Urlaub oder sonstige Erholung die in der freien Wirtschaft l ngst als grundlegend wichtig f r die Motivation und die Leistungsf higkeit der Mitarbeiter erkannt wurde wurde den Studenten der Projektgruppe im Zeitplan nicht zugestanden 95 96 KAPITEL 9 R CKBLICK 9 2 Umfang der Aufgabenstellung Mit einem echten Kunden konnte bisher noch keine Projektgruppe der Uni Stuttgart arbeiten so da zun chst eine gewisse Wie im richtigen Leben Euphorie vorhanden war Da allerdings eine detaillgetreue Modellierung der Realit t einen enormen Aufwand erfordert wurde schnell klar Bereits die halb wegs schematisch geordnete Erfassung und Dokumentation der Anforderungen zei
104. rializable TRO ListenElement o class TRO Fahrt implements java lang Cloneable java io Serializable TRO ListenElement o class TRO Fahrzeug implements java io Serializable TRO ListenElement o class TRO Fahrzeugkonfiguration implements java io Serializable TRO ListenElement o class TRO Fahrzeugtyp implements java io Serializable TRO ListenElement o class TRO Feiertag implements TRO ListenElement java io Serializable o class TRO GUI GUIHelfer o class TRO Helfer o class TRO Hilfsmittel implements TRO ListenElement java io Serializable o class TRO Institution implements java io Serializable TRO Zahler o class TRO KommunikationsVerbindung implements java io Serializable TRO ListenElement o class TRO KontaktPerson implements TRO ListenElement o interface TRO ListenElement extends TRO Comparable o class TRO Verkehrsmodul MoeglicherAnbindungsPunkt implements TRO ListenElement java io Serializable o class TRO Ort implements java io Serializable o class TRO Person implements java io Serializable TRO Zahler class TRO BezugsPerson implements TRO ListenElement class TRO Sachbearbeiter class TRO Kunde implements TRO ListenElement java io Serializable class TRO Mitarbeiter implements TRO ListenElement java io Serializable o class TRO Qualifikation implements java io Serializable TRO ListenElement o class TRO Rhythmus implements java io Serializable TRO ListenElement o class TRO SortierterVektor i
105. rn scheint jedoch Probleme zu machen oder kam nicht immer der Hinweis Szenario ge ndert Speichern Jedenfalls waren nicht immer alle Daten da die zuvor eingegeben wurden Al lerdings konnte dieser Fehler bisher nicht reproduziert werden Auch beim Test der Funktionen des Untermen s TourSzenario gab es Pro bleme wechseln zeigte keine Wirkung kopieren schl gt fehl da die vom System automatisch aufgerufene Methode korrigiereFahrzeiten zu einer Exception f hrte zum Master machen Funktioniert auf den ersten Blick allerdings sieht man auf der Konsole da das unbekannte Kommando tourszena rio_fahrten_ schreiben aufgerufen wird Die brigen Men punkte zeigten bei mehrmaligen Aufrufen und auch bei zwi schenzeitlichem Verlassen des Programms die gew nschte Wirkung 47 48 KAPITEL 4 TEST 4 1 2 Kunden und Dienstw nsche Abgesehen von den in Kapitel 4 3 genannten Fehlern fiel nichts mehr auf Der Men punkt Dienstw nsche erf llt d rfte den Planer nur f r kurze Zeit erfreu en es werden angeblich immer alle W nsche erf llt 4 1 3 Touren Untertouren und Fahrten Die Probleme die sich hinter dem Men punkt Tourenliste verbergen werden im Detail in 4 3 beschreiben Insbesondere lie en sich keine Untertouren bilden Damit war auch ein Test aller Men punkte Dialoge die sich auf Untertouren oder Fahrten beziehen nicht m glich Der Konsistenztest entdeckte fehlende Mitarbeiter und Qualifikationen Eben
106. rplan abgedurckt werden sollen dies k nnte z B der Hausarzt von anfallsgef hrdeten Kunden sein Ort und Zeit Erfa t einen oder mehrere Orte je nach Dienstart sowie den Termin des Dienstwunsches Ein Termin enth lt einen Zeitraum sowie eine Menge von Rhythmen Der Zeitraum gibt den Datumsbereich an innerhalb dessen der Dienst ausgef hrt werden soll Angegeben werden kann ein Rahmen z B ein Schuljahr sowie eine Menge von Ausnahmezeiten z B Ferien w hrend derer der Dienst nicht erw nscht ist Ist der Rahmen leer hat dies die Bedeutung Immer Ein Rhythmus gibt an wie oft und regelm ig ein Dienst stattfinden soll Die gew nschten Wochentage k nnen bestimmt werden ebenso ob der Dienst nur an Werktagen stattfinden soll also ausf llt falls der angege bene Wochentag ein Feiertag ist Ist das K stchen Nachricht an Feierta gen angekreuzt erscheint beim Laden des Szenarios eine Warnmeldung falls der Dienst wegen eines Feiertages ausfallen w rde Dadurch kann der Dienst in der kritischen Woche rechtzeitig vorher auf einen anderen Tag verlegt werden F r seltener stattfindende Dienste kann angegeben wer den alle wieviel Wochen die Ausf hrung erw nscht ist Au erdem enth lt ein Rhythmus die Uhrzeit zu der ein Dienst an den angegebenen Tagen stattfinden soll Die hierf r ben tigten Angaben sind von der Dienstart abh ngig und werden in Zusammenhang mit den dienst spezifischen Anforderungen erl utert
107. rzeuge 7 7 1 Mitarbeiter Zeigt eine nderbare Liste aller Mitarbeiter an 7 7 1 1 Eingabedialog f r Mitarbeiter Neben den allgemeinen Personendaten siehe 7 5 1 1 hat jeder Mitarbeiter ei ne Personalnummer die ihn eindeutig kennzeichnet Diese kann aus beliebigen Zeichen bestehen ist also nicht nur auf Ziffern beschr nkt Ein Dienstantrittsdatum sowie ein Entlassungsdatum kann hier erfa t werden was insbesondere bei Zivildienstleistenden eine wichtige Information f r die Einsatzplanung ist Durch Auswahl eines Arbeitszeitprofils siehe 7 10 2 wird festgelegt zu welchen Zeiten bzw wie lang ein Mitarbeiter im Dienst ist Diese Information wird zur Darstellung der Mitarbeiterauslastung ben tigt Die Verf gbarkeit eines Mitarbeiters wird durch einen Zeitrahmen z B das laufende Kalenderjahr oder den Rest der Dienstzeit sowie durch Ausnahmezei ten gekennzeichnet z B Krankheit Urlaub oder Schulung Werden bekannte Ausnahmezeiten rechtzeitig vorher hier eingetragen z B Urlaub wird dies bei der Konsistenz berpr fung beachtet und gegebenenfalls gewarnt falls ein mo mentan nicht verf gbarer Mitarbeiter f r Fahrten eingeteilt ist Aus den definierten Qualifikationen siehe 7 10 1 k nnen durch Auswahl in der Liste diejenigen bestimmt werden die der Mitarbeiter besitzt Diese Infor mation ist wichtig um die F higkeiten von Mitarbeitern mit den Anforderungen der Kunden in ihren Dienstw nschen abgleichen zu k nnen
108. s kann man lange warten bis eine Aktion beendet ist e Zeitrahmen werden immer um einen Tag nach vorne geschoben 4 1 6 allgemeine Fehler e Bilden von Untertouren nicht m glich e Es ist nicht m glich einen Dienstwunsch zu l schen der von Touren refe renziert wird Es erscheint zwar die Frage Dienstwunsch aus allen Touren entfernen eine Antwort mit ok wird jedoch nur durch eine Exception quittiert 4 1 7 Erg nzungen zum Test Tourszenarien Tourszenarien k nnen jetzt kopiert werden zwischen verschie denen Tourszenarien eines Szenarios kann gewechselt werden und das je weils aktive Tourszenario kann zum Master Tourszenario gemacht werden notwendige Bedingung f r das Schreiben von Fahrten Untertouren erstellen Untertouren konnten erstellt werden und mit Teil dienstw nschen best ckt werden Das Verschieben einzelner Teildienst w nsche klappte ebenso wie das Verschieben von Halten wobei die Pr fung aufrichtige Reihenfolge der Stationen korrekt arbeitete Daim Modus ohne Verkehrstool getestet wurde wurden unbekannte Entfernungen bzw Fahrzeiten angezeigt und konnten vom Benutzer eingegeben werden 50 KAPITEL 4 TEST Fahrten erzeugen Zu den erzeugten Untertouren wurden Fahrten erzeugt Dabei wurden die Zeitr ume der Dienstw nsche beachtet und gegebenen falls keine neuen Fahrten erzeugt Die neu erzeugten Fahrten wurden dem Benutzer zur berpr fung und m glichen Bearbeitung pr sentiert Hier konnten M
109. shPanel HashListener class 5 4 KLASSENHIERARCHIE 63 TRO GUI Ressourcen FahrzeugDialog implements TRO GUI HashPanel HashListener class TRO GUI Dienste IndividualfahrtDialog class TRO GUI Kunden KundeDialog class TRO GUI Dienste MSDDialog class TRO GUI Ressourcen MitarbeiterDialog class TRO GUI Dienste SchulfahrtDialog class TRO GUI Dienste RhythmusDialog class TRO GUI Kunden SachbearbeiterDialog class TRO GUI Dienste StationZeitDialog class TRO GUI TeilDienstwunschWahlDialog class TRO GUI TeilListeWahlDialog class TRO GUI TextEingabeDialog class TRO GUI Touren TourDialog implements TRO GUI ObjektListePanel ElementListener class TRO GUI UhrzeitDialog class TRO GUI Touren UntertourDialog class TRO GUI Definitionen VerkehrstoolDialog class TRO GUI ZahlEingabeDialog class TRO GUI ZeitdauerDialog class TRO GUI OKDialog class TRO GUI Definitionen ArbeitszeitProfileDialog implements TRO GUI ObjektListePanel ElementListener class TRO GUI Definitionen BenannteStationenDialog implements TRO GUI ObjektListePanel ElementListener class TRO GUI Definitionen EssensartenDialog implements TRO GUI ObjektListePanel ElementListener TRO GUI ObjektListePanel InformationListener class 64 KAPITEL 5 ARCHITEKTUR DES PROGRAMMS TROSS class java awt TRO GUI Touren FahrtenListeDialog class TRO GUI Definitionen FahrzeugtypenDialog implements TRO GUI ObjektList
110. ss TRO Zeit implements java io Serializable class TRO Aufenthaltszeit implements java io Serializable class TRO Lieferzeit class TRO Transportzeit class TRO Zeitraum implements java io Serializable class TRO Zeitspanne implements java io Serializable TRO ListenElement Kapitel 6 Erweiterungsm glichkeiten 6 1 6 2 M gliche Verbesserungen am Programm Bei der Kundeneingabe erscheint bei den dienstbezogenen Daten kein Kundenname es w re jedoch hilfreich zu wissen welcher Kunde gerade bearbeitet wird Bei der Dienstwunscheingabe wird zwar ein Kundenna me angezeigt dieser ist jedoch bei Kundenneuanlage null null Bei der Tourplanung erh lt der Benutzer keinen Hinweis wenn Mitarbei ter oder Fahrzeuge mehrfach verplant werden obwohl das System diese Informationen schon hat Die Dialogbox Dienstart w hlen kann nicht abgebrochen werden Vermi t wurde eine globale Zeitgrenze f r Essenstouren die in der Regel zwischen 10 45 und 12 30 erledigt werden m ssen Hilfestellungen f r den Benutzer Die Einf hrung benannter Rhythmen k nnte die Eingabe von h ufig auf tretenden Rhythmen z B Schulfahrten erheblich vereinfachen An allen Stellen an denen aus globalen Listen z B Hilfsmittel ausge w hlt werden kann sollte auch eine Modifizierung der Liste m glich sein Wird eine R ckfahrzeit angegeben sollte das R ckfahrt Flag automatisch gesetzt werden anstatt die eingegebenen R ckfahrtzeiten zu ign
111. sstellten Auf jeden Fall mu te hier der fehlende Ent wurfsschritt nachgeholt werden was teilweise nicht im ersten Versuch gelang 42 KAPITEL 3 IMPLEMENTIERUNG Als Beispiel soll hier die Speicherung von Essensarten und deren Anzahlen im EARDienstwunsch erl utert werden Der Entwurf l t mit der Formulierung Essensart x int die genaue Umsetzung offen Ein erster Versuch bei der Implementierung benutzte zus tzliche interne Klas sen zur Speicherung von Essensarten und Anzahl Es stellte sich aber heraus da diese schlecht zu handhaben sind eigene Lese und Setzmethoden sowie Verwaltung der Liste mit Eintragen L schen und Suchen w ren n tig Also mu te eine andere L sung gesucht werden Die Speicherung der Anzahlen in einer Hashtabelle mit Essensarten als Schl ssel leistet dies auf elegante Weise ist allerdings nicht ganz trivial in ein gut bedienbares Oberfl chenelement zur Eingabe umzusetzen siehe 3 4 2 1 3 4 2 Einfach aber aufwendig Manche Datenstrukturen lassen sich umgangssprachlich und auch in der Pro grammiersprache leicht ausdr cken sind aber semantisch recht komplex so da ihre Eingabe nicht einfach zu modellieren ist 3 4 2 1 Hashtabellen Ein Beispiel daf r sind Hashtabellen die einer Menge von Schl sselobjekten je einen Eintrag zuordnen Da weder unter den g ngigen Fenstersystemen noch unter Java Eingabem glichkeiten f r in der Gr e nicht von vornherein festge legte zweidimensionale
112. t Uhrzeit endZeit Uhrzeit 18 KAPITEL 2 NACHTRAG ZUM ENTWURF wuensche Vector ein Vector mit den tats chlich erf llten Dienstw n schen fahrzeug Fahrzeug ersterMitarbeiter Mitarbeiter zweiterMitarbeiter Mitarbeiter In der Log Datei wird f r jeden Halt und jeden dort bedienten Dienstwunsch eine Zeile mit folgenden Inhalten angelegt Das Datum z B 24 12 1997 Die Nummer der Untertour z B 2b Die Kurzbezeichnung der Dienstart der Tour und damit aller ihrer Dienst w nsche z B Schule Die Bezeichnung des Fahrzeugs z B 123 Der erste Mitarbeiter z B Zivi Zacharias 12 Der zweite Mitarbeiter z B Uhrzeit der Ankunft z B 16 23 Die Adresse z B Die Strasse 12 70123 Stuttgart Der Kunde z B Sparwasser Emma 11 Bei einem Essensdienstwunsch die Anzahl der bestellten Essen je Essensart z B 2 Di t Die Bemerkung vom Tourplan Die einzelnen Eintr ge sind durch Tabulatoren getrennt einige Eintr ge wer den durch Hochkommata vor dem Auftrennen gesch tzt 2 2 3 Verkehrsmodul An der Schnittstelle zum Verkehrsmodul gab es nderungen die zu folgendem Aufbau f hrten Attribute anbindungsPunkte Hashtable in dieser Hashtabelle werden die Anbindungspunkte gespeichert Schl ssel sind die Map amp Guide Stationen die Daten sind AnbindungsPunkte entfernungen EntfernungsTabelle MapAndGuidePfad String der Pfad zu mg exe MapAndGuideAuftragsVerzeichnis String Das
113. t Damit ersetzt bank das im Feinentwurf vorgesehene Attribut BLZ kontoNr String Die Kontonummer ohne die im Feinentwurf gemachte Einschr nkung auf zehn Ziffern einzug boolean Ist true wenn eine Einzugserm chtigung vorliegt Vor einstellung true Zus tzlich wurde das Interface Listenelement implementiert 3 3 1 3 Bezugsperson Unterklasse von Person e Attribute bezugsArt String Gibt die Art des Bezuges zum Kunden an Z B Familienverh ltnis Arzt etc bemerkung String Dieses Attribut wird jetzt aus der Oberklasse Per son geerbt Zus tzlich wurde das Interface Listenelement implementiert 3 3 1 4 Institution e Attribute name String Name des Institus z B Krankenkasse X Sozialamt Y Versicherung Z adressen Vector In diesem Attribut das gegen ber dem Feinentwurf erg nzt wurde werden alle Adressen einer Institution vermerkt 30 KAPITEL 3 IMPLEMENTIERUNG bankVerbindungen Vector In diesem Attribut das gegen ber dem Feinentwurf erg nzt wurde werden alle Bankverbindungen einer In stitution vermerkt kommunikationsVerbindungen Vector In diesem Attribut das ge gen ber dem Feinentwurf erg nzt wurde werden alle Kommunikati onsverbindungen einer Institution vermerkt Zus tzliche wurden die Interfaces Listenelement und Zahler implementiert Durch das Zahlerinterface kann eine Institution als Rechnungsempf nger bei den Dienstw nschen der Kunden eingetragen werden 3
114. tarbeiter erkennen welcher Dienst wann erledigt werden soll 7 8 2 Dienstplan Datengrundlage f r Dienstpl ne sind die Fahrten eines Zeitraum den der Benut zer vorgibt Dadurch werden einzelne nderungen an Fahrten z B kurzzeitiger Austausch eines Mitarbeiters wegen Krankheit in die Pl ne bernommen Der Plan zeigt eine graphische bersicht ber den gew nschten Zeitraum Darin werden alle Fahrten die der gew hlte Mitarbeiter ausf hren soll als Bal ken dargestellt 7 8 3 Gesamtdienstplan 7 8 4 Angezeigten Plan drucken Gibt den gerade im Hauptfenster angezeigten Plan auf den Drucker aus 7 8 5 Untermenu Pl ne drucken 7 8 5 1 Dienstpl ne Druckt eine Menge von Dienstpl nen ohne diese einzeln auf dem Bildschirm an zuzeigen Der Benutzer kann eine beliebige Teilmenge aller Mitarbeiter angeben f r die die Pl ne gedruckt werden sollen 84 KAPITEL 7 BEDIENUNGSANLEITUNG EI Ree S L I ARR FA Ss O u m li ah ma Amel nme Ta o mdai mann le Drerisiglar Tur Aego Love 307 Wi Zeg sei Mi E i A Ce Abbildung 7 4 Beispiel f r einen Tourplan 7 8 5 2 Tourpl ne Druckt eine Menge von Tourpl nen ohne diese einzeln anzuzeigen Der Benutzer w hlt die Touren aus 7 9 Analyse Alle Analysedaten basieren auf den Plandaten also Touren und Untertouren 7 9 1 Auslastung Mitarbeiter Zeigt die Zeit die die Mitarbeiter auf Touren besch ftigt sind im Verh ltnis zur Sollarbeitszeit die durch die Arbeitsprof
115. te Speicherplatz auf der Festplatte h lt sich dank der Kompression in Grenzen Tabelle 4 2 zeigt die Dateigr en in Bytes verschiedener Szenarien Weshalb das Szenario 3 kleiner ist als Szenario 1 ist nicht erkl rbar Die Szenarien in den letzten drei Zeilen enthalten jeweils noch die Fahrten der Schultouren f r 1 2 bzw 3 Wochen Pro Fahrt werden etwa 17905 17187 220 3 2 Bytes ben tigt Dank der Kompression gibt es hier also keine Engp sse 52 KAPITEL 4 TEST Gr ke in Bytes Szenario 1 134 472 Szenario 2 254 954 Szenario 3 134 423 Szenario 4 16 292 Szenario 4 1 Woche 17 187 Szenario 4 2 Wochen 17 513 Szenario 4 3 Wochen 17 905 Tabelle 4 2 Gr en verschiedener Szenarien 4 3 Abgleich mit den Anforderungen Durchspie len der Szenarien Ein Teil der Testphase bestand darin die Daten aus den Szenarien der Anforde rungsanalyse mit TROSS zu verarbeiten Im folgenden soll dargestellt werden welche Teile mit TROSS verarbeitet werden konnten welche sich aufgrund von Fehlern nicht verarbeiten lie en und welche aus konzeptionellen Gr nden nicht mit TROSS verarbeitet werden konnten 4 3 0 1 Schulfahrten Szenario 1 Die Qualifikationen Lastenheben und Epilepsie Umgang wur den neu angelegt Daraufhin wurden die Zivildienstleistenden Gustav H berle und Karl Tremmle gem den Vorgaben des Szenarios erfa t Danach wurden die vier vorgegebenen Kunden erfa t und zu einer Tour zusammengestellt
116. tenztests erfolgen nderungen an anderen Programmteilen sind bis auf eventuelle kleine Ver nderungen der Aufrufschnittstelle nicht n tig 3 3 4 Analysedaten Aus der F lle der in der Spezifikation geplanten Analysedaten wurden im Ge spr ch mit dem Kunden diejenigen ausgew hlt die f r den Kunden wichtig und interessant sind e Auslastung der Mitarbeiter e Ressourcenbindung Fahrzeugauslastung e Anzahl km und Zeit pro Dienstart 40 KAPITEL 3 IMPLEMENTIERUNG e Ausfallzeiten der Mitarbeiter und der Fahrzeuge 3 3 4 1 Darstellung F r die grafische Darstellung der Auslastungen wurde eine generische Klasse entworfen die f r jeden Mitarbeiter bzw jedes Fahrzeug nach einer textuellen Beschreibung des Mitarbeiters Name und Mitarbeiternummer bzw des Fahr zeugs Fahrzeugnummer einen Balken darstellt dessen L nge dem prozentua len Verh ltnis der Auslastung des Mitarbeiters bzw des Fahrzeuges entspricht Den Balken werden dabei zwei Farben zugewiesen Solange die Auslastung unter 100 bleibt ist der Balken gr n steigt die Auslastung jedoch ber 100 wird der Balken in roter Farbe dargestellt Die bergabe der Analysedaten an die Klasse zur grafischen Darstellung TRO Analyse ProzentGrafik erfolgt mittels einer eigens daf r entworfenen Record Klasse TRO Analyse ProzentRecord Die Darstellung der anderen Analysedaten Zeit und km Aufwand bzw Aus fallzeiten erfolgt in tabellarischer Form Dem Benutzer bietet sich au
117. tere Anpassungsm glichkeit best nde beim Einsatz der generi schen Containerbibliothek JGL Java Generic Library die M glichkei ten zur Listenbehandlung Sortierung u bietet Kapitel 7 Bedienungsanleitung Der Aufbau dieser Bedienungsanleitung entspricht der Anordnung der Menu punkte im Programm TROSS so da sie vor allem zum schnellen Nachschlagen bei Unklarheiten im Umgang mit dem Programm geeignet ist Trotzdem sollte jeder Benutzer vor der Arbeit mit dem Programm TROSS alle Punkte durchgehen um die Konzepte und Arbeitsweisen zu verstehen die z B eine gewisse Reihenfolge mancher Bedienungsschritte erfordern 7 1 Systemvoraussetzungen Das Programm ben tigt eine Rechnerplattform auf der Java l uft entwickelt und getestet wurde es unter Sun Solaris 2 3 sowie Microsoft Windows NT 4 0 Soll das Verkehrstool Map amp Gruide benutzt werden siehe 7 10 9 ist Microsoft Windows als Betriebssystem notwendig 7 2 Installation Das Programm besteht aus drei Dateien Tross jar Diese Datei enth lt alle ausf hrbare Teile des Programms TROSS Tross gif Das Titelbild Tross ini Hier werden die globalen Einstellungen des Programms gespeichert z B die Einstellungen zum Verkehrstool Diese Dateien m ssen in ein Verzeichnis auf der Festplatte kopiert werden Im folgenden nehmen wir an da die Programmdateien im Verzeichnis tross liegen und das Java Development Kit unter java zu finden ist auf einem PC unter MS Windows
118. timmen void finalize Sorgt daf r da eine unreferenzierte Station durch den Garbage Collector aus dem Verkehrsmodul abgemeldet wird be vor sie aus dem Speicher entfernt wird Um garantiert alle unrefe renzierten Stationen aus dem Verkehrsmodul abzumelden mu der Garbage Collector vor dem Speichern explizit aufgerufen werden Zus tzliche wurde das Interface Listenelement implementiert 3 3 1 12 Qualifikation e Attribute bezeichnung String Schl ssel Eindeutiger Kurz Bezeichner f r die Qualifikation beschreibung String N here Beschreibung der Qualifikation verrechnungsWert int Kostenfaktor der bei der Optimierung be r cksichtigt wird falls diese Qualifikation erf llt jedoch nicht gefor dert wird Dieser Wert wird automatisch berechnet falls autoWert true ist und sich Mitarbeiterdaten bzgl der Qualifikation ndern Im Feinentwurf war noch der Typ byte vorgesehen autoWert boolean Ist autoWert false findet keine automatische Be rechnung des Verrechnungswertes mehr statt Wird der Verrech nungswert manuell ge ndert wird autoWert auf false gesetzt Zus tzlich wurde das Interface Listenelement implementiert 3 3 2 Datenhaltung Die Daten werden mit der in Java vorgesehenen M glichkeit der Objekt Seriali sation in eine Datei geschrieben Dazu werden die Objekte von Szenarien ver waltet Wie in Abbildung 3 1 zu sehen lassen sich folgende zwei Szenarioarten unterscheiden 1 Tourszenarien
119. tspezifisch reagieren zu k nnen 3 1 2 6 Eingabe von Hashtabellen Hashtabellen werden an verschiedenen Stellen im Projekt TROSS eingesetzt unter anderem zur Speicherung der gew nschten Mengen verschiedener Essens arten Da es unter den Standardeingabeelementen die unter Java zur Verf gung stehen keine Tabellen gibt sondern nur eindimensionale Listen mu ten die Hashtabellen bzw Tabellen aller Art zur Eingabe in ihre einzelnen Dimen sionen zerlegt werden Eine Liste zeigt alle Essensarten an bei Auswahl einer Essenart wird die zugeh rige Anzahl angezeigt und kann ge ndert werden Un erl lich f r die sinnvolle Bedienung war es hier auf Anfrage eine bersichtsliste anzuzeigen die wenigstens in der Ausgabe alle in der Hashtabelle zugeordneten Objekte tabellenartig anzeigt 3 2 Designentscheidungen 3 2 1 Fensteraufbau Da der Aufbau eines Fensters unter Java relativ viel Zeit in Anspruch nimmt weil jedesmal die Anordnung aller Elemente berechnet werden mu wurde die M glichkeit diskutiert einmal ge ffnete Fenster nur auf dem Bildschirm un sichtbar zu machen und f r weitere Verwendungen zu speichern Dies h tte zwar einen Vorteil in der Laufzeit gebracht wurde aber aus zwei Gr nden verworfen 1 Das Umschreiben aller Dialoge w re mit erheblichem Aufwand verbunden den die zeitliche Situation der Projektgruppe nicht erlaubt 2 Die meisten Dialoge bekommen die zu bearbeitenden Objekte im Kon struktor bergeb
120. tszeitprofilen definierten Obergrenzen da dies zum einen nicht ganz einfach zu implementieren ist und zum anderen f r die zersplitterte Arbeitszeit verteilung der Zivis beim DRK nur wenig Aussagekraft besitzt 3 3 3 3 Vorgehensweise Die berpr fung auf Konsistenz der eingegebene Daten erfolgt an zwei Stellen der Eingabe 1 Beim L schen von Objekten wird die Referenzintegrit t gepr ft Es d r fen nur solche Objekte gel scht werden die von keinem anderen Objekt referenziert werden Dazu mu z B f r Qualifikationen jeder Mitarbeiter gepr ft werden ob diesem die Qualifikation zugeordnet ist sowie jeder Dienstwunsch ob die ser die Qualifikation fordert Ist also M die Menge der Mitarbeiter und DW die Menge der Dienstw nsche des Kunden k hat die Pr fung ob eine Qualifikation gel scht werden darf den Aufwand O M 3 pex IDWr OPT Dieser einmalige gro e Aufwand lie e sich in mehrere kleinere Teile auf trennen indem jede Qualifikation R ckw rtsreferenzen auf alle Mitarbei ter und Dienstw nsche mitf hrt die die Qualifikation referenzieren Da durch verlagerten sich allerdings Aufgaben der Konsistenzpr fung in die Datenobjekte wodurch auch das abgespeicherte Szenario stark w chse Da das L schen von Objekten durch den Benutzer keine zeitkritische Aufgabe darstellt und auch bei einigen hundert Kunden mit insgesamt einigen tau send Dienstw nschen noch in akzeptabler Zeit durchzuf hren sein sollte wurde
121. ttelt f r das Laden des kleinen Szenarios die folgenden Top Rechenzeit Verbraucher 59 4 ObjectInputStream inputClassFields Object Class int 20 9 System ge 11 2 Object wait long Alle drei Methoden kommen von Java Die erste Methode ist nicht dokumen tiert dem Namen nach liest sie die Attribute der Objekte Die zweite ist der Garbage Collector und die dritte dient zur Synchronisation paralleler Zugriffe Eine Laufzeit Optimierung ist hier also nicht m glich am einfachsten k nnen die 21 f r den Garbage Collector durch mehr Speicher verringert werden Die brigen gestoppten Zeiten w ren auf dem Cyrix Prozessor gerade noch hinnehmbar das Laden und Speichern mittels Objekt Serialisation ist aber nicht akzeptabel kann aber wegen Zeitmangels nicht mehr ge ndert werden F r die folgenden Versuche wurde ein viertes Szenario mit vom zuk nftigen Benutzer von TROSS gelieferten Daten erstellt Dieses enth lt 46 Fahrzeuge 63 Mitarbeiter 94 Kunden mit Dienstw nschen Essen auf R dern und Schulfahr ten und 11 Schultouren Bei ausgeschaltenem Verkehrstool wurden die Dienstw nsche angelegt Da nach wurde das Verkehrstool eingeschaltet F r das Anbinden der 95 Statio nen 94 und eine Schule wurden 95 Sekunden ben tigt Danach wurden f r alle 11 Schultouren die Entfernungen zwischen den einzelnen Stationen ermit telt Das dauerte 160 Sekunden Hier wurden etwa 160 11 15 Sekunden pro Map amp Guide Auftrag Der ben tig
122. turverzeichnis Bal96 BN97 CAS97 Fla97 Pre92 Pro98 BALZERT HELMUT Lehrbuch der Softwaretechnik Band 1 Software Entwicklung Spektrum Verlag 1996 BERNSTEIN PHILIP A und ERIC NEWCOMER Principles of transac tion processing The Morgan Kaufmann series in data management systems Morgan Kaufmann San Francisco Calif 1997 XXTV 358 S CAS SOFTWARE GMBH Map amp Guide Benutzerhandbuch 1997 FLANAGAN DAVID Java in a Nutshell O Reilly Zweite Auflage Mai 1997 PRESSMAN ROGER S Software engineering a practitioner s ap proach McGraw Hill international editions computer science series McGraw Hill New York u a Dritte Auflage 1992 793 S PROJEKTGRUPPE TRANSPORTOPTIMIERUNG Zwischenbericht Be richt 1998 06 Institut f r Informatik der Universit t Stuttgart 1998 98
123. unkt zu beginnen Denkbar ist eine Vorgehensweise parallel zum Design des Datenmodells Zu den bereits spezifizierten Datenobjekten k nnen Eingabemasken entworfen werden die dann einerseits zur Veranschaulichung des Planungsstandes im Dialog mit dem Anwender dienen zum anderen aber eine Basis f r die endg ltige Imple mentierung bieten da sicher viele Teile bernommen werden k nnen 3 6 Verwendung externer Programme Das Ver kehrsmodul Als wesentliches Problem bei der Implementierung des Verkehrsmoduls hat sich die Batch Schnittstelle von Map amp Guide herausgestellt die f r eine solche Ver wendung zumindest mit der vorhandenen sp rlichen Dokumentation eigentlich nicht geeignet ist Sie ist daf r ausgelegt da die Benutzer ihre Anfragen in einer Auftragsdatei asc an Map amp Guide geben und dieses eine Tourbeschreibung in einer Ergebnisdatei lst speichert oder die Tour textuell oder graphisch auf einem Drucker ausgibt Aus der Tourbeschreibung kann zwar prinzipiell die Entfernung zwischen den Stationen herausgelesen werden aber daf r mu es in dieser Preislage eigentlich besser geeignete M glichkeiten geben Zun chst war die Frage wie eine Station f r Map amp Guide aussehen mu Des halb wurden einige Beispiele entsprechend dem Handbuch eingegeben Als erstes Problem stellte sich die bergabe von Stra ennamen heraus die nicht zu funk tionieren schien Nachdem die Antwort des Supports von Map amp Guide nicht funkt
124. ution ber einen Sachbearbeiter entschieden der eine Bezugsperson ist und von dieser Klasse erbt Mehrfachvererbung h tte es auch erm glicht dem in 3 1 1 1 erw hnten Inter face Comparable eine Standard Implementierung der Vergleichsmethode mitzu geben In Java mu te der etwas aufwendige Stringvergleich nach l nderspezifi schen Sortierregeln vielfach redundant codiert werden 3 7 1 1 Das Abstract Window Toolkit AWT Auch im package java awt zur Erstellung der graphischen Benutzungsoberfl che wurden einige vielverwendete Klassen schmerzlich vermisst Zum Beispiel mu te ein LayoutManager der die simple Aufgabe erf llt Oberf chenelemen te untereinander in einem Dialog anzuordnen komplett selbst implementiert werden Besonders deutlich bemerkbar macht sich die fehlende Unterst tzung typisier ter Eingabefelder sowohl beim Setzen als auch beim Auslesen von Werten Das JDK bietet nur reine Textfelder als fertige Oberfl chenelemente an Um andere Datentypen als Strings zu erfassen mu sich der Programmierer um die Kon vertierung der Gr e in einen String genauso k mmern wie um das Umsetzen 46 KAPITEL 3 IMPLEMENTIERUNG der eingegebenen Zeichenkette in das gew nschte Datum Vor allem letzteres ist mit einem gewissen Aufwand verbunden da diverse Exceptions behandelt werden m ssen Selbst f r elementare Datentypen wie ganze Zahlen int mu der Umweg ber Textfelder von Hand programmiert werden 3 7 2 Entwicklungsumg
125. verschiedenen Zeiten an verschiedenen Wochentagen sein kann wurde f r die Untertour der Begriff des Teildienstwunsches eingef hrt Ein Teildienstwunsch ist ein Dienstwunsch eingeschr nkt auf einen Wochentag und entweder Hin oder R ckfahrt Dem nach besteht jeder Dienstwunsch aus einem oder mehreren Teildienstw nschen Genauso wie eine Tour aus verschiedenen Dienstw nschen besteht beinhaltet eine Untertour eine Menge von Teildienstw nschen Um eine neue Untertour zu definieren k nnen deshalb zun chst Teildienst w nsche gew hlt werden die die Untertour erf llen soll Die Untertour wird durch einen alphanumerischen Zusatz zur Tournummer gekennzeichnet Diese Untertournummer kann Werte von a bis z und aa bis zz annehmen f r neu erstellte Untertouren wird jeweils ein passender Wert vorgeschlagen Zur leichteren Unterscheidbarkeit kann jeder Untertour eine Bezeichnung gegeben werden Dienstart Mitarbeiter und Fahrzeug der Tour werden zur Information hier nochmals angezeigt Der wesentliche Teil der Untertour besteht in den diversen Stationen die bei ihrer Ausf hrung angefahren werden sollen Dies sind neben den Stationen an denen Kunden abgeholt beliefert oder anderweitig bedient werden eine unab h ngige Anfangs und Endstation mit zugeh rigen Zeitangaben Die Untertour beginnt an der Anfangsstation zur angegebenen Zeit dies kann die Einsatz zentrale sein oder auch die Endstation einer unmittelbar
126. vertieren selbst ndig zwischen den Datenobjekten und den in Javas Textfeldern ein und ausgegebenen Strings und k nnen dabei gleich Typ und Wertebereichspr fungen vornehmen Analog zu den Datenklassen setzen sich die zugeh rigen Eingabefelder aus anderen Eingabefeldern niedrigerer Komplexit t zusammen ganze Zahlen Datum Uhrzeit Datumsspanne Zeitspanne Stationen Personendaten die wiederum nur einen Teil der Daten eines Kunden oder Mitarbeiters ausmachen etc e Dialogr mpfe f r die wichtigsten Grundfunktionen Zuweisen von Tastendr cken an Buttons und andere Bedienelemente TastaturDialog Eingabedialoge die mit OK best tigt oder mit Abbruch abgebro chen werden k nnen 0OKCancelDialog Umfangreiche Eingabemasken die nach dem Vorbild von Register karten zwischen verschiedenen thematisch zusammengefa ten Ein gaberegionen umschalten k nnen RegisterDialog 3 1 ENTWURFSENTSCHEIDUNGEN AUF PROGRAMMIERSPRACHENEBENE25 3 1 2 1 Typisierte Eingabefelder Da Javas Klassenbibliothek keinerlei Unterst tzung f r typisierte Eingabefelder bietet wurden f r das Projekt TROSS zus tzliche Eingabefelder f r die Datenty pen Integer und Datum geschaffen die die Konvertierung in Strings selbst ndig vornehmen Aus diesen elementaren Eingabefeldern wurden komplexere zusam mengestellt um z B Zeitr ume einzugeben die als fertige Module wie einfache Textfelder in die Oberfl
127. vorausgegangenen Untertour und endet an der Endstation zur angegebenen Zeit Anfangs und 7 6 TOUREN 79 Endzeit werden automatisch angepa t falls sie im Widerspruch zu den Zeiten der Stationenliste stehen Diese Stationenliste enth lt alle Untertourhalte die aufgrund der in der Un tertour enthaltenen Teil Dienstw nsche angefahren werden sollen Ein Unter tourhalt enth lt neben der Station an der der Halt stattfindet die Ankunfts und Wiederabfahrtszeit Da vor allem bei Schulfahrten die Dienstw nsche vieler Kunden dasselbe Ziel haben das aber nur einmal in der Liste auftauchen soll sind jedem Halt auch die Dienstw nsche zugeordnet die diese Station fordern Die Liste mit den Untertourhalten l t sich mit den rechts daneben angeord neten Buttons auf vielf ltige Weise ver ndern die Operationen auf und ab beziehen sich hierbei immer auf den ausgew hlten Halt Dienstwunsch Auf Verschiebt einen in einem Untertourhalt enthaltenen Dienstwunsch eine Position nach oben Dadurch entsteht ein neuer Halt mit diesem einen Dienstwunsch an der zugeh rigen Station Dienstwunsch Ab Verschiebt einen Dienstwunsch aus dem gew hlten Halt auf dieselbe Art nach unten Halt Auf Verschiebt einen Halt mit allen enthaltenen Dienstw nschen eine Position nach oben Halt Ab Verschiebt einen Halt mit allen enthaltenen Dienstw nschen eine Po sition nach unten Fahrzeit ndern ndert die Fahrzeit zwischen der Station des ge
128. w hlten Hal tes und der des vorausgehenden Ist der erste Halt in der Liste gew hlt kann die dortige Ankunftszeit gesetzt werden Aufenthaltszeit ndern ndert die Aufenthaltszeit an einem Halt Standard m ig entspricht die Aufenthaltszeit der im Dienstwunsch geforderten z B Einsteigezeit der Kunden die dort abgeholt werden so da Kor rekturen zun chst einmal dort gemacht werden sollten Trotzdem kann es im Einzelfall sinnvoll sein hier die gesamte Aufenthaltszeit explizit anzu geben Dienstwunsch komplett entfernen Entfernt einen Dienstwunsch mit allen Teildienstw nschen aus der Untertour Dadurch k nnen auch einzelne Hal te verschwinden Teildienstwunsch einf gen F gt einen weiteren Teildienstwunsch zur Unter tour hinzu und h ngt die neuen Halte an die Liste an Teildienstwunsch entfernen Entfernt einen Teildienstwunsch und gegebe nenfalls die zugeh rigen Halte aus der Liste Verschieben von Dienstw nschen und Halten in der Liste ist nur dann m g lich wenn die Reihenfolge der Stationen innerhalb der einzelnen Dienstw nsche gewahrt bleibt Da es z B wenig Sinn hat den Zielort einer Dialysefahrt zu erreichen bevor man alle zu transportierenden Kunden abgeholt hat wird in einem solchen Fall mit einer Warnmeldung das Verschieben verweigert Nach nderungen an einer Untertour werden alle zugeh rigen Fahrten ge l scht deren Datum in der Zukunft liegt ltere die also bereits erfolgt sind 80 KAPITEL
129. wenn sie eine entsprechende Methode besitzen ListenElement Elemente die in einer selbstsortierenden Liste von der gra phischen Benutzungsoberfl che dargestellt werden sollen implementieren zus tzlich zum Interface Comparable die Methode listenText die eine textuelle Darstellung des Objekts f r die Liste liefert Im Laufe der Implementierung stellte sich heraus da es die Performance von Java nicht zul t umfangreichere Listen vor jedem Anzeigen neu zu sortieren Deswegen wurden umfangreiche dynamischen Arrays der Klasse Szenario von der Klasse java util Vector auf eine eigene Klasse TRO SortierterVektor umgestellt Mit den oben beschrieben Interfaces konnte eine automatische Sor tierung durch bin res Einf gen leicht erfolgen und durch die Anpassung der Schnittstelle des selbstsortierenden Arrays an die von java util Vector waren in den Datenklassen praktisch keine zus tzlichen Ver nderungen erforderlich 3 1 1 2 Datum und Zeit Die Verwaltung von Kalenderdaten und Uhrzeiten wurde zwischen den Java Versionen JDK 1 0 und JDK 1 1 erheblich ver ndert In der aktuellen Klas senbibliothek existiert eine Klasse die beide Funktionalit ten vereinen soll Da 23 24 KAPITEL 3 IMPLEMENTIERUNG die Konzepte dieser Datums und Zeitverwaltung der Projektgruppe zum einen nicht gut durchdacht und daher schlecht handhabbar erschienen zum anderen die vorliegende Version des JDK noch offensichtliche Fehler enthielt die sich beim Umga
130. wurde getan Ausprogrammierung des Enturfs aufgrund des gro en Zeitaufwandes fiel die Optimierung weg Vorf hrung einer Version 0 Review ber Teile 20 7 1998 22 5 1998 vollst ndige Abgabe Version 1 13 8 1998 bergabe an den Kunden 21 9 1998 Test Beginn 9 7 1998 1 6 1998 was wurde getan Test erfolgte ber eine unvollst ndige Implementierung Funktionalit tstest der einzelnen Masken 8 1 PLANUNG F R DAS PROJEKT TRANSPORTOPTIMIERUNG 93 Test des Laufzeitverhaltens Abgleich mit den Szenarien Review 23 7 1998 26 6 1998 e Endbericht Beginn 2 7 1998 29 6 1998 was wurde getan Zusammenstellung bisher erstellter Dokumente korrekturlesen Abgabe Rohfassung 18 8 1998 Dokument fertig 5 10 1998 15 7 1998 8 1 4 Tats chlicher Zeit und Kostenaufwand Zum Abschliessen des Projektes wurde als Stichtag der Abgabetag des End berichtes 18 08 98 genommen Gegen ber dem geplanten Aufwand von 33 5 Wochen steht ein tats chlicher Aufwand von 39 Wochen Dieser Rahmen konnte aber nur eingehalten werden da vor allem in der Schlu phase der Projektgruppe vieles parallel bearbeitet wurde Den Arbeitsaufwand pro Pro jektgruppenmitglied l t zeigt Abbildung 8 1 Somit ergibt sich ein Gesamtauf wand f r das Projekt von 2186 Stunden bzw ungef hr 292 Tagen Werden die unter 8 1 1 angesetzten fiktiven Kosten von 150 DM pro Mitarbeiterstun de angesetzt ergeben sich folgend
131. zugeordneten An bindungspunkt beim Verkehrsmodul abzumelden damit dieses seine internen Tabellen so klein wie m glich halten kann Ein selbstverwaltetes Abmelden aller gel schten Stationen im Programm w re mit immensem Aufwand verbunden und sehr fehleranf llig Au erdem wider spr che ein solches Vorgehen dem grunds tzlichen Speicherkonzept der Sprache Java das oben erl utert wurde Leider l t Javas Dokumentation gewisse Zweifel an der Vollst ndigkeit und Korrektheit der Speicherverwaltung offen Der Aufruf des Garbage collectors ist mit folgendem Kommentar versehen Runs the garbage collector Calling this method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse When control returns from the method call the Java Virtual Machine has made its best effort to recycle all unused objects Die Projektgruppe entschied sich dennoch mit den finalize Methoden zu ar beiten M gliche Fehlfunktion des Java Laufzeitsystems sollten nicht zu unn ti gem Programmieraufwand der Anwendung f hren F r die korrekte Arbeitswei se des Programms TROSS gilt also die Annahme da Javas Garbage collector alle nicht mehr referenzierten Objekte erkennt und deren finalize Methode auf ruft 3 3 Umsetzung des Entwurfs in der Implementie rung 3 3 1 Personenklassen In den folgenden Abschnitten werden die Implementierung und Abweichung

Dokument 1

Contents

Download Pdf Manuals

Related Search

Related Contents