Entscheidungsprotokoll - Archi-Lab/prox-documentation-gp-ws2018 GitHub Wiki

Inhalte auf dieser Seite

In diesem Abschnitt wurden wichtige Entscheidungen zu Design und Technologie getroffen. Zur Architektur wurden keine Entscheidungen vom Entwicklungsteam getroffen, da sie als Randbedingung vorgegeben wurden. Vollständigkeitshalber wird hier aber erklärt was solche Architekturentscheidungen umfassen.

Architekturentscheidungen

Beim Konzipieren einer Softwarearchitektur werden nicht-funktionale Anforderungen von wichtigen Stakeholdern wie z. B. Skalierbarkeit, Wartbarkeit, Wiederverwendbarkeit u. ä. in einer Abstraktion auf hoher Ebene eines Systems verwandelt. Auf dieser Ebene befinden sich vor allem technische und geschäftliche Erwartungen. Beantwortet hauptsächlich die Frage von „was“ für ein System entwickelt werden soll.

Unter „Softwarearchitektur“ befindet sich die von unserem Auftraggeber vorgegebene Randbedingung.

Designentscheidungen

Im Prozess des Softwaredesigns, werden unterschiedliche Muster und Prinzipien auf Codebasis betrachtet. Hierzu gehören Überlegungen im Umfang von Modulen, Klassen, Funktionszweck usw. Als Beispiel soll das SOLID Prinzip hier aufgeführt werden. Beantwortet die Frage von „wie“ die einzelnen Komponenten des Systems entwickelt werden sollen.

Neuentwicklung der Weboberfläche

Da wir als Team festgelegt haben, den kompletten Backend-Bereich (Module, Projekte und Studiengänge) neu zu implementieren, haben wir uns demnach auch entschlossen, die Webplattform neu zu entwickeln. Eine Neuentwicklung statt der Anpassung des alten Webplattforms war für uns sinnvoller aufgrund der folgenden drei Aspekte:

  1. Das Angular 4 HAL Framework war aufgrund eines Fehlers seitens Angular 4 HAL nicht Ordnungsgemäß im Frontend hinzugefügt. Der Fehler ist mittlerweile im neuen Frontend behoben.
  2. Die Nutzer-Komponente im Frontend erfüllte keinen Zweck.
  3. Ziel war es zunächst ein MVP für das neue Modul/Studiengang-Backend zu erzeugen und später für das neue Projekt-Backend.

Benutzeroberfläche als Single-Page-Applikation für alle Microservices

Da wir für die Entwicklung unserer Weboberfläche das Angular Framework verwenden, und Routing für die Navigation zwischen den einzelnen Modulen verwenden, wird nicht jede Seite vom Server vollständig neu geladen. Es werden lediglich nur neue Daten gesendet, wenn der Benutzer durch die Module bzw. Seiten der Weboberfläche navigiert. Eine Single-Page-Applikation bietet uns statt herkömmlich traditionelle Seiten folgende Vorteile:

  • Eine SPA Weboberfläche ist und fühlt sich für den Nutzer viel schneller an, da die meisten Ressourcen während der gesamten Anwendungsdauer nur einmal geladen werden. Nur Daten werden hin und her übertragen. Dadurch muss der Nutzer nicht auf den Browser für die erneute Ladung der Weboberfläche warten.
  • Neben der schnelleren Benutzererfahrung verbraucht der Server weniger Ressourcen, da sich der Server auf die Bereitstellung einer effizienten API konzentrieren kann, anstatt Layouts serverseitig zu erstellen.
  • SPAs lassen sich mit Chrome und Firefox problemlos debuggen, da Sie Netzwerkvorgänge, Seitenelemente und damit verbundene Daten untersuchen und überwachen können.

Aufgrund der oben genannten Vorteile entschieden wir uns für die Entwicklung einer Single-Page-Applikation für alle Microservices in der Weboberfläche.

Look-and-Feel des Frontends anhand von Material Design gestalten

Das Design des Frontends basiert fast vollständig auf das Material Design für Angular von Google. Wir haben uns für das Material Design entscheiden, weil diese direkt vom Angular Framework unterstützt wird, uns viel CSS-Arbeit abnimmt und sich ohne viel Aufwand im Code implementieren lässt. Zusätzlich gefällt uns die Designart, da sie sehr professionell wirkt.

Frontend reagiert automatisch und unterschiedlich auf verschiedenen Endgeräten mittels Responsive Design

