diff --git a/Projektarbeit-3/Vorgehensweise.md b/Projektarbeit-3/Vorgehensweise.md
index f0ee16e..182893d 100644
--- a/Projektarbeit-3/Vorgehensweise.md
+++ b/Projektarbeit-3/Vorgehensweise.md
@@ -116,7 +116,7 @@ Folgender zeitlicher Rahmen ergab sich nun rückblickend für unser Projekt:
12 |
Dokumentation |
Projektdokumentation und Präsentation |
- 3 (1,5 + 1,5 |
+ 3 (1,5 + 1,5) |
Marcel Schwarz, Tim Herbst |
3 |
@@ -124,6 +124,8 @@ Folgender zeitlicher Rahmen ergab sich nun rückblickend für unser Projekt:
// TODO: Abweichung vom Projektplan farblich Kennzeichnen
+Generell haben wir akkurat und präzise die Personentage geschätzt und haben bei keinem geplanten Arbeitspaket die dafür vorgesehene Zeit überschritten.
+Durch die enorme Performancesteigerung im Backend mussten wir mehr Zeit im Frontend für die dynamische Interaktion zwischen Tabelle und Mini-Map (Im Dashboard) einplanen. Dadurch hat sich aber der Zeitplan des gesamten Projektes nicht verändert.
# Backend
## Architektur
@@ -227,19 +229,103 @@ Die Lokalen Endpoints sind:
# Frontend
## Architektur
-Das Frontend basiert auf dem Prinzip einer Single-Page Applikation. Das bedeutet, dass die Webanwendung aus einem einzigen HTML-Dokument besteht und deren Inhalte dynamisch nachgeladen werden. In unserem Fall, laden wir anhand unserer URL die einzelnen Komponenten.
+Das Frontend basiert auf dem Prinzip einer Single-Page Applikation. Das bedeutet, dass die Webanwendung aus einem einzigen HTML-Dokument besteht und deren Inhalte dynamisch nachgeladen werden. In unserem Fall laden wir anhand der URL die einzelnen Komponenten.
Folgende Architektur wurde umgesetzt:
+Jede Kachel repräsentiert eine Komponente in Angular, wobei diese wiederum weitere Unterkomponenten besitzt.
+Hierarchisch betrachtet ergibt sich folgende Reihenfolge:
+
+
+
+
+Programmatisch sieht das wie folgt aus (AppComponent.html):
+```
+
+
+
+```
+### Toolbar und Footer
+Da Toolbar und Footer unabhängig der URL fast den gleichen Inhalt besitzen sind diese auf Top-Level Ebene in der App-Komponente gepflegt.
+
+### Router-Outlet
+Das Router-Outlet kommt mit dem AngularRoutingModule und man erhält dadurch von Haus aus eine sehr einfache Möglichkeit, eigene Routen und URL-Parameter zu definieren.
+
+Im `AppRoutingModule` muss lediglich ein Array mit den gewünschten Routen definiert werden. Dies sieht wie folgt aus:
+```
+const routes: Routes = [
+ {path: '', redirectTo: 'map', pathMatch: 'full'},
+ {path: 'map', component: MapComponent},
+ {path: 'dashboard/:id', component: DashboardComponent}
+];
+```
+Mit der Angabe von **:id** im Pfad für die `DashboardComponent` können wir später je nach Wahl der Station das Dashboard nach Dashboard-ID generieren.
## Hochzeit mit dem Backend
-* Methoden der Services, welche mit dem Backend kommunizieren.
-* Erläuterung der Domänenobjekte
+### Domänenobjekte im Frontend
+Um das von uns erstellte Datenmodell im Frontend ohne Weiteres nutzen zu können, mussten wir erst einmal die wichtigsten Domänenobjekte im Frontend mappen.
+
+#### Map-Bike-Point
+Der Map-Bike-Point wird vor allem für Map auf der Startseite und das PopUp benötigt. Das Domänenobjekt liefert folgende Informationen:
+* id: eindeutiger Identifier vom Typ string
+* commonName: sprechender Name der Station vom Typ string
+* lat: Breitengrad vom Typ number
+* lon: Längengrad vom Typ number
+* status: verschachteltes Objekt vom Typ BikePointStatus
+
+Das verschachtelte Objekt status vom Typ BikePointStatus hat wiederum folgende Felder:
+* NbBikes: Anzahl verfügbarer Fahrräder in der Station
+* NbEmptyDocks: Anzahl leerer Fahrraddocks in der Station
+* NbDocks: Anzahl aller Fahrraddocks in der Station
+
+Programmatisch ist der Map-Bike-Point wie folgt abgebildet:
+```
+export interface IMapBikePoint {
+ id?: string;
+ commonName?: string;
+ lat?: number;
+ lon?: number;
+ status?: BikePointStatus;
+}
+
+export class MapBikePoint implements IMapBikePoint {
+ constructor(
+ public id?: string,
+ public commonName?: string,
+ public lat?: number,
+ public lon?: number,
+ public status?: BikePointStatus
+ ) {
+ }
+}
+
+export class BikePointStatus {
+ NbBikes?: number;
+ NbEmptyDocks?: number;
+ NbDocks?: number;
+}
+```
+#### Dashboard-Common-Bike-Point
+Der Dashboard-Common-Bike-Point ist in der Dashboard-Komponente und allen Kind-Komponenten zu finden. Folgende Informationen erhalten wir:
+* id: eindeutigen Identifier vom Typ string
+* color: Farbe für das Icon auf der Mini-Map vom Typ string
+* commonName: sprechender Name der Station vom Typ string
+* lat: Breitengrad vom Typ number
+* lon: Längengrad vom Typ number
+* maxEndDate: spätest-mögliche Datum in der eine Ausleihe enden kann
+* maxStartDate: frühest-mögliche Datum in der eine Ausleihe starten kann
+
+Programmatisch ähnelt dieses Domänenobjekt dem Map-Bike-Point.
+
+### Methoden, welche mit dem Backend kommunizieren
+
+
+
## Einbinden von Leaflet
* Erläuterung des Map-Service in Bezug auf Layer und Marker-Generierung
* Grober Ablauf der Map-Generierung (Layer-Aufbau grafisch darstellen)
* Heatmap bei Umsetzung
-* Minimap mit dynamischen An/aus auch in Umsetzung
\ No newline at end of file
+* Mini-Map mit dynamischen An/aus auch in Umsetzung
\ No newline at end of file