MINT lernen

Übungen: Projekt: Software im Team

Vier Leute, vier Klassen, ein Programm: Es funktioniert nur, wenn alle sich vorher auf dieselben Methodenköpfe einigen.

Dein Fortschritt:
0 / 0 Aufgaben
1

Übungsaufgaben

Zehn Übungen zum Klicken, Ziehen und Knobeln — von AFB I bis AFB III. Jede Übung gibt dir sofort Rückmeldung; wenn du hängst, helfen dir die gestuften Tipps.

A1
Projektphasen der Schülerzeitungs-App
AFB I

Ein Informatikkurs entwickelt für die Schülerzeitung eine App, in der Artikel eingereicht, geprüft und veröffentlicht werden. Ordne jede Tätigkeit der passenden Projektphase zu.

Ziehe jede Karte in den passenden Korb — oder wähle sie mit Enter aus und drücke dann die Ziffer des Korbs (0 legt sie zurück).
1Analyse
2Entwurf
3Implementierung
4Test
Die Analyse klärt, was die Software leisten soll (Anforderungen, Pflichtenheft). Der Entwurf legt fest, wie sie aufgebaut ist (Klassen, Attribute, Methodenköpfe). Erst dann wird implementiert und getestet. Typischer Fehler: das Festlegen der Methodenköpfe zur Implementierung zählen. Die Köpfe sind aber Teil des Entwurfs — sie bilden die Schnittstelle, auf die sich alle verlassen, bevor jemand Code schreibt.
Ansatz: Frage bei jeder Karte: Geht es um Wünsche, um den Bauplan, um Code oder ums Überprüfen?
Weiter: Methodenköpfe und Klassendiagramm gehören zum Entwurf — auch wenn sie schon nach Java aussehen.
A2
Das Klassendiagramm als Vertrag
AFB I

Drei Teams programmieren ein Escape-Room-Spiel für den Tag der offenen Tür. Team A schreibt die Klasse Raum, Team B die Klasse Raetsel, Team C die Steuerung. Vorher vereinbaren alle ein Klassendiagramm. Welche Aussagen stimmen?

Mehrere Antworten sind richtig. Markiere alle zutreffenden und klicke dann auf „Prüfen“.
Das Klassendiagramm ist ein Vertrag: Jedes Team verlässt sich darauf, dass die vereinbarten öffentlichen Methoden genau so heißen und funktionieren. Deshalb kann Team C parallel arbeiten. Private Attribute sind gerade nicht Teil der Schnittstelle — sie darf jedes Team frei ändern. Eine Umbenennung einer öffentlichen Methode bricht dagegen den Vertrag: Der Code der anderen lässt sich nicht mehr übersetzen.
Ansatz: Überlege, was ein anderes Team von deiner Klasse wissen muss, um sie zu benutzen.
Weiter: Öffentliche Methodenköpfe gehören zur Schnittstelle, private Attribute und die Umsetzung im Rumpf nicht.
A3
Fachbegriffe beim Sportfest-Projekt
AFB I

Ein Kurs programmiert die Auswertung für das Sportfest. Setze die Fachbegriffe ein — einer bleibt übrig.

Wort anklicken, dann Lücke anklicken (oder umgekehrt) — mit Tab und Enter geht es genauso. Ein Klick auf eine gefüllte Lücke legt das Wort zurück.

Zuerst sammelt das Team mit der Sportfachschaft die , z. B. „Für jeden Lauf wird die Zeit in Zehntelsekunden erfasst“. Das Ergebnis wird im festgehalten, das beide Seiten abstimmen. Im Entwurf entsteht daraus ein mit den Klassen Teilnehmerin, Disziplin und Ergebnis. Die öffentlichen Methodenköpfe bilden die , auf die sich alle Teams verlassen. Schon vor der Implementierung legt das Team fest: Eingabe 12,4 s beim 100-m-Lauf → erwartet 11 Punkte. Das ist ein .

Vererbung bleibt übrig — sie gehört nicht zum Stoff des Grundkurses und hat mit dem Projektablauf nichts zu tun. Oft verwechselt: Anforderungen und Pflichtenheft. Die Anforderungen sind die einzelnen Wünsche; das Pflichtenheft ist das abgestimmte Dokument, in dem sie verbindlich stehen. Ein Testfall besteht immer aus einer Eingabe und dem erwarteten Ergebnis — beides wird festgelegt, bevor der Code existiert.
Ansatz: Die Begriffe folgen der Reihenfolge der Projektphasen: Analyse, Entwurf, Test.
Weiter: Eine Eingabe zusammen mit dem erwarteten Ergebnis heißt Testfall. Das abgestimmte Dokument mit allen Anforderungen heißt Pflichtenheft.
A4
Die Nachhilfebörse Schritt für Schritt
AFB II