Bei der Entwicklung des Frontends wurde auf ein Responsive Design geachtet. Uns war es wichtig, dass die Weboberfläche auf jedem Endgerät präsentabel aussieht. Aufgrund dessen hängt die Darstellung einiger UI-Komponenten an die Fenstergröße ab. Das heißt, dass auf Basis der Fenstergröße, sich der Styleart solcher UI-Komponenten in der Weboberfläche ändert, damit sie bei beliebiger Fenstergröße optisch überschaubarer und besser aussieht.

Coding-Styleguides

Für die UI haben wir uns entschieden das Angular Styleguide zu verwenden. Für die Domänenobjekte, die in Java unter der IntelliJ IDEA programmiert wurden, wurde folgender Codestyle verwendet.

Technologieentscheidungen

Während der Entscheidung was für ein System und wie das durch Code ausgedrückt wird stattfindet, werden Technologien dafür verwendet um diesen Wertschöpfungsprozess auf Entwickler- und Teamprozess-Ebene zu unterstützen. Diese Technologien sollen das Erledigen von den Aufgaben des Entwicklerteams erleichtern. Diese Beschreibung beschränkt sich hauptsächlich auf der Nutzung von digitalen Technologien. Dieser Abschnitt bewantwortet grundsätzlich die Frage „womit“ das System entwickelt werden soll.

Migration von GitLab auf GitHub

Um alle von Git Versions-kontrollierte Code-Artefakte zentral zu lagern, brauchten wir einen Ablageort, einen sogenannten „Git Repository“, um diese zu machen. Zu Anfang des Projekts entschieden wir uns das Repositorium in unsere GitLab Gruppe prox zu verwenden, da alle Teammitglieder schon mal GitLab verwendet hatten. Dieser Ablageort ist aber der Öffentlichkeit nicht zugänglich, deshalb kann es nur mit Zugangsberechtigung zugegriffen werden.

Im Laufe des Projekts fiel die Entscheidung seitens der Organisation ArchiLab, die ganze Codebasis auf ein komplett öffentliches Git-Repositorium (GitHub) Stück für Stück umzuziehen. Diese Entscheidung hätte bis zum Abschluss unseres Projekts kein direkten Einfluss gehabt, ob wir bei GitLab bleiben oder zu GitHub umziehen. Da wir aber als Prox Team uns vorgenommen hatten die „Projekt- und Themenbörse“ vor vornerein als ein ausgereiftes und wartbares Softwareprojekt zu entwickeln, entschieden wir uns dafür die ganze von uns entwickelte Codebasis auf GitHub zu migrieren. Mit dieser Entscheidung wurde unsere Ansicht verstärkt relevante Software zu produzieren und erfüllte die von unseren Hauptstakeholder aufgestellten Anforderung eines Minimal Viable Product (MVP).

Ablage der Dateien und Ordner auf Google Drive

Zu Anfang des Projekts, war es nötig Dateien und Ordner miteinander im Team zu teilen. Da viele von uns Google Accounts schon hatten, wurde die Entscheidung gefällt alle Code-unabhängige Artefakte auf unserem gemeinsamen Google Drive Ordner zu speichern.

Continuous Deployment auf Jenkins

Continuous Deployment ist ein Vorgehensmodell Software so zu entwickeln, das bei jedem Push einer Codeänderung zum eigenen Git-Repositorium, die ganze Änderung in Produktion geht. Kurz und prägnant, der Nutzer der Software wird sofort von der Codeänderung im Livesystem mitbekommen. Dies verkürzt die Feedback-Schleifen, die Softwareentwickler dadurch erlangen können, sodass sie schneller auf Kritik und Beschwerden über die Software reagieren können.

Wir haben uns explizit dazu entschieden Jenkins weiterzuverwenden, da die vorherigen Teams, die sich damit beschäftigt haben Jenkins in einem eigenen Server laufen zu lassen, dies so konfiguriert haben, dass es mit neuen Projekten oder Services problemlos weiter funktioniert.

Kommunikation im Team via Discord

Face-2-Face Kommunikation war seit Anbeginn unseres Projekts die höchste Priorität. Dies ist aber nicht immer möglich. Für Fälle wo trotzdem so schnell wie möglich in Form von Text-Chat oder Voice-Chat kommuniziert werden sollte, wurde Discord verwendet. Alles lief über unseren Projekt-dedizierten Kanal.

Dokumentation mittels GitHub (Markdown)

Um das ganze Projekt zu dokumentieren, haben wir uns entschieden alles auf GitHub zu erfassen. Der Vorteil davon ist, das mit dieser sogenannten „GitHub Flavored Markdown“-Sprache ohne großen Aufwand „lebendige“ Dokumente erstellt werden können, die kontinuierlich, kollaborativ und Versions-kontrolliert weiter gepflegt werden können. Dazu soll die Projektdokumentation so nah am Code liegen wie möglich. Aus diesem Grund existiert auch das Git Repositorium Prox Dokumentation.

