Design Dokumentation

Vorwort

Bei der Planung und Implementierung des Projekts wurde darauf geachtet das durch eine lose Kopplung die Arbeitsteilung und erweiterung gewährleistet wird. Die Gliederung erfolgte durch eine Zusammenfassung von Assemblies zu logischen Komponenten. Die Zuordnung erfolgt hier über den Namespace.

Die folgenden Design Entscheidungen und Vorgaben wurden aus dieser Architektur abgeleitet.

Folgende Design Entscheidungen wurden zu Anfang getroffen:

• Verwendung von WCF Named Pipes um die logischen Komponenten miteinander zu verbinden.
• Pro logischer Komponente muss es eine Assembly geben welche die Funktionen und Objekte bereit stellt welche über die WCF angeboten werden.
• Eine zentrale Logging Komponente wird verwendet um eine gute Sichtbarkeit über die Events der Gesamten Applikation zu gewährleisten.
• Die Simulations Komponenten sollen unabhängig vom UI laufen können. Dies wurde Entschieden um die Austauschbarkeit des UI's zu ermöglichen.

Die Beschreibung erfolgt in mindestens zwei Schritten

1. Bildliche Darstellung des Klassendiagramms jeweiliger Komponente.
2. Schnittstellenbeschreibung (Die Frage ist, machen wir die Schnittstellenbeschreibung auf der Komponenteneben, wie z.B. Simulation.Engine / Simulation.WebService usw., oder auf eine Ebene höher, wie z.b. Simulation / TrafficLightControl usw.

=======================

=======IN ARBEIT=========

=======================

3. Je nach Bedarf, weitere Beschreibungen relevanten Zusammenhängen zwischen einzelnen Komponenten oder innerhalb der gleichen Komponente.

Logging - NLog

=======================

=======IN ARBEIT=========

=======================

Simulation

Contracts

=======================

=======IN ARBEIT=========

=======================

Engine

1. Klassendiagramm SimulationEngine:

Variante 1:

Variante 2:

2. Schnittstellenbeschreibung (erst die globale Frage,siehe Vorwort, beantworten):

=======================

=======IN ARBEIT=========

=======================

Traffc Light Control

=======================

=======IN ARBEIT=========

=======================

Contracts

=======================

=======IN ARBEIT=========

=======================

Engine

=======================

=======IN ARBEIT=========

=======================

UI

=======================

=======IN ARBEIT=========

=======================

User Interface UI

=======================

=======IN ARBEIT=========

=======================

Application

=======================

=======IN ARBEIT=========

=======================

Contracts

=======================

=======IN ARBEIT=========

=======================

View Model

=======================

=======IN ARBEIT=========

=======================

BESPRECHUNGSNOTIZEN

Allgemein

Was muss da sein?

Straße soll da sein

Straße ist eine "Kante"

"Kante" bekommen eine Länge x

Kreuzung soll da sein

Kreuzung ist ein "Knoten"

"Knoten" müssen Koordinaten haben

Auto soll fahren

Auto hat Start "Quelle" und Ziel "Senke" (Route).

Start kann auch gleichzeitig ein Ziel sein

Start und Ziel sind definitiv die Endpunkte vom Bildschirm

Engine

was soll das Ding könne?!

• Thema Tick
  • fix in der Engine einprogrammiert
  • s

Enviroment

• Heimat aller Strassen Kreuzungen

• Hat fertige Objekte, die instansiert sind

• Einfügen Basisklassen im Enviroment

Includiert:

• Knoten und Kanten

GUI

• Viewe Model

  • sdf

• Simulation

  • sdf

Setting

Beschreibung:

• Settin ist dumm

• darf/soll nichts können, außer object - Beschreibung

Statisch

• z.b. default beim "Start"

--> die Statischen Werten dürfen nicht nicht von den UI werten mipuliert werden

Dynamisch

• sdf
• sdf