Die Schülervertretung lässt eine Nachhilfebörse programmieren: Wer Nachhilfe gibt, trägt Fach und Zeiten ein; wer Hilfe sucht, kann sich melden. Bringe die Projektschritte in eine sinnvolle Reihenfolge.

Ziehe die Karten in die richtige Reihenfolge — mit der Tastatur: ↑/↓ verschiebt, Shift+↑/↓ wechselt nur den Fokus.
1Mit der SV klären, was die Börse können soll
2Das Pflichtenheft schreiben und von der SV bestätigen lassen
3Klassendiagramm entwerfen und Methodenköpfe gemeinsam festlegen
4Zu jeder vereinbarten Methode Testfälle mit erwarteten Ergebnissen festlegen
5Klassen auf die Teammitglieder verteilen und implementieren
6Die festgelegten Testfälle ausführen und gefundene Fehler beheben
Jeder Schritt baut auf dem vorigen auf: Ohne geklärte Anforderungen kein Pflichtenheft, ohne Pflichtenheft kein sinnvoller Entwurf. Die Testfälle beziehen sich auf die vereinbarten Methoden, also kommen sie nach dem Entwurf — aber vor der Implementierung. So kann das Ergebnis nicht unbewusst an den fertigen Code angepasst werden. Typischer Fehler: Testfälle erst nach dem Programmieren festlegen („wir testen, was wir gebaut haben“).
Ansatz: Welcher Schritt braucht das Ergebnis welches anderen Schrittes?
Weiter: Testfälle werden festgelegt, sobald die Methodenköpfe feststehen — und ausgeführt, wenn der Code da ist.
A5
Stimmt's? — Teamarbeit beim Tischtennis-Turnier
AFB II

Vier Schülerinnen und Schüler programmieren die Verwaltung für ein Tischtennis-Turnier. Stimmen diese Aussagen über ihre Zusammenarbeit?

Fünf Aussagen nacheinander. Eine falsche Einschätzung reicht — dann startest du die Serie mit „Neue Runde“ neu.
Aussage 1 von 5

Im Team entstehen die meisten Fehler nicht in den Klassen, sondern zwischen ihnen. Deshalb werden die Schnittstellen vorher vereinbart und Testfälle vorher festgelegt. Tests können Fehler finden, aber nie beweisen, dass es keine mehr gibt.
Ansatz: Unterscheide: Was beschreibt, was die Software tun soll — und was, wie sie gebaut ist?
Weiter: Eine Klasse, die für sich funktioniert, passt noch lange nicht zu den anderen.
A6
Vom Pflichtenheft zur Schnittstelle: Das Fundbüro
AFB II

Das Sekretariat wünscht sich eine App für das Fundbüro der Schule. Aus dem Pflichtenheft ist dieses Klassendiagramm entstanden:

Fundbuero
  • - stuecke: Reihung vom Typ Fundstueck
  • c Fundbuero()
  • + aufnehmen(f: Fundstueck)
  • + anzahlOffen(): Ganzzahl
  • + suchen(wort: Zeichenkette): Fundstueck
verwaltet1n
Fundstueck
  • - beschreibung: Zeichenkette
  • - ort: Zeichenkette
  • - abgeholtVon: Zeichenkette
  • c Fundstueck(beschreibung: Zeichenkette, ort: Zeichenkette)
  • + istAbgeholt(): Wahrheitswert
  • + abholen(name: Zeichenkette)

Verbinde jede Anforderung mit dem Eintrag im Diagramm, der sie umsetzt.

Ansatz: Suche in jeder Anforderung das Verb: Wird etwas erfragt oder verändert?
Weiter: Etwas erfassen heißt: ein neues Objekt erzeugen. Etwas übernehmen heißt: ein vorhandenes Objekt weitergeben.
A7
Testfälle für die Freibadkasse
AFB IIMix

Laut Pflichtenheft kostet der Eintritt im Freibad: unter 6 Jahren 0 €, von 6 bis 17 Jahren 3 €, von 18 bis 64 Jahren 6 €, ab 65 Jahren 4 €. Ein Teammitglied hat die Methode mit einer Mehrfachverzweigung (Kapitel 1) implementiert:

public class Freibadkasse {
    public int preis(int alter) {
        if (alter <= 6) {
            return 0;
        } else if (alter < 18) {
            return 3;
        } else if (alter > 65) {
            return 4;
        }
        return 6;
    }
}

Vor der Implementierung hat das Team diese Testfälle festgelegt (Eingabe → erwartetes Ergebnis):

k.preis(5)   // erwartet 0
k.preis(6)   // erwartet 3
k.preis(17)  // erwartet 3
k.preis(18)  // erwartet 6
k.preis(64)  // erwartet 6
k.preis(65)  // erwartet 4
k.preis(70)  // erwartet 4

Wie viele der sieben Testfälle schlagen fehl?

Rechne selbst und trage das Ergebnis ein — Enter prüft direkt.
Die Methode liefert: 5 → 0 ✓, 6 → 0 ✗ (erwartet 3), 17 → 3 ✓, 18 → 6 ✓, 64 → 6 ✓, 65 → 6 ✗ (erwartet 4), 70 → 4 ✓. Zwei Tests schlagen fehl — beide genau an einer Grenze: alter <= 6 müsste alter < 6 heißen und alter > 65 müsste alter >= 65 heißen. Genau deshalb legt man Testfälle direkt an die Grenzwerte aus dem Pflichtenheft. Wer nur 5, 10, 30 und 70 testet, findet keinen der beiden Fehler.
Ansatz: Rechne jeden Testfall mit der Methode durch und vergleiche mit dem erwarteten Wert.
Weiter: Achte auf die Vergleichsoperatoren: Welcher Zweig wird bei genau 6 bzw. genau 65 genommen?
A8
Die Schulbuch-Tauschbörse planen
AFB III

Für eine Tauschbörse gebrauchter Schulbücher steht im Pflichtenheft:

  1. Ein Angebot hat einen Buchtitel und einen Preis in Euro und gehört zu einer anbietenden Person.
  2. Der Preis eines Angebots kann gesenkt werden.
  3. Man kann abfragen, ob ein Angebot schon reserviert ist.
  4. Anbietende können nach einem Verkauf mit 1 bis 5 Sternen bewertet werden.
  5. Die Börse zeigt alle Angebote bis zu einem Höchstpreis an.

Das Team hat daraus diesen Entwurf gemacht:

Boerse
  • - angebote: Reihung vom Typ Angebot
  • c Boerse()
  • + hinzufuegen(a: Angebot)
  • + guenstigeZeigen(hoechstpreis: Ganzzahl)
enthält1n
Angebot
  • - titel: Zeichenkette
  • - preis: Ganzzahl
  • - reserviert: Wahrheitswert
  • - anbieter: Anbieter
  • c Angebot(titel: Zeichenkette, preis: Ganzzahl, anbieter: Anbieter)
  • + getTitel(): Zeichenkette
  • + getPreis(): Ganzzahl
  • + preisSenken(betrag: Ganzzahl)
  • + reservieren()
  • + istReserviert(): Wahrheitswert
  • + getAnbieter(): Anbieter
gehört zun1
Anbieter
  • - name: Zeichenkette
  • - klasse: Zeichenkette
  • c Anbieter(name: Zeichenkette, klasse: Zeichenkette)
  • + getName(): Zeichenkette

Vereinbart ist: Für jede Anfrage (Methode mit Rückgabetyp) der Klasse Angebot werden 2 Testfälle festgelegt, für jeden Auftrag (ohne Rückgabetyp) 3.

Rechne die Kette Schritt für Schritt: Erst wenn ein Schritt stimmt, wird der nächste freigeschaltet. Enter prüft.
  1. Wie viele Klassen enthält der Entwurf? Klassen
  2. Wie viele öffentliche Methoden (ohne Konstruktor) umfasst die Schnittstelle der Klasse Angebot? Methoden
  3. Wie viele Testfälle werden für die Klasse Angebot festgelegt? Testfälle
  4. Wie viele der fünf Anforderungen lassen sich mit diesem Entwurf noch nicht umsetzen? Anforderungen
