Die Druckversion wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

aiMOOC

Anwendungsentwicklung und Softwarequalität – Software in verständliche Bausteine zerlegen

QR-Code

Einleitung

Anwendungsentwicklung und Softwarequalität – Software in verständliche Bausteine zerlegen

Zielgruppe: Ausbildung Fachinformatik – Anwendungsentwicklung

Dauer: ca. 90 Minuten Grundlagen und Labor, anschließend Projektaufgaben

Ausbildungsfall: Du entwickelst eine kleine Bestellsoftware für einen fiktiven Schreibwarenladen.

Deine Lernziele:

Bausteine nach Verantwortlichkeiten trennen.
Schnittstellen eindeutig beschreiben.
Kopplung reduzieren und Kohäsion stärken.
Software mit lokalen Modultests überprüfen.
Architekturentscheidungen anhand der Softwarequalität begründen.

Sicherheitsregel: Alle Bestellungen sind erfunden. Die Python-Beispiele verwenden ausschließlich lokale Prozesse und Arbeitsspeicher. Keine fremden Netze, Produktivsysteme, Zugangsdaten oder Kundendaten verwenden. Externe Medien und Lernplattformen nur nach Freigabe aufrufen.

Lerneinheit 1: Eine Software, mehrere Bausteine

Zeit: 10 Minuten

Ein Programm muss nicht alle Aufgaben an einer Stelle erledigen. Modularisierung teilt die Anwendung in verständliche Einheiten.

Grafik: Symbole von Softwarekomponenten. Quelle: Wikimedia Commons, Nixdorf/Stannered, CC BY-SA 3.0.

Unser Ausbildungsfall

Ein Kunde bestellt zwei Hefte und einen Stift.

Artikel	Stückpreis	Anzahl	Betrag
Heft	2,50 €	2	5,00 €
Stift	1,50 €	1	1,50 €
Gesamt			6,50 €

Vier fachliche Aufgaben:

       BESTELLUNG
           |
     +-----+------+
     |            |
  Preislogik    Ablauf
     |            |
     +-----+------+
           |
         Ablage
           |
       Anzeige

Die Preislogik berechnet den Betrag. Der Ablauf koordiniert die Bestellung. Die Ablage speichert das Ergebnis. Die Anzeige stellt es verständlich dar.

Merke: Ein Baustein soll eine nachvollziehbare fachliche Verantwortung besitzen.

Video: David Tielke – Softwarearchitektur: Komponenten schneiden.

Mini-Aufgabe: Welcher Baustein sollte geändert werden, wenn ein Preisberechnungsfehler gefunden wird?

Feedback: Die Preislogik ist der erste Prüfpunkt, weil dort die Rechenregeln liegen. Eine Änderung an der Anzeige wäre keine passende Fehlerbehebung.

Lerneinheit 2: Verantwortung, Kohäsion und Kopplung

Zeit: 10 Minuten

Grafik: Kopplung und Kohäsion, Wikimedia Commons, Евгений Мирошниченко, CC0 1.0.

Begriff	Bedeutung	Ziel
Kohäsion	Fachlich zusammengehörige Aufgaben innerhalb eines Bausteins	Möglichst hoch
Kopplung	Abhängigkeiten zwischen Bausteinen	Möglichst gering
Single Responsibility	Verantwortung nach fachlichen Änderungsgründen abgrenzen	Verständliche Zuständigkeiten

Beispiel:

Die Preisberechnung soll nicht selbst eine Datenbankverbindung herstellen.

Warum? Eine geänderte Speichertechnik sollte keine Änderung an der Preisformel erzwingen.

Das Single-Responsibility-Prinzip bedeutet nicht einfach, dass eine Klasse nur eine Methode haben darf. Entscheidend ist, welche fachlichen Anforderungen und Akteure Änderungen auslösen.

Video: the native web – Das Single-Responsibility-Prinzip.

Entscheide: Soll eine Funktion gleichzeitig Preise berechnen, Nachrichten verschicken und Rechnungen ausdrucken?

Feedback: Diese Verantwortlichkeiten sollten normalerweise getrennt werden, weil sie aus unterschiedlichen Gründen geändert werden können.

