Vom Auftrag zum Entwurf
- Analyse:Anforderungen sammeln und im Pflichtenheft festhalten: Was soll die Software können?
- Entwurf:Klassen, Attribute, Methoden und Beziehungen festlegen — Ergebnis: das Klassendiagramm.
- Implementierung:die Klassen programmieren, jede nach ihrem Diagramm.
- Test:prüfen, ob jede Anforderung erfüllt ist — mit vorher festgelegten Testfällen.
- Reihenfolge:die Phasen bauen aufeinander auf; zeigt ein Test einen Fehler, geht man einen Schritt zurück.
Phasen: Analyse, Entwurf, Implementierung, Test — sie bauen aufeinander auf; bei einem Testfehler geht man einen Schritt zurück.
Analyse: Anforderungen sammeln und im Pflichtenheft festhalten.
Entwurf: Klassen, Attribute, Methoden und Beziehungen festlegen — Ergebnis ist das Klassendiagramm.
Implementierung und Test: Jede Klasse nach ihrem Diagramm programmieren und mit vorher festgelegten Testfällen prüfen.
Arbeiten im Team
- Aufteilen:jedes Team übernimmt ganze Klassen, nicht einzelne Zeilen.
- Schnittstelle:die öffentlichen Methoden, die ein anderes Team benutzt, z. B.
getPreis(): Fließkommazahl. - Vertrag:Schnittstellen stehen im Klassendiagramm und werden nur gemeinsam geändert.
- Testfälle:Eingabe und erwartetes Ergebnis — Normalfall, Grenzfall, Fehlerfall.
Die Mensa-App ist zu groß für eine Person. Zerlege sie in ihre vier Klassen und lege die Teile auf die beiden Teamtische — ziehen, oder Teil fokussieren und 1/2 drücken (0 legt zurück). Jede Beziehung, die zwischen den Tischen verläuft, ist eine Schnittstelle, die beide Teams vorher vereinbaren müssen.
Halte fest: Man teilt ein Projekt so auf, dass möglichst wenige Beziehungen zwischen den Teams verlaufen. Jede verbleibende Schnittstelle — Methodenname, Parameter, Rückgabetyp — wird im Klassendiagramm festgelegt, bevor programmiert wird.
| Ausgangslage und Aufruf | Erwartetes Ergebnis |
|---|---|
| guthaben = 5.0; abbuchen(3.2) | guthaben = 1,8 — Normalfall |
| guthaben = 3.2; abbuchen(3.2) | guthaben = 0 — Grenzfall: genau das ganze Guthaben |
| guthaben = 2.0; abbuchen(3.2) | guthaben bleibt 2,0 — Fehlerfall: zu wenig Geld |
Softwareprojekt: Analyse → Entwurf → Implementierung → Test.
Aufteilen: Jedes Team übernimmt ganze Klassen, nicht einzelne Zeilen — möglichst wenige Beziehungen verlaufen zwischen den Teams.
Schnittstelle: Die öffentlichen Methoden, die ein anderes Team benutzt (Name, Parameter, Rückgabetyp). Sie stehen im Klassendiagramm und werden nur gemeinsam geändert — das Klassendiagramm ist der Vertrag im Team.
Testfälle: Eingabe und erwartetes Ergebnis: Normalfall, Grenzfall, Fehlerfall.
Allgemeine Hinweise
Nicht sofort programmieren
Wer ohne gemeinsamen Entwurf loslegt, merkt erst beim Zusammensetzen, dass Namen und Datentypen nicht zueinander passen.
Schnittstellen nicht allein ändern
Benennt ein Team getPreis() eigenmächtig um, lässt sich der Code des anderen Teams nicht mehr übersetzen.
Grenzfälle zuerst
Genau 0, genau die Obergrenze, knapp darüber: An diesen Stellen stecken die meisten Fehler.