Update Vorgehensweise
parent
bba1fa801c
commit
e8b1adc525
@ -116,7 +116,7 @@ Folgender zeitlicher Rahmen ergab sich nun rückblickend für unser Projekt:
|
|||||||
<td>12</td>
|
<td>12</td>
|
||||||
<td>Dokumentation</td>
|
<td>Dokumentation</td>
|
||||||
<td>Projektdokumentation und Präsentation</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>Marcel Schwarz, Tim Herbst</td>
|
||||||
<td>3</td>
|
<td>3</td>
|
||||||
</tr>
|
</tr>
|
||||||
@ -124,6 +124,8 @@ Folgender zeitlicher Rahmen ergab sich nun rückblickend für unser Projekt:
|
|||||||
|
|
||||||
// TODO: Abweichung vom Projektplan farblich Kennzeichnen
|
// 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
|
# Backend
|
||||||
## Architektur
|
## Architektur
|
||||||
@ -227,19 +229,103 @@ Die Lokalen Endpoints sind:
|
|||||||
|
|
||||||
# Frontend
|
# Frontend
|
||||||
## Architektur
|
## 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:
|
Folgende Architektur wurde umgesetzt:
|
||||||
<div align="center">
|
<div align="center">
|
||||||
<img src="uploads/f3d80c5db349d01a62743a6a4dd34df8/Architektur-design.png"/>
|
<img src="uploads/f3d80c5db349d01a62743a6a4dd34df8/Architektur-design.png"/>
|
||||||
</div>
|
</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
|
## 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
|
## Einbinden von Leaflet
|
||||||
* Erläuterung des Map-Service in Bezug auf Layer und Marker-Generierung
|
* Erläuterung des Map-Service in Bezug auf Layer und Marker-Generierung
|
||||||
* Grober Ablauf der Map-Generierung (Layer-Aufbau grafisch darstellen)
|
* Grober Ablauf der Map-Generierung (Layer-Aufbau grafisch darstellen)
|
||||||
* Heatmap bei Umsetzung
|
* Heatmap bei Umsetzung
|
||||||
* Minimap mit dynamischen An/aus auch in Umsetzung
|
* Mini-Map mit dynamischen An/aus auch in Umsetzung
|
Loading…
Reference in New Issue
Block a user