|
Size: 5664
Comment:
|
← Revision 200 as of 2020-08-11 10:31:11 ⇥
Size: 7966
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #acl Claudius Korzen:read,write -All:read | ## page was renamed from ProgrammierenCplusplusSS2020/Projekt/Korrekturschema #acl Claudius Korzen:read,write All:read |
| Line 5: | Line 6: |
| Sie können für das Projekt maximal 80 Punkte erreichen (die restlichen 20 Punkte gab es bereits für Ü11). Die Berechnung Ihrer Punktzahl erfolgt in zwei Schritten. Im ersten Schritt wird die Funktionalität Ihres Programms bewertet. Sie erhalten hierfür maximal 80 Punkte. Das zugrundeliegende Bewertungsschema für diesen Schritt ist weiter unten ("Bewertung der Funktionalität") erläutert. Im zweiten Schritt wird das "Drumherum" (Tests, Style, valgrind, etc.) bewertet. Sie erhalten hierfür eine ''prozentuale'' Punktzahl, die mit der Punktzahl aus dem ersten Schritt ''multipliziert'' wird. Das Bewertungsschema für diesen Schritt ist ebenfalls weiter unten ("Bewertung des Drumherums") erläutert. |
Zur Benotung Ihrer Abgabe bewerten wir zwei Aspekte: (1) die Funktionalität Ihres Programms und (2) die Qualität des Codes (inkl. Unit Tests, Code Style, Valgrind, etc.). Beides bewerten wir mit einer Prozentpunktzahl zwischen 0 und 100. Die detaillierten Punktevergabeschemas hierfür sind in den entsprechenden Abschnitten ''"Bewertung der Funktionalität"'' und ''"Bewertung der Code-Qualität"'' weiter unten erläutert. |
| Line 8: | Line 9: |
| ''Beispiele: '' | Ihre Gesamtpunktzahl errechnet sich aus: '''Funktionalität''' ''(in %)'' ''' x Qualität''' ''(in %)'' '''x 80'''. Die maximal erreichbare Punktzahl ist also 80 (die restlichen 20 Punkte gab es ja bereits für Ü11). Hier ein paar Rechenbeispiele, die erläutern, wie das Bewertungsschema zu verstehen ist: |
| Line 10: | Line 11: |
| (1) Wenn Ihr Programm alle Anforderungen erfüllt und das Drumherum auch perfekt ist, erhalten Sie: '''80 * 100% = 80 Punkte'''. <<BR>> (2) Wenn Ihr Programm alle Anforderungen erfüllt und das Drumherum nur zur Hälfte in Ordnung ist, erhalten Sie: '''80 * 50% = 40 Punkte'''. <<BR>> (3) Wenn Ihr Programm nur ¾ der Anforderungen und 90% des Drumherums erfüllt, erhalten Sie '''60 * 90% = 54 Punkte'''. |
'''Beispiel 1:''' ''Wenn Ihr Programm alle Funktionalitäten erfüllt und auch die Qualität perfekt ist, erhalten Sie 100 Prozentpunkte für die Funktionalität und 100 Prozentpunkte für die Qualität. Das ergibt eine Gesamtpunktzahl von '''100% x 100% x 80 = 80'''.'' <<BR>> '''Beispiel 2:''' ''Wenn Ihr Programm alle Funktionalitäten erfüllt, aber die Qualität nur zur Hälfte in Ordnung ist, erhalten Sie 100 Prozentpunkte für die Funktionalität und 50 Prozentpunkte für die Qualität. Das ergibt eine Gesamtpunktzahl von '''100% x 50% x 80 = 40'''.'' <<BR>> '''Beispiel 3:''' ''Wenn Ihr Programm ¾ der Funktionalitäten erfüllt und die Qualität zu 90% ok ist, ergibt das eine Punktzahl von '''75% x 90% x 80 = 54'''.'' |
| Line 14: | Line 15: |
| Gleitkommazahlen werden zur nächsthöheren Ganzzahl aufgerundet. Die maximal erreichbare Punktzahl ist 80 Punkte (die restlichen 20 Punkte gab es bereits für Ü11). | Gleitkommazahlen werden zur nächsthöheren Ganzzahl aufgerundet. |
| Line 18: | Line 19: |
| === Projekt 1 (80 Punkte) === | Im Folgenden ist zuerst das Punktevergabeschema für Projekt 1 und danach das Punktevergabeschema für Projekt 2 erläutert. Die genannten Punkte sind als Prozentpunkte zu verstehen (siehe dazu auch die Erklärungen oben). Sie können in beiden Projekten maximal 100 Punkte = 100% erreichen. |
| Line 20: | Line 21: |
| * Spiellogik (25 Punkte) - ''Korrekte Implementierung der Bewegungen (inkl. der genannten Spezialfälle):'' 20P (5P pro Richtung) <<BR>> - ''Korrektes Hinzufügen der zufälligen Kacheln zu Beginn des Spiels und nach jedem Zug: 5P'' |
=== Projekt 1 (100 Punkte) === * Spiellogik (30 Punkte) - ''Korrekte Implementierung der Bewegungen (inkl. der genannten Spezialfälle):'' 24P (6P pro Richtung) <<BR>> - ''Korrektes Hinzufügen der zufälligen Kacheln zu Beginn des Spiels und nach jedem Zug: 6P'' |
| Line 27: | Line 30: |
| * Punktzahl (5 Punkte) - ''Berechnung:'' 3P <<BR>> |
* Aktuelle Punktzahl (5 Punkte) - ''Korrekte Berechnung:'' 3P <<BR>> |
| Line 30: | Line 33: |
| * Anzahl Züge (4 Punkte) - ''Berechnung:'' 2P <<BR>> |
* Anzahl Züge (5 Punkte) - ''Korrekte Berechnung:'' 3P <<BR>> |
| Line 33: | Line 36: |
| * Spiel gewonnen (4 Punkte) - ''Berechnung:'' 2P <<BR>> |
* Spiel gewonnen (6 Punkte) - ''Korrekte Berechnung:'' 4P <<BR>> - ''Anzeige:'' 2P <<BR>> - ''Wenn Spiel nicht weiter spielbar ist:'' -1P * Spiel verloren (6 Punkte) - ''Korrekte Berechnung:'' 4P <<BR>> |
| Line 36: | Line 43: |
| * Spiel verloren (4 Punkte) - ''Berechnung:'' 2P <<BR>> - ''Anzeige:'' 2P * Undo Funktion (12 Punkte) |
* Undo Funktion (10 Punkte) |
| Line 41: | Line 45: |
| - ''Behandlung Tastendruck:'' 1P <<BR>> - ''Logik:'' 1P |
- ''Korrekte Behandlung Tastendruck:'' 1P <<BR>> - ''Logik:'' 2P |
| Line 45: | Line 49: |
| - ''Behandlung Tastendruck:'' 1P <<BR>> - ''Logik:'' 8P |
- ''Korrekte Behandlung Tastendruck:'' 1P <<BR>> - ''Logik:'' 6P |
| Line 48: | Line 52: |
| * Grafik (20 Punkte) - ''Farbliche Markierung der Kacheln (mit unterschiedlichen Farben pro Wert):'' 8P <<BR>> - ''Quadratische Kacheln'': 3P <<BR>> - ''Abstand der Kacheln zueinander:'' 3P <<BR>> - ''Anzeige Wert einer Kachel:'' 2P <<BR>> |
* Grafik (25 Punkte) - ''Farbliche Markierung der Kacheln (mit unterschiedlichen Farben pro Wert):'' 10P <<BR>> - ''Quadratische Kacheln'': 4P <<BR>> - ''Abstand der Kacheln zueinander:'' 4P <<BR>> - ''Anzeige Wert einer Kachel:'' 3P <<BR>> |
| Line 56: | Line 60: |
| === Projekt 2 (80 Punkte) === | * Main-Programm (5 Punkte) - ''Initialisierungen'': 1P <<BR>> - ''Usage Info'': 1P <<BR>> - ''Game Loop'': 3P <<BR>> |
| Line 58: | Line 65: |
| Die Punktzahl ergibt sich aus dem in den [[https://ad-wiki.informatik.uni-freiburg.de/teaching/ProgrammierenCplusplusSS2020/Projekt|Projektspezifikationen]] beschriebenen Punkteschema (pro Instanz des Benchmarks ''"größte Kachel / 2048"'' Punkte). Die insgesamt erreichte Punktzahl wird Ihnen nach einem Durchlauf des Benchmarks unten links (in der letzten Zeile) angezeigt. ''Anmerkung'': Wenn Sie eine Punktzahl > 80 erreichen, bekommen Sie trotzdem nur 80 Punkte. | * Terminal-Wiederherstellung nach Beenden des Spiels (2 Punkte) - ''Farben unverändert'': 1P <<BR>> - ''Formatierung, Zeilenumbrüche, etc. unverändert'': 1P |
| Line 60: | Line 69: |
| == Bewertung des "Drumherums" == | === Projekt 2 (100 Punkte) === |
| Line 62: | Line 71: |
| === Fixer Anteil (30%) === | Die Punktzahl errechnet sich aus 1.25 x ''<Strategie-Punkte>'', wobei ''<Strategie-Punkte>'' die Punkte sind, die sich aus dem in den [[https://ad-wiki.informatik.uni-freiburg.de/teaching/ProgrammierenCplusplusSS2020/Projekt|Projektspezifikationen]] beschriebenen Punkteschema (pro Instanz des Benchmarks ''"größte Kachel / 2048"'' Punkte) ergeben und die Ihnen nach einem Durchlauf des Benchmarks unten links (in der letzten Zeile) angezeigt wird. Ihre Strategie muss also mindestens 80 Punkte erreichen, damit sie die volle Punktzahl erhalten. ''Anmerkung'': Wenn Ihre Strategie mehr als 80 Punkte erreicht, bekommen Sie trotzdem nur 100 Punkte. |
| Line 64: | Line 74: |
| === Tests (30%) === | == Bewertung der Code-Qualität == Auch hier sind die im Folgenden genannten Punkte als Prozentpunkte zu verstehen (siehe dazu auch die Erklärungen oben). Sie können maximal 100 Punkte = 100% erreichen. === Kompilierung (30 Punkte) === * Der Code muss fehlerfrei kompilieren. * Abzug abhängig davon, wie viele Kompilierfehler es gibt, und wie einfach diese für uns zu fixen sind. Bei einfachen Fehlern (z.B. Schreibfehlern): ''bis zu -5P pro Fehler''. Bei mittleren Fehlern: ''bis zu -10P pro Fehler''. Alles darüber hinaus ''-30P''. === Tests (30 Punkte) === |
| Line 66: | Line 84: |
| - ''Als trivial gelten nur ganz einfache Funktionen wie getter und setter.'' | - ''Es ist ok, wenn man eine Funktion f() zusammen mit Methoden testet, auf die sich f() unmittelbar auswirkt. Beispiel: Wenn man die Methoden zum Bewegen der Kacheln testet, ist es ok, wenn man getScore() oder getNumMoves() im gleichen Test mittestet.'' |
| Line 68: | Line 86: |
| - ''Als Spezialfall gelten solche Fälle, die in der Praxis nur selten auftreten (aber trotzdem auftreten können). Beispiele für Spezialfälle bezogen auf 2048: (1) Benutzer drückt undefinierte Taste; (2) Benutzer möchte einen Zug ausführen, der nicht möglich ist; (3) Beim Hinzufügen einer zufälligen Kachel ist das Feld bereits voll (es ist also kein Platz mehr für die Kachel).'' * TODO: Insgesamt Punkte entsprechend dem Anteil der Tests, die entsprechend der oben genannten Anforderungen in Ordnung sind. - TODO: Beispiele: Wenn 50% der Tests in Ordnung, dann 15 %. |
- ''Als Spezialfall gelten solche Fälle, die in der Praxis nur selten auftreten (aber trotzdem auftreten können). Beispiele für Spezialfälle bezogen auf 2048: (1) Benutzer drückt undefinierte Taste; (2) Benutzer möchte einen Zug ausführen, der nicht möglich ist; (3) Beim Hinzufügen einer zufälligen Kachel ist das Feld bereits voll (es ist also kein Platz mehr für die Kachel).'' * Abzug entsprechend dem Anteil der Tests, die nach den oben genannten Anforderungen nicht in Ordnung sind. Wenn zum Beispiel 50% der Tests nicht in Ordnung sind, gibt es nur 15 Punkte. |
| Line 72: | Line 89: |
| === Doku, Style, Modularität, Codequalität (20%) === * Doku (30%) - Jede Funktion muss dokumentiert sein. - Zu jedem Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, muss es einen Kommentar geben. - XXX entsprechend dem Anteil der Dokumentation, die in Ordnung ist (wenn z.B. nur die Hälfte der Funktionen dokumentiert sind, gibt es nur 15%). * Style (30%) - Checkstyle muss fehlerfrei durchlaufen <<BR>> - Code muss abgesehen davon auch gut lesbar sein, insbesondere korrekt eingerückt sein. <<BR>> - Abzug entsprechend TODO * Modularität (20%) - Wenn ein Teil des Codes für sich alleine umfangreich bzw. komplex genug ist oder mehrfach benötigt wird, muss er in einer geeigneten Funktion stehen. <<BR>> - Der Code für die Logik und die Grafik muss logisch voneinander getrennt sein. <<BR>> * Code-Qualität (20%) - Kein unnötiger Hardcode - Verwendung sinnvoller Typen - Korrekte Verwendung von Zeigern/Referenzen statt Objekten - Abzug. |
=== Doku, Code Style, Modularität, Codequalität (20 Punkte) === * Doku (6 Punkte) - ''Jede Funktion muss dokumentiert sein.'' <<BR>> - ''Zu jedem Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, muss es einen Kommentar geben.'' <<BR>> - ''Abzug entsprechend dem Anteil des Codes, für den eine Dokumentation fehlt/nicht in Ordnung ist.'' * Style (6 Punkte) - ''Checkstyle muss fehlerfrei durchlaufen.'' <<BR>> - ''Der Code muss abgesehen davon auch gut lesbar sein, insbesondere korrekt eingerückt sein.'' <<BR>> - ''Abzug entsprechend der Menge an Fehlern: pro Fehler 1P Abzug.''<<BR>> * Modularität (4 Punkte) - ''Wenn ein Teil des Codes für sich alleine umfangreich genug ist oder mehrfach benötigt wird, muss er in einer geeigneten Funktion stehen.'' <<BR>> - ''Der Code für die Logik und die Grafik muss logisch voneinander getrennt sein.'' <<BR>> - ''Abzug entsprechend dem Anteil des Codes, der nach den oben genannten Funktionen nicht in Ordnung ist.'' * Code-Qualität (4 Punkte) - ''Kein unnötiger Hardcode'' <<BR>> - ''Verwendung sinnvoller Typen'' <<BR>> - ''Korrekte Verwendung von Zeigern/Referenzen statt Objekten'' <<BR>> - ''pro Fehler 1P Abzug''. |
| Line 90: | Line 108: |
| === Const, public/private/protected, valgrind (20%) === * Const-correctness (40%) * Sinnvolle Einteilung in public/private/protected (30%) * Speicherlecks, valgrind (30%) |
=== Const, public/private/protected, valgrind (20 Punkte) === * Const-correctness (8 Punkte) <<BR>> - ''pro Fehler 1P Abzug''. * Sinnvolle Einteilung in public/private/protected (6 Punkte) <<BR>> - ''Abzug entsprechend dem Anteil der Funktionen/Variablen, für die der Modifier nicht ok ist. 6P Abzug wenn alles public ist.'' * Speicherlecks, valgrind (6 Punkte) - ''pro Fehler 1P Abzug''. |
Bewertungsschema
Zur Benotung Ihrer Abgabe bewerten wir zwei Aspekte: (1) die Funktionalität Ihres Programms und (2) die Qualität des Codes (inkl. Unit Tests, Code Style, Valgrind, etc.). Beides bewerten wir mit einer Prozentpunktzahl zwischen 0 und 100. Die detaillierten Punktevergabeschemas hierfür sind in den entsprechenden Abschnitten "Bewertung der Funktionalität" und "Bewertung der Code-Qualität" weiter unten erläutert.
Ihre Gesamtpunktzahl errechnet sich aus: Funktionalität (in %) x Qualität (in %) x 80. Die maximal erreichbare Punktzahl ist also 80 (die restlichen 20 Punkte gab es ja bereits für Ü11). Hier ein paar Rechenbeispiele, die erläutern, wie das Bewertungsschema zu verstehen ist:
Beispiel 1: Wenn Ihr Programm alle Funktionalitäten erfüllt und auch die Qualität perfekt ist, erhalten Sie 100 Prozentpunkte für die Funktionalität und 100 Prozentpunkte für die Qualität. Das ergibt eine Gesamtpunktzahl von 100% x 100% x 80 = 80.
Beispiel 2: Wenn Ihr Programm alle Funktionalitäten erfüllt, aber die Qualität nur zur Hälfte in Ordnung ist, erhalten Sie 100 Prozentpunkte für die Funktionalität und 50 Prozentpunkte für die Qualität. Das ergibt eine Gesamtpunktzahl von 100% x 50% x 80 = 40.
Beispiel 3: Wenn Ihr Programm ¾ der Funktionalitäten erfüllt und die Qualität zu 90% ok ist, ergibt das eine Punktzahl von 75% x 90% x 80 = 54.
Gleitkommazahlen werden zur nächsthöheren Ganzzahl aufgerundet.
Bewertung der Funktionalität
Im Folgenden ist zuerst das Punktevergabeschema für Projekt 1 und danach das Punktevergabeschema für Projekt 2 erläutert. Die genannten Punkte sind als Prozentpunkte zu verstehen (siehe dazu auch die Erklärungen oben). Sie können in beiden Projekten maximal 100 Punkte = 100% erreichen.
Projekt 1 (100 Punkte)
- Spiellogik (30 Punkte)
- Korrekte Implementierung der Bewegungen (inkl. der genannten Spezialfälle): 24P (6P pro Richtung)
- Korrektes Hinzufügen der zufälligen Kacheln zu Beginn des Spiels und nach jedem Zug: 6P - Bedienung über Pfeiltasten (6 Punkte)
- Korrektes Verhalten nach Drücken der Pfeiltasten: 4P (1P pro Pfeiltaste)
- Korrektes Verhalten nach Drücken von "ESC": 1P
- Korrektes Verhalten nach Drücken von "n": 1P - Aktuelle Punktzahl (5 Punkte)
- Korrekte Berechnung: 3P
- Anzeige: 2P - Anzahl Züge (5 Punkte)
- Korrekte Berechnung: 3P
- Anzeige: 2P - Spiel gewonnen (6 Punkte)
- Korrekte Berechnung: 4P
- Anzeige: 2P
- Wenn Spiel nicht weiter spielbar ist: -1P - Spiel verloren (6 Punkte)
- Korrekte Berechnung: 4P
- Anzeige: 2P - Undo Funktion (10 Punkte)
- Wenn Undo nur mit festem (hartgecodetem) Wert funktioniert:
- Korrekte Behandlung Tastendruck: 1P
- Logik: 2P
- Wenn Undo mit variablem Wert funktioniert:
- Einlesen des Parameters von Kommandozeile: 3P
- Korrekte Behandlung Tastendruck: 1P
- Logik: 6P
- Grafik (25 Punkte)
- Farbliche Markierung der Kacheln (mit unterschiedlichen Farben pro Wert): 10P
- Quadratische Kacheln: 4P
- Abstand der Kacheln zueinander: 4P
- Anzeige Wert einer Kachel: 3P
- Geeignete Größe der Kacheln: 2P
- Konsistentes Erscheinungsbild im gesamten Spielverlauf: 2P
- Main-Programm (5 Punkte)
- Initialisierungen: 1P
- Usage Info: 1P
- Game Loop: 3P
- Terminal-Wiederherstellung nach Beenden des Spiels (2 Punkte)
- Farben unverändert: 1P
- Formatierung, Zeilenumbrüche, etc. unverändert: 1P
Projekt 2 (100 Punkte)
Die Punktzahl errechnet sich aus 1.25 x <Strategie-Punkte>, wobei <Strategie-Punkte> die Punkte sind, die sich aus dem in den Projektspezifikationen beschriebenen Punkteschema (pro Instanz des Benchmarks "größte Kachel / 2048" Punkte) ergeben und die Ihnen nach einem Durchlauf des Benchmarks unten links (in der letzten Zeile) angezeigt wird. Ihre Strategie muss also mindestens 80 Punkte erreichen, damit sie die volle Punktzahl erhalten. Anmerkung: Wenn Ihre Strategie mehr als 80 Punkte erreicht, bekommen Sie trotzdem nur 100 Punkte.
Bewertung der Code-Qualität
Auch hier sind die im Folgenden genannten Punkte als Prozentpunkte zu verstehen (siehe dazu auch die Erklärungen oben). Sie können maximal 100 Punkte = 100% erreichen.
Kompilierung (30 Punkte)
- Der Code muss fehlerfrei kompilieren.
Abzug abhängig davon, wie viele Kompilierfehler es gibt, und wie einfach diese für uns zu fixen sind. Bei einfachen Fehlern (z.B. Schreibfehlern): bis zu -5P pro Fehler. Bei mittleren Fehlern: bis zu -10P pro Fehler. Alles darüber hinaus -30P.
Tests (30 Punkte)
- Es muss für jede nicht-triviale Funktion einen einzelnen Test geben.
- Es ist ok, wenn man eine Funktion f() zusammen mit Methoden testet, auf die sich f() unmittelbar auswirkt. Beispiel: Wenn man die Methoden zum Bewegen der Kacheln testet, ist es ok, wenn man getScore() oder getNumMoves() im gleichen Test mittestet.
- Jeder Test muss mindestens einen Normalfall und einen Spezialfall (falls es einen gibt) testen.
- Als Spezialfall gelten solche Fälle, die in der Praxis nur selten auftreten (aber trotzdem auftreten können). Beispiele für Spezialfälle bezogen auf 2048: (1) Benutzer drückt undefinierte Taste; (2) Benutzer möchte einen Zug ausführen, der nicht möglich ist; (3) Beim Hinzufügen einer zufälligen Kachel ist das Feld bereits voll (es ist also kein Platz mehr für die Kachel).
- Abzug entsprechend dem Anteil der Tests, die nach den oben genannten Anforderungen nicht in Ordnung sind. Wenn zum Beispiel 50% der Tests nicht in Ordnung sind, gibt es nur 15 Punkte.
Doku, Code Style, Modularität, Codequalität (20 Punkte)
- Doku (6 Punkte)
- Jede Funktion muss dokumentiert sein.
- Zu jedem Stück Code, dessen Funktionsweise sich nicht unmittelbar durch Lesen des Codes ergibt, muss es einen Kommentar geben.
- Abzug entsprechend dem Anteil des Codes, für den eine Dokumentation fehlt/nicht in Ordnung ist. - Style (6 Punkte)
- Checkstyle muss fehlerfrei durchlaufen.
- Der Code muss abgesehen davon auch gut lesbar sein, insbesondere korrekt eingerückt sein.
- Abzug entsprechend der Menge an Fehlern: pro Fehler 1P Abzug.
- Modularität (4 Punkte)
- Wenn ein Teil des Codes für sich alleine umfangreich genug ist oder mehrfach benötigt wird, muss er in einer geeigneten Funktion stehen.
- Der Code für die Logik und die Grafik muss logisch voneinander getrennt sein.
- Abzug entsprechend dem Anteil des Codes, der nach den oben genannten Funktionen nicht in Ordnung ist. - Code-Qualität (4 Punkte)
- Kein unnötiger Hardcode
- Verwendung sinnvoller Typen
- Korrekte Verwendung von Zeigern/Referenzen statt Objekten
- pro Fehler 1P Abzug.
Const, public/private/protected, valgrind (20 Punkte)
Const-correctness (8 Punkte)
- pro Fehler 1P Abzug.Sinnvolle Einteilung in public/private/protected (6 Punkte)
- Abzug entsprechend dem Anteil der Funktionen/Variablen, für die der Modifier nicht ok ist. 6P Abzug wenn alles public ist.- Speicherlecks, valgrind (6 Punkte)
- pro Fehler 1P Abzug.