Hallo zusammen, wenn ich privat programmiere, programmiere ich meistens einfach drauf los und beginne erst während des Schreibens Teile in dedizierte Funktionen auszulagern usw. Ich finde das mittlerweile ziemlich mühselig. Ich würde künfitg gerne (1) erst die Grundstruktur der Software festlegen und (2) anschließend erst die ganzen Funktionen auskodieren. Ich vermute, dass es da für sicher schon etablierte Methoden/Entwurfsmuster usw. gibt. Könnt ihr mir da Hinweise geben? Wie geht man da am besten vor? Danke! LG!
:
Bearbeitet durch User
Ist zwar wahrscheinlich nicht genau das was du suchst, hilft dir aber vielleicht als Übersicht? https://de.wikipedia.org/wiki/Programmablaufplan https://de.wikipedia.org/wiki/Nassi-Shneiderman-Diagramm
Mark Twain schrieb: > UML? Und dabei kommt dann C++ heraus was keiner versteht. Sicherlich ist effizienter Code mehr als nur Spaghetti-Code. Wer etwas strukturiert vorgeht sollte das auch ohne UML und Erzeugnisse der Software-Ingenieure weiteres hinbekommen. Wichtig ist es erstmal zu abstrahieren. Denke dir im Kopf(oder auf Papier) welche Funktionen du brauchst. Schaffe dir einen "HAL" (Hardware Abstraction Layer). Beispiel: Du hast ein LCD, und brauchst Funtionen die an Zeile x,y ein Zeichen setzen. Also brauchst du sowas wie printf_lcd_xy... Kreise zeichnen etc. Im prinzip ist "printf" ja nichts anderes. Du musst nur einmal die Hardware "uart-puts" schreiben und dann kannst du das entsprechend "ummappen". Gleiches tust du mit read_adc, read_spi etc.
Wenn du denkst das du Software auf dem Papier entwerfen kannst, dann wird dein genialer theoretischer Softwareentwurf nur noch durch sein grandioses Scheitern übertroffen. Das sieht man immer wieder schön bei deutschen Großprojekten. Alle reden, werfen mit buzz words um sich und zeichnen tolle Diagramme. Aber trotzdem scheitern viele. Also ich würde dir empfehlen, mach brain storming, benutze für einzelne Teile Programmablaufpläne, schreibe Softwareprototypen und wenn die funktionieren dann programmiere das nochmal richtig "schön" unter Verwendung von design pattern. Deine Erfahrung wächst mit der Anzahl und Größe deiner Projekte. Programmieren ist ein Handwerk, dass man lernen (design pattern) und praktisch üben muss.
Manuel W. schrieb: > wenn ich privat programmiere, programmiere ich meistens > einfach drauf los und beginne erst während des Schreibens > Teile in dedizierte Funktionen auszulagern usw. Das muss nicht zwingend verkehrt sein. Für das "Wegwerfen und in besserer Form neu schreiben" gibt es den hochtrabenden Ausdruck "Refaktorisieren". > Ich finde das mittlerweile ziemlich mühselig. Ich würde > künfitg gerne (1) erst die Grundstruktur der Software > festlegen und (2) anschließend erst die ganzen Funktionen > auskodieren. Man kann nur programmieren, was man verstanden hat. Berechnungen kann ich "am Reißbrett" programmieren, die sollte ich verstanden haben, bevor ich mit Tippen beginne. Ein GUI muss ich ausprobieren können, denn ich muss erstmal sehen, wie es sich anfühlt. > Ich vermute, dass es da für sicher schon etablierte > Methoden/Entwurfsmuster usw. gibt. Könnt ihr mir da > Hinweise geben? Wie geht man da am besten vor? Es gibt zwei Grundstrategien: 1) Änderungen vermeiden. 2) Beliebig oft ändern -- aber so klar und strukturiert programmieren, dass Änderungen keinen großen Aufwand bedeuten. Der Trick besteht darin, für jedes Teilproblem die richtige Strategie zu wählen.
... schrieb: > Wenn du denkst das du Software auf dem Papier entwerfen kannst, dann > wird dein genialer theoretischer Softwareentwurf nur noch durch sein > grandioses Scheitern übertroffen. Ich gebe zu, ein PAP auf dem Papier gewinnt keinen Schönheitspreis. Aber er hilft ungemein, die Aufgabe in Schritte zu unterteilen und sich überhaupt erstmal den möglichen Ablauf klarzumachen und ihn auf logische Richtigkeit zu überprüfen. Und es geht deutlich schneller, als mit jedem Tool am PC. Und für Korrekturen nimmt man den Radiergummi. Man kann eben nicht alles im Kopf behalten. Meine Vorgehensweise für ein Projekt: 1. PC abschalten. 2. Papier, Bleistift und Radiergummi nehmen. 3. PAP erstellen. 4. PAP auf logische Fehler und Vollständigkeit prüfen. 5. PC einschalten. 6. PAP 1:1 in Code umsetzen.
Manuel W. schrieb: > Ich vermute, dass es da für sicher schon etablierte > Methoden/Entwurfsmuster usw. gibt. Könnt ihr mir da Hinweise geben? Wie > geht man da am besten vor? Es gibt etliche Bücher zum Thema Software Design. Ein gutes Buch zum Thema zu lesen kann sicher nicht schaden. Einen ersten Überblick kann der englische Wikipedia-Artikel geben: https://en.wikipedia.org/wiki/Software_design Übrigens: Bevor man überhaupt mit dem Software Design anfängt, steht erst einmal das Feststellen und Aufschreiben der Anforderungen. Was soll die Software bzw. das Gesamtprodukt machen? Wenn das so weit feststeht, dass man ein benutzbares und sinnvolles Programm bzw. System spezifiziert hat, dann fängt man damit an sich die Frage zu stellen wie dies umgesetzt werden soll.
Hallo Manuel, Manuel W. schrieb: > wenn ich privat programmiere, programmiere ich meistens einfach drauf > los und beginne erst während des Schreibens Teile in dedizierte > Funktionen auszulagern usw. was meist auch sehr hilfreich ist, die eigene "Planlosigkeit" im Zaun zu halten, ist sich die Anforderungen genau zu überlegen (wann bin ich fertig?). Gerade bei privaten Projekten lässt man das ja gerne mal auf sich zu kommen. mfg Torsten
Manuel W. schrieb: > wenn ich privat programmiere, programmiere ich meistens einfach drauf > los und beginne erst während des Schreibens Teile in dedizierte > Funktionen auszulagern usw. Hmm, genauso programmiere ich auch. Und das beruflich :) Okay, etliche Jahre an Erfahrung sorgen dafür, dass dabei auch was Gscheites rauskommt. Dabei beginne ich immer mit ganz einfachen Sachen, um zu testen, ob alles koscher ist. D.h., ich aktiviere die Led und kontrolliere mit der Stoppuhr, ob die eingestellte Clock-Frequenz auch richtig ist. Und dann geht es schrittweise weiter. Was ganz wichtig ist: Falls aus dem Funktionsnamen deren Sinn und Zweck nicht ersichtlich ist, hat jede Funktion einen kurze Beschreibung. Und zwar so, dass auch nach 10 Jahren der Groschen eine Chance hat, den Boden zu küssen. Sobald das Skellet Gestalt annimmt, beginne ich parallel das Handbuch zu erstellen. Ich habe naemlich die Erfahrung gemacht: sobald das Geraet ausgeliefert ist, fehlt einfach die Lust und auch die Zeit, dieses zu erstellen. Langer Rede kurzer Sinn: ich kann mich nicht erinnern, jemals ein Programm mit Bleistift und Papier begonnen zu haben. Was zwei Schlussfolgerungen zulaesst: entweder hatte ich bis heute keine allzu komplexen Aufgaben zu bewaeltigen. Oder ich kann auch sehr komplexe Probleme gedanklich in den Griff bekommen. Hoffe, dass es das letztere ist :)
Ich hatte sowas in der Schule, die ganzen Diagramme waren Schrecklich... Die Relevanten Ausdrücke sind hier unter anderem OOA und OOD. Bei OOA geht es um die Hauptaktoren, Grundanforderungen und Grundfunktionen. Alles nur ganz Grob, meist an Realen vorgängen Orientiert, und nicht an der Umsetzung. Man überlegt sich dann Beispielobjektinstanzen, und wie diese Interagieren. Die Beispielobjekt kann man in einem Objektdiagramm abbilden. Die Interaktionen kann man mit Aktivitätsdiagrammen abbilden. Dann gibt es da noch Dinge gie Anwendungsfalldiagrame usw. Bei OOD abstrahiert man das ein wenig, Man veralgemeinert Objekte in Objektdiagrammen zu Klassen in Klassendiagrammen. Man überlegt sich mögliche Methoden für die Klassen. Man betrachtet dann einzelne Ablaufe etwas genauer, mittels Sequenzdiagrammen. Es gibt auch hier viele weitere Diagramme. Dann kommen Hilfsklassen zur Anwendung von Patterns hinzu. z.B. Factories, singletons, etc. Und am Ende setzt man es ganz anders um, weil die entstandenen Ablaufe einfach nicht Sinnvoll sind. Ich mag diese Diagramme nicht.
1. Anforderungen möglichst genau spezifizieren (Papier oder im Kopf) 2. die grundlegendsten Funktionen testweise implementieren 3. ist kein Spaß! --> ein paar Tage nichts machen und einfach nur das Gehirn im "Hintergrund" das Puzzle zusammensetzen lassen --> eventuell wieder GOTO 2. 4. Programm fertig schreiben: immer in kleinen Schritten und dabei immer wieder testen
Ich mache es, wie ich es mal gelernt habe -genau so wie Peter Danegger. ->Bleistift, Papier und Radiergummi ->Den Ablauf in Klartext in den PAP eintragen ->Von Hand durchgehen, ob Alles berücksichtigt ist ->Ver-und-ungen, Ver-oder-ungen und Schiebereien von Hand auf Papier ausprobieren, um zu sehen, obe man die falschen Bits abgesägt hat. ->In den Rechner als Quelltext eingeben ->Syntax-Fehler finden ->Ganz wichtig: Den Papier-Pap(p) abheften, weil man sonst trotz Kommentaren nach ein paar Wochen nicht mehr weiß, WARUM das Programm überhaupt funktioniert. :-) MfG Paul
Nassi Shneidermann ist unnötig, da ist der Code selbst die bessere Dokumentation. Denn man macht nichts anderes, als die Abfragen in Diagrammform zu bringen und jede kleinste Änderung macht dich zum Papiertiger. Und komplexere Programme kann man so nicht mehr abbilden. In UML sieht man relativ gut die Abhängigkeiten und das Zusammenspiel der einzelnen Softwareblöcke. Dies zwingt einen dabei auch nicht Objektorientiert zu programmieren, man kann genauso die Implementation in C erledigen. Aber auch in UML kann man es zu weit treiben, oftmals genügt ein Klassen- und Objektdiagramm um die Übersicht des Programms zu wahren. Nach meiner Erfahrung beschränkt sich das eigentliche Code schreiben auf rund 30% meiner Zeit, der Rest ist vorher Design und danach Debug/Test.
Auch bei kleineren Projekten mache ich mir von den Datenstrukturen und Algorithmen immer mal wieder Zeichnungen auf Papier. Geht einfach schneller als am PC. Und es schadet auch nicht, wenn man mal ein paar Algorithmenschritte manuell durchgegangen ist. Wenn es ein neues Hobbyprojekt ist: 1. Grobe Anforderungen klären und aufschreiben (!) 2. Grundstruktur zeichnen - Welche Klassen/Platinen? Was ist drin? 3. Anforderungen überarbeiten (beim Hobby gibts immer wieder neue Ideen) 4. Grundstruktur überarbeiten 5. 3) und 4) wiederholen bis man halbwegs zufrieden ist 6. Los gehts!
Mehmet K. schrieb: > Dabei beginne ich immer mit ganz einfachen Sachen, um zu testen, ob > alles koscher ist. D.h., ich aktiviere die Led und kontrolliere mit der > Stoppuhr, ob die eingestellte Clock-Frequenz auch richtig ist. Und dann > geht es schrittweise weiter. So ähnlich mache ich es auch. Die einzelnen Schritte sind dabei sehr klein, und ihr Funktionieren kann möglichst getestet werden, bevor der nächste Schritt kommt. > Langer Rede kurzer Sinn: ich kann mich nicht erinnern, jemals ein > Programm mit Bleistift und Papier begonnen zu haben. Ich habe das im Studium mal machen müssen, im Fach "Software-Engineering". Hat für mich überhaupt nicht geklappt. Irgendwie denke ich an einem Rechner anders als auf dem Papier. Demenstprechend steht auf dem Papier dann was, das auf dem Rechner überhaupt nicht sinnvoll ist.
Ich denke, dass man mit dem objektorientierten Ansatz immer ganz gut einfach drauf los programmieren kann, ohne danach noch viele strukturelle Änderungen machen zu müssen.
Lassen wir mal den Zirkus um die einzige wahre Diagrammform für Softwareentwurf beiseite, denn es geht eigentlich um etwas anderes: Diagramme etc. sind Ausdruck von Gedanken und ein Kommunikationsmittel. Arbeitet man ein eine Lösungsentwurf sind sie sind Artefakte des Entwurfs. Der eigentliche Entwurf findet im Kopf statt. Die Sache mit dem Denken kann man und sollte man trainieren. In welcher Form man das Ergebnis des Nachdenkens dokumentiert, ob PAP, eines der x UML Diagrammtypen, Pseudocode, ausführlichen Beschreibungen ist mehr äußeren Zwängen und persönlichen Vorlieben geschuldet. Es sollte allerdings dem Zweck angemessen sein. Das sind mechanische Abläufe die nicht das Denken ersetzen. Die mechanischen Ablaufe kann man lernen. Bei der Lösungsfindung im Kopf und der Dokumentation einer Lösung gibt es einen Sonderfall. Zeichnen, genauer das Freihandzeichnen, kann selber eine Rolle bei der Lösungsfindung spielen. Die Maschinenbauer kennen vielleicht 'Ulrich Viebahn: Technisches Freihandzeichnen'. Natürlich ist freihändig konstruieren etwas anders als ein Flussdiagramm zu malen, aber bei beiden gibt es eine Rückkopplung. Der manuelle Vorgang des Zeichnens kann Ideen auslöst, d.h. hilft bei der Lösungsfindung.
Theo Regler schrieb: > Ich denke, dass man mit dem objektorientierten Ansatz immer ganz gut > einfach drauf los programmieren kann, ohne danach noch viele > strukturelle Änderungen machen zu müssen. Gerade mit OOP kann man sich ohne Planung wunderbar ins Knie schiessen, meistens ist dann auch gleich das ganze Bein weg. Besonders in meinen Anfängen mit C++ habe ich teilweise ganze Programme oder Programmteile weggeschmissen, weil die Struktur einfach nur verkrüppelter Murks war. @TO: Schau dir mal diesen Thread an, evt. ist da was für dich dabei: Beitrag "Wie große Programme programmieren?"
Theo Regler schrieb: > Ich denke, dass man mit dem objektorientierten Ansatz immer ganz gut > einfach drauf los programmieren kann, ohne danach noch viele > strukturelle Änderungen machen zu müssen. Mit Sicherheit nicht. Trollst Du noch oder trägst Du schon etwas Sinnvolles bei?
Manuel W. schrieb: > programmiere ich meistens einfach drauf > los und beginne erst während des Schreibens Teile in dedizierte > Funktionen auszulagern usw. genau so machen das die Profis. Lass dir blos nichts anderes einreden.
Jay schrieb: > Lassen wir mal den Zirkus um die einzige wahre Diagrammform für > Softwareentwurf beiseite, denn es geht eigentlich um etwas anderes: Auch wenn ich deinem nachfolgenden Text im Grossem zustimme, so geht es eigentlich genau um die Diagrammform. Schliesslich fragt er: Manuel W. schrieb: > Ich vermute, dass es da für sicher schon etablierte > Methoden/Entwurfsmuster usw. gibt. Könnt ihr mir da Hinweise geben? Wie > geht man da am besten vor? Und nicht die Frage, ob das Vorgehen mit Papier und Stift zu beginn der Softwareentwicklung die beste Vorgehensweise ist. Leider führten die ersten paar Antworten zu einer völlig anderen Diskussion als vermutlich gewünscht.
Stefan schrieb: > genau so machen das die Profis. Lass dir blos nichts > anderes einreden. Super. "Ein Amateur baute die Arche Noah, Profis die Titanic."
Stefan schrieb: > Manuel W. schrieb: >> programmiere ich meistens einfach drauf >> los und beginne erst während des Schreibens Teile in dedizierte >> Funktionen auszulagern usw. > > genau so machen das die Profis. Lass dir blos nichts anderes einreden. Nö. Zumindest macht man es nicht durchgängig so. Spätestens wenn man eine API programmiert legt man vorher fest, welche Funktionen es geben soll und was diese tun sollen. Dass es immer mal wieder Refactoring gibt, z.B. dass man eine zu groß gewordene Funktion in mehrere kleine aufteilt: Klar, das kommt vor.
:
Bearbeitet durch User
Wenn ich anfange und erst mal keinen grossen Plan habe wie die gesamtarchitektur aussehen wird, lagere ich alles wahllos in Funktionen aus und zwar möglichst viel besser zwei Funktionen mehr als zu wenig. Später wenn man mal ansatzweise eine Klassenstruktur sich herauskristalisiert wandern die Funktionen in die einzelnen Klassen. Das Problem ist meisten dass sie die Anforderungen später immer wieder die Klassenstruktur betreffen aber die Entwicklung "im Kleinen" also die Funktionen die die eigentliche Arbeit machen bleiben weitgehend gleich. So muss man später nur noch ein paar Funktionen zurechtbiegen (Parameter...) wenn man sie in Klassen einbaut. Das ist vielleicht nicht der offizielle saubere Stil aber er hat sich bei mir bestens bewährt: Software wie am Reissbrett per UML also erst mal im Grossen zu entwerfen funktioniert für gewisse Anwendungen. Im Embeddedbereich und einigen anderen Bereichen ich nenne sie mal der mid-size-range-Grösse ist es murks. Man muss die tolle Architektur immer nachpflegen (Refactoring) weil die Anforderungen oft noch nicht in Beton gegossen sind und somit ist es auch vergeugete Zeit sich frühzeitig über die Architektur Gedanken zu machen. Die weiss man im Groben schon vorher aber eben die Ausarbeitung in detailierte Klassenbeziehungen ist oft vertane Zeit. Ich nenne das Softwareentwicklung "von Innen heraus", also weder vom Grossen zum Kleinen (wie mit UML und OOA/D) hin oder umgekehrt. Im Studium hies es immer bei OOA/D ist das einzig Wahre und nie schon in der Analysephase sich Gedanken über Details in der Implementierung machen. Ich hielt das immer für Falsch weil ich dann nämlich schon mal vor unangenehmen Überraschungen verschont werde, meist Performanceproblem weil der Klassenzoo vom "Analyst" in der Praxis unbrauchbar ist. Und immer viel Testen, das geht auch schon wenn man nur die Funktionen ausprogrammiert hat und noch gar keine Klassen vorhanden sind. Auch ein Vorteil wenn man schon früh genug testen kann.
Bezirksbefruchter schrieb: > Und immer viel Testen, das geht auch schon wenn man nur die Funktionen > ausprogrammiert hat und noch gar keine Klassen vorhanden sind. Auch ein > Vorteil wenn man schon früh genug testen kann. Wie testest du das? Die Memberfunktionen meiner Klassen greifen auf die Membervariablen zu. Wenn sie das nicht tun wurden, hätten sie keine Daseinsberechtigung als Memberfunktion sondern nur als Freistehende.
@ Jay Es gibt tatsächlich etablierte Methoden. Andererseits hat jeder auch so seine eigene Denk- und Vorstellungsweise. Die sollte man nicht ohne weiteres verwerfen. Will sagen: Ich empfehle Dir, zunächst einmal ein oder zwei Paradigmen kennenzulernen, sie dann anzuwenden und, falls notwendig, so zu anzupassen, dass sie für Dich das leisten, was Du möchtest. Danach wieder mal ein oder zwei weiter Methoden anschauen. Das passt auch dazu, wie es diesen Methoden selbst ergeht. Sie werden immer wieder verändert und neue kommen hinzu. Was dafür spricht, dass es nicht DIE eine ultimative Methode gibt. Sollte ich sagen müssen, welche Methode Du als erstes lernen solltest würde ich, von mir ausgehend, zwei empfehlen: 1. Das Use-Case-Diagramm: Ausgehend von einem Strichmännchchen (das nicht nur eine Person sondern, auch ein System sein kann) werden, werden die Tätigkeiten aufgeführt und in Ist-Teil-Aktivität-von-Beziehungen zu den Aktivitäten der Software gesetzt. Ich selbst neige dazu, relativ tiefe Strukturen zu zeichnen, aber das wird irgendwann so detailliert, dass man die Software auch gleich schreiben kann. Wenn man mehr als 3 oder 4 Ebenen zeichnet, sollte man mal kritisch überdenken ob das wirklich notwendig ist, oder ob man sich nicht schon anhand der Kurzbeschreibung der Aktivität allein, - und auch später, mit zeitlichem Abstand -, die Details denken kann. Extrem unnötig scheint mir, wenn man eine Aktivität wie "Zähler inkrementieren" oder ähnliches hinschreiben will. (Siehe auch unten die Bemerkung zu Bedingungen). Erweiterungen von Use-Case-Diagrammen berücksichtigen auch Entscheidungen resp. Bedingungen und anderes. Diese Methode hat aus meiner Sicht den Vorteil, dass sie von dem eigentlichen Anlass ausgeht, der einen dazu treibt eine bestimmte Software zu schreiben: Der Benutzer (oft man selbst) will eine bestimmte Aktivität durchführen. Dazu gehören diese und jene Teilaktivitäten, welche die SW ausführen soll. Viele Menschen neigen nämlich dazu, sich recht schnell auf Implementierungsdetails zu konzentrieren und verlieren dabei den jeweiligen Zweck aus den Augen. Analoges sieht man übrigens hier im Forum, in dem recht oft nach Detailproblemen einer Implementierung gefragt wird, ohne dass der zugrundeliegende Zweck genannt wird. Daher wird auch in der Netiquette (mit einer kurzen Begründung) darauf hingewiesen, immer auch den eigentlichen Zweck zu nennen. Analoges gilt auch für Software. 2. Datenflussdiagramme: Ich weiss nicht ob sich das UML schon einverleibt hat, aber unter dem Stichwort findet man sicher noch einiges im Internet darüber. Genau genommen habe ich die zuerst verwendet. Der wesentliche Aspekt ist die Beziehung von Daten und den Funktionen die Eingangsdaten in Ausgangsdaten "umrechnen". In einem etwas grösseren Projekt wird es irgendwann mühsam, das Gesamtbild dieser Beziehungen zu vergegenwärtigen. Welche Funktion ist eigentlich nochmal für was zuständig? Und es hilft beim Entwurf, die Daten und die Funktionen sinnvoll zu gliedern. Wenn man in einem menügesteuerten Thermometer irgendwo die Temperatur und eine Menüposition in die selbe Funktion eingibt und daraus ein Seiteneffekt auf die Cursorposition und die Anzeige einer Zahl erfolgt, dann ist das auffällig und wird im allgemeinen als falsches Design angesehen. Funktionen sollten möglichst nur eine Sache erledigen. (Das ist natürlich nur ein einfaches Beispiel). In diesem Diagramm spielen Bedingungen eine untergeordnete Rolle. Es gibt, meiner Ansicht nach, nur zwei wesentliche Anwendungsfälle für Bedingungen: 1. Es wird auf recht hoher Ebene entschieden, welche von mehreren Hauptaktivitäten des Programmes ausgeführt werden soll und 2. sozusagen "elementare" oder "triviale" Entscheidungen, wie etwa die Berücksichtigung eines Vorzeichens bei einer Berechnung oder ähnliches. Weil man den ersten Fall oft ohnehin im Kopf hat, - er unterscheidet ja ganz global über den Ablauf -, ist es oft nicht notwendig, das festzuhalten. (Wenn doch, dann geht das im Use-Case-Diagramm). Der zweite Fall betrifft aber das ganz detaillierte Vorgehen, dass sich aus der Kenntnis des Algorithmus und dem Hinschreiben ohne Weiteres zwangsweise ergibt. Es ist ganz allgemein ein Problem bei diesen Entwurfsmethoden, nicht zu detailliert zu werden, weil das einfach zu viel Zeit benötigt. Andererseits kann es hilfreich sein, sehr detailliert zu werden, wenn man einen Algorithmus das erste Mal verwendet oder auch einen neuen Algorithmus erfindet. Aber da muss jeder seine Form finden. Es wird noch andere "Lieblingsformen" geben. Sie haben alle ihre Berechtigung, weil sie für denjenigen "funktionieren". Die Supermethode gibt es nicht. Ich denke man muss aber bei allen diesen Methoden berücksichtigen, dass sie recht früh von den Betriebswirtschaftlern sozusagen "in Besitz" genommen wurden. Ende der 80er Jahre begann man im Management, die "Erstellung" von Software eher als konstruktive Tätigkeit im Gegensatz zu einer kreativen Tätigkeit darzustellen. Der Gegensatz ist, meiner Ansicht nach, nicht vorhanden, aber ich will hier darüber keine Diskussion anfangen. Das war ohnehin nur der erste Schritt, mit der Vision, das Entwerfen und Implementieren von Software als rein mechanische Tätigkeit darzustellen, die man zum einen geringer bezahlten "Programmierern" (also Leuten, die nur einen Entwurf implementieren) überlassen konnte und die andererseits, - wie das Ausheben von Gräben -, einfacher kalkulierbar sein sollte. Diese Entwurfsmethoden aber sollten letztlich von Leuten benutzt werden, welche spezifizieren, was die Software tun soll, die "wissen was wichtig ist" (die Kaufleute natürlich) und sich nicht in "Spielereien" vertun, wie die ohnehin sozial unverträglichen Nerds, die einem stundenlang über Carry-Flags erzählen können. Funktioniert hat diese Vision bis heute nicht. Die Methoden sind (bis auf wenige Ausnahmen) bis heute nur von Leuten anwendbar, die auch designen können und die wenigen Ausnahmen geben so abstrakte Darstellungen, dass daraus in keinem Fall, auf mechanischem Wege eine Implementierung abzuleiten ist. Ich hoffe, der lange Sermon, hilft Dir weiter.
Stefan schrieb: > Manuel W. schrieb: >> programmiere ich meistens einfach drauf >> los und beginne erst während des Schreibens Teile in dedizierte >> Funktionen auszulagern usw. > > genau so machen das die Profis. Lass dir blos nichts anderes einreden. Tatsächlich Profis? Dilettanten!! Anfang: Das Programm, System, Gerät usw. beschreiben wir einfach per Hand auf einem Blatt DINA4 mit möglichst mit wenigen Sätzen. Wie soll es sich verhalten? Was soll es machen? Gemälde, in welcher Notation auch immer dürfen - mit der Hand gemalt - nicht über die Seite hinausgehen. Diese Begrenzung ist wichtig. Wir sind gezwungen, uns auf das Wesentliche zu konzentrieren. Natürlich ist damit nicht das Ganze beschrieben, sondern nur die betrachtet Ebene. Daraus ergeben sich natürlich weitere Elemente, die noch zu beschreiben sind. Das machen wir später. Die Beschreibung übertragen wir auf den Rechner, als Kommentar und teilweise als Code in der Programmiersprache. Wir haben damit ein bereits dokumentiertes Programm. Auf Gemälde verweisen wir einfach. Die einzelnen Programmelemente bekommen die langen Namen aus der Beschreibung. Abkürzungen sind nicht erlaubt. Wir sind damit in der Lage, mit einer Mischung aus Kode und Kommentar das System zu beschreiben. Wir können sogar schon den Kode für diesen Teil schreiben. In den meisten Fällen ergeben sich daraus Unterprogramme oder auch Klassen, die benötigt werden. Wir können sogar beschreiben, was diese leisten sollen. Das machen wir genauso, wie unter "Anfang" beschrieben. Immer wieder, Immer wieder ... Der Clou des Vorgehens ist, das wir schon früh anfangen zu kodieren und dabei feststellen, ob das Ganze überhaupt funktionieren kann. Oft ist es eine gute Idee, für ein Unter-Programmteil einfach einen Dummy zu schreiben, der es simpel zu simuliert. Wer das öfter angewandt hat, ist dann in der Lage, weitgehend auf Papier zu verzichten und unmittelbar in den Rechner zu schreiben. Er weiss, wie knapp die Beschreibung sein sollte. Die dokumentierte Klärung ist wichtig. Die wiederholte Anwendung der der obigen Vorgehensweise führt zu einem strukturierten Programm mit Unterprogrammen und Klassen, die hierarchisch aufgebaut sind und sich logisch aus der darüber liegenden Ebene ergeben. (Für die OOP'ler: Klassen werden auf diese Weise komponiert.) Eigentlich entspricht das Vorgehen dem >> programmiere ich meistens einfach drauf >> los und beginne erst während des Schreibens Teile in dedizierte >> Funktionen auszulagern usw. Aber nicht einfach einfach drauf los! Und genau dieses unterscheidet den Profi vom Dilettanten. Jemand, der mit Programmieren sein Geld verdient, ist damit noch lange kein Profi. Lasst euch blos nichts anderes einreden.
Heiner K. schrieb: > Jemand, der mit Programmieren sein Geld verdient, ist damit noch lange > kein Profi. Das stimmt zu 100%. Die Menge an schlechtem Code ist Legion.
Mark B. schrieb: > Theo Regler schrieb: >> Ich denke, dass man mit dem objektorientierten Ansatz immer ganz gut >> einfach drauf los programmieren kann, ohne danach noch viele >> strukturelle Änderungen machen zu müssen. > > Mit Sicherheit nicht. Ich sehe das Problem nicht. Nehmen wir an, man programmiert einen µC. Zuerst erstellt man Klassen für die einzelnen Komponenten. Danach kann man diese je nach Bedarf zum Beispiel in der Main Funktion ansteuern. Optinal können die Komponentenklassen wiederum andere Klassen benutzen, zum Beispiel einen Ringpuffer oder ähnliches. Bei der Steuerungssoftware mache ich es genauso. Bei Windows-Programmen erstellt man wiederum modulare Klassen, je nach Thema oder Funktion und alles programmiert sich wie von selbst, ohne sich vorher großartig Gedanken zu machen. Alles zusammen lässt sich dann ganz einfach zu einem übersichtlichen und kompakten Programm zusammenbauen.
Theo Regler schrieb: > Mark B. schrieb: >> Theo Regler schrieb: >>> Ich denke, dass man mit dem objektorientierten Ansatz immer ganz gut >>> einfach drauf los programmieren kann, ohne danach noch viele >>> strukturelle Änderungen machen zu müssen. >> >> Mit Sicherheit nicht. > > Ich sehe das Problem nicht. Nehmen wir an, man programmiert einen µC. > Zuerst erstellt man Klassen für die einzelnen Komponenten. Danach kann > man diese je nach Bedarf zum Beispiel in der Main Funktion ansteuern. Genau umgekehrt wird eine Schuh daraus. Die Main Funktion wird zuerst beschrieben und nur die benötigten Klassen für die benötigten Komponenten werden dann erstellt. Sonst werden Rüschen programmiert, die schön anzusehen sind und kein Mensch wirklich braucht. Oder was häufiger der Fall ist, den benötigten Anforderungen nicht entsprechen und dann angepasst werden müssen. Ich gehe mal davon aus, dass Theo eine mehr oder weniger klare Vorstellung davon hat, was die Main Funktion machen soll und was dabei benötigt wird. Warum schreibt er es dann nicht auch auf? Ich habe den Verdacht, dass wir eine Schere im Kopf haben, die uns davon abhält, etwas einfach - nicht simpel - zu machen und das anderen zugänglich zu machen. Etwas auf den Punkt zu bringen, ist aber die kreative Leistung. Und wenn wir dann strukturiert vorgehen, müssen wir tatsächlich selten strukturelle Änderungen machen. Das ist übrigens ein alter Hut von Niklaus Wirth.
Heiner K. schrieb: > Das ist übrigens ein alter Hut von Niklaus Wirth. Hier trägt er ihn: http://www.quotationof.com/images250_/niklaus-wirth-3.jpg :-) mfG Paul
Heiner K. schrieb: > Die Main Funktion wird zuerst beschrieben und nur die benötigten Klassen > für die benötigten Komponenten werden dann erstellt. Naja.. in der main herrscht natürlich noch gähnende Leere, solange man noch keinen Treiber für die Komponenten hat. Ich setze dort zunächst nur mal diese und mal jene Funktionen rein, um die Softwareteile zu testen. Mir persönlich hilft es enorm zuerst die Komponentenklassen zu erstellen, ohne groß darauf zu achten, was ich davon in meinem speziellen Programm tatsächlich brauchen werde. Somit sind schonmal die ersten Programmteile fertig die modular in verschiedene Programmen einfach eingefügt werden können. Heiner K. schrieb: > Oder was häufiger der Fall ist, den benötigten Anforderungen nicht > entsprechen und dann angepasst werden müssen. Eigentlich ist das kein nennenswertes Problem. Es geht hier ja in dem Thread darum, dass man keine Umstrukturieren der Software machen muss. Wenn etwas noch nicht implementiert ist, kann man es an enstprechender Stelle ohne struktureller Veränderungen erweitern. Besser ist es natürlich bereits vorher universelle Softwarepakete zu schreiben. Diese universellen Softwarepakete lassen sich für mich aber um so leichter schreiben, je weniger ich daran denke, was ich in dem speziellen Programm wirklich brauchen werde. Heiner K. schrieb: > Warum schreibt er es dann nicht auch auf? Mach ich doch. Der Quellcode ist die Dokumentation. :P
Heiner K. schrieb: > Dilettanten!! An Selbstüberschätzung leidest Du vermutlich nicht :-) Ich programmiere zwar beruflich keine Mikrocontroller aber anderweitig, hier nicht "hoffähig". Nur privat arbeite ich mit MC's. Eigentlich gehe ich, wie Peter es beschrieben hat (Flussdiagramm etc.) - vor, aber wirklich aufzeichnen tue ich das nur noch selten. In den Anfangsjahren öfter, da es einen wirklich guten Anhalt gibt. Heute arbeite ich ähnlich wie Du - stelle ein Gerüst (analog Flussdiagramm) im Programm auf und fülle nach und nach die (ggf. weiter verzweigten) "Unterroutinen". Ich spare mir also lediglich Papier, Bleistift und Radiergummi und arbeite direkt im System und erzeuge Rümpfe oder Prototypen. Das wird Schritt für Schritt verfeinert und ggf. umgestellt / angepasst. Ohne eine halbwegs präzise Vorgabe, was eigentlich erwartet wird (Pflichtenheft) geht das natürlich nicht - aber zumindest in meiner Umgebung sind diese Wünsche oft eher "nebulös". Da hilft nur eine halbwegs vernünftige Sachkenntnis, um den Anforderungen gerecht zu werden.
Heiner K. schrieb: > Jemand, der mit Programmieren sein Geld verdient, ist damit noch lange > kein Profi. Jeder, der mit Programmieren Geld verdient, ist Profi. Ob er ein guter Programmierer ist, sei dahin gestellt. (Profi => professionell => Profession => Beruf)
Heiner K. schrieb: > > Genau umgekehrt wird eine Schuh daraus. > Das eine nennt sich "Top-Down", dass andere "Bottom-Up". Nicht, "Richtig" und "Falsch". > [...] > > Das ist übrigens ein alter Hut von Niklaus Wirth. Ist das ein Autoritäts-Argument oder gar ein religiöses? Egal. Ist beides unzweckmäßig.
Holla die Waldfee, was hab ich hier denn losgetreten? Also vielen Dank erstmal für die angeregte Diskussion, ich habe schon einiges daraus mitgenommen. Operator S. schrieb: > Jay schrieb: >> Lassen wir mal den Zirkus um die einzige wahre Diagrammform für >> Softwareentwurf beiseite, denn es geht eigentlich um etwas anderes: > > Auch wenn ich deinem nachfolgenden Text im Grossem zustimme, so geht es > eigentlich genau um die Diagrammform. Schliesslich fragt er: > > Manuel W. schrieb: >> Ich vermute, dass es da für sicher schon etablierte >> Methoden/Entwurfsmuster usw. gibt. Könnt ihr mir da Hinweise geben? Wie >> geht man da am besten vor? > > Und nicht die Frage, ob das Vorgehen mit Papier und Stift zu beginn > der Softwareentwicklung die beste Vorgehensweise ist. Leider führten die > ersten paar Antworten zu einer völlig anderen Diskussion als vermutlich > gewünscht. Da hast du Recht. Mir geht es tatsächlich nicht um das ob, denn das steht für mich außer Frage. Ich glaube gerne das andere so erfahren sind, dass sie ohne lang zu planen gleich drauf los legen können, und intuitiv das Richtige machen; aber ich gehöre nicht zu dieser Gruppe. Wenn ich bedenke, wie oft ich bereits geschriebenen Code nochmal anpassen musste, und wieviel Tipparbeit ich in Summe bereits umsonst spendiert habe... Also effizient ist was anderes! Ich würde die Diskussion also tatsächlich gern vom "ob planen" zum "wie planen" lenken. Weiter oben wurde bereits einige Male "PAP" erwähnt. Das steht dann wohl für "Programmablaufplan". Ich habe mich da ein bisschen eingelesen, und mir kommt es vor, als wenn man da schon wirklich sehr im Detail wäre. Bei der Auskodierung der Funktionen quasi. Mir geht es mehr darum, die "Grobstruktur" der Software festzulegen. Aus welchen logisch voneinander trennbaren Elementen besteht meine Software? Welches Element kommuniziert mit welchem? Welche Elemente isoliere ich voneinander am besten um Wiederverwendbarkeit für künftige Projekte zu haben? (= Abstraktion.) Und so weiter. Also wenn ich OOP richtig verstanden habe, geht es schon so ein bisschen in Richtung "welche Klassen habe ich?" Das Problem ist halt: Mein Kopf ist nicht groß genug, um alles im Hirn zu behalten. Wenn ich das Projekt von Anfang bis zum Ende durchgedacht habe, habe ich den Anfang schon wieder vergessen. Ich muss einfach zwischendurch Sachen auf Papier (oder von mir aus eine Datei am Computer) auslagern. Und ich weiß nicht, wie ich das am besten mache. Jede "Klasse" ein Kästchen? Methoden als Verbindungslinien? Oder ganz anders?
:
Bearbeitet durch User
Be S. schrieb: > Theo Regler schrieb: >> Ich denke, dass man mit dem objektorientierten Ansatz immer ganz gut >> einfach drauf los programmieren kann, ohne danach noch viele >> strukturelle Änderungen machen zu müssen. > > Gerade mit OOP kann man sich ohne Planung wunderbar ins Knie schiessen, > meistens ist dann auch gleich das ganze Bein weg. Besonders in meinen > Anfängen mit C++ habe ich teilweise ganze Programme oder Programmteile > weggeschmissen, weil die Struktur einfach nur verkrüppelter Murks war. > > > @TO: > Schau dir mal diesen Thread an, evt. ist da was für dich dabei: > Beitrag "Wie große Programme programmieren?" Danke für diesen Link! Du sprichst mir aus der Seele und der Link war gold wert, ich habe ihn regelrecht verschlungen!
Manuel W. schrieb: >> Beitrag "Wie große Programme programmieren?" Den kannte ich nicht - und auch ich bedanke mich.
Manuel W. schrieb: > Ich würde die Diskussion also tatsächlich gern vom "ob planen" zum "wie > planen" lenken. > > Weiter oben wurde bereits einige Male "PAP" erwähnt. Das steht dann wohl > für "Programmablaufplan". Ich habe mich da ein bisschen eingelesen, und > mir kommt es vor, als wenn man da schon wirklich sehr im Detail wäre. > Bei der Auskodierung der Funktionen quasi. Tja, wie planen.. Also, zumeist fängt das ganze bei mir mit dem Papier und Bleistift an - aber anders als bei Peter: Ich mach mir zuerst Gedanken darüber, was ich voraussichtlich an Hardware brauche, also wieviele Pins, was für Funktionen und so. Dann kommt das Suchen nach nem geeignet erscheinenden Controller und dann das Zuordnen der Signale zu dessen Pins. Anschließend weiß ich, was für Lowest-Level-Funktionen ich in diversen noch zu schreibenden Treibern brauche. Also nicht "PinXYZ(low oder high)" sondern "Motor(ein oder aus). Damit endet bei mir die Papier-Phase erstmal. Eine zweite kommt später. Dann kommt der schiere Anfangs-Krempel, also erstes Greifen in die Tasten für Zeugs wie System und Takte aufsetzen. Dann ne Pause für das gedankliche Reifen des Ganzen und ggf. alles umstülpen und nochmal von vorne. Jetzt kommt die zweite Papier-Phase, wo die Abläufe, deren Überwachung, die diversen Protokolle und so zunächst erstmal salopp und dann möglichst präzise formuliert werden. Ich denke mal, 60% Bleistift, 40% Radiergummi. Aber kein PAP. PAP empfinde ich als fast immer unzureichend, denn das bedeutet im µC Zeit vergammeln und ggf. hängenbleiben. Ich mach das Ganze lieber ereignisgesteuert und mit verzögerten Events als Zeitüberwachung für alle Hardwarevorgänge. Schließlich soll der µC ja auf Fehlersituaionen auch noch irgendwie reagieren können, so daß die Kiste wieder in die Gänge kommt oder wenigstens in einen gefahrlosen Stopp. Ein PAP kann bei Detail-Vorgängen helfen. Aber für's Ganze ist er eher hinderlich. Bei PC-Programmen sieht das Ganze ein bissel anders aus, da entfällt natürlich der allererste µC- und hardware-bezogene Teil. Aber da die allermeisten PC-Programme bei mir eben keine Kommandozeilentools a la stdin-->stdout sind, sondern Apps mit GUI, ist zu allererst das Nachdenken über ein sinnvolles "Gesicht" der Anwendung nötig. Manchmal male ich mir das auf, zumeist jedoch nicht. Häufig genug ist jedoch eine Kommunikation zwischen PC und einem µC nötig - und da steht am allerersten Anfang das Ausdenken eines sinnvollen Protokolls zwischen beiden - was dann bis zum Entwicklungsende auch pingelig von beiden Seiten einzuhalten ist. Sonst kommt Chaos auf und keiner ist es gewesen. Deshalb ist dessen präzise schriftliche Formulierung extremer Wichtigkeit. Zumeist lasse ich mir dabei noch eine Art Hintertür offen, also irgend ein Protokoll-Zweig für eventuelle Erweiterungen oder Zusätze. Genauso, wie ich auch bei Kalkulationen mir immer noch nen kleinen Posten für Unvorhergesehenes gönne. Und (O Wunder!) der wird dann auch regelmäßig benötigt und oftmals überzogen... W.S.
Mehmet K. schrieb: > Manuel W. schrieb: >> wenn ich privat programmiere, programmiere ich meistens einfach drauf >> los und beginne erst während des Schreibens Teile in dedizierte >> Funktionen auszulagern usw. > > Hmm, genauso programmiere ich auch. Und das beruflich :) > Okay, etliche Jahre an Erfahrung sorgen dafür, dass dabei auch was > Gscheites rauskommt. > Dabei beginne ich immer mit ganz einfachen Sachen, um zu testen, ob > alles koscher ist. D.h., ich aktiviere die Led und kontrolliere mit der > Stoppuhr, ob die eingestellte Clock-Frequenz auch richtig ist. Und dann > geht es schrittweise weiter. > Was ganz wichtig ist: Falls aus dem Funktionsnamen deren Sinn und Zweck > nicht ersichtlich ist, hat jede Funktion einen kurze Beschreibung. Und > zwar so, dass auch nach 10 Jahren der Groschen eine Chance hat, den > Boden zu küssen. > Sobald das Skellet Gestalt annimmt, beginne ich parallel das Handbuch zu > erstellen. Ich habe naemlich die Erfahrung gemacht: sobald das Geraet > ausgeliefert ist, fehlt einfach die Lust und auch die Zeit, dieses zu > erstellen. > > Langer Rede kurzer Sinn: ich kann mich nicht erinnern, jemals ein > Programm mit Bleistift und Papier begonnen zu haben. Was zwei > Schlussfolgerungen zulaesst: entweder hatte ich bis heute keine allzu > komplexen Aufgaben zu bewaeltigen. Oder ich kann auch sehr komplexe > Probleme gedanklich in den Griff bekommen. Hoffe, dass es das letztere > ist :) Oh Gott. Lass mich raten, KMU? Du machst alleine SW? Maximal zw. 5k - 10k LoC. Ja da kann das noch funktionieren. Darüber hinaus geht sowas einfach nicht. Schon alleine, weil da mehr als 1 Person beteiligt ist. Dabei ist es egal, ob du eine Java EE Applikation programmierst, oder einen 2 MByte SW für einen µC mit komplizierten Algorithmen. Für Hobbyprojekte sind solche Konzepte ganz gut, man macht es ja weil Programmieren/"das Spielen" Spass macht. Nicht weil man es verkaufen und damit Geld verdienen will. Willst du das einzig und allein in Hobbyprojekten nutzen: - Papier und Stift -> Grobkonzept -> bisserl granularer (dazwischendrin programmiert man immer mal wieder etwas, um ein Gefühl für die Probleme zu bekommen) -> dann ausprogrammieren, nachdem man das Ganze grob/fein in Funktionalitäten aufgeteilt hat (z.B. Kommunikation oder Ausgaben) Willst du dir evtl. zusätzliches Wissen aneignen, welches du später irgendwann anwenden willst um damit Geld zu verdienen, denk an folgendes: - Große Projekte (ab 5 - 10 Leute, hoch bis 100 Programmierer) stecken ca. 30% des Gesamtaufwandes in die Anforderungen (Requirements Engineering in Business Deutsch) - warum? weil wichtig ist das Anforderungen fix sind, bevor sie in SW umgesetzt werden. Ansonsten ändert man zum Schluss nochmal Dinge, und die gehen richtig ins Geld - Nochmal soviel wird typischerweise in Test & Architektur investiert (egal welches Vorgehensmodell, Scrum, V-Modell etc.) Tests werden in Hobbyprojekten oft hintenangestellt. - ca. 10% für die ganze Organisation außenrum - max. 30% gehen wirklich ins Programmieren. Architektur ist halt wichtig, dabei ist die Programmiersprache völlig egal. Man kann Klassendiagramme auch in C umsetzen, auch wenn die dann natürlich was Kapselung und Polymorphie angehen, aufgeweicht sind. Das ist aber nicht schlimm. Viele Diagrammtypen (Aktivitätsdiagramm, Datenflussdiagramm, Statemachine) sind völlig Sprachunabhängig und eignen sich, meiner Meinung nach, besonders für Hobbyprojekte. Man kann einfach im Voraus abschätzen was man alles machen muss, um vom Start A zum Ziel B zu kommen. Welche Komponenten man dann hat, wie man die unterteilt, ergibt sich dann oft wie von selbst. Auf alle Fälle ist es eine gute Arbeitsweise, erst Hirnschmalz in ein Projekt zu stecken, bevor man anfängt zu Programmieren. Einfach mal drauf loscoden macht zwar Spass, führt aber selten gut zum Ziel. (ausgenommen sind natürlich 1-Mann Projekte, wo der Programmierer sehr gut weiß was er macht und was er machen will - aber auch da gilt: Wenn er nicht weiß welche Anforderungen er hat, wird das nix).
Manuel W. schrieb: > Hallo zusammen, > > wenn ich privat programmiere, programmiere ich meistens einfach drauf > los und beginne erst während des Schreibens Teile in dedizierte > Funktionen auszulagern usw. > > Ich finde das mittlerweile ziemlich mühselig. Ich würde künfitg gerne > (1) erst die Grundstruktur der Software festlegen und (2) anschließend > erst die ganzen Funktionen auskodieren. Hallo, das ging mir auch so. Ich habe das hier durchgearbeitet: https://wiki.delphigl.com/index.php/Tutorial_Softwareentwicklung1 (auch Teil 2 und 3) Vorallendingen das B-C_E-Prinzip hat mir sehr weitergeholfen. Programieren tue ich in Python, wo sich OOP auch schön umsetzen lässt. Aber auch in C kann man sicher viel übernehmen. Wenn man das B-C_E-Prinzip gut umsetzt ist es auch ziemlich einfach ein Kommandozeilenprogramm auf eine GUI zu erweitern.
Manuel W. schrieb: > wenn ich privat programmiere, programmiere ich meistens einfach drauf > los und beginne erst während des Schreibens Teile in dedizierte > Funktionen auszulagern usw. > > Ich finde das mittlerweile ziemlich mühselig. Ich würde künfitg gerne > (1) erst die Grundstruktur der Software festlegen und (2) anschließend > erst die ganzen Funktionen auskodieren. Du möchtest also von der Bottom-Up- zur Top-Down-Methode wechseln. > Ich vermute, dass es da für sicher schon etablierte > Methoden/Entwurfsmuster usw. gibt. Könnt ihr mir da Hinweise geben? Wie > geht man da am besten vor? Dafür gibt es IMHO nicht "die eine, die beste" Vorgehensweise; es hängt immer von der zu lösenden Aufgabe und ein bisschen auch von Dir selbst ab, welche Methoden für Dich besser funktionieren und welche weniger gut. In einer ersten Entwurfsphase helfen mir Mindmaps, um mir zunächst einen Überblick zu verschaffen. Bei der Übersicht über Datenstrukturen und die Beziehungen zueinander ist UML recht brauchbar, bei der Modellierung des Programmablaufs hilft ein klassischer PAP. Bei Netzwerksoftware mit mehr als zwei beteiligten Maschinen können Diagramme ebenfalls sehr hilfreich sein, um die Kommunikationswege und Datenflüsse besser zu verstehen. Ich ganz persönlich verwende für Diagramme aller Art gerne das Programm "dia"; das ist ein bisschen gewöhnungsbedürftig in der Bedienung, kann aber verschiedene Diagrammtypen (unter anderem UML, PAP, Netzwerke) und ist für Linux, Windows und MacOS verfügbar. Für Mindmaps gibts Werkzeuge wie Sand am Meer; unter Linux nehme ich "vym". Meistens entwerfe ich kleinere Programme allerdings immer noch im Kopf und benutze die verschiedenen Diagramme dann weniger zum Entwurf, als vielmehr zur Dokumentation meiner Software. Einerseits sagt ein Bild ja bekanntlich mehr als tausend Worte, andererseits geht mir das mit der Dokumentation so deutlich schneller von der Hand. Obwohl mit Drittwerkzeuge die Möglichkeit bieten, etwa aus UML-Diagrammen von "dia" Code erzeugen zu lassen, nutze ich das Feature so gut wie nie, höchstens mal für einen ersten Startpunkt bei einem Datenbankschema.
problem schrieb: > Oh Gott. Lass mich raten, KMU? Du machst alleine SW? Maximal zw. 5k - > 10k LoC. Ja da kann das noch funktionieren. Darüber hinaus geht sowas > einfach nicht. > (...) > Große Projekte (ab 5 - 10 Leute, hoch bis 100 Programmierer) stecken > ca. 30% des Gesamtaufwandes in die Anforderungen (Requirements > Engineering in Business Deutsch) Verzeihung, mein Fehler. Ich vergass, dass dieses Forum hauptsaechlich von solchen Leuten besucht wird, die entweder Angestellte in Grosskonzernen, oder gar Besitzer solcher Konzerne sind. Und wenn ich jetzt im Nachhinein den Eröffnungstread mir nochmals so anschaue, wird mir auch klar, dass der TO ganz offensichtlich ein Konzept für ein Grossprojekt mit zig Programmierern suchte. Nochmals: sorry!
Manuel W. schrieb: > Hallo zusammen, > > wenn ich privat programmiere, programmiere ich meistens einfach drauf > los und beginne erst während des Schreibens Teile in dedizierte > Funktionen auszulagern usw. > > Ich finde das mittlerweile ziemlich mühselig. Ich würde künfitg gerne > (1) erst die Grundstruktur der Software festlegen und (2) anschließend > erst die ganzen Funktionen auskodieren. > > Ich vermute, dass es da für sicher schon etablierte > Methoden/Entwurfsmuster usw. gibt. Könnt ihr mir da Hinweise geben? Wie > geht man da am besten vor? Also ich für meinen Teil habe mit 10 Jahren mit Programmieren angefangen, hab es einige Jahre gemacht, hab dann wieder aufgehört, und habe jetzt dann in der Arbeit gleich mit einem Großprojekt wieder anfangen dürfen. Die wichtigste Erkenntnis war für mich: Lerne OOP! Ich komme aus der Visual Basic Ecke, da gibt es zwar Klassen, aber dann hört das auch schnell wieder auf. Hätte ich als Kind gleich C/C++ gelernt, wäre ich heute wohl ein weitaus besserer Programmierer. Aber das nur am Rande. Ich habe das Projekt auch hier "einfach mal drauf los" gestartet. Ich muss dazu sagen, ich habe das Projekt vom Vorgänger übernommen, und der Code ist komplett unwartbar gewesen. Ich musste es neu machen, weil das Teil so verklausuliert war, dass ich mich nicht mehr einfinden konnte. Und außerdem konnte ich ja noch kein C#. Nach elend viel Programmieren kam ich dann an den Punkt, ab dem die Implementierung von Funktionen "außer der Bahn" zu so vielen Workarounds wurden, dass ich nach 2 Monaten Entwicklungszeit das komplette Projekt in die Papiertonne getreten habe und nochmal von der Pike auf neu angefangen habe (ich hatte meinen Chef gewarnt, dass ich einfach schon lange nicht mehr programmiert habe). Schlussendlich war es der beste Meilenstein im Projekt, weil ich damit alle Fehler, die ich beim ersten Herangehen begangen habe, durch eine weitaus bessere Struktur vermeiden konnte. Dennoch würde ich heute nochmal anders herangehen, denn auch jetzt sind ein paar faule Hunde drin :) Was ich damit ausdrücken will: Ziellosigkeit ist der größte Feind und führt nur dazu, dass man sich selbst kein Konzept aufzwingt, das man dann konsequent umsetzt. Im schlimmsten Fall artet das dann so aus, wie bei mir, sodass man dann anfängt, an verschiedenen Ecken ähnliche Probleme anders zu lösen. Und spätestens jetzt schafft man sich eine Wartungsleiche. Daher - und jetzt kommt der Bogen zur OOP - sollte man (ich) immer versuchen, ein Programm in zwei Ebenen zu teilen. Eine Funktionalitätsebene, und eine Abstraktionsebene. Die Funktionalitätsebene kapselt Programmteile, die wiederverwertet werden können. Die Abstraktionsebene stellt durch objektorientierte Funktionen die wiederverwendbarkeit sicher. Und nichts lässt sich heutzutage konfortabler verwenden, als Objekte. Die Frage, welche Objekte ich benötige, beantworte ich mir aus der GUI. Eigentlich fange ich diese relativ früh an, und baue ersteinmal mein Konglomerat an gewünschten Funktionen. Die GUI muss noch nicht schön sein, sie muss erstmal nur funktional sein. An diesem Punkt merkt man eigentlich dann schon, wohin die Reise geht. Denn als nächstes beantworte ich mir die Frage, wie ich die Funktionen, die ich jetzt alle haben möchte, so gestalten muss, dass sie im gesamten Programm harmonieren. Daraus ergibt sich dann auch sehr schnell die Schnittstellendefinition. Und auf Basis dieser Schnittstellendefinition lässt sich über die Abstraktionsebene die Funktionale Ebene von der GUI trennen. Im Grunde missbrauche ich damit die GUI als Lastenheft. Natürlich kann man dies auch mit Stift und Papier machen. Gerade in größeren Arbeitsgruppen kommt man vermutlich auch gar nicht darum herum, weil man im Team wohl sehr schlecht eine GUI als Vorlage nutzen kann :) Dennoch: Stift und Papier gehören definitiv dazu. Man muss sich ersteinmal einen Eindruck davon verschaffen, was man eigentlich möchte und seine Aufgaben klar abgrenzen. Gerade Entwickler jeglicher Art neigen zu Overengineering. So wird nur leider kein Projekt jemals fertig. Was ich auch beim Programmieren mache ist eine Prioritätenliste. Dort stehen alle Teilaufgaben, die ich zu erledigen habe. Ich priorisiere diese Aufgaben von 1-3 (wichtig/unwichtig) und fasse so logische Gruppen zusammen. Bisher fahre ich mit dieser Methode ganz gut. Besser geht's mit Sicherheit immer.
Mark Brandis schrieb: >Übrigens: Bevor man überhaupt mit dem Software Design anfängt, steht >erst einmal das Feststellen und Aufschreiben der Anforderungen. Ja genau. Und das beschreibt man dann formal korrekt als Use Case Diagram. https://en.wikipedia.org/wiki/Use_Case_Diagram
Sheeva schrieb >Ich ganz persönlich verwende für Diagramme aller Art gerne das Programm >"dia"; Ein Link wäre da nicht schlecht: https://de.wikipedia.org/wiki/Dia_(Software)
Markus schrieb: > Sheeva schrieb >>Ich ganz persönlich verwende für Diagramme aller Art gerne das Programm >>"dia"; > > Ein Link wäre da nicht schlecht: Gern: http://bfy.tw/6e6h
Hanswurst schrieb: > Das eine nennt sich "Top-Down", dass andere "Bottom-Up". Nicht, > "Richtig" und "Falsch". Wie die vorstehenden Beiträge belegen, klären wir zunächst, was wir machen und wie wir es machen. Wir beginnen mit dem Ganzen und verfeinern es bis wir bei elementaren Dingen angelangt sind. Dies gelingt bei nicht zu grossen Programmen im Kopf. Dann können wir mit der Implementierung beginnen. Oft beginnen wir mit den elementaren Dingen und bauen daraus das Ganze auf. Analyse und Design verlaufen Top-Down. Die Kodierung Bottom-Up. Wir sind uns ziemlich einig, dass wir unsere Vorüberlegungen aufschreiben sollten. Dann passiert es nicht, dass wir uns verzetteln und am Anfang (Bottom) überflüssiges (Rüschen) schreiben. Niklaus Wirth hat vor, ich glaube, 40 Jahren gezeigt, dass es Vorteilhaft ist, frühzeitig zu kodieren, also Top zuerst zu schreiben. Damit kann frühzeitig geklärt werden, ob und wie das gesamte Programm läuft. Wenn wir frühzeitig unsere Überlegungen kurz und knapp darstellen und sie mit Kommentar und Kode beschreiben, haben wir erstens unsere Überlegungen aufgeschrieben, zweitens gut dokumentierten Kode und drittens bereits früh geklärt ob, das Ganze überhaupt funktioniert. >> Das ist übrigens ein alter Hut von Niklaus Wirth.
Manuel W. schrieb: > Das steht dann wohl > für "Programmablaufplan". Ich habe mich da ein bisschen eingelesen, und > mir kommt es vor, als wenn man da schon wirklich sehr im Detail wäre. Nö, wie tief ein PAP geht, bestimmst allein Du. Man macht ja auch nicht einen großen PAP über das gesamte Programm, sondern viele kleine für die jeweiligen Module. Die Unterteilung in Module ist wichtig, damit man den Durchblick behält. Man sieht im PAP sehr schön, was in ein Modul rein bzw. rausgeht, welche Untermodule es benötigt und welche Querverbindungen zu anderen Modulen bestehen. Meine PAPs sind auch mehr für mich selbst, damit ich meine Ideen nicht wieder vergesse. Meistens zerknülle ich die Kritzeleien nach dem Coden und dem Test. Eine Doku sollte man allerdings auch erstellen, z.B. als Übersichts-PAP oder als Text. Es ist auch nicht verkehrt, erstmal ein Pflichtenheft für die Software zu erstellen. Also mit dem Schwerpunkt, was muß die Software alles machen, das Wie ist erstmal zweitrangig. Manuel W. schrieb: > Mein Kopf ist nicht groß genug, um alles im Hirn > zu behalten. Wenn ich das Projekt von Anfang bis zum Ende durchgedacht > habe, habe ich den Anfang schon wieder vergessen. Das ist normal. Wer behauptet, er könne alles direkt aus dem Kopf coden, der hat bisher nur sehr kleine Projekte bearbeitet und auch nicht im Team, sondern nur als Einzelkämpfer.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.