Lerneinheit 3: Schnittstellen verständlich gestalten

Zeit: 10 Minuten

Eine Schnittstelle beschreibt, wie Bausteine miteinander zusammenarbeiten.

Sie legt insbesondere Eingaben, Ausgaben und erwartetes Verhalten fest.

Grafik: Beispiel eines Sequenzdiagramms, Wikimedia Commons, Dannyc20, CC BY-SA 3.0.

Schnittstellenvertrag unseres Programms

Baustein	Aufruf	Ergebnis
Preislogik	betrag_cent(positionen)	Gesamtbetrag als Integer in Cent
Ablauf	abschliessen(nummer, positionen, ablage)	Gesamtbetrag in Cent
Ablage	speichere(nummer, betrag_cent)	Speichert einen Eintrag ohne Rückgabewert
Anzeige	als_euro(cent)	Formatierte Zeichenkette

Vereinbarungen:

Geldbeträge werden als ganze Centbeträge verarbeitet.
Eine Bestellposition besteht aus Artikelname, Centpreis und positiver Stückzahl.
Ungültige Positionen erzeugen einen ValueError.
Vor einer erfolgreichen Preisprüfung wird nichts gespeichert.

Abhängigkeiten austauschbar machen

Grafik: Beispiel für Dependency Injection, Wikimedia Commons, Frap, CC0 1.0.

Bei Dependency Injection erhält ein Baustein benötigte Abhängigkeiten von außen.

Unser Bestellablauf bekommt deshalb ein Ablageobjekt als Parameter. Es muss lediglich die vereinbarte Methode bereitstellen.

Eine echte Datenbank ist dafür nicht erforderlich.

Video: The Morpheus Tutorials – Dependency Injection, deutsch.

Lerneinheit 4: Lokales Python-Labor

Zeit: 30 Minuten

Du baust jetzt die Bestellsoftware selbst zusammen.

Voraussetzung: Python 3.9 oder neuer, Texteditor und Terminal.

Laborregeln: Eigener lokaler Übungsordner, ausschließlich fiktive Daten, keine zusätzlichen Pakete, keine Netzwerkzugriffe. Eine virtuelle Python-Umgebung trennt Python-Pakete, ist aber keine Sicherheits-Sandbox für unbekannten Code.

Schritt 1: Projektstruktur

bestelllabor/
|-- preise.py
|-- service.py
|-- speicher.py
|-- demo.py
|-- test_service.py

Erstelle die fünf Dateien mit genau den folgenden Inhalten.

Schritt 2: Preislogik

Datei: preise.py

def betrag_cent(positionen):
    """Position: (artikel, preis_cent, anzahl)."""
    gesamt = 0
    for artikel, preis, anzahl in positionen:
        if (not isinstance(artikel, str) or not artikel.strip()
                or type(preis) is not int or type(anzahl) is not int
                or preis < 0 or anzahl < 1):
            raise ValueError("Ungueltige Position")
        gesamt += preis * anzahl
    return gesamt

def als_euro(cent):
    return f"{cent // 100},{cent % 100:02d} EUR"

Beobachte: Die Berechnung kennt weder den Bestellablauf noch eine Ablage.

Schritt 3: Lokale Ablage

Datei: speicher.py

class Merkspeicher:
    """Nur RAM; keine Datei und keine Datenbank."""
    def __init__(self):
        self.daten = {}

    def speichere(self, nummer, betrag_cent):
        self.daten[nummer] = betrag_cent

Beobachte: Die Ablage speichert nur in einem Python-Dictionary. Nach Programmende bleiben die Daten nicht erhalten.

Schritt 4: Bestellablauf

Datei: service.py

from preise import betrag_cent

def abschliessen(nummer, positionen, ablage):
    """Vertrag: ablage.speichere(nummer, betrag_cent)."""
    if not isinstance(nummer, str) or not nummer.strip():
        raise ValueError("Bestellnummer fehlt")
    betrag = betrag_cent(positionen)
    ablage.speichere(nummer, betrag)
    return betrag

