Steinmüllerallee 4
51643 Gummersbach
Gebäude LC4
Raum 1708 (Wegbeschreibung)
Sprechstunde nach Vereinbarung
Terminanfrage: calendly.com
Wenn Sie dieses Tool nicht nutzen wollen, schicken Sie eine Mail
und ich weise Ihnen einen Termin zu.
Softwaretechnik 2 (ST2), SS26
Die Veranstaltung ST2 versucht Sie mit grundlegenden Überlegungen beim Design und der Implementierung von komplexen Softwaresystemen vertraut zu machen. Ein besonderer Fokus liegt dabei auf den Konzepten des Domain-Driven Designs (DDD) und deren beispielhafter Umsetzung im Backend mittels Spring Boot.
Zeitraum und zeitliche Organisation der Veranstaltung
20.04.2026 - 24.07.2026. Organisiert als 6 Ganztages-Workshops (Montags 10:00 - 17:00). Genaue Daten und Inhalte stehen weiter unten.
Ort der Veranstaltung
Die Veranstaltung findet in Präsenz statt. In Ausnahmefällen (aber nur wenn explizit für den Tag kommuniziert) weichen wir auf eine Remote-Option (Videokonferenz) aus. Wenn mehrere Räume angegeben sind, dann schauen schauen Sie bitte bei dem jeweiligen Zeitschlitz oder Workshoptag nach (siehe unten auf dieser Seite), welcher Raum an welchem Tag genutzt wird. Falls auf dieser Seite keine Angaben sind, prüfen Sie bitte die sonstigen Kommunikationkanäle für diese Veranstaltung (z.B. Discord).
Raum:
KI-Labor 0503 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena. Das KI-Labor ist üblicherweise (anders als andere Hörsäle) abgeschlossen. Ich werde rechtzeitig da sein, um Sie einzulassen. Wenn Sie weit vor Beginn der Veranstaltung da sind, warten Sie am besten in einem der anderen Hörsäle - es gibt genügend Räume, die auch in der Regel nicht alle auf einmal belegt sind.), siehe auch
detaillierte Wegbeschreibung
Das Praktikum wird über eine Folge von personalisierten und individuell für Sie generierten Git-Repos durchgeführt. Für jeden Meilenstein erhalten Sie ein neues Repo von uns. Jede*r Teilnehmer*in muss eine eigenständige Bearbeitung der Praktikumsaufgabe durchführen. Wir ermutigen Sie ausdrücklich, Ihre Lösungen in Arbeitsgruppen zu diskutieren. Ein einfaches Copy-Paste von Lösungen (unter Anpassung der Personalisierung) werten wir aber als Täuschungsversuch. Studierende, bei denen wir dieses sehen (und wir haben automatisierte Möglichkeiten, dies zu sehen) werden ohne Vorwarnung vom Praktikum ausgeschlossen. Das gilt sowohl für die Person, die kopiert hat, wie auch für die-/denjenigen, die/der die Lösung zur Verfügung gestellt hat.
Für dieses Praktikum gilt ein "One Free Pass". Sie müssen nicht alle Meilensteine bestehen, sondern alle bis auf einen – ein Meilenstein kann ausgelassen werden. Wenn Sie einen Meilenstein auslassen möchten, arbeiten Sie einfach den nächsten Meilenstein. Die Abgabefristen der übrigen Meilensteine gelten weiterhin unverändert.
Anmeldung
zum Praktikum
Bitte werden Sie Mitglied
in dieser ILIAS/ILU-Gruppe
.
(liegt
in diesem ILIAS/ILU-Kurs).
Die Deadline ist 20.04.2026.
Bitte denken Sie daran, dass Sie sich zusätzlich noch über PSSO zur Prüfung anmelden müssen. Die Anmeldefristen dafür finden Sie auf den F10-Informationsseiten der TH Köln.
Verpflichtendes Beratungsgespräch
zu den Inhalten des Praktikums und zum Umgang mit KI
Jede*r Teilnehmer*in muss ein Pflichtgespräch mit einem Betreuer führen, um das Praktikum zu bestehen. In diesem Gespräch geht es darum, aufgetretene Schwierigkeiten zu besprechen, den eigenen Lösungsansatz zu erläutern und den Einsatz von KI-Tools zu reflektieren. Das Gespräch ist kein Test – niemand wird aufgrund dieses Gesprächs vom Praktikum ausgeschlossen.
(Auch wenn nur der Name vo n Fabian Krampe bei den Sprechstundenterminen genannt ist - die Termine
werden zwischen Stefan Bente und Fabian Krampe aufgeteilt. Wir entscheiden kurzfristig, wer welchen
Termin übernimmt. Eine gezielte Buchung bei einem von uns beiden wollen wir bewusst nicht anbieten.)
Raum:
3219 (Hauptgebäude am Campus Gummersbach, dritter Stock)
https://git.archi-lab.io/.
Bitte loggen Sie sich unbedingt vorab einmal mit Ihrer CampusId dort ein. Sonst kann das Repo Ihnen nicht automatisch zugewiesen werden.
KI-Hilfsmittel wie ChatGPT und Github Copilot
KI-Hilfsmittel dürfen Sie verwenden, aber genau wie bei jedem anderen Werkzeug sind Sie sind am Ende für das Ergebnis verantwortlich.
Wir werden das Thema "KI-Hilfsmittel" als dediziertes Thema in diesem Modul behandeln.
(Siehe auch
Learning Outcome
und
KI-Tools wie Claude, ChatGPT und Github Co-Pilot
.)
In der Klausur werden keine KI-Tools zur Verfügung stehen. Daher müssen Sie in jedem Fall in der Lage sein, die Aufgaben dieses Moduls auch selbstständig und ohne KI-Unterstützung zu lösen.
Discord-Server für schnelle Kommunikation
Discord hat sich als sehr effektive Plattform für den Informationsaustausch, Diskussionen und Fragen an Lehrende/Betreuer:innen erwiesen. Deshalb sollten Sie dem ArchiLab-Discord-Server beitreten unter
https://discord.gg/YYNYb5whU8.
Navigieren Sie zum Channel
#rollenzuweisung
und klicken Sie auf
st2.
Die entsprechenden Kanäle zur Veranstaltung werden anschließend für Sie freigeschaltet.
Youtube-Kanal
Für diese Veranstaltung sind Lehrvideos auf Youtube verfügbar. Abonnieren Sie dafür am besten den Kanal
ArchiLab.
Für die Videos zu dieser Veranstaltung gibt es eine
Playlist.
(Disclaimer - die Videos auf diesem Kanal sind nicht monetarisiert. Weder ich persönlich noch das Labor ArchiLab verdienen damit Geld. Wir nutzen YouTube vor allem deshalb, weil es für Studierende ein leicht zugänglicher Kanal ist. Außerdem bekommen wir als Labor an der TH Köln so auch Sichtbarkeit nach außen, was z.B. bei dem Einwerben von externen Gastvorträgen hilft.)
Script
Für diese Veranstaltung ist ein Script verfügbar
(in den Videos verwendete Folien als PDF, mit abschnittsweisen Links auf das entsprechende Video).
Im ST2-Praktikum wird großer Wert darauf gelegt, das theoretische Wissen auch praktisch umzusetzen. Folgendes Learning Outcome liegt der Veranstaltung zugrunde - das sollten Sie am Ende können, wenn Sie für sich das Beste aus der Veranstaltung herausholen.
Als SW-Entwickler:in oder SW-Architekt:in kann ich ein Softwaresystem für eine gegebene Aufgabenstellung iterativ konzipieren und mit gängigen Tools implementieren,
indem ich ...
passende Prinzipien, Patterns und Architekturstile für mein IT-System auswähle, wie etwa die SOLID-Prinzipien und die Regeln des Clean Code, und dann eine gängige Schichtenarchitektur auswähle,
ein Rich Domain Model nach dem Ansatz des Domain-Driven-Design (DDD) in Building Blocks konzipiere und mit Hilfe von Spring JPA umsetze,
meine Domäne(n) in Aggregates strukturiere,
diese Aggregates als REST Level 2 API für die Kommunikation mit Umsystemen und Clients verfügbar mache, und dies mit Spring Web MVC umsetze,
KI-Tools wie Claude, ChatGPT und Github Co-Pilot in der Softwareentwicklung einsetze, und mir deren Potential und Grenzen bewusst mache,
damit ich eine nachhaltig wartbare Software mit passender, langlebige und änderungsfähiger Architektur erstellt habe.
Workshops und Lehrmaterialien für diesen Kurs
Für den Kurs Softwaretechnik 2 findet nahezu vollständig nach dem Prinzip des Flipped Classroom statt. Das heißt, es wird
keine Vorlesungen im klassischen Sinne geben, sondern Ganztagesworkshops, in denen sich
gegebenenfalls ein kurzer Inhaltsimpuls abwechselt mit Einzel- und Gruppenarbeit. Insbesondere werden wir in
den Workshops schon anfangen, an den Praktikumsaufgaben zu arbeiten. Die Ergebnisse werden dann jeweils kurz
vorgestellt und es können Fragen zu dem Stoff und den Aufgaben diskutiert werden. Der Besuch der Workshops
ist also unbedingt zu empfehlen.
Die Inhalte für ST2 werden als Lehrmaterialien bereitgestellt. Das sind in erster Linie Videos, die jeweils unten bei den
Workshop-Tagen und den Meilensteinen aufgeführt sind. Daneben gibt es noch
Infoseiten und Beispiel-Repositories, die auch hier auf der Seite verlinkt sind. Für die vollständige
Liste schauen Sie bitte auch hier oben im Hauptmenü unter ST bei den jeweiligen Materialien-Links hinein:
Anschauen der Videos und Bearbeiten der Quizze
In den letzten Semestern haben wir festgestellt, dass die Videos in ST1 und ST2 nicht durchgehend angeschaut werden -
mutmaßlich, weil man mit KI und Google/ChatGPT-Suche auch schon irgendwie durchkommt. Mit so einer Strategie kann man
das Praktikum bestehen, aber wird in der Klausur schlechte Karten haben.
Um dem vorzubeugen, gibt es ab diesem Semester zu jedem der besonders relevanten Videos jeweils ein kurzes,
verpflichtendes Multiple-Choice-Quiz auf ILU. Sie können das Quiz so oft absolvieren, wie Sie wollen, aber Sie müssen jedes
der Quizze bestanden haben, sonst gilt Ihr Meilenstein als nicht bestanden und damit sind Sie aus dem Praktikum ausgeschieden.
Die Quizze sind so konzipiert, dass man sie nach Schauen der Videos einfach beantworten kann. Sie müssen also nicht
stundenlang lernen, um die Quizze zu bestehen, sondern einfach nur die Videos anschauen.
Die Links zu den Quizzes sind unten den Video-Icons in der Workshop- und Meilensteinliste verlinkt. Sie werden Stück für
Stück jeweils mit dem aktuellen Meilenstein freigeschaltet.
Regeln für das Praktikum
Für das Praktikum gelten die nachfolgenden Regeln.
Zusammenarbeit ist gewollt, simples Copy-Paste ist ein Täuschungsversuch
Jede*r Teilnehmer*in muss eine eigenständige Bearbeitung der Praktikumsaufgabe durchführen.
Wir ermutigen Sie ausdrücklich, Ihre Lösungen in Arbeitsgruppen zu diskutieren. Ein einfaches
Copy-Paste von Lösungen (unter Anpassung der Personalisierung) werten wir aber als
Täuschungsversuch.
Wir haben die Möglichkeit, die Lösungen automatisiert zu vergleichen und “merkwürdige” Ähnlichkeiten zu
erkennen. Das Tooling vergleicht Repos paarweise und deckt Code-Ähnlichkeiten mit großer Zuverlässigkeit auf.
Ein solches Kopieren von Lösungen ist ein Betrugsversuch und zieht einen sofortigen Ausschluss aus dem
Praktikum nach sich - und zwar sowohl für “Kopierer:in” wie auch für “Urheber:in” einer solchen Lösung.
Zusätzlich informieren wir den Prüfungsausschuss über den Vorfall, so dass Sie einen entsprechenden Eintrag
in Ihren Unterlagen erhalten. Bei schweren Fällen kann der Prüfungsausschuss Auflagen für das erneute
Absolvieren des Praktikums erlassen, oder noch weitergehende Maßnahmen ergreifen.
Wir werten auch das versuchte Umgehen unserer Maßnahmen zur Individualisierung (und den damit verbundenen
Kontrollmechanismen) als Täuschungsversuch.
Anderen direkten Zugriff auf das eigene Repo zu geben ist nicht erlaubt
Sie dürfen niemanden direkten Zugriff auf Ihr Repo geben. Weder durch Weitergabe Ihrer Zugangsdaten, noch
durch das Erstellen eines Personal / Project Access Tokens und dessen Weitergabe, Forken, einfaches Kopieren
der Sourcen und Verschicken, oder auf andere Weise.
Wer seine Lösung weitergibt, riskiert ebenfalls den Ausschluss aus dem Praktikum. Überlegen Sie sich
das gut, ob Sie das Risiko eingehen wollen, dass jemand anderes Ihre Lösung kopiert und Sie dann dafür
bestraft werden.
Was geht?
Wir möchten ausdrücklich, dass Sie über Lösungen diskutieren und diese auch gern gemeinsam erarbeiten.
Das Folgende ist also ok:
Das Modell, die Klassenstruktur und einen Algorithmus gemeinsam überlegen
Fragen diskutieren
Das Ergebnis dann jede/r für sich implementieren
In diesem Fall gibt unser Tooling keinen Match aus, weil Code schreiben so individuell wie Handschrift ist.
Ähnliche Klassenstrukturen sind ok, die werden nicht als Match gewertet, wenn der Code erkennbar einzeln geschrieben wurde.
Was geht NICHT?
Arbeitsteilig arbeiten (ich mache Service A, und du machst Service B, und dann tauschen wir
die Klassen aus und passen die Individualisierung an)
Gemeinsam im Pair Programming-Modus eine Lösung entwickeln und dann die Individualisierung anpassen
(Pair Programming ist ein guter und in der beruflichen Praxis oft genutzter Weg, um Software zu
entwickeln. Im Beruf machen das aber Entwickler:innen, die ihre Qualifikation schon praktisch bewiesen haben.
Hier möchten wir das bewusst ausschließen, damit jede/r von Ihnen sich einmal daran gewöhnt, eigenständig
komplexen Code zu schreiben.)
ganze Lösungen kopieren und die Individualisierung anpassen (oder Lösungen weitergeben).
So etwas findet unser Tooling.
Disclaimer zur Auswertung der Repo-Daten
Wir behalten uns vor, die Daten Ihrer Commits in dieses Repo zur Lernstandskontrolle
sowie - in anonymisierter Form - für die Beforschung der eigenen Lehre (SoTL, Scholarship of Teaching
and Learning) und bei der (Weiter-)Entwicklung von Lehrunterstützungs-Tools zu verwenden.
Bewertung (Klausur)
Die Bewertung von ST2 erfolgt über die ST2-Klausur in der Prüfungsphase in Juli. Die Klausur wird im PC-Pool der Hochschule geschrieben.
Es handelt sich um eine digitale Semi-Open-Book-Klausur.
Wie gewohnt erhalten Sie für die Klausur ein individualisiertes Repo, das nur Sie selbst und wir sehen können.
Vorher müssen wir Ihre Identität sicherstellen. Im Hörsaal ist das einfach - Kontrolle von MultiCa und
Personalausweis, plus Sichtkontrolle, ob Sie es selbst sind.
Erlaubte Hilfsmittel
Sie dürfen bestimmte Hilfsmittel zu nutzen. Dazu zählen:
Das “Bauzeichner 2.0”-Repo mit der
Anleitung, wie man das Dependency Inversion Principle anwendet, um Zykel aufzulösen
Die Materialien aus https://www.archi-lab.io/, allerdings weder die Videos
noch verlinkte Materialien, nur die auf der Seite direkt zugänglichen Materialien
Aufgrund der Veröffentlichung einer Probeklausur, die
nahe an der tatsächlichen Klausur liegt, müssen wir den Zugriff auf “mitgebrachte” Unterlagen (digital oder analog)
leider einschränken, damit die Klausur eine Aussagekraft hat. Sonst könnten Sie eine eigene oder fremde Lösung
dieser Probeklausur mitbringen und dann einfach - mit möglicherweise nur leichten Anpassungen - abschreiben.
Das wollen wir verhindern.
Auch die Nutzung der Praktikumsrepos wird während der Klausur nicht möglich sein.
Sie können sich also nicht darauf verlassen, dass Sie ähnliche Lösungen aus dem Praktikum einfach durch
Copy-Paste in Ihre Klausur einfügen können.
Nicht erlaubte Hilfsmittel
Blockiert und verboten sind:
Eigene Notizen auf Papier
Alle Repositories oder sonstigen digitalen Resourcen, eigene oder fremde, die nicht auf der Liste der erlaubten
Hilfsmittel stehen.
Kommunikation mit anderen Personen, z.B. über Discord-Chat, Telefon, SMS, WhatsApp, etc.
Sollte wir einen Verstoß gegen diese Regeln feststellen, so ist dies ein Täuschungsversuch im Sinne der Prüfungsordnung. Sie
müssen dann mit den entsprechenden Konsequenzen rechnen.
Inhalte der Klausur
Inhalt und Form der Klausur werden den Meilensteinen M0 - M4 ähneln, allerdings natürlich - wegen der begrenzten
Zeit - in deutlich komprimierter Form. Die Klausur wird aus mehreren Aufgaben bestehen, die Sie in beliebiger
Reihenfolge bearbeiten können. Die Aufgaben werden in sich abgeschlossen sein und bauen nicht aufeinander auf.
Es wird Code in der Klausur zu schreiben sein. Anders als im Praktikum wird der Code aber nicht automatisiert
getestet, sondern manuell von uns bewertet. Es wird vermutlich auch keine vordefinierten Tests in der Klausur
geben. Sie können gern selbst Tests schreiben. Bonuspunkte gibt es dafür (und für andere Extraleistungen) nur,
wenn in der Klausuraufgabe ausdrücklich vermerkt. Ihr Code muss nicht notwendig compilieren, allerdings kann
nicht compilierender Code Abzüge geben. Auch hierfür stehen die Details noch nicht fest, und ich verweise
auf die Aufgabenbeschreibungen in der Klausur.
Sie sollten davon ausgehen, dass alle Inhalte von M0 - M4 vorkommen können. Darüber hinaus werden die
wesentlichen Elemente von ST1 als bekannt und beherrscht vorausgesetzt - es kann also sein, dass Sie
z.B. mit Domain-Modellen (fachlich oder logisch) oder mit Status-Modellen umgehen müssen.
Das kann z.B. folgende Aufgabenstellungen bedeuten (Liste hat keinen Anspruch auf Vollständigkeit):
Analyse eines Code-Fragments bezüglich Verstöße gegen Clean-Code-Regeln
Dito für Verstöße gegen SOLID-Prinzipien
Refactoring eines Code-Fragments, um solche Verstöße zu beheben
Analyse eines Code-Fragments bezüglich sinnvoller Domain Primitives
Implementierung von Domain Primitives
Analyse von Aggregates anhand eines Domain Modells
Definition von REST-Endpoints
Festlegung von passenden REST-Returncodes für bestimmte Fehlersituationen
Implementierung von REST-Endpoints
Gezieltes Schreiben von Unit-Tests als Teil der Entwicklung
Verständnisfragen zu den Inhalten von M0 - M4
KI-Tools
KI-Tools (Claude, ChatGPT, GitHub Co-Pilot, …) stellen gerade eine Disruption der Arbeitsweise von
Softwareentwickler*innen dar. Sie sind mächtige Werkzeuge, die es ermöglichen, Code
wesentlich schneller zu schreiben (oder sich komplett schreiben zu lassen), sich Code erklären zu
lassen, Fehler zu finden, bislang unbekannte Frameworks und Sprachen schnell zu lernen, und vieles mehr.
Je komplexer die Software, desto wichtiger wird es, die KI-Tools verantwortungsvoll einzusetzen.
Sie müssen jederzeit in der Lage sein, Ihre eigene Software komplett zu verstehen, erklären
und ändern zu können. Sie sollten die KI steuern, nicht die KI Sie.
KI-Tools im Praktikum
Bei ArchiLab haben wir uns intensiv mit dem Einsatz von KI-Tools in Software-Entwicklung allgemein,
und in der Lehre im Besonderen, beschäftigt. Insbesondere soll das Praktikum auch ausdrücklich
praxisnah sein. Das heißt, wir verwenden Aufgabenstellungen, Technologie-Stacks und Entwicklungsmethoden,
wie man sie auch mehr oder weniger genau so in der aktuellen Praxis einsetzt.
Daher ist den Einsatz von KI-Tools im Praktikum ausdrücklich erlaubt. Das bedeutet, dass Sie im
Praktikum die Möglichkeit haben, KI-Tools zu nutzen. Verwendung von KI-Ergebnissen für das Praktikum
ist auch ausdrücklich KEIN Copy-Paste gemäß der obigen Regeln für die Zusammenarbeit.
Wir wollen aber auch, dass Sie im Praktikum trainieren, die KI (wie oben gesagt) verantwortungsvoll
einzusetzen. Das bedeutet vor allem zwei Dinge.
Sie müssen es auch ohne KI können. In der Klausur haben Sie keine KI-Tools zur Verfügung.
Sie müssen die KI-Nutzung transparent durch das Einchecken Ihrer Chatprotokolle belegen.
Transparenz der KI-Nutzung durch Einchecken von KI-Chatprotokollen
Wir als Lehrende müssen nachvollziehen können, wie Sie KI im Praktikum einsetzen. Nur dadurch können
wir Ihnen gezieltes Feedback geben. Um das sicherzustellen, können Sie im Praktikumsrepo angeben, ob
Sie KI verwendet haben oder nicht. Wenn ja, dann müssen Sie Ihre KI-Chatprotokolle in Ihrem Repo einchecken.
Eine Anleitung, wie Sie Chatverläufe aus den gängigen KI-Tools exportieren, finden Sie
auf dieser Infoseite.
Wenn wir den Eindruck haben, dass Ihre Angaben zur KI unglaubwürdig sind oder dass Sie die KI
“in Vertretung von Ihnen selbst” am Praktikum arbeiten lassen, dann entspricht das nicht
den Lernzielen der Lehrveranstaltung. Sie werden sowohl in der Klausur wie auch in der späteren
Berufspraxis Probleme bekommen.
Keine KI-Tools in der Klausur
In der Klausur werden wir den Einsatz von KI-Tools nicht erlauben. Insbesondere sollen Sie in dieser
Veranstaltung lernen, wie man Architektur großer Systeme gemäß aktuellen Regeln des Software-Engineering gestaltet.
Diese Architekturkompetenz müssen Sie grundsätzlich auch ohne KI leisten. Daher müssen Sie in der Klausur
nachweisen, dass Sie das wesentliche Handwerkszeug auch so beherrschen. Die Aufgaben in der Klausur sind
dafür natürlich weitaus einfacher als die im Praktikum, und lassen sich gut ohne KI-Tools lösen.
Wir werden KI-Tools in der Klausur technisch blockieren. Sie müssen also weiterhin Code im Rahmen
der Aufgabenstellung von ST2 selbst schreiben können. Ebenso müssen Sie Code verstehen, um ihn
zu verbessern (Refactoring). Außerdem müssen Sie die Konzepte beherrschen, die dem Code zugrunde liegen.
Oder, mit anderen Worten: Sie müssen die Aufgabenstellungen des Praktikums grundsätzlich auch ohne solche
Tools lösen können, sonst haben Sie keine Chance, die Klausur zu bestehen.
Die entsprechenden Kompetenzen kann man anhand der sogenannten
Bloom’s Revised Taxonomy einordnen.
Die Praktikumsaufgaben werden mit einer Markierung versehen, welcher Stufe der Taxonomie
sie entsprechen. Damit Sie sich die “höheren” Kompetenzen wie etwa “Analyse” aneignen können,
müssen Sie die entsprechenden Aktivitäten auch selbst und eigenständig durchgeführt haben. Auch
wenn Sie im praktischen Berufsleben KI-Tools als Hilfe nutzen.
Workshops
Mon 20.04.2026, 10:00 - 12:30: ST2-Kickoff
Ich stelle Ihnen den Inhalt von ST2 des Praktikums vor. Wir werden über die Neuerungen in diesem Semester sprechen, die mit der Verwendung von KI-Tools zusammenhängen. Dann werden wir uns inhaltlich den ersten Meilenstein M0 anschauen und mit der Modellierung beginnen. (Wir teilen uns diesen Workshoptag mit MCI, daher hören wir schon um 12.30 auf, aber für Sie geht es dann mit MCI bis zum späten Nachmittag weiter.)
Ort des Workshops
Raum:
KI-Labor 0503 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena. Das KI-Labor ist üblicherweise (anders als andere Hörsäle) abgeschlossen. Ich werde rechtzeitig da sein, um Sie einzulassen. Wenn Sie weit vor Beginn der Veranstaltung da sind, warten Sie am besten in einem der anderen Hörsäle - es gibt genügend Räume, die auch in der Regel nicht alle auf einmal belegt sind.), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie kennen die Rahmenbedingungen für ST2 und können mit dem ersten Meilenstein beginnen.
{"de"=>"Für das Restaurant-Fallbeispiel aus dem ST2-Praktikum ab Sommersemester 2026 machen wir ein paar initiale Modellierungen – Fachliches Datenmodell und einige Zustandsmodelle.\n", "en"=>"For the restaurant case study from the ST2 lab starting in summer semester 2026, we create some initial models – a conceptual data model and several state diagrams.\n"}
Vorstellung Meilenstein M0
gemeinsame Arbeit am logischen Datenmodell und an Zustandsmodellierung
12:30 - 13:30:
Mittagspause
13:30 - 17:00:
(... dann geht es für Sie mit den KollegInnen von MCI weiter ...)
Mon 04.05.2026, 10:00 - 17:00: Clean Code, SOLID, und Auflösen von Zyklen
In diesem Workshop geht es darum, die Clean Code & SOLID Prinzipien anzuwenden und Verstöße zu erkennen, sowie diese zu beheben. Darüber hinaus wenden Sie DDD-Konventionen an, insbesondere Vernon's Aggregate-Konventionen. Dazu nutzen Sie die aus Videos bekannte Vorgehensweise.
Ort des Workshops
Raum:
KI-Labor 0503 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena. Das KI-Labor ist üblicherweise (anders als andere Hörsäle) abgeschlossen. Ich werde rechtzeitig da sein, um Sie einzulassen. Wenn Sie weit vor Beginn der Veranstaltung da sind, warten Sie am besten in einem der anderen Hörsäle - es gibt genügend Räume, die auch in der Regel nicht alle auf einmal belegt sind.), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie können Clean Code, SOLID und Aggregate-Konventionen auf den eigenen Code anwenden.
Mon 01.06.2026, 10:00 - 17:00: Domain Primitives und Testing mit Mockito, JaCoCo und PIT
Es gibt verschiedene Mittel, um seinen Code so aufzubauen, dass er gut wartbar und leicht verständlich ist. Dazu gehören Domain Primitives (auch "Rich Domain Model" genannt). Das sind domänenspezifische Basisklassen mit Funktionalität und Validierung. Sie refactorn Ihren eigenen Praktikumscode, um passende Domain Primitives zu definieren. Darüber hinaus nutzen wir die DPs als kleinen, gut abgegrenzten Kontext, um die Nutzung von einem Integration-Test-Framework wie Mockito sowie den Tools JaCoCo und PIT für Testabdeckung und Mutation Testing zu demonstrieren.
Ort des Workshops
Raum:
KI-Labor 0503 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena. Das KI-Labor ist üblicherweise (anders als andere Hörsäle) abgeschlossen. Ich werde rechtzeitig da sein, um Sie einzulassen. Wenn Sie weit vor Beginn der Veranstaltung da sind, warten Sie am besten in einem der anderen Hörsäle - es gibt genügend Räume, die auch in der Regel nicht alle auf einmal belegt sind.), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie wissen, wie sinnvoll gewählte Domain Primitives in Ihrem Code aussehen, und können diese in Ihrem eigenen Code nutzen. Außerdem wissen Sie, wie Sie Mockito für Integrationstests nutzen können, und wie Sie JaCoCo und PIT einsetzen können, um die Qualität Ihrer Tests zu verbessern.
Mon 15.06.2026, 10:00 - 16:00: REST-API-Spezifikation und JaCoCo/PIT für alle eigenen Tests
Wir schauen uns an, wie man REST APIs definiert (als Vorbereitung von M4, wo wir sie implementieren). Darüber hinaus dehnen wir das "Monitoring" der eigenen Tests auf weitere selbst geschriebenen Tests aus und nutzen das konsequent als Entwicklungswerkzeug, um die Qualität der Tests zu verbessern.
Die Inhalte können in diesem und diesem Foliensatz nachgelesen werden.
Ort des Workshops
Raum:
KI-Labor 0503 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena. Das KI-Labor ist üblicherweise (anders als andere Hörsäle) abgeschlossen. Ich werde rechtzeitig da sein, um Sie einzulassen. Wenn Sie weit vor Beginn der Veranstaltung da sind, warten Sie am besten in einem der anderen Hörsäle - es gibt genügend Räume, die auch in der Regel nicht alle auf einmal belegt sind.), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie wissen, wie Sie Aggregates nutzen, um REST APIs zu definieren. Außerdem sind Ihre eigenen Tests soweit verbessert, dass sie eine wirkliche Unterstützung bei der Entwicklung sind - und Sie wissen, wie Sie das mit JaCoCo und PIT erreichen können.
Mon 06.07.2026, 10:00 - 17:00: REST-APIs mit Spring implementieren
Welche Prinzipien sollte man bei der REST-Implementierung einhalten? Wie macht man das in einem Framework wie Spring Boot? Zusätzlich vertiefen wir das Test-Thema weiter.
Ort des Workshops
Raum:
KI-Labor 0503 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena. Das KI-Labor ist üblicherweise (anders als andere Hörsäle) abgeschlossen. Ich werde rechtzeitig da sein, um Sie einzulassen. Wenn Sie weit vor Beginn der Veranstaltung da sind, warten Sie am besten in einem der anderen Hörsäle - es gibt genügend Räume, die auch in der Regel nicht alle auf einmal belegt sind.), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie wissen, wie Sie REST APIs mit Spring Boot implementieren und testen.
Mon 20.07.2026, 10:00 - 17:00: Probeklausur und Fragen zum Stoff
Wir schreiben eine Probeklausur und besprechen sie, zusammen mit anderen Fragen zum Stoff.
Ort des Workshops
Raum:
KI-Labor 0503 (Gebäude LC6, gegenüber dem Haupteingang der Schwalbe-Arena. Das KI-Labor ist üblicherweise (anders als andere Hörsäle) abgeschlossen. Ich werde rechtzeitig da sein, um Sie einzulassen. Wenn Sie weit vor Beginn der Veranstaltung da sind, warten Sie am besten in einem der anderen Hörsäle - es gibt genügend Räume, die auch in der Regel nicht alle auf einmal belegt sind.), siehe auch
detaillierte Wegbeschreibung.
Ziel des Tages
Sie wissen, was in der Klausur auf Sie zukommt, und wie Sie sich darauf vorbereiten können
Dann bearbeiten Sie unter Klausurbedingungen die Aufgaben, d.h. keine Gespräche untereinander, keine Diskussionen
Ich übernehme die Rolle der Klausuraufsicht und stehe für Fragen zur Verfügung
Nach 3 Stunden schließen wir die Klausur ab (die Klausur ist länger als die "richtige" Klausur, weil es eine Obermenge aller möglichen Aufgaben ist. Die echte Klausur ist nur 2h lang und enthält weniger Aufgaben.)
13:00 - 14:00:
Mittagspause
14:00 - 16:00:
Nachbesprechung der Probeklausur
Wir besprechen die Aufgaben der Probeklausur und stellen zumindest die Lösungsidee kurz vor. Eine Musterlösung gibt es nicht.
Sie können Fragen stellen und die Lösungen diskutieren
16:00 - 16:15:
Allgemeine Hinweise zur Klausur
Ich stelle kurz vor, was in der Klausur zu erwarten ist (siehe auch Inhalte der Klausur).
Sie können alle Fragen zur Klausur loswerden, die Sie noch haben.
16:15 - 17:00:
Retrospektive ST2 - Auswertung der Umfrage
Ich stelle die Ergebnisse der Feedback-Umfrage vor
Diskussion der Ergebnisse
Praktikums-Meilensteine
Das Praktikum gliedert sich in die folgenden Meilensteine. Sie müssen alle bis auf einen Meilenstein bestehen, um das Gesamtpraktikum zu bestehen – ein Meilenstein kann ausgelassen werden ("One Free Pass"). Die Tests eines bearbeiteten Meilensteins müssen komplett grün sein, um ihn zu bestehen.
M0: Initiale Implementierung, basierend auf Aggregates
In diesem Meilenstein implementieren Sie eine Aufgabenstellung gegen vorgegebene Acceptance Tests. Dabei muss Ihre Software in Aggregates aufgeteilt sein. Bei den ST2-Aufgaben bekommen Sie die Tests immer "für Sie geschrieben". Es kann auch in der realen Welt passieren, dass ein Auftraggeber für ein größeres Softwareprojekt Acceptance Tests schreibt. Diese Tests decken aber i.d.R. komplette Arbeitsabläufe ab. Sie müssen vollständig sein, aber nicht unbedingt "leicht zu verstehen". Stattdessen nutzt man in der Entwicklung Unit Tests und Integration Tests. Die können Sie auch zum Finden von Bugs nutzen, und gut zusammen zu Ihrem Code schreiben. Wenn Tests zusammen mit dem Code geschrieben werden, führt das zu besserer Wartbarkeit - gut testbarer Code ist meist auch gut strukturiert und modular. Daher werden Sie hier immer Unit- und Integrationstest zusammen mit dem Code schreiben.
Der Meilenstein wird
komplett automatisch (per Unit-Tests) überprüft.
M1: Clean Code, SOLID-Prinzipien und Auflösen von zyklischen Abhängigkeiten mittels DIP
In diesem Meilenstein geht es um das Refactoring Ihres Codes aus M0. Wir beschäftigen uns mit den Clean-Code-Regeln und den SOLID-Prinzipien. Insbesondere wenden Sie das Dependency-Inversion-Principle an, um zyklische Abhängigkeiten zu vermeiden. Dazu nutzen Sie die aus Videos bekannte Vorgehensweise. Außerdem werden ab diesem Meilenstein die Qualität Ihrer selbstgeschriebenen Tests mittels JaCoCo und PIT in der CI-Pipeline überprüft. Damit liegt der Fokus in diesem Meilenstein nur zum Teil auf neuen Features, sondern eher auf Refactoring und Verbesserung der Code-Qualität.
Der Meilenstein wird
komplett automatisch (per Unit-Tests) überprüft.
M2: Domain Primitives und Testing mit Mockito, JaCoCo und PIT
Sie machen ein Refactoring unserer Lösung, indem wir Domain Primitives verwenden. Darüber hinaus verwenden Sie für die kleine, abgegrenzte Codebasis der neuen Domain Primitives das Integration-Test-Framework Mockito sowie JaCoCo und PIT für Testabdeckung und Mutation Testing.
Der Meilenstein wird
komplett automatisch (per Unit-Tests) überprüft.
M3: REST-API-Design und JaCoCo/PIT für alle eigenen Tests
Aufbauend auf den Aggregates designen Sie ein REST-API für wesentliche Funktionalitäten. Darüber hinaus dehnen wir das "Monitoring" der eigenen Tests auf weitere selbst geschriebenen Tests aus und nutzen das konsequent als Entwicklungswerkzeug, um die Qualität der Tests zu verbessern.
Der Meilenstein wird
komplett automatisch (per Unit-Tests) überprüft.
M4: REST-API-Implementierung und weitere Vertiefung von Tests
Für eine Auswahl von REST-APIs machen wir eine Implementierung basierend auf Spring Data JPA und Spring Web MVC. Zusätzlich werden Tests für die REST APIs geschrieben.
Der Meilenstein wird
komplett automatisch (per Unit-Tests) überprüft.
