Lecture Notes 4ahitm ITP 20/21

students notes

1. Fragen

Warum bezeichnet man Scrum und ähnliche Vorgehensmodelle als agil?
Antwort
- Durch die kleinteilige Erstellung des Softwaresystems, kann man auf geänderte Rahmenbedingungen im Projektverlauf reagieren.
- Die Funktionalität von Individualsoftware kann früh(er) beurteilt werden. zB besonders wichtig bei Erweiterung von bestehenden (komplizierten) Systemen
Unterschied FA - NFA + Beispiele

2. What to do

Projektthema bestimmen
Pflichtenheft erstellen

3. 2020-09-24

3.1. Anforderungen an Projekte / Curriculum

https://htl-leonding-college.github.io/syp-itp-lecture-notes/sypitp4.html

3.2. Architektur von db-basierten Projekten

architecture projects

3.3. Projekte

Details

Europäische Urwaldroute
- Adrian
- Silvio
- Jakob m/4
Leonie
- Jonas littleCity
- Basti Langhaar
- Jonas Nr 3
- Nina
- der Bär
Rocketman → Prof. B. Ernecker
- Sarah mit Haube
- Synchronsprecher
Dünnschichtchromatogramm → Prof. B. Ernecker
- n/a
School-IoT "The appealing classroom"
- Jonas Känga
- Phil
- Quirinus
LeoSchool → derzeit Diplomarbeit
- LeoDatabaseLearner
  - Primerl
  - Isabel
  - Marah
- LeoSurvey
- LeoCode
LeoTurnier
- Rosi
- Kelly
- Sandy
DigitalSignage - On-Demand Videos
- Meris
- Airy Jakob
- Blondie123
DigitalSignage - AlertMessenger
- 11 Simon Langhaar
- Florian aus St. Florian
openMower-Projekt

Project School-Iot Details

Analyse des Istzustandes
Erstellung des Gesamtkonzepts
Detaillierung des Projektumfangs
…

Project DigitalSignage Details

ds_cms: Digital Signage Server mit Restful Endpoint
server: quarkus (ev. nodejs) bereitet die REST-Endpoints für den Angular Client vor
angular_client:
- On-Demand Video: Berechtigte Personen können aus einer Video-Library auf beliebigen Screens Videos abspielen. Das momentane Programm wird überblendet.
- AlertMessenger Berechtigte Personen (Sekretariat, AV, Dir, Schulwart) können (wichtige) Nachrichten auf beliebigen Screens für eine beliebige Zeitdauer (jjjj-mm-dd hh:mm VON - BIS). Die Nachricht kann in einem online HTML-Editor formatiert werden. Automatisch wird darunter klein angegeben, wer die Nachricht geschalten hat.

3.4. Unterricht

Foliensatz 01_Vorgehensmodelle begonnen (bis V-Modell)

3.5. Projekte

3.5.1. Project Proposal (Projektantrag)

4. 2020-10-09

4.1. Git Grundlagen

5. Feedback Projektauftrag

5.1. Digital Signage

Beim Projekt ist das out-Verzeichnis im Repo eingecheckt
- out ist das Gegenstück zu target nur für Ant → maven ist obligatorisch!
- out wurde generiert und darf NICHT in ein Repo eingcheckt werden !!!

5.1.1. ad Problemstellung

Es wird im Zuge eines ITP - Projekts eine Oberfläche für einen Touchscreen erstellt, bei dem es aber keine Möglichkeit gibt den Inhalt auf einem Smartphone zu verwalten.

Habt Ihr jetzt ein anderes Projekt?
Diese Problemstellung kenne ich nicht
Welcher Touchscreen?

Bei der Problemstellung darf die Lösung nicht enthalten sein.

5.1.2. ad Aufgabenstellung

In Kooperation mit dem anderen DigitalSignage Team wird das Backend für unsere Anwendungen programmiert. Unser Team erstellt zusätzlich noch eine Swift - Applikation von der aus die ganze Oberfläche des Touchscreens verwaltet werden kann.

Bis jetzt, weiß man noch nicht was das Problem ist,
was eigentlich erstellt werden soll,
aber es wird auf ein ominöses zweites Team verwiesen (das es wahrscheinlich gar nicht mehr gibt)
Es wird ein Swift Anwendung zusätzlich zu was programmiert?

