add documentation into branch to merge into master

documentation/day01_progress.adoc

@@ -0,0 +1,27 @@
+= Fortschritt Tag 1
+
+=== GutHub-Repo
+
+- Branch-Protection aktiviert
+- CI-Workflow erstellt
+
+=== Spring-Skelett
+
+Projekt initialisiert mit
+- Spring-Actuator
+- Spring-Devtools
+- Thymeleaf
+- Spring Data JDBC
+- Spring Web
+- Spring Security
+- H2 Database
+- Lombok
+
+Wir haben uns für eine H2 Datenbank wärend der Entwicklung entschieden.
+Wir haben uns wegen kleinen Datenbankanforderungen und Verständnis für Spring Data JDBC entschieden.
+
+Zusätzliche Dependencies:
+- ArchUnit
+- AssertJ
+- Spotbugs
+- Checkstyle

documentation/day02_progress.adoc

@@ -0,0 +1,30 @@
+
+= Fortschritt Tag 2
+
+=== Datenbankschema
+
+Wir haben ein simplifiziertes Datenbankschema aufgebaut um die Grundfunktionalität zu implementieren und die Entitäten implementiert.
+
+=== Dockerfile
+
+Wir haben ein Dockerfile geschrieben, welches ein jar-file baut ausführt.
+
+== API
+
+- Swagger2 für Springboot hinzugefügt und einen Beispielcontroller mit einer Produktliste erstellt.
+
+
+== Entities
+-   Entities für die Logik in der Java application erstellt
+-   ToDo: DTO klassen für das handleln der Datenbank erstellen
+
+== Checkstyle
+- nerviges Problem mit Checkstyle gefixt bei dem die Imports immer alphabetisch sortiert werden mussten(!?)
+
+== KeyCloak
+- implementiert, dass man mit einer Rolle angemeldet sein muss, um auf die index.html zu gelangen.
+- @Sessionscope mit rein gepackt, noch nicht 100% sicher ob es funktioniert
+
+== Webdesign
+- Wir haben an der index.html gearbeitet. Es gab jedoch Probleme mit Spring Security, weshalb die Änderungen nicht hochgeladen wurden.
+  Der Fehler wurde jedoch nun gefunden.

documentation/day03_progress.adoc

@@ -0,0 +1,25 @@
+= Fortschritt Tag 3
+
+== Datenbankschema
+
+Mit Jens' Input haben wir uns beim Datenbankschema umentschieden. Wir werden eine Tabelle nutzen die die alle Operationen chronologisch speichert. Die Operationen beinhalten:
+
+- `add Student`
+- `del Student`
+- `create Group`
+- `del Group`
+- `addAdmin Student`
+- `delAdmin Student`
+
+ (These Operations Operations are not final and can be subject to change ;P)
+
+Sie soll nach dem Prinzip funktionieren wie in DB.pdf
+
+Dazu kommen noch weitere Spalten wie StudentID, StudentName und GroupID. So kann eine einfache Gruppierung anhand der Identifier stattfinden.
+
+== Schnittstelle (Idee)
+
+Wir wollen anderen Gruppen die gesamte history, abhängig von der letzten ID die sie an uns mit einem Request schicken, schicken. Die Implementierung und das Handling in ihrem eigenen Modul wollen wir momentan noch ihnen überlassen. Also würden wir die Daten nicht Verarbeiten bevor wir sie rausgeben. Falls das Verarbeiten der Daten am Ende der Nutzer zu lange Dauert könnte man darüber nachdenken die Daten im eigenen Modul zu cachen und kompakter rauszugeben
+
+== Spotbugs
+- Das reportlevel = "high" von spotbugs entfernt. Vorher hat spotbugs eine arrayOutOfBound nicht gemeldet.

documentation/day04_progress.adoc

@@ -0,0 +1,41 @@
+= Fortschritt Tag 4
+
+== Datenbankschema
+
+Also wir haben wieder leichte Veränderungen am Datenbankmodell vorgenommen.
+Wir werden Eventsourcing als Persistenzmodell Verwenden. Die Datenbank besteht nun aus den Spalten:
+`event_id` `group_id` `user_id` und `eventpayload`.
+
+Die Spalte `eventpayload` wird im JSON-Format representiert und beinhaltet alle Infos zu veränderungen.
+Ganz vorne steht die Action die stattfand, welche wir in 7 mögliche Actions unterteilt haben:
+
+- `DeleteGroup`
+- `CreateGroup`
+- `AddUser`
+- `DeleteUser`
+- `UpdateRolle`
+- `UpdateGroupTitle`
+- `UpdateGroupDescription`
+
+== Gruppenservice/Events
+
+Wir verwenden nun einen Datentyp `Event` um die verschiedenen Events zu handleln.
+Es wird eine Eventliste als Parameter an eine überladene Methode in die `Gruppe` Klasse übergeben.
+Vom Datentyp Event erben die Verschiedenen Events die wir in der DB haben und haben einen entsprechenden Konstruktor:
+
+
+    public class CreateGroupEvent extends Event {
+    String titel;
+    String beschreibung;
+        public CreateGroupEvent(long id, long gruppe_id, String user_id, String titel, String beschreibung)
+        {
+            super(id, gruppe_id, user_id);
+            this.titel = titel;
+            this.beschreibung = beschreibung;
+        }
+    }
+
+== Tests
+
+Wir haben Tests zu den `applyEvent()` Methoden geschrieben aber müssen noch weitere Logik testen.
+

documentation/day05_progress.adoc

@@ -0,0 +1,16 @@
+= Fortschritt Tag 4
+
+== Event -> Group
+Hier haben wir uns mit der übersetzung von den Events zu den Gruppen klassen beschäftigt und Exeptions entwickelt. Auch einige User-cases wie doppeltes einfügen von Gruppenmitgliedern wir jetzt abgefangen. Außerdem wurden Test dazu geschrieben.
+
+== Event
+Wir haben heute das speichern von Events gemacht. Darüber hinaus haben wir das Serializieren und Deserializeren der JSON Daten implementiert. Hierfür haben wir Jackson benutzt.
+
+== Controller
+Wir haben damit angefangen den Input über die UI zu interpretieren, dabei haben wir gemerkt dass wir viele weitere Methoden für das Java Backend schreiben müssen welche wir als nächstes erstellen.
+
+== Tests
+Wir haben mit ArchUnit-Tests die Programm-Architektur überprüft und festgelegt.
+
+== Templates und UI
+Wir haben die Templates für search.html und create.html erweitert.

documentation/day06_progress.adoc

@@ -0,0 +1,17 @@
+== Tag 6
+
+= Gruppen abspeichern
+Wir haben uns heute darum gekümmert über die UI eine Gruppe zu erstellen und diese in die Datenbank zu schreiben. Der Ersteller der Gruppe wird momentan mit in die Gruppe eingefügt das kann später noch verändert werden. Alle Logik findet momentan im Controller statt was später noch verändert wird.
+
+= Tests
+
+Architekturtests erweitert und umstrukturiert, neue tests für die deserialisierung (die sind ein wenig unnötig) und tests für die neue projectGruppen() methode.
+
+= ProjectionService
+
+Die Eventliste wird komplett gelesen und zu gruppen verarbeitet
+Außerdem kann man Gruppen IDs nach User erhalten
+
+= UI
+
+Styling verbessert

documentation/day07_progress.adoc

@@ -0,0 +1,13 @@
+= Tag 7
+
+== Heute haben wir über die Struktur diskutiert. Wir sind zum folgenden Ergebnis gekommen:
+* Wir haben uns für zwei Maps entschieden
+** 1. In der einen Map mappen wir die group_id mit der Gruppe.
+** 2. In der anderen Map mappen wir die user_id mit einer Liste von Gruppen ids.
+** Beide Maps haben die Funktion, schneller auf die Gruppen zuzugreifen.
+
+Dafür haben wir einen neuen Branch erstellt und ein paar Funktionen implementiert. 
+Danach haben wir nochmal Rücksprache mit Jens und Christian gehalten und gemerkt, dass die Implementierung über Maps nicht so vorteilhaft ist wie wir gedacht haben. Der Code wäre zu verwirrend und unübersichtlich.
+Auch wenn wir es so weitermachen könnten, haben wir uns für die Idee mit den Querys entschieden, da wir das als übersichtlicher empfinden.
+
+Ebenfalls haben wir die Readme geschrieben.

documentation/day08_progress.adoc

@@ -0,0 +1,24 @@
+= Tag 8
+
+== APIController
+
+Wir haben einen Controller für die Anfragen der anderen Gruppen geschrieben. Die Anfrage enthält den
+aktuellen Status der Gruppe und liefert als JSON Objekt den neuen Status und die Liste mit den Gruppen
+die sich geändert haben.
+Zzusätlich gibt es eine Wrapperklasse, um die Objekte die wir herausgeben mit der anderen Gruppenbildung-Gruppe
+anzugleichen.
+
+== Testing
+
+Der Eventbuilder wurde verbessert, sodass leichter mit großen Mengen von events getestet werden kann.
+
+Zusätlich gibt es eine Wrapperklasse, um die Objekte die wir herausgeben mit der anderen Gruppenbildung-Gruppe anzugleichen.
+
+== Dokumentation
+
+Wir haben heute fünf Punkte von Arc42 bearbeitet, da wir jetzt wissen, wie unser Projekt genau aussehen soll.
+Außerdem haben wir für eine bessere Lesbarkeit angefangen, den Funktionen Kommentare hinzuzufügen.
+
+== Frontend
+Wir heute wurde die Funktionalität des Erstellens von Gruppen und der Anzeige der eigenen Gruppen hergestellt. Das Template funktioniert nun korrekt mit dem Code.
+Außerdem haben wir das Styling der 3 bestehenden HTML-Templates verbessert und mit der Anwendung abgestimmt.

documentation/day09_progress.adoc

@@ -0,0 +1,20 @@
+= Tag 9
+
+== Frontend
+Wir haben das Styling des Formulars zur Gruppenerstellung verbessert und die fehlenden Optionen zum Teil hinzugefügt.
+Außerdem haben wir eine Anzeige für die Details einer Gruppe erschaffen, die auch mit dem Programm funktioniert, und das Styling der Seite angepasst. Wir haben uns entschieden, getrennte HTML-Files zu erstellen: Eins für den Link von der Liste der eigenen Gruppen aus und eins für den Link über die Suche, in der der User kein Mitglied ist, damit ihm im letzteren Fall die Optionen, die ein Mitglied hätte, unzugänglich sind.
+
+== API Controller
+
+Den API Controller haben wir voerst fertiggestellt. Alle Anfragen die wir bisher bearbeiten wollen,
+werden nun auch bearbeitet.
+
+== EventService Tests
+
+In Zusammenhang mit dem API Controller haben wir ein paar Tests für den Eventservice erstellt, da
+auch hier  einige neue Methoden hinzugefügt wurden und sich der Controller selbst nur schwer testen
+lässt.
+
+== DB und Backend
+
+Heute haben wir uns darum gekümmert der Datenbank die Spalte visibility hinzuzufügen, damit wir schneller nach öffenlichen und privaten Gruppen suchen können. Ebenfalls haben wir die Suche nach öffentlichen Gruppen implementiert.

documentation/day10_progress.adoc

@@ -0,0 +1,11 @@
+= Tag 10
+
+== Frontend
+Heute haben wir eine Error-Seite erstellt, die aber noch nicht error.html heißt, damit noch die normale Error-Seite mit dem Log angezeigt wird. Die Seite wird umbenannt, sobald das Frontend in Kombination mit dem Backend funktioniert.
+Außerdem haben wir die Detailseite überarbeitet, auf die man weitergeleitet wird, wenn man von der Suche aus kommt. Die Seite zeigt nun die richtigen Informationen an. Die benötigten Methoden haben wir in den Controller geschrieben.
+
+== Keycloak
+Änderungen an Keycloakanbindung -> APIController abgesichert
+
+== Backend
+Wir haben uns heute um die Umstrukturierung der Vererbung gekümmert. Vorher hatten wir die Methoden die Einfluss auf die Gruppe nehmen(also die Events) in der Klasse Group. Jetzt haben wir es so umgebaut, dass wir in die einzelnen Events die Gruppe reingeben und die Methode in dem jeweiligen Event ausgeführt wird.

documentation/day11_progress.adoc

@@ -0,0 +1,14 @@
+= Tag 11
+
+== Frontend
+Heute haben wir eine Seite zum Bearbeiten der Mitglieder eine Gruppe mit den entsprechenden Controllern geschrieben. Außerdem haben wir das Styling aller Seiten vereinheitlicht.
+
+== InviteLink
+
+Es wird nun beim erstellen einer privaten Gruppe ein Einladungslink erstellt, der zusammen mit der zugehörigen GroupID in einer seperaten Tabelle gespeichert wird.
+Der Link soll Admins auf der Detailsseite der Gruppe angezeigt werden. Über den Link kommt man dann zur Beitrittsseite der jeweiligen Gruppe.
+Bei dem Löschen der Gruppe muss in Zukunft auch noch das löschen des Links hinzugefügt werden.
+
+== Backend
+Heute haben wir alte Fehlermeldungen implementiert. Wir haben außerdem das beitreten in eine Gruppe über die UI implementiert.
+Zudem haben wir angefangen eine extra Seite zu erstellen, wo man Gruppen über eine csv Datei eine Gruppe erstellen kann. Dort hatten wir Schwierigkeiten einen Button je nach Role des Users anzeigen zu lassen. Das Problem lag im th:if. Dort hatten wir anstatt das ' ' -> " "   

documentation/day12_progress.adoc

@@ -0,0 +1,21 @@
+= Tag 12
+
+== Backend
+zeiHeute haben wir uns darum gekümmert eine Veranstaltung mit einer csv Datei zu erstellen. Außerdem haben wir die Suchfunktion verbessert.
+Bedeutet Groß und Kleinschreibung wird ignoriert, damit eine bessere suche möglich ist.
+Außerdem haben wir die Suchfunktion verbessert.
+
+== Frontend
+Heute haben wir die Templates für das Editieren von Mitgliedern der Gruppe fertiggestellt und den entsprechenden Buttons ihre Funktion gegeben. Das Frontend ist nun im groben fertig, es fehlt nur noch der Feinschliff.
+Außerdem haben wir einige Changes am Styling gemacht, damit alles konsistenter und schöner aussieht.
+
+== CSv-Import
+Heute haben wir uns darum gekümmert eine Veranstaltung mit einer csv Datei zu erstellen.
+Außerdem kann jetzt ein orga auch in der gruppenübersicht -> mitgliedglider bearbeiten über eine csv-datei mitglieder hinzufügen.
+Wenn man die CSV-Datei auswählt wird nun ihr Name auf der website angezeigt.
+
+== Eventservice
+Checkgroup Methode auf Query umgestellt(performence)
+
+== ErrorHandling
+Errorpage angepasst und als default gesetzt. Außerdem die Exceptions überarbeitet, deren Message wird nun auch auf der Errorpage angezeigt.

documentation/day13_progress.adoc

