1 changed files with 211 additions and 112 deletions
-
323Lerntagebuch.md
@ -1,169 +1,268 @@ |
|||||
## Lerntagebuch |
## Lerntagebuch |
||||
### Übung 1 2.11.2022 |
|
||||
|
|
||||
### Lernziel |
|
||||
|
# Mein Lerntagebuch für Programmiermethoden und -werkzeuge |
||||
|
Das ist ein Beispiel wie ein Lerntagebuch aussehen könnte. |
||||
|
|
||||
|
## SU 01(21.10.2021) |
||||
|
### Lernziel |
||||
|
- Organisatorisches |
||||
|
- Versionskontrollsysteme allgemein |
||||
|
- git |
||||
|
- Vorteile |
||||
|
- wie lege ich ein Repository an |
||||
|
- vim (ein paar alltägliche Befehle) |
||||
|
|
||||
|
### Erkenntnis |
||||
|
Versionskontrolle werden wir im Projekt einsetzen, um |
||||
|
zu jeder Zeit den Entwicklungsstand einzusehen und paralleles Arbeiten an Dateien zu ermöglichen. Sollten Probleme an der Software auftreten, können wir zu einem funktionierenden Stand wechseln und durch das Commit-Log die Ursache ausfindig machen. |
||||
|
Außerdem kann ich als Developer mit den gelernten vim-Befehlen vor den anderen flexen. |
||||
|
|
||||
|
### Kritik |
||||
|
`git status` zeigt mir einen groben Zustand meines Git-Repositorys an. Manchmal werden Dateien oder Verzeichnisse dort rot oder grün angezeigt. Die grünen |
||||
|
Dateien verschwinden von der Ausgabe, wenn ich `git commit` |
||||
|
ausführe. Rote Dateien werden mit `git add` grün. |
||||
|
|
||||
|
### Mitteilung |
||||
|
an die Dozierenden Da dieser Punkt optional ist, lasse ich ihn |
||||
|
weg. Aber wenn mich irgendwas stört oder begeistert, kann ich es |
||||
|
hier anmerken. |
||||
|
|
||||
|
## Uebung 01 (27.10.2022) |
||||
|
### Lernziel |
||||
|
- SSH-Zugriff-zum-git-server-konfigurieren |
||||
|
- SSH key pair generieren |
||||
|
- oeffentlichen SSH key im Repository eintragen |
||||
|
- Lokale Kopie auf SSh-Zugriff umstellen |
||||
|
- Neue lokale Repositories |
||||
|
|
||||
|
### Erkenntnis |
||||
|
- einen ssh-key erstellt |
||||
|
- öffentlichen Schlüssel zu gogs hinzugefügt |
||||
|
- Master Branch erstellt |
||||
|
|
||||
|
### kritik |
||||
|
man muss die git-Konfigurationsdatei überprüfen und den url-Link in gitea/gogs SSH-Remote-Repository-Link ändern. |
||||
|
|
||||
|
### Mitteilung |
||||
|
|
||||
|
|
||||
|
|
||||
#### Übung 2 7.11.2022 |
|
||||
|
## Übung 02 (2.11.2022) |
||||
|
### Lernziel |
||||
|
- legen Sie in Ihrem Repository die Datei Programmierparadigmen.md an. |
||||
|
- Analysieren Sie die Programmiersprachen Java,C,Python,go,JavaScript und TypeScript hinsichtlich der in der Vorlesung genannten Kriterien und Schreiben sie ihre Analyse in Stichpunkten in die neu erstellte datei. |
||||
|
- Suchen Sie im Internet nach weiteren Programmierprinzipien und dokumentieren sie diese (Acronym, Langbezeichnung, Beschreibung) in der Obigen Datei. |
||||
|
|
||||
|
### Erkenntnis |
||||
|
Ein neu Datei als Programmierparadigmen.md an Gitea hochgeladet. |
||||
|
|
||||
einen ssh-key erstellt |
|
||||
öffentlichen Schlüssel zu gogs hinzugefügt |
|
||||
Branch erstellt |
|
||||
|
### Kritik |
||||
|
Programmierprinzipien |
||||
|
- SOLID |
||||
|
- STUPID |
||||
|
- KISS (Keep It Simple & Stupid) |
||||
|
- FCoH (Favor Composition over Inheritance) |
||||
|
- YAGNI (You Ain't Gonna Need It) |
||||
|
- IOC (Inversion Of Control) |
||||
|
- DI (Dependency Injection) |
||||
|
- DRY (Don't Repeat Yourself) |
||||
|
- DYC (Document Your Code) |
||||
|
- Clean Code at All Cost |
||||
|
|
||||
### Übung Debugging 16.11.2022 |
|
||||
#### Übung 3 |
|
||||
|
### Mitteilung |
||||
|
|
||||
clone link https://gogs.informatik.hs-fulda.de/Programmiermethoden_und_werkzeuge-public/UebungDebugging.git |
|
||||
|
|
||||
**Task 1 Uebung 1** |
|
||||
- Nachdem Aktivieren Sie die Zeilen 36 bis 38 durch entfernen der beiden *slashes*. |
|
||||
**Ausgaben sind:** |
|
||||
enter an integer number: 5 |
|
||||
- input: 5, Schleifenvariable: 2, Ergebnis 1 |
|
||||
- input: 5, Schleifenvariable: 3, Ergebnis 2 |
|
||||
- input: 5, Schleifenvariable: 4, Ergebnis 1 |
|
||||
- number 5 passed check: true% |
|
||||
|
## SU 1(datum) |
||||
|
### Lernziel |
||||
|
|
||||
enter an integer number: 34 |
|
||||
- input: 34, Schleifenvariable: 2, Ergebnis 0 |
|
||||
- number 34 passed check: false% |
|
||||
|
### Erkenntnis |
||||
|
### Kritik |
||||
|
|
||||
enter an integer number: 89 |
|
||||
- nachdem schleifen es gibt |
|
||||
- number 89 passed check: true% |
|
||||
|
### Mitteilung |
||||
|
|
||||
Nachdem einen Breakpoint an ziele 35 und zahl 45 eingeben es gibt |
|
||||
- die Inhalte der Variablen sind nextInt: 45, i:2, ergebnis:1 |
|
||||
|
## Übung 3 (16.11.2022) |
||||
|
|
||||
Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47 |
|
||||
- die Inhalte der Variablen sind nextInt: 47, i:2, ergebnis:1 dann nextInt: 47, i:3, ergebnis:2 |
|
||||
- am ende nextInt: 47, i:46 Ergebnis:1 check: true |
|
||||
|
clone link https://gogs.informatik.hs-fulda.de/Programmiermethoden_und_werkzeuge-public/UebungDebugging.git |
||||
|
|
||||
**Task 2 Uebung 2** |
|
||||
|
### Lernziel |
||||
|
- Führen Sie die Übung entsprechend den Anweisungen in der README.md-Datei aus. |
||||
|
- Debugging |
||||
|
|
||||
|
### Erkenntnis |
||||
|
**Task 1 Uebung 1** |
||||
|
- Nachdem Aktivieren Sie die Zeilen 36 bis 38 durch entfernen der beiden *slashes*. |
||||
|
**Ausgaben sind:** |
||||
|
enter an integer number: 5 |
||||
|
- input: 5, Schleifenvariable: 2, Ergebnis 1 |
||||
|
- input: 5, Schleifenvariable: 3, Ergebnis 2 |
||||
|
- input: 5, Schleifenvariable: 4, Ergebnis 1 |
||||
|
- number 5 passed check: true% |
||||
|
|
||||
Öffnen Sie das programm `Uebung2.java` im Editor |
|
||||
- Starten Sie das Programm mehrfach (*"run as Java Application"*) und geben Sie verschiedenen natürliche Zahlen ein. |
|
||||
|
enter an integer number: 34 |
||||
|
- input: 34, Schleifenvariable: 2, Ergebnis 0 |
||||
|
- number 34 passed check: false% |
||||
|
|
||||
- **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt** |
|
||||
|
enter an integer number: 89 |
||||
|
- nachdem schleifen es gibt |
||||
|
- number 89 passed check: true% |
||||
|
|
||||
|
Nachdem einen Breakpoint an ziele 35 und zahl 45 eingeben es gibt |
||||
|
- die Inhalte der Variablen sind nextInt: 45, i:2, ergebnis:1 |
||||
|
|
||||
- setzen Sie einen BreakPoint in Zeile 40 |
|
||||
- Starten Sie das Programm wie bisher |
|
||||
- Starten Sie das Programm im Debug-Modus und geben Sie die Zahl 45 ein |
|
||||
- Notieren Sie die Inhalte der Variablen (this) nextInt: 23 |
|
||||
- this: **Uebung2@8** |
|
||||
- count: **3** |
|
||||
- Notieren Sie die Anzahl der Einträge in der *Debug View* (this): **this, count, in, out in total 4 mit Zwischenüberschritt** |
|
||||
|
Nochmal lauft das Programm im Debug-modes und eingeben zahl ist 47 |
||||
|
- die Inhalte der Variablen sind nextInt: 47, i:2, ergebnis:1 dann nextInt: 47, i:3, ergebnis:2 |
||||
|
- am ende nextInt: 47, i:46 Ergebnis:1 check: true |
||||
|
|
||||
- in welcher Zeile steht der Debugger? 34->36 |
|
||||
- Notieren Sie die Anzahl der Einträge in der *Debug View* (this) |
|
||||
- nextInt: **45**, count: **2** |
|
||||
|
**Task 2 Uebung 2** |
||||
|
|
||||
|
Öffnen Sie das programm `Uebung2.java` im Editor |
||||
|
- Starten Sie das Programm mehrfach (*"run as Java Application"*) und geben Sie verschiedenen natürliche Zahlen ein. |
||||
|
|
||||
- in welcher Zeile steht der Debugger? **40** |
|
||||
- Notieren Sie die Anzahl der Einträge in der *Debug View* (this) false |
|
||||
- nextInt: **16**, count: **4** ergebnis: **false** |
|
||||
|
- **natürliche zahlen sind 45, 14, 89 ergebnis sind False ingesamt** |
||||
|
|
||||
**Beenden Sie den Debugger (*"Terminate"*)** |
|
||||
|
|
||||
### Uebung 4 23.11.2022 |
|
||||
|
- setzen Sie einen BreakPoint in Zeile 40 |
||||
|
- Starten Sie das Programm wie bisher |
||||
|
- Starten Sie das Programm im Debug-Modus und geben Sie die Zahl 45 ein |
||||
|
- Notieren Sie die Inhalte der Variablen (this) nextInt: 23 |
||||
|
- this: **Uebung2@8** |
||||
|
- count: **3** |
||||
|
- Notieren Sie die Anzahl der Einträge in der *Debug View* (this): **this, count, in, out in total 4 mit Zwischenüberschritt** |
||||
|
|
||||
#### Source Code Management (SCM) |
|
||||
|
- in welcher Zeile steht der Debugger? 34->36 |
||||
|
- Notieren Sie die Anzahl der Einträge in der *Debug View* (this) |
||||
|
- nextInt: **45**, count: **2** |
||||
|
- in welcher Zeile steht der Debugger? **40** |
||||
|
- Notieren Sie die Anzahl der Einträge in der *Debug View* (this) false |
||||
|
- nextInt: **16**, count: **4** ergebnis: **false** |
||||
|
|
||||
**Lokale Respository** |
|
||||
1.1 Stage und Historic |
|
||||
1.2 Merge |
|
||||
1.3 rebase |
|
||||
|
**Beenden Sie den Debugger (*"Terminate"*)** |
||||
|
|
||||
|
### Kritik |
||||
|
|
||||
|
### Mitteilung |
||||
|
|
||||
**Git Respositoty changes** |
|
||||
|
|
||||
#### Vorlesung 07.12.2022 |
|
||||
|
|
||||
##### Test |
|
||||
|
|
||||
|
|
||||
|
|
||||
|
|
||||
**Testmethodoligie - Bestandteile eine Tests** |
|
||||
|
### Uebung 4 23.11.2022 |
||||
|
|
||||
- Stichprobe |
|
||||
- Testfälle |
|
||||
- Testdaten |
|
||||
- Testobekt |
|
||||
- Testumgebung |
|
||||
- Testziel |
|
||||
- Soll-/Ist- Wertvergliech |
|
||||
|
#### Source Code Management (SCM) |
||||
|
|
||||
**Testziele** |
|
||||
|
**Lokale Respository** |
||||
|
1.1 Stage und Historic |
||||
|
1.2 Merge |
||||
|
1.3 rebase |
||||
|
|
||||
- Fehler aufzeigen |
|
||||
- Qualität erfassen |
|
||||
- Vertrauen erhöhen |
|
||||
- Grenzen ermitteln |
|
||||
|
|
||||
**Testebenen** |
|
||||
|
|
||||
- Anwendung/System |
|
||||
- Teilsystem/Modul |
|
||||
- Codeebene/Unit |
|
||||
|
**Git Respositoty changes** |
||||
|
|
||||
**Testpyramide** |
|
||||
|
|
||||
- GUI Tests (end to end tests) |
|
||||
business logik überprufen, functions und kommiunikation mit anderen components überprufen. |
|
||||
- Integration tests |
|
||||
|
|
||||
- Component / Contract Tests |
|
||||
- Unit Tests |
|
||||
|
### Erkenntnis |
||||
|
|
||||
**Testnamen** |
|
||||
|
### kritik |
||||
|
|
||||
Test werden benannt nach: |
|
||||
- Ziel (Integration Test, Lasttest) |
|
||||
- Methode (Regressionstest) |
|
||||
- Testgegenstand (UI-test, Module-test, Unit-test) |
|
||||
- Level (Systemtest) |
|
||||
- Personen (Entwicklertest, Anwendertest) |
|
||||
- Testabdeckung (Komplettest, partieller Test) |
|
||||
|
### Mitteilung |
||||
|
|
||||
**Qualitätskosten** |
|
||||
|
|
||||
- High Cost -> Poor Quality -> Failure Costs |
|
||||
- High Cost -> Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost) |
|
||||
- Low Cost -> Exceptional Quality -> prevention & Appraisal Cost |
|
||||
|
|
||||
|
## SU 07 (07.12.2022) |
||||
|
|
||||
**Testprozess** |
|
||||
|
### Lernziel |
||||
|
- Relvante Literatur |
||||
|
- Motivation |
||||
|
- Grundlagen |
||||
|
- Testmethodologie |
||||
|
- TestProzess |
||||
|
- Psychologische Aspekte |
||||
|
|
||||
|
### Erkenntnis |
||||
|
**Testmethodoligie - Bestandteile eine Tests** |
||||
|
|
||||
**Testprozess - Ablauf** |
|
||||
|
- Stichprobe |
||||
|
- Testfälle |
||||
|
- Testdaten |
||||
|
- Testobekt |
||||
|
- Testumgebung |
||||
|
- Testziel |
||||
|
- Soll-/Ist- Wertvergliech |
||||
|
|
||||
|
**Testziele** |
||||
|
|
||||
**Testprozess - Plannung** |
|
||||
|
- Fehler aufzeigen |
||||
|
- Qualität erfassen |
||||
|
- Vertrauen erhöhen |
||||
|
- Grenzen ermitteln |
||||
|
|
||||
**Testprozess - Analyse & design** |
|
||||
|
**Testebenen** |
||||
|
|
||||
- basiert auf Anforderungsdokumentation |
|
||||
- Testspezifikation |
|
||||
- Testfaelle |
|
||||
- Kritikalitaet |
|
||||
- Testdaten |
|
||||
- Testumgebung |
|
||||
- Ausfuehrungsreihenfolge |
|
||||
- Infrastruktur |
|
||||
- Testkriterium |
|
||||
|
- Anwendung/System |
||||
|
- Teilsystem/Modul |
||||
|
- Codeebene/Unit |
||||
|
|
||||
|
**Testpyramide** |
||||
|
|
||||
|
- GUI Tests (end to end tests) |
||||
|
business logik überprufen, functions und kommiunikation mit anderen components überprufen. |
||||
|
- Integration tests |
||||
|
|
||||
|
- Component / Contract Tests |
||||
|
- Unit Tests |
||||
|
|
||||
|
**Testnamen** |
||||
|
|
||||
|
Test werden benannt nach: |
||||
|
- Ziel (Integration Test, Lasttest) |
||||
|
- Methode (Regressionstest) |
||||
|
- Testgegenstand (UI-test, Module-test, Unit-test) |
||||
|
- Level (Systemtest) |
||||
|
- Personen (Entwicklertest, Anwendertest) |
||||
|
- Testabdeckung (Komplettest, partieller Test) |
||||
|
|
||||
|
**Qualitätskosten** |
||||
|
|
||||
|
- High Cost -> Poor Quality -> Failure Costs |
||||
|
- High Cost -> Exceptional Quality -> Sweet Spot (prevention & Appraisal Cost) |
||||
|
- Low Cost -> Exceptional Quality -> prevention & Appraisal Cost |
||||
|
|
||||
|
|
||||
|
**Testprozess** |
||||
|
|
||||
|
**Testprozess - Ablauf** |
||||
|
|
||||
**Testprozess - Testausfuerung** |
|
||||
|
|
||||
Testlog |
|
||||
- aufgetretenes Fehlverhalten |
|
||||
- Fehlerkategorie (high/medium/low) |
|
||||
|
**Testprozess - Plannung** |
||||
|
|
||||
|
**Testprozess - Analyse & design** |
||||
|
|
||||
**Testprozess - Testnachbereitung** |
|
||||
|
- basiert auf Anforderungsdokumentation |
||||
|
- Testspezifikation |
||||
|
- Testfaelle |
||||
|
- Kritikalitaet |
||||
|
- Testdaten |
||||
|
- Testumgebung |
||||
|
- Ausfuehrungsreihenfolge |
||||
|
- Infrastruktur |
||||
|
- Testkriterium |
||||
|
|
||||
- Testreport |
|
||||
- Zusammenfassung Testausfuehrungen |
|
||||
- Vergleich mit frueheren Testlaeufen |
|
||||
- Entscheidung ueber Lieferfaehigkeit |
|
||||
|
**Testprozess - Testausfuerung** |
||||
|
|
||||
|
Testlog |
||||
|
- aufgetretenes Fehlverhalten |
||||
|
- Fehlerkategorie (high/medium/low) |
||||
|
|
||||
|
**Testprozess - Testnachbereitung** |
||||
|
|
||||
|
- Testreport |
||||
|
- Zusammenfassung Testausfuehrungen |
||||
|
- Vergleich mit frueheren Testlaeufen |
||||
|
- Entscheidung ueber Lieferfaehigkeit |
||||
|
|
||||
|
### kritik |
||||
|
|
||||
|
### Mitteilung |
||||
Write
Preview
Loading…
Cancel
Save
Reference in new issue