# SDD Überarbeiten

## 1. Nachricht an Till Niese

Beispielnachricht:

### v3

Hallo Till,

vielen Dank für dein Feedback. Wir haben das Sequenzdiagramm entsprechend deinem Feedback überarbeitet und uns dazu besprochen. Dabei ist uns noch eine Frage aufgekommen:

Wird von uns erwartet für jeden Use-Case bzw jedes UML Diagramm des SDD ein eigenständiges Sequenzdiagramm zu erstellen mit jeweiligen Ablauf des Edge-Cases?
Dies erschien uns nicht klar, da im Beispieldokument auch nur ein Sequenzdiagramm (und dies auch sehr generisch gehalten) dargestellt ist. Wie viel Zeit hätten wir dafür noch?

Bezüglich der Funktionsrückgabewerte hast du einen sehr guten Punkt. Um die Aussagekraft und Flexibilität der Rückgabewerte zu verbessern haben wir haben uns entschieden statt booleans und Strings, Error-codes zu verwenden. Wenn bei einer User-Interaktion etwas schiefgeht über das der User bescheid wissen sollten, können diese Error-Codes dann im GUI Objekt verarbeitet werden um dem Benutzer spezifisches Fehlerfeedback zu präsentieren.

Wir haben auch die Interfaces komplett aus dem Diagram gestrichen. Stattdessen beziehen wir uns nun nur noch auf die Objekte, welche die Interfaces bereitstellen. Dadurch sollte das Diagram lesbarer und aussagekräftiger sein.

Das überarbeitete Sequenzdiagramm findest du im Anhang.

### v2

(Du oder Sie ?)
- N: Ich wär für du

Hallo Till,

vielen Dank für dein Feedback. Wir haben uns dazu besprochen und es sind noch ein paar Fragen aufgekommen:

Wird von uns erwartet für jeden Use-Case bzw jedes UML Diagramm des SDD ein eigenständiges Sequenzdiagramm zu erstellen mit jeweiligen Ablauf des Edge-Cases?
Dies erschien uns nicht klar, da im Beispieldokument auch nur ein Sequenzdiagramm (und dies auch sehr generisch gehalten) dargestellt ist.

Bezüglich der Funktionsrückgabewerte hast du einen sehr guten Punkt. Um die Aussagekraft und Flexibilität der Rückgabewerte zu verbessern haben wir haben uns entschieden statt booleans und Strings, Error-codes zu verwenden. Wenn bei einer User-Interaktion etwas schiefgeht über das der User bescheid wissen sollten, können diese Error-Codes dann im GUI Objekt verarbeitet werden um dem Benutzer spezifisches Fehlerfeedback zu präsentieren.

Wir haben auch die Interfaces komplett aus dem Diagram gestrichen. Stattdessen beziehen wir uns nun nur noch auf die Objekte, welche die Interfaces bereitstellen. Dadurch sollte das Diagram lesbarer und aussagekräftiger sein.

Im folgenden haben wir ein überarbeitetes Sequenzdiagramm hinzugefügt. Ist dies so in Ordnung?

### v1
(So halb)
Dies bezieht sich auf dein Feedback bezüglich der Function-Returns und der 'Alt'-Statement in den Sequenzdiagrammen. Wir haben uns entschieden an vielen stellen Error-codes als Funktionsrückgabewerte zu verwenden. Wenn bei einer User-Interaktion etwas schiefgeht über das der User bescheid wissen sollten, sollen diese Error-Codes dann im GUI Objekt 'übersetzt' werden um dem Benutzer individuelles Fehlerfeedback zu präsentieren. Im folgenden haben wir ein überarbeitetes Sequenzdiagramm hinzugefügt. Ist dies so in Ordnung?

### __Fragen__
- [x] Umfang - Für was alles sollen wir Sequenzdiagram machen?
- [x] Für alle use cases??
- [x] Umfang vllt. bissle runterhandeln
- [x] Hatten wir irgend eine möglichkeit zu wissen, dass wir Sequenzdiagramme in diesem Detailgrad und zu so vielen Sachen machen mussten?
- [x] Im Example wars doch auch so wie wir's orginal gemacht hatten (Nur eines und relativ allgemein gehalten)
- [x] ~~((Wir hatten Sequenzdiagramme zu dem Zeitpunkt noch nicht in SE))~~ [Weiß nicht ob das stimmt]