5.1.3. ad Funktionalität

Ein Benutzer kann sich auf der Applikation einloggen.

Berechtigte Benutzer können dann von der App aus den Inhalt der Oberfläche "ferngesteuert" verwalten. (Videos abspielen, pausieren, etc.)

Einloggen ist kein Use-Case
Der zweite Use-Case ist ok

5.1.4. Restliche Kapitel

Sind leer
Besonders das Projektergebnis wäre wichtig (wurde bereits in der Problemstellung erstellt)
Eure Projektphasen sind ebenfalls hochinteressant
- Aufbau eines lokalen Xibo-Servers
- Lernen der Grundfunktionen von Xibo
- Marktanalyse
  - Welche Möglichkeiten zur Authentifizierung gibt es?
- Analyse der Xibo-Rest-Schnittstelle
  - Erster Zugriff auf Xibo mittels Insomnia oder Postman
  - Erstellen eines ersten einfachen Quarkus-Prototypen
- …

Leider wird im Repo (rechts oben) oder im README.md nicht der URL der gh-pages angegeben

https://2021-4ahitm-itp.github.io/01-project-proposal-digitalsignage-application/

Eure Klarnamen müssen / sollten nicht im Internet publiziert werden

Folgende Fragen müssen beantwortet werden:

Wieso hat nur ein Teamitglied committed?
Ist das Projektteam überfordert (→ Ja)
Sollte das Projektteam nicht besser ein einfacheres Thema nehmen?
Sollte man das Projektteam nicht auf andere Teams aufteilen?

5.1.5. Beurteilung

Obwohl in diesem Dokument weiter oben (Project School-Iot Details) das Projekt bereits besprochen wurde, ist dies das Ergebnis

→ ngd (5)

5.2. European Primeval Forest Route

5.2.1. Allgemeine Anmerkungen

keine generierten Verzeichnisse comitten
- .asciidoctor wurde eingecheckt
- nicht einfach "alles" comitten !!!
Es gibt zwei Branches für die gh-pages
- doc
- gh-pages
- In den gh-pages wird nichts angezeigt
Man muss im Projekt das File mit dem Projektauftrag erst suchen
- das ist auch der Grund, warum man in den gh-pages "nichts" findet (das Unter-Unterverzeichnis wird nicht gerendert)
- Das ganze Projekt ist "Kraut und Rüben"

forest directory structure

Rechtschreibfehler

5.2.2. ad Problemstellung

In der Vergangenheit kam es öfters vor, dass durch motivierte Wanderer die Vegetation verschmutzt und zerstört wurde, indem sie unmakierte/unoffizielle Wege nahmen. Um die Tiere und Organismen in solchen Gebieten in Zukunft zu schützen wird eine Software entwickelt.

In der Problemstellung hat die Lösung nichts verloren.

5.2.3. ad Was kann das Softwareprodukt nicht?

Was soll das bedeuten?

forest 01

5.2.4. ad Projektphasen

zuwenige Phasen angeführt - das gesamte Projekt sollte geplant werden

forest 02

5.2.5. Projektstart und Projektende

Die könnte man schätzen

5.2.6. Projektresourcen

forest 03

Warum will jedes Projekt einen Swift Client erstellen?

5.2.7. Beurteilung

Man kann sich gut vorstellen, was zu tun ist
es fehlen ganze Kapitel (Ziele, …)
Das Projekt ist in einem nicht-verwendbaren Zustand
→ gen(4)

5.3. OnDemand

5.3.1. Allgemeines

Der Link zu den gh-pages in README.md vorhanden
Warum hat nur eine Person committed?
Warum gibt es einen Ordner "Organise"

5.3.2. ad PRoblemstellung

Vermischung mit Ausgangssituation

5.3.3. ad Aufgabenstellung

sehr abstrakt - könnte und sollte konkreter sein

demand 01

5.3.4. ad Projektphasen

tw. ok, jedoch ungenügende Präzisierung (Welches System ist kennzulernen)
sehr optimistisch
vergleiche die Kommentare des anderen Projekts

5.3.5. ad Projetstart und Projektende

Da sollten wohl Kalenderdaten stehen

demand 02

5.3.6. Beurteilung

