Software-Design durch Pseudocodierung?

Kennen Sie eine gute Möglichkeit, Software mit einer auf Pseudocode basierenden Methode zu entwerfen (dh aufzuschreiben)?

Ich bin neu im Software-Design und lese einige Informationen über UML. Meine bescheidenen Klassenhierarchien sind bisher gut, aber nachdem es komplex geworden ist, stelle ich fest, dass ich mit dem "Sehen des ganzen" Bildes eine andere Struktur für mehr zukünftige Erweiterbarkeit hätte verwenden können. Da Python gut für das Prototyping geeignet ist, kann ich fast erst anfangen zu schreiben, aber nicht ganz.

Also habe ich UML-Klassendiagramme ausprobiert, aber sie scheinen mir nicht viel zu helfen. Die Probleme, die ich dort löse, kann ich trivial in meinem Kopf tun. Ich stelle jedoch zusätzliche Entwurfsanforderungen fest, sobald ich anfange, die tatsächlichen Methoden zu pseudocodieren.

Wenn Sie also per Pseudocode entwerfen möchten, wie würden Sie das tun? Ich glaube für mich, dass eine Methode, die mit Code ungefähr 1 zu 1 ist, am besten funktioniert. Die meisten UML-Programme zeigen jedoch nicht einmal den Code der Methode an (im Gegensatz zu Bildern in z. B. GoF).

Jemand behauptete, UML sei nur für Dokumentation und Präsentation gedacht und nicht so gut für Design? Ich habe auch dieses Gefühl. Ich dachte, reine UML und einige vereinfachte Whiteboard-Skizzen wären der Weg, um Software zu entwerfen, bis ich beim Googeln Envision APDT fand.

Ist agile Entwicklung etwas, worauf ich achten sollte, oder nennen sie das zufällig agil - ich dachte, bei agil geht es nur um Zeitplan? Oder entwerfe ich falsch (mit UML) - entwirft jemand per Pseudocode? Wie finde ich ein gutes Werkzeug dafür?

 I thought agile is about schedule only?

Es ist nicht nur Planung. Bei der agilen Softwareentwicklung geht es eher um eine evolutionäre Entwicklung und eine zeitgesteuerte iterative Bereitstellung mit adaptiver Planung, die eine flexible Reaktion auf vom Produktbesitzer angeforderte Änderungen fördert.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

Nach meiner Erfahrung sind Diagramme aus Sicht des Kundenstandes viel einfacher zu verstehen. Sie sind optisch ansprechend und oft sehr farbenfroh und leicht zu folgen. Aufgrund der Art der Trennung vom tatsächlichen Anwendungscode ist es jedoch sehr schwierig, Diagramme zu pflegen. Jedes Mal, wenn eine Änderung in der Anwendung vorgenommen wird, muss sich der Entwickler die Zeit nehmen, um alle Dokumentationen einschließlich der Diagramme zu aktualisieren. Dieses Problem kann jedoch leicht behoben werden, sobald ein BA im Team oder Unternehmen vorhanden ist, der die Geschäftsprozesse der Kunden gut versteht und die UML-Diagramme verwalten kann.

Tools wie UML können diesen Prozess vereinfachen, funktionieren jedoch nur mit objektorientierter Programmierung. Pseudocode ist für technische Teams viel einfacher. Der Prozess der Erstellung dieses Codes erhöht die Geschwindigkeit der eigentlichen Entwicklungsphase der Programmiersprache erheblich.

Es gibt einige andere Alternativen, nach denen Sie möglicherweise auch suchen:

• Datenflussdiagramme
• Zustandsdiagramme
• Prozessflussdiagramme

Gute Referenzen zum Anschauen: Software Design Tutorials . Außerdem würde ich persönlich raten, einen guten Blog über Pseudocode oder Code zu lesen ? Gepostet von Coding Horror - mein Lieblingsblog zum Lesen :)

Alles in allem gibt es einige Kompromisse, die Sie berücksichtigen müssen.

Beim Programmieren in Assemblersprache ist das Schreiben von Pseudocode sehr sinnvoll. Der Algorithmus könnte überprüft werden, bevor der Aufwand für die manuelle Übersetzung in die Assemblersprache und das anschließende Debuggen der Übersetzung aufgewendet wird. Für kompilierte Sprachen der ersten Generation wie FORTRAN IV, in denen das einzige Kontrollkonstrukt GOTO war, alle Variablen (außer formalen Argumenten) global waren und die Variablennamen auf sechs Zeichen beschränkt waren, war dies immer noch sinnvoll.

