3. 2021-10-05
-
Projektarbeit (UCD und CLD)
-
Datenmodelle (Beispielskatalog)
-
Bsp 4 - Kinokette
-
CLD wurde teilweise erarbeitet
-
-
| Übung: Fertigstellen des CLDs bis Donnerstag 7.10.2021 |
5. 2021-11-22 (Distance Learning)
5.1. Aufsetzen des Projekts
-
Eintragen des Projekts im YouTrack
-
Verbindung zum VCS herstellen
-
Definieren der User Stories und Eintragen ins YT
-
Definieren von Tasks, Zuweisen zu Personen, Eintragen ins YT
-
Erstellen von Sprints (sprint 1, sprint 2) als zeitliche Komponente
-
Die jeweiligen Commits sind den Tasks zuzuweisen (→ in YT sind bei den Tasks die Commits aufgelistet)
5.2. Projektthemen
| Projekt | Teammitglieder | Anmerkung |
|---|---|---|
Absolventenverband FIT |
Niklas Aichinger, Julia König |
Repository von M.Bucek |
LeoCompetition |
Christoph Handel, Lukas Baumgartner, Joachim Pelzeder |
|
Vinitor |
Sheila Hautzmayer, Anna Hartl |
Repository bei Vinitor (gitlab) |
Beeyond |
Markus Remplbauer, Nico Hirsch |
|
LeoCode |
Florian Keintzel, Raphael Ablinger, Oliver Sugic |
|
School-IoT |
Jakob Rathberger, Philipp Kerschbaum |
|
LeoQuest |
Edina Abazovic, Sebastijan Bogdan, Marcel Plakolb, Paul Binder |
|
Franklyn |
Tamara Melcher, Michael Tran |
|
Leonie-Chatbot (LeonieWeb) |
Darius-Cristian Pavelescu, Niklas Neudorfer, Johannes Tunc |
5.3. Erstellen von Protokollen
-
Jedes Gespräch mit Nicht-Teammitgliedern ist zu protokollieren
-
ev. Gedächtnisprotokoll
-
-
Die Protokolle sind im adoc-Format zu erstellen
-
Wenn man will kann man diese Protokolle in die gh-pages einbinden (vgl quarkus-technology-notes)
<<20yy-mm-dd-thema.adoc>>
-
Vorlage für Protokolle
6. 2021-11-23
6.1. Vorgehensweise beim Projekt
6.1.1. gh-pages
-
Die Projektgruppen arbeiten selbstständig an Ihren Projekten, dh es wird nicht gewartet bis jede Kleinigkeit mit dem Betreuungslehrer besprochen wird.
-
Ist keine Arbeit zu machen, wird aktiv nachgefragt und neue User Stories werden vereinbart.
-
Es sind gh-pages zu erstellen, mit einer kurzen Beschreibung des Projekts
-
Die gh-pages dienen als Landing Page, dh wenn Besucher der Website, die keine Ahnung vom Projekt haben, dies lesen, so soll ihnen ungefähr klar sein, um was es geht
-
Wir verwenden ein jam-stack.
-
j → javascript; a → api; m → markup language
-
-
Dann werden die anderen Entwurfsdokumente, Protokolle usw verlinkt
-
Bsp: Projekt Netunus
-
6.1.2. Youtrack
-
Ausgehend von den Use Cases werden die User Stories (aus Gründen der Vereinfachung) abgeleitet
-
In Youtrack wird für jede User Story eine Swimlane (Zeile) erstellt
-
Für jede User Story werden Tasks erstellt
-
Die Tasks werden einem oder mehreren Teammitgliedern zugewiesen
-
(Wenn man auch die Storypoints vergibt, kann man ein Burndown-Chart generieren lassen )
-
Als zeitliche Komponente (Fertigstellungstermin) sind Sprints zu erstellen
-
Sprints werden mit "Sprint 001 xxx", "Sprint 002" usw bezeichnet
-
Die Sprints werden den einzelnen Tasks (ev auch US) zugewiesen.
-
-
Jeder Commit ist den einzelnen Tasks zuzuordnen
-
zB Commit-Message: bla bla #leocomp-3 in progress
-
| Grundprinzip: Wir überlegen uns, was wir tun, wir tun es und wir dokumentieren das Tun |
6.2. Projektarbeit ist zu dokumentieren
-
Die Teams werden darauf hingewiesen, dass die Projektarbeit zu dokumentieren ist:
-
Zuerst sind im Youtrack User-Stories einzutragen
-
Für diese User-Stories sind Tasks zu erstellen
-
Diese müssen den einzelnen Teammitgliedern zugewiesen werden
-
weiters sind die Sprints (zeitliche Komponente) festzulegen
-
Die einzelnen Commits sind den Tasks zuzuordnen.. Im Youtrack muss man ersehen
-
-
7. 2021-12-06
7.2. Grundprinzipien
-
Objektorientierung (Objektidentität)
-
Programmieren gegen Schnittstellen
-
Single-Responsibility-Principle
-
Open/Closed Principle
7.2.1. Analytische Maßnahmen
-
Buch Seite 322
-
Statische Methoden
-
Dynamische Methoden (Testen)
-
Black-Box
| Testfallspezifikation - man überlegt sich, wie die zu erstellenden Testfälle aussehen |
-
Äquivalenzklassenmethode
-
Grenzwertfallanalyse
-
Testfall auf der Grenze des Wertebereichs
-
Testfall knapp über der Grenze
-
Testfall knapp unter der Grenze
-
-
White Box
-
Grey Box
8. 2022-01-10
8.2. Data Transfer Objects - DTO
-
Grundprinzipen der OO
-
Value Objects
-
DTOs
-
json-Objekte
-
java-records
-
9. 2022-01-18
-
Jede Komponente soll getestet werden
-
Die Tests sollen voneinander unabhängig sein (beliebige Reihenfolge)
-
Es sollen Tests auf den verschiedenen Testlevels (Modultest / Integrationstest / Systemtest / Akzeptanztest) erstellt werden
| Testlevel | Testmethode | Testgegenstand | Erwartetes Verhalten |
|---|---|---|---|
Modultest |
MyTest::calcAgeWith100y_Fail |
berechnetes Altersfeld Person |
Column 4, row 1 |
Systemtest |
… |
… |
… |
12. 2022-03-01
12.1. Übung: Erstellung von Dockerfile 's
-
Erstellen Sie für jede Datenbank ein eigenes Verzeichnis in Ihrem Microprojekt
12.1.1. Derbydb
-
Die verschiedenen Dockerfiles sind jeweils in einem eigenen Verzeichnis mit aussagekräftigem Namen
-
Erstellen Sie ein Dockerfile für die DerbyDb
-
Eine Version soll die Daten der DB im Container speichern.
-
eine zweite Version soll die Daten mittels Bind Mount im Ausführungsverzeichnis im Verzeichnis
dataspeichern.
-
-
Erstellen Sie
-
einen Aufruf mittels
docker-Command -
erstellen Sie einen Aufruf mittels docker-compose
-
fügen Sie der docker-compose Konfiguration noch einen Container mit einem nativen Quarkus Server hinzu, der Daten in der Datenbank speichert.
-
-
13. 2022-03-14
13.1. asciidoctor / plantuml - testdrive
| Lernen Sie Datenmodellierung |
| Verstehen Sie die Zusammenhänge |
Stg-T
13.2. Stoffumfang der 1. LF
-
asciidoctor
-
plantuml
-
qualitätsmanagement
-
wähle ich testfälle aus?
-
Teststrategien?
-
Grenzwertanalyse
-
Äquivalenzklassenanalyse
-
-
assertj-core und assertj-db
-
-
git
13.3. Projektpräsentation
-
Sämtliche Projekte sind zu präsentieren:
-
Verwendung von revealjs und asciidoctor
-
Inhalt
-
Kann variieren - je nach Thema
-
Grundsätzlich ist die Leistung des jeweiligen Teams zu "verkaufen"
-
mögl. Gliederung
-
Ausgangssituation
-
Problem
-
Aufgabenstellung (Ergebnis, Leistung)
-
Ziel (Leistungswirkung)
-
Systemarchitektur
-
Derzeitiger Stand des Projekts → Youtrack
-
Demo
-
Resümee, Weitere Schritte, …
-
-
-
Anschließend nach Präsentationen Code-Review
14. 2022-03-21
14.1. gh-actions
-
Was sind gh-actions?
-
Jedes Softwaresystem muss deployed werden
-
zB eine SPA auf einem Web-Server bereitstellen
-
SPA … Single Page Application
-
-
dieser Vorgang wird automatisert
-
man verwendet dazu gh-actions
-
-
sind vergleichbar mit einer Scriptsprache, die sequentiell mehrere Aktionen ausführt.
-
zusätzlich gibt es actions, die eine bestimmte Funktionalität kapseln, zB
-
Installation von Java
-
kopieren des repos auf die aktuelle Maschine
-
-
in gh kann man dazu virtuelle Instanzen (meist Linux) verwenden
-
19. Qualitätssicherung
19.1. Buch Kapitel QS
-
Konstruktive Maßnahmen
-
Analytische Maßnahmen
-
statische Prüfungen
-
dynamische Prüfungen
-
19.2. Test Doubles
-
Test Doubles
-
Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
-
Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an InMemoryTestDatabase is a good example).
-
Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test.
-
Spies are stubs that also record some information based on how they were called. One form of this might be an email service that records how many messages it was sent.
-
Mocks are pre-programmed with expectations which form a specification of the calls they are expected to receive. They can throw an exception if they receive a call they don’t expect and are checked during verification to ensure they got all the calls they were expecting.
-
19.3. Testen mit Karate
-
wir verwenden hier nur das API-Testing
19.3.1. pom.xml - Dependencies
<dependency>
<groupId>com.intuit.karate</groupId>
<artifactId>karate-junit5</artifactId>
<version>1.2.0</version>
<scope>test</scope>
</dependency><properties>
...
<graal-sdk.version>22.1.0.1</graal-sdk.version>
</properties>
...
<dependencies>
...
<dependency>
<groupId>org.graalvm.sdk</groupId>
<artifactId>graal-sdk</artifactId>
<version>${graal-sdk.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.graalvm.js</groupId>
<artifactId>js</artifactId>
<version>${graal-sdk.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.graalvm.js</groupId>
<artifactId>js-scriptengine</artifactId>
<version>${graal-sdk.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.graalvm.truffle</groupId>
<artifactId>truffle-api</artifactId>
<version>${graal-sdk.version}</version>
<scope>test</scope>
</dependency>
</dependencies>19.3.2. Config File
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', 2000);
return config;
}19.4. gherkin-Testfile
Feature: Product creation endpoint.
An user of the endpoint is able to create Products
Background:
* url baseUrl
Scenario: Create a Product
Given path 'products'
And request { name: "Timmie's Hundefutter" }
When method POST
Then status 201
Scenario: Get a product
Given path 'products'
When method GET
Then status 200
And match response == { name: "Timmie's Hundefutter" }19.5. JUnit-Test
-
Die Cucumber/gherkin-Tests werden von einem junit-Test aufgerufen
package at.htl.karatedemo.boundary;
import com.intuit.karate.junit5.Karate;
import io.quarkus.test.junit.QuarkusTest;
@QuarkusTest
class ProductResourceTest {
@Karate.Test
Karate product_crud_in_productEndpointTest() {
return Karate.run("products").relativeTo(getClass());
}
}
21. 2020-06-29
21.1. User Design, User Experience
21.1.2. Usability-Interaktionsprinzipien
-
-
Sichtbarkeit des Zustands und Feedback des Systems
-
Übereinstimmung mit der (realen) Welt der Nutzer
-
Kontrolle und Freiheit der Nutzer - Nutzer sollen die Freiheit haben Aufgaben abzubrechen und Aktion zu widerrufen.
-
Konsistenz und Standards- branchenübliche Standards; Innere Konsistenz bedeutet, dass Elemente, die gleiche Aufgaben haben, auch in Aussehen und Verhalten gleich sind.
-
Fehlerprävention - Am besten gestaltest du das System so, dass Fehleingaben unwahrscheinlich werden zB Eingabefeld für Telefonnummer nur Ziffern als Eingabe zulässt
-
Helfen Fehler zu erkennen, verstehen und beheben - verständliche und gut sichtbare Fehlermeldungen
-
Hilfe und Dokumentation
-
-
-
Aufgabenangemessenheit
-
Selbstbeschreibungsfähigkeit
-
Erwartungskonformität
-
Erlernbarkeit
-
Steuerbarkeit
-
Robustheit gegen Benutzungsfehler
-
21.3. Versionierung
-
pre-alpha: Oft wird eine solche Version verwendet, wenn ein halbwegs fertiges Modul der Software vorgestellt werden soll. Eine weitere Bezeichnung ist die Entwicklervorschau (von englisch developer preview)
-
alpha: Die erste zum Test durch Fremde (also nicht die eigentlichen Entwickler) bestimmte Version. Noch nicht feature-complete.
-
beta:Eine Beta-Version ist die erste Version, die vom Hersteller zu Testzwecken veröffentlicht wird. Der Begriff ist nicht exakt definiert, als Faustregel zur Abgrenzung einer Beta-Version von anderen Versionen gilt in der Regel, dass in ihr zwar alle wesentlichen Funktionen des Programms implementiert, aber noch nicht vollständig getestet sind. Das Programm kann oder wird daher unter Umständen noch viele, evtl. auch schwerwiegende Fehler enthalten, die einen produktiven Einsatz nicht empfehlenswert machen.
-
release candidate: Darin sind alle Funktionen, die die endgültige Version der Software enthalten soll, schon verfügbar (sogenannter feature complete), alle bis dahin bekannten Fehler sind behoben. Aus dem Release Candidate wird vor der Veröffentlichung die endgültige Version erstellt, um einen abschließenden Produkttest oder Systemtest durchzuführen. Dabei wird die Qualität der Software überprüft und nach verbliebenen Programmfehlern gesucht.
