Hallo zusammen!

Ich möchte hier gerne eine allgemein Frage zu Softwareentwicklung stellen. Hierbei bezieht es sich nicht konkret auf Delphi, sondern ist eher theoretischer Natur.

Neben der Erlernung von Delphi arbeite ich derzeit auch noch mit der graphischen Programmiersprache Labview. Dort möchte ich ein Programm schreiben, naja was sonst wohl. Allerdings happert es da mit der Umsetzung. Bisher bin ich immer aus dem Bauch an ein Problem herangegangen, musste in letzter Zeit jedoch feststellen, dass das nicht sehr erfolgreich ist. Wie sagt man so schön, das Programmieren beginnt mit Papier und Beistift. Und da sind sie meine Probleme, die Umsetzung. So fällt es mir sehr schwer, eine Idee zunächst theoretisch und dann anschließend in eine Programmiersprache umzusetzen.

Aus diesem Grunde wollte ich mich hier mal bisschen schlau machen, wie ihr an eine Problemstellung rangeht und diese dann umsetzt? Vielleicht hat jemand auch ein kleines Tutorial parat oder mal ein konkretes Beispiel. Würde mich auf jeden Fall sehr freuen, denn damit würde ich hoffentlich einen grossen Sprung Richtung effizientere Programmierung hinlegen.

Danke schön und schöne Grüße
der Endanwender

Stichwort: Objektorientierte Programmierung

Das ist ein sehr umfassendes Thema... Also grobe Einteilung ist mal zuerst die Planungsphase und danach die Entwicklungsphase. Was die Entwicklungsphase ist, wird wohl klar sein, da codet man dann Die Planungsphase ist, je nachdem wie groß das Projket werden soll, unterschiedlich umfangreich. Für ein "Kleinstprogramm" (z.B. ein Programm, dass dir DM in € umrechnet oder so) braucht man so gut wie keine Planungsphase, da reicht es, wenn man sich das ne halbe Stunde überlegt und dann kann man gleich loscoden. Wenn das Projekt ein "kleines Projekt" ist (z.B. ein Programm, mit dem man seine Berge von CDs zu Hause verwaltet), sollte auf jeden Fall am Ende ein Klassendiagramm (UML?) dastehen. Dazu muss man sich natürlich erst mal darüber klar werden, was soll das Programm alles können etc. Das muss vorher feststehen. Bei einem Großprojekt (z.B. die Personalverwaltung von einem großen Konzern) muss man exterm Zeit darin investieren, herauszufinden, was das Programm alles können muss. Das schließt eine Menge Gespräche mit dem Kunden (der das Programm am Ende nutzt) ein und muss alles sehr wohl durchdacht sein. Da fallen dann auch mehr Diagramme an, als nur das Klassendiagramm. Zu diesem Thema gibt es dann aber unter Garantie Bücher (ich kenn jetzt aber keins).
Generell muss man natürlich iummer an die Dokumentation denken (in erster Linie die Doku für den Programmierer; z.B. PasDoc) und dass man Schnittstellen schafft, mithilfe denen man das Programmm nachher möglichst leicht erweitern kann (auf jeden Fall eine klare Objektstruktur (Vererbung!) und evtl. externe Schnittstellen zum Anbinden von z.B. DLLs).
Außerdem sollte natürlich immer, wenn irgendwo irgendwas gespeichert wird (z.B. in XML-Dtaeien oder in ner DB) diese auch dokumentiert und sorgfältig aufgebaut sein (ergibt dann auch sowas ähmliches wie ein Klassendigramm, nur eben mit "Datensatztypen" in der DB o.Ä.).


Das ist momentan alles was mir so einfällt...


MrSaint

EDIT: was ich noch vergessen habe: Vor der Entwicklungsphase sollte man sich einen Coding-Styleguide zusammenschreiben und sich auch immer daran halten. Weil nunmal jeder anders programmiert, müsste sich ein anderer nur den Styleguide neben hin legen und dann sollte er das Programm einigermaßen lesen können. In so einen Styleguide gehört zum Beispiel die ungarische Notation rein und dass alle Variablen aussagekräftige Namen haben müssen etc.

Wahrhaft gut gesprochen

Da ich auch noch Anfänger bin in Sachen Projekten behaupte ich mal, das auch viel Erfahrungssache ist und natürlich Kenntnis des Werkzeugs. Wenn man ein Projekt gleich 100% schaffen will und dann auch noch neue Sprachen,Funktionen,unbekanntes Terrain ausprobiert geht das IMHO meist gegen Baum

Naja, ob es gleich ein UML-Diagramm sein muss ... Ist zwar ganz nett und brauchbar, aber das Erlernen von UML ist auch nicht ohne. UML bringt wohl erst dann richtig was, wenn das Diagramm gleich maschinell in Code übersetzt werden kann. Das kostet dann aber auch richtig Geld ...

Ich jedenfalls komme (noch) ohne so etwas aus, und das schon seit 20 Jahren. Auf jeden Fall solltest Du Dein Problem erst mal in viele kleine Einzelaufgaben zerlegen. Zusammengehörige Daten in jeweils eine Klasse packen, und ihre Verarbeitung in verschiedene Routinen. Es hat sich bewährt, diese Routinen so klein zu halten, dass sie maximal drei Bildschirmseiten belegen, sonst weisst Du am Ende nicht mehr, was Du am Anfang geschrieben hast. Also besser eine komplexe Funktion in mehrere Einzelteile zerlegen. Ob das aber auch bei LabView so funktioniert, weiss ich nicht.

Styleguide und ausführliche Kommentare kann ich nur ausdrücklich empfehlen. Wir machen so etwas in der Firma seit Jahren, und besonders dann, wenn mehrere Leute an einem Projekt werkeln, oder sich andere Kollegen in eine Software einlesen sollen, ist das extrem hilfreich.

Viel Erfolg.