Beobachte: Der Ablauf kennt nur die Methode speichere. Er ist nicht an eine konkrete Datenbank gebunden.

Schritt 5: Interaktive lokale Simulation

Datei: demo.py

from preise import als_euro
from speicher import Merkspeicher
from service import abschliessen

wahl = input("Anzahl Hefte (1 oder 2): ").strip()
if wahl not in ("1", "2"):
    raise SystemExit("Nur 1 oder 2 eingeben.")

positionen = [("Heft", 250, int(wahl)),
              ("Stift", 150, 1)]
ablage = Merkspeicher()
gesamt = abschliessen("B-001", positionen, ablage)

print("1 # entspricht 50 Cent")
for artikel, preis, anzahl in positionen:
    cent = preis * anzahl
    print(f"{artikel:6} {cent:4} Cent | {'#' * (cent // 50)}")
print("Gesamt:", als_euro(gesamt))
print("RAM:", ablage.daten)

Die Simulation fragt lokal eine Menge ab. Sie erzeugt keine Netzwerkanfragen.

Schritt 6: Lokal ausführen

Erstelle im Projektordner optional eine virtuelle Umgebung:

python -m venv .venv

Linux oder macOS:

.venv/bin/python -B demo.py

Windows:

.venv\Scripts\python.exe -B demo.py

Gib zunächst 2 ein.

Erwartete Ausgabe:

Anzahl Hefte (1 oder 2): 2
1 # entspricht 50 Cent
Heft    500 Cent | ##########
Stift   150 Cent | ###
Gesamt: 6,50 EUR
RAM: {'B-001': 650}

Die Balken sind eine einfache Datenvisualisierung. Ein Zeichen steht für 50 Cent.

Experiment: Starte erneut mit der Menge 1. Der Gesamtbetrag beträgt dann 4,00 EUR.

Lerneinheit 5: Softwarequalität durch Tests

Zeit: 15 Minuten

Grafik: Testing Pyramid, Wikimedia Commons, Abbe98, CC BY-SA 4.0.

Softwaretests überprüfen erwartetes Verhalten.

Unit-Tests prüfen kleine Einheiten. Integrationstests prüfen das Zusammenspiel mehrerer Einheiten. End-to-End-Tests betrachten größere Abläufe.

Die Testpyramide ist ein Orientierungsmodell, keine starre Zahlenregel.

Video: Datamics – Python: Code testen mit unittest, deutsch.

Isolierter Test mit Testdouble

Ein Testdouble ersetzt für den Test eine Abhängigkeit.

Datei: test_service.py

import unittest
from preise import betrag_cent
from service import abschliessen

class TestAblage:
    def __init__(self):
        self.aufrufe = []

    def speichere(self, nummer, betrag_cent):
        self.aufrufe.append((nummer, betrag_cent))

class BestellTests(unittest.TestCase):
    def test_betrag(self):
        daten = [("Heft", 250, 2), ("Stift", 150, 1)]
        self.assertEqual(betrag_cent(daten), 650)

    def test_menge_null(self):
        with self.assertRaises(ValueError):
            betrag_cent([("Heft", 250, 0)])

    def test_schnittstelle(self):
        ablage = TestAblage()
        wert = abschliessen("B-001", [("Heft", 250, 2)], ablage)
        self.assertEqual(wert, 500)
        self.assertEqual(ablage.aufrufe, [("B-001", 500)])

    def test_fehler_speichert_nicht(self):
        ablage = TestAblage()
        with self.assertRaises(ValueError):
            abschliessen("B-002", [("Heft", 250, -1)], ablage)
        self.assertEqual(ablage.aufrufe, [])

if __name__ == "__main__":
    unittest.main()

Linux oder macOS:

.venv/bin/python -B -m unittest -v test_service

Windows:

.venv\Scripts\python.exe -B -m unittest -v test_service

Erwartetes Ergebnis: Vier erfolgreiche Tests und die Meldung OK.