Man kann sich vorstellen, was das Ergebnis ist
sogar messbare Eigenschaften
Man hat das Gefühl die beteiligten PErsonen haben sich was überlegt

→ bef(3)

5.4. Rocketman

n/a

5.5. School-IoT

5.5.1. Allgemeines

Links zu gh-pages in README.md vorhanden
keine Klarnamen im Internet

5.5.2. ad Background

naja

5.5.3. Beurteilung

Man kann sich überhaupt nicht vorstellen, …
- … um was es geht?
- … was bereits vorhanden ist (Sonsorbox und Vorgängerprojekt)
- … Das damit die Qualität in den Klassen (Luftqualität) verbessert werden soll; die Schüler werden leistungsfähiger
Das Architekturdiagramm ist toll
- jedoch nicht mit Plantuml erstellt
- und trotzdem schaffen es die die Pfeile nicht korrekt wo hinzuzeigen
Obwohl in diesem Dokument weiter oben (Project School-Iot Details) das Projekt bereits besprochen wurde, ist dies das Ergebnis

→ ndg(5)

5.6. Tournament

5.6.1. Allgemeines

tournament 01

Warum ist im git-repo wieder ein Unterverzeichnis
das repo hat kein README.md
das generierte Verzeichnis .asciidoctor ist ins repo eingecheckt
Euer Projektauftrag hat den Titel "My Project" und ist ein Mischmasch mit meinem Pflichtenheft-Template
Den Projektauftrag habt ihr Projektantrag genannt
Rechtschreibfehler
keine Klarnamen im Web

5.6.2. Inhaltlich

Projektphasen entsprechen dem Projekt der dritten Klasse
eigentlich ziemlich ok, ist aber nicht überraschend, da es das Gleiche vom Vorjahr ist

→ gen(4)

5.7. Konsequenzen

Ein neues Repo für das Pflichtenheft ist von allen Teams zu erstellen

6. 2020-11-13

6.1. Semantic Versioning

https://semver.org/lang/de/
Versions-Nr zB 1.2.5
Struktur: MAJOR.MINOR.PATCH
- MAJOR: Neue Version, die nicht kompatibel mit den Vorgängerversionen ist
  Die API "bricht", neue Features
- MINOR: Neue Version mit neuen Features, die kompatibel mit Vorgängerversionen ist
- PATCH: Neue Version, KEINE neuen Features, nur Bug-Fixes (Fehlerbehebungen)
Erweiterungen zB mit Build Nr: zB 1.2.5.1212423

6.2. DOM — Domain Object Modell

D … Fachbereich
O … Object
M … Model

→ Fachbereichsobjektmodell

Beispiele:
- Hausarzt → Patient, Diagnose, Fall, …
- Handel → Produkt, Kunde, Rechnung, Mahnung, Lieferung
- …
Keine technischen Klassen
vergleichbar mit einem ERD (Entity-Relationship-Diagram)
wird zB in einer SysSpec (Pflichtenheft) verwendet
Man kann mit dem Kunden über seine Geschäftsobjekte sprechen.

6.3. Mögliche Vorgehensweise

how to begin

7. 2020-11-20

7.1. Frage

class VehicleTest {

    @Test
    void createVehicle() {
        Vehicle commodore = new Vehicle("Opel", "Commodore", 100.0);
        assertThat(commodore.getBrand()).isEqualTo("Opel");
    }
}

Frage:
- Ist bei diesem Test ein @QuarkusTest notwendig?
- Begründen Sie Ihre Antwort
Antwort:
- Es ist ein einfacher Unit-Test einer Klasse.
- Dabei sind keine Abhängigkeiten notwendig.
- Man injiziert nicht (es gibt kein @Inject)

8. 2020-12-04

8.1. Arten von Zielen

leistungsziele

Zielarten
- Wirkungssziele
- Ergebnisziele
- Prozessziele

https://www.wirkung-lernen.de/wirkung-planen/ziele/erarbeiten/

vmodell

8.2. Behaviour Driven Design - BDD (Karate & Gherkin)

https://de.wikipedia.org/wiki/Behavior_Driven_Development

Arten der Softwareentwicklung

