Skip to content

7. Abgaberelevante Informationen

Michael Dick edited this page Feb 17, 2023 · 14 revisions

Anmerkungen in Bezug auf den Bewertungsbogen

Kategorien

Welche Kategorien haben wir uns ausgesucht?

1. Schnittstellen

Um die Kommunikation zwischen Frontend und Backend zu realisieren, haben wir unsere eigene Version einer Inter-Process-Communication implementiert. Diese basiert auf Nachrichten im JSON-Format, die von einem eigens dafür geschriebenen Parser im jeweiligen Anwendungsteil (FE/BE) verarbeitet werden.

Die Nachrichten müssen den vorgegebenen Schemas entsprechen, siehe 📚IPC API Dokumentation

2. GUI

Das Frontend für Firstpass ist in Form einer leichten und performanten Electron-Anwendung umgesetzt. Diese nutzt die asynchrone IPC-Schnittstelle, um mit dem Java-Backend zu kommunizieren.

Das grafische Nutzerinterface soll dem Nutzer die Bedienung des Passwortmanagers so angenehm und einfach wie möglich machen. Bedienelemente und Interaktionsabläufe sind so gestaltet, dass Standardaktionen wie das Abspeichern oder verschieben eines Passworts mit wenigen Klicks ausgeführt werden können. Zudem bieten die Einstellungen die Möglichkeit, für bestimmte Aktionen eigene Tasten-Shortcuts festzulegen, um versierten Nutzern einen noch besseren Workflow zu ermöglichen.

Die Farben der Anwendung können durch vordefinierte und benutzerdefinierte Themes verändert werden, um den Wünschen des Nutzers gerecht zu werden. Aufgrund der Flexibilität der Firstpass-UI fügt sich der Passwort-Manager perfekt in bestehende Systeme ein und stellt kein Hindernis in Arbeitsabläufen dar.

Mehr Nutzer nutzen einen Passwortmanager weil er im Alltag nicht nervt = Mehr sicher aufbewahrte Passwörter! 🏆✅

Checkmate, Cyber Criminals! 🥷

CI/CD Pipeline

package.yaml

Der Workflow wird bei Pushes auf den Main-branch des Repositorys ausgelöst und setzt die beiden Umgebungsvariablen "BACKEND_PATH" und "FRONTEND_PATH" auf die Pfade des Backend- und Frontend-Ordners.

  1. Verpacken des Backends:
  • Code aus dem Repository auschecken.
  • Stellt die Java JDK-Version 17 mit der Aktion actions/setup-java@v3 ein.
  • Führt den Maven-Befehl mvn package aus, um das Java-Projekt zu bauen.
  • Lädt das generierte JAR-File mithilfe der Aktion actions/upload-artifact@v2 auf Github als Artefakt hoch.
  1. Bauen des Frontends:
  • Code aus dem Repository auschecken.
  • Installiert Node.js, NPM und Yarn mithilfe der Aktion actions/setup-node@v1.
  • Lädt das Backend-JAR-Artefakt aus dem vorherigen Job herunter.
  • Baut und veröffentlicht die Electron-App mithilfe der Aktion samuelmeuli/action-electron-builder@v1.
  • Archiviert die generierten Anwendungsdateien und lädt sie als Artefakte mithilfe der Aktion actions/upload-artifact@v3 hoch.

pullrequest_backend.yaml

Diese Github Action führt die Unittest des Backends aus sobald ein Pullrequest auf den develop-Branch geöffnet wird und es Änderungen im backend/ Ordner gibt. Erst wenn diese Action erfolgreich durchgelaufen ist, ist der Pullrequest freigegeben.

pullrequest_frontend.yaml

Hier passiert exakt das gleiche wie bei der pullrequest_backend.yaml Action, mit dem Unterschied, dass hier die Tests im Frontend ausgeführt werden wenn es im frontend/ Ordner Änderungen gab. Auch diese Action blockiert das Mergen eines Pullrequests.

Clean Code

SOLID Principles

Single Responsibility Principle

In unserem Projekt haben wir auf einen sauberen Aufbau und Strukturierung sehr großen Wert gelegt. Wie im Single Responsibility Principle vorgeschrieben hat bei uns eine Klasse genau eine Verantwortung die durch den Name der Klasse gut beschrieben wird. Anhand dessen soll man direkt erkennen was, welche Klasse im welchem Kontext tut

Open Closed Principle:

Erweiterungen lassen sich sehr einfach in Firstpass implementieren. Als Beispiel erlauben wir Entwicklern neue Datenbanktypen oder andere Verschlüsselungsalgorithmen zu implementieren. Hierbei bleibt aber die generelle Architektur des Projekts gleich und kann nicht verändert werden.

Liskov Substitution Principle

Dort wo in Firstpass Vererbung genutzt wurde, wurde sehr drauf geachtet, dass Unterklassen die Oberklassen so minimal wie nur möglich erweitern müssen. Somit sind Oberklassen sehr generisch gehalten.