Test	Was wird geprüft?	Warum ist das wichtig?
Betrag	650 Cent für die Beispielbestellung	Rechenfehler werden erkannt
Menge null	ValueError	Ungültige Daten werden abgelehnt
Schnittstelle	Korrekte Parameter an speichere	Zusammenarbeit bleibt überprüfbar
Fehlgeschlagene Bestellung	Kein Speicheraufruf	Ungültige Ergebnisse werden nicht abgelegt

Wichtig: Die Tests belegen nur die geprüften Eigenschaften. Sie beweisen keine vollständige Fehlerfreiheit.

Vertiefung auf Englisch: Corey Schafer – Unit Testing with unittest.

Lerneinheit 6: Architektur bewerten

Zeit: 10 Minuten

Ein modularer Aufbau kann Änderungen vereinfachen, erzeugt aber auch zusätzliche Schnittstellen. Die richtige Aufteilung hängt von Anforderungen und Änderungsrisiken ab.

Grafik: Model-View-Controller als weiteres Trennungsbeispiel. Wikimedia Commons, Gfbares/Stannered, gemeinfrei.

Drei Prüffragen:

Ist die Verantwortung des Bausteins eindeutig?
Ist seine Schnittstelle verständlich und testbar?
Kann eine interne Änderung erfolgen, ohne unnötig andere Bausteine anzupassen?

Nach ISO/IEC 25010 kann Softwarequalität anhand verschiedener Merkmale betrachtet werden. Für diesen Kurs stehen insbesondere Wartbarkeit und Testbarkeit im Vordergrund.

Gestufte Hilfen für das Labor

Versuche die Aufgabe zunächst ohne Hilfe. Öffne dann die Hinweise nacheinander.

Hilfe 1 – Orientierung

Zeichne die Module als Rechtecke und verbinde sie nur dort, wo tatsächlich ein Aufruf stattfindet. Unterscheide die Richtung eines Aufrufs von der Rückgabe.

Hilfe 2 – Schnittstellen

Untersuche den Parameter ablage in abschliessen. Welche einzige Methode erwartet der Ablauf? Welche Informationen muss diese Methode erhalten?

Hilfe 3 – Teststrategie

Erzeuge ein neues Testdouble mit einer leeren Liste. Protokolliere Speicheraufrufe. Vergleiche danach die Liste mit dem erwarteten Ergebnis. Bei ungültiger Menge muss sie leer bleiben.

Interaktive Aufgaben

Quiz: Teste Dein Wissen

Was beschreibt Modularisierung? (Die Aufteilung einer Anwendung in sinnvolle Bausteine) (!Die vollständige Entfernung aller Funktionen) (!Die ausschließliche Verwendung einer einzigen Datei) (!Das automatische Veröffentlichen einer Anwendung)

Welche Aufgabe hat die Preislogik im Ausbildungsfall? (Sie berechnet den Gesamtbetrag) (!Sie versendet Nachrichten) (!Sie verwaltet Netzwerkverbindungen) (!Sie installiert Datenbanken)

Was ist mit hoher Kohäsion gemeint? (Die Aufgaben innerhalb eines Moduls gehören fachlich zusammen) (!Alle Module haben denselben Quelltext) (!Jeder Baustein greift direkt auf alle anderen zu) (!Alle Funktionen werden in einer Klasse gesammelt)

Worauf bezieht sich Kopplung? (Auf Abhängigkeiten zwischen Bausteinen) (!Auf die Bildschirmauflösung) (!Auf die Geschwindigkeit des Tastaturanschlags) (!Auf die Anzahl der Kommentare)

Welche Information gehört zu einem Schnittstellenvertrag? (Erwartete Eingaben und Ergebnisse) (!Die Lieblingsfarbe des Programmierers) (!Die Größe des Monitors) (!Die Anzahl der Computer im Raum)

Warum wird ein Geldbetrag hier als Integer in Cent verarbeitet? (Um die Rechnung mit ganzen Centbeträgen durchzuführen) (!Um automatisch eine Datenbank anzulegen) (!Um jede Eingabeprüfung überflüssig zu machen) (!Um das Programm im Internet zu veröffentlichen)

Was prüft ein Unit-Test? (Das Verhalten einer kleinen testbaren Einheit) (!Nur die Gestaltung des Firmenlogos) (!Immer alle Produktionsserver gleichzeitig) (!Ausschließlich die Hardwaretemperatur)

Wozu dient eine Testablage? (Sie ersetzt eine Abhängigkeit und zeichnet Aufrufe auf) (!Sie lädt echte Kundendaten herunter) (!Sie umgeht Zugangskontrollen) (!Sie löscht fremde Datenbanken)

Was geschieht bei einer Bestellposition mit Menge null? (Es wird ein ValueError ausgelöst) (!Die Menge wird automatisch erhöht) (!Es wird eine E-Mail versendet) (!Die Bestellung wird ohne Prüfung gespeichert)

Was bedeutet Refactoring? (Die innere Code-Struktur bei gleichbleibendem äußerem Verhalten verbessern) (!Eine Anwendung ohne Tests beliebig verändern) (!Alle Funktionen durch Netzwerkaufrufe ersetzen) (!Fehlermeldungen grundsätzlich ignorieren)

Memory

Kohäsion	Fachlich zusammengehörige Aufgaben innerhalb eines Bausteins
Kopplung	Abhängigkeit zwischen Softwarebausteinen
Schnittstelle	Vereinbarung über das Zusammenwirken von Bausteinen
Fachlogik	Berechnung des Bestellbetrags
Merkspeicher	Ablage ausschließlich im Arbeitsspeicher
Testdouble	Kontrollierbarer Ersatz einer Abhängigkeit
Refactoring	Strukturverbesserung ohne Änderung des beobachtbaren Verhaltens

Drag and Drop

Ordne die richtigen Begriffe zu.	Verantwortung
Preislogik	Gesamtbetrag berechnen
Bestellablauf	Bestellung koordinieren
Merkspeicher	Ergebnisse im Arbeitsspeicher ablegen
Benutzerdialog	Eingaben entgegennehmen
Testdouble	Speicheraufrufe kontrolliert beobachten

Kreuzworträtsel

Modul	Wie heißt eine abgrenzbare Programmeinheit?
Kopplung	Welcher Begriff beschreibt Abhängigkeiten zwischen Softwarebausteinen?
Kohaesion	Wie heißt der fachliche Zusammenhalt innerhalb eines Moduls?
Schnittstelle	Was regelt den vereinbarten Austausch zwischen Bausteinen?
Refactoring	Wie heißt eine Strukturverbesserung bei gleichbleibendem Verhalten?
Testdouble	Wie nennt man den kontrollierbaren Ersatz einer Abhängigkeit im Test?

LearningApps

Die folgende externe Suche ist optional. Nutze sie nur, wenn die Lernplattform im Unterricht freigegeben ist. Verwende keine personenbezogenen Daten.

Lückentext

Die Aufteilung einer Anwendung in logische Bausteine nennt man

.

Der fachliche Zusammenhalt innerhalb eines Moduls heißt

.

Die Abhängigkeit zwischen Bausteinen wird als

bezeichnet.

Eine Vereinbarung über den Aufruf eines Bausteins heißt

.

Die Regeln zur Berechnung des Bestellbetrags gehören zur

.

Geldbeträge werden im Beispiel als ganze

verarbeitet.

Die Klasse Merkspeicher legt Ergebnisse im

ab.

Ein Ersatz für eine echte Abhängigkeit im Test heißt

.

Das Python-Testframework im Kurs heißt

.

Eine Strukturverbesserung bei gleichbleibendem Verhalten nennt man

.

Offene Aufgaben

Die zwölf Aufgaben sind nach Schwierigkeit gestaffelt. Das Feedback beschreibt jeweils, woran Du eine tragfähige Lösung erkennst.

Leicht – Basisaufgaben

