Abschlußpräsentation Studienprojekt 2 im AF Verkehr Marc Bufé Projekt PBV2K Abschlußpräsentation Studienprojekt 2 im AF Verkehr Marc Bufé

Überblick Produkt Projekt und einzelne Phasen Vorgehensweise und Probleme Auslieferung Fragen Vorführung Zuerst Produkt vorstellen, das bisher bestehende System und die angedachten und nun von uns umgesetzten Erweiterungen

Produkt VPROG (Teil von WUMS) bestehendes Verkehrsprognoseprogramm Erweiterung um P+R / P+M WUMS umfasst ausserdem weitere Programmteile (groesseres Produkt., mehr auf WebSite www.architektur.uni-stuttgart.de/wums) Vorgabe/Ziel des Projekts war es, das bestehende WUMS - Modell um Park & Ride sowie Park & Meet Funktionalitäten inkl. aller zugehörigen Dokumente in einem qualitativ hochwertigen Prozess zu erweitern. Das bestehende Prognosemodell VPROG umfasst alle Bereiche der Verkehrsprognose, d.h. Erzeugung, Verteilung, Aufteilung und Umlegung, berücksichtigt aber nicht die Aspekte von Park & Ride (P&R) und Park & Meet (P&M) und vor allem, dass mehrere Fahrzeuge für einen Weg (Fahrtzweck) benutzt werden können. Quelle -> Ziel , bisher nur 1 VM von Q nach Z ohne Umsteigen und dass dies jetzt abgespalten wird... WUMS ist ein Verkehrsprognoseprogramm zur Berechnung von Verkehrserzeugung, Verkehrsverteilung, Verkehrsaufteilung und Verkehrsumlegung für ein gegebenes Gebiet. Als Verkehrsmittel werden bisher der öffentliche Verkehr (ÖV) und der Individualverkehr (IV) in die Berechnung mit einbezogen. Im Rahmen des Studienprojektes sollen P+R und P&M als neue Verkehrsmittel in die Berechnung aufgenommen werden. Das System soll die neuen Verkehrsmittel auf Wunsch bei der Berechnung berücksichtigen. Die alte Methode soll auch weiterhin zur Verfügung stehen.

Produkt Vorher: IV Z Q ÖV Z Q Vorher nur 2 Verkehrsmittel pro Fahrtzweck bzw. Wegekette berücksichtigt. Startzelle zu Zielzelle... Q Z

Produkt Nachher: Park+Ride Z Q IV ÖV P P = P+R Parkplatz P+R symbolisiert durch den Weg Q – P – Z Immer noch Weg Startzelle – Zielzelle, aber mit Umsteigen und Nutzen zweier Verkehrsmittel P

Produkt Nachher: Park+Meet Z Q1 IV IV P Q2 IV P+M: hier erfolgen von mehreren Quellzellen Fahrten zu einem P+M Parkplatz, um dann mit einem einzigen Auto zur Zielzelle weiterzufahren Mehrere Startzellen, nach Absprache fahren mehrere zu Treffpunkt PM, und dann mit einem Kfz weiter. P Q2 IV

Produkt Programmiersprache C++ Objektorientierte Programmierung Bedingt durch Wartungsprojekt Objektorientierte Programmierung Natürliche Abbildung der realen Welt Datenkapselung OOP Paradigma für die Programmierung, wozu: prinzipiell Ziel die Welt möglichst natürlich abzubilden, Abstraktionsebene Objekte, Vererbungsbeziehungen. Progr.sprache: vorgegeben gewesen, bietet OOP (im Unterschied zu C), eine der weitverbreitesten Sprachen.