`TODO:?`

### __Auf seine Kritikpunkte eingehen / unsere Entscheidungen im Sequenzdiagramm begründen__

#### Kritikpunkt 1
- Result string / result boolean sind zu generic → We should use "alt" instead

Unsere Rechtfertigung:
- [x] Wir brauchen kein alt ausser im GUI Objekt, weil unser Plan ist: Wir benutzen ErrorCodes als Rückgabewerte von Funktionen die Fehlschlagen, (z.B. durch invalide Eingaben vom Benutzer). Im Fall von dem Sequenzdiagram was wir ihm geschickt haben würde das GUI Objekt ein Array von ErrorCodes zurückbekommen, und dann selbst entscheiden, was es mit den Error Codes macht. (z.B. ein die TextBox rot färben und "Passwort zu kurz" hinschreiben oder so.)
- [x] Bei den Rückgabewerten der Validators, hat er einen guten Punkt. Booleans sind wahrscheinlich nicht ausdrucksstark genug, deshalb haben wir uns entschieden nun auch ErrorCodes als Rückgabewerte zu verwenden. Diese liefern Informationen darüber, wieso eine bestimmte Eingabe invalide ist. (z.B. gäbe es dann verschiedene ErrorCodes für "Email addresse nicht vergeben", "Invalide email addresse", "Passwort zu kurz", "Passwort zu einfach", "Leeres Eingabefeld", etc.)

`TODO:?`

Kritik umsetzten:
- [x] Vllt. sollten wir ins Diagram in der GUI Objekt Lifeline ein "alt" Dings einbauen, dort wo es den function return bekommt
`Brauchen wir wirklich ein 'alt' im GUI Objekt Lifeline oder reicht ein neuer 'Balken'/Prozess der den erhaltenen Status code auf die Response mappt?`

`Das macht voll Sinn danke für den Hinweis 👍👍` `..Ich habs doch mit alt gemacht, hat irgendwie Sinn gemacht. Das ergebnis ist` [hier](https://gitlab.inf.uni-konstanz.de/inf-12160/group-11/-/blob/master/SDD%20Document/DRAWIO/sequence-diagrams/seqDia_Login_v3.png).

`TODO:Noah`

- [x] ~~Vllt. ist StatusCode ein treffenderer Name als ErrorCode, aber das müssten wir nochmal in allen Class Diagrams ändern, dafür bin ich zu faul deshalb würde ich es jetzt so lassen~~
- [x] Anstatt String returns, ArrayList<ErrorCode> returns
`DONE:Felix`
- [x] Anstatt boolean returns, ErrorCode returns
`DONE:Felix`

- [ ] Auch in den Class Diagrams bei `FirebaseBackend::Validators::Validators` updaten - Anstatt boolean returns, ErrorCode returns

:::info
__Als Referenz zu den Sequenz Diagrams hat er geschrieben:__ (Wie er sich das mit "alt" vorstellt, etc.)
Please refer to the slides of the Software Engineering course "Part 2: Requirements and Analysis" in the section "Use Case Diagrams and Sequence Diagrams"
:::

#### Kritikpunkt 2

* Should we group BackendFacadeMobileApp, MobileAppManangmentInterface, MobileAppManagment, and maybe also BackendFacadeForMobileAppInterface into a parent component to avoid redundancy

Unsere Rechtfertigung:
- [x] Bei Redundancy von Interfaces hat er einen guten Punkt, wir haben uns entschieden, die InterfaceObjekte aus dem Sequenzdiagramm wegzulassen, da diese ja garkeine eigenständigen Objekte darstellen [glaube ich] sondern nur Interaktionsmethoden mit einem Objekt deklarieren. Deshalb schreiben wir jetzt nur noch die Objekte hin zwischen denen tatsächlich Kommunikation stattfindet
- [x] ~~Wir haben uns entschieden, im Backend zwei verschieden Objekte die Speziell für die Verarbeitung von eingehender Kommunikation existieren zu erstellen. Diese sind BackendFacadeForMobileApp, und BackendFacadeForWebApp. Intern sind die Fun...~~ [Weiß nicht wie ich das formulieren soll und nicht so wichtig]

`TODO:?`

Kritik umsetzten:
- [x] Interfaces Rausstreichen

`DONE:Felix`

# 2. Sequenzdiagramme erstellen

...