‏ ‏ ‎ ‏ ‏ ‎

1. 2022-09-19

  • Organisatorisches

1.1. Plantuml

cld

2. 2022-10-03

2.1. Git-Grundlagen

  • centralized vcs

  • distributed vcs

2.2. Projekte (Buch)

2.2.1. Projektmerkmale

  • Routineaufgaben vs. Projekte

querschnittsaufgaben

  • Reporting (Berichtswesen)

    • Standard-Reports (wöchentlich, monatlich, …​.)

    • adhoc-Reports (aufgrund eines Ereignisses)

  • Stakeholder → Betroffenen

    • nicht die Projektdurchführenden (Programmierer und User) und Eigentümer, sondern Personen, die die Auswirkungen des Projekts verspüren

    • Stakeholder-Analyse identifiziert die Betroffenen, versucht die Auswirkungen für diese Betroffenen zu erfassen und ggf. deren Maßnahmen

  • Meilenstein beinhaltet

    • Termin (Zeitpunkt)

    • und eine inhaltliche Komponente (Was wurde gemacht)

2.2.2. Projektantrag

  • Erstellen Sie einen Projektantrag (Link im Moodle)

    • in Asciidoctor

    • Gliederung lt. Buch

3. 2022-10-10

3.1. Kreativitätstechniken

3.1.1. Mindmap

  • Freeplane

  • plantuml - mindmap

  • doc-as-code

Diagram

3.2. Projektidee - Projektantrag

3.3. Variantenbildung

  • SWOT - Analyse

3.4. Zielbestimmung

  • Ausgangssituation

  • Problemstellung

  • Aufgabenstellung

  • Ergebnis → Leistung

  • Ziel → Leistungswirkung

  • Operationalisieren s. Buch S. 53

3.4.1. Magisches Viereck

effektivität vs effizienz

  • Effektivität → Grad der Zielerreichung

  • Effizienz → Input-Output-Relation

4. 2022-10-17

Projektanträge - Übersicht
png
Projektgruppen
png

5. 2022-11-07

5.1. Projektaufträge

5.2. Klassendiagramm

  • bis Folie 3-1-19 Geltungsbereich (Scope) Attribute und Methoden

5.3. Modell

  • Vereinfachte Darstellung der Realität unter Berücksichtigung eines besonderen Aspektes

  • zB

    • Datenmodell → die Datenstrukturen werden besonders herausgearbeitet

    • Ablaufdiagramm → die zeit-logischen-Zusammenhänge werden besonders beachtet

democld

5.4. Google Java Style Guide

Google Java Style Guide

code quality

6. 2022-11-14

6.1. Klassendiagramme (Fortsetzung)

  • Signatur

democld2

6.1.1. Multiplizität

  • 2 Interpretationen

    • Anzahl der Instanzen einer Klasse

      • keine Instanzen zB Math-Klasse

      • eine Instanz → Singleton

      • mehrere Instanzen

    • Anzahl der Objekte bei einer Beziehung zB Assoziation

6.2. DOM - Domain Object Model

  • nicht zu verwechseln mit Document Object Model (Baum-Repräsentation der HTML-Seite im Browser)

  • Domain entspricht Fachbereich

    • zB Medizin, Einzelhandel, Kfz-Handel, Warenwirtschaft,…​

  • DOM ist vergleichbar mit einem ERD

    • ein Klassendiagramm ohne technische Klasse nut mit Fachbereichsklassen

6.3. Beziehungen

  • Assoziation - benutzt-Beziehung

  • Aggregation - "besteht aus" → zerstörungsfreie Zerlegung

    • zB Auto besteht aus Autoreifen

  • Komposition - "besteht aus" → zerstörende Zerlegung

    • zB Haus besteht aus Etagen

  • Vererbung

  • Realisierung (Implementierung)

  • Beziehungen

    • unidirektional

    • bidirektional

  • Multiplizität

    • 1:*

    • 1:1

    • *:*

6.3.1. Vererbung

