Softwareentwurf vor der Programmierung

  • Allgemein

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    Softwareentwurf vor der Programmierung

    Servus Leute!

    Mich würde mal interessieren, wie ihr eure Software plant und entwerft, sofern ihr das tut. Einfach drauf los schreiben kann ja jeder :D
    Wie geht ihr vor? Nutzt ihr Architekturmuster? Entwerft ihr Diagramme? Und wie bringt ihr das alles dann unter einen Hut?

    Ich mache mir meistens auf einem Schmierblatt oder nem Whiteboard ein ganz grobes Archiktekturdiagramm und grobe Klassendiagramme. Erst im Nachhinnein entwerfe ich Klassendiagramme in UML bzw. Nassi-Shneidermann-Diagramme für Algorithmen um eine gewisse Übersicht zu bekommen. Aber ich bin nicht wirklich zufrieden damit, denn zum Einen flacken die Diagramme dann irgendwo im Projektordner rum und zum Anderen habe ich dann ja erfolgreich die Planung nach der Entwicklung gemacht :D. Mir fehlt sozusagen der große Blick aufs Ganze und die richtige Vorgehensweiße zur Planung im Vorhinein.

    Daher würde mich einfach mal interessieren, wie ihr so vorgeht.
    LG ^^
    @ichduersie Bei mir ist ein wichtiger Punkt die Austauschbarkeit von Moduln, z.B. Kameras.
    Das Programm soll mit mehreren Kameras laufen, aber dem User soll egal sein, welche physische Kamera dran ist.
    Wichtig ist hier, ein gutes Interface zu designen, eigentlich zwei:
    Ein Interface zur Ansteuerung der Kamera (Init, Setzen, Auslesen der Parameter, Snapshot, Live, ...),
    ein Interface zur Beschreibung der Parameter {Breite, Höhe, Has16Bit, Seriennummer, ...}.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    VB-Fragen über PN / Konversation werden ignoriert!
    @RodFromGermany: Darauf achte ich auch sehr. Genau aus dem Grund abstrahiere ich sehr viel und gliedere viel in voneinander unabhängige Module. Da ich meistens mit C arbeite, habe ich dafür natürlich keine Namespaces aber Bibliotheken tuns auch :D

    Aber gerade in C ist es mMn nochmal schwerer, eine wirklich brauchbare Archiktektur für ein großes Programm zu entwerfen und grafisch darzustellen. Denn logischerweise fallen hier auch noch die Klassendiagramme raus. In C# und C++ fällt es mir da noch etwas leichter :D
    So blöd es klingt:

    Ich hau mich mit 10 Blatt Papier und nem Kuli in nen Raum, kritzel wild drauf los und bekomme im Endeffekt einen Grobdesign von API/Frontend/Datenbank, was man halt so braucht.

    Ich abstrahiere das auch meist soweit, dass die Struktur der Applikation zwar klar ist, aber das "wie" beim Programmieren geklärt wird.
    Es gibt nichts schlimmeres, als wenn du deinen Entwurf umsetzt, merkst dass es evtl. einen bessere Lib/Möglichkeit gibt und du dann den ganzen Entwurf anpassen oder neu designen darfst.

    Ich denke auch, dass alles andere zwar "logischer" und im Endeffekt auch besser auf lange Zeit gesehen ist. Aber die Zeit dazu muss man erstmal haben xD


    LG, Acr0most
    Wenn das Leben wirklich nur aus Nullen und Einsen besteht, dann laufen sicherlich genügen Nullen frei herum. :D
    Signature-Move 8o
    kein Problem mit privaten Konversationen zu Thema XY :thumbup:

    ichduersie schrieb:

    Nutzt ihr Architekturmuster? Entwerft ihr Diagramme? Und wie bringt ihr das alles dann unter einen Hut?
    Ich hab heut was sehr kleines gebastelt: einen Sql-Transformer, der aus generiertem Linq-Sql ein Sql macht, was man leichter lesen kann, und was man auch direkt im SqlManager eingeben kann und ausprobieren.
    Angefangen hab ich mit einer ungefähren Idee des Datenmodells, dann habich im Dataset-Designer ein konkretes Datenmodell gebastelt (und damit gleichzeitig ein ER-Diagramm erstellt), und dann habich drauflos-programmiert - zunächstmal ühaupt Laden/Speichern/Anzeigen der Daten, dann bisserl Text-Verarbeitung, damit aus dem einen Sql ein anderes wird.
    Beim Rumspielen hat sich dann gezeigt, dass mein Datenmodell viel zu kompliziert war, also als letztes habich nochmal derbe vereinfachen können.

    Von Herum-Abstrahieren halte ich nicht viel, bei mir wird abstrahiert, wenn nötig - nicht vorher.
    Auch Diagramme bringen nix: Entweder sind sie total allgemein und damit nichtssagend, oder sie sind detailliert - dassis aber so aufwändig, dass man in der Zeit auch den Code geschrieben hat.
    Die heutigen Hochsprachen brauchen keine Diagramme mehr, denn Code erklärt sich selbst.
    Und "über-planen" bringt auch nix - es zeigt sich immer erst beim Programmieren, wie der Plan wirklich sein muss.
    • Anfangen tu ich mit viel denken, was das Proggi können soll.
    • Dann Datenmodell - vorzugsweise typisiertes Dataset
    • Dann rohe Oberfläche
    • Dann Feature-Complete
    • Dann überflüssigen Kram weghauen / Architektur zurechtrücken.
    • Feinschliff

    Acr0most schrieb:

    Es gibt nichts schlimmeres, als wenn du deinen Entwurf umsetzt, merkst dass es evtl. einen bessere Lib/Möglichkeit gibt und du dann den ganzen Entwurf anpassen oder neu designen darfst.
    Sehe ich genauso.

    ErfinderDesRades schrieb:

    Auch Diagramme bringen nix: Entweder sind sie total allgemein und damit nichtssagend, oder sie sind detailliert - dassis aber so aufwändig, dass man in der Zeit auch den Code geschrieben hat.
    Die heutigen Hochsprachen brauchen keine Diagramme mehr, denn Code erklärt sich selbst.
    Eben. Und falls man doch mal noch Hilfe braucht, kann man ja bspw. auf Doxygen o.ä. zurückgreifen. Nur bin ich einfach verunsichert, schließlich lernt man in Schule und Uni oft Anderes. Mir wurde damals fröhlich der SDLC und UML eingeprügelt, aber wir haben in den Klausuren auch noch den Quellcode auf ein Blatt Papier geschrieben.

    Ich dümpelte eben immer so vor mich hin (mit meinen kleinen Miniprojekten), aber habe noch nie wirklich an einem richtig großen Projekt mitgearbeitet bzw. eines gestartet. Hat sich einfach nie wirklich ergeben, daher fehlt mir da einfach die Erfahrung...
    Als erste besteht bei mir immer eine Idee, ein Vorhaben, eine Optimierung etc.

    Ich beschreibe mir in ganz groben Zügen zuerst was genau das Ziel ist, was es können muss, und was es erfüllen soll.

    Dann erstell ich mir einen groben Ablaufplan und ein paar wichtige Meilensteine, und wenn nötig einen ungefähren Zeitplan. (Wobei ich hier sehr flexibel sein will)

    Anhand dieses Ablaufplanes sehe ich dann auch ungefähr, was auf mich zu kommt. Das kann also auch unter Umständen das Einarbeiten bzw. Einlesen in gewisse Themen sein, die ich noch nicht kenne.

    Dann fange ich an Programmieren.

    Viele Details löse ich eh immer gleich direkt aus dem Kopf. Schwierige und komplexere Sachen löse ich mit Blatt Papier und Bleistift. Es kann sogar vorkommen, dass ich zuerst ein oder mehrere kleine Sub-Projekte starte, und dieses dann in das Main-Projekt einbaue. Das sind dann aber schon sehr komplexe Sachen, die ich ausgiebig vorher teste und optimieren möchte.

    Wenn das Ganze dann fertig ist, wird es nochmals verfeinert, verbessert und getestet.

    Freundliche Grüsse

    exc-jdbi
    Nachdem definiert wurde was das Programm können soll, bastel ich die GUI und dann das Datenmodell. Dann lernt das Kind Laufen und Schwimmen. Am Ende der Feinschliff. Ich hasse den Feinschliff. Denn hier geht so dermaßen viel Zeit drauf um Fehlein-/angaben abzufangen und den User sinnvoll dabei zu unterstützen das Programm bedienen zu können.
    "Gib einem Mann einen Fisch und du ernährst ihn für einen Tag. Lehre einen Mann zu fischen und du ernährst ihn für sein Leben."

    Wie debugge ich richtig? => Debuggen, Fehler finden und beseitigen
    Wie man VisualStudio nutzt? => VisualStudio richtig nutzen

    mrMo schrieb:

    bastel ich die GUI und dann das Datenmodell
    hihi - bei mir umgedreht.
    Weil aus einem Datenmodell kann man sich Gui-Elemente generieren lassen (sehr einfach sogar) - aber nicht umgekehrt.

    Das macht, dass bei mir ein Proof-Of-Concept - Prototyp schon sehr früh verfügbar ist, sodass ich allerlei Sackgassen vermeiden kann.