BY Abitur Informatik gA common mistakes
BY Abitur Informatik gA · Understand the traps and how to avoid them.
Beim Schreiben von Java- oder Pseudocode werden Attributdeklarationen, Konstruktorsignatur und Methodenköpfe (Rückgabetyp, Parameterliste) unvollständig oder in falscher Reihenfolge notiert, sodass der Code nicht kompiliert bzw. die geforderte Schnittstelle nicht erfüllt.
Unter Zeitdruck wird aus dem Gedächtnis formuliert statt gegen die Aufgabenstellung geprüft; die Lernenden verwechseln die Rolle von Klasse, Attribut und Methode und unterschätzen, dass die Klausur auf lauffähigen bzw. syntaktisch korrekten Entwurf punktet.
What to do instead
Vor dem Abschreiben ein kurzes Gerüst anlegen: Klasse, Attribute mit Typ und Sichtbarkeit, Konstruktor mit allen Parametern, dann Methoden mit Rückgabetyp und Parametern. Anschließend jeden Methodenkopf gegen die Aufgabenformulierung abhaken und einmal gedanklich kompilieren (jede Variable deklariert? jeder Pfad mit return?).
Bei der Analyse objektorientierter Modellierungen werden Beziehungen zwischen Klassen falsch benannt oder die Multiplizitäten vertauscht (z. B. 1..* und * an der falschen Seite, Vererbung mit Assoziation verwechselt), obwohl ein Klassendiagramm oder ein Beschreibungstext vorliegt.
Multiplizitäten werden als reine Leserichtung des Satzes interpretiert statt von der Klasse aus, an der die Zahl steht; Vererbung (ist-ein) und Assoziation (hat-ein) werden sprachlich nicht sauber getrennt.
What to do instead
Jede Kante einzeln laut lesen: 'Ein A hat n B, ein B gehört zu m A' und die Zahlen an die jeweils gegenüberliegende Klasse schreiben. Bei Vererbung prüfen, ob der Oberbegriff den Unterbegriff ohne Zusatz beschreibt; Generalisierung nur bei echtem ist-ein-Verhältnis ziehen.
Algorithmen werden nur informal beschrieben ('dann sucht man halt weiter'), statt als strukturierter Pseudocode mit Initialisierung, Schleifenbedingung, Rekursionsabbruch und Rückgabe; dadurch fehlen die bewerteten Strukturelemente.
Die Lösungsidee ist vorhanden, wird aber nicht in die geforderte Darstellungsform übersetzt; Lernende halten Fließtext für gleichwertig und sparen sich die Formalisierung.
What to do instead
Ein festes Schema einüben: Eingabe, Vorbedingung, Initialisierung, Schleife/Rekursion mit Abbruchbedingung, Nachbedingung, Rückgabe. Jeden Algorithmus zuerst in diesem Schema auf Papier skizzieren und erst danach in die geforderte Sprache übertragen.
Rekursive Lösungen enthalten keinen oder einen falschen Abbruch (Basisfall), oder der rekursive Aufruf verkleinert das Problem nicht, sodass eine Endlosrekursion entsteht bzw. das Ergebnis nicht stimmt.
Der Fokus liegt auf dem 'eleganten' rekursiven Schritt; der Basisfall wird als trivial übersprungen. Zudem wird nicht geprüft, ob jeder Aufruf tatsächlich auf ein kleineres Problem führt.
What to do instead
Rekursion immer zuerst vom Basisfall her entwickeln: kleinstes Problem explizit lösen, dann den Schritt formulieren, der garantiert näher an diesen Fall führt. Am Ende für kleine Eingaben (n = 0, 1, 2) den Ablauf von Hand durchspielen.
Bei der Komplexitätsanalyse werden Laufzeitklassen nur grob geraten oder Schleifen falsch gezählt (verschachtelte Schleifen als O(n) statt O(n²), Rekursion ohne Berücksichtigung der Aufrufanzahl), und die Begründung fehlt.
O-Notation wird als Etikett auswendig gelernt statt aus der Struktur des Codes abgeleitet; konstante Faktoren und die Anzahl der rekursiven Aufrufe pro Ebene werden nicht systematisch erfasst.
What to do instead
Zählmethode anwenden: Schleifen von innen nach außen multiplizieren, bei Rekursion Aufrufe pro Ebene mit Tiefe multiplizieren. Ergebnis immer mit Begründungssatz 'weil die innere Anweisung x-mal pro Durchlauf der äußeren ausgeführt wird' versehen und gegen ein Beispiel n = 10 plausibilisieren.
Datenstrukturen werden ohne Bezug zur Aufgabe gewählt (z. B. Liste statt Stack/Queue, obwohl LIFO bzw. FIFO gefordert ist) und die Operationen (push/pop, enqueue/dequeue, Einfügen in sortierte Liste) werden mit falscher Wirkung beschrieben.
Die Begriffe werden nach Alltagsverständnis verwendet; die charakteristischen Zugriffsbeschränkungen (nur oben bzw. vorne/hinten) sind nicht präsent, und die Aufgabenstellung wird nicht auf ihr Zugriffsmuster hin gelesen.
What to do instead
Vor der Wahl das Zugriffsmuster der Aufgabe notieren ('zuletzt eingefügt zuerst gebraucht' → Stack). Dann die geforderten Operationen mit Vor- und Nachbedingung sowie Laufzeit aufschreiben und prüfen, ob die Struktur genau dieses Muster effizient unterstützt.
Beim Sortieren oder Suchen wird ein Verfahren nur benannt, aber die Schrittfolge für die konkrete Eingabe nicht dokumentiert; Zwischenzustände, Vergleiche und Tauschvorgänge fehlen, ebenso die Angabe zu Stabilität oder Best-/Worst-Case.
Das Verfahren ist bekannt, die geforderte Nachvollziehbarkeit wird unterschätzt; Lernende springen direkt zum Endergebnis und verlieren die Punkte für den Weg.
What to do instead
Eine Tabelle mit Spalten 'Schritt, betrachtete Elemente, Vergleich, Aktion, Feldzustand' anlegen und jeden Durchlauf eintragen. Zusätzlich pro Verfahren Best- und Worst-Case mit Begründung notieren und die Stabilität an einem Beispiel mit gleichen Schlüsseln zeigen.
Bei Aufgaben zu endlichen Automaten oder formalen Sprachen werden Zustandsübergänge unvollständig notiert (fehlende Übergänge, kein Start- oder Endzustand markiert) oder ein gefundener Automat nicht gegen Gegenbeispiele getestet.
Der Entwurf erfolgt intuitiv aus wenigen positiven Beispielen; die Notwendigkeit, auch abzulehnende Wörter zu prüfen, wird übersehen, und die Formalisierung (Übergangstabelle, regulärer Ausdruck) wird nachlässig behandelt.
What to do instead
Nach dem Entwurf eine Testliste anlegen: alle Wörter der Aufgabenstellung, dazu gezielt Gegenbeispiele (leeres Wort, ein Zeichen zu viel, falsche Reihenfolge). Jedes Wort durch den Automaten laufen lassen und das Ergebnis in der Übergangstabelle dokumentieren, bevor die Lösung abgegeben wird.
Bei Aufgaben zu Datenbanken oder Relationen wird ein SQL-Abfrageentwurf ohne Prüfung der geforderten Spalten und ohne Verbundbedingung formuliert, oder ein Normalformverstoß wird benannt, aber nicht durch funktionale Abhängigkeiten belegt.
Die Abfrage wird aus dem Aufgabentext 'übersetzt', ohne das Ergebnis schema zu prüfen; Normalformen werden als Definitionen zitiert, ohne die konkreten Abhängigkeiten der Tabelle herzuleiten.
What to do instead
Abfrage rückwärts prüfen: Welche Spalten soll die Ausgabe haben, welche Tabelle liefert sie, wie werden Tabellen verknüpft, welche Zeilen filtert die WHERE-Klausel. Bei Normalformen zuerst alle funktionalen Abhängigkeiten aus den Daten auflisten, dann Verstoß und Zerlegung explizit begründen.
In der Begründung oder Bewertung wird ein Ergebnis nur behauptet ('das ist effizienter', 'das ist besser'), ohne Kriterien zu nennen, abzuwägen oder auf die Aufgabensituation zu beziehen; Alternativen werden nicht gegenübergestellt.
Bewertungsaufgaben werden wie Wissensaufgaben behandelt; Lernende geben die vermutete Musterantwort statt einer argumentierten Position und übersehen, dass Kriterien und Abwägung eigenständig bewertet werden.
What to do instead
Dreischritt einüben: Kriterium nennen (z. B. Laufzeit, Speicherbedarf, Wartbarkeit), beide Optionen am Kriterium vergleichen, dann ein begründetes Fazit für den konkreten Fall ziehen. Jeden Bewertungssatz darauf prüfen, ob er ein Kriterium und einen Vergleich enthält.