@@ -0,0 +1,15 @@
+= Tag 13
+
+== Performance Tests
+Wir haben ein paar Performancetests geschrieben und geschaut, wo man eventuell noch optimierungen vornehmen kann.
+Dann ist uns aufgefallen das das wahrscheinlich so gar nicht so sinnvoll ist.
+
+== Entadminisierung
+Wir haben um gekümmert dass in jedem Fall mindestens ein admin in einer gruppe bestehen bleibt.
+
+== Funktionen
+Heute haben wir uns darum gekümmert das unsere Gruppen ein Beitrittslimit haben. Das kann man bei normalen Gruppen über die UI einstellen.
+Für Vorlesungen haben wir uns entschieden erstmal einen festen Wert zu nehmen, da wir uns noch uneinig sind ob wir die Gruppengröße Anpassbar machen wollen. Ebenfalls haben wir Probleme bei der Suchefunktion und beim Beitrittslimit gefixt. 
+
+== Frontend
+Heute haben wir das Styling weiter verbessert und vereinheitlicht. Außerdem haben wir die Funktion eingebunden, dass man die tatsächliche und die maximale Anzahl Mitglieder sehen kann.

documentation/day14_progress.adoc

@@ -0,0 +1,19 @@
+= Tag 14
+
+== Gruppen löschen
+
+Wir haben die Funktionalität Gruppen zu löschen für die Admins ermöglicht.
+Darüber hinaus werden Gruppen gelöscht wenn sie keine Mitglieder mehr haben
+
+== MaxUser anpassen
+
+Die Anzahl der Maximalen User wird immer angepasst wenn beim hinzufügen über CSV die Grenze überschritten wird.
+
+== Suche optimiert
+Grundlegende überlegungen zur Suche gemacht und mit Grundgerüst angefangen
+
+== Links anzeigen
+Angefangen zu implementieren, dass die InviteLinks von privaten Gruppen auf der details Seite angezeigt werden.
+
+== API
+Schnittstelle zum erstellen von Gruppen angelegt. Wird jetzt wohl doch nicht mehr gebraucht ...

documentation/day15_progress.adoc

@@ -0,0 +1,19 @@
+= Tag 15
+
+== Event 
+
+Heute haben wir ein neues Event hinzugefügt. Dieses bewirkt das man die maximale Teilnehmer Zahl ändern kann.
+
+== Fehler
+
+Heute haben wir Fehler die mit dem neuen Event aufgetaucht sind behoben. Außerdem auch andere die uns jetzt erst aufgefallen sind.
+Wir haben heute angefangen unsere Tests zu refactorn.
+
+== Invite Link
+Der Einladungslink von privaten Gruppen wird nun auf der Details Seite angezeigt und kann per Button
+kopiert werden. Die Server URL ist bei Verbindung über localhost aber noch fehlerhaft. Um dies zu beheben
+wurde localhost gehardcoded, was unbedingt am Ende entfernt werden sollte.
+
+== Frontend
+Heute haben wir einen Scrollbar für die Mitgliederliste eingefügt und das Styling bei "EditMembers.html" angepasst.
+

documentation/day16_progress.adoc

@@ -0,0 +1,28 @@
+= Tag 16
+
+== Documentation
+Heute haben wir an der arc42-Dokumentation weitergearbeitet und die ersten Abschnitte fertiggestellt.
+
+== Tests
+
+Heute haben wir damit weiter gemacht unsere Tests zu Refactorn.
+Diese müssen sowieso noch angepasst werden weil wir für die GruppenId jetzt eine UUID nutzen.
+
+== Controller
+
+Wir haben den Controller refactored da zu viel Logik in den Methoden waren.
+Diese haben wir zum größten Teil in den Controllerservice ausgelagert.
+
+== Titel und Beschreibung
+
+Wir haben eine Seite erstellt über die man den Titel und die Beschreibung einer Gruppe nachträglich noch anpassen kann.
+
+== Suche reparieren
+
+Man kann nicht wieder beitreten sobald man die Gruppe verlassen hat
+
+== changeMetaData
+Der Titel und die Beschreibung sind nun bearbeitbar über die Detailseite der Gruppe.
+
+== InviteLink
+Der Einladungs Link wird nun richtig zusammengebaut und angezeigt.

documentation/day17_progress.adoc

@@ -0,0 +1,17 @@
+= Tag 17
+
+== Documentation
+
+Heute haben wir an der arc42-Documentation weitergearbeitet.
+
+== Gruppensuche
+Die Gruppensuche funktioniert nun, auch nach mehrfachem verlassen und beitreten der selben Gruppe.
+
+== sortierte Gruppen
+Die Gruppen werden nun sowohl auf der Startseite als auch bei der Suche sortiert nach Veranstaltung und normaler Gruppe angezeigt.
+
+== Checkstyle und Spotbugs
+Alle Fehler wurden behoben auf dem aktuellem Stand des masters.
+
+== Tests und Refactorn
+Wir haben heute unsere Tests für GroupService Refactort. Außerdem haben wir damit angefangen unsere Klasse ControllerService und unsere Tests dazu zu Refactorn.

documentation/docArc42.adoc