B1 – Bausteine erkennen: Zeichne die vier Verantwortlichkeiten des Bestellprogramms und beschrifte sie. Feedback: Die Zuordnung ist überzeugend, wenn Berechnung, Ablauf, Ablage und Anzeige unterscheidbar sind, weil sie unterschiedliche Aufgaben erfüllen.
B2 – Vertrag beschreiben: Dokumentiere die Eingabe und die Rückgabe von betrag_cent. Feedback: Ein guter Vertrag nennt die Struktur der Positionen, Cent als Einheit und das Fehlerverhalten, weil sonst Missverständnisse entstehen.
B3 – Verantwortung bewerten: Erkläre, warum die Preislogik keine Nachrichten verschicken soll. Feedback: Deine Begründung ist stark, wenn Du unterschiedliche Änderungsgründe und die daraus entstehende Kopplung benennst.
B4 – Tests ausführen: Starte alle vier lokalen Tests und halte das Ergebnis fest. Feedback: Der Nachweis ist vollständig, wenn alle Tests erfolgreich sind und Du auch erklärst, welches Verhalten geprüft wurde.

Standard – Anwendungsaufgaben

A1 – Fehlerfall ergänzen: Füge einen Test für einen negativen Preis hinzu. Feedback: Ein erwarteter ValueError ist sinnvoll, weil ein negativer Stückpreis im vereinbarten Beispiel unzulässig ist.
A2 – Testdouble austauschen: Schreibe eine zweite Ablageklasse, die erfolgreiche Speicheraufrufe zählt. Feedback: Der Ablauf muss unverändert bleiben, weil er nur den vereinbarten Methodenaufruf kennen soll.
A3 – Anzeige trennen: Verschiebe als_euro in eine neue Datei anzeige.py und passe demo.py an. Feedback: Die Änderung verbessert die Abgrenzung, wenn alle bisherigen Ergebnisse gleich bleiben und die Tests weiterhin erfolgreich sind.
A4 – Balkendiagramm vergleichen: Starte die Simulation mit einer und mit zwei Heft-Einheiten und interpretiere beide Balkendiagramme. Feedback: Der Vergleich ist richtig, wenn sich nur der Heftbetrag um 250 Cent verändert und die Summe entsprechend steigt.

Schwer – Transferaufgaben

T1 – Rabattmodul entwerfen: Ergänze einen Baustein für zehn Prozent Rabatt. Lege eine eindeutige Rundungsregel für Centbeträge fest und teste Grenzfälle. Feedback: Die Lösung ist nachvollziehbar, wenn Rabattregel, Rundung und Schnittstelle dokumentiert sind, weil sonst unterschiedliche Ergebnisse entstehen können.
T2 – Ablage austauschen: Entwickle eine Listenablage, ohne den Bestellablauf zu verändern. Feedback: Ein erfolgreicher Austausch zeigt eine geringe Abhängigkeit zur Speicherimplementierung, weil nur derselbe Vertrag benötigt wird.
T3 – Speicherausfall simulieren: Erzeuge ein Testdouble, das beim Speichern einen RuntimeError auslöst, und teste das Verhalten des Ablaufs. Feedback: Deine Analyse ist gut, wenn Du zwischen Preisprüfung und Speicherfehler unterscheidest und eine sinnvolle Fehlerstrategie begründest.
T4 – Neues Fachproblem übertragen: Übertrage die Bausteinidee auf eine fiktive Bibliotheksausleihe. Zeichne Verantwortlichkeiten, Schnittstellen und mindestens drei Tests. Feedback: Ein überzeugender Entwurf trennt Ausleihregeln, Ablauf und Ablage, weil sich diese Bereiche unabhängig ändern können.

Lernkontrolle

Bearbeite die folgenden Aufgaben schriftlich oder anhand von lokalem Code. Begründe jeweils Deine Entscheidung.

Änderungsanalyse: Eine neue Anforderung verändert nur die Anzeige von Geldbeträgen. Welche Module sollten betroffen sein? Begründe anhand der Abhängigkeitsstruktur.
Architekturvergleich: Vergleiche eine einzige große Funktion mit der modularen Bestellsoftware hinsichtlich Testbarkeit, Verständlichkeit und Änderungsaufwand.
Schnittstellenänderung: Die Ablage soll künftig zusätzlich eine Uhrzeit speichern. Entwickle zwei Lösungsvarianten und bewerte ihre Auswirkungen auf bestehende Bausteine.
Fehlersuche: Ein Bestellbetrag ist korrekt, wird aber nicht gespeichert. Entwickle eine schrittweise Teststrategie, um den betroffenen Baustein einzugrenzen.
Qualitätsbewertung: Begründe, warum vier bestandene Tests noch keinen vollständigen Qualitätsnachweis darstellen.
Transfer: Ein Kollege will alle Module wieder in einer großen Datei zusammenführen. Erkläre, wann dies vertretbar sein kann und welche Nachteile auftreten können.

