nicht angemeldet
Hi Frank,
daran liegt ja eigentlich der Sinn, Software zu schreiben, die den Geschäftsablauf unterstützen bzw. ausführen und nicht einen eigenen Ablauf aufgrund der Technik vorzugeben. Insofern versteh ich deinen zweiten Satz "Wir haben ... nicht aber nach Sotware-Ablauf" nicht ganz.
Naja - weil die Abläufe in unserem Unternehmen nicht so perfekt waren haben wir zunächst den Prozess nach Arbeitsablauf neu definiert und dann auch so programmiert.
Das aber wurde extrem komplex (viele Funktionen etc. im Code, die von irgendwo aufgeruden werden), weswegen mir jetzt eine Darstellung fehlt, die alle involvierten Dateien/Funktionen/Klassen etc zeigt. Denn dieser Software-Flow ist noch mal ein anderer als der eigentliche Prozessablauf im Unternehmen. Daher auch meine Anfrage, womit und wie man sowas am besten visualisiert.
Was heisst leider? Nicht jedes Problem muss seine Lösung in der Objektorientierung finden und für die Entwicklung das Heil allein in OOP zu suchen, ist auch kein Erfolgsgarant.
Das stimmt - aber ich halte die OOP für eine Möglichkeit, den Code besser zu strukturieren und Redundanzen zu vermeiden.
Aber das übrige Konzept sollte auch stimmen.
Diagramme und Modelle sollen dir helfen komplexe Zusammenhänge aufzubereiten (sich darüber klar zu werden)
Ich stimme dir voll zu!
Sie sollen nicht nur zur technischen Befriedigung (von UML Fetischisten) gemacht werden ;)
Stimmt, das sicher nicht - aber ein bisschen Dokumentation (und diese über Kommentare im Quelltext hinausgehend) hat auch noch nie geschadet...
Also,
schöne Grüße & schönes Wochenende,
Tobi