Zeichnen der Diagramme mittels draw.io

Um alle Diagramme in unserem Projekt zu zeichnen verwendeten wir draw.io. Es ist eine kostenlose Online Diagrammsoftware zur Erstellung von UML-Diagramme, Netzwerkdiagrammen und sonstige für uns relevante Diagramme. Wir entschieden uns dafür, da es eine sehr bequeme und nahtlose Integration mit Google Drive anbietet, und weil Mitglieder unseres Teams schon bei früheren Softwareprojekten gute Erfahrung damit gesammelt haben.

Whiteboard für das Verwalten von Teamaufgaben

Da die Anzahl der Entwickler (drei Teammitglieder) zu Beginn des Projekts eindeutig war, konnten wir schon früh genug entscheiden, wie wir unsere Aufgaben verwalten würden. Wir entschieden uns einen Whiteboard (inkl. Karten und Marker) dafür zu nehmen. Die wichtigsten Anforderungen, die wir damit zu erfüllen versuchten waren die Plansichtbarkeit, Face-2-Face-Kommunikation und Engagement jedes Teammitglieds. Einer der größten Vorteile Aufgaben mit einem Whiteboard zu verwalten, ist die persönliche Zusammenarbeit, die bei kollokierten Teams besonders unterstützt wird. Außerdem bot sich das an ein Whiteboard für unsere Teamarbeit zu verwenden, da wir als Randbedingung für das Teamprozess Scrum verwendeten, und von vornherein zwei feste Arbeitstage in der Woche festgelegt wurden. Hier befindet sich eine Abbildung unseres Whiteboards als Verwaltungsprozess unserer Aufgaben.

Kommunikation zwischen dem Frontend und Backend mittels Angular 4 HAL Framework

Angular 4 HAL ist ein HAL/JSON-HTTP-Client Framework für die einfache Interaktion zwischen einem Angular basierten Webplattform und einer Spring Data Rest API. Wie beim Angular Framework, wurde auch dieses Framework von der vorherigen Guided Project Gruppe für die Entwicklung von Prox verwendet, aber im Gegensatz zu Angular, war die Verwendung von Angular 4 HAL nicht als Randbedingung vorgegeben worden. Aufgrund dessen und weil wir zu der Entwicklungszeit keine sinnvolleren und besseren Frameworks für die Kommunikation zwischen dem Frontend und Backend gefunden haben, haben wir uns für dieses Framework entschieden. Zusätzlich stellt Angular 4 HAL viele Methoden bereit und Relationen zwischen Entities im Frontend lassen sich einfach abbilden. Die genaue Angular 4 HAL Version, die wir bei der Entwicklung des Frontends verwendet haben ist 7.7.0. Das Haupteinsatzgebiet des Angular 4 HAL Frameworks im Frontend wird im unteren Abschnitt Struktur und Kommunikation beschrieben.

Containerisierung durch Docker

Moderne Webanwendungen, die einen Microservice-Architekturstil verfolgen, bedürfen eine leichtgewichtige Containerlösung, um möglichst voneinander entkoppelten Microservices (bspw. Module Service) in Betrieb zu nehmen. Diese leichtgewichtige Variante einer Ausführungsumgebung bietet vor allem den Vorteil gegenüber andere Varianten wie z. B. Virtuelle Maschinen, dass es kein komplettes Betriebssystem simulieren muss, um die jeweiligen Anwendungen oder Diensten auszuführen. Während Virtuelle Maschinen die Hardware „virtualisiert“, abstrahieren Container das Betriebssystem. Containers existieren lediglich, um einzelne Anwendungen auszuführen. Docker gilt als Synonym von Containern, und da es Open-Source ist, konnte wir als Studenten diese Technologie ohne größeren Aufwand nehmen und auf unserem Projekt verwenden.

Objekt-orientiertes Programmieren mit Java

Uns für Java als Programmiersprache zu entscheiden fiel nicht schwer. Schon seit Anfang unseres Bachelor- und Masterstudiums lernten wir die Konzepte dieser Sprache und wandten es an unterschiedlichen Projekten an. Es ist das de facto Standard für objekt-orientiertes Programmieren und herrscht schon seit geraumer Zeit im TIOBE Index auf erster Stelle der meist angewendeten Programmiersprachen. Zusätzlich genießt Java eine erstklassige Unterstützung in den von uns angewendeten Spring Framework, womit produktionsreife Anwendungen komfortabel entwickelt werden können.