Lernnachweis

Für Deinen Lernnachweis erstellst Du eine kleine Projektdokumentation mit folgenden Bestandteilen:

Architekturdiagramm: Mindestens vier verständlich beschriftete Verantwortlichkeiten und ihre Verbindungen.
Schnittstellendokumentation: Eingaben, Ausgaben, Datentypen beziehungsweise Formate und Fehlerfälle der zentralen Aufrufe.
Lauffähiger Quelltext: Die Module des fiktiven Bestellprogramms mit nachvollziehbarer Aufgabenteilung.
Testnachweis: Mindestens vier erfolgreiche lokale Tests, darunter ein ungültiger Eingabefall und ein Test mit austauschbarer Ablage.
Transferleistung: Eine neue Anforderung mit begründeter Architekturentscheidung und passendem Test.
Reflexion: Eine kurze Erklärung, wo die Lösung gut wartbar ist und welche Grenzen sie besitzt.

Bewertungsraster:

Kriterium	Punkte
Verständliche Verantwortlichkeiten	20
Klare Schnittstellen	20
Funktionierende lokale Umsetzung	20
Aussagekräftige Tests	20
Begründete Transferentscheidung und Reflexion	20
Gesamt	100

Erfolgsorientierung: Wichtig ist nicht die Anzahl der Dateien, sondern ob Du Deine Modulgrenzen fachlich begründen und deren Zusammenarbeit nachweisen kannst.

OERs zum Thema

Wikipedia – Modulare Programmierung

Weitere fachliche Quellen:

Python-Dokumentation: unittest – Testfälle, Assertions und Testausführung.
Python-Dokumentation: venv – Virtuelle Python-Umgebungen.
Martin Fowler: Layering Principles – Kopplung, Kohäsion und Trennung von Verantwortlichkeiten.
ISO/IEC 25010:2023 – Offizielle Übersicht über das Software-Produktqualitätsmodell.
Wikipedia: Modulare Programmierung – Grundlagen.
Wikipedia: Single-Responsibility-Prinzip – Verantwortlichkeiten und Änderungsgründe.

Medienrechte und Nachweise

Die eingebundenen Wikimedia-Dateien wurden anhand ihrer Dateibeschreibungsseiten ausgewählt.

Medium	Urheber bzw. Quelle	Lizenz
Software components.svg	Nixdorf, nachgezeichnet von Stannered	CC BY-SA 3.0
CouplingVsCohesion.svg	Евгений Мирошниченко	CC0 1.0
Sequence diagram.png	Dannyc20	CC BY-SA 3.0
Dependency injection example app.svg	Frap	CC0 1.0
Testing Pyramid.svg	Abbe98	CC BY-SA 4.0
ModelViewControllerDiagram.svg	Gfbares, nachgezeichnet von Stannered	Gemeinfrei

Die Lizenzen und gegebenenfalls erforderlichen Namensnennungen und Weitergabebedingungen sind auf den verlinkten Commons-Dateiseiten dokumentiert.

YouTube: Die eingebundenen Videos wurden über ihre konkreten YouTube-Seiten identifiziert. Eine freie Wiederverwendungslizenz wurde nicht vorausgesetzt. Die Videos dürfen deshalb nicht ohne zusätzliche Rechteprüfung kopiert, heruntergeladen oder als eigene OER weiterveröffentlicht werden. Beim Abruf externer Medien können Verbindungsdaten an die jeweiligen Anbieter gelangen.

Technik und Datenschutz: Die Python-Übungen sind eigenständige, lokale Beispiele. Externe Medien, Wikipedia und LearningApps sind optionale Unterrichtsressourcen und für die Ausführung der Programme nicht erforderlich.