SpringBoot Teil 1: Ein erstes Projekt initialisieren
Mit dem SpringInitializr ein neues Projekt konfigurieren und anlegen, in der Projektstruktur zurechtfinden, einen “Hello World”-Webservice implementieren und starten.
Mit dem SpringInitializr ein neues Projekt konfigurieren und anlegen, in der Projektstruktur zurechtfinden, einen “Hello World”-Webservice implementieren und starten.
Tutorial zur Installation von Java, VSCodium und Gradle/Maven – als Intro zur mehrteiligen Artikelserie zu Java-Frameworks.
Am Beispiel Bubblesort wird auf vier verschiedene Arten die zyklomatische Komplexität bestimmt.
Wenn die grundlegenden Testfälle gegen die Anforderungen (aus Blackbox-Sicht) erstmal erstellt sind ist es an der Zeit, die Testgüte zu messen und gegebenenfalls darauf basierend weitere Tests zu erstellen.
Im Entity-Relationship-Modell lassen wir uns noch alle Wege offen: wie wollen wir die Daten persistieren? Als XML? Als Dictionary? Als relationale Datenbank? Erst im logischen Modell legen wir uns fest.
Unzureichend geplante Datenmodelle führen zu Inkonsistenzen und Problemen beim Löschen, Aktualisieren und Löschen. Wir wollen hier einen Blick auf das Regelwerk werfen, dass uns vor diesen Anomalien schützt – und herausfinden, ob man immer normalisieren muss.
Methoden werden schnell sehr komplex. Aber wie kann ich Komplexität messen? Wie kann ich sie vergleichen? Welche Komplexität ist noch in Ordnung?
Was passiert eigentlich, wenn ich nicht mehr 300 sondern 300.000 Datensätze bearbeiten muss? Welche Auswirkungen hat das auf die Laufzeit? Wie kann ich das im Vorhinein bestimmen?
Algorithmen können mit einem Programmablaufplan, Nassi-Shneiderman-Diagramm allgemeinverständlich ausgedrückt werden – oder eben mit Pseudocode. Welche Festlegungen gibt es eigentlich für Pseudocode?
UML-Usecase-Diagramme lassen sich mit vielen Tools erstellen. Um sie aber als versionierbaren Code direkt in die Readme-Dateien des Repositories zu übernehmen führt kaum ein Weg an PlantUML vorbei.
Ein Bild sagt mehr als tausend Worte: Funktionale Anforderungen lassen sich im Kundengespräch oft am schnellsten mit einem Diagramm zeichnen. Ein paar Strichmännchen, ein paar Ellipsen, ein Rechteck – aber was bedeuten die Notationsmittel genau, und wo setzte ich sie sinnvollerweise ein?
Anwendungsfälle stellen den Nutzen, den ein System für Benutzer*innen bereitstellt, in das Zentrum der Betrachtung. Mit ihnen können Anforderungen identifiziert und (tabellarisch oder als Diagramm) dokumentiert werden.
Anforderungen kommen nicht vom Himmel gefallen. Viele Projekte scheitern daran, dass nie hinreichend definiert wurde, was eigentlich die Ziele sein sollen. Wie kann eine systematische Anforderungsanalyse aussehen?