klassisches Vorgehen
- Erstellen eines detaillierten Pflichtenheftes für das ganze Projekt
- Vorgehensmodelle: Wasserfallmodell / V-Modell
- Dokumente: Pflichtenheft (WAS), Entwurf (WIE), Projekthandbuch (ORGANISATION)
- Implementieren des gesamten Projekts
- Ausliefern des gesamten Projekts (Big Bang)
agile Vorgehen
- das gesamte Projekt wird zunächst nur grob umrissen
- Vorgehensmodelle: Scrum, Kanban
- Scrum: Epics und Userstories
  - immer die nächsten User Stories werden detailliert mit Tasks beschrieben …
  - … und anschließend implementiert, getestet und an den Kunden ausgeliefert
  - Starke Mitarbeit des Kunden
  - Übersicht aller User Stories im Product Backlog
  - zeitliche Zielsetzungen mittels Sprints

Qualität: sehr allgemein formuliert → ist das, was der Kunde wünscht

Konzept: BDD
- aus der sicht des Kunden werden die Tests erstellt
- die Tests werden sprachneutral (i.S.v. Programmiersprachen) als Gherkin-files erstellt (feature-Files)
- Karate ist das Testframework, welches die Tests ausführt
- Karate wird von jUnit Tests (also von Java) aufgerufen

8.3. Karate

karate overview

Karate-Statement

karate hello world

https://github.com/intuit/karate

Erstellen des Projekts

mvn io.quarkus:quarkus-maven-plugin:1.9.2.Final:create \
    -DprojectGroupId=at.htl \
    -DprojectArtifactId=quarkus-karate-demo \
    -DclassName="at.htl.karate.boundary.GreetingResource" \
    -Dpath="/hello"

