Skip to content
GitLab
Projects
Groups
Snippets
Help
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
pse-tipps
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
3
Issues
3
List
Boards
Labels
Service Desk
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Operations
Operations
Incidents
Environments
Analytics
Analytics
CI / CD
Repository
Value Stream
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
IPDSnelting
pse-tipps
Commits
8539f166
Commit
8539f166
authored
Jan 14, 2015
by
Andreas Zwinkau
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Mehr Tipps zum Entwurf
parent
c8bfb8bb
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
68 additions
and
2 deletions
+68
-2
tipps.tex
tipps.tex
+68
-2
No files found.
tipps.tex
View file @
8539f166
...
...
@@ -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}
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment