Project Teams
-
Rocketman → Prof. B. Ernecker
-
14 Jan Händler
-
17 Marcel St. Martin
-
10 Lukas Hörnchen
-
-
Dünnschichtchromatogramm → Prof. B. Ernecker
-
Drohne
-
11 Duke Ellington
-
4 Paulchen Panther
-
2 Ballkarawane
-
-
School-IoT "The appealing classroom"
-
21 Felix der Große
-
15 Vinzent K
-
20 Roberto
-
-
LeoSchool → derzeit Diplomarbeit
-
3 Musikfreund 1
-
13 Musikfreund 2
-
23 Musikfreund 3
-
19 Jimmy
-
-
LeoTurnier
-
9 Lorenzius
-
12 Tarik Tarik
-
5 Jonas die Birke
-
6 Nico
-
-
LeoDatabaseLearner
-
24 Patrick
-
16 Muammar
-
-
DigitalSignage - On-Demand Videos
-
7 Eggman
-
1 Daniel
-
-
Kubernetes Provision Tool
-
27 Krimiman
-
8 Moritz mit Brille
-
22 Eminem
-
18 Moritz ohne Brille
-
-
LeoSurvey
-
25 TF
-
26 TP
-
1. 2020-09-21
-
Vorbereitung für Verwendung von plantuml
-
docker installieren
-
AsciiDoc plugin in IntelliJ installieren
-

1.1. Jenkins-Pipeline