WUMS Soll-Zustand: Verkehrsprognose für IV/ÖV, mit P+R / P+M Im Vorfeld: Datenerhebung zu P+R / P+M (Preise, Stellplätze, Ort) Zuweisen der P+R Parkplätze zu Verkehrszellen Daten grossteils nicht bekannt Was fuer Daten erhoben: 1. Parkplaetze,Preise,Anzahl Stellplaetze, Ort, (nicht ueberall bekannt: Preise, zu PM gabs keine Daten -> fuer PM nur Strukturen, aber keine Daten (= PR i.A. bei uns) 2. Zuteilung zu Verkehrszellen (Karte,Datenbank) Zentrales Ziel dieses Projekts ist es, das bestehende Programm so zu erweitern, dass bei der Verkehrsaufteilung auch die Möglichkeiten von P&R und P&M berücksichtigt werden.

WUMS Soll-Zustand: Anpassung der bestehenden Daten Erweiterung des Modells um P+R sowie P+M Ermittlung von Umsteigewiderständen Ermittlung Widerstände und Routen für P+R und P+M Anpassung der Widerstandsattraktivitäten Ergänzung der Verkehrsaufteilungsmatrix Anpassung: Ändern der Berechnungsgrundlagen Erweiterung: Berücksichtigung wie... Formeln für 4 letzte Punkte Ermittlung Umsteige: Formeln Widerstandattraktivitäten: Widerstaende: 3 beste Routen, und warum... Ergänzung: neue Spalten dazu gekommen, Fzw Arbeit/Wohnen, warum neue Spalten

Vorgehen Standard-Phasenmodell Iteratives Wasserfallmodell, Meilensteine Risiko Analyse Spezifikation Entwurf Prozessmodell Standard-Phasen-Modell ... Fehler sollten möglichst früh korrigiert werden (Anforderungen), da sie sonst immer teurer werden! Der Eigentliche weg ist topdown (dicker hervorheben), zur not bottomup Was wird in einzelnen Phasen gemacht? Datengrundlagen sammeln, dann Spezifikation schreiben (implementierungsunabhängig), Systementwurf, Architekturentwurf, Grobentwurf, Implementierung, (Test ist noch am Laufen) Am Ende jeder Phase steht der Meilenstein, davor wird ggf. ein Review (quasi eine Kontrolle) durchgeführt. Spezifikation und Entwurf wurden vorgeführt... Implementierung Test Zeit

Projekt und einzelne Phasen Entstandene Dokumente Begriffslexikon Spezifikation Entwurf Quellcode Abschlußbericht folgt Welche Dokumente sind entstanden, welchem Zweck dienen diese? z.b. Semantik einzelner Begriffe klären, verschiedene Sichten aus Kunden- und Programmierersicht (führt zu Begriffslexikon) Spezifikation legt Anforderungen fest, Entwurf Ganz wichtig: Der Source Code ist auch Dokument, Software schliesst zudem auch jede Dokumentation ein (Software umfasst alles) -> Abschlussbericht kommt noch, dadurch dass Projekt noch nicht abgeschlossen ist

Projekt und einzelne Phasen Projektumgebung IDE MS Visual C++ Office WinCVS (CM) Together (CASE) (MS Pool Fak. Inf.) Projektumgebung: IDE (Programmierumgebung, Editor, Debugger etc.) ist MS Visual C++ , Office (für externe Doku) interne findet im Code statt CVS (weiß jeder was das ist? ;) zur Versionierung) Configuration Management (Manager = Micha) – ermoeglicht verteiltes Arbeiten Together (für den Entwurf) , CASE (unterstützt einzelne Phasen, mit Automatisierung, Code-Vorgeneriung von stubs (stubs = „Leere“ Klassen, quasi Geruest, compilierbar, beinhalten aber keine Funktionalitaet, zum Testen) -> Code noch zu schreiben, quasi auszuformulieren Ort MSPool der Fak Inf (wegen Infrastruktur, mehr Rechner, schneller)

Einhalten der Meilensteine? Zeitplan Analyse Spezifik. Entwurf Implem. Okt Nov Dez Jan Feb Mär Apr Mai Jun Jul Aug Sep Ausgesprochen gut für das Produkt, dass fast alle Meilensteine bis auf letzten erreicht wurde! Vorgesehen fuer die erste BETA-Version war Ende Juni/Anfang Juli. Worauf zurückzuführen? Verzögerungen eingetreten wegen Unvorhergesehenes! Angebotsabgabe 07. Dezember 2000 Meilenstein Spezifikation 08. März 2001 Meilenstein Entwurfs 03. Mai 2001 Auslieferung 1.Version 31. Mai 2001 Abnahme durch Kunden 23. Juli 2001 Gründe ... Im Zeitplan folgen auf nächster Folie Verzögerung

Verzögerungen Gründe Parallel Unvorhergesehenes Studienprojekt IBIS / SPE Hauptseminare Fachstudien Jobs Unvorhergesehenes

Probleme mit ReEngineering Probleme mit Implementierung: Transparenz des vorhandenen Codes Erheblicher Zeitaufwand für Reengineering Entwurf unvollständig Vorgabe: Bestehenden Code i.A. nicht ändern! Schwierig den Code zu lesen, undokumentiert (ist aber normal), Nachvollziehbarkeit was wie programmiert wurde (Was ist Reengineering ;) ? ) Entwurf unvollstaendig, da wir von Sachen ausgingen die es so nicht gab. Methoden fehlten. Matrixzugriff, viele Dinge mussten nochmals geschrieben worden, um den bestehenden Code nicht aendern zu muessen Get und Set-Methoden fehlten, Vorstellungen der Programmierer deckte sich nicht mit unserem Weltbild Mit den Probs die nach dem Entwurf bei der Implementierung anfielen haben wir nicht gerechnet, und mussten zum Entwurf zurückgehen (wie gesagt ist diese Möglichkeit im Phasenmodell vorgesehen) Loesungen: Entwurf anpassen. Es musste neuer Code geschrieben werden, der so nicht eingeplant war Vorgabe war den alten Code weitestgehend nicht zu ändern, an manchen Stellen natürlich erlaubt ;)