Interface Segregation Principle / Dependency Inversion Principle

Überall wo eine konkrete Implementierung irrelevant war und der Code modular gehalten werden sollte, wurden Interfaces verwendet. Wie oben schon beschrieben bei z.B. der Datenbankimplementierung. Hier kann die konkrete Implementierung je nach Datenbank anders ausfallen. Klassen die dann diese Implementierung benötigen, haben als Parameter das Interface hinterlegt um später einfacher austauschen zu können. Eine konkrete Implementierung kann dann per Factory (z.B: beim Verschlüsselungsalgorithmus) erzeugt werden.

Testing

Auf das Testing in Firstpass haben wir großen Wert gelegt. Da wir hier mit sehr sensiblen Daten arbeiten, bedeutet und das Testen der Verschlüsselungsalgorithmen im Speziellen sehr viel. Aus dem Grund besitzt Firstpass eine hohe Test-Coverage (> 60%) die sowohl die positiven, negativen und die Edgecases testen. Im Projekt wurden die Test wie folg implementiert:

  • Backend
    • J-Unit Tests mit Jacoco Code Coverage
  • Frontend
    • Jest Tests der IPC-Kommunikation

Known Issues

  • .dmg und AppImage Distributionen funktionieren nicht, da die jar-Datei mit im Archiv ist und nicht aufgerufen werden kann.

Reflexion

Was lief gut? Was lief schlecht?

Der Passwortmanager Firstpass ist als gemeinsames Projekt von uns Studenten der Hochschule der Medien im Fach "Software Entwicklung 3" entstanden. Für die Mehrheit war es das erste Softwareprojekt dieser Größe, was natürlich erfordert, dass man sich in den Workflow einarbeitet, die Tools kennenlernt und sich Tricks und Kniffe von anderen Mitgliedern abschaut.

Anfangs, als die Zuständigkeiten und die Themen festgelegt/verteilt wurden, fiel es manchen schwer, sich für einen Bereich zu entscheiden. Zwar war die Motivation, etwas neues zu schaffen und Erfahrungen zusammeln da, aber es gehört natürlich auch der Mut dazu, sich neuen Herausforderungen zu stellen und zu sagen: "Ich habe zwar noch nie im Backend gearbeitet, aber ich lasse mich jetzt einfach mal darauf ein", oder "Design ist nicht so meins aber ein Einblick in den architektonischen Aufbau eines Frontends wollte ich schon immer Mal bekommen".

Das Brainstorming zu Ideen und deren Umsetzung ging gut von der Hand und war nach 2-3 Treffen erledigt. Die Code-Entwicklungsphase lief zügig an nachdem das Repository aufgesetzt war und alle die Funktionsweise des Github-Projektboards verinnerlicht hatten. Das Java-Projekt inkl. passender Struktur stand schnell und obwohl die komplette API ohne Kommunikations-Framework implementiert werden sollte und somit einiges an Planungsaufwand erforderte, machte diese Baustelle trotzdem schon früh stetige Fortschritte.

Das Frontend-Team befasste sich anfangs mit dem Konfigurieren von Electron, um sich eine Grundlage zu schaffen. Während das Backend voranschritt und immer mehr Funktionen implementiert wurden, entstand im Frontend schon das Grund-Design von Firstpass.

Als die MVP-Präsentation anstand, musste das noch bei Weitem nicht fertige Firstpass schnell in einen möglichst funktionalen Zustand gebracht werden, um dem Publikum vorgeführt zu werden. Hierfür musste schnell ein Command Line Interface her, da das Frontend zum damaligen Zeitpunkt nur vereinzelte Funktionen unterstützte. Einige Programmbestandteile mussten hier das erste mal vereint werden und zusammen funktionieren. Da dies, wie auch bei uns, selten beim 1. Versuch klappt war hier einiges an zügigem Bug-Fixing und eine gute Zusammenarbeit notwendig.

Nachdem Firstpass zum Präsentationstermin den MVP-Stand erreicht hatte, verlief die Entwicklungsphase wesentlich reibungloser als zu Beginn. Alle Projektmitglieder trieben gemeinsam den Projektfortschritt voran und nebenher wuchs auch das Wiki.

Die fertig eingerichtete CI/CD-Pipeline ermöglichte dann das veröffentlichen des V 1.0 Releases, ein großer und lang erwarteter Meilenstein im Projekt.

Fazit

Trotz der Anzahl der Projektteilnehmer und dem Umfang des Projekts kamen wir eigentlich immer sehr gut voran. Umplanungen bei Implementation und Umsetzung waren nur selten nötig und es gab keine Rückschläge durch Fehlplanungen. Alle Projektmitglieder haben in den Bereichen git, Organisieren eines Softwareprojekts, Build Management, Schnittstellen und Nutzeroberflächen viel dazugelernt und gegenseitig Wissen austauschen können. Die Arbeit an Firstpass hat viel Spaß gemacht und auch wenn es zwischendurch stressig wurde ging dieser nie verloren.

~ Das Firstpass-Team