Wie geht man "vor dem tippen" vor?

[Gast]

Hallo zusammen,

ich habe ein organisatorisches planungs Problem.
Wenn man kein Bock auf UML hat, wie kann man trotzdem im vorraus sich eine gute Übersicht machen, was alles in ein Projekt muss (Klassen, Methoden, Variaben..)??
Einfach drauf losprogrammieren habe ich schon desöfteren und jedes mal erwische ich mich, wie ich etwas in eine Klasse packe, was nicht reinkommen sollte (wenn man diese Klasse z.B auch für andere Projekte weiterverwenden will).

Ich hab auch schon über diese Flußdiagramme nachgedacht, allerdings wäre das ja dann 20km lang, bei den ganzen Algorithmen und lohnt sich ja wirklich nur bei wenig aufwendigen Sachen.

Gruß und Thx

[Trap]

Im voraus wissen was genau man braucht geht nur bei Dingen, die man schonmal programmiert hat, und dann braucht man sie nichtmehr programmieren.

Je mehr man ohne Wissen über die tatsächlichen Anforderungen entscheidet, desto mehr kann falsch sein. Das gibt zusätzliche Arbeit das überhaupt zu erkennen, es im Team klarzumachen und sich dazu zu entscheiden es neu zu machen. Wenn man mit Implementierungsdetails anfängt weiß man nicht wie die im Programm verwendet werden, bei der Architektur ist nicht klar was überhaupt umsetzbar ist.

Am ehesten sinnvoll erscheint mir ein Ansatz in Richtung "test driven design".

[Arokh]

Wenn man kein Bock auf UML hat, wie kann man trotzdem im vorraus sich eine gute Übersicht machen, was alles in ein Projekt muss (Klassen, Methoden, Variaben..)??

[...]

Ich hab auch schon über diese Flußdiagramme nachgedachtdas verstehe ich jetzt nicht ganz... wenn du keinen Bock auf UML hast, was willst du dann mit Flußdiagrammen? Flußdiagramme gibt's auch bei UML, sie werden dort nur Aktivitätsdiagramme genannt. Wenn es dir um Diagramme geht, die es in UML nicht gibt, dann probier's doch mal mit Schicht- oder Säulendiagrammen: du unterteilst die Funktionalität des Programms in Schichten, und diese ggf. horizontal in Säulen. Einfaches Beispiel: du willst einen Würfel und eine Kugel graphisch darstellen, dann machst du als obere Schicht die graphische Ausgabe (View), und als unterliegende Schicht die Berechnung der zur Darstellung benötigten Daten (Model), die in zwei Säulen zerfällt, nämlich die Berechnung für den Würfel und die für die Kugel. Ein solches Diagramm wäre dann eine Vorstufe zum Klassendiagramm: jede Schicht/Säule kannst du in Klassen aufteilen oder selbst direkt als Klasse realisieren.

[Monger]

Es gibt viele Ansätze an ein Projekt ranzugehen - das wichtigste ist wohl schlicht ein Pflichtenheft, egal ob das nur ne halbe Seite umfasst oder dick wie eine Enzyklopädie ist. Alles was man machen will, muss irgendwo mal festgehalten sein.
Dazu gehören üblicherweise auch die Use Cases, d.h. mal ein paar Beispiele (in Text und Bild) was denn der Benutzer konkret mit dem Produkt anfangen soll. Eine Skizze von der Oberfläche ist auch nicht übel.

Wenn man das alles SAUBER macht, ist UML imho im Entwicklungsprozess eher nebensächlich. Ein UML Diagramm macht man, sobald man mit dem Projekt fertig ist, und es für Updates o.ä. dokumentieren will.

Wichtig ist, dass man das Ziel nicht aus den Augen verliert. Der technische Prozess sollte Mittel zum Zweck, und nicht etwa Selbstzweck sein.