Commit 8539f166 authored by Andreas Zwinkau's avatar Andreas Zwinkau
Browse files

Mehr Tipps zum Entwurf

parent c8bfb8bb
......@@ -340,6 +340,63 @@ Design is the art of separation, grouping, abstraction, and hiding. The fulcrum
\item Formale Spezifikation von Kernkomponenten?
\end{itemize}
Unserer Erfahrung nach ist die Entwurfsphase die schwierigste,
da Studenten hier so gut wie keine Erfahrung haben
(im Gegensatz zur Implementierungsphase).
Deswegen hier ein paar konkrete Schritte,
die helfen sollen einen Anfang zu finden.
\begin{enumerate}
\item Sucht alle relevanten Substantive im Pflichtenheft heraus.
Viele davon lassen sich direkt als Klassen abbilden.
Zum Beispiel: Button, Level, Spielfigur, Bild, etc.
\item Was kann man mit diesen Objekten tun?
So erhält man die Methoden.
Beispielsweise kann man ein Bild drehen, anzeigen und umfärben.
\item In welcher Beziehung stehen die Objekte miteinander?
So erhält man die Pfeile im UML Diagramm.
Zum Beispiel weiß eine Spielfigur vielleicht in welchem Level sie ist.
\item Organisiert die Klassen sinnvoll in Gruppen.
So erhält man die Paketstruktur.
Beispielsweise Model-View-Controller könnte hier sichtbar werden.
\item Diese ersten Schritte kann man erstmal zügig in einer Sitzung
mit dem ganzen Team machen.
Anschließend kann man die Pakete oder Klassen einzelnen Personen zuordnen,
die dann eigenverantwortlich die Details ausarbeiten.
\item Nun ist die erste Woche rum.
Man hat einiges an Material produziert und kann es dem Betreuer zeigen.
\item Jetzt ist es auch an der Zeit mit dem eigentlichen Dokument zu beginnen.
Inbesondere sollten technische Fragen geklärt sein.
Womit erstellen wir unsere UML Diagramme?
Automatisches Erzeugen von Java-Code mit JavaDoc-Kommentaren
und daraus LaTeX und PDF erzeugen?
Das alles sollte man in der zweiten Woche zum Laufen bringen.
\item Da man nun bereits ein Dokument hat,
kann man grundlegende Entwurfsentscheidung sofort niederschreiben.
Sammelt erstmal alles in dem Dokument.
Ordnen und polieren kann man das später in der Phase.
\item Ein weiterer großer Brocken ist die Anbindung an die Platform,
die man benutzt. Beispielsweise Qt, Android oder ein anderes Framework.
Hier ist es oft ratsam ein paar minimale Beispielanwendungen zu bauen,
um ein Gefühl für die API zu bekommen.
\item Nach zwei Wochen sollten die meisten Klassen entworfen sein.
Allerdings hat üblicherweise jedes Teammitglied seinen Bereich für
sich bearbeitet.
Nun wird es Zeit sich mit der Integration zu beschäftigen.
Nehmt euch die Testfallszenarien aus dem Pflichtenheft
und spielt diese anhand des Klassendiagramms durch.
Wer ruft wen mit welchen Argumenten auf?
Üblicherweise fallen dabei viele Details auf,
wo man mehr Informationen weitergeben muss.
Das alles kann man in Sequenzdiagrammen festhalten.
\item Auch nicht zu vergessen sind Dinge die nicht im UML auftauchen.
Bilder, SQL-Schema, JSON-Schema, Tools wie ein Leveleditor, etc.
\item Nun sind drei von vier Wochen rum
und eigentlich sollte der Entwurf so ziemlich vollständig sein.
Jetzt ist genügen Zeit für Feinschliff, Präsentation
und Konsistenzprüfung.
\end{enumerate}
\subsection{Bewertung eines Entwurfs}
Hier ein paar Tipps, wie man einen Entwurf einschätzen kann.
......@@ -428,17 +485,26 @@ Paradoxe Anforderungen zeigen, dass gutes Design ein Kunst ist.
\subsection{Inhalt der Präsentation}
\begin{itemize}
\item Gerade für UML Diagramme wäre eine unkonventionelle Präsentation
mit \href{http://prezi.com/}{Prezi} einen Versuch wert.
Man kann ein großes allumfassendes Klassendiagram zeigen
und dann in Packages und Klassen reinzoomen.
\item Kurze Einführung und Verbindung zum Pflichtenheft
\item Ein Sequenzdiagram als anschauliches Beispiel
mit Ausschnitten aus dem Klassendiagramm.
Hier kann man ein Testfallszenario aus dem Pflichtenheft auswählen.
\item Überblick über das Gesamtklassendiagramm, Pakete, Module geben.
Hier kann man über die Verwendung von Entwurfsmustern erzählen.
\item Einhaltung softwaretechnischer Prinzipien zeigen
(z.B. Kohäsion, Lokalitätsprinzip, etc)
\item Gestrichene Wunschkriterien
\item Gestrichene Wunschkriterien können aber müssen nicht erwähnt werden.
Man muss hier aufpassen, dass kein negativer Eindruck zurückbleibt.
Für manches gibt es gute Gründe, aber oft ist es geschickter
Streichungen nur im Dokument zu erwähnen.
\item Verwendete externe Resourcen
(Bilder,Frameworks,Bibliotheken,Sounds,Musik,etc)
\item Nur kurz erwähnen weil eher langweilig:
Eigene Formate, Datenbankschemata, Einstellungen
Eigene Formate, Datenbankschemata, Einstellungen, Menüstruktur
und Dialoge.
\end{itemize}
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment