Update Vorgehensweise

Projektarbeit-3/Vorgehensweise.md

@@ -116,7 +116,7 @@ Folgender zeitlicher Rahmen ergab sich nun rückblickend für unser Projekt:
         <td>12</td>
         <td>Dokumentation</td>
         <td>Projektdokumentation und Präsentation</td>
-        <td>3 (1,5 + 1,5</td>
+        <td>3 (1,5 + 1,5)</td>
         <td>Marcel Schwarz, Tim Herbst</td>
         <td>3</td>
     </tr>
@@ -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:
 <div align="center">
    <img src="uploads/f3d80c5db349d01a62743a6a4dd34df8/Architektur-design.png"/>
 </div>
+Jede Kachel repräsentiert eine Komponente in Angular, wobei diese wiederum weitere Unterkomponenten besitzt.
 
+Hierarchisch betrachtet ergibt sich folgende Reihenfolge:
+<div align="center">
+   <img src="uploads/812d9ee512b476a5050d9d263906fbcb/Architektur.001.png"/>
+</div>
+
+Programmatisch sieht das wie folgt aus (AppComponent.html):
+```
+<app-toolbar></app-toolbar>
+<router-outlet></router-outlet>
+<app-footer></app-footer>
+```
+### 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.
+### Domänenobjekte im Frontend
-* Erläuterung der Domänenobjekte
+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
+* Mini-Map mit dynamischen An/aus auch in Umsetzung