Umsetzung / Vorgehensweise Laden Daten P+R und P+M Berechnung von Erzeugung Widerstände Widerstandsattraktivitätsquotienten Fahrten Speichern Daten P+R und P+M Berücksichtigung beim Split Grober Ablauf: Das System lädt die zur Berechnung notwendigen Dateien. Dazu gehören die PRDatenbank.prd und PMDatenbank.pmd. Dann werden die Widerstände mit den im Kapitel 6.2 beschriebenen Formeln berechnet. Die Widerstände können alternativ auch aus einer Datei (z.B. Widerstände.res) geladen werden, wenn sie bereits früher einmal berechnet wurden. Die neuen Widerstände für P+R und P&M werden dann bei der Verteilung der Fahrten von einer Zelle zu einer anderen berücksichtigt. Die Ergebnisse der Verteilung werden in einer Datei gespeichert (z.B. verteilt.vd). Berechnungsumfang variabel einstellbar, sofern die zu berechnenden Daten in einem vorherigen Lauf bereits berechnet worden sind, und dann einfach eingelesen werden! SCREENSHOT hier von EIGENSCHAFTEN, am Schluss den Vortrags ein Programmlauf

Screenshot

Klassen CPark Einlesen Parkplatzdaten Berechnen und Speichern Basis-Widerstände CResistance Einlesen Basis-Widerstände Berechnen und Speichern Widerstände mit IV/ÖV CWAQ Einlesen Widerstände Berechnen und Speichern WAQ Csplit Berechnen ModalSplit anhand CWAQ Bei Interesse Weitere Details hierzu informelles Treffen möglich

Auslieferung Umfang der Auslieferung: Einweisung Erste Kalibrierung Source Code Dokumentation Handbuch Abschlussbericht Einweisung Erste Kalibrierung Einweisung in die Bedienung! Eichung muss noch vorgenommen werden! (allerdings nur eine grobe) – wenn fertig getestet

Zum Schluß ein besonderes IV Unvorhergesehene Zwischenfälle Unvorhergesehener Zwischenfall: Projektmanager hatte Moppedunfall mit SR-500 ... Problem: Erstmal 8 Tage ausgefallen, niemand wusste was zu tun ist ;) gewissermassen fiel die Koordination flach Ausfall durch Rehabilitationsmassnahmen, dadurch Projektverlauf ins Stocken geraten

Fragen ? Wenn Sie noch Fragen haben, können Sie jetzt loslegen ;)

RESERVE-FOLIEN ! Wenn Sie noch Fragen haben, können Sie jetzt loslegen ;)

Probleme der Phasen Probleme mit OO-Test: - Zustandsbetrachtung - Testautomatisierung fehlte - Seiteneffekte nicht ausschließbar - OOP und modale Programmierung gemischt Test oo: (teletubbies) (http://w3studi.informatik.uni-stuttgart.de/~badstoms/hase/) Ursprungsentwurf für den zu Grunde liegenden Source Code nicht vorhanden Testautomatisierung fehlte, d.h. jeder Testlauf benötigte viel Zeit Seiteneffekte sollten ausgeschlossen werden (aber: Abhängigkeiten zw. Klassen sind nicht sichtbar) Urspruenglicher Code nicht alles objektorientiert, sondern mit modaler Programmierung gemischt