complete vs incomplete
disjoint vs overlapping
democld3
Figure 1. Assoziative Beziehung (wird bei *:*-Beziehungen verwendet)
democld4
Figure 2. Alternative bei der Darstellung einer assoziativen Beziehung

6.4. Anwendungsfalldiagramm (Use-Case-Diagramm)

  • Dient beim Erstellen der Anforderungen als Schnittstelle zwischen Kunde und Programmierer

  • Es werden Anwendungsfälle dargestellt

    • Bsp PKW

      • Transport von Personen

      • Transport von Gütern

      • ev. Statussymbol

demo4

  • ev. Ergänzung mit

    • Tabelle und

    • Aktivitätsdiagramm

7. 2022-11-21 Erstellen von gh-pages mit Asciidoctor

7.1. Wireframe vs Mockup vs Prototyp

siehe Wireframes, Mockups und Prototypen: Was, wann und warum?

7.2. Anforderungen an Projekt-Repositories

  • Im repo-root gibt es ein README.adoc, in dem

    • ganz kurz erklärt wird, was die Aufgabenstellung (und ev. das Problem) des Projekts ist

    • sämtliche (adoc)-Dokumente aufgelistet sind

    • das .idea-Verzeichnis wird nicht committed

    • REGEL: Sämtliche Artefakte, die generiert werden, dürfen nicht im Repo gespeichert werden

7.3. Anforderungsanalyse

7.3.1. Interview

8. 2022-11-28

projekt leitfaden

  • kein technischer Overkill - besser mit Bleistift gezeichnetes Wireframe als Clickable Mockup

8.1. Pflichtenheft

8.2. Git - Branches

feature branches
Figure 3. source: Git-flow-Workflow

  • main-branch nur für releases

  • develop-branch immer lauffähig

  • feature- und bugfix-branches für entwickeln

9. 2022-12-05

10. Git - Architektur und Überblick

git overview2

10.1. V-Modell

v modell

10.1.1. Vorgehensmodelle in der Software Entwicklung

  • Grobe Unterteilung

    • Klassische Vorgehensweise

      • Wasserfallmodell

      • Spiralmodell nach Boehm

      • V-Modell

      • …​

    • Agile Vorgehensmodelle

      • Scrum

      • Kanban

11. 2022-12-19

11.1. Test 01

11.2. Scrum

12. 2023-01-09

12.1. Rückgabe Test und Besprechung

12.2. Nächste Schritte im Projekt

13. 2023-01-16

13.1. Regeln für die Projektarbeit

13.1.1. Jeder Commit ist einer User Story / Task zugeordnet

13.1.2. Arbeitszuordnung

  • Jedes Projektmitglied hat einen eigenständigen Aufgabenbereich zB einen Task.

  • Dieser Task wir in einem eigenem Branch erstellt / durchgeführt

13.1.3. Sprint Reviews / Präsentationen

  • Es darf nicht auf dem eigenen Rechner (kein grüner Pfeil in der IDE) präsentiert werden. Ein essentielles Deployment ist erforderlich.

  • Folgende Möglichkeiten

    • oravm

    • leocloud in eigenem Namespace

    • minikube

In einem laufenden Sprint wird nichts verändert. Weder Aufgaben des Sprint Backlog noch die gewählte Vorgangsweise (zB Branching)

13.1.4. git-branching

git branching

13.2. Projekthandbuch für Scrum

13.3. Dokumentation

  • Es muss eine (grobe) Systemarchitektur geben

  • Gewisse Entwurfsentscheidungen müssen dokumentiert werden

  • Eine RevealJS-Präsentation muss immer verfügbar sein

    • Problemstellung

    • Aufgabenstellung

    • derzeitiger Stand

13.4. Testen

  • Die Akzeptanzkriterien sind als Unit-Tests implementieren (wenn möglich)

  • und ist zu präsentieren

13.5. Film

  • im 5. Jg.

13.6. Plakat

13.7. Nächste Schritte im Projekt

