DIGITAL
Softwareengineering muss geübt werden.
In diesem Praxisorientierten Übungsblatt bekommen Sie die Möglichkeit ein etwas größeres Softwareengeneeringprojekt durchzuführen. Dabei wird im Gegensatz zur Funktionalität die genaue Struktur des Projektes nicht spezifiziert, weshalb es sich um eine Kreativaufgabe handelt. Bitte beachten Sie, dass es sich besonders bei dieser Übung um eine Gruppenarbeit handelt wobei es das Ziel ist es dass jede Lerngruppe jeden Schritt von der Konzeption bis zum finalen Code gemeinsam löst.
Die Aufgabe teilt sich in drei Teile auf.
Die Aufgabe teilt sich in Planung, Umsetzung und Erweiterung auf. Bei der Planung geht es darum, die grobe Struktur und das Zusammenspiel der verschiedenen Klassen zu erklären. Im Umsetzungsteil soll dieser abstrakte Plan als Code implementiert werden. Einer der schwersten Aspekte des Softwareengineering ist es Code zu schreiben, der flexibel und wartbar ist. Aus diesem Grund haben wir eine Erweiterung als letzten Teil der Übung angedacht: nach Fertigstellung des Hauptprojektes soll ein weiteres Feature eingebaut werden. Falls ihr Code gut gestaltet ist, sollte Ihnen dies leichter fallen. Nach einer Woche Bearbeitungszeit erscheint der Erweiterungsteil der Aufgabe. Die Erweiterung im Vorhinein nicht zu kennen ist hier teil der Übung.
Ablauf
In diesem Übungsblatt sollen Sie das Projekt planen und das Grundgerüst erarbeiten. Nach einer Woche erscheint ein weiteres Übungsblatt zum Erweiterungsteil der Übung, in dem weitere Features zu Ihrem Projekt hinzugefügt werden. Das komplette Projekt hat einer Bearbeitungszeit von zwei Wochen. Die Abgabe der beiden Teile erfolgt in ein einziges Repository.
Letzte Änderung: 01. June 2021, 09:48 Uhr
Sobald man mit einer Programmiersprache über for
-Loops zu der Definition von Klassen gekommen ist, ist es durchaus eine gute Übung, ein kleines Spiel zu implementieren. Natürlich wäre das Ganze mit GUIs und der Möglichkeit zu zeichnen sehr viel interessanter, aber leider sind wir noch nicht so weit. Aus dem Grund schreiben wir eine kleine Simulation, die uns direkt auf der Konsole ausgegeben werden soll. Ein Vorteil einer Simulation gegenüber einem interessanten Spiel ist, dass dynamische Tastenabfrage in der Konsole leider auch schwierig zu bewerkstelligen ist.
Der Hauptgrund für eine Simulation als Aufgabe ist, dass hierbei verschiedene Akteure selbstständig aufeinander reagieren. Diese Eigenschaft macht eine solche Simulation zu einem ausgezeichneten Kandidaten für eine OOP-Aufgabe.
Es gibt zwei Projekte zur Auswahl. Wählen Sie als Gruppe eines der beiden Projekte aus und bearbeiten Sie dann die Aufgaben.
Wählen Sie als erstes gemeinsam im Team eines der beiden Projekte aus und besprechen Sie neben dem internen Interesse auch eventuelle Pro- und Kontra-Argumente der jeweiligen dahinterliegenden Aufgaben. Überlegen Sie sich schon einmal, wie das Projekt gemeinsam gelöst werden kann. Es geht hier um Softwareengineering. Aufgabenverteilung, Planung und eine Verständigung innerhalb der Gruppe kann wichtig werden.
Lesen Sie vor der internen Besprechung die Anlage für Klassendiagramme und schauen Sie sich noch einmal intensiv die UML-Beispiele der Vorlesung an.
Überlegen Sie sich gemeinsam, welche Klassen Sie innerhalb Ihres Programmes verwenden werden müssten und welche Methode diese jeweils bereitstellen sollten. In der OOP gibt es zwei Ansätze, die dabei gefahren werden können:
class simulation
, darin ist eine Methode simulate
) und sich langsam immer mehr zu den spezielleren Klassen (etwa class car
) vorarbeiten.Beide Herangehensweisen bringen so ihre Vor- und Nachteile mit sich. Meiner persönlichen Erfahrung nach muss je nach Projekt abgewogen werden; Während das erstere zwar oft schneller zu einer schönen API führt, kann es schnell passieren, dass die gewünschten Pläne nicht so leicht umzusetzen sind und große Teile umgeschrieben werden müssen. Andererseits ist letzteres vielleicht näher am üblichen „direkt darauf los programmieren“, kann jedoch auch schnell zu Code, der nicht so leicht erweiterbar ist, führen und daher ebenfalls große Teile neu geschrieben werden müssen.
Dies einfach auszuprobieren und nach dem Bauchgefühl zu entscheiden ist Teil der Übung. ;)
Punkte gibt es für
Geben Sie das fertige Diagramm in ihrem Repository ab.
(Wie vorher auch ist es natürlich nicht zwingend erforderlich tikz-uml
zu verwenden.)
Als Hilfestellung bieten wir euch eine im eigenen Haus erstellte Konsolenbibliothek, die für die letzte Projektklausur entwickelt wurde und mit einigen Komfortfunktionen ausgestattet ist. Die Verwendung ist Freiwillig, jedoch stark empfohlen, da die Aufgabe sonst deutlich schwieriger wird. Beachten Sie jedoch falls sie die Bibliothek nicht nutzen möchten, dass im Rahmen der Erweiterung potentiell auch das Abfragen von gedrückten Tasten benötigt wird. Die Konsolenbibliothek selbst ist in QT geschrieben, kann aber ohne Wissen über QT über eine (sehr) einfache API verwendet werden. Sie bietet folgende Funktionen:
Genauere Informationen finden Sie in der Dokumentation der Konsolenbibliothek. Die Architektur ist Ereignissorientiert. Der Bildschirm wird ca. 20 mal pro Sekunde aktualisiert. Vor jedem Neuzeichnen wird die Methode "onRefresh()" aufgerufen, hier muss ihr Code integriert werden. Für eine langsamere Wiedergabe kann man z.B. nur jeden zweiten "OnRefresh()"-Zyklus ausführen.
Die dokumentierte Konsolenbibliothek ist in ihrem Repository hinterlegt. Öffnen Sie die Demo und machen Sie sich mit den API-Funktionen vertraut.
Implementieren Sie die von Ihnen ausgewählte Problemstellung.
Achten Sie bei der Abgabe darauf
main
-Methode anzufangen. Arbeiten Sie sich dann „von oben“ durch alle nötigen Programmebenen durch.Hinweise zur Korrektur: Ähnlich zur Klausur werden nur Features korrigiert, die funktionnieren und im Programm auffindbar sind. Im Code versteckte Features, die nicht voll funktional oder in der Benutzung nicht auffindbar sind, geben keine Punkte.