-
Alternativprodukte
-
Automation Server in der jeweiligen Cloud
-
GitHub / Travis (?)
-
2. 2020-09-22
2.1. Projektantrag / Project Proposal
mit Asccidoctor Template: https://github.com/htl-leonding-college/asciidoctor-docker-template
Project Proposal - Grades
lfd.Nr. | Name | Thema | Feedback |
---|---|---|---|
1 |
Daniel |
Digital Signage (siehe Eggman) |
ngd(5) |
2 |
Kawasaki |
Feedback Survey |
ngd(5) |
3 |
Benjamin Musikfreund 1 |
Turnierverwaltung |
korr. bef(3) |
4 |
Paul |
n/a |
ngd(5) |
5 |
Jonas die Birke |
FinanceCheck |
ngd(5) |
6 |
Nico |
siehe Jonas die Birke |
ngd(5) |
7 |
Benjamin Eggman |
DigitalSignage - On-Demand Videos |
ngd(5) |
8 |
Moritz Brille |
Freiwillige Feuerwehr |
korr. bef(3) |
9 |
Lorenzius |
Digital Price Tag |
gen(4) |
10 |
Lukas H |
Rocketman |
ngd(5) |
11 |
Duke Ellington |
Smart School |
ngd(5) |
12 |
Tarik Tarik |
Turnierverwaltung |
gen(4) |
13 |
David Musikfreund 2 |
Lagerverwaltung |
gen(4) |
14 |
Jan Händler |
Rocketman |
ngd(5) |
15 |
Vinzent K |
Terminkalender |
gen(4) |
16 |
Muammar |
Fitness Studio |
ngd(5) |
17 |
Marcel die Ecke |
Rocketman |
ngd(5) |
18 |
Moritz ohne Brille |
easyschool |
gen(4) |
19 |
Jimmy |
Kassasystem |
gen(4) |
20 |
Roberto |
Bank Account Manager |
gen(4) |
21 |
Felix der Große |
Buffet-Anwesenheitsampel |
bef(3) |
22 |
Eminem |
Event Organizer |
ngd(5) |
23 |
Bocki Musikfreund 3 |
BetAtSchool |
ngd(5) |
24 |
Patrick |
ngd(5) |
|
25 |
Fabian Woody |
Bibliothek |
ngd(5) |
26 |
Philip Cokeman |
ngd(5) |
|
27 |
Marc Krimiman |
SIP Phones |
gut(2) |
4. 2020-10-06
Vortrag "School-IoT" von Prof. G.Köck
-
MQTT
-
Einsatzgebiet
-
Vor- und Nachteile
-
Publish-Subscribe-Pattern
-
Quality of Service
-
5. Einteilung Projekte 20/21
5.1. Projektthemen 20/21
Project Topics
Projektbez. | Team | Auftraggeber / Ansprechpartner | Anmerkungen |
---|---|---|---|
Rocketman |
|
Prof. B. Ernecker |
|
|
Prof. B. Ernecker |
||
School-IoT |
|
Prof. G. Köck |
"The appealing classroom" |
LeoSchool |
|
T.Stütz |
→ derzeit Diplomarbeit |
LeoTurnier |
|
T.Stütz |
bereits Projekt vorhanden |
LeoDatabaseLearner |
|
||
On-Demand Videos |
|
→ Bereich "DigitalSignage" |
|
Kubernetes Provision Tool |
|
Prof.C.Aberger |
6. 2020-10-19
-
Automatisiertes Testen
-
Assert-J core
-
@QuarkusTest
-
@Context
-
Verwendung eines Loggers
-
Response Codes bei REST
7. 2020-10-20
7.3. File aus der staging area löschen
git restore --staged . (1)
git restore --staged <file(s)>
1 | Sämtliche Files werden aus der Staging Area gelöscht |
7.4. Zurücknehmen der lokalen Änderungen
git restore .
git restore <file(s)>
-
neu erstellte Files werden nicht automatisch gelöscht, sondern verbleiben untracked in der working copy
-
diese Files müssen separat glöscht erden
git clean -fd
-
-f … force
-
-d … directories
9. 2020-11-16
9.1. Benotung der Pflichtenhefte
aus der Sicht des Kunden beschreiben |
-
Es sind die Geschäftsprozesse zu ermitteln
-
Was kann der Kunde mit dem System machen?
-
-
Das zu erstellende System ist zunächst überblicksmäßig zu beschreiben
-
erst anschließend die einzelnen Komponenten im Detail
-
-
Der Kunde möchte meist auch die GUI schon im Vorfeld sehen
-
grober Entwurf der GUI zB mit Bleistiftzeichnung
-
12. 2020-11-24
-
Zielarten
-
Wirkungsziele
-
Ergebnisziele
-
Prozessziele
-
12.1. Behaviour Driven Development - BDD (Karate & Gherkin)
-
Konzept: BDD
-
aus der sicht des Kunden werden die Tests erstellt
-
12.2. Karate
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"
<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>
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;
}
12.3. 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
-
-
Erstellen Sie dazugehörige Karate-Tests
14. 2021-02-16
14.1. Was ist für eine Diplomarbeit geeignet?
-
kleine Prototypen für einen organisatorischen Ablauf zB Einlesen von EAN-Codes auf Paketen mit Android Brille
-
kleiner Prototyp für eine neue Technologie zB Webshop in Angular, Vue, Svelte, …
-
ein eher für die Firma nicht so wichtiges Projekt (nice-to-have):
-
Essensanmeldung für Kantine
-
14.2. Diplomarbeit - Gliederung
-
Theorieteil
-
Beschreiben der Technologien (wird erst zum Schluss der Arbeit gemacht)
-
-
Praktischen Teil
-
Ausgangssituation
-
Istzustand
-
Problemstellung
-
Aufgabenstellung
-
Ziele (Leistungswirkung)
-
Marktanalyse
-
Entwurfsentscheidungen
mit Kriterienkatalog -
Systemarchitektur und Entwurf
-
Ausgewählte Aspekte und Probleme
Was habe ich besonders gut gemacht, wo hatten wir Probleme und wie lösten wir diese -
Resumee
-
Was habe ich gelernt …
-
bezüglich Zeiteinteilung
-
Zusammenarbeit mit Kollegen
-
Zusammenarbeit mit Firmen
-
-
Selbstreflexion der Arbeit
-
-
Aufteilung der Arbeit nach Teammitgliedern
zB Gliederung mit den Namen derjenigen, die das jeweilige Kapitel verfasst haben -
Literaturverzeichnis (irgendeinen Standar wählen zB Harvard Zitierung)
https://www.itcp.kit.edu/wilhelm/download/Zitieren-in-wissenschaftlichen-Texten.pdf -
und andere Verzeichnisse
-
14.3. Diplomarbeit - Durchführung
-
Gliederung erstellen
-
Mit den schwierigen Kapitel beginnen
-
Nicht sofort die Sätze ausformulieren,
-
sondern zuerst nur Codes, Tabellen, Diagramm und Stichworte schreiben
Stichwort: die Argumentationslinie nicht verlieren -
Immer gleich die Quellen (bei Links mit Datum) im Text angeben zB in eckigen Klammern
-
Wenn man eine interessante Quelle findet, glich in die Arbeit eintragen
17. 2021-04-13
17.1. Projektbesprechung IoT
-
das Team gibt an am Simulator zu arbeiten
-
Implementierung lt. Team fertig
-
es wird an der Dokumentation gearbeitet
-
Kommentar Stütz:
-
es gibt im Projekt nur einen Task.
-
die Konfiguration (MQTT-Server-Adresse) ist nur im Code als Variable enthalten → diese Daten sind in der application.properties einzutragen → die Anwendung ist mit Environment Variablen zu konfigurieren
-
Es arbeitet nur ein Teammitglied am Simulator
-
-
19. 2021-04-26 Gruppe B
docker-compose fertig
-
Beispiel docker-compose mit quarkus Gruppe B
-
Hrn Hain fragen, dass er docker-compose Beispiel erklärt
21. 2021-05-25 - Karate Test-Framework
21.1. Erstellen eines Quarkus - Projekts
mvn io.quarkus:quarkus-maven-plugin:1.13.4.Final:create -e \ -DprojectGroupId=at.htl.demo \ -DprojectArtifactId=demo \ -DclassName="at.htl.demo.boundary.VehicleEndpoint" \ -Dpath="/demo" \ -Dextensions="resteasy, resteasy-jsonb, smallrye-openapi"
21.2. Exkurs: Test-Frameworks
SDLC-Phase | Framework |
---|---|
Unit-Testing |
JUnit, AssertJ, Hamcrest, (TestNG, Spock) |
Integration-Testing |
JUnit, AssertJ, Hamcrest, Mockito, JMock |
System-Testing |
REST: RESTassured, Karate, Jersey-Client, Jasmin |
Abnahmetesten / Akzeptanztest |
wird durch den Kunden durchgeführt |
21.3. Erstellen des zu testenden Endpoints
package at.htl.demo.boundary;
import ...
@Path("/demo")
public class VehicleEndpoint {
@GET
@Produces(MediaType.APPLICATION_JSON)
public String hello() {
return """
{
"brand":"Opel",
"type":"Admiral"
}
""";
}
@POST
public Response post(@Context UriInfo uriInfo, String text) {
System.out.println(text);
URI uri = uriInfo.getAbsolutePathBuilder().path("42").build();
return Response.created(uri).build();
}
}
21.4. Konfigurieren von Karate
-
Eintragen der maven-Dependency
-
<testResources>-Element in <build>-Element in pom.xml eintragen
-
karate-config.js
insrc/test/java
erstellen
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;
}
21.5. Aufrufen des Karate Tests
package at.htl.demo.boundary;
import com.intuit.karate.junit5.Karate;
import io.quarkus.test.junit.QuarkusTest;
import org.junit.jupiter.api.Disabled;
import org.junit.jupiter.api.Test;
import static io.restassured.RestAssured.given;
import static org.hamcrest.CoreMatchers.is;
@QuarkusTest
public class VehicleEndpointTest {
@Karate.Test
Karate testVehicle() {
return Karate.run("vehicle").relativeTo(getClass());
}
}
21.6. Feature-File for Karate
Das .feature-File ist in Gherkin geschrieben. Gerkin wurde ursprünglich für https://de.wikipedia.org/wiki/Cucumber(Software)[Cucumber] entwickelt. Karate nutzt die Gherkin-Notation, hat aber sonst mit Cucumber nichts zu tun.
Feature: Get infos about our vehicles
Background:
* url baseUrl
Scenario: Show single car
Given path 'demo'
And header Content-Type = 'application/json'
When method GET
Then status 200
And match response ==
"""
{
"type":"Admiral",
"brand":"Opel"
}
"""
Scenario: Create a car
Given path 'demo'
And header Content-Type = 'application/json'
And request { "type":"Admiral", "brand":"Opel" }
When method POST
Then status 201
And print responseHeaders

-
Das Szenario im Feature File entspricht einem Use Case im UCD
-
Man könnte ev. auch eine Feature aus dem Feature File einem Szenario aus einem UCD zuordnen
-
zB show card infos
-
die einzelnen Szenarien im Feature File bilden nun die einzelen Testfälle (normale Durchführung, Workarounds, Fehlschläge, …) ab
-