Website
=======
- ODEMx-Homepage auf Sourceforge einrichten und mit Inhalt fuellen
Grund: ODEMx-Zitierbarkeit in Papers

Tutorials und Doku
==================

- fuer typische Simulationsaufgaben
- fuer kompliziertere Komponenten
- Ueberarbeitung der existierenden Beispiele
- Makefiles sollten dokumentiert / kommentiert werden
Grund: Nutzung vieler Komponenten ist nicht am API abzulesen,
Doku ist zu knapp, Code-Beispiele sind zu alt oder nicht vorhanden

Coding Guidelines, Formatierung
===============================

- bessere Trennung von Interface und Implementierung
- viele Funktionen direkt im Header implementiert
- viele Header werden zu frueh eingebunden
- manche Dateien enthalten mehr/andere Klassen, als ihr Name sagt
- Module sollten eigene Namespaces haben (Doku der ns in odemx.h)
- wenn möglich auf Referenzkonzepte umstellen, um die Semantik von
  Funktionen klarer zu machen
Grund: bessere Wartbarkeit, weniger Suchen im Code/Dateien,
einfacher zu erweitern, Möglichkeit der Nutzung gleicher Komponenten mit
verschiedener Implementierung. (Mit z.B. verschiedenen Modellierungstiefen)

Bessere XHTML/XML-Nutzung
=========================

- XML-Schema fuer XmlTrace, XmlReport
- Ueberarbeitung des HtmlTrace fuer XHTML-Konformitaet
- hinzufuegen eines XmlWriters als sauberes Backend fuer alle Klassen
Grund: Implementierung ist sehr unlesbar, schlecht zu warten

Datenerfassung
==============

- Trace koennte bei einigen Klassen mehr Informationen enthalten
  (Protokoll, Synchronisationselemente)
- Report-Statistik ueberpruefen, ob mehr Daten zu gewinnen sind
- Observer ist unsicher, weil beobachtete Aktionen nicht atomar sind
  -> kann bei Stackwechseln zu unerwartetem Verhalten fuehren
  -> Observer kann Scope-gebunden implementiert werden
  -> Signal erst nach Beenden einer internen Aktion
  -> evtl. 2 Observer-calls - einer zu Begin einer Aktion und einer am Ende
Grund: detailreichere Traces, mehr Aufschluss ueber Simulationsinterna,
sichere Nutzung (man sollte Interna nicht kennen muessen, um Features zu nutzen)

Nutzung anderer Bibliotheken
============================

- Untersuchung der Nutzung von TR1
  -> Container
  -> verschiedene Zufallszahlengeneratoren / -verteilungen
- Zugriff auf Dateisystem waere nutzlich fuer Display-Modul
  -> stylesheets, javascript, XSLT
- Strukturierung von Simulationsausgaben in Verzeichnissen
- Unterstuetzung fuer XML-Verarbeitung
- Observer koennte mittels Signalbibliothek umgesetzt werden
Grund: Verwendung bewaehrter Implementationen mit wenig Eigenaufwand

Koroutinen und Scheduler
========================

- Untersuchung alternativer Koroutinen-Implementationen auf Vorteile
  -> insbesondere Boost.Coroutine (nicht Teil der Boost-Distribution)
- Entwicklung eines neuen Schedulers
  -> Vereinfachung der Klasse Simulation wenn moeglich
  -> Verteilen ihrer Aufgaben auf mehrere Klassen
  -> sicheres Scheduling, Prozessaktivierung (Stackwechsel) ohne Seiteneffekte
- genauere Dokumentation noetig
Grund: sehr alte Codebasis, schwer verstaendlich, kaum wartbar oder erweiterbar

Build-System
============

- Abhaengigkeiten fuer alle Quelldateien generieren
- kann von g++ selbst mit -M... erzeugt werden
Grund: Header-Aenderungen fuehren nicht zur korrekten Uebersetzung abhaengiger
Quelldateien, macht Erweiterungen von ODEMx umstaendlich

Neue Continuous Implementierung
===============================

- Integration mit ODEMx-Features (Datenerfassung, Auswertung)
- Erweiterung des Test-Moduls mit Unit-Tests fuer die neuen Klassen
- Integration der genutzten Bibliotheken in Makefile / Visual Studio Projekten
- Dokumentation und mehrere Beispiele zur Nutzung der neuen Komponenten
Grund: Funktionalitaet und Nutzerfreundlichkeit ;)