@@ -1,56 +0,0 @@
-// numbering from here on
-:numbered:
-
-<<<
-// 1. Anforderungen und Ziele
-include::src/01_introduction_and_goals.adoc[]
-
-<<<
-// 2. Randbedingungen
-include::src/02_architecture_constraints.adoc[]
-
-<<<
-// 3. Kontextabgrenzung
-include::src/03_system_scope_and_context.adoc[]
-
-<<<
-// 4. Lösungsstrategie
-include::src/04_solution_strategy.adoc[]
-
-<<<
-// 5. Bausteinsicht
-include::src/05_building_block_view.adoc[]
-
-<<<
-// 6. Laufzeitsicht
-include::src/06_runtime_view.adoc[]
-
-<<<
-// 7. Verteilungssicht
-include::src/07_deployment_view.adoc[]
-
-<<<
-// 8. Querschnittliche Konzepte
-include::src/08_concepts.adoc[]
-
-<<<
-// 9. Entscheidungen
-include::src/09_design_decisions.adoc[]
-
-<<<
-// 10. Qualität...
-include::src/10_quality_scenarios.adoc[]
-
-<<<
-// 11. Risiken
-include::src/11_technical_risks.adoc[]
-
-<<<
-// 12. Glossar
-include::src/12_glossary.adoc[]
-
-'''
-
-(C)
-We acknowledge that this document uses material from the arc42 architecture template, http://www.arc42.de.
-Created by Dr. Peter Hruschka & Dr. Gernot Starke.

documentation/entscheidungen.adoc

@@ -0,0 +1,28 @@
+= Entscheidungsfindung
+
+=== Tag 1
+
+- H2 Datenbank: In-Memory, startet automatisch, schnell
+
+=== Tag 2
+
+- Swagger für API: Automatische Doku + Interaktive UI
+- MySql für Production: Wir wissen nix besseres + JSON Datatype
+- Checkstyle: Google als Basis, Einrückung auf 4 spaces erhöht
+
+=== Tag 3
+
+- Spring Security verringert für H2-Console
+- Event Sourcing: Hat jens gesagt klingt cool
+
+=== Tag 4
+
+-
+
+=== Tag 5
+
+- Jackson für JSON: Spring dabei + Einfaches handling von subklassen
+- Lombok event annotations: Jackson braucht den defaultconstructor
+- Fehlerbehandlung: Exceptions zum besseren umgang in tests etc
+
+=== Tag 6

documentation/src/00_DocumentationToDos.adoc

@@ -0,0 +1,21 @@
+= To Dos der Documentation
+
+== Kontextabgrenzung in 03
+
+* Fachlicher Kontext mit Diagramm
+* Technischer Kontext mit Diagramm
+
+== Blocksicht des Aufbaus in 05
+
+* 1000 verschiedene sachen
+
+== Laufzeitsicht in 06
+
+* auch todes viel
+
+== Noch ne sicht in 07
+
+* auch ass viel
+
+== Mehr Konzepte hinzufügen in 08
+

documentation/src/01_introduction_and_goals.adoc

@@ -1,15 +1,46 @@
+
 [[section-introduction-and-goals]]
 ==	Einführung und Ziele
 
 === Aufgabenstellung
 
+
+==== Was ist das Modul "Gruppenbildung"?
+
+* Die Gruppenbildung dient dem Erstellen und Verwalten von Gruppen im Kontext zu Vorlesungen und sonstigen Veranstaltungen im Rahmen der Heinrich-Heine-Universität.
+* Die Gruppenbildung kann entweder zur Bildung von Gruppen in Verbindung mit einer Vorlesung, einem Kurs, oder einer Lerngruppe oder unabhängig von Vorlesungen zur Bildung einer anderen Zusammenkunft von Studenten außerhalb von Veranstaltungen der Universität verwendet werden.
+* Das Modul kann sowohl von Studenten zur Verwaltung der Teilnehmer einer Vorlesung o.ä., als auch von Studenten zum Bilden von Lerngruppen verwendet werden.
+
+
+==== Wesentliche Features
+
+* Funktionsfähige Software zur Gruppenbildung im Zusammenhang mit oder unabhängig von einer Vorlesung
+* Implementierung verschiedener Rollen mit verschiedenen Funktionen zur Separation von Studenten und Organisatoren
+* Eignung für den täglichen Gebrauch durch viele Benutzer
+* Gute Performance und intuitives Interface
+* Einfache und zuverlässige Verwaltung der Daten über einen langen Zeitraum
+
+
 === Qualitätsziele
 
+[cols="1,2" options="header"]
+|===
+|Qualitätsziel |Motivation und Erläuterung
+|Effizienz und Zuverlässigkeit |Die Softwware wird in Zukunft von vielen Usern gleichzeitig verwendet werden. Dementsprechend spielt Effizienz und Zuverlässigkeit eine große Rolle.
+|Attraktivität |Da die Software ein Teil des MOPS-Moduls ist, das von Studenten täglich verwendet werden soll, wird Wert auf ein attraktives und intuitives Interface gelegt.
+|Wartbarkeit und Analysierbarkeit |Da die Software nach dem Praktikum in fremde Hände gegeben wird, sollte sie für außenstehende gut wartbar sein, ohne viel Zeit aufwenden zu müssen, bis man den Code verstanden hat. Dementsprechend sollte der Code sinnvoll auskommentiert sein. Außerdem soll die Benennung der Variablen, Klassen und Methoden gut verständlich sein.
+|Änderbarkeit |Da die Software Teil eines Praktikums ist und ggf. am Endprodukt Änderungen vorgenommen werden müssen, sollte der Code zugänglich für Änderungen sein. Dies schließt direkt an die Verständlichkeit des Codes an (s.o.).
+|Einfache Anbindung an andere Komponenten des MOPS-Moduls |Da die Komponente Gruppenbildung in Zusammenarbeit mit anderen Komponenten des MOPS-Moduls funktionieren soll, wird eine Schnittstelle für die anderen Komponenten gestellt.
+|===
+
+
 === Stakeholder
 
 [cols="1,1,2" options="header"]
 |===
 |Rolle |Kontakt |Erwartungshaltung
-| _<Rolle-1>_ | _<Kontakt-1>_ | _<Erwartung-1>_
-| _<Rolle-2>_ | _<Kontakt-2>_ | _<Erwartung-2>_ 
+|Entwicklerteam IT-Bois |Entwickler der Software |Möchte Einsicht in Softwareentwicklung im Team und in der Praxis erhalten, Fähigkeiten im Bezug auf Entwicklung einer Software weiterentwickeln, ein gutes Endprodukt für eine gute Benotung im Praktikum abliefern.
+|Jens Bendisposto, Christian Meter, ... |Veranstalter des Praktikums, Bewerter der Software |Möchten ein gutes Gesamtprodukt aus allen Komponenten des MOPS-Moduls erhalten und erwarten demnach eine gute Software als Endprodukt.
+|Studenten |Verwender der Software nach der Fertigstellung |Möchten eine zuverlässige und schnelle Software im Universitätsalltag verwenden, ohne vor Schwierigkeiten in der Bedienung gestellt zu werden.
+|IT-Abteilung der HHU |Möchte nach Übernahme des MOPS-Moduls einen verständlichen, wartbaren Code erhalten, um diesen nach Ende des Praktikums verwalten zu können.
 |===

documentation/src/02_architecture_constraints.adoc

@@ -1,4 +1,28 @@
 [[section-architecture-constraints]]
 == Randbedingungen
 
+=== Technische Randbedingungen
 
+[cols="1,2" options="header"]
+|===
+|Randbedingung |Erläuterung und Hintergrund
+|Niedrige Hardwareanforderungen |Da nicht von jedem Studenten erwartet werden kann, sich einen PC mit starker Hardware zuzulegen, muss das System auch in Kombination mit Hardware von geringerer Leistung gut funktionieren.
+|Betrieb auf allen standartmäßigen browserfähigen Geräten |Da die geschriebene Software eine Webanwendung ist, deren Darstellung nur über Websites funktioniert, ist es auf jedem browserfähigen Gerät möglich, sie zu verwenden. Unter anderem sind demnach Apple, Windows, Linux unterstützte Betriebssysteme.
+|Implementierung in Java, Darstellung durch HTML |Die Funktionalität der Software ist vollständig mit Java 11 implementiert. In der Anwendung wird die Software durch HTML sichtbar gemacht.
+|Anbindung an andere MOPS-Komponenten durch Links |Da die Software ein Teil des MOPS-Moduls ist, ist die Kommunikation mit den anderen Komponenten gewährleistet. Die Weiterleitung erfolgt über Links.
+|Keine Verwendung von fremder Software außerhalb des MOPS-Moduls |Abgesehen von den anderen Komponenten des MOPS-Moduls wird keine Fremdsoftware verwendet.
+|===
+
+=== Organisatorische Randbedingungen
+
+[cols="1, 2" options="header"]
+|===
+|Randbedingung |Erläuterung und Hintergrund
+|Team |Team IT-Bois der Veranstaltung "Programmierpraktikum 2"
+|Zeitplan |Beginn der Entwicklung am 2. März 2020, Ende der Entwicklung am 27. März 2020. Abgabe der Software am letzten Tag.
+|Vorgehensmodell |Testorientierte Entwicklung, also Schreiben der Tests vor oder während der Implementierung der Funktionalität. Zur Dokumentation wird das arc42-Modell verwendet. Die vollständige Dokumentation ist eins der Ziele des Praktikums.
+|Entwicklungswerkzeuge |Erstellen der Grundidee durch Tafelbilder, die von Teammitgliedern entworfen werden. Implementierung der Quelltexte in IntelliJ, außerdem Einbindung vom Spring Framework.
+|Konfigurations- und Versionsverwaltung |Verwendung von Github während des gesamten Praktikums.
+|Testwerkzeuge und -prozesse |JUnit 5 für automatisiertes Testing, Checkstyle und Spotbugs für das Prüfen des Quellcodes. Alle Tests, Checkstyle und Spotbugs und die Continuous Integration (lässt Tests der Anwendung laufen) prüfen den Code vor dem Merge in den Master-Branch.
+|Veröffentlichung als Werkzeug der Universität |Die Quelltexte werden nach Abgabe der Lösung der Universität übergeben.
+|===

documentation/src/03_system_scope_and_context.adoc

@@ -6,17 +6,15 @@
 === Fachlicher Kontext
 
 
+image::fachlicher_kontext.png[]
 
-**<Diagramm und/oder Tabelle>**
-
-**<optional: Erläuterung der externen fachlichen Schnittstellen>**
+Das System wird vom User bedient. Externe Systeme, die Daten von unserem System anfordern, sind die angegebenen. Diese werden ebenfalls im Rahmen des Praktikums entwickelt.
 
 === Technischer Kontext
 
 
+image:technischer_kontext.png[]
 
-**<Diagramm oder Tabelle>**
+Das System erhält Authentifikationsinformationen von einem universitätsinternen Keycloak-Server. Damit können sich die User anmelden. Außerdem erhält es von den anderen Systemen die CSV-Dateien, die die Mitglieder, die einer Gruppe hinzugefügt werden sollen, angibt.
 
-**<optional: Erläuterung der externen technischen Schnittstellen>**
-
-**<Mapping fachliche auf technische Schnittstellen>**
+Die User erhält das System somit von Keycloak, den Input der externen Systeme in Form von CSV-Dateien.

documentation/src/05_building_block_view.adoc

@@ -7,81 +7,66 @@
 
 
 
-_**<Übersichtsdiagramm>**_
+image::bausteinsicht.png[]
 
-Begründung:: _<Erläuternder Text>_
 
-Enthaltene Bausteine:: _<Beschreibung der enthaltenen Bausteine (Blackboxen)>_
+Das System erhält vom User zunächst eine Eingabe in Form eines textuellen Inputs in ein Formular oder eines Knopfdrucks. Dieser Input wird, entsprechend seiner Art, an die Komponenten Gruppenerstellung, Gruppenverwaltung, Gruppensuche und Gruppenbeitritt gegeben.
 
-Wichtige Schnittstellen:: _<Beschreibung wichtiger Schnittstellen>_
+Gruppenerstellung gibt die Information, dass eine Gruppe erstellt wurde, an die Gruppenverwaltung weiter, die Gruppen speichert und löscht.
+
+Eine Eingabe direkt an die Gruppenverwaltung kann z.B. das Löschen einer Gruppe oder das Entfernen eines Users sein. Dies wird von der Gruppenverwaltung selbst durchgeführt.
+
+Die Gruppensuche erhält als Input einen Suchbegriff, den der User eingibt.  Die Suche sucht dann mithilfe der Gruppenverwaltung die gespeicherten Gruppen, die den Suchbegriff beinhalten, heraus und zeigt sie dem User an.
+
+Von der Suche aus kommt man zum Gruppenbeitritt. Dieser wird ebenfalls an die Gruppenverwaltung weitergeleitet und von ihr durchgeführt.
+
+
+Wichtige Schnittstellen:: Die Kommunikation zwischen den Komponenten erfolgt mithilfe von Methodenaufrufen und den darin übergebenen Parametern.
 
 
 
-==== <Name Blackbox 1>
+==== Gruppenerstellung
+
+image::whitebox_erstellen.png[]
+
+Im obigen Diagramm sieht man eine detaillierte Ansicht des Vorgangs der Gruppenerstellung.
+
+Zunächst wird der Input des Users, der in das Formular zur Gruppenerstellung eingetragen wird, vom WebController.java gemapped, also aufgezeichnet, und an den ControllerService.java weitergeleitet. Dort wird die Methode createGroup aufgerufen, falls es sich um eine Gruppe handelt, oder createOrga, falls eine Veranstaltung erstellt wird.
+Beide Methoden erhalten einen Keycloak-Account, einen Gruppentitel, eine Beschreibung, die gewünschte Sichtbarkeit und die gewünschte maximale Teilnehmerzahl, bzw. die Information, dass die Teilnehmerzahl unbegrenz sein soll.
+
+Innerhalb der beiden Methoden werden die Methoden updateTitle, updateDescription, addUser und updateRole aufgerufen. Diese erstellen sogenannte Events mit verschiedenen Eigenschaften.
+Es wird ein CreateGroupEvent erstellt, das aussagt, dass eine Gruppe erstellt wird. Zu jeder Aktion, die beim Erstellen der Gruppe ausgeführt wird, wird ein Event erstellt, so z.B. auch ein AddUserEvent, wenn der Ersteller der Gruppe hinzugefügt wird, oder ein UpdateTitleEvent, wenn der Titel gesetzt wird. So wird zu jedem Attribut der Gruppe ein Event erstellt.
+
+Diese Events werden in den EventService.java hineingegeben. Dieser ist dafür zuständig, das Event zu speichern und erledigt dies mithilfe der Methoden saveEvent und getEventDTO.
+
+Das DTO wird weitergereicht an das EventRepository. Dies ist ein Interface, das von Java gestellte Methoden enthält, die die Kommunikation mit der Datenbank durch Queries erleichtern.
+Durch die Methode save wird das DTO nun in der Datenbank gespeichert.
+
+
+==== Gruppenverwaltung
+
+image::whitebox_verwalten.png[]
+
+Die Gruppenverwaltung funktioniert sehr ähnlich wie die Gruppenerstellung. Zunächst wird der Input vom WebController erfasst. Dieser wird aber zunächst an den ValidationService geleitet. Dieser prüft mithilfe der Methoden checkIfAdmin und checkTitleAndDescription, ob der User, der die Änderungen vornehmen möchte, berechtigt ist, dies zu tun, und ob er valide Eingaben abgesendet hat.
+
+Wenn diese Eingaben korrekt sind, dann werden sie an den ControllerService weitergegeben. Dieser erstellt analog zur Gruppenerstellung die Events, die die Änderungen an den Gruppen speichern.
+Diese Änderungen werden, ebenfalls analog, in die Datenbank gespeichert.
 
 
 
-_<Zweck/Verantwortung>_
+==== Gruppensuche
 
-_<Schnittstelle(n)>_
+image::whitebox_suche.png[]
 
-_<(Optional) Qualitäts-/Leistungsmerkmale>_
-
-_<(Optional) Ablageort/Datei(en)>_
-
-_<(Optional) Erfüllte Anforderungen>_
-
-_<(optional) Offene Punkte/Probleme/Risiken>_
-
-==== <Name Blackbox 2>
-
-_<Blackbox-Template>_
-
-==== <Name Blackbox n>
-
-_<Blackbox-Template>_
+Bei der Gruppensuche wird, vergleichbar mit der Gruppenverwaltung, zunächst der Input geprüft. Wenn der Suchbegriff valide ist, also nicht leer, dann wird im GroupService entweder die Methode findGroupWith aufgerufen, die die Gruppen zurückgibt, die den Suchbegriff im Titel oder in der Beschreibung enthalten, oder die Methode getAllGroupsVisibilityPublic, die alle Gruppen zurückgibt, deren Sichtbarkeit öffentlich ist. Private Gruppen werden in der Gruppensuche nicht angezeigt.
 
 
-==== <Name Schnittstelle 1>
+==== Gruppenbeitritt
 
-...
+image::whitebox_beitreten.png[]
 
-==== <Name Schnittstelle m>
+Hier wird der Input des Users in Form eines Knopfdrucks an den WebController geleitet. Dieser ruft dann den ValidationService auf, der den Vorgang mithilfe zweier Methoden prüft. Zunächst wird geprüft, ob der User bereits in der Gruppe ist. Wenn nicht, dann wird noch geprüft, ob die Gruppe bereits die maximale Teilnehmerzahl erreicht hat.
 
-=== Ebene 2
+Wenn beides nicht der Fall ist, dann wird der ControllerService aufgerufen, der mithilfe der Gruppenverwaltung und des Erstellens eines AddUserEvents den neuen User in die Gruppe einfügt und die Änderung an die Datenbank vermittelt.
 
 
-
-==== Whitebox _<Baustein 1>_
-
-
-
-_<Whitebox-Template>_
-
-==== Whitebox _<Baustein 2>_
-
-_<Whitebox-Template>_
-
-...
-
-==== Whitebox _<Baustein m>_
-
-_<Whitebox-Template>_
-
-=== Ebene 3
-
-
-
-==== Whitebox <_Baustein x.1_>
-
-
-
-_<Whitebox-Template>_
-
-==== Whitebox <_Baustein x.2_>
-
-_<Whitebox-Template>_
-
-==== Whitebox <_Baustein y.1_>
-
-_<Whitebox-Template>_

documentation/src/06_runtime_view.adoc

@@ -2,16 +2,4 @@
 == Laufzeitsicht
 
 
-
-=== _<Bezeichnung Laufzeitszenario 1>_
-
-*  <hier Laufzeitdiagramm oder Ablaufbeschreibung einfügen>
-*  <hier Besonderheiten bei dem Zusammenspiel der Bausteine in diesem Szenario erläutern>
-
-=== _<Bezeichnung Laufzeitszenario 2>_
-
-...
-
-=== _<Bezeichnung Laufzeitszenario n>_
-
-...
+Erläutert in Abschnitt 5.

documentation/src/07_deployment_view.adoc

@@ -3,32 +3,17 @@
 
 
 
-=== Infrastruktur Ebene 1
+=== Infrastruktur
 
+image::deployment.png[]
 
+[cols="1,2" options="header"]
+|===
+|Komponente |Definition
+|Java Application |Ausführbares Programm, mithilfe dessen sich die Anwendung starten lässt
+|Java Runtime Environment SE |Umgebung, auf der das Programm läuft
+|Docker Container |Beinhaltet die Anwendung und simuliert Betriebssystem, auf dem die Anwendung läuft. Enthält außerdem die Datenbank.
+|Browser |Anwendung, die Zugang zum Internet ermöglicht
+|Any type of host |Jedes Endsystem, das Zugriff auf einen Browser hat, kann die Gruppen2Application verwenden.
+|===
 
-_**<Übersichtsdiagramm>**_
-
-Begründung:: _<Erläuternder Text>_
-
-Qualitäts- und/oder Leistungsmerkmale:: _<Erläuternder Text>_
-
-Zuordnung von Bausteinen zu Infrastruktur:: _<Beschreibung der Zuordnung>_
-
-=== Infrastruktur Ebene 2
-
-
-
-==== _<Infrastrukturelement 1>_
-
-_<Diagramm + Erläuterungen>_
-
-==== _<Infrastrukturelement 2>_
-
-_<Diagramm + Erläuterungen>_
-
-...
-
-==== _<Infrastrukturelement n>_
-
-_<Diagramm + Erläuterungen>_

documentation/src/08_concepts.adoc

@@ -2,17 +2,47 @@
 == Querschnittliche Konzepte
 
 
+=== Benutzeroberfläche
 
-=== _<Konzept 1>_
+Für die Benutzeroberfläche wurd Wert auf Einheitlichkeit und stimmige Farbgebung geachtet. Dies sieht man beispielsweise an der Darstellung der Details einer Gruppe:
 
-_<Erklärung>_
+image::frontend_1.png[]
 
-=== _<Konzept 2>_
+Außerdem wird darauf geachtet, dass sich die Oberfläche selbst erklärt und dementsprechend intuitiv funktioniert, ohne, dass Erklärungen notwendig sind.
 
-_<Erklärung>_
+Ein Beispiel hierfür ist das Erstellen einer Gruppe:
 
-...
+image::frontend_2.png[]
 
-=== _<Konzept n>_
+Hier ist das Ausfüllen der Felder des Formulars selbsterklärend und eindeutig.
 
-_<Erklärung>_
+
+=== Event
+
+image::concept_event.png[]
+
+Hier sieht man ein Beispiel für ein Event. Jedes Event ist eine Unterart der Oberklasse Event. Diese Events werden in der Datenbank gespeichert (s. 9. Entscheidungen, "Event Sourcing")
+
+Jede Eventklasse überschreibt die Methode "applyEvent", sodass, je nach Eventtyp die richtige Aktion ausgeführt wird.
+
+Hier sieht man das AddUserEvent, das einen User anhand seiner ID und Informationen einer Gruppe, die mithilfe einer ID identifiziert wird, hinzufügt.
+
+Bevor dies geschieht, werden jedoch Validierungen ausgeführt, die prüfen, ob der User bereits Mitglied in der Gruppe ist und ob die maximale Mitgliederzahl bereits erreicht ist.
+Wenn die Validierungen ohne Fehler verlaufen, dann wird dem User die Rolle "Mitglied" gegeben.
+
+
+=== Validierung im Backend
+
+image::concept_validation.png[]
+
+Hier sieht man ein Beispiel für eine Validierung im Quellcode. Diese prüft, ob ein User Admin ist. Der User und die Gruppe werden in die Methode als Parameter übergeben.
+
+Zunächst wird eine weitere Validierung innerhalb dieser durchgeführt, um zu prüfen, ob der angegebene User Mitglied der angegeben Gruppe ist. Dann wird die Rolle der Users innerhalb der Gruppe geprüft. Falls dieser kein Admin ist, dann wird die angegebene Exception ausgegeben.
+
+
+=== Gruppe
+
+image::concept_group.png[]
+
+Hier sieht man die Klassendefinition der Gruppe.
+Die Attribute werden mithilfe von Lombok, einem Plugin, automatisch eingefügt.

documentation/src/09_design_decisions.adoc

@@ -1,4 +1,37 @@
 [[section-design-decisions]]
 == Entwurfsentscheidungen
 
+=== Festlegen auf einen Datenbanktypen
 
+Während der Entwicklung wird eine H2-Datenbank verwendet, da sie In-Memory funktioniert und automatisch und schnell startet. Die Daten werden hier nur temporär gespeichert, weshalb sie sich nur für die Entwicklung und nicht für die Produktion eignet. In der Produktion wird dann eine MySQL-Datenbank als persistenter Speicher verwendet.
+
+=== Verwendung einer Swagger-API
+
+Da eine Schnittstelle benötigt wird, damit andere MOPS-Komponenten mit unserer Software kommunizieren können, haben wir uns für eine Swagger-API entschieden. Diese nimmt Statusinformationen von den Komponenten entgegen und reagiert mit aktuellen Informationen. Wir haben uns dafür entschieden, weil diese API gut mit Spring funktioniert.
+
+=== Verwendung von Event Sourcing
+
+Dieses Vorgehen wurde uns von unserem Dozenten vorgestellt. Es bewirkt, dass nicht die Gruppen gespeichert werden, sondern die Aktionen, die auf die Gruppen ausgeführt werden. Dies ist an einem Beispiel eines Bankaccouts darstellen, in dem auch nicht der aktuelle Kontostand gespeichert wird, sondern vielmehr die Transaktionen, aus denen dann der Kontostand ausgehend von einem Startwert berechnet wird. So kann man den Stand des Kontos sowohl zum aktuellen, als auch zu jedem vergangenen Zeitpunkt bestimmen.
+
+=== Ausgabe von JSON-Files als Schnittstelle nach außen
+
+Wir haben uns für JSON-Files als Schnittstelle gewählt, weil man sie sehr gut in Java-Objekte umwandeln kann. Somit lassen sie sich von anderen MOPS-Komponenten sehr gut weiterverwenden.
+
+=== Verwenden von aussagekräftigen Exceptions
+
+Durch das Verwenden von Exceptions kann man bessere Aufzeichnung der Fehler der Software erzielen. So sieht man in den Logs genau, welcher Fehler wo aufgetreten ist. Außerdem kann man in den automatisierten Tests die Fehler schneller und genauer identifizieren.
+
+=== Differenzieren der Rechte von Studenten und Organisatoren
+
+Wir haben uns darauf geeinigt, dass Organisatoren nicht nur wie Studenten Gruppen erstellen können, sondern auch die übergeordneten Lehrveranstaltungen, mit denen eine Gruppe verknüpft werden kann.
+So ist die Kontrolle über Lehrveranstaltungen in verantwortungsvollen Händen.
+Studenten können Gruppen jeder Art erstellen.
+
+=== Beitreten in Gruppen in beide Richtungen
+
+Wir haben uns entschieden, dass man als Student Gruppen von sich aus beitreten kann, aber auch, dass man als Ersteller von Gruppen Studenten in eine Gruppe hinzufügen kann. Dies geschieht über den Upload einer CSV-Datei.
+
+=== Beitreten in private Gruppen
+
+Das Beitreten in private Gruppen funktioniert über einen Link, der nur dem Admin der privaten Gruppe sichtbar ist. Diesen Link kann er mit entsprechenden Studenten teilen, sodass nur diese die Möglichkeit erhalten, der Gruppe beizutreten.
+Private Gruppen können in der Suche auch nicht gefunden werden und sind demnach nur über den Link zu erreichen.

documentation/src/10_quality_scenarios.adoc

@@ -2,11 +2,24 @@
 == Qualitätsanforderungen
 
 
-
 === Qualitätsbaum
 
-
+image::quality_tree.png[]
 
 === Qualitätsszenarien
 
-
+[cols="1,2" options="header"]
+|===
+|Qualitätsziele |Szenario
+|1|Ein Student möchte einer Lerngruppe des Fachs Lineare Algebra 1 beitreten. Obwohl es insgesamt über 1000 Gruppen gibt, wird die Suche in angemessener Zeit durchgeführt und die passenden Ergebnisse angezeigt.
+|1|Die Leitung der Fachrichtung Informatik möchte eine Gruppe mit allen Studenten des Fachs erstellen, um regelmäßig wichtige Informationen verteilen zu können. Der Leiter der Fachrichtung kann mithilfe einer CSV-Datei, in der die über 5000 Studenten gelistet sind, die Studenten schnell und zuverlässig hinzufügen.
+|2, 3 |Die Universität verwaltet mithilfe des Moduls Gruppenbildung sehr viele verschiedene Gruppen, was zu einer hohen Belastung des Speichers der Universitätsserver führen kann, wenn die Gruppen nicht richtig verwaltet werden. Da aber die Gruppen ohne Mitglieder automatisch gelöscht werden und auch von Usern manuell gelöscht werden können, findet kein unnötiger Speicherverbrauch statt.
+|3, 4 |Ein Student, der neu an der Universität ist, gibt aus Versehen im Formular zur Gruppenerstellung fehlerhafte Daten ein und setzt weder einen Haken, der die unbegrenzte Anzahl der Mitglieder gewährleistet, noch eine maximale Mitgliederanzahl. Da aber sowohl im User Interface als auch in der Geschäftslogik Validierungen durchgeführt werden, gelangen keine fehlerhaften Objekte in die Datenbank und Fehler werden verhindert.
+|5 |Die Universität legt seit Jahren Wert auf ein modernes Auftreten und hat kürzlich sowohl das eigene Logo, als auch die Studentenausweise modernisiert. Demnach ist eine entsprechende Anforderung an moderner Optik an die Software gestellt, die die Studenten verwenden sollen. Aufgrund des einheitlichen und modernen Aussehens passt die Oberfläche des Moduls "Gruppenbildung" in das Image der Universität.
+|5, 6 |Ein neuer Mathematik-Student, der nicht viel Erfahrung mit PCs und digitalen Formularen hat, sucht eine Lerngruppe im Fach Analysis, um die gelernten Inhalte zu wiederholen. Dank der intuitiven Benutzeroberfläche findet er sich im Modul gut zurecht und kann eine Gruppe nach seinen Vorstellungen erstellen.
+|6, 7 |Ein neuer Mitarbeiter der IT-Abteilung soll in das Modul eingeführt werden und sich in Zukunft um die Wartung kümmern. Weil der Code gut auskommentiert und die Variablen sinnvoll benannt sind, findet er sich in der Software zurecht und braucht nicht lange, bis er mit der Arbeit beginnen kann.
+|7 |Der Dozent des Fachs "Programmierpraktikum" möchte anhand eines Beispiels die Arbeit Teams im 2. Praktikum und das Ergebnis, was erzielt werden kann, darstellen. Dafür zeigt er Teile des Codes und erläutert kurz die Logik, die den Studenten leicht verständlich ist.
+|7, 8 |Ein Student hat einen Bug in der Software gefunden und diesen der IT-Abteilung gemeldet. Da sich der neue Mitarbeiter der Abteilung schnell in den Code eingefunden hat, kann er den Fehler beheben, ohne viel Zeit zu investieren.
+|7, 8 |Die Leitung der Universität möchte ein neues Feature in das Modul "Gruppenbildung" einfügen, und zwar sollen die Mitglieder nicht mehr über eine CSV-Datei, sondern über ein anderes tabellarisches Datenformat eingefügt werden. Weil es nur wenige Abhängigkeiten im Code gibt, kann das  Feature problemlos eingefügt werden.
+|9 |Eine neue Komponente soll ins MOPS-Modul eingefügt werden. Es soll Gruppen annehmen und die Abgabe von Übungsblättern in diesen Gruppen verwalten. Die Schnittstelle der "Gruppenbildung" ist einfach gehalten, weshalb die Anbindung eines neuen Moduls problemlos funktioniert.
+|===

documentation/src/11_technical_risks.adoc

@@ -2,4 +2,71 @@
 == Risiken und technische Schulden
 
 
+=== Unklare Spezifikation und Umfang der Software, fehlerhafte Umsetzung
+
+Zu Beginn des Praktikums bestehen kleine Unstimmigkeiten zwischen der Information, die aus den Spezifikationen, die online zur Verfügung gestellt wurden, und denen, die uns zu Beginn von den Tutoren gegeben wurden. Zu diesem Zeitpunkt lässt sich keine klare Aussage über den Umfang der Software machen.
+In Erwartung, dass im Laufe des Praktikums nähere Informationen über Anforderungen und gewünschte Features gegeben werden, besteht das Risiko, dass wir zu Beginn einen falschen Ansatz wählen und mitten im Praktikum neu beginnen müssen oder länger brauchen als vorgegeben ist (s.u.).
+
+*Eventualfallplanung:*
+
+Falls wir einen falschen Ansatz wählen, dann bleibt uns nichts übrig, als neu zu beginnen oder so viel zu ändern, bis die Software den Anforderungen entspricht.
+
+*Risikominderung:*
+
+Um das Risiko zu mindern, sprechen wir uns mit den Tutoren ab und bitten regelmäßig um Auskunft über Anforderungen oder Wünsche. Außerdem versuchen wir, die Abhängigkeit der verschiedenen Komponenten der Software voneinander möglichst gering zu halten, um Teile bei Bedarf austauschen oder verändern zu können.
+
+
+=== Zeitliche Begrenzung des Praktikums in Relation zum Umfang der Software
+
+Da die Software bis zum 27. März fertiggestellt sein muss und Unklarheiten über den Umfang und die Anforderungen bestehen, sind wir uns nicht sicher, wie viel Zeit die Implementierung in Anspruch nehmen wird.
+
+*Eventualfallplanung:*
+
+Falls die Software nicht fertiggestellt werden kann, haben wir keine anderen Optionen als auf ein Bestehen zu hoffen oder mit den Dozenten eine Verlängerung auszuhandeln.
+
+*Risikominderung:*
+
+Um das Risiko der Zeitknappheit möglichst gering zu halten, beginnen wir mit der Implementierung der wesentlichsten Features, die sicher benötigt werden. Wir werden abwarten, bis die Tutoren oder Dozenten mit Anweisungen zu uns kommen, sondern auf sie zugehen und uns mit ihnen absprechen, um, auch solange Unklarheiten über das Endprodukt bestehen, schnell mit der Implementierung beginnen und voranschreiten zu können.
+Um während der Entwicklung schnell voranzukommen, werden wir uns immer gut absprechen, um ein effizientes Vorgehen umzusetzen.
+
+
+=== Mangelnde Vorkenntnisse
+
+Alle Mitglieder des Teams IT-Bois haben Vorkenntnisse aus den Vorlesungen zur Programmierung. Allerdings ist es möglich, dass die Software, die im Praktikum entwickelt wird, andere und höher gesteckte Anforderungen hat, als wir mit dem aktuellen Wissensstand bedienen können.
+
+*Eventualfallplanung:*
+
+Falls wir auf ein Problem stoßen, dass wir mit unseren Kenntnissen nicht lösen können, dann werden wir die Tutoren befragen können. Wenn dies auch nicht funktioniert, dann müssen wir uns auf einen anderen Lösungsweg einigen.
+
+*Risikominderung:*
+
+Da die Tutoren während des Praktikums stets zur Stelle sein werden, werden wir sie um Rat fragen können, wenn wir Probleme haben. Manche Probleme werden sich vermutlich auch mit einfachen Suchen im Internet lösen lassen. Außerdem sind wir ein Team mit vielen Mitgliedern, in dem sich hoffentlich zu den meisten Problemen eine Lösung finden lässt.
+
+
+=== Kommunikation mit anderen Gruppen, Einigung auf eine Schnittstelle
+
+Da unsere Komponente des MOPS-Moduls mit vielen verschiedenen anderen Komponenten interagieren muss, müssen wir uns mit den anderen Entwicklerteams auf eine Schnittstelle einigen. Da viele verschiedene Teams ggf. verschiedene Anforderungen haben, könnte diese Einigung ein Problem werden.
+
+*Eventualfallplanung:*
+
+Falls sich eine Unstimmigkeit bei der Wahl der Schnittstelle ergibt, dann bleibt keine Option, als so lange mit den anderen Teams zu kommunizieren, bis eine Einigung erzielt wird.
+
+*Risikominderung:*
+
+Um das Risiko von Unstimmigkeiten zu mindern, haben wir die Situation so gedreht, dass die anderen Gruppen unsere Ideen annehmen, statt dass wir ihre umsetzen, da so die Quelle der Idee nur eine ist, und nicht viele verschiedene. Die Schnittstelle, die wir entwerfen, muss dennoch für alle anderen Komponenten brauchbar und zu verwenden sein. Auch bleiben wir offen für Feedback, wenn wir etwas an der Grundidee unserer Schnittstelle ändern müssen.
+
+
+=== Aufteilung der Aufgaben auf 8 Leute
+
+Da keiner von uns bisher eine Software im Team mit über 5 Mitgliedern entwickelt hat, könnte sich die Aufteilung der Aufgaben auf 8 Personen als schwierig erweisen. Außerdem möchten wir vermeiden, dass Teammitglieder nur an einer Komponente der Software arbeiten und ihnen dann Kenntnis über andere Komponenten fehlt.
+
+*Eventualfallplanung:*
+
+Im schlimmsten Fall fehlen einzelnen Teammitgliedern Kenntnisse über einzelne Softwarekomponenten. In dem Fall muss nach dem Praktikum und vor der Klausur ein Teammeeting stattfinden, in dem wir uns über die Einzelteile der Software austauschen und so jeder ein Grundwissen über alle Komponenten entwickelt.
+
+*Risikominderung:*
+
+Damit jeder an jedem Teil der Software arbeiten kann und jeder eine Aufgabe hat, sprechen wir uns jeden Morgen ab, wer was an dem entsprechenden Tag in Angriff nehmen möchte. Außerdem wird Wert auf Programmieren in Paaren oder Kleingruppen gelegt, damit man Probleme gemeinsam lösen kann. Wenn jemand keine konkrete Aufgabe hat, dann setzt er sich zu bestehenden Teams dazu und arbeitet mit ihnen.
+
+
 

documentation/src/12_glossary.adoc

@@ -5,13 +5,20 @@
 
 [cols="1,2" options="header"]
 |===
-|Begriff
-|Definition
-
-|_<Begriff-1>_
-|_<Definition-1>_
-
-
-|_<Begriff-2_
-|_<Definition-2>_
+|Begriff |Definition
+|MOPS-Modul |MOPS steht für die "Modulare OrganisationsPlattform für Studenten", die ein neues Werkzeug für Studenten darstellt, mit dem ihnen verschiedenste Dienste zur Verfügung gestellt werden. MOPS ist die übergeordnete Anwendung, von der die "Gruppenbildung" ein Teil ist.
+|arc42 |arc42 ist ein Muster zum Erstellen einer guten Entwicklungsdokumentation während eines -prozesses.
+|Java 11 |Java 11 ist die 11. Version der Programmiersprache Java.
+|Framework |Ein Framework ist eine Ansammlung von Diensten, die zur Unterstützung der Entwickler dient. Durch das Verwenden eines Framworks können verschiedene Prozesse automatisiert werden, die sonst manuell durchgeführt oder implementiert werden müssten.
+|JUnit |JUnit ist ein auf Java basiertes Framework zum Schreiben von automatisierten Softwaretests.
+|Spring Framework |Spring ist ein Framework, das viele Dienste zum Aufbauen einer Software zur Verfügung stellt, wie z.B. die Automatisierung verschiedener Funktionen, die sonst per Hand implementiert werden müssten.
+|GitHub |Werkzeug zur Arbeit an Software von verschiedenen PCs aus und zur Versionskontrolle.
+|Branches und Master-Branch |Auf GitHub werden die Änderungen im Code online gespeichert. Wenn man Änderungen machen möchte, die aber nicht direkt in der endgültigen Software landen sollen, dann kann man sog. Branches erstellen, die den bestehenden Code kopieren, aber unabhängig davon bearbeitet werden. Der Haupt-Branch heißt der Master. Auf diesem liegt die endgültige Software.
+|Checkstyle und Spotbugs |Werkzeuge zum automatisierten Finden von Fehlern in Quellcode. Spotbugs findet Fehler in der Funktionalität und Checkstyle prüft die Schreibweise des Codes.
+|Continuous Integration/CI |Lässt Tests laufen, bevor Änderungen an der Software endgültig gespeichert werden können. So kann eine funktionierende Software zu jedem Zeitpunkt garantiert werden.
+|Log |Aufzeichnung der Meldungen während der Laufzeit einer Software. Darin kann man mögliche Fehler- oder Erfolgsmeldungen auslesen und so bessere Auskunft über die unsichtbaren Vorgänge innerhalb der Software erlangen.
+|Keycload |Externes Plugin, das die Authentifizierung und damit den Zugang zur Anwendung ermöglicht.
+|DTO |Data Transfer Object. Dies ist eine Vereinfachung einer Java-Instanz, die leichter innerhalb der Datenbank verwaltet werden kann.
+|Interface |Sammlung von Java-Methoden, die von Klassen implementiert werden können.
+|Queries |Zeichenketten, die in der Sprache einer Datenbank geschrieben sind und so die Kommunikation mit ihr ermöglichen.
 |===