Der Entwurf hat drei Klassen. Angebot hat sechs öffentliche Methoden: vier Anfragen (getTitel, getPreis, istReserviert, getAnbieter) und zwei Aufträge (preisSenken, reservieren) — also 4 · 2 + 2 · 3 = 14 Testfälle. Der Konstruktor zählt nicht mit, private Attribute auch nicht. Anforderung 4 fehlt komplett: Weder Anbieter noch eine andere Klasse hat ein Attribut oder eine Methode für die Sternebewertung. Genau solche Lücken soll der Abgleich Pflichtenheft ↔ Entwurf aufdecken, bevor programmiert wird.
Ansatz: Gehe die Klassenkarte von Angebot durch und markiere Methoden mit und ohne Rückgabetyp.
Weiter: Anfragen: 4, Aufträge: 2. Suche dann zu jeder Anforderung die Methode, die sie umsetzt — wo findest du nichts?
A9
Fehlersuche: Der Vertrag im Hausaufgaben-Planer
AFB III

Für einen Hausaufgaben-Planer hat das Team diese Klassenkarte vereinbart. Ein anderes Team programmiert schon die Wochenansicht und ruft diese Methoden auf.

Hausaufgabe
  • - fach: Zeichenkette
  • - bisTag: Ganzzahl
  • - erledigt: Wahrheitswert
  • c Hausaufgabe(fach: Zeichenkette, bisTag: Ganzzahl)
  • + istErledigt(): Wahrheitswert
  • + erledigen()
  • + getBisTag(): Ganzzahl
  • + verschieben(tage: Ganzzahl)

Juri hat die Klasse implementiert. Sein Code lässt sich übersetzen — aber drei Zeilen halten den vereinbarten Vertrag nicht ein.

In diesem Text stecken Fehler. Klicke genau die falschen Zeilen an — die richtigen musst du stehen lassen.
Juris Klasse ist für sich genommen fehlerfrei — sie passt nur nicht zum Vertrag. Genau diese Fehler bemerkt man erst, wenn die Teile zusammengesetzt werden. Wer eine Änderung an der Schnittstelle für nötig hält (etwa einen Grund beim Verschieben), muss sie mit dem ganzen Team vereinbaren und das Klassendiagramm anpassen.
Ansatz: Vergleiche Zeile für Zeile mit der Klassenkarte: Sichtbarkeit, Namen, Parameterlisten.
Weiter: isErledigt und istErledigt sind für Java zwei verschiedene Namen. Und − im Diagramm heißt private.
A10
Trickaufgabe: Wer muss mitändern? — Proberaum-Buchung
AFB IIITrick

Die Musik-AG bucht Proberäume mit vier Klassen. Wer welche öffentlichen Methoden aufruft, steht fest:

  • Planer ruft Buchung.getRaum(), Buchung.getStunde() und Raum.getNummer() auf.
  • Buchung ruft Band.getName() und Raum.getNummer() auf.
  • Band und Raum rufen keine Methoden anderer Klassen auf.

Wie viele Klassen müssen bei jeder Änderung mindestens angepasst werden — die geänderte Klasse mitgezählt?

Wähle für jede Zeile eine Stufe: 1 = 1 Klasse, 2 = 2 Klassen, 3 = 3 Klassen, 4 = 4 Klassen. Mit der Tastatur: Tab zur Zeile, ←/→ zwischen den Stufen, Enter setzt.
1 = 1 Klasse4 = 4 Klassen
Raum speichert die Nummer intern als Zeichenkette statt als Ganzzahl; getNummer() liefert weiterhin eine Ganzzahl.
Raum.getNummer() wird in getRaumnummer() umbenannt.
Band.getName() bekommt einen zusätzlichen Parameter.
Band bekommt eine neue öffentliche Methode getMitglieder(), die noch niemand aufruft.
Buchung.getStunde() liefert künftig eine Fließkommazahl statt einer Ganzzahl.
Der Trick liegt in der ersten und vierten Zeile: Sie sehen nach großen Änderungen aus, betreffen aber nur eine einzige Klasse. Solange die Schnittstelle — Name, Parameter, Rückgabetyp — gleich bleibt, merken die anderen Klassen nichts von der inneren Umstellung. Auch eine neue Methode stört niemanden. Ändert sich dagegen ein Methodenkopf, müssen alle Klassen mit, die ihn aufrufen: bei getNummer Raum, Buchung und Planer. Genau deshalb vereinbart man die Schnittstellen früh und ändert sie nur gemeinsam.
Ansatz: Zähle bei jeder Änderung: die Klasse selbst plus alle Klassen, die die geänderte Methode aufrufen.
Weiter: Ändert sich nur das Innere einer Klasse, aber kein Methodenkopf, ist nur diese eine Klasse betroffen.