pom.xml

    <dependency>
      <groupId>com.intuit.karate</groupId>
      <artifactId>karate-apache</artifactId>
      <version>0.9.6</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>com.intuit.karate</groupId>
      <artifactId>karate-junit5</artifactId>
      <version>0.9.6</version>
      <scope>test</scope>
    </dependency>
    ...

  <build>
    <testResources>
      <testResource>
        <directory>src/test/java</directory>
        <excludes>
          <exclude>**/*.java</exclude>
        </excludes>
      </testResource>
    </testResources>
    <plugins>
    ...
    </plugins>
  ...
  </build>

src/test/java/karate-config.js

function fn() {
    var env = karate.env; // get java system property 'karate.env'
    karate.log('karate.env system property was:', env);
    if (!env) {
        env = 'dev'; // a custom 'intelligent' default
    }
    var config = { // base config JSON
        baseUrl: 'http://localhost:8081'
    };
    // don't waste time waiting for a connection or if servers don't respond within 5 seconds
    karate.configure('connectTimeout', 5000);
    karate.configure('readTimeout', 5000);
    return config;
}

8.4. Aufgabe Karate

Erstelle einen Endpoint mit einem PathParameter
- localhost:8080/hello/susi ergibt einen Rückgabewert "hello susi"
- einmal als plain text, einmal als xml und einmal als json
Erstellen einer Entität Vehicle mit brand und type
- Create eines Vehicles über Endpoint
- Das Vehicle ist ein File
- siehe dazu https://github.com/htl-leonding-college/quarkus-karate-testcontainers-demo

9. 2021-01-15

Projektarbeit
- Feedback für Leonie
- TNMS Helfenberg

10. 2021-01-22

10.1. Erstellen von Unit-Tests

10.1.1. Was teste ich

Unit-Tests sind NICHT (oder nur teilweise) das testen von Gettern und Settern.
- Es ist nicht sinnvoll, von der IDE generierte Getter und Setter zu testen.
Zu testen ist:
- Das Zusammenspiel der Klassen (die Assoziationen, Vererbungs- und sonstigen Beziehungen)
- Eigene MEthoden, die zusätzlich zu Konstruktoren, Gettewrn und Settern erstellt wurden
- Collections und der Zugriff darauf

10.2. Wie gehe ich beim Testen vor

Man geht von den Anwendungsfällen aus:
- Bsp: Umfragetool QuestionZ
  - US1: Der Befrager erstellt einen Fragebogen
  - US2: Der Befrager erstellt eine Umfrage
  - US3: Die Befragten nehmen an einer Umfrage teil
  - Us4: Der Befrager wertet die beantworteten Fragebögen aus
Man erstellt für jeden Anwendungsfall eigene Tests (ein oder mehrere, zB Sonderfälle)
- ev. ohne Persistierung, die Datenbank aber sehr wohl verwendet.
- es geht um das Ergebnis
  - zB bei US1: Es steht ein Fragebogen zur Verfügung (zB mit 6 Fragen und allen Fragetypen), in der Datenbank (oder nur im Hauptspeicher als Java-Objekte)
  - zB bei US2: Eine fertig erstellte und konfigurierte Umfrage (Datum, TANS sind gerneriert, …), in der Datenbank (oder nur im Hauptspeicher als Java-Objekte)
  - zB bei US3: zB fünf ausgefüllte Fragebögen in der Datenbank (oder nur im Hauptspeicher als Java-Objekte)
  - zB bei US$: Die Auswertung wird in unserem Beispiel nicht in der DB gespeichert. Als werden nur die Summen / Mittelwerte usw auf Korrektheit getestet

10.3. Ziel des Unit-Tests

Fehler sollen frühzeitig erkannt werden - speziell im Datenmodell
- Das Datenmodell ist die Grundlage des gesamten Softwaresystems und Fehler darin ziehen umfangreiche Änderungen bis in die GUI nach sich.
- Die Abläufe werden in den Tests simuliert.
- Sind die Ergebnisse dieser getesteten Abläufe in Ordnung beginnt man mit der nächsten Schicht
- Test-Schichten
  - Entity-Tests (ev. noch ohne Persistierung)
  - Repository-Tests
  - Endpoint-Tests
  - GUI-Tests (meist der Webanwendung)

10.4. TODO - Kommentar

In intellij una anderen IDEs gibt es ein eigenes Fenster, in dem alle TODOs aufgelistet werden.

10.5. Vorgehensweise

10.5.1. kleine Schritte

Man versieht nicht alle Klassen mit Persistenzannotationen sondern …
... man beginnt mit einer Klasse, die man sofort persistiert in einem Unit-Test

10.5.2. Repository Pattern verwenden

siehe Microsoft
aggregates verwenden, nicht jede Entity-Klasse hat ein eigenes Repository

10.5.3. keine unverschlüsselten Credentials (passwords usw) im github speichern

11. 2021-03-04

Erstellen eine Pipeline mit gh-actions
- Vergleichsprodukt zu gh-actions ist Jenkins, Travis, …
- Erstellen von ssh-keys
- infrastructure-as-code
- Zweck: Nach dem Pushen der Files in das git-repo wird automatisch
  - kompiliert
  - getestet und
  - deployed (zB auf einen Server kopiert und gestartet)

12. 2021-03-05

Was soll der (begeisterte) ITP-Schüler und auch -in immer können:
- git (Theorie + Praxis)
  - Versionsnummern (Aufbau)
- github-actions (Theorie)
  - ssh-keys
  - Erstellen einer Pipeline
- Vorgehensweise beim Durchführen von Projekten (Theorie und Praxis)
  - Scrum vs klassische Vorgehensweise
  - Strukturierung eines Projekt in github
  - V-Modell
- Testen
  - Welche Arten von Tests
  - Welche Test-Frameworks werden wie angewendet (Theorie und Praxis)
- UML-Diagramme
  - CLD und Objektdiagramm
  - ACD
  - State Diagram
  - Deployment Diagram
  - Kompositionsstrukturdiagramm

wird nicht geprüft, muss vorher noch gemacht werden
** Virtualisierung mit Docker (Theorie)
*** docker-compose "Jeder Dienst ein eigener Container"

Build-Tools
- Zweck
- Funktionalität
  - Einbinden und automatischer Download von Libraries
  - Einbinden von Plugins
- Varianten: v.a. maven, gradle, npm, …

12.1. Organisation von Projekten mit github und gh-projects

Problem:
- Die bevorzugte Vorgehensweise ist Scrum
- In github gibt es allerdings "nur" Kanban
  - keine Sprints sondern Meilensteine
  - keine User Stories und Tasks, nur Issues die in gh-project (vglbar mit Sprint Backlog) dargestellt werden können
  - User Stories sind Issues mit einem Tag "User Story"
Wie werden Issues sonst noch verwendet?
- Die Tasks werden in gh-Projects je nach Ihrem Zustand (open/in progress/to review/done) dargestellt
- Gesprächsprotokolle werden mit m-o-m (Minutes of Meeting) gekennzeichnet
- Bug-Reports werden mit "bug" gekennzeichnet und als Task in das gh-projekt eingetragen
Ganz wichtig ist die konkrete Zuordnung von Aufgaben zu Teammitgliedern
- Ein Issue (Task, Bug, …) soll nur einem Teammitglied zugeordnet sein (es kann Ausnahmen geben)
- Es soll jedem Task (und auch Bugfix, …) eine Fertigstellungsdatum zugeordnet werden durch die Verwendung von Meilensteinen
- Die Aufgabe die im Task beschrieben ist, soll klar lösbar, kontrollierbar und testbar sein
  - der Projektkoordinator (Projektleiter) soll den Teammitgliedern entsprechend ihrer Fähigkeiten die Aufgaben zuordnen.
  - die Erfüllung dieser Aufgaben ist Teil der Bewertung
  - Gibt es Aufgaben, die nicht programmiert werden zB Marktanalyse, Entwurfsentscheidung, … dann muss es ebenfalls ein Ergebnis geben zB einen (kurzen) Bericht darüber
  - Die einzelnen Commits sind durch #<no des issues> den Issues (Tasks, Bugfixes usw) zuzuordnen
  - Die User Stories können nummeriert werden zB "US-01 Eintragung einer Fahrt"
  - Somit können die Tasks den User Stories zugeordnet werden, zB "Repositories erstellen (US-01)"
  - Eine Alternative zu dieser Strukturierung:
    
    Die Meilensteine erhalten dieselben Bezeichnungen wie die User-Stories
    
    Jeder Task ist dem entsprechenden Meilenstein zugeordnet (so ersieht man ebenfalls die Zugehörigkeit zu einer User Story)
    
    Jeder Meilenstein hat ein Datum
  - Grundsätzlich ist das System nach Beendigung eines Tasks lauffähig (IMMER)
  - Wenn ein Teammitglied eine neue Aufgabe zugewiesen bekommt zB eine neue Funktion, so ist ein Feature-Branch zu erstellen
    
    dh der Main Branch ist immer lauffähig
    
    nach Fertigstellung des neuen Features gibt es ein Code Review mit anschließendem Merge
    
    oder es gibt einen Pull-Request mit anschließendem Review und ev. Merge

12.2. Beispiel: Wie kann man ein Projekt zerlegen

12.2.1. Überblick verschaffen

Zb Erstellen eines UCDs

Oft dient die Strukturierung mit Use-Case-Diagrammen als Anhaltspunkt für Meilensteine.
Hier könnte man zB drei Meilensteine definieren
- Fahrt eintragen
- Route eintragen
- Auswertung
zusätzliche Meilensteine könnten sein
- Vorbereiten der Infrastruktur (Server aufsetzen)
- Prototyps für Eintragen des Standorts per GPS
Es sind alle Meilensteine zu erstellen und mit (geschätzten) Fertigstellungsterminen zu versehen.
- Der Detaillierungsgrad (ob die Tasks schon für den jeweiligen Meilenstein erstellt wurden) nimmt bei späteren Meilenstainen ab.
Unterteilt man in Frontend und Backend als getrennte Systeme, so ist es sinnvoll die Schnittstelle zwischen diesen beiden System zu definieren.
Anschließend kann man für jedes System die Funktionalität auflisten und abarbeiten
Frage: was ist der Unterschied von Use-Case (Anwendungsfälle) zu User Stories
- Beide definieren Anforderungen / Funktionalitäten aus Kundensicht
- Use-Cases sind etwas größer (vllt. kann man sagen, dass ein UC aus mehreren User-Stories bestehen kann)
- User Stories sind etwas detaillierter, da aufgrund dieser programmiert werden muss (mit einem konkreten Ergebnis)

13. 2021-03-XX

Vorstellen der Verschlüsselung von Stefnotch zum einpflegen von Secrets in github → Jonas Dorfinger

14. 2021-03-26 (Freitag)

Es wurde festgestellt, dass noch Defizite im Bereich Docker und docker-compose bestehen
→ nach den Osterferien wird Docker durchgearbeitet
im Rahmen des Deployments per gh-actions auf eine Oracle VM