Heute programmieren wir sehr wenig in Assemblersprache, und ich sehe wenig Wert darin, Pseudocode zu schreiben, anstatt nur Code zu schreiben. In einer anständigen Sprache folgt der eigentliche Code fast wörtlich dem Pseudocode, und der Pseudocode ist nur Zeitverschwendung.

Ich beginne jedoch nicht unten mit dem Codieren. Ich folge TDD und beginne mit einem Test. Dann beginne ich oben mit dem Codieren und arbeite mich nach Bedarf nach unten, um die Tests zu bestehen.

Die Alternative zum Pseudocode besteht darin, nicht 1000 Zeilen Klassen niedriger Ebene zu schreiben. Beginnen Sie stattdessen oben und rufen Sie die ideale, aber nicht vorhandene API für Ihre Domain auf. Erstellen Sie dann die API.

Ich finde, dass Klassendiagramme kaum die Mühe wert sind, selbst wenn Sie die Auflistung aller Methoden überspringen und einfach die Vererbungshierarchie anzeigen. Sequenzdiagramme sind gut, fühlen sich aber beim Zeichnen unangenehm an (wahrscheinlich nur ich).

Ich finde Datenflussdiagramme und Strukturdiagramme nützlicher (obwohl Strukturdiagramme häufig mit BDUF assoziiert werden und daher derzeit nicht bevorzugt werden). DFDs sind besonders nützlich für die funktionelle Zersetzung. Jede "Blase" in einem DFD kann in ein eigenes DFD zerlegt werden, bis Sie den gewünschten Detaillierungsgrad erreicht haben.

Ich denke, grafische Werkzeuge sind besser als Pseudokodierung, aber UML ist einfach so überkompliziert, dass es das Schlechte in diesen Methoden kombiniert :-)

Um es etwas klarer zu machen: Ich denke, Programmierung ist meistens eine Möglichkeit, ein bestimmtes Problem zu analysieren, es in kleinere Komponenten und deren Interaktion aufzuteilen. Dies ist "eine Reise, kein Ziel". Sie verbessern ständig Ihr Wissen über das Problem, sodass sich das Diagramm der Komponenten ändert: Ebenen werden angezeigt und ausgeblendet, Funktionen und Datenelemente bewegen sich auf und ab usw.

Das natürliche Werkzeug, um diesem Prozess zu folgen, ist ein Skizzenbrett, so einfach wie möglich, aber komplex genug, um ein schnelles Verständnis zu ermöglichen (gleiche Farben, Formen, Pfeile für dieselbe logische Bedeutung). Ich habe die Silberkugel nicht gefunden, und vielleicht werde ich eines Tages meine eigene schreiben, aber jetzt benutze ich gliffy ; kombiniert mit der Zoomfunktion von prezi wäre es fast perfekt.

Warum nicht Pseudocodierung? Die Pseudokodierung ist ein Schritt vorwärts zur Implementierung, einer "serialisierten Form des Komponentendiagramms", wenn Sie Ihre Ideen noch formulieren. Nicht gut, schränkt deinen Kopf ein. Nach meiner Erfahrung muss ich umso weniger Code wegwerfen, je später ich mit dem Codieren beginne ...

Aber vielleicht liegt das daran, dass ich all diese weggeworfenen Codes geschrieben habe, damit ich sie jetzt nicht schreiben muss. Die Erfahrung, die ich daraus gemacht habe, liegt bei mir beim Entwerfen des Systems? Nun, ich muss die Aussage ändern.

Wenn Sie mit Ihrem Diagramm verloren gehen und viele gleichwertige mögliche Lösungen sehen, gehen Sie zum Pseudocode oder schreiben Sie diesen Code sogar mit Scheinobjekten - in Java ist das fast kein Unterschied. Sehen Sie sich den Code an, spüren Sie die Struktur und Benutzerfreundlichkeit dieser Komponenten und helfen Sie dabei, Ihr Diagramm zu korrigieren und Entscheidungen zu treffen. Dies funktioniert jedoch NUR, wenn Sie bereit sind, diesen Code wegzuwerfen, wenn Sie der Meinung sind, dass er schlecht ist. Ich denke, dies ist der Vorteil von Pseudocode: Je weniger Versuchung es zu behalten, wenn es funktioniert, aber es ist falsch in der Struktur (und wie immer haben Sie nicht genug Zeit). :-)