https://github.com/1920-3ahitm-itp/02-project-repositories-studentfeedback

  • Entsprechend der Vorlage wird mit mybatis ein grundlegendes Projekt erstellt.

    • Erstellung eines plantuml-Datenmodells mit anschließender Erstellung eine sql-Files

    • Beim Starten des Projekts werden die Tabellen erstellt und Daten importiert (INSERTs)

14. 2023-01-23

14.1. Pflichtenheft

  • Ausgangssituation

  • Istzustand (IST)

    • DOM-Ist

  • Problemstellung

  • Aufgabenstellung (SOLL)

    • Funktionale Anforderungen

      • DOM-Soll

      • UCD

      • ACD

      • Wireframes

    • Nichtfunktionale Anforderungen

nfa

  • Ziele

  • Mengengerüst

  • …​

  • TODO: Wie erstelle ich eine RevealJS-Präsentation

dart feedback 2023 01 23

15. 2023-02-13

  • Bis nach den Semesterferien

    • Cld fertigstellen

    • in Java programmieren

      • Entities

      • Repositories

    • Use-Cases mit assertj-db testen

    • Konfigurieren einer gh-page im Repo laut Angabe

Für die einzelnen Aktivitäten im youtrack User Stories und tasks anlegen und bei den Commits deren Id in der Commit-Message eintragen

16. 2023-02-27

16.1. Docker

  • Docker ist leichtgewichtige Virtualisierung.

16.1.1. Warum Docker?

works on my machine

  • Man braucht eine Laufzeitumgebung, die genau definiert ist

    • Java hatte früher den Slogan "Write once, runs anywhere" (WORA)

    • Heutzutage eher "Write once, run predictable" (WORP)

  • Unterschied Developer - Operator

    • Developer: programmiert Applikationen

    • Operator: ist im Rechenzentrum; kümmert sich um das Hosting der Anwendungen, Sicherungen, etc.

    • Es gab immer Konflikte zwischen Devs und Operators

    • → jetzt gibt es DevOps

17. 2023-03-10

scrum und v modell

18. 2023-03-13

  • Leistungsfeststellung

18.1. Docker

web server

18.1.1. Hausübung

  • Erstellen eines Containers mit MariaDb

    • In einem bind mount sollen die Datenbank-Files gespeichert werden (db-Verzeichnis)

    • Das docker run - Kommando soll in einem shell-script create-db-container.sh gespeichert werden.

    • Nach Ausführen des Scripts soll der Container erstellt werden.

    • Erstellung eines Script stop-db-container.sh (der Container muss automatisch gelöscht werden)

    • Nach einem neuerlichen Start müssen die Daten wieder vorhanden sein

    • Erstellen Sie in IntelliJ eine Datenbank-Connection zu Ihrer Maria-Db

19. 2023-03-20

19.1. Package Manager (maven, gradle, …​)

  • gibt die Struktur (Verzeichnisse, Files, …​) in einem Softwareprojekt vor

  • man trägt in einer zentralen Datei (bie maven pom.xml) die Library ein

    • diese Libraries werden automatisch beim Start des Programms heruntergeladen und

    • in einem zentralen Verzeichnis gespeichert (bei maven .m2 im User-Home)

    • Dies hat den Vorteil, dass bei Verwendung einer Library in mehreren Projekten, die Library nur einmal heruntergeladen wird.

19.2. Testen von Softwareprodukten

  • jUnit

    • stellt die Funktionalität zur Verfügung, um ein Programm testen zu können

    • beim Testen werden die Ergebnisse von Methoden mit erwarteten Werten verglichen (matching)

    • falls nicht das erwartete Ergebnis geliefert wird, gibt es einen Fehler

    • als matcher kann man die Methoden von jUnit verwenden, allerdings gibt es bessere (zB hamcrest, assertj, karate ,…​)

    • wir verwenden assertj-core und assertj-db

unit tests

  • Test-Matcher

    • ein aktueller Wert wird mit einem vorgegebenen Wert verglichen.

    • in jUnit sind solche Matcher bereits eingebaut

      • assertEquals

      • assertTrue

      • assertXXX

    • Es gibt aber auch alternative Matcher

    • Vorteile von alternativen Matcher

20. 2023-03-20

20.1. Activity Diagrams

21. 2023-04-17

21.1. assertj-Tipps

assertj using recursive comparison
assertj satiesfies

21.2. Übung Dockerfile

21.3. Übung Youtrack für das eigene Projekt

  • Erstellen Sie im Product-Backlog mehrere UserStories und Tasks für eine, max. 2 User Stories

  • Verschieben Sie diese 2 User Stories mit ihren Tasks in das Sprint-Backlog

  • Führen Sie nun die in den Tasks angeführten Aufgaben durch und "verbinden" sie die Commits mit den jeweiligen Tasks (Issues)

21.4. Testen

21.4.1. Was testet man?

Teststrategien

  • bei Datenbanken

    • CRUD-Funktionalität

      • CREATE - Erstellen eines Datensatzen einer Entity Klasse in der Entity-Table

      • READ - Lesen eines Datensatzes und erstellen des zugehörigen Java - Objekts

      • UPDATE - Ändern eines Java - Objekts und diese Änderungen werden in der zugehörigen DB-Tabelle gespeichert

      • DELETE - Löschen eines Java - Objekts mit dazugehörogem Löschen in der Datenbank

        Man beginnt mit den Stammdaten (ohne Abhängigkeiten zu anderen Tabelle)

      • Bsp:

        • Nicht Zimmer, sondern Hotel als erste Klasse testen

    • Transaktionen nicht vergessen

  • User Stories (Use-Cases, Anwendungsfälle) testen

    • zB Reise buchen

    • zB Reise stornieren

  • Grenzwertanalyse - Grenzwerte werden getestet

    • zB Alter von 450 Jahen bei Personen - wie reagiert das System

    • Alter von -10 Jahren

  • Äquivalenzklassenanalyse → Äquivalenzklassen identifizieren und aus jeder Klasse einen Wert testen und die Grenzen dieser Klasse

    • Bsp: Eintrittspeise: Kinder frei, Jugendliche 5 €, Erwachsene 50 €, Pensionisten 20€

      • Sind drei Äquivalenzklassen (alle Eingabewerte innerhalb einer solchen Klasse ergebn des selben Ausgabewert)

      • Bsp: Kind mit 3J → gratis

      • Kind mit 5 J → gratis

  • Exceptions testen

21.4.2. Naming der Tests

The name of your test should consist of three parts:

  • The name of the method being tested.

  • The scenario under which it’s being tested.

  • The expected behavior when the scenario is invoked

22. 2023-04-17

22.1. Docker build

23. 2023-04-24

23.1. Projekt-Feedback

23.1.1. Testen

  • Tests müssen voneinander unabhängig sein

23.2. docker-compose Einführung

24. 2023-05-15

24.1. docker-compose

https://htl-leonding-college.github.io/docker-lecture-notes/docker-compose.html

24.1.1. Übung docker-compose

  • erstellen Sie ein File docker-compose.yaml welches folgende Dienste beinhaltet

    • Service backend

      • beinhalted eine nodejs-express-Anwendung

      • greift auf eine mariadb zu

    • Service db

      • wird vom Service backend benutzt

    • Service phpmyadmin

    • Netzwerk my-network mit ip 10.0.2.0/24

  • erstellen Sie ein asciidoc-File, dass direkt die source-Files (docker-compose.yaml) in das sciidoc-File included.

    • Es darf nicht das gesamte File auf einmal inkludiert werden, sondern nur die einzelnen Teile hintereinander

    • verwenden Sie keyb-Macros

    • Achten Sie auf eine saubere Präambel und allgemein ein sauberes Asciidoc-File

  • Abgabe: siehe moodle

25. 